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.
In the previous blog entry I revisited “The Price is Right”. Today, we’ll have a look at “Do you want Agility with that?”
Qualifying Tip 1: Make sure you have a committed customer
Agile fixed price projects require greater effort and involvement from the customer. A hard release date is a good indicator of a motivated customer.
The customer will be more motivated, more willing to think about solutions if there’s the pressure of a hard deadline.
In retrospect: this is clearly insufficient. A hard business deadline, not some invented meaningless deadline, is one positive factor in many successful projects. It’s also present in many tales of deathmarches. Necessary but not sufficient. A limited budget is always useful too; beware of customers who have too much money (they do exist). During the sales, we must test the customer to see if they’re really committed to this project. Ensure that you get to talk to everyone who will be involved in the project. If they don’t have time to see you during the sales process, they won’t have time to help you during implementation. Ensure that their goals are aligned with the project’s goals.
Qualifying Tip 2: Make sure you get timely feedback
We need timely and regular feedback from the customer. We put those customer commitments in the contract.
Customer collaboration AND contract negotiation. The customer has responsibilities too and those belong in the contract. If we don’t get the feedback in time, we can’t run the project. I’ve stopped several projects because the customer didn’t honor those agreements. We either resolve the problem (the customer ensures they make some people available) or we stop the project altogether. Maybe we’ll restart the project at a time that’s more convenient for the customer. See Selling Tip 2: It works both ways.
In retrospect: it’s about more than feedback. We need to agree on the way we’ll collaborate.
Sales Tip 1: Many small projects are better than one big project
Success rates are higher for small projects than for large projects. We reduce the size of the scope to only include a minimal feature set. As a result, the customer pays less, gets value sooner and can postpone decisions. I reduce my risk, get a chance to prove myself with the customer and can test our relationship with a small investment. But don’t do projects of a few days only.
Small projects bring lots of advantages to customer and provider IF we can keep the startup and transaction costs of each project small. As an example, at one time we had a rule that no project could take longer than three months and that we had to deliver at least each month for customer acceptance. The smallest project (an extra feature in a product) took one week from customer request to delivery of the product CD. Many projects had weekly delivery for acceptance.
In retrospect: the advice still stands, but we deal with scope differently. Instead of creating lots of User Stories and selecting those that have high value, we start with the Business Value drivers and then derive the minimal set of User Stories that will deliver the value. Therefore, our scope is minimal and sufficient by construction, not by elimination.
Implementation Tip 1: Let the customer sort the requirements
User Stories are ordered by the customer and implemented, as much as possible, in that order so that the customer gets the high value stories sooner, can test sooner and reduces the risk of dropping high value features.
Implementing this way is good for the team: we’re working with value- and business-driven priorities, we have to make sure that the user stories are independent to give the customer the liberty to sort.
In retrospect: the advice still stands. If the stories have been derived from the Business Value drivers, we will already have this ordering.
As an aside: many agile teams get off to a wrong start when they talk about this to their customer:
Team: we need you to order the stories by value and we’ll implement them in that order.
Customer: why is that important? As long as you deliver the scope, in any order, I’m happy.
Team: well, if we mis-estimate and run out of time we’ll drop some of the lower value stories.
Customer: what? You plan to run out of time? And you‘ll drop my stories? Do you guys know what you’re doing?
Mitigating schedule risk is one of the minor advantages of implementing by value. It’s more about delivering value sooner, getting information sooner, keeping the customer involved and mitigating the risk of building the wrong thing.
Implementation Tip 2: Requirements as stories. Don’t sweat the details
The requirements for the project should be expressed as high level stories. These stories’ contents have some margin for negotiation. The specification becomes shorter and easier to understand. We put less effort in creating the specification and we can delay decisions. This only works if I have a pretty good understanding of the domain and the customer. I need a good working relationship with the customer to be sure that the details will get filled in just in time.
We install a pull analysis system to create detailed specs just in time. We usually make this visible by having one or more columns on the kanban board that show this activity, so that we can quickly see if the customer is keeping up with the team.
In retrospect: the advice still stands, but how do you make it actionable? The best way is to start from Business Value Drivers and then to describe real Business Requirements. The specification and the contract shouldn’t fix implementation, they should specify the business goals to be achieved and the capabilities that must be delivered to achieve the goals.
Implementation Tip 3: Exchange Requests
If the customer wants to add a new User Story, they must first remove a number of User Stories for at least the cost of the new User Story. That’s the way we keep budget and timing constant. That’s the way we keep the price fixed.
Change Requests are evil. When we run a project (not only fixed price ones), we’re very strict on Change Control. Nothing gets changed in the scope unless we know there will be no negative effects. I don’t like change.
In retrospect: advice still stands. It’s simple, but very effective. A well-run project with Exchange Requests has a fixed price, fixed deadline and a minimum guaranteed value. The customer gets more value than expected, because they exchange high value new stories for lower value stories.
Implementation Tip 4: Put dropped requirements in a follow-up project
The User Stories that get dropped because of an Exchange Request are probably still useful (or they wouldn’t have been in scope in the first place). Never extend the current project, but define a follow-up project for these lower-value stories.
Fixed price, fixed deadline. The customer gets the system on the requested date. Qualifying Tip 1 means that the customer can’t afford to miss the deadline. If they want more, we’re more than happy to do another project.
In retrospect: the advice still stands. Moving deadlines reduce the value of the solution and demoralise the customer and the development team.
Implementation Tip 5: Let the customer use the software before the follow-up project
Let the customer use the delivered system for a while before starting the next project. The customer will learn a lot and come up with better ideas for the next project.
The best feedback comes from production use. Let the customer put the solution in production and start earning value. By the time we start the next project, the customer has more information and more money.
The problem is that we delay our income. I consider this a sound investment in a collaboration that’s valuable for both parties.
In retrospect: the advice still stands.
Implementation Tip 6: I’m the onsite customer
Not every customer can afford to have a full-time onsite customer in the team. In those cases, I as business analyst-project manager, can play the proxy customer role. This requires that the proxy customer knows a lot about the domain and that they know what they don’t know. Then we need to consult with the real customer.
Projects with a real onsite customer go measurably faster. Projects with a proxy customer are slower, but still faster than those with an off-site customer. We do need to be sure that we can get enough access to the real customers when we need it. That’s why we’ve agreed from the start how we’ll communicate and collaborate (see Qualifying Tip 2).
In retrospect: try to get a real onsite customer first. It may seem impossible, but if the project is value-driven you may be able to convince the customer. For example: “with an onsite customer avalailable N days, we can deliver the project one month earlier, which will bring an extra revenue of X“. If X is substantially more than the cost of N days, the customer would be stupid not to have an onsite customer.
Implementation Tip 7: Frequent releases, incremental delivery
Release frequenly for acceptance testing (for example once a week) and divide the project in one month increments that deliver a coherent set of functionality. The customer might discover that these increments are good enough to be used and will ask for incremental delivery.
The team and the customer need to learn to deal with regular releases. See how fast you can go today and decrease the “takt time” gradually.
In retrospect: the advice still stands. Unfortunately, I see more and more companies and team that go backwards, delivering fewer releases per year and increasing their cycle time. This leads to a vicious cycle, as releases get more complex and error-prone. Agile requires technical and operational excellence, otherwise frequent releases can’t be sustained.
Implementation Tip 8: Looking back to learn
Take time to look back and learn in a retrospective. Review actuals versus estimates to provide the basis for future estimates. Preserve new knowledge about risks and how to deal with them.
It may sound self-evident that you’d do this, but I’ve seen very few companies that learned from projects. In many cases there are retrospectives, but no actions or no time (or courage) to tackle root causes. Many projects feel like Groundhog Day: an endless rerun of the same mistakes with no hope of escaping. An ominous voice in my head keeps repeating “It is happening again. It is happening again.”
In retrospect: sound advice, but how do you make it actionable? Make sure that you find and tackle root causes using, for example, Systems Thinking techniques. Make sure that actions are defined and performed. Keep track of real project measurements, especially actual cost and time versus estimate.
And the score is…
Most of the advice still stands but the implementation should be described better to make it actionable.
We have changed the way we do analysis: instead of discovering the scope and estimating value, we define value and derive the scope from that. This value-driven approach brings several benefits:
- The scope is minimal and sufficient by design, so we spend less time on it
- The project is value-driven, which make prioritising and assigning an onsite customer easier
- We negotiate about value first, cost second. Customers have no problem paying if they’re convinced of the value.
I’ve learned that the techniques from the two articles need to be taken together. It’s not “Do you want Agility with that?”, but “You need Agility with that”.
There are some more tips I’ve collected over the years. We’ll look at them in the next entry.
