Plans

Project Managers who work in a Program Environment will be able to take advantage of how projects have been done in the past and get examples of how Project Plans are to be created. These standard plans or PRINCE2 Templates can be a great help.

PRINCE2 might give the impression that you need to know everything upfront before you create the Project Plan and Product Description for all products. This is possible with some projects, but with many IT projects, a more relaxed approach is required and each stage can be an iteration. So the Stage Boundary process can be used to create Product Descriptions for new products that will be created in the next stage.

One good thing to keep in mind is how you will communicate the Project Plan to the Project Board , as they are not interested in reading a 20- to 30-page document. You could ask the Executive how they want to receive this status information (ask about previous projects).

A good planning/tracking/reporting tool is the product checklist. This is easy to create, maintain and read and, most importantly, it is a good way to communicate with stakeholders that need this information. You will find an example of a product checklist later in this Theme.

One of the first things in planning is to try and get an idea of scope. It is very easy for a project to start off as a simple project, but when you start to draw out the requirements in a Product Breakdown Structure, it shows exactly what this so-called simple project involves. The Product Breakdown Structure makes it easy to discuss the scope and requirements with the Senior User.

Few Project Managers use the Product-Based Planning technique, especially the Product Breakdown Structure technique, which is a pity, as it is very useful. Perhaps the main reason for this is that Project Managers don’t get time to cover this in the training. Therefore, this manual includes a simple example and shows how you can use the indented list to help you get started. For the Foundation Exam, you just need to be aware how Product-Based Planning works.

The Plans Knowledge provided by PRINCE2

The purpose of the information in the Plans Theme is to provide a framework to design, develop and maintain the Project Plans, which are the Project Plan, Stage Plan, Exception Plan and Team Plan.

This Theme helps to answer the following questions:

• What is required?
• How it will be achieved and by whom?
• How to best go about creating the products?
• What will the steps be?
• How can Product-Based Planning be done?
• What Quality has to be reached?
• How much will it cost?
• What will be the level of detail required for each plan?

Remember, without a Plan there is no control, so a plan is required for the project. Failing to Plan is Planning to Fail

The very act of planning helps the Project Management team to think ahead and avoid duplication, omissions and threats. And remember, failing to plan is planning to fail.

Plans Definitions

Sometimes people think a plan is a Gantt chart, but it is much more than that. It is a document that describes how, when and by whom a specific target or set of targets is to be achieved. You might think the target is just to create the Project Product, but there will also be targets for time, cost, quality, scope, risk, benefits and, of course, products.

A plan must therefore contain sufficient information to show that these targets are achievable.

As you can imagine, the backbone for any project is the plan. It is created at the start of the project and continually updated during the project to show what has been realized so far (actuals) and what is still left to do. The original plan could also be compared to the plan during the project or the plan at the end of the project to see how well the project is doing in relation to the original plan. The original plan can also be known as the first baselined (signed off and dated) Plan.

A project plan answers these questions: Why, What, Who, When and How much

What is Planning?

Planning is the act or the process of making and maintaining the plan. The term planning is used to describe the actions used to create the plans and associated documents. Sometimes the planning stage can be rushed, as there is pressure to get started on creating the products that the customer wants to use.

Three levels of a Plan

It is often impossible to plan an entire project from the start, as you can only accurately plan in detail a short time in advance. This is called the planning horizon, i.e., as far ahead as you can see. It is therefore a good idea to have different levels of plans; PRINCE2 recommends three levels. The three types of plan are: Project Plan, Stage Plan and Team Plans.

• The Project Plan is used at the Direction Level and therefore is used by the Project Board. It is created during the Initiating a Project process and is a high-level plan for the whole project. It will show the major products of the project, when they will be delivered and the associated cost. It is a major control document for the Project Board. The Project Manager keeps the Project Plan up to date during the project.
• The Stage Plan is used at the Management Level. It is created for each stage (e.g., for a period of 2 months), and is used by the Project Manager on a day-to-day basis. It is much more detailed than the Project Plan and just focuses on one stage.
• The Team Plans are used at the Delivering Level. They are created and used by the Team Manager in the Managing Product Delivery process. The focus is to plan the work that is assigned to the Team Manager in Work Packages.

The other plans created during the project include the Exception Plan, which will replace an existing Project Plan or Stage Plan and the Benefits Management Approach, which is covered in the Business Case theme.

The Path to Planning

Here is a simple overview of the planning steps in a typical project. This will make it easier to understand when the plans are created and their value to the project. All Plans are explained in the following pages. I would suggest referring back to this diagram when reading the next few sections.

• Create the Project Product Description (PPD). Creating the PPD is the first part of Product-Based Planning.
• This is the Initiation Stage Plan; the Project Manager creates it. This is the day-to-day plan for the Initiation Stage, which is the 1st stage in the project. This Product-Based Planning technique can be used in the Starting up a Project , Initiating a Project and Managing a Stage Boundary processes. The following documents are produced by this technique
• Project Product Description (Only created in SU process). Product Descriptions are the responsibility of the Project Manager or Team Manager.
  • Create Product Breakdown Structure (PBS).
  • Create Product Descriptions (PDs).
  • Create Product Flow Diagram (PFD).
• The Project Plan is a high-level plan for the whole project. It provides the Business Case, Cost & Timescale information and needs to be approved by the Project Board. After approval, it is baselined (signed off and stored).

Stage Plans are created by the Project Manager and are produced near the end of the current stage for the next stage. It is a day-to-day level plan for the next stage.

• Exception Plans are plans that can be used to get the project or stage back on track if the project or stage goes out of tolerance. The Exception Plan picks up from where * the current plan left off and goes to the end of the plan.
• The Project Plan is updated in each Stage Boundary process, and it shows when and which products have been created in the last stage. The Project Plan is also updated to include any new planning information from the next Stage Plan and perhaps other forecast information.
• At the end of the project, the Project Plan is updated by the Project Manager. It shows the full cost and timescale for the project, and also showing what has been delivered. The Project Board can compare this plan to the original baselined plan to see how well the project went compared to the original plan.
• Team Plans are created by the Team Managers and they are optional.

The Project Plan

The Project Plan is a high-level plan and is mainly used by the Project Board. It provides a statement of how and when a project’s time, cost, scope and quality targets are to be achieved. The Project Plan shows the major products, activities and resources required for the project.

How is the Project Plan used by the Project Board? The Project Plan is used by the Project Board as a baseline against which to monitor the progress stage by stage. The Project Board can check the status of the project at the end of each stage to see how well the project is progressing in relation to the original Project Plan.

The Stage Plan

A Stage Plan is required for each stage in the project. The Stage Plan is similar to the Project Plan but is a lot more detailed, as the Project Manager will use this plan on a day-to-day basis. Remember, the Project Plan is a very high-level plan, as it is for the whole project.

Creating the Stage Plan: Each Stage Plan is produced near the end of the current management stage in the Stage Boundary process. One advantage of using stages is that it allows a big project to be broken up into manageable chunks. Some other project methods use sub-projects to break up larger projects.

Team Plans

Team Plans are produced by the Team Manager to plan the execution of one or more Work Packages. Team Plans are optional, depending on the project’s size, complexity and the number of resources involved in creating the products.

PRINCE2 does not provide a format for a Team Plan, and Teams can be from different suppliers who might have their own plan format. The Team Managers may create their Team Plans in parallel with the Project Manager as they create the Stage Plan.

The Exception Plan

An Exception Plan is used to recover from the effect of tolerance deviation (go out of tolerance). For instance, if during a stage, the Project Manager is forecast to go out of tolerance on cost by 15% (or does so), and then they must warn the Project Board about this deviation (also called “Exception”). The Project Board will most likely ask for an update plan to complete the current stage, and this plan (Exception Plan) will replace the current Stage Plan. So the Project Manager will create an Exception Plan and if approved by the Project Board, will replace the current Stage Plan to allow the Project Manager to complete the current stage.

An Exception Plan is created at the same level of detail as the plan it replaces. It picks up from where the current plan stopped until the work is done. Exception Plans can be used to replace Stage Plans and Project Plans, but not Team Plans.

Planning Steps

PRINCE2 has a unique approach to planning. It starts with identifying the products required and only then considers the activities, dependencies and resources required to deliver the products. Most other project methods and frameworks start with the activities. Perhaps you have heard the term “Work Breakdown Structure.”

The PRINCE2 approach to Plans has the following 7 steps that are easy to understand.

• Design the Plan: Should be called “Choose style and format of plan”
• Define and analyze products: Product-Based Planning is used to do this.
• Identify activities and dependencies: Activities to create the products.
• Prepare estimates: Estimate time and resources.
• Prepare the schedule: Put activities into a schedule and show sequence.
• Document the plan: Add narrative to explain plan using assumptions, lessons used, prerequisites, plan introduction, monitoring, control, budgets, and tolerances
• Analyze the risks: For each of the above steps, new information on new and existing risks will be uncovered and need to be followed up.

These steps are taken to create the Project Plan, the Stage Plan and perhaps some of the later steps can be taken to create the Team Plan.

Step 1: Design the Plan

I think this heading should be “Choose Plan Design,” as that is mostly what Project Managers do in the real world. If the project is part of a program, then the Programme will most likely have a common approach to planning, which could then be adopted by the project.

Some tips to consider for this step – Design the plan:

• Think of your audience and how they might access the data.
• Consider which tools to use for things such as estimating, planning and monitoring.
• The choice of planning tools is not obligatory but it can save a great deal of time and highlight potential issues, such as overuse of resources and dependencies issues.

Step 2: Product-Based Planning

PRINCE2 uses the technique Product-Based planning to identify and analyse the planned products. The four steps in Product-Based Planning are:

• Writing the Project Product Description: Describing the main product during the Starting up a Project process.
• Creating the product breakdown structure: Listing all products that need to be created.
• Writing the Product Description: Done for required products.
• Creating the Product Flow Diagram: Shows product flow and interdependencies.

Product-Based Planning is an iterative process and has a number of benefits:

• Clearly identifying and documenting the plan’s products and interdependencies.
• Clearly showing what the project involves; this avoids setting the wrong expectations.
• Involving users in supplying product requirements and thus increasing their support.
• Improving communications, as it provides a simple overview of what needs to be done, and makes it much easier to get feedback.
• Clarifying what is in and out of scope; this helps to avoid “scope creep.”
• And finally, it is easier to gain a clear agreement on what needs to be produced.

PBP Step 1: Write the Project Product Description

The very first step in Product-Based Planning is to write the Project Product Description. This is a description of the main product that the project will produce (for example, the “Apartment Block”). We already covered this in the Quality Theme and learned that a detailed Project Product Description is very important to understand what needs to be produced by the project and to understand the required quality.

The Senior User is responsible for providing the information on the Project Product Description. The Project Manager will coordinate most of the work in preparing this document. They will consult with the Senior User, Executive, and other specialists. The Project Product Description should be as detailed and complete as possible, and it can have the following format.

PBP Step 2: Create the Product Breakdown Structure

A Project Product is broken down into the major products which in turn are broken down into further products to give a hierarchical overview. This is called a Product Breakdown Structure (PBS). A “mind map” diagram could also be used. In fact, I would suggest that you start with a mind map. Don’t worry about how well you are doing this. If you can use the PBS to help explain how you see the parts of the project to another person, then you are on the right track.

You should consider the following points when creating a Product Breakdown Structure:

• It is a good idea to involve a group of people (workshop) who represent the different interests of the project, such as User, Supplier, and people having specific knowledge.
• Use Post-Its or a whiteboard, so it will be easier to make changes as you learn.
• Be open about the structure to use in the Product Breakdown Structure diagram, and decide on one by reaching a consensus with the others.
• Identify external products that will be used and use Circle or Ellipse to show this.

Product Breakdown Structure example for a book website:

PBP Step 3: Write the Product Descriptions

A Product Description is normally written for each of the identified products in the Product Breakdown Structure if required. Here are some things to consider when creating the Product Descriptions. Remember that Quality information forms a good part of these descriptions.

• Writing Product Descriptions should be started as soon as they have been identified and should involve all the necessary persons.
• Once the Project Plan is complete, all the Product Descriptions are baselined and have to pass via Change Control if changes need to be made.
• People who represent the Users should be involved in defining the Quality Criteria for the products and other Quality information.
• As projects are often similar in companies, some Product Descriptions from previous projects could be used instead of creating each Product Description from scratch.
• Refer to standards whenever possible instead of writing out the specification in detail.
• For small projects, it may be necessary to write only the Project Product Description.

PBP Step 4: Product Flow Diagram

A Product Flow diagram defines the sequence in which the products of the plan will be developed, and shows the dependencies between them. The diagram also shows the products that are outside the scope of the plan. Once this diagram is in place, the next steps would be to consider the activities that are required, as well as estimating and scheduling.

Here are some points to consider when creating a Product Flow diagram:

• The Project Manager should make sure to involve the other people who will help to deliver the products instead of trying to do this on his/her own.
• You can consider creating the Product Flow diagram at the same workshop meeting as the Product Breakdown Structure as you will have the people with the knowledge with you.
• Use symbols in the diagram (a rectangle for a product, an ellipse for an outside product).

A good example of a Product Flow Diagram is the assembly diagram that you get when you buy furniture at IKEA. Their diagrams show the steps you have to follow.

Step 3: Identify Activities and Dependencies

Activities: The objective is to make a list of activities that need to be done, and this is much easier now that you have the information from Product-Based Planning documents with the Product Breakdown Structure and Product Flow diagrams together with the Product Descriptions. Dependencies: Look for dependencies between the activities and note them. There are two types of dependencies – Internal and External – and there is a clue in the name. Internal dependencies are within the project, while external denotes outside.

Step 4: Prepare Estimates

Estimating is about deciding how much time and how many resources are required to carry out a piece of work to an acceptable standard. The Project Manager should do as little estimating as possible as, it’s better to ask someone who has more experience. So the Project Manager should facilitate a workshop and invite the necessary persons; this can be done in the same workshop as Product-Based Planning.

Estimating involves:

• Identifying the type of resource required, as specific skills are often crucial. Consider non-human resources, such as equipment (e.g., testing equipment), travel and money.
• Approximating the effort required for each activity, as we can never really guarantee an exact time for an activity.

Step 5: Prepare the schedule

This is the 5th step of the PRINCE2 approach to plans, there are many different approaches to scheduling and more and more people are using computer-based tools to help. The Project Manager must already have the list of all activities, their dependencies, and the duration of effort for activities before they can begin this task of scheduling. So, here are some of the steps that a Project Manager will accomplish:

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

If you have done scheduling before, you have covered most of these steps. It is just that PRINCE2 has given each of them a name and MS Project allows you to do most of them at one time.

Step 6: Document the Plan

Documenting the Plan is the 6th step in the PRINCE2 Approach to Plans. The objective is to add text similar to the following to help explain them:

• Plan Description: A text description of the Plan to help explain it.
• Plan prerequisites: Aspects that must be in place for the Plan to succeed.
• External dependencies: List of external dependencies that will influence the Plan.
• Planning assumptions: List of assumptions upon which the Plan is based.
• Lessons incorporated: Lessons from similar or previous projects.
• Monitoring and Control: Describe how the Plan will be monitored and controlled.
• Budget Information: Cost, time of project, provisions for Risk & Change Budget.
• Tolerances: Overview of tolerances for the 6 project variables.
• Risk: Overview of Risk.

The Product Checklist

The Product Checklist is a list of all the major products of a Plan, plus key delivery dates. The Product Checklist may most likely be a spreadsheet that will contain the following information:

• Product ID: Number and Product Title.
• Product Description: Plan Date when this will be ready and Actual Date.
• Product Draft: Plan & Actual dates for draft version of the product.
• Quality Check: Plan & Actual dates for Quality Check.
• Approved date: Plan & Actual dates for Approval.
• Handover date: Plan & Actual dates for handover (if this step is necessary).

I know some Project Managers who use the Product Checklist. It is a very simple way to communicate the progress of the project to stakeholders and is also my preferred planning tool.

Roles and Responsibilities

• Corp/Program
  • Set Project Tolerances (listed in the project mandate).
  • Approve Project Exception Plans.
• Executive
  • Approve Project Plan and can approve Stage-Level Exceptions Plans.
  • Define tolerances for each stage.
• Senior User
  • Provide resources to assist with Product-Based Planning.
• Senior Supplier
  • Provide resources to assist with Product-Based Planning & Planning.
• Project Manager
  • Facilitate complete Product-Based Planning process.
  • Write Product Descriptions (share responsibility with Team Manager).
  • Create Project and Stage Plans plus Exception Plans if necessary.
  • Update Project Plan (during the SB process) to show actuals to date./
• Team Manager
  • Assist Project Manager with Planning and prepare Team Plans.
  • Share responsibility for writing Product Descriptions and PFD.
• Project Assurance
  • Give Planning advice to Project Manager.
  • Assure the Project Board on the implementation of the QMS.
• Project Support
  • Assist with compilation of Project Plans and Stage Plans