Request comparable quotes for a software project
A worked portal example shows how to specify outcomes, scope boundaries, your contributions and unresolved assumptions before requesting quotes.
Comparable software quotes start with a shared task. If one provider prices only the interface while another includes the ERP connection, the totals say little about the price of the same service.
Give all providers the same description of the starting situation. The working example below shows what can be made explicit. It is a hypothetical project scope, rather than an estimate for a real customer project.
Describe the intended outcome
A retailer wants a customer portal: authorised business customers see their prices, select goods and send orders to the existing ERP. The portal shows whether the order was actually created there. Payment processing, new marketplaces and importing old invoices are excluded from this initial scope. These boundaries apply only to the example.
Fill in a shared scope
The following table can form a working basis for the request. The retailer's contributions are planning items, not work already completed.
Identifier | Requested outcome | Retailer's contribution | |
|---|---|---|---|
| Login and display of assigned customer prices | Two test accounts each see the prices authorised for them | Test accounts, price reference and role approval |
| Item, unit and quantity selection in the cart | A specified cart agrees with verified product data | Product examples with clear units |
| Order transfer to ERP with a clear outcome | Test order in ERP with the correct company, goods and quantity; errors or uncertain outcomes remain unconfirmed | ERP test access and a responsible process owner |
| Documented handover of deployment and error handling | The named operations contact can follow the instructions in a test | Hosting access and a technical contact |
Ask for a response to each row: included, offered with different scope or still unresolved. Differences need an explanation. A blanket statement such as “ERP integration included” does not explain which of these tasks is covered.
Keep unresolved prerequisites visible
In this example, permission to write orders through the ERP interface has not been confirmed. Treat this capability as an unresolved prerequisite in the request. A bounded investigation could first establish the access route, write capability and outcome of a test order. The affected scope can then be described more reliably.
A provider can also offer an explicitly conditional item or an alternative. What matters is that an unverified assumption does not silently become the basis for the entire quote.
Bring the responses onto the same basis
Ask providers to explain development work, external services and ongoing operations separately. Record the contributions and approvals your business must supply and what remains unresolved if prerequisites are not met. A fixed price does not make different scope boundaries equal.
Before comparing amounts, reconcile responses and exclusions with the table. If an outcome is missing, ask how it will be handled. This creates a shared basis for deciding without assigning invented solutions or prices to unresolved points.
Sources
Read more
All articles
IT Consulting & Strategy with ASES
Strategy, architecture and technology choice