Root Cause Analysis: Why Do IT Projects Fail (And How to Fix It)

Every post-mortem produces the same list: poor communication, scope creep, weak sponsorship, unrealistic timelines, insufficient resources. That list is symptoms. Run actual root cause analysis on those five and they collapse into three: decisions without a named owner, requirements that were never testable, and status reported as opinion rather than evidence. Fixing symptoms produces a communication plan and another failed project. Fixing causes means naming decision owners, writing acceptance criteria a stranger can execute, and replacing percentage-complete reporting with binary gates. This guide covers the collapse, a method for running the analysis on a live project, and the three fixes.

Introduction

I have read a lot of project post-mortems. They arrive at the same five findings with remarkable consistency, regardless of sector, platform, or budget.

Communication broke down. Scope crept. The sponsor was not engaged. The timeline was unrealistic. We were under-resourced.

The consistency should bother you more than it does. Five different projects, five different teams, five different technologies, and the same five answers every time. Either every organization on earth has the same problems, or the analysis is stopping too early.

It is stopping too early. Those five findings are things people noticed, not things that caused anything.

Why do IT projects fail, according to most post-mortems?

Because the exercise is usually run as a retrospective, which surfaces experiences, rather than as a causal analysis, which asks why each experience happened.

There is a practical reason for this. Post-mortems are run late, by people who are tired, in a room that includes the person who might be blamed. Under those conditions the group converges on findings that are true, nobody disputes, and nobody owns. "Communication broke down" is the ideal finding: accurate, unfalsifiable, and attached to no one.

Then a communication plan gets written for the next project, which also fails, and produces the same finding.

Key Takeaway: A finding nobody can be assigned is not a cause. It is a description.

Running a project you suspect is drifting? Our Planning practice includes independent health checks before recovery becomes the only option. Book a free consultation.

What does root cause analysis reveal instead?

Take each standard finding and ask why until you reach something a person could have done differently. The answers converge fast.

Six findings, three causes. That is what a real analysis looks like, and it is why the standard list is so unhelpful. It has six items where it should have three, and none of them can be assigned to anyone.

Key Takeaway: If your post-mortem produced six findings, you have probably found three causes and three restatements.

The three root causes behind most project management failures

Cause one: decisions with no named owner. Every project generates decisions that are nobody's job. Which of two conflicting business rules wins. Whether a nice-to-have is in this release. Whether to accept a defect or hold the date. When these have no owner, they get made by whoever is blocked, at the moment they are blocked, without the context to make them well. Scope creep is this cause. So is sponsor disengagement, because a sponsor who is never asked to decide anything correctly concludes they are not needed.

Cause two: requirements that were never testable. A requirement that cannot be turned into a test by someone who was not in the room is an agreement to talk about it later. Later arrives during build, when the cost of disagreement is highest. Most "communication problems" are two groups reading the same untestable sentence differently and both being right. Estimates built on such requirements are also guesses, which is where unrealistic timelines come from.

Cause three: status reported as opinion, not evidence. Percentage complete is self-assessed, unfalsifiable, and reliably optimistic until it collapses. A task at 80% has been at 80% for three weeks on every project you have run. Binary evidence, a passing test, a signed gate, a reconciled load, cannot be shaded. Teams that report evidence discover slippage in week four. Teams that report percentages discover it in month six.

The three interact, which is why projects fail suddenly rather than gradually. Untestable requirements generate disputes. Disputes need decisions. Decisions have no owner, so they queue. Percentage reporting hides the queue. Then the queue empties into a single week near the deadline.

Key Takeaway: Failure is rarely one bad thing. It is three ordinary gaps that compound quietly and surface together.

How do you run a root cause analysis on a live project?

You do not have to wait for a post-mortem. The analysis is more useful mid-flight, when there is still something to change.

Step 1: Pick a specific incident, not a theme. "Communication is poor" is unanalysable. "The pricing rule was built three times in six weeks" can be traced.

Step 2: Build the timeline before you build the explanation. What happened, in order, with dates. Do this from artifacts, not memory. Memory reorders events to fit the explanation people already hold.

Step 3: Ask why until you reach a decision a person could have made differently. Stop when the answer becomes a personality trait or an industry condition. "Because the developer was careless" and "because the market moved" are both places the analysis has failed, not places it has finished.

Step 4: Test the cause backwards. If this cause had not been present, would the incident still have happened? If yes, keep going. This one step removes most false causes.

Step 5: Write the fix as a change to a process, not a change to effort. "Be more diligent" is not a fix. "Every business rule has a named owner recorded in the rules register before build starts" is a fix, because it is either true or it is not.

Do this on two or three incidents and the pattern will be visible. In my experience it is nearly always one of the three causes above, which is useful, because it means you are not solving a novel problem.

Key Takeaway: Step four is the one people skip and the one that does the work.

How do you prevent failure in project management before it starts?

Three fixes, matched to the three causes. None of them requires a methodology change or a tool purchase.

• Publish a decision register at kickoff. List the decisions you know are coming, with an owner and a due date for each. Add to it as new ones appear. The register's job is to make an unowned decision visible while it is still cheap.
• Set an acceptance criteria standard and enforce it. Every requirement gets criteria a tester who missed the workshop could execute. Reject the ones that do not. This is unpopular for two weeks and then becomes the reason nothing is re-argued in month five.
• Replace percentage reporting with binary gates. Fewer status points, each one either passed or not, each backed by evidence. You will get worse-looking status reports and better projects.

The first two are business analysis work, and they are the cheapest insurance available on a delivery programme. The third is a governance decision, and it costs nothing but the discomfort of seeing real progress.

Key Takeaway: Every fix here is a process change with a yes or no answer. If a proposed fix depends on people trying harder, it is not a fix.

Frequently Asked Questions

What is root cause analysis in project management?A structured method for tracing an observed problem back to the decision or process gap that produced it, rather than stopping at the symptom. In practice it means building a factual timeline from artifacts, asking why repeatedly until you reach something a person could have done differently, and then testing that cause by asking whether the problem would have occurred without it. The output is a process change, not a lesson learned.

Is root cause analysis the same as a retrospective?No. A retrospective gathers experiences and improves team practice, which is valuable and should continue. Root cause analysis is a causal investigation of a specific incident, run from evidence, aimed at a single traceable chain. Retrospectives produce sentiment and themes. Root cause analysis produces an assignable cause. Most teams run the first and believe they have run the second.

Why do IT projects fail more often than other project types?Largely because the product is invisible until late. On a construction project everyone can see that the second floor is not built. On a software project, progress is reported rather than observed, which makes optimistic status easy to sustain and hard to challenge. The requirements are also less constrained by physics, so ambiguity survives longer before something forces it to resolve.

Can a failing project be recovered, or should it be stopped?Both happen, and the deciding factor is usually whether the original business case still holds at the revised cost and date. If it does, recovery is a question of re-establishing the three basics: decision ownership, testable requirements, and evidence-based status. If it does not, continuing is a sunk cost decision dressed as a delivery decision. An independent assessment is worth more than another internal replan, because the people closest to the project cannot see the case objectively by that point.

Conclusion

The reason the same five findings appear in every post-mortem is that the same three gaps appear in every project, and the standard analysis is not built to reach them.

Name your decision owners. Write requirements a stranger can test. Report evidence instead of percentages. None of that is difficult, which is the frustrating part.

If you want an outside read on a programme before it needs recovering, book a free consultation.

‍