Vendor A quotes $80,000.
Vendor B quotes $105,000.
Which costs less?
You do not know yet.
Vendor A may exclude migration, two required integrations and onsite training.
Vendor B may include them.
One price may cover Year 1 while another includes a three-year subscription.
One may assume 25 users and another unlimited users.
One may hold renewal pricing while another leaves it undefined.
The arithmetic is easy.
The boundary is the hard part.
The Common Price Boundary
CMMSBuyersGuide uses a Common Price Boundary before comparing competing proposals.
A Common Price Boundary means both proposals have been normalized across five dimensions:
Scope | Quantity | Time | Growth | Uncertainty
Only then do the totals describe approximately the same purchase.
Public buyers often create standardized cost schedules for exactly this reason.
AlexRenew's CMMS procurement separated common cost categories and requested multi-year totals.
The lesson is not that every private buyer needs a government RFP.
It is that vendors should be asked to price the same commercial problem.
1. Normalize scope
List every required component.
Examples:
- core software
- required modules
- implementation
- configuration
- migration
- integrations
- testing
- training
- go-live/stabilization
- support
- hosting
- environments
- third-party components
Then mark each proposal:
Included | Excluded | Assumed | Optional | Future | Unclear
Do not add optional capabilities merely to make proposals identical.
Normalize the scope you have decided the operation requires.
Scope Delta Register
Create a separate register for differences.
Example:
Required ERP integration
Proposal A: excluded
Proposal B: included
Do not immediately invent a dollar value for A.
First identify the delta.
If the vendor can price it, obtain the price.
If not, classify it as unresolved commercial uncertainty.
That is more rigorous than inserting an unsupported estimate.
2. Normalize quantity
Make the proposals price the same operating population.
Depending on licensing model, normalize:
- full users
- requesters
- concurrent users
- sites
- assets
- modules
- environments
- storage
- integrations
- migration volume
- training sessions
- support hours
If Vendor A prices 25 users and Vendor B prices 50, the totals do not yet answer the same question.
The same is true if one quote covers one facility and another covers five.
3. Normalize time
Separate:
Initial cash requirement
from
Comparable contract-period cost.
A Year-1 total can contain large implementation charges.
Years 2–5 may contain mostly recurring subscription/support.
For each proposal, build the same time horizon.
Component | Year 1 | Year 2 | Year 3 | Year 4 | Year 5
Do not assume five years is always the correct horizon.
Use the decision horizon relevant to the contract and organization.
But never compare one-year and multi-year totals as if they were equivalent.
4. Normalize growth
Today's configuration may not be tomorrow's operating model.
Apply the same plausible growth case to each vendor.
Example:
Current:
40 full users
1,500 assets
2 sites
Growth case:
55 full users
2,000 assets
3 sites
Then ask each vendor to price the same state.
This is where different licensing models reveal themselves.
A per-user model may react to 15 added users.
A facility model may react to the third site.
An asset model may react to 500 added assets.
A tiered plan may cross a threshold.
The goal is not to predict the future perfectly.
It is to test how the commercial model behaves under the same future.
5. Normalize uncertainty
Not every cost can be known before selection.
Do not hide that.
Create an Uncertainty Register.
For each unresolved item record:
- item
- why it is uncertain
- which proposal it affects
- likely decision point
- who owns resolution
- whether it could materially change comparison
Examples:
- migration scope not validated
- integration complexity unknown
- travel not estimated
- historical data volume unresolved
- premium support undecided
- renewal formula not supplied
A proposal with a lower known total but several major unknowns is not automatically cheaper.
It is simply less commercially resolved.
The Normalization Bridge
For each proposal:
Quoted total
+ required excluded items with verified prices
+ required deferred items with verified prices
+ quantity normalization
+ time normalization
+ known contractual escalation
= Comparable Boundary Cost
Then place unresolved items beside the number, not invisibly inside it.
Example:
Vendor A
Comparable known boundary: $310,000
Unresolved: ERP integration; archive migration
Vendor B
Comparable known boundary: $327,000
Unresolved: none material
This does not tell you which product to choose.
It tells you what you actually know about the price comparison.
That is the purpose.
Do not manufacture precision
A five-year spreadsheet can look rigorous while resting on invented assumptions.
Avoid:
- guessing future professional-services hours
- assigning arbitrary inflation where the contract is silent
- treating optional modules as inevitable
- using a generic “implementation percentage”
- inventing migration costs
- assuming all users/assets/sites grow at the same rate
If a material number is unknown, keep it unknown and resolve it.
Commercial uncertainty is data.
Separate three numbers
For each proposal, maintain:
1. Year-1 cash requirement
What must be funded to implement and operate through the initial period?
2. Comparable horizon cost
What is contractually known or supportably calculated over the chosen comparison period?
3. Growth-case cost
What happens if the same defined operating change occurs?
These answer different questions.
Collapsing them into one “TCO” can hide useful information.
Compare pricing formulas, not only prices
That is a powerful buying practice.
If the formula is known, the buyer can model change.
For each variable component, capture:
Price = unit × quantity
or
Price = tier
or
Price = facility × rate
or
Price = fixed platform + active users
or
Price = negotiated enterprise boundary
The formula is often more durable than today's total.
Compare assumptions
Two vendors can price the same line item under different assumptions.
Example:
“Data migration — included.”
Vendor A assumes:
one asset file, cleansed and deduplicated by customer.
Vendor B assumes:
assets + open work + PMs + parts + selected history, with vendor mapping assistance.
The line-item names match.
The scope does not.
Normalization therefore requires both price and assumption.
The Price Boundary worksheet
Use one row per commercial component.
Columns:
Component
Required scope
Required quantity
Vendor A state
Vendor A cost
Vendor A assumption
Vendor B state
Vendor B cost
Vendor B assumption
Normalized delta
Uncertainty
Evidence
Then add separate sections for:
- Year 1
- recurring years
- growth scenario
- renewal assumptions
This structure should later power the CMMSBuyersGuide Quote Comparison Worksheet.
DO NOT BUILD THAT TOOL IN THIS TASK.
A final test before calling one proposal cheaper
Ask:
- Same required scope?
- Same quantities?
- Same time horizon?
- Same growth case?
- Same treatment of required options?
- Same treatment of implementation and migration?
- Same integration boundary?
- Same support/hosting boundary?
- Renewal assumptions visible?
- Material unknowns listed?
If not, keep normalizing.
The buying principle
Proposal comparison is not the act of putting two totals next to each other.
It is the act of making those totals describe the same commercial reality.
Two totals are comparable only when they buy the same boundary for the same period.
How to decide what CMMS is best for your operation
Sources
- Alexandria Renew Enterprises — RFP No. 22-001, Provision, Implementation and Maintenance of CMMS
Requires offerors to break down project cost by deliverable using the cost proposal form, to describe all assumptions made in calculating costs, and to provide yearly totals and a five-year total.