Questions to ask before quoting a fixed price implementation project

Questions to ask before quoting a fixed price implementation project must show what the price covers.

Useful questions do more than collect details: they show whether each point is an explicit requirement, a stated assumption, or a missing fact. You can then price, test, exclude, or decline each point.

This sequence gives each answer a commercial result for IT services teams that must quote before implementation starts.

What must be explicit before you estimate?#

Start with the result, not the proposed technology. Ask what must be true for the client to accept the implementation.

Use these questions:

1. What business process will change when this project is complete?
2. Which user groups and business units are included? Which countries and environments does the project cover?
3. What must the team configure, build, migrate, and integrate? What must it test and document? What training must it provide?
4. What named deliverable proves each part is complete?
5. Who accepts each deliverable, and what test will they use?
6. Which dates are fixed, and what event makes each date fixed?
7. What work is explicitly outside this project?

Do not accept “system implemented” as a deliverable: it has no count, boundary, or acceptance test that you can use to check completion. Replace it with outputs that you can verify. For example: one configured production environment, one approved migration run, and one administrator handover session.

This sets the proposal's boundaries. The guide to defining deliverables that clients cannot expand shows how to add counts and acceptance tests.

GAO's cost estimating guide includes scope, schedule, a technical baseline, a work breakdown structure, and assumptions among its estimating steps. It addresses government programmes. Use those categories to structure your technical review, not as a ready-made commercial quote.

The proposal guides explain how to turn those boundaries into work the client can review.

Which assumptions are carrying the price?#

An assumption is a statement you price as true without complete evidence, not a hidden reserve for uncertainty.

Ask your delivery lead to finish these sentences:

• “The client will provide...”
• “The source data contains...”
• “The target system supports...”
• “Access will be available by...”
• “The client will decide...”
• “Testing will include...”
• “Support after launch will last...”

Turn each answer into a plain statement. Add an owner and a confirmation date. State what happens if the assumption is false.

For example: “The client will provide a complete customer export with stable identifiers by 6 October. If identifiers are absent, data matching is new work.” The assumption now protects a specific estimate line.

Ask the client to confirm or correct every material assumption, and treat any assumption that nobody can confirm as a missing fact. Silence is not confirmation.

The scope exclusions guide explains how to test an uncertain boundary. Use an exclusion only when you can identify the excluded work during delivery.

What integration facts are still missing?#

Integration names are not integration facts. “Connect CRM to finance” says nothing about the work inside the connection.

Ask these questions for every source and target system:

1. Which product is in use, including its version and edition? What hosting model and environment does it use?
2. Is there a supported API, file exchange, event feed, or database interface?
3. Who owns the interface and its credentials? Who owns the firewall rules and test environment?
4. Which objects and fields move in each direction?
5. How must you transform and validate the data? How must you handle duplicates?
6. How much data must move, and how often? What delay is acceptable?
7. How does authentication work, and which permissions can the client grant?
8. Can you inspect a sample payload and its schema? Is API documentation or a working test available?
9. What happens after a failed transfer, and who resolves it?
10. Which system remains the source of truth for each record?

Ask for evidence that shows how the connection works, such as a successful test call, sample export, field map, or vendor confirmation. A sales assurance such as “the systems integrate” does not define how you will implement the connection.

Count each interface separately, with its direction and purpose stated so that you can check it against the estimate during delivery. If a second data flow appears later, you can show that the original estimate did not include it. The method for stopping unscoped integration work gives a practical interface register.

Questions to ask before quoting a fixed price implementation project#

Use this recommended decision tree, not an empirically tested pricing rule. Run each requirement through it. Apply it to each assumption too, and then to each dependency and integration. Do not run the whole brief through it as one item.

Can the client state the required result?
├─ No → Ask who needs the result and what decision it supports.
│       ├─ Still unclear → Decline fixed pricing or sell discovery.
│       └─ Clear → Continue.
└─ Yes → Is the output bounded by a count and acceptance test?
        ├─ No → Define the boundary. If you cannot, sell discovery.
        └─ Yes → Do you have evidence for the delivery method?
                ├─ Yes → Is any estimate input controlled by the client or a vendor?
                │       ├─ No → Price the work.
                │       └─ Yes → State the assumption, owner, date, and failure result.
                └─ No → Could the missing fact change method, effort, or specialist need?
                        ├─ Yes → Test it in paid discovery before fixing the price.
                        └─ No → State a narrow assumption or exclusion, then price.

Use the last question to decide which missing facts need discovery before you price the work.

Do not hide that choice inside a percentage buffer. Instead, price a paid discovery phase with named outputs.

Which client dependencies can change the quote?#

Fixed-price work still depends on the client's actions. Ask who will provide access and data. Name the people who must make decisions, review the work, and approve it. Then ask when you must receive each item.

Test the dependency in operational terms:

• Which named role owns it?
• What exactly must they provide or approve?
• What format must they use?
• What quality check applies?
• What is the latest useful date?
• What work stops if it is late or incomplete?
• Does a delay move the schedule, add cost, or both?

A response time such as “within two days” also needs a start point. State whether the clock starts after delivery, review submission, or a complete request.

Unclear dependencies can change the work you must deliver. In US federal procurement, firm-fixed-price contracts place cost and profit risk on the contractor. That rule is not a universal contract term. Check your agreement and put response rules and the change process in the proposal.

When should you refuse to give a fixed price?#

Do not give a fixed price when a material branch in the work remains open. Offer paid discovery or a phased quote instead. A different commercial model is another option.

Stop and change the approach if:

• nobody can define the acceptance result;
• no authorised client owner can answer the questions;
• access cannot be tested before the commitment;
• the source data cannot be sampled;
• a vendor controls an undocumented interface;
• the client expects included work to change during delivery;
• the deadline depends on approvals with no response rule;
• the requested price must cover several incompatible technical routes.

You have not failed to estimate. You have decided not to sell unknown work as known work.

If the client needs a budget now, give a range with its basis and label it as a planning figure, not a fixed quote. State what discovery must resolve before you commit.

How do you turn the answers into a quote?#

Create four lists: explicit requirements, confirmed assumptions, missing facts, and exclusions. Link each item to a deliverable, or explain why the price does not include it.

Then apply one action to every item:

State	Action before quote	Proposal treatment
Explicit requirement	Estimate the bounded output	Included deliverable and acceptance test
Confirmed assumption	Price on that basis	Assumption with its owner and failure result
Missing material fact	Resolve through discovery	Discovery output, then reprice
Missing minor fact	Use a narrow stated assumption	Assumption or allowance
Excluded work	Define the observable boundary	Scope exclusion and change trigger

Review the result with sales to confirm the client's need and with delivery to confirm the effort. Ask the technical owner to check each integration method and missing fact.

Only then build the estimate, showing labour and fixed costs for each deliverable, along with its contingency and margin. Do not let one total hide a group of work that you have not tested.

Use the same structure during delivery. If evidence breaks an assumption, stop the affected work and use the agreed change request process. The proposal then acts as a decision record, not only a sales document.

Start a free Korrel trial to separate requirements, assumptions, and missing information before you build the fixed-price estimate.