There is a question that is asked many times during our Introduction to Agile course, usually about half way through when the potential of these techniques has become clear but the practicalities of applying them have begun to raise doubts. The same question is asked by people who award contracts to software vendors, and by people working for the vendors themselves. “How can you adapt agile methods to work with our fixed price contracts?”
Fixed price, fixed scope contracts seem like a great idea if you have an idea for a new product and you want to limit your exposure to escalating costs. By inviting competing vendors to tender for a defined level of scope, you achieve the holy grail of project management: fixing time, scope and budget at the beginning. Life is good after the contract has been signed; just sit back, and wait for the valuable working software to come rolling in.
Agile ways of working appear to threaten this utopia. Common to all agile methods is the understanding that
- There is uncertainty at the beginning.
- We will learn how to build it as we go along.
- We will refine what we want as we see early versions.
This raises problems when you try to determine exactly what will be built before you start the work.
As customers, by fixing what we want at the start we benefit from transferring all of the uncertainty to the vendor, but agile techniques emphasise changing the scope based on what we have learned. Few vendors will agree to a fixed price if we ask for the provision to change our minds, and change requests are often expensive.
As vendors, we like having large fixed price contracts on the books so that we won’t suddenly have a team of developers with nothing to develop, but working in an agile way gives us the tools to terminate development early or change the scope significantly as we factor in knowledge learned.
I have been unlucky with fixed price contracts. A few years ago I was working for a large company who had spent a year analysing requirements for a new product and inviting tenders from all of the big players. I joined the team just as we were sitting back and waiting for delivery, but unthinkably things started to go wrong. Early in development, it became clear that the performance levels set a year ago could not be met by the architecture that had been chosen. Contracts were examined, penalty clauses were exercised, and collaboration ceased until we redrew the contract at great expense. The problem was that by the time the issue had been discovered, the large inventory of requirements, analysis and design made change very difficult, both technically and commercially.
Some time later I took a role with a vendor who had just landed a contract to build a big new feature for a long-standing client. Looking forward to the freedom of 9 months of funding, I set about getting an agile team together to do great things for the client. The obstacles between valuable working software and our customer could not have been more effective if they were planned. Opportunities to learn from progress went unreported, transparency on work being carried out was politicised, and reported defects were assessed through the lens of functional and technical definition documents. The commercial interests established by the contract were a direct inhibitor to collaboration.
I have arrived at the opinion that the alignment of opportunity benefit with development risk is a key feature in the development of relevant and valuable product. Separating the responsibility for these two areas raises the possibility of driving sup-optimal behaviours on both sides. This applies to internal teams and is amplified in the case of separate commercial interests with a client-vendor relationships. Why? Because collaboration between those building the product and those paying for it is key. Collaboration thrives in an environment of trust and may be inhibited by commercial pressures not directly aligned with business value.
If I had a great idea for a product but did not have an in house team, I would want to build a relationship with a trustworthy vendor and keep hold of the risk myself. Rather than award a large up-front contract I would seek to allocate funding on a medium-term basis, rather than sell the uncertainty of development costs for a 30% fixed price buffer. I’d retain the ability to influence development at regular intervals without the vendor worrying about cost changes. Initially I might only want to pay for 2-4 weeks funding, but as trust was built up I might buy 2-3 months of a team’s time up front on the basis that I could have direct influence on what they work on.
If I were on the vendor side, I would take pride in being able to meet my customer’s needs and being transparent about the technical challenges that emerge naturally during development. I would pay particular attention to clarifying the following key information at the beginning and then at regular intervals as development progressed:
- Budget – the current level of funding.
- Benefits – the desired outcomes upon exhausting the current budget.
- Constraints – the parameters within which we may operate.
- Timescales – desired dates and hard deadlines after which opportunities lose their value.
By establishing these factors at the beginning and maintaining a shared understanding as they change, we will be able to focus on collaborating towards shared business outcomes.
The move away from fixed price, fixed scope contracts may be a departure from your current business model but the benefits to both sides are great. By keeping the development risk and the opportunity benefits together, decisions are made in the best interests of the enterprise and avoid the potential for sub-optimal behaviours. The only thing standing in your way is trust, and to establish that you may have to make the first move.