A Maximo PM that fires once a fortnight on every pump in a station sounds harmless on the configuration screen. Multiply it across an estate of a few thousand assets, add a handful of parents and children, set the lead time to a generous number, and the cron task quietly hands the planning team a queue they cannot work through. Maximo PM design is one of the few configuration areas where a small decision early translates directly into supervisor frustration twelve months later. This piece sets out the patterns that keep the PM library generating work the field can actually do.
The focus here is IBM Maximo Manage, including under MAS. Most of the mechanics described have existed since well before MAS and apply equally to Maximo 7.6.1 estates that have not yet upgraded.
What a PM Actually Generates
A PM record in Maximo Manage carries the asset or location it applies to, one or more job plans, a frequency (time-based, meter-based, or both), an active date range, optional active days and active months, and the operational state that controls whether it is generating at all. When the PM is active and due, the work order generation routine creates a work order against the asset, applies the relevant job plan, and stamps the next due date based on the frequency rule.
Two points get missed routinely. The first is that the PM and the work order are different records with different lifecycles; editing the PM today does not change work orders already generated from it. The second is that a PM can carry both a time frequency and a meter frequency, and the default behaviour is that whichever comes due first will trigger generation. IBM Support documents this: a PM with a 30 day frequency and a 100 hour meter frequency will generate at 30 days or 100 hours, whichever is first. The explicit option “Use this PM only when meter frequency is reached” changes the behaviour. Estates that want duty-driven PMs and do not tick that option will see calendar-driven work orders they did not intend to create.
Frequencies That Match the Operating Reality
Frequency is where most PM libraries drift. The honest test is whether the cycle reflects the failure behaviour of the asset or the comfort of the planner who built the record. Annual inspections fixed to a calendar quarter, monthly tasks set to thirty days because the previous CMMS did it that way, weekly walkdowns that were a habit on the old paper round, all of these accumulate in a library that nobody curates.
The pattern that holds up:
- Calendar frequencies for genuinely calendar-driven work. Statutory inspections, lubrication routes, seasonal preparation. The frequency matches the regulator or the operating cycle, not a round number.
- Meter frequencies for duty-driven work. Running hours on a rotating asset, kilometres on a vehicle, cycles on a press. These earn their keep when usage varies materially between assets that look similar on paper.
- A combined frequency only when both axes genuinely apply, and with explicit thought given to the “only when meter frequency is reached” option. Otherwise the calendar axis silently wins for assets that have been idle.
- Condition-based triggers handled through Maximo Health or Maximo Predict where the data supports it, not bolted onto a PM as a workaround for a missing strategy.
A PM whose frequency cannot be defended in a short conversation with the reliability lead should be challenged. A library full of those is what fills the queue.
Hierarchies Used Where They Earn Their Keep
PM hierarchies are well established in Maximo Manage. A PM can have a parent, and a child PM can have only one parent. IBM documentation has long described this for situations where related work needs to be coordinated against an asset hierarchy or a location hierarchy. The parent PM generates a parent work order and the children generate child work orders linked to it.
The hierarchy is genuinely useful in three cases:
- A complex asset where a parent inspection and several child tasks must be planned and dispatched together, with labour and material costs rolling up to the parent.
- A location hierarchy where the same outage window covers a primary asset and auxiliary equipment, and the planner wants one dispatchable package.
- A route-style inspection where the parent record represents the round and the children represent the stops.
It is the wrong tool for grouping unrelated PMs that happen to share an asset class. The simpler approach for unrelated PMs against the same asset is several flat PMs with sensible scheduling.
A meter-driven parent is the classic pitfall. A parent PM whose frequency is driven by a meter will pull its children with it. If the children would otherwise have been on independent calendar cycles, the result is premature child work orders the supervisor has not asked for.
Lead Time, Slack Time and the Cron Task
The PM record has a lead time on its frequency tab. This is the number of days in advance of the next due date that the generation routine will create a work order. Slack time is the parameter on the Generate Work Orders action that controls how far into the future the routine looks during a given run. The PMWoGenCronTask runs generation as a background job on a schedule, against the sites it is configured for.
The interactions matter:
- Lead time set too generously will pre-create work orders that sit unstarted for weeks, displacing real planning attention. A two-week lead time on a monthly PM means the queue is permanently a fortnight ahead of where the work actually is.
- Slack time on a manual run can pull months of forecast work into the queue in a single click. This is occasionally useful for a planning week, regularly disastrous when used to “catch up” a library that is misconfigured.
- The cron task should be on a defined cadence, with a known instance per site or set of sites, logged. A silent PMWoGenCronTask failure is a category of incident that surfaces, eventually, as a supervisor wondering where last week’s PMs went.
PM Forecast is a separate tool. It generates forecast records, not work orders, to give scheduling visibility further out. A forecast date populated on a PM will override the calculated next due date when generation occurs. Estates that mix forecasted PMs and calendar-driven PMs without understanding this end up with work orders on dates the planning team did not anticipate.
Owning the Backlog
The configuration only earns its keep if someone owns what comes out of it. The PM library, like the job plan library that feeds it, is a controlled artefact and benefits from the same discipline:
- A named owner per asset class or trade, with authority to retire PMs that no longer match the strategy.
- An annual review against the maintenance strategy at the asset level, not against the convenience of the planning team.
- A rule for inactivating PMs whose work orders are consistently cancelled, deferred or closed-as-not-required. A PM that the field rejects nine times in ten is not protecting the asset; it is producing noise.
- Clear reporting on PM compliance that distinguishes work the field did not have time for from work the supervisor decided was unnecessary. Both are signals; they are not the same signal.
Operators that pair this with a sensible work order priority model and active backlog management find that the queue stabilises. The PM library shrinks rather than grows, and the frequencies that survive review are the ones that match how the assets actually run.
Closing Position
A PM in Maximo Manage is a small record that controls a very large amount of downstream work. Frequencies chosen against operating reality, hierarchies used where they earn their keep, lead time and slack time held in proportion to the planning horizon, and a named owner for the library, are the configuration choices that decide whether the queue is a plan the field can run or a backlog nobody touches. The configuration screens are not difficult; the discipline is.