handcuffs_0

Fixed price part 1, what’s so bad?

In his excellent article 10 Contracts for your next Agile Software Project, Peter Stevens described 10 different contracts that are often used in software development projects. At the end of his article he singles out one contract-type:

“Fixed price projects and agile development are considered not to mix. I know from experience that this is not strictly true. I am also convinced that other forms are better.”

I completely agree with him on this but since fixed price contracts are so common in software development it seems like a good idea to look at them a bit more carefully. In this article I want to look the problems with fixed price and why traditional software engineering methodologies are unable to solve these problems. In my next article I want to continue on a more positive note and show how agile practices will help you make the most of fixed price.

What’s so bad?
The most obvious downside is of course lack of flexibility. Fixing project scope in the contract often makes it non negotiable during the project often preventing change altogether. In my experience stakeholders will change their minds during any non-trivial project and fixing scope at the start of a project will limit the quality of the end-product because it will not fit the client’s wishes one-hundred percent.

Not only scope is fixed at the start of a project but price is also fixed, hence the name. Making the supplier to commit to price estimates even before the project has started forcing critical decisions at the worst time possible. The later you make a decision the more information you have to base that decision on. Agile tells us to make them at “the last responsible moment”. Making them sooner is risky.

Fixed price projects are often more expensive than they should be. The rigidity of these projects often causes scope to be too large. At the start stakeholders in the client-organization will specify many requirements and features they probably won’t need ‘just in case’. They know it will be hard to get them in later. Fixed price projects also force the supplier to make very accurate estimates at the start of a project to reduce risk, the time spent creating these estimates are later often added to the price of the project. Suppliers often also add a fee for the extra risk they have to carry, a former employer of mine added 20% to fixed price contracts and seeing how much trouble fixed price was for them this was actually low.

Instead of aligning interests of the client and the supplier fixed price projects artificially opposes them. The client will want to stretch the scope agreed in the contract as wide as possible while the supplier will want to do as little work as possible. This often prevents good communication while increasing risk. I have yet to see a fixed price project where the client delivered an on-site-customer and I don’t think this is a coincidence. Fixed price pushes stakeholders into roles that are not beneficial to the success of a project.

Fixed price and BDUF
I’ve heard more than once that these problems make fixed price problems especially to do in an agile way. A potential employer once told me when I asked him if they used any agile practices “We do fixed price so we can’t do agile”. When you look at the downsides of fixed price projects this seems logical. Fixed price has problems with some of the core agile values like flexibility and communication. The focus on up-front estimation also seems to point to big design up front or BDUF.

Unfortunately more traditional approaches won’t help us either. Big design up front will not help with estimations. We need accurate estimations before the project has even started. There hasn’t been time to gather anything resembling a complete set of requirements. Traditional estimation techniques like function point analysis are only as good as the data you put into them and unfortunately the data isn’t very good at the start of a project. Problems with flexibility and communication are only hidden, not solved.

Fixed price has some big problems. Not only for the supplier as many clients seem to believe but also for clients. These problems don’t go away by giving in to the traditional big design up front methodologies although some of the problems with flexibility and communication will be less visible. In the next article I want to look at how you’d do fixed price in a more agile way. This won’t solve the problems but it will give some tools to see them coming and to make it easier to switch contracts during a project.

6 thoughts on “Fixed price part 1, what’s so bad?”

  1. I think you are on to something. Traditionally fixed price is well suited for the scenario where product is already produced, and therefore the cost and infrastructure has been established and remains fixed.

    What the clients forget is that you are essentially building something that is only exists in their minds, and that you have an idea of what they want. UI development on fixed price? Forget it. Management jumps on the Internet and sees an idea that they think would be cool. Okaaayy. That means more time. That means more money.

    I have always questioned the tactic of “squeezing in” as much as you can into a contract, because you run this risk of diluting the focus on the core objectives. It’s really silly when you think about. “If you have time, can you install a passenger-side air bag?” Many things in life are not ad hoc, and when they are, usually they are done with duct-tape.

  2. Hi There,

    Great article. I have to admit, I have worked in the consulting world for years and you are right about fixed price. When estimating work, we would always add quite a solid margin of error into quotes. Often 25% or more.

    I love the way our current team works. We practice SCRUM religiously and are building the new release of our product to cater for it. The problem which we all face though is that from a stakeholders perspective, they want to limit the amount which they will spend on their project. If they can nail their implementation partner down to a price, as far as they are concerned, they have fixed their outgoings and have a guaranteed delivery.

    Am interested in seeing part two of your article!

    Adam

  3. Any ideas for government projects? Too often than not, they have to request the budget a year earlier, with specific specs and scopes. By the time the vendor got the project, budget has been set in stone. Scope has been set in stone. Time may not be set in stone, but you already know upfront how much you would be burning before your balance sheets turns red.

  4. Thanks for the nice comments!

    @David Robbins
    Yup, implementing stories in order of importance and then stopping when you’re not delivering business value any more usually gets rid of this problem. Unfortunately Fixed-price makes this hard because you have to keep going until you have implemented everything in the contract.

    @Adam Feldman and Fadzlan
    Current practice is very much geared towards competing on price for software engineering projects. This leads to situations where suppliers offering fixed price contracts with very low estimates win the contract. Usually this leads to problems later so next time the customer is even less inclined to trust the supplier enough for other types of contracts.

    Also many clients have budget concerns (large organizations often have the same problem as government projects here) So even though Fixed price is far from ideal it will be a long time before we can get away from fixed price projects.

    In my next article I want to get into doing agile fixed price. I think there are some ways we can get out of fixed price contracts easier and if that’s not possible make fixed price hurt a bit less by making it more manageable.

  5. As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it’s spending money, at worst – waisting money. That is why real huge governmental projects are fixed priced: Nobody really cares.

  6. I suggest that you stand back and look at fixed price projects from a different perspective. First there are effectively three elements in a fixed price contract: Scope, Resources, Time. In our Agile practice we fix resources and time – the scope is variable. Of course the customer might initially cry foul until they come up to speed with the concept of Agile but once they see the value of delivering lean, fit to purpose, application software they will fully embrace the concept.

    So, fix the resource and time! Do this by defining user stories for ‘everything’ the customer wants and then set a time box for the project. This effectively fixes your Resources and Time. Next apply the practice of working your backlog in priority order (of course looking at risky features and moving them forward when it makes sense so they don’t hit you at the end) and deliver something the customer can really use. This will lead to happy customers and usually a second project to pick up the lower value features that were moved out of scope.

    Everyone wins!

Leave a Reply

Your email address will not be published. Required fields are marked *