Project Initiation and Stages practice questions

Replace the team members with experienced ones

Why it fails: This is a drastic action; the PM should first assess and plan.

Escalate to the Project Board for decision

Why it fails: Escalation may be needed later, but initially the PM should log the risk.

Update the Project Plan to include training

Why it fails: Training is a possible response, but first the risk must be documented.

Reduce scope to lower costs

Why it fails: Scope changes require Board approval and may not be necessary.

Seek alternative options to improve benefits

Why it fails: May be valid, but the immediate action is to provide justification.

Recommend project cancellation

Why it fails: Too drastic; further analysis is needed.

Ignore the assumption

Why it fails: Ignoring would lead to flawed decision-making.

Stop the project

Why it fails: Too premature; the impact may be manageable.

Inform the Project Board

Why it fails: Informing is important, but updating first provides accurate information.

Close the project

Why it fails: Closing is the final stage.

Deliver the project product

Why it fails: Delivery occurs in subsequent stages.

They cover the entire project timeline

Why it fails: Stage Plans cover only one stage.

They replace the Project Plan

Why it fails: The Project Plan remains; Stage Plans are complementary.

They are less detailed than the Project Plan

Why it fails: Stage Plans are more detailed than the Project Plan.

Project Initiation Documentation

Why it fails: PID is an output, not input.

End Project Report

Why it fails: This is from the final stage.

Proceed with the current Business Case as the board is eager

Why it fails: Ignoring risks is not prudent; the board needs full information.

Escalate to the programme manager without updating the Business Case

Why it fails: The PM should first assess and update the Business Case.

Recommend cancelling the project due to poor viability

Why it fails: Too premature; the risk-adjusted case may still be acceptable.

Proceed with the plan as the supplier has always delivered eventually

Why it fails: Past eventual delivery does not remove the risk of missing a fixed date; PRINCE2 requires the threat to be identified, assessed and recorded in the Risk Register, with contingency reflected in the Business Case and plan. It is tempting because historical delivery suggests reliability, but the fixed date makes the delay risk material to the business justification.

Adjust the business case to remove the supplier dependency

Why it fails: Removing the dependency alters the business case to fit the plan, inverting PRINCE2's logic that the plan should satisfy the business justification. The risk should instead be recorded and evaluated in the Business Case and Risk Register. It is tempting because eliminating a threat appears decisive, but the business case is the project's justification, not a variable to be edited away.

Ask the project board to approve the project with a note about the risk

Why it fails: Escalating the risk for approval is premature during Initiating a Project; the project manager should first assess and document it in the Risk Register and Business Case, then include it in the Project Initiation Documentation for board decision. It is tempting because boards do approve projects, but approval follows analysis, not a bare note.

Report Highlights, then Authorize Work Packages, then Review Work Package Status, then Receive Completed Work Packages, then Review Stage Status, then Capture and Examine Issues and Risks, then Take Corrective Action, then Escalate Issues and Risks (if needed)

Why it fails: This is incorrect because reporting highlights should occur after reviewing stage status, not before authorizing work.

Take Corrective Action, then Authorize Work Packages, then Review Work Package Status, then Receive Completed Work Packages, then Review Stage Status, then Report Highlights, then Capture and Examine Issues and Risks, then Escalate Issues and Risks (if needed)

Why it fails: This is incorrect because corrective action must be based on identified issues and risks, which come after reviewing status and capturing issues.

Escalate Issues and Risks (if needed), then Authorize Work Packages, then Review Work Package Status, then Receive Completed Work Packages, then Review Stage Status, then Report Highlights, then Capture and Examine Issues and Risks, then Take Corrective Action

Why it fails: This is incorrect because escalation is a last resort after attempting corrective action, not the first step.

Starting Up a Project: To establish a solid foundation for the project, enabling the project board to decide on committing to the project.

Why it fails: Incorrect — this describes the purpose of Initiating a Project, not Starting Up a Project.

Initiating a Project: To ensure that the prerequisites for initiating a project are in place.

Why it fails: Incorrect — this describes the purpose of Starting Up a Project, not Initiating a Project.

Quality tolerances

Why it fails: Quality tolerances are part of the project controls section of the PID, not the quality management approach. They define the allowable deviation from the quality requirements before escalation is needed. While they are related to quality, they are not a component of the quality management approach itself, making this an incorrect choice.

Quality register format

Why it fails: The quality register is a separate management product that records quality activities. The quality management approach may reference it, but it does not include the format of the quality register. The format is defined in the quality register itself. Therefore, this is not a correct element to include in the quality management approach.

Quality assurance team

Why it fails: While a quality assurance team may exist, the quality management approach does not require a specific team to be named. Instead, it defines the roles and responsibilities for quality assurance, which may be assigned to existing roles. Naming a separate team is not a required element, making this option incorrect.

The PID must contain the Project Board's terms of reference.

Why it fails: While the PID defines roles and responsibilities, including those of the project board, a separate 'terms of reference' document is not a minimum requirement. The PID includes the project management team structure and role descriptions, but not necessarily a formal terms of reference. The focus is on the project definition, plans, and business case.

The PID must contain the End Stage Report.

Why it fails: The End Stage Report is produced at the end of a stage, not during Initiation. It summarizes performance and is used by the project board to decide whether to proceed. The PID is created during Initiation and does not include End Stage Reports, which are outputs of the Managing a Stage Boundary process. Therefore, this is not a minimum requirement for the PID.

The PID must contain the Project Brief as issued.

Why it fails: The Project Brief is an input to the Initiation Stage, not a required component of the PID. The PID is a consolidation of information that supersedes the Project Brief. While the Project Brief informs the PID, it is not included as a standalone document. The PID contains updated and expanded information, such as the detailed Business Case and the project plan.

Project Controls

Why it fails: Project Controls describe how the project will be monitored and controlled, including reporting and escalation. They do not include product descriptions or quality criteria. Therefore this option is incorrect because it focuses on governance mechanisms, not product specifications.

Quality Management Strategy

Why it fails: The Quality Management Strategy defines the quality approach, such as quality control measures and acceptance criteria. It does not list individual products and their quality criteria; that is done in the Project Plan's product descriptions. This option is wrong because it describes the overall quality approach, not the specific product details.

Business Case

Why it fails: The Business Case provides the justification for the project, including expected benefits, costs, and risks. It does not contain product descriptions or quality criteria. Those are part of the Project Plan. Thus this option is incorrect because it addresses the business rationale, not the products.

Request the Project Board to approve a change to the Project Plan through the Change Authority, because all plan changes require Board approval.

Why it fails: During Initiation, the Project Plan is still a draft and has not yet been baselined. Changes to a draft plan do not require formal change control through the Change Authority. The Project Manager should update the draft plan and Business Case, then raise an issue if the change affects the project's viability or tolerances. Formal change control applies after baselining.

Log the supplier's delivery change in the Risk Register and continue with the existing Project Plan, because the project is still in Initiation and no baseline has been approved.

Why it fails: Although the supplier's change is a risk, simply logging it and continuing with the unadjusted Project Plan would leave the plan inaccurate and the Business Case potentially invalid. The Project Manager must update the affected baselines and inform the Board. Logging the risk alone does not address the impact on timescales, costs, or viability.

Immediately escalate to the Project Board by raising an exception report, because the supplier delay exceeds stage tolerances.

Why it fails: An exception report is only produced when a stage or project is forecast to exceed its tolerances. At this point, the Project Manager has not yet assessed the impact against tolerances; the Initiation Stage may still be within its own tolerances. The correct first step is to assess and update the plans, then escalate only if tolerances are threatened or breached.

Benefits Review Plan

Why it fails: The Benefits Review Plan is not part of the PID. In PRINCE2, the Benefits Management Approach is included in the PID. The Benefits Review Plan is a different management product used in some contexts, but it is not a standard component of the PID as defined by PRINCE2.

Project Board's Terms of Reference

Why it fails: The Project Board's Terms of Reference are not a component of the PID. The PID includes the project management team structure and role descriptions, but the detailed terms of reference for the board are typically covered in the project's organization documentation, not the PID.

Stage Plan for the Initiation Stage

Why it fails: The Stage Plan for the Initiation Stage is not part of the PID. The Initiation Stage is managed using a Stage Plan that is created during Starting Up a Project. The PID is produced as a result of the Initiation Stage, but the plan for that stage itself is not included in the PID.

The Communication Management Approach

Why it fails: The Communication Management Approach specifies how information will be exchanged among stakeholders. It is part of the PID but concerns communication planning, not how PRINCE2 is adapted. It would not answer the Board's question about method tailoring, making it an incorrect choice.

The Quality Management Approach

Why it fails: The Quality Management Approach defines the project's quality standards, procedures, and responsibilities. It is a PID component but addresses quality control and assurance, not the tailoring of PRINCE2 principles, themes, and processes to the project context, so it is not the right document here.

The Project Plan

Why it fails: The Project Plan describes the project's products, activities, resources, and schedule at a high level. While it is part of the PID, it does not explain how PRINCE2 itself is tailored; it focuses on delivery planning, not method adaptation, so it would not satisfy the Board's request.

To document the justification for the project, including costs, benefits, and risks.

Why it fails: Documenting the justification for the project, including costs, benefits, and risks, is the purpose of the Business Case. The Business Case is a component of the Project Initiation Documentation, but it is not an approach. Approaches define how the project will operate in specific areas, whereas the Business Case provides the rationale for undertaking the project.

To define the roles and responsibilities of the Project Board, Project Manager, and Team Manager.

Why it fails: Roles and responsibilities for the Project Board, Project Manager, and Team Manager are defined in the project's organisation structure and role descriptions, not in an approach. The Organisation theme covers the project management team structure. Approaches, such as the Risk Management Approach, describe how specific management areas will be handled, not who fills which roles.

To provide a detailed schedule of activities, resources, and costs for the next stage of the project.

Why it fails: A detailed schedule of activities, resources, and costs for the next stage is the purpose of a Stage Plan, not an approach. Approaches describe how specific aspects of the project will be managed, such as risk, change, quality, and communication. The Stage Plan is a separate management product that provides the basis for day-to-day control of a stage.

End Stage Report

Why it fails: The End Stage Report is produced at the end of each management stage, including the Initiation Stage, to summarise performance and provide information for the next stage. However, it is not the document that authorises the project; the PID is the primary product for that decision. The End Stage Report is an input to the PID review.

Benefits Review Plan

Why it fails: The Benefits Review Plan describes how and when the project's benefits will be measured and reviewed. It is part of the PID, but it is not the overall document that the Project Board approves to authorise the project. The PID as a whole is the required product.

Stage Plan

Why it fails: A Stage Plan is produced for each management stage, including the next stage after initiation. It details how the stage will be executed. While a Stage Plan for the first delivery stage is often included in the PID, the PID itself is the overarching document that must be approved to authorise the project.

Executive

Why it fails: The Executive is responsible for the overall success of the project and represents the business interests. While they ensure the Business Case is viable, the specific responsibility for benefits realization lies with the Senior User. The Executive focuses on the business justification and strategic alignment, not the day-to-day benefits delivery.

Project Manager

Why it fails: The Project Manager is responsible for the day-to-day management of the project, including planning, monitoring, and controlling. They do not own the benefits; that responsibility belongs to the Senior User. The Project Manager ensures the project delivers the products to the required quality, but benefits realization is a user responsibility.

Senior Supplier

Why it fails: The Senior Supplier represents the interests of those designing, developing, and implementing the project's products. They are responsible for the technical integrity of the project and ensuring resources are available. They do not have responsibility for benefits realization, which is the domain of the Senior User.

Review the risk management approach from a previous similar project and adopt it without changes.

Why it fails: While reviewing lessons from previous projects is valuable, adopting an approach without changes ignores the need to tailor to the current project's complexity and context. The Board specifically requested alignment with this project's complexity, so the Project Manager must adapt the approach, not simply reuse it. This action would not meet the Board's requirements.

Create the Risk Register and populate it with all known risks.

Why it fails: Creating the Risk Register is a separate activity that occurs after the Risk Management Approach is defined. While the register is a key product, it is not part of developing the approach itself. The approach describes how the register will be used, but the register's creation is not one of the activities to develop the approach. The Board's request focuses on the approach, not the register.

Assign the Senior User as the risk owner for all project risks.

Why it fails: Assigning a single individual as the risk owner for all risks is not practical or aligned with PRINCE2 principles. Risk owners should be assigned based on the specific risk and the appropriate level of authority. The Risk Management Approach defines roles and responsibilities for risk management, but it does not mandate that the Senior User owns all risks. This action would not effectively tailor the approach.