The 90-day CMMS implementation guide

Why implementations fail before kickoff

Industry lore holds that a large share of CMMS implementations underdeliver, and the causes are boringly consistent: the asset registry was loaded dirty, the configuration tried to model every exception on day one, and the technicians — the people whose data entry feeds everything — met the system for the first time at training. None of these are software failures. All of them are decided before kickoff, which is why the fix is a plan, not a product.

The 90-day frame works because it forces scope discipline. Ninety days is enough to stand up assets, PMs, work orders, mobile, and inventory basics at one to three sites. It is not enough to build custom workflows for every edge case, integrate every system, and roll out twelve modules — and that is the point. Everything beyond the core earns its place after the core is live and trusted.

One staffing decision predicts success better than any other: a named internal owner with real time allocated — typically a planner or maintenance engineer at 50 percent or more — plus an executive sponsor who will defend the scope. Implementations run as a side project by a full-time maintenance manager fail on calendar math alone.

Days 1–30: the foundation is the asset registry

Month one has one deliverable: a clean, physically verified asset registry with a sensible hierarchy. Resist loading whatever spreadsheet exists. Walk the site. Verify that each critical asset exists, capture nameplate data and photos, apply QR or barcode labels, and place each asset in a location hierarchy that matches how people actually describe the plant — site, building or area, system, asset, at most one level deeper. Deep hierarchies impress consultants and confuse technicians.

Ruthlessly triage what gets a record. Critical and maintainable equipment: yes. Every valve, socket, and light fitting: no, or not yet. A useful screen is 'will anyone ever raise a work order against this specifically?' A registry of 800 real assets beats a registry of 8,000 where the signal drowns. You can always add granularity later; deduplicating a bloated registry later is misery.

In parallel, set the categorical vocabulary: work order types and priorities (four of each, maximum), failure codes (a short, plain-language list), and trades. These lists look trivial and govern every future report. Draft them with the supervisors who will use them, and keep every list short enough to memorize.

Days 31–60: workflows, PMs, and the mobile pilot

Month two builds the work engine. Configure the request-to-completion flow: who can request work, who approves, how it gets assigned, what a technician must record to close. Default to the simplest flow the site can live with — request, approve, assign, do, close — and add approval layers only where money or safety demands them. Every additional status is a place for work to get stuck.

Load the PM program, but through a review, not a copy. For each PM from the old system or OEM manuals, confirm the asset still exists, the frequency has a rationale, and the task list is executable as a mobile checklist. This pass typically kills or amends a meaningful fraction of inherited PMs and converts vague tasks ('check pump') into checkable steps ('record discharge pressure; inspect seal for leakage; photo required'). Meter-based PMs come next month; calendar-based first.

Start the mobile pilot in week six with a friendly crew of three to five technicians doing real work orders on real assets. Their friction list is your configuration backlog: fields nobody can fill get cut, checklists that read wrong get rewritten, and the sync behavior in the plant's dead zones gets tested by reality. A pilot crew that helped shape the system becomes your advocate corps at rollout. Skipping this step is the single most common cause of month-four adoption collapse.

Days 61–90: rollout, inventory basics, and the first integration

Month three goes live for everyone. Train by role and keep it short: technicians need ninety minutes on the mobile app, requesters need ten minutes on raising a ticket, supervisors need a half day on assignment and review. Train on your data — your assets, your PMs — never on demo content. From the go-live date, enforce one non-negotiable rule with management backing: if it is not in the system, it did not happen. Paper and WhatsApp channels for work requests get retired visibly.

Stand up inventory for the critical spares only: the parts whose stockout stops production or safety-critical work. Set min-max levels from history where it exists and from supervisor judgment where it does not; both will be wrong and corrected by consumption data within two quarters. Whole-storeroom cataloging is a quarter-two project — do not let it hold go-live hostage.

Wire exactly one integration in the first 90 days, chosen for pain relief per unit of effort. For most sites that is either single sign-on (adoption friction) or the ERP purchase-requisition link (planner time). Telemetry, historian, and multi-system orchestration come after the core is stable. Integration appetite is the classic scope-killer; one is a decision, five is a delay.

The adoption mechanics nobody writes down

Adoption is won in the first three weeks after go-live, in small mechanical ways. Supervisors must assign all work through the system, because technicians follow the channel their boss uses. Every request raised must visibly move — nothing kills requester trust like a ticket that vanishes into silence. And the first useful output must be shared fast: a two-chart summary in week three showing work completed and top problem assets tells everyone the data they enter comes back as something useful.

Expect and plan for the dip. Weeks one and two run slower than paper did, and someone influential will say so loudly. The counter is responsiveness: a daily fifteen-minute triage of user friction reports during weeks one to three, with visible same-week fixes. Systems earn trust at the speed their administrators fix small annoyances.

Day 90 and beyond: what good looks like

At day 90, measure five things against the pre-launch baseline: percentage of work flowing through the system (target: effectively all), PM compliance on critical assets (target: above 90 percent), mean work order cycle time, data completeness on closed work (failure codes and labor hours recorded), and requester usage outside the maintenance team. Publish the numbers whether they flatter or not; the habit of honest measurement is itself a deliverable.

Then, and only then, open the quarter-two backlog: meter-based and condition-based PMs, sensor-driven monitoring on the worst actors, the full storeroom, deeper ERP integration, analytics for reliability engineering. Every one of these lands better on a foundation of trusted core data. The 90-day implementation does not finish the journey — it makes the journey fundable, because from day 91 onward, every proposal comes with data behind it.