facebook
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
AEC
IT SYSTEMS 3/2014 , Projektové řízení

Řízení (nejen) IT projektů (5. díl)

Jedinečný projekt si zaslouží jedinečný přístup



PM ConsultingStanovení požadovaných výsledků, kterému jsme se věnovali v minulém dílu seriálu, je teprve začátkem plánování projektu. Praxe přece jen ukazuje, že pouhé stanovení požadovaných cílů a následné očekávání, že nějak (samovolně) nastanou, obvykle k úspěchu nevede. V tomto článku se zaměříme na nástroje a kroky vedoucí k dostatečnému určení plánu průběhu projektu tak, aby podle nich šel projekt řídit během své realizace.


K čemu je vlastně pro projekt potřeba nějaký plán?

Mám v paměti případ jednoho podniku, kde řešili neustále se opakující situace. Manažer některého z projektů přilétl do jednoho z odborných oddělení s tím, že od zítřka potřebuje deset z jejich patnácti členů, že to tak musí být, a že když je mít nebude, bude velký průšvih. Liniový manažer už měl ten den za sebou dva obdobné rozhovory a rázně odpálkoval i tohoto projektového manažera. Takže se celá událost nakonec spolu s ostatními stejně řešila na velké poradě vedení, a kdo si dokázal uhádat více zdrojů, ten je dostal. Pikantní bylo, že dané přidělení bylo skutečně závislé především na bázi tvrzení „já ty zdroje potřebuji víc“ a hlasitosti projevu řečníka. Přesto tento chaos nějak fungoval. Cenou ale byla frustrace a přetíženost běžných pracovníků. Vedlo to také k poměrně silné fluktuaci zaměstnanců, což bylo vnímáno jako palčivý problém. Na druhou stranu se v rámci dané firmy management v podstatě shodoval, že se nemá cenu pokoušet něco plánovat, když to bude stejně jinak.

Pokusil jsem se tehdy vedení přiblížit jejich situaci na příkladu: „Jste v Peci pod Sněžkou. Vidíte tu špičatou horu, co vykukuje támhle za kopcem? Fajn. Váš cíl je dojít na vrchol a do večera se vrátit zpět. Rozumíte zadání? OK, co byste dělali v takové situaci?“ „No, asi bychom se šli podívat na mapu, kudy se tam jde, která cesta bude nejlepší,“ dostalo se mi odpovědi. „A já bych si s sebou sbalil něco k jídlu, pláštěnku a tak,“ doplňoval jiný manažer. „Aha, a proč se tedy na projektech chováte tak, že se otočíte na patě a prostě vyrazíte směrem hora,“ zeptal jsem se. Chvilku bylo ticho a poté jsme se konečně začali bavit o tom, jak se dají dělat smysluplné projektové plány a jaká může být jejich přidaná hodnota.

K čemu by tedy vlastně měl takový plán sloužit? Vždy, když někam směřujeme, je dobré mít plán cesty, který nám umožní zjistit, kde se zrovna nacházíme, zda a jak velký máme (nemáme) problém s časem, penězi a případně dalšími aspekty. To znamená, že projektový plán, respektive plány by pro nás měly být především jakýmsi ukazatelem, srovnávací základnou, vůči které budeme porovnávat svůj reálný postup, abychom podle zjištěných odchylek podnikli další aktivity. Pokud jsme navíc v prostředí s omezenými lidskými zdroji, o které se dělí více projektů, pak je rozumně podrobný způsob plánování jedním z mála způsobů, jak optimalizovat hospodaření s těmito zdroji. Projektové plány jsou ve své podstatě především nástroje komunikace mezi různými lidmi, jejímž předmětem a cílem je úspěšný průběh a výsledek projektu.

Plán řízení projektu není jen harmonogram

Dobrý plán řízení projektu obvykle obsahuje dvě základní skupiny informací. V první jsou obsaženy vlastní (směrné) plány, ve druhé pak pravidla, postupy a procedury vzniku a následné změnování těchto plánů. Například v oblasti rozsahu lze uvažovat o tzv. scope baseline, která může být složena z WBS, slovníku WBS a popisu rozsahu projektu (scope statement). Alespoň tak praví PMI PM BoK.

Dobrá, jak konkrétně to ale bude ve vašem aktuálním projektu? Nyní se potřebujete domluvit na tom, z čeho se bude vaše konkrétní scope baseline skládat, jak bude vytvořena, za jakých podmínek a kdo ji bude moci měnit atd. Takže se třeba domluvíte, že v oblasti rozsahu vám stačí WBS plus zjednodušený popis pracovních balíků, že změny v rámci pracovních balíků schvaluje projektový manažer, nad rámec pracovních balíků sponzor a máte daná pravidla. Pokud podle nich následně vyrobíte WBS a daným způsobem popíšete pracovní balíky, máte svou scope baseline, tedy směrný plán rozsahu projektu.

Dalšími směrnými plány jsou obvykle rozpočet (cost baseline) a harmonogram (schedule baseline). V kontextu našeho seriálu mohou tyto záležitosti vzniknout například díky informacím z popisů pracovních balíků, kam byly zaznamenávány činnosti, které je potřeba provést, včetně jejich nároků na zdroje a lidi.

Rozsah, čas a finance však nejsou vše, co je možné a případně potřebné v projektu naplánovat. Je vhodné zvážit, zda a v jaké podobě by bylo vhodné pro projekt definovat pravidla a vytvořit základní plán pro oblast:

  • řízení komunikace,
  • řízení lidských zdrojů (což zahrnuje i sestavení projektového týmu, organizační strukturu projektu atd.),
  • řízení kvality (které požadavky má projekt splnit a jak to bude zajištěno),
  • řízení rizik,
  • řízení zainteresovaných stran,
  • řízení nákupu zboží a služeb (procurement),
  • případně i řízení konfigurace, zákaznických požadavků, zlepšování procesů atd.

Je zřejmé, že pro málokterý projekt je smysluplné zpracovávat vše výše uvedené. Řiďme se zásadou, že veškeré nástroje pro nás musí mít přidanou hodnotu, která jednoznačně převýší úsilí a energii vynakládané na jejich zřízení a používání.

V rámci simulace projektu Pacifická dráha, kterou používáme jako jednu možnost tréninku základních principů PM, předkládáme trénovanému projektovému týmu obsáhlá zadání projektových rolí a jakoby stranou jim přikládáme i poměrně složité formuláře pro reporting. Dotyční se je ve své přirozenosti snaží ze všech sil správně vyplňovat a tráví tím spoustu času, který je nejen v naší hře klíčovou komoditou. Když pak máme brainstorming nad tím, jak zrychlit, ptáme se: „Co vám zabírá nejvíc času?“ Po nějaké chvilce se ozve: „No, ten reporting.“ „OK. Kdo ho potřebuje?“ Následuje obvykle chvilka ticha a trochu udivené pohledy. Na to se rozvine krátká interní debata s výsledkem, že vlastně nikdo. Následně necháváme takto nesmyslně nastavený reporting padnout pod stůl, necháme účastníky, aby si natahali reporting podle svých potřeb a skokem jsme dvakrát rychlejší.

Tímto způsobem učíme účastníky našich tréninků přemýšlet nejen nad tím, co dělají, ale také jak to dělají. Tento přístup je vhodné použít již ve fázi tvorby plánu řízení projektu – od začátku je dobré přemýšlet nad tím, co bude nejlepší v projektu nedělat vůbec, a co jen v nejnižší nutné míře tak, aby jej bylo možné efektivně uřídit.

Je kritická cesta passé?

Pokud uvažujeme o plánování projektu, nelze pominout plánování času a od toho odvozené plány, minimálně plán čerpání zdrojů lidských i finančních. Ty jsou s moderním projektovým řízením spjaty od začátku. Klasický projektový management dodnes preferuje plánování pomocí některé z metod odvozených od metody kritické cesty (CPM – critical path method). Základní principy jsou velmi jednoduché. Na začátku potřebujete seznam všech činností k provedení. Pokud máte popisy pracovních balíků, máte jej, a to včetně odhadů doby trvání, pracnosti a nákladů. Poté začnete činnosti řadit pomocí logických vazeb začátek–konec. Nejprve tedy budou činnosti, které nemají žádného potřebného předchůdce, mohou začít třeba hned. Poté ty, které mohou začít po nich. Tedy něco ve smyslu: vykopání jámy, založení domu, výstavba stěn, zastřešení. Následně provedete kontrolu, že máte jeden začátek a jeden konec. Pokud ne, doplníte milník, činnost s nulovou dobou trvání, který navážete na všechny volné začátky či konce. V takovéto síti pak již můžete hledat nejdelší cestu od daného jediného začátku do daného jediného konce. Tato nejdelší cesta je tzv. kritická. Projekt zřejmě nebude trvat kratší dobu, než je délka této cesty. Uvedená analýza poskytuje několik dalších benefitů. Víte, kam se máte zaměřit, pokud chcete projekt zkrátit. Víte, kde máte rezervy. Už se nebavíte se svým nadřízeným či zákazníkem o dojmech, ale o pojmech a faktech. Zcela zásadní je tento způsob plánování pro zdrojové harmonogramy.

PM Consulting


Obrázek demonstruje dva způsoby zápisu harmonogramu. Jeden jako PDM síťový graf, druhý jako Ganttův diagram, který je využívaný v drtivé většině současného softwaru na podporu plánování času v projektech. V hranatých závorkách za obdélníky reprezentujícími činnosti je údaj o počtu potřebných lidí na danou činnost (pokud má proběhnout v daném termínu). V levé části obrázku je demonstrována situace, která často vznikne na základě prvního „natahání“ vazeb. Zdroje jsou na některých místech přetíženy, jinde nevyužity. Pravá část demonstruje možnosti optimalizace pomocí využití rezerv v časovém plánu.

Je zřejmé, že tento postup může být již na bázi jednoho projektu velmi přínosný. Při aplikaci na část organizace, nebo dokonce celou organizaci se tento efekt násobí. Ovšem za jedné podmínky. Plány musí být aktualizovány podle skutečného vývoje a je třeba s nimi průběžně pracovat. Jinak celé úsilí postrádá smysl. Jeden velmi pravdivý bonmot v oblasti projektového managementu zní: plán je k ničemu, plánování je vše!

V poslední době se velmi diskutuje o různých alternativách, obzvláště na bázi agilního přístupu. Ty však vůbec nemusí být s uvedeným v rozporu. O tom ale zas někdy příště.

Příště

Projekt máme vymyšlen a naplánován, nezbývá tedy nic jiného než se do něj konečně pustit a vyrovnat se s nejistotou dnešního světa.

Jan Doležal
Autor je ředitelem společnosti PM Consulting. Je držitelem certifikací PMI PMP a IPMA level B. Zabývá se především optimalizací systémů řízení projektů v různých firmách a organizacích.
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.

Inzerce

CRM, DMS a docházkové systémy, ITIL 4 a firewally

Obsahu aktuálního vydání IT Systems dominují témata CRM a DMS, což jsou zkratky, se kterými se v oblasti podnikového IT setkáváme již mnoho let, ale přesto bychom jim stále měli věnovat pozornost. Rozhodně se totiž nejedná o vyřešenou a uzavřenou záležitost, protože nové technologie přináší také nové možnosti, a to jak do oblasti řízení vztahů se zákazníky, tak i do oblasti správy dokumentů, jejich digitalizace a řízení oběhu v rámci workflow, protože až s ním dostává DMS skutečný smysl.