+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Quoting fixed price without losing money

IT Strategy By Mits Engineering Team 2 min read
Quoting fixed price without losing money

Fixed price is what most Indian buyers want, and for a supplier it is a bet on your own estimate. The bet is winnable on well-defined work and close to unwinnable on vague work, and the commonest cause of an unprofitable services project is a fixed price quoted against a brief that could be interpreted three ways. The discipline is not better estimating; it is declining to quote fixed price on work that is not fixed.

The test is simple and worth applying every time. Could you hand this brief to three different teams and receive three implementations you would consider equivalent? If yes, estimate and quote. If no, the scope is not defined, and a fixed price is either padded heavily — in which case you may lose the deal to someone who did not pad — or it is optimistic, in which case you will recover the difference through change requests, and the relationship becomes adversarial around month three.

Where the brief is unclear, sell a paid discovery first at a fixed price of its own. Two to four weeks producing an architecture, a costed plan and a specification precise enough to quote against. That is genuinely boundable, it is valuable to the client even if they take it elsewhere, and it converts an unquotable project into a quotable one. Clients who refuse to pay for discovery are usually the clients whose projects go worst, so the refusal is itself information.

Estimate bottom-up and then apply a contingency you name rather than hide. Break the work into pieces small enough that someone has built something comparable, estimate each, and add explicitly for the things that always happen: integration surprises, environment setup, review cycles, the client's availability, and rework from feedback. A contingency stated as a line item can be defended; one buried in inflated task estimates gets negotiated away piece by piece.

Then protect the margin with contract mechanics rather than optimism. A written definition of done. A named change process with a price attached, so additions are decided rather than absorbed. Client-side obligations with dates — access, data, decisions, environments — and a stated consequence when they slip, because supplier-caused delay and client-caused delay should not have the same effect on your margin. And staged payments tied to deliverables rather than to elapsed time.

Finally, measure every completed project against its quote, by phase, and keep the record. After a dozen projects you will have a multiplier for your own team on your own kind of work — and that number, applied to a bottom-up estimate, is worth more than any estimation technique. Firms that do not track this estimate from optimism forever, because there is no feedback loop connecting the quote to what actually happened.

Need help with this? Explore our Software Development services. Learn more Back to all news

Keep reading

More on IT Strategy