Part 1

Ever wonder why IT service providers shy away from Fixed price Agile projects ?

For people who have been delivering software application development services the traditional way, when clients ask for Agile delivery as Fixed-price (same as Fixed bid), its a total nightmare, that’s why !

Life used to be much simple. The clients knew what they wanted.. The technologies used to last for few years at least.. the designs were more predictable (did we even have many design and technology choices ?).. the requirements used to be less volatile.. so why should you not take up Fixed price projects 10 years ago ? yes, of course we did.. we took our requirements, broke them into WBS, estimated them, priced them, and we delivered too ! clients were reasonably happy, suppliers made reasonable profits.. it was a happier time…

Now, here comes “Agile” ! The villain !

Everybody loves agile ! The clients love it, they can touch and feel the product in making.. nobody is putting a gun on their head to write down all the requirements for the next 5 years, they can change their mind today, tomorrow and day after, hey, which client would not love agile ??

And the supplier, hmmm.. its another story ! You want the project, you dread agile fixed-price (never done it before, or done it and swore never to do it again ! ) Thinking : If you want agile fixed-price, give me all your requirements so that I can lock the scope! Doesn’t sound very agile-like does it ?

Now why do we have this absurd situation ?

We are all familiar with the iron triangle, triple constraints or any other name we want to call it.

Traditionally, we write down all the scope, estimate the effort it would take to build it and translate it to estimated time and the cost. Voila ! You are ready to enter into your fixed-price contract.

In agile, we get stuck in the very first step. You simply dont have all the detailed requirements (well, most of the time, anyway). But your client most probably have a budget in mind and a timeline in mind as to when they want something coming out. Which means, you start with your time and cost fixed, and see what you can produce (scope) within that. i.e, you try to give as much business value within the constraints of time and cost set by your client.

In the traditional scenario, the supplier can arrive at a price keeping in mind the stable requirement, and through a change management process, get paid for any additional scope delivered.

In the agile scenario, the supplier has to agree on a fixed price ‘and’ a changing scope. And here arises the inherent conflict in Agile fixed price scenario :

“To be able to fix the price, you need all the requirements. If you need all the requirements upfront, you are not being very agile, are you?”

To be continued in part 2 ( different scenarios, types of agile fixed price contracts, how to structure fixed price agile contracts….terms and conditions… creating win-win for the client and the supplier…)

Those who are impatient to wait while I put it together, can contact me directly 🙂