PRINCE2 Processes practice questions

Initiating a Project

Why it fails: This process happens after authorization to initiate has been given.

Starting up a Project

Why it fails: This process prepares the project but does not give approval to initiate.

Managing a Stage Boundary

Why it fails: This process ends a stage, not initiates the project.

Revise the Stage Plan and resubmit it to the project board

Why it fails: While possible, the immediate action is to report the issue; revision may come later.

Escalate to the program or corporate management for a decision

Why it fails: The project manager should first use the Exception Report to the project board.

Proceed with the next stage as planned, then report to the project board at the next review

Why it fails: This ignores the board's rejection and is not allowed.

Business Case

Why it fails: The Business Case is developed in parallel but not the primary input for the plan.

Risk Register

Why it fails: The Risk Register is created during planning, not an input to the Project Plan.

Configuration Item Records

Why it fails: These are not used at this stage for the Project Plan.

It is the process where the project board reviews the Business Case.

Why it fails: Business Case reviews happen in other processes.

It is the process where the project manager authorizes work packages.

Why it fails: Authorization of work packages occurs in Controlling a Stage.

It is the process where the Stage Plan is created for the next stage.

Why it fails: Stage Plans are created in Managing a Stage Boundary.

The project manager is appointed during this process.

Why it fails: The project manager is appointed during Starting up a Project, before Initiating a Project begins, so this cannot occur within the process. It is tempting because the project manager owns and drives Initiating a Project, but appointment precedes that activity rather than forming part of it.

The Project Initiation Documentation is created in Starting up a Project.

Why it fails: The Project Initiation Documentation is assembled during Initiating a Project, not Starting up a Project, which only produces the project brief and appoints the project manager. It is tempting because Starting up a Project does create the brief that feeds the PID, but the PID itself is a later, separate deliverable.

The project brief is created during this process.

Why it fails: The project brief is produced in Starting up a Project and is a prerequisite input to Initiating a Project, which builds the PID from it. It is tempting because Initiating a Project does refine and expand brief content, but the brief's creation belongs to the preceding process.

Update the project plan to reflect the actual cost.

Why it fails: Updating the plan comes after the issue is resolved; first, escalate the exception.

Record the actual cost and continue with the project.

Why it fails: The actual cost exceeds tolerance, so an exception report is needed before continuing.

Accept the variance as the work package is complete.

Why it fails: The variance exceeds the 10% tolerance, so it cannot be accepted without escalation.

Directing a Project

Why it fails: DP authorizes plans.

Controlling a Stage

Why it fails: CS manages current stage work.

Initiating a Project

Why it fails: IP is only at the start.

Project Brief

Why it fails: The Project Brief is created in the Starting Up a Project process, not in Initiating a Project. The key output of Initiating a Project is the Project Initiation Documentation (PID), which refines and expands the Brief into a detailed baseline for execution. It is tempting because the Project Brief provides the initial high-level justification and scope, and would be the correct output if the question asked about the Starting Up a Project process instead.

End Stage Report

Why it fails: The End Stage Report summarises progress against the current stage’s plan and is produced at the end of each management stage, not during the Initiating a Project process. It is tempting because it is a key document for stage boundaries, but the question asks for the output of project initiation, which is the Project Initiation Documentation. The End Stage Report would be correct if the question referred to a stage boundary review.

Exception Report

Why it fails: The Exception Report documents a forecast deviation from tolerance during a stage, produced in Managing a Stage Boundary, not Initiating a Project. It is tempting because both are PRINCE2 reports, but Initiating a Project's key output is the Project Initiation Documentation, which consolidates the business case and plans.

To approve the project mandate

Why it fails: Approving the project mandate is the mandate's own authorisation step, performed by the project board before Starting Up a Project begins. The process is tempting because it does examine the mandate, but its purpose is producing the Project Brief and appointing the project board.

To manage the delivery of products

Why it fails: Managing product delivery is the Managing Product Delivery process, which controls work packages during the delivery stages. It is tempting because Starting Up a Project does plan the work, but its purpose is preparing the Project Brief and stage plan for initiation, not delivering products.

To develop the Project Initiation Documentation

Why it fails: Developing the Project Initiation Documentation belongs to Initiating a Project, which runs after the project board authorises the initiation stage. It is tempting because Starting Up a Project assembles the Project Brief, the PID's precursor, but the full PID is created later.

Close the project immediately as the Business Case is no longer viable

Why it fails: Exceeding stage cost tolerance triggers escalation to the Project Board, which decides whether to authorise a Exception Plan or stop the project; the Project Manager cannot unilaterally close it. Closing is tempting when the Business Case is genuinely no longer viable, but that judgement belongs to the Board.

Continue with the current plan and report the overrun in the next Highlight Report

Why it fails: A forecast breach of stage cost tolerance is an exception that must be escalated immediately, not deferred to the next Highlight Report. Continuing and reporting later is tempting because Highlight Reports do communicate progress, but they follow the event rather than triggering the required exception process.

Request more budget from the Project Board

Why it fails: Requesting more budget directly bypasses the exception process; the Project Manager must escalate via an Exception Report so the Project Board can decide. It is tempting because the Board controls budget, but the Project Manager cannot unilaterally request funds outside the agreed tolerances.

SU produces the Stage Plan for the initiation stage, while IP produces the Project Plan

Why it fails: Both statements are true but not the best distinguishing description.

SU is performed by the Project Board, while IP is performed by the Project Manager

Why it fails: SU is led by the Executive/PM; IP is led by the PM.

SU selects the project mandate, while IP develops the project brief

Why it fails: The project mandate is an input; SU produces the Project Brief.

Authorize overtime to compensate for the lost time

Why it fails: Overtime may be one option after assessment, but not the first action.

Update the project plan to reflect the delay

Why it fails: The project plan is updated at stage boundaries, not during a stage.

Escalate immediately to the Project Board as a potential exception

Why it fails: Escalation is only needed if tolerances are forecast to be exceeded.

To deliver the project's products

Why it fails: Delivering products is the Managing a Stage Boundary and Controlling a Stage work, executed by the Project Manager, not the board. Directing a Project covers board-level decisions: authorising initiation, the project, stage boundaries, and closure. It is tempting because the board ultimately owns the project's outcomes, but delivery is delegated.

To plan the next stage

Why it fails: Planning the next stage is the purpose of Managing a Stage Boundary, which prepares the next Stage Plan for the board's approval. Directing a Project instead authorises that plan and gives ad hoc direction. Stage planning is tempting because the board reviews plans, but the actual planning activity sits with the managing level.

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

Why it fails: Day-to-day management is the purpose of Managing a Stage Boundary's counterpart, Controlling a Stage, where the Project Manager authorises work packages and monitors progress. Directing a Project is a board-level process providing direction and decisions. Daily management is tempting because it sounds like overall project leadership, but it is delegated below the board.

Benefits Management Approach

Why it fails: The Benefits Management Approach is created during Initiating a Project, defining how benefits will be measured and reviewed. It is tempting because the Business Case originates in Starting Up a Project, but the Benefits Management Approach itself is not a Starting Up a Project output.

End Project Report

Why it fails: The End Project Report is produced during Closing a Project, confirming project closure and reviewing performance. It is tempting because Starting Up a Project also handles project boundaries, but the End Project Report belongs to the closing process, not the pre-project start-up.

Project Initiation Documentation

Why it fails: The Project Initiation Documentation is assembled during Initiating a Project, after the Project Board authorises the project. It is tempting because Starting Up a Project produces the Project Brief, which the PID later expands, but the PID itself is not a Starting Up a Project output.

The Highlight Report is a written document, while the Checkpoint Report is always verbal

Why it fails: Both can be written or verbal depending on the project.

The Highlight Report covers the entire project, while the Checkpoint Report covers only a specific Work Package

Why it fails: Highlight Report covers the stage; Checkpoint Report covers a Work Package.

The Highlight Report is produced at the end of each stage, while the Checkpoint Report is produced weekly

Why it fails: Frequency varies; Highlight Reports are typically more frequent than stage-end.

End Stage Report

Why it fails: An End Stage Report is produced by the Managing a Stage Boundary process at the close of each management stage, not during Initiating a Project. It is tempting because both are assurance documents reviewed by the project board, yet the End Stage Report summarises stage performance, whereas initiation outputs the PID.

Project Brief

Why it fails: The Project Brief precedes initiation; it is an input the project board uses to authorise the Project Initiation Documentation. Initiating a Project produces the PID, which consolidates the business case, plans and controls. The Brief is tempting because it also describes the project, but it is created during pre-project starting up a project.

Exception Report

Why it fails: The Exception Report documents a forecast deviation from tolerance for the project board's decision; it is produced during Managing a Stage Boundary or Controlling a Stage, not Initiating a Project. It is tempting because both are project-board-facing documents, but the Exception Report is correct only when tolerances are threatened.

Business Case

Why it fails: The Business Case justifies the investment and confirms continued viability; it does not define control mechanisms. It is tempting because it is a core PID component produced during Initiating a Project, but the controls section of the PID, not the Business Case, describes how the project is controlled.

Project Plan

Why it fails: The Project Plan defines the project's products, schedule and tolerances, but the Project Initiation Documentation's controls section defines how the project is controlled. The Project Plan is tempting because it is produced during Initiating a Project, yet it addresses delivery, not the control approach.

Stage Plan

Why it fails: A Stage Plan covers one management stage's products, activities and tolerances, so it cannot define project-level control. It is tempting because stage plans are created during Initiating a Project for the next stage, but the PID's controls section, not a Stage Plan, specifies how the project is controlled.

Checkpoint Report

Why it fails: A Checkpoint Report is a progress-monitoring product produced during stage execution, not a component assembled in the PID at initiation. It is tempting because it belongs to the same PRINCE2 product family and is genuinely required for stage control, but it would be the correct answer only when asked which products a Work Package or stage review generates.

End Stage Report

Why it fails: The End Stage Report is produced at a stage boundary to summarise performance, so it cannot be part of the PID, which is approved before delivery begins. It is tempting because it references the PID's baselines, and would be the right answer if the question asked for managing a stage boundary outputs.

Lessons Report

Why it fails: The Lessons Report is created at the end of a stage or project and sits outside the PID, which is baselined during initiation. It is tempting because lessons logs feed the PID's risk and business case content, and would be correct if the question asked for outputs of closing a project.

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

Why it fails: Managing day-to-day activities belongs to Controlling a Stage, where the project manager authorises work packages, monitors progress and handles issues. It is tempting because both processes involve active project management, but Starting Up a Project precedes the project itself, producing the project brief and appointing the project board before initiation begins.

To close the project in a controlled manner

Why it fails: Closing the project in a controlled manner is the purpose of the Closing a Project process, which confirms acceptance, reviews benefits and produces the end project report. It is tempting because both processes bookend the project lifecycle, but Starting Up a Project instead creates the project mandate, appoints the executive and project manager, and produces the project brief.

To develop the Project Initiation Documentation

Why it fails: Developing the Project Initiation Documentation belongs to Initiating a Project, which builds the PID after the project mandate is approved. It is tempting because Starting Up a Project produces the Project Brief, a PID input. Starting Up a Project instead appoints the team and validates the mandate.

Exception Report

Why it fails: An Exception Report is produced during Managing a Stage Boundary when tolerances are forecast to be exceeded, not during Initiating a Project. It tempts because it is a genuine PRINCE2 management product, and it would be the correct output when a stage or project is predicted to breach its agreed tolerances.

Project Brief

Why it fails: The Project Brief is the input that Initiating a Project builds upon, being produced during Starting up a Project; the process's key output is the Project Initiation Documentation. It tempts because it is the central pre-project document, and it is the correct answer when asked for the key output of Starting up a Project.

End Stage Report

Why it fails: An End Stage Report is created in Managing a Stage Boundary to review a completed stage, not in Initiating a Project. It tempts because it is a legitimate PRINCE2 report, and it would be the correct output when a stage boundary is being assessed before the next stage is authorised.