1. Reducing Project Duration: Project Crashing

2. 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”

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

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

5. 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)

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

7. Case: Architectural Associates, Inc.
Projects uniformly run late, thus over budget
Is that the problem, or just the symptom?

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

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

10. Reducing Project Duration to Reduce Project Cost
Identifying direct costs to reduce project time
Gather information about direct and indirect costs of specific project durations.
Search critical activities for lowest direct-cost activities to shorten project duration.
Compute total costs for specific durations and compare to benefits of reducing project time.

11. Project Cost—Duration Graph

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

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

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

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

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

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

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

19. Activity Graph

20. FIGURE: Network with Normal and Crash Times and Their Costs

21. TABLE: Time-Cost Trade-Off

22. Cost—Duration Trade-off: Another Example

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

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

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

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

27. Summary Costs by Duration

28. Project Cost—Duration Graph

29. Practical Considerations
Using the Project Cost—Duration Graph
Crash Times
Linearity Assumption
Choice of Activities to Crash Revisited
Time Reduction Decisions and Sensitivity

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

31. “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 . . .

32. 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?

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

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

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

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

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

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

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

40. The Critical Chain Longest chain of consecutively dependent events
considers both precedence relationships and resource dependencies
Project Buffer
Feeding Buffer

41. Figure: Project and Feeder Buffers