Maritime CMMS Implementation Checklist: Phase by Phase, Ship by Ship

Implementing a CMMS on a ship is not an office software project. The vessel is not available when you are. The crew that builds the asset register will not be the crew using it in six months. Half the data you want to migrate sits in a folder that has never left the bridge. And the only thing that will really matter is whether an inspector can open the system a year from now and find what he is looking for, without being told the history of the project first.

This article is a chronological checklist. Phase by phase, in the order the work actually happens on board: what has to be dealt with, who owns it ashore and who owns it on the ship, what gets delivered, and the criterion that lets you say a phase is finished. The tables are on this page. There is nothing to download.

The programme belongs to the ship, not to the project

Accept this first: your project schedule does not exist. What exists is the vessel's operating programme. The only moments when you can do anything useful on board are long port calls, seasonal lay-up, planned technical stops and dry-docking. In between, you will see neither the chief engineer nor the nameplates.

Before announcing a go-live date, write down the pilot vessel's next three real windows: the next long alongside period, the next full crew change, the next time she comes out of the water. Everything else fits into those windows. A rollout that ignores this ends up with an asset register built from a desk ashore, from photographs, with wrong serial numbers. And during peak operating season you impose nothing: you observe.

Phase 0 — Before you sign

Scope. How many vessels, which ones, in what order. A deep-sea trawler, a passenger ferry and an offshore wind service vessel do not share the same asset structure, the same documentary requirements or the same port call rhythm. Write the list out with, for each ship, her type, flag, classification society and rollout position. Identify sister ships immediately: they will save you most of the configuration effort.

Ownership. A CMMS project needs two names, not a steering committee. One owner ashore, usually the superintendent or technical manager, who decides the naming convention and settles disputes. One owner on board per vessel, most often the chief engineer, who knows the machinery and whom the crew will listen to. Both need time released, not time added.

The proof you will be asked for. Write down now what you want to be able to show in a year. Not "improve maintenance", but questions phrased the way an inspector phrases them: show me the last five jobs on the emergency generator; show me that the starting air compressor was overhauled at the maker's recommended interval; show me who did that job and when. Those questions become the real specification for your configuration. If you are still comparing suppliers, our guide on how to choose maritime CMMS software covers this stage.

Phase 1 — The asset register, which everything else depends on

This phase decides the quality of everything that follows: a maintenance plan is worthless if it points at assets that are badly named or entered twice. Three levels are enough for the vast majority of fleets: vessel, system, asset. Propulsion, power generation, compressed air, fuel oil, sea water systems, steering gear, lifting appliances, safety equipment, fishing gear or cargo handling depending on the trade. Under each system sit the physical assets, the ones that carry a nameplate. The classic trap is to mirror the current org chart: org charts change, the shaft line does not.

The naming convention must be stable and written down. One simple rule, with examples, and two people naming the same asset independently must produce the same string. That is the only test that counts. On board, the longest job is the physical survey: make, type, serial number, year, rating, plus a photograph of the nameplate. The photograph saves endless argument over worn stampings and it pays for itself later when a spare has to be ordered. Schedule the survey during a port call, with a crew member who knows the spaces, never from a desk ashore. The equipment and asset hierarchy module fills up quickly once that groundwork is done.

Finally, criticality. The ISM Code requires you to identify equipment and technical systems whose sudden operational failure may result in hazardous situations (chapter 10.3). This list is not a paperwork exercise: it drives which tasks take priority, which spares count as critical and which due dates cannot be allowed to slip.

Phase 2 — Migrating what already exists

You have a spreadsheet. You also have a folder in the engine control room, a notebook in the chief's drawer and purchase orders in somebody's mailbox. Not all of it is worth migrating, and trying to migrate all of it is the surest way never to start. The useful rule: bring across what you need to make decisions tomorrow, archive the rest. In practice that means current running hours, the last known job on each critical asset, open due dates, valid certificates and the spares actually on board. Not ten years of line-by-line history: keep that file read-only, dated and reachable, but do not make it a condition of going live.

The clean-up is about duplicates. De-duplicate on serial number, never on description: "LT pump no. 2", "fresh water LT pump 2" and "LT pump stbd" are usually the same machine. Delete free-text comment columns whose author nobody can name, and any line nobody will claim.

The most important point of this phase: the spreadsheet has to die on an announced date. As long as it lives in parallel, nobody enters anything seriously into the CMMS. If you are still weighing what a spreadsheet actually costs in consolidation time and errors, our article on the true cost of running maintenance on a spreadsheet sets out the arithmetic.

Phase 3 — The maintenance plan and its triggers

Three sources feed the plan and they do not agree. Maker's recommendations, written for the worst operating case and to protect the maker. Classification society requirements, which are binding once you operate under an approved planned maintenance system. Statutory tasks: periodic testing of safety equipment, pollution prevention checks, flag State inspections.

The trade-off is made asset by asset, and it is documented. Extending a maker's interval can be defended if the asset is monitored another way, through oil analysis or vibration readings. But the justification has to be written in the system, not held in the head of a chief engineer who signs off in eight weeks. And a task that comes from a class-approved planned maintenance system is not changed unilaterally.

Then comes the trigger, and this is where a serious plan separates from a cosmetic one. Calendar suits statutory inspections and seasonal checks. Running hours suit anything that wears while it turns: main and auxiliary engines, generators, compressors, pumps, separators. Condition suits assets that are actually monitored. Putting everything on calendar because it is quicker to configure produces a plan that raises pointless jobs when the ship has been alongside and lets wear run when she has been working back-to-back voyages. The build method is set out in our four-step guide to a preventive maintenance plan. One last thing: simulate twelve months of workload before you sign the plan off, or every annual interval will fall in the same month simply because it was entered on the same day.

Phase 4 — Job plans and attached documents

A job plan is written for someone who has never done the job, at three in the morning, in a seaway, and whose first language is neither English nor French. That is not a pessimistic assumption. On a fleet with crew rotation, it is the normal case.

What that means in practice: short sentences, one action per line, imperative mood, nothing implied. Every figure written with its unit — tightening torques, clearances, test pressures, tolerances — rather than a vague reference to the manual. Tools and consumables listed at the top, so nobody walks to the store three times. And the safety section before the first technical step: isolation, lock-out, enclosed space entry permit, hot work permit, personal protective equipment. The drafting standards are covered in our article on job plans and the quality of the work done.

Attach drawings, system diagrams, manual extracts and permit templates to the task itself, not to a shared folder somewhere ashore. Watch file size: a drawing of several tens of megabytes will not open on a phone connected to a port network, so cut it into usable extracts. Finally, prioritise. Writing every job plan in the fleet before going live is a project with no end. Start with the critical assets identified in phase 1 and fill in the rest as real jobs come round.

Phase 5 — Spares and purchasing

A spare part that is not linked to an asset is a dead line: nobody will find it when it is needed. Linking parts to assets is therefore the first job of this phase, and it is done with the chief engineer, manual in hand.

Then location, and here the maritime case is genuinely different. A part can be in the ship's store, in a shore warehouse, or at a supplier with a lead time. These are not three shades of the same status, they are three different operational situations. A vessel on passage, several days' steaming from a port, can only rely on what is physically on board. If the system blurs the two, you will air-freight a part that is already in the ship's store.

Reorder levels come next. A useful level is not a round number: it follows from the lead time actually observed with that supplier and from the vessel's port call rhythm. A part deliverable in three days into a port called weekly does not justify the same holding as a part with an eight-week lead time on a ship working a long campaign. The full reasoning is in our article on MRO inventory management and critical spare part stockouts. That leaves the purchasing route, usually neglected at configuration: who requests, who approves, above what value, and who receipts the goods.

Phase 6 — Users and permissions, ship and shore

The roles to configure are the ones that already exist: master, chief engineer, second engineer and watchkeeping officers, bosun, superintendent, designated person ashore, shipowner, storekeeper, and occasionally an external contractor. The visibility principle fits in one sentence: the ship sees her own vessel, shore sees the fleet. A master does not need the history of the ship berthed next door, and giving him that access creates noise without creating value. Conversely, the superintendent and the owner need the consolidated view, otherwise the CMMS is just another digital notebook.

Two points deserve an explicit decision. First, the right to modify the asset hierarchy: it must belong to very few names. If everyone can create an asset, the same compressor will appear under three descriptions within six months and the register built in phase 1 will decay without anyone noticing.

Second, named accounts. A shared "engine room" or "bridge" login destroys traceability: you can no longer say who carried out a job, which empties the documentation expected under the ISM Code of its meaning and makes audits uncomfortable. One account per person, opened before joining, closed on final sign-off. The link between maintenance traceability and compliance is developed in our article on the ISM Code and vessel maintenance compliance.

Phase 7 — Training on board, during a port call

Training happens on board, during a port call, on the ship's own machinery. Not in a classroom ashore, not on demonstration data. This is not about comfort: an officer who has closed his first job on his own auxiliary engine has understood what the system is for. The same officer trained on a fictitious vessel has attended a presentation.

The format that works: a short session, an hour to ninety minutes, small group, three actions only. Open today's job and its job plan. Close it, recording what was done, hours spent and parts used. Raise a defect or an observed anomaly. Everything else is learned afterwards; those three actions cover the bulk of daily use. The aide-memoire fits on one page, posted in the engine control room and on the bridge. A full manual belongs in the ship's documentation, but it is not what anyone reads standing in front of a stripped pump.

Watch your coverage: if the ship runs two crews, train both. An untrained crew joining after go-live drops usage to zero for the whole of their tour, and the missing data then has to be reconstructed.

Phase 8 — Go-live: pilot vessel, then the fleet

One pilot vessel first. The choice matters: not the oldest ship in the fleet, whose register will be a permanent special case, and not the most complex. Ideally the lead ship of a sister series, with a chief engineer who wants it to work. That vessel will absorb the method mistakes, and that is precisely its job.

The pilot is not measured in calendar weeks but in operating cycles. It is finished when at least one preventive task has been raised, opened, carried out and closed in the system with its hours and its parts, and when one unplanned defect has been handled end to end. Until that has happened you have tested a configuration, not a way of working. Only then does the rest of the fleet follow, in waves, reusing the template corrected by the pilot — and a wave is scheduled around port calls, never around an administrative date.

That leaves the most political moment: switching the spreadsheet off. It needs a single date, announced ship and shore, and that date is not renegotiated vessel by vessel. For as long as double entry exists, the crew will keep trusting the file they know, the CMMS data will stay incomplete, and everyone who resisted the change will be proved right.

Phase 9 — The first 90 days

After go-live you observe before you correct. Three indicators are enough, and they must be calculated the same way month after month, otherwise the comparison means nothing.

Preventive completion rate: of the tasks due in the period, how many were closed inside their window. That measures actual use, not stated goodwill. Backlog: the number of overdue tasks, but above all their age. Ten tasks a week overdue is normal; a critical-equipment task two months overdue is a safety issue, not a software issue. Recording quality: take five closed jobs at random. If you can understand what was done without ringing the author, you are fine. If you read "OK" or "done", the data exists but will be worth nothing in an audit. Definitions and calculation methods are set out in our article on maintenance KPIs in shipping: MTBF, MTTR and backlog.

The rhythm: a 30-day review to spot tasks that were never opened, a 60-day review to correct intervals that are visibly wrong, a 90-day review to lock in what becomes routine. Do not adjust after a fortnight: you would be correcting a start-up effect, not a configuration fault.

Phase 10 — The first crew change is the real test

Everything above can go perfectly well and prove nothing. The chief engineer who built the register knows the system because he built it. The day he signs off, the officer relieving him arrives without that context, with his own habits, and finds a system he did not choose. That is the moment of truth for a fleet rollout: if usage collapses at the first crew change, it will collapse at every one after it, and you will end up with a system fed by a single person — which is exactly the situation you were trying to leave when you gave up the chief's notebook.

Four things are prepared before the change, not during it. The joiner's account is created and tested before he embarks, so he can log in on his first watch. The handover happens in the system: work in progress, deferred tasks and the reasons for deferral are recorded by the leaver, not passed on verbally at the gangway. A short familiarisation is run in the first week by the shipboard focal point. And a check is made thirty days after the change, comparing the completion rate before and after.

A rollout that survives two consecutive crew changes without a drop is a successful rollout. Before that, you have a project in progress, not a system in service.

What you should be able to show a year later

Go back to the questions you wrote in phase 0: they are your acceptance test. A year after the pilot vessel went live, open the system in front of someone who was not involved in the project and check that you can answer without preparation. Job history on every critical asset, with date, author, hours spent and parts used. Evidence that approved-plan tasks were carried out inside their window, or that the deviation was reported. Certificates in force and their expiry dates. Critical spares actually held on board. All of it reachable in a few clicks, without opening a side file or asking the chief engineer what he remembers.

If that works, the implementation is finished. If it does not, you know which phase to go back to: the missing answer almost always points at a stage that was signed off too quickly. To scope your own rollout, or to have your asset structure reviewed before you freeze it, talk to our team.