EVM for it- og softwareprojekter
At anvende Earned Value Management på it- og softwareprojekter er både mere udfordrende og mere nuanceret end at anvende det på byggeriet. Softwarearbejde er abstrakt, krav kan ændre sig midt i projektet, og måling af "procent færdig" for en funktion er i sagens natur subjektivt. Alligevel giver EVM, med de rette tilpasninger, enorm værdi for it-programstyring og for at kommunikere budget- og tidsplanstatus til ikke-tekniske interessenter.
Den centrale udfordring: Måling af Earned Value i software
Inden for byggeriet kan du måle fysiske fremskridt (støbte kubikmeter, lagte meter). I software måler du usynligt arbejde. De tre mest almindelige tilgange:
1. Story Points (Agil EVM)
I Scrum- eller Kanban-miljøer estimerer teams arbejde i story points. Du kan bygge EVM oven på dette:
- BAC = Samlet antal story points × gennemsnitlige omkostninger pr. story point
- PV = Story points planlagt til færdiggørelse i denne sprint
- EV = Faktisk færdiggjorte story points × gennemsnitlige omkostninger pr. story point
- AC = Faktiske teamomkostninger (lønninger, infrastruktur, licenser) for perioden
Denne tilgang giver kun historier status som "færdige", når de opfylder teamets definition af færdig (Definition of Done) — hvilket forhindrer fælden med "90 % færdig".
2. Milepælsbaseret EVM (Vandfald)
For vandfalds- eller faseopdelte projekter tildeles budgetvægte til milepæle (f.eks. Krav = 15 %, Design = 20 %, Udvikling = 40 %, Test = 20 %, Implementering = 5 %). Earned Value krediteres først, når hver milepæl er fuldt ud færdiggjort og accepteret.
3. Vægtede arbejdspakker
Opdel softwaren i funktionelle moduler (autentificering, rapportering, API, brugergrænseflade). Estimer omkostninger og varighed for hver. Spor færdiggørelse på modulniveau. Dette er den mest traditionelle EVM-tilgang, der er velegnet til fastpris it-kontrakter.
Beregnet eksempel: Softwareudviklingsprojekt
Et projekt til udvikling af et tilpasset CRM: BAC = $400.000, 8 sprints (16 uger). Ved sprint 4 (uge 8):
- Samlet antal story points: 800. Gennemsnitlig pris pr. story point: $500.
- Story points planlagt inden sprint 4: 400. PV = 400 × $500 = $200.000
- Faktisk færdiggjorte story points: 320. EV = 320 × $500 = $160.000
- Faktiske omkostninger (teamlønninger + infrastruktur): AC = $195.000
SPI = EV ÷ PV = 160.000 ÷ 200.000 = 0,800 (20 % bagefter planen)
EAC = BAC ÷ CPI = 400.000 ÷ 0,821 = $487.211
VAC = 400.000 − 487.211 = −$87.211
EVM og Agile: Almindelige indvendinger
| Indvending | Svar |
|---|---|
| "Agile har ikke et fastlagt omfang" | EVM arbejder med en prioriteret backlog — BAC repræsenterer det aftalte udgivelsesomfang, ikke hele produktets backlog |
| "Krav ændres hver sprint" | Brug en ændringskontrolproces. Godkendte omfangsændringer opdaterer BAC. Uplanlagte ændringer er afvigelser, der skal undersøges. |
| "Story point velocity er mere nyttig" | Velocity er fantastisk for teamet; EVM giver det økonomiske overblik, der er nødvendigt for sponsorer og ledelsen. |
| "Vi estimerer ikke på forhånd" | EVM kræver en baseline. Selv relativt størrelsessatte historier kan danne grundlag, hvis de er konsekvent vurderet. |
Praktiske tips til it-projektledere
- Sæt din BAC før sprinten, ikke efter: Baseline skal være stabil, for at EVM er meningsfuld.
- Tæl kun 0 % eller 100 % for historier, der er i gang: Undgå delvis kreditering; det overvurderer EV og skjuler tidsplansrisici.
- Spor CPI-tendenser ugentligt: Softwareprojekter bevæger sig hurtigt. Månedlig EVM-rapportering kan fange problemer for sent.
- Adskil BAC for infrastruktur/drift vs. udvikling: Infrastrukturomkostninger har forskellige omkostningsdrivere og bør spores separat.
- Brug EVM på programniveau: Hvis du har flere Agile-teams, kan du samle deres EV/AC-data på programniveau til ledelsesrapportering.