big

NOOP.NL | The Creative Networker

Fixed Price Contracts in Agile Projects

23/09/2008

Gears
Again and again I am asked (or feel compelled) to explain why agile software development fits nicely with fixed price contracts. Some people still think that a fixed price contract requires a detailed up-front requirements study, to accurately calculate the costs of the project. But that's not correct.

These are the arguments that I use frequently:

  1. In all the so-called "requirement studies" that I have seen (for fixed price contracts), I have never come across a proper description of the final product, as it has been delivered to the customer. It appears that, in all our software projects, customers change their minds, and we are simply expected to accommodate for that. Therefore, a detailed requirements study is not the best way to calculate the costs for a fixed price project. It turns out that the details are simply never correct! In fact, it might be easier to base our fixed price calculations on the weather, as it is more predictable than our customers.
  2. A fixed price contract requires only that the scope of the project is constrained so that we are confident enough to carry the risks. You don't need to know the exact length of the third field on the fifth input form on page 283 to do proper risk management. A simple set of high-level requirements is usually sufficient to reduce risks to a manageable degree. We just let the customer know that we're estimating two days for that ordinary customer contact form that he so desperately wants in his product. (And this form is highly unlikely to cost us more than four days.) That's all you need to know when signing the contract.
  3. For fixed price projects it is essential that you are able to constrain the scope (even more than with time-and-material contracts). With changing requirements (which are a fact of life) it is best not to have detailed requirements. From a psychological viewpoint, it is much easier to throw away old requirements, replacing them with new ones, if you haven't wasted time on any details. Oh, you also want a FAQ list in the product? Fine, but we won't have time for the contact form then. Is that ok with you? We couldn't care less, because we had only spent 30 seconds on the requirements anyway…
  4. If you agree on a fixed price contract using high-level requirements (like user stories), you retain the option of negotiating the details of the requirements. If the details of user story A cost you more time to implement than you had expected, then you have the option of implementing user story B later in the project using the simplest interpretation possible. Yes sir, we understand that you had expected the contact form to include support for smileys, attachments and spell-checking. But the import of your product catalog over a 14.4k modem from the backside of the moon cost us more effort than we had expected. (And we're still delivering according to the minimal specifications.)

For time-and-material contracts, working with user stories, or some other form of high-level requirements, is the smart thing to do. Many agile experts have already explained this a zillion times. But for fixed-price contracts, fixing the scope using high-level requirements, and not detailed requirements, seems even more crucial to me. The need to throw away old requirements is much higher, and detailed requirements do not enable you to re-negotiate the work that is involved to implement them.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
A Theory of Everything for Software Development
Professionalism = Knowledge First, Experience Last
Architects vs. Agilists (1 – 1)

This article is written by on in Risk & Uncertainty. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://blog.mendeltsiebenga.com Mendelt Siebenga

    I found that fixed price contracts are a great way to get to know a client. The important thing is to make sure your sales team understands the agile way of working.
    As soon as a client sees you create real business-value every iteration and understand you’re more flexible than just creating the initial requirements one piece at a time they will want you to do more. Agile will give you the opportunity to switch course half-way your sales team has to grab that opportunity to sell the client the features they really want. Because as you say most of them won’t be in the requirements documents that your contracts are based upon.

  • http://theruntime.com/blogs/jacob/ Jacob

    Brilliant. Well-argued. I’ve always preferred fixed-bid contracts for a lot of reasons (beginning with the built-in conflict in interests between me and the client with hourly rates and ending with the advantage that quality programmers have in a fixed bid competition). This is a great way to approach those longer-termed fixed-bid contracts.

  • http://blog.brodzinski.com Pawel Brodzinski

    I agree with your points. However you silently assume your client would share these arguments too which isn’t always true. What more, I can give you whole branches where it is very unlikely to meet a people who would agree with agile approach.
    If your client doesn’t want to agree with “OK, we can have this if we resign from that” methods you’ll face serious issues each time you implement some vague requirement.
    If your client insist on getting detailed specification it won’t be easy to convice them to do other way just because your software development methodology tells so.
    Sometimes agile doesn’t suit to a specific customer organization. Then, you can either reject to work for the customer or adjust your processes to theirs.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    Thanks guys!
    @Pawel: Sure, I understand that some clients refuse to work that way. In that case we simply have to “interface” our way of working (=Scrum) with their old way of working.
    This does *not* mean that you have to adjust your processes. You simply have to translate them. E.g. it’s fine if they want a full-blown requirements study. We’ll just convert that to a list of backlog items.
    And I know “old-style” customers who started out with a big requirements study, and then later appreciated that we were still agile and flexible enough to accommodate for changes to the requirements.

  • http://blog.brodzinski.com Pawel Brodzinski

    Of course you’re right – you don’t have to change completely the way you work. Usually it’s enough to create some kind of proxy between your team and customer. Sometimes effort needed to maintain that proxy will be very high.
    There’s one more thing – in all agile methodologies one of the most important elements is client’s iteraction. Unless people on other side want to participate in what you’re developing for them you lose much value from agile approach.
    Sure, you should do a piece of very good job with iterative approach but with no feedback from client you’ll end up implementing detailed list of requirements stated on the very beginning of the project.
    Don’t misunderstand me. I don’t try to evangelise against agile. I can see what added value can be brought with agile and when can happen. Yet I’m far from treating agile as an answer for every question.
    If my team worked with scrum and I happened to get a contract with old-style customer I’d keep the way people work.

  • Jim Doobie

    Hmm. You seem to be arguing against design, not for agile in fixed price. I want to see the arguments that show agile as positive in fixed price, not other approaches as negative. I could easily come up with four reasons against agile but would that prove that waterfall was best? No.
    I like “Yes sir, we understand that you had expected the contact form to include support for smileys, attachments and spell-checking. But the import of your product catalog over a 14.4k modem from the backside of the moon cost us more effort than we had expected. (And we’re still delivering according to the minimal specifications.)”. My biggest customer would sit back in his chair, fold his arms and say “Not my problem – you gave me a fixed price and never said it wouldn’t do that. It is essential to my business so get it implemented or you don’t get paid.” Where would that leave the me? Up s**t creek.
    In the end, my biggest customer would happily go to court over it and I would not have a leg to stand on because I don’t have a contract that helps me. Unless you expect a contract that says “Company X reserves the right to do as much as it thinks it should for the fixed price and then say that it has run out of money.”
    Let’s have another post that explains the positive aspects of the agile approach and that deals with these issues.

  • http://profile.typekey.com/jurgenappelo/ Jurgen Appelo

    @Jim: I think your reasoning is flawed.
    You said: “My biggest customer would sit back in his chair, fold his arms and say ‘Not my problem – you gave me a fixed price and never said it wouldn’t do that. It is essential to my business so get it implemented or you don’t get paid.’”
    Well, I would then sit back in my chair, fold my arms and tell him I never said it *would* do that. If it is essential to your business, you should have told us. But you didn’t. No lawyer, judge or jury in the world would agree that I am required to read your mind.
    This is precisely why I am arguing *for* agile. With detailed requirements (that are usually incorrect and bad) you always end up being screwed. High-level requirements strengthen your position with tough customers. Negotiation will cost you less than having to implement outdated detailed requirements.

  • Arturo Pina

    @Jurgen, I’m sorry but I think I agree with Jim. I think the single most important factor in a project is managing expectations and that’s different from “you should have told us”. It’s impossible to shoot a moving target. I agree that managing scope is key for fixed price contracts but how can you manage your scope if you don’t know what your scope is? High level requirements, cool, they sort of tell you what you’re not going to do, but then we come to the detail of how well are we going to implement some feature. And for that you need to get into detail. And if you just settled with high level requirements and they are not enough then it’s both you and your client’s fault, and you don’t want to fall into lawyer’s land even if you’re right.
    Having a happy customer is the other most important thing (but I guess it’s really the same as managing expectations).
    So, is there an (easy) answer? It is difficult. It is difficult to do that mapping between a fixed budget/scope and Agile.
    It all comes down to a matter of risk and how well are you able to assess the risk you’re getting in for committing to that ‘contract’ with your client.
    Is there space for Agile, yes if you have trusting clients who can prioritise and appreciate the cost of building software and who can understand trade-offs in functionality or schedule in order to meet a budget…
    Apologies I know I haven’t provided an answer but then I don’t have (a definitive) one…

  • Arturo Pina

    @Jurgen, I’m sorry but I think I agree with Jim. I think the single most important factor in a project is managing expectations and that’s different from “you should have told us”. It’s impossible to shoot a moving target. I agree that managing scope is key for fixed price contracts but how can you manage your scope if you don’t know what your scope is? High level requirements, cool, they sort of tell you what you’re not going to do, but then we come to the detail of how well are we going to implement some feature. And for that you need to get into detail. And if you just settled with high level requirements and they are not enough then it’s both you and your client’s fault, and you don’t want to fall into lawyer’s land even if you’re right.
    Having a happy customer is the other most important thing (but I guess it’s really the same as managing expectations).
    So, is there an (easy) answer? It is difficult. It is difficult to do that mapping between a fixed budget/scope and Agile.
    It all comes down to a matter of risk and how well are you able to assess the risk you’re getting in for committing to that ‘contract’ with your client.
    Is there space for Agile, yes if you have trusting clients who can prioritise and appreciate the cost of building software and who can understand trade-offs in functionality or schedule in order to meet a budget…
    Apologies I know I haven’t provided an answer but then I don’t have (a definitive) one…

  • Ryan

    @Jim (and Arturo): A few thoughts because I hear a few parts of these arguments so frequently.
    If the customer doesn’t understand agile development and work within it’s constraints, to a reasonable degree, of course things aren’t going to go well. That would be true for any development process. Linear development (e.g. waterfall) is the easiest to understand and I think that’s why people always try to fall back on it as a foundation of some fictional scenario.
    I also wouldn’t say that having a happy customer = managing expectations. Of course that’s the ideal, but a key to managing customer expectations is often giving bad news to or being open and honest. If you’re collecting data (which you better be!) it’s hard to argue with a velocity. If the customer doesn’t like how long it will take to get a feature with a certain level of quality, well, let it go. It’s not worth fighting a customer that you can’t work well with. I think Arturo does get close to an answer–the clients must be educated about agile and you have to have a close working relationship. But, those are some tenants of agile, so it should come as no surprise.
    Finally, I would emphasize that understanding the quality attributes needed in a product up front is crucial. If the software needs sat comm. from the moon, that better be exposed up front and worked in at the architecture level. Understanding those “architectural drivers” must still be done, but doesn’t *necessarily* require documenting every little detail you can imagine before you implement anything, because unless you’ve done it before a good piece of it will likely be wrong.

  • Ryan

    Hmm… just saw that this post is really really old. Google Reader FAIL.