I am taking a Stand: Fixed-Price, Fixed Scope

I have come to a conclusion: I do not want to be on any more fixed price, fixed scope projects. From what I hear, that is all the projects the consulting business is getting today — if that is the case, I will have to find something else to do.

The main reason I take this stance is simple: To me, seeing the value of my work in the real world is the only real measure of accomplishment. And I believe fixed-price, fixed-scope projects always have a very poor ROI.

The detailed argument is too long to get into, and better minds than mine have already extolled them (Kent Beck, Mary Poppendieck). I will restrict myself to partially sum up my position:

  • 65% of delivered software features is seldom or never used. Being forced to decide the scope up front will force the customer to include in scope much more than what an adaptive scope would require. This will only make the situation worse. (Source: Standish Group’s CHAOS 2002 report)
  • In a marked where providers are in cut-throat competition, the result will be that the providers will be forced to be more and more reckless. This increases the risk for late, insufficient, poor quality, excessive changes, and failure to deliver. All these risks are carried by the customer. Some people refer this as a competition to see who can lean the furthest out of the winding (while holding on to the customer)
  • Fixed-price, fixed-scope tend to have drawn out deliveries. This means that the supplier will interpret the real user needs more than with an iterative process. This is probably an important factor in the number of software projects that are delivered according to specification, yet do not fullfil the real need of the system. In addition, drawn-out deliveries postpones ROI (See Poppendieck’s work)
  • Fixed-price, fixed-scope treats software delivery like procurement of commodities, something it is definately not.
  • Specifications are inherently vague, incomplete, open for interpretation, and often wrong. Competing on a specification is more a question of who can hide the largest part of the project in change requests down the road. (A secondhand comment from a big Norwegian hospital project: “If we ask for 9 billion NOK, they will not approve the project. We’ll ask for 6 billion and just blow our budgets”)
  • Fixed-price, fixed-scope projects create a adversary relationship between the customer and provider. This hinders the task of creating the best ROI. (I have heard the contracts referred to as “ping-pong” contracts: Send the ball back to the other party until someone lose)

In conclusion: I believe it is professionally irresponsible to deliver projects in this way. If you ask what I propose instead: Some variation of fixed-price, variable scope, highly iterative process. But that is a whole other argument

As an example: When the Norwegian tax authorities had to cut the contract with their provider for their “SKARP” project, the project had already incurred on the provider a cost of 250 Million kroner (about $30 million). Even if the tax authorities did not have to pay for this work, the project was cancelled after (I believe) two years. This mean that no matter what way you look at it, the SKARP project is delayed 2 years. I am hoping that if my government projects, say $50 million on a project, they are hoping for a return of, say $100 million over 10 years life time. This means that the project must be worth $10 million per year. This means that either the project has an insanely stupid ROI, or they have just lost $20 million due to lost opportunities. I think this is grossly negligent.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Software Development. Bookmark the permalink.