PRINCE2 Foundation (PRINCE2F) — Questions 1–75

Controlling a Stage is the process where the Project Manager monitors work against the stage plan, reviewing progress, taking corrective action and reporting via Highlight Reports. The stem's activity of reviewing progress against the stage plan sits squarely within this process, not Managing a Stage Boundary or Directing a Project.

The 'Project Initiation Documentation' (PID) contains the project management team structure and role descriptions. At each stage boundary, the Project Manager should review the PID to ensure the organization is still appropriate. If changes are needed, the PID is updated and submitted for approval. This ensures the Project Board remains effective and has the necessary authority for the next stage, aligning with the 'Continued business justification' principle.

The Project Manager owns the day-to-day management of the project, operating within the tolerances set by the Project Board. This directly satisfies the stem's constraint: the Project Board sets stage tolerances, and the Project Manager manages the stage within them, escalating only when a forecast breach is likely.

Reviewing the lessons log at stage boundaries ensures that lessons are identified, documented, and acted upon throughout the project. This is a direct application of the 'Learn from experience' principle, as it promotes continuous improvement and avoids repeating mistakes in subsequent stages.

This principle requires that a project has a justifiable Business Case and that the justification is reviewed and updated throughout the project, not just at the start. Since the Business Case has not been reviewed since authorization, the project no longer fulfills this principle. The project board must ensure the Business Case remains valid at every stage.

Exceeding the Stage Plan's agreed cost tolerance is a stage-level exception, so the board should direct the project manager to produce an Exception Plan for Stage 3, which replaces the Stage Plan and is approved by the board.

This principle requires that a project has a clear organizational structure, with defined roles such as the Project Board, Project Manager, and Team Manager. It ensures accountability and decision-making authority. In this scenario, establishing the project's organization is essential before initiating the project, aligning with PRINCE2's emphasis on clear roles.

The Product Description records the quality criteria a product must meet and the methods used to verify and accept it, forming the baseline for quality control activities. It thereby defines what acceptance means before work begins, rather than describing tolerances, roles or the quality management approach itself.

The Managing a Stage Boundary process covers preparing the next Stage Plan and, when tolerances are forecast to be exceeded, producing an Exception Plan for the project board to approve, replacing the remainder of the current Stage Plan.

Assessing follows identification in PRINCE2's recommended risk management procedure, covering probability, impact and proximity to produce a risk rating. This satisfies the stem's sequence constraint: the procedure orders identify, then assess, before plan responses and implement. Skipping straight to a response would breach that defined process order.

The learn from experience principle requires that the project team captures and applies lessons throughout the project. By emphasizing this principle, the Project Manager ensures that reviews, lessons logs, and continuous improvement are integral to each stage, addressing the Board's concern.

The Highlight Report is the Project Manager's regular progress report to the Project Board during a stage, covering status, issues, and forecasts. It satisfies the stem's requirement for routine reporting within a stage, unlike End Stage Reports which are produced at stage boundaries.

Continued Business Justification requires the business case to be reviewed and revalidated at every stage boundary and exception, so funding continues only while benefits still outweigh costs and risks. This directly satisfies the stem's viability constraint, since a project whose justification lapses is stopped rather than allowed to drift on.

The Benefits Management Approach is first drafted during Initiating a Project, within the business case theme, defining how benefits will be measured, reviewed and realised. It is baselined as part of the project initiation documentation, satisfying the requirement that benefits management be planned before the project proceeds.

Logging the request in the Issue Register and assessing its impact captures the change before any decision, satisfying the Controlling a Stage activity of issue capture and impact analysis. Only after assessment can the project manager decide whether to escalate or handle within tolerance.

DP includes authorizing initiation.

Management stage boundaries are placed at natural decision points where the project board must authorise the next tranche of work. Aligning stages with major risks and decisions lets the board review viability and commit resources only when uncertainty has been addressed, satisfying the request to divide the project appropriately.

Closing a Project produces the End Project Report, evaluating the project against its original Project Initiation Documentation baseline, including objectives, final performance and lessons. It is created once the project's products have been handed over and accepted.

Directing a Project is the process used by the Project Board to oversee the project throughout its life, providing management direction and decision-making at key points. This satisfies the stem's requirement for board-level oversight across the entire project.

The Project Manager manages stage boundary activities, ensuring the End Stage Assessment is planned and the next stage is prepared. This responsibility sits with the Project Manager under PRINCE2, distinct from the Project Board's authorisation role.

Project Assurance must evaluate the project objectively against business, user and supplier interests. Separating it from the Project Manager prevents self-review, since the manager cannot independently scrutinise their own work, delivering the independent oversight the stem requires.

Approving an Exception Plan is a Project Board decision within Directing a Project, specifically the "Authorise an Exception Plan" activity. This satisfies the stem's constraint that the Board is executing a directing-level process, since Exception Plans escalate beyond Project Manager tolerances and require Board authority to approve.

After the Project Board authorises project initiation in Directing a Project, the Project Manager moves to the Initiating a Project process to create the Project Initiation Documentation. This includes the Business Case, Project Plan, and other key documents. The Project Board's authorisation triggers the start of Initiating a Project, which is the next process in the PRINCE2 process model.

The Team Manager is responsible for providing timely feedback on team progress to the Project Manager because the PRINCE2 role description assigns them the specific duty of reporting on actual progress against the Work Package plan. This satisfies the stem’s constraint of “timely feedback” by requiring the Team Manager to escalate deviations or completed deliverables directly, enabling the Project Manager to update the Project Plan and manage stage tolerances.

Plan responses is a step.

Project Assurance is independent of the Project Manager, monitoring the project on the Project Board's behalf. Project Support provides administrative services such as maintaining the Issue Register and configuration management under the Project Manager's direction.

Project Assurance is the role delegated by the Project Board to monitor all aspects of the project's performance and products independently of the Project Manager, reporting directly back to the Board. That independence is precisely what the stem demands, since the Project Manager cannot assure their own work.

The Project Manager must first evaluate the deviation against the stage plan's tolerances. If the slippage remains within delegated tolerance, corrective action is taken locally; only an anticipated breach of stage tolerance requires escalation to the Project Board.

The Project Initiation Documentation is assembled during Initiating a Project, consolidating the business case, plans, controls and project approach into the baseline the Project Board authorises. It is the process's principal output, satisfying the stem's request for a key deliverable.

Directing a Project is the Project Board's process for ad-hoc direction, covering activities such as authorising the project, giving ongoing direction and responding to exceptions outside the normal Managing a Stage Boundary cycle. It satisfies the stem's requirement for board-level, non-scheduled direction.

An Exception Plan is produced only in response to an Exception Report forecasting that stage tolerances will be breached. Without that forecast breach, the Project Manager follows the normal Managing a Stage Boundary activities, so the Exception Report is the specific trigger.

The End Stage Report is produced within Managing a Stage Boundary, the process triggered as a stage nears completion. It reviews performance against the stage plan and business case, providing the Project Board with the information needed to authorise the next stage. This satisfies the stem's requirement for the process where the Project Manager creates that report.

The Senior User role represents the interests of those who will use the project's products and is accountable for ensuring that the project delivers the expected benefits. In a commercial environment, the Senior User ensures the supplier's deliverables meet user needs and enable benefit realization.

The Project Controls section of the Project Initiation Documentation explicitly defines the project's governance framework, including the reporting arrangements, tolerance levels for time, cost, scope, quality, risk, and benefit, and the escalation procedures. It is the correct place to document how the project will be controlled at each management level, ensuring the project board can manage by exception.

The Project Initiation Documentation is assembled during Initiating a Project and consolidates the Project Plan, business case, and controls into a single baseline. It explicitly defines how the project will be managed, satisfying the stem's requirement for the management approach document produced in that process.

Project Assurance provides the Project Board with independent, objective scrutiny of the project's management, checking that PRINCE2 is applied correctly. It sits outside the Project Manager's line of command, giving the Board confidence that progress, plans and the Business Case are sound.

The risk owner owns and manages the risk, monitoring it and selecting responses, while the risk actionee carries out the agreed response actions. This division of accountability satisfies the stem's requirement to distinguish the two roles precisely.

The End Project Report includes a review of the project's performance against its baselines (e.g., scope, time, cost, quality). This provides the project board with an assessment of whether the project delivered what was expected. It is a key component for evaluating project success and informing lessons learned.

Progress is the theme that compares actual achievement against the plan baseline, using checkpoint, highlight and end stage reports. It supplies the monitoring mechanism the stem asks for, distinct from Plans, which only define the baseline.

The Chair owns the review's conduct, keeping it focused on objectives, managing the reviewers, and confirming the review achieves its purpose. That accountability for effective running of the review sits with the Chair, not the presenter or reviewers.

The Project Brief is the primary output of Starting Up a Project, capturing the outline business case, scope and project approach. It is then refined into the Project Initiation Documentation during the Initiating a Project process.

Focus on products means that the project is driven by the definition and delivery of products, including their quality criteria. This principle ensures that before work starts, the product description defines what the product must do and how it will be judged fit for purpose, directly answering the team manager's question.

This principle requires that the project has an organizational structure with defined roles and responsibilities, including the project board representing business, user, and supplier interests. By defining these roles and ensuring accountability, the project manager is directly applying this principle, which is essential for effective governance and decision-making throughout the project lifecycle.

An RFC proposes modifying a baselined product, whereas an Off-specification records where a product fails to meet its agreed requirements. This separates proposed change from identified non-conformance, satisfying the stem's requirement to distinguish the two PRINCE2 change control types.

Exception Reports go to the Project Board, which responds through Directing a Project. That process provides the board's decision-making activities, including authorising corrective action, so it is where the response to a forecast tolerance breach is agreed.

Accountability and execution are separated: the risk owner owns the risk and is answerable for its management, while the risk actionee carries out the agreed response actions. This division satisfies the stem's requirement to distinguish the two PRINCE2 risk roles.

An RFC formally proposes an alteration to baselined products or scope, whereas an off-specification records that a product has failed to meet a specified requirement. This distinction separates proactive change requests from actual non-conformance, matching the stem's contrast between proposed change and unmet specification.

The Project Board holds ultimate accountability for the project's success, since it owns the business case and authorises each stage. This satisfies the stem's requirement for a true statement about the Board's role, distinguishing accountability from the Project Manager's day-to-day responsibility.

Focus on products requires that the project is driven by the definition and delivery of products, not just by activities. Defining products and their quality criteria first ensures that planning is based on what must be delivered and to what standard. This approach helps avoid scope creep and ensures that activities are only included if they contribute to a defined product.

In PRINCE2, the Team Manager reports to the Project Manager, who owns day-to-day delivery within the project's tolerances. Escalating a potential delay to Sarah Lee therefore follows the defined line of authority rather than bypassing it.

The supplier delivered a product that fails to meet its agreed product description, yet remains usable. PRINCE2 classifies any such failure to meet specification as an off-specification issue, distinct from a change request or a general concern, so this correctly matches the stem's scenario.

Manage by exception mandates that the Project Manager only escalates when a tolerance is forecast to be exceeded. Here, the cost tolerance is at risk, so the Project Manager should escalate to the Project Board, providing an exception report and seeking a decision on how to proceed.

Managing a Stage Boundary is the process triggered at each stage end, producing the End Stage Report on current performance and the Next Stage Plan. It satisfies the stem's dual requirement of planning the next stage while reporting on the stage just completed.

The defect is a problem requiring management action, so it is logged in the issue register and handled through the Controlling a Stage process, where the project manager assesses, prioritises and escalates it. Configuration item records track products and versions, not defect resolution.

The Project Manager owns the day-to-day management of the project, operating within the tolerances delegated by the Project Board. This directly satisfies the stem's constraint: PRINCE2 assigns the Project Manager authority to run the stage, while the Board retains control only at tolerance breaches or exception situations.

Directing a Project is the process where the project board makes key decisions, including authorizing the project once the PID is complete. The board reviews the PID, ensures the Business Case is viable, and gives approval to proceed to the next stage. This is the correct authority because the board owns the project's direction, not the project manager.

The Business Case justifies the project's investment and forms part of the Project Initiation Documentation, alongside the Project Product Description, Project Approach, and Project Controls. It satisfies the requirement to identify a genuine PID component, capturing the reasons and benefits underpinning the project.

The Product Status Account provides a snapshot of the current state of each product in the project, recording which are complete, in progress or approved. It gives the project manager visibility of product status for reporting and control.

When a stage plan shows tolerance for time will imminently be exceeded, the project manager escalates by issuing an exception report to the project board, which decides how to respond. This satisfies PRINCE2's tolerance-escalation principle before the deviation actually occurs.

Product-based planning begins by creating a product breakdown structure, decomposing the final product into its component products. This hierarchical decomposition precedes writing product descriptions and producing the product flow diagram, satisfying the stem's requirement for the first step.

The Stage Plan details the activities, resources and costs for one management stage, forming the basis for stage-level control. It satisfies the requirement for a document covering a single management stage's detailed activities, resources and costs.

The Project Manager should first attempt to correct the situation within the stage tolerance. If the work package is likely to exceed its cost tolerance, the Project Manager can take corrective action, such as reallocating resources or negotiating changes, as long as the stage tolerance is not breached.

The End Project Report is produced during Closing a Project, where the Project Manager evaluates the project against its original baselined Business Case, verifies acceptance of products, and captures lessons learned before the project is formally disbanded.

The Executive owns the Business Case and is accountable for ensuring the project remains aligned with business objectives and delivers value for money. This role-specific accountability directly satisfies the stem's requirement for whoever confirms continuing business justification.

Reports flow along distinct accountability lines: the Highlight Report gives the Project Board progress against the Stage Plan at agreed intervals, while the Checkpoint Report gives the Project Manager progress against the Work Package at frequencies set in that Work Package.

The Project Initiation Documentation is the consolidated baseline document that must exist for the Initiation Stage to close, containing the Business Case, plans, controls and project approach. Its approval by the project board is what authorises the project to proceed, satisfying the stem's completion requirement.

The End Stage Report reviews actual versus planned performance for the closing stage and provides the Project Board with the information needed to approve the next Stage Plan, satisfying the boundary's dual reporting and authorisation purpose.

Because the deviation stays within stage tolerances, the Project Manager retains authority and handles it at stage level without escalation. Corrective action restores the work package to plan, satisfying the stem's condition that tolerances are not exceeded.

An Exception Plan is triggered when the Project Board approves an Exception Report, since the board has agreed corrective action is needed. The Project Manager then plans how to recover from the tolerance breach, replacing the remainder of the current Stage Plan.

Exception-driven meetings occur only when tolerances are breached or a stage boundary needs authorising, rather than at fixed intervals. This suits PRINCE2's principle of management by exception, letting the Project Board govern without routine attendance, though they must still meet at each stage boundary.

The project controls section of the PID defines the tolerance levels for the project and the escalation procedures if tolerances are forecast to be exceeded. It specifies what actions will be taken if the project exceeds its tolerances. Therefore, this section directly answers the project board chair's question about what will happen in such a scenario.

The Team Manager accepts Work Packages from the Project Manager and is accountable for delivering their contents to the agreed tolerances, allocating work and reporting progress. This delivery-focused accountability distinguishes the role from the Project Manager, who manages the stage rather than individual Work Packages.

The Team Manager is responsible for Work Package delivery.

Project Assurance operates independently of the Project Manager, reporting directly to the Project Board. This separation from the delivery team is what satisfies the stem's requirement for independent assurance that the project is being managed correctly.