Choosing a CMMS means matching software to the specific maintenance problems you need to solve, then judging each candidate on whether technicians will actually use it. Requirements come first, features second, and the deciding test is almost always adoption: the best-fit system your floor will use beats the most powerful one it will not.
The trap in CMMS selection is the feature checklist. Every product lists dozens of capabilities, most vendors can tick most boxes, and a checklist tells you nothing about the two things that matter, whether the system fits how your plant actually works, and whether a technician can close a work order on a phone without cursing. This guide covers how to write requirements before you look at software, which features are genuinely must-have, how to run a demo that reveals the truth, and the evaluation process that keeps you from buying the wrong thing well.
Why start with requirements, not features?
Because features are the vendor's story and requirements are yours. If you walk into demos without written requirements, you get sold, steered toward whatever each product does best, dazzled by modules you will never switch on, and left comparing apples to oranges. Requirements flip the room: you define what you need, and every candidate has to show how it meets your list, on your terms.
Good requirements come from the problems you named before you started shopping. Lost work orders, missed PMs, an audit that demanded maintenance records, a storeroom nobody trusts, each one becomes a concrete requirement the software must satisfy. Write them down, rank them, and separate the must-haves from the nice-to-haves before a single sales call. A plant that knows its own requirements buys in weeks; a plant that does not spends months being impressed by demos and still picks wrong.
How do you turn maintenance pain into requirements?
Every real requirement traces back to something that hurts today. The exercise is to write down each pain, then translate it into a testable statement the software must satisfy. Do it with the people who feel the pain, the planner, a couple of technicians, the storeroom lead, not in an office alone.
- "Work requests get lost" becomes: operators can submit a request that lands in a queue, and nothing gets worked without a work order.
- "We failed the audit on PM records" becomes: the system produces a defensible record of which PMs were due, done, when, and by whom.
- "Nobody can find parts at 2 a.m." becomes: parts are linked to the assets they fit, with bin locations and min/max, searchable on a phone.
- "History lives in one planner's head" becomes: every closed work order is searchable by asset, with hours and failure notes.
Rank the resulting list. A requirement that solves a daily, painful, audit-relevant problem outranks a capability that would be neat to have someday. That ranking becomes the weighting on your scorecard later, so the effort you spend here is not paperwork, it is the scoring system that will decide the purchase. A plant that can hand a vendor a ranked, testable requirements list has already done the hardest thinking in the whole selection.
What features are genuinely must-have in a CMMS?
Every CMMS does the core jobs; the question is depth and usability, not presence. Sort the feature list into must-have (the system is pointless without it), should-have (real value, weigh it), and nice-to-have (do not pay a premium or trade adoption for it).
| Tier | Feature | Why it lands there |
|---|---|---|
| Must-have | Mobile work-order close-out | If technicians can't close work at the machine, history becomes fiction and everything downstream fails |
| Must-have | Asset hierarchy + history | The spine every work order, PM, and part attaches to |
| Must-have | PM scheduling (calendar + meter) | The whole reason a CMMS beats a spreadsheet |
| Must-have | Spare parts / MRO with asset linkage | Turns a 2 a.m. breakdown from a parts hunt into a pick |
| Should-have | Configurable reports and dashboards | Reporting you can shape to each audience without a consultant |
| Should-have | Request portal for operators | Captures the floor's requests without a radio call |
| Nice-to-have | Sensor / condition-monitoring integration | Valuable later, but do not let it drive the core decision |
| Nice-to-have | Purchasing / heavy financials | Often EAM territory; may be over-scope for a single plant |
Be honest about the tiers, because vendors will try to move nice-to-haves up. A slick predictive-analytics module or an AI assistant makes a great demo, but if your technicians still cannot close a work order quickly on a phone, that module has nothing real to run on. Features that depend on clean, complete data are worthless until the capture that produces that data works. Rank accordingly.
The pattern: the must-haves are all about capturing and using maintenance work, and mobile close-out sits at the top because it is the one feature that decides whether the whole system gets real data. The nice-to-haves are where vendors compete on demo dazzle and where plants overpay. If a heavy financial or asset-lifecycle wish list is climbing your must-have tier, you may be looking at an EAM rather than a CMMS a different, bigger decision.
What evaluation criteria matter beyond features?
Two systems can match your feature list and still be very different buys. Weigh these:
- Usability for technicians. Time how long it takes a real technician to close a work order on a phone in the demo. This single number predicts adoption better than any feature list.
- Implementation and data support. Does the vendor help with the migration and configuration, or hand you a login and wish you luck? Data prep is where projects fail; support here is worth paying for.
- Total cost of ownership. Look past the license: implementation, data migration, training, integrations, and per-user fees over three years. The cheap license with expensive everything-else is common.
- Scalability and fit. Right-sized for your plant today, with room for more sites or assets if you grow, without forcing you into an enterprise platform you do not need.
- Support and community. Responsive support and an active user base mean faster answers when something breaks at go-live.
How do you run a demo that reveals the truth?
Control the demo or it controls you. A vendor-led walkthrough shows the software at its best on the vendor's data doing the vendor's favorite tasks. You learn nothing about fit. Instead, hand the vendor a script built from your requirements and your data, and make them drive it.
- Send your scenarios in advance. Give each vendor three or four real workflows from your plant, a breakdown call to closed work order, a meter-based PM triggering, a part issued against a job. Make every demo run the same scripts so you compare like for like.
- Load a slice of your real data. Ask to see your own assets and parts in the system, not the demo factory. How the software handles your messy hierarchy tells you more than any polished sample.
- Put a technician on the phone. Have an actual technician close a work order on a mobile device during the demo, and time it. Their reaction is your adoption forecast.
- Ask how it fails. Push the edge cases: offline at the machine, a part with no barcode, a PM that needs rescheduling. Confident answers to hard questions separate real fit from sales polish.
- Score immediately, against the weights. Fill the scorecard right after each demo while it is fresh, using the weights you set from your requirements. Decide on the numbers, not on which salesperson you liked.
What is the real cost of choosing wrong?
The license is the small number. The real cost of the wrong CMMS is a failed implementation, a floor that quietly returns to spreadsheets, and a year lost before anyone admits it. Because every product tends to demo well, the plants that choose badly are usually the ones that chose on features and charisma instead of requirements and adoption.
Adoption is not a soft factor, it is where the value is. Classic wrench-time studies dating to the DuPont work find maintenance technicians spend only about 25% to 35% of their shift on hands-on work, with much of the rest lost to travel, waiting, and hunting for parts and information (Reliabilityweb, on measuring wrench time). A CMMS that a technician can drive on a phone at the machine attacks that lost time directly; one they route around adds to it. And the reason to bother at all is documented: the U.S. Department of Energy's FEMP O&M Best Practices Guide, kept with Pacific Northwest National Laboratory, estimates functional preventive maintenance saves 12% to 18% over reactive operation (PNNL, O&M Best Practices: Maintenance Approaches), savings a well-chosen, well-adopted CMMS makes reachable.
Choose on your ranked requirements, prove fit with your data and a real technician, and weigh adoption above raw power. Then line the winner up for a disciplined implementation with the storeroom and spare parts data ready and the KPIs you will judge success by chosen in advance. The whole point is better equipment reliability so pick the system that will actually get used toward it. Start from the CMMS overview if you are still deciding whether you need one, and see the CLS case study for what capturing real floor data looks like once the choice is made. Get selection right and implementation gets easier; get it wrong and no amount of project discipline saves it.