This document proposes the EVA (Earned Value Analysis) model and performance dashboard to help track the relative performance of modules or projects within a large, complex program. The EVA model breaks down work into detailed tasks with planned start/end dates. Actual progress is tracked by binary questions on task completion. This rolls up to expected and actual percentage completions at the module level, addressing issues with subjective status updates. The performance dashboard then ranks modules based on their performance against schedule and cost targets using EVA data. This provides program managers and sponsors with an objective tool to monitor performance and take corrective actions.

1. 1 Page

2. The EVA Model of Performance
Measurement for Heterogeneous and
Multi Platform Programs
Aditya Rawal – Associate Consultant, TATA Consultancy Services Limited

3. Contents
1. Abstract ........................................................................................................................................... 4
2. Business Challenge ........................................................................................................................ 4
3. Solution Approach ........................................................................................................................... 5
4. Conclusion..................................................................................................................................... 12
5. Bibliography................................................................................................................................... 12
6. Author’s Profile: ............................................................................................................................. 13
3 Page

4. 1. Abstract
With a continuously changing business scenario, Enterprises are looking for operational efficiency to
remain competitive and to track the relative performance of modules/projects within a large program.
The traditional method of comparing the performance of multiple projects or modules in a
program has inherent flaws because of information inconsistency, heterogeneity and incompatible
data.
This paper highlights the challenges in tracking the relative performance of multiple Modules or
Projects in a large Program and discusses the practical implementation of the EVA Model and
Performance Dashboard for effective program performance monitoring and control aiding the
supervisor to take corrective action.
The EVA Model and Performance Dashboard provide the framework to isolate and insulate the
differences among modules by decoupling their intrinsic complexity and by providing common
platform based on similarity or equivalence.
The performance Dashboard ranks individual modules based on their performance on schedule and
on cost budget front.
The ranking of the modules is derived from the Earned Value Analysis (EVA) model based on effort
consumed, planned and actual completion.
This entire model is based on actual verifiable data. The Four most important aspect of this are:
1. Actual Cost: This is the cost which is actually consumed while performing a task.
2. Budgeted Cost: The baselined cost budget defined at the time of project Start up
3. Expected % Completion: This is derived from the Planned End date of each task
4. Actual % Completion: This is derived from the actual end date of the task.
2. Business Challenge
Case Scenarios which can be found commonly in heterogeneous program
Project Manager A to Project Manager B: “I am managing a project having five Modules of varying
complexities and five leads reporting to me. All of them are doing good progress, but there is no
common yardstick for me to measure their relative performance”
Module Lead: “I am not comfortable with my team members sharing the status of their work by way
of “% completion”. I cannot rely on their value judgement.
Project Sponsor: “I am not able to take any corrective action based on the project report that is
getting submitted by Project Manager. Instead of making any value judgement I wish there were tools
available to me to decide on my resource allocation priorities”
Challenges of tracking performance in a Program
The biggest challenge which the Project Sponsors and Project Manager face today is to gauge the
relative performance of multiple modules or Projects within a large Program. Project leads come up
with their own effort estimation and have their own method of arriving at the project completion status
4 Page

5. (Mostly by way of depicting in % completion). At a higher level, project sponsors do not have
necessary visibility on the relative performance of the modules.
Availability of this information can assist the stakeholders in taking timely corrective actions like
adding or withdrawing resources and or identifying training needs or technical help.
Just as an athlete cannot make it to the Olympics without extraordinary physical ability, a good
Manager must master the four dimensions of Project Management to be successful. (Gerstenmaier)
3. Solution Approach
Program Managers and Sponsers in today’s challenging business environment need a tool for
effective decision making. This tool could be in the form of a Dashboard, which can rank individual
modules or Projects based on their performance on schedule and cost budget front.
The ranking is derived from the Earned Value Analysis (EVA) model based on actual effort
consumed, effort planned and actual completion of work.
The entire model is based on actual verifiable data. Four most important aspects of this model are:
1. Actual Cost: This is the cost which is actually consumed when the module or project gets
completed.
2. Budgeted Cost: The baselined cost budget defined at the time of project Start up.
3. Expected % Completion: This is derived from the Planned End date of each task.
4. Actual % Completion: This is derived from the actual end date of the task.
The EVA model functions by breaking down each module into task and creating detailed Work
Breakdown Structure (WBS).
While defining Work Breakdown Structure in a large program, the most important aspect is the
granularity to which tasks are to be defined. To put point in perspecive, we take the example of a
large Program for Utility domain. There were 15 modules. Each module was of a size of a small
project (Around 200 Person Months)
A detailed WBS is prepared for each module. In order to sufficiently decompose the work into proper
granularity, inputs from the junior most team member is taken.
5 Page

6. A screen shot of the actual WBS for the entire program is given in the following figure:
Figure 1: Work Breakdown Structure
Against each task, there is a Planned Start and Planned End Date and Actual Start and Actual End
date arrived at based on the effort estimation. Each task has a field for “% completion”. There is a
calculated field called “Expected % - Final”.
The progress of the task is being tracked on a daily basis. Conventionally Project or Module leads
are used to taking “% completion” status from each team member for the task asigned to them.This
has a inherent element of ambiguity and judgemental error.In the proposed model Instead of asking
for “% completion for each of the task from the task owner, binary questions are asked.The task
owner has only the option of answering in a “Yes” or a “No”. Based on the response only three
discrete values (0%, 33% and 100%) is entered against “Actual % Completion” column. Here
6 Page

7. No Task Completion = 0%
Task Started?
Yes
No
Task Completed?
Task Completion = 33%
Yes
Task Completion = 100%
Figure 2: Binary logic for tracking Actual percentage completion
Has the task started? Yes/No?
If No, then assign the task a % completion of 0%
If the answer is Yes, then another question, Has the task completed? Yes/No?
If No, then assign the task a % completion of 33% else 100%
Thus the “Actual % completion” having either 0%, 33% or 100% rolls up to a discrete figure at module
level based on the weighted average logic based on the planned start and end date. (The tool used
here is Micrsoft Project). Based on the planned start and end date of each task, an “Expected %”
completion is arrived automatically for each task by comparing the system date with the planned end
date. If the system date is greater or equal to the planned end date then the “expected %” completion
for that task turn to 100% which again rolls up to a discrete value at module level. Thus for each
module on a daily basis, there is expected and actual % completion data which keeps on changing
The advantage of this model is uniformity in gauging the % completion across every module. All
individuals are different and have a unique view point with respect to assessing the % completion of
the task he or she is performing. Somebody may be too conservative when sharing the % completion
of a task while the others may be too aggressive.
Since each module is broken up into the appropriate level of granularity into tasks and sub tasks, and
each task is assigned values based on binary feedback, the % completion when it rolls back at the
module level gives a fairly accurate picture of the module % completion.
Consumer Portal Module is taken as an example for the case study.
7 Page

8. The “Testing” phase of the portal modules is explained as follows.
In this case, the planned end date of the testing phase for most of the tasks has gone past the current
date which is the system date so the Expected % comletion is being shown as 100% for them. Only
for sub phase “Performance Testing”, the planned end date is a future date. Hence the expected %
completion for that sub phase is shown as 0%.
For the completed tasks a percentage completion of 100% is assigned.
The rest are “work in progress” or have not started yet. Hence, a % completion of 33% and 0%
respectively is assigned to those tasks. When the task rolls up at the phase level, we get a %
completion is 34%.
Figure 3: WBS for testing phase of Consumer Portal
At first sight it may look as though this may give erraneous result. Because if task definiation doesn’t
have uniform granularity, the % completion may be deciptive. However this is not the case. Since the
individual tasks roll up to a discrete number.
The detailed EVA analysis for the portal is explained in the following table:
8 Page

9. Table 1: Earned Value Analysis for Consumer Portal
Indicators Value Explanation
We should have done 39.59 Person Months worth of Work till date (April
Planned Value 39.56 2011 End)
Earned Value 36.51 We have actually completed 36.51 Person Months worth of work till date
Actual Cost 115 We have consumed 115 Person Months till date
Budget at
Completion 43 Our original Budget to complete the activity is 43 Person Months
Cost Variance -78.49 We are lagging behind the schedule by 78 person months.
Cost Performance
Index (CPI) 0.31 We are only getting 31 Paisa out of every Rupee we put into the project
Schedule Variance -3.04 We are lagging behind the schedule by 3.04 person months.
Schedule Per. Index
(SPI) 0.92 We are only progressing at 92% of the rate planned
Estimate at
Completion 135.45 At completion we would have spent close to 135 PM worth of effort.
Estimate to
Complete 20.45 We need further 20 PM worth of effort to reach to completion
Variance at There is a variance of 92.45 PM worth of effort between our planned and
Completion -92.45 actual effort
Planned value PV = Expected % completion X Budget at Completion (Effort Estimate)
= 0.9199*43
= 39.56 PM
Earned Value EV = Actual % completion X Budget at Completion (Effort Estimate)
= 0.849*43
= 36.51 PM
Actual Cost AC = the total cost consumed in person months
= (Number of associates X Elapsed days)/22
= (8 X 316)/22
= 115 PM
9 Page

10. Cost Variance = EV – AC
= - 78.49 PM
Schedule Variance = EV -PV
= -3.04 PM
Cost Performance
Index =EV/AC
= 0.317
Schedule Performance
Index =EV/PV
=0.92
Estimate at
Completion = Budget at completion/CPI
= 135 PM
The Performance Dashboard
Both Cost Performance Index and Schedule Performance Index are two sides of a same coin.
Once the Actual and Expected % completion is calculated for all modules, the same is represented in
the Performance Dashboard as shown in the following table. An average of the same is arrived at,
based on which, a Ranking is given to each module.
Consumer portal is highlighted in Red in the following table:
Table 2: Performance Dashboard
Original Actual Expected Actual Cost Sch.
Estimate Effort % % Perf. Perf.
Modules (PM) cons.(PM) Comp. Comp. Index Index Average RANK
Beehive 15 7 91.05% 85.62% 1.83 0.94 1.385 1
Unified
Content
Management 32 31 82.11% 82.11% 0.84 1 0.92 2
SOA 53 92 97.62% 86.51% 0.49 0.88 0.685 3
MDM 65 83 99.22% 77.12% 0.6 0.77 0.685 3
10 Page

11. Original Actual Expected Actual Cost Sch.
Estimate Effort % % Perf. Perf.
Modules (PM) cons.(PM) Comp. Comp. Index Index Average RANK
Identity and
Access
Management 30 35 94.99% 71.72 0.61 0.75 0.68 5
Business
Intelligence 45 104 98.56% 93.17% 0.403 0.94 0.6715 6
Consumer
Portal 43 115 91.99% 84.90% 0.31 0.92 0.615 7
Data Center 89 179.167 100.00% 79.09% 0.39 0.79 0.59 8
GIS 184 285 65.05% 45.78% 0.29 0.7 0.495 9
High
Within budget but Behind Within Budget and on
Schedule Schedule. (Beehive)
CPI
Behind Schedule and On Schedule but budget
Low
budget overrun (GIS) over run. (Portal)
Low High
SPI
Figure 4: Schedule-Cost Budget Quadrant
In this case, the Portal team had done extreme detailing in the WBS and following the philosophy of
0, 33 and 100 arrived at actual work completion of 84.9% against expected work completion of
91.99%.
The team was more or less on target as far as meeting the deadline was considered. However, in
doing so, it overshot the budget. By April 2011, the actual cost budget consumed was 115 PM against
the actual work completion of 39.56 PM. Based on this, estimate at completion was calculated and it
arrived at 135 PM. The portal module went live in August 2011. Till that time, the actual effort
consumed came to 139 PM. Thus, this model gave an accuracy of +/- 2%.
There is another example of “Beehive” module explained as follows:
In this module, the Cost Performance Index was 1.35, meaning the cost budget was grossly
underutilized. Also the Schedule Performance Index was 0.94 indicating that the module was as per
the schedule.
11 Page

12. There could be the following inference from this:
1. The Module has been able to manage with less resource and at the same time adhere to the
schedule.
2. The Module has buffer available to take on additional tasks.
3. Effort estimation for the module was incorrect
4. Conclusion
The EVA Model for Performance Dashboard can be used as an instrument for standardization for
performance management across a large program. The EVA Model is able to address various
aspects of dissimilarities in modules by using a common logic of schedule and cost tracking. Effective
management, organizational discipline, and structured approach would be required to sustain the
benefits identified by the model.
It can help the sponsors take decisions on:
1. Identifying the modules/projects which are adhering to the schedule but are over staffed.
2. Identifying the modules which have been slipping on both schedule and cost front. This will
give fair amount of indication about the experience level and skill sets of resources, there aid
in identifying the training needs for the team members.
3. Identifying the modules for which the effort estimation done in the beginning was flawed there
by having either too much or too little buffer.
4. Giving a fairly accurate prediction of additional effort and cost needed to complete the Project
or Program.
5. This model is applicable across various industry segments.
5. Bibliography
1. A Guide to the Project Management Body Of Knowledge (PMBOK® Guide), Fourth Edition
by Project Management Institute
2. Rita Mulcahy PMP Exam Preparation, Chapter on Time and Cost Management.
12 Page

13. 6. Author’s Profile:
Aditya Rawal, PMP has 12 years of experience in managing
many medium and large projects in Utility domain. Currently he
is managing a Large program for Power reforms in India.
Email: aditya.rawal@tcs.com; adityarawal@gmail.com
13 Page