Directing a Project Process

In PRINCE2 7, the 'Authorizing Initiation' activity occurs at the end of the Starting Up a Project process when the Executive reviews the submission to decide whether to authorize the Initiation Stage.

The PRIMARY evaluation criterion at this authorization point should focus on whether the proposed Stage Plan for initiation represents appropriate activities and reasonable investment to develop the comprehensive Project Initiation Documentation needed for the subsequent 'Authorizing the Project' decision.

At this stage:
- The Executive is NOT making a full project authorization decision
- The Executive is evaluating whether to invest in developing more detailed documentation
- The initiation stage is specifically designed to refine initial products into mature baseline documents
- The key question is: 'Does this initiation plan represent good value to develop what we need for the next decision point?'

The correct answer appropriately focuses on evaluating whether the 10-week, £126,000 initiation Stage Plan contains the right activities (developing PID, refining Business Case, creating management approaches, establishing quality frameworks, defining governance) and represents reasonable investment to produce the documentation needed for Edward's subsequent authorization decision.

The other options are incorrect because:

The Daily Log concern misunderstands the authorization context. While Daily Logs are indeed personal working notes not formal baseline documents, this is not the PRIMARY criterion for authorizing initiation. The Daily Log's presence doesn't prevent authorization if the Stage Plan is sound. This represents a distraction from the main authorization question.

The Business Case evaluation focuses on detailed financial justification that is premature at this stage. The outline Business Case provides sufficient direction for authorizing initiation - the initiation stage itself will refine this into a detailed Business Case. Requiring comprehensive cost-benefit breakdown across all hubs before authorizing initiation contradicts PRINCE2's staged approach to business case development.

The Risk Register comprehensiveness similarly expects a level of detail (comprehensive threat identification, fully defined response strategies, complete ownership assignments) that belongs in the refined Risk Register produced DURING initiation, not in the preliminary version used to authorize it. The preliminary Risk Register appropriately identifies key risk categories; detailed response strategies will be developed in the initiation stage.

This answer represents the MOST appropriate course of action based on PRINCE2 7 principles and practices.

The key considerations are:

1. Project Board Authority: The vendor's upgrade proposal represents a potential scope change that would alter the agreed Project Product Description and potentially impact benefits, costs, risks, and timelines. Only the Project Board has the authority to approve such changes - this is not within the Project Manager's delegated authority.

2. Not an Exception: The project is currently operating within all tolerances. An Exception Report is only required when a stage is forecast to exceed its tolerances. This situation does not constitute an exception - it is an opportunity that requires a change decision.

3. Appropriate Escalation Process: The correct approach is to acknowledge the value of the opportunity while recognizing it requires Project Board consideration. The Project Manager should document the opportunity with proper impact analysis (covering benefits, risks, costs, schedule implications, and resource requirements) and seek Project Board direction.

4. Timing Sensitivity: While there is a vendor deadline (ten business days), this doesn't automatically trigger the exception process. The Project Manager should present the opportunity to the Project Board, either at the scheduled meeting (if timing permits) or request ad hoc direction if the timing is critical - allowing the Board to decide on the urgency.

Why the other answers are less appropriate:

The Exception Report approach is incorrect because the project remains within tolerances. Exceptions are triggered by tolerance breaches, not by opportunities or change requests. Using the exception process inappropriately would blur the governance boundaries and create confusion about when exceptions are truly needed.

Waiting to include this in the Highlight Report for the next scheduled Board meeting (in fourteen days) would likely miss the vendor's ten-day deadline. Highlight Reports are for routine progress updates, not for urgent decisions requiring Board input. This passive approach fails to recognize the time-sensitive nature of the opportunity.

Contacting Board members separately and convening an urgent meeting bypasses proper governance processes. While the Project Manager can request ad hoc Board decisions, the approach described suggests making individual contacts before properly documenting the opportunity and its implications. The Project Manager should first prepare appropriate documentation and then formally request Board direction through proper channels, rather than conducting informal polling of Board members.

The correct answer demonstrates appropriate escalation, respects governance boundaries, acknowledges time constraints, and ensures proper documentation - all consistent with PRINCE2 7's emphasis on defined roles, tailored governance, and appropriate decision-making at the right organizational level.

The PRIMARY factor guiding the Project Board's decision on authorizing closure should be whether all project products have been accepted and ownership has transferred to those responsible for their ongoing operation and maintenance.

In PRINCE2 7, project closure is authorized when the project's products have been delivered, accepted, and handed over to the operational teams or users who will maintain them. The scenario clearly states that the building has been handed over and accepted by the City Council's facilities management department, and the Lessons Report has been compiled and distributed.

The key principle here is that a project is temporary by nature and exists solely to create products. Once those products are delivered and accepted, the project has fulfilled its core purpose. The other elements mentioned in the scenario do not prevent closure:

• Unspent budget for seasonal planting: This represents work that was planned but is not critical to the acceptance of the core project product (the sports facility building). This can be managed through operational budgets or a separate small work package.

• Benefits Review Plan scheduled for eight months later: Benefits realization occurs AFTER project closure, not before. The Benefits Review Plan is a product that guides post-project benefits measurement, which is typically conducted during the operational phase. Projects deliver outputs; benefits are realized later through business operations.

• Team members transitioning to support roles: This is a normal part of project closure. The transition to operational support funded by operational budgets indicates proper handover is occurring.

The essence of PRINCE2 is that projects are temporary endeavors. Once products are delivered, accepted, and handed over with appropriate documentation (including the Lessons Report), the project should close. Keeping a project open for benefits measurement or minor outstanding work items contradicts the principle of project temporariness and wastes project governance resources.

The other options represent either post-project activities (benefits measurement), operational concerns (budget spending on future work), or administrative matters (team transitions) that should not prevent closure when the primary deliverable has been accepted.