Reducing Project Duration: Project

Crashing

Some Definitions Resource allocation permits efficient

use of physical assets Within a project, or across multiple projects Drives both the identification of resources,

and timing of their application There are generally two conditions:

“Normal” “Crashed”

Rationale for Reducing Project Duration

Time Is Money: Cost-Time Tradeoffs Reducing the time of a critical activity usually

incurs additional direct costs. Cost-time solutions focus on reducing (crashing)

activities on the critical path to shorten overall duration of the project.

Reasons for imposed project duration dates: Customer requirements and contract

commitments Time-to-market pressures Incentive contracts (bonuses for early

completion) Unforeseen delays Overhead and goodwill costs Pressure to move resources to other projects

Explanation of Project Costs Project Indirect Costs

Costs that cannot be associated with any particular work package or project activity.

Supervision, administration, consultants, and interest

Costs that vary (increase) with time. Reducing project time directly reduces indirect

costs. Direct Costs

Normal costs that can be assigned directly to a specific work package or project activity.

Labor, materials, equipment, and subcontractors

Crashing activities increases direct costs.

Normal and Crashing Normal: Most likely task duration,

like “m” in ‘Schedule Control’ Crash: Expedite an activity, by

applying additional resources Specialized or additional equipment More people (e.g., borrowed staff,

temps) More hours (e.g., overtime, weekends)

No Free Lunch: Crashing Creates a Ripple Effect

Crashing buys time, but nothing comes free Potential cost areas

Additional equipment/material Extra labor Negative effects on other projects Reduced morale, from excessive hours/shifts Lower quality, from the pressure of time,

inexperienced and tired staff “If you want it bad, you’ll get it bad . . .”

Case: Architectural Associates, Inc.

Projects uniformly run late, thus over budget

Is that the problem, or just the symptom?

Case: Architectural Associates, Inc. (cont’d)

PROBLEM: Deterministic task schedules cause workers to plan to meet schedule – nothing more, nothing less Parkinson’s Law: “Work expands to fill the

time available.” RESULT: Issues arising early in each

task can be worked around, but late-occurring issues can’t be absorbed in schedule And most issues do arise late

Case: Architectural Associates, Inc. (concluded)

The Solution: Use probabilistic time estimates

(optimistic, pessimistic, most likely) Have staff schedule work for

effectiveness and efficiency, not just to fill x-number of days

Reducing Project Duration to Reduce Project Cost

Compute total costs for specific durations and Compute total costs for specific durations and compare to benefits of reducing project time.compare to benefits of reducing project time.

Compute total costs for specific durations and Compute total costs for specific durations and compare to benefits of reducing project time.compare to benefits of reducing project time.

Search critical activities for lowest direct-cost Search critical activities for lowest direct-cost activities to shorten project duration.activities to shorten project duration.

Search critical activities for lowest direct-cost Search critical activities for lowest direct-cost activities to shorten project duration.activities to shorten project duration.

Identifying direct costs to reduce project timeIdentifying direct costs to reduce project timeIdentifying direct costs to reduce project timeIdentifying direct costs to reduce project time

Gather information about direct and indirect Gather information about direct and indirect costs of specific project durations. costs of specific project durations.

Gather information about direct and indirect Gather information about direct and indirect costs of specific project durations. costs of specific project durations.

Project Cost—Duration Graph

Constructing a Project Cost—Duration

Graph

Find total direct costs for selected project durations.

Find total indirect costs for selected project durations.

Sum direct and indirect costs for these selected project durations.

Compare additional cost alternatives for benefits.

When Trying to Crash a Project . . . Two basic principles

1. Generally, focus on the critical path Usually not helpful to shorten non-critical

activities Exception: When a scarce resource is

needed elsewhere, e.g., in another project 2. When shortening project duration,

choose least expensive way to do it

Fast-Tracking a Project Used Primarily in Construction

Industry Building phase started before

design and planning phases completed

Particularly appropriate when large proportion of work is routine

Approach to Expediting: Fast-tracking/Concurrency

Different terms for similar concept “Fast-tracking” (construction),

“Concurrent engineering” (manufacturing)

Both refer to overlapping project phases E.g., design/build, or build/test

Fast-tracking/Concurrency (cont’d) Pros:

Can shorten project duration Can reduce product development cycles Can help meet clients’ demands

Cons: Can increase cost through redesigns,

excessive changes, rework, out-of-sequence installation, and more

Constructing a Project Cost—Duration

Graph Determining Activities to Shorten

Shorten the activities with the smallest increase in cost per unit of time.

Assumptions: The cost relationship is linear. Normal time assumes low-cost, efficient

methods to complete the activity. Crash time represents a limit—the greatest

time reduction possible under realistic conditions.

Slope represents a constant cost per unit of time.

All accelerations must occur within the normal and crash times.

Compute Cost per Day of Crashing a Project

Compute cost/time slope for each expeditable activity

Slope = crash cost – normal cost normal time - crash time

Activity Graph

FIGURE: Network with Normal and Crash Times and Their Costs

TABLE: TimeCost TradeOff

Cost—Duration Trade-off: Another Example

Cost—Duration Trade-off Example (cont’d)

Cost—Duration Trade-off Example (cont’d)

Cost—Duration Trade-off Example (cont’d)

Cost—Duration Trade-off Example (cont’d)

Summary Costs by Duration

Project Cost—Duration Graph

Practical Considerations Using the Project Cost—Duration Graph

Crash Times

Linearity Assumption

Choice of Activities to Crash Revisited

Time Reduction Decisions and Sensitivity

What if Cost, Not Time is the Issue? Commonly Used Options for Cutting

Costs Reduce project scope

Have owner take on more responsibility

Outsourcing project activities or even the entire project

Brainstorming cost savings options

“Cost, Schedule, or Performance: Pick Any Two.”

Assuming fixed performance specifications, tradeoff areas must be in time or cost

Time-limited or resource-limited If all three dimensions are fixed,

the system is “overdetermined” Normally, no tradeoffs are possible But, something has to give . . .

Goldratt’s Critical Chain: Introduction

Similar issues that trouble people about working on projects regardless of type of project unrealistic due dates too many changes resources and data not available unrealistic budget

These issues/problems related to need to make trade-offs

To what extent are these problems caused by human decisions and practices?

Goldratt’s Critical Chain There are systemic problems that

plague project schedule performance These problems are not randomly

distributed If they were random, there would be

as many projects finishing early as late

Some Systemic Causes of Late Projects 1. Thoughtless Optimism

Overpromising at project start “Success-oriented” schedules Lack of management reserves

2. Setting capacity equal to demand Ignoring concepts of resource loading

and leveling

Common Chain of Events Safety time misused Misused safety time results in

missed deadlines Hidden safety time complicates

task of prioritizing project activities Lack of clear priorities results in

poor multitasking

Some Systemic Causes of Late Projects (cont’d)

3. “The Student Syndrome” Delaying start of non-critical tasks Parkinson’s Law: “Work expands to

fill the time available” 4. Multitasking to reduce idle time

Switching back and forth between projects creates delays

Common Chain of Events Poor multitasking increases task

durations Uneven demand on resources also

results due to poor multitasking More projects undertaken to ensure

all resources fully utilized More projects further increases

poor multitasking

Some Systemic Causes of Late Projects (concluded)

5. Complexity of schedule drives delay Uncertainty and complex paths join to make

trouble 6. People need reason to strive

There’s often no advantage seen to finishing early

7. Game playing E.g., lower levels pad estimates, senior

management slashes them Both can be equally arbitrary

Reversing the Cycle Reduce number of projects assigned to

each individual Schedule start of new projects based on

availability of bottleneck resources Reduce amount of safety time added to

individual tasks and then add some fraction back as project buffer activity durations set so that there is a high

probability the task will not be finished on time

The Critical Chain Longest chain of consecutively

dependent events considers both precedence

relationships and resource dependencies

Project Buffer Feeding Buffer

Figure: Project and Feeder Buffers