EVM per Progetti IT e Software
Applicare l'Earned Value Management a progetti IT e software è al tempo stesso più impegnativo e ricco di sfumature rispetto all'edilizia. Il lavoro software è astratto, i requisiti possono cambiare a metà progetto e misurare la "percentuale completata" di una feature è intrinsecamente soggettivo. Tuttavia, con i giusti adattamenti, l'EVM fornisce un valore enorme per la gestione dei programmi IT e per comunicare lo stato del budget e della schedulazione agli stakeholder non tecnici.
La Sfida Centrale: Misurare l'Earned Value nel Software
Nelle costruzioni puoi misurare il progresso fisico (metri cubi versati, metri posati). Nel software, stai misurando un lavoro invisibile. I tre approcci più comuni sono:
1. Story Point (Agile EVM)
In ambienti Scrum o Kanban, i team stimano il lavoro in story point. Puoi costruire l'EVM su questa base:
- BAC = Story point totali × costo medio per story point
- PV = Story point pianificati per il completamento entro questo sprint
- EV = Story point effettivamente completati × costo medio per story point
- AC = Costi effettivi del team (stipendi, infrastrutture, licenze) per il periodo
Questo approccio accredita le storie come "fatte" solo quando soddisfano la Definition of Done del team — prevenendo la trappola del "completato al 90%".
2. EVM Basato su Milestone (Waterfall)
Per progetti waterfall o a gate, assegna pesi di budget alle milestone (es. Requisiti = 15%, Design = 20%, Sviluppo = 40%, Testing = 20%, Deployment = 5%). L'Earned Value viene accreditato solo quando ciascuna milestone è completamente terminata e accettata.
3. Pacchetti di Lavoro Ponderati
Suddividi il software in moduli funzionali (autenticazione, reportistica, API, UI). Stima costo e durata per ciascuno. Traccia il completamento a livello di modulo. Questo è l'approccio EVM più tradizionale, adatto ai contratti IT a prezzo fisso.
Esempio Pratico: Progetto di Sviluppo Software
Un progetto di sviluppo di un CRM personalizzato: BAC = $400.000, 8 sprint (16 settimane). Allo sprint 4 (settimana 8):
- Story point totali: 800. Costo medio per story point: $500.
- Story point pianificati entro lo sprint 4: 400. PV = 400 × $500 = $200.000
- Story point effettivamente completati: 320. EV = 320 × $500 = $160.000
- Costo effettivo (stipendi del team + infrastruttura): AC = $195.000
SPI = EV ÷ PV = 160.000 ÷ 200.000 = 0.800 (20% in ritardo sul piano)
EAC = BAC ÷ CPI = 400.000 ÷ 0.821 = $487.211
VAC = 400.000 − 487.211 = −$87.211
EVM e Agile: Obiezioni Comuni
| Obiezione | Risposta |
|---|---|
| "L'Agile non ha un ambito fisso" | L'EVM funziona con un backlog prioritizzato — il BAC rappresenta l'ambito di rilascio concordato, non l'intero backlog di prodotto |
| "I requisiti cambiano ogni sprint" | Usa un processo di controllo delle modifiche. Le modifiche approvate all'ambito aggiornano il BAC. Le modifiche non pianificate sono varianze da indagare. |
| "La velocity in story point è più utile" | La velocity è ottima per il team; l'EVM fornisce la visione finanziaria necessaria per sponsor ed esecutivi. |
| "Noi non facciamo stime in anticipo" | L'EVM richiede una baseline. Anche le storie dimensionate in modo relativo possono formare una base se valutate con coerenza. |
Consigli Pratici per i Project Manager IT
- Imposta il tuo BAC prima dello sprint, non dopo: La baseline deve essere stabile affinché l'EVM sia significativo.
- Conta solo lo 0% o il 100% per le storie in corso: Evita i crediti parziali; gonfiano l'EV e mascherano il rischio sulla schedulazione.
- Monitora i trend del CPI settimanalmente: I progetti software si muovono velocemente. Report EVM mensili potrebbero cogliere i problemi troppo tardi.
- Separa il BAC dell'infrastruttura/operazioni da quello dello sviluppo: I costi dell'infrastruttura hanno driver diversi e andrebbero tracciati separatamente.
- Usa l'EVM a livello di programma: Se hai più team Agile, aggrega i loro dati EV/AC a livello di programma per i report direzionali.