Od doby vzniku disciplíny označované jako projektové řízení docházelo k podstatným změnám jejího pojetí. Původně byly vyčleněny z obecné teorie řízení techniky určené pro jedinečné a mimořádně významné akce. Proto byly zaměřeny především na posloupnost, provázanost a propojení dílčích samostatně prováděných kroků. Prioritou bylo zvládnutí úkolu, tedy obsah, v terminologii trojúhelníku cílů projektového řízení kvalita či výstup. V praxi se zjistilo, že pro faktický úspěch akce hraje stejně důležitou roli čas. Peníze fakticky přicházejí na řadu až v současné době, kdy projektové řízení sestupuje z piedestalu gigantických akcí typu Apollo či Temelín do podnikové praxe. A ukazuje se, že tradiční přístup ke zkrocení této trojhlavé saně asi nebude stačit.

Kořeny řízení projektů
Předpokládejme, že je oprávněné pochybovat o tom, zda postupy uváděné v autoritativních učebnicích jsou stále platné. Tím rozhodně neříkáme předem, že nejsou, přesněji řečeno nebyly ve své době a v daném kontextu správné. Pouze vycházíme z toho, že je zcela jistě správné ptát se, jestli se nezměnily podstatným způsobem podmínky, ve kterých musíme či chceme příslušné metody využívat. Říká se, že Albert Einstein dal jednou své sekretářce otázky, které měla rozdat studentům skládajícím zkoušku. Sekretářka si je přečetla a namítla: "Ale pane profesore, to jsou stejné otázky, jaké jste dával loni. Nebudou na ně studenti už znát odpovědi?" "Víte, to je v pořádku," odpověděl Einstein, "otázky jsou sice stejné, ale odpovědi se liší." To, co platí pro fyziku, platí i pro podnikání.

Na tom, že se ptáme, zda jsou nabízené nástroje vhodné do našeho prostředí, není nic kacířského. Kladná odpověď nám poskytne klid a jistotu při jejich používání a negativní zase umožní vyhnout se problémům, se kterými bychom se mohli potýkat, kdybychom je používali. Pravděpodobně nám v obou případech pomůže najít lepší řešení, tedy vybrat opravdu účelné nástroje a lépe je chápat. Je podivuhodné, s jakou naivitou se řada z nás obrací k něčemu, co se zdá být spolehlivou jistotou, aniž bychom si ověřili, co se pod důvěryhodným obalem ukrývá. Při vzdělávání v oblasti projektového řízení i v podnikové praxi se setkáváme s přesvědčením, že použití metodiky řízení projektů je klíčovým opatřením, které snadno překryje systémové chyby obchodní politiky, absenci kapacitního plánování, neúčinnou komunikaci, nedostatek odborné kvalifikace či dokonce zásadní chyby motivačního systému. Občas si zodpovědní pracovníci ony systémové chyby ani neuvědomují a téměř nikdy nerespektují, že projektové řízení je vysoce sofistikovanou nadstavbou nad pevnými základy podnikového systému řízení. A že bez základů se nic kloudného postavit nedá.

V naší každodenní praxi se ovšem pod pojmem "projektové řízení" skrývá něco úplně jiného, než měli na mysli autoři klasických pouček z této oblasti. Tradiční pojetí této problematiky, prezentované mimo jiné v řadě odborných článků, zdůrazňuje původní autoritativní pojetí tvorby plánu projektu. Autoritativnost spočívá v historických kořenech pravidel řízení. Vždy bylo nesporné, že ten, kdo zadával úkol, věděl, jakých má být dosaženo výsledků. Což v jistém smyslu znamenalo, že si byl jistý, že těchto výsledků je reálné dosáhnout. Pracoval s lidmi, u kterých bylo rozumné předpokládat, že tomu, co se od nich očekává, poměrně dobře rozumí. Původní pojetí projektového řízení bylo založeno na tom, že existuje detailní technický projekt řešení. Řízení prací nutných k dosažení stanovených cílů bylo z jistého hlediska poměrně jednoduchou koordinací jednoznačně definovaných úkonů vyplývajících z nutnosti dodržet či naplnit daný technický projekt. Bylo to tradiční řízení lidí v rámci velké jedinečné komplexní akce v poněkud odlišných podmínkách, než byla tehdejší podoba rutinních činností.

Tradiční pojetí a realita
Jinými slovy - sestavení projektu (plánu prací) bylo založeno na postupu daném otázkami (uvedenými v dříve publikovaném seriálu) CO - JAK - S KÝM - KDY - ZA KOLIK. Ten je naprosto v pořádku, pokud jsme schopni na začátku této posloupnosti v návaznosti na definici jednotlivých konkrétních výstupů (CO) stanovit také, JAK jich bude dosaženo. Je zřejmé, že základní podmínkou je jasná specifikace zadání. Musí tedy být určen jednoznačný výstup prací. Pokud je dán výstup, je (většinou) pouze technickou záležitostí (a to byl hlavní úkol tradičního projektového řízení) najít kroky, které k jeho splnění vedou. Což je relativně jednoduchá inženýrská činnost. Známe tedy jak výsledek, tak (více či méně) postup, metodu řešení. Není potřeba diskutovat a není dovoleno pochybovat o tom, co všechno je potřeba udělat, jak moc je to obtížné či nejisté - protože už víme JAK. Dosažení výsledků nezávisí na náhodě nebo ochotě toho, kdo zadané činnosti realizuje, ale pouze na dodržení stanoveného postupu.

Výše uvedený scénář odpovídá zmíněnému postupu na základě technické dokumentace, podle které jsme v takovýchto případech projekt (coby souslednost závazně navazujících činností) definovali. Aneb fakticky máme autoritativní (detailní) zadání, ze kterého snadno sestavíme plán prací. Ten je v takovém případě víceméně deterministickou záležitostí, protože obsah, potřebné kapacity s danou kvalifikací a z toho vyplývající časové a finanční nároky jsou dány zadáním. Navíc často není potřeba o tyto zdroje soutěžit s ostatními aktivitami, protože tradiční projekt je skutečně tím nejdůležitějším. Hlavním úkolem manažera projektu je tedy najít optimální souslednost činností, popř. optimální využití kapacit. Vedlejším úkolem je zjistit, které zdroje nejsou dostupné a zajistit je.

Je nutné upozornit, že principem je (cituji ze zmiňovaného seriálu): "Když víme, CO a JAK budeme dělat, máme dostatek podkladů pro určení, S KÝM …" (myšleno, kdo bude danou činnost realizovat). V řadě případů se ovšem - a to je právě situace, která dnes vzniká stále častěji - setkáváme s tím, že bez účasti projektového týmu nejsme schopni dostatečně stanovit, co a jak budeme dělat. Je to dáno tím, že pro smysluplný a realistický odhad nároků jednotlivých kroků potřebujeme zapojit jednotlivé realizátory, protože oni jsou jediní, kteří jsou schopni korektně odhadnout, co je v tom kterém kroku potřeba udělat. Dostáváme se do situace, že z lidí, kteří mají nejlepší předpoklady (v horším případě z těch, kteří jsou právě k dispozici) sestavíme tým a dáváme mu (často nejednoznačné) zadání a chceme po něm, aby si vytvořil plán prací, kde není daným faktorem kvalita (věcné zadání), ale spíše čas a peníze.

Bezpochyby je takový postup také možný a v řadě případů účelný. Jenom není tak dobře popsán, jako jsou tradiční, podstatně více mechanické přístupy. Jednoznačně je náročnější, protože hledáme věcné zadání, které bude vyhovovat stanoveným limitům, což znamená navrhnou množinu zadání, prověřit jejich nároky a vybrat to nejlepší zadání, které je ještě možné realizovat. Spornou oblastí v takovém projektu je pochopitelně postavení zadavatele, který musí přistoupit na to, že se jedná o hledání "co nejužitečnějšího" využití disponibilních zdrojů vzhledem k danému problému. Jenže obvyklým scénářem není ani tento případ, naopak - spíše jsou určeny předem všechny složky trojimperativu. Potom se vedoucí projektu dostává do situace, kdy neplatí žádné racionální argumenty a není možné nalézt splnitelný scénář (vyjma případů, kdy je náhodou zadání naopak zbytečně "měkké").

Zdroj problémů
Při analýze požadavků a potřeb firem, které se snaží o rozvoj systémů řízení, se nejčastěji ukazuje, že tradiční pojetí projektů přestává vyhovovat. Čím více se řízení mimořádných aktivit s využitím metodiky klasického projektového řízení vzdaluje od obvyklého pojetí (tedy velmi rozsáhlé a velmi významné akce), tím více je zřejmé, že řízení takovýchto aktivit není záležitostí zvládnutí zázračné metodiky. Není pravděpodobné, že by někdo, kdo "umí řídit projekty", dělal zázraky. Nelze oddělovat projekty od běžného života firmy, naopak je nutno je do něj integrovat.

Dramatickou chybou, které se dopouštějí právě firmy z branže ICT, je to, že se domnívají, že jejich (všechny nebo ty klíčové) činnosti jsou projekty a mají být řízeny projektově. Vždyť přece to, že pro zákazníka se (velmi často) jedná o projekt (mimořádná jednorázová aktivita), neznamená, že pro dodavatele je to také mimořádná jednorázová aktivita. Sporným tématem je, nakolik je přípustné, korektní a účelné (a výhodné pro některou ze zúčastněných stran) přenášet řízení projektů na dodavatele. To sem ale nepatří. V naprosté většině případů se bude jednat z hlediska řízení (organizace práce) činností uvnitř dodavatelské firmy o procesy. To, že se ty procesy týkají pokaždé poněkud jiné věcné podstaty (dodávky), neznamená, že se jedná o projekt. Vždyť nakonec každé auto na výrobní lince je jiné a fakticky je jiný i každý pytlík pracího prášku. Nejlepší je položit si otázku, zda se např. u vývoje standardního programového vybavení jedná o projekty nebo "průmyslovou činnost". Zda služby (včetně vývoje individuálního řešení) jsou projekty nebo rutinní provoz.

Tato úvaha ale rozhodně není věnována řízení zakázek projektového charakteru (náplň dalšího článku). Pojmem projekt označujeme v souladu s obecným pojetím této disciplíny významnou, komplexní, jedinečnou a rozsáhlou akci, např. vývoj nového produktu, inovace podnikového informačního systému, změna systému řízení apod. V této souvislosti je dobré vymezit pojem projekt i z druhé strany - jako projekt rozhodně nechápeme jednoduché zadání (např. z porady), u kterého objektivně není účelné sestavovat plán prací dle metodiky projektového řízení, nevyžaduje (rozsáhlou) součinnost ostatních útvarů atd. Často se můžeme setkat s rozlišením typu "pokyn" (což je zadání pro jednoznačné a známé činnosti) a "úkol" (což je zadání, u kterého není předem známý způsob řešení). Pokud je zadání natolik jednoduché, aby je s jednoznačně vyžádanou součinností jiných pracovníků zvládl jedinec, není potřeba pro řešení vytvářet "projekt".

Jako nejčastější problémy při realizaci akcí řízených projektovým způsobem (viz článek Problémy projektového controllingu) jsou uváděny:

. Nejasný systém hodnocení a stanovení přínosů.
. Nedostatek zdrojů všech typů (kvalita plánu).
. Časté změny požadavků (technické zadání).
. Součinnost ostatních částí firmy.
. Přetěžování lidí - obecně využití kapacit.

Jinými slovy, nedaří se nám sestavit plány prací v projektech tak, aby podle nich bylo možné projekty skutečně úspěšně řídit, a neumíme správně motivovat pracovníky, zapojení do těchto činností. Už vůbec se nám nedaří skutečně efektivně používat osvědčené metody projektového řízení (či spíše řízení obecně), zejména průběžně aktualizovat plány prací, informovat o posunech termínů, identifikovat problémové činnosti a soustřeďovat na ně dostupné zdroje. To bohužel souvisí s nedostatečnou funkčností nástrojů pro podporu projektového řízení. Jednou ze slabin je i to, že většinou nepodporují napojení na základní podnikový informační systém. Ovšem mnohem větším problémem je naše víra v to, že nasazením nejlepšího (nejdražšího) možného systému se naše potíže s řízením mimořádných aktivit samy od sebe vyřeší. Zkušenosti říkají, že náročné a komplikované činnosti se s počítači dělají často obtížněji než bez nich (k tomuto tématu se vrátíme v dalších částech).

Kompetence
Společnou základní příčinou je pravděpodobně nedostatečná kvalifikace firmy (je myšleno vrcholové vedení) v oblasti metod řízení (mimo jiné neochota rozvíjet formalizované metody řízení), nedostatečná funkčnost systému řízení (to se týká získávání, zpracování a dostupnosti potřebných dat, možností a kvalifikace lidí v oblasti faktické správy znalostí), nevyjasněné strategické zásady a nefunkční motivační systém. K tomu patří neúčinné metody formalizace problémů, správa zásobníku potenciálních zadání, správa příležitostí, schopnost identifikovat přínosy, formulace úkolů (v širším slova smyslu) a nevyhovující hodnocení výkonnosti. Což znamená nedostatečná nebo nevhodná metodika řízení projektů. Velká část organizací - a týká se to i takových, u kterých je to životní nutnost - nemá funkční směrnici pro řízení projektů. Projekty se sestavují pokaždé jinak podle toho, jakou představu má vedoucí projektu (horším případě, jak se to líbí zadavateli).

Pokusme se polemizovat s tradičním přístupem. Samozřejmě musí být tato polemika zjednodušená a vyhraněná. Jejím smyslem je pokusit se upozornit, ke kterým obvyklým metodám a znalostem je potřeba přistupovat obzvlášť opatrně. Takže pokud víme, "co" a "jak" je potřeba dělat, je sporné, nakolik je účelné označovat koordinaci činností nad definovaným obsahem a postupem jako projektové řízení. Resp. znovu a znovu se nám vnucuje otázka, co je ve skutečnosti podstatou projektového řízení. Nebudeme se snažit na tuto otázku jednoduše odpovědět. Každá jednoduchá odpověď nese příliš velké riziko nepřípustného zjednodušení. Budeme se snažit najít všechny podstatné otázky, které s tímto problémem souvisí.

Zejména bude takováto pochybnost užitečná v dnešním světě, kdy téměř všechno, co se kolem nás děje, má vysoce proměnlivý charakter. Když víme, co a jak je potřeba udělat, je možné poskytnout vybraným realizačním pracovníkům splnitelné, víceméně jednoznačné zadání (většinou včetně času a spotřeby zdrojů). Nepředpokládáme (není nezbytností) jejich tvůrčí přístup a vysokou variabilitu (nejistotu) provedení s vysokými nároky na komunikační zajištění prováděných činností. Tedy s nutností vybudovat kolem takto řízených činností zvláštní opatření v oblasti plánování, vykazování, kontroly, komunikace a motivace. Nemáme problém s kontrolou kvality a termínů ani s odměňováním. Faktickou výzvou jsou pouze obtíže při efektivním začlenění takto definovaných činností mezi ostatní podnikové aktivity.

U klasických projektů se často využívala taková organizace, kdy lidé byli vyčleněni výhradně pro potřebu projektu. Tady můžeme vidět nejdůležitější odchylku od principů uváděných v dostupných materiálech. A je zřejmé, že pokud se liší organizační pravidla (principy přidělování pravomocí a určování zodpovědnosti), tak se budou muset lišit i metody řízení. Organizace aktivit projektového charakteru je zejména v souvislosti s moderními přístupy k týmové práci, motivaci, komunikaci a ostatním prvkům řízení lidí samostatným, velice náročným a obsáhlým tématem, kterému se budeme věnovat v další části tohoto článku. Zvláštní pozornost budu právě této oblasti věnovat na podzimních vzdělávacích akcích. Třetí část tohoto článku přinese analýzu zkušeností z reálného projektu a také vstup do otázky, zda a nakolik je vývoj softwaru projektovou činností.