The Five Project Failures That Repeat, and What Actually Fixes Them

Projects fail in a small number of recognisable ways. That is oddly encouraging: a failure mode you can name in advance is one you can build a defence against. What follows is the mechanism behind each of the five most common, and the intervention that works in practice rather than the one that sounds sensible in a post-mortem.

1. Scope creep

The mechanism. Scope rarely expands through one large decision. It expands through a sequence of small requests, each individually reasonable, none of which is ever priced. Because no single addition looks significant, no single addition triggers a conversation about the deadline — and by the time the aggregate is obvious, it is embedded in expectations.

What does not work. A change control process that requires a form. It gets routed around, because the requests genuinely are small and the process is genuinely disproportionate.

What works. Price every request in days, immediately and without judgement, and hand the decision back. "That's about three days, which moves launch to the 19th — do you want it?" This is not obstruction; it is information. Most requests survive this and are worth it. The ones that do not were never worth the deadline slip, and the requester works that out themselves.

2. Estimates that were never going to hold

The mechanism. Estimates are usually produced by the most optimistic available process: asking someone how long a task will take while they are picturing the version where nothing goes wrong. Historical data showing that the last six similar tasks each took 40% longer is available and almost never consulted.

What does not work. Asking people to "be more realistic". Optimism in estimation is close to a cognitive constant; exhortation does not shift it.

What works. Compare against outcomes rather than intuitions. If similar work has historically run 40% over, apply 40% and stop treating it as pessimism. Estimate ranges internally and commit near the top of the range. And decompose anything estimated at more than about a week — large estimates are where optimism compounds invisibly.

3. Resource conflicts nobody saw coming

The mechanism. Two workstreams are planned independently, each perfectly reasonable in isolation, and both assume the same person in the same fortnight. Nothing in a task list makes this visible; it only surfaces when that person is asked to do both.

What does not work. Asking people to flag their own over-allocation. They usually cannot see it either — each request arrived from a different direction and looked fine on its own.

What works. A view that shows assignment against a timeline rather than against a backlog. The conflict is trivially visible the moment both commitments are on the same axis, and invisible in almost every other representation. This is the specific problem a Gantt view solves better than a board, and a good reason to keep one even on teams that work primarily in Kanban — see Gantt vs Kanban for where each view earns its place.

4. Stakeholders who wanted something else

The mechanism. Requirements are gathered at the start, when everyone's understanding is at its weakest, and then treated as settled. The stakeholder's mental model keeps developing. The team's does not, because they are heads-down building against the original brief. The gap only becomes visible at review, by which point it is expensive.

What does not work. More detailed up-front requirements. It makes the artefact more precise without making the underlying understanding more correct, and it increases the sunk cost that makes people reluctant to revisit it.

What works. Short feedback loops against something real. A rough working version at week two surfaces the divergence while it costs a day to fix. Detailed sign-off on a document at week zero surfaces it at week ten.

5. Communication breakdown

The mechanism. Information exists, but not where the person who needs it will look. A decision made in a call is known to four people. A blocker mentioned in a thread scrolls away. The failure is rarely that nobody said anything; it is that saying it and recording it are different acts, and only the first happened.

What does not work. More meetings, and more channels. Both increase the number of places information can be, which makes any given piece harder to find.

What works. Fewer canonical locations, and a rule that a decision is not made until it is written where the plan lives. One current plan beats four accurate conversations, because the plan is still there next Tuesday.

The pattern underneath

Four of these five are the same failure wearing different clothes: a consequence existed but was not visible to the person who could have acted on it. The scope addition had a cost nobody quoted. The over-allocation was real but unrepresented. The requirements gap existed but had no surface to show up on.

Which suggests the general defence is not more process but better visibility — a single current plan that encodes dependencies and assignments, so that a change anywhere shows its consequences everywhere. That is a modest-sounding conclusion, and it is most of the job.