Continuous Improvement in Project Management: Kaizen, PDCA and More

What does continuous improvement mean in a project context?

continuous improvement in project management is a key topic in modern project management and teamwork. It means treating the way you run projects as a system that can be improved incrementally, with evidence, by the team that operates it. Not a maturity model, not a certification, not an annual review.

Three properties distinguish it from ordinary firefighting:

It is recurring. Improvement happens on a cadence — weekly, per sprint, per phase — not when something breaks badly enough to trigger a meeting.

It is measured. Each change has a before and after on a specific metric. “The team feels better” is a legitimate outcome but not a measurement.

It is owned by the doers. The people closest to the work propose and test the change. Management’s job is to remove obstacles and protect the time, not to select the improvements.

Improvement work that appears only in strategy decks and never in anyone’s calendar is not improvement; it is intention.

Where do kaizen and PDCA actually come from?

The history is more useful than the mythology, because it explains why the methods look the way they do.

Kaizen (改善) simply means “improvement” in Japanese. The business meaning — continuous improvement of every facet of operations, with participation from the chief executive to the shop floor — was popularised internationally by Masaaki Imai’s 1986 book *Kaizen: The Key to Japan’s Competitive Success*. The practice itself arrived in Japan through American postwar industrial training: the Training Within Industry programme taught small, same-day improvements because wartime production had neither time nor resources for large redesigns. Deming’s teaching and Toyota’s production system built on that foundation.

PDCA has an even less Japanese origin. Walter Shewhart described the specification-production-inspection cycle at Bell Telephone Laboratories in the 1920s. W. Edwards Deming modified it in the 1940s and taught it in Japan during the 1950s, where participants shortened it to plan-do-check-act. Deming himself preferred plan-do-study-act, arguing that “study” captures the intent better than “check”. Toyota later added observation to the front, giving OPDCA, and the lean literature treats the cycle as an exercise in the scientific method rather than a management ritual.

That history matters for one practical reason: the loop is a learning mechanism, not a compliance procedure. If your PDCA is a form that gets filled in, you have the vocabulary and none of the mechanism.

How do kaizen, PDCA, retrospectives and DMAIC differ?

They are four packagings of the same underlying loop, with different scopes and different failure modes.

The practical advice is to stop choosing between them. Use a retrospective as the recurring appointment, PDCA as the structure inside it, kaizen as the permission for anyone to raise a small change, and DMAIC only when the problem is large enough to justify a dedicated team.

How does one PDCA cycle actually run in a project?

Four steps, and the third one is the one teams skip.

Plan. State the problem in measurable terms and a single hypothesis. Not “our reviews are slow”, but “code review takes a median of 4.2 days; we believe the cause is that reviews are batched twice a week; if we move to a daily 30-minute review slot, median time should fall below 2 days within four weeks”. A plan without a predicted number cannot be checked.

Do. Run the change on a limited scope — one team, one project, two sprints. Keep the rest of the system stable so the result is attributable. This is where most improvement efforts overreach: they change four things at once and then cannot say which one worked.

Check. Compare the metric to the prediction. Look for the second-order effects too: review time may fall while defect escape rate rises, which means you moved the problem rather than solving it.

Act. If it worked, standardise it — write it into the definition of done, the checklist, the template. If it did not, record what you learned and try the next hypothesis. Deming’s point was that cycles should spiral: each loop leaves more knowledge than the last.

The act step is what turns an experiment into an improvement. A team that runs experiments but never updates its standards is doing research, not improvement.

What does compounding actually look like?

Small improvements are counter-intuitive because human beings evaluate change linearly and processes compound.

A 1% improvement per week, sustained for 52 weeks, is 1.01 multiplied by itself 52 times — a factor of 1.678, or 68% better a year later. Half a percent per week yields 1.297, about 30% better. Two percent per week yields 2.80, nearly triple.

The same arithmetic runs in reverse, which is why neglect is expensive. A 1% weekly erosion — a slightly longer review, one more approval, one more status meeting — leaves you at 0.59 of your starting performance after a year. Nothing dramatic happened on any single week.

This is the strongest argument against the annual transformation programme. A single 30% improvement delivered once and then allowed to decay is worth less than a boring 1% habit that nobody announces.

Worked example: a twelve-week improvement cycle

A delivery team of eight runs roughly 1,600 project hours a month. Their retrospective identifies rework as the largest waste: work returned for correction after review.

Baseline. Rework consumes 3% of hours — 48 hours a month. At a fully loaded cost of $85 per hour, that is $4,080 a month, or $48,960 a year.

Hypothesis. Rework is concentrated in work handed over without a written acceptance checklist. If every deliverable carries a five-point checklist before review, rework should fall to 1.5% within eight weeks.

Do. Two sprints, one workstream, checklists only — nothing else changes.

Check. After eight weeks rework is 1.6% — 25.6 hours a month, a saving of 22.4 hours. At $85 that is $1,904 a month, or $22,848 annualised.

Act. The checklist becomes part of the definition of done for that workstream. Next cycle: apply it to the second workstream and test whether the same rate holds.

Note what the team did not do. They did not launch a quality programme, appoint a rework tsar, or write a 40-page process document. They changed one behaviour, measured it for eight weeks, and standardised the result. That is a complete improvement cycle, and it fits inside a normal quarter.

Why do large improvement programmes fail where small loops succeed?

Because improvement is a behaviour, and behaviours are learned in small increments.

Initiative fatigue. A team that has survived four transformations in three years treats the fifth as weather. Compliance replaces engagement, and the metrics are gamed to end the programme faster.

No measurement baseline. Programmes often start with a new metric that has no history, so nobody can prove anything changed. Improvement requires a before.

Too many simultaneous changes. Five changes at once makes attribution impossible, so the organisation learns nothing even when performance improves.

No owner for the boring part. Someone must update the template, adjust the checklist, and chase the follow-up. That work is unglamorous and usually unassigned.

Improvement without standardisation. If a better way of working is not written into the standard, the team drifts back within two months. Without a standard there is no baseline to improve from, only variation.

Local optimisation. One team gets faster by pushing work downstream, and the system’s throughput does not move.

How do you run a retrospective that actually changes something?

Most retrospectives fail for a simple reason: they generate more actions than the team can absorb, and none of them have owners.

A workable format, in about 45 minutes:

1. Restate the prime directive. Norm Kerth’s version is the standard: everyone did the best job they could with what they knew, their skills, and the situation at hand. Without this, the session becomes a blame exercise and people stop being honest.
2. Look at data first. Cycle time, defect counts, incidents, carry-over, estimate accuracy. Opinions about a week are unreliable; numbers are shared.
3. Pick one problem. Not five. The one with the largest measured cost, or the one blocking everything else.
4. Form one hypothesis with a predicted number. “If we do X, metric Y should move from A to B within N weeks.”
5. Assign one owner and one check date. A named person and a date in the calendar, not “the team will”.
6. Review the previous action at the start of the next session. This single habit is what separates a functioning retrospective from a monthly ritual.

If the previous action was not done, generate no new one. Find out why the commitment failed — usually the person had no capacity, which is the finding.

Which metrics show that improvement is real?

Choose a small set that reflects flow and quality rather than activity. Five are usually enough:

• Cycle time from ready to done, at the median and the 85th percentile. The median shows typical performance; the tail shows predictability.
• Throughput — items completed per period. Watch it alongside cycle time, because reducing work in progress can cut cycle time without improving throughput.
• Rework rate — the share of effort spent correcting work already done.
• Estimate accuracy — actual divided by estimated, tracked as a distribution rather than an average.
• Escaped defects — problems found after handover, which is the only quality measure the customer feels.

Add one business measure — margin per project, or on-time delivery — because internal metrics can improve while the commercial outcome does not.

Where does continuous improvement go wrong?

Four trade-offs worth naming honestly.

Improvement has a cost. Every hour spent on a retrospective is an hour not spent delivering. The return is real but not immediate, and in a crisis the first thing cut is the loop that would have prevented the crisis.

Metrics get gamed. Any measure used for evaluation stops being a measure. Cycle time falls when items are split into smaller pieces; rework falls when “rework” is redefined. Write definitions down and audit them.

Change fatigue is cumulative. A team can absorb one meaningful behavioural change per cycle. Beyond that, compliance drops even when the changes are good.

Improvement can entrench a bad process. Making an unnecessary approval 20% faster is still an unnecessary approval. Occasionally the right move is to remove the step entirely, which is a design decision rather than an improvement one.

> Practical tip: Keep an improvement log with four columns — change, hypothesis, measured result, standard updated yes or no. In a year it becomes the most credible document your team owns, because it shows what you tried, what worked, and what you deliberately kept.

How do you make improvement stick operationally?

Three requirements: a visible log, a recurring calendar slot, and data that does not need assembling by hand.

The calendar slot is the easiest and the most often skipped. A 45-minute retrospective that exists in the recurring calendar survives a busy quarter; one that is scheduled “when needed” does not.

The data problem is subtler. If measuring cycle time means exporting from a task board, joining to a spreadsheet and manually counting, the improvement loop dies within two months — not from lack of will but from friction. The metrics have to be a by-product of normal work.

That is the layer Doitify covers: Kanban boards with status transitions that give you cycle time automatically, tasks and sub-tasks with owners and due dates, checklists that encode the definition of done, sprints and backlogs, and work and performance reports that show throughput and progress without a manual export. Transparency note: Doitify is our product, and no tool improves a process by itself. It removes the measurement friction; the hypothesis, the discipline and the accountability still come from the team.

What mistakes should you avoid?

• Running a retrospective with no data. It becomes a discussion about feelings and the loudest person’s week.
• Choosing five improvements. Choose one and finish it.
• Skipping the check step. Without a before and after, you cannot distinguish improvement from luck.
• Forgetting to update the standard. If the template, checklist or definition of done is unchanged, the change will decay.
• Measuring activity instead of flow. “Number of meetings held” is not an improvement metric.
• Letting a manager pick the improvement. Ownership is the mechanism; removing it turns the loop into a suggestion box with extra steps.

Conclusion

Continuous improvement in project management is not a programme you launch. It is a habit you schedule: a recurring slot, one problem at a time, a predicted number, a decision, and a standard that gets updated so the gain survives.

The methods are less different than the marketing suggests. Kaizen supplies permission and the insistence on standards; PDCA supplies the experimental structure; retrospectives supply the appointment. What separates teams that improve from teams that talk about it is unglamorous: they write down the hypothesis, measure long enough to know, and change the template when something works.

Start with one metric and one cycle. A team that has completed three real improvement loops in a quarter is stronger than one that has launched a transformation.

If this post on continuous improvement in project management was helpful, you might also enjoy What Are Task Dependencies in Project Management? and How to Plan Your Workday: 5 Steps That Work.