Agile Fixed Price Projects
In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:
- Qualifying: do I want to take this project on and if so, how?
- Selling: how do I get the contract in such a way that we can succeed?
- Implementing: now that we’ve got it, how do we make this project a success?
What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.
First, let’s re-read “The Price is Right“.
Qualifying Tip 1: Do I know what I’m doing?
I’ll only enter into a fixed-price contract if I can specify, estimate and plan the project as agreed, within a small tolerance.
I need to ask myself four questions:
- Am I familiar with the domain? If not, I’ll spend a lot of time learning and won’t be able to help the customer define what they really need.
- Am I familiar with the technology? If not, I’ll spend a lot of time dealing with stupid technology issues.
- Am I working with my usual team? If not, I’ll spend a lot of time building the team and I won’t be able to use velocity to estimate.
- Am I used to delivering projects of this size? I not, I’ll spend a lot of time scaling up my usual practices.
In retrospect: the advice still stands, not just for fixed-price projects.
Selling Tip 1: Don’t respond to RFPs, communicate
Don’t just respond to a written Request For Proposal but establish a real collaboration and communication with the customer.
We’re going to collaborate and communicate anyway, so let’s start now and see if it works before we’ve spend much time in this relationship.
In retrospect: the advice still stands. Some customers prefer not to communicate and keep providers at arm’s length. Do you really want to work with them? If so, plan on a large risk contingency.
Selling Tip 2: It works both ways
Ensure that the contract evenly distributes responsibilities and benefits between customer and provider. Make sure that the customer is committed to doing what you expect of them.
The most important goal of the sales process is to set up a working agreement between customer and provider than leads to success. Always “test” the customer: build in small commitments for the customer and see if they hold their part of the bargain.
In retrospect: the advice still stands. I won’t enter into an agreement that I think is unfair. I won’t start a project unless I have confidence that the customer will do what they’re responsible for. Too many projects go wrong because the customer agrees to do something and then doesn’t take up their responsibilities.
Selling Tip 3: Don’t underbid
Don’t quote a price below cost to win a contract with the intent of making it up later with extra costs.
No unfair contracts.
In retrospect: the advice still stands.
Selling Tip 4: Add enough slack to cover the risks
Do a risk assessment of the project. Add enough slack to the estimate to cover risk, estimation accuracy and (especially) the type of customer you’re working with.
How much slack needs to be added? That requires a lot of experience (see qualifying tip 1) and historical data. For example, what’s the fluctuation in velocity over the last few projects? How does this customer compare to previous customers?
In retrospect: the advice still stands, but I’d clarify that this is a “project buffer“, à la Critical Chain: the extra time does not get added to individual features, but is kept in a “global pot”. If things go better than expected, we add to the pot. If something goes less well than expected we take a bit from the pot. The state of the pot tells us if we’re on track.
Selling Tip 5: Real Business Requirements
Write the specification with the customer so that each feature is well-understood, adds business value and is testable.
We want to write a short, clear and actionable specification without technical detail and just enough functional detail to get started.
In retrospect: I didn’t emphasize this enough. We need to agree on Business Requirements, not System Requirements. What’s the difference? Business Requirements describe what the customer gets out of the project, the value that will be gained and the capabilities that are needed to achieve those goals. System Requirements describe how we will implement the capabilities. The customer doesn’t perform acceptance testing on implementations. The customer accepts when the capabilities deliver the expected value.
Implementation Tip 1: No Change Requests
Never allow Change Requests that increase the scope, cost or duration of a project.
Never. It’s a slippery slope: with each little change the project gets more out of control. I don’t like change.
In retrospect: the advice still stands, you should use “Exchange Requests” instead and only allow changes that are beneficial to the project.
Implementation Tip 2: Spend your slack wisely
Resist the temptation to “slack off” because there’s slack time left.
The project buffer should only be used when things go wrong. Avoid the temptation to “gold plate” features because there’s time left. The team should be energised and motivated to get their work done in time.
In retrospect: how do you implement this? Critical Chain recommends planning with “50% certainty” estimates, estimates that will be too short 50% of the time, to avoid Parkinsons Law. I recommend building a team that’s motivated to deliver quality and business value.
Implementation Tip 3: Simple, honest and correct tracking
Track progress using a simple burndown chart, but only count things that are DONE.
If you have a clear definition of done for every piece of work (and you can have definitions for each column on your kanban board), then you can simply record how much work is done versus how much work you expected to be done. For most projects, the expected amount of work done curve looks close enough to a zone around the diagonal from 100% to 0% done, so that a simple burndown chart, updated regularly, is enough to know where you are. Make sure that the information is visible and understandable to everyone involved.
In retrospect: the advice still stands. The important part is to be able to say that something is done. I’m very strict in this: I prefer seeing the burndown “flatline” because no story is done, than to see fake progress because something is “90% done”.
Implementation Tip 4: Manage your project
The job is not about specifying, estimating and planning perfectly. The job is about delivering what the customer needs.
Attack your risks or they will attack you.
Don’t shield the team. Help them to avoid and solve problems.
Good project managers don’t seem to do a lot and lead pretty uneventful lives.
Success comes from setting up the right project (qualifying) the right way (selling) and then doing all the daily work to keep it on track (implementing). It’s all about actively managing the project with a light touch.
In retrospect: the advice still stands, but to explain how you do this would require (at least) a whole book and lots of experience. Look for the project managers who have a reputation for “calm, quiet” projects that deliver and learn from them.
And the score is…
I still stand by what I wrote then, but I need to explain some of the tips in more detail.
I’ve learnt a lot more about writing contracts and discovering real business requirements.
I’ve also learnt that these tips aren’t enough to run a project, fixed-price or not. Agile (or professional) techniques aren’t an option, they’re necessary. Those are in the second part of the article.
Imagine this situation: the CIO of a large company decrees that from now “all applications we develop must be browser based“. This becomes a non-negotiable constraint for every new project.
