Practical Guide To Project Management

Project
Management
By: Dr Dennis Laxton
_____________________________________________________________________
Designed by: Dr D M Laxton ©
Project Management Module
_______________________________________________________________________________________________
1. PROJECT MANAGEMENT OVERVIEW..........................................................4
2. THESE MODULES STRIVE TO PROVIDE YOU WITH: ..................................5
3. THE ELEMENTS AND SCOPE OF PROJECT MANAGEMENT .....................6
4. AIMS AND OBJECTIVES.................................................................................7
5. COMPETENCY.................................................................................................7
6. INTRODUCTION ..............................................................................................8
7. HOW DO WE RELATE PROJECTS TO OUR WORK? ...................................9
8. WHY HAVE PROJECTS? ..............................................................................13
9. THE PROJECT LIFE-CYCLE.........................................................................15
9.1 The project life cycle components explained: 20
9.2. Using the project life cycle 21
MANAGEMENT OVERVIEW..............................................................................30
BUSINESS NEED...............................................................................................30
ALTERNATIVE SOLUTIONS .............................................................................30
PROPOSED SOLUTION ....................................................................................30
JUSTIFICATION.................................................................................................30
BENEFITS ..........................................................................................................31
BUSINESS CASE...............................................................................................31
RISK ...................................................................................................................31
FEASIBILITY ......................................................................................................31
_____________________________________________________________________
Designed by: Dr Dennis Laxton © Page 2 of 236
_______________________________________________________________________________________________
STATEMENT OF AUTHORITY ..........................................................................32
CONSTRAINTS ..................................................................................................32
ASSUMPTIONS..................................................................................................32
9.2.2. The Design Phase 42
Manage Project authorization 42

9.2.2.2. Defining the Scope Boundaries of the Project ............................................................. 57
9.3.2.3. Creating A WBS / OBS Fit ........................................................................................... 62
9.3.2.4. Determining the project milestones.............................................................................. 65
9.3.2.5. Determining project milestones.................................................................................... 72
9.3.2.6. Setting, Monitoring and Managing the Project Parameters ......................................... 75
9.3.3 The implementation phase 113

9.3.3.1 Managing the Project Implementation ........................................................................ 114
9.3.3.2 Managing Project Communication .............................................................................. 115
9.3.3.3 Techniques to Manage the Project Plan ..................................................................... 118
9.3.3.4 Team Resistance to Managing the Project Plan......................................................... 126
9.3.3.5 Updating the Project Plan ........................................................................................... 127
Motivating the Team................................................................................................................ 138
Delegating work to teams........................................................................................................ 142
Skills for managing a Project team 146
9.3.4 The Commission phase 160

9.3.4.1 Completion and Handover .......................................................................................... 162
9.3.4.1 A Practical Guideline for Commissioning and Close-off ............................................. 163
9.3.4.2 Forms to Complete For Commissioning and Close-Off .............................................. 165
COMPARISON OF PLANNED GANNT CHART VS THE ACTUAL GANTT

CHART. 176
REFERENCES .................................................................................................219
INTERNET REFERENCES...............................................................................234
_____________________________________________________________________
_______________________________________________________________________________________________
1. Project Management Overview

These modules are aimed at anyone involved or intending to become involved with the
management of projects. Project management comprises of numerous elements, and
calls for a wide variety of management skills and practices. These modules cover:
managing, planning, organising and controlling projects. Further sections provide a
rudimentary understanding of the financial and legal aspects of project management.
The techniques and practices of project management provided in these modules not
only demonstrate basic project management skills, but also provide the practicing
manager with useful tools for managing and implementing projects through the
application of the practical templates provided in these modules.
Sometimes the concept of project management may be misinterpreted as the mere

practice of ‘scheduling activities’. In fact such a misinterpretation may lead to the
question; ‘What is the difference between scheduling activities and a project?’ These
modules take a look at project definitions, and demonstrate that project management
deals with the management of change - a very challenging and dynamic endeavour.
“The reasonable man adapts himself to the world; the unreasonable man persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man.”
George Bernard Shaw
Within an organisation, the need for change can arise from the need to remain
competitive in the business environment. The management of change has become a
cornerstone of successful business management, and the techniques and practices of
project management can provide the practicing manager with useful tools for managing
and implementing change.
A further misinterpretation is to associate project management only with the field of

engineering. Within an organisation, project based management encompasses a wide
variety of disciplines, such as: Strategic management; Finance; Human resources;
_____________________________________________________________________
_______________________________________________________________________________________________
Marketing and Sales; Production or Operations Management and the practice of

management in general
In terms of the objectives of a particular project, change can occur in a variety of ways.
For example the project may be aimed at bringing about a change in technology, product
offering, marketing strategy, culture, staff skills, management practices, information
technology, etc.
2. These modules strive to provide you with:
• An explanation of project management and the role of the project manager

• An understanding of the main project planning techniques, and the ability to
apply these in your place of work
• The ability to use project management techniques to plan a project and produce
project reports
• An understanding of the factors important to controlling the principal features of
project management, and the ability to implement such measures in your own
working environment
• An appreciation of the financial, legal and negotiation principles surrounding
project management
These modules are focused on introducing and explaining the fundamental elements of
project management.
The module is aimed at anyone involved or intending to become involved with the
management of projects. Project management comprises of numerous elements, and
calls for a wide variety of management skills and practices of project management.
The techniques and practices of project management provided in these modules not
only demonstrate basic project management skills, but also provide the practicing
manager with useful tools for managing and implementing change.
_____________________________________________________________________
_______________________________________________________________________________________________
3. The Elements and Scope of Project Management

Prior to engaging in an analysis of the practices and principles surrounding project
management, let’s define and understand what we mean by the concept of project
management.
Various schools of thought exist for defining project management. The purpose of this
module is not to introduce philosophical debate on the correct definitions, or to try to
redefine the concept of project management, but rather to understand the principle
elements. For this reason various definitions are considered, and the interpretations
provided have been adapted to create a basic understanding of the fundamental
elements of project management.
In 1976 an international institute known as the Project Management Institute (PMl)

started to work on standards for the Project Management Body of Knowledge (PMBOK),
which provides an internationally accepted body of knowledge on the practice of project
management (www.pmi.org)
Consider the following quote from the Project Management Institute, who define project
management as:
The PMBOK(2000) define project management as “The art of directing and coordinating
human and material resources throughout the life of a project, by using modern
management techniques to achieve predetermined objectives of scope, cost, time,
quality and participant satisfaction.”
• Using this definition, the key features and / or elements of project management are:
o Directing and coordinating – a responsibility of the project manager and / or
project team
o Resources - expressed in terms of both human and material
o Scope - this refers to the primary objective of the project
o Cost - usually a limited resource with respect to the particular project
o Time - this can be expressed in terms of a start date, completion date and the
anticipated duration of the project. Similarly, this resource may be limited.
_____________________________________________________________________
_______________________________________________________________________________________________
Note that some projects are known not to have had a specific start date (i.e.
they may have arisen from a sequence of events)
o Quality - this is typically determined prior to the start of the project and relates
to the customer’s expectation of the final product or outcome of the project.
o Participant satisfaction – the most obvious reason for participating in a project
is to realise or achieve the anticipated goal/s of the project. The extent to
which the project was successfully completed will directly affect the level of
participant satisfaction.
4. Aims and objectives

• To assist in managing personal projects.
• To assist in managing business projects from inception to completion
• To be able to apply project management templates.
• To effectively apply specific project management tools, techniques and practices in
various situations
• To gain insight into the challenges facing project driven industries
• To understand the role of project management as a professional
5. Competency
Planning, implementing and managing personal and business project processes
and people by effectively and efficiently applying the available project management tools
and techniques, assisted by structured templates.
_____________________________________________________________________
_______________________________________________________________________________________________
6. Introduction
Who will benefit from applying Project Management skills?
In today’s competitive environment, project management is a useful skill for people

wishing to organise their work in a systemic, planned and effective manner. The
PMBOK(2000) views a project as a defined unit of work that has a clear beginning and
ending and specific milestones along the way to assist in providing measurable check-
points along the way. This all occurs within the limited time, resource and budget
constraints. From this definition one can see that the project management approach can
be applied to almost any function in your personal life and in an organisation, such as
planning a holiday, a wedding, etc. With the organisation, project management can be
applied in the fields of human resources in situations such as the planning of a training
course, hr induction programs, etc.
Within the marketing and sales departments, project management can be used to plan
product launches, implement promotional plans, etc. Within the manufacturing,
distribution, project management can me used to create production schedules,
maintenance schedules and is beneficial when installing new capital equipment. From
this one can see that project management can be used across all sectors.
This way of working is becoming increasingly popular in organizations, and

Business School students are being encouraged to apply the principles at work to
improve efficiency and effectiveness.
_____________________________________________________________________
_______________________________________________________________________________________________
7. How do we relate Projects to our work?

A Project will have a unique outcome, result or solution. This could mean, for
example, a strategic plan, a corporate Intranet, a marketing brochure, a set of
financial records or a new parking area.
Products or Services are what the organization is in business to make, sell or

provide. These earn income for the organization and can lead to the initiation
of a Project.
Facilities are required to produce products. Facilities may be factories,

equipment, computer systems or groups of people. A facility is the product
that a Project delivers.
Projects are undertaken by organizations to deliver, construct, maintain or

renew facilities, systems or processes.
Projects are made up of a number of activities; all focused on achieving the desired
end result of the Project. These activities are undertaken by different groups of
people, utilizing various resources. The activities must be related to one another,
and therefore will need to be planned either in sequence or in parallel. Network
planning is one tool used to plan activities of a Project.
_____________________________________________________________________
_______________________________________________________________________________________________
Identify whether the following are projects or not by ticking in the

?? appropriate box.
Question
Yes No
Plan a wedding
Writing monthly reports on the fifth of each month
Writing a unique company newsletter
Manage quality on the shop floor
Implement a company intranet from scratch
Install a security system in a branch office
Carry out a routine performance appraisals
Organise a sailing trip
Conduct research
Maintain the premises in good order
_____________________________________________________________________
_______________________________________________________________________________________________
Identify whether the following are projects or not by ticking in the

?? appropriate box.
Answers
Yes No
Plan a wedding Yes
Writing monthly reports on the fifth of each month No
Writing a unique company newsletter Yes
Manage quality on the shop floor No
Implement a company intranet from scratch Yes
Install a security system in a branch office Yes
Carry out a routine performance appraisals No
Organise a sailing trip Yes
Conduct research Yes
Maintain the premises in good order No
_____________________________________________________________________
_______________________________________________________________________________________________
Based on what you have learned so far, think about the things you
do at work. Identify a few parts of your job that could be done by
using a project approach.
??
Question
_____________________________________________________________________
_______________________________________________________________________________________________
8. Why have Projects?

Your answer should include things like the work to be done is to produce a unique
outcome, and this outcome is expected to deliver benefit or business purpose.
The purpose may be:
A business purpose, for example to increase profits, efficiency, turnover, or

employment
A social purpose, for example relaxation, enjoyment, fund-raising
Humanitarian, for example flood disaster relief
Projects are undertaken because we cannot produce or achieve the same benefits
by doing routine tasks. Projects will help us to:
improve time management
deliver a one-off solution
give better control
improve risk management
improve ability to meet expectations
improve quality, and
participate in productive cross-functional communication
_____________________________________________________________________
_______________________________________________________________________________________________
Review the above information and analyse which of the identified

? Think point
benefits of a project approach will help you to achieve in your own
projects.
Question
Your answer should include things like the work to be done is to produce a unique
outcome, and this outcome is expected to deliver benefit or business purpose.
The purpose may be:
A business purpose, for example to increase profits, efficiency, turnover, or

employment
A social purpose, for example relaxation, enjoyment, fund-raising
Humanitarian, for example flood disaster relief
We undertake Projects because we cannot produce or achieve the same benefits

by doing routine tasks. Projects will help us to:
improve time management
deliver a one-off solution
give better control
improve risk management
improve ability to meet expectations
improve quality, and
participate in productive cross-functional communication
_____________________________________________________________________
_______________________________________________________________________________________________
Review the above information and analyse which of the

?? identified benefits of a Project approach will help you to
achieve in your own Projects.
Question
9. The Project Life-Cycle
This course will be structured by using the project management life cycle curve as
discussed in the (PMBOK, 2000). This enables the project to be structured into definite
phasing with set milestones and deliverables in each of the phases. the project into a
number of stages of its life cycle allows greater control and monitoring of progress.
Some projects may be stretch over a number of years. By using the project management
life cycle curve, the project can be broken into manageable chunks of work, known as
‘phases’ within the project. This allows for achievements to be recorded and measured
more often, motivating team members and customers alike, and making it more likely
that the project requirements and specifications will be met. It also allows for deviations
to be re-aligned before things have gone too far off track. Each phase of the project can
have a definite handover with sign-off before the next phase is allowed to start. The
advantage of this phased approach is that it can be linked to the project budget and
payments only made on acceptance of the work.
_____________________________________________________________________
_______________________________________________________________________________________________
Within each phase there will be specific inputs which depend on the completion of
the previous phases outputs. There will be specific processes to follow in each
phase. These processes will have specific outcomes and deliverables, with
appropriate hold-points. This will assist in facilitating effective cost, time and quality
management in projects where there are a number of unknowns and unpredictable
variables. Probably the biggest advantage of the phased approach to implementing
a project is that, if at any point, the project is halted, limited resources will have
been committed, reducing losses.
By allocating resources in phases, only when each phase is complete, the size of
the part of the project being handled at any one time is smaller, which reduces the
risk.
The parameters of time, quality and cost can all be evaluated at the end of each
phase, and re-negotiated if necessary.
_____________________________________________________________________
_______________________________________________________________________________________________
Figure 1: The project life cycle
Accumulative
High
Effort over the

life of a project
Level of effort
Low
The time frame of the project

Start Finish
Project Design Implementation Commission
identification
and concept
Input Input Input Input
Problem or Approval to go Approval to implement Commissioning
Opportunity, ahead and the project plan, notification of
project brief, design the completion
project charter product
Process Process Process Process
Detailed scope Award contracts and Start up and test
Project design and issue instructions, the product, has
identification and definition procure equipment and the problem been
proposal, through the services, make the solved?
feasibility study, application of a product or solve the Produce as-built
identify work breakdown problem drawings and
stakeholders, structure (WBS), operation manuals
cost-benefit Design the
analysis; product, develop
Assign project detailed
manager; Decide schedules, CPM
on the and budgets
appropriate type
or organisation
_____________________________________________________________________
_______________________________________________________________________________________________
breakdown
structure (OBS) to
use;
create a
responsibility
matrix.
Key Activities Key Activities Key Activities Key Activities
The key activities Key activities Key activities may be Key activities are
may be may be certain compliance to certain usually based on
environmental specific design legislation or standards methods to
impact studies or requirements or imposed on the project. evaluate the
market research. systems and implementation of
standards to the contractual
comply with. terms and
conditions.
Hold Points Hold Points Hold Points Hold Points
1. Approval of the 1. Approval of 1. These could be 1. These are
factors affecting the detailed quality sign-off’s or usually the
the concept, such scope check points as the customers sign-off
as: environmental documents, project progresses. and the final
impact analysis, Approval of They will be used to delivery documents
marketing design verify if work is to or manuals, etc.
research, standards and proceed or not.
Shareholder specifications as
approval, etc. well as the final
plans and
designs. This
may be the
approval of a
third party such
as the Council,
etc.
Objectives Objectives Objectives Objectives
_____________________________________________________________________
_______________________________________________________________________________________________
1. To ensure the 1. To ensure 1. To ensure clear 1. To ensure there

projects the work is objectives have is a formal
support the structured been set for close-out
strategies correctly in monitoring the meeting and
2. To ensure the similar schedules success. hand-over.
Organisation packages of 2. To ensure effective 2. To ensure the
has the work. feedback and contractual
appropriate 2. To ensure measurement conditions are
resources to the design techniques are in audited and the
be able to work is place. user signs the
complete the linked to the 3. To ensure any project off.
projects concept and deviations from the .
3. To ensure the done in schedule are
concept is accordance recorded and
clearly defined with set deviation requests
and adds design are completed.
value to the parameters
organisation and
specification
s.
3. To ensure
accurate
time
schedules
are drawn up
and the
correct
resources
are assigned
to the work.
Output Output Output Output
Feasibility study Baseline plan Certificate of Close out report
report completion
Approval Approval Approval Approval
_____________________________________________________________________
_______________________________________________________________________________________________
Go/No go To implement Ready to commission Project accepted by

decision, to project client
proceed with
design phase
9.1 The project life cycle components explained:

Figure 2: Project Life Cycle explained
PLANNING ACCOMPLISH
Phase 1 Phase 2 Phase 3 Phase 4

Project Design Implementation Commission
identification and (Develop) (Execute) (Finish)
concept
(Conceive)
1 Gather data Appoint key Set up: Finalize
2 Identify need team Organisation products
3 Establish members Communications Review and
4 Goals and Conduct Motivate team accept
objectives studies Detail technical Transfer
5 Basic Develop requirements product
economics, scope Establish : responsibilit
feasibility baseline: Work packages y
6 Stakeholders end products Detailed schedule Evaluate
7 Risk level quality Information project
8 Strategy standards control systems Document
Potential team resources Procure goods results
Guestimate activities and services Release/red
resources establish: Execute work irect
Identify master plan packages resources
alternatives budget, cash Direct/monitor/for Reassign
_____________________________________________________________________
_______________________________________________________________________________________________
Present proposal flow ecast/control: project team

Obtain approval WBS Scope
for next phase Policies and Quality
procedures Time
Assess risks Cost
Confirm Resolve problems
justification
Present
project brief
Obtain
approval to
proceed
9.2. Using the project life cycle
9.2.1. Project identification and concept phase
During this phase the project identification, proposal, feasibility study, identification of
stakeholders as well as a cost-benefit analysis is done
9.2.1.1. Identify the purpose of the project
Project management is the process whereby beneficial change is defined and

implemented. The approach to project management needs to follow three fundamental
steps. Before a project can start and the concept can be defined, the basic operating
rules and expectations must be understood. The project management team needs to
know so that they can fully commit to the project! The first steps must include:
Why the project is being undertaken?
What is the purpose of this project?
What is the deliverable of this project?
What does the project cover and not cover? What is its scope?
What are the objectives and outcomes?
How are we going to undertake this project? What is the process?
_____________________________________________________________________
_______________________________________________________________________________________________
What are the tools and techniques we can use?
What is the concept of this project?
What are the client’s needs (the client may also be the shareholder)
What predefined output rate is required for the product?
What conditions must the product operate under?
What is the minimum life expectancy of the product?
What are the budget constraints and limits?
From those first steps, the Project team should be able to

set out the:
Vision
Purpose
Parameters
Terms of reference
Priorities and authority levels
9.2.1.2. Identify stakeholders and their needs
A shareholder is anyone or organisation that provides the funding for the project, while a
stakeholder is anyone with a vested interest in the project; they may be part of it or a
customer, supplier, investor in it. One way or another they have interest in the outcome
of the project.
Each individual shareholder and stakeholder has a different need from the project, and a
different measure of success – each will have their own definition of the outcome they
require. The project manager, wanting to deliver a successful project, needs to know
exactly what each shareholder and stakeholder expects, so that the desired outcome for
every stakeholder can be delivered.
Thus, the process to follow is:

Identify the shareholder(s) and understand their objectives and outcomes.
_____________________________________________________________________
_______________________________________________________________________________________________
Identify all the stakeholders through brainstorming with the Sponsor and the team
members.
Meet with stakeholders to establish their criteria for success.
Document and gain approval on the criteria. The list should include reference to
time, quality standards and cost.
Design measurement instruments for each outcome, by stakeholder
When reporting progress to each stakeholder, do so in terms of progress towards

the outcomes they are concerned with.
Figure 3: project planning – shareholder and stakeholder

analysis
Shareholder 1 Shareholder 2
Outcome Outcome
Project name
Stakeholder 1 Stakeholder 2
Outcome Outcome
The shareholder / stakeholder map above will assist in identifying all the relevant
shareholders, stakeholders and their needs. It is essential to identify the needs,
expectations and desired outcomes and of each individual stakeholder in order to meet
them. You cannot generically lump them all together and expect to deliver what they
want. To take the concept a step further, try to identify the stakeholders and
shareholders in a project with which you are familiar. This may be a wedding, an
_____________________________________________________________________
_______________________________________________________________________________________________
extension of your home, a systems installation in your workplace, etc. Now complete the
table below.
_____________________________________________________________________
_______________________________________________________________________________________________
? Think point
For a project applicable to your personal or work life,
Identify the shareholders and stakeholders
Question Identify the output or outcome desired by each of them.
Shareholder Desired Outcome or Output
Stakeholder Desired Outcome or Output
_____________________________________________________________________
_______________________________________________________________________________________________
? Think point
Refer to the Glossary at the back of this Programme, and find
definitions for the following:
Question
Term Definition
Sponsor
Project Manager / Leader
Team members
Customer
Line Managers of
team members
Stakeholder
_____________________________________________________________________
_______________________________________________________________________________________________
? Think
point In the space below, draw a diagram to illustrate the
?? relationships between these people or groups of people, and
indicate what it is that they require from one another.
Question
_____________________________________________________________________
_______________________________________________________________________________________________
9.2.1.3. Compiling a Project Charter
The project charter formally recognises the existence of and initiates a project. It should
be issued by a manager who is external to the project and at a level appropriate to the
needs of the project. The project charter provides the necessary authority to apply
organisational resources to initiate project activities.
Business units and departmental managers, to initiate projects, should use the following
project charter guideline template provide below.
The purpose of this project charter template is to give guidelines on how the project
charter should be completed and what it should typically include. This document is here
mainly to provide the necessary project initiation information to enable management to
accept, reject or defer future work on the project.
• The project charter is intended as:
o a single, documented, point of reference that provides a justification for the

project.
o an executive - level document which will not contain task details.
• It is used:
• to confirm the commitment to the project of the organisation.

• as an aid to communication both within and outside the project.
• as a basis for project definition.
PROJECT CHARTER TEMPLATE

Requestor: (Name of the person requesting the product or service.)
_____________________________________________________________________
_______________________________________________________________________________________________
Requesting Organization: (Name of department / organisation requesting the product

or service.)
Business Venture Manager: (If known) (Representative(s) of the business responsible

for the quality of the project.)
Owner:
Client:
Project Manager:
Revision Number:
Approved by:
Date of approval:
Distribution
Name Location
Signatories
The report described herein is agreed to by the project sponsor. By signing this
document, the project sponsor gives the project manager a mandate to proceed with the
project as described in this report.
Project Sponsor
Date:
_____________________________________________________________________
_______________________________________________________________________________________________
Management Overview
The following is an overview of the project.
Product/Service Description:
(A brief summary of the product or service being requested.)
Business Need
The requirement(s), situation(s) or condition(s) that will be addressed by the project are:
Critical Issues:
(Identify any critical issues known at this point in time; such as, any specific control
requirements.)
Relationship to Other Projects:

(Identify if this project is dependent on or related to any other ongoing or potential
project.)
Alternative Solutions
The alternative solutions (including doing nothing) that were investigated in terms of their
relative strengths and weaknesses are:
Proposed Solution
The proposed solution is:
Justification
The proposed solution best meets the business need in the following ways:
(State who else supports this)
_____________________________________________________________________
_______________________________________________________________________________________________
Benefits
The following benefits of the project were identified:
The benefits will be incorporated into the business and measured in the following ways:
For comparison, the benefits of the rejected options were as follows:
Business Case
The implementation of the proposed solution will involve the following costs:
(Include the Return on Investment – ROI where appropriate)
Risk
The following major risks associated with the proposed solution were identified and
analysed:
No Risk Probability Impact

(Low, medium or high) (Low, medium or high)
Feasibility
The feasibility of the project is based on the following:

(The following questions need to be asked in order to establish the feasibility of the
project:
1. Can we do the project?
2. Should we do the project?
3. Will the project work?
_____________________________________________________________________
_______________________________________________________________________________________________
4. What will happen if we don't do the project?

Also to be considered is the strategic importance of the project and the acceptance of
the project by the organisation.)
Statement of Authority
The authorities of the key people (Project Sponsor, Project Manager and Technical
Architect as a minimum) are as follows:
Project sponsor
Project manager
Technical architect
Constraints
The constraints that surround the project are:
Assumptions
The assumptions about the environment in which the project will operate are:
The project charter essentially formalises the project and should be documented and
signed off, if not by the client, by the project manager.
Expert judgement will often be required to assess the inputs in the Initialisation process.
This input can be achieved through holding meetings with other units within the
organisation, consultants, professional and technical associations, industry groups etc.
The identified project manager must now be formally appointed and the specific roles
and responsibilities defined and agreed upon by the relevant parties, such as, the
stakeholders, shareholders and management where appropriate. The project manager
must be appointed who will be solely responsible for all aspects pertaining to the project.
_____________________________________________________________________
_______________________________________________________________________________________________
The project manager should be appointed as early in the project as possible and
preferably before much planning has been done.
It is essential to understand that a functional manager is responsible for the functions of

a specific department, such as: marketing, production accounts, etc. The functional
manager makes decisions concerning the activities of the specific department as well as
managing the resources of that department.
• The functional manager has:
• Accountability - This cannot be delegated and the functional manager must

answer for all the decisions made as well as the
consequences of the decisions.
• Authority - This is the right to give orders to the functional managers

department within the scope of the departments operating parameters and
the legal and industrial relations framework.
• Responsibility - The duty to follow instructions within the scope of the
organisation structure.
• The project manager:
Has the accountability, authority and responsibility to ensure that the project
objectives are met and that resources are optimised to achieve synergy in a well
run environment.
o The roles and responsibilities of the project manager:

To understand the organisations vision.
To understand the projects vision.
To understand the organisations strategies.
To understand the organisations functional strategies created by other

departments
_____________________________________________________________________
_______________________________________________________________________________________________
To create a project plan including

Being involved in the project charter
The scope of work
The structuring of the work
The definition of tasks
The logical relationships of the tasks hart
The Sequencing of tasks through a network and Gantt

chart
The Resource allocation
The Division of labour.
The Levelled resource plan
A cost analysis
A crashed (Shortened) project
Tracking the project
Performing earned value
Creating teams
To handle conflict
_____________________________________________________________________
_______________________________________________________________________________________________
• A checklist of what it takes to be a good project manager
To effectively control the project plan in terms of :

The scope of work - The work content or component of a project.
The Pert chart - The project management calculations.
The Gantt chart - The graphical display of the project on a bar chart.
The Resource allocation - Allocation of Money, Machinery, Manpower and Material.
The Division of labour - Grouping labour to generate an effective project structure.
The Levelled resource plan - This is done to resolve any resource conflicts.
The cost analysis – This includes setting standards and cash flow analysis.
The crashed (Shortened) project - Done to shorten the end date of the project
Tracking the project - To monitor the progress of the project.
Performing earned value - To monitor cost and schedule variances.
Creating teams - Teams can be used on a permanent or temporary basis.
Handling conflict - This is conflict on activities and manpower.
Once the project manager has been appointed, the project manager needs to be place
into the organisation structure. The organisation breakdown structure (OBS) must be
created to incorporate the project manager.
9.2.1.4. Creating the Organisation Breakdown Structure (OBS)

The more common types of organisational structures (OBS) are now discussed.
• Option 1: Centralised organisational structure
This type of organisation design is mostly used by large organisations with many diverse
types of projects that are in many different locations. The planning, decision making and
control is done at the head office and followed by the divisions. Any deviations need to
be approved by the head office.
_____________________________________________________________________
_______________________________________________________________________________________________
This can be very restrictive to growth, especially if the projects are very diverse in nature
and decision making needs to be instantaneous. The staff involved in the various
projects may become demotivated by the lack of autonomy and power to make
decisions.
• Option 2: Decentralised
This type of organisation design is often used by large organisations with many diverse
types of projects that are in many different locations. The planning, decision making and
control is only assisted by the head office, but the divisions have full autonomy for
implementing their own strategies and tactics, as long as they are aligned with those of
the head office.
Only major deviations need to be approved by the head office. This is less restrictive on
growth, especially if the projects are very diverse in nature and decision making needs to
be instantaneous. The staff involved in the various projects become motivated by their
autonomy and power to make decisions.
• Option 3: The functional organisational structure
This is based on the classical organisation theory developed by Henri Fayol (1841-1925)
Fayol was the first to systematize the organisation.
Fayol was interested in the total organisation and designed departments.
Fayol’s 14 principles of management:

1) Division of labour.
2) Authority.
3) Discipline.
4) Unity of command.
5) Unity of direction.
6) Common goal by all.
7) Remuneration.
8) Centralisation.
_____________________________________________________________________
_______________________________________________________________________________________________
9) Order.
11) Equity.
12) Stability of staff.
13) Initiative.
14) Team spirit.
The traditional grouping is by common function into various departments, such as,
accounts, production, sales, engineering, etc. The traditional project organisation
structure is based on the sub-division of the project lines or disciplines into separate
departments, together with a vertical hierarchy.
Figure 4: The functional organisational structure
CEO
Functional Functional
Yellow Boxes Manager Functional Manager
Represent Staff Manager
Involved in project
activities Staff Staff Staff
Staff Staff Staff
Staff Staff Staff
• Advantages
A high degree of Specialisation in each function that can be used to assist the project
manager. Lines of communication are well established and well defined through the
organogram. Functional department’s work is easier to estimate as the work is of the
same nature and usually follows a certain industry standard. A fast reaction time to solve
problems within the department is possible due to the similarity of the functions.
_____________________________________________________________________
_______________________________________________________________________________________________
• Disadvantages
The client is not always the main focus of concern for that specific department. It is
difficult to determine and allocate a single point of responsibility. The departmental work
may take preference over the project work.
The department often does not see the whole picture and often ignores the urgency of
the project.
There are no formal lines of communication between the different departments. There
may be a lack of motivation if the project is not seen as being beneficial to the specific
department.
• Option 4: The matrix organisation structure
This is designed on the same topology as the mathematical matrix, using vertical lines to
represent the functional responsibility and authority, while the horizontal lines are used
to show represent the project line of responsibility and authority.
This gives the matrix structure its unique appearance. The intersection of the lines
represents the people contact on the specific project. The project manager has
functional authority over the specific function to be completed by that department.
Within the matrix structure there are a number of variations caused mainly by the
distribution of power in the projects and the organisation.
• The most common are:
o The co-ordination matrix:
This is similar to the traditional Organisation structure, except that the project manager
co-ordinates the various departments to ensure the project is completed as scheduled.
_____________________________________________________________________
_______________________________________________________________________________________________
The problem is that the project manager lacks the necessary authority within the various
departments and often wastes time chasing the same activity.
This can often be overcome with the use of quality circles where cross functional teams
are formed and have full management support at all levels.
The project manager now acts as a facilitator, working to a project schedule that is
designed and controlled by the team.
o The normal matrix:
This is where resources from the required departments are assigned to the project until
their work on the project is completed. They report to the project manager on issues
involving the project and to their own departmental managers on the functional issues
that are not project related.
The major problem is that employees often have conflict when reporting to two
managers, especially if the work is closely related and conflicts within the work must be
resolved. One such conflict could occur when the time allocation is limited and there are
too many urgent deadlines too meet.
o The empowered project manager matrix:
To eliminate the situation above where the employee reports to two bosses, the project
mangers can be more empowered with a wider range of powers over the total project.
The project manager is now more senior to the functional managers, but still
needs to negotiate with them for the use of their resources.
This creates a single point of project responsibility and a large company resource pool
from which to draw.
This allows for faster response to client needs and any problems that may occur. This is
no guarantee that conflict will not arise between the departments and the project
_____________________________________________________________________
_______________________________________________________________________________________________
manager, especially if the project management position is sought after by other

functional managers.
E.g. : The Matrix Organisation structure
GENERAL
MANAGER
Engineering Quality Finance Other

Manager Manager Manager Managers
Project
Manager
Project A Specific resources assigned from various departments
Project
Manager
Project B
traditional department lines of authority
_____________________________________________________________________
_______________________________________________________________________________________________
• Option 5: the true (perfect) Project Organisation Structure

This is based on the classical Organisation design, except the departments are based
on projects and is very useful when an Organisation is involved in multiple projects. The
project manager has full authority over the project and all resources are under the
control of the project manager. This eliminates the need to obtain departmental authority
and the conflict of having to report to two bosses. The lines of communication are a lot
faster and allows for a centralised responsibility centre with better customer care and
faster response to problems.
E.g. : The true (perfect) Project Organisation Structure
General
Manager - Projects
Civil Structural
manager manager
Civil site Structural site

manager manager
_____________________________________________________________________
_______________________________________________________________________________________________
9.2.2. The Design Phase
During this phase the scope is further refined from the project charter. The design is
completed for the product or service, detailed schedules are developed, a Work
Breakdown Structure (WBS) is created with risks linked to it, The task are defined and a
network diagram is completed to show the logical relationships between the tasks. The
critical path method (CPM) used to calculate the longest path in the network which
shows the earliest possible finishing time. Resources are allocated and the budgets are
also completed at this stage. Tenders are also collected in this phase when applicable.
9.2.2.1. Defining the scope of the project
The scope of a project defines the end products, processes or outputs of a project,
as well as the standards and criteria that will apply to them, and the work required
to produce them. Scope management involves the initial justification of the project
and initial project start-up, as well as the definition of deliverables, objectives and
constraints. Project scope forms the foundation of the project plan and the basis
from which other related plans are developed and the focus of their integration.
The key outputs and activities of scope management are:
• Manage Project authorization
o Analyse needs, in consultation with client and stakeholders, to determine

the justification for the existence of the project and for designation of
project manager
o Obtain project authorization from higher Project authorities as the basis for
future project management activity and commitment of resources and
effort
_____________________________________________________________________
_______________________________________________________________________________________________
? Think point Name a Project you need to undertake at work, and write it into the
space below. Assume the role of a key customer for your Project,
Activity and write their name next to the Project name. Then answer the
following questions in order to assist you to define the Scope of
your Project.
Project name: Customer name: ___
Describe what the end result should look like.
1. What specifications or standards should apply to the end result?
2. What is the problem or situation that has lead to your wanting this?
3. What is actually happening vs what you would like to happen? (What is the
gap between expectation and actual?)
_____________________________________________________________________
_______________________________________________________________________________________________
4. What will be the benefit to the organization once you have delivered
this product or formulated the process?
5. Who else will be affected by this Project in some way? (Who are the
stakeholders?) What does each of them want to see?
6. Do you have the ultimate authority to approve this Project and the
resources it requires? Who else needs to be consulted or informed?
Whose support do you need to make it happen?
7. What will happen to the product/process once you have delivered it?
What will you do with it?
_____________________________________________________________________
_______________________________________________________________________________________________
• Define and Plan Project Scope
Scope definition involves sub-dividing the major project deliverables (as identified
in the scope statement) into smaller, more manageable components in order to, Improve
the accuracy of cost, time and resource estimates. Proper scope definition is critical to
project success. When there is poor scope definition, final project costs can be expected
to be higher because of the inevitable changes that disrupt project rhythm, cause
rework, increase project time and lower the productivity and morale of the workforce. It
establishes a method to identify all the items of work that are required to identify all the
items that are required to be carried out to complete the project.
• Actions to take in Project Scope Management Planning:

Define the Project objectives, deliverables, constraints and principal work activities, and
use them as the basis for agreement between the project team and the client
Determine measurable project benefits and outcomes to enable evaluation of

Project performance. Examples might be cost reduction (percentage or Rand
amount), increased output of an item (number of items per unit of time), reduced
wastage (tons), actual revenue or profit (Rands) or market share increased (%),
etc.
Develop, agree and communicate scope management strategies and plans
The scope statement covers all measurable or observable elements that

demonstrate that the project purpose has been met.
The following scope statement template can be used to document all the output from the
project scope planning stage.
_____________________________________________________________________
_______________________________________________________________________________________________
Statement of Work Template

General information
For:
Author:
Owner:
Client:
Project Manager:
Revision Number:
Approved by:
Created Date:
Distribution
Name Location
Planned start:
Planned finish:
Key contact name:
Background
Objectives
Responsibility of parties
Deliverables
Standards of acceptability
_____________________________________________________________________
_______________________________________________________________________________________________
Detailed Scope Planning Template.

1. Project background/current environment
(In this section include the following topics:
• Historic perspective of work effort
• References to pertinent people, places, events and documents
• Identification of product uses
• Description of how product will be used to conduct business activities
Describe the current environment by using the following:
• Existing information technology policies related to the project
• Description of the enterprise
• Current high-level system profile
• Current technology infrastructure of the business
2. BUSINESS OBJECTIVE
(Define the business driver behind the proposed work effort.
For example:
• Business opportunity(ies) for customer
• Business problems that can be resolved)
3. PRODUCT/SERVICE DESCRIPTION
(A brief summary of the product or service being requested.)
4. PROJECT SCOPE
Defines the:
Boundaries – what is included and what is excluded from the project
Business functions the scope encompasses)
_____________________________________________________________________
_______________________________________________________________________________________________
4.1 Included in the Project

(Identify items that will be included in the project. For example, business functions or
processes that will be addressed, B
4.2 Excluded from the Project

(Identify items that will not be addressed during the course of the project.)
4.3 Key Deliverables/Expected Outcomes

(A list of the summary level sub-products whose full and satisfactory delivery marks
completion of the project.)
4.4 Context Analysis

(Context analysis consists of defining the environment within which a process operates.
The context model approach is used because it provides a simple and quick way to
generate a common view of a process. For Phase 1, briefly describe the following:
• description of the process “as is"
• assessment of the process output/condition
• business or information system gaps associated with the current condition
• business or information system impacts associated with current condition of output
• description of the process /information system improvements needed
• context diagram
• The structure of a context diagram is relatively simple. It shows a single process as
a rectangle (representing the boundaries of the system), with arrows indicating
inputs, outputs, controls and enablers (sometimes called mechanisms.) See context
analysis guidelines for an in-depth explanation of context analysis.)
_____________________________________________________________________
_______________________________________________________________________________________________
5. Project parameters
5.1 Constraints
(Constraints are limiting factors which could influence the way the assignment is
undertaken. They may alter recommendations and may even affect the quality of the
deliverable; thus, they must be specified up-front. The following factors are typically
included in a list of constraints:
• time scale (the assignment must be completed by a specified date)
• effort (the job is to be accomplished within a budget of workdays; the specification
may include a proportion of available time, such as three days per week)
• budget (the amount of money allocated for this activity)
• people (the category of staff or specific individuals - e.g., users, systems analysts,
service providers)
• equipment (type of hardware; accessibility limitations may also be specified)
• environment (facilities available during the work effort; may also include such items
as the extent to which change can be recommended)
5.2 Assumptions
(At the beginning of a project, not all relevant facts are apparent; thus, any assumptions
must be clearly itemised. Stating what the project team assumes can provide a helpful
first review point with management, who will clarify what they can, and then either
agree or refute the itemised assumptions.
Examples include:
• the assumed availability of key resources
• project approach to work effort (e.g., package vs. home grown.)
_____________________________________________________________________
_______________________________________________________________________________________________
5.3 Detailed Issues/Risks analysis (refer to project charter)

Risk Assessment Checklist is categorised by types of risks. It contains risks
Checklist in bold and suggested actions for each risk.
Risks Associated with the Project Team
Inexperienced Project Leader
• Avoid assigning such a person to large projects or
those with a lot of risk.
• Have management closely monitor plans and
progress.
Large Project Team
• Hold frequent team meetings.
• Partition work to minimise interdependence.
Inexperienced Project Team
• Assign more experienced staff.
• Hold frequent "walkthroughs" of task products.
Project Team Members Come from Multiple
Departments
• Move project team members to one locale.
• Have them administratively report to the
organisation responsible for the project.
Project Team Members are not full-time
• Gain a full understanding of other commitments and
schedules.
• Track progress carefully.
• Estimate additional time for part-time project team
members.
High Probability of Loss of Project Team Members
• Determine the likelihood and timing, and estimate
the time needed to accommodate the change.
High Probability of Billing Rate Increases
• Work with Resource Development Contract
Administration group to determine likelihood of
_____________________________________________________________________
_______________________________________________________________________________________________
contractor rate increases and your Account team to

determine the need to increase analyst rates.
• Add a management reserve amount to account for
estimated rate increases across the life of the
project.
Risks Arising from Relationships with Other
Organisations
Low Confidence in Project Development Organisation
• Assign a Project Manager skilled at dealing with
other organisations and users.
• Assign competent project team members.
• Hold frequent reviews for user management.
Users Feel Threatened by the Application
• Schedule sessions with users to discuss the impact
and explain the benefits of the application.
• Ensure work plans contain an adequate amount of
time for user training.
Users Time Availability does not Match Required
Commitment
• Work with Business Venture Manager to increase
their time.
• Defer the project until the appropriate commitment
is made.
Multiple Organisations will use the Application
• If the project size warrants it, organise a
stakeholder committee that meets periodically to
discuss needs, priorities, progress, and funding.
Client Project Manager is not full-time
• Arrange frequent meetings with the Client Project
Manager or Business Venture Manager.
• Set milestones and visible products.
• Focus communications on key management issues.
Risks Associated with the Business Environment
_____________________________________________________________________
_______________________________________________________________________________________________
Highly Volatile Business Area

• Divide the project into subprojects or stages to
provide flexibility for change.
• Design the application and databases to
accommodate change.
• Build into the budget a significant allowance for
change.
• Establish and adhere to a procedure for managing
change.
Users are Unsure of their Needs
• Communicate your understanding of the current
business environment, deficiencies, and proposed
changes to the user and ask for verification.
• Conduct "walkthroughs" of the functional
specifications and the Users' Manual with the users.
• Develop and use prototypes to verify user needs.
Users Have Very Limited Experience with Computers
• Develop a prototype and use it as a training tool
before putting the application into production.
• Allow for additional time in plans, more than normal,
for training.
Development of an Application within a Tight Deadline
• Determine whether there are interim alternatives
that could be used to extend the deadline.
• Provide the Application in stages to minimise the
risk of last-minute changes.
• Provide a fallback plan if the deadline cannot be
met.
High Probability of Staff / Management Changes
• Determine the likelihood and timing, and estimate
the time needed to accommodate the change.
Significant Business Procedural Changes due to
Application
_____________________________________________________________________
_______________________________________________________________________________________________
• Ensure Business Venture Manager has adequately

estimated the Business Process Change
Management Plan.
Trades Restrictions, Language Barriers, Political and
Time Differences related to International Projects
• Work with Business Venture Manager to address
concerns.
• Plan meetings carefully (e.g. alternate meeting
times).
• Provide common electronic project discussion
areas.
Risks Associated with the Application
Complex Application
• Divide the application into small units for design and
development.
• Add sufficient time in the project plans to review the
design, code, and testing of the application, both
when divided into small units and as a whole.
• Staff the project team with experienced personnel.
Application is in a New Business Area
• Budget extra time for the project to become familiar
with the business.
• Expect larger than normal Project Definition and
Design Basis stages, with increased user
involvement.
Application Requires Complex Data Structures
• Utilise applicable analysis techniques to model the
data structures.
• Review logical and physical designs with
appropriate experts.
Application Requires Data to be Shared with Others
• Review logical design and security with other
appropriate experts.
_____________________________________________________________________
_______________________________________________________________________________________________
Individual Programs are Complex

• Break down the programs into subroutines and use
top-down design, coding, and testing techniques
with frequent "walkthroughs".
• Assign experienced staff to develop the complex
programs.
• Add extra time to resource estimates to allow for
additional design reviews and changes.
Technical Environment is Complex
• Review the project team's recommendations in a
"walkthrough" with technical experts.
• Assign a full-time, experienced person to the project
to co-ordinate technical decisions.
New Technology will be Used
• Emphasise performance and acceptance criteria.
• Benchmark test the system.
• Add extra time to the project plan for the project
team to train and become familiar with the
technology.
• Build a prototype to gain familiarity with the
technology.
• Develop a backup plan with alternatives if the new
technology fails.
Project Team has Little Experience with the
Technology to be Used
• Add personnel experienced with the technology to
the project team.
• Use consultants as appropriate.
• Add time to the project plan for training the project
team and for gaining familiarity with the technology.
Data to be Used by the Application is of Questionable
Quality
• Assign the task of reviewing the data and Improving
_____________________________________________________________________
_______________________________________________________________________________________________
its quality to the user. If this cannot be done, assign

this responsibility to a team member.
• Establish controls for verification of data as it is
converted or input.
• Allow time in the project plan for this activity.
Risks Associated with Vendor Development
Vendors Will Develop All or Part of the Application
• Ensure that the project development organisation
will have managerial control of the work effort.
• Establish a schedule with pre-set objectives,
milestones, and reviews.
• Consider adding extra time in schedule reserve if
vendor will be developing new release of software
for project. Assess vendor's internal project
management capability and supplement as needed.
• Review products thoroughly and have the vendor
correct any problems before proceeding.
• Allow ample time for negotiating favourable contract
terms. Involve Procurement resources from the
beginning. Include terms in the contract for
penalties or cancellation for inadequate
performance and incentives for exemplary
performance.
General Risks
Long Project (over six months to planned completion)
• Deliver the application in stages.
• Increase the number of team members.
Implementation will Occur at a Busy Time for the Users
• Reschedule the implementation to a more
convenient time.
• Have additional staff assigned to the user group to
accommodate increased work during project
development and training.
_____________________________________________________________________
_______________________________________________________________________________________________
Development of the Planned Application will Require

other Applications, Databases, or Business Functions
to be Changed
• Contact support personnel responsible for the
affected applications or databases as early as
possible to plan and implement the required
changes.
• Contact affected business organisations and obtain
their commitment.
• Ensure that all parties have the same
understanding of commitments and deadlines.
5.4 Critical Success Factors

(Critical success factors are quantifiable criteria that must be met for the project
to be considered successful.)
_____________________________________________________________________
_______________________________________________________________________________________________
9.2.2.2. Defining the Scope Boundaries of the Project
• The project scope can be expressed by clearly defined boundaries such

as:
o Work Breakdown structure – a cascade of products and work activities
o Product Breakdown structure - a cascade of products, sub-products,

assemblies and components
o Process Breakdown structure – a cascade of interrelated processes
o Cost Breakdown structure – a cascade of budgets and costs
o Organizational Breakdown structure – a cascade or resource types, skills

types or activities
• Designing a Work Breakdown Structure (WBS)
In order to complete major tasks, the task should be broken down into clearly defined
areas of work, and into manageable chunks. The Work Breakdown Structure (WBS) is
one of the most important first steps in defining and planning a Project. Not only does it
assist with setting the boundaries for the Project, but it also structures the key elements
to be included, so that nothing is omitted, and assists with work and task allocation.
The purpose of the work breakdown structure (WBS) is to sub-divide the scope of work
into manageable work packages which can be estimated, planned and assigned to a
responsible person or department for completion
_____________________________________________________________________
_______________________________________________________________________________________________
Figure 5: A WBS Standard Template per Project Phase
. Sample Work Breakdown Structure Organised By Phase
Detail Design
Project Product Detail Design Construction Integration and

Management Requiremen Test
ts
Planning Software Software Software Software
Meetings User User User User

Documentatio Documentatio Documentatio Documentatio
n n n n
Administration Training Training Training Training

Program Program Program Program
Materials Materials Materials Materials
• Steps in designing a work breakdown structure
o Decomposition – The sub-dividing of the major project deliverables into

smaller, more manageable components until the deliverables are defined in
sufficient detail to support future project activities (Planning, executing,
controlling, and closing). Decomposition involves identifying the major elements
of the project which will be the project deliverables and project management. The
major elements should always be defined in terms of how the projects will
actually be managed. E.g. the phases of the project life cycle may be used as the
first level of decomposition with the project deliverable repeated at the second
level
_____________________________________________________________________
_______________________________________________________________________________________________
o Within each area of work, identify the deliverables or outputs, along with
responsibilities (which team member is accountable for delivery) for each output,
and the means of achieving the outputs.
o Identify all the resources required for each output – men (human
resources), materials, machines, means (processes), money (budget) and time
(the deadline).
o Identify all people who need to be involved in some way: RACI is

a good way to remember who is Responsible (who does it), who is Accountable,
(who is ultimately accountable), who needs to be Consulted, who needs to be
Informed.
o The WBS is the foundation of the project plan, as well as

providing critical input into defining the scope of the project.
o The WBS can be the one-page document used as the basis for
managing the Project.
• Scope Definition Output
A work breakdown structure – A work breakdown structure is a deliverable

oriented grouping of project elements that organises and defines the total scope of the
project: Work not in the WBS is outside the scope of the project. The WBS is often used
to develop or confirm a common understanding of the Project Scope. Each descending
level represents an increasingly detailed description of the project elements. Each item
in the WBS is generally assigned a unique identifier; these identifiers are often know
collectively as the “Code Of Accounts”. The items at the lowest level of the WBS are
known as the “work packages”.
_____________________________________________________________________
_______________________________________________________________________________________________
Figure 6: A detailed example of a WBS by Phase
An Intranet WBS Organised by Phase
_____________________________________________________________________
_______________________________________________________________________________________________
Figure7: A detailed example of a WBS by Product
An Intranet WBS Organised by Product
• Guidelines for structuring the WBS:
o Start with the Project as a whole unit – e.g. “throw a party”
o Sub-divide it into major categories as illustrated above: people, venue,

refreshment
o Divide each major category into its component parts.
o Identify the outcome for each part.
o For each part, identify the tasks to be done, e.g. for “Guests”, we could have:
compile guest list, send invitations, record responses, etc.
_____________________________________________________________________
_______________________________________________________________________________________________
o For each part, identify the resources required, (men, materials, machines,
money, means and time).
o Allocate responsibilities for the various parts of the Project to your team
members.
o Continue to break the Project down until the entire scope in terms of outputs,
processes, responsibilities, activities and resources has been documented.
o Everyone should be clear about what he or she must do, how he or she must do
it, what he or she should have achieved at the end, and how their achievement
will be measured.
• The advantages of doing a proper work breakdown are:
o It provides better control of work definition.
o It allows work packages to be delegated.
o It allows work to be defined at appropriate levels for estimating and control for the
current stage of the Project.
o It allows risk to be contained within the Work Breakdown Structure.
9.3.2.3. Creating A WBS / OBS Fit
Once the Organisations Breakdown Structure (OBS) has been established and the Work
Breakdown Structure (WBS) designed. The ‘Responsibility matrix’ must be created to
ensure that the responsibilities for the phases of the project are well defined and
documented in a ‘Responsibility Matrix’ as the one shown below.
_____________________________________________________________________
_______________________________________________________________________________________________
There should be sufficient supporting detail. The supporting detail for organisational
planning usually varies by application area and project size. Information frequently
supplied as supporting detail includes, but is not limited to; organisational impact – what
alternatives are precluded by organising in this manner; Job descriptions – written
outlines by job titles of the skills, responsibilities, knowledge, authority, physical
environment, and other characteristics involved in performing a given job. Training needs
– If the staff to be assigned is not expected to have the skills needed by the project,
those skills will need to be developed as part of the project.
_____________________________________________________________________
_______________________________________________________________________________________________
Figure 8: Responsibility Matrix

Activity Project Team Project Business Project
Members Manager Owner Stakeholders
Project change P P P P
identification
(complete change
request form)
Screen request for P P
reasonableness &
determine effort
required to evaluate
impact to project
Conduct informal P A
interview with client to
determine whether
further handling of the
request is warranted
Record change and A P
monitor status on
change control log
If approved for The person the project change is assigned to will be accountable.
investigation by client, This person may be from any of these areas and may seek
prepare cost/schedule participants from any of these areas.
impact assessment -
communicate impact
to client
Project change A A S A
solution
approved/rejected
Modify project A P
baseline and work
papers as required
Do required work A P A A
_____________________________________________________________________
_______________________________________________________________________________________________
Project change The person the project change implementation is assigned to will
resolution be accountable. This person may be form any of these areas or
implemented may be from outside the project team.
P = Perform A = Assist S = Signoff
Figure 9: Sample WBS / OBS (Showing who is responsible for

each work package).
WBS
1.1 1.2
1.1.1 1.1.2 1.2.1 1.2.2
Civil
Mech. OBS
Elec.
9.3.2.4. Determining the project milestones
Projects need to be managed by objectives. To achieve each objective, the milestones

need to be set. A milestone is a normally a significant event, generally relating to the
completion of a certain part of the project. This usually requires some type of sign-off to
_____________________________________________________________________
_______________________________________________________________________________________________
be completed or a certificate issued and is often accompanied by a payment. A Project

should have a series of milestones, indicating a series of tasks to be completed.
Milestones occur at the end of a stage, not at the end of each activity!
• At each milestone there is:
o A formal progress report

o A finished document or
o A finished product/service
Motivation, productivity and communication are all boosted if definite progress can be
seen. By identifying major achievement points within your Project life cycle, you can set
goals that people can understand. Interested parties in the Project have a tangible
expectation and the Project team members have a tangible delivery at a point in time.
The attainment of a milestone is linked to delivering sub-products/services, or attaining

the set objectives. The milestone plan should be clear to everyone involved, focus on
decisions, be logical and measurable and preferably not more than a page long.
• Setting Project objectives
Both the objectives and milestones should conform to the SMART formula. They must
be: specific, measurable, attainable, realistic and time bound. There should be an overall
objective for the project, and an objective for each milestone.
• Establish Project measures
Measuring the output of projects needs to inform us when the objectives of the project
have been met and the milestones achieved. Having measures in place assist in
keeping the project members, internal and external, informed about where we are now,
where we want to be, and how we are progressing towards where we want to be.
_____________________________________________________________________
_______________________________________________________________________________________________
It is generally difficult to undergo any sort of meaningful change without information on

the projects progress. This must be compared to the original charter and scope of the
project.
A good measurement system should provide data that is actionable, meaning that the
system should include both effectiveness and efficiency indicators – i.e. answers the
questions “are we doing the right things?” as well as “are we doing things right?”
according to the defined and agreed upon charter and scope of work. The system should
include measures of positive accomplishments, not only negatives – often we see
included items such as “staff turnover”, “number of complaints received”, and “number of
errors made”.
The system should measure what it intends to measure – e.g. the value of a report could
be measured in terms of its contents versus specified criteria, and the timeliness with
which it was submitted – do not measure the amount of time spent working on it. The
measures should be easily understandable by all.The system should only provide
measures to a particular group or individual that they have full control over – for example
a sales person cannot be fully accountable for sales of an item that is out of stock
because of a production problem.
Measures should be objective and discrete – not dependent on one another; otherwise
the “halo effect” may come into play. For example, a sales person may generate good
sales, so his manager may rate him as being high on customer service, something that
may not necessarily be true; customer service needs its own, individual measure.
Measurements should be put into place for each milestone in a project plan, as well as at
the end, to ensure those progress reports and rewards or corrective action take place
timorously. Measurement information should be available easily through standard
reports or measuring instruments. The system should enhance awareness of progress
and improvement, not only control, even though the Project will be controlled through the
use of the measurement system.
_____________________________________________________________________
_______________________________________________________________________________________________
• The System should identify:

o What will we measure?
o Who will do the measuring?
o How will the measurement take place?
o Where will the measurement information be recorded and reported?
o When and how often will the measurement information be communicated?
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Identify two measures for each milestone in your Project.
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Do a work breakdown for your Project.
Write the name of the Project:
Write the major categories that your Project will consist of:
Identify the specifications for the whole Project as well as each category:
Write down the activities to be carried out within each category
Estimate the length of time each activity will take
Estimate the cost of each item at the first level of the WBS
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Reflect on the process you have just undertaken. What are
your insights about performing a WBS in terms of
workplace efficiency and effectiveness?
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.2.5. Determining project milestones
• Define your communication strategy
During the course of the project you will have to communicate extensively with your
team members, with the sponsor, with customers, stakeholders and suppliers. To
do this effectively you need to identify each individual or group that you must
communicate with, what you need to communicate with them about, when you will
communicate and how you will communicate with them. For example:
Who What When How

Sponsor Project progress By the 1st of each Monthly report
Resource month
utilisation
Team (whole Get feedback Third Monday Team meeting
group) Report progress each month
Administrative Project news Quarterly Company
staff Newsletter
_____________________________________________________________________
_______________________________________________________________________________________________
Activity Write a broad communication strategy for your own

project by completing the following table.
Who What When How
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Based on the answers to your questions in the previous
activity, write a Scope Statement for your Project on a
separate sheet of paper. Use the template above as a
guideline
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.2.6. Setting, Monitoring and Managing the Project

Parameters
Learning objectives:
After working through this section you should be able to:
y Plan, monitor and manage the time dimension
y Plan, monitor and manage the quality dimension
y Plan, monitor and manage the cost dimension
Project management is the most important task when running a project, or groups
of projects. A project manager gets Projects done. The Project manager’s job is to
complete the Project on time, within budget and to quality expectations.
The positive way to limit behaviour is for all members of the Project team to have
clearly defined roles and responsibilities, together with working plans that prescribe
how they will meet their Project objectives. Control is defined as:
Comparing where you are to where you are supposed to be, and then taking action
to correct any discrepancy
If you have no plan, you have no control! Three important areas requiring control
were identified in the figure below, namely time, cost and quality. These determine
the success of the Project. Another area to monitor is the legal aspect of your
Project.
_____________________________________________________________________
_______________________________________________________________________________________________
Figure 10: Project Parameters
PROJECT
PROJECT PARAMETERS
PARAMETERS
PROJECT
PARAMETERS
QUALITY COST TIME
Specifications Budget Schedule
a. Planning, monitoring and managing the Time dimension
Time can be considered a soft constraint on a Project. Being late reduces the
benefit, but few Projects will fail if they are not completed on time. There are
exceptions - for example, Project Giotto, the spacecraft to Haley’s comet: there
was a very small time window in which to make the rendezvous, and if it missed it,
there would not be another opportunity for 75 years! Another was the opening of
the Randburg waterfront. The opening function was set; the shops had advertised
their opening date, and would have lost many sales and much credibility had the
opening not taken place on time. However, on most Projects, timely completion is
a benefit that must be balanced against the cost of achieving it.
The three important aspects of planning and managing time are to develop
schedules, manage the schedules and evaluate the process afterwards in order to
improve it.
_____________________________________________________________________
_______________________________________________________________________________________________
a.1. Develop Project Schedules

Determine the duration, sequence and dependencies of tasks from the
scope definition
Use time management techniques and tools to determine the schedule,

resource allocation and financial requirements.
Gain agreement to the schedule and communicate to stakeholders. Use

it as the basis for planning, implementation, and review of progress.
a.2. Manage Project Schedules

Develop mechanisms to monitor, control, record and report project
progress in relation to the agreed schedule.
Continuously monitor Project progress against the schedule and identify

variances.
Adjust the schedule, with agreement, as necessary to ensure that

changing scope, objectives and constraints related to time and resource
availability are accommodated.
Respond to schedule changes and manage them to achieve project

objectives.
a.3. Analyse Time Management outcomes

Analyse Project outcomes and report on the effectiveness of the
schedule and time management processes.
Incorporate lessons learned into future Projects.
a.4. Developing Project schedules
There are three ways of communicating a Project’s schedule:
Activity listings with dates, like a to-do-list
Bar charts (or Gantt charts)
Network / Pert diagrams
_____________________________________________________________________
_______________________________________________________________________________________________
b. Constructing Network Diagrams
• Activities in Serial
When the activities are in series they are carried out one after the other. When
the network is first developed this would probably be the most common type of
relationship used.
• Activities in Parallel
When activities are in parallel they may be carried out at the same time, hence
that is a more effective use of time. Critical Path Method Steps
Definitions
The Critical Path is the longest path along the network with zero or
closest to zero float.
Early Start: the earliest date which, an activity can start.
Early Finish: the earliest date by which an activity can be completed.
Late Start: The latest date by which an activity needs to start before it will
delay the project's completion date.
Late Finish: The latest date by which an activity needs to be completed so

that it will not delay the project's completion date.
Constraint Dates: These dates may be a number of imposed dates,

influenced by the delivery of materials, or access to sub- contractors.
Target Start: The date an activity is planned to start.
Target Finish: The date an activity is planned to finish.
Activity Float: Also known as slack, is a measure of the flexibility of an

activity, indicating how many working days the activity can be delayed or
extended before it will effect the completion date of the project or any
target finish dates.
Float is calculated by either of the two equations:

FLOAT = Late Start - Early Start (Preferred method).
Float = Late Finish - Early Finish.
_____________________________________________________________________
_______________________________________________________________________________________________
Total Float: Here the float is shared with all the other activities in the arm.
Free Float: This is a measure of the amount of float the activity can use
up without affecting the early start of any other activity.
This only happens when there is one activity in the network arm linked to
a critical activity or milestone.
Negative Float: When calculations show that an activity must start before
the preceding activities are finished, this is indicated as negative float.
It is an unworkable situation which occurs when an activity falls behind

planned progress. This value of the negative float indicated how much the
activities duration or logic must be shortened.
An example of the construction of a network (Pert chart) and the related Gantt Chart.
This is based on a “Landscape Project for a park.”
Draw the network diagram activity box as shown below.
EARLY START EARLY FINISH

Early Finish =
early start +
duration - 1
FLOAT ACTIVITY NUMBER DURATION
Float = late DESCRIPTION
start – early
start
LATE START LATE FINISH
Late start = late
finish –
duration + 1
_____________________________________________________________________
_______________________________________________________________________________________________
Assign duration’s to all activities.
Give the project a start date.
link the tasks using the following options :
Finish-to-Start link
Start-to-Start link
Finish-to-Finish link
Start-to-Finish
Decide on the Lead or Lag required when doing the above linking.
Use hammock Tasks where required.
_____________________________________________________________________
_______________________________________________________________________________________________
Step One – Assign activity / task durations and draw up a

logic table
The activity times can be estimated by Program Evaluation and Review technique
(PERT) set up by the US Navy development team with Lockheed Aircraft Corporation,
and a management consultant Booz Allen and Hamilton, to design PERT as an
integrated planning and control systems to manage their Polaris Submarine project. The
PERT techniques applies a statistical treatment to the possible range of activity time
durations. A three time probabilistic model was developed, using pessimistic, optimistic
and most likely time durations. The three times were imposed on a normal distribution to
calculate the activities average time. The average time is calculated by applying the
following formula:
Tm = most probable time

To = optimistic time (shortest)
Tp = pessimistic time (longest)
Te = estimated time
Tm = (To + 4 Tm + Tp) / 6
Once the most probable or average time is calculated, the ‘Logic table’ is constructed
and this time reflected on the table.
The ‘Logic table’ shows a list of the activities and the logical order in which they are
linked. This is also referred to as ‘constraints’ between the activities. This table forms the
basis for creating a ‘network diagram’ to visually depict the sequence of activities. The
table below indicates a list of activities, with their predecessor(s) and successor(s).
_____________________________________________________________________
_______________________________________________________________________________________________
ACTIVITY Most likely PREDECESSOR ACTIVITY SUCCESSOR ACTIVITY

(average)
Time (Tm) in days
A 2 Days - B,C,D
(Design the
landscape)
B 3 Days A E
(Prepare back of park)
C 4 Days A E
(Prepare front of park)
D 2 Days A F
(Order plants)
E 2 Days B,C G
(Add compost to land)
F 3 Days D G
(Prepare the plants)
G 3 Days E,F -
(Plant)
_____________________________________________________________________
_______________________________________________________________________________________________
Step Two - Construct the Network diagram and calculate the

Critical Path.
The Forward Pass - to determine the Project Duration. This calculates the Early
Start and the Early Finish Days (at a Junction take the highest Early Finish
value).
3 5 At a junction, take the highest

B 3 Days Early finish value, i.e. 6
7 8
E 2 Days
1 2
3 6
A 2Days
C 4 Days
9 11
G 3Days
3 4 5 7
D 2 Days F 3 Days
_____________________________________________________________________
_______________________________________________________________________________________________
Calculations for the above network diagram.( Early start and Early
Finish)
Activity Early Start Early Finish

Early Finish = early
start + duration - 1
A Starts at beginning of day 1 1+2-1 = 2
B Starts after end of day 2, i.e. Day 3 3+3-1 = 5
C Starts after end of day 2, i.e. Day 3 3+4-1 = 6
D Starts after end of day 2, i.e. Day 3 3+2-1 = 4
E Can only start after day 6 i.e. Day 7 7+2-1 = 8
F Starts after end of day 4, i.e. Day 5 5+3-1 = 7
G Can only start after day 8, i.e. Day 9 9+3-1 = 11 (Project
Early Finish is at the
end of Day 11)
_____________________________________________________________________
_______________________________________________________________________________________________
The Backward Pass - to determine the critical path (the longest path through the
network) and the float (spare time available on the activity). The highest individual float
amount on an activity is the total spare time for the complete network. The individual;
float amount cannot be added up for each path on the network diagram. Remember that,
at a Junction, to take The lowest Late Start value.
After calculating the backward pass, the float per activity needs to be calculated by using
the following formula: Float = LS-ES. The float is shown in bold on the left hand side, in
the centre of the activity. The critical path (The longest path. And the path with no, or the
least, float) is A-C-E-G. If any one of these tasks is delayed the project end date will be
pushed out.
3 5
1 B 3 Days Critical
4 6 Path
(Longest
7 8 path)
0 E 2 Days
7 8
1 2
3 6
0 A 2Days
0 C 4 Days
1 2
3 6
9 11
0 G 3Days
Use lowest
Late Start
9 11
at junction
3 4 5 7
1 D 2 Days 1 F 3 Days
4 5 6 8
_____________________________________________________________________
_______________________________________________________________________________________________
Calculations for the above network diagram.

(Early start and Early Finish).
Start by letting the early finish = late finish
Activity Late Start Late Finish
Late Start = Late finish - duration +1
A 2-2+1 = Day 1 Must finish at the end
of Day 2 if D must start
on Day 3 (Lowest Late
start of B,C or Task D)
B 6-3+1 = Day 4 Must finish at end of
Day 6 if E must start on
Day 7
C 6-4+1 = Day 3 Must finish at end of
Day 6 if E must start on
Day 7
D 5-2+1 = Day 4 Must finish at end of
Day 5 if F must start on
Day6
E 8-2+1 = Day 7 Must finish at end of
Day 8 if G must start
on day 9
F 8-3+1 =Day 6 Must finish at end of
Day 8 if G must start
on day 9
G 11-3+1 = Day 9 Let EF=LF (Bring down
Day 11 to LF).
Day 11 (From EF)
_____________________________________________________________________
_______________________________________________________________________________________________
Step 3 the Gantt chart (Bar chart) for the above network diagram
The early start Gantt chart.
Day (Working from 8AM TO

5PM) M Tu W Th F M Tu W Th F M
Activity \ Day number 1 2 3 4 5 6 7 8 9 10 11
A
B
C
D
E
F
G
The Late Start Gantt Chart
Day (Working from 8AM TO

5PM) M Tu W Th F M Tu W Th F M
Activity \ Day number 1 2 3 4 5 6 7 8 9 10 11
A
B
C
D
E
F
G
_____________________________________________________________________
_______________________________________________________________________________________________
NOTE: The red activities are the critical path activities. From the Gantt chart it is easy to
see how they follow on from each other to create the longest path. This longest path is
known as the ‘critical path’. Any delays on this path will cause the project end date to be
extended. The activities with float are pushed to the right in the late start Gantt chart and
the critical activities do not move at all as they have no float. Also, note that, weekends
are non-project work days in the above detailed example. Once the Early Start / Early
Finish and Late Start / Late Finish Gantt charts are drawn up, the resource and cost
allocations can commence.
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Draw a Gantt chart for your own Project by following

these steps:
List the steps required to complete the Project (from

your work breakdown) and estimate the time
required for each step.
On the grid below: list the steps down left side of chart and time intervals
along the bottom
Draw a horizontal bar for each step, from the planned start date to the
planned end date
Overlap the parallel steps that can be done at the same time
Estimate the resource requirements for each activity
Allocate a cost per activity per day.
Allocate a contingency allowance where you feel the risk is higher
_____________________________________________________________________
_______________________________________________________________________________________________
Remember - a Gantt chart shows:
The minimum total time needed to complete the Project
Proper sequencing of events and activities
Which steps can be underway at the same time
The actual progress can be charted to show actual beginning and end times versus
estimated beginning and end times.
Step 4: Resource management

A resource is usually understood to mean the following.
Manpower
Materials
Machinery
Financial funds
A resource is basically any commodity that is required to complete the activity / task. The
ideal situation is where the resource requirements equals the resources available.
Unfortunately in project management this seldom happens, because it is not always
possible to adjust supply with demand, so some form of compromise is essential.
• When a resource is overloaded there are three basic solutions

available to address the problem :
Delay activities with float.
Resource-limited smoothing, where resources are assigned to a pre-determined

limit and re-schedule if necessary.
Time-limited resource smoothing, where the end date of the project fixed and
resources are increased to meet the revised manpower histogram.
_____________________________________________________________________
_______________________________________________________________________________________________
• Resource Estimating
The resource estimate is linked directly to the scope of work and the Bill of Materials.
The scope of work may be expressed as so many tones of steel erected, or so many
square-meters of wall to be painted etc.
From this scope the man-hours per unit of X must be determined and trade-off analysis
between the resource requirement and the activity duration must be performed.
E.g. The work requirement is to erect 12 tones of timber and the estimator knows from
past experience that the work can be done in 150 man-hours per tone and the men work
10 hour shifts, then the equation is:
(12 tones X 150 man-hours per tone)

= 180 man days
(10 hours per day)
The resource / duration trade-off would be as follows:
RESOURCE MEN DURATION DAYS MAN-DAYS

10 18 180
11 16.4 180
12 15 180
13 13,8 180
14 12.9 180
_____________________________________________________________________
_______________________________________________________________________________________________
• Step 5: Resource Forecasting

The next step is to forecast the total resource requirement by discipline or
interchangeable resource.
This is done by compiling all the resource estimates and presenting them in a
structured resource table as follows:
ACTIVITY RESSOURCE QUANTITY RESSOURCE LEAD

NUMBER TYPE PER DAY DURATION TIME
010 WELDER 5 4 DAYS O
Definitions :
Activity Number: The resource information is addressed through an
activity number.
Resource Type: This field is used to distinguish the different types of

resource.
Quantity / Day: Use this field to enter the quantity of resource required
per day.
Duration: Use this field to indicate how man days the resource will be
working on that activity.
Lead-time: this is the difference in time between the activity's scheduled

start and the resource's start.
If there is more than one resource working on an activity. Use a separate

line for each resource.
_____________________________________________________________________
_______________________________________________________________________________________________
ACTIVITY RESOURCE QUANTITY RESSOURCE LEAD

NUMBER TYPE PER DAY DURATION TIME
010 ENGINEER 3 6 DAYS O
010 FITTER 4 10 0
• Step 6: Resource Levelling
An example of an unlevelled Gantt Chart and

Histogram
The resource Dennis works an 8 hour day and on day one has 24 hours work
scheduled. On day two 16 hours and on day three, 8 hours. Clearly Dennis cannot
do all this work without working overtime to resolve the conflict situation. The
resource histogram for Dennis is shown below the Gantt chart.
ec '97 28 Dec '97 4 Jan '98
ID Task Name Duration W T F S S M T W T F S S M T W T F S S
1 RESOURCE LEVELLING 3d
2 TASK 1 1d DENNIS
3 TASK 2 2d DENNIS
4 TASK 3 3d DENNIS
5
6
_____________________________________________________________________
_______________________________________________________________________________________________
Resource Graph or Histogram for the Resource Dennis as

Scheduled on the above Gantt Chart
Dec 28, '97 Jan 4, '98
F S S M T W T F S S M T W T
300%
250%
200%
150%
100%
50%
% Work Allocated: 300 200 100
Dennis Overallocated: Allocated:
Full Resource Levelling is done as follows

The Gantt chart with the resource Dennis (normal hours per day = 8) with full resource
levelling is shown below. With full resource levelling the tasks are delayed to match the
resources availability (note the three tasks are not linked in this example)
ec '97 28 Dec '97 4 Jan '98

ID Task Name Duration W T F S S M T W T F S S M T W T F S S
1 LEVELLED PROJECT 6d
2 TASK 1 1d DENNIS
3 TASK 2 2d DENNIS
4 TASK 3 3d DENNIS
_____________________________________________________________________
_______________________________________________________________________________________________
The levelled resource histogram below shows that all conflict has been
resolved by pushing out the activities with conflict and thereby extending the duration of
the project from three to six days.
28 Dec '97 4 Jan '98 1

M T W T F S S M T W T F S S M T
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
100 100 100 100 100 100
DENNIS Overallocated: Allocated:
• An example of using units or teams as opposed to individual

resources
This example is based on the following network diagram. This network diagram is for a
landscaping organisation who must landscape five gardens. There is one team of
landscapers with five members in the team. These five members all have the same set
of skills and are interchangeable on each of the gardens requiring landscaping. The
network diagram below shows the activities average time, as well as the logical
relationship, or links between the gardens. The contract with the landscaping
organisation specified this sequence (links) between the various gardens. The Gantt
chart is drawn up below this network diagram and the resources allocated by the
activities requirements.
_____________________________________________________________________
_______________________________________________________________________________________________
o The network diagram
GARDENS (5 IN
TEAM)
1 7d
29/12/97 6/1/98 17
GARDEN1 GARDEN2 GARDEN4
2 2d 3 1d 5 1d
29/12/97 30/12/97 31/12/97 31/12/97 5/1/98 08 5/1/98 17
GARDEN3 GARDEN5
4 3d 6 2d
31/12/97 2/1/98 17 5/1/98 08 6/1/98 17
o The Gantt chart and unlevelled histogram
The Gantt chart graphically shows the sequence of activities. The resources specified
and required to complete each activity are allocated. This is seen in the parenthesis
beside the resource name on the Gantt chart (right hand pane). Garden 1 requires all
five of the members and so on.
_____________________________________________________________________
_______________________________________________________________________________________________
ec 28, '97 Jan 4, '98 Jan 11, '98

ID Task Name Dur Pred Succ T W T F S S M T W T F S S M T W T
1 GARDENS (5 IN TEAM) 7d
2 GARDEN 1 2d 3,4 GARDEN TEAM[5]
3 GARDEN 2 1d 2 5 GARDEN TEAM[4]
4 GARDEN 3 3d 2 5,6 GARDEN TEAM[3]
6 GARDEN 5 2d 4 GARDEN TEAM[5]
7
8
9
10
11
12
o The unlevelled Histogram (Maximum Men In The Team Is 5)

Dec 28, '97 Jan 4, '98 J
T W T F S S M T W T F S S M T
10
9
8
7
6
5
4
3
2
Peak Units: 5 7 3 3 10 5
GARDEN TEAM Overallocated: Allocated:
The histogram above shows that the team is over-allocated on two days, Wednesday
and Monday. There in only float (spare time) on garden two and garden four. But
working day-by-day and firstly pushing out activities that have float to try and
accommodate the resources, it is not possible. Because the resources cannot be split up
and the specified amount of resources are pre-defined per task, there is insufficient float
available.
_____________________________________________________________________
_______________________________________________________________________________________________
This requires that the tasks be moved past their allowable float, which in turn pushes out
the projects end date (Early Finish date) in order to accommodate the resource
limitations. This is shown in the levelled Gantt chart below.
The levelled Gantt chart for 5 Men in the Team (Showing

baseline activities, i.e. ‘what it was before’
Dec 28, '97 Jan 4, '98 Jan 11,

ID Task Name Dur Pred Succ M T W T F S S M T W T F S S M T W
1 GARDENS (5 IN TEAM) 9d
3 GARDEN 2 1d 2 5 GARDEN TEAM[4]
4 GARDEN 3 3d 2 5,6 GARDEN TEAM[3]
6 GARDEN 5 2d 4 GARDEN TEAM[5]
7
8
9
10
11
12
The histogram below shows that there are no resources over-allocated as there is no
more than the limitation of the five resources allocated on any of the project days. This
has unfortunately caused the project end date to be pushed out.
_____________________________________________________________________
_______________________________________________________________________________________________
Histogram for the above, Levelled Gantt Chart for 5 in the team.
28 Dec '97 4 Jan '98
S M T W T F S S M T W T F S S M
5.0
4.5
4.0
3.5
3.0
2.5
2.0
1.5
1.0
0.5
5 5 3 3 3 4 5 5 5
GARDEN TEAM Overallocated: Allocated:
_____________________________________________________________________
_______________________________________________________________________________________________
• Step 7: Cost Estimation and Budgeting
• Cost estimation and budgeting is an output from resource

planning.
Resource requirements – The output of the resource planning process is a description of
what types of resources are required and in what quantities for each element of the work
breakdown structure. These resources will be obtained either through staff acquisition or
procurement.
• Cost Estimating
Cost estimating involves developing an approximation (estimate) of the costs of the
resources needed to complete project activities. When a project is being performed, care
should be taken to distinguish cost estimating from pricing. Cost estimating involves
developing an assessment of the likely quantitative result – how much it will cost the
performing organisation to provide the product or service required. Pricing is a business
decision – how much will the performing organisation charge for the product or service.
• Inputs to cost Estimating.

The Work Breakdown Structure and the resource requirements are required as inputs to
cost estimating. The following cost information is required
o Resource rates – The individual or group preparing the estimates must know
the unit rate (e.g. staff per unit rates, bulk material cost per cubic meter) for
each resource in order to calculate project costs. If actual rates are not
known, the rates themselves may have to be estimated.
o Activity Duration estimates – will affect cost estimates on any project where
the project budget includes an allowance for the cost of financing (interest
rates).
o Historical Information – Information on the cost of many categories of
resources is often available from one or more of the following sources;
_____________________________________________________________________
_______________________________________________________________________________________________
o Project Files – One or more of the organisations involved in the project may
maintain records of previous project results that are detailed enough to aid in
developing cost estimates. In some application areas, individual team
members may maintain such records.
o Commercial cost estimating database – Historical information is often
available commercially.
o Project Team Knowledge – The individual members of the project teams
may remember previous actuals or estimates. While such recollections may
be useful, they are generally far less reliable than documented results.
o Chart of Accounts – A chart of accounts describes the coding structure
used by the performing organisation to report financial information in its
general ledger. Project cost estimates must be assigned to the correct
accounting category (figure 12).
Figure 11: Example of Accounting Codes.

Department Code
Technology 340
Corporate Bank 210
Loan Products 340
Internal Audit 710
Cash Management 560
• Tools and Techniques for cost Estimating
o Analogous Estimating – Also called top down estimating means using the
actual cost of a previous, similar project as the basis of estimating the cost of
the current project. It is frequently used to estimate total project costs when
there is a limited amount of detailed information about the project. It is a form
of expert judgement and is generally less costly than other techniques, but is
also generally less accurate. The upward effect of inflation can be established
using a commercial available cost price index (CPI) and inflation indices.
_____________________________________________________________________
_______________________________________________________________________________________________
o One of the problems with method is that different commodities tend to

escalate at different rates, this can be addressed by sub-dividing the project
into its component costs by a CPI category see the figure below . It is most
reliable when; The previous projects are similar in fact and not just
appearance. The individual or groups preparing the estimate have the
needed expertise.
Figure 12: Sample Analogous Estimating Template
YEAR 2000 2001 2002
Base Cost Inflation Rate New Price Inflation Rate New Price
Labour R500,000 10% R550,000 8% R594,000
Material R400,000 15% R460,000 5% R483,000
TOTAL R900,000 15% R460,000 5% R1,077,000
• Parametric Modelling – Involves using project characteristics (parameters) in a

mathematical model to predict project costs. The models can be simple ( It costs
R2.50 per meter square) or complex (one model of software development costs
uses 13 separate adjustment factors each of which has 5-7 points on it). These
models are most likely to be accurate when; The historical data used to develop
the model was accurate. The parameters used in the model are quantifiable. The
model is scalable (works well for either a large of small model). See the figure
below.
_____________________________________________________________________
_______________________________________________________________________________________________
Figure 13: Sample Parametric Model

Management Fee 5% of Contract price
Quality Assurance 1% of Contract price
Engine Beds 2% of Engine
Pipe work 20% of Generator price
Consumables 10% of material price
Profit 20% of construction price
o Bottom up estimating – Involves estimating the cost of individual work

items, then summarising or rolling up the individual estimates to get a project
total. See the figure below.
Figure 14: Sample Bottom up estimating Template

TASK DESCRIPTION LABOUR MATERIAL PLANT TRANSPORT TOTAL
HIRE
Mark out
100 R1,000 R500 R1,500
foundations
200 Dig Foundations R5,000 R500 R1,000 R500 R7,000
300 Lay Foundations R3,000 R10,000 R3000 R2,000 R18,000
TOTAL ESTIMATE R26,000
o Computerised tools – MS Project ® is widely used to assist with cost

estimating.
o 3-point consensus - Use experts to determine pessimistic (P), optimistic (O)
and most likely (ML) costs.
Target Cost Estimate = (P + 4ML + O) / 6
• Cost Estimating Outputs.

o Cost estimate – Cost estimates are quantitative assessments of the likely
costs of the resources required to complete project activities. They may be
presented in summary or detail.
_____________________________________________________________________
_______________________________________________________________________________________________
o Costs must be estimated for all resources that will be charged to the project.
This includes, but is not limited to , labour, materials, supplies, and special
categories such as inflation allowance or cost reserve.
o Supporting Detail – Should include; A description of the Scope of Work –
Provided by a reference to the WBS
o Documentation on the basis for the estimate – i.e. how it was developed.
o Documentation of any assumptions made.
An indication of a range of possible results i.e. R10,000 + R1000 to indicate
that an item is expected to cost between R9,000.00 to R10,000
o Cost Management Plan – The cost management plan describes how cost
variances will be managed (e.g. different responses to major problem than to
minor ones). It may be formal or informal, highly detailed or broadly framed
based on the needs of the project stakeholders.
• Cost Budgeting.
Cost budgeting involves allocating the overall cost estimates to individual work items in
order to establish a cost baseline for the measuring project performance.
Cost management includes the identification, analysis and refinement of project

costs to produce a budget and to control project cost. Cost estimations and
budgeting are based on the Work breakdown structure. In the same way that you
assigned quality standards to each element, you can assign costs to each
element.
9 Typical cost components include Labour (wages, contract / temporary /

consultants included), Overheads, Materials (inputs into items to be
delivered), Supplies (used in the delivery of items, e.g. stationery, reference
sources) and other Resources, Equipment purchase or rental (e.g.
computers, scaffolding, vehicles), Administrative costs (support services,
secretarial, purchasing) and profit if applicable.
9 Labour will be a significant component, so accurate time estimation will be

required before this can be budgeted. Refer to the WBS and schedule for
input.
_____________________________________________________________________
_______________________________________________________________________________________________
Combine similar items into categories of costs for the budget proposal to the
sponsor, stakeholders and / or higher project authorities.
Agree with the relevant parties on the costs, the maximum flexibility in the
budget, and on ways to handle discrepancies between the budgeted cost and
the actual cost.
9 A key issue here is Scope creep - changing specifications without formal

approval, due to new ideas that crop up, the team wanting to over-deliver or
new requirements on the part of stakeholder or customer.
Obtain agreement from resource providers / suppliers that they will incorporate
agreed cost estimates into their budgets, and obtain cost codes where
relevant. Ensure that the budget is phased correctly throughout the project life
cycle.
o Cost Budgeting Inputs.

o Cost estimates – Described in section 1.6.2.3.
o Work Breakdown Structure – Described in section 1.3.3.
o Project schedule – Includes the planned start and expected finish
dates for the project elements that costs will be allocated to.
o Output from Cost Budgeting.

o Cost baseline – A time phased budget that will be used to measure
and monitor cost performance on the project, developed by summing
estimate costs by period and is usually displayed in the form of an “S”
curve during the design and execution phase. The following might be
useful headings for your budget:
Labour: Wages/salaries for Project staff
Overheads: Taxes, fringe benefits
Materials: All items used on the Project
Supplies: Tools and equipment, etc.
Equipment: Rental or price (if bought) of machinery,

hardware and other
_____________________________________________________________________
_______________________________________________________________________________________________
General and Admin: Cost of management and support

services for time of Project
Profit: Successful completion (% of cost)
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Refer to the Work Breakdown Structure and allocate an
estimated cost to each item.
_____________________________________________________________________
_______________________________________________________________________________________________
Summary on managing time

There are four steps to using the schedule to control the Project’s duration:
Set a Measure: The planned dates set the measures for control of time.
It is important to measure against a fixed baseline. Do not update the
schedule at every meting, use the baseline set out during the planning phase
of the Project. Team members can quickly forget what the original schedule
was!
Record Progress: This is achieved by reporting actual start and finish

dates versus planned start and finish dates. Progress is measured regularly
and fed up to higher levels of the WBS over a longer period.
Calculate the Variance: The variance is calculated either in the form

of delays to completion of critical or near critical work, or as the remaining float
for activities still to be completed.
Take Remedial Action: In order to determine the impact of any delays

on the Project, and any proposals for eliminating them, it is necessary to
analyse the effect of each, on the overall Project. The final step is take action
to correct the problem!
_____________________________________________________________________
_______________________________________________________________________________________________
• Step 8: Quality management on the Project
Institute quality and improvement mechanisms within a project management process

• Establish and conduct a project review program to evaluate project team
performance
• Demonstrate application of emerging techniques of participative project
management to the managing of the stakeholder process, integral to South
African community projects, and community projects in general in developing
countries
• Identify critical success factors of new project situations
• Planning, monitoring and managing the Quality dimension

If a project is not managed properly, it is almost impossible to achieve a quality product.
The project manager must understand how to measure time and cost – hours or days,
Rand and cents, but very few people have a clear idea of what is meant by quality in a
Project.
The word quality is often used to mean expensive, luxury or conforming to an extremely
high specification. For example, a quality car is a Mercedes or Roll Royce; a quality
watch is a Rolex. Adopting this view of quality could result in you pursuing an impossibly
expensive standard that is neither what the customer wants, not what is necessary for
the Project. Good quality does not have to mean high prices; it means supplying the
customer what they want, to the standard and specification they require, with a
predictable degree of reliability and uniformity, and at the price that suits their needs.
Quite a tall order!
_____________________________________________________________________
_______________________________________________________________________________________________
• Achieving quality on projects

The process being adopted by many organizations is total quality management (TQM).
Total quality management means:
Harnessing everyone’s effort to achieve zero defects at lowest
cost.
• Zero defect means to customer requirements. On a Project this is embodied in
five elements:
o Quality of Product: This is the ultimate goal. This means meeting the
customer’s purpose.
o Quality of Management Process: Another necessary condition for achieving
quality product. The management process is to assure the quality of the product
throughout each stage of the Project.
o Quality Assurance: These are steps taken in advance to increase the

likelihood of obtaining a quality product. Prevention aims to stop defects
from happening.
o Quality Control: These are steps taken to measure the quality of both the
product and the management processes, and to eliminate any variance
from the desired standard.
o Attitude of mind: This is the commitment of everyone in the Project team

to achieve quality. This commitment must start at the top. It cannot be
delegated.
• An example of a quality specification for a corporate

dinner function:
o The Venue must accommodate 50 people, seated at round tables of 5 per table
o At least 5 toilets to be available in each rest room.
o Parking to be adequate for 50 vehicles.
o At least 2 accredited Security guards to be available from 5.00pm to 12.00pm.
o Map to show directions to venue from Durban International Airport to The venue
in Durban centre.
_____________________________________________________________________
_______________________________________________________________________________________________
o Quality management tools:

o The tools are used in conjunction with one another. We have already
used the Work breakdown structure in defining the Scope of the Project,
and we will use it again here, adding to it by specifying standards for
each of the units and sub-units identified.
o The principle tools used in defining, planning and managing quality are:
The Work Breakdown structure
Project specifications
Each of the specific items and tasks identified in the Work Breakdown structure
can have specifications. While it is good to aim for high standards, remember that
the specifications will be used as measures for success for the various stages of
the project, and if unnecessarily stringent may be difficult to meet, or may add
significantly to the cost and / or time requirements of the project.
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
For your Project, select five of the outcomes or outputs

and write them down below. Identify at least three
quality standards that they must each meet in order to
be acceptable to the customer.
Outcome or Output Quality standard
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.3 The implementation phase
During this phase the contracts are awarded instructions are issued to procure
equipment and services, make the product or solve the problem. This phase involves
carrying out and monitoring the planned activities. It would typically involve all the team
members, suppliers and contractors, communication with stakeholders and monitoring,
reporting and managing all resources, parameters and people.
The project manager moves into a co-ordinating and managing role, ensuring that the
team members have the skills, knowledge and resources they require, that they are
working well together, that schedules are being adhered to, quality standards achieved,
and that budgets are not overspent. Achievements should be noted and rewarded to
maintain motivation. Any unforeseen problems that arise need to be dealt with in a
satisfactorily manner and corrective action need to be taken when deviations occur. This
is indicated in the figure below.
Figure 15: The Process for Managing Project Scope Changes
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.3.1 Managing the Project Implementation
Creating the project charter and scope, supported by detailed plans is often seen as the
most difficult part by some project managers. However, now this project must be
managed and the project manager must ensure that it represents the current status of
the project. Just as important, the project plan should always give a good representation
of how much work is remaining. The following are some recommendations to review the
project plan.
• Review the project plan on a regular basis. For a small to medium project, it is
probably still best to do this on a weekly basis through a formal project evaluation
process. For larger projects the frequency might be every two weeks due to the
volume of activities or the longer duration of the activities. Try to avoid having long
delays before progress meetings are held. The activities on the critical path should
be evaluated much more frequently, as this is the longest path through the network
and any delays on this path will delay the whole project. The activities with critical
resources must also be monitored more frequently. Where the critical resources are
on the critical path, the reporting frequency should possibly be daily.
• If the project management systems allow for automatic capturing of actual dates,
effort hours and costs, update the project plan with this information. On an on-going
basis. This will also allow the project manager to manage by exception, by identifying
only the deviations. By identifying activities that have been completed within the
scope boundaries will allow the project manager to spend more time on the
exception activities in the project. The effort hours and status can come from team
members through the status Reports and status meetings
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.3.2 Managing Project Communication
Effective and efficient project management communication on a project is one of the

most critical success factors for managing the expectations of the customer,
stakeholders and the shareholders. If they are not kept well informed of the project
progress there is a much greater chance of problems and difficulties due to differing
levels of expectations. In fact, in many cases where conflicts arise, it is not because of
the actual problem, but because the customer or manager was surprised.
It is essential that all projects should communicate status. This includes reporting from
the project team to the project manager and reporting from the project manager to the
customers and stakeholders. Two typical forums for communicating status are through a
status meeting and status reports. Larger projects need to be more sophisticated in how
they communicate to various constituents.
The project manager needs to determine whether there are any other activities that
should be completed, but are not. This information can be gathered by running the
appropriate report from the project management tool. Work with the project team
members who are assigned to see what is going on. There could be problems that need
to be resolved, or it may be that the length of time needed to complete the activity was
underestimated. Determine how much additional effort and duration will be needed to
complete the work and update the project plan accordingly.
After the project plan has been updated to show the current reality, let the tool
reschedule the work to see if the project will be completed within the original effort, cost
and duration. Even though some activities may be completed later than planned, other
work may be completing early.
Run additional reports from the project management tool, such as MS project ® or any
other systems used to assist in running the project. This will further assist in determining
how the project is progressing. For instance, look at resource allocation. The project may
be completing on schedule because some of the team members are being scheduled for
75 hours per week.
_____________________________________________________________________
_______________________________________________________________________________________________
If you saved a baseline version of the project plan (the original plan before the project
implementation began), you can run reports to compare the current project plan against
the baseline to see the variances.
Look at your budget. (Because of how financial reporting is done, you may need to
manage the budget on a monthly basis, even if you update the project plan on a weekly
or bi-weekly basis.) If you are keeping all of your expenditures in your project
management tool, this may be as simple as running a report to compare actual
expenditures against budgeted expenditures. More than likely, however, you are keeping
up with your budget on a separate spreadsheet. Update the tool to reflect all
expenditures paid to date, including all expenses related to labor, equipment and
material. Then compare the numbers against your budget. There are a number of items
to factor in to this comparison.
Some expenses may be budgeted for, but in another period. If you paid for a major
purchase this period that was originally scheduled for next period, then it shouldn't
surprise you to see that you are technically 'over-budget'. This type of expense will be a
wash over time.
You may not be over-budget if you are also ahead of schedule. If your project is on
schedule, but over-budget, there may be a problem. However, if your project is ahead of
schedule, it may be fine that you are also ahead of your budget. For instance, you may
have paid a contractor overtime to get ahead of schedule, or utilized more employee
labour hours to get ahead of schedule. In this case, creating your estimate-to-complete
should show that the project would complete within its allocated budget.
The project may be on schedule but over-budget because some of the activities are
taking more effort than estimated. This could be because of working unscheduled
overtime or applying more resources than estimated. In this case, if the trend continues,
the project budget may be in jeopardy. This should be raised as a budget risk unless
there are mitigating factors that will allow the over-budget trend to reverse.
It's very possible that mandatory activities or project expenses were missed when the
original estimates were put together. If the work or expense is required, but missed in the
estimating process, you may not be able to invoke scope change management. In this
_____________________________________________________________________
_______________________________________________________________________________________________
case, a budget risk should be raised unless there are mitigating factors that will allow
you to recoup the additional expense through a cost saving somewhere else.
Is an over-budget situation caused by doing work that is outside the approved Project
Definition or business requirements? If so, the work should stop until scope change
management can be invoked. Even if the over-budget can be recouped somewhere else
by cost savings, scope change requests should not be allowed to impact the project
unless they were approved, along with the corresponding approval of revised budget
and delivery timeframe, if necessary.
Look for other signs that the project may be in trouble. These
could include:
Activities starting to trend over budget or behind schedule early on in the project. There
is a tendency to think you can make it up, but usually these are a warning that you will
get further and further into trouble.
• A small variance starts to get bigger, especially early in the project.

• You discover that activities you think have already been completed are
still being worked on.
• You need to rely on unscheduled overtime to hit the deadlines, especially
early in the project.
• Team morale starts to decline
• Deliverable quality or service quality starts to deteriorate.
• Quality control steps, testing activities and project management time
starts to be cut back from the original schedule.
If these situations start to occur, raise visibility through risk management. Put together a
Risk Management Plan to proactively ensure that the project stays on track. If you
cannot successfully manage through the problems, raise an issue. Evaluate the critical
path of the project. The critical path is the sequence of activities that must be completed
on time for the entire project to be completed on schedule.
If the end date has slipped, it will be because at least one activity on the critical path did
not completed on time. It is important to understand the critical path sequence to know
_____________________________________________________________________
_______________________________________________________________________________________________
what activities need to be accelerated for the project to complete earlier. Placing
additional resources on non-critical activities will not result in the project completing
earlier. It is also very possible for the critical path to change on the project. Again, you
may be trying to accelerate activities that were on the critical path, but if the critical path
changed, this will not have the intended result.
Adjust the project plan so that it reflects how the remaining work will be completed. The
first priority should be to complete the project within the original estimates for effort,
duration and cost.
If any of the original estimates cannot be met, new estimates need to be prepared and
communicated to your management and to the customer. This is important information to
share because there may be areas where they can provide input. For instance, the
customer may agree to reduce the remaining requirements to allow the project to
complete within the original estimates.
On a monthly basis, adjust future work to reflect any additional information, or additional
detail you know now. For instance, when the project plan was created, many of the later
activities may have been vague, and placed on the project plan at a high level. On a
monthly basis, this work needs to be defined in greater detail. For sure, work that covers
the next three month window should be scheduled out in activities of not more than 80
hours. If work is entering this three month window at a higher level, then break it down
into a lower level of detail. Note that this step refers to originally identified work that
requires more detailed information. This is not the place to add new work. That is done
through effective scope management.
9.3.3.3 Techniques to Manage the Project Plan
• Techniques to Get a Project Back on Schedule
Just because the project manager monitors the project on an ongoing basis does not
mean that deadlines will always be met. The good thing about managing the project plan
is that you will know very quickly if you are trending over the end date. This will give you
an opportunity to put a proactive plan in place to get back on schedule. There is not a
_____________________________________________________________________
_______________________________________________________________________________________________
simple process that will do the trick in every case. However, there are some techniques
you can apply to get the job done.
• Overtime work. Can team members work (more) overtime to make up the
shortfall? This may have cost consequences, but may allow you to get the project
back on schedule.
• Reallocate resources onto the critical path. First determine what
work is on the critical path of the project. Then see if there are resources that can
be moved from other activities to help with the work on the critical path. This will
allow you to get the project back on track by delaying or stretching out some work
that can safely be delayed. Be careful though - delaying some work may end up
changing the critical path.
• Swap resources. Is the project delay caused by a team member(s) who is
less productive than others or does not have the right skill set? There may be
opportunities to replace resources, or swap them within a project team so that a
more productive resource works on the critical path.
• Improve processes. There may be delays caused by inefficient internal
processes. Get team member feedback and look for ways that are within your
team's internal control to streamline processes. If there are delays caused by
external processes, try to negotiate changes to the processes on a going
forward, or at least a temporary basis.
• "Crash" the Schedule - Crashing the schedule means to apply additional
resources to the critical path, in a way that minimizes the incremental costs. For
instance, if one person were assigned to complete an activity in ten days, would
two people be able to complete it earlier - perhaps not in five days, but earlier
than ten days? The additional resources may come from within the project team,
or they may be loaned temporarily from outside the team. Note that one of the
goals is to minimize the extra cost. However, in exchange for completing some
work ahead of schedule, crashing usually always leads to some additional
incremental cost to the project.
• Fast Track - This involves looking at activities that are normally done in
sequence, and assigning them totally or partially in parallel. For instance, a
concrete foundation normally cannot be laid until the wooden frames are up.
_____________________________________________________________________
_______________________________________________________________________________________________
However, as a part of fast tracking, can the concrete be poured on one side of
the foundation while the other half is still being framed? If so, then parts of these
two activities can be done in parallel. Note that this technique can accelerate the
schedule, but it almost always leads to more rework in subsequent activities, as
all the details of the preceding activity become known to the succeeding activity.
Therefore, there are almost always some incremental costs to the project.
• "Zero Tolerance" scope change. Work with the customer and team
members to ensure that absolutely no unplanned work is being requested or
worked on, even if it is just one hour. All energy should go into accelerating the
core work that was agreed to.
• Regain commitments. Work with team members to evaluate future work,
re-validate estimates, and gain commitments to complete work on schedule.
Refocus the team on meeting deadlines.
• Improve morale. Build shared purpose, increase camaraderie, do some fun
things. The team will work harder and perform better if they do not spend time
complaining and sulking. Get people excited and happy again.
• Scope back work. If the completion date is firm (timeboxed) and you
cannot get the remaining work completed by the deadline date, then raise the
situation as an issue. If no other options are found, work with the customer to
reduce the scope and deliver less by the due date. This will first require issues
management, and then scope change management. Update the Project
Definition, if necessary, and replan the project based on the new remaining
workload.
• Techniques to Get a Project Back on Budget

Just as the Project Manager may face scheduling difficulties, you may also find yourself
trending over-budget. If you monitor costs regularly, you should know very quickly if you
are trending over your budget. This control process is somewhat more difficult than
managing the schedule, because there could be a variety of reasons why your financial
information is not as good or as accurate. With scheduling, you know right away if you
missed an end date. With the budget, you may not always know. First of all, you rarely
spend money at a constant rate.
_____________________________________________________________________
_______________________________________________________________________________________________
So, the project manager needs to understand what you expected to spend during the
period, as well as what you actually spent. In most companies, financial information
comes in on a lag. For instance, you might not know the financial status for the previous
month until second week of the current month. You may not recognize some expenses
until you receive an invoice. In other cases, you may not have the expense hit the books
until you pay an invoice, which may be much later.
In any case, although you may not always have the financial information at the optimum
time, there are a number of techniques you can apply to try to rein in spending to get
back within your budget.
• Unpaid overtime work. This option takes advantage of the situation

where your employee staff does not get paid for overtime. It is usually the first
place to look, and a team will rally around overtime to get a project back on
budget. This is usually not a good solution for very long.
• Swap human resources. It may be possible to swap highly paid
resources with ones that can do the work, but at a lower cost. In fact, if cost
containment is more important then scheduled, you may also be willing for the
work to take a longer time, if it ultimately can be completed successfully at a
reduced cost.
• Eliminate or replace non-labour costs. Just as with people, it may
be possible to utilize less costly materials, supplies or services than what was
originally budgeted. For instance, can travellers stay at a discount hotel chain
instead of more luxurious accommodations? Can team members utilize existing
upgraded hardware instead of new machines? Can computer-based training, or
team mentoring, be utilized instead of formal training? Can one person travel to
the customer's location instead of two or three. In each of these cases, you are
attempting to satisfy the original need, but by using a less-costly alternative.
• Improve processes. There may be cost overruns caused by inefficient
internal processes. Get team member feedback and look for ways that are within
your team's internal control to streamline processes.
_____________________________________________________________________
_______________________________________________________________________________________________
• If there are cost implications caused by external processes, try to negotiate

changes to the processes on a going forward, or at least a temporary basis.
• "Zero Tolerance" scope change. Work with the customer and team
members to ensure that absolutely no unplanned work is being requested or
worked on, even if it is just one hour. All energy should go into completing the
core work that was agreed to. All approved changes to scope must also contain
incremental budget.
• Regain commitments. Work with team members to evaluate future work,
re-validate estimates, and gain commitments to complete the remaining work
within budget.
• Use budget contingency. If the project is trending overbudget because
of underestimating some of the work, start to dip into your estimating
contingency, if you have one. .
• Scope back work. If the budget is firm and you cannot get the remaining
work completed within the budget, then raise the situation as an issue. If no other
options are found, work with the customer to reduce the scope and deliver less within
the original budget. This will first require issues management, and then scope
change management. Update the Project Definition, if necessary, and re-plan the
project based on the new remaining workload.
_____________________________________________________________________
_______________________________________________________________________________________________
Make Sure Team Members Know What Their Assignments Are

One of the basic responsibilities of the project manager is to assign work to team
members. However, some project managers are not always clear on what needs to be
done and who is responsible. This causes uncertainty in the team, and can result of
some activities running late. In fact, if you have managed projects for a while, you have
probably run into this situation. You ask a team member the status of a critical
assignment and they tell you that they did not realize that they were assigned to the
activity. A good way to test whether your directions and assignments are clear is to ask
team members what they are responsible for completing in the next two weeks. This is
not something you need to do with every team member every week. However, it can be
valuable to ask once in a while, or when a critical activity is due, just to validate whether
you are assigning the work effectively. If the team members know what is expected of
them, chances are that you are effectively assigning the world. However, if they give you
different answers than what you expect, it may mean that you need to work on being
clearer and more precise.
When you manage the project plan, you do not want to be accurate to the minute or to
the Rands and Cents. You also do not want to make a big deal if your project is a day
over deadline one week, and a day ahead of schedule the next. Your customer does not
expect that level of accuracy, and they are not interested in an hour-by-hour account of
how the project is progressing. As the project manager, you should have some sense for
what the tolerance level is for your project. For example, let's say you are updating your
project plan and you realize you have overspent your budget by R1,000. Should you
raise an issue or a risk? Should you inform your customer? It depends on your tolerance
level. If you have a R10,000 budget, you should probably be concerned, because now
you are at risk of going over budget by 10%. If your project has a one million Rands
dollar budget, then the thousand dollars is not material at all. (In fact you would be a
hero if you delivered within one thousand Rands.)
Use common sense and work with your customer on the tolerance levels for budget and
deadline. If you stay within the tolerances, then you are fine. If you go outside those
limits, then you should be concerned.
_____________________________________________________________________
_______________________________________________________________________________________________
• Manage the Project plan by using Earned Value
Earned value is a set of techniques that were first used in the 1960's in the Department
of Defense to objectively measure the status of a project in terms of budget and
schedule. The concepts are interesting and of value for all project managers. However,
from a practical standpoint, very few companies and projects utilize earned value. It is a
concept worth knowing, but probably not one worth applying to your project unless your
entire organization chooses to track progress this way.
The topic of earned value can be the subject of a one-day class. The purpose of this
page is to provide an overview of the concepts. There are many websites and white
papers that can be reviewed to find more information on this subject.
Budgeted Cost of Work Performed (BCWP). This term is also referred to as the Earned
Value. The BCWP is calculated by adding up the budgeted cost of every activity that has
been completed. If an activity is in progress, you can give it zero value until it is
completed, 50%, or the full amount. Just be sure you are consistent with whatever rule
you choose for in-progress work.
BCWP is the basic measure of how much value the project has achieved so far. By itself,
it does not tell you too much. So, we use it in combination with other calculations to
determine your budget status.
Actual Cost of Work Performed (ACWP). To calculate this number, add up the actual
cost for all the work that has been completed so far on the project.
Budgeted Cost of Work Scheduled (BCWS). This is the sum of all the budgeted
estimates for all the work that was scheduled to be completed by today (or by any
specific date).
Schedule Variance (SV). This is the BCWP - BCWS. It tells you whether you are ahead
of schedule or behind schedule. If the result is positive, it means that you have
performed more work than what was initially scheduled at this point. In other words, the
budgeted cost of the work scheduled at this time is less than the budgeted cost of the
work actually performed. Likewise, if the SV is negative, the project is probably behind
schedule.
_____________________________________________________________________
_______________________________________________________________________________________________
Cost Variance (CV). This is the BCWP - ACWP. This gives you a sense for how you are
doing against the budget. If this CV is positive, it means that the budgeted cost to
perform the work was more than what was actually spent for the same amount of work.
This means that you are fine from a budget perspective. If the CV is negative, you may
be over-budget at this point.
Schedule Performance Index (SPI). This is a ratio calculated by taking the BCWP /
BCWS. This shows the relationship between the budgeted cost of the work that was
actually performed and the cost of the work that was scheduled to be completed at this
same time. It gives the run rate for the project. If the calculation is greater that 1.0, the
project is ahead schedule. For instance, if the SPI is 1.1, it means that your project has
completed approximately 10% more work than what was scheduled. If that trend
continues, you will end up taking 10% less time to complete the project than what was
scheduled.
Cost Performance Index (CPI). This is the ratio of taking the BCWP / ACWP. This shows
the relationship between the budgeted cost of work performed and the actual cost of the
work that was performed. It gives the burn rate for the project. If the calculation is less
than 1.0, the project is over budget. For instance, a CPI of .90 means that for every
ninety dollars of budgeted expenses, your project is spending R100 to get the same
work done. If that trend continues, you will end up 10% over budget when the project is
completed.
Budget at Completion (BAC). This calculation can be in terms of dollars or hours. It is the
ACWP, added to the budgeted cost of the remaining work. If the CPI is not close to 1.0,
then the budgeted cost of the remaining work must be factored to take into account the
historical burn rate. So, if the CPI is not 1.0, then the BAC is the ACWP + (Budgeted
Cost of Work Remaining / CPI).
Estimate to Complete (ETC). This is calculated by looking at the budget at completion

(BAC), and subtracting the money (or hours) you have spent so far (ACWP).
This page gives a sense for the logic and intuition behind earned value calculations. If
you chose to use them, they can be a valuable tool for determining where you are at in
terms of budget and schedule. There are other calculations that can be included as well
_____________________________________________________________________
_______________________________________________________________________________________________
to give a fuller picture of the project status, if you have collected the basic information
shown here
9.3.3.4 Team Resistance to Managing the Project Plan
It's one thing to build a project definition and the project plan. It's another thing to
effectively manage the project. If you could issue the plan and the work assignments and
have everyone complete their activities on-time, the Project Manager's life would be
much easier. However, the process of managing the team and the project plan becomes
complicated because of the people element involved. To understand how the project is
proceeding and to ensure that it stays on track, controls are needed. You may need to
go around and ask people how they are doing. You may need people to tell you in status
reports and status meeting how they are doing. You may try to keep updated statistics
on work completed, in-progress and not started. These activities make up your overall
project management processes. However, people do not always respond well to these
processes for a number of reasons.
• They may think the processes are cumbersome and keep them from completing
their deliverables
• They may feel they will be punished for bring bad news, or doing things
incorrectly
• They may not feel the project management processes are effective
• They may have a normal human tendency against processes that feel like
controls
• The processes may not be complete or make sense. They may have tried to
follow one, but found it was not complete, or was not supported by others.
• They may feel that the Project Manager is not following the procedures.
• They may see people going around the processes without consequences
Knowing and recognizing these normal human tendencies will help design a set of
project management processes that are appropriate to the project being managed. It
also points out the need to communicate the processes effectively, including the overall
value to the project. Once discussed with the team, it is important to apply the processes
consistently for them to be adopted successfully on the project.
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.3.5 Updating the Project Plan
In most projects the project manager is responsible for the project plan and updates it on
a weekly or bi-weekly basis. In most projects the project manager is the only one that is
allowed to update the plan. However, there are some options, especially for larger
projects.
In some cases, the project manager asks each team member to update the project plan
with a current status and effort hours (if they are being tracked). In this scenario, the
team members normally indicate whether their assigned work is completed. If not, they
identify what percentage of the activity is complete, or adjust the end date to reflect
when the activity will be complete. They can also plug in their actual effort hours per
activity so far. In most cases, team members are not allowed to assign themselves to
new work, add new activities or otherwise alter the project plan. After the team members
update the plan with current status, the project manager can begin to evaluate the
overall project status.
For very large projects, it is also common for one or more people to be assigned to
update the project plan on behalf of the project manager. They can get information from
team members and update current status and actual hours worked. They can run a
standard set of reports for the project manager and get additional information from team
member for anything that looks unusual. They bring this all to the project manager for
final analysis and evaluation. The bottom line is that the additional staff perform much of
the logistics associated with the project plan, but it is still the responsibility of the project
manager to understand what is going on, and make the appropriate decisions to
complete the project successfully
• Proceed with Caution if Managing by Percent Complete
Most project management tools have an available field for entering the percentage
complete for each activity. Before an activity starts, it is 0% complete. When it is finished,
it is 100% complete. However, in between can be tricky. On the surface, if an activity is
estimated at 40 hours, and a team member had worked on it for 20 hours, you could say
they are 50% complete. But are they? They may be close to done, or they may be only
_____________________________________________________________________
_______________________________________________________________________________________________
10% done. The Project Manager could ask team members to report on their percent
complete, but in many cases you fall into the 99% complete syndrome. This occurs when
an activity is 90% done one week, the next week it is 95% done, the next week 99%
done, etc.
A better way to get the information you need is to ask 'When will the work be done?’ So,
if the schedule shows an activity to be completed on Friday, and the work is not done,
don't ask what percentage complete they are. Instead ask the team member 'When will
the work be done?’ Asking when the work will be completed gives you concrete
information you can place on your project plan, while also getting the team member to
make another commitment to the end date.
• Managing by Due Date

In many organizations, project estimates are based on costs, effort hours and duration.
However, when the project starts they do not collect the actual effort hours worked on
each activity. Unless tracking effort hours is important to your organization, the Project
Manager should feel comfortable to manage the project schedule based on completion
dates. In other words, assume you have an activity that is scheduled to take 40 hours
and have a two week duration. If the work is done within the two weeks, it is not as
important to know if the work actually took 35 hours or 50. It would only be important if
the difference in effort hours caused another activity due date to be missed. The effort
hours are important in the estimating process since they help set completion dates and
help balance workloads. But when the activities are assigned, getting the work done on
time is most important.
There is one important exception. If the work is being done by a resource that you are
compensating on an hourly basis, it is important to manage by effort hours and
completion date. Now it does matter whether the 40 hour activity actually took 50 hours,
since there is an incremental cost to your project.
• Managing by Milestones
A milestone is a scheduling event that signifies the completion of a major deliverable or a
set of related deliverables.
_____________________________________________________________________
_______________________________________________________________________________________________
A milestone, by definition, has duration of zero and no effort. Milestones are great for
Project Managers because they provide an opportunity to validate where the project is
and what the future looks like. In particular, you can do the following activities:
• Update the project plan and validate where you are trending in terms of overall
project budget and deadline.
• Validate that work done up to this point is correct and accurate. The customer
should have approved any external deliverables produced up to this point.
• Make sure that the rest of the project lan includes all the activities necessary to
complete the project.
• Double-check the effort, duration and cost estimates for the remaining work.
Based on prior work completed to-date, you may have a much better feel for
whether the remaining estimates are accurate. If they are not, you will need to
modify the project plan. If it appears that your budget or deadline will not be met,
raise an issue and resolve the problems now.
• Issue formal communication and status, per the communication plan.
• Evaluate the Risk Plan for previously identified risks, and perform a new risk
assessment to identify new risks.
• Update all other project management logs and reports.
These activities should be done on a regular basis, but a milestone date is a good time
to catch up, validate where you are at, get clear on what's next and get prepared to
charge ahead.
• The Project Audit

Sometimes the Project Manager can get too comfortable (or too uncomfortable) in how
the project is progressing. In many cases, it makes sense to have an outside party come
in to evaluate the project management processes being employed and provide a double-
check to make sure the project is progressing as expected. . The Project Manager or
functional manager might call for a project audit as part of an overall quality
management program. In some cases, such as a government project, periodic audits
may be called for as a part of the overall contract. In any event, an outside audit should
provide comfort to the project stakeholders that effective project management processes
are being utilized.
_____________________________________________________________________
_______________________________________________________________________________________________
• When 'Completed' Activities Are Not Really Completed

Sometimes a team member says that an activity is complete - when in reality it is not
quite. This can happen if the activity should have been completed yesterday, and the
team member believes they are just an hour away from completing it. They might rather
say it is complete and then finish it up, rather than deal with the consequences of it being
late. Usually this is not a big deal. Sometimes, however, activities start to slip because
the team member did not start it on time - because they were finishing up a prior
'completed' activity. Sometimes this can also be caused by deliverables that are
completed but not approved. The team member may say the work is complete, but when
the deliverable is checked it is discovered it is incomplete or needs additional follow-up
work. To avoid this, make sure that there is an approval process for all major
deliverables, and that the project plan leaves time for the approval process and for
rework based on feedback. Then there is no question that the deliverable is completed,
because it has either been approved or it hasn't. If an activity does not call for the
completion of a deliverable, you would expect that if a team member says an activity is
completed, that it probably is. If you find a pattern of this not being the case, then the
individual team member might need coaching on how to better report the status of their
work.
• Action Items
This is probably as good a place as any to discuss action items. After all, action items
are nothing more than work that need to be done to complete an activity, answer an
outstanding question, etc. One technique to ensure that action items are completed is to
place them in the project plan. For further information, click over to
An action item is work that requires follow-up execution. By their nature, action items
normally cannot be planned for in advance. They arise on an ad-hoc basis during
meetings or as a by-product of working on something else. An action item is assigned
because there is not enough knowledge, expertise or time to resolve the item at the time.
In many cases, action items are administrative in nature, but in other cases they can
require substantial work to complete. They are not significant enough to require
alterations to the Project Definition, however they need to be followed up on and
completed. (If they are not going to be completed, they should not be called action items.
Instead, simply note that the item will not be followed up on.) Examples of action items
_____________________________________________________________________
_______________________________________________________________________________________________
include forwarding specific information to someone, arranging a meeting and providing a

quick estimate on a piece of work, etc.
Sometimes as action item is established to investigate an area where there may be a

potential problem. Because of this, action items are sometimes mixed in with issues.
However, this is not right. An action item should not be confused with an issue. An issue
is a problem that will have a detrimental impact on the project if left unresolved. An
action item may lead to the discovery of an issue or a risk (a potential issue in the
future), but the action item itself is not an issue.
There are two common approaches used to manage action items. The best approach is
to document the items as activities on the project project plan. A resource and end date
is assigned as well, and the activity is then managed and tracked as normal. In general,
this is the better approach to follow, because it keeps the work items in one place, and
allows the Project Manager to enforce the discipline of 'if it's not on the project plan, it will
not be worked on.'
However, another popular approach is to track and manage action items on a separate
Action Item Log. If you use this approach, action items can be identified, documented,
assigned and resolved using the following process:
1. Action items may be identified by anyone on the project team. They often arise
out of interactions between and among project team members, particularly at
status meetings.
2. The Project Manager or a designated person enters the action item in the Action
Item Log. This records its existence to ensure that it receives attention and is
carried out.
3. The Project Manager or designated person assigns the action item to a team
member, who assumes responsibility for the action item and takes the necessary
steps to complete it. A quick estimate of effort should be agreed to and added to
the log.
4. A date for the completion of each action item should be entered in the log.
5. If completing an action item involves more work than anticipated, it should be
brought to the attention of the Project Manager.
_____________________________________________________________________
_______________________________________________________________________________________________
6. The Action Item Log should be reviewed at regular intervals during project team
meetings to ensure that action items have been completed successfully.
Action items are normally time sensitive. If an action item has not been completed in a
reasonable timeframe, it should be eliminated.
The Project Manager (or designated person) must follow-up to ensure that action items
are closed. In general, if they are not assigned to a specific person, have no target date
or are not followed-up, there is a good likelihood that the action item will not be
completed. If they are not going to be completed, there is no
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.3.5 Project management team Building
This section assists the project manager to:
Identify and recruit a strongly committed Project team
Write Project objectives
Manage a Project team

Formulate an agenda for a successful kick-off team meeting
• Introduction
It is hard to imagine a Project being completed successfully without teamwork.

The combined talents of specialists in many different disciplines are required to
develop most products, or provide most services, whether developing a new
banking service, or building a house. Not everyone is eager to work in teams, even
for a particular Project. Many feel group efforts only lead to disaster. However,
this need not be so. The problem is often not that teams are unsound but that
they are often poorly managed.
Different people have different needs. You must understand each person’s
character, needs, expectations and problems to manage them accordingly.
Teams don’t just happen, they are built!
A group of people does not necessarily make a team. Teams have characteristics
different from those of groups. Teams must have:
Shared goals
Interdependence
Commitment
Accountability for the outcome
A way of working together so that the group produces more than the sum of the
individuals working separately.
_____________________________________________________________________
_______________________________________________________________________________________________
A team is a group of people who are committed to the attainment of a common

objective, who work well together and enjoy doing so, and who produce high
quality results.
It is an inescapable fact of life that some people work well together while others don't. In
order to make sure that the project team operates at maximum efficiency, the project
manager will need to ensure that each of the project team members:
believes in the project goal
wants to be a part of the project team
have their own set of skills to contribute.
able to get on well with the other members.
is prepared to work towards achieving a common project goal.
Choosing the Right Team

Before nominating the different members of a future project team, the [project manager
should attempt to:
Select or build a team of people with compensating strengths and weaknesses.
Try to match the talent of each individual to his or her particular task.
To arrive at a good and effective team the project manager will need project team
members who:
¾ CREATE useful ideas (ideas person).
¾ ANALYSE problems effectively (resource investigator).
¾ GET things done (completer - finisher).
¾ COMMUNICATE well (chairperson).
¾ HAVE LEADERSHIP qualities (team builder).
¾ EVALUATE logically (monitor-evaluator).
¾ HAVE TECHNICAL abilities.
¾ CAN CONTROL work (company worker).
¾ WRITE and SPEAK well (shaper).
_____________________________________________________________________
_______________________________________________________________________________________________
When selecting a team, try to get a balance of the above "types" in one team. The
team will then be in a position to function effectively.
_____________________________________________________________________
_______________________________________________________________________________________________
Developing the Project Team

In order to manage teams successfully, the project manager must distance themselves
from the task in hand. No matter how appealing this task may be, or how well-qualified
the project manager is to deal with the task on hand. It is recommended that a low
profile be kept by the project manager if the team is to function effectively.
• The project manager should use a systematic approach, such

as the one below, to developing the project team.
Define the task before briefing your team.
Unless you have understood your objective thoroughly yourself, and worked out
the various steps in your plan of action, you are not going to be able to
communicate to others the details of what you expect to be done.
Clarify aims and success criteria.

Most people need definite goals to work towards, and, as a team, it is essential
that these goals are known to and shared by all concerned.
Any vagueness at this stage could lead to a misunderstanding of what is to be
achieved and drastically affect your chances of success.
Explore ways of achieving the aims.

There is usually more than one way of achieving an objective, and by
encouraging input from the members of your team you may well find yourself in
possession of several possibilities.
This will provide you with an opportunity of choosing the one best suited to your
purpose, together with a second plan to use as a "back-up" should the original
plan fail to work out.
Design an action plan.

This stage again allows the opportunity for team participation as you work out
ways and means of reaching your common goal.
_____________________________________________________________________
_______________________________________________________________________________________________
As noted above, it is advisable to have a second or "contingency" plan available

in the event of the first one proving unsatisfactory.
Monitor and evaluate the team's progress.

While it will probably be necessary, particularly in the early stages of their
working together as a team, to keep a watchful eye to ensure that everything is
going according to plan, care must be taken not to give the impression of
breathing down their necks, or even mistrusting them.
Too much control could have the negative effect of de-motivating the individuals
concerned.
Review the progress of the project with the team.

This should be done on a regular basis to make sure that all is going according to
plan. Regular meetings will also make it known that you are at all times interested
in their progress, and available to give advice should this be required.
All the members of the group should be involved in these reviews, both to unite
them as a team, as well as to make it easier for them to see for themselves how
their individual efforts contribute towards achieving the joint objective.
_____________________________________________________________________
_______________________________________________________________________________________________
Motivating the Team

If you wish to run a successful team, you should endeavour to co-ordinate the aims
of your staff with those of the company.
• This can be best achieved by:

reconciling the personal aspirations of the staff with the needs of the
organisation.
Your team could be motivated as follows:
Get to know the members of your team individually.

Apart from putting yourself in a position to avail yourself of their separate
skills and talents, you will be showing a personal interest in them as
individuals that cannot fail to have a positive effect.
Understand what interests and motivates individual

team members.
Just as they each have their own particular abilities, so every team member
will have his or own set of interests and goals.
By finding out what these are, you will be able to plan projects so that each
person will gain the maximum amount of job satisfaction.
Provide the team with increasingly more challenging

opportunities.
It is a temptation once a team is functioning efficiently to leave well alone and
not change the type of project it is given.
This strategy, however, could also have the negative effect of causing the
individuals to "go stale" on the job, resulting in demotivation and, in the long
term, possibly poor work performance.
_____________________________________________________________________
_______________________________________________________________________________________________
Analyse their strengths and their weaknesses.

It is only by making yourself fully aware of these different qualities in your
staff that you can devise strategies which will make the most of their
strengths and compensate for those areas in which they may be less
effective.
Coach and guide the team in those areas in which its

members are weak.
As noted above, you will first need to have analysed your team's weaknesses
before you can begin to rectify them.
For example, a possible weakness could be the regular completion of the
necessary paperwork. In this situation you could provide the required
guidance and instruction, or appoint one team member to ensure that this is
carried out on a regular basis.
Give immediate recognition for good job performance.

Although they are working in a team situation, each member of that team still
remains an individual with needs and desires that are particularly his or hers.
Recognition of effective job performance is therefore essential, both to ensure
that these needs are met, as well as to reassure the person concerned that
his personal efforts are noted and appreciated.
Ensure team members get the reward they deserve.

As noted above, people need to know that their efforts and achievements are
noticed and recognised.
If a certain reward has been promised, it should be given as soon as the
objective has been achieved, and not withheld in the hopes of encouraging
an even greater team effort.
_____________________________________________________________________
_______________________________________________________________________________________________
Delegate more of your own work to an effective team.

Apart from the obvious advantage of allowing you more time to get on with
those really vital tasks, this move will inspire a feeling of confidence amongst
your team members.
They will now possibly see themselves as having graduated to a level where
they can be trusted to perform a job that formerly only you, the manager,
could carry out effectively.
Involve the team in the decision making.

This is their right. They are the ones who are to carry out the plan, and it
therefore makes sense for them to have some say in drawing it up.
Being involved in this part of the strategy will not only give them a feeling of
being an integral part of the group, but could also produce some worthwhile
ideas regarding the project itself that might not have occurred to you at an
earlier stage.
Share information.
Even information that might at first glance seem irrelevant could later turn out
to have had a bearing on some facet of the job in hand. Possessing this
information might have led to a more effective work performance had the
person concerned been in possession of all the facts.
Help the team to resolve problems with other parts of

the organisation.
Your team could be a marketing one, dependant on the performance of the
production section in order to achieve certain goals.
In a situation where your team cannot meet its commitments because of the
failure of the factory to produce the goods as promised, it is your
responsibility to see that the problems are dealt with and resolved as quickly
and effectively as possible.
_____________________________________________________________________
_______________________________________________________________________________________________
Provide the right conditions for the team to work

effectively.
There are some things that the team cannot arrange for itself and these may
affect its eventual work performance.
For example, its members may be situated in different offices throughout the
building, with the result that valuable time is wasted in going from one office
to the other. You may well be in a position to overcome this difficulty, and
relocate at least some members of your team to a more convenient
workplace.
_____________________________________________________________________
_______________________________________________________________________________________________
Delegating work to teams.

There are three stages of delegating work to teams:
• Brief the Team.
Specify the essential parameters.

Everybody needs to know the boundaries within which he or she is expected
to operate, and it will probably save you valuable time later on if you make it
clear at an early stage exactly where these limits lie.
Explain the desired outcome.

Most of your team will probably be aware of this once they have heard your
plan, but it will nevertheless still be to your advantage to "spell it out" for them
at this stage of the proceedings.
By explaining to them exactly why these are the objectives, you will avoid any
later possibility of confusion or misunderstanding.
Get the team to explain its plan of action.

It may well be your plan that they are about to follow, but by having them
repeat it to you in detail, it will:
give you the opportunity to see whether they have grasped all its finer points.
check the plan objectively for any possible flaws or omissions.
Check that the team understands what is required.
In order to do this effectively, you may have to get the team members to
outline this requirement to you, both as a team as well as from their individual
standpoints.
As well as ensuring that everyone knows exactly what must be done, this
final check will allow you to verify once more whether all the essential points
have been covered.
_____________________________________________________________________
_______________________________________________________________________________________________
Sell, but do not oversell your own approach.
As noted above, you should ideally stand as far back as possible from the
project and allow your team to "go it alone" as much as they can.
At the same time you should make sure that the members of your team are
aware of your approach and preferences as far as the implementation of the
plan is concerned, and that they will take these into account when performing
their various tasks.
Be realistic about your expectations.
It is only natural that you should want your plan to achieve the maximum
result possible.
If your expectations are too high, however, your team may become
discouraged and demotivated by the knowledge that they are not going to be
able to achieve your objectives.
Indicate the need for progress reports.
Although you have probably decided that once your team knows what is
expected, you are going to allow its members to achieve your aims in their
own way, you have to be kept up to date with regard to the progress of the
project.
If your team knows it is responsible for preparing these progress reports, the
individuals can see to it that these documents are as comprehensive as
possible to provide you with all the information you are likely to need.
¾ Discuss the areas of the task that are sensitive to error or risk.
We know the old saying "forewarned is forearmed". If your team members

have been alerted to be on their guard in certain areas and at certain times
during the course of the project, and they understand why these warnings
have been given, they will then be in a position to take the necessary
precautions.
• Monitor the progress of the team.

Encourage the team to follow their plan of action.
_____________________________________________________________________
_______________________________________________________________________________________________
Once the plan has been discussed and approved, the team should be given
all possible encouragement, as well as the knowledge that assistance is
available if required to assist them in carrying it through.
Be alert for signs that things are starting to go wrong.
You are the person with the experience, and therefore best equipped to
notice and point out these minor problems before they have the chance to
become major ones.
Intervene only when the team does not spot errors.
You may have to bite your tongue on occasions, and give the team the
opportunity to rectify matters for itself, but the experience it can gain in such
situations will probably well justify your restraint!
You must, however, be ready to step in before matters get out of hand and a
disaster occurs.
Be ready to help but avoid doing the task yourself.
As long as the team knows you are available to provide advice and guidance
when needed, its members will probably appreciate being left to cope on their
own.
Doing the job yourself because you feel it will be done more quickly and
efficiently will destroy the team's sense of initiative and ability to think for
themselves.
¾ Encourage frequent informal discussion rather than formal feedback.
As well as inhibiting some team members who may be reluctant to voice their
opinions in a strictly conventional environment, a practice of formal feedback
only could lead to the suppressing of important information if the team
member feels that he or she should wait until the "right time" to pass it on.
• Evaluation and Feedback

Praise the team and give recognition to the people involved if the task was
successful.
We are all human enough to be anxious to know that our efforts are appreciated,
and your team will probably have worked hard to achieve your objective.
_____________________________________________________________________
_______________________________________________________________________________________________
A few additional words of encouragement and congratulation could make all the
difference to those persons who have put in that additional and vital amount of
extra effort.
Evaluate the reason why if the result was problematic, and work together with
your team to rectify the problem.
At the point it is of little use to anyone to hand out blame; in any event, the
chances are that the people who are at fault will be aware of this by now.
You will probably find it far more constructive to get together with your team to
determine the cause of the difficulty and to make plans to resolve it.
_____________________________________________________________________
_______________________________________________________________________________________________
Skills for managing a Project team
Addressing a group.
Emphasize that you want group members to work together as a team.

Discuss the definition of a team with them. Promote involvement from the
very beginning.
Ask group members to share ideas, suggestions, and experiences that they
think will help this group work as a team. Get them to write up a list of
things they think will undermine teamwork. Ask members who have
participated in team activities to help generate a model for how this team
might function. Make a list of things that come out of the discussion.
State the team goal, and explain why it is important. Don’t underestimate
the importance of this step! Project managers sometimes feel it is not
necessary since “they all know how important this Project is.”
Most important, convince group members that they can gain from
participation in the Project. It is important for them to “sell” ideas to their
colleagues on the basis of how it can benefit the organisation, clearly
emphasizing the advantages for themselves, which may not be obvious.
_____________________________________________________________________
_______________________________________________________________________________________________
How to give feedback

Be Constructive. The information given should assist the other person to
become more effective. It should show concern for them as a person.
Don’t label them.
Be Specific. Support with examples to illustrate the behaviour. Focus on

what, when, where, and how – not why, or we are getting into motives.
Be Positive. Put emphasis on how performance could be improved with a

changed behaviour. Give examples.
Be Sparing. Don’t dump so much negative feedback on them that they don’t
know which way to turn.
Include Feelings. Feedback on how you felt as a result of the behaviour

gives a fuller picture of the impact it had.
Don’t be Personal. Address what they did, not who they are.
Observations, not Assumptions. Only describe what you actually saw or

heard.
No Judgements. Do not label things as “good” or “bad”, only “more effective”

or “less effective”.
Don’t Overstate. Cite specific examples – don’t use words like “always” or
“never”.
Do not give advice. The person should feel enlightened not incapable. Let
them come up with the best way to use the information.
Focus on Performance Improvement. Before saying anything ask yourself if

the feedback will be helpful in getting the other person to be more effective.
Don’t try and get them to be a clone of you. Every person is unique.
_____________________________________________________________________
_______________________________________________________________________________________________
How to receive feedback

Listen. Empathetic listening does not necessarily mean that you agree with
the other person’s message, simply that you understand it.
Be Willing to Learn. You are going to be the richer for this exercise. Make the
most of it.
Be Objective. This means being non-defensive, and unemotional. As soon

as you feel a “Yes, but . . .” coming into your mind, you are being defensive,
and you are no longer listening to the feedback.
Their Perceptions are Their Reality. Learn whatever you can from the
interchange. You will also learn a lot about the person giving the feedback.
Ask only for Clarity. Do not question, challenge, dispute or justify. You may
only ask for clarity, examples, and elaboration.
_____________________________________________________________________
_______________________________________________________________________________________________
TEAM BUILDING
• Introduction
It is an inescapable fact of life that some people work well together while others don't. In
order to make sure that your team operates at maximum efficiency, you will have to
make sure that each of your individuals:
o has his own set of skills to contribute.

o is able to get on well with the other members.
o is prepared to work towards achieving a common goal.
• Choosing The Right Team
Before nominating the different members of your future team, you should attempt to:
Select or build a team of people with compensating strengths and weaknesses.
Try to match the talent of each individual to his or her particular task.
_____________________________________________________________________
_______________________________________________________________________________________________
To arrive at a good and effective team you will need people who:
• CREATE useful ideas (ideas person).

• ANALYSE problems effectively (resource investigator).
• GET things done (completer - finisher).
• COMMUNICATE well (chairperson).
• HAVE LEADERSHIP qualities (team builder).
• EVALUATE logically (monitor-evaluator).
• HAVE TECHNICAL abilities.
• CAN CONTROL work (company worker).
• WRITE and SPEAK well (shaper).
When selecting a team, try to get a balance of the above "types" in one team. The team
will then be in a position to function effectively.
Developing the Team
In order to manage teams successfully, you must pull back yourself from the task in
hand.
No matter how appealing this task may be, or how well-qualified you are to deal with it
yourself, you will have to keep a low profile if the team is to function effectively
• A systematic approach will help you to develop your team.
• Define the task before briefing your team.
Unless you have understood your objective thoroughly yourself, and worked out the
various steps in your plan of action, you are not going to be able to communicate to
others the details of what you expect to be done.
_____________________________________________________________________
_______________________________________________________________________________________________
• Clarify aims and success criteria.
Most people need definite goals to work towards, and, as a team, it is essential that
these goals are known to and shared by all concerned.
Any vagueness at this stage could lead to a misunderstanding of what is to be achieved

and drastically affect your chances of success.
• Explore ways of achieving the aims.
There is usually more than one way of achieving an objective, and by encouraging input
from the members of your team you may well find yourself in possession of several
possibilities.
This will provide you with an opportunity of choosing the one best suited to your
purpose, together with a second plan to use as a "back-up" should the original plan fail
to work out.
• Design an action plan.
This stage again allows the opportunity for team participation as you work out ways and
means of reaching your common goal.
As noted above, it is advisable to have a second or "contingency" plan available in the

event of the first one proving unsatisfactory.
• Monitor and evaluate the team's progress.
While it will probably be necessary, particularly in the early stages of their working
together as a team, to keep a watchful eye to ensure that everything is going according
to plan, care must be taken not to give the impression of breathing down their necks, or
even mistrusting them.
_____________________________________________________________________
_______________________________________________________________________________________________
Too much control could have the negative effect of de-motivating the individuals
concerned.
• Review the progress of the project with the team.
This should be done on a regular basis to make sure that all is going according to plan.
Regular meetings will also make it known that you are at all times interested in their
progress, and available to give advice should this be required.
All the members of the group should be involved in these reviews, both to unite them as
a team, as well as to make it easier for them to see for themselves how their individual
efforts contribute towards achieving the joint objective.
• Motivating The Team
If you wish to run a successful team, you should endeavour to co-ordinate the aims of
your staff with those of the company.
• This can be best achieved by:
reconciling the personal aspirations of the staff with the needs of the organisation.
Your team could be motivated as follows:
• Get to know the members of your team individually.
Apart from putting yourself in a position to avail yourself of their separate skills and
talents, you will be showing a personal interest in them as individuals that cannot fail to
have a positive effect.
_____________________________________________________________________
_______________________________________________________________________________________________
• Understand what interests and motivates individual team

members.
Just as they each have their own particular abilities, so every team member will have his
or own set of interests and goals.
By finding out what these are, you will be able to plan projects so that each person will
gain the maximum amount of job satisfaction.
Provide the team with increasingly more challenging opportunities.
It is a temptation once a team is functioning efficiently to leave well alone and not
change the type of project it is given.
This strategy, however, could also have the negative effect of causing the individuals to
"go stale" on the job, resulting in demotivation and, in the long term, possibly poor work
performance.
• Analyse their strengths and their weaknesses.
It is only by making yourself fully aware of these different qualities in your staff that you
can devise strategies which will make the most of their strengths and compensate for
those areas in which they may be less effective.
• Coach and guide the team in those areas in which its

members are weak.
As noted above, you will first need to have analysed your team's weaknesses before you
can begin to rectify them.
For example, a possible weakness could be the regular completion of the necessary
paperwork. In this situation you could provide the required guidance and instruction, or
appoint one team member to ensure that this is carried out on a regular basis.
_____________________________________________________________________
_______________________________________________________________________________________________
• Give immediate recognition for good job performance.
Although they are working in a team situation, each member of that team still remains an
individual with needs and desires that are particularly his or hers.
Recognition of effective job performance is therefore essential, both to ensure that these
needs are met, as well as to reassure the person concerned that his personal efforts are
noted and appreciated.
• Ensure team members get the reward they deserve.
As noted above, people need to know that their efforts and achievements are noticed
and recognised.
If a certain reward has been promised, it should be given as soon as the objective has
been achieved, and not withheld in the hopes of encouraging an even greater team
effort.
• Delegate more of your own work to an effective team.
Apart from the obvious advantage of allowing you more time to get on with those really
vital tasks, this move will inspire a feeling of confidence amongst your team members.
They will now possibly see themselves as having graduated to a level where they can be
trusted to perform a job that formerly only you, the manager, could carry out effectively.
• Involve the team in the decision making.
This is their right. They are the ones who are to carry out the plan, and it therefore
makes sense for them to have some say in drawing it up.
_____________________________________________________________________
_______________________________________________________________________________________________
Being involved in this part of the strategy will not only give them a feeling of being an
integral part of the group, but could also produce some worthwhile ideas regarding the
project itself that might not have occurred to you at an earlier stage.
• Share information.
Even information that might at first glance seem irrelevant could later turn out to have
had a bearing on some facet of the job in hand. Possessing this information might have
led to a more effective work performance had the person concerned been in possession
of all the facts.
• Help the team to resolve problems with other parts of the

organisation.
Your team could be a marketing one, dependant on the performance of the production
section in order to achieve certain goals.
In a situation where your team cannot meet its commitments because of the failure of the
factory to produce the goods as promised, it is your responsibility to see that the
problems are dealt with and resolved as quickly and effectively as possible.
• Provide the right conditions for the team to work

effectively.
There are some things that the team cannot arrange for itself and these may affect its
eventual work performance.
For example, its members may be situated in different offices throughout the building,
with the result that valuable time is wasted in going from one office to the other. You
may well be in a position to overcome this difficulty, and relocate at least some members
of your team to a more convenient workplace.
_____________________________________________________________________
_______________________________________________________________________________________________
• Delegating work to teams.

o There are three stages of delegating work to teams:
Brief the Team.
Specify the essential parameters.
Everybody needs to know the boundaries within which he or she is
expected to operate, and it will probably save you valuable time
later on if you make it clear at an early stage exactly where these
limits lie.
Explain the desired outcome.
Most of your team will probably be aware of this once they have heard your plan, but it
will nevertheless still be to your advantage to "spell it out" for them at this stage of the
proceedings.
By explaining to them exactly why these are the objectives, you will avoid any later
possibility of confusion or misunderstanding.
Get the team to explain its plan of action.
It may well be your plan that they are about to follow, but by having them repeat it to you
in detail, it will:
give you the opportunity to see whether they have grasped all its finer points.
check the plan objectively for any possible flaws or omissions.
• Check that the team understands what is required.
In order to do this effectively, you may have to get the team members to outline this
requirement to you, both as a team as well as from their individual standpoints.
As well as ensuring that everyone knows exactly what must be done, this final check will
allow you to verify once more whether all the essential points have been covered.
Sell, but do not oversell your own approach.
_____________________________________________________________________
_______________________________________________________________________________________________
As noted above, you should ideally stand as far back as possible from the project and
allow your team to "go it alone" as much as they can.
At the same time you should make sure that the members of your team are aware of
your approach and preferences as far as the implementation of the plan is concerned,
and that they will take these into account when performing their various tasks.
• Be realistic about your expectations.
It is only natural that you should want your plan to achieve the maximum result possible.
If your expectations are too high, however, your team may become discouraged and
demotivated by the knowledge that they are not going to be able to achieve your
objectives.
• Indicate the need for progress reports.
Although you have probably decided that once your team knows what is expected, you
are going to allow its members to achieve your aims in their own way, you have to be
kept up to date with regard to the progress of the project.
If your team knows it is responsible for preparing these progress reports, the individuals
can see to it that these documents are as comprehensive as possible to provide you with
all the information you are likely to need.
• Discuss the areas of the task that are sensitive to error or

risk.
We know the old saying "forewarned is forearmed". If your team members have been
alerted to be on their guard in certain areas and at certain times during the course of the
project, and they understand why these warnings have been given, they will then be in a
position to take the necessary precautions.
_____________________________________________________________________
_______________________________________________________________________________________________
• Monitor the progress of the team.

o Encourage the team to follow their plan of action.
Once the plan has been discussed and approved, the team should be given all possible
encouragement, as well as the knowledge that assistance is available if required to
assist them in carrying it through.
o Be alert for signs that things are starting to go wrong.
You are the person with the experience, and therefore best equipped to notice and point
out these minor problems before they have the chance to become major ones.
o Intervene only when the team does not spot errors.
You may have to bite your tongue on occasions, and give the team the opportunity to
rectify matters for itself, but the experience it can gain in such situations will probably
well justify your restraint!
You must, however, be ready to step in before matters get out of hand and a disaster
occurs.
o Be ready to help but avoid doing the task yourself.
As long as the team knows you are available to provide advice and guidance when
needed, its members will probably appreciate being left to cope on their own.
Doing the job yourself because you feel it will be done more quickly and efficiently will
destroy the team's sense of initiative and ability to think for themselves.
o Encourage frequent informal discussion rather than

formal feedback.
As well as inhibiting some team members who may be reluctant to voice their opinions in
a strictly conventional environment, a practice of formal feedback only could lead to the
_____________________________________________________________________
_______________________________________________________________________________________________
suppressing of important information if the team member feels that he or she should wait
until the "right time" to pass it on.
o Evaluation and Feedback
Praise the team and give recognition to the people involved if the task was successful.
We are all human enough to be anxious to know that our efforts are appreciated, and
your team will probably have worked hard to achieve your objective.
A few additional words of encouragement and congratulation could make all the
difference to those persons who have put in that additional and vital amount of extra
effort.
Evaluate the reason why if the result was problematic, and work together with your team
to rectify the problem.
At the point it is of little use to anyone to hand out blame; in any event, the chances are
that the people who are at fault will be aware of this by now.
You will probably find it far more constructive to get together with your team to determine
the cause of the difficulty and to make plans to resolve it.
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.4 The Commission phase

The purpose of this section is to close the project off, hand it over to the client and
evaluate the project performance. During this phase the start-up and testing of the
product is done. The key consideration here is to establish if the project objectives have
been met according to the agreed upon scope. The as-built drawing and operations
manuals are now compiled to assist with the operations of this completed project.
When trying to understand why Projects fail, it is important to look at what caused
the failure, rather than what the failure itself actually was. There are lessons to be
learnt from failure, if only we are willing to find and examine them. Research has
shown that companies spend thousands of hours planning and implementing
projects, but far too little time critically evaluating and learning from their
experiences. The project manager should ask some vital questions, such as:
• Did we get what we expected to get?

• Was the investment worthwhile?
• Did it go according to plan?
• If yes, how? If not, why not?
• What can we learn from the experience to do things more effectively
• What could we have done better this time?
• What could we have not done?
• What can we do the next time?
_____________________________________________________________________
_______________________________________________________________________________________________
The following could be typical factors that may cause

projects to fail. These include:
• Work Begins Without A Plan or Stated Objectives: Many

project teams are so eager to get on with the Project, that they forget to spend
time up front clearly defining the business case or ‘why’ the project is being
implemented. This creates uncertainty of what is expected from the team, and
they may even lose motivation for the project.
• Due Dates and Milestones Are Missed Or Deadlines Slip:

Teams are motivated by achievement, and not only will the project not be
completed on time, but the motivation of team members can also be negatively
affected as they feel they are not achieving. This can also lead to increased
workload and pressure.
• Trust Within the Organization or Team is broken: This could

lead to a fragmented project team, pulling in different directions, not meeting
set objectives.
• Control is not maintained: The project manager should maintain

control of the cost, time and quality throughout the Project, not only when the
milestones are expected to be completed. By this stage it is too late to
implement corrective action.
• No Defined Customer: When the customer has not been defined, the
project lacks a business case, clarity and possibly priority. When this type of
Project shows signs of failure, other operations will suddenly be ‘priority’ for
team members.
• Resources not available when required: Poor planning can lead

to setbacks in achieving project milestones. If the resources have not been
suitably managed, projects are set for failure.
• Authority and Responsibility Not Clear: All team members

should be clearly informed as to their authority and responsibility.
_____________________________________________________________________
_______________________________________________________________________________________________
• All team members need to know who should be informed, at what level, and
how often. A responsibility chart will aid the communication of authority and
responsibility.
9.3.4.1 Completion and Handover

The desired end result of a project is successful hand-over to a satisfied client. The
client needs to be satisfied that the quality specifications of the project have been met.
The value of setting up the initial documentation specifying the standards and criteria will
now come into its own. Of course, the monitoring and control process does allow for
specifications to change as the Project progresses, and it is important that these
changes are recorded, approved and the documentation amended appropriately. The
delivered product will be measured against the specifications laid down in the project
management charter and scope documents.
• The delivery usually includes the following:

o The actual product produced.
o Transition of responsibility and ownership of the project deliverables to the
client.
o Completion of any warranty documentation.
o Final audit and reconciliation of the project against the original project charter
and scope.
o Financial finalization in terms of reports, payments, etc. between the project
team and the client, and also between project team and any suppliers and
contractors.
o Project evaluation: what worked, what didn’t work, what learning is there to
be passed on - this information needs to be documented and shared with
other Project teams
o Any training of client or client staff should be scheduled and take place,
including operating manuals as necessary
o Re-assignment or return of team members, resources, facilities, etc.
o Celebration of success
o Summarise recommendations for future projects
_____________________________________________________________________
_______________________________________________________________________________________________
o Conduct review with senior management/stakeholders and submit final

reports
o The definition of a project included the critical criterion of being a discrete unit
of work with a specific beginning and ending point. The Project must be
completed in order to meet the definition. Projects that do not have a definite
sign-off simply drag on and on, never quite finished. This could be
dissatisfying and de-motivating for client and the project team alike, and does
not allow for re-deployment of valuable resources. This limits the learning and
prevents the project from being moved into the next phase. It is perfectly in
order for a new “project maintenance plan” to be drawn up to take the
completed project to the next level.
9.3.4.1 A Practical Guideline for Commissioning and Close-off

In terms of closing the project off, all contractual and tender requirements will have had
to be met in order to satisfy the client that the project is complete. Hand-over may then
occur, with the release of the completed product and any necessary documentation to
the client. Further involvement of the organisation responsible for doing the project
should only occur for maintenance or if additional work or the client requests support.
This may occur during the project itself, when the client notes the need for a variation to
the initial product. This must be done through a formal ‘scope change request’ and have
an impact study done on the initial project scope. This will be what is eventually closed
out.
In addition to closing the project off, evaluation of performance during the project is
essential. Only by examining the project and comparing it to historical data and to the
initial planned objectives can we see if the project has progressed as planned. If the
project has not been successful then recommendations for future projects should be
made; similarly if the project has been superior in performance to previous projects then
recommendations should be made on how to repeat the performance achieved in the
project.
_____________________________________________________________________
_______________________________________________________________________________________________
• Check Points When Handing-Over the Project:

o Check that all tender objectives have been achieved – use the project
objectives list to formulate a list of tender objectives to use as a checklist.
o Check that in addition to the project goals that all the contractual
requirements are met e.g. that the items are delivered to the right places and
signed off using the agreed method for verification purposes.
o Ensure that all payments have been met and payments on outstanding
amounts are organized.
o Obtain a letter of acceptance from the client
o Project Evaluation should include the following points:
o Obtain historical data from previous projects for use in comparisons.
o How accurate was the PERT analysis?
o Comparison of Planned Gantt chart Vs the actual Gantt chart.
o Comparison of Budgeted Costs Vs Actual Costs.
o Comparison of Resource Allocation to Resource Usage.
o What mistakes were made, how were they handled, how were they corrected
and how can they be avoided in future projects?
o What went better than expected, why and how may it be repeated?
o Evaluation of control and management functions.
o What new methods were used, which worked and how can they be used in
future projects?
o Evaluation of staff on the project should occur, how well did each perform Vs
what was expected of them? Were there skill levels sufficient, under skilled or
over skilled for the job at hand?
o Client Satisfaction should be measured.
o Generate a project close out report.
_____________________________________________________________________
_______________________________________________________________________________________________
9.3.4.2 Forms to Complete For Commissioning and Close-Off
Once all tender and contractual agreements have been met and all issues related to
them finalised, the project is ready to be handed over to the client. In order to officially
hand the project over to the client a letter of acceptance, from the client, should be
handed over.
The letter of acceptance is a document, which indicates a client’s acknowledgement of

receipt of the finished product and their satisfaction with the finished result. The letter of
acceptance confirms that all contractual requirements have been met. For this reason,
the letter of acceptance should be asked for when the conditions of the original contract
have been fulfilled. Later additions and changes to the contract should not prevent
project hand over at this point as the work you were contracted for has now been
completed.
In order to avoid a conflict with the client, it should be explicit in the original contract at
which point a letter of acceptance will be issued. In some cases a client may be reluctant
to hand out a letter of acceptance for the product if there are outstanding items which
prevent him from utilising the project in the manner he wishes to do so. By explicitly
stating in the original contract when a letter of acceptance is due, the client cannot
refuse due to changes to the contract agreed to by himself, unless it is agreed by both
parties that a particular change to the contract is, mandatory in order to complete the
contract.
Thus a project may have more than one letter of acceptance, one when the original
contract is completed, and further letters of acceptance as variances and additions to the
contract are completed.
Once the project is complete, it is important to evaluate how well we did during the
project and from the project. Thus it is important to go back to the tools used for project
evaluation and to analyse them to find our weak points and strong points. It is important
to find weak points in order that we can correct these before starting on other projects,
but it is just as important to highlight our strong points in order to ensure that these are
repeated in the next project.
_____________________________________________________________________
_______________________________________________________________________________________________
In the sections below, different areas of the project evaluation will be examined. Some
of these are dependent on information gathered in the planning stage, thus highlighting
the need for good planning methodologies which provide a structure ensuring all
necessary steps are carried out.
The first step in evaluating the project is to obtain historical data from previous projects
to use in evaluating how we performed in this one. If we neglect to obtain historical data
then we can only compare the project to itself and can thus only evaluate performance
based on what happened during the project itself.
The historical data is usually obtained from prior projects, but care must be taken that
the data used is relevant and not so outdated as to be irrelevant. The scope and
specifics of each task will most likely be different; methods may have changed due to
automation or legislation restricting certain types of labour.
Even though the projects may not have been identical, there are usually similarities.
Problems, which occurred previously, may occur again if no preventative action has
been taken in the mean time. Looking at what went right and wrong, together with their
recommendations may be informative, to see which, if any of these have been
incorporated into your own project.
If many of the same problems have occurred, and if the recommendations for getting
things to go right have been ignored, one must try and find out what the reason for not
incorporating these lessons are. Obtaining and storing information is useless if the
recommendations and lessons, to be learnt from previous experience are ignored.
The final document of the project should be the Project Close Out Report. The purpose
of this report is to summarise the above analysis for future needs. The report should
evaluate the performance of the project VS the project objectives and should make
recommendations for future projects.
The report should evaluate against the overall objectives of the project, and should not
look at specific tasks used in achieving those objectives. Thus the main points of the
project should be highlighted and examined to evaluate how well they were achieved.
Criteria such as budget, time taken and resource utilisation would be examined for each
objective, comparing these to the estimates.
_____________________________________________________________________
_______________________________________________________________________________________________
An extremely important area to examine here, would be the final result VS the objective,
does the delivered product meet the specified needs of the customer? Even if the project
is late and over budget, the final product should at least meet the objectives laid out for it
at the start. Unavoidable delays and errors may have occurred. But, if a good product
has been delivered then one may be able to still call the project a success.
The second part of the close out report should contain recommendations for future
projects. These can be distilled down from the above evaluation, especially the final
ones, which examined the overall project. If the above analysis has been done, this
should just involve including the points from work done previously.
_____________________________________________________________________
_______________________________________________________________________________________________
Form: 1 Tender Objective checklist

At the close of the project, one should check that all the objectives of the tender have
been met. This is important for two main reasons:
¾ The customer’s expectations of the project are based on the tender and thus their
perception of your company and your project is based on how well you fulfilled your
objectives and
¾ The tender is a legal document and specifies what needs to be done in order to fulfill
the contract.
Looking at the first of the two reasons we can understand how important to us it is to fulfil
the tender objectives, for our own sakes and not just to fulfil the legal requirements.
Future work from that client will be based on how well we performed during this project.
Thus an incomplete project which is handed over to the client may cause us a loss of
income in lost business from them, as well as negative word of mouth which may well
reach the ears of other potential clients.
The handing over of an incomplete project may also result in legal problems as the client
attempts to recoup any losses suffered. In addition, any penalties listed in the contract
may become active resulting in further financial loss. The loss of a legal case also results
in a permanent public record of your company’s error.
For this reason, in addition to fulfilling the listed tender objectives, any variations or
additions to these objectives should be recorded and signed off by the client to prevent a
retraction by the client at a later date. Also, the person who signs the variation,
cancellation or addition of a tender objective should have the required authorization,
preferably having these people or positions detailed in the initial contract.
An important element of variations, cancellations and additions to objectives to

remember is that these fall outside of the initial contract. The contract may be written
with a clause to cover how these are handled, but those which are enhancements to the
system and do not prevent the system from going live, should not prevent the project
from being closed off at that point. The additional elements, which have been added to
the project since the original tender/contract should then be completed as a separate
entity and should not count towards the budget and costing of the original objectives.
_____________________________________________________________________
_______________________________________________________________________________________________
The form below provides a means of recording the objective and when it was completed.
A place is also provided next to each item for the client to sign to show that the objective
has been met to their satisfaction.
Objective Objective Date Signed By Signature

Number Completed
_____________________________________________________________________
_______________________________________________________________________________________________
Form 2: Variations to Tender Objective

A further form is provided for the recording of variations or cancellations of tender
objectives. The objective number should correspond to the objective number on the
previous form. Details of the variation should be recorded with the date completed. The
responsible person from the client should sign next to the variation in the authorisation
column with the date authorised next to it. The variation itself should also then be signed
off by the client to show their satisfaction with it.
Objective Variation Date Authorised Sign Completed: Completed:

Number Authorised By atur Signed by Signature
e
_____________________________________________________________________
_______________________________________________________________________________________________
Form 3: Contractual Conditions Checklist

Similar to the requirement to check that all the tender objectives have been met, is the
requirement that all contractual requirements have been met. Whilst looking at the
tender objectives, it may appear that the project is completed, there may still be
contractual requirements to be met.
These extra contractual requirements may be items such as acceptance testing by the
using, obtaining some outside qualitative measure on the work done, delivering the
items to various locations other then the primary one, etc. Until all of these conditions are
met, the project is not yet complete.
The best way to ensure that all contractual requirements have been met is to list these
on a checklist and mark them off as they are completed. In this manner it becomes easy
to check on what still needs to be completed.
The form below provides a means to do this. Space is provided for the condition, date
completed and customer signature if necessary.
Condition Condition Completed Signed By Signature
_____________________________________________________________________
_______________________________________________________________________________________________
Form 4: Variations to Contractual Conditions

Also, in a similar manner to the tender objectives, variations to the contract should be
carefully monitored and recorded to prevent any problems with the client at Project Close
off. Usually, contractual variations will have a supporting document which both parties
will have signed to satisfy the legal requirements necessary to modify a written contract.
Not withstanding these documents a checklist of these variations to the original contract
should be kept and treated as in the contractual item checklist.
Condition Variation Completed Signed By Signature

Number Y/N?
_____________________________________________________________________
_______________________________________________________________________________________________
Form 5: Checklist of Payments

An important area of the project to keep track of is that of payments. The importance of
the control of cash flows does not end as the project ends. The customer may still owe
you money, and you may still owe sub contractors and suppliers money. As the project is
being closed off and commissioned it should be checked that all necessary payments
have been made to date and that plans have been made for future payments.
If the client has had a history throughout the project of not meeting progress payments
or if large amounts are delinquent, you may wish to postpone project close off until these
amounts are settled. If possible and if it is necessary withholding of the final parts of the
project may be necessary in order to obtain amounts owing from the client. If withholding
the final portion of the project is not possible due to the nature of the project other
remedies may be necessary. Where possible, the exact course these remedies will take
should be incorporated into the contract, making it easy to enforce through the legal
system.
To keep track of payments is generally an easier task than that of contractual conditions
and tender objectives, as these are all entered into the accounting system of your
company? However, a checklist of when payments were due, and if they have been
made is useful to check on the progress of payments of the client. The form below
records when the payment was due, how much it was for, if it was paid and the reason
for no payment (if necessary).
Payment Due Date Amount Paid? Reason for Non-Payment
_____________________________________________________________________
_______________________________________________________________________________________________
Form 6: Network Comparison Chart
At the start of the project a network chart needs to be drawn up. This is a precedence
network that shows the flow of activities, their precedence and time to complete. The
network chart is used in planning resource allocation as well as in the drawing up of the
Gantt chart.
The main usage of reviewing the network chart at this point will be to show how well the
project was understood during the planning phase, and how well the planning of
activities was done. If the project was well understood, then the network chart will show
an accurate reflection of the activities during the project and how they related to each
other. A poorly formulated network chart will have shown activities inaccurately, the
relationships between the activities will not be correct, thus the other areas of the project
plan which were dependent on the network for planning will be badly formulated. If an
accurate Gantt was kept during the project, and extra activities added to the Gantt chart
then the network analysis is not necessary as the Gantt analysis will provide the same
information, which may well be more accurate. The network analysis is necessary if the
interrelationship between activities is important, as the Gantt chart does not reflect these
well.
To see how accurate the network chart was it is necessary to redraw the network chart
using actual data as opposed to the forecast data of the first network. Extra activities
may need to be added in or activities may need to be removed. The addition and
removal of activities will be necessitated by the variation in planning stages as compared
with the actual project. An example of this may be due to changing requirements from
the client or a change in regulations in the industry or legal environment. Additionally, a
necessary step may have been neglected or a redundant step added to the project.
The next step in drawing the post project network will be to insert the actual duration of
the activities, the start day and the end day. These may well vary from the planned
network, as resource allocation may have caused variations in the scheduling of
activities.
_____________________________________________________________________
_______________________________________________________________________________________________
After this one should then compare the two network, listing differences in the two sets of
activities, whether the difference was foreseen due to resource allocation problems and
was thus varied before the project started, what caused other problems, and whether the
precedence allocation of the activities was correct.
Also, the critical path may be re-examined to ascertain if the same activities remained on
the critical path, and how these affected the project.
Once the differences in the two network charts have been noted and analysed, as
above, it is necessary to further analyse them. Where activities varied from the expected,
it should be ascertained why this occurred. Not only worse performance should be
analysed, but also where performance was better than expected should be analysed.
The purpose behind analysing these differences is to find a reason and a manner in
which to either avoid the problems experienced or to be able to repeat good
performances.
In the form below place is given for the each activity in the network chart. Following that
are the planned and actual successors and predecessors and the planned and actual
duration, with a space to fill in the reason for the variation if it is possible to do so. This
can then be used when next planning a project by providing a quick summary sheet for
referencing.
Activity
Description
Activity
Predecessors
Planned
Predecessors
Actual
Successors
Planned
Successors
Actual
Duration
Planned
Actual Duration
Variations.
Reason
Possible
for
_____________________________________________________________________
_______________________________________________________________________________________________
Form 7: Gantt Chart Comparison
COMPARISON OF PLANNED GANNT CHART VS THE ACTUAL

GANTT CHART.
As with the network chart, at the time the project was initially being considered and
planned, a Gantt chart should have been drawn up. The Gantt chart is a bar chart that is
used for project planning and control. During the project it is also used to track activity
progress.
At the end of the project, the Gantt chart should have two bars, one being the scheduled
(baseline) values and the other being the actual values. The Gantt chart thus provides a
much easier and quicker route to evaluate planned Vs actual duration of activities than
the network chart does. If the Gantt chart is accurate then the analysis of activities can
be done from there, and the post project network evaluation done above can be
restricted to those activities that were not initially planned and thus do not appear on the
Gantt chart. If the Gantt chart has had extra activities added to it, and redundant
activities noted as such, it can provide all the information that the post project network
does and thus alleviates the need for redrawing the network chart and recalculating
values on the network chart.
Unlike the network, the Gantt is usually redrawn once final resource allocation has been
decided, and thus may provide a more accurate picture of activities than the network
chart. If the Gantt was redrawn after resource allocation, any variations on the Gantt
between planned and actual values will be as a result of project conditions.
As the Gantt is a visual tool, it is easy to pick out those activities, which have varied from
the planned basis. Delays to starts, early starts and changes in duration are very easy to
note as the two bars for the activity will not be identical.
Examining the activities with variations will allow one to note how well activities were
performed and planned. If there are only a few variations then performance has been as
expected, planning was done accurately and the project has proceeded as planned. If
there have been many variations then things have not been as expected. The project
should be examined to see if many activities have been added to the Gantt.
_____________________________________________________________________
_______________________________________________________________________________________________
If there have been many new activities, then it is likely that there was a problem with the
initial planning. Why were these activities not expected at the project planning stage?
Are these activities that should have been foreseen but were not, or are these extra
activities that resulted from a change to project objectives after the project had started?
The first case may be indicative of a lack of knowledge regarding the processes
necessary to complete the project on the part of the planner, laziness in drawing up the
project plan or insufficient knowledge about the planning process resulting in a flawed
planning process. The second case may indicate that the initial scope of the project was
insufficient, due to the problem not being thoroughly researched or understood. It may
also be due to the customer changing the requirements of the project due to changing
business needs and environment.
How would one solve these problems? Extra training and incentives may help alleviate
some of the above problems, but it may be out of your hands if there was no possible
way to foresee the variations at the time the project was planned. A customer whose
needs change during the course of the project may be frustrating but cannot be
foreseen.
In addition to being able to see extra activities, it is also easy to spot variations to
planned activities. In looking at these variations it is very important to note good
performance as well as bad. Activities which were performed faster, were able to start
earlier and thus shorten the project are important to note. How did these activity
variations occur? Is there some way that this behaviour can be incorporated into other
projects and other activities to improve performance? If so, this should be noted and
utilised when possible.
If performance was bad, if activities took longer than expected or started late and held
up project completion, these activities should be closely examined. Why did the problem
occur? Was the difficulty of the task underestimated, resulting in it taking longer than
expected, were more resources such as time or manpower needed than were expected
or available, was there some delay in starting the activity that had not been foreseen and
may have been prevented or foreseen? These questions are some of the few that may
help in understanding the problem.
_____________________________________________________________________
_______________________________________________________________________________________________
A useful technique for finding the reason for a problem is to continuously ask the
question WHY? Until a base reason is arrived at. This works as follows:
PROBLEM: The activity started late.

Q Why did the activity start late?
A The supplies to start the activity were unavailable.
Q Why were the supplies unavailable?
A They hadn’t been ordered.
Q Why had the supplies not been ordered?
A The store man was on leave and his replacement did not know to order the supplies.
Q Why, did the replacement not know about the need to order the supplies?
A He was only put onto the job after the store man had left and no information was left
for him. At the end, we can see that it was a lack of communication between the store
man and a replacement that led to the problem. Therefore that is the problem that needs
to be corrected to prevent a similar incident in the future.
Activity
Description
Activity
Predecessors
Planned
Predecessors
Actual
Successors
Planned
Successors
Actual
Duration
Planned
Duration
Actual
Variations.
Reason
Possible
for
Activity Activity Variatio Reason for Possible
Description n Variation Change
_____________________________________________________________________
_______________________________________________________________________________________________
Form 8: Resource usage/allocation comparison chart
This area of evaluation looks at how well we allocated resources to various tasks. In
order that this may be done it is necessary to estimate at the start of the project how
much of each resource will be necessary during the project. The units will be different
depending on the type of resource being used, for people it may be man hours, while for
raw materials it may be in Kilograms or tons.
The reason for needing to know how well resources were allocated, is that misallocation
of resources usually results in higher costs. If too many people were put onto tasks then
manpower costs will be higher, if too few people are put onto a task then it may take
longer, and could end up delaying project completion and could result in penalties.
Similarly with machines and raw materials too much of either or too little of either can
result in cost overruns and delays.
At the start of the project, a resource histogram should have been drawn up. This
histogram should show what resources, will be needed at what point in the project. If
more than one type of resource is going to be needed then more than one histogram
should be drawn up. Thus a histogram showing manpower allocation may be needed, as
well as a histogram for the flow of raw materials. If the men are going to be, dependant,
on machine availability to be able to work, then the histogram should be drawn up with
machine availability as a constraint. Raw materials may be needed as a constraint too,
necessitating much forethought before a resource histogram can be put to paper.
If the resource histogram had the required planning and forethought then it should have
accurately reflected conditions during the project. To test this, actual resource usage
during the project should have been monitored, utilising any constraints from the initial
planning. If resource usage differed from the plan then it should be examined to see
why this occurred.
Some possible reasons are variations in the project from the start, difficulties and time
needed on activities either over or underestimated, idle time on resources because
activity precedence were incorrect and some couldn’t start when planned, supplies not
arriving on time, machine breakdowns, etc. Some of these may have resulted from bad
_____________________________________________________________________
_______________________________________________________________________________________________
planning, but others may due to other operational or environmental problems. For
example, in the case of machinery breaking down, this may have been preventable if
better maintenance standards had been enforced or if a regular maintenance schedule
is enforced.
Once the resources have been examined and the problems seen, this information
should be noted down on a chart similar to that used in the network and Gantt
comparison. Once again this should be kept for future reference to provide a guide
when doing other projects.
Activity Activity Variation in Reason for Possible

Description Resources Variation Change
_____________________________________________________________________
_______________________________________________________________________________________________
Form 9: Staff Evaluation Problem Chart 1

An extremely important factor in how well the project runs is in the staff assigned to it.
Staff who are demotivated with a low morale will not perform well, whereas happy
motivated employees will generally perform better.
An important factor in determining the staff’s morale is how well suited to their tasks the
staff are. People forced to do jobs for which they are ill equipped and untrained will
generally have a low morale. Expecting people to perform in ways that they cannot is a
sure way to create a demotivated project team, which is unlikely to perform well even on
tasks within its capabilities. Similarly, people who are over skilled for the job may grow
bored and demotivated by the lack of challenge inherent in the job being performed.
For this reason it is important to select the right mix of people for the project team, one
that will contain people with the correct mix of skills and at the correct levels for them to
be able to do, their jobs effectively and efficiently.
Additionally, a performance appraisal of each staff member on the project at the end of
the project may be useful in pinpointing weaknesses and strengths in each individual. It
can also be used as a tool in deciding on bonuses and promotions.
The form below should be filled in by each person on the project, rating themselves, and
by that person’s manager. Once they have filled in the form, they come together and
compare their results. In discussion with one another a consensus score on each item
can be obtained and, each person can gain an impression of what the other is thinking
and how to approach problem areas to correct them.
Problems experienced and possible ways of preventing them.

Problem Experienced Cause of problem Ways to avoid problem in the
future
_____________________________________________________________________
_______________________________________________________________________________________________
_____________________________________________________________________
_______________________________________________________________________________________________
Form 10: Problem chart 2

Problems experienced how they were handled, and how they should be handles in
the future.
Problem Experienced How was it handled How should it be
handled in the future
_____________________________________________________________________
_______________________________________________________________________________________________
Form 11: Budgeting variances
Budgetary constraints are an extremely important area of project management and

control. Thus it is exceptionally important to evaluate how well the project remained
within budget and how well cost objectives were met.
An extremely useful tool to do this is the Earned Value Analysis (C spec). This provides
both a mathematical tool and a graphical one for showing planned VS actual costs. Thus
if the C spec was done correctly during the Project Analysis phase one need only
examine it in order to see variations in budgeted VS actual costs. Once these variations
have been noted, each activity which has exceeded its budget, or come in under budget,
should be examined. The purpose of this closer look is to see if there are any variations
in these activities, which caused the variation to occur.
If the previous areas of the post project evaluation have been carried out, then many of
the activities being examined may have already been examined during the network or
Gantt chart stages, as any variations there are likely to affect the budget for that activity.
However, this is not true of all variations. An increase in price of one of the inputs, can
result in an increase in cost e.g. a sudden increase in the cost of labour VS machinery
will result in an activity running over budget even though it has been performed perfectly,
one would then want to re-examine that activity to see if it could be made more machine
intensive and thus reduce its cost
Similarly, one of the inputs on an activity may become less expensive, resulting in it
coming in under budget. In this case one would want to examine that activity to see
which input has become less expensive, and how this can be applied, to other activities
eg: The dramatic influx of computers onto the market and the business world since the
early 80’s due to their high performance and low cost.
In analyzing a variation of cost on the activity the information gained during the earlier
evaluations of the Gantt chart and network chart will be extremely helpful, showing how
these activities varied from the plan. Those activities, which did not appear on either of
the two previous evaluations are the ones most likely to have been affected by
environmental factors and changes in costs of inputs.
_____________________________________________________________________
_______________________________________________________________________________________________
However, one must be careful to avoid the scenario where an activity was evaluated
previously due to it starting early or late and then assuming that the variance in the
budget is related to the previous reason for the variance on the activity. The activity may
still have been processed exactly as planned, once started, but the variance in the
budgeted cost is due to other factors. Thus one must still examine each activity to
ensure that the previous reason for variance is the same as the reason for the budgetary
variance.
A form is provided at the end for recording variances of activity budgets, the reason for
these and what changes can be made to future projects to improve budgeting
performance. Like the charts for the previous areas of post project evaluation, this
should be kept for referencing when new projects are being planned, or methods are
being reviewed.
Looking back in time people often say that they wished they had know what was going to
happen so that they could have avoided the problems with which they were confronted.
The aim of this stage of the evaluation is to find these problems, and to try and
incorporate the lessons learned into the planning stages of the next project. It will also
provide a gauge for us to see how well our planning was done and how effective our
planning was.
The precious evaluation stages have all been reliant on parts of the initial planning stage
in order to be effective. This stage examines the project in retrospect to try and find
areas in which we could have performed better, areas in which mistakes were made and
affected the project negatively.
Each problem should be examined separately and the causes for them occurring
ascertained. The method discussed earlier of continuously asking WHY? can be an
invaluable tool in tracing down the root of a problem. Once the root of a problem has
been ascertained it is possible to find a solution to prevent a similar occurrence in future
projects. Looking at how the problem was corrected during this project may be helpful,
but is not usually the correct solution. Generally, during the project the fastest, easiest
solution is used to correct the problem, but does not correct the cause of the problem.
_____________________________________________________________________
_______________________________________________________________________________________________
Thus the solution from the project may be useful to see to know how to correct a similar
problem during a project, but it will not necessarily tell you how to prevent the problem.
Another important area for consideration is how was the problem handled? Was it
allowed to become a crisis with panic setting in and nobody taking any effective action,
or was it controlled and effectively managed in order to prevent as much damage as
possible? Either of these situations provides an opportunity to learn. In the first case we
can see how not to handle problems, and we should try to formulate a solution that
would have been better and can be used in latter problem solving. In the second case,
we can see how we should handle problems and if possible the process used should be
formalised in order to enable us to reuse it when necessary.
In order to record the problems experienced and the solutions utilised, and possible
other solutions/ ways to avoid in the future two forms are provided. One of the forms is to
record what problems were experienced, what the probable causes were and how they
may be avoided in the future. The second form is for problem handling, how was it
handled this time and how should it be handled if it reoccurs sometime in the future.
Activity Activity Reason for Variance Possible changes

Description
_____________________________________________________________________
_______________________________________________________________________________________________
Form 12: Good Performance chart - what went better than

expected and why.
Just as importantly as identifying problems in the project, is the task of identifying those
items that succeeded better than planned. In order to learn from the project, it is
necessary to identify those areas in which we were more successful and record how we
did it and how it may be repeated.
In many cases, these variations should have been picked up prior to this point, during
the earlier stages of the post project evaluation. The purpose of re-examining the
project now to see if there are any other points to be learned from is twofold. Firstly, it
acts as a double check on the earlier areas of project evaluation, ensuring that anything
we may learn from those areas is recorded. Secondly, extraneous areas that have not
fallen into other areas of the evaluation will now be examined, ensuring that all areas of
the project are evaluated.
Just as in trying to reach the cause of a problem we asked questions to ascertain what
the real cause was, so we should perform the same procedure here. By getting to the
root of the reason for better performance, we can more easily find a way in order to
emulate the behaviour. Too often, it is easy to concentrate on the errors and problems
experienced, without paying proper attention to those things that were done right.
Once the root of reason for better performance is found, we can proceed to create
methods to incorporate these lessons into our next project. Care should be taken that
something that occurred due to environmental circumstances is not misinterpreted as
behaviour that we ourselves can influence. If environmental changes are the reason for
the improved performance, it is outside of our control and we can only hope that the
situation will remain favourable to us. Where possible, if we know that the environmental
situation is about to change, an attempt to recreate that environment within the company
may be useful. This tactic is useless if the situation is due to changes in law or other non
controllable areas.
_____________________________________________________________________
_______________________________________________________________________________________________
Once we have identified those things we have done right, we should record them to
allow us to learn from them and incorporate them into future projects. A form is included
for this with space to record what it was that went better than expected, how it happened
and how it can be repeated in future projects.
Area of better Reason for better How can this

performance performance performance be
repeated?
_____________________________________________________________________
_______________________________________________________________________________________________
Form 13: Evaluation of management and control methods.
In evaluating the control and management of the project, one must examine how the
overall flow of the project occurred. If the flow was good, with efficient integration
between different areas, control of cross team functions was smooth and good client
relations evident, then good control and management was exercised. If, on the other -
hand, the project was a shambles, moving from one crisis to the next with little or no
communication between functional areas then there is a definite need for better control
and management structures.
If there was a problem with the control and management of the project, the techniques
used for managing the project should be closely examined. Are the techniques
themselves at fault or was it the manner in which they were utilised that was at fault?
If the techniques themselves are incorrect then a change in management methods is

necessary. Instead of just jumping in to the deep end, and picking some methods, out of
a text book and, placing those in place, it may be preferable to hire outside consultants
to examine the company and to recommend what new methods should be utilised to suit
your company and your area of business. Additionally, staff with the knowledge of the
management methods desired may be hired and put to work adapting your current work
methods to those you wish to achieve.
If the fault in the control and management of the project is not so much in the methods
used as in the way they are being utilised, the problem may be one of training.
Insufficiently or incorrectly trained staff may use the tools provided without any real
understanding of what they are meant to achieve. This results in errors which, will lead to
problems in the project. Also, a lack of understanding may lead to people taking
shortcuts with the process, not realising what they are skipping and the problems they
will cause in other areas. In this case refresher courses, on methods used by the
company and the reasoning behind them can be beneficial in keeping staff motivated to
utilise the methods utilised by the company.
Retraining of staff can be done internally if the necessary skills are available from within
the company. Alternatively, if the methods used by your company are ones generally
_____________________________________________________________________
_______________________________________________________________________________________________
used in the market, external people/companies can be used for the training of staff.
However, since it is very unlikely that your company will follow some outside
management methodology without, any variations at all, internal training should still take
place, showing how the process is performed within the company.
Once again, a chart with the problems experienced should be kept to allow you to store
the lessons learned from the project. For this reason there is a form provided that follows
the format for the forms in the previous sections, having place for the problem
experienced, corrective action and possible way of preventing it occurring once again.
Management Problem that Corrective Action Suggestion to prevent

area with occurred taken problem occurring in
problem later projects
_____________________________________________________________________
_______________________________________________________________________________________________
Form 14: Evaluation of new method

In all the previous sections we have highlighted the need to provide documentation to
allow us to review this project and transfer new knowledge to other projects. Such a
process may have occurred with this project, resulting in us trying new ways of doing
things. Additionally, you may have just undergone a restructuring of your company or
management methods leading to you trying new ways to achieve your objectives.
In order to see if these new methods have been successful, one must examine the areas
in which they were implemented and compare it to the historical data from previous
projects. Only by comparing it to what went before can we see if there was an
improvement or not.
In comparing the data, one must remember that there is a time difference factor that may
affect your results. An example of this is when comparing two monetary amounts. Before
comparing them the time value of money should be accounted for by finding either the
future value of the amount from the historical value, or the discounted amount of the
current value. Only once both amounts are in the same time frame can they be
compared. Alternatively, ratios or percentages can be used if two values from the same
time period are utilised for both the historical and, current values. Similar problems may
also result from changes in laws or the outside environment, not making the two
situations similar enough for comparative purposes.
Once the data from the current project and the historical project are ready to be
compared, you can proceed with evaluating new methods used on the current project. If
the new method has proven to be superior to the old, then one should continue to utilise
it. If the new method has not performed as well as expected, then one should return to
doing things the way you did them, previously, or else look for another way to perform
that task if the previous method was unsatisfactory.
The results of these evaluations should be stored, in order that at a later stage if other
methods are tried there is comparative data for them to utilise. An important factor to
remember is that just because a method is new, it does not necessarily mean that it is
superior to previous methods.
_____________________________________________________________________
_______________________________________________________________________________________________
A form is supplied to record the result of the evaluations of new methods and whether
one should continue to utilise these new methods. Place is provided to enter the new
method, how it performed, how it compares to the previous method and whether it
should continue to be used.
New Method Details Details of performance Superior to old Continue to utilise

method? new method?
_____________________________________________________________________
_______________________________________________________________________________________________
Form 15: Client Questionnaire

At the end of the project client satisfaction should be gauged. The whole aim of the
project is to provide the client with a product from which he will benefit, and from which
you will make a profit by producing. If the client is unsatisfied with his product, then only
half of the project has been completed even if the client has received a product.
What are the results of a dissatisfied client? Generally once you have supplied a client
with a product with which he is not satisfied, he is unlikely to return to you to obtain
further items. Additionally, that client is likely to talk to other potential clients who, on
hearing a negative report on your performance, will be harder to convince to utilise your
services.
With satisfied clients the opposite is true. A client who is happy with your performance is
likely to return when they next need to utilise your services, and they are likely to give
other people good reports on your company. A satisfied client can almost act as an
unofficial salesman in extolling the virtues of your Product to others.
Thus it can be seen to be essential to measure customer satisfaction, to hopefully

discover a dissatisfied customer and turn them into a satisfied one. Also, when the
project has delivered a product that will be in use for a long period of time, remaining in
contact with the client can help with keeping him satisfied.
A well known, problem in marketing is that of post purchase dissonance. Post purchase
dissonance occurs after the sale is made, the buyer begins to question the wisdom of his
choice. Through remaining in contact with the buyer through advertising, direct mail etc.
one can, reassure him of the wisdom of buying your product.
Similarly in project management, once the project has been completed the client may
begin to doubt the wisdom of performing the project, of utilising you to carry it through.
By remaining in contact with the client one can be there to reassure the client that they
made the right decision in carrying out the project and their is a higher chance of having
a satisfied client.
One of the best ways to ascertain whether the client is satisfied or not is via a
questionnaire. In completing a questionnaire the client provides you with a vehicle to
_____________________________________________________________________
_______________________________________________________________________________________________
discover what the client believes in certain areas and how they evaluate those areas as
opposed to how you may evaluate them yourself.
An example questionnaire is provided in the forms section. This questionnaire is aimed
at a specific person in the client’s company and as such is unlikely to be anonymous. If
an anonymous questionnaire is needed, such as one to be distributed to the users of a
new system rather than to the management then the optional pages should be included.
Company Name:
Address:
Project:
Person Completing Questionnaire:
(Leave out if anonymous)
Position:
(Leave out if anonymous)
Role in Project:
All Responses are rated on a scale of 1 to 5, 1 showing total disagreement and 5 being
total agreement. Please circle the desired response.
◊ You agree that the project plan was well thought out and defined?
◊ ◊ ◊ ◊ ◊
◊ You agree that the scope of the project was well defined?
◊ ◊ ◊ ◊ ◊
◊ You agree that the scope of the project was managed to prevent it getting out of hand
once the project started?
◊ ◊ ◊ ◊ ◊
◊ You agree that project manager had a thorough understanding of the needs of the
project?
◊ ◊ ◊ ◊ ◊
◊ You agree that the project manager was able to transmit his understanding of the
project to the people involved in performing the work?
_____________________________________________________________________
_______________________________________________________________________________________________
◊ ◊ ◊ ◊ ◊
◊ You agree that problems that occurred during the project were well handled?
◊ ◊ ◊ ◊ ◊
◊ You agree that the project team had the skills required to do the project?
◊ ◊ ◊ ◊ ◊
◊ You agree that the best solution for the project objective was chosen?
◊ ◊ ◊ ◊ ◊
◊ You agree that the right technology and tools were utilised for the project?
◊ ◊ ◊ ◊ ◊
◊ You agree that communication during the project between you and the project team
was good?
◊ ◊ ◊ ◊ ◊
◊ You are happy with the final product
◊ ◊ ◊ ◊ ◊
◊ You were happy with the means of resolving conflict between yourself and the
project team.
◊ ◊ ◊ ◊ ◊
◊ You are happy with the final budget on the project
◊ ◊ ◊ ◊ ◊
◊ You would utilise our company again for more projects.
◊ ◊ ◊ ◊ ◊
◊ You are happy with the way the project was managed
◊ ◊ ◊ ◊ ◊
◊ Please give any general comments/suggestions in the area below:
_____________________________________________________________________
_______________________________________________________________________________________________
Thank you for filling out this questionnaire.
_____________________________________________________________________
_______________________________________________________________________________________________
Form 16: Client Questionnaire:

Optional pages for anonymous questionnaire.
As this is an anonymous questionnaire, please do not put your name or title on
this sheet.
Please tick the correct option.
AGE:
Under 20 31 – 35 46 – 50 61 - 65
21 – 25 36 – 40 51 – 55 over 65
26 – 30 41 – 45 55 – 60
Highest Educational Qualification:
No Formal Three year
Education degree/Diploma
Primary Postgraduate
School qualification
High
School
Length of time in company

Under 6 months 2 – 5
Years
6 months – 1 Year 5 – 10
Years
1 – 2 Years More than
10 Years
_____________________________________________________________________
_______________________________________________________________________________________________
Activity
Think about the Project you are working on. What is
working well? Why is it working well? What could you
stop doing now? What could you do differently
_____________________________________________________________________
_______________________________________________________________________________________________
Glossary
Accountability Matrix. See responsibility assignment matrix.
Activity. An element of work performed during the course of a project..
Activity Definition. Identifying the specific activities that must be performed in order to
produce the various project deliverables.
Activity Description (AD). A short phrase or label used in a project network diagram..
Activity Duration Estimating. Estimating the number of work periods which will be
needed to complete individual activities.
Activity-on-Arrow (AOA). See arrow diagramming method.
Activity-on-Node (AON). See precedence diagramming method.
Actual Cost of Work Performed (ACWP). Total costs incurred (direct and indirect) in
accomplishing work during a given time period. See also earned value.
Actual Finish Date (AF). The point in time that work actually ended on an activity.
Actual Start Date (AS). The point in time that work actually started on an activity.
Administrative Closure. Generating, gathering and disseminating information to

formalize project completion.
Application Area. A category of projects that have common elements not present in all
projects.
Arrow. The graphic presentation of an activity. See also arrow diagramming method.
_____________________________________________________________________
_______________________________________________________________________________________________
Arrow Diagramming Method (ADM). A network of diagramming technique in which

activities are represented by arrows.
As-of-date. See data date.
Backward Pass. The calculation of late finish dates and late start dates for the
uncompleted portions of all network activities.
Bar Chart. A graphic display of schedule-related information.
Baseline. The original plan (for a project, a work package, or an activity), plus or minus
approved changes.
Baseline Finish Date. See scheduled finish date.
Baseline Start Date. See scheduled start date.
Budget At Completion (BAC). The estimated total cost of the project when done.
Budget Estimate. See estimate.
Budgeted Cost of Work Performed (BCWP). The sum of the approved cost estimates
(including any overhead allocation) for activities (or portions of activities) completed
during a given period (usually project-to-date). See also earned value.
Budgeted Cost of Work Scheduled (BCWS). The sum of the approved cost estimates
(including any overhead allocation) for activities (or portions of activities) scheduled to be
performed during a given period (usually project-to-date). See also earned value.
Calendar Unit. The smallest unit of time used in scheduling the project.
Change Control Board (CCB). A formally constituted group of stakeholders

responsible for approving or rejecting changes to the project baselines.
_____________________________________________________________________
_______________________________________________________________________________________________
Change in Scope. See scope change.
Chart of Accounts. Any numbering system used to monitor project costs by category (
e.g. labor, supplies, materials).
Charter. See project charter.
Code of Accounts. Any numbering system used to uniquely identify each element of
the work breakdown structure. See also chart of accounts.
Communications Planning. Determining the information and communications needs of

the project stakeholders.
Concurrent Engineering. An approach to project staffing that, in its most general form,
calls for implementors to be involved in the design phase. Sometimes confused with fast
tracking.
Contingencies. See reserve and contingency planning.
Contingency Allowance. See reserve.
Contingency Planning. The development of a management plan that identifies

alternative strategies to be used to ensure project success if specified risk events occur.
Contingency Reserve. A separately planned quantity used to allow for future situations
which may be planned for only in part (sometimes called “known unknowns”).
Contract. A contract is a mutually binding agreement which obligates the seller to

provide the specified product and obligates the buyer to pay for it. Contracts generally
fall into one of three broad categories :
• Fixed price or lump sum contracts – this category of contract involves a fixed total
price for a well-defined product. Fixed price contracts may also include incentives for
meeting or exceeding selected project objectives such as schedule targets.
_____________________________________________________________________
_______________________________________________________________________________________________
• Cost reimbursible contracts – this category of contract involves payment

(reimbursement) to the contractor for its actual costs. Costs are usually classified as
direct costs (costs incurred directly by the project, such as wages for members of
the project team) and indirect costs (costs allocated to the project by the performing
organization as a cost of doing business, such as salaries for corporate executives).
Indirect costs are usually calculated as a percentage of direct costs. Cost
reimbursible contracts often include incentives for meeting or exceeding selected
project objectives such as schedule targets or total cost.
• Unit price contracts – the contractor is paid a preset amount per unit of service and
the total value of the contract is a function of the quantities needed to complete the
work.
Contract Administration. Managing the relationship with the seller.
Contract Close-out. Completion and settlement of the contract, including resolution of

all outstanding items.
Control. The process of comparing actual performance with planned performance,

analyzing variances, evaluating possible alternatives, and taking appropriate corrective
action as needed.
Control Charts. Control charts are a graphic display of the results, over time and
against established control limits of a process. They are used to determine if the
process is “in control” or in need of adjustment.
Corrective Action. Changes made to bring expected future performance of the project
into line with the plan.
Cost Budgeting. Allocating the cost estimates to individual project components.
Cost Control. Controlling changes to the project budget.
Cost Estimating. Estimating the cost of the resource needed to complete project
activities.
_____________________________________________________________________
_______________________________________________________________________________________________
Cost of Quality. The costs incurred to ensure quality. The cost of quality includes
quality planning, quality control, quality assurance and rework.
Cost Performance Index (CPI). The ratio of budgeted costs to actual costs
(BCWP/ACWP).
Cost Plus Fixed Fee (CPFF) Contract. (A type of contract where the buyer reimburses
the seller for the seller’s allowable costs (allowable costs are defined by the contract)
plus a fixed amount of profit (fee).
Cost Plus Incentive Fee (CPIF) Contract. A type of contract where the buyer
reimburses the seller for the seller’s allowable costs (allowable costs are defined by the
contract), and the seller earns its profits if it meets defined performance criteria.
Cost Variance (CV). (1) Any difference between the estimated cost of an activity and
the actual costs of that activity. (2) In earned value, BCWP less ACWP.
Crashing. Taking action to decrease the total project duration after analyzing a number
of alternatives to determine how to get the maximum duration compression for the least
costs.
Critical Activity. Any activitiy on a critical path. Most commonly determined by using
the critical path method.
Critical Path. In a project network diagram, the series of activities which determines
the earliest completion of the project.
Critical Path Method (CPM). A network analysis technique used to predict project
duration by analyzing which sequence of activities (which path) has the least amount of
scheduling flexibility (the least amount of float).
Current Finish Date. The current estimate of the point in time when an activity will be
completed.
_____________________________________________________________________
_______________________________________________________________________________________________
Current Start Date. The current estimate of the point in time when an activity will begin.
Data Date (DD). The point in time that separates actual (historical) data from future
(scheduled) data. Also called as-of-date.
Definitive Estimate. See estimate.
Deliverable. Any measurable, tangible, verifiable outcome, result, or item that must be
produced to complete a project or part of a project.
Dependency. See logical relationship.
Dummy Activity. An activity of zero duration used to show a logical relationship in the
arrow diagramming method.
Duration (DU). The number of work periods (not including holidays or other non-
working periods) required to complete an activity or other project element.
Duration Compression. Shortening the project schedule without reducing the project
scope.
Early Finish Date (EF). In the critical path method, the earliest possible point in time on
which the uncompleted portions of an activity (or the project) can finish based on the
network logic and any schedule constraints.
Early Start Date (ES). In the critical path method, the earliest possible point in time on
which the uncompleted portions of an activity (or the project) can start, based on the
network logic and any schedule constraints.
Earned Value (EV). (1) A method for measuring project performance. (2) The budgeted
cost of work performed for an activity or group of activities.
Earned Value Analysis. See definition (1) under earned value.
_____________________________________________________________________
_______________________________________________________________________________________________
Effort. The number of labor units required to complete an activity or other project
element.
Estimate. An assessment of the likely quantitive result.
Estimate At Completion (EAC). The expected total cost of an activity, a group of

activities, or of the project when the defined scope of work has been completed.
Estimate to Complete (ETC). The expected additional cost needed to complete an

activity, a group of activities, or the project.
Event-on-Node. A network diagramming technique in which events are represented by

boxes (or nodes) connected by arrows to show the sequence in which the events are to
occur.
Exception Report. Document that includes only major variations from plan (rather than
all variations).
Expected Monetary Value. The product of an event’s probability of occurrence and the
gain or loss that will result.
Fast Tracking. Compressing the project schedule by overlapping activities that would
normally be done in sequence, such as design and construction.
Finish Date. A point in time associated with an activity’s completion.
Finish-to-Finish (FF), See logical relationship.
Finish-to-Start (FS). See logical relationship.
Firm Fixed Price (FFP) Contract. A type of contract where the buyer pays the seller a
set amount (as defined by the contract) regardless of the seller’s costs.
_____________________________________________________________________
_______________________________________________________________________________________________
Fixed Price Contract. See firm fixed price contract.
Fixed Price Incentive Fee (FPIF) Contract. A type of contract where the buyer pays the
seller a set amount (as defined by the contract) and the seller can earn an additional
amount if it meets defined performance criteria.
Float. The amount of time that an activity may be delayed from its early start without
delaying the project finish date.
Forecast Final Cost. See estimate at completion.
Forward Pass. The calculation of the early start and early finish dates for the
uncompleted portions of all network activities. See also network analysis and backword
pass.
Fragnet. See subnet.
Free Float (FF). The amount of time an activity can be delayed without delaying the
early start of any immediately following activities. See also float.
Functional Manager. A manager responsible for activities in a specialized department

or function (e.g. engineering, manufacturing, marketing).
Functional Organization. An organization structure in which staff are grouped

hierachically by specialty (e.g. production, marketing, engineering and accounting at the
top level, with engineering, further divided into mechanical, electrical and others).
Gantt Chart. See bar chart.
Grade. A category or rank used to distinquish items that have the same functional use
(e.g. “hammer”) but do not share the same requirements for quality.
Graphical Evaluation and Review Technique (GERT). A network analysis technique

that allows for conditional and probabilistic treatment of logical relationships.
_____________________________________________________________________
_______________________________________________________________________________________________
Hammock. An aggregate or summary activity (a group of related activities is shown as

one and reported at a summary level).
Hanger. An unintended break in a network path.
Information Distribution. Making needed information available to project stakeholders

in a timely manner.
Initiation. Committing the organization to begin a project phase.
Integrated Cost/Schedule Reporting. See earned value.
Invitation for Bid (IFB). Generally, this term is equivalent to request for proposal.
Key Event Schedule. See master schedule.
Lag. A modification of a logical relationship which directs a delay in the successor task.
Late Finish Date (LF). In the critical path method, the latest possible point in time that
an activity may be completed without delaying a specified milestone (usually the project
finish date).
Late Start Date (LS). In the critical path method, the latest possible point in time that an
activity may begin without delaying a specified milestone (usually the project finish date).
Lead. A modification of a logical relationship which allows an acceleration of the

successor task.
Level of Effort (LOE). Support-type activity (e.g vendor or customer liason) that does
not readily lend itself to measurement of discrete accomplishment.
Leveling. See resource leveling.
_____________________________________________________________________
_______________________________________________________________________________________________
Life-cycle Costing. The concept of including acquisition, operating and disposal costs
when evaluating various alternatives.
Line Manager. (1) The manager of any group that actually makes a product or
performs a service. (2) A functional manager.
Link. See logical relationship.
Logic. See network logic.
Logic Diagram. See project network diagram.
Logical Relationship. A dependency between two project activities, or between a

project activity and a milestone.
• Finish-to-start-the “from” activity must finish before the “to” activity can start.
• Finish-to-finish-the “from” activity must finish before the “to” activity can finish.
• Start-to-start-the “from” activity must start before the “to” activity can start.
• Start-to-finish-the “from” activity must start before the “to” activity can finish.
Loop. A network path that passes the same node twice.
Management Reserve. A separately planned quantity used to allow for future situations
which are impossible to predict (sometimes called “unknown unknowns”).
Master Schedule. A summary-level schedule which identifies the major activities and
key milestones. See also milestone schedule.
Mathematical Analysis. See network analysis.
Matrix Organization. Any organizational structure in which the project manager shares
responsibility with the functional managers for assigning priorities and for directing the
work of individuals assigned to the project.
Milestone. A significant event in the project, usually completion of a major deliverable.
_____________________________________________________________________
_______________________________________________________________________________________________
Milestone Schedule. A summary-level schedule which identifies the major milestones.

See also master schedule.
Mitigation. Taking steps to lessen risk by lowering the probability of a risk event’s
occurrence or reducing its effect should it occur.
Modern Project Management (MPM). A term used to distinquish the current broad
range of project management (scope, cost, time, quality, risk, etc) from narrower,
traditional use that focused on cost and time.
Monitoring. The capture, analysis, and reporting of project performance, usually as

compared to plan.
Monte Carlo Analysis. A schedule risk assessment technique that performs a project
simulation many times in order to calculate a distribution of likely results.
Near-Critical Activity. An activity that has low total float.
Network. See project network diagram.
Network Analysis. The process of identifying early and late start and finish dates for
the uncompleted portions of project activities.
Network Logic. The collection of activity dependencies that make up a project network
diagram.
Network Path. Any continuous series of of connected activities in a project network

diagram.
Node. One of the defining points of a network, a junction point joined to some or all of
the other dependency lines.
Order of Magnitude Estimate. See estimate.
_____________________________________________________________________
_______________________________________________________________________________________________
Organizational Breakdown Structure (OBS). A depiction of the project organization

arranged so as to relate work packages to organizational units.
Organizational Planning. Identifying, documenting, and assigning project roles,

responsibilities, and reporting relationships.
Overall Change Control. Coordinating changes across the entire project.
Overlap. lSee lead.
Parametric Estimating. An estimating technique that uses a statistical relationship

between historical data and other variables.
Pareto Diagram. A histogram, ordered by frequency of occurrence, that shows how

many results were generated by each identified cause.
Path. A set of sequentially connected activities in a project network diagram.
Path Convergence. In mathematical analysis, the tendency of parallel paths of

approximately equal duration to delay the completion of the milestone where they meet.
Path Float. See float.
Percent Complete (PC). An estimate, expressed as a percent, of the amount of work

which has been completed on an activity or group of activities.
Performance Reporting. Collecting and disseminating information about project

performance to help ensure project progress.
Performance Organization. The enterprise whose employees are most directly

involved in doing the work of the project.
_____________________________________________________________________
_______________________________________________________________________________________________
PERT Chart. A specific type of project network diagram. See Program Evaluation and
Review Technique.
Phase. See project phase.
Planned Finish Date (PF). See scheduled finish date.
Planned Start Date (PS). See scheduled start date.
Precedence Diagramming Method (PDM). A network diagramming technique in which

activities are represented by boxes (or nodes).
Precedence Relationship. The term used in the precedence diagramming method for
a logical relationship.
Predecessor Activity. (1) In the arrow diagramming method, the activity which enters
a node. (2) In the precedence diagramming method, the “from” activity.
Procurement Planning. Determining what to procure and when.
Program. A group of related projects managed in a coordinated way.
Program Evaluation and Review Technique (PERT). An event-oriented network

analysis technique used to estimate project duration when there is a high degreee of
uncertainty with the individual activity duration estimater.
Project. A temporary endeavour undertaken to create a unique product or service.
Project Charter. A document issued by senior management that provides the project
manager with the authority to apply organizational resources to project activities.
Project Communications Management. A subset of project management that includes

the processes required to ensure proper collection and dissemination of project
information.
_____________________________________________________________________
_______________________________________________________________________________________________
Project Cost Management. A subset of project management that includes the

processes required to ensure that the project is completed within the approved budget.
Project Human Resource Management. A subset of project management that

includes the processes required to make the most effective use of the people involved
with the project.
Project Integration Management. A subset of project management that includes the

processes required to ensure that the various elements of the project are properly
coordinated.
Project Life Cycle. A collection of generally sequential project phases whose name and
number are determined by the control needs of the organization or organizations
involved in the project.
Project Management (PM). The application of knowledge, skill, tools, and techniques
to project activities in order to meet or exceed stakeholder needs and expectations from
a project.
Project Management Body of Knowledge (PMBOK). An inclusive term that describes

the sum of knowledge within the profession of project management.
Project Management Professional (PMP). An individual certified as such by the

Project Management Institute.
Project Management Software. A class of computer applications specifically designed

to aid with planning and controlling project costs and schedules.
Project Management Team. The members of the project team who are directly
involved in project management activities.
Project Manager (PM). The invidual responsible for managing a project.
_____________________________________________________________________
_______________________________________________________________________________________________
Project Network Diagram. Any schematic display of the logical relationships of project
activities.
Project Phase. A collection of logically related project activities, usually culminating in

the completion of a major deliverable.
Project Plan. A formal, approved document used to guide both project execution and
project control.
Project Plan Development. Taking the results of other planning processes and putting
them into a consistent coherent document.
Project Plan Execution. Carrying out the project plan by performing the activities
included therein.
Project Planning. The development and maintenance of the project plan.
Project Procurement Management. A subset of project management that includes the

processes required to acquire goods and services from outside the performing
organization.
Project Quality Management. A subset of project management that includes the

processes required to ensure that the project will satisfy the needs for which it was
undertaken.
Project Risk Management. A subset of project management that includes the

processes concerned with identifying, alayzing and responding to project risk.
Project Schedule. The planned dates for performing activities and the planned dates
for meeting milestones.
Project Scope Management. A subset of project management that includes the

processes required to ensure that the project includes all of the work required, and only
work required, the complete the project successfully.
_____________________________________________________________________
_______________________________________________________________________________________________
Project Team Members. The people who report either directly or indirectly to the
project manager.
Project Time Management. A subset of project management that includes the

processes required to ensure timely completion of the project.
Projectized Organization. Any organizational structure in which the project manager

has full authority to assign priorities and to direct the work of individuals assigned to the
project.
Quality Assurance (QA). (1) The process of evaluating overall project performance on
a regular basis to provide confidence that the project will satisfy the relevant quality
standards. (2) The organizational unit that is assigned responsibility for quality
assurance.
Quality Control (QC). (1) The process of monitoring specific project results to
determine if they comply with relevant quality standards and identifying ways to eliminate
causes of unsatisfactory performance. (2) The organizational unit that is assigned
responsibility for quality control.
Quality Planning. Identifying which quality standards are relevant to the project and
determining how to satisfy them.
Remaining Duration (RDU). The time needed to complete an activity.
Request for Proposal (RFP). A type of bid document used to solicit proposals from
prospective sellers of products or services.
Request for Quotation (RFQ). Generally, this term is equivalent to request for
proposal.
Reserve. A provision in the project plan to mitigate cost and/or schedule risk.
_____________________________________________________________________
_______________________________________________________________________________________________
Resource Leveling. Any form of network analysis in which scheduling decisions (start
and finish dates) are driven by resource management concerns.
Resource-Limited Schedule. A project schedule whose start and finish dates reflect
expected resource availability.
Resource Planning. Determining what resources (people, equipment, materials) are

needed in what quantities to perform project activities.
Responsibility Assignment Matrix (RAM). A structure which relates the project

organization structure to the work breakdown structure to help ensure that each element
of the project’s scope of work is assigned to a responsible individual.
Responsibility Chart. See responsibility assignment matrix.
Responsibility Matrix. See responsibility assignment matrix.
Retainage. A portion of a contract payment that is held until contract completion in

order to ensure full performance of the contract terms.
Risk Event. A discrete occurrence that may affect the project for better or worse.
Risk Identification. Determining which risk events are likely to affect the project.
Risk Quantification. Evaluating the probability of risk event occurrence and effect.
Risk Response Control. Responding to changes in risk over the course of the project.
Risk Response Development. Defining enhancement steps for opportunities and

mitigation steps for threats.
S-Curve. Graphic display of cmulative costs, labor hours, or other quanitities, plotted
against time.
_____________________________________________________________________
_______________________________________________________________________________________________
Schedule. See project schedule.
Schedule Analysis. See network analysis.
Schedule Compression. See duration compression.
Schedule Control. Controlling changes to the project schedule.
Schedule Development. Analyzing activity sequences, activity durations, and resource

requirements to create the project schedule.
Schedule Performance Index (SPI). The ratio of work performed to work scheduled
(BCWP/BCWS). See earned value.
Schedule Variance (SV). (1) Any difference between the scheduled completion of an
activity and the actual completion of that activity. (2) In earned value, BCWP less
BCWS.
Scheduled Finish Date (SF). The point in time work was scheduled to finish on an
activity.
Scheduled Start Date (SS). The point in time work was scheduled to start on an
activity.
Scope. The sum of the products and services to be provided as a project.
Scope Baseline. See baseline.
Scope Change. Any change to the project scope.
Scope Change Control. Controlling changes to project scope.
_____________________________________________________________________
_______________________________________________________________________________________________
Scope Definition. Decomposing the major deliverables into smaller, more manageable
components to provide better control.
Scope Planning. Developing a written scope statement that includes the project
justification, the major deliverables, and the project objectives.
Scope Verification. Ensuring that all identified project deliverables have been
completed satisfactorily.
Should-Cost Estimates. An estimate of the cost of a product or service used to provide

an assessment of the reasonableness of a prospective contractor’s proposed cost.
Slack. Term used in PERT for float.
Solicitation. Obtaining quotations, bids, offers, or proposals as appropriate.
Solicitation Planning. Documenting product requirements and identifying potential

sources.
Source Selection. Choosing from among potential contractiors.
Staff Acquisition. Getting the human resources needed assigned to and working on
the project.
Stakeholder. Individuals and organizations who are involved in or may be affected by

project activities.
Start Date. A point in time associated with an activity’s start, usually qualified by one of
the following : actual, planned, estimated, scheduled, early, late, target, baseline or
current.
Start-to-finish. See logical relationship.
Start-to-date. See logical relationship.
_____________________________________________________________________
_______________________________________________________________________________________________
Statement of Work (SOW). A narrative description of products or services to be

supplied under contract.
Subnet. A subdivision of a project network diagram usually representing some form of

subproject.
Subnetwork. See subnet.
Successor Activity. (1) In the arrow diagramming method, the activity which departs a
node. (2) In the precedence diagramming method, the “to” activity.
Target Completion Date (TC). An imposed date which constrains or otherwise modifies
the network analysis.
Target schedule. See baseline.
Task. See activity.
Team Development. Developing individual and group skills to enhance project

performance.
Team Members. See project team members.
Time-scaled Network Diagram. Any project network diagram drawn in such a way that
the positioning and length of the activity represents its duration.
Target Finish Date (TF). The date work is planned (targeted) to finish on an activity.
Target Start Date (TS). The date work is planned (targeted) to start on an activity.
Total Float (TF). See float.
_____________________________________________________________________
_______________________________________________________________________________________________
Total Quality Management (TQM). A common approach to implementing a quality

improvement program within an organization.
Workaround. A response to a negative risk event.
Work Breakdown Structure (WBS). A deliverable-oriented grouping of project

elements which organizes and defines the total scope of the project.
Work Item. See activity.
Work Package. A deliverable at the lowest level of the work breakdown structure. A
work package may be divided into activities.
BIBLIOGRAPHY, REFERENCES & RESOURCES
REFERENCES
Allaire, Y. & Firsirotu, M.E. 1984. Theories of Organisation Culture. Organisation

Studies, 5(3):193-226.
_____________________________________________________________________
_______________________________________________________________________________________________
Alvesson, M. 1987. Organisation Theory and Technocratic Consciousness: Rationality,

Ideology and Quality of Work. Berlin: De Gruyter.
Arendt, H. 1958. The human condition. 2nd edition. Chicago, IL: University of Chicago
Press.
Aristotle. Ross, W.D. (Trans.). 1958. The Nicomachean Ethics. In Kaplan, J.D. (Ed.). The
Pocket Aristotle. New York: Simon & Schuster.
Ashdown, A. 1998. Notes on Strategic Planning. Unpublished handout.
Asher, H. 1983. Causal Modeling. Beverly Hills, CA: Sage.
Babbie, E. 1990. Survey Research Methods. Belmont, CA: Wadsworth.
Barling, J. 1983. Behaviour in organisations, South African Perspectives. South Africa:

McGraw-Hill.
Bank SETA. Sector Skills Plan for Banking: 14 March 2001. South African Government.
Barnard, C.I. 1938. The functions of the executive. Cambridge, MA: Harvard University
Press.
Beck & Cowen. 1996. Double Helix. McGraw-Hill.
Beck, D. & Linscott, G. 1991. The Crucible: Forging South Africa’s Future.
Johannesburg: New Paradigm Press.
Becker, H.S. 1970. The Nature of a Profession in Sociological Work: Method and
Substance. Harmondsworth: Allen Lane.
Bennatan, E.M. 1992. Software Project Management: A Practitioner’s Approach.

London: McGraw-Hill.
Bennis, W. & Nanus, B. 1985. Leaders: the strategies for taking charge. New York:
Harper and Row.
_____________________________________________________________________
_______________________________________________________________________________________________
Biesheuvel, S. 1987. Cross Cultural Psychology: Its relevance to South Africa. In Mauer,
K.F. & Retief, A.J. (Eds). Psychology in Context: Cross cultural research trends in
South Africa. HSRC Investigation into Research Methodology. Research Report
Series 4, Pretoria HSRC:1-35.
Billsberry, J. 1996. The effective manager: London: Sage Publications Ltd.
Blackler, F. 1995. Knowledge, Knowledge Work and Organisations: An Overview and

Interpretation in Organisation Studies. Knowledge Management, 16(6):1021-
1046.
Bolman, L.G. & Deal, T.E. 1997. Reframing Organizations: Artistry, choice and
leadership. 2nd edition. San Francisco: Jossey-Bass.
Bondenhamer, B., Dr. 1997. Mindlines: Lines for Changing Minds. New York: Wiley.
Bower, M. 1966. Will to manage. New York: McGraw-Hill.
Bridges, W. 1992. The Character of Organisations. CPP Books.
Burke, R. 2000. Project Management. 3rd edition. Cape Town: Technical Books (Pty) Ltd.
Brown, A. 1995. Organisational Culture. London: Pitman Publishing.
Campbell, D. & Stanley, J. 1963. Experimental and Quasi-Experimental Designs.

Chicago: Rand McNally.
Cleland, D.I. & King, W.R. 1968. Systems Analysis and Project Management. New York:
McGraw-Hill.
Cleland, D.I. & King, W.R. 1975, Systems Analysis and Project Management. 2nd edition.
New York: McGraw-Hill.
Cleland, D.I. & King, W.R. 1988. Project Management Handbook. New York: Van
Nostrand Reinhold.
_____________________________________________________________________
_______________________________________________________________________________________________
Cohen, March & Olsen. 1972. A Garbage Can Model of Organisational Choice.
Administrative Science Quarterly, 17(1).
Collins, J.C. & Porras, J. 1998. Built to Last. Randomhouse.
Collins, J.C. & Porras, J. 1995. Cult-Like Cultures. Randomhouse.
Commission of Inquiry into the Monetary System and Monetary Policy in South Africa -
Final Report RP 70:1. 1984. Pretoria: Government Printer
Committee to Review the Functioning of Financial Institutions - Report. 1980:25. London:

Her Majesty's Stationery Office.
Converse, J. & Presser, S. 1986. Survey Questions. Beverly Hills, CA: Sage.
Cook, T. & Campbell, D. 1979. Quasi-Experimental Design. Chicago: Rand McNally.
Cooper, D. & Schindler, P. 2001. Business research methods. 7th edition. McGraw-Hill.
Cotterell, M. & Hughes, B. 1995. Software Project Management. London: International

Thompson.
Courpasson, D. 1997. Regulating and Governing Organisations: For a Sociology of

Managerial Action. Sociologie du Travail, 39 (1):39-61.
Dalton, M. 1959. Men who Manage. New York: Wiley.
Day, D.W.J. 1994. Project Management and Control. Macmillan.
Deal, T.E. & Kennedy, A.A. 1982. Corporate cultures: The rites and rituals of corporate
life. Reading, MA: Addison-Wesley.
Deetz, S. 1992. Disciplinary Power in the Modern Corporation in Critical Management

Studies. Alvesson, M. and Willmott, H. (Eds). London: Sage.
Deloitte Research. 2001. The Future of Retail Financial Services.
_____________________________________________________________________
_______________________________________________________________________________________________
Demarco, T. & Lister, T. 1987. Peopleware: Productive Projects and Teams. New York:
Dorset House Publishing.
Denison, D.R. 1996. What is the difference between organisational culture and
organisational climate? A natives point of view on a decade of paradigm wars.
Academy of Management Review, July 21(3):619-654.
Dillon, W.R., Madden, T.S. & Firtle, N.H. 1994. Marketing Research in a Marketing
Environment. 3rd edition. Irwin.
Dougall, H.E. 1970. Capital Markets and Institutions. 2nd edition. New Jersey: Prentice-
Hall.
Drennan, D. 1992. Transforming Company Culture. London: McGraw-Hill.
Drucker, P.F. 1993. Managing the Future: The 1990s and Beyond. New York: McGraw-
Hill.
Durkheim, E. 1951. Suicide: A study in sociology. Spaulding, J.A. & Simpson, G. (Trans.)
(Eds). Glencoe, IL: Free Press.
Earl & Feeny. 1995. Is your CIO adding value? Mckinsey Quarterly, (2):144-161.
Eldridge, J.E.T. & Crombie, A.D. 1974. A Sociology of Organisations. London: Allen and
Unwin.
F&T Weekly. 8 November 1996:55.
Fairclough, L. 1989. Language and Power. London: Longman.
Fairclough, L. 1992. Discourse and Social Change. Cambridge: Polity Press.
Faure, A.P. 1987. An overview of the South African Financial System: The Securities
Markets. Johannesburg: Securities Research, 3:17-25.
Faure, A.P. et al. 1991. The Interest-bearing Securities Market. Halfway House:
Southern Book Publishers.
_____________________________________________________________________
_______________________________________________________________________________________________
Festinger, L. 1957. A theory of cognitive dissonance. Stanford, CA: Stanford University

Press.
Fitzgerald, B. 1996. Formalized Systems Development Methodologies: A Critical

Perspective. Information Systems Journal, 6(1):3-23.
Foucault, M. 1977. Discipline and Punishment: The Birth of the Prison. Harmondsworth:
Penguin.
Foucault, M. 1979. The History of Sexuality Volume I: An Introduction. London: Allen

Lane.
Foucault, M. 1980. Power/Knowledge - selected interviews and other writings 1972-

1977. Gordon, C. (Ed.). Brighton: Harvester Press.
Fournier, V. 1997. The Appeal to "Professionalism" as a Discursive Device of Control.

15th Annual International Labour Process Conference, March 1997.
Fulop, L. & Linstead, S. 1999. Management: A Critical Text. Australia: Macmillan

Business.
Furness, E.L. 1972. An Introduction to Financial Economics. London: Heinemann.
Furnham, A. 1997. Corporate culture shock. Singapore: Times Editions Pte Ltd.
Getzels, J.W., Lipham, J. & Campbell, R.F. 1968. Educational Administration as a Social
Process. New York: Harper and Row.
Giddens, A. 1979. Central Problems in Social Theory. London: Macmillan.
Glick, W.H. 1985. Conceptualising and measuring organisational and psychological

climate: Pitfalls in multi-level research. Academy of Management Review,
10:601-616.
Godsell, G. 1981. Value Conflicts in Organisation. National Psychology Congress,

September 1981. Cape Town.
_____________________________________________________________________
_______________________________________________________________________________________________
Goffee, R. & Jones, G. 1998. The Character of a Corporation. New York: HarperCollins
Publishers.
Goffman, E. 1959. The Presentation of the Self in Everyday Life. Harmondsworth:

Penguin.
Golden, K.A. 1992. The individual and organizational culture: Strategies for action in
highly-ordered contexts. Journal of Management Studies, 29:1-21.
Graham, R. & Englund, R. 2001 Creating an Environment for Successful Projects. New
York: HarperCollins Publishers.
Graves, C.W. 1970. Levels of Existence: An open system theory of values. Journal of
Humanistic Psychology, 10(2):135.
Gray & Larson (2002). Project Management. New York: HarperCollins Publishers.
Grey, C. 1997a. Management as a Technical Practice: Professionalization or

Responsibilization? Systems Practice, 10(6):703-725.
Grey, C. 1998. On Being A Professional In a ‘Big Six’ Firm in Accounting. Organisations

and Society, 23(5-6):569-587.
Grint, K. 1994. Re-engineering History in Organisation.
Guest, D. 1987. Human Resource Management and Industrial Relations. Journal of

Management Studies, 24(5):503-21.
Gurley, J.G. 1965. Financial Institutions in the Saving-Investment Process. In Ketchum,

M.D. & Kendal L.T. (Eds). Readings in Financial Institutions. Boston: Houghton
Mifflin.
Gurley, J.G. 1996. The Market in Loanable Funds: Creation of Liquid Assets and
Monetary Control. In Carson, D. (Ed.). Money and Finance. New York: Wiley.
Hagan, F. 2000. Research Methods in Criminal Justice and Criminology. Boston: Allyn &
Bacon.
_____________________________________________________________________
_______________________________________________________________________________________________
Hales, C.P. 1986. What Do Managers Do? A Critical Review of the Evidence. Journal of
Management Studies, 23(1):88-115.
Haralambos, M. with Heald, R.M. 1985. Sociology: Themes and Perspectives. London:
Unwin Hyman Limited.
Handy, C. 1985. Understanding Organisations. London: Penguin Books.
Handy, C. 1995. Gods of Management: The Changing Work of Organisations. London:

Arrow.
Handy, C. 1999. Understanding Organizations. Penguin Books.
Harrison, F.L. 1981. Advanced Project Management. Aldershot: Gower.
Harrison, R. 1972. Understanding your organisation’s character. Harvard Business

Review, May–June:119-128.
Henriques, J., Hollway, W., Unwin, C., Venn, C. & Walkerdine, V. 1984. Changing the
Subject: Psychology, Social Regulation and Subjectivity. London: Methuen.
Hersey, P. & Blanchard, K. 1982. Management of Organizational Behavior: Utilizing

Human Resources. 4th edition. Engelwood Cliffs, NJ: Prentice-Hall Inc.
Herzberg, F., Mausner, B., & Snyderman, B.B. 1959. The motivation to work. New
Brunswick, NJ: Transaction Publishers.
Hofstede, G. 1991. Culture and Organisations: Software of the Mind. London: McGraw-
Hill.
Hofstede, G., Neuwen, B., Ohayv, D.D. & Sabders, G. 1990. Measuring organisational
culture: a qualitative study across twenty cases. Administrative Science
Quarterly, 35:286-316.
Hou, C.H., Sheang, L.K. & Hidajai, B.W. 1991. Sun Tzu: War and Management. World
Executives Digest, November:3-4.
_____________________________________________________________________
_______________________________________________________________________________________________
Hoy, W. K. & Miskel, C. G. 1991. Educational Administration: Theory, Research and

Practice. 3rd edition. New York: Random House.
Hughes. 1986. Why Projects Fail: The Effects of Ignoring the Obvious. Industrial
Engineering, 18(4):14-18.
Huysamen, D. 1996. Re-humanising the organisation. People Dynamics, 14(8):34-39.
IEEE. 1987. Standards for Software Management Plans. New York: The Institute for
Electrical and Electronic Engineers Inc.
Jacques, E. 1951. The changing culture of a factory. New York: Dryden Press.
Jackall, R. 1988. Moral mazes. New York: Oxford University Press.
Jahoda, M. 1979. The impact of unemployment in the 1930’s and the 1970’s. Bulletin of
the British Psychological Society, 32:309-314.
Johnson, T.J. 1972. Professions and Power. London: Macmillan.
Kantor, l., Schomer, H. & Louw, J. 1997. Lifestyle changes following a stress
management programme: an evaluation. South African Journal of Psychology,
27(1):16-21.
Kerzner, H. 2001. Project Management: A Systems Approach to Planning, Scheduling

and Controlling. 7th edition. New York: John Wiley & Sons Inc.
Knight. 1999. Neuro-Linguistic Programming. London: Harper Collins.
Kreps, G.L. 1998. Organisational Communication. 2nd edition. Longman: New York.
Kroeber, A.C. & Kluckohn, C. 1952. Culture: a critical review of concepts and definitions.
New York: Vintage Books.
Lamont, P. & Wiseman, R. 1999. Magic in Theory: An introduction to the theoretical and
psychological elements in conjuring. Hatfield, UK: University of Hertfordshire
Press.
_____________________________________________________________________
_______________________________________________________________________________________________
Lapin, L.L. 1987. Statistics for mordern business decisions. Harcourt Brace Jovanovich
Inc.
Lasley, J. 1999. Essentials of Criminal Justice and Criminological Research. NJ:

Prentice Hall.
Lessem, R. & Nussbaum, B. 1996. Sawubona Africa: Embracing four worlds in South
African management. Johannesburg: Zebra Press.
Lock, D.L. 1996. Project Management. Gower: London.
Longworth, G. 1992. A User’s Guide to SSADM: Version 4. Oxford: Blackwell.
Manning, T. 2001. Strategy. Cape Town: Zebra Press.
Maslow, A.H. 1943. A theory of motivation. Psychological Review, 50.
Maylor. 1996. Project management. 2nd edition. Pitman Publishing.
McComb & Smith. 1991. System Project Failure: The Heuristics of Risk. Journal of
Information Systems Management, 8(1): 25-34.
McConnell, S. 1998. Software Project Survival Guide. Redmond, Washington: Microsoft

Press.
McNay, L. 1994. Foucault: A Critical Introduction. New York: Continuum.
McWhinney, W. 1992. Paths of change: Strategic choices for organisations and society.
Newbury Park, CA: Sage Publications.
Metcalfe, B. 1997. Project Management System Design: A Social and Organisational

Analysis. International Journal of Production Economics, 52(3):305-316
Meredith, J.R. & Mantel, S.J. 2000. Project Management. 4th edition. New York: John
Wiley and Sons Inc.
Mintzberg, H. 1973. The Nature of Managerial Work. New York: Harper and Row.
_____________________________________________________________________
_______________________________________________________________________________________________
Mintzberg, H. 1975. The Manager’s Job: Folklore and Fact. Harvard Business Review,
July-August:49-61.
Mintzberg, H. 1979. The Structuring of Organisations. Upper Saddle River, NJ: Prentice
Hall.
Molnos, A. 1998. A psychotherapist's harvest.
Morgan, G. 1997. Images of organization. 2nd edition. Thousand Oaks, CA: Sage
Publications.
Morris, P.W.G. 1994. The Management of Projects. London: Thomas Telford.
Murphy, R. 1988. Social Closure: The Theory of Monopolization and Exclusion. Oxford:
Clarendon Press.
Myers, M.S. & Myers, S.S. 1974. Toward understanding the changing work ethic.
California Management Review, 16(3):7-19.
Nelson, D. (Ed.) 1992. A mental revolution: Scientific management since Taylor.

Columbus, OH: Ohio State University Press.
Neuman, L. & Wiegand, B. 2000. Criminal Justice Research Methods. Boston: Allyn &
Bacon.
Oakland, J. 1989. Total Quality Management. London: Heinemann.
Owens, R. 1994. Organisational Behaviour in Schools. Englewood Cliffs, New Jersey:

Prentice Hall.
Paconowsky, M.E. & O’Donnell-Trujillo, N. 1982. Communication and Organisational

Culture. The Western Journal of Speech Communication, Spring, 46:115-130.
Parker, I. 1989. Discourse and Power in Texts of Identity. Shotter, J. & Gergen, K.J.
(Eds). London: Sage.
_____________________________________________________________________
_______________________________________________________________________________________________
Patton, M.Q. 1990. Qualitative evaluation and research methods. Newbury Park, London
New Delhi: Sage Publications.
Peters, T.J. & Waterman, R.H. Jr. 1982. In search of excellence. New York: Warner.
Pietersen, H. 1991. Corporate Culture: clarification of a concept. Human Resource

Management, 6(10):26-31,
Pinto & Slevin. 2001. The Effective Manager. 1st edition. London: Sage Publications.
Porter, M. 1985. Competitive Advantage. New York: Free Press.
Raynor. 2001. In Kerzner, H. Project Management: A Systems Approach to Planning,

Scheduling and Controlling. 7th edition. New York: John Wiley & Sons Inc.
Reiss, G. 1996. The Delegation Model of Multi-project Management. AFITEP - Paris.
Reiss, G. 1996. Multi-project Scheduling & Management. World Congress on Project

Management, 26 June.
Reiss, G. 1996. Project Management Demystified. Chapman Hall.
Revell, J. 1973. The British Financial System. London: Macmillan.
Robbins, S.P. 1999. Downsizing of organisations – psychological aspects. Journal of

Management Education, February, 23(1):31-41.
Robbins, S.P. 2001. Organisational Behaviour. 9th Edition. New Jersey: Prentice Hall.
Roger, R.W. 1995. The Psychologecal Contract of Trust – part III. Executive
Development, 8(2):7-15.
Romberg.1998. Computing Canada. Plesman Publications, 9 November.
Rose, N. 1990. Governing the Soul: The Shaping of the Private Self. London: Routledge.
Rosenau, M. 1998. Successful Project Management. Van Nostrand Reinhold.
_____________________________________________________________________
_______________________________________________________________________________________________
Salant, P. & Dillman, D.A. 1994. How to conduct your own survey. John Wiley & Sons
Inc.
Schein, E.H. 1990. Organisational Culture and Leadership. San Francisco: Jossey-Bass
Publishers.
Schein, E.H. 1992. Organisational Culture and Leadership. 2nd edition. San Francisco,
CA: Jossey-Bass.
Schmickl, E. 1985. Organisational Culture. Unpublished Paper. Pretoria: S.B.L. UNISA.
Scotto, M. 1998. Chapter 13 - Project Resource Planning. Project Management

Handbook. Jossey-Bass Publishers.
Segall, M.A. 1984. More that we need to know about culture, but are afraid to ask.
Journal of Cross-Cultural Psychology, 15:153-162.
Selznick, P. 1957. Leadership in Administration. New York: Harper Row.
Senese, J. 1997. Applied Research Methods in Criminal Justice. Chicago: Nelson Hall.
Sergiovanni, T.J., & Corbally, J.E. (Eds.). 1986. Leadership and organisational culture.
Urbana, IL: University of Illinois Press.
Slack, N., Chambers, S. & Johnston, T. 2001. Operations Management. Prentice Hall.
Smith, J.M. 1988. Contemporary communication research methods: CA: Wadsworth

Publishing Company.
Smith, M. 1998. Training: A Manager's Perspective. Windows NT Magazine, March:15.
Smith, L. 1994. Burned or Bosses. Fortune, 25 July:108-113.
Smit, P. & De J Cronje, G.J. 1997. Management Practices. 2nd Edition. South Africa:
Juta.
Smith, P. 1971. Economics of Financial Institutions and Markets. Illinois: Irwin.
_____________________________________________________________________
_______________________________________________________________________________________________
Spector, P. 1981. Research Designs. Beverly Hills, CA: Sage.
Steinmann, N. 2002. In a Knowres team effectiveness seminar. As reported by Yvonne

Fontyn in Business Day 1st edition, 3 June.
Stevenson, W.J. 2002. Operations Management. New York: McGraw-Hill.
Stigum, M. 1983. The Money Market. New York: Irwin.
Stubbs, M. 1983. Discourse Analysis: The Sociolinguistic Analysis of Natural Language.

Oxford: Blackwell.
Schwalbe, K. 2002. Information Technology: Project Management. Canada: Course

Technology.
Tagiuri, R. 1968. The concept of organisational climate. In Tagiuri, R. & Lituin, G. (Eds).
Organisation Climate: Explorations of a Concept. Boston: Harvard Graduate
School of Business.
Taylor, F.W. 1911. The principles of scientific management. New York: W.W. Norton.
Thamhain, H.J. & Wilemon, D.L. 1986. Criteria for controlling software according to plan.
Project Management Journal, June:75-81.
Thomas, A. 1996. Beyond affirmative action: Managing diversity for a competitive

advantage in South Africa. Johannesburg: Knowledge Press.
Thompson, P. & McHugh, D. 1995. Work Organisations: A Critical Introduction. London:

Macmillan.
Thornhill, A., Lewis, P., Millmore, M. & Sauders, M. 2000. Managing change: a Human
Resource Strategy Approach. Harlow: Prentice Hall
Toffler, A. 1980. The Third Wave. London: Pan Books.
Townley, B. 1994. Reframing Human Resource Management: Power, Ethics and the
Subject at Work. London: Sage.
_____________________________________________________________________
_______________________________________________________________________________________________
Wastell, D.G. 1996. The Fetish of Technique: Methodology as a Social Defence.

Information Systems Journal, 6(1):25-40.
Weber, M. 1930. The Protestant ethic and the spirit of capitalism. Giddens, A. (Trans.).
New York: Routledge.
Weick, K. 1982. Administrating education in loosely coupled systems. Phi Delta

Kappan:673-676.
Weisbord, M. 1987. Organisational Diagnosis: A Workbook of Theory and Practice.

Reading: Addison-Wesley Publishing Company.
Wilkinson, A. and Willmott, H. 1995. Making Quality Critical: New Perspectives on

Organisational Change. London: Routledge
Winn, M.I. & Keller, L.R. 1999. Harnessing Complexity, Idiosyncrasy and Time: A
Modellling Methodology for Corporate Multi-Stakeholder Decisions. In Wood, D.J.
& Windsor, D. (Eds). International Association for Business and Society 1999
proceedings of the Tenth Annual Conference held in Paris, France, June:482-
487.
Winterboer, T. 2002. Strategic and Emerging Issues in South African Banking – 26 April
2002. PriceWaterhouseCoopers Inc.
Yourdon, E. and Becker, P. 1997. Death March: The Complete Software Developer’s
Guide to Surviving ‘Mission Impossible’ Projects. Prentice Hall Computer Books.
_____________________________________________________________________
_______________________________________________________________________________________________
INTERNET REFERENCES
Internet 1
Main Causes for Projects to Fail. [On-Line]. Available on the internet at:
http://www.jgaudio.com/Project_Defined.html#Main Causes for Projects to Fail
Unsuccessful IT Projects A Major Cost To Economy: KPMG. [On-Line]. Available on the

internet at:
http://ww2.newswire.ca/releases/November1997/05/c0838.html
www.it-cortex.com/stat-failure-rate.htm
(November 1997).
Internet 2
The Standish Group. (1998). Chaos. [On-Line]. Available on the internet at:
http://www.standishgroup.com/chaos.html
Internet 3
The Standish Group International, Inc. (January 1995). Chaos (Application Project and
Failure). [On-Line]. Available on the internet at:
http://www.standishgroup.com/chaos.html
Internet 4
McConnell, Steve. (September 1996). Classic Mistakes. [On-Line]. Available on the

internet at: http://www.construx.com/stevemcc
Internet 5
_____________________________________________________________________
_______________________________________________________________________________________________
KPMG. (October 1997). What Went Wrong? Unsuccessful Information Technology

Projects. [On-Line]. Available on the internet at: www.kpmg.com
Internet 6
Project Management Institute. (1996). A Guide to the Project Management Body of

Knowledge. [On-line]. Available on the internet at: www.pmi.org
(April 1998). Platinum Technology Delivers the Next Generation of its Development
Solution for Automating Business Rules in Enterprise Applications. [On-Line]. Available
on the internet at: http://nt.excite.com/news/bw/980415/platinum-aion
Bick, Julie. (1997). All I Really Need to Know in Business I Learned at Microsoft. [On-
Line].
Internet 7
Rosebeth Moss Kanter
Larry Greiner
Michael Porter
(June 1997). Available on the internet at: www.havanet.com/damarest/marc/dwpol.html
Internet 8
Joch, A. and Sharp, O. (December 1995). How Software Doesn't Work. [On-Line].
Available on the internet at: http://www.byte.com/art/9512/sec6/art1.htm
Internet 9
Pongpen Sutharoj. The Nation. (March 1998). Failed IT Project To Be Turned Into Case
Study. [On-Line]. Available on the internet at: http://www.ostc-
s.org/newsletter/0398_12.html
Internet 10
_____________________________________________________________________
_______________________________________________________________________________________________
Yourdon, E. (April 1997). Making Death March Projects Pay Off. [On-Line]. Available on
the internet at: http://www.datamation.com/PlugIn/issues/1997/april/04proj.html
Internet 11
Uhlfelder, Helene F., Ph.D. (1998). Teams: Why Are They So Difficult? [On-Line].
Available on the internet at: http://millerhoward.com/articles/whyteams.htm
_____________________________________________________________________

Practical Guide To Project Management

Uploaded by

Copyright:

Available Formats

Practical Guide To Project Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Practical Guide To Project Management

Uploaded by

Copyright:

Available Formats

Project

1. PROJECT MANAGEMENT OVERVIEW..........................................................4

2. THESE MODULES STRIVE TO PROVIDE YOU WITH: ..................................5

3. THE ELEMENTS AND SCOPE OF PROJECT MANAGEMENT .....................6

4. AIMS AND OBJECTIVES.................................................................................7

7. HOW DO WE RELATE PROJECTS TO OUR WORK? ...................................9

8. WHY HAVE PROJECTS? ..............................................................................13

9. THE PROJECT LIFE-CYCLE.........................................................................15

9.1 The project life cycle components explained: 20

9.2. Using the project life cycle 21

ALTERNATIVE SOLUTIONS .............................................................................30

PROPOSED SOLUTION ....................................................................................30

STATEMENT OF AUTHORITY ..........................................................................32

9.2.2. The Design Phase 42

Manage Project authorization 42

9.3.3 The implementation phase 113

Skills for managing a Project team 146

9.3.4 The Commission phase 160

COMPARISON OF PLANNED GANNT CHART VS THE ACTUAL GANTT

1. Project Management Overview

Sometimes the concept of project management may be misinterpreted as the mere

A further misinterpretation is to associate project management only with the field of

Marketing and Sales; Production or Operations Management and the practice of

2. These modules strive to provide you with:

• An explanation of project management and the role of the project manager

3. The Elements and Scope of Project Management

In 1976 an international institute known as the Project Management Institute (PMl)

4. Aims and objectives

In today’s competitive environment, project management is a useful skill for people

This way of working is becoming increasingly popular in organizations, and

7. How do we relate Projects to our work?

 Products or Services are what the organization is in business to make, sell or

 Facilities are required to produce products. Facilities may be factories,

 Projects are undertaken by organizations to deliver, construct, maintain or

Identify whether the following are projects or not by ticking in the

Writing monthly reports on the fifth of each month

Writing a unique company newsletter

Manage quality on the shop floor

Implement a company intranet from scratch

Install a security system in a branch office

Carry out a routine performance appraisals

Organise a sailing trip

Maintain the premises in good order

Identify whether the following are projects or not by ticking in the

Plan a wedding Yes

Writing monthly reports on the fifth of each month No

Writing a unique company newsletter Yes

Manage quality on the shop floor No

Implement a company intranet from scratch Yes

Install a security system in a branch office Yes

Carry out a routine performance appraisals No

Organise a sailing trip Yes

Conduct research Yes

Maintain the premises in good order No

8. Why have Projects?

 A business purpose, for example to increase profits, efficiency, turnover, or

 A social purpose, for example relaxation, enjoyment, fund-raising

 Humanitarian, for example flood disaster relief

 improve time management

Products or Services are what the organization is in business to make, sell or

Facilities are required to produce products. Facilities may be factories,

Projects are undertaken by organizations to deliver, construct, maintain or

A business purpose, for example to increase profits, efficiency, turnover, or

A social purpose, for example relaxation, enjoyment, fund-raising

Humanitarian, for example flood disaster relief

improve time management

deliver a one-off solution

give better control

improve risk management

improve ability to meet expectations

improve quality, and

participate in productive cross-functional communication

A business purpose, for example to increase profits, efficiency, turnover, or

A social purpose, for example relaxation, enjoyment, fund-raising

Humanitarian, for example flood disaster relief

improve time management

deliver a one-off solution

give better control

improve risk management

improve ability to meet expectations

improve quality, and

participate in productive cross-functional communication

Present proposal flow ecast/control: project team

Why the project is being undertaken?

What is the purpose of this project?

What is the deliverable of this project?

What are the objectives and outcomes?

How are we going to undertake this project? What is the process?

What are the tools and techniques we can use?

What is the concept of this project?

What predefined output rate is required for the product?

What conditions must the product operate under?

What is the minimum life expectancy of the product?

What are the budget constraints and limits?

Priorities and authority levels

Meet with stakeholders to establish their criteria for success.

Design measurement instruments for each outcome, by stakeholder

When reporting progress to each stakeholder, do so in terms of progress towards