ertyuytrewertyuiuytrewertyu

1. Software Project Management
Lecture 13
1

2. Software Project Controlling
Software Project Controlling is the process of
monitoring, measuring and guiding a software project
to ensure it stays on track in terms of time, scope and
quality.
Key aspect included:
• Schedule Control
• Cost/Budget Control
• Quality
• Risk monitoring
• Performance Tracking

3. Project Management Processes
Initiating
Processes
Planning
Processes
Controllin
g
Processes
Executing
Processes
Closing
Processes
Source: A Guide to the Project Management Body of Knowledge, PMI,
1996
3

4. Project Control
• The Project Plan is just a
roadmap
• The Project Manager must
drive the project to
Initiating
Processes
Planning
Processes
Project
Management
Plan
Task 3 Task 3
1.1.3 1.2.3
Milestone A
1.
0
Task 2 Task 2 Task 2 Task 2 Task 2
1.1.2 1.2.2 2.1.2 2.2.2 3.1.2
T
ask 3 Task 3
2.2.3 3.1.3
T
ask 4
2.2.4
Activity A1 Activity A2 Activity B1 Activity B2 Activity C1
1.1 1.2 2.1 2.2 3.
1
Task 1 Task 1 Task 1 Task 1 Task 1
1.1.1 1.2.1 2.1.1 2.2.1 3.1.1
Milestone B Milestone C
2.
0 3.
0
Main Goal
completion, making
corrections and
adjustments where
necessary
• Main Purpose: to steer the
project’s execution
Controllin
g
Processes
Executing
Processes
Closing
Processes
4

5. The project control life-cycle
the real
world
Data
Collectio
n
Dat
a
Processin
g
decisio
n
makin
g
implemen
t- ation
modelin
g
define
objective
s
action
s
information
decision
s
dat
a
objective
s
5

6. What needs controlling?
• Technical integrity
– What tasks have been completed?
• 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
• 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
6

7. Project Control
• Try to keep the shape!
Quality of Performance
Cost of Resources
Time Parameters
Quality
Cheap
Cost
7

8. The bug chain
error
s
Requirement
s
gathering
erro
rs
error
s
Design
errors
build
more errors
even more errors
HELP!
test
8

9. Levels of
control
project
board
checkpoint
reports
End-stage assessment
event-driven
Mid-stage assessment
time-driven e.g.
monthly
project
manager
(stage
manager)
chec
kpoin
t
meeti
ngs
e.g.
weekl
y
9

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

11. Project information
• Collecting
– checkpoint meetings
– time sheets
– machine generated statistics e.g. connect time
– configuration management data
– internal documents e.g. error reports
• Presenting
– avoid ‘information overload’
– focus on real problems - exceptions to planned activity
11

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

13. Graphical representation
SA
SD1
SD2
CDR1
CDR2
‘Slip-chart’ red-line indicates position as of
today
A very uneven line suggests need for
rescheduling 13

14. Why Is It Necessary ToTrack Status?
• To Mitigate Schedule & Budget Shortfalls Caused by
Unpredicted Changes
• If our plans were perfect and if conditions never changed,
we would not need to track project status.
• We Track Actual Versus Planned:
– Expenditures, Tasks (Development / Testing progress), Milestones,
Software Estimates, Defects, Productivity, Requirements, Progress
(w.r.t. Milestones),
Risks, Other Resources
– Current Plans: Must Be Updated Periodically & as Warranted
– Actuals Must Be Accurate: Must Collect & Validate Project Data
– Standard Reporting: Everyone Understands the Mechanisms Used
– Corrective Action: As Required to Bring Actuals Into Conformance
14

15. How Can We Obtain
The Necessary
Information?
• Change Control: #, Rate & Criticality of Problems & Change
Requests
• Baseline Tracking: # Modules Designed, Coded, Tested,
Integrated
• Action Item Tracking: Working Groups, Boards
• Progress Reviews: Action Items, Follow-ups
• Work Package Tracking: #Open, #Completed,
Trends
• In-process Peer Reviews: Problems, Trends
• Incremental Demonstrations: Progress, Quality,
Performance
• Quality Assurance: Audits, Reviews, Non-conformances
15

16. When can Status & Progress
be Reported?
• Major & Minor Milestones:
– Lifecycle Phases
– End of Planned Iterations and Increments
– At Project Baselines
– Delivery of Major Reports, Demonstrations,
Releases, …
• Periodic Work Group & Team Meetings
• When Required by the Customer or Senior
Management
16

17. # Staff
Total
Staff
planned
actuals
40
50
Experienced
Staff
Months
10
20
30
17

18. 500
300
# Defects
400
30
40
50
Defects / KLOC
200
100
0
Open # of Defects
Time
10
20
Planned
Release
Date
Actual
Release
Date
18
Note: Defect also called Software Problem or Trouble Report

19. Action Item Tracking
• Each action item should include the following
information:
– description of the problem
– action to be taken
– responsible party
– completion criteria
– response date
• Action items must be recorded, reviewed
periodically, and tracked to closure, in the same way
that Change Proposal and Software Problem Report
are tracked
• They should also be allocated to their associated
tasks to account for actual effort and schedules 19

20. Binary Tracking of Work
Packages
• Binary tracking requires that progress on a work
package be counted as:
– 0% complete until the associated work products pass their
completion criteria
– 100% complete when the work products pass their
completion criteria
• Some organizations count work in progress at 50%
completed
• Binary tracking of work packages, with objective
completion criteria for the work products prevents the
90% completion syndrome
20

21. Binary Tracking of
Work Packages
Input Process
3.
Coding
3.1 3.2
41.5%complete
Only Competed
Packages are
Counted
(3.1.1 & 3.2.1)
This example assumes work packages 3.1 and 3.2 are of equal
size
Module Module
3.1.1 3.2.1 3.2.2 3.2.3
3.1.2
Get
Input
100
%
Edit
Data
0%
50% 33%
Check
Input
0%
Format
Data
100%
Process
Data
0%
21

22. Team Leaders Do The Detailed
Planning and Tracking
Team
Leader #1
Team
Leader#2
Team
Leader #3
V&V CM
Project Manager
Chief Architect
. . .
Member Member Member Member
Each team is in the range of 3 to 5 members plus the team leader.
Team leaders are first-level agents for schedule progress and quality control.
. . .
22

23. Progress Measurement
• ACTIVITY
• Arch. Design:
• Detailed Design:
• Code & Unit Test:
• Integration Test:
• Acceptance Test:
MEASURE OF PROGRESS
% of req’ts documented in design baseline
% of modules thru detailed design review
% of modules released to integration
% of modules integrated
% of requirements tested
(Assuming requirements have been
baselined)
• Ex: % Effort per Activity
• Architectural Design: 17 %
• Detailed Design:
26 %
• Code & Unit Test:
35 %
• Integration Test:
10 %
• Acceptance Test:
12 %
Based on
Historical or
Industry Data
23

24. Control:
• red not on plan:
recoverable only with
difficulty
• amber not on plan:
recoverable
• green on schedule
24

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

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

27. Q&A
27