Preventive Maintenance Plans and Programs: A Framework

There is a question I ask early in almost every CMMS or EAM assessment, and the answer tells me more than any system demonstration: who owns your preventive maintenance content, and how does a PM task change? Most of the time the answer is a name rather than a process. One planner, or one long-serving supervisor, holds the whole programme in their head and in a spreadsheet. The schedules run, the work orders generate, the technicians turn up. It looks like a working preventive maintenance system. It is actually one resignation away from nobody knowing why the chiller inspection is quarterly. A preventive maintenance programme is not a set of schedules. It is an organisational capability with a policy, a data foundation, defined roles, a repeatable weekly cycle, change control and an improvement loop. This guide is about building that capability.

The message up front: a preventive maintenance system is three things stacked in order, and skipping a layer is why programmes decay. The foundation is asset data and criticality, which decides who gets PM at all. The middle layer is the job plan library and the planning cycle, which decides what gets done and when. The top layer is governance: a written policy, named roles, change control and a review loop. Buy a CMMS and you have bought the middle layer's mechanics. The foundation and the governance are yours to build, and they are what makes the difference between a programme and a pile of schedules.

1. The difference between a schedule and a programme

The vocabulary in this field is loose, and the looseness causes real confusion in procurement and in project scoping. It is worth being precise, because these are different objects with different owners and different failure modes.

• A PM task is one instruction: check belt tension, record bearing temperature, replace the filter. It lives in a job plan or a checklist.
• A PM schedule is a task or set of tasks attached to an asset with a frequency and a trigger. Quarterly, or every 500 running hours, or every 10,000 cycles. This is the level most people mean when they say preventive maintenance, and it is the level a CMMS handles natively. The mechanics of building one are covered in how to build a preventive maintenance schedule.
• A PM plan is the set of schedules covering a defined scope: a building, a plant area, an asset class, a contract. It is the thing you present to a client or an auditor as your maintenance intent for that scope.
• A PM programme, or preventive maintenance system, is the whole apparatus that produces, executes, controls and improves those plans: the policy, the data, the library, the roles, the cycle, the change control and the review. It is the only one of the four that is genuinely an organisational asset rather than a document.

Why this matters practically: when a maintenance programme underperforms, people almost always try to fix it at the schedule level. They adjust frequencies, add tasks, tighten the compliance target. Sometimes that is the right fix. More often the problem is a layer down (the asset register is wrong, so the PM is attached to assets that do not exist as recorded) or a layer up (nobody owns PM content, so changes are made informally and undocumented). Fixing schedules when the problem is governance is the single most common wasted effort I see in maintenance improvement work. For the broader foundation of what preventive maintenance is and how it fits alongside other strategies, start with the complete guide to preventive maintenance.

2. Defining scope and objectives before anything else

A preventive maintenance programme without stated objectives cannot be judged, and a programme that cannot be judged will drift. The objectives need to be specific enough that someone could tell you next year whether they were met, and they need to be written down somewhere more durable than a slide deck.

The four objective families worth being explicit about:

• Statutory and regulatory compliance. Fire systems, lifting equipment, pressure vessels, electrical installations, potable water systems, lifts. These are not negotiable and they are not subject to optimisation. They are the floor of the programme and they should be tagged distinctly so nobody ever "optimises" a legal inspection out of existence.
• Asset reliability and availability. Reducing unplanned failures on the assets whose failure disrupts the operation. This is where the engineering judgement lives.
• Asset life and capital deferral. Maintaining condition so replacement happens on a capital plan rather than an emergency budget line.
• Cost and resource efficiency. Delivering the above with a defined labour envelope and without generating work that produces no reliability benefit.

Scope needs the same discipline. State what is in and, more usefully, what is deliberately out. A programme that says "all assets" is a programme that has not made any decisions. A programme that says "all statutory assets, all criticality 1 and 2 assets, and criticality 3 assets in the central plant rooms only, with all other assets on corrective response" has made real choices that can be resourced, audited and defended.

3. The maintenance policy document: what it contains and why it exists

The maintenance policy is the artefact most organisations skip, and its absence is felt constantly without being diagnosed. It is a short document, usually five to fifteen pages, that states the rules of the programme so that decisions do not have to be re-litigated every time someone new joins or a contractor asks why.

What a useful maintenance policy actually contains:

• Scope statement. Which sites, systems and asset classes the policy governs, and what is explicitly excluded.
• Strategy assignment rules. How an asset is assigned to preventive, condition-based, or run-to-failure. This should reference criticality bands rather than naming individual assets, so it stays valid as the register grows.
• Frequency-setting rules. The permitted bases for a frequency: manufacturer recommendation, statutory requirement, recognised standard, failure history, engineering judgement documented with a rationale. Requiring a recorded basis for every frequency is the single highest-value clause in the document.
• Compliance definition. What counts as a PM completed on time, what the grace window is, and how a deferral is authorised. Without this, PM compliance percentages are not comparable across months, let alone across sites.
• Deferral and cancellation authority. Who may defer a PM, by how long, and what must be recorded. Statutory PMs typically have no deferral authority below a named senior role.
• Data standards. Naming conventions, hierarchy rules, mandatory fields, failure coding requirements at closeout.
• Roles and authorities. The RACI, or at minimum a clear statement of who owns PM content, who schedules, who approves changes.
• Review cycle. When the policy itself and the PM content get reviewed, and by whom.

For organisations that want an external reference frame for this document, the ISO 55000 asset management family is the natural anchor, and for building services specifically the SFG20 maintenance specification is the widely used baseline in the UK and increasingly in the Gulf. Neither replaces your own policy, but both give you defensible ground to stand on when a client or auditor asks where your task content came from.

Useful references: ISO 55001 asset management and SFG20 .

4. The asset register and criticality as the foundation

Every preventive maintenance system rests on the asset register, and the register is where most programmes are quietly broken. If the register is incomplete, PM does not exist for the missing assets and nobody notices until something fails. If the register is duplicated, PM generates twice and technicians learn to ignore work orders. If the hierarchy is wrong, you cannot roll up cost or failure history to any level that supports a decision.

The three foundation elements, in dependency order:

• A complete, deduplicated register with a stable identifier per asset and a location that matches physical reality. Verified by survey, not by importing whatever the handover spreadsheet contained.
• A hierarchy that reflects how you operate and report, not how the previous system happened to be structured. Site, building, system, equipment, component is a common and workable shape. See asset hierarchy design for CAFM and EAM for how to get this right the first time, because retrofitting a hierarchy across a live register is genuinely painful.
• Criticality assigned and recorded against every asset, using a consistent, documented method rather than a supervisor's instinct. This is the field that drives almost every downstream decision in the programme. The method is covered in asset criticality classification.

Alongside these sits the discipline of keeping them true over time, which is a master data problem rather than a maintenance problem. New assets from projects, decommissioned assets from replacements, changed locations from refurbishments: each one is a register update that somebody has to own. See master data management for assets for the governance that keeps a register from degrading back to the state you found it in.

5. Deciding which assets get PM at all

This is the decision that most determines programme cost, and it is frequently not made at all. The default, especially in handover from a construction project or a previous contractor, is that every asset with a manufacturer manual gets a PM schedule. That produces an enormous, unexecutable programme, and it is the root cause of the bloat problem examined in PM programme design: quality over quantity.

The screening logic I would apply, in order, to every asset class in the register:

Two things about this table are worth stating plainly. First, "run to failure" is a legitimate, deliberate strategy for a large share of any register, typically the low-consequence, low-cost, quickly replaceable assets, and recording it as a decision is very different from arriving at it by neglect. Second, the fourth question is the one people skip. If you cannot describe a task that would actually detect or prevent the dominant failure mode, adding a generic "inspect and clean" PM achieves nothing except consuming labour and generating compliance figures. The related strategy choices, time versus meter versus condition, are set out in preventive maintenance strategies.

6. Building the PM library: job plans, task lists and standard times

The PM library is the reusable content layer, and treating it as a library rather than as a pile of per-asset schedules is one of the highest-leverage structural decisions available. The principle: write the task content once per asset class and attach it to many assets, rather than writing it per asset.

A well-formed job plan has these components:

• A stable identifier and version. If you cannot tell which version of a job plan a completed work order used, you cannot audit it or improve it with confidence.
• Scope and applicability. The asset class, type and any qualifying condition. "Air-cooled chiller, 200 to 500 TR, quarterly" rather than "chiller PM".
• Ordered task steps with measurable outcomes. Not "check the belt" but "measure belt deflection, record value in mm, replace if outside manufacturer tolerance". The distinction between an instruction and an observation record is what makes PM data useful later. Format and examples in PM checklists, templates and examples.
• Meter and condition readings to capture, with units and expected ranges. These become your trend data, at no additional cost.
• Craft, crew size and standard time. One technician, 1.5 hours. Without standard times you cannot forecast labour, level a schedule or size a team, which means you cannot plan.
• Required parts and materials, so kitting can be automated rather than improvised.
• Tools, access requirements and permits. Whether a permit to work, isolation, or roof access is needed changes how the job is scheduled entirely.
• Safety content and referenced procedure. Hazards, PPE, isolation points, and a link to the controlling procedure rather than a duplicated copy of it.

On standard times: estimates are acceptable to start with, provided they are labelled as estimates and then corrected from actuals. The mistake is to leave the initial guesses in place for years and then wonder why the schedule never fits the available hours. A quarterly exercise comparing actual duration against standard time for the highest-volume job plans, and adjusting, is inexpensive and transforms planning accuracy.

Most enterprise platforms support this library pattern properly. IBM Maximo has job plans with routes and a separate PM record; SAP PM uses task lists with maintenance plans and items; Hexagon EAM and Infor EAM have equivalent constructs. Mid-market tools such as Fiix, eMaint, Limble, MaintainX and UpKeep vary: some have genuine reusable templates, others effectively copy content per asset, which works until the day you need to change one step across four hundred assets. That single capability is worth checking specifically during selection, and it is one of the criteria in the CMMS buyer shortlist.

7. Roles and responsibilities: the RACI that makes it real

A preventive maintenance system fails at the organisational layer more often than at the technical one. The specific failure is role collapse: one person performing planning, scheduling, supervision and content ownership simultaneously, which means none of them gets done properly and all of them stop when that person is on leave.

The distinct functions, which may be separate people on a large site and combined roles on a small one, but should always be separately named:

• Maintenance manager: owns the policy, the objectives and the resourcing. Approves strategy changes and authorises statutory deferrals.
• Reliability or maintenance engineer: owns PM content. Decides tasks and frequencies, reviews failure history, proposes changes. This is the role most often missing entirely, and its absence is why PM content never changes.
• Planner: converts identified work into executable job packages. Scopes, estimates, specifies parts and permits, builds the backlog of ready-to-schedule work. Planning is about the future and about readiness, not about today's fires.
• Scheduler: allocates ready work to a time window and a resource. On smaller operations this merges with planning, but the two activities are genuinely different and confusing them is why planners spend their days firefighting.
• Supervisor: assigns to individuals on the day, manages execution quality, ensures closeout data is entered properly.
• Technician: executes, records readings and findings, applies failure coding, raises follow-up work for defects found.
• Storeroom or materials controller: maintains stock for PM-driven demand, kits work orders, flags parts risk before it becomes a schedule problem.
• CMMS administrator or data owner: configuration, master data integrity, reporting, and control of who can change what.

On a site with fifteen technicians you will not have eight distinct people. What you should still have is a table like this with real names in it, showing that one person holds the reliability engineering hat and another holds the planning hat even if they also do other things. The value is not headcount, it is that no activity in the table has an empty Accountable column. Run down that column and look for blanks: those blanks are where your programme will fail.

8. The planning and scheduling weekly cycle

The weekly cycle is the heartbeat of a preventive maintenance system. Without it, PM work orders generate into a queue and get done when there is time, which in practice means when there is nothing urgent, which in practice means less often than intended. A fixed cycle forces PM to compete for capacity on stated terms rather than losing by default.

The pattern that works, expressed as a rolling weekly rhythm:

Two details carry most of the weight. First, only work that is genuinely ready (scoped, parted, permitted) enters the schedule. A schedule containing unready work is a wish list, and technicians learn within weeks to treat the whole schedule as optional. Second, the reserve for emergent work has to be sized from actual history, not optimism. If reactive work has historically consumed thirty percent of hours, scheduling ninety-five percent of capacity to planned work guarantees the schedule breaks every week. Schedule seventy percent, hold the rest, and the compliance figure becomes meaningful.

9. Work identification and backlog management

A preventive maintenance system does not only consume the work it generates. A well-functioning PM programme is a work identification engine: inspections find defects, meter readings show drift, technicians notice things. That output has to land somewhere structured, or it evaporates.

The intake needs a single front door and consistent typing. Work order types are the mechanism, and getting them right is what makes every downstream report possible; the taxonomy is covered in work order types in a CMMS. At minimum you want to distinguish PM-generated work, corrective work arising from a PM finding, corrective work from an operator report, emergency work, and project or improvement work. The second category, corrective from PM finding, is the one people forget to separate, and it is the most valuable number in the programme: it is the direct evidence that your PM is finding things before they fail.

On backlog, the mistake is treating it as a problem to be eliminated. A healthy backlog is a planning asset. What matters is composition and age, not size:

• Ready backlog, measured in crew weeks. Work scoped, parted and waiting for a slot. Two to four crew weeks is a comfortable working range; below that the scheduler has nothing to build from, well above that suggests you are identifying faster than you can execute.
• Waiting backlog, split by reason: awaiting parts, awaiting access or shutdown, awaiting approval, awaiting engineering decision. Each reason has a different owner and a different fix, and lumping them together hides all of them.
• Ageing profile. Anything sitting for more than a defined period without movement gets reviewed and either actioned or deliberately cancelled with a reason. Silent accumulation is what turns a backlog into a graveyard.
• Safety and statutory items tracked separately and never allowed to age. These do not queue behind convenience work.

A monthly backlog review with the maintenance manager, planner and operations present, working through composition rather than total count, is a modest time commitment that prevents most of the chronic backlog pathologies.

10. Spares, kitting and the materials link

The most common reason a planned PM does not happen on the day is that a part is not there. This is a programme design problem, not a storeroom problem, and it is solved at the job plan level.

The chain that has to be intact:

• Job plans carry their bill of materials. Every PM that consumes a part names it with a stock code and a quantity. Without this, PM demand is invisible to the storeroom and stock levels are set from guesswork.
• PM demand is forecast, not reacted to. Because PM frequencies are known, the parts consumption they cause is forecastable months out. That forecast should drive reorder levels for PM-consumable items such as filters, belts, lubricants, seals and lamps.
• Kitting happens before the schedule freezes. Parts are picked and staged against the work order, in the week before execution, so the technician collects a kit rather than hunting a storeroom. This is the single highest-return change in wrench-time terms available to most operations.
• Unready work does not enter the schedule. If a part is short, the work goes to waiting backlog with the reason recorded. It does not get scheduled and then fail.
• Consumption is recorded against the work order and the asset. This closes the loop: it gives you parts cost per asset, which feeds criticality review and replace-versus-repair decisions.

11. Change control for PM content

This is the section that separates a managed programme from an informal one, and it is where I would focus first on most sites I assess. The symptom of no change control is simple: nobody can tell you why a frequency is what it is, and task content quietly diverges from what the policy says it should be.

What change control requires, and it is lighter than it sounds:

• A rationale field on every PM, populated. Manufacturer manual reference, statutory citation, standard clause, or a named engineering decision with a date. Retrofitting this across an existing programme is tedious but it is a one-time cost and it permanently changes the quality of every future review.
• A defined request route. Anyone can propose a change to a task or frequency, through a recorded request rather than a conversation.
• An assessment step owned by the reliability engineer. Does the evidence support the change? What failure modes does it affect? What does the history say?
• Approval proportionate to risk. Adjusting a non-critical inspection interval is a routine engineering decision. Reducing scope on a statutory or safety-critical PM needs the maintenance manager and, where relevant, HSE.
• Versioned job plans, with the version recorded on completed work orders. Otherwise you cannot tell whether a failure occurred under the old task content or the new.
• Communication of the change to supervisors and technicians before it appears in their work orders. Content that changes silently gets executed to the old habit anyway.

The reason to insist on this: PM optimisation, the deliberate reduction and refinement of task content, is impossible without it. You cannot safely remove tasks from a programme when you do not know why they were added. Change control is not bureaucracy for its own sake; it is what makes the programme improvable rather than merely maintainable.

12. The continuous improvement loop

A preventive maintenance programme that does not change is decaying, because the assets age, the duty changes, the failure history accumulates and the original assumptions expire. The improvement loop is what converts operational data back into better content.

The loop, on a practical cadence:

• Monthly: compliance and non-completion review. Which PMs were not done and why. Recurring non-completion for the same reason is a design signal, not a discipline problem. If a PM has never been completed on time in eighteen months, the interval or the resourcing is wrong.
• Quarterly: failure history against PM content. Take the assets with the most corrective work and ask whether their PM addresses the failure modes that are actually occurring. This requires usable failure coding, which is why problem, cause, action failure coding is a prerequisite rather than a nice-to-have.
• Quarterly: PM effectiveness by task. What proportion of PM executions found a defect and generated corrective work? A task that finds nothing across hundreds of executions is a candidate for interval extension or removal. A task that frequently finds late-stage defects is a candidate for interval reduction.
• Annually: criticality and scope review. Assets change importance as operations change. The register and the criticality bands need a scheduled revisit.
• Annually: policy review. Does the written policy still describe what you actually do, and what you actually want?

The metric frame that supports all of this, and the discipline of picking a small number of measures that drive behaviour rather than a dashboard nobody reads, is set out in the FM KPI framework. For a preventive maintenance programme specifically, the short list I would hold to is PM compliance, schedule compliance, proportion of total work that is planned versus reactive, PM-found defect rate, and ready backlog in crew weeks. Five measures, reviewed monthly, will tell you almost everything.

13. The maturity ladder: from ad hoc to managed

Programmes do not jump from informal to optimised. They climb, and knowing which rung you are on prevents the common error of attempting a level-four intervention on a level-one foundation. Deploying PM optimisation analytics on a site with an unverified asset register and no failure coding is the classic version of that error.

My honest read on where most organisations sit: level two, with ambitions stated at level four and a self-assessment that claims level three. The gap between level two and level three is the hardest and most valuable transition in the whole ladder, because it is almost entirely organisational. It requires naming a reliability owner, running a disciplined weekly cycle, and building a job plan library, and none of those are purchases. That is exactly why they get deferred in favour of buying something.

14. A ninety day plan for establishing the framework

If you are starting from a programme that exists but is not governed, this is the sequence I would recommend. It is deliberately ordered so that each step makes the next one possible.

• Days 1 to 15. Baseline honestly. Current PM count, compliance, proportion of reactive work, backlog composition, and a register quality sample: pull fifty assets and physically verify them. Place yourself on the maturity ladder from evidence, not opinion.
• Days 15 to 30. Draft the maintenance policy. Keep it short. Get the strategy assignment rules, compliance definition and deferral authority agreed and signed.
• Days 20 to 45. Name the roles and publish the RACI. Fill the reliability engineering accountability even if it is a part-time hat on an existing person. Nothing else in the framework works without that column filled.
• Days 30 to 60. Fix criticality. Assign or re-assign criticality to every asset using a documented method. This unlocks every scoping decision downstream.
• Days 45 to 75. Start the weekly cycle. Pick one area, run the full planning, materials, schedule, freeze, review rhythm for six weeks. Measure schedule compliance from week one and expect it to look bad initially.
• Days 60 to 90. Consolidate the PM library for the two or three highest-volume asset classes into reusable job plans with standard times and rationale. Do not attempt the whole library.
• Day 90. Review, and publish the change control process. Then repeat the library and weekly cycle work area by area.

Ninety days does not deliver a mature programme. It delivers a governed one, with the policy written, the roles named, the foundation corrected and the cycle running in one area as a working proof. The rest is repetition, and repetition is a management problem rather than a design problem.

The idea to walk away with

A preventive maintenance system is not the schedules and it is not the software. It is the policy that states the rules, the asset data and criticality that decide who gets maintained, the job plan library that holds the task content, the named roles that own each activity, the weekly cycle that turns intent into executed work, the change control that makes the content improvable, and the review loop that feeds evidence back in. Every one of those layers is organisational rather than technical, and every one of them survives a staff change only if it is written down.

The diagnostic question from the opening is the one worth keeping. If you cannot say who owns PM content and how a task changes, you do not yet have a system. You have schedules that happen to be running, and a dependency on the person who understands them. Closing that gap costs almost nothing in software and almost everything in management attention, which is precisely why it is the work that gets postponed and the work that makes the difference.

Final thoughts

The temptation in maintenance improvement is always to act at the schedule level, because it is visible and it feels productive. Adjust the intervals, add the tasks, chase the compliance number. I have watched that cycle repeat for years on sites that never got better, because the constraint was one layer down in the asset data or one layer up in the governance, and neither was being touched.

If you take one action from this guide, make it the RACI. Write down every activity in your preventive maintenance programme and put a real name in the Accountable column for each one. The blanks you find will tell you, with uncomfortable precision, where your programme is going to fail next. Everything else in this framework is a refinement of that single act of assigning ownership.

Related reading: Preventive maintenance: the complete guide, PM programme design: quality over quantity, How to build a preventive maintenance schedule, Asset criticality classification, Master data management for assets, FM KPI framework.