A geographic breakdown underscores the fact that cloud projects are business projects first, IT projects second, and cloud projects a distant third.

Seattle is a wonderful city, as long as it's not raining. The fact that it does rain there quite a bit means there's lots of clouds, but not apparently the kind you build using IT and network products. Seattle is one of the major metro areas with a high failure and delay rate for cloud computing projects, despite the fact that it sits literally on Microsoft's doorstep.

Cloud projects are a challenge for businesses everywhere, but I noticed that they are less likely to be a problem in East-Coast cities that we'd think were disconnected from the new age centers of the cloud, compared with places out on the West Coast where cloud giants tend to have their headquarters locations. That raises the question of what secret sauce the old iron age players of the east might have found. Is it as simple as "Yuppies can't do clouds"?

In one sense, that's what my surveys suggest. If you look at the cities where cloud success rates are the highest (New York, Boston, even Chicago), what you find are cities where IT and network executives have reported losing ground in terms of influencing their companies' plans. At least in the Eastern cities, those enterprises where IT is still strongest is also where cloud issues are most likely to arise. That sure sounds like the IT guys are messing up the cloud projects.

Except that they aren't, as you can see when you look at smaller metro centers. Here, the chances of a cloud project failing is four times as high without IT support as with it. However, the chances of the project being delayed are twice as high when IT is involved—a figure that holds for smaller markets as well as the big centers of (relative) cloud success like New York. So what's happening here?

One thing that jumps out of more detailed interviews is that cloud projects tend to originate either in IT organizations or in line departments, and, to some extent, this may explain where the issues with smaller, and particularly West-Coast cities, arises. On the West Coast, in cities like Seattle and San Francisco, we have cloud projects that reflect a kind of state-of-the-cloud-art. They push the technology limits. If you look at the extent to which cloud projects are revolutionary versus evolutionary, the West Coast unsurprisingly leads the revolutionary charge. On the East Coast, projects are more likely to be modest cloud enhancements of current IT activities. The projects are smaller relative to total IT spending in the east than in the west, and that alone means less risk of failure.

Another interesting point is that East-Coast projects are much more likely to be launched by business/operations executives than IT executives. While IT still gets involved, their mission is more one of support than of decision, and that combination of a business-unit driver and an IT/CIO-level facilitator seems to be very favorable for cloud project success.

Still, there have been some high-profile cloud successes out on the West Coast—what accounts for these? One reason is that most of the early cloud projects have been focused on online services rather than on the transformation of business IT. It's not that these latter types of applications aren't potentially good cloud applications, but right now they're not the typical kind of application a business is considering for the cloud. Online services, on the other hand, are a natural for moving to the cloud, but that's a limited addressable market: We all can't be in the travel-site business.

The final factor in the seeming East-Coast localization of cloud IT project success is the depth of experience of the project teams. The average level of experience of the CIOs in the West-Coast projects was four years in senior management while the East-Coast CIOs had nine years on the job. The head of the cloud project also had twice the number of years in their current position or level of responsibility than the comparable West-Coast person. The West-Coast people had nearly twice the experience in cloud technology, though.

The moral here is that cloud projects are business projects first, IT projects second, and cloud projects a distant third. In places where there is a long history of IT support of business operations, that priority list is accepted by all and it drives how projects are proposed and how they develop. In places where business processes and IT processes matured almost side by side, there's still perhaps a bit of tension over who is in charge, over what the real priority of the project is.

Remember our finding that IT involvement raises project success rates but also raises the chances a project will be delayed? That seems to represent a period in which the two poles of the project—business operations and technology planning—reconcile to each other. It's taking longer for that to happen than people expected, but it has to happen or the project's risks rise precipitously, and the cost of failure in a cloud project can be very high.

The good news is that there is some indication, in the correlation of the 2010 and 2011 survey results, that best practices for cloud projects are socializing (largely within industries and through personal contacts) between the East and West coasts, and that the sharp divisions of the past may be ending. Look up at the clouds next time you're in Seattle. The sun may be peeking through.