IT lawyer Susan Atkinson argues, in the IEEE Computer Society Journal, that the neglected standard contract model for software development is contributing to the high rates of failure in IT projects.

It is hard to believe that, despite the fact that the software industry has come of age, the success rates of IT projects are so poor. According to the CHAOS Report issued by the Standish Group in 2011 about two thirds of all software projects are delivered late or fail outright. More recently it has been found that one in six IT projects has an average cost overrun of 200 per cent and a schedule overrun of almost 70 per cent.

It seems that no organisation is immune from these risks. There was a common belief that out of control IT projects were the preserve of the public sector, but recent studies show that the private sector does not fare any better in comparison.

For many years, the spotlight has been focused on the suppliers or the project management to try to explain these failure levels. Yet to date the contract model underpinning these projects has been largely ignored. Susan Atkinson, IT specialist with Keystone Law, argues in the IEEE Computer Society Journal that the contract model for software development is based on outdated thinking which is seriously flawed, and that the contract model plays a significant factor in contributing towards these failures.

Even if an IT project is resourced internally, the organisation tends to apply quasi-contractual relationships between its internal departments for the purchase of IT services. And we have found the principles of the contract model in evidence here too.

The traditional IT contract model

The term ‘contract model’ is used to refer to any contract that contains the following three elements:

  • output-based requirements – the supplier is required to deliver output that possesses all of the requirements, as specified by the customer in the contract. The term ‘output’ is used to refer to product (e.g. code, features, functions, attributes), documentation and services;
  • change control mechanism – any change to any output-based requirement or to any other element of the contract is regulated by the change control mechanism. This involves a formal and documented process which leads to an amendment to the contract incorporating the agreed change; and
  • sequential development – the software is to be developed sequentially, that is, using the waterfall model. Development is seen as flowing steadily downwards, like a waterfall, through the phases of conception, initiation, analysis, design, construction and testing. The supplier is required to complete each phase before starting the next phase, and the output of each phase provides the input for the next phase.

On the face of it, the contract model may appear to be eminently sensible. It creates a sense of certainty and predictability regarding the IT project, and it provides an apparently clear basis on which the budget for the IT project can be forecast. In addition, the contract model mirrors current procurement models.

However, the effect of the contract model is to increase the risk of failure of the IT project.

Risk in IT projects

Any IT project is subject to risk which can be categorised into three main types:

  • 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 does not deliver the expected business value; or
  • existing business model failure risk – the risk that the IT project damages the existing organisation.

The contract model does not address the second two categories of risk and actually increases the customer’s exposure to all three categories of risk.

Delivery risk

The contract model assumes that the output-based requirements can be predicted upfront. As a result the contract model fails to adequately respond to changing conditions and forces the customer to incur costs disproportionate to the returns on the IT project.

The assumption that the output-based requirements can be predicted upfront is predicated on two further assumptions. Firstly, that the output-based requirements are understood fully by both the customer and the supplier before the contract is signed and, secondly, that the software can be finished before significant changes occur.Both of these assumptions are flawed.

The very dynamics of the IT project lead to changes. In any event, it is not possible to anticipate how the many disparate design elements of the software will interact before the software is implemented, and this can frequently lead to surprises.

External forces are also at play. Technology is evolving faster, and the market or context in which the concept for the software was conceived continues to change.

If changes do happen, the parties will need to implement the change control mechanism. This is administratively burdensome, expensive to operate, inevitably leads to delays (as neither its implementation nor its impact was factored into the original schedule), and it can have a destabilising effect on the IT project.

To make matters worse – and as a result of sequential development – it is not until testing, late on in the IT project, that the customer has access to the software and can assess whether the software meets its needs. It is much more expensive to make changes at this late stage.

Business value risk

The business value risk, actually overlooked by the contract model, is far more serious. There is an assumption underlying the contract model that if the supplier delivers software that meets the output-based requirements, it will therefore deliver business value to the customer.

However, this in turn assumes that the customer knows what itneeds. In practice, although customers are very good at stating what they want, far too often customers do not in fact know what they need. As a result, it is not uncommon for the customer to be disappointed with the resulting software, even if the supplier can demonstrate that the software meets the output-based requirements.

This has been demonstrated by the findings of the US Department of Defense, which analysed the value received from its annual IT expenditure. Alarmingly, it found that only 2 per cent of the software was able to be used as delivered. The vast majority of the software was either never used or was cancelled prior to delivery.

Increased existing business model risk

Similarly, the contract model does not address the possibility of existing business model failure risk. As a result it increases the exposure of the customer to this category of risk, which is arguably the most insidious of the three different categories.

The contract model encourages the customer to release the new software system as a single unit. Yet for many organisations it is simply not realistic to attempt to assimilate a large and complex software system into their existing business processes all at once.The risk of any of the existing business processes falling down under the enormity of the change is huge.

Next steps

The contract model is in need of a total overhaul. With our increasing dependency on IT and escalating costs of IT expenditure, an overhaul of the contract model cannot happen soon enough.

First published as ‘Software development: why the traditional contract model is not fit for purpose’by Susan Atkinson and Gabrielle Benefield, IEEE Computer Society – 2013 46th HICSS.

This article is for general information purposes only and does not constitute legal or professional advice. It should not be used as a substitute for legal advice relating to your particular circumstances. Please note that the law may have changed since the date of this article.