Why 90% of performance transformations fail before they even begin
I have sat through more transformation kickoffs than I can count, in boardrooms in Quito, Bogotá, Mexico City, Lima, Santiago, and São Paulo.
The setting is always the same: a new program name, a famous framework on slide three, a roadmap full of milestones on slide twelve, and a sincere promise that this time will be different. And very often, eighteen months later, the dashboard is green, the budget is spent, and the way work actually happens has not changed at all.
Studies place the failure rate of major transformation efforts somewhere between 70% and 90%, depending on the study and the definition. The model that inspired this post states it more sharply:
Nine out of ten performance transformations fail before they even begin.
That number is not a condemnation of execution. It states where the cause of death actually lives. It lives upstream, in the foundation that is laid, or never laid, before the first project plan is drawn.
After more than twenty years in product design, solutions architecture, and business development, leading RFI, RFQ, and RFP processes for banks, retailers, and telecoms across Latin America, I have reached the same conclusion from the other side of the table:
Successful transformations start with the right foundation, not the right framework.
The foundation, not the framework
Frameworks are commodities
Kotter’s steps, ADKAR, agile at scale, OKRs, lean portfolios: all are publicly available, and all have succeeded somewhere and failed somewhere else. The framework is not the differentiator.
The foundation is a sequence of six decisions:
- Diagnose the real issue,
- Align leaders first,
- Design the right path,
- Build adoption,
- Sustain the change,
- Realize the results.
Read them as a loop, not as a waterfall, because in practice you will revisit each decision many times. Each one is small, cheap, and unglamorous, and skipping any of them quietly converts a transformation into an expensive rearrangement of the org chart. In the sections that follow
I walk through each decision the way I apply it in real programs and in complex deals, with the field scars to match.
Step 1: diagnose the real issue
Every organization reports symptoms, because symptoms are what dashboards show:
- Low adoption of the digital channel
- Slow credit cycle time
- High cost to serve
- Missed service levels.
Root causes sit below the waterline, like the hidden mass of an iceberg: incentives that reward the old behavior, decision rights nobody can name, structures that force handoffs nobody owns. The discipline of this first step is to refuse to build a roadmap on top of a symptom.
A retail bank once asked me for a redesign of its mobile app because, in the words of a very confident executive, customers did not love it. We paired the analytics with two weeks of conversations: branch staff, call center agents, compliance officers, a handful of real customers. The app was honestly fine.
The bottleneck was an operating model where every release waited for a committee that met twice a month, and a branch incentive scheme that paid for in-person transactions. The issue was organizational, not individual, as it almost always is. A redesign would have taken a year and fixed nothing.
I apply the same discipline in high-stakes procurement
A client’s RFP very often describes a symptom. The vendor that diagnoses the root cause and reflects it in the proposal wins the deal and, more importantly, wins the outcome
Before you design anything, write the diagnosis on one page: the root cause in one sentence, the evidence behind it, and the bottleneck it creates. If you cannot write that sentence, you are not ready to spend money on solutions.
Step 2: align leaders first
The single most cited reason transformations fail is lack of leadership alignment. Not lack of leadership support: on paper, support is everywhere, in signatures, charters, and kickoff photos. Alignment is different, and rarer.
Alignment means the leaders, in private, can state the same why and the same outcomes in the same words, and that they have agreed on what the program will not do. It also means visible commitment:
Leaders spending the scarcest resource they control, their calendar time, on the change.
I have seen a regional program stall for two quarters while two sincere sponsors pulled in opposite directions: one wanted consolidation and control, the other wanted speed to market. Both believed they were sponsoring the same program.
We paused execution and ran a short alignment session that produced a one-page charter: the problem, the outcomes, the non-goals, the single owner, and the cadence of review. The program recovered not because the charter was brilliant, but because it made disagreement visible and then resolved it.
In complex deals, we do this instinctively with the client: before the proposal, we align the evaluation committee on the definition of value, because a divided committee kills even the best offer. Internal transformations deserve the same discipline. If your leaders cannot repeat the why in the same sentence, your teams hear six different messages and hedge six ways.
Step 3: design the right path
A good plan is simple, specific, and outcome-driven, and it is co-created with the people who will execute it. Most transformation roadmaps fail this test in the opposite direction: they are thick, generic, and activity-driven, a portfolio of initiatives that nobody can repeat from memory.
The test I use is brutal and useful: if a manager cannot recite the roadmap’s three high-impact moves in one breath, the roadmap is not a roadmap; it is a filing cabinet.
Co-creation is not politeness; it is engineering.
The people closest to the work know which moves will actually move the metric and which will die in the exceptions. In product work, we formalize this with user story mapping and backlog prioritization: sequence by impact and feasibility, cut the rest, and protect the pipeline from noise.
One team I led reduced customer request resolution time by thirty percent, not by adding people, but by narrowing the pipeline to a small number of high-impact proofs of concept and finishing them properly.
Define the success metrics at this stage, not at the post-mortem
Agree on a short dashboard that carries both leading indicators, like cycle time and adoption, and lagging ones, like revenue, cost, and risk. A roadmap without metrics is a wish list with dates, and wish lists do not survive contact with a fiscal year.
Step 4: build adoption
People do not resist change; they resist uncertainty
That distinction is the whole craft of adoption. What leaders read as resistance is usually anxiety:
- Will I still be good at my job?
- Will my status survive?
- Will I be measured on things I cannot control?
Treat resistance as a design input, not as a character flaw, and adoption stops being a battle and becomes a sequence of practical moves.
Start with early adopters
Every organization has informal leaders, the people others watch before they decide. Recruit them early, let them break the new way of working, equip them to teach their peers, and let credibility travel person to person.
Communicate relentlessly, because the sender’s fatigue is the receiver’s sufficiency: the why needs to be said many times, in many formats, before it lands. And remove barriers fast.
Every obstacle reported and fixed within days is a deposit of trust; every obstacle ignored is a withdrawal. Double data entry, conflicting KPIs, legacy tools left running in parallel: these small frictions kill more transformations than any memo ever will.
This is where my design background pays its dividend
Adoption is a user experience problem, and the users are your own people. Programs that treat employees as customers, map their journey, and remove friction see adoption curves that compound. Programs that rely on mandates see compliance until the mandate is lifted, and then reversion.
Step 5: sustain the change
The applause of launch is the most dangerous moment of a transformation, because it feels like the finish line and it is actually the starting line. Old habits are not deleted; they are only overwritten, and they return under pressure: quarter close, audit season, a production incident. The fifth decision is to plan for that pressure in advance, and to make the new way the only way.
Sustaining is three practices done consistently.
- Reinforce new behaviors by changing the systems that produce the old ones: incentives, permissions, defaults, access. When the old path stays open, people will find it on the worst day of the quarter.
- Track progress on a steady cadence, the same rhythm that keeps a multi-year deal healthy: a short weekly check, a monthly review, a quarterly target conversation with regional and industry leaders. What gets measured gets improved, and the keyword is consistently, not intensely.
- Recognize wins publicly, rewarding the behaviors that produce results, not only the results themselves: the team that logs every case correctly deserves the same applause as the team that closes the quarter.
A transformation that survives its first pressure cycle is a transformation that survives. Everything before that is rehearsal.
Step 6: realize the results
Results create belief, and belief creates momentum
Yet many programs never actually harvest their results: the numbers live in a consultant’s appendix, the victory is declared on anecdotes, and the organization never receives the one asset that makes the next change cheaper, which is proof.
Measure the business impact in the same language used in the diagnosis: cycle time, adoption, revenue, cost, risk. Publish the numbers even when they are imperfect, especially when they are imperfect, because honesty about gaps is what makes the wins credible.
Then capture the lessons, including the failures
A lessons-learned session that produces only successes is a theater session. The most valuable lines are the ones that say we were wrong about this, and this is what we now know. Finally, scale what works: package the playbook, staff the next wave, and move from pilot to enterprise with the same discipline you used to move from diagnosis to pilot.
Some of the best years of my career came from this compounding: a proof of concept in one country became a playbook, the playbook became a regional rollout, and the regional rollout became a multi-year contract. Momentum is not a feeling. It is an asset, and it is built by closing loops.
A six-question gate review before you spend on execution
The model ends with a checklist, and I use it as a gate review before significant spend, and again monthly after that. Six questions:
- Have we validated the real problem below the waterline?
- Are the leaders aligned and visibly committed, in private and in public?
- Do we have a simple roadmap with clear metrics that anyone can repeat
- Is the adoption plan in motion, with early adopters recruited and barriers being removed?
- Do we track and reinforce progress on a steady cadence?
- Do we measure impact, capture lessons, and adapt?
If any answer is no, the foundation is cracked, and money poured on execution will pour out through the crack. Fix the foundation first. It is always cheaper now than later, and “later” has a way of arriving during an audit.
Closing thoughts
Frameworks will keep changing, and that is fine. The foundation will not change, because it is built on human constants: people need to understand the real problem, see their leaders aligned, know the path, feel certainty instead of fear, see progress measured fairly, and watch results become belief.
That is why this model will still hold when you read it years from now, in any market, in any industry, whether you are rolling out a digital banking platform, reworking an operating model, or answering a high-stakes RFP. The framework is the easy part. The foundation is the work. Do the work.
Web references and further reading
Web references:
- Harvard Business Review, “Leading change: why transformation efforts fail“, by John P. Kotter. The original article on why transformation programs die, and the seed of the eight-step method.
- Kotter International, “The 8-step process for leading change“. The public, current version of the methodology.
- Prosci, “The ADKAR model“. A research-based view of individual change: awareness, desire, knowledge, ability, reinforcement.
- McKinsey & Company, “Perspectives on transformation” and “Common pitfalls in transformations“. A sober look at the seventy percent failure rate and the pitfalls behind it.
Books that reinforce this post:
- “Leading change”, by John P. Kotter.
- “The heart of change”, by John P. Kotter and Dan S. Cohen.
- “Our iceberg is melting”, by John P. Kotter and Holger Rathgeber.
- “Switch: how to change things when change is hard”, by Chip Heath and Dan Heath.
- “Good strategy bad strategy”, by Richard Rumelt.
- “Measure what matters”, by John Doerr.
- “Atomic habits”, by James Clear.
