Pokud se chcete podívat na příčiny neúspěchů projektů v mezinárodním měřítku, naleznete řadu zdrojů, které se tomu věnují. Většinou se témata neúspěchu shodují na variaci špatného řízení rizik, příliš optimistického plánování, slabého stakeholder managementu, výběru nevhodné technologie, špatného řízení rozsahu a změnových požadavků, nedostatečné komunikaci, nevhodném obsazení klíčových pozic lidmi, atp. Samozřejmě, je otázkou, jak definujete neúspěch projektu, protože kritéria se mohou různit od nedodržení termínů (které pro někoho je zásadní a pro jiného zase až tak moc ne) po překročení rozpočtu, nebo dodání něčeho úplně jiného, než co bylo v zadání. Zatímco některé neúspěchy se potichu zametou „pod koberec“ v rámci organizace, některé dostanou i prostor v médiích. Pokud jste zaznamenali určitý neúspěch na projektu a chcete mít pocit, že v tom nejste sami, můžete se při kávě začíst do Katalogu katastrof, který připravuje pro každý rok Calleam [1]. Zjistíte, že na tom zdaleka nejste tak špatně. Možná vás také zaujme soubor analýz neúspěchů projektů [2], ze kterých plyne například to, že 17% velkých IT projektů dopadne natolik špatně, že to může ohrozit samotnou další existenci firmy, nebo že 75% lidí zapojených do projektů nedoufá, že jejich projekt dopadne dobře vlivem nejasného zadání ze strany byznysu, slabého zapojení a řízení očekávání stakeholderů a významné pracnosti na předělávky.

Každý projektový manažer, který má již určité zkušenosti a svoji práci dělá poctivě, si říká, že něco takového se mu nemůže stát, rizika řídí, projektový plán umí sestavit i poslepu.... A přece…existují věci, které jsou často i mimo kompetence projektového manažera, které mohou projekt položit na lopatky. Na různě velkých projektech, v různých odvětvích, jsme posbírali (ať už v roli konzultantů, nebo projektových manažerů) zkušenosti, o které se s vámi chceme podělit. Výčet rozhodně není vyčerpávající, ale třeba zde také naleznete něco, s čím jste se již setkali.

1. Je to v podstatě hotové

S touto větou jsme se poprvé setkali zhruba před 20 lety. A od té doby ji slýcháme pravidelně. Tehdy jsme tomu uvěřili. Věřili jsem tomu, že dospělý člověk, který ji říká, má i dospělý přístup ke své práci. Neměl. Nebylo to hotové. Jak se v praxi ukazuje, věta „Je to v podstatě hotové“ může znamenat téměř cokoliv. Od toho, že chybí již pouze dopsat dokumentaci, po to, že na daném úkolu ještě ani nezačal pracovat. Jak ověřit průběžný postup prací a nebýt přitom v roli policajta, který neustále jen kontroluje?

Osvědčilo se nám rozpadnout zadání na malé části, které tvoří ucelené prvky celku. Tyto části přidělit mezi členy projektového týmu a na častých statusech (agilní denní standup nebo alespoň 1-2x týdně), kontrolovat postup prací. Doporučujeme také zapojit reálné ukázky výsledků práce, na kterých se nejlépe ověří, zda informace ze statusů se zakládají na pravdě. Pokud jako projektový manažer nemáte dostatečné technické znalosti, můžete zavést hodnocení výsledků mezi týmy navzájem. Je potřeba ale vytvořit takové prostředí, které povede ke spolupráci, nikoliv k vzájemné rivalitě. Jednotlivé pracovní týmy by si měly být vědomy toho, že pracují na společném celku, takže pokud jeden z nich nebude fungovat, jak má, ohrozí to výsledek všech. Spolupráci a zadávání práce je vhodné na středních a velkých projektech podpořit i vhodným nástrojem (Task management systém), který umožňuje projektovému manažerovi sledovat průběh prací a vytvářet reporty bez toho, aby je musel požadovat po členech týmu. Ti pak mají čas na vlastní práci. Pro ověření souladu mezi informacemi v systému a v realitě slouží právě pravidelné projektové statusy. Při plánování statusů je vhodné se zamyslet i nad jejich obsazením. Pokud jsou krátké (max. 30-60 min), strukturované a věcné, mohou dobře sloužit i pro koordinaci informací napříč týmy. Nebojte se i přizvat i zástupce byznysu jako pozorovatele. Ctěte pravidlo, že status je pro informování o stavu, na řešení konfliktů a eskalací je potřeba svolat separátní schůzku.

2. Nenahraditelný Superman

Na každém projektu existuje pan (méně často paní) Nenahraditelný. Projekt na něm stojí. Někdy jich je dokonce víc. Jediný architekt, nenahraditelný analytik, hlavní vývojář, který jako jediný rozumí tomu, jak do sebe komponenty zapadají. Prostě SUPERMAN. Projektový manažer, nebo rovnou celý delivery tým mu visí na rtech. On je tím, kdo musí vše posvětit. On jediný všechno zná. Zkuste si tedy představit, když takový Superman najednou v sobotu napíše, že odletěl na 14dní na dovolenou, protože ji má už dlouho schválenou (PM o tom samozřejmě nic neví, protože to bylo schváleno před 9 měsíci) a že mu v pátek žena položila nůž na krk (ano, každý Superman má svůj Kryptonit). Nedošlo k žádnému předání práce, zbytek týmu se pohybuje ve vakuu. Možná přemýšlíte, jestli to neudělal tak trochu schválně, aby zvýšil svoji nenahraditelnost.

Právě nenahraditelnost je jedinou kartou, na kterou Superman sází. Pro projekt je to samozřejmě obrovské riziko. Je proto potřeba začít budovat skupinu lidí, kteří budou mít sdílené know-how a bude existovat i systémová podpora pro předávání informací. Pro někoho je naprosto automatické, že provede sběr a analýzu požadavků byznysu a ty strukturovaně zdokumentuje. U jiných týmů tyto návyky chybí, a tak se právě vytváří prostor pro nenahraditelné Supermany.

Pokud Superman není ochoten začít informace sdílet, je zapotřebí rovnou, od začátku vytvářet plán B, který ho nezahrnuje. Praxe totiž ukazuje, že projekt, nebo obecně i liniový tým, se lépe vzpamatuje po řízeném odchodu Supermana, i když to s sebou může nést určitá rizika, než když časování necháte v rukou Supermana, který si bere celý projektový tým jako rukojmí. Přepracovaný nenahraditelný pracovník je totiž jako tikající časová bomba.

Pokud přicházíte (například jako externí projektový manažer) do prostředí, které nepodporuje sdílení informací mezi lidmi a vytváření dokumentace, je potřeba zavést určitá pravidla. Udělejte si přehled o tom, jaké jsou klíčové kompetence pro dodání projektu a jak jsou na tom jednotliví členové týmu – můžete použít třeba Team competency matrix [2]. Přehled vytvořte ve spolupráci s celým týmem a společně naplánujte, jak dosáhnete zastupitelnosti v klíčových oblastech. Využijte to i jako příležitost pro cílený rozvoj členů týmu a zvýšení jejich univerzálnosti. Také pomůže zavedení určitých pracovních návyků – vytvoření katalogu požadavků, způsob jejich prioritizace, tvorba zápisů i z interních schůzek, pravidelné schůzky s byznysem, forma a způsob vytvoření byznys analýzy, definice toho, co znamená, že je něco hotovo (a že do toho patří dokumentace, popis kódu, upravený datový model…) atp.

3. Hra na Černého Petra

Tato oblíbená karetní hra se často hraje na velikých projektech s řadou subdodavatelů a systémovým integrátorem. Hra se hraje sice bez karet, zato s velmi vysokými vklady, kterými jsou smluvní penále za nedodržení termínů. Hra spočívá v tom, kdo dříve přizná, že má problém. Ve složitém prostředí s nepřehledným tokem dodávek mají velkou výhodu ti hráči, kteří si umí zachovat pokerovou tvář do posledního okamžiku. Pokud totiž k posunu milníku dojde vlivem jiného týmu, nebude uplatněna penalizace. Jde jen o to, šikovně navléknout řetězec důkazů, ne/součinnosti a zásahů vyšší moci.

Jedinou obranou v této hře je transparentnost, komunikace a řízení očekávání stakeholderů. Pokud existuje integrační plán, seznam subdodávek a mapa závislostí, mělo by být poměrně zřejmé, kde je zádrhel. Důsledně také pracujte se zápisy – vytvářejte je, kontrolujte plnění úkolů a důsledně připomínkujte zápisy ostatních viz. bod 6 Pravdu mám já, určitě ne vy.

4. Víme, co zadavatel chce…

Toto je jeden z největších omylů, který se v různých variacích opakuje pravidelně. Někdy ani samotný zadavatel neví přesně, co chce. My jsme tu ovšem od toho, abychom mu pomohli jeho potřeby, myšlenky a nápady porodit.

Cesta k problémům spojenými s nepochopením zadání často může být dlážděna dobrými úmysly. Tak například – při kalkulaci došlo k podhodnocení určitých oblastí a projekt je na tom špatně s rozpočtem. Kde ušetříme? Máme šikovné vývojáře, nepotřebujeme analýzu! Výsledkem je tedy to, že zástupce IT (vývojář, či juniorní analytik) se sejde se zadavatelem. Často si ani nenastuduje dopředu podkladové materiály, ze kterých zadání vychází (například v oblasti regulované legislativou toto může být kritické). Na schůzce každý hovoří svým jazykem: zadavatel byznysovým, ajťák technickým… Výsledek jednání zapíše ajťák do UML diagramu a nechá si to od zadavatele posvětit. UML přeci umí přečíst i malé děcko, IT podle něj může začít pracovat, takže takhle je to nejbezpečnější, že?! Bohužel, většina zástupců byznysu nerozumí UML diagramům stejně, jako IT. Dochází tak k tomu, že výsledný produkt neplní potřeby byznysu. Pokud zadání není sepsáno jazykem a formou, které zadavatel sám bez pomoci rozumí a umí je sám interpretovat, je cena tohoto popisu z pohledu zafixování zadání velmi malá. Výzkum Geneca z roku 2010-2011 [3] ukázal, že v 78% nejsou požadavky byznysu v souladu s tím, jak zadání vnímá projekt.

5. Změna? Nebo jen upřesnění zadání?

Pokud projekt začne s nejasným zadáním, v průběhu času byznys zjistí, že řešení není to, co chce, nebo prostě jen změnil názor, a tak požaduje změnu. Prezentuje ji ale jako upřesnění zadání. Naproti tomu projektový manažer ji vnímá jako požadavek nad rámec scope, požaduje navýšení času a rozpočtu. A konflikt je na světě.

Této nepříjemné situaci se lze vyhnout dvěma způsoby. Buď investováním času do sepsání požadavků a provedení kvalitní a detailní byznys analýzy a její odsouhlasení s byznysem, nebo zavedením iterací a několika kol prototypů, aby na praktické ukázce byznys viděl, kam se projekt ubírá. Scope projektu, je poté potřeba zafixovat a nové požadavky na změny pouze zaznamenávat do fronty, ale nepřijímat je k realizaci, dokud se výsledný produkt nedostane do stavu, kdy si mohou zástupci byznysu ověřit, jak lidé reálně produkt používají a zda požadované funkcionality skutečně potřebují. Podle analýzy Standish Group je totiž často využíváno pouhých 20% funkčností, zatímco celých 50% se nevyužívá vůbec [4]. Je potřeba si uvědomit, že nová funkčnost nenese s sebou pouze náklady na vlastní vyrobení (tedy analýzy, vývoj, testing), ale také náklady na integraci s okolím, testování při každém release a aktualizace v budoucnu apod. Nejvíce ušetříte, pokud těch 80% funkcionalit, které se nevyužívají vůbec, nebo jen sporadicky, objevíte ještě před začátkem analýzy.

K požadavkům máme ještě jedno drobné upozornění ze života. Ověřte si, jak požadavky vnímají různé skupiny byznys uživatelů. Často jsou totiž představy pracovníků na centrále dost odlišné od toho, jak by to vyhovovalo pracovníkům poboček, kteří ale tvoří 95% reálných uživatelů výsledného produktu.

6. Pravdu mám já, určitě ne vy

Děláte zápisy? Někdo tuto administrativní činnost nesnáší. Dost často je určeno kulturou a zvyklostmi firmy, jak rozsáhlé a formální zápisy jsou. Je potřeba si ale uvědomit, že s postupem času, jak se přítomnost naklání do minulosti, jsou zápisy jediným záznamem o kolektivně vnímané pravdě. Kdo píše zápis, vytváří pravdu, která mu více vyhovuje. A to se může dost hodit, když dojde na lámání chleba. Nezřídka se totiž ke chlebu podává i grilovaný obětní beránek.

Zápisy piště strukturovaně. Ideální je přijít na jednání s předpřipravenou osnovou zápisu, která slouží jako příprava pro status. Účastníci tak mají možnost se dopředu seznámit s probíranými tématy. Ti, kteří mají poskytnout vstupy, je musí zaslat dopředu, takže projektový manažer má šanci zjistit případné problémy ještě před statusem a případně přijmout nápravná opatření (viz Je to v podstatě hotové). Úkoly ze statusů musí být adresné (kdo má co vykonat a do kdy) a na následném statusu kontrolovány. Zápisy, které dostanete k připomínkování detailně projděte a ověřte, že skutečně zachycují dohody a stav věcí tak, jak bylo prezentováno. Připadá vám to samozřejmé? Gratulujeme! Ale nepatříte k většině.

7. Co kdybychom si opatrně přiznali, že jsme v tom až…

Nikdo nechce být poslem špatných zpráv. Ale bohužel, v životě nejsou věci vždy podle plánu. Včasné přiznání problémů umožní je řešit. Přehlížení vede do patové situace. Problémy fungují jako sněhová koule, časem se nabalují a jsou větší a větší. Podcenili jste analýzu? Nebo jste špatně pochopili zadání a udělali analýzu na něco úplně jiného? Styďte se! ☺ Ale stát se to může, všichni jsme jen lidé. Pokud si to včas přiznáme, můžeme to ještě stihnout předělat. Bude nás to možná stát nějaké peníze navíc, možná i nějaký týden zpoždění, ale rozhodně bude dopad menší, než když to teď ututláme a necháme podle té špatné analýzy vývojáře pracovat. Pokud se vyskytnou problémy, podívejte se na ně v delším časovém horizontu. Náklady předělání analýzy jsou menší než náklady za smluvní penále za nedodání požadované funkcionality, které v konečném důsledku mohou přivést firmu i k bankrotu.

Vytvořte tedy prostředí, ve kterém je možné chybovat. A ve kterém přiznání chyby není stíháno. Je vždy lepší, když na chybu přijde tým interně, než když ji zjistí zákazník při akceptačních testech. Nastavte kontrolní mechanismy, které zajistí vzájemnou křížovou kontrolu (viz Nenahraditelný Superman). Jako projektový manažer buďte s týmem, stýkejte se s nimi i neformálně, naslouchejte jejich obavám. Pokud zjistíte určité problémy, komunikujte je v rámci týmu. Jednak pro řízení očekávání (bude práce přesčas? bude potřeba rušit dovolené?), možných zpoždění a nového uspořádání priorit, ale také proto, že společně můžete najít řešení daného problému, které by izolovaně nevzniklo.

Pokud by vás inspirovaly typické problémy IT projektů a zajímaly by vás další, třeba abyste věděli, na co si dát pozor, můžete jich zde [5] najít hned 101. Všechny mají ale jedno společné. Bez ohledu na to, jak je projekt složitý, vždy závisí na jednotlivcích, kteří se ho účastní a na tom, zda společně dokáží najít cestu ke společnému cíli. Jsme lidé, chybující, ale je lidské umět chybu přiznat a poučit se z ní.

Zdroje:
[1] International Project Leadership Academy – Catalogue of Catastrophe http://calleam.com/WTPF/?page_id=3
[2] Team competency matrix - https://management30.com/practice/competency-matrix/
[3] International Project Leadership Academy – Facts and Figures http://calleam.com/WTPF/?page_id=1445
[4] Standish Group – Exceeding Value (2014) - https://www.standishgroup.com/files/Exceeding%20Value_Layout4.pdf
[5] International Project Leadership Academy – 101 Common Causes http://calleam.com/WTPF/?page_id=2338

Eva a Zdeněk Macháčkovi Autoři článku, Eva a Zdeněk Macháčkovi, pracují jako konzultanti a projektoví manažeři. Zaměřují se na strategické poradenství, vzdělávání a popularizaci nových trendů businessu a podnikového IT. http://bit.ly/evamachackova http://bit.ly/zdenekmachacek