PRINCE2 Practices practice questions

Senior Supplier

Why wrong: The Senior Supplier represents the interests of those providing the project's products, but does not maintain the Business Case.

Senior User

Why wrong: The Senior User represents the users' interests and provides requirements, but does not maintain the Business Case.

Executive

Why wrong: The Executive is accountable for the Business Case and owns it, but does not maintain it day-to-day; that responsibility lies with the Project Manager.

Resource

Why wrong: Resource is not a formal PRINCE2 tolerance; it is managed through the plan and not subject to tolerance delegation.

Cost

Why wrong: Cost is a standard PRINCE2 tolerance, but it is not selected as one of the two correct answers in this question.

Budget

Why wrong: Budget is not a PRINCE2 tolerance; the correct term is Cost.

Executive (Senior Responsible Owner)

Why wrong: The Executive owns the Business Case and approves it, but is not responsible for its day-to-day maintenance.

Senior User

Why wrong: The Senior User provides the user perspective and benefits, but does not maintain the Business Case.

Project Board

Why wrong: The Project Board makes decisions about the Business Case but does not maintain it.

Transfer

Why wrong: Transfer is a response for threats.

Avoid

Why wrong: Avoid is a response for threats.

Fallback

Why wrong: Fallback is a response for threats.

To approve the project's quality management approach

Why wrong: Approving the quality management approach is the Project Board's responsibility.

To update the quality register

Why wrong: The quality register is updated as a result, but it is not the purpose of the technique.

To define quality criteria for products

Why wrong: Quality criteria are defined in product descriptions, not in the review.

Change

Why wrong: Change is a practice, not an issue type.

Risk

Why wrong: A risk is an uncertain event, not an issue.

Opportunity

Why wrong: In PRINCE2, the three defined types of issues are a Request for Change, an Off-Specification, and a Problem/Concern. An Opportunity is not a recognised issue type; it is instead a type of risk (a positive risk) managed via the risk management approach. This option is tempting because the term "opportunity" sounds like a project event requiring a decision, but PRINCE2 explicitly separates risk management from issue management, reserving "issue" for events that have already occurred or require a deviation decision.

To initiate the project and produce the Project Initiation Documentation

Why wrong: That is the purpose of Initiating a Project.

To close the project and hand over the product

Why wrong: That is the purpose of Closing a Project.

To control the day-to-day activities of the project stage

Why wrong: That is the purpose of Controlling a Stage.

To update the project schedule

Why wrong: The project schedule is updated in the Stage Plan, but the Business Case review focuses on viability.

To identify new stakeholders

Why wrong: Stakeholder identification is part of the Organising practice, not the primary purpose of the Business Case review at stage boundaries.

To assign team managers to the next stage

Why wrong: Team manager assignments are part of resource planning, not the Business Case review.

Exception Plan

Why wrong: Exception Plan is created when a stage is forecast to exceed tolerance, not for normal work instructions to a Team Manager.

Team Plan

Why wrong: Team Plan is produced by the Team Manager, not the Project Manager, so it does not fit the question's description.

Project Plan

Why wrong: Project Plan is high-level and covers the entire project; it does not provide detailed work instructions to a Team Manager.

Constraint

Why wrong: Constraint is not an issue type in PRINCE2.

Opportunity

Why wrong: Opportunity is a type of risk, not an issue.

Risk

Why wrong: A risk is an uncertain event that could affect project objectives, not a type of issue. In PRINCE2, issues are events that have already occurred and require management action, whereas risks are handled through the risk management procedure. This option is tempting because both risks and issues can disrupt a project, and practitioners often confuse the two. It would be correct if the question asked for types of risk, not types of issue.

The Executive

Why wrong: Incorrect. While the Executive is accountable for the Business Case and must approve changes, they do not maintain it; that responsibility falls to the Project Manager.

The Senior User

Why wrong: The Senior User represents the users' interests but does not own the Business Case.

The Project Board

Why wrong: The Project Board collectively approves the Business Case, but the Executive owns it.

The Project Manager

Why wrong: The PM cannot provide independent assurance as they are responsible for delivery.

The Team Manager

Why wrong: The Team Manager is part of delivery, not independent assurance.

The Project Support

Why wrong: Project Support provides administrative services, not independent assurance.

Product descriptions

Why wrong: Product descriptions are part of the Plans practice.

Project plan

Why wrong: The project plan is a separate document.

Risk register

Why wrong: The risk register is a separate management product.

End Stage Report

Why wrong: Produced during Managing a Stage Boundary.

Work Package

Why wrong: Produced during Controlling a Stage for team delivery.

Highlight Report

Why wrong: Produced during Controlling a Stage.

It is performed by the Project Manager

Why wrong: Project Assurance is independent of the PM.

It focuses only on financial aspects

Why wrong: Assurance covers all aspects: business, user, supplier.

Avoid

Why wrong: Avoid is a threat response.

Accept

Why wrong: Accept can apply to both but is not specific to opportunities.

Transfer

Why wrong: Transfer is a threat response.

Day-to-day management of the project

Why wrong: That is the Project Manager's responsibility.

Managing configuration items

Why wrong: Usually done by Project Support or a dedicated role.

Creating the Project Plan

Why wrong: The Project Manager creates the plan, though the Board approves it.

An RFC is raised by the Project Board; an Off-spec is raised by the Project Manager

Why wrong: Both can be raised by any stakeholder; the source is not the difference.

An RFC is about scope changes; an Off-spec is about quality defects only

Why wrong: Off-spec can relate to any product aspect, not just quality.

An RFC is raised before the product is baselined; an Off-spec is raised after baselining

Why wrong: Both can occur after baselining; the timing is not the key difference.

Threat; Transfer

Why wrong: This is not a threat; transfer is for negative risks.

Opportunity; Reject

Why wrong: Reject is for opportunities that are not worth pursuing; this one is beneficial.

Threat; Avoid

Why wrong: A threat is a negative risk; this scenario describes a positive risk.

End Stage Report

Why wrong: The End Stage Report summarises performance against the stage plan at the end of a stage, not on a regular basis during it. It is tempting because it is the primary vehicle for reporting stage-level progress to the Project Board, but the scenario requires a periodic checkpoint—the Checkpoint Report—which provides the regular, short-interval progress update the Project Manager uses to keep the Board informed between stage boundaries.

Checkpoint Report

Why wrong: Checkpoint Reports are from Team Manager to Project Manager.

Exception Report

Why wrong: Exception Reports are produced when tolerances are forecast to be exceeded, not routinely.