Chapter 8
Modifying Project
Schedules to
Accommodate Time and
Resource Constraints
McGraw-Hill/Irwin
Copyright © 2010 by the McGraw-Hill Companies, Inc. All rights reserved.
Chapter Learning Objectives
When you have mastered the material in this chapter,
you should be able to:
•
Recognize project constraints and apply the appropriate
combination of methods to modify existing schedules.
•
Apply the logic of time-cost trade-offs to systematically
shorten a project’s expected duration by adding resources
to key activities.
•
Level-load project schedules to reduce variation in resource
requirements or meet resource limitations.
•
Estimate realistic project completion times by incorporating
information about the availability of specialized resources.
•
Differentiate between the critical path and the critical chain,
and apply buffer concepts to reduce schedule risks.
•
Explain project modification options to stakeholders and
offer rational arguments for the most appropriate choices.
8-2
Modifying Project Schedules to
Accommodate Time and Resource
Constraints
“The first schedule is always wrong.”
Frederick Brooks
8-3
Exhibit 8.1
Reasons for Schedule Modifications
8-4
Exhibit 8.2
Initial Network Schedule for Product Development
Project with Early- and Late-Start Finish Times
8-5
Schedule Modification Options
• Crashing
• Fast Tracking
• Delay Some Activities to Reallocate
Resource Expenditures
• Reduce Scope
8-6
Exhibit 8.4
Original and Compressed Schedules for Product
Development Example Shown as a Comparative
Gantt Chart
8-7
Exhibit 8.4
Original and Compressed Schedules for Product
Development Example Shown as a Comparative
Gantt Chart
In this revised schedule,
• Task A, user requirements, and Task B, benchmark, are fast-tracked
(performed concurrently), which shortens the planned duration by one
month.
• This allows hardware, Task C, and software, Task D, to start a month
earlier.
• However, it is not actually necessary to begin Task C, hardware, right
after benchmarking is complete, so it has been delayed by one month,
still leaving an additional month of float as a schedule buffer.
• Task D, software, can be crashed; more programmers can be hired to
reduce duration from five months to four months.
• Integration, Task E, can start two months earlier than initially planned if
software is completed at the end of month 6.
continued
8-8
Exhibit 8.4
Original and Compressed Schedules for Product
Development Example Shown as a Comparative
Gantt Chart
• Task F, production ramp up, can begin two months earlier than
planned, and it can be reduced by two months because of a
reduction in scope.
• The marketing plan, Task G, can also begin two months earlier
than the initial plan, but could, if necessary, be delayed or extended
by a month because it has float.
• And, Task H, handoff, can be completed at the end of month 13,
meeting the expectations of the sponsor.
Of course, whether or not this new schedule works will depend on
everything happening monthly. The project manager must clearly
communicate the benefits, risks and potential challenge associated
with this new schedule.
8-9
Crashing Project Schedules
• Crashing involves an analysis of trade-offs
between prolonging a project or adding
resources to shorten it.
• To make project crashing decisions
requires some knowledge of the cost of
reducing task durations.
• Some activities can be shortened easily,
others are more difficult to divide.
8-10
Exhibit 8.5
Crashing Project Schedules
8-11
Box 8.1
Round-the-Clock Programming
A Canadian company specializing in data-mining software for enterprisewide IT
systems attempted to speed up some of its projects with round-the-clock
programming. Programmers in Canada finished their work at the end of each
day and electronically handed it off to programmers in India as they began their
workdays. This was intended to cut programming time in half. Unfortunately, the
geographic distance and asynchronous timing made it impossible for real-time
communication, and the receiving team had trouble understanding the details
and rationale underlying the programming done by colleagues on the other side
of the world. The series of handoffs, likened to a relay race, actually caused
projects to take more, rather than less, time. Company officials realized that
although this type of programming had become an industry trend, it was not
effective for their work. Consequently, they divided the work so certain projects
were performed entirely in Canada and others were performed entirely in India.
Productivity improved and projects were completed in far less time, and with
better outcomes, than they had been under the round-the-clock strategy.
8-12
Determining Crash Costs for Trade-Off
Analysis
A general formula for calculating incremental crash costs is
as follows:
Incremental crash cost =
Crash cost - Normal cost
Normal time - Crash time
Where:
• Normal time is the time required for a task under
normal conditions, typically in the time specified in the
initial project schedule.
• Crash time is the least amount of time in which a task
can be feasibly completed.
• Normal cost is the cost of completing the task at its
normal time.
• Crash cost is the cost of completing the task at its
fully crashed time.
8-13
Determining Ongoing Project Costs, EarlyCompletion Incentives, and Delay Penalties for
Trade-Off Analysis
During the life cycle of any project, a set of costs
accumulates on a daily basis. These can include:
• Salaries and benefits of core team members,
adjusted for the percent of their time allocated
to the project.
• Apportioned percentages of salaries and
benefits of personnel who provide support
services to team members.
• Apportioned costs associated with the physical
space where team members work (rent,
utilities).
• Rental of equipment dedicated to the project.
8-14
Determining Ongoing Project Costs, EarlyCompletion Incentives, and Delay Penalties for
Trade-Off Analysis
In addition to costs that accumulate over the life of
the project, other incentives for finishing a project
sooner rather than later can include:
• Incentives offered by customers for early completion.
• Contractual penalties for late delivery.
• Lost profits associated with late market entry.
Beyond tangible costs and incentives, a project
manager also should consider:
• The potential for declining morale and associated losses
in productivity and quality when a project is prolonged.
Shorter projects hold people’s attention better than longer
projects.
8-15
Exhibit 8.7
Sequential Procedure for Crashing
Project Activities
8-16
Exhibit 8.8
Crash-Cost Calculations for Garage Remodel and Car
Repair Project
8-17
Exhibit 8.9
AON Diagram for Garage Remodel and Car
Repair Project
8-18
Exhibit 8.10
Time-Based Network for Garage
Remodel and Car Repair Project
8-19
Exhibit 8.11
Tabular Approach for Sequential Crashing
8-20
Exhibit 8.12
19-Day Schedule for Garage Remodel and Car
Repair Project after Task A Is Crashed by 2 Days
8-21
Exhibit 8.13
17-Day Schedule for Garage Remodel and Car
Repair Project after Task A Is Crashed by Two
Days and Task D Is Crashed by Two Days
8-22
Exhibit 8.14
16-Day Schedule for Garage Remodel and Car Repair Project after
Task A Is Crashed by Two Days, Task D Is Crashed by Two Days,
and Tasks D and F Are Crashed Simultaneously by One Day
8-23
Exhibit 8.15
15-Day Schedule for Garage Remodel and Car Repair Project
after Task A Is Crashed by Two Days, Task D Is Crashed by
Two Days, Tasks D and F Are Crashed Simultaneously by One
Day, and Task G Is Crashed by One Day
8-24
Applying Crashing Concepts
In selecting tasks to crash in the absence of objective crash cost
data, a project team should focus on the critical path. Beyond that,
consider crashing:
•
Start-up activities. Compressing early activities leaves room
for unexpected contingencies that arise during project
delivery.
•
Activities in bottleneck positions. It makes sense to
compress an activity that can affect many others.
•
Long-duration activities. It is easier to find opportunities for
compressing longer activities rather than shorter ones.
•
Labor-intensive or low-skill activities. These are less
expensive to compress than a technology-dependent activity.
•
Activities subject to uncontrollable risks. Some activities
are more vulnerable to risks than others.
•
Divisible activities. Some activities are easier than others to
divide and parcel out to several people.
8-25
Fast Tracking
• Fast tracking involves scheduling two
or more tasks simultaneously.
• Fast tracking can be applied
independently or in combination with
crashing and scope reduction to
shorten a project’s duration.
8-26
Exhibit 8.16
Depicting Fast Tracking for an Internet Project
Using a Start-to-Start Precedence Relationship
8-27
Modifying Schedules to
Accommodate Resource Constraints
• Often, the first draft of a project schedule reveals
that necessary resource loads exceed the
availability of team members (overallocation).
• Or resource levels can be very uneven, producing
situations in which people sometimes do not have
enough to do (underallocation) and giving them
impossibly heavy workloads at other times.
• Through the use of schedule float, it can be
possible to smooth out the peaks and valleys in a
resource load profile.
8-28
Exhibit 8.17
Simple Resource Allocation Problem Demonstrating the
Use of Schedule Float to Create Even Workforce Loading
8-29
Exhibit 8.18
Precedence Table for Wildlife Film Project
Exhibit 8.18
Precedence Table for Wildlife Film Project
8-30
Exhibit 8.19
Early-Start Time-Based Network for
First Phase of Wildlife Film Project
8-31
Time Constrained Resource
Smoothing
Time-constrained resource smoothing. Redistributing
resources and float within the confines of a specified end date.
The process:
1. Schedule critical path activities. Assuming the project cannot
be delayed, the critical path is a given constraint.
2. Schedule noncritical activities. Use a combination of a few
decision rules and common sense.
 For example, compare activities that are eligible to be
added to the schedule based on the float they have
available. Activities with the least float should have
higher priority.
 In cases where there is a tie between two activities
based on float, give priority to shorter activities near the
beginning of the project.
8-32
Exhibit 8.20
Excel Based
Gantt Chart
and
Histogram
Showing
Resource
Loads for
Early-Start
Schedule of
Wildlife Film
Project
8-33
Exhibit 8.21
TimeConstrained
Resource
Smoothing:
Modified
Schedule for
Wildlife Film
Project with
Noncritical
Activities
Delayed
8-34
Exhibit 8.22
Modified Wildlife Film Project after First Two
Resource Allocation Decisions under
12-Crewmember Constraint
8-35
Modifying the Schedule When There
Is a Resource Limit
A procedure for solving a resource-constrained problem is to
schedule the activities one week at a time, starting on the left.
1. Identify all activities eligible to begin, and give priority
to those with the least float.
2. If there is a tie, it is reasonable to select those with
resource loads that complement the loads of other
eligible activities, or those that bring the resource load
closest to reaching the limit.
3. As with time-constrained leveling, the team engaged
in scenario planning must consider other projectspecific factors.
In resource-constrained allocation problems it is not
appropriate to automatically schedule the critical path—it has
priority, though, because it has no float.
8-36
Exhibit 8.23
Schedule Modification to Accommodate
12-Crewmember Constraint: Wildlife Film Project Is
Extended by Four Weeks
8-37
Exhibit 8.24
MS Project Gantt View of Wildlife Film
Project Early-Start Schedule
8-38
Exhibit 8.25
MS Project Resource Histogram for
Wildlife Film Project Early-Start Schedule
8-39
Exhibit 8.26
MS Project Gantt View of Wildlife Film Project Schedule
Following Software-Generated Resource Leveling
8-40
Exhibit 8.27
MS Project Resource Histogram for
Wildlife Film Project Leveled Schedule
8-41
Exhibit 8.28
Network Schedule for an IT Project with Constraints on
Specialized Resources
8-42
Exhibit 8.28
Network Schedule for an IT Project with Constraints on
Specialized Resources
8-43
Exhibit 8.28
Precedence Table for Network Schedule for an IT
Project with Constraints on Specialized Resources
8-44
Exhibit 8.29
Early-Start Schedule for IT Project
with Specialized Resources
This is an impossible schedule! Individual team members are expected to perform
more than one task at a given time. It is impossible to accommodate the resource
constraints without extending the schedule.
8-45
Exhibit 8.30
27-Day Schedule for IT Project with
Specialized Resources
8-46
Adjusting the Schedule to Accommodate
Specialized Resources
1. Consider delaying tasks with the most
float.
2. For resource-conflicted tasks that appear
early in the project, consider scheduling
the shorter tasks before longer tasks for
each resource.
3. For resource-conflicted tasks that appear
late in the project, consider scheduling
shorter tasks later than longer tasks for
each resource.
8-47
Exhibit 8.31
22-Day Schedule for IT Project with
Specialized Resources
8-48
Exhibit 8.32
19-Day Schedule for IT Project with Specialized
Resources (Shortest-Time Feasible Option)
8-49
Exhibit 8.33
19-Day Schedule with Critical Chain
Highlighted (dashed boxes)
8-50
Critical Chain Concepts
•
Critical chain – The actual sequence of
deliverables, activities, tasks, or work packages
that cannot be delayed without delaying the
project.
•
While similar to the critical path concept, the
critical chain adds another layer of complexity by
taking into account resource availability.
•
Tips for managing the critical chain:
 Give priority to the critical chain
 Use schedule buffers to protect the critical
chain
 Beware the effects of multitasking
8-51
Critical Chain Concepts - Buffers
•
Feeding Buffer – A segment of float intentionally scheduled
at points where noncritical activities merge with the critical
chain.
•
Resource Buffer – A time designated within a critical chain
activity whereby the owner of that activity shares information
about the progress of the current activity with the owner of
the subsequent critical chain activity. The resources buffer is
set at a certain number of days prior to the scheduled end of
the critical chain activity underway.
•
By sharing this information prior to the end of the
activity problems or possible causes for delay might
be resolved. This helps mitigate the risk of delay to
the project.
•
Project Buffer – The time between a project’s anticipated
end date and the due date specified by the customer.
Project buffers are often used in lieu of buffers within
individual activities, which allows for the sharing of buffer
time between all team members.
8-52
Box 8.2
The Advantage of Working on One
Project at a Time
The CEO of an international corporation that designs and
manufactures industrial cutting equipment gave a speech at a
professional meeting to explain some of his company’s
successes. Most notable was the company’s 50 percent reduction
in product development time. When asked what the company had
done to make such a dramatic improvement, he replied: “We
insisted that every engineer work on only one project at a time. I’m
personally committed to this and regularly walk through the design
department to ask people what they are working on. If an
individual tells me that he or she is working on multiple projects, I
make a visit to the supervisor to correct the problem.” He went on
to say, “Our goal as an organization is not to see how busy we
can keep the engineers—it is to get the projects out the door in a
8-53
timely manner.”
Exhibit 8.34
Effects of Multitasking in Engineering Projects
8-54
Chapter Summary
• This chapter presents several tools and concepts for modifying
schedules to accommodate time and resource constraints.
• Creative solutions are available to those who understand
network scheduling concepts and how to use them as tools for
problem solving and persuasion.
• Before asking for more resources or time, the effective project
manager investigates the potential to:
• eliminate WBS activities (scope reduction)
• add resources to critical tasks to shorten durations (crash)
• perform sequentially related tasks concurrently (fast track)
• or delay tasks to reallocate resources
• In the case of crashing, the project manager might have to ask
for more money to compensate for potential lost efficiency, but
the overall cost of a crashed schedule should be less than one
without crashing when time-related fixed costs are considered.
8-55
Chapter 8
Team Activities and
Discussion Questions
and Exercises
8-56
Team Activity 8-2
Network Diagram for Web Site Design
8-57
Exercise 8-7
Network Diagram for Road Construction Project
8-58
Exercise 8-8
Network Diagram for IT Project
8-59
Exercise 8-9
Software Project Development Time and
Number of Programmers
8-60