Plans

Instead of going on with the project and reacting to everything on an ad hoc basis, we spend some time and plan the best way of doing the project and then implement the plan.

By default, a PRINCE2 project is planned at a high level at the beginning of the initiating a project process and then gradually detailed before each management stage in managing a stage boundary process.

Note that “planning” includes “scheduling”, but is not limited to that.

Purpose

The purpose of the plans practice is to provide a structured framework for designing, developing, and maintaining various project plans. These include the project plan, stage plan, exception plan, and team plan. This practice helps answer key project management questions and ensures clarity in project execution:

• What is required?
• How will it be achieved, and by whom?
• How should the products be created?
• What steps will be followed?
• How can product-based planning be implemented?
• What quality standards must be met?
• What is the estimated cost?
• What level of detail is required for each plan?

Remember, without a plan, there is no control over the project. As the saying goes, “Failing to plan is planning to fail.” planning is crucial to ensure that progress can be tracked and managed effectively throughout the project lifecycle.

The 3 levels of planning

It is often not feasible to plan the entire project in detail upfront because, in most cases, the ability to plan in-depth extends only a short distance into the future. This is known as the planning horizon—the furthest point in the future that can be accurately planned for. To accommodate this, PRINCE2 recommends three levels of planning:

• The project plan: This is a high-level plan used at the direction level by the project board. It is created during the initiating a project process and outlines the major products, their delivery timelines, and the associated costs. It serves as a primary control document for the project board, providing the overall direction for the project. The project manager keeps the project plan updated throughout the project.
• The stage plan: This plan is used at the management level by the project manager. Created for each stage of the project, it covers a detailed time period (e.g., two months) and outlines the specific activities, resources, and costs for that stage. It is far more detailed than the project plan, focusing on the immediate stage of the project.
• The team plans: These plans are used at the delivering level by the team manager. Created within the managing product delivery process, they focus on the tasks assigned to the team as part of a work package. The team plan helps ensure that the team’s work is clearly defined and controlled.

Additional plans

In addition to the main three plans, PRINCE2 projects may also create other important plans:

• Exception plans: These replace an existing project plan or stage plan when deviations from the original plans are forecasted. They provide a way to bring the project back on track.
• Benefits management approach: Covered in the business case practice, this plan outlines how the project’s benefits will be realized and tracked throughout the lifecycle.

By using these planning tools and techniques, PRINCE2 ensures that the project is clearly defined, effectively controlled, and capable of delivering the expected outcomes.

Meaning of planning

While some people may view a plan simply as a Gantt Chart, it is far more comprehensive. A plan is a document that outlines how, when, and by whom specific targets or goals will be achieved. These targets go beyond just delivering the project product; they also cover time, cost, quality, scope, risk, benefits, and products.

A good plan should provide enough detail to show these targets are achievable. The plan should serve as the backbone of the project, guiding the project team and providing a baseline for assessing progress. It is developed at the project’s start and updated throughout its lifecycle. As the project progresses, the actual performance is compared against the original plan to measure how well the project is doing.

A project plan answers key questions:

• Why is the project happening?
• What will be delivered?
• Who is responsible for each task?
• When will things happen?
• How much will it cost?

Path to planning

Here’s an overview of the typical planning steps in a project. This will help you understand when the plans are created and how they add value to the project.

Project product description

The first step in product-based planning is to create the project product description. This document outlines the overall scope, purpose, and requirements of the project product. It is created during the starting up a project process and forms the foundation for all further planning.

Initiation stage plan

The project manager is responsible for creating the initiation stage plan, which covers the details of the first stage of the project. This plan is the day-to-day guide for managing the initiation stage and serves as the first formal stage plan in the project.

This product-based planning technique is used across multiple processes: Starting up a project, initiating a project, and managing a stage boundary. The following key documents are produced during this phase:

• Project product description (created during the starting up a project process)
• Product breakdown structure
• Product descriptions
• Product flow diagram

Project plan

The project plan is a high-level document that provides a roadmap for the entire project. It includes key elements such as the business case, cost, and timescale information, and it must be approved by the project board. Once it is approved, the project plan is baselined (signed off and stored) as the official project reference.

Stage plans

Stage plans are developed by the project manager towards the end of each stage for the next stage. These plans provide day-to-day management details for the next stage, ensuring the project stays on track for the upcoming period.

Exception plans

An exception plan is created if a project or stage goes outside of its agreed tolerances. This plan addresses how to get the project or stage back on track, providing a revised approach that picks up from where the current plan left off and extends to the end of the stage or project. Exception plans help address significant issues that threaten the project’s success.

Updated project plan

At each stage boundary process, the project plan is updated. This involves reviewing the products created in the previous stage and incorporating new information from the next stage plan. The updated project plan also includes any forecast information that may affect the project’s future direction.

At the end of the project, the project plan is once again updated by the project manager. It now reflects the full cost, timescale, and what has been delivered throughout the project. This final version allows the project board to compare the actual outcomes with the original baseline plan to assess how well the project performed in terms of time and cost.

Team plans

Team plans are created by the team managers for the specific work assigned to their teams. While these plans are optional, they are particularly useful in complex projects where clear direction and detailed planning for individual work packages are necessary.

Exception plan

An exception plan is created when there is a deviation from the agreed tolerances, also known as “going out of tolerance.” for example, if during a stage, the project manager forecasts that the project will exceed the agreed cost tolerance by 15% (or if it already has), they must inform the project board of this deviation, which is referred to as an “exception.”

Once the project board is notified of the exception, they will typically request an updated plan to recover the project and complete the current stage. This updated plan, called the exception plan, will replace the current stage plan and will provide the direction and actions needed to bring the project back within the tolerances.

The exception plan is developed with the same level of detail as it replaces and continues from where the previous plan left off. Its purpose is to get the project back on track and ensure that it progresses as planned. Exception plans can be used to replace stage plans and project plans but cannot be used for team plans. They are crucial for managing deviations and ensuring that the project can still achieve its objectives despite the issues that arise.

Planning steps

PRINCE2 uses product-based planning, starting with defining products and then creating the work breakdown structure, estimates, and schedule based on those descriptions. You can use a different method, but any changes should be documented in the project initiation documentation.

This technique covers all plans: project, stage, team, and exception plans. The project management team defines products, activities, resources, schedules, and risks for each plan.

Stage and team plans are more detailed but narrower in scope than the project plan. For example, a stage plan might break down work by day, while the project plan shows the overall timeline. When creating subordinate plans, ensure no new requirements are added that aren’t in the original project plan to avoid scope creep.

The planning steps used to create the project plan and stage plan are:

1. Defining and analysing the products
   1. Writing the project product description
   2. Creating a product breakdown structure
   3. Writing product descriptions
   4. Creating a product flow diagram
2. Organizing work packages
3. Preparing estimates
4. Preparing schedule
5. Preparing the budget
6. Documenting the plan
7. Analysing risks

Step 1/7 — defining and analysing the products

Defining and analysing products consists of four steps, and I will introduce each one of these steps:

1. Writing the project product description
2. Creating a product breakdown structure
3. Writing product descriptions
4. Creating a product flow diagram

Step 1.1 — writing the project product description

The project product description is created during the starting up a project process. The project manager is primarily responsible for creating this document, but they will typically involve key stakeholders such as the senior user, senior supplier, and team managers. These stakeholders collaborate to define the project’s major products, establish quality expectations, and set acceptance criteria.

The purpose of the project product description is to ensure that all necessary products required to meet the user’s expectations are identified and documented. It also prevents the inclusion of unnecessary products that may otherwise add complexity or confusion. High-level acceptance criteria are often stated in measurable terms for clarity. However, when precise measurements aren’t feasible at this stage, descriptive statements can be used, with the understanding that these will be refined into more concrete criteria during the development of the product descriptions.

This document not only facilitates a shared understanding among the project manager, project board, and other stakeholders but also serves as the foundation for setting effective quality tolerances. If necessary, alternative project approaches and solutions may be considered to ensure the best products are included in the scope and align with the business case. These solutions are typically described in high-level detail.

Project product description: A comprehensive description of the project’s major products, user quality expectations, the acceptance criteria, and methods for accepting the products. This ensures the project’s objectives are clear and achievable from the outset.

Step 1.2 — creating a product breakdown structure

A product breakdown structure (PBS) is a hierarchical list of all the products to be delivered during a plan.

The PBS helps define the products and their components, breaking them down into smaller elements. The requirements for each element are gathered. This structure also helps group related requirements together logically. For example, plumbing requirements in a house are grouped separately from wall finishing.

It’s useful for identifying and managing external dependencies, such as products the project depends on. Additionally, a PBS can group requirements by procurement or delivery method.

I prefer using a mind map to create a PBS. It’s a great tool for visualizing the structure and ensuring all components are accounted for in a logical manner.

Step 1.3 — writing product descriptions

During project initiation, the required products are described in more detail. The project manager gathers user requirements and documents them in product descriptions, which serve as specification documents for each product. The project manager will typically invite subject matter experts, team members, and key stakeholders to the meetings where these product descriptions are created. These descriptions outline how the products will be procured, developed, tested, used, and supported after acceptance. The goal is to ensure the product requirements are clear enough for accurate scheduling and estimation.

While PRINCE2 suggests that product descriptions are created during the initiation stage, they can also be developed during the managing a stage boundary process. In linear projects, product descriptions should be detailed to estimate costs and time accurately. In iterative projects, high-level descriptions can be used initially, with detailed requirements developed alongside the product. Additionally, prioritizing quality specifications helps balance user expectations with project constraints, ensuring the most important requirements are met.

Step 1.4 — creating a product flow diagram

A product flow diagram shows the sequence and dependencies of products in a product breakdown structure.

The product breakdown structure helps identify product dependencies, which are shown in a product flow diagram. This diagram illustrates the sequence in which products will be developed and how they are interrelated. Intermediate products, which are created as inputs for other products but not used by the end user, may also need to be included. For example, a prototype might be produced as an input to full-scale production but isn’t used by the final customer. The product flow diagram must account for both intermediate and final products, including dependencies on external products outside the project scope.

While product flow diagrams can be helpful, they are often difficult to create and read. As a result, they are not widely used. Instead, many project managers choose to list the products in a Gantt Chart and show the dependencies between them. This method is easier to create and much more accessible for stakeholders to read and understand.

Step 2/7 — organizing work packages

A work package is a clearly defined set of tasks, responsibilities, and resources required to deliver a specific product or part of a product within the project. It is a manageable unit that helps organize and track progress, and each work package is linked to the overall project scope.

The product flow diagram helps decide whether the project should be delivered in a linear-sequential or iterative-incremental way. Once the delivery method is decided, the project management team organizes the activities into work packages. Each work package groups related people, resources, and activities to create at least one required or intermediate product.

The work package description must document dependencies between work packages or external sources. This description is an agreement between the project manager and the team manager, even if no formal contract exists.

The project manager should ensure there is no overlap between work packages to avoid unnecessary costs and conflicts. The total of all work packages must cover the whole project scope, with no gaps between the product flow diagram, product breakdown structure, and work packages.

It is helpful to organize project management activities into one work package for each stage, even if these activities are not part of the project budget. This shows the relationship between stages and milestones in relation to product delivery.

PRINCE2 has introduced the concept of work breakdown structure (WBS) to map work packages. However, this can be confusing because the WBS is similar to the product breakdown structure (PBS), and I will not go further into WBS in this section.

Step 3/7 — preparing estimates

Estimating is the process of determining the time, resources, and effort needed to complete a task to an acceptable standard. Project managers and team managers rely on estimates for various aspects of a project:

• People: Required skills, effort, timing, and location.
• Resources: Materials, equipment, facilities, and costs.
• Duration of activities: Estimated time to complete tasks.
• Cost of people and resources: Labor rates, unit costs, and market or supplier rates.
• Benefits: Estimated value of project outcomes.
• Risk: Estimates of risk proximity, probability, and impact, including responses.

The project manager should minimize estimating and, instead, facilitate workshops with the necessary people. This collaborative approach ensures accurate estimates, as it taps into the experience of those involved. These workshops can be combined with product-based planning sessions to improve the process.

By engaging the right team members and using their expertise, the project manager ensures that estimates are both realistic and actionable, reducing risks and improving project outcomes.

Step 4/7 — preparing a schedule

A schedule is a graphical representation of a plan, often displayed as a Gantt Chart, showing tasks, their sequence, and resource allocations to deliver the plan.

The sequencing, interrelationships, and duration of work packages and tasks are captured to create a schedule. A work package contains delivery activities, which are broken down into tasks. For each task, the project manager identifies the required resources, the effort needed, and estimates the duration. The schedule should include all work packages for the stage, which is refined as the level of effort and task duration becomes clearer.

Here are the steps involved in preparing a schedule:

• Define the activity sequence.
• Assess resource availability.
• Assign resources.
• Level resource usage.
• Agree on control points.
• Define milestones.
• Calculate total resource requirements and costs.
• Present the schedule.

Warning: The project manager should avoid defining minute tasks for team members, as this leads to micromanagement, which is not good practice. Instead, the project manager should focus on managing work packages and ensuring that the team has the autonomy to complete tasks within the agreed scope, time, and resources.

A schedule is essential for managing project progress, and PRINCE2 helps organize these steps. Many modern tools, like MS project, assist in executing these steps together, making it easier to manage tasks and resources effectively.

Step 5/7 — preparing the budget

The budget is calculated by listing the required people, resources, and their costs, along with other project expenses. The budget should cover:

• Costs of activities
  • people
  • equipment
  • materials
  • facilities
  • project management activities
  • Etc.
• Risk budget
• Change budget
• Cost tolerances

Definition of “resource”: The goods, services, equipment, materials, facilities, and funding needed to complete the plan.

Typically, the project manager will be responsible for preparing the budget. They will likely collaborate with the project board, finance team, team managers, and other stakeholders to gather the necessary information and make informed decisions. Past experience and lessons learned from previous projects are important in this process, as they provide insights into estimating costs and identifying potential risks.

The budget may need to be documented in different components depending on the resource type. For example, the time needed in a test facility could be included in the schedule, while capital funding would be detailed in the project budget.

Risk and change budgets are optional. Their use depends on the project’s context, weighing the value of extra control against additional project management costs and time.

Step 6/7 — analysing risks

As the project plan develops, it’s important to analyze it for potential risks. Throughout the planning process, the plan should be checked for risks and all identified risks should be entered into the risk register.

Once the plan is created, it should still be treated as a draft until decisions are made on how to address any inherent risks. Based on these decisions, the plan may need to be updated.

The project manager is responsible for analyzing the plan for risks. They will typically seek input from team managers, subject matter experts, and other stakeholders to identify risks effectively and ensure the plan accounts for them.

Step 7/7 — documenting the plan

The PRINCE2 planning technique involves creating several management products, like schedules, budgets, product breakdown structures, and flow diagrams. These can be stored in various tools like documents, spreadsheets, or collaboration tools. However, it’s also important for the project manager to prepare a high-level narrative document that explains the overall plan. This document should include:

• Internal and external dependencies
• Proposed tolerances
• Monitoring and control requirements
• Budgets
• Key risks
• Assumptions underlying these elements

Additionally, the document should outline the project’s stages and describe the planned decisions for the project board.

Supporting techniques for planning

There are three main supporting techniques for planning:

• Prioritizing
• Scheduling
• Estimating

Let’s have a closer look at each technique.

Prioritizing

This section focuses on various techniques supporting project planning, such as prioritizing, scheduling, and estimating. These techniques help manage the project’s scope, timeline, resources, and risks.

Projects rarely have enough time, money, or resources to deliver everything requested, even if it’s all justified. Therefore, project scope, including acceptance criteria and quality specs, needs to be prioritized to deliver what has the most business value.

Some common ways to prioritize include:

• MoSCoW: Categorizing requirements as must-have, should-have, could-have, or won’t have
• Using a product backlog to define the order of features or criteria delivery
• Pairwise comparisons to understand preferences
• The Kano model classifies features as delighters, performance, or essentials
• Eisenhower matrices to assess importance vs. urgency or value vs. ease

These prioritization techniques help define scope tolerances and align with the manage by exception principle.

Scheduling

A project schedule outlines the sequence, dependencies, durations, and milestones of activities. Common scheduling techniques include:

• Gantt Chart: A visual representation of task durations over time, useful for projects with many activities.
• Spreadsheet: A simple list of tasks and timelines, though harder to manage for large projects with frequent changes.
• Product checklist: A list of major products and key delivery dates, providing an overview of project performance.
• Kanban board (activity flow board): Displays how products progress through development or delivery, often used in iterative projects like those using kanban boards.

While creating these schedules is essential, it’s important to keep them simple. Overcomplicating the plan with too many details or frequent updates can waste time. Remember, plans are always changing as the project progresses. As a project manager, spending too much time updating every detail can be counterproductive. Instead, focus on keeping the schedule straightforward and flexible to handle changes efficiently.

Identifying schedule constraints helps the project manager manage potential exceptions and avoid delays by adjusting timing and resource usage.

Estimating

Estimating is the process of predicting the cost, time, and resources required for a project using various techniques. Common techniques include:

• Top-down estimating
• Bottom-up estimating
• Comparative estimating
• Parametric estimating
• Data analytics
• Subject matter expertise

Let’s take a closer look at each technique.

Top-down estimation

Estimates are made for major products or work packages and then broken down into smaller components. This is useful for projects with stages or sprints.

Example: For a software project, estimate that development will take 6 months, then break it down into tasks like coding, testing, and deployment.

Bottom-up estimation

Estimates are made for individual tasks and then aggregated into overall estimates. Best for well-understood tasks.

Example: In-house construction, estimate the time for tasks like pouring concrete, laying bricks, and installing plumbing. Combine these estimates for a total construction time.

Comparative estimating

Estimates are based on similar projects or market data.

Example: If you’ve managed a similar project before, compare costs, such as using the same materials or methods, to estimate the new project.

Parametric estimating

It uses project data (like size or units) to calculate estimates and is often used in construction.

Example: In construction, estimate costs based on square meters or units, using industry standards or historical data.

Data analytics

Uses historical data and predictive models to improve estimates.

Example: For a manufacturing project, use past data to predict the time it takes to produce a part based on machine efficiency and other factors.

Subject matter expertise

Consensus techniques, like Delphi or planning poker, help experts agree on estimates.

Example: During project planning, consult engineers or architects to estimate technical tasks, using their expertise to form a consensus.

In larger projects, multiple techniques are often combined, and project managers may seek advice from cost estimation specialists.

Roles and responsibilities

In PRINCE2, clear roles and responsibilities are essential for effective planning and successful project execution. Each role plays a critical part in defining, managing, and ensuring the delivery of project objectives. This section outlines the specific responsibilities of key roles involved in the planning process, highlighting their contributions to creating, managing, and maintaining project plans.

• Business layer
  • Set project tolerances (listed in the project mandate), ensuring that the project is aligned with business objectives.
  • Approve project exception plans to ensure that any deviations from the original plan are properly addressed and that the project remains on track.
• Executive
  • Approve project plan, ensuring it aligns with the overall objectives of the organization and project goals.
  • Approve stage-level exception plans when deviations occur within a specific stage of the project.
  • Define tolerances for each stage, setting boundaries within which the project manager can operate without requiring further approval.
• Senior user
  • Provide necessary resources (personnel, expertise) to assist with product-based planning, ensuring that the user’s requirements and expectations are incorporated into the planning process.
  • Ensure that user expectations are reflected in the project deliverables and that the products meet the quality and functionality requirements.
• Senior supplier
  • Provide resources for both product-based planning and overall planning activities, ensuring that suppliers’ needs and constraints are considered.
  • Contribute specialized knowledge and expertise on resource capabilities, risks, and quality standards from a supplier’s perspective.
• Project manager
  • Facilitate the complete product-based planning process, ensuring that the entire team is involved and that all relevant details are addressed in the planning.
  • Write product descriptions and share responsibility with the team manager for detailing product requirements, including quality criteria, delivery methods, and acceptance criteria.
  • Create project and stage plans to outline the project scope, deliverables, and timelines. Prepare exception plans when necessary, in response to unforeseen deviations.
  • Update the project plan (during the stage boundary process) to reflect actuals, ensuring that the plan remains up-to-date and provides accurate tracking.
• Team manager
  • Assist the project manager with planning by providing input into resource and time requirements for the work packages.
  • Prepare team plans, outlining detailed steps for delivering work packages and ensuring that the team is clear on tasks, resources, and deadlines.
  • Share responsibility for writing product descriptions and developing the product flow diagram (PFD) to map the sequence and dependencies of products.
• Project assurance
  • Provide planning advice to the project manager, ensuring that the planning process aligns with the organization’s governance and quality standards.
  • Assure the project board that the quality management system (QMS) is being properly implemented and followed during the planning stages, helping to prevent issues that could affect product quality.
• Project support
  • Assist with the compilation of project plans and stage plans, ensuring that all necessary details are captured, documented, and tracked.
  • Help coordinate the collection of data, feedback, and resources necessary for accurate and timely updates to plans throughout the project lifecycle.

—o—

Written by Frank Turley.

If you have questions or doubts after using this wiki, you can ask for help on the Facebook or LinkedIn study groups.