Why IT Projects Fail
When project managers talk about IT projects, they more often than not mean business projects with a substantial IT component in them. Sometimes they mean IT product development projects or projects that involve building IT infrastructure, but even these need to have a business case as a foundation so that an organisation can understand the benefits to be derived from the product or implementation and accept the project.
“Ideally there would be no such thing as an IT project, they would all be business projects,” defines John Roberts, vice president and distinguished analyst at Gartner CIO Research (Asia-Pacific). “If we look in the application area of IT, it’s typically building or taking a package and adapting it to apply in a particular business environment.”
Recent research conducted by Gartner shows that, in the Asia-Pacific region, the top three reasons businesses conduct IT projects is to improve business processes, reduce enterprise costs, and manage enterprise change initiatives, showing that upgrading technology or infrastructure is a symptom of the business case, not the other way round.
Marco Cattaneo, subject coordinator of IT Masters at Charles Sturt University, sees an IT project as a change in the current IT infrastructure “from the old operational equilibrium to a new one to meet either new business or IT requirements”. Thus, even projects with large IT components have a business aspect to it, he believes.
Also wary of the term ‘IT project’ is Brent Cahill, program office consultant at The Litmus Group. “There’s no such thing as an IT project, it’s a business project that has an IT component,” he says. “The distinguishing factor is how much of a project is IT. You can have infrastructure projects with 90 percent IT, but nothing is 100 percent IT—there is always a business component.”
It is this business component of an IT project that gives a clue as to why many so-called IT projects fail; they are often treated as a pure IT projects without sufficient regard to their respective business cases and as a result fail to meet the organisation’s objectives. But do IT projects fail more often than other types of projects?
The myth of constant failure
IT projects have a reputation and unfortunately it isn’t a good one. The Standish Group, well known as a research organisation that collects data on projects in the IT industry, first released the now famous CHAOS Report in 1994, at the time revealing that only 16 percent of IT projects were completed ‘successfully’, that is, on time, on budget and meeting user requirements. The remaining projects were either ‘challenged’ (eventually completed, but with schedule, budget and/or requirement problems—53 percent) or ‘failed’ (cancelled or delivered and never used—31 percent).
Since then, the CHAOS Report has tracked the fortunes of IT projects worldwide. The 2009 version shows an improvement with the success rate double that of the 1994 figure at 32 percent, 44 percent considered challenged, and 24 percent recorded as failed.
What the research doesn’t tell you is how this compares to projects in other sectors; in fact, there is little research available that could assist comparison. The focus on IT project failure is therefore disproportionately unfavourable, when the success/challenged/failure ratio appears quite normal for all projects conducted worldwide.
Other research is specific to Australia and concerns IT projects in the public sector. Sir Peter Gershon’s 2008 Review of the Australian Government’s Use of ICT examined the execution and effectiveness of Federal Government IT projects. Gershon’s main finding was around weak governance and disconnect between the government’s agenda and the projects. He also noted that many agencies conducted projects their own way, with the lack of uniformity contributing to “sub-optimal outcomes in the context of prevailing external trends, financial returns, and the aims and objectives of the current Government”.
Considering both Standish’s CHAOS Report and the Gershon review, IT projects may have very public problems, but they are certainly not doomed to fail any more than any other type of project. The task is therefore to find out what does cause them to fail and whether the solution is one that project managers in any sector can take on board.
Intangible benefits
One theory on IT project failure centres on their relative intangibility. “I used to be an engineering manager and I could always walk down to the plant and see the current status of a project. IT projects are a little more virtual than that,” remarks Roberts.
Especially for inexperienced IT project managers, intangibility makes it harder to define scope. In many cases, true scope may not be revealed until some time after a project schedule, budget and the business case has been presented for approval. “Often it takes some time before people actually understand exactly what the project scope really is,” says Roberts. “The real weakness is a lack of a proper risk assessment or a quality assurance test about that project cost and project timing and resourcing.”
