Open the slide deck for almost any AI transformation: you have seen it before. There is a maturity assessment. There is a target operating model. There is a projected return built on assumptions nobody will revisit, and a roadmap that runs eighteen months before anyone measures a real result. Swap three nouns and it is the digital transformation deck from 2005. Swap three more and it is the agile transformation deck from 2019.
David Pereira makes the point plainly: most transformations fail, and they fail for predictable reasons. Consultancies did well out of the digital wave. Smaller companies ran Scrum, larger ones ran SAFe, everyone hired, and the results were mostly disappointing. Changing the adjective in front of the word transformation has never changed what comes out the other end.
Why the programme shape fails
A programme front-loads the parts that feel like progress and defers the only part that tells you anything. You spend the first two quarters on diagnosis and architecture. You commit a budget against a business case whose numbers are guesses. Then you integrate for a year before a single workflow runs end to end with real data.
By the time you can measure whether any of it worked, the models you designed around have been replaced twice, the vendor you standardised on has changed its pricing, and the executive who sponsored the business case has moved to another role. Nobody wants to be the person who says the projected return is no longer credible, so the programme keeps moving because stopping it would be an admission. This is how a digital transformation ran for three years and left the company with a new intranet and the same lack of decision-making.
What a loop looks like instead
Mark Ajzenstadt describes the alternative as a loop rather than a programme. You pick one workflow with real users, real data, and an outcome the business already cares about. You prove the smallest useful slice in two to four weeks. You put the evaluation in place before the system exists, because a measurement you build after seeing the results is not a measurement. Then you look at throughput, quality, and economics, and you make one decision: harden it for production and pick the next workflow, or stop and save the budget.
One workflow, one measurement, one decision based on what you actually observed, then the next one.
The smallest useful slice is doing real work for real people, not a demo. Pick a task a team runs weekly, automate the part of it that is well defined, leave the judgement calls with a person, and see whether the throughput, the quality, and the cost per run actually move. If they do, you have earned the right to widen it. If they do not, you have spent a month and a small model bill to learn something true.
It sounds modest next to a transformation office, and that is the point. The loop produces evidence every couple of weeks. The programme produces status updates for a year and a reckoning at the end.
What survives contact with the next model
The loop has a property the programme does not. Everything you build inside one iteration keeps its value when the technology underneath it changes.
The orchestration framework you chose this quarter will be deprecated next quarter, and the model behind it will be superseded before your procurement team has finished onboarding the vendor. None of that matters much if the thing you were really building was the workflow knowledge, the evaluation criteria, and the operating ownership. Those do not expire. They are the durable asset. The tooling is scaffolding you expect to replace.
A failed iteration costs you a month at most, and tells you where the workflow breaks. A failed programme costs you a year at least, a reorganisation, and all chances to try again.
A precondition not on the slides
Methodology is not the main reason the loop wins. AI amplifies the organisation it enters, and a programme gives that amplification eighteen months to compound before anyone checks the result.
If your strategy is clear and your teams trust each other, AI makes a functioning system faster. If your strategy is absent, your priorities change monthly, and your teams compete for the same scope, AI makes that faster too. The technology amplifies the organisation it enters, and I have seen organisations install AI on top of a decision process that already did not work and act surprised when the result was more confident nonsense arriving sooner.
The tools are not the intervention. The intervention is the work leaders have been putting off for years: naming the strategy, resolving the tension the team keeps re-litigating, deciding who owns what. That work is uncomfortable and unglamorous, and it is the first thing a real transformation requires. A budget line for model credits does not substitute for it.
Where to start today
Not with an assessment. Pick one workflow. Choose it because a real team does it often, it has an outcome you can measure, and someone senior would notice if it got better. Write down how you will know it worked before you build anything. Give yourself a month. Measure. Decide. Then do it again.
An AI transformation that skips the foundations is not a transformation. It is the last one you failed, running faster.
Leave a Reply