Seeing at the Gemba

The Scheduler Who Took Two Months to Notice a Failing Project through Power BI Dashboards

There is a project scheduler sitting in a corporate office three hundred miles from the jobsite. He manages schedules for seventeen projects across the region. Every day he opens Power BI dashboards filtering data from P6 schedules. Colorful charts show float trends, variance analysis, and critical path metrics. And one day, something feels wrong about a particular project. He cannot pinpoint it. Just a feeling. So he keeps watching. Two months later, the dashboard finally flags the project. Red indicators everywhere. Schedule variance off the charts. Critical path compressed. Float consumed. And the scheduler calls the project team: we need to swarm and recover this project immediately. The team mobilizes. Consultants arrive. Recovery plans get written. And six months later, the project finishes four months late despite heroic efforts. When someone asks the scheduler what happened, he explains proudly: I noticed something was wrong and kept watching the dashboards until the data confirmed it two months later. Then we acted quickly to minimize damage. And he does not understand why people are not impressed. Because two months is not quick. Two months is catastrophic. In those two months, the project burned through contingency, destroyed relationships with trades, and locked itself into a crash landing that no amount of swarming could prevent. Meanwhile another project using Takt planning spotted a sequencing problem in four hours. Not two months. Four hours. The superintendent noticed trades stacking up visually on the Takt board. Called an afternoon coordination meeting. Adjusted the sequence. And work resumed flowing the next morning. Same industry. Same problem type. Different latency. And the gap between two months and four hours is the difference between projects that succeed and projects that fail.

Here is what happens when teams cannot see problems at the Gemba, the actual place of work. A superintendent manages a project using CPM schedules. The P6 file has 5,000 activities. Logic tied. Resources loaded. Updated weekly by a project engineer who inputs actual dates and runs recalculations. The engineer uploads the updated schedule to the project website. Sends an email announcing its availability. And assumes communication is complete. Meanwhile on the jobsite, mechanical falls three weeks behind because steel fabrication delayed. But the delay does not show up in the CPM schedule for six weeks. Why? Because the logic ties are so complex that the impact takes weeks to ripple through the network. And by the time the schedule shows the problem, mechanical is six weeks behind instead of three. Recovery costs double. Trade relationships deteriorate. And the owner starts questioning competence. Not because the team lacked skill. But because the scheduling system hid the problem for six weeks while it metastasized from manageable to catastrophic. CPM is not a visual system. It is a data system. And data systems have latency that kills projects.

The real pain is the research proving visual systems win. Studies analyzing thousands of projects show traditional project management methods using CPM achieve only 26% success rates. Absolute failures are 21%. And projects that are challenged are 53%. When teams switch to agile methods like Scrum or lean methods like Last Planner, success rates jump to 42% minimum. Challenged projects drop to 50%. And failures plummet to 8%. That is a massive improvement. From 26% success to 42% success. From 21% failure to 8% failure. And the primary difference is latency. How quickly teams see problems and decide to act. Teams that identify and begin correcting issues within five hours have dramatically higher success rates than teams that take days, weeks, or months to notice problems through dashboards and reports. Five hours is the threshold. Not five days. Not five weeks. Five hours. Because problems compound. Small issues become big issues. Big issues become disasters. And the longer you wait to act, the harder recovery becomes.

The failure pattern is predictable and expensive. A project uses CPM scheduling. The scheduler sits in a corporate office reviewing dashboards monthly. A superintendent on site notices something feels wrong. Electrical seems behind. But the CPM schedule shows them on track. So the superintendent questions his judgment. Maybe electrical is fine. Maybe I am overreacting. Two months later, electrical admits they are six weeks behind. The schedule finally catches up to reality. And the project scrambles to recover. Crash schedule. Mandatory overtime. Compressed sequences. And ultimately finishes three months late. When someone asks what happened, the answer is always the same: we did not see the problem until it was too late. Because CPM schedules hide problems instead of surfacing them. The complexity creates opacity. The data lag creates latency. And by the time dashboards show red flags, the damage is done. Meanwhile projects using Takt boards see problems the day they start. Literally. A trade falls behind by one day. Everyone sees it on the visual board. And they adjust immediately. Before the one-day delay becomes a one-week delay that becomes a one-month delay that destroys the project.

I had a recovering scheduler call me recently defending CPM. He said: Jason, you are wrong. CPM is great. I had a project where I felt something was wrong. So I kept watching the Power BI dashboards. Sure enough, two months later the project showed up flagged. We swarmed and recovered it. And I said: you just proved my point. Two months. You took two months to notice a problem that visual systems would have surfaced in hours or days. That latency is the problem. Not whether you eventually noticed. But how long it took. Because in two months, small problems become catastrophic. And recovery costs ten times more than prevention. That is why Takt planning, Last Planner, and Scrum outperform CPM. Not because the people are smarter. But because the systems have lower latency. Problems surface immediately. Teams see them at the Gemba. And they act within five hours instead of two months. If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your field teams stabilize, schedule, and flow.

What Seeing at the Gemba Actually Means

Gemba is a Japanese word meaning “the actual place of work.” Where the work happens. Not the office. Not the conference room. The jobsite. The production floor. The place where value gets created. Seeing at the Gemba means going to the actual place of work, observing what is happening, and making decisions based on reality instead of reports. CPM schedules remove decision-making from the Gemba. Schedulers sit in offices. Review data. Generate reports. And make recommendations based on information filtered through multiple layers of abstraction. By the time problems show up in reports, they are old news. Already damaging the project. Already compounding. Visual systems put decision-making at the Gemba. Where people can see reality unfiltered. And respond immediately.

Latency is the delay before action. Between problem occurrence and problem identification. Between identification and decision. Between decision and action. Every layer of latency allows problems to compound. A trade falls one day behind. With visual systems at the Gemba, the superintendent sees it that afternoon. Calls a coordination meeting. Adjusts the sequence. And work resumes flowing the next morning. Total latency: four hours. With CPM systems, the delay does not show up in the schedule for weeks. The scheduler notices it months later through dashboards. And recovery happens after the problem has compounded into catastrophe. Total latency: two months. Same problem. Different latency. Catastrophically different outcomes.

Signs Your System Has Too Much Latency

Watch for these patterns that signal your scheduling and coordination systems hide problems instead of surfacing them:

• Problems get discovered weeks or months after they start because scheduling systems lag reality and dashboards filter information through multiple abstraction layers before flagging issues
• Superintendents notice problems on site but second-guess themselves because CPM schedules show everything on track creating cognitive dissonance between reality and reports
• Recovery efforts start after problems compound into crises instead of when issues are small and easily corrected because latency delays identification and decision-making
• Schedulers work in offices reviewing data while superintendents work on sites unable to see schedule status visually forcing reliance on reports instead of direct observation
• Teams spend more time updating schedules and generating reports than solving actual coordination problems because administrative overhead consumes capacity that should go to problem-solving
• Project success depends on schedulers noticing anomalies in dashboards instead of teams seeing problems directly at the Gemba and acting immediately without waiting for corporate confirmation

These are not people problems. These are system design problems. CPM creates latency by design. Data-driven systems require data collection, processing, analysis, and reporting. Each step adds delay. Visual systems eliminate latency by making problems visible immediately at the Gemba where work happens and decisions get made.

What Visual Systems Must Accomplish

Systems that enable seeing at the Gemba must meet specific criteria. They must be visual. Not just data tables. Actual visual representations that show status at a glance without analysis. They must bring problems to the surface immediately. Not next week. Not next month. The moment problems occur. They must show clearly what the problem is to everyone. Not just schedulers. Not just superintendents. Everyone on the project team sees the same reality simultaneously. They need to be easily understood. No training required to interpret. No complex analysis. Just look and know. They need to be easily checked. Walk past the board and verify reality matches the plan. No software required. They need to be actionable. Seeing the problem immediately suggests the solution. They need to be fast. Minutes to update. Not hours. Not days. They need to be reliable. Reflect actual reality. Not aspirational plans disconnected from field conditions. And they need to begin immediately. Problems visible today. Solutions implemented today. Not two months from now.

Takt planning accomplishes this. Visual boards showing zones and trades flowing through sequences. When a trade falls behind, everyone sees it immediately. The visual gap between planned position and actual position is obvious. No analysis required. Just look. See the problem. Call a meeting. Adjust. Resume flow. Total time from problem occurrence to solution implementation: hours. Last Planner accomplishes this. Weekly work planning with percent plan complete tracking. When commitments fail, teams see it in the weekly meeting. Discuss causes. Remove constraints. Re-plan. Total time: days. Scrum accomplishes this. Sprint planning with daily standups. When impediments arise, teams surface them immediately. Remove blockers. Continue sprinting. Total time: hours. CPM fails this. Problems hide in 5,000-activity schedules. Latency measured in weeks or months. Recovery happens after damage is done.

Process Not People When Problems Surface

When visual systems surface problems immediately, leaders face choices. Blame people or fix processes. Bad leaders blame people. Good leaders blame processes and behaviors. Shaming means blaming the person and who they are. Guilt or proper accountability focuses on what they are doing. Leaders never shame. They correct bad behavior and coach for improvement. And they focus first on process failures. What went wrong structurally that allowed this problem? If you think this way, you are forced to think creatively, solve problems, improve processes, and coach for bad behavior instead of scapegoating. You must believe people are capable of amazing things with proper coaching and mentoring. You must believe there is always a level of support and process needed for people to do their best work.

When Takt boards show a trade falling behind, the question is not: why is this foreman incompetent? The question is: what process failure created this delay? Did make-ready planning miss a constraint? Did procurement delay materials? Did another trade fail to complete their handoff? Did the sequence need adjustment? Focus on process first. If behavior is the issue, address behavior directly. But never assume people failed. Assume the system failed them first. And fix the system. This builds trust. Creates psychological safety. And enables teams to surface problems proactively instead of hiding them out of fear of blame. Visual systems only work when teams trust that surfacing problems leads to solutions instead of punishment.

Why Latency Kills Projects and How to Eliminate It

Latency compounds problems exponentially. A one-day delay today becomes a three-day delay next week becomes a two-week delay next month. Because construction work is interconnected. One trade’s delay cascades to downstream trades. Access conflicts multiply. Coordination failures compound. And small problems metastasize into catastrophes. The only defense is immediate visibility and rapid response. See problems when they are small. Act before they compound. And prevent disasters instead of recovering from them. This requires systems with minimal latency. Not data systems requiring collection, processing, and analysis. Visual systems showing reality immediately at the Gemba.

Eliminate latency by putting decision-making at the Gemba. Not in corporate offices reviewing dashboards. At the jobsite where superintendents and foremen see reality directly. Use visual boards updated daily showing planned versus actual status. Takt boards. Last Planner boards. Scrum boards. Any visual system that makes problems obvious without analysis. Hold coordination meetings at the Gemba. Not in conference rooms. At the location where work happens. Where teams can point to actual conditions instead of describing them abstractly. Empower teams to make decisions within five hours of identifying problems. Not escalate to corporate. Not wait for schedulers to analyze. See problem. Decide solution. Implement. Move on. This requires trust. Autonomy. And systems designed for speed instead of control.

The research is clear. Teams that act within five hours have 42% success rates instead of 26%. Failures drop from 21% to 8%. And the primary difference is latency. How quickly problems get identified, decided upon, and corrected. CPM creates latency by design. Complexity hides problems. Data lag delays identification. Corporate review slows decisions. Visual systems eliminate latency by design. Problems surface immediately. Teams see them at the Gemba. And they act. That is why Takt, Last Planner, and Scrum outperform CPM. Not because they are magical. But because they reduce latency from months to hours. And in construction, hours matter.

The Challenge

Walk onto your project tomorrow and ask: how long does it take us to notice when trades fall behind? If the answer is “when the schedule update shows it next week” or “when dashboards flag it next month,” you have a latency problem. And latency kills projects. Switch to visual systems. Takt boards showing zones and trade flow. Last Planner boards tracking weekly commitments. Scrum boards managing sprint work. Any system that makes problems visible immediately at the Gemba instead of hiding them in data waiting for analysis. Hold coordination meetings at the jobsite. Not in conference rooms. Where teams can see actual conditions. Point to actual work. And make decisions based on reality instead of reports.

Empower superintendents and foremen to act within five hours of identifying problems. Not escalate. Not wait for corporate approval. See problem. Call meeting. Decide solution. Implement. Done. This requires courage. Trusting field teams to make decisions. Giving them authority to adjust plans. And accepting that speed matters more than perfect analysis. Because by the time you perfectly analyze a problem, it has compounded into something ten times harder to fix. Better to act quickly on eighty-percent information than perfectly on two-month-old data. The research proves it. 42% success versus 26%. 8% failure versus 21%. And the difference is latency.

As Toyota teaches: “Go and see for yourself to thoroughly understand the situation.” That is seeing at the Gemba. Not reviewing dashboards. Not analyzing reports. Going to the actual place of work. Seeing reality directly. And acting immediately when problems surface. Because construction rewards teams that reduce latency. That see problems in hours instead of months. That act within five hours instead of two months. So go. See. Act. And watch your success rates climb while your failure rates plummet. Because seeing at the Gemba is not optional. It is essential. On we go.

Frequently Asked Questions

What is the Gemba and why does it matter for construction scheduling?

Gemba is Japanese for “the actual place of work”—the jobsite where work happens. Seeing at the Gemba means making decisions based on direct observation of reality instead of reports filtered through data systems with latency.

What is latency in construction project management?

Latency is the delay between problem occurrence and action. Teams using CPM have weeks or months of latency. Teams using visual systems (Takt, Last Planner, and Scrum) have hours or days enabling faster problem resolution.

What are the project success rates for CPM versus agile methods?

Traditional CPM methods achieve 26% success with 21% failures. Agile methods (Scrum, Last Planner) achieve 42% success with 8% failures. The primary difference is latency in problem identification and resolution.

Why is five hours the threshold for problem resolution?

Research shows teams that identify and begin correcting issues within five hours have dramatically higher success rates. Problems compound exponentially, one-day delays become week-long delays that become catastrophic without rapid response.

What must visual scheduling systems accomplish to reduce latency?

Systems must be visual, bring problems to surface immediately, show clearly what problems are, be easily understood and checked, be actionable and fast, be reliable, and enable immediate action rather than delayed corporate analysis.