This course will help you to develop the skills required when planning a project. You will examine the various components of a project plan, and be introduced to a number of tools and techniques to aid planning.
This OpenLearn course provides a sample of postgraduate study in Business
After studying this course, you should be able to:
develop plans with relevant people to achieve the project's goals
break work down into tasks and determine handover procedures
identify links and dependencies, and schedule to achieve deliverables
estimate and cost the human and physical resources required, and make plans to obtain the necessary resources
allocate roles with clear lines of responsibility and accountability.
Once the project brief has been agreed by the project sponsors and approved by the main stakeholders, you can move into the detailed planning phase. The project plan can become a working tool that helps to keep the project team focused on the project's tasks and activities and points them towards completion. It enables managers to keep track of resources, time and progress towards achieving objectives.
All projects are different and the planning for each will 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:
Discussing the issues to produce a joint plan with the team usually creates a sense of commitment that can be crucial to the project's success. Identifying who needs to be communicated with at the different stages can be useful here. (Below is a discussion and an example of a communications matrix to help you with this.)
This course examines the various components of a project plan, and introduces a number of tools and techniques to aid planning.
A communications matrix is a way of noting who needs to be consulted and at what stage. It can be a formal chart or rough notes, but its purpose is to help minimise the problems that arise when people feel they have not been consulted. The communications matrix below shows an example of a communications matrix for putting a new building unit into use.
|Stages||Operations Director||Area Manager||Site Manager||Marketing Director||Equipment Suppliers||Fittings Suppliers|
|After first site meeting|
|Operation of unit agreed|
|On-site work nearing end|
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.
Although all projects are different, any project can be considered to have a life-cycle consisting of five phases (see the communications matrix). 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 and to
Phase 4 – closure – and
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.
Although Figure 2 is linear, the phases of a project are often iterative in practice, with refining and modification taking place throughout the life 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.
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 (Figure 3) 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.
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 replanning. 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 scope to change or modify the plan.
The planning stage of a project usually takes place before the activities start, but not always. In any case, planning always continues during the implementation of a project because there is always a need to change some aspects and to revise plans.
Consider this story told by a senior line manager who had been asked to help Pat, a junior manager leading a small team on a project that was intended to produce a number of prototype packaging options. Pat was an experienced designer but had very little experience in managing projects and had run into problems in her new role as project manager. Time was short and the team had started to work enthusiastically, but something had gone wrong. They were two months into the project but were not producing anything – there was no sign of measurable progress.
‘Pat had a number of designs in draft form, as did other members of the team, but nothing had been completed. My task was to review the project and help Pat to get it back on track. I asked for the project plan – which was produced rather hesitantly. “I got stuck”, Pat explained. “I tried to follow the company guidelines, but I couldn't understand why we needed to go through all of those stages and hold lots of meetings – we all know how to design this sort of thing”.
‘However, the team had all had different ideas about how to approach the project and had been working separately, trying out a lot of different ideas that Pat had realised were not really addressing the requirements of the project. Some of the team thought that this was a good opportunity to develop some creative ideas and wanted to try out different ways of doing things. Pat felt that there was no time to waste in planning and filling in paperwork, just to conform with the company procedures, when the available time could be spent producing the prototypes. However, most of Pat's time was spent in trying to keep the team members working on practical ideas and in fending off inquiries about progress and so little progress had been made. The team felt as though they had been working very hard and were being unfairly criticised.
‘We sorted the problem out in two days. I worked through the planning document with Pat, and explained that it was the process, not the paperwork, which was important. We involved the team in planning so that they understood what was needed from each of them. Developing a plan helped the team to bring their ideas together, to agree on who would do each task and to focus on the outcomes that were required. Once Pat had made a plan that the team could all believe in, this quickly got the project back under control, and it was completed successfully’.
Note down a list of the barriers that Pat encountered in planning the project.
How could each of these barriers have been overcome earlier?
We identified the barriers listed below and suggest ways in which they could have been overcome.
Pat had tried to make a plan but had found the instructions in the manual too complicated to follow. A manual of procedures was provided – but this can be bewildering for a person who does not understand why the procedures should be followed, particularly if the procedures seem to be about producing paperwork rather than carrying out the work of the project. Luckily, the first review date had been set early enough for the situation to be recovered.
None of the team seemed to appreciate why a plan was useful. If they had been involved in discussing the project and how they could complete it they would have realised that they needed to decide who would carry out each task and in what order these needed to be done. Involvement in planning usually also increases motivation to complete the plan.
All the team members were feeling pressure to make progress as time was short. However, without a plan it was not clear to Pat which tasks each team member needed to do or in what order these should be done. Activity without such a plan used up energy but was frustrating because little progress with the project was achieved. A plan with targets would have helped everyone to carry out tasks that contributed to progressing the project.
The problem was not noticed by senior managers until the first review date, which was rather late and could have been embarrassing for Pat. In this case it was not too late for corrective action to be taken to rescue the project. As this was Pat's first project it would have been helpful for a more experienced manager to offer coaching through all of the stages of managing the project.
Pat's work seems to have been unsupervised and it is possible that the culture of the organisation made it difficult to ask for support. However, if the plan had been agreed with the project sponsor, there would already have been some discussion about what should be reported and when reports should be made. This would have helped to focus on whether Pat needed support before the first review date.
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.
Some people think that all that is required in planning a project is to make a list of tasks, classify them under headings, call the project team together and ask them to do particular jobs – and then work towards the deadline. Based on my experience, this will not work. Depending on the complexity of the project, high risks and cross-functional activities, this could very quickly lead to fire-fighting rather than managing the project.
Project planning is about addressing the fundamental questions: what needs to happen and when? It is the process by which the activities in a project are defined, their logical sequence determined and the effort required in terms of time, cost and quality is estimated. A project plan has two main purposes:
it underpins the ‘business case’ (business approval to proceed with the implementation of the project, including a full investment appraisal);
it provides a route map defining and communicating how the project will move from start to finish.
For the project manager, the project plan is the most important tool for monitoring and control. Most project planning tools and techniques have been around for a long time and have proved themselves to be useful, enabling the project manager to deliver his projects to time, cost and quality. In discussions I have had with many project managers from across the industry I found that where project planning is not given the priority it deserves, project managers failed to deliver their projects in a timely manner.
When I first started to project manage refurbishment projects, my planning was based on what I thought was the best way to plan the work. Some of my projects were late because I underestimated the resource requirements. Some were over budget because I did not carry out an impact analysis when the scope of the project changed and sometimes my project deliverables did not comply with the specification because I did not define and monitor the deliverables adequately. Any project manager who does not produce a plan will soon run into unplanned activities, which incur unexpected costs.
There is also the opportunity to filter out projects with negative returns at this point thus eliminating unproductive projects and avoiding abortive work. However, you can only make these savings if you carry out cost-benefit analysis. Forcing a systematic project plan to be produced can eliminate some of the more frivolous projects. I use the project plan to check that the project is right for the business and meets the stated requirements of the project brief. A good plan can also show that the project manager took every possible precaution to ensure that the end result was positive.
The downside of planning is cost. It takes time to plan and if planning goes on for too long it can drain the project budget. On reflection I believe that project planning is a value-added activity.
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.
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. Then 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.
A training agency that provided work placements for young people decided to develop a directory of services available for young adults in the community. The key stages identified were:
|B||Negotiate with other agencies|
|C||Form advisory group|
|D||Establish data collection plan|
|F||Write directory text|
|H||Agree print contract|
|J||Agree distribution plan|
Figure 4, showing the logic diagram for directory production, illustrates each of these stages. Each stage has at least one arrow entering it and one leaving: for example, organising distribution (K) is dependent on agreeing a distribution plan (J), and collecting the data (E) cannot happen until a data collection plan has been established (D). However, preparatory activities for distribution (J and K) and printing (G and H) can run concurrently. We have assumed that the advisory group will make decisions about the acceptability of the data collection and distribution plans and will agree the printing contract.
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.
A comparison chart is not a formal technique as such, but is a way of setting out for oneself and others the relative merits of different approaches. The only ‘essentials’ in this are the three criteria of quality, cost and time-scale against which subjective judgements are made. In this case study various elements of each approach are considered against these three criteria, but both the format and the method could have been different.
The comparison chart below covers a project to develop an induction programme for new staff in a call centre. It shows how different ideas are put forward for how the induction might be undertaken. This shows that there might be different ways that a company could develop an induction programme, and there would be different implications in terms of timescales, the quality (in terms of how different approaches would seem to new employees) and finally in terms of different costs.
Imagine that managers in your organisation are considering developing a directory to be given to new staff appointed, as part of the induction process. You expect that you will be asked to manage this project. You want to be well prepared for the meeting at which the potential project will be discussed. Draw up a list of the tasks involved in the project and organise them into key stages on a logic diagram.
Your diagram probably looked similar to the one in Figure 4. You should have noted that you would need approval to use resources (A), which might include approval to involve others in the organisation and to interview people in each area of work (B). You might have decided to have some sort of steering committee (C) – this is often a good idea because it brings ideas from various perspectives to the project and it also helps to attract support for the project and its outcomes. You would have needed to plan for data collection (D and E) and someone would have to create the text (F) which would need to be printed or produced in an accessible electronic form (I) so that new people to the organisation could easily access the information. The production process would need steps G and H, as in the earlier logic diagram. You would also need to consider how the directory should be distributed to each area of work in the organisation (J, K and L). There are essentially three sequences of activities that must be completed in sequential order before the whole project can be completed.
An overview of the key activities and stages of the project provides the skeleton of your plan. You can then work out the details in each of the stages. Your understanding of the project will develop and change as you become more familiar with the issues raised in each stage of planning. Planning is a dynamic process and one of your main roles in managing a project is to keep the balance between:
the need to have a plan to ensure that the project outcomes can be achieved within time, budget and quality requirements;
the need to respond to change in the setting surrounding the project and in the understanding of all of the people involved in the project.
It is helpful to keep a project brief as the starting point in each stage of planning, to ensure that the purpose of the project is not forgotten in the practicalities of planning. As each part of the plan develops, use the project brief as a basis for checking that the key outcomes are still the focus of activity and that the balance of budget, schedule and quality are being maintained.
A checklist for drafting a project brief appears below.
|Name of sponsor and main contact for project approval|
|Locations – address of sponsor, project location, contact address|
|Name of person managing the project and possibly their organisation if different from that of the project sponsor|
|Date of agreement of project brief|
|Date of project start and finish|
|Background to the project and purpose with goals outlined|
|Key objectives with quality and success criteria|
|Details of how achievement of these will bring benefits to the business or sponsoring organisation|
|Scope of the project and any specific boundaries|
|Timescale of the project|
|Deliverables and target dates (milestones)|
|Reporting and monitoring arrangements|
|Decision-making arrangements – level of authority and accountability held by manager of project and arrangments for any necessary renegotation|
|Signature of sponsor with date, title and authority|
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.
The first objective in a project that aimed to change the service focus of an organisation was to ensure that all of the key managers were trained to carry out the change. The deliverable might have been evidence that 80 key managers had been trained in managing change. This evidence might have taken the form of records showing that the training had taken place. If the training was really the objective, then this would be sufficient.
However, in this case, the training was intended as preparation for action. It might have been closer to the purpose of this project if the deliverable for this objective had been framed in terms of each of the 80 trained managers being able to provide evidence of having successfully managed change.
Even this deliverable would not, in itself, support the project manager's personal intention to raise the profile of the human resources department within the organisation. To achieve this, s/he might have decided to collect the evidence that these 80 managers had successfully managed change and then used this evidence to produce a report as the deliverable. This would show how the training provided by the HR department had succeeded in developing these managers so that they were able to contribute effectively to organisational change. It is important to ensure that the outcomes of the project are the ones intended and this can be focused with specific objectives and identified deliverables.
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.
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.
One of the most difficult aspects of planning a project is estimating how long it will take to complete each key stage. An estimate might be based on:
the size of the tasks and the effort required to complete them;
the number of days that are not available for working on the project;
historical data from other projects, including the experience of colleagues.
Where a project has a fixed end-date (for example, an event where a Member of Parliament will declare a new building open) there is a natural tendency to try to compress the schedule to fit all the key stages into the time available. All too often it becomes clear later that the schedule is impossible to meet. It is better to be realistic at the outset and be clear about what can be delivered and what cannot. Productive time may only amount to 3.5 to 4 days each week and time needs to be built in for meetings, communication, co-ordination and the normal line-management arrangements. You will also need to allow some extra time for contingencies such as unexpected interruptions and eventualities that cannot be predicted.
When the objectives are identified, trying to ensure that each objective is SMART (Specific, Measurable, Achievable, Realistic and Timebound) is good practice or at least to have considered the extent to which these conditions could be met. As in all planning, this process is continuous and as new information becomes available and as the project progresses, changes will need to be made to aspects of the objectives and to the sequences of tasks that contribute to achievement of the completed project.
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 6 shows part of the work breakdown structure for the data-collection package in the directory project. Note that a work breakdown structure does not usually show the necessary sequence of work, other than through grouping under the key stages.
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.
Teams have great difficulty in working effectively if they are too large to work together conveniently. Six to eight people is often considered to be about right. Where the project needs more staff to deliver all of the outcomes, the structure could consist of a number of teams, each with a team leader. In some projects there may not be a team but, instead, a number of individuals or groups making a specialist contribution at an appropriate time and a method for co-ordinating these inputs becomes vital.
At this stage, the roles will be identified in terms of the expertise or skills that are needed to complete each of the main tasks. Where members need to be recruited to the team, this process will help to identify the criteria for selection. If some of the project team have already been identified, or if the team leaders have been appointed, there is an opportunity to include them in determining the team structure. The key responsibilities can also be allocated.
The project manager will usually retain the responsibility for ensuring that the decisions reflected in the authority chart are carried out. Once the levels of authority have been decided it is not difficult to decide how the approval will be sought and recorded, how those who should be informed will be told and how consultation will be arranged. All of these activities involve subtasks that can be allocated to individual team members.
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 analyis are two useful techniques that will help you to plan for each of these issues.
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 (Figure 7 – Gantt chart for directory production). 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.
In this example, 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.
Imagine that managers in your organisation are considering developing a directory to be given to new staff appointed, as part of the induction process. You expect that you will be asked to manage this project. You want to be well prepared for the meeting at which the potential project will be discussed.
Draw up a list of the tasks involved in the project and organise them into key stages on a logic diagram. Now turn this into a Gantt chart to show how long it will take to produce the directory. Use your own judgement to estimate how long each stage would take.
(PDF, 1 page, 0.09MB)
Click here to access a blank Gantt chart Gantt chart
The amount of time you allowed for this project depends on how you applied your knowledge of your own organisation. This should have led you to allow time for each of the tasks that form sequences that must be completed before a subsequent task can start (for example, you should have completed planning the data collection before you collected the data and you should have done most of this before you started writing up the text). You might have allowed some overlap of these activities if some progress was possible before the previous activity was complete; for example, you might have anticipated that some of the text could be produced before the data collection had been completed.
If your Gantt chart demonstrated that the whole job could be completed in fewer than the 28 weeks that were needed in our example, the Gantt chart for directory production, compare your chart with it to see where the differences occurred and consider how realistic your estimate is. It might, of course, be possible to complete the project more quickly in your organisation, particularly if there is agreement to invest additional resources to speed up some of the activities. Remember, however, that if consultation and agreement are required, time must be allowed to arrange meetings with key stakeholders. Similarly, you might have estimated that the project would take longer in your organisation because of the way in which your systems work.
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.
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|
|B||Negotiate with other agencies||4|
|C||Form advisory group||4|
|D||Establish data collection plan||6|
|F||Write directory text||4|
|H||Agree print contract||2|
|J||Agree distribution plan||12|
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 (see Figure 8: Critical path for directory production) 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.
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.)
|Project brief agreed||project start|
|Design new system||completed by 2nd July|
|Project review (when most of initial work is done)||19th July|
Look at Figure 9 which illustrates the Gantt chart for a project to convert a room into a computer suite. From this chart:
identify the earliest possible time for completion of the project
identify the activities that comprise the critical path
could the project be completed in less time?
The extreme right-hand side of the Gantt chart shows the completion of the final task and so the completion of the project on the 54th day. If you looked back along the chart from that final point you might have identified the critical path as the tasks involving the new floor. The décor had to be specified before floor materials could be ordered and installed and this had to be done before the final decoration of the room.
You might have considered that the project could be speeded up if the ordering time for the flooring could have been reduced – but there were a number of other activities taking place during that waiting time. Some of these other activities also have dependencies, so it is not a simple matter to attempt to reduce the time-scale of a project by speeding up only one activity.
Now compare the Gantt chart in Figure 9 – the chart to show the main tasks needed to convert a room into a computer suite with the critical path network diagram for the same project in Figure 10 – the critical path network diagram of the project to convert a room into a computer suite. Note that the numbers written on the arrows represent the duration of an activity and the flow is from left to right. The numbers in circles are the sequence of tasks in each activity and each task on a line has to be completed before the next one begins. The dotted lines show other constraints. For example, the air conditioning cannot be commissioned (task 23) until the air conditioning system has been designed, ordered and installed, but it also needs electricity (task 21) to work. Similarly, the electricity must be working before the fire prevention system can be commissioned (task 22).
The critical path is the path of longest duration through the network and it is the sequence of tasks involving the new floor. However, there are seven other sequences of tasks that must be completed before task 24, which must be completed before the decoration begins. If there are delays in any of these other activities there may be implications for the critical path and the duration of the whole project.
Although it is essential to identify dependencies, it is very helpful to establish that these are unavoidable. If one activity is usually completed before another it is not necessarily essential to complete it first and it might be possible to overlap the activities. It is an advantage to reduce the number of dependencies because that will increase the flexibility available in implementing the project.
If a task on the critical path is expected to finish five days early, will the project complete five days early?
Make a note of your thoughts.
The project would not necessarily finish five days early because there might be another task that was not critical because it would have finished two days before this unexpectedly early one. In this case, the other task now becomes the critical one and defines the expected finishing time which would now be three days early.
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 having ideas, trying them out and 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.
Projects vary in how they are eventually financed. They can be purely commercial projects from which the products are sold at market prices, and so eventually the revenues they generate are expected to cover the costs and provide an operating profit. In the meantime, development costs and working capital have to be financed from share and loan capital raised by the organisation, the cost of which will be met from the profit the project makes. At the other extreme there are projects, in both for-profit and non-profit organisations, that are regarded as a cost item, for example, a staff training programme that is to be financed from within an organisation. There are projects in non-profit organisations in the private and public sectors, funded by an external grant, patron or sponsor, for example, a community project financed by a grant from the National Lottery.
Estimating market revenue from sales of outputs for a speculative project isn't easy. The following considerations apply to purely commercial projects run by for-profit organisations and to projects that depend on user charges to cover costs and break even. Estimates can be gleaned from obtaining knowledge about previous similar projects in other similar locations, with the emphasis on the word similar and by carrying out marketing research. Understanding the basis of demand (e.g. climate, demographics, socio-economic status of customers, level of competition, cultural practices and religious beliefs) helps to understand potential demand.
It is different if you sell the output before the project really gets going; for example, if you are building a hotel under contract to a hotel company. You will, however, still need to win the tender, negotiate an agreement with the contracting organisation over stage payments for work done at various junctures in the project schedule, and raise capital finance to cover the lag between capital and operating outlays and the receipt of revenues. A similar way of reducing the market and financial risk of a speculative commercial project (for example, operating a hotel in a proposed new holiday area) is to obtain a pre-implementation contract with a large purchaser (perhaps a package holiday company) for part of the future output. No doubt this would be at a concessionary price, but the contract would provide partial insurance against a flop and would make capital finance easier to obtain and less costly.
Finally, in estimating revenues, it is usual to err on the low side: just as it is usual to err on the high side in estimating costs. That way there are in-built safeguards if things go slightly awry. Be careful, however, that you don't become too conservative with your estimates because this would kill off too many projects.
The staff time and staff-related costs need to be calculated. These include salaries, taxes, holidays, overtime, training, travel and subsistence, and accommodation for the number of staff for the time they will be needed. This raises all sorts of questions about the basis on which staff are costed and the relationship of the project budgeting system to other budgets and costing systems in the organisation. The basic assumptions underlying allocation of resources need careful consideration early in a project, particularly if there is likely to be substantial investment of staff time in the start up stages of operations.
One issue is that of how to treat the use of existing staff and other resources that are to be allocated to the project on a temporary basis. It's common to overlook these opportunity costs, or at least those when the project is a small part of any individual's time because leaving out these costs will make the project look more attractive.
However, if the opportunity cost of existing staff time is not calculated in some way, there is a danger of overlooking this cost when these staff would normally be working on the core work of the organisation. This analysis would show when it would be less costly for an organisation to hire staff specifically to work on a project, rather than to redeploy existing staff. For example, situations occur when the skill requirements would mean training existing staff before they could carry out the project tasks – probably less efficiently and with more mistakes, due to lack of experience – than if experienced outsiders were used. This, of course, raises another issue, because part of the purpose of the project may be to train staff to be more skilled, in which case the cost of training is a necessary project cost.
Staff costs can be estimated by analysing the project into tasks that staff must complete, working out staff requirements in terms of the quantity and expertise, and finding out rates of pay, taxes and other costs. Organisations that regularly work on projects often have standard approaches to calculating and costing staff time. Projects of a construction or engineering nature (for example, roads, houses, office buildings or ships) may be unique, but most of their components are not, being replications of previous work. The uniqueness derives from the mixture of components and how they are to be combined. Projects of a human service nature (e.g. schools, hospitals) often use formulae to develop operations costs. These formulae include ratios of staff to clients (for example, the number of teachers to students) and of one staff group to another (clinical staff to administrative staff).
In many projects, staff costs are the most expensive element, but there are other costs to consider, such as materials and equipment. Indeed, in some projects (for example, some military and space projects) these other costs are at least as significant as staff costs. For organisational accounting purposes, a distinction will be required between capital expenditure, or the acquisition of fixed assets, and revenue expenditure, or the incurring of expenses. The work breakdown plan and the schedule give information about the nature of each task and this can be used to estimate the costs related to use of materials and equipment.
If the organisation already has whatever equipment is needed, the only costs relating to the project may be those associated with redeploying the equipment for temporary use on the project, including any loss of value through wear and tear. However, if equipment is normally in use elsewhere there will be an opportunity cost incurred in taking it away from its normal use.
The consultancy unit of an organisation based in Kent needed an additional fax machine for two months to enable them to take registrations for residential development centres. They borrowed the fax machine from the training unit, where it was used for routine but non-urgent communications. However, the training unit found that many of its usual communications were badly disrupted during this period because people had become used to using the fax. The greatest problem was that many of the trainees in placements in India, Australia and New Zealand, had great difficulty in telephoning the office because of the time zone differences. The loss of the fax machine, even for a short period, proved to be expensive in the time spent compensating for its absence.
Equipment costs are not limited to acquisition costs. Most equipment needs regular maintenance, may break down and need repairing, it will require fuel or energy, and it will need accommodation or garaging and security. All these costs of keeping and operating equipment should be considered. And, someone will probably be needed to work the equipment. This might entail costs relating to skilled use of equipment and supervision and training for staff unfamiliar with the equipment.
There will be many categories of materials, supplies and consumables used in a project. Once again, the materials that are in constant use and easily and ‘freely’ available in an organisation might be overlooked in costing the project. For example, it is easy to assume that stationery will be available in much the same way as it is for day-to-day work. However, a project is a bounded activity, and if you are to understand the full cost of achieving the outcomes, you will need to know how much the whole range of activity costs. For example, a project can easily and inconspicuously increase the organisation's operating costs of postage and telephone or of paper and printing.
If the project involves constructing something from materials there will be a cost related to raw materials. Transport and storage will also need to be included. Materials that are fragile or that have a limited life will need special consideration. For example, if the purpose of the project is to stage an event at which there will be food served, the timing and storage considerations will be very different from projects that involve use of materials that will last indefinitely.
The person managing the project is not necessarily the best one to prepare the estimates, although they should be closely involved, both as a source of information and because they need a clear understanding of what the estimates mean and what the estimators assume about outputs, inputs and the transformation process. If there are others who have more experience or more knowledge about some of the areas of work, these people may be the best ones to make estimates for the project or parts of it. Ask each person to work independently and then meet to compare estimates and to discuss how to arrive at realistic figures for revenues and costs. Similarly, it is often helpful to involve other perspectives to ensure that you have not forgotten revenues and costs that arise as part of carrying out areas of work unfamiliar to you.
If there is someone associated with the project with experience of estimating it could be very valuable to involve them. Taking advice about any risks relating to the revenues and costs can be helpful; for example, if you will need to buy materials, the prices of raw materials might vary over time or according to the quantity of the order. In a large project, the services of an experienced buyer might contribute cost savings.
Having considered estimating for time and for costs, the third dimension of projects – quality needs to be considered. The need to achieve a particular level of quality may mean that more time must be spent completing certain tasks or that more resources must be made available for a particular purpose. Once the time and cost estimates have been made, review them to ensure that this estimate will allow an outcome of the right quality.
Many organisations have corporate quality assurance systems in place, which have to be applied to any project for which they are responsible. However, difficulties may arise when several quality assurance systems are in operation in a multi-agency project. In such a case, it would be possible to include the development of an appropriate quality assurance framework as part of the project itself.
Part of the documentation for a project may include a ‘quality manual’ which describes the aims of the project, how each part of the project system is organised functionally, procedural documentation that states how each task is to be completed, and any relevant technical specifications. The quality assurance process needs to be monitored and communicated to stakeholders, with regular reviews built into the reporting cycle.
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.
This course has focused on planning a project. At this stage you may find it useful to recap on the learning objectives introduced at the beginning of the course and to think about some of the issues associated with them.
You should now be able to develop plans with relevant people to achieve the project's goals. This will involve identifying and finding ways of including the appropriate people in the project.
You should be able to break work down into tasks and determine handover procedures so that the work is manageable and progress can be tracked.
You should be able to identify links and dependencies and schedule to achieve deliverables. We introduced techniques that will help you to schedule and to identify dependencies so that you can plan using the concept of the critical path.
Estimating is part of planning and you should be able to estimate and cost the human and physical resources required, and make plans to obtain the necessary resources.
You should be able to allocate roles with clear lines of responsibility and accountability and to allocate tasks that are realistic and equitable and accommodate other work loads. It is important that the team feel that their tasks are achievable and that they know to whom they are accountable.
You should be able to plan for effective communications within the project activities by establishing appropriate and agreed meeting schedules and reporting control and communication methods.
Except for third party materials and otherwise stated (see terms and conditions), this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence
Figure 3: Elbeik, S. and Thomas, M. (1998), Project Skills, Butterworth-Heinemann Publishers Ltd, a division of Reed Educational & Professional Publishing Ltd;
Figure 9: Lock, D. (1993), The Handbook of Management, Gower Publishing Company Ltd;
Figure 10: Lock, D. (1993), The Handbook of Management, Gower Publishing Company Ltd.
Don't miss out:
If reading this text has inspired you to learn more, you may be interested in joining the millions of people who discover our free learning resources and qualifications by visiting The Open University - www.open.edu/ openlearn/ free-courses