General

Change control is the means by which all requests to change a scope baseline are captured, evaluated and then approved or rejected. Its goals are to:

• capture stakeholders’ requests to make changes to scope;
• ensure that requests are only approved if viable and achievable;
• integrate changes into the existing scope.

Where scope is well defined early in the life cycle, it is essential for success that changes to approved baselines are controlled. A rigorous change control procedure must be established and maintained on all projects, programmes and portfolios. It must allow stakeholders to submit their suggestions for changes to scope. A typical procedure is shown below:

 

The planning step will define how the management team will work with stakeholders to handle a subject that can be significant source of conflict. It may include setting limits on the amount of change permissible and must certainly integrate closely with stakeholder management. It may even define which stakeholders are allowed to submit requests, perhaps acting as a point of contact and initial filter for their stakeholder group.

The initiation step will ensure that resources are mobilised that have the necessary competences to deal with the complexity of the scope. This sometimes requires the appointment of a body called the change control authority to ensure that change requests are not only properly assessed but the procedure is seen to be open and fair.

Planning and initiation will often be performed as part of overall scope management and will usually be combined with the corresponding steps in the configuration management procedure.

The first specific step in the procedure is when a stakeholder makes a change request. The stakeholder must provide relevant information about the nature of the change. The request is entered into a change log which records all requests and their status (e.g. pending, approved, rejected or deferred).

The change request is reviewed to determine its high-level impact on outputs, outcomes and benefits. If necessary, further clarification may be sought before deciding if it is worthwhile performing a detailed assessment. The proposed change may be rejected without further evaluation, in which case the reasons for rejection will be recorded and feedback given to the stakeholder.

If a full assessment is justified, all options relating to the change are captured and evaluated. To be accepted a proposed change should be beneficial, practical and affordable.

Beneficial means that it has a positive impact on the business case, or has some other advantage such as reducing risk. Practical means that it will work in the context of the specification and any other changes. Affordable means that funds are available to pay for the change perhaps through a change budget or management reserve.

The detailed impact on delivery plans is also assessed and a recommendation to approve, reject, defer, or request more information is made. Thresholds are set to determine whether the decision can be made by the P3 manager, sponsor or other members of the management team.

The decision is then communicated to the management team and stakeholders including feedback where appropriate. Recording lessons learned from the assessment can speed up future assessments that have similar technical content.

If the change is approved relevant delivery plans are updated and the changes are made to existing products, or specifications for future products.

There is always the possibility that urgent changes are imposed or pushed through without due process. These should be retrospectively put through the change control procedure.

Any approved changes need to be fed back into the configuration management system. In some circumstances it may be appropriate to have a change freeze where no further changes to scope will be considered. Where this has been agreed by the sponsor, it should be included as a key decision point in the scope management plan.

 

Projects, programmes and portfolios

Most change requests relate to the products that make up a project output. Approved changes usually have cost implications and ideally funds will have been set aside in the project budget to cover this. Some projects will be subject to contractual terms that have a significant impact on change control. Payment methods written in to the contract may not allow any change to the contracted specification while others will have a pre-determined schedule of payments for authorised changes.

Just like any other budget, a change budget will have limits and tolerances. If the work is predicted to exceed these tolerances the project manager will need to escalate this issue to the sponsor who may have to seek additional funding.

Agile projects take a very different approach and make change an integral part of development. Each iteration starts with a planning meeting that clarifies and prioritises the products addressed in the iteration. Some of these features may be changes to existing features but are considered alongside all the others.

Change control at programme level is concerned with changes that relate to benefits, either because a change request is directly aimed at a benefit profile or because of the indirect effect of project changes on benefits.

The procedure will initially assess the impact of a change request on benefits and then assess the impact on the component projects. Significant change to a project may require a redistribution of resources or funds and may have a knock-on effect on other projects.

Some change requests within one project may have knock-on effects on other projects. The complexity of these inter-dependencies is something that the programme management team need to be very aware of.

A structured portfolio is dependent upon corporate strategy for its objectives. This may change to reflect a changing commercial environment and naturally the portfolio must respond accordingly. The change control procedure doesn’t really apply to ‘change requests’ emanating from corporate strategy in terms of deciding whether to accept or reject them. Nonetheless, these changes still need to be assessed for their implications on the objectives of the component projects and programmes.

Instead of approving or rejecting a change request, the portfolio version of the procedure may result in reprioritisation, or even the cancellation, of some of projects or programmes and the identification of new ones.