Chapter 11 Project Dashboard 1
Chapter 11 Project Dashboard CSc 171/233 Fall 2013 2
Chapter 11 Project Dashboard CSc 171/233 Fall 2013 3
Chapter 11 Project Dashboard CSc 171/233 Fall 2013 4
Chapter 11 Project Dashboard CSc 171/233 Fall 2013 5
Chapter 11 Project Dashboard CSc 171/233 Fall 2013 6
Chapter 11 Project Dashboard CSc 171/233 Fall 2013 7
Dilbert Scott Adams CSc 171/233 Fall 2013 8
Chapter 11 Project Dashboard Regular measurements Quantitative Qualitative Transparency Pitfalls of assessment or misunderstandings of why you measure. 1. Too much time spent at a cost to real work 2. Gaming the perceived intent of the measuring 3. Measuring people and not the project You get what you measure! 9
Measure more than one thing Recommendations: Go back to your drivers, constraints, and floats Pick at least four Those four are the areas you are most likely to modify during the project. Measure them! You need to see what to change You need more than just the start and end dates. 10
Measuring progress towards completion What is meant by completion? the only accurate way to measure progress for a software project is to measure how many features the project team has completed. What about serial projects? 11
Features 70 Velocity Chart to check schedule progress 60 50 40 30 # Features Done # Features Left Tot Features 20 10 Manage 0 It! Your Guide to Modern, Pragmatic Project 12 Management. 29-Nov Johanna 18-Jan Rothman 9-Mar 28-Apr 17-Jun 6-Aug 25-Sep 14-Nov 3-Jan
Velocity Features per Iteration After 9 th iteration PM stops changes Iteration Contents Chart - Velocity 9 8 7 Defects Changes Features 6 5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 Iteration 13
Features CSc 171/233 Fall 2013 6 Week Velocity Chart (Fig. 11.3) 9 8 7 6 5 4 3 2 Features Left Features Done Total Features 1 0 0 1 2 3 4 5 Week 14
Figure 11.4 (Page 210) Estimated Quality Factor Track estimates versus actual completion data Area indicates error Remember Schedule estimates are just guesses showing why the schedule varies and explaining it is useful 15
Estimated End Date End of the Project line Estimated Quality Factor (Fig. 11.4) 12-Nov 2-Nov 23-Oct 13-Oct 3-Oct 23-Sep 13-Sep 3-Sep 24-Aug 14-Aug 4-Aug 25-Jul Estimated End Date 1-Jan 1-Feb 1-Mar 1-Apr 1-May 1-June 1-Jul 1-Aug 1-Sep 1-Oct 1-Nov How good were your estimates? Date of Estimate 16
Estimated End Date CSc 171/233 Fall 2013 Weekly inch-pebble assessments used to update EQF chart Tommy's Estimation Quality Factor 21-Feb 21-Feb 20-Feb 20-Feb 19-Feb 19-Feb 18-Feb 18-Feb 17-Feb 17-Feb 16-Feb 0 1 2 3 4 5 5 6 7 8 109 10 11 12 15 13 14 15 16 20 17 18 19 20 21 25 No update until halfway through project even though pieces had been completed early Week of Estimate Fig. 11-5 17
How to know what s happening? Pick a few measurements: Schedule estimates vs. actuals When people are assigned vs. when they are needed Requirements changes (after baseline is set) Fault feedback ratio (ratio of fixes that don t fix to total fixes) Cost to fix defects Defect find, close and open rates Indicators of problems but you still need to figure out why! 18
Time lost is never going to be regained With no schedule you would not know what time was lost! With no schedule when you are over budget and delivery is not near you can only imagine you lost time somewhere! With a schedule but no tangible evidence of progress, no one notices the time that is lost. 19
Time lost is never going to be regained Project start slips one month Fig 11.6 20
CSc 171/233 Fall 2013 Time lost is never going to be regained Milestone Based on Actual Start Project start slips one month Fig 11.6 21
You don t get the people when you need them. Fig. 11.8 22
Rate of Change Figure 11.9 (Page 217) Requirements Change Chart Major Reqts changed Minor Reqts changed Simple Criterion: Interface changes between modules tend to create defects Minor change effects one module Major change effects more than one module 23
Number of of Changes Requirements Change Chart (Fig. 11.9) 16 14 12 10 Minor Major 8 6 4 2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Week 24
Fault Feedback Ratio Number of Fixes that do not fix the problem Total Number of Fixes FFR 10% You are having serious problems fixing problems! NOTE. The earlier you measure FFR, the more feedback you can get 25
Defects Closed Fault Feedback Ratio & Closed Defects CSc 171/233 Fall 2013 35 60% 30 25 20 15 10 5 FFR Defects Closed 50% 40% 30% 20% 10% Fault Feedback Ratio 0 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728 0% Week Fig. 11.10 26
Cost to Fix a Defect (2 project sample - Fig. 11.10 & 11.11) Industry Standard Phase Reqts Design Code Test Post- Release Cost 1 10 100 1,000 10,000 EXAMPLE Phase Project 1 Post- Release Not measured 0.5 PD 1.-0 PD 18 PD Reqts Design Code Test Not measured Project 2 0.25 PD 0.25 PD 0.5 PD 0.5 PD 8 PD PD = Person Days 27
Some good rules The longer it takes to fix a problem the more likely that parts of the system are not understood! The longer it takes to find the problem, the less is known about the product or the less is known about how to test the product comprehensively! In either case, confidence in the product is low! 28
Look for the Knee (Page 221) Risk of release lessens Fig 11.12 29
Qualitative Data Feature Set Feature 1 Scenario 1 Scenario 2 Scenario 3 Last Test Date Status Next Planned Test Feature 2 30
Scale 0 6 6= Success! Staged Delivery Practices Chart Fig. 11.15 Peer Review 6 5 Practices chosen what is preventing Success! Develop Automated Smoke Tests 4 2 0 Builds fixed within a few hours Ask the team! Rolling-wave Planning Implement by Feature 31
Sponsors want to know! The risks and progress toward meeting release criteria Fig. 11.17 Initial Risk List Severity Risk Description Likelihood if it occurs Exposure Trigger Date Lucinda & her staff won't be 1 available for prtotype reviews High High High, High 1-May when we need them Mitigation Plan 1. Explain schedule to Lucinda 2. Keep her apprised of progress 3. Warn her 1 week in advance 2 Suipply chain thing will change entire DB design itf it occurs before Sept 1 High Medium Medium, High 1-Sep Continue to talk to Lucinda about the disruption these changes could make. Give her a date for when we can take changes. 32
Severity of Occurrence Constellation Risk List HIGH (Two) (Three MEDIUM (Four) LOW (One) LOW MEDIUM HIGH Probability of Occurrence 33
Progress Meeting Release Criteria Criterion Status Status Status Status Build 123, pass, Reliability Criterion Build 121, Build 125 but defects x, y, Build 127 pass #1: run for 13 hours fail pass z discovered All online help reviewed Build 1221, Module A reviewed Build 123, Modules B, C reviewed Build 125, Module D reviewed Build 127, All except Module G reviewed 34
Weekly Weather reports: A quick assessment! Project Schedule is on target Minor Schedule concern, but schedule can be met Schedule concern, can be met with extra effort Current Schedule or Feature Set is highly risky Schedule or Feature Set cannot be met under current conditions Cannot meet Schedule or the desired Feature Set 35