PRINCE2 Plans - complete
Plans
There are 3 levels of plans in PRINCE2 projects.
The Project Plan
A Project Plan must be produced for the Project, but as the accuracy of information about aspects of the project which are further away in time are poor, it does not provide detail of every element of the project at the start. This detail is added in Stage Plans for each stage.
The Project Plan is a high level plan which sets out the major products to be produced; the timescale, activities and resources for production.
If the project is part of a programme or corporate strategic plan, the Project Plan should align with this plan.
The Project Plan will feed into the Business Case, with the costs and timescales for the project.
The Project Plan is used by the Project Board as the baseline against which to monitor and control the project. It will have the major control points of stages identified with the associated milestones.
The Project Plan is produced in Initiating a Project and then updated at the end of every Stage in Managing a Stage Boundary.
The Project Plan is the basis for planning Stages to deliver the project.
Stage Plan
A Stage Plan is required for every management stage in the project.
The Stage Plan provides sufficient detail to enable the Project Manager to undertake the day to day monitoring and control of the stage.
The Stage Plan format is the same as the Project Plan, but provides more detail for the stage being entered into.
Each stage is planned near to the end of the current stage. This enables the Project Manager to take account of the performance of the project to date and consider up to date information about the events in the next stage.
At the end of Starting Up a Project the Stage Plan for Initiation (Stage 1) is produced and then toward the end of Initiation the Stage Plan for the next stage (stage 2) is produced.
The Project Board authorize the Stage Plans in Directing a Project and receive Highlight Reports from the Project Manager to monitor progress of the stage against the Stage Plan.
The Stage Plan is the basis for planning Work Packages to deliver the stage.
Team Plan
The Team Plan is the only optional plan. Decisions about whether Team Plans will be produced, will depend on the size and complexity of the project; as well as the number and location of resources involved.
The format of Team Plans is not prescribed by PRINCE2®. If the team is from an external supplier it may be inappropriate for their plan to be authorized by the Project Manager. This applies more particularly where there is an output contract in place, specifying the products to be delivered with the timescales, quality and costs. How the team achieves it is for them.
Team Managers will finalize Team Plans in the Managing Product Delivery process as part of the Accept a Work Package activity. The Team Plans may be created in parallel to the Stage Plan being produced, or be informed by the Stage Plan which has been agreed.
If teams Plans are used, the Project Manager will authorize them during the activity Authorize a Work Package. They will also be monitored by the Project Manager through the receipt of Checkpoint Reports from the Team Manager.
The Team Plan shows the basis on which work is to be carried out to produce products.
Exception Plan
If a plan is forecast that it can no longer complete within tolerances, a replacement plan is produced. This is the Exception Plan. It will plan the actions required to recover from the deviation, or take a new direction, as agreed with the Project Board.
An Exception Report will trigger the Project Board to request an Exception Plan in Ad Hoc Direction. The Exception Plan will be produced in Managing a Stage Boundary and will be produced at the same level as the plan it replaces.
Most Exception Plans replace Stage Plans. There are times, however, when an exception situation will forecast the Project Plan to exceed tolerances and in this situation the Exception Plan would need to replace the Project Plan. If Work Packages are forecast to exceed tolerances the Team Manager should inform the Project Manager immediately by raising an issue. Corrective Action would be agreed between the Team Manager and Project Manager to amend a Work Package or create a new one. Only if the issue cannot be resolved within Stage Tolerances would the Project Manager then escalate the issue to the Project Board in an Exception Report.
Exception Plans require authorization in the same way as other plans. If the Exception Plan is at stage level then the Project Board will authorize the Exception Plan in DP. If, however, the exception is at project level then the Exception Plan would need to be authorized at corporate or programme level as they set the project tolerances and need to agree actions to recover from the deviation.
Planning Procedure
There are seven steps to produce a PRINCE2® plan. They need to be carried out with an understanding that planning is iterative and earlier steps will be amended as more information is available.
The PRINCE2® philosophy is that the products to be produced during the plan will first be identified and these drive the planning. The technique of Product Based Planning is used to identify the products and the dependencies between them. Once this has been done the activities needed to produce the products can then be considered and planned, taking account of the dependencies between the activities, estimates of how long things take and resource availability.
There are six steps which have a logical order, but will also be iterative as the plan develops. Running through all six is the need to consider risks. The risks will be from the development of the plan, e.g. Many activities on the critical path; or inherent in the activities e.g. Using unstable chemicals in a new process.
Design Plan
A pre-requisite of planning, for decisions to be taken about how best to present the plan.
When designing the plan there are several factors to take into account to produce a plan which is acceptable and useful to those who will need to use it. These factors include:
Standards – does the plan need to adhere to any specific standards. The standards could be organization wide, specific to a programme or considered for this project. Standards can include presentation and format as well as content. E.g. the use of diagrams vs text.
Audience – the audience for the plan will dictate the level of detail required in the plan. It will also influence how it is presented. E.g. Microsoft project plan or excel spreadsheet.
Programme – is there a programme plan that this plan needs to align with and standards within the programme.
Tools – PRINCE2® does not dictate that any tools need to be used, but the use of software in complex projects can be a big help.
Estimating methods – all plans rely on estimating the effort and duration of work to be done in producing products. Some organisations or industries have recognised estimating methods which can be used, some projects will, however need other methods identified and agreed.
Plan is a single management product with the same composition shown in Appendix A of the manual for all levels of plan.
Define and analyse the products
This step of the planning procedure is where the product based planning technique is used to identify and define products. There are four steps in product based planning and they will be considered following completion of the planning procedure.
The first step – to produce the Project Product Description – will have been undertaken in Start Up and will be used when creating the Project Plan. The next three steps are undertaken at stage level, and, if the PRINCE2® format is adopted, also at team level. The Project Product Description is checked to confirm the final outputs of the project. It describes what the project is going to produce. The Acceptance Criteria in it are critical, as they will be used when handing over the project to business as usual and, need to be met before the project can be confirmed as delivered as agreed.
The Product Breakdown Structure and Product Flow Diagram can be produced in parallel, if preferred, but will certainly influence each other. The Product Breakdown Structure is likely to require amendment as a result of the Product Flow Diagram being produced, so iterative development is the most likely.
Product Descriptions should be produced for each product identified in the Product Breakdown Structure and are needed in order to quality check the products produced.
Define Activities and dependencies
Once the products have been identified, activities are needed in order to produce them. These activities also need to be planned and dependencies between them shown.
The Product Flow Diagram is a good starting point for the activities; or the Product Breakdown Structure can be used as the basis for creating a work breakdown structure identifying the tasks to be undertaken.
When looking at activities those which are external dependencies need to be part of the plan as well as the internal ones. Interactions with external parties should be included in the plan as well.
The activities should remain at the level of detail of the plan and a tendency to proliferate the activities to a greater detail avoided. Aim to keep things simple.
Prepare estimates
Estimating is a difficult task and too often is taken as the baseline against which to judge performance. There are a number of reasons that estimating is difficult. Often the users are not as clear at the beginning of a project and make a number of seemingly minor changes as the project progresses. Each of these changes produce impacts on the estimates.
Although estimates are not accurate, they will give a picture for the plan. There are a number of methods to estimate and no single method is correct in all situations.
Top down – an overall estimate sub-divided across the plan.
Bottom Up – each individual piece of work is estimated by those doing it and then summed together. A combination of top-down and bottom up can be used as well.
Comparative – using historical data to compare and provide inputs to estimate for the project.
Parametric – based on data measured and accepted in order to predict.
Single-point – sample data to give a single best guess
Three-point – skilled input to give best, worst and most likely figures. A weighted average is taken.
Delphi – group input to reach consensus based on a series of questionnaires and feedback.
Prepare schedule
With an understanding of the products to be delivered, activities to produce them and estimates of the effort and duration to do so, a schedule can be produced.
The schedule identifies whether the plan is feasible and can be delivered. Often planning tools are used to input the resource availability and then the tool can produce the schedule.
The schedule will need to take into account the types of resources needed, their availability, what activities can be delayed without affecting the critical path and where the controls need to be.
Costs are derived from the resources, duration of usage and other costs associated with delivering the products. In addition the plan should show the risk budget, change budget and tolerances. The total budget for the plan is made up of all these elements.
Breaking a plan into milestones can give the Project Manager an early indication of issues which might impact on the successful completion of the plan.
Analyse risks and document the plan
Risks are continually being identified in the project. As planning is done in parallel with other work risks will arise both from the plan and the wider environment. The plan will be draft until these risks have been analysed and where needed, plans amended as a result.
Each activity of the plan and associated resources needs to be looked at for potential risks. Any risks which are found should be entered in the Risk Register.
Risks can arise from many activities being done in parallel; many resources being added at the same time; 100% of people’s time being allocated to the project without any time off allowed or most activities being on the critical path. Risks can also be inherent in the activity or due to dependencies on external products.
The plan will need to be documented and consists of more than just a chart. Explanations are required of any assumptions made, constraints on the plan, external dependencies and pre-requisites.
The monitoring and control points need to be added as well as the tolerances available. Tolerances of time, cost, scope and risk can be applied to plans and will vary according to the priorities of the corporate organization and the needs of the project.
Presentation of plans will vary depending on the organization but should have been considered in the design a plan activity of PL.
Product Based Planning
Product Based Planning is a technique used in to ‘Define and Analyse the Products’. In this activity the technique provides a product based focus to begin planning.
There are many benefits to product based planning, but the most important is to understand what needs to be delivered and clarify the scope. It can also facilitate communication, involve users and so remove ambiguity about expectations.
The Project Product Description is the first step of product based planning. It is only needed for the project plan, although it is first produced when preparing the outline Business Case in SU. It will be refined in IP for the Project Plan. It is also used in CP to confirm that the project has delivered what had been agreed (Acceptance Criteria). In SB the Project Product Description is checked and if amendments are needed then they would be dealt with as a request for change.
The detailed contents of the Project Product Description is in Appendix A, but it defines what the project must deliver for it to be accepted. The Acceptance Criteria section sets this information out in detail and must be measurable. It also defines the method by which they will be measured and who is responsible for acceptance. The project level quality tolerances show the range of quality which will be accepted and can provide flexibility where products do not need to be exact. E.g. Light blue between shade m01 and shade r01.
How to create
Aby sa pripravila hierarchická dekompozícia produktov a diagram toku produktov, môže sa postupovať takto:
Hierarchická dekompozícia produktu
1. Identifikujte končený produkt (dodávku) plánu (plán projektu, etapy alebo tímu)
2. Identifikujte všetky položky, ktoré budú potrebné na dodanie konečného produktu
3. Umiestnite produkty na nálepky , aby ste skontrolovali, že nie sú aktivitami
4. Zoskupte produkty, ktoré majú logické prepojenia
5. Hierarchicky zostavte tieto skupiny produktov (štýl rodokmeňa)
6. Prepojte všetky produkty až po konečný produkt hore linkami.
Diagram toku produktov
1. Vezmite všetky produkty vrátane externých produktov (nie skupiny) z hierarchickej dekompozície produktov
2. Umiestnite konečný produkt na spodnú časť strany
3. Identifikujte, čo sa dá vytvoriť bez spoliehania sa na niečo iné
4. Potom identifikujte, čo sa nedá vytvoriť
5. Opakujte krok 4, až kým sa nepoužijú všetky produkty
6. Prepojte všetky produkty, aby ste ukázali závislosti medzi nimi použitím šípok
7. Skontrolujte, či sa identifikovali všetky krížové väzby a lineárne väzby.
Product Breakdown Structure
The Product Breakdown Structure (PBS) is a hierarchical representation of products. Major products are broken down to their constituent parts. These constituent parts are then broken down and so on to a level which is relevant to the plan. Each level of plan in the project will have a PBS which goes to a greater level of detail than the plan above it.
Plans are best done with input from a team who know about different aspects of the products to be produced. This is no different for product based planning.
The Product Breakdown Structure can be shown in different ways depending on the organisation and project environment. There may be a standard in place for them. The easiest way to think of a PBS is to consider a family tree where there are not any only children from a couple. There are either no children, or two or more siblings.
In a PBS the products on which there are external dependencies need to be identified, but as the Project Manager is not producing or controlling these they should be shown differently – e.g. In an ellipse on the family tree. Similarly some products could be grouped together for convenience, but do not produce a higher level product by integrating together. These should also be shown differently in the PBS – perhaps a rhomboid in the family tree.
Appendix D has examples of Product Breakdown Structures.
Product Decsription
Product Descriptions should be written as soon as possible after the product is identified as being needed. They should be produced for all products that require checking and will be base-lined with the plan in which they will be produced.
The users should be involved in producing Product Descriptions so that their needs are captured. If there is a detailed requirements specification for the product then this can be either substituted for the Product Description or appended to it.
In small projects it may only be necessary to have a Project Product Description – although this would be rare. In a large organisation there will be Product Descriptions from previous projects and these may be able to be re-used or amended to be appropriate to this project.
Producing good Product Descriptions is essential for the project to succeed. The quality criteria define what will be accepted and so need careful thought to ensure there is as little ambiguity as possible here.
Identifier: ID from Configuration Management
Title: The product name
Purpose: What is it for?
Composition: What is it made up of?
Derivation: Where materials are from
Format & Its “look and feel?”
Presentation:
Development skills: Skills needed for production
Quality criteria: Measurable – identifies “finished”
Quality tolerance: Acceptable range of quality
Quality method: How to Check? E.g. Quality review
Quality check skills: Skills or people needed for testing
Quality responsibilities:Producer, Reviewer and Approver
Product Flow Diagram
The Product Flow Diagram (PFD) shows all the products to the produced by the plan and the order in which they are able to be produced with dependencies identified. This is a natural lead into the consideration of activities to produce the products (next step of planning procedure).
The Product Flow Diagram, as with the PBS can be shown in different ways but one convention is to connect all the products from the ‘family tree’ of products, in the order of creation, by arrows to show the direction of flow.
Any products which already exist or are from work outside our plan will be external, but the plan is dependent on them. As such they are known as external and shown in a different symbol (as in the PBS). Any groupings for convenience are not shown on the PFD as they do not result in the production of products. The direction of flow also needs to be clear on the PFD and so arrows may be used.
There can be many products which are being produced in parallel on the Flow Diagram and when the activities have been identified the resources available will need careful consideration to produce a plan which is realistic.
Comments
Sign up to make a comment.