Agile projects need agile contracts

Project contracting techniques, however, have historically been largely aligned with the waterfall model of delivery. This is focused on requirements being identified upfront to enable a fixed price to be agreed with a supplier for the design and delivery of a fixed scope.

Many organisations, even after adopting Agile for their project delivery, continue to contract with suppliers using a mindset, and contracting techniques, more suited to waterfall projects. The default becomes contracts for agile projects which are based on an open ended time and materials basis where the balance of power sits with the supplier. As work then overruns, the customer has no option but to continue to pay. To deal with this problem, organisations should instead be looking for contracts that bring the benefit of a fixed price without fixing the scope, that do not put them at a disadvantage from the outset, and do not cap the release of value they can achieve from suppliers.

If companies are going to get the best out of adopting Agile as their primary delivery mechanism, they need to ensure they have an approach to strategic contracting that will position them to build strong supplier relationships and support their Agile delivery.

There are a number of best practices that can help organisations when they are procuring for agile projects.

Recognise and understand your project conditions to contract effectively

The first step in determining the most appropriate commercial approach is to ask the questions that will ensure you understand the project conditions that you will be operating under. Are you working with a vendor who you have a strong transparent relationship with and who you trust will behave reasonably as requirements emerge and change? What level of changes in scope over the course of your project are you expecting? Are you and the vendor familiar and comfortable with the proposed architecture and technology set? These types of conditions will impact the type of commercial approach you adopt. For instance, a poor relationship with a vendor may indicate a greater level of upfront requirements specificity might be helpful; if you are working with a new technology set, you may endeavor to address uncertainty via prototyping in initial cycles prior to entering into a long term contract with a vendor.

Align customer and supplier motivations via your commercial approach

When considering which commercial approach to adopt, you need not only to take into account your project conditions but also the goals of agile contracting. These are to align customer and supplier motivation, to enable contracting based on a partnership model and risk sharing —and to fix the price without having to fix scope.

One approach is to make use of a two phase contract, which is an effective way of embedding flexibility. The first phase, a time and materials contract, is focused on de-risking and delivery of the most valuable functionality as well as confirming you have the right partner. It is also used to set a baseline for delivery velocity (the speed at which a team can deliver working software in each design-build-test cycle) and to agree the relative size of each piece of functionality. Each piece of significant functionality is called an Epic.

This approach then allows for the second phase of the project to be contracted for a fixed price, based on the size of all known Epics. Within this the customer can substitute new Epics into the contract as they emerge on a “one in, one out of a similar size basis,” with agreement from the supplier. This approach is supported by additional commercial techniques, such as fixed profit, that lowers the margin a supplier can apply if the work is extended by overruns. The key to success is continuous and transparent dialogue and a partnership approach between the customer and supplier.

One of the top five pharmaceutical companies in the industry used this approach with all its tier 1 suppliers, rewriting their lead contracts to reflect agile principles and embedding a partnership and Agile approach into their relationships. This meant they were better able to align both their and their suppliers’ motivation, to address risk and deliver value early in projects and to maintain flexibility in their project scope.

Design for exit

Each programme will benefit from specific commercial arrangement with suppliers to reflect project conditions, but all will benefit from intentionally designing for exit rather than leaving it to chance. Designing for exit helps in two ways: by making exit easier if required; and, by making a threat of exit more realistic. By doing this thinking up front, the problem of what to do with a system that is part live can be considered before too much risk is accumulated.

An example of what can go wrong if this doesn’t happen can be seen when a large retailer found itself facing huge delays and cost overruns with a second release of software which was key to their core business. It was clear that the next two releases faced similar issues but that ending of the contract would eliminate support for the partly live system, and ultimately did not allow for the engagement of another supplier.

Building in an approach to managing intellectual property ownership into the contract for partially live systems can allow an alternative supplier to take over development and operation of deployed systems. Along with a requirement for knowledge transfer from the old supplier to the new, will de-risk delivery and make exit from the contract more achievable if it is required.

It is clear that companies do not have to be constrained to a time and materials model when contracting for an agile project. This kind of contracting is different but the benefits of aligning motivations and fixing price can be achieved by making use of agile principles and embedding these into contracts.