Public Bid Fixed-Price Contracts and Agile

21 August 2013

Yaser Marey
Microtech


In public bids, you need to commit to fixed time, scope, and cost. This commitment, at its best at this stage, is a mere guess! A guess that wouldn’t stand long as change floods the project once it starts.

So, to mitigate the risk, we either pad our estimates generously, anticipating the coming change, or we bid low and count on starting the project with an extensive analysis phase. From analysis, we produce a thick document we call the SRS (or Software Requirements Specifications) and we insist that the customer sign it before we move on to the next phase.

The result is that we squander a lot of time and effort in the analysis, signing the requirements specifications becomes an epic of meticulous document review, the resulting document is still full of holes and inconsistencies, and the customer will later request a change and heated debates will cause friction and undermine trust among all parties.

This usually ends in one of three scenarios:
  1. We force the customer to drop the change request, so we end up delivering something less desirable to the customer, which means that the customer will think twice before giving us further business.
  2. We tell the customer, “We will do it, but we do it only as a favor for you, Customer,” and usually quality will suffer greatly as we try to shortcut the effort to preserve our financial condition.
  3. We force the customer to pay for the change request, and the customer becomes unhappy and feels cheated.
It is a lose-lose situation -- very clear!

My advice is that unless you have a degree of freedom in adjusting one of the project constraints, then don’t do it! It is a death march!

But if you have to take this project for any reason, then Agile can help, for the following reasons:
  1. Agile gives the advantage of delivering valuable software early, while in classical Waterfall we may hit the deadline without having any usable software produced. And even if we didn’t cover the whole agreed-upon scope, there is a better chance that you will have a happier customer, because with Agile methods you develop the most valuable features first.
  2. Agile helps us mitigate the fixed-price contract risk because it makes you fail fast; it simply gives us a better chance to reduce our losses if we have to lose.
  3. It helps us gain the customer's trust by using tools such as sprint review meetings and demos to negotiate the scope every step of the way, also using information radiators and making project progress visible.
  4. Agile also engages the customer in the development process, which encourages the customer to share the responsibility of meeting the project constraints. For example, the customer might decide to remove some of the project scope in favor of meeting a specific deadline.
So, yes, by all means do fixed-price projects in an Agile way. You will have a better chance of meeting the project constraints and have a happy customer, which means more business. You will also know early if you can’t do it, and you can withdraw before you lose too much!


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 1 (1 ratings)

Comments

Glen Wang, CSM, 8/21/2013 1:16:22 AM
An organization should build its own strategy to buffer changes.
Yaser Marey, CSM, 8/21/2013 6:16:08 PM
I agree with you Glen and what I am suggesting here is to use Agile as part of this strategy for fixed price contracts despite the fact that Agile methods require either scope or cost to be variable.
Amol Patki, CSM, 8/22/2013 1:31:49 AM
With fixed time, scope , cost, it even become tough to deliver in agile way. Essence of agile is to welcome change not to avoid it and in this case business prioritization and feature estimation along with client collaoration and partnership becomes extreamly important.
Sameer Chudaman Patil, CSP,CSM,CSPO, 8/22/2013 2:39:01 AM
You can still do fix prose project with Agile but Contract with heavy penalty should not follow agile.
If customer recommend to use agile then I am sure he will be able to negotiate during sprint planning, prioritizing and he may give us freedom in adjusting one of the project constraints.
As Amol said there project where there is strong involvement form customer or recommendation to use agile should take agile approach
Yaser Marey, CSM, 8/22/2013 2:25:07 PM
Amol and Sameer, I still think that even in the case when your contract is fixed scope and cost, I say you still can benefit from the incremental iterative delivery and close collaboration with the customer that is encouraged by Agile methods.
Also, in the process your customer will learn about Agile methods and possibly gradually transform to Agile contracts in the coming projects.
Patrick McGovern, CSM, 9/24/2013 6:31:33 AM
This is a really interesting topic to me and one that is rarely, if ever, addressed in the Scrum literature so thanks for raising it. I struggle with this on a daily basis and have not found a good workaround. The key issue is one of getting paid. Companies typically structure a deal with payment milestones and deliverables and those must be met on time if the company is to get paid. The key, I believe, lies in ensuring that the requirements are kept at a high enough level to allow for iterative understanding but low level enough to be meaningful.

You must Login or Signup to comment.