Why fixed-price deals in IT projects lose money more often than you think

You prepare a quotation for a software project. You estimate 400 hours, calculate with an internal cost price of €75 per hour and add a 20 percent margin. The client agrees to a fixed price of €37,500. After delivery the margin turns out to be less than 5 percent.

We see this often at IT service providers and software agencies, including agencies that estimate carefully. The estimate is correct. The causes lie in what happens after the estimate, and those causes are well described in the project management literature. This article goes through them and shows how to measure the margin per sprint instead of at the post-calculation.

Why a fixed price cuts the link between costs and revenue

With a fixed price, the project's revenue is fixed the moment the client signs. The costs are not. They consist of the hours your team actually puts in, at the cost price of the people doing the work. Everything that changes after the signature therefore comes entirely out of your margin.

With a fixed price you are in effect selling insurance on your own estimate. The client buys certainty, you carry the risk that the estimate was too low. An insurer charges a premium for that. In most quotations we see, that premium is not stated explicitly, or it is hidden in a buffer that is rarely left over (see cause 1).

On an hourly-rate project you see an overrun on the next invoice. With a fixed price you only see it if someone puts the hours worked, at cost price, next to the agreed price. That often only happens at the post-calculation, when the project has already been delivered.

Five causes that go deeper than a wrong estimate

1. The buffer is used up before it is needed

Virtually every estimate contains a buffer. In the example it is 40 of the 400 hours: the net estimate was 360 hours, and the 10 percent on top is meant for setbacks. In practice that buffer is almost always gone by the end of the project, usually without there having been a real setback.

The explanation was described as early as 1955 by Cyril Northcote Parkinson: work expands to fill the time available. Eliyahu Goldratt worked this out for projects in Critical Chain (1997). As soon as an engineer knows that 400 hours are available, 400 hours becomes the plan. The safe estimate becomes the norm, and the buffer hours are used for extra finishing, for work that needs to be done a bit differently after all, or are lost to what Goldratt calls the student syndrome: only starting when the deadline approaches, because there is room anyway. If a real setback does come after that, the buffer is already gone.

On top of that, at many agencies an estimate is implicitly a promise. An engineer who estimates 360 hours and needs 380 has to explain that. With 400 estimated and 400 used, nobody asks anything. So the system rewards using up the buffer.

The solution Goldratt proposes also works for software projects: have the team estimate without a safety margin per task, and put the buffer as a single item at project level, managed by the project manager or the owner. The team plans against 360 hours. The 40 hours are there, but they are not a target. Per sprint you report how much of the buffer has been used against how much of the project is finished. If 60 percent of the buffer is gone at 40 percent progress, you know enough.

2. The engineer builds a Mercedes, the client ordered a Golf

A good programmer works towards perfection. That is a quality you want in your team, and at the same time one of the largest cost items in a fixed-price project. The client bought a solution that solves his problem, and is happy with an eight out of ten. The last two points to a ten cost a disproportionate number of hours: neater code, an extra abstraction layer for a future that may never come, an interface that is nicer than requested. In project management terms this is called gold plating.

Nowhere is it recorded what an eight is. Without explicit acceptance criteria, "done" in practice means "the engineer is satisfied", and that bar is higher than the client's. The hours in between are spent without anyone having chosen to spend them.

The solution is a Definition of Done per feature, agreed with the client before the sprint starts: what it must do, what it must not do, when it is accepted. It also helps to give each feature an hours budget and make it visible to the engineer. Someone who knows there are twelve hours for a component makes different choices from someone who only knows it has to be "good". The quality level then becomes a commercial decision you take in advance, instead of an outcome you discover afterwards.

3. Extra work without a commercial reflex

During the project the client asks for a change that was not in scope. Usually it is a few hours, and they are done without adjusting the price, because nobody wants to put the relationship under pressure for a few hours. Over the course of a 400-hour project this easily adds up to 40 or 60 extra hours. That is 10 to 15 percent of the budget, and it is recorded nowhere.

The underlying mechanism is an asymmetry in memory. The client remembers that "yes" was said and from then on regards the change as part of the agreement. The agency does not remember the hours, because they were never recorded as extra work. At the final invoice there is therefore no basis left to discuss it.

The solution is an extra-work register that is kept even when you decide not to charge anything. Every deviation from scope gets a line: what, how many hours, invoiced or not. Those lines appear as a separate item on the invoice, even if the amount is €0. That makes visible what you are giving away, gives the client a realistic picture of what he is receiving, and gives you a negotiating position for the next project. A threshold also helps: changes above a certain number of hours (for example four) go past someone with commercial responsibility before they are built.

4. Staffing differs from the estimate

The quotation assumes a medior developer at €75 per hour. That person is on another project or drops out, and a senior at €95 takes over. The work gets done and the client notices nothing, but the cost price of those hours is 27 percent higher than budgeted. In the example this concerns 60 hours, so €1,200 of margin.

This usually happens without anyone looking at it: planning is based on availability, and cost price does not appear in the planning. The solution is simple, but requires the estimate to be made per role and time registration to record the role: per project you track the realised average cost rate against the estimated one. If it deviates, that is either a deliberate choice that you record including its effect on margin, or a signal to adjust the planning.

5. Estimates are too optimistic, and early in the process above all too wide

Daniel Kahneman and Amos Tversky described the planning fallacy in 1979: people systematically underestimate how long a task will take, even when they know that similar tasks overran in the past. The estimate is made from the plan (what needs to happen), not from experience (how similar projects turned out). Bent Flyvbjerg calls the remedy reference class forecasting: estimate on the basis of the actual outcomes of comparable earlier projects, and use them to correct the inside-view estimate.

There is a second problem that has nothing to do with optimism: the moment at which the estimate is made. In 1981 Barry Boehm mapped how far estimates of software projects were from the actual size, set against the phase in which they were made. Steve McConnell developed that into what is now called the cone of uncertainty. The figures: at a first idea, the actual size is somewhere between a quarter and four times the estimate. After an approved product definition it is half to double, a factor of two. After fully worked-out requirements, two thirds to one and a half times. After functional design and choice of architecture, 80 to 125 percent. After technical design, 90 to 110 percent.

For the example project, a factor of two means the 400 hours from the estimate could in reality be 200 or 800 hours, and that both outcomes are equally defensible at that moment. A fixed price of €37,500 on a project that could also cost 800 hours is a gamble with €22,500 at stake: that is the loss if it ends up at the top of the range. With a range of 80 to 125 percent, the extreme is 500 hours, so €37,500 in costs. In the worst case the project then yields no margin, but no loss either. That is the point at which a fixed price becomes defensible.

This gives a practical rule for what is acceptable. A range of 25 percent or less, so after functional design and architecture: a fixed price is responsible, with a risk premium that covers the upward deviation. A range of 50 percent, so after worked-out requirements: a fixed price is only possible with a frozen scope and an explicit risk premium, or better, a fixed price per phase. Anything before that, a factor of two or wider: an indication within a range, and no price.

Uncertainty only shrinks by doing work: writing out requirements, designing, choosing the architecture, running a first sprint. Thinking longer about the same estimate does not change the range. That is why agencies that do this well sell the first phase separately: a paid scoping or design phase of one or two sprints, delivering a worked-out design, an estimate with a range of 25 percent and a fixed price for the rest. The client pays for that phase. What he gets in return is a price he can rely on, instead of a price the agency has to renegotiate halfway or quietly pays for out of its margin.

The figures from Boehm and McConnell are averages across many projects. You get your own range per phase from your post-calculations: for each completed project, put the estimate at quotation, at design and at the start of the build next to the actual hours. After ten projects you have your own cone, and it is usually wider than expected. That is reference class forecasting in practice. If your last ten fixed-price projects cost on average 18 percent more hours than estimated at quotation, that is not a coincidence, and that 18 percent belongs in the next estimate.

Also estimate in three points: optimistic, most likely and pessimistic, and calculate with the weighted average (optimistic plus four times most likely plus pessimistic, divided by six). For the example: 360, 400 and 560 hours gives an expected value of 420 hours. The difference from the 400 of the single-point estimate, 20 hours, is the risk premium that belongs in the price.

How to measure the margin during the project

The five causes above have one thing in common: they become visible in the hours long before they become visible in the invoice. The method for measuring this has existed for decades and is called earned value management. It was developed for large construction and defence projects, but the core fits in a spreadsheet and works per sprint.

You need three figures. The planned value: what part of the budget should have been spent by now according to the plan. The earned value: what part of the scope is actually finished and accepted, expressed in budget. And the actual costs: the hours spent at the actual cost price per role. The ratio between earned value and actual costs is the cost performance index. If it is 1, you are in line with the estimate. If it is 0.85, every euro of delivered work costs €1.18.

Back to the example. The project is planned in eight sprints of 50 hours, cost budget €30,000. After three sprints, 37.5 percent of the scope has been accepted, so the earned value is €11,250. The actual costs: 150 planned hours at €75 plus 20 hours of extra work by a senior at €95, together €13,150. The cost performance index is 11,250 divided by 13,150, or 0.86. Divide the cost budget of €30,000 by 0.86 and you have a forecast of total costs: just over €35,000. Against a price of €37,500 that is an expected margin of about 6 percent. The quotation said 20.

You know this after sprint three. There are then still five sprints in which to act: charge for the extra work after all, bring staffing back to the estimated mix, define the scope of the remaining sprints more tightly, or deliberately accept that this project yields less and settle that within the relationship. After delivery only the post-calculation remains. In the example it comes to €35,700 in costs and a 4.8 percent margin.

What you need for this: time registration per project and per role, an up-to-date cost rate per role, and a sprint close in which scope is accepted, so that the earned value is not an estimate. The calculation itself takes a quarter of an hour per project per sprint.

The commercial side: price the risk you are selling

A fixed price is a choice. Whoever carries the risk of the estimate should be paid for it, and that premium belongs in a separate risk reserve at company level, apart from the team's buffer (which gets used up, see cause 1). In concrete terms: the team estimates 360 hours, the project manager manages 40 hours of buffer, and the commercial price includes on top of that a premium for the estimation risk. Its size follows from the three-point estimate and the range of the phase: in the example 20 hours at a range of 25 percent, and more as the range gets wider.

With high uncertainty, a different form of contract fits better. A fixed price per sprint with variable scope puts the risk with the client, who decides what is built in each sprint. An hourly rate with a cap shares the risk. Jeff Sutherland described a variant that is more common in agile contracts: the client may stop at any time and then pays a percentage of the remaining budget, and may swap scope as long as the total size stays the same. Which form fits depends on the phase you are in and therefore on the range of the estimate (see cause 5). At a factor of two, so before the requirements have been worked out, a fixed price is not wise in any form of contract. In that case, first sell the design phase at a fixed price and then give the price for the build.

How to protect the margin on fixed-price projects: six measures

To protect the margin on a fixed-price project, you have to cover each of the five causes above separately and measure the margin per sprint. That comes down to six measures you can introduce within a month.

1. Split the estimate into a net estimate and a project buffer, and manage the buffer outside the team. Report buffer use against progress per sprint.
2. Record a Definition of Done and an hours budget per feature, agreed with the client, before the sprint starts.
3. Keep an extra-work register and put every deviation as a separate line on the invoice, even at €0.
4. Estimate per role and record hours per role, so you can track the realised cost rate per project.
5. Calculate the cost performance index and the cost forecast per sprint. Agree at which value (for example below 0.9) a conversation with the client or internally follows.
6. Feed the post-calculation of each completed project back into the estimating basis for the next quotation.

Frequently asked questions

Why is the buffer in a project estimate always used up?

Because the team knows about the buffer and the safe estimate therefore becomes the plan (Parkinson's law). In addition, most organisations reward using the full estimate and penalise exceeding a tight one, so nobody has an interest in leaving buffer hours unused. The solution from Critical Chain (Goldratt): estimate without a safety margin per task and manage the buffer as a single item at project level.

How do you stop developers building more than the client needs?

By agreeing in advance with the client, per feature, what will be accepted (Definition of Done and acceptance criteria) and by making an hours budget per feature visible to the engineer. Without those two, "done" is determined by the engineer's quality standard, and that is higher than what the client bought.

How do you calculate the margin of a software project during the project?

With earned value: divide the value of the accepted scope by the actual costs to date (hours spent at cost price per role). That ratio, the cost performance index, together with the cost budget gives a forecast of total costs, and therefore of the margin. You do this per sprint or per month.

Does earned value management also work for agile software projects?

Yes, provided the sprint close is a genuine acceptance of scope. The earned value is then the part of the backlog that has been delivered and accepted, expressed in budget. Actual costs come from time registration. The formal version of earned value is more extensive, but the cost performance index and the cost forecast are enough to steer per sprint.

When is it better not to agree a fixed price?

As long as the range of the estimate is wider than 25 percent. According to the cone of uncertainty (Boehm, McConnell), that is the case until the functional design and architecture have been worked out; after a product definition alone, an estimate still lies between half and double the actual size. In that phase, sell a paid design phase, a fixed price per sprint with variable scope, or an hourly rate with a cap, and only give the fixed price after that.

What does a factor-of-two uncertainty in a software estimate mean?

That the actual size lies between half and double the estimate: 400 estimated hours can become 200 or 800 hours. This is the range immediately after a product definition, before requirements and design have been worked out. The range only narrows by doing that work, not by thinking longer about the estimate.

Fixed price or time & material for software projects: which is wiser?

That depends on the phase. With a range of 25 percent or less (after functional design and architecture), fixed price is responsible and gives the client the certainty he is looking for. Before that, time & material with a cap, or a fixed price per sprint with variable scope, fits better, because otherwise the agency carries a risk it cannot assess. A combination often works best: a paid design phase on time & material, then fixed price for the build.

How high should the risk premium on a fixed price be?

At least the difference between the weighted three-point estimate and the most likely estimate. In the example: 360, 400 and 560 hours gives an expected value of 420 hours, so a premium of 20 hours (5 percent) at a range of 25 percent. With a wider range, the pessimistic estimate is higher and the premium therefore larger. Also correct with the average overrun from your own post-calculations of comparable projects.

Further reading: Keeping projects profitable: from estimate to evaluation and Utilization rate vs. profitability, the metric agencies forget.

← Back to knowledge base