Every maintenance leader knows at least one PM that shouldn’t exist. The monthly route that pumps fresh grease into sealed-for-life bearings. The quarterly teardown that introduces more defects than it prevents. The checklist item that says “check for abnormal conditions” and means absolutely nothing.
You know it’s waste. Your best technicians know it’s waste. And yet it survives, year after year, because everyone understands the unwritten rule of maintenance politics: nobody ever got fired for doing a PM, but plenty of people got blamed for canceling one.
So the bad PM lives on. It eats labor hours, clogs the schedule, and teaches your technicians that pencil-whipping is fine because the task never mattered anyway. That last part is the real damage. The wasted hours are easy to count. The credibility your program loses is the part that actually hurts.
Here’s how to kill it properly, with the evidence, the process, and the political cover to survive whatever happens next.
Why Bad PMs Are So Hard to Kill
A bad PM has a superpower: fear works in its favor. If you keep doing it, nothing visible happens. If you cancel it and the asset fails two years later (for a completely unrelated reason), someone in the failure review will say, “Didn’t we used to have a PM on that?”
That question, asked in front of a plant manager, ends careers. Or at least it ends the willingness of anyone in the room to ever challenge a PM again.
A useless PM teaches your technicians that the schedule is negotiable and the paperwork is fiction.
There’s also an ownership problem. Most PM libraries were built decades ago from OEM manuals, then layered with tasks added after every bad failure. Nobody owns the library as a system. Nobody is accountable for its total cost. So it only grows.
OEM recommendations deserve a hard second look here. They’re a starting point, written around generic duty cycles, conservative safety margins, and warranty protection. The manufacturer doesn’t know your operating context, your environment, or your actual failure history. You do.
The math nobody runs
Take an honest look at what a single bad PM costs. A monthly task consuming 2 labor hours runs you 24 hours a year. At a fully loaded rate of $85 an hour, that’s $2,040 annually for one task on one asset. Multiply across 40 similar tasks and you’re burning over $80,000 a year on work that prevents nothing.
And that’s the cheap version. Intrusive PMs cost more than labor. Every time you open a gearbox, break a flange, or disturb a bearing that was running fine, you create a fresh opening for contamination, an assembly error, or reassembly damage. Some of your failures are maintenance-induced, caused by the PM meant to prevent them. (Sit with that one for a minute.)
Build the Case Before You Touch the Schedule
You kill a PM with a file. Build the paper trail before you touch the schedule, so that if the asset ever fails, the record shows a disciplined process anyone can stand behind.
Start with the failure data
Pull the work order history for the asset: every corrective, every emergency, every PM finding for the last five years if you have it. You’re looking for one thing. Has this PM ever caught the failure mode it was designed to prevent?
A clean history is only one input, and it’s easy to overweight. For a failure mode that develops fast and shows up often, years of no findings is real evidence the task is low value. For a rare, high-consequence mode, or a hidden function like a protective device, zero findings tells you almost nothing. That’s exactly the case where the failure stays invisible until the day you need the device and it doesn’t work. Weigh the history against how often the mode occurs, how bad it is when it does, and whether you’d even see it coming.
If the PM has been generating findings, look closer at what they actually are. A note like “tightened loose guard bolt” is housekeeping. A note like “caught bearing spalling before failure” is the task earning its keep.
Test every task against the failure mode
Before you run a single task through this screen, wall off the ones that aren’t yours to cut. Regulatory inspections, statutory tests, environmental requirements, insurer and warranty conditions, and anything protecting a safety-critical or protective-device function go through a separate formal review of their own. Cost never outranks safety or compliance. Everything else is fair game.
Run each remaining task through a simple screen. A PM task earns its place on the schedule only if it can clear all of these:
- It addresses a specific, credible failure mode for this asset in this operating context.
- The failure mode is credible and consequential. Weigh how likely it is, how bad the outcome is, whether you’d detect it before it bites, and the exposure hours involved. Low probability plus high consequence still earns a formal response, though that might be a redesign, redundancy, or another control rather than a PM.
- The task can actually detect or prevent that failure mode. “Inspect general condition” detects nothing.
- The interval matches the failure development period. A monthly check for a failure that develops over 18 months is theater.
- No better option exists. If a routine vibration check or an online sensor covers the same failure mode at lower cost and lower risk, the intrusive task loses.
Run an honest review and a good share of legacy tasks fail at least one of these tests. The chart below shows the rough shape it tends to take. Treat it as an illustration and plug in your own numbers.
| Outcome | Share of tasks reviewed | Share |
|---|---|---|
| Keep as written | 40% | |
| Adjust frequency | 30% | |
| Rewrite the task | 15% | |
| Delete outright | 15% |
Notice that “delete outright” is only part of the win. Adjusting frequency often recovers more hours than deletion does, and it’s an easier sell politically. Extending a monthly task to quarterly cuts its cost by two thirds while keeping the coverage story intact.
Get the Political Cover in Writing
Here’s where most PM-killing efforts die. An engineer builds a solid technical case, changes the schedule quietly, and 14 months later becomes the answer to “who canceled that PM?”
Don’t be that engineer. The protection comes from making it a documented, multi-signature decision that no single person owns.
A file kills a PM cleanly. Put five signatures on the decision and blame has nowhere to land.
Set up a lightweight PM review board. It needs a reliability engineer, a senior technician who actually performs the task, a planner, an operations representative, and someone with budget authority. Five people, one hour a month, working through tasks in priority order.
For every change, produce a one-page decision record: the task, the failure mode it claimed to address, the evidence reviewed, the decision, and the signatures. File it against the asset in your CMMS. That document is your insurance policy.
One more move that pays off: brief your plant manager before the first change goes in, well ahead of any failure. Frame it in dollars recovered and hours returned to proactive work. Leaders who approved the program can’t act surprised by it later.
Replace it before you retire it
The safest kill is a substitution. Instead of “we canceled the monthly gearbox inspection,” the record reads “we replaced an intrusive monthly inspection with a vibration route and oil analysis.” Better detection on the modes that matter, without the routine teardown. Set the monitoring frequency off the P-F interval for each mode, so the schedule follows the physics. A slow-developing fault gets checked less often than a fast one.
Condition monitoring is your best friend in this fight. It lets you retire intrusive tasks while increasing actual coverage, which flips the political script entirely. Nobody accuses you of cutting corners when detection got better.
Kill It in Stages
For high-consequence assets, don’t go from monthly to never in one move. Extend the interval first: monthly to quarterly, quarterly to semiannual. Track the findings rate at each step.
If the task keeps finding nothing at the longer interval, you’ve built real evidence for full retirement. If it starts catching things, you’ve learned the interval was wrong in the other direction, and that’s worth knowing too.
Set a formal review date for every change, 6 or 12 months out, and actually hold the review. A PM change with a scheduled follow-up looks like engineering. A PM change with no follow-up looks like neglect, even when the analysis was sound.
A canceled PM with a scheduled review looks like engineering. A canceled PM with no follow-up looks like neglect, even when the analysis was right.
When Something Fails Anyway
Eventually, an asset with a retired PM will fail. Count on it. What matters is what happens in the room afterward.
First question: did it fail from the mode the old PM addressed? Usually the answer is no. A gearbox that fails from a lubrication problem says nothing about the alignment check you retired. Make that distinction loudly and early in the failure review, with the decision record on the table.
If it did fail from that mode, the decision record still protects you, because it shows a reasoned call made with the best available evidence and a defined review process. Reinstate the task at an appropriate interval, update the record, and move on. Good reliability engineering includes being wrong occasionally and correcting fast.
The worst outcome in maintenance is a PM library full of waste that nobody has the nerve to touch. A documented wrong call, you can fix in an afternoon. Rot you’re afraid to name just keeps growing. Kill the bad PMs. Just make sure the file does the talking when someone comes asking.
