The Issues Practice in PRINCE2 7 serves a fundamental purpose of establishing and maintaining a systematic procedure for capturing, assessing, and managing any matters that arise during the project lifecycle that require formal consideration and decision-making. This practice ensures that all concerns, problems, requests for change, and off-specification items are handled in a controlled and consistent manner throughout the project duration.

The primary purpose is to provide a structured approach for identifying and recording issues as they emerge, ensuring nothing falls through the cracks or gets overlooked. By implementing this practice, project teams can evaluate each issue's potential impact on the project's objectives, timelines, costs, quality, and overall business case viability.

Another key purpose is to facilitate informed decision-making at appropriate management levels. Issues are escalated according to their severity and the authority required to resolve them, ensuring that the right people make decisions about matters affecting project success. This supports effective governance and maintains clear accountability.

The practice also aims to track issue resolution progress, ensuring that identified matters receive appropriate attention and are resolved within acceptable timeframes. This tracking capability provides transparency and allows stakeholders to understand the current status of outstanding concerns.

Furthermore, the Issues Practice purpose extends to maintaining a historical record of all issues and their resolutions. This documentation proves valuable for lessons learned, audit trails, and future project reference. It enables organizations to identify patterns and recurring problems that might benefit from process improvements.

The practice integrates closely with other PRINCE2 practices, particularly Change Control and Risk Management, as issues often relate to changes or may identify new risks. By fulfilling its purpose effectively, the Issues Practice contributes significantly to maintaining project control and increasing the likelihood of successful project delivery within agreed parameters.

The Issue Management Approach in PRINCE2 7 is a fundamental component of the Issues practice that defines how issues will be handled throughout a project's lifecycle. This approach establishes the procedures, responsibilities, and techniques for identifying, assessing, and resolving issues that arise during project execution.\n\nAn issue in PRINCE2 is defined as a relevant event that was not planned and requires management action. Issues can be categorized into three types: a request for change (proposal to modify a baseline), an off-specification (something that should be provided but is not meeting requirements), and a problem or concern (any other issue requiring attention).\n\nThe Issue Management Approach typically documents several key elements. First, it outlines the procedure for capturing and logging issues in the Issue Register, ensuring all issues are formally recorded with relevant details such as date raised, author, description, and priority. Second, it defines the assessment criteria and methods for evaluating the severity and impact of each issue on project objectives.\n\nThird, the approach specifies escalation paths and decision-making authorities. Some issues can be resolved at the Project Manager level, while others may need escalation to the Project Board or corporate management depending on their impact on tolerances and project boundaries.\n\nFourth, it establishes timescales for issue handling, ensuring issues are addressed within appropriate timeframes based on their urgency and priority. The approach also defines how issues relate to other PRINCE2 practices, particularly Risk and Change Control.\n\nThe Project Manager is responsible for maintaining the Issue Register and implementing the Issue Management Approach. Regular issue reviews ensure that outstanding matters are progressed and closed when resolved. Effective issue management contributes to project success by ensuring problems are addressed systematically rather than being overlooked or handled inconsistently across the project team.

The Issue Register is a fundamental management product within PRINCE2 7 that serves as the central repository for capturing, tracking, and managing all formal issues raised throughout a project's lifecycle. It functions as a comprehensive log that ensures no concern or problem goes unaddressed during project execution.

The Issue Register captures three main types of issues: requests for change (proposals to modify project baselines), off-specifications (situations where a product does not meet its agreed specification), and problems or concerns (any other matters requiring management attention). Each entry in the register receives a unique identifier for tracking purposes.

Key information recorded in the Issue Register includes the issue type, date raised, author, priority, severity, current status, and closure date. The register also documents the issue description, impact analysis, recommended actions, and the decision made regarding resolution. This structured approach ensures consistent handling of all issues across the project.

The Project Manager maintains responsibility for the Issue Register, regularly reviewing entries and escalating matters to the Project Board when issues exceed their delegated authority. The register supports effective communication between team members and stakeholders by providing a transparent view of ongoing concerns and their resolution progress.

During stage boundaries and project closure, the Issue Register is reviewed to ensure all matters have been appropriately addressed or transferred to operational teams for ongoing management. Open issues may influence decisions about project continuation or require inclusion in the lessons learned documentation.

The Issue Register integrates with other PRINCE2 management products, particularly the Risk Register when issues have risk implications, and the Configuration Management system when changes affect product baselines. This integration ensures comprehensive project control and supports informed decision-making throughout the project lifecycle. Effective use of the Issue Register contributes to successful project delivery by maintaining visibility and control over matters requiring attention.

An Issue Report is a formal document used in PRINCE2 7 to capture and manage any concern, problem, or change that arises during a project. It serves as the primary mechanism for recording issues that require assessment and decision-making by appropriate project management levels.

The Issue Report contains essential information including a unique identifier, the type of issue (whether it is a request for change, an off-specification, or a problem/concern), a detailed description of the issue, its impact assessment, priority rating, and recommended actions. It also tracks the status of the issue throughout its lifecycle.

There are three categories of issues in PRINCE2. First, a Request for Change represents a proposal to modify a baseline product, such as adding new features or altering existing functionality. Second, an Off-Specification occurs when a product fails to meet its specified requirements or when there is a forecast that it will not meet them. Third, a Problem or Concern covers any other matter that the Project Manager needs to address or escalate.

The Issue Report follows a structured process. When an issue is identified, it is logged and given a unique reference number. The Project Manager then examines the issue, assesses its severity and impact on the project objectives, and determines the appropriate response. Depending on the nature and significance of the issue, it may be handled at the Project Manager level or escalated to the Project Board for decision.

The Issue Report provides an audit trail of all issues and their resolution, ensuring transparency and accountability. It helps maintain control over project changes and problems while ensuring that stakeholders remain informed about matters affecting the project. This document is closely linked to the Issue Register, which provides a summary log of all issues raised during the project.

In PRINCE2 7, an issue is formally defined as a relevant event that has happened, was not planned, and requires management action. Issues are distinct from risks in that risks are uncertain future events, while issues are events that have already occurred or are currently happening and need to be addressed.

The Issues Practice in PRINCE2 7 provides a structured approach to capturing, assessing, and resolving these unplanned events throughout the project lifecycle. Issues can arise from various sources including team members, stakeholders, customers, or external parties, and they must be properly documented and managed to ensure project success.

There are three types of issues recognised in PRINCE2:

1. Request for Change - A proposal to modify a baseline product, such as adding new features or altering specifications that were previously agreed upon.

2. Off-specification - A situation where a product does not meet its agreed specification, or where there is a forecast that it will not meet the specification. This represents a deviation from what was promised.

3. Problem or Concern - Any other type of issue that the Project Manager needs to resolve or escalate, which does not fall into the above categories.

Each issue must be captured in an Issue Register, which serves as a central repository for tracking all issues throughout the project. The Issue Register records details such as the issue type, description, priority, severity, status, and the individual responsible for resolution.

The Project Manager is responsible for assessing each issue, determining its impact on project objectives, and deciding on appropriate action. Depending on the severity and authority levels, issues may be resolved at the project level or escalated to the Project Board for decision-making. Proper issue management ensures that unplanned events are handled efficiently, minimising negative impacts on time, cost, quality, and scope.

In PRINCE2 7, the Issues practice deals with handling events that were not planned and require management attention. There are three main types of issues that can occur during a project.

**1. Request for Change (RFC)**
A Request for Change is a proposal to modify a baseline product, such as a deliverable that has already been approved. This could include changes to scope, requirements, or specifications. RFCs must be formally assessed for their impact on time, cost, quality, benefits, and risk before any decision is made. The change authority evaluates whether the change should be approved, rejected, or deferred.

**2. Off-Specification**
An off-specification occurs when a product does not meet its agreed specification or when it is forecast that it will fail to meet the specification. This represents a deviation from what was promised in the product description. Off-specifications need to be assessed to determine whether the product can be accepted as-is, whether corrective action is needed, or whether a concession should be granted to accept the non-conforming product.

**3. Problem or Concern**
This category covers any other issue that the Project Manager needs to resolve or escalate. Problems and concerns might include resource conflicts, stakeholder disagreements, external factors affecting the project, or any situation requiring management attention that does not fall into the other two categories.

**Managing Issues**
All issues should be captured in the Issue Register, which tracks their status, priority, and resolution. The severity and impact of each issue determines whether it can be handled at the Project Manager level or needs to be escalated to the Project Board. Effective issue management ensures that problems are addressed promptly and decisions are made with full understanding of consequences, keeping the project on track toward successful delivery.

A Request for Change (RFC) is a formal proposal to modify any aspect of a project that has been baselined or approved. In PRINCE2 7, the Issues Practice provides a structured approach to handling such requests throughout the project lifecycle.

When stakeholders identify a need to alter project deliverables, scope, timelines, or other controlled aspects, they submit a Request for Change. This differs from other issue types like off-specifications (which deal with deviations from agreed specifications) or problems and concerns (which address general project difficulties).

The RFC process begins when someone identifies a desired modification. This request is then captured, logged, and assessed for its potential impact on the project. The assessment examines how the proposed change would affect time, cost, quality, scope, benefits, and risks. This analysis provides decision-makers with the information needed to determine whether the change should be approved, rejected, or deferred.

Authority levels for approving changes are established during project initiation. Minor changes might be approved by the Project Manager within defined tolerances, while significant changes require escalation to the Project Board or even higher organizational levels. This hierarchy ensures appropriate governance while maintaining project momentum.

Once a decision is made, the outcome is communicated to relevant parties and documented in the Issue Register. Approved changes lead to updates in project plans, product descriptions, and other affected documentation. The change is then implemented and tracked to ensure successful integration.

Effective RFC management helps maintain project control by ensuring modifications are properly evaluated before implementation. It prevents scope creep, manages stakeholder expectations, and maintains alignment between project outputs and business needs. The formal process creates an audit trail demonstrating how and why project changes occurred, supporting transparency and accountability throughout the project journey.

In PRINCE2 7, an Off-Specification is a specific type of issue that occurs when a product or deliverable fails to meet its agreed specification or quality criteria. It represents a situation where something that should have been provided by the project is either missing entirely or does not conform to the requirements outlined in the Product Description.

Off-Specifications are formally tracked within the Issues Practice, which provides a systematic approach to capturing, assessing, and resolving problems that arise during project delivery. When an Off-Specification is identified, it must be logged in the Issue Register with all relevant details including its description, impact assessment, and proposed resolution options.

There are several ways an Off-Specification might occur. A deliverable could be incomplete, meaning certain features or components were not included. Alternatively, the product might be complete but fail to meet the quality standards defined in its Product Description. It could also represent functionality that was promised but not delivered.

When handling an Off-Specification, the Project Manager must assess its severity and determine the appropriate course of action. Options include requesting a concession from the relevant authority, which allows the project to continue with the non-conforming product, or taking corrective action to bring the product back into specification.

The authority to approve Off-Specifications depends on the tolerance levels set for the project. If the deviation falls within the Project Managers authority, they can make decisions themselves. However, if it exceeds their tolerance, the matter must be escalated to the Project Board through an Exception Report.

Proper management of Off-Specifications is essential for maintaining product quality and stakeholder confidence. By addressing these issues transparently and following established procedures, projects can manage deviations effectively while keeping all parties informed of any compromises to the original requirements.

In PRINCE2 7, a Problem or Concern is one of the three types of issues that can be raised during a project, alongside Request for Change and Off-Specification. Understanding this classification is essential for effective issue management within the Issues practice.

A Problem or Concern refers to any matter that the Project Manager needs to address or escalate but does not fall into the categories of requesting a change to the baseline or identifying something that deviates from agreed specifications. These are typically worries, queries, or situations that could potentially impact the project if left unaddressed.

Examples of Problems or Concerns include resource availability questions, potential risks that have not yet materialized, stakeholder relationship difficulties, communication challenges, or uncertainties about how to proceed with certain aspects of the project. They represent situations where clarity, guidance, or action is needed to maintain project momentum and health.

When a Problem or Concern is identified, it should be captured in the Issue Register, which serves as a central repository for all issues requiring attention. The Project Manager must assess each Problem or Concern to determine its severity and the appropriate response. Some may be resolved at the Project Manager level, while others may require escalation to the Project Board for decision-making.

The key difference between a Problem or Concern and other issue types is that it does not necessarily require a formal change to project baselines or products. Instead, it calls for investigation, discussion, and potentially advisory input from relevant stakeholders or authorities.

Effective handling of Problems and Concerns demonstrates good project governance and helps prevent minor issues from escalating into major threats. By maintaining vigilance and addressing these matters promptly through the Issues practice, project teams can sustain stakeholder confidence and keep the project on track toward successful delivery.

A Business Opportunity Issue in PRINCE2 7 is a type of issue that represents a potential benefit or advantage that was not originally planned or anticipated when the project was initiated. Unlike problems or concerns that need resolution, a business opportunity is a positive development that could enhance the project's value, scope, or outcomes if properly pursued and managed.

Within the Issues Practice of PRINCE2 7, business opportunities are formally captured and assessed through the issue management procedure. When someone identifies a potential opportunity, it is logged in the Issue Register with appropriate details including its description, potential impact, and recommended actions.

The key characteristics of a Business Opportunity Issue include: it represents something beneficial rather than detrimental to the project; it typically requires a change to the project baseline to be realised; it needs proper evaluation to determine if pursuing it aligns with the business case; and it must be assessed against the project's tolerances and constraints.

When a business opportunity is identified, the Project Manager evaluates its potential value against the cost and effort required to implement it. If the opportunity falls within the Project Manager's delegated authority, they may approve it. However, if implementing the opportunity would exceed stage or project tolerances, it must be escalated to the Project Board through an Exception Report or included in a request for change.

The Project Board ultimately decides whether to pursue significant business opportunities by considering factors such as alignment with corporate strategy, return on investment, impact on project timelines, and resource availability. This ensures that valuable opportunities are not missed while maintaining appropriate governance and control over project changes. Proper management of business opportunities demonstrates PRINCE2's flexibility in adapting to changing circumstances while preserving project integrity.

A Project Baseline in PRINCE2 7 represents the approved and agreed-upon reference points against which project performance is measured throughout its lifecycle. It serves as the foundation for monitoring and controlling the project effectively.

The baseline encompasses several critical elements including scope, time, cost, quality, benefits, and risk parameters that have been formally approved at the start of a stage or the project itself. These baselines are documented within the Project Initiation Documentation (PID) and Stage Plans, providing a clear benchmark for comparison.

When managing issues within PRINCE2 7, the project baseline becomes essential for assessing the impact of proposed changes or problems. The Issues Practice requires that any deviation from the established baseline be properly evaluated, documented, and escalated through appropriate channels when tolerances are exceeded.

The Project Board sets tolerances around these baselines, allowing the Project Manager operational flexibility within defined limits. Should an issue threaten to push performance beyond these tolerances, an exception report must be raised to the Project Board for decision-making.

Baselines are not static throughout the entire project. They can be formally revised through the change control process when approved changes are incorporated. This ensures that the reference point remains relevant and accurate while maintaining proper governance and traceability of all modifications.

Key baseline documents include the Project Plan, Stage Plans, Work Packages, and the Benefits Management Approach. Each provides specific benchmarks for different aspects of project delivery.

The relationship between issues and baselines is fundamental to PRINCE2 7 governance. Every issue raised must be assessed against current baselines to determine its potential impact on project objectives. This structured approach ensures that decisions are made with full awareness of consequences and that the project remains aligned with its original business justification while adapting to necessary changes through controlled processes.

Change Control is a fundamental aspect of the Issues practice in PRINCE2 7, providing a systematic approach to managing modifications to project baselines. It ensures that all changes are properly evaluated, authorized, and implemented in a controlled manner, protecting the project from uncontrolled scope creep and maintaining product integrity.

The Change Control process begins when a change request is raised, typically through a Request for Change (RFC). This formal document captures the details of the proposed modification, including its rationale, impact assessment, and potential benefits. All change requests must be logged in the Issues Register for tracking and management purposes.

Once a change request is submitted, it undergoes a thorough impact analysis. This assessment examines how the proposed change affects the project's time, cost, quality, scope, benefits, and risks. The analysis provides decision-makers with the information needed to make informed choices about whether to approve, reject, or defer the change.

The Project Board typically holds the authority to approve significant changes, though they may delegate minor change decisions to the Project Manager through defined tolerances or a Change Authority. The Change Authority concept allows for more efficient handling of changes by empowering designated individuals or groups to make decisions within specified parameters.

PRINCE2 7 emphasizes maintaining a Change Budget, which is a sum of money set aside to fund approved changes. This approach prevents projects from constantly returning to corporate management for additional funding for minor modifications.

Effective Change Control maintains traceability throughout the project lifecycle, ensuring that all decisions are documented and that the impact of approved changes is reflected in updated plans and baselines. This practice supports good governance by providing transparency and accountability in how project modifications are handled, ultimately contributing to successful project delivery.

Baseline Management is a fundamental concept within PRINCE2 7 that relates to how projects handle changes and maintain control over key project documents and plans. In the context of Issues Practice, Baseline Management provides a reference point against which all proposed changes can be assessed and measured.

A baseline represents an approved version of a product, plan, or document that serves as a fixed reference point throughout the project lifecycle. Once established, baselines cannot be modified except through formal change control procedures. This ensures that any alterations to the project scope, schedule, costs, or quality requirements are properly evaluated, documented, and approved before implementation.

Within Issues Practice, Baseline Management plays a crucial role in managing requests for change. When an issue is raised that could potentially impact the project, the Project Manager must assess how this change would affect the established baselines. This comparison helps stakeholders understand the true impact of implementing any proposed modification.

Key baselines typically include the Project Initiation Documentation, Stage Plans, Product Descriptions, and cost estimates. These documents define what was originally agreed upon and provide clarity when disputes or uncertainties arise during project execution.

The benefits of effective Baseline Management include improved decision-making through clear impact assessment, better stakeholder communication regarding project status, enhanced traceability of changes throughout the project, and stronger governance through documented approval processes.

PRINCE2 7 emphasizes that baselines should be stored securely and version controlled appropriately. The Project Board retains authority over significant baseline changes, while the Project Manager may handle minor adjustments within defined tolerances.

By maintaining robust Baseline Management practices, project teams can ensure that changes are handled systematically, preventing scope creep and maintaining alignment between stakeholder expectations and project delivery objectives.

Issue Resolution is a fundamental component of the Issues Practice in PRINCE2 7, providing a structured approach to handling problems that arise during project execution. An issue is defined as any relevant event that has happened, was not planned, and requires management action. Issues can include problems, concerns, changes to requirements, or any other matter that needs addressing.

The Issue Resolution process begins with capturing and logging issues in an Issue Register, which serves as a central repository for tracking all identified issues throughout the project lifecycle. Each issue is assigned a unique identifier, categorized by type, and assessed for its potential impact on project objectives including time, cost, quality, scope, benefits, and risk.

Once an issue is logged, it undergoes analysis to determine the appropriate response. The Project Manager evaluates the severity and urgency of each issue, considering various resolution options. These options might include taking corrective action within existing tolerances, escalating to the Project Board when tolerances are threatened, or implementing approved changes through formal change control procedures.

The resolution approach depends on the issue type and its potential consequences. Some issues can be resolved at the Project Manager level, while others require escalation through Exception Reports when they exceed delegated authority. The Project Board then decides on the appropriate course of action, which may involve approving additional resources, accepting modified outcomes, or implementing alternative solutions.

Effective issue resolution requires clear escalation paths, defined roles and responsibilities, and regular communication with stakeholders. The process ensures that problems are addressed promptly and systematically, preventing minor concerns from escalating into major project threats. Throughout the resolution process, all actions and decisions are documented, maintaining an audit trail that supports project governance and enables lessons to be learned for future projects.

In PRINCE2 7, delegating authority for changes is a fundamental aspect of the Issues practice that enables efficient project governance while maintaining appropriate control levels. This delegation establishes clear boundaries for decision-making across different management levels within the project hierarchy.

The Project Board holds ultimate authority for approving changes but recognizes that involving them in every minor change would be inefficient and could delay project progress. Therefore, they establish change authority limits that define who can approve different types of changes based on their impact and cost.

Change authority can be delegated to several levels. The Project Board may retain authority for high-impact changes that significantly affect the business case, major scope alterations, or changes exceeding defined cost thresholds. The Project Manager typically receives authority to approve changes within specified tolerances, usually covering moderate impacts to time, cost, or scope that remain within stage boundaries.

For smaller changes, authority may be delegated further to Team Managers or even a dedicated Change Authority role. This person or group handles routine changes that fall within predefined parameters, ensuring quick decisions for low-risk modifications.

The change budget is a key mechanism supporting this delegation. The Project Board allocates funds specifically for approved changes, and different authority levels have access to portions of this budget corresponding to their decision-making scope.

Clear documentation of these delegation levels appears in the Change Control Approach, which defines thresholds, approval routes, and escalation procedures. This ensures everyone understands their authority boundaries and knows when to escalate decisions to higher levels.

Effective delegation balances two competing needs: maintaining control over significant changes while avoiding bureaucratic bottlenecks for minor modifications. This approach keeps projects moving efficiently while ensuring appropriate oversight of decisions that could materially impact project success.

A Change Budget in PRINCE2 7 is a sum of money allocated within the project budget specifically to fund the implementation of approved changes to the project scope, requirements, or deliverables. This budget is established during project initiation and is held separately from the main project budget to provide flexibility when handling change requests throughout the project lifecycle.

The Change Budget serves several important purposes within the Issues Practice. First, it enables the Project Manager to respond to approved changes in a timely manner by having pre-allocated funds available. This prevents delays that would occur if funding approval was required each time a change was needed. Second, it provides a controlled mechanism for managing scope changes while maintaining financial governance.

The Project Board typically delegates authority to the Project Manager to spend from the Change Budget up to specified tolerance limits. When a change request is raised through the issue and change control procedure, the Project Manager can approve changes that fall within their delegated authority and fund them from this budget. Changes exceeding the delegated limits must be escalated to the Project Board for decision.

The Change Budget is closely linked to the Issues Practice because change requests are a type of issue that requires assessment, decision-making, and potentially funding for implementation. When evaluating a change request, the impact assessment should include the cost implications and whether sufficient Change Budget remains available.

Not all projects will have a Change Budget established. In some cases, particularly smaller projects or those with very stable requirements, the organization may decide that changes will be funded through exception procedures or by adjusting the overall project budget. However, for projects where changes are anticipated, establishing a Change Budget provides a pragmatic approach to managing the financial aspects of change control while maintaining appropriate governance and oversight throughout the project.

The Issue and Change Control Procedure in PRINCE2 7 is a fundamental component of the Issues practice that provides a structured approach for managing all types of issues throughout a project lifecycle. This procedure ensures that problems, concerns, and proposed changes are handled systematically and appropriately.

The procedure encompasses five key steps:

1. **Capture**: When an issue arises, it must be formally recorded in the Issue Register. This includes documenting the issue type, description, priority, and severity. Issues can originate from team members, stakeholders, or through routine project activities.

2. **Assess**: Each issue undergoes thorough analysis to understand its impact on project objectives, including time, cost, quality, scope, benefits, and risk. The assessment determines the appropriate response and identifies who has authority to make decisions.

3. **Propose**: Based on the assessment, one or more response options are developed. For change requests, this might involve creating an Exception Plan or adjusting tolerances. The proposal should outline implications and recommendations.

4. **Decide**: The appropriate authority makes a decision based on the proposal. This could be the Project Manager, Project Board, or Change Authority depending on the impact level and delegated tolerances.

5. **Implement**: Once approved, the agreed actions are executed, progress is monitored, and the Issue Register is updated to reflect the current status and resolution.

PRINCE2 7 recognizes three issue types: requests for change (modifications to baselines), off-specifications (products not meeting requirements), and problems or concerns (other matters requiring attention).

Effective issue and change control maintains project integrity by preventing scope creep, ensuring stakeholder alignment, and preserving the business case validity. The procedure provides transparency and accountability while enabling projects to adapt to legitimate needs throughout their duration.

In PRINCE2 7, the Issues Practice and Principles share a fundamental relationship that ensures effective project management through structured problem-solving aligned with core governance concepts. Issues represent any relevant events that require management attention during a project, including problems, concerns, requests for change, and off-specifications. The relationship between Issues and PRINCE2 Principles creates a cohesive framework for addressing challenges. The principle of Continued Business Justification connects to issues management by requiring that all issues be evaluated against their impact on the Business Case. When an issue arises, project teams must assess whether resolving it maintains project viability. Managing by Exception ties closely to issue handling through defined tolerances. Issues that exceed tolerance levels must be escalated appropriately, ensuring proper authority levels make decisions. This creates clear boundaries for decision-making. Focus on Products ensures that issue resolution considers the impact on project deliverables and their quality requirements. Each issue must be evaluated for how it affects the agreed products and specifications. Learn from Experience encourages teams to capture lessons from issue resolution, building organizational knowledge that prevents similar problems in future projects. Define Roles and Responsibilities ensures clear accountability for issue management, with specific individuals authorized to make decisions at appropriate levels. Manage by Stages enables structured issue assessment at stage boundaries, allowing for comprehensive review of outstanding issues before proceeding. Tailor to the Project Environment recognizes that issue management processes should be scaled appropriately based on project complexity, size, and risk profile. Together, these relationships ensure that issue management remains principled, consistent, and aligned with organizational governance while maintaining flexibility to address unique project circumstances effectively.