EVM för IT- och mjukvaruprojekt
Att tillämpa Earned Value Management på IT- och mjukvaruprojekt är både mer utmanande och mer nyanserat än att tillämpa det på byggprojekt. Mjukvaruarbete är abstrakt, kraven kan ändras mitt i projektet och att mäta "procent färdigt" av en funktion är i sig subjektivt. Med rätt anpassningar ger EVM dock ett enormt värde för programhantering inom IT och för att kommunicera budget- och tidplansstatus till icke-tekniska intressenter.
Kärnutmaningen: Att mäta Earned Value i mjukvara
Inom bygg kan du mäta fysiska framsteg (gjutna kubikmeter, lagda meter). Inom mjukvara mäter du osynligt arbete. De tre vanligaste metoderna:
1. Story Points (Agil EVM)
I Scrum- eller Kanban-miljöer uppskattar team arbetet i story points. Du kan bygga EVM ovanpå detta:
- BAC = Totala story points × genomsnittlig kostnad per story point
- PV = Story points planerade att vara klara vid denna sprint
- EV = Faktiskt slutförda story points × genomsnittlig kostnad per story point
- AC = Faktiska teamkostnader (löner, infrastruktur, licenser) för perioden
Denna metod ger endast kredit till berättelser som "klara" (done) när de uppfyller teamets Definition of Done — vilket förhindrar fällan med "90 % färdigt".
2. Milstolpebaserad EVM (Vattenfall)
För vattenfallsprojekt eller fasstyrda projekt, tilldela budgetvikter till milstolpar (t.ex. Krav = 15 %, Design = 20 %, Utveckling = 40 %, Testning = 20 %, Driftsättning = 5 %). Earned Value krediteras först när varje milstolpe är helt slutförd och accepterad.
3. Viktade arbetspaket
Dela upp mjukvaran i funktionella moduler (autentisering, rapportering, API, användargränssnitt). Uppskatta kostnad och varaktighet för varje. Spåra färdigställande på modulnivå. Detta är den mest traditionella EVM-metoden, lämplig för IT-kontrakt med fast pris.
Exempel: Projekt för mjukvaruutveckling
Ett projekt för utveckling av ett anpassat CRM: BAC = $400 000, 8 sprintar (16 veckor). Vid sprint 4 (vecka 8):
- Totala story points: 800. Genomsnittlig kostnad per story point: $500.
- Story points planerade till sprint 4: 400. PV = 400 × $500 = $200 000
- Faktiskt färdigställda story points: 320. EV = 320 × $500 = $160 000
- Faktisk kostnad (teamlöner + infrastruktur): AC = $195 000
SPI = EV ÷ PV = 160 000 ÷ 200 000 = 0,800 (20 % efter tidsplanen)
EAC = BAC ÷ CPI = 400 000 ÷ 0,821 = $487 211
VAC = 400 000 − 487 211 = −$87 211
EVM och agila metoder: Vanliga invändningar
| Invändning | Svar |
|---|---|
| "Agilt utveckling har ingen fast omfattning" | EVM fungerar med en prioriterad backlog — BAC representerar den överenskomna release-omfattningen, inte hela produktbacklogen |
| "Kraven ändras varje sprint" | Använd en process för ändringskontroll. Godkända ändringar i omfattningen uppdaterar BAC. Oplanerade ändringar är avvikelser som ska undersökas. |
| "Hastighet (velocity) för story points är mer användbar" | Velocity är bra för teamet; EVM ger den ekonomiska överblicken som sponsorer och ledning behöver. |
| "Vi uppskattar inte i förväg" | EVM kräver en baslinje (baseline). Även relativt storleksbestämda berättelser kan utgöra en grund om de bedöms konsekvent. |
Praktiska tips för IT-projektledare
- Sätt ditt BAC före sprinten, inte efter: Baslinjen måste vara stabil för att EVM ska vara meningsfullt.
- Räkna endast 0 % eller 100 % för pågående berättelser: Undvik partiell kredit; det överdriver EV och döljer tidplanerisker.
- Spåra CPI-trender veckovis: Mjukvaruprojekt går snabbt. Månatlig EVM-rapportering kan upptäcka problem för sent.
- Separera BAC för infrastruktur/drift från utveckling: Infrastrukturkostnader har andra kostnadsdrivare och bör spåras separat.
- Använd EVM på programnivå: Om du har flera agila team, aggregera deras EV/AC-data på programnivå för ledningsrapportering.