All projects are different, and the planning for each will subsequently be different.

The difficulty with planning a unique activity is that there is no prototype from which to predict all the work that will need to be done, so the plan must evolve as work proceeds. Reviewing any similar projects that have been completed within the same organisation, or in a similar setting, to identify lessons that could be applied in a new project can be helpful.

Planning can be approached by asking a series of questions:

  • What actions are needed?
  • By when are these actions needed?
  • Who is going to do them?
  • What resources are required?
  • What other work is not going to be done?
  • How shall we know if it is working?

The planning process aims to demonstrate how the project outcomes will be achieved successfully within both the required timescale, the agreed budget and the required quality. As each project is different, there are a number of ways of taking an overview of a project. Two of these are:

  • the project life-cycle, which is a useful way of understanding the different phases of a project as it progresses, and
  • the classic six-stage project management model, which helps us to identify the key stages and to integrate them through the processes of the project.

6.1 The project life-cycle modell

Although all projects are different, any project can be considered to have a life-cycle consisting of five phases. The phases are usually referred to collectively as the life-cycle of a project because they provide an overview of the life of the project from its beginning to its end.

Each phase is marked by a completion which is often one of the deliverables of the project:

  • Phase 1 – project definition – is completed by the production of the agreed project brief.
  • Phase 2 – planning – is completed as a project plan, although this remains flexible in many ways and is revised during the progress of the project.
  • Phase 3 – implementation – leads to an achievement of the project outcomes.
  • Phase 4 – closure
  • Phase 5 – evaluation.

These phases can also be used as evaluation points, so that as each phase is completed a review is held to determine whether the project is succeeding in its overall performance and whether key deliverables are being achieved. There are options at these review stages to revise the plans and improve performance or even to discontinue the project.

As each project is different, so each life-cycle varies also. Real life is more chaotic than the simple model shown in the communications matrix would suggest, but it can be used to provide a structure that helps to reduce the chaos by putting some boundaries around different stages of the project.

Projects can often change as they progress. This is particularly so in service organisations such as health or educational services, where projects are usually defined by needs and problems rather than by tangible outputs such as factories or cars. Projects often take place in rapidly-changing contexts and the impact of the changing environment on the life-cycle of a project has to be managed. Flexibility is one of the keys to successful project management.

6.2 The classic six-stage project management model

This model also consists of stages, but, unlike the sequential flow of the project life-cycle, the six-stage model assumes that some stages are carried out simultaneously. In particular, the model assumes that communications will take place throughout the project. It also assumes that team building, leading and motivation will take place once the project has been defined and continue until it ends.

Figure 2           Classic six-phase project management model (http://openlearn.open.ac.uk)

The six phases are:

  • Define: The project is discussed fully with all the stakeholders and the key objectives are identified. The costs and timescales are also established at this stage and there is often a feasibility study as well. This stage is complete when the project brief has been written and agreed.
  • Plan: An initial plan is developed. Planning is an ongoing activity because the plan is the basis for reviews and revision when necessary, depending on how the project progresses.
  • Team: The team members are usually involved in developing the plan and are often able to contribute specialist knowledge and expertise. The building of this team and its motivation and leadership also continue until the project is finished.
  • Communications: should take place continuously, both within the project team and between the project team and stakeholders in the project, including anyone who contributes to achievement of the outcomes. Some communications will be through formal reporting procedures but many will be informal.
  • Control: Implementation takes place during the control stage (stage 4 in the model). During this stage, the tasks and activities of the team will be monitored against the plan to assess the actual progress of the project against the planned progress. Control is essential to ensure that the objectives are met within the scheduled timescales, budgeted costs and quality. Regular reviews are usually held to enable the plan to be revised and for any difficulties that emerge to be resolved.
  • Review and exit: The review is held to evaluate whether all the intended outcomes of the project have been met. It is also important because it enables information to be gathered about the processes used in carrying out the project from which lessons can be learned for the future. The exit from the project has to be managed to ensure that:
    • any outstanding tasks are completed,
    • all activities that were associated with the project are discontinued,
    • all resources are accounted for, including any that remain at the end and have to be transferred or sold to someone else.

Many projects evolve through a series of loops of planning, acting, reviewing and re-planning.

It is important to think of planning as a continuous activity rather than something that can be completed once and used without change for the duration of the project. Expect change and allow for scope to change or modify the plan.

Although there are many approaches to planning a project, there are seven elements that are normally included in a project plan:

  • a work breakdown structure to show separate tasks and activities,
  • the team structure and responsibilities of key people,
  • an estimate of effort and duration for each task,
  • a schedule to show the sequence and timing of activities,
  • details of resources to be allocated to each task,
  • details of the budget to be allocated to each cost identified,
  • contingency plans to deal with risks identified.

The ways in which planning can be approached usually fall in one of the following:

  • bottom-up – identify all the small tasks that need to be done and then group them into larger, more manageable blocks of work;
  • top-down – start by mapping out the major blocks of work that will need to be carried out and then break them down into their constituent tasks;
  • work backwards from the completion date if that is a given point in time, for example, 1 January, and then fill in the intermediate stages that will enable you to get there.

Each of these approaches has advantages and disadvantages and you will need to choose the one that best fits your circumstances. Ideally, you should then use one of the other approaches to check that nothing has been missed out. It is important to record your thinking and to keep any diagrams or charts produced as these will help to provide detail in the initial plan.

Contingency plans indicate what to do if unplanned events occur. They can be as simple as formalising and recording the thought processes when you ask ‘what if …?’ and decide which options you would follow if the ‘what if?’ situation happened. The key points in contingency planning can be summarised as follows.

  • Note where extra resources might be obtained in an emergency and be aware of the points in your plan where this might be required.
  • Identify in advance those dates, which if missed, will seriously affect your plans, e.g. gaining financial approval from a committee that meets only once every six weeks.
  • Know your own plan very well; probe for its weak points and identify those places where there is some ‘slack’ which only you know about …
  • Keep all those involved (including yourself) well informed and up-to-date on progress so that problems can be addressed before they cause too much disruption.
  • Recognise the key points in your plan where there are alternative courses of action and think through the possible scenarios for each one.
  • Learn from experience – sometimes the unpredictable peaks and troughs in activity follow a pattern – it's just that we have yet to recognise it.

The following suggestions for dealing with contingencies were all made by practising managers:

  • Break key tasks down to a greater level of detail to give better control.
  • Be prepared to overlap phases and tasks in your plan in order to meet time-scales, but give the necessary extra commitment to communication and co-ordination this will require.
  • Spend time at the start in order to pre-empt many of the problems.
  • Learn from experience, e.g. develop a list of reliable contractors, consultants, etc.
  • Try and leave some slack before and after things which you cannot directly control, to minimise the knock-on effect of any problems prior to, or during, such tasks.

6.3 Using a logic diagram to identify key stages

To use a bottom-up approach to planning, the activity schedule is best compiled by drawing on the collective experience and knowledge of the project team that is going to carry out the tasks.

Grouping their ideas into related tasks will remove duplication and you can then start to identify activities which have to run in series and those that could run concurrently. Some tasks have to be sequential because they are dependent on one another: you can't put the roof on a house until you have walls strong enough to take the weight. Other tasks can run concurrently and the overall plan needs to make the most of these opportunities: the most successful project plans tend to be those that optimise concurrency because this reduces the project length and intensifies the use of valuable resources.

From the clusters of activities and tasks, you can begin to identify key stages by creating a logic diagram.

This exercise can be approached by writing the key stages on cards or coloured self-adhesive notepads, so that you can move the notes around and then arrange them on a whiteboard or a large sheet of paper. Put cards labelled ‘start’ and ‘finish’ on the board first and then arrange the key stages between them in the appropriate sequence.

Finally draw arrows to link the stages in a logical sequence. The arrows indicate that each stage is dependent on another and sometimes more than one.

Figure 3           A logic diagram to develop a directory of services (http://openlearn.open.ac.uk)

The following conventions might be helpful in drawing a logic diagram:

  • time flows from ‘start’ on the left to ‘finish’ on the right, but there is no time-scale;
  • each key stage must be described separately;
  • the duration of key stages is not relevant yet;
  • different coloured cards can be used for different kinds of activities;
  • debate the position of each card in the diagram;
  • show the dependency links with arrows;
  • when your diagram is complete, try working backwards to check whether it will work;
  • don't assign tasks to people yet;
  • keep a record of any decisions made and keep the diagram for future reference.

6.4 Identifying deliverables

The project brief will identify the goals of the project and may express some of these as key objectives. At an early stage of planning you will need to identify all of the project objectives and the deliverables that are implied or required from each objective.

Each objective will identify a clear outcome. The outcome is the deliverable. In some cases, the outcome will be some sort of change achieved and in other cases it will be the production of something new. In either case, the project deliverables should be identified so that it will be easy to demonstrate that they have been achieved.

Outputs can be defined when there is a distinctly identifiable product but outcomes are more holistic and can imply a changed state that might not be evident for some time. In some situations it may be difficult to demonstrate outcomes, for example, where cause and effect are uncertain. It is still important in such settings to identify goals and to define them in a way that will enable an appraisal of the extent to which the aims of the project have been achieved. ‘How shall we know if we have been successful?’ and identify the indicators that will help in making that judgement.

Deliverables:

  • need to be handed over to someone authorised to receive them;
  • at the handover, there should be a formal acknowledgement that the specification has been fully met and each item has been ‘signed off’ as fully acceptable;
  • the deliverable will be something for which users will need some training to use or something that needs to be implemented in some way. In these cases, once the deliverable has been identified, it is important to agree who will be responsible for the ongoing training or implementation, so that there are no misunderstandings about the boundary of the project.

6.5 Work breakdown

A work breakdown structure enables:

  • the work of a project to be divided into ‘packages’;
  • these ‘packages’ can be further subdivided into ‘elements’;
  • these elements are then divided into individual ‘tasks’.

This structure provides a basis for estimating the time and effort required. In a large project, the work breakdown structure might allow packages of work to be allocated to teams or team members so that they could identify and schedule the subtasks.

The deliverables can be identified in the work breakdown structure so that all the activities can be seen to contribute towards achieving the deliverables. Involving the project team in constructing the work breakdown structure can be one of the initial team-building tasks and can provide the first opportunity to develop an understanding of the whole project.

Figure 4           Work breakdown structure for data collection package

As the work breakdown is considered, groups of activities might be identified that could be considered as mini projects in themselves. These can offer useful staff development opportunities for team leaders in appropriate areas of work.

Although the work breakdown structure should be kept simple by identifying substantive tasks rather than all of the subtasks, it is important to consider the team or staffing structure and key responsibilities at this stage.

6.6 Scheduling

Scheduling is about deciding the time that each task will take to do and the sequence in which the tasks will be carried out.

There are a number of approaches to estimating the time and effort (and, therefore, cost) required to complete a project. Some estimates may be based on past experience but, because each project is essentially unique, this alone may not be sufficient. A clearer picture can be obtained by measuring each task in terms of the content of the work, the effort required to carry it out, and its duration. This should enable you to estimate resource requirements in order to begin scheduling, taking account of the current workloads of the members of the project team and their capacity to carry out the work.

Usually there are some things that must be completed before others can be carried out. This is called dependency. When one task is dependent on another, the sequence needs to be planned, but there is also the possibility of delay if the dependent task cannot be started until the previous task is completed. The Gantt chart and critical path analysis are two useful techniques that will help you to plan for each of these issues.

6.6.1 Gantt chart

The Gantt chart enables you to establish the sequence of tasks and subtasks and to estimate a timescale for each task. It will allow you to block out periods of time throughout the duration of the project to ensure that it is completed on time. The Gantt chart is not so useful in demonstrating the dependencies and the impact of delay if any of the foundation tasks are not completed as scheduled. A technique called Critical Path Analysis (CPA) is frequently used to plan the implications of dependencies. We shall look at each in turn.

Gantt charts show all the key stages of a project and their duration as a bar chart, with the time-scale across the top. The key stages are placed on the bar chart in sequence, starting in the top left-hand corner and ending in the bottom right-hand corner. A Gantt chart can be drawn quickly and easily and is often the first tool a project manager uses to provide a rough estimate of the time that it will take to complete the key tasks. Sometimes it is useful to start with the target deadline for completion of the whole project, because it is soon apparent if the timescale is too short or unnecessarily long.

The detailed Gantt chart is usually constructed after the main objectives have been determined.

Figure 5           Gantt chart for directory production

In the example above:

  • key stage K (‘organise distribution’) starts at week 23 so that its end-point coincides with key stage L (‘distribute directory’).  However, K could begin as early as week 17, as soon as key stage J is completed.
  • Key stage K is therefore said to have slack.
  • Key stage H (‘agree print contract’), has been placed to end at week 12. However, it could end as late as week 22, because key stage I (‘print directory’), does not begin until week 23.
  • Key stage H is therefore said to have float. Float time can be indicated on the chart by adding a line ahead of the bar to the latest possible end-point. Slack and float show you where there is flexibility in the schedule, and this can be useful when you need to gain time once the project is up and running.

You can add other information to a Gantt chart, for example:

  • milestones – if you have special checkpoints, you can show them by using a symbol such as a diamond or triangle,
  • project meetings could be indicated by another symbol such as a circle,
  • reviews of progress could be indicated by a square.

For a complex project you may decide to produce a separate Gantt chart for each of the key stages. If you do this shortly before each key stage begins, you will be able to take any last-minute eventualities into account. These charts provide a useful tool for monitoring and control as the project progresses.

Gantt charts are relatively easy to draw by hand, but this doesn't offer the same level of flexibility during monitoring that you would get from a software package. Various programmes are available to assist project managers in scheduling and control. Once the data have been entered, a programme helps you to work on ‘what if’ scenarios, showing what might happen if a key stage is delayed or speeded up. This is more difficult if you are working manually.

6.6.2 Identifying the critical path

The critical path describes the sequence of tasks that would enable the project to be completed in the shortest possible time. It is based on the idea that some tasks must be completed before others can begin. A critical path diagram is a useful tool for scheduling the dependencies and controlling a project. In order to identify the critical path the length of time that each task will take must be calculated.

We will use the logic diagram for production of the directory of services for carers as a starting point, because it is usual to complete a logic diagram before making a critical path analysis. The length of time in weeks for each key stage is estimated:

  Key stage

Estimated
time in weeks

A Secure funds 0
B Negotiate with other agencies 4
C Form advisory group 4
D Establish data collection plan 6
E Collect data 4
F Write directory text 4
G Identify printer            2
H Agree print contract 2
I Print directory 4
J Agree distribution plan 12
K Organise distribution 4
L Distribute directory 2

We have given the key stage ‘secure funds’ an estimated time of zero weeks because the project cannot start without the availability of some funding, although estimates would provide detail at a later stage. The stages can now be lined up to produce a diagram that shows that there are three paths from start to finish and that the lines making up each path have a minimum duration.

If we now trace each of the possible paths to the ‘Finish’ point, taking dependencies into account, the route that has the longest duration is known as the critical path. This is the minimum time in which it is going to be possible to complete the project.

In this example the critical path is A–B–C–D–E–F–I–L, and the earliest completion date for the project is the sum of the estimated times for all the stages on the critical path – 28 weeks – from the point of securing the funding. All the key stages on the critical path must be completed on time if the project is to be finished on schedule.

If the projected total time is a long way off the project sponsor's expectations, you will need to renegotiate the time-scale. Mapping the critical path helps to identify the activities that need to be monitored most closely.

We have used a relatively straightforward example to illustrate this technique, but a more complex project may have several lines of key stages operating at first in parallel but later converging, so that several critical activities may have to be completed before another can start.

Figure 6           Critical path for directory production

A key event list is a statement of identifiable key points along the path of the project together with their scheduled dates. Such a listing may be useful as a concise guide for senior managers. A key events list should always be derived from a more detailed plan, preferably critical path based, to ensure that the dates stated are achievable. (Note: the terminology of ‘milestones’ is sometimes used for, and/or confused with, key events.)

Key Event

Timing

Project brief agreed project start
Design new system completed by 2nd July
Project review (when most of initial work is done) 19th July
Handover 21st August

Formally, logic diagram is very similar to the much complicated CPM diagram which was developed for complex but fairly routine projects with minimal uncertainty.

Figure 7           A critical path network (CPM) diagram of converting a room into a computer suite (Lock, 1993, p. 538)

6.7 Estimating costs, revenues and intangible benefits

Planning a project includes preparation of financial and related projections. Frequently, these will be used to:

  • weigh up the economic feasibility of the project,
  • obtain approval from a higher authority in the organisation for the project to proceed,
  • set boundaries of delegation or empowerment in a formal budget,
  • provide the basis for accounting for project revenues and costs,
  • provide a means of diagnostic and, possibly, interactive control of the project.

At the project preparation and planning stages, your focus is on understanding and shaping the future. Among important questions you should be addressing are those along the lines of:

  • What resources will we require and what will they cost the organisation?
  • What products will be produced, in what quantity and of what quality?
  • Depending on the type of organisation, either:
    • for what prices can our for-profit organisation sell these products and how much revenue will they generate?
    • how much must our non-profit organisation charge users for these products if these charges are to cover resource costs?
    • In producing these products or offering these services, how much economic, political and/or social value will our governmental organisation confer on their direct beneficiaries, and on other citizens and other taxpayers generally; and by doing so, what private costs will our governmental organisation impose on citizens and other taxpayers?
  • What cost savings will accrue to our organisation from these products or what fines/penalties will our organisation avoid by producing these products?

Planning a project is an iterative process, involving:

  • developing ideas;
  • trying them out;
  • formulating them into something coherent enough to call an outline proposal for a project.

All these activities result in an opportunity cost, mainly of staff time (spent on thinking, corridor discussions, meetings, etc.) that is not, therefore, being devoted to other valuable activities. As soon as most of these costs are incurred, however, they are sunk, irrecoverable and, therefore, irrelevant to analysis of the future, at least in economic terms.

One trap to watch out for is to be sucked further and further into a project on the political grounds that the organisation has invested (or sunk) so much money and effort in it so far that it can't afford to pull out now.

Projected benefits and costs need to be calculated at an early stage in the life of the project, working as far ahead as possible, preferably until the project would be completed. There must be a case that shows that the benefits exceed the costs by a large enough margin to warrant spending more planning time on the project, instead of working on alternative organisational activities.

Estimates are the best guess that you can make given the information available at the time of estimating. It provides a way of testing the extent to which the desired aims are likely to be achieved by the organisation within the financial resources it can make available internally or raise externally. It is only when you have a detailed breakdown of work and a schedule of timing that you can be more specific about the revenues and costs involved.

Few projects are genuinely unique. Many are look-alikes and a prime source of estimates is similar activities, past or present, elsewhere in the organisation. Data, published and otherwise, should be available from other organisations, especially those that that aren't direct competitors. Often you just have to telephone or email the right person as you can make use of networking to establish useful contacts.

It helps to distinguish between development and operational costs, and to analyse these further into stages or components of the project, based on Gantt and/or critical path charts.

These components will each require effort and resources, and these inputs can be analysed and translated into monetary values simply by applying unit prices or rates. Revenue and intangible benefit estimates can be approached in a similar way, based on other experiences and components of your market. Be aware, however, of monetary amounts being assigned to intangible benefits because these may give rise to an impression of objectivity that is not deserved.

6.8 Drawing up the implementation plan

Once the detailed planning and risk assessments have been carried out, you are ready to assemble your implementation plan. A typical implementation plan, including diagrams and charts where appropriate, will contain:

  • a description of the background to the project,
  • its goals and objectives in terms of intended outputs and/or outcomes,
  • the resource implications (budget, personnel – including any training requirements – and facilities),
  • the project schedule,
  • how action will be taken and by whom,
  • a description of how the project will be managed,
  • the reporting and review arrangements,
  • the evaluation plan – how success will be measured,
  • the risks and contingency plans.

The project plan should also include an executive summary, providing the basic information and main goals and objectives in a few paragraphs.