Hard Difficulty Questions

By delegating dependency mapping entirely to corporate quality assurance.

Why it fails: Delegating dependency mapping to corporate quality assurance removes the delivery team's ownership of sequencing across increments; dependencies must be identified and tracked within the plans themselves. Quality assurance audits process compliance. It is tempting because QA already reviews planning artefacts, suggesting oversight could substitute for mapping.

By relying solely on verbal agreements during daily stand-ups.

Why it fails: Verbal agreements leave no auditable record, so dependencies cannot be tracked, escalated or reconciled against the plan across increments. Stand-ups suit daily coordination of progress and blockers, not formal dependency documentation within a stage plan.

By listing them in the Risk Register under external threats.

Why it fails: The Risk Register records uncertain events and their responses, not confirmed product dependencies between increments. Dependencies belong in the plan's product descriptions; the Risk Register would only capture the threat that a dependency might slip.

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

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

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

Why it fails: Restricting communication stifles collaboration and creativity.

Automatically initiate the Closing a Project process early.

Why it fails: An underspend with progress on schedule is reviewed through Controlling a Stage, with the budget reviewed at stage boundaries; Closing a Project requires the project's products to be delivered and accepted. Early closure is tempting when work appears finished, but delivery and acceptance have not occurred.

Secretly reallocate the surplus funds to personal bonuses without informing anyone.

Why it fails: Diverting surplus funds to personal bonuses breaches the project's financial controls and the Project Manager's duty to report actuals and forecasts to the Project Board. It is tempting when underspend looks like spare cash, but PRINCE2 tolerances require disclosure and Board authorisation, not private reallocation.

Ignore the underspend since being under budget never requires management attention.

Why it fails: Underspend still requires review against the cost tolerance and revised forecasts, since it may signal mischarging, deferred work or inaccurate estimates. Ignoring it is tempting because under budget appears favourable, but Controlling a Stage mandates monitoring actuals against plan and escalating exceptions.

Transfer

Why it fails: Transfer shifts the financial impact to a third party, typically via insurance or contractual indemnity, and does nothing to lower the probability of cultural resistance. It would be correct for insurable losses, not for influencing middle-management behaviour through champions and incentives.

Avoid

Why it fails: Avoidance removes the threat entirely by changing scope, approach or objectives, for example abandoning the transformation. Here the project continues while countermeasures are added, so the risk is reduced rather than eliminated; avoidance would be correct if the change were cancelled.

Accept

Why it fails: Acceptance involves acknowledging the threat and taking no proactive action beyond contingency planning. Appointing champions and redesigning incentives actively reduce likelihood and impact, which is mitigation; acceptance would be correct only where the risk's cost is deemed tolerable.

Drafting the detailed Team Plans for specialist delivery

Why it fails: Team Plans are drafted by the Team Manager, not the Project Board, whose Directing a Project decisions are authorisation-focused. It tempts because the Board does approve Plans, but at stage and project level via the Project Manager, so delegation of detailed planning sits below their remit.

Writing the Project Initiation Documentation

Why it fails: The Project Initiation Documentation is written by the Project Manager, not the Project Board, which authorises it at the end of Initiating a Project. It tempts because the Board does approve the PID, but authorisation differs from authorship.

The 'People' aspect is only relevant during the 'Initiating a Project' process when the team is first formed, and should not be revisited in later stage boundaries.

Why it fails: This statement is incorrect because the 'People' aspect is relevant throughout the project lifecycle. Team dynamics and individual well-being can change over time, and PRINCE2 7 expects the Project Manager to continuously manage and monitor these factors. Ignoring them at stage boundaries would miss an opportunity to address issues before they escalate and could jeopardise the next stage's success.

The End Stage Report should focus exclusively on product delivery and business case viability, as people-related matters are outside the scope of PRINCE2.

Why it fails: While product delivery and business case viability are critical elements of the End Stage Report, PRINCE2 7 also recognises the importance of the 'People' aspect. Excluding people-related matters would give an incomplete picture of the stage's performance. The Project Manager should consider team morale, performance, and any personnel issues as part of the overall assessment, especially if they impact the project's ability to deliver.

The 'People' aspect is managed separately by the Project Board, so the Project Manager does not need to include team performance in the End Stage Report.

Why it fails: The Project Board is accountable for the overall success of the project, but the Project Manager is responsible for managing the team and reporting on its performance. The 'People' aspect is not managed separately; it is an integral part of the Project Manager's responsibilities. Excluding it from the End Stage Report would leave the Project Board without crucial information needed to make informed decisions about the next stage.

Leave it in the Risk Register and wait to see if the supplier recovers.

Why it fails: An unplanned severe threat requires escalation to the Project Board and immediate response planning, since the Risk Register must record an owner and response. Leaving it passive breaches the risk management principle that risks are actively managed. It is tempting to await supplier recovery, but tolerances and escalation thresholds demand proactive action.

Retroactively alter the Risk Management Approach to prevent bankruptcies.

Why it fails: The Risk Management Approach is a baseline document; PRINCE2 7 requires the Project Manager to escalate the unplanned threat to the Project Board as an exception, not rewrite the approach retrospectively. It tempts because the approach does define risk procedures, but it is updated only through formal change control, not to address a single materialised event.

Write off the project loss without informing the Project Board.

Why it fails: Writing off the loss bypasses the Project Board's exception and directing-a-project responsibilities; PRINCE2 7 requires escalation of a threat with no planned response so the Board can authorise recovery, re-plan or closure. It tempts as loss recognition, but tolerances exist precisely so breaches are reported, not absorbed silently.

Risk Management Approach review by Project Assurance

Why it fails: The Risk Management Approach is a strategy document reviewed during initiation; it is not a governance procedure invoked by a tolerance breach. It is tempting because the disruption originated as a risk, and reviewing the approach would be correct when planning how risks are identified and controlled.

Project Closure procedure

Why it fails: Closure applies only when the project is being brought to a controlled end, so it cannot address an in-stage forecast breach. It is tempting because a severe overrun may eventually trigger premature closure, but that decision follows escalation, not the breach itself.

Initiating a Project process

Why it fails: Initiating a Project produces the Project Initiation Documentation and only runs once, before delivery begins, so it cannot respond to a Stage 2 forecast. It is tempting because re-planning resembles re-initiation, and it would be correct when starting a new project or re-baselining after closure.

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

Why it fails: Concealment violates PRINCE2's principle of communicating openly with stakeholders, inflaming the very resistance described. This option tempts because delaying bad news can seem tactically safe, but that suits short, low-stakes rollouts; here it destroys trust and guarantees the feared outcome.

Replace all resistant staff members immediately before starting the project.

Why it fails: Removing resistant staff destroys the trust and psychological safety PRINCE2 7 engagement depends on, and ignores the root fear driving the resistance. It is tempting because removing blockers feels decisive, and would fit a compliance-driven scenario where individuals actively sabotage delivery rather than merely resist change.

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

Why it fails: Dismissing fears breaches PRINCE2's engage-and-communicate principle, which requires addressing stakeholder concerns to sustain buy-in. This option tempts because some projects do proceed despite resistance, but that approach fits low-impact technical changes, not deep-seated cultural opposition where engagement determines adoption.

Focusing exclusively on delivering technical project outputs on time and under budget.

Why it fails: Delivering outputs on time and under budget addresses product delivery, not the behavioural adoption the transformation demands. It is tempting because PRINCE2 emphasises continued business justification and stage boundaries. Managing change requires addressing people, culture and readiness, which this output-only focus omits.

Outsourcing all change communication to an external public relations firm to maintain corporate image.

Why it fails: External PR teams control messaging but cannot own the business-unit engagement, capability building and feedback that PRINCE2 7 places with the change team. It is tempting because PR firms excel at crisis communications and brand reputation, which would be the right choice for a public-facing announcement or media-handling campaign.

Enforcing compliance through strict HR disciplinary measures for any staff member who questions the new processes.

Why it fails: Disciplinary enforcement suppresses the open feedback and learning PRINCE2 7 change management depends on, so resistance goes underground rather than being addressed. It is tempting because formal authority can force surface compliance, which would suit a mandatory safety or regulatory rule where behaviour must change regardless of buy-in.

When a Team Manager fails to complete a single Work Package on time.

Why it fails: A single late Work Package is handled by the Project Manager within stage tolerances, escalating only if the stage tolerance is forecast to be breached. An Exception Plan is warranted when stage-level tolerances are exceeded, not one work package's delay.

When the Project Board wants to prematurely close the project due to corporate budget cuts.

Why it fails: Premature closure is handled through the Directing a Project decision to close, not by producing an Exception Plan. An Exception Plan responds to a forecast breach of stage or project tolerances, replacing the current Stage Plan to bring the project back within tolerance.

Automatically at the end of every successful stage, regardless of performance.

Why it fails: Routine stage-end planning produces the next Stage Plan, not an Exception Plan; an Exception Plan is only triggered when stage or project tolerances are forecast to be exceeded. It would be correct if the question asked what the Project Manager produces at every normal stage boundary.

Exempt the project from the Plans practice.

Why it fails: Exempting the project abandons a practice the organisation requires all projects to apply, so the governance mandate is breached rather than tailored. It is tempting because tailoring permits scaling the practice to project size, and exemption would suit a small, low-risk project where formal plans add no control value.

Replace Product Descriptions with sprint backlogs across the entire project.

Why it fails: Replacing Product Descriptions with sprint backlogs project-wide removes the defined product scope, quality criteria and acceptance method that stage-gate governance depends on. It is tempting because sprint backlogs legitimately describe near-term agile work, and they would be the correct artefact for a wholly agile project without traditional gating.

Discard the Stage Plan entirely and rely solely on agile Kanban boards.

Why it fails: Discarding the Stage Plan removes the governance baseline the organisation mandates, leaving stage boundaries, tolerances and gating approvals undefined, so traditional governance cannot operate. It is tempting because Kanban boards give agile teams visible flow, and they would be the right complement to, not replacement for, a Stage Plan.

Document the conflict in the Issue Register and assign it to the Senior User, as they are responsible for representing user needs and should resolve any disputes.

Why it fails: While issues should be captured in the Issue Register, assigning the conflict to the Senior User implies they are solely responsible for resolving it. In PRINCE2 7, the Project Manager is responsible for managing issues, including conflicts, and should not delegate this responsibility entirely to one party. The Issue Register is a tool for tracking, not for assigning blame or responsibility for resolution.

Escalate the conflict to the Executive immediately, as only the Executive has the authority to resolve disputes between project board members.

Why it fails: While the Executive is ultimately accountable for the project and may need to be involved in escalated disputes, immediate escalation is not the first step. PRINCE2 7 advocates that the Project Manager should first attempt to resolve conflicts at the lowest possible level. Escalating immediately can undermine the Project Manager's role and may be premature if the issue can be addressed through facilitated discussion.

Refer the matter to the Change Authority to formally raise a Request for Change, as the conflict indicates a change in requirements.

Why it fails: The Change Authority is responsible for approving or rejecting changes to the project's baselines, not for resolving interpersonal or role-based conflicts. Raising a Request for Change would only be appropriate if the conflict resulted in a proposed change to the project's scope, time, cost, or quality baselines. Using the change control process to address a disagreement about scope interpretation would be a misuse of that mechanism.

The Daily Log tracking minor operational issues.

Why it fails: The Daily Log records routine progress, risks and issues; it does not articulate purpose or align stakeholder mindset. It is tempting as a familiar control artifact, but revisiting the project's vision and benefits, not operational logging, addresses conflicting departmental assumptions.

The Project Management Team structure chart in the Project Initiation Documentation.

Why it fails: The team structure chart shows roles, responsibilities and reporting lines, not shared purpose or mindset. It is tempting because it maps stakeholders, but PRINCE2 7 addresses cultural resistance through the project vision and benefits, which align assumptions rather than define hierarchy.

The Work Package descriptions issued to team managers.

Why it fails: Work Packages are agreements with team managers covering delivery of products, not artefacts for aligning stakeholder mindset. They are tempting because they communicate expectations, but they address task execution rather than the conflicting assumptions about purpose that the project's vision or communication approach must resolve.

Cancel the project immediately without preparing an End Stage Report.

Why it fails: Cancellation is a board decision taken after reviewing an End Stage Report and updated Business Case, not an immediate Project Manager action. The PM should prepare the next Stage Plan and Exception Report for the board. Cancelling outright would be right only when the board judges the project no longer viable.

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

Why it fails: Lowering quality criteria to absorb cost breaches the quality theme; tolerance deviations must be escalated via an Exception Report, not resolved by degrading products. Quality criteria derive from customer expectations recorded in the Project Product Description. Reducing scope formally, with board approval, would be the legitimate route.

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

Why it fails: Spending contingency outside delegated tolerances bypasses the board's direction and the change control approach; unplanned external resource costs require an Exception Report. Contingency is drawn only within authorised tolerance. Escalating first would be correct; direct procurement suits costs already inside the Stage Plan's agreed budget.

Coercive power, enforcing compliance through direct disciplinary control.

Why it fails: Coercive power relies on disciplinary control the Project Manager lacks over experts reporting to other line managers, so it cannot secure genuine collaboration. It tempts because authority appears decisive, and would suit a direct line-management hierarchy where the manager controls subordinates' objectives and appraisals.

Laissez-faire management, allowing experts to operate in total isolation without coordination.

Why it fails: Laissez-faire abdicates the coordination PRINCE2 7 requires when experts span reporting lines; collaboration demands active engagement, not isolation. It is tempting because autonomy suits self-organising specialists, and would fit a stable team with mature, aligned self-governance and no cross-functional dependencies.

Micro-management, dictating every detailed step of the experts' technical work.

Why it fails: Micro-management overrides the delegated authority experts hold from their own line managers, undermining the trust collaboration requires. It tempts because close control feels diligent, and would fit a junior, inexperienced team performing unfamiliar, tightly specified tasks under direct supervision.

Complete risk response categorization for external threats

Why it fails: Product Descriptions define purpose, composition, derivation, quality criteria, quality method and tolerances for a deliverable; risk response categorisation belongs in the Risk Register. It is tempting because quality criteria and risks are linked, but categorising external threats is a risk management activity, not a product specification element.

Individual team member salary scales and contracts

Why it fails: Product Descriptions specify the deliverable's purpose, composition, quality criteria and quality method; salary scales and contracts are commercial and HR records held elsewhere. It is tempting because team resourcing affects delivery, but remuneration data is not a product specification element and would not define acceptance.

Draft the End Stage Report for the Project Board.

Why it fails: The End Stage Report is drafted by the Project Manager at a stage boundary, not by a Team Manager completing a Work Package. It is tempting because stage-end reporting does occur in PRINCE2, but that activity belongs to Managing a Stage Boundary, where the Project Manager reviews progress before the Project Board authorises the next stage.

Update the Project Business Case with actual costs incurred during manufacturing.

Why it fails: Business Case updates are the Project Manager's responsibility, drawing on Highlight Reports and stage boundary reviews, not a Team Manager's task on Work Package completion. It is tempting because actual costs do inform the Business Case, but that happens during Managing a Stage Boundary, not within Managing Product Delivery.

Perform a formal project-level post-project benefit review.

Why it fails: Post-project benefit reviews occur after project closure, within the Benefits Review Plan's later timeframe, not when a Team Manager returns completed products. It is tempting because benefits realisation is a genuine PRINCE2 concern, but the Team Manager's immediate duty is obtaining approval of the completed Work Package products before handover.

Penalize the auditor for finding a non-conformance.

Why it fails: Auditors report non-conformances; penalising them suppresses the assurance the Quality practice depends on. The corrective action is to raise the non-conformance and re-check the product against the missed criterion. Penalties apply to those who approved the product, not to the auditor who detected the gap.

Automatically reject the entire project stage and restart it.

Why it fails: Rejecting and restarting the whole stage is disproportionate; the Quality practice requires the failed criterion to be re-checked and the product corrected, not the stage discarded. It tempts as a strict response to non-compliance, but stage-level rejection is not a defined corrective action.

Update the Quality Management Approach to exclude that criterion retroactively.

Why it fails: Retrospectively removing a mandatory criterion from the Quality Management Approach falsifies the quality baseline rather than correcting the product. It tempts as a quick administrative fix, yet the criterion was contractually agreed in the Product Description and must be met, not deleted.

It eliminates the need for stage boundary approvals by the Project Board.

Why it fails: Stage boundary reviews remain mandatory.

It transfers all schedule risk to the Senior Supplier.

Why it fails: Risk ownership is separate from the planning methodology.