Select Two (Multi-Select) Questions

Next Stage Plan

The Next Stage Plan is created during Managing a Stage Boundary, setting out how the following stage will deliver its products. It is a required output of that process, directly supporting progress governance by giving the Board a basis for authorising the next stage.

Updated Business Case

The Business Case is updated at each stage boundary to confirm the project remains viable and aligned with the investment. This updated version is a mandated output of Managing a Stage Boundary, supporting progress governance by informing the continued business justification decision.

End Stage Report

The End Stage Report summarises actual versus planned performance for the closing stage. It is produced during Managing a Stage Boundary and is a required input to the Board's decision on whether to authorise the next stage, directly supporting progress governance.

Authorizing project initiation

Authorising project initiation is a formal Project Board decision within Directing a Project, exercised through the DP1 activity "Authorise initiation". It satisfies the stem's constraint by confirming the Board's continued commitment before committing resources to the Initiation Stage, distinct from day-to-day Managing a Stage Boundary approvals.

Authorizing project closure

Authorising project closure is a Project Board decision made within Directing a Project, specifically at the "Authorise project closure" activity. It satisfies the stem's constraint by being a formal board-level responsibility, distinct from the Project Manager's day-to-day managing activities, and confirms the board retains authority until the project formally ends.

Authorizing a Stage Plan or Exception Plan

Authorising a Stage Plan or Exception Plan is a core Project Board decision within Directing a Project, exercised at stage boundaries or after an exception. It satisfies the stem's requirement for formal Project Board responsibility, since only the Board can commit the project to a revised or next-stage baseline.

Senior Supplier

The Senior Supplier represents those designing, developing and delivering the project's products, supplying resources and expertise. Alongside the Executive and Senior User, this role forms the Project Board's three core interests, ensuring supplier commitment and viability are represented in decisions.

Senior User

The Senior User represents those who will use the project's products and realise the benefits. With the Executive and Senior Supplier, this role completes the Project Board's core business, user and supplier interests, ensuring requirements and benefits are championed.

The principles empower behavior and good practice rather than prescribing rigid bureaucratic steps.

PRINCE2 principles are guiding obligations that shape behaviour and good practise, deliberately avoiding prescriptive bureaucracy. This satisfies the stem's requirement for a true governance statement, since tailoring is expected and principles are applied according to project scale, complexity and risk.

Applying the principles helps determine whether a project is genuinely being managed using PRINCE2.

The seven principles act as a benchmark for assessing whether a project is genuinely applying PRINCE2, rather than merely adopting its terminology. This satisfies the stem's focus on governance, since a project claiming PRINCE2 compliance can be evaluated against each principle.

The principles provide a universal foundation of good practice for any project regardless of industry.

The principles are deliberately industry-agnostic and scale-independent, so they apply to any project type, size or sector. This satisfies the stem's requirement that they provide a universal foundation of good practise, unlike the themes and processes, which are tailored to context.

Tolerances can be established across six dimensions: cost, time, quality, scope, risk, and benefit.

Tolerances span exactly six dimensions in PRINCE2: cost, time, quality, scope, risk and benefit. This statement satisfies the stem's requirement for a correct Progress practice fact, since the project board delegates authority by setting these six tolerance types, enabling management by exception.

Tolerances define the upper and lower limits of deviation permitted without escalation.

Tolerances set the permissible upper and lower boundaries of deviation from planned targets; breaching them triggers escalation to the next management level. This directly satisfies the stem's requirement to describe what tolerances fundamentally represent in the Progress practice.

Producing the End Stage Report

The End Stage Report is produced during Managing a Stage Boundary, summarising stage performance and providing the Project Board with the information needed to authorise the next stage. This satisfies the stem by confirming it as a core activity of that process rather than of Controlling a Stage.

Preparing the next Stage Plan

Preparing the next Stage Plan is a core Managing a Stage Boundary activity, giving the Project Board a basis for authorising the following stage. This satisfies the stem by confirming the process's forward-looking planning purpose, distinct from the day-to-day work of Controlling a Stage.

Composition (what parts make up the product)

Composition is a required Product Description element, listing the parts, components or sub-products that together form the finished product. It defines the product's structure so those parts can be planned, produced and quality-checked, supporting the Plan and Quality practices.

Purpose (what the product is for)

Purpose is a required Product Description element, stating what the product is for and why it is needed. It links the product to the business justification and expected benefits, giving the producer and quality reviewers a clear rationale for the deliverable.

Quality criteria and quality method

Quality criteria and quality method are required Product Description elements. Quality criteria define the measurable attributes the product must satisfy, while the quality method specifies how compliance will be verified, such as testing or inspection, directly supporting the Quality practice.

It defines how and when the projected benefits of the project will be measured.

The Benefits Management Approach specifies the measurements, timing and responsibilities for tracking projected benefits, defining how and when each will be measured against the Business Case. This satisfies the stem's requirement for describing measurement arrangements.

It includes post-project benefit reviews to ensure long-term value realization.

The Benefits Management Approach schedules post-project benefit reviews, assigning responsibility for verifying that expected benefits are actually realised after the project closes. This addresses the stem's long-term value realisation requirement, extending benefit accountability beyond project closure.

Project Assurance provides independent monitoring of project performance.

Project Assurance operates independently of the Project Manager, monitoring performance against the business case, plans, and tolerances on behalf of the Project Board. This independence is the defining mechanism that satisfies the requirement for objective oversight rather than self-reported progress.

Project Assurance covers business, user, and supplier perspectives.

Project Assurance is exercised from three distinct perspectives — business, user, and supplier — each corresponding to a Project Board role. Covering all three satisfies the requirement that assurance reflects every stakeholder interest, rather than only the business or delivery viewpoint.

The Senior Supplier

The Senior Supplier is mandatory, representing those designing, developing and implementing the products. This satisfies the stem because PRINCE2 7 requires supplier-side interests on the Project Board alongside business and user representation, ensuring feasibility and delivery capability inform every decision.

The Senior User

The Senior User is mandatory, representing those who will use and benefit from the project's products. This satisfies the stem because PRINCE2 7 requires user interests on the Project Board, ensuring requirements and benefits realisation are represented alongside business and supplier perspectives.

The Executive

The Executive is mandatory, chairing the Project Board and owning the Business Case. This satisfies the stem because PRINCE2 7 requires the Executive as the single accountable individual representing the business interest, without whom the board cannot legitimately authorise the project.

Quality Register

The Quality Register is a core PRINCE2 management product within the Quality practice, recording quality activities, results and approvals throughout the project. It satisfies the stem's requirement by tracking planned and completed quality checks, providing the audit trail the Quality practice demands for verifying that products meet their agreed quality criteria.

Product Description

Product Descriptions are a core PRINCE2 quality management product, defining the customer's quality expectations and acceptance criteria for each product. They satisfy the Quality practice's requirement to specify quality criteria before work begins, enabling subsequent quality control activities such as quality inspection and approval against those predefined criteria.

Quality Management Approach

The Quality Management Approach is a management product within the PRINCE2 Quality practice, defining the project's quality standards, procedures and responsibilities. It satisfies the stem's requirement by being one of the three products the Quality practice formally recognises, alongside the Product Description and Quality Register.

Product purpose

Product purpose states why the product is needed and what it achieves, forming a required Product Description element alongside composition, quality criteria, and quality method. This satisfies the stem's request for elements typically documented within a Product Description.

Quality criteria

Quality criteria belong in a Product Description because they define the measurable attributes the product must exhibit to be accepted, satisfying the stem's requirement for documented elements. They give the quality control and quality assurance activities objective, testable acceptance measures against which the finished product is verified.

Derivation

Derivation records the source information or originating document from which the product's requirements are drawn, satisfying the stem's requirement for documented elements. It provides traceability, showing reviewers where the product's specification came from and why the product is needed within the project.

If the business justification for a project ceases, the project should be stopped.

A project lacking valid business justification must be discontinued, satisfying the principle's requirement that justification remains valid throughout. PRINCE2 mandates that if the Business Case no longer demonstrates viable justification, the project board should stop the project rather than continue investing, ensuring resources are not wasted on unjustified work.

The business case must remain valid throughout the entire lifecycle of the project.

Continued business justification demands the business case stays valid from start to close, not merely at initiation. This statement satisfies the principle's lifecycle-wide constraint: justification is reviewed at every stage boundary and end stage assessment, and the project must be stopped or re-scoped if the business case no longer holds.

The risk profile and geographical dispersion of the project team.

Tailoring must reflect the project's risk profile and team dispersion, since these determine how much formality, control and communication structure the method needs. Higher risk or geographically spread teams require adapted governance, satisfying the stem's requirement to consider these factors when tailoring.

The scale, complexity, and importance of the project.

Tailoring scales PRINCE2's products and processes to the project's scale, complexity and importance, so a large, complex or business-critical project retains more rigorous governance while smaller ones use lighter documentation. This directly satisfies the stem's requirement to consider these factors when tailoring.

The organizational culture, environment, and existing corporate governance standards.

Tailoring must align with the organisation's culture, environment and existing governance standards, since PRINCE2 is adapted within, not replacing, corporate frameworks. Embedding the method consistently with these ensures acceptance, satisfying the stem's requirement to consider them when tailoring.

Controlling a Stage

Controlling a Stage sits with the Project Manager, who authorises work packages, monitors progress, handles issues and reports via Highlight Reports. It is one of the three processes the Project Manager owns, alongside Starting up a Project and Managing a Stage Boundary.

Initiating a Project

Initiating a Project is owned by the Project Manager, who prepares the Project Initiation Documentation and plans the project's controls. It is one of the three processes the Project Manager manages primarily, alongside Controlling a Stage and Managing a Stage Boundary.

Managing a Stage Boundary

Managing a Stage Boundary sits within the Project Manager's remit, providing the Project Board with the End Stage Report, Next Stage Plan and updated Business Case at each stage gate. This satisfies the stem's constraint of processes managed primarily by the Project Manager, rather than by the Board or corporate programme.

Verify user acceptance of project products

Verifying user acceptance confirms the products meet agreed requirements before handover, satisfying the CP objective to confirm acceptance of the project's products. This acceptance evidence supports the project board's decision to authorise closure, ensuring deliverables are formally signed off rather than merely completed.

Evaluate project performance against the PID baselines

Evaluating performance against the PID baselines is a stated objective of Closing a Project, satisfying the process's requirement to assess whether the project delivered against its approved baseline. This comparison occurs before the project is disbanded, feeding lessons and the end project report, and confirms the project achieved what the Project Board originally authorised.

Ensure provision is made for post-project benefit reviews

Closing a Project must plan how benefits will be measured after the project closes, so ensuring post-project benefit reviews are provisioned is a genuine CP objective. It confirms the project's outputs can be evaluated against the Business Case once the team disbands.

A project's outputs and their quality requirements must be defined and agreed upon before work begins.

Focus on products requires defining and agreeing outputs and their quality requirements before work commences, ensuring effort is directed at delivering specified products rather than activity for its own sake. This matches the principle's emphasis on agreed product definition.

Deliverables must satisfy acceptance criteria before being formally signed off by the customer.

Deliverables must meet their agreed acceptance criteria before formal customer sign-off, ensuring quality is built in and verified rather than assumed. This reflects the principle's requirement that products conform to defined quality criteria before acceptance.

Product Descriptions are essential management products used to define each output's quality and criteria.

Product Descriptions define each output's purpose, composition, quality criteria and quality method, making them essential management products under 'Focus on products'. They shift attention from activity-based planning to agreed outputs, satisfying the principle's requirement that teams define and deliver against explicit product specifications before work begins.

Tolerances are established for six aspects of project performance, including time and cost.

Tolerances define the delegated limits for the six aspects of project performance — time, cost, scope, quality, risk and benefits — that allow the next management level to work within agreed boundaries without seeking approval, which is the mechanism enabling management by exception.

The Project Manager must immediately escalate via an Exception Report if stage tolerances are forecast to be breached.

Forecast breach of stage tolerances removes the Project Manager's delegated authority, so escalation to the Project Board via an Exception Report is mandatory. This preserves the agreed tolerance boundaries and lets the Board decide whether to continue, change or stop the stage.

Checkpoint Report (Team Manager to Project Manager)

The Checkpoint Report provides progress information from the Team Manager to the Project Manager at the work package level, typically at the frequency defined in the Work Package. It is one of the reports communicating status between management levels.

Highlight Report (Project Manager to Project Board)

The Highlight Report is produced by the Project Manager for the Project Board at the frequency defined in the Communication Management Approach, summarising stage progress, status and issues. It communicates status upward between these two management levels.

Authorizing a Work Package

Authorising a Work Package sits squarely in Controlling a Stage, where the Project Manager allocates work, sets tolerances and confirms acceptance criteria with the Team Manager. It satisfies the stem's requirement for CS activities, unlike Managing Product Delivery, which receives and executes the Work Package.

Capturing and assessing issues and risks

Capturing and assessing issues and risks sits within Controlling a Stage, where the Project Manager handles day-to-day exceptions against the stage plan. This satisfies the stem's requirement for CS activities, since issue and risk registers are reviewed and updated during stage execution, feeding escalation decisions to the Project Board when tolerances are threatened.

Reviewing work package status

Reviewing work package status sits within Controlling a Stage because the Work Package is the mechanism for delegating and monitoring work during the delivery stage. The Team Manager reports progress, issues and forecast against the agreed tolerances, letting the Project Manager assess whether corrective action is needed.