For too long the poor track record of IT projects has been blamed on the suppliers or the project management. The contract model has been largely ignored.
However, traditional contracts are based on outdated principles which can be traced back to the Industrial Revolution. They are ill-suited to today’s dynamic and consumer-driven business environment. And the effects are disastrous.
This is of concern not just for IT projects which have been outsourced to an external provider. Even where a project is resourced internally, the organisation tends to set up quasi-contractual relationships between its internal departments for the purchase of IT services. And we find the principles of the contract model in evidence here too.
Traditional contracts require the customer to specify all the requirements for the product upfront. All of these requirements are developed in a single pass using the discredited waterfall model. If any changes occur during the development process, they are regulated by the formalised change control mechanism and require an amendment to the contract.
Project management risk categories
- Delivery risk: The risk that the IT project is not delivered on time, on budget and to the required quality.
- Business value risk: The risk that the IT project doesn't deliver the expected business value.
- Existing business model failure risk: The risk that the IT project damages the existing organisation.
In its desire to create certainty, the contract model actually courts dysfunction and increases the risk of the project failing. This risk can be categorised into three types: delivery risk, business value risk and existing business model failure risk. The contract model ignores the second two categories of risk and actually increases the risk in all three categories.
The focus of the contract is on getting it right first time, on time and within a narrow margin of error from the original budget.
But no one can predict with accuracy all of the requirements for the product before the project starts. This assumes, firstly, that the customer knows precisely what it needs and the supplier knows exactly what to build before the IT project starts; and, secondly, that nothing will change before the product is built. Both of these assumptions are flawed.
As a result, the contract encourages the parties to embark on an exercise that is bound to fail. And to compound the problems, the contract fails to respond adequately to changing conditions.
The business risk, actually overlooked by the contract, is far more serious.
Firstly, there is no attempt to link the resulting product to the business outcomes which the customer wishes to achieve. It is not uncommon for the supplier to build the "wrong product". It successfully executes against the contractual requirements, but the customer is still disappointed because the product does not do what it needs it to do.
To make matters worse, the single pass approach means that the supplier builds the full product straight away, without learning empirically along the way what the customer actually needs.
Existing business model risk
The existing business model risk is arguably the most insidious of the three categories of risk.
The traditional contract model for software development is in need of a total overhaul
Susan Atkinson, Keystone Law & Gabriella Benefield, Evolve Beyond
The contract does not address how the new product will be assimilated into the customer’s existing business operations. For many organisations, it is simply not realistic to launch the entire new product all at once. The risk of any of the customer’s existing business processes falling down under the enormity of the change is huge.
The traditional contract model for software development is in need of a total overhaul. With our increasing dependency of IT and escalating costs of IT spend, an overhaul cannot happen soon enough.
Susan Atkinson, a Consultant Solicitor at Keystone Law, and Gabrielle Benefield, a coach at Evolve Beyond, (both pictured above) have developed a lightweight, flexible contract model that embraces emergent, evolutionary and iterative design.
This was first published in April 2013