Key takeaways
- Projects fail because they were built against what managers described, not what staff actually do.
- Ship a usable slice within six to eight weeks. Feedback from real use is worth more than any amount of upfront specification.
- Reserve budget for post-launch correction. Every system surfaces problems under real use that testing did not catch.
- A single unnamed decision-maker who was never in the room is the most common cause of late-stage rework.
Across roughly 100 delivered projects, the ones that went wrong almost never went wrong for technical reasons. The technology was rarely the hard part.
Five failure modes account for most of it, and all five are visible before a line of code is written.
1. Built against what managers described
The most common cause, by a wide margin.
Requirements get gathered in meetings with the people who own the budget. Those people describe the process as it is supposed to work. The staff who actually perform it every day have, over the years, developed workarounds, exceptions, and shortcuts that never made it into any documentation — usually for good reasons.
The system gets built against the described process. It ships. Staff discover it does not accommodate the way the work actually happens. They keep using the spreadsheet. The system is quietly abandoned while everyone reports that it was delivered.
The prevention is unglamorous: sit with the people doing the work and watch them do it, before designing anything. One or two weeks of observation reveals things no requirements meeting produces. Every project where I have done this has surfaced at least one rule that would have broken the build.
2. The decision-maker who was never in the room
A project runs for three months with a project team. Then it reaches someone senior who was not involved, who has a fundamental objection to an assumption made in week one.
This is not unreasonable of them. It is a failure of who was invited.
The prevention: identify, in writing, every person who can veto or materially change the project. Get them into the scoping conversation, even briefly. If someone cannot spare an hour at the start, that is useful information about how the project will go.
3. Scope agreed once and never revisited
Requirements are fixed in month one. The build runs nine months. The business changes during those nine months, because businesses do.
The system ships against requirements that were accurate a year ago, and everyone is disappointed by something that was delivered exactly as specified.
The prevention: ship something usable within six to eight weeks, even if it covers only one workflow for one user role. Real feedback from real use reshapes the remaining scope while changing it is still cheap. A specification is a prediction; a working slice is evidence.
4. Launch treated as the finish line
The budget covers building. Nothing remains for what happens after.
But every system surfaces problems under real use that no testing regime catches — the edge case that appears when a user does something nobody anticipated, the performance issue that only shows at real data volumes, the workflow step that turns out to need one more field.
If there is no budget left, those go unfixed. The system works for the straightforward cases and fails at the edges, and users lose confidence in it.
The prevention: reserve budget explicitly for post-launch correction, and treat it as part of delivery rather than as a contingency. A proposal that includes it is more honest than one that assumes it will not be needed.
5. Nobody owns it afterwards
The vendor hands over. The internal champion who drove the project moves to another role. Six months later nobody knows how it works, nobody is applying updates, and the documentation — if it exists — was written for someone who already understood the system.
The prevention: two things. Documentation written for a developer who was not involved in the build, and deliberately unexciting technology choices. Clever architecture that only its author understands is a liability the moment it is handed over. Mainstream frameworks and standard patterns mean the next person can pick it up.
What actually correlates with success
Looking at what separated the projects that landed from the ones that struggled, three habits did most of the work:
Watching before designing. One to two weeks observing the current process. It consistently changes the design, and it always costs less than discovering the same thing in month five.
A usable slice early. One complete workflow in front of real users within six to eight weeks. It converts assumptions into evidence at the point where acting on evidence is still cheap.
Budget reserved for correction. Not contingency for overruns — specific budget for the fixes that only real usage reveals.
None of that is a methodology. It is three habits, and they are why a 92 percent on-time rate was achievable across that volume of work.
The uncomfortable question worth asking
Before starting any digital project, ask what happens if you do nothing.
Sometimes the honest answer is that the current process is inefficient but workable, and the money would produce more return somewhere else entirely. That is a legitimate outcome of a scoping conversation, and a consultant who never reaches it is not evaluating, they are selling.
The most valuable recommendation I give is fairly often do not build this. It is also the one that costs me the most to give, which is precisely why it is worth having from someone with no product to resell.
Questions
Should we insist on a fixed price?
Fixed price transfers risk to the vendor, who prices that risk in and then defends the scope line rigidly. It works well for genuinely well-defined work. For anything exploratory it produces an adversarial relationship where every discovery becomes a negotiation, which is not where you want to be in month three.
Can a failing project be rescued?
Often, and more cheaply than restarting. The first step is an independent assessment of what exists — code review, architecture, and whether what was delivered matches what was contracted. Sometimes the build is sound and the process broke down, which is a much easier problem than it feels from inside.
