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 Ireland-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 reiterate her words, take a look at her article on flawed software contracts. I left feeling inspired.