The Walk of the Gemba

What is a “Gemba” – a slight rant

Gemba, as a term, is here to stay. We’re told that gemba comes from the Japanese for “the actual place”, and people who know more than me say it probably should translate as “Genba” but phonetically it uses an “m” instead and as a result, it’s commonly referred to as gemba – so that’s how it is used. Someday I’ll see a good linguistic study of loan words in quality circles, and I have been known to fight against some of the “buzz-terminess” of adoption of words from Japanese. But gemba is a term that seems to have settled in, and heck, English is a borrowing language.

Just don’t subject me to anymore hour long talks about how we’re all doing lean wrong because we misunderstood a Japanese written character (I can assure you I don’t know any Japanese written characters). The Lean practitioner community sometimes reminds me of 80s Ninja movies, and can be problematic in all the same ways – you start with Enter the Ninja and before long its Remo Williams baby!

So lets pretend that gemba is an English word now, we’ve borrowed it and it means “where the work happens.” It also seems to be a noun and a verb.

And if you know any good studies on the heady blend of Japanophobia mixed with Japanophilia from the 80s and 90s that saturated quality and management thinking, send them my way.

The Importance of the Gemba Walk

Gemba is a principle from the lean methodology that says “go and see” something happening for real – you need to go and see how the process really works. This principle rightly belongs as one of the center points of quality thinking. This may be fighting words but I think it is the strongest of the principles from Lean because of the straightforward “no duh” of the concept. Any quality idea that feels so straightforward and radical at the same time is powerful.

You can think of a gemba through the PDCA lifecycle -You plan, you do it, you decide on the learnings, you follow through.

Gemba seen through the PDCA lense

This is all about building a shared understanding of problems we all face together by:

  1. Observation of specific issues where things don’t go as intended, listening to the people who do the work.
  2. Discussion of what those issues mean both in the details of operations but also on a wider strategic level.
  3. Commitment to problem solving in order to investigate further – not to fix the issue but to have the time to delve deeper. The assumption is that if people understand better what they do, they perform better at every aspects of their job

Gemba walks demonstrate visible commitment from the leadership to all members of the
organization. They allow leadership to spread clear messages using open and honest
dialogue and get a real indication of the progress of behavioral change at all levels. They
empower employees because their contributions to site results are recognized and their
ideas for continuous improvements heard.

Conducting a Successful Gemba Walk

Elements of a Successful Gemba

Plan Effectively
Define your goalWhat is it that you want to do a gemba walk for? What do you hope to find out? What would make this activity a success? A successful walk stresses discovery.
Set a scopeWhich areas will you observe? A specific process? Team? This will allow you to zoom into more detail and get the most out of the activity.
Set a themeWhat challenges or topics will you focus on? Specific and targeted gemba walks are the most effective. For example, having a emba focusing on Data Integrity, or area clearance or error reduction.

Picking the right challenge is critical. Workplaces are complex and confusing, a gemba walk can help find concrete problems and drive improvement linked to strategy.
Find additional viewpointsWho else can help you? Who could add a “fresh pair of eyes” to see the big questions that are left un-asked. Finding additional people to support will result in a richer output and can get buy in from your stakeholders.
Get supportBring visibility and sponsorship for your gemba. Ensure all stakeholders are aware and on board.
Plan the Logistics
Identify Suitable TimeFind a suitable time from the process’ perspective. Be sure to also consider times of day, days of the week and any other time-based variations that occur in the process.
Find right locationWhere should you see the process? Also, do you need to consider visiting multiple sites or areas?
Map what you’ll seeDefine the process steps that you expect to see.
Build an agendaWhat parts of the process will you see in what order? Are there any time sensitive processes to observe?
Share that agendaSharing your agenda to get help from the operational owner and other subject matter experts.
Doing the Gemba Walk
Explain what you are doingPut people at ease when you’re observing the process.

When you are on the walk you need to challenge in a productive yet safe manner to create a place where everyone feels they’ve learned something useful and problems can be resolved. It pays to communicate both the purpose and overall approach by explaining the why, the who, and the when.
Use your agendaKeep some flexibility but also make sure to cover everything.
Ask open questionsOpen discussion and explore the process challenges.
Ask closed questionsUse this to check your understanding of the process.
Capture reality with notesTake notes as soon as possible to make sure you recall the reality of the situation.
CoachAs a coach, your objective is not to obtain results – that’s the person you’re coaching’s role – but to keep them striving to improve. Take a step back and focus on dismantling barriers.
What did you learnWhat did you expect to see but didn’t? Also, what did you not expect to happen?

The ask questions, coach, learn aspect can be summarized as:
  1. Visualize the ideal performance with your inner eye

  2. Spot the specific difficulty the person is having (they’ll tell you – just listen)

  3. Explain that (though sometimes they won’t want to hear it)

  4. Spell out a simple exercise to practice overcoming the difficulty.
After the Gemba Walk
What did you learn?Were challenges widespread or just one offs? Review challenges with a critical eye. The best way I’ve heard this explained is “helicopter” thinking – start n a very detailed operational point and ascend to the big picture and then return to the ground.
Resolve challenges with a critical eyeDefine next steps and agree which are highest priority. It is a good outcome when what is observed on the gemba walk leads to a project that can transform the organization.
Take actionFollow-through on the agreed upon actions. Make them visible. In order to avoid being seen only as a critic you need to contribute firsthand.
Hold yourself to accountShare your recommendations with others. Engage in knowledge management and ensure actions are complete and effective.
Key points for executing a successful GEMBA

Gemba Walks as Standard Work

You can standardize a lot of the preparation of a gemba walk by creating standard work. I’ve seen this successfully done for data integrity, safety, material management and other topics.

Build a frequency, and make sure they are often, and then hold leaders accountable.

WhoBest Practice FrequencyMinimum Recommended Frequency
First line supervisorsEach shift, multiple timesEach shift
Team leaders in individual unitsDaily covering different shifts2 per week
Unit/Department heads1 per day1 per week
Leadership team1 per day1 per month
Internal customers and support (e.g. purchasing, finance, HR)1 per month1 per quarter
Frequency recommendation example

Going to the Gemba for a Deviation and Root Cause Analysis

These same principles can apply to golden-hour deviation triage and root cause analysis. This form of gemba means bringin together a cross-functional team meeting that is assembled where a potential deviation event occurred. Going to the gemba and “freezing the scene” as close as possible to the time the event occurred will yield valuable clues about the environment that existed at the time – and fresher memories will provide higher quality interviews. This gemba has specific objectives:

  • Obtain a common understanding of the event: what happened, when and where it happened, who observed it, who was involved – all the facts surrounding the event. Is it a deviation?
  • Clearly describe actions taken, or that need to be taken, to contain impact from the event: product quarantine, physical or mechanical interventions, management or regulatory notifications, etc.
  • Interview involved operators: ask open-ended questions, like how the event unfolded or was discovered, from their perspective, or how the event could have been prevented, in their opinion – insights from personnel experienced with the process can prove invaluable during an investigation.

You will gain plenty of investigational leads from your observations and interviews at the gemba – which documents to review, which personnel to interview, which equipment history to inspect, and more. The gemba is such an invaluable experience that, for many minor events, root cause and CAPA can be determined fairly easily from information gathered solely at the gemba.

What prevents us from improving systems?

Improvement is a process and sometimes it can feel like it is a one-step-forward-two-steps-back sort of shuffle. And just like any dance, knowing the steps to avoid can be critical. Here are some important ones to consider. In many ways they can be considered an onion, we systematically can address a problem layer and then work our way to the next.

Human-error-as-cause

The vague, ambiguous and poorly defined bucket concept called human error is just a mess. Human error is never the root cause; it is a category, an output that needs to be understood. Why did the human error occur? Was it because the technology was difficult to use or that the procedure was confusing? Those answers are things that are “actionable”—you can address them with a corrective action.

The only action you can take when you say “human error” is to get rid of the people. As an explanation the concept it widely misused and abused. 

Human performance instead of human error
AttributePerson ApproachSystem Approach
FocusErrors and violationsHumans are fallible; errors are to be expected
Presumed CauseForgetfulness, inattention, carelessness, negligence“Upstream” failures, error traps; organizational failures that contribute to these
Countermeasure to applyFear, more/longer procedures, retraining, disciplinary measures, shamingEstablish system defenses and barriers
Options to avoid human error

Human error has been a focus for a long time, and many companies have been building programmatic approaches to avoiding this pitfall. But we still have others to grapple with.

Causal Chains

We like to build our domino cascades that imply a linear ordering of cause-and-effect – look no further than the ubiquitous presence of the 5-Whys. Causal chains force people to think of complex systems by reducing them when we often need to grapple with systems for their tendency towards non-linearity, temporariness of influence, and emergence.

This is where taking risk into consideration and having robust problem-solving with adaptive techniques is critical. Approach everything like a simple problem and nothing will ever get fixed. Similarly, if every problem is considered to need a full-on approach you are paralyzed. As we mature we need to have the mindset of types of problems and the ability to easily differentiate and move between them.

Root cause(s)

We remove human error, stop overly relying on causal chains – the next layer of the onion is to take a hard look at the concept of a root cause. The idea of a root cause “that, if removed, prevents recurrence” is pretty nonsensical. Novice practitioners of root cause analysis usually go right to the problem when they ask “How do I know I reached the root cause.” To which the oft-used stopping point “that management can control” is quite frankly fairly absurd.  The concept encourages the idea of a single root cause, ignoring multiple, jointly necessary, contributory causes let alone causal loops, emergent, synergistic or holistic effects. The idea of a root cause is just an efficiency-thoroughness trade-off, and we are better off understanding that and applying risk thinking to deciding between efficiency and resource constraints.

In conclusion

Our problem solving needs to strive to drive out monolithic explanations, which act as proxies for real understanding, in the form of big ideas wrapped in simple labels. The labels are ill-defined and come in and out of fashion – poor/lack of quality culture, lack of process, human error – that tend to give some reassurance and allow the problem to be passed on and ‘managed’, for instance via training or “transformations”. And yes, maybe there is some irony in that I tend to think of the problems of problem solving in light of these ways of problem solving.

Root Cause Analysis Deficiencies

An appropriate level of root cause analysis should be applied during the investigation of deviations, suspected product defects and other problems. This can be determined using Quality Risk Management principles. In cases where the true root cause(s) of the issue cannot be determined, consideration should be given to identifying the most likely root cause(s) and to addressing those. Where human error is suspected or identified as the cause, this should be justified having taken care to ensure that process, procedural or system based errors or problems have not been overlooked, if present.

Appropriate corrective actions and/or preventative actions (CAPAs) should be identified and taken in response to investigations. The effectiveness of such actions should be monitored and assessed, in line with Quality Risk Management principles.

EU Guidelines for Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use, Chapter 1 Pharmaceutical System C1.4(xiv)

The MHRA cited 210 companies in 2019 on failure to conduct good root cause analysis and develop appropriate CAPAs. 6 of those were critical and a 100 were major.

My guess is if I asked those 210 companies in 2018 how their root cause analysis and CAPAs were doing, 85% would say “great!” We tend to overestimate our capabilities on the fundamentals (which root cause analysis and CAPA are) and not to continuously invest in improvement.

Of course, without good benchmarking, its really easy to say good enough and not be. There can be a tendency to say “Well we’ve never had a problem here, so we’re good.” Where in reality its just the problem has never been seen in an inspection or has never gone critical.

The FDA has fairly similar observations around root cause analysis. As does anyone who shares their metrics in any way. Bad root cause and bad CAPAs are pretty widespread.

This comes up a lot because the quality of CAPAs (and quantity) are considered key indicators of an organization’s health. CAPAs demonstrate that issues are acknowledged, tracked and remediated in an effective manner to eliminate or reduce the risk of a recurrence. The timeliness and robustness of these processes and records indicate whether an organization demonstrates effective planning and has sufficient resources to manage, resolve and correct past issues and prevent future issues.

A good CAPA system covers problem identification (which can be, and usually is a few different processes), root cause analysis, corrective and preventive actions, CAPA effectiveness, metrics, and governance. It is a house of cards, short one and the whole structure will fall down around you, often when you least need it to.

We can’t freeze our systems with superglue. If we are not continually improving then we are going backwards. No steady state when it comes to quality.

Interviewing

One of the great tools of root cause analysis, planning, process improvement and knowledge management is the interview. Properly used the interview allows one to gather a great deal of information and perspective and ferret out hidden information.

For interviews to be truly effective, we have to understand how the function and apply a process. Cognitive Interviewing, originally created for law enforcement and later adopted during accident investigations by the National Transportation Safety Board (NTSB), provides an effective framework. I was first introduced to this at my previous company, where it has become a real linchpin, so I share it here.

The two principles here are:

  • Witnesses need time and encouragement to recall information
  • Retrieval cues enhance memory recall

Based on these two principles there are four components:

ComponentWhat It Consists of
Mental ReinstatementEncourage the interviewee to mentally recreate the environment and people involved.
In-Depth ReportingEncourage the reporting of all the details, even if it is minor or not directly related to the purpose of the interview. This is intended to improve the detail and accuracy of memory.

For example, if investigation a computer error, you would encourage the interviewee to discuss everything they were doing around the event. You would hold the interview at the station the error happened, ideally using the computeras much as possible.
Multiple PerspectivesAsk the interviewee to recall the event from others’ points of view. For example, the person upstream or downstream, or a partner or observer.
Several OrdersAsk the interviewee to recount the timeline in different ways. Beginning to end, end to beginning.
Four Components of Cognitive Interviewing

A key part of this is that retrieval cues access memory. This is why doing the interview on the scene (or Gemba) is so effective.

The basic behaviors you want to bring to bear are:

  • Recreate the original context; have them outline and walk you through process to explain how they work.
  • Tell the the witness to actively generate information and not wait passively for the interviewer to ask questions.
  • Adopt the witness’s perspective; ask eyewitness-compatible questions.
  • Perform the interview at the Gemba, the place where the work happens.
  • Listen actively, do not interrupt, and pause after the witness’s response.
  • Ask open-ended questions, utilize short phrases when possible.
  • Encourage the witness to use imagery. Explicitly request detailed descriptions.
  • Follow the sequence of the cognitive interview major components.
  • Bring support materials such as attachments, procedures, and copies of relevant documents.
  • Establish a connection with the witness; demeanor has a big impact.
  • Remember, active listening.
  • Do not tell the interviewee how they made the mistake, blame, or assume.

Active listening is key here.

Active Listening funnel

At the mouth of the funnel we begin with an ‘open’ question. This question is intended to give the interviewee the widest possible scope for responding. Sometimes it may be necessary to repeat or rephrase this question to give the interviewee more thinking time and further opportunities to raise information. Working down the narrowing body of the funnel we use a series of probing questions to draw out further specific information and help complete the picture. Closed questions then have their place to draw out, check or confirm specific pieces of information, or to get the interviewee to commit on a point more precisely. This then brings us to the bottom of the funnel where we clarify, using a short summary, what we have got out of the discussion, aiming to check our understanding of the main points. The question sequence might go something like this:

  • ‘Tell me how you went about…?’ (open)
  • ‘How did you prepare?’ (open – secondary)
  • ‘What was your starting point?’ (probe)
  • ‘So, what happened next?’ (probe)
  • ‘Who else was involved?’ (probe)
  • ‘And how did they respond?’ (probe)
  • ‘What were your thoughts at that stage?’ (probe)
  • ‘What were the main outcomes?’ (probe)
  • ‘So, that took a total of 30 minutes?’ (closed – clarifying)
  • ‘And the task was completed?’ (closed – clarifying)
  • ‘So, let me see if I’ve followed you…’ (checking – summary)

A good interview requires preparation. Have opening questions ready, ensure you have all the right props and the right people involved. That extra hour or two will pay dividends.

Here is a helpful worksheet.

Lessons in Lean – Structured Problem-Solving: Rarely Given the Attention it Deserves

There is little argument regarding the critical role that structured problem-solving plays in a lean transformation. Besides the business results associated with solving problems, developing problem-solving skills increases learning, drives the desired change in thinking, and helps people more clearly understand how lean works as a system. With this said, however, it is amazing how little effort many organizations put into developing effective problem-solving skills. It seems like more time is spent on things like 5S, value stream mapping, and other tools that are generally considered easier to apply and less likely to be met with resistance.  As a result, transformation does not occur, improvements are not sustainable, and the big gains possible through lean thinking are never achieved.

Lessons in Lean: Structured Problem-Solving: Rarely Given the Attention it Deserves
by Greg Stocker

Good discussion on the importance of rigorous, sustained problem-solving as part of Lean initiatives. I think many of us have experienced this in our own organizations.

Utilizing problem solving tools in a structured way helps us better understand what is happening, how it is happening and most importantly, why it is happening. Armed with this understanding we can then engage in those improvements. Problem solving is key to getting those improvements because it allows us to discover why a problem is actually happening and not to just treat symptoms.

Problem Solving needs to reach a level of detail that accurately identifies an actionable cause that can then be addressed.