Poorly estimated projects

Size: px
Start display at page:

Download "Poorly estimated projects"

Transcription

1 Flow of Software Estimates on a Well-Established Project Chapter 16 Poorly estimated projects No focus on estimating size of the software Instead, focus is on estimating cost, effort and schedule Based on what? Lots of re-estimating as project schedule slips

2 Flow of Software Estimates on a Well-Established Project Chapter 16 Poorly estimated projects No focus on estimating size of the software Instead, focus is on estimating cost, effort and schedule Based on what? Lots of re-estimates as project schedule slips

3 Flow of Software Estimates on a Well-Established Project Chapter 16 Poorly estimated projects No focus on estimating size of the software Instead, focus is on estimating cost, effort and schedule Based on what? Lots of re-estimates as project schedule slips

4 Flow of Software Estimates on a Well-Established Project Chapter 16 Poorly estimated projects No focus on estimating size of the software Instead, focus is on estimating cost, effort and schedule Based on what? Lots of re-estimates as project schedule slips

5 Poorly estimated projects Inputs, the estimation approach, and outputs (the estimates) not well defined Effort at better definitions is usually focused on making the estimate smaller (to make it smaller) TIP: Don t argue over the output (the estimate) change the output only by changing the inputs

6 A well-estimated Project Adjust the inputs until to you get an acceptable outcome The approach/process should not be designed to create a specific estimate

7 Focus on estimating Size first Fig. 6.3 Flow of a single estimate on a well-estimated project. Effort, Schedule, Cost & Features are computed from a Size estimate Schedule Size Effort Cost Features

8 Fig Summary: Matching estimation techniques to the project phase Large Sequential Project Small Sequential Project Iterative Project Kind of Technique Computing Counting Historical Data from Organization Historical Data from Sam Project Decomposition Analogy Proxy-Based Estimation Complex Algorithm Automated Estimation Tool Expert Judgment Estimates by Skilled Estimators Estimates by Contributors Bottom-up, Task-Level Estimation Group Estimates/Reviews Pre-Requirements During Req'ts During Design During Construction During Initial Planning During Construction During Initial Planning During Construction

9 Large projects At the start, nothing to count Use algorithms, SW tools, etc. Refine with group reviews Estimation Flow Later stages, move to historical-based approaches & bottom-up task estimation Small projects Same approach at the start As soon as people are assigned, estimate tasks (work packages) (bottom-up)

10 Estimation refinement What to do when you slip (miss a milestone)? Options (which to choose): 1. Assume you can make up the lost time later in the schedule 2. Add the time slipped to the total schedule 3. Multiply the whole schedule by the magnitude of the slip (e.g. 50%) Most common approach: Option #1 Seldom the best choice 1991 survey: 300 projects, time is not made-up Option #2 assumes that the slip was an anomaly, the rest of project will be right on Typical slips represent systemic problems (they will happen again) Unlikely that the entire estimate is correct. With rate exceptions Option #3 is the it.

11 Single point estimate: Re-estimation When First Interim Release takes 18 months, management goes ballistic! Panic: behind schedule and over budget Estimate Point in Project (Staff Months) Initial concept 10 Approved product definition 10 Requirements complete 13 User interface design complete 14 First interim release 16 FINAL 17

12 Range estimates: Re-estimation Allows for tightening up the estimate as the project progresses Which means, narrowing the ranges Being honest about the 90% confidence level Estimate Point in Project (Staff Months) Initial concept 3-40 Approved product definition 5-20 Requirements complete 9-20 User interface design complete First interim release FINAL 17

13 When to present re-estimates (the tightening of the ranges)

14 A Well-estimated Project Dot represents the actual project outcome.

15 Poorly estimated Project Dot represents the actual project outcome.