400 likes | 943 Views
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
E N D
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
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
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 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
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
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