GPM First
Chapter 15 of Project Management (978-1-4094-5419-9) by Dennis Lock

Scheduling Resources, Part 1: Principles

Resource scheduling is a complex subject that can be viewed from a number of different standpoints. At the strategic level it can be seen as an important element in formulating the long-range plans of companies. In this book, the subject is treated from the point of view of the project manager, who is more likely to be concerned with the shorter-term operations of the business. However, the techniques described here for project resource management cannot be regarded in isolation from the longer-term strategy, since project and other working schedules contribute vital information to the higher-level strategic planning process.

There are arguments (not discussed here in detail) concerning the attitude of company management to the stability of its workforce. In an organization that cherishes a stable labour force, with job security and long-term career development high on the list of its perceived staff motivators, resource scheduling can be seen as the process of identifying the resources available to the project organization and then attempting to deploy those resources as eficiently as possible to achieve the business objectives. The number of organizations which take that approach seems to have become fewer in recent years. More companies now start by examining or re-examining the needs of the organization, and then match their staff numbers accordingly (which can mean ruthless ‘downsizing’).

Resource management can also be looked at in other ways, depending on the nature of the business and on management attitudes. In those industries with a high proportion of casual labour, or which subcontract large elements of their work, detailed in-house resource scheduling can usually be conined to the relatively few permanent headquarters staff. Even in those industries, however, some knowledge of future resource requirements is desirable, so that subcontractors can be forewarned for instance.

An organization that handles projects using its own permanent engineering and manufacturing or construction workforce will need to take resource scheduling very seriously. It will have to calculate detailed working schedules that satisfy not only needs of each individual project, but also the combined effect of all work on the organization’s total resource pool. The possible effects of predicted new work must be tested, preferably using ‘what-if?’ modelling. Information must be gathered on the longer-term work requirements of the organization, so that facilities can be planned and provided for the future expected workload.

What are Resources and Which of Them Can be Scheduled?

A project resource is any person, object, tool, machine or sum of money needed for work on a project. Resources can be categorized in several ways and it is interesting to start by identifying three main classes (the definitions are my own).

Exhaustible Resources

Once an exhaustible resource has been used, it is no longer available for use on a project. Replenishment is physically impossible.

Time is the most important exhaustible resource. Time is truly exhaustible. Once spent, it has gone forever and can never be renewed. Time is a very special resource, needing its own techniques for planning and scheduling. These range from the simple day-to-day diary to the methods described in the preceding chapters.

Fossil fuels (such as coal, oil and natural gas) and mineral deposits (like the ores used in mining) are exhaustible resources. Once the deposits in a particular region have been used up, they cannot be replaced and the life cycle of the project that exploited them must end.

Exhaustible resources feature in project feasibility and strategic studies and in total life-cycle analysis but (with the exception of time) they do not generally feature in project resource scheduling and are not considered further in this book.

Replenishable Resources

Materials and components obtained through purchasing are replenishable resources. Although stocks of these resources might become exhausted when they are built into a project, they can usually be replenished by buying fresh supplies. The principal methods for scheduling materials come within the realm of stock control and purchasing, but information from project planning provides the control framework for purchasers and stock controllers by stating how much will be needed and when.

Although not considered speciically in this chapter, agricultural crops and their products are replenishable resources. However, they may not all be replenishable in the short term (timber, for example).

Some project management programs can schedule replenishable resources directly if required. This scheduling might include, for instance, the phasing of materials deliveries to a construction site so that the quantities on site match the rate of progress expected from the project critical path network.

Money, especially when it is scarce, might be regarded by some as an exhaustible resource. Strictly, however, it is replenishable. There are many examples of projects where the sponsors have been persuaded to provide more money for an ailing project rather than see it and their initial investment sink into oblivion. As with materials, project management data can determine how much cash will be needed and when. Cash flow predictions are a form of project resource scheduling and all competent project management software can be used to generate cash flow schedules. Cash flow scheduling is discussed further in Chapter 17.

Re-Usable Resources

Re-usable resources are assets that are required for use on project work but which remain available for re-use after each task has been performed. They can be compared to catalysts in a chemical reaction: they are necessary to promote the reaction but at the end they emerge unchanged. Levels of re-usable resources tend to remain fairly stable over the longer term. They might, however, be scarce, in which case their use requires careful planning and scheduling.

People, with their particular skills and aptitudes, are the most common type of reusable resource. Some might claim that people do not emerge from a project unchanged, but (ageing apart) they should be available for work on consecutive projects. Most of Chapter 16 is concerned with scheduling people as a resource.

Industrial plant and machinery, other manufacturing facilities, test centres and so on can also be considered and treated as re-usable resources. Although people and machines are very different resources, the same techniques and computer programs can be used to schedule them, provided that their use can be categorized by a simple code and their quantity can be speciied in straightforward units.

Factory or office space is, of course, a re-usable resource. One usually has to consider not only the number of space units (square metres or square feet) but also the shape of the space and, sometimes, also its volume. In heavy machine tool design and manufacturing projects, for example, machines set up for pre-shipment testing might have to be positioned in the assembly and test bay according to their height and foundation requirements, and it might be necessary to save space by allowing for machines from different projects to overhang each other. Project management software is not capable of dealing with these aspects of scheduling. In practice the solutions are best left to production engineers (for factory space) or facilities managers (for ofice space). They would use loor plans or three-dimensional models, either with or without the aid of a computer. However, the project manager still has a vital role to play, because it is principally he or she who can tell the production engineer or facilities manager when the space will be needed for each project.

The Role of Network Analysis in Resource Scheduling

A network cannot be used by itself to demonstrate the volume of resources needed at any given point in project time. In fact, when the network is drawn no considered account can be taken of the resources which will be available. The start of each task is usually assumed to be dependent only upon the completion of its preceding tasks, and not on the availability of resources at the right time.

Naturally if a planning team knows that, for the sake of argument, a total of four pipefitters are employed in the project organization, they would not estimate the duration of any pipefitting task at a level which demands the employment of more than four pipefitters on that task. However, the chance of other pipefitting tasks occurring elsewhere in the network at the same time is impossible to deal with when the network is being drawn because the timing of those other tasks cannot be known before the network has been completely drawn and time analysis has been carried out.

In general, therefore, network logic shows only those constraints between tasks that are related to the logical, preferred sequence of working. Thus, although a network should be fine in logical theory, it is not always possible in practice to start all tasks at their earliest possible times. In fact, if too many tasks clamour for too few resources it might be impossible to carry out the project in the time indicated by the critical path.

This is far from saying that work spent in preparing a critical path network has been wasted. The network diagram and its time analysis must be seen as the irst essential step in the wider process of scheduling project resources. The results of critical path network time analysis play a key role in resource scheduling, but the practicable allocation of project resources to tasks requires at least one more stage of calculation after determining the amount of loat available for each task and locating the critical path.

Allocating Priorities According to Float

The results of network time analysis determine task priorities. When different tasks compete simultaneously for the same limited resources, priority rules can be applied so that the resources are allocated where they are most urgently needed. Usually tasks with least loat are given the highest priority.

A Resource Scheduling Case Example: The Garage Project

The principles and some of the problems of resource scheduling can be introduced by considering a small construction project. Manual methods (as opposed to the use of a computer) are described here, because these demonstrate the underlying processes. In practice, one of the many commercially available computer programs could be used (see Chapter 18).

Garage Project Definition

A small irm of builders has been commissioned to erect a detached garage. The building is to be constructed of brick, with a corrugated sheet roof. This roof will incorporate some transparent sheets as roof lights instead of windows. The doors are to be timber-framed and hung on strap hinges. No heavy lifting is involved in this project and no task needs more than two people.

Resources available

The building irm engaged on the garage project is a very tiny outit, comprising the not unusual father-and-son team. The father, no longer capable of sustained heavy work, is nevertheless a good all-round craftsman with long experience. The son, on the other hand, can best be described as a strong, willing lad, sound in wind and limb but lacking any special experience or skill. This irm’s resource availability can therefore be listed as follows:

  • Skilled persons – 1

  • Labourers – 1.

 

Critical Path Network Diagram for the Garage Project

Figure 15.1 shows the network diagram for this project. For comparison, this is given in both arrow and precedence versions. The number of tasks that can be shown clearly on a book page is limited so, for clarity of illustration, activities such as allowing time for paint to dry or for concrete to cure have not been included in these networks and it is assumed that all materials and hire plant needed are already available on site.

All the task durations have been estimated in days, and they assume that only the small labour force already described (one skilled all-round craftsman and one labourer) will be available for this project.

When the network was drawn, no consideration was given to any competition for these very limited resources that might be caused by the possibility of two or more tasks requiring them at the same time. The planner, correctly, followed this course knowing that any such problems would be resolved in a subsequent, quite separate, resource scheduling calculation.

Time Analysis and the Calendar

The results of time analysis for the garage project network are given in Figure 15.2, which also provides the task list. If unlimited resources could be used, so that all the earliest possible dates could be achieved, the whole project should take 24 working days. But there is no direct indication from the network or its time analysis of how many craftsmen and labourers would be needed to achieve this result.

All times refer to close of work on the given days. Thus a task scheduled to finish on (for example) day 8, means that it should be finished at close of work on day 8. A job scheduled to start on day 8 means that it could start at the end of day 8 which, in practice, really means the beginning of day 9.

This rule can be explained best by reference to the arrow diagram in the upper section of Figure 15.1. A network event (as opposed to a task) occupies no time itself and its achievement takes place at the instant when all its preceding tasks have been completed. Subsequent tasks can start at the same instant. Task 01-02 (dig foundations) for instance, starts at time 0, which is the end of an imaginary day 0 or, in reality, the beginning of day 1. The intervening night hours are simply not recognized as time available for work by the computer and are thus completely ignored. The estimated duration of task 01-02 is four working days, which means that its earliest possible completion is at the end of day 4. Event 02, therefore, can be achieved at close of work on day 4. The following task, 02-05 (concrete foundations) can therefore start on day 4, but that means the end of day 4. In practice, therefore, task 02-05 would not start until the beginning of day 5.

This convention can give rise to an interesting anomaly for zero duration tasks that are processed by some computer programs. Suppose that a zero duration task is shown as starting on 1 May. That really means start of work on 1 May, typically at 09.00. Because computers ignore non-working night hours, the inish of this same task might be shown as 31 March, because to the computer, 17.00 on 31 March is the same instant in time as 09.00 on 1 May. So apparently we have a task finishing one day before it starts! However, most modern programs overcome this problem.

 
Figure 15.1 Garage project: network diagram

graphics/fig15_1.jpg

 
Figure 15.2 Garage project: task list and time analysis

graphics/fig15_2.jpg

Gantt Chart (Bar Chart) for the Garage Project

Because we are not using a computer in this introductory case, the first step in determining the labour requirements is to convert the network diagram into a Gantt chart (most workmen would call this a bar chart because they have would never have heard of Henry Gantt). Figure 15.3 shows the initial bar chart for this project, with every task placed at its earliest possible time.

Please imagine the bar chart in Figure 15.3 as having been set up on a wallboard, using strips that plug into holes on a grid pattern, or are otherwise attached so that they can be moved sideways to adjust the schedule as required. Each bar represents a task on the network, with its length scaled according to the task’s estimated duration.

The bars are coded according to the type of resource needed, black indicating a skilled person and grey for a labourer. No task in this project needs more than one skilled person or more than one labourer. Some tasks need both one skilled person and one labourer, and for those tasks black and grey bars have been drawn side by side.

Calendar and timescale details

The garage project timescale starts at the beginning of 13 May and network day numbers have been converted into calendar dates for the working schedule. These conversions are valid for the year 2013. The project calendar has been arranged with no weekend working so that only week day dates are valid for scheduling. Because Saturdays and Sundays are non-working days, their dates are excluded from the schedule. In practice, public holidays would similarly be excluded as working days, but they have been ignored for this case example.

 
Figure 15.3 Garage project: bar chart and resource histogram – aggregation

graphics/fig15_3.jpg

The schedule in Figure 15.3 shows that the earliest possible completion date for this project is 13 June. Saturday mornings (not shown on the chart) could be considered as time to be held in reserve against unforeseen contingencies. Evening overtime is another possible reserve resource. However, these possible additional working hours are hidden reserves and the project planner was quite right not to build them into the initial plan.

Resource Scheduling for the Garage Project

Simple resource aggregation

Each task on the bar chart in Figure 15.3 is shown starting at its earliest possible time. No thought has yet been given to the resources needed and it is now time to start putting that right. The resources needed each day to carry out this simple plan are easy to calculate. It is only necessary to add up the number of times a strip of each code (grey or black) occurs in each day’s column.

The planned total daily resource requirements are entered at the foot of the chart. This has been done in the form of a histogram in our example. The result is, to say the least, unsatisfactory. On some days the workers are expected to be idle; on other days three people will be needed where only one is available. The workload is unbalanced, showing too many peaks and troughs for proitable comfort.

The reason for this uneven schedule is that the planner has shown every job starting at its earliest possible date, regardless of need or priority. Such a plan is known as ‘resource-aggregated’ and it has little practical use except as a step towards obtaining a more practicable ‘resource-allocated’ schedule.

The important principle missed in Figure 15.3 is that many of the jobs are known from critical path network time analysis to have float, and the starts of these tasks could therefore be delayed to smooth the workload without extending the project’s end date. Using the adjustable wallchart, therefore, it should be possible to reschedule non-critical tasks to remove some or all of the unwanted workload peaks.

Resource-limited schedule

If the garage project is to be carried out solely by the father-and-son team, it is obvious that the schedule displayed in Figure 15.3 cannot be implemented. The schedule must be rearranged so that the modest resources available are never double-booked. Using the adjustable chart, the tasks can be shufled around until no column total exceeds the number of people available. When this shuffling is carried out, however, the logic of the network from which the bar chart was constructed must be remembered and all the constraints between different tasks must still be observed.

Figure 15.4 shows the bar chart for the garage project after levelling to produce a resource-limited schedule (see Figure 15.7 for an explanation of the term resource-limited schedule). The resulting workload histogram is given at the foot of the chart. Imposing the resource-limited constraint has therefore delayed the planned finish of this project from 13 June to 26 June, extending the timescale by nine working days (plus the additional intervening weekend days). However, there is now a smooth resource schedule, which is perfect for this tiny company because there are almost no idle days and no unwelcome peaks.

Time-limited resource levelling for the garage project

The resource-limited schedule, although ideal for the contractor, may not be so acceptable to the customer. She has ordered an expensive new car and wants to be able to garage it safely as soon as she gets it. If the new garage cannot be promised in time the customer may decide, not unreasonably, to look for another contractor.

In these circumstances, several courses of action are open to the small builder. These include the following:

  1. Work to the resource-limited timescale of 33 days (Figure 15.4), but make a false promise to the customer that the garage will still be finished on 13 June. Making such false promises can never be recommended, for commercial as well as for moral reasons.

  2. Tell the customer that the project cannot be finished by 13 June – and lose the order as a penalty for telling the unvarnished truth.

  3. Revert to the original resource-aggregated schedule shown in Figure 15.3 and take on additional workers, regardless of cost, in order to finish the project in 24 working days.

  4. Plan to complete the project within the required 24 working days, accept that additional workers will be needed, but review and adjust the resource-aggregated schedule in an attempt to smooth the workload into a more cost-effective pattern.

 

 
Figure 15.4 Garage project: bar chart and resource histogram – resource-limited

graphics/fig15_4.jpg

Option 4 is one that is commonly taken in project scheduling, and it will work well for the garage project. Remember that this rescheduling of tasks can only take place within the constraints imposed by the network logic, so that no task may be started before all its predecessors have been achieved. Further, if the overall project timescale is not to be extended, no task may be rescheduled to start later than its latest permissible start time, as determined by the network time analysis (shown in Figure 15.2). This means that non-critical tasks can be delayed within the float which they possess. Critical tasks have zero float, and must therefore always be scheduled to start at their earliest possible times.

Figure 15.5 is the rescheduled bar chart. The resource histogram at the foot of the chart shows that it is possible to reschedule this project over 24 working days with a resource usage pattern that is far smoother than aggregation, needing only one additional person of each skill category.

 
Figure 15.5 Garage project: bar chart and resource histogram – time-limited

graphics/fig15_5.jpg

Float (or Slack)

The concept of ‘float’ and the specific definitions for its possible variations are sometimes dificult to comprehend. Since one of the more practical applications of loat is found during the resource scheduling process, it is convenient to illustrate and deine loat in some detail at this point. The network for the garage project (Figure 15.1) will provide a suitable case for study.

The illustration in this section is supported by both precedence and arrow network references.

Consider garage project task G1016 (10–16), ‘Case lintel and build parapet’. For those with no experience of construction projects, this means encasing the steel lintel over the garage doors in concrete and then building a brick parapet on top of it. The duration of this task has been estimated (perhaps optimistically) at two days. For clarity, this task has been extracted from the main network and is shown as a separate detail in Figure 15.6. All the data relevant to calculating float are included in this extract.

A glance at this network fragment shows that the earliest possible start for this task is (the end of) day 17. The latest permissible finish is day 22. Allowing for the two-day duration of this task, it is easy to see that its start (and its finish) could be delayed by up to three days without causing any delay to the tasks that follow. This three days is the total float possessed by task G1016 (10–16).

 
Figure 15.6 Garage project: float analysis of activity G1016 (10-16)

graphics/fig15_6.jpg

If, because of delays in the project or through intentional resource scheduling, the lintel cannot be encased at its earliest possible time, some (if not all) of the loat for this task will be eroded. This will usually have a ‘knock-on’ effect through the network, robbing loat from tasks which follow, because they can no longer be started at their earliest possible times.

In fact the float for any task must always be seen in relation to how it is likely to affect, or be affected by, the loat possessed by other tasks in the network. Consideration of these effects gives rise to deinitions for various types of loat. These deinitions will now be given, but it is not necessary to be conversant with all of them. Before the start of a project, planners and project managers are generally most concerned with ‘total loat’. From the time when resource scheduling starts, and throughout the active life of the project, the focus is on ‘remaining loat’.

Total Float

‘Total loat’ is deined as the amount by which a task can be delayed if all its preceding tasks take place at their earliest possible times and following tasks can be allowed to wait until their latest permissible times.

The early and late times for event 10 in the arrow network are both 17. Because these times are equal, event 10 is fixed in time and thus has zero float. However, that applies only to the event, and not to all the tasks passing through it. Although event 10 lies on the critical path, the path branches at this event and a glance at the whole network in Figure 15.1 shows that the critical path actually misses task G1016 (10-16). Task G1016 (10–16) does indeed possess float. Version (c) in Figure 13.4 showed one way in which this dificulty can be avoided in arrow networks. However, the problem disappears altogether with precedence notation, as can be seen in the upper half of Figure 15.6.

The actual loat conditions of this task are illustrated best in the segment of Gantt chart included in lower portion of Figure 15.6. It is apparent from this diagram that, using the formal deinition, the total loat for task G1016 (10–16) is three days.

Total float = latest permissible task finish time

minus the earliest possible task

start time minus the estimated task duration

Applying the data from Figure 15.6 to this formula:

Total float of task G1016 (10−16) = (22 − 17 − 2) = 3 days

 

In the precedence version, shown in the upper part of Figure 15.6, the calculation for total loat can be made simply by subtracting the earliest possible inish time from the latest permissible finish time, which gives the same result (22 −19) = 3 days. Subtracting the earliest possible start time from the latest permissible start time gives the same result (20 − 17) = 3.

Free Float

‘Free loat’ is deined as the amount of loat available to a task when all its preceding tasks take place at their earliest possible times and following tasks can still take place at their earliest possible times.

In the arrow network, free float is found as follows:

Free float = earliest possible end-event time

minus the earliest possible start-event time

minus the estimated task duration

 

Applying the arrow network data from Figure 15.6 to this formula:

Free float of activity G1016 (10–16) = (20 − 17 − 2) = 1 day

 

In the precedence network the calculation for free loat is different, and it is necessary to refer back to the full diagram in Figure 15.1 and its time analysis in Figure 15.2. The calculation of free loat using precedence notation is as follows:

Free float = earliest start of the immediately following activity or activities

minus the earliest finish of the task under consideration

 

From the precedence network diagram in Figure 15.1 it can be seen that the task immediately following task G1016 is task G1618. The time analysis data tabulated in

Figure 15.2 show that G1016 has an earliest possible finish of day 19, and G1618 has an earliest possible start time at day 20. Thus the free float of task G1016 is (20 − 19) = 1 day.

Independent Float

Now consider task G1016 (10–16) once again (as shown in Figure 15.6). Notice that it is possible to shufle this task around over a one-day period, whatever happens to the schedule for all other network tasks. It matters not whether the preceding events are allowed to run up to their latest permissible times, or whether the following events must start at their earliest possible times. This task can be moved backwards and forwards within one day before any other task is affected. This small amount of loat, because it is entirely independent of all surrounding tasks, is called ‘independent loat’.

Defined formally, independent float is the amount of float available to a task when all its preceding tasks take place at their latest permissible times and all following tasks can still take place at their earliest possible times. Independent loat is easiest to observe in arrow networks, from which the mathematical expression for independent loat is as follows:

Independent float = the earliest possible end-event time

minus the latest permissible start-event time

minus the task duration

 

Task G1016 (10–16) in Figure 15.6 does happen to possess some independent loat, as illustrated in the Gantt chart fragment and as calculated by using the task data in the above mathematical expression:

Independent float of task G1016 (10–16) = (20 – 17 – 2) = 1 day

 

It is purely coincidental that the free loat and independent loat have the same value in this case.

Independent loat is almost always zero is generally ignored.

Remaining Float

The total loat possessed by any task is at risk of erosion from the moment that project resource scheduling starts right up to the time when the task is actually completed. Total loat can be reduced, for example, as a result of a conscious decision to delay the planned start of a task as part of the resource scheduling process (in order to achieve a smoother workload plan). There is also the risk that preceding tasks will run late, absorbing some or all of the total loat previously possessed by the current task.

For practical purposes, once a project is started the project manager is not interested in the total loat that a task had in the beginning of the project, when the network was first drawn. It is the residue of the total float still possessed by each uncompleted task that should concern the project manager. This is the remaining float.

Tasks with zero remaining float

Tasks which have zero remaining loat have become critical tasks. They should claim priority for resources and for management attention to ensure that they are inished without delay. Otherwise the project completion must itself be delayed.

Tasks With Negative Float

Suppose that the critical path through a network has a total estimated duration of 100 weeks. The end task will therefore have an earliest possible completion time of 100 weeks. Barring other considerations, the latest permissible completion time for the project will also be at the end of the 100th week. Time analysis will, in the usual way, produce one or more critical paths back through to the start of the network in which all the critical tasks have zero total loat. Suppose, however, that those ‘other considerations’ include a promise to the customer that the project will be completed in only 90 weeks. The latest permissible project end date is therefore ten weeks before its earliest possible date. If 90 weeks is substituted as the latest permissible date for completion of the inal task, the backward pass through the network will now reduce the loat of all those activities on the critical path from zero to minus ten weeks.

Negative float can be caused whenever impossible scheduled target dates are imposed on the end task, or indeed on any other task in a project network. Negative float will appear in any schedule (including those computer printouts produced by software which has the capability of reporting it) where it is impossible to achieve scheduled target dates for the following reasons:

  1. The shortest possible duration of the relevant path through the network to a task bearing an imposed target date is longer than the time allowed by the target date (that is, an impossible target has been set).

  2. Delayed progress prevents one or more tasks being inished by their latest permissible inish dates.

  3. Tasks have to be delayed beyond their latest permissible dates because resources are inadequate.

 

Needless to say, tasks with negative float have become hypercritical. Prompt management action is essential in attempting to expedite them and rescue the project.

Two Fundamental Priority Rules for Resource Scheduling

The approach to resource scheduling must usually be governed by the choice between two planning options or priority rules, namely whether the schedule should be resource-limited or time-limited. These options occurred in the garage project earlier in this chapter, but they require further explanation. The choice between these two rules must be made whenever there is a clash between meeting a project completion date and finding the necessary resources.

Figure 15.7 is a graphical illustration of the resource- and time-limited concepts. The balloon represents a project, which should be imagined as an incompressible luid of constant volume being squeezed between the two main constraints of time and resources.

 
Figure 15.7 Time-limited versus resource-limited rules for resource scheduling

graphics/fig15_7.jpg

Resource-Limited Scheduling

Resource-limited scheduling results in a plan that never exceeds the declared levels of available resources. This often means accepting a project end date that is later than the earliest possible date predicted from network time analysis. In other words, working within available resource levels is seen as the irst scheduling objective, with secondary priority for completing the project in the shortest possible time. This condition is shown in the upper diagram in Figure 15.7.

Time-Limited Scheduling

If the completion time is the paramount objective, the planning procedure must be time-limited. The overriding objective in this case is to ensure that the project can be scheduled for completion by a speciied date. This date is often the earliest possible completion date indicated by network time analysis (the duration of the critical path) but it might be some slightly later target date.

Time-limited scheduling means that any predicted resource overloads must be accepted, probably on the assumption that these can be made good by hiring subcontract labour or by making other suitable short-term resource arrangements. Even though resource constraints are seen as having secondary priority in a time-limited schedule, the planner should still aim at a smooth resource usage pattern, avoiding unnecessary interruptions, peaks and troughs in the workload patterns of all the project resources. The time-limited condition is depicted in the lower half of Figure 15.7.

Methods for Easing the Resource and Time Restrictions

If neither strict resource limitation nor time limitation fail to produce an acceptable schedule, it might be necessary either to breach the limits or, alternatively, attempt to ease them to allow a compromise solution.

Using threshold resources to extend the resource availability limit

Sometimes it is possible to consider a second tier, or ‘threshold’ level of a particular resource, to be used in schedules only when all the normally available resources have been allocated to tasks, and when the project timescale would otherwise be at risk. An example would be an engineering department with a declared resource strength of 75 permanent staff employees, where the engineering manager knows that an additional 30 engineers could be made available from various subcontract agencies.

When a computer is used for scheduling with threshold resources available, it first attempts to generate a schedule that only uses the normally available resources. The additional resources are only brought into play when the computer is unable to schedule a task without exceeding the stated amount or ‘threshold’ of normally available resources. The schedule might still exceed the target completion date, but at least the use of threshold resources can take some of the strain, as shown in the lower part of Figure 15.7.

In the case of the engineering department, the engineering manager would receive a computer report showing how many of the 30 subcontract people are expected to be needed, with the dates. This should enable the manager to negotiate with the subcontract agencies well in advance for the supply of the additional engineering staff. It would also give the company time in which to arrange for the hire of any necessary accommodation and equipment for them. This is another example taken from real life, where the system worked eficiently, prevented last minute panics, and allowed plenty of time for seeking subcontracted staff and facilities from the most cost-effective sources.

Specifying alternative resources

It sometimes happens that the start of a task has to be delayed because the speciied resource is not free, although there exists in the project organization another type of resource that could be substituted. This state of affairs could occur, for example, in an engineering ofice. It might be that a specialist in electronic engineering also has skills in control and lubrication design. Some computer programs allow the planner to specify such alternative resources in the initial plan, so that the computer can take advantage of their availability in time of need.

Allowing project end-slip

Some computer software allows the planner to declare an element of acceptable project slip, beyond the preferred target completion date. The computer is then able to make use of this extra time if, but only if, resource limits would otherwise be exceeded in a time-limited scheduling calculation. Such end-slip is not counted during time analysis, and loat is still calculated from the normal end of the project. Thus if, for instance, a slip period of eight weeks is allowed after the last project task, the calculated critical path length will exclude this eight weeks: otherwise eight weeks of artiicial loat would be created to give everyone involved on the project a false sense of security.

In the top part of Figure 15.7 the computer has not been able to contain the project within the permitted slip, and the project is scheduled to end late because of the resource limitations.

This kind of facility does not exist in all the popularly available software.

Summary: The Elements of a Practicable Schedule

An Example of How Not to Schedule

An engineering director I once knew called for a departmental plan, drawn on a sheet of paper covering a long reference table, which was supposed to allocate 30 engineers (identified by their names) to jobs from several projects (actual project orders and expected future orders) at weekly intervals covering a period of no less than two years ahead. This elaborate chart therefore needed about 3,000 pencilled entries. It cost about ten days of a highly paid chief engineer’s time and involved detailed discussions with the engineering director and other senior people.

The schedule did look quite impressive when it was inished, but it was completely inlexible and virtually impossible to update. Not surprisingly, it became outdated and totally useless after only a few weeks. Even if the work plans had been soundly based (which they were not) it is always ludicrous to expect to be able to allocate named individuals to specific jobs on precise dates so far into the future. Even if all expected orders for new projects had been received (they were not), and all the jobs did by some chance happen to materialize in the particular weeks shown on the plan, there would still be a large question mark regarding how many of the 30 named engineers would continue to be employed by the company. In fact, that particular irm was wound up with big debts before the two years covered by the plan had expired.

How It Should Be Done

Here is a checklist for a practicable schedule:

  1. Does the plan include all known major tasks?

  2. Is the plan drawn in enough detail to generate work-to lists?

  3. Are all tasks placed in their logical chronological sequence?

  4. Have task interdependencies been respected?

  5. Is the plan easy to understand and is it visually effective?

  6. Is the plan flexible and easy to adapt to take account of changes to project requirements or strategy?

  7. Are the project milestones shown?

  8. Are all the duration estimates feasible and achievable?

  9. Are urgent and high-priority tasks clearly highlighted?

  10. Have key managers and supervisors participated in the plan and accepted it as their commitment?

  11. Can the plan be used to check day-to-day progress?

  12. Has the plan been made to take account of resources?

  13. Have the resource needs of other projects been considered?

  14. Will it satisfy all the stakeholders’ expectations?

A point has now been reached in this text where most of the methods necessary to meet the above conditions have been described. Manual scheduling methods will not provide the lexibility needed to meet all the above conditions (Item 6), but once a computer is introduced all the above conditions can be satisied.

The following chapter continues this subject of planning and resource scheduling and is based on the assumption that a computer, loaded with capable project management software, will be used. Chapter 18 is concerned more specifically with such computer applications.

References and Further Reading

59 

Devaux, S. A. , (1999), Total Project Control: a Manager’s Guide to Integrated Planning, Measuring and Tracking, New York, Wiley (this text is practical throughout and is far better than most in its definitions of float and examples of complex precedence relationships).

60 

Kerzner, H. , (2009), Project Management: A Systems Approach to Planning, Scheduling and Controlling, 10th edn, Hoboken, NJ, Wiley.

61 

Meredith, J. R. , and Mantel, S. J. Jnr. , (2003), Project Management: a Managerial Approach, 5th edn, (international edition), New York, Wiley.

Submit your own content for publication

Submit content