How Fixed Bid Projects Work in the Agile World

Story time: Once upon a time, in a far far away land, a new project contract was signed. Congratulations! Mr. Client (a huge enterprise) agrees to pay the project team such and such gold coins for building a world class, enterprise level software solution. The big scope items were outlined in the statement of work was signed and a FIXED PRICE has been agreed on. The team, all agile experts, started diving into the requirements and begun building the product backlog.

A short time goes by, the backlog of work items become clearer and clearer and our team realizes that there is no way that they can deliver all the scope within the fixed budget – BIG PROBLEM!

The team’s illustrious PROJECT MANAGER, known for his excellent consulting and negotiation skills, carefully plans how to communicate this to the client. He is so good in executing his plan that he succeeds in the impossible: The client reviews the priorities and agrees to reduce the scope so it can fit the new estimates – Only the important items that bring real business value will be built.

The team’s ARCHITECT, designs a wonderful solution and is diligent about all QUALITY MATTERS; he has a ZERO TECHNICAL DEBT policy. We do things right! In this team is his mantra.

And so construction ensues… At the beginning the pace is slow… causing leadership to lose a few heartbeats. As the time goes by, the advantages of the sound technical foundation and the ZERO TECHNICAL DEBT approach begin to emerge and the team picks up speed with every iteration that goes by.

The speed acceleration is so impressive that after a while, the esteemed project manager, offers the client stakeholders to add a few items that were removed from the original scope. The client is thrilled, but by now, they’ve had some more time think about their priorities and realized that what was removed, isn’t really needed! There are new ideas that the product owners have that seem like a good fit.

</Story Ends>

Are Fixed-Priced Contracts and Reduced Risk a Myth?

Statistics and software development studies suggest that many projects fail or are perceived as failures by different stakeholders for many possible reasons:

  1. Overspending and exceeded budget
  2. Missed schedules and deadlines
  3. Scope issues – not everything was developed
  4. Quality issues
  5. Real business value wasn’t obtained
  6. Low user acceptance and adoption

What do humans do in the face of risk? Buy assurances… and in the world of information technology and software development, these usually come in the form of fixed-bid contracts.

Review my story again and you may realize that it have gone bad in multiple ways:

  1. The client could have not agreed to change the focus or priorities and the scope would be more than what could be built with the same budget/schedule/resources – TEAM LOSES
  2. The project manager could have chosen to not communicate that there is room for more scope – CLIENT LOSES

My experience leads me to conclude that YES, fixed priced contracts DO NOT REDUCE RISK in the real world; they just give clients the nice, fuzzy and warm feeling that they are going to get what they need for a known price.

In reality, if the scope is too great for the budget or time, it will not get delivered! At least not to the client’s satisfaction (quality might suffer, users will complain etc.)

At the end of the day… something has to give… and if you do not plan right, communicate effectively… bad things will happen… awkward conversations, hurt feeling and sometimes even legal issues are some of the things that you could expect.

  • Chris F Carroll

    Good point, well made and your short story neatly illustrates more points than you use it for.
    But customer *always* have a budget, since they are not infinitely rich. So some kind of fixed price or cap is always needed somehow?