We've noticed that your computer is viewing this page in Internet Explorer 6 or earlier. Please upgrade to one of the following free internet browser applications for an optimal viewing experience: Internet Explorer (latest version) Firefox Safari

  1. T: 0845 351 9090
  2. E: .(JavaScript must be enabled to view this email address)


Latest IT law, outsourcing and e-commerce legal updates

Return to view all Resources

Success by Planning for IT Project Failure (Part 1)

Posted 22nd February 2012 by Jagvinder Kang, Director


When one is planning an IT project, one should always be taking a positive approach, planning for and striving for success. However, it would be foolhardy not to also plan for failure. The ‘what if’ scenario, therefore clearly needs to be contemplated and addressed, both practically and contractually.

In this Technology Column, we start to consider certain of the prudent steps one needs to take in the context of IT projects.

Legal and Business Considerations

There are numerous factors one needs to consider when planning an IT project, and with each, there is the potential for things to go wrong. A checklist of certain of these issues would therefore include dealing with:

  • Scope & Scope Creep;
  • Failure of Customer's Obligations;
  • Acceptance Testing;
  • Business Continuity and Disaster Recovery;
  • Exit Assistance;
  • Termination Liabilities; 
  • Pilot Run, Parallel Running, Roll Back; and
  • Insurance

In this edition of the Technology Column, we will consider the first two aspects of the above:

Scope & Scope Creep

It is still shocking how many projects are rushed along to meet an ‘artificial deadline’, at the expense of having clarity of what is actually being sought to be delivered and the respective obligations of the parties.

The unclear scope is just opening parties up to potential project failure and litigation down the line. As what is likely to be produced, is probably not going to meet the aspirations which the customer has, whilst trying to subsequently change the project scope to meet those aspirations, is something which the service provider has probably not factored into its time and cost model for the project.

The parties must therefore ensure that there is contractually documented clarity on the scope of the project, together with an agreed process (whether through subsequent workshops with agreed sign-offs or otherwise) to ensure that any granularity of scope can be agreed.

Where changes are necessary during a project, these should be undertaken through an agreed change control process – differentiating between low level operational/delivery process changes and material changes to the project – to ensure that the parties do not find themselves sinking in contractual change control documentation.

Failure of Customer’s Obligations

We have already mentioned above, the importance of clarity of scope, to the extent that this is reason- ably possible to achieve, within any timescales constraining the project (although it is important to clearly distinguish between genuine timescales and artificial timescales set by over-zealous IT procurement teams or over-anxious supplier sales teams).

With regard to obligations on both sides, it is important that these are properly managed. An important aspect of this, is to ensure that project managers are appointed on both sides to ensure compliance with both the contractual and practical requirements that the respective parties are required to deliver.  Ensuring the imposition of a simple, but structured and effective, governance team and process, will facilitate highlighting issues early on in the project roadmap, to mitigate against the risk of project failure downstream.


Contractually, a customer’s lawyers sometimes seek to absolve customer clients of all responsibility for compliance with their obligations, unless the supplier has proactively also managed the customer. This goes against the ‘partnering’ approach which is a necessity of complex or high-value IT projects. There are though, instances where a supplier should be managing the customer with a more ‘hands-on approach,’ but this is where the parties have agreed this commercially upfront, in circumstances where there is a lack of expertise within the ‘customer camp,’ rather than it being contractually and unilater- ally imposed by the customer’s lawyers.

Depending upon the nature of the project, and the specific requirements of the customer, a supplier agreeing to take responsibility for managing the customer, will usually only do so (this is in private sector transactions, as opposed to public sector transactions - which seem to often leave the service provider with no option but to be pro-actively ‘hands-on’ !), where the supplier has had reasonable op- portunity to:

  • undertake due diligence with regard to the requirements of the project, together with the existing nature of the customer organisation; and
  • expressly price for such additional management responsibilities.

In most IT projects though, especially where the customer has IT expertise within its organisation, whether through its internal IT team or through the procurement of IT consultants for a specific project to act as a ‘go-between’ the customer and the supplier, it will be inappropriate to have a contract
where it is permissible for the customer to ‘bury its head in the sand,’ until such time as the supplier in- tervenes. Therefore, effective project management on both sides, together with appropriate governance, is the recommended solution, rather than ‘attempted duress’ through contractual provisions.

Further Thoughts

We continue this topic in the next edition of the Technology Column. However, it is important for parties to reflect at this stage, as to whether timelines imposed for not only a project, but the negotiation of the contract itself, are realistic. The inevitable rush to finalise a contract, especially where this is being undertaken within artificial time constraints, is setting up a project for failure at the outset. It is therefore important, that appropriate time is provisioned for consideration and reflection of the types of issues we have mentioned in this Technology Column, together with the issues we will consider in the following edition.