Managing a Stage Boundary Process

In PRINCE2 7, when a Stage Plan forecasts exceeding project-level tolerances, the Project Manager must escalate to the Project Board via an Exception Report and cannot proceed with changes until authorization is received.

The correct approach follows this sequence:
1. The Project Manager has correctly prepared an Exception Report (already done)
2. An Exception Plan must be created showing how the exception will be handled
3. The Project Board must review and authorize the Exception Plan
4. Only after authorization can the Project Plan be updated with the new baseline
5. The approved changes are then incorporated into the Project Plan with updated forecasts

This respects the fundamental PRINCE2 principle of 'managing by exception' - the Project Manager operates within delegated tolerances but must seek authorization when forecasting a breach of project-level tolerances.

Why the other answers are incorrect:

Revising the Project Plan and presenting updates to the Project Board reverses the correct sequence. The Project Board must approve the Exception Plan BEFORE the Project Plan baseline is changed. The Project Plan represents the authorized baseline, and changing it without prior approval violates PRINCE2 governance.

Updating the Stage Plan first is incorrect because the stage-level changes are already known and documented. The issue is that these changes will cause project-level tolerance breaches. Waiting for stage tolerances to be 'formally exceeded' misunderstands the process - the forecast breach triggers the exception, not the actual breach. Stage Plan updates alone don't address the project-level governance requirement.

Incorporating Exception Report findings directly into the Project Plan and then seeking approval puts the cart before the horse. The Exception Report identifies the problem, but the Exception Plan (which must be approved first) defines the solution. Making detailed downstream adjustments before authorization wastes effort and assumes approval, which violates the 'manage by exception' principle and the Project Board's decision-making authority.

The primary purpose of the Exception Assessment conducted by the Project Board when a stage is forecast to exceed its tolerances is to determine whether the project remains viable and decide on appropriate corrective actions or project closure.

In PRINCE2 7, when tolerances are forecast to be exceeded, the Project Manager must escalate this as an exception to the Project Board through an Exception Report. The Project Board then conducts an Exception Assessment to evaluate the situation and make a decision about how to proceed.

The key focus of this assessment is on project viability and deciding the appropriate course of action. The Board needs to determine:
- Whether the project is still justified given the forecast deviation
- What corrective actions should be taken
- Whether to authorize an Exception Plan to recover the situation
- Whether the project should continue or be closed

This assessment is fundamentally about governance and decision-making at the Project Board level regarding the project's future direction.

Why the other answers are incorrect:

The option about evaluating stage deliverables and quality criteria is not the primary purpose of an Exception Assessment. Quality evaluation is an ongoing activity throughout the stage and is part of quality management activities, not specifically the focus when tolerances are exceeded.

The option regarding the Project Manager's authority and delegation is not relevant to Exception Assessment. The Project Manager's authority is established through Work Packages and stage authorization, not reassessed during exception handling.

The option about corporate risk appetite and revised tolerance thresholds misses the main point. While risk may be considered, the Exception Assessment is primarily about determining viability and deciding on corrective actions for the current situation, not about resetting tolerances for future stages.

The PRIMARY concern for the Project Board when deciding on Stage 4 authorization must focus on the most critical threat to project success and business case viability.

The correct answer addresses the cumulative timeline impact combined with the critical procurement dependency. This is the primary concern because:

1. The project has already incurred a 2-week delay in Stage 3 (exceeding the +1 week tolerance)
2. Stage 4 requires vendor equipment with a 16-week lead time
3. Procurement hasn't started yet, creating an immediate critical path issue
4. There are contracted go-live dates with major business customers at stake
5. This directly threatens the business case benefits realization

In PRINCE2 7, the End Stage Report must enable the Project Board to make informed decisions about project continuation. When a stage is completed outside tolerance and the next stage faces critical dependencies, the Project Board needs to understand the cumulative impact on the project's viability and ability to deliver contracted commitments.

The other options, while relevant, are not the PRIMARY concern:

The Exception Plan performance analysis is important for assurance and learning, but it addresses past management rather than the immediate critical forward-looking issue that could jeopardize the entire project timeline and customer commitments.

Technical quality achievements and compliance, while positive, don't address the pressing scheduling crisis. Quality success doesn't mitigate the timeline risks that threaten contracted delivery dates and business case realization.

Detailed geological analysis and lessons learned are valuable for project learning and future risk management, but they focus on retrospective analysis rather than the immediate decision point facing the Project Board regarding a critical procurement delay that could cascade into project failure.

The Project Board's authorization decision must prioritize information about threats to the project's fundamental viability and ability to deliver contracted business benefits.