B713_2 Fundamentals of senior management

Planning a project

About this free course

This free course provides a sample of postgraduate study in Business http://www.open.ac.uk/postgraduate/find/business

This version of the content may include video, images and interactive content that may not be optimised for your device.

You can experience this free course as it was originally designed on OpenLearn, the home of free learning from The Open University:
www.open.edu/openlearn/money-management/management/business-studies/planning-project/content-section-0.

There you’ll also be able to track your progress via your activity record, which you can use to demonstrate your learning.

The Open University Walton Hall, Milton Keynes MK7 6AA

Copyright © 2016 The Open University

Intellectual property

Unless otherwise stated, this resource is released under the terms of the Creative Commons Licence v4.0 http://creativecommons.org/licenses/by-nc-sa/4.0/deed.en_GB. Within that The Open University interprets this licence in the following way: www.open.edu/openlearn/about-openlearn/frequently-asked-questions-on-openlearn. Copyright and rights falling outside the terms of the Creative Commons Licence are retained or controlled by The Open University.
Please read the full text before using any of the content.

We believe the primary barrier to accessing high-quality educational experiences is cost, which is why we aim to publish as
much free content as possible under an open licence. If it proves difficult to release content under our preferred Creative
Commons licence (e.g. because we can’t afford or gain the clearances or find suitable alternatives), we will still release
the materials for free under a personal end-user licence.

This is because the learning experience will always be the same high quality offering and that should always be seen as positive
– even if at times the licensing is different to Creative Commons.

When using the content you must attribute us (The Open University) (the OU) and any identified author in accordance with the
terms of the Creative Commons Licence.

The Acknowledgements section is used to list, amongst other things, third party (Proprietary), licensed content which is not
subject to Creative Commons licensing. Proprietary content must be used (retained) intact and in context to the content at
all times.

The Acknowledgements section is also used to bring to your attention any other Special Restrictions which may apply to the
content. For example there may be times when the Creative Commons Non-Commercial Sharealike licence does not apply to any
of the content even if owned by us (The Open University). In these instances, unless stated otherwise, the content may be
used for personal and non-commercial use.

We have also identified as Proprietary other material included in the content which is not subject to Creative Commons Licence. These
are OU logos, trading names and may extend to certain photographic and video images and sound recordings and any other material
as may be brought to your attention.

Unauthorised use of any of the content may constitute a breach of the terms and conditions and/or intellectual property laws.

We reserve the right to alter, amend or bring to an end any terms and conditions provided here without notice.

All rights falling outside the terms of the Creative Commons licence are retained or controlled by The Open University.

Head of Intellectual Property, The Open University

The Open University

978 1 47300 022 3 (.kdl)
978 1 47300 117 6 (.epub)

Contents

- Introduction

- Learning outcomes

- 1 The planning phase

- 2 Taking an overview

- 2.1 Introduction

- 2.2 The classic six-stage project management model

- 3 Where do I start?

- 3.1 Barriers to planning

- 3.2 The project plan

- 3.3 Using a logic diagram to identify key stages

- 4 Identifying deliverables

- 5 Mapping tasks and activities

- 5.1 Introduction

- 5.2 Work breakdown

- 5.3 Team structure and responsibilities

- 6 Scheduling

- 6.1 Introduction

- 6.2 Gantt chart

- 6.3 Identifying the critical path

- 7 Estimating costs, revenues and intangible benefits

- 7.1 Introduction

- 7.2 Revenues

- 7.3 Staff costs

- 7.4 Equipment costs

- 7.5 Materials costs

- 7.6 Who should estimate?

- 7.7 Planning for quality

- 8 Drawing up the implementation plan

- Conclusion

- Keep on learning

- References

- Acknowledgements

Introduction

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

Learning outcomes

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.

1 The planning phase

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:

- 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?

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.

The communications matrix

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.

A communications matrix

Stages

Operations Director

Area Manager

Site Manager

Marketing Director

Equipment Suppliers

Fittings Suppliers

Initial plan

After first site meeting

Operation of unit agreed

On-site work nearing end

Start operations

2 Taking an overview

2.1 Introduction

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.

Figure 2 The life-cycle of a 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.

2.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 (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.

Figure 3 Classic six-phase project management model (Elbeik and Thomas, 1998, p. 14)

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.

3 Where do I start?

3.1 Barriers to planning

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.

Activity 1

0 hours 20 minutes

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?

View discussion - Activity 1

3.2 The project 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.

Example 1: A project manager's view

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.

3.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. 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.

Example 2: Processes in developing a directory

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:

A

Secure funds

B

Negotiate with other agencies

C

Form advisory group

D

Establish data collection plan

E

Collect data

F

Write directory text

G

Identify printer

H

Agree print contract

I

Print directory

J

Agree distribution plan

K

Organise distribution

L

Distribute directory

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.

Figure 4 Logic diagram for directory production

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.

Figure 5 An example of a comparison chart

Activity 2

0 hours 45 minutes

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.

View discussion - Activity 2

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.

Project title

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

Constraints

Assumptions

Timescale of the project

Deliverables and target dates (milestones)

Estimated costs

Resourcing arrangements

Reporting and monitoring arrangements

Decision-making arrangements – level of authority and accountability held by manager of project and arrangments for any necessary
renegotation

Communications arrangements

Signature of sponsor with date, title and authority

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.

Example 3

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.

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.

5 Mapping tasks and activities

5.1 Introduction

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.

5.1.1 SMART objectives

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.

5.2 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 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.

Figure 6 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.

5.3 Team structure and responsibilities

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.

6 Scheduling

6.1 Introduction

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.

6.2 Gantt chart

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.

Figure 7 Gantt chart for directory production

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.

Activity 3

0 hours 25 minutes

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

View discussion - Activity 3

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.3 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.

Example 4

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
(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.

Figure 8 Critical path for directory production

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.)

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

Activity 4

0 hours 30 minutes

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?

Figure 9 Chart to show the main tasks needed to convert a room into a computer suite (Lock, 1993, p. 537)

View discussion - Activity 4

Activity 5

0 hours 30 minutes

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).

Figure 10 Critical path network diagram of the project depicted in Figure 10 (Lock, 1993, p. 538)

View discussion - Activity 5

Activity 6

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.

View discussion - Activity 6

7 Estimating costs, revenues and intangible benefits

7.1 Introduction

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.

7.2 Revenues

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.

7.3 Staff costs

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).

7.4 Equipment costs

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.

Example 5

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.

7.5 Materials costs

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 stationary 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.

7.6 Who should estimate?

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.

7.7 Planning for quality

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.

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.

Conclusion

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

Keep on learning

Study another free course

There are more than 800 courses on OpenLearn for you to choose from on a range of subjects.

Find out more about all our free courses.

Take your studies further

Find out more about studying with The Open University by visiting our online prospectus.

If you are new to university study, you may be interested in our Access Courses or Certificates.

What’s new from OpenLearn?

Sign up to our newsletter or view a sample.

For reference, full URLs to pages listed above:

OpenLearn – www.open.edu/openlearn/free-courses

Visiting our online prospectus – www.open.ac.uk/courses

Access Courses – www.open.ac.uk/courses/do-it/access

Certificates – www.open.ac.uk/courses/certificates-he

Newsletter – www.open.edu/openlearn/about-openlearn/subscribe-the-openlearn-newsletter

References

Anderson, E.S., Grude, K., Haug, T. and Turner, J.R. (1990) Goal directed project management, London, Kogan Page.

Anthony, R.N., and Young, D.W. (1999) Management Control in Non-profit Organizations, 6th edn, Boston, MA, Irwin/McGraw-Hill.

Elbeik, S. and Thomas, M. (1998) Project Skills, Oxford, Butterworth-Heinemann.

Lock, D. (1993) ‘Project management’ in Handbook of Management, 3rd edn, Aldershot, Gower Publishing Company Limited.

Maylor, H. (1996) Project Management, London, Pitman Publishing.

Young, T.L. (1998) The Handbook of Project Management, London, Kogan Page.

Acknowledgements

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

Course image: We have moved! Please visit /highwaysengland in Flickr made available under Creative Commons Attribution 2.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

Activity 1

Discussion

We identified the barriers listed below and suggest ways in which they could have been overcome.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Back

Activity 2

Discussion

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.

Back

Activity 3

Discussion

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.

Back

Activity 4

Discussion

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.

Back

Activity 5

Discussion

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.

Back

Activity 6

Discussion

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.

Back