Most Transformation Projects Fail Before Launch
The post-mortems blame execution. The truth is that the project was already lost in the planning room — before a single system was built.
I lead the tech and systems side of an internationally awarded agency, and I have watched a lot of transformation projects die. Here is the uncomfortable part: most of them did not die during the build. They died in the planning room, months before launch, while everyone was still optimistic and the budget was still intact.
When these projects collapse, the post-mortem almost always blames execution — the vendor, the timeline, the team. But the failure was usually baked in before anyone wrote a line of code. The launch just made it visible.
Why the conventional wisdom is wrong
The conventional wisdom says transformation is an execution problem: pick good technology, hire a capable team, manage the project well, and you will succeed. So organizations pour their energy into the build phase and treat planning as a formality to get through quickly. That is exactly backwards. The decisions that determine success are made before the build, not during it.
The success criteria were never defined, so nobody could tell whether the project was working until it was too late.
The current process was never honestly mapped, so the new system was built to automate a workflow nobody actually understood.
The people who would use the system were never consulted, so it was designed to solve a problem they did not have.
Leadership approved a scope that was a wish list, not a plan, and the contradictions surfaced only after money was committed.
What is actually true
What is actually true is that transformation is a clarity problem long before it is a technology problem. The hard work is deciding what you are changing, why, for whom, and how you will know it worked. That work is slow, political, and unglamorous, which is exactly why organizations skip it and jump to the part that feels like progress: building something.
A project that starts with a clear problem, honest constraints, and an agreed definition of done can survive a mediocre build. A project that starts vague cannot be rescued by a brilliant one. Industry research has consistently found that the majority of large transformation efforts fail to deliver their intended value — and the common thread is rarely the technology itself. It is the conditions set before the work began.
The signs a project is already lost
You can usually tell a transformation is doomed at kickoff, if you know what to listen for.
Nobody in the room can state the problem in one sentence without using the words "modernize" or "streamline."
The goal is described as "implement the platform" rather than "achieve a specific outcome."
There is no agreement on what success looks like, only on the deadline.
The budget was set before the scope, so the scope will quietly expand until it breaks the budget.
What we see at TTGC
When clients bring us a transformation already in motion and asking why it is stalling, we rarely find a technical failure. We find a planning failure that has been migrating downstream. The team is building competently — they are just building toward a target nobody agreed on. So before we touch a single system, we force the slow conversation: what is the actual problem, who feels it, what does fixed look like, and what are we explicitly not doing. That conversation is uncomfortable, and clients sometimes resent it because it delays the satisfying part. But it is the cheapest insurance a transformation can buy. The projects we have seen succeed were boring at the start and calm at the end. The ones that failed were exciting at the start and chaotic at the end.
The honest take
If you are about to launch a transformation, the most valuable thing you can do is not start yet. Go back to the planning room and check whether you actually agreed on the problem, the outcome, and the definition of done — or whether you just agreed to begin. A project built on a shared, honest answer can absorb a rough build. A project built on a vague one was lost before launch, and the launch will only confirm it. Fix the planning, and you fix most of what would have failed.
Sources
McKinsey & Company — research on the high failure rate of digital transformations and the conditions that predict success. mckinsey.com
TTGC — patterns across client transformation work.
