CMMS Rollout on Board: The Six Mistakes That Sink the Project

A CMMS rollout almost never fails on the day it goes live. It fails three to six months later, quietly. Work orders stay open, the crew goes back to the paper folder, and at the next visit the chief engineer produces a report nobody recognises. The software works perfectly well. It is the rollout that has drifted.

This article is not the how-to. It is the opposite view: the failure modes. What breaks a CMMS rollout on board, why it breaks, and what to do instead. Six of them, all seen on vessels in service, all recoverable if you catch them early.

None of these is a change management problem. They are technical mistakes, specific to running a ship: a maintenance programme sized for a maker's catalogue, an equipment register inherited from a spreadsheet, a crew that rotates every six weeks, an engine room with no signal, and an ISM audit that asks for records rather than ticked boxes.

The six failure modes at a glance

These six situations share one thing: the visible symptom nearly always points at the wrong culprit. The crew gets blamed, or the interface, or bad luck, when the cause sits upstream in the set-up or in the data.

Mistake 1: loading the maker's maintenance programme unedited

The symptom

The vessel starts with a maintenance programme that looks immaculate on paper. Every maker's manual has been keyed in line by line: main engine, auxiliaries, generators, starting air compressors, separators, winches, windlass, steering gear. Several thousand active tasks on a mid-sized vessel.

Six weeks in, the dashboard is red and nobody opens it any more. The chief engineer does what he has always done: he deals with what needs dealing with, in the order he judges right, and ignores the system. The accumulated overdue count grows past the point of recovery, and therefore past the point of meaning. At that stage the overdue figure no longer measures the condition of the ship. It measures the gap between the ship and an unrealistic plan.

The cause

A maker's programme is not a ship's maintenance programme. It is a liability position: the engine builder describes what has to be done for its warranty to stand up under the harshest duty. It knows nothing about your trading pattern, nothing about the hours each machine actually runs, and nothing about the fact that your number three auxiliary only runs as standby alongside.

A deep-sea trawler on twenty-day trips, a ferry turning round eight times a day and an offshore wind service vessel standing by on site do not wear the same components at the same rate. Applying one programme to all three guarantees that two of them will be doing unnecessary work while the things that matter slip.

The fix

Treat the maker's programme as raw material, not as a deliverable. Work through it task by task before you load it, against three tests: how critical the equipment is, how the machine is actually used on board, and whether an external class or certification requirement is attached to it.

Start with criticality. The ISM Code, at 10.3, requires the identification of equipment and technical systems whose sudden operational failure may result in hazardous situations. That list is your floor: on those items the maker's interval is not up for discussion.

Next, separate what belongs to a class-approved planned maintenance system from what does not. The first block is untouchable and has to stay recorded in the form the society expects. The second is open to judgement: interval, grouping, or removal altogether.

Finally, move whatever can be moved from calendar to running hours. A monthly task on a machine that runs thirty hours a year is a phantom task. The same task triggered on counter reading reflects the real condition of the component.

A tight starting programme the crew completes in full is worth far more than an exhaustive one completed a fifth of the time. You add to it later, as history builds and trends become visible.

Mistake 2: migrating a dirty equipment register into a clean system

The symptom

The equipment register is loaded, but nobody can navigate it. The same compressor appears three times: once under its maker's designation, once as "port compressor", once as "the little one to port". An auxiliary engine is identified by serial number on one line and by position number on another. Spares held on board are linked to a unit that was landed two years ago.

The result is that search returns nothing useful, the crew logs hours against the wrong machine, and maintenance history scatters across three records instead of accumulating on one. The CMMS reproduces the disorder of the original spreadsheet faithfully, and less forgivingly, because you can no longer fix a cell with one keystroke.

The cause

Data migration is almost always underestimated. It gets treated as an export-and-import exercise when it is really a normalisation exercise. The source spreadsheet has been alive for ten years, fed by five people in succession, each with a naming convention of their own, and nobody ever had a reason to clean it because a human who knew the ship could always find their way around it.

That is exactly where a spreadsheet stops being a management tool: the flexibility that makes it easy is also what lets it accumulate inconsistencies for a decade with nothing flagging the problem. A CMMS does not tolerate ambiguity, which is good news, provided the tidying is done first.

The fix

Clean before you load, not after. The order matters, because once work orders are attached to equipment records, merging two duplicates becomes a heavy operation that puts history at risk.

Three rules head off most of the damage. One equipment item, one unique identifier, decided ashore and imposed across the fleet; the shipboard nickname can live as a secondary label, never as the key. An equipment tree that follows the physical structure of the vessel rather than the crew organisation chart: vessel, department, system, equipment, sub-assembly. And a filter on the history you bring over: keep only what is dated, attributable to an identified item, and useful to a future decision. Five years of doubtful records are worth less than eighteen months of reliable ones.

Physical marking closes the loop. As long as the identifier exists only in the software, the crew will keep using the nickname. A label on the machine itself, readable from the working platform, aligns the deck plates with the register. That is the whole point of QR code asset tagging: the engineer scans, lands on the right record, and the naming question stops being a question.

Mistake 3: setting the system up around the crew on board today

The symptom

The rollout went beautifully. The second engineer of the day took to it, built the equipment tree, wrote the job plans, set the intervals. For two months the vessel is the reference case.

Then he pays off. The relief arrives, opens the CMMS, and finds job plans that read "check clearance as per usual procedure" or "check tightening to the correct torque". Which usual procedure? What torque? The new engineer does not know, has no time to go looking, does it the way his experience tells him, and ticks the box. Three crew changes later nobody can say why that interval was set at 250 hours, and the system has become a form people fill in without reading.

The cause

Crew rotation is the defining constraint of shipboard maintenance, and it is the one most often forgotten at set-up. Ashore, a maintenance team stays in place for years and tacit knowledge passes on by simple presence. On board, the whole team can be replaced in a single port call. Any knowledge that is not written down leaves with the person who paid off.

The ISM Code anticipates precisely this. Chapter 6 requires the company to establish procedures ensuring that personnel who are new, or transferred to new assignments, are given proper familiarisation with their duties. A CMMS whose configuration is understood only by the person who built it sits directly against that requirement.

The fix

The knowledge has to live in the job plans, not in people's heads. In practice, a job plan a relief engineer can use on a vessel he has never sailed contains the tools required, the isolation and safety instructions, the expected values with their tolerances, the tightening torques, the part and consumable references, and the criterion that triggers an alert. Miss any one of those and the task goes back to depending on whoever wrote it. We set out that structure in detail in our article on job plans and intervention standards.

Two habits reinforce it. First, have the critical job plans read by somebody who took no part in the set-up, ideally an engineer from another vessel in the fleet. Whatever is missing for him will be missing for the relief. Second, record the reasoning behind the configuration, not only the result: why that interval, why that item was classed critical, why that task was removed from the maker's programme. A comment field on the job plan is enough. Without it the next crew will redo the same judgements, in the opposite direction.

Finally, design the handover to happen inside the system. What a joining engineer needs on day one is the open work orders, the unresolved defects and the due dates for the next three weeks. If that view exists and is trustworthy, the CMMS becomes the handover. If it does not, the handover will happen verbally at the gangway, exactly as before.

Mistake 4: treating offline working as a nice-to-have

The symptom

Recording happens in bursts. On Friday evening, or on the day of the port call, a dozen work orders are closed at once, all with the same timestamp and terse comments. The recorded values are suspiciously round: 80 °C, 4 bar, 250 hours. Nobody is lying. It is simply that nobody remembers the exact figure read three days earlier at the bottom of the engine room.

And some of it never gets recorded at all. The job was done, and done well, but it left no trace, because when the work happened there was no signal, and when there was signal there was something more pressing.

The cause

A CMMS designed for a shore site assumes connectivity is a given. On board it is the reverse. The satellite link is limited, expensive and shared with operations, and it drops. Even on a well-connected vessel the engine room is a Faraday cage: steel bulkheads, decks, technical spaces down in the bilges. The bridge Wi-Fi does not reach the shaft tunnel.

Which is exactly where the data has value. A temperature read at the machine, at the moment of the check, is data. The same reading reconstructed from memory in the cabin that evening is an approximation that contaminates every trend built on top of it.

The fix

Offline capability is not a comfort feature, it is a knock-out criterion when choosing the system. Three things need checking before you sign, not after.

First, how far the offline mode goes: can you only read, or can you raise a work order, record a value, attach a photograph and sign, with no connection at all? Second, the synchronisation logic: what happens when two people have edited the same record offline, and how long can a device stay disconnected before it loses its queue? Third, the volume exchanged on reconnection, which has to be compatible with a satellite link billed by the megabyte.

Test it in real conditions before the fleet rollout: one engineer, one tablet in flight mode, a full engine room round, then synchronise. What that test reveals in an hour, a rollout reveals in six months. The underlying principle is the one behind the mobile digital work order: if the record cannot be made at the machine, it will be made from memory that evening, or not at all.

Mistake 5: confusing the system with the evidence

The symptom

The completion rate is excellent. Everything is green. Then an ISM auditor opens three work orders at random and asks, for each one, what was found. All three records contain a ticked box and the word "OK". No reading, no photograph, no part reference, and a generic signature from a shared account.

The same scene plays out at Port State Control. The inspector does not dispute that the work was done. He notes that there is nothing to establish it. And a documentary finding on safety equipment weighs a great deal more than an isolated technical one.

The cause

A CMMS is usually sold, and understood, as a planning tool. It is one. But in a maritime context its most defensible function is as a system of record. The ISM Code does not require maintenance to be planned in software; it requires inspections to be held at appropriate intervals and the corresponding records to be kept and available. A ticked box is not a record, it is an assertion.

The underlying error is treating data entry as paperwork that follows the work, when it is part of the work. We develop that logic in our article on the ISM Code and maintenance compliance on board.

The fix

Make the evidence mandatory at close-out, in the job plan itself rather than in anyone's good intentions. A work order on critical equipment should not be closeable without the fields that make it stand up.

Two things to watch. Shared accounts of the "engine" or "deck" kind destroy the attributability of everything entered under them, so each person needs a named account. And a defect found has to generate its own record, tracked separately until it is closed. A fault noted and then buried in the comment field of a completed work order is exactly what an inspector is looking for. Our article on avoiding detention at Port State Control covers the documentary deficiencies most often raised.

Mistake 6: running the rollout with no measurement

The symptom

Six months after go-live, somebody ashore opens the system and finds the real picture: of eight vessels, two are up to date, three are recording partially, three have given up. Nobody saw it coming, because nobody was looking. The progress meetings tracked the project calendar, not actual use.

Yet the drift is slow and perfectly visible in the data. A vessel does not stop overnight: its backlog climbs steadily, its preventive completion rate erodes, and the average delay between a task falling due and being closed stretches out. Those signals are there by week six or eight.

The cause

A rollout gets managed as an IT project, with installation milestones, when it is a change in working method whose only measurable outcome is use. A vessel that has been "rolled out" is not a vessel where the software is installed. It is a vessel where maintenance is genuinely run from the software.

The fix

Three measures are enough for the rollout phase, followed per vessel and never as a fleet average. The average hides precisely what you are looking for, which is the vessel falling behind.

• Preventive completion rate, calculated on tasks falling due within the period. A steady decline across three periods is a signal, not an accident.
• Backlog, expressed in outstanding labour hours rather than in number of tasks, so that twenty five-minute readings are not confused with a three-day overhaul.
• Delay between due date and close-out, which tells you whether the crew is working with the system as they go or regularising after the event.

Set the alert threshold before the rollout, not once the figure looks bad. And decide in advance what happens when it is crossed: a call to the vessel, not a chasing email. Nine times out of ten a vessel falling behind has a specific and fixable reason — a programme still too heavy, a job plan nobody understands, a tablet that will not synchronise. How to define and read these measures is covered in our article on maintenance KPIs: MTBF, MTTR and backlog.

One point of method: during the first months these numbers exist to find vessels in difficulty, not to rank them. The day the crew works out that the completion rate is being used to score them, it becomes excellent and stops meaning anything.

What makes a rollout hold

The six mistakes above have one thing in common. Each transplants onto a ship a maintenance logic designed somewhere else. A maker's programme written to cover a warranty. A register inherited from a spreadsheet only its author could read. A configuration that assumes a stable team. Software that assumes a network. Data entry that assumes nobody will ask for proof. A project assumed complete because it was delivered.

A rollout that holds starts from the opposite constraint. The vessel is isolated, the crew rotates, connectivity is uncertain, and everything done will one day have to be shown. A system configured against those constraints also works in the easy cases. The reverse is not true.

If you are starting now, take it in order: edit the programme before loading it, clean the register before migrating it, write job plans for somebody who is not on board yet, test offline working in the engine room, make the evidence mandatory at close-out, and look at three numbers every week. If you want to test these six points against your own operation, let us talk about your fleet.