Upload
johnathan-sparks
View
226
Download
0
Embed Size (px)
Citation preview
9-1
Resource Allocation
Some definitions Resource allocation, loading,
leveling Expediting and crashing projects Goldratt’s “Critical Chain”
9-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”
9-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)
9-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 . . .”
9-5
Case: Architectural Associates, Inc.
Projects uniformly run late, thus over budget
Is that the problem, or just the symptom?
9-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
9-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
9-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-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
9-10
An Example (Table 9-1)
Activity Predecessor Days(normal, crash)
Cost(normal, crash)
a - 3, 2 $40, 80
b a 2, 1 20, 80
c a 2, 2 20, 20
d* a 4, 1 30, 120
e** b 3, 1 10, 80
* Partial crashing allowed** Partial crashing not allowed
9-11
Example (cont’d): Cost per Day to Crash (Table 9-2)
Activity $ Saved/Day
a 40
b 60
c -
d 30
e 70 (2 days)
9-12
A CPM Example, Figure 9-1
9-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
9-14
CPM Cost-Duration, Figure 9-2
9-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
9-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 . . .
9-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
9-18
Resource Usage Calendar, Figure 9-3
9-19
AOA Network, Figure 9-4
9-20
Modified PERT/CPM AOA, Figure 9-5
9-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
9-22
Load Diagrams, Figure 9-6
9-23
Network Before and After Resource Loading, Figure 9-7
9-24
Load Diagrams, Figure 9-8
9-25
Resource Loading Chart, Figure 9-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
9-27
MSP Gantt with Resources, Figure 9-10
9-28
MSP Load Diagram, Showing Resource Conflict, Figure 9-11
9-29
MSP Load Diagram, Leveled, Figure 9-12
9-30
Network for Resource Load Simulation, Figure 9-13
9-31
Load Chart, Figure 9-14
9-32
Task a Decomposed, Figure9-15
9-33
Hierarchy of Gantt Charts, Figure 9-16
9-34
Sources and Uses of Resources, Figure 9-17
9-35
Project Life Cycles, Figure 9-18
9-36
Flow Diagram for SPAR-1, Figure 9-19
9-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
9-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
9-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
9-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