Earned Value Management in an agile context

Earned Value Management (EVM), also known as Earned Value Analysis (EVA), is based on results planning, where planned costs are assigned to each partial deliverable.

After acceptance by the customer (customer sign‑off; Site Acceptance Test) of a planned deliverable and once the related actual costs have been determined, the Cost Performance Indicator can be calculated early on (simplified: deliverable‑based CPI = ∑planned costs / ∑actual costs). If the CPI drops below 1, corrective action can be taken immediately.

Prerequisites and challenges

Prerequisite: my project deliverables are defined in sufficient detail. In agile work, this may mean that planned deliverables need to be changed—or even removed— and that other results should be delivered instead.

The risk: the baseline plan becomes obsolete due to agile changes. As a result, the initial, precise assignment of planned to actual costs can no longer be used, and the CPI is no longer meaningful. If the project goes off track, negative trends may not be recognized in time.

The role of the project manager

As a project manager, I am responsible for the business and technical success of my projects. How do I organize controlling so that deviations can be identified reliably and in a timely manner?

What needs to be set up so that, despite changes to planned deliverables, EVM can still be applied and the CPI can still be calculated?

Proposal: introducing Points of Profit (PoP)

The following approach is relatively easy to implement, but it requires a mutual agreement with the customer regarding the project deliverables.

  1. Introduce a unit of measure: Points of Profit (PoP). PoP expresses the absolute contribution a deliverable makes to the overall result.
  2. Define the project roadmap: Which results are to be produced, and how (e.g., customer collaboration)?
  3. Define result types: For each result type, concrete, accept‑able deliverables and their corresponding PoP are agreed—so‑called PoP sets.

Examples of PoP sets in software development

  • User story / specification: 30 PoP per instance (initially 30 instances agreed)
  • Implemented interface: 100 PoP
  • Information object (mapped in software): 50 PoP
  • Workflow function: 20 PoP
  • Sprint review with the customer (partial acceptance): 15 PoP
  • Steering committee incl. preparation and follow‑up: 30 PoP
  • Remove a deliverable: 3 PoP (documentation required)
  • Customer training: 5 PoP
  • Extend the user concept: 8 PoP
  • Additional PoP sets: QA, tests, optimization, documentation, etc.

Implementation steps

  1. List and sum up the PoP sets defined at project start.
  2. Divide the project budget by the total PoP to obtain the project price per PoP.
  3. Create an Evaluated Results List (ERL) containing all deliverables and their PoP.
  4. New deliverables can then be cost‑estimated using their PoP.

If the Evaluated Results List can be continuously maintained together with the customer— i.e., adding new deliverables and PoP as needed—the project can be managed safely and transparently.

Planning and controlling

Example calculation

Initial plan: budget €5 million, 4,000 PoP → €1,250 per PoP.
Extension: 5,000 PoP → new budget €6,250,000.

Planned and actual costs are calculated using the newly agreed PoP sets. For accepted deliverables: CPI = planned costs / actual costs. This yields a performance measure and allows timely interventions.

Note: CPI should be evaluated in detail per result type, to improve the result‑type‑specific PoP estimation and to make future agile planning more accurate.

Response option: budget adjustment

It may be necessary to align within the steering committee if a result type was underestimated, and why more PoP (and therefore more production cost) must be allocated to that type.

Whether higher costs can be passed on to the customer depends on the contract clauses in place. If needed, additional sales training may be required.

Response option: optimizing project performance

Through PoP project reviews of already delivered results, management can establish a solid basis for internal cost analyses. Improvement needs for one’s own performance become visible.

This enables future project costs to be planned fairly for customers and value‑creating for the company—based on actual productivity.

Conclusion

Introducing Points of Profit (internally) enables precise controlling even as project goals change. A calculation basis aligned with the customer (“deliverable to PoP”) greatly simplifies necessary budget adjustments and creates transparency regarding performance, value, and effort in agile projects.