Why Preventive Maintenance Programs Fail: Quality Over Quantity

Ask a maintenance manager how their preventive maintenance program is doing and the answer usually comes back in the form of a number: how many PM work orders they generate a month, how many they close on time, how their PM compliance percentage compares against last quarter. All valid metrics on their own. All completely useless as a measure of whether the PM program is actually preventing failures. This article is the working guide I wish more maintenance leaders had in front of them before they added their next fifty PMs to the CMMS.

The central message, up front: a successful preventive maintenance program is measured by improved reliability, optimised maintenance effort, and efficient use of technician time. It is not measured by the number of PM work orders in the CMMS. Everything in this article works back to that idea.

1. Preventive maintenance is more than creating work orders

This is where I need to start every conversation. PM is a maintenance strategy, not a scheduled work order. Confusing the two is the single most common design flaw I see when auditing CMMS deployments that have been running for years and are not delivering the reliability outcomes the operations team expected.

A well-designed PM program should deliver five outcomes:

• Reduced equipment failures: fewer unplanned events, particularly the high-consequence ones that generate downtime, safety incidents, or regulatory exposure.
• Improved reliability: mean time between failures (MTBF) trending upward on the asset classes that matter operationally.
• Increased asset life: assets reaching or exceeding their design life expectancy, with predictable end-of-life planning rather than surprise failures.
• Optimised maintenance costs: total maintenance spend (labour, materials, contractor callout) trending downward relative to the value of assets under management.
• Improved technician productivity: field team spending more time on maintenance that matters and less time on administrative overhead, travel between locations, and unnecessary inspections.

If your PM program is not moving these five needles, adding more PM work orders will not fix it. The PM count is a lagging indicator of the quality of the underlying strategy. Focus on the strategy.

2. Avoid creating one PM for every asset

The most consequential design mistake in early-stage PM programs. A maintenance planner sees an asset register with five thousand assets and reasons that if each asset needs a monthly inspection, they need five thousand monthly PMs. So they create them. Six months later the CMMS is bloated, the backlog is massive, the field team is drowning, and nobody knows which of the five thousand PMs actually matter.

Consider a typical facility with four identical pumps in the same pump room. The wrong approach:

Four work orders. Four separate scheduling entries. Four sets of parts pulls. Four completion records for the planner to review. Four data points to maintain when the PM interval or checklist changes.

The right approach:

One work order. One scheduling entry. One route the technician walks in sequence. One completion record. One place to maintain the checklist when it needs updating. The benefits compound: less administration for the planner, better route planning for the technician, reduced travel time between assets, higher productivity on the shift, and dramatically cleaner CMMS data downstream. The failure data still lands per asset because the technician's findings on each asset are captured against the specific asset record, but the operational unit is the route, not the asset.

Every serious PM program design starts with this question: what is the natural operational grouping of these assets, and can I build one PM against the group rather than one PM per asset?

3. Group similar assets intelligently

Grouping is the design activity where the leverage sits. Get this right up front and the rest of the PM program builds cleanly around it. Get it wrong and you spend the next three years refactoring PMs one at a time. The dimensions that matter for grouping:

• Equipment type: pumps with pumps, motors with motors, AHUs with AHUs. The checklist and inspection technique are consistent within a type.
• Physical location: assets in the same plant room, riser, floor, or zone. The technician's travel time drops when the route stays local.
• Building or process area: assets serving the same building or the same process area typically have similar operating conditions and often correlate on failure modes.
• Production line or utility zone: assets that share the same process context often need coordinated maintenance windows.
• Maintenance crew: assets typically maintained by the same team. Routes should sit within the accountability of one crew, not span crews.
• Skill required: assets needing the same technician certification (mechanical, electrical, controls, HVAC, high-voltage) sit naturally together.
• Shutdown window: assets that can only be inspected during a plant outage should be grouped so the outage window is used efficiently.

In practice, most PMs group across two or three of these dimensions. A "Monthly HVAC inspection route in Tower B" groups by equipment type, physical location, and building. That is stronger design than grouping by any single dimension alone. (For the underlying asset structuring, see the asset hierarchy design pillar.)

4. Build logical maintenance routes

Once assets are grouped, the next design decision is the route itself. A PM is not a random collection of assets; it is a defined sequence the technician follows, starting at a point, walking a path, and ending at a point. The route matters because technician walking time is not maintenance time. It is pure overhead that no CMMS report will surface unless someone deliberately designed for it.

A well-designed route looks like this on paper:

The technician does not double back. The route uses the natural physical logic of the building. Each asset is inspected in a defined sequence with the correct tools staged for that sequence. When the technician finishes, they log the outcomes for all assets on one work order and return to the workshop.

The cumulative time saving on a well-designed route versus a poorly-designed one is significant. A single site can easily save several hundred technician hours a year just from route design. Across a portfolio of sites, this is the difference between a lean and a bloated maintenance operation. And unlike many optimisation exercises, route design is a one-time investment that pays back for years.

5. Standardise checklists so every technician does the same inspection

A common failure mode: the PM says "inspect pump" and the technician's interpretation varies from a two-minute visual glance to a twenty-minute detailed walkdown, depending on who is doing it and how their shift is going. The result is inspection data that means different things depending on who captured it, which is worse than no data because it looks like reliable data.

The alternative is a structured checklist with specific items to inspect and specific criteria to check:

Every technician performs the same inspection. Every asset gets the same treatment. The data captured is comparable across assets and across time. Reliability engineering downstream becomes credible for the first time because the input data is standardised.

The design discipline: build the checklist once, per equipment type, and reuse it across every PM that inspects that equipment type. Do not rewrite the checklist for each PM. Do not customise it for individual assets unless there is a genuine engineering reason. Standardisation is what gives the data value; local variation destroys it.

6. Estimate standard labour hours (and measure against them)

Every PM should have an estimated labour hours figure attached to it. This is not optional or "nice to have" in a mature program. Without planned hours, you cannot schedule realistically, you cannot measure efficiency, and you cannot know whether the PM design is working operationally.

A simple example:

Now you have real data. The planner can schedule the technician's day realistically. The supervisor can see when routes are consistently running long (route needs redesign) or consistently running short (technician is skipping steps or the estimate was inflated). The reliability engineer can identify PMs whose actual time is drifting upward over quarters (a signal that assets are deteriorating faster than expected).

Estimated hours also unlock the KPIs that matter. Planned vs actual hours, wrench time, planner productivity, and technician utilisation all depend on this single data point being present and reasonably accurate. In every maintenance operation I have improved, one of the first design changes was ensuring every PM had a defensible labour-hours estimate attached.

7. Measure PM effectiveness with the right KPIs

Once the structural design is in place, you need to measure whether the program is delivering. The KPIs that matter for a PM program specifically, drawn from what I actually use in practice:

• PM Compliance: percentage of scheduled PMs completed within their compliance window. Target 90%+ for most operations; 95%+ for statutory compliance work.
• Schedule Compliance: percentage of PMs completed on the scheduled date (not just within the window). Measures planning discipline.
• Planned vs Actual Hours: variance between estimated and actual labour hours. Signal for PM design drift.
• PM Completion Rate: percentage of started PMs that reach completion (versus being suspended, cancelled or partially closed).
• Emergency Work Percentage: reactive work orders as a percentage of total work orders. A healthy PM program drives this down over time.
• Repeat Failures: same failure mode on the same asset within a defined window (typically 30 or 60 days). Rising repeat failure rate is a signal that the PM is missing something.
• PM-Generated Corrective Work: percentage of PMs that identify a defect requiring corrective work. This should be non-zero; if it is zero, PMs are too shallow. If it is 80%, PMs are catching everything but frequency may be too aggressive.
• Mean Time Between Failures (MTBF): the primary reliability metric. Should trend upward on asset classes covered by the PM program.
• Mean Time To Repair (MTTR): secondary reliability metric. Should trend downward as the PM program surfaces issues earlier.

Notice what is NOT on this list: total number of PM work orders. That number tells you nothing about whether the program is working. High PM count with poor MTBF is a program in trouble. Low PM count with good MTBF is a program working well. The count is not the metric.

For the broader FM operational KPI frame, see the FM KPI framework pillar.

8. Optimise PM frequency to match asset reality

Weekly inspection is not appropriate for every asset. Neither is annual. Frequency should match the specific asset's failure characteristics, criticality, operating conditions, and manufacturer guidance, blended with the actual operational history you have accumulated in the CMMS.

A rational frequency ladder:

• Weekly: high-consequence assets where failure carries safety, production or environmental impact; assets with short-cycle wear patterns; assets under harsh operating conditions.
• Monthly: standard operational assets where visible inspection catches deterioration in time; rotating equipment at moderate duty; typical HVAC in occupied buildings.
• Quarterly: stable assets with long deterioration cycles; standby equipment used infrequently; some categories of statutory compliance work.
• Semi-annual: assets with slow-changing condition and low failure consequence; some categories of building envelope inspection.
• Annual: statutory inspections with defined regulatory cycles (LOLER, PAT, fire safety); deep-clean or overhaul work with long intervals; asset condition surveys.

The design inputs are: manufacturer recommendation (baseline), failure history from CMMS records (adjustment factor), asset criticality (adjustment factor), and operating conditions (adjustment factor). None of these alone gives the right frequency. Manufacturer recommendations are conservative and often ignore actual operating context. Failure history requires two to three years of clean CMMS data to be reliable. Criticality gets you the priority ranking but not the specific interval. Operating conditions matter but are often qualitative.

The design discipline: start with manufacturer recommendation, adjust down for low-criticality low-duty assets, adjust up for high-criticality high-duty assets, and review the frequency annually against actual failure data. Frequency is a design parameter to tune, not a fixed value to inherit from the vendor manual.

9. Risk-based PM matches effort to consequence

Not every asset deserves the same maintenance attention. A pump serving a critical process on the plant floor and an identical pump used as backup that runs an hour a month should not receive the same PM effort. Risk-based PM design matches maintenance intensity to consequence of failure.

The framework I use in practice, drawn from the asset criticality classification pillar:

• Tier 1 critical assets: high-frequency inspection, detailed checklists, mandatory condition monitoring, escalated reporting on any defect found. These assets get PM attention proportional to their operational and safety consequence.
• Tier 2 important assets: standard inspection frequency, standard checklists, normal reporting. The bulk of the operational fleet.
• Tier 3 non-critical assets: simpler PM, longer intervals, sometimes moved to run-to-failure with a rapid-response corrective process. This is not neglect; it is deliberate resource allocation.

The value in this discipline is not just the maintenance effort saved on Tier 3 assets. It is the mental clarity it gives the maintenance team about where their attention needs to be. When everything is treated as equally important, nothing gets the attention it actually needs. Risk-based design reserves technician skill and time for the assets that genuinely need it.

10. Minimise work order volume deliberately

This is the section that will resonate with maintenance managers who have watched a well-intentioned PM implementation turn into a work-order factory. The failure mode goes like this: an implementation partner or an internal enthusiast decides that "more PMs" means "better maintenance," and starts adding PMs to cover every possible failure mode on every possible asset. Six months later:

• The paperwork burden on planners has exploded, leaving less time for actual planning
• The scheduling load has overwhelmed the field team's capacity, so PMs run late chronically
• Every PM needs a supervisor approval to close, which becomes a bottleneck
• The overdue-work-order backlog grows week over week
• Technicians start doing the visible PMs (checkbox exercises) and skipping the harder ones (the ones that actually find defects)

The organisation is now generating more paperwork than value. The CMMS looks impressively busy, but reliability is stagnant or worsening. This is the failure mode "more PMs is better" produces.

The reframe: the objective is not to maximise the number of PM work orders. The objective is to maximise asset reliability with the minimum necessary maintenance effort. That reframe changes every design decision.

You group assets to reduce work-order count without reducing coverage. You design routes to reduce technician travel. You standardise checklists to reduce interpretation variability. You right-size frequency to avoid over-inspection. You risk-tier assets to avoid over-maintaining low-consequence equipment. Every one of these design activities reduces work-order volume while improving actual reliability. The two are not in tension; they align once you stop measuring the wrong thing.

11. Review PM performance regularly and honestly

A PM program that was designed three years ago and never revisited is guaranteed to be misaligned with current operational reality. Assets have changed. Operating conditions have shifted. Some PMs are catching failures well; others have become checklist rituals that add no value. Regular review is what separates a program that improves from one that atrophies.

The questions I ask when reviewing an existing PM in an audit:

• Is this PM preventing failures? What does the failure history for the covered assets show over the last 12 to 24 months?
• Are technicians finding anything? What is the PM-generated corrective work rate on this PM?
• Has this checklist become obsolete? Has the asset been modified, the operating context changed, or the failure modes shifted?
• Can two PMs be merged into a single route without loss of coverage?
• Can inspection frequency be reduced without increasing failure risk?
• Can this PM become condition-based rather than time-based, given available sensor data?

Rhythm matters: I like to see a formal PM review at least annually for every PM, plus a broader program review every two years that questions the fundamental design assumptions. The alternative is a PM program that quietly drifts out of relevance without anyone noticing.

12. Use data to improve PMs, not opinions

Every review of a PM should be informed by data from the CMMS, not by opinion or vendor claim. The specific data points that matter:

• Failure history: what has actually failed on these assets, at what frequency, from what root causes? The failure record tells you what the PM should be looking for.
• Labour hours: how long is this PM actually taking? Trends in this number reveal a lot about asset condition and PM design quality.
• Material usage: what parts are being consumed against this PM? High material usage may indicate PMs are becoming corrective in disguise.
• Downtime: is the covered asset class experiencing downtime, and are the events preceded by missed or ineffective PMs?
• Root causes: for the failures that do occur, what root causes are recurring? Do the PMs address these root causes or are they inspecting the wrong things?
• KPI trends: MTBF, MTTR, PM compliance, emergency work percentage across the covered assets over multi-year windows.

Modify PMs based on evidence, not assumption. Fine-tune the checklist based on what technicians are actually finding. Adjust frequency based on failure trend data. Redesign routes based on actual technician time captured against the PM. This is the discipline that separates a mature PM program from a static one.

13. Move toward predictive and condition-based maintenance where it makes sense

Preventive maintenance is not the final destination of maintenance strategy maturity. It is one step on a well-established evolution:

Every organisation should be moving up this ladder over time, but not on every asset simultaneously. Critical rotating equipment should be moving from time-based to condition-based to predictive. Low-consequence assets can stay at simple preventive. Some assets may be more efficiently maintained reactively with a rapid response process.

The mistake to avoid: treating preventive maintenance as the destination. If your PM program is designed as though nothing better exists, you are locked in to the compromises of time-based inspection forever. Design PMs with the expectation that some will convert to condition-based or predictive as sensor data and reliability engineering capability mature. (See the preventive maintenance strategies pillar for the broader time-vs-meter-vs-condition framework, and the AI copilot for utilities CMMS pillar for how AI is starting to accelerate this transition.)

14. Common mistakes I see repeatedly in PM design

Pulling together the patterns from multiple CMMS and EAM implementations, the mistakes I see over and over again:

• Creating one PM for every individual asset without considering routes or grouping. The single most common design flaw and the one with the biggest compounding impact on program quality.
• Copying manufacturer recommendations without adapting them to actual operating conditions, criticality, or failure history. Manufacturer recommendations are conservative baselines, not final designs.
• Using generic checklists that do not provide meaningful inspection guidance. "Inspect pump" is not a checklist. It is a shrug.
• Not defining estimated labour hours. Without them, you cannot schedule, measure efficiency, or detect drift in PM effort.
• Scheduling PMs without considering technician travel or work sequencing. Scheduling in the CMMS is not the same as designing the field workflow.
• Treating all assets as equally critical. Nothing gets the attention it needs when everything is treated as equally important.
• Never reviewing or optimising PMs after implementation. A PM designed three years ago is almost certainly wrong today. Review is a required activity, not an optional one.
• Measuring success by the number of completed PM work orders instead of reliability improvements. This is the metric that quietly destroys programs from the inside.

Every one of these mistakes is fixable. None of them requires new software or vendor engagement. They are design choices that maintenance leaders can make (or unmake) with the tools they already have.

The idea to walk away with

If you take one thing from this article, take this: the number of PM work orders in your CMMS is not the goal. It is not even a leading indicator. It is a byproduct of program design decisions, some of which are good and some of which are bad. Judging your PM program by the size of the PM list is like judging a book by its weight. The weight tells you almost nothing about the quality of what is inside.

The measurable goal of a preventive maintenance program is improved reliability, optimised maintenance effort, and efficient use of technician time. Every design decision, from grouping to routing to checklist standardisation to frequency to risk-tiering, works back to those three outcomes. When PM design is aligned with those outcomes, the PM count usually comes down while reliability improves. That is what a healthy PM program looks like from the inside.

Final thoughts

Preventive maintenance is the strategy layer, not the paperwork layer. The organisations that get this right end up with lean PM programs that deliver strong reliability, respected planners with time to actually plan, technicians with focus and pride in their route work, and CMMS data that supports credible reliability engineering downstream. The organisations that get this wrong end up with bloated PM programs, overwhelmed planners, disengaged technicians, and reliability data that nobody trusts because the underlying process is unreliable.

The good news is that migrating from the wrong version to the right one is a design exercise, not a technology purchase. It costs nothing beyond the time to review, redesign, and consolidate. It does not require a new CMMS. It does not require a vendor engagement. It requires a maintenance leader who is willing to challenge the assumption that "more PMs is better" and rebuild the program around the outcomes that actually matter.

Do the work once and it pays back for a decade. Skip it and you carry the cost forever.

Related reading: Preventive maintenance strategies (time vs meter vs condition), Work order types in CMMS, Asset hierarchy design, Asset criticality classification, Failure codes: Problem, Cause, Action, FM KPI framework, AI copilot for utilities CMMS.