25

---

Let’s Do it Differently!: Change Control

Controlling change

Changes are an inevitable fact of project life (Figure 25.1). Seldom does a project go exactly to plan. Unless you manage these changes effectively you will soon lose sight of the objectives and scope and thereafter lose total control of the project.

Controlling change does not mean preventing change, but rather allowing only beneficial changes to be adopted and included in the project.

Change control is related to risk, opportunity and issue management; a risk or opportunity will become an issue if the event occurs. Issues can be dealt with either within the scope of the project as currently defined or via a change to the project. If this ‘issue’ is to be resolved by a change to the defined project, the impact of this change should be assessed, particularly with respect to the expected benefits (see Figure 25.1).

Change may result from a number of sources:

• changes in business needs/requirements driven by the project sponsor or other stakeholders;
• changes in the business environment (e.g. economics, social factors, competitor action);
• problems or opportunities which occur during the course of the project;
• modifications or enhancements identified by the project team (beware of these!);
• faults detected by the project team or users (these must be addressed).

• benefits to be realised by the project;
• scope of work and detail for each deliverable;
• project timescale and intermediate milestone dates;
• project cost.

‘Scope creep’ is a phenomenon where a project overruns its agreed timescale and budget due to many extra (often minor) ‘requirements’ being added in an uncontrolled manner. For this reason it is often easier to bundle a number of small changes together and assess them as a whole, choosing to implement only those which will further the objectives of the project. At the other end of the scale it is wise to consider delaying the addition of a major change until after the project is completed and introduce it as a second phase project.

Remember, the primary aim of a project is to fulfil a stated business need. As long as this need is satisfied, fine tuning, enhancing or embellishing the outputs is a potential waste of resource and time.

Inevitably, a time will come when an issue will arise on a project which cannot be resolved while still keeping the project viable. Either a time window will be missed or costs will be so high that even a marginal cost analysis leads to the conclusion that it is not worth continuing. In these cases, the impact assessment will result in a recommendation to terminate the project. Such an outcome should be treated as a success, as there is little point in continuing with a project which is not viable in business terms (for more on termination, see pp. 448, 463).

The change control process

Because of the potential for changes to reduce projects to chaos, it is preferable to adopt a formal approach to assessing and authorising change right from the start (Figure 25.2):

• Note the proposed change in the change log (see Figure 25.3, for an example).
• Assess the impact of the change on the project and any interdependent projects. (See Figure 25.4 for a summary impact assessment form.)
• If within the project manager’s authority, reject or accept the change proposal.
• If it is outside the project manager’s authority, refer the decision (with a recommendation) to the appropriate level for a review and decision.

The change proposal may be:

• accepted for immediate implementation;
• accepted, subject to certain conditions being met;
• accepted but implementation is deferred to a later date;
• rejected (with/without recommendation to include in a later project).

Once the decision has been made, the project manager should:

• obtain further financial authorisation (if needed);
• record the outcome in the change log.
• If the change was accepted:
  • implement the change;
  • update the project documentation;
  • inform all interested parties about the change;
• inform the originator of the outcome and, if rejected, give the reason for the decision.

Accountabilities for change decisions

All proposed changes need to be reviewed and their impact assessed before they are accepted or rejected. A project may have several levels for the review and authorisation of changes, depending on how serious or far reaching the impact of the change will be. The following table suggests such levels.

Notice that the first two levels of authority lie within the project itself as the impacts do not affect other projects. Once other projects are affected, it is necessary to have the change reviewed and authorised by a higher authority that can balance the conflicting needs of different projects and sponsors.

The impact levels should be defined and agreed when the project is authorised. (Often an organisation has a standard set as part of its project authorisation process.) This should be documented in the Initial or Full Business Case.

The change request form

If a change is minor in nature and can be approved by the project manager, this may be noted directly in the change log. If approval is required by higher authority it is recommended that a change request form is used to ensure the relevant information is captured prior to completing the log.

A change request form is used to:

• document requested changes;
• summarise the impact of the change;
• formally record the decision regarding the change.

An example is given in Figure 25.4. While this is a ‘paper-based’ example, the logic lends itself to electronic-based workflow systems.

The project manager should:

• enter the relevant data into the change log (change reference number, description, originator, date raised, impact assessment by, assessment due);
• complete Part A of the change request form;
• assess (with the help of others) the impact of the change and complete Part B (impact) of the form;
• pass the form (with any supporting information) to the higher authority as appropriate (see p. 437) for approval. Any necessary financial authorisation documents should also be prepared.

The ‘approver’ should:

• review the proposed change and complete Part C as appropriate;
• return the form to the project manager.

The project manager should complete the entry in the change log.