Overview of PRINCE2 and Principles practice questions

Manage by stages

Why it fails: The output shows Manage by Stages: YES.

Tailor to suit the project environment

Why it fails: The output shows Tailor to Suit the Project Environment: YES.

Focus on products

Why it fails: The output shows Focus on Products: YES.

Manage by Exception: The project manager has unlimited authority without any tolerances.

Why it fails: Incorrect — Manage by Exception actually sets tolerances for time, cost, etc., and escalates deviations.

Tailor to Suit the Project Environment: The project must follow a standard approach without adjustment.

Why it fails: Incorrect — the principle Tailor to Suit the Project Environment requires adapting PRINCE2 to the project's context.

Continued Business Justification: The project is divided into manageable stages.

Why it fails: Incorrect — this definition describes the 'Manage by Stages' principle, not 'Continued Business Justification'.

Learn from Experience: Management by exception is applied to empower decision-making.

Why it fails: Incorrect — this definition describes the 'Manage by Exception' principle, not 'Learn from Experience'.

Tailor to suit the project environment; the project manager should adapt the tolerances to the project's complexity, so missing some is acceptable.

Why it fails: Tailoring allows adaptation of processes and documents, but it does not permit omitting tolerances for key aspects. Manage by exception explicitly requires tolerances for all six aspects. Tailoring might adjust the level of detail or format, but the absence of scope and quality tolerances is a violation of manage by exception, not a tailoring issue.

Define roles and responsibilities; the project board must define who is responsible for setting tolerances, so the project manager is not at fault.

Why it fails: Defining roles and responsibilities ensures that accountabilities are clear, but the failure to set scope and quality tolerances is a breach of manage by exception. The project board is responsible for setting tolerances, but the principle violation is the lack of tolerances, not the role definition. The project manager should have highlighted this gap.

Focus on products; without product descriptions, the project cannot define quality tolerances, leading to unclear scope.

Why it fails: Focus on products is about defining products and their quality criteria, which is important but not the principle directly violated here. The lack of scope and quality tolerances relates to manage by exception, which requires all relevant tolerances to be set. Focus on products would address product definitions, not the delegation of authority through tolerances.

Tailor to suit the project environment

Why it fails: Tailoring ensures that PRINCE2 is adapted to the project's size, complexity, and risk. It does not inherently ensure strategic alignment or provide decision-makers with the necessary information. Those outcomes depend on having clearly defined roles and responsibilities within the project organization.

Manage by exception

Why it fails: Manage by exception defines tolerances for delegated authority so that the Project Board is only involved when thresholds are threatened. While it supports governance, it does not itself guarantee alignment with corporate strategy or ensure decision-makers receive the right information; that alignment is achieved through the defined roles and responsibilities principle.

Focus on products

Why it fails: Focus on products ensures that the project defines and delivers the required outputs and outcomes. It is about clarity of what will be produced, not about the governance structure or strategic alignment. The concern raised is about roles and decision-making information, which is addressed by a different principle.

Documenting the project's progress in a daily log and sharing it with the team.

Why it fails: Documenting progress in a daily log is a good communication practice, but it does not necessarily capture lessons learned or apply them to improve the project. The learn from experience principle requires actively seeking, recording, and acting on lessons, not just recording progress.

Ensuring that all project team members have the required technical certifications.

Why it fails: Having certified team members is beneficial for competence, but it does not demonstrate learning from experience. The principle focuses on using past project knowledge to inform current work, not on individual qualifications, which relate more to defined roles and responsibilities.

Holding a post-project review to capture lessons for future projects.

Why it fails: While a post-project review is part of learning from experience, it only captures lessons at the end of the project. The principle requires learning to be applied throughout the project, not just at the end, so this action alone is insufficient to demonstrate the principle fully.

Manage by exception

Why it fails: This principle concerns defining tolerances and delegating authority so that management action is only taken when exceptions occur. The scenario does not mention any issue with tolerances or escalation. The problem is the content of the business case, not the management approach being used.

Tailor to suit the project environment

Why it fails: This principle involves adapting PRINCE2 to the project's size, complexity, and environment. The scenario does not suggest that the project is failing to tailor; rather, it is about a missing element in the business case. Tailoring would not fix the absence of a stop scenario.

Learn from experience

Why it fails: This principle focuses on capturing and applying lessons from previous projects. While important, the scenario does not indicate that lessons are being ignored; the issue is specifically about the business case lacking a stop scenario. The programme manager's concern is about justification, not about learning from past projects.

The project manager must assign all tasks to team members without consulting the project board.

Why it fails: Defined roles and responsibilities does not mean the project manager acts unilaterally. The project board is accountable for the project, and the project manager works within delegated authority. Assigning tasks without consulting the board ignores the defined roles and can lead to misalignment. The principle requires clear accountabilities, not unilateral action.

The project manager is accountable to the project board for the day-to-day management of the project.

Why it fails: While the project manager is responsible for day-to-day management, the principle of defined roles and responsibilities emphasizes accountability, not just responsibility. The project board is accountable for the project's success, and the project manager is responsible for managing it. This statement is partially true but not a complete application of the principle as required by PRINCE2.

The project board must approve all changes to the project plan, regardless of size.

Why it fails: Defined roles and responsibilities does not require the project board to approve every change. The board sets tolerances and delegates authority; changes within tolerance can be managed by the project manager. Requiring board approval for all changes would undermine manage by exception and is not a correct application of the principle.

Review the business case to confirm that the project remains viable.

Why it fails: While reviewing the business case is important for continued business justification, it does not directly address the principle of focus on products. The scenario specifically highlights that products are being defined during development, which is a violation of focus on products. The first step should be to define the products, not to review the business case, although that may be a subsequent action.

Update the risk register to reflect the potential for scope creep.

Why it fails: Updating the risk register is a good practice, but it does not directly implement the focus on products principle. The principle requires that products are defined before development, so the immediate action should be to create product descriptions and a product breakdown structure. Risk management is important but secondary to ensuring the principle is applied correctly in this context.

Hold a quality review to assess the products that have already been developed.

Why it fails: Quality reviews are part of the quality theme and are used to verify products against their quality criteria. However, holding a review after products are developed does not address the root issue of defining products upfront. The focus on products principle requires that products are defined before development, so the first step should be to create those definitions, not to review existing products.

The principles can be tailored, but tailoring must not compromise the principles themselves.

Why it fails: While PRINCE2 can be tailored, the principles themselves cannot be tailored or compromised. Tailoring applies to the processes, themes, and documents, not the principles. The principles are universal and must be applied as-is. This statement incorrectly suggests that the principles can be adapted, which is not true. The scenario is about correct descriptions of principles, and this is a common misconception.

The principles are optional and can be selected based on the project's needs.

Why it fails: The principles are not optional; they are mandatory. A project cannot claim to be using PRINCE2 if it omits any of the principles. This statement contradicts the mandatory nature of the principles and is therefore incorrect. The scenario is about correct descriptions, and this is a false statement that might confuse those who think principles can be chosen like processes.

The principles are only applicable to large, complex projects and can be ignored for small projects.

Why it fails: PRINCE2 principles are applicable to all projects, regardless of size or complexity. They are scalable and can be applied to small projects as well. This statement is incorrect because it suggests that small projects can ignore the principles, which is not true. The principles are universal, and tailoring allows for appropriate application, but the principles themselves are always required.

Focus on stakeholders

Why it fails: Focus on stakeholders is not a PRINCE2 principle. PRINCE2 includes the organization theme, which addresses stakeholder engagement, but it is not a principle. The team member should not mistake a theme or aspect of a theme for a principle, as principles are the foundational requirements.

Manage by risk

Why it fails: Manage by risk is not a PRINCE2 principle. While risk management is important and is covered in the risk theme, it is not one of the seven principles. The team member might confuse themes with principles, but the principles are the guiding obligations that define PRINCE2.

Learn from experience

Why it fails: Learn from experience is indeed a PRINCE2 principle, but it is not one of the two correct answers in this multi-select question. The question asks for two, and the correct ones are continued business justification and manage by exception. While learn from experience is a principle, it is not selected here because the scenario or the question's specific requirement is to identify two, and those two are the ones that are correct in this context.

Define roles and responsibilities

Why it fails: Define roles and responsibilities is a PRINCE2 principle, but the exact wording is 'defined roles and responsibilities'. The option uses 'define', which is a slight variation, but in the context of the exam, the principle is 'defined roles and responsibilities'. However, since the question asks for two, and the correct ones are continued business justification and manage by exception, this option is not correct as it is not one of the two correct answers in this multi-select context. The principle exists but is not selected here.

Identify and manage risks

Why it fails: Identify and manage risks is not one of the seven PRINCE2 principles. While risk management is a key theme in PRINCE2, it is not a principle. The principles are the guiding obligations that must be applied for a project to be considered PRINCE2. Risk management is part of the risk theme, which is tailored and applied according to the project's needs.

Manage by stages

Why it fails: Manage by stages concerns dividing the project into controllable stages with decision points, not continuously validating the business case. It is tempting because stage boundaries include business case reviews, but the principle directly governing ongoing viability is continued business justification.

Learn from experience

Why it fails: Learning from experience concerns capturing and applying lessons from previous projects and throughout the lifecycle; it does not govern whether the investment remains justified. It is tempting because lessons are reviewed at each stage boundary, but the stem describes assessing continued viability, which is the continued business justification principle.

Tailor to suit the project environment

Why it fails: Tailoring concerns adapting PRINCE2's themes, processes and roles to the project's scale, complexity and environment; it says nothing about reviewing continued viability. It is tempting because tailoring is a genuine PRINCE2 principle applied at initiation, but the stem's ongoing viability review maps to the continued business justification principle.

Defined roles and responsibilities

Why it fails: Roles might have been defined.

Continued business justification

Why it fails: The business case might still be valid.

Learn from experience

Why it fails: Lessons are not the primary concern.

Continued business justification

Why it fails: Continued business justification requires a valid Business Case throughout the project; it does not address adapting PRINCE2 to context. It is tempting because justification drives viability decisions, but it would be correct when the question concerns whether the project remains worthwhile, not tailoring.

Focus on products

Why it fails: Focus on products defines the project by its products and their quality criteria; it does not address adapting PRINCE2 to context. It is tempting because product-based planning shapes delivery, but it would be correct when the question concerns defining outputs and acceptance criteria rather than tailoring.

Manage by stages

Why it fails: Manage by stages divides the project into controllable management stages with decision points; it does not cover adapting PRINCE2 to context. It is tempting because stages are a visible structural feature, but it would be correct when the question concerns stage boundaries, end stage assessments or delegation.

Continued business justification

Why it fails: Continued business justification concerns whether the project remains viable and worth investing in, so it does not address planning horizon or detail. It is tempting because stage boundaries trigger justification reviews, but the stem's driver is dividing the project into manageable, controllable increments, which is the manage-by-stages principle.

Learn from experience

Why it fails: Learn from experience concerns capturing and applying lessons from previous projects and stages, which the stem never mentions. It is tempting because lessons are reviewed at stage boundaries, but the actual decision here is to plan only the next stage in detail, which is the manage-by-stages principle.

Focus on products

Why it fails: Focus on products defines the project by its deliverables and their quality criteria, not by how far ahead planning extends. It is tempting because stage plans derive from product descriptions, yet the stem's contrast between a stage plan and a full Gantt chart concerns planning horizon and control, which manage by stages governs.

Learn from experience

Why it fails: Learn from experience concerns capturing and applying lessons throughout the project, not sequencing product descriptions ahead of development. It tempts because retrospective reviews and lessons logs are prominent PRINCE2 activities, yet nothing in the stem indicates prior knowledge was ignored; the breach is defining products before building them.

Tailor to suit the project environment

Why it fails: Tailoring concerns adapting PRINCE2's themes, processes and roles to the project's scale and complexity; it does not govern when product descriptions are authored. It is tempting because tailoring legitimately permits adjusting documentation formality, but the stem's failure is that products were built before their descriptions existed, breaching the principle that defines outputs before work begins.

Manage by stages

Why it fails: Manage by Stages governs approval, tolerance and authorisation at stage boundaries; it does not require products to be defined before work begins. It is tempting because stages gate progression, but the violated principle is Focus on Products, which mandates product descriptions before development.

Risk management

Why it fails: This is a theme, not a principle.

Configuration management

Why it fails: This is a practice, not a principle.

Waterfall methodology

Why it fails: This is not a PRINCE2 principle.

Plans

Why it fails: This is a theme, not a principle.

Business Case

Why it fails: This is a management product, not a principle.

Focus on products

Why it fails: Focus on products concerns defining outputs and their quality criteria, which the exhibit already demonstrates, so it is not missing. It is tempting because product-based planning is central to PRINCE2, but it would be correct only if the configuration failed to define products and their acceptance criteria.

Manage by exception

Why it fails: Manage by exception concerns tolerances and escalation, and the exhibit already shows it applied, so it cannot be the missing principle. It is tempting because the principle is frequently tested, but it would be the right answer only if the configuration lacked defined tolerances or escalation routes.

All principles are applied

Why it fails: The exhibit does show a principle missing, so claiming all are applied contradicts the configuration. It is tempting because several principles are clearly evidenced, but PRINCE2 requires all seven to be applied; the exhibit omits one, making this option the correct choice only when every principle is demonstrably present.