Posts Tagged ‘Agile Project FixPrice’

It happened again. Big Bank and fix price screwed up a project. Luckily, it wasn’t an important one. A friend and I offered to extend a small web portal with additional features. Those features are deemed to facilitate the growth of the business. All the pre work was done by my friend; he met with the stake holders wrote down their requirements demoed a short what-if scenario. They liked it and so I was involved and we started to break down the work. As it is common, it was a big-bang fix price offer. During analysis we bumped into some questions which we could not verify as we had no customer access. Anyway, between Christmas and New Year we compiled an offer which was realistic for us and in our opinion fairly priced. We added some padding to mitigate our risks in areas where we had to rely on assumptions more then we did like.

We were turned down. Too expensive!

No surprise from my side. We didn’t follow rule 1 in fix price offerings. Low ball as much as you can, even loose some money on the project, cash in for any change after the contract is signed. With cash in I mean CASH IN, asking for big bucks.
Here my alternative scenario about how this could have played out.

Rewind 4 weeks and let’s start again.

According to a Standish Group research only 7% of features are used regularly. Another 13% often. The remaining 80% are either barely or never used. This is the Pareto principle par excellence. This rule states that 80% of the value comes from 20% effort. Find those 20% and your customers are 80% happy. Doing that you eliminate 80% of investment: time, resources, pay etc. This can be a huge cost saving for the price of some minor features you most likely won’t miss anyway. But, those 20% are not lying around waiting to be picked up, you have to dig for them. Even, if you think you found them you might have fools gold in your hands.

Transparency, Inspection and Adaption

Those three words are at the core of Agile development. Those three words allow a project to pay attention to the empirical nature of software projects and pick up the gold nuggets.
With transparency you make sure, that all artefacts and their value are visible early on. Customers can look at the application, play around with it and learn. This inspection creates valuable knowledge about the state of the project. For this to work, we need it continuously and on an ongoing basis. This is why Agile works in short iterations in which full functional product increments are being developed. In each of those iterations we adapt the product plan according to our findings. This way we get the best possible product in the shortest possible time frame. Also, once the customer is happy you can stop the project after each iteration.

In our case, we could have started of with the most important feature. Develop it in one or two sprints and just get paid for those. The customer decides whether to continue or if this is good enough. Rinse and Repeat.
Doing it this way, we would have been able to identify those 20% providing 80% value in less then 50% of the original estimated effort. The customer and we would have been happy! Instead, he now looks for a cheaper implementation for his big-bang problem.

The future is lean agile!

Read Full Post »