Why we get brought in.
These are five problems we're brought in to prevent, and sometimes to fix. When you address them at the source, through clear and well-evidenced requirements, you’re far less likely to end up paying for them later in operations.
You're focused on low-value use cases.
01
You've got a whole squadron of AI pilots: meeting summarisers, FAQ bots, document-drafting agents. They're eating your change capacity without touching the P&L, and rarely reach beyond the person who built them. When the board asks what your investment achieved, the answer is an awkward 'well, it's made things more convenient'.
How did this happen? The CFO thought it was cost-out, the COO thought it was capacity, the CRO thought it was sandboxed experimentation. Nobody agreed where time, judgement and value sit, so use cases got picked on enthusiasm, demo quality, or the seniority of their sponsor.
The next wave is joining the dots – one client calls it 'going multi-player'. It starts with a shared baseline of where the value really is, which our AI tooling runs in days, not months.
Try this
Ask three members of your leadership team, separately, what your AI programme is for. How many different answers do you get?
You haven't laid
the groundwork.
02
The people your change depends on are resisting it. Usage metrics look fine, but the reality is broken: underwriters re-checking every output, advisers keeping their own spreadsheets. So you're double-paying for the new system and the old way of working. Ouch.
Nobody mapped whose judgement the change would land on, so you designed around your experts rather than with them. Capability was assumed, not tested: 75 engineers on the org chart read as proof the team could work agentically, and when they couldn't, the build stalled in month four.
Laying the groundwork means understanding where your people are, then creating the conditions that move them. That's not to promise everyone carries on as before – some roles change, some open up, some go. What earns trust is clarity, not reassurance.
Try this
Take your most-used AI tool and ask three frontline users what they do with its output. If the answers include 'check' or 'copy and paste', you're not done with the groundwork.
You can't
evidence progress.
03
You can't defend your programme upwards or outwards. Upwards, you can't attribute benefits, so it can't justify itself and dies – not because it failed, but because you couldn't prove it succeeded. Outwards, when a regulator or auditor asks why the system decides the way it does, there's no documented line from business intent to technical behaviour.
There's no baseline before, no value contract during, no auditable trail after. 'We believe it is working' isn't going to cut it. A baseline is the starting point for evidence; a value contract keeps score in terms your CFO accepts; and the requirements trail doubles as the explainable justification of the system's behaviour.
Try this
Pick your most successful AI initiative. Could you prove its benefit to a sceptical CFO using metrics you took beforehand?
You can't articulate your future state.
04
What gets delivered doesn't resemble what was signed off, because BAs and developers need more than a vision to build from. The programme burns change requests re-deciding things the design should have settled, and years later the complaints mount, auditors make 'findings', and nobody can say what the service was originally meant to do.
The future state was a vision, not a specification. A thousand small decisions get made during the build with none of the original context – each reasonable on its own, but they don't hold together. This is where service design earns its place: we turn the vision into requirements detailed enough to sit at the top of the architecture and complete enough for the build team to move quickly, so the awkward questions get answered now rather than downstream.
Try this
Look at your last transformation's design artefacts, then at what got built. Could an outsider trace the line from one to the other?
You're automating yesterday's company.
05
Processing times improve on paper while outcomes and cost barely move. Months after launch, the people this automation was meant to free up get drawn into dealing with the issues it's creating, and private workarounds grow up around the new process.
Nobody explored where time and judgement go, so the programme just digitised the process as the operations manual described it. It was specified for the ideal path – because that's what people describe when you ask how their process works – while the one-in-five cases that take most of your people's time stay outside the system.
A proper discovery exercise exposes the gap between the documented process, the process people think they follow, and daily reality, so the exceptions that matter get written into requirements before build, not tacked on afterwards.
Try this
Sit with your best operator for an hour and count the judgement calls the process description doesn't cover – the exceptions, the workarounds. Each is a decision your build has to make: automate it, or free your people to handle it. Miss them now and they'll re-emerge downstream, expensively.
Five problems, one cause.
None of these is a technology failure. Each is a requirements gap that revealed itself late enough to look like something else.
Settle those requirements early and everything downstream can move at the pace the tools allow, because engineering is no longer guessing at intent.
If you don’t identify them, intent will gradually drift, until the same problems reappear years later as something far more damaging and far more expensive.