Processes practice questions

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

Why it fails: Detailed Stage Plans for the whole life cycle are not produced in Starting up a Project; only the initiation stage plan is prepared. The option is tempting because planning is an SU activity, but full stage plans are created later during Managing a Stage Boundary, not before the project is even initiated.

Authorizing the Project Management Plan.

Why it fails: The Project Management Plan is authorised by the Project Board during Initiating a Project, not in Starting up a Project. The option is tempting because the Project Manager does draft it, but SU ends with the project brief and request to initiate; authorisation of the plan follows the initiation stage.

Conducting a formal End Project Evaluation.

Why it fails: End Project Evaluation belongs to Closing a Project, so it cannot occur during Starting up a Project. It is tempting because SU does assess whether the project is worthwhile, but that judgement is captured in the Project Brief and the initiation request, not a closure-stage evaluation.

The Project Assurance role independently

Why it fails: Project Assurance provides independent monitoring and advice to the Project Board; it holds no approval authority. It is tempting because assurance reviews changes, but approval of a change affecting the Project Product Description rests with the Project Board, which owns that product description.

The Project Manager

Why it fails: The Project Manager cannot self-approve changes to the Project Product Description; that document sits within the PID, so approval rests with the Project Board (or change authority it delegates to). The Project Manager is tempting because they author and maintain the PID, but authority to approve baseline changes is not theirs.

The Team Manager

Why it fails: The Team Manager only manages delivery of assigned work packages and has no authority over the Project Product Description, which forms part of the PID. It is tempting because Team Managers raise and assess change impacts, but approval of changes affecting project-level baselines belongs to the Project Board.

Starting up a Project

Why it fails: Starting up a Project is a pre-project process producing the Project Brief and daily log; it ends before the project proper begins. Lessons are captured continuously across all processes, with the Lessons Log created here but maintained throughout, not confined to this process.

Closing a Project

Why it fails: Closing a Project captures lessons for handover to the organisation at the end, but this is a terminal activity, not a continuous habit. The Lessons Log is reviewed and updated throughout every process, so lessons are not the preserve of closure alone.

Managing Product Delivery

Why it fails: Managing Product Delivery covers work package acceptance, execution and delivery by the Team Manager. Lessons are logged and shared continuously across the whole project lifecycle, not restricted to product delivery activities within this single process.

Disband the Project Board permanently

Why it fails: Disbanding the Project Board happens at project closure, after the final stage, not during Initiating a Project. It is tempting because IP does establish the Project Board, but that is appointment, not disbandment; IP's objectives centre on assembling the Project Initiation Documentation and securing project authorisation.

Hand over all project products to the operational environment

Why it fails: Handing products to the operational environment occurs during Closing a Project or through Managing Product Delivery transitions, not within Initiating a Project. It is tempting because IP defines acceptance criteria and operational arrangements, but the actual transfer of products happens later, once the project delivers them.

Appoint the initial Executive prior to project mandate receipt

Why it fails: The Executive is appointed before the project mandate is received, during the pre-project Starting up a Project process, not within Initiating a Project. It is tempting because IP does confirm Project Board roles, but those appointments already exist by then; IP focuses on documenting the project's justification and approach.

Executing specialist Work Packages

Why it fails: Executing specialist Work Packages belongs to Controlling a Stage, where the Project Manager authorises and monitors work. Managing a Stage Boundary instead produces the End Stage Report and Next Stage Plan for the Board. It is tempting because Work Packages are central to delivery, but SB is about reviewing and planning, not execution.

Appointing the initial Project Manager

Why it fails: Appointing the initial Project Manager occurs during Starting up a Project, before the Project Board exists to authorise the project. Managing a Stage Boundary covers producing the End Stage Report, updating the Business Case and Plan, and assembling the Next Stage Plan. Appointing is tempting as a project-setup task, but it precedes SB entirely.

Completed Work Package delivery sign-offs

Why it fails: Delivery sign-offs belong to Managing Product Delivery and confirm completed products, not the baseline documents IP assembles. They are tempting because sign-offs do feed later stage boundary and closure activity, but IP runs before any Work Package exists, so none can be available as an input.

The End Project Report from the previous project

Why it fails: The End Project Report is produced during Closing a Project of the same project, so it cannot exist beforehand. It is tempting because lessons from a prior project do inform IP via the Lessons Log, but that log, not the report itself, is the input PRINCE2 specifies.

IP is managed by Team Managers while SU is managed by Corporate.

Why it fails: Both SU and IP are managed by the Project Manager, with the Project Board authorising each; corporate management governs neither. Tempting because SU precedes the board's appointment of the Project Manager, but Team Managers are appointed later and manage stage work, not IP.

IP must be completed before SU can even begin.

Why it fails: SU precedes IP: the Project Brief and project approach are produced during SU, and IP builds the Project Initiation Documentation from them. Reversing the sequence is tempting because IP authorises the project, but authorisation happens after SU's work, not before it can start.

SU produces the final baselined Project Management Plan.

Why it fails: The Project Management Plan is baselined during Initiating a Project, not Starting up a Project, which only produces the Project Brief and outline business case. It is tempting because SU initiates activity, but the baselined plan is an IP output approved at the end of initiation.

Corporate/Programme management

Why it fails: Corporate or programme management sits outside the project's delivery structure, receiving reports and providing the project mandate; it does not work within Managing Product Delivery. It tempts because it owns the business case context, but MP involves only the Project Manager, Team Manager and team members.

Senior Supplier only

Why it fails: The Senior Supplier is a Project Board role providing supplier resources and assurance, not an active participant in Managing Product Delivery. MP involves the Project Manager, Team Manager and the team. It tempts because the Senior Supplier represents those delivering products, yet the Team Manager, not the Board, accepts and executes work packages.

Executive

Why it fails: The Executive is a Project Board role responsible for the business case and direction, not for delivering work packages. Managing Product Delivery involves the Project Manager, Team Manager and team members. It tempts because the Executive owns the project's justification, but MP concerns accepting, executing and delivering work packages.

Project Mandate

Why it fails: The Project Mandate is an input to Starting up a Project, produced before the project even exists, so it cannot be created or updated at a stage boundary. It is tempting because SB does revisit earlier documentation, but the Mandate is superseded by the Project Brief and PID, not revised during delivery stages.

End Project Report

Why it fails: The End Project Report is produced during Closing a Project, not at an intermediate stage boundary. It is tempting because SB and CP both involve review and reporting, but the End Project Report evaluates the whole project's performance against its baseline, which only becomes possible once all stages are complete.

Initial Project Brief

Why it fails: The Initial Project Brief is created in Starting up a Project, before the project mandate is expanded, and is baselined at the end of Initiating a Project. Managing a Stage Boundary instead produces the End Stage Report, Next Stage Plan and updated Business Case. It is tempting because the Brief is a baseline document, but it is not revisited at stage boundaries.

Direct the Project Manager to alter stage tolerances without a plan

Why it fails: Stage tolerances are set by the Project Board within the stage plan; altering them without an approved plan breaches the tolerance baseline. It is tempting because the Board may adjust tolerances, but only through a formal Exception Plan or revised stage plan, not verbally.

Take over day-to-day management of the work packages directly from the Team Managers

Why it fails: The Project Board sets tolerance and direction; it never assumes operational control of work packages, which remains with Team Managers under Managing Product Delivery. Escalation triggers a Board decision — instruct, stop, or replan the stage — not direct supervision. It tempts because Boards do intervene when tolerances are breached, but through direction, not by managing delivery.

Closing a Project

Why it fails: Closing a Project handles acceptance, handover and post-project review once the product is delivered; it cannot appoint a Project Manager or authorise the mandate. Pre-project work sits in Starting up a Project, which produces the Project Brief and appoints the Project Manager before the Board authorises initiation. The name suggests a lifecycle bookend, hence the pull.

Managing Product Delivery

Why it fails: Managing Product Delivery governs the Team Manager's acceptance, execution and delivery of work packages, not Board-level pre-project appointments. Starting up a Project is where the Board appoints the Project Manager and authorises the mandate's transition into the Project Brief. Its delivery focus makes it tempting when thinking about who does the work.

Controlling a Stage

Why it fails: Controlling a Stage covers the Project Manager's day-to-day monitoring of an authorised stage, not pre-project Board activity. Appointing the Project Manager and authorising the mandate belong to Starting up a Project, which precedes the initiation stage. The stage-management terminology attracts candidates because it sounds like early governance.

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

Why it fails: The End Stage Report covers performance against the stage plan, business case, risks, issues and lessons; personnel salary reviews sit with line management, not project governance. It is tempting because team performance matters, but that data is handled through resource management and appraisals outside PRINCE2 reporting.

A request to dissolve the corporate organization.

Why it fails: Dissolving the corporate organisation is outside the project's remit; the End Stage Report reviews stage performance and forecasts the next stage for the Project Board's continued business justification decision. Corporate restructuring is a strategic matter, not a stage boundary artefact.

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

Why it fails: Benefit realisation is reviewed post-project, often years later, so a five-year audit cannot inform an End Stage Report at a stage boundary. It is tempting because benefits underpin the business case, but the report uses current benefit reviews and the updated business case, not future audits.

Directing a Project

Why it fails: Directing a Project authorises and provides ad-hoc direction; it never authors plans. It is tempting because the Project Board approves the initiation-stage plan, but authorising a plan differs from creating it. The detailed next-stage plan is produced in Initiating a Project, where the Project Initiation Documentation is assembled.

Starting up a Project

Why it fails: Starting up a Project produces the Project Brief and outline business case, then requests project initiation; it creates no stage plan. It is tempting because it precedes initiation, but its remit is the pre-project groundwork. The detailed next-stage plan belongs to Initiating a Project, which assembles the Project Initiation Documentation.

Managing a Stage Boundary

Why it fails: Managing a Stage Boundary plans the following stage only when a stage is ending, not the stage after initiation. It is tempting because it does produce next-stage plans, but that occurs at each subsequent boundary. The stage immediately after initiation is planned during Initiating a Project itself.

Project Assurance

Why it fails: Project Assurance provides independent monitoring and advice to the Project Board on project viability; it does not approve the Project Brief. It is tempting because it reviews project documentation, but the Project Board itself approves the Brief, and Assurance would be correct for reporting on whether the project remains justified.

Project Manager

Why it fails: The Project Manager drafts the Project Brief but cannot approve it; approval sits with the Project Board, since the Brief is the document they use to authorise initiation. Drafting and approving are deliberately separated. The Project Manager is tempting because they own the document's production, but that ownership covers writing, not sign-off.

Project Support

Why it fails: Project Support administers tools, templates and information management; it holds no approval authority over the Project Brief. Approval rests with the Project Board, who authorise initiation based on the Brief. Project Support is tempting because it often maintains project documentation, but maintaining documents differs from approving their content.

Executive role description

Why it fails: The executive role description is defined in the Project Brief's project management team structure and carried into the PID, so it is inherited rather than newly created. It tempts because the executive is central to PRINCE2 governance, but the PID baselines artefacts such as the business case and project plan.

Project objectives

Why it fails: Project objectives are already stated in the Project Brief, which the PID then refines and baselines rather than originating them. It tempts because objectives are fundamental to the PID, yet the Brief supplies the outline; the PID newly creates the detailed business case, plans and controls.

Project Approach

Why it fails: The Project Approach is selected during Starting up a Project and recorded in the Project Brief, so it is inherited, not newly created for the PID. It tempts because the approach shapes planning, but the PID baselines the business case, project plan, benefits and risk management approach.

Issue an Exception Report directly to the Project Board

Why it fails: Team Managers and Project Managers do not raise Exception Reports directly to the Project Board; only the Project Manager raises Project-level Exception Reports to the Board.

Terminate the Work Package immediately

Why it fails: Tolerances are designed for management escalation, not automatic termination.

Adjust the Project Board's stage tolerances

Why it fails: The Project Manager has no authority to adjust Project Board tolerances.

The Project Board Executive

Why it fails: The Executive owns the business case and benefits, while acceptance of products is confirmed by the Senior User or the customer receiving them. It is tempting because the Executive authorises the project, but Closing a Project records acceptance from those who will use and operate the products.

Project Assurance

Why it fails: Project Assurance monitors the project on the board's behalf against business, user and supplier interests; it does not confirm product acceptance. Acceptance is performed by the customer or senior user receiving the products. Project Assurance would be involved in reviewing closure documentation, not in confirming handover.

Project Manager

Why it fails: The Project Manager prepares the End Project Report and closure documentation, but cannot confirm acceptance of products they delivered. Acceptance belongs to the customer or senior user who receives them. The Project Manager would be correct for assembling the closure notification, not for confirming acceptance.

Automatically extend the project deadline by the saved amount

Why it fails: Positive variance is recorded and reported through Highlight Reports and, if significant, escalated via Exception Report; the deadline is not extended automatically. Tempting because saved time could be reallocated, but PRINCE2 requires the Project Board to authorise any change to the baseline.

Close the entire project immediately

Why it fails: A single Work Package completing early does not justify closing the project; closure follows the Closing a Project process once all products are delivered and accepted. Tempting because early completion suggests readiness, but other work packages and stage boundaries remain outstanding.

Immediately return the saved money to corporate treasury without informing anyone

Why it fails: Financial variance is handled through the stage budget and reported to the Project Board; saved funds are not returned unilaterally without governance approval. Tempting because underspend appears surplus, but PRINCE2 requires tolerance-based escalation and formal change control before releasing budget.

Rewriting the Business Case to reflect actual total costs and benefits realized

Why it fails: The Business Case is updated with actuals during Closing a Project, not rewritten to reflect realised benefits, which are only measurable post-project. Rewriting it is tempting because evaluating the Business Case against actual costs and benefits is a genuine closing activity, but the mandatory action is updating, not rewriting.

Appointing new members to the Project Board for post-project governance

Why it fails: Closing a Project dissolves the Project Board; it never appoints new members for post-project governance, which belongs to the host organisation's operational or programme structure. Appointing members is tempting because confirming who owns the products after closure is a closing concern, but that is acceptance, not new board appointments.

Highlight Report template for the Board

Why it fails: The Highlight Report template is produced during Controlling a Stage, not Initiating a Project, which instead creates the Project Initiation Documentation and strategies. It is tempting because reporting is planned early, but the template belongs to the stage-level progress reporting cycle once delivery begins.

End Stage Report for the initiation stage

Why it fails: Initiation is a stage, but it results in a Project Initiation Documentation approval rather than a standard End Stage Report (though an end-stage evaluation occurs).

Team Plan for the first work package

Why it fails: Team Plans are created by Team Managers as Work Packages are assigned, often during delivery stages.