Skip to content

Planned Maintenance Percentage (PMP): Formula & Benchmarks

By Martin Brandel · Last updated: April 2026

TL;DR: Planned Maintenance Percentage (PMP) is the share of total maintenance hours that were scheduled in advance: planned maintenance hours ÷ total maintenance hours × 100. A mature plant runs 70–85% PMP. Below 50% signals a reactive, firefighting culture. Above 90% almost always signals something worse — that planned hours have been inflated or that stops which really were unplanned have quietly been reclassified as "scheduled." The number on its own tells you very little. What matters is how the underlying hours were booked, and whether the classification survives a serious audit.

What is Planned Maintenance Percentage?

Planned Maintenance Percentage (PMP) is a maintenance-performance KPI that measures the proportion of maintenance work which was scheduled — by date, by runtime counter, by condition trigger or by prior work order — against the total maintenance effort in a given period. It is one of the most widely used indicators of maintenance maturity, sitting alongside MTBF, MTTR and availability as the standard vocabulary for how well a plant manages its equipment.

The metric exists because maintenance cost does not behave linearly. An hour of planned work during a scheduled window is not the same cost as an hour of unplanned repair during production — the planned hour is typically 3 to 10 times cheaper once you include lost output, expedited parts, overtime labour and the collateral damage of an unscheduled stop. PMP captures that asymmetry in a single ratio. High share of planned work means the maintenance organisation is in control of its schedule. Low share means the schedule is in control of the maintenance organisation.

How is PMP calculated?

The formula is simple; the bookkeeping behind it is where all the interesting questions live.

PMP = (Planned maintenance hours ÷ Total maintenance hours) × 100

Worked example. A plant records 480 maintenance labour hours in a month. 360 of those hours came from scheduled work orders — preventive maintenance tasks, planned component swaps, condition-triggered interventions that were queued and dispatched in advance. 120 hours came from break-in work: a bearing failure on a press, an unexpected hydraulic leak, a sensor fault during night shift. PMP = (360 ÷ 480) × 100 = 75%. That is squarely in the mature-plant range.

The arithmetic is not the problem. The problem, as anyone who has spent time in a maintenance meeting knows, is the numerator. What counts as "planned"? A work order raised at 8:00 and executed at 10:00 the same morning — is that planned? What about a stop triggered by condition monitoring that the team knew about for two shifts before acting on it? What about the five-minute adjustment that the day-shift technician does three times a week and nobody books at all? Every plant answers those questions differently. Every answer changes the number.

What are realistic PMP benchmarks?

The figures below reflect what shows up consistently in discrete manufacturing plants where maintenance hours are booked through a CMMS (SAP PM, IBM Maximo, Ultimo or equivalent) and where "planned" is defined by the existence of a work order raised before the work started — not after. Plants that allow retroactive classification will always report higher numbers; those numbers do not mean the same thing.

Maturity level PMP range What it typically looks like on the shop floor
Reactive < 50% Maintenance runs on radio calls. PM schedule exists on paper but slips constantly.
Transitional 50–70% CMMS in place, PM compliance improving, but unplanned stops still dominate on critical assets.
Mature 70–85% Disciplined PM execution, condition monitoring on critical assets, stable availability.
Suspiciously high > 90% Either world-class — or, far more commonly, reclassification at work. Audit before celebrating.

The jump from 70% to 85% is genuine work and takes two to four years of disciplined effort. The jump from 85% to 95% almost never happens through better maintenance alone; it happens through changes in how the hours are booked. That is not cynicism — it is what the data from serious rollouts consistently shows.

Where does PMP reporting typically go wrong?

Three decades of connecting plants to higher-level systems has produced a short list of patterns that show up in almost every site where PMP looks better than the production reality suggests. None of them are fraud. All of them are bookkeeping conventions that drift in a convenient direction when nobody is watching.

  • Retroactive work orders. A line goes down at 03:00. A technician fixes it by 04:30. At 09:00 the next morning, a work order is raised dated 02:00 — "planned inspection." The hours flow into the planned bucket. Technically the CMMS shows a work order that preceded the work. Practically, it was a break-in fix. The fix: enforce work-order creation timestamps at the BDE/MDE layer, not in the CMMS UI where they can be backdated.
  • Duration inflation of planned jobs. A planned PM task scheduled for two hours runs over because a component was unexpectedly worn. The extra three hours should logically split — two planned, three unplanned. In practice the whole five hours usually gets booked as planned because "the work order was a PM." This is the most common single distortion in PMP and the hardest to fix without changing how technicians log time.
  • Denominator erosion. Small unplanned interventions — the five-minute jam clear, the reset of a conveyor fault, the operator's lubrication top-up between shifts — are often not logged at all. They don't appear in the numerator (they weren't planned) and they don't appear in the denominator (they weren't logged anywhere). PMP looks cleaner than it is because the messy hours are invisible.
  • The "standing work order" trick. A permanent, open work order labelled "routine maintenance" absorbs any hours the technicians cannot otherwise classify. Everything in that bucket is planned by definition. This is the single most effective way to make PMP look like 95% on paper while the shop floor runs like 55%.

The pattern behind all four: PMP is assembled from two numbers that humans fill in, and whenever humans fill in numbers under management attention, the numbers drift toward the preferred answer. The only durable counter is automation of the capture layer — machine states, stop reasons and durations written directly from the PLC or the I/O gateway into the MES, then reconciled against the CMMS work order. The shop floor can still argue about classification, but it can no longer argue about how long the machine was down.

How does PMP relate to PM Compliance, MTBF and availability?

PMP is one indicator in a family, and reading it alone produces the wrong conclusions. The useful cross-check is always the triangle below.

Metric What it measures Unit
PMP Share of maintenance hours that were planned % of hours
PM Compliance Share of scheduled PM tasks that were executed in the due window % of tasks
MTBF Average operating time between unplanned failures Hours
Availability Share of planned production time the asset is running % of time

The healthy signature of a maintenance program that is genuinely improving: PMP rises, PM Compliance stays at 85–95%, MTBF rises, availability rises. The signature of a program that is only improving on paper: PMP rises, PM Compliance rises to suspicious levels near 100%, MTBF flat or falling, availability flat. Any plant management review that looks at PMP without MTBF next to it is reading half the page.

How do you actually improve PMP?

Real PMP improvement — the kind that also moves MTBF and availability — follows a predictable sequence. The theoretical version is in every maintenance textbook. The practical version, based on MES rollouts across metal processing, automotive supply and FMCG packaging, is shorter and less elegant.

  1. Fix the capture layer first. Before trying to move the number, make sure the number is honest. Automatic downtime capture through the PLC or an I/O gateway, classified by the operator with a short reason code, timestamps written into the MES. Until stop reasons are captured automatically, every discussion about PMP is a discussion about gut feel.
  2. Define "planned" and write it down. One page. A work order raised and released before the intervention started. Signed by maintenance and production. Anything else is unplanned. This sounds obvious and is almost never done explicitly, which is why the number drifts.
  3. Pareto the unplanned hours. Three to five failure modes account for 70–80% of unplanned maintenance time in almost every plant. Attack those first — with condition monitoring, with redesigned PM intervals, with root-cause fixes that eliminate the failure rather than treat it. Each failure mode eliminated shifts hours from the unplanned to the planned bucket honestly.
  4. Raise PM Compliance before raising PMP. A plant that executes its scheduled PM tasks on time and to spec will see PMP rise naturally as MTBF improves. A plant that tries to raise PMP while PM Compliance is at 60% is optimising the wrong variable.
  5. Audit the classification boundary quarterly. Pull a random sample of 20 work orders from the last month. Check the timestamp of work-order creation against the timestamp of the stop event in the MES. Any work order created after the stop started is unplanned, regardless of what the CMMS says. This single check, done honestly, keeps the number connected to reality.

A reference number from the field: plants that move from manual maintenance logging to MES-linked automatic downtime capture typically see reported PMP drop by 10–20 percentage points in the first three months. The drop is not a regression. It is the first honest baseline. Real improvement starts from there.

Where does PMP fit in the SYMESTIC platform?

In the deployment pattern I lead as MES Consultant, SYMESTIC is not a CMMS — it is the data layer that makes the CMMS's PMP number honest. Stop events and durations are captured automatically via OPC UA on modern controllers and via digital I/O gateways on brownfield equipment. The alarms module structures the downtime reasons; the process data module supplies the runtime counters and parameter context that usage-based PM intervals rely on. The CMMS — SAP PM, IBM Maximo, Ultimo and similar — continues to hold the work orders and the maintenance hours, but the reconciliation between "work order existed before the stop" and "stop actually happened" lives in the MES. That reconciliation is the difference between a PMP number that survives an audit and one that looks good on the dashboard. For further reading in authoritative print references, the relevant frameworks are ISO 14224 (reliability and maintenance data), EN 13306 (maintenance terminology) and VDI 2895 (organisation of maintenance) — no link worth putting here, standards bodies move their URLs; the documents are easy to find by name.

FAQ

What is a good PMP target?
70–85% is the mature-plant range and a legitimate target for most discrete manufacturing operations. World-class programs sit at the top of that range and sometimes slightly above. Anything above 90% should be audited before it is celebrated — the odds are high that the number reflects classification conventions more than maintenance excellence.

Is higher PMP always better?
No. A PMP that rises while MTBF stays flat means the maintenance organisation is doing more planned work without preventing more failures — which is over-maintenance, not excellence. A PMP that rises together with MTBF and availability is the healthy signal. Always read the three together.

What is the difference between PMP and PM Compliance?
PMP is a ratio of hours: planned maintenance hours ÷ total maintenance hours. PM Compliance is a ratio of tasks: completed PM tasks ÷ scheduled PM tasks, measured in a defined due-date window. They answer different questions. PMP tells you how much of your effort was scheduled. PM Compliance tells you whether you actually did what you scheduled. A plant can have high PMP and low PM Compliance if it reclassifies break-in work as planned while skipping the actual PM schedule — that combination is common and worth checking for.

How is "planned" maintenance defined in practice?
The only workable definition is a work order raised and released before the intervention starts, with a timestamp that pre-dates the stop event. Any looser definition — "we knew about it a while ago," "it was in the plan" — is unenforceable and drifts toward whatever makes the number look best. Tighten the definition and the number becomes meaningful; leave it loose and the number becomes theatre.

Does PMP apply to condition-based maintenance?
Yes, and arguably more cleanly. A condition-monitoring alert that triggers a work order, which is then scheduled and executed before failure, is by any reasonable definition planned maintenance — even though the trigger was reactive to a sensor signal rather than to a date. The more condition-based maintenance a plant runs, the more naturally PMP rises, because the window between "we know this is coming" and "we fix it" expands.

Why does PMP drop when we install MES-based downtime capture?
Because the previous number was wrong. Automatic capture catches the small unplanned interventions that manual logging missed — the five-minute jam clears, the shift-handover fixes, the night-shift resets that nobody wrote down. Those hours appear in the denominator, PMP drops, and the new baseline is the first honest number the plant has had. From there, real improvement is measurable. Without that step, every subsequent improvement claim is unverifiable.

How often should PMP be reviewed?
Monthly at maintenance-manager level, quarterly at plant-manager level, with a deeper classification audit once per quarter. Weekly tracking is usually overkill — PMP is a trend metric, not an operational one. What matters is that the review includes MTBF and availability on the same page, and that the classification boundary is audited periodically against actual stop-event timestamps from the MES.


Related: Preventive Maintenance · MTBF · MTTR · Availability · Condition Monitoring · CMMS · Machine Data Acquisition · OEE · Manufacturing Operations Management · Alarms.

About the author
Martin Brandel
Martin Brandel
MES Consultant at SYMESTIC. 30+ years in industrial automation — Simatic S5/S7/TIA, large-scale commissioning of conveying, process and coating lines across Eastern Europe and China at Hermos AG, then Head of Automation at SYMESTIC from 2000 to 2018 (process-industry software standard for beverage and wood industries, Simatic-S5-to-S7/TIA retrofits, brownfield machine integration). Since 2019, MES Consultant and project lead — from first scoping conversation through machine connectivity, KPI configuration and go-live. Specialises in mixed-vintage machine parks: modern OPC UA controllers next to 1990s equipment with no digital interface. Dipl.-Ing. Communications Engineering. · LinkedIn
Start working with SYMESTIC today to boost your productivity, efficiency, and quality!
Contact us
Symestic Ninja
Deutsch
English