Software project management (intro)

1. Software project management (intro) Project control

2. Introduction • How information about project progress is gathered and what actions must be taken to ensure a project meets its target • How can we deal with changes in requirements

3. Introduction (2) • If there is a mismatch between the planned outcomes and the actual ones • Re-planning to bring the project back on target • The target will have to be revised • Departures from the plan • Delays in meeting the target dates • Shortfall in quality • Inadequate functionality • Costs going over target

4. Project control - overview • The project control life-cycle • What’s going on? Collecting control information • Excuses, excuses… Reporting upwards • Doing something about it. Corrective action.

5. The project control life-cycle Publish initial plan Start Gather project information Publish revised plan Compare progress vs targets Satisfactory? No Take remedial action Yes Yes Project completed? No End project

6. What needs controlling 1. Technical integrity What tasks have been completed? 2. Business integrity of project Costs of project must be less than benefits Delays in implementation reduce benefits Project may be on time but only because more resources have been used than were originally budgeted Conversely, project may be late because planned resources have not been used

7. What needs controlling (2) 3. Quality • a task has not really been finished unless the product of that task is satisfactory • activity reported as finished could need to be re-worked • testing is difficult to control: depends on an unknown number of errors

8. The bug chain errors Requirements gathering more errors Design errors even more errors errors build HELP! test errors

9. Some problems with controlling projects • 99% completion syndrome • job reported as ‘on time’ until last scheduled week • job reported as ‘99% complete’ for each remaining week until task is completed • Solution? • control on deliverables

10. Further problem • Scope creep • tendency for system to increase in size during development • Solution? • re-estimating • change control

11. tasks completed staffing scope (more requirements) external dependencies cost of quality finance risk analysis can identify sensitive factors that need monitoring Progress check list

12. Levels of control project board Ensuring satisfactory progress End-stage assessment event-driven checkpoint reports Mid-stage assessment time-driven e.g. monthly project manager (stage manager) Day-to-day responsibility checkpoint meetings e.g. weekly project team

13. Levels of control control information decision-making reporting on actions • As information goes to higher levels it becomes more summarised • General directives are filled in with operational details as they filter down • Danger of ‘information overload’

14. Collecting project information • Sources • checkpoint meetings • time sheets • machine generated statistics e.g. connect time • configuration management data • internal documents e.g. error reports

15. Example of Timesheet

16. Risk Reporting:Red, amber, green • red not on plan: recoverable only with difficulty • amber not on plan: recoverable • green on schedule

17. Presentation • avoid ‘information overload’ • focus on real problems - exceptions to planned activity • some approaches • graphical representation • Gantt Chart • Slip Chart • Ball Chart • Timeline • high-light problem cases

18. Progress report content • Achievements in reporting period • Tasks that should have been finished • Tasks that should have been started • Costs - actual costs compare to budgeted • Staffing - joiners, leavers, sickness etc. • Risk monitoring - status of identified risks • Outlook • how things are likely to progress in next period

19. Graphical representationGantt Chart 9/01 4/01 3/01 8/01 7/01 5/01 6/01 Gavin Purdy Justin Spencer Amanda

20. Graphical representationSlip Chart 9/01 4/01 3/01 8/01 7/01 5/01 6/01 Gavin Purdy Justin Spencer Amanda ‘Slip-chart’ red-line indicates position as of today A very uneven line suggests need for rescheduling

21. Graphical representationBall Chart 31/3/99 31/3/99 11/5/99 21/5/99 Code and test module A original Actual 6/4/99 8/4/99 13/5/99 17/5/99 Code and test module B Encourage competitiveness between teams Relatively easy to keep up to date

22. Graphical representationTimeline • A method of recording and displaying the way in which the targets have changed throughout the duration of the project

23. Corrective action • Tolerance • acceptable margins of overshoot may be specified in plan • Contingency • this is not owned by the activity but by the project: give and take between activities • Exception plans • drawn up when the original plan needs major change: especially change to scope or costs • requires project board authority

24. Some possible actions to recover project • Re-schedule • make more resources available • redefine scope • modify quality requirements • enhance productivity e.g. through training, tools

25. Cost MonitoringAccumulative chart -- behind schedule and over budget

26. Earned value analysis 1. Identify ‘modules’ good if users can recognize these 2. Identify ‘checkpoints’ when a phase finishes - should be specific and measurable 3. Identify %durations e.g. design 30% code 25% test 45%

27. Earned value analysis -continued 4. Estimate size/effort for each module 5. When phase is completed for a module that percentage of the project has been ‘earned’

28. EARNED VALUE ANALYSIS (EVA) Using only actual and planned costs can mislead management and customers • Eg. A project has duration of 10 month & a cost of $200,000/month (total cost = $2 million) • For the first 5 months, actual cost is $1,3 million • Is there a cost overrun of $300,000? • Or, is it ahead of schedule? • For the first 5 months, actual cost is $0.8 million • Is the cost less than expected by $200,000? • Or, is it behind schedule? Need to keep track schedules and budgets against time ++

29. Example $400 100% $340 85% ACWP Actual Cost $300 75% BCWS Baseline SV CV $200 50% BCWP Earned Value $100 25% 40 50 20 10 30 duration ++

30. Interpretation of Graph • At the end of period 25, 75% of work was scheduled to be accomplished (BSWS) • At the end of period 25, the value of the work accomplished is 50% (BCWP) • At the end of period 25, the actual cost is $340 or 85%(ACWP) • Cost Variance shows that the project is over budget by $140 ($200 - $340) • Schedule Variance suggests that the project is behind schedule ($200 - $300 = -$100) ++

31. EVA indicators - cost • BCWP Budgeted cost of work performed • ACWP Actual cost of work performed • i.e. what it actually cost to get BCWP • Cost variance BCWP - ACWP • Example (using time) • work should have taken 20 days • work actually took 30 days

32. EVA indicators - schedule performance • BCWS Budgeted cost of work scheduled: BCWP that would be achieved if all work had been finished on time • Schedule variance BCWP - BCWS • Example • three tasks each planned to take 10 days should have been completed: only two have

33. EVA performance indices • Cost performance indicator (CPI) • BCWP/ACWP • Schedule performance indicator (SPI) • BCWP/BCWS • less than 1.00 is not good!

34. Prioritizing Monitoring • Critical path activities • Activities with no free float • Activities with less than a specified float • High risk activities • Activities using critical resources

35. Getting the project back to target • Shorten the critical path • Staff to work harder • Increase resource level • Allocate more efficient resource on the critical activities • Reconsider the precedence requirements • Subdivide activity • Reconsider: quality, risk

36. Change Control • Request from user • The user management consider the request • Assess the products that would be affected • The development management decide – whether to go ahead • Developers are authorized to take copies of the master product • The copies are modified • The user management is notified • When user is satisfied, the master copies will be replaced