UNIT — III Project Monitoring and Control

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 ACTION Correct deviations from plan RE-PLAN as necessary PLAN Specifications Project Schedule Project budget Resource plan Vendor contracts MONITOR Record status Report progress 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] SV=[EV-PV] CPI=[EV/AC] SPI=[EV/PV] EAC=[BAC/CPI] ETC=[EAC-AC] VAC=[BAC-EAC] When memorizing the formulas I have found it best to look for patterns. When I see the correct pattern I know the formula is correct. AC = ACWP PV = BCWS EV = BCWP

Earned Value Management Example Task – Drill & install 10 piezometers • Budget - $100, 000 ($10 K 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

$60 K $50 K $40 K $30 K $20 K $10 K 1 w 2 w 3 w 4 w 5 w 6 w 7 w 8 w 9 w 10 w

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

$60 K $50 K $40 K $30 K $20 K $10 K 1 w 2 w 3 w 4 w 5 w 6 w 7 w 8 w 9 w 10 w

$60 K $50 K $40 K Cost Variance $30 K $20 K Schedule Variance $10 K 1 w 2 w 3 w 4 w 5 w 6 w 7 w 8 w 9 w 10 w

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 INFO 636 Week #8 52

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 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 8 x 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 k. LOC 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 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 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