Řídit projekt znamená způsobit, že co je naplánováno, bude taky uděláno. Jak projekt naplánovat, a že bez plánů ani o projekt nejde, jsme si vysvětlili v minulém čísle. Nemá smysl sahat po sofistikovaných metodách, pokud nejsou zažité zásady projektového řízení. Zásady vypadají až triviálně. Avšak kdykoli je budeme chtít porušit, pečlivě zvažme důsledky. Po zásadách a některých zkušenostech si ukážeme, kde se nejčastěji stávají chyby. Nové a pokročilejší metody zvládání těchto velmi komplexních problémů přiblížíme v příštím díle seriálu.

Projekt a zásady jeho řízení
Projekt a čtyři ohniska soustředění pro jeho úspěch jsou ilustrovány na obrázku 1.

Řídit projekt znamená způsobit, že co je naplánováno, bude taky uděláno. Pomocí etap projektu řídíme hlavně riziko. Zejména riziko, že bychom proinvestovali zbytečné peníze. Proto etapy následují bez překrývání jedna za druhou. Riziko pak řídíme pomocí tzv. bran, které buďto projekt propustí do následující etapy (když to, co bylo v současné etapě uděláno, nezhatilo naději na celkový úspěch) nebo jej nepropustí (když se tato naděje ztrácí). Pak jsou dvě možnosti: buď je ještě možné naplánovat a provést nápravná opatření - projekt pak pokračuje, ale podle změněných plánů (tomu se říká řízení změn), nebo jsou výsledky právě ukončované etapy tak tristní, že náprava v rozumných časových a finančních mezích již není možná. Pak musí být projekt v bráně zastaven. Pokud k zastavení projektu nenajdete odvahu kvůli tomu, kolik peněz již bylo do projektu vloženo, počítejte s tím, že takto ztratíte ještě mnohem více.

Kvalitu a konfiguraci výsledných produktů řídíme převážně pomocí kroků. Každá etapa se může rozpadnout na několik kroků. Každým krokem bychom měli vytvořit nějaký dílčí produkt, jehož kvalitu lze jednoznačně posoudit, a je tak možné poznat, zda to, co činíme, směřuje k očekávaným výsledkům. Kroky se v rámci etapy mohou i překrývat. To znamená, že kde to logika věci dovolí, probíhají kroky paralelně. Při ukončení každého kroku porovnáváme jeho výsledek s očekávaným (naplánovaným) stavem. Je-li výsledek kroku ve shodě se specifikací, popisující v plánech naše očekávání, projekt pokračuje podle plánů. Není-li tomu tak, nastává změna: buďto musíme připlánovat a pak provést nápravné akce, abychom výsledek uvedli do shody se specifikací, nebo musíme k neshodnému výsledku přizpůsobit zbytek projektu a další návazné kroky provést podle těchto změněných plánů. Kterou z variant použijeme, závisí na tom, u které vidíme větší naději na dodržení trojimperativu projektu.

Vlastní průběh prací na projektu řídíme pomocí úkonů. Úkony jsou elementární balíčky práce, které manažer projektu, nebo jím stanovený koordinátor, přiděluje jednotlivcům, či malým dvou až tříčlenným týmům. Úkony opět mohou probíhat paralelně a provedení určité množiny úkonů znamená vykonání nějakého kroku. Úkony jsou přidělovány a sledovány pomocí rozpisu prací - viz příklad v tabulce 1.

Kdy	Kdo	Kde	Co
do 15.2.	analytici XXX, XXY, XYZ	u klienta	sběr podkladů o relevantních událostech a postupech jejich ošetření
do 25.2.	XXX, XXY	na svém pracovišti	návrh popisu procesů
26.2.	řešitelský tým + pracovní tým	výjezdové zasedání	workshop: oponentura a revize popisu procesů
do 7.3.	XXX, XXY, XYZ	na svém pracovišti	kompletace procesního modelu businessu zákazníka – výsledný produkt kroku „Vytvoření modelu procesů“

Zkušenosti
Řízení projektu je na jedné straně o důslednosti, s níž plníme dříve navržené plány, a jednak o změnách plánů, když z různých příčin ty původní nelze splnit. Znalosti a zkušenosti projektového managera pak ústí v umění rozpoznat, kdy být důsledný a kdy měnit plán. Na to žádná kuchařka neexistuje. Je třeba učit se vnímat souvislosti, efektivně pracovat se znalostmi, a hlavně projít řadou projektů. Kdo jimi vnímavě projde a snaží se o systematické zlepšování, ten se k onomu umění propracuje.

Ve většině knih o řízení projektů je hodně pozornosti věnováno tomu, jak uřídit termíny - tedy čas, a náklady - čili rozpočet projektu. K tomu se rovněž váže i řada podpůrných SW nástrojů, které umožňují plánovat a pak sledovat termíny a zdroje na projektu. Jenom nepatrná část SW nástrojů, a rovněž tak knih, se zabývá také věcným sledováním rozpracovanosti vytvářených produktů. A přitom řízení kvality (tj. řízení toho, jak jsou produkty provedeny) je, vedle již popsaného řízení průběhu, řízení změn a řízení rizik, jedním ze čtyř základních témat řízení projektů. Osobně mu přikládám vysoký význam, a proto - na rozdíl od běžné literatury o projektech - doporučuji věnovat sledování rozpracovanosti produktů a jejímu porovnávání s očekávanými výsledky výrazně větší pozornost. Poněvadž projekty se svými produkty velmi výrazně odlišují, je SW podpora definování parametrů výsledků a sledování rozpracovanosti produktů komplikovanější než sledování termínů a zdrojů. Tato podpora vyžaduje velmi efektivní a sofistikovanou práci se znalostmi, jak ukážeme v posledním díle tohoto seriálu.

Obecně vzato, kvalita v řízení projektu znamená udělat to, CO chceme, do KDY to chceme a ZA KOLIK to chceme. Tedy jinými slovy: kvalita v řízení projektu znamená dodržení trojimperativu. To ovšem předpokládá, že projekt je nastartován s takovým trojimperativem, který dodržet lze! Opět se, z jiné strany, dostáváme k definování věcných parametrů výsledku, cíle, nebo-li k určení rozsahu a obsahu řešení. Právě toto, CO máme projektem dosáhnout, je určující pro zbylé dvě dimenze trojimperativu. Velké a smělé cíle nelze dosáhnout v krátkém čase a za málo peněz!

Kde nastala chyba?
Tuto otázku si často klademe, když se nám, či našim dodavatelům, nedaří trojimperativ splnit. Trvání projektu překračuje původně stanovený termín (a to někdy i více než dvojnásobně), náklady na projekt jsou oproti předpokladu zvyšovány (a ještě zvyšovány...). Nakonec třeba i zjistíme, že vlastně nedostaneme ani to, co jsme chtěli, když jsme se rozhodli do projektu investovat. Důvodů je víc. Pokusím se naznačit ty chyby, které se podle mých zkušeností vyskytují nejčastěji.

Nerealistický trojimperativ
Zákazníci většinou chtějí za málo peněz hodně muziky, a to co nejdříve. A jestliže dodavatel chce zakázku získat, tak musí někdy i lhát a tvrdit ve své nabídce, že za těch málo peněz skutečně hodně muziky bude. Neudělá-li to on, udělá to někdo druhý. A tak, jestliže nechce zahynout nedostatkem zakázek, moc jiného mu nezbývá. Že nastanou problémy (v lepším případě) a trojimperativ se nedodrží (v horším případě a častěji), je zřejmé. Vsadím však galon whisky (Chivas Regal), že řada z vás, kteří toto čtete, hned zítra svým rozhodnutím k podobným problémům přispějete.

Podceňování významu souvislostí
Slyšel jsem již hodně generálních ředitelů říkat "to s tím nesouvisí, tím se nezabývejte", například když souběžně s naším projektem informační strategie rozjížděli stamilionové investice nebo třeba připravovali personální strategii, popřípadě když vedle naší systémové integrace běželo ještě stále se táhnoucí dokončované nasazování velkého SW balíku, který byl "z politických důvodů" vyjmut ze soustavy projektů, tvořících systémovou integraci. Neměli pravdu. Souviselo. A často jim to "zlomilo vaz" či přišli o svou židli. O systémové integraci si povíme více v následujícím díle seriálu.

Příliš rizikové vývojové a implementační metody
Doporučení, která jsem uvedl na začátku, mohou někomu připomínat postup v řemeslné výrobě dávných dob, která byla s dramatickou účinností překonána sériovou tovární výrobou v dobách pozdějších. A je tomu tak. Ta doporučení skutečně taková jsou. Mnohé dodavatele proto láká vyjít zákazníkovi vstříc v jeho velmi optimistických představách o čase dodání výsledků projektu. Začnou aplikovat různé akcelerované implementační metodologie, které ruší následnost a nepřekrývání etap a nečekají na odsouhlasení hotového dílčího produktu. Dílčí produkt použijí pro další postup hned, jakmile to stadium jeho rozpracovanosti dovolí, a souběžně je tento produkt dokončován. Akcelerované implementační technologie takto významně zvyšují riziko neúspěchu projektu. Tím, že přestávají být orientovány na produkt, znesnadňují totiž kontrolu souhlasu věcného plnění se specifikací v plánech. To, co činí sériovou výrobu tak efektivní při jejím rutinním opakování, je velmi nebezpečné v projektu, který je jedinečný.

Sebeobelhávání
Další zaručený způsob, který vede k problémům ne-li ke krachu celého projektu. Jak často si všichni říkáme "to přece není nic důležitého, to se samo hned srovná, taková maličkost nemůže ovlivnit celý projekt…", anebo "když jsme tak přesně a vyčerpávajícím způsobem napsali požadavky při vyhlášení poptávky, tak nás dodavatelé již nemohou ničím překvapit!", "když tak pečlivě a formálně dokonale vedeme situační zprávy a záznamy z porad a kontrolních dnů projektu, tak nám žádný náznak, že věci se vyvíjejí nedobře, nemůže uniknout". Nedávno jsem viděl další z řady projektů v objemu desítek milionů korun, které přes všechna tato uvedená přesvědčení zkrachovaly.

Někdy v roce 1990 jsem poprvé četl známou statistiku Gartner Group o úspěšnosti SW projektů. Pouze 12 % všech započatých projektů splní svůj trojimperativ. V 15 % případů se podaří splnit věcnou dimenzi (CO se má udělat) po značných dodatečných investicích (ZA KOLIK) a často až za dvojnásobný čas (KDY). Dalších 30 % projektů po oboustranném vyčerpání zákazníka i dodavatele ustrne na určitém věcném plnění, které sice nenaplňuje původní očekávání CO bude uděláno, ale po mnoha časových skluzech a dodatečných finančních injekcích již nikdo nemá odvahu snažit se naplnění této představy dokončit. Zbylých 43 % započatých projektů není vůbec dopracováno alespoň do jakéhosi kompromisně použitelného stavu. Zajímavé je, že nedávno byla tato čísla publikována znovu. Situace se nijak nezlepšuje. Kde hledat příčinu? Určitě je do značné míry v tom, že zadání toho, co se má projektem informačního systému dosáhnout, je prakticky vždy ne zcela jasné a v průběhu řešení se mění a doplňuje o nové a nové požadavky zákazníků.

Můžeme vůbec u SW projektů očekávat jasné a stabilní zadání toho, co vlastně má být uděláno? Používané paradigma tvorby IS za předpokladu, že ano, vychází. Používané paradigma je znázorněno na obrázku 2. Bez ohledu na konkrétně zvolenou metodu či technologii a její specifické členění problému, vždy v projektech zavádění IS vysledujeme zde uvedených pět fází.

Apriorním a bez diskusí přijímaným faktem evidentně je, že uživatelé, s nimiž provádíme úvodní analýzu, vědí co potřebují. Celý proces zavádění IS je pak o tom, tuto jejich potřebu naplnit. Odpovídá to však skutečnosti? Podle mých zkušeností NE. V každém projektu zavádění IS, kterého jsem se nějak zúčastnil, se v průběhu řešení, a zejména při nasazení do provozu, ukázalo, že teprve rozpracování řešení a předvedení určitých funkčních prototypů umožňuje uživatelům lépe a adekvátněji formulovat, co vlastně potřebují. Tedy požadavky a někdy i cíle se vždy začaly měnit, a to, co na počátku bylo jasné zadání, se později ukázalo být pouze více, či méně detailní metaforou.

Závěr
Asi si dovedeme aspoň trochu představit, jak se vypořádat s chybami, kterými jsme v minulém odstavci začali: nerealistický trojimperativ, podceňování významu souvislostí, příliš rizikové vývojové a implementační metody a sebeobelhávání. K významu souvislostí, ale nejen k němu se ještě vrátíme v příštím díle seriálu o komplexních projektech a pokročilých metodách. Avšak poslední problém - očekávání jasného a stabilního zadání - bude asi složitější. Dokonce i prototypovací metody vývoje SW jej řeší pouze částečně a neuspokojivě. Určité východisko naznačíme v posledním díle seriálu - o managementu znalostí v projektech.

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

www.shine.cz