Project Planning

1. Project Planning CS169 Lecture 6 Prof. Aiken CS 169 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 Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

5. Back To Reality • It’s hard, but we can’t ignore it • We still need to make plans . . . Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

7. Recommendations for Planning Prof. Aiken CS 169 Lecture 6

8. One Approach • Recommend one approach • Because I believe it is reasonably realistic • And widely practiced Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

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). Prof. Aiken CS 169 Lecture 6

13. Example Graph E Done D A I F C B H G Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

15. Example Graph 2 days E 4 days Done 3 days D 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 Prof. Aiken CS 169 Lecture 6

16. Example PERT chart for a DAJ project AS1 s2 50 Done cd 20 UCE1 V3 start V2 80 60 AS3 V1 30 UC1 AS2 AM1 10 s1 70 40 AM2 Prof. Aiken CS 169 Lecture 6

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? Prof. Aiken CS 169 Lecture 6

18. Critical Path 2 days E 4 days Done 3 days D 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 Prof. Aiken CS 169 Lecture 6

19. Resources • Each task requires resources • Particular people • Money • Perhaps special hardware, etc. • Make sure these will be available • E.g., one person isn’t expected to be doing two tasks at the same point in the schedule Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

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. Prof. Aiken CS 169 Lecture 6

22. Measuring Progress: A Key Principle Move from working system to working system Prof. Aiken CS 169 Lecture 6

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 Prof. Aiken CS 169 Lecture 6

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 don’t get to lower-priority builds late in the schedule Prof. Aiken CS 169 Lecture 6

25. Builds Build 3 Build 1 Build 2 2 days E 4 days Done 3 days D 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 Prof. Aiken CS 169 Lecture 6

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 aren’t completing lots of tasks without checking that everything works together! • Another form of false progress Prof. Aiken CS 169 Lecture 6