The PRINCE2 7 Approach To Change Management
PRINCE2 7 CHANGE MANAGEMENT IN A NUTSHELL
PRINCE2 recommends an approach to issue management and change control but this is not prescriptive. Any approach that meets the requirements can be said to be following PRINCE2.
Responsibilities for managing change in PRINCE2 are described below, and if roles are combined. these responsibilities must still be undertaken.
Be aware that corporate, programme management or the customer provides the corporate, programme management or customer strategies for issue resolution and change control
PRINCE2 7’s approach to change
To be following PRINCE2, a project must, as a minimum: define its change control approach. This approach must minimally cover:
- how issues are identified and managed assessing whether identified issues might have a material impact on the business justification of the project PRINCE2’s continued business justification principle
- the roles and responsibilities for change control (PRINCE2’s defined roles and responsibilities principle)
- must include a defined change authority
The PRINCE2 7 change system must:
- define how product baselines are created, maintained and controlled
- maintain some form of issue register to record identified issues and decisions relating to their analysis, management and review
- ensure that project issues are captured, examined, managed and reviewed throughout the project lifecycle
- use lessons to inform issue identification and management (PRINCE2’s learn from experience principle)
PRINCE2 requires that the following products are produced and maintained:
- The Issue register captures and maintains information on all the issues that are being formally managed.
- Issues management approach Identifies how, and by whom, the project’s products will be controlled and protected. If the issue register does not contain sufficient detail (e.g. for the options appraisal, recommendation and decision), then a separate issue report can be used but this is an optional management product
- The project’s controls for issues and change will be defined and established during the initiating a project process, then reviewed and (if necessary) updated towards the end of each management stage by the managing a stage boundary process
PRINCE2 Change Control Roles and Responsibilities
Executive
- Determine the change authority and change budget
- Set the scale for rating the severity of issues
- Set the scale for priority ratings for requests for change and off-specifications
- Respond to requests for advice from the project manager
- Make decisions on escalated issues, with particular focus on continued business justification
Senior User
- Respond to requests for advice from the project manager
- Make decisions on escalated issues
- Safeguard the expected benefits
Senior Supplier
- Respond to requests for advice from the project manager
- Make decisions on escalated issues
- Safeguard the integrity of the complete solution
Project Manager
- Create and maintain the change control approach
- Create, Maintain, and manage the issue and change control procedures, assisted by project support where possible
- Implement corrective actions
Team Manager
Implement corrective actions
Project Assurance
Advise on examining and resolving issues
Project Support
Administer the change control and issue procedures by:
- maintaining configuration item records, if used
- producing product status accounts
- assisting the project manager in maintaining the issue register
Guidance for effective change control
General tailoring considerationsThe starting point for all projects will be to identify whether there are any corporate, programme management or customer policies and processes that need to be applied, and incorporate them into the project’s own change control approach.
If the project is within a programme or portfolio, there may be a requirement that the project uses their defined policies and processes. In a commercial environment, the project may be required to adopt change control procedures and processes defined in the contract.
Issue management and change control may be treated as separate processes or procedures provided the relationship between them is defined. The approach may be tailored to reflect any tools used, in terms of roles, workflow and terminology.
Project size, scale and complexity
Ensure that the change control approach is appropriate to project size, scale and complexity. It is important to ensure that the change control approach to a project provides support for effective decision-making on the project and does not create undue burden or bureaucracy.
In general, smaller, simpler projects will need correspondingly simpler issue management and change control arrangements.
Managing product baselinesAll projects need an appropriate approach to creating, maintaining and controlling product baselines for both management and specialist products.
For simpler projects, document management procedures will generally suffice. More complex projects will usually need some form of formal configuration management, asset management or product management process, often supported by specific tools.
Regardless of size, scale and complexity, the project team needs to determine the appropriate level at which products need to be baselined.
This is generally determined by breaking down the project’s products until the level is reached at which a component can be independently released, installed, replaced or modified.
However, the level of control exercised will be influenced by the importance of the project and the complexity of the relationships between its products
How configuration items are identified
Generally, a coding system of some type will need to be established, providing a unique identifier for each configuration item
The specific authorities and authorizations needed to approve and baseline configuration items, what information about configuration items needs to be captured and maintained in configuration item records, if used.
It is good practice to periodically verify that the actual status of products reflects the authorized state of products as they are registered in the configuration item records, looking for any discrepancies.
This is usually through reviews or audits, typically undertaken at the end of each stage and at the end of the project.
The project’s delivery approach
It is important that the approach to managing issues and change works with, and supports, the project’s chosen delivery approach, rather than working against it.
For example, a change control approach that defines that there will be a monthly review of proposed changes is unlikely to effectively support an agile delivery approach where delivery may be happening every week or 2 weeks.
The appropriate definition of product descriptions, quality criteria, quality tolerances and work packages is important.
They can be defined in such a way as to allow for change at the detailed level, while at the same time creating a clearly defined baseline that can prevent a change to the purpose of a product going undetected.
Delegating to a change authority
The project board is responsible for reviewing and approving requests for change and off-specifications. In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands of the project board.
But for projects where there are likely to be many changes, the project board may choose to delegate some decisions to a person or group, called the change authority. The project manager and/or the people with delegated project assurance responsibilities may act as the change authority.
In practice, the majority of changes will be generated at the work package level. It is important to ensure that the change authority for work packages has sufficient delegated authority so that changes can be made without always having to escalate decisions to the project board for approval.
Establishing a change budget
A change budget is a sum of money that the customer and supplier agree will be used to fund the cost of requests for change, and possibly also their analysis costs.
Unless the anticipated level of change on a project is low, a budget should be set up to pay for changes. This arrangement can reduce the number of trivial exceptions arising in projects where the frequency of change requests is forecast to be high.
Including a change budget provides for a more realistic expectation of the overall costs/time frame of the project.
Where a change budget is given to a change authority, the project board may wish to put a limit on the cost of any single change, and the amount spent on change in any one stage without reference to the project board.
The change control procedure would then be defined in such a way as to control access to the change budget. If used, the change budget is documented in the relevant plan. The project board should decide the need for a change budget
Want to Pass PRINCE2 PRACTIONER On the First Try?
PRINCE2® 7 Foundation and Practitioner
Learn PRINCE2® 7 Foundation and Practitioner Online
** Enhance your PRINCE2 career now **
PRINCE2® Masterclass gives you the skills necessary to manage projects effectively and achieve your objectives.
Get 7 days a week 12 months one to one coaching with ex PRINCE2 examiner Dave Litten.
PRINCE2® is a globally recognized project management framework. By completing both the Foundation and Practitioner courses through our self-paced e-learning, you will develop an understanding of the methodology and learn how to effectively adapt it to any project.
The PRINCE2® 7 Foundation and Practitioner Masterclass is PeopleCert Accredited and guarantees to take you from PRINCE2 Novice to PRINCE2 Practitioner with our famous video learning, study guides and practice exams.
What Does the Masterclass Cover?
The PRINCE2 Foundation examination assesses your knowledge and comprehension of the PRINCE2 project management methodology as detailed in the syllabus. The PRINCE2 Practitioner examination, on the other hand, gauges your ability to apply and tailor the PRINCE2 method. Candidates who pass the Practitioner exam should be able to start implementing the method on an actual project with some guidance. However, their effectiveness may differ based on their experience in project management, the complexity of the project, and the level of support they receive in their work environment.
