EVM for IT- og programvareprosjekter
Å bruke Earned Value Management i IT- og programvareprosjekter er både mer utfordrende og mer nyansert enn i byggebransjen. Programvarearbeid er abstrakt, krav kan endres midt i prosjektet, og å måle "prosent fullført" av en funksjon er iboende subjektivt. Likevel gir EVM, med de rette tilpasningene, enorm verdi for styring av IT-programmer og for å kommunisere budsjett- og tidsplanstatus til ikke-tekniske interessenter.
Kjerneutfordringen: Å måle Earned Value i programvare
I byggebransjen kan du måle fysisk fremdrift. I programvare måler du usynlig arbeid. De tre vanligste tilnærmingene:
1. Story Points (Agile EVM)
I Scrum- eller Kanban-miljøer estimerer team arbeid i story points. Du kan bygge EVM på toppen av dette:
- BAC = Totale story points × gjennomsnittlig kostnad per story point
- PV = Story points planlagt for fullføring innen denne sprinten
- EV = Story points faktisk fullført × gjennomsnittlig kostnad per story point
- AC = Faktiske teamkostnader (lønn, infrastruktur, lisenser) for perioden
Denne tilnærmingen krediterer kun historier som "ferdige" når de oppfyller teamets Definition of Done — og forhindrer dermed "90% fullført"-fellen.
2. Milepælsbasert EVM (Fossefall)
For fossefalls- eller fase-port-prosjekter, tildel budsjettvekter til milepæler (f.eks. Krav = 15%, Design = 20%, Utvikling = 40%, Testing = 20%, Utrulling = 5%). Earned Value krediteres kun når hver milepæl er fullstendig fullført og akseptert.
3. Vektede arbeidspakker
Del programvaren inn i funksjonelle moduler (autentisering, rapportering, API, UI). Estimer kostnad og varighet for hver. Spor fullføring på modulnivå. Dette er den mest tradisjonelle EVM-tilnærmingen, egnet for IT-kontrakter med fast pris.
Gjennomgått eksempel: Programvareutviklingsprosjekt
Et tilpasset CRM-utviklingsprosjekt: BAC = $400 000, 8 sprinter (16 uker). Ved sprint 4 (uke 8):
- Totale story points: 800. Gjennomsnittlig kostnad per story point: $500.
- Story points planlagt innen sprint 4: 400. PV = 400 × $500 = $200 000
- Story points faktisk fullført: 320. EV = 320 × $500 = $160 000
- Faktisk kostnad (teamlønn + infrastruktur): AC = $195 000
SPI = EV ÷ PV = 160 000 ÷ 200 000 = 0,800 (20% bak plan)
EAC = BAC ÷ CPI = 400 000 ÷ 0,821 = $487 211
VAC = 400 000 − 487 211 = −$87 211
EVM og Agile: Vanlige innvendinger
| Innvending | Svar |
|---|---|
| "Agile har ikke et fast omfang" | EVM fungerer med en prioritert backlog — BAC representerer det avtalte lanseringsomfanget, ikke hele produkt-backlogen |
| "Krav endres hver sprint" | Bruk en endringskontrollprosess. Godkjente omfangsendringer oppdaterer BAC. Uplanlagte endringer er avvik som må undersøkes. |
| "Story point-hastighet er mer nyttig" | Hastighet er flott for teamet; EVM gir den økonomiske oversikten som sponsorer og ledere trenger. |
| "Vi estimerer ikke på forhånd" | EVM krever en baseline. Selv relativt størrelsesbestemte historier kan danne et grunnlag hvis de størrelsesbestemmes konsekvent. |
Praktiske tips for IT-prosjektledere
- Sett BAC før sprinten, ikke etter: Baselinen må være stabil for at EVM skal være meningsfylt.
- Tell bare 0% eller 100% for pågående historier: Unngå delvis kreditt; det blåser opp EV og skjuler tidsplanrisiko.
- Spor CPI-trender ukentlig: Programvareprosjekter beveger seg raskt. Månedlig EVM-rapportering kan fange opp problemer for sent.
- Separat BAC for infrastruktur/drift vs. utvikling: Infrastrukturkostnader har andre kostnadsdrivere og bør spores separat.
- Bruk EVM på programnivå: Hvis du har flere Agile-team, samle deres EV/AC-data på programnivå for ledelsesrapportering.