Hard Difficulty Questions

Start a new project to realize more benefits

Why wrong: Not relevant.

Delete the project files

Why wrong: Files must be archived, not deleted.

Close the project immediately

Why wrong: Closing requires verification and documentation.

Plans

Why wrong: This is a theme, not a principle.

Business Case

Why wrong: This is a management product, not a principle.

Reduce scope to lower costs

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

Seek alternative options to improve benefits

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

Recommend project cancellation

Why wrong: Too drastic; further analysis is needed.

They cover the entire project timeline

Why wrong: Stage Plans cover only one stage.

They replace the Project Plan

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

They are less detailed than the Project Plan

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

To reduce the workload of the Project Manager

Why wrong: While it may reduce workload, the main reason is independence.

To allow the Project Manager to focus on technical work

Why wrong: The PM focuses on management, not technical work.

To ensure that the Project Board is kept informed

Why wrong: That is a benefit, but not the primary reason.

Project Assurance is performed by the Project Manager; Project Support is performed by the Team Manager

Why wrong: The PM cannot assure themselves.

Project Assurance reviews products; Project Support reviews processes

Why wrong: Both can review products and processes but with different focus.

Project Assurance is optional; Project Support is mandatory

Why wrong: Both are optional roles.

There is no difference; they are synonymous

Why wrong: They serve distinct purposes in PRINCE2.

Project Assurance is a one-time activity, while quality reviews are continuous

Why wrong: Project Assurance is ongoing throughout the project; quality reviews are performed at specific points.

Project Assurance is performed by the Project Manager, while a quality review is performed by the team

Why wrong: Project Assurance is independent and cannot be delegated to the Project Manager.

Continued business justification

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

Tailor to suit the project environment

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

Learn from experience

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

Update the risk register with the resource and budget issues and proceed with the stage as planned.

Why wrong: Updating the risk register is not sufficient; the changes impact the viability of the project.

Proceed with the first delivery stage using the existing approved plans, but closely monitor resource usage.

Why wrong: This ignores the significant changes and could lead to failure.

Adjust the project plan and resource allocations to fit the new budget and proceed without further authorization.

Why wrong: Changes of this magnitude require project board approval.

Risk owners are responsible for the risk budget.

Why wrong: Risk owners manage the risk, but the risk budget is controlled by the project manager.

Risks are assessed only during the initiating a project process.

Why wrong: Risks are assessed throughout the project, not only during initiation.

Included the critical risks in the project plan

Why wrong: The project plan outlines timelines and costs, not risk communication.

Prepared a highlight report instead of a detailed risk report

Why wrong: Highlight reports are periodic summaries, not tailored for specific critical risks.

Updated the risk register and sent it to the board

Why wrong: The risk register is a log, not a communication tool; board members need tailored reporting.

Risk

Why wrong: Risk practice manages uncertainties, not quality.

Plans

Why wrong: Plans practice focuses on defining the project's stages and activities, not specifically on quality.

Change

Why wrong: Change practice manages change requests, not quality.

Defined roles and responsibilities

Why wrong: Roles might have been defined.

Continued business justification

Why wrong: The business case might still be valid.

Learn from experience

Why wrong: Lessons are not the primary concern.

Remove the criterion from the Project Product Description.

Why wrong: Removal should be a formal change control decision.

Ignore the issue because the criterion is already documented.

Why wrong: The issue needs to be addressed to avoid ambiguity.

Reclassify it as 'Must' to ensure delivery.

Why wrong: This should be agreed with the customer first.

Managing a Stage Boundary

Why wrong: SB produces the Exception Plan but the Board authorizes it in DP.

Controlling a Stage

Why wrong: CS is for the PM, not the Board.

Closing a Project

Why wrong: CP is for project closure, not exception plans.

End Stage Report

Why wrong: Produced in SB.

Project Initiation Documentation (PID)

Why wrong: Produced in IP.

There is no difference; they are synonyms

Why wrong: They are distinct concepts in PRINCE2.

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

Why wrong: Both can relate to any aspect of a product; schedule changes are not the sole focus of RFCs.

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

Why wrong: Both can be raised by various roles; the distinction is not about who raises them.

There is no difference; they are interchangeable terms

Why wrong: They are distinct concepts in PRINCE2's issue management.

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

Why wrong: Off-spec relates to product specifications, not schedule.

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

Why wrong: Both can be raised by any stakeholder; the source is not the defining difference.

It allows the Project Manager to approve all changes

Why wrong: The PM may advise but does not approve; the Change Authority is independent.

It eliminates the need for the Configuration Management process

Why wrong: Change Authority works within configuration management; it does not replace it.

It ensures all changes are approved by the Senior Supplier

Why wrong: The Change Authority can include representatives, but not exclusively supplier.

To reduce the overall cost of project management

Why wrong: Separation may increase costs, not reduce.

To speed up decision-making by the Project Board

Why wrong: Separate roles may slow decision-making due to additional reporting.