Implement, Live & Continuously Improve

Purpose

RCM only pays back once the tasks are actually being executed and the results are being reviewed. Phase 7 turns the analysis into a live PM programme with feedback loops.

Scope

PM task loading and job plan build in the CMMS
Deletion or supersession of legacy PMs
Reliability KPIs: MTBF, MTTR, PM compliance, bad-actor list
Trigger events for re-analysis (context change, repeated failure, incident)

Process Steps

01
Build job plans and load PMs
Intent
Convert every accepted task into a CMMS job plan with steps, materials, labour, safety and permits so it can be released and executed cleanly.
Inputs
- Accepted task list from Phase 6 with interval, duration, trade and instructions
- Standard job-plan template
- Spare-parts catalogue and permit-to-work register
Actions
- Use the standard job-plan template — no ad-hoc formats
- Cross-check spares availability and permit / isolation requirements
- Load PM plans, task lists and maintenance items into the CMMS
- Peer-review each plan before release
People
Planner builds. Reliability engineer signs off content. Supervisor sanity-checks execution feasibility.
Process
No PM goes live without peer review. Loading is done in controlled batches so KPI baselining is possible.
Technology
CMMS PM plan module; job-plan library; spares master data; permit register.
What Good Looks Like
- Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
- The opposite of: pMs loaded without linked spares or permits
- The opposite of: ad-hoc job plans that skip the template
- The opposite of: no peer review
What Bad Looks Like
- PMs loaded without linked spares or permits — trades stop the job
- Ad-hoc job plans that skip the template
- No peer review — quality drift shows up months later
Outputs
- PM plans loaded and active in the CMMS
- Job-plan library entries with linked spares and permits
02
Retire superseded PMs
Intent
Every legacy PM the RCM replaces must be retired or archived — running old and new together doubles labour and confuses trades.
Inputs
- Cross-reference list of new PMs vs existing PMs
- Planner + supervisor endorsement
- CMMS change-control process
Actions
- Publish the change list before go-live
- Get planner and supervisor sign-off on every retirement
- Deactivate legacy PMs in the CMMS under controlled change
- Confirm no orphaned work orders remain in the backlog
People
Planner drives. Supervisor approves. Reliability engineer confirms the RCM task fully replaces the legacy PM.
Process
Retirement happens on the same day the replacement PM goes live — never a lag that leaves both running.
Technology
CMMS PM plan module with change-control audit trail.
What Good Looks Like
- Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
- The opposite of: legacy PMs left running alongside new ones
- The opposite of: silent deactivation with no register
- The opposite of: orphaned open work orders keep triggering after PM retirement
What Bad Looks Like
- Legacy PMs left running alongside new ones — double labour, no reliability gain
- Silent deactivation with no register — impossible to audit later
- Orphaned open work orders keep triggering after PM retirement
Outputs
- Retired-PM register with dates and approver
- Clean PM schedule with no duplicates
03
Measure outcomes
Intent
Track PM compliance, MTBF, MTTR and functional-failure recurrence against a documented baseline to prove the analysis is paying back.
Inputs
- Baseline reliability KPIs captured before RCM go-live
- CMMS reporting suite (PM compliance, MTBF, MTTR)
- Functional-failure recurrence data
Actions
- Set the baseline before implementation — not after
- Publish monthly KPI report to operations and reliability governance
- Investigate every recurring failure to confirm the RCM task is doing its job
People
Reliability engineer owns KPIs. Supervisor drives PM compliance. Asset owner sponsors the monthly review.
Process
KPIs are published, not just calculated. Every miss triggers a documented action, not silent tolerance.
Technology
CMMS KPI dashboard; reliability-analysis tool; monthly review pack template.
What Good Looks Like
- Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
- The opposite of: no baseline captured
- The opposite of: kPIs calculated but never published
- The opposite of: recurring failures not traced back to the RCM row that should have prevented them
What Bad Looks Like
- No baseline captured — impossible to prove payback
- KPIs calculated but never published
- Recurring failures not traced back to the RCM row that should have prevented them
Outputs
- Baseline vs actual KPI report on a fixed monthly cadence
- Recurrence investigations linked back to specific RCM rows
04
Trigger re-analysis
Intent
Re-open the RCM when duty, environment, throughput or the asset itself changes so the analysis stays current.
Inputs
- Log of process, throughput or context changes
- Incident and RCFA outputs
- Bad-actor recurrence data
Actions
- Log every context change with date and description
- Re-analyse after any major incident or repeated bad-actor failure
- Schedule a rolling review cadence (e.g. 3–5 years) for stable assets
People
Reliability engineer triggers. Asset owner sponsors. Original facilitator re-convenes the workshop team where possible.
Process
RCM is a living document — treat the first pass as the start, not the end. Re-analysis is triggered by events, not calendars alone.
Technology
Re-analysis register; change-log; incident / RCFA system.
What Good Looks Like
- Every reliability, maintenance and operations lead can point to where this step lives — decisions, evidence and outputs are in one place, not in someone's inbox.
- The opposite of: first-pass analysis frozen
- The opposite of: re-analysis called only after a serious incident
- The opposite of: no sponsor for re-analysis
What Bad Looks Like
- First-pass analysis frozen — never re-opened even after context change
- Re-analysis called only after a serious incident
- No sponsor for re-analysis — the trigger is logged but never acted on
Outputs
- Re-analysis register with trigger events and outcomes
- Updated RCM pack after each re-analysis

People

Planner loads PMs. Supervisor drives compliance. Reliability engineer owns the outcome KPIs. Asset owner sponsors reviews.

Process

RCM is a living document — treat the first pass as the start, not the end.

Technology

CMMS PM module, job plan library, KPI dashboard, engineering change register.

Phase Outputs

Live PM programme aligned to the RCM analysis
Baseline vs actual reliability KPIs
Re-analysis register

What Good Looks Like

Every reliability, maintenance and operations lead can point to where this phase lives — decisions, evidence and outputs are all in one place, not in someone's inbox.
The opposite of: analysis on the shelf
The opposite of: old PMs left running alongside new ones
The opposite of: no KPI baseline