Business Case and Organizing practice questions

Update the Business Case without informing the board

Why it fails: The board must be informed and approve changes.

Reduce project scope to cut costs

Why it fails: Scope changes need board approval.

Stop the project immediately

Why it fails: The project manager must escalate, not stop unilaterally.

Senior User

Why it fails: The senior user cannot substitute for the executive.

Senior Supplier

Why it fails: The senior supplier cannot substitute for the executive.

Project Assurance

Why it fails: Project assurance is an independent role, not a substitute.

Start a new project to realize more benefits

Why it fails: Not relevant.

Delete the project files

Why it fails: Files must be archived, not deleted.

Close the project immediately

Why it fails: Closing requires verification and documentation.

Project Manager

Why it fails: Project manager manages the project, not benefits.

Senior Supplier

Why it fails: Supplier provides resources, not benefits.

Executive

Why it fails: Executive owns the business case but not specifically benefits delivery.

Project Plan

Why it fails: The Project Plan is created in Initiating a Project.

End Project Report

Why it fails: The End Project Report is created in Closing a Project.

Risk Register

Why it fails: The Risk Register is created in Initiating a Project.

Escalate to the senior supplier immediately

Why it fails: The issue is with the executive; the senior supplier may not be the right first step.

Ignore the executive's instructions and continue with the project plan

Why it fails: Ignoring the executive may create conflict and is not appropriate.

Issue a change request to update the project plan to include the executive's instructions

Why it fails: This would formalize the bypassing, which is not the correct approach.

Business Case: To define the project's structure of accountability and responsibilities.

Why it fails: Incorrect — this describes the Organization theme, not Business Case.

Quality: To identify, assess, and control uncertainty.

Why it fails: Incorrect — this describes the Risk theme, not Quality.

Benefits Management Approach

Why it fails: The Benefits Management Approach defines how benefits will be measured and realized, but it does not contain tolerances. Tolerances are set in the Business Case. Updating the Benefits Management Approach would not address the project board's request to revise the benefits tolerance.

Stage Plan

Why it fails: The Stage Plan details the work for the upcoming stage, including products, activities, and resources. It does not contain benefits tolerances. The benefits tolerance is a project-level parameter recorded in the Business Case, not in a Stage Plan.

Project Plan

Why it fails: The Project Plan outlines the schedule, resources, and activities, but it does not include benefits tolerances. While changes to benefits tolerance may impact the plan, the tolerance itself is documented in the Business Case. Updating the Project Plan alone would not satisfy the project board's request.

The Project Manager is a member of the Project Board and votes on stage authorization decisions.

Why it fails: The Project Manager is not a member of the Project Board. This role manages the project on a day-to-day basis, prepares the information the board needs, and implements the board's decisions, but does not vote on authorizing stages or committing board-level resources.

Project Assurance is accountable to the Senior Supplier and reports to the supplier organization.

Why it fails: Project Assurance is a responsibility of the Project Board as a whole, not of the Senior Supplier alone. Each board member may delegate assurance activities, but the accountability remains with the board, and assurance reports to the board rather than to the supplier.

The Team Manager is accountable for the overall Business Case and for authorizing the project's closure.

Why it fails: The Team Manager is responsible for managing a team to produce specified products within agreed tolerances. The Business Case accountability and authority to authorize closure belong to the Executive and the Project Board, not to the Team Manager.

The Executive

Why it fails: The Executive is the chair of the Project Board and is ultimately accountable for the project's business case, but the decision to continue, change, or stop the project is made by the Project Board as a whole, not by the Executive alone. The Executive would lead the discussion and ensure the Board makes an informed decision, but cannot unilaterally decide without Board agreement.

The Senior User

Why it fails: The Senior User represents the interests of those who will use the project's products and is responsible for specifying benefits and ensuring they are realized. However, the Senior User alone does not have the authority to stop or continue the project; that is a collective decision of the Project Board. The Senior User would raise concerns and provide input, but the decision is made by the Board.

The Project Manager

Why it fails: The Project Manager is responsible for day-to-day management and for preparing the updated business case, but does not have the authority to make the ultimate decision on project continuation. That decision rests with the Project Board, which represents the business, user, and supplier interests. The Project Manager would escalate the issue and provide recommendations, but cannot approve a major change to the project's justification.

Update the Business Case to reflect the new market conditions and continue with the stage

Why it fails: Updating the Business Case is necessary, but it should not be done without first assessing the impact and obtaining approval. The project manager cannot unilaterally change the Business Case; it requires project board approval. Continuing without approval could lead to misalignment with business objectives. The first step is to evaluate the situation and escalate if needed.

Ask the senior user to provide a revised benefits realization plan before taking any action

Why it fails: While a revised plan may be needed, it is not the first action. The project manager should first escalate the issue to the project board, as it may constitute an exception. The board may decide to request a revised plan or take other action. Asking the senior user to act alone bypasses the governance structure and delays necessary decisions.

Ignore the concern because the project has already been approved and the stage is ending

Why it fails: Ignoring the concern is not acceptable. PRINCE2 requires continuous business justification. If benefits are no longer achievable, the project may no longer be viable. The project manager must act on such information. Failing to escalate could lead to wasted resources and project failure. The board needs to be informed to make a decision.

Chairing the Project Board

Why it fails: The Executive is responsible for chairing the Project Board and cannot delegate this to the Project Manager. Chairing the board is a key part of the Executive's accountability and ensures that the board operates effectively. Delegating it would compromise the governance structure.

Ensuring the project delivers the expected benefits

Why it fails: The Executive is ultimately accountable for ensuring that the project delivers the expected benefits. While the Project Manager may manage day-to-day activities that contribute to benefits, the accountability for benefits realization cannot be delegated. It remains with the Executive, who represents the business interests.

Approving the Project Initiation Documentation

Why it fails: Approving the PID is a Project Board decision, and the Executive cannot delegate this to the Project Manager. The Executive may chair the board and influence the decision, but the approval itself requires collective board agreement. Delegating this would undermine the governance structure.

Appoint multiple Senior Suppliers to represent each external supplier.

Why it fails: PRINCE2 requires only one person to be appointed to each project board role. Appointing multiple Senior Suppliers would violate this principle and could lead to unclear accountability. The Senior Supplier role can be supported by other supplier representatives, but only one person holds the role.

Delegate the Senior Supplier role to the Senior User.

Why it fails: The Senior User represents the user community and is concerned with benefits realization. The Senior Supplier represents the supplier community and is concerned with providing resources and technical expertise. These are distinct interests, and combining them would undermine the balanced representation on the project board.

Assign the Senior Supplier responsibilities to the Project Manager.

Why it fails: The Project Manager cannot hold a project board role because it would compromise the separation of duties. The Project Manager is responsible for day-to-day management, while the Senior Supplier provides supplier perspective and ensures resources are available. Combining these roles would create a conflict of interest.

Managing the project on a day-to-day basis

Why it fails: Managing the project on a day-to-day basis is the responsibility of the Project Manager, not the Executive. The Executive provides direction and makes key decisions but does not manage the project on a daily basis. The Project Manager handles the day-to-day operations, while the Executive focuses on the overall business justification and strategic alignment.

Ensuring that the project delivers the expected benefits

Why it fails: Ensuring that the project delivers the expected benefits is a shared responsibility among the project board, particularly the Senior User and the Executive. However, the Executive is ultimately accountable for the Business Case, which includes benefits. But the specific responsibility for benefits realization is often assigned to the Senior User. In PRINCE2, the Executive is accountable for the Business Case, but the day-to-day ensuring of benefits delivery is typically the Senior User's role.

Chairing the project board meetings

Why it fails: While the Executive often chairs project board meetings, this is not a core responsibility defined in PRINCE2. The Executive may delegate the chairing to another member, but the accountability for the project remains with the Executive. The PRINCE2 manual does not explicitly state that the Executive must chair meetings; it is a common practice but not a defined responsibility.

Team Manager

Why it fails: The Team Manager is responsible for managing a team to produce the products assigned by the Project Manager. While they ensure that products meet quality criteria, their responsibility is limited to their specific work package. The overall responsibility for ensuring the project delivers all required products to quality criteria lies with the Project Manager, who coordinates across all teams and work packages.

Project Assurance

Why it fails: Project Assurance is responsible for monitoring all aspects of the project's performance and products independently of the Project Manager. It provides confidence to the Project Board that the project is being managed properly. However, it does not have direct responsibility for producing products to quality criteria; that is the responsibility of the Project Manager and the team. Project Assurance would review and report on quality activities.

Senior Supplier

Why it fails: The Senior Supplier represents the interests of the suppliers and is accountable for the quality of products delivered by the supplier teams. However, they do not have overall responsibility for ensuring the project meets all quality criteria; that is the Project Manager's role. The Senior Supplier provides resources and expertise but does not manage the project's quality activities on a day-to-day basis.

Assuring that the project's approach to quality is appropriate

Why it fails: Quality assurance is typically provided through project assurance, which reports to the project board but is not itself a board role. The board receives assurance and makes decisions, but the responsibility for checking that quality methods are appropriate sits with assurance roles. This is distinct from the three core project board responsibilities of business, user, and supplier interests.

Representing the interests of the supplier delivering the products

Why it fails: The Senior Supplier role represents the interests of those designing, developing, and delivering the project's products. While this is a legitimate project board role, the question asks for responsibilities that must be covered. Supplier representation may be provided by more than one person and its specific responsibility is supplier performance, not one of the two essential accountabilities listed in the correct answers. Care is needed to distinguish board roles from the mandatory responsibilities being asked about.

Managing the day-to-day delivery of the project's products

Why it fails: Day-to-day management of product delivery is the responsibility of the project manager, supported by team managers where used. The project board focuses on direction and decision-making at key points, not operational delivery. Including this as a board responsibility would confuse the board's governance role with the project manager's management role.

The Senior User represents the interests of the suppliers who are building the project's products.

Why it fails: Representing the suppliers is the responsibility of the Senior Supplier role, not the Senior User. The Senior User represents the users who will use the mobile app and ensures their needs are met. The Senior Supplier focuses on the technical delivery and resource availability. Confusing these roles can lead to misalignment between user needs and technical solutions.

The Senior User has the authority to approve changes to the project's technical architecture.

Why it fails: Approving changes to the technical architecture is typically the responsibility of the Senior Supplier, who ensures technical integrity. The Senior User focuses on user needs and benefits, not technical decisions. In this mobile app project, the Senior User would not approve architectural changes unless they impact user requirements, which would be handled through change control with appropriate roles.

The Senior User is accountable for the overall viability of the project's Business Case.

Why it fails: Accountability for the overall viability of the Business Case lies with the Executive, not the Senior User. The Senior User contributes to the Business Case by defining benefits and ensuring they are realized, but the Executive owns the Business Case and is responsible for its ongoing viability. This distinction is important to avoid confusion over ultimate accountability.

The Project Board can delegate approval of the Business Case to the Project Manager to speed up decision-making.

Why it fails: The Business Case is a key governance document that must be approved by the Project Board, specifically the Executive. Delegating its approval to the Project Manager would undermine the accountability framework. While the Project Manager may draft and maintain the Business Case, approval and ongoing ownership remain with the Executive and the Board, so this statement is incorrect.

The Senior Supplier represents the business interests and is accountable for the benefits realised from the project.

Why it fails: The Senior Supplier represents the interests of those designing, developing and implementing the project's products. The role is focused on supplier resources and technical feasibility, not on business benefits. Accountability for benefits realisation ultimately lies with the Executive and the business, so this statement confuses the Senior Supplier's remit with that of the business roles.

The Senior User is responsible for ensuring that the project delivers the outcomes and benefits defined in the Business Case.

Why it fails: The Senior User is responsible for specifying the needs of users and for monitoring that the solution will meet those needs and deliver the expected benefits. However, accountability for the Business Case itself rests with the Executive. The Senior User contributes to benefits definition and realisation but does not own the Business Case, so this statement misassigns accountability.

The Quality Management Strategy, because it describes the quality techniques, standards and responsibilities used to verify products.

Why it fails: The Quality Management Strategy defines the quality approach, standards and responsibilities, and it does support product acceptance. But it does not establish how the Business Case will be demonstrated as valid throughout the project. The question requires a single element that addresses both product acceptance and Business Case validity, so the Quality Management Strategy is only part of the picture.

The Benefits Review Plan, because it specifies when and how the project's benefits will be measured and reviewed after closure.

Why it fails: The Benefits Review Plan defines the measurement of benefits after the project, which supports the Business Case's continued validity. It does not, however, set out the acceptance criteria for the project's products or the quality methods used during delivery. The question asks for the element covering both product acceptability and Business Case validity, which is broader than benefits measurement alone.

The Project Plan, because it defines the timeline, cost and resource baseline against which the Business Case is monitored.

Why it fails: The Project Plan does provide the baseline against which progress and cost are tracked, supporting the ongoing review of the Business Case. However, it does not define product acceptance criteria or the mechanisms for verifying that benefits remain achievable. Those quality and justification aspects belong to other components of the Project Initiation Documentation, so the Project Plan alone is not the answer.

The Next Stage Plan

Why it fails: The Next Stage Plan is an output of Managing a Stage Boundary. It is not an input to updating the Business Case. The Business Case is updated before the Next Stage Plan is approved. However, the Business Case update may inform the Next Stage Plan. The key inputs are the End Stage Report and the current Business Case.

The End Stage Report

Why it fails: The End Stage Report is an output of Managing a Stage Boundary, not an input to updating the Business Case. It summarizes stage performance and is used by the board to decide on the next stage. While it may contain information relevant to the Business Case, it is not a direct input. The Business Case is updated using other documents.

The Business Case itself from the previous stage

Why it fails: The previous Business Case is a baseline, but it is not an input for updating; it is the document being updated. The update requires new information from the stage. Inputs include the End Stage Report and Next Stage Plan. The existing Business Case provides the starting point, but the update is driven by current performance and changes.