Kapitola 18: Změny a rozrůstání rozsahu

Rozsah roste, i když to nikdo nechce

Plíživé rozrůstání rozsahu (scope creep) má obvykle obyčejné příčiny:

• nedotažená analýza a nejasné hranice rozsahu,
• více lidí s rozdílnými požadavky na straně zákazníka a chybějící vlastník produktu,
• změna legislativy během projektu,
• měnící se priority vedení. Výzkum DORA ukázal, že nestabilní priority snižují produktivitu týmu a zvyšují riziko vyhoření DORA, 2024.

Změny samy o sobě nejsou chyba. Během vývoje se vždy ukáže něco nového. Chybou jsou změny neřízené: domluvené na chodbě, neoceněné a nikde nezapsané. Každá zvlášť je drobnost, dohromady z nich vznikne etapa, kterou nikdo neobjednal. Většině příčin předejdete analýzou se seznamem toho, co v rozsahu není (kapitola 14), a jedním vlastníkem produktu (kapitola 16).

Změnové řízení: pět kroků místo „to tam ještě dejte“

Změnové řízení zní byrokraticky, ale jde jen o předem dohodnutý postup. Platí pro firmu i úřad a vejde se na jednu stranu smlouvy.

Dodržujte ještě dvě pravidla. Zaprvé, oprava vady není změna: vadu dodavatel opravuje zdarma v záruce, změnu si nechá zaplatit a smlouva má obojí jasně oddělit (kapitola 11). Zadruhé, vícepráce bez podepsaného změnového listu se neplatí. Sjednejte to ve smlouvě, pak souhlas e-mailem nebo „ústně na demu“ nestačí.

Proces se vyplatí u každého cenového modelu (kapitola 10). U fixní ceny chrání rozpočet před vícepracemi. U placení podle odpracovaného času se změna sice nefakturuje zvlášť, ale čerpá dohodnutý rozpočtový strop a posouvá termín, takže o ní má rozhodnout stejný člověk se stejnými podklady. Zpozorněte, když:

• změnových listů je hodně a každý je malý,
• vícepráce se odsouhlasují e-mailem nebo telefonem,
• nikdo neumí říct, kolik z rezervy zbývá.

ZMĚNOVÝ POŽADAVEK č.: ZP-___        Datum: ____
Kdo žádá (jméno, útvar): ____
Popis změny (co má systém dělat jinak): ____
Důvod (proč, co se stane, když to neuděláme): ____
Typ: [ ] nová funkce  [ ] úprava funkce  [ ] změna legislativy  [ ] oprava vady (není změna!)
Priorita (MoSCoW): ____

--- vyplní dodavatel (do 5 pracovních dnů) ---
Odhad pracnosti (MD) a cena (Kč bez DPH): ____
Dopad na termín (etapa, milník): ____
Dopad na jiné funkce a rizika: ____
Návrh, co z backlogu vyřadit nebo odložit: ____

--- rozhodnutí ---
[ ] schváleno  [ ] zamítnuto  [ ] odloženo do backlogu
Rozhodl (vlastník produktu / řídicí výbor), podpis, datum: ____
Čerpání rezervy po této změně (Kč a %): ____

--- jen úřad ---
Zatřídění podle § 222 odst. __ ZZVZ, odůvodnění: ____
Uveřejnění (registr smluv / profil zadavatele), datum: ____

Něco dovnitř, něco ven

Při pevném rozpočtu je hlavním nástrojem výměna požadavků. U každého změnového požadavku se ptejte, co z backlogu vypadne, aby se nová věc vešla. Funguje to jako kufr do letadla: když přibalíte boty, něco jiného zůstane doma.

Jak říct ne? Vlastník produktu potřebuje mandát a kritérium, podle kterého rozhoduje: cíl projektu a rozsah MVP. Co do MVP nepatří, neodmítá napořád, ale odkládá do backlogu na další etapu. Zpozorněte, když na rozšiřování rozsahu tlačí sám dodavatel ještě před dokončením MVP. Více práce pro dodavatele nemusí znamenat větší přínos pro vás.

Rezerva je nutná, krátké etapy jsou silnější

Rezerva není přiznání neschopnosti, ale pojistka. Orientačně počítejte s těmito hodnotami:

• dobře připravený projekt: 10–15 % rozpočtu a 15–20 % času,
• nový systém s nejasnými napojeními na jiné systémy: 20–30 % rozpočtu.

Rezervu drží zákazník, ne dodavatel, a o každém čerpání rozhoduje stejně jako o změně. U víceletého projektu nemusí stačit ani velká rezerva. Velké IT projekty překračují rozpočet v průměru o 45 % a každý rok trvání navíc zvyšuje překročení nákladů o 15 % McKinsey a Oxford, 2012. Silnější pojistkou jsou proto krátké etapy, po kterých můžete upravit plán nebo projekt ukončit. Úřad musí myslet i na smluvní možnost rezervu využít: musí ji vyhradit jako opci nebo změnu v zadávací dokumentaci.