People: organizations, teams, and leadership practice questions

Increase the number of management stages to allow more frequent checkpoints

Why it fails: Adding stages alters the number of control points but not the underlying delegation of authority and tolerances that 'manage by stages' requires; the principle concerns defining and authorising each stage, not multiplying them. More stages suit long, high-risk projects needing tighter review, not a communication-delay problem.

Update the communication management approach to include asynchronous updates

Why it fails: Communication delays are a delivery concern, not a stage-boundary control; the communication management approach governs channels, not the delegation of authority that 'manage by stages' requires. It would be correct when planning how distributed teams exchange information, but here the principle demands defining stage boundaries and tolerances first.

Implement daily stand-up meetings at a time that is convenient for the majority

Why it fails: Scheduling stand-ups addresses daily coordination, not the stage-boundary and tolerance structure that 'manage by stages' governs. Stand-ups suit agile delivery cadence, but this principle requires the Project Board to authorise work stage by stage, with defined tolerances, before any meeting format is chosen.

Defined roles and responsibilities

Why it fails: While related, the issue is specifically about bypassing stage gates and escalation, not undefined roles.

Learn from experience

Why it fails: This principle involves capturing and applying lessons, not escalation procedures.

Continued business justification

Why it fails: This principle is about ensuring the project remains viable, not about escalation paths.

Included the critical risks in the project plan

Why it fails: Embedding risks in the project plan buries them in a baseline document the board approves once, not a channel for escalating current critical risks. It is tempting because the plan is a formal board-facing artefact, but it would be right for capturing baseline assumptions, not for ensuring members actually receive urgent risk information.

Prepared a highlight report instead of a detailed risk report

Why it fails: A highlight report is a periodic progress summary, so critical risks could still be omitted or understated; the stem's problem is that members were unaware, not that the report was too detailed. Highlight reports suit regular board progress updates, whereas critical risks need explicit, targeted communication to those affected.

Updated the risk register and sent it to the board

Why it fails: Distributing the risk register documents risks but does not guarantee the board reads or acknowledges them; the stem's failure is that members were unaware, which is a communication, not documentation, gap. Sending the register suits routine risk visibility, whereas the board needed a deliberate, targeted communication of critical risks.

Executive: Manages the project on behalf of the Project Board.

Why it fails: Incorrect — this describes the Project Manager's role, not the Executive's.

Senior User: Ensures the project has sufficient resources.

Why it fails: Incorrect — this describes the Senior Supplier's responsibility, not the Senior User's.

Project Manager

Why it fails: The Project Manager develops and maintains the Business Case on behalf of the Executive, but accountability remains with the Executive.

Senior User

Why it fails: The Senior User represents the users' interests but is not accountable for the Business Case.

Project Assurance

Why it fails: Project Assurance provides independent oversight but is not responsible for maintaining the Business Case.

Increase the stage budget and continue with the current plan

Why it fails: Stage tolerances are set by the project board, so the Project Manager cannot unilaterally raise the budget; a forecast breach must be escalated via an exception report. Increasing the budget is tempting because it appears to keep delivery on track, and would be correct only if the board had already delegated that tolerance.

Continue with the plan and report the overrun in the next Highlight Report

Why it fails: PRINCE2 requires the Project Manager to raise an exception report as soon as a forecast breach of stage tolerance is identified, escalating to the project board for a decision. Continuing and reporting later is tempting because Highlight Reports do cover progress, but they inform rather than trigger the tolerance-escalation mechanism.

Close the project immediately as the Business Case is no longer viable

Why it fails: Closing the project immediately is premature because exceeding stage cost tolerance does not automatically invalidate the Business Case; the Project Manager must first assess whether the deviation can be managed via an Exception Plan. This option is tempting because a fundamental breach of tolerance can indeed threaten viability, and if the Business Case were genuinely no longer viable, escalating for premature closure would be the correct action under PRINCE2’s exception management process.

Project Manager

Why it fails: The Project Manager cannot be responsible for assurance as it must be independent of management.

Senior Supplier

Why it fails: The Senior Supplier may provide assurance from the supplier perspective, but the Board as a whole is responsible.

Team Manager

Why it fails: The Team Manager is focused on delivering Work Packages, not assurance.

Coaching

Why it fails: Coaching is for low competence and low commitment; this team has high competence.

Delegating

Why it fails: Delegating is for high competence and high commitment; this team has low commitment.

Directing

Why it fails: Directing is for low competence; this team has high competence.

Issue a Change Request directly to the Project Manager

Why it fails: The Senior Supplier raises the concern through the Project Board or Project Manager rather than issuing a Change Request, which is a formal product owned by the Project Manager. It tempts because suppliers do flag feasibility issues, but the Change Request mechanism belongs to change control, not supplier escalation.

Approve the change as it aligns with the Business Case

Why it fails: The Senior Supplier provides supplier-side assurance on feasibility; approving changes against the Business Case is the Executive's decision, taken at the Project Board. It tempts because suppliers care about viability, yet Business Case approval is not their remit.

Update the Project Plan to reflect the change

Why it fails: Updating the Project Plan is the Project Manager's responsibility, and only after a change is approved through change control. It tempts because the supplier may hold technical detail needed for replanning, but amending the plan bypasses the board's authorisation.

Business Case

Why it fails: The Business Case is developed within Initiating a Project, but it is not the process's key output; the Project Initiation Documentation is. It is tempting because the Business Case justifies the project's continued viability, and it would be the central artefact when seeking board approval to proceed past the starting gate.

Stage Plan

Why it fails: A Stage Plan covers one management stage's delivery detail, produced during Managing a Stage Boundary, not Initiating a Project. It is tempting because initiation does create the first Stage Plan, but the process's key output is the Project Initiation Documentation, which consolidates the baseline for the whole project.

Project Brief

Why it fails: The Project Brief is the key input to Initiating a Project, not its output; it is produced during Starting up a Project. It is tempting because the Brief defines the project's initial scope and justification, and would be the correct answer had the question asked for the trigger to initiation.

An RFC is raised by the Project Board, while an Off-Spec is raised by the Project Manager

Why it fails: Both can be raised by anyone; the source does not define the type.

An RFC is about a change to an approved product, while an Off-Spec is about a problem with project management

Why it fails: Off-Specs are about products, not management.

They are the same thing

Why it fails: They are distinct; RFC proposes a change, Off-Spec identifies a failure to meet a requirement.

Project Manager

Why it fails: The Project Manager maintains the project documentation but does not own the Business Case.

Project Assurance

Why it fails: Project Assurance provides independent oversight but does not maintain the Business Case.

Senior User

Why it fails: The Senior User represents the users and specifies the requirements but is not accountable for the Business Case.

Project Brief

Why it fails: The Project Brief precedes initiating, being the trigger input that authorises the process to begin; it is refined into the PID during initiating. It is tempting because it does define the project's initial scope and objectives, and would be the correct output of the Starting up a Project process.

Project Plan

Why it fails: The Project Plan is created during Initiating a Project, but the key output of that process is the Project Initiation Documentation, which consolidates the business case, plan and controls. The plan is tempting because it is a major component, yet it is one element of the PID rather than the process's primary deliverable.

Business Case

Why it fails: The Business Case is refined during initiating, but it is a component of the PID rather than the key output itself. It is tempting because initiating does develop it, yet the PID is the single document that consolidates the Business Case, plans, and controls.

Continue and report the overrun in the next Highlight Report

Why it fails: Highlight Reports are progress updates, not exception mechanisms; a forecast breach of cost tolerance must be escalated immediately via an Exception Report so the Project Board can decide. Reporting later suits minor in-tolerance variances, not a predicted tolerance exceedance.

Increase the budget and continue with the current plan

Why it fails: Raising the budget breaches the Project Manager's delegated cost tolerance; only the Project Board can authorise additional funding via a change to the Business Case. It tempts because contingency reserves exist for genuine variances, but those are released through formal exception handling, not unilateral overspend.

Close the project as the Business Case is no longer viable

Why it fails: Exceeding cost tolerance is a stage-level exception handled by escalating to the Project Board, which decides on corrective action; closing the project is a board decision based on Business Case viability, not the manager's. It is tempting because closure is correct when the Business Case itself is no longer viable.

To manage the delivery of work packages

Why it fails: Managing work packages is part of the Controlling a Stage process.

To plan the next stage and update the project plan

Why it fails: This is part of the process, but not the full purpose.

To request authorization to start the project

Why it fails: Authorization to start the project is given after Initiating a Project.

There is no difference; they are synonyms

Why it fails: A Request for Change proposes altering a baselined product; an Off-specification reports that a product will not meet an agreed specification. They trigger different PRINCE2 issue-and-change handling. Treating them as synonyms is tempting because both are issues, but their origin and required response differ.

A Request for Change is about schedule changes; an Off-specification is about quality issues

Why it fails: Both are issue types, but the axis is not schedule versus quality: a Request for Change seeks approval to modify baselined products, while an Off-specification reports a product that will not meet its agreed specification. It is tempting because change often affects schedule, yet a change may concern scope or cost with no quality dimension.

A Request for Change is raised by the Project Manager; an Off-specification is raised by the Team Manager

Why it fails: Raising authority is not the distinguishing axis; anyone may raise either issue. A Request for Change proposes altering a baselined product, whereas an Off-specification discloses that a product cannot meet its specification. It is tempting because Team Managers commonly raise Off-specifications, but Project Managers can raise both.

Managing the day-to-day activities of the project

Why it fails: This is the Project Manager's responsibility.

Preparing the Project Plan

Why it fails: The Project Manager prepares the Project Plan.

Approving the Work Packages

Why it fails: Work Packages are authorized by the Project Manager, not the SRO.

The Change Authority is appointed by the Project Manager

Why it fails: The Change Authority is appointed by the Project Board, which owns change authority, not by the Project Manager. It is tempting because the Project Manager handles day-to-day change administration, and appointment by the Project Manager would be correct for roles the Board explicitly delegates to them.

The Change Authority is always a single person

Why it fails: PRINCE2 permits the Change Authority to be delegated to one or more people, or to a group such as a change board, so a single person is not mandatory. It is tempting because small projects often assign this to one individual, which is a valid configuration rather than a rule.

The Change Authority is a mandatory role in PRINCE2

Why it fails: The Change Authority is optional; it is only appointed when the Project Board delegates change decisions, so it is not mandatory. It is tempting because change control is mandatory in PRINCE2, and the role would be required if the Board chose to delegate authority rather than retain it.

There is no difference; they are interchangeable terms

Why it fails: An RFC and an Off-spec are distinct PRINCE2 records: an RFC requests a change to a baseline, while an Off-spec reports something delivered that fails to meet its specification. Treating them as interchangeable ignores this distinction. They are tempting to conflate because both trigger change control, but they capture different events.

An RFC is a change to the project scope; an Off-spec is a change to the schedule

Why it fails: An RFC covers any proposed change to a baselined product, and an Off-spec records a product that does not meet its agreed specification — neither is defined by schedule versus scope. This split misreads both terms. It is tempting because both feed change control, but the axis is specification conformance, not scope versus time.

An RFC is raised by the Project Board; an Off-spec is raised by the Project Manager

Why it fails: The raising authority for both Requests for Change and Off-specifications is not exclusively tied to the Project Board or Project Manager; anyone can raise either. The fundamental difference lies in an RFC being a *proposal* for a desirable change to baselined products, whereas an Off-spec is a *report* of a deviation from baselined products that has already occurred or is forecast. This option is tempting because the Project Board ultimately *authorises* changes and the Project Manager *manages* the change control procedure, leading to a misconception about their exclusive raising roles.

Project Assurance is performed by the Project Manager; a quality review is performed by the team

Why it fails: Assurance is independent, not the PM.

Project Assurance is optional; a quality review is mandatory in every stage

Why it fails: Both are recommended but not mandatory in every stage.

Project Assurance reports to the Project Board; a quality review reports to the Project Manager

Why it fails: Quality review results are reported to the PM, but not exclusively.