EVM pro IT a softwarové projekty
Aplikace Earned Value Management na IT a softwarové projekty je jak náročnější, tak i více nuancovaná než její aplikace na stavebnictví. Práce na softwaru je abstraktní, požadavky se mohou během projektu měnit a měření „procenta dokončení“ u dané funkce je z podstaty subjektivní. Nicméně se správnými úpravami poskytuje EVM obrovskou hodnotu pro řízení IT programů a pro komunikaci stavu rozpočtu a harmonogramu netechnickým zúčastněným stranám.
Hlavní výzva: Měření Earned Value u softwaru
Ve stavebnictví můžete měřit fyzický pokrok (vylité metry krychlové, položené metry). V softwaru měříte neviditelnou práci. Tři nejběžnější přístupy:
1. Story Points (Agilní EVM)
V prostředích Scrum nebo Kanban týmy odhadují práci ve story points. EVM můžete postavit na tomto základě:
- BAC = Celkový počet story points × průměrné náklady na jeden story point
- PV = Story points naplánované k dokončení do tohoto sprintu
- EV = Skutečně dokončené story points × průměrné náklady na jeden story point
- AC = Skutečné náklady týmu (platy, infrastruktura, licence) za dané období
Tento přístup připisuje příběhům status „hotovo“ pouze tehdy, když splňují definici hotového (Definition of Done) týmu — čímž se zabrání pasti „90 % hotovo“.
2. EVM založené na milnících (Waterfall)
Pro projekty vodopádového typu nebo s fázovým schvalováním přiřaďte milníkům váhu rozpočtu (např. Požadavky = 15 %, Návrh = 20 %, Vývoj = 40 %, Testování = 20 %, Nasazení = 5 %). Earned Value je připsána, až když je každý milník plně dokončen a přijat.
3. Vážené pracovní balíčky
Rozdělte software na funkční moduly (autentizace, reportování, API, uživatelské rozhraní). Odhadněte náklady a trvání pro každý z nich. Sledujte dokončení na úrovni modulů. Toto je nejtradičnější přístup k EVM, vhodný pro IT smlouvy s pevnou cenou.
Zpracovaný příklad: Projekt vývoje softwaru
Projekt vývoje vlastního CRM: BAC = 400 000 $, 8 sprintů (16 týdnů). Ve 4. sprintu (8. týden):
- Celkový počet story points: 800. Průměrná cena za story point: 500 $.
- Story points naplánované do 4. sprintu: 400. PV = 400 × 500 $ = 200 000 $
- Skutečně dokončené story points: 320. EV = 320 × 500 $ = 160 000 $
- Skutečné náklady (platy týmu + infrastruktura): AC = 195 000 $
SPI = EV ÷ PV = 160 000 ÷ 200 000 = 0,800 (20% zpoždění za plánem)
EAC = BAC ÷ CPI = 400 000 ÷ 0,821 = 487 211 $
VAC = 400 000 − 487 211 = −87 211 $
EVM a Agile: Běžné námitky
| Námitka | Odpověď |
|---|---|
| "Agile nemá pevný rozsah" | EVM pracuje s prioritizovaným backlogem — BAC představuje sjednaný rozsah vydání, nikoliv celý produktový backlog |
| "Požadavky se mění každý sprint" | Použijte proces kontroly změn. Schválené změny rozsahu aktualizují BAC. Neplánované změny jsou odchylky k prošetření. |
| "Rychlost (velocity) story points je užitečnější" | Velocity je skvělá pro tým; EVM poskytuje finanční pohled potřebný pro sponzory a vedení. |
| "Neodhadujeme dopředu" | EVM vyžaduje výchozí plán (baseline). Dokonce i relativní velikosti příběhů mohou tvořit základ, pokud jsou dimenzovány konzistentně. |
Praktické tipy pro IT projektové manažery
- Nastavte BAC před sprintem, ne po něm: Výchozí plán musí být stabilní, aby mělo EVM smysl.
- Započítejte pouze 0 % nebo 100 % u probíhajících příběhů: Vyhněte se částečnému zápočtu; nadhodnocuje EV a maskuje riziko zpoždění.
- Sledujte trendy CPI každý týden: Softwarové projekty postupují rychle. Měsíční reporting EVM může odhalit problémy příliš pozdě.
- Oddělte BAC pro infrastrukturu/ops a pro vývoj: Náklady na infrastrukturu mají jiné nákladové činitele a měly by být sledovány samostatně.
- Používejte EVM na úrovni programu: Pokud máte více agilních týmů, agregujte jejich EV/AC data na úrovni programu pro reporting vedení.