Every project involves change. For example, the users or customer might alter their quality expectations or requirements, while the changing environment of the project may entail further changes within the project itself.
The Change theme aims to develop a reliable change management approach, to enable the project manager to deal with each potential change, while maintaining the stability and security of the project.
In PRINCE2, a project issue is any relevant event which has happened, wasn’t planned, and requires management action. To manage issues effectively, it is crucial to develop a rigorous and consistent approach to the identification and assessment of project issues.
According to PRINCE2, project issues can be categorized as follows:
- A request for change is a request to change a baseline, e.g., a request to change the requirements for a product
- An off-specification identifies a current requirement that the project either does not fulfil, or is forecasted not to fulfil
- A problem/concern is essentially anything else that either needs to be resolved by the project manager or needs to be escalated to a higher level of management.
Issue register and issue report
The issue register records all project issues that are to be managed in a formal manner. It is created during the initiation stage and maintained by the project manager or project support. It contains information such as a description of the Issue, the individuals involved in dealing with it, and an evaluation of its priority and severity.
Each entry in the issue register has its own issue report, which offers up-to-date information about the issue’s status at any given point in the issue management process, including its impact on the project and on plans.
Issue and change control procedure
The PRINCE2 procedure for dealing with each project issue involves five steps:
- Enter a project issue which is to be managed formally into the issue register otherwise enter it into the Daily Log (if it is to be managed informally)
- Create an issue report if the issue is to be managed formally.
- Conduct an impact assessment of the changes that will be caused to other aspects of the project, such as schedule, scope, and project risk profile.
- Evaluate alternatives for dealing with the project issue
- Recommended appropriate actions to address the project issue.
- The project manager either resolves the project issue or escalates it to the project board (or the change authority)
- Escalation involves either an issue report or an exception report, depending on whether the action proposed would trigger an exception by exceeding tolerances.
- Following the decision, the project manager either initiates the recommended decision by taking corrective action, or produces an exception plan if requested by the project board (or change authority)
- The project manager updates either the daily log, or the issue register and issue report, and informs the appropriate parties regarding the decision.
To ensure that the project can afford to make changes without threatening project or stage cost tolerances, it is crucial to designate a separate change budget. This can be calculated by anticipating what level of change is probable, e.g., by considering whether the users or customers are uncertain about requirements.
The project board has ultimate authority over whether to make changes on a project. To avoid involving the project board unnecessarily, however, a change authority might be appointed.
The change authority generally constitutes users from the customer organization and possibly other stakeholders, who are given the authority to determine how the change budget is to be spent. This avoids lengthy and inefficient decision making about changes to the project.
However, if a proposed change would exceed the change budget, or indeed any other tolerance, such as the project schedule, then the change must be escalated to the project board.
Both the change budget and the change authority are established during the initiation stage.
Every time that a baseline is changed, a new version of the associated product (or product component, or even set of products) is created. In order to protect and control these multiple versions, the project manager must ensure adequate configuration management.
The project manager writes the change control approach during the initiation stage. This entails detailing the following:
- Configuration management
- tools and techniques
- roles and responsibilities
- Issue and change control
- Reporting requirements for both procedures
- Priority/severity scales for project issues
- Contents and format of configuration item records.
A product (or product component/set) that is subject to configuration management is known as a configuration item. Each configuration item will have a configuration item record, which documents its history, current version number and status, its location, copy-holders, related products and any related issues and risks.