REFERENCE MANUAL

if:, i or scli '.E* •04 ,0-iir,

st Ar

• dr --

411041.6/41;":5 ‘..47. "f:eilre:40-1:441::: 44:41.141.1144,311:(1111 1 '11:11.44)119- • lir

I. .0.

* 'k • .4,

f 4, r t 0.5! 444Skitv' tv

e

il 144 a Ne 7 41/4' 4 ' . 40. L 1 s., .4 • ' 0 '

7:. • 0

-AV, 40,44 iftiq..16 *'" 3-

f It 17%%

PROJECT MANAGEMENT ,,,,„744, NSW DEPARTMENT OF WATER RESOURCES Resources

PROJECT MANAGEMENT

REFERENCE MANUAL

• CONTENTS

SUMMARY 2

GLOSSARY OF TERMS

INTRODUCTION

WHAT IS A PROJECT?

4

6

7

2.1 Definition of a project 7

2.2 Types of projects 8

2.3 Results wanted from projects 8

2.4 Projects within projects 9

WHERE DO PROJECTS COME FROM? 10

3.1 The Client 10

3.2 Where does Project Management begin? 10

4 WHY DO PROJECTS FAIL? 11 • MANAGING A PROJECT 12

5.1 General 12

5.2 The Role of the Project Director 12

5.3 The Role of the Project Manager 15

5.4 The Role of the Unit Manager 16

5.5 The Role of Project Officers 16

5.6 The Role of the Project Review Board 16

5.7 The Role of the Steering Committee 17

5.8 Documentation of the Project 18

5.9 Managing Conflict 18

5.10 Good Project Management 20

REFERENCE MANUAL

PLANNING A PROJECT 21

6.1 General 21

6.2 A Life Cycle 21

6.3 Work Breakdown Structure 23

6.4 Project Responsibility Chart 25

6.5 Networks 25

6.6 Bar Charts 26

6.7 Estimating 27

6.8 Accuracy in Estimating 27

6.9 Value Management 28

PROJECT CONTROL 30

7.1 The Control Process 30

7.2 Project Meetings 32

PLANNING AND CONTROL 33

- WHAT GOES WRONG?

8.1 General 33

8.2 Action for out of control projects 35

EXPEDITING A PROJECT 37

COMPLETING A PROJECT 38

APPENDICES 40

1

8

10

•

PROJECT MANAGEMENT SUMMARY

ORGANISATION ARRANGEMENTS

CI Management of a project is initiated by a

Project Director who establishes the

team responsible and oversees its progress.

71 Within a Division each project is managed

by a Project Manager who is respon-

sible for planning the project and managing

it to achieve its objectives according to

agreed time, cost and standard.

71 Where several Divisions are involved with

a project, each Division may appoint a

Project Manager one of whom will be

the Co-ordinating Project Manager.

11 The Project Director and the Project

Managers comprise the Steering Corn-

mittee. It must not be confused with the

Project Review Board.

O Project Officers assigned to carry out

project work are accountable to the Project

Manager for carrying out that work and are

accountable to their Unit Managers for

technical standards and administrative

matters.

O Unit Managers have the functional

role of ensuring that necessary skills are

developed and are available and that appro-

priate standards are set and achieved for

the expertise that their Unit provides. It is

important to recognise that Unit Managers

are the ultimate authority for the expertise

under their control.

O Project Review Board. Important

projects will have formal PRB's to see that

things are going as they should and appro-

priate standards are being met. The pri-

mary role of the PRB is control. It is not

another project team and must not func-

tion as such. It must not be confused with

the Steering Committee.

PLANNING PROJECTS

O Objectives. A statement of why the

project is being undertaken and what it is

that will be achieved, is essential.

O Lifecycle. The over-all Project is planned

with the aid of the , Lifecycle which

describes the phases that most systems tend

to follow during their life. Proper planning

and evaluation must consider all phases,

not just the phases prior to operation.

O Work Breakdown Structure

(WBS). A methodical listing of the

activities to be undertaken. At a high level of

planning this would go as far as major pieces

of work, often called "work packages",

which can be handed over to a Unit or a Pro-

ject Officer. For more detailed functional

level planning, the work packages would be

further broken down into smaller tasks.

O Project Responsibility Chart. This

lists the activities or work packages of a

project plan and describes the level of

responsibility of the Units involved in the

project.

El Estimates. Estimates of the required

resources, time and costs must be pre-

pared. Ensure that time for any activity is

expressed in lapsed-time and not work-

time or EFT's.

2 3

O Network. Networks (CPM, PERT etc)

show the logical relationship of the activ-

ities identified in the WBS. They are

fundamental to the operation of planning

software packages. If software is not used

the network must be drawn by hand.

O Bar Chart. Bar Charts are required to

show the project schedule and to develop

resource profiles, cash flows and budgets.

Planning software will generate Bar Charts

automatically but if software is not avail-

able, standard pro-formas may be used.

CONTROLLING PROJECTS

O Control means keeping the project on

track according to time, standard and bud-

get. Where a deviation between the

planned situation and the actual situation

is identified, corrective action may be nec-

essary to put the project back on course.

O Planning and re-Planning. A project

cannot be controlled unless a reasonable

project plan exists so that planned achieve-

ments can be compared to actual

achievements

O Project Review Board. A PRB may be

established to oversee the progress of the

project and to identify where progress is

not going according to plan.

CI Project Control File. Items relating to

the overall project should be placed on one

file. Other matters may be placed on sub-

files. Typically matters on the Project

Control File would include:

• The clients requirements

• The project plan

• Estimates of costs

• Amendments to the project plan

• Dealings with the client

• Budget allocations

• Project reports

• Project Review Board proceedings

0 Reporting. Reports will be required reg-

ularly on the progress of the project to:

• The Project Director

• The Client

• The Project Review Board.

DOCUMENTING A PROJECT

71 Calculations, data, records of discussions,

sketches, etc. are maintained on Technical

Files by the Project Manager and Project

Officers as appropriate.

FINALISING A PROJECT

[71 Project work is complete when:

• All work required has been completed

• Technical Files have been finalised

• A report on the project work has been

completed

• A summary statement of the cost of the

project has been prepared and placed on

the Project Control File.

STAGE

STEERING COMMITTEE

TARGET

TASK FORCE

UNIT MANAGER

PROJECT MANAGEMENT SYSTEM (PMS) The interrelated systems that together enable the

conduct of project work.

PROJECT MANAGEMENT INFORMATION Information system on project activity

WORK BREAKDOWN STRUCTURE (WBS)

and performance. SYSTEM (PMIS)

4 5

REFERENCE MANUAL

Graph showing the duration of activities located in

calendar time. Also called Gannt Chart.

A technique using networks to plan a project, iden-

tify critical activities and allocate resources.

Equivalent full-time person: net of recreation, long

service and study leave, holidays etc.

Manager in charge of a Unit providing specific

expertise.

See Bar Chart

Development of a project from conception to

termination.

Events within a project plan which serve as key indi-

cators of planned progress.

Graph showing sequence and logical relationships

between activities in a project. Also known as PERT

Diagram, CPM Network, Precedence Diagram.

Specifically the "Project Evaluation Review Tech-

nique" but often applied to any network-based

planning technique.

A division of the project Lifecycle.

The officer responsible for initiating and co-

ordinating project planning and overseeing the man-

agement process.

Officer in charge of the project ; responsible for plan-

ning and managing the progress of the project.

Officer of a functional unit responsible for the per-

formance of some aspect of project work.

Schedule showing Units involved in a project and

the level of involvement.

Committee established to review the project plans,

quality standards, progress and cost. Not to be con-

fused with the Steering Committee.

The project officers assigned to the project, respon-

sible to the Project Manager for management

aspects of the project but responsible to their Unit

Managers for technical and administrative aspects.

A major division of a project which may be time or

geographically based. Not to be confused with

Phase.

The Project Director and the various Project Man-

agers responsible for the management of the project.

Not to be confused with the Project Review Board.

A Milestone and its expected date of completion in

the project schedule.

Project Officers assigned to work full-time on a pro-

ject under direct management and administrative

control of the Project Manager. Technical control

may still be exercised by functional managers.

See Functional Manager

Breakdown of work activities from the major stages

of a project into "work packages" which can be

handed over to functional Units or specific indi-

viduals for planning, estimating and executing.

Project work which may be handed over to one indi-

vidual or one Unit.

GLOSSARY OF TERMS PROJECT OFFICER

PROJECT RESPONSIBILITY CHART (PRC)

PROJECT REVIEW BOARD (PRB)

PROJECT MANAGER WORK PACKAGE

BAR CHART

CRITICAL PATH METHOD (CPM)

EFT

FUNCTIONAL MANAGER

GANNT CHART

LIFECYCLE

MILESTONES

NETWORK

PERT

PHASE

PROJECT DIRECTOR

PROJECT TEAM

REFERENCE MANUAL

lou INTRODUCTION

WHAT IS A PROJECT?

4p.

0 •

Much of the work of the Department is carried

out in the form of projects: non-routine activ-

ities directed towards specific objectives.

The past functions of the Department (as the

Water Resources Commission or the Water

Conservation and Irrigation Commission)

involved it in major water conservation

projects requiring considerable project man-

agement expertise.

Today the Department is dealing with projects

which are often multidisciplinary in nature

and cross Unit and Divisional boundaries. Pro-

jects are often small to medium in scale but

complex. More consideration needs to be given

to secondary impacts and impacts outside the

Department. Sound project management is

still important.

These procedures formalise much of what

would be regarded as good project practice. But

without formal processes, good practice has

often lapsed in the face of urgency or expe-

diency. The objective is not to tie officers up in

"red tape" or time wasting administration. It is

to encourage well thought out, efficiently man-

aged and well documented projects.

Like anything new the procedures may seem

awkward at first and the temptation to fall

back on old ways of doing things will be

strong. Success will require the support of eve-

ryone involved. This will be essential if the

Department is to be business-like and effi-

cient in the way it functions and in the

"product" it delivers.

2.1 DEMI-MON OF A PROJECT

Put simply a project is:

"A collection of activities carried out to

achieve a specific objective".

A project is something different to routine,

repetitive work. It is to a greater or lesser

degree unique and is intended to bring about a

change in existing circumstances. A project

requires concentrated effort and very often

creative processes because the project will be

something new: nothing has been done

exactly like it in the past.

REFERENCE MANUAL

ft-

Projects are very often multidisciplinary in

nature (engineering, economics, environment,

finance, human resources etc.) and sometimes

extremely complex. The scale may vary from

work done by one person to the work of tens of

thousands of people.

2.2 TYPES OF PROJECTS

Five types of project may be identified:

CI Construction

Design and construction of buildings, roads,

factories, dams, bridges, machines, etc.

11 Manufacturing

Design and development of products for

manufacturing.

Research & Development

The carrying out of research into unknown

areas to develop new materials, processes,

systems etc.

11 Management

Promotional activities, organisational

activities etc.

Information Systems

Computer-based systems for collecting,

storing and reporting on information.

Apart from manufacturing, the Department is

involved in all of the above projects. Each tends

to have its own traditions, approaches and ter-

minology. However, basic principles tend to be

the same. This manual will be general in its

orientation and the procedures described may

be usefully applied to any project of any scale.

However, it is not expected to replace specific

PMS's established for specific types of pro-

jects. For example, SPECTRUM has been

designed for use in information system pro-

jects and should perform that job better than

the more general procedures of this manual.

Of course, SPECTRUM would not be

expected to work very well in the design and

construction of a dam.

2.3 RESULTS WANTED FROM PROJECTS

To clearly identify the results wanted from a

project, it is important to focus on the "prod-

uct" of a project rather than the project work

itself. The project has been initiated with some

objective in mind, whether this be a dam, a

more efficient work process or a computerised

accounting system. Always keep this objective

in mind and make sure it is understood by eve-

ryone engaged in the project.

For example, you may be involved in designing

a dam but is the "product" a dam? Is it not regu-

lated flow? Is not the desired end-result increased

agricultural production or better flood protection?

Of course by the time you are involved, these

questions may already have been answered. A

decision has been made to build a dam on a

specific river and at a specific site. Your part

in the project is to get the dam designed and

built to an appropriate standard, within bud-

get and within time.

Time, cost and quality (TCQ) are interrelated

but the client may place more importance on

one requirement than the others. There may

be a limited budget. There may be strict dead-

lines to meet. A certain standard or quality

may be required. This must be viewed from

the client's perspective. For instance:

A quick job may cost more in cash but it

may be economically beneficial for the

client to have it done this way. The system

would in place and functioning at an ear-

lier date.

71 A higher standard job will normally cost

more and/or take a longer time but may be

more productive with less maintenance

and repairs.

Project costs may decline as more time

becomes available to do the work ; but only

up to a certain point. Eventually waste,

overheads, change of personnel, etc. will

make a drawn out project more expensive.

There is an optimum point.

2.4 PROJECTS WITHIN PROJECTS

It is easy to think of projects as sub-projects of

larger projects. Someone designing a bridge across

a channel forming part of a drainage scheme will

reasonably see it as a project in its own right.

The bridge is a sub-project of a sub-project (the

channel) of a project (the drainage scheme).

Looked at in this way, sub-projects may be

nested quite deeply. We may well end up deal-

ing with sub-sub-sub-projects etc. and this

would become unwieldy and confusing. Sub-

projects would tend to take on a life of their own

and the overall project objectives can be lost.

From the Department's point of view, the pro-

ject must be defined at as high a level as possible

and sub-projects treated as project work pack-

ages. Avoid the creation of sub-projects. Keep

everything relating to a particular project under

one management structure: one Project Direc-

tor: one Project Manager per Division: one

Project Review Board.

Major projects may be broken into stages: a

staged project is one which is broken into sev-

eral more major divisions which may be

developed and implemented independently.

The basis of the division may be function, time

or location. An example is the division of a

drainage scheme into major drainage basins.

Project work can proceed on these stages in

parallel or sequentially. Large projects, or pro-

jects whose development will take a long time,

may be broken into stages from the point of

view of project management and each stage

treated as an individual project. But care is

needed to keep the objectives of the total pro-

ject in view and the project as a whole under

one management.

(Do not confuse a project Stage with a project

Phase. A Phase refers to the location of the

project in its Lifecycle. A Stage is a major divi-

sion of the project work. It does not refer to

the Lifecycle.)

we"

a•lr

8

9

REFERENCE MANUAL

171 WHY DO PROJECTS FAIL?

WHERE DO PROJECTS COME FROM?

0•21r.

%b.

3.1 THE CLIENT

Projects originate with somebody's desire to do

something new or bring about a change to an

existing situation. Without this desire all our

activities would be routine administrative

ones; the outcomes of past projects.

That somebody may be referred to as the Client.

This Department will generate projects, directly

from its strategic planning process, or indirectly

from its programs. Clients external to the Depart-

ment may also want projects undertaken. In

either case the Project Manager will be respon-

sible for satisfying the client's requirements.

Projects may occur at different levels in the

organisation. The Executive may want a pro-

ject undertaken and delegate the res-

ponsibility to the Project Director. A Unit

Manager or supervisor may want a project

undertaken to achieve a goal of the Unit Busi-

ness Plan. The Project Director, Unit

Manager or supervisor stand in the position of

the client for the project.

It is vital to the success of the project to gain a

good understanding of the client's require-

ments. A lot of work and money may be

wasted if this understanding is not established

as first priority in the project. This task may

not be easy; the client may be vague about

what is required or may not even know. It may

take some to-ing and fro-ing to establish clearly

the project objectives.

Note that the client will expect that oral infor-

mation, given informally early on in the project,

will be understood and assimilated. On the

other hand, you may be totally confused and

overwhelmed with detail. It is therefore advis-

able to commit all dealings with the client, even

telephone conversations, to writing and place

your notes on the Project Control File. If the

client does not provide a clear brief, write your

own and confirm it with the client.

3.2 WHERE DOES PROJECT

MANAGEMENT BEGIN?

Project management begins at as high a level as

possible. The total system must be defined and

justified initially before detailed work on sub-

systems may begin. In large complex systems,

this is usually a complex and difficult task and

a major cause of problems and poor per-

formance. In any system design there are two

major sources of error:

El Sub-optimisation - optimising the per-

formance of a sub-system to the detriment

of the system as a whole.

71 Failure to take account of inter-

relationships and secondary effects among

a system's sub-systems and components.

For any large complex project to proceed with-

out change in plans, mistakes, problems in

bugeting and performance is perhaps unusual.

In projects of high risk, it is a miracle if they

even come close. There are a large number of

factors which have the potential to cause a pro-

ject to fail. A summary and incomplete list

includes:

II Not meeting the client's require-

ments: mostly due to poor objectives

resulting from poor communications.

El Poor planning: unclear objectives ; poor

communication of objectives ; lack of con-

sideration of broad systems aspects ; not

considering all Phases in the Lifecycle of

the project.

El Poor estimating: not considering risk ;

poor estimating of money, resources and

time.

CI Failure to control: failure to monitor

the progress of the project, to relate actual

achievement to planned progress and to

take corrective action where necessary.

CI Failure to document: absent or sloppy

documentation gives rise to uncertainty,

repetition and inability to learn from mis-

takes.

LI Delegation to unqualified people:

delegation is often a good management

practice but it is not abdication.

El Undefined responsibilities: respon-

sibility for each aspect of the project must

be specified and communicated.

El Unclear objectives:it is essential to be

very clear about what the project is to

achieve.

El Not finding the "best" solution:

this failure may not even be recognised.

Just because a project is completed within

time, budget and standard, does not nec-

essarily mean that the best solution or plan

was adopted.

Two traps must be clearly recognised.

[I A tendency to want to jump quickly over

consideration of alternatives. Most of us

want to get on with the job. This can mean

unclear objectives, not considering all the

implications and failing to find the best

solution.

El A tendency to forget about risk once a deci-

sion has been made. The risk does not go

away and it should be explicitly recognised

in estimating and with contingency plans.

Finally, beware of the optimistic estimator.

Most people will greatly under-estimate the

time and cost factors. Generally they will be

quite consistent in doing this and a Project

Manager must learn to factor estimates up to a

more realistic level.

10

11

.011,

•■•■•■

F-1

LC)

a) b.o

1

■•••••••0

71" N-1

0/3

13

MANAGING A PROJECT Figure I

MATRIX STRUCTURE PROJECT MANAGEMENT

5.1 GENERAL

Many Department projects will be managed

within the boundaries of a functional Unit

and will not impinge greatly on other Units.

Some projects will be broader in scale and will

require input from several functional Units.

The latter situation results in a matrix organ-

isational structure as shown in Figure 1.

Alternatively, in the case of a particularly

urgent or important project, the project may

be undertaken by a special Task Force - the

resources required will be devoted solely to

the project under the direct control of the

Project Manager.

In most cases there will be a Project Direc-

tor who has responsibility for initiating a

project and maintaining a general oversight

of its progress.

In all cases, project work will be managed by a

Project Manager who will be the person

accountable for the project plan and project

control. The Project Manager must negotiate

with Unit Managers in the development of pro-

ject plans, schedules, allocation of resources

and performance standards.

For projects which cross Divisional boun-

daries, there may be a Project Manager in each

Division to manage the components of the pro-

ject within that Division and provide the

communication links across Divisions. In such

cases, a Co-ordinating Project Manager may be

required to co-ordinate the process. This func-

tion will be delegated by the Project Director to

one of the Divisional Project Managers or to

someone else.

Where the term "Steering Committee" is used

it will be applied to the combination of Project

Director, Divisional Project Managers and oth-

ers, who are together responsible for managing

the project. It must not be used to describe a

group with review functions since this is the

role of the Project Review Board.

For major or important projects, a Project

Review Board (PRB) may be established. The

function of the PRB is to provide an inde-

pendent assessment of the project: its plan,

budget, performance, progress and any

changes to these. Approval by the PRB is an

indication to the Executive that all is well

with the project.

It is particularly important to recognise the role

of the Unit Manager in this process. The Unit

Manager Is considered to be the ultimate

source of advice to the Department on the

expertise represented by the Unit. No project

can be considered sound if Unit Managers do

not support its technical work.

The general relationships of the project man-

agement process and the officers involved is

shown in Figure 2.

5.2 THE ROLE OF THE PROJECT

DIRECTOR

Project Directors are responsible for:

• Initiating a project.

• Overseeing the progress of the project.

• Deciding on the PRB.

• Chairing the PRE.

• Dealing with conflict.

12

Project Director

Figure 2

THE PROJECT MANAGEMENT PROCESS

Divisional Project

Manager

WHAT (Project Plan)

WHEN (Project Schedule)

HOW MUCH (Budget Allocation)

Unit Project Officer

Unit Manager

WIN

OW.

The Project Director should not be deeply

involved in day-to-day management of the pro-

ject. This is the role of

the Project Managers.

In some ways the Pro-

ject Director represents

the interests of the

client and should not

be considered as an

integral part of the pro-

ject team. The Project

Director would prob-

ably delegate much of

the co-ordinating func-

tion to the Project Manager from the Division

with the major involvement in the project.

Formal contact with outside parties would nor-

mally be conducted over the signature of the

Project Director.

5.3 THE ROLE OF THE PROJECT

MANAGER

Project Managers are responsible for:

• Developing and maintaining project

plans.

• Giving project schedule and budget

direction.

• Evaluating and reporting project per-

formance.

• Maintaining contact with clients, con-

sultants and management.

In many ways the Project Manager is a general

manager carrying out the functions of leading,

planning, communicating and controlling.

Technical knowledge is important but as the

project becomes larger, or has increased multi-

disciplinary input, so must the Project Manager

exercise management skills that extend beyond

knowledge of a narrow speciality.

Rarely will the Project Manager have authority

to simply order things to be done. Each project

will be competing for resources and priority.

Unit Managers have demands placed on them

by other project work as well as their Unit

responsibilities. They will not appreciate eager-

beaver PM's trying to order them around.

In general, the priorities and budget allocations

will have been worked out in the budget devel-

opment process which took place perhaps 12

months before the cur-

rent

financial year.

However adjustments,

amendments, additions

and deletions to the

Department's works pro-

gram will take place.

The Project Manager

will need to reassess the

resources allocated ; the

Executive will need to

reassess priorities.

The Project Manager must be more than a co-

ordinator. It will not be sufficient to send off

minutes requesting action and sit back safe in

the knowledge that someone else must now

run with the ball. The Project Manager "owns"

the project and must also "own" the problems.

A good Project Manager will keep informed,

provide leadership, help solve problems and

above all seek the best way to get things done

effectively. If the plan fails to work, if some crit-

ical input fails to eventuate or was not even

included in the plan, it is the Project Manager

who will be asked:

• Why did this happen?

• Wasn't there any warning?

• Couldn't something have been done to

avoid it?

14

15

REFERENCE MANUAL

Oa.

01.

The Project Manager is the person expected to

integrate the technical aspects with time, cost,

resources and human factors necessary to get

the job done.As well as the technical skills, good

project management requires people man-

agement skills. In a project of any size, Project

Managers will never be able to do everything

that might be required. They must be able to

achieve things through people. The Project

Manager will need the attributes of a good gen-

eral manager: communicating, motivating,

negotiating, conducting effective meetings,

planning organising, prioritising, etc.

5.4 THE ROLE OF THE UNIT MANAGER

Unit Managers are responsible for:

• Accomplishing the Unit's work tasks

on schedule and within budget.

• Establishing technical standards.

• Providing technical policy and pro-

cedural advice.

• Providing adequately trained staff.

• Maintaining technical excellence.

• Developing Unit works programs, busi-

ness plans and budget control.

The primary role of a Unit Manager is to staff

and organise a Unit to provide some specific

expertise required by the Department. The

Unit Manager is the ultimate source within

the Department of advice on the expertise rep-

resented by the Unit. The Unit Manager will

schedule allocation of resources within the

Unit and decide who will handle project work

tasks and the performance standards that must

be met.

5.5 THE ROLE OF PROJECT OFFICERS

Project Officers are responsible for:

• Developing and maintaining work

package plans.

Achieving technical standards.

• Establishing detailed schedule and

operating budgets.

• Carrying out work on the Project.

• Controlling and reporting work pack-

age performance.

Project Officers are accountable to their Unit

Manager for the administrative performance of

duties relating to their employment in the

Department and for achievement of the appro-

priate technical standards. They will be

accountable to the Project Manager for the

achievement of their component of the project.

5.6 THE ROLE OF THE PROJECT REVIEW

BOARD

A Project Review Board (PRB) may be estab-

lished for important or complex projects and

will be responsible for:

• Reviewing the project plan, schedule,

budget and performance standards.

• Considering reports on progress.

• Considering any changes in plan,

schedule, budget or qiialiry standards.

The composition of a PRB will vary to suit par-

ticular projects but would not generally include

the Project Manager or any Project Officers. It

will include the Project Director and may

include the Unit Manager with prime tech-

nical responsibility, if that person is not already

the Project Director, and a client representative

or representatives. It is desirable to include at

least one person not directly concerned with

the project to provide an objective viewpoint.

The PRB provides an independent assessment of

the project and its progress in meeting its objec-

tives. For this reason it is important that the PRB

does not become another project team or Steer-

ing Committee. Its prime role is not to assist

Project Managers in managing their projects or

to solve their problems but to represent the

interests of the client and senior management in

seeing that the project has been soundly planned

and is being properly executed.

The PRB should prepare its own minutes of

proceedings and see that these and its rec-

ommendations are placed on the Project

Control File. The Project Director will act as

convenor and chair of the PRB.

5.7 THE ROLE OF THE STEERING

COMMI1TEE

The Steering Committee is responsible for:

• The co-ordination of project work.

• Identification of problems.

• Assessment of progress.

The Steering Committee comprises the Project

16

17

Director, the Divisional Project Managers and

perhaps a Project Manager representing the

client. It must not be confused with the Project

Review Board whose function is review only:

not management. In many cases a Steering

Committee will not be necessary. The co-

ordination function will be given to a Co-

ordinating Project Manager in those cases

where there are a number of Divisional or

client Project Managers

5.8 DOCUMENTATION OF THE

PROJECT

It is the responsibility of the Project Manager

and the Project Officers to maintain proper and

adequate documentation of plans, meetings,

discussions, telephone calls, calculations, data,

field inspections, drawings etc. If proper

records are not maintained, if calculations are

done on the back of an envelope, if information

is hidden away in cupboards, then within a

short time that information is effectively lost.

Confidence in project work will diminish if fig-

ures cannot be justified or conclusions

explained. Disputes over what was decided or

approved may become serious. Work may need

to be repeated and unnecessary costs incurred.

Assume that in the years ahead someone unfa-

miliar with the project will want to know why

things were done, where the data came from

and how calculations were undertaken.

Present information in such a way that it will

be useful if the parameters of the project are

later changed.

It is not sufficient to store heaps of paper in

folders. Some effort must be put into selecting,

summarising, presenting sources and indexing.

Calculations should be checked wherever pos-

sible, signed and dated. It is particularly

important to date any money figures.

Maintenance of good records is an important

aspect of managing a project and is vital if the pro-

ject is being undertaken for an external client.

5.9 MANAGING CONFLICT

In any organisation with limited resources and

many projects cutting across organisation

boundaries, conflict is inevitable. Studies show

the following rank order of conflict intensity

over a project Lifecycle:

1. Schedules

2. Project priority

3. Personnel resources

4. Technical opinions and performance

trade-offs

5. Administrative procedures

6. Personality

7. Costs

These conflicts will vary according to the

phase in the Lifecycle. For example, admin-

istrative procedures can cause problems

initially but these tend to reduce as the project

settles in. Considering only the first three,

what can be done about resolving them?

Schedules

• Develop commitment in advance of

commencement by agreement and co-

operation.

• Carefully monitor schedules during the

project work and communicate them

to those concerned.

• Consider reallocation of resources to

those activities prone to falling behind

schedule.

Project Priority

• Joint decision-making with affected

parties.

• Clearly defined plans.

• Feedback on project needs.

• Recognition of Department work

priority.

Personnel Resources

• Forecast personnel requirements early.

• Feedback on project needs.

• Recognition of Department work

priority.

An appeal to hierarchical authority should be

the last resort. This will place the problem of

resolving the conflict with the Project Director

and ultimately with the Executive. Naturally

this is something they can do without. Nev-

ertheless, timely resolution of conflict is

essential: do not procrastinate or assume it will

go away. Unresolved conflicts may be veil?'

damaging to the outcome of the project.

Before seeking intervention of the Project

Director, the parties to the dispute should

attempt to resolve it by negotiation. Failing

this they should agree upon:

• the issue;

• the impact on the project and the organ-

isation;

• the alternatives ;

and make their separate recommendations.

Conflict is not intrinsically bad. What is bad is

failure to work constructively for a resolution

and indulge in personal attacks, passive resis-

tance or petty jealousies.

"RP

18

19

REFERENCE MANUAL

5.10 GOOD PROJECT MANAGEMENT

Good project management can cover a large

number of issues. It is generally agreed that the

key issues include the following:

• Clear objectives: why is the project

being undertaken ; establish clearly the

client's objectives ; involve users; state

clearly what it is you are trying to do.

• Plan well: it is essential to have a

plan before activity starts, specifying

the schedule, the standards, the costs

and the risks.

• Keep control: consistently check

actual performance against the plan

and take action when things go wrong.

Update the plan regularly.

These three points are essential and may seem

obvious but adhering to them requires dis-

cipline and dedication. Factors to watch are:

• Communication: do not sit around:

talk to people; see for yourself; let peo-

ple know what is going on.

• Documentation: get it down on

paper in a way that someone else can

make sense of it; ensure that the source

and date of information are given.

• Taking care with changes to

the plan: change can be disruptive

and costly; check implications for the

plan, cost and other systems.

• Critical items: identify and con-

centrate on the critical items - the

Pareto or 80:20 rule: but note that

unimportant things can become critical

if ignored for too long.

• Anticipation of problems: do not

rely on the formal reporting system ; by

the time it turns up on a computer

printout it may be too late. Keep your

finger on the pulse. Watch for trends.

• Identification of high risk

areas: have contingency plans ready ;

avoid unnecessary risk ; remember Mur-

phy's Law: Anything that can go wrong

will go wrong.

6.1 GENERAL

Planning is determining how some future goal

is to be achieved. The general elements of any

plan are:

• What activities need to be undertaken

• Who undertakes them

• When should they be carried out

• the Resources required

• the Cost

Routine activities may not require a formal

plan but projects do. Project planning is impor-

tant, vitally important. Without a plan there is

no guarantee that the desired goal will be

achieved and if it is, it will almost certainly be

at greater cost.

Planning must take place at various levels. The

Department Strategic Plan identifies the organ-

isational goals and the programs needed to

achieve them. A Project must be planned in

broad terms over the lifecycle of the project.

Various phases of the project must be planned

as well as the components of those phases right

down to the basic work packages.

All the elements must be integrated and co-

ordinated to achieve the project plan and this is

one of the essential activities of project man-

agement.

The various techniques described in this man-

ual may be used at any level in the planning

process. They include:

• the Project Lifecycle

• the Work Breakdown Structure

• the Project Responsibility Chart

• Networks

• Bar Charts

• Budgets

• Targets

• Cash Flows

These techniques are described in the following

sections. Bar Charts, Budgets, Cash Flows and

Targets are also applied in Project Control and

illustrate the close connection between Plan-

ning and Control. The relationships between

them are shown on Figure 3.

6.2 A LIFECYCLE

A Lifecycle is useful in providing an overview

of a project and identifying the broad categories

of work required. It is based on the observation

that organisms, structures, organisations etc.

are systems which tend to pass through phases

of a Lifecycle from conception to death. The

phases used in the DVVR Project Lifecycle are:

r

PLANNING A PROJECT

20

21

REFERENCE MANUAL