An AI operating model, not an AI project portfolio
Pilots are easy and evaporate. What survives is an operating model: how ideas enter, how they are evaluated, who is accountable, and what gets measured after release.
Two years into enterprise AI, the common failure is not technical. Organisations can build the thing. What they cannot do is decide which thing, keep it staffed once the novelty fades, and prove afterwards that it worked.
That is an operating model problem, and it can be designed.
The four moving parts
- Intake — a single ideas bank where anything proposed is tested for desirability, feasibility and viability before it earns a place in a release.
- Sequencing — releases with dates, not programmes with milestones. Every release names the KPI it moves.
- Accountability — one senior owner per release who is present from diagnosis to post-launch measurement, not a rotating cast.
- Compounding — post-release measurement and iteration funded by default, because the second and third iterations are where the returns actually appear.
Why fixed-scope starts work
Open-ended AI budgets create optionality for the vendor and anxiety for the client. A fixed-price first sprint forces both sides to name the outcome and the date. If the value is real, converting into an ongoing relationship is a formality; if it is not, everyone found out cheaply.
“If a programme cannot name the release it is heading for, it is a research project with a delivery budget.”
Measurement that survives the launch party
We run a balanced scorecard monthly: the tangible outcome numbers on one side, relationship and delivery health on the other. It is unglamorous. It is also the only reliable early warning that a programme is drifting, and it makes the difference between an AI capability and an AI anecdote.
