Why fixed-price, fixed-scope projects are nearly always a bad idea

There are lots of reasons why a client might prefer a fixed-price, fixed-scope project. The biggest one is there’s a feeling of security when you set out to buy something and you know exactly what that something is, and how much it will cost.

It’s a bit like when you need a loaf of bread and you have $5 in your wallet. You go to the bakery, find a $5 loaf and buy it.

Except building a website isn’t anything like buying a loaf of bread.

It’s iterative and constantly changing. What you wanted on day one probably won’t resemble what you discover you need on day 10, or what you get on completion day.

That’s why, unless you can see into the future, it’s impossible to work out a fair fixed price and fixed scope before getting started on a project. Anything fixed will be a guess, and probably a bad, unfair guess at that.

Let us explain.

The Problems with Fixed price, Fixed Scope Projects

We’ve already established that only clairvoyants can see to the end of a project before it begins. While we at IC are a lot of things (pianists, parents, tabletop role-playing game enthusiasts), we’re not psychic.

Overpricing to Mitigate Risk

We’re often asked to quote, on a fixed-price, fixed-scope basis, for projects that involve research and design phases.

“Research and design phases” imply that you’ll discover something you didn’t know before. But if the scope is fixed, why bother doing any research? The discovery is only going to change the scope, which is not allowed!

Only a fool wouldn’t protect themselves from risk, so at quoting time we normally assume that the research will uncover an extremely demanding, unexpected feature, or that the design will be tricky to implement, so we’ll build in an extra cost margin to cover risk. It’s the only way we can guarantee we won’t lose money.

That’s no good for the client, and it only gets worse.

Stuck with Features That Turn Out to be Non-essential

We’ve seen it a thousand times: we start working, and as soon as we get an initial-version software to the client, their understanding of what’s possible will change.

Originally you thought feature X was essential, but now you realise an out-of-the-box solution will do everything you wanted feature X for, so it’s not worth spending more time and money on it.

Except with a fixed price, unless you can make a contract variation (not always easy), you’re locked into paying for feature X even though you don’t need it.

Arguments Over Scope

Another problem with a set feature list is that we’ll often interpret it one way, and our client will interpret it another way.

We’re developers, so we know a lot about building websites, and we might assume you’re looking for something a lot more sophisticated or complex than you are. We might quote a price based on that complex solution, when you were just looking for something simple (and cheaper).

On the other hand, you know a great deal about your business, so some things might be obvious to you about what's needed in feature, that we don't understand at quote time.

From the start, we’re setting ourselves up for ongoing arguments over the scope that's allowable within a budget that's already been decided. Productive arguments in a project are healthy and good, but these kinds of arguments tend to get pretty difficult.

No Flexibility

Working piecemeal and allowing clients to test bit by bit is much better for the end result, and helps set the direction of the project.

In a fixed-scope, fixed-price arrangement, it’s in the developer’s best interest to not communicate regularly throughout the project. That’s because the scope is set in stone on day one, and giving updates only leads to confusion, conflict or change.

It’s better for the developer to make monolithic deliveries which tick boxes on the scope list, rather than being flexible. Better for the developer, but not better for the project or for you.

An adversarial, rather than cooperative, relationship

Sharing and cooperating always gets the best result. Fixed-price, fixed-scope projects motivate everyone to look out for their own interests and focus on getting the best value rather than building the best website.

The developer is motivated to stick absolutely to the agreed scope (even if it proves to be not quite right), work as fast as possible, and deliver the minimum they can get away with, just to maximise profit.

The client is motivated to argue for as many features, bells, whistles and revisions as they can get away with to achieve the best “value for money”.

It’s clear that fixed-price, fixed-scope doesn’t work very well, but is there a better alternative? We’re glad you asked.

We call it “straightforward billing” and we'll talk a bit more about it next week.

This post is part of a series about Agile Development and how we use agile approaches at the IC. Get updates to this series and more new ideas by signing up to our mailing list.