Issues

Any expectation different from the baselines is called an issue in PRINCE2. So, the following are all examples of issues in PRINCE2 terminology:

• You build something, and it ends up different from what it was supposed to be.
• Someone becomes president in a different country and does something that increases the price of the material you have to buy for the project!
• The customer wants you to add something to the project.

Types of issue

There are five types of issues; they are:

• Request for change: It is a proposal for a change to a baselined product, i.e., a product that has already been approved. This could be a product description document for one of the specialist’s products being created by the project.
• Problem/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.
  • Any other issue that the project manager needs to resolve or escalate could be positive or negative.
• Business opportunity: An issue that represents unanticipated positive consequences for the project or user organization.
• External event: An external event is an issue that arises from factors outside the control of the project, such as changes in legislation, market conditions, or supplier actions, that impact the project and require a response or adjustment.
• Off-specification: This is something that was agreed to be done but is not provided by the supplier and/or not forecast to be provided, and therefore, is out of specification or off-specification.

Purpose

The knowledge within the issues practice is to help you identify, assess, and control potential changes to products that have already been approved and baselined. The issues practice is not solely about handling change requests; it also focuses on addressing issues that arise during the project. In fact, it is better to think of the issues practice as providing a unified approach to both issues and change control.

Change is inevitable in any project, and every project needs a clear strategy to identify, assess, and control issues that could lead to changes. This practice offers a structured approach to managing both issues and changes effectively.

Timing

Issue and change control occur throughout the entire lifecycle of the project. The goal is not to prevent changes but to ensure that any changes are agreed upon and approved before they are executed.

Every project requires a configuration management system that tracks products, records when products are approved and baselined, and ensures that the correct versions are used during the project and delivered to the customer.

Issues

An issue is an event relevant to the project that requires project management consideration.

Issues can arise unexpectedly and may impact project objectives, timeline, quality, or cost. Issues can be raised by any team member, stakeholder, or external party at any time during the project. They should be documented in the project log for tracking and resolution. Proper issue management ensures that problems are addressed promptly, minimizing their impact on the project.

Change

A change is defined as a modification to any of the approved products that constitute the project baseline.

This could include changes to deliverables, scope, schedule, or costs. Before a change can be incorporated into the baseline, it must be formally approved by the individual or role with the appropriate authority, such as the project board or change authority. This ensures that changes are properly evaluated for their impact on the project’s objectives and resources.

Project baseline

The project baseline refers to the approved versions of the management products and project products that are subject to change control, including scope, schedule, cost, and quality specifications.

For example, in a software development project, the baseline would include the approved requirements document, project schedule, and budget. Any changes, such as added features or timeline delays, must be reviewed and approved before being incorporated into the baseline.

Effective issue management

The PRINCE2 issue management approach provides a structured framework for identifying, assessing, and controlling issues and changes throughout the project lifecycl and comprises of:

• Baselines: Defines what is subject to change control within the project.
• Issue resolution: Outlines the process for identifying, capturing, assessing, and recommending actions to resolve issues.
• Change control: Describes how changes to the project baseline are managed and controlled.
• Delegating authority for changes: Specifies how authority is allocated from the project board down to enable a responsive yet controlled handling of changes.
• Change budget Refers to the allocated funds set aside in the project plan to cover the cost of changes.

1/5 — baselines

Effective issue management and change control require product baselines. Each time a change is approved, a new version of the product is created. This helps track changes and ensures they are linked to decisions made by the appropriate authority.

The issue management approach depends on the products to be delivered and the planned activities. This approach is typically prepared after defining product descriptions and work packages.

For any project, the management team should determine:

• The level at which products need to be baselined based on their ability to be released, installed, or modified independently.
• How products and versions are identified, using a system that tracks key information like versions, status, and relationships.
• The authorities and process required for approvals and baselining.
• A procedure for managing issues and changes.

It’s good practice to periodically verify that products match their authorized state through reviews or audits, usually at the end of each stage or project.

Baselines may be managed with various systems, with management products maintained as documents and specialist products in dedicated systems. Each system should ensure changes are properly approved and tracked, and the product register in the project log should record all changes to the baseline.

2/5 — issue resolution

PRINCE2 recommends categorizing issues as this helps assess issues and identifies patterns.

• Problem or concern
• External event
• Business opportunity
• Request for change
• Off-specification

When categorizing issues, it’s helpful to check if the issue is actually a risk. Risks are uncertain, and if this is the case, the issue should be transferred to the risk register. Many issues first appear informally in conversations or communications among team members. Problems, concerns, or business opportunities often fall into this category.

Handling problems and concerns requires judgment. If too many are recorded as issues, the team may be overwhelmed by trivial decisions. However, issues should be identified early to resolve them within the project’s tolerances.

External event

External events, such as a supplier going out of business, are beyond the project’s control but can still impact it. These events should be monitored regularly to evaluate their effects and decide on the best response.

Example: If a key supplier goes out of business, it may delay the project or increase costs. The project manager should assess the impact and find alternative suppliers or solutions to minimize disruption.

Business opportunities

Not all issues are negative. In fact, some issues, such as cost savings or the opportunity to use new technology, can have a positive impact on the project.

Example: Suppose a supplier offers a new, more cost-effective software tool that could enhance the project’s functionality. This could result in significant cost savings and improve project outcomes. In this case, the project manager should bring the opportunity to the project board, evaluate the benefits and risks, and decide whether to integrate the new tool into the project.

Recording issues

Issues must be recorded in the issue register. For simple issues, the register may be enough to determine actions. However, complex issues may need an issue report, which should assess the impact and recommend a resolution. All decisions and actions should be documented in the issue register.

If the resolution of an issue results in a change to the project baseline, it must follow the change control process.

3/5 — change control

All projects need a clear approach to control changes to the project baseline. The issue management approach outlines the project’s change control procedure, including how change proposals will be recorded and decided. PRINCE2 categorizes proposals to change a baseline as either a request for change or off-specification.

A request for change must specify the management products to be changed and provide justification. If the change has a cost, it must be funded by the approved change budget or additional funds.

Off-specifications usually occur when a supplier fails to meet quality standards or when a required quality specification is found to be unachievable. In both cases, the discrepancy must be addressed through change control.

If an off-specification is accepted, the project baseline must be updated to reflect the change. Accepted off-specifications, known as concessions, need approval from the project board or delegated authority. If rejected, the project manager and team manager must find a way to resolve the issue, possibly using the change budget or raising an exception report.

If an issue leads to a request for change or off-specification, the issue report should include the details for timely decision-making.

Change control definitions:

• Change control: The process of identifying, assessing, approving, rejecting, or deferring changes that may affect the project baseline.
• Request for change: A proposal to change a baseline.
• Off-specification: A product that fails to meet its quality specifications.
• Concession: An off-specification accepted by the project board without corrective action.

4/5 — delegating change authority

The project board is the ultimate authority for approving changes and off-specifications. However, they can delegate authority to speed up decision-making. Effective delegation balances efficiency with control. Too little delegation can slow progress, while too much may reduce alignment with the project’s goals.

In projects with few expected changes, it may be best for the project board to keep all approval authority. However, in projects with many changes, the board may delegate some decisions.

Example of change authority layers:

• Project manager: Approves minor changes, such as adjusting the schedule for non-critical tasks, without affecting the overall project scope.
• Change authority: Approves moderate changes, like adding a minor feature to the scope, without significantly impacting the project’s budget, timeline, or objectives.
• Project board: Reviews and approves major changes that impact the project’s scope, budget, timeline, or key deliverables.

Most changes will arise at the work package level, so it’s important to delegate authority (to the project manager) to approve these changes. This prevents the need to escalate every decision to the project board. Depending on the project’s size and complexity, authority may be delegated to different levels within the project team, as outlined in the issue management approach.

Issue management documents

The issue and change management approach will be decided in the first stage, during the initiating a project process. this approach can be reviewed at the end of each stage in the managing a stage boundary process.

PRINCE2 has four management products that are used to control issues and changes:

• Issue management approach: This document contains the strategy on how issues and changes will be handled in the project (e.g., how to identify products, how to control products and how to do status accounting and verification).
• Daily log: The project manager uses this log as a diary for all informal information. Formal information is placed in a register (issue or risk register) and documented in the progress practice.
• Issue register: Imagine a spreadsheet to capture and maintain issues (formal). The purpose of the issue register is to log all issue reports raised during the project lifecycle, their current status, and date of closure.
• Issue report: This report describes an issue in detail. The purpose of the issue report is to describe the issue’s impacts on the project baseline and identify ways to resolve the issue or address off-specification and recommend a decision.

Let’s have a closer look at the relationship between the issue management approach and the issues practice.

Issue management approach

The issue management approach document outlines the strategy for handling issues and changes within the project. A fundamental question for the project manager is: What are the existing standards for issue and change control within the organization?

If a programme environment is established, an issue management approach template is typically available. This document should address the following aspects:

• How should products be identified and controlled? (configuration management).
• How are issues and changes handled? (PRINCE2 technique - CARDI).
• What tools will be used to help track issues and product information (e.g., SharePoint, niku clarity, shared drive, a spreadsheet)?
• What data should be kept for each product?
• How often will the project manager consider issue & change control (e.g., once a week, twice a month, etc.)?
• Who will be responsible for what? In other words, what will be the roles & responsibilities? (for example, who has the role of change authority?)
• How are issues and changes prioritized? What scale will be used to prioritize issues?
• What scale will be used for the severity of issues (e.g., 1 to 4, low-med-high…)?
• Which management levels will deal with different severity issues? (for instance, the severity 1 issue could go to the project manager, but severity 3 and 4 have to go to the change authority.)

Similar to other approach documents, the issue management approach is developed during the initiating a project process by the project manager and requires approval from the project board.

Prioritizing issues

Effectively prioritizing change requests is crucial in project management. PRINCE2 utilizes the MoSCoW technique to assist in this process. MoSCoW stands for must have, should have, could have, and won’t have for now.

• Must have: Essential changes critical to the project’s success; their absence would jeopardize project objectives. For example, a fundamental feature without which the product cannot function as intended.
• Should have: Important changes that, if omitted, would weaken the business case. The project would still meet its objectives, but these changes add significant value.
• Could have: Desirable changes that are not essential. Their absence does not impact the project’s success, but they enhance user satisfaction.
• Won’t have for now: Changes that are neither essential nor important in the current timeframe. They can be deferred to a later stage without affecting the project’s overall success.

To assist requesters in understanding these priority levels, consider asking the following questions:

• Must have: Will the end product function if this change is not implemented? (expected answer: Yes)
• Should have: Does this change impact the business case? (expected answer: Yes)
• Could have: Does this change impact the business case? (expected answer: No)
• Won’t have for now: Is this change essential or important at this time? (expected answer: No)

For more detailed guidance on prioritizing issues, refer to the PRINCE2 “plans” practice, specifically section 7.3.3.1 on prioritizing.

Severity

Severity refers to the level of impact an issue has on the project’s objectives. It is crucial to define how issues are rated in the issue management approach to ensure a consistent and structured approach to managing problems that arise during the project.

Example: You can use a scale from 1 to 5, or descriptive terms such as minor, significant, major, and critical to assess the severity of an issue.

The severity level of an issue can be linked to specific roles within the project to ensure the appropriate individual or group addresses the issue:

• Severity minor → project support
• Severity normal → project manager
• Severity significant → change authority
• Severity major → project board
• Severity critical → program management (e.g., project out of tolerance)

Change authority

The change authority is the person or group responsible for considering requests for change and off-specifications. While the project board holds the ultimate responsibility for approving changes, they can either manage this themselves (which is common in projects with few expected changes) or delegate this task to others. In larger projects where numerous changes are anticipated, delegating authority to another person or group ensures the project board isn’t overwhelmed and can focus on higher-level decisions.

The person or group selected for this role depends on the project’s size, value, change budget, and the amount of money the change authority approves for each change. This could be the executive’s secretary or a member of the project board for smaller projects. It could be a financial officer or another competent individual with the necessary expertise in larger projects.

Change budget

The change authority is typically allocated a change budget, a sum of money agreed upon by both the customer and supplier to fund requests for change. It is recommended that a change budget be set for each project. The project board may impose limits on the cost of a single change or the total amount that can be spent at any given stage.

The change control process is a vital tool for the project manager. For example, when senior members of the organization request changes, the project manager may face pressure to agree, potentially jeopardizing the project. Instead of directly rejecting the request, the project manager can say, “Of course. Here’s our change request process, and I’d be happy to help you complete the change request form.” this approach ensures the project manager remains helpful and professional while properly routing the request to the change authority for evaluation.

PRINCE2 technique for issue management

The PRINCE2 technique for issue management is encapsulated in the issue and change control procedure. This process addresses a range of issues, including requests for change, off-specifications, and other concerns or problems. The procedure consists of five key steps, which can be referred to as CARDI:

1. Capture: Identify the type of issue (formal or informal) and classify it into one of the three categories (e.g., change request, off-specification, or other).
2. Assess: Evaluate the impact of the issue on the project’s objectives. This step involves understanding how the issue will affect the project’s scope, time, cost, or quality.
3. Recommend: Propose possible actions to address the issue. Identify available options, evaluate their impact, and recommend the best course of action.
4. Decide: A designated decision-maker (e.g., the project manager, change authority, or project board) will approve, reject, or modify the proposed solution based on its merits and alignment with the project objectives.
5. Implement: Once approved, implement the recommended solution. This includes taking corrective actions and ensuring that the issue is resolved in accordance with the project’s goals.

Let’s take a closer look at the steps of this technique.

Step 1/5 — capturing issues

Issues can arise throughout the project, and the project manager must ensure that the process for documenting these issues into formal reports is efficient, with minimal administrative overhead.

Both new and ongoing issues listed in the issue register should be regularly reviewed in all project meetings, including status updates and stage boundary reviews.

Step 2/5 — assessing issues

Issue assessment should be a collaborative process involving input from project team members and stakeholders. Effective facilitation by the project manager is crucial in ensuring this process runs smoothly. When reviewing issues, the key questions to address are:

• What type of issue is it (problem, concern, external event, business opportunity, change request, or off-specification)?
• Does it affect the project?, if yes, how?

Not all issues require a detailed assessment or a change request. Major issues that impact the project baseline should be assessed in relation to the overall project plan, tolerances, business case, and other work packages. Where possible, present the project board with multiple response options, considering trade-offs between requirements and tolerances.

Not all issues require changes. In some cases, rejecting an issue and taking no action is the best response, especially for low-value change requests.

Step 3/5 — recommending resolution

The project manager is responsible for making recommendations on how to resolve the issue based on the assessment. This recommendation, whether to approve or reject a change request, should clearly outline the consequences of both options.

To ensure transparency and proper record-keeping, the recommendation, along with any supporting rationale and the decision-making process, should be documented in the issue register or change log. This documentation records decisions, ensures accountability, and provides a reference for future review if the issue reappears or if there are challenges in implementing the resolution.

Step 4/5 — deciding on changes

This is an overview of the typical responses to requests for change.

• Approve: The cost of making the change can be funded through:
  • Use of the change budget
  • Reducing the scope of other project elements
  • Requesting additional funds.
• Reject: will the business justification still be satisfied? Will expected benefits be realized if the change is rejected?
• Ask for an exception plan: Appropriate if the issue stems from overly stringent quality specifications or acceptance criteria and can be resolved by adjusting approved tolerances.
• Request more information: Defers the decision, suitable if the impacts of approving or rejecting the change are complex.

The following is an overview of the typical response requests for off-specification (A product that will not meet its quality specifications):

• Accept: What is the impact on business justification and expected benefits? The project baseline is updated, and the off-specification is recorded as a concession.
• Reject: How can the issue be resolved?
  • Use the change budget.
  • Use an exception plan.
  • Use a contractual remedy (if a supplier is responsible).

Off-specification example: In a project to develop a healthcare app, the specification required full encryption of patient data. However, it’s found that only part of the data is encrypted, not meeting the agreed security standards.

This is an off-specification, as the app doesn’t meet the original requirements. The issue could be accepted with a concession or rejected, depending on its impact on the project’s business case.

Step 5/5 — implementing changes

Once a change request or off-specification is approved, the project manager is responsible for ensuring it is recorded in the project log (issue register) and updated in the relevant management products. The project support team may assist by maintaining and organizing these records. Different systems can be used to manage these products, but each system must ensure proper configuration control by keeping a record of changes and archiving outdated versions.

Roles and responsibilities

• Business layer
  • Provide policies, standards, or procedures for issue management and change control.
  • Approve the project-level change budget (if used), respond to requests for advice, and handle escalated issues from the project executive.
• Project executive
  • Decide if a project-level change budget is needed, determine the amount, and set the stage-level change budget.
  • Determine if delegated authority to approve changes is necessary.
  • Approve the issue management approach and ensure it aligns with project objectives.
  • During the project, make decisions on escalated issues, focusing on maintaining the business justification.
• Senior user
  • Respond to requests for advice and handle escalated issues, focusing on safeguarding expected benefits.
  • Agree on the issue management approach.
• Senior supplier
  • Respond to requests for advice and handle escalated issues, focusing on protecting the integrity of the overall solution.
  • Agree on the issue management approach.
• Project manager
  • Consult with stakeholders to prepare and maintain the issue management approach, defining product baselining levels.
  • Manage the issue and change control procedure, with support from project support where needed.
  • Ensure team managers implement the agreed issue and change control procedures in their work packages.
  • Implement corrective actions as necessary and maintain the appropriate documents.
• Team manager
  • Implement the issue and change control procedures outlined in their work package description.
  • Implement corrective actions when needed, as instructed by the project manager.
• Project assurance
  • Advise the project manager on the issue management approach.
  • Confirm compliance with business policies to the project board.
  • Provide advice on assessing and resolving issues.
  • Review issue and exception reports for the project board and project manager when requested.
• Project support
  • Administer change control and issue procedures by maintaining the issue register and project baseline.
  • Assisting the project manager in preparing issue reports.
  • Support the project management team with the application of risk management procedures.

—o—

Written by Frank Turley.

If you have questions or doubts after using this wiki, you can ask for help on the Facebook or LinkedIn study groups.