When we talk about "business value," and in the same sentence say Earned Value is not Business Value, therefore Earned Value is of no interest to the business, it's likely that we don't actually understand how projects are managed at the business or governance level. 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...
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) assess 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," or worse states Earned Value has no business in the business of developing software for business, 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.
