When a company's IT project falls apart, what are the key reasons for the failure? Recent research tells us that it's largely about the way a project is planned in the first place.
"Most IT project problems are rooted in ambiguous business definitions," says Satya Iluri, founder and CEO of Capstera, one company working to create IT-project solutions.
From there, Iluri says, projects flounder based on "churn" in requirements gathering, scope creep (beyond a minimum marketable feature set), wild cost guesstimates, not planning for interdependencies, and a lack of strong governance.
Let’s look further at what the experts can tell us about why IT projects fail, starting with what business executives say they consider to be failure in the first place.
Defining Project Failure
A new project is like a space where executives and IT admins meet to make the ideas behind a company materialize. But it's a complicated, nuanced process often fraught with the potential for misunderstanding.
When an IT project falls apart, each side often has its own impression of what went wrong. But at what point do executives tend to categorize a project as a failure?
A 2012 Gartner survey shows that the definition of failure for small, medium, and large IT projects equates to functionality issues — or so say 22%–24% of the respondents. Here are some additional failure-class outcomes, according to the survey:
- Late projects: Small, medium, and large projects fail when they are substantially late, say 23%, 24%, and 28% of the survey takers (the numbers apply to each project size, respectively).
- Cost difference: Especially in the evaluation of medium and large projects, the polled executives say that a substantial difference between actual and projected project cost amounts to an IT-project failure. Some 24% said so in the case of large-scale efforts; 22% said so when it came to the medium class.
Other factors behind failures included poor quality work and cancellations after launch.
For IT leaders, the criteria for failure is clearly most problematic in the first three categories: functionality, lateness, and cost overrun. Research suggests that there are some root causes to these problems, starting with the way that an IT project is understood from the outset.
Reasons for Project Failure
A McKinsey-Oxford study on the subject may have cracked the code when it comes to underlying causes of IT-project disintegration.
Looking at the numbers, 29% of respondents said the project started with unclear objectives and less than laser-like focus on goals. Just behind that, but certainly attendant to it, were some other key considerations:
- 25% said that an unrealistic schedule and reactive management, as opposed to proactive planning, were to blame.
- 20% cited the negative impact of shifting requirements and unplanned-for technical complexities.
- 13% indicated that unsatisfactory teamwork was to blame, and teams with insufficient skill sets were also a factor.
- 13% of the blame for project collapse ended up in a category that the report classified as "unexplained."
For IT, it's that last category that can wreak particular havoc. Leaving the interpretation of project failure to Monday-morning quarterbacking can further lead to a diminishing number of green lights for future plans.
Pathways to Success
As recently as 2011, a Geneca survey showed that the effect of project failure is to dampen expectations for both IT and business execs. In a survey of 600 such execs, 75% said they that they anticipated some new projects to be "doomed from the start."
That's a bleak prospect, but it doesn't have to be the case. What can fix the underlying problems and create a better sense of anticipation when it comes to IT build-outs?
"While business architecture and capability mapping is not a panacea," says Iluri, offering one suggestion, "it is probably a much needed discipline whenever an IT executive hears, 'Why does that button on the website cost a million dollars' and whenever a business executive hears 'IT does not understand the big picture of, and the requirements for, what business wants from this project.'"
Answers, in a nutshell, rely upon closer attention to providing better information:
- What and How: Lead with a project précis that explains not only end-result capabilities, but also overlays with a description of how the system under construction actually does those things. You want to bring executives into the nitty gritty of the process underneath the project.
- Cost Savings: Overruns are overruns, but it's critical to have a clear understanding of how a given project can save the company money over the long-term, especially when its successful completion stands to reduce future enterprise software spending.
No, we'll never be able to eliminate all project failures. But knowing what to look for, and understanding what business executives are concerned about, from the outset, can help steer your next project to an outcome everyone can evaluate as a win.