A process improvement framework you can run in six weeks

Most process improvement frameworks are built for programmes with a sponsor, a steering group and a year to run. A team of twenty with one slow process does not need that. It needs a short sequence it can finish before everyone loses interest.

This is the one we use. It has six stages and fits into about six weeks when one person can give it a few hours a week. The stages are not new. What matters is that each one ends with something you can show to somebody.

Stage 1: Pick one process (week 1)

Choose a process that is frequent, visibly painful and owned by someone who will take part. "Customer onboarding" is too wide. "From signed contract to first invoice" is a process. Write one sentence that says where it starts and where it ends, and get the owner to agree to it. If you cannot agree on the boundary, you have just found your first problem.

Stage 2: Measure the baseline (weeks 1 to 2)

Collect three numbers: how many cases per week, how long a case takes from trigger to finish, and how many go back for correction. If you have no data, sample 30 recent cases and read the timestamps in email and your systems. A rough number you trust is more useful than a precise one you do not. We go into this in three numbers every process needs.

Stage 3: Map what really happens (weeks 2 to 3)

Map from observation, not from the procedure document. Ask someone to walk through a real case on screen. Draw every step, every handoff and every loop where work returns to an earlier step. Mark where it waits. A swimlane layout, with one row per role or system, shows handoffs at a glance. You can see typical examples on our process maps page.

Stage 4: Diagnose (week 3 to 4)

Put the baseline numbers on the map. Where does the elapsed time go? Where do cases come back? Which steps add nothing the customer would pay for? The longest wait is usually not where people think. Our guide on finding bottlenecks covers the methods in more detail.

Stage 5: Change, in order (weeks 4 to 5)

Work through the options in this order, and stop as soon as the problem is solved:

1. Eliminate the step.
2. Simplify it.
3. Combine or reorder steps.
4. Name an owner and a time limit for each handoff.
5. Automate what remains.

Automation is last on purpose. If you automate first, you freeze the problems in place. See fix the process before you automate it. Make one change at a time where you can, so you know which one worked.

Stage 6: Hold the gain (week 6 onward)

Improvements decay. People drift back to the old way when the new one is not written down or nobody is looking at the number. Update the procedure, tell everyone who is affected, and put the baseline metrics on a single page that the process owner reviews monthly. If the number slips for two months in a row, treat it as a new problem.

The framework on one page

Stage	Question	Output
Pick	Which process, from where to where?	One-sentence scope, named owner
Measure	How many, how long, how often wrong?	Baseline of three numbers
Map	What really happens?	Swimlane map with loops and waits
Diagnose	Where does the time go?	Ranked list of causes
Change	What is the smallest fix that works?	One or two changes, in place
Hold	Is it staying fixed?	Updated SOP, monthly metric

Where teams get stuck

Scope creep. Halfway through mapping someone says "while we are here, what about approvals for the other department?" Write it on a list and leave it.

No baseline. Without a before number, the after number proves nothing, and the project is judged on opinions.

Too many changes at once. If you change five things and the cycle time halves, you do not know which one to keep when something breaks later.

If you would rather have someone run the first pass with you, that is what our process improvement service is for, and the first review is free.

Related reading and services