When planners get together and let their hair down they tend to get into long and boring discussions about the relative merits of precedence versus arrow diagrams or of one computer programme versus another. It is not the intention to enter into such arguments here but rather to express in a simple way the ideas that lie behind the chosen approach in our organization. These ideas have evolved in practice. They are personal and only relate to the kind of projects in which we are involved. They may not suit the temperaments of other planners or the type of projects they plan, and like all ideas they may change or be modified in time.
Methods Are Only Tools
Networks, data bases, line-of-balance graphs, bar charts and other techniques are no more than tools to aid the planner. The planner must be clear in his own mind why he has chosen to use a certain tool and what benefits he expects to get as a result.
For example, a bar chart has advantages over a table of dates because it is a visual presentation of scheduling information (a picture is worth a thousand words). However, bar charts are liable to misinterpretation because the sequencing logic is ambiguous. They are hard to compile for many activities. Networks provide some answers: activities, logic and durations can be considered separately, floats may be calculated and the whole business computerised to ease updating.
The real danger of using some of the elaborate modern techniques is that the planner may be enslaved by the method. A good plan may be no more than a list of jobs scribbled on the back of a cigarette packet — if it is helpful as an action guide. The way the planner should avoid the danger is always to consider the ‘what?’ before the ‘how?’. Rather than decide he is going to use a cumulative labour S-curve to tackle the problem he should first look at what is required. Then the particular method, his S-curve, can be viewed as only one among a variety of ways to set about the solution. If he is clear in his mind on the benefits he expects from his chosen technique then he can critically assess whether he is realising them in the application.
Big networks usually spring up where modules or repetitive subnets are used. The problems of updating in such detail are enormous, and the prime benefit of computerisation — a fast response to changing conditions — is lost. One mistake that leads to oversized networks is planning in too much detail. Activity durations, for example should be in units of the monitoring period. It is a waste of effort to plan in days when site reports occur once a week and you update only once a month. The more detailed the network the more essential it becomes to resource-schedule rather than time-analyse.
We favour simple time-analysed networks with broad-scale activities, only expanding the detail in an area that becomes critical. It is a common error to believe that because plans are very detailed and take a long time to produce they must provide a better measure of control. It just is not so. When the planner finds himself defending his original logic, because it is now too difficult to change, all the warning bells in his mind should ring. The large network rapidly becomes a poor model of reality and loses its value as a planning tool.
The Reality of Limited Control
The sad truth is that project management has limited control over a project — even with good planning. There are too many uncertainties. Planning cannot anticipate bad weather on site, a client that changes his mind or a major engineering change coming when the plant is half finished. Having reconciled themselves to this fact, there is still hope for the planner and the project manager, because the areas in which best control is possible are also those of most, importance.
The chances of the project being completed on time are usually determined before construction work starts on site. They are decided in the drawing office and the buying department. By the time construction is underway the die is cast for work availability and material supply.
The implications of these statements will be developed later; the important point is that design and buying are activities that go on at head office and so can be well controlled. We have less control of the subsequent activities (manufacture, deliver, erect) because the work is often out of our hands. Having accepted the reality of limited control it becomes obvious that finely detailed plans are a delusion, and the whole emphasis of planning effort must lie elsewhere than on elaborate scheduling.
Structuring of Information Systems
Managing a project can be compared to fighting a battle. You have to win in the early stages or thereafter you fight a rear-guard action. The successful general is likely to be the man with the best intelligence service. Through reconnaissance he knows well the strengths and weaknesses of the enemy and is well equipped to develop a strategy to overcome them. Project management also has a lot in common with crime prevention and detection. The good detective relies heavily on his informers. Accurate and timely information is the key to success.
We believe that scheduling should occupy no more than twenty percent of the planner's time. Instead most of his attention should be focussed on the development and maintenance of information systems. These information systems can be very formal or, as the effective generals and detectives know, they may be very informal. The planner should consciously cultivate personal contacts and sources.
The progress meeting is an admission of failure. It is not good enough that a planner be in touch with progress once a week or once a month. Via his information system he should be continuously appraised of development and he should be continuously reassessing the project plan in the light of the latest information. If he needs a meeting once a week, say, to find out what is going on in the project then his information systems have failed him. Worst of all he should never have to wait for his monthly computer update to spell out for him the implications of the changing situation.
This does not deny the value of the planner's participation in a regular project review meeting or a report-back meeting to the client. These meetings have enormous value for communication, coordination, involvement and commitment.
Information Systems: An Example
One of the systems we employ is a method of equipment-listing. Figure 1 shows the layout of such a list. We have a set of these lists broken down by cost section for each contract. All requisitions are routed through planning to buying. The planner enters the date of requisition, the description of the item, the plant item numbers and drawing numbers (if any) on the equipment list. He also enters the required delivery date. In most cases the engineer or contract manager who wrote the requisition will leave the required delivery date open for the planner to specify. If the planner does not like a given delivery date he will go back to the author of the requisition and talk it over with him.
Without delay, the requisition is passed to buying. Similarly the planner will see the bid analysis and the progress copy of the order. He will enter the order date, the order delivery date, the supplier and order number on his equipment list.
If expediting report delays he will enter the latest forecast delivery date (revised date), and when the goods are received on site he will enter the date and the number of the goods-receipt voucher.
This is the essence of one system we have found very valuable. It can be used on small projects where a computerized data base could not be justified. The lists are helpful to expediting and are issued regularly to site. The planner is continuously in touch with the order state. Although it sounds like a lot of mere clerical work it is most important that the planner should compile this record for himself. As he writes down the information he is encouraged to think about it and consider its implications. In structuring such information systems we aim to place the planner in the path of the existing information flows in the organisation.
FIGURE 1 SAMPLE EQUIPMENT LIST
Level of Indenture
There is a planning principle given the grandiose title of ‘level of indenture’ which says: don't issue unnecessary information. We use the following guidelines:
• don't issue the history of the project: it is probably very interesting but is of no use to line management during project time;
• use charts and graphs for easy reading;
• use job types and responsibility codes to ensure that each individual receives only the information he needs; and,
• don't issue schedules for more than eight weeks ahead or about 1½ to 2 updating cycles.
This principle can be extended. In particular, don't issue networks and printouts to your client unless you want him to take control of the project. In fact, avoid issuing printouts at all unless they are very closely tailored to the needs of the recipient.
There is one very important rule in this matter of indenture:
Make sure you give the man doing the job the information he needs to control his own work; don't give it to his boss only — he won't respond to your planning if the first he learns about it is when he gets in trouble with his superior.
BIGGEST CONTRIBUTION IN THE EARLIEST STAGES
By the time construction begins on site, procurement will be well under way. The most common cause of construction delays is shortage of material. If the battle is lost in the early stages then there is little that can be done on site to recover the situation. The planner who puts most of his effort into scheduling is trying to control the wrong thing. This is especially true because site work is more subject than any other to unpredictable factors: bad weather, labour problems, equipment failure and so on.
Proposal-Planning
The importance of Proposal-Planning can hardly be overstated. Many contracts are late before they begin simply because the marketing manager feels he must knock a couple of months off the completion date to stand a chance with the tender. This may be so, but he should be consciously aware that the project will not be completed on his promised date and the company may incur penalties as a result.
Proposal plans should set fixed dates for freezing design and should have sufficient detail to show which long-delivery items must be ordered as soon as possible after award of the contract. Setting the date for freezing design at the proposal stage makes sure that the client understands that he cannot continue indefinitely to change his mind without delaying the project.
Planning and Expediting
Planning must direct the efforts of expediting. The planner is the only man who can assess the full significance of failure to meet order due-dates. It may be critical that one item does not slip a day, while the next may be months overdue and not matter. Expediting cannot tell, and they cannot expedite every order fully and successfully. It is the responsibility of the planner to ensure that expediting is economically and effectively employed.
Planning and Contracts
We have already said that the planner must be involved in the buying process: enquiry, bid analysis, requisition and order. He has a major contribution to make in the setting of manufacturing priorities and contractual due-dates. Where problems arise the planner must be prepared to climb into the subcontractor or supplier, plan his work and support expediting by installing monitoring and controlling tools.
There are all areas in which the planner aids the project in the crucial early stages.
TECHNIQUES
It is obviously not the aim of this article to discuss at length the merits of alternative planning techniques. However, for the record, though we don't believe in giving our clients networks and printouts we do give them trend charts for the anticipated completion date and, where suitable, for the float. We do not use curves for the cumulative percentage of network activities completed (‘S-charts’ or ‘banana curves’ — whatever you like to call them). We find precedence networks easier to draw, and we use them for proposal plans and simple projects. Unfortunately the best-supported computer-networking packages at the moment are based on arrow diagrams, so that we have to use this type of network formulation when we computerize on a large scale.
Anticipated Completion-Date Trend-Charts
Trend charts are a powerful but little used tool.
Management demands a simple measure of the health of the project. It must be easy to interpret, highlight the major problem areas, record the changing fortunes of the contract and occupy no more than one side of a piece of paper. For the client, it must answer the question: when will the project be finished? For your own management, it must show if the project is profitable.
Some planners plot S-curves of the cumulative percentage of network activities complete against the earliest-finish and latest-finish envelopes. This presentation does mislead. It takes a delay on only one activity to prejudice the success of the project; network activities cannot be considered equal in terms of progress; such a chart loses its points of reference if the planner changes the network. It is similar to the mistake of labelling activity bars with percentage completion. It is not the work done but the time-to-complete that matters.
Trend charts are better as management summary reports. Figure 2 shows a time trend-chart. Update by update (in this case, month by month), the planner has recorded the delays that affected the project completion date and any action that was effective in retrieving the situation. Not only does it show the planner's assessment of how late the project is to date (the negative float, perhaps) but it also predicts the outcome of a trend of accumulating delays. The point where this trend intercepts the equal-time line gives the predicted completion-date. To show the profit situation, the gross percentage margin can be plotted on a parallel chart.
FIGURE 2 TYPICAL TREND CHART
The Predicted Completion-Date
At the discretion of the planner any sort of trend line can be fitted to the series of points plotted on the trend chart. The simplest is the straight line between the award of contract (when, presumably, we felt we could meet the target contract-span ‘c’) to the point, elapsed time't’ later, when we have an actual delay ‘a’.
Let's’ be the anticipated project span.
Then
s(t) = c + a(t)
where
a(o) = 0
and, therefore,
s(o) = c
This leads us to a simple equation giving ‘p’, the predicted delay. From the trend-chart geometry, illustrated in figure 3, the predicted delay is defined as the delay at the point where the extrapolation of the trend line intersects the equal-time line (s = t).
FIG 3 TREND CHART GEOMETRY
So we have
hence
In words, we define the predicted delay as the product of the actual delay to date and the target contract-span, divided by the difference between the elapsed time and the actual delay.
It is only meaningful to talk of a predicted delay when t>a>o. If a<o then we have no delay. If a>t then the trend line will not intersect the equal-time line (that is, the gradient of the trend line is greater than or equal to one) which means, at this rate, the project will never be finished. For example, suppose our contract has a target span of two years (twenty-four months) and that, ten months after award of contract, the actual delay is two months, then from the equation the predicted delay is
Reporting to management that, on the basis of past performance, we predict the project will be six months late prompts a greater response than merely saying actual delays of two months have been experienced so far.
Float Trend Charts
How good is our budget for the use of float across the project? Float trend-charts provide a guide. Figure 4 illustrates a typical float trend-chart. From a table of dates, sorted in order of the remaining float after resource analysis, the maximum and minimum remaining-float as well as the limit of remaining-float on ten percent, fifty percent and ninety percent of the outstanding activities can be found. Month by month these points are plotted on the chart. Straight lines are drawn from the initial values to intersect the zero-float line at the target completion-date. These form guidelines against which to judge the monthly figures. If, for example, we are using up our float so fast that at least fifty percent of the network activities will become critical some months before the target completion date then almost any delay is likely to prevent the project from finishing on time.
CONCLUSION
The interrelation of time, resources and cost on a project can be likened to a post with three stays: it will only remain upright and stable when all three forces are balanced. The human brain is still the subtlest computer we know, and it is only through the personal skills of a project manager that a happy compromise can be achieved in the control of these factors.
FIGURE 4 TYPICAL TREND CHART
Once again the central problem of achieving total control lies in the structuring of information systems. There are far reaching implications here for the whole organisation. This is where the planner has both the most important contribution to make and the furthest to go in making it.
