Software project management (intro) Project control

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

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

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.

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

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

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

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

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

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

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

Levels of control project board End-stage assessment event-driven 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

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’

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

Example of Timesheet

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

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

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

Graphical representation Gantt Chart 9/01 3/01 4/01 8/01 5/01 6/01 7/01 Gavin Purdy Justin Spencer Amanda

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

Graphical representation Ball Chart 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

Graphical representation Timeline A method of recording and displaying the way in which the targets have changed throughout the duration of the project

Corrective action Tolerance Contingency Exception plans 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

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

Cost Monitoring Accumulative chart -- behind schedule and over budget

Earned value analysis 1. Identify ‘modules’ 2. Identify ‘checkpoints’ 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%

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’

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

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

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) ++

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

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

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

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

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

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