Preventive Maintenance KPIs and Schedule Compliance

There is a particular slide I have seen in more monthly maintenance reviews than I can count. PM compliance: ninety-something percent, green. Everybody nods. Nobody asks a question. And in the plant outside the meeting room, the same three pumps keep failing, the backlog keeps ageing, and the emergency call-outs have not moved in two years. The number is not a lie exactly. It is a number that has been made to look good, by people responding rationally to the way it was defined and the way it was used. That gap, between the metric and the reliability it is supposed to represent, is what this guide is about.

The message up front: every preventive maintenance KPI in common use can be made to look good without any improvement in reliability. That is not a reason to stop measuring, it is a reason to define each metric tightly, pair it with a counter-metric that detects the gaming, keep the set small enough that people actually use it, and review it in a way that asks why rather than who. A KPI set you cannot game is not achievable. A KPI set where gaming is visible is.

1. What PM KPIs are actually for

Before defining anything, it is worth being precise about the purpose, because most KPI sets fail at this first step. A preventive maintenance KPI exists to answer one of three questions, and the three are not interchangeable:

• Are we doing the planned work? This is execution: schedule compliance, completion rate, labour utilisation. It tells you whether the plan you wrote is actually happening on the floor.
• Is the planned work the right work? This is programme quality: PM yield, the ratio of planned to reactive work, repeat failures on assets under an active PM. It tells you whether the tasks you are diligently completing are worth completing.
• Is reliability actually improving? This is outcome: mean time between failures, unplanned downtime, emergency work percentage, cost per asset. It tells you whether any of the above is producing the result the whole programme exists for.

Most maintenance organisations measure the first category obsessively, the second barely at all, and the third only when something has gone badly wrong. That imbalance is the root cause of the ninety-percent-compliance-with-unchanged-failures problem. Execution metrics are easy to collect from the CMMS, easy to report, and easy to influence. Outcome metrics are slower, noisier and less flattering. So the reporting drifts toward the easy end and stays there.

If you are building a measurement set from scratch, the sequencing I would recommend is to define at least one metric in each of the three categories before adding a second metric to any of them. A balanced set of six beats an execution-heavy set of twenty. The broader structure for this sits in the FM KPI framework, and the method for connecting a floor-level metric up to a business outcome is covered in building a KPI tree.

2. PM schedule compliance, and the definition fight

Schedule compliance is the headline PM metric almost everywhere, and it is also the one where the definition argument matters most. There are two competing definitions in circulation, and organisations routinely report one while believing they are reporting the other.

Definition A, completed in window: a PM counts as compliant only if it was completed within its scheduled window, typically expressed as the due date plus or minus a tolerance. A PM due on the 5th and completed on the 27th is not compliant, even though it was done.

Definition B, completed at all: a PM counts as compliant if it was closed within the reporting period, regardless of when in that period it happened. A monthly PM due on the 5th and closed on the 30th is fully compliant.

Definition B is far more common in practice, and it is far weaker. It measures whether work eventually got done, not whether the maintenance interval was honoured. The entire engineering basis of a preventive interval is that the task happens at roughly the frequency the failure mode requires. A quarterly task performed twice in quick succession and then not again for five months satisfies Definition B and completely fails the engineering intent. If you have ever wondered why compliance is high and interval-related failures persist, this is usually where it starts.

The workable formulation I would recommend is Definition A with an explicitly stated, interval-proportional window. Something like: a PM is compliant if completed within a tolerance of plus or minus ten percent of its interval, so a thirty-day PM gets a three-day window and a 365-day PM gets a wider one. The percentage is a policy choice, not a law of nature, but the principle, that tolerance scales with interval rather than being a flat number applied to everything, is what makes the metric mean something. A flat seven-day window is generous on a weekly PM and meaningless on an annual one.

3. PM completion rate, and why it is not compliance

Completion rate and schedule compliance are frequently used as synonyms, which causes real confusion. They measure different things and they should both be on the board.

PM completion rate is completed PMs divided by scheduled PMs in the period, with no timing condition. It answers: of everything we planned, how much got done? It is the volume question.

PM schedule compliance is PMs completed within window divided by PMs scheduled. It answers: of everything we planned, how much got done on time? It is the discipline question.

Completion rate will always be equal to or higher than compliance. The gap between them is genuinely informative. A small gap means the work is being done broadly when it should be. A large gap means the work is getting done, but late and probably in a rush at period end, which usually correlates with thinner execution quality. I would report both, side by side, and treat the gap itself as a signal. A widening gap between completion and compliance is one of the earliest indicators that a planning function is losing control of its schedule.

Both metrics also depend entirely on a clean work order taxonomy. If your CMMS cannot cleanly separate a PM from a corrective from an emergency from a project task, neither number means anything. The work order type structure that makes this possible is covered in work order types in a CMMS, and it is worth getting right before you start reporting anything.

4. Planned versus reactive work ratio

The proportion of maintenance labour hours spent on planned work versus reactive work is the single best one-number summary of maintenance maturity. A team in control of its assets spends most of its time on work it chose to do at a time it chose to do it. A team out of control spends its time responding.

You will find a figure of around eighty percent planned work quoted widely as the target, sometimes attributed to reliability literature, sometimes just repeated as received wisdom. Treat it as a commonly quoted rule of thumb and nothing more. It varies enormously by sector, asset mix, asset age and operating regime. A modern data centre with redundant plant and a hard change-control regime will sit very differently from a twenty-year-old mixed-use property portfolio with high tenant-driven demand, and both can be well run. The useful question is not "are we at eighty percent" but "is our ratio moving in the right direction, and do we understand why it sits where it does". Adopting somebody else's benchmark as a target handed down from above is one of the more reliable ways to trigger the reclassification gaming described later in this guide.

Two practical notes on the calculation. First, measure it in labour hours, not work order counts. A hundred small planned inspections and two long emergency repairs is not an easy call by count and is an obvious one by hours. Second, decide explicitly whether planned-but-corrective work counts as planned. My view is that it should, because the distinction that matters operationally is whether the work was scheduled and resourced in advance, not whether it originated from a PM. But whichever way you decide, write the definition down, because this is exactly the kind of ambiguity that gets exploited when a target is attached.

5. PM yield: the metric almost nobody runs

PM yield, sometimes called the find rate or PM effectiveness, is the proportion of preventive maintenance tasks that generate a corrective action: a follow-up work order, a defect raised, a part replaced outside the routine scope. It is the closest thing the maintenance world has to a direct measure of whether a PM task is worth doing, and very few organisations calculate it.

What makes it powerful is that it is bad news at both ends of the range, which forces a genuine conversation rather than a target chase.

• Very low yield means the PM almost never finds anything. Either the task is inspecting for a failure mode that does not occur on this asset, or the interval is far shorter than the degradation actually requires, or, uncomfortably, the task is being closed without being performed. All three are worth knowing, and the third is the one people do not want to look at.
• Very high yield means the PM finds a defect nearly every time. That sounds like a successful PM, and sometimes it is, but more often it means the interval is too long and you are consistently catching degradation late, or the asset is in a condition that warrants a different maintenance strategy altogether, or the operating environment has changed and the task has not been revisited.

I would not set a numeric target for yield. I would set a review trigger: any PM task whose yield sits in the extreme low or extreme high band for two consecutive review cycles gets pulled into a task review, where an engineer decides whether to change the interval, change the scope, or retire the task. That is the mechanism that keeps a PM programme from calcifying, and it is described in more depth in PM programme design: quality over quantity.

The prerequisite for measuring yield at all is that follow-up work is actually raised and linked back to the parent PM. If technicians fix small findings in-line and never record them, your yield will read near zero on tasks that are working perfectly well. Consistent defect capture and failure coding is what makes this metric possible, and it is the usual reason organisations cannot produce it.

6. The PM KPI definition table

This is the centrepiece of the guide. For each metric: the formula, what a healthy pattern looks like in plain language rather than a benchmark number, and the specific way I have seen it gamed. Read the last column first.

Nothing in that last column is exotic. Every one of those behaviours is something a competent, well-intentioned person will do when a number they cannot fully control is attached to their performance review. That is the framing that matters: gaming is usually a rational response to a badly designed measurement, not a character failing. Design the measurement better and most of it disappears.

7. How PM metrics get gamed, and what to do about it

The table above is the summary. This section is the detail, because the counter-measures are where the practical work lies. These are the six patterns I see most often.

Closing PMs without doing them. The most direct form, and the hardest to detect from the CMMS alone, because a closed PM looks identical whether it was performed or not. Counter-measures: require meter readings, measured values or photographs on tasks where they are meaningful, so closure carries evidence; run a sampling audit where a supervisor physically verifies a small random percentage of closed PMs each month; and watch completion timestamps, because forty PMs closed by one technician in a single afternoon is a pattern the system can flag for you.

Widening the compliance window. Quieter and much more common. Nobody falsifies anything; the tolerance is simply relaxed until the number comes right. Counter-measure: treat the window as a controlled parameter with an owner, a documented value and a change log, and report compliance at both the current window and a fixed reference window so any change in the definition is visible in the trend rather than hidden in it.

Reclassifying reactive work as planned. Where a planned-ratio target exists, this follows. An emergency repair gets a planned work order raised for it the same morning, and the ratio improves without anything changing on the floor. Counter-measure: define planned as scheduled at least a set period in advance, commonly the start of the current week, and calculate the ratio from the work order creation timestamp rather than its type field. A work order created and completed on the same day is reactive regardless of what it is labelled.

Splitting or merging work orders. Counts-based metrics invite this from both directions. Splitting one job into five raises completion counts; merging five jobs into one lowers backlog count and can shorten reported MTTR. Counter-measure: base metrics on labour hours rather than counts wherever you can, and monitor the average hours per work order as a control chart. A sudden shift in average job size, with no change in the work itself, is the signature.

Deferring rather than failing. A PM about to breach its window is deferred, rescheduled or moved to a hold status, so it never registers as missed. It is the single most common form of compliance inflation because most CMMS platforms make it a two-click operation. Counter-measures: make deferral a controlled transaction requiring a reason code and an approval above the person performing the work; report deferral volume and deferral reasons as a first-class metric alongside compliance; and cap the number of times a single PM instance can be deferred before it escalates automatically.

Selective scoping. Assets or task types that persistently fail their targets are quietly moved out of the reported scope, into a separate register or a category the report excludes. Counter-measure: report the denominator, always. Compliance of ninety-four percent on 1,200 PMs is a different statement from ninety-four percent on 700, and if the denominator is moving, that is the first thing to explain.

8. Leading and lagging indicators

The distinction is worn out from overuse in management literature, but it earns its place in maintenance because the two types behave so differently under pressure. A leading indicator measures an input you control now and believe will produce a result later. A lagging indicator measures the result itself, after the fact.

The rule I would apply: never review a leading indicator without the lagging indicator it is supposed to drive in the same field of view. Schedule compliance on its own is an activity report. Schedule compliance next to unplanned downtime and emergency work percentage is a reliability conversation. If compliance is climbing and downtime is flat over several quarters, one of two things is true: the PM tasks are not addressing the failure modes that actually cause your downtime, or the compliance number is not real. Both are worth a serious hour of management attention, and neither is visible if you only look at the leading metric.

9. Why more than about eight KPIs stops working

There is a practical ceiling on how many metrics a maintenance team will genuinely use, and it is considerably lower than the number most CMMS platforms will happily generate. My working rule is around eight for an operational review set. That is not a scientific finding, it is an observation from sitting in a lot of these meetings, but the mechanism behind it is straightforward.

• Attention is the binding constraint. A monthly review has perhaps an hour. Eight metrics allow a few minutes each and time to discuss the two that moved. Twenty-five metrics means each is read aloud and none is discussed.
• Large sets always contain contradictions. Cost per asset pushes down, PM coverage pushes up, compliance pushes toward volume, yield pushes toward selectivity. With eight metrics the tensions are visible and can be argued out. With twenty-five they are invisible, and the team resolves them privately by choosing which ones to care about, which is the same as you not having chosen.
• Dilution destroys accountability. When everything is measured, nothing is owned. Eight metrics with eight named owners produces action. Twenty-five metrics owned by "the maintenance team" produces a report.
• Reporting cost is real. Every metric that is not automatic consumes planner or analyst time to compile. Time spent assembling a metric nobody acts on is time not spent planning work.

A defensible eight-metric operational set, as a starting point rather than a prescription: schedule compliance, completion rate, planned work ratio, PM yield, backlog in crew-weeks, backlog ageing beyond ninety days, emergency work percentage, and unplanned downtime hours. Everything else becomes diagnostic, pulled on demand when one of the eight moves and you need to understand why. That distinction, between a standing review set and a diagnostic library, is what lets you keep the review short without losing analytical depth. Where a platform makes it easy to pin a small set to the front page, as Maximo does with its start centre concept covered in Maximo start centres and KPIs, use that constraint deliberately rather than filling every available portlet.

10. The data foundations that have to exist first

None of these metrics survive contact with poor source data, and this is where I would spend the first month of any KPI programme rather than on dashboard design. The prerequisites, in rough order of how often they are missing:

• A clean work order type taxonomy. PM, corrective, emergency, project, statutory, tenant request. Unambiguous, mutually exclusive, and enforced at creation rather than corrected later.
• Labour hours actually recorded. Any ratio expressed in hours is fiction if timesheeting is patchy or estimated at closure. This is the most common single blocker to a credible planned-work ratio.
• Correct asset linkage. Work orders raised against a location rather than an asset make MTBF, cost per asset and repeat-failure analysis impossible. Location-level work is endemic in facilities maintenance and quietly disables half the metric set.
• Failure coding at closure. Problem, cause and action, applied consistently. Without it there is no repeat-failure analysis and no way to test whether a PM addresses the failure modes actually occurring.
• Honest due dates. If PM due dates were loaded at go-live and never rebaselined, the compliance denominator is measuring an obsolete plan. The build discipline behind this is covered in how to build a preventive maintenance schedule.
• A defined reporting period and cut-off. Sounds trivial. It is the source of an enormous amount of argument when two reports disagree because one runs to the calendar month and the other to a four-week cycle.

A useful diagnostic before you commit to any KPI: take last month's data and calculate the metric by hand for a single asset group. If you cannot, because the fields are empty or ambiguous, that metric is not ready to be reported, and publishing it anyway teaches everyone that the numbers are decorative. The wider programme context for this sits in PM plans and programmes: a framework, and the fundamentals in the complete guide to preventive maintenance.

11. On benchmarks, targets and borrowed numbers

A short but necessary section, because the most damaging thing done to maintenance KPIs is the import of a number from somewhere else and its installation as a target.

Figures circulate: a planned-work ratio somewhere around eighty percent, a schedule compliance figure in the nineties, a wrench-time figure that varies wildly depending on who is quoting it. These are commonly quoted rules of thumb. Some trace to real studies in specific industries decades ago; others are simply repeated until they sound authoritative. Every one of them varies by sector, asset mix, asset age, climate, contract model and operating pattern, and none of them should be adopted as a target handed down from above. A portfolio of ageing mixed-use buildings in a harsh climate with a reactive-heavy tenant base is not comparable to a new-build pharmaceutical facility, and holding both to the same number produces reclassification in one and complacency in the other.

What I would do instead: establish your own baseline over at least two full quarters with the definitions locked, then set improvement targets relative to that baseline. Use external figures as a sanity check on direction, a prompt to ask why you sit where you do, and a starting point for discussion. Never as the number the team is held to. If a benchmark is genuinely needed for a contract or a board, cite its source, state its industry, and say plainly that it is indicative. For the related question of how contractual performance targets get set and misused in service agreements, see SLA matrix design for FM operations.

The standards world is more useful here than the benchmark world. ISO 55000 asset management gives you a structure for connecting asset decisions to organisational objectives, and SFG20 gives a maintained library of building services task content and frequencies that is a far better anchor for what your PM schedule should contain than any compliance percentage. Neither hands you a KPI target, which is exactly the point.

12. Building a PM KPI review that changes behaviour

A KPI set is only as good as the meeting it is discussed in. Most PM KPI reviews are reporting events: numbers are presented, colours are noted, nobody's plan changes, and the same slide appears next month. A review that changes behaviour has a different shape.

• Circulate the pack before, discuss only exceptions in the room. Reading numbers aloud consumes the entire hour. Send the pack two working days ahead and open the meeting with the three metrics that moved outside their expected band.
• Ask why before who. The first question on a missed target is "what happened", not "whose is this". The moment the first question becomes attributive, gaming becomes the rational response and your data quality starts degrading from that meeting onward.
• Always show the denominator and the definition. Every metric on the pack carries its formula and its population count in small print. This single habit prevents most quiet scope-shifting.
• Pair every leading metric with its lagging partner on the same page. Compliance next to unplanned downtime. Planned ratio next to emergency percentage. The pairing is what makes the conversation about reliability rather than activity.
• Every exception produces a named action with a date. Not "we will look at the pump PMs" but a person, a specific task list, and a review date. Actions carry forward on the pack until they are closed.
• Review the metrics themselves once a year. Ask of each one: has it changed a decision in the last twelve months? If not, retire it. A KPI that has never caused an action is overhead.
• Include a standing task-review item. Bring the PM tasks flagged by extreme yield, and decide interval, scope or retirement. This is what converts the measurement system into an improving programme rather than a monitoring one.

The cultural point underneath all of this is the one that determines whether any of it works. If missing a target is treated as a personal failure, people will protect themselves by managing the number, and they will be good at it, because they understand the system better than the person reading the report. If missing a target is treated as information about the plan, people will surface problems early and the data stays honest. You cannot engineer your way around this with definitions and counter-measures alone. The definitions raise the cost of gaming; the way the review is conducted determines whether anyone wants to.

The idea to walk away with

PM KPIs do not fail because the formulas are wrong. They fail because a controllable leading indicator was given a target, detached from any outcome measure, and reviewed in a way that made looking good more important than being good. The formulas in this guide are unremarkable and widely agreed. What separates a measurement system that improves reliability from one that produces green slides is three things: definitions tight enough that the number means what it claims, a small enough set that each metric is genuinely discussed, and a review culture where the first question is what happened rather than whose fault it was.

If you do only one thing after reading this, go and check which definition of schedule compliance your organisation is actually reporting. In my experience it is the weak one more often than not, and the conversation that follows from discovering it is more valuable than any dashboard you could build this quarter.

Final thoughts

Measuring preventive maintenance well is not about finding the perfect metric. Every metric in the table above can be made to look good by someone under pressure, and pretending otherwise is how organisations end up trusting numbers they should not. The realistic goal is a set where gaming is visible rather than impossible: definitions written down and version-controlled, denominators always shown, leading metrics always paired with the outcome they claim to drive, and a small enough set that anomalies stand out instead of disappearing into a twenty-page pack.

Start with the definition of compliance, because everything else inherits its credibility from that one. Add PM yield, because it is the metric that tells you whether the work is worth doing and almost nobody runs it. Keep the operational set to around eight. Review the metrics themselves annually and retire the ones that have never changed a decision. Done that way, a PM KPI pack stops being a monthly formality and becomes the mechanism by which the maintenance programme actually improves, which is the only reason to build one.

Related reading: Preventive maintenance: the complete guide, FM KPI framework, Building a KPI tree, PM programme design: quality over quantity, Work order types in a CMMS, Failure codes: Problem, Cause, Action, Warehouse KPIs.