1. Computer Engineering 203 R Smith Project Tracking 12/2008 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?

2. 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?

3. 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.

4. 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

5. 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

6. 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.

7. 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

8. 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.

9. 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.

10. 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.

11. 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

12. 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.

13. 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.

14. 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.

15. 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

16. 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

17. 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

18. 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

19. 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?

20. 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

21. 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

22. 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.

23. 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.

24. 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

25. 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

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

27. 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.

28. 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?

29. 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.

30. 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

31. 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

32. 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.

33. 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?

34. 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

35. 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?

36. 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?

37. 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.

38. 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.

39. 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

40. 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.

41. 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?