Key takeaways
PM compliance is everywhere. It is on the wall of every maintenance manager's office, in every monthly report, in every steering committee deck. Its appeal is operational: a number that goes up or down depending on whether the team did the work they said they would. Easy to define, easy to measure, easy to communicate.
The problem is that it answers the wrong question. PM compliance tells you whether the team executed the schedule. It does not tell you whether the schedule itself prevents the things it is supposed to prevent. A plant with 95% compliance and a steady rate of unplanned failures is running a PM program that is working as a scheduling exercise and failing as a reliability exercise.
This pattern is so common that it is almost a default state. The maintenance team optimises compliance because compliance is what they are measured on. The plant manager sees 95% compliance and assumes the reliability problem is something else. Six quarters later the failure data shows that something is not working, but by then the PM program has been treated as solved for so long that nobody questions it.
Effectiveness asks: for the failures we saw in the last 90 days, were the underlying assets ones whose PMs were completed on schedule? If yes, the PM was ineffective, the schedule executed, the failure happened anyway. If no, the PM was the right one but did not happen (a compliance problem). The two diagnoses look the same in aggregate failure data but have completely different fixes.
The math: for each unplanned failure in the period, look up the PM schedule for that asset. If the most recent scheduled PM was completed on time and the failure happened within the PM cycle anyway, count it as an effectiveness failure. If the PM was overdue, count it as a compliance failure.
Many plants are uncomfortable when they first run this: a large share of failures turn out to be on assets where the PM ran on schedule and the failure happened anyway.
Even directionally, that share is usually big enough to imply that a meaningful portion of preventable failures are not actually being prevented by the current PM program. The piece on the preventive maintenance schedule covers the structural changes that finding points to.
Three reasons effectiveness is harder to optimise:
The compliance number is in the CMMS. The failure data is also in the CMMS. The link between them, "this failure happened on an asset whose last PM was X days ago", is one query in a well-structured CMMS and a manual reconciliation in a poorly-structured one. Most plants are in the second camp.
Compliance is a team performance metric. Effectiveness is a program design metric. A low effectiveness number implicates whoever designed the PM intervals and tasks, usually the same engineer or vendor recommendation that has been in place for years. Nobody wants to be the person to say the program needs redesign.
Compliance can change in a week. Effectiveness changes over quarters, because changing PM design and seeing the failure data adjust takes 60-180 days. The slow feedback loop discourages teams from prioritising it. The article on root cause analysis covers the same problem in different terms.
Monthly numbers are too noisy. Quarterly smooths the variance and matches the feedback loop. The quarterly report has two numbers per asset class: PM completion rate (compliance) and PM-precedes-failure rate (effectiveness).
Compliance below about 80% triggers an execution conversation. A persistently high share of failures on assets whose PM ran on time triggers a design conversation. Above the line, leave the metric alone, chasing 99% compliance is a waste of energy when most of your failures are still landing on assets whose PMs ran on schedule.
Compliance is a maintenance manager conversation: do we have the people, the parts and the access to do the PMs we scheduled? Effectiveness is a reliability engineer / plant manager conversation: are the PMs we are doing the right ones? Mixing the two produces confusion and finger-pointing.
A plant-wide effectiveness number averages across PMs that are over-effective (a few) and under-effective (many) and produces a meaningless number. Per asset class, the picture sharpens, usually two or three asset classes account for most of the effectiveness gap. Those become the redesign queue. The piece on manufacturing KPIs covers the per-asset-class metric structure this depends on.
When effectiveness on an asset class is below threshold, the redesign options are typically:
The link to the work order management system matters because the redesigned PM is a new work-order type and needs to be set up cleanly in the system, not as a one-time override.
The compliance metric is in any CMMS. The effectiveness metric requires linking PM execution data to failure events on the same asset, which is straightforward in a unified OEE + CMMS platform and laborious otherwise.
Fabrico is built so the link is automatic, every failure event carries the timestamp of the last completed PM on the asset, and the effectiveness ratio is a quarterly query. To see what the compliance-and-effectiveness picture would look like on your top asset classes, book a demo .
80-90% is the working range. Above 95% usually means the schedule is loose enough that anything would hit it; below 75% means execution is structurally underpowered. The exact number matters less than the trend and the consistency.
There is no published industry benchmark for PM effectiveness the way there is for compliance, so the honest answer is to track your own baseline and watch the trend rather than chase a number.
What matters is direction: the share of failures landing on assets whose PM ran on time should fall over time as the PM designs improve. If that share stays high, a meaningful part of the PM budget is producing no failure prevention.
It helps, but it does not replace the metric. Condition-based interventions are still PMs in this framework; the question is the same, did the intervention prevent the failure or not. CBM done well usually reduces unplanned failures substantially on the asset classes where it is deployed, the published evidence points to materially lower downtime, which is exactly the effectiveness gain the metric is trying to capture.
The reliability engineer if the role exists; the plant manager otherwise. Not the maintenance manager, they own compliance. Separating the two is what makes the program redesign possible.
Reporting effectiveness alongside compliance without separating the conversations. The maintenance manager feels attacked when effectiveness is low, defaults to defending the team's compliance work, and the design conversation never happens. Holding two distinct meetings, execution review and design review, keeps the framework working.