Pkg Solutions
Quality Glossary
Project Management
PLANNING FOR EFFECTIVE TEAMWORK
Teamwork is an important part of a successful T.Q. programme. To obtain
the full benefits ft is essential to plan and agree the work of the team.
1. Clarify the Objectives
All members must agree to a clearly stated objective.
2. Identify all the Tasks
Itemize all jobs necessary to meet that objective. This needs to be
done painstakingly, through discussion.
3. Put the Tasks into a Logical Sequence
Some can be started immediately, others will depend on the completion
of preceding jobs.
4. Estimate Time and Resources
Estimate the time, resources, and effort involved in completing each
task.
5. Review the Whole Plan
Discuss the team's plans in detail with all those involved. The whole
exercise must be visualized and worked to spot difficulties that could
arise. Revise your ideas to take account of them.
6. Progress Reports
Progress against the plan must be monitored and reported. For a simple
project these need not be long documents, but the team must know whether
there is any slippage against the milestones they have set themselves.
1. CLARIFY THE OBJECTIVES
Let us be quite clear what we mean by project objectives; we mean the
development of a specified output, at a specified cost, within a specified
time.
These three attributes output,
cost and time are
completely interdependent so that a change of one usually has an impact
on the others. Inevitably there is a tendency to want a comprehensive
project quickly and at low cost, using minimum resources. This is usually
impossible and so to the project objective is the compromise between these
attributes which most effectively fulfills the specified requirements.
2. IDENTIFY ALL THE TASKS
The first step you should take in the programming process is to break
down the overall work content into packages. There are certain basic rules
to be followed:
Work packages should be appropriate to the level
at which the work will be programmed and controlled. For example, the
master programme will identify broad areas of responsibility and major
activities, whereas for the detailed programme each individual task will
be identified.
Individual work packages should have a recognizable
completion, otherwise there will be discussions as to whether it has been
completed. The best completion is the delivery of a tangible product.
Work packages should be kept to an easily manageable
size commensurate with the level of programming.
Each work package must be the responsibility of
a single person in the project group.
Chosen work packages must respect company and
project organizational constraints.
Always remember that the purpose of programming is to forecast and to
exercise control. Don't get carried away preparing enormous programmes
which are cosmetic and therefore never used. The useful programme is the
one which can be easily understood by the person controlling ft it
should always be a working document in constant use.
It is vitally important that you let the person in control of each pan
of the work prepare his own programme. You must establish the ground rules
within which he must programme (objectives, targets, rules for breakdown,
form of reports, etc) but within these constraints he should be free to
programme and to control his own work. Don't forget, however, to review
his programme before it is implemented to make sure that it does comply
with your requirements, and to make sure that it contains regular check
points so that you can verify the progress reported.
3. PUT THE TASK INTO A LOGICAL SEQUENCE
Once you have broken the overall job down into work packages, they must
be arranged in a logical sequence so that the overall time and resources
needed to do the job can be determined.
A network is a conventional way of drawing the activities in a programme,
so that you can represent the dependencies between them. By dependency,
we mean the way in which one activity depends upon another.
For example:
"A" cannot start until "B"
has finished
"B" must finish at least three weeks
before "C"
finishes
"C"
must finish before "D", "E"
and "F"
can start
Networks are a conventional way of expressing data to record the logical
arrangement of activities in a project. They should not be used for information
or progress reporting since they can often be confusing to persons who
are unskilled in their use. The purpose of networks is twofold; firstly
to impose a discipline so that the interrelationship between activities
can be identified; and secondly to permit programmes to be mounted on
computers for swift analysis.
Whenever we arrange activities logically we are preparing a "n6twork",
although we rarely express or present it in that manner. Some projects
will not involve multiple dependencies, and in these cases formal networking
techniques may not be used. However in every case you MUST identify dependencies
between activities and reflect these in your programme. If this is not
done it is impossible to analyze even the simplest programme since you
cannot predict the effect that an activity will have on any subsequent
activities.
The easiest way to identify dependencies is by means of a linked bar
chart, where a link is drawn between the dependent points of two activities;
for example between the end of one and start of another. The following
figure shows the same activities represented in the form of:
An Arrow network
A Precedence network
A Linked bar chart
Don't neglect this exercise of showing dependency. As you monitor progress
throughout a project you must continually look into the future, and a
logic network enables you to forecast the effect on future activities
of current variations from plan. For example, a slippage of one month
for Activity 2 would have no effect on the project in the figure, but
the same slippage for Activity 4 would result in a one month delay to
completion.
Your network or bar chart should accurately reflect the work breakdown
and should cover all the project activities you have identified. Show
overlaps between activities, and the time lags required between the end
of one activity and the start of another (for example for approvals),
where these are appropriate. If you set up a hierarchy of programmes make
sure there is a direct relationship between the activities of the plans
at the various levels so that the costs, resources and progress can easily
be aggregated.
4. ESTIMATE TIME AND RESOURCES
Having established the logical order of the activities you must estimate
the time and the resources needed to carry out each one. Base all estimates
on a measure of the work content and record the basis for your estimate,
so that in the future you can compare actual with predicted and thereby
improve the accuracy of estimates.
If there are activities which you know will happen, but cannot define,
then you must include them in the programme as activities of assumed duration.
You should then endeavor to maintain the actual duration within your assumption.
Don't forget that you cannot switch projects and resources on and off.
There will be a gradual build up and run down of resources, and staff
from all functions will require a learning period before they reach 100%
productivity. Allow for these factors in your programme.
When you apply your estimated durations and resources to the logic plan,
you may find that:
the predicted completion date falls after a desired Completion date
the resource levels show gaps, or peaks or troughs of demand
You must therefore go back and adjust resource levels, introduce gaps
between activities, or consider how you may change the logic in order
to achieve the desired date, and efficient utilization of resources. Alternatively
you may have to adjust the desired date. This process is known as resource
scheduling.
A word of warning. Don't programme to complete the project precisely
on the desired completion date - always allow some float at the end (usually
about 10%) so that you can absorb a certain level of unforeseen events,
or events whose work content cannot practically be specified. If there
is an unusual level of uncertainty associated with the project or with
certain activities then make special provision for this by allowing additional
float.
Remember that on many projects there are certain activities which are
locked into predetermined start or finish dates, or which must be carried
out within a predetermined time window. If your programme is based upon
constraints such as these, they MUST be clearly identified, so that all
relevant members of the group are aware of them.
ft is of crucial importance to set target completion dates. Do not make
the mistake of merely setting work content targets..."you have 15
man days in which to complete this activity". You are trying to achieve
a completion date for the project, and so activity dates are important
if you are to retain control.
The final approved programme, against which you will control the work,
is therefore a compromise between:
Logic
Outside constraints
Internal constraints
Project targets
Changes to any one of these factors may well affect the others, and
will necessitate a review of the approved programme.
5. REVIEW THE WHOLE PLAN
If you are to exercise effective control you need:
A firm programme
A simple and agreed form of progress measurement
Regular comparison of actual progress against programme
Regular forecasts of future events
Action to correct variances
It is
therefore important that you establish the basis for control against the
agreed programme before any work commences, so that everyone on the project
may be quite clear about:
What Is going to be controlled
How control is going to be exercised
What their role and responsibilities will be within the control system
You cannot expect staff to fulfill their roles unless you have clearly
specified your requirements.
PROGRAMME
The approved programme developed for the project, or for part of a project,
must be distributed to all team members to whom it relates. They should
be given a clear statement of how they are expected to contribute to its
achievement.
MEASUREMENT
Keep measurement simple. It is far better to establish a universally
understood approximate method of measuring progress, rather than one which
is 100% accurate but complex, slow to operate and difficult to understand.
Measurement MUST relate to a specific deliverable. The number of man
days expended, or expenditure incurred, is NOT a measure of progress.
COMPARISON
The comparison of actual work with work programmed to be complete must
be carried out regularly at predetermined times. A four weekly comparison
is the minimum requirement; for complex or critical areas of work a weekly
comparison should be made so that adverse trends can be quickly identified
and remedial action taken.
FORECASTING
You cannot manage past events. The whole purpose of programming, measuring
and comparing progress is to enable you to predict future variances either
by identifying trends, or by following the logic sequence. You must regularly
review forecast progress in order to establish the most effective management
route.
CORRECTIVE ACTION
Regular comparison of actual with programmed progress, and regular forecasting
of possible variances will reveal the area where corrective management
action must be taken. If you wish to exercise control you must take CLEAR
and DECISIVE action to remedy variances, and you must take it QUICKLY.
This is why frequent and up to date reports on progress are essential.
6. PROGRESS REPORTS
You must observe a number of basic rules if your progress reports are
to be of real use to the project. In particular they must be:
Consistent and accurate
Timely
Clear
Point to remedial action
Guidance on each of these points is given below.
CONSISTENT AND ACCURATE
Errors will quickly erode the confidence of superiors and subordinates
alike. Accuracy does not mean that they must be precise and correct to
the last detail, but it does mean that the approximation which is necessary
for swift reporting is clearly identified, and falls consistently within
predetermined levels.
TIMELY
If reports are issued a long time after the event, then they are useless
as a basis for decision or action. Any action then taken will be unlikely
to improve matters. Remember, it is far more useful to have timely information
which is approximate, than precise information which is late.
CLEAR
Reports must be clearly understood by all recipients. Avoid preparing
full and detailed reports which merely provide information, but require
the recipient to deduce key factors and trends. It is far better to break
the information down into several reports each of which highlights a single
factor and
make that key factor obvious to the recipient. Ideally you should concentrate
on reports which point out critical variances from the approved programme,
and trends in performance; then present these graphically.
POINT TO REMEDIAL ACTION
If possible, select the key facts you are reporting upon so that the
corrective action required is obvious. Concentrate on major aspects which
clearly reflect progress (milestones, critical path, etc.)
Much of the information you require to manage a project will be provided
by others, using the programmes and control systems they have set up.
It is of great importance that you advise everyone on the project of the
form, standards and level of detail you require in the reports made to
you. If you receive information from a number of sources which is presented
differently, arrives at different times, and is of varying accuracy, then
you will find it difficult to build up a comprehensive and meaningful
picture of overall progress. You must encourage consistency and accuracy.
Never forget that information is power, so do your utmost to ensure
that it is provided as clearly as possible.
Aim to minimize the amount of time and effort required to establish
the status of work, and keep the volume of data to a minimum, so that
attention is focused on critical areas. MOST IMPORTANTLY, DON'T FORGET
THAT THE PRIMARY OBJECTIVE OF PROGRESS REPORTING IS TO ENABLE CORRECTIVE
ACTION TO BE TAKEN IN THE FUTURE, NOT TO RECORD PROBLEMS IN THE PAST,
although good progress reports will of course highlight past problems
and achievements.