Earned Value Management (EVM)

Earned Value Management (EVM)

The earned value Management involves developing these key values for each schedule activity, work package, or control account:

Planned value (PV). PV is the budgeted cost for the work scheduled to be completed on an activity or WBS component up to a given point in time.

Earned value (EV). EV is the budgeted amount for the work actually completed on the schedule activity or WBS component during a given time period.

Actual cost (AC). AC is the total cost incurred in accomplishing work on the schedule activity or WBS component during a given time period. This AC must correspond in definition and coverage to whatever was budgeted for the PV and the EV (e.g., direct hours only, direct costs only, or all costs including indirect costs).

Cost variance (CV). CV equals earned value (EV) minus actual cost (AC). The cost variance at the end of the project will be the difference between the budget at completion (BAC) and the actual amount spent. Formula: CV= EV – AC

Schedule variance (SV). SV equals earned value (EV) minus planned value (PV). Schedule variance will ultimately equal zero when the project is completed because all of the planned values will have been earned. Formula: SV = EV – PV

These two values, the CV and SV, can be converted to efficiency indicators to reflect the cost and schedule performance of any project.

Cost performance index (CPI). A CPI value less than 1.0 indicates a cost overrun of the estimates. A CPI value greater than 1.0 indicates a cost underrun of the estimates. CPI equals the ratio of the EV to the AC. The CPI is the most commonly used cost-efficiency indicator. Formula: CPI = EV/AC

Schedule performance index (SPI). The SPI is used, in addition to the schedule status to predict the completion date and is sometimes used in conjunction with the CPI to forecast the project completion estimates. SPI equals the ratio of the EV to the PV. Formula: SPI = EV/PV

Forecasting

Forecasting includes making estimates or predictions of conditions in the project’s future based on information and knowledge available at the time of the forecast. Forecasts are generated, updated, and reissued based on work performance information provided as the project is executed and progressed.

BAC is equal to the total PV at completion for a schedule activity, work package, control account, or other WBS component. Formula: BAC = total cumulative PV at completion.

ETC is the estimate for completing the remaining work for a schedule activity, work package, or control account.

ETC based on new estimate. ETC equals the revised estimate for the work remaining, as determined by the performing organization. This more accurate and comprehensive completion estimate is an independent, non-calculated estimate to complete for all the work remaining, and considers the performance or production of the resource(s) to date.

Alternatively, to calculate ETC using earned value data, one of two formulas is typically used:

ETC based on atypical variances. This approach is most often used when current variances are seen as atypical and the project management team expectations are that similar variances will not occur in the future. ETC equals the BAC minus the cumulative earned value to date (EVC). Formula: ETC = (BAC – EVC)

ETC based on typical variances. This approach is most often used when current variances are seen as typical of future variances. ETC equals the BAC minus the cumulative EVC (the remaining PV) divided by the cumulative cost performance index (CPIC). Formula: ETC = (BAC – EVC) / CPIC

EAC is the projected or anticipated total final value for a schedule activity, WBS component, or project when the defined work of the project is completed. One EAC forecasting technique is based upon the performing organization providing an estimate at completion:

EAC using a new estimate. EAC equals the actual costs to date (ACC) plus a new ETC that is provided by the performing organization. This approach is most often used when past performance shows that the original estimating assumptions were fundamentally flawed or that they are no longer relevant due to a change in conditions. Formula: EAC = ACC + ETC

The two most common forecasting techniques for calculating EAC using earned value data are some variation of:

EAC using remaining budget. EAC equals ACC plus the budget required to complete the remaining work, which is the budget at completion (BAC) minus the earned value (EV). This approach is most often used when current variances are seen as atypical and the project management team expectations are that similar variances will not occur in the future. Formula: EAC = ACC + BAC – EV

EAC using CPIC. EAC equals actual costs to date (ACC) plus the budget required to complete the remaining project work, which is the BAC minus the EV, modified by a performance factor (often the CPIC). This approach is most often used when current variances are seen as typical of future variances. Formula: EAC = ACC + ((BAC – EV) / CPIC)

USE Case Point Estimation

Use Case Estimation

Use Case Points (UCP) is an estimation method that provides the ability to estimate an application’s size and effort from its use cases.

UCP analyzes the use case actors, scenarios and various technical and environmental factors and abstracts them into an equation.

The equation is composed of four variables:

  • Technical Complexity Factor (TCF).
  • Environment Complexity Factor (ECF).
  • Unadjusted Use Case Points (UUCP).
  • Productivity Factor (PF).

UCP = TCP * ECF * UUCP * PF

Technical Complexity Factors

Thirteen standard technical factors exist to estimate the impact on productivity that various technical issues have on an application. Each factor is weighted according to its relative impact. A weight of 0 indicates the factor is irrelevant and the value 5 means that the factor has the most impact.

Technical Factor Description Weight
T1 Distributed system 2
T2 Performance 1
T3 End User Efficiency 1
T4 Complex internal Processing 1
T5 Reusability 1
T6 Easy to install 0.5
T7 Easy to use 0.5
T8 Portable 2
T9 Easy to change 1
T10 Concurrent 1
T11 Special security features 1
T12 Provides direct access for third parties 1
T13 Special user training facilities are required 1

For each project, the technical factors are evaluated by the development team and assigned a value from 0 to 5 according to their Assigned Value. An Assigned Value of 0 means the technical factor is irrelevant for this project; 3 is average; 5 mean it has strong influence.

Technical Factor Description Weight Assigned Value (0-5) Weighted Value
T1 Distributed system 2 0
T2 Performance 1 0
T3 End User Efficiency 1 0
T4 Complex internal Processing 1 0
T5 Reusability 1 0
T6 Easy to install 0.5 0
T7 Easy to use 0.5 0
T8 Portable 2 0
T9 Easy to change 1 0
T10 Concurrent 1 0
T11 Special security features 1 0
T12 Provides direct access for third parties 1 0
T13 Special user training facilities are required 1 0
Total Factor 0

Technical Complexity Factor (TCF) = 0.6 + (0.01 * Total Factor)

Environmental Complexity Factors

Environmental Complexity estimates the impact on productivity that various environmental factors have on an application. Each environmental factor is evaluated and weighted according to its perceived impact and assigned a value between 0 and 5. A rating of 0 means the environmental factor is irrelevant for this project; 3 is average; 5 mean it has strong influence.

Environmental Factor Description Weight
E1 Familiarity with UML 1.5
E2 Application Experience 0.5
E3 Object Oriented Experience 1
E4 Lead analyst capability 0.5
E5 Motivation 1
E6 Stable Requirements 2
E7 Part-time workers -1
E8 Difficult Programming language 2

Each factor’s weight is multiplied by its Assigned Value to produce its calculated factor. The calculated factors are summed to produce the Total Factor.

Environmental Factor Description Weight Assigned Value (0-5) Weighted Value
E1 Familiarity with UML 1.5 0
E2 Application Experience 0.5 0
E3 Object Oriented Experience 1 0
E4 Lead analyst capability 0.5 0
E5 Motivation 1 0
E6 Stable Requirements 2 0
E7 Part-time workers -1 0
E8 Difficult Programming language 2 0
Total Factor 0

Environmental Factor (EF) = 1.4 + (-0.03 * Total Factor)

Unadjusted Use Case Points (UUCP)

Unadjusted Use Case Points are computed based on two computations:

The Unadjusted Use Case Weight (UUCW) based on the total number of activities (or steps) contained in all the use case Scenarios.

The Unadjusted Actor Weight (UAW) based on the combined complexity of all the use cases Actors.

UUCW

Individual use cases are categorized as Simple, Average or Complex, and weighted depending on the number of steps they contain – including alternative flows.

Use Case Type

Description

Weight
Simple A simple user interface and touches only a single database entity; its success scenario has 3 steps or less; its implementation involves less than 5 classes.
L
5
Average More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes. 10
Complex Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes. 15

UAW

In a similar manner, the Actors are classified as Simple, Average or Complex based on their interactions.

Actor Type

Description

Weight
Simple The Actor represents another system with a defined API.
L
1
Average The Actor represents another system interacting through a protocol, like TCP/IP. 2
Complex The Actor is a person interacting via an interface. 3

Finally, the UUCP is computed by adding the UUCW and the UAW.

Productivity Factor

The Productivity Factor (PF) is a ratio of the number of man hours per use case point based on past projects. If no historical data has been collected, a figure between 15 and 30 is suggested by industry experts. A typical value is 20.

illustration Points

  • The number of steps in a scenario affects the estimate. A large number of steps in a use case scenario will bias the result towards complexity and increase the Use Case Points. A small number of steps will bias it towards simplicity. Sometimes, groups of steps can be reduced to a fewer number without sacrificing the business process. Strive for a uniform level of detail but don’t force a use case to conform to the estimation method.
  • Including and extending use cases increases the complexity. Count these as a single use case.
  • The number of actors in a use case also affects the estimate. If possible, generalize the actors into a single superactor. This reduces the complexity without affecting the use case. On the other hand, don’t force a generalization where none exists.
  • The values for the Technical and Environmental Factors need to be adjusted over time as actual data is obtained. The more projects that employ Use Case Points for their estimations will yield more accurate values for the perceived values.
  • The Productivity Factor can only be obtained over time. Track the time spent designing and implementing the use cases and adjust the Productivity Factor accordingly.