Plánování a řízení projektů znamená umět vidět souvislosti, umět hledat cesty, jak je využívat a skutečně je využívat. Podstata řízení projektů - trojimperativ (Co -Kdy - Za kolik), plánování (Co - Jak - S kým - Kdy - Za kolik) a zásady řízení projektu (podle etap, kroků a úkonů) - tvoří nepominutelnou osnovu, kterou proplétáme vnímáním, respektováním a ovlivňováním souvislostí. Pokročilé metody, z nichž naznačíme konkurenci časem, TOC a kritický řetěz, soustavy projektů (tzn. komplexní projekty) a projekty s nejasným cílem (vývoj nových produktů, silně inovativní projekty), jsou všechny o souvislostech, vždy z jiného úhlu, ale nakonec pořád o tom samém.

Projekt a čas
Jedním z velkých nebezpečí projektu je "šibeniční termín". Často nevzniká ani špatným odhadem ani kvůli neblahému tlaku zákazníka, ale je prostě důsledkem reálné situace. Všechno se zrychluje a prostředí konkurence nám jednoduše více času neposkytne. Jak celé to "Co - Jak - S kým - Kdy - Za kolik" stihnout, když trh nečeká? Jsou dvě zásadní možnosti: změnit cestu (= způsob), JAK cílů dosahujeme, nebo najít rezervy ve způsobu řízení a přímo zkrátit odhadnuté termíny, KDY dosáhneme cíle.

První možnost vlastně znamená použít takové technologie, které čas potřebný k vykonání projektu zkrátí. Použití technologií je velmi závislé na druhu projektu, na jeho cílech, a často je z obchodního hlediska ani nemůžeme ovlivnit, jsou prostě součástí zadání projektu a navíc jsou vzdálenější vlastnímu umění řídit projekty. Proto se podívejme podrobněji na druhou možnost (k té první ostatně vyšel článek o technologii eTrium v prosincovém čísle).

Nalezení rezervy ve způsobu řízení, nebo-li zkrácení T2M (time to market), může vycházet ze souvislostí spíše vnějších: říká se tomu multitasking - klíčoví pracovníci pracují na několika projektech současně a neustále "přepínají" z jednoho projektu na druhý, aby všechny tak nějak zároveň dotlačili do cíle. Čas, který by bylo třeba věnovat činnostem jednoho projektu bez "přepínání", je vždy kratší, než čas s "přepínáním". I skvělý odborník pracuje po každém "přepnutí" poněkud pomaleji, než se do daného problému "vžije". A budete-li takto přepínat mezi třemi projekty, z nichž každý by sám o sobě trval tři měsíce, dokončíte je všechny tři někdy až po devíti měsících. V takové situaci je přece výhodnější rozlišit tyto projekty z hlediska priority a následně budete mít ten s nejvyšší prioritou v cíli již za tři měsíce, druhý třeba za sedm a třetí někdy po devíti měsících (u těch dvou zbývajících mi asi trochu multitaskingu zbylo). Jenom je třeba najít odvahu ono rozlišení priorit skutečně provést.

Ale rezervy lze hledat i v souvislostech vnitřních. Víme, že riziko nedodržení termínu lze snížit, když na činnost naplánujeme čas i s rezervou. Jak to s rezervami dopadá a jak s nimi pracovat, si ukážeme v souvislosti s tzv. kritickým řetězem.

TOC a kritický řetěz
Koncem 90-tých let se vynořil fenomén jménem Eliyahu Goldratt. Jeho knihy - romány Cíl a Kritický řetěz se staly bestsellery v USA a myslím, že poměrně známé jsou i u nás. Doporučuji přečíst, a to v uvedeném pořadí. Jsou to docela čtivě napsané romány a něco se naučíte: jak vidět věci takové, jaké jsou, co je to ono vnímání souvislostí, a jak lze díky tomu prakticky řešit problémy v řízení výroby a problémy řízení projektů.

Tendence manažerů (aspoň jak ji vidívám při svých konzultacích) je vnímat svůj problém jako jedinečný a svými specifiky zcela odlišný od všech problémů těch ostatních. Dokonce se i brání, když přirovnám jejich problém k něčemu, co jsem již viděl. "Ne, v našem případě se jedná o něco úplně jiného!" - zní častá odpověď. A při tom právě vidění podobností je jedním z nejsilnějších nástrojů na řešení zapeklitých a nepoddajných problémů, jak Godratt ve svých knihách ukazuje. Mimochodem, řízení výroby a řízení projektu lze postavit nad téměř stejnými pojmovými modely, proti čemuž asi také někdo bude protestovat.

V čem tedy spočívá TOC (= theory of constraints - teorie omezení) a kritický řetěz? TOC - popsaná hlavně v knize Cíl - je o tom, na co především soustředit pozornost. Zjednodušeně, pro potřeby řízení projektů, lze říci, že spočívá v následujících pěti krocích:

1. Identifikujte systémové omezení (tedy, najděte "nejslabší článek řetězu", to, co způsobuje, že nemůžeme stihnout udělat víc práce, přijmout více zakázek, poněvadž to přes toto úzké místo prostě neprotlačíme).

2. Rozhodněte, jak systémové omezení využít (co udělat, abychom z něj dostali maximum, které získat lze).

3. Podřiďte vše ostatní, co děláte, těmto rozhodnutím (vše, co na projektech činíme, se děje v kontextu vzájemných souvislostí je zbytečné někde zvyšovat úsilí, když výsledky se zarazí o ono slabé místo).

4. Pozvedněte systémové omezení (soustředíme pozornost v prvé řadě na to, jak posílit ono slabé místo, neboť "pevnost řetězu je maximálně taková, jaká je pevnost jeho nejslabšího článku").

5. Jestliže se krokem 4 systémové omezení odstraní, přejděte na krok 1.

Cena dobrých zdrojů (špičkových odborníků) je velká, a nikdy jich tedy není dostatek. Při práci na projektech právě tyto zdroje často vyvolávají systémová omezení. Systémovým omezením ale může být například i získávání nových zakázek nebo předávání hotových vývojových projektů do údržby.

Vraťme se ale ke zdrojům. Základní závislost činností na jednom projektu je dána logikou jejich návaznosti (SW nemůžu testovat, když jsem jej ještě nenaprogramoval). Avšak závislost mezi činnostmi (a to nejenom na jednom projektu, ale na celé soustavě projektů, které právě řešíme) je také dána sdílením důležitých (a prakticky nenahraditelných) zdrojů. Již u multitaskingu jsme si ukázali, že v daný okamžik zdroj pracuje jenom na jedné činnosti. A tak činnosti, na kterých má pracovat zdroj XYZ (za který nemáme náhradu), přestože na sebe věcně vůbec nenavazují, jsou ve skutečnosti na sobě závislé, poněvadž sdílí tento zdroj. Tedy závislost činností na projektech vzniká buď z logiky návaznosti nebo sdílením společného zdroje. Na sobě závislé činnosti nelze vykonat souběžně vždy jenom jednu po druhé. Potom je omezením pro projekt nejdelší řetězec na sobě nějak závislých činností, který nazval Goldratt kritickým řetězem (kniha Kritický řetěz).

Kritická cesta (nejdelší cesta v projektu po logicky na sebe navazujících činnostech) nebývá pro určení nejkratšího možného trvání u SW projektů zajímavá, poněvadž projekt není ve vzduchoprázdnu a dobrých zdrojů je vždy nedostatek. Daleko více si musíme pro určení doby trvání SW projektu všímat kritického řetězu. To je také důvodem, proč jsme při popisu plánování projektu zdůrazňovali postup od JAK (logika návazností) přes S KÝM (disponibilita a sdílení zdrojů) ke KDY (výsledný harmonogram).

I když zůstaneme u velmi zjednodušujícího výkladu, je třeba ještě zmínit působnost tří faktorů, které jsou příčinou zavedení tzv. projektových nárazníků (časových rezerv). Parkinsonův zákon říká: činnost trvá nejméně tak dlouho, na jak dlouho je naplánovaná (prakticky nic neskončí dříve, než je naplánováno). Studentův syndrom lze formulovat takto: jestliže na provedení činnosti byla naplánována časová rezerva, pak tato rezerva je spotřebovaná, ještě než činnost začne (nikdo nezačne pracovat dříve, než je to nezbytně nutné). Konečně (poslední) Murphyho zákony říkají: Vždy se něco pokazí. Nikdy se nepokazí všechno. Asi vidíme, že plánovat ke každé činnosti její časovou rezervu, nebude mít smysl. Dejme ale za kritický řetěz rezervu (tzv. projektový nárazník), která bude vyrovnávat odchylky skutečně spotřebovaných časů na činnostech oproti plánovaným časům. Tato rezerva může být určitě kratší, než by byl součet rezerv jednotlivých činností (Murphyho zákony), které by beztak byly neplodně utraceny v důsledku studentova syndromu. Zároveň tím eliminujeme jak studentův syndrom, tak Parkinsonův zákon: S rezervou v projektovém nárazníku můžeme totiž obchodovat. Jestliže potřebuješ více času pro svou činnost, kup si jej za část své odměny. Jestliže naopak spotřebuješ méně času než počítal plán, prodáš nám tento čas do společné rezervy na konci projektu za zvýšení tvé odměny. Ze společné rezervy pak efektivně kryjeme neočekávané problémy.

Řízení ve velkém
Už u kritického řetězu se nám nenápadně vynořil pojem soustava projektů. O soustavě projektů obecněji mluvíme v případě, že více projektů sdílí zdroje nebo více projektů sdílí tzv. globální produkty nebo když více projektů sdílí vyšší cíl. Soustava projektů se vynoří vždy, když existuje něco, čím se projekty ovlivňují. Kromě sdílení zdrojů se mohou taky ovlivňovat globálními produkty - produkty, které vznikají v rámci jednoho projektu (a mohou to být třeba i pouhé mezivýsledky v tomto projektu), a které jsou využity při řešení jiného projektu. Nebo se mohou projekty ovlivňovat tím, že vzájemným synergickým působením naplňují nějaký vyšší cíl (synergií inovace IS a změny organizace práce je třeba dosaženo zvýšení podílu na trhu). Ve všech těchto případech platí, že úspěch jednoho projektu soustavy dosažený na úkor jiných projektů nebo bez ohledu na jiné projekty, není ve skutečnosti dosažením celkového "business úspěchu". Dosáhnout celkového úspěchu vyžaduje uřídit celou soustavu projektů tak, aby všechny projekty naplnily své trojimperativy.

Z předchozích úvah již víme, že to, čím se projekty ovlivňují je vlastně omezením soustavy projektů. Pouze jsme úvahy o závislosti činností posunuli o úroveň výš a řešíme závislosti mezi projekty. Jednoduchou aplikací TOC zjistíme, že u soustavy projektů je třeba 1. identifikovat omezení soustavy (určit strategické zaměření), 2. rozhodnout, jak omezení využít, 3. vše na soustavě podřídit tomuto rozhodnutí (vytvořit informační strategii; stanovit výstupy a cesty k nim), 4. pozvednout omezení soustavy (implementací této strategie se posunout ve směru strategického zaměření; pozvednout omezení)

Řízení soustavy projektů tedy vyžaduje vytvořit strategii (v našem případě informační strategii). Strategická analýza ukáže, KDE JSME (start) a KAM CHCEME DOJÍT (cíl), výběr strategie určí jednu z možných CEST od startu do cíle a implementace strategie je SOUSTAVA PROJEKTŮ, jejichž postupné vykonání nás skutečně dovede k cíli. Tato soustava projektů v sobě obsahuje projekty oné původní soustavy, kterou jsme měli řešit, a jejíž omezení (v důsledku vzájemných ovlivnění mezi projekty) jsme identifikovali. Přehledně to zobrazuje diagram na obr.1.

(P4 představuje projekt, který nebyl v původní soustavě projektů.) Důležitým poselstvím je skutečnost, že věci nikdy neprobíhají pěkně v pořadí Strategická analýza Vývěr strategie Implementace strategie, ale navzájem se neustále ovlivňují a vyžadují revizi předchozí rozhodnutí. A tak i bod 5 (opakovat od kroku 1) z TOC zde má své místo.

Soustavu navzájem se ovlivňujících projektů můžeme vidět jako komplexní projekt. Takový komplexní projekt má samozřejmě opět svůj trojimperativ: CO = cíle soustavy projektů, KDY = harmonogram soustavy projektů, a ZA KOLIK = rozpočet celé soustavy projektů. Má i své plány - vybranou cestu v rámci Výběru strategie, tj. plán navazujících činností, jehož činnostmi jsou celé projektyK řízení soustavy projektů je tedy třeba strategické řízení (strategický životní cyklus) a dvoustupňové řízení: řízení jednotlivých projektů soustavy (tzv. RVM = řízení v malém) a řízení celé soustavy projektů (tzv. RVV = řízení ve velkém).

Řízení ve velkém vyžaduje sledování projektů ve vzájemných souvislostech, zejména v tom, jak se ovlivňují společně využívanými zdroji (viz TOC výše) a jak se ovlivňují změnami, které v průběhu řešení jednotlivých projektů nastávají. A klíčové pro soustavu projektů je sledovat rozpracovanost a řídit důsledky rozpracovanosti globálních produktů.

Projekty s nejasným či plovoucím cílem
Charakteristickým rysem projektů vývoje nových produktů či silně inovativních projektů je, že až samo řešení projektu ukazuje CO má být výstupem, JAK tohoto výstupu vůbec dosáhneme, S KÝM tedy bude potřeba řešení realizovat, jak dlouho to bude trvat (KDY) a kolik to vlastně bude stát (ZA KOLIK). A dokonce cíl, který se zdá být vyjasněn v první fázi, se později, při prohlubování znalostí o problému, začne posunovat, a tak výrazně měnit všechny předpoklady dříve těžce vyrobených plánů.

M.D. Rosenau v knize Řízení projektů hovoří v takových případech o mlhavém začátku následovaném fází etapa-brána. Projekt se plánuje detailněji vždy na jednu etapu, která končí branou. Ta projekt zavře, není-li již naděje na dosažení úspěchu, nebo ho pustí do další etapy. Plán další etapy je vždy druhým klíčovým produktem ukončované etapy (prvním je vlastní rozpracovaný produkt). Tak má projekt vlastně mlhavý i konec.

Po tom, jak jsem horlil v prvním díle pro přesné plánování, může toto někomu připadat jako pověstný Cimrmanův krok stranou. Není tomu tak. Co jsem řekl, za tím si stojím. Je třeba si pouze položit otázku: jak z nejasného cíle udělat cíl jasný? Odpověď zní: posunout pozornost o stupeň výš, tam definovat jasný cíl a na původním daném (výchozím) stupni směřovat k onomu vyššímu cíli. Tak se z (možná) jednoho projektu s nejasným cílem stane soustava projektů s jasným vyšším cílem, při čemž projekt s nejasným cílem jde cestou etapa-brána a je řízen projektem v soustavě, který se zabývá výhradně nalézáním cílů pro jednotlivé brány. Takový projekt musí být v soustavě přítomen. Je to podobný princip, jako když doporučujeme, aby před implementací nejprve proběhl projekt analýzy potřeb, ve kterém se věcné cíle, čas a peníze naplánují. Zde jde o to, že takovou analýzu potřeb provádíme průběžně spolu s realizačním projektem a postupně vyjasňujeme cíl. Kdyby chybělo dvoustupňové řízení soustavy, octl by se projekt s nejasným cílem v chaosu. Vidíte, že (jak říkáme my matematici) jsme problém elegantně převedli na předchozí případ.

Závěr
Začíná se nám to dost komplikovat a objevuje se legitimní otázka, zda to jde prakticky vůbec zvládnout. Začal jsem tím, že vše je o souvislostech a že se k nim z různých stran nakonec vždy dostaneme. Při pohledu na toto naše povídání trochu z nadhledu uvidíme jistou podobnost: vždy jsme si "hřiště problému" nějak rozdělili do kategorií (kategorizovali jsme to, na co soustřeďujeme pozornost) a pak jsme hledali souvislosti a stanovovali pravidla k těmto kategorizacím. V posledním díle seriálu to probereme podrobněji a naznačíme v diskusi o managementu znalostí v projektech, že to zvládnout skutečně lze.

Pozn. red.: Autor, RNDr. Zdenko Staníček, působí na Masarykově univerzitě v Brně, Fakultě informatiky.


www.shine.cz