0% found this document useful (0 votes)
333 views

Study Guide PUB2617

Public administration

Uploaded by

Tebogo Mbewe
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
333 views

Study Guide PUB2617

Public administration

Uploaded by

Tebogo Mbewe
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 91

©

2018 University of South Africa


Second edition 2006
Third edition 2012
Fourth edition 2017

All rights reserved

Printed and published by the


University of South Africa
Muckleneuk, Pretoria

PUB2617/1/2018-2020

70537135

InDesign

CGM_Style
CONTENTS
 Page

Preface vi
How to use this study guide vi
Introduction and general orientation vii
1. General viii
2. Importance of the module viii
3. Status of the module as an academic discipline ix
4. Approach to the module ix
5. Aims of this module x
6. Learning outcomes and assessment criteria x
7. Reasons why project management should be studied in the public sector xi
8. What you can expect of the course xii
9. What do lecturers expect of students? xii
10. Framework of the course xii
11. Necessary resources xiii
12. Conclusion xiv

Theme 1: Project scope and planning


Learning unit 1: Project scope and planning 2
1.1 Introduction 2
1.2 What is a project scope 2
1.3 How should i define the project 4
1.3.1 The project definition meeting 5
1.3.2 The project business plan 6
1.4 Conclusion 10
1.5 Self-assessment 11
1.6 References 11
1.7 Additional reading 12
1.8 Feedback on self-assessment 12

Learning unit 2: Project planning 15


2.1 Introduction 15
2.2 Planning concepts 16
2.2.1 The content of a project plan 17
2.3 Why are plans essential? 18
2.3.1 To coordinate and communicate 18
2.3.2 To control and monitor 19
2.3.3 To satisfy requirements 19
2.3.4 To avoid problems 19
2.4 What should i consider when planning? 20
2.4.1 Uncertainty and risk 20
2.4.2 Choosing between options 21
2.4.3 Hazards 22
2.4.4 Current plans 22
2.5 Planning and projects 22

PUB2617(III)
CONTENTS

2.6 Planning processes 23


2.7 Work breakdown structure (wbs) 24
2.7.1 Involving the project team in creating the WBS 25
2.8 Network diagrams 31
2.8.1 Visual approach 33
2.8.2 Analytical approach 34
2.8.3 Critical path method 38
2.9 Bar charts 40
2.10 Milestones 41
2.11 Conclusion 42
2.12 Self-assessment 43
2.13 References 43
2.14 Additional reading 44
2.15 Feedback on self-assessment 44

Theme 2: Project implementation, control and evaluation 49


Learning unit 3: Project implemen tation 50
3.1 Introduction 50
3.2 How do I execute the project? 51
3.2.1 An implementation issue 51
3.2.2 Implementing the project 52
3.3 How do i control the project? 53
3.3.1 Phenomena influencing execution and causing deviation from
planned project performance 54
3.3.2 Scope creep 54
3.3.3 Murphy’s law 54
3.3.4 Parkinson’s law 54
3.3.5 The student syndrome 54
3.3.6 Pareto’s law 54
3.3.7 Escalation of commitment 55
3.3.8 Statistical variation among dependent events 55
3.3.9 Project monitoring principles 55
3.4 What happens in practice? 55
3.5 Programme evaluation and review technique 56
3.6 What documentation is used for project management? 58
3.6.1 Why report? 58
3.6.2 Guidelines for reporting 59
3.7 Conclusion 65
3.8 Self-assessment 65
3.9 References 65
3.10 Additional reading 66
3.11 Feedback on self-assessment 66

Learning unit 4: Control and evalu ation 68


4.1 Introduction 68
4.2 Why is evaluation important? 68
4.3 Why is ethics important? 69
4.4 What are typical evaluation problems? 69
4.4.1 Standards 69
4.4.2 Application standards 69
4.4.3 Appropriate action 69

(IV)
Contents

4.5 How often should we evaluate? 70


4.6 How to close the project 71
4.6.1 Deliverables for project closure 71
4.6.2 Wrapping up the project 71
4.6.3 Evaluation of performance and management of the project 71
4.6.4 Retrospectives 71
4.6.5 Avoid drift 72
4.6.6 Have a closing event 72
4.6.7 Learn the lessons 72
4.7 Conclusion 75
4.8 Self-assessment 75
4.9 References 76
4.10 Feedback on self-assessment 76

PUB2617(V)
PREFACE
Public management is a dynamic field of study that has to adapt constantly to a
range of environmental influences. These environmental influences, which can be
related to the open-systems approach, demand that public managers be flexible,
but at the same time demonstrate accountability towards the clients they serve.

Public institutions have a responsibility towards their clients. This means in es-
sence that public institutions must deliver services and products to the public
in order to improve their welfare and general wellbeing. To put it another way,
public institutions and the people who work in them are responsible for creating
an enabling environment in which the public can prosper.

This module, and indeed the whole course, was designed and developed to fulfil
a need expressed by public institutions operating at local, provincial and national
levels in South Africa. The environment in which public institutions operate has
changed, making new skills and qualifications necessary. Therefore the quali-
fications in Public Administration and Management have been re-curriculated.

The re-curriculation of the qualifications in Public Administration and Management


made the study of different topics necessary. The aim, therefore, was to develop
a complete course that would cover all the knowledge, skills and competencies
that a public manager requires to deliver quality services to the public. Each
study unit is intended as a unique contribution to the field of public management
and to provide public managers with the necessary skills and competencies to
manage their institutions effectively and efficiently.

Lecturers
Public Administration and Management

HOW TO USE THIS STUDY GUIDE

This study guide has been compiled with the goal of providing students, who may
well ultimately join the management corps of the public sector, with the neces-
sary knowledge, information and sensitivity to deal effectively with a number of
issues in South African society. It is intended to serve as a basis and guideline
for the application of management functions and processes, as well as a useful
source of information for those who simply wish to orient themselves regarding
the environment, functions and processes of the public sector.

The study guide is divided into four study units. Each study unit starts with a route
map that shows you where you are and how the study unit fits into the module
as a whole. The aim of the route map is to provide you with a mental map of the
structure of the complete study guide.

Study units start with learning objectives, in line with SAQA requirements and com-
plying with the National Qualifications Framework (NQF) guidelines. These learn-
ing objectives tell you what you should be able to do by the end of each study
unit and during formal assessment.

In the text you will find helpful hints and pointers, as well as activities that will
help you focus your attention so that you remain objective-oriented regarding the
learning content. These activities should provide you with some of the answers

(VI)
Preface

that you will need to complete the self-assessment questions at the end of each
study unit. The self-assessment questions are intended to help you to understand
and apply the key aspects of the study unit. Feedback on the self-assessment
questions is supplied at the end of each study unit. This feedback provides you
with pointers and guidance, and will assist you in assessing your own progress
during your studies.

Before we begin, a quick note about being messy: As you might already have
discovered in your studies and in getting involved with volunteering and other com-
munity projects, things can very quickly get messy. For us, messy is good. It
is an important part of the experiential learning process. If you produce a big,
messy tangle of writings, diagrams, drawings, photographs, newspaper clippings
and links to online materials, such as videos and articles, it is a sign that you are
really serious about creating your own understanding of Community Psychology
intervention strategies. It also shows your appreciation for the fact that change is
a richly complex, contradictory and confusing phenomenon. We would rather that
you go away from this module thinking “Wow! Getting involved and changing
things is a lot more complicated than I thought!”, than that you go away with
some neat, clean and all-encompassing (and maybe even dangerous) theory that
claims to explain every aspect of the change process. 

The self-assessment questions form an extensive question bank that is used in


other forms of assessment during the course. For example, we use the question
bank when we compile your assignments. In other words, if you work system-
atically through all the activities and self-assessment questions in the manual,
you should not have any difficulty in answering the assignment questions. The
same goes for the final examinations. The examinations are set from the self-
assessment questions at the end of each study unit and are also in line with the
learning objectives at the beginning of each study unit.

INTRODUCTION AND GENERAL ORIENTATION

“When government has the right people, and the right system, and the right inten-
tions, many good things are possible. The trick is to know which ones they are.”

Alan Ehrenhalt

1. General
We are happy to introduce you, as an undergraduate student, to the dynamic
environment of project management (which will be referred to from now on as
PUB2617). We hope that the study guide and the tutorial material will serve their
purpose and be helpful to you in completing your course.

The module, Project Management IIB, was designed to meet the needs of a
wide range of students. The method of presentation provides an excellent back-
ground for everyone involved in this learning area who is interested in obtaining
knowledge or preparing themselves for a career in project management within
the public sector.

Experts who give their consideration to the subject of Project Management will
see the value of this module, because it also has a firm theoretical foundation
and focuses on issues such as project definition and scope, project planning,

PUB2617(VII)
PREFACE

project implementation and project control and evaluation. You will note that
we do not follow a narrowly specialised approach for this module, but prefer to
focus on a holistic interaction between the various activities which make up the
project management function, almost a postmodern approach. The study guide
is presented in such a way that practically any interested student should be able
to study generic aspects as well as the more fundamental processes.

Policy makers, advisors, managers, project management and other role players
also need to know about PUB2617, as a discipline with the sole purpose of gen-
erating knowledge as well as of making public sector institutions more success-
ful. However, what does it mean to be a project management practitioner in the
context of the public sector? In simple language it means the extent to which an
institution succeeds in its core business and its impact on service delivery. You
must realise that people study Public Administration with the aim of achieving
the stated and quantifiable macro objectives of government as well as those of
the institution concerned.

2. Importance of the module


This module, and indeed the whole course, was designed and developed to fulfil
a need that public institutions express when operating at local, provincial and
national level in South Africa.

A senior project management practitioner once commented that all prospective


public managers and project management practitioners should be prepared in a
professional way so that they can deal with project management matters properly.
This person based the comments on the belief that public servants should pos-
sess a broad spectrum of practical knowledge in project management in general.
In short, this implies that a module such as PUB2617 is of the utmost importance
for those who wish to prepare themselves for a career in the public sector.

PUB2617 has become important as an academic subject for the following reasons:
(1) The environment in which the public sector’s activities takes place, requires
the effective and efficient delivery of services, and projects could be used
as a means to deliver services.
(2) New technology emphasises the need for continuous training.

3. Status of the module as an academic discipline


We can trace the origins of a form of management by projects as far as the
construction of the pyramids in ancient Egypt and the Great Wall of China (Van
der Waldt & Knipe 1998:61). In other words, project management and aspects
thereof have been present for decades and even centuries.

In South Africa project management also started to catch on in the construction, infor-
mation technology, defence and development sectors. Principles of project manage-
ment were being applied even in education, publishing and the government sectors.
However, it was only during the early 1990s that project management dramatically
gained popularity in the government sector. Since then, numerous local, provincial
and national institutions have run project management training courses for their staff.

Project management is therefore not something completely new in the South


African public sector. It is probably only its terminology that is still unfamiliar.

(VIII)
Preface

However, the tools and techniques have been in use for quite a number of years.
For this reason, project management should not be completely new to people
in the public sector.

4. Approach to the module


Project management is a dynamic branch of Public Administration and can,
therefore, not be studied in isolation. It is closely related to the other branches
in Public Administration such as Human Resource Management and Financial
Management.

Students, who are registered for PUB2617, must ask themselves why they are
studying the subject. It is a relevant question, since there are so many problems
associated with project management and its practice. While you are studying the
subject, you must constantly be aware that you are looking for new knowledge. In
order to come to the so-called “truth”, you should be investigating and analysing
phenomena such as the disciplining of staff and the appointment procedures for
staff. In order to prepare you more adequately for the workplace, it has become
clear that more input should be made at academic level. Therefore, it is our
plan, on the other hand, to follow an academic approach, so as to equip you, the
student, with as much scientific knowledge of project management as possible.

You are, however, also jointly responsible for acquiring this scientific knowledge.
The academic approach will expose you to the values of the subject and the
larger field of study, so that you can understand the environment in which project
management activities take place. On the other hand, we also want to follow a
skills approach.

With the skills’ approach we want to develop your skills in such a way that you
will be more equipped to fulfil the project management function in a professional
way. The knowledge you acquire as a result of the academic approach, must be
used as a starting point for the professional management and administration of
projects in the public sector.

We would also like to bring certain academic methods to your attention, such
as research, assignments and case studies. These methods can allow you to
practise relevant practical tasks and skills in project management. If you are suc-
cessful in mastering these methods you should be in a position (be competent)
to manage projects in an effective and efficient manner.

5. Aims of this module


As you should know, this module does not stand alone and is not offered in isola-
tion. It forms an integral part of other disciplines such as management, policymak-
ing, finance organising and transformation of public administration. However, it is
our overall objective here to continue the study of PUB2617, to examine its role
and influence, and to say more, on a more advanced level, about specific theories,
views, perspectives, approaches, models, concepts and applications. We intend
to introduce you to the project management challenges facing managers in the
public sector, in order to ensure that they take the right decisions that will keep
public officials happy, motivated and productive so that they can deliver quality
service. Note that we cannot discuss all the various dimensions of PUB2617 in
this module because they are too divergent and it is quite simply impossible to

PUB2617(IX)
PREFACE

cover them all in one module. We will deal only with a limited number of relevant
themes. It should also be clear to you by now that PUB2617 cannot be regarded
as a pure science because it deals with human behaviour, which is unpredictable,
and this makes it difficult to demarcate the subject area. Therefore, you will find
that the contents of the module can be approached in different ways. This is why
this module is uniquely presented in a Unisa context, and why you will find that it
must necessarily differ from the way the subject is taught at other higher educa-
tion institutions. In spite of this, we have tried consistently to structure the themes
in such a way that they cover a large part of the subject area.

PUB2617 is a flagship module within Public Administration, since people actu-


ally manipulate the entire spectrum of activities in the public sector workplace.
In other words, project management does not only focus on certain segments
of the subject area, but is active in practically every aspect of public administra-
tion. PUB2617 is a unique sub-discipline within Public Administration and offers
you, the student, theories, philosophies, models and learning challenges, which
you will not encounter in any other curriculum or programme. You will have to
use a helicopter approach (a holistic view) of the subject when you learn about
PUB2617. Your studies in PUB2617 will bring you as close as possible to the real
public administration as it exists in practice.

6. Learning outcomes and assessment criteria


In order to ensure that this module is nationally and internationally accredited, we
have registered it in the National Qualifications Framework (NQF) as indicated below.

Syllabus/subjects covered/essential prior knowledge:


•• project definition and scope
•• project planning
•• policy implementation
•• project control and evaluation
NQF level: 6
Credits allocated to module: 12
South African Qualifications Authority Field: Public Administration and Management

You might not be familiar with the meaning of concepts like NQF and SAQA.
Briefly, these are government structures responsible for ensuring that all South
African qualifications are nationally and internationally accredited. At present, all
South African qualifications are graded on nine levels (NQF levels 1 to 9). Note
that each level indicates clearly what knowledge, skills and values you need to
master in order to be declared competent on that level. The number of credits
allocated to the module also indicates the number of hours which you will (ideally)
take to master the learning outcomes set in the various study units. In practice,
this means that you will have to spend at least 120 hours on this module in order
to master the learning material. You can divide the 120 hours like this:

•• Working through the study guide, consulting the recommended books, reading
other sources like academic textbooks and journal articles, obtaining information
on the internet, watching relevant DVDs and videos, attending seminars and
conferences and talking to experts in the field = 40 hours
•• Completing activities in the study guide and completing assignments =40 hours
•• Preparing for the examination = 40 hours

(X)
Preface

The general learning outcome for the module is to make the comprehensive,
systematic, organised and clear knowledge in the field of project management
available to you so that you will be able to prepare yourself for related tasks in the
public sector workplace and elsewhere using self-study, case studies, learning,
assignments activities and any other research methods.
Specific learning outcomes have also been formulated for this module. The learn-
ing outcomes of this module are as follows:

LEARNING OUTCOME 1 (THEME 1)


The student will learn the project definition and will be able to undertake project
scope and planning.

ASSESSMENT CRITERIA
In the form of tasks, various activities and self-evaluation questions in the study
guide, a multiple-choice assignment, an essay-type assignment and a written
examination, students will be assessed on their ability to:
•• discuss the importance of project definition
•• define a project in your community or work environment
•• determine the feasibility of a project
•• write a business plan for a project
•• provide an overview of project planning as a phase in the project life cycle
•• identify the steps in project planning
•• explain strategic planning in projects
•• illustrate the use of work breakdown structures during planning
•• illustrate the use of network diagrams during planning
LEARNING OUTCOME 2 (THEME 2)
The student will be able to understand project implementation, control and evalu-
ation by using the correct procedures.

ASSESSMENT CRITERIA
In the form of tasks, various activities and self-evaluation questions in the study
guide, a multiple-choice assignment, an essay-type assignment and a written
examination, students will be assessed on their ability to:
•• execute a project according to an approved plan
•• compare project goals and objectives with actual results
•• use reports for project control and monitoring
•• explain the importance of closing a project
•• conduct a project review
•• compile a final project report

7. Reasons why project management should be studied in the public sector


In view of the previous discussion, you might be wondering if it is really necessary to
study Project Management IIB (PUB2617). You might ask: “What’s in it for me?” You
are a student in the field of Public Administration, whether in one of the related mod-
ules at undergraduate or postgraduate levels, and you will quite possibly find yourself
in one of two main employment areas, as a manager or as an operational worker.

You should also remember that these two employment areas are to be found in every
specialisation area of the public sector, including the project management function.

PUB2617(XI)
PREFACE

8. What you can expect of the course


As lecturers, we are well aware that we need to deliver high quality service to
you, the student. This has led us to conclude that we need to create a learning
environment which promotes learning. For this purpose, we undertake to:
•• provide you on an ongoing basis with augmented, relevant learning material
which is regularly compared with similar local and international project
management courses
•• liaise on an ongoing basis with employers and the profession in order that
we can compile and develop the learning material for project management in
such a way that the needs of the public sector will be met
•• give you the support you need in your studies as and when you want it
•• provide you with clear guidelines on formative and summative assessment so
that you will know what is expected of you
•• provide you with feedback on your assignments in good time. In this regard we
will strive to return your assignment, with our feedback on it, within three weeks
of the closing date if you hand in the assignment on or before the closing date

9. What do lecturers expect of students?


Unisa has various guidelines for different subject areas, so you need to be quite
clear that we, as lecturers in the Department of Public Administration and Man-
agement, expect our students to:
•• take personal responsibility for the learning process, because we expect you
as students to have an acceptable level of skill to cope with human resource
problems in the public sector
•• be sensitive to and have empathy with the cultural and academic views of other
students, and in this way to work together effectively in order to contribute to
the work needed in the field of PUB2617
•• read with insight about human resource theories and philosophies, and to
interpret and report on them insightfully and scientifically in the broader context
of Public Administration
•• collect human resource information from a wide range of sources, to analyse
it innovatively, organise it creatively and evaluate it critically within the field of
Public Administration
•• investigate human resource problems in the public sector with understanding,
analyse them thoughtfully and solve them judiciously
•• manage the learning process in the field of PUB2617 responsibly by evaluating
your own progress and acquiring skills for completing assignments, writing
examinations and doing research
•• use scientific methods and technological aids effectively in order to master
the learning activities, while at the same time taking responsibility for the
environment and the welfare of other people

10. Framework of the course


In order to ensure that all students achieve the learning outcomes, we have ar-
ranged the learning material as follows:

(XII)
Preface

•• Themes. The contents of the study guide are arranged in themes. For instance,
theme 1 begins with the topic “Project scope and planning”. Each theme
consists of an overview, which poses certain key questions (which can actually
be regarded as learning outcomes) and explains key concepts, which, in turn,
are set out in study units.
•• Study units. Each study unit consists of an introduction, learning activities and
a retrospective section in the form of self-evaluation questions to determine
whether you have achieved the learning outcomes. The self- evaluation
questions will give you an indication of the knowledge you needed to acquire
and serve as guidelines on the types of questions we will set in the examination.

You will only make a success of this module if you follow these study hints:
Study on the basis of the key questions provided for you at the beginning of
each theme. Remember these questions as you work through the study units
and make sure that you have a sound understanding of the learning outcomes
and assessments criteria.
•• Complete all the activities and make sure that you understand the subject
matter which each of them is testing.
•• Answer the self-evaluation questions at the end of each study unit to make
sure that you have mastered the content of that particular section.
•• Make sure that you know what you will be tested on in this module. Your
progress will be tested by means of:
• formative assessment
• summative assessment

Formative assessment takes place when you complete the activities in the study
guide and the assignments in the tutorial letter. The examination at the end of
the academic year is a summative assessment. You should assess your own
progress constantly, and revise those aspects of each learning outcome which
in your opinion you need to improve.

You will notice in figure 1 below that this module is divided into two (2) themes
with four (4) study units.

THEME 1: PROJECT SCOPE AND PLANNING


Study unit 1: Project definition and scope
Study unit 2: Project planning

THEME 2: PROJECT IMPLEMENTATION, CONTROL AND EVALUATION


Study unit 3: Project implementation
Study unit 4: Project control and evaluation

11. Necessary resources


In Tutorial Letter 101 there is a list of the resources you will need to achieve
the learning outcomes of this module. Note that you will need these resources
to complete the activities in every study unit.

Prescribed books
There are no any prescribed books for this module.

PUB2617(XIII)
PREFACE

Recommended books
Please consult the recommended books and sources as contained in the 101
tutorial letters or any other relevant source, including articles in Project Manage-
ment or Public Administration journals, internet documents and newspaper articles
that deal with Project Management.

12. Conclusion
It is our belief that this introduction and general orientation will help you to tackle
your study of this module (PUB2617) with greater clarity. Some of the literature
in this module may seem strange to you at first, but you will see as you progress
with your study of this module that we have not moved outside the framework of
the guidelines mentioned earlier in (10).

We would like to point out that successful study of this interesting field (Project
Management) ought to lead to attractive career opportunities in the public sector,
and also that you have entered a dynamic field of knowledge in Public Admin-
istration which can offer you important challenges in the academic world. The
vital need to utilise project management optimally in the public sector so as to
increase the institutional work rate has existed for a long time as a discipline and
will continue to do so. This discipline is aimed at expanding the research area
using independent thinking and well considered practices.

We hope that you will find the contents of this module interesting and instructive,
and that you will enjoy them with us.

WE WISH YOU EVERY SUCCESS WITH YOUR STUDIES.

(XIV)


THEME 1
PROJECT SCOPE AND PLANNING

Learning unit 1:
Project scope and planning 2

Learning unit 2:
Project planning 15

PUB2617/11


1 LEARNING UNIT 1
1 PROJECT SCOPE AND PLANNING

LEARNING OUTCOMES
After studying this study unit, you should be able to:
•• discuss the importance of project definition
•• define a project in your community or work environment
•• determine the feasibility of a project
•• write a business plan for a project

1.1 INTRODUCTION
Your project has been identified and a team has been put together to start a
project. However, it would be irresponsible to start implementing the project im-
mediately. The team members must first determine exactly what is expected of
them. This is what is generally referred to as project scope or definition.

Defining the project is very important because it is the only opportunity that team
members will get to clarify the basic elements of what is required of them. Often
teams start planning or sometimes just implementing, without asking what they
have to do and by when and with what. The “W-questions” is what I refer to as
the critical questions any project team should ask before it starts to plan and
implement the project.

Let me tell you a story – and I really wish that it were not true – about a team that
didn’t ask those important W-questions and thus didn’t define its project properly.
The team was given the task of constructing a new primary school in Middelburg.
The project was implemented and on the day when the new school was handed
over to the community, one of the elders in the community approached the team
manager and asked, “Why did you build us another school here when we have
a big enough school just a couple of street blocks away?” Naturally the project
manager immediately realised something was wrong and started to review the
plans and initial instructions. Only then did they realise that the school was sup-
posed to be built in Middelburg, Mpumalanga and not Middelburg, Eastern Cape!

You can imagine the enormous cost and great deal of work that went into this
project and, in the end, it was in the wrong location. That is why it is so important
for every team member to know exactly what needs to be done, where, when,
with what and why. This study unit will provide information and guidelines on
determining exactly what your project is all about – information that is necessary
before you can determine how it should be done.

1.2 WHAT IS A PROJECT SCOPE


“Scope” is an interesting word with a number of meanings. Though not used by
all project managers, it is nonetheless a useful and important concept. Work that

2
LEARNING UNIT 1:  Project scope and planning

needs to be done to deliver a product, service or result with specified features


and functions can be referred to as the project scope (Newton 2015:8). Fox and
Van der Waldt (2007: 44) argue that project scope is about the size of the project.
However, it is not until the end of the project, or at least not until it is well under
way, that it is known what “everything” is. So, while a definition that says scope
is everything that is in the project may be precise, it is fairly useless.

According to Fox and Van der Waldt (2007:44) project scope can include one or
more of the following considerations:
•• all that the project needs to achieve
•• when the project should start and end
•• the total obligation of resources (money, people, supplies, equipment)
The purpose of scope is to tell you and the team what is in the project; it is a
guide to the project sequence. An example of scope could be where a building
of certain dimensions and characteristics is required.

After initial work, a concrete structure is chosen as opposed to a steel building – a


building was the purpose of the project sequence, not a concrete building. Having
decided on a concrete building as the project, the definition of what should be in
the project has been modified from “a building” to “a concrete building”. The deci-
sion on concrete will guide subsequent work on the project, but it is not at its core.

It should be clear from the above that the project scope develops and even
changes to a certain degree with the project. This change in the scope is also
called scope variation. A project scope statement should be written down and
stakeholders in the project must accept this scope statement.

To keep things on track and ensure that the scope variations are not that dramatic,
there need to be some signposts. These signposts always lead eventually to
people, to the client and to the stakeholders. These signposts are also referred
to as project objectives.

PMBOK (2013:18) state that in order to understand and to document the project
objectives and requirements, you as the project manager need to interview the
project client to determine:
•• What belongs within the scope of the project?
•• What work needs to be done?
•• When the end product is needed?
•• Who needs to be involved?
•• You may also ask about any additional considerations.
The scope of a project puts boundaries on the planning process and deliverables.
The scope must outline the specific outcomes or deliverables as well as those
activities and deliverables which fall outside the scope of the project.

Scope “creep” is a term which is used for describing the process of adding work to
a project, little by little, until the original schedule and cost estimates become mean-
ingless. Project managers must ensure that there is not any “creep” in the project
plan and that it is agreed to in writing as well as in the budget and schedule changes
(Fox & Van der Walt 2007:45). You will learn more on this concept in section 3.3.2.

The project client is the person or organisation that wants the work done. It can
be a department or the community or a private organisation. Here are some ques-
tions that you will need to ask the project client to determine the project objectives:

PUB2617/13


•• What do you really want?


•• Is there a specific time when you need it? What circumstances have mandated
this time-frame?
•• What are the exclusions, if any (for example, the computer system will not be
implemented in the Accounts Department)? What specifications do not have to
be included in this project (in other words, what are the minimum specifications)?
•• What standard will you use to measure the end product?
•• How do you see the end product performing?
•• What will be the use(s) for the end product?

Fox and Van der Waldt (2007:44) states that scope management includes the
processes which are necessary to ensure that the project includes all of the
work required, and only that, in order to complete the work successfully. Scope
management includes the following processes:
•• Initiation: committing the organisation to start the following phase of the project
•• Scope planning: developing a written scope statement as the basis for future
project decisions
•• Scope definition: subdividing the major project variables into smaller more
manageable components
•• Scope verification: formalising acceptance of the project scope
•• Scope change control: controlling changes to the project scope

According to Larson and Gray (2011:102) the following project scope check-
list, which includes examples, can be used to ensure that the scope definition
is complete:
•• Project objective: to construct a high-quality, townhouse within five months at
a cost not to exceed R1,500,000
•• Deliverables: a 1,500 square foot, 2 bath, 3 bedroom, finished townhouse
•• Kitchen appliances to include oven, hob, microwave and dishwasher
•• Milestones: permits approved by March 10 or final inspection by June 20
•• Technical requirements: townhouse must meet local building codes

Ceiling insulation must meet an “R” factor of 25. Structure must pass seismic
stability codes.
•• Limits and exclusions: owner responsible for landscaping. Refrigerator is not
included in kitchen appliances. Site work is limited to Monday to Friday, 08:00
AM to 06:00 PM.
•• Reviews with the client: Thabo and Leonie Champion.

The scope statement is a summary of all the information discussed above. This
information now needs to be used, together with the identified constraints or risks,
and any assumptions for the scope of project definition (for example, if the date
that materials will be delivered is uncertain, the team may assume a specific date).

1.3 HOW SHOULD I DEFINE THE PROJECT?


When a need is identified and a project chosen, the project needs to be defined
so that all stakeholders know exactly what they are letting themselves in for and
so that they can clarify all uncertainties about the project. One way of defining
the project is a meeting involving the project team and role-players.

Larson and Gray (2011:101) indicates that defining a project involves five steps, which are:
•• defining the project scope
4
LEARNING UNIT 1:  Project scope and planning

•• establishing project priorities


•• creating a work breakdown structure (WBS) (this will be discussed later)
•• integrating the WBS with the organisation
•• coding the WBS for the information system
Although scope and definition are very similar, they are discussed here separately
to distinguish between the two concepts. Please note that project definition is
only a part, and probably the most important part, of project scope.

1.3.1 The project definition meeting


It is strongly recommended that all stakeholders for the project come together for
a first meeting. It is not necessarily the team only that should attend the meeting.
However, it is recommended that the project manager take charge of the meet-
ing. The purpose of such a meeting would be to get to know all the stakeholders
and to resolve any possible problems and clarify uncertainties.

The following issues should be discussed at the definition meeting:


•• Who are the members and what are their respective fields of expertise?
In other words, get to know the people with whom you will be working closely
during the duration of the project.
•• What are the roles of each member? In other words, why are you on the team
and what skills do you bring to the team?
•• What are the responsibilities of each member? Or what is expected of you as
a project team member?
•• What about a code of conduct? Often it is included in some way in a project
charter (the document specifying all the details pertaining to the project). A
code of conduct provides some rules to abide by when dealing with project
matters.
•• When and where the next meeting will take place. You can even start to
schedule all project team meetings for the duration of the project, but these
dates would typically be adapted as the project progresses.

The project manager takes the lead and, as the chairperson, directs the dis-
cussion until there is consensus. Only those people with a direct interest in the
project should be invited to the meeting – thus all the stakeholders. The time
should be limited so that the team can focus on the main aspects. These main
aspects could include some or all of the aspects listed above. The objectives of
the meeting should be clear. In other words, the project manager (chairperson)
should clarify the purpose of the meeting when calling the meeting.

The project manager has to manage trade-offs in relation to criteria including


time, cost and performance. This means that project managers must define and
understand the priorities of the project. In order to establish the importance of
each criterion, a discussion with the client and senior management needs to oc-
cur. (Larson & Gray 2011:106).

During this meeting – if time permits – the team can start defining the project.
Sometimes it would be necessary to schedule a second meeting specifically for
defining the project.

Typical agenda items could include the following:

PUB2617/15


Sample agenda of a project definition meeting


Purpose: Defining the project
•• Background to the choice of project (data gathered during the feasibility
study)
•• Why this particular project?
•• What are the parameters of the project (time-frame, allocated budget,
beneficiaries, goal, location, etc)?
•• List of possible problems confronting the project team
•• List of possible solutions to these problems
•• List of factual information that the team will need (ie maps, surveys,
legislation, etc)
•• List of initial tasks and responsibilities (Who would bring which of the above
documents to the next meeting or make them available to the team?)
•• Rough framework for planning (What are the deadlines for the project?)

The definition of the project is particularly important if funds have to be raised.


Developers want to know exactly what the project is all about, and a clearly
written document is needed for this. All related matters must be in writing so
that nothing important is left out during the planning phase. The advantage of a
written document is that the project manager cannot be blamed later if something
has not been done. Everyone must participate in formulating the document. It is
important to gather factual information.

Note that a detailed document can be submitted only after the planning phase,
because the time schedules, all activities and people responsible have not yet
been finalised. Include the following aspects, which are required to define the
project, in this document:
•• destination or location of the project, i.e., who will benefit from it and where
•• objectives and/or milestones
•• size and extent of the project
•• factual information and client approval
•• planned completion date (optimistic and pessimistic)
•• available and required resources
•• allocated budget (material, transport, etc.)
•• people responsible, i.e. the team members and other stakeholders
You should never be afraid to ask questions. When a task is given and you are
in any doubt, it is imperative to get clarity on all issues. Get the project advocate
(initiator or identifier) to explain exactly what is meant by each of the parameters
of the project. Ensure that everyone in the team understand exactly:
•• What the extent of the project will be?
•• Where it will take place?
•• When it should be completed?
•• How much money was allocated?
•• Who will do it?
•• Who will benefit from it?
•• Why it should be implemented?
1.3.2 The project business plan
All this information should typically be set out in the project business plan. I
have provided an example of a project business plan below. However, it is very

6
LEARNING UNIT 1:  Project scope and planning

important to understand that business plans, just like projects, are unique. When
you compile a project business plan, it would be a good idea to approach the
intended funding agency to determine the exact requirements so that the project
team and project advocate and sponsor can apply for funding. Different institutions
have different requirements for business plans, mainly because of their focus
areas. It is important to consider these differences and specific requirements
when compiling a business plan for your project.

SAMPLE TEMPLATE FOR A TYPICAL PROJECT BUSINESS PLAN

[Cover page]

LOGO OF ORGANISATION
NAME OF ORGANISATION
PROJECT PROPOSAL/BUSINESS PLAN
TITLE:
[Insert project title here]

[2nd page]

Enquiries: [Insert contact person]


Tel.: [Insert telephone number here]
Date: [Insert date here]
[Insert the name and contact details of the organisation to which this pro-
posal is directed]

PROJECT OF
[Insert the name of the organisation that will pay for the project here]
TITLE:
[Insert project title]
SECTOR:
[Insert sector, e.g., Health]
EXECUTING AGENCY:
[Insert name of your organisation/team here]
IMPLEMENTATION DATE:
[Insert initiation (start) date and completion date]
PROJECT BUDGET:
[Insert total project budget]
PROJECT FUNDING REQUIRED:
[Insert amount requested from donor]
PROJECT SUMMARY:
[Insert a brief summary of project purpose, objectives and anticipated
outcomes]
TARGET AUDIENCE:
[Insert a brief description of who the intended beneficiaries of the project are]

PUB2617/17


[Next page]
INTRODUCTION
[Insert a brief description of the project]
1. THE PROBLEM
[Insert a description of the problem the project intends to address. Include
all necessary details to indicate importance of project]
2. CONTEXT
[Describe the historical, socio-economic and political factors that will affect
the project. Include a brief description of current government policies in this
area, any obstacles or favourable factors, past attempts at resolving the
problem and any exploratory work already done on this project]
3. ORGANISATIONAL FRAMEWORK
[Describe your organisation and the magnitude of the work it has per-
formed in the intended project sector, existing facilities available to the
institution, and qualifications and experience of staff. Indicate the project
management experience of the organisation]
4. JUSTIFICATION
[Justify the solutions put forward to solve the problems]
5. PROJECT STRATEGY
[Discuss alternative solutions and explain why they would not be success-
ful. Indicate why your proposed solution is the best based on rational and
cost-effective reasons. Explain the impact on the proposed beneficiaries
and provide proof of the sustainability of the scheme, that is, whether it will
collapse after the project is completed or whether it will continue]
6. TARGET BENEFICIARIES
[Focus more precisely on who the target beneficiaries are. Provide a socio-
economic profile of beneficiaries, covering factors such as purchasing
power, social status, whether they can be mobilised and at what stage of
the project they become involved]
7. EXPECTED RESULTS
[Explain the end product of the project in terms of the benefits for the
beneficiaries, ie what they will have gained and how the project has altered
their lives qualitatively and quantitatively]

8. PROJECT IMPLEMENTATION
8.1 Main outcome
[Indicate the primary outcome of the project at a macro (large-scale)
level and how it contributes to society]
8.2 Project outcomes
[Indicate the immediate outcomes of the project. There should be a
maximum of three objectives and they should focus exclusively on the
problem. They must be concrete and achievable, verifiable and easy to
evaluate. They should be able to be quantified so that you can check
whether the project was a success]
8.3 Project activities (or outputs)
[Each of the identified project outcomes needs to be divided or broken
down into a cluster of homogenous activities (activities of the same kind)
that can be implemented together to achieve the immediate outcome]
8.4 Project inputs
[Indicate all the material and other requirements for implementing the
project activities. These should be listed in a neutral fashion, i.e., not

8
LEARNING UNIT 1:  Project scope and planning

brands (such as Mecer Pentium) just technical specifications (Pentium II


personal computer)]
8.5 Budget
[Prepare an annual budget breakdown based on local prices (if you are
applying to a foreign donor, add conversion to US dollars or foreign cur-
rency in brackets next to Rand amounts)]
8.6 Project workplan
[Assign starting and ending periods to each project activity and the re-
sources and the personnel who will execute them. Donors appreciate it
when you display this information in the form of a Gantt chart (which we
will discuss in study unit 6)]
8.7 Monitoring and evaluation
[Make provision for project monitoring every six months and evalua-
tion every six or 12 months after project initiation. These periods are of
course dependent upon project duration. This information should also
appear in the workplan and Gantt chart]

9. CONCLUSION
[Explain the impact of the project on the targeted population and how it has
improved circumstances by solving the problem]
ANNEXURES
[Attach any other documentation that may be of assistance to the funder/
donor]

The above information should serve as a guideline only and can be used to compile
business plans in general. The information included in this template is typically
the information required by most institutions. However, ask questions in order
to determine the exact requirements of the organisation that will provide money
for your project.

The project charter contains not only the information typically contained in the
project business plan, but also includes information such as the project team struc-
ture and code of conduct. Many authors and sources refer to the project charter
as the most important document in any project. The project charter establishes
the authority of the project manager and specifies important parameters. Fund-
ing and deadlines can sometimes be modified as a detailed project unfolds, and
the baseline data provided for in the project charter will give the project team a
sense of the purpose and scope of its tasks (Brown & Hyer 2010:99).

An example of a Project Charter: Blue Diamond Medical Services Project


Charter

Organisation’s mission: To maintain a premier position of leadership in


the medical device industry by designing, continuously improving and pro-
ducing high quality medical equipment.
Purpose of the project: The purpose of the project is to improve project
selection, management and learning. Such improvements will support our
mission by helping to ensure our ability to maintain a position of leadership
in the industry.
Expected results: Ongoing improvement in our ability to select, plan and
execute projects will result in projects being completed on time, within
budget and with excellent technical results. This will in turn help to save on
costs and satisfy clients.

PUB2617/19


Project objective: To create a project management office which will cre-


ate avenues for best practice sharing, offer training, create avenues for
best-practice sharing, facilitate problem solving and encourage coopera-
tion across projects.
Project sponsor: Thabo Mokoena, Director-General; Project Manager:
Riaan Cruywagen
Project stakeholders: All the organisation’s employees involved in man-
aging or supporting projects, supply chain management, engineering and
administrative services.
Preliminary project deliverables include:
•• curriculum and materials for training programmes, to educate the
organisation on the standard project management process
•• a project measurement system
•• a system for capturing and disseminating lessons learned
•• a website to support and coordinate project activities across the project
Preliminary project budget: R500,000 in outside costs, plus 3,000 hours
of internal staff and management time (These numbers may be revised
after the project team has developed a more complete plan).
Preliminary completion date: Based on estimates the project is set to
begin on 1 August and move to routine operational phase by 15 February.
(This will also be subject to adjustment based on the team’s initial work).

Source: Brown & Hyer (2010: 100).

Activity
Define a project that was identified in your organisation or community by using
the guidelines provided in this study unit. Compile a document that contains all
this information, which could be used as a project proposal or business plan.

1.4 CONCLUSION
Sometimes it happens that your employer gives you a project and you simply
have to “do the work”. So, what happens to project definition and scope when
the time-frame, budget, people and objectives are planned and given to you in a
document? Do you forget about the whole scope definition process?

No! In fact, by defining the project for yourself and the team, you can determine
the exact impact of the given information. In other words, define the project for
yourself, even if it means asking the same information from the boss again. He
or she may lift an eyebrow, but you will definitely not regret it. Remember that
some information is in place – you just have to verify the information that your
boss gave you.

10
LEARNING UNIT 1:  Project scope and planning

If you do find that there are some areas where you disagree with the information
that your boss provided to you with, don’t set ultimatums or change the docu-
mentation without consultation. Rather present management with some alterna-
tives. However, the same applies when dealing with a community project. You
just need to put on kid gloves and treat the initiators from the community very
carefully and tactfully so as to convince them that your alternatives and ideas
are actually more viable.

Project definition and scope is important for all projects because, in the words
of LJ Peter in Kerzner (1995), “If you don’t know where you are going, you will
probably end up somewhere else”.

In study unit 2, we will focus on the fourth step in the project life cycle, namely
project planning. While it is sometimes neglected, it is probably the most impor-
tant step in the project life cycle, that is, apart from the actual implementation!

1.5 SELF-ASSESSMENT
(1) What is a project scope? (10)
(2) Describe the concept of “scope creep”. (2)
(3) Discuss the five (5) processes of scope management. (10)
(4) Discuss the project scope checklist which you can use to ensure
that the scope definition is complete. (12)
(5) Defining a project involves five (5) steps. List the five (5) steps. (5)
(6) Discuss the project definition meeting in detail. (10)
(7) List any five (5) agenda items of a project definition meeting. (5)
(8) List the main aspects that should form part of most project
proposals or business plans. (20)
(9) Discuss and provide an example of a project charter. (12)

1.6 REFERENCES
Brown, KB & Hyer, NL. 2010. Managing projects: a team-based approach. New
York: McGraw Hill.
Duncan, WR. 1996. A guide to the project management body of knowledge. Up-
per Darby, Pa: Project Management Institute.
Fox, W & Van der Waldt, G. 2007. A guide to project management. Cape Town:
Juta & Co.
Newton, P. Managing project scope: project skills. E-book. www.free-manage-
ment-ebooks.com
Kerzner, H. 1995. Project management: a systems approach to planning, schedul-
ing and controlling. 5th edition. New York: Van Nostrand Reinhold.
Knutson, J & Bitz, I. 1991. Project management: how to plan and manage suc-
cessful projects. New York: American Management Association.
Larson, EW & Gray, CF. 2011. Project management: the managerial process.
New York: McGraw Hill.
Maylor, H. 1996. Project management. London: Pitman.
Van der Waldt, G & Knipe, A. 1998. Project management for strategic change
and upliftment. Johannesburg: International Thompson.

PUB2617/111


1.7 ADDITIONAL READING


Bender, SA. 1997. Managing projects well: what they don’t teach you in project
management school. Singapore: Butterworth-Heinemann.
Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw-Hill.
Morris, PWG. 1994. The management of projects. London:
Telford, T & Rosenau, MD. 1992. Successful project management: a step-by-step
approach with practical examples. 2nd edition. New York: Van Nostrand
Reinhold.

1.8 FEEDBACK ON SELF-ASSESSMENT


(1) Refer to section 1.2 to check your answer.
“Scope” is an interesting word with a number of meanings. Though not used by
all project managers, it is, nonetheless, a useful and important concept.

Everything that the project encompasses can be defined as the project scope
(Healy1997:252). Fox and Van der Waldt (2007:44) argue that project scope is
about the size of the project. However, it is not until the end of the project, or at
least not until it is well under way, that it is known what “everything” is.

So, while a definition that says scope is everything that is in the project may be
precise, it is fairly useless.

(2) Refer to section 1.2 to check your answer.


“Scope creep” is a term which is used for describing the process of adding work
to a project, little by little, until the original schedule and cost estimates become
meaningless. Project managers must ensure that there is not any “creep” in the
project plan and that it is agreed to in writing as well as in the budget and schedule
changes (Fox & Van der Waldt 2007:45).

(3) Refer to section 1.2 to check your answer.


Scope management includes the following five processes:
•• Initiation: committing the organisation to start the following phase of the project
•• Scope planning: developing a written scope statement as the basis for future
project decisions
•• Scope definition: subdividing the major project variables into smaller more
manageable components
•• Scope verification: formalising acceptance of the project scope
•• Scope change control: controlling changes to the project scope

(4) Refer to section 1.2 to check your answer.


According to Larson and Gray (2011:102), the following project scope check-
list, which includes examples, can be used to ensure that the scope definition
is complete:
•• Project objective
•• Deliverables
•• Milestones
•• Technical requirements
•• Limits and exclusions
•• Reviews with the client

12
LEARNING UNIT 1:  Project scope and planning

(5) Refer to section 1.3 to check your answer.


Defining a project involves five steps, which are:
•• defining the project scope
•• establishing project priorities
•• creating a work breakdown structure (WBS) (this will be discussed later)
•• integrating the WBS with the organisation
•• coding the WBS for the information system
(6) Refer to section 1.3 to check your answer.
The project definition meeting
It is strongly recommended that all stakeholders in the project come together for
a first meeting. It is not necessarily the team only that should attend the meeting.
However, it is recommended that the project manager take charge of the meeting.
The purpose of such a meeting would be to get to know all the stakeholders and
to resolve any possible problems and clarify uncertainties. The following issues
should be discussed at the definition meeting:
•• Who are the members and what are their respective fields of expertise? In
other words, get to know the people with whom you will be working closely
during the duration of the project.
•• What are the roles of each member? In other words, why are you on the team
and what skills do you bring to the team?
•• What are the responsibilities of each member? Or what is expected of you as
a project team member?
•• What about a code of conduct? Often it is included in some way in a project
charter (the document specifying all the details pertaining to the project). A
code of conduct provides some rules to abide by when dealing with project
matters.
•• When and where the next meeting will take place. You can even start to
schedule all project team meetings for the duration of the project, but these
dates would typically be adapted as the project progresses. The project
manager takes the lead and, as the chairperson, directs the discussion until
there is consensus. Only those people with a direct interest in the project
should be invited to the meeting – thus, all the stakeholders. The time should
be limited so that the team can focus on the main aspects. These main aspects
could include some or all of the aspects listed above. The objectives of the
meeting should be clear. In other words, the project manager (chairperson)
should clarify the purpose of the meeting when calling the meeting.

The project manager has to manage trade-offs in relation to criteria including


time, cost and performance. This means that project managers must define and
understand the priorities of the project. In order to establish the importance of
each criterion, a discussion with the client and senior management needs to oc-
cur. (Larson & Gray 2011:106). During this meeting – if time permits – the team
can start defining the project. Sometimes it would be necessary to schedule a
second meeting, specifically for defining the project.

(7) Refer to section 1.3 to check your answer.


Agenda items could include the following:
•• Background to the choice of project (data gathered during the feasibility study)
•• Why this particular project?
•• What are the parameters of the project (time-frame, allocated budget,
beneficiaries, goal, location, etc.)?

PUB2617/113


•• List of possible problems confronting the project team


•• List of possible solutions to these problems
•• List of factual information that the team will need (i.e. maps, surveys, legislation,
etc.)
•• List of initial tasks and responsibilities (Who would bring which of the above
documents to the next meeting or make them available to the team?)
•• Rough framework for planning (What are the deadlines for the project?)

(8) Refer to section 1.3 to check your answer.


The following are the main aspects that should form part of most project propos-
als or business plans you are expected to elaborate your discussion.
•• destination or location of the project, in other words, who will benefit from it
and where
•• objectives and/or milestones
•• size and extent of the project
•• factual information and client approval
•• planned completion date (optimistic and pessimistic)
•• available and required resources
•• allocated budget (material, transport, etc.)
•• people responsible, in other words, the team members and other stakeholders
(9) An example of a project charter is provided in section 1.3. Please do check
on the internet for more examples.

14
2 LEARNING UNIT 2
2 PROJECT PLANNING

LEARNING OUTCOMES
After studying this study unit, you should be able to:
•• give an overview of project planning as a phase in the project life cycle
•• explain planning in general and project planning in particular in South Africa
•• identify the steps in project planning
•• explain strategic planning in projects
•• illustrate the use of work breakdown structures during planning
•• illustrate the use of network diagrams during planning
•• integrate project planning, risk planning, cost estimating and budgeting, time
estimating and activity sequencing

2.1 INTRODUCTION
In this – the first – decade of the new century, planning appears to have become
a buzzword. In our workplaces, adaptability, responsiveness to customer needs,
employee empowerment, quality circles, decentralisation and sweeping organi-
sational re-engineering are all symptoms of a climate which has transformed the
winds of change of the 1960s into hurricanes of disorder and chaos in the late
1990s and early 2000s. These winds of change and many others have challenged
and overthrown many traditional management wisdoms that were built on the
concepts of planning and control. Some see planning as a dirty word, which is
associated with reactive management forms, while others want to plan everything
they do to the smallest detail.

But is planning an outmoded and outdated concept or is it a powerful and flexible


tool whose use managers have to relearn in the volatile management environ-
ment? Successful projects require planning – they don’t just happen – and that
planning must be capable of withstanding the buffeting of the increasingly unset-
tled environment in which we all work.

Planning is the act of creating a plan, and a typical dictionary tells us that this is a
diagram, table or programme which indicates the relationships of a set of objects
or times, places and so on of intended actions. For most of us, our plans involve
actions and, if they are to contribute to the success of those actions, they tell us:
•• When they are to be done?
•• Who is to do them?
•• What do we need to do them? For example, equipment, tools, techniques
and so on.
However, plans are not just a detailed list of actions. At worst they can represent
the rigid, inflexible and doctrinaire (dogmatic) demands of others which suppress
and choke our creativity and spontaneity. But, at best, they are powerful tools
that embody our visions, hopes and desires. These plans can be used flexibly
to communicate the why, what, how and when of those visions and hopes to oth-

PUB2617/115


ers and form the basis of those co-operative efforts that characterise successful
teams. But, whatever the management theorists might have in store for us next,
we will all continue to need to reach out and try to shape and control our future.
Plans are a proven and effective tool, which, if used well, will enable us to suc-
ceed in all our projects.

Planning is of major importance to a project because the project involves do-


ing something that has not been done before. As a result, there are relatively
more processes in this phase of the project life cycle. However, the number of
processes does not mean that project management is primarily planning – the
amount of planning performed should be in line with the scope of the project and
the usefulness of the information developed.

We will discuss the planning processes, tools and techniques in this study unit.
I will illustrate planning tools such as the work breakdown structure, Gantt chart
and PERT diagram. You will note that this is the longest study unit in this study
guide. Take your time working through the material and take frequent breaks to
allow you to digest the material.

2.2 PLANNING CONCEPTS


In broadest generality, plans depend on three factors:
•• knowing where you are now (or will be when whatever is being planned for
will start)
•• knowing where you want to get to
•• defining in which way you will get from where you are to where you want to be

Let me illustrate these factors in the diagram below:

Many projects are initiated because of the organisation’s long-term plan. Thus,
plans are frequently hierarchical, with short-term plans established within the
context of long-term plans. For example, project task plans are components of the
overall project plan. In addition, planning is interactive, so project plans must be
revised when other plans change. For example, when the long-term plan covers
five years, changes obviously occur, priorities must be altered, and projects are
added or cancelled in response to the dynamic environment.

Burke (2010:76) defines plan as an intended future course of action.


The Project Management Body of Knowledge (PMBOK) in Burke (2010:75) defines
a project management plan as the process of documenting the actions neces-

16
LEARNING UNIT 2:  Project planning

sary to define, prepare and integrate and coordinate all the supporting plans.
The project management plan then becomes the main source of information for
the project management process, i.e. initiation, planning, execution and closing.
The project manager is the owner of the project management plan.

Burke (2010:76) states that a plan in its simplest form contains the following
information:
•• Objectives: What are the goals and objectives?
•• How to: How to achieve the goals and objectives?
•• Resources: What people, materials and equipment are required/available?
•• Activities: Sequence of activities with details of time, cost and quality.
A plan is a set of actions or steps through which the project manager aims to
achieve a predefined goal or objective. Planning involves the process of think-
ing about the activities which are required to achieve predefined objectives or
output. The project manager is prompted to ask the questions: why, what, when,
where, who, how to, and how much in order to assist the team members who
are responsible for project execution. This will assist with creating awareness
among the team members and stakeholders and helps to solve problems and
strives for decisions based on consensus (Burke 2010:76).

The planning process also involves the identification of the communication needs
of the stakeholders, what information they require, when it should be communicated
and how. The planning process communicates planning information to the stake-
holders, encouraging them to participate in the process and obliging them to “sign
on” and pledge their support for the project. If all the stakeholders are not involved
in the planning process, this may lead to plans being misinterpreted and ignored.

2.2.1 The content of a project plan


According to Baca (2007:38) a project plan should contain the following information:
•• Scope information: The scope statement must be captured in the project
management plan.
•• Work breakdown structure (WBS): The WBS is a hierarchical depiction of
the activities of the project and it is a great tool for getting new team members
up to speed on your project.
•• Schedule: After the WBS has been completed, the activities can be used
to create a schedule with it. The schedule should cover major milestones in
addition to the major deliverables.
•• Risk plan: The risks should be identified in the project plan as well as the
mitigation of the risks. The risk response plan is also part of the project plan.
•• Human resources strategy: All the information regarding human resources will
be included in the project plan. This includes the project organisation structure,
a resource calendar, roles and responsibilities and even a placement plan,
which will specify where the resources will go when the project is complete.
•• Cost elements: This information includes the cost baseline, which is used
during the execution of the project so that you can compare what you planned
to spend to what you are spending.
•• Communication plan: Here you will describe what information you will send
at what point in time during the life of your project.
•• Procurement plans: This will include a description of resources, which will
be procured outside of the organisation. Resources can mean tools and
equipment or human resources and how to get the resources on your project.
•• Quality management: This will include describing how you will guarantee
the quality of the processes, which you will execute.

PUB2617/117


•• Project execution plan: Everything which you will plan to do should be


covered in this plan, including change control and configuration management.
•• Execution monitor and controlling: This must be included to ensure that
delivery is guaranteed on time and on budget. You must also include which
performance reports will be generated and how you will take action when
things go wrong.

Activity
Define planning in your own words.

2.3 THE IMPORTANCE OF PLANS


In short, plans are essential in aiding co-ordination and communication, provid-
ing a basis for controlling and monitoring, satisfying requirements and helping
to avoid problems. The following are the detailed reasons:

2.3.1 To coordinate and communicate


Most projects involve more than one person. Typically, a technical expert is asked
to perform in the area of his/her expertise. For example, a carpenter works on
wood framing, not the plumbing or electrical wiring in a construction project. Simi-
larly, an expert on electronic circuit design works on the electronic circuit design
task, not on the optical design task for an electro-optical system. The project plan
informs everyone on the project on what is expected of him/ her and what oth-
ers will be doing. Plans are a vehicle to delegate portions of the triple constraint
(cost, time and quality) down to the lowest (task or subtask) reporting level. If
the people responsible for these tasks also participate in making plans, they will
have an added impetus to stick to them. Remember, the golden rule for planning:

Get the persons who will do the work to plan the work.
•• They should know more about the work than anyone else.
•• They are the ones responsible for the tasks, so the tasks are theirs, not yours.
Your project plans matter. Even if your project can be performed in your office,
other people in the organisation will want to know where your project is headed,
what you are doing and for how long you will be doing it. Thus, project plans
constitute an important communication and coordination document and may
motivate people to perform better.

18
LEARNING UNIT 2:  Project planning

2.3.2 To control and monitor


Plans are also the basis of your project monitoring and controlling.

It is common that sometimes projects do not go as planned. When you start a


project, you do not know where and how it will deviate from the plan. During the
project performance your monitoring process will detect deviations from plan
that should alert you of problems to be resolved. This should help you to re-plan.

When an aero-plane takes off from OR Tambo International Airport in Kempton-


park heading towards Cape Town, there is a planned course to be followed. Dur-
ing the flight, the navigator makes measurements of the plane’s position, noting
whether the path being followed has deviated from the one that was planned at
the beginning. If there is a deviation, the pilot changes course after the navigator
notes the deviation so that the plane can arrive at Cape Town. If the pilot does
not correct the flight path, the plane might have to land in the Atlantic Ocean.
This would be as disastrous for the plane as a similar outcome would be for a
project that deviated too far from its intended triple constraint point for which re-
planning was not done.

Plans are a detailed description, formulated before the project is carried out, for
accomplishing its various aspects. Deviations may indicate that the project will
not reach its intended destination.

2.3.3 To satisfy requirements


Plans are sometimes created merely to satisfy requirements that one person
imposes on others – perhaps a customer or your boss. In this situation, plans
are often created under duress rather than being perceived to be valuable, even
essential, in achieving project objectives. Plans created in this way are frequently
not followed. All too often they are generated and then discarded because they
were prepared only to meet the requirement to prepare a plan. When plans are
required and the plans are prepared slavishly rather than thoughtfully, it is a waste
of time for the preparer and the reader.

2.3.4 To avoid problems


Less experienced project managers often find project management to be a race
against disaster. For example, too often a new crisis may arise while you are
still busy resolving the earlier crisis, and then the project manager is too busy to
anticipate and try to head off the next one.

A good plan helps you to avoid problems during project execution, but plans can-
not prevent problems. Consider the following example of a schedule and cost
problem. Your project requires a final report. You planned that it will require sixty
pages, and the technical documentation group, which will prepare the report,

PUB2617/119


agrees to do it in one week for R1 000. When you later realised that your planning
was not correct and you ask them to prepare a one-hundred-page report, they
tell you that you will get it two weeks later and it will cost R2 000. Obviously, you
have to plan carefully to make sure that you will be able to get the report on time
and within the budgeted amount. You must make the best plans and estimates
as possibly as you can and then try to adhere to them. For example, as you get
to the final phase of your project and must prepare the report, assign writing to
the participants in such a way that they all clearly understand the planning goal.
These participants must also do their utmost best in the report writing to adhere
to plans. If you do this, the report should be approximately sixty pages.

Activity
Explain the need for planning on a page in your notepad.

2.4 WHAT SHOULD I CONSIDER WHEN PLANNING?

2.4.1 Uncertainty and risk


Plans relate to future events. This means that your plans are a simulation of how
things will occur in the future. The future holds uncertainties, some of which may
be somewhat predictable and thus partially controllable, but many of which are
unpredictable.

Your objective is to be as confident as possible about those things that are pre-
dictable. You also need to be fully confident that you will successfully achieve the
triple constraint. But there will always be uncertainties, unanticipated tasks and
outcomes, unexpected options and unfortunate mistakes – so total confidence
in complete success is naïve. The best you can do is work towards all the objec-
tives, while recognising that many totally unexpected developments will challenge
you and your team.

You can use checklists to reduce (but not eliminate) these predictable uncertain-
ties, thoroughly discussing the plans with experts and involving your entire team.
Nevertheless, uncertainties will remain because there are always unpredictable
factors when you are doing something new. You can also insert contingency al-
lowance in your plans to allow for these unknowns, but you cannot eliminate the
unknowns. For example, thorough plans cannot prevent bad weather or strikes
from delaying a construction project or eliminate cost changes due to currency
rate fluctuations. Plans can be no better than your present understanding. If you
have done something similar before, you can plan it better than if it is entirely new
to you and your team. For example, past experience with electrification projects
is not terribly helpful for planning a water project.

Assumptions, such as which people will be able to work on your project, are
involved in planning. The plan for the water project looks a lot different when a

20
LEARNING UNIT 2:  Project planning

senior civil engineer will do the work than when a junior electrical or chemical
engineer will. Because assumptions are involved in your planning, it is important
to include contingencies. Good plans are quantitative rather than qualitative and
as precise as possible.

2.4.2 Choosing between options


In preparing plans, as in carrying out project work, you are frequently confronted
with options. These choices may include programme management options,
product quality standards, extent of subcontracting to be undertaken, and so on.
Your plan may be considered the record of your choices between these options
and will normally depend on how much risk you are willing to take or how much
contingency allowance is included in your plans.

Project participants will frequently present a plan that seems absurd to you. It
may in fact be completely absurd. But perhaps the person who prepared it is
simply emphasising activities you did not stress. A common project task, ordering
required materials, illustrates this problem. Sensible choices are to order these
materials as early as possible (to be certain they are available when required)
or as late as possible (to reduce the possibility of having to change selection or
to help your organisation’s cash flow). It is important to discuss the perceptions
of everyone involved in the undertaking.

Or imagine your boss asks you at 09:00 to join him/her on a 17:00 transcontinental
flight to attend an important meeting. You agree and arrange to meet at the air-
port. This arrangement allows you to pass by your house en route to the airport
and pack your suitcase. In this simple example, your plan might be as follows:

Tasks

A Tell secretary to make


travel reservations

B Call spouse to tell


him/her about the trip

C Pack briefcase

D Have secretary obtain


and deliver tickets

E Go home, pack suitcase


and go to airport

Time

The sequence of tasks A, B and C may not seem to matter here; and it does not
in terms of your time. But it is desirable to start your secretary’s assignment as
soon as possible so that he/she can perform task D while you do tasks B and C.
Thus, you should perform task A first, but you can do C before B (or vice versa)
without any schedule delay.

PUB2617/121


2.4.3 Hazards
There are innumerable hazards in preparing project plans. In an attempt to gain
time in the early phases of a project or because you are addicted to your own
ideas, you may tend to do much of the planning yourself. You should avoid this for
the same reason you do not like to be told to carry out somebody else’s plan – it
is demotivating. In fact, the golden rule is to involve the people who will actually
be doing the work so they can plan their work as much as possible.

In addition, poor planning frequently occurs. Other than sheer laziness, almost
all poor planning is based on a misunderstanding of the triple constraint point.
Taking the time to create plans allows you to identify your perception of the triple
constraint point and shows whether it differs from somebody else’s.

2.4.4 Current plans


Once you have decided to plan your project and have issued the plans, people
should take them seriously. They can do so only if they know the plans are cur-
rent. Therefore, it is very important to know who has copies of these plans. When
you revise plans, you should provide revisions to all people who have copies
of previous plans. When you do this conscientiously, everyone involved in your
project will know that you take planning seriously. They will know their copies
of the plans are a reliable indication of the project intention. You can increase
others’ assurance by dating all planning documents, and revisions must have a
revision serial number and date.

Activity
Discuss the planning issues referred to in this section and any other issues you
feel are important to project planning on a clean sheet of module in your notepad.

2.5 PLANNING AND PROJECTS


A project plan is the mechanism by which we convert the objectives of a project
from statements of intent to the concrete reality of achieved outcomes. If we fail
to create such a plan then not only do we put at risk our ability to create the de-
sired outcome of the project but we also limit our ability to create that outcome
as desired.

Project definition provides us with our starting point for the creation of the project
plan. But in order to convert the goals and objectives into a plan we also need
to know the answers to the following questions:
•• What actions are needed?
•• When do these actions need to start or finish?
•• How long will they take?
•• Who will perform them?
•• What equipment, tools and materials are needed?
22
LEARNING UNIT 2:  Project planning

You also need to know what the budgeted cost of the project is and in what
way the quality of the outcome is to be defined since both of these could af-
fect either the way that you undertake the required actions or even the actions
themselves. Next, you need to know whether any of the actions can be started
before other actions are finished. In the jargon of project planning this is usually
called “interdependency”.

Regardless of the accuracy level of the initial estimate, a successful project needs
a plan that meets the following standards:

Content. The plan should contain enough detail to make it meaningful and usable
but not so much detail that it becomes unnecessarily complicated. The content
should be clear and unambiguous.
•• Understandability. A plan that can be easily understood by all who use it is
vital to the success of the project.
•• Changeability. An effective plan is one that can be easily changed, updated
and revised.
•• Usability. The plan must be in a form that facilitates communication and the
monitoring of project progress.

A good plan will have all the above characteristics but will still need the skills,
abilities and creativity of people to make it come to life. A bad plan will not only
be difficult to understand or contain inadequate or irrelevant detail but it will also
limit or even neutralise the vital contribution of those people’s skills, abilities and
the creativity.

It is a bad plan that admits no modification.


Publius Syrus, 1st century BC

Activity
In your notepad identify and discuss all the aspects that must be included in any
project plan.

2.6 PLANNING PROCESSES


The initiating processes in the project life cycle lead to the planning processes.
Some planning processes have clear dependencies that require them to be
performed in essentially the same order in most projects. For example, activities
(tasks) must be defined before they can be scheduled or costed. The following core
planning processes may be iterated several times during any phase of the project:
•• Scope planning – developing a written scope statement as the basis for future
project decisions.
•• Scope definition – subdividing the major project deliverables into smaller, more
manageable components.

PUB2617/123


•• Activity definition – identifying the specific activities (tasks) that must be


performed to produce the various project deliverables.
•• Activity sequencing – identifying and documenting interactivity dependencies.
•• Activity duration estimating – estimating the number of work periods (hours,
days, weeks, months) which will be needed to complete individual activities.
•• Schedule development – analysing activity sequences, activity durations, and
resource requirements to create the project schedule.
•• Resource planning – determining what resources (people, equipment, materials)
and what quantities of each should be used to perform project activities.
•• Cost estimating – developing an estimate of the costs of the resources needed
to complete project activities.
•• Cost budgeting – allocating the overall cost estimate to individual work items.
•• Project plan development – taking the results of other planning processes and
putting them into a consistent, coherent document.

There are many tools and techniques for planning that project managers and their
teams can use. We will discuss some of the most prominent, tried and tested tools
in the next section. Take a break so that you can return fresh for our discussion
on the work breakdown structure, which is an important planning tool.

2.7 WORK BREAKDOWN STRUCTURE (WBS)


Brown and Hyer (2010: 132) defines a work breakdown structure (WBS) as “a
deliverable oriented hierarchical decomposition of the work to be executed by
the project team, to accomplish the project objectives and create the required
deliverables. The WBS organises and defines the total scope of the project... The
planned work contained within the lowest level WBS components which are called
work packages, can be scheduled, cost estimated, monitored and controlled.”

Larson and Gray (2011:108) states that after the scope and deliverables have been
identified, the work of the project can be subdivided into smaller work elements.
The outcome of this process is called a work breakdown structure (WBS). The
WBS is a map of the project and helps to assure project managers that all the
work elements are identified to integrate the project with the current organisation
and to establish a basis of control. The WBS is an outline of the project with dif-
ferent levels of detail. Major project work deliverables are identified first, then the
sub-deliverables to accomplish the larger deliverables. This process is repeated
until the sub-deliverable detail is small enough to be manageable and where one
person can be responsible. The sub-deliverable is further divided into work pack-
ages. The lowest sub-deliverable usually includes several work packages and is
grouped by type of work, e.g. hardware programming and testing. The groupings
within a sub-deliverable are called cost accounts. They also facilitate a system
for monitoring projects progress by work, cost and responsibility.

The work breakdown structure (WBS) is a checklist of every task that must be
performed to create the end product. This checklist becomes the foundation for
the schedule, resource allocation and budget plans. In other words, it is a conveni-
ent method for dividing a project into small work packages. A WBS reduces the
likelihood of something being overlooked. To put it another way, a WBS is intended
to assure that all the required project tasks are logically identified and related.

According to Burke (2010:137) the structure and content of the work packages
and deliverables can be defined as follows:

24
LEARNING UNIT 2:  Project planning

•• Ownership: Who will be responsible for the work package? A key project
management philosophy is to assign ownership to all aspects of the project.
•• Deliverables: The scope of the work must be broken down into tangible
deliverables such as the individual components of a car.
•• Scope of the work: The scope describes what has to be made or performed
and by implication, what is not included.
•• Independent: The work packages should be independent of each other so
that they can be managed separately.
•• Specifications: The specifications define what the work packages need to
achieve and outline what is the required standard.
•• Quality requirements: The quality requirements outline the required condition,
the level of inspection and the qualifications of the workforce.
•• Estimate person hours: The estimate of person hours is a measure of the
work content per work package.
•• Duration: The duration is the trade-off between the work content and resources
available.
•• Budgets: A budget is the amount of money assigned to complete the work
package. Some organisations might limit the work package to a specific
maximum amount e.g. R300 000 (amount could be less or more).
•• Procurement: The procurement lists all the bought items per work package
•• Resources: The resources identify all the machines and people required
to complete the work.
•• Equipment/materials: The equipment list identify all the equipment and plant
hire that are required per work package.
•• Similar size: The work packages should be of a manageable size, typically
between 20 to 80-person hours.
•• Number: The work packages should be uniquely identified with a number.

2.7.1 Involving the project team in creating the WBS


The project manager and the team can start to create the WBS when they have
a clear picture of the purpose or mission and scope of the project. There are
many advantages in involving the team in WBS development. The team members
are the content experts and are best equipped to know what is actually involved
in compiling and generating each deliverable and how to break tasks down into
doable work packages. If team members are involved in WBS development, they
will have a systems view of the total project and the interrelationships among
project elements. Participation will build commitment to the project and people
will be more likely to support what they have helped to create. Collaboratively,
creating a WBS brings conflicting views and unresolved questions to the surface
when it is not too late to address it (Brown & Hyer 2010:136).

There is no magic formula for constructing a WBS. The following figure shows
two levels of detail, but there is no standard number of levels to use. In general,
probably at least three or four should be shown, but it might sometimes be ap-
propriate to show five or ten or even more. The breakdown might occur using
earlier or later tasks, particularly organisational involvements, or almost anything
that makes reasonable sense.

This figure is also known as a “tree diagram” in project management.

PUB2617/125


Install new software


package

Assess
Design Develop Text Implement
requirements

A Assess B Design C Modify F Test I Implement


requirements purchased purchased new software
package package package

D Modify G Test J Train staff


in-house in-house
procedures procedures

E Modify H Test
manual manual
systems systems
flow flow

In general, it is best to structure the WBS on tangible, deliverable items, both


software and hardware. The customer, in the case of some projects awarded by
a contract, such as providing water pumps to the Department of Water Affairs,
can dictate the WBS layout and numbering.

The more work packages you have in your project, the smaller and cheaper
each work package becomes. However, the more work packages you have, the
more money and time are spent in arranging for these to be properly managed
and interfaced with each other. Small WBS tasks with short durations improve
the precision of project status monitoring. Conversely, if you have only one work
package, there is no interfacing cost, but the task itself is large and expensive.
Therefore, you have to strike a happy medium as you gain experience. In gen-
eral, you should break your project into smaller work packages which are under-
standable and easy to manage. The more closely each WBS task conforms to
prior experience, the more realistic and accurate your plan’s schedule and cost
estimate becomes. Another consideration in deciding how large a single WBS
task should be is whether it will be the responsibility of a senior or junior person
and his/her relevant experience.

The WBS defines the work packages and will be tied to attendant schedules and
budgets for the work performers. Thus, it is desirable for the lowest level pack-
ages to correspond to small work increments and short-time periods. It is often
helpful to indicate who the task leader is by putting his/her name in the WBS box
for the task. To make it less cluttered, initials can be used for this purpose. It is
also possible to insert the WBS number and schedule or budget information. In
any event, the WBS can clarify organisational responsibility on a project.

In preparing a WBS, do not forget required tasks such as analyses or trade-off


studies that must be done but that do not have specific deliverable items. Also
remember to include reports, reviews, meetings and coordination activities. In
fact, displaying them on a WBS is a good way of highlighting that they are neces-
sary and that resources must be devoted to them.

It is desirable to involve the whole team when making the WBS. A good way of
doing this is by means of a brainstorming session. This ensures that oversight

26
LEARNING UNIT 2:  Project planning

will be minimised and even eliminated. An outsider may even be asked to make
a WBS, which can then be used to highlight discrepancies and oversights.

The best practice in project management is to make a WBS as illustrated in figure


above. However, another way of preparing the WBS is to brainstorm the com-
plete project and capture all tasks that the team mentions. Then the tasks can
be listed – similar to the diagrammatic way. Write each of the identified tasks on
a separate post-it notepad and then start to put them in a logical sequence. The
other information, such as the person responsible, budget, start and finish dates
and durations can also be captured on these notes.

After the initial WBS has been made, schedule planning can commence. The
schedule planning may identify further items to be added to the WBS. Although
less likely, the same may occur as you do cost planning. You will then have to
revise the WBS to include these work packages so that everything on the WBS
is finally tied to scheduled work packages and budgets and vice versa.

In summary, the WBS is a specialised technique that determines the success


of the entire project. It is described as a hierarchical structure designed to sub-
divide all the work elements of a project logically into a graphical presentation.
Furthermore, WBS helps or provides a tool for the project manager and team to
define the project’s full scope of work accurately and quickly.

Activity
Explain your understanding of a work breakdown structure on a sheet of module.

You can use the following steps to make a WBS:


•• Firstly, write the full scope of work (title of the project) at the top of the diagram.
•• Secondly, subdivide the scope of work uniformly into smaller elements of work
at each lower level of the breakdown.
•• Lastly, put work packages at the lowest level of the structure.

The WBS can be most effective when the scope of the project is outlined and
when specific responsibilities are assigned to each work package. You can make
the WBS according to a subdivision by description. This means that:
•• level one tasks represent the full scope of the work
•• level two is the first subdivision of the work into the main tasks
•• level three is where each task is further subdivided into work packages
PUB2617/127


The following table illustrates what a more comprehensive WBS could look like:

Number Task Duration Start date Finish date

1.1.5.3 Special event 680h Fr. 98/01/02 Th. 98/04/30

1.1 Pre-planning 560h Fr. 98/01/02 Th. 98/04/09

1.1.1 Initial planning 8h Fr. 98/01/02 Fr. 98/01/02


meetings

1.1.1.1 Determine budget 1d Fr. 98/01/02 Fr. 98/01/02

1.1.1.2 Invitation list 1d Fr. 98/01/02 Fr. 98/01/02

1.1.2 Selection 120h Mon. 98/01/05 Fr. 98/01/23

1.1.2.1 Theme 2d Mon. 98/01/05 Tu. 98/01/06

1.1.2.2 Date 3d Wed. 98/01/12 Fr. 98/01/09

1.1.2.3 Site 1w Mon. 98/01/12 Fr. 98/01/16

1.1.2.4 Costumes 1w Mon. 98/01/19 Fr. 98/01/23

1.1.3 Hire 168h Mon. 98/01/26 Mon. 98/02/23

1.1.3.1 Caterer 2d Mon. 98/01/26 Tu. 98/01/27

1.1.3.2 Entertainment 9d Wed. 98/01/28 Mon. 98/02/09

1.1.3.3 Keynote speaker 2w Tu. 98/02/10 Mon. 98/02/23

1.1.4 Public relations 88h Tu. 98/02/24 Tu. 98/03/10

1.1.4.1 Alert community 2w Tu. 98/02/24 Mon. 98/03/09

1.1.4.2 Press release 1d Tu. 98/03/10 Tu. 98/03/10

1.1.5 Rent equipment 40h Wed. 98/03/11 Tu. 98/03/17

1.1.5.1 Rent tents 2d Wed. 98/03/11 Th. 98/03/12

1.1.5.2 Rent audio-visual 2d Fr. 98/03/13 Mon. 98/03/16


equipment

1.1.5.3 Rent tables and 1d Tu. 98/03/17 Tu. 98/03/17


chairs

1.1.6 Meet with caterer 16h Wed. 98/03/18 Th. 98/03/19

1.1.6.1 Menu selection 1d Wed. 98/03/18 Wed. 98/03/18

1.1.6.2 Drink selection 1d Tu. 98/03/19 Tu. 98/03/19

1.1.7 Hire personnel 40h Fr. 98/03/20 Th. 98/03/26

1.1.7.1 Bartenders 1d Fr. 98/03/20 Fr. 98/03/20

28
LEARNING UNIT 2:  Project planning

Number Task Duration Start date Finish date

1.1.7.2 Security 2d Mon. 98/03/23 Tu. 98/03/24

1.1.7.4 Clean-up crew 1d Th. 98/03/26 Th. 98/03/26

1.1.8 Arrangements 80h Fr. 98/03/27 Fr. 98/04/09

1.1.8.1 Transportation for 1d Fr. 98/03/27 Fr. 98/03/27


speaker

1.1.8.2 Event 3d Mon. 98/03/30 Wed. 98/04/01


transportation

1.1.8.3 Flowers 4d Wed. 98/04/08 Wed. 98/04/08

1.1.8.4 Table decorations 1d Wed. 98/04/08 Wed. 98/04/08

1.1.8.5 Lighting 1d Th. 98/04/09 Th. 98/04/09

1.2 Event preparation 48h Fr. 98/04/10 Fr. 98/04/17

1.2.1 Buy room 1d Fr. 98/04/10 Fr. 98/04/10


decorations

1.2.2 Buy party gifts 1d Mon. 98/04/13 Mon. 98/04/13

1.2.3 Set up equipment 2d Tu. 98/04/14 Wed. 98/04/15


for event

1.2.4 Decorate 2d Th. 98/04/16 Fr. 98/04/17

1.2.5 Special event 0d Fr. 98/04/17 Fr. 98/04/17

1.3 Event wrap-up 72h Mon. 98/04/20 Th. 98/04/30

1.3.1 Clean-up 2d Mon. 98/04/20 Tu. 98/04/21

1.3.2 Pay bills 4d Wed. 98/04/22 Mon. 98/04/27

1.3.3 Write thank-you 2d Tu. 98/04/28 Wed. 98/04/29


letters

1.3.4 Write event 1d Th. 98/04/30 Th. 98/04/30


summary

1.3.5 Vacation 0d Th. 98/04/30 Th. 98/04/30

Other columns that can be added to this table are:


•• one for the cost of each item
•• one for the person responsible for each item
•• one for the standard of quality required
•• one for the performance indicator that will be used to determine quality
While templates are not a magic formula for any project management tool or tech-
nique, the following template should provide some guidance on how to compile
a WBS in table format:

PUB2617/129


Performance indicator
Budget
Person responsible
Duration
Task
No.

The following is an example of a chart that the project manager and project team
can use to monitor responsibility during the planning and eventual implementa-
tion of the project:

30
LEARNING UNIT 2:  Project planning

LINEAR RESPONSIBILITY CHART

Project: Notebook Date 01 July 2017 Sheet: 1 of 1


for project issued:
manager

Manager: Jim Serapu Date 12 July 2017 Filename: NBFPM


received:

Project contributions
TASK
Vusi John Cynthia Patrick Norman

Design forms 2 1

Layout of forms 1 2

Draft guidelines 1 2

Design package 1 2 2

Develop sales plan 1 2 2

Production coordination 1 2 2

Codes: 1=actual responsibility, 2=support, 3=must be notified, blank=not involved

Activity
Identify a project at work or in your community. Use the techniques and guidelines
provided in this section to compile a WBS. Make use of the tree diagram method
as well as the template provided. Take a break after this activity to reward yourself
before we start focusing on network diagrams. Ensure that you have mastered
the learning material so far before continuing.

2.8 NETWORK DIAGRAMS


Now you know how to get started on planning your project. You should also
know what other tools are available that you can use when planning. The WBS
is the breakdown of tasks into smaller work packages and the logical step is to
find the dependencies between the tasks. So, one can use a network diagram to
illustrate these dependencies. In the network diagram you can also indicate the
milestones of the project – which are the achievements along the way to the suc-
cessful completion of the project. We will discuss these aspects in the sections
that follow below.

The WBS defines the tasks logically and then the network organises them sequen-
tially. Every work task in the WBS must also appear in the network. The network
analyses the sequence of task execution and portrays it in a diagram to ensure
that the team agrees on the sequence. The team must feel that the sequence
provides them with all prerequisites to their tasks. The objective of the network
is to portray visually the relationships of work activities to each other. A network
demonstrates these relationships and communicates them more clearly to project
team members and to managers than any other technique in project management.

PUB2617/131


According to Burke (2007:129), network diagrams can be defined as a graphical


presentation of the projects activities showing the planned sequence of work. In
order to compile a network diagram and perform the critical path method calcula-
tion, the following information is required:
•• list of activities
•• activity duration
•• calendar or work pattern
•• start date
•• logic relationships between the activities
The network diagram, also referred to as a precedence diagram method (PDM),
is a development of the activity-on-node (AON) technique.

There are many forms of network diagrams, but the program evaluation and
review technique (PERT) is probably the most common. Network diagram is a
generic term for PERT, precedence diagramming method, arrow diagramming
method, activity-on-arrow, activity-on-node, bubble diagrams and many others.
Network diagrams are the recommended approaches to planning the schedule
for any project. They identify the precedence conditions and the sequential con-
straints for each task.

There are two options for producing a network:


•• drawing the network free form (a right-brained, visual approach)
•• determining the immediate predecessor(s) for each activity (left-brained,
analytical approach) from which to generate the network

Burke (2007:130) defines an activity as any task, job, or operation that must be
performed to complete the work package or project. A WBS work package can be
subdivided into one or more activities called tasks, work and job. In a network diagram
an activity is always presented in a box with an identity number and description.

The characteristics of an activity include the following:


•• Number: An activity must have a unique activity code or number. The code
may be in alpha, numeric or alphanumeric format.
•• Description: An activity must have a description and must be as informative
and as clear as possible.
•• Logic: This characteristic ensures there are logical relationships between
activities, either in series (shows activities happening consecutively) or parallel
(shows activities happening at the same time).
•• Duration: All activities have a time duration for completing the task, even if
it is zero.
•• Calendar: All activities have a calendar or work pattern to indicate when the
work can be scheduled even if it is seven days a week.
•• Target date: An activity can have a target start and target finish dates assigned to it.
•• Procurement: An activity may require materials and services to be procured.
If the materials are linked to an activity, their delivery date can be established
to produce a procurement schedule.
•• Resources: By linking the resources to an activity, it can be scheduled to
produce a resource histogram.
•• Costs: By linking the costs to an activity, it can be scheduled to produce a
cash flow statement.

Three approaches which are linked to network diagrams will be discussed in the next
subsection. These are the visual, analytical and critical path method approaches.

32
LEARNING UNIT 2:  Project planning

2.8.1 Visual approach


In order to create a visual network, go back to the WBS and separately label
each of the tasks. You may choose to produce labels on post-it notepads or any
other material. The specific tool is not important. What is important is that your
labelling method allows team members to arrange and rearrange the network
flow in as many ways as possible. The basic sequential flow of the network usu-
ally follows the sequence of major work assignments (level 1 tasks) from the
WBS – but not always, since the project team is analysing how the tasks can
best fit together in a whole project, not just the work assignment areas themselves.
Once the labels of tasks have been arranged, you can draw arrows between
tasks as in the figure below – a useful way to show a network of independent
tasks when team members are visually oriented.

End
new software

J Train staff
I Implement

package

procedures
purchased

systems
package

manual
in-house

H Test

flow
F Test

G Test
procedures
purchased

systems
manual
package

in-house

E Modify
C Modify

D Modify

flow
business
B Design

system
require-
A Assess

ments
Start

PUB2617/133


2.8.2 Analytical approach


In this approach, define the most immediate predecessor(s) for each task on the
work breakdown structure, and then prepare a dependency analysis worksheet
that can be translated to a network.

Task ID Task Person Deliverable(s) Immediate


responsi- predeces-
ble sor
ASSESS
REQUIREMENTS
A Assess Joan R Requirements -
requirements document
DESIGN
B Design business Bob S Project A
system definition
DEVELOP
C Modify purchased Guy R Reprogrammed B
package package
D Modify in-house Mary S Procedures B
procedures manual
E Modify manual Bob S Flowcharts B
systems flow
TEST
F Test purchased Guy R Package online C
package
G Test in-house Mary S User standards D
procedures in place
H Test manual sys- Bob S Operational E
tems flow procedures in
place
IMPLEMENT
I Implement new Joan R F, G, H
software package
J Train staff Mary S F, G, H

For each task, ask yourself, “What task produces the deliverable I need to begin
this task?” Your answer will be the immediate predecessor(s). For example, in
the above worksheet, you have to complete task A before starting with task B.
Therefore, task A is the immediate predecessor of task B.

Another name for this technique is dependency analysis. The key purpose is
to review the relationships among tasks within the project. Some tasks must be
done in a sequential order, for example the electricity must be compatible before
the equipment can be installed and tested. Other tasks may occur simultaneously,
for example preparing an implementation checklist while development continues.

In order to analyse dependencies and produce a network ultimately, isolate the


lowest level of tasks on the WBS. Assign an identification number (ID) or letter to
each task. Remember to keep the numbering as simple as possible so that it is

34
LEARNING UNIT 2:  Project planning

not a burden later in the project. Then determine the immediate predecessor(s)
using a dependency analysis worksheet such as the one on the previous page.

Activity
What is the purpose of and need for network diagrams in project management?.

Some guidelines for developing a network diagram:


•• Don’t worry about time estimates or drawing the network diagram to scale.
Concentrate on relationships. The diagram aesthetics can be improved later.
•• Make sure there is only one “Start” box and one “End” box.
•• Do not allow any task to dangle. Every task must connect to another task or
to the start or end of the project. In other words, every task must be integrated
into the framework of the network diagram. If several tasks are all ending tasks,
tie them together to one “End” box.
•• Indicate key “go”/”no-go” points in this network diagram.
•• Remember that this is a communication tool – it must be clear to all who will
use it.

Network diagrams are tools to describe the sequence of project activities and
the relationships between those activities. They also:
•• arrange these activities so that they flow from left to right
•• use arrows to form the network
•• locate squares or circles at the points of intersections or nodes of these arrows
•• store information at these nodes
However, they do use these arrows and nodes in very different ways as we can
see below.

Activity-on-arrow (AOA) networks – these use an arrow to represent an activity


and circles for the nodes which are the start and finish of that activity.

Activity

Paint the ceiling

Start node Finish node

PUB2617/135


Activity-on-node (AON) networks – these represent an activity by a box at the


node and use arrows to link activities together

Activities

Wash down ceiling Paint ceiling

Nodes

When looking closely at the AOA network, it is clear that:


•• The finish node of one activity is also the start node of the following activity.
•• Some of the activities take place at the same time.
•• Several activities can start from one event, or merge into one event.
•• Project and activity duration can be indicated on the nodes.
•• The project critical path can be indicated in the diagram.
•• Activity interdependence can be indicated in the diagram.
The other information can be indicated on the nodes and the diagram. The activ-
ity number, earliest event time (EET), latest event time (LET) and float can all be
indicated on any specific node. This is indicated in the example below.

Activity Duration Can only be completed after activity


A 2 -
B 2,75 A
C 3,5 A
D 4 B and C
E 2 C

THE AOA NETWORK WITH ACTIVITY DURATIONS:

4
2,75
B
1 2 5
2
C E
3,5
2
3

36
LEARNING UNIT 2:  Project planning

THE AOA NETWORK NODE:

No. EET.

Float LET.

The AOA networks can be used under conditions of uncertainty to estimate prob-
able project durations. To do so fully, requires a detailed working knowledge of
statistical theory, but approximations can be made by calculating what is called
the “expected activity duration” for each activity and using those to generate
the network. To calculate this, you can use the following equation:

(a + 4m = b)
Expected activity duration = 6

Where a = estimated shortest activity duration
b = estimated longest activity duration
m = most likely activity duration

The AON (activity-on-node) network looks very similar to the AOA network. The
only difference is that all the information that would appear on the arrows in the
AOA network is also included in the relevant nodes in the AON network. The
AON node typically looks like this:

Earliest start time Activity duration Earliest finish time

Activity descriptionj

Latest start time Float Latest finish time

The two other pieces of information that are added in the AON network node
are earliest and latest finish time. This information simplifies the drawing of a
precedence network diagram.

PUB2617/137


We can illustrate and classify the relationships or precedencies found in network


diagrams as follows:

Finish-to-start

Start-to-start

Finish-to-finish
Start-to-finish

The basic rule-of-thumb is that the network should be planned in no more detail
than can be managed. For example, you may develop a WBS down to level six, but
the schedule may show only work packages (level five). This is not a suggestion
to play games with others in the organisation. Rather, it is an acknowledgement
that one cannot manage with precision at too great a level of detail.

Activity
Use the information from the WBS prepared in session 8.2 above and draw a
basic network diagram in your notepad.

Activity
Draw a table in your notepad to differentiate between AOA and AON networks.

2.8.3 Critical path method


Once you have drawn a suitable network, with durations assigned to all activi-
ties, you should determine where the longest path is in the network, and see if it
will meet the target completion date. The longest path through the project deter-
mines minimum project duration, but if any activity on that path takes longer than
planned, the end date will slip accordingly, so that path is called the critical path.
In the simplest form, computations are made for the network assuming that activity
durations are exactly as specified. However, activity durations are a function of
the level of resources applied to the work, and if that level is not actually avail-
able when it is time to do the work, then the scheduled dates for the task cannot
be met. It is for this reason that you must ultimately make network computations
with resource limitations in mind. In other words, resource allocation is necessary
to determine what kind of schedule is actually achievable! Failure to consider
resources almost always leads to a schedule that one cannot meet.
The first step in network computations is to determine where the critical path is
in the schedule and what kind of latitude is available for non-critical work, under

38
LEARNING UNIT 2:  Project planning

ideal conditions. Naturally, the ideal situation is one in which unlimited resources
are available, so the first computations that one makes for the network are done
ignoring resource requirements. This yields the best-case solution.

Activity
What is a critical path in project management and why is it so important?.

Activity
Draw a network diagram in your notepad, using the following information:
•• Activity A is the start activity
•• When activity A is completed, activities B, C and D can start
•• When activity B is completed, activities E and F can start
•• When activity C is completed, activity J can start
•• When activity D is completed, activities K and L can start
•• Activity M is the end activity and can start when activities E,F,J,K and L
are completed
Durations:
•• A = 5 weeks
•• B = 13 weeks
•• C = 12 weeks
•• D = 15 weeks
•• E = 8 weeks
•• F = 2 weeks
•• J = 7 weeks
•• K = 6 weeks
•• L = 2 weeks
•• M = 4 weeks

PUB2617/139


Network diagrams are generally used for fairly complex projects. Bar charts
are used for projects that have lower levels of complexity, a lower degree of so-
phistication and not as much analysis. Rather than representing an activity on
an arrow or on a node, it can be represented as a bar on a bar chart. The next
section will provide some guidelines on how to convert network diagrams and
the WBS to a bar chart.

2.9 BAR CHARTS


Bar charts, often called Gantt charts after Henry L. Gantt, an industrial engineer
who popularised them during World War I, are frequently used for scheduling.
The following is a simple example of a bar chart:

SAMPLE SPECIAL EVENT PROJECT

The project is divided into a number of activities with planned durations. The bars
represent the forecasted span of the activities. Bar charts are simple to construct
and easy to understand and change. They show graphically which activities are
ahead of or behind schedule.

Offsetting these favourable features are some weaknesses, the most serious of
which is that bar charts are essentially useless for managing projects. Knowing
the status of project activities gives no information at all about overall project
status because one activity’s dependence on another and the entire project’s
dependence upon any particular activity are not apparent.

Despite all of the above, a bar chart remains a popular and useful method of
presenting information about the project plan. It has:
•• a horizontal time-scale
•• a vertical list of activities
•• a horizontal line or bar for each activity
•• lines or bars of a length proportional to the time needed to complete the activity
In addition to providing planning information, one can also use the chart to moni-
tor progress. In all projects there are activities which are carried out in parallel
with each other or at the same time, and these can be easily shown on the Gantt
chart as the example above shows (see the first two activities).

40
LEARNING UNIT 2:  Project planning

Another feature that is crucial to the management of all projects is the project’s
critical path (discussed in section 8.3). This represents the sequence of activi-
ties which leads to the shortest project completion time and which, if delayed,
will hold up the completion of the total project. This path comprises a sequence
of activities and tells us which of all the project activities you need to focus on
to ensure completing the project on time. You can take the information from
the network diagram and use a different colour (red by default) to indicate the
critical path on the Gantt chart.

The Gantt chart, with its time-scale base and visual representation of activity
duration and completion, gives us a clear and easily understandable picture of
the project. This chart requires limited training for its creation and use and can be
drawn by hand on standard graph paper or by using something like a year planner.

ADVANTAGES DISADVANTAGES

Simple to draw and read Difficult to update where there are


many changes – charts can quickly
Good for static environments become obsolete and therefore
Useful for providing overview of discredited
project activities Does not equate time with cost
Very widely used Does not help in optimising re-
The basis of the graphical interface source allocation
for most computer software

Activity
In the previous sections you identified your own project, compiled a WBS and
drew a network diagram. Now take the information from the WBS and the network
diagram and draw a basic bar chart in your notepad.

2.10 MILESTONES
A milestone schedule notes a few key events, called milestones, on a calendar
bar chart. Milestones are probably best defined as events that other people could
clearly verify or requiring approval before proceeding further. The major differ-
ence between an activity and an event is that an event has zero duration – it is
a point in time. On the other hand, an event (also called key date or milestone)
represents a happening on a particular day. This could be when the order is
placed, plans are approved and goods are received or even the start and finish
dates of an activity (Burke 2006:160).

The key to the usefulness of milestones is selectivity. If you use only a few key
events – perhaps one every three months or so – you will avoid turning mile-
stones into pebbles (sometimes called inch stones) over which people are always
stumbling! Some useful milestones might be, for instance, a major design review
or a first article test.

When milestones have been defined (e.g., in the customer’s request for a proposal
or in your proposal document), listing them often helps in preparing your project
plan. Having such milestones with attendant schedule and budget measures adds

PUB2617/141


extra emphasis to a few key points of a project. But, in common with bar charts,
milestone schedules do not clarify activity or task interdependencies. Thus, they
must be used with other tools if they are used at all.

Milestones have the following characteristics:


•• An event has no duration, it is a point in time.
•• An event may be the start or finish of an activity, WBS work package, project
phase or the project itself.
•• An event focuses the project on a checkpoint, a major accomplishment, a
deliverable result, a stage payment or an approval to succeed.
•• An event could be the interface between trades, or contractors as one hands
over to another.
•• Data capture will be more accurate if the scope of work is subdivided into
milestones (Burke 2006:160).

Activity
What is a milestone in project management and how would you include it in the
project plan?

2.11 CONCLUSION
This study unit focused on the planning techniques and tools for planning pro-
jects. We discussed the importance of and need for planning and highlighted
some factors influencing project planning. However, all these should be seen as
background information to be considered during planning and when using the
various planning tools and techniques.

Typically, the project plan will cover many of the following aspects:
•• project summary and requirements
•• milestones and a work breakdown structure
•• network diagram of the activities with scheduled dates
•• budget for all activities
•• responsibility and organisation charts
•• standards
•• communication plan
•• possible risk areas
•• project control and evaluation measures
Project plans require activation. Firstly, obtain whatever higher-level approvals are
required, including those of the customer. Secondly, disseminate the plan to all
involved. In very large projects, dissemination may require a chart room in which
the walls are covered with charts displaying the plans for and status of various
activities, including financial progress and resource allocation. Chart rooms are
not required for smaller projects.

42
LEARNING UNIT 2:  Project planning

Project plans may vary from fairly simple one-page statements to records with
overwhelming intricate levels of detail. There is an appropriate level for each
project undertaking. There is no magic formula that establishes the right level of
detail. In general, never spend more time planning than it would take to correct
any problems encountered because planning had not been undertaken. That is,
a basic purpose of planning is to avoid problems.

Never spend more time on a plan than would be required to correct problems
resulting from a lack of a plan.

2.12 SELF-ASSESSMENT
(1) List the three (3) factors upon which plans depend. (3)
(2) A plan in its simplest form contains four (4) pieces of information.
List and discuss the four pieces of information. (8)
(3) Discuss the content of a project plan. (20)
(4) Discuss in detail why plans are essential. (16)
(5) Discuss in detail what should be considered when planning. (16)
(6) A successful project needs a plan that meets four (4) standards.
List and discuss the standards. (8)
(7) List and discuss the ten (10) core planning processes. (20)
(8) Discuss the concept of work breakdown structure (WBS) in detail. (25)
(9) Define what a work breakdown structure (WBS) entails. (3)
(10) Discuss the structure and content of work packages and deliverables
in detail. (25)
(11) Define network diagrams. (3)
(12) List and discuss the characteristics of an activity. (18)
(13) List the advantages and disadvantages of Gantt charts. (8)

2.13 REFERENCES
Baca, CM. 2007. Project management for mere mortals. Boston: Pearson Edu-
cation Inc.
Baguley, P. 1995. Managing successful projects: a guide for every manager.
London: Pitman.
Brown, KB & Hyer, NL. 2010. Managing projects: a team-based approach. New
York: McGraw Hill.
Burke, R. 2010. Fundamentals of project management: tools and techniques.
Burke Publishing.
Burke, R. 2007. Introduction to project management: one small step for the project
manager. Burke Publishing.
Burke, R. 2006. Project management: planning and control techniques. Burke
Publishing.
Duncan, WR. 1996. A guide to the project management body of knowledge. Up-
per Darby, Pa: Project Management Institute.
Healy, PL. 1997. Project management. Melbourne: Butterworth-Heinemann.
Kerzner, H. 1995. Project management: a systems approach to planning, schedul-
ing and controlling. 5th edition. New York: Van Nostrand Reinhold.

PUB2617/143


Larson, EW & Gray, CF. 2011. Project management: the managerial process.
New York: McGraw Hill.
Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw- Hill.
Maylor, H. 1996. Project management: a managerial approach. 3rd edition. New
York: Wiley.
Rosenau, MD. 1992. Successful project management: a step-by-step approach
with practical examples. 2nd edition. New York: Van Nostrand Reinhold.
Van der Waldt, G & Knipe, A. 1998. Project management for strategic change
and upliftment. Johannesburg: International Tompson.

2.14 ADDITIONAL READING


Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw-Hill.
Rosenau, MD. 1992. Successful project management: a step by step approach
with practical examples. 2nd edition. New York: Van Nostrand Reinhold.

2.15 FEEDBACK ON SELF-ASSESSMENT


(1) Refer to section 2.2 to check your answer.
Plans depend on three factors, namely:
•• knowing where you are now (or will be, when whatever is being planned for
will start)
•• knowing where you want to get to
•• defining in which way you will get from where you are to where you want to be

(2) Refer to section 2.2 to check your answer.


A plan, in its simplest form, contains the following information:
•• Objectives: What are the goals and objectives?
•• How to: How to achieve the goals and objectives?
•• Resources: What people, materials and equipment are required/ available?
•• Activities: Sequence of activities with details of time, cost and quality.
(3) Refer to section 2.2 to check your answer.
According to Baca (2007:38), a project plan should contain the following information:
•• Scope information: The scope statement must be captured in the project
management plan.
•• Work breakdown structure (WBS): The WBS is a hierarchical depiction of
the activities of the project and it is a great tool for getting new team members
up to speed on your project.
•• Schedule: After the WBS has been completed, the activities can be used
to create a schedule with it. The schedule should cover major milestones, in
addition to the major deliverables.
•• Risk plan: The risks should be identified in the project plan as well as the
mitigation of the risks. The risk response plan is also part of the project plan.
•• Human resources strategy: All the information regarding human resources will
be included in the project plan. This includes the project organisation structure,
a resource calendar, roles and responsibilities and even a placement plan,
which will specify where the resources will go when the project is complete.

44
LEARNING UNIT 2:  Project planning

•• Cost elements: This information includes the cost baseline that is used during
the execution of the project so that you can compare what you planned to
spend to what you are spending.
•• Communication plan: Here you will describe what information you will send
at what point in time during the life of your project.
•• Procurement plans: This will include a description of resources that will be
procured outside of the organisation. Resources can mean tools and equipment
or human resources and how to get the resources on your project.
•• Quality management: This will include describing how you will guarantee
the quality of the processes which you will execute.
•• Project execution plan: Everything which you will plan to do should be
covered in this plan, including change control and configuration management.
•• Execution monitor and controlling: This must be included to ensure that
delivery is guaranteed on time and on budget. You must also include which
performance reports will be generated and how you will take action when
things go wrong.

(4) Refer to section 2.3 to check your answer.


You are expected to discuss, in detail, the following reasons that make plans essential:
•• To coordinate and communicate: Most projects involve more than one
person.
•• To control and monitor: Plans are also the basis of your project monitoring
and controlling.
•• To satisfy requirements: Plans are sometimes created merely to satisfy
requirements that one person imposes on others – perhaps a customer or
your boss.
•• To avoid problems: Less experienced project managers often find project
management to be a race against disaster.

(5) Refer to section 2.4 to check your answer.


There are number of elements that need to be considered when planning, such as:
•• Uncertainty and risk
Plans relate to future events. This means that your plans are a simulation of how
things will occur in the future. The future holds uncertainties, some of which may
be somewhat predictable and, thus, partially controllable, but many of which are
unpredictable.

•• Choosing between options


In preparing plans, as in carrying out project work, you are frequently confronted
with options. These choices may include programme management options,
product quality standards, extent of subcontracting to be undertaken, and so on.
Your plan may be considered the record of your choices between these options
and will normally depend on how much risk you are willing to take or how much
contingency allowance is included in your plans.

•• Hazards
There are innumerable hazards in preparing project plans. In an attempt to gain
time in the early phases of a project, or because you are addicted to your own
ideas, you may tend to do much of the planning yourself. You should avoid this for
the same reason you do not like to be told to carry out somebody else’s plan – it
is demotivating. In fact, the golden rule is to involve the people who will actually
be doing the work, in order for them to plan their work, as far as possible.

PUB2617/145


•• Current plans
Once you have decided to plan your project and have issued the plans, people
should take them seriously. They can do so only if they know the plans are cur-
rent. Therefore, it is very important to know who has copies of these plans. When
you revise plans, you should provide revisions to all the people who have copies
of previous plans. When you do this conscientiously, everyone involved in your
project will know that you take planning seriously. They will know their copies of
the plans are a reliable indication of the project intention. You can increase others’
assurance by dating all planning documents, and revisions must have a revision
serial number and date.Refer to section 2.5 to check your answer.

A successful project needs a plan that meets the following standards:


•• Content. The plan should contain enough detail to make it meaningful and
usable, but not so much detail that it becomes unnecessarily complicated.
The content should be clear and unambiguous.
•• Understandability. A plan that can be easily understood by all who use it, is
vital to the success of the project.
•• Changeability. An effective plan is one that can be easily changed, updated
and revised.
•• Usability. The plan must be in a form that facilitates communication and the
monitoring of project progress.

(6) Refer to section 2.6 to check your answer.


The following are the ten core planning processes, which may be iterated several
times during any phase of the project:
•• Scope planning – developing a written scope statement as the basis for future
project decisions
•• Scope definition – subdividing the major project deliverables into smaller, more
manageable components
•• Activity definition – identifying the specific activities (tasks) that must be
performed to produce the various project deliverables
•• Activity sequencing – identifying and documenting interactivity dependencies
•• Activity duration estimating – estimating the number of work periods (hours,
days, weeks, months) which will be needed to complete individual activities
•• Schedule development – analysing activity sequences, activity durations and
resource requirements to create the project schedule
•• Resource planning – determining what resources (people, equipment, materials)
and what quantities of each should be used to perform project activities
•• Cost estimating – developing an estimate of the costs of the resources needed
to complete project activities
•• Cost budgeting – allocating the overall cost estimate to individual work items

Project plan development – taking the results of other planning processes and
putting them into a consistent, coherent document

(7) Refer to section 2.7 to check your answer.


You should discuss, in detail, the WBS. The work breakdown structure (WBS) is
a checklist of every task that must be performed to create the end product. This
checklist becomes the foundation for the schedule, resource allocation and budget
plans. In other words, it is a convenient method for dividing a project into small
work packages. A WBS reduces the likelihood of something being overlooked.
To put it another way, a WBS is intended to assure that all the required project
tasks are logically identified and related.

46
LEARNING UNIT 2:  Project planning

(8) Refer to section 2.7 to check your answer.


Brown and Hyer (2010:132) define a work breakdown structure (WBS) as “a
deliverable oriented hierarchical decomposition of the work to be executed by
the project team, to accomplish the project objectives and create the required
deliverables. The WBS organises and defines the total scope of the project ... The
planned work contained within the lowest level WBS components, which are called
work packages, can be scheduled, cost estimated, monitored and controlled.”

(9) Refer to section 2.7 to check your answer.


According to Burke (2010:137), the structure and content of the work packages
and deliverables can be defined as follows:
•• Ownership: Who will be responsible for the work package? A key project
management philosophy is to assign ownership to all aspects of the project.
•• Deliverables: The scope of the work must be broken down into tangible
deliverables such as the individual components of a car.
•• Scope of the work: The scope describes what has to be made or performed
and, by implication, what is not included.
•• Independent: The work packages should be independent of each other so
that they can be managed separately.
•• Specifications: The specifications define what the work packages need to
achieve and outline what the required standard is.
•• Quality requirements: The quality requirements outline the required condition,
the level of inspection and the qualifications of the workforce.
•• Estimate person hours: The estimate of person hours is a measure of the
work content per work package.
•• Duration: The duration is the trade-off between the work content and resources
available.
•• Budgets: A budget is the amount of money assigned to complete the work
package. Some organisations might limit the work package to a specific
maximum amount, for example, R300 000 (amount could be less or more).
•• Procurement: The procurement lists all the bought items per work package.
•• Resources: The resources identify all the machines and people required
to complete the work.
•• Equipment/materials: The equipment list identify all the equipment and plant
hire that are required per work package.
•• Similar size: The work packages should be of a manageable size, typically
between 20 to 80-person hours.
•• Number: The work packages should be uniquely identified with a number.

(10) Refer to section 2.8 to check your answer.


According to Burke (2007:129), network diagrams can be defined as a graphical
presentation of the projects activities showing the planned sequence of work. In
order to compile a network diagram and perform the critical path method calcula-
tion, the following information is required:
•• list of activities
•• activity duration
•• calendar or work pattern
•• start date
•• logic relationships between the activities
The network diagram, also referred to as a precedence diagram method (PDM),
is a development of the activity-on-node (AON) technique.

PUB2617/147


(11) Refer to section 2.8 to check your answer:


The characteristics of an activity include the following:
•• Number: An activity must have a unique activity code or number. The code
may be in alpha, numeric or alphanumeric format.
•• Description: An activity must have a description and must be as informative
and as clear as possible.
•• Logic: This characteristic ensures there are logical relationships between
activities, either in series (shows activities happening consecutively) or parallel
(shows activities happening at the same time).
•• Duration: All activities have a time duration for completing the task, even if
it is zero.
•• Calendar: All activities have a calendar or work pattern to indicate when the
work can be scheduled even if it is seven days a week.
•• Target date: An activity can have a target start and target finish date assigned
to it.
•• Procurement: An activity may require materials and services to be procured.
If the materials are linked to an activity, their delivery date can be established
to produce a procurement schedule.
•• Resources: By linking the resources to an activity, it can be scheduled to
produce a resource histogram.
•• Costs: By linking the costs to an activity, it can be scheduled to produce a
cash flow statement.

(12) Refer to section 2.9 to check your answer.


Advantages of the Gantt chart
•• simple to draw and read
•• good for static environments
•• useful for providing overview of project activities
•• very widely used
•• the basis of the graphical interface for most computer software
Disadvantages of Gantt chart
•• It is difficult to update where there are many changes – charts can quickly
become obsolete and therefore discredited.
•• It does not equate time with cost.
•• It does not help in optimising resource allocation.

48
THEME 2
PROJECT IMPLEMENTATION, CONTROL
AND EVALUATION

Learning unit 3:
Project implementation 50

Learning unit 4:
Control and evaluation 68

PUB2617/149


3 LEARNING UNIT 3
3 PROJECT IMPLEMENTATION

LEARNING OUTCOMES
After studying this study unit, you should be able to:
•• execute a project according to the approved plan
•• monitor project progress with the use of monitoring tools and techniques
•• compare project goals and objectives with actual results
•• control a project
•• use reports for project control and monitoring

3.1 INTRODUCTION
In the earlier study units of this study guide, we have looked at the ways in which
we convert project outcomes or objectives to the broad concepts of the project’s
early life to the precision and detail of the project specification. We have also
seen how that specification is then converted into a project plan – a sequence
of intended actions that gives life and form to our desire to reach out and control
the future of the project.

But things don’t always happen as planned. For example:


•• The material deliveries of our project can be delayed.
•• The critical or key project activities can run into unforeseen snags and difficulties
and fail to achieve their scheduled completion dates.
•• The equipment can break down just when we need it for a critical path task.
•• The allocated budget can be reduced without warning.
•• One of the project team members may resign or be fired.

When any of these calamities occur, the net result is to put at risk our ability to
create the outcomes of our project:
•• at the right time
•• with the desired performance
•• at the right cost
•• with the desired quality
What we need, under these all too common circumstances, is a quick and ef-
ficient system that will:
•• tell us when things are not as expected
•• enable us to correct or limit the effects of that difference
In this study unit we will discuss the execution of projects. But part of that execu-
tion involves controlling the project so that we reach the desired outcome. We will
also elaborate on control, with reference to some of the controlling techniques
and tools that one can use in this step of the typical cycle.

50
LEARNING UNIT 3:  Project implementation

3.2 PROJECT EXECUTION


Implementation is the process in which all planned actions are executed. Plans
of action are put into operation, the people responsible carry out tasks and give
feedback to the project team, resources are allocated and controlled. Because
circumstances change rapidly, implementation should follow the planning phase
as soon as possible. If circumstances have changed to such an extent that the
plans are no longer viable, project managers have to make new plans. The whole
project must then be planned right from the start and new time schedules given
to each activity.

3.2.1 An implementation issue


A problem that may arise during implementation is lack of enthusiasm. The
previous steps have not required any significant sacrifices and all project team
members have still been fully committed to carrying out the project. However, now
that each one has to physically do something, all sorts of excuses are given. The
longer the period between planning and implementation, the greater the chance
of warning enthusiasm.

You can do the following to maintain enthusiasm (Van der Waldt & Knipe 1998:83):
•• Make sure that the goal of the project can be achieved within a fairly short time
and that the demands made on those carrying out the project are not too high.
•• Create interim objectives towards achieving the goal, so that the project team
experiences a sense of success before the project is completed.
•• Involve every person in the project team.
•• The project manager must be enthusiastic and convey this to project members.
•• Be positive, even if problems occur.
•• Try to predict obstacles before they occur so that they can be avoided and
the group can prepare for them.
•• Give recognition for good work and compliment people if they perform well.
•• Turn a setback into a positive learning experience.
•• Allow the commitment, motivation and enthusiasm of the project manager to
be always evident to everyone.

The role of project managers is critical in the implementation phase. They must
co-ordinate all activities, take the lead, motivate project team members, moni-
tor the process continually and take corrective steps if there are any deviations
from the original plan. They must help maintain the enthusiasm and motivation of
project team members and the community. They need to emphasise the benefit
that everyone will gain from the project and the final product.

However, enthusiasm alone is not going to result in a successful project. Com-


mitment to the project is very important. To illustrate the difference between com-
mitment and enthusiasm, let me use the analogy of breakfast in a hotel. When
you order breakfast in a hotel or restaurant, you will probably have eggs and
bacon on your plate. Now, the chicken was involved in your breakfast – and prob-

PUB2617/151


ably quite enthusiastic about it – by laying the egg(s). But, in order for the bacon
to be on your plate, the pig had to be committed! This does not mean that you
have to give your life for your project – even though it may appear so sometimes.
But you have to give everything you have to make a success of it.

Consider the following “laws” of project management during implementation (Van


Der Waldt & Knipe 1998:84):
•• No major project is ever installed on time, within budget, and with the same
staff that started it. Yours will not be the first.
•• Projects progress quickly until they become 90 percent complete, then they
remain 90 percent complete forever.
•• One advantage of fuzzy project objectives is that they let you avoid the
embarrassment of estimating the corresponding costs.
•• When things are going well, something will go wrong. When things can’t get any
worse, they will. When things appear to be going better, you have overlooked
something. Murphy was an optimist.
•• If project content is allowed to change freely, the rate of change will exceed
the rate of progress.
•• No system is ever completely debugged. Attempts to debug a system inevitably
introduce new bugs that are even harder to find.
•• Project teams detest progress reporting because it so vividly manifests the
lack of progress.
•• A carelessly planned project will take three times longer to complete than
expected. A carefully planned project will only take twice as long.

Read through these “laws” and realise that projects and managing projects are
not always as simple as they seem. However, you should also realise that you will
not be the first one to make mistakes – as long as you learn from those mistakes.
This is even supported by the saying that goes: “Even monkeys fall out of trees”

Activity
On a separate page in your notepad, explain what project implementation mean
and why motivation and enthusiasm are so important in this phase of the project.

3.2.2 Implementing the project


It is the project team that delivers the implementation, not the project manager.
But it is the responsibility of the project manager to ensure that the team’s output
meets the performance requirements stated in the project definition and deliv-
ers the goals of the project. How the implementation is managed has a direct
relationship to the quality, time scale and cost of the project.

You should monitor the following important items:


•• regular reviews of the outcomes of tasks
•• training methods and their effectiveness (where applicable)
•• comparison between the work completed to date with the project definition and plan
52
LEARNING UNIT 3:  Project implementation

Ratios are very useful for monitoring. For example, if your team estimates that
half the work has been done (on any stage or task), and you know that 3/5 of the
budget has been spent, then you have a problem that must be addressed im-
mediately. The project sponsor (or budget owner) should always be kept informed
because surprises are more detrimental than budget overruns. If this pattern is
being repeated elsewhere, then the cost overruns could spiral out of control.

The same applies to time scales. Maybe you are ahead on time, but over budget.
Cutting back on labour may balance this out. If the extra expenditure has reduced
the project risks, then maybe no action is necessary. If you are over time and
over budget, you have a serious problem that must be addressed, probably at a
very senior level. Always report bad news at the earliest possible time and seek
authorisation for remedial action, even if this means stopping the project. Better
to stop the project than drive the organisation into budget overruns or even into
receivership (bankruptcy).

But project management is not just about time and money (important though they
are); it is about the performance of the business process, product or service being
developed. A compromised performance may ultimately be more damaging than
a budget overspent. It is about balance and who has the authority to make that
judgement. Sometimes it can be a team member, often it’s the project manager
but, sometimes, it has to be the CEO.

3.3 PROJECT CONTROL


Although the project team completed and delivered project work, this work needs
guidance and control to ensure that it stays on track. This is the primary function
of the project manager during the implementation phase.

The project manager must have sufficient understanding of the issues involved
in the work to guide the team but need not be an expert at any particular type of
work. Often it is detrimental to the project if the project manager has a particular
expertise because there will be a natural tendency to concentrate on that ele-
ment, to the detriment of the project as a whole. It is better to have a peer review
meeting with an expert from outside the project (a senior technical manager or
business process expert) to review elements that require special expertise.

The project manager must use the project organisation that has been created
(reporting and communications structures, work review and performance testing)
to report on and control the project. Swift and decisive action must be taken if the
project does not stay on course or does not work to plan and budget. The project
manager must be a diplomat who can persuade but also a force to be reckoned
with if the situation calls for it. The higher authority of a programme manager,
project sponsor or even the senior management team should be invoked if neces-
sary to ensure timely decisions, necessary resources and removal of obstructions.

According to Brown and Hyer (2010: 293), project monitoring refers to tracking
systems from a simple checklist to sophisticated dashboard-style approaches,
to identify variances from the original plan. The project team must agree on the
appropriate approach for monitoring key performance indicators (KPIs) during
the life of a project. Even if project teams have endeavoured to prepare for all
possible contingencies, members must be prepared to respond to gaps between
KPI targets and actual performance. Project control refers to the set of processes,
decisions, and actions involved in responding to project variances. Project teams

PUB2617/153


also need to develop a project change management process for deciding when
changes are appropriate.

In an ideal world, project performance will be identical to the project plan. However,
in reality things seldom happen as anticipated. There are phenomena which can
cause actual performance to depart from planned performance.

3.3.1 Phenomena influencing execution and causing deviation from planned


project performance
Examples include scope creep, Murphy’s Law, Parkinson’s Law, the student syn-
drome, Pareto’s Law, escalation of commitment and statistical variation among
dependent events. The abovementioned phenomena are discussed below.

3.3.2 Scope creep


Scope creep describes the tendency for projects to grow beyond its initial size.
Several factors can cause it including team members’ enthusiasm, idle team mem-
bers looking for ways to contribute during downtime, and redefinition of customers’
needs. Closely related phenomena include feature creep, which is the tendency in
technical environments for engineers to add features beyond what, may be useful
or marketable and quality creep, which is the tendency for technical specialists to
want to make a product incrementally better often reaching what is beyond what
is necessary in terms of specifications. Project change control systems can be
used to control the above types of project creep (Brown & Hyer 2010:294).

3.3.3 Murphy’s law


According to Murphy’s Law, anything that can go wrong will go wrong. Not all
risks can be anticipated, but if project managers are vigilant, they may be able
to stem risks or dampen their effects by preparing for Murphy’s inevitable delays
and snags.

3.3.4 Parkinson’s law


Parkinson made the following observation: “Work expands as to fill the time
available for its completion.” Overly generous task estimates can become self-
fulfilling prophecies and project team members cannot dawdle over tasks longer
than necessary. This could lead to noncritical tasks becoming critical jeopardising
the project’s target end date.

3.3.5 The student syndrome


The student syndrome is the tendency for project team members to delay the
start date of their work until the last minute. This syndrome could create situa-
tions in which schedule buffers could disappear and jeopardise the critical path.

3.3.6 Pareto’s law


Pareto estimated that 80% of the people had 20% of the wealth and 20% of the
people had 80% of the wealth. This concept is also known as the 80/20 rule.
A common example is that a business often obtains 80% of its revenue from
20% of its customers. The project management application is that 80% of project
problems and delays are likely to be caused by 20% of project activities. An effec-
tive project monitoring system should focus on activities which carry the highest
risk for delays, cost overruns or performance challenges.

54
LEARNING UNIT 3:  Project implementation

3.3.7 Escalation of commitment


Some people tend to pursue failing courses of action, even when signals point to
the fallacy of the strategy. This phenomenon is known as the escalation of com-
mitment. Project managers often tend to increase their commitment when things
go badly instead of rather seeking a new approach. This could result in failure to
correct good projects that need redirection or failure to kill bad projects.

3.3.8 Statistical variation among dependent events


When dependent activities are executed in a project schedule, some activities
will be completed ahead of time and others will be completed behind schedule.
Late activities will always delay subsequent activities and early completions rarely
benefit successor activities due to hesitation of team members to communicate
with their handoff colleagues when they anticipate early completion (Brown &
Hyer 2010:295).

3.3.9 Project monitoring principles


Several attributes exist which can describe an effective monitoring system. The
attributes are as follows:
•• Identifies metrics relevant to the project: The project manager and team
must measure a balanced set of performance indicators. The greatest priority
will be those metrics which are tied to project goals.
•• Is built into the project plan: A monitoring system cannot be implemented
after the project is underway. The project team must establish performance
metrics and baseline data as well as determine who will be responsible for
keeping records, the frequency of reporting and the level of detail or granularity
of reporting.
•• Provides accurate information: To effectively manage a project and make
ongoing adjustments, the project manager and the team must be able to trust
the information which they receive as accurate.
•• Provides timely information: Project data must be available to the project
manager as soon as it becomes available. Finding out in February that a task
was two weeks behind in November does not give the team the information
it needs to take corrective action.
•• Facilitates management by exception: Management by exception is a
general approach for weeding important information from fast quantities of
data and using threshold signals to determine when there is a problem.
•• Is visible to team members: If team members know what is being measured
and have access to the information, they are likely to behave in ways that keep
performance on course.
•• Provides a basis for problem discovery and solution: The monitoring system
must be a problem-solving tool and not a “big brother is watching” mechanism
that strikes fear into the hearts of participants (Brown & Hyer 2010:296).

3.4 WHAT HAPPENS IN PRACTICE?


There is some difference between what the textbooks say and what happens in prac-
tice. The main difference is that people don’t do what the plan says. They are either
early or late with some tasks, or risks materialise or the requirement(s) may change.

Some major changes in the requirement(s) or other aspects of the project may
mean that the project is not worth doing anymore, or it may have minor implica-

PUB2617/155


tions that change certain important aspects of the project. This means that you
as the project manager will have to make instant decisions about the continuation
of the project. If you are employed in the public sector, you will unfortunately not
have the opportunity to suggest that you discontinue the project. The reason is
that the project probably was a direct instruction from senior or top management
and it is “your job”.

So, what can you do about these things that may go wrong in practice? The best
thing is to monitor the plan, the risks, the change and the quality of the project.
In other words, check the reality or actual work against the plan and be careful
to pick up on all deviations – even the smallest ones.

But how can one monitor and control the project in practice? One way is to moni-
tor the plan and the risks by plotting the actual performance on the plan. For this
you would need a tracking Gantt chart. This is exactly the same as the planned
Gantt chart, but now we add the actual performance on the same document.
This tool enables you to track (and thus monitor and control) exactly what is hap-
pening on your project.

Another way of monitoring and controlling your project is to meet often with the
team to review progress and risks. Ideally your progress report meetings should be
indicated on your plan as well. This will be in the form of a number of recurring tasks.

Apart from the tracking Gantt chart, there is another important technique that you
can use during the implementation of your project. The programme evaluation and
review technique (PERT) is a network diagram and analysis tool developed for
the specific reason to control and monitor certain critical aspects of the project.

3.5 PROGRAMME EVALUATION AND REVIEW TECHNIQUE


The technique used to review and evaluate certain parts of your project is also
called network analysis. Follow the following steps in network analysis:
•• list the tasks or activities
•• list the dependencies
•• draw the network
•• calculate earliest start time (EST) and earliest finish time (EFT)
•• determine project duration
•• calculate latest start time (LST) and latest finish time (LFT)
•• calculate float
•• identify the critical path
The following is a simple example of a network:

56
LEARNING UNIT 3:  Project implementation

We will use the diagram below to illustrate the basic points of PERT. Let’s use
the simple example of making a cup of coffee.

The earliest start time (EST) is the earliest time when work on a task or activity
can start. On the other hand, the latest finish time (LFT) is the latest time by which
the task or activity must be completed if the project is to be completed on time.

The other concept that I have mentioned earlier is float. Total float is when you
deduct the earliest finish time from the latest finish time. Thus:

Float = LFT − EFT

The critical path, which we will discuss in the next section, is where float is nil
(0). In other words when: earliest finish time = latest finish time

The node itself looks as follows:

The following is a solution to this exercise:

Activity
Try the following network analysis exercise by drawing a simple network in your
notepad.
A and B are both start tasks
C Happens after A
D and E happen after B
F and G happen after C
H happen after G
J happen after E
F,H and J are finish tasks.

PUB2617/157


The following is a solution to this exercise:

The critical path method flows out of the network and indicates the longest
route from the start to the finish of the project. A critical task refers to the task
that will have an impact on the total project cost, time or quality if the cost, dura-
tion or quality of the task is changed. The critical path is usually indicated in red.

3.6 DOCUMENTATION FOR PROJECT MANAGEMENT


Documentation involves all the various reports on a project, including the applica-
tion for approval, all monitoring reports and the final report. To place reporting in
its correct context, we need to look briefly at the background of regular reporting
on development projects.

3.6.1 Reasons for project reporting


Regular reporting on the progress of development projects that communities and/
or local authorities address is important for the following reasons:
•• to maintain financial discipline
•• to compare the progress of projects with action plans
•• to determine the achievement of project objectives against the relevant key
performance indicators (KPIs)

KPIs are measuring instruments used to express achievements in terms of ob-


jectives to:
•• emphasise important performances not specified in the action plans
•• emphasise possible problem areas in the project and to suggest corrective
action
•• emphasise future important aspects and opportunities in projects

Project reports that the government receive are used to:


•• monitor the progress of the RDP and other projects against RDP guide- lines
and objectives
•• prepare general progress reports for the President and Cabinet
•• provide early warning of potential opportunities and threats and so to ensure
that they can be used to the benefit of the parties involved

It is therefore beneficial for all those involved in the specific project to ensure
that the reports are ready in time and are accurate and complete. This is also
required for the continued funding of projects.

58
LEARNING UNIT 3:  Project implementation

Activity
Answer the following question on reporting in your notepad:
•• Why is reporting on projects so important?
•• What is project documentation used for?

3.6.2 Guidelines for reporting


All development project reports must follow a certain format when they are drawn.
This format must be strictly followed to ensure that important information on the
project is easily available but also accurate. In addition, it is important so that
various development projects can be compared with one another as far as the
achievement of objectives is concerned. For these reasons all progress reports
on development projects should be standardised, and will typically include the
following:
•• the purpose
•• a motivation (this is optional, but should at least be used for pilot projects)
•• a detailed plan of action
•• a summary of expenditure versus budget
•• a summary of important milestones reached
•• a summary of performance in terms of KPIs
•• a summary of performance in terms of project-specific KPIs
•• a provisional conclusion
The ideal is for this type of report to be submitted monthly to the government, com-
munity and/or funders of the specific project. However, remember that in large, com-
plex projects, this type of monthly reporting would be impractical. In such cases
reporting can take place quarterly.

A sample framework for a typical progress report is as follows:

PUB2617/159


60
LEARNING UNIT 3:  Project implementation

PUB2617/161


62
LEARNING UNIT 3:  Project implementation

PUB2617/163


To speed up the process of reporting, it is advisable to investigate the use of


technology. It is possible to send a report via e-mail from one office to another.
However, note that the relevant report should also be available in hard copy, in
case information goes missing in the technological transfer.

64
LEARNING UNIT 3:  Project implementation

3.7 CONCLUSION
Project implementation is probably one of the most important steps in the project
management cycle, because it does not help to have a brilliant plan on a shelf
but nothing is implemented in practice. So often, we have these wonderful plans,
but we never get around to doing anything about them.

Project implementation also means that we have to ensure that the team mem-
bers are enthusiastic and motivated about the project at hand. Commitment is
another important requirement in project implementation. So often, project teams
and members stop to interact and even disperse without doing anything about
the actual work!

The project manager is responsible for ensuring the commitment of the team
during this, often, difficult phase of the project. It is important to keep the team
together and to acknowledge the work that people do. Reporting would greatly
assist in determining the progress and thus the effort of the team members. There
are various types of reports that can be used and we provided some examples
in this study unit.

Some of the basic tools and techniques that can be used in project implementa-
tion, monitoring and control are the tracking Gantt chart and PERT. While other
techniques such as cost-benefit analysis can also be very useful, the point is
that the project manager and team should keep a close check on what is actually
happening against what was planned.

In study unit 4, we will discuss the last step in the project management cycle,
which is project evaluation.

3.8 SELF-ASSESSMENT
(1) Explain in detail how a project will be executed. (25)
(2) Discuss what you can do to maintain enthusiasm during project
implementation. (8)
(3) Discuss the phenomena which can influence project execution and
cause actual project performance to depart from planned performance (14)
(4) List and discuss the attributes which can describe an effective
monitoring system. (14)
(5) Discuss why reporting is needed on the progress of projects. (10)
(6) Discuss the guidelines for reporting. (10)

3.9 REFERENCES
Baguley, P. 1995. Managing successful projects: a guide for every manager.
London: Pitman.
Brown, KB & Hyer, NL. 2010. Managing projects. a team-based approach. New
York: McGraw Hill.
Duncan, WR. 1996. A guide to the project management body of knowledge. Up-
per Darby, Pa: Project Management Institute.
Healy, PL. 1997. Project management: getting the job done on time and in budget.
Port Melbourne: Butterworth-Heinemann.

PUB2617/165


Kerzner, H. 1995. Project management: a systems approach to planning, schedul-


ing and controlling. 5th edition. New York: Van Nostrand Reinhold.
Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw- Hill.
Maylor, H. 1996. Project management. London: Pitman.
Meredith, JR & Mantel, SJ. 1995. Project management: a managerial approach.
3rd edition. New York: Wiley.
Rosenau, MD. 1992. Successful project management: a step by step approach
with practical examples. 2nd edition. New York: Van Nostrand Reinhold.
Van der Waldt, G & Knipe, A. 1998. Project management for strategic change
and upliftment. Johannesburg: International Tompson.

3.10 ADDITIONAL READING


Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw-Hill.

3.11 FEEDBACK ON SELF-ASSESSMENT


(1) Refer to section 3.2 to check your answer.
You are expected to give a detailed explanation of how a project should be ex-
ecuted. For instance, implementation is the process in which all planned actions
are executed: plans of action are put into operation, the people responsible carry
out tasks and give feedback to the project team, resources are allocated and
controlled. Because circumstances change rapidly, implementation should follow
the planning phase as soon as possible. If circumstances have changed to such
an extent that the plans are no longer viable, project managers have to make
new plans. The whole project must then be planned right from the start and new
time schedules given to each activity.

(2) Refer to section 3.2 to check your answer.


You can do the following to maintain enthusiasm:
•• Make sure that the goal of the project can be achieved within a fairly short time
and that the demands made on those carrying out the project are not too high.
•• Create interim objectives towards achieving the goal, so that the project team
experiences a sense of success before the project is completed.
•• Involve every person in the project team.
•• The project manager must be enthusiastic and convey this to project members.
•• Be positive, even if problems occur.
•• Try to predict obstacles before they occur so that they can be avoided and
the group can prepare for them.
•• Give recognition for good work and compliment people, if they perform well.
•• Turn a setback into a positive learning experience.
•• Allow the commitment, motivation and enthusiasm of the project manager to
be always evident to everyone.

(3) Refer to section 3.3 to check your answer.


Phenomena influencing execution and causing deviation from planned
project performance

66
LEARNING UNIT 3:  Project implementation

Examples include scope creep, Murphy’s law, Parkinson’s law, the student syn-
drome, Pareto’s law, escalation of commitment and statistical variation among
dependent events. The abovementioned phenomena are discussed below.

(4) Refer to section 3.3 to check your answer.


Several attributes exist which can describe an effective monitoring system. These
attributes are as follows:
•• Identifies metrics relevant to the project: The project manager and team
must measure a balanced set of performance indicators. The greatest priority
will be those metrics which are tied to project goals.
•• Is built into the project plan: A monitoring system cannot be implemented
after the project is underway. The project team must establish performance
metrics and baseline data as well as determine who will be responsible for
keeping records, the frequency of reporting and the level of detail or granularity
of reporting.
•• Provides accurate information: To effectively manage a project and make
ongoing adjustments, the project manager and the team must be able to trust
the information that they receive as accurate.
•• Provides timely information: Project data must be available to the project
manager as soon as it becomes available. Finding out in February that a task
was two weeks behind in November does not give the team the information
it needs to take corrective action.
•• Facilitates management by exception: Management by exception is a
general approach for weeding important information from fast quantities of
data and using threshold signals to determine when there is a problem.
•• Is visible to team members: If team members know what is being measured
and have access to the information, they are likely to behave in ways that keep
performance on course.
•• Provides a basis for problem discovery and solution: The monitoring
system must be a problem-solving tool and not a “big brother is watching”
mechanism that strikes fear into the hearts of participants (Brown & Hyer
2010:296).

(5) Refer to section 3.6 to check your answer.


Regular reporting on the progress of development projects that communities and/
or local authorities address is important for the following reasons:
•• to maintain financial discipline
•• to compare the progress of projects with action plans
•• to determine the achievement of project objectives against the relevant key
performance indicators (KPIs)

(6) Refer to section 3.6 to check your answer.


All development project reports must follow a certain format when they are drawn.
This format must be strictly followed to ensure that important information on the
project is easily available, but also accurate. In addition, it is important, as various
development projects can be compared with one another as far as the achieve-
ment of objectives is concerned.

PUB2617/167


4 LEARNING UNIT 4
4 CONTROL AND EVALUATION

LEARNING OUTCOMES
After studying this study unit, you should be able to:
•• explain the importance of closing a project
•• discuss the necessity for a closing event by referring to a practical example
•• conduct a project review
•• compile the final project report

4.1 INTRODUCTION
In the previous study units, you have studied thus far, we have discussed not only
the context of project management in South Africa, but also the various steps in
the typical project management life cycle. Study unit 3 dealt with the implementa-
tion of the plan we have worked on for a long time. It also highlighted some things
that can go wrong and what to manage to achieve success.

In this study unit we will discuss the closing of projects. Project close-out involves
a number of important aspects, such as a:
•• specific closing event
•• project review
•• final project report
We will discuss all these aspects of the final step in the project life cycle briefly.
Evaluating and closing the project mean that we will have to look at the results
from the project. The results must be quantifiable (measurable). This does not
mean the assessment of only the tangible, physical results, such as financial state-
ments, but also the invisible results, such as the degree of change in attitudes and
perceptions. This is particularly important when projects are used to transform
a department or division. The cost-effectiveness of the project, organisational
capacity and operational systems must also be assessed. In public institutions
it is important to determine whether the project has been completed within the
guidelines of existing policy and regulations.

4.2 IMPORTANCE OF EVALUATION


The process of evaluation should be monitored continually, corrective steps
taken where necessary and possible problems anticipated. Evaluation should
be done on an ongoing basis to identify deviations and make recommendations
for improvement.

The programme evaluation and review technique (PERT) is probably the most
well-known technique used to evaluate projects. It involves a network of the

68
LEARNING UNIT 4:  Control and evaluation

whole programme, which is developed during the planning phase. An analysis of


these network schedules is important because it determines resources such as
people, money and material. Because PERT can be illustrated visually in a graph,
it has the advantage that it is always visible, which makes constant evaluation
possible. Because it is a fairly complicated technique that should be explained
in detail, we will not deal with it in this course. However, I encourage you to read
more about it, since it is a useful method that produces results.

4.3 IMPORTANCE OF ETHICS


When money for development is received from the community, a developer, a
private enterprise or the government, everyone involved should be sensitive to
the ethics. You, as a project manager, must realise that the money should be
used to improve the quality of life of everyone in the community and that personal
interests cannot play a role. To ensure that value for money is obtained, activities
should be evaluated strictly to make adjustments in good time if money is being
used ineffectively.

You should always be aware that bribery and corruption are rife in South Africa.
Especially where community projects are being implemented, project team
members and the project manager tend to be approached with some offer. Be
careful of this trap and always remember that you are working with public funds.

4.4 WHAT ARE TYPICAL EVALUATION PROBLEMS?


The following three main obstacles may occur during the evaluation process:
•• standards
•• application of standards
•• appropriate action
4.4.1 Standards
The project team needs to formulate standards or criteria for each phase. Some
of the criteria that should be considered include:
•• meeting the scheduled completion date
•• achieving the objective within the budget
•• quality
•• cooperation
•• accuracy
4.4.2 Application standards
The standards must be tested. In other words, some mechanism is needed for
determining how the standards have been met. These mechanisms differ from
one project to the next and may be left to the discretion of the project team.

4.4.3 Appropriate action


The third obstacle, i.e., deciding on appropriate action, requires insight from
project managers. For instance, if project managers realise that the planned
schedules are not being adhered to, this is a problem in itself, but it may have

PUB2617/169


an underlying cause, such as lack of co-operation between team members. It


is fairly easy to get back on schedule, but it is a complex process to overcome
lack of cooperation and possible conflict between team members. The following
may cause this conflict:
•• lack of communication
•• personal differences
•• motivation
•• incompetence of team members

4.5 HOW OFTEN SHOULD WE EVALUATE?


Some managers regard evaluation as a formal process carried out on given
dates. Others regard it as an informal, ongoing activity. There is no right answer.
However, what is important is that the budget must be controlled and monitored
constantly. Money is a sensitive issue – especially if the whole community has
contributed funds towards the project. The people in the community are entitled
to know exactly how their money is being used and by whom.

The project team may decide on the frequency and basis of evaluation itself.
Regular feedback on the state of affairs is, however, needed to keep to time
schedules and indicate the position on the Gantt chart.

Use the checklist below to ensure that evaluation and control of the project have
been and are being carried out properly. If the answer to any question is “no”,
you should trace and solve the cause of the problem.

QUESTIONS YES/NO

Has the objective been achieved?

Was the objective achieved on time?

Does the project address the need?

Was the budget exceeded?

Were the standards maintained?

Was a progress record kept?

Was the project monitored constantly?

Can all the money be accounted for?

Were corrective steps taken if devia-


tions occurred?

Were the role-players involved in


evaluation?

Was the schedule maintained?

70
LEARNING UNIT 4:  Control and evaluation

Activity
Read the following and think about it for a moment:
Its unwise to pay too much but it is worse to pay too little
When you pay too much, all you lose is a little money - that is all
When you pay too little, you sometimes lose everything because the thing you
bought was incapable of doing the thing it was bought to do
The common law of business prohibts paying a little and getting a lot - it can’t
be done. If you deal with the lowest bidder, it is as well to add something for the
risk you run, and if you do that, you will have enough to pay for something better.

4.6 CLOSING THE PROJECT


According to Larson and Gray (2011: 505), every project comes to an end even-
tually. Therefore, it is important to focus on the deliverables for project closure.

4.6.1 Deliverables for project closure


There are three deliverables for project closure, that is, wrapping up the project,
evaluating performance and managing the project as well as retrospectives. The
three deliverables are discussed below.

4.6.2 Wrapping up the project


Project members must ensure that the customer approves and accepts the pro-
ject. Other wrap up activities include closing accounts, paying bills, reassigning
people and equipment and writing a final project report. You can use checklists
to ensure that some tasks are not overlooked.

4.6.3 Evaluation of performance and management of the project


The evaluation includes a team, individual team members and project manager’s
performance. So, evaluation of the major players will provide important informa-
tion for the future.

4.6.4 Retrospectives
Retrospectives of lessons learned are designed to improve performance on
current and future projects. Major input to the closure report will include lessons
learned. The post project reviews should be held with the team to catch any
missing issues or gaps.

According to Larson and Gray (2011:508), implementing project closure involves


six major activities:
•• getting delivery acceptance from the client
•• shutting down resources and releasing new uses
•• reassigning project team members
•• closing accounts and seeing that bills are paid
•• delivering the project to the client
•• writing a final report

PUB2617/171


It is important to ensure that a project is closed properly for the following two
reasons:
(1) There is a tendency for projects to drift on and become, or develop into,
other projects.
(2) It is important to ensure that the work of the project team is acknowledged
and that the lessons to be learned from the project are formally investigated
and recorded for use on the next project.

4.6.5 Avoid drift


Avoid the tendency for projects to continue forever. It leaves all the team members
feeling dissatisfied and unrewarded for the work (often extra work) that they have
done. Often, nobody checks that all the project’s objectives have been completed
or exceeded. People may note either that the budget for the project is underspent
and then spend the budget on something else or the project may just drift into
over expenditure and then be considered an unsuccessful project.

By carefully monitoring and maintaining the project definition and the project plan
the project will not only be under control but may be officially closed at the end. It
is at the end of a project that the benefits of tight control become evident. The time
and effort spent ensuring that any extra work was specified, budgeted, resourced
and fully authorised will be rewarded by an “on time-on budget” project report.

Similarly, the voices of dissatisfaction can be dispelled (or at least silenced) when
the project report reveals that the project delivered all that it was defined to do,
but not those elements that were authorised to be removed from the project so
that it could deliver its product/service/result by a defined date.

4.6.6 Have a closing event


Always have a closing event to formally round off the project – a party, a dinner,
a night in the pub, or an outing to the theatre or any other venue. Have some
kind of reward for work well done. Ensure some money is put into the budget for
this event at the planning stage of the project.

Even if the project was unsuccessful, overran and brought shame to those who
were responsible for it (rare, on your projects, I’m sure!), it should be formally
closed and the team that worked hard for its success should be rewarded.

Why reward failure? Because you are not rewarding failure – you are rewarding
effort. There is no universal cure for cancer but there are many excellent drugs
that resulted from projects to find its cure. What scientists strive to do is to learn
the lessons for the next project – for the next step forward. That is what we must
do as organisations, as project teams and as people.

4.6.7 Learn the lessons


The last formal piece of work the project team should undertake is the project
review. This event should be a formal review of what did or did not go well with the
project. The project review should include the following aspects of the project:
•• Objectives review
•• Performance criteria
•• Financial criteria
•• Resource utilisation
•• Slips and gains of time
72
LEARNING UNIT 4:  Control and evaluation

•• Quality of work
•• Adherence to the project definition and plan
You should include every aspect that comes to mind and the ones that will arise
from a group discussion.

You also have to allow the team time to reflect on and prepare for the review.
Ensure that there is plenty of time for group discussion. Keep the meeting posi-
tive; don’t dwell too much on the negatives, but ensure that the positive lessons
are brought out from each negative event.

Doing better next time is the theme of the review rather than delving into the minute
detailed reasons for each perceived failure. Start with what we did right and are
pleased with and then move on to what did not go well (or was a total disaster).

You should circulate a project review questionnaire before the meeting to focus
the team’s thoughts on the subject. A sample project review questionnaire is
as follows:

Project review questionnaire

Project: ....................................................................................................

Name: ...................................................................................................

Date: ...................................................................................................

Dept/section(s) represented: .............. .............................................

Position held: Team member/team leader/project leader/product manager/


project manager
The objectives of the project review are to:
•• learn from our experiences
•• repeat successes in future
•• handle unsuccessful aspects differently in future
•• provide data which others may benefit from
•• identify various aspects of the methodology that we may wish to change
in future
Please complete the questionnaire and return it to your project manager.
If a question is not appropriate to your role in the project, simply mark N/A
(not applicable).
There is a section at the end to add any new questions that you think
are appropriate to the project and which should be considered for future
amendments to the questionnaire.

Questionnaire
1. How could the product and project objectives have been better defined?
2. What areas were not well defined?
3. Were the roles of the project manager/project leaders/product mana-
gers/team leaders understood?
4. What would you have liked the following role-players to have spent more
time on:
•• Project Manager
•• Project Leader
•• Product Manager
PUB2617/173


5. What changes would you recommend to the project organisation struc-


ture, and why?
6. What were the major omissions or inaccuracies (if any) in your part of
the product definition (PD)?
7. What would you have liked to see in the PD that would have been bene-
ficial to your responsibilities?
8. How could the process of pulling the PD together have been improved?
9. Was the method of planning adequate? How well was the plan moni-
tored, maintained and communicated?
10. Do you have any suggestions for improving the planning process? In
your answer consider construction of the plan, communication, monitor-
ing and maintenance.
11. What factors caused deviations from the plan? How could the original
plan have been improved?
12. How did the cost of the project (in your area) compare with what was
planned? What were the costs which had not been anticipated?
13. What was the communication like during the course of the project?
Which areas worked well? Which area could have been improved
upon? In your answer consider department, project team and others.
14. How useful were the meetings? What would you have liked them to
have spent more/less time on?
•• Department team meetings
•• Project team meetings
•• Steering team meetings
•• Informal meetings
15. How useful were the minutes you received? How do you feel they could
have been improved? (If you were involved in several meetings, ie pro-
gress and steering meetings, please state the type of meeting.)
16. How well did the decision-making process work? How could it have
been improved?
17. What did you enjoy most on the project?
18. What did you find the most frustrating?
19. What did you perceive to be the most successful aspect of the project?
20. What did you perceive to be the least successful aspect of the project?
21. What are the things that we intended to do but did not achieve?
22. What changes would you recommend to the product development
methodology, and why?
23. What are the specific recommendations that you would like to make for
future (similar) projects?
24. With the benefit of hindsight, what would you have done differently?
25. What could have been done to reduce the time to first shipments?
26. What key areas do you think would benefit from subsequent reviews?
(List up to five and indicate who you think should attend the review.)

The outcomes from the project review should be incorporated in a project report.
Unless your organisation demands a detailed project report, keep it short and
succinct. Ensure that it provides the measures of the relative successes (time,
budget, performance and delivery) but clearly stipulates the lessons learned. It
is best to deal with unpleasant truths with care.

74
LEARNING UNIT 4:  Control and evaluation

For example, if the project team had little or no management support (assuming
they positively asked for it – their own fault if they did not), then it may be best to
report that with the benefit of hindsight it would have been better to have had a
formal management review of the project at its key stages. This is always prefer-
able at any rate, but, in some organisations, you may have to push hard for this.

The last thing to do, is to ensure that a memo is sent to the finance department
to inform them that the project is closed. This should be done so that they do not
continue booking invoices to your completed project’s account. Even if you invite
them to the closing event, you cannot assume they will close the account. You
should always invite the project accountant and invoice clerk to the closing event
because they are always left out (unless it’s a new accounting system project)
and you will need their support for the next project.

4.7 CONCLUSION
In this study unit, I briefly discussed the last step in the typical project life cycle,
which is project evaluation. This is also referred to as project close-out. The ter-
minology does not really matter. What matters is that you have to conclude your
project and ensure that it is properly ended.

The following points were made in this study unit:


•• Evaluation of the project outputs or results is very important and should not
be neglected.
•• Be careful not to fall into the trap of unethical behaviour by accepting bribes
for favours related to the project you are involved in.
•• Evaluation is something that should be done right at the end of the project
after implementation, whereas monitoring and control take place throughout
the project implementation phase.
•• You should be careful not to let the project drift for too long. In other words,
do not postpone the final completion of the project.
•• Ensure that there is a specific project closing event where the team members
will be rewarded for the work they have done – even if that work was not as
successful as planned.
•• Review the project by using a questionnaire such as the example provided
in this study unit.
•• Compile a document that lists all the lessons learned from the project experience.
•• Compile a final project report and ensure that all stakeholders are informed
that the project has been closed.
This study unit then concludes the study guide. With the basic principles, meth-
ods, tools and techniques of project management outlined in this study guide,
you should be able to manage your own projects successfully. Just remember
that it will take time to get skilled at this and you will have to be patient and will-
ing to learn every day.

4.8 SELF-ASSESSMENT
(1) Discuss the importance of evaluation in the project life cycle. (5)
(2) Discuss the importance of ethics in evaluation. (3)
(3) List and discuss the three (3) main obstacles which may occur during
the evaluation process. (15)

PUB2617/175


(4) Discuss the three (3) deliverables for project closure in detail. (6)
(5) Why is it important not to let your project drift? And what does drifting
mean in the project management context? (6)
(6) Describe the importance and necessity of having a closing event for
a project. (5)
(7) Why is it important to determine and discuss the lessons learned
from a project experience? (10)
(8) Discuss “how to close the project” in detail. (25)

4.9 REFERENCES
Baguley, P. 1995. Managing successful projects: a guide for every manager.
London: Pitman.
Duncan, WR. 1996. A guide to the project management body of knowledge.
Upper Darby, Pa: Project Management Institute.
Healy, PL. 1997. Project management. Melbourne: Butterworth-Heinemann.
Kerzner, H. 1995. Project management: a systems approach to planning, schedul-
ing and controlling. 5th edition. New York: Van Nostrand Reinhold.
Larson, EW & Gray, CF. 2011. Project management: the managerial process.
New York: McGraw Hill.
Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw- Hill.
Rosenau, MD. 1992. Successful project management: a step-by-step approach
with practical examples. 2nd edition. New York: Van Nostrand Reinhold.
Van der Waldt, G & Knipe, A. 1998. Project management for strategic change
and upliftment. Johannesburg: International Tompson.

4.10 ADDITIONAL READING


Lewis, JP. 1995. The project manager’s desk reference. New York: McGraw-Hill.

4.11 FEEDBACK ON SELF-ASSESSMENT


(1) Refer to section 4.2 to check your answer.
Evaluation is important because its process is monitored continually, correc-
tive steps can be taken where necessary and possible problems anticipated.
Evaluation should be done on an ongoing basis, to identify deviations and make
recommendations for improvement.

(2) Refer to section 4.3 to check your answer.


When money for development is received from the community, a developer, a
private enterprise or the government, everyone involved should be sensitive to
the ethics. You, as a project manager, must realise that the money should be
used to improve the quality of life of everyone in the community and that personal
interests cannot play a role. To ensure that value for money is obtained, activities
should be evaluated strictly to make adjustments in good time, if money is being
used ineffectively.

76
LEARNING UNIT 4:  Control and evaluation

(3) Refer to section 4.4 to check your answer.


The project team needs to formulate standards or criteria for each phase. Some
of the criteria that should be considered include:
•• meeting the scheduled completion date
•• achieving the objective within the budget
•• quality
•• cooperation
•• accuracy
(4) There are three deliverables for project closure, that is, wrapping up the
project, evaluating performance and managing the project as well as retro-
spectives. Refer to section 4.6.1 for detailed discussion.

(5) Refer to section 4.6 to check your answer.


Avoid the tendency for projects to continue forever. It leaves all the team members
feeling dissatisfied and unrewarded for the work (often extra work) that they have
done. Often, nobody checks that all the project’s objectives have been completed
or exceeded. People may note either that the budget for the project is underspent
and then spend the budget on something else or the project may just drift into
over expenditure and then be considered an unsuccessful project.

(6) Refer to section 4.6 to check your answer


Always have a closing event to formally round off the project – a party, a dinner,
a night in the pub, or an outing to the theatre or any other venue. Have some kind
of reward for work well done. Ensure some money is put into the budget for this
event at the planning stage of the project. Even if the project was unsuccessful,
overran and brought shame to those who were responsible for it (rare, on your
projects, I’m sure!), it should be formally closed and the team that worked hard
for its success should be rewarded.

(7) Refer to section 4.6 to check your answer.


It is important to determine and discuss the lessons learned from a project ex-
perience in order to ensure that “do better next time” is the theme of the review,
rather than delving into the minute detailed reasons for each perceived failure.
Start with what we did right and are pleased with, and then move on to what did
not go well (or was a total disaster).

(8) Refer to section 4.6 to check your answer.


According to Larson and Gray (2011: 505), every project comes to an end even-
tually. Therefore, it is important to focus on the deliverables for project closure.

PUB2617/177

You might also like