The highest emphasis placed by Organizations, Programmes, independent Knowledge workers, Professional bodies and frameworks such as PMBOK® (PMI) and PRINCE2® (AXELOS Limited) is on Planning. Effective and thorough planning will eliminate and/or reduce rework at later stages of the project when the cost of making changes is very high. 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 realize the benefits that have been described within the business case by the user community.

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. All Project Planning must result in an achievable plan of execution which is able to be adjusted based on the effect of change and non-performance. This begins with a set of objectives, linked with the overall business objectives, and providing measurability to ensure an accurate view of attainment. So, all of the project objectives must be specific and quantified. To ensure the specificity and measurability of the project objectives, most clients will demand that each individual objective complies with the SMART format: Specific, Measurable, Achievable, Realistic, and Time-based.

Once you have SMART objectives, you have a baseline Project Schedule and you have a Cost Baseline (project budget), you are able to track the progress and performance of your project. As the Project Manager, one would expect you should review the performance metrics with your client’s finance team (since they are typically tasked with measuring the overall business performance). They may have specific tools, software, or formulas which they use to measure performance. If not, a simple approach is to use the Earned Value (EV) formulas to track project progress and performance.

The Journey --

Using input from the Project Initiation process (the Project Charter, Project Mandate, Project Brief, Outline Business case, Business Plan, and other documents i.e., feasibility studies, budget models, decision checklists), and the approval of the Project Sponsor (or the Project Board under a PRINCE2® project) to proceed, we begin the planning processes. Since PRINCE2® focuses on “Product-Based Planning”, the Planning begins with identifying and analyzing the products produced during the project. Once the PM identifies the activities to develop these products, then he/she can begin to develop the schedule and align the resources required. Essentially, the planning phase generally consists of:

• Identifying the work involved (through a review of the Project Initiation phase/stage documents) – at a high level, this will identify the major project activities and deliverables
• Developing a project network diagram -- Again, at a high level, but important to show dependencies and initial risks
• Assigning resources -- This is an alignment of the major activities with the skills required. From this, the PM should work with the Project Sponsor to obtain resources from the internal organization and determine gaps in skills to anticipate the need for external resources 
• Developing the project schedule -- Although you may initially use a spreadsheet, it is highly recommend the use of scheduling and project planning software. The most widely used scheduling software is Microsoft Project. Enter the activities and deliverables (as milestones) described above.
• Developing a project budget -- Once you have identified the activities, their approximate durations (from the project schedule), and the resources required (internal and external), you can develop the budget – though preliminary at first (rough order of magnitude), during this phase you will finalize the budget as you better define the three elements of activities, time, and resources.
• Creating a Project Plan -- this is the primary deliverable from the Project Planning phase and is composed of all of the information described in the bullets above.

The product based planning technique – A PRINCE2® Approach

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 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 then the above may need to use their preferred approach as defined by the programme management. Other decisions that need to be made for plans within a project may include any company standards or the use of a planning tool such as Microsoft project. Estimating methods may also be mandated by the organization or the governing programme management that will be primarily based on the size, complexity, risk, or preferences within the organization 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), create 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.

Let us now see 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. 

• 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 authorized, 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.

• Identifying activities and dependencies.

It appears 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 and schedule.

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. 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 situations which may be present; such as that large resource peaks will be evident at certain points within the project, and this can result in management or logistical problems or there may be over utilization of some resources. The act of resolving either of the above is called leveling. The critical chain technique may also be helpful at this step.

• Agree control points and define Milestones.

A 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 authorization or audit points. The definition of a milestone is a zero duration activity, and similar to the above, shows key control points. Such milestones may highlight 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 budget. Such a budget must include the cost of the management and specialist activities, any optional risk or change budgets, and the cost tolerances.

• 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, 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.

________________________________________________________________________

Author - Vijayakumar Reddy, CTO & Lead Trainer, A2A IMTCS Pvt. LTD.

© Copyright 2015 A2A - IMTCS. All rights reserved. www.iimtcs.in

The Swirl logo is a trade mark of AXELOS Limited. 

PRINCE2® is a Registered Trade Mark of AXELOS Limited. www.axelos.com