Project Tracking

1. Project Tracking • Why do we want to track a project? • What is the projects MOV? • Why is tracking important to management? • What is the MPV in project tracking for developers? • What can an individual developer gain form project tracking? • What do we track? • If we are not on track what can be done? • What is the best method to communicate the data? Computer Engineering 203 R Smith Project Tracking 12/2008

2. Why do we want to track a project? • Initially a project plan was developed, which is a road map for the project and instructions. • Tracking is the periodic checking of where we are on that road map. • Why create a road map if we do not intend to follow it or care if we are on track? Computer Engineering 203 R Smith Project Tracking 12/2008

3. Why do we want to track a project? • Tracking gives us the opportunity to make corrections if we are off-plan. • Tracking provides a check on the quality of our planning process. • Tracking allows us to see if our basic assumptions were correct. Computer Engineering 203 R Smith Project Tracking 12/2008

4. What is the MOV? • What is the measurable value to the organization to project tracking? • Why is it important to management? • Coordination with other departments • Commitments and dependencies • Forecasting revenue • Management goals • Customer expectations Computer Engineering 203 R Smith Project Tracking 12/2008

5. What is the MPV? • What personal value is there in project tracking: • Less schedule pressure • More resources • Making management aware of problems while there is still time to correct problems • Provides a wider audience for exploring possible solutions Computer Engineering 203 R Smith Project Tracking 12/2008

6. What Is the MPV? • Project tracking involves tasks that developers do not like to do or do poorly. • Telling developers that what they are doing is for the good of the organization is not very effective motivation. • Developer motivation needs to come from an understanding of what personal value is derived from providing tracking data. Computer Engineering 203 R Smith Project Tracking 12/2008

7. What do we track? • The role of metrics • Things we can track: • Estimated size versus actual size • Predicted work completed versus actual work completed • Planned dates versus actual dates • Expected resources versus actual resources • New or changed requirements Computer Engineering 203 R Smith Project Tracking 12/2008

8. What do we track? • Any project can be off the expected plan for multiple reasons. • Each reason may require a different solution and often the wrong solution will only make the problem worse. • Metrics help provide information on what the specific problem is. Computer Engineering 203 R Smith Project Tracking 12/2008

9. Estimated Size • The Software Development plan should contain estimates by size of each of the work products. • Tracking the actual size lets us know if the estimates for future work products will be accurate or not. • Actual size numbers can be accumulated outside the normal development process. Computer Engineering 203 R Smith Project Tracking 12/2008

10. Predicted work completed versus actual work completed • When the project is estimated and scheduled a production rate is assumed. Tracking expected work completed per resources expended gives us a check on how valid the assumed production rate is. • Other estimates based on the same production rate should be called into question. Computer Engineering 203 R Smith Project Tracking 12/2008

11. Production Rates • Things that can effect production rates: • Work more complex than expected • Developer learning curve • Actual versus expected tool performance • More complex logistics or communications than expected • Over optimism for a new process Computer Engineering 203 R Smith Project Tracking 12/2008

12. Changes to production rates • In general changing tools or process in the middle of a project will not help the production rate. • If the project is long enough it is possible to overcome the learning curve. Computer Engineering 203 R Smith Project Tracking 12/2008

13. Planned versus actual dates • Are dependencies being met? • Expecting dates to improve without taking action. Computer Engineering 203 R Smith Project Tracking 12/2008

14. Planned versus actual resources • Our size estimates, production rates and dependencies can be right on plan and we still are missing dates, why? • Our estimates are correct yet the developers just are not spending hours expected on the project. • Failure to hire or high turnover rate • Priority conflicts • Unscheduled vacations, sick time, or company shut downs. Computer Engineering 203 R Smith Project Tracking 12/2008

15. New or Changed Requirements • Tracking how and when requirements change can predict further changes in the project. • This can reflect on the requirements gathering process. • Introduction of better control methods. • Did we select the correct development model? • A model that facilitates change Computer Engineering 203 R Smith Project Tracking 12/2008

16. Other things to track • If a project has significant costs other than direct labor then those costs should be tracked. • You should be looking at both price and quantity Computer Engineering 203 R Smith Project Tracking 12/2008

17. What Data is Required for Project Tracking • Estimates • Actual Size • Defects • Change Requests • Actual Resources Expended Computer Engineering 203 R Smith Project Tracking 12/2008

18. Time Cards • For most of these measures actual developer time must be accurately tracked. • How many hours spent even if over 40 or less than expected. • All time needs to be accounted for. • Questions • Recording frequency and increments • Quality checks Computer Engineering 203 R Smith Project Tracking 12/2008

19. Now that we know where we are what can we do about it? • The four dimensions of control: • Resources • Time • Function • Quality • If nothing changes can we expect any different results? Computer Engineering 203 R Smith Project Tracking 12/2008

20. Resources • Adding more resources generally does not help, why? • Training time • Added integration and communications costs • Integration into the team • Adding the right resources does help • Experience or special skills Computer Engineering 203 R Smith Project Tracking 12/2008

21. Time • Most projects do not have the option to add more time. • If you can add time make sure you add enough time. • Estimated sizes • Actual resources • Changing requirements Computer Engineering 203 R Smith Project Tracking 12/2008

22. Function • Reduce function if possible • Works best when functions are implemented in priority order • Establish better control over changing requirements. Computer Engineering 203 R Smith Project Tracking 12/2008

23. Quality • Quality is always an easy target. • It comes at the end of the development cycle • Less objective measures are used • Is there a bottom line to quality? • Does reduction in quality just postpone work until after release when it is more expensive. Computer Engineering 203 R Smith Project Tracking 12/2008

24. What else can be done? • Many times removing road blocks is the most effective way to get a project back on track. • Common road blocks • Communication issues • Minimum hardware resources • Training • Priorities Computer Engineering 203 R Smith Project Tracking 12/2008

25. How can we communicate the data? • Before deciding how to communicate your tracking data you need to decide on your objective. • Are you conveying information and with no expected action needed? • Do you want action if so what and when? • Be prepared to say what you want by when. • Lay the ground work so there are no surprises Computer Engineering 203 R Smith Project Tracking 12/2008

26. Metrics • What are project metrics? • Data/facts • Metrics are measured • Metrics are objectives • Examples Computer Engineering 203 R Smith Project Tracking 12/2008

27. Metrics • Metrics are important because they give management an objective way to look at progress, quality and performance • Metrics must provide solid data without subjective input such as • The code is 80% done • There are very few institutional-standard software metrics, metrics need to be team and project based. Computer Engineering 203 R Smith Project Tracking 12/2008

28. Metrics • The importance of meaningful data GQM • Goal, Question, Metrics • Goals: what are we trying to determine? • Questions: what data pertains to this goal? • Metrics: How can we measure it? • Is the data useful? Computer Engineering 203 R Smith Project Tracking 12/2008

29. Metrics • It is important to remember that our goal is to use the data we get through metrics gathering to make a decision. • If the data does not lead to making a decision either now or later then why are we collecting data. • Most resistance to collecting data comes from a lack of understanding of how the data will be used or the belief that the data will not be used. Computer Engineering 203 R Smith Project Tracking 12/2008

30. Other basic Metrics Concepts • Reliability • Is the data repeatable • Validity • Criteria for Causality • Is there a logical reason to expect that the action can actually cause the results. • Which league wins the Superbowl predicts the stock market Computer Engineering 203 R Smith Project Tracking 12/2008

31. Common uses of Metrics • Tracking progress • Use of resources • Schedule • Size • Defects • Density • Arrival rate • By project phase • Process Improvement Computer Engineering 203 R Smith Project Tracking 12/2008

32. Tracking Progress • Are the resources we planned for available? • Are we using more resources than we planned? • Looking at actual hours not just days or weeks. Computer Engineering 203 R Smith Project Tracking 12/2008

33. Tracking Progress • Are milestones being completed as planned? • Are milestones really being completed or do we expend resources even after the milestone is marked completed? • Are milestones objective and binary? Computer Engineering 203 R Smith Project Tracking 12/2008

34. Tracking Progress • How does actual size compare to estimated size? • What is our actual production rate compared to our historical production rate? • Is our measure of size a true reflection of the resources being used? • Criteria of Causality Computer Engineering 203 R Smith Project Tracking 12/2008

35. Tracking Progress • Typical problems • Size Estimate incorrect • Production Rate incorrect • Resources expected not available • Dependent milestones not fully met • Each of these problems would appear as a schedule slip, but the corrective action for each is different. • What would be examples of corrective action? Computer Engineering 203 R Smith Project Tracking 12/2008

36. Defect Tracking • What can we do with the defect tracking information? • Defect density points to code that needs to be reviewed, recoded or designed. • Predict customer experience. • Metrics of early phases can indicate corrective actions needed in later phases. • Is testing as good as expected? Computer Engineering 203 R Smith Project Tracking 12/2008

37. Defect Tracking • Defect Density • By code module, feature or function • Determine where resources should be focused to achieve the greatest results. • Provides insight as where problems are occurring. Computer Engineering 203 R Smith Project Tracking 12/2008

38. Defect Tracking • Arrival rate • Are we discovering problems at an unexpected rate? • Results should be normalized over hours of testing • Determine the trend line of the arrival rate • A declining rate indicates product is stabilizing • A raising rate indicates an unstable product • Defect fix rate, are more being found faster than being fixed. • By phase allows us to look at the success of our development process. Computer Engineering 203 R Smith Project Tracking 12/2008

39. Defect Tracking • By project phase • When was the problem created and when was it discovered? • Does the quality plan discover problems early enough • Helps determine if development processes can be improved Computer Engineering 203 R Smith Project Tracking 12/2008

40. Process Improvement • Process improvement drives most metrics programs yet the improvement process is rarely the focus of study itself. • It is important to understand if the changes being introduced in the name of process improvement actually do produce changes not just additional work. Computer Engineering 203 R Smith Project Tracking 12/2008

41. Process Improvement • Do we have a baseline? • How good are our estimates? • How good is our quality? • How do the changes we make in the process effect our progress and quality? • What is the value of our changes compared to the cost? Computer Engineering 203 R Smith Project Tracking 12/2008