IT project failures
by
Charlie Bess
I was exchanging emails with Dennis Howlett about his thoughts on improving EDS' blog. He posted an entry about this blog and so an e-mail discussion ensued. In the process of that discussion, he wondered what I thought about this article from Accounting Age magazine discussing an analysis by KPMG of IT project failures. From what I read, it said that projects fail because of bad metrics and poor governance. I can see their point since exposing something to sunlight illuminates as well as disinfects.
The document does make the statement:
'Success is increasingly being defined as achieving the promised benefits, as opposed to the traditional focus on time and budget measures.’
I find this statement entertaining, since the only reason the project exists is to achieve business benefits. Project managers need to have the business needs as the project objective. If it appears the project will not be done on time and meet the objectives - speak up, early and often. Bad news does not get better with age. Part of developing that understanding will be having useful business metrics, and those may not be easy to find. People in the IT industry are often satisfied with metrics that are easy to collect. People in seats, effort spent...
One thing I determined long ago was that most users “know it when they see it.” Putting all the requirements on paper and beating the user over the head with the documentation is rarely a good idea. Flexibility is required in order to do something useful - plan for it. Contracts may need to shift from hours spent to value delivered. If the real value is there, it can be measured and tracked. If it is not there, it's better to stop the project early.
One of the implications of having a more model driven business that assembles solutions is that it will be a more responsive and value based approach. The traditional project management techniques may need to change significantly to remain viable.
I wrote an entry a while back about metrics. Bill Phifer (one of the other EDS fellows) provided me with these thoughts. Unless carefully considered and monitored, metrics themselves can easily become dysfunctional; Robert Austin (Measuring and Managing Performance in Organizations) likens this condition to gremlins flying an airplane while at the same time giving the pilot what looks like good operational data to believe he is on course. People do tend to understand the metrics that they are measured on, and over time usually find a way to game them to their advantage. That doesn't mean that metrics are bad, only that they need to be carefully collected, stored, analyzed, interpreted, reported and monitored in such a way that they measure the process, not the person.
One reason that fewer projects fail nowadays is because they are typically smaller and shorter; gone are the days of the monolithic 12-24 month project. The industry has learned that most successful projects are completed with fewer than six people and in less than six months - and that smaller project size also allows for more of the hands-on project status and constant communication that you talk about. It also supports most of the core techniques of agile programming methods. The speed of new business innovations as well as new technology integration was also a factor, as these introductions often made a major "new" system obsolete before it was completed.
