V čem je tedy problém?

„Nejsou lidi,“ křičí jeden projektový manažer vedle druhého, a poukazuje na to, že máme nejvyšší zaměstnanost v rámci Evropské unie, a pracovní trh je tedy zcela přesycen. V tom mají nepochybně pravdu. Často v rámci běžné pracovní rutiny slýcháme taktéž verze „nejsou peníze“ či obecně „nejsou zdroje“, což je, vzhledem k tomu, že jsme na vrcholu ekonomické křivky, trochu paradox.

Společně s kolegy v PwC máme raději než dojmy tvrdá data, a tak ve 110 zemích světa cyklicky sbíráme data pro průzkum „Global Portfolio and Programme Management Survey“, ze kterého budu v některých částech zbývajícího textu vycházet. Pravdou totiž je, že od roku 2004, kdy jsme s dotazováním začali, není nejčastější příčinou neúspěchu projektů nedostatek zdrojů (ten se krčí až na třetím místě), ale zcela nerealistický proces plánování a jeho výsledky. A to zcela bez ohledu na zaměstnanost v tom či konkrétním regionu nebo fakt, že celý trh za dobu sběru dat prošel masivní krizí.

Samozřejmě, plánování a zdroje jdou ruku v ruce. Známý trojúhelník „cena, kvalita, čas“, ze kterého lze vždy dosáhnout splnění maximálně dvou proměnných, netřeba dlouze vysvětlovat. A tak rovnou, bez velkého mučení, prosím: Sáhněte si do svědomí vy všichni, kdo do projektových plánů píšete zdroje jako „Proxy consultant“ a „To behired“. To je totiž první předpoklad obrovského problému. Pokud máte v pětičlenném projektovém týmu tři skutečné lidi a dva, které se vám nikdy nepodaří nabrat, je zřejmé, že projekt dříve či později skončí v troskách a navrch dokonale otrávíte tři zaměstnance (či v lepším případě externisty).

Jednou ze starších – a věřím, že dnes již přežitých – taktik, jak řešit problémy spojené s dodávkou projektu, je „nasmnogo“. Tento přístup bohužel nebyl zcela funkční ani před dvaceti lety (hluboce zakořeněné problémy organizace nevyřeší dvacet nových zmatených lidí na pracovišti, najatých za účelem uspíšení dodávky projektu), a tím spíše nebude funkční dnes, kdy před každou firmou nestojí zástup padesáti uchazečů, jak tomu bylo v minulosti.

Každý ví, časy se mění

Častou příčinou problémů jsou také změny – ať už v zadání projektu (často na jeho samém konci, jakkoliv šíleně to zní), ve strategii společnosti či v okolí organizace. Do této kategorie patří třeba stav trhu obecně, regulatorika či politické prostředí. Věřím, že každý čtenář si vybaví některé medializované, velké IT projekty ve státní správě, na nichž se vystřídalo tolik politických reprezentací, zadavatelů i dodavatelů, že je až neuvěřitelné, že některé z nich došly do zdárného konce. Často však za cenu tzv. scopecreep, tedy dodávky pouze parciálního řešení (pochopitelně však za původně kalkulovanou cenu). Schválně, vzpomenete si, co všechno měla podle prvního plánu umět Opencard? Běžte se podívat, budete se hodně divit…

Automobilky v celé EU letos významně pocítily, že pokud se regulátor rozhodne narychlo změnit pravidla hry, může to vést k takovému extrému, jakým jsou desetitisíce odstavených vozidel s chybějící homologací kvůli novému způsobu měření emisí. Francouzský národní železniční dopravce SNCF zase v rámci projektu za 15 miliard € tak dlouho měnil zadání, až v roce 2014 slavně vysoutěžil vlaky, jejichž šířka byla nekompatibilní s francouzskými nástupišti. Daňové poplatníky tato legrace přišla na 50 milionů € investovaných do úpravy nástupišť v 1 300 (!) stanicích.

Proč v článku pro IT odborníky věnuji tolik prostoru povídání o automobilech, vlacích a kartičkách do MHD? Je to jednoduché – jde o příklady elementárních selhání, která si každý člověk dokáže barvitě představit. Selhání ve světě IT, třeba chybějící penetrační testy a důsledky z toho plynoucí či neúspěšné migrace dat při implementaci nového ERP a následné rollbacky, si dokáže představit jen málokdo. Jen velmi těžko si je dokáže představit zkostnatělé vedení firem, které IT nemají jako svůj primární byznys. A na to IT projektoví manažeři i dodávající týmy tak trochu sázejí…

Hledáme projektového manažera. Zn. Musí umět červenou!

Smutnou pravdou totiž je, že je lidskou přirozeností tutlat problémy do poslední chvíle, zvlášť pokud stav projektu reportuje nadřízenému orgánu projektový manažer, který je za něj pochopitelně implicitně zodpovědný. Určitě to dobře znáte – prezentace je plná zelených, v nejhorším případě žlutozelených bublinek,“ akorát to tedy, šéfe, ještě není jakoby úplně hotový, ale nebojte, to se stihne, to vám slibuju“.

Před sto a více lety by se za tutlání skutečného stavu věcí (např. u důležitých dopravních staveb ve zpoždění) možná i střílelo, dnes (díkybohu!) hrozí projektovým manažerům maximálně zlatý padák a z ostudy kabát k tomu. A podle toho to také vypadá. Dle našich dat je průměrně projektový rozpočet překročen o více než 30 % - ale tato data zahrnují i projekty, které jsou hodnoceny jako úspěšné a podařilo se je ukončit pod budgetem.

Já dohlížím, ty dohlížíš, on dohlíží

Převážné části výše zmíněných problémů může předejít projektový dohled. Ten má přitom obvykle dvě různé složky, které se terminologicky v různých metodikách (PRINCE2, PMBOK aj.) zaměňují a častují různorodými výrazy jako „project assurance“ a „quality assurance“.

V prostředí IT to v praxi představuje jeden tým dohlížející na projektové aspekty, zcela odděleně od samotné podstaty dodávaného produktu. Projektový dohled abstrahuje od toho, zda cílem projektu je přestříkat milion zelených aut na žlutá, postavit další mrakodrap na Pankráci či zavést do provozu nový core-bankingový systém. Je proto na místě, aby nezávisle zrevidoval klíčové dokumenty projektu, mezi které patří jeho zadání, business case, projektový plán či metodika změnového řízení. A následně po celou dobu dohlížel na dodržování stanovených pravidel a revidoval stav, který se reportuje projektovému sponzorovi či sponzorům a vedení společnosti. To mimo jiné znamená, že musí být na projektovém manažerovi (a ideálně i sponzorovi) zcela nezávislý. Pakliže projektový manažer reportuje, že za okny organizace svítí sluníčko, role projektového dohledu není kolegiálně přitakávat, ale jít se podívat, jestli se neblíží přeháňka, nebo v horším případně pořádná bouřka.

Druhým aspektem je assurance (dohled, ujištění) zaměřené na samotný produkt. V případě IT projektů, jejichž nejčastější náplní je implementace nových systémů a funkcionalit, jde přirozeně především o dohled na celkovou kvalitu. Mezi nejčastější aspekty patří kontroly toho, zda vyvinutý systém odpovídá zadávací dokumentaci, plní požadavky uživatelů z řad byznysu, či detailní dohled nad migrací datových struktur.

Nejde o všespásné řešení, ale pomoc ucítíte okamžitě

Jeden z klíčových aspektů, na který jsem poukázal již na konci perexu, je fakt, že velká většina projektů začíná bez jakéhokoliv dohledu. Ten je přizván až v okamžiku, kdy se ukáže, že skutečný stav projektu neodpovídá představám zadavatele – a to je v lepším případě za pět minut dvanáct. U běžících projektů pak jde spíše než o dohled o služby z oblasti „project recovery“. Zkušený externí tým obvykle identifikuje nejslabší články projektu během několika málo workshopů, a následně přijde s jasným řešením, které lze snadno zavést a které má téměř okamžitý pozitivní vliv na jeho průběh. Často jde třeba jen o malou změnu projektové metodiky, několik hodin strávených tréninkem či cílený mentoring.

Pokud však stojíte o to, aby se váš IT projekt do situace, kdy budete potřebovat záchranný tým, nikdy nedostal, je více než vhodné na projektový dohled myslet již na samotném začátku projektu. Díky aktivní osvětě je takových projektů čím dál více – ale stále ani náznakem tolik, kolik by bylo třeba. Nezávislé oko, které posoudí vaše odhady, plány a předpoklady, konfrontuje je se zkušenostmi z projektů podobné velikosti i typu, a dohlédne na projekt po celou dobu jeho trvání, dnes pořídíte u konzultačních společností jako službu již za několik desítek tisíc korun měsíčně. Pokud existuje šance, že vás díky své pozornosti a pečlivosti zachrání od bolavého rollbacku neúspěšné implementace či rekonstrukce 1 300 nádraží za miliony eur, tak to možná stojí za to, nemyslíte?

Ondřej Koch Autor článku je senior konzultant IT bezpečnosti ve společnosti PwC ČR.