I've been inside enough transformation programs to know the pattern. Ambition at the top, a mandate, a budget. Six months in, everyone's busy and nothing has changed.
It's never one big mistake. It's a pile of smaller ones nobody names until the whole thing is stuck. I keep seeing the same seventeen, and they fall into four groups.
1. Vision and goals that don't guide anything
Most transformations die right here, before they ever start.
The vision exists, but it's aspirational. Not just the town-hall slogan. There's usually a more specific version related to: "modernize the core system, improve customer experience, reduce manual work." Sounds concrete. It isn't. It describes direction, not decisions. Teams can't use it to choose what to build first, what to stop doing, or how to resolve a tradeoff. So everyone interprets it differently, and those interpretations start diverging on day one.
The big picture is missing. Nobody has spelled out what actually changes and what stays the same. This doesn't mean a software architecture diagram, but the real picture: how will roles, responsibilities, processes, and decision-making work differently after this? What does the current state look like versus the target? What's the gap people are expected to cross? Without that, every team fills in their own version and those versions always conflict.
Business goals aren't measurable, so they don't cascade. "Better customer experience" and "more efficient operations" sound like goals but don't behave like ones. In a core system renewal, the business goals should translate into UX KPIs: which journeys need to be smooth, which workflows are the real bottleneck, which capabilities matter more than others. Those KPIs drive the backlog. What gets built first, where you invest and what you accept as good-enough. Without that chain from business goal to measurable target to backlog priority, whoever argues loudest in the room wins, and "everything is important" becomes the operating principle.
No way to tell whether you've arrived. When targets aren't tied to outcomes, the only signal of progress is activity. Meetings are held and deliverables ship. Budgets burn down. But whether the organization actually operates differently? Whether customers notice anything? Whether the thing the transformation was supposed to do is actually happening? Nobody can answer that with evidence. Tracking defaults to budget and timeline. The program "succeeds" because it stayed on schedule. But the question remains, did it really create value?
2. Ownership and organization gaps
No business-side ownership. Tech leads, business second and customer forgotten. IT runs the project, the vendor manages deliverables, and the people who actually understand the business — the ones who'll live with whatever gets built — aren't anywhere near the wheel. This is the single most common structural failure I see.
Project organization assembled before the target is clear. Teams are formed and budgets allocated, before anyone has defined what they're building toward. The structure locks in before the thinking is done.
Documentation is missing or incomplete. Decisions aren't recorded, documentation gets lost in Jira or the documentation process is so heavy people skip it. The next phase can't move forward without rediscovering decisions already made, reverse-engineering logic never written down, re-litigating tradeoffs already resolved. It slows everything down and quietly exhausts the people doing the work.
In core system renewals this compounds fast — testing, operations, support, and the business teams writing actual work instructions all depend on it. When vendors change mid-program (and they do), handover without documentation is painful or impossible. The organization pays for the same knowledge two or three times over.
The organization wasn't involved when it mattered. People hear about the transformation at a town hall. Maybe they join a workshop. But when the actual solution gets designed, they're not invited to the process. Nobody validates or iterates with the people who'll use the result. Resistance later isn't irrational. It's a response to being handed something you never shaped.
Building capabilities in isolation. Each workstream builds its piece. Nobody designs how the pieces connect. This is why operating models matter more than org charts. The connections between parts determine whether the whole thing works.
3. Processes and the customer journey
Processes mapped too late. The new system is half-built before anyone describes how work flows today or should flow tomorrow. Then the gaps between system and reality become everyone's emergency.
No customer journey. The transformation is designed from the inside out. Nobody mapped how the customer actually moves through the organization's services. When the customer journey is missing, you optimize for internal efficiency only. Not for the people who pay.
No clarity on who this is for. Which internal roles will use this? What do they need to get done? Which customer segments does it serve? If nobody has answered these for both sides, you're building something generic that fits nobody well.
No end-user involvement. Frontline staff, customers, operational teams aren't consulted. Their insights show up as bugs and complaints after launch, not as design inputs before it.
4. Execution without line of sight
Subprojects in silos. Each workstream runs on its own. Program management tracks timelines but can't see how the pieces fit. The steering group meets every other week and gets a status parade. Each team reports what they've done. Nobody plans together how the pieces connect. I wrote about the hidden cost of this kind of governance overhead. It's higher than most leaders realize.
Vendors without a shared way of working. Three vendors, three methodologies, three reporting formats. Nobody designed how they coordinate. The integration work lands on the client, who doesn't have capacity for it.
No transparency in what's actually happening. Status reports say green. The work says otherwise. Without demos, prototypes, or visible work-in-progress, leadership runs on narratives instead of evidence.
Waterfall development instead of discovery-first. Large programs still default to waterfall. Months writing prose requirements, months building to spec, then discovering at UAT that the spec was wrong. The alternative has been obvious for twenty years: build a rough concept, demo it to real users, iterate, and only spec the details once the need is validated. With AI tools this loop now happens lot faster. Yet most large organizations still start with a requirements document instead of a prototype. Same mistake startups make when they code first and ask questions later. It just costs more in enterprise transformations, the stakes are higher and every wrong turn takes months to unwind. Concept design fills this gap. Most programs skip it, unfortunately.
The pattern underneath
These seventeen problems share a root cause: business hands the transformation off to IT too early.
Leadership makes the call. "We're renewing the core system." "We're transforming operations." "We're going digital." Then the baton passes to IT, reflexively. A PMO gets stood up, vendors are selected, workstreams launch. All of it before anyone on the business side has designed what actually changes — the target operating model, how roles and decision rights shift, how processes flow across the new setup, how the pieces connect.
The structure gets built on top of a gap. Once the structure is in place, going back to do the design work is nearly impossible. The program is running and budgets are committed. Vendors are billing. So these aren't seventeen separate problems. They're seventeen symptoms of the same missing layer: nobody designed the transformation itself before the project organization started executing it.
This is what transformation design is for. Translating the strategic decision into a concrete target operating model, business capabilities, process design, and decision logic before the project organization locks in around the wrong structure.
Count how many of these seventeen you recognize. If it's more than five, the stall isn't a surprise. It's structural, and it started before the program did.
