Efficient Resource Allocation in Project Management

1. Resource Allocation • Some definitions • Resource allocation, loading, leveling • Expediting and crashing projects • Goldratt’s “Critical Chain”

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

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

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

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

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

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

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

10. An Example (Table 9-1) *Partial crashing allowed ** Partial crashing not allowed

11. Example (cont’d): Cost per Day to Crash (Table 9-2)

12. A CPM Example, Figure 9-1

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

14. CPM Cost-Duration, Figure 9-2

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

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

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

18. Resource Usage Calendar, Figure 9-3

19. AOA Network, Figure 9-4

20. Modified PERT/CPM AOA, Figure 9-5

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

22. Load Diagrams, Figure 9-6

23. Network Before and After Resource Loading, Figure 9-7

24. Load Diagrams, Figure 9-8

25. Resource Loading Chart, Figure 9-9

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

27. MSP Gantt with Resources, Figure 9-10

28. MSP Load Diagram, Showing Resource Conflict, Figure 9-11

29. MSP Load Diagram, Leveled, Figure 9-12

30. Network for Resource Load Simulation, Figure 9-13

31. Load Chart, Figure 9-14

32. Task a Decomposed, Figure9-15

33. Hierarchy of Gantt Charts, Figure 9-16

34. Sources and Uses of Resources, Figure 9-17

35. Project Life Cycles, Figure 9-18

36. Flow Diagram for SPAR-1, Figure 9-19

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

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

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

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