5 reasons for IT project failures aren't IT's fault

I've been involved in a number of IT projects in my career, ranging from overwhelming successes in every sense of the word, to projects that came in a full 100% over budget, to projects that came in on time and on budget but didn't meet the business needs. Most of the articles that I read about IT project failure focus on IT. This is understandable, since by definition, IT is involved in every IT project failure. But when an IT project fails, there's usually plenty of blame to go around. What are some reasons that these projects fail that aren't directly related to IT?

Lack of shared understanding of the project goals

It is tough enough getting business leadership and IT on the same page as to what should go into a software product, where compromises should be made (in quality vs. cost vs. time-to-market), etc. This becomes infinitely more difficult when the individuals on the business team cannot agree to what the product should be. Minor disagreements are normal, and every good IT manager plans for them. But major disagreements can doom a project before it starts. In my experience, the two major sources of these types of conflicts arise when:

• The business stakeholder leading the project only has a vague idea what the project's goals are
• Multiple business stakeholders leading the project have conflicting ideas as to what the project's goals are

The second scenario is less challenging to fix - in this case the stakeholders would need to choose a leader to represent the group and find ways to appease everyone. While this won't solve all issues, it will simplify communication and clarify the vision. It's tough to rescue a project in the first situation, though. In this case, it's often best to stop the project, or start over with clearer goals.

Slow feedback

By far the most common reason that I've encountered that IT projects run long is that the business leaders directing the project are slow in giving feedback. When feedback is slow in one particular area (i.e. what to do with one particular feature), or when feedback is slow about minor details (i.e. what exact wording should go on a button), the software delivery team can usually work around it. But when feedback is consistently slow, or feedback is slow in a particularly critical area, the IT team either has to start pushing deadlines or has to start making guesses as to what the functionality should be. If the IT team is making guesses, you'd better hope that they thoroughly understand the business need behind the system being created, otherwise expect moderate to severe budget overruns as their decisions are removed from the system.

Inability to differentiate "need" from "want"

The average business user would be shocked at the complexity that is present in even the most simple-seeming software product. On top of that, the more complex the business need is, the disproportionately more complex the software needs to be to support it. The best way to combat this problem is to keep the software as simple and small as possible, then build on it as time and budget allows. When business leaders cannot differentiate the things that they must have in order for the project to be a success and the things that they would like in order to make the project better, uncontrollable scope creep occurs and the project never gets finished.

Inability to talk conceptually

Until businesses get smart and start hiring IT personnel who have a deep knowledge of the business they're supporting and business leaders who have a reasonable understanding of the technology they're using, we're going to have a gulf between the vocabulary and understanding of the business leaders and the IT staff that support them. The level of difficulty will vary depending on the skills of both the business leaders and the IT staff. To simplify the discussion, I'm going to define some terms that describe the levels of understanding that business leaders can have about their processes and IT:

• A leader has deep project-level understanding if they are a subject matter expert and have experience/skills in envisioning how their processes could be simplified by software.
• A leader has subject matter expertise if they understand both how their business works and why the processes are the way they are, and can communicate their understanding to others. They don't, however, have the experience or skills to know how specifically how software can fix their problems.
• A leader is a figurehead when they neither have the understanding of their own business processes nor have an understanding of the benefits and limitations of software. (Note, a person who has an understanding of their processes, but cannot communicate them to a non-expert such as IT, might as well be a figurehead for the purposes of an IT project and will be treated as such here.)

I will also draw on a previous post to describe IT's understanding of the business:

• A Stage 2 IT leader will be a technological expert who focuses on delivering what the business team asks for.
• A Stage 4 IT leader will be a technological expert who has an understanding of the business and focuses on delivering a solution that meets the stated business needs.

To show what kind of effect this can have on your project's chances of succeeding, here is a chart that shows my experiences with skill levels and project success. (Note: all cells assume that the IT staff is competent with the technology they're using.)

	Stage 2 IT	Stage 4 IT
Deep Understanding	The business leader will lead the project, and the project will generally run smoothly	Expect success
Subject Matter Expert	Expect a product that is delivered late and/or over budget, as there will be a lot of trial and error during the development process, but the product should eventually meet the business needs	Expect the IT team to lead most aspects of the project and that the business leader will focus on ensuring the details are right
Figurehead	Expect failure	Expect the project to go sideways as poor communication derails the effort

Note that the best chances for success lie when someone, either the business leader or IT, has an understanding of both the business process and the underlying technology. Without that, the ability to communicate both the how and the why of the business processes at hand become vital to the project succeeding by any definition.

Lack of focus

If you try to make a little bit of progress on everything, you won't make significant progress on anything. Yes, there are a lot of areas that need to be improved, but you will be significantly better off by getting one problem fixed then moving onto the next rather than trying to solve everything at once. There is a balancing act that must be done here. If you try to proceed with too many ideas at once, the project will stall and die. If the business leadership tries to be too hyper-focused on only one or two needs, they risk losing the enthusiasm and support of the people who will use the software.