Project Management - Plans | Compass / PRINCE2 / Summary

Plans

The purpose of the plans practice is to facilitate communication and control by defining the products to be delivered (the ‘what’) and the means to deliver them (the ‘who’, the ‘how’, the ‘where’, and estimates of the ‘when’ and for ‘how much’) to satisfy the project business case (the ‘why’).

Definition: Plan A proposal that outlines the what, where, when, how, and who of the project as a whole (or a subset of its activities). In PRINCE2, there are the following types of plan: project plan, stage plan, team plan, and exception plan.

7.1 The Dual Purpose of Plans

Plans Enable Understanding and Communication

Plans integrate three perspectives:

The user’s expectations of the products to be delivered and the benefits to be realized
The project management team’s assessment of the most effective approach to meet these expectations
The business support for the project, including the commitment of funding, people, and resources

Plans enable the project management team to assess and understand:

The why: the user’s driving requirements and the benefits they expect to realize
The what: the products to be delivered and their associated acceptance criteria and quality specifications
The how: the delivery method and any constraints
The when: the sequence and estimated duration of delivery activities
The where: the locations and facilities involved in delivery and acceptance
The who: the required skills and responsibilities of the project team and how they will be organized
The how much: the estimated cost of the agreed products and the associated delivery and management activities

Plans Enable Control

Definition: Scope The sum of the product, delivery, and management activities represented by an approved plan and its product descriptions and work package descriptions.

An approved and baselined project plan represents the agreed scope of the project. A clear understanding of what is and what is not within the approved project scope is essential to avoid uncontrolled changes, often referred to as scope creep.

7.2 Guidance for Effective Planning

7.2.1 Planning Horizon

Plans are always based on estimates. The PRINCE2 principle of manage by stages addresses the need to keep plans within reasonable planning horizons. A PRINCE2 project has:

A project plan: a high-level description of how and when the project’s objectives are to be achieved
A stage plan: a detailed document for the current stage based on more precise estimates achievable within the planning horizon

7.2.2 Levels of Plans

Plan Type	Definition
Project plan	A high-level plan showing the major products of the project and when, how, and at what cost they will be delivered
Stage plan	A detailed plan used as the basis for project management control throughout a stage
Team plan	A plan used as the basis for organizing and controlling the work of a team when executing a work package. Team plans are optional in PRINCE2
Exception plan	A plan that follows an exception report and explains how the project will respond to the exception within the stage

Relationship between plans:

Project mandate/business plan → Project plan → Subsequent stage plans → Team plans
                              ↘ Initiation stage plan
                                              ↘ Exception plans (as necessary)

7.2.3 Stages

Determining how to divide the project into stages is a matter of balancing:

The delivery method (iterative-incremental or linear-sequential)
The sequence of delivery activities
The type of people and resources involved
The number and timing of key decision points
The amount of risk the project can manage
How far ahead in the project it is sensible to plan

The number of stages: A greater number of stages increases the degree of control, but every stage boundary requires effort to manage.

The length of stages is determined by:

The level of complexity: high dependencies may benefit from shorter stages
The level of risk: stage breaks at key points where risks can be reviewed before major resource commitment
The planning horizon: significant uncertainty benefits from shorter stages
Appropriate decision points: stage boundaries aligned with critical decisions
Alignment with programme activities: programme may require alignment with tranche boundaries

PRINCE2 stages do not overlap — they partition the project by introducing stop-go decision points, enabling the project board to review progress and confirm continued business justification.

7.2.4 Tolerances in Planning

PRINCE2 includes tolerances for benefits, time, cost, quality, scope, risks, and sustainability:

Tolerance Type	Definition
Time tolerance	The permissible deviation in a plan’s time that is allowed before the deviation needs to be escalated to the next level of management
Cost tolerance	The permissible deviation in a plan’s cost that is allowed before it needs to be escalated to the next level of management
Scope tolerance	The permissible deviation in a plan’s scope that is allowed before it needs to be escalated to the next level of management

7.2.5 Product-Based Planning

Definition: Product-based planning The PRINCE2 technique leads to a plan based on the creation and delivery of the required products.

Focus on products is a principle of PRINCE2. Benefits:

Helps avoid activities that do not contribute substantively to the required outputs
Helps the project manager know where to start when developing plans
Reduces the risk of scope being neglected or overlooked
Helps exception plans focus on resolving the exception with minimal impact on cost and schedule

7.3 PRINCE2 Planning Technique

7.3.1 Planning Technique Steps (Six Steps)

Step	Description
1. Defining and analysing products	Write project product description → Create product breakdown structure → Write product descriptions → Create product flow diagram
2. Organizing work packages	Identify work packages and determine dependencies
3. Preparing estimates	Estimate people, resources, activity duration, costs, benefits, and risks
4. Preparing a schedule	Sequence, interrelationships, and duration of work packages and tasks
5. Preparing the budget	Calculate plan costs including risk budget and change budget
6. Documenting the plan	Analyse risks, create narrative document explaining the plan

Defining and Analysing Products in Detail

Project product description

A description of the project’s major products or outcomes, including the user’s quality expectations, together with the acceptance criteria and acceptance methods for the project.

Product breakdown structure

A hierarchy of all the products to be produced during a plan.

Each product is divided into its component elements in a hierarchical manner, and the requirements for those elements are collected.

Product flow diagram

A diagram showing the sequence of production and interdependencies of the products listed in a product breakdown structure.

Dependencies

A dependency means that one product is dependent on another.

Internal dependency: between two products of a project — the project team has control

External dependency: between a project product and a product or activity outside the scope of the project — the project team does not have complete control

7.3.2 Supporting Techniques

Prioritizing methods:

Categorizing criteria as must-have, should-have, could-have, or won’t have (MoSCoW)
A product backlog approach explaining the sequence in which features will be made available
Pairwise comparison to understand preferences between criteria
The Kano model (delighters, performance features, and essential features)
Eisenhower matrices (importance vs. urgency or value vs. ease of implementation)

Scheduling tools:

Gantt chart: graphical representation of task duration against time progression
Spreadsheet: listing work packages and tasks with corresponding timelines
Product checklist: list of major products and key delivery dates
Activity flow board: shows progress of each product through development/delivery (Kanban)

Estimating techniques:

Top-down: costs, durations, and effort estimated at a high level of confidence, then allocated down
Bottom-up: estimates made at the lowest defined level, then aggregated
Comparative: based on similar projects or publicly available market information
Parametric: using values in the project (numbers of units, size) to estimate
Data analysis: descriptive analysis (characteristics of tasks) and predictive analysis (likely outcomes)
Subject matter expertise: consensus-based techniques such as Delphi and planning poker

7.4 Applying the Practice

7.4.1 Organizational Context

Project plans are typically affected by the organizational context, including policies, procedures, and support
The programme management team may play a major supporting role, even leading the planning for its projects
The programme may define a standard set of stages that projects within it must follow

7.4.2 Commercial Context

For projects in a commercial context, the role of suppliers is an important consideration
Agreements should ensure supplier plans provide clear traceability to the user’s project plan
Agreements should describe how plans are prepared and what inspection and audit rights the user has
Plans should include procurement-related milestones aligned to each stage

7.4.3 Delivery Method

Linear-sequential projects: most planning work done upfront during starting up and initiating processes; comparable projects help establish planning horizons and high-confidence estimates
Iterative-incremental projects: focus on how much can be produced in a fixed time period (e.g., sprints or timeboxes); aim to quickly deliver initial products and iteratively improve them

7.5 Management Products

Key planning management products include:

Project product description: for project plan only, created during starting up a project
Product descriptions: describe required products in more detail during initiating a project
Work package descriptions: agreements between project manager and team manager, documenting all dependencies
Schedule and budget: may be maintained in separate systems or files
Narrative document: explains the plan at a high level, identifying dependencies, proposed tolerances, monitoring and control requirements, budgets, key risks, and assumptions