Na vašem soukromí nám záleží!

Používáme soubory cookie ke zlepšení uživatelského prostředí a pro reklamní účely. Prohlášení o zásadách ochrany osobních údajů.

Změna, která vás přežije - analytická fáze projektu

Tragickou havárii raketoplánu Challenger sledoval v přímém přenosu celý svět. V dalším díle seriálu o řízení změn vysvětlíme, proč se o Challengeru dodnes učí inženýři po celém světě.
Jan Škrabánek

12. 2. 2019

V lednu 1986 zažila Amerika tragédii. Sedmdesát dva sekund po svém startu explodoval v přímém televizním přenosu raketoplán Challenger. Ještě několik hodin před startem se přitom inženýr Roger Boisjoly pokoušel upozornit na problematické těsnění raketového pohonu. Doporučoval odložení startu. „Výsledkem může být ta nejhorší tragédie, ztráta lidských životů,“ varoval. V NASA ale odmítli naslouchat. Challenger startoval v podmínkách, které nebyly v přípravné fázi dostatečně prozkoumané. A když se našel člověk, který na problém upozornil, nepodařilo se mu přesvědčit ostatní. Studium havárie Challenger je dnes povinná četba pro technické inženýry. V některých zemích je dokonce součástí povinné přípravy pro získání profesionální licence.

publikováno v časopise IT SYSTEMS, vydání 12/2018


Dvacátého osmého ledna byla na Floridě neobvyklá zima. Tato skutečnost se později ukázala osudnou. Roger Boisjoly pracoval pro firmu Morton Thiokol, která NASA dodávala startovací stupně, kritickou součást raketového pohonu. Tým inženýrů ve firmě upozorňoval na nespolehlivost těsnění v nízkých teplotách. Thiekol měl jako výrobce kritických systémů pravomoc zastavit start raketoplánu. Vedení firmy tedy vyvolalo telekonferenci s NASA. Tam ale narazili na odpor. NASA se představa odložení letu vůbec nelíbila. Vedení Thiokolu si vyžádalo čas na rozmyšlenou. Z následující interní schůzky ale vyloučili všechny inženýry včetně Rogera Boisjoly. Rozhodli se vyhovět NASA.

Na příkladu Challengeru se inženýři dodnes učí řadu principů. Opomenutí jednoho klíčového prvku může mít nedozírné následky pro celý projekt. Naučí nás mnohé také o problémech komunikace, skupinového myšlení a vztahu zákazníka s dodavatelem. V dnešním díle se podíváme, proč je důležité nepodceňovat úvodní analytickou fázi projektu, a nabídneme několik tipů, jak ji zvládnout. 


Analytická fáze je nejdůležitější

Analytická fáze je nejdůležitější. Rudolf Slaba, ITIL® expert a procesní manažer v O2 Czech Republic, často implementuje nové procesy nebo funkce do složitého prostředí korporátního IT. Vždy se snaží akcentovat úvodní analytickou část projektu: „Snažím se prosadit, abychom analytické části projektu dali klidně pětinu nebo i čtvrtinu projektového času. Někomu se to může zdát hodně, ale pokud věnuji adekvátní kapacitu analýze, podstatně se zvýší moje šance implementovat proces nebo funkci na první dobrou.

Že přípravná fáze je nejdůležitější si myslí i Tomáš Gregor, manažer IT služeb Fakultní nemocnice Ostrava: „Cílem prvních kroků (definice projektu, projektový charter), je odhalit všechny vágní a nejednoznačné formulace, odstranit otazníky a jasně říct, že nemůže být A i B zároveň.“ V úvodní analýze je nutné přesně zjistit, co se očekává, jaké jsou impaktované role, atd.

Co se stane, když podobně jako inženýři z projektu Challenger opomeneme důležitý aspekt projektu? Důsledky zanedbané analýzy se přenesou do realizační fáze, jak vysvětluje Rudolf Slaba: „V analytické části někdy zjistíte, že pro některou ze zainteresovaných skupin má projekt výrazně negativní dopad. Musí najednou vytvářet dokument či report, který dříve nedělali, nebo jim to jiným způsobem sebere kapacitu. To je chyba v projektu, která následně způsobí, že konkrétní realizovaná změna je z nějaké strany torpédovaná lidmi, kteří k tomu mají pádný důvod. Nikdo s nimi změnu neprobral, nezískal jejich souhlas, nenabídl jim kompenzaci a nepokusil se je přesvědčit. Ve fázi přípravy zůstali tito lidé ponechaní v nesouhlasící opozici a to se přeneslo do realizační fáze. Kdybych jim v přípravné fázi věnoval 4 hodiny času, mohli jsme tomu předejít. Jakmile k negaci dojde ve fázi provozu, bude mě to stát 4 dny, než situaci napravím.“ 


Odvěká otázka: Vodopád nebo agile?

Podrobná analýza je důležitá, to ale neznamená, že byste měli řídit projekty vodopádově. „Když se řekne analýza, lidem někdy vstávají hrůzou vlasy na hlavě,“ říká kolega Jirka Janků, „Představí si, jak s tebou prochází nekonečně dlouhý dotazník, abys pak na půl roku zmizel a po dlouhém odmlčení se objevil s řešením. Z toho by byl každý nervózní. S úvodní analýzou je to jako s novým autem – když vyjede z autosalonu, už ztrácí 30 % hodnoty. Všechno, co při analýze zjistíš, může rychle ztratit relevanci. Proto je důležité, aby vznikla analytická vrstva projektu, kdy budeš schopný na základě zpětné vazby a nových poznatků zadání agilně upravovat a zpřesňovat po celou dobu trvání projektu. Čekají tě sice náročnější jednání o rozsahu projektu, ale výsledek stojí za to, protože zákazník ho doopravdy ocení.

Tuto zkušenost potvrzuje i Rudolf Slaba: „Kdykoli v projektu dochází k nějaké změně, prvním krokem je opět analytická činnost. Bez ní si nedovedu představit dát doporučení nebo určit strategii pro další postup. Místo teoretizování od stolu musí člověk věci vždycky dělat na základě přímé konfrontace a komunikace s prostředím, ve kterém se to bude odehrávat. Nemůžeš přistoupit na to, aby ti management dal zadání, které vyrobili za čtvrt hodiny na základě jedné porady. To nefunguje.

Odvěké otázce zda agile nebo vodopád se nevyhnete (OK, Agile manifesto spatřilo světlo světa roku 2001, což se v kontextu moderního IT dá považovat za dávné věky). Důležité je uvědomit si, že vodopádové i agilní metody mají své opodstatnění a vhodný přístup je třeba volit podle typu projektu, ale rovněž podle konkrétní etapy projektu. Častou chybou je, že za agilní řízení se někdy vydává i lajdácká improvizace. Rudolf Slaba k tomu dodává: „Někdy agilní projekt probíhá tak, že se zrealizuje podle nějaké formulky nebo metodologie a pak se upravuje podle toho, jak křičí uživatelé a zákazníci. Z jejich pohledu je to špatně řízený projekt. Když takových projektů realizujete více, reputace projekt manažera rapidně klesne.“ 


Váš vlastní mozek jako nepřítel úspěchu

Jeden z největších problémů analytické fáze přijde z nečekané strany. Ukazuje se, že pro naše myšlení je extrémně náročné zachovat si objektivitu. Vzpomeňte na Challenger. Jak je možné, že tým manažerů s technickým vzděláním odmítne důrazné varování špičkového inženýra a dá pokyn ke startu? Jak ilustruje Daniel Kahneman v knize Myšlení rychlé a pomalé, náš mozek nerad ztrácí čas náročným přemýšlením a hledá zkratky, jak složité problémy vyřešit s minimem úsilí. Intuitivní přemýšlení nám může dobře posloužit ve většině životních situací, při řízení projektů nás ale někdy zavede na scestí.

Takzvaných kognitivních zkreslení, kterým náš mozek podléhá, je celá řada. Pojďme se na některá podívat blíže. Konfirmační zkreslení je přirozená tendence upřednostňovat informace a interpretace, které ladí s naším viděním světa. „Většina z nás miluje vlastní hypotézy,“ říkal evoluční biolog a nositel Nobelovy ceny Konrád Lorenz. „Je velmi bolestivou, ale současně velmi zdravou a osvěžující ranní rozcvičkou, hodíme-li svou oblíbenou hypotézu přes palubu.“ To pro nás ale není jednoduché. Proto si i protichůdné informace budeme vykládat jako potvrzení vlastních předpokladů. Milovníci konspiračních teorií v tomhle excelují, ale běžná populace není zase tolik pozadu.

Další kognitivní zkreslení odhalili vědci, kteří v jednom experimentu nechali skupinu lidí sestavit skříň z řetězce IKEA a následně jim nabídli skříň k odkupu. Druhá skupina dostala stejnou nabídku pouze s tím rozdílem, že skříň už byla sestavená. Lidé z první skupiny byli ochotni zaplatit za skříň o 63 % více než ti, kteří do stavby skříně nic neinvestovali. I zde se jedná o kognitivní zkreslení s příznačným názvem IKEA efekt. Jakmile jste osobně zapojení do přípravy řešení, bude pro vás extrémně těžké dívat se na věci objektivně. Z projektu se stává vaše dítě. Nikdo si o svých dětech nemyslí, že jsou ošklivé a nešikovné. IKEA efekt je obzvlášť nebezpečný u projektů, jejichž součástí je programování softwarového řešení a customizací.

Klam dostupnosti způsobuje, že upřednostňujeme informace a příklady, které si snadno vybavíme. Je to představa, že pokud si na něco jasně vzpomínáme, musí to být důležité. Proto dáváme přednost tvrzením a výkladům, které jsme slyšeli v blízké minulosti. Jestli je váš mailbox zavalený články o nejnovějším trendu ve vašem odvětví, bude pro vás přirozené prosazovat právě takové řešení na další poradě. Jestli jste právě zažili nepříjemný incident, budete rizikům spojeným s podobnými incidenty přikládat neúměrnou váhu.

Ve výčtu kognitivních zkreslení bychom mohli pokračovat několik dalších stran. Pro tento okamžik si postačí uvědomit, jak je pro nás těžké dívat se na problémy objektivně. 


Praktické tipy pro analytické schůzky

Kdyby náhodou nestačilo, že mozek se nás neustále pokouší oklamat, všechno se ještě zkomplikuje, jakmile do rovnice přidáte další lidi. Vraťme se na chvilku k raketoplánu Challenger a inženýru Rogerovi Boijoly. Po havárii začal přednášet o etice na pracovišti. O klíčové schůzi managerů Morton-Thiokolu s lidmi z NASA prohlásil: „Šlo o neetické rozhodovací fórum, které bylo důsledkem intenzivního zastrašování zákazníkem.“ Případ challengeru dal podnět k hlubšímu studiu syndromu skupinového myšlení. V zájmu zachování shody celé skupiny jednotliví účastníci potlačí svoje pochybnosti a přikloní se ke špatnému rozhodnutí. Jinými slovy lidé zůstávají konformní a bojí se vyjádřit svůj názor.

S tím se dá bojovat. Zajímavý způsob, jak se na věc podívat z neobvyklých úhlů a zároveň dát lidem větší volnost k vyjádření svých myšlenek je premortem analýza. Zkuste si představit, že projekt už se realizoval a skončil katastrofálně. Následně zkuste identifikovat příčiny neúspěchu. Jedná se o hypotetickou postmortem analýzu. Čistě vzato je to úplně stejné jako zeptat se, co by se mohlo pokazit. Rozdílná formulace úkolu ale může udělat divy. Následně nechte lidi sepsat na papírky všechny důvody, které je napadnou. Všechny důvody zaznamenejte a následně o nich s týmem diskutujte. Na základě výstupů pak manažer projektu může posílit slabá místa projektového plánu.

Výše popsaná metoda brainwritingu je sama o sobě dobrým způsobem, jak válčit se syndromem skupinového myšlení. Brainwriting v poslední době do značné míry nahrazuje populární brainstorming, který nesedí úplně každému. Aktivní účast na brainstormu totiž vyžaduje určitou míru asertivity a sebevědomí. Introvertně založení lidé či zaměstnanci, kteří se na schůzce cítí do počtu, se v takové situaci hůře prosazují. To platí obzvlášť v českém prostředí, kde se často obáváme, abychom neřekli nahlas nějakou hloupost. Pomocí brainwritingu dáme prostor vyjádřit se i těmto lidem a jejich zpětná vazba může být často nejcennější.

Pro získání cenných podnětů je ve výsledku nejdůležitější klást správné otázky. Jaké jsou známé neznámé tohoto projektu? S jakými neověřenými předpoklady pracujeme? Kdybychom radikálně zmenšili rozpočet, dodali bychom alespoň nějakou hodnotu? Neměli bychom to nejprve zkusit? Když tento aspekt projektu dobře zvládnete, máte výrazně větší šanci na úspěch.

V každém případě, aby analýza dávala smysl, je nutné se zjištěními dále pracovat. Někdy je lepší celý projekt zahodit, než riskovat katastrofu. Jak řekl Richard Feynman, člen komise vyšetřující havárii Challengeru a rovněž nositel Nobelovy ceny: „Realita musí mít přednost před PR, neboť přírodní zákony neoklamete.



ITIL® is a (registeredTrade Mark of AXELOS Limited. All rights reserved.

Odebírejte CIO newsletter

  • to nejlepším z našeho blogu
  • tipy a triky z IT managmentu
  • inspirativní rozhovory s CIO českých i zahraničních firem
  • pozvánky na webináře a konference


Přihlaste se k odběru newsletteru