- Přehledy IS
- APS (25)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (31)
- CRM (52)
- DMS/ECM - správa dokumentů (19)
- EAM (17)
- Ekonomické systémy (68)
- ERP (75)
- HRM (28)
- ITSM (6)
- MES (33)
- Řízení výroby (36)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (41)
- Dodavatelé CRM (38)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (66)
- Informační bezpečnost (48)
- IT řešení pro logistiku (48)
- IT řešení pro stavebnictví (26)
- Řešení pro veřejný a státní sektor (27)
Tematické sekce


















Branžové sekce
![]() | Přihlaste se k odběru zpravodaje SystemNEWS na LinkedIn, který každý týden přináší výběr článků z oblasti podnikové informatiky | |
![]() | ||
Partneři webu
IT SYSTEM 12/2003
Čas a znalosti
Praktické zkušenosti ze světa projektů
Petr Opletal
Nová doba přináší nové pojetí řízení. Není pochyb o tom, že pro zvládnutí výjimečných rozsáhlých komplexních akcí úspěšně využíváme řízení projektů. Jedinečné aktivity prostě nelze řídit stejně jako rutinní činnosti. Ale jak umíme v běžné praxi nasadit metody projektového řízení? Co mají projekty a procesy společného? Co děláme při řízení projektů v naší chaotické době dobře, a co špatně?
Na tyto otázky se pokusíme najít odpověď. V předchozích dvou částech jsme se snažili najít rozpory mezi obvyklým a moderním pojetím projektového řízení a identifikovat nejdůležitější faktory, které ovlivňují využití projektových metod. Některé situace v tomto článku vycházejí z reálného projektu, který má za úkol komplexní rozvoj řízení. Jsou ovšem modifikovány jinými zkušenostmi a pro srozumitelnost dotaženy do extrému. Jak to tedy je s projektovým řízením? Jak to, co přináší pozitivního, správně využít?
Když v podniku všechno funguje, jak má, není potřeba mimořádných aktivit. Není tedy potřeba ani projektové řízení. Jakmile ovšem vyvstane potřeba „něco“ změnit, je taková záležitost většinou naléhavá, občas hodně naléhavá. Vyžaduje změnu, která má nebo může mít rozsáhlé důsledky a je potřeba ji provést co nejrychleji. Dost často existují dokonce termíny, ke kterým je žádoucí, či nutné, aby práce byla hotová. Z toho ovšem vyplývá, že ta úroveň zadavatelů (v případě firmy majitelé), která si přeje co nejdříve začít využívat výsledky uvažované změny, více či méně naléhá na co nejrychlejší spuštění prací. Určitě to všichni známe – když už víme, co je potřeba udělat, připadá nám samotným naprosto jednoduché to udělat, jinými slovy, „už je to hotové“.
Čas na zadání
Proto bývá obtížné, nebo občas nemožné dohodnout dostatečně korektní a přesný plán prací. V onom zmíněném konkrétním projektu byl pro nultou etapu připraven relativně nezávislý plán prací, který vycházel z toho, že všechno, co bylo potřeba udělat, bylo víceméně jednoznačné. Zadání pro tuto první etapu bylo jasné. Byl jasný i postup, jakým ho dosáhneme. Tím i čas a náklady. Tedy byl k dispozici realistický plán prací, které se podařilo dodržet. Navazující etapa již tak jednoznačná nebyla a bylo zjevně potřeba provést důkladnou přípravu (časově náročnou s nejistými výsledky) pro „zmapování terénu“, a především pro stanovení jasných srozumitelných měřitelných výsledků. Přes výrazné úsilí, které jsme vynaložili pro zajištění odpovídající přípravy, nepodařilo se odpovídající plán prací stvořit. Hlavním důvodem byl (zdánlivě) kritický (fatální) termín, kdy bylo potřeba tuto etapu ukončit. Proto byl přijat plán prací, který byl nepřijatelně obecný a vzhledem k tomu, že byly zcela nerealisticky a vágně formulovány požadavky na výsledky, byl fakticky nesmyslný. Etapa byla urychleně zahájena.
Při určitém zjednodušení lze orientačně odhadnout, že na začátku etapy (díky tomu, že se vše neuvěřitelným způsobem komplikovalo dezorientací celého týmu) se spotřebovalo na vyjasnění toho, co se vlastně má dělat, dvoj- až pětinásobek času, který by byl potřeba na důslednou přípravu. Je asi pravda, že při správné přípravě bychom asi dospěli k závěru, že navrhovaná etapa (resp. to, co jsme potřebovali jako její výstup) se musí uskutečnit poněkud jiným způsobem, možná bychom museli redukovat očekávané výstupy a tomu přizpůsobit další postup projektu. Nic z toho se ovšem nestalo.
Jenom pro dokončení popisu situace – etapa byla víceméně násilně ukončena měsíc poté, co vypršel onen „kritický“ termín. Výsledky byly naprosto mizivé. A jejich absence kriticky zkomplikovala další postup projektu. Ve všech metodikách a doporučeních najdeme důrazné varování před ukvapeným zahájením prací. Jako jedna z nejčastějších příčin neúspěchů se uvádí nedostatečná příprava. I přísloví říká „dvakrát měř …“. Kde je tedy příčina naší nepoučitelnosti? Co nás vede neustále k nesmyslnému spěchu a nedůslednosti? Všichni přece víme, nebo tušíme, že čím méně času věnujeme přípravě, tím hůř se nám to vymstí při realizaci. Svou roli může hrát náročnost problému, nezkušenost vedoucího projektu a tisíc dalších důvodů. Je ale pravděpodobné, že ze systémového hlediska je primární příčina v podcenění, nebo ignorování pochopení a oddělení rolí zadavatele a realizátora.
Zadavatel a realizátor
Setkal jsem se se zajímavou otázkou. Jednomu projektovému týmu, který pracoval na úkolu strategického rozvoje, nebylo jasné, kdo je vlastně zadavatelem a jestli zadavatele skutečně nezbytně nutně potřebují. Dokonce to bylo formulováno tak, že se jim to „násilné oddělování rolí“ nelíbí. Tvrdili, že onen úkol si zadali sami, že jsou sami sobě zadavatelem. Byla to typická situace, kdy byl velmi obecně či vágně formulován zájem (když bychom to zjednodušili, tak v poloze „vymyslete (a udělejte) něco, co společnosti umožní vydělávat více peněz“) a tým samotný byl pověřen naplnit toto zadání obsahem. Dokonce ani nebyl jmenován vedoucí projektu. Tým má dojem, že si zadává úkol sám. V podstatě to tak obvykle je – konkrétní úkoly by si měl realizátor vždy zadávat sám. Ale úkol není zadání. Zadání není to, jak a co se má dělat. Zadání říká, k čemu to má být užitečné. Jakou roli má tedy hrát zadavatel?
Zadavatel by měl být ten subjekt, který zodpovídá za racionální využívání disponibilních zdrojů pro uspokojování potřeb na vyšší úrovni, než na které je on sám. V uvedeném případě to byl mnohamilionový rozpočet akce zaměřené na získání lepší pozice na trhu. Vždy ale platí, že kdyby o nic jiného, tak jde o čas těch lidí, kteří jsou do akce zapojeni. Zadavatel má nezpochybnitelnou roli, ve které musí posoudit realističnost navrhovaných postupů a odhadovaných výsledků. Zadavatel je realizátor projektového záměru, tedy on je ten, kdo „dostane“ výstupy projektu a bude s nimi muset „vydělávat více peněz“. Tato zodpovědnost se nedá přenést na vedoucího akce, která má zajistit nástroje, jejichž pomocí se možná dá více peněz vydělávat.
Možná není úplně zřetelně vidět, proč to nejde. Ale když použijeme elementární pravidla teorie řízení, zjistíme, že tento systém postrádá zpětnou vazbu. Jinými slovy kapři si nevypouštějí rybník. A to platí bez ohledu na to, jak kvalitní spolupracovníky zaměstnáváme, bez ohledu na jejich motivy a priority. Zpětnou vazbu potřebuje každý cílově orientovaný mechanismus. Na úrovni projektového záměru „vydělávat více peněz“ je to zpětná vazba ze strany vlastníků (investorů) a jejich výkonných orgánů. Sám sobě nikdy nemohu poskytnout objektivizaci kritérií pro hodnocení výsledků vlastní práce. Proto člověk, který je pověřen úkolem „vymyslet něco, co umožní vydělávat víc peněz“, potřebuje kritickou zpětnou vazbu, která mu řekne, „dobře, ale když to, co jsi tady vymyslel, nezvládneš, tak tě nikdo v branži už nenechá ani umývat podlahu“. To sám sobě říci nemohu. Navíc je potřeba, aby zadavatel vytvořil podmínky očekávané projektem. To také není, a nemůže být v kompetenci vedoucího projektu. Ten může hospodařit se zdroji, které mu byly pro projekt svěřeny, ale nemůže rozhodovat o okolí projektu, respektive úrovni vstupů do projektu.
V našem projektu komplexního rozvoje systému řízení se projevil jeden z nejčastějších problémů našich dosud nevyspělých struktur podnikové správy. Je tisíc různých názorů a důvodů pro, a proti tomu, aby vlastníci byli současně manažery svých podniků. Toto téma má hodně společného se situací, kdy manažeři jsou odměňováni a motivováni majetkovou spoluúčastí (i když i to je hodně sporné téma). Z logiky věci ovšem vyplývá, že vlastníci mají zcela protichůdné zájmy a přístup než manažeři. Zde byl majoritní vlastník současně vrcholovým manažerem a z logiky věci (a také proto, že ve vrcholovém vedení nebyl nikdo, kdo by mohl být podobným projektem pověřen) se ve skutečnosti stal i vedoucím projektu komplexního rozvoje (i když formálně byl vedením projektu pověřen někdo jiný). Seznam zásadních chyb a průšvihů, které se v takovém projektu staly a ještě musí stát, si jistě na základě vlastních zkušeností sestaví každý sám.
Projekty nejsou rutina
Co se stane, když nemáme pro řízení projektu dostatečně kvalifikovaného a zkušeného projektového manažera? Obvykle situace, která byla na začátku přiblížena – už je jasné, co je potřeba udělat, je to tedy vlastně hotové. A čím méně dané problematice vedoucí projektu rozumí, tím „rychleji“ je to hotovo. V našem případě jsme se chtěli poučit a pro následující etapu jsme se rozhodli připravit podrobný plán prací. Přesně v tom duchu, že etapa bude obsahovat jen to, o čem jsme skálopevně přesvědčeni, že obsahovat má. Budeme vědět, co a jak se bude dělat. Což je obecně zcela správné rozhodnutí, naprosto dle doporučení „když není zcela jisté, jak má projekt probíhat, plánujte na tak dlouho a jen ty činnosti, o kterých to neplatí“.
Jinými slovy, rozhodli jsme věnovat přípravě právě tolik času, kolik je nezbytně nutno. Tolik času, kolik je potřeba pro vysvětlení a shodu o tom, co se musí udělat a proč. Odvodit, jak dlouho to má trvat, kolik zdrojů to spotřebuje a jaké mají jednoduché měřitelné výsledky. Etapa měla trvat přibližně měsíc. Dopadlo to tak, že po šesti týdnech přípravy (fakticky začala příprava ještě o dva týdny dříve uprostřed předchozí etapy) ve třetím kole přepracovávání plánu prací zazněla památná věta: „Abychom věděli, jak to má dopadnout, museli bychom to nejdřív udělat.“. Fakticky to znamená, že zadavatel nemá dost síly ověřit si, zda navrhovaný postup a navrhované výsledky připravovaných prací jsou realistické a uspokojí jeho potřeby. V podstatě to znamená, že problematiku nezvládá dostatečně a proto také není možné si pod navrhovaným postupem a výstupy představit nic srozumitelného. Zcela jistě je tato situace také indikací, že faktické potřeby nejsou dostatečně dobře „známy“.
Od těch dob celý slavný „projekt“ komplexního rozvoje není řízen projektově (ačkoli se tomu tak říká), ale naprosto živelně, přesně dle zadání „něco udělat“ … a až to bude hotové, tak se zamyslíme nad tím, jestli je to k něčemu dobré. Což je pochopitelně přehnaně negativní vylíčení situace. Bohužel nutno říci, že většina podobných aktivit, zejména v oblasti vývoje software a jiných aktivit v oblasti ICT, probíhá velmi podobně. Typickým dokladem je to, když se akceptační kritéria etapy formulují v den akceptace (popř. se žádnou akceptací „nezdržujeme“). Z této zkušenosti vyplývají dvě hlavní otázky: zda se mělo a mohlo (popř. čí je to selhání) z hlediska korektnosti řízení projektu postupovat v dané situaci jinak, a pokud ano, tak jak?
Ocitáme se zdánlivě v bludném kruhu. V moudrých knihách kromě toho, že říkají „věnujte dostatečný čas přípravě“, najdeme i rozporuplné prohlášení, „nevěnujte plánování více času, než byste spotřebovali na odstraňování problémů vzniklých tím, že žádný plán mít nebudete“. To fakticky znamená, že neumíme žádným obecným způsobem určit, co je „dostatečná“ příprava. U akcí, které se zabývají něčím, co je opravdu mimořádné a jedinečné, téměř automaticky nevíme, co všechno potřebujeme, a nevíme ani to, jaké mají být výsledky. Je jenom otázka, jestli bychom se do takových akcí měli pouštět.
Operativní řízení projektu
Pokud se přesto pustíme do akce, která není připravena ani tak, že bychom věděli, jaké má mít jednoznačné výstupy nebo projektový manažer není ochoten zodpovědně garantovat to, že stanovené výstupy se podaří dosáhnout v termínu, musíme se smířit s tím, že takovou akci budeme muset řídit nikoli projektově, ale operativně. V takovém případě projektový manažer nenese žádnou zodpovědnost a stává se pouhým vykonavatelem příkazů. V našem projektu se asi nijak jinak postupovat nedalo a vše nasvědčuje tomu, že v důsledku těchto zkušeností byl iniciován (byť zatím víceméně živelný) proces kultivace a zdokonalování. Víceméně se daří uplatnit mechanismus, který se snaží vypořádat se se situací a převést živelné řízení projektu do přijatelné podoby.
Cílem takového operativního řízení mimořádných aktivit by se mělo stát vytvoření podmínek, a to zejména v oblasti znalostí, k tomu, aby mohla být tato mimořádná aktivita převedena do režimu projektového řízení. Byť by to bylo řízení „nejasného“ projektu, tedy po etapách. Jenom tak můžeme přenést zodpovědnost za průběh prací na někoho jiného než zadavatele. A zadavatel by se ze své podstaty neměl zabývat operativním řízení činností, protože existuje jen omezený počet zadavatelů a jejich kapacita není nevyčerpatelná. Rozhodně by to mělo být tak, že kapacity zadavatele jsou využitelné jiným způsobem s výrazně vyšším užitkem. Právě proto musí být ve větších firmách (organizacích) strukturovaný systém řízení, prostě není možné, aby všechno řídil jediný člověk.
Když to tedy shrneme, v uvedených příkladech byla jednoznačně příčina nekorektního postupu na straně zadavatele (velmi dobře je to vidět v případě, kdy zcela „chybí“ vedoucí projektu). Jednoduché doporučení – to, že k něčemu takovému dojde, je signál, že zadavatel je přetížený, není schopen ani identifikovat chyby, kterých se dopouští. Je tedy nezbytně nutné část jeho aktivit přesunout na jiného pověřeného pracovníka. Zadavatel by neměl spouštět projekty, u kterých mu chybí způsob posouzení jejich realističnosti. Buď dané problematice rozumím natolik, že jsem schopen vyhodnotit, zda to, co se má dít, je reálné, nebo připouštím nepřijatelně vysokou pravděpodobnost neodhadnutelných ztrát.
Pro řešení případného kritického stavu, kdy je zjevné, že se „něco“ udělat musí, a to hned, přitom není reálné získat bezprostředně dostatek informací a znalostí pro posouzení realističnosti, je možné použít externí audit projektu. Ale rozhodně je nezbytně nutné vytvořit základní systémové předpoklady – stanovit pravidla pro řízení projektů. Bez jasně formulovaných zásad, závazných postupů a formalizace informací nebude možné provést ani vlastní, ani externí kontrolu toho, zda je projekt připraven a zda je realistický.
Proces projektového řízení
Zní to poněkud rozporuplně. Když je něco projekt, tak to není proces. Ale pozor, nemluvíme o projektu (a fakticky ani o řízení jednotlivého projektu). Projektovým řízením je zde míněno především okolí projektů. Přesněji řečeno schopnost organizace řídit několik souběžných jedinečných aktivit. To velmi zjednodušeně znamená stanovení pravidel pro to, co musí být nezbytně nutně provedeno a dodrženo pro jejich spuštění, průběh a ukončení. Plně to odpovídá provedené analýze problémů při řízení projektů a jejich příčin, kdy se u kořene příčin všech problémů objevuje nedostatečná příprava, nevyhovující komunikace, neúčinná koordinace, špatné zadání a jako společný důvod byla identifikována nízká kvalifikace organizace pro projektové řízení.
Tím je myšleno to, že standardní činnosti, které v organizaci kolem řízení mimořádných aktivit probíhají, musí být závazným způsobem určeny a podporovány příslušnou informační infrastrukturou stejně jako všechny ostatní procesy. Dostatečně podrobná a srozumitelná analýza všeho toho, co by mělo být v procesu projektového řízení zajištěno, překračuje možnosti a záměr tohoto článku. Možná by stálo za to zdůraznit informační infrastrukturu, kterou je potřeba pro úspěšné řízení projektů využívat. Množství a nezbytně nutná kvalita informací, které potřebujeme, zcela vylučuje jakákoli provizoria a improvizaci.
Takže co doporučit – jednoznačně klíčovým prvkem je zvyšování „projektové“ kvalifikace firem. To znamená přizpůsobit celopodnikový systém řízení tomu, že bude existovat čím dál více komplexních jedinečných akcí, které musí být řízeny projektově. Tím se nemyslí (pouze) vysedávání na školeních, věnovaných jednoduchým a nepoužitelným teoretickým poučkám, ale aktivní hledání cesty, jak a které náměty a myšlenky tvůrčím způsobem využít v podnikové praxi. Bez vzdělávání vrcholových manažerů a vytváření nejlepších možných podmínek pro potenciální projektové manažery to samozřejmě nepůjde. Ale je to pouze první krok. To, co musíme udělat, je „naučit“ firmu žít společně s projekty. Nic jiného nám totiž nezbývá. Tlak prostředí po nás již dnes vyžaduje, abychom na změny situace reagovali systémově a komplexně. Prostřednictvím řízené změny. Změnu můžeme řídit pouze s využitím pravidel projektového řízení. Pokud si to dnes ještě nepřipouštíme, zítřek nás pravděpodobně přesvědčí o tom, že jsme udělali chybu.


Na tyto otázky se pokusíme najít odpověď. V předchozích dvou částech jsme se snažili najít rozpory mezi obvyklým a moderním pojetím projektového řízení a identifikovat nejdůležitější faktory, které ovlivňují využití projektových metod. Některé situace v tomto článku vycházejí z reálného projektu, který má za úkol komplexní rozvoj řízení. Jsou ovšem modifikovány jinými zkušenostmi a pro srozumitelnost dotaženy do extrému. Jak to tedy je s projektovým řízením? Jak to, co přináší pozitivního, správně využít?
Když v podniku všechno funguje, jak má, není potřeba mimořádných aktivit. Není tedy potřeba ani projektové řízení. Jakmile ovšem vyvstane potřeba „něco“ změnit, je taková záležitost většinou naléhavá, občas hodně naléhavá. Vyžaduje změnu, která má nebo může mít rozsáhlé důsledky a je potřeba ji provést co nejrychleji. Dost často existují dokonce termíny, ke kterým je žádoucí, či nutné, aby práce byla hotová. Z toho ovšem vyplývá, že ta úroveň zadavatelů (v případě firmy majitelé), která si přeje co nejdříve začít využívat výsledky uvažované změny, více či méně naléhá na co nejrychlejší spuštění prací. Určitě to všichni známe – když už víme, co je potřeba udělat, připadá nám samotným naprosto jednoduché to udělat, jinými slovy, „už je to hotové“.
Čas na zadání
Proto bývá obtížné, nebo občas nemožné dohodnout dostatečně korektní a přesný plán prací. V onom zmíněném konkrétním projektu byl pro nultou etapu připraven relativně nezávislý plán prací, který vycházel z toho, že všechno, co bylo potřeba udělat, bylo víceméně jednoznačné. Zadání pro tuto první etapu bylo jasné. Byl jasný i postup, jakým ho dosáhneme. Tím i čas a náklady. Tedy byl k dispozici realistický plán prací, které se podařilo dodržet. Navazující etapa již tak jednoznačná nebyla a bylo zjevně potřeba provést důkladnou přípravu (časově náročnou s nejistými výsledky) pro „zmapování terénu“, a především pro stanovení jasných srozumitelných měřitelných výsledků. Přes výrazné úsilí, které jsme vynaložili pro zajištění odpovídající přípravy, nepodařilo se odpovídající plán prací stvořit. Hlavním důvodem byl (zdánlivě) kritický (fatální) termín, kdy bylo potřeba tuto etapu ukončit. Proto byl přijat plán prací, který byl nepřijatelně obecný a vzhledem k tomu, že byly zcela nerealisticky a vágně formulovány požadavky na výsledky, byl fakticky nesmyslný. Etapa byla urychleně zahájena.
Při určitém zjednodušení lze orientačně odhadnout, že na začátku etapy (díky tomu, že se vše neuvěřitelným způsobem komplikovalo dezorientací celého týmu) se spotřebovalo na vyjasnění toho, co se vlastně má dělat, dvoj- až pětinásobek času, který by byl potřeba na důslednou přípravu. Je asi pravda, že při správné přípravě bychom asi dospěli k závěru, že navrhovaná etapa (resp. to, co jsme potřebovali jako její výstup) se musí uskutečnit poněkud jiným způsobem, možná bychom museli redukovat očekávané výstupy a tomu přizpůsobit další postup projektu. Nic z toho se ovšem nestalo.
Jenom pro dokončení popisu situace – etapa byla víceméně násilně ukončena měsíc poté, co vypršel onen „kritický“ termín. Výsledky byly naprosto mizivé. A jejich absence kriticky zkomplikovala další postup projektu. Ve všech metodikách a doporučeních najdeme důrazné varování před ukvapeným zahájením prací. Jako jedna z nejčastějších příčin neúspěchů se uvádí nedostatečná příprava. I přísloví říká „dvakrát měř …“. Kde je tedy příčina naší nepoučitelnosti? Co nás vede neustále k nesmyslnému spěchu a nedůslednosti? Všichni přece víme, nebo tušíme, že čím méně času věnujeme přípravě, tím hůř se nám to vymstí při realizaci. Svou roli může hrát náročnost problému, nezkušenost vedoucího projektu a tisíc dalších důvodů. Je ale pravděpodobné, že ze systémového hlediska je primární příčina v podcenění, nebo ignorování pochopení a oddělení rolí zadavatele a realizátora.
Zadavatel a realizátor
Setkal jsem se se zajímavou otázkou. Jednomu projektovému týmu, který pracoval na úkolu strategického rozvoje, nebylo jasné, kdo je vlastně zadavatelem a jestli zadavatele skutečně nezbytně nutně potřebují. Dokonce to bylo formulováno tak, že se jim to „násilné oddělování rolí“ nelíbí. Tvrdili, že onen úkol si zadali sami, že jsou sami sobě zadavatelem. Byla to typická situace, kdy byl velmi obecně či vágně formulován zájem (když bychom to zjednodušili, tak v poloze „vymyslete (a udělejte) něco, co společnosti umožní vydělávat více peněz“) a tým samotný byl pověřen naplnit toto zadání obsahem. Dokonce ani nebyl jmenován vedoucí projektu. Tým má dojem, že si zadává úkol sám. V podstatě to tak obvykle je – konkrétní úkoly by si měl realizátor vždy zadávat sám. Ale úkol není zadání. Zadání není to, jak a co se má dělat. Zadání říká, k čemu to má být užitečné. Jakou roli má tedy hrát zadavatel?
Zadavatel by měl být ten subjekt, který zodpovídá za racionální využívání disponibilních zdrojů pro uspokojování potřeb na vyšší úrovni, než na které je on sám. V uvedeném případě to byl mnohamilionový rozpočet akce zaměřené na získání lepší pozice na trhu. Vždy ale platí, že kdyby o nic jiného, tak jde o čas těch lidí, kteří jsou do akce zapojeni. Zadavatel má nezpochybnitelnou roli, ve které musí posoudit realističnost navrhovaných postupů a odhadovaných výsledků. Zadavatel je realizátor projektového záměru, tedy on je ten, kdo „dostane“ výstupy projektu a bude s nimi muset „vydělávat více peněz“. Tato zodpovědnost se nedá přenést na vedoucího akce, která má zajistit nástroje, jejichž pomocí se možná dá více peněz vydělávat.
Možná není úplně zřetelně vidět, proč to nejde. Ale když použijeme elementární pravidla teorie řízení, zjistíme, že tento systém postrádá zpětnou vazbu. Jinými slovy kapři si nevypouštějí rybník. A to platí bez ohledu na to, jak kvalitní spolupracovníky zaměstnáváme, bez ohledu na jejich motivy a priority. Zpětnou vazbu potřebuje každý cílově orientovaný mechanismus. Na úrovni projektového záměru „vydělávat více peněz“ je to zpětná vazba ze strany vlastníků (investorů) a jejich výkonných orgánů. Sám sobě nikdy nemohu poskytnout objektivizaci kritérií pro hodnocení výsledků vlastní práce. Proto člověk, který je pověřen úkolem „vymyslet něco, co umožní vydělávat víc peněz“, potřebuje kritickou zpětnou vazbu, která mu řekne, „dobře, ale když to, co jsi tady vymyslel, nezvládneš, tak tě nikdo v branži už nenechá ani umývat podlahu“. To sám sobě říci nemohu. Navíc je potřeba, aby zadavatel vytvořil podmínky očekávané projektem. To také není, a nemůže být v kompetenci vedoucího projektu. Ten může hospodařit se zdroji, které mu byly pro projekt svěřeny, ale nemůže rozhodovat o okolí projektu, respektive úrovni vstupů do projektu.
V našem projektu komplexního rozvoje systému řízení se projevil jeden z nejčastějších problémů našich dosud nevyspělých struktur podnikové správy. Je tisíc různých názorů a důvodů pro, a proti tomu, aby vlastníci byli současně manažery svých podniků. Toto téma má hodně společného se situací, kdy manažeři jsou odměňováni a motivováni majetkovou spoluúčastí (i když i to je hodně sporné téma). Z logiky věci ovšem vyplývá, že vlastníci mají zcela protichůdné zájmy a přístup než manažeři. Zde byl majoritní vlastník současně vrcholovým manažerem a z logiky věci (a také proto, že ve vrcholovém vedení nebyl nikdo, kdo by mohl být podobným projektem pověřen) se ve skutečnosti stal i vedoucím projektu komplexního rozvoje (i když formálně byl vedením projektu pověřen někdo jiný). Seznam zásadních chyb a průšvihů, které se v takovém projektu staly a ještě musí stát, si jistě na základě vlastních zkušeností sestaví každý sám.
Projekty nejsou rutina
Co se stane, když nemáme pro řízení projektu dostatečně kvalifikovaného a zkušeného projektového manažera? Obvykle situace, která byla na začátku přiblížena – už je jasné, co je potřeba udělat, je to tedy vlastně hotové. A čím méně dané problematice vedoucí projektu rozumí, tím „rychleji“ je to hotovo. V našem případě jsme se chtěli poučit a pro následující etapu jsme se rozhodli připravit podrobný plán prací. Přesně v tom duchu, že etapa bude obsahovat jen to, o čem jsme skálopevně přesvědčeni, že obsahovat má. Budeme vědět, co a jak se bude dělat. Což je obecně zcela správné rozhodnutí, naprosto dle doporučení „když není zcela jisté, jak má projekt probíhat, plánujte na tak dlouho a jen ty činnosti, o kterých to neplatí“.
Jinými slovy, rozhodli jsme věnovat přípravě právě tolik času, kolik je nezbytně nutno. Tolik času, kolik je potřeba pro vysvětlení a shodu o tom, co se musí udělat a proč. Odvodit, jak dlouho to má trvat, kolik zdrojů to spotřebuje a jaké mají jednoduché měřitelné výsledky. Etapa měla trvat přibližně měsíc. Dopadlo to tak, že po šesti týdnech přípravy (fakticky začala příprava ještě o dva týdny dříve uprostřed předchozí etapy) ve třetím kole přepracovávání plánu prací zazněla památná věta: „Abychom věděli, jak to má dopadnout, museli bychom to nejdřív udělat.“. Fakticky to znamená, že zadavatel nemá dost síly ověřit si, zda navrhovaný postup a navrhované výsledky připravovaných prací jsou realistické a uspokojí jeho potřeby. V podstatě to znamená, že problematiku nezvládá dostatečně a proto také není možné si pod navrhovaným postupem a výstupy představit nic srozumitelného. Zcela jistě je tato situace také indikací, že faktické potřeby nejsou dostatečně dobře „známy“.
Od těch dob celý slavný „projekt“ komplexního rozvoje není řízen projektově (ačkoli se tomu tak říká), ale naprosto živelně, přesně dle zadání „něco udělat“ … a až to bude hotové, tak se zamyslíme nad tím, jestli je to k něčemu dobré. Což je pochopitelně přehnaně negativní vylíčení situace. Bohužel nutno říci, že většina podobných aktivit, zejména v oblasti vývoje software a jiných aktivit v oblasti ICT, probíhá velmi podobně. Typickým dokladem je to, když se akceptační kritéria etapy formulují v den akceptace (popř. se žádnou akceptací „nezdržujeme“). Z této zkušenosti vyplývají dvě hlavní otázky: zda se mělo a mohlo (popř. čí je to selhání) z hlediska korektnosti řízení projektu postupovat v dané situaci jinak, a pokud ano, tak jak?
Ocitáme se zdánlivě v bludném kruhu. V moudrých knihách kromě toho, že říkají „věnujte dostatečný čas přípravě“, najdeme i rozporuplné prohlášení, „nevěnujte plánování více času, než byste spotřebovali na odstraňování problémů vzniklých tím, že žádný plán mít nebudete“. To fakticky znamená, že neumíme žádným obecným způsobem určit, co je „dostatečná“ příprava. U akcí, které se zabývají něčím, co je opravdu mimořádné a jedinečné, téměř automaticky nevíme, co všechno potřebujeme, a nevíme ani to, jaké mají být výsledky. Je jenom otázka, jestli bychom se do takových akcí měli pouštět.
Operativní řízení projektu
Pokud se přesto pustíme do akce, která není připravena ani tak, že bychom věděli, jaké má mít jednoznačné výstupy nebo projektový manažer není ochoten zodpovědně garantovat to, že stanovené výstupy se podaří dosáhnout v termínu, musíme se smířit s tím, že takovou akci budeme muset řídit nikoli projektově, ale operativně. V takovém případě projektový manažer nenese žádnou zodpovědnost a stává se pouhým vykonavatelem příkazů. V našem projektu se asi nijak jinak postupovat nedalo a vše nasvědčuje tomu, že v důsledku těchto zkušeností byl iniciován (byť zatím víceméně živelný) proces kultivace a zdokonalování. Víceméně se daří uplatnit mechanismus, který se snaží vypořádat se se situací a převést živelné řízení projektu do přijatelné podoby.
Cílem takového operativního řízení mimořádných aktivit by se mělo stát vytvoření podmínek, a to zejména v oblasti znalostí, k tomu, aby mohla být tato mimořádná aktivita převedena do režimu projektového řízení. Byť by to bylo řízení „nejasného“ projektu, tedy po etapách. Jenom tak můžeme přenést zodpovědnost za průběh prací na někoho jiného než zadavatele. A zadavatel by se ze své podstaty neměl zabývat operativním řízení činností, protože existuje jen omezený počet zadavatelů a jejich kapacita není nevyčerpatelná. Rozhodně by to mělo být tak, že kapacity zadavatele jsou využitelné jiným způsobem s výrazně vyšším užitkem. Právě proto musí být ve větších firmách (organizacích) strukturovaný systém řízení, prostě není možné, aby všechno řídil jediný člověk.
Když to tedy shrneme, v uvedených příkladech byla jednoznačně příčina nekorektního postupu na straně zadavatele (velmi dobře je to vidět v případě, kdy zcela „chybí“ vedoucí projektu). Jednoduché doporučení – to, že k něčemu takovému dojde, je signál, že zadavatel je přetížený, není schopen ani identifikovat chyby, kterých se dopouští. Je tedy nezbytně nutné část jeho aktivit přesunout na jiného pověřeného pracovníka. Zadavatel by neměl spouštět projekty, u kterých mu chybí způsob posouzení jejich realističnosti. Buď dané problematice rozumím natolik, že jsem schopen vyhodnotit, zda to, co se má dít, je reálné, nebo připouštím nepřijatelně vysokou pravděpodobnost neodhadnutelných ztrát.
Pro řešení případného kritického stavu, kdy je zjevné, že se „něco“ udělat musí, a to hned, přitom není reálné získat bezprostředně dostatek informací a znalostí pro posouzení realističnosti, je možné použít externí audit projektu. Ale rozhodně je nezbytně nutné vytvořit základní systémové předpoklady – stanovit pravidla pro řízení projektů. Bez jasně formulovaných zásad, závazných postupů a formalizace informací nebude možné provést ani vlastní, ani externí kontrolu toho, zda je projekt připraven a zda je realistický.
Proces projektového řízení
Zní to poněkud rozporuplně. Když je něco projekt, tak to není proces. Ale pozor, nemluvíme o projektu (a fakticky ani o řízení jednotlivého projektu). Projektovým řízením je zde míněno především okolí projektů. Přesněji řečeno schopnost organizace řídit několik souběžných jedinečných aktivit. To velmi zjednodušeně znamená stanovení pravidel pro to, co musí být nezbytně nutně provedeno a dodrženo pro jejich spuštění, průběh a ukončení. Plně to odpovídá provedené analýze problémů při řízení projektů a jejich příčin, kdy se u kořene příčin všech problémů objevuje nedostatečná příprava, nevyhovující komunikace, neúčinná koordinace, špatné zadání a jako společný důvod byla identifikována nízká kvalifikace organizace pro projektové řízení.
Tím je myšleno to, že standardní činnosti, které v organizaci kolem řízení mimořádných aktivit probíhají, musí být závazným způsobem určeny a podporovány příslušnou informační infrastrukturou stejně jako všechny ostatní procesy. Dostatečně podrobná a srozumitelná analýza všeho toho, co by mělo být v procesu projektového řízení zajištěno, překračuje možnosti a záměr tohoto článku. Možná by stálo za to zdůraznit informační infrastrukturu, kterou je potřeba pro úspěšné řízení projektů využívat. Množství a nezbytně nutná kvalita informací, které potřebujeme, zcela vylučuje jakákoli provizoria a improvizaci.
Takže co doporučit – jednoznačně klíčovým prvkem je zvyšování „projektové“ kvalifikace firem. To znamená přizpůsobit celopodnikový systém řízení tomu, že bude existovat čím dál více komplexních jedinečných akcí, které musí být řízeny projektově. Tím se nemyslí (pouze) vysedávání na školeních, věnovaných jednoduchým a nepoužitelným teoretickým poučkám, ale aktivní hledání cesty, jak a které náměty a myšlenky tvůrčím způsobem využít v podnikové praxi. Bez vzdělávání vrcholových manažerů a vytváření nejlepších možných podmínek pro potenciální projektové manažery to samozřejmě nepůjde. Ale je to pouze první krok. To, co musíme udělat, je „naučit“ firmu žít společně s projekty. Nic jiného nám totiž nezbývá. Tlak prostředí po nás již dnes vyžaduje, abychom na změny situace reagovali systémově a komplexně. Prostřednictvím řízené změny. Změnu můžeme řídit pouze s využitím pravidel projektového řízení. Pokud si to dnes ještě nepřipouštíme, zítřek nás pravděpodobně přesvědčí o tom, že jsme udělali chybu.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.
![]() ![]() | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
IT Systems podporuje
Formulář pro přidání akce
Další vybrané akce
15.5. | Konference SCADA Security |
22.5. | Akce pro automobilové dodavatele "3DEXPERIENCE... |
12.6. | Konference ABIA CZ 2025: setkání zákazníků a partnerů... |
29.9. | The Massive IoT Conference |