when we talk about business value and in the same sentence say Earned Value, we're speaking about the same word, but with two different meaning.

1. Connecting Business Value with Earned Value It Increase the Probability of Success
When we talk about "business value," and in the same sentence say Earned Value we are many
times speaking about the same word, but with two different meanings. Both business facing and
project facing measures are needed for success.
The "values" of interest to the business should be connected to the "business case." They need to
answer the question why are we doing this project. While it is necessary to have a business case
and hopefully define what business value means, it is far from sufficient for success of a business
system project.
This is a common lament of those on the business side when encountering project managers. And
even more so when encountering agile software developers. Both the project managers and the
software developers have their "units of measure." These units are meaningful to the members of
their domain - or at least we should assume so.
 Earned Value project managers speak in Cost and Schedule measures. Of course both
cost and schedule in Earned Value is measured in "money." What does it mean to be
$125,000 behind schedule? How much is an hour worth?
 Agile software developers speak in "story points." How many story points are there in the
Estimate to Complete? They can say. They can say how many story points per iteration
and provide an approximate forecast of when "done" will arrive. But how much will it
cost to complete - the Estimate At Completion (EAC) of the financial view of the
project?
There is a better starting point in trying to connect the project facing measures with the business
facing measures of performance - the achievement of business value. This starting point is the
Systems Engineering paradigm. This paradigm has "measures" that are connected to the
participants. Here they are...

2. These measures define meaningful units that can be used by the decision makers to make
decisions.
 Measures of Effectiveness (MoE) are stated in units meaningful to the buyer. They focus
on capabilities independent of any technical implementation. They are connected to the
mission success. These are operational measures of success that are closely related to the
achievements of the mission or operational objectives evaluated in the operational
environment, under a specific set of conditions. The MoE's belong to the customer.
 Measures of Performance (MoP) are attributes that assure the system has the capability
to perform. They are an assessment of the system to ensure it meets design requirements
to satisfy the MoE. These measures characterize physical or functional attributes relating
to the system operation, measured or estimated under specific conditions. MoP’s belong
to the Program – Developed by the Systems Engineer, Measured By CAMs, and
Analyzed by Program Planning & Control function.
 Key Performance Parameters (KPP) have a threshold or objective value. They
characterize the major drivers of performance. They are considered Critical to Customer
(CTC). They represent the capabilities and characteristics so significant that failure to
meet them can be cause for reevaluation, reassessing, or termination of the program. The
acquirer defines the KPPs during the operational concept development – KPPs say what
DONE looks lik.
 Technical Performance Measures (TPM) assesses design progress, Define compliance
to performance requirements. TPMs identify technical risk. They are limited to critical
thresholds and include projected performance. They are the attributes that determine how
well a system or system element is satisfying or expected to satisfy a technical
requirement or goal.
So when someone speaks about "business value," ask a few questions just to clarify
understanding:
 What are the units of measure we're using in this discussion? Without shared units of
measure it's just blather.
 How are you assigning these units of measure to specific actionable outcomes that need
to be made by the decision makers? In other words how can I know if the project is
getting better or getting worse from my specific point of view?
 When you say "value" what are the units of measure, how did you derive these, are they
in fact meaningful to someone outside your domain of action (developer, cost analyst,
CIO)?
Now you may not be interested in Estimates At Completion (EAC), Estimates to Complete
(ETC), MoP's, MoE's, TPM's and KPP's. But someone better be interested if you're spending
other people's money.