Why we get brought in.
Five problems we are brought in to prevent, and sometimes brought in to fix. Each one gets settled in the requirements, or paid for later in operations.
01You're focused on low-value use cases.
A wall of pilots: meeting summaries, FAQ bots, document drafting. They’re eating your entire change capacity without touching the P&L. Months in, the board asks what it bought, and the honest answer is convenience. The valuable second wave then inherits the scepticism the first wave earned.
Your Exco is aligned on the ambition, not on where to apply it. The CFO thinks it is cost-out, the COO thinks it is capacity, the CRO thinks it is contained experimentation. So use cases get chosen by enthusiasm, ease of demo or seniority of sponsor, because nobody is working from the same baseline of where time, judgement and value actually sit. Guessed value always favours the easy over the important.
A baseline is also an alignment device. Private versions of a programme are hard to hold when the evidence is on one page in front of everyone.
Try this
Ask three SLT members, separately, what your AI programme is for. How many different answers do you get?
02You haven't laid the groundwork.
The people the change depends on are apprehensive rather than excited. Usage figures look fine and reality does not match them: underwriters re-check every output, advisers keep their own spreadsheets, the tool becomes a duplicate step rather than a replacement. So you pay for the system and for the old way of working.
Resistance is not a personality trait of your workforce. It is what happens when nobody mapped whose judgement the change touches, so the people whose expertise it encroaches on were designed around rather than designed with. Capability gets assumed the same way trust does: 300 engineers on the org chart is read as evidence the team can work agentically, and the build stalls in month four with the estimate tripled. And if nobody established what stops, the programme competes with business as usual for the same stretched people. Business as usual wins.
Judgement mapping tells you whose world changes, and on what basis their judgement stays. That’s where enthusiasm comes from, because people can see where they fit rather than fearing they don’t. A readiness assessment answers the capability question with evidence before the route is chosen.
Try this
Take your most-used AI tool and ask three front-line users what they do with its output. If the answer includes the word "check", the groundwork is missing.
03You can't evidence progress.
Two directions. Upwards, benefits cannot be attributed, so at the next funding round the programme cannot defend itself and dies. Not of failure, of unprovability. Outwards, when the regulator or internal audit asks why the system decides what it decides, there is no documented line from business intent to technical behaviour, and a design shortcut becomes a personal problem for whoever holds the accountability.
No baseline before, no value contract during, no auditable trail throughout. If you did not measure it before, you cannot prove it after, and "we believe it is working" satisfies neither the board nor the supervisor.
The baseline is the evidence. A value contract keeps score in terms your CFO accepts, and the requirements trail doubles as the explanation of the system's behaviour.
Try this
Pick your most successful AI initiative. Could you prove its benefit to a sceptical CFO using measurements that predate it?
04You can't articulate your future state.
What ships does not resemble what was signed off, because analysts and developers cannot implement a vision, so the programme burns change requests re-litigating decisions the design was supposed to settle. Years later, wearing a compliance badge: a complaints cluster, an audit finding, redress provisioning, and nobody can reconstruct what the service was originally designed to do.
The future state was a vision, not a specification. Vision decks and experience prototypes gloss over the level of detail where the difficulty actually lives, so delivery makes a thousand small decisions without the context. Each one reasonable. The sum of them wrong. And the hard lines - where judgement carries risk, where a customer must never be wrongly locked out - were never written into the specification at all.
Service design as the requirements specification. Detailed enough to be coded in at the top level of the architecture, complete enough that the build team moves faster with it than without it, and traceable from intent to specification.
Try this
Look at your last transformation's design artefacts, then at what got built. Could a stranger trace one to the other?
05You're automating yesterday's company.
Cycle times improve on paper while outcomes and cost barely move. The demo worked perfectly and the P&L did not notice. Then, three to six months after go-live, the referral queue starts growing, the experienced people the automation was meant to free up get pulled back in to arbitrate, and a shadow manual process grows around the new system. Unbudgeted, unstaffed, untrained.
Nobody baselined where time and judgement actually go, so the programme digitised the process as the operations manual describes it, queues and handoffs and re-keying included. The structure that created the cost is still there, just faster. And the system was specified for the happy path, because the happy path is what people describe when you ask how their process works. The fifth of cases that take most of the effort stayed in people's heads.
A proper baseline exposes the gap between the documented process and the real one, including which workarounds are signal and which are noise. The exceptions get written into the requirements before the build, rather than after the queue proves they exist.
Try this
Ask your best operator what the system could not handle last month. If the answer is a shrug and "the usual", you already have a shadow process.
Five problems, one cause.
None of these is a technology failure. Each is a requirements gap that surfaced late enough to look like something else.
Settle the requirements early and everything downstream can move at the pace the tools allow, because engineering is no longer guessing at intent.
Leave them unsettled and intent drifts a little at a time, quietly, until it surfaces years later as something far more damaging and far more expensive than the decision that caused it.