How do you turn a project's big idea into a series of achievable steps without missing anything important? That's the problem the Plans theme solves. For your PRINCE2F exam, understanding how PRINCE2 structures planning—using product-based planning and different levels of plan—is essential for ensuring a project stays on track and delivers what it promised.
Jump to a section
A wedding is a complex project with a fixed date and a specific outcome: a successful celebration. The couple's vision is the project's goal. The wedding planner is the project manager, and their detailed plan is the roadmap to success. This plan is not a single document, but a set of nested plans that break down every aspect of the event.
The top-level plan is the 'project plan' for the entire wedding: it shows all major phases from engagement to honeymoon, with key milestones like booking the venue and sending invitations. Below this, the 'stage plan' covers a specific phase, like the reception. This stage plan includes smaller 'team plans' for the caterer, florist, and band. Each team plan uses a product-based approach: first, the caterer identifies the 'products' they must deliver (starter, main course, wedding cake). Then they define the steps to create each product, including all required ingredients and tasks (preparation, cooking, presentation). This method ensures every component is planned before work starts. Without these nested plans, the wedding would be chaotic: the band might arrive during dinner, or the cake might be left in the kitchen. The levels of plan ensure that everyone from the couple to the caterer knows their tasks and how they fit into the bigger picture, making the entire event manageable and successful.
The Plans theme is one of PRINCE2's seven core themes, and its purpose is to set out the steps needed to deliver the project's products and manage the work effectively. A 'theme' in PRINCE2 is an area of management that must be addressed throughout the project lifecycle. The Plans theme provides the framework for defining, sequencing, and resourcing all the work.
At its heart, the Plans theme introduces the concept of 'product-based planning'. This is a technique that starts by identifying and defining the products (the outputs) that the project must deliver, rather than starting with the tasks or activities. A 'product' can be any physical or digital deliverable, such as a user manual, a software module, or a training course. The key idea is to first answer 'what must we produce?' before answering 'how do we produce it?'. This approach reduces the risk of forgetting a crucial step because you've already defined the end result.
Product-based planning involves three main steps:
Writing a Project Product Description: This describes the final product of the entire project—its purpose, composition, and quality criteria. For a new mobile app, this document would specify the app's features, performance targets, and target platform.
Creating a Product Breakdown Structure (PBS): This is a hierarchical diagram that breaks the final product into its component products. For the app, the PBS might include sub-products like 'user login module', 'search functionality', and 'help documentation'. Breaking the product down helps ensure nothing is overlooked.
Producing a Product Flow Diagram (PFD): This diagram shows the order in which the products must be built and the dependencies between them. For example, you cannot create 'search functionality' until the 'database structure' product is complete.
After defining the products, you then identify the activities required to create each product, estimate the effort and resources needed, and schedule the work in a timeline. This leads to the creation of the 'plan' itself, which is a management product.
A management product is a document or record created to manage the project. Under the Plans theme, the key management product is simply called the 'plan'. However, PRINCE2 recognises that a single plan isn't enough for all projects. Instead, it defines different 'levels of plan' that correspond to the levels of management within the project management team.
The three levels of plan are:
The Project Plan: This is the top-level plan created by the Project Manager and approved by the Project Board. It covers the entire project lifecycle, from initiation to closure. It includes the major products, key milestones, cost estimates, and timeframes. The Project Plan is updated as the project progresses, but it provides the overall framework for decision-making.
The Stage Plan: PRINCE2 divides projects into management stages. Each stage has its own detailed plan, created by the Project Manager just before the stage begins. The Stage Plan covers only the work of that specific stage, with finer detail than the Project Plan. For example, the Stage Plan for a development stage might list each coding task and the developer assigned to it. This level of detail would be too granular for the Project Plan.
The Team Plan: This is an optional plan created by a Team Manager and used to plan the work for a specific team within a stage. It provides the most detailed level of activity planning, often used for specialist teams like software developers or marketing experts. The Team Plan feeds into the Stage Plan.
The purpose of having these levels is to allow different stakeholders to focus on the information relevant to them. The Project Board can look at the Project Plan for a high-level view of costs and timelines, while the Team Manager uses the Team Plan for day-to-day task management. This hierarchy prevents information overload and ensures that planning is appropriate for the decision-making level.
The Plans theme also emphasises that planning is not a one-time activity. It should be iterative—you refine your plans as more information becomes available. PRINCE2 recommends that planning should be done 'just in time' for the next stage, because detailed planning for work far in the future often becomes outdated quickly. This approach is pragmatic and reduces wasted effort.
In summary, the Plans theme provides the structure and processes for creating and maintaining plans throughout the project. It moves away from activity-based planning (starting with tasks) to product-based planning (starting with what you need to produce). The three levels of plan ensure that planning is appropriate for each management level, and the iterative nature of planning keeps the project adaptive to change. Without this theme, projects risk floundering because they lack a clear, shared roadmap that everyone understands.
Define the Project Product Description
Start by writing a clear description of the final product the project must deliver. This document includes the product's purpose, composition, and quality criteria. It ensures everyone understands what 'done' looks like before planning begins.
Create the Product Breakdown Structure (PBS)
Break down the final product into its component products in a hierarchy. For example, a mobile app might break down into login module, search function, and payment gateway. This step ensures no product is forgotten and helps define the scope.
Develop the Product Flow Diagram (PFD)
Map out the order in which the products must be created, showing dependencies. This diagram reveals critical paths and identifies which products must be completed before others can start.
Identify Activities and Dependencies
For each product in the PBS, list the activities required to create it. Estimate the effort and resources needed for each activity. This step bridges the 'what' (products) to the 'how' (tasks).
Create the Plan with Schedule and Budget
Consolidate the activities, dependencies, estimates, and resources into a single plan document. Include a timeline (schedule) and cost estimates (budget). This becomes the management product that guides execution.
Select the Appropriate Level of Plan
Decide whether you need a Project Plan (for the whole project), a Stage Plan (for the next management stage), or a Team Plan (for a specific team). Each level provides the right granularity for the audience.
An IT professional, say a Project Manager at a software consultancy, uses the Plans theme every time a new project kicks off. Let's step through a real-world scenario.
A client, 'MediConnect', asks the consultancy to build a mobile app that lets patients book GP appointments online. The Project Manager doesn't start by asking 'what tasks do we need to do?'. Instead, they apply product-based planning.
First, they write a Project Product Description for the app. This document defines the app's purpose (allow booking, cancellation, and reminders), its composition (login, booking, payment modules), and key quality criteria (response time under 2 seconds, meets UK data protection laws). This gives a clear, shared understanding of what 'done' looks like.
Next, they create a Product Breakdown Structure (PBS). They break the app into components: 'patient login module', 'search doctor function', 'booking engine', 'payment gateway', 'admin dashboard', and 'training materials for clinic staff'. Each of these is a product. They then create a Product Flow Diagram (PFD) showing the order: the 'patient login module' must be finished before the 'booking engine' can be built, because the engine needs user identity data. This diagram helps the team spot dependencies early.
With the product structure clear, the Project Manager now identifies activities. For the 'patient login module', the activities might be 'design database schema for user accounts', 'develop login API', 'code mobile login screen', 'test login and security', and 'write user guide for login'. They estimate each activity's effort in hours and assign resources (database developer, front-end developer, tester). The total cost is estimated.
The Project Manager then organises the work into management stages. The first stage might be 'Initiation', where the Project Manager creates the Project Plan using this data. The Project Plan shows the four-month timeline, key milestones (completion of each module), and overall budget of £250,000. The Project Board approves this high-level plan.
For the first detailed stage ('Set Up Infrastructure'), the Project Manager creates a Stage Plan. This plan lists specific tasks: 'set up cloud server', 'configure database', 'install development tools'. Each task has an owner and a deadline. The team works to this Stage Plan.
Midway through the project, the lead developer needs to coordinate work for two front-end and two back-end developers working on the 'booking engine'. The Project Manager might ask the developer to create a Team Plan. This Team Plan breaks the 'booking engine' product into daily tasks: 'task 1: design API endpoints', 'task 2: implement availability check', 'task 3: code booking confirmation page'. This granular plan helps the team manage their daily work without overwhelming the Project Manager with too much detail.
Throughout the project, the Project Manager regularly updates the Project Plan with actual costs and timelines. When the client requests an extra feature (e.g., video consultations), the Project Manager revisits the PBS, updates it to include a 'video consultation module', and recalculates the budget and schedule. They present the updated Project Plan to the Project Board for approval before proceeding.
In this scenario, the Plans theme gives the Project Manager a consistent, repeatable method for planning. It ensures that the client sees a clear end product first, that dependencies are understood before coding starts, and that every level of the team has the right amount of detail to work effectively. Without this structured approach, the project would likely miss requirements, cost more, and run late.
The PRINCE2F exam will test your understanding of the Plans theme in several specific ways. Here's exactly what to expect.
First, you need to memorise the purpose of the Plans theme. The exam gives four options; the correct one is always about 'defining the steps needed to deliver the products and managing the work'. Be careful with distractors like 'defining the budget' or 'allocating tasks'—those are partial truths but miss the plan's role.
Key definitions to know cold:
Product-based planning: a technique that begins with defining the required products before planning the activities. The exam might describe a scenario and ask 'what technique is the project manager using?' If the scenario mentions identifying products first, the answer is product-based planning.
Project Product Description: describes the final product of the entire project. The exam tests it as the document that defines what the project must deliver.
Product Breakdown Structure (PBS): a hierarchical breakdown of all products. The exam will ask you to identify it among other diagrams (like a Gantt chart or a PFD).
Product Flow Diagram (PFD): shows the order of creating products and dependencies. Expect a scenario question: 'Which diagram would the project manager use to understand the sequence of work?' Answer: Product Flow Diagram.
Plan: the management product that documents how the project will be executed. The exam distinguishes between the Project Plan, Stage Plan, and Team Plan. They love testing the difference between these levels.
Exam traps to watch for:
The exam will try to confuse you by applying the wrong level of plan to a situation. For example, they might say 'The Project Manager creates a detailed list of tasks for the next two weeks.' The correct answer is that this is a Stage Plan (or Team Plan if it's for a specific team), not a Project Plan. The Project Plan covers the whole project at a high level.
They might describe activity-based planning (starting with tasks) and ask what the project manager is doing. The correct answer is 'not following product-based planning'. PRINCE2 mandates product-based planning, so any scenario starting with tasks is a trap.
Regarding the Planning Horizon: the exam will state that detailed planning should be done 'just in time' for the next stage. They might ask 'Why does the Project Manager not write a detailed plan for stage 4?' Answer: because detailed plans for future stages are likely to change, so it's a waste of effort.
Concepts they love to test:
The three steps of product-based planning: Write Project Product Description, Create PBS, Create PFD. The exam will give a list of actions and ask you to select the correct sequence.
The four parts of a plan: description of products, activities, resources, and schedule. The exam may ask 'What is included in a plan?'
The difference between a management product (like the plan) and a specialist product (like the mobile app). The Plans theme produces a plan, which is a management product.
Final tip: read every scenario question carefully. If the question mentions 'planning before doing', they are testing whether you understand the purpose of the theme. If they mention 'breakdown of products', they are testing PBS. Always match the description to the specific term.
The purpose of the Plans theme is to define the steps needed to deliver the project's products and to manage the work effectively.
Product-based planning starts by identifying the required products, not the tasks.
The three levels of plan are Project Plan (whole project), Stage Plan (a management stage), and Team Plan (optional, for a specific team).
A Product Breakdown Structure (PBS) is a hierarchical list of all products the project must deliver.
A Product Flow Diagram (PFD) shows the order and dependencies of creating those products.
The Project Product Description describes the final product of the entire project.
Planning should be iterative and done 'just in time' for the next stage to avoid wasted effort on outdated details.
The plan itself is a management product, not a specialist product.
These come up on the exam all the time. Here's how to tell them apart.
Product Breakdown Structure (PBS)
Is a hierarchical list of all products needed.
Shows the breakdown of the final product into components.
Does not show the order or timing of product creation.
Product Flow Diagram (PFD)
Is a diagram showing the sequence of product creation.
Shows dependencies between products.
Reveals the order in which products must be built.
Project Plan
Covers the entire project from start to finish.
Includes high-level milestones and overall budget.
Created during the Initiating a Project process.
Stage Plan
Covers only one management stage.
Includes detailed tasks, resources, and timelines for that stage.
Created just before the stage begins, using 'just in time' planning.
Product-Based Planning
Starts by defining the required products first.
Reduces risk of missing activities by working backwards from outputs.
Mandated by PRINCE2 for all projects.
Activity-Based Planning
Starts by listing tasks or activities first.
Often leads to overlooked products and unclear scope.
Is not recommended in PRINCE2.
Management Product
Created to manage the project (e.g., a plan, a report).
Used by the project team for control and decision-making.
Does not directly deliver business benefit to the end user.
Specialist Product
Created to deliver the project's objectives (e.g., a software app, a manual).
Used by the end user or customer.
Delivers direct business value.
Mistake
The Project Plan is the only plan needed for the entire project.
Correct
PRINCE2 uses three levels of plan: Project Plan, Stage Plan, and Team Plan. Each level provides the right amount of detail for different management levels.
Beginners often think one big plan is enough because that's how many non-project-management jobs work. They don't realise that detailed plans change quickly and need to be separated by stage.
Mistake
Product-based planning means the same as creating a list of tasks.
Correct
Product-based planning starts with defining the products (outputs) before identifying the tasks (activities). It is the opposite of activity-based planning.
The word 'product' can be misinterpreted as a synonym for 'task' or 'work item'. Beginners confuse the 'what' (products) with the 'how' (activities).
Mistake
The Product Breakdown Structure (PBS) is the same as a Work Breakdown Structure (WBS) used in other methodologies.
Correct
The PBS focuses only on the products (outputs), not the tasks. A WBS typically includes both tasks and products. PRINCE2's PBS is purely product-oriented.
Many beginners come from backgrounds where 'breakdown structure' always means tasks. They see the word 'breakdown' and assume it's about activities.
Mistake
The Project Plan is created once and never changed.
Correct
The Project Plan is a living document that is regularly updated as the project progresses. It reflects actual costs, timelines, and any scope changes.
In everyday life, plans feel like fixed documents (like a holiday itinerary). Beginners don't realise that project plans are dynamic and updated iteratively.
Mistake
Team Plans are mandatory in every project.
Correct
Team Plans are optional. They are created only when the Project Manager or Team Manager determines there is a need for more detailed planning within a stage.
Since there are three levels, beginners assume all three must always be used. PRINCE2 is flexible; Team Plans are used only when beneficial.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Project Plan covers the entire project lifecycle at a high level, including major milestones and overall budget. The Stage Plan covers only one management stage in much greater detail, listing specific tasks and assignments.
No. The Project Plan is mandatory. Stage Plans are mandatory (one for each management stage). Team Plans are optional and used only when a team needs more detailed planning within a stage.
Product-based planning is a technique where you first define the products the project must deliver (using a Project Product Description, PBS, and PFD) before identifying the tasks. It is used to ensure nothing is overlooked and to clarify scope early.
The main management product is the 'plan' itself, which can be a Project Plan, Stage Plan, or Team Plan. Supporting documents include the Project Product Description, Product Breakdown Structure, and Product Flow Diagram.
No. The Project Product Description describes the final product of the entire project in words. The Product Breakdown Structure is a hierarchical diagram showing all component products that make up the final product.
Detailed plans for far-future stages often become outdated as new information emerges. Planning just in time reduces wasted effort and keeps the plan more accurate and relevant.
You've finished Plans Theme. Continue through the PRINCE2F study guide to build a complete picture of the exam.
Done with this chapter?