Change Control is described in depth in any PRINCE2 training course offered by Knowledge Train.
In any project, it is normally end users, customers or clients who specify the results or outcomes required and expected from the project. These requirements must be specified by users and customers before any products can be built. For example, if you employ a builder to build you a new house, you would have to provide the builder with architectural plans which specifies the details of the building. Without these specifications, the builder does not know what to build.
A problem occurs when the user or customer doesn’t quite know what they need or, after agreeing their needs, change their mind about them. ‘I know we agreed the walls would be blue, but can you paint over them in white?’ In these circumstances, it is all too common for Project Managers to agree to make changes to products simply out of a desire to satisfy the end users and customers. When a request is made to change a product or create a new product within a project, this is known as a Request for Change which is a type of Project Issue.
If these Requests for Change are paid for from the original project budget, then the inevitable result is that the project goes over budget, is delivered late, or a combination of these things. In other words, the project suffers from ‘scope creep’ where the amount of work in the project gets larger and larger, but without any formal acknowledgement that this is happening.
However, many changes that are requested are important to the success of the project and so must still be implemented. How then do we pay for these changes if we are to avoid going over budget?
The answer is to set aside a separate budget which is used solely to pay for agreed changes. This budget is known as a Change Budget.
Of all the Requests for Change that might be raised on a project, which ones are important to implement straight away, which ones can be left till a later time and which ones should not be implemented at all? Before making a decision, it is important to perform a detailed analysis of each change to understand the effect of making the change on the project’s cost, schedule, risks, quality, plans, tolerances, Business Case and other products. Once these things are known, an informed decision can be made about whether a Request for Change should be implemented.
Let’s assume that a decision is required about whether or not to implement a change. Who should make this decision – the Project Manager, customer, end user, supplier or somebody else? The answer is the Project Board makes all decisions about whether or not to implement each change. The Project Board though might be too busy to spend a lot of time assessing potentially large numbers of Requests for Change. Their authority for making change can therefore be delegated to a group of people known as a Change Authority. This group could be comprised of users, customers and suppliers. Normally however, there always needs to be representation from the user community in order to prioritise the Requests for Change.
The Change Authority can therefore decide how to spend the Change Budget for the project. By doing so, this avoids the Project Board having to be involved in releasing small amounts of money every time a Request for Change comes along. This allows for more streamlined and effective decision-making.
What happens however, if the Change Authority wishes to sanction a change which can be done within the remaining Change Budget but by doing so takes the Stage beyond the remaining time tolerance? The answer, as is the case when any tolerance threat occurs, is to refer the change upwards to the Project Board who in turn can decide what to do if Stage tolerances are threatened. If the change can only be made by deviating beyond Project time tolerance, then the change must be referred upwards to Corporate and Programme Management.
So in summary, it is normal to assume that change always occurs on projects. This is because the business environment within which the project has to operate might change, something occurs on the project which proves to be more difficult than anticipated, or users/customers change their mind about the products to be delivered.
In these circumstances it is sensible to consider what level of change budget might be useful. Projects where end users are unsure about their requirements implies a need for a larger Change Budget. Projects where users have requirements which are fixed in stone, implies little or no Change Budget. Before the project moves out of the Initiation Stage, then the Change Budget and composition of the Change Authority must have been decided upon.
This article was taken from the booklet Concise PRINCE2™ (PRINCE2 ™ is a Trade Mark of the Office of Government Commerce) which was offered to students as part of the PRINCE2 training course (version 2005) by Knowledge Train. This booklet has been based on OGC (PRINCE2™) material. Reproduced under licence from OGC.
No part of this work may be reproduced, transcribed, or used in any form or by any means – graphic, electronic or mechanical, including photocopying, recording, taping, web distribution, or information storage and retrieval systems – without the prior written permission of the publisher.
©2008 Knowledge Train Limited unless otherwise stated.
