Fixed Price vs Time and Materials Software

Fixed price vs time and materials software: which overruns less?

Neither model overruns less on its own. Fixed price puts the cost of drift on the vendor when scope is stable and testable. Time and materials suits work where discovery is the real task. Changing scope drives most overruns, whatever the contract says.

Viithiisys has shipped software since 2007 and has completed 500+ projects for clients in the US, UK, Canada, India, China and Nigeria. This article does not publish an overrun percentage for each contract model. A figure is only useful with its definition, its baseline and its sample, so we give you the definition and the method and leave the numbers out. You can then judge any vendor's figures, including ours.

What counts as an overrun?

Overrun means final delivered cost measured against the baseline agreed at kickoff, expressed as a percentage. Decide up front whether approved change requests move the baseline. If they do, a project can grow a great deal and still show no overrun. Report both versions, with and without approved changes, or the comparison tells you little.

How should projects be classified for a fair comparison?

A project is fixed-scope if the written scope and acceptance criteria were signed before build started. It is time and materials if work was billed against effort with a backlog that could change. Hybrid engagements, such as a billed discovery phase followed by a fixed build, belong in a third group. Mixing them into either of the other two hides the most useful pattern.

How should you compare fixed bid vs T&M overrun figures?

Ask for two numbers per model, not one: how often projects finished above baseline, and how far above when they did. A model that overruns often by a little and one that overruns rarely by a lot are different risks for a CTO. A comparison worth reading reports, for each of fixed-scope, time and materials and hybrid:

• Project count: how many engagements are in the group.
• Share over baseline: the percentage that finished above the kickoff figure.
• Median overrun: the typical size of the overrun among those that went over.
• Share on or under baseline: the projects that finished early or exactly on budget.

Any comparison also hides a selection effect. Teams tend to offer fixed price on work that looks well understood, so fixed-scope projects start with an easier profile. A lower overrun rate for fixed-scope work partly reflects what was chosen for it, not only what the contract did. Splitting results by project size reduces that distortion but does not remove it.

Does project size change the picture?

Larger projects tend to carry more unknowns, more stakeholders and more integration surface, so there is more room for drift. Size bands show whether the model matters more at the small end or the large end. Define them by baseline duration in weeks or team-months, not by currency, so they stay comparable across years and countries.

Why does the large band behave differently?

Large projects rarely stay at their original scope for the whole build. A fixed price on a long engagement turns into a stream of change requests, each negotiated separately. The contract then carries the paperwork of time and materials without its transparency, which is the failure mode to watch for.

What actually causes software project overruns?

Overruns come mainly from scope that changed after estimation, requirements that were ambiguous when the estimate was made, and slow decisions on the client side. The contract model sets who pays for the drift. It does not stop the drift.

The best-known public evidence on the scale of the problem is Bent Flyvbjerg and Alexander Budzier's study of 1,471 IT projects in Harvard Business Review. They found an average cost overrun of 27%, but about one in six projects was a "black swan" with an average cost overrun of 200%.

The tail, not the average, is what hurts a company. Software project overrun statistics that quote only the mean miss it, and so does any vendor claim built on an average alone.

Why do estimates miss in the first place?

Planning optimism is documented and persistent. Dan Lovallo and Daniel Kahneman described it in Delusions of Success, where teams plan from the inside view of their own project and ignore how comparable projects ended. Estimates built that way are low before any vendor adds a margin.

How should you tag the cause of an overrun?

Whoever reviews a project should name one primary driver for each overrun at closeout, agreed with the delivery lead and the client, and keep the list short: scope change after kickoff, ambiguous requirements, client decision delay, third-party integration, or technical underestimate. A single driver per project keeps the tally honest. If the wider evidence holds, the first three will dominate and the contract model will explain little of the spread.

What are the three scope controls that cut overruns most?

Three working practices address the main causes above: a written acceptance test for every feature before build, a change process that prices each change before it starts, and a named client decision-maker with a response deadline. These are the controls we apply on delivery. Each is a working practice, not a contract clause, and each targets one of the leading causes of drift.

Why write acceptance tests before build?

A feature with a testable acceptance condition has an end. Without one, "done" is negotiated at the end of the sprint, which is where most scope drift enters. Writing the condition up front also exposes ambiguity while it is still cheap to resolve, and it gives QA and testing something to verify against.

How should change requests be handled?

Every change gets a written estimate of effort and schedule impact before work starts, and the client approves it. This works the same under fixed price or time and materials. The only difference is whether the approved change adjusts a fixed figure or adds to a running total.

Why name one decision-maker?

Waiting on approvals is idle time that someone pays for. A single named owner with an agreed response window removes the committee delay that shows up as slipped milestones. Treat it as part of the scope, with a deadline attached.

If your current project has none of these three in place, our broken workflow assessment is a fast way to find out where drift is entering. You describe the workflow, and we identify where scope, approvals and acceptance are leaking time and budget.

Which fixed price vs time and materials software model fits you?

Use fixed price when scope is stable and testable, time and materials when discovery is the real work, and a hybrid when you are unsure. Match the model to how much of the scope is still unknown, not to how much certainty you want.

The US federal acquisition rules describe the same trade-off. FAR 16.601 notes that a time-and-materials contract gives the contractor no positive profit incentive to control costs, which is why the buyer must manage effort closely. Fixed price shifts that incentive but invites disputes when scope moves.

When does fixed price fit?

It fits an MVP with a frozen feature list, a migration with a known inventory, or an integration against a documented API. Our Moonship MVP offer is built around a fixed scope. It only works when the scope is agreed up front and additions wait for the next cycle, and the timeline is confirmed during scoping.

When does time and materials fit?

It fits exploratory work: a new product with unproven demand, a legacy system nobody has fully mapped, or ongoing engineering capacity. It needs a buyer who reads burn reports weekly. Teams without that capacity often prefer fractional CTO leadership to own the backlog and the budget conversation.

How does Viithiisys price software projects?

Viithiisys scopes every engagement after a discovery call and publishes no rate card, because any number written before scoping would be invented. The commercial shape follows the risk: a fixed scope where scope is known, a fractional basis for ongoing leadership, and a billed discovery phase where it is not.

We have delivered from Mohali in the Chandigarh tricity, with a Canadian office in Markham, Ontario, for clients including Paytm, Snapdeal, IKEA, Nestle, Shiprocket and Vikram Solar.

A short scoping step before any commitment is the practice we favour, because it settles the baseline and the acceptance criteria that every later comparison depends on. You can read more about the team and how we work on the Viithiisys company page.

What does this mean for a buyer comparing vendors?

Ask any vendor for their overrun data and the definition behind it: what the baseline was, whether approved changes reset it, and how many projects the figure covers. If they cannot produce one, the fixed price on the quote is a guess with a margin on top. For the build itself, see our custom software development work.

If you want to see how we scope, run the broken workflow assessment to map where your current process leaks scope, or contact us to talk through a project.