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
Publish initial
plan
Start
Gather project
information
Publish revised
plan
Compare
progress vs
targets
No
Take remedial
action
Satisfactory?
Yes
Yes
End project
Project
complete
d?
No
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
even more errors
Design
errors
build
errors
HELP!
test
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

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
Ensuring satisfactory
progress
project board
checkpoint reports
Day-to-day
responsibility
End-stage assessment
event-driven
Mid-stage assessment
time-driven e.g. monthly
project manager
(stage manager)
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
Gavin
Purdy
Justin
Spencer
Amanda
Graphical representation
Slip Chart
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
31/3/99
6/4/99
8/4/99
Code and test module A
Code and test module B
11/5/99
21/5/99
13/5/99
17/5/99
Encourage competitiveness between teams
Relatively easy to keep up to date
original
Actual
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

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
120
100
% complete
80
planned
60
actual
40
20
0
1
2
3
4
5
6
7
8
9
10
11
week number
-- behind schedule and over budget
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%
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%
$300
75%
ACWP
Actual Cost
BCWS
Baseline
SV
$200
$100
50%
BCWP
Earned Value
25%
10
++
CV
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