SE351a: Software Project & Process Management

24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa

SE351a: Software Project & Process ManagementSE351a: Software Project & Process Management

W9 : Project Monitoring & Control

24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 2

SE351 RoadmapSE351 Roadmap

Introduction to Software Project Management

Project Management

Software Development Life Cycles

Requirements Engineering

Software Process & Project Metrics

Software Project Planning

Project Monitoring & Control

• Risk Management

• Software Quality Assurance

• Software Configuration Management


Scope the Project State the problem or opportunity Establish the project goal Define the project objectives Identify the success criteria List assumptions, risks and obstacles

Develop Detailed Plans • Identify project activities • Estimate activity duration • Determine resource requirements • Construct & analyze project network • Prepare the project proposal Launch the Plan

Recruit and organize project team Establish team operating rules Level project resources Schedule work packages Document work packages

Monitor & Control ProgressEstablish progress reporting system Install change control process Define problem escalation process Monitor progress versus plan Revise project plan

Project Close-Out Obtain client acceptance Install project deliverables Complete project documentation Complete post-implementation audit Issue final project report

The Architecture of PMLC…


Project Management:Project Management:The Control panelThe Control panel

Cost ScheduleCost ScheduleC

umul

ativ

e C

ost

Cum

ulat

ive

Cos

t55 1010

Resource AllocationResource Allocation

Pers

onne

lPe

rson

nel

PERTPERTAssessmentAssessment

Expected DateExpected Date

Specifyoverallsystem

SpecifymoduleA

SpecifymoduleB

SpecifymoduleC

SpecifymoduleD

Checkspecifi-cations

DesignmoduleA

DesignmoduleB

DesignmoduleC

DesignmoduleD

Code/testmoduleA

Code/testmoduleB

Code/testmoduleC

Code/testmoduleD

Integrate/testsystem

Activity PlanActivity Plan


Project ControlProject Control

• Project control is an iterative process

with following actions

1) Determining Project Status

2) Comparing Status with Planning

3) Taking Corrective Actions


Monitoring PrinciplesMonitoring Principles

• Frequency to receive information

depends on the size and risk of the project

It is recommended to have

o weekly collection of information while it is still fresh

• The higher the level

the less frequent and detailed the reporting needs to be

o Team leaders may have to assess daily

especially for inexperienced staff

o Higher level managers may find weekly or monthly reporting appropriate


Project Reporting StructureProject Reporting Structure

Analyst/Designer

TeamLeader

Analyst/Designer

ProjectManager

TeamLeader


Reporting System: CharacteristicsReporting System: Characteristics

• Provides timely, complete, and accurate status information

• Easily understood

• Warns of pending problems in time to take actions

• Doesn’t add so much overhead

• Acceptable by the project team and senior management


Types of Project Status ReportsTypes of Project Status Reports

• Current Period Reports

The most recently completed period

Highlight activities completed and variance between scheduled and actualcompletion dates

• Cumulative Reports

Captures the history of the project from beginning to the end

• Variance Reports

Report differences between what was planned and what actually happened

Typical variables tracked are: schedule and cost

• Exception Reports

Reports variances from Plan, typically targeting senior management


Types of ReportingTypes of Reporting

Report Type Examples Comments

Written, formal, Job sheets, progress Normally weekly, regular reports using forms

Written, formal Exception reports, irregular change reports

Verbal, formal, Weekly or monthly Written minutes should regular progress meetings be kept

Verbal, formal, Milestone review Also includes writtenirregular meetings documentation

Verbal, informal, Walking around, Often providesad hoc social interactions early warning


Assessing ProgressAssessing Progress

• Progress assessment based on information collected

o information should be objective and tangible

Set a series of checkpoints in the initial project plan

Weekly, reports, milestones, ...

activities should be broken down into controllable tasks (work packages)

– with one to a few weeks duration

partial completion of an activity can be estimated with a series of productsseries of products

– e.g., number of screen layouts produced


Gathering MetricsGathering MetricsA ReminderA Reminder……

• An organization striving to get to SEI level 3 or higher

has to gather metrics

• The best time to obtain metric inputs is

while the project is underway

o Data is timely, not likely to be lost

o Errors in data collection can be corrected

• Current project metrics are an excellent indicator of

progress, budget and schedule control


Current Project Metrics: Current Project Metrics: ExamplesExamples

Description Description UnitsUnitsNumber of project staff People

Effort (by work package) Person-hours

Labor cost (by work package) $/person-month

Elapsed time to completion Days, weeks, months

Newly developed code FP/KLOC

Modified (existing code) FP/KLOC

Delivered code FP/KLOC

Number of defects Defects

Documentation Pages, figures


Project WBSelement

Description Hours thisweek

%Complete

Scheduledcompletion

Projectedcompletion

Time Sheet

Staff J. Smith Week ending 11/14/03

P21 2.1.12 Design A32.1.12 Design A3 28 90 90 11/8/03 11/12/03

P21 3.4.3 Code mod. C53.4.3 Code mod. C5 12 30 30 11/22/03 12/10/03

Weekly Time Sheet & Progress Review FormAn Example


Visualizing ProgressVisualizing Progress

• A manager needs to present data in way that has the greatest effect

Visualization gives a quick assessment tool for senior management

Public visualization of progress can be used as a staff motivating tool

o Good performers are recognized

o People behind schedule are motivated to catch up


Visualizing Progress Visualizing Progress Using a Gantt ChartUsing a Gantt Chart

W T F M T W T F M T W T F M T W T F M T W T12 13 14 15 16

Code & testmodule A

Code & testmodule B

Code & testmodule C

Code & testmodule D

Integrate & test system

Planned Time (Week Numbers)

Today


Visualizing Progress Visualizing Progress Using a Milestone ChartUsing a Milestone Chart

J. SmithCode & testmodule A

H. BrownCode & testmodule B

A. CamptonCode & testmodule C

D. GordonCode & testmodule D

H. BrownIntegrate & test system

13 14 15 16 17Planned Time (Week Numbers)

Today


The TrafficThe Traffic--Light Method: BottomLight Method: Bottom--UpUp

• Break the key elements into constituent elements (second level)

• Assess each of second level elements

Green –on targeton target

Amber –notnot on targeton target but recoverable

Red –notnot on targeton target and recoverable only with difficulty

• Review all second level assessments to

arrive at first level assessments, and

all first level assessments to produce an overall assessment


A Traffic Light AssessmentA Traffic Light Assessment

Week No.

+ Activity summary

Component

- Screen handling procedures

- File update procedures

- Compilation

- Test data runs

- Program documentation

13 14 15 16

Staff:

Ref: IoE/P/13 Activity: Code & test module C

A. Campton


Rules of Thumb for Effort MetricsRules of Thumb for Effort Metrics

• Software size metric

as a tool tracks the magnitude of the development effort

Trend shouldshould be fairly stable

o month-to-month estimates should notshould not vary by more than 5%5%

o Variations may indicate:

A better understanding of the requirements, or

Problems with the development process


Personnel MetricsPersonnel Metrics

300

200

100

0

-20Time

Total

Experienced

Planned

Actual

Unplanned losses


Rules of Thumb for Personnel MetricsRules of Thumb for Personnel Metrics

• Ratio of total to experienced personnel

a typical ratio is 3:1

o should never exceed 6:1

• The project front end should be leveraged with

more experienced personnel

• Understaffing is

an an early sign of schedule slipo You cancan’’t alwayst always catch up by adding more people later

it may even further delay work

• High turnover or loss of personnel is a sign of problems


Computer Resource MarginsComputer Resource Margins

80

60

40

20

0

Time

Planned Spare

% U

tiliz

a tio

n

CPUMemoryI/O


Computer Resource Metrics:Computer Resource Metrics:Rules of Thumb Rules of Thumb

• CPU and Memory utilization should allow for a 50% margin at delivery

• Resource utilization tends to increase with time

so plan for expansion

• For real-time systems performance

degrades quickly above 70% utilization


Requirements Changes MetricRequirements Changes Metric

2000

1500

1000

500

0Time

TotalReqmts

CumChanges

Req

uire

men

ts


Requirements Changes MetricsRequirements Changes Metrics

• Track open software action items (requirements lacking analytic justification)as well as requirements

action items should be closed within a specified period

• Use requirements traceability tool to track requirements status

• Requirements growth will impact planned resources

should be contained from start


Defects and Fixes MetricDefects and Fixes Metric

New Faults

ResolvedFaults

200

150

100

50

0Time

Def

ects

and

Fix

es


Test Program StatusTest Program Status

• Measure planned vs. actual tests

• Track software problem reports (SPRs)

Typical range is 5 - 30 SPRs per KLOC

Too manyToo many SPRs indicate poor quality

However, Too few SPRs may mean inadequate testing

Track number of days that SPRs remain openremain open

Track SPRs by priority


Cost MonitoringCost Monitoring

• Expenditure monitoring provides an indication of

effort that has gone into a project

Costs have to be compared with budgeted-costs

24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 30C

umul

ativ

e C

ost (

$)

Time

BCWS

ACWP

BCWP

Earned Value AnalysisEarned Value Analysis

• The cumulative value of completed WPs

can be compared to the budgeted and actual cost to complete

o Gives a more accurate measure of schedule and budget progress

• Examine the variancebetween the project plan and the project status

• To perform EVA

use the SS--curvescurves with five cumulative variables:

o BCWS: Budgeted Cost of Work Scheduled

o BCWP: Budgeted Cost of Work Performed (earned valueearned value)

o ACWP: Actual Cost of Work Performed

o BAC: Budget at Completion

o EAC: Estimated budget at Completion


EVA: ParametersEVA: Parameters

EACEstimate at completion What do we nownow expect the total job to cost?

BACBudget at completion (total budget)What waswas the total job supposed to cost?

ACWPActual cost of work performed (actuals) How much did the "is done" work cost?

BCWPBudgeted cost of work performedHow much work is done?

What was the “is done” supposedsupposed to cost?

BCWSBudgeted cost of work scheduledHow much work should be done?

AcronymAnswerManagement Question


Types of VariancesTypes of Variances

• Cost VarianceCV = BCWP - ACWP

– CV < 0 Cost overrun– CVP = CV / BCWP %

• Schedule VarianceSV = BCWP - BCWS

– SV < 0 behind-schedule– SVP = SV / BCWS %

• Variance At CompletionVAC = BAC - EAC


Snippet of Cumulative &Weekly Costs: 4 Module Project

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Week Number

$25K/$5

$50K/$10

$75K/$15

$100K

Cumulative Cost /Weekly Cost


Smoothing Resource Requirements:Activities Rescheduling

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

No.

Pe r

s onn

elA

ctiv

ities

Week Number

1

2

3

4

5

2


The SThe S--Curve of Cumulative ExpenditureCurve of Cumulative Expenditure

Cum

ulat

ive

Cost

($)

SV = BCWP - BCWS

CV= BCWP - ACWP


Example:Example:Cost/Performance VarianceCost/Performance Variance

$500

Scheduled/BudgetedTo do $500 Work over 5 days in a 5-day windowBCWS = $500

5 days

$300

Scheduled SlippagePermits only 3days/300$ work to be performedBCWP = $300SV = - $200SVP=-40%

$200

5 days

$400

ACWP = $400CV = - $100CVP=-33.33%

$200

5 days


Estimate To CompletionEstimate To Completion

Cum

ulat

ive

Cos

t ($)


Comparing Status With PlanningComparing Status With Planning

• Variances can be addressed through o progress reviews

o schedule and technical meetings

o informal communications

• Analyze it to provide indicators of trends and problems


Performance EfficiencyPerformance Efficiency

• Schedule Performance IndexSPI = BCWP/BCWS

How close the project is to performing work o as it was actually scheduled

• Cost Performance IndexCPI = BCWP/ACWP

How close the project is to spending on the work performedo to what was planned to have spent

• Nominal: value for SPI and CPI is 1 Perfect Performance

• Problems: value of SPI and CPI less than 1 Poor performance

• Outstanding: value for SPI and CPI > 1 Exceptional Performance


Example:Example:Performance EfficiencyPerformance Efficiency

$500

Scheduled/BudgetedTo do $500 Work over 5 days in a 5-day windowBCWS = $500

$300

Scheduled SlippagePermits only 3days/300$ work to be performedBCWP = $300SV = - $200SVP=-40%SPI= 300/500 = 0.6

$400

ACWP = $400CV = - $100CVP=-33.33%CPI = 300/400= 0.75

$200$200

5 days 5 days 5 days


Performance EfficiencyPerformance Efficiency(Cont.)(Cont.)

• SPI & CPI are used for trend analysis

Trend analysis is an early warning system to take actions to alleviate unfavorable trends

• However, it requires 3-6 months moving averages to predict a trend


Other Useful indicatorsOther Useful indicators……

• To-Complete Performance Index:

TCPI = (BAC - BCWP(cumul))/(EAC - ACWP(cumul))

• Estimate at Completion:

EAC = ACWP(cumul) + PF*(BAC - BCWP(cumul))

where PF is ACWP/BCWP

• Schedule Variance in Time Units:

SV(tu) = SV(cumul)/BCWP(current tu)

• Percent Spent:

%Spent = ACWP(cumul)/BAC*100

• Percent Complete:

%Complete = BCWP(cumul)/BAC*100


Prioritized MonitoringPrioritized Monitoring

• Monitoring

consumes time

uses resources that might be put to better use

• Levels of monitoring can be set based on priorities

Critical path activities

Activities with less than a specified float

High risk activities

Activities using critical resources


Data AccumulationData Accumulation

SV

CV

BCWS

BCWP

ACWP

BUDGET

EACOR

GA

NIZ

ATI

ON

OR

GA

NIZ

ATI

ON

WBSWBS


Cost Data Collection & Reporting FlowCost Data Collection & Reporting Flow

BCWSBCWS

Inventory AccountInventory Account

StaffStaff

ActualsActuals

ACWPACWP

BCWPBCWP

MonthlyProject Efforts

MonthlyProject Efforts

Weekly LaborReports

Weekly LaborReports

VarianceReports

VarianceReports


Variance analysisVariance analysis

• A tool allows a manger to take actiontake actiono either, to correct the problem within the original budget

o or, to justify a new estimate

To do so, the following need to be addressed

1. What is the problem causing the variance?

2. What is the impact on

• time, cost, and performance?

• other efforts, if any?

3. What corrective actions are planned or under way?

4. What are the expected results of the corrective actions?


Cost Control & Report FlowCost Control & Report Flow

ReportsReportsExceptions

Reports(if necessary)

ExceptionsReports

(if necessary)

Functional Management

StaffTime Sheet

StaffTime Sheet

Actual% Complete

Project Management Office

Budgets &Target % Complete

Executive Management

Total Project Detailed Reports

ProjectSummary Reports

Functional Detail/Summary Reports


Reporting Procedure for VarianceReporting Procedure for Variance

• Variance Status Reporting should be concise

It yields fast feedback and response

Variance analysis

Diagnose the problem

Find the cure for the problem

o Two main constraints on rescheduling resources

The end date is fixed

Resources are constant (or limited)

Develop a plan to recover the problem



Responses to Variance ReportResponses to Variance Report

• Ignore itIf variance within boundaries

• Functional modificationVariance is marginal

• Re-planningMajor variance:

o redefine the project goals as work progresses

but within system specifications

• System redesignMajor variance and re-planning cannot be accomplished

o some specifications need to be sacrificed

to satisfy time and money constraints


ReRe--planningplanning

• A plan is a living document

A project can be re-planned

o After taking any necessary corrective actions

o With agreement from the customer

• Project plans need to be kept current

to reflect actual and agreed to conditions


Taking Corrective ActionsTaking Corrective Actions

• Schedule variances (SV) are essential, but

do not provide a complete schedule performance picture

nor do they consider the sequence of work activities

• We need to perform schedule analysis

to quantify

o how time delays, caused by technical or other problems, will affect all futureactivities and milestones

o how corrective action plans can reduce the scope of these effects

especially, performance on the critical path


Getting the Project Back on TrackGetting the Project Back on Track

• Shorten the critical path?allocate additional resources (add people)

o Will adding people late in the program shorten or lengthen the time required to complete the remaining work?

increase level of existing resources (overtime)

allocate more efficient resources to critical activities

• Reconsider precedence requirementsAlter “normal” practice

Subdivide activitieso into components which can start immediately

Analyze resulting risk and quality

• Reallocate resourcesExamine earned value summary report:

Are there areas that are under planned expenditures?

Documents

SE351a: Software Project & Process Management