Fixed Price or Agile ?

16 Jun 2007 Fixed Price or Agile ?

Mark raised some very good points in his comment against my recent post on welcoming change in projects:

“One main barrier to these approaches being adopted in the past was the engagement/contract models that our clients dictated. If the project needs a fixed cost, you usually need a fixed set of requirements.”

So what to do ? Does this mean that an Agile approach can’t be used ?

Much of what makes up Agile development is simply sound development practices, but what specifically could we take from the Agile philosophy for use in a fixed price contract ?

Let’s look at a typical situation we encounter – responding to an RFP or other tender. The client has provided some overview of the goals, objectives and requirements, a target completion date and wants a fixed price quote.

1) Respond to the RFP in the best way that you can
You need to make (and document) assumptions, try and fill in the gaps, use your experience – anything you can do to improve your information. And you need to estimate the work. There are no silver bullets here, with Agile or anything else, you just have to do the best that you can. However, if you’re used to working Agile you’ll be used to identifying requirements and putting together good estimates fairly quickly – treat is just like a normal planning session (someone will have to pretend to be the customer !).

2) Plan to deliver business benefit early
This is core to an Agile approach in any case – “early and continuous delivery of valuable software” – but it also means that if something surfaces during the project that significantly affects your original estimates you’re in a better bargaining position. A client is much less likely to be concerned about a suggestion to drop some of the minor functionality if they can see a working solution that already implements their most important requirements.

3) Promote your Agile approach as a benefit as part of the proposal (and put your money where your mouth is)
The use of Agile processes is now widespread, almost mainstream, so is something that can add value to your proposal. Even if your client isn’t really aware of what Agile processes are all about tell them what you are offering – choice. The ability for them – the client – to have control over the process and end it at the end of the next iteration if they’re not happy. Or maybe even if they are – because they might by that stage have what they need to achieve the business benefits they are after.

4) Do the job better
In the worst case – even if the client is not interested in Agile processes or iterative development – you can still benefit from those processes as an external vendor / supplier. If your development processes are more efficient and more effective then you are going to be more competitive at proposal time, as well as more likely to deliver on time, on budget and to meet (or exceed) your client’s expectations.

As Mark also points out in his comment – things work better when you have “trusted partnering relationships where both parties are working for mutual benefit”. Or – as the Agile Manifesto puts it -“Customer collaboration over contract negotiation”.

The more you can demonstrate delivery of business value, the more you can develop trust. On the other hand, if you need to rely on the wording of a contract to protect your position then the project is already in trouble.