From The Blog

Chain Breaking

How Fixed-Price Contracts Fail Clients

Posted by Robert Dempsey on 10. Jun, 2010 in Articles

We’ve been talking with a potential client about a project, and this morning, he updated his estimate asking for a fixed-price contract. His...

Chain Breaking

We’ve been talking with a potential client about a project, and this morning, he updated his estimate asking for a fixed-price contract. His exact words were:

I also would like a quote that is based on delivering the site bug free vs time. I will not keep a clock, so all I need a system that does what’s in the doc for a locked price we agree on. I don’t want an open end agreement. Thanks.

A little background – we had written out initial user stories with some acceptance criteria, so more fleshing out of the requirements was needed. We did have an initial estimate in place based on the list of user stories and a few conversations and emails. In addition, I know for a fact that he had spent a lot of money on a software project previously, and ended up throwing out the result, hence his request for a fixed-price contract for a bug-free application.

After telling him that we don’t do fixed-price (in the traditional fixed price/scope sense – which he was asking for), I realized that more explanation was necessary. What follows is the email that I sent to him, with names removed for privacy.

Hi [NAME REMOVED],

I wanted to explain a bit more on why we don’t do fixed-price contracts. This is based on the experience that we and others have had with developing software applications.

When approaching a software project, people want to ensure a few things:

  1. They get the features that want
  2. The software is working as expected
  3. Their risk (i.e. the amount of money spent on the project) is a low as possible

In response to this, people typically want fixed-price contracts, especially when the numbers on the amount of failures of software projects are typically high.

Traditionally, the way this was handled was:

  1. There was a large up-front requirements gathering process that explicitly defines each requirement. This was either done for a fee by the company producing the software, or by the customer.
  2. The application was developed in it’s entirety and then delivered to the customer

There were one of few possible outcomes:

  1. The customer got exactly what he wanted
  2. The project was not completed on time due to unforeseen circumstances (people got sick, estimates were incorrect, etc.)
  3. The project was delivered on time but due to incorrect estimates and unforeseen circumstances, was either not fully functional or was full of bugs
  4. The customer got what he asked for, however it was no longer what he wanted or needed

Unless the first occurred, which was rare, the relationship between the customer and the software company soured.

This is where the method we employ – Agile – comes into play.

We are operating under a few assumptions:

  1. The customer has not explicitly defined the requirements up front
  2. The customer might and will most likely change his mind

To address the concerns of risk (spending more than expected) and getting the desired features, we develop incrementally, and bill a fixed-fee on a weekly basis. This does a few things for us:

  1. If any issues arise they appear sooner rather than later
  2. Our customers have the ability to update the requirements on a weekly basis, or completely stop the project
  3. As we have more information on the project, we can update our estimates accordingly, and as that is communicated to the customer, he can make a decision on how to proceed

To address the concern of the application working as expected (bug free and per-spec), we:

  1. Write user stories with acceptance criteria (listing the expected behavior of the application)
  2. Use a test driven approach (TDD) – we write the tests first to match the behavior outlined in the requirements, and then write the code

In our experience, this produces much better results for customers, and is why we do not do fixed-price contracts with fixed-scope.

—

Some additional thoughts.

What this comes down to is trust. For this customer, because he got screwed over before, he is trying to reduce his risk. As a business person I can understand this 100%. And it is for this exact reason that we do Agile development – so that neither he nor we get screwed again.

Transparency, communication, and continuous delivery rule, and in my experience is currently the best way I know to build trust with customers.

Other Posts That Might Interest You

  1. Why We Love Fixed-Price Contracts
  2. To Fix The Price Or Not To Fix The Price
  3. On requesting an estimate

Tags: 

  • http://topsy.com/blog.adsdevshop.com/2010/06/10/how-fixed-price-contracts-fail-clients/?utm_source=pingback&utm_campaign=L2 Tweets that mention How Fixed-Price Contracts Fail Clients — Topsy.com

    [...] This post was mentioned on Twitter by Mark Richman ♬, Sanjiv Augustine. Sanjiv Augustine said: Great post! RT @acts_as_conf: How Fixed-Price Contracts Fail Clients http://bit.ly/asNd2Y #agile [...]

  • Justin Blake

    Agile is the best way to avoid getting screwed over as a client. Continuous delivery, constant communication, and a continually running, transparent test/feature suite means you're never going to surprised by getting a big, buggy project that you wasted a ton of money on.

  • http://twitter.com/mrichman Mark Richman

    I think you are confusing two completely separate issues here…a billing methodology vs. a project management methodology. The arguments over hourly billing vs. fixed-price vs. value-based fees have nothing to do with agile vs. waterfall.

  • Justin Blake

    Mark, I don't think Rob is arguing against a specific billing methodology. The problem is approaching a project with the idea of a fixed price AND a fixed scope. Meaning the project will have exactly X and cost exactly $Y, no more and no less. No changes allowed. This is very much apposed to an agile way of approaching things, regardless of how the actual work is billed.

    Edit: Apologies for not taking full advantage of disqus and making this a direct reply…

  • http://twitter.com/mrichman Mark Richman

    Why aren't changes allowed? I'd simply respond with a new proposal. Yes, I realize I may be oversimplifying, but my point is that we, as IT professionals, are more often than not hired tactically, not strategically. There is far more value in strategy. The impact of changes at the tactical level are far more easily swallowed by *both* the client and consultant when the project is approached strategically. Who cares if the client wants a jQuery widget vs. a Flash thingamabob during iteration X when the strategic value of the project's outcome is so high that the profit differential to the consultant is so negligible?

  • Justin Blake

    My point is you shouldn't have to respond to change with an entirely new proposal. Change should be expected.

  • http://blog.adsdevshop.com/ Robert Dempsey

    Hi Mark,

    As I mentioned on Twitter, I purchased the Value-Based Fees book by Alan Weiss and will take a look as I'm very interested in this method. I would like to talk with you about your use of it. Do you have time later next week (week of the 14th) to speak with me? I'd prefer hearing practical application along with reading the book.

  • David Winch

    At the risk of merely repeating what's been said before, if between the contractor and the client you don't have enough information to specify a fixed scope that is acceptable to both parties, you need to spend more effort on information gathering. This may or may not be chargeable, but if it doesn't get finished within the first 1-2 hours free session, then it probably should be.

    The client can't expect to give the partially thought out problem to the contractor to take away and fix while they get on with something else, and the contractor mustn't allow them to. This is a recipe for scope creep!

    As the project will involve working together, the client has to understand they have several commitments to make to the project over and above the fee involved. One of these is their commitment to doing their tasks in a timely and diligent manner too. At some points the client, and not the contractor, will be on the critical path.

    Of course change requests may be made but the simple rule of fixed-price, fixed-scope projects is that if it's within the scope it gets done within the price. And if it's not, then you need to discuss a separate chargeable project. This project will also need prioritising alongside the current one as the contractor can't be working on two things at once for the client.

    Mark rightly points out that you have to differentiate between pricing and project management. All the above is to do with project management and the management of client expectations. For the fixed-price element, the solution must valuable to the client, so the price must represent a huge RoI to the client. At the same time, the price must represent a huge profit for the contractor. In this way, both sides win because their best interests are identical. If these checks aren't met you will have to re-visit the value, or the solution, or the price – probably in that order!

  • David Winch

    I don't think I'm saying rip up the original proposal. I mean the additional work will be a separate project, to be paid for separately, and to be undertaken either straight away while the current project is shelved, or at the end of the current project, or somewhere in between.

  • Justin Blake

    That is a one way of doing proposals and project management. But it is not agile.

    Requiring change requests that may be treated as separate projects doesn't make it impossible for the client to change their mind, but it makes it difficult, with lots of overhead. This is great for the developer, since they never have to worry about scope creep, but it is not great for the client.

    When I said change should be expected, I mean that change can and should happen continuously throughout a project. It's an ever-evolving beast so I do not want to force the client to try and determine all requirements upfront. We can work together to gather a high-level list of features and use that to create a rough estimate. Then we take it one iteration at a time, only hammering out the fine details of the features for that iteration.

    As we build the project, we're continually delivering, and the client is continually evaluating, updating the backlog, and re-prioritizing. The estimates are also continually updated as the backlog evolves.

  • http://blog.adsdevshop.com/2010/06/14/keep-your-external-backlog-to-a-minimum-for-business-agility/ Keep Your External Backlog To A Minimum For Business Agility

    [...] other day I wrote a blog post about how fixed-price contracts fail clients. The reactions to that post show that there are definitely people on both sides of the [...]

  • http://blog.adsdevshop.com/2010/07/14/to-fix-the-price-or-not-to-fix-the-price/ To Fix The Price Or Not To Fix The Price | Robert Dempsey

    [...] I stated that we loved fixed-price contracts, and then another from this year where I said that fixed-price contracts fail clients. His company is adopting a more agile method of development, and he was concerned that their [...]

blog comments powered by Disqus