How do you compare proposals that price different things?

The highest price may include unnecessary work, or be the only estimate covering migration, security, testing and maintenance. First establish whether the proposals target the same outcome.

Start with a common comparison matrix

Break each proposal into the same categories. Differences then become visible instead of hiding behind marketing language and different document structures.

• Analysis and design.
• In-scope features and processes.
• Integrations and data exchange.
• Data migration and preparation.
• UX, interface and supported devices.
• Functional, security and performance testing.
• Deployment, training and hypercare.
• Documentation and handover.
• Licences, infrastructure and recurring fees.
• Maintenance, SLA and further development.
• Assumptions, exclusions and client obligations.

Compare scope, not the number of rows

One vendor may split a feature into ten items while another describes a whole module in a sentence. Item counts do not measure completeness.

Focus on business process coverage. Can users complete the full workflow, or does the proposal cover isolated screens without exceptions, permissions, notifications and reporting?

Identify assumptions

Assumptions can matter more than the estimate. A vendor may assume clean, ready-to-use data, current integration documentation and users available for testing.

If an assumption fails, costs follow. Ask each vendor for an explicit list of assumptions, exclusions and client dependencies.

Compare pricing models

Fixed price allocates risk differently from time and materials, but is not automatically safer. Unclear scope may produce a large contingency or a minimal interpretation of ambiguous requirements.

Hourly billing offers more flexibility but demands stronger control of priorities, pace and outcomes. Compare budget management and change control as well as rates.

Calculate the total cost

• Implementation and preparatory work.
• Licences and external service fees.
• Infrastructure and environment maintenance.
• Changes, fixes and further development.
• Support, SLA and team availability.
• User training and migration.
• Exit costs: data export, documentation handover and vendor replacement.

Assess the team, not just the brand

A portfolio does not deliver the project — specific people do. Ask who is assigned, their relevant experience, availability and replacement arrangements.

Run a workshop with finalists. Notice whether they ask about the problem, identify risks, challenge weak assumptions and explain decisions clearly.

Example criteria and weights

Weights should reflect your project. For example: problem understanding 20%, team capability and availability 20%, delivery and quality 15%, total cost 15%, security 10%, contract and exit terms 10%, maintenance 10%.

The goal is not mathematics that merely looks objective. A matrix makes decision-makers state what matters before seeing final prices. To put real proposals on a common footing, consider an IT proposal and estimate review.