Plans Practice

According to PRINCE2 7, the Project Plan serves as a high-level business view of the entire project, maintained at a strategic level throughout the project lifecycle. It is specifically designed for executive-level decision making and portfolio management purposes.

The correct approach is to present the Project Plan as a high-level business view showing overall timescales, aggregate costs across stages, key milestone dates, and significant baseline changes. This aligns with several key PRINCE2 principles:

1. Purpose of the Project Plan: The Project Plan is intended to provide a macro-level view for strategic decision-making, not detailed operational control. It enables comparison across portfolio initiatives and supports resource allocation decisions at the organizational level.

2. Appropriate Level of Detail: For a strategic investment committee comparing multiple projects, the focus should be on overall viability, strategic alignment, and major milestones - not granular stage-level variances or operational details.

3. Management by Exception: The Executive and committee need to see significant baseline changes and overall project health, not the detailed management actions being taken within tolerance at stage level.

4. Separation of Concerns: PRINCE2 distinguishes between the Project Plan (strategic) and Stage Plans (tactical). The committee's need is strategic, so the Project Plan should remain at its intended level of abstraction.

The other approaches are incorrect because:

Enhancing the Project Plan with detailed Stage 2 variance reports and comprehensive risk analysis conflates the Project Plan with Stage Plan content. This level of detail is inappropriate for strategic portfolio comparison and would obscure the high-level view needed by the investment committee.

Incorporating detailed quality metrics, team performance indicators, and stage-by-stage variance trending attempts to serve both strategic and operational purposes simultaneously. This violates PRINCE2's principle of maintaining appropriate management levels and would create confusion about the project's strategic position.

Supplementing the presentation with Stage Plan details for current and upcoming stages mixes management levels inappropriately. While Stage Plans are essential for detailed control, presenting them alongside the Project Plan at a strategic committee meeting introduces unnecessary complexity and shifts focus from portfolio-level decision making to operational details that should be managed by the Project Manager within delegated authority.

The Project Plan should remain fit for its intended purpose: providing a consistent, high-level business view that enables strategic comparison and decision-making across the organizational portfolio.

In PRINCE2 7's product-based planning approach, external products are items required by the project but produced outside the project's scope and control. The telecommunications license renewal perfectly fits this definition because:

1. It is required for project delivery (the network infrastructure cannot legally operate in three regions without valid licenses)
2. It is produced by an external authority (government regulatory body)
3. The project has no control over the approval process or timeline
4. The project can only influence it by submitting applications and providing required documentation

The correct approach is to document it as an external product in relevant Product Descriptions (likely for the regional network implementations in those three regions). The Product Description should:
- Identify it as an external dependency
- Specify acceptance criteria focusing on evidence of license validity (not the license creation process itself)
- Note any required formats or documentation standards
- Include quality criteria related to validity period and coverage scope

This treatment allows the project to:
- Track the dependency appropriately
- Plan around potential delays
- Define clear acceptance criteria
- Maintain realistic expectations about control

The other approaches are incorrect because:

Treating it as a management product misclassifies its nature - management products are created to manage and control the project (like plans, reports, registers). While compliance monitoring might be a management activity, the license itself is not a project management artifact; it's an operational/regulatory requirement external to the project.

Creating it as a specialist product with full Product Description including detailed format and derivation implies the project team will produce it, which contradicts reality. Specialist products are created by the project team using specialized skills. The project cannot create a government license; only the regulatory authority can issue it.

Placing it in a separate 'Regulatory Products' branch with comprehensive composition details suggests the project has control over its creation and can break it down into manageable components. This overstates the project's control and creates unnecessary documentation for something the project cannot directly produce. External products should be identified where they're needed (in the Product Descriptions of products that depend on them) rather than given elaborate breakdown structures the project cannot influence.

The correct action is to close the current Work Package, raise an Exception Report to the Project Board, and await direction before authorizing a revised Work Package.

This is correct because:

1. Exception Management: The 15% cost increase likely exceeds the Project Manager's cost tolerance, requiring Project Board involvement through an Exception Report as per PRINCE2's exception management process.

2. Work Package Closure: The current Work Package cannot be delivered as specified due to incompatible infrastructure. It should be formally closed rather than amended mid-execution.

3. Project Board Authority: Significant cost increases and specification changes (different sensors and calibration procedures) require Project Board approval before proceeding, as these may impact business case viability.

4. Proper Sequencing: The Project Manager must obtain authorization before committing to the additional expenditure and revised approach.

Why the other answers are incorrect:

Authorizing the Team Manager to proceed immediately and updating documentation retrospectively violates PRINCE2's principle of managing by exception. The Project Manager would be exceeding their authority by approving a 15% cost increase without escalation, and retrospective updates undermine proper controls.

Closing the Work Package and creating a revised one while only reporting to the Project Board in the next Highlight Report is inappropriate because the cost variance likely exceeds tolerance and requires immediate escalation via Exception Report, not routine reporting. The Project Manager would be committing resources beyond their authority.

Requesting an impact analysis and amending existing tolerances assumes the Project Manager has authority to absorb these changes, which is unlikely given the 15% cost increase and significant specification changes. Tolerances cannot simply be amended by the Project Manager when they're being exceeded - this requires Project Board intervention through exception management.