Monthly Archives: July 2013

Fixed Price = Death March?

So there you are being asked to lead that agile fixed price project. Is it a death march project?

What will you do to find out if it’s worth doing the project or if you should avoid it?

Maybe it’s one of the following:

  • Scope – find out what exactly should be built and how much uncertainty and assumptions are in it
  • Risk – create a list of major risks, how they will affect the project and what you can do to mitigate the risks and if the estimated buffer is big enough for your list
  • Team – does the team that should deliver the project have enough domain knowledge, more important was the team involved in the estimation process and is the team the right one to do the job?
  • Customer – Do you have a dedicated customer representative that is there for your questions and who will do the demos with you ensuring that what you build during your sprint/iterations is what the customer wants? Will he also be there to continuously re-prioritize the backlog if needed?
  • Environment – Are all the technical (software/hardware/systems) and physical (desks, access) prerequisites met?
  • Definition of Done – Has a concrete list of deliverables and constraints been defined together with the customer to define what the product increments should include in the demo?
  • Dependencies –  are there any dependencies that you cannot influence and is your customer taking care of those?
  • Velocity – Do you already have empirical data of the team that should work on the project so you can validate scope vs estimation? 
  • Change – Is a change process defined together with the customer to avoid scope creep?
  • Ceremonies – is there a buffer for clarification of unclear specification? For additional meetings beyond your Pre-Planning, Planning, Demo and Retrospective? Are those even included?
After you checked these and everything is to your satisfaction, there are still some indicators that can help you on your way.
Project Burndown

If you have a burndown like that, you should act already in sprint 3-4 and talk with the customer about the budget vs. story point delivered trend. Whatever the reasons are when the money is out it’s too late to act.
Don’t allow Change Requests
  • The scope is as negotiated, if the customer wants one extra feature he has to remove another from the backlog, and he has to take into account that you have some extra work estimating the new feature and managing backlog etc. so he’ll probably loose some additional scope 
  • Always have a dotted line in your backlog that marks the “end of the line”, all items that are below that line won’t make it in the final package and should go in a follow-up project (if they are still needed)
  • Together with your customer focus on MVP don’t let that fancy additional functionality tempt you

Focus on long-term partnership with your customer
  • With a deadline ahead it’s easy to drop quality to get the feature done in time. This might help in the short-term but will damage your customer relationship in the long-term if problems arise
  • Don’t overburden your team. If you keep them running on 120-150% to finish that project what happens if you customer is so excited that he immediately wants to start the next project with you? Keep a steady pace in what you do, that helps motivation and quality
  • By being completely transparent and in constant interaction with your customer you’ll gain their trust and this will always pay out in the end
What are your experiences with fixed price projects?
Do you have ideas to add to that list?
What would be a total no-go for you?
I’m happy to hear your thoughts and learn more on this…