Turning Variances Into Opportunities for Improvement

Why Variance Categories Fail, and How to Fix Them

Here’s the deal. The Last Planner System deserves real credit for pioneering something valuable, the idea that when a commitment gets missed, you actually do a root cause analysis to understand why. That is a genuinely good instinct. The way most teams have implemented it since then has a real problem, and it is not the concept itself. It is the language we use to categorize the reason.

Why Percent Plan Complete Is Not the Metric You Think It Is

Before getting to variances specifically, it is worth being honest about Percent Plan Complete, one of my least favorite KPIs in this entire industry. It is a lagging indicator, meaning it tells you what already happened rather than helping you see what is coming.

It also locks you inside a weekly work plan with what is called a lock line, and that creates a real problem. If something genuinely needs to change the day before, you should be able to change it, and you should not be penalized for making that call. PPC actively penalizes stopping the train of trades to use a workable backlog, one of the legitimate recovery strategies available in a Takt system, which means it discourages exactly the flexible response that good Takt planning is supposed to enable. On top of that, PPC tracks every single activity indiscriminately, not just the ones sitting on the actual path of critical flow, so it does not even tell you whether your project genuinely has flow. In practice, I have never seen a project team dig deep enough into root cause analysis, using this metric, to actually identify a real variance and a real corrective measure.

The Real Value Hiding Inside Variances

Here is the part worth taking seriously. Turning variances into something genuinely foreseeable and preventable is valuable, and it can become a real leading indicator, specifically in the form of a roadblock removal average, tracking how consistently your team catches and clears roadblocks before they ever touch the work. That is worth building toward. The problem is that the way variances typically get categorized actively works against people actually using them honestly.

Why People Will Not Honestly Report the Real Reason

Here is the pattern that got me thinking about this. Standard variance categories are simply not built in a way human beings actually want to acknowledge. Several of the most common categories are quietly negative, and negative in a specific way, they ask someone to admit fault, either their own or someone else’s.

Bad planning blames the planner directly. Prerequisite work not done effectively tattles on another trade or party. Design issue blames the designer. Failed inspection implies the trade underperformed ahead of time. Compare those against categories like labor not available, materials not available, equipment not available, contract change orders, or submittal delays, all of which feel genuinely neutral, describing a condition rather than assigning blame to a person.

Watch for these signs your current variance tracking is producing dishonest or incomplete data:

• The same neutral categories, materials, equipment, labor, getting selected repeatedly while blame-adjacent categories almost never appear.
• Root cause conversations that stop short of naming the actual underlying issue.
• Variance logs that read as complete on paper but never actually change future planning behavior.

Why This Specifically Conflicts With How We Are Wired

There is a real cultural dimension here worth naming honestly. The first four categories genuinely conflict with common cultural instincts, particularly in the United States, around kindness and not placing blame. We generally want to see ourselves as kind people, and from a religious standpoint too, many people do not want to identify as being unkind toward a colleague or a trade partner, even in something as small as a variance log entry.

That means a category structure built around admitting fault runs directly against how people are inclined to see themselves, which makes it far less likely anyone will select those categories honestly, even when they are the actual truth. The result is a variance log that looks complete but quietly misrepresents what is actually happening on the project.

The Fix: Two Changes That Actually Work

There are two specific changes worth making, and both matter.

The first is timing. Stop treating variance analysis as something that only happens after the fact, looking backward at what already went wrong. Look for these conditions before they impact the work, the same discipline behind identifying and removing roadblocks early rather than discovering them once a zone is already delayed.

The second is language. Reframe the categories entirely around neutral, system level conditions instead of assigning fault to a person or party. Instead of bad planning, describe it as changes to the plan or planning incomplete. Instead of prerequisite work not done, describe it as work area not ready. Add categories like permissions needed, layout not currently ready, something in the way, defects, missing information, missing resources, equipment issues, labor shortage, and site conditions. Failed inspection can be softened somewhat too, described in terms of the condition rather than the performance judgment behind it.

None of these categories ask anyone to admit they personally failed. They describe a condition, a system, or a process problem, which is exactly the framing that lets people report honestly without triggering the instinct to protect their own identity or someone else’s.

Why This Reframing Is Not Just Softer Language

This is not about being gentle for its own sake. It is about accuracy. A variance category structure that people will not honestly use produces a variance log that quietly hides the real information a project delivery team actually needs. Blame the system and the process, not the person, and you get data people will actually report truthfully, which is the only kind of data that can genuinely drive a leading indicator like a real roadblock removal average.

I want to be direct that I genuinely appreciate the Last Planner System and the organizations behind it. I have simply never liked the traditional variance list itself, and I think the industry, including the software tools and other Lean practitioners building on top of this concept, would benefit from shifting toward this neutral, roadblock-oriented framing, and toward catching these conditions before they impact work rather than only analyzing them afterward.

Building This Into Your Own Project

If your project needs superintendent coaching, project support, or leadership development, Elevate Construction can help your teams build a variance and roadblock tracking system that people will actually use honestly, tied to catching conditions before they impact work rather than analyzing them only in hindsight.

So here is the challenge. Pull your own current variance log and look at the category distribution. If a handful of neutral categories dominate the list while blame-adjacent ones almost never appear, that pattern itself is data, not an absence of problems. It likely means your team is not reporting honestly, not that those problems genuinely never happen. Switching to neutral, condition-based language is worth trying specifically to see whether the honest picture underneath actually changes.

Jason Schroeder said it plainly: “Variances are not set up for human beings to actually want to acknowledge.” Fix the language, fix the timing, and the honest data underneath finally becomes visible.

On we go.

FAQ

Why is Percent Plan Complete considered a weak metric for measuring project flow?

Because it is a lagging indicator that reports what already happened rather than predicting what is likely to happen next, and it tracks every activity indiscriminately rather than focusing on the activities that sit on the actual path of critical flow. It also penalizes legitimate recovery strategies, like stopping the train of trades to use a workable backlog, which discourages exactly the flexible response a well built Takt system is designed to allow.

Why do people avoid honestly selecting variance categories like bad planning or failed inspection?

Because those categories directly ask someone to admit personal fault, either their own or someone else’s, which conflicts with a common cultural instinct to see oneself as kind and non-blaming. That reluctance leads to those categories being underreported even when they accurately describe what actually happened, which quietly distorts the entire variance log.

What does it mean to switch variance categories toward “neutral roadblock” language?

It means describing the underlying condition, such as work area not ready, missing information, or equipment issues, rather than assigning fault to a specific person or party, such as bad planning or prerequisite work not done. The neutral version communicates the same underlying problem without triggering the identity protective reluctance that keeps people from reporting fault-based categories honestly.

Why does catching variances before they impact work matter more than analyzing them after the fact?

Because a variance analyzed after the fact has already cost the project real time and money, while a condition identified before it impacts work can often be resolved with a phone call or a quick adjustment. Shifting the discipline earlier, the same way roadblocks get identified and removed before they touch the schedule, prevents the delay entirely rather than simply explaining it after it has already happened.