At the quarterly town hall, the CEO announced an AI programme. A budget, a steering committee, a slide with a timeline reaching into next year. The room nodded and went back to work.
Nobody in that room had named which problem the money was for. Six months later there was a vendor shortlist and a pilot still sitting in a test environment, and the things that actually slowed the business down in January were slowing it down in June.
Two floors below, a shift supervisor could have named one of those things without pausing to think. Every quote sat in review for two days because one person had to sign it by hand, and she had said so in three meetings that year. Nobody holding a budget had been in the room to hear it.
Why we build it this way
Those are the two ways an AI programme fails, and they fail for opposite reasons. A mandate from the top with no named problem buys a demo. The budget exists, so a team gets assembled and a vendor gets chosen, but nobody holding the money knows which day-to-day pain the system is supposed to remove — so the work chases whatever looks impressive in a steering-committee deck instead of whatever is actually broken on the floor.
A problem found on the floor with no mandate from the top buys nothing at all. The supervisor who knows exactly where the two days go has no budget line, no standing to pull in an engineering team, and no cover if the fix touches a process that three departments each think they own. The problem stays named, correctly, in a spreadsheet nobody acts on.
A programme that only has money is building a demo. A fix that only has a problem is writing a memo nobody will fund. We ask for both before we start.
So before any work begins, we ask for two things to be in the same room: a sponsor at the leadership level who has already agreed this is worth paying for, and the business units who can each say, specifically, where their week slows down. We turn down a project if either side is missing. A department's enthusiasm with no budget behind it wastes everyone's time, and a budget with no named problem behind it has no way to tell afterward whether anything worked.
How it works, roughly
Before anything is built, we run a short round with the people who would actually use the system, and bring what comes back of it to the sponsor who holds the budget.
- A list from each business unit of where its week actually slows down — the specific step, who it costs, and how often — not a request for "AI"
- A sponsor at the leadership level who reviews that list and commits budget to two or three of the named problems, never to a general capability
- A written agreement, signed before any building starts, on what "working" means for the first problem chosen
When a business unit's most urgent problem and the sponsor's priority do not match, the two sides meet before any engineering work starts, not after the first review. The sponsor makes the call, in writing, with the business unit's objection recorded alongside it rather than quietly dropped.
A year in, the supervisor two floors down can point to the quote that used to sit for two days and now clears in an afternoon, and the sponsor who signed for it can point to a problem that got fixed — not a programme that is still "underway."
See how we run a programme →