Lessons from Failed Projects
Projects almost never fail suddenly. They fail slowly, in full view, over months in which several people know something is wrong and none of that knowledge turns into a decision. The interesting question is not what went wrong — it is what happened to the warnings.
In short
- The warnings are usually visible within the first two months. The gap is between noticing and deciding.
- Failure is a chain, not an event. Every link had somewhere it could have been broken.
- The most common structural cause is that raising a problem felt more expensive than absorbing it.
- Recognising these in your own project is worth more than any amount of agreeing with the analysis.
The shape of a failure
The five signs, and why each is ignored
| Warning sign | Why it gets ignored | The cheap intervention |
|---|---|---|
| No named sponsor | Someone senior is nominally attached, so it looks resolved. The gap only appears when a decision is needed. | Ask in week one who decides between date and scope. Escalate if the answer is vague — 2.1 |
| Unknown external lead times | It isn’t your team’s work, so it doesn’t appear in the plan as a task with a duration. | Put every external dependency on the schedule with a real date — 3.2 |
| Unpriced scope growth | Each request is small and refusing feels unhelpful. The total is invisible because nobody adds it up. | A cost line on every change, and a running total — 6.2 |
| A growing review queue | Nobody owns the queue. Everyone’s individual review load looks reasonable. | Track the age of the oldest item in review, weekly — 6.1 |
| Tasks stuck at 90% | The status is technically true and nothing looks alarming week to week. | Count deliverables accepted, not percentages — 6.1 |
Notice that all five interventions are cheap and none is a process. The obstacle is never the difficulty of the fix. It is that acting on the sign requires somebody to say something uncomfortable while the project still looks fine.
A composite: the project that was fine until it wasn’t
The project. A customer-facing portal, twenty weeks, eight people, one integration with an external payments provider. Approved enthusiastically by a director who then took on two other initiatives.
Weeks 1–4. Genuinely good. The team built quickly and demoed early. Nobody wrote exclusions, because the scope “was obvious”. Two small requests arrived and were absorbed — each about a day.
Weeks 5–10. Fourteen more small requests. Status remained green because the tasks that existed were on track; the new work simply appeared as new tasks. The vendor’s security review was scheduled “for when we need it”. Two people privately thought the date was already gone.
Weeks 11–15. The vendor review started and turned out to require an architecture change. The review queue grew because the one person who could approve integration work was also building it. Three items sat at 90% for a month. Status was still green — nobody had escalated.
Week 16. The sponsor, asked for a decision for the first time in four months, was unavailable for two weeks.
Week 18. Declared red. Delivered eleven weeks late, with the payments integration cut. The retrospective concluded that the vendor had been the problem.
That last sentence is the most instructive part. The vendor was a problem, and it was the visible one at the end. The actual failure was that a project with no exclusions, no priced changes, an absent sponsor and no measure other than task status had no way to convert four months of accumulating evidence into a single decision.
The pattern behind the pattern
Look across the five signs and one structural fact keeps appearing: raising the problem was more expensive than absorbing it.
Absorbing a small request costs a day and earns goodwill. Raising it costs an uncomfortable conversation about scope. Saying “the date is gone” in week eight, while everything looks fine, costs credibility if you turn out to be wrong — and nobody thanks you if you turn out to be right, because the project then merely finishes on the revised date.
Which means the single highest-leverage thing anyone can do about project failure is change that calculation. Concretely:
- Respond to early warnings with help, visibly, the first time. The whole team is watching what happens to the first person who raises something.
- Make amber a normal state. If the only two options are “green” and “career event”, everything is green until it isn’t.
- Ask what people are worried about, individually. The information usually exists; it is not in the meeting.
- Never punish an early flag that turned out to be nothing. The occasional false alarm is the price of the true ones arriving on time.
Failures that aren’t this one
For completeness, some projects do fail for other reasons, and it’s worth not over-fitting:
- The problem changed. The market moved, the regulation was withdrawn, the acquirer cancelled it. Not a management failure — and the right response is a clean cancellation, done visibly.
- It was genuinely infeasible. Sometimes the thing could not be built for that money in that time by anyone. The failure is then in initiation — the go decision — rather than in delivery.
- Real bad luck. It exists. It is much rarer than the post-mortems suggest, because it is the most comfortable explanation available and therefore over-selected.
How this looks in AB
All five warning signs are visible in a project’s own data before anyone writes a status report. In AB Projects:
- Unpriced scope growth → tasks created after the baseline was agreed, with no linked change note. Easy to see, rarely looked at.
- Review queue age → how long items have sat in a review state. The single most useful weekly number on this page.
- The 90% problem → tasks whose progress hasn’t moved in three weeks. The change-history tab has the dates.
- Sponsor absence → when they last commented on anything. Uncomfortable and informative.
- External dependencies → whether they exist as dated tasks at all, or only as an assumption in someone’s head.
Five minutes a week checking those is a genuine early-warning system, and it needs no report, no meeting and nobody’s permission.
Terms used on this page
- Watermelon report
- A status that stays green on the outside while the project goes red underneath. The defining artefact of the failure pattern on this page. More →
- Scope creep
- Work added after scope was agreed without a matching change to time or budget. Arrives as small reasonable requests, never as a demand. More →
- Escalation
- Passing a decision to someone with the authority to make it. The mechanism that all five warning signs needed and didn’t get. More →
- Psychological safety
- The shared belief that raising a problem won’t be held against you. The variable that decides whether warnings become decisions. More →
- Leading indicator
- A measure that moves before the outcome does — review age, blocked count, tasks unmoved for weeks. All five signs here are leading indicators. More →
- Hindsight bias
- The tendency to see an outcome as predictable once it is known. Worth resisting when reading this page: at the time, these signs sat among fifty other things. More →
Related reading
8.1 Traits of Successful Projects
The same five variables running the other way, and the two-hour week-one checklist that sets them.
6.3 Reporting Progress
Defining green, amber and red so that amber is a usable state rather than an admission.
3.4 Risk Management
Turning “two people privately thought the date was gone” into a register entry with a trigger.