Preventive Maintenance (PM): Acting Before Failure & the Optimal Interval

In short

Preventive maintenance (PM) is work done before a failure to stop it disrupting production. Crucially, that includes condition-triggered work: if you refit a bearing because it started to rumble or run hot, but before it breaks down, that is preventive — not corrective.

PM comes in flavours: time-based (every N months), usage-based (every N hours/cycles), and condition-based (when a measurement crosses a limit). Predictive is condition-based PM made continuous and forecasting.

The danger is doing too much or too little: over-maintenance wastes money and introduces faults, under-maintenance lets failures through. There is an optimal interval that minimises total cost — and the model below finds it.

The Bluestream Toolbox PM Optimisation tool showing a 26-line PM plan reviewed against four years of completion and failure history. The verdict summary reads 1 shorten, 11 extend, 12 reconcile, 1 refer to barrier management and 1 refused. The first row is expanded to show the evidence behind the shorten recommendation, including the clause quoted, a counter-argument, the consequence class, the peer comparison with its raw and multiplicity-corrected p values, and the evidence grade. — **Tool 02 in the Toolbox, reading a 26-line PM plan against four years of history.** The first line is shortened because that pump’s bearings fail well above the rest of its peer group — 11 failures against the 2.2 expected of it. The card behind the verdict carries the NORSOK Z-008:2024 §11.5 wording it rests on, the counter-argument against shortening, the peer comparison with both the raw and the multiplicity-corrected p, and the attribution tier — so the recommendation can be argued with rather than taken on trust.

What counts as preventive

The cleanest definition is by timing relative to failure: preventive maintenance is done before the failure; corrective is done after. What it is not defined by is how scheduled it was. This trips people up because we associate "preventive" with calendars and "corrective" with surprises — but a condition-triggered, somewhat-urgent intervention is still preventive if it beats the breakdown.

The rule, plainly: if the maintenance is intended to assess or mitigate degradation and reduce the item’s probability of failure, it is preventive (EN 13306:2017, 7.1) — even if you only acted because a bearing began to rumble or a temperature climbed. If you refit it before the breakdown, it's preventive. Only the repair done after the failure is corrective. (See the timeline in Corrective Maintenance.)

So preventive maintenance spans everything from a routine quarterly greasing to an unplanned-but-pre-emptive change-out prompted by a vibration alarm. They share the only thing that matters: they happened in time.

The kinds of PM

Type	Trigger	Good for	Watch out for
Time-based (calendar)	Every N weeks/months	Predictable wear; simple to plan	Wastes life if the clock doesn't match the wear
Usage-based	Every N run-hours / cycles / km	Wear that tracks usage, not time	Needs reliable usage counting
Condition-based (CBM)	A measurement crosses a limit	Acting only when needed; max life	Needs monitoring & a known P-F interval
Predictive (PdM)	A forecast from continuous data	Maximum lead time & planning	Needs sensors, connectivity, analytics

The trend over the last decades has been to move down this table — from rigid time-based PM toward condition-based and predictive — because acting on actual condition wastes less life and catches more faults. But time-based PM never disappears: for many simple items it is the cheapest, most robust choice, and for failures that are genuinely random it's pointless to monitor at all (an RCM finding).

Too much, too little, or just right

PM has a Goldilocks problem. Do it too rarely and failures slip through — you're effectively running to failure. Do it too often and you waste labour and parts, take production down needlessly, and — counter-intuitively — introduce failures: every intrusive intervention risks infant mortality (a bad reassembly, a contaminated bearing, a nicked seal). This is the "do no harm" principle: unnecessary PM can make things worse.

Between those extremes is an interval that minimises total cost: the PM cost (which falls as you do it less often) plus the expected failure cost (which rises as you do it less often). The sum is a U-curve with a clear bottom. Find it:

Interactive — The optimal PM interval

Live model

PM interval 12 mo

How often you do the preventive task

Cost per PM $600

Labour + parts for one PM event

Failure consequence $25,000

Cost of one unplanned failure

Total cost

$—

per month, at this interval

Optimal interval

—mo

lowest total cost

Cost at optimum

$—

per month

vs optimum

—

overspend

Cost vs PM interval

Total = PM cost (falls) + failure cost (rises). The bottom is the optimum.

TotalPM costFailure costyour interval

Model: total monthly cost ≈ C_pm/T + C_f·a·T (PM cost per time falls with interval; expected failure cost rises with it), optimum at T* = √(C_pm/(C_f·a)). A teaching simplification — real optimization uses the item's failure distribution (e.g. Weibull) and downtime, often via RCM — but the U-shape and the trade-off are exactly real.

The PM Optimisation trigger register, listing the eight NORSOK Z-008 clause 11.4 triggers for a detailed investigation in the clause’s own order. Each shows a state: clear, unavailable, or fired with a count. Notes beside each explain what it needs, including that the production-loss threshold has no default because the word unacceptable belongs to the operator. — **What should make you look again — §11.4, in the clause’s own order.** Z-008 separates the things that should prompt an *investigation* from the things that justify *changing the plan*, and the tool holds that line: nothing on this tab moves an interval. Where a trigger needs a number the standard does not supply, it says so rather than inventing one — “unacceptable” production loss is your threshold, not ours. Two of the eight have no source in a CMMS export at all and are shown as unavailable rather than quietly dropped.

Building a PM program that works

Choose tasks by failure mode, not habit — let FMECA and RCM say which failures a PM task can actually prevent. PM on a random-failure item is wasted.
Prefer condition-based where you can — it wastes the least life; fall back to time/usage-based where monitoring isn't practical.
Set intervals deliberately — from the P-F interval for condition tasks, or the cost optimum above for time-based ones; then refine with history.
Do no harm — minimise intrusive work; every disturbance is a fresh chance to introduce a fault.
Review and prune — PM programs bloat over time. Periodically cull tasks that catch nothing and add ones that history shows you need.

Where the strategies meet. Preventive is the broad middle ground between reactive corrective and data-driven predictive work. Predictive maintenance is really preventive maintenance done with the best possible information — continuous condition data and a forecast — so you act at the last safe moment, wasting the least life of all.

The PM Optimisation KPI panel showing NORSOK Z-008 Table 4’s seven example key performance indicators, each with the standard’s own purpose and comment text. Preventive workload reads 301 orders and 666 hours with a note that man-hours are present on 297 of them; the overdue rows show counts of open orders past their deadline; the failure-fraction row refuses to give a PFDavg. — **How you know whether the programme is working — §11.3, Table 4.** The standard calls these *examples* rather than required outputs, and the panel says so. The workload row carries its own caveat: 666 hours across 301 preventive orders, with man-hours recorded on 297 of them, so the reader knows what the total is missing. The failure-fraction row declines to give a PFDavg at all — §11.3 wants that target to come from risk- and barrier analysis, and the tool holds neither yours nor a barrier model.

Key takeaways

Preventive = before failure, including condition-triggered work done in time.
Time, usage, or condition-based — move toward condition/predictive to waste less life.
There's an optimal interval — too much PM wastes money and adds faults; too little lets failures through.
Choose PM tasks by failure mode (FMECA/RCM), set intervals deliberately, and prune the program.

The strategies

Strategy · 3

Predictive maintenance →

Condition-based PM made continuous — forecast the remaining useful life and act at the last safe moment.

Strategy · 1

Corrective maintenance →

The after-failure work PM exists to avoid — and where run-to-failure is the right call.