Principles practice questions

Focus on products

Why it fails: Focus on products centers on product descriptions and quality expectations, not tolerance escalation.

Defined roles and responsibilities

Why it fails: Although roles dictate who escalates, the actual governance mechanism of setting tolerances and thresholds belongs to manage by exception.

Continued business justification

Why it fails: While tolerance breaches may ultimately impact the business case, the immediate handling of breaches via escalation is managed by exception.

Focus on products

Why it fails: Focus on products concerns defining products and their quality criteria; it does not drive escalation when a cost tolerance is breached. Manage by exception requires the Project Manager to escalate once a tolerance is forecast to be exceeded. It is tempting because products are still being delivered, but the trigger is the tolerance breach.

Manage by stages

Why it fails: Manage by stages governs dividing the project into stages with defined boundaries and Stage Plans; it does not itself require escalation when a tolerance is breached mid-stage. Manage by exception obliges the Project Manager to escalate forecast tolerance breaches. It is tempting because the breach occurs within a stage, but the driver is the tolerance.

Continued business justification

Why it fails: Continued business justification drives reassessment of the Business Case when tolerances are threatened, but the stem's trigger is a stage-level cost tolerance breach, which mandates the Manage by Exception principle — escalating to the Project Board. Continued business justification underpins the Business Case throughout, and would be the focus when justification itself is questioned.

Eliminating the Project Board role to speed up daily decision-making in small projects.

Why it fails: Eliminating the Project Board removes the three mandated PRINCE2 role groups (business, user, supplier), directly contradicting the principle. It tempts because small projects seek faster decisions, and it would suit a lightweight agile team, but PRINCE2 requires those interests represented at every scale.

Ensuring the Project Manager also acts as the Executive to streamline project authority.

Why it fails: Combining Executive and Project Manager in one person merges the accountable owner with the day-to-day manager, removing the check on the Project Manager's own work. It tempts as streamlining authority, and would be correct only where PRINCE2 roles are properly separated and delegated.

Allowing the Project Manager to unilaterally approve changes to the project's overall Business Case.

Why it fails: Unilateral Project Manager approval of Business Case changes removes Project Board authority over continued business justification. It tempts as faster change handling, and would be correct where the Project Manager holds explicitly delegated change authority within defined tolerances, not overall Business Case ownership.

Document the lesson in the lessons log and proceed with the project board composition as originally planned.

Why it fails: Simply documenting the lesson without taking action does not apply the principle 'Learn from experience'. The principle requires that lessons are actively used to inform decisions and actions. Proceeding with the original composition ignores the lesson and increases the risk of repeating the same failure, which is contrary to the principle's intent.

Escalate the issue to the project board and ask them to decide on the composition of the project board.

Why it fails: During 'Starting up a Project', the project board may not yet be fully established, and the Project Manager is responsible for designing the project board composition as part of the project initiation documentation. Escalating to the project board for a decision on its own composition is premature and not aligned with the Project Manager's role in applying lessons learned.

Conduct a risk assessment to identify potential impacts of not having a business representative on the project board.

Why it fails: While risk assessment is valuable, it is not the first action to apply the principle 'Learn from experience'. The principle emphasizes using past lessons to inform current decisions. Conducting a risk assessment without first incorporating the lesson into the project board design misses the opportunity to proactively prevent the known issue.

Learn from experience

Why it fails: Learning from experience reviews lessons from previous projects to inform planning; it does not define outputs or their quality criteria. The 'Define roles, responsibilities and relationships' or 'Focus on products' principle covers agreeing outputs and quality expectations before work starts, making this tempting only because past lessons can shape product descriptions.

Defined roles and responsibilities

Why it fails: Defined roles and responsibilities concerns who is accountable for what within the project organisation, not agreeing quality criteria for outputs. It is tempting because it also addresses clarity, but the principle covering agreed definitions of outputs and their quality is 'focus on products'.

Continued business justification

Why it fails: Continued business justification concerns whether the project remains viable and worth investing in, not defining outputs or their quality criteria. It is tempting because it governs project continuation, but the principle requiring agreed, clearly defined outputs and quality expectations is 'focus on products'.

Tailor to suit the project

Why it fails: Tailor to suit the project concerns scaling PRINCE2's processes, themes and documentation to the project's size, complexity and risk. A Project Board containing business, user and supplier interests demonstrates the Defined Roles and Responsibilities principle. It is tempting because large infrastructure projects do require tailoring, but the stem describes role representation.

Manage by exception

Why it fails: Manage by exception defines tolerances delegated to each management level, so the Board escalates only beyond agreed limits. The stem describes three stakeholder interests represented on the Board, which implements the defined roles and responsibilities principle, not delegation of authority boundaries.

Continued business justification

Why it fails: Continued business justification requires a viable Business Case maintained throughout the project. The stem instead evidences the three primary stakeholder interests sitting on the Project Board, which demonstrates the defined roles and responsibilities principle covering business, user and supplier representation.

Defined roles and responsibilities

Why it fails: Defined roles and responsibilities concerns who does what within the project organisation, not the reuse of prior experience. Reviewing lessons from an earlier campaign demonstrates learning from experience, which requires seeking and applying knowledge from similar past work during initiation.

Tailor to suit the project

Why it fails: Tailoring concerns adapting PRINCE2's processes, themes and management products to the project's scale, complexity and risk. Reviewing lessons learned from a previous campaign is learning from experience; tailoring would apply only once those lessons shape how the method is adapted.

Manage by stages

Why it fails: Lessons from a previous project inform the current one, which demonstrates 'Learn from experience'. Manage by stages concerns dividing the project into manageable chunks with decision points at boundaries; it would be correct where the question asked how the Project Manager controls progression between stages.

Escalate immediately with an Exception Report because any delay is unacceptable.

Why it fails: Tolerance consumption without breach stays within the Project Manager's delegated authority, so the delay is handled at team/PM level and reported via Highlight Reports. Escalation is reserved for forecast tolerance breach, which triggers an Exception Report. Escalating here would wrongly transfer a decision the Board already delegated.

Suspend the project immediately to re-verify the business justification.

Why it fails: Suspension applies when the business justification itself is invalidated, not when time tolerance is merely consumed. The Project Manager should continue managing within delegated tolerance and report progress. Halting delivery would breach the 'manage by exception' principle by escalating a decision already delegated.

Rewrite the Project Brief to adjust the quality expectations of the outputs.

Why it fails: The Project Brief is a pre-project document superseded by the Project Initiation Documentation once the project is running; quality expectations are baselined there and changed only through formal change control. Rewriting it bypasses the Change practice. Adjusting scope or quality requires an approved change, not unilateral revision.

Focus on products

Why it fails: Focus on products concerns defining and agreeing product descriptions and quality criteria before work begins, not dividing delivery into authorisation increments. Managing by stages covers stage boundaries and Board authorisation. It is tempting because increments deliver products, but the stem describes staged governance, not product definition.

Manage by exception

Why it fails: Manage by exception concerns tolerances delegated to the Project Manager and escalation when they are forecast to be breached, not the Board authorising each stage. Managing by stages requires the Board to approve the next Stage Plan. It is tempting because both involve Board decisions at boundaries.

Tailor to suit the project

Why it fails: Tailoring concerns adapting PRINCE2 to the project's scale, environment and complexity; it does not itself mandate stage boundaries or Board authorisation. Managing by stages requires dividing work into stages with Board decisions at each boundary. It is tempting because three-month increments look like tailoring, but the stem describes staged control.

Manage by exception

Why it fails: Manage by exception sets tolerances and escalates only breaches; it does not justify tailoring products to project size. Tempting because it sounds like reducing oversight, but Tailor to suit the project environment is the principle permitting scaled governance and documentation.

Focus on products

Why it fails: Focus on products concerns defining and agreeing outputs and their quality criteria, not tailoring governance boards and reporting to project scale. It is tempting because products are central to PRINCE2 planning, and it would be correct where the question asked how to define deliverables or acceptance criteria.

Manage by stages

Why it fails: Manage by stages concerns dividing the project into manageable chunks with decision points, not scaling management products and boards to a two-week effort. It tempts because staging aids control, and it would be correct where a project needs stage boundaries and end-stage assessments.

Focus on products

Why it fails: Focus on products concerns defining and agreeing product descriptions and quality criteria, so it does not address whether the business justification remains viable. It is tempting because regulation change may alter product requirements, but that principle would drive product redefinition, not the Project Board's decision to stop the project.

Tailor to suit the project

Why it fails: Tailoring concerns adapting PRINCE2's processes, themes and documentation to the project's scale, complexity and environment; it does not govern continued viability. It is tempting because stopping a project may involve bespoke governance arrangements, but the decision itself rests on the business justification principle, not tailoring.

Manage by exception

Why it fails: Manage by exception concerns tolerances delegated to the Project Manager and escalation when forecasts breach them, not the Board's evaluation of business viability. It is tempting because the Board is acting at a decision point, but escalation only triggers the review; the principle driving the stop decision is continued business justification.

Manage by exception

Why it fails: Manage by exception deals with tolerance variances within a stage, whereas stage gates are planned boundary reviews.

Continued business justification

Why it fails: Continued business justification confirms the project remains viable, but it does not itself mandate short stages with go/no-go gates. Managing by stages is the principle requiring review points that permit premature closure when uncertainty is high. Justification is tempting because gates do reassess viability, yet the staging structure is the mechanism being leveraged.

Tailor to suit the project

Why it fails: Tailoring adapts PRINCE2 to project size, complexity and risk, but the principle directly requiring staged review points with decision gates is managing by stages. Short high-frequency stages with go/no-go gates are that principle applied to uncertainty. Tailoring is tempting because short stages look like an adaptation, yet the staging requirement itself drives the design.

Focus on products

Why it fails: Focus on products concerns defining and agreeing product descriptions and quality criteria. The stem's undocumented team structure and unclear approval authority relate to defined roles and responsibilities, which requires an explicit organisation structure with accountable roles.

Tailor to suit the project

Why it fails: Tailoring concerns adapting PRINCE2's themes and processes to the project's scale, complexity and environment; it does not address undefined roles. The stem's failure is that authority for approving design changes was never assigned or documented, which breaches Defined Roles and Responsibilities. Tailoring would be correct when scaling governance artefacts, not when accountability is missing.

Manage by exception

Why it fails: Manage by exception sets tolerances so higher management intervenes only when they are forecast to be breached. The stem concerns undefined roles and approval authority, which violates defined roles and responsibilities rather than any tolerance-setting mechanism.

Defined roles and responsibilities

Why it fails: Defined roles and responsibilities concerns who is accountable for what, not the logging and comparison of a deliverable against its Product Description. It tempts because team members are acting within their assigned duties, but the scenario demonstrates the principle of focusing on products and their agreed quality criteria.

Learn from experience

Why it fails: Learn from experience concerns capturing and applying lessons from previous or current work, not verifying a deliverable against its agreed Product Description. It tempts because logging a flaw resembles recording information, but the scenario's substance is product-focused quality checking, which is the focus on products principle.

Manage by exception

Why it fails: Manage by exception concerns tolerances and escalating deviations beyond delegated authority, not checking a deliverable against its Product Description. It tempts because a flaw could be escalated, but here the team resolves it against agreed criteria, demonstrating focus on products.

Learn from experience

Why it fails: Learn from experience concerns capturing and applying lessons, not justifying continued viability. It tempts because reviews occur at stage boundaries, but the Business Case update exists to confirm the project remains desirable, viable and achievable, which is the continued business justification principle.

Focus on products

Why it fails: Focus on products concerns defining and delivering products against requirements, not reassessing viability. It tempts because stage boundaries involve product review, but the Business Case update is driven by the continued business justification principle, not product definition.

Manage by stages

Why it fails: Manage by stages provides the control framework of stage boundaries and authorisation points, but it does not itself require the Business Case to be refreshed. It tempts because updates happen at stage ends, yet the underlying driver is continued business justification.

Manage by exception

Why it fails: Sprint reviews deliver stakeholder engagement and product validation, reinforcing 'Focus on products' and 'Learn from experience'. Manage by exception concerns tolerances delegated to the Project Manager, with escalation only when forecast to breach them; it applies where decision-making authority is devolved.

Continued business justification

Why it fails: Sprint reviews validate the product and engage stakeholders, which supports 'Focus on products' rather than justification. Continued business justification concerns whether the Business Case remains viable; it would be correct where reviews reassess benefits, costs and risks to confirm the project still merits investment.

Learn from experience

Why it fails: Sprint reviews primarily validate the product with stakeholders, reinforcing 'Focus on products'. Learn from experience concerns capturing and acting on lessons throughout the project; it would apply where reviews feed lessons into the Lessons Log to improve future work.

Continued business justification

Why it fails: Continued business justification concerns the ongoing viability of the business case throughout the project, not capturing lessons for reuse. It is tempting because closing a project does involve confirming benefits, and this principle would be the answer if the report justified whether the project should still proceed.

Tailor to suit the project

Why it fails: Tailoring concerns adapting PRINCE2 to the project's scale, environment and risk, not recording lessons learned for other projects. It is tempting because lessons reports are often tailored documents, and this principle would be correct if the question asked how the method itself was adapted to fit the project.

Focus on products

Why it fails: Focus on products concerns defining and agreeing product descriptions and quality criteria, not capturing lessons for reuse. It is tempting because both involve documentation, but the report here records what went well and poorly, which is the learn from experience principle's lessons log activity.

Defined roles and responsibilities

Why it fails: Defined roles and responsibilities concerns who is accountable for what within the project organisation, not adapting reports and terminology to corporate governance. It is tempting because governance frameworks assign accountabilities, but tailoring is the principle governing how PRINCE2 is adapted while retaining core controls.

Manage by exception

Why it fails: Manage by exception concerns agreeing tolerances and escalating only when forecasts breach them; it does not cover adapting reports and terminology to corporate frameworks. It is tempting because governance frameworks often set escalation thresholds, but the scenario describes tailoring PRINCE2, not tolerance-based delegation.

Learn from experience

Why it fails: Learn from experience concerns capturing and applying lessons throughout the project; it does not cover aligning reports and terminology with corporate governance frameworks. It is tempting because embedding PRINCE2 across departments may draw on prior rollouts, but the scenario describes tailoring, not lessons management.

Manage by stages

Why it fails: Manage by Stages concerns dividing the project into manageable stages with end-stage assessments and board authorisation, not financial justification. The requirement that benefits outweigh costs and risks is the Continued Business Justification principle. Manage by Stages would be correct when justifying stage boundaries and delegated tolerances.

Defined roles and responsibilities

Why it fails: Defined roles and responsibilities concerns who is accountable for what within the project organisation, not the business justification for undertaking it. It is tempting because role clarity genuinely underpins governance, and would be the correct principle where accountability for decisions or deliverables is unclear.

Focus on products

Why it fails: Focus on products concerns defining and agreeing the project's products and their quality criteria, not the financial justification for the investment. It is tempting because product definition drives scope, and would be correct where the issue is unclear or poorly specified deliverables.

Continued business justification

Why it fails: Continued business justification requires a valid Business Case throughout, not per-increment acceptance criteria. It is tempting because justification underpins all projects, but defining Product Descriptions with acceptance criteria before development reflects the defined roles and responsibilities principle, or manage by stages.

Manage by stages

Why it fails: Managing by stages concerns dividing the project into manageable chunks with end stage assessments, not defining acceptance criteria per increment. It tempts because staged delivery suits rapidly changing requirements, but the described behaviour is defining products and their quality criteria, which is the focus on products principle.

Tailor to suit the project

Why it fails: Tailoring concerns adapting PRINCE2 to the project's scale, environment and complexity; it does not require a Product Description with acceptance criteria before each increment. It tempts because agile, changing requirements demand tailoring, but the stem describes applying the focus on products principle, not adapting the method.