Project management in action (or inaction)

This week's Computerworld has another article on poor project management; this one is Failed VA security contract 'was an open checkbook'. It seems at least monthly we are seeing an article on an IT project gone bad as a result of poor management. A few months ago, the winner was the failure of Philadelphia's municipal water billing system. This month, we read about a 10-year project that was shut down after three years. If you go back and look, I'm sure there'd be a dozen other stories like that in the past year.

What bothers me the most is how we as IT professionals continue to let this happen. In the recent article, there are a number of contributing factors identified, including changes in how the contracts were managed, non-competitive contract awards and 'deficiencies in planning'. These failures don't involve high tech activities; they don't require engineering degrees nor multiple certifications in various technical areas. They require careful planning, budgeting andcost controls. Sadly, these failures seem to have a common thread: long term projects are doomed to failure if they rely on emerging technologies and large bureaucracies.

I don't think that the problem will ever go away; as applications grow in complexity, there are more things that can break, and as projects grow in size, so do the problems associated with them. I believe that IT professionals should not be allowed to manage these projects. Traditionally, the IT professionals have come up through the ranks as engineers, analysts and have not got the background not the education to handle large projects. It's too easy for us to be inspired by the next new thing to keep a steady hand on project management. It's also a problem for the IT pro who is handling Sar-Box, Security, Interopability and a variety of of other issues. Leave the task of running one of these huge projects to specialists, just like everything else we do these days.

There are not too many CIOs who would go into a new technology without bringing in an expert. I wouldn't touch a contract negotiation without a lawyer next to me; I'd rather he did the work and saved me and my employer, a lot of money. I wouldn't trust a bookkeeper to audit my books, so why would I try to manage a large project? Like I've said in the past, bring in the experts; we just don't have all the answers.

And my last comment on the subject deals with accountability. In the Philadelphia debacle, the IT person involved went to work for a consulting firm before the project took it's final plunge. In the case of the VA, the consulting firm and the VA staffers have no culpability as the project scope changed considerably and wasn't handled correctly at many levels. There needs to be accountability. There needs to be people who come forward and admit to their shortcomings when things fail. We've been watching a line of financial people marching off to club-fed as a result of Enron-like catastrophes. It could very well be time for that kind of result to hit IT for these failures.