PRINCE2 issue and change control procedure
PRINCE2 Capture
The first step in the procedure is to undertake an initial analysis to determine the type of issue that has been raised and whether it should be managed informally or formally.
The project manager makes an initial assessment of the issues severity and priority
The project manager is likely to receive many issues that can be handled without having to treat them formally, particularly if the issue can be resolved immediately.
In such cases, the project manager should decide the best course of corrective action
The purpose of distinguishing between those issues that can be managed informally and those that need to be managed formally is to:
- Ensure decisions are made at an appropriate level within the project management team
- Avoid the project board being inundated with too many issues and therefore diluting the time it has available to deal with the key issues affecting the project
- Reduce the administrative burden on the project manager when dealing with the day-to-day issues that may arise
Issues being managed formally should be entered in the issue register and given a unique identifier
The daily log can be used to record issues being managed informally
PRINCE2 – Assessing issues
The next step is to assess the issue by undertaking an impact analysis
However, the project manager needs to consider whether it is worthwhile doing a detailed impact analysis as the duration and effort required to undertake one may itself cause a deviation from the plan
The impact analysis should consider the impact the issue has, or will have on:
- The project performance targets in terms of time, cost, quality and scope, including whether there are any other products that are within the project scope that will also be impacted by this issue
- The project business case, especially in terms of the impact on benefits
- Any other dependent products produced by the project
- The project risk profile, that is, the impact on the overall risk exposure of the project
If the project is part of a programme, the impact of the change on the program as a whole should be considered. There may also be effects on other projects that are not necessarily part of the program.
Examining the impact of issues can be wrongly taken to mean only the impact on the customer. Impact analysis must cover the three areas of business, user and supplier (for example including the suppliers cost and effort required to implement a change, and what products would have to be changed)
Having undertaken the impact analysis, the severity and priority of the issue should be re-evaluated
The issue register should be updated to include the above information and the person who raised the issue should be kept informed of its status
It may be necessary to request advice from the project board to check its understanding of the issue’s priority or severity before proposing resolutions
PRINCE2 Proposing corrective actions
After a full understanding of the impact of the issue has been gained, the next step is to consider alternative options for responding to it and proposing a course of action to take.
Consideration should be given to the effect each of the options will have on the project’s time, cost, quality, scope, benefits and risk performance targets
There must be a balance between the advantage to be gained by implementing the option and the time, costs and risk of implementing it
The risk considerations should include both project risks, for example of not completing within tolerances, and risks to operational performance when the project’s products are in use
If any of the proposed options would take the stage or project beyond tolerance is, seek advice from the project board. The project manager should execute any decision by the project board in response
PRINCE2 Deciding on corrective actions
The project manager may be able to resolve issues without the need to escalate them to the project board. For example, in minor change to an approved detailed design document that does not affect any other products, could be handled by the project manager if allowed in the change control approach, as long as it is formally recorded
Other issues may need to be escalated to the project board, or its delegated change authority, for decision. For escalating issues and exceptions, the likely project board responses are as follows:
Requests for change
- Approve the change
- Reject a change
- Defer decision
- Request more information
- Ask for an exception plan is a request for change cannot be implemented within the limits delegated to the change authority
If a request for change involves extra cost, there are three principal ways to fund it:
- Use the change budget if one is being used and it is of sufficient size
- Request that corporate, programme management or the customer increase the project budget
- De-scope Other elements of the project
Tolerance should not be used to fund requests for change
Off-Specification
- Grant a concession
- Instruct that the Off-Specification be resolved
- Defer decision
- Request more information
- Ask for an exception plan if the concession cannot be granted within the limits delegated to the change authority
The project board may decide to accept the Off-Specification without the immediate corrective action . This is referred to as a concession. When a product is granted a concession , the product description will need to be revised before the product is handed over to the user
Problem /Concern
- Provide guidance to label the project manager to solve the problem
- Ask for an exception plan
- Could the problem /Concern the resolved by relaxing the stage tolerances?
PRINCE2 Implementing corrective actions
The project manager will either:
- Take the necessary corrective action, which might include updating affected products, work packages, plans and registers
Or
- Create an exception plan for approval by the project board
In both cases, the project manager will update the issue register with the decision and inform all interested parties
Implementation of the corrective action must ensure that baselined products are updated in a controlled manner and with appropriate authorizations
If a product that has been baselined is to be changed, the new version should be created to accommodate the change and the baseline version is kept unchanged
Old baseline versions should be archived where possible and not discarded
After an issue has been closed, the project manager should update the issue register
Tolerance should not be used to fund requests for change
Become a PRINCE2 Practitioner NOW!
This course is DEPRECATED
The old PRINCE2 6th Edition Foundation and Practitioner syllabus was upgraded in 2024. Check out the brand NEW PRINCE2 7th Edition Masterclass, covering all the current syllabus, training material and online exam benefits HERE
Your Route To PRINCE2 6th Edition Practitioner
Study PRINCE2 6 Foundation and Practitioner Exams with our famous on-line course with streaming HD Video Lessons, study guides and mock exams. In the last fifteen years we have had 6,000+ Academy students successfully transform their careers as PRINCE2 Practitioners.
