Planning
What is a Plan?
A plan is a document, or set of documents, created according to a method, which describes
|
|
how |
|
|
when and |
|
|
by whom |
,
a specific target or set of targets is to be achieved. A plan is a design of how identified targets for
|
|
|
|
|
timescales, |
|
|
Costs and |
|
|
quality |
can be met. Plans are the foundation of the management of any project. A plan requires the approval and commitment of the Project Management Team and must be formally approved by the Project Board.
But, a plan is just that, it is a plan. It is not set in concrete, and will by definition change as the project unfolds. It is impossible to define all the elements of a project exactly before it starts.
What are the Elements of a Plan?
When asked to describe a plan, many people consider only its pictorial view. They often think only of the Gantt charts of popular software products. PROMISE requires this to be supported by a specific format of text.
A plan is a statement of:
|
|
What the deliverables are |
|
|
The activities needed to create those deliverables |
|
|
The quality activities needed to validate the deliverables |
|
|
The resources and time needed for all activities (including quality control and handover to operations), and any need for people with specific skills |
|
|
The dependencies between activities |
|
|
External dependencies for the delivery of information, products or services |
|
|
When activities will occur |
|
|
The points at which progress will be monitored and controlled |
Plans should be presented as management reports, with key information documented in a way that the audience can understand, interpret and question. A Stage Plan might, therefore, be held in two forms; a summary plan suitable for presentation to the Project Board, and the more detailed one used for day-to-day control of the stage.
The statement of activities and breakdown of resource requirements must be backed up by text which explains to the reader:
|
|
What the plan covers (e.g. delivery of specific products) the intended approach to implement the plan |
|
|
How adherence to it is to be monitored and controlled |
|
|
What management reports will be issued |
|
|
The quality control methods and resources to be used |
|
|
Any assumptions on which the plan is based |
|
|
Any pre-requisites which must be in place on day one of the plan |
|
|
What risks there are which may prevent the plan being achieved and what measures should be (or have been) taken to address these risks |
.
The PROMISE Approach
The PROMISE planning structure allows for a plan to be broken down into lower level plans containing more detail. But all plans have the same overall structure and are always matched back to the planned requirements, including quality and benefits, before approval.
Levels of Plan
Activity durations and resource requirements become more difficult to estimate accurately the further into the future they extend. Regardless of this problem, there is still a need to provide a provisional estimate of the duration and cost of the project as a whole in order to gain approval to proceed.
Except for extremely small projects, it is seldom desirable, or possible, to plan an entire project in detail at the start. The reasons for this include:
|
|
Uncertainty about the detailed nature of later elements of work |
|
|
A changing or uncertain environment |
|
|
Risk factors which could change the situation |
|
|
Difficulty in predicting resource availability well into the future |
|
|
Difficulty in predicting business conditions in the future. |
However, if the current elements of work are to be controlled, detailed plans containing firm estimates are needed for the realistically foreseeable future. For these reasons, plans need to be produced at different levels of scope and detail.
PROMISE proposes two basic levels of planning, the Project Plan and the Stage Plan, to reflect the needs of the different levels of management involved in the project. Use of the Team Plans is optional, and will depend on the needs of the individual project. These other levels are explained in more detail later in this chapter, but, briefly:
|
|
A Stage Plan may be broken down into a number of Team Plans (where, for example, a number of teams may be contributing to the work) |
|
|
Where a Stage or Project Plan is forecast to exceed its tolerances, an Exception Plan is put forward which will replace a Stage Plan or lead to a revised Project Plan. |
The principle idea behind the levels is that the lower the level, the shorter the plan's timeframe and the more detail it contains. The project chooses the levels and, therefore, the number of plans it needs according to its size and extent of risk exposure.
An overview of the total project is needed. This is the Project Plan. It forms part of the Project Foundation Document. The Project Plan is mandatory. It provides the Business Case with project costs and is used by the Project Board as a baseline against which to monitor actual costs and project progress stage by stage. The Project Plan identifies key deliverables, resource requirements and the total costs. It also identifies major control points within the project, such as stage boundaries. The Project Quality Plan for the project is documented separately in another part of the Project Foundation Document.
Once the Project Foundation Document has been accepted, the initial Project Plan is 'baselined' and shows the original plan on which the project was approved. Subsequent versions of the Project Plan are produced at the end of each stage to reflect:
|
|
Progress already made |
|
|
Any agreed changes in circumstances |
|
|
Any revised forecast of cost and / or duration of the total project |
As the project moves through its stages. The initial and current versions of the Project Plan form part of the information used by the Project Board to monitor how far the project is deviating from its original size and scope.
If the Project Plan is likely to exceed the tolerance laid down by management, the deviation must be referred upwards by the Project Board to get a decision on corrective action. In such cases an Exception Plan (for the entire project) should accompany the submission. The format of an Exception Plan is the same as for any other Plan and is discussed later in the chapter.
For each stage identified in the Project Plan, a Stage Plan is required. Each Stage Plan is produced near the end of the previous stage. It will be the basis of the Project Manager's day-to-day control.
The Stage Plan is similar to the Project Plan in content, but each element will be broken down to the level of detail required to be an adequate basis for day-to-day control by the Project Manager. The validity of assumptions and risk analyses should be re-assessed for the stage, as these may have changed since they were previously considered, new risks may have arisen or become apparent when looking in more detail.
Each Stage Plan is finalised near the end of the previous stage. This approach should give more confidence in the plan because:
|
|
The Stage Plan is produced close to the time when the planned events will take place |
|
|
The Stage Plan is for a much shorter duration than the Project Plan |
|
|
After the first stage the Stage Plan is developed with knowledge of the performance of earlier stages. |
Exception Plan
When it is predicted that a plan will no longer finish within the agreed tolerances, an Exception Plan is produced to replace that plan. An Exception Plan is prepared at the same level of detail as the plan it replaces. Most Exception Plans will be created to replace a Stage Plan, but the Project Plan may also need to be replaced. An Exception Plan picks up from the current Stage Plan actuals and continues to the end of the Stage.
An Exception Plan has the same format as the plan that it will replace, but the text will cover:
|
|
Why the Exception Plan is needed |
|
|
The impact of the Exception Plan on the Project Plan (if it is a lower level of plan which is being replaced), the Business Case and risks. This extra information comes from the Exception Report. The Exception Plan needs the approval of the Project Board. |
Team Plan
Team plans are optional and are used to break down activities into a lower level of tasks that are to produce one or more of the Stage Plan's products. They might be used for separate teams working in a stage, especially if those teams are from different skill groups, or work for external contractors. The Team Manager would create the Team Plan as part of the sub-process accepting work. The Stage Plan would be a summary of the various Team Plans.
The need for Team Plans will be determined by the size and complexity of the project and the number of people involved. If they are considered necessary, the plans are prepared in parallel with the Stage Plan.
Benefits of
Planning
Effective Planning Identifies:
|
|
Whether the targets are achievable |
|
|
The resources needed to achieve the targets within a timeframe |
|
|
The activities needed to ensure that quality can be built in to the products |
|
|
The problems and risks associated with trying to achieve the targets and stay within the constraints |
.
Other benefits of planning include:
|
|
Avoiding muddle and ad hoc decisions |
|
|
Helping the management team to think ahead |
|
|
Providing a yardstick against which progress can be measured |
|
|
Communication, through the distribution of a plan to all concerned, of what is to be done, how it is to be done, the allocation of responsibilities and how progress will be monitored and controlled |
|
|
Gaining commitment from the contributors and recipients |
|
|
The provision of personal targets |
.
Planning is not a trivial exercise. It is vital to the success of the project. A plan must contain sufficient information and detail to confirm that the targets of the plan are achievable.
It is essential to allocate time for the planning activity. Every project should have an Initiation Stage in which time is allocated to identify and agree the scope of the project and to plan it in terms of management, resourcing, deliverables, activities, quality and control. Time should also be allocated for the refinement of the Business Case. The Initiation Stage may or may not be formal, depending on the nature and complexity of the project. In addition, during the Initiation Stage and towards the end of every stage in the project except the last one, time should be allowed for planning the next stage in detail.
Without effective planning, the outcome of complex projects cannot be predicted in terms of scope, quality, risk, timescale and cost. Those involved in providing resources cannot optimise their operations. Poorly planned projects cause frustration, waste and re-work.