PRINCE2 Foundation — Scenario Practice Guide

This independent guide is for candidates preparing for the PeopleCert PRINCE2 Project Management Foundation (Version 7), exam code PRINCE2 Foundation. It focuses on public exam-preparation reasoning: how to read a project scenario, identify the real decision, and select the most defensible answer using PRINCE2 concepts.

Scenario questions often feel harder than direct recall questions because several answers may sound like reasonable project management. Your task is not to pick the most energetic action, the most senior person, or the most detailed plan. Your task is to choose the answer that best fits the PRINCE2 role, process, practice, principle, and facts given.

Start with the PRINCE2 decision frame

Before comparing answer options, slow the scenario down. Ask five questions in order:

1. Who is acting or deciding? Is the scenario about the Project Manager, Team Manager, Project Board, Executive, Senior User, Senior Supplier, Project Assurance, Project Support, Change Authority, or a stakeholder?

2. Where is the project in the PRINCE2 lifecycle? Is it being started, initiated, delivered in a stage, reviewed at a stage boundary, managed after an exception, or closed?

3. What type of event has occurred? Is it a risk, issue, change request, off-specification, quality concern, tolerance forecast, stakeholder concern, team problem, or business justification question?

4. Is the next step analysis, communication, action, or escalation? PRINCE2 usually expects control before reaction: record the event, assess impact, consult the right role, then act or escalate according to authority.

5. Which answer preserves PRINCE2 governance? The best answer normally respects defined roles, stage control, product focus, tolerances, business justification, and tailoring.

Use this as your mental checklist before you read the answer choices too deeply.

Identify the role in the scenario

PRINCE2 is role-driven. Many scenario answers are wrong because they give the right activity to the wrong person.

If the scenario mentions the Project Manager

Think about day-to-day management within agreed tolerances. The Project Manager normally:

• Plans and controls stages.
• Authorizes work packages.
• Monitors progress.
• Manages issues and risks within delegated authority.
• Reports progress to the Project Board.
• Escalates forecasts that exceed tolerance.
• Maintains management products such as registers, logs, plans, and reports.

A Project Manager should not casually change the business case, bypass the Project Board, ignore tolerances, or approve major changes outside delegated authority.

If the scenario mentions the Project Board

Think direction, authorization, and key decisions. The Project Board normally:

• Provides overall direction.
• Authorizes initiation, the project, stages, exception plans, and closure as appropriate.
• Ensures continued business justification.
• Makes decisions when matters exceed delegated authority.
• Represents business, user, and supplier interests.

If an option has the Project Board doing detailed daily control, assigning individual tasks, or managing team-level work, question it.

If the scenario mentions the Executive

Think business ownership. The Executive is accountable for the project’s business justification and value. In a scenario, the Executive is often relevant when:

• The business case is threatened.
• Benefits, costs, or value are being challenged.
• A major decision affects continued justification.
• Competing business priorities need resolution.

If the scenario mentions the Senior User or Senior Supplier

Think interest represented:

• Senior User: user needs, expected benefits, usability, acceptance, and operational impact.
• Senior Supplier: supplier capability, specialist resources, technical feasibility, and delivery approach.

If the scenario is about whether a product will meet user acceptance criteria, the Senior User interest matters. If it is about supplier capacity or technical delivery constraints, the Senior Supplier interest matters.

If the scenario mentions the Team Manager

Think work package delivery. The Team Manager normally:

• Accepts work packages.
• Plans and manages the specialist work needed to deliver products.
• Provides checkpoint reports.
• Raises issues or risks to the Project Manager when necessary.
• Delivers completed products back according to the work package agreement.

The Team Manager does not usually make project-level decisions about tolerances, business justification, or stage approval.

If the scenario mentions Project Assurance or Project Support

Separate assurance from support:

• Project Assurance checks that the project is being conducted properly from business, user, and supplier perspectives. It is independent of the Project Manager.
• Project Support provides administrative and specialist support, such as maintaining registers, configuration information, or document control, depending on tailoring.

If an answer gives Project Assurance direct management responsibility, be cautious. Assurance checks and advises; it does not replace the Project Manager.

Determine the delivery context without losing PRINCE2 governance

PRINCE2 can be tailored to different environments. A scenario may sound predictive, agile, iterative, supplier-led, internal, external, large, small, simple, or complex. Do not let the delivery style override the governance logic.

Ask:

• Is the scenario about how specialist work is delivered, or about how the project is governed?
• Are roles and tolerances still defined?
• Are products and acceptance criteria clear?
• Is the issue within a stage, at a boundary, or outside tolerance?
• Has authority been delegated, for example to a Change Authority?

In agile or hybrid wording, the best answer may still be a PRINCE2 answer: clarify the product, manage by stage, keep the business case under review, use agreed roles, and escalate only when authority or tolerance requires it.

Locate the project process implied by the facts

You do not need to force every scenario into a process, but process context often reveals the best next step.

Starting up a Project

Look for wording such as a new idea, mandate, need for initial viability, appointment of key roles, or preparation before initiation.

Good reasoning:

• Is there enough information to justify initiating the project?
• Are the Executive and Project Manager identified?
• Is a project brief or outline business case being prepared?
• Is the initiation stage being planned?

Avoid jumping straight into detailed delivery if the scenario is still about deciding whether the project is worth initiating.

Directing a Project

Look for Project Board decisions and authorization points.

Good reasoning:

• Does the Project Board need to authorize initiation, a stage, an exception plan, or closure?
• Is continued business justification being reviewed?
• Has the Project Manager escalated an exception or major issue?

This process is about direction and decision-making, not daily management.

Initiating a Project

Look for detailed definition before delivery: baseline plans, controls, strategies, risk approach, business case refinement, and the project initiation documentation.

Good reasoning:

• Is the project being defined well enough to control it?
• Are roles, controls, plans, and baselines being established?
• Is the business case being developed from outline to a stronger basis for authorization?

Do not select an answer that starts delivery before the project has been properly initiated, unless the scenario clearly says authorization already exists.

Controlling a Stage

Look for work in progress within an authorized stage.

Good reasoning:

• Has the Project Manager authorized work packages?
• Is progress being monitored?
• Is an issue or risk being captured and assessed?
• Is corrective action within tolerance?
• Is a highlight report or exception report needed?

This is one of the most common scenario contexts because it tests everyday control.

Managing Product Delivery

Look for Team Manager and specialist team activity.

Good reasoning:

• Has the Team Manager accepted a work package?
• Are products being created to agreed quality criteria?
• Are checkpoint reports being provided?
• Is the completed product being delivered back to the Project Manager?

If the question is about team delivery, the answer should usually stay at work package level unless a project-level issue has emerged.

Managing a Stage Boundary

Look for the end of a stage, review of current performance, planning the next stage, or deciding whether the project should continue.

Good reasoning:

• Should the next stage plan be prepared?
• Should the business case be updated?
• Should risks, issues, and lessons be reviewed?
• Is the Project Board being asked to authorize the next stage?

A stage boundary is a control point. Expect review and authorization, not automatic continuation.

Closing a Project

Look for completed products, acceptance, handover, premature closure, final reports, lessons, or benefits review planning.

Good reasoning:

• Have products been accepted?
• Has handover been addressed?
• Are outstanding issues or follow-on actions captured?
• Are lessons and final performance reported?
• Has the Project Board authorized closure?

Closure is controlled. It is not simply stopping work because delivery seems complete.

Classify the event: risk, issue, change, quality, progress, or people

A scenario usually turns on one event. Name it before choosing an answer.

Risk

A risk is uncertain. Look for words such as “may,” “might,” “could,” “possible,” “threat,” or “opportunity.”

Best next-step pattern:

• Identify and record the risk.
• Assess probability, impact, and proximity as appropriate.
• Plan a response.
• Assign ownership.
• Escalate if the risk threatens tolerance or requires higher authority.

A risk is not automatically an exception. It becomes an escalation issue when its forecast effect exceeds tolerance or authority.

Issue

An issue is something that has happened, is happening, or requires a decision. In PRINCE2, issue handling may include:

• A request for change.
• An off-specification.
• A problem or concern.

Best next-step pattern:

• Capture the issue.
• Classify it.
• Assess impact on plans, business case, risks, quality, scope, benefits, and tolerances as relevant.
• Decide within delegated authority or escalate to the appropriate authority.
• Communicate the decision and update records.

If a customer asks for an extra feature, do not automatically approve it. Treat it as a request for change and follow change control.

Quality concern

Quality scenarios often include product descriptions, acceptance criteria, quality criteria, tests, reviews, or user dissatisfaction.

Best next-step pattern:

• Check the agreed product description or project product description.
• Confirm the relevant quality criteria and quality method.
• Determine whether the product meets agreed requirements.
• Record defects or off-specifications as issues when necessary.
• Involve the right quality or user roles.

A quality answer should be product-focused, not opinion-focused.

Progress or tolerance concern

Progress scenarios often mention time, cost, scope, quality, benefits, risk, or other agreed performance targets.

Best next-step pattern:

• Compare actual or forecast performance with tolerances.
• If within tolerance, manage at the appropriate level.
• If forecast to exceed tolerance, escalate through the correct report or decision route.
• Do not rebaseline casually without authorization.

Management by exception is central: authority is delegated within tolerances, and exceptions are escalated.

People or stakeholder concern

PRINCE2 7 gives explicit attention to people, relationships, and organizational context. Scenario wording may include resistance, confusion, poor communication, competing priorities, stakeholder dissatisfaction, or unclear responsibilities.

Best next-step pattern:

• Identify whose interest is affected.
• Clarify roles, responsibilities, and relationships.
• Use the communication approach or stakeholder engagement method.
• Address the concern at the lowest appropriate level.
• Escalate only if authority, tolerance, or governance requires it.

A good people-focused answer is not simply “tell people what to do.” It should improve understanding, alignment, engagement, or decision-making within the PRINCE2 structure.

Decide whether to analyze, communicate, act, or escalate first

Scenario questions often test sequence. Many candidates choose an answer that might eventually be needed but is premature.

Use this order unless the scenario clearly points elsewhere:

1. Clarify and record the event. Use the appropriate log, register, report, or management product.

2. Assess impact. Consider effects on products, quality, plans, risks, benefits, business case, tolerances, and stakeholders.

3. Check authority. Decide whether the role in the scenario can act within delegated limits.

4. Consult or communicate with the right role. Communicate through the agreed route, not randomly to the most senior person.

5. Act, approve, reject, defer, or escalate. Choose the response that matches the facts and authority.

When action comes first

Action may come first when:

• The role has clear authority.
• The event is within tolerance.
• The answer is a routine control action.
• The scenario already says impact has been assessed.
• The action prevents immediate disruption without changing baselines or authority.

Example: A Team Manager realizes a minor task needs resequencing within the agreed work package tolerance. The best next step may be to manage the work package and inform the Project Manager through agreed reporting, not escalate to the Project Board.

When analysis comes first

Analysis usually comes first when:

• A change is requested.
• A defect or off-specification is found.
• A risk has been identified.
• A stakeholder wants a different outcome.
• A supplier predicts delay or cost increase.
• The business case may be affected.

Example: A user requests an additional reporting feature. The best answer is likely to record and assess the request for change, not promise inclusion or reject it without considering impact.

When communication comes first

Communication is likely first when:

• The issue is misunderstanding, alignment, or stakeholder engagement.
• A report is due under agreed controls.
• A role needs information to make a decision.
• Team members are unclear about responsibilities or product criteria.

Example: If users are worried that a product will not meet operational needs, the answer may involve engaging the Senior User or confirming acceptance criteria, rather than asking the supplier team to add features informally.

When escalation comes first

Escalation is appropriate when:

• A forecast shows tolerance will be exceeded.
• The decision is outside the role’s delegated authority.
• The Project Board or Change Authority must decide.
• Continued business justification is threatened.
• A major exception plan or project-level decision is needed.

Escalation should be controlled. A strong answer usually names the appropriate report, decision route, or authority rather than simply saying “inform senior management.”

Use the seven PRINCE2 practices as scenario lenses

When a scenario feels busy, match it to the practice being tested.

Business case

Look for value, benefits, costs, justification, investment decision, or whether the project should continue.

Ask:

• Is the project still desirable, viable, and achievable?
• Has new information affected expected benefits or costs?
• Who is accountable for business justification?
• Should the business case be updated or reviewed?

A business case scenario usually favors evidence-based review, not continuing because work has already started.

Organizing

Look for unclear responsibilities, decision rights, stakeholder representation, assurance, or reporting lines.

Ask:

• Which role owns this decision?
• Are business, user, and supplier interests represented?
• Is the Project Manager being asked to do something outside their role?
• Is assurance independent enough?

The best answer should respect defined roles and responsibilities.

Plans

Look for stage plans, project plans, team plans, exception plans, work packages, estimates, dependencies, or baselines.

Ask:

• Which level of plan is affected?
• Is the plan authorized?
• Is the change within tolerance?
• Is a stage boundary or exception situation involved?

Do not choose informal replanning if authorization is required.

Quality

Look for product descriptions, quality criteria, acceptance criteria, reviews, tests, defects, or user acceptance.

Ask:

• What product is being assessed?
• What criteria were agreed?
• Who is responsible for quality review or approval?
• Is this a defect, off-specification, or misunderstanding?

PRINCE2 quality reasoning starts with agreed criteria, not personal preference.

Risk

Look for uncertain events, threats, opportunities, probability, impact, response, owner, or actionee.

Ask:

• Is the event uncertain or already real?
• What is the effect if it occurs?
• Who owns the risk?
• Does it threaten tolerance?

Do not treat every risk as an issue, and do not escalate every risk automatically.

Issues

Look for requests for change, off-specifications, problems, concerns, defects, or decisions needed now.

Ask:

• What type of issue is it?
• Has impact been assessed?
• Who has authority to decide?
• Which plans, products, or baselines are affected?

Issue handling should be controlled and documented.

Progress

Look for status, forecasts, reports, tolerances, stage control, exceptions, or performance review.

Ask:

• What is actual or forecast performance?
• Which tolerance level is affected?
• What report or decision is needed?
• Can the Project Manager take corrective action within authority?

Progress scenarios often test management by exception.

Use the principles as tie-breakers

If two answers seem plausible, test them against the PRINCE2 principles.

Continued business justification

Does the answer protect the reason for doing the project? If new facts threaten value or benefits, review the business case rather than pressing ahead blindly.

Learn from experience

Does the scenario mention previous projects, lessons, recurring problems, or a new team? A strong answer may involve using or recording lessons.

Defined roles, responsibilities, and relationships

Does the answer assign the decision to the correct role? Does it clarify accountability instead of creating confusion?

Manage by stages

Does the answer respect stage boundaries and authorization points? Major decisions are not made casually in the middle of delivery without the right control.

Manage by exception

Does the answer use tolerances correctly? If within tolerance, manage at the delegated level. If forecast outside tolerance, escalate.

Focus on products

Does the answer refer to outputs, acceptance criteria, quality criteria, and product descriptions? PRINCE2 scenarios often reward product-based thinking.

Tailor to suit the project

Does the answer apply PRINCE2 appropriately for the project’s size, complexity, risk, and context? Tailoring does not mean ignoring principles or removing control.

Separate facts from distractors

Scenario wording may include emotional, technical, or organizational detail. Some detail matters; some is there to create pressure.

Prioritize facts that affect the PRINCE2 decision:

• Role: who is acting, deciding, reporting, or affected?
• Stage: where is the project in its lifecycle?
• Authority: who has delegated authority?
• Tolerance: is performance within or outside limits?
• Product: which product or quality criterion is involved?
• Event type: risk, issue, change, off-specification, or concern?
• Business impact: is justification affected?
• Stakeholder impact: whose needs or expectations are affected?
• Existing control: is there a plan, work package, register, report, or product description already in place?

Treat these as lower priority unless they change the decision:

• Strong emotions such as “urgent,” “angry,” or “concerned.”
• Seniority that is not linked to a PRINCE2 role.
• Technical detail unrelated to product criteria or supplier capability.
• A proposed solution before impact has been assessed.
• Pressure to skip governance because the team is busy.

Mini-scenarios: how to reason to the best next step

Scenario 1: Forecast delay within stage tolerance

A Team Manager tells the Project Manager that a product may be delivered three days later than planned, but the stage is still forecast to remain within agreed time tolerance.

Reasoning:

• Role: Project Manager.
• Context: controlling a stage.
• Event: progress forecast.
• Tolerance: still within tolerance.
• Best next step: manage the issue within the stage, update plans or records as appropriate, and continue agreed reporting.

Do not escalate to the Project Board just because there is a delay. Management by exception allows the Project Manager to act within tolerance.

Scenario 2: Forecast cost exceeds tolerance

A supplier cost increase means the current stage is forecast to exceed cost tolerance.

Reasoning:

• Role: likely Project Manager.
• Context: controlling a stage.
• Event: progress exception.
• Tolerance: forecast outside tolerance.
• Best next step: escalate through the appropriate exception route, providing impact and options for decision.

Do not simply absorb the cost or amend the stage baseline without authorization.

Scenario 3: User requests an extra feature

A Senior User representative asks the team to include a new reporting feature that was not in the agreed product description.

Reasoning:

• Event: request for change.
• Product focus: agreed product description matters.
• Authority: depends on delegated change authority and impact.
• Best next step: capture and assess the request for change, then route it to the appropriate decision authority.

Do not let the team add the feature informally just because a user wants it.

Scenario 4: Product fails agreed quality criteria

A completed product does not meet one of its agreed quality criteria.

Reasoning:

• Event: quality failure and likely issue/off-specification.
• Evidence: agreed quality criteria.
• Best next step: record and manage the issue according to quality and issue control, assess impact, and determine corrective action or decision authority.

Do not accept the product based only on schedule pressure.

Scenario 5: Stakeholders resist a new process

Operational stakeholders are resisting a product because they do not understand how it will change their daily work.

Reasoning:

• Event: people and stakeholder engagement concern.
• Practice connection: organizing, communication, business change impact, benefits realization.
• Best next step: engage the affected stakeholders through the agreed communication approach, clarify needs and impacts, and involve the appropriate user representation.

Do not treat stakeholder resistance as only a technical delivery problem.

Scenario 6: End of stage review

A stage is nearly complete, and the Project Manager is preparing information for the Project Board to decide whether to continue.

Reasoning:

• Context: managing a stage boundary.
• Decision: authorize next stage or take another direction.
• Best next step: review stage performance, update business case and plans as needed, capture lessons, and prepare for Project Board authorization.

Do not assume the next stage starts automatically.

How to compare answer options

After you understand the scenario, evaluate each option with a short test.

Ask of each answer:

• Does this role have authority to do that?
• Does it match the current PRINCE2 process?
• Does it address the actual event, not a side issue?
• Does it preserve product focus and quality criteria?
• Does it respect tolerances and management by exception?
• Does it assess impact before making a major decision?
• Does it communicate through the appropriate route?
• Does it support continued business justification?
• Is it tailored but still recognizably PRINCE2?

The best answer may not be the longest or most dramatic. It is usually the one that is controlled, proportionate, role-correct, and based on the facts.

Build a fast exam-day reading habit

Use this compact routine during final practice:

1. Read the final sentence first. Identify what the question is asking: next step, role, reason, product, practice, or process.

2. Mark the role. Who is responsible in the scenario?

3. Mark the trigger. What changed, failed, appeared, or needs a decision?

4. Classify the trigger. Risk, issue, change, quality, progress, business case, people, or role clarity?

5. Check tolerance and authority. Is this within delegated control or outside it?

6. Predict the PRINCE2 response before reading options. Form a simple expectation such as “record and assess the change” or “escalate the forecast exception.”

7. Choose the option closest to that response. Prefer the answer that fits PRINCE2 governance over a generic project management reaction.

Final review checklist

Before your final mock exams, make sure you can answer these quickly:

• Who authorizes project initiation, stages, exceptions, and closure?
• What does the Project Manager control within a stage?
• When does a Team Manager report to the Project Manager?
• What makes something a risk rather than an issue?
• How are requests for change and off-specifications handled?
• When does tolerance require escalation?
• Which management product defines product quality criteria?
• What is reviewed at a stage boundary?
• How does the business case influence continuation decisions?
• How does tailoring preserve PRINCE2 principles while adapting detail?

If any item feels slow, drill that topic with short scenarios until the decision sequence becomes automatic.

Practical next step

Use your next PRINCE2 Foundation practice session as a reasoning exercise, not just a scoring exercise. For each scenario, write one line naming the role, process, event type, authority point, and best next step. Then review missed questions by topic, drill weak areas, and finish with a timed mock exam to build speed without losing PRINCE2 control logic.