Why some projects never end

My chum Steve Swoyer recently posted some new thinking on IT project management, and as usual, he brings clarity to the conflicting FUD that gets dished out to us on a daily basis. Since SOA , in a collective sense, may be one of the biggest projects any of us will undertake, its worth our while to look at what makes projects successful.

I know, purists will argue that SOA should not be regarded as a mere "project." But if SOA deployment is not treated as a project -- with project management methodologies -- it will be doomed to wander about the enterprise like a porcupine in a balloon factory, making annoying popping sounds and getting on people's nerves, and ultimately serving no useful purpose.

Steve cites the latest data out of Cutter Consortium, which validates previous studies that show that the vast majority of software projects are neither completed on time nor under budget. Nearly half (44 percent) of all organizations say they have abandoned one or more software projects over the last three years. However, for the most part, most projects will eventually get done, somehow, at some point in time. By sheer will, or perhaps brute force, projects are eventually brought through to completion.

Is this a good thing that projects get shepherded through, no matter how late, and how far over budget? Cutter concludes that companies tend to "stay the course-without substantially revisiting or revising their initial project assumptions, the governance model they're using to manage and track project progress, or the capabilities of their project development team."

So, is this the ultimate fate of SOA projects, no matter how well intentioned?

Cutter senior consultant E.M. Bennatan says the key "is to identify when a project is a catastrophe and when it's not. For example, if a project is more than 50 percent behind schedule; if it's more than 50 percent over budget; or if it's plagued by serious quality problems, it's objectively a catastrophic failure. This doesn't mean it's irredeemable, however: Even project catastrophes can still be salvaged, provided organizations take the necessary steps to do so."

Often, projects run amuck because the business changes, but the project doesn't adapt accordingly. Again, is the fate of SOA?  Can we avoid making these integration efforts bloated, out-of-synch projects that outlive their intended purpose?

For now, it's not an issue. In fact, SOA and Web services may offer some relief from this fate, at least initially, because they can be built and rolled out incrementally, rather than all in one big bang. Plus, standardization makes it possible to rapidly link many application components.

But eventually, we're going to call on the enterprise to commit some serious money and staff time to start bringing the various pieces of an SOA together. In his column, Steve hints that an incremental approach, in which various pieces of SOA projects are broken up and managed as chunks, may help stem the bloating seen with most other IT projects.