Two plants. Same industry, similar size.

The first proudly reports a 20,000-hour backlog. It sounds like a mountain of demand, a clear case for more people and more budget. And yet week after week, that plant can't build a weekly schedule it can actually execute. Priorities shift. Jobs fall through. The mountain never seems to shrink.

The second carries eight thousand hours. Less than half the pile. And it executes a stable, believable schedule almost every single week.

So which plant is in better shape? The one with the smaller number, easily, and it isn't close.

The difference isn't the backlog size. It's what each plant means by the word. One has a genuine work queue: ready work, sorted and prepared, waiting for a slot. The other has a giant undifferentiated list that mixes real demand with noise, and calls the whole thing a backlog.

The most misleading number in maintenance is the open work-order count.

It's easy to pull, easy to report, and almost meaningless on its own. A backlog of four hundred work orders tells you nothing about how much labor they represent, which crafts they need, which assets they touch, how urgent they are, or whether a single one of them is ready to execute. Four hundred could be four hundred hours or forty thousand. It could be all electrical or all mechanical. It could be mostly stale requests nobody will ever action, or a tight list of prepared jobs waiting on a window.

Count the work orders, and you've measured the length of the list. You've learned nothing about the work. Seasoned planning and scheduling guidance says the same thing: track backlog in labor hours, by priority, craft, area, and equipment, not as a raw count, because those are the dimensions that tell you what you're actually holding and whether you can act on it.

Part of the confusion is that we lump work orders at completely different stages of life together.

A piece of work moves through a lot of states before it's done. It gets requested and screened to decide whether it's real and worth doing. Prioritized against everything else. Scoped, so the actual work is defined and planned, with steps, labor, parts, and resources. Made ready, once materials, access, and permits line up. Scheduled, committed to a time and a crew. Executed. Closed. And, if you're doing it right, you learn from it so the next one goes better.

A healthy backlog holds work at all of those stages, but it never pretends they're the same. A brand-new request nobody has looked at yet, and a fully prepared job waiting on an outage window are both "in the backlog," and they couldn't be more different. One is a question. The other is a commitment waiting to happen.

The single most useful line you can draw through a backlog is this one: ready to schedule, or not.

Work is ready to schedule when the scope is clear, labor and duration are estimated with some confidence, materials are identified and available, access and the operational window are understood, permits and safety controls are known, and the tools and any special support are accounted for. Not perfect. Not gold-plated. Just resolved enough that a crew could execute it without a pile of preventable discovery work.

Everything else is not ready, and that's fine, as long as you know it. Unready work isn't bad work. It's just work that still needs something before it can be committed. The failure isn't having unready work. The failure is not knowing which is which, then trying to build a weekly schedule from a pile where ready and unready look identical.

Aged work needs its own discussion, separate from fresh demand.

A work order that's been sitting for a year is telling you something. Maybe it's genuinely low priority and keeps losing the fight for resources, which is a legitimate, if uncomfortable, answer. Maybe it's a real risk that keeps getting ignored. Maybe the scope is now obsolete because the asset changed. Or maybe nobody actually owns it, so it just drifts. Whatever the reason, aged work rarely resolves itself by sitting in the same pile as this week's new requests. It needs a deliberate look: still valid, still needed, still scoped correctly, or time to close it out honestly.

A real backlog also sorts work by type, because the different kinds carry different urgency and different risk. At minimum, you're usually holding:

Lump all of that into one number and you can't reason about it. Sort it, and the backlog starts telling you where your risk is, what's coming, and what you're quietly choosing not to do.

Then there's the part of the pile that shouldn't count at all.

Most large backlogs carry false backlog: duplicate requests for the same problem, stale items overtaken by events, work orders whose scope is obsolete because the equipment or situation changed, and orphan jobs nobody owns and nobody will ever action. Left in the count, all of it inflates the number, distorts your reporting, and hides the real work underneath. A twenty-thousand-hour backlog with a third of it false isn't a twenty-thousand-hour backlog. It's a messy thirteen thousand wearing a scary costume.

This is usually one of the first things we help a client untangle, because it's fast and it's clarifying. Clean out the false backlog, sort what's left by type and readiness, and separate the aged work into its own conversation. Almost always, the pile shrinks, the real demand comes into focus, and the team can finally see what they're actually holding, instead of a number that just makes everyone anxious.

A backlog is not a pile of work. It's a portfolio of decisions waiting to be made well: what's real, what's ready, what's urgent, what's aged out, and what you're choosing to defer. Treated as a single number, it tells you almost nothing and quietly misleads everyone who looks at it.

The plant with twenty thousand hours it can't schedule isn't stronger than the plant with eight thousand it can. It's just carrying more fog. The work that matters, the ready, prioritized, executable work, is your real queue. Everything else is demand at different stages of becoming real, and it deserves to be labeled honestly.

Next in the series, we take on a word that causes as much trouble as backlog: planned. Because a job can carry a planner's name and a scheduled date and still fall apart the moment a crew tries to execute it.