Why we scope AI projects to one process

The failed rollouts we get called in to fix have one thing in common: they tried to change five workflows at once.

Almost every rescue project we take on started as an ambitious one. A company decided to modernise operations, picked a platform, and scheduled a rollout across procurement, scheduling, customer service and reporting in the same quarter. Six months later nothing is live, everyone is tired, and the word AI has become politically difficult inside the building.

The reason is not technical. When you change one process, you can tell whether it worked. Volume through it, error rate, time per item: those numbers move, and they move for a reason you can name. When you change five, every number moves at once and none of the movement is attributable. Nobody can say which part earned its cost, so the whole thing gets judged on feel, and feel during a rollout is always bad.

There is a second reason, which is that data problems only reveal themselves under load. A schema that looked fine in the scoping workshop turns out to have three years of records where a field was used for something else entirely. On a single-process project this is a two-week detour. Across five, it is a stall in every workstream simultaneously, because the same underlying data feeds all of them.

So we scope one. We pick the process with the highest volume of repetitive human work and the cleanest boundary, ship it, and let it run for a month before discussing the next. The month matters. It is how you find out whether the exception rate you measured in testing survives contact with a real week, including the Friday before a bank holiday.

Clients occasionally read this as a lack of ambition. The opposite is true. Sequencing is what makes the second and third projects cheap: by then we know the data, the systems, the people who actually approve things, and the estimate stops being a guess.