Unofficially there are no such things as fixed priced projects in the software industry.
Of course, officially this term is still used, but lets face it these are no good to the customer or vendor. Why? Because if the project is completed early then the vendor may just work slower to ensure the completion is as close to the deadline as possible (so their next quote for a similar project can be justified) or, more likely, unexpected issues will occur causing the project to overrun in time or money or even be scrapped completely.
So what happens when the PMO declares that the project cannot be approved financially with an analysis of all the requirements and costing performed up front (i.e. a fixed price contact)?
I attended the first Phoenix Scrum User Group last night, where Ken Schwaber was presenting remotely and was given this very scenario. He gave some interesting facts that I believe should be used to educate the financial folks to understand that this is the wrong way to look at project costing. Here are some numbers:
35% of requirements change on a project (on average)
50% of features initially scoped are never or rarely used.
82% of projects fail (this is from the 2002 NIST report where failure is deemed as late, scrapped or not all features implemented that were originally scoped).
Using an Agile framework such as Scrum, the customer can see that that backlog is broken down into many tasks which are planned in more detail the closer they are to be implemented. I.e. For the next month here are the details of what we are going to do, how we are going to achieve it and with priorities.
For the work we are going to do in future months, here is a general overview which will become more detailed as we start the iteration of work for that particular set of requirements in the backlog.
Apart from a significant increase in risk management (on both sides), this gives the customer multiple chances to change any future requirements (as we know will happen). However, they are NOT allowed to change anything on the current iteration.
If some work in the current iteration needs to be changed later, we can add this to the backlog.
If work performed in the current iteration, for some extraordinary reason must be changed completely, then the most we have lost is up to one-months work.
Compare this to a project where all the requirement are set up front and six months later the customer receives a deliverable way off the current needs, are they going to be happy?
If the customer still insists that all requirements are expected up front and priced then insist on a contract where no requirements will change. This is far from ideal and a review the customer may come around to a more appropriate way of thinking. If they still persist and are not willing to sign this type of a contract, you are probably best to walk away. Look at the stats!
Recent Comments