The causes of failure in software projects are extraordinarily well documented. The Standish Group’s annual CHAOS reports, Gartner’s periodic surveys, and U.S. Defense Department studies of its own projects punctuate legions of anecdotal reports of software project woes. Dilbert presents my favorite take on YouTube. The CHAOS reports are particularly rigorous – and monotonous. They chronicle the failures of over 80,000 IT projects over more than 25 years – and find year after year after year that about 60 to 70 per cent of projects are outright failures or are significantly over budget, behind schedule, or of poor quality. Further, the same 10 reasons year after year cause the bad results; a lack of:
So if we know why IT projects fail, then why is Standish still reporting that about a quarter of recent projects fail outright and more than 40 per cent are “challenged?” Why do some of the most recent surveys report results worse than those of 20 years ago? I surmise:
I occasionally ask IT professionals if they’ve heard of these project failure surveys. Their answers are almost always “no.” Their references seem limited to the experiences of themselves and their colleagues.
Standish’s Cause #4 for project failure is lack of “emotional maturity.” In my experience, emotional maturity is critical to team-work, decision-making, and overall project health. But Standish’s solutions for #4 are difficult to operationalize: how does a manger specifically impart community, honor, awareness, objectiveness, and superior excellence. Of course, strong managers do so every day, but if one is lacking, it is just easier to tackle other shortcomings with more tangible remedies.
One expert representing Gartner recommends “keeping the schedule realistic.” But such advice entangles budget, scope and quality, and depends on underlying factors that have consumed more than a few books.
Some organizations have so many problems that their significant improvements still do not yield successful projects. One must cross a critical threshold of capabilities to deliver a project on time, on schedule, within budget and still meet end-user needs. Which set of improvements will yield success and how much time and resources do they require? Priorities are important.
This impediment may exist more than most of us want to admit. But we’ve all seen it. Some of us are even guilty of it. I recall one manager whose team attempted to document a current state process, develop a target state process, develop requirements for a software application to support the new process, and to develop the “wireframes” for the system – all concurrently or at times even in backwards order! When presented with the reasons why this is probably not a good idea, and several potential solutions to remedy the problem, the manager thrice demurred. The multi-million dollar project failed miserably and predictably. Why did this manager refuse sensible advice? Answers to such questions vary widely, and are often difficult to pinpoint. Remedying this problem short of termination is difficult, and so is termination.