As the “backbone” of the management information system required for a project, plans are a crucial theme within the PRINCE2 methodology. Essentially, plans are management products that detail what must be done to attain a particular goal (or goals), the various activities which are required to be performed, when they need to be done, and who is going to do them.
The goals of a project include not only the product(s) it will create, but also its time and cost constraints, its quality requirements, and the benefits expected from it.
Plans are used not only to provide instruction for the future, but to measure current progress, functioning as a yardstick for evaluating what has been achieved and what has been expended on a project. As such, plans must be written to a sufficient level of detail to enable the Project Manager to determine whether the project is on track, whether goals have been achieved, and indeed, whether they are still achievable.
On the other hand, it is also important that plans are kept to an appropriate level of detail. PRINCE2 recommends three levels of plan, corresponding to the three levels of management within the project management team. Each of these planning levels demands a different degree of planning detail. For example, the Project Plan demands less detail than the Stage Plans, since the reliability of forecasts diminishes over longer periods of time. It is also the case that the Project Board, who will use the Project Plan to monitor progress, are not concerned with the details, but are interested more in seeing the “bigger picture”.
PRINCE2 Planning Levels
Throughout the project, the Project Board uses the Project Plan as a baseline against which to measure progress. As such, the Project Plan must contain the overall schedule and cost of the project, as well as tolerances set by corporate/programme management. The Project Plan also provides a high-level view of the project’s management stages.
The Project Manager uses the Stage Plan as a baseline for everyday project management activities. Each management stage on a project will have its own Stage Plan, describing the products and resources involved, the quality activities required, and time/cost tolerance levels assigned by the Project Board. The Stage Plan is able to provide a lower level of detail than the Project Plan, since its range of forecast is shorter (i.e., for each subsequent stage, rather than for the project as a whole).
By updating the Stage Plan with information about the ongoing progress of the stage, the Project Manager can become aware more quickly of actual or potential deviations from the stage-level constraints. This enables timely escalation of exceptions to the Project Board.
Depending on the size and individual characteristics of a project, Team Managers may be employed. In this case, the Stage Plan can be segmented into Team Plans, which the Team Managers then use in order to allocate tasks to team members, monitor their progress, and keep an eye on team-level constraints. If the tolerances, which are set by the Project Manager, are forecast to be exceeded, then the Team Manager refers the situation as a project issue to the Project Manager.
Strictly speaking, the Exception Plan does not occupy any one level within the project management hierarchy. Instead, it may be created if a Stage Plan or a Project Plan goes into exception, i.e., if they are forecast to exceed tolerance levels. In this situation, the Project Manager must submit an Exception Report to the Project Board, articulating the details and impact of the exception, outlining possible courses of action, and recommending one particular option for handing the problem. If stage-level tolerances are likely to be exceeded then the Project Board will make a decision on the situation; if project-level tolerances are forecast to be breached, then the Project Board will escalate the issue to corporate/programme management.
Where necessary, an Exception Plan will be created in response to an Exception Report, and if authorized, will replace the original plan, covering the duration of the plan it replaces, from the point at which the exception was identified.
The PRINCE2 planning method comprises seven basic steps.
(1) Designing the Plan
The framework for the Plan is determined in part by the standards employed on the project, and entails selecting the appropriate format, layout, planning tools, estimating methods, level(s) of planning necessary (i.e., Project, Stage, and Team), and monitoring methods for creating Plans on the project.
(2) Defining and analysing products
There are various planning techniques, but PRINCE2 has developed a distinctive technique, product-based planning, which is focused on identifying the product(s) necessary to obtain project objectives, thus elucidating the relationships between individual products and the project product – i.e., what must be delivered, and must gain acceptance on a project, in order for the project to be deemed a success.
The product-based planning technique is described in greater detail below.
(3) Identifying activities and dependencies
In order to fill out the details of the Plan’s workload, it is necessary to identify what tasks are necessary to generate and develop the products involved in the Plan. This encompasses management and quality checks, interaction with external parties (such as eliciting quality expectations from the customer), and, of course, the activities required to actually create the specialist product(s).
At this stage it is also necessary to describe the dependencies and relationships between tasks and products, e.g., Activity A can only begin once Activity B is complete.
(4) Preparing estimates
As well as identifying the products that must be created and the activities necessary to create them, it is the Project Manager’s responsibility to estimate the resources, effort, and timeframe needed to complete the work to the required quality standards.
This does not mean guaranteeing the cost or duration of the activities included in the Plan; however, it does offer an overall perspective on how long the Plan will take, and what resources will be expended. It is expected that estimates will alter as further information is collected and actual progress details are entered into the Plan.
(5) Preparing the schedule
At this point, the required activities and their dependencies, as well as their timescales, are transformed into a schedule. This is often a graphical representation of the Plan, specifying the time at which the various tasks will be performed, and how resources are to be assigned.
Computer-based planning and control tools are frequently used to facilitate this planning step, although schedules can also be constructed, particularly for smaller projects, without any computerized aid.
“Preparing the schedule” is repeated throughout the duration of the Plan, as updated information about actual progress may alter estimates (see step 4), which may in turn affect the allocation of time and resources.
(6) Analysing risks
It is important that risk analysis be performed simultaneously with each planning step, since risks may become apparent at any moment in writing and rewriting Plans.
Planned activities and resources should be inspected for possible risks, and these risks included in the Risk Register (or, when planning the initial stage, in the Daily Log). Planning risks might be, for example, that the Plan relies on unproven or unknown suppliers, or that the Plan has too few management decision points (e.g., Stage Boundaries).
Until planning risks have been sufficiently identified and evaluated, and the Plan altered to account for them, each Plan should be treated as only a draft.
(7) Documenting the Plan
Finally, the Project Manager must insert a narrative into the Plan. This entails describing the necessary products and activities, identifying constraints (e.g., of time and cost), external dependencies, and assumptions, specifying the activities needed to monitor/control project progress, and identifying risks and their appropriate response.
The PRINCE2 Product-Based Planning Technique
PRINCE2 has developed the Product-Based Planning technique, an iterative planning process that focuses attention on the products that a project must deliver. Product-based planning is often applied in tandem with an activity-centred planning approach (see step 3 above, ‘Planning activities and dependencies’) in order to ensure a balanced final Plan.
Following the product-based planning technique entails a number of benefits, such as
- • Establishing clearly the products that must be created on a project, and the dependencies between them;
- • Determining the scope boundary for the Plan (e.g., whether products are in or out of the Plan’s scope), and thus ensuring limitation of changes and avoidance of “scope creep”;
- • Prepares the foundations for Work Packages
- • Articulates responsibilities for creating, reviewing, and approving products
Product-based planning includes four steps:
(1) Write the Project Product Description
In order the gain acceptance, a project must deliver its project product to the required quality standard. The PRINCE2 management product designed to provide baseline information about the project product, including its scope, requirements, quality expectations, and acceptance criteria, is the Project Product Description.
Responsibility for specifying the project product lies with the Senior User, although it is often the Project Manager who actually writes the Project Product Description, through consultation with both the Executive and the Senior User.
(2) Create the product breakdown structure
It is important to identify the individual outputs on the project, and to describe their relationship to the project product. A product breakdown structure is a tree diagram that analyses the project product into its major products, and then these products into their own major products, etc., until the appropriate level of detail is obtained. Within this structure, each product is the component of just one higher-level product.
(3) Write the Product Descriptions
The purpose of a Product Description is to provide the necessary details about the composition, purpose, derivation, and quality criteria of the product. Each product requires its own Product Description.
(4) Create the product flow diagram
The product flow diagram is intended to depict the order and interdependencies of product development within the Plan.