How to Build a Preventive Maintenance Schedule

Most preventive maintenance schedules I am asked to review fail for the same reason, and it has nothing to do with the tasks themselves. The task content is usually fine. What is missing is arithmetic. Someone loaded every PM into the CMMS with a start date of the first of the month, the system dutifully generated four hundred work orders on the first Monday, and the crew of six looked at it, picked the ones that felt urgent, and let the rest age into a permanent backlog. Six months later schedule compliance reads thirty percent and everyone concludes the PM programme does not work. It works fine. It was never levelled.

The message up front: building a preventive maintenance schedule is two jobs, not one. Job one is technical: for each asset, choose the trigger and the frequency that the failure behaviour justifies. Job two is industrial engineering: spread the resulting work across the calendar so that weekly labour demand sits inside weekly labour capacity, every week of the year. Teams do job one and skip job two, then blame the software.

1. The preconditions: you cannot schedule what you have not registered

A preventive maintenance schedule is a layer that sits on top of an asset register. If the register is incomplete or badly structured, the schedule inherits every one of those defects and amplifies them. Before you write a single PM, three things need to be true.

• Every asset you intend to maintain exists as a record, with a unique identifier, a location, a class, and enough nameplate data (make, model, capacity, serial, install date) that you can look up what the manufacturer actually recommends. An asset that is not in the register cannot carry a PM, and unregistered plant is where surprise failures live.
• The hierarchy is deliberate. Site, building, system, equipment, component. The hierarchy decides where the PM attaches, which in turn decides how cost and history roll up. Attach PMs too high and you lose the ability to see which specific unit is consuming the labour; attach them too low and you generate a hundred work orders where one route would do. If the hierarchy is not settled, settle it first: see the asset hierarchy design guide.
• Criticality is assigned. Criticality is the single most useful input to frequency decisions and to what happens when the schedule slips. If you have not classified assets by consequence of failure, you have no principled way to decide which PM gets deferred in a bad week. The asset criticality classification guide covers the scoring.

A fourth precondition is softer but just as real: someone has to own the schedule. A named maintenance planner whose job it is to forecast, level, release and measure. Schedules without an owner drift back to chaos within two quarters. For the wider programme context, the complete guide to preventive maintenance is the pillar.

2. Choosing the trigger: calendar, runtime or condition

Every PM fires on a trigger, and getting the trigger right matters more than getting the interval precisely right. There are three, and they are not interchangeable.

Calendar-based (fixed time). Every 30 days, every quarter, every 12 months. Use it when degradation is driven by elapsed time rather than use: corrosion, seal drying, battery ageing, filter loading in a building that runs continuously. Also use it, without apology, for anything statutory. A fire pump test, an emergency light discharge test, a pressure vessel inspection, a lifting-equipment examination: these are calendar PMs because the regulation is expressed in calendar terms. They are not negotiable and they should be flagged as compliance PMs in the system so nobody levels them away.

Runtime or meter-based. Every 500 running hours, every 10,000 cycles, every 20,000 km. Use it when degradation tracks use: generators, compressors, vehicles, pumps with variable duty. The catch is that meter-based PMs require a meter reading to reach the CMMS. If nobody enters readings, a runtime PM never fires, and you find out eighteen months later that the standby generator has not been serviced since commissioning because its hour meter was never captured. Before committing to meter triggers, confirm the reading path: automatic from a BMS or SCADA tag, or a disciplined manual round.

Condition-based. The inspection is scheduled, the corrective intervention is not. You schedule a monthly vibration reading; the reading decides whether a bearing replacement is raised. Efficient on the right assets, but note the monitoring itself still needs a calendar or runtime PM to make it happen. Condition-based maintenance does not remove scheduling, it moves it one level up.

Mixed triggers are normal. IBM Maximo, Infor EAM, SAP PM and Hexagon EAM all let a PM fire on whichever of time or meter arrives first, which is correct for a generator due every 250 hours or annually, whichever comes sooner. Lighter platforms such as MaintainX, Limble, Fiix or UpKeep handle calendar and meter triggers competently; check the whichever-comes-first logic before assuming it. For how the resulting work is typed and routed, see the work order types guide.

3. Setting frequency honestly: three inputs, one decision

Frequency is where preventive maintenance programmes bloat, and where the most defensible savings hide. There are three legitimate inputs, and the skill is in weighing them rather than deferring to any one.

Input one: the manufacturer recommendation. The starting point and the default. It is also, almost universally, conservative. The manufacturer wrote that interval for the worst plausible duty cycle in the worst plausible environment, with warranty exposure on their side of the ledger and a spare-parts business attached. A quarterly interval on a unit running at forty percent duty in a clean plant room is frequently a genuine over-service. That is a real observation and also the most dangerous one in this article, which is why it gets its own limitation callout below.

Input two: actual duty cycle and environment. Two identical air handling units, one serving a dusty loading bay in Abu Dhabi summer, one serving a clean office floor, do not deserve the same filter interval. Duty hours, ambient temperature, dust and humidity loading, chemical exposure, start-stop frequency and load factor all move the correct interval. Most schedules ignore this input entirely, applying one class-level frequency to every instance, which simultaneously over-maintains the easy installations and under-maintains the punished ones.

Input three: your own failure history. After two or three years of disciplined work order closure you own the most relevant dataset that exists for your plant. If a PM has been performed sixteen times on an asset class and found nothing on all sixteen, that is evidence. If assets keep failing between intervals with the same failure mode, that is stronger evidence in the other direction. Reading this history requires usable closure data, which is a discipline problem more than a software one.

There is a fourth source worth naming for building services specifically: published standards-based task libraries. In the UK and much of the Gulf, SFG20 is the common reference for building engineering maintenance task content and frequencies, and it saves an enormous amount of first-principles work. For reliability method rather than task content, SAE JA1011 sets out what a genuine reliability-centred maintenance process has to satisfy, and ISO 55000 frames the asset management system the schedule sits inside.

The practical default: adopt manufacturer or SFG20 frequencies at go-live, tag each PM with its basis, and schedule a formal review at twelve and twenty-four months using your own closure history. That gives you a defensible starting point and a structured path to optimisation, which is a much better position than either blind adoption forever or day-one guesswork. The PM programme design guide goes deeper on pruning a bloated task set.

4. Writing the job plan: task content, duration and resources

A PM that says "service AHU" is not a job plan, it is a reminder. What you need attached to each PM, and what the CMMS calls a job plan, task list or maintenance plan depending on the platform, is a structured specification.

• Ordered task steps, specific enough that a competent technician who has not done this unit before can execute it. Each step gets a pass/fail or a measurement field where a reading matters, because readings are what turn PM history into trend data.
• Estimated labour hours by trade. The number the whole schedule depends on, and the one most often left blank. Without hours per task, levelling is impossible: you cannot balance a load you have not quantified.
• Crew size and trade mix. Two hours for one electrician is a different demand from two hours needing an electrician and a mechanic together.
• Parts and materials with quantities, so the CMMS can reserve stock ahead of release instead of the technician finding an empty bin at the asset.
• Permits, isolations and safety requirements. If the task needs a permit to work, a lockout or a confined-space entry, that belongs on the plan, and the permit lead time belongs in the scheduling assumptions.
• Access constraints. Tenant areas needing notice, plant that can only go offline at night, rooms requiring escort. Access is a constraint as hard as labour capacity and almost never captured.

On estimating hours, the honest method: start with a considered estimate from the person who does the work, not the vendor data sheet, then correct it with actuals. Once technicians book time against PM work orders, two or three cycles give you real durations and the levelling arithmetic becomes trustworthy. Until then treat estimates as provisional and leave more float than feels necessary.

5. Establishing real labour capacity

Before you can level, you need the denominator: how many PM hours per week can this team actually deliver? The mistake is to take headcount times forty. What you want is the wrench time genuinely available for planned preventive work after everything else is honoured.

Work it down in steps. Start from contracted hours, then subtract leave, holidays, training and sickness; the share of capacity reactive work will consume, read from last year's history rather than guessed; and travel, toolbox talks, permit waiting and administration. What remains is your PM capacity, and it lands far lower than people expect.

Two rules follow from this table. First, do the deduction by trade, not in aggregate. Total hours can look comfortable while the two electricians are hopelessly overloaded and the mechanical team is underused. Second, plan to fill only around eighty to eighty-five percent of net PM capacity. The remainder is float, and float is not slack, it is the thing that absorbs a bad week without destroying compliance.

6. Resource levelling: the step everybody skips

Here is the failure mode in plain arithmetic. Suppose a site has 900 monthly PMs, 300 quarterly, 200 semi-annual and 150 annual. If every one of them is created with a start date of the first of the month, the CMMS generates 900 work orders on the first working day of every month, plus 300 on the first day of every quarter, plus the semi-annual and annual clusters on top. Week one is an impossible wall and weeks three and four are empty. The crew triages, the backlog forms, and compliance collapses.

Levelling fixes it by staggering start dates so that demand is flat. The mechanics are straightforward once you accept that the day a PM lands is a planning decision, not a property of the asset.

• Distribute monthlies across all working weeks. A monthly PM does not have to be on the first. Split the monthly population into four or five roughly equal weekly buckets, grouped by location so a technician works one building per day rather than crossing the site.
• Offset quarterlies, semi-annuals and annuals. Quarterlies go into offset groups, one per month within the cycle. Annuals spread across all twelve months. Never let all annuals land in the same month.
• Nest the intervals. Where an asset has monthly, quarterly and annual tasks, land the quarterly in a week its monthly also falls and absorb the monthly checks into that visit rather than doing both. The CMMS calls this PM hierarchies or nested job plans, and it saves real travel and setup time.
• Route by geography. Group PMs on the same equipment type in the same building into a route, so one work order covers twelve light fittings rather than twelve separate orders. Routes cut administrative overhead sharply.
• Check the weekly total by trade against capacity, and iterate. This is the actual work of levelling: move start dates, re-check, repeat, until no week exceeds the trade ceiling.

The one constraint you must not level away: statutory and insurance-mandated tasks. Their window is fixed. Level everything else around them.

7. A worked example: levelling a mid-sized estate

Take a hypothetical estate with a mechanical and electrical team of six, net PM capacity calculated at 120 hours per week across trades, and an annual PM population totalling roughly 5,400 labour hours. Before levelling, the monthly profile looks like the left column below; after levelling, like the right.

Note what did not change: the total. Levelling does not reduce the workload and should not be sold as an efficiency gain. What it changes is whether the workload is deliverable. Before, four months demanded roughly double the available capacity and eight ran well under it. After, every month sits inside a capacity band, with the variation tracking seasonal reality rather than the accident of a start date.

Then take the same logic down to weeks, because monthly balance can still hide a brutal week one. A levelled week for the same estate, by trade:

The retained float is the point of the table. Twenty-two hours a week is what lets the team absorb a chiller trip, a permit delay or an absence without pushing PMs out of their compliance window. A schedule planned at ninety-eight percent utilisation looks more productive on paper and fails in practice, because maintenance weeks are not average weeks.

8. Seasonal work and shutdown windows

Levelling to a flat line is not always right. Some work belongs in a specific part of the year, and a good schedule shapes itself around those realities rather than fighting them.

• Pre-season readiness. In the Gulf, chiller overhauls, cooling tower cleans, condenser coil work and refrigerant checks belong in the cool months, finished before the first serious heat. Intrusive cooling work in July is how you convert a PM into an outage. In heating-dominated climates the same logic applies to boilers in late summer.
• Peak-season protection. Deliberately reduce planned intrusive load in the months when reactive demand peaks and taking plant offline is least tolerable. The June to August dip in the worked example is intentional.
• Shutdown and turnaround windows. Some tasks can only be done with the system off: de-energised switchboard inspection, pressure vessel internals, tank cleaning, main breaker servicing. Schedule these backwards from the shutdown date; the shutdown becomes a fixed anchor everything else levels around.
• Occupancy and business calendar. A university estate does most of its disruptive work in the summer vacation; scheduling it in exam term is a plan that will not survive contact with the campus. Retail, hotels and schools each have their own version.
• Leave and holiday clusters. Ramadan working hours, national holidays and summer leave all reduce capacity. Build those into the capacity model per week, not as an annual average.

The output is a small set of fixed anchors in the annual calendar: shutdown weeks, the pre-summer readiness block, the low-capacity holiday weeks. Place the anchors first, then level the flexible work into what remains. Levelling into an unanchored calendar and then discovering the shutdown is a rework loop you do not need.

9. Compliance windows, float and what deferral really means

A PM due on the 12th is not usually a PM that must happen on the 12th. Most tasks have a legitimate tolerance, and defining that tolerance explicitly is what separates a schedule that reports honestly from one that reports either fiction or despair.

Two design decisions go with this. First, decide whether a completed-late PM resets the next due date. Fixed-cycle means an annual PM done in March is next due the following March regardless; floating counts twelve months from actual completion. Fixed is correct for statutory work and anything where the calendar itself matters; floating where the interval is about elapsed service life. Most platforms set this per PM, and most implementations never look at the setting, which is how annual PMs quietly drift later each year.

Second, define deferral formally: a decision with a reason, an approver and a new date, recorded against the work order. An abandoned order aging in the backlog is not a deferral, it is a silent risk acceptance nobody signed. Criticality drives the approval level.

10. Doing it in the CMMS: PM masters, forecasting and lead time

The conceptual work above has to land in software, and the four objects that matter are broadly consistent across platforms even when the names differ.

• The PM master record. One per asset-plus-task-set combination, holding the asset, trigger type, frequency, job plan reference, next due date, compliance window, fixed-versus-floating setting and generation lead time. Maximo calls this a PM; SAP PM uses maintenance plans with items and strategies; Hexagon EAM and Infor EAM use PM schedules; lighter tools call it a recurring work order or PM template.
• The job plan or task list. Reusable task content, hours, trades, parts and permits, attached to many PM masters. Build these once per asset class, not once per asset, or maintaining the library becomes its own full-time job.
• The forecast. Every serious platform can project PM due dates forward without generating work orders. This is the tool you level with: pull 52 weeks, export, sum hours by week and trade, adjust start dates until the profile is flat. If a system cannot forecast forward with labour hours, levelling in it is guesswork, and that is a genuine shortlisting criterion: see the CMMS buyer shortlist.
• Auto-generation and lead time. How far ahead of the due date the work order actually appears. Too short and the planner cannot reserve parts, raise permits or book access. Too long and the backlog fills with work that is not yet actionable, which trains everyone to ignore the backlog.

On lead time: set it to the longest lead item in the preparation chain. If a permit takes five working days and a filter is three days from the store, seven to ten days is right for that PM. For simple routine tasks with stocked parts, two to three days is enough. Set it per PM, because one site-wide value will be wrong for both the lamp check and the transformer inspection needing a de-energisation plan.

One more setting causes trouble: what happens when the previous occurrence is still open. Suppressing the next one hides the true backlog and flatters compliance; generating it creates duplicates that annoy everyone. I prefer generating, because a visible backlog gets escalated instead of absorbed. Pain the system hides becomes permanent.

11. Measuring schedule compliance without gaming it

Schedule compliance is the primary health metric for a PM programme, and it is also one of the easiest numbers to manipulate. Define it tightly.

PM schedule compliance is the count of PMs completed within their defined compliance window, divided by the count of PMs that were due in the period. Note both halves. Completed, not opened or in progress. Within the window, not merely eventually. Due in the period, not generated in the period. A mature programme runs above ninety percent, and above ninety-five on critical and statutory assets. A programme below seventy percent is usually not a discipline problem, it is an unlevelled or overloaded schedule, and the schedule is the thing to fix.

Surround it with a few measures that make gaming visible.

• PM completion quality. Percentage of completed PMs with all required readings and task results actually recorded. High compliance with empty task fields is pencil-whipping, and it is worse than a missed PM because it manufactures false assurance.
• PM-to-corrective ratio. The proportion of PMs generating a follow-up corrective order. If almost none do, your PMs are finding nothing and the intervals or task content deserve review. If almost all do, the assets are in worse condition than the programme assumes.
• Planned versus reactive labour split. The classic target is roughly eighty percent planned, and it is the best single indicator of whether the schedule is in control of the workload.
• Backlog in crew-weeks. Outstanding hours divided by weekly capacity. In weeks it becomes a number managers can act on, unlike a raw work order count.
• Estimate accuracy. Actual against estimated hours on PM work orders: the feedback loop that keeps your levelling arithmetic honest.

The broader measurement frame is covered in the FM KPI framework. On whether optimisation tooling helps with the levelling arithmetic itself, the AI schedule and resource optimisation guide takes the honest view: useful once your hour estimates and capacity model are trustworthy, and it amplifies your errors when they are not.

12. The build sequence, in order

Compressed into a checklist a planner can work through. The order matters; each step consumes the output of the one before.

Step ten is the one that gets skipped under delivery pressure, and it is the one that determines whether the other thirteen were worth doing. If you have time for only one thing on this list beyond the basics, pull the forecast and level it.

The idea to walk away with

A preventive maintenance schedule is a capacity plan wearing a maintenance costume. The task content, the intervals and the triggers are the engineering half, and they get most of the attention because they feel like the technical work. But the reason schedules fail is almost always the other half: nobody added up the hours, compared them to the crew, and moved the start dates until the two matched. That is unglamorous arithmetic and it is the entire difference between a PM programme that runs above ninety percent compliance and one that generates a backlog on day one and never recovers.

The corollary is that a schedule is not a document you produce once. Duty cycles change, assets get added, crews shrink, and the failure history keeps telling you things about your intervals you did not know at go-live. Treat the forecast-and-level cycle as a standing quarterly task, not a project deliverable.

Final thoughts

If you are inheriting a broken PM schedule rather than building a new one, the diagnostic sequence is short. Pull the 52-week forecast by trade and look for the wall. Calculate net capacity honestly and compare. Check how many PMs carry a labour hour estimate at all, because if most are blank you have found the root cause. Check whether annual PMs are clustered in one or two months. Check whether compliance is being measured against a defined window or against eventual completion. In most cases those five checks locate the whole problem, and the fix is start dates and honest capacity arithmetic rather than new software.

And hold the line on the frequency question. Manufacturer intervals are conservative, and there is genuine waste to recover by optimising them, but that recovery is earned with documented evidence, one asset class at a time, with statutory work left entirely alone. A schedule that is levelled, measured and reviewed will surface those optimisation opportunities to you with evidence attached. A schedule that was never levelled will only ever tell you that the team is behind.

Related reading: Preventive maintenance: the complete guide, Preventive maintenance strategies, PM programme design: quality over quantity, Asset hierarchy design, Asset criticality classification, Work order types in a CMMS, FM KPI framework.