My mother’s latest project is projected to be over-budget. Thanks to a change in the way projects are allocated she now has X dollars instead of Y hours. Her project needed 50,000 “IT” hours (yes, she actually did the quote thing with her fingers when she said that), but now it can only have 45,000 “IT” hours because the “cost” (yes, she actually did the quote thing with her fingers when she said that, too, because enterprise dollars are more like Monopoly money than real money) of IT has increased by a few dollars per hour and she was forced to completely change the way the project was accounted for – now using ‘dollars’ instead of ‘hours’. Yes, I was flabbergasted, too, that in the middle of a project the valuations changed and an uncompromising stance of “figure it out” was imposed on all projects, but no one said working in IT was going to be logical, fair, or easy.

This is problematic primarily because the bulk of the costs of projects within the enterprise are staff related. Those “IT” hours might be budgeted separately from other project costs because they are “IT money” and not $vendor money that might be used to acquire software, hardware, or other tangible IT assets required for the project.

Staff related costs often were 50% to 70% of the total cost over a period of three years. Cost of communications, power, cooling and facilities could add up to another 30% to 40% of the total. Hardware and software, when combined, usually represented somewhere between 20% and 25% of the costs.

Surprised to find that people are the most costly component of an IT solution?

-- Cloud computing could cost more than using your own systems, April 2010, ZDnet (emphasis added)

As she was explaining how the change mid-project essentially completely changed the budget, I realized public cloud computing couldn’t change that. There’s nothing in this math that would change simply because the organization was using a public cloud computing based model instead of a traditional client-server mixed with web-based model coupled with legacy mainframe model. The core cost of IT remains the same because it’s based on the cost of IT overall, on a complex calculation involving salaries and benefits and compensation models. That figure, that $X per “IT” hour, doesn’t change because the deployment architecture changed.

If an organization uses different costs per “IT” hour based on the function provided, that might change the overall costs to a project. If security is $70 per hour while IBM WAS configuration is $50 per hour, that might make an impact on a project’s budget. Of course differentiating IT costs based on function might lead to an ugly place: we don’t need all those security hours, we can’t afford them! We don’t need all those testing hours, we can’t afford them. It also impacts architecture. If network security is more “expensive” than putting security in the application from an internal budget standpoint it stands to reason security is going to end up in the application. But when all “IT” hours look the same on the bottom line, there’s really not much cloud can do to change that. By normalizing the cost of IT prioritization of function becomes focused on, well, function rather than cost. And that’s probably a good thing, because we wouldn’t want to ignore security tasks because they cost a bit more in the organizational balance sheet.

So core IT costs aren’t likely to be changed by public cloud computing and, here’s the kicker, public cloud computing might cost the organization more.

What? Couldn’t happen? Consider that traditional troubleshooting techniques don’t really work so well with public cloud computing. Log files aren’t necessarily readily available, there’s no “tap into the switch” to analyze network traffic to find problems, no way to obtain a holistic view of the data path through the network that can obviously identify a bottleneck that’s adding seconds of latency to business transactions that are, by their definition, sensitive to such delays in delivery. Yes, it takes fewer hours to provision and deploy applications in a public cloud, but it is likely to take more hours to troubleshoot issues that arise – and they always arise.

I’m not the only one that’s put forth such crazy-talk. Joe McKendrick recently discussed “Why cloud computing may cost more than on-premise systems” and quoted industry pundit David Linthicum, who goes into much greater detail in his latest book, “Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide”:

Enterprises shouldn’t be fooled for one minute thinking that outside cloud services offer dirt-cheap alternatives to on-premise IT. Dave Linthicum, who also participated in Dana’s latest analyst roundtable, points out that there’s a lot more to enterprise IT than simply accessing and running applications. “Cloud computing typically is going to be a better, more strategic, more agile architecture, but it’s also typically going to be more expensive, at least on the outcome,” he remarks.

But while public cloud computing might not be able to change the core costs, private cloud computing might be able to impact the all important “IT” hours that are available to projects and to the IT hours that used by projects in general. The formula for determine the pool of “IT” hours as explained to me is pretty simple (Disclaimer: I am not an economist, I don’t play one on Twitter, and if you want to read about cloudonomics that are more complex but make perfect sense, you’ll need to visit Joe Weinman’s Cloudonomics blog – and brush up on your calculus). 

Now, what cloud might change in the above equation is the number of total IT hours available to projects because cloud computing has reduced the number of hours required for core IT maintenance and activities. For example, if provisioning a server used to take 40 hours, but now takes only 4, those “extra” 36 hours can be returned to the overall pool of hours available to projects rather than kept for IT themselves. It’s kind of like virtualizing human capital, isn’t it? That leaves 10% of IT staff hours for administrative overhead. Ironically, the only way to increase the pool of available hours is to (a) hire more staff, which may increase the cost of “IT” hours to projects or to somehow reduce the administrative overhead. It’s the latter that may be helped by cloud computing models internally as it should, ostensibly, according to the experts, reduce the amount of overhead associated with the business of IT – provisioning, maintenance, deployment, etc…

This kind of scenario is exactly the reason it should be no surprise that most organizations are driving toward internal cloud computing models not for cost-savings, but for agility and efficiency of IT – not monetarily but operationally. Recent market research for the venture capital firm, the Sand Hill Group, indicates that the drive for agility has outpaced the desire for cost efficiency.

"Forty-nine percent of companies are driven to the cloud for business agility reasons, while only 46% are motivated by cost efficiency," the report states.
                        -- IT Spending on Cloud Ratcheting Up, April 2010, InformationWeek