PRINCE2 7 issues and change management
The PRINCE2 issue management approach comprises:
- baselines: describes what is subject to change control
- issue resolution: how issues are identified, captured, assessed, and recommended for resolution
- change control: describes how changes to the project baseline are controlled
- delegating authority for changes: allocating authority from the project board down to enable a responsive but controlled way to handle changes
- change budget: the money set aside in a plan to cover changes.
Baselines
Change can only be assessed in terms of its impact on the project as understood and approved by the project board.
At any stage in its lifecycle, the project will comprise a set of management and specialist products. At any point in time, each product is either in preparation, development or has been approved. In all cases, they will be under change control.
A prerequisite to effective issue management and change control is a way of creating baselines of products that allow changes to be analysed and controlled. A new version of the product is created each time a change is approved and implemented.
Change control enables those involved to identify when changes have been made and to trace them to a decision made by the appropriate authority.
The issue management approach for a project is driven by the nature of the products to be delivered (the ‘what’ ) and the planned delivery activities (the ‘how’ ). Therefore, the preparation of this approach usually follows the preparation of product descriptions and work package descriptions.
Regardless of size, scale, and complexity, the project management team needs to determine:
- the appropriate level at which the products need to be baselined is generally determined by dividing the project products until they reach the level at which a component can be independently released, installed, replaced, or modified
- the level of control exercised will be influenced by the importance of the project and the complexity of the relationships between its products
- how products and their versions are identified
- the specific authorities and authorizations needed to approve and baselines
- the procedure to follow to capture and manage issues and changes
Generally, a system of some type will need to be established, providing a unique identifier for each product. what information about products needs to be captured and maintained in the project log (for example, versions, status, and relationships with other products).
It is good practice to periodically verify that the actual status of the products reflects the authorized state of products and look for any discrepancies. This usually occurs through reviews or audits and is typically undertaken at the end of each stage and the end of the project.
Project baselines are often managed with a variety of systems. Management products may be maintained as documents with a simple way of indicating each version and its date of approval.
Specialist products may require a dedicated system. However, each system should ensure that changes cannot be introduced without the appropriate level of approval and provide an audit trail for all changes.
In addition, the product register element of the project log should record the approval and implementation of all changes to the project baseline.
Issue resolution
PRINCE2 recommends that all issues be categorized as either:
- a problem or concern
- an event external to the project
- a business opportunity
- a request for change
- off-specification.
This assists the assessment and also provides valuable data on the type of issues that are repeatedly being raised which can indicate another aspect of project management is not working.
It is good practice when assessing and categorizing issues to check whether the issue is a risk. The distinction is that risks are uncertain. If this is the case the issue should be transferred to the risk register and the procedure in the risk management approach should be followed.
Similarly, it is good practice to review and check whether the risk register includes any entries which are not uncertain and therefore should be managed as an issue.
PRINCE2 problem or concern
A problem is an issue with an immediate and negative impact.
A concern is an issue whose timeliness and impact need to be assessed. Often, issues are first presented informally in conversations or communications among project team members.
This is particularly the case for issues that constitute a problem, concern, or business opportunity.
How to handle problems and concerns is often a matter of judgement.
Capturing too many problems and concerns as issues can inundate the project management team with trivial decisions and distract them from the most important ones.
On the other hand, project managers should avoid filtering or prejudging problems and concerns. It is most effective to identify issues early when they can generally be resolved within approved tolerances.
In some cases, the issue is an event external to the project that may impact the project in some way.
For example, a supplier going out of business is outside the project’s control, but it may force the project management team to analyse the resulting impacts and consider finding an alternative supplier.
This is why it is always advised to monitor the project’s external environment regularly.
PRINCE2 business opportunity
An issue that represents unanticipated positive consequences for the project or user organization.
Not all issues have negative consequences. In some cases, an issue occurs that represents a business opportunity with positive consequences.
For example, significant savings in the cost of goods or services, or the availability of new equipment with improved functionality.
The consequences of such business opportunities are not always limited to a project, so it can be useful to seek the advice of the project board when preparing the assessment of impacts and possible resolutions.
Issues should be recorded in the issue register. For some issues, the details captured in the issue register are sufficient for the issue to be considered and an action agreed upon.
However, some issues may require more detailed analysis and an issue report will be created.
The issue report should identify the type of issue, assess its impact on the project baseline, and recommend how to resolve the issue. Decisions and actions relating to issues should be recorded in the issue register.
In some cases, the issue or its resolution will represent a change to the project baseline. This will then need to be addressed through the change control procedure.
PRINCE2 Change control
- Change control: the process by which changes that may affect the project baseline are identified, assessed, and then approved, rejected, or deferred
- Request for change: a proposal for a change to a baseline
- Off-specification: a product that will not meet its quality specifications
- Concession: an off-specification accepted by the project board without corrective action.
All projects need an appropriate approach to control changes to the project baseline.
The issue management approach describes the project’s change control procedure, including how proposals to change the project baseline will be recorded and decided.
PRINCE2 characterizes proposals to change a project baseline as either a request for change or off-specification.
A change request must identify the management products proposed to be changed and justify making the change. If there is a cost associated with the change, the source of its funding must be identified as either the approved change budget or additional funding.
Off-specifications most often occur when a supplier fails to deliver a product that fully complies with its quality specifications. However, off-specification can also occur when a required quality specification is found to be unachievable.
In either case, it represents a discrepancy between the approved project baseline and the delivered products, and this discrepancy must be addressed through the change control procedure.
If the off-specification is accepted, the project baseline must be changed to reflect the affected product description.
Accepted off-specifications are known as concessions and require project board approval, or approval by those with delegated change authority. If the off-specification is rejected, the team manager in consultation with the project manager will need to explore how to correct the situation, including through possible use of the change budget or raising an exception report.
If an issue requires a request for a change or off-specification, the issue report should include the details of the proposed changes to enable timely decision-making.
Delegating authority for changes
The project board is the ultimate authority for reviewing and approving requests for change and off-specifications. However, the project board may delegate authority to approve changes.
Delegating authority for effective change control is a matter of balancing efficiency and control. If there is too little delegation, the project board is likely to slow the progress or be asked to review changes that others are able to decide better.
Whereas, if there is too much delegation, particularly too many different roles, there is an increased risk that the overall benefits of the project will be reduced as alignment with the business justification is diluted.
In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands of the project board. However, for projects where there are likely to be many changes, the project board may choose to delegate some decisions.
In practice, most changes will be generated at the work package level. It is important to ensure that there is sufficient delegated authority to approve the changes to the work packages.
In this way, changes can be made without always having to escalate decisions to the project board for approval.
Subject to the scale and complexity of the project, it may be useful to delegate change authority to several levels within the project management team. This is based on parameters specified in the issue management approach.
PRINCE2 Change budget
The money or authorized constraints are set aside in a plan to cover changes. It is allocated by those with delegated authority to deliver authorized changes.
The project manager should ensure that delegated authority is accompanied by an appropriate change budget from which approved changes can be delivered. The change budget is usually an amount of money earmarked specifically to fund changes.
However, it can also be defined as a set of authorized constraints within which trade-offs can be made.
A project brief might call for in-person user training, while also allowing virtual training to be used as an alternative (as long as the same number of people can be trained within the required timeframe).
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.
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.
