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

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 errors Design
even more errors
errors
build
test
HELP!
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 Solution?
tendency for system to increase in size during development
Solution?
re-estimating
change control

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

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

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 representation Gantt Chart
9/01
3/01
4/01
8/01
5/01
6/01
7/01
Gavin
Purdy
Justin
Spencer
Amanda

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

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

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

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

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 Monitoring Accumulative chart
-- behind schedule and over budget

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

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 BaselineSV CV
$200
50%
BCWP
Earned Value
$100
25% 10 20 30 40 50
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