IEC 60300-3-11: the rulebook for when your RCM programme needs to survive an audit.

Why a standard for RCM at all

RCM has a lineage. It started with Nowlan & Heap's aviation research in 1978, was turned into an industrial method by Moubray's RCM II, and was then formalized twice: SAE JA1011 defined the criteria a process must meet to call itself RCM, and the IEC published this application guide inside its wider 60300 dependability management family. Roughly speaking, JA1011 answers "is this really RCM?" while IEC 60300-3-11 answers "how do I set up and run an RCM programme?" - selection of systems, the analysis itself, task decisions, implementation, and keeping the whole thing alive afterwards.

Why should you, a working reliability engineer with a backlog and three bad actors, care about a Geneva document? Because the word "RCM" has been abused for decades. Sites have paid six figures for "RCM studies" that were a spreadsheet of OEM tasks with new column headers. When a process has to line up against an international standard, that trick stops working. The standard is not the method - it is the quality bar for the method.

A few things in that loop deserve your attention:

• It starts before the analysis. Management commitment, trained people, defined scope and access to data come first. An RCM study launched without a sponsor who will fund the resulting changes is a workshop that produces a PDF.
• You do not analyse everything. Systems are selected and ranked - typically by criticality - so the effort lands on the crusher feed conveyor and the boiler feed pumps, not on the workshop bench grinder.
• The analytical core is functional. Functions and performance standards first, then the ways they can be lost, then the failure modes and their effects - the FMEA discipline. Task selection follows from consequences: condition-based tasks where you can detect deterioration, scheduled restoration or discard where age genuinely matters, failure-finding tests for hidden failures of protective devices, deliberate run-to-failure where consequences are tolerable, and redesign when no task deals with the risk.
• Step 06 is the whole point. The guide treats RCM as a living programme: failures and near-misses feed back into the analysis, intervals get reviewed against real behaviour, and the plan is re-baselined as the operating context changes. This is the part almost every site skips - and it is exactly what separates a programme from a binder.

• A common language. When the owner, the maintenance contractor and the regulator all anchor on the same reference, "we did RCM" means something checkable. Function, functional failure, failure mode, failure-finding: everyone argues about the same things, in the same terms, across sites and across contracts.
• Defensibility. In regulated industries, in safety cases and in front of insurers, "why is this pump on a 6-month inspection?" needs a better answer than "it's always been like that". A programme run along the lines of the standard gives you a traceable chain: this task exists because of this failure mode, which matters because of this consequence, reviewed on this date. That chain is what an auditor actually reads. It is also what protects the engineer who signed the decision to let the redundant sump pump run to failure.
• A filter against RCM-in-name-only. If a vendor's "accelerated RCM" cannot show functions, failure modes, consequence-based task selection and a plan to keep the analysis alive, then whatever they are selling, it is not RCM. Ask them to map their process to the standard before you sign. Watch how fast the meeting gets interesting.

None of this is bureaucracy for its own sake. The day a conveyor pulley failure injures someone, the difference between "our PM programme is a pile of inherited tasks" and "our PM programme is a documented, standard-aligned decision record" is not academic. One of them survives the investigation.

Practical reading order for a plant engineer: Moubray for the method, JA1011 to keep vendors honest, and this IEC guide when the programme becomes official - written into contracts, safety cases or corporate standards.

What it will not do. It will not teach you facilitation - getting an operator, a fitter and a process engineer to agree on what "failed" means for slurry pump P-201 is a craft the document cannot transfer. It will not pick a failure mode, set an interval, or argue with production for the shutdown window. A standard keeps your process honest; your engineers still do the thinking.

What changed since 2009. The logic has aged well - it was never about technology. What has changed is the cost of doing it properly. In 2009, a full RCM programme meant months of workshops per system, which is why so many sites bought the diluted version. In 2026, the heavy lifting - drafting functions from P&IDs and manuals, mining the CMMS for failure history on your compressors and conveyors, pre-populating FMEA worksheets - can be done by AI in days, leaving humans to validate, challenge and decide. The standard's expectations stop being expensive. That kills the last excuse for RCM-in-name-only.

The trap to avoid. Do not let the programme become paperwork-first. The point of aligning with the standard is defensible decisions on real equipment, not a compliance shelf. If your RCM records are pristine but the seal on the loading pump has failed three times this year without triggering a review, you have the binder, not the programme.