Most transformations fail because they buy technology before naming the operational problem it must solve. If you fund the tool first, you guarantee that failure.
That is the point. The rest of this piece proves it and gives you the gate that stops it.
Picture the budget review a year from now. The money is spent. The pilots ran. The work has not changed. You have to explain why.
In McKinsey’s State of AI 2026, published August 25, 2026, only 37 percent of respondents reported a positive contribution to EBIT from AI. The survey covered 1,719 respondents in 97 countries. That is respondents, not organizations. EBIT contribution is a narrow test. It does not mean the other 63 percent got no return at all. It means most respondents could not point to a positive EBIT contribution.
Use inversion to test your own program. Ask how to guarantee failure, then avoid those moves.
1. Name the problem before you buy the tool
Buy the tool first and every later decision becomes a guess about features. Teams build what the tool can do. They do not build what the work needs.
Name the problem first in one sentence: what operational work must change, and what business outcome must that change produce. If you cannot name it, do not fund the next phase. You are shopping, not transforming. Technology should serve the business outcome, not become the outcome.
The cost of buying first shows up later in rework and low adoption.
2. Sponsor with metrics and resources, not with a name
Symbolic sponsorship guarantees failure. A leader lends a name and attends the launch. The metrics stay the same. Managers are still measured on throughput in the old process. Staff are asked to do new work with old incentives. The transformation loses every time.
Real sponsorship changes what is measured, what is funded, and who is accountable for adoption in their own team. Most organizations do have a change conversation. They improvise it without a system and leave bases uncovered. Adequacy, not absence, is the problem.
If no metric was retired, no budget moved, and no manager was named accountable, sponsorship has not happened yet.
3. Prove capability in real work, not in a course
Treat capability as an afterthought and staff will work around the system. They are asked to work in a new way with no time to learn it, no aid at the moment of use, and no manager to correct early mistakes. Leaders then call that resistance. It is a rational response to being set up to fail.
A workshop creates exposure. It does not create capability. Capability is proven only when a person can do the new work in the real workflow, under real conditions, with a check that the result held. Workforce readiness is not demonstrated by attendance, completion rates, or confidence surveys.
Schedule training late and generic and you guarantee that proof never arrives.
The pattern is the failure
Technology first. Sponsorship in name only. Capability last. Each one alone weakens a program. Together, they guarantee it.
The winners do the opposite. In the same McKinsey survey, about 6 percent of respondents reported a positive EBIT contribution of 5 percent or more. Nearly three quarters of those high performers had redesigned workflows, compared with about one quarter of others. They did not add AI to the old work. They changed the work, who did which part of it, and how the result was checked.
If you only add tools, you will keep producing the same work, faster, at higher cost. Do not confuse a completed implementation with an improved business outcome.
The gate: four questions before you fund the next phase
We do not fund the next phase because the calendar says so. We fund it because four questions have clear answers.
First, Work Allocation. Which parts should a person do, which parts should a system do, and which parts need a person to check the result? If that allocation is not written down, no one can be accountable for it.
Second, Human Accountability. Who is accountable for the outcome in real work, by name? If accountability stays with a program office, it stays abstract.
Third, Capability Assurance. Can the people who must do the new work actually do it, proven in real work? If the only proof is completion, you have no proof.
Fourth, Evidence. What will you measure, how often, and what decision will that evidence trigger? If the evidence cannot stop, redesign, constrain, or pause the program, it is reporting, not governance.
Those four stages, Work Allocation, Human Accountability, Capability Assurance, Evidence, are the decision system. Diagnose first applies before investment and throughout execution, including transformations already underway.
Ask the four questions and record a plain answer to each. What problem must this phase solve, in one sentence? What work changes, who does which part, and who checks it? What proof do you have that people can do that work in real conditions? What evidence would make you stop, redesign, constrain, or pause this phase, and who owns that decision?
Score each answer honestly. A specific answer passes. A general answer fails. One failed answer means redesign or constrain. Two mean pause. Three or four mean stop and re-diagnose. A gate that cannot stop a phase is not a gate. It is a milestone.
The example below is illustrative, not a named case.
A company funds an AI-assisted claims process to reduce rework by cutting handoffs. The system drafts, a person decides, a senior reviewer checks high-value cases. Capability is proven with ten real claims per handler, checked in the workflow. Evidence is set: rework rate and decision time, reviewed weekly, with a pause trigger if rework rises for two weeks. At week three, rework rises. The gate triggers a pause. The team finds incomplete inputs, constrains the rollout to simple claims, fixes the input, and re-proves capability before expanding.
Your next decision
Run the gate test on the next phase before you fund it. Do not run it on the whole program at once. Run it on the next decision. If an answer is vague, do not fund around it. Redesign it until the answer is specific, or pause it.
Proceed only when the four answers are specific. Redesign when one is vague. Constrain when the risk is contained but real. Pause when the evidence is missing. Stop when the problem itself was never named. That discipline is the transformation.
