Project Planning

1
Project Planning

• CS169
• Lecture 6

2
Example Denver Airport

• Opening delayed entirely by software bugs in
  baggage handling system
• After 9 month delay, admitted they did not know
  when the airport would open
• Delay cost 1.1M/day
• Initial development of baggage system 193M

3
Example Air Traffic Control System

• FAA contracted with IBM
• IBM blamed for poor management
• FAA blamed for altering requirements
• Four part project
• Two parts cancelled after 144M spent
• Unreliable and over budget
• Fourth part 1B over budget and 5 years late
• And still not completed

4
IBM Survey of Distributed Systems

• 55 of projects over budget
• 68 over schedule
• 88 had to be redesigned
• Note Distributed systems are harder than many
  other systems to build

5
Back To Reality

• Its hard, but we cant ignore it
• We still need to make plans . . .

6
Talent

• What about programmer productivity?
• Productivity differences of 10-1 to 100-1
• Some programmers simply much better than others
• These differences can swamp all others
• Especially in small teams

7
Recommendations for Planning
8
One Approach

• Recommend one approach
• Because I believe it is reasonably realistic
• And widely practiced

9
Planning in Four Easy Parts

• Break project into tasks
• Requires a good design with good interfaces
• Allows tasks to be correctly enumerated
• Allows places for parallel development to be
  identified
• Again, interfaces have to be right or unexpected
  dependencies will be discovered later!
• Realism in estimating task length
• Observable completion
• Tasks are clearly done or not done
• Prioritization

10
Plan from Design

• Start with the design
• Break project into tasks
• Indivisible units of work for one person
• Rules of thumb
• Nothing less than a day is a task
• Anything more than a week is at least two tasks
• Longer tasks harder to estimate
• Need to think about how to break it into logical
  pieces

11
Dependency Graph

• Write down dependencies for each task
• What tasks already must have been done?
• Build a dependency graph
• Nodes are tasks This is not right, see next
  viewgraph
• Edge (A,B) if A must be completed before B

12
PERT chart (Program Evaluation and Review
Technique)

• Nodes Milestones Events
• Edges Tasks Activities Jobs
• Edge weight Task duration
• If edge (u,v) enters vertex v and edge (v,x)
  leaves v, then task (u,v) must be performed prior
  to task (v,x).

13
Example Graph
E
Done
D
A
I
F
C
B
H
G
14
Estimating Time

• Assign tasks to people
• Individuals estimate time for their own tasks
• They know their own abilities best
• Genuine commitment to their own promises

15
Example Graph
2 days
E
4 days
Done
D
3 days
1 day
4 days
A
I
F
2 days
1 day
C
2 days
3 days
5 days
B
5 days
H
G
2 days
16
Example PERT chart for a DAJ project
AS1
50
s2
Done
20
cd
UCE1
V3
start
V2
80
60
AS3
V1
30
UC1
AS2
AM1
10
s1
70
40
AM2
17
Notes

• Durations go on the edges, not the nodes
• Some dependencies may be satisfied before a task
  is complete
• Dummy Done node
• Shows when everything is completed
• Graph is useful for analysis
• E.g., what is the critical path?

18
Critical Path
2 days
E
4 days
Done
D
3 days
1 day
4 days
A
I
F
2 days
1 day
C
2 days
3 days
5 days
B
5 days
H
G
2 days
19 days
19
Resources

• Each task requires resources
• Particular people
• Money
• Perhaps special hardware, etc.
• Make sure these will be available
• E.g., one person isnt expected to be doing two
  tasks at the same point in the schedule

20
Fudge Factor

• Scale estimated time by a fudge factor
• Allows for the inevitable unexpected problems
• I take the time estimated to complete all the
  tasks and double it.
• - Silicon Valley VPE

21
Measuring Progress

• Checking off tasks gives illusion of progress
• Real progress only if task completion is
  observable
• Bad
• Task 1 10 of feature, task 2 20 of feature
• What does 10 mean?!
• Good
• Task 1 All menus implemented and respond
  correctly to mouse clicks.

22
Measuring Progress A Key Principle

• Move from working system to working system

23
Make the Plan a Sequence of Builds

• Get the first build up as soon as possible
• After that, always maintain a working system
• System grows as tasks are checked off
• Move from build to build

24
Why?

• Can observe true progress
• If nothing runs, hard to know if we are close to
  running
• Makes changes in plan easier
• Each build provides a natural point for changes
• Allows priorities
• Put most critical features in first build
• If schedule slips, just dont get to
  lower-priority builds late in the schedule

25
Builds
Build 3
Build 1
Build 2
2 days
E
4 days
Done
D
3 days
1 day
4 days
A
I
F
2 days
1 day
C
2 days
3 days
5 days
B
5 days
H
G
2 days
19 days
26
Summary

• Tasks are unit of work
• But tasks need to make sense
• Realistic duration, know when they are done
• Group tasks into builds
• Guarantees we arent completing lots of tasks
  without checking that everything works together!
• Another form of false progress