Redesigning the Process

Once the analysis is done, the interventions available fall into a short list, and the cheapest are usually the largest.

Remove the handover

Each handover adds a queue, and the queue usually exceeds the work.

Where two teams each touch a case, ask whether one could do both.

Where a handover exists because of a skill or authority boundary, consider extending the authority rather than moving the case.

Free, and it frequently removes days.

Name the decision owner

Ping-pong between two teams is almost always an ownership ambiguity.

Naming who decides takes one meeting.

Measure the bounce rate before and after, which is a clean comparison.

Move the check upstream

A check that catches errors after effort has been spent is expensive by design.

Validate at entry instead, which prevents the loop rather than detecting it.

Publish the criteria that approvals apply, since rejections frequently fail against criteria nobody stated.

Fix availability rather than capacity

Waiting concentrated at particular hours or days is an availability problem, not a capacity one.

Reshape when the step is staffed, stagger breaks, cover the cut-off hour.

Far cheaper than adding capacity and it addresses a large share of waiting in most processes.

Reduce batching

Work accumulated before processing adds delay with no benefit unless the batch genuinely reduces handling cost.

Halve one batch and measure both sides. Frequently the handling cost does not rise, which means the batch was pure delay.

Route the predictable exceptions differently

Where the analysis identified a subset that will predictably rework, route it to the right path at the start.

This is the strongest finding type available because it prevents the failure rather than handling it.

Absorb the variant

A deviation occurring in a third of cases is not a deviation.

Either make it part of the standard process or prevent it, but stop reporting it as non-compliance.

Documentation that describes a minority of cases is worse than none, because every conformance report is then noise.

Then consider automation

After the process is worth automating, not before.

Automating a step that should be removed locks in the waste.

What to avoid

Redesigning everything at once, which makes the effect unmeasurable.

A target without a mechanism, which is a hope.

Changing the documentation instead of the process, which improves the conformance score and nothing else.

Adding a control in response to a single failure, which is how processes accrete steps until the next analysis finds them.

The free changes, checked first

Five interventions that cost nothing and are available in most processes.

Name the decision owner where cases bounce between teams.

Move a check to entry where a downstream approval keeps rejecting for a knowable reason.

Reshape when a step is staffed, where waiting concentrates at particular hours.

Halve a batch and measure both sides.

Publish the criteria that an approval applies, since rejections frequently fail against unstated ones.

Try all five before proposing anything with a budget, because at least one usually applies and the credibility from a free win funds the rest.

The change that only moves the queue

The most common disappointing result, and it is predictable.

Speeding up a step that was not the constraint produces a larger queue at the constraint and no change in output.

Adding capacity upstream of the bottleneck does the same.

Identify the constraint first, and expect no throughput gain from improving anything else.

Where the change was still worth making — for quality or for the people doing it — say so, and do not claim a cycle time effect it cannot have.

Re-measure after every change, because the constraint will have moved and the previous analysis is stale.

Using the log as the specification

A redesign informed by the discovered process avoids the standard failure.

Design for the variants that exist, not for the one in the documentation.

Count the cases in each variant and decide explicitly which the new design serves and which it routes to an exception path.

Name the exception path rather than pretending there will not be one, because unhandled exceptions are how a new design acquires the old workarounds within a year.

Keep the log definition stable across the change, or you cannot measure whether it helped.

Re-run discovery three months after go-live, which reliably finds the paths the design did not anticipate.