UNIT - III

Project Monitoring and Control

 Dimensions of Project Monitoring &
Control

Software Project:
Project is a planned, non-routine activity, designed and
implemented to achieve a predefined objective in a given
time span.
Monitoring – collecting, recording, and reporting
information concerning project performance
that project manger and others wish to know.
 Project control
Controlling –
-Uses data from monitor activity to bring actual
performance to planned performance.

Software = Program + Operating Procedures

+ Documentation Manuals
 Project Control Cycle

PLAN
Specifications
ACTION Project Schedule
Correct Project budget
deviations Resource plan
MONITOR
from plan Vendor contracts
Record status
RE-PLAN as Report progress
necessary Report cost
COMPARE
Actual status
against plan
-Schedule
-Cost

4
 Techniques for monitoring and
control

Earned Value Analysis

Critical Ratio
Earned Value
Analysis
 Earn Value Analysis
A way of measuring overall performance (not
individual task) is using an aggregate performance
measure - Earned Value
Earned value of work performed (value completed) for
those tasks in progress found by multiplying the
estimated percent physical completion of work for
each task by the planned cost for those tasks.
The result is amount that should be spent on the task
so far.
This can be compared with actual amount spent.
 Earn Value Analysis
Methods for estimating percent completion-
The 50-50 estimate. 50% is assumed when task is begun,
and remaining 50% when work completed.
0-100% rule. This rule allows no credit for work until task
is complete, highly conservative rule, project always seem
late until the very end of project when everything appears to
suddenly catch up
Critical input rule. This rule assigns progress according to
amount of critical input that has been used. Labor or skilled
dependent, machine critical input – buy machine complete
task – may be misinformation
Proportional rule. This rule divides planned (or actual)
time-to-date by total scheduled time(or budgeted (or actual
) cost-to-date by total budgeted cast] to calculate percent
complete. This is commonly used rule.
 Earned Value Analysis

What is Earned Value Management

(EVM)?
• A method of integrating scope, schedule, and
resources, and for measuring project performance.
• It compares the amount of work that was planned
with what was actually earned with what was actually
spent to determine if cost and schedule performance
are as planned.
 Earned Value Analysis

What is needed for EVM?

• A baseline plan
• A project budget
• (BAC – Budget at Completion)
• A project end date
• Tasks are identified & scheduled
• Each task has a budget or effort
• (resource loaded / weighting)
• Actuals tracked
 Earned Value Analysis

To Perform EVM, three values need to

be determined
• Planned Value (PV or BCWS)
• Actual Costs (AC or ACWP)
• Earned Value (EV or BCWP)
 Earned Value Management

Planned Value (PV)

“What are the budgeted costs of
the work scheduled”?
•Time phased based on baseline budget.

•Only changes when baseline is changed.

•Also referred as “BCWS” & “BAC”.

 Earned Value Management

Actual Costs (AC)

“What are the actual costs of the
work performed”?
•Based on the actual completion of
work packages.
•Actual costs for reported work.
•Also referred as “ACWP”.
 Earned Value Management

Earned Value (EV)

“What are the budgeted costs of
the work performed”?
•Based on the actual completion of
work packages
•Baseline value of the reported work
•Also referred as “BCWP”
 Terms in EV Analysis
EAC: Independent Estimate at Completion
AC : Actual Cost
PF: Performance Factor
BAC: Budget at Completion
EV: Earned Value
CPI: Cost Performance Index
[CPI = EV / AC]
SPI: Schedule Performance Index
[SPI = EV / PV]
CPIx = Value of CPI for last x periods
 Formulae in EV Analysis
CV=[EV-AC]
When memorizing the
SV=[EV-PV]
formulas I have found
CPI=[EV/AC] it best to look for
patterns. When I see
SPI=[EV/PV]
the correct pattern I
EAC=[BAC/CPI] know the formula is
correct.
ETC=[EAC-AC]
AC = ACWP
VAC=[BAC-EAC] PV = BCWS
EV = BCWP
 Earned Value Management Example

Task – Drill & install 10 piezometers

• Budget - $100,000 ($10K per piezometer)
• Time – 10 weeks (1 piezometer per week)
Progress Report At week 5:
• 4 piezometers drilled and installed
• $47,500 spent to date

PV = $50,000
AC = $47,500
EV = $40,000
 Earned Value Management

Calculating Earned Value and

interpreting results
• to measure the progress of the project
• help identify trends
• forecast costs
• and identify ways to correct/mitigate
project pitfalls.
 Earned Value Management

Cost Variance (CV)

CV = EV - AC

•Good News: If CV value is positive, the project is

currently under budget (spending less than
planned for the work)
•Bad News: If CV value is negative, the project is
currently over budget (spending more than
planned for the work)
 Earned Value Management

Cost Performance Index

(CPI)
CPI = EV / AC
•Good News: If CPI value is >1 or =1, the project
cost trend is currently under or at planned budget
•Bad News: If CPI value <1, the project cost trend
is currently over budget
 Earned Value Management

Cost Variance % (CV%)

CV% = CV / EV

•Good News: If CV% value is positive, the project

is currently under budget by the CV%
•Bad News: If CV% value is negative, the project
is currently over budget by the CV%
 Earned Value Management

Schedule Variance (SV)

SV = EV - PV

•Good News*: If SV value is positive, the project is

currently ahead of schedule
•Bad News: If SV value is negative, the project is
currently behind schedule

* - not all positive SVs are good

 Earned Value Management

Schedule Performance
Index (SPI)
SPI = EV / PV
•Good News: If SPI value is >1 or =1, the project
schedule trend is currently ahead or on planned
schedule
•Bad News: If SPI value <1, the project schedule
trend is currently behind schedule
 Earned Value Management

Schedule Variance % (SV%)

SV% = SV / PV

•Good News: If SV value is positive, the project is

currently ahead of schedule
•Bad News: If SV value is negative, the project is
currently behind schedule
 Earned Value Management

Estimate at Completion
(EAC)
#1
Actual costs to date plus a new estimate for all
remaining work (original plan no longer valid)

EAC = AC + ETC
(ETC  Estimate to Complete)
 Earned Value Management

Estimate at Completion
(EAC)
#2
Actual costs to date plus remaining budget
(current variances are viewed as atypical of future
variances)

EAC = AC + BAC - EV
 Earned Value Management

Estimate at Completion
(EAC)
#3 & #4
Actual costs to date plus remaining budget
modified by a performance factor (CPI) (current
variances are viewed as typical of future
variances).

EAC = AC + [(BAC - EV) / CPI]

EAC = BAC / CPI
Earned Value Scenario
Earned Value Scenario
Earned Value Scenario
Earned Value Scenario
 Earned Value Scenario

BAC = $100,000 (current project budget)

EV = $42,000 (42% of project completed,
$100,000 planned)
PV = $56,000 (56% of project planned $100,000
completed – initial aging report)
AC = $48,000 (from actual expenditures
reporting)

Is this project on schedule / budget?

Or is it in trouble?
 Earned Value Scenario
Cost Variance (CV):
CV = EV – AC
= $42,000 - $48,000
= - $6,000

Cost Performance Index (CPI):

CPI = EV / AC
= $42,000 / $48,000
= 0.875

Cost Variance % (CV%):

CV% = CV / EV
= - $6,000 / $42,000
= 14% OVER BUDGET
 Earned Value Scenario
Schedule Variance (SV):
SV = EV – PV
= $42,000 - $56,000
= - $14,000

Schedule Performance Index (SPI):

SPI = EV / PV
= $42,000 / $56,000
= 0.750

Schedule Variance % (SV%):

SV% = SV / PV
= - $14,000 / $56,000
= 25% BEHIND SCHEDULE
 Earned Value Scenario
Estimate at Completion (EAC):
Method #1:
EAC = AC + ETC (say $68,000)
= $48,000 + $68,000
= $116,000
(Change Management for $16,000 funds
request)

Method #2:
EAC = AC + BAC – EV
= $48,000 + $100,000 - $42,000
= $106,000
(Change Management for $6,000 funds
request)
 Earned Value Scenario
Estimate to Complete (ETC):
Method #3
EAC = AC + [(BAC – EV) / CPI]
= $48,000 + [($100,000 - $42,000) / 0.875]
= $48,000 + $66,285
= $114,285
(Change Management for $14,285 funds
request)

Method #4
EAC = BAC / CPI
= $100,000 / 0.875
= $114,285
(Change Management for $14,285 funds
request)
Earned Value Scenario
 Budget Management

Module 6 Exercise
• Work as a team to perform EVM on
assigned project on page 69.
• Prepare a report similar to the
module scenario reporting project
progress.
• Brief class on methods of recovery, if
needed, for project.
 Budget Management

Graphing Earned Value exercise

• Gantt chart baseline (report)
• EVM graph
• Task information
• Cost distribution
• EVM worksheets
 Budget Management

Graphing Earned Value exercise

• Planned Value (PV) is always shown
in blue with circle nodes
• Actual Cost (AC) is always shown in
red with square nodes
• Earned Value (EV) is always shown in
green with triangle nodes
 Budget Management

Graphing Earned Value exercise

• Work together as a team to calculate the
task cost (task budget) for each task
• Record these values on the worksheet
with the total (BAC) calculated
• Warning: Wait to plot on the EVM graph as
a class – we will use the Cost Distribution
Report
$60K

$50K

$40K

$30K

$20K

$10K

1w 2w 3w 4w 5w 6w 7w 8w 9w 10w
 Budget Management

Graphing Earned Value – week 1

• Task A started on time – 30% complete
• Task B started 2 days late – 30% complete
• Task C started 1 day late – 25% complete
• Tasks D, E, F, G, H, and J have not started
• Project Management is on-going
• Actual Costs reported for week 1 = $5000
$60K

$50K

$40K

$30K

$20K

$10K

1w 2w 3w 4w 5w 6w 7w 8w 9w 10w
$60K

$50K

$40K

Cost
$30K
Variance

$20K
Schedule
Variance
$10K

1w 2w 3w 4w 5w 6w 7w 8w 9w 10w
 Error Tracking
Allows comparison of current work to past
projects and provides a quantitative
indication of the quality of the work being
conducted.
The more quantitative the approach to
project tracking and control, the more likely
problems can be anticipated and dealt with in
a proactive manner.
 Reviews
Conducting reviews of requirements,
design, and code is one of the best
ways to improve your work’s quality
and your productivity
Here we’ll look at various types of
reviews and how to document them

51
 Reviews
Review types, in descending order
of formality, include
Inspections
Walk-throughs
Personal reviews

INFO636 Week #8 52
 Inspections
Inspections follow a structured
procedure for evaluating a work product
Fagan inspections are among the best
known brand of inspection
Inspections start with preparation,
where each participant reviews the
work separately, and makes note of
defects found

53
 Inspections
Then there’s an inspection meeting
to discuss the findings of each
participant, and put together a
cumulative list of defects
Then the work product owner fixes the
defects, and puts together a report to
say so, in the repair and report phase

54
 Walk-throughs
Walk-throughs require little preparation,
except by the work product owner
A presentation is given, and participants
provide feedback during it
Follow-up is informal, with the work
product owner responding to the
comments received

55
 Personal reviews
Personal review is the work product
owner reviewing their own stuff
As compiling code has gotten trivially
easy, many programmers have
dropped reviewing their own work in
the hopes that the computer will find
their mistakes
Not a good strategy!

56
 Target of Reviews
Any work product can be the subject
of reviews
Any document
Requirements specification
Design models
Test plans
Internal project processes & procedures
Source code
Scripts too!

57
 Commentary
For those taking INFO 637, the Team
Software Process uses formal reviews
extensively, so pay extra attention!
N track people - while the text
obviously focuses on reviews related to
code, keep in mind that these methods
and tools for reviews can be used to
plan and conduct reviews for anything
58
 Why Review Software?
The history of the PSP has shown
that most people
Initially spend much of their time
(30-50%) in compiling and testing
By the end of this course, only about
10% of their time is spent testing
Good reviews are a key to reducing
testing time

59
 Review Efficiency
Finding and fixing defects is much
faster to do in review than in testing
Humphrey found 8x faster fix time in
review than testing
Code reviews are 3-5 times as efficient
at finding defects than testing
Part of the reason is that testing finds
symptoms of the defect, which has to
be investigated by debugging

60
 Severity of Review
We don’t mean to imply that every
piece of code needs exhaustive review
Different approaches can be used,
depending on the complexity, risk,
and importance of the code
Hence you might use inspections for critical
code, walk-throughs for typical code, and
just personal review for low risk code

61
 Review Principles
Any kind of review process typically
follows three principles
Establish defined review goals
Follow a defined process for conducting
a review (here, we’ll use scripts)
Measure and improve your review process

62
Separate Design and Code Reviews
Design and code should be
reviewed separately
Forces making a design before coding
It’s hard to decipher design from the code
Helps spot logic errors in design, and
identify design improvements
Helps focus review scope

63
 Design Reviews
Make your design reviewable
Follow a standard notation for design,
such as UML, DFD, ERD, etc.
Make sure design addresses both
functional and non-functional requirements
Follow personal design standards,
hopefully in concert with
organizational standards

64
 Design Reviews
Follow a design review strategy
Look at various elements of design
systematically – don’t try to assess
it all at once
Design review strategy stages
might include
Check for required program elements

65
 Design Reviews
Examine overall program structure
and flow
Check for logical completeness
Check for robustness - handling errors, etc.
Check parameters and types for methods
and procedure calls
Check special variables, data types, and
files, including aliases

66
 Design Reviews
Check design against the requirements
More elaborate inspections might use
A traceability matrix to prove
completeness, or
Use formal methods (Z, Larch) to show
correctness mathematically

67
 Measuring Reviews
Key basic measures for reviews are
Size of product being reviewed
(in pages or LOC)
The review time, in minutes
The number of defects found
And based on later work, the defects
that weren’t found by the review

68
 Measuring Reviews
Derived metrics for reviews are
Review yield, the percent of defects
found by review
Yield = 100*(defects found) /
(defects found + defects not found)
Number of defects found per kLOC or page
Number of defects found per hour of
review time

69
 Measuring Reviews
The number of LOC or pages reviewed
per hour
Defect Removal Leverage (DRL)
The ratio of defects removed per hour for
any two phases or activities
DRL(coding) = Defects/hour(coding)/
Defects/hour(design)

70
 Checklists
Checklists are used to help make sure
a process or procedure is followed
consistently each time
A sample code review checklist for C++
is on variations can be developed for
other languages.
It has several blank columns so each
module can be checked off separately

71
 Designing Checklists
Checklists should be designed so that
you have to focus on only one topic
at a time
Similar to reviewing a book for grammar
versus plot development – it’s hard to
look for both at once
To use a checklist most effectively,
completely review one module

72
 Using Checklists
Different strategies should be
considered for different types
of reviews
Design review for a large application
might prefer to be from the top down
Code review often works better from
the bottom up for your code, but top
down for someone else’s

73
 Building Checklists
Don’t take the example as the ultimate
final perfect most-wonderful-of-all
checklist that ever was *breathe*
Study the kinds of problems you
encounter (in your defect log) to
see what you need to emphasize
in your checklist

74
 Building Checklists
The types of defects are given again,
consider adapting this to your needs
and other languages
One way to look for your most common
types of defects is to lump all your
defect logs together, and generate a
Pareto chart by defect type

75