Kaizen for Project Managers: Small Fixes That Add Up

Key takeaways

Kaizen is a Japanese word for "change for the better," and in practice it means many small improvements, made by the people who do the work, every week, instead of one big reorganization every few years.
A project manager's version is simple: run one small improvement at a time with a one-page card that names the problem with a number, finds the root cause with five whys, tries one change, and checks the result on a date.
Improve the process, not the person. The moment a name appears next to a failure, people stop telling you what really happens.
Go and see. An hour standing where the work is done (the Japanese term is gemba) gives you more truth than a week of reports.
Small does not mean trivial. A two-minute fix that saves ten people two minutes a day returns about 80 hours a year, and a team that sees one fix land believes in the next.

A project manager walks into a meeting and announces a Big Transformation. There is a slide with a rocket on it. Everyone nods, the way people nod when a flight attendant explains the seat belt. Six weeks later the rocket is still on the slide, the old way of working has quietly won, and the only thing that changed is that people now sigh when they hear the word "transformation."

Now picture a different Tuesday. A site coordinator mentions that the daily safety forms are in a binder on the far side of the trailer, so people fill them in at the end of the day from memory. Someone moves the binder to the door. It takes forty seconds. The next morning the forms are filled in when they should be, and nobody has had to give a speech about it.

The second Tuesday is kaizen, and it is one of the most useful ideas a project manager can borrow. This article explains what it is (and what it is not), how it fits inside a project instead of competing with it, and gives you a one-page method and a card builder you can use on Monday.

What kaizen actually means

Kai means change and zen means good, so kaizen is "change for the better." In business the word came out of Japanese manufacturing after the Second World War, and it is most closely tied to Toyota's way of working, where workers on the line were expected to notice problems and fix them continuously. The idea spread through the lean movement, and it now shows up in hospitals, software teams, restaurants, offices and construction sites.

Two features separate kaizen from a normal improvement project:

It is continuous. There is no "improvement phase" that ends. Each week, someone looks at one small thing and makes it a little better. The gains compound, quietly, like interest.
It belongs to the people who do the work. The person who fills in the form every day knows exactly why it is annoying. A consultant (yes, even this one) can help them see it, but the person at the work is the expert on the work.

It is often contrasted with kaikaku, a radical redesign, the "tear it down and rebuild" kind of change. Both have a place. If a process is fundamentally broken, you redesign it. But most processes are not fundamentally broken. They are full of small frictions: a missing field, a wait for a signature, a file nobody can find. Those frictions are kaizen's natural habitat.

Why a project manager should care

At first glance kaizen and project management look like opposites. A project has an end date; kaizen never ends. A project delivers a defined result; kaizen is unlimited. Look closer and they fit together very well, in four places.

1. Inside the project, on how the team works. Your kickoff is the start of a small system: how decisions get made, how changes get approved, how the weekly report is produced. Some of that will be clumsy at first. A weekly 15-minute improvement slot lets the team fix the clumsy parts while the project is still running, which is when the fix pays back.

2. Between projects, as the engine behind lessons learned. A lessons learned session produces a list of things to change. Kaizen is the habit that makes the list real. Without it, the lessons are filed with the other documents nobody opens.

3. In the product or building you deliver. Construction crews and factories have used it for decades to remove rework: a poka-yoke (a "mistake-proofing" device, such as a bolt that cannot be fitted backwards) is kaizen in steel. The same goes for the checks in project management in construction: each inspection is a place where a small check stops a large repair.

4. In your own practice. A good project manager is a chronic improver of their own templates: the status report that got shorter, the kickoff agenda that got sharper. The status report guide is the result of that kind of loop.

A tidy workshop pegboard where every hand tool hangs in its own painted outline, one outline empty — The painted outline is a tiny kaizen: you notice the missing tool in two seconds, without asking anyone.

The plain-English toolbox

Kaizen comes with a long vocabulary that can make it sound like a martial art. You need only a handful of ideas, and each one has a plain name.

PDCA: the loop under everything

PDCA stands for Plan, Do, Check, Act, and it is sometimes called the Deming cycle, after the quality expert W. Edwards Deming, who popularized it. It is a tiny experiment:

Plan: name the problem, guess the cause, decide what to try and how you will tell if it worked.
Do: try it, on a small scale, for a short time.
Check: compare what happened with what you expected.
Act: keep it, change it or drop it. Then start the next loop.

Notice that the "Check" step is what most real-life improvements skip. People fix something, feel good and never find out whether the fix did anything. The card at the end of this article puts the check date on paper for that reason.

Gemba: go and see

Gemba means "the real place," the place where the work happens. The advice is simple and very hard to follow: before you decide what is wrong, go and watch the work. A project manager who has never seen how the daily forms are really filled out will write a policy about forms. One who has seen it will move the binder.

A gemba walk is just a regular, unhurried visit to where the work is done, with one rule: you ask questions and you do not fix anything on the spot. Go to see, to ask and to learn. It is the cheapest source of improvement ideas ever invented, and it has a side effect: people notice that someone cares enough to look.

The five whys

When something goes wrong, the first answer is almost never the cause. The five whys is a way to keep asking until you reach something you can change. A quick example, illustrative as always:

The inspection failed. Why? Because the rebar spacing was wrong.
Why was the spacing wrong? Because the crew worked from an old drawing.
Why an old drawing? Because the new revision was sitting in the project manager's inbox.
Why was it sitting there? Because the drawings are emailed to one person, who forwards them when he remembers.
Why does it depend on remembering? Because nobody ever decided who distributes drawings, or how.

You can fix the fifth answer (name an owner, post the current set in one place, mark the old ones). You cannot fix the first one, except by shouting at the crew, which is a popular choice and a useless one. Do not worry about reaching exactly five. The point is to go past the first answer, and to stop at a cause you control.

The eight wastes

Lean thinking, which grew out of the same Toyota roots, names wastes that hide in all work. The standard list has eight, and they are easy to remember with the acronym DOWNTIME:

Defects: doing it again. Rework, corrected drawings, resubmitted reports.
Overproduction: making more than needed. Reports nobody reads, features nobody asked for.
Waiting: idle time. Waiting for an approval, a delivery or a decision.
Non-utilized talent: not using people's ideas. Skilled people who only execute instructions.
Transport: moving things around. Files passed through six inboxes.
Inventory: piling up unfinished work. Ten tasks started, none finished.
Motion: extra movement. Searching for a file, walking to the trailer for a form.
Extra processing: more work than the customer values. Three approvals for a $50 purchase.

If you want to see waste on your project, start with waiting and inventory. They are everywhere, and they connect directly to the theory of constraints and to kanban's work-in-progress limits: finish before you start more.

The A3 and the kaizen card

Toyota popularized a one-page problem-solving report, called an A3 after the paper size. It holds the whole story on a single sheet: the problem, the current state, the root cause, the countermeasure, the plan and the follow-up. The discipline of one page forces clear thinking. For a small team, a lighter "kaizen card" does the same job in six lines, and that is what the tool below produces.

A kaizen cycle in six steps

Here is the method I would run on a real project. It fits in a 30-minute slot once a week.

Step 1: Pick one irritation. Ask the team: "What is one thing that wasted your time this week?" Write all the answers on sticky notes. Do not debate. Then choose one, using two questions: does it hurt often, and can we fix it ourselves? A frequent, fixable problem is the sweet spot.

Step 2: Put a number on it. "People waste time on forms" is a complaint. "Eleven forms were filled in late last week, each costing 15 minutes of rework" is a problem. If you cannot find a number, estimate one and say it is an estimate. A rough number is enough, because you only need to know later whether it moved.

Step 3: Find the root cause. Use the five whys with the people who do the work. Ask what, not who. Stop when you reach a cause that your team can change.

Step 4: Pick the smallest change that could work. Resist the grand solution. If the cause is "nobody owns the drawings," the smallest change is a name and a folder, not a document management system. You can buy the system later if the folder proves too small.

Step 5: Try it for a short time. Two weeks is typical. Tell everyone it is an experiment, which is both true and a relief, because nobody has to defend it.

Step 6: Check on the date, then keep, change or drop. On the date you wrote down, look at the number again. Better? Make it the new standard and tell the team. No change? Good news too: you learned the cause was not what you thought, and you did it cheaply.

A project manager in a hard hat and safety vest standing quietly at the edge of a busy building site, watching the crew work and holding a small blank notebook — A gemba walk is mostly watching and asking. The notebook stays in your hand, and your opinions stay in your pocket.

Examples from very different places

All of these are illustrative, built from typical situations, and none refers to a real client.

A construction site. The superintendent notices that the daily huddle starts late because the foreman for the concrete crew has to find the pour schedule. Fix: a laminated one-page pour schedule at the gate. Time saved: about ten minutes a day, for twelve people, which is two hours a day.
A restaurant opening. During the restaurant opening trial services, the cooks walk across the kitchen to fetch the same four tools at every order. Fix: a second set at the station. Cost: forty dollars. Result: the longest ticket time dropped by about a minute.
A small consulting practice. Proposals take three days because the pricing is rebuilt from scratch each time. Fix: a one-page template with the three standard options. Result: proposals go out within a day, which matters because speed is one of the few things a small firm fully controls (see the first ninety days in how to start a consulting business).
An office. The weekly status report takes two hours to assemble from five sources. Fix: one shared sheet that people update on Thursday. The report takes fifteen minutes. The weekly status report can also be automated, but you should simplify before you automate.
A clinic. Patients wait at the front desk while forms are checked. Fix: send the form the day before. Waiting time is cut, and the desk becomes calmer. (The same logic powers how a clinic opens on time.)

Notice what these have in common. None needed a budget approval. Each was visible to the people who did the work. Each could be undone if it failed.

Where kaizen goes wrong

Kaizen is simple, and simple things get ruined in predictable ways.

It becomes a suggestion box. Ideas go in, nothing comes out, and within a month nobody writes anything. A suggestion that does not get an answer in a week is a suggestion you have lost.
Management delegates it and disappears. When the manager never asks "what did we try this week?" the team concludes it does not matter. You need not run the sessions, but you must show up and notice.
The fixes are always big. Teams that aim only for big fixes do nothing for months while they wait for the big budget. The rule of thumb: if it cannot be tried in two weeks, cut it in half.
Blame sneaks in. "Why did you not follow the process?" turns a learning session into a trial. Replace it with "What made the process hard to follow?"
Nobody measures. Without a number you cannot tell improvement from fashion. A rough number beats none.
Improvements are never standardized. A fix that lives in one person's head disappears when they go on holiday. When a change works, write it into the checklist, template or procedure. If you cannot say where it is written, it is not a standard yet.
It is used as a weapon. If "continuous improvement" really means "do more with fewer people," people will hide problems instead of reporting them. Kaizen only works where honesty is safe.

Fitting kaizen into a project without slowing it down

The most common worry I hear is: "We do not have time." Fair enough. Here is how I keep it light:

One slot per week, 20 to 30 minutes, at the end of an existing meeting, not a new meeting. The weekly review in the free toolkit is a good home for it.
One improvement at a time. The limit is what makes it finish. This is the same logic as a work-in-progress limit.
A visible list. A board with three columns: ideas, trying and done. If you already use a kanban board, add a lane.
A small budget of time, not money. Allow about 5% of the team's time for improvement. That is two hours in a forty-hour week. It repays itself quickly.
Record decisions. When a change becomes the standard, note it in the decision log, with the reason. It prevents "why do we do it this way?" in six months.
Feed the loop with the project's own data. Late tasks, repeated change requests and recurring defects tell you where to look. The change request log is a good source: a type of change that appears four times is a process problem, not four bad luck events.

Build your kaizen card

The card below is the one-page version of everything above. The sample is a small, realistic problem (late daily forms on a building site). Replace it with an irritation from your own project. The tool checks the card as you type: it warns when the problem has no number, when there is no root cause, when the test has no date, and when there is no measure for the check. It then turns your answers into a one-page summary you can paste into an email or a shared document. Nothing you type leaves your browser.

What to do this week

Pick one irritation. Just one. Ask your team on Monday, "What wasted your time last week?", write down the answers on sticky notes and choose the most frequent one that you can fix yourselves. Put a number on it. Ask why until you reach a cause you control. Try the smallest change for two weeks and write the check date on the card. On that date, look at the number again.

That is the whole practice, and it is a good one. If you would like help setting up an improvement rhythm for your team, or running a short process review before a project starts, you can reach me through the contact page.

What is the smallest fix you ever made that saved the most time? Tell me in the comments.

More tools. The decision log, the change request log and the weekly review are free in the toolkit.

Also read. The meeting that feeds the loop: lessons learned, with a template and five questions. And the idea that tells you which small fix to try first: the theory of constraints for project managers.

Need a project manager's help? See how I work with owners and teams in Utah and across the US: project management consulting in Salt Lake City and business consultant in Utah.

Frequently asked questions

What is kaizen in project management?

Kaizen is the practice of making many small improvements continuously, led by the people who do the work. In project management it means holding a short weekly slot to fix one irritation at a time, with a number, a root cause, a small change and a date to check the result.

What is the difference between kaizen and PDCA?

PDCA (Plan, Do, Check, Act) is the cycle used to run one improvement experiment. Kaizen is the broader habit of running such cycles all the time, with everybody taking part. PDCA is the method; kaizen is the culture that keeps using it.

How do you start kaizen on a small team?

Ask the team what wasted their time last week, pick one frequent problem you can fix yourselves, put a rough number on it, find the root cause with the five whys, try the smallest change for two weeks and check the number on a fixed date. Repeat every week.

Does kaizen work on projects that only last a few months?

Yes. Short projects benefit most from fast, small fixes made while the project is still running. A weekly 20-minute slot inside an existing meeting is enough, and the lessons carry over into the checklists and templates you use on the next project.

Kaizen for Project Managers: Small Weekly Fixes, the Five Whys and a One-Page Card

What kaizen actually means

Why a project manager should care