Project planning
Download
1 / 26

Project Planning - PowerPoint PPT Presentation


  • 237 Views
  • Uploaded on

Project Planning. CS169 Lecture 6. 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Project Planning' - beau-malone


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Project planning

Project Planning

CS169

Lecture 6

Prof. Aiken CS 169 Lecture 6


Example denver airport
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


Example air traffic control system
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


Ibm survey of distributed systems
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


Back to reality
Back To Reality

  • It’s hard, but we can’t ignore it

  • We still need to make plans . . .

Prof. Aiken CS 169 Lecture 6


Talent
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


Recommendations for planning

Recommendations for Planning

Prof. Aiken CS 169 Lecture 6


One approach
One Approach

  • Recommend one approach

    • Because I believe it is reasonably realistic

    • And widely practiced

Prof. Aiken CS 169 Lecture 6


Planning in four easy parts
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


Plan from design
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


Dependency graph
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


Pert chart program evaluation and review technique
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


Example graph
Example Graph

E

Done

D

A

I

F

C

B

H

G

Prof. Aiken CS 169 Lecture 6


Estimating time
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


Example graph1
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


Example pert chart for a daj project
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


Notes
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


Critical path
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


Resources
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


Fudge factor
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


Measuring progress
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


Measuring progress a key principle
Measuring Progress: A Key Principle

Move from working system to working system

Prof. Aiken CS 169 Lecture 6


Make the plan a sequence of builds
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


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


Builds
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


Summary
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


ad