A Continuous Improvement Process Example, Worked End to End
Key takeaways
- A continuous improvement process targets the constraint that caps system throughput, not the step that merely looks busiest.
- PDCA cycles are only falsifiable when the Plan stage states a predicted system-level effect on cycle time, WIP, and throughput.
- Check improvements by measuring the whole workflow, because a step's utilisation dropping can coincide with faster total delivery.
- Standardise gains as one-page standard work with explicit WIP limits, then re-baseline weekly before treating new numbers as the floor.
- The constraint migrates after each fix, so re-measure demand versus capacity per step before scoping the next cycle.
Most continuous improvement process examples stop at a generic list, so this one follows a single small design studio's client-delivery workflow through every PDCA step, from finding the constraint to standardising the fix. You get before/after cycle times, WIP, and throughput at each stage, so you can judge whether the method holds up before applying it to a client engagement.
What is a continuous improvement process?
A continuous improvement process is a repeatable loop: find the constraint that caps throughput, change one thing about it, check whether system-level output actually moved, then standardise the change and run the cycle again. It is not a brainstorm of unrelated fixes. If an improvement upstream of the constraint does not raise total throughput, it was not an improvement. The backbone of most cycles is PDCA: Plan the change, Do it small, Check the effect, Act on what you learned, as defined by ASQ's overview of the Plan-Do-Check-Act cycle. The rest of this article traces one full cycle through a small design studio's client-delivery workflow, with before/after cycle times, WIP and throughput at each stage. You can scope a cycle like this yourself with a tool such as Improve First before quoting the deeper engagement.
What does a full continuous improvement process example look like step by step?
The rest of this article traces one worked example end to end: a three-person design studio delivering client work. The same workflow carries through every stage, so you can see the numbers move rather than follow an abstract framework.
The workflow before any improvement
Brief arrives, designer drafts, founder reviews, revisions loop, files ship. Current state: average lead time of 9 working days per project, WIP of 5 projects in flight, throughput of 2.5 projects per week. The constraint sits with the founder's review step, not the drafting.
Each later section picks up this example at a different stage:
| Stage | Question answered | Example moment |
|---|---|---|
| Identify the constraint | Where is the bottleneck? | Founder review caps weekly output |
| Plan-Do-Check-Act | What changes and how do we verify? | Checklist cuts review cycle time |
| Standardise | How does it stick? | Review becomes a written routine |
| Next cycle | When do we run again? | Constraint moves to drafting |
The structure mirrors the worked capacity example at https://improvefirst.com/examples/recruitment-process-capacity, applied here to a service workflow instead of hiring.
How do you identify the constraint before improving a process?
Calculating demand and capacity per step
Take the worked example: a three-person design studio delivering client work through brief (2 days/week capacity, 3 days demanded), design (5 days capacity, 5 days demanded), and review (4 days capacity, 2 days demanded). Demand vs capacity per step shows design is the constraint: it can absorb exactly the work arriving, while brief and review each hold roughly two days of slack. Throughput is capped at five design-days per week no matter what the other steps do.
Why the obvious fix targets the wrong step
The studio's instinct is to speed up the brief stage, because that is where clients wait. But shortening a non-constraint adds nothing to total throughput; the work simply queues in front of design longer. This is the core insight of the Theory of Constraints, and of kaizen as continuous improvement centred on the whole system rather than local fixes, as the Lean Enterprise Institute's kaizen definition puts it. Before quoting an engagement, scope which step actually limits output. The Constraint Impact Calculator runs this demand-vs-capacity comparison and predicts where the constraint moves once design improves.
What does Plan-Do-Check-Act look like applied to one real workflow?
Plan: define the problem and the expected system effect. The studio's constraint sits in client sign-off: briefs average 9 days from draft to approval, WIP piles up at 14 open briefs, and total throughput is 6 projects per month. The plan states a prediction in system terms: move the designer's review pass before the client handoff and sign-off should drop to 6 days, cutting WIP to roughly 9 briefs and lifting throughput toward 8 projects per month. A prediction written this way makes the cycle falsifiable. The Constraint Impact Calculator exists for exactly this scoping moment: it shows which step limits total output and where the constraint is likely to move once the current one is relieved, so you quote the engagement against a stated system effect rather than a hunch.
Do: run the change on one client stream. The consultant applies the new review sequence to a single retainer client for two weeks, leaving all other briefs on the old path. One stream keeps the comparison clean and caps the cost of being wrong.
Check: measure throughput, not local utilisation. The sign-off step now shows 85% utilisation instead of 98%, which looks worse locally. But system numbers tell the real story: cycle time falls from 9 to 6.5 days, WIP drops from 14 to 10 briefs, and monthly throughput rises from 6 to 7.5 projects. This is the trap most clients fall into, and it is worth spelling out in full. A step running at 98% utilisation feels productive because everyone at that step is busy all day, yet a constraint loaded to capacity converts every upstream hiccup into queue time, so the work sits invisible in a backlog nobody owns.
Measuring the step in isolation rewards the team for keeping the bottleneck saturated, while the client waits longer and the studio invoices less. Only system-level numbers, throughput and total WIP, reveal whether a change helped or merely moved the queue somewhere harder to see. That is why the Check stage measures the whole workflow, never the improved step alone.
Act: adopt, adapt or abandon. The prediction mostly held, so the change is adopted for all client streams and written into the studio's standard brief checklist. The residual gap against the 8-project forecast becomes the input for the next cycle.
How does the Japanese kaizen approach shape continuous improvement lean methods?
Kaizen means continuous improvement through many small, frontline-led changes rather than one large project. In the design studio example, that difference shows up concretely: instead of buying new software or hiring, the studio shortened review cycles by ten minutes per brief and capped WIP at two jobs per designer. Throughput rose because the constraint, the single senior reviewer, gained capacity, which is the Theory of Constraints logic that a system's output is set by its tightest constraint, not by total resource utilization.
Kaizen also changes who runs the cycle. The designers who felt the backlog daily proposed the change; the consultant facilitated rather than delivered it. For scoping, that means your engagement can start small and cheap: run the numbers on a calculator like Improve First's process capacity calculator, test one frontline suggestion, and let results justify the deeper work.
How do you standardize and sustain an improvement after the first cycle?
An improvement that lives only in the consultant's head dies the week the invoice is paid. In the studio example, the gain came from capping WIP at the review stage, so that cap has to outlive the engagement.
Writing the new standard work
Keep it to one page per role: what triggers the work, the WIP limit, the cycle time target, and what to do when demand exceeds capacity. The studio's designer gets a one-pager saying reviews queue behind a two-job limit, nothing more. If a step needs a paragraph to explain, it has not been simplified enough.
What to re-measure and how often
Re-baseline the same three numbers you used to diagnose: cycle time, WIP, and throughput. Check weekly for the first month, then monthly. When throughput holds at the new level for four consecutive weeks, treat it as the new baseline and start hunting the next constraint, which in the studio's case had already shifted from review to client feedback.
When should you run another continuous improvement cycle instead of stopping?
Run the next cycle when throughput at the new constraint drops below demand, or when WIP starts piling up in front of a different step. After one fix, the constraint rarely stays put; it migrates to whatever step now has the least capacity relative to takt time, the customer-demand rhythm that sets the pace of output (Lean Enterprise Institute glossary). If system capacity now meets or exceeds demand with stable lead time, stop and monitor instead.
Where the constraint moved in the worked example
In the studio example, fixing the review bottleneck pushed the constraint downstream to client feedback, where WIP sat waiting. Cycle time improved at review, but throughput didn't, because the limiting step had changed.
Scoping the next cycle before quoting the engagement
That migration is the signal to scope cycle two. Measure where the backlog forms now, confirm it holds across two weeks of data, and quote against that step rather than the one you already fixed.
Which tools help you scope a continuous improvement cycle?
For a scoping pass, most consultants reach for a spreadsheet capacity model. It is free, flexible, and the client already has it. The trade-off: you build the takt time, WIP and utilisation logic yourself, and the client cannot rerun it after you leave.
Purpose-built options exist. DO.Impact, ProcessModel and FlowVisual all model process flow, though each carries a learning curve and a licence cost before you know whether the engagement is worth quoting. KaiNexus sits adjacent; it manages improvement work rather than sizing the constraint.
Improve First's Constraint Impact Calculator takes the narrower brief: identify the bottleneck, test whether a fix moves system throughput, and predict where the constraint shifts next. Its honest shortcomings: it handles a single constraint chain, not the multi-resource scheduling problem in the forum thread above, and it will not produce the simulation depth of ProcessModel. Use it to scope, then quote the deeper work.
FAQ
What are some continuous process improvement examples for small service businesses?
A three-person design studio is a clean case: briefs took 9 working days, WIP sat at 14 open projects, and throughput was 6 projects per month. Moving the designer's review pass ahead of client handoff cut cycle time to 6.5 days and lifted throughput to 7.5 projects per month. The same loop applies to agencies, consultancies, and any workflow with a queue.
Is PDCA the same as kaizen, or are they different continuous improvement processes?
They are different layers. PDCA is the loop structure: plan a change, run it small, check system-level results, then adopt, adapt, or abandon. Kaizen is the philosophy of many small, frontline-led changes rather than one large project. In the studio example, the designers themselves proposed shortening review cycles by ten minutes per brief, with the consultant facilitating rather than delivering.
How long should one continuous improvement cycle take?
Long enough to gather honest before/after data, short enough to stay cheap. The worked example ran the change on a single retainer client for two weeks, then checked weekly for a month before treating the new throughput level as the baseline. If four consecutive weeks hold steady, close the cycle and start hunting the next constraint.
How do you measure whether an improvement actually worked?
Measure the whole workflow, never the improved step alone. Track cycle time, WIP, and total throughput against a written prediction made during planning. In the example, the review step's utilisation dropped from 98% to 85%, which looks worse locally, but system cycle time fell from 9 to 6.5 days and monthly throughput rose from 6 to 7.5 projects.
Can I run a continuous improvement process without expensive software?
Yes. A spreadsheet capacity model comparing demand against capacity per step is free, flexible, and already on the client's machine. Purpose-built tools like ProcessModel or Improve First's Constraint Impact Calculator speed up scoping, but the method itself needs only three numbers per step: cycle time, WIP, and throughput. Buy software after results justify the engagement.