Issue Explained
This article looks at change during the project phase of an IT deal. (By project phase I mean either a material transition or transformation activity at the start of a new technology deal or perhaps the development of a significant new application or IT system where the customer has transferred the risk of the development to the supplier.)
One thing that can kill a project dead, even when the customer and supplier have otherwise set the deal up to succeed, is the customer raising a series of Change Requests (for anything other than the most minor of changes). Projects lose significant time and resource when the project team is required to impact assess Change Requests and agree the resulting Change Control Note. In addition, against the moving background of the project, even change processed through the best-run change regime can become dangerously out of date before the Change Control Note is agreed.
I focus here on the impact of multiple changes on a project, but you should keep in mind that any Change Request will require significant work by the supplier in determining the impact of the change. The Impact Assessment will be carried out by those closest to the project who understand the way the solution and the deal has been constructed: those vital to the project itself. It is inevitable, therefore, that all Change Requests will have an impact on the performance of the project team and, even if they don’t result in an immediate delay to the project, will increase the pressure on the plan.
In my view all change should be avoided during the project phase of a technology deal. If change is vital, the supplier and customer should recognise the project float (or time contingency) that is being eroded by the change and be prepared to allow for a relaxation to the plan and amendments to costs and charges regardless of whether the change is implemented or not.
Change Requests as a Symptom
There are many reasons why Change Requests are raised. However, if a number of requests start to get raised during the project phase one of the other factors discussed or to be discussed in these posts may well be the cause.
If there is an underlying cause, it will often be better for the parties to focus on agreeing a halt to the project (and how costs should be dealt with for the pause) and to then establish a firmer baseline to reset the contract and the project around.
What Happens when a Change is Raised?
Imagine what happens when a customer raises a Change Request during a project: The supplier has to triage the change and decide who needs to consider it to prepare an Impact Assessment.
Unless a very minor matter is being addressed, the change is going to need the Solution Architect to review the change and its implications for the solution. If the change might impact the design or operation of the on-going service provided using the system being developed then the Service Delivery Director will need to consider the implications of the change for the on-going service. Next the Project Director will need to consider the implications for the project plan.
The change may also have risk implications – eg the risks associated with the solution or the robustness of the service it will provide. The risks along with the costs associated with the revised solution, changes to the plan and changes to the costs of delivering the service will all need to be considered by the costing experts to prepare a change to the charges.
Finally, these are all fed back to the customer in the form of an impact assessment.
If agreed, the parties will then need to engage the commercial teams to prepare and negotiate a Change Control Note implementing the change.
It will generally take several weeks to consider even a relatively minor change request carefully. All the while, the project is moving on, and key resource is being diverted from the project deliverables to the change task.
One or two changes of this kind during the course of a project lasting a number of months is probably going to be OK, given the float and the ability for individuals to take on an overload of work for short periods.
It remains a risk to projects – even at this low level – and should be recognised as such: hence the suggestion above to avoid change if at all possible.
When Changes Continue to be Raised
Consider the situation when two, three or more Change Requests are raised within a few days or weeks of each other. Here the situation is much more serious, and shows how quickly change can cause a project to fail.
When there is more than one Change Request in process at once, the question then becomes: what is the baseline against which each Change Request should be considered?
Imagine the supplier is assessing the impact of a change to the solution. It is going to take another week to get an Impact Assessment completed and returned to the customer. In the meantime a second Change Request is received from the customer, and a similar process has to be followed. This time however, the supplier has to impact the second change both against the baseline project documentation and then, again, against the project as changed by the first change.
So, instead of two Change Requests resulting in two Impact Assessments, the two Change Requests require three Impact Assessments.
Now imagine that just as the first Impact Assessment is delivered back to the customer to consider whether to accept it or not, a third Change Request is received. Here that change will need to be impacted against the baseline; the first change; the second change; the first change not applying, but the second change applying; the first change applying and the second change not applying. So now, we have five additional Impact Assessments to consider and eight in total.
If we go one further step, consider the position where there are four Change Requests being considered by the parties without having finalised and signed off any as the new baseline. Here the supplier will have to prepare the following Impact Assessments for the fourth Change Request:
- baseline (with no previous changes applying);
- the first change, second change and third change all applying;
- the first change not applying, but the second and third applying;
- the first, not the second, but the third applying;
- the first and second not applying, but the third applying;
- the first and second applying, but not the third;
- the first and third not applying, but the second applying.
So here there are seven Impact Assessments for the fourth Change Request – together with the five for the third, the three for the second and the one for the first: 15 altogether.
At five requests, there are up to 31 Impact Assessments required. That many spells the end of a well managed project. And that is at just five Change Requests.
The number of Impact Assessments required goes up exponentially according to the following formula (where n is the number of Change Requests outstanding at that point):
Number of Impact Assessments = (2^n) – 1
You can imagine the time required by those involved in the project to consider the impact of these changes and the resulting distraction from the project. Simply assessing the impact of change is highly likely to cause delays to the project.
I may be exaggerating the number of impact assessments that will be prepared in practice when more than one change is outstanding, but the points remain:
- all change will distract from a project, and can materially impact the project plan;
- as the number of changes outstanding at any point increases beyond two, the change process quickly becomes unworkable.
Dealing with the Issue
Ideally, a change freeze should be imposed. If that is not possible, a combination of a few of the other suggestions below will minimise the risk.
The underlying reason for any Change Requests should also be considered if the number of requests starts to tick up. They will often be a symptom of a more significant problem with the deal. Where that is the case, as mentioned above, it is often better for the parties to focus on agreeing a halt to the project (and how costs should be dealt with for the pause) and to establish a firmer baseline to reset the contract and the project around.
Suggestions for dealing with the issue include:
- Impose a change freeze for the duration of the project/project phase.
- Establish a ‘triaging system’, that allows only changes that are considered vital to the success of the project to continue to be impact assessed.
- Put a queuing system in place. This would require that only two changes may be in the process of having been raised, impact assessed and approved/rejected at any one time.
- Require a discussion of the implications of raising a change at the senior governance board, before a decision to raise it is made.
- In addition, require the agreement of both parties in the senior governance board that it should be raised.
- Provide for the impacting of all changes to be charged for – in order to incentive the business and project teams to keep changes to a minimum and to raise only changes that are likely to be followed through.
- Provide for impact assessments to include changes to the project plan and charges to take account of any delay caused by impact assessing the change request.
Summary
Raising changes during the project phase of a deal has the potential to damage, perhaps fatally damage, the project. It is best to find ways to avoid raising changes and if a change must be raised, to keep the number of changes being considered to only a few at any one time.
Andrew Hooles is Legal Director, Commercial, Legal and Assurance at Fujitsu Services Limited. His series of blog posts on the topic can be accessed here.
