CSCI 411

March 11, 2015

Scheduling - adjusting

Copyright © 2010 by the McGraw-Hill Companies, Inc. All rights reserved.McGraw-Hill/Irwin

Exhibit 8.1

Reasons for Schedule Modifications

8-2

Exhibit 8.2Initial Network Schedule for Product Development Project with Early- and Late-Start Finish Times

8-3

Schedule Modification Options

• Crashing

• Fast Tracking

• Delay Some Activities to Reallocate Resource Expenditures

• Reduce Scope

8-4

Exhibit 8.4

Original and Compressed Schedules for Product Development Example Shown as a Comparative Gantt Chart

8-5

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-6

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-7

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-8

Exhibit 8.5

Crashing Project Schedules

8-9

Box 8.1

Round-the-Clock ProgrammingA 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-10

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-11

Determining Ongoing Project Costs, Early-Completion 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-12

Determining Ongoing Project Costs, Early-Completion 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-13

Exhibit 8.7

Sequential Procedure for Crashing Project Activities

8-14

Exhibit 8.8

Crash-Cost Calculations for Garage Remodel and Car Repair Project

8-15

Exhibit 8.9

AON Diagram for Garage Remodel and Car Repair Project

8-16

Exhibit 8.10

Time-Based Network for Garage Remodel and Car Repair Project

8-17

Exhibit 8.11

Tabular Approach for Sequential Crashing

8-18

Exhibit 8.12

19-Day Schedule for Garage Remodel and Car Repair Project after Task A Is Crashed by 2 Days

8-19

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-20

Exhibit 8.1416-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-21

Exhibit 8.1515-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-22

Applying Crashing Concepts

• 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.

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:

8-23

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-24

Exhibit 8.16

Depicting Fast Tracking for an Internet Project Using a Start-to-Start Precedence Relationship

8-25

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-26

Exhibit 8.17

Simple Resource Allocation Problem Demonstrating the Use of Schedule Float to Create Even Workforce Loading

8-27

Exhibit 8.18

Precedence Table for Wildlife Film Project

Exhibit 8.18 Precedence Table for Wildlife Film Project

8-28

Exhibit 8.19

Early-Start Time-Based Network for First Phase of Wildlife Film Project

8-29

Time Constrained Resource SmoothingTime-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-30

Exhibit 8.20

Excel Based Gantt Chart

and Histogram Showing Resource Loads for Early-Start

Schedule of Wildlife Film

Project

8-31

Exhibit 8.21

Time-Constrained

Resource Smoothing:

Modified Schedule for Wildlife Film Project with Noncritical Activities Delayed

8-32

Exhibit 8.22

Modified Wildlife Film Project after First Two Resource Allocation Decisions under 12-Crewmember Constraint

8-33

Modifying the Schedule When There Is a Resource LimitA 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 project-specific 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-34

Exhibit 8.23

Schedule Modification to Accommodate 12-Crewmember Constraint: Wildlife Film Project Is Extended by Four Weeks

8-35

Exhibit 8.24

MS Project Gantt View of Wildlife Film Project Early-Start Schedule

8-36

Exhibit 8.25

MS Project Resource Histogram for Wildlife Film Project Early-Start Schedule

8-37

Exhibit 8.26

MS Project Gantt View of Wildlife Film Project Schedule Following Software-Generated Resource Leveling

8-38

Exhibit 8.27

MS Project Resource Histogram for Wildlife Film Project Leveled Schedule

8-39