A Gemba walk is a management practice built around direct observation. Instead of trying to understand a process only through dashboards, status meetings, or reports, a leader goes to the place where the work happens, watches the process, asks respectful questions, and learns how value is actually created. In Lean thinking, \u201cgemba\u201d means the actual place. The central idea is simple: decisions improve when managers understand the real work before changing it.<\/p>\n
That principle fits project management surprisingly well. Projects often fail through a gap between the process described in plans and the process people actually follow. A schedule may say that one task takes two days, while the team waits three additional days for approval. A dashboard may report a stable defect rate, while engineers spend hours reworking the same handoff. A process document may describe a clean workflow that nobody uses because it is too slow for real conditions.<\/p>\n
Gemba walks help project managers find those differences. They are closely related to Lean thinking<\/a> because the goal is not to inspect people. The goal is to understand value, flow, waste, constraints, and the conditions under which the team performs the work.<\/p>\n The easiest way to misuse a Gemba walk is to arrive with a predetermined answer. If the manager already believes the problem is \u201cpeople are not following the process,\u201d every observation will be interpreted through that assumption. A productive walk begins with curiosity.<\/p>\n Observe what happens from the perspective of the work. Where does an item enter the process? Who touches it? What information do they need? Where does it wait? Which approvals interrupt flow? What tools are used? What happens when something is wrong? How often does a task return for rework?<\/p>\n The project manager should ask questions that uncover the process rather than defend the project plan. \u201cWhat makes this step difficult?\u201d is more useful than \u201cWhy are you behind?\u201d \u201cWhat information do you usually wait for?\u201d is more useful than \u201cWhy can\u2019t this be completed faster?\u201d The tone matters because people will hide problems if they believe observation is really a performance inspection.<\/p>\n Project plans are abstractions. They break work into tasks, durations, dependencies, milestones, and resources. Real work contains interruptions, workarounds, queues, informal approvals, tool problems, conflicting priorities, and knowledge that exists only in one person\u2019s head.<\/p>\n Suppose a software-release plan includes a one-day security review. The schedule looks reasonable. During a Gemba walk, the project manager discovers that developers cannot request the review until a spreadsheet is updated manually, only one person approves access to the test environment, and the security team receives requests in several different formats. The \u201cone-day review\u201d may actually include four days of waiting before the technical work begins.<\/p>\n That insight changes project management. The problem is no longer \u201csecurity takes too long.\u201d The project can improve request standardization, access preparation, capacity planning, or the timing of the dependency. Direct observation turns a vague delay into a process that can be improved.<\/p>\n Projects often optimize activities while ignoring the time between activities. A person may complete a task efficiently and still contribute to a slow overall process because work waits in queues or crosses too many handoffs.<\/p>\n Gemba observation encourages the manager to follow the item, not only the worker. In manufacturing, that item might be a physical product. In software, it could be a feature, defect, pull request, incident, or release. In a service organization, it could be a customer request, claim, purchase order, or support case.<\/p>\n Following work from start to finish makes waiting visible. It also exposes batch behavior. Teams may hold ten requests before processing any of them because \u201cthat is how we have always done it.\u201d A reviewer may check work only twice a week even though reviews take five minutes. A manager may require a meeting for decisions that could be made asynchronously.<\/p>\n This is where continuous improvement<\/a> becomes practical. Improvement does not always require a major transformation project. Removing one unnecessary queue can reduce lead time more than asking every person to work faster.<\/p>\n Formal risk registers are useful, but they usually contain risks someone has already identified. Gemba walks can reveal emerging problems before they are large enough to appear in project reporting.<\/p>\n A project manager may notice that a team is using an unsupported spreadsheet to track critical configuration, that one specialist is answering every technical question, that temporary manual work has become permanent, or that staff are repeatedly bypassing a quality check to meet deadlines. None of those conditions may have caused a visible project failure yet, but each can become a risk.<\/p>\n Observation gives the manager a chance to ask whether the condition is understood, whether it is temporary, and what would happen if it worsened. The point is not to add every observation to the risk register. It is to recognize patterns that deserve investigation before they become incidents.<\/p>\n A Gemba walk should not feel like an executive inspection. If employees expect blame, they will clean up the process before the visit, hide workarounds, and give safe answers. The manager then sees a performance rather than the real system.<\/p>\n Lean management treats the people doing the work as an important source of process knowledge. They know which forms are confusing, which handoffs fail, which tools slow them down, which exceptions occur repeatedly, and which official rules are impossible to follow under current conditions.<\/p>\n That does not mean every suggestion is correct or that managers surrender responsibility. It means improvement should begin with evidence from the process and from the people who interact with it every day. Asking \u201cWhat gets in your way?\u201d can reveal more than a month of status reporting if the conversation is genuinely safe.<\/p>\n This human side is why Gemba walks work well with the broader skills described in effective project management<\/a>: communication, stakeholder management, leadership, risk awareness, problem solving, and decision-making all improve when the manager has direct knowledge of the work.<\/p>\n Walking around without a question can produce interesting observations but little improvement. Before the walk, define the process or problem you want to understand. The focus might be release approval, customer onboarding, defect resolution, invoice processing, deployment, handoff between engineering and operations, or another workflow connected to project performance.<\/p>\n Use a small set of prompts: What is the purpose of this process? What is the expected flow? Where does work wait? What information is missing? What causes rework? What prevents people from completing the step correctly the first time? What evidence is available?<\/p>\n Do not turn the prompts into a checklist that prevents discovery. If an unexpected issue appears, follow it. A Gemba walk is valuable precisely because it allows managers to see conditions that were not in the original report.<\/p>\n Visual management makes Gemba observations easier to connect to project data. Physical or digital visual management can help teams make flow visible. Kanban boards, queue dashboards, defect trends, cycle-time charts, work-in-progress limits, blocked-item markers, and service-level indicators all provide useful context during a Gemba walk.<\/p>\n The key is to compare the visual system with reality. Does the board show all active work? Are blocked items marked when people are actually waiting? Does the status reflect the point where value is created, or only the status entered for reporting? Does a green dashboard hide a growing queue?<\/p>\n When the visual signal and observed process disagree, investigate the definition. A metric can be accurate while still measuring the wrong thing. A team may report \u201ctask completion\u201d when the customer still waits two more weeks for integration. Gemba observation helps project managers validate whether metrics reflect outcomes rather than administrative milestones.<\/p>\n Lean focuses heavily on value, flow, waste, and continuous improvement. Six Sigma focuses on variation, defects, measurement, and process capability. Gemba can support both because it gives the improvement team direct knowledge before measurement or redesign.<\/p>\n A Lean Six Sigma Green Belt<\/a> project, for example, may begin with data showing long cycle time. A Gemba walk can reveal why the cycle time exists and help the team decide what data should be collected. That evidence can then be analyzed more formally rather than relying on impressions.<\/p>\n Likewise, 5S<\/a> improvement often benefits from seeing the actual workplace. The point is not to make a workspace look tidy for a photograph. It is to reduce searching, unnecessary movement, ambiguity, and conditions that make correct work harder.<\/p>\n Do not confuse Gemba with micromanagement. Micromanagement is usually about controlling how individuals perform work. Gemba is about understanding the system in which they perform it. The difference becomes obvious in the questions asked.<\/p>\n A micromanager asks why one person took 40 minutes. A Gemba-minded manager asks what conditions make the step take anywhere from 10 to 60 minutes. A micromanager tells the team which button to click. A Gemba walk asks why the process requires repeated manual entry at all.<\/p>\n This distinction is important for project leaders because process problems often appear as individual performance issues. If every analyst struggles with the same data handoff, replacing one analyst will not fix the handoff. Direct observation helps identify whether the constraint belongs to the person, the process, the tool, the policy, or the design of the work.<\/p>\n Turn observations into small experiments instead of immediate large changes. After the walk, resist the urge to launch a major redesign based on one observation. Confirm what you saw, discuss it with the people involved, collect data where needed, and test a small improvement.<\/p>\n If a queue exists because requests arrive with missing information, try a clearer intake template with one team before changing the organization-wide process. If a handoff requires an unnecessary approval, test delegated authority for a limited category. If a dashboard is misleading, change the metric definition and see whether decisions improve.<\/p>\n Small experiments reduce risk and create evidence. If the change works, standardize it. If it does not, learn why. This cycle is one of the reasons Gemba fits naturally with Lean Six Sigma<\/a> thinking.<\/p>\n The best outcome is not a long list of faults. It is a more accurate understanding of the process. You should know where value is created, where work waits, which constraints matter, which metrics are misleading, and what the team experiences that management reporting did not show.<\/p>\nA Gemba walk begins with observation, not with a solution<\/h3>\n
Gemba walks reveal hidden work that schedules often miss<\/h3>\n
Use Gemba walks to understand flow, not just individual task duration<\/h3>\n
Gemba walks can improve risk management because weak signals appear early<\/h3>\n
Respect for people is essential because the goal is to learn from the work<\/h3>\n
A Gemba walk should have a focus without becoming a scripted audit<\/h3>\n
Gemba walks work particularly well with Lean and Six Sigma improvement<\/h3>\n
A useful Gemba walk leaves the project manager with better questions<\/h3>\n