Why We Quote Fixed Scope - And When to Refuse It

Time-and-materials pays us to be slow. That is not a cynical read of the incentive, it is the stated position of the rulebook the US government uses to buy software: a time-and-materials contract “provides no positive profit incentive to the contractor for cost control or labor efficiency”, and therefore “appropriate Government surveillance of contractor performance is required”.[1]

The buyer has to watch the vendor, because the contract will not do it for them. That is what you are signing up to audit when you agree to an hourly rate.

Fixed scope moves that risk. The same rulebook is equally direct about what firm-fixed-price does: it “places upon the contractor maximum risk and full responsibility for all costs”, and in exchange “provides maximum incentive for the contractor to control costs and perform effectively and imposes a minimum administrative burden upon the contracting parties”.[2]

We quote fixed scope because we would rather carry that risk than be supervised.

The part most studios leave out

Fixed price is not better. It is a different allocation of risk, and there is a well-established body of work on exactly when it is the wrong one.

Bajari and Tadelis modelled this in the RAND Journal of Economics: fixed-price contracts give strong effort incentives, but their cost rises with how incomplete the design is, because every deviation has to be renegotiated as a change order. Their prediction is blunt - “simple projects (which are cheap to design) will be procured using FP contracts and will be accompanied by high levels of design completeness”, while more complex projects go to cost-plus with low design completeness.[3]

They also name the cost the client pays that nobody puts in a proposal: raising a change is “time consuming and requires considerable administrative effort”, and a buyer who raises many of them “may acquire a reputation for being difficult to work with”.[3]

Read that as a warning about us, because it is one. A fixed-scope contract makes changing your mind expensive, and it makes you feel awkward about it. That is the mechanism working as designed, and it is the right mechanism only when you already know what you want built.

So refuse a fixed price when

• You are still finding the product. If the honest answer to “what are we building” is “we will know in three weeks”, a fixed quote is a guess with a penalty attached, and the penalty lands on whoever guessed. We will either pad it or lose money on it, and neither of those helps you.
• The scope depends on something nobody has looked at yet. An unmapped legacy database, an API whose behaviour is undocumented, a compliance regime nobody has read. Price the looking, then price the building.
• The vendor quotes fixed without asking hard questions. A fixed price given cheaply is a fixed price that will be renegotiated later, and you will be the one with less leverage when it is.

For those cases, buy discovery as its own small piece of work with its own deliverable, and decide about the build afterwards. Pricing the unknown is how you end up paying for somebody’s guess about it.

Why we still default to it

Because of the shape of the risk, not the size of it.

The best available data on IT project overruns is a study of 5,392 projects by Flyvbjerg and colleagues, and its most useful finding is one that cuts against the usual agency scare story: “contrary to conventional wisdom, there is a strong tendency for IT projects to be on budget (mode and median close to 0% overrun)”.[4]

Most software projects are fine. The problem is what the rest do. The same paper finds the overruns follow a power law with a tail fat enough that “the average cost overrun for IT projects does not exist (i.e., cannot be calculated)”.[4] Their example: a workflow customisation project budgeted at $1,500 that finished at $425,000.

An earlier study of 1,471 large IT projects by the same group put it in plainer numbers: one in six was a black swan, averaging 200% cost overrun and almost 70% schedule overrun.[5]

So the question a fixed-scope contract answers is not “will this cost more than we said”. Usually it will not. The question is who pays if this is the one in six, and the answer to that should be the party who chose the architecture.

Worth stating the limit on that number too: that sample averaged $167 million a project and was 92% public-sector.[5] Those are not your MVP. Use it for the shape of the risk, not the magnitude.

The statistic we will not use

You have read that 31% of software projects are cancelled and the rest cost 189% of their estimates. It comes from the Standish Group’s 1994 CHAOS report and it is in half the agency blog posts on this subject.

We do not cite it, because a peer-reviewed review of that report found the respondents were selected by calling executives and “asking them to share failure stories”, that no definition of the cost-overrun metric was ever published, that Standish declined to explain the method when asked, and that every independently reviewed survey of the same era found average overruns around 30%, not 189%.[6]

We are pointing this out because we would rather be checkable than dramatic, and because you are going to see that number quoted at you by somebody else this week.

What it means in practice

Before any work starts we agree what we are building, when it lands, and what it costs. Weekly, you see it running. When something changes, we tell you what the change does to the date and the number before we start it, and you decide.

The trade is straightforward and it is not free: you get a price that does not move, and in exchange you give up the right to change your mind cheaply. If that trade sounds wrong for where your product is right now, it probably is, and we would rather hear that on the first call than in week six.

If it sounds right, tell us what you are building - the project, the budget range, the date it needs to be live. You get a scope and a price back, or you get told we are the wrong fit for it.