The plans theme and product based planning

The plans theme and product based planning

PRINCE2 uses the plans theme to describe precisely how plans are used, what levels of planning are included and goes on to describe the PRINCE2 approach to those, which is utilising the product based planning technique.

Plans are the backbone of the management information system required for any project and the plans theme is there to implement communication and control by describing the methods of delivering the products.  Without a plan there is no control, therefore planning provides information on what is required, how all be achieved and by whom, and when key events must happen.

For a plan and the project to be successful it must be viable, desirable and achievable.  The latter must be clearly shown within the plan to determine that the performance aspects and hence the targets of cost, time, quality, scope, risks and benefits, are achievable.

Just like taking a journey for the first time, a project uses the plan as a baseline against which to monitor progress and compare what has actually happened against what was originally planned.  Another advantage of creating a plan is that it allows the project manager and team to mentally rehearse what must be done, so that when carrying out the plan there is a greater chance of success.

A plan is a document not just schedule such as a Gantt chart (although the plan will include such information).  A plan must therefore contain sufficient information at an appropriate level of detail to confirm that the projects products are achievable. 

Remember that the ultimate objective of any project is to deliver products into the business as usual or operational areas of the customer, and that these products will ultimately realise the benefits that have been described within the business case.

PRINCE2 uses the rolling wave approach to planning due to the fact that producing detailed plans for events in the future becomes more difficult for longer time frames.  The period of time for which it is realistic to equity plan is called the planning horizon, and for this reason it is often not possible or desirable to plan an entire project in detail at the very start. This is the main reason why PRINCE2 states that the project must be down into at least two stages.

For this reason PRINCE2 recommends three levels of planning to be produced at different levels of scope and detail to reflect the three levels of management within the project.  These levels are the project, stage, and optional team plans.

The first PRINCE2 process that uses the plans theme is starting up a project which occurs pre-project.  This process create the initiation stage plan along with the project approach and the project brief containing the customer's quality expectations and acceptance criteria, and the project board uses the directing a project process to authorize the initiation stage plan and hence the formal start of the project.

During the initiation stage the initiating a project process is used to create the project plan which forms part of the project initiation documentation (PID), and this is used to authorize the project.

Starting with the initiation stage, the managing a stage boundary process is used to create the next stage plan and this is authorized or otherwise at each end stage assessment.

Optionally, the team manager may create a team plan which covers the execution of one or more work packages.  Obviously the need for a team plan will be dictated by the size and complexity of the work packages.

The project plan provides the business case with plant at project costs and time scales, and includes the major control points required for the project such as key milestones plus start and end dates of the stages.  The project plan is used by the project board as a baseline to monitor both project and stage by stage levels.

The structure of all PRINCE2 plans is similar, however the level of detail will be different at to the project, stage, and team levels.  In addition, it important to know that each stage plan is created close to the end of each stage to ensure that it contains the latest accurate information and can build upon the performance of the current and previous management stages.

PRINCE2 uses the principle of management by exception.  Whenever a plan is forecast to exceed tolerance bounds, then an exception report must be created.  If required, an exception plan will now be prepared for the appropriate management level to show the actions required to recover from the effects of a tolerance deviation.  If an exception plan is approved it will replace the plan that was an exception and hence become the new baselined plan whether the project or stage level. Here the PRINCE2 activity of plan the stage or exception plan is used.

An exception plan at project level must be referred by the project board up to corporate or programme management as they alone have the authority to approve such a plan.  If the exception plan is to replace the stage plan, then the project board have the authority to approve it.

If the project manager has set tolerances at work package level, and the team manager is now forecasting that such tolerances will be exceeded, then an issue is raised to bring this to the attention of the project manager, who will determine if this issue can be resolved within stage tolerance levels.  If corrective action is needed and approved by the project manager, then this may result by an update to the current work package or authorizing a new work package.

Team managers may create their team plans at the same time as the project manager creates the stage plan when preparing for an end stage or an exception assessment. The team plans are used in the Managing Product Delivery process.

The only other plan used within PRINCE2, is the benefits review plan.  However this is used to define how and when measurement of the achievement of the project benefits (expected by the senior user), can be made.  The benefits review plan is created within the initiating a project process (where it is approved by the executive and accompanies the PID), and it is updated at each stage boundary. 

The benefits review plan is used during the closing a project process where it is updated to reflect any benefits that have already been realized, and most importantly those benefits along with the resources that have yet to be realized after the project has been completed.

The product based planning technique.

The use of the PRINCE2 methodology provides powerful benefits over traditional planning approaches.  This is because the philosophy is that products are first identified within the planning steps, and only then are the activities, dependencies between them, and the resources required to deliver those projects are than planned.  This is called Product-based planning and will be used for project, stage and optionally team plan levels.

Like most planning procedures, this one is iterative in nature and will often be progressively elaborated as the process of creating the plan proceeds.  At the end of each stage for example, the project plan will be updated and normally refined.  Whenever work on a plan is needed, the Product-based planning technique will be used.

At the start of any PRINCE2 project, decisions must be made about how the plan can be passed presented, which will be used, and any specific presentation and layout rules that should be adhered to.  If the project is part of a programme them the above may need to use their preferred approach.

Other decisions that need to be made at this point for plans within a project, may include any company standards or the use of a planning to all such as Microsoft project.  Estimating methods may also be mandated all recommended and will be based on the size, complexity, risk, or preferences within the organisation or industry.

The Product-based planning technique consists of four steps, with the first step of writing the project product description only being used for the project plan.  The remaining three steps are to create the product breakdown structure (PBS), creates the lower level product descriptions, and then create the product flow diagram (PFD). 

The remaining steps to create the plan document (which starts with identifying activities and dependencies), occurs after the Product-based planning technique, but of course is used in the creation of any PRINCE2 plan.

I shall now describe the sequence from the start of the Product-based planning technique through to final documentation of a given plan:

Write the project product description.

This is the first step, and although the senior user is responsible for specifying the project product, it will often be created by the project manager in close communication with both the senior user and the executive of the project board.

The project product description describes the purpose of the project product and who will use it.  It also contains the specialist skills required along with the customer's quality expectations and the acceptance criteria/tolerances/acceptance method/exceptions responsibilities.

Create the product breakdown structure (PBS).

This is a hierarchical diagram where the major products of the plan are broken down to the required level of detail.  A powerful way creating this is by the use of Post-It notes within a team brainstorming session.

There are rules for constructing a PBS.  A lower level product can be a component of only one higher level product.  The PBS does not show sequence, and therefore the only linkages between each product must either be upwards or downwards, in other words there must be no loops or sequencing.  Whenever breaking a product into lower level products, there must always be at least two lower level products, since a 1 to 1 link would infer that the higher product consists entirely of the lower product – and hence they must be the same product!

It is important to differentiate any external products required within a plan, and these are defined as any product that already exists or that they must be created or updated outside the scope of this particular plan (however these products are required in order to create one or more of the plans products).  An example might be that a plot of land requires planning permission from the local authority before building can start work.  The external product here would be ‘planning permission granted’. 

External products will normally be seen as a risk because they are outside of the control of the project and hence each external product should be entered on the risk register along with appropriate responses.

Another concept which is important here is that the products may have different ‘states’ and that it is important to differentiate these from each other within the plan.  For example in a relocation project, you may need to dismantle a Computer System, deliver it to the new site, and then install it.  Because each of these product states are unique and would need associated activities and resources, then it is important to include these within the plan.  In this example they could be described as ‘dismantled system’, ‘delivered system’, and ‘installed system’.

Since the Product-based planning technique will be used for each level of plan, then the lower levels of a PBS at project level, will become the higher levels of product at the appropriate stage plan level.

At this point in the sequence, only the project product description will have been created.  The next step is to focus on product descriptions at the lower levels within the PBS.

Write the product descriptions.

For each product shown on the PBS, a product description is required, and should be created as soon as possible after the need for the product has been identified.  Once a plan is baselined after approval by the appropriate authority, then all included product descriptions are also baselined and hence under change control.

PRINCE2 recommends involvement by the users in the drafting of product descriptions.  If similar product descriptions have been used in previous projects or stages, then these may be available via a library often looked after by project support.  Each product description must include the quality criteria against which is the product is designed and ultimately authorised, and it is important to give this criteria careful thought as it alone differentiates unacceptable product from an unacceptable one at a quality review

Create the product flow diagram.

Unlike the PBS, a product flow diagram (PFD)  identifies and defines the sequence in which the products of the plan will be developed and also shows the link dependencies between them.  Again such diagrams are best created using Post-It notes within a team or brainstorming workshop.

This is the final step within the Product-based planning technique, however the plan document has yet to be completed, and I will now cover the remaining steps to do this:

Identifying activities and dependencies.

It is tempting just to include the activities required to create the projects products.  But this would be a mistake since such activities must also include management activities including communication, along with quality checking, and authorizing activities for each product.

Dependencies between each activity and appropriate products must now be identified and these will include both internal and external dependencies.  Internal dependencies reflect logical relationships between each activity, for example activity B cannot start until activity A has finished.  An example of an external dependency might be the release of a product by an independent third party that is required by this project at a certain point within it.

Prepare estimates.

There are many estimating techniques that can be used, but the objective of estimating is that for each activity it is known how long it will take, the resource knowledge and skills required, the amount of work effort to carry out the activity, and any non human resources such as facilities or tools.

Methods that can be used for estimating include:

Top-down estimating where the overview of a plan is broken down into detailed through the levels of the product breakdown structure, so that no and ratios between development phases such as design and testing can be proportioned accordingly.

Bottom-up estimating.  As the name suggests estimating is down at the lowest level within both activities and products and can be summed upwards to arrive at the total estimate.

Comparative and parametric estimating.  The former depends upon date or stage from previous and similar projects in terms of both products and activities, and the latter is basing estimates and measured/empirical data.

Three-point estimating.  Rather than use a single point of estimate, that is, just using a best guess, this involves asking for a best case estimate, at most likely place estimate, and a worst case estimate.  The final step is to use a formula such as adding the best case to the worst case plus three times the most likely estimate, and dividing the result by six.

Prepare the schedule.

This is the generation of a bar chart or Gantt chart showing the activities, then dependencies, and the sequence in which they must be performed.  Critical path analysis is normally used here, and hence the identification of critical and non-critical activities to determine the earliest project finish date along with the critical path and the client or slack of non-critical activities. 

Note that the critical path by definition as zero float or slack, whereas non-critical activities will have some amount that determines the amount of time that such an activity can slip or extend without affecting future activities or the end date of the project.

Assess and assign resources.

The first step here is to identify who is available in terms of knowledge skills and experience, to carry out the work.  This will also include the identification of available non human resources such as facilities.

The next steps is to assign such resources to each appropriate activity, taking into consideration work effort estimates and that their availability.  As a consequence of this the critical path may be modified.

Level resource usage.

There are two situations which may now be present; the first is that large resource peaks will be evident at certain points within the project, and this can result in management or logistical problems.  The second may result in over utilisation of some resources.  The act of resolving either of the above is called levelling.  The critical chain technique may also be helpful at this step.

Agree control points.

By now, a draft schedule would have been created for the plan and key plan control points need to be identified.  These will include at project plan level, the end stage points, and that stage plan level, control points such as product completion, quality checking, and authorisation or audit points.

Define milestones.

The definition of a milestone is a zero duration activity, and similar to the above, shows key control points.  Such milestones may highlights key review points or early indication of issues, as well as indicating completion of key aspects within the plan.

Calculate total resource requirements and costs.

It is at this point for the first time, that resource requirements and other costs can be calculated to produce the planned as budget.  Such a budget must include the cost of the management and specialist activities, any optional risk or change budgets, and the cost tolerances.

Present the schedule.

This refers to the format used for the schedule, and would include the use of gantt charts, critical path diagrams, or maybe spreadsheets – particularly if a formal planning to all such as Microsoft project is not to be used.

PRINCE2 also includes a management document called the product checklist, which basically is a list of the major products plus key dates in their delivery within a particular plan.  Such dates may include draft product ready, planned quality check, and approval.

Analyze the risks.

This activity will run in parallel with all the other steps as risks may be identified at any point during the creation or update of a given plan.  The main purpose here is having identified risks, that their responses and associated resources are built into the plan so that the risks can be managed.  By the very act of planning new risks may consist of those related to the plan itself or the information contained within it.

Document the plan.

This is the final step and leads to the creation of the complete plan document.  Aspects that need to be included here will include the schedule, the costs, the required controls and supporting text which will be added here to explain the plan, any constraints on it, external dependencies and assumptions, monitoring and can trolling activities along with risk responses.

For more information CLICK HERE