Control – part 19 - Controlling change part 2
Project changes
Terms of reference, scope, objectives, approach
Clearly any change to areas in the Terms of Reference require agreement amongst the stakeholders.
This is particularly important when referring to the scope of the project and what is delivered to the customer.
There should be a clear understanding as to necessary characteristics and features of the product compared to ‘nice to have’.
Any such modifications would have to be approved by senior management.
This would be the Project Board under PRINCE2®.
The project approach is the strategy of how to produce the customer product.
This is decided before the project can gain approval.
If there is a drastic change in the approach it may well cause closure of the project and the start of a new one.
Subject to impact and cost-benefit analysis
Any changes to the project scope, objectives or approach is likely to affect the Terms of Reference and as such may well affect business interests.
Any changes should be assessed as to their impact and a cost / benefit analysis carried out.
This would be a natural consequence of reviewing the Business Case under PRINCE2 which justifies a viable business plan before a project is approved.
Necessary v nice to have
The change of scope could focus on identifying the product features in terms of ‘necessary’ and ‘nice to have’.
Project deliverables
Milestones are the key review point in projects and are usually designed to mark a natural break in the project.
These will be designated stages or stage boundaries.
The completion of a stage is noted by reaching a milestone and showing that all the deliverables have been produced to the desired quality.
All deliverables should be identified for each milestone and recorded.
Mostly paper
In terms of project deliverables, (apart from the product itself), these will be mostly paper.
For example, reports, plans, designs, specifications etc (non paper could be a prototype or other model).
Make sure the prototype is not suddenly mistaken for the end product.
It is what it says, a prototype. Once the prototype has been completed remove it so no one mistakes it for the end product.
Organise via the ‘project office’
All control processes must be agreed and well communicated so that all managers and staff are aware of them and their significance.
This aspect can be aided by a ‘project office’ who can help manage the standards.
Under PRINCE2 2005 the Configuration Librarian will control the archiving, issuing, version number and recall of project documentation centrally.
This role or that of the project office may be under the control of programme management if the project is part of a wider activity.
This is described in more detail within the process Change Control Technique and the process 'Controlling a Stage (CS)'.
[see Change control – technique].
In PRINCE2 2009 [see ‘The Complete Project Management plus PRINCE2’], the process Change Control Technique is named Change Control Procedure and exists as part of the Change theme.
It provides a common approach to dealing with requests for change, off-specifications and problems/concerns.
[see Change - The PRINCE2 approach - Issue and change control procedure]
Documentation control procedures
Make sure that you document changes, impacts and actions in just the same way as for risks and issues.
You may wish to record:
Project no:
Ref. number:
title / description:
Priority:
Date raised:
External ref: To risk or issue perhaps causing the change
Status: Open, closed i.e. incorporated in the plan or schedule
Action:
Responsibility:
Impact: For example, on cost, resource or timescales
Sign off authority:
Review date:
PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.