Select Two (Multi-Select) Questions

Waterfall

Why it fails: Waterfall is a sequential delivery lifecycle, not one of the seven PRINCE2 practices such as business case, organisation, quality, plans, risk, change and progress. It is tempting because PRINCE2's process model is often delivered sequentially, yet lifecycle choice sits under tailoring rather than the practices themselves.

Sprint Planning

Why it fails: Sprint Planning belongs to Scrum, not PRINCE2's seven practices (business case, organisation, quality, plans, risk, change, progress). It is tempting because PRINCE2 can be tailored alongside agile delivery, but Sprint Planning remains a Scrum event and is never a PRINCE2 practice.

It is defined in the Configuration Management Approach

Why it fails: It is defined in the Change Control Approach.

It is always the Project Manager

Why it fails: The Change Authority can be the Project Manager, but not always.

It is responsible for maintaining the Configuration Item Records

Why it fails: Configuration management is separate.

Providing independent assurance to the Project Board

Why it fails: Independent assurance is delivered by Project Assurance, which reports directly to the Project Board, whereas Project Support provides administrative services to the Project Manager and team. It tempts because both roles sit outside the delivery line and interact with the Board, but assurance requires independence Project Support cannot hold.

Preparing the Highlight Report

Why it fails: The Highlight Report is produced by the Project Manager to update the Project Board on progress, so drafting it sits outside Project Support's remit of maintaining logs, files and administrative tools. It tempts because Project Support often formats and distributes the report, but authorship and content ownership remain with the Project Manager.

The Executive approves all Work Packages

Why it fails: Work Package approval sits with the Project Manager, who authorises work within the Stage Plan; the Executive only approves Stage Plans and Exception Plans at board level. It is tempting because the Executive owns the Business Case and approves major commitments, but routine Work Package sign-off is delegated.

The Executive manages the project on a day-to-day basis

Why it fails: Day-to-day management belongs to the Project Manager, who runs the team and delivers products; the Executive provides board-level direction and remains accountable for the Business Case. It tempts because the Executive is accountable overall, yet PRINCE2 separates accountability from operational control.

The Executive is appointed after the project brief is approved

Why it fails: The Executive is appointed during pre-project, before the Project Brief is written, and typically authors or approves that brief. It tempts because later roles such as the Project Manager are confirmed once the brief exists, but the Executive must be in place to shape the mandate.

Authorise a Work Package

Why it fails: Authorising a Work Package belongs to Controlling a Stage, where the Project Manager approves work for the team. Managing a Stage Boundary instead reviews the current stage and prepares the next Stage Plan. Authorisation occurs during stage execution, not at its boundary.

Produce the Project Brief

Why it fails: The Project Brief is produced in Starting up a Project, before the Project Board authorises initiation. Managing a Stage Boundary produces the End Stage Report and next Stage Plan. The Brief therefore precedes the stage boundary entirely.

Deliver a product

Why it fails: Delivering a product happens during stage execution under Controlling a Stage, when the team completes Work Packages. Managing a Stage Boundary assesses the stage's outputs and plans the next one. Delivery is therefore an ongoing activity, not a boundary activity.

Budget overrun due to inflation

Why it fails: External factors like inflation are not directly addressed.

Technology failure

Why it fails: PRINCE2 does not cover technology risks specifically.

Project Support

Why it fails: Project Support provides administrative services, not decision-making.

Project Manager

Why it fails: The Project Manager is a management role, not on the Project Board.

The Project Board performs project assurance and project support

Why it fails: Project assurance is delegated by the Board to assurance roles, and project support is provided by the Project Manager's support team; the Board itself performs neither. It is tempting because the Board is accountable for assurance, but accountability is discharged through delegation, not by the Board executing these functions directly.

The Project Board prepares the Stage Plans

Why it fails: Stage Plans are produced by the Project Manager and approved by the Project Board; the Board does not author them. It is tempting because the Board does approve Stage Plans and authorise the next stage, so its involvement in the planning cycle is genuine, but authorship sits with the Project Manager.

The Project Board is responsible for the day-to-day management of the project

Why it fails: Day-to-day management belongs to the Project Manager, delegated through the Work Packages and Stage Plan authorisation. The Board directs and manages by exception, meeting at decision points. It is tempting because Board members do carry accountability for the project's success, but accountability differs from operational control.

Producing Checkpoint Reports

Why it fails: Checkpoint Reports are produced by Team Managers, not the PM.

Reviewing the Business Case

Why it fails: The Business Case is reviewed by the Project Board throughout; the PM maintains it but reviewing viability is a Board responsibility.

Project Manager

Why it fails: The Project Manager manages the project on the board's behalf but sits below it, reporting to the Project Board rather than being a member of it. It is tempting because the role is central to delivery, yet the board comprises Executive, Senior User and Senior Supplier.

Project Assurance

Why it fails: Project Assurance is a role delegated by individual Project Board members to monitor the project on their behalf; it is not itself a Project Board role. It is tempting because assurance reports directly to the board, but the board's actual roles are Executive, Senior User and Senior Supplier.

Team Manager

Why it fails: The Team Manager leads a team delivering products and reports to the Project Manager, sitting below the Project Board. It is tempting because the role is a formal PRINCE2 management position, but board membership is limited to Executive, Senior User and Senior Supplier.

The Business Case

Why it fails: A Work Package is the authority given to a Team Manager to deliver defined products, including the product description, tolerances, constraints and reporting requirements. The Business Case is a project-level document owned by the Executive. It is tempting because justification underpins all work, but it is not delegated within a Work Package.

The project's risk register

Why it fails: The risk register is a project-level management product maintained by the Project Manager; a Work Package instead specifies the risks, constraints and tolerances relevant to that delegated work. It is tempting because teams must manage risk locally, but the register itself is not an element of the Work Package.

The composition of the project team

Why it fails: A Work Package defines the products, tolerances, constraints, reporting and interfaces for delegated work; team composition is a resourcing decision, not part of the Work Package. It is tempting because the Team Manager does assign people, but staffing sits outside the authority document's defined elements.

Project Assurance reports to the Project Manager

Why it fails: Project Assurance reports to the Project Board, not the PM.

The Project Manager can assign Project Assurance tasks to themselves if resources are limited

Why it fails: The PM cannot perform Assurance due to independence requirements.

The Project Manager can delegate Project Assurance duties to a Team Manager

Why it fails: Assurance cannot be delegated to the PM or Team Manager.

The Risk Register

Why it fails: The Risk Register is a separate PRINCE2 management product, maintained independently and not embedded within the PID. It is tempting because risk information feeds the PID's Business Case, and the register would be correct as the standalone log of identified threats, owners and responses.

The Lessons Log

Why it fails: The Lessons Log is a separate project file maintained throughout, feeding Lessons Reports into the PID's lessons section rather than being a PID component itself. It tempts because lessons are captured within the PID, so the log appears related, yet it remains a distinct management product.

The Team Manager

Why it fails: The Team Manager is a role appointed during organisation, not a PID component; the PID contains the Project Plan, business case and controls. It tempts because role appointments are documented in the project's organisation structure, which is itself a PID section, but the role holder is not the component.

Lessons Log

Why it fails: The Lessons Log captures lessons from previous or current projects and sits outside the Project Initiation Documentation baseline; it is a separate PRINCE2 record. It is tempting because lessons inform the PID's approach, and would be correct where the question asks which document feeds lessons into project initiation.

Quality Register

Why it fails: The Quality Register records quality activities and results and is maintained outside the Project Initiation Documentation; the PID contains the Quality Management Approach instead. It is tempting because quality planning is central to initiation, and would be correct where the question asks which register tracks quality checks during delivery.

Risk Register

Why it fails: The Risk Register is created during Initiating a Project and updated throughout, but it is a separate management product, not a component of the Project Initiation Documentation baseline. It is tempting because the PID references risk tolerances; however, the register itself sits outside the PID's document set.

Monitor

Why it fails: Monitor is not a separate step; Communicate covers ongoing communication.

Analyze

Why it fails: PRINCE2 uses 'Assess', not 'Analyze'.

To plan the next stage

Why it fails: Planning the next stage belongs to Managing a Stage Boundary, which produces the next Stage Plan for board approval. It is tempting because Managing Product Delivery also involves agreeing work packages with the project manager, yet its scope is accepting, executing and delivering those packages, not stage-level planning.

To manage stage boundaries

Why it fails: Managing stage boundaries is the purpose of the Managing a Stage Boundary process, which prepares the End Stage Report and next Stage Plan for the board. It is tempting because both processes sit within the stage-level governance layer, but Managing Product Delivery concerns accepting, executing and delivering work packages.

To close the project

Why it fails: Closing the project belongs to Closing a Project, which handles project closure and post-project review. Managing Product Delivery concerns accepting, executing and delivering work packages, so this purpose is tempting because delivery completion precedes closure.

Is accountable for the management of the entire stage

Why it fails: The Project Manager manages the stage; the Team Manager only manages work packages.

Is a member of the Project Board

Why it fails: The Project Board consists of SRO, Senior User, Senior Supplier.

It prioritises products based on their quality criteria

Why it fails: Product-based planning derives the product breakdown structure and product descriptions first; quality criteria are documented per product, not used to rank or prioritise products. It tempts because quality criteria are genuinely central to product descriptions, making this the right answer when a question asks what each product description must contain.

It starts by identifying activities and then determines products

Why it fails: PRINCE2 product-based planning reverses this: products are identified first, then the activities and resources needed to deliver them are derived. It tempts because activity-based planning is a legitimate technique elsewhere, and would be correct if the stem described a plan built from a work breakdown of tasks rather than deliverables.

The Project Board meets on a regular basis (e.g., weekly)

Why it fails: Project Board meetings are exception-driven, not regular.

The Senior User chairs the Project Board

Why it fails: The Executive chairs the Project Board.

The Project Board authorizes the Work Packages

Why it fails: The Project Manager authorizes Work Packages.

Authorise a Work Package

Why it fails: Authorising a Work Package is performed by the Project Manager in Controlling a Stage, not by the Project Board during Directing a Project. It is tempting because the Board does authorise stage and project plans, so authorisation language appears throughout the method, but work package approval sits with the Project Manager.

Produce the Highlight Report

Why it fails: The Highlight Report is produced by the Project Manager during Controlling a Stage and circulated to the Project Board; it is an output reported to the Board, not an activity the Board performs. It is tempting because the Board does receive and review Highlight Reports, which would fit a question about governance inputs rather than Directing a Project activities.