PRINCE2 Practices practice questions

Request an exception plan to reallocate the surplus

Why it fails: An exception plan is only triggered when a stage or project is forecast to exceed its tolerances; underspend with complete scope breaches nothing. It is tempting because surplus feels like a deviation needing formal handling, but PRINCE2 exception mechanisms address forecast breaches, not favourable variances.

Immediately authorize the next stage as the project is under budget

Why it fails: The board should first understand the reasons for the under-run before authorizing.

Ask the project manager to revise the project plan to increase costs

Why it fails: Revising the plan to spend surplus contradicts PRINCE2's principle of continued business justification; underspend with complete scope needs no corrective plan. It is tempting because budgets are usually the problem, but here the board should simply authorise the next stage, since tolerances are not breached.

Business Case practice

Why it fails: This is incorrect. The Business Case practice focuses on justifying the project's viability and ensuring continued alignment with business objectives. The project product description does not support the business case directly.

Plans practice

Why it fails: This is incorrect. The Plans practice deals with defining how to deliver the products, but the project product description defines what the product should be, not how to plan its delivery.

Risk practice

Why it fails: This is incorrect. The Risk practice identifies and manages uncertainties; the project product description is about the product's quality rather than risks.

Project product description

Why it fails: The project product description is part of the Business Case practice, not the Quality practice.

Quality register

Why it fails: The quality register is a management product that records quality activities, but it is not an element of the Quality practice itself; it's a document.

Low

Why it fails: Low risk exposure would require either low probability and low impact, or a combination that yields a low product. Here, both probability and impact are medium, so the product is medium, not low.

Very High

Why it fails: (Very High) is incorrect because neither probability nor impact is at the highest level. Very High exposure would require both probability and impact to be High or Very High.

High

Why it fails: (High) is incorrect because the product of two Medium ratings does not reach the threshold for High exposure. High would require at least one factor to be High or the product to be higher.

Business Case

Why it fails: The Business Case records the justification but does not detail review activities.

Project Plan

Why it fails: The Project Plan covers schedule and resources, not benefit measurement.

Risk Register

Why it fails: The Risk Register lists threats and opportunities, not benefit review processes.

Escalate directly to senior management without discussion with the stakeholder.

Why it fails: The issue should first be resolved at the project level; escalation is a last resort.

Proceed with including the product as the project manager has authority over product definitions.

Why it fails: The project manager does not have unilateral authority; decisions about products should be agreed with stakeholders.

Remove the product to satisfy the stakeholder, as stakeholder satisfaction is key.

Why it fails: Stakeholder satisfaction is important, but the product may be necessary for the project's success; a balanced decision should be made.

The risk register with identified risks.

Why it fails: The risk register is a dynamic log, not part of the approach document.

The risk appetite of the organization.

Why it fails: Risk appetite is an organizational factor that influences the approach but is not defined within it.

The risk budget for the project.

Why it fails: The risk budget is a resource allocation, not a description of the risk management approach.

The project manager reports to the project board through the senior user.

Why it fails: The project manager reports to the executive.

The project board consists of four roles: executive, senior user, senior supplier, and project manager.

Why it fails: The project board has three roles; the project manager is not on the board.

Project assurance is a role within project support.

Why it fails: Project assurance is independent of project support.

Remove the criterion from the Project Product Description.

Why it fails: Removal should be a formal change control decision.

Ignore the issue because the criterion is already documented.

Why it fails: The issue needs to be addressed to avoid ambiguity.

Reclassify it as 'Must' to ensure delivery.

Why it fails: This should be agreed with the customer first.

Ask the project board to approve the Project Plan subject to a review of the Business Case later.

Why it fails: The Business Case should be finalized before plan approval.

Proceed with the Project Plan as the Business Case already shows a positive NPV.

Why it fails: A positive NPV and 12% IRR justify the investment case, but they do not resolve the executive's specific concern about uncertain market demand for the benefits. PRINCE2 expects the Business Case to be re-evaluated and, where benefit tolerance is at risk, for the project manager to address that uncertainty before baselining the Project Plan. Proceeding ignores the board's stated worry; this approach would fit a project whose benefits are already confirmed and stable.

Update the Business Case to reflect the uncertainty and seek approval from the project board before proceeding with the Project Plan.

Why it fails: The project manager should not unilaterally update the Business Case; but this is close to correct, however the project manager should first refine the Business Case with the senior user and senior supplier.

Step 1: Define and analyze products, Step 2: Design the plan, Step 3: Identify activities and dependencies, Step 4: Estimate, Step 5: Schedule and document the plan

Why it fails: This is incorrect because defining products should come after designing the plan, as the plan design sets the overall context and approach before detailing specific products.

Step 1: Design the plan, Step 2: Identify activities and dependencies, Step 3: Define and analyze products, Step 4: Estimate, Step 5: Schedule and document the plan

Why it fails: This is incorrect because identifying activities should be based on the products that need to be created, so defining products must come before identifying activities.

Step 1: Design the plan, Step 2: Define and analyze products, Step 3: Estimate, Step 4: Identify activities and dependencies, Step 5: Schedule and document the plan

Why it fails: This is incorrect because estimating effort and duration requires knowing the activities involved, so estimating should come after identifying activities, not before.

Corporate or Programme Management: The level responsible for delivering project products.

Why it fails: Incorrect — this describes the Delivering (Team Manager) level, not Corporate or Programme Management.

Managing (Project Manager): The level responsible for overall direction of the project.

Why it fails: Incorrect — overall direction is the responsibility of the Directing (Project Board) level, not the Managing level.

Senior Supplier

Why it fails: The Senior Supplier represents those delivering the products and advises on their viability, but does not own or maintain the Business Case. That accountability sits with the Executive, who is ultimately answerable for the project's ongoing justification and benefits.

Senior User

Why it fails: The Senior User represents user interests and specifies requirements; accountability for the Business Case rests with the Executive, who owns its viability throughout. It is tempting because the Senior User contributes benefits-realisation evidence, and would be correct for confirming that delivered products meet user needs, not for maintaining the Business Case.

Executive

Why it fails: The Executive is accountable for the Business Case, but the Project Manager performs the day-to-day maintenance and updating of it. Delegating upkeep to the Executive misreads the accountability-versus-responsibility split that PRINCE2 draws between the two roles.

Project Brief

Why it fails: The Project Brief is the key output of Starting up a Project, not Initiating a Project; it is the trigger input that the Project Initiation Documentation builds upon. It is tempting because the Brief authorises the project's initiation, but Initiating a Project produces the PID, including the business case, plans and controls.

Project Plan

Why it fails: The Project Plan is only one component of the Project Initiation Documentation, not the process's key output. It is tempting because planning dominates the Initiating a Project activities, but the PID as a whole — business case, benefits, risk and quality approaches — is the documented result that the Project Board approves.

Business Case

Why it fails: The Business Case is tempting because it provides the project's ongoing justification and is significantly refined during Initiating a Project. However, it is initially created as an Outline Business Case in Starting up a Project. In Initiating a Project, the Business Case becomes a key component *within* the Project Initiation Documentation (PID), which is the comprehensive key output that authorises the project's delivery. Therefore, while crucial, the Business Case itself is not the singular key output of Initiating a Project.

Continue with the current plan and adjust the budget in the next stage

Why it fails: Continuing unchanged breaches the cost tolerance without escalation, denying the Board the exception decision PRINCE2 requires. It tempts because continuing is valid when the Project Manager has raised an exception report and the Board has approved a revised stage plan.

Close the project immediately

Why it fails: Closing the project immediately removes any opportunity to assess options, and premature closure wastes the investment already delivered. It tempts because closure is legitimate once the business case no longer justifies continuation and the Board endorses that decision.

Reduce the scope to stay within budget without informing the Board

Why it fails: Reducing scope to absorb a forecast cost overrun bypasses the Board, which must authorise changes to the agreed baseline and tolerances. It tempts because scope reduction is a legitimate corrective action once the Board approves an exception plan or revised business case.

To manage the day-to-day activities of the team

Why it fails: Day-to-day team activities are managed by the Managing Product Delivery process, which controls work package execution and reporting. Managing a Stage Boundary sits with the Project Manager at stage end, providing the board with information to authorise the next stage. It is tempting because both involve ongoing delivery oversight, yet the boundary process is periodic, not daily.

To close the project and produce the End Project Report

Why it fails: Closing the project and producing the End Project Report belongs to the Closing a Project process, which confirms delivery and captures lessons. Managing a Stage Boundary instead prepares the next Stage Plan and updates the PID for the board's authorisation. It is tempting because both processes produce reports for the project board, but closure is triggered by project completion, not a stage end.

To initiate the project and create the PID

Why it fails: Initiating a project and creating the PID occurs in the Initiating a Project process, which establishes the baseline before delivery begins. Managing a Stage Boundary reviews the current stage and prepares the next Stage Plan for board approval. It is tempting because both produce or update PID content, but initiation happens once, whereas boundary management recurs at each stage end.

A Request for Change is for changes to the project plan; an Off-specification is for changes to products

Why it fails: A Request for Change covers any proposed modification, including to products, so the plan-versus-product split is false. It is tempting because RFCs often address baselined plans, but Off-specifications specifically record products that fail to meet their agreed specification, not product change requests.

A Request for Change is raised by the team; an Off-specification is raised by the project manager

Why it fails: Both are issue types raised by anyone, including team members; the stem's distinction concerns who raises them, which is not the actual axis. It is tempting because role-based framing feels tidy, but the real difference is that an Off-specification covers something the project should deliver but currently does not.

A Request for Change requires an issue report; an Off-specification does not

Why it fails: Both are captured within an issue report; the presence of an issue report is not what separates them. It is tempting because documentation artefacts feel like the natural dividing line, but the real distinction is that an Off-specification describes a gap between agreed and actual delivery, whereas a Request for Change proposes altering baselined scope.

Risk

Why it fails: Risk is a separate PRINCE2 register with its own lifecycle and management responses; issues are change requests, off-specifications and problems/concerns. It is tempting because risks and issues share escalation routes and both threaten objectives, but PRINCE2 deliberately keeps them distinct, so risk is never an issue type.

Highlight Report

Why it fails: The Highlight Report is a progress communication product sent by the Project Manager to the Project Board at agreed intervals; it is not an issue type. It is tempting because it can carry escalated concerns, but PRINCE2 classifies issues as change requests, off-specifications and problems/concerns, so a reporting artefact cannot qualify.

Lessons Report

Why it fails: The Lessons Report is a product produced during Closing a Project to capture and share learning; it is not an issue type. It is tempting because lessons often arise from problems, but PRINCE2's issue types are change requests, off-specifications and problems/concerns, so a lessons artefact sits outside that classification.

The Project Assurance

Why it fails: Project Assurance provides independent oversight but does not maintain the Business Case.

The Executive

Why it fails: The Executive owns the Business Case but does not maintain it day-to-day.

The Senior Supplier

Why it fails: The Senior Supplier provides resources and expertise but does not maintain the Business Case.

Starting Up a Project

Why it fails: This process occurs before project initiation, not during a stage.

Directing a Project

Why it fails: Directing a Project is for the Project Board's decisions, but the trigger is within Controlling a Stage.

Managing a Stage Boundary

Why it fails: This process occurs at the end of a stage, not when a tolerance is forecast to be exceeded during the stage.