1 / 40

Resource Allocation

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

mercer
Download Presentation

Resource Allocation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related