Hard Difficulty Questions

Manage by exception

Why wrong: Manage by exception establishes tolerances, but the scaling of overall governance is governed by tailoring.

Focus on products

Why wrong: Focus on products deals with product delivery and quality, not overall governance scaling.

Manage by stages

Why wrong: Manage by stages dictates breaking the project into stages, but not scaling down governance structures inherently.

The requirement to alter mandatory PRINCE2 principles to suit executive convenience.

Why wrong: PRINCE2 principles are universal and cannot be altered or omitted; only the practices and governance can be tailored.

The personal preferences and favorite management frameworks of individual team members.

Why wrong: Tailoring is driven by project needs, environment, and organizational standards, not personal whims.

Manage by exception

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

Continued business justification

Why wrong: Although stage gates test the business case, the architectural breakdown into control points is manage by stages.

Tailor to suit the project

Why wrong: While stage length can be tailored, the primary mechanism of control through sequential decision points is manage by stages.

Focus on products

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

Defined roles and responsibilities

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

Continued business justification

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

Focus on products

Why wrong: Tolerance breaches regarding cost and time are governed by exception management, not product quality criteria.

Manage by stages

Why wrong: Stage boundaries are planned reviews, whereas mid-stage tolerance breaches are handled via exception.

Continued business justification

Why wrong: While market shifts affect the business case, the immediate procedural trigger for halting and reporting a tolerance breach is manage by exception.

Manage by exception

Why wrong: Sprint reviews are routine governance checkpoints, not exceptions.

Continued business justification

Why wrong: Sprint reviews validate product increments, not the ongoing business case viability.

Learn from experience

Why wrong: While sprints provide learning, their primary purpose in an agile context is iterative product delivery and stakeholder feedback.

Continued business justification

Why wrong: Acceptance criteria definition ensures product quality, not overall project economic viability.

Manage by stages

Why wrong: Iterations or increments relate to staging, but explicit deliverable definition is focus on products.

Tailor to suit the project

Why wrong: Using Product Descriptions is a mandatory PRINCE2 practice, not an example of tailoring.

Enforce rigid, repetitive routines without deviation to maximize short-term output

Why wrong: Rigid routines worsen stagnation and reduce creative problem-solving.

Prohibit any team communication outside of formal, highly restricted status meetings

Why wrong: Restricting communication stifles collaboration and creativity.

Conceal the automation plans until the final week before go-live to prevent early complaints.

Why wrong: Concealing plans causes severe shock and backlash when the system is suddenly deployed.

Replace all resistant staff members immediately before starting the project.

Why wrong: Mass replacement is impractical, highly disruptive, and damages corporate knowledge.

Dismiss the users' fears as groundless and proceed with the technical rollout without consultation.

Why wrong: Dismissing fears guarantees active user sabotage and failure of adoption.

Bypass the functional managers entirely and negotiate private overtime arrangements directly with individual team members.

Why wrong: Bypassing functional managers damages organizational relationships and violates governance protocols.

Reallocate all project tasks exclusively to external contractors to avoid relying on matrixed internal resources.

Why wrong: External contracting is often cost-prohibitive and fails to leverage necessary internal domain knowledge.

Escalate to the Executive to issue a corporate mandate making the project the absolute priority over all functional work.

Why wrong: Corporate mandates rarely solve underlying operational realities and can trigger hostile pushback.

Impose a single rigid communication style based solely on the Project Manager's home culture.

Why wrong: Imposing one cultural norm ignores local context and exacerbates misunderstandings.

Abandon all structured communication and rely exclusively on unstructured local chats.

Why wrong: Abandoning structure leads to loss of control and governance oversight.

Outsource all international stakeholder interactions to external consultants without oversight.

Why wrong: Outsourcing relationship management removes direct leadership accountability.

Drafting the detailed Team Plans for specialist delivery

Why wrong: Team Plans are drafted by Team Managers, not the Project Board.

Writing the Project Initiation Documentation

Why wrong: The PID is authored by the Project Manager, not the Project Board.

It is executed by the Project Board to govern stage boundaries.

Why wrong: Stage boundaries are managed via SB and DP, not MP.

It is responsible for authorizing the overall Project Initiation Documentation.

Why wrong: PID authorization is done by the Project Board in Directing a Project.

It replaces the Controlling a Stage process entirely.

Why wrong: MP runs concurrently with and supports Controlling a Stage; it does not replace it.

A detailed personnel evaluation and salary review for all project team members.

Why wrong: Personnel salaries and HR reviews are internal line management functions, not stage boundary report contents.

A request to dissolve the corporate organization.

Why wrong: Stage boundary reports do not alter corporate structures.

The final benefit realization audit conducted 5 years post-project.

Why wrong: Post-project benefit reviews occur long after the project and stage boundaries are complete.

Escalate directly to the Project Board, bypassing the Project Manager.

Why wrong: Team Managers report to and communicate through the Project Manager, not directly to the Project Board.

Pause the Work Package indefinitely until the supplier figures out a workaround.

Why wrong: Pausing work without formal notification and approval violates the control loops of MP and CS.

Change the quality criteria directly to match what the team can achieve and record it in the Team Plan.

Why wrong: Team Managers do not have the authority to change agreed product descriptions or quality criteria without Project Manager approval.

Initiating a project.

Why wrong: Initiating a project is an activity within the Initiating a Project process, not a Directing a Project board activity.

Authorizing project closure.

Why wrong: Project closure is premature unless the project is no longer viable, which is determined via 'Authorizing project closure' activity, but the board is looking for an alternative way forward.

Capturing and sharing lessons.

Why wrong: Capturing lessons is an ongoing activity, not the specific board response to an exception.

Approving the detailed Stage Plans for the entire project life cycle.

Why wrong: Only the initiation stage plan is planned during SU; subsequent stage plans are planned near the end of each preceding stage.

Authorizing the Project Management Plan.

Why wrong: The Project Management Plan is authorized by the Project Board during Initiating a Project, not during SU.

Conducting a formal End Project Evaluation.

Why wrong: End Project Evaluation occurs in Closing a Project.

The Project Assurance role independently

Why wrong: Project Assurance advises and monitors; it does not have executive decision-making authority to approve changes.

The Project Manager

Why wrong: The Project Manager can only authorize changes within agreed stage tolerances, not changes to the Project Product Description.

The Team Manager

Why wrong: Team Managers do not have authority to approve changes to project-level baselines.

Cancel the project immediately without preparing an End Stage Report.

Why wrong: Cancellation requires formal Project Board evaluation based on an Exception Report or End Stage Report.

Reduce the quality criteria of all upcoming products to offset the cost of the external resources.

Why wrong: Quality criteria cannot be arbitrarily lowered to cover budget overruns without board approval.

Procure the external resources immediately using project contingency funds without informing the board.

Why wrong: Major unexpected external resource costs impacting the Business Case must be approved by the Project Board.

Ignore the shift, as the End Stage Report only reflects past stage performance

Why wrong: Ignoring a critical threat to viability violates PRINCE2 principles.

Stop the current stage immediately without consulting the Project Board

Why wrong: Only the Project Board can prematurely terminate a stage or project.

Immediately rewrite the Business Case and submit it to Corporate

Why wrong: The Project Board must first decide the fate of the project based on the End Stage Report and updated Business Case recommendations.