Updated 12:04 p.m., Aug. 11, 2008. Link to report fixed.
A report released this week by Forrester Research Inc. spreads the blame for information technology project failures. It's the bosses' fault, too.
Forrester analyst Lewis Cardin says there is plenty of blame to go around for IT project failures -- not just for the project manager. "Worse still, the conclusion of failure is often incorrect," he writes. Cardin debunks four myths of project failures:
1. Steering committees. They typically avoid blame for failures. These committees are in charge of project governance: approval, setting goals and solving problems. When the committee doesn't make their decisions on time or communicate them adequately to the project management team, projects can fail. "Unless the cause of this delay is visible and shown to be for governance reasons, someone is going to point fingers — months later — to defective project management and not the real source of the delay," Cardin wrote.
2. Business managers. They may add requirements to the project after it has launches, and the changes may very well add benefits that are worth the added costs. But when the project comes to completion, "the business has forgotten about the improved value component while memories are crystal clear about the increased dollar and time investment. A project has a high probability of being tallied under the failure column when in fact it may have been a noteworthy success."
3. Steering committees, again. For projects built from scratch, budgets and time schedules are merely educated guesses. Cardin says project managers can adjust as reality sets in and stay within budget and schedule, but frequently they "must spend more time on damage control with steering committees and project resources rather than on execution — doubling their work when it is least desirable to do so."
4. Business executives. When project managers first estimate costs and time for a project, they frequently say the forecast could fall between plus 75 percent and minus 25 percent - -a big interval. "But business execs remember the number and forget how uncertain it is. . . . As the estimates are refined during planning, requirements, and design, these business execs may see this simply as increasing costs, not as the inevitable result of greater knowledge."
COMMENTS
We identified that the business — in all its forms — was a primary cause of project failure and value loss almost 20 years ago. But what is the traditional response? — better project managers!
We won't get improvement until we educate and train business managers as both project clients and steering committee members.
They don't perform well because, not least, they don't know what to do! I've tried to address this for some years via project-sponsor.com, but until we recognize it as a problem to be addressed, it will persist.
We therefore need to get project managers to recognize that they need an effective business/steering committee and to agitate for its education and training.
Jed Simms 08/11/08 06:49 pm ET
Good article. My experience, starting in the 1970 timeframe, is about a 300% overrun on IT projects. Has this changed much?
You can't know everything going in.
You can't manage what you don't know that you don't know.
Fixing blame is the all-American past-time.
Tom Ciriacks 08/11/08 11:10 am ET
Can't access the report...not sure if it is a firewall issue on my end or something with your link...
Allan, good analysis all around. All the more reason to establish some sort of knowledge base at the beginning of the program that captures business decisions and tradeoffs. Re item #4 - I wonder if this is compounded by the Steering Committees as well...or is it a lack of understanding by those doing evaluations of the programs? If expectations are not properly set or properly understood, that boils down to a lack of program management skills, doesn't it?
voice_in_dc 08/11/08 10:06 am ET
Link to the report is ill-formed or broken.
t1234 08/11/08 09:55 am ET
Cardin's comments are right on the money, especially for projects involving a sizable software development effort. Exactly when the original estimate is made also affects how closely the final budget and schedule track to it. If the scope is settled and the requirements elaborated, a reasonably accurate estimate can be done. New requirements added after that should be recorded as a new schedule baseline and prgress tracked against that, not the originals.
IT Project Manager 08/11/08 09:47 am ET
This one is long overdue. PM after PM gets bashed by overly optimistic senior managers and steering committees who ignore the risks and only remember the initial "baseline." They starve the programs/projects for resources to produce a product about which knowledge of what the job entails grows during development (nothing to do with escalating requirements--only an escalation is understanding what management asked for). Then, they make life worse by cranking up the reporting and oversight requirements without improving the situation. The proposed IT oversight legislation in the Senate will only add to this waste bucket.
Charlie N. Space 08/11/08 09:12 am ET