Project Management


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.


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.


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:

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.


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:

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:

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.


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:

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:

Changes to any one of these factors may well affect the others, and will necessitate a review of the approved programme.


If you are to exercise effective control you need:

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:

You cannot expect staff to fulfill their roles unless you have clearly specified your requirements.


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.


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.


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.


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.


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.


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:

Guidance on each of these points is given below.


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.


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.


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.


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.