project management guide

_____________________________________________________________________ Designed by: Dr D M Laxton ©

Project

Management

By: Dr Dennis Laxton

Project Management Module _______________________________________________________________________________________________

_____________________________________________________________________ Designed by: Dr Dennis Laxton © of 236

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



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.



Question

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

appropriate box.

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

???



Answers

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

appropriate box.

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

???



Question

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.

???



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



? Think point Question

Review the above information and analyse which of the identified

benefits of a project approach will help you to achieve in your own

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

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



Question

Review the above information and analyse which of the

identified benefits of a Project approach will help you to

achieve in your own Projects.

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

Lev

el o

f effo

rt

L

ow

Hig

h

Project identification and concept

Design Implementation Commission

Input Input Input Input

Problem or

Opportunity,

project brief,

project charter

Approval to go

ahead and

design the

product

Approval to implement

the project

Commissioning

plan, notification of

completion

Process Process Process Process

Project

identification and

proposal,

feasibility study,

identify

stakeholders,

cost-benefit

analysis;

Assign project

manager; Decide

on the

appropriate type

or organisation

Detailed scope

design and

definition

through the

application of a

work breakdown

structure (WBS),

Design the

product, develop

detailed

schedules, CPM

and budgets

Award contracts and

issue instructions,

procure equipment and

services, make the

product or solve the

problem

Start up and test

the product, has

the problem been

solved?

Produce as-built

drawings and

operation manuals

Accumulative Effort over the life of a project

The time frame of the project Start Finish



breakdown

structure (OBS) to

use;

create a

responsibility

matrix.

Key Activities Key Activities Key Activities Key Activities

The key activities

may be

environmental

impact studies or

market research.

Key activities

may be certain

specific design

requirements or

systems and

standards to

comply with.

Key activities may be

compliance to certain

legislation or standards

imposed on the project.

Key activities are

usually based on

methods to

evaluate the

implementation of

the contractual

terms and

conditions.

Hold Points Hold Points Hold Points Hold Points

1. Approval of the

factors affecting

the concept, such

as: environmental

impact analysis,

marketing

research,

Shareholder

approval, etc.

1. Approval of

the detailed

scope

documents,

Approval of

design

standards and

specifications as

well as the final

plans and

designs. This

may be the

approval of a

third party such

as the Council,

etc.

1. These could be

quality sign-off’s or

check points as the

project progresses.

They will be used to

verify if work is to

proceed or not.

1. These are

usually the

customers sign-off

and the final

delivery documents

or manuals, etc.

Objectives Objectives Objectives Objectives



1. To ensure the

projects

support the

strategies

2. To ensure the

Organisation

has the

appropriate

resources to

be able to

complete the

projects

3. To ensure the

concept is

clearly defined

and adds

value to the

organisation

1. To ensure

the work is

structured

correctly in

similar

packages of

work.

2. To ensure

the design

work is

linked to the

concept and

done in

accordance

with set

design

parameters

and

specification

s.

3. To ensure

accurate

time

schedules

are drawn up

and the

correct

resources

are assigned

to the work.

1. To ensure clear

objectives have

been set for

monitoring the

schedules success.

2. To ensure effective

feedback and

measurement

techniques are in

place.

3. To ensure any

deviations from the

schedule are

recorded and

deviation requests

are completed.

1. To ensure there

is a formal

close-out

meeting and

hand-over.

2. To ensure the

contractual

conditions are

audited and the

user signs the

project off.

.

Output Output Output Output

Feasibility study

report

Baseline plan Certificate of

completion

Close out report

Approval Approval Approval Approval



Go/No go

decision, to

proceed with

design phase

To implement

project

Ready to commission Project accepted by

client

9.1 The project life cycle components explained: Figure 2: Project Life Cycle explained

PLANNING

ACCOMPLISH

Phase 1

Project

identification and

concept

(Conceive)

Phase 2

Design

(Develop)

Phase 3

Implementation

(Execute)

Phase 4

Commission

(Finish)

1 Gather data

2 Identify need

3 Establish

4 Goals and

objectives

5 Basic

economics,

feasibility

6 Stakeholders

7 Risk level

8 Strategy

Potential team

Guestimate

resources

Identify

alternatives

Appoint key

team

members

Conduct

studies

Develop

scope

baseline:

end products

quality

standards

resources

activities

establish:

master plan

budget, cash

Set up:

Organisation

Communications

Motivate team

Detail technical

requirements

Establish :

Work packages

Detailed schedule

Information

control systems

Procure goods

and services

Execute work

packages

Direct/monitor/for

Finalize

products

Review and

accept

Transfer

product

responsibilit

y

Evaluate

project

Document

results

Release/red

irect

resources

Reassign



Present proposal

Obtain approval

for next phase

flow

WBS

Policies and

procedures

Assess risks

Confirm

justification

Present

project brief

Obtain

approval to

proceed

ecast/control:

Scope

Quality

Time

Cost

Resolve problems

project team

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

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

Shareholder 1

Stakeholder 1 Stakeholder 2

Shareholder 2

Project name

Outcome

Outcome

Outcome

Outcome



extension of your home, a systems installation in your workplace, etc. Now complete the

table below.




For a project applicable to your personal or work life,

Identify the shareholders and stakeholders

Identify the output or outcome desired by each of them.

Shareholder Desired Outcome or Output

Stakeholder Desired Outcome or Output




Refer to the Glossary at the back of this Programme, and find

definitions for the following:

Term Definition

Sponsor

Project Manager / Leader

Team members

Customer

Line Managers of

team members

Stakeholder



Question

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.

? Think point

???



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 (Low, medium or high)

Impact (Low, medium or high)

1

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

Yellow Boxes

Represent Staff

Involved in project

activities

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

CEO

Functional Manager

Functional Manager Functional

Manager

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff



• 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 Activity

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,

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

Checklist is categorised by types of risks. It contains risks

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

Detail Design

Project Management

Product Requiremen

ts

Detail Design Construction Integration and Test

Planning Software Software Software Software

Meetings User Documentatio

n

User Documentatio

n

User Documentatio

n

User Documentatio

n

Administration Training Program Materials

Training Program Materials



. Sample Work Breakdown Structure Organised By Phase

• 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 An Intranet WBS OrganisedOrganised by Phaseby Phase



Figure7: A detailed example of a WBS by Product

An Intranet WBS An Intranet WBS OrganisedOrganised by Productby 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

Members Project Manager

Business Owner

Project Stakeholders

Project change

identification

(complete change

request form)

P P P P

Screen request for

reasonableness &

determine effort

required to evaluate

impact to project

P P

Conduct informal

interview with client to

determine whether

further handling of the

request is warranted

P A

Record change and

monitor status on

change control log

A P

If approved for

investigation by client,

prepare cost/schedule

impact assessment -

communicate impact

to client

The person the project change is assigned to will be accountable.

This person may be from any of these areas and may seek

participants from any of these areas.

Project change

solution

approved/rejected

A A S A

Modify project

baseline and work

papers as required

A P

Do required work A P A A



Project change

resolution

implemented

The person the project change implementation is assigned to will

be accountable. This person may be form any of these areas or

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

.

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

WBS

1.1 1.2

1.1.1 1.1.2 1.2.1 1.2.2

Civil

Elec.

Mech. OBS



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

Resource

utilisation

By the 1st of each

month

Monthly report

Team (whole

group)

Get feedback

Report progress

Third Monday

each month

Team meeting

Administrative

staff

Project news Quarterly Company

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:

Plan, monitor and manage the time dimension

Plan, monitor and manage the quality dimension

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

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.

PROJECT PARAMETERSPROJECT PARAMETERS

Specifications

QUALITY

Budget

COST

Schedule

TIME

PROJECTPARAMETERS



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 Float = late

start – early

start

ACTIVITY NUMBER DESCRIPTION

DURATION

LATE START Late start = late

finish –

duration + 1

LATE FINISH



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 (average) Time (Tm) in days

PREDECESSOR ACTIVITY SUCCESSOR ACTIVITY

A

(Design the

landscape)

2 Days - B,C,D

B

(Prepare back of park)

3 Days A E

C

(Prepare front of park)

4 Days A E

D

(Order plants)

2 Days A F

E

(Add compost to land)

2 Days B,C G

F

(Prepare the plants)

3 Days D G

G

(Plant)

3 Days E,F -



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

1 2 A 2Days

3 6 C 4 Days

3 4 D 2 Days

7 8 E 2 Days

9 11 G 3Days

3 5 B 3 Days

5 7 F 3 Days

At a junction, take the highest Early finish value, i.e. 6



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.

1 2 0 A 2Days 1 2

3 6 0 C 4 Days 3 6

3 4 1 D 2 Days 4 5

7 8 0 E 2 Days 7 8

9 11 0 G 3Days 9 11

3 5 1 B 3 Days 4 6

5 7 1 F 3 Days 6 8

Use lowest Late Start at junction

Critical Path (Longest path)



Calculations for the above network diagram. (Early start and Early Finish). Start by letting the early finish = late finish

Activity Late Start Late Start = Late finish - duration +1

Late Finish

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 NUMBER

RESSOURCE TYPE

QUANTITY PER DAY

RESSOURCE DURATION

LEAD 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 NUMBER

RESOURCE TYPE

QUANTITY PER DAY

RESSOURCE DURATION

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

ID Task Name Duration1 RESOURCE LEVELLING 3d

2 TASK 1 1d

3 TASK 2 2d

4 TASK 3 3d

5

6

DENNIS

DENNIS

DENNIS

W T F S S M T W T F S S M T W T F S Sec '97 28 Dec '97 4 Jan '98



Resource Graph or Histogram for the Resource Dennis as Scheduled on the above Gantt Chart

50%

100%

150%

200%

250%

300%

% Work Allocated:

Dennis Overallocated: Allocated:

F S S M T W T F S S M T W TDec 28, '97 Jan 4, '98

300 200 100

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)

ID Task Name Duration1 LEVELLED PROJECT 6d

2 TASK 1 1d

3 TASK 2 2d

4 TASK 3 3d

DENNIS

DENNIS

DENNIS

W T F S S M T W T F S S M T W T F S Sec '97 28 Dec '97 4 Jan '98



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.

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

DENNIS Overallocated: Allocated:

M T W T F S S M T W T F S S M T28 Dec '97 4 Jan '98 1

100 100 100 100 100 100

• 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 INTEAM)1 7d29/12/97 6/1/98 17

GARDEN3

4 3d31/12/97 2/1/98 17

GARDEN4

5 1d5/1/98 08 5/1/98 17

GARDEN5

6 2d5/1/98 08 6/1/98 17

GARDEN2

3 1d31/12/97 31/12/97

GARDEN1

2 2d29/12/97 30/12/97

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.



ID Task Name Dur Pred Succ1 GARDENS (5 IN TEAM) 7d2 GARDEN 1 2d 3,43 GARDEN 2 1d 2 54 GARDEN 3 3d 2 5,65 GARDEN 4 1d 4,36 GARDEN 5 2d 47

8

9

10

11

12

GARDEN TEAM[5]

GARDEN TEAM[4]

GARDEN TEAM[3]

GARDEN TEAM[5]

GARDEN TEAM[5]

T W T F S S M T W T F S S M T W Tec 28, '97 Jan 4, '98 Jan 11, '98

o The unlevelled Histogram (Maximum Men In The Team Is 5)

1

2

3

4

5

6

7

8

9

10

Peak Units:

GARDEN TEAM Overallocated: Allocated:

T W T F S S M T W T F S S M TDec 28, '97 Jan 4, '98 J

5 7 3 3 10 5

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’

ID Task Name Dur Pred Succ1 GARDENS (5 IN TEAM) 9d2 GARDEN 1 2d 3,43 GARDEN 2 1d 2 54 GARDEN 3 3d 2 5,65 GARDEN 4 1d 4,36 GARDEN 5 2d 47

8

9

10

11

12

GARDEN TEAM[5]

GARDEN TEAM[4]

GARDEN TEAM[3]

GARDEN TEAM[5]

GARDEN TEAM[5]

M T W T F S S M T W T F S S M T WDec 28, '97 Jan 4, '98 Jan 11,

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.

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

4.5

5.0

GARDEN TEAM Overallocated: Allocated:

S M T W T F S S M T W T F S S M28 Dec '97 4 Jan '98

5 5 3 3 3 4 5 5 5



• 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

HIRE TRANSPORT TOTAL

100 Mark out

foundations R1,000 R500 R1,500

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.

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.

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.

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 Number

Objective Date Completed

Signed By Signature



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 Number

Variation Date Authorised

Authorised By

Signature

Completed: Signed by

Completed: Signature



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 Number

Variation Completed Y/N?

Signed By Signature



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

Activity

Description

Planned

Predecessors

Actual

Predecessors

Planned

Successors

Actual

Successors

Planned

Duration

Actual D

uration

Possible

Reason

for

Variations.



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

Activity

Description

Planned

Predecessors

Actual

Predecessors

Planned

Successors

Actual

Successors

Planned

Duration

Actual

Duration

Possible

Reason

for

Variations.

Activity Activity Description

Variation

Reason for Variation

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


Variation in Resources

Reason for Variation

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


Reason for Variance Possible changes



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 performance

Reason for better performance

How can this 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 area with problem

Problem that occurred

Corrective Action taken

Suggestion to prevent problem occurring in 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 method?

Continue to utilise 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

Education

Three year

degree/Diploma

Primary

School

Postgraduate

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

project management guide

Documents