Success by planning for IT failure – part 1: Scope and scope creep

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 from an IT and business perspective, as well as contractually.

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. We will have this as our theme over the course of some of the following articles.

In this edition, we will start by considering where things can start to go awry – ‘scope,’ and let’s not forget the wonderful world of ‘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, as well as the respective obligations of the customer and IT service provider.

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 and expectations which the customer has, whilst trying to subsequently change the project scope to meet those requirements, is something which the service provider has probably not factored into its time and cost model for the project.

The true ‘classic fudge’ to this problem, is to adopt a complacent approach, by a customer stating that it requires a new solution, which achieves all of the functionality and performance of what the customer already had ‘and then some’… (the ‘then some’ usually has a sprinkling of ‘kitchen sink’ items !).

So what is the problem with adopting such a short-cut approach ? Well, unless it is a very simple IT implementation from a standard platform, for an IT service provider to work out what the existing system is providing from a functionality and performance perspective, is going to require considerable due diligence – which means time and cost. There will also be the inevitable caveats to what is covered and not covered by such due diligence. So the customer will inevitably risk ending up with a solution which does not entirely meet its requirements, because of the limitations and caveats applied to the due diligence exercise.

It is therefore, far better, for the IT and commercial teams of the parties to invest some time to 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.

It is this change control process which is supposed to deal with the ‘scope creep’ elements. Again, some parties feel that this is a great ‘get out of jail free card’ to getting the scope correct at the outset, as the parties can continually choose to change or expand the requirements. Well this is not what such a process is intended for. The process is supposed to deal with genuine changes in requirements. If it is used as a ‘scope filler’ to address any initial complacency, then the parties need to be alive to the fact, that there will be time and cost associated with such activities. It will be a question of negotiation as to who bears the cost of the change, depending upon the nature of the changes, but if it is a genuine scope change, then more than likely, this cost will be imposed on the customer. This of course means that the agreed time and cost budgets which have been presented and signed off by the customer’s Board, will inevitably also change.

Scope clarity is therefore essential. Now it is not necessary to go to the ‘nth degree’ as to granularity of detail, as long as what is agreed, materially sets out the requirements, with a process to agree further granularity through a co-operative approach.

One needs to also bear in mind though, that at law, ‘an agreement to agree’ is not enforceable (and in extreme cases can result in a contract being held void for uncertainty). So although commonly used in contracts, together with qualifications as to ‘reasonableness,’ one does not want to have key arrangements relating to scope to be left as such ‘agreements to agree.’ In particular, what happens if the parties can not agree something ? – whilst the relationship is ‘peachy,’ agreements will come naturally, but as soon as the clichéd object ‘hits the fan,’ then such mutual co-operation may be more difficult to come by, especially when the parties are feeling time or cost pressures.

So in summary:
      

1 Don’t rush the contract !

2 Provision time for stakeholders from the IT and business teams to get involved early in discussions, to identify what is being required (and being able to internally justify why, rather than just providing a ‘wish list’);

3 Get the IT and business team to actively get involved in drafting up the scope requirements for the contract, rather than leaving it just to the lawyers – as we have said in previous articles, this is where the IT team can seek true empowerment within the organisation;

4 Ensure that what is being sought to be provided, is clear, and capable of being provided within realistic timeframes;

5 Ensure that there is a process for agreeing further granularity and changes, and identify upfront which stakeholders from both the customer and the service provider need to be involved in those processes;

6 Check that key aspects are not being left as ‘agreements to agree.’ If the scope of the project means that there is no alternative but to agree certain arrangements subsequently, ensure that an appropriate process, such as workshops, are provisioned to allow for that, or make the contract a framework arrangement to allow aspects to be undertaken in a phased manner.

Jagvinder Kang, Technology Law Alliance