Fixed Price Projects and Agile, or The Scariest Nightmare

Fixed price contract is by itself the greatest nightmare in the project manager’s life. But when it is combined with agile development frameworks – scrum/kanban/etc – it becomes also a tricky nightmare.

Usually, when clients ask you for “fix price” they mean: fixed money, fixed scope, fixed time. Some of the most reasonable clients I worked with on fixed price projects told me “We are not crazy! Let’s not fix the time! But we should be live till the 1st of June, we have this marketing campaign, you know…”

Even if you work in the “so agile” software development company there is the day when the sales manager comes to you and says: “Hi! We have a new project. I have a bad and a good news for you. The bad one is that it is fixed price, I know how you hate it. But the great one is that you can still your agile, client is ok with it”. So, let’s discuss what you, as PM, can do in this situation.

Rescue plan

1) Find out what type of fixed price sales manager is talking about:

Fixed scope, variable price – Yeee! You are on the safe side. This works well with your agile mindset – you just have to go through the iterations, no matter what the price is – just ship it! Asap) Personally, I never worked with such contracts.

Fixed price, variable scope – You can still survive. The most issues you’ll have with managing the backlog – prioritizing it by business value, making sure you are moving towards the working product in the end, when the budget is over. That will require you to spend additional time on the often revisions of the all backlog (even the distant epics) and restorations to adjust prognosis.

Fixed price and fixed scope – The toughest one. They fixed everything! But you need something to vary to fulfil the terms. The only thing left is quality. So you’ll have to vary the quality of the product. How is that for your agile mindset? I think, you are a bit disappointed.

2) Understand, what is your biggest problem.

With fixed price your biggest problem is the fixed scope. Because it defines what exactly should be built. It defines it in the beginning of the project. When no one is aware of what should be build. And there is no room of changes, as we all pretend that we know everything about the product that we are going to build and won’t learn while we progress with the development.

That is the main conflict with your agile mindset and all the infrastructure you created for it – fixed scope.

3) Do some magic.

Ok, so you got this fixed price, you know you main enemy and now it’s the time to act. I promise you that following the next 10 steps you can magically turn the fixed scope to fixed budget in the client’s mind.

Here are the 9 steps:

Step 1 Explain customer how you are going to work and why are you going to work this way. They should understand that you are on their side. That you don’t want to release just one more not working software peace. Tell the client what are the user stories, story points, definition of done, iterations.

Step 2 Gather User stories. 1-2 weeks, several sessions with the client. Remember not to go into much details, collect “just enough” information. Create definition of done for each story. That will set the expectations on the quality (al least the basic ones). People, who are going to estimate the user stories should be present!
(Remember, that this time we have to go through all the user stories, do not leave the not detailed “epics” and user stories, which have no enough information.)

Step 3 Estimate. I assume you know how to do that. Just use your usual technique. So you’ll get as the result N of points for the backlog.

Step 4 Define the magic number – team’s velocity prediction. That is the only number you’ll have to predict in this flow. What you can use to make the prediction more accurate: find out the velocity of the teams in the relevant project, velocity of the team which took part in the estimation, discuss the prediction with the team. Also do not forget to count the environment – how easy is the communication with the client, are there any difficulties with the testing, content, design, etc.

Step 5 Check if the estimated budget fits the one from the contract. The formula is very difficult, but I am sure PM can cope with it:

Budget = round(Number of points/Estimated velocity)*Hours per iteration*Hourly rate

Define how different is the estimated budget from the one in the contract. I bet it is much higher. If it is less than 50% higher you are still on the safe side. Just follow me.

Step 6 Remember I asked you not to add too many details to the user stories? That will save your ass now! As this is the “variable scope” you have. I don’t even speak about the “quality” that you can vary, I mean the complexity of the feature. You can easily(ok, that will require some effort) make the feature in the “easy” or “difficult” version.
Let me explain: Here is the example of the different “difficulty” for one feature – “Push notifications”.  “Difficult” 5 times more work than “Simple”.

So always try to get closer to the “simpler” version (also think about the user of the product).

Step 7 Track the project progress and budget. You always have to see these numbers. Make the decisions on the basis of how far is the “actual” progress from the “ideal” line:

You can see I am showing you not only the happy cases 🙂

Step 8 Implement the change management in frames of the fixed budget. Use the budget points defined to replace the stories one by another and still be in budget. You’ll be able to do that when client starts trusting you and listening to your advice.

Step 9 Be careful with the illusion of control you have with the estimated backlog. The closer to the beginning of the project you are – the less you actually know about the risks. The things always go wrong.

These 9 easy steps will help you to survive with the fixed price project if you have the agile mindset ^_^