EVM for IT and Software Projects
Applying Earned Value Management to IT and software projects is both more challenging and more nuanced than applying it to construction. Software work is abstract, requirements can change mid-project, and measuring "percent complete" of a feature is inherently subjective. Yet with the right adaptations, EVM provides tremendous value for IT program management and for communicating budget and schedule status to non-technical stakeholders.
The Core Challenge: Measuring Earned Value in Software
In construction, you can measure physical progress (cubic meters poured, meters laid). In software, you are measuring invisible work. The three most common approaches:
1. Story Points (Agile EVM)
In Scrum or Kanban environments, teams estimate work in story points. You can build EVM on top of this:
- BAC = Total story points × average cost per story point
- PV = Story points planned for completion by this sprint
- EV = Story points actually completed × average cost per story point
- AC = Actual team costs (salaries, infrastructure, licenses) for the period
This approach only credits stories as "done" when they meet the team's Definition of Done — preventing the "90% complete" trap.
2. Milestone-Based EVM (Waterfall)
For waterfall or phase-gate projects, assign budget weights to milestones (e.g., Requirements = 15%, Design = 20%, Development = 40%, Testing = 20%, Deployment = 5%). Earned Value is credited only when each milestone is fully completed and accepted.
3. Weighted Work Packages
Break the software into functional modules (authentication, reporting, API, UI). Estimate cost and duration for each. Track completion at the module level. This is the most traditional EVM approach, suitable for fixed-price IT contracts.
Worked Example: Software Development Project
A custom CRM development project: BAC = $400,000, 8 sprints (16 weeks). At sprint 4 (week 8):
- Total story points: 800. Average cost per story point: $500.
- Story points planned by sprint 4: 400. PV = 400 × $500 = $200,000
- Story points actually completed: 320. EV = 320 × $500 = $160,000
- Actual cost (team salaries + infrastructure): AC = $195,000
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800 (20% behind plan)
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
EVM and Agile: Common Objections
| Objection | Response |
|---|---|
| "Agile doesn't have a fixed scope" | EVM works with a prioritized backlog — the BAC represents the agreed release scope, not the entire product backlog |
| "Requirements change every sprint" | Use a change control process. Approved scope changes update the BAC. Unplanned changes are variances to investigate. |
| "Story point velocity is more useful" | Velocity is great for the team; EVM provides the financial view needed by sponsors and executives. |
| "We don't estimate in advance" | EVM requires a baseline. Even relative-sized stories can form a basis if consistently sized. |
Practical Tips for IT Project Managers
- Set your BAC before the sprint, not after: The baseline must be stable for EVM to be meaningful.
- Only count 0% or 100% for in-progress stories: Avoid partial credit; it inflates EV and masks schedule risk.
- Track CPI trends weekly: Software projects move fast. Monthly EVM reporting may catch problems too late.
- Separate BAC for infrastructure/ops vs. development: Infrastructure costs have different cost drivers and should be tracked separately.
- Use EVM at program level: If you have multiple Agile teams, aggregate their EV/AC data at the program level for executive reporting.