Implementing a Redesign Without Breaking the Operation

The defining constraint of process redesign is that the process cannot stop. Customers keep arriving, work keeps flowing, and the team is expected to maintain output while the ground moves.

That rules out the approach people naturally reach for, which is to design the new process fully, then switch. Big-bang cutover concentrates all the risk at one moment, and the failure mode is severe: if the new process does not work, you have already dismantled the old one.

What works instead is incremental introduction with the ability to reverse each step. Three properties make that possible.

Each change is small enough to attribute. If three things changed and the result got worse, you cannot tell which caused it, and you will probably revert all three including the one that helped.

Each change is reversible for long enough to matter. The old path stays available until the new one has been observed under real conditions including a busy period.

And each change is measured against the baseline from the first lesson, which is the only reason any of the observations mean anything.

The temptation to move faster is strongest when the redesign looks obviously right on paper. That is precisely when the discipline pays, because obviously right designs fail on details nobody modelled.

The order of introduction affects both the result and whether the effort survives politically.

Start with eliminations. Removing a compensating step by fixing its upstream cause is low-risk, requires no new technology, and produces a visible improvement quickly. It also demonstrates that the analysis was sound, which buys permission for the harder changes.

Then do the constraint. Relieving the step that governs throughput is the change most likely to move the end-to-end number, and doing it early means every subsequent improvement is visible rather than absorbed by the bottleneck.

Then the structural changes: unbatching, collapsing handoffs, relocating review. These affect how people work and need more support.

And introduce AI last, or at least after the above. This ordering is counterintuitive and it is the single most useful recommendation in this lesson. AI introduced into an unfixed process gets blamed for the process's existing problems, and its actual contribution becomes impossible to measure because everything else is moving at the same time.

A team that fixes the form, integrates the systems, raises the approval threshold, and then adds AI can say precisely what AI contributed. A team that does all four at once has one number and no attribution, which is exactly what makes the next investment decision impossible to argue.

The safest introduction runs the new path alongside the old rather than replacing it, and the pattern will be familiar from the AI QA cursus.

In shadow mode, the new path processes real items while the old path remains authoritative. Nothing the new path produces reaches a customer. What you get is real-distribution behaviour with no exposure, and a direct comparison on the same items.

Then a proportion of real volume routes to the new path, chosen deliberately rather than randomly where the risk profile differs by case type. Simple cases first is usually right, since they surface mechanical problems without putting hard cases at risk.

The proportion rises as the comparison holds, with the old path retained until the new one has been through a full cycle including a peak period.

The rollback condition is defined in advance, in the same spirit as the release gate: what result sends volume back to the old path, decided before anyone is invested in the new one working.

Every redesign reports an improvement in the thing it was optimising. The question that determines whether the improvement is real is what moved in the other direction.

Four counterweights to measure alongside the headline.

Quality: rework rate, error rate, and defects found downstream. A faster process producing more errors has moved cost to whoever handles the consequences, and that cost is usually invisible in the redesign's own reporting.

The exception path. Redesigns optimise the common case, and the exceptions often get worse because the new path handles them badly or routes them into an unstaffed queue. Measure elapsed time for exceptions separately, because blending them into an average hides a serious degradation.

Downstream load. A change that speeds up one team by handing partially-finished work to the next has improved a local metric and moved the problem. Ask the receiving team.

And the people doing the work. A process that is faster and more unpleasant produces attrition on a delay, and by the time it shows up nobody attributes it to the redesign.

The practical rule is to report the counterweights in the same document as the gain, always. A redesign summary showing only improvement is not a summary of what happened, and the omission is usually not deliberate, which is why the rule has to be procedural.

The people currently doing the work know things the map does not contain, and they also have the most at stake. Both facts have practical consequences.

They are the best source of design input. They know which exceptions are common, which steps are harder than they look, and which of the redesign's assumptions are wrong. A redesign built without them will contain avoidable errors that surface during implementation at much higher cost.

They are also the people whose jobs change. That is the honest situation, and the managing-teams cursus covers how to handle the conversation. What is specific here: a redesign that removes steps is visibly removing work, and people can do the arithmetic. Pretending otherwise damages the credibility of everything else.

Three things that help.

Involve them in the mapping, not just the consultation. Someone who helped produce the analysis argues with its conclusions rather than with the process.

Be specific about what happens to the time freed. Absorbing more volume, reducing overtime, moving to work that was previously neglected, and reducing headcount are all real answers with very different implications, and saying which one applies is more respectful than leaving it ambiguous.

And give the redesign back to them to run. A process owned by the people in it survives; one imposed on them reverts quietly to the old way within months, usually through the exception path.

Six failure modes, which between them account for most disappointing redesigns.

Automating instead of redesigning. The original reengineering lesson, still the most common error. The process keeps its shape and one step gets faster.

Optimising the wrong thing. Attacking touch time in a process dominated by waiting, or improving a step upstream of the constraint. Both are prevented by the mapping in the first lesson and both happen anyway, because the step people want to automate is rarely the constraint.

No baseline. The change is made, the result feels better, and nobody can say whether it is. This also makes the next redesign harder to fund, because there is no track record.

Too much at once. Several changes in parallel, an unreadable result, and no way to attribute or selectively revert.

The exception path forgotten. The common case improves and the ten percent that are unusual fall into a gap, generating complaints that eventually swamp the gain.

And no owner after go-live. The redesign team disbands, small deviations accumulate unchallenged, and within a year the process has drifted back toward its old shape with the new tooling bolted awkwardly on.

The common structure: four of the six are prevented by measurement discipline, and two by keeping scope small. Neither requires sophistication, and both require someone holding the line when a schedule is tight.

Some processes should be left alone, and recognising them saves considerable effort.

Where volume is low. A process running twice a month does not repay redesign, however inefficient each run is. The arithmetic is unforgiving and frequently ignored because the inefficiency is annoying.

Where the process is about to change anyway. Redesigning around a system being replaced next year produces work that is discarded.

Where the constraint is external. If throughput is governed by how quickly a regulator responds or a supplier delivers, internal redesign moves the queue rather than shortening it.

Where the real problem is demand rather than process. A process struggling because it receives three times the work it is staffed for has a capacity problem wearing a process costume, and redesign will be blamed when it does not fix it.

And where nobody owns the outcome. A cross-functional process with no single owner can be redesigned and cannot be implemented, because every change requires agreement nobody is accountable for reaching. Fix the ownership first, or do not start.

The honest summary of the cursus: map before you change, because the map usually shows the gain is elsewhere. Redesign the shape rather than accelerating a step. Introduce AI after the process is fixed, so you can tell what it contributed. Measure the counterweights. And be willing to conclude that this process was not the one worth changing.