We now turn to the fifth function, managing time, by which the project manager coordinates the efforts of those involved, delivers the change to meet market opportunities, and so ensures revenues are derived at a time which gives a satisfactory return on investment. All three of these purposes for managing time imply it is a soft constraint on most projects. Being late reduces the benefit; it does not cause the project to fail absolutely. There are only a few projects for which there is an absolute deadline. Project Giotto, the space craft which intercepted Halley's comet in 1986 was one: there was a very small time window in which to make the rendezvous, and if missed it would not reoccur for 76 years.1 Another is the preparation for the Olympic Games. The start date is known six years in advance, to the nearest minute, and to miss that minute would be embarrassing, not to mention play havoc with the TV schedules. Such projects are rare. Unfortunately many project managers treat time management as being synonymous with project management, and much of the project management software is written on this assumption.
In the next section, I consider the purpose of managing time, define the concepts and terminology of the time schedule, and introduce tools for communicating the schedule, including activity list and bar charts. I describe how to calculate the duration of work elements, and how to use networks to calculate the overall project duration. I then show how to adjust the schedule by balancing resource requirements and resource availability, and end by describing the use of the schedule in controlling the duration of a project.
The time schedule is a series of dates against the work of the project, which record
When we forecast the work will occur
When the work actually does occur
Purpose of the Schedule
The purpose of recording these dates and times is
To ensure the benefits are obtained at a timescale which justifies the expenditure
To coordinate the effort of resources
To enable the resources to be made available when required
To predict the levels of money and resources required at different times so that priorities can be assigned between projects
To meet a rigid end date
FIGURE 9.1 Timing of minimum cost of a project.
The first of these is the most important. It addresses the raison d'être of project management, achieving the overall purpose. The second is the next most important as it enables the project to happen. The third and fourth are variations. It is the fifth item that gets most attention from project managers. They set a rigid end date, sometimes unnecessarily, and focus on this to the detriment of cost and quality. Part of the aim of managing the time is to optimize the cost and returns from the project. Figure 9.1 shows that the cost is made up of two elements:
A work-dependent element: 100 days of effort is the same whether 5 people take 20 days or 2 people take 50 days.
A time-dependent element: the project manager's salary for instance.
However, the work-dependent element does increase as you try to shorten the project, and people interfere with each other; 10 people take 12 days, and 20 people 8, perhaps. Adding the two gives an optimum time window for the project in which cost is minimized. Figure 9.2 shows that maximum returns may not correspond to minimum cost. The value of the asset may decay with time, because of limited market windows and hence highest profit may be made at a time earlier than minimum cost. Through the time schedule we must optimize cost and benefit.
The Schedule
On a simple level, the schedule records the planned and actual start date, finish date, and duration of each work element. We may also record whether there is any flexibility in when each element may start without delaying the completion of the project. This is called the float. Sophisticated schedules record up to five versions of each of the start date, finish date, duration, and float: the early, late, baseline, scheduled, and actual dates.
The Duration. This is the time required to do the work. It is common to treat a work element's duration as a fixed given. For some, it is dependent on external factors beyond the control of the team. For others, it is a variable, and can be changed by varying the number of people working on the activity, or by other means. Before work starts for each activity
FIGURE 9.2 Timing of optimum return from a project.
we estimate its duration. Once work starts, but before it finishes we can estimate remaining duration. This may be equal to the planned duration less the time since the activity started, or we may reestimate remaining duration based on the knowledge gained from doing the work so far. Once work is complete we can record an actual duration. It is useful to record actuals because a comparison of planned and actual figures may indicate trends which may be useful in the control process.
Early and Late Dates. These are forecast from the estimated duration of all activities. The start of an activity may be dependent on other work finishing. Therefore there is an earliest date by which an activity may start. This is known as the early start date. The early start date plus the estimated duration is the early finish date, the earliest date by which the work can finish. Similarly, other work may be dependent on the activity being finished, so there is a latest date by which it can finish and not delay completion of the project. This is known as the late finish date, and correspondingly the late start date is this less the duration. If the late start date is different to the early start date, there is flexibility about when the element can start, the float:
Float = late start date – early start date
If the duration is fixed, the difference between early and late start and early and late finish is the same (and indeed this is the assumption made in most scheduling systems). However it is not too difficult to imagine situations where the duration is dependent on when the work is done and we will then get different answers if we calculate float using finish dates.
A work element with zero float is said to be critical. If a project is scheduled with minimum duration, then running through it will be a series of work elements with zero float. This series is known as the critical path, and the duration of the project will be equal to the sum of the durations of the work elements along the path. Work elements with large float are known as bulk work. They are used to smooth forecast resource usage, by filling gaps in the demands made by the critical path. There are also work elements with very small float. These are near critical, and should receive as much attention as the critical path. Section 9.3 describes the critical path method (CPM) networks, which are mathematical tools for calculating early and late start and finish, and float.
Planned, Baselined, and Schedule Dates. Planned dates are dates between the early and late dates when we choose to do the work. However, the date we planned to do a work element at the start of the project may be different to our current plan. It is important to record the original plan, because that is the measure against which we control progress. This original measure is commonly known as the baseline date, and the current plan as the scheduled date. If the baseline start is later than the early start, then the planned or baseline float will be less than the available float. Likewise, as a project progresses, if the start or finish of a work element is further delayed, then the remaining float will be less than the original float.
The Total Schedule. Hence, there are up to fifteen dates and times associated with a work element (Table 9.1). The process of scheduling the project is the assignment of values to these dates and times. First you estimate the duration and then assign start and finish dates. This is usually done by calculating the early start and late finish dates and then assigning baseline dates somewhere between these, after taking account of other factors such as resource smoothing. It is sometimes necessary to assign a finish date after the late finish and thereby delay the project. If the logic is correct it will be impossible to schedule the start before the early start.
For some projects with a well-constructed work breakdown structure (WBS), you can schedule the project manually, by nesting the schedule at lower levels within that at higher levels. To do this you need to break the project into discrete work areas and work packages, with few logical links between them and little sharing of resources. The four large multi-disciplinary projects described in Sec. 5.5 were like that. In the Regional Health Authority warehouse and the Norwegian Security Centre projects, the project managers positively resisted computer systems because they felt they retained greater visibility without them. Where there are complex interdependencies and multiple shared resources, it may be necessary to use computer-aided support tools.
Communicating the Schedule
There are two accepted ways of communicating a project's schedule:
Activity Lists with Dates. This is a list of some of the work elements at a given level of the WBS, with dates listed beside them. This method of communicating the schedule gives a comprehensive check list, but is not very visible. Table 9.2 is an activity listing for a simple project to erect a statue. Although this list shows the float, I believe it should not be shown as it tends to be consumed. The responsibility chart (Figs. 6.5 and 6.6) is effectively an activity listing.
TABLE 9.1 Fifteen Time Elements of the Schedule of a Project
| ||
Early start | Duration | Early finish |
Late start | Float | Late finish |
Baseline start | Baseline float | Baseline finish |
Schedule start | Remaining float | Schedule finish |
Actual start | Remaining duration | Actual finish |
| ||
Where Planned duration = planned finish - planned start Planned float = late finish - planned finish | ||
TABLE 9.2 Activity Listing for a Project to Erect a Statue 1
| |||||
Landscape Ltd | |||||
| |||||
Project |
| Erect statue |
| ||
|
| ||||
Activity | Duration | Early start | Early finish | Float | |
|
| ||||
No | Name | Days | Day | Day | Days |
| |||||
A | Grade site | 3 | 0 | 3 | 0 |
B | Cast plinth | 2 | 3 | 5 | 0 |
C | Plant grass | 3 | 3 | 6 | 1 |
D | Set concrete | 2 | 5 | 7 | 0 |
E | Place statue | 1 | 7 | 8 | 0 |
| |||||
Bar Charts. The schedule can be more visibly represented using bar charts, (sometimes called Gantt charts, after Henry Gantt who pioneered their use in routine operations management). Figure 9.3(a) is a simple bar chart for the project in Table 9.2. This is what I think you should show to the project team to tell them when you want the work to be done. Figure 9.3(b) is the same bar chart with the float shown. It is also possible to show the logic in a bar chart, Figure 9.3(c). These second two are useful planning tools for the project manager and project planners. I do not believe in showing the project team the float, for exactly the same reason you should ask them to work on the raw estimate (Table 8.5); it tends to get consumed. You can show the team which work is critical and which is not, as shown in Fig. 9.3(a), but ask them to work on the planned dates, and come back and negotiate extra time for noncritical activities if they need it.
Once work has started, we can also draw a tracked bar chart, Fig. 9.3(d). The original schedule has now been converted into the baseline plan, the upper set of bars in each pair. The lower set is the actual dates and current schedule (actual before time now and current schedule after time now). In this way the team are given realistic dates to work to, but they can see the original schedule (baseline), and so control is maintained.
FIGURE 9.3 Bar charts for the activity listing in Table 9.2.
The duration of work elements is central to scheduling, not only in relating the start and finish of a given work element, but in calculating its earliest start from the cumulative duration of the preceding activities, and the latest finish from the cumulative duration of the succeeding activities. The duration of a work element is dependent on one of three things:
1. The amount of time it physically takes to do the work involved, which in turn is dependent on the number of people available to do it.
2. The lead time, or waiting time, for the delivery of some item is independent of the number of people doing the work.
3. Some mixture of the two.
Duration Dependent on Work Content
It is often assumed the duration of a work element depends on the amount of work to do and the number of people available to do it. Nominally:
I described the role of work content in negotiating the contract between project manager and resource providers in Chap. 6 and how to estimate it as a labour cost in Chap. 8. It is always necessary to add allowances to this raw estimate of duration, to calculate the actual duration. These allowances are to account for various factors, which include
Time lost through nonproject activities
Part-time working
Interference between people doing the work
Communication between people doing the work
Lost Time. Somebody nominally working full-time on a project is not available 5 days/week, 52 weeks/year. They lose time through holidays, sickness, training, group meetings, and the like. It is suggested that for the average project worker these consume 80 days/year; somebody assigned full-time to a project does on average 180 days of project work a year, equivalent to 70 percent availability. To allow for this 40 percent is added to the nominal duration (1.4 = 1.0/0.7). A smaller ratio will be added if the project's resource calendar allows for some lost time.
Part-Time Working. Individuals may be assigned to a project part-time. However, you must be careful not to double account. If somebody is assigned two days per week to a project, 40 percent, you must be clear whether those two days include or exclude a proportion of the lost time above before adding the 40 percent allowance.
Interference. Doubling the number of workers does not always halve the duration, because people doing work can restrict each other's access to the work face, and so reduce their effectiveness. For instance, if the task requires access to a limited space with room for just one person, adding a second person will not double the rate of working. Two will work faster than one, because they can step each other off, but only one can work at a time. Adding a third person will not increase the rate of working, and may even reduce it by distracting the other two. A third person would be most effectively used to extend the working day through a shift system.
Communication. Where more than one person work on a job, they need to communicate details of the work to each other to make progress. This is especially true of engineering design and writing software. With two people there is just one communication channel, so they may work almost twice as fast as one. With three people there are three channels, with four people six, and as the number of people grows, the channels grow as the square of the number of people. Hence, you reach a point where adding another person in fact reduces the amount of effective work (Example 9.1). The way to overcome this is to find ways of reducing the channels of communication, by using a central administrator or project support office (Chap. 16). In the office in Example 9.1, the pool was split into four pools of three secretaries. It is commonly believed that in a professional office, three is the optimum team size, balancing the additional motivation from working in a team, with the added levels of communication.
Example 9.1 Communication consumes time
In an office I worked in, there were three managers each with a secretary. As the office grew, and new managers joined, the numbers of secretaries grew, until there were about twelve working in the same pool. We reached a point where adding a new secretary seemed to make no difference to the amount of work done in the pool. If we assume a new secretary spends a quarter of an hour each day talking to each of the others, (not an unreasonable amount of time for social interaction), then each conversation consumes half an hour's work, and since he or she has twelve conversations, six hours is lost, equal to the effective working day.
Estimating Durations. Hence the estimate of duration for a work element is based on the formula above, but adjusted taking account of all the factors discussed, which may indeed dominate. This just reinforces that project management is not a mathematical exercise, but much more of a social science.
Duration Dependent on Lead Time
For some work elements the duration depends on the lead time or waiting time to obtain some item of material or information or to wait for some change to take place. This may include
Delivery time for materials in procurement activities
Preparation of reports
Negotiations with clients or contractors
Obtaining planning permission or financial approval
Setting of concrete or watching the paint dry
Duration Dependent on Work Content and Lead Time
In some instances a work element contains lower-level activities, some of which are work dependent and some lead-time dependent (Example 9.2). The duration of the work package must be calculated from the duration of each of the activities and their logical dependence, perhaps using the networking techniques described in Sec. 9.3 in more complex cases.
Example 9.2 A work package from the CRMO Rationalisation Project containing activities of mixed type
The work-package, O5: Redeployment and Training, from the CRMO Rationalisation Project may consist of the following activities:
1. Identify training needs of staff
2. Develop training material
3. Conduct courses
4. Transfer staff to new posts
The first two of these are work dependent. The number of trainers assigned depends on the number of people requiring training and the amount of material to be developed. However, two people will not work twice as fast as one since they need to keep each other informed of progress. The duration of the third activity depends on the availability of training facilities, and the fourth on how quickly people can be assimilated into new work environments.
Estimating Sheets
The estimating sheet (Table 9.3) is a tool which can be used for estimating work content and durations. Table 9.3 shows the calculation of milestone P1 of the CRMO Rationalization Project. Example 9.3 provides a rationale.
Example 9.3 Rationale for the duration of the work package P1: Project Definition
The person with the most work to do is the project control officer, with 24 days of effort. The duration of the work package will be determined by his or her availability. It is assumed during project definition he or she will not take holiday. Therefore his or her availability will be greater than the average 70 percent. A figure of 80 percent is assumed. The duration is therefore 30, (24/0.8), days.
9.3 CALCULATING THE SCHEDULE
WITH NETWORKS
Having estimated duration, we assign dates to work elements. I believe that on majority of projects, that can be done manually using bar charts. However, with larger more complex projects that is more difficult, and computer-aided techniques help with the calculations. The simplest of these are based on a mathematical technique called variously the critical path method (CPM), critical path analysis (CPA), or the program evaluation and review technique (PERT). The initials CPM, CPA, and PERT are used interchangeably by many people, although they do mean something slightly different. At their core is network analysis. Networks are a mathematical technique used to calculate the schedule. They are seldom useful for communicating the schedule. Bar charts or activity listings (Sec. 9.2) are best for that. Networks will only be used where the project is too complex to be scheduled manually through the WBS and so will only be used in conjunction with computer-aided systems. However, I think it is useful to know the mathematics behind the analysis.
CPM, CPA, and PERT are themselves only useful on projects of lower complexity. They are linear and deterministic; D follows C follows B follows A, with no looping back,
TABLE 9.3 Estimating Sheet with Durations Entered for the Milestone P1: Project Definition from the CRMO Rationalisation Project
Estimating sheet with durations entered for the milestone P1: Project Definition from the CRMO Rationalisation Project
and no branching depending on what happens at a certain step. On more complex projects still, where at a certain step several possible things can occur depending on what happens at that step, and where feedback loops can occur, more sophisticated modelling techniques are necessary,2 but they are beyond the scope of this book.
In this section, I describe the mathematical technique of networking.
Types of Network
There are three types of network:
Precedence networks (also called activity-on-node networks)
Activity-on-arrow networks (sometimes called IJ networks)
Hybrid networks
Precedence Networks. In precedence networks, work elements are represented by boxes, linked by logical dependencies, which show that one element follows another. Figure 9.4 is a simple precedence network with four activities A, B, C, and D. B and C follow A and D follows B and C. Four types of logical dependency are allowed (Fig. 9.5):
End-to-start: B cannot start until A is finished.
End-to-end: D cannot finish until C is finished.
Start to-start: D cannot start until C has started.
Start-to-end: F cannot end until E has started.
FIGURE 9.4 A simple precedence network.
FIGURE 9.5 Four types of logical dependencies.
End-to-start dependency is usually used, (a hangover from IJ networks). End-to-end and start-to-start are the most natural and allow overlap of succeeding work elements in time. It is not uncommon to build ladders of activities like C and D. It is the use of end-to-end and start-to-start dependencies which allows fast-track or fast-build construction (Sec. 3.5). Start-to-end are only defined for mathematical completeness. I have never come across a case where it might be used. I will introduce later leads and lags on dependencies. I suggest you use only end-to-start dependencies, and use leads and lags to overlap activities. This greatly simplifies the network. The milestone plan (Sec. 5.3) is a precedence network. The circles, nodes, represent the work. The lines are end-to-end dependencies, linking the milestones.
Activity-on-Arrow Networks. These are often called IJ networks, because each activity is defined by an IJ, start/finish, number. In this type of network each work element is represented by an arrow between two nodes. The activity is known by the number of the two nodes it links. Figure 9.6 is Fig. 9.4 redrawn as an IJ network. Activity A becomes 1-2, and so on. Because activities must be uniquely defined two cannot link the same two nodes. Therefore, B and C finish in nodes 3 and 4, respectively, and these nodes are linked by a dummy activity. Because activities are linked through nodes, end-to-start logic is imposed. However, it is possible to introduce dummy activities to represent the other three logical links.
Hybrid Networks. These mix the two previous types. Work is represented by either a box (node), or a line (arrow). Furthermore, there may be boxes and lines which do not represent work, just events in time and logical dependency. A line need not join a box at its start or finish, but at any time before, during or after its duration. In advanced hybrid networks, even the distinction between nodes and lines disappears. Hybrid networks are rare, so cannot be discussed further.
Precedence versus Activity-on-Arrow Networks. You will find some people fervently committed to one or the other. The very early work on network analysis in the late 1940s was done with arrow networks, whereas precedence networks were not introduced until the mid-1950s. Therefore arrow networks tend to be the default option. However, precedence networks are often preferred by practising project managers. There are several reasons for this:
1. It is more natural to associate work with a box.
2. It is more flexible for drawing networks. All the boxes can be drawn first and the logical dependencies added later. In Sec. 5.3, I described how to develop a precedence network, milestone plan, by moving Post-Its around a flip-chart or white board. The same is not possible with an activity network since the activities are only defined by two nodes and that imposes logic.
3. It is easier to write network software for precedence networks. Most modern softwares are precedence only or both. That which is both has an algorithm to convert from precedence to IJ.
FIGURE 9.6 Activity-on-arrow network.
4. It is easier to draw a bar chart showing precedence logic with the bars representing the activity boxes and vertical lines showing the logical dependencies [Fig. 9.3(c)]. With an arrow network either more than one activity must be drawn on a line or dummies must be used to show logic, which virtually gives a precedence network. (This last statement reintroduces hybrid networks, and shows that the distinction between precedence and IJ networks really is slight.)
5. The work exists independently of the logic, and so you can draw a work breakdown structure and overlay the logic later. (People who use IJ networks have to draw the network before developing the work breakdown structure.)
Networking Technique
All networks do is to calculate the early start and finish, the late start and finish and the float of work elements in a project, given their duration and logical dependency. The reason this is useful is it allows you to explore many different options, called conducting a "what-if" analysis, assuming different durations and logical dependencies of the work elements. As I introduce networking technique, I will illustrate it by scheduling a simple project, represented by the network in Fig. 9.4. An activity listing for the network is given in Table 9.4. This is modified Table 9.2 and you will see shortly that the activity, "set concrete" has been replaced by a lag on the logical dependency from B to D.
Notation. In a precedence network, each work element is represented by a box with seven segments (Fig. 9.7). The top three segments contain the early start, duration, and early finish, respectively. The bottom three contain the late start, float, and late finish. The central one contains a description of the activity. Figure 9.8 is Fig. 9.4 with durations entered. In an arrow network the node has four segments, the identifier, the early and late time, and the float. The time is the start of the succeeding activity and the finish of the preceding activity. The duration is still associated with the activity (Fig. 9.9).
Leads and Lags. The dependencies connecting the activities in a precedence network usually have zero duration. However, they can be given positive or negative duration, and this is called lag or lead, respectively. In Table 9.4, the concrete must be left for two days to dry before erecting the statue. These two days can either be added to the duration of B (taking it to four days) or shown as a lag on the dependency. Similarly it might be possible to start planting grass on the second day after the first third of the
TABLE 9.4 Activity Listing for a Project to Erect Statue 2
| ||||
Landscape Ltd | ||||
| ||||
Project |
| Erect statue |
| |
|
| |||
Activity |
|
|
| |
| Duration | Preceding | Lead/lag | |
No | Name | days | activity | day |
| ||||
A | Grade site | 3 | – | 0 |
B | Cast plinth | 2 | A | –2 |
C | Plant grass | 3 | A | 0 |
D | Place statue | 1 | B, C | +2, 0 |
| ||||
FIGURE 9.7 Activity in a precedence network.
site has been graded. This can be shown as a start-to-start dependency with a lag of 1 or a finish-to-start with a lead of –2. The latter is chosen. The leads and lags are also shown in Fig. 9.8.
Forward Pass. Early start and finish are calculated by conducting a forward passthrough the network. The early start of the first activity is zero and the early finish is calculated by adding the duration. The early finish is transferred to subsequent activities as the early start, adding or subtracting any lead or lag, assuming a finish to start dependency. For a start-to-start dependency it is the start time which is transferred to the start, for a finish-to-finish dependency the finish time to the finish, and for a start-to-finish the start time to the finish. Where an activity has two or more preceding activities the largest number is transferred. The process is repeated throughout the network. Figure 9.10 shows the example network after a forward pass.
Back Pass. The late start and finish and float are calculated by conducting a back pass. The early finish of the last activity becomes its late finish. The duration is subtracted to calculate the late start. The late start is transferred back to the late finish of preceding activities. Again it is the start or finish time which is transferred to become the start or finish time
FIGURE 9.8 Precedence network: durations entered.
FIGURE 9.9 Activity in an IJ network.
depending on the type of dependency. Where an activity has two or more succeeding activities it is the smallest number which is transferred, after adding lags or subtracting leads. The process is repeated throughout the network. The float of each activity is calculated (Sec. 9.2). (This should be the same for both start and finish.) The float of the first and last activities should be zero. Figure 9.11 shows the network after the back pass.
Identifying the Critical Path. This is the series of activities with zero float, here A-B-D.
Arrow Networks. Figure 9.12 shows the drawn as an arrow network after forward and back pass.
Case Study Project. Figure 9.13 is the precedence network (at work-package level) for the CRMO Rationalization project.
Software Packages. Some software packages assume that if an activity has a start date of day six, (Monday say), and duration three, then it will finish on Wednesday evening, day eight. Therefore the finish is
Finish date = start date + duration – 1.
However, if there is no delay to the start of the next activity, it starts on Thursday morning, day nine, and so one is added to the finish date as it is transferred to be the start date of
FIGURE 9.10 Network after forward pass.
FIGURE 9.11 Network after back pass.
the next activity. The start date of the first activity is taken as day one, Monday morning, rather than zero as I have used above. The overall effect is just to add one to all the start dates you would obtain using the method I have proposed above.
Scheduling the Project
The network only calculates early and late dates. The baseline or scheduled dates must be chosen taking account of other factors. Hopefully they will be between the early and late dates. There are three options:
Schedule by early start (hard-left): used to motivate the workforce
Schedule by late finish (hard-right): used to present progress in the best light to the customer
Schedule in between: done either to smooth resource usage (Sec. 9.4) or to show management the most likely outcome
FIGURE 9.12 Arrow network after forward and back pass.
FIGURE 9.13 Precedence network at work-package level for CRMO Rationalization Project.
Networks are a mathematical tool to be used as appropriate. This does not depend on the size of the project. In Sec. 5.5, I gave examples of multimillion pound projects where they were not used. It depends on the complexity of the interdependencies and resource sharing and the manager's ability to analyze these without computer support. As a mathematical tool, they help the manager calculate the schedule and analyze the impact of changes, what-if analysis. However, networks should not be used to communicate the plan or schedule. Bar charts, activity listings, or responsibility charts should be used for that.
9.4 RESOURCE HISTOGRAMS AND RESOURCE
SMOOTHING
Using a network, you can calculate the early and late start and finish for work elements. However, in order to set the baseline or scheduled dates, it is necessary to take account of other constraints. Resource constraints are the most common. If the resource requirements for all activities are known then, once the project has been scheduled, you can calculate a resource profile for the project as a whole. This is known as the resource schedule and is either listed as a table of resource levels with time or is drawn as a resource histogram. This resource schedule can be compared to the known availability of each type of resource, and if the requirement exceeds availability it may be necessary to adjust the schedule to reduce the requirement. It may be possible to do this by consuming some of the float on noncritical activities. Alternatively, it may be necessary to extend the duration of the project.
Table 9.5 is an activity listing for a small project which I will use to illustrate the concept of resource scheduling. There are two resource types: analysts and programmers. Figure 9.14(a) shows the bar chart and resource histogram for both resource types with the project scheduled by early start. This produces quite wildly varying resource levels. If there were only one analyst available to the project, he or she would be overloaded during the first two months of the project. One person can work up to 22 days in a month without overtime. To overcome this problem we can try to use the float associated with some of the work elements
TABLE 9.5 Activity Listing for a Project with Resources
| |||||||
TriMagi | |||||||
| |||||||
|
|
|
|
|
| Resource requirement | |
|
| Early | Late | Early | Late |
| |
| Duration | start | start | finish | finish | Analyst | Programmer |
Activity | (mths) | (mth) | (mth) | (mth) | (mth) | (days) | (days) |
| |||||||
A | 3 | 0 | 1 | 3 | 4 | 24 | 0 |
B | 2 | 0 | 2 | 2 | 4 | 24 | 0 |
C | 2 | 0 | 2 | 2 | 4 | 16 | 16 |
D | 1 | 3 | 4 | 4 | 5 | 0 | 12 |
E | 1 | 0 | 3 | 1 | 4 | 0 | 4 |
F | 4 | 0 | 0 | 4 | 4 | 16 | 0 |
G | 1 | 4 | 4 | 5 | 5 | 12 | 8 |
H | 1 | 5 | 5 | 6 | 6 | 4 | 8 |
| |||||||
FIGURE 9.14 Resource smoothing.
to smooth the resource profiles. Figure 9.14(b) shows the bar chart and resource profiles for the project scheduled by late start. This is no better as the analyst is still overloaded, but now in months three and four. Concentrating on the analyst, Fig. 9.14(c) shows a schedule which gives the least variability of the analyst's utilization, giving a maximum level of 24 days in month three. This can be easily met by overtime. It also illustrates two further points:
The danger of imposing a rigid resource constraint of 22 days which would delay the project
The need to encourage the analyst to take his annual holiday in months five and six rather than months one to three
Alternatively you can take the programmer as priority. Figure 9.14(d) shows the schedule and resource profiles in that case. However, this overloads the analyst again.
So far I have explained how to calculate and communicate the schedule. I conclude by discussing how to use the schedule to control the project's duration, which is its primary purpose. I describe the control process and tools to visually represent progress.
Control Cycle
There are four steps in the control process (Sec. 7.2):
Set a measure.
Record progress.
Calculate the variance.
Take remedial action.
Set a Measure. The planned, or baselined, dates set the measure for control of time. It is vital to measure progress against a fixed baseline. If you measure progress against the most recent update of the plan you lose control. It is not uncommon to come across projects which are always on time, because the schedule is updated at every review meeting, and people very quickly forget what the original schedule was; they can remember that the schedule has been updated, but not by how much.
Record Progress. Progress is recorded by reporting actual start and finish dates. In Sec. 5.1, I suggested that at the activity level you record actual start and finish dates only. It is problematic to report percentage completion, although team members should report how much work they have left to do to complete the activity for cost control purposes (Sec. 8.4). Progress data can then be rolled up to the work package level to calculate percentage completion of the work package, and forecast its completion date, that is, the date the milestone will be achieved.
Calculate the Variance. The variance is calculated either in the form of delays to completion of critical, or near critical, work, or as the remaining float of subsequent activities. Forward-looking control (Sec. 8.4) focuses on the remaining float of subsequent work, or on future delays to the start of critical or near critical work. That is what we can do something about. Delays to critical or near critical work have an impact on the remaining float of subsequent work, and when the remaining float of a subsequent work element becomes negative, that extends the forecast completion date of the project. It is important to monitor near critical work, and not focus solely on the critical path. The mathematical exactitude of the network can produce an undue focus on one area of the project, whereas it may be one of several other near critical paths which determines the duration of the project, and it was only estimating error that caused one of these to be identified as the critical path. Indeed, if you focus all your management attention on one path, you can guarantee another will determine the duration.
Where delays occur to bulk work, it will have little effect on the remaining float of future activities, until it has been delayed so much that it is itself critical. Indeed, resources may be switched from bulk work to critical work to maintain progress on the latter. However, if bulk work becomes significantly delayed, resource availability may determine the duration of the project, not the logic of the critical path.
In order to determine the impact of any delays on the project, and any proposals for eliminating them, it is necessary to analyze the effect of each on the overall project. This is a repeat of the what-if analysis described above. If the WBS has been well constructed this analysis can often be conducted manually, by analyzing the effect of the delay on the work package within which it occurs and then the effect of the work package on the overall project. The milestone plan is a powerful tool for determining whether a work package is critical and its effect on the project. This approach gives greater management control. Alternatively, where there are complex interdependencies and multiple shared resources, the analysis can be performed using the network. This provides a more accurate picture of the effect of changes, but it is difficult to determine the appropriate changes in the first place. The network does provide a valuable support to the manual approach, avoiding oversights.
Visual Representation
There are several tools which provide a visual representation of progress on the project.
Tracked Bar Charts. Figure 9.3(d) is a tracked bar chart. It shows current progress against baseline. Figure 9.15 shows a tracked bar chart for the CRMO Rationalization Project at a point part way through the project.
Milestone Tracker Charts. A problem with the tracked bar chart is it doesn't show how much the project has slipped since the last report; it just provides a snap shot of current progress. The milestone tracker chart (Fig. 9.16) shows the change since the last report. On the horizontal axis we plot the planned completion date for each milestone. On the vertical axis we plot the report date. So at each report date we can see the current planned completion date of the milestone, and can compare it to the planned date at the last report date, and the original or baseline date shown in the first line.
This makes it very difficult for the project manager to hide what is going on in the project, and there are two things the client managers do not want to see:
1. Milestones slipping every report date: If a milestone slips, the client managers want to see the project manager make and hold a commitment to the new date, not have it slip every time.
2. Early milestones slipping and later ones being shown as not slipping: Perhaps some early milestones will not be on the critical path, but the nature of milestones is that many of them will be critical. So if early milestones slip the client managers expect the project manager to show the impact on later milestones.
FIGURE 9.15 Tracked bar chart for the CRMO Rationalization Project.
FIGURE 9.16 Milestone tracker chart for the CRMO Rationalization Project.
The milestone tracker chart is mainly used by the project manager to report progress against on the overall project. The team could use it at a lower level of WBS to report progress against activities on the packages of work they are doing.
Figure 9.16 is a milestone tracker chart for the CRMO Rationalization Project at the same reporting period as Fig. 9.14.
S-curves. S-curves, plotted as part of earned value analysis (Sec. 8.4), provide a pictorial representation of whether the project is on average, ahead of or behind schedule. The schedule variance introduced in that section is another time variance, in addition to the remaining float on critical activities.
1. The purpose of scheduling time on a project is
To obtain timely benefits which justify the expenditure
To coordinate resource inputs
To schedule resource availability
To assign priority for resources between projects
To meet a specified end date
2. The schedule specifies the duration, start and finish date, and float of the activities in the project. There are several dates recorded against each activity:
Early date
Late date and float
Baseline date and baseline float
Most likely date and remaining float
Actual date and remaining duration
3. The schedule can be communicated as:
An activity listing
Bar charts
4. The duration is calculated by comparing the work content to the number of people available, and allowing for:
Lost time
Part-time working
Interference
Communication
Lead times
Sequencing of tasks within activities
5. The early and late dates can be calculated from the durations and logical sequence of the activities using a critical path network. There are two main types of network:
Precedence network
Activity-on-arrow network
6. Given the initial schedule and resource requirements for each activity, a resource schedule can be calculated showing the requirements for each type of resource with time. This can be smoothed by delaying bulk work to fill peaks and troughs, or by extending the duration of the project. The resulting schedule is frozen as the baseline.
7. Progress against the schedule can be monitored by:
Recording progress on the critical or near critical paths
Using tracked bar charts and milestone tracker diagrams
Recording progress on S-curves
1. Morris, P.W.G. and Hough, G.H., The Anatomy of Major Project: A Study of the Reality of Project Management, Chichester, U.K.: Wiley, 1987.
2. Williams, T., Modelling Complex Projects. Chichester, U.K.: Wiley, 2002.