PRINCE2 Foundation and Practitioner - Plans Theme Tutorial

7.1 Plans Theme

Hello and welcome to PRINCE2 Foundation Certification Course offered by Simplilearn. This lesson is about Plans, which is one of the seven themes of PRINCE2 methodology. This theme is based on the principle “Focus on Products”. Planning is important to ensure the success of the project. Let us discuss the objectives of this lesson in the next screen.

7.2 Objectives

After completing this lesson, you will be able to: Define the Plans theme Explain the PRINCE2® approach to Plans theme Define the roles and responsibilities in Plans theme Let’s look at the purpose of Plans theme in the next screen.

7.3 Purpose of Plans Theme

The purpose of the Plans theme is to facilitate communication and control by defining the means of delivering the products. The Plans theme provides a framework to design, develop and maintain the project’s plan. The Plans are also baselined to measure progress against it. Effective project management relies on effective planning. Without a plan there is no control. The targets of Plan are: time, cost, quality, scope, risk and benefits. Planning provides all personnel involved in the project with information on: What is required; How it will be achieved and by whom, what specialist equipment and resources will be used; When events will occur and Whether the targets for time, cost, quality, scope, risk and benefits are achievable. In the next screen we will look at the key definitions associated with plan.

7.4 Plans Terms—Definitions

A PRINCE2 plan is a document describing how, when and by whom a specific target or set of targets is to be achieved. These targets will include the project’s products, timeframes, costs, quality and benefits. A Plan is the backbone of the management information system required for any project. It is important that plans are kept in line with the Business Case at all times. A plan requires the approval and commitments of the relevant levels of the project management team. Planning is the process of making and maintaining a plan and it is crucial, regardless of the type or size of the project. Without effective planning, the result of complex projects cannot be predicted in terms of scope quality, risk, timescale, cost and benefits. It is, therefore, essential to allocate sufficient time for the Planning stage. PRINCE2 requires a product-based approach to planning. Let us look at the levels of plan in the next screen.

7.5 Levels of Plan

PRINCE2 suggests that there should be different plans at different levels for effective project management. As seen in the image on the screen, project plan is created during ‘initiating a project’ process. Plans must be produced at different levels of scope and detail. The period of time for which it is possible to accurately plan is known as the planning horizon. Due to this, it is seldom desirable, or possible, to plan an entire project in detail at the start. Initiation stage plan is created during the ‘starting up a project’ process. PRINCE2 recommends three levels of plan to reflect the needs of the different levels of management involved in the project, stage and team. Team plans are created during the managing product delivery process. Let us discuss project plan in the following screen.

7.6 Project Plan

The Project Plan provides a statement of how and when a project’s time, cost, scope and quality performance targets are to be achieved, by showing the major products, activities and resources required for the project. A Project Plan includes Costs, Efforts, Timelines, Quality milestones and Baselines to monitor project progress. We will continue our discussion on project plan in the next screen.

7.7 Project Plan (contd.)

The Project Plan is created by the Initiating a Project process and lists the management stages. The Project Plan is used by the project board as baseline to monitor project progress stage by stage. It is prepared in sync with the corporate or programme management plan. Let’s look at the stage plans in the following screen.

7.8 Stage Plan

The Stage Plan is similar to the Project Plan in content, but each element is broken down to the level of detail required to be an adequate basis for day-to-day control by the Project Manager. A Stage Plan is required for each management stage. The Stage Plan is based on the project plan, however it exists for a shorter duration than the project plan. This plan depends on the performance of previous management stages and is created for the next management stage and at the near end of the current one. The initiation Stage Plan is created by the “Starting Up a Project” process and each subsequent Stage Plan is created by the “Managing a Stage Boundary” process. Team Plans are created by the “Managing Product Delivery” process. In the next screen we will discuss team plans.

7.9 Team Plan

A team plan is created to facilitate the execution of one or more Work Packages. Team plans are optional; their need and number will be determined by the size and complexity of the project and the number of resources involved. PRINCE2 does not prescribe the format or composition of Team Plan. The Team Plan is produced by the team Manager. The formality of the Team Plan could vary from simply appending a schedule to the Work Package, to a fully-formed plan in similar style as a Stage Plan. The Team Managers may create their Team Plans in parallel to the Project Manager creating the Stage Plan for the management stage. The Team Plan should be reviewed and approved by the Project Manager and Senior Supplier. In the following screen, we will learn about one of the important plans, i.e. Exception Plan.

7.10 Exception Plans

Exception Plan is created to handle situations when the tolerances are forecasted to exceed or have already exceeded. Project Plan, Stage Plan, Team Plans and Exception Plans are different types of Plan. It details the actions to be taken to control the situation in a project It is prepared for the appropriate management level to show the actions required to recover from the effects of a tolerance deviation. If approved, the Exception Plan will replace the plan that is in exception and it will become the new baseline Project Plan or current Stage Plan, as appropriate. Exception Plan is produced by the Project Manager. So exception may occur at the stage level or at the project level. When the exceptional situation occurs, working as per the plan that was prepared before is not feasible as project or stage plan is no longer valid. There is a need to prepare a different plan to replace the current one. If a Stage Plan is replaced with Exception Plan, this will require the approval of the Project Board. Replacement of a Project Plan should be referred by the Project Board to corporate or program management if it is beyond the authority of the Project Board. An Exception Plan picks up from the current plan actuals and continues to the end of that plan. It is prepared with the same level of details as the plan it replaces. The Exception Plans are not produced for Work Packages. If a Team Manager forecasts that the assigned Work Package may exceed tolerances, they will notify the Project Manager by raising an issue. Let us learn about the PRINCE2 approach to the plans in the following screen.

7.11 PRINCE2® Approach to Plans

Let’s first understand the philosophy behind PRINCE2 approach to plans. The products required are identified first, and only then the activities, dependencies and resources required to deliver those products identified. This is known as product-based planning. The image on the screen illustrates the steps involved in preparing a PRINCE2 plan. The first step in preparing the Plan is Design the Plan, which means agreeing on a format and layout of the plan. This is also a pre-requisite step for planning. The next step is to define and analyse the various products that are required to be built as part of the project. When the products are identified, both the specialist as well as management products of the project will have to be identified. Specialist products are the products whose development is the subject of the plan, and management products are the products required as part of managing the project and establishing and maintaining quality. The management products are highlight reports, project issues, risk register, quality management strategy, etc. Management products are usually items of paperwork that are necessary to ensure the project remains in control and its products satisfy the expectations of the customer. Once the product identification is over, the next step is to identify the activities and dependencies required to deliver those products. The next step is to prepare estimates followed by schedule. The last step is to document the plan. This is known as product-based planning and is used for the Project Plan, Stage Plan and optionally, the Team Plan. Analysis of the risks involved occurs during the ‘Define and analyse the products’ step and continues till the Schedule is prepared. It is highly recommended that user community, which is represented by senior user, be involved in specifying the product requirements thus increasing buy-in and reducing approval disputes. Let’s learn the first step, which is Design the Plan, which is a pre-requisite, in the following screen.

7.12 Design the Plan

Designing the plan is a pre-requisite of planning. Decisions need to be taken about how the plan can best be presented to the audience who will use the plan and how it will be used. In some cases, where the Project is part of a programme, the programme may have developed a common approach to project planning. This may cover standards, for example, levels of planning, estimation methods, presentation layout and tools. These tools will be the starting point for designing any Project Plan. In the following screen, we will look at the next step, which is define and analyse the products.

7.13 Define and Analyse the Products

PRINCE2 follows product-based planning technique, which is likely to be iterative. As seen in the image on the screen, the first step of this technique is to write the project product description. This means, clearly identifying what the project intends to build. The next step is to create the product breakdown structure for management and specialist products. This means identifying all the intermediate deliverables that need to be produced to get the final project output. The next step is to write the product description, which is elaborating the intermediate deliverables of the project. The components of the intermediate deliverables can be better demonstrated graphically in the form of product flow diagrams. Hence, creating product flow diagram is the last step of this technique. Let’s move on to the next step of PRINCE2 approach to plans, i.e. identifying activities and dependencies.

7.14 Identify Activities

The activities required to create or change each planned product need to be identified to give a complete picture of the plan’s workload. The activities should include management and quality-checking activities as well as the activities needed to develop the specialist products. A Work Breakdown Structure is created, based on the Product Breakdown structure, to define the activities required. In the following screen, we will discuss dependencies.

7.15 Identify Dependencies

The activities cannot be performed simultaneously. In almost all the projects some activities are dependent on others and hence, any dependency between activities and products should also be identified. The dependencies could be on both internal and external factors. For example, as part of a project to build a desktop computer in under 150 Pounds, the RAM Cards will be designed only after the Motherboard is designed (internal dependency). However, the mouse, supplied by the manufacturer can be procured before the design (external dependency) as they will fit into standard USB slots. Let us discuss an example of identifying dependencies in the following screen.

7.16 Identify Dependencies—Example

The 787 Boeing Dreamliner project involved multiple external dependencies including wing manufacture (Mitsubishi Heavy Industries, Japan), cargo doors, access doors, and crew escape door (Saab AB, Sweden), software development (HCL Enterprise, India), and floor beams (TAL Manufacturing Solutions Limited, India). Though the project was supposed to be over before August, 2007, the project was delayed more than 5 times. The reasons included fastener shortage, and incomplete software. Let us learn about preparing estimates in the next screen.

7.17 Prepare the Estimates

Prepare the estimates is based on the estimating methods decided in the first step, i.e. Design the Plan. A decision about the time and resources required to carry out an activity to acceptable standards of performance must be made by identifying the type of resources required and estimating the effort required for each activity by resource type. Specific skills may be required depending on the type and complexity of the plan. Requirements may include non-human resources, such as equipment, travel or money. Resource requirements are estimated, post which the effort required for each activity by the resource is estimated. Based on the time and resource estimates, cost is calculated. The budget should include cost of the activities to develop and verify the specialist products and the cost of the project management activities. An example is three point estimating where the best, likely and the worst case are estimated. Another example is the Delphi technique, which is questionnaire based. We will look at the ‘prepare schedule’ method in the following screen.

7.18 Prepare the Schedule

A plan can only show the ultimate feasibility of achieving its objectives when the activities are put together in a schedule that defines when each activity will be carried out. The steps to prepare the schedule are: define activity sequence, which is a critical path method; assess resource availability; assign resources; level resource usage; agree control points; define milestones; calculate total resource requirements and costs and finally, present the schedule. Gantt chart is an example of a scheduling tool. We will continue our discussion on preparing the schedule in the following screen.

7.19 Prepare the Schedule (contd.)

A schedule defines when each activity will be carried out in a plan. A schedule is best presented in a graphical form. There are a number of ways of presenting a schedule to suit the need of the people who will use it. Most planning tools like Microsoft Project or Primavera offer a choice of formats to view the schedule. The image on the screen demonstrates a sample format of schedule. This way of representing schedule is called Activity On node, as each of the node in the diagram is an activity. Let’s now learn about analysing the risks in the next screen.

7.20 Analyse the Risks

Analyse the Risks is the planning activity that will usually run parallel with the other steps, as risks may be identified at any point in the creation or revision of a plan. Each resource and activity and all the planning information should be examined for its potential risk content. All identified risks should be entered in the Risk Register. We will discuss how to document the plan in the next screen.

7.21 Document the Plan

Document the plan: A narrative must be added to explain the plan—its constraints, external dependencies, assumptions made, any monitoring and control required, the risks identified and their required responses. It is a good idea to have one Plan format for seeking required approval on the plan and a more detailed format for day-to-day control purposes. It is necessary to keep plans as simple as it is appropriate. Let us move on to the benefits of product-based planning technique in the next screen.

7.22 Benefits of Product-based Planning Technique

The key benefits of Product-based Planning Technique are: Comprehensive identification and documentation of the plan’s products and the interdependencies between them. Reduces the risk of important scope aspects being neglected or overlooked. Involves users in specifying the product requirements. Increases user buy-in and reduces approval disputes. Clarifies the scope boundary. Identifies external products and helps in preparing the work packages for suppliers. In the next screen, let us discuss an example of product-based planning.

7.23 Product-based Planning—Scenario

A project is required to organise and run a conference for 80 to 100 delegates. The date and the topics of the conference have been provided. The conference has been organised to bring members of a particular profession up-to-date on recent developments in professional procedures and standards. All delegates will be members of the profession, and a mailing list is available for use. The project team is responsible for: Identifying the venue, Finding out availability of the venue and facilities and checking the price. The venue will be booked depending on the availability and price. The project team must identify the suitable speakers, contact them and book them for the conference. We will continue our discussion on the other aspects of this example in the next screen.

7.24 Product-based Planning—Scenario (contd.)

A detailed agenda and programme must be identified after finalising the speakers. Booking arrangements must be established, the programme must be agreed on, and the venue must be selected and booked before the direct mail is sent out. Once the venue is booked, a press release based on the programme must be prepared and issued. The attendance list will be updated with the responses once the press release has been issued and the direct mail distributed. Staff must be recruited to help on the day, based on the finalised attendance list. We will continue our discussion on the other aspects of this example in the next screen.

7.25 Product-based Planning—Scenario (contd.)

For the conference, it is decided that hand-out packets will be distributed. A hand-out packet should reflect the selected topic or subject matter. One hundred such delegate hand-out packets will be required. The packets must contain: a printed agenda covering the agreed upon program, copies of slides and notes used by the speakers and a feedback form, based on the programme, to capture attendee reviews. Let’s look at the conference project in project product description in the next screen.

7.26 Example of Product-based Planning—Project Product Description

Project Product description is one of the management products. It is a special form of a product description and defines what the project must deliver so that the project’s product is accepted. The sections of project product description are Purpose, Composition, Derivation, Development Skills Required, Customer’s Quality Expectations, Acceptance Criteria and Project-level Quality Tolerances (In priority order), Acceptance Method and Acceptance Responsibilities. Click each tab to understand the composition of Project Product Description. Example of Product-based Planning—Project Product Description The purpose section defines the purpose of project’s product. The “Purpose” of “Conference Project” states that the conference is organised to bring members of a particular profession up-to-date on recent developments in professional procedures and standards. Example of Product-based Planning—Project Product Description The composition section describes the major products delivered by the project. The conference is composed of conference venue, attendees, speakers, publicity, delegate hand-outs and conference logistics. Example of Product-based Planning—Project Product Description The sub products from which this product is derived is defined as derivation. In this example, derivation section includes Selected Subject Matter, Marketing and Public Relations. Example of Product-based Planning—Project Product Description The development skills required are conference management, marketing and public relations. Example of Product-based Planning—Project Product Description The customer quality expectations are one of the most important sections because it impacts every part of the product development and so the time and cost. The quality expectations are captured during the discussion with the customer. PRINCE2 suggests that wherever possible, prioritise the expectations. In this example, the first priority customer quality expectations are: professional in style funded by attendees and address the needs of the range of members from beginners to experienced professionals. The event should provide a forum for networking and repeat attendance at future conferences is generated from satisfied members. The second priority customer quality expectations are: The speakers should be chosen on the basis of their knowledge, experience and expertise as they are not delivering a ‘sales pitch’ to the members. The conference should be interactive in style and the conference should be held at a central location, therefore minimising travel. Example of Product-based Planning—Project Product Description The acceptance criteria and project-level tolerances are described in the Project Product Description. Acceptance criteria is a list of criteria that project’s product must meet before the customer will accept it, such as the cost of the conference must be covered by the attendance fees and minimum of 80 and maximum of 100 delegates must attend the conference. The other criteria are that more than 50 percent of the presentations should be interactive, the speakers and programme must be approved by the editorial board representing the interests of the members and the attendees’ satisfaction survey should indicate that more than 75 percent will attend next year’s conference and/or recommend it to their colleagues. Project-level quality tolerances specify any tolerances that may apply for the acceptance criteria such as the hotel venue should be within three miles of a main line train station. Example of Product-based Planning—Project Product Description The acceptance method describes the means by which acceptance will be confirmed. As the conference cannot be rerun if it is proven to be unacceptable, the project board will grant two forms of acceptance. Preliminary acceptance is based on approval of the agreed programme by the editorial board and independent assurance that the attendee numbers and conference costs re-forecast will be acceptable. Final acceptance is based on the end project report providing evidence that the acceptance criteria were met. Example of Product-based Planning—Project Product Description The acceptance responsibilities define who will be responsible for confirming the acceptance. In this example, the Project Board has decided to grant the preliminary acceptance and then the final acceptance. So depending on the arrangements made and number of delegates expected to join, the project board will decide whether to go ahead with the project. The Senior User and the Executive are responsible for confirming the acceptance. Let us discuss an example of Product-based Planning, which is Product Breakdown Structure, in the following screen.

7.27 Example of Product-based Planning—Product Breakdown Structure

PRINCE2 does not recommend any specific format for Product Breakdown Structure. In the hierarchy chart, the various components of the product are shown in a hierarchical manner. For arranging the conference, Venue, Attendees, Speaker, etc are needed. If the product “Venue” is further classified, then the venue requirements, candidate venues, etc have to be determined. As seen in the image on the screen, this structure includes the project’s products, external products and the product group. For example, mailing list is an external product as it will be available for this project by other sources which are outside the boundary of this project. In the next screen we will discuss the mind map technique to prepare a product breakdown structure.

7.28 Example of Product-based Planning—Product Breakdown Structure (contd.)

Mind Map technique can be applied to prepare a product breakdown structure. The external and internal products can be represented by using different formats. The image on the screen illustrates a mind map by utilising the same example. Irrespective of whether hierarchy chart, mind map or just a list of the products is used, all the project’s products should be covered. The decision of whether to include the smallest product of the project or only consider the products up to a certain level will depend on the project and the complexity of the products. Extra detailing may also require more time and incur more cost. Let’s look at the product flow diagram in the next slide.

7.29 Example of Product-based Planning—Product Flow Diagram

The product breakdown structure does not depict the dependencies between various products of the projects. For example, the conference cannot be run unless the venue is finalised. The delegate hand-outs cannot be printed unless the agenda of the conference is finalised. A mechanism or a tool is required to depict the dependences pictorially. A product flow diagram must be created to identify and define the sequence in which the products of the plan will be developed and any dependencies between them. The product flow diagram also identifies dependencies on any products outside the scope of the plan. It leads naturally into consideration of the activities required, and provides the information for other planning techniques, such as estimating and scheduling. When creating a product flow diagram, consider the following: Some planners prefer to create the product flow diagram in parallel with the product breakdown structure. A product flow diagram needs few symbol. Each product to be developed within the plan is identified. For example, it may be enclosed in rectangles. Any products that already exist or that come from work outside the scope of the plan should be clearly identified as external products. For example, it may be enclosed in a different shape, such as an ellipse. The image on the screen represent the product flow diagram based on the above discussed example. Let us look at the different responsibilities in the next screen.

7.30 Roles and Responsibilities in Plans Theme

The table on the screen depicts the responsibilities of corporate or programme management in Plans Theme. The corporate or programme management set project tolerances and document them in the project mandate. They approve exception plans when project-level tolerances are forecast to be exceeded and provide the corporate or programme management planning standards. The Executive approve the Project Plan, define tolerances for each stage and approve stage plans. Executive is also responsible for approving exception plans when stage-level tolerances are forecast to be exceeded and committing business resources to stage plans (i.e., finance). Senior users ensure that Project Plans and stage plans remain consistent from the user perspective and commit user resources to stage plans. We will continue our discussion on the roles and responsibilities in the next slide. The senior suppliers ensure that the project and stage plans remain consistent from the supplier perspectives and commit supplier resources to stage plans. Project managers design the plans, prepare project and stage plans and decide how management and technical stages are to be applied and design stage plans. Project Managers also instruct corrective action when work package-level tolerances are forecast to be exceeded and prepare an exception plan to implement corporate management, programme management or the project board’s decision in response to exception reports. We will continue our discussion on the roles and responsibilities in the next slide. Team managers prepare team plans and schedules for each work package. Project assurance monitor changes to the project plan to see whether there is any impact on the needs of the business or the project business case. They also monitor stage and project progress against agreed tolerances. Project support assist with the compilation of project plans, stage plans and team plans. They contribute specialist expertise (for example: planning tools) and baseline, store and distribute project plans, stage plans and team plans. Let us move on to the quiz questions to check your understanding of the concepts covered in this lesson.

7.32 Summary

Here is a quick recap of what we have learnt in this lesson: The purpose of Plan theme is to facilitate communication and control by defining the means of delivering the products A Plan is a document describing how, when and by whom a specific target or set of targets is to be achieved Designing the plan is a pre-requisite of planning Hierarchy Chart and Mind Map are the two formats of Product Breakdown Structure

7.33 Thank you

In the next lesson, we will discuss the next theme, which is Risk.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*