PMS Setup Best Practices — Building It Right the First Time

A planned maintenance system is one of the most consequential pieces of digital infrastructure on a vessel. Done well, it makes the chief engineer's life easier, satisfies class and audit requirements, and provides the data backbone for performance and reliability decisions. Done poorly, it becomes the thing everyone ignores until the next survey panic. The difference between the two is usually established in the first three months of setup. This article works through what separates the two.

The trap most managers fall into

The most common failure mode in PMS setup is treating it as a data entry exercise. A maintenance coordinator opens the CMMS software, the OEM manuals come out, and someone starts typing components and maintenance jobs into the system. Six months later there are several thousand entries, the system is technically live, and nobody on the vessel finds it useful.

The reason is that PMS is not data entry. It is data architecture. The choices made about hierarchy, naming conventions, criticality classification, and interval logic in the first few weeks determine whether the system will be useful for years afterwards, or whether it will need a costly rebuild.

The component hierarchy question

Every PMS rests on a hierarchical structure that organises components from vessel level down to individual replaceable parts. The hierarchy typically runs to four or five levels:

• Level 1: Vessel
• Level 2: System (Main Engine, Auxiliary Engine, Boilers, Steering Gear, Cargo Systems, etc.)
• Level 3: Sub-system (Fuel Oil System, Lubricating Oil System, Cooling System, etc.)
• Level 4: Component (Fuel Oil Booster Pump No. 1, Fresh Water Cooler, etc.)
• Level 5: Sub-component (bearings, valves, sensors)

The questions that matter at this stage are where the hierarchy terminates, how naming is standardised across vessels in a fleet, and whether the structure will accommodate components added later in life. Inconsistency here makes fleet-wide reporting and benchmarking effectively impossible.

Criticality classification — the most important field

Every component should carry a criticality classification that drives maintenance priority and survey requirements. The classification typically runs along the following lines:

• Critical: failure threatens vessel, life, or environment, or stops operations
• Important: failure causes operational degradation but not immediate safety risk
• Standard: failure affects efficiency or convenience but operations continue

This classification is not bureaucratic decoration. It drives spare parts holding decisions, maintenance interval logic, condition monitoring scope, and survey planning. Vessels with poorly classified PMS data find themselves either holding excessive spares (capital tied up) or running short of critical spares at the worst moment.

Interval logic — calendar versus condition

Default OEM maintenance intervals are conservative for good reason: the OEM has to write intervals that work across every possible operating condition. For a specific vessel in a specific service, those intervals are often either too conservative (resulting in unnecessary maintenance cost) or insufficient (resulting in premature failure).

The maturity of a PMS programme can be judged by how much of it has moved from pure calendar-based intervals to condition-based or hybrid logic. The transition typically takes 18 to 24 months of operating data and disciplined analysis.

A well-tuned PMS programme reduces maintenance hours and parts cost by 15 to 25 percent compared to running pure OEM intervals, without increasing failure rates. The savings fund the analytical work several times over.

What good looks like across the fleet

Mature PMS implementations across a fleet share certain characteristics:

• Consistent naming — component naming follows a standard across all vessels, enabling fleet-wide reporting
• Class-aligned data — survey-related components are flagged and the system tracks survey dates and class requirements directly
• Linked spares — each component links to its required spares, with criticality-based holding levels defined
• Condition data integration — vibration measurements, oil analysis, and thermal readings feed back into the PMS, not just sit in separate reports
• Audit-ready records — jobs completed are documented with photos, signatures, and observations, not just ticked off

Migration projects — the rebuild question

Many fleet managers eventually face a decision about whether to rebuild their PMS or migrate it. The rebuild is usually triggered by one of three things: switching CMMS platforms, undergoing a management change, or recognising that the existing data is too compromised to keep working with.

Rebuilds are not undertaken lightly. A full PMS rebuild for a single vessel typically takes six to eight weeks of focused work, depending on vessel complexity. For a fleet of ten vessels, this becomes a year-long project that requires careful sequencing.

Done properly, however, a rebuild resets the maintenance economics of the fleet for a decade. The capital case for doing it well is rarely in doubt; what is usually missing is the disciplined methodology to execute it.

The questions to ask before starting

For any operator considering a new PMS implementation, migration, or rebuild, three questions tend to determine whether the project succeeds:

1. Has the component hierarchy been designed before any data entry begins, or is it being made up as people go?
2. Has criticality classification been agreed across the fleet, or is each superintendent applying their own judgement?
3. Is there a plan for moving from calendar-based to condition-based intervals over the first 24 months of operation, or is the system being set up to run on OEM defaults forever?

A clear answer to all three suggests the project will produce a useful system. Vague answers to any of them suggest a rebuild will be needed within five years.