This is one of those ‘tree falling in the woods’ philosophical conundrums which looks great on paper or at some party, but gets a bit out shape when you hit the real world.
To be the pedant – which I do so often – no object is immovable. Newton sorted that out – a = F/m. In short, an object will move if a force is applied. Small object needs a small force to get going, and the greater the force applied then the greater the acceleration. So a big object will move even if a small force is applied – it just won’t move very much. Likewise with ‘irresistible force’. Well, every object with mass has inertia, at least in this Universe so I guess what this boils down to is ‘huge amount of energy hitting something massive that isn’t going to move quickly.’
However, for this post I’m considering something a little more metaphorical; Fixed Fee contracts and Agile projects.
Most vendors don’t like fixed fee engagements as this means that the uncertainty that may risk an overrun can equate to reduced profitability or even loss on a project. Their preference is T&M – time and materials – so, if there is an overrun, the vendor will just keep billing for the hours worked.
Most clients don’t like T&M engagements for the exact same reasons. The thought process is that we’ve brought you in as the expert, so you should know this stuff. You should be able to generate an accurate number so if you get it wrong, you will carry the can.
In the Waterfall world, this wasn’t as much of an issue since you’re applying a known process for a mature and understood product.
However, once we start looking at complex projects that have a high level of uncertainty and almost guaranteed to change, then who carries the cost of the uncertainty? Clients and vendors point the finger at each other.
One route is to identify the key features of the new product and group them as:
- M – MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
- S – SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
- C – COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
- W – WON’T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.
This is the MoSCoW prioritization technique. From this, we can list the features in order from most to least important to begin planning. To get around uncertainty, a ‘feature buffer’ can be used. As Mike Cohn describes:
Creating a feature buffer is simple to do on an agile project. First, the customer selects all of the absolutely mandatory work. The estimates for that work are summed. This represents the minimum that can be released. The customer then selects another 25% to 40% more work, selecting toward the higher end of the range for projects with more uncertainty or less tolerance for schedule risk. The estimates for this work are added to the original estimate, resulting in a total estimate for the project.
(Taken from Agile Estimating and Planning).
The logic is simple enough; if we’re on target with our estimates you’ll get all of the ‘must haves’ and several ‘nice to have’ features (the 25% to 40% buffer). If we’re messed up and run over, then at least you’ll get the must have items. If we’ve overestimated then you’ll get the must have items, the buffer items, and a whole lot more.
Of course, assuming you get this agreed with the stakeholders, if a contract is involved then you’ll need to get it past their legal team.
This can often be painful if the legal department is not used to Agile projects and a good place to start at the Agile Contracts website and download the Agile Contracts Primer PDF. (This is based on the ‘contracts’ chapter from Practices for Scaling Lean & Agile” by Craig Larman and Bas Vodde.) The primer has advice on how to work with legal teams and suggestions for ensuring key points such as:
- Confirming that the structural and legal aspects of agile-project contracts are the same as for contracts of more traditional development styles and how to explain the key differences.
- That the legal team will need an understanding of agile and lean principles and systems thinking.
- Just as successful projects are ultimately born from from relationships based on collaboration, transparency, and trust, then ‘successful’ contracts contain mechanisms that support the building of collaboration, transparency, and trust.
One interesting feature is that there are no sample contracts. Although the Primer covers common topics of Agile Contracts, the feedback that the team had from lawyers was that cut-and-paste between contracts causes more trouble than it saves. So although it touches on subjects such as change management, payments, and such you will still need to sit down with the lawyers and work with them.
It isn’t an easy read, but it is valuable and should go some way to ending the fear of fixed price contracts for Agile projects.