Information Systems Project Management—David Olson
8-1
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-2
Chapter 8: Network Scheduling
Methods
Critical path method (CPM)
Buffers
Leveling & Smoothing
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-3
why networks?
• Gantt charts don’t explicitly show task
relationships
• don’t show impact of delays or shifting
resources well
• network models clearly show
interdependencies
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-4
Logic Diagrams
• network of relationships
research
what’s
been done
research
what needs
doing
internet
research
pick
final
topic
write
print
elements & relationships (sequence)
this is ACTIVITY-ON-NODE
can have ACTIVITY-ON-ARC
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-5
Network Diagrams
• activity duration
• milestone
milestone
activity
(duration)
• immediate predecessors
identified by arrows leading into
• durations
can include in parentheses
• dummy activities
need for AOA networks
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-6
networks
• networks make a good visual
• they are TOTALLY UNNECESSARY for
identifying
–
–
–
–
early starts
late finishes
slack
critical paths
earliest an activity can be begun
latest an activity can finish
spare time
activities with no slack
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-7
Project Scheduling
MODEL COMPONENTS
• activities
• predecessors
• durations
–
–
–
–
from WBS
what this activity waits on
how long
durations are PROBABILISTIC
CPM DETERMINISTIC
PERT considers uncertainty, but UNREALISTIC
simulation
• all assume unlimited resources
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-8
Critical Path Method
• INPUTS: activities, durations, immediate predecessors
• ALGORITHM
forward pass schedule all activities with no unscheduled predecessors
ES/EF determine early starts & early finishes (start ASAP, add duration)
backwards pass schedule in reverse (schedule all activities with no
unscheduled FOLLOWERS)
LF/LS determine late finishes, subtract duration to get late starts
slack difference between LS-ES (same as LF-EF)
critical path all chains of activities with no slack
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-9
CPM Example
FORWARD PASS
activity
A requirements analysis
B programming
C get hardware
D train users
schedule A
start
schedule B
&C
schedule D
duration
3 weeks
7 weeks
1 week
3 weeks
0
finish
3
3
10
© McGraw-Hill/Irwin 2004
predecessor
A
A
B, C
0+3 =3
3+7 =10
3+1 =4
10+3 =13
Information Systems Project Management—David Olson
8-10
CPM Example
backward pass
schedule D finish 13
schedule B
10
&C
10
schedule A
3
slack A
LF= 3
B
LF= 10
C
LF= 10
D
LF= 13
critical path: A-B-D
late start=
EF=
EF=
EF=
EF=
3
10
4
13
© McGraw-Hill/Irwin 2004
13-3
10-7
10-1
3-3
3-3
10-10
10-4
13-13
= 10
=3
=9
=0
=0
=0
=6
=0
Information Systems Project Management—David Olson
8-11
Gantt Chart
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
A
x x x
B
x x x x x x x
C
x
D
x
© McGraw-Hill/Irwin 2004
x
x
Information Systems Project Management—David Olson
8-12
CPM
• can have more than one critical path
activity
A requirements analysis
B programming
C get hardware
D train users
duration
3 weeks
7 weeks
7 weeks
3 weeks
predecessor
A
A
B, C
• critical paths A-B-D
A-C-D
both with duration of 13 weeks
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-13
Buffers
• Assure activities completed on time (Goldratt, 1997)
• Project Buffers: after final project task
• Feeding Buffers: where non-critical
activities lead into critical activities
• Resource Buffers: before resources
scheduled to work on critical activities
• Strategic Resource Buffers: assure key
resources available
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-14
Project Buffer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
A
x x x
B
xxxx x x x
C
x
D
x
© McGraw-Hill/Irwin 2004
x
x
b
b
Information Systems Project Management—David Olson
8-15
Resource Limitations
critical path crashing
(cost/time tradeoff)
other methods
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-16
Crashing
• can shorten project completion time by
adding extra resources (costs)
• start off with NORMAL TIME CPM
schedule
• get expected duration Tn, cost Cn
• Tn should be longest duration
• Cn should be most expensive in
penalties, cheapest in crash costs
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-17
Time Reduction
• to reduce activity time, pay for more
resources
• develop table of activities with times and
costs
• for each activity, usually assume linear
relationship for relationship between
cost & time
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-18
Crash Example
Activity:
programming
Tn:
7 weeks
Cn:
$14,000 (7 weeks, 2 programmers)
if you add a third programmer, done in 6 weeks
Tc:
6 weeks
Cn:
$15,000
cost slope = (15000-14000)/(6-7)=-$1000/week
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-19
Example Problem
activity
A requirements
B programming
C get hardware
D train users
Pred TnCn
Tc
none 3 can’t crash
A 7 14000 6
A 1 50000 .5
B,C 3 can’t crash
Cc
slope
max
15000 -1000 1 week
51000 -2000 .5 week
Crashing Algorithm:
1 crash only critical activities
B only choice
2 crash cheapest currently critical
B is cheapest
3 after crashing one time period, recheck critical
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-20
Crash Example
Import critical software from Australia: late penalty $500/d > 12 d
A get import license
5 days no predecessor
B ship
7 days A is predecessor
C train users
11 days no predecessor
D train on system
2 days B,C predecessors
can crash
C: $2000/day more than current for up to 3 days
B: faster boat 6 days $300 more than current
bush plane 5 days $400 more than current
commercial 3 days $500 more than current
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-21
Crash Example
Original schedule: 14 days, $1,000 in penalties
= $1000
crash B to 6 days:13 days, $500 penalties, $300 cost
= $800*
crash B to 5
C to 10:
12 days, no penalties, $400+2000 cost = $2400
to 11 days is worse
NOW A SELECTION DECISION
risk versus cost
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-22
Crashing Limitations
• assumes linear relationship between
time and cost
– not usually true (indirect costs don’t change at
same rate as direct costs)
• requires a lot of extra cost estimation
• time consuming
• ends with tradeoff decision
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-23
Resource Constraining
• CPM & PERT both assume unlimited
resources
NOT TRUE
– may have only a finite number of systems analysts,
programmers
• RESOURCE LEVELING - balance the
resource load
• RESOURCE CONSTRAINING - don’t
exceed available resources
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-24
Resource Leveling
unleveled
leveled
25
40
35
20
30
25
15
20
analysts
programmers 10
trainers
5
15
10
analysts
programmers
trainers
5
0
0
1st
Qtr
2nd
Qtr
3rd
Qtr
4th
Qtr
1st
Qtr
2nd
Qtr
3rd
Qtr
© McGraw-Hill/Irwin 2004
4th
Qtr
Information Systems Project Management—David Olson
8-25
Work Patterns
• natural resource demands tend to have
lumps
• maintaining a stable work force works
better if demand leveled
• HOW TO LEVEL: split each activity into
smaller activities, schedule them at
different times
• USUALLY NOT THAT EASY
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-26
Resource Leveling
this leveling often works for specific
activities, but complicated even more
when resources shared
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-27
Resource Leveling Methods
• split up work, stagger
• eliminate some activities (subcontract)
• substitute less resource consuming
activities (use CASE tools)
• substitute resources (hire spot work
programmers)
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-28
Resource Smoothing
• Adjust schedules to level workload
– expand duration for peak load
– compress durations where load low
• Fill in gaps of work
• Requires balancing resources
– for activities with heavier load, use multiple
crews
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-29
Resource Loading
• MUST schedule activities to not
overschedule critical resource
• If there is only one training room, and it
includes the only delivery system
– can’t speed up training
– can’t conduct two training activities at once
• LINEAR PROGRAMMING
• heuristics
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-30
Recap
• cost/time tradeoff
– time consuming, still makes assumptions
• resource leveling
– manual shuffling
• resource constraining
– pure solution to optimality a research issue
– heuristics have been applied in software
• NO IDEAL SOLUTION METHOD
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-31
Criticisms of CPM
• Rarely to activities proceed as planned
– critical path therefore very volatile
• options to speed some activities available
– crashing
• resource limits not reflected
– resource leveling
• schedule likely to be very lumpy
– resource smoothing
© McGraw-Hill/Irwin 2004
Information Systems Project Management—David Olson
8-32
Summary
• Critical path provides managers valuable
information
– What activities interfere with project completion
– Estimate of project duration
• Buffers a means to manage risk
• Crashing a means to analyze cost/time tradeoff
• Resource management
– Leveling
– smoothing
© McGraw-Hill/Irwin 2004