PeopleCert PRINCE2 Practitioner Practice Test

Practice PeopleCert PRINCE2 Practitioner with free sample questions, timed mock exams, and detailed explanations for PRINCE2 governance and scenario decisions.

PRINCE2 Practitioner (v7) is about applying the method in realistic project situations rather than just recalling terms. If you are searching for PRINCE2 Practitioner sample exam questions, a practice test, or an exam simulator, this is the main PM Mastery page to start on web and continue on iOS or Android with the same account.

Interactive Practice Center

Start a practice session for PRINCE2 Project Management Practitioner (Version 7) below, or open the full app in a new tab. For the best experience, open the full app in a new tab and navigate with swipes/gestures or the mouse wheel—just like on your phone or tablet.

Open Full App in a New Tab

A small set of questions is available for free preview. Subscribers can unlock full access by signing in with the same account they use on web and mobile.

Use on iPhone or Android too: PM Mastery on the App Store or PM Mastery on Google Play using the same account you use on web. The same subscription works across web and mobile.

What this PRINCE2 Practitioner practice page gives you

  • A direct path into the PM Mastery simulator for PRINCE2 Practitioner.
  • Scenario-based drills that emphasize applied governance judgment and tailoring decisions.
  • Mixed sets and timed practice built around practitioner-style case interpretation.
  • Detailed explanations that show why the strongest PRINCE2 response is best.
  • A clear web-to-mobile continuation path with the same account.

PRINCE2 Practitioner exam snapshot

  • Vendor: PeopleCert
  • Official exam name: PRINCE2 Project Management Practitioner (Version 7)
  • Exam label: PRINCE2 Practitioner (v7)
  • Assessment style: open-book, scenario-based application exam
  • Marks available: 70
  • Time limit: 150 minutes

Practitioner rewards deliberate scenario reading. Strong performance usually comes from identifying the missing control, tailored response, role responsibility, or management-product update before you look at the answer choices.

Topic coverage for PRINCE2 Practitioner practice

TopicWeightEstimated emphasis
Learning Outcome 1: Key concepts relating to projects and PRINCE23%Low
Learning Outcome 2: PRINCE2 principles8%Moderate
Learning Outcome 3: People in successful projects14%Moderate
Learning Outcome 4: PRINCE2 practices60%Very high
Learning Outcome 5: PRINCE2 processes15%High

How to use the PRINCE2 Practitioner simulator efficiently

  1. Start with scenario-based drills focused on one learning outcome at a time.
  2. Review every explanation until you can defend why the best answer is the best PRINCE2 action, not just why it looks familiar.
  3. Move into mixed sets once you are comfortable switching between controls, roles, practices, and process decisions.
  4. Finish with full timed runs to rehearse long-form scenario pacing and answer discipline.

Free preview vs premium

  • Free preview: a smaller set on web so you can validate the scenario style and explanation depth.
  • Premium: the full PRINCE2 Practitioner practice bank, focused drills, mixed sets, timed mock exams, detailed explanations, and progress tracking across web and mobile.

24 PRINCE2 Practitioner sample questions with detailed explanations

These sample questions include the same mix of single-answer and multiple-response items you should practice for PRINCE2 Practitioner. Use them to check your readiness here, then move into the full PM Mastery question bank for broader timed coverage.

Question 1

Topic: Learning Outcome 4: PRINCE2 practices

On a customer data platform project, a Senior User asks the Project Manager to “just add” an extra dashboard widget to support a new regulatory report. The Project Manager is unsure whether this should be treated as a change request or handled within existing authority, and the request has not yet been logged.

What information should the Project Manager obtain/verify FIRST before deciding how to handle the request?

  • A. Who has delegated authority to decide this issue and what records must be updated
  • B. Whether the request increases overall project risk exposure beyond tolerance
  • C. Whether the supplier can provide resources to build the widget this week
  • D. Whether the existing product acceptance criteria already include the widget

Best answer: A

Explanation: Before acting on an issue, PRINCE2 expects it to be captured and handled using the agreed issue management approach. That approach clarifies who can make which decisions (delegated authority/change authority) and what must be recorded and reported. Without confirming authority and required records, the Project Manager risks bypassing governance and losing auditability.

The issue management approach is the project’s agreed way of handling issues consistently and with the right governance. In this scenario, the Project Manager cannot decide “how to handle” the request until they know who is authorized to make the decision (e.g., Project Board or a delegated Change Authority) and what must be logged/reported (e.g., create an Issue Register entry and, if required, an Issue Report for decision).

An effective issue management approach typically covers:

  • Roles and responsibilities (who captures, analyses, decides, and owns issues)
  • Procedures (capture, assess, recommend, decide, implement, close)
  • Authority and delegation (decision rights and escalation routes)
  • Records and reporting (Issue Register, Issue Reports, tracking status)

Impact, risk, and resourcing analysis are important, but they are performed within this defined procedure and under the right decision authority.


Question 2

Topic: Learning Outcome 5: PRINCE2 processes

A Project Manager is about to start development work with an in-house delivery team on a PRINCE2 project. A Team Manager has been appointed, but the team has not yet started work. The Project Board wants clear control of the interface between the Project Manager and the delivery team while allowing day-to-day delivery to be managed by the Team Manager.

Select TWO statements that correctly describe what should happen next when applying Managing Product Delivery.

  • A. The Project Board should authorize the Work Package before the Team Manager starts any work.
  • B. The Project Manager should update the Stage Plan with detailed team tasks before issuing the Work Package.
  • C. The Team Manager should provide Checkpoint Reports to the Project Manager as agreed and, when products are complete, hand them over for approval.
  • D. The Team Manager should send a weekly Highlight Report to the Project Manager to show progress.
  • E. The Project Manager should issue a Work Package defining required products, quality criteria, tolerances, and reporting arrangements for the Team Manager to accept.
  • F. The Project Manager should create and maintain the Team Plan for the delivery team to follow.

Best answers: C, E

Explanation: Managing Product Delivery exists to control the interface between the Project Manager and the delivery teams. In practice, this is done by agreeing and authorizing work via Work Packages, and then controlling progress and product handover through agreed reporting and acceptance of completed products.

Managing Product Delivery ensures that the delivery team(s) create the specialist products as required, while the Project Manager retains control through a clear, agreed interface. The key mechanisms are:

  • The Project Manager authorizes work by issuing a Work Package that defines what is to be delivered (including quality expectations), plus constraints and reporting.
  • The Team Manager accepts the Work Package, manages day-to-day delivery, reports progress via Checkpoint Reports, and delivers completed products back to the Project Manager for approval.

This maintains manage-by-exception by giving the team freedom to deliver within agreed constraints while keeping the Project Manager informed using the correct PRINCE2 controls.


Question 3

Topic: Learning Outcome 4: PRINCE2 practices

A construction supplier reports that the only available low-carbon concrete (needed to meet a published sustainability commitment in the Business Case) will add $180,000 to the current stage forecast. The stage cost tolerance is +$100,000, and using standard concrete would keep costs within tolerance but increases the risk of failing the sustainability commitment and reducing forecast benefits.

The Project Manager needs the best management product as evidence to validate the situation and obtain a decision from the Project Board.

Which management product should be used?

  • A. Checkpoint Report
  • B. Risk Register
  • C. Exception Report
  • D. Highlight Report

Best answer: C

Explanation: Because the preferred risk response (to protect sustainability benefits) drives a forecast cost over the agreed stage tolerance, the Project Manager must manage by exception. An Exception Report provides the Project Board with validated impacts, options (e.g., accept risk, change scope, increase budget), and the recommendation needed to decide how commercial constraints change the risk response.

In PRINCE2, commercial constraints (e.g., fixed budgets and tolerances) can limit which risk responses are viable, and sustainability commitments can change both the level of risk exposure (benefits/reputation impact) and the preferred response. Here, the sustainability-driven mitigation increases the stage forecast beyond the delegated +$100,000 tolerance, so the Project Manager can no longer proceed within authority.

An Exception Report is used to escalate the exception, validate the forecast breach, and present decision-ready information to the Project Board, typically including:

  • What tolerance will be exceeded and why
  • The sustainability/benefits implications of alternative responses
  • Options, recommendation, and required decisions

Routine reports and registers support monitoring, but they are not the control product for seeking authority when tolerances will be breached.


Question 4

Topic: Learning Outcome 4: PRINCE2 practices

You are the Project Manager for a digital citizen-portal project. Delivery is by a supplier Scrum team working in 2 week sprints, but the Project Board requires PRINCE2 stage boundaries and monthly Highlight Reports. The current stage has agreed tolerances of 10% cost and 1 week time.

Which planning approach is NOT aligned with PRINCE2 governance and controls for this delivery context?

  • A. Plan the stage as sprint milestones with time/cost tolerances
  • B. Let the Scrum team change stage scope/dates without escalation
  • C. Use rolling wave planning at each stage boundary
  • D. Define Work Packages using backlog items and acceptance criteria

Best answer: B

Explanation: PRINCE2 allows agile planning techniques (e.g., sprints, backlogs, rolling wave) as long as governance remains through approved Stage Plans, agreed tolerances, and manage-by-exception. Team-level replanning is fine within delegated authority, but changing stage scope or dates without escalation undermines the Project Manager’s control and the Project Board’s accountability for tolerances.

The Plans practice can be tailored to an agile delivery approach by combining PRINCE2’s management levels with agile team planning. The Project Board governs via stage approvals and tolerances, while the Project Manager controls progress against the Stage Plan and only escalates when forecasts indicate tolerances may be exceeded.

In this scenario, it is appropriate to express the Stage Plan in terms of sprint/release milestones, use rolling wave planning to refine detail as information emerges, and package work using Work Packages that reference backlog items and clear acceptance criteria. What is not acceptable is bypassing change/issue control by allowing the delivery team to alter stage scope or dates without the Project Manager assessing impact and escalating when tolerances are threatened.


Question 5

Topic: Learning Outcome 3: People in successful projects

Halfway through a management stage, the Team Manager reports that a newly discovered data-retention requirement will add two weeks and \(\$45{,}000\) to the stage forecast. This will exceed the agreed stage tolerances. The change is not yet approved, but it affects compliance and could undermine the Business Case if delayed.

As Project Manager, what is the MOST appropriate next step to support effective Project Board decision making?

  • A. Request the Project Board to authorize the work via a Work Package
  • B. Produce an Exception Plan and replace the current Stage Plan immediately
  • C. Create and submit an Exception Report with impacts and options
  • D. Update the Issue Register and wait for the next Highlight Report cycle

Best answer: C

Explanation: When forecasts show stage tolerances will be exceeded, PRINCE2 uses manage-by-exception: the Project Manager escalates to the Project Board. An Exception Report is the key input that enables effective board decision making because it summarizes the situation, impacts (including on the Business Case), and viable response options. The board can then decide whether to request an Exception Plan or take other action.

Effective Project Board decision making is timely, unambiguous, and based on decision-ready inputs (impacts, options, and recommendations) at the right control points. Here, the new compliance requirement causes a forecast breach of stage tolerances, so control must shift from the Project Manager to the Project Board.

The appropriate next step is to:

  • Document the situation and options in an Exception Report
  • Include impacts on time/cost/scope, risks, and the Business Case
  • Submit it to the Project Board for a decision (e.g., request an Exception Plan, change scope, or stop)

Producing other records may still be needed, but they do not provide the governance trigger and decision package required when tolerances are forecast to be exceeded.


Question 6

Topic: Learning Outcome 3: People in successful projects

A project is refurbishing 20 regional offices. During delivery of Stage 2, the corporate Sustainability Office (outside the project’s delivery organization) asks that all flooring and paint meet a new low-emissions standard to support a public net-zero commitment.

The Project Manager estimates this would add 1 week and 6% cost to the Stage 2 plan, still within stage tolerances (2 weeks and 10% cost). What is the correct PRINCE2 next step?

  • A. Update the Stage Plan and issue new Work Packages to the teams
  • B. Update the PID and request the Project Board to re-authorize the project initiation
  • C. Produce an Exception Report to the Project Board because the quality expectations have changed
  • D. Record it as an issue, assess options and impacts (including sustainability benefits), and submit an Issue Report for approval

Best answer: D

Explanation: The Sustainability Office’s request changes stakeholder expectations and may change the project’s value proposition, so it must be handled through issue and change control. Because the forecast impact remains within tolerances, the Project Manager should capture and assess the request, then seek the appropriate approval using the issue management products rather than escalating as an exception or immediately replanning.

In PRINCE2, a new or changed sustainability expectation from a stakeholder is handled as an issue (typically a request for change) so that its impacts on scope, quality, time, cost, risk, and benefits can be evaluated. The Project Manager should first record the request and analyze options, including how meeting the sustainability standard affects stakeholder acceptance and the project’s benefits/value. Because the forecast impact is within stage tolerances, this stays within normal change control: prepare an Issue Report with the impact assessment and recommendation and send it to the change authority (or Project Board) for a decision. Only after approval should plans, product descriptions, and baselines be updated and communicated.


Question 7

Topic: Learning Outcome 4: PRINCE2 practices

A Team Manager reports that the supplier has delivered the first version of the “Customer Data Migration Script”. During integration testing, the team finds it fails one acceptance criterion in its Product Description (it drops records with non-standard characters). The fix is expected to take 3 days and can be absorbed within the Work Package and stage tolerances.

The Project Manager wants objective evidence to decide whether the product is ready to be handed over for formal acceptance.

Which management product is the BEST source of evidence to validate acceptance readiness?

  • A. Highlight Report to the Project Board
  • B. Issue Report raised for the defect
  • C. Checkpoint Report from the Team Manager
  • D. Quality Register entry with the latest quality check results

Best answer: D

Explanation: Acceptance readiness should be validated using the recorded results of quality activities against the product’s defined criteria. The Quality Register (and its referenced quality records) shows what checks were performed, the outcomes, and whether rework is still outstanding. This gives the Project Manager auditable evidence to decide if the product can proceed to acceptance.

In PRINCE2, a defect or nonconformance found during a quality check means the product has not yet met its stated acceptance/quality criteria. The Project Manager needs evidence of whether the required quality methods have been applied and what the outcomes were, not just a status narrative.

The Quality Register is the control record that logs planned and completed quality activities and references the results (e.g., test outcomes, review records). For this scenario, the latest entry for the migration script will show the failed acceptance criterion and, after rework, the subsequent pass result, providing objective proof of acceptance readiness. The Issue Report helps manage the defect, but it is not the primary evidence that acceptance criteria have been met.


Question 8

Topic: Learning Outcome 5: PRINCE2 processes

You are the Project Manager and are finalizing the PID during Initiating a Project. A Senior User asks you to “just add” a new analytics dashboard to the agreed scope. The Senior Supplier says the effort and cost impact are unclear, and you are not sure whether you can approve the change yourself or must refer it to the Project Board.

What information should you obtain or confirm FIRST (as part of the PID) before deciding how to proceed?

  • A. The change management approach, including change authority and tolerances
  • B. The dashboard’s acceptance criteria in a Product Description
  • C. The dashboard’s risk exposure rating in the Risk Register
  • D. An updated benefits forecast in the Business Case

Best answer: A

Explanation: Before acting on a requested scope change, you must know the project’s agreed decision rights and escalation rules. In PRINCE2 these are defined in the PID through the change management approach (and associated controls/tolerances), which supports governance and clear communication about how change requests will be handled.

The PID is the baseline for how the project will be governed, controlled, and communicated once authorized. When a stakeholder requests a scope change during initiation, the first need is to confirm the agreed mechanism for handling change: who has delegated authority to approve changes, what information is required for assessment, and when something must be escalated as an exception.

In the PID, this is set out in the change management approach (and linked project controls), which typically clarifies:

  • How change requests/issues are logged and assessed
  • Decision-making authority (e.g., Project Board vs delegated change authority)
  • How tolerances/impact thresholds drive escalation

Without that, you cannot correctly decide whether to approve, defer, or escalate the request.


Question 9

Topic: Learning Outcome 5: PRINCE2 processes

During a stage of a customer-portal upgrade project, the Project Manager is repeatedly surprised by delays and rework from the development Team Managers. Different team leads report progress in different formats and at irregular times. Developers say “requirements keep changing” because Senior Users approach them directly with new requests, and the team often starts work immediately to “stay busy”. Several delivered products are rejected because acceptance criteria were not agreed upfront.

In PRINCE2 terms, what is the most likely underlying cause?

  • A. The Project Manager is not producing Highlight Reports frequently enough for the Project Board
  • B. The Senior Users are not attending enough workshops, so decisions are made late
  • C. The stage is under-resourced, so progress reporting is delayed and work is rushed
  • D. Work Packages are not being properly authorized with clear Product Descriptions, tolerances, and agreed checkpoint reporting

Best answer: D

Explanation: These symptoms point to weak Work Package control within the stage: work is starting without authorization, acceptance criteria are unclear, and progress is not being monitored through agreed checkpoint reporting. In PRINCE2, well-defined and authorized Work Packages set delivery expectations (products, quality, tolerances) and establish how the Team Manager will report, preventing uncontrolled scope changes and rework.

In Controlling a Stage, the Project Manager controls delivery by authorizing Work Packages to Team Managers and then monitoring progress against what was agreed. A Work Package should make it clear what products are to be created (via Product Descriptions and quality/acceptance criteria), the constraints/tolerances, and how often and in what format progress will be reported (e.g., Checkpoint Reports).

If work starts before a Work Package is agreed and authorized, the team can accept “new requests” informally, products are built against shifting expectations, and the Project Manager loses visibility until problems surface. Tightening Work Package definition, authorization, and checkpoint reporting restores control while keeping escalation by exception when tolerances are forecast to be exceeded.


Question 10

Topic: Learning Outcome 4: PRINCE2 practices

A government team is delivering a new citizen-facing web service in a 12-week timebox using 2-week agile sprints. The Project Board requires formal approval to proceed at two points: after the MVP is demonstrated, and before a public launch (due to reputational risk).

As a tailoring decision, how should the Project Manager define and use stages to keep PRINCE2 control effective without adding unnecessary bureaucracy?

  • A. Make each 2-week sprint a management stage, requiring a Stage Plan and Project Board approval every sprint
  • B. Set management stages around the two Board decision points, with sprints treated as technical stages within each management stage
  • C. Define management stages as UX, build, test, and deploy phases because these are the team’s technical handoffs
  • D. Run the whole 12-week delivery as one management stage and use sprint reviews as the main control points

Best answer: B

Explanation: PRINCE2 management stages are for directing and controlling the project through explicit decision points, not for mirroring how the work is technically performed. By aligning management stages to the two required Project Board approvals, the Project Manager creates clear stage boundaries for authorization, replanning, and exception escalation while still letting agile sprints run as delivery cycles inside stages.

Management stages exist to provide the Project Board with periodic control points where it can review performance, confirm continued viability, and authorize the next tranche of work (or stop/redirect) based on updated forecasts and the Business Case. Technical stages (such as sprints or specialist phases) describe how products are created and can occur within a management stage.

In this scenario, the Board has defined two meaningful go/no-go points (post-MVP and pre-launch). Tailoring should therefore:

  • Use management stage boundaries at those approval points (plus initiation as normal)
  • Use Stage Plans for each management stage to set near-term detail
  • Treat 2-week sprints as technical delivery cycles, controlled day-to-day via team-level reporting

This preserves PRINCE2’s manage-by-exception control without forcing Board governance at sprint cadence.


Question 11

Topic: Learning Outcome 4: PRINCE2 practices

A project is delivering a new self-service customer portal. During initiation, the Project Board agreed the high-level scope (products to be delivered) but did not agree the portal’s acceptance criteria with the Senior User, deciding to “confirm what good looks like during user testing”.

The Project Manager is about to authorize a supplier Work Package to build the portal and has drafted Product Descriptions with quality criteria (e.g., accessibility and performance measures).

What is the most likely near-term impact of proceeding without agreed acceptance criteria?

  • A. Checkpoint reporting will be suspended until scope is redefined
  • B. The stage will automatically move into exception
  • C. Quality approvals will lack an objective basis for acceptance
  • D. The Business Case will immediately become invalid

Best answer: C

Explanation: Acceptance criteria define the conditions for the customer to accept the final product(s) and provide a clear basis for approving completed products. If they are not agreed up front, quality control may still occur against quality criteria, but the governance decision to accept products becomes subjective. This increases the likelihood of late challenge and rework within the stage.

In PRINCE2, scope defines which products will be delivered; quality criteria define the measurable attributes each product must meet; acceptance criteria define what must be true for the customer to accept the project’s outputs. Acceptance criteria should be agreed early because they set the “done” threshold for governance decisions.

Proceeding with delivery when acceptance criteria are deferred means the team can build and test against drafted quality criteria, but the Project Board and Senior User do not have an agreed, objective standard for confirming that the delivered scope is acceptable. The immediate consequence is weaker control over product approval and a higher risk of late disputes and rework when acceptance is finally discussed.

This is a control weakness, not an automatic exception or immediate Business Case failure.


Question 12

Topic: Learning Outcome 3: People in successful projects

A project to implement a new HR system has frequent Project Board meetings, but decisions are often deferred. The delivery teams report rework because priorities change after each meeting, and scope keeps shifting through informal “quick approvals”. The Project Manager escalates many minor issues to the Project Board and provides long narrative status updates, but does not show whether stage tolerances are being approached or give clear impact summaries on the Business Case.

In PRINCE2 terms, what is the MOST likely underlying cause of these poor Project Board decisions?

  • A. Users are requesting too many late changes
  • B. Stage tolerances and exception reporting are not being used
  • C. Checkpoint reporting from teams is missing
  • D. The Project Board is deliberately postponing decisions

Best answer: B

Explanation: Effective Project Board decision making relies on manage-by-exception: decisions are triggered by clear tolerances and supported by concise reporting on progress and impacts (time, cost, scope, risk, benefits). Here, the Board is flooded with minor escalations and narrative updates, with no tolerance status or clear impact on the Business Case. That points to weak exception-based control and decision inputs, not simply “too many changes.”

In PRINCE2, the Project Board should focus on direction and key decisions, not day-to-day control. That is enabled by manage-by-exception: agreed tolerances at project/stage level and clear, timely decision inputs that show whether the project remains within those tolerances and what the impact of issues/changes would be on the Business Case and plans.

In this scenario, the Project Manager escalates minor issues and provides narrative reporting without tolerance status or clear impact summaries, and changes are being handled informally. This prevents the Board from seeing what genuinely requires their decision and from assessing options quickly and consistently.

The key takeaway is that decision latency and scope churn here are symptoms of missing/unused tolerances and exception-based reporting, which should structure and trigger Project Board decisions.


Question 13

Topic: Learning Outcome 4: PRINCE2 practices

A project must follow an organizational standard requiring independent verification of key products and a traceable record of quality checks. To “tailor for speed”, the Project Manager stops using formal quality reviews for key products and asks the Team Manager to self-certify completion, keeping only informal notes in the team tool.

What is the most likely near-term impact on project governance and control?

  • A. Project Assurance will lack objective evidence to confirm standards
  • B. The Business Case will immediately become invalid
  • C. Users will only discover quality problems after handover
  • D. The project will automatically exceed stage tolerances

Best answer: A

Explanation: Tailoring can simplify how quality control is performed, but it must still provide sufficient independence and evidence to show that required standards and user expectations are met. By replacing independent verification and a quality record with self-certification and informal notes, governance loses visibility and confidence in product acceptance. The immediate consequence is weakened assurance and control, not an automatic tolerance or Business Case failure.

Tailoring quality controls is acceptable only when the alternative approach still achieves the required standard and provides adequate confidence to governance. In this scenario, independent verification is a stated organizational requirement and the project also needs a traceable record of quality checks. Replacing formal reviews with Team Manager self-certification removes independence and reduces the reliability of evidence available for acceptance.

Near-term, this impacts governance by weakening Project Assurance’s ability to confirm that products meet their acceptance criteria and mandated standards, increasing the likelihood that the Project Board will challenge product acceptance and require reinstated controls or an updated Quality Management Approach. A common tailoring pattern is to streamline the format (e.g., lighter records) but not remove required independence or the ability to demonstrate compliance.


Question 14

Topic: Learning Outcome 4: PRINCE2 practices

A Project Manager receives a change request to add an additional validation rule to a data-import component that was previously approved at a stage boundary. The component has already passed system testing and is currently being used in user training.

Before the Change Authority decides whether to approve the change, what is the MOST appropriate next step in PRINCE2 terms?

  • A. Update the Product Description and Stage Plan, then issue a new Work Package
  • B. Raise an Exception Report because an approved baseline is being changed
  • C. Check the configuration and quality records for the component, then update the Issue Report with impact analysis
  • D. Send the change request to the Change Authority immediately for a decision

Best answer: C

Explanation: The change decision needs a dependable understanding of what is currently baselined and whether the affected product has already met its quality criteria. Configuration records identify the exact version/status in use, and quality records provide evidence of tests and approvals completed. Using these, the Project Manager can produce a robust impact analysis for the Change Authority’s decision.

In PRINCE2 change control, a change request should be examined before it is decided. For a product already approved and in use, the Project Manager should use configuration records (e.g., the product’s configuration item record and product status information) to confirm exactly what version is baselined, where it is deployed, and what other products depend on it. Quality records (e.g., quality register entries and quality records/results) show what quality activities were completed and what would need to be repeated if the product changes.

With this evidence, the Project Manager can update an Issue Report with realistic impacts on scope, cost, schedule, risk, and rework, enabling the Change Authority to make an informed approval/rejection decision. Implementing plan/product changes comes after authorization.


Question 15

Topic: Learning Outcome 3: People in successful projects

A project to roll out a new customer-support platform is in its first delivery stage. The team are experienced support analysts and developers, but this is their first PRINCE2 project.

Symptoms over the last month:

  • Decisions are late because questions are not escalated clearly.
  • Frequent rework because “done” means different things to different people.
  • Highlight information is inconsistent and sometimes missing.
  • Scope keeps changing through informal agreements.

What is the MOST likely underlying cause in PRINCE2 people terms?

  • A. The issues are normal early-stage symptoms; no root cause
  • B. Insufficient capability in the customer-support domain
  • C. Competency gap in applying PRINCE2 roles and controls
  • D. Unmanaged exceptions due to stage tolerances being breached

Best answer: C

Explanation: The scenario shows people can do the work (they are experienced analysts and developers) but are not performing well within PRINCE2 ways of working. Late escalation, inconsistent reporting, informal scope change, and unclear “done” point to a competency shortfall in applying roles, product definitions, and controls. This is addressed by staffing for (or developing) PRINCE2 competence, not replacing domain expertise.

Capability is having the underlying ability to perform the specialist work (e.g., support analysis and software development). Competency is being able to apply that capability effectively in the project context, including the behaviours, discipline, and method knowledge needed to work within defined roles and controls.

Here, the team’s capability is evidenced by their experience, yet performance suffers because they are not consistently:

  • defining acceptance/“done” through product definitions
  • escalating decisions and issues through agreed roles
  • using agreed reporting and change control

This points to a competency gap that should be addressed through targeted onboarding/coaching, clear role expectations, and light-touch control training, rather than assuming the team lacks specialist capability.


Question 16

Topic: Learning Outcome 3: People in successful projects

A project to implement a new customer self-service portal is in delivery. Over the last month, stakeholders have complained that design decisions are made late, resulting in rework. Reporting is inconsistent across teams, and the scope seems to change after workshops.

The Project Manager finds that most delays are waiting for user-priority decisions because the Senior User rarely attends and has not delegated decision-making. Current stage forecasts remain within time and cost tolerances, but benefits are at risk if rework continues.

In PRINCE2 terms, what is the most likely underlying cause that means these stakeholder concerns should be escalated to the Project Board, and what information should be provided?

  • A. Weak Product Descriptions; ask teams to rework them and continue
  • B. Poor reporting quality; include the complaints in the next Highlight Report
  • C. Unmanaged exception; submit an Exception Report requesting extra tolerance
  • D. Unclear Senior User accountability; raise an Issue Report summarizing impacts, options, and recommendation

Best answer: D

Explanation: The pattern of late decisions, rework, and scope churn is best explained by missing/unclear user decision authority, which sits with the Senior User and Project Board. Even without a forecast breach of tolerance, the concern should be escalated because governance needs correction to protect benefits. The escalation should include the impact and practical options for restoring timely decisions.

Stakeholder concerns should be escalated to the Project Board when the root cause is a governance/accountability issue that the Project Manager cannot resolve (for example, lack of effective Senior User engagement or decision authority), or when unresolved concerns threaten continued business justification (benefits) even if tolerances are not yet forecast to be exceeded.

In this scenario, delayed user-priority decisions are driving rework and perceived scope churn, which indicates the Senior User role is not being fulfilled or delegated. The Project Manager should provide decision-ready information, typically through an Issue Report, including:

  • a short summary of the stakeholder concern and its root cause
  • assessed impact on time/cost/quality/benefits and key risks
  • options (e.g., appoint a deputy Senior User, agree decision timescales, adjust governance/communication)
  • a recommendation for the Project Board decision

An Exception Report is reserved for forecast breaches of agreed tolerances.


Question 17

Topic: Learning Outcome 4: PRINCE2 practices

A project is delivering a new customer self-service portal. At the end of each stage, the Project Board repeatedly postpones the stage-end decision because it cannot see clear evidence that the stage products meet the agreed user expectations. In the next stage, teams often rework completed outputs after late stakeholder feedback. Highlight Reports describe progress in terms of activities completed, but do not reference product acceptance or test outcomes. Scope discussions keep reopening because “done” is interpreted differently by different parties.

Which is the MOST likely underlying cause in PRINCE2 terms?

  • A. Quality controls and acceptance criteria were not defined and recorded, so quality evidence is not being produced
  • B. Scope churn is happening because change requests are being approved too quickly
  • C. Rework is happening because the Senior User is not attending enough progress meetings
  • D. Stage-end decisions are late because the Project Board schedules stage-end reviews too close to the deadline

Best answer: A

Explanation: Stage-end decisions rely on objective, recorded evidence that products meet defined acceptance/quality criteria. If the project has not defined and planned quality controls (and does not capture results), reporting will default to activities and “percent complete,” leading to delayed acceptance, rework, and recurring debates about what “done” means.

In PRINCE2, the Project Board’s stage-end decision and continued business justification depend on reliable information about what has been delivered and whether it is acceptable. That requires product-based definition (clear acceptance/quality criteria in Product Descriptions) and planned quality activities, with results captured as quality records (often surfaced via the Quality Register and referenced in reports). When quality criteria, methods, and responsibilities are not defined and the evidence is not recorded, progress reporting becomes activity-based, acceptance becomes subjective, and late rework and repeated stage-end delays are predictable.

Key takeaway: strengthen product definitions and quality control/recording so stage-end decisions are based on objective quality evidence, not opinions.


Question 18

Topic: Learning Outcome 4: PRINCE2 practices

A project is developing a new online returns portal. In the current stage, system testing has found more defects than expected, and the Team Manager proposes skipping the planned accessibility test to recover one week and stay on the planned go-live date. The Project Manager believes the stage can still be delivered within time tolerance without skipping the test, but wants to protect business value and avoid an uncontrolled reduction in quality.

Which option is the BEST use of PRINCE2 management products to support this decision?

  • A. Update the Product Register to show testing is complete and move on
  • B. Check the Product Descriptions’ quality criteria and update the Quality Register with the agreed quality activities
  • C. Raise an Exception Report to the Project Board immediately
  • D. Agree to skip the accessibility test to protect the go-live date

Best answer: B

Explanation: Quality trade-offs should be based on agreed acceptance and quality requirements, not schedule pressure. Product Descriptions provide the definitive quality criteria and quality methods for each product, and the Quality Register is used to plan, track, and record quality activities and results. Using these products supports an informed, controlled decision within tolerances while protecting business justification and value.

PRINCE2 protects value by ensuring products meet their agreed acceptance and quality requirements. When a team proposes reducing or skipping a quality activity, the Project Manager should first use the Product Descriptions to confirm what quality criteria and verification methods are required (and therefore what would be compromised). The Quality Register is then used to control quality work by recording what quality activities are planned, who will perform them, when they will occur, and the results.

If the stage can be kept within tolerance, the Project Manager should manage the re-planning and quality control without escalating unnecessarily; if meeting required quality criteria becomes impossible within tolerance, escalation is handled through exception management. The key takeaway is: decide quality changes against Product Descriptions, and control/record quality activities in the Quality Register.


Question 19

Topic: Learning Outcome 5: PRINCE2 processes

A Project Manager is running a small internal app enhancement stage (2 weeks) with a single delivery team led by a Team Manager. The work is low risk, co-located, and will be delivered as one agreed set of products. The Project Board has asked for minimal documentation, but still wants clear authorization and progress control.

What is the most appropriate tailoring of PRINCE2 management products for Managing Product Delivery?

  • A. Baseline a detailed Team Plan for each Work Package
  • B. Authorize delivery with a Work Package; no separate Team Plan
  • C. Start work without a Work Package; rely on Checkpoint Reports
  • D. Use a Team Plan instead of issuing a Work Package

Best answer: B

Explanation: In PRINCE2, the Work Package is used to authorize and control delivery by a Team Manager, including products, tolerances, reporting, and handover. A Team Plan is only needed when the team’s work needs a separate, more detailed planning/control layer. Given the small, low-risk, single-team context, keep the Work Package but avoid an unnecessary Team Plan.

Managing Product Delivery relies on the Work Package as the formal agreement between the Project Manager and the Team Manager: what will be delivered, quality expectations, tolerances, how progress will be reported, and how completed products will be returned. A Team Plan is a planning product used by the Team Manager (or Project Manager) when the work needs additional detail or separate control beyond the Stage Plan-such as complex delivery, multiple parallel activities, multiple Work Packages, or higher risk.

In this scenario the stage is short, work is low risk, and one team is delivering one coherent set of products. Tailoring should therefore:

  • keep the Work Package to maintain clear authorization and control
  • avoid a separate Team Plan, using the Stage Plan and Checkpoint Reports to manage and monitor delivery

The key distinction is that a Work Package is an authorization/control “contract”, while a Team Plan is optional detailed planning when warranted by complexity or risk.


Question 20

Topic: Learning Outcome 4: PRINCE2 practices

You are the Project Manager for a small internal CRM configuration project. To keep governance lightweight, the Project Board asked for only brief Highlight Reports during the stage.

The current delivery stage has agreed tolerances of 1 week and $15,000. Halfway through the stage, the supplier confirms a key interface component will be delivered 2 weeks later than planned. Re-sequencing work will not recover the delay; cost remains within tolerance.

Which planning/control tailoring is MOST appropriate now, while keeping PRINCE2 manage-by-exception intact?

  • A. Continue the stage and propose widening stage tolerances at the next Project Board meeting
  • B. Escalate with an Exception Report and create an Exception Plan for the stage
  • C. Ask the Team Manager to replan the Work Package and avoid changing the Stage Plan
  • D. Update the Stage Plan and communicate the revised end date in the next Highlight Report

Best answer: B

Explanation: An Exception Plan is required when performance is forecast to exceed agreed tolerance at the relevant level (here, the stage). A 2-week delay breaches the stage’s 1 week time tolerance, so the situation must be escalated and a recovery proposal prepared for approval rather than simply “absorbed” through lightweight reporting.

In PRINCE2, tolerances enable delegation, but they also define the trigger for escalation and replanning. When the Project Manager forecasts that a stage will exceed its agreed tolerance (time, cost, scope, quality, risk, or benefits), they must raise an Exception Report to the Project Board and prepare an Exception Plan describing how the remainder of the stage (or project) would be delivered.

In this scenario the forecast end date is 2 weeks late against a 1 week stage time tolerance, so the stage is in (forecast) exception even though cost is still within tolerance. The “lightweight governance” request can reduce routine reporting, but it cannot remove the exception mechanism that underpins manage-by-exception.


Question 21

Topic: Learning Outcome 3: People in successful projects

A public-sector organization is running a PRINCE2 project to replace its customer portal. Mid-stage, a new data-retention requirement means a change is needed to add automated archiving and audit logging.

The change is estimated at +2 weeks and +$120,000, which is within the stage tolerances (+4 weeks, +$200,000). However, it also adds $50,000/year operating cost, reducing forecast benefits.

Which action by Project Assurance BEST supports governance by protecting business justification and value?

  • A. Independently review the updated Business Case and advise the Project Board
  • B. Approve the change to avoid delaying delivery
  • C. Instruct the Project Manager to implement it because tolerances allow it
  • D. Recommend halting the project until the regulation impact is fully known

Best answer: A

Explanation: Project Assurance supports governance by independently checking that key decisions remain aligned to business justification and compliance, not by making decisions or directing delivery. Here, the change is within stage tolerances but may undermine value due to reduced benefits and added operating cost. An independent review of the updated Business Case and impacts equips the Project Board to make an informed decision.

Project Assurance provides an independent view to the Project Board that the project remains viable, compliant, and aligned to agreed value. Being within time/cost tolerances does not remove the need to confirm that the Business Case still justifies the investment, especially when benefits and whole-life costs change and there is a compliance driver.

In this scenario, Project Assurance should ensure that the impacts are properly reflected (e.g., updated Business Case, benefits and risk information) and then independently validate the assumptions and compliance implications before advising the Project Board. This preserves governance: the Project Board decides, while Assurance provides objective confidence that the decision protects value and remains compliant.

The key is independent verification and transparent advice, not taking control actions or creating unnecessary disruption.


Question 22

Topic: Learning Outcome 4: PRINCE2 practices

Halfway through a delivery stage, a Change Request is raised to add a new sustainability reporting module. The Project Manager’s impact assessment estimates +$120,000 cost and +3 weeks schedule, still within the stage tolerances ($150,000 and 4 weeks). However, the additional operating costs reduce forecast net benefits.

Before asking the Project Board to decide, which management product provides the best evidence to update the Business Case with the change’s impacts?

  • A. Issue Report with impact analysis
  • B. Highlight Report
  • C. Checkpoint Report
  • D. Exception Report

Best answer: A

Explanation: To update the Business Case after a significant change request, the Project Manager needs validated impact information on costs, timescales, benefits, and risks. The management product designed to document an issue and its impact assessment for decision-making is the Issue Report. This provides the evidence base to revise the Business Case before seeking approval.

Updating the Business Case after a significant issue or change request requires reliable impact information, so the justification can be re-evaluated before a decision is made. In PRINCE2, the Project Manager documents a change request and its impact assessment in an Issue Report, which typically covers how the change would affect forecasts such as cost, time, benefits (including dis-benefits), and risk exposure; this is exactly the information needed to update the Business Case.

An Exception Report is only appropriate when forecasts exceed agreed tolerances and an exception decision is needed. Here, the impacts are within tolerance, so the decision can be supported using issue documentation rather than exception-level escalation.


Question 23

Topic: Learning Outcome 4: PRINCE2 practices

You are Project Manager for a 10-week project to deliver an internal self-service portal. The work is being delivered by one Team Manager using an agile approach (a single backlog and 2-week iterations). Governance requires the Project Board to be alerted only if the forecast is likely to exceed agreed limits. The project is low risk, but the Executive has set a firm cost cap.

Which tailoring of planning tolerances and monitoring controls is MOST appropriate while keeping PRINCE2 principles intact?

  • A. Set zero tolerance for time and cost in all plans and require weekly Exception Reports to the Project Board to ensure tight control over the cost cap.
  • B. Define tolerance only once in the PID at project level and keep Stage Plans as task lists; escalate any deviation from the Stage Plan immediately to the Project Board.
  • C. Remove tolerances from plans and rely on the Team Manager’s burn-up chart to show progress; inform the Project Board at the end of each iteration.
  • D. Set time/cost tolerances in each Stage Plan and agree Work Package tolerances with the Team Manager; monitor actual and forecast via lightweight Checkpoint Reports/iteration metrics and raise an Exception Report only when tolerances are forecast to be exceeded.

Best answer: D

Explanation: PRINCE2 sets tolerances in plans at each level of delegation (project, stage, and Work Package) so that delivery can be managed by exception. The Project Manager monitors actuals and forecasts against those tolerances using proportionate controls (e.g., Checkpoint/Highlight reporting and delivery metrics). Escalation to the Project Board happens only when a tolerance is forecast to be breached.

Tolerances are agreed limits (e.g., for time and cost) that are set in the relevant plan to enable delegation and manage-by-exception. In this scenario, the Project Board wants to be alerted only when the cost cap or other agreed limits are at risk, so tolerances must be explicit in each Stage Plan and then further delegated as Work Package tolerances to the Team Manager.

During delivery, monitoring focuses on comparing actual and forecast performance against those tolerances using lightweight, frequent information (e.g., Checkpoint Reports and iteration metrics). If the Project Manager forecasts a breach of stage tolerance, they escalate via an Exception Report rather than routinely pulling the Project Board into day-to-day control. The key tailoring is to keep tolerances and exception escalation, while making the reporting mechanism proportionate to a short, low-risk agile delivery.


Question 24

Topic: Learning Outcome 5: PRINCE2 processes

A Project Manager is delegating the build of an API integration component to a supplier Team Manager during a delivery stage. The Stage Plan only shows the component as a single activity with a milestone date.

The Team Manager says the work needs more detailed planning and asks what PRINCE2 management products should be used.

Which TWO statements are correct about what should happen next?

  • A. The Team Manager may produce a Team Plan to manage the team’s detailed work and use it to support progress reporting against the Work Package.
  • B. The Team Manager should create the Work Package and send it to the Project Manager for authorization.
  • C. The Project Board should approve the Team Plan because it provides the detailed breakdown missing from the Stage Plan.
  • D. The Project Manager should issue a Team Plan as the formal authorization for the supplier to start work.
  • E. The Project Manager should agree and authorize a Work Package before work starts, defining required products, constraints, tolerances, and checkpoint reporting.
  • F. A Work Package is only needed when the Team Manager forecasts that tolerance will be exceeded; otherwise an email instruction is sufficient.

Best answers: A, E

Explanation: In Managing Product Delivery, the Project Manager delegates work using an authorized Work Package that sets out what must be delivered and how it will be controlled. If the work needs more detail than the Stage Plan provides, the Team Manager can create a Team Plan to manage the team’s activities and then report progress (e.g., via checkpoints) against the Work Package.

A Work Package and a Team Plan serve different purposes in Managing Product Delivery. The Work Package is the Project Manager’s mechanism to formally hand over responsibility for a defined set of products to a Team Manager, including the product requirements (via Product Descriptions), quality expectations, constraints (time/cost/scope), tolerances, and the agreed reporting/checkpoint frequency.

A Team Plan is optional and is produced by the Team Manager when the work needs detailed planning beyond the Stage Plan. It focuses on how the team will deliver the Work Package (tasks, sequencing, resourcing, internal controls). The Team Plan supports the Team Manager’s day-to-day management and provides the basis for checkpoint reporting; it does not replace the Work Package as the authorization to start work.

Revised on Sunday, April 26, 2026