THE REAL VALUE OF WORK

"Do we have any idea how big it is? And is it getting better or worse?"

Bring up maintenance debt in a leadership room and people get it right away. They picture the recurring bad actors, the inspections that keep sliding, the emergency jobs that torched last year's budget. Heads nod. Somebody says, yeah, we're definitely carrying some.

Then comes the hard question above. And that's where a lot of organizations stall. The idea lands, but nobody knows how to see it or track it, so they assume they need a complex model, new software, or a team of analysts.

You don't. You need a small set of simple, honest indicators that put numbers to what your frontline people already feel. You won't capture every nuance. You'll capture enough to steer.

Maintenance debt is messy by definition. It's the work you deferred, the work you did poorly, the work that never made it into the system, and the data and capability gaps that make the next job harder. You will not boil that into a single clean figure, and you don't need to.

What you want are indicators that line up well with risk and future pain, stay simple enough for planners, supervisors, and techs to understand, and can be tracked over time without heroic data work. The reliability world already hands you a head start. Deferred work reliably drives up failures, downtime, and cost, and a high share of reactive work runs three to five times more expensive than the same work done as planned. Build on that. Five indicators will get you a working maintenance debt dashboard.

Aged backlog by criticality comes first. Forget total backlog hours. Look at how much overdue work sits on your high-criticality assets, your C1 and C2 tags, and how long it's been overdue: past 30, 60, or 90 days. When critical work has been overdue for months, you're staring straight at backlog debt. You don't need a perfect criticality study to start. Even a rough A, B, C split beats treating all backlog as equal, because it separates "overdue on things that matter" from "overdue on stuff that doesn't."

Reactive versus planned work ratio is the second. What share of your work orders are emergency or reactive, and what share are planned and scheduled? A heavy reactive share is the classic fingerprint of debt. Skip proactive maintenance long enough and the assets force you into reactive mode anyway. And since reactive work carries that three-to-five-times cost penalty, a high reactive share doesn't just mean you're carrying debt. It means you're paying steep interest on it. Don't fuss over the exact target. Watch the direction. If you're at sixty or seventy percent reactive today, trending toward thirty-five is the win.

PM deferral patterns are the third. Split your PMs into done on time, done late, and skipped, then break that down by system or asset class. A single PM-compliance percentage hides the story. Break it apart and the debt jumps out: the systems where deferral has quietly become routine, whether you're deferring the high-risk tasks more than the rest, and whether the deferrals are climbing or falling over time. Some deferral is always going to happen. You just want to know where it's turned into a habit.

Repeat failures are the fourth. Count the assets and tags that fail more than once inside a twelve-to-twenty-four-month window, or rack up repeat work orders for the same issue. Repeat failures tell you the root cause isn't being touched, the fixes are partial or temporary, and the asset is running close to the edge. In debt terms, they're interest payments. You keep paying for the same problem. Plot them by system and your quality, scope, and capability debt light up right where they're concentrated.

Data quality on completed work is the fifth, and it's the multiplier. Pull a sample of closed work orders and ask three plain questions. Is there a meaningful failure code? Is the cause clear? Do the comments say what was actually found and done? Turn it into one number: the percentage of completed work orders that clear a minimum data-quality bar. When that number is low, you're flying half-blind, and that inflates every other kind of debt because nobody can see the patterns. Push it up and you hand planners and engineers the context they need to kill repeat failures and design better maintenance, which pays the debt down directly.

You don't need more than a single sheet to give leaders and crews a working view. Picture a dashboard with:

You're not monetizing debt down to the dollar. You're trying to see three things: where it's concentrated, whether it's growing or shrinking, and whether your improvement work is actually moving it. Because every one of these indicators is grounded in daily reality, what's overdue, how you're executing, how often things fail, and what you write down, the people on the floor will recognize them as legitimate instead of dismissing them as another abstract metric.

One warning. Turn these into blunt targets and start punishing people when the numbers look bad, and they'll become one more set of figures to game. You'll have spent real effort building a dashboard that lies to you.

The value isn't in the chart. It's in the conversations the chart forces. Why is critical backlog growing in this unit, and what's actually in there? Why did reactive work creep up last quarter? Why do we keep deferring this class of PMs, are they badly designed, or are we just under-resourced? Why do these assets keep failing, and what haven't we learned yet? Why is our data quality low, do people lack the time, the training, or fields worth filling in? Used that way, the indicators stop being a scorecard and start being a way to focus resources and justify the investment. That's the work we tend to do with clients: not handing them a fancier model, but standing up a handful of honest measures and then helping them act on what those measures keep pointing at.

You don't need a PhD, a new platform, or an analytics team to get a grip on maintenance debt. You need five indicators you can pull from systems you already own: aged critical backlog, reactive ratio, PM deferral patterns, repeat failures, and data quality.

None of them is perfect. Together they're directionally honest, and directionally honest beats precisely blind every time. Track them, talk about them, and you've turned a gut feeling into something you can manage on purpose.

Next in the series, we widen the lens from one plant to many. A dashboard works fine at a single site. But run maintenance across a fleet of plants with different cultures, different maturity, and different ideas of "normal," and complexity takes on a whole new shape.