How to Run a CMMS Pilot: A 90-Day Plan and Success Criteria That Hold Up

How to Run a CMMS Pilot: A 90-Day Plan and Success Criteria That Hold Up

A 14-day free trial tells you whether the software works. It doesn't tell you whether your operation will work on it. Those are different questions, and for anything bigger than one site and a dozen users, the second one is the expensive one to get wrong.

A pilot answers the second question. One site, a small group, real work, a fixed period, and a scorecard agreed before anyone logs in. Done properly it produces a decision that survives the finance meeting. Done badly it produces three months of "it seems fine" and a rollout that stalls at site two.

This is the plan I use for pilots, whether the customer runs it themselves or runs it with us. It's vendor-neutral. The criteria work for any CMMS worth piloting.

Want it as a working document? The Excel version has the 90-day plan week by week, 16 success criteria with baseline and day-30/60/90 columns, a pilot group roster, and the day-90 decision sheet:

Trial or pilot?

Use a trial when one team can be live by this afternoon: a single site, under about 15 people who plan work, data that fits in a spreadsheet. Import it, use it, decide. Two weeks is plenty.

Use a pilot when the switch is a project. Several sites. Fifty or more paid seats. A current CMMS or ERP module with years of history. A regulated environment where the audit trail is not optional. In those operations, the risks a trial never surfaces are the ones that kill rollouts: the data import that goes sideways, the field team that never opens the app, the compliance report nobody checked.

A pilot puts those risks on the table early, on one site, before the whole operation depends on the answer.

Step 1: Pick the site (not the easiest one)

The instinct is to pilot on the site with the keenest manager and the cleanest data. Resist it. That site will succeed with any system, and the result tells you nothing about the other nine.

Pick a representative site. Typical data quality, typical technicians, typical signal coverage. If half your estate is basements with no reception, the pilot site needs a basement. If your compliance load is LOLER and PUWER, the site needs cranes and machinery, not just an office.

One site only. Two sites in a pilot doubles the setup and halves the attention.

Step 2: Pick the group (5 to 10 paid seats, every operator)

The pilot group is the people who plan and assign work on that site: the maintenance manager, the planner, the supervisors, maybe a compliance lead. Five to ten is the range. Fewer than five and one person's opinion is the result. More than ten and you can't support them properly.

Then add everyone else on the site as operators or requesters. Most CMMS platforms either don't charge for these roles or shouldn't. Operators log defects and do daily checks. Requesters raise jobs. If they aren't in the pilot, you're testing the office and not the field, and the field is where CMMS rollouts die.

Include at least one sceptic. The technician who thinks it's all pointless will find the naming that makes no sense on a phone screen faster than any enthusiast. Their verdict at day 90 is worth more than everyone else's.

Step 3: Agree the success criteria before anything is set up

Skip this step and you're running a long trial, not a pilot.

Pick four to six measures, baseline them, and write down the day-90 target. The download lists sixteen across six areas. The ones I'd start with:

Baselines are the hard part. The old system may not give you them. A two-week manual count before the pilot starts is enough: how many jobs happened, how many were logged anywhere, how long PMs were overdue.

Two people-questions belong on the scorecard as well, asked at day 30, 60 and 90. To each technician: would you keep using this? To the site manager: do you trust the dashboard over the spreadsheet? Write the answers down verbatim.

Step 4: The 90 days

Week 0, scope. Site chosen, group named, criteria agreed and baselined. Nothing is set up until this is done.

Week 1, build. Import the site's assets, locations, PM schedules and open work orders. Only that site. Set up users. Put QR labels on the critical assets so the fastest way to log a job is the machine itself. If the import is the scary part, the migration guide covers mapping and cleaning for one site.

Week 2, go live on real work. Every work order on the site goes into the system from Monday, and the old spreadsheet is frozen for this site. Parallel running feels safe and guarantees failure, because the team never switches.

Week 3, first fixes. Hold a 30-minute review and ask one question: what blocked you? Not "do you like it". You'll hear about categories that don't match how the team thinks and assignments landing with the wrong person. Fix all of it this week.

Week 4, day-30 review. Fill in the scorecard. Don't judge against the target yet. Look for direction: is PM completion moving, are mobile closes climbing.

Weeks 5 to 6, settle. Tune the PM schedules the first cycle exposed. Get the dashboard into the weekly site meeting so it's used, not admired.

Week 7, stretch. Add one thing the site asked for: parts, meter readings, a request portal for the operators. Stop at one. Scope creep is how pilots turn into rollouts nobody approved.

Week 8, day-60 review. Scorecard again, plus the two people-questions to everyone, including the sceptic.

Weeks 9 to 11, prove it. Run the audit-style report and time it. Pull MTTR and PM completion against baseline. Draft the rollout plan: which sites in which wave, how many seats, which old systems get migrated in what order.

Weeks 12 to 13, decide. Scorecard day 90. Written pilot report: what worked, what didn't, what a full rollout costs and looks like. Go, extend, or stop.

Step 5: The day-90 decision

The scorecard is the decision. That's the point of agreeing it in week 0: nobody gets to move the goalposts at the end, in either direction.

Criteria met, technicians would keep it, manager trusts the dashboard: roll out. The pilot report becomes the rollout plan, and the pilot site becomes the reference the next sites visit.

Criteria mostly met with specific gaps: extend by a month with the gaps as the only focus. Vague gaps mean the criteria were vague.

Criteria missed: stop, and be glad you found out on one site. Write down why, because the reasons (data quality, field adoption, a workflow the software can't do) are what the next evaluation has to test first.

What goes wrong

The pilot never goes live on real work. It becomes a sandbox with demo data and three weeks of "we'll switch properly next month". If real work orders aren't in the system by week 2, restart the clock.

No baseline. Day 90 arrives with a PM completion rate of 88% and nobody knows if that's up or down. Count before you start.

Only the enthusiasts get asked. The verdict comes from the manager who chose the software. Ask the sceptic, on the record.

Free pilots. A pilot nobody paid for is a pilot nobody owns. If it's a vendor-run pilot, expect to pay something for it; if it's a good vendor, expect that payment to count toward the contract rather than disappear. Either way, someone on your side should have a number attached to the outcome.

If you're still choosing between systems, the CMMS selection guide covers evaluation. If you've picked one, the implementation checklist is the six-week plan that follows a successful pilot.

Shane Price

AssetOS

Writing about maintenance management, CMMS implementation, and the real challenges operations teams face.