How to Make the Final CMMS Decision

By the final decision, most of the work is already done. Requirements are written, shortlisted systems have been compared on the same problems, demos have been recorded as stated, shown, tested, supported or unresolved, and each proposal has been reconciled against what was evaluated. What remains is the judgment: which option to select, and why.

This guide covers that judgment and how to document it. It assumes the earlier records exist and carries them forward rather than repeating them.

The final CMMS decision comes before every uncertainty is gone. It is the point at which your organization decides which remaining differences, obligations and uncertainties it is prepared to accept, and records why.

The question the final decision answers

Each earlier step asked a narrower question. Comparison asked what differs between systems. Demo evaluation asked what was actually stated, shown, tested, supported or left unresolved. Proposal evaluation asked whether the solution established during evaluation is the solution being offered.

Waiting for zero uncertainty usually means never deciding. Some questions can only be answered during implementation or operation. The task is to know which uncertainties remain, judge whether each is material, and decide what to do about each one.

Carry the evidence forward

Start from the records you already have. For each material requirement, bring forward the vendor claim, the evidence obtained, what remains uncertain, the proposed scope, the commercial boundary and any gap found during proposal reconciliation.

Requirement → Vendor Claim → Evidence → Remaining Uncertainty → Proposed Scope → Commercial Boundary → Tradeoff → Decision → Rationale

This chain is decision traceability. Its purpose is to keep the history of material decision items intact as the process moves from requirements to selection. It does not require documenting every minor feature. A requirement that shaped the choice should still be traceable to the evidence behind it when someone asks later why this system was chosen.

Five decision states

The earlier evidence states describe what you know about a claim. Decision states describe what an item means for the selection. CMMS Buyer’s Guide uses five. They are this guide’s editorial method; they are not a government procurement framework or an external standard.

MUST MEET

A material requirement or condition your organization has determined cannot reasonably be traded away. Most desired features do not belong here.

DIFFERENTIATOR

More than one option may be acceptable, but one has a meaningful advantage under your actual operating conditions.

TRADEOFF

An option provides something valuable while introducing additional cost, responsibility, dependency, complexity, limitation or another material consequence.

UNRESOLVED

Evidence remains insufficient for a material question. This does not mean automatic rejection: you may obtain more evidence, mitigate the uncertainty, address it in written terms where appropriate, or knowingly accept it.

DEAL BREAKER

A requirement, boundary, risk, obligation or commercial condition your organization has determined it is unwilling or unable to accept.

These states identify decision significance. They are not vendor scores, and they are not stages an item must pass through in order. An item can start UNRESOLVED and later become a TRADEOFF, a DIFFERENTIATOR or a DEAL BREAKER once more evidence arrives. Two items with the same state can matter very differently to your operation.

Separate must-meets from differentiators

A must-meet is a condition without which the system cannot serve your operation. If technicians routinely work in areas without connectivity, offline work completion may be a must-meet. If connectivity is reliable everywhere, the same capability may be a differentiator or may not matter.

Keep the must-meet list short and specific. When a long feature list is labeled must-meet, every option fails something, and the label stops helping the decision. When a real must-meet is folded into general preferences, a system can look competitive while missing the one condition that matters most.

Differentiators are where acceptable options actually separate. Write each one as an advantage under your conditions: which work, which users, which sites, and what the advantage changes in practice.

Identify real tradeoffs

A tradeoff exists when choosing one benefit brings a consequence you would otherwise avoid. Write both sides explicitly.

• A stronger planning module that requires a higher subscription tier.
• A lower one-time price with more data preparation assigned to your staff.
• A tested offline workflow that depends on records being downloaded before work begins.
• A standard integration that covers some, but not all, of the data your finance system needs.
• A shorter implementation schedule with less configuration support included.

Cost belongs in the same analysis. Compare one-time and recurring costs against what each option includes, what your team must provide, and how quantities, tiers and renewal terms may change the cost later. A lower price is meaningful only against the scope and responsibilities behind it. The licensing model and the implementation plan often decide which option actually costs less to operate.

Public procurement offers one useful illustration. In U.S. federal source selections that use a tradeoff process, the government may accept other than the lowest-priced proposal, but the perceived benefits of the higher-priced proposal must merit the additional cost, and the rationale for tradeoffs must be documented [1]. The federal rule for the source selection decision requires documentation of the rationale for business judgments and tradeoffs, including benefits associated with additional costs, and states that this documentation need not quantify the tradeoffs [2].

These are rules for federal agencies. Private CMMS buyers are not bound by them. The practice illustrates a principle this guide applies: a price difference is justified by the benefits and consequences behind it, and that reasoning can be recorded in plain language.

What to do with unresolved items

An UNRESOLVED item needs a treatment before or at the decision. Choose the treatment that fits the question:

Obtain more evidence

The question can be tested or documented before selection, such as a sandbox test or sample migration.

Clarify the proposal

The uncertainty is about what is included, assumed or excluded.

Revise scope

A needed service, module or quantity is missing from the offer.

Mitigate operationally

Your team can reduce the risk through process, training or phased rollout.

Address it in written terms

Responsibility or a commitment should be stated in writing; material contract questions may need legal or procurement review.

Knowingly accept it

The item is real but its possible consequence is tolerable, and the decision owner accepts it on record.

Treat it as unacceptable

The possible consequence is severe enough that the item becomes a deal breaker.

Accepting an uncertainty knowingly is a legitimate decision. Leaving it unrecorded is the problem: later, nobody can tell whether it was accepted or missed. Items touching data migration and integrations often fall into this category because their full behavior appears only with production data. This guide does not provide legal advice.

When scoring helps, and where it can mislead

A score can summarize a judgment. It should not replace the evidence and tradeoffs that produced the judgment.

Scoring has real uses. It can make evaluators apply the same factors consistently, it can make priorities explicit, and some organizations and procurements require a formal weighted evaluation. If yours does, use it.

The limits appear when the score is treated as the decision. Federal rules permit evaluations using color or adjectival ratings, numerical weights and ordinal rankings, and require the relative strengths, deficiencies, significant weaknesses and risks supporting the evaluation to be documented [3]. GAO protest decisions have repeatedly described ratings, whether numerical, adjectival or color, as merely guides for intelligent decision-making, and have said that relative merit is properly based on a qualitative assessment of proposals rather than a simple count of strengths and weaknesses [4][5].

Applied to CMMS selection, that suggests several cautions:

• Numerical precision can conceal qualitative differences. An 84 and an 82 may reflect very different strengths.
• Two options with similar scores can differ in dependencies, remaining uncertainty and commercial boundaries.
• Weights express your organization’s priorities. They are choices, and they should be discussed as choices.
• A must-meet condition should not disappear inside an average. A high total cannot compensate for a failed must-meet.
• Keep the underlying evidence and rationale alongside any scorecard, so the score can be explained.

The CMMS Decision Record

The CMMS Decision Record preserves the reasoning behind the selection for each material decision item. It is not a vendor scorecard: it has no points, totals or rankings. Each row records what was required, what was established, what the proposal includes, what remains uncertain, and what the organization decided and why.

Decision item

The material question or capability being decided.

Requirement

The requirement it traces to, in your operation’s terms.

Evidence obtained

What was stated, shown, tested or supported, and under what conditions.

Proposal reconciliation

What the proposal includes, excludes or assumes for this item.

Remaining uncertainty

What is still unknown and why it matters.

Decision state

MUST MEET, DIFFERENTIATOR, TRADEOFF, UNRESOLVED or DEAL BREAKER.

Tradeoff

What is gained and what consequence comes with it.

Mitigation / follow-up

The action, evidence or written term that addresses the item.

Decision owner

The person or group accountable for this judgment.

Decision

Accepted, rejected, accepted with mitigation, or pending.

Rationale

Why the decision was acceptable to your organization.

Use one row per material decision item. Most selections have a manageable number of these; minor features stay in the comparison record.

Worked example: offline technician workflow

This example continues the offline technician scenario used in the comparison, demo and proposal guides. It is illustrative. It does not describe any real vendor’s capability, pricing or contract terms.

Decision item

Offline technician workflow

Requirement

Technicians must complete work without connectivity

Evidence obtained

Representative offline workflow tested; synchronization observed under tested conditions

Proposal reconciliation

Mobile capability included for required users under the illustrative proposed scope

Remaining uncertainty

Conflict handling was not demonstrated

Decision state

UNRESOLVED

Tradeoff

Delay selection for further testing versus accepting uncertainty with mitigation

Mitigation / follow-up

Controlled sandbox conflict test before contract execution

Decision owner

Maintenance + IT

Decision

Pending additional evidence

Rationale

Conflict behavior could materially affect record integrity, so additional evidence is required before accepting the remaining uncertainty

Suppose the sandbox test is then run. The record should keep the original entry and add what changed. For example: the test showed that conflicting edits were flagged for supervisor review and neither version was lost; the decision state moved from UNRESOLVED to TRADEOFF because resolving flagged conflicts adds a supervisor task; the decision became accepted with mitigation, with a documented review procedure; and the rationale explains why that added task was acceptable.

If the test had shown lost records, the same item could have become a DEAL BREAKER. Either way, the record shows what was known at each point and why the decision followed. For more on offline behavior itself, see the mobile CMMS guide.

Record the rationale

Don’t just record which CMMS you chose. Record why the tradeoffs were acceptable.

A useful rationale names the must-meets each option satisfied or failed, the differentiators that separated acceptable options, the tradeoffs accepted, the uncertainties accepted or still being addressed, and the costs and obligations your organization took on. Plain sentences are enough. The test is whether someone who was not in the room could understand why this choice made sense given what was known.

After the decision

The Decision Record stays useful after selection. It can help future stakeholders understand what was known, what remained uncertain, which obligations were accepted and why the organization chose the system. During implementation, it shows which follow-up items and buyer responsibilities were agreed. At renewal, it gives a baseline for asking whether the original reasons still hold.

A record cannot prevent implementation problems or disputes. It does make it easier to see whether a later problem was a known, accepted risk or something nobody anticipated.

Before you sign

Bring the Decision Record together with the reconciled proposal, open follow-up items and any written clarifications. Confirm that every item marked accepted with mitigation has an owner, and that nothing still marked UNRESOLVED is being treated as settled.

Previous: How to Evaluate a CMMS Proposal →

If you are earlier in the process, your CMMS Requirements Tool can help you define which requirements are likely to become must-meets for your operation.