Gemba Walk Checklist: How to Tell If an Improvement Is Quietly Slipping

The Gemba Walk Checklist is a checklist of observations and questions to use during gemba walks to assess sustainment. That is the whole job. You walk the process, you ask the same questions each time, you write down what you expected and what you actually saw, and you mark each item conforming or non-conforming.

It sits in the Sustain phase of RDMAICS because that is where improvements die quietly. The project closes. The team disperses. The control plan is signed. Six weeks later the board is a week stale and nobody has mentioned it. Nothing broke. The process simply drifted back towards what it was before.

Reach for this tool once the handover is done and the improvement belongs to the line, not the project. Use it on a cycle you can hold to, whether that is weekly or monthly. The value comes from repetition. A single walk tells you about one morning. A run of walks tells you whether the new way of working has taken root.

Everything below is built on the sample data that ships with the tool. It is fictional. It is there so you can see the shape of a completed checklist before you write your own.

The case is a sustainment walk on a process that has a control plan behind it. The walk covers five items: whether SOPs are accessible, whether the visual board is updated, whether SPC charts are reviewed, whether open exceptions are managed inside the agreed window, and whether training is current. Those five cover documents, visual management, data review, escalation and capability. Between them they describe most of what keeps an improvement standing.

Four of the five came back conforming. One did not. That single result is the reason to walk at all.

Each row in the table is one observation. You fill in the item, the question you will ask, what you expect to see, what you actually saw, the finding, and any action. Observation Item and Finding are the required fields. The rest make the record useful to someone who was not there.

The sample shows how specific an expectation should be. For SOPs the expected value is not simply yes. It is yes, at workstation. That tells the observer where to look and removes the argument about whether a document buried in a shared folder counts as accessible. For the board the expectation is updated today, not updated recently. For SPC the expectation is yes, in huddle, which names the forum as well as the act.

Write the questions in the words you will actually use when you stand in front of someone. Can operators find the SOP. Is the board current. Did the team review charts today. Are open exceptions under twenty four hours. Any untrained staff. Short questions get honest answers.

The actual column is the only one you fill in during the walk. Everything else is set before you leave your desk. That discipline is what stops a gemba walk from becoming a wander.

The tool counts what you recorded. For the sample data it reports five items observed, four of five conforming, one non-conforming, and one of one non-conforming items carrying an action.

That last count is the one most people skim past. It is not asking how many problems you found. It is asking whether every problem you found has somebody doing something about it. One non-conforming item, one action attached. The ratio is complete. If it read zero of one, the walk would have produced an observation and nothing else.

The tool then names the gap directly. Exceptions managed, expected yes, actual two aged over twenty four hours, action investigate approver. Below that, each of the five items is laid out with its question, expected value, actual value, finding and action, including the four that passed. The passes matter. They are the evidence that four parts of the control plan are still holding.

The tool also offers an AI review that explains the result if you want a second reading of what the pattern suggests.

The sample walk supports three decisions and rules out a fourth.

First, it tells you where to look next. The action on the non-conforming row is investigate approver, not retrain operators. The exceptions were raised. They were simply not cleared inside the window. That points at the approval step, not the floor. A checklist that recorded only a count of failures would not have steered you there.

Second, it tells you what to leave alone. SOPs, board, SPC review and training all came back conforming. You do not need to rebuild those routines this month. Sustainment effort is finite and the checklist tells you where not to spend it.

Third, it tells you whether the drift is systemic or local. One non-conforming item out of five is a point problem. If the board had also been stale and the huddle skipped, you would be looking at a routine that is collapsing as a whole, and the response would be different.

What it does not support is a conclusion about trend. One walk is one morning. Two aged exceptions may be a bad week or the start of a pattern. You need the next walk to know.

The checklist is a detector. Certain patterns in it are worth naming.

Watch for the expected value quietly softening. If updated today becomes updated this week between one walk and the next, the standard moved, not the process. Watch for non-conforming rows that recur with the same action text. Investigate approver is a reasonable action once. The third time it appears unchanged, the action is not being done or the approver is not the cause.

Watch for the non-conforming with an action count falling below the non-conforming count. That means you are recording problems and walking away from them. It is the most common way a sustainment routine turns into theatre.

Watch also for the actual column filling with single words where the expected column is detailed. In the sample, the SOP row records actual yes against expected yes, at workstation. That is acceptable when the observer genuinely checked the workstation. It becomes a problem when yes is what the observer heard rather than what the observer saw.

The first mistake is writing too many rows. Five items were enough to cover documents, visuals, data, escalation and training in the sample. Twenty items turn a walk into a form filling exercise and the actuals start getting copied from last time.

The second is vague expectations. If the expected value is good or adequate, two observers will disagree and the finding becomes an opinion. Every expected value in the sample can be checked by looking.

The third is deleting the conforming rows to save space. The four conforming items are the record that the control plan is working. Remove them and you keep only a list of complaints, which is a poor picture of a process and an unfair one.

The fourth is leaving a non-conforming row with no action. The tool counts that ratio for a reason.

The Gemba Walk Checklist records what one person saw at one time against expectations that person wrote. It does not verify them. If the observer records yes without checking, the tool will count a conforming item and the output will look clean.

It does not analyse causes. The sample names an action, investigate approver, which is an instruction to go and find out, not a finding. The checklist can point at a step. It cannot tell you why that step is slow.

It does not track trend on its own. The counts of five, four of five and one belong to this walk. Comparing walks over time is work you do outside the tool, and that comparison is where most of the sustainment signal actually lives.

It does not measure process performance. Four conforming items mean four routines were being followed on the day. They do not mean the output is in control, the customer is satisfied or the gain held. For that you need the control charts the checklist only asks whether somebody looked at.

Finally, it does not make anyone act. The one of one action count tells you an action was written down. Whether it was done shows up in the next walk, or it does not show up at all.