Upload
vstojnic
View
231
Download
4
Embed Size (px)
DESCRIPTION
Project Management Reference Manual Part #1
Citation preview
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