Resource Allocation • Some definitions • Resource allocation, loading, leveling • Expediting and crashing projects • Goldratt’s “Critical Chain”
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”
Normal and Crashing • Normal: Most likely task duration, like “m” in Chapter 8 • 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
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
Compute Cost per Day of Crashing a Project • Compute cost/time slope for each expeditable activity • Slope = crash cost – normal cost crash time – normal time
An Example (Table 9-1) *Partial crashing allowed ** Partial crashing not allowed
Example (cont’d): Cost per Day to Crash (Table 9-2)
A CPM Example, Figure 9-1
Another 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
CPM Cost-Duration, Figure 9-2
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
“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 . . .
Resource Loading • Resource loading: types and quantities of resources, spread by schedule across specific time periods • One project, or many • Identifies and reduces excess demands on a firm’s resources
Resource Usage Calendar, Figure 9-3
AOA Network, Figure 9-4
Modified PERT/CPM AOA, Figure 9-5
Resource Leveling • Resource leveling minimizes period-by-period variations in resource loading, by shifting tasks within their slack allowances • Advantages • Less day-to-day resource manipulation needed • Better morale, fewer HR problems/costs • Leveling resources also levels costs, simplifies budgeting and funding
Load Diagrams, Figure 9-6
Network Before and After Resource Loading, Figure 9-7
Load Diagrams, Figure 9-8
Resource Loading Chart, Figure 9-9
Constrained Resource Scheduling • Two basic approaches • Heuristic • Rule-based, rules of thumb • Priority rules, tie-breakers • Optimization • Not finding an answer that works, but the best answer
MSP Gantt with Resources, Figure 9-10
MSP Load Diagram, Showing Resource Conflict, Figure 9-11
MSP Load Diagram, Leveled, Figure 9-12
Network for Resource Load Simulation, Figure 9-13
Load Chart, Figure 9-14
Task a Decomposed, Figure9-15
Hierarchy of Gantt Charts, Figure 9-16
Sources and Uses of Resources, Figure 9-17
Project Life Cycles, Figure 9-18
Flow Diagram for SPAR-1, Figure 9-19
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
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
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
