In the context of PRINCE2 7, the Project Plan is a mandatory management product created during the 'Initiating a Project' process. It serves as a high-level statement detailing how and when a project's objectives—specifically time, cost, scope, and quality targets—will be achieved. It identifies the major products, activities, and resources required for the entirety of the project lifecycle.

The Project Plan is pivotal for the Business Case, as it provides the planned costs and timescales necessary to verify the project's viability. It acts as the primary baseline against which the Project Board monitors total progress. While it outlines the overall schedule and defines the number and duration of management stages, it remains distinct from and less detailed than the specific Stage Plans used for day-to-day management.

A key aspect of the Project Plan in PRINCE2 7 practice is its dynamic nature. Although baselined at the start to authorize the project, it is updated at the end of each management stage (during the 'Managing a Stage Boundary' process). These updates reflect actual progress from the completed stage and revised forecasts for the remainder of the project. This ensures that the Project Board always possesses a current view of the project's status to make informed decisions regarding continued business justification.

The plan typically includes the schedule, prerequisites, external dependencies, planning assumptions, lessons incorporated, monitoring and control definitions, budgets, and tolerances. It essentially forms the 'contract' between the Project Manager and the Project Board, defining the deliverable expectations and the resources required to achieve them.

In the context of PRINCE2 7, a Stage Plan is a detailed management product created to facilitate day-to-day control over a specific management stage. While the overarching Project Plan provides a high-level roadmap and the Business Case justifies the investment, the Stage Plan offers the granular detail required for execution and monitoring. It is typically produced by the Project Manager near the end of the current stage during the 'Managing a Stage Boundary' process, serving as a prerequisite for the Project Board to authorize the next stage.

Within the Plans Practice, the Stage Plan is distinct because it operates on a shorter planning horizon, allowing for greater accuracy in estimating time, costs, and resources compared to the Project Plan. It breaks down the stage deliverables into activities and products, forming the basis for the Work Packages assigned to Team Managers. The plan must include details on quality management activities, risk responses, specific resource requirements, and the schedule for the stage.

Crucially, the Stage Plan acts as the 'contract' between the Project Manager and the Project Board. The Board approves this plan and sets specific tolerances (limits on time, cost, scope, quality, risk, benefits, and sustainability). If the Project Manager forecasts that the stage will remain within these tolerances, execution continues. However, if tolerances are forecast to be exceeded, the Stage Plan is effectively invalidated, triggering an Exception Report. If the Board wishes to proceed, the Stage Plan is then replaced by an Exception Plan. This structure ensures that the project is managed in manageable 'bites,' preventing loss of control over long durations.

In the context of the PRINCE2 7 Plans practice, a Team Plan is an optional level of planning used to govern the execution of one or more Work Packages. While Project Plans and Stage Plans are mandatory management products owned by the Project Manager to direct and manage the project, the Team Plan is created and managed by the Team Manager (or the delivery team) to facilitate the actual delivery of specialist products.

The primary purpose of a Team Plan is to provide the granular detail regarding activities, resource requirements, and schedules necessary to complete the assigned Work Package within agreed tolerances. It acts as a bridge between the high-level management control of the Project Manager and the technical execution by the delivery team. Because the Project Manager manages by exception and focuses on the delivery of products via Work Packages, they do not require visibility of the minute details contained within a Team Plan, provided the Work Package constraints are met.

PRINCE2 7 highlights significant flexibility regarding the format of a Team Plan. It does not need to follow the formal structure of a Project or Stage Plan. In agile environments, for example, a Team Plan might simply take the form of a sprint backlog or a Kanban board showing tasks in 'To Do,' 'Doing,' and 'Done' columns. In traditional environments, it might be a detailed Gantt chart. Crucially, the Team Plan allows the Team Manager to monitor progress and resource utilization effectively without overburdening the Project Manager with micromanagement, ensuring that the products are delivered to the requisite quality standards and within the agreed timeline.

In the context of PRINCE2 7, an Exception Plan is a specific type of plan used to recover from a situation where agreed tolerances are forecast to be exceeded. It is essentially a revised plan that replaces a Stage Plan (or occasionally a Project Plan) that is no longer viable. When a Project Manager forecasts that a stage will breach its tolerances for time, cost, quality, scope, benefits, or sustainability, they must escalate the issue to the Project Board via an Exception Report. If the Board wishes the project to proceed, they will request an Exception Plan.

Structurally, an Exception Plan follows the same format and level of detail as the plan it replaces. It includes prerequisites, external dependencies, planning assumptions, schedules, and budgets. However, its specific purpose is to show the actions required to recover from the exception and complete the work of the stage (or project) effectively. It covers the period from the point where the current plan is abandoned to the end of the stage.

Crucially, the Exception Plan is not an add-on; it is a replacement. Once the Project Board approves it during an Exception Assessment, the Exception Plan becomes the new baselined plan. The original Stage Plan is no longer used for measuring progress. This mechanism ensures that the project remains under control even when significant issues arise. It allows the Project Board to reassess the project's viability (business case) in light of the new data and costs required to fix the issue, ensuring that resources are not wasted on a project that can no longer deliver its intended value.

In the context of the PRINCE2 7 Plans practice, the Project Product Description (PPD) is a specialized management product that acts as the ultimate definition of what the project must deliver to gain acceptance. It essentially defines the project's scope and serves as a binding agreement between the customer (user) and the supplier regarding the final output.

Created during the 'Starting a Project' process and refined during 'Initiating a Project', the PPD is the starting point for the Product-Based Planning technique. Before a project manager can create a Product Breakdown Structure (PBS), they must first define this top-level product. The PPD provides the context for the Project Plan, identifying the development skills required and the quality standards that must be met.

The document distinguishes between two vital quality elements:
1. **Customer's Quality Expectations**: High-level requirements (e.g., speed, scalability, sustainability) that influence the design and choice of solution.
2. **Acceptance Criteria**: A prioritized list of specific, measurable definitions of what the final product must achieve to be signed off. These criteria are strictly binary (met or not met).

Throughout the project lifecycle, the PPD serves as the baseline against which changes are assessed. If a request for change alters the PPD, it requires Project Board approval. Finally, during the 'Closing a Project' process, the PPD is referenced to verify that the project has delivered exactly what was requested, ensuring the output is fit for purpose and capable of realizing the expected benefits defined in the Business Case.

In the context of PRINCE2 7 and the Plans practice, the Work Package Description serves as the fundamental vehicle for delegating work from the Project Manager to the Team Manager. It acts as a formal agreement between the managing layer (Managing a Stage process) and the delivery layer (Managing Product Delivery process), ensuring that no work commences without specific authorization.

Its primary purpose is to define exactly what needs to be delivered, the constraints involved, and the reporting requirements. It contains or references one or more Product Descriptions, detailing the quality criteria and standards required. The Work Package allows the Project Manager to maintain control without micromanaging, as it establishes the boundaries—specifically tolerances for time, cost, and scope—within which the Team Manager can operate autonomously.

Key components of a Work Package include:

1. Joint Agreements: Estimates for effort, cost, and dates agreed upon by both the Project Manager and Team Manager.
2. Techniques and Standards: Specific development methods or quality standards that must be applied.
3. Interfaces: Details on human or technical interfaces (e.g., who must be consulted during development).
4. Reporting Arrangements: The frequency and format of Checkpoint Reports.
5. Problem Handling: Procedures for escalating issues if tolerances are forecast to be breached.

From a planning perspective, the Work Package is the trigger for the Team Manager to create a Team Plan (optional in PRINCE2 but recommended). It represents the lowest level of work definition in the project's planning hierarchy. By defining the work clearly in this document, the project ensures that the products delivered align with the Stage Plan and Project Plan, while clearly delineating accountability for delivery.

The Product-based Planning technique is a distinctive framework within the PRINCE2 7 Plans practice that prioritizes deliverables over activities. The core philosophy is that a project team cannot effectively plan the work (activities) until they clearly define exactly what must be produced. This approach minimizes the risk of scope creep and ensures a shared understanding of quality requirements from the outset.

The technique comprises four sequential steps:

1. Write the Project Product Description: This defines the final output of the project. It establishes the customer's quality expectations and acceptance criteria, acting as the ultimate target.

2. Create the Product Breakdown Structure (PBS): This is a hierarchical diagram that decomposes the project product into its constituent parts. It breaks down the scope into major products and sub-products, identifying all necessary management, specialist, and quality products required for success.

3. Write Product Descriptions: For the component products identified in the PBS, detailed descriptions are drafted. These specify the composition, format, quality criteria, and tolerances for each item, providing the team with precise instructions on what 'finished' looks like.

4. Create the Product Flow Diagram (PFD): This diagram maps the sequence in which products must be developed. It highlights dependencies, showing which products must exist before others can be created, and identifies any external products required.

Only after these four steps are complete does the Project Manager move to activity-based planning (identifying activities, estimating resources, and scheduling). By enforcing this sequence, PRINCE2 7 ensures that plans are realistic, complete, and aligned with the principle of 'Focus on Products'.

In the context of PRINCE2 7, the relationship between the Planning Horizon and Management Stages is central to the principle of 'manage by stages'. The **Planning Horizon** refers to the period of time for which it is possible to plan activities, costs, and resource usage with a reasonable degree of accuracy. PRINCE2 recognizes that trying to plan the detailed minutiae of a project from start to finish is often wasted effort due to the 'cone of uncertainty,' where accuracy diminishes the further into the future you look.

**Management Stages** are the discrete sections into which the project is divided to handle this uncertainty. The length and number of stages are largely dictated by the planning horizon. A management stage should only last as long as the project team can plan for effectively. For example, a high-risk or highly innovative project may require short stages to allow for frequent review points, whereas a repetitive, low-risk project might have longer stages.

This logic drives the two-tiered planning approach in PRINCE2. The **Project Plan** covers the entire duration but remains at a high level, outlining major products and milestones to support the Business Case. Conversely, the **Stage Plan** is created stage-by-stage (rolling wave planning). Produced before the start of a new stage, the Stage Plan contains the granular detail necessary for day-to-day control, strictly aligned with the current planning horizon. This ensures that the Project Board only authorizes resources and work for a period that can be forecasted confidently, maintaining control and viability.

In the context of the PRINCE2 7 Plans practice, distinguishing between Tolerances and Constraints is fundamental to establishing realistic baselines and enabling 'Management by Exception'.

Constraints are restrictions or limitations within which the project must be delivered. They represent the non-negotiable boundaries of a plan. Constraints effectively remove flexibility and are often driven by external factors or rigid business requirements. For example, a project might have a hard deadline due to new legislation (Time constraint), a fixed grant amount that cannot be exceeded (Cost constraint), or mandatory adherence to specific environmental standards (Sustainability constraint). During the planning process, constraints are identified first because the plan must be constructed to fit within these limitations.

Tolerances, conversely, define the permissible deviation from a plan’s specific target that is allowed before the deviation must be escalated to the next level of management. Tolerances provide the layer of autonomy required for the project management team to function without micromanagement. PRINCE2 7 establishes tolerances against seven aspects of performance: Benefits, Costs, Time, Quality, Scope, Risk, and Sustainability. For instance, a Stage Plan might have a target cost of $50,000 with a tolerance of plus/minus $5,000. As long as the stage is forecast to stay within $45,000 and $55,000, the Project Manager retains control. If the forecast exceeds these bounds, an Exception Report must be raised to the Project Board.

In summary, while constraints dictate the rigid parameters the plan must adhere to, tolerances define the authorized 'wiggle room' around targets, ensuring efficient governance and controlled progress.