Na obzoru je tsunami katastrof IT projektů

Nikdy není populární postoj v organizaci být prognostikem katastrof a neúspěchu, takže tento dopis píšu s plným pochopením, že jeho obsah bude hluchý a potenciální přínosy mých rad budou nalezeny na hromadě „Kéž bychom měli…“ Existuje tsunami projektových katastrof, které se rychle stěhují směrem k pobřeží podniku a nelze udělat mnoho k tomu, jak ho zastavit.

Typ projektových katastrof, o kterém mluvím, nejsou tím typem, který je nad limit rozpočtu nebo zpožděný, ale spíše jde o velkolepá selhání, která narušují dodavatelské řetězce, zdržují vykazování financí a vyhazují do vzduchu kariéry zdánlivě kompetentních manažerů. Toto jsou typy selhání, které vznikají, když podniky „uvedou do provozu“ implementaci, která bude při zpětném pohledu považována za provedenou neuváženým způsobem.

Pište pro CIO Business World

Máte dobré nápady, máte co říct? Chcete se podělit o své znalosti se čtenáři CIO BW?

Je tu ideální příležitost. V redakci neustále hledáme externí autory, kteří rozšíří náš záběr. Nabízíme možnost publikací zajímavých článků nejen na webu, ale také v našem tištěném magazínu. Pokud máte zájem, ozvěte se šéfredaktorovi na e-mail: radan.dolejs@iinfo.cz

Čtyři předzvěsti zkázy

Proč jsem tak přesvědčen, že mnoho projektů je na kolizním kurzu s neúspěchem? Zvažte následující:

• Dvojnásobek objemu. Mezi květnem a zářím letošního roku je v provozu dvojnásobný počet velkých projektů, které mají být spuštěny ve srovnání s běžným rokem. Když COVID na začátku roku 2020 všechno zastavil, pozastavilo i mnoho společností své velké transformační programy s podporou IT. Začátkem roku 2021 se přehrada protrhla a velké programy, které měly začít v roce 2020, byly spuštěny v roce 2021. Zároveň tak učinily společnosti, které původně plánovaly spustit programy v roce 2021. Voila! To znamená dvojnásobný počet potenciálních katastrof projektu. S počátečními termíny dodání v průměru 12–18 měsíců pro hlavní iniciativy jsou karty rozdány.
• Zkreslení aktuálnosti. Kdy jste naposledy četli o selhání spuštění velkého projektu? Projekty jako Select Comfort, National Grid, Cover Oregon nebo Los Angeles Department of Water and Power (LADWP) byly několik let mimo radar – dost dlouho na to, aby vymizely z paměti členů vedení podniků. Organizační arogance je mocná síla, která často vyvažuje realitu reálné možnosti katastrof. Když nejsou žádné zprávy o katastrofách, potenciální hrozba mizí. Existuje důvod, proč všichni jezdíme opatrněji poté, co jsme viděli dopravní nehodu.
• Talentové prázdno. Téměř všechny hlavní katastrofy při uvádění projektů do provozu lze vysledovat zpět k nedostatku zkušeností ze strany vedoucích členů projektového týmu. Schopnost zjišťovat a komunikovat rizika je samozřejmě prvořadá pro jejich zmírnění. S dvojnásobným počtem projektů ve hře byla schopnost systémových integrátorů (SI) přivést vysoce kvalifikované talenty do všech programů značně snížena. Spojte to s mírou „velké rezignace“ a mírou opotřebení, které se za posledních 6 měsíců zdvojnásobily, a uvidíte, že úroveň situačního povědomí o těchto programech se dramaticky snížila.
• Netestované metody. Během pandemie jsme viděli mnoho projektů, které se potýkaly s problémy v oblastech testování integrovaných systémů. Zdroj zásahu do produktivity je často vysledován v chybějícím společném umístění projektových týmů. Bez toho, aby byli členové týmu spolu, se tak rychle neučí od svých sousedů a tipy a triky se tak snadno nepředávají. Nyní se rychle přesuňte do doby po nasazení a zvažte potenciální dopad na tisíce uživatelů, kteří nemusí mít superuživatele na dalším křesle, aby je provedli spuštěním. Není důvod se domnívat, že stejné problémy, jaké jsme viděli při testování, budou po nasazení zázračně vyléčeny.

Jak se vyhnout IT katastrofám

Existují způsoby, jak se vyhnout tsunami katastrof? Souhrnná odpověď je bohužel ne. Kostka byla vržena. Existují taktiky, které lze implementovat na jednotlivé programy, aby se zabránilo katastrofě? Naštěstí je tato odpověď ano. Zde je několik jednoduchých doporučení:

• Uskutečněte to. Požádejte svého SI, aby sestavil prezentaci o zkušenostech získaných při velkých programových katastrofách. Není třeba, abyste byli ‚poslem, kterého zastřelí na pláži.‘ Dostaňte tuto prezentaci k řídícímu výboru dříve než později, abyste ukázali, že podnikáte vhodná opatření na ochranu podniku.
• Kritéria pro spuštění stanovte v raných fázích. Příliš mnoho programů tvoří vstupní kritéria 2–3 měsíce před cílovým spuštěním. V tomto případě se kritériem stává „Co můžeme dosáhnout před uvedením do provozu?“ spíše než „Kde bychom měli být?“ To platí zejména pro projekty, které jsou pod rozpočtovým tlakem.
• Nezávislý pohled. „Přejít naživo“ nebo „horečka na vrcholu“ je skutečná – zeptejte se kterékoli z rodin těch, kteří zahynuli při pokusu dostat se na vrchol hory. Dobrý úsudek je snadno zatemněn podhodnocenými odhady nákladů a nezajištěným plánováním nejlepšího scénáře. Nezávislý pohled může být velmi střízlivý.

Uvědomuji si, že tento příspěvek je pravděpodobně trochu tlumícím lékem nebo může být vnímán jako prostá senzacechtivost, ale pokud rozpohybuje byť jen jeden projekt, aby se předešlo katastrofě, stálo to za to!