page 258

CHAPTER

EIGHT

Scheduling Resources and Costs

page 259

Project network times are not a schedule until resources have been assigned. Cost estimates are not a budget until they have been time-phased.

—Clifford F. Gray

We have consistently stressed that up-front planning results in big payoffs on predictable projects. For those who have diligently worked through the earlier planning processes chapters, you are nearly ready to launch your project. This chapter completes the final two planning tasks that become the master plan for your project—resource and cost scheduling. (See Figure 8.1.) This process uses the resource schedule to assign time-phased costs that provide the project budget baseline. Given this time-phased baseline, comparisons can be made with actual and planned schedule and costs. This chapter first discusses the process for developing the project resource schedule. This resource schedule will be used to assign the time-phased budgeted values to create a project budget baseline.

There are always more project proposals than there are available resources. The priority system needs to select projects that best contribute to the organization’s objectives, within the constraints of the resources available. If all projects and their page 260respective resources are computer scheduled, the feasibility and impact of adding a new project to those in process can be quickly assessed. With this information the project priority team will add a new project only if resources are available. This chapter examines methods of scheduling resources so the team can make realistic judgments of resource availability and project durations. The project manager uses the same schedule for implementing the project. If changes occur during project implementation, the computer schedule is easily updated and the effects easily assessed.

8.1 Overview of the Resource Scheduling Problem

After staff and other resources were assigned to her project, a project manager listed the following questions that still needed to be addressed:

Will the assigned labor and/or equipment be adequate and available to deal with my project?
Will outside contractors have to be used?
Do unforeseen resource dependencies exist? Is there a new critical path?
How much flexibility do we have in using resources?
Is the original deadline realistic?

Clearly this project manager has a good understanding of the problems she is facing. Any project scheduling system should facilitate finding quick, easy answers to these questions.

The planned network and activity project duration times found in previous chapters did not take into account resource usage and availability. The time estimates for the work packages and network times were made independently with the implicit assumption that resources would be available. This may or may not be the case.

If resources are adequate but the demand varies widely over the life of the project, it may be desirable to even out resource demand by delaying noncritical activities (using slack) to lower peak demand and, thus, increase resource utilization. This process is called resource smoothing.

On the other hand, if resources are not adequate to meet peak demands, the late start of some activities must be delayed, and the duration of the project may be increased. This process is called resource-constrained scheduling.

The consequences of failing to schedule limited resources are costly and project delays usually manifest themselves midway in the project when quick corrective action is difficult. An additional consequence of failing to schedule resources is ignoring the peaks and valleys of resource usage over the duration of the project. Because project resources are usually overcommitted and because resources seldom line up by availability and need, procedures are needed to deal with these problems. This chapter page 261addresses methods available to project managers for dealing with resource utilization and availability through resource leveling and resource-constrained scheduling.

Up to now the start and sequence of activities have been based solely on technical or logical considerations. For example, assume you are planning a wedding reception that includes four activities—(1) plan, (2) hire band, (3) decorate hall, and (4) purchase refreshments. Each activity takes one day. Activities 2, 3, and 4 could be done in parallel by different people. There is no technical reason or dependency of one on another (see Figure 8.2A). However, if one person must perform all activities, the resource constraint requires that the activities be performed in sequence or series. Clearly the consequence is a delay of these activities and a very different set of network relationships (see Figure 8.2B). Note that the resource dependency takes priority over the technological dependency but does not violate the technological dependency; that is, hire, decorate, and purchase may now have to take place in sequence rather than concurrently, but they must all be completed before the reception can take place.

One may ask, “Why not factor resource availability along with technical dependency when creating the original network?” First, resource availability may not be known until the initial schedule is completed. Second, even if resources are known, one could not assess the impact of resources unless a resource neutral schedule were created. For example, one would never know that the wedding could be planned in three days instead of five if three people were available instead of the assumed one. When the premise behind this simple example is applied to other, more elaborate projects, the implications can be significant.

The interrelationships and interactions among time and resource constraints are complex for even small project networks. Some effort to examine these interactions before the project begins frequently uncovers surprising problems. Project managers who do not consider resource availability in moderately complex projects usually learn of the problem when it is too late to correct. A deficit of resources can significantly alter project dependency relationships, completion dates, and project costs. Project managers must be careful to schedule resources to ensure availability in the right quantities and at the right time. Fortunately, there are computer software programs that can identify resource problems during the early project planning phase when corrective changes can be considered. These programs only require activity resource needs and availability information to schedule resources.

page 262

SNAPSHOT FROM PRACTICE 8.1

Working in Tight Places

In rare situations, physical factors cause activities that would normally occur in parallel to be constrained by contractual or environmental conditions. For example, in theory the renovation of a sailboat compartment might involve four or five tasks that can be done independently. However, since space allows only one person to work at one time, all tasks have to be performed sequentially. Likewise, on a mining project it may be physically possible for only two miners to work in a shaft at a time. Another example is the erection of a communication tower and nearby groundwork. For safety considerations, the contract prohibits groundwork within 2,000 feet of the tower construction.

iStockphoto/Getty Images

The procedures for handling physical factors are similar to those used for resource constraints.

See Snapshot from Practice 8.1: Working in Tight Places for a third constraint that impinges on project schedules.

8.2 Types of Resource Constraints

Resources are people, equipment, and material that can be drawn on to accomplish something. In projects the availability or unavailability of resources will often influence the way projects are managed.

1. People. This is the most obvious and important project resource. Human resources are usually classified by the skills they bring to the project—for example, programmer, mechanical engineer, welder, inspector, marketing director, supervisor. In rare cases some skills are interchangeable, but usually with a loss of productivity. The many differing skills of human resources add to the complexity of scheduling projects.

2. Materials. Project materials cover a large spectrum—for example, chemicals for a scientific project, concrete for a road project, survey data for a marketing project. Material availability and shortages have been blamed for the delay of many projects. When it is known that a lack of availability of materials is important and probable, materials should be included in the project network plan and schedule. For example, delivery and placement of an oil rig tower in a Siberian oil field has a very small time window during one summer month. Any delivery delay means a one-year, costly delay. Another example in which material is the major resource scheduled was the resurfacing and replacement of some structures on the Golden Gate Bridge in San Francisco. Work on the project was limited to the hours between midnight and 5:00 a.m., with a penalty of $1,000 per minute for any work taking place after 5:00 a.m. Scheduling the arrival of replacement structures was an extremely important part of managing the five-hour work-time window of the project. Scheduling materials page 263has also become important in developing products where time-to-market can result in loss of market share.

3. Equipment. Equipment is usually presented by type, size, and quantity. In some cases equipment can be interchanged to improve schedules, but this is not typical. Equipment is often overlooked as a constraint. The most common oversight is to assume the resource pool is more than adequate for the project. For example, if a project needs one earthmoving tractor six months from now and the organization owns four, it is common to assume the resource will not delay the pending project. However, when the earthmoving tractor is due on-site in six months, all four machines in the pool might be occupied on other projects. In multiproject environments it is prudent to use a common resource pool for all projects. This approach forces a check of resource availability across all projects and reserves the equipment for specific project needs in the future. Recognition of equipment constraints before the project begins can avoid high crashing or delay costs.

8.3 Classification of a Scheduling Problem

Most of the scheduling methods available today require the project manager to classify the project as either time constrained or resource constrained. Project managers need to consult their priority matrix (see Figure 4.2) to determine which case fits their project. One simple test is to ask, “If the critical path is delayed, will resources be added to get back on schedule?” If the answer is yes, assume the project is time constrained; if no, assume the project is resource constrained.

A time-constrained project is one that must be completed by an imposed date. If required, resources can be added to ensure the project is completed by a specific date. Although time is the critical factor, resource usage should be no more than is necessary and sufficient.

A resource-constrained project is one that assumes the level of resources available cannot be exceeded. If the resources are inadequate, it will be acceptable to delay the project, but as little as possible.

In scheduling terms, time constrained means time (project duration) is fixed and resources are flexible, while resource constrained means resources are fixed and time is flexible. Methods for scheduling these projects are presented in the next section.

8.4 Resource Allocation Methods

Assumptions

Ease of demonstrating the allocation methods available requires some limiting assumptions to keep attention on the heart of the problem. The rest of the chapter depends entirely on the assumptions noted here. First, splitting activities will not be allowed. Splitting refers to interrupting work on one task and assigning the resources to work on a different task for a period of time, then reassigning them to work on the original task. No splitting means that once an activity is placed in the schedule, assume it will be worked on continuously until it is finished. Second, the level of resources used for an activity cannot be changed. These limiting assumptions do not exist in practice but simplify learning. It is easy for new project managers to deal with the reality of splitting activities and changing the level of resources when they meet them on the job.

page 264

Time-Constrained Projects: Smoothing Resource Demand

Scheduling time-constrained projects focuses on resource utilization. When demand for a specific resource type is erratic, it is difficult to manage, and utilization may be very poor. Practitioners have attacked the utilization problem using resource leveling techniques that balance demand for a resource. Basically all leveling techniques delay noncritical activities by using positive slack to reduce peak demand and fill in the valleys for the resources. An example will demonstrate the basic procedure for a time-constrained project. See Figure 8.3.

For the purpose of demonstration, the Botanical Garden project uses only one resource (backhoes); all backhoes are interchangeable. The top bar chart shows the activities on a timescale. The dependencies are shown with the vertical connecting page 265arrows. The horizontal arrows following activities represent activity slack (for example, irrigation requires six days to complete and has six days of slack). The number of backhoes needed for each task is shown in the shaded activity duration block (rectangle). After the land has been scarified and the plan laid out, work can begin on the walkways, irrigation, and fencing and retaining walls simultaneously. The middle chart shows the resource profile for the backhoes. For periods 4 through 10, four backhoes are needed.

Because this project is declared time constrained, the goal will be to reduce the peak requirement for the resource and thereby increase the utilization of the resource. A quick examination of the ES (early start) resource load chart suggests only two activities have slack that can be used to reduce the peak—fence and walls provide the best choice for smoothing the resource needs. Another choice could be irrigation, but it would result in an up-and-down resource profile. The choice will probably center on the activity that is perceived as having the least risk of being late. The smoothed resource loading chart shows the results of delaying the fence and walls activity. Note the differences in the resource profiles. The important point is that the resources needed over the life of the project have been reduced from four to three (25 percent). In addition, the profile has been smoothed, which should be easier to manage.

The Botanical Garden project schedule reached the three goals of smoothing:

The peak of demand for the resource was reduced.
The number of resources over the life of the project was reduced.
The fluctuations in resource demand were minimized.

Smoothing improves the utilization of resources. Backhoes are not easily moved from location to location. There are costs associated with changing the level of resources needed. The same analogy applies to the movement of people back and forth among projects. It is well known that people are more efficient if they can focus their effort on one project rather than multitasking their time among, say, three projects.

The downside of leveling is a loss of flexibility that occurs from reducing slack. The risk of activities delaying the project also increases because slack reduction can create more critical activities and/or near-critical activities. Pushing leveling too far for a perfectly level resource profile is risky. Every activity then becomes critical.

The Botanical Garden example gives a sense of the time-constrained problem and the smoothing approach. However, in practice the magnitude of the problem is very complex for even small projects. Manual solutions are not practical. Fortunately, the software packages available today have very good routines for leveling project resources. Typically they use activities that have the most slack to level project resources. The rationale is that those activities with the most slack pose the least risk. Although this is generally true, other risk factors such as reduction of flexibility to use reassigned resources on other activities and the nature of the activity (easy, complex) are not addressed using such a simple rationale. It is easy to experiment with many alternatives to find the one that best fits your project and minimizes the risk of delaying the project.

Resource-Constrained Projects

When the number of people and/or equipment is not adequate to meet peak demand requirements and it is impossible to obtain more, the project manager faces a resource-constrained problem. Something has to give. The trick is to prioritize and allocate resources to minimize project delay without exceeding the resource limit or altering the technical network relationships.

page 266

The resource scheduling problem is a large, combinatorial one. This means even a modest-sized project network with only a few resource types might have several thousand feasible solutions. A few researchers have demonstrated optimum mathematical solutions to the resource allocation problem but only for small networks and very few resource types (Arrow & Hurowicz, 2006; Talbot & Patterson, 1979; Woodworth & Shanahan, 1988). The massive data requirements for larger problems make pure mathematical solutions (e.g., linear programming) impractical. An alternative approach to the problem has been the use of heuristics (rules of thumb) to solve large, combinatorial problems. These practical decision or priority rules have been in place for many years.

Heuristics do not always yield an optimal schedule, but they are very capable of yielding a “good” schedule for very complex networks with many types of resources. The efficiency of different rules and combinations of rules has been well documented (Davis & Patterson, 1975; Fendly, 1968). However, because each project is unique, it is wise to test several sets of heuristics on a network to determine the priority allocation rules that minimize project delay. The computer software available today makes it very easy for the project manager to create a good resource schedule for the project. A simple example of the heuristic approach is illustrated here.

Heuristics allocate resources to activities to minimize project delay; that is, heuristics prioritize which activities are allocated resources and which activities are delayed when resources are not adequate.

The parallel method is the most widely used approach to apply heuristics, which have been found to consistently minimize project delay over a large variety of projects. The parallel method is an iterative process that starts from the beginning of project time and, when the resources needed exceed the resources available, retains activities first by the priority rules:

Minimum slack.
Smallest duration.
Lowest activity identification number.

Those not able to be scheduled without delaying others are pushed out further in time. However, do not attempt to move activities that have already started. When considering activities not to delay, consider the resources each activity uses. In any period when two or more activities require the same resource, the priority rules are applied. For example, if in period 5 three activities are eligible to start (i.e., have the same ES) and require the same resource, the first activity placed in the schedule would be the activity with the least slack (rule 1). However, if all activities have the same slack, the next rule would be invoked (rule 2), and the activity with the smallest duration would be placed in the schedule first. In very rare cases, when all eligible activities have the same slack and the same duration, the tie is broken by the lowest activity identification number (rule 3), since each activity has a unique ID number.

When a resource limit has been reached, the early start (ES) for succeeding activities not yet in the schedule will be delayed (and all successor activities not having free slack) and their slack reduced. In subsequent periods the procedure is repeated until the project is scheduled. The procedure is demonstrated next; see Figure 8.4. The shaded areas in the resource loading chart represent the “scheduling interval” of the time-constrained schedule (ES through LF). You can schedule the resource anyplace within the interval and not delay the project. Scheduling the activity beyond the LF will delay the project.

page 267

The Parallel Method:

Period	Action
	See Figure 8.4.
0–1	Only activity 1 is eligible. It requires 2 programmers.
	Load activity 1 into schedule.
1–2	No activities are eligible to be scheduled.
2–3	Activities 2, 3, and 4 are eligible to be scheduled. Activity 3 has the least slack (0)— apply rule 1.
	Load activity 3 into schedule.
	Activity 2 is next with slack of 2; however, activity 2 requires 2 programmers and only 1 is available.
	Delay activity 2. Update: ES = 3, slack = 1.
	The next eligible activity is activity 4, since it only requires 1 programmer.
	Load activity 4 into schedule.
	See Figure 8.5.
3–4	Activity 2 is eligible but exceeds limit of 3 programmers in pool.
	Delay activity 2. Update: ES = 4, slack = 0.
4–5	Activity 2 is eligible but exceeds limit of 3 programmers in pool.
	Delay activity 2. Update: ES = 5, LF = 11, slack = −1.
	Delay activity 7. Update: ES = 11, LF = 13, slack = −1.
5–6	Activity 2 is eligible but exceeds limit of 3 programmers in pool.
	Delay activity 2. Update: ES = 6, LF = 12, slack = −2.
	Delay activity 7. Update: ES = 12, LF = 14, slack = −2.
6–7	Activities 2, 5, and 6 are eligible with slack of −2, 2, and 0, respectively.
	Load activity 2 into schedule (rule 1).
	Because activity 6 has 0 slack, it is the next eligible activity.
	Load activity 6 into schedule (rule 1).
	The programmer limit of 3 is reached.
	Delay activity 5. Update: ES = 7, slack = 1.
7–8	Limit is reached. No programmers available.
	Delay activity 5. Update: ES = 8, slack = 0.
8–9	Limit is reached. No programmers available.
	Delay activity 5. Update: ES = 9, LF = 11, slack = −1.
9–10	Limit is reached. No programmers available. Delay activity 5. Update: ES = 10, LF = 12, slack = −2.
10–11	Activity 5 is eligible.
	Load activity 5 into schedule.
	(Note: Activity 6 does not have slack because there are no programmers available—3 maximum.)
11–12	No eligible activities.
12–13	Activity 7 is eligible. Load activity 7 into schedule.

The programmers are limited to three. Follow the actions described in Figures 8.4 and 8.5. Note how the limit of three programmers starts to delay the project.

Observe how it is necessary to update each period to reflect changes in activity early start and slack times so the heuristics can reflect changing priorities. When using the parallel scheduling method, the network in Figure 8.5 reflects the new schedule date of 14 time units, rather than the time-constrained project duration of 12 time units. The network has also been revised to reflect new start, finish, and slack times for each activity. Note that activity 6 is still critical and has a slack of 0 time units because no resources are available (they are being used on activities 2 and 5). Compare the slack page 268for each activity found in Figures 8.4 and 8.5; slack has been reduced significantly. Note that activity 4 has only 2 units of slack rather than what appears to be 6 slack units. This occurs because only three programmers are available, and they are needed to satisfy the resource requirements of activities 2 and 5. Note that the number of critical activities (1, 2, 3, 5, 6, 7) has increased from four to six.

page 269

page 270

This small example demonstrates the scenario of scheduling resources in real projects and the resulting increase in the risk of being late. In practice this is not a trivial problem! Managers who fail to schedule resources usually encounter this scheduling risk when it is too late to work around the problem, resulting in a project delay.

Since manually using the parallel method is impractical on real-world projects because of size, project managers will depend on software programs to schedule project resources.

8.5 Computer Demonstration of Resource-Constrained Scheduling

Fortunately, project management software is capable of assessing and resolving complicated resource-constrained schedules using heuristics similar to those described in the previous section. We will use the EMR project to demonstrate how this is done using MS Project. It is important to note that the software is not “managing” the project. The software is simply a tool the project manager uses to view the project from different perspectives and conditions. See Snapshot from Practice 8.2: Assessing Resource Allocation for more tips on assessing resource problems.

SNAPSHOT FROM PRACTICE 8.2

Assessing Resource Allocation

One of the strengths of project management software is the ability to identify and provide options for resolving resource allocation problems. One project manager who uses MS Project shared the following checklist for dealing with resource conflicts after preliminary assignment of resources.

Assess whether you have overallocation problems (see Red in the resource sheet view).
Identify where and when conflicts occur by examining the resource usage view.
Resolve the problem by
1. Replacing overallocated resources with appropriate resources that are available. Then ask if this solves the problem.
If not:
1. Use the leveling tool and choose the level within slack option.
  1. Does this solve the problem? (Are resources still overallocated?)
  2. Check the sensitivity of the network and ask if this is acceptable.
If not:
1. Consider splitting tasks.
  1. Make sure to readjust task durations to take into account additional start-up and shutdown time.
If 3 does not work, then either
1. Use level tool default option and ask if you can live with the new completion date.
If not:
1. Negotiate for additional resources to complete the project. If not possible:
2. Consider reducing project scope to meet deadline.

While this checklist makes specific references to MS Project, the same steps can be used with most project management software.

page 271

EMR is the name given to a hand-held electronic medical reference guide that is being developed to be used by emergency medical technicians and paramedics. Figure 8.6 contains a time-limited network for the design phase of the project. For the purpose of this example, we assume that only design engineers are required for the tasks and that the design engineers are interchangeable. The number of engineers required to perform each task is noted in the network, where 500 percent means five design engineers are needed for the activity. For example, activity 5, feature specs, requires four design engineers (400 percent).

The project begins January 1 and ends February 14, a duration of 45 workdays. The calendar for the project has been set up to work seven days a week so the reader can trace and more easily see the results and impacts of resources—similar to manual solutions present in chapter exercises. The time-limited (constrained) bar chart for the project is shown in Figure 8.7. This bar chart incorporates the same information used to develop the project network but presents the project in the form of a bar chart along a timeline.

Finally, a resource usage chart is presented for a segment of the project—January 15 to January 23; see Figure 8.8A. Observe that the time-limited project requires 21 design engineers on January 18 and 19 (168 hrs/8 hrs per engineer = 21 engineers). This segment represents the peak requirement for design engineers for the project. However, due to the shortage of design engineers and commitments to other projects, only 8 engineers can be assigned to the project. This creates overallocation problems, more clearly detailed in Figure 8.8B, which is a resource loading chart for design engineers. Notice that the peak is 21 engineers and the limit of 8 engineers is shown by the gray shaded area.

To resolve this problem we use the “leveling” tool within the software and first try to solve the problem by leveling only within slack. This solution would preserve the original finish date. However, as expected, this does not solve all of the allocation problems. The next option is to allow the software to apply scheduling heuristics and level outside of slack. The new schedule is contained in the revised, resource-limited network chart presented in Figure 8.9. The resource-limited project network indicates the project duration has now been extended to 2/26, or 57 workdays (versus 45 days time limited). The critical path is now 2, 3, 9, 13.

Figure 8.10 presents the project bar chart and the results of leveling the project schedule to reflect the availability of only eight design engineers. The application of the heuristics can be seen in the scheduling of the internal, external, and feature specification activities. All three activities were originally scheduled to start immediately after activity 1, architectural decisions.

This is impossible, since the three activities collectively require 14 engineers. The software chooses to schedule activity 5 first because this activity is on the original critical path and has zero slack (heuristic rule # 1). Next, and concurrently, activity 4 is chosen over activity 3 because activity 4 has a shorter duration (heuristic rule # 2); internal specs, activity 3, is delayed due to the limitation of 8 design engineers. Notice that the original critical path no longer applies because of the resource dependencies created by having only eight design engineers. See Figure 8.9 for the original planned critical path.

Compare the bar chart in Figure 8.10 with the time-limited bar chart in Figure 8.7. For example, note the different start dates for activity 8 (screen). In the time-limited plan (Figure 8.7), the start date for activity 8 is 1/18, while the start date in the resource-limited schedule (Figure 8.10) is 2/16, almost a month later!

page 272

page 273

page 274

While resource bar graphs are commonly used to illustrate overallocation problems, we prefer to view resource usage tables like the one presented in Figure 8.8A. This table tells you when you have an overallocation problem and identifies activities that are causing the overallocation.

The Impacts of Resource-Constrained Scheduling

Like leveling schedules, the limited resource schedule usually reduces slack, reduces flexibility by using slack to ensure delay is minimized, and increases the number of critical and near-critical activities. Scheduling complexity is increased because resource constraints are added to technical constraints; start times may now have two constraints. The traditional critical path concept of sequential activities from the start to the end of the project is no longer meaningful. The resource constraints can break the sequence and leave the network with a set of disjointed critical activities.¹ Conversely, parallel activities can become sequential. Activities with slack on a time-constrained network can change from critical to noncritical.

page 275

page 276

page 277

8.6 Splitting Activities

Splitting tasks is a scheduling technique used to get a better project schedule and/or to increase resource utilization. A planner splits the continuous work included in an activity by interrupting the work and sending the resource to another activity for a period of time and then having the resource resume work on the original activity. Splitting can be a useful tool if the work involved does not include large start-up or shutdown costs—for example, moving equipment from one activity location to another. The most common error is to interrupt “people work,” where there are high conceptual start-up and shutdown costs. For example, having a bridge designer take time off to work on the design problem of another project may cause this individual to lose four days shifting conceptual gears in and out of two activities. The cost may be hidden, but it is real. Figure 8.11 depicts the nature of the splitting problem. The original activity has been split into three separate activities: A, B, and C. The shutdown and start-up times lengthen the time for the original activity. One study reported that task switching can cost from 20 percent to 40 percent loss in efficiency (Rubinstein, Meyer, & Evans, 2001).

Some have argued that the propensity to deal with resource shortages by splitting is a major reason projects fail to meet schedule (c.f., Goldratt, 1997; Newbold, 1997). We agree. Planners should avoid the use of splitting as much as possible, except in situations where splitting costs are known to be small or when there is no alternative for resolving the resource problem. Computer software offers the splitting option for each activity; use it sparingly.

page 278

8.7 Benefits of Scheduling Resources

It is important to remember that if resources are truly limited and activity time estimates are accurate, the resource-constrained schedule will materialize as the project is implemented—not the time-constrained schedule! Therefore, failure to schedule limited resources can lead to serious problems for a project manager. The benefit of creating this schedule before the project begins leaves time for considering reasonable alternatives. If the scheduled delay is unacceptable or the risk of being delayed too high, the assumption of being resource constrained can be reassessed. Cost-time trade-offs can be considered. In some cases priorities may be changed. See Snapshot from Practice 8.3: U.S. Forest Service Resource Shortage.

Resource schedules provide the information needed to prepare time-phased work package budgets with dates. Once established, they provide a quick means for a project manager to gauge the impact of unforeseen events such as turnover, equipment breakdowns, or transfer of project personnel. Resource schedules also allow project managers to assess how much flexibility they have over certain resources. This is useful when they receive requests from other managers to borrow or share resources. Honoring such requests creates goodwill and an “IOU” that can be cashed in during a time of need.

SNAPSHOT FROM PRACTICE 8.3

U.S. Forest Service Resource Shortage

A major segment of work in managing U.S. Forest Service (USFS) forests is selling mature timber to logging companies that harvest the timber under contract conditions monitored by the service. The proceeds are returned to the federal government. The budget allocated to each forest depends on the two-year plan submitted to the U.S. Department of Agriculture.

Olympic Forest headquarters in Olympia, Washington, was developing a two-year plan as a basis for funding. All of the districts in the forest submitted their timber sale projects (numbering more than 50) to headquarters, where they were compiled and aggregated into a project plan for the whole forest. The first computer run was reviewed by a small group of senior managers to determine if the plan was reasonable and “doable.” Management was pleased and relieved to note all projects appeared to be doable in the two-year time frame until a question was raised concerning the computer printout. “Why are all the columns in these projects labeled ‘RESOURCE’ blank?” The response from an engineer was “We don’t use that part of the program.”

The discussion that ensued recognized the importance of resources in completing the two-year plan and ended with a request to “try the program with resources included.” The new output was startling. The two-year program turned into a three-and-a-half-year plan because of the shortage of specific labor skills such as road engineer and environmental impact specialist. Analysis showed that adding only three skilled people would allow the two-year plan to be completed on time. In addition, further analysis showed hiring only a few more skilled people, beyond the three, would allow an extra year of projects to also be compressed into the two-year plan. This would result in additional revenue of more than $3 million. The Department of Agriculture quickly approved the requested extra dollars for additional staff to generate the extra revenue.

Darinburt/Getty Images

page 279

8.8 Assigning Project Work

When making individual assignments, project managers should match, as best they can, the demands and requirements of specific work with the qualifications and experience of available participants. In doing so, there is a natural tendency to assign the best people the most difficult tasks. Project managers need to be careful not to overdo this. Over time these people may grow to resent the fact that they are always given the toughest assignments. At the same time, less experienced participants may resent the fact that they are never given the opportunity to expand their skill/knowledge base. Project managers need to balance task performance with the need to develop the talents of people assigned to the project.

Project managers need to decide not only who does what but also who works with whom. A number of factors need to be considered in deciding who should work together. First, to minimize unnecessary tension, managers should pick people with compatible work habits and personalities but who complement each other (i.e., one person’s weakness is the other person’s strength). For example, one person may be brilliant at solving complex problems but sloppy at documenting his progress. It would be wise to pair this person with an individual who is good at paying attention to details. Experience is another factor. Veterans should be teamed up with new hires—not only so they can share their experience but also to help socialize the newcomers to the customs and norms of the organization. Finally, future needs should be considered. If managers have some people who have never worked together before but who have to later on in the project, they may be wise to take advantage of opportunities to have these people work together early on so that they can become familiar with each other. Finally, see Snapshot from Practice 8.4: Managing Geeks for some interesting thoughts from the former CEO of Google on how to put together teams.

SNAPSHOT FROM PRACTICE 8.4

Managing Geeks^*

Eric Schmidt, after a successful career at Sun Microsystems, took over struggling Novell, Inc., and helped turn it around within two years. Four years later he became the CEO of Google. One of the keys to his success is his ability to manage the technical wizards who develop the sophisticated systems, hardware, and software that are the backbone of electronically driven companies. He uses the term “geek” (and he can, since he is one, with a Ph.D. in computer science) to describe this group of technologists who rule the cyberworld.

Schmidt has some interesting ideas about assigning geeks to projects. He believes that putting geeks together in project teams with other geeks creates productive peer pressure. Geeks care a great deal about how other geeks perceive them. They are good at judging the quality of technical work and are quick to praise as well as criticize each other’s work. Some geeks can be unbearably arrogant, but Schmidt claims that having them work together on projects is the best way to control them—by letting them control each other.

At the same time, Schmidt argues that too many geeks spoil the soup. By this he means that when there are too many geeks on a development team, there is a tendency for intense technical navel gazing. Members lose sight of deadlines, and delays are inevitable. To combat this tendency, he recommends using geeks only in small groups. He urges breaking up large projects into smaller, more manageable projects so that small teams of geeks can be assigned to them. This keeps the project on time and makes the teams responsible to each other.

^*Russ Mitchel, “How to Manage Geeks,” Fast Company, May 31, 1999, pp. 175–80.

page 280

8.9 Multiproject Resource Schedules

For clarity we have discussed key resource allocation issues within the context of a single project. In reality resource allocation generally occurs in a multiproject environment where the demands of one project have to be reconciled with the needs of other projects. Organizations must develop and manage systems for efficiently allocating and scheduling resources across several projects with different priorities, resource requirements, sets of activities, and risks. The system must be dynamic and capable of accommodating new projects as well as reallocating resources once project work is completed. While the same resource issues and principles that apply to a single project also apply to this multiproject environment, application and solutions are more complex, given the interdependency among projects.

The following are three of the more common problems encountered in managing multiproject resource schedules. Note that these are macro manifestations of single-project problems that are now magnified in a multiproject environment.

Overall schedule slippage. Because projects often share resources, delays in one project can have a ripple effect and delay other projects. For example, work on one software development project can grind to a halt because the coders scheduled for the next critical task are late in completing their work on another development project.
Inefficient resource utilization. Because projects have different schedules and requirements, there are peaks and valleys in overall resource demands. For example, a firm may have a staff of 10 electricians to meet peak demands when, under normal conditions, only 5 electricians are required.
Resource bottlenecks. Delays and schedules are extended as a result of shortages of critical resources that are required by multiple projects. For example, at one Lattice Semiconductor facility, project schedules were delayed because of competition over access to test the equipment necessary to debug programs. Likewise, several projects at a U.S. forest area were extended because there was only one silviculturist on the staff.

To deal with these problems, more and more companies are creating project offices or departments to oversee the scheduling of resources across multiple projects. One approach to multiple project resource scheduling is to use a first come–first served rule. A project queue system is created in which projects currently under way take precedence over new projects. New project schedules are based on the projected availability of resources. This queuing tends to lead to more reliable completion estimates and is preferred on contracted projects that have stiff penalties for being late. The disadvantages of this deceptively simple approach are that it does not optimally utilize resources or take into account the priority of the project. See Snapshot from Practice 8.5: Multiple Project Resource Scheduling.

Many companies utilize more elaborate processes for scheduling resources to increase the capacity of the organization to initiate projects. Most of these methods approach the problem by treating individual projects as part of one big project and adapting the scheduling heuristics previously introduced to this “mega project.” Project schedulers monitor resource usage and provide updated schedules based on progress and resource availability across all projects. One major improvement in project management software in recent years is the ability to prioritize resource allocation to specific projects. Projects can be prioritized in ascending order (e.g., 1, 2, 3, 4, . . .), and these priorities will override scheduling heuristics so that resources go to the project highest on the priority list. (Note: This improvement fits perfectly with organizations that use project priority models similar to those described in Chapter 2.) Centralized project scheduling also makes it easier to identify resource bottlenecks that stifle progress on projects. Once bottlenecks have been identified, their impact page 281can be documented and used to justify acquiring additional equipment, recruiting critical personnel, or delaying the project.

SNAPSHOT FROM PRACTICE 8.5

Multiple Project Resource Scheduling

The case for a central source to oversee project resource scheduling is well known by practitioners. Here is a synopsis of a conversation with one middle manager.

Interviewer: Congratulations on acceptance of your multiproject scheduling proposal. Everyone tells me you were very convincing.

Middle Manager: Thanks. Gaining acceptance was easy this time. The board quickly recognized we have no choice if we are to keep ahead of competition by placing our resources on the right projects.

Interviewer: Have you presented this to the board before?

Middle Manager: Yes, but not this company. I presented the same spiel to the firm I worked for two years ago. For their annual review meeting I was charged to present a proposal suggesting the need and benefits of central capacity resource planning for managing the projects of the firm.

I tried to build a case for bringing projects under one umbrella to standardize practices and to forecast and assign key people to mission critical projects. I explained how benefits such as resource demands would be aligned with mission critical projects, proactive resource planning, and a tool for catching resource bottlenecks and resolving conflicts.

Almost everyone agreed the idea was a good one. I felt good about the presentation and felt confident something was going to happen. But the idea never really got off the ground; it just faded into the sunset.

With hindsight, managers really did not trust colleagues in other departments, so they only gave half-hearted support to central resource planning. Managers wanted to protect their turf and ensure that they would not have to give up power. The culture there was simply too inflexible for the world we live in today. They are still struggling with constant conflicts among projects.

I’m glad I made the switch to this firm. The culture here is much more team-oriented. Management is committed to improving performance.

Finally, many companies are using outsourcing as a means of dealing with their resource allocation problems. In some cases, a company will reduce the number of projects they have to manage internally to only core projects and outsource noncritical projects to contractors and consulting firms. In other cases, specific segments of projects are outsourced to overcome resource deficiencies and scheduling problems. Companies may hire temporary workers to expedite certain activities that are falling behind schedule or contract project work during peak periods when there are insufficient internal resources to meet the demands of all projects. The ability to more efficiently manage the ebbs and flows of project work is one of the major driving forces behind outsourcing today.

8.10 Using the Resource Schedule to Develop a Project Cost Baseline

Once resource assignments have been finalized, you are able to develop a baseline budget schedule for the project. Using your project schedule, you can time-phase work packages and assign them to their respective scheduled activities to develop a budget schedule over the life of your project. Understanding the reason for time-phasing your budget is very important. Without a time-phased budget, a good project schedule and cost control are impossible.

Why a Time-Phased Budget Baseline Is Needed

The need for a time-phased budget baseline is demonstrated in the following scenario. The development of a new product is to be completed in 10 weeks at an estimated cost page 282of $400,000 per week, for a total cost of $4 million. Management wants a status report at the end of 5 weeks. The following information has been collected:

Planned costs for the first 5 weeks are $2,000,000.
Actual costs for the first 5 weeks are $2,400,000.

How are we doing? It would be easy to draw the conclusion there is a $400,000 cost overrun. But we really have no way of knowing. The $400,000 may represent money spent to move the project ahead of schedule. Assume another set of data at the end of 5 weeks:

Planned costs for the first 5 weeks are $2,000,000.
Actual costs for the first 5 weeks are $1,700,000.

Is the project costing $300,000 less than we expected? Perhaps. But the $300,000 may represent the fact that the project is behind schedule and work has not started. Could it be the project is behind schedule and over cost? We cannot tell from these data. The many systems found in the real world that use only planned funds (a constant burn rate) and actual costs can provide false and misleading information. There is no way to be certain how much of the physical work has been accomplished. These systems do not measure how much work was accomplished for the money spent! Hence, without time-phasing cost to match your project schedule, it is impossible to have reliable information for control purposes.

Creating a Time-Phased Budget

By using information from your WBS and resource schedule, you can create a time-phased cost baseline. Remember from the WBS for the PC Project in Chapters 4 and 5 that we integrated the WBS and OBS organization breakdown structure so the work packages could be tracked by deliverable and organization responsible. See Figure 8.12 for an example of the PC Prototype Project arranged by deliverable and organization unit responsible. For each intersection point of the WBS/OBS matrix, you see work package budgets and the total cost. The total cost at each intersection is called a cost or control account. For example, at the intersection of the Read/write head deliverable and the Production Department we see there are three work packages with a total budget of $200,000. The sum of all cost accounts in a column should represent the total costs for the deliverable. Conversely the sum of the cost accounts in a row should represent the costs or budget for the organization unit responsible for accomplishing the work. You can continue to “roll up” costs on the WBS/OBS to total project costs. This WBS provides the information you can use to time-phase work packages and assign them to their respective scheduled activities over the life of the project.

Recall, from the development of your work breakdown structure for each work package, the following information needed to be developed:

Define work (what).
Identify time to complete a work package (how long).
Identify a time-phased budget to complete a work package (cost).
Identify resources needed to complete a work package (how much).
Identify a single person responsible for units of work (who).
Identify monitoring points for measuring progress (how well).

Number three, time-phasing the work package, is critical for the final step of creating your budget baseline. The process of time-phasing work packages, which is illustrated next, is demonstrated in Figure 8.13. The work package has a duration of three weeks. page 283Assuming labor, materials, and equipment are tracked separately, the work package costs for labor are distributed over the three weeks as they are expected to occur—$40,000, $30,000, and $50,000 for each week, respectively. When the three-week work package is placed in the network schedule, the costs are distributed to the time-phased budget for the same three scheduled weeks. Fortunately, most single WPs become an activity and the process of distributing costs is relatively simple. That is, the relationship is one-for-one. Such budget timing is directly from the work package to the activity.

page 284

In a few instances an activity will include more than one work package, where the packages are assigned to one responsible person or department and deliverable. In this case the work packages are consolidated into one activity. As seen in Figure 8.14, this activity includes two WPs. The first, WP-1.1.3.2.4.1 (Code), is distributed over the first three weeks. The second, WP-1.1.3.2.4.2 (Integration), is sequenced over weeks 3 and 4. The activity duration is four weeks. When the activity is placed in the schedule, the costs are distributed starting with the schedule start—$20,000, $15,000, $75,000, and $70,000, respectively.

These time-phased budgets for work packages are lifted from your WBS and are placed in your project schedule as they are expected to occur over the life of the project. The outcome of these budget allocations is the project cost baseline (also called planned value—PV), which is used to determine cost and schedule variances as the project is implemented.

Figure 8.15 shows the Patient Entry project network schedule, which is used to place the time-phased work packages’ budgets in the baseline. Figure 8.16 presents the project time-phased budget for the Patient Entry project and the cumulative graph of the project budget baseline. In this figure you can see how the time-phased work package costs were placed into the network and how the cumulative project budget graph for a project is developed. Notice that costs do not have to be distributed linearly, but the costs should be placed as you expect them to occur.

page 285

You have now developed complete time and cost plans for your project. These project baselines will be used to compare planned schedule and costs using an integrative system called earned value. The application and use of project baselines to measure performance are discussed in detail in Chapter 13. With your project budget baseline established, you are also able to generate cash flow statements for your project, like the one presented in Figure 8.17. Such statements prepare the firm to cover costs over the lifespan of the project. Finally, with resource assignments finalized, you are able to generate resource usage schedules for your project (see Figure 8.18). These schedules map out the full deployment of personnel and equipment and can be used to generate individual work schedules.

page 286

page 287

Summary

A project schedule is not a schedule until resources have been assigned. If resources are inadequate then task sequences are likely to be impacted and the schedule extended. If resources are adequate it may be advantageous to “smooth” resources to improve their utilization. The results after resource scheduling are frequently significantly different from the results of the standard CPM method.

With the rapid changes in technology and emphasis on time-to-market, catching resource usage and availability problems before the project starts can save the costs of crashing project activities later. Any resource deviations from plan and schedule that occur when the project is being implemented can be quickly recorded and the effect noted. Without this immediate update capability, the real negative effect of a change may not be known until it happens. Tying resource availability to a multiproject, multi-resource system supports a project priority process that selects projects by their contribution to the organization’s objectives and strategic plan.

Assignment of individuals to projects may not fit well with those assigned by computer software routines. In these cases overriding the computer solution to accommodate individual differences and skills is almost always the best choice.

The project resource schedule is important because it serves as your time baseline, which is used for measuring time differences between plan and actual. The resource schedule serves as the basis for developing your time-phased project cost budget baseline. The baseline (planned value, PV) is the sum of the cost accounts, and each cost account is the sum of the work packages in the cost account. Remember, if your budgeted costs are not time-phased, you have no reliable way to measure performance. Although there are several types of project costs, the cost baseline is usually limited to direct costs (such as labor, materials, equipment) that are under the control of the project manager; other, indirect costs can be added to project costs separately.

Key Terms

Heuristics, 266
Leveling, 264
Planned value (PV), 284
Resource-constrained project, 263
Resource-constrained scheduling, 260
Resource smoothing, 260
Splitting, 263
Time-constrained project, 263
Time-phased budget baseline, 281

Review Questions

How does resource scheduling tie to project priority?
How does resource scheduling reduce flexibility in managing projects?
Present six reasons scheduling resources is an important task.
How can outsourcing project work alleviate the three most common problems associated with multiproject resource scheduling?
Explain the risks associated with leveling resources, compressing or crashing projects, and imposed durations or “catch-up” as the project is being implemented.
Why is it critical to develop a time-phased baseline?

page 288

SNAPSHOT Images FROM PRACTICE

DISCUSSION QUESTIONS

8.1 Working in Tight Places

Can you think of other examples where the physical environment constrains project work?

8.3 U.S. Forest Service Resource Shortage

What do you think would have happened if the Washington Forest Service did not assess the impact of resources on their two-year plan?

8.4 Managing Geeks

Do you agree that geeks are different from other workers?

8.5 Multiple Project Resource Scheduling

Why would people resist a multiproject resource scheduling system?

Exercises

Consider a project with the accompanying Gantt chart. Stella is your only electrical engineer and she is responsible for activities 3 and 4, which overlap. Level the project so that Stella is only working a maximum of 8 hours each day. What would the new Gantt chart look like? What would be the new project completion date?

Consider a project with the following Gantt chart to answer exercises 2 and 3.
Bjorn and Thor are plumbers who have been scheduled to work on the construction of a new school building. Just before the start of the project, Bjorn broke his arm and cannot work on the project. Now Thor has to handle his own activities as well as Bjorn’s. Level the project Gantt chart so that Thor is responsible for activities 3, 4, 6, and 7. What is the new estimated completion date for the project?
Suppose instead of assigning Bjorn’s work to Thor, you have the opportunity to hire two new plumbers to perform Bjorn tasks (shortening them by 50 percent). page 289What would the new project estimated completion date be? Show your work.
Given the network plan that follows, compute the early, late, and slack times. What is the project duration? Using any approach you wish (e.g., trial and error), develop a loading chart for resource, electrical engineers (EE), and resource, mechanical engineers (ME). Assume only one of each resource exists. Given your resource schedule, compute the early, late, and slack times for your project. Which activities are now critical? What is the project duration now? Could something like this happen in real projects?
Given the network plan that follows, compute the early, late, and slack times. What is the project duration? Using any approach you wish (e.g., trial and error), develop a loading chart for resources carpenters (C) and electricians (E). Assume only one carpenter is available and two electricians are available. Given your page 290resource schedule, compute the early, late, and slack times for your project. Which activities are now critical? What is the project duration now?
Compute the early, late, and slack times for the activities in the network that follows, assuming a time-constrained network. Which activities are critical? What is the time-constrained project duration?

Note: Recall that in the schedule resource load chart the time-constrained scheduling interval (ES through LF) has been shaded. Any resource scheduled beyond the shaded area will delay the project.

Assume you have only three resources and you are using software that schedules projects by the parallel method and following heuristics. Schedule only one period at a time!

Minimum slack

Smallest duration

Lowest identification number

Keep a log of each activity change and update you make each period—e.g., period 0–1, 1–2, 2–3, etc. (Use a format similar to the one on page 267.) The log should page 291include any changes or updates in ES, LF, and slack times each period, activities scheduled, and activities delayed. (Hint: Remember to maintain the technical dependencies of the network.) Use the resource load chart to assist you in scheduling (see Figures 8.4 and 8.5).

List the order in which you scheduled the activities of the project. Which activities of your schedule are now critical?

Recompute your slack for each activity, given your new schedule. What is the slack for activity 1? 4? 5?
You have prepared the following schedule for a project in which the key resource is a tractor(s).^* There are three tractors available to the project. Activities A and D require one tractor to complete, while activities B, C, E, and F require two tractors.

page 292

Develop a resource-constrained schedule in the loading chart that follows. Use the parallel method and heuristics given. Be sure to update each period as the computer would do. Record the early start (ES), late finish (LF), and slack (SL) for the new schedule.
page 293Develop a resource schedule in the loading chart that follows. Use the parallel method and heuristics given. Be sure to update each period as the computer would do. Note: Activities 2, 3, 5, and 6 use two of the resource skills. Three of the resource skills are available. How has slack changed for each activity? Has the risk of being late changed? How?
You have prepared the following schedule for a project in which the key resource is a backhoe(s). This schedule is contingent on having three backhoes. You receive a call from your partner, Brooker, who desperately needs one of your backhoes. page 294You tell Brooker you are willing to let him have the backhoe if you are still able to complete your project in 11 months.

Develop a resource schedule in the loading chart that follows to see if it is possible to complete the project in 11 months with only two backhoes. Be sure to record the order in which you schedule the activities using scheduling heuristics. Activities 5 and 6 require two backhoes, while activities 1, 2, 3, and 4 require one backhoe. No splitting of activities is possible. Can you say yes to Brooker’s request?
You are one of three carpenters assigned to complete a short construction project.^* Right before the start of the project, one of your fellow carpenters is hospitalized and will not be available to work on the project.

Develop a resource-constrained schedule in the loading chart that follows to see how long the project will take with only two carpenters. Be sure to record the page 295order in which you schedule the activities using the scheduling heuristics. Activities A, B, C, D, E, G, and H require two carpenters to complete. Activity F requires only one carpenter. No splitting of activities is possible.

You will receive a bonus if the project is completed within 15 days. Should you start planning how you will spend your bonus?
Given the time-phased work packages, complete the baseline budget form for the project.

page 296
Given the time-phased work packages and network, complete the baseline budget form for the project.
page 297Given the time-phased work packages and network, complete the baseline budget form for the project.^*
page 298Given the time-phased work packages and network, complete the baseline budget form for the project.
page 299The National Oceanic Research Institute is planning a research study on global warming in Antarctica. The 16-month network schedule is presented below. It is followed by budgets for each activity. Create a time-phased budget for the research project in the form provided.

^*The solution to this exercise can be found in Appendix 1.

page 300

References

Arrow, K. J., and L. Hurowicz, Studies in Resource Allocation Process (New York: Cambridge University Press, 2006).

Brucker, P., A. Drexl, R. Mohring, L. Newmann, and E. Pesch, “Resource-Constrained Project Scheduling: Notation, Classification, Models and Methods,” European Journal of Operational Research, vol. 112 (1999), pp. 3–42.

Burgess, A. R., and J. B. Kellebrew, “Variations in Activity Level on Cyclical Arrow Diagrams,” Journal of Industrial Engineering, vol. 13 (March/April 1962), pp. 76–83.

Charnes, A., and W. W. Cooper, “A Network Interpretation and Direct Sub Dual Algorithm for Critical Path Scheduling,” Journal of Industrial Engineering (July/August 1962).

Davis, E. W., and J. Patterson, “A Comparison of Heuristic and Optimum Solutions in Resource-Constrained Project Scheduling,” Management Science, April 1975, pp. 944–55.

Demeulemeester, E. L., and W. S. Herroelen, Project Scheduling: A Research Handbook (Norwell, MA: Kluwer Academic Publishers, 2002).

Fendly, L. G., “Towards the Development of a Complete Multi Project Scheduling System,” Journal of Industrial Engineering, vol. 19 (1968), pp. 505–15.

Goldratt, E., Critical Chain (Great Barrington, MA: North River Press, 1997).

Kurtulus, I., and E. W. Davis, “Multi-project Scheduling: Categorization of Heuristic Rules Performance,” Management Science (February 1982), pp. 161–72.

Reinersten, D., “Is It Always a Bad Idea to Add Resources to a Late Project?” Electric Design, October 30, 2000, pp. 17–18.

Rubinstein, J., D. Meyer, and J. Evans, “Executive Control of Cognitive Processes in Task Switching,” Journal of Experimental Psychology: Human Perception and Performance, vol. 27, no. 4 (2001), pp. 763–97.

Talbot, B. F., and J. H. Patterson, “Optimal Methods for Scheduling under Resource Constraints,” Project Management Journal (December 1979).

Wiest, J. D., “A Heuristic Model for Scheduling Large Projects with Unlimited Resources,” Management Science, vol. 18 (February 1967), pp. 359–77.

Woodworth, B. M., and C. J. Willie, “A Heuristic Algorithm for Resource Leveling in Multiproject, Multiresource Scheduling,” Decision Sciences, vol. 6 (July 1975), pp. 525–40.

Woodworth, B. M., and S. Shanahan, “Identifying the Critical Sequence in a Resource Constrained Project,” International Journal of Project Management, vol. 6 (1988), pp. 89–96.

page 301

Case 8.1

Blue Mountain Cabin

Jack and Jill Smith have just retired and want to build a small, basic cabin in the Blue Mountains of Vermont. They have hired Daryl Hannah as the general contractor for the project. She has assembled a team of three workers to complete the project: Tom, Dick, and Harry. Daryl has negotiated a cost-plus contract with the Smiths whereby she will receive 15 percent beyond the cost of labor and materials.

Before they sign the contract the Smiths want an estimate of how much the project is likely to cost and how long it will take.

Daryl has estimated that the cost for materials, permits, etc., will total $40,000. She wants to determine labor costs as well as how long the project will take. This is one of several projects Daryl is managing, and other than occasionally helping out, her role is strictly limited to supervising. She has devised the following master plan and assignments.

Note that Dick is the only skilled plumber in the group, while Harry is the only skilled electrician. Tom is a general carpenter and can assist them with their work. Dick and Harry each get paid $300 a day, while Tom gets paid $200 per day.

Daryl has negotiated a 10 percent management reserve to deal with unexpected problems. Unused funds will be returned to the Smiths.

Prepare a short proposal for the Smiths that includes a Gantt chart with resources assigned and cost estimates if the project starts on 8/1/16. Did resource limitations affect the final schedule? If so, how? What financial risks does this project face? What can the Smiths do to protect themselves against those risks?

Case 8.2

Power Train, Ltd.

Memo: Power Train Management Team

We have great information systems for reporting, tracking, and controlling costs on design projects. Our planning of projects is better than any I have seen at other companies. Our scheduling seemed to serve us well when we were small and we had only a few projects. Now that we have many more projects and schedule using multiproject software, there are too many occasions when the right people are not assigned to the projects deemed important to our success. This situation is costing us big money, headaches, and stress!

Claude Jones, VP, Design and Operations

page 302

HISTORY

Power Train (PT), Ltd., was founded in 1970 by Daniel Gage, a skilled mechanical engineer and machinist. Prior to founding PT he worked for three years as design engineer for a company that designed and built transmissions for military tanks and trucks. It was a natural transition for Dan to start a company designing and building power trains for farm tractor companies. Today Dan is no longer active in the management of PT but is still revered as its founder. He and his family still own 25 percent of the company, which went public in 1998. PT has been growing at a 6 percent clip for the last five years but expects industry growth to level off as supply exceeds demand.

Today PT continues its proud tradition of designing and building the best-quality power trains for manufacturers of farm tractors and equipment. The company employs 178 design engineers and has about 1,800 production and support staff. Contract design projects for tractor manufacturers represent a major portion of PT’s revenue. At any given time, about 45 to 60 design projects are going on concurrently. A small portion of their design work is for military vehicles. PT only accepts military contracts that involve very advanced, new technology and are cost plus.

A new phenomenon has attracted the management of PT to look into a larger market. Last year a large Swedish truck manufacturer approached PT to consider designing power trains for its trucks. As the industry consolidates, the opportunities for PT should increase because these large firms are moving to more outsourcing to cut infrastructure costs and stay very flexible. Only last week a PT design engineer spoke to a German truck manufacturing manager at a conference. The German manager was already exploring outsourcing of drive trains to Porsche and was very pleased to be reminded of PT’s expertise in the area. A meeting is set up for next month.

CLAUDE JONES

Claude Jones joined PT in 1999 as a new MBA from the University of Edinburgh. He worked as a mechanical engineer for U.K. Hydraulics for five years prior to returning to school for the MBA. “I just wanted to be part of the management team and where the action is.” Claude moved quickly through the ranks. Today he is the vice president of design and operations. Sitting at his desk, Claude is pondering the conflicts and confusion that seem to be increasing in scheduling people to projects. He gets a real rush at the thought of designing power trains for large trucks; however, given their current project scheduling problems, a large increase in business would only compound their problems. Somehow these conflicts in scheduling have to be resolved before any serious thought can be given to expanding into the design of power transmissions for truck manufacturers.

Claude is thinking of the problems PT had in the last year. The MF project is the first to come to mind. The project was not terribly complex and did not require their best design engineers. Unfortunately, the scheduling software assigned one of the most creative and expensive engineers to the MF project. A similar situation, but reversed, happened on the Deer project. This project involved a big customer and new hydrostatic technology for small tractors. In this project the scheduling software assigned engineers who were not familiar with small tractor transmissions. Somehow, thinks Claude, the right people need to be scheduled to the right projects. Upon reflection, this problem with scheduling has been increasing since PT went to multiproject scheduling. Maybe a project office is needed to keep on top of these problems.

A meeting with the information technology team and software vendors was positive but not very helpful because these people are not really into detailed scheduling page 303problems. The vendors provided all sorts of evidence suggesting the heuristics used—least slack, shortest duration, and identification number—are absolutely efficient in scheduling people and minimizing project delays. One project software vendor, Lauren, kept saying their software would allow PT to customize the scheduling of projects and people to almost any variation selected. Lauren repeated over and over, “If the standard heuristics do not meet your requirements, create your own heuristics that do.” Lauren even volunteered to assist in setting up the system. But she is not willing to spend time on the problem until PT can describe to her exactly what criteria will be used (and their sequence) to select and schedule people to projects.

WHAT NEXT?

Potential expansion into the truck power train business is not feasible until the confusion in project scheduling is solved or reduced significantly. Claude is ready to tackle this problem, but he is not sure where to start. What criteria should he consider? What should be the sequence for selecting and assigning people to projects?

Case 8.3

Tham Luang Cave Rescue

On June 23, 2018, in Thailand, a group of 12 boys aged between 11 and 17 from the local football team, named the Wild Boars, and their 23-year-old assistant coach entered the Tham Luang cave. Tham Luang is a large cave complex in northern Thailand along the border with Myanmar. The cavern was popular with locals and the boys had visited Tham Luang before. Tham Luang cave is isolated—there is no GPS, Wi-Fi, or cell phone service. The last known survey was conducted in the 1980s by a French caving society, but many of the deeper recesses remain unmapped.

The boys had little difficulty getting fairly far into the cave, crawling through a couple of choke points to open spaces. They did not anticipate any problems getting back. The monsoon rains weren’t expected until the next week, and the year before, the cave did not begin to flood until the middle of July. The team took no food with them, because this was going to be a brief field trip. They planned to stay for perhaps an hour, then return home to their parents.

However, nature had different plans. Heavy monsoon rain began to fall. The Wild Boars didn’t know about the rain at first. There was a thousand feet of rock above them and they were more than a mile from the open forest. Heavy rains gathered in streams that disappeared into sinks, rushing through limestone into the cavern. Water rose suddenly and quickly, forcing the team to retreat farther and farther into the cave. The interior of the cave is not level but rather rises and falls as it burrows into the mountain. The team scrambled for higher ground as the water continued to rise. Finally, they settled on a mud slope and waited to see if the water would continue to rise. It didn’t.

A mother of one of the boys contacted the police when her child failed to come home. A teammate who had missed practice that day told people that the team had planned to visit the cave after practice. Parents rushed to the cave, only to find their children’s bikes and cleats at the entrance and the cave flooded.

A contingent of Thai Navy SEAL divers arrived the next day and began pushing their way into the flooded cave. This was no easy task. The Thai frogmen were accustomed to tropical open water, not the dark, cold currents racing through the cave. page 304They lacked equipment, much less expertise needed for caves, where divers cannot just rise to the surface if something goes wrong.

The plight of the Wild Boars drew international attention overnight. Soon skilled cave divers from around the world, including Finland, Britain, China, Australia, and the United States, volunteered their services. At first the foreign divers were not met with open arms by the Thai military in charge of the rescue. Many of the SEAL divers bristled at the idea of needing foreign assistance. The divers were not even allowed into the cave. After much political haggling, the Thai Ministry of Foreign Affairs told the military chiefs to let the foreign divers go.

Even the experienced cave divers found the conditions extremely difficult. “It was like walking into a strong waterfall and feeling the water rushing at you,” one diver said. “It was a horizontal climb against water with every move.”

The divers painstakingly penetrated the cave, securing guidelines needed to ensure safety. Visibility at times was negligible. “If you put your hand in front of you, it just disappeared,” said one diver. “You couldn’t see anything.”

Meanwhile, on the surface, policemen with sniffer dogs searched for shaft openings that could provide an alternative entrance to the cave system. The search was augmented by hundreds of volunteers dressed in lemon-yellow shirts and sky-blue caps, searching for hidden cracks in the limestone that might reveal an opening to the cave. Drones were also used, but no technology existed to scan for humans deep underground. Local holy men created a shrine at the mouth of the cave, where they chanted and communed with the spirit of the cave, “Jao Mae Tham.” Several times the search had to be suspended due to heavy rains.

After the team had spent 10 days of captivity without real food or water, there was little hope among the rescuers of discovering the boys alive.

In the cave, a pair of British divers working to extend the guide ropes popped up near a narrow ledge. First they smelled, and then they saw, 13 emaciated people perched in the dark. The Wild Boars had run out of food and light but had survived by sipping the condensation from the cave walls. Later it was reported that the assistant coach, a Buddhist, had led the boys in meditation to relax and conserve energy. The ledge where they were found was about 2.5 miles from the cave mouth.

The next day Thai SEALs ferried food, water, and blankets to the Wild Boars. Four divers, including a doctor, would stay with them until their rescue. Thai officials reported that the rescuers were providing health checks, keeping the boys entertained, and none of the boys were in serious condition.

Thai officials released a video made by the rescuers and shared to the world. The video showed all 12 boys and their coach introducing themselves and stating their ages. Wrapped in emergency blankets and appearing frail, each boy said hello to the outside world, “Sawasdee khrap,” with his palms together in wai, the traditional Thai greeting. The video went viral. Soon all the major newscasts across the world were covering the story. The big question then became, now that the boys had been found, how could they be gotten out alive?

A rescue camp was set up at the cave entrance, accommodating the volunteers and journalists in addition to the rescue workers. The camp was divided into zones: restricted areas for the Thai Navy SEALs, other military personnel, and civilian rescuers; an area for relatives to wait in privacy; and areas for the press and general public.

An estimated 10,000 people contributed to the rescue effort, including more than 100 divers, 900 police officers, 2,000 soldiers, and numerous volunteers. Equipment included 10 police helicopters, seven ambulances, and more than 700 diving cylinders, of which more than 500 were in the cave at any time while another 200 were in queue to be refilled.

page 305

The plight of the Wild Boars caught the attention of Elon Musk of Tesla and Space X fame. He tasked engineers to build a kid-size submarine that could be used to transport the boys out of the cave. Within days an actual submarine was sent to Tham Luang. Thai officials praised the effort but concluded it was not practical, given the narrow passages in the cavern.

The journey through the cave to the team took six hours against current and five hours to exit with the current. The route had several flooded sections, some with strong currents and zero visibility, and some extremely narrow parts, the smallest measuring only 15 by 28 inches. The boys were perched on a ledge 400 yards from Pattaya beach chamber, named after an above-ground beach in Thailand. Chamber 3, which was dry, would be used as rescue base.

Pumps were brought in to remove water from the cave. Although not a solution, efforts at draining the cave began to produce results. Crags and outcroppings emerged from the murk. The most challenging passage, which had taken five hours to navigate early on, could now be traversed in two hours with the help of guide ropes.

As the crisis unfolded, rescuers considered several different methods to save the team. The principal options included

Wait until the end of the monsoon season, with divers providing food and water.
Find an alternative entrance to the cave that would allow for an easier escape.
Drill a rescue shaft.
Teach the group basic diving skills and have them swim out with the divers.

Waiting until the monsoons ended in November and the water drained was the simplest solution. The boys could walk out on their own. However, the logistics did not make sense. Feeding 13 people, three times a day, for even 60 days is more than 2,750 meals. Every meal would have to be ferried in by a team of divers, flirting with death each time they went under.

This was a growing concern. Four days after the boys were found, retired Navy SEAL diver Saman Kunan lost consciousness while returning from dropping off three air tanks. His dive buddy attempted CPR without success. Kunan had left his airport security job to volunteer for the rescue mission. Before that fatality, three divers were lost for over three hours in the dark cave, and rescue efforts had to be redirected to find them.

From the beginning hundreds of volunteers crawled over the hillside in search of hidden openings. People knew the odds were slim to none, given the depth of the cave, but it was worth a try.

Drilling through a couple thousand feet of rock would require extensive infrastructure work and take too long. Besides, there was significant uncertainty as to where to drill.

That left the fourth option. None of the boys or the coach knew how to dive. Even if they could master the basics, cave diving is not the same as a practice run at a resort swimming pool. A weakened child submerged in darkness and breathing unnaturally through a regulator is likely to panic. Yet through long stretches of the cave, he wouldn’t be able to surface and regain his composure—he would be in a flooded tunnel.

Privately experts thought maybe half the boys would survive the journey. But pulling it off 13 times in a row would take a miracle.

While plans were being developed, two alarming events occurred. First, the oxygen levels in the cave began to drop faster than anticipated. This raised fears that the boys could develop hypoxia if they remained for a prolonged time. By July 7 the oxygen level was measured to be 15 percent. The level needed to maintain normal functions page 306for humans is between 19.5 percent and 23.5 percent. Thai engineers’ attempts to install an air supply line to the boys failed.

The second development was the weather forecast. Monsoon rains were predicted for later in the week, which could flood the cave until November.

The Thai Navy SEALs, with the support of U.S. Air Force rescue experts, devised a plan approved by the Thai Minister of the Interior. Rescuers initially wanted to teach the boys basic diving skills to enable them to make the journey. Organizers even built a mockup of a tight passage with chairs and had divers practice with local boys in a nearby school swimming pool. Eventually it was decided that the boys were too weak to swim, and the plan was revised to have divers bring the boys out.

On July 8 the rescue attempt was initiated. For the first part of the mission, 18 divers were sent into the caves to retrieve the boys, with 1 diver to accompany each boy on the dive out. The boys were dressed in a wetsuit, a buoyancy jacket, and a harness. Instead of sticking a regulator in each boy’s mouth, they were given a full face mask that allowed them to breathe naturally. An oxygen cylinder was clipped to their front, a handle was attached to their back, and they were tethered to a diver in case they were lost in poor visibility.

Panic was a chief concern. The SEAL doctor administered an anesthetic to the boys before the journey, rendering them unconscious to prevent them from panicking on the escape and risking the lives of their rescuers.¹ The anesthetic lasted about 50 minutes, requiring the divers, whom the doctor had trained, to re-sedate their bodies during the three-hour-plus journey.

There was discussion about which boy should go first—the weakest, the youngest, the strongest—but in the end it came to a boy who volunteered. The boys were maneuvered out by the divers holding on to their back or chest, with each boy on the left or right depending upon the guideline. In very narrow spots, the divers had to push the boys from behind. The divers kept their heads higher than the boys so that in poor visibility the divers would hit their heads first against the rocks. After a short dive to a dry section of cave, the divers and boys were met by three divers, and the boys’ dive gear was removed. A drag stretcher was used to transport the boys up over a 200-meter stretch of rocks and sandy hills. The dive gear was put back on before entering the next submerged section.

After being delivered by the divers into the rescue base in chamber 3, the boys were then passed along a “daisy chain” of hundreds of workers stationed along the treacherous path out of the cave. The boys were alternately carried, slid, and zip-lined over a complex network of pulleys installed by rock climbers. The path out of the chamber contained many areas still partially submerged, and the boys had to be transported over slippery rocks and through muddy waters. The journey out of chamber 3 took about four to five hours initially, less later as a result of drainage.

Soon after 7 p.m. local officials announced that two boys had been rescued. Shortly later, two more boys appeared out of the cave. On July 9, four more boys were rescued. On July 10, the last four boys and their coach were rescued.

The four Thai Navy SEALs, including the doctor who had stayed with the boys the entire time, were the last to dive out. When they got to chamber 3, a water pipe burst, and the main pump stopped working. All of a sudden, the water began to rise rapidly. This forced the SEALs and 100 of the rescuers still a mile inside the cave to abandon the rescue equipment and scramble out of the cave.

page 307

Upon reaching the surface the boys were quarantined while health workers determined whether they had caught any infectious diseases. The boys were on a fixed rice porridge diet for the first 10 days. Parents initially visited their children looking through a window, but once the laboratory results proved negative, they were allowed to visit in person while wearing a medical gown, face mask, and hair cap.

After the rescue, the boys’ families, officials, and thousands of volunteers gathered at the cave entrance. The group gave thanks for the lives saved and asked forgiveness from the cave goddess, “Jao Mae Tham,” for the intrusion of pumps, ropes, and people during the rescue.

The world rejoiced with the news of the successful rescue. The head of the rescue mission said that the cave system would eventually be turned into a living museum to highlight how the operation unfolded. As a result of the incident, Thailand’s Navy SEALs will include cave diving in their training programs.

On September 7, 2018, the Royal Thai government hosted a reception for all Thai and foreign officials and personnel involved in the rescue. His Majesty the King granted a royal decoration, The Most Admirable Order of the Direkgunabhorn, to those who were involved in the rescue of the football team—114 foreigners and 74 Thais. The order is bestowed upon those who render devotional service to the Kingdom of Thailand. The title Direkgunabhorn roughly translates as “Noble order of abundance and quality.”

Three months after being rescued, the entire Wild Boar team and coach appeared on the U.S. day-time talk show Ellen. Speaking through a translator, the team revealed that four of the boys had had birthdays while trapped in the cave. The team and coach were stunned when their football hero, Zlatan Ibrahimović, who now plays for the LA Galaxy, made a surprise appearance on the show to meet them. The Swedish star high-fived each member. “These kids, this team is braver than me and they showed their collective teamwork and had patience, faith,” Ibrahimović said. “This is probably the best team in the world.”

How did the physical environment of the cave affect the rescue plan?
How did the rescue team respond to the risks of the project?
Some have called the rescue a miracle and that luck was the decisive factor. Do you agree?

Sources

ABC News, “It Was Utter Chaos: Inside the Thai Cave Rescue That Nearly Didn’t Happen,” December 1, 2018. www.abc.net.au. Accessed 2/8/19.

ABC News, “Thai Cave Rescue: Elon Musk Hits Out at Mission Chief Who Turned Down Mini-submarine Offer,” July 11, 2018. www.abc.net.au. Accessed 2/8/19.

Beech, H., R. C. Paddock, and M. Suhartono, “Still Can’t Believe It Worked: The Story of the Thailand Cave Rescue,” New York Times, July 12, 2018. www.nytimes.com. Accessed 2/9/2019.

Ellis-Petersen, H., “Thai Cave Rescue Boys Meet Hero Zlatan during Ellen Interview,” The Guardian, October 17, 2018. www.theguardian.com. Accessed 2/12/19.

Flynn, S., “Miracle at Tham Luang,” GQ, December 3, 2018. www.gq.com. Accessed 2/10/19.

¹ The Thai government provided the SEAL doctor with diplomatic immunity if something went wrong.

page 308

Appendix 8.1

The Critical-Chain Approach

In practice, project managers carefully manage slack on sensitive resource-limited projects. If possible, they will add slack at the end of the project by committing to a completion date that goes beyond the scheduled date. For example, the plans say the project should be completed on April 1, although the official completion date is May 1. Other managers take a more aggressive approach to managing slack within the schedule. They use an early start schedule and prohibit use of slack on any activity or work package to be used unless authorized by the project manager. Progress by percent complete and by remaining time is carefully monitored. Activities that are beating estimated completion times are reported so that succeeding activities can start ahead of schedule. This ensures that the time gained is used to start a succeeding activity earlier and time is not wasted. The overall intent is to create and save slack as a time buffer to complete the project early or to cover delay problems that may creep up on critical activities or paths.

Eliyahu Goldratt, who championed the “theory of constraints” in his popular book The Goal, advocates an alternative approach to managing slack.¹ He has coined the term critical chain to recognize that the project network may be constrained by both resource and technical dependencies. Each type of constraint can create task dependencies, and in the case of resource constraints, new task dependencies can be created! Remember how resource constraints shifted the critical path? If not, visit Figure 8.5 again. The critical chain is the longest string of dependencies that exist on the project. Chain is used instead of path, since the latter tends to be associated with just technical dependencies, not resource dependencies. Goldratt uses the critical-chain concept to develop strategies for accelerating the completion of projects. These strategies are based on his observations about time estimates of individual activities.

TIME ESTIMATES

Goldratt argues that there is a natural tendency for people to add safety (just-in-case) time to their estimations. It is believed that those who estimate activity times provide an estimate that has about an 80 to 90 percent chance of being completed on or before the estimated time. Hence, the median time (50/50 chance) is overestimated by approximately 30 to 40 percent. For example, a programmer may estimate that there is a 50/50 chance that he can complete an activity in six days. However, to ensure success page 309and to protect against potential problems, he adds three days of safety time and reports that it will take nine days to complete the task. In this case the median (50/50) time is overestimated by approximately 50 percent. He now has a 50/50 chance of completing the project three days ahead of schedule. If this hidden contingency is pervasive across a project, then most activities in theory should be completed ahead of schedule.

Not only do workers add safety, but project managers like to add safety to ensure that they will be able to bring the project in ahead of schedule. They will add a month to a nine-month project to cover any delays or risks that might spring up. This situation raises an interesting paradox:

Why, if there is a tendency to overestimate activity durations, and add safety to the end of a project, do so many projects come in behind schedule?

Critical-Chain Project Management (CCPM) offers several explanations:

Parkinson’s law. Work fills the time available. Why hustle to complete a task today when it isn’t due until tomorrow? Not only will the pace of work be dictated by deadline, but workers will take advantage of perceived free time to catch up on other things. This is especially true in matrix environments where workers will use this time to clear work backlog on other projects and duties.
Self-protection. Participants fail to report early finishes out of fear that management will adjust their future standards and demand more next time. For example, if a team member estimates that a task will take seven days and delivers it in five, the next time she is asked for an estimate, the project manager may want to trim the estimate based on past performance. Peer pressure may also be a factor here: to avoid being labeled a “rate buster,” members might not report early finishes.
Dropped baton. Goldratt uses the metaphor of project as relay race to illustrate the impact of poor coordination. Just as a runner’s time is lost if the next runner is not ready to receive the baton, so is the time gained from completing a task early lost if the next group of people are not ready to receive the project work. Poor communication and inflexible resource schedules prevent progress from occurring.
Excessive multitasking. The norm in most organizations is to have project personnel work on several projects, activities, or assignments at the same time. This leads to costly interruptions and excessive task splitting. As pointed out in our discussion of splitting tasks, this adds time to each activity. When looked at in isolation the time loss may seem minimal, but when taken as a whole the transition costs can be staggering.
Resource bottlenecks. In multiproject organizations, projects are frequently delayed because test equipment or other necessary resources are tied up on other project work.
Student syndrome (procrastination): Goldratt asserts that just as students delay writing a term paper until the last minute, workers delay starting tasks when they perceive that they have more than enough time to complete the task. The problem with delaying the start of a task is that obstacles are often not detected until the task is under way. When the start of the task is postponed, the opportunity to cope with these obstacles and complete the task on time is compromised.

Critical Chain in Action

CCPM’s solution to reducing project time overruns is to insist on people using the “true 50/50” activity time estimates (rather than estimates that have an 80 to 90 percent chance of being completed before the estimated time); the 50/50 estimates result page 310in a project duration about one-half the low risk of 80–90 percent estimates. This requires a corporate culture that values accurate estimates and refrains from blaming people for not meeting deadlines. According to CCPM, using 50/50 estimates will discourage Parkinson’s law, the student syndrome, and self-protection from coming into play because there is less “free time” available. Productivity will be increased as individuals try to meet tighter deadlines. Similarly, the compressed time schedule reduces the likelihood of the dropped baton effect.

CCPM recommends inserting time buffers into the schedule to act as “shock absorbers” to protect the project completion date against task durations taking longer than the 50/50 estimate. The rationale is that by using 50/50 estimates you are in essence taking out all of the “safety” in individual tasks. CCPM also recommends using portions of this collective safety strategically by inserting time buffers where potential problems are likely to occur. There are three kinds of buffers in CCPM:

Project buffer. First, since all activities along the critical chain have inherent uncertainty that is difficult to predict, project duration is uncertain. Therefore, a project time buffer is added to the expected project duration. CCPM recommends using roughly 50 percent of the aggregate safety. For example, if the modified schedule reduces the project duration by 20 days from 50 to 30, then a 10-day project buffer would be used.
Feeder buffers. Buffers are added to the network where noncritical paths merge with the critical chain. These buffers protect the critical chain from being delayed.
Resource buffers. Time buffers are inserted where scarce resources are needed for an activity. Resource time buffers come in at least two forms. One form is a time buffer attached to a critical resource to ensure that the resource is on call and available when needed. This preserves the relay race. The second form of time buffer is added to activities preceding the work of a scarce resource. This kind of buffer protects against resource bottlenecks by increasing the likelihood that the preceding activity will be completed when the resource is available.

All buffers reduce the risk of the project duration being late and increase the chance of early project completion.² See Snapshot from Practice A8.1: Critical Chain Applied to Airplane Part Arrivals.

Critical-Chain versus Traditional Scheduling Approach

To illustrate how CCPM affects scheduling, let’s compare it with the traditional approach to project scheduling. We will first resolve resource problems in the way described in Chapter 8 and then using the CCPM method. Figure A8.1A shows the planned Air Control project network without any concern for resources. That is, activities are assumed to be independent and resources will be made available and/or are interchangeable.

Figure A8.1B depicts the bar chart for the project. The dark blue bars represent the durations of critical activities; the light blue bars represent the durations of noncritical activities; the gray bars represent slack. Note that the duration is 45 days and the critical path is represented by activities 1, 4, 6, 7, and 8.

Parallel activities hold potential for resource conflicts. This is the case in this project. Ryan is the resource for activities 3 and 6. If you insert Ryan into the bar chart in Figure A8.1B for activities 3 and 6, you can see activity 3 overlaps activity 6 by five days—an page 311impossible situation. Because Ryan cannot work two activities simultaneously and no other person can take his place, a resource dependency exists. The result is that two activities (3 and 6) that were assumed to be independent now become dependent. Something has to give! Figure A8.2A shows the Air Control project network with the resources included. A pseudo-dashed arrow has been added to the network to indicate the resource dependency. The bar chart in Figure A8.2B reflects the revised schedule resolving the overallocation of Ryan. Given the new schedule, slack for some activities has changed. More importantly, the critical path has changed. It is now 1, 3, 6, 7, 8. The resource schedule shows the new project duration to be 50 days rather than 45 days.

SNAPSHOT FROM PRACTICE A8.1

Critical Chain Applied to Airplane Part Arrivals^*

In the past Spirit Aero Systems, manufacturer of airplane parts, was forced to delay product development projects as a result of missing parts for assemblies. Spirit management cycled through several approaches, such as lean, value chain, cycle time reduction, and knowledge-based engineering, to reduce the problem. Although each yielded minor improvements, the impacts were not substantial. Rework, overtime, delay costs, and vendor expediting costs continued to have significant impact on costs, meeting commitments, and reputation. Spirit turned to critical-chain management methodology in a pilot project.

Joseph Zenisek, the critical-chain manager, said the choice of critical chain was “a game changer for us.” Spirit applied the critical-chain approach to assembly of newly designed pylons (brackets) used for failure destruction testing of casings for a jet engine project. Zenisek credited success to three key factors:

Creating a rule to never start a work package until all parts and staff are available.
Ensuring part buffers to cover work packages by vigilantly monitoring assembly parts that use a large number of parts or where rate or number used is high.
Developing a small engineering team to manage vendors and buffers to ensure that delivery of over 300 parts arrived on time.

The critical-chain program led to impressive results. The parts and staffing rule cut down on late deliveries and rework on partially completed work packages caused by missing parts. The result was a reduction of 50 percent in overtime. Reducing delays reduced assembly cycle time by 18 percent. Work in process and work packages were also reduced since availability of buffer parts avoided delays. The critical-chain method led to better resource management and reduced stress.

Given the success of the critical-chain program, Spirit intends to expand the application of the critical-chain method to new product development projects for their clients.

^*Peter Fretty, “E Is in the Air,” PM Network, February 2012, pp. 50–56.

page 312

Now let’s apply the CCPM approach to the Air Control project. Figure A8.3 details many of the changes. First, notice that task estimates now represent approximations of the 50/50 rule. Second, observe that not all of the activities on the critical chain are technically linked. Manufacture custom parts is included because of previously defined resource dependency. Third, a project time buffer is added at the end of schedule. Finally, feeder buffers are inserted at each point where a noncritical activity merges with the critical chain.

The impact the CCPM approach has on the project schedule can best be seen in the Gantt chart presented in Figure A8.4. Notice first the late start times for each of the three noncritical activities. For example, under the critical path method, Order vendor page 313parts and Software development would be scheduled to begin immediately after the order review. Instead they are scheduled later in the project. Three-day feeder buffers have been added to each of these activities to absorb any delays that might occur in these activities. Finally, instead of taking 50 days, the project is now estimated to take only 27 days with a 10-day project buffer!

page 314

This example provides an opportunity for explaining the differences between buffers and slack. Slack is spare time inherent in the schedule of noncritical activities and can be determined by differences between the early start and late start of a specific activity. Buffers, on the other hand, are dedicated time blocks reserved to cover most likely contingencies and are monitored closely so, if they are not needed, subsequent activities can proceed on schedule. Buffers are needed in part because the estimates are based on 50/50 approximations, and therefore roughly half of the activities will take longer than planned. To protect against these extended activity durations, buffers are inserted to minimize the impact on the schedule. Buffers are not part of the project schedule and are used only when sound management dictates it.

While not depicted in the figures, an example of a resource buffer would be to add six days to Ryan’s schedule (remember, he is the critical resource that caused the schedule to be extended). This would ensure that he could continue to work on the project beyond the 18th day in case either Produce standard parts or Manufacture custom parts takes longer than planned. Progress on these two tasks would be monitored closely, and his schedule would be adjusted accordingly.

CCPM and Splitting Tasks

Buffers do not address the insidious effects of pervasive task splitting, especially in a multiproject environment where workers are juggling different project assignments. CCPM has three recommendations that will help reduce the impact of splitting activities:

Reduce the number of projects so people are not assigned to as many projects concurrently.
Control start dates of projects to accommodate resource shortages. Don’t start projects until sufficient resources are available to work full time on the project.
Contract (lock in) for resources before the project begins.

Monitoring Project Performance

The CCPM method uses buffers to monitor project time performance. Remember that as shown in Figure A8.3 a project buffer is used to insulate the project against delays along the critical chain. For monitoring purposes, this buffer is typically divided into three zones—OK, Watch & Plan, and Act, respectively (see Figure A8.5). As the buffer begins to decrease and moves into the second zone, alarms are set off to seek corrective action. To be truly effective, buffer management requires comparing buffer usage with actual progress on the project. For example, if the project is 75 percent complete and you have only used 50 percent of the project buffer, then the project is in pretty good shape. Conversely, if the project is only 25 percent complete and 50 percent of the buffer has already been used, you are in trouble and corrective action is needed. A method for estimating percentage complete is described in Chapter 13.

The CCPM Method Today

CCPM has generated considerable debate within the project management community. While sound in theory, support at this time is limited but growing. For example, Harris page 315Semiconductor was able to build a new automated wafer fabrication facility within 13 months using CCPM methods when the industry standard for such a facility was 26–36 months. The Israeli aircraft industry has used CCPM techniques to reduce average maintenance work on aircraft from two months to two weeks. The U.S. Air Force and Navy as well as Boeing, Lucent Technologies, Intel, GM, and 3M are applying critical-chain principles to their multiproject environments.³

CCPM is not without critics. First, CCPM does not address the biggest cause of project delays, which is an ill-defined and unstable project scope. Second, some critics challenge Goldratt’s assumptions about human behavior. They question the tendency of experts to pad estimates and the fact that employees act deliberately against the organization for their own interest and benefit (c.f., Button, 2011; Pinto, 1999). Critics also object to the insinuation that trained professionals would exhibit the student syndrome habits (Zalmanson, 2001). Third, evidence of success is almost exclusively anecdotal and based on single case studies or on computer modeling. The lack of systematic evidence raises questions about generalizability of application. CCPM may prove to work best for only certain kinds of projects (Raz, Barnes, & Dvir, 2003).

One of the keys to implementing CCPM is the culture of the organization. If the organization honors noble efforts that fail to meet estimates as it does efforts that do meet estimates, then greater acceptance will occur. Conversely, if management treats honest failure differently than success, then resistance will be high. Organizations adopting the CCPM approach have to invest significant energy in obtaining “buy-in” on the part of all participants to its core principles and allaying the fears that this system may generate.

Appendix Summary

Regardless of where one stands in the debate, the CCPM approach deserves credit for bringing resource dependency to the forefront, highlighting the modern ills of multitasking, and forcing us to rethink conventional methods of project scheduling.

Appendix Review Questions

Explain how time is wasted in the management of projects.
Distinguish between project and feeder buffers.
Buffers are not the same as slack. Explain.

page 316

Appendix Exercises

Check out the Goldratt Institute’s homepage at http://www.goldratt.com for current information on the application of critical-chain techniques to project management.
Apply critical-chain scheduling principles to the Print Software, Inc., project (Exercise 10) presented in Chapter 6. Revise the estimated time durations by 50 percent, except round up the odd time durations (e.g., 3 becomes 4). Draw a CCPM network diagram similar to the one contained in Figure A8.3 for the Print Software project, as well as a Gantt chart similar to Figure A8.4. How would these diagrams differ from the ones generated using the traditional scheduling technique?

Appendix References

Budd, C. S., and M. J. Cooper, “Improving On-time Service Delivery: The Case of Project as Product,” Human Systems Management, vol. 24, no. 1 (2005), pp. 67–81.

Button, S., “A Critical Look at Critical Chain,” EM 540 research paper, March 2011.

Goldratt, E., The Goal (Great Barrington, MA: North River Press, 1997).

Herroelen, W., R. Leus, and E. Demeulemeester, “Critical Chain Project Scheduling: Do Not Oversimplify,” Project Management Journal, vol. 33, no. 4 (2002), pp. 48–60.

Leach, L. P., “Critical Chain Project Management,” Proceedings of 29th Annual Project Management Institute, 1998, Seminars and Symposium (Newtown, PA: Project Management Institute, 1998), pp. 1239–44.

Levine, H. A., “Shared Contingency: Exploring the Critical Chain,” PM Network, October 1999, pp. 35–38.

Newbold, R. C., Project Management in the Fast Lane: Applying the Theory of Constraints (Boca Raton, FL: St. Lucie Press, 1998).

Noreen, E., D. Smith, and J. Mackey, The Theory of Constraints and Its Implication for Management Accounting (Great Barrington, MA: North River Press, 1995).

Pinto, J., “Some Constraints on the Theory of Constraints: Taking a Critical Look at Critical Chain,” PM Network, 1999, pp. 49–51.

Raz, T., R. Barnes, and D. Dvir, “A Critical Look at Critical Chain Project Management,” Project Management Journal (December 2003), pp. 24–32.

Sood, S., “Taming Uncertainty: Critical-Chain Buffer Management Helps Minimize Risk in the Project Equation,” PM Network, March 2003, pp. 57–59.

Steyn, H., “An Investigation into the Fundamentals of Critical Chain Scheduling,” International Journal of Project Management, vol. 19 (2000), pp. 363–69.

Zalmanson, E., “Readers Feedback,” PM Network, 2001, p. 4.

¹ Goldratt, E., The Goal (Great Barrington, MA: North River Press, 1997).

page 317

Case A8-1

The CCPM Dilemma

Pinyarat worked in the IT Department of a diversified IT firm. She was describing the firm’s early encounters with critical-chain scheduling to a friend in another IT firm.

Three years ago management decided to add 10 percent time to all activity estimates because almost all projects were coming in late. One thought was people were simply working too hard and needed some relief. This approach did not work! Projects still came in late. Next, management decided to take away the extra time for activities and add 10 percent for project estimates to ensure project durations would be met. Again, nothing improved and projects continued to come in late. Recently, the firm hired a consultant who promoted critical-chain scheduling, which was implemented for all projects in her division. Almost all failed to perform.

Pinyarat explained, “The estimates were basically impossible. The activity durations got squeezed down to less than the 50 percent guideline. We were late on nearly every task. In addition, I was not allowed to put in a big enough project buffer, which only added to projects being late. One colleague who was working on six projects gave up and quit; he said he was killing himself and saw no hope of things getting better. My projects are not the only ones having big problems. Some people had no idea why anyone would use CCPM scheduling. To quote one of my best programmers: ‘They ask for an estimate and then they cut it 50 percent or more.’ What kind of game is this? Apparently they don’t trust us.”

A week later, to Pinyarat’s surprise, she was called to the IT manager’s office. Pinyarat imagined numerous bad scenarios of how the meeting would go—even to the remote possibility of being fired! The manager wanted the division to straighten out their project management practices and stop this business of nearly all IT projects being late. There were rumors of cleaning house or outsourcing IT work.

The manager believed that Pinyarat, who passed the PMP exam, had the best chance of turning things around. He said, “Pinyarat, I’m nearing the desperate level; top management is reaching the end of the rope with our division. We need to turn this around for both our sakes. Give me a plan that I can sponsor within the week.”

Pinyarat explained to her friend a few of her ideas—like squeezing estimates too far. But she said she would take any ideas she could get from anyone.

Give Pinyarat a report that identifies the key problems and a plan of action she can present to her sponsor. Limit your report to 800 words or less.

¹ See the appendix at the end of this chapter for more on how resource constraints affect project schedule.

² For more information on buffers, see: Leach, L. P., “Critical Chain Project Management Improves Project Performance,” Project Management Journal, vol. 30, no. 2 (1999), pp. 39–51.

³ Cited in materials developed by the Eliyahu Goldratt Institute (New Haven, CT) for a workshop attended by one of the authors entitled “Project Management the TOC Way,” 1998.