Overview of PRINCE2 and the project environment practice questions

Risk Register

Why it fails: The Risk Register lists risks, not objectives.

Business Case

Why it fails: The Business Case provides justification but does not detail alignment with strategy.

Project Plan

Why it fails: The Project Plan focuses on the project's approach and schedule.

Continued business justification

Why it fails: This principle ensures the project remains viable, but does not directly address audit trails.

Tailor to suit the project environment

Why it fails: Tailoring is about adapting PRINCE2, not specifically about maintaining evidence.

Learn from experience

Why it fails: This principle focuses on capturing lessons, not on audit evidence.

Resources

Why it fails: Resources are part of cost, not a separate aspect.

Value

Why it fails: Value is not a separate aspect; benefits cover value.

Customer satisfaction

Why it fails: Customer satisfaction is not a separate aspect; it relates to quality and benefits.

Senior User

Why it fails: The Senior User represents user interests on the Project Board and specifies requirements, but does not authorise the initiation stage. That authority belongs to the Project Board, which approves the Project Initiation Documentation and the business case.

Project Manager

Why it fails: The initiation stage requires authorisation from the project board, not the project manager, who manages the stage but lacks the authority to approve its start. This option is tempting because the project manager is responsible for producing the initiation stage plan and requesting authorisation, so in a later stage, they would manage delivery once approval is granted.

Team Manager

Why it fails: The Team Manager manages delivery of products within a work package and reports progress to the Project Manager; authorising the initiation stage sits with the Project Board. Team Manager involvement is correct once work packages are being delivered, not at stage authorisation.

Continued business justification

Why it fails: While important, this principle does not specifically address how to manage frequent changes.

Focus on products

Why it fails: This principle ensures quality but does not directly address changing requirements.

Tailor to suit the project environment

Why it fails: Tailoring is a principle, but 'manage by stages' is the key to handling frequent changes.

Project Manager

Why it fails: The Project Manager does maintain and update the Business Case day to day, but accountability for it rests with the Executive, who owns the document and ensures it remains viable. The Project Manager's upkeep role makes this tempting, yet PRINCE2 assigns overall responsibility to the Executive.

Senior User

Why it fails: The Senior User specifies benefits and confirms they are realised, feeding benefit information into the Business Case, but does not own it. Accountability sits with the Executive, who represents the business interest and judges continued viability. The Senior User's benefits focus makes this option tempting.

Senior Supplier

Why it fails: The Senior Supplier represents those designing and delivering the products, providing supplier resource and feasibility information, but holds no accountability for the Business Case. That rests with the Executive. The role's involvement in stage planning and product delivery makes this option superficially attractive.

To initiate the project

Why it fails: Initiating a Project produces the Project Initiation Documentation and the baseline; Managing a Stage Boundary instead prepares the next Stage Plan, updates the Project Plan and reports exception or continuation to the board. It tempts because both processes occur at stage transitions and involve planning and approval activity.

To close the project

Why it fails: Closing a Project confirms acceptance, reviews benefits and hands over; Managing a Stage Boundary instead provides the board with information to assess continued viability and approve the next stage. It tempts because both are end-of-stage processes requiring board decisions, but only closure terminates the project.

To manage day-to-day activities

Why it fails: Managing day-to-day activities belongs to the Controlling a Stage process, which authorises work packages and monitors progress within a stage. Managing a Stage Boundary instead prepares the End Stage Report and Next Stage Plan for the project board. It is tempting because both processes involve the Project Manager acting during delivery stages.

Team Manager

Why it fails: The Team Manager manages product delivery for their team and reports progress to the Project Manager; assurance requires independence from the delivery line. It tempts because Team Managers do monitor work within their teams, but that oversight is internal, not the independent Project Assurance function.

Project Support

Why it fails: Project Support provides administrative services such as maintaining the project filing and configuration management, not independent assurance. It tempts because support staff often gather status data, yet Project Assurance is a distinct role reporting to the Project Board on the project's viability.

Project Manager

Why it fails: The Project Manager runs the project day to day, so cannot independently assure their own management; assurance must come from outside the delivery line. It tempts because the Project Manager does monitor and control, but that is management, not the independent Project Assurance role.

Manage by stages

Why it fails: Manage by stages is one of the seven PRINCE2 principles, so it cannot be the exception the question seeks. The stem asks which is NOT a principle, and this genuinely is one, covering stage division and board control points. It is tempting because stage-related processes exist separately, but the principle itself is legitimate.

Focus on products

Why it fails: Focus on products is a genuine PRINCE2 principle, defining outputs by their quality criteria before planning activities. Since the question asks which is NOT a principle, this option fails because it correctly belongs to the seven. It is tempting because product-based planning is also a technique, but the principle remains valid.

Continued business justification

Why it fails: Continued business justification is a genuine PRINCE2 principle, requiring a documented, reviewed business case throughout the project. The question asks which is NOT a principle, so this fails by being one of the seven. It is tempting because business case documentation is also a management product, but the principle stands.

Managing a Stage Boundary

Why it fails: Managing a Stage Boundary is a PRINCE2 process, not one of the seven practices (previously themes). It is tempting because it governs stage-end activities and appears alongside practice content, but the practices are Business Case, Organisation, Quality, Plans, Risk, Change and Progress.

Directing a Project

Why it fails: Directing a Project is a PRINCE2 process, not one of the seven practices (previously themes). It is tempting because it covers project board activity and sounds like a governance theme, but the practices are Business Case, Organisation, Quality, Plans, Risk, Change and Progress.

Starting Up a Project

Why it fails: Starting Up a Project is a PRINCE2 process, not a practice (theme); it covers the pre-project activities that precede the Initiating a Project process. It is tempting because it is a genuine PRINCE2 element, and would be correct if the question asked which processes exist rather than which practices.

Increased project duration

Why it fails: Increased project duration is a drawback, not a benefit; PRINCE2's controlled stages and defined tolerances typically reduce wasted effort and rework. It tempts because added governance can feel slower, but the framework's benefit is predictable delivery within agreed tolerances, not longer timelines.

Improved stakeholder management

Why it fails: While possible, it is not a direct benefit.

Providing day-to-day management of the project

Why it fails: Day-to-day management of the project belongs to the Project Manager, not the Project Board, which operates by exception and focuses on direction. It is tempting because board members do engage with progress, but their role is to authorise, assure and take key decisions rather than run daily delivery.

Assigning work packages to teams

Why it fails: Assigning work packages to teams is the Project Manager's responsibility when authorising work, not the Project Board's. It is tempting because the board approves stage plans and tolerances, but individual work package allocation sits with the Project Manager, while the board provides direction, assurance and decision-making.

To direct the work of the project team

Why it fails: Directing the project team's work belongs to the Directing a Project process, where the Project Board authorises each stage. Managing a Stage Boundary instead prepares the End Stage Report and Next Stage Plan for that authorisation. It is tempting because directing work sounds central to managing, but that activity sits above stage boundaries.

To capture lessons throughout the project

Why it fails: Capturing lessons is a continuing activity performed throughout every process, not a stage-boundary event. Managing a Stage Boundary produces the End Stage Report, Next Stage Plan and updated Business Case for the board's authorisation decision. The option tempts because lessons are reviewed at stage ends, but their capture is not this process's purpose.

To authorize the initiation of the project

Why it fails: Authorising project initiation occurs in Directing a Project, when the board approves the Project Initiation Documentation after the Initiating a Project process. Managing a Stage Boundary instead prepares the End Stage Report and Next Stage Plan so the board can authorise the next stage. The confusion arises because both involve board decisions.

Project Assurance

Why it fails: Project Assurance monitors and reports on the Business Case, checking it against tolerance; it does not author or update it. It tempts because assurance reviews Business Case viability and benefits, and Project Assurance would be the correct answer if the question asked who independently checks that the Business Case remains justified.

Senior User

Why it fails: The Senior User specifies and monitors benefits realisation but does not maintain the Business Case document. It tempts because the Senior User is accountable for benefits and represents user interests, and would be the correct answer if the question asked who is responsible for specifying and tracking the benefits the project delivers.

Project Brief

Why it fails: The Project Brief is the key input to Initiating a Project, produced during Starting up a Project; the key output is the Project Initiation Documentation. It is tempting because the Brief is central to initiation, but it precedes the process rather than resulting from it.

Stage Plan

Why it fails: A Stage Plan is produced during Managing a Stage Boundary for the next stage, not by Initiating a Project. It is tempting because initiation does create the first Stage Plan, but the key output of Initiating a Project is the Project Initiation Documentation.

Report in the next Highlight Report

Why it fails: A forecast breach of cost tolerance is a tolerance exception requiring immediate escalation to the Project Board, not deferred reporting in a Highlight Report. Highlight Reports are the correct vehicle for routine progress information within tolerance, which is why the option attracts, but they cannot substitute for exception reporting.

Increase the project budget

Why it fails: The Project Manager cannot unilaterally increase the budget; cost tolerance sits with the Project Board, which decides on the exception. Raising the budget is tempting because it appears to resolve the overspend directly, and would be valid only once the Board has approved a change to the Business Case and project budget.

Close the project

Why it fails: Closing the project is a Project Board decision taken only if the Business Case no longer justifies continuation; a forecast cost-tolerance breach alone does not warrant termination. It tempts because early closure is a legitimate response to a non-viable project, but the immediate requirement is escalation via an Exception Report.

A Request for Change is always approved; an Off-specification is always rejected

Why it fails: Approval or rejection is a decision taken by the change authority for either request; neither type carries an automatic outcome. The real axis is that a Request for Change proposes altering baselined products, while an Off-specification reports a product failing to meet its agreed specification. The option tempts by pairing the two with opposite verdicts.

An Off-specification is raised by the Project Board; a Request for Change is raised by the Project Manager

Why it fails: Both a Request for Change and an Off-specification may be raised by anyone, including team members, so the raiser is not the distinguishing axis. The genuine difference is that a Request for Change proposes modifying a baselined product, whereas an Off-specification reports a product that cannot meet its specification. The option tempts by inventing a role split.

They are the same thing

Why it fails: They are distinct issue types with different triggers: a Request for Change proposes altering a baselined product, while an Off-specification reports a product that cannot meet its agreed specification. Both are captured in the Issue Register and assessed by the change authority. The option tempts because both are issues, but their origins differ.

Raise an Issue to the Project Board

Why it fails: Raising an Issue to the Project Board is reserved for tolerances being threatened or exceeded, not routine product completion. It is tempting because Issues escalate exceptions, but here the Project Manager should record completion and check the product against its quality criteria before proceeding.

Update the Project Plan

Why it fails: The Project Plan is updated at stage boundaries, not on each completed product. It is tempting because plan progress feels relevant, but the immediate action is reviewing the completed product against its quality criteria and updating the Stage Plan, Work Package and product status.

Send a Highlight Report

Why it fails: Highlight Reports go to the Project Board at agreed intervals, not triggered by a single completed product. It is tempting because reporting progress seems natural, but the Project Manager must first check the product against its quality criteria and update the Stage Plan before any scheduled reporting.

Clear definition of roles and responsibilities

Why it fails: Clear definition of roles and responsibilities is a genuine PRINCE2 benefit, so it cannot be the exception. It tempts because the question asks for what is NOT a benefit, and this sounds like a governance overhead rather than an advantage, yet the defined roles are central to the method.

Focus on business justification

Why it fails: Focus on business justification is a core PRINCE2 principle and genuine benefit, so it fails as the exception. It tempts because the continued business justification principle could be mistaken for a constraint, but it is precisely the benefit the question excludes.

Improved stakeholder communication

Why it fails: Improved stakeholder communication is a real PRINCE2 benefit delivered through defined roles and management products, so it cannot be the exception. It tempts because communication is often seen as a soft extra, yet PRINCE2's organisation theme explicitly enables it.

Initiating a Project is done by the Project Board; Starting Up a Project is done by the Project Manager

Why it fails: Both processes are performed by the Project Manager, with the Project Board only authorising the Project Initiation Documentation at the end of Initiating a Project. It tempts because the Board does make key decisions at these gateways, and Board-level authorisation would be the correct answer if the question asked who approves the PID.

They are the same process

Why it fails: Starting Up a Project and Initiating a Project are distinct processes with different purposes, inputs and outputs. It tempts because both sit in the pre-delivery stage and involve the Project Manager, and treating them as one would be correct only if the question asked which processes occur before the delivery stage begins.

Starting Up a Project is about creating the PID; Initiating a Project is about creating the Project Brief

Why it fails: The outputs are reversed: Starting Up a Project produces the Project Brief, while Initiating a Project produces the PID. It tempts because both documents are pre-project baselines, and the stated mapping would be correct if the question asked which document initiates a project before the PID is authorised.