Accountabilities for change decisions
Changes are an inevitable fact of project life. Unless you manage these changes effectively you will soon lose sight of the objectives and scope and thereafter lose total control of the project.
‘Change is certain. Progress is not.’
E H CARR
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:
Change, in the context of a project, is any modification to the benefit, scope, time, or cost targets that have previously been approved. This means that there can only be a ‘change’ if there is an approved ‘baseline’. The baseline is provided by the project definition (included in the initial and full business case) which defines the:
Change control is the process through which changes to a project (to cost, schedule, scope or benefits) are introduced and evaluated prior to their adoption or rejection.
‘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).
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):
The change proposal may be:
Once the decision has been made, the project manager should:
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.
Impact of change | Approval required by |
No impact on overall schedule, cost or benefits Allocation of scope reserve |
Project manager (record in change log) |
Minor impact. Change affecting schedule or costs which can be accommodated without affecting other projects and are within the authority (tolerance) delegated to the project sponsor Allocation of contingency |
Project sponsor (use change request form and record in change log) |
Major impact. Change affecting scope, objectives, benefits, schedule or costs which cannot be accommodated within the authority (tolerance) delegated to the project sponsor or which affects other projects | Project review group (use change request form and record in change log) In some cases a business programme board may have delegated authority which would normally be at project review group level |
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:
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:
The ‘approver’ should:
The project manager should complete the entry in the change log.
Now that many organisations have IT capabilities on virtually every desktop, the opportunity now exists to streamline the project control logs. Many organisations are now building database tools which integrate the risk, opportunity, issue and change logs into a single tool. In addition meeting notes, action and lessons learned are also often included. Such tools can greatly simplify administration. However, always remember you do need to communicate these logs/reports and therefore unless all your team members and stakeholders are equipped, you risk ‘cutting them off’.
3.138.37.191