What we're saying

Traditional contracts are doomed

I've been thinking for some time now that traditional "Supply of Goods" contracts make building a collaborative client/supplier relationship tough. The nature of the contract is to fix the requirements up front, agree delivery milestones and try to focus the team on delivering what has been defined up front.

Given that being able to handle change and being responsive to your customer's needs is the cornerstone of all agile and lean approaches to software development, how can a contract that actively discourages change help to build a long term relationship with your client?

This very issue came up recently at the Institute for Government. The current IT procurement process within Government is based on the supply of goods, which leads to a big up-front definition of the required product and doesn't engage the supplier in a collaborative process during the development of the product. This often results in projects that try to get it right first time. When this isn't achieved, the dreaded change control process kicks in and the post-delivery project costs soar while the supplier struggles to deliver what is needed.

During my presentation, I said that contracts needed to change to allow Government IT to be more dynamic and responsive. When asked how they should change, I simply said that the contract needs to be focused on purchasing a capability from the supplier to deliver the product, not for the supply of the product itself.

I was delighted this view was reinforced by Lawyer Susan Atkinson from Gallen Alliance, an Irish based legal company, who eloquently defined exactly what was wrong with traditional software contracts and why they introduce barriers to adopting agile processes. Rather than re-iterate her words, take a look at her article on flawed software contracts. I left feeling inspired.

See also

Agile Governance

Change Management

IndigoBlue's ADAPT and CONTROL governance framework

Comments

Good point here. "Contract needs to be focused on purchasing a capability." Very good.

And, by a capability, I mean a capacity to delivery requirements at a desired rate and quality.  Now defining those terms contractually is interesting!  Otherwise it is a license to print money for the supplier!

See also the related blog post: Many Contracts Have Wrong Focus

John,

Thank you for referencing me in your blog.

As you have commented, traditional contract models for the supply of goods or services are unsuited for projects based on agile and lean principles. The essence of a traditional contract is that the products/services are pre-defined, the customer tests whether they have received something that meets the description, and various contractual rights and obligations flow from this. Such an approach works well for commoditised goods and services which can be defined up front, and there will always be a place for the traditional contract models.

However, in product development (such as software development) and transformational solution delivery the project is essentially a problem-solving exercise to facilitate the creation of something new that, by definition, cannot be pre-defined.

So a different type contract model is required - a contract for the supply of capacity. The supplier is selling, and the customer is buying, a domain expertise and a level of rigour that is applied to the development of new products/services. In other words, the supplier commits to provide a quantified outcome. The focus of the contract is not on the detail or content of the outcome, but on the amount of the outcome and how that outcome will be delivered using a highly disciplined process.

I am currently working with some of the leaders in agile and lean on a white paper that will set out in more detail the contract model for projects based on agile and lean principles. If you would like to register your interest in this paper please contact me on satkinson@gallenalliance.com.

There is a related article on CIO.co.uk on the need for a more collaborative approach at the Request for Proposals stage rather than the very common formal definition of features approach.

Two of the key points made in the article are the need to:

  • Express the business objectives of the development (vision, strategy, objectives and what success should look like)
  • Build creativity and innovation into the relationship

I entirely agree that a more agile procurement model is required to complement the more agile contract model. By using a more agile approach it is possible to greatly reduce the time involved in the tender process and to assess the suitability of the shortlisted suppliers to work in an agile way. I attach a link to an article that outlines this more agile procurement model .

http://www.methodsandtools.com/archive/archive.php?id=84

This model is potentially fully compatible with the EU procurement laws which require public sector bodies to procure goods and services in an open and transparent way and to select the most economically advantageous tender using pre-defined and objective criteria.

One really telling phrase used in the link Susan Atkinson references above: Finding a Partner to Trust: The Agile RFP, by Peter Stevens is:

"As a customer, what are you really buying when you contract for software development? You may think you are getting a solution. But what you are really getting is an implementation team."

 

The July Second Wednesday Agile and Lean Management Breakfast Discussion is on this topic - see "Traditional IT Contracts are Doomed! Breakfast Discussion".

Absolutely.

Traditional contract and procurement models work on the basis that the customer is buying a defined product (the contract is a hybrid of a supply of services and products). But at the point at which the customer awards the contract to the supplier, the customer doesn't really know exactly what it wants - it simply has a vision of what it wants to achieve with some high-level desired outcomes and a knowledge of certain high-level constraints within which the solution needs to be delivered.

Software - and ultimately the solution - involves nothing more than the codification of business processes. The supplier provides the technical domain and the customer has to provide the business domain. It is only when these two skill sets fully come together that the optimum solution can be achieved. So, to pick up on Alex's point, both the contract and procurement model should be based on a purer service model for the procurement of a technical skill set and resource. However, importantly, the model is results-driven and outcome-based (to ensure that quantifiable value is delivered to the customer).

The supplier is selling, and the customer is buying, a domain expertise and a level of rigour that is applied to the development of new products/services. In other words, the supplier commits to provide a quantified outcome. The focus of the contract is not on the detail or content of the outcome, but on the amount of the outcome and how that outcome will be delivered using a highly disciplined process.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.

About IndigoBlue

Since incorporation in 2002, we have built an unrivaled reputation, successfully delivering a number of the UK's largest Agile change programmes.

More about IndigoBlue >>