SAU Working Papers ŠAVŠ Pracovní texty
Working Paper No. 5/2007 Metody a nástroje v projektovém řízení
Drahoslav Dvořák
ŠkodaAuto Vysoká škola ŠkodaAuto University
Working Paper 5/2007
Metody a nástroje v projektovém řízení
Drahoslav Dvořák1
1
Ing. Drahoslav Dvořák Ph.D., Microsoft ČR s. r. o., Vyskočilova 1461/2a, 140 00 Praha 4
[email protected]
Název:
Metody a nástroje v projektovém řízení
Autor:
Drahoslav Dvořák
Vydavatel:
Škoda auto a.s. Vysoká škola
Místo a rok vydání:
Mladá Boleslav, 2007
Evidenční číslo MK ČR
E 16189
Tištěná verze:
ISSN 1802-2715, ISBN 978-80-87042-16-8
On-line verze:
ISSN 1802-2723
© ŠkodaAuto Vysoká škola
Abstract There are lots of methodologies and software for project management available on the market. Both are getting more and more complex, offer more capabilities and covered last trends in project management. But to support project specific to your organization means especially to select right mixture of methodologies and tools supporting specific character of your projects. First objective of this text is to introduce a way how to thing about level of project management processes support. There are many angels of view on this, so things mentioned within first chapter could be perceived like starting points (see picture 1). Second objective could be formulated as relationship between methodologies and software tools. So to manage a project, a balanced mix of methodologies and software is always required (see picture 2).
Keywords Project, Project management, tools, methodologies, logical frame, mind map, feasibility study, critical path, baseline, earned value, Microsoft Project, Project Server, Sharepoint.
JEL classification
Obsah 1.
Nástroje a metody v projektovém řízení.....................................................................................7
2.
Iniciace projektu........................................................................................................................11
3.
4.
5.
2.1
Logický rámec.........................................................................................................................11
2.2
Myšlenkové mapy ..................................................................................................................13
2.3
Studie proveditelnosti a realizovatelnosti a definice rozsahu ...............................................14
Plánování projektu ....................................................................................................................17 3.1
Metody odhadování dob trvání jednotlivých úkolů...............................................................17
3.2
Vzájemné závislosti a časová omezení...................................................................................21
3.3
Hodnocení rizikovosti projektu..............................................................................................24
Sledování a řízení projektů........................................................................................................27 4.1
Sledování průběhu projektu ..................................................................................................27
4.2
Kritická cesta ..........................................................................................................................30
4.3
Řešení studentského syndromu a Parkinsonova zákona.......................................................34
Podpůrné nástroje.....................................................................................................................37 5.1
Microsoft Office Project 2007................................................................................................37
5.2
Řešení Microsoft Enterprise Project Management ...............................................................37
5.3
Microsoft Office Sharepoint Server 2007 ..............................................................................40
6.
Závěr..........................................................................................................................................44
7.
Přehled použité odborné literatury ..........................................................................................45
1. Nástroje a metody v projektovém řízení Chystáte-li se řešit projekt, budete dříve, nebo později potřebovat opřít se o nástroje a know how, které Vám usnadní jeho přípravu, plánování, sledování a řízení. Projekty totiž dávno nejsou akce o několika úkolech, které vyžadují kooperaci několika málo lidí, a jejichž případný neúspěch nezasáhne výrazně do finančního hospodaření firmy. Je to právě naopak – projekty jsou rozsáhlé a komplexní, vyžadují náročnou organizační práci a stojí hodně peněz. Zároveň hodně peněz přinášejí, umožňují lidem kariérní postup a podpoří přežití firmy v současných turbulentních podmínkách. Aby se projekt realizoval rychleji, aby se vyvaroval problémů s kvalitou, zpožděním atd., je nanejvýš rozumné opřít se o moderní přístupy a nástroje. V tom okamžiku je však potřeba řešit i druhou věc: do jaké míry nástroje a potažmo i metodiky pro řízení projektu používat tak, aby realizace projektu byla nanejvýše efektivní. Protože moderní nástroje a špičkoví konzultanti jsou k mání za nemalé peníze… K rozpoznání správné míry použití nástrojů a metodik při řízení projektů může posloužit následující barometr definující rozsah projektového řízení v organizaci. Na obr. 1 je představeno celkem 8 rovin, přičemž ani tento počet nemusí být konečný. Do přehledu byly zohledněny tyto základní proměnné: -
Rozsah projektu, resp. počet zainteresovaných stran a míra zapojení externích subjektů.
-
Typy projektů zahrnující interní aktivity, nebo projekty realizované pro vnějšího zákazníka.
-
Množství projektů za časové období – prostý počet projektů za rok.
-
Doba trvání typického projektu – průměrná doba trvání projektových aktivit.
-
Náklady na projektové aktivity vůči aktivitám ostatním.
-
Režim zdrojů, přesněji režim práce na projektech.
-
Způsob iniciace projektu – jak a kým je projekt zakládán.
-
Přístup k řízení projektu a jeho garanti.
Zdroj: Vlastní zpracování
Obr. 1 Barometr míry nasazení projektového řízení
V závislosti na velikosti plochy, která se získá spojením hodnot specifických pro konkrétní situaci, a počtu zásahů v červené, oranžové a zelené zóně pak lze usuzovat na kroky potřebné k zavedení systému Projektového řízení. Červená = nerozjíždět Pro červené pásmo zavádění komplexního systému řízení projektů není vhodné. Situaci v oblasti projektů lze za naznačených podmínek shrnout asi následovně. Ve společnosti probíhá zhruba pět projektů ročně s rozsahem nepřesahujícím několik dnů, nebo jeden až dva delší projekty. Výstupy těchto projektů slouží výhradně interním potřebám organizace jako zadavatele a práci zajišťují v drtivé převaze vlastní zaměstnanci. Projekty jsou v podniku chápány jako aktivity „navíc“. Budování komplexní metodiky pro řízení projektů by v tomto případě znamenalo brát kanón na pomyslného vrabce.
Oranžová = připravit, pozor!
Oranžová zóna a její charakteristické proměnné budou vyžadovat nepoměrně více pozornosti, než předchozí situace. Projekty zde uvedené mění svou tvář z aktivit konaných zpravidla nad rámec běžných povinností do činností, které vývoj, výrobu, obchod a další strategické procesy, přímo ovlivňují. Závažnost těchto projektů, v porovnání s prvním případem, je tedy značně odlišná. Na diametrální rozdíl priority projektů ukazují zejména jejich obsah (roste poměr externích zakázek), stoupající počet a ve prospěch externích zdrojů měnící se struktura členů projektových týmů. Zelená = plnou parou vpřed Zelené pásmo představuje stav, kdy jsou v podstatě veškeré procesy označované v minulých odstavcích za „ostatní aktivity“ realizovány formou projektů. Projektové řízení v podstatě plní roli řízení podniku obecně. Podle toho musí vypadat i podpora tohoto systému, kde implementace uceleného know–how pro projektové řízení bývá nezbytná. Podle
těchto
rovin
budou
dále
vysvětleny
metodiky
iniciace,
plánování
řízení
a podpory projektů. Metodické nástroje jsou na následujícím schématu rozděleny do rovin: Červená - Základní: Metodiky a nástroje, které jsou použitelné prakticky pro všechny projekty. Oranžová - Pokročilé: Metodiky a nástroje, které bývají použity v organizacích s vyšší projektovou intenzitou. Zelená - Profesionální: Metodiky a nástroje používané v organizacích řízených podle projektů.
Zdroj: Vlastní zpracování
Obr. 2 Matice rozdělení projektových metodik a nástrojů
2. Iniciace projektu Smyslem iniciační fáze projektu je oddělit pověstné zrno od plev a prověřit, že realizace projektu má smysl. Základní metodikou pro iniciační fázi projektu představuje logický rámec. Na něj mohou být postupně navázány další nástroje, které rozvíjejí některé jeho části (myšlenkové mapy) případně podrobují projekt hlubší analýze (definice rozsahu).
2.1
Logický rámec
Logický rámec tedy představuje základní rozvahu projektu. Jedná se o velmi elegantní metodu, jejímž smyslem je pouhé srovnání si základních údajů o projektu na jedno místo. Je až s podivem, kolika projektům podobná bilance schází. „Jednou z metod, jak přehledně „zmapovat“ naše záměry a očekávání a uvést je do souvislosti s konkrétními výstupy a činnostmi při realizaci projektu je metoda logického rámce. Je to postup, jehož pomocí jsme schopni stručně, přehledně a srozumitelně popsat projekt na jednom listu formátu A4.“ Roman Chudoba, Formulace projektu metodou logického rámce, www.teamtechnologies.cz
Logický rámec se skládá ze čtyř základních dimenzí: 1. Popis projektu - na této úrovni dochází ke specifikaci závislých proměnných: vize – účel – produkt - úkoly. První čtvrtina bilance logického rámce slouží jako základ pro následnou tvorbu harmonogramu. Hlavní přínos lze spatřovat především v šíři definice, kdy je třeba vymezit nejen CO, ale i PROČ projekt realizovat. Zde by se měla naplno využít vyjednávací schopnost obstaratele (tedy subjektu, který bude projekt realizovat pro zadavatele), který by měl zadavatele přimět k zamyšlení se nad důvody (přínosy) projektu. Proč ale klást takový důraz na přínosy? Stačí si vzpomenout, kolikrát je nutno před zadavatelem obhájit věci typu navýšení nákladů projektu. Pokud bude zadavateli například známo, o kolik % vzroste vlivem realizace projektu jeho vlastní zisk, pak se obhajoba drobného navýšení projektových nákladů stává mnohem jednodušší.
2. Měřitelná kritéria - sloupec věnovaný metrikám je stěžejní především pro management jakosti výstupů projektu a následně i pro obsah smluvních závazků. Pro manažera týmu skýtá přehled kritérií šanci, jak si usnadnit směřování týmu k výsledku. Čím více totiž bude produkt popsán, tím méně se manažer bude setkávat s předpoklady, domněnkami a dalšími nejistotami. 3. Zdroje dat – ruku v ruce s životním cyklem projektu (založení – plánování – sledování – řízení – uzavření) vzniká projektová dokumentace. Skládá se z dat vztažených k produktu projektu a k projektovým procesům. Aby účastníci projektu nemuseli porozumět různým formám dokumentů, vyplatí se popsat jejich strukturu již na samém začátku projektu jejich strukturu (př. akceptační protokol – zápis z jednání – faktura). 4. Předpoklady/Rizika - pokud se manažer nechce pouštět do Sisyfovské práce v podobě potlačení Murphyho zákonů, pak to znamená, že připouští existenci rizik. V tomto okamžiku by se měl začít ptát, jak s rizikem ve svých projektech pracovat, případně kdy se riziky začít zabývat. Odpověď zřejmě nebude v této souvislosti nikterak překvapivá. K aktivaci procesu identifikace a kvantifikace rizik by mělo dojít právě v logickém rámci. Logický rámec rozhodně není pouze formální záležitostí. Užitek z něj je možné realizovat i v případech, se rozhodne obstaratel použít rámec pouze interně, bez spolupráce se zadavatelem projektu. Získá tak náměty na otázky, které může následně při jednáních o projektu položit. Ideální případ pochopitelně počítá s tím, že logický rámec je skládán ve spolupráci se zadavatelem, a tímto je též verifikován jeho obsah. Podaří-li se naplnit tento ideál, pak se projekt velmi pravděpodobně odrazí k výborným výsledkům. Logický rámec představuje též odrazový můstek pro řízení projektu. Jeho jednotlivé sloupce představují báze důležitých pilířů projektu: 1. sloupec - popis projektu je vstupem pro plán, konkrétně seznam úkolů 2. sloupec – kritéria promlouvá do definice časů, peněz a řízení kvality 3. sloupec – seznam dokumentace pokládá základ dokumentačnímu managementu 4. sloupec – rizika a předpoklady definuje vstupy do řízení rizik.
Tab. 1 Příklad zpracovaného logického rámce projektu
Popis projektu
Metrika
Zdroj dat
Riziko
Zvýšit spokojenost zákazníků
Spokojenost > 85%
Průzkum, listopad 2006
Nekvalitní dodavatelé
Prodej domu na klíč
Marže z prodeje 15%
Účetní systém
Konkurence
Dodávka domu typ A
Akceptace díla nejpozději 1. 10. 06
Projektová dokumentace
Počasí
Základy
Vomáčka
Hrubá stavba
Novák
Střecha
Dvořák
2 000 000 Kč
Zdroj: Vlastní zpracování
Zbývá dodat, že k vytvoření bilance lze použít jakýkoliv tabulkový procesor například Microsoft Office Excel 2007. Bilanci lze rovněž dále upravit, není tedy nutné se držet se uspořádání 4x4. Výsledkem takových úprav mohou být matice 3x3, případně 3x5 apod.
2.2
Myšlenkové mapy
Někdy je však třeba specifikaci projektu realizovanou logickým rámcem rozšířit. Nejčastější metodou bývají myšlenkové mapy. Tyto mapy jsou v podstatě logickou strukturou budoucího plánu projektu. Navazuje tedy na čtvrté pole v prvním sloupci logického rámce. Myšlenkové mapy mají velmi blízko k brainstormingu. Vztah těchto dvou pojmů lze definovat jako formální a obsahovou stránku používanou jako východisko především pro řešení neznámých, či nejistých problémů. Cílem sestavení myšlenkové mapy je podpořit a rozvinout kreativní a myšlení při řešení úkolů a tím eliminovat riziko neúspěchu. „Sestavení vlastní mapy je v zásadě prosté – stačí naslouchat a získané podněty dávat do vzájemných souvislostí. Hledáním a definováním logických závislostí a vazeb pak dochází ke zrodu myšlenkových map.“ Drahoslav Dvořák, článek Myšlenkové mapy v MS Project, www.projektoverizeni.spaces.live.com
Čím je řešená úloha komplexnější a složitější, tím více vyvstává potřeba podpory pro formální konstrukci jejího řešení. Na trhu již v současnosti existuje bezpočet sofistikovaných aplikací.
Myšlenkové mapy mohou být zkonstruovány např. v aplikaci Mind Manager, nebo Microsoft Office Visio 2007 a v mnoha dalších…
Zdroj: Karel Hyndrák, Microsoft Office Project – Hotová řešení, str. 29 Obr. 3 Myšlenková mapa jako síťový graf v aplikaci Mind Manager 7
2.3
Studie proveditelnosti a realizovatelnosti a definice rozsahu
Nejrozsáhlejší projekty, případně projekty realizované pro externího zákazníka, bývají, co do podrobnosti testování smyslu a definování obsahu, nejdokonalejší. Právě u nich totiž hrozí riziko dodatečných změn nejvíce. Složité produkty mívají velké množství parametrů, které je třeba důkladně popsat. Vedle logického rámce a myšlenkových map, které slouží jako pomocné materiály, vznikají dokumenty typu Definice rozsahu. Zejména u projektů, kde je zapojen i stát, či Evropská unie pak definici rozsahu předchází studie proveditelnosti a realizovatelnosti. Na první pohled podobné termíny mají různý obsah. Zatímco za testováním proveditelnosti stojí snaha ověřit, zda dostupné technologie a úroveň poznání mohou vést k získání produktu projektu, realizovatelností se chápe reálnost požadavků zadavatele co do času a nákladů. „Definice rozsahu musí být tak jednoznačná, stručná a zároveň komplexní, jak je možné.“ William R. Duncan, A guide to Project management body of knowledge, str. 127
Pro projekty menšího rozsahu vznikají v praxi zjednodušené – hybridní - šablony. Příkladem takového dokumentu může být následující dokument.
ANALÝZA REALIZOVATELNOSTI - PROVEDITELNOSTI Identifikace projektu: Název Projektu:
...................................................................................................
Autor dokumentu:
...................................................................................................
Datum a místo vystavení:
...................................................................................................
Identifikace zúčastněných stran: Vedoucí projektu:
......................................
Kontakt: ......................................
Zástupce zadavatele:
......................................
Kontakt: ......................................
Řídící výbor projektu (nejvyšší rozhodovací orgán projektu – 3 – 5 členů): Jméno:
......................................
Kontakt: ......................................
Další významné zainteresované strany: Existence výstupů
Vliv na: Jméno:
Kritéria výstupů
Realizace Jiné rizik
...........................
Realizovatelnost - přínosy, jichž má být dosaženo + jak jich bude dosaženo: Vize projektu:
Měřitelná kritéria dosažení vize:
Strategické cíle projektu naplňující vizi:
Měřitelná kritéria dosažení cílů:
Výstupy nutné pro dosažení strategických cílů:
Měřitelná kritéria dosažení výstupů:
Proveditelnost projektu z pohledu zákazníka: Ekonomická životaschopnost:
Financování projektu:
Sponzor: Předpokládaná návratnost: Očekávané náklady na projekt: Rizika:
Bude připravena odezva + odpovědná osoba?
Hlavní kontrolní body - milníky: Datum:
Událost:
Za splnění odpovídá:
KONEČNÝ TERMÍN SPLNĚNÍ PROJEKTU
Dokumentační management projektu: Vypracování Harmonogramu:
ANO
Stav plnění kritérií projektu:
Periodicky Týdně
Akceptační protokol:
Dle milníků Měsíčně
ANO Na konci
Dokumentace řešení:
NE
NE Po dosažení milníků
Metodika zákazníka
Metodika obstaratele
Předpokládaná časová dotace ...... hodin práce Dne........................
............................................
............................................
Podpis zástupce zadavatele
Podpis zástupce realizátora
Zdroj: Vlastní zpracování
Obr. 4 Vzorový formulář definice rozsahu, hodnocení proveditelnosti a realizovatelnosti projektu
3. Plánování projektu Projekt bývá definován, plánován, sledován a řízen ve 3 základních rovinách: kvalita, čas a náklady. Kvalitu projektu naplňují činnosti, jejichž soupis lze získat rozvinutím činností logického rámce, myšlenkové mapy, případně studie proveditelnosti. I plán nákladů lze relativně snadno sestavit na základě znalosti nákladových sazeb zdrojů, které pro realizaci projektu použijete, potažmo fixních nákladů k úkolům které lze chápat např. jako náklady smluvní. Hlavní problémy při plánování projektu jsou tedy spojeny s poslední z podmínek – tedy s časem. Hlavní metody jsou shrnuty dále.
3.1
Metody odhadování dob trvání jednotlivých úkolů
V časovém plánování projektu je kvalita, tedy přesnost plánu podmíněna zejména přesností odhadů dob trvání jednotlivých úkolů. „Je zřejmé, že časový plán pro jakýkoli projekt vyžaduje znalost (nebo odhad) doby trvání úkolů. Protože už podle definice se projekt nikdy dříve neprováděl, jsou také odhady času nutně nepřesné.“ Milton D. Rosenau, Řízení projektů, str. 105
Nastavování vazeb (závislostí) mezi úkoly – jakožto druhé komponentě harmonogramu - se můžeme přidržet logiky věci, resp. technologického postupu produktu projektu. Přístupy k odhadování času lze rozlišit do dvou skupin: -
Deterministické metody odhadu.
-
Stochastické metody odhadu.
A: Deterministické přístupy odhadování času Deterministické
přístupy
jsou
založené
na
minulé
zkušenosti
vedoucího
projektu
a členů týmu. Plně respektují Zlaté pravidlo plánování. To eliminuje potenciální nepřesnost odhadu zapojením lidí, kteří budou úkol plnit, a kteří by měli mít dostatek zkušenosti s plněním stejného, nebo podobného úkolu z minulosti. Jako zdroj pro následující odstavce posloužil článek Hledá se doba
trvání
úkolu,
zn.
Jen
reálně
www.projektoverizeni.spaces.live.com).
(autor:
Drahoslav
Dvořák,
publikováno
na
Analogie s minulostí. Nejjednodušším krokem pro eliminaci rezerv vkládaných do odhadu je se opřít o zdroje typu dokumentace obdobných projektů realizovaných v minulosti interně, nebo v jiných firmách, odvětvích apod. Zavedení doby vyrovnání do projektu. Podstata tohoto přístupu, s nímž se lze setkat spíše v praxi, než v teorii projektového řízení je vcelku triviální: základ pro plánovanou dobu trvání úkolu představuje optimistický odhad, ke kterému manažer projektu přidává rezervy o stejném rozsahu. Tzn. každý odhad se „jistí“ fixním objemem rezervy např. 20%. Přidání vyrovnávacího úkolu. Přidání „prázdného“ úkolu sloužící jako „nárazník“ na konec každé fáze, případně na samotný konec projektu, má obdobnou funkci jako doba vyrovnání. Vyrovnávací úkol je v podstatě rezerva pro sekvenci vzájemně závislých úkolů v síťovém grafu. Podle čerpání vyrovnávacích úkolů je možno projekt koordinovat tak, aby nedošlo k přečerpání a tedy ke zpoždění.
Zdroj: Vlastní zpracování
Obr. 5 Srovnání deterministických metod odhadování času B: Stochastické metody odhadování času
Ačkoliv stochastické metody rovněž využívají odhadů poskytnutými členy týmů, pro eliminaci rezerv používají statistické postupy. S odhadem pracují jako s náhodnou veličinou a pro konstrukci odhadu využívají její rozdělení. Na základě zkoumání dob trvání úkolů lze rozdělení charakterizovat jako jednovrcholové, přibližně normální rozdělení. Popis rozdělení lze provést asi následovně:
Zdroj: Internetové stránky www.ICCC.cz
Obr. 6 Odhady pro stochastické modely Minimální doba trvání – jedná se o nezbytnou dobu potřebná pro splnění úkolu s vyloučením negativních dopadů náhodných událostí. Nejpravděpodobnější doba trvání – je reprezentována vrcholem křivky. Jedná se o nejběžněji (nejčastěji) dosahovaný čas potřebný k realizaci úkolu. Bezpečný odhad – za jak dlouho odpovědný pracovník garantuje splnění úkolu – někdy též nazývaný pesimistický odhad, který již obsahuje, že se pokazí více věcí. Bezpečný odhad odpovídá odhadu pořízenému na základě zlatého pravidla plánování, tedy ryzímu deterministickému odhadu. Konečný odhad - nepříznivých okolností se může teoreticky nakupit nekonečně mnoho, ovšem, že se tak stane, má malou pravděpodobnost. Z tohoto důvodu tedy nelze jednoznačně vymezit maximální doba trvání úkolu.
Nejsnáze se ze stochastických metod aplikuje metoda PERT (Program Evaluation and Review Technique.) Principem této metody je evidence ne jednoho, ale celkem třech odhadů pro každý úkol: nejkratší možné doby trvání úkolu (tzv. optimistický odhad), nejdelší přípustné doby trvání úkolu (tzv. pesimistický odhad) a konečně "zlaté střední cesty" (obvyklá doba trvání) ležící někde uprostřed mezi prvními dvěma odhady. „Metoda PERT se liší od metody CPM (deterministických odhadů – pozn. autora) primárně že jako odhad používá střední hodnotu namísto předpokládaného odhadu.PERT se užívá zřídka samostatně, nicméně hodnoty PERT jsou často využity v kalkulacích CPM. William R. Duncan, A Guide to the Project management body of knowledge, str. 67
Z pohledu daného zdroje, člena týmu, který odhady poskytuje, se v podstatě jedná o minimální, nejpravděpodobnější a bezpečný odhad.
Analýzu PERT lze dále rozšířit a modifikovat. Je možné jí použít i v případech, kdy je k dispozici více odhadů např. 3x odhad člena týmu + 1x průmyslový standard + 1x osobním zkušenosti manažera. Modifikovat lze pochopitelně i váhy. Aby byla vaše práce jednodušší je metoda PERT integrována do softwarových nástrojů jako Microsoft Office Project 2007, jak je naznačeno na následujícím obrázku.
Zdroj: Vlastní zpracován
Obr. 7 Metoda PERT integrovaná do Microsoft office Project 2007
3.2
Vzájemné závislosti a časová omezení
Poté co se vyjasní, který z uvedených způsobů odhadu trvání úkolů bude pro projekt tím pravým, přichází na řadu propojení úkolů do síťového diagramu, tedy vytvoření vzájemných závislostí. Prostřednictvím závislostí se určí pořadí jednotlivých úkolů, tak jak budou realizovány v projektu. V aplikaci Microsoft Office Project 2007 existují čtyři základní typy závislostí mezi dvěma a více úkoly: •
Dokončení - Zahájení pro případy, kdy k zahájení následujícího úkolu může dojít teprve tehdy, skončí-li práce na předchůdci. V praxi se jedná o zdaleka nejpoužívanější typ závislosti.
•
Zahájení – Zahájení je typ vazby naznačující zahájení více úkolů v jeden okamžik.
•
Dokončení – Dokončení představuje opačný typ vazby k předchozímu typu.
•
Zahájení – Dokončení je atypickou závislostí opačnou k prvně jmenovanému typu. Dokončení předchůdce je zde iniciováno zahájením následníka (oproti typu Dokončení - Zahájení, kdy zahájení následníka je závislé na dokončení předchůdce). Přehled vazeb zpracován dle Jan Kališ, Karel Hyndrák, Vlastimil Tesař, Microsoft Project Kompletní průvodce pro verze 2003 a 2002, str. 91
Nadto může manažer projektu každou z vazeb modifikovat prostřednictvím nastavení prodlevy – tedy pevné doby mezi dokončením předchůdce a zahájením následníka, případně předstihu – tedy doby, po kterou mohou úkoly běžet paralelně.
Zdroj: Vlastní zpracování dle Jan Kališ, Karel Hyndrák, Vlastimil Tesař, Microsoft Project Kompletní průvodce pro verze 2003 a 2002, str. 91
Obr. 8 Možnosti nastavení vzájemných závislostí v aplikaci Microsoft Office Project 2007
Pokud manažer zamýšlí propojit dvě fáze projektu, je rozhodně lepší spojovat souhrnné úkoly, které je reprezentují, než spojovat poslední dílčí úkol první fáze s prvním úkolem následné fáze. Nikde totiž není zaručeno, že poslední úkol zůstane navždy posledním a první prvním. Ačkoliv se to nemusí zdát podstatné, správné propojení úkolů vám může ušetřit v projektu nemálo času. Správné propojení znamená nastavení takových typů vazeb a prodlev, či předstihů, které odpovídají logice věci. Před nastavením každé závislosti se neustále ptát: „Je to skutečně ten nejlepší způsob, opravdu nelze úkoly realizovat současně, nebo alespoň částečně v souběhu?“ Tento kritický pohled se v praxi určitě vyplatí. V případě, že se v projektu vyskytne potřeba fixovat určité konkrétní termíny, je třeba postupovat velice obezřetně. Microsoft Office Project 2007 umožňuje nastavit celkem 6 typů časových omezení, které lze rozdělit do 2 kategorií: •
Tvrdá omezení, jejichž prostřednictvím se fixuje přímo termín zahájení, či dokončení práce na úkolu. K dispozici jsou dvě: o Musí začít – přesné datum, kdy musí nutně dojít k zahájení prací. o Musí skončit – přesné datum, kdy musí dojít k ukončení prací.
•
Měkká omezení, která definují nejdříve možné a nejpozději přípustné konce práce na úkolu. Manažer může využít hned čtyři možnosti: o Nezačne dříve, než – úkol nezačne před určitým datem, ale může být zahájen později. o Neskončí dříve, než – úkol neskončí před určitým datem, ale může skončit později. o Nezačne později, než – úkol nesmí být zahájen později, ale může být zahájen dříve. o
Neskončí později, než – úkol nesmí skončit později, ale může skončit dříve. Rozdělení upraveno podle Jan Kališ, Karel Hyndrák, Vlastimil Tesař, Microsoft Project Kompletní průvodce pro verze 2003 a 2002, str. 91
Konečně poslední z možností časového plánování projektu představuje nastavení tzv. konečného termínu. Jeho vytvoření nemá, na rozdíl od časových omezení, přímý vliv na zahájení/dokončení
úkolu, spíš se jedná o jakéhosi hlídacího psa, který upozorní v okamžiku překročení zadaného termínu. Doporučení pro praxi lze formulovat následovně: Časová omezení by měl manažer používat obezřetně, ideálně pouze u úkolů, na které nemá žádný vliv (např. podání daňového přiznání). Naopak konečné termíny je dobré doplňovat na konec každé fáze projektu. Pomohou mu totiž s předstihem indikovat problémy a naznačí, co je třeba udělat pro vrácení projektu do původních kolejí.
Příklad: Srovnání časových omezení a konečného termínu Pro názornou ilustraci fungování časových omezení a konečných termínů poslouží jednoduchý příklad, kdy manažer projektu má za úkol uřídit dva úkoly. Ty jsou naznačeny na obr. 46. V prvním případě bylo nastaveno tvrdé omezení na úkol Nastěhovat na 13. 3. 2007. Ve druhém případě bylo nastaveno měkké omezení na stejné datum. Konečně ve 3. případě byl nastaven konečný termín na 14. 3. 2007.
Zdroj: Vlastní zpracování
Obr. 9 Výchozí situace: Nastavení tvrdého, měkkého časového omezení a konečného termínu Většině projektů se však nevyhnou změny a nejinak tomu bude i v tomto případě. Vlivem nepříznivých povětrnostních podmínek je manažer nucen odsunout celý projekt o několik dní a zahájit úkol Vymalovat až 12. 3. 2007. Dopady na jednotlivé situace jsou patrné z obr. 10. Jak vidno, největší dopad má posun na tvrdé časové omezení, na měkké omezení situace dopad neměla, konečný termín signalizuje překročení nastavené hodnoty indikátorem v levém sloupci.
Zdroj: Vlastní zpracování
Obr. 10 Dopady posunu projektu na časová omezení a konečný termín
3.3
Hodnocení rizikovosti projektu
Jako nejsofistikovanější metoda, která je zároveň jednoduše použitelná v praxi, je manažerovi k dispozici ukazatel pravděpodobnosti zkrácení projektu. Pomocí rozptylu odhadů dob trvání úkolů lze tak určit pravděpodobnost zpoždění, případně – obráceným postupem – dojít i k pravděpodobnosti dokončení projektu dříve a tím určit rizikovost projektu z pohledu dimenze času. Realizovaný výpočet může být poté směrodatný například pro vkládání rezerv v podobě vyrovnávacích úkolů, případně pro stanovení pevné míry rezerv přikládaných ke každému z úkolů. K výpočtu pravděpodobnosti zkrácení projektu na určitou dobu trvání jsou potřeba optimistické, obvyklé a pesimistické odhady, které jsou i vstupem pro metodu PERT. Poté je třeba pro každý úkol spočítat rozptyl
podle vzorce: 2
Pravděpodobnost, že trvání projektu T bude kratší, než plánovaná délka trvání Tp, lze potom vyjádřit pomocí distribuční funkce náhodné veličiny doby trvání projektu s normálním rozdělením:
Kde pravděpodobnost, že projekt bude trvat dobu T, která je menší, než Tp T
požadovaná doba trvání projektu
Tp
plánovaná doba trvání projektu střední doba trvání projektu
Výpočty uvedené v tomto oddíle citovány dle knihy Petr Fiala, Projektové řízení – modely, metody, analýzy. str. 97 – 99.
Příklad: Pravděpodobnost zpoždění projektu Jako důkaz tvrzení, že projektem může být cokoliv, je uveden projekt nekomerčního charakteru – cesty do Liberce na dovolenou. Po definování úkolů byly pořízeny odhady, které jsou shrnuty v následující tabulce. Z technologického pohledu se jedná o jednoduchý export dat přímo z aplikace Microsoft Office Project 2007:
Tab. 2 Rozptyl odhadů dob trvání v projektu Dovolená v Liberci ID
Název
Doba Trvání
Optimistická
Očekávaná
Pesimi- Opt stická (h)
Oček Pes Rozptyl (h) (h)
1
Start Projektu
0 days
0 days
0 days
0 days
0
0
0
0
3
Vybrat peníze
0,4 days
2 hrs
3 hrs
5 hrs
2
3
5
0,25
4
Koupit lyže
3 days
1 day
3 days
1 wk
8
24
40
28,444444
5
Zabalit věci
4 days
2 days
4 days
6 days
16
32
48
28,444444
6
Zjistit spojení
0,26 days
30 mins
2 hrs
4 hrs
0,5
2
4
0,3402778
7
Zajistit hotel
1,1 days
5 hrs
8 hrs
2 days
5
8
16
3,3611111
9
Cesta MHD
0,32 days
30 mins
45 mins
1,5 days
0,5
45
12
3,6736111
10 Cesta Autobus
0,15 days
55 mins
70 mins
95 mins 0,917 1,17 1,58 0,0123457
11 Sraz s kamarády
0 days
0 days
0 days
0 days
0
0
0
0
12 Dovolená
2 wks
2 wks
2 wks
2 wks
80
80
80
0
13 Návrat
0 days
0 days
0 days
0 days
0
0
0
0
Zdroj: vlastní zpracování Hodnoty jednotlivých ukazatelů vypočtené pro typový projekt shrnuje následující přehled:
σ(T) =
= 8,0328223
Pravděpodobnost, že projekt bude trvat 140 hodin (Tp = 140) lze určit jako:
0,04182 Existuje tedy pouze 4,2% pravděpodobnost, že se projekt podaří zkrátit na uvedenou hodnotu. Vzhledem k takto nízké hodnotě lze dojít k závěru, že se jedná o relativně rizikový projekt. Z hodnot distribuční funkce lze určit i výslednou dobu trvání projektu při určité pravděpodobnosti. Např. doba trvání projektu s 80% pravděpodobností se určí jako:
0,7955 =
a odsud Tp = 147,1124 hod.
4. Sledování a řízení projektů Fáze časového plánování se dostává do svého konce, štafetu přebírají etapy sledování a řízení projektu. Na pomyslné předávce stojí směrný plán jako srovnávací základna pro projekt, respektive analýza přidané hodnoty. Jako naprosto klíčová metodika pro řízení projektu bude prezentována Kritická cesta. V této části bude provedeno shrnutí dosud vyřčeného a poté naznačeno manažerské využití. Konečně na pomyslném vrcholu stojí strategie pro řízení Studentského syndromu a Parkinsonova zákona. „Sledování plánu je spojeno s: a) Ovlivňováním faktorů způsobujících změny v plánu b) Zjišťováním, zda se plán změnil, či nikoliv c) Řízením eliminace vzniklých odchylek.“ William R. Duncan, A Guide to the Project management body of knowledge, str. 71
4.1
Sledování průběhu projektu
Práce manažera projektu v této fázi projektu spočívá především v neustálém sledování a vyhodnocování odchylek skutečných a plánovaných hodnot. Projekty jsou už ze své podstaty zatíženy vyšším rizikem a tudíž i nepoměrně větším výskytem odchylek od plánu. Namísto časově náročné eliminace všech odchylek je spíše třeba vzniklé odchylky měřit a analyzovat jejich dopad na projekt jako celek a teprve potom reagovat. Jinými slovy: cílem je uřídit projekt jako celek, nikoliv každý jednotlivý úkol. Jako zdatný pomocník se v tomto smyslu etablovala analýza přidané hodnoty. Ta integruje míry rozsahu, nákladů a času do jediné bilance, z níž lze získat ucelený přehled o plnění času a nákladů. Jejím základním stavebním kamenem se stává směrný plán, tedy záloha původně plánovaného průběhu projektu. Hodnoty zálohy plánovaných dat se střetávají jednak se změnami plánu (např. přidáním nového úkolu, nebo prodloužením některého z již definovaných úkolů a jednak se skutečně odvedenou prací (viz. úkol Základy – původní plán = šedá část pruhu, současný plán = celý červený pruh, skutečná práce = sytě červený pruh).
P Zdroj: Vlastní zpracování
Obr. 11 Srovnání hodnot směrného plánu s aktuální verzí plánu a skutečnou prací Ale zpět k analýze přidané hodnoty. Ta funguje jako univerzální srovnávací základna pro různé projekty. Aby bylo vůbec možné postavit vedle sebe více (různé dlouhých) projektů a zohlednit veličiny odvedené práce, časových zpoždění, nově přidaných úkolů a dalších změn v projektu, je třeba analýzu opřít o jednotný základ. Tuto roli spolehlivě plní peníze, respektive náklady na plánované a realizované práce. Přehled těchto parametrů modelu analýzy přidané hodnoty shrnuje další z tabulek: Tab. 3 Přehled parametrů a ukazatelů analýzy přidané hodnoty Veličina
Vysvětlivky
PV
Plánovaná hodnota (BCWS – Budgeted cost of work scheduled)
AC
Skutečné náklady (ACWS – Actual cost of work scheduled)
EV
Vytvořená hodnota (BCWP – Budgeted cost of work performed)
BAC
Celkový rozpočet pro dokončení projektu (BAC – Budget at completion)
EAC
Odhad nákladů v okamžiku dokončení (EAC - Estimation at completion)
CPI
Nákladový index (CPI – Cost performance index = EV/AC)
SPI
Index výkonnosti plánu (SPI – Schedule performance index = EV/PV )
CV
Nákladová odchylka (CV – Cost variance = EV – AC)
SV
Plánová (zpoždění/předstih) odchylka (SV – Schedule variance = EV - PV)
Zdroj: Vlastní zpracování dle Gradua Cegos, Projektový manažer – příprava k certifikaci, str. 50 -51
Praktickou aplikaci přidané hodnoty ukazuje další příklad. Zbývá doplnit, že vhodný nástroj pro její zpracování představuje znovu Microsoft Office Project 2007. Výčet funkcionality tohoto nástroje tedy dále narůstá. Příklad: Analýza přidané hodnoty v projektu dovolená V návaznosti na předchozí příklad projektu dovolená byly vypočteny hodnoty všech veličin obsažených v analýze přidané hodnoty. Jak vypadá situace projektu ke zvolenému datu 12.9.2006 ukazuje tabulka Přidaná hodnota převzatá z aplikace Microsoft Office Project 2007 a grafický sumář poskytuje přiložený graf.
Tab. 4 Přidaná hodnota vytvořená v aplikaci Microsoft Office Project 2007
Zdroj: Vlastní pracování
Zdroj: Vlastní zpracování
Obr. 12 Analýza přidané hodnoty: S-křivka nákladů Z dat lze vyčíst následující:
Projekt se jako celek prodražuje:
CV je záporná (CV = -2272,50 Kč)
Projekt má malé (oproti CV) zpoždění:
SV je záporná (SV = - 312,50 Kč)
Relativní propady oproti plánu jsou:
Cca 6,9% u rozpočtu (CPI = 0,931) Cca 1% u harmonogramu (SPI = 0,99)
4.2
Kritická cesta
Srdcem každého harmonogramu je Kritická cesta. Jedná o takovou sekvenci úkolů (úkol – vazbaúkol), která svým rozsahem vymezuje čas potřebný ke splnění celého projektu, tedy všech úkolů. Znalost kritické cesty má pro manažera klíčový význam. Základním a nezbytným předpokladem umožňujícím využití metody kritické cesty v projektech je správně postavený časový harmonogram projektu. Tento musí mít především jednoznačně vymezený konec, tedy spíše bod, kam ústí všechny cesty projektu (sekvence vzájemně závislých úkolů). Základním přínosem kritické cesty je podpora řízení projektu, kde hraje nezastupitelnou úlohu. Smyslem této metodiky není úsilí o to, aby všechny, nebo alespoň drtivá většina, úkolů proběhla, tak jak byly plánovány. Spíše se snaží na logickém základě nalézt podstatné úkoly pro dodržení časového rozsahu projektu jako celku. „Kritická cesta však bývá v praxi často nesprávně vysvětlována, chápána a - co je z pohledu projektů nejzávažnější – nedostatečně využívána.“ Drahoslav Dvořák, Manažerské využití kritické cesty, www.projektoverizeni.spaces.live.com
Konkrétní příklady přidané hodnoty kritické cesty mohou být zformulovány například následovně: 1. Příprava na řízení projektu – usnadnění rozhodování, na co je třeba si dát pozor a co lze sledovat „volněji“ (nekritické cesty). 2. Krizové řízení při zpoždění v projektu během realizace – co udělat ihned a co potom. 3. Efektivita rozhodování – kritická cesta pomáhá manažerovi řešit situace, kdy dojde ke zpoždění více, než jednoho úkolu současně. To, zda se jedná o úkol kritický, či nikoliv rozhoduje o tom, které přetížení se bude řešit nejdříve (rozsah zpoždění se posuzuje až poté). Rozdělení citováno dle Drahoslav Dvořák, Manažerské využití kritické cesty, www.projektoverizeni.spaces.live.com
Pokud manažer projektu tyto efekty nevyužije, dostává sám sebe do velmi nevděčné pozice: subjektivně vynakládá vysoké úsilí a snaží se řešit maximální množství problémů projektu. Ovšem dopady na průběh projektu mohou být různé. Takový vedoucí projektu bývá následně semlet hned třemi mlýnskými kameny naráz: -
Projektovým týmem – vedení projektu stylem „nemám na Vás čas“.
-
Managementem - projekt je stále ve skluzu.
-
Sám sebou – snaha být všude znamená nebýt nikde.
Projekty mívají 1 kritickou cestu, výjimečně se najde v projektu více stejně dlouhých cest s vlivem na celkovou dobu trvání projektu. Nicméně kritická cesta se může v průběhu projektu měnit. Tuto skutečnost lze vnímat spíše jako teoretickou. Změna kritické cesty v průběhu vlastní realizace projektu, je pro manažera krajně nevýhodná. Na kritické a nekritické úkoly je totiž aplikován diametrálně odlišný způsob řízení času. Zatímco
Kritickou
cestu
je
třeba
řídit
na
bázi
každého
úkolu
na
ní
obsaženého,
u nekritických cest je tomu jinak. Úkoly na nich zahrnuté se řídí jako celek, respektive podle míry čerpání rezervy, která zbývá do změny nekritické cesty na cestu kritickou. Příklad: Průběh projektu Stavba výrobní haly Typový projekt - stavba výrobní haly – se nyní posunul směrem k realizaci. Z obr. 14 je patrné, že došlo ke splnění prvních dvou úkolů. Na kritické cestě zůstávají celkem čtyři úkoly (včetně milníku Kolaudace haly). U těchto úkolů musí manažer dbát na dodržení termínů plánovaného zahájení a dokončení. Na rozdíl od úkolů nekritických – tedy instalace krovů a pokládání krytiny – kde zcela postačí hlídat si velikost rezervy. Ta aktuálně činí 2,8 dne. Pochopitelně řeč je pouze o řízení času. Náklady je třeba řídit přes všechny úkoly stejně. Přechod na řízení nekritických úkolů na bázi jednotlivých úkolů může manažer uskutečnit teprve v případě hrozby vyčerpání rezervy a hrozící změny celé kritické cesty.
Zdroj: Vlastní zpracování
Obr. 13 Změna kritické cesty projektu vlivem prodloužení nekritického úkolu
Zdroj: Vlastní zpraco vání
Obr. 14 Průběh projektu: Kritické úkoly, nekritické úkoly a rezerva u nekritické cesty Jak tedy řídit nekritické úkoly? Princip řízení úkolů na nekritických cestách bývá v praxi nejčastěji aplikován na bázi třetin. Pokud dojde k vyčerpání rezervy v rozsahu 1/3 a méně, pak není třeba reagovat vůbec. Zpravidla se totiž
jedná o drobná zpoždění, jejichž náprava nemá pro projekt jako celek výraznější přínos. Je tedy mnohem snazší nechat taková zpoždění ovlivnit projekt a šetřit síly na vážnější problémy. Poškození
rezervy
v rozsahu
1/3
–
2/3
znamená
již
konkrétní
hrozbu
pro
projekt
a manažer už se jí musí zabývat. Nemusí jít nutně o aplikaci protiopatření, většinou postačí zahájit s týmem jejich přípravy. Poškození rezervy převyšující 2/3 pak vyžaduje realizaci připravených akcí. Hrozba změny kritické cesty se stává reálnou a bez podniknutí konkrétních opatření k její změně také dochází. Řízení dle čerpání rezerv lze v aplikaci Microsoft Office Project 2007 podpořit nastavením personalizovaných indikátorů stavu. Příklad takového vlastního dynamicky se měnícího indikátoru je zobrazen na obr. 15. Kritické úkoly žádnou rezervu nemají, jejich zpoždění se rovnou promítá do zpoždění projektu, proto jsou indikovány červeně. Nekritické úkoly se však mohou zpozdit až o 3 dny, proto je jejich statut daný mírou nečerpané rezervy pozitivní – zelená barva.
Zdroj: Vlastní zpracován
Obr. 15 Vlastní indikace stavu čerpání rezervy Zpoždění realizace, nebo neplánované prodloužení doby trvání úkolu však může situaci změnit. Pokud dojde k vyčerpání více, než 2/3, změní se indikace na červenou.
Zdroj: Vlastní zpracování
Obr. 16 Změna stavu čerpání rezervy vlivem zpoždění nekritických úkolů
4.3
Řešení studentského syndromu a Parkinsonova zákona
Na pomyslném vrcholu řízení časové dimenze projektu stojí řešení Studentského syndromu a Parkinsonova zákona. „O existenci Studentského syndromu a Parkinsonova zákona může manažer projektu pochybovat, či dokonce nesouhlasit, ale to je tak jediné, co se s tím dá dělat...“ Upraveno dle textu Divadla Járy Cimrmana, www.djc.cz Příklad: Vítejte v projektu Představte si, že vaše společnost připravuje projekt vývoje nového výrobku a byli jste požádáni, abyste vypracovali tržní analýzu oblasti, kde žijete. Vlastní práce by Vám měla zabrat zhruba jeden pracovní týden, nicméně vzhledem ke svému vytížení se vám podaří vyjednat celý měsíc. Na otázku týkající se dokončení úkolu jste tedy manažerovi projektu odpověděli: „Za dvacet pracovních dnů“. Znamená to však, že budete psát jednu stránku denně? Nebo se zachováte jinak? A kdy vlastně začnete na studii pracovat? A kdy celou práci odevzdáte? Čas běží… V kalendáři uteklo deset pracovních dnů. Podle matematické logiky by vaše zpráva měla mít v tomto bodě rozsah právě deset stran. Shoduje se ale toto tvrzení se skutečným stavem? Jistě se najde několik z vás, kteří budou mít i více, než polovinu, možná dokonce celou zprávu. Mnohem pravděpodobněji se ukáže, že mnozí budou mít sepsáno osm a méně stran, někteří se dokonce rozhodnete celou práci odložit, protože vás takříkajíc zatím v botě netlačí. Že se s touto situací nesetkáváte poprvé? Pak se, prosím, seznamte se Studentským syndromem, svým „tichým společníkem“. Jeho princip se dá popsat zhruba následovně: pokud je na úkol dostatek času, jen těžko lze najít vnitřní sílu, která by vás motivovala k jeho rovnoměrnému plnění. Znamená to však, že vaše jednání nebylo správné? Nikoliv, přece jste stále v časovém limitu, který vám byl přidělen manažerem projektu. Navíc počítáte s dokončením prací za dalších deset dnů, a pokud odhadujete
stejně jako manažer, že práce na zprávě zabere pouhých pět dnů – tedy polovinu toho, co máte k dispozici. Formulací předchozí myšlenky jsme v podstatě nadefinovali další přirozenou lidskou vlastnost, kterou tentokráte popisuje Parkinsonův zákon. Ten tvrdí: Pokud opět neexistují žádné tlaky na urychlení plnění úkolu, v drtivé většině případů nedochází k plnění s předstihem. Za těchto podmínek jsou úkoly zpravidla dokončeny přesně v okamžiku jejich plánovaného konce. Úvaha však ještě nemá konec. Dojde totiž k dalšímu posunu v čase a uplyne další týden. Zbývá posledních pět dnů do odevzdání. Nyní už si asi všichni uvědomujete nutnost začít na zadané zprávě pracovat a proto se i poslední z vás pravděpodobně pustíte do díla. Někteří budou dokonce psát teprve úvodní stránky – ti budou mít plné ruce práce, aby termín uzávěrky vůbec stihli. Situace jako dělaná pro útok Murphyho zákonů… Z fungování zákona schválnosti je možné vybrat třeba neodkladnou služební cestu, nebo naléhavý problém ve výrobě apod. A znovu je tu otázka: Bude Vaše chování opravdu špatné, pokud se budete nyní věnovat řešení kolapsu výroby?
Protože Studentský syndrom představuje součást přirozeného lidského chování, stojí jeho vymýcení z projektu obrovské úsilí. Z tohoto důvodu nemá smysl se snažit Studentský syndrom vymýtit, mnohem většího efektu lze dosáhnout přípravou projektu na jeho existenci a projevy. Strategie pro řízení časového průběhu projektu se bude opírat o 3 základní stavební pilíře: 1. Časové plánování a řízení Prvním krokem k řešení je úprava metodiky plánování času tak, aby bylo možné účinně se bránit atakům syndromu. Na praktickém příkladu Vítejte v projektu bylo jasně patrné, že časová rezerva, která byla poskytnuta k jednotlivým zadáním, byla de facto promrhána. Je tedy zřejmé, že se bude muset přístup k časovým rezervám změnit. Řešení nabízí Elyiahu M. Goldratt v díle Kritický řetěz, kde nabádá k odpoutání rezerv od jednotlivých úkolů (tzn., dojde ke zkrácení doby trvání úkolu) a přesunu rezervy na konec celé fáze projektu jako „časový nárazník“.
2. Řízení dle poškození nárazníku – vyrovnávacího úkolu Druhý z pilířů časového řízení představuje zohlednění poškození nárazníků – tedy vyrovnávacích úkolů. Jeho princip byl naznačen v předchozí části věnované kritické cestě a funguje obdobně.
Zdroj: Vlastní zpracování
Obr. 17 Srovnání plánu projektu bez a s nárazníkem 3. Motivace týmu směrem ke splnění cíle Role manažera projektu a role trenéra sportovního týmu jsou si velmi podobné. Výsledky manažera jsou totiž zcela závislé na výsledcích týmu. Před nutností čelit této pravdě neuchrání manažera sebedokonalejší nástroj. Motivovat tým k výkonům dle představ manažera nebývá rozhodně jednoduché. Vždyť manažer má v úmyslu razantně zkrátit dobu trvání jednotlivých úkolů! Zároveň musí vysvětlit, jak bude využit nárazník. K tomu, aby bylo docíleno žádoucích výsledků, je třeba, aby se projevil týmový duch.
5. Podpůrné nástroje Nasazení podpůrných technologií by vždy mělo být realizováno v kontextu projektového prostředí. Podle jeho dimenzí lze v případě Microsoft office Project 2007 volit mezi nasazením této aplikace samostatně, případně rozšířit pokrytí řešením i na projektový tým. Nejvyšší úroveň technologické podpory znamená zahrnutí všech pracovníků v organizaci včetně vedení společnosti.
5.1
Microsoft Office Project 2007
Aplikace Microsoft Office Project 2007 představuje již několikátou generaci tohoto nástroje. V současnosti umožňuje tento nástroj profesionální naplánování a sledování projektu a dobrou kooperaci s ostatními programy rodiny Microsoft Office systém 2007. Nicméně manažer projektu musí
mít
stále
na
paměti,
že
se
jedná
pouze
o aplikaci podporující rozhodování. „Microsoft Project je program, který umožňuje racionální a promyšlené plánování a řízení společných projektů, koordinaci subprojektů provádění analýz vlivů změn a odchylek od standardního průběhu, vyhodnocování úspěšností etap projektů a mnoho dalších možností, které jsou nedílnou součástí metod řízení v práci každého manažera a vedoucího pracovníka.“ František Adamec, Řízení projektů pomocí MS Project 2000, rešerše
Následující přehled funkcionality může sloužit jako částečná rekapitulace (obr. 18).
5.2
Řešení Microsoft Enterprise Project Management
Druhá úroveň technologické podpory pro řízení projektů počítá s rozšířením řešení na celý projektový tým, nejen na osobu manažera projektu. Řešení společnosti Microsoft pro správu podnikových projektů tak představuje ideální řešení pro organizace vyžadující koordinaci a standardizaci více projektů, centralizovanou správu zdrojů a vedení projektů na "vyšší úrovni". Základními potřebami, které stojí za požadavky na implementace tohoto systému, jsou ambice:
Zdroj: Vlastní zpracování s využitím stránek http://office.microsoft.com
Obr. 18 Základní přehled funkcionality Microsoft Office Project 2007 •
Lépe spravovat pracovní úkoly Efektivně přidělovat pracovníky na projekty znamená hlídat jejich kapacitu přes všechny projekty. Zdroje lze dále třídit např. podle dosažených znalostí a schopností apod. Poté je k dispozici automatizované přidělování úkolů a podpořen je i proces aktualizace skutečného stavu prací na úkolech. Manažer pak promítá změny do projektů prostřednictvím přijímání elektronických hlášení o stavu.
•
Řídit více projektů současně
Tato ambice znamená především udržení nadhledu nad více projekty a snadného odhalení problémů. Další prvek představuje spojování několika projektů do jediného tzv. multiprojektu a jeho následné řízení. Multiprojektové prostředí vyžaduje též mnohem detailnější analýzy a také schopnost vytvářet prognózy, řídit rizika a problémy. Po technologické stránce se řešení Enterprise Project management skládá ze tří komponent: [1] Microsoft Office Project 2007 Professional Aplikace Microsoft Office Project Professional 2007 poskytuje veškerou funkcionalitu popsanou v předchozí části. Ve spojení se serverem Microsoft Office Project Server 2007 nabízí navíc účinné funkce pro správu portfolia a zdrojů. [2] Microsoft Office Project Server 2007 Rozšíření řízení projektu ve smyslu řízení projektového týmu vyžaduje nasazení Microsoft Office Project Server 2007. Tento produkt slouží jako rozhraní pro komunikaci z databází, kde jsou uložena veškerá projektová data. „Microsoft Office Project Server je aplikační řešení, které umožňuje soustředění projektových informací pro skupinu uživatelů, nebo pro celou organizaci. Nabízí platformu pro publikování a sdílení projektových harmonogramů a sledování stavu realizace jednotlivých projektových úkolů.“ Jan Kališ, Karel Hyndrák, Vlastimil Tesař, Microsoft Project kompletní průvodce pro verze 2003 a 2002, str. 270
[3] Microsoft Office Project Web Access 2007 Rovněž portál pro týmovou spolupráci poskytující členům týmu přístup k projektovým informacím byl dále zdokonalen ve smyslu posílení komunikace v reálném čase. Pomocí Microsoft Office Project Web Access 2007 mohou členové týmu, ředitelé a vedoucí zdrojů informace zobrazovat a aktualizovat. Nespornou výhodou je i fakt, že rozhraní je čistě webové, čili přístupné de facto odkudkoliv pomocí internetového prohlížeče. Rozšiřitelná architektura řešení poskytuje možnost přizpůsobit řešení v souladu s podnikovými procesy, sdílet data s jinými systémy a škálovat celé řešení podle růstu podniku.
Zdroj: Upraveno dle http://office.microsoft.com
Obr. 19 Technologická struktura řešení Enterprise Project Management
5.3
Microsoft Office Sharepoint Server 2007
Myšlenka na propojení vhodné technologie a metodiky projektového řízení má dlouhou historii.
V podstatě už od chvíle, kdy se začne s pracemi na prvních projektech a odstartuje vývoj vlastní metodiky pro řízení projektů, je společnost postavena před dvě zásadní otázky: •
Jak zajistit dosažitelnost dat „z terénu“ (např. od zákazníka)?
•
Jak zajistit aktuálnost dat?
Odpověď na tyto otázky lze nalézt v portálových technologiích. Portál v podstatě znamená strukturovanou prezentaci dat prostřednictvím webových stránek. „Microsoft Office SharePoint Server 2007 představuje integrovaný balík serverových služeb schopných pomoci zlepšit efektivnost organizace. Poskytuje komplexní řízení oběhu dokumentů, sdílení webového obsahu, vyhledávání informací napříč informačními zdroji v organizaci, akceleruje sdílení informací napříč podnikovými procesy a dostupných odkudkoliv prostřednictvím např. mobilních zařízení. To přináší lepší přehled o stavu a vývoji podniku. Microsoft Office Sharepoint Server 2007
umožňuje provozovat intranetové, extranetové i internetové řešení prostřednictvím jediné technologie bez nutnosti spoléhat se na různé systémy.“ Internetové stránky společnosti Microsoft http:// office.microsoft.com
Protože řešení Microsoft Office Sharepoint Server 2007 využívá stejné principy jako Enterprise Project Management, lze je spojit do jednoho celku a vytvořit tak univerzální komunikační rozhraní firmy pokrývající projektové i neprojektové aktivity. •
Rozhraní portálu je uživatelsky přívětivé a snadno ovladatelné. Informace jsou logicky setříděné do celků: např. novinky, dokumenty, kontakty apod.
Zdroj: Vlastní zpracování
Obr. 20 Domovská stránka projektového portálu •
Díky jednoduché správě zabezpečení lze zamezit neoprávněným přístupům a intuitivně řídit uživatelskou práci s metodikou (čtení vs. editace).
•
Standardní funkcionalita portálu pro práci s verzemi dokumentů je jako stvořená pro nastartování procesu neustále aktualizovatelnosti metodiky. Na webu jsou vždy vystaveny pouze aktuální verze a všechny předchozí jsou archivovány.
Zdroj: Vlastní zpracování
Obr. 21 Verzování dokumentů v aplikaci Microsoft Office Sharepoint Server 2007 •
Také uchopení znalostní databáze je - znovu díky standardním možnostem technologie Sharepoint - velmi snadné – pomocí Blogů, případně WIKI stránek dochází k výměně zkušeností ve formě aktuálních trendů.
Konečně, portál lze propojit i s ostatními systémy typu CRM, nebo ERP. Tím vzniká unikátní komunikační rozhraní společnosti – tedy 1 přístupový bod pro veškeré informace. Informace lze pak sdružovat do logických celků a vytvářet tak weby dle rolí, divizí, segmentů trhu, produktu apod. Jako ukázka poslouží náhled na stránku Generálního ředitele.
Zdroj: Vlastní zpracování
Obr. 22 Znalostní databáze na bázi Blogu na portálu Microsoft Office Sharepoint Server 2007
Zdroj: Vlastní zpracování
Obr. 23 Jednotné komunikační rozhraní firmy – portál kombinující projektová a neprojektová data
6. Závěr Předchozí text si kladl za cíl ukázat na dvě základní skutečnosti: 1. Podporu projektového řízení je třeba volit citlivě vůči projektovým poměrům v organizaci. Vyrazit s pomyslným kanónem na vrabce, či přivést do praxe řešení opačného charakteru končí vždy špatně. 2. Nástroje se bez metodiky neobejdou. Pro úspěch v projektech je třeba zvážit optimální kombinaci nástrojů z oblasti informačních technologií a metodických standardů. Tyto musí být ve vzájemné rovnováze – používání pokročilých vlastností software bez vazby na metodické pozadí ústí většinou v problémy v oblasti tzv. soft skills, tedy managementu, komunikace, motivace apod. Naproti tomu nedocenění nástrojů končívá v praxi spoustou vizí na téma „co by mohlo být“ ovšem realizace za velkými cíli zpravidla pokulhává.
Proto vždy dbejte na to, aby obě tyto roviny byli vyvážené. Bez této rovnováhy nejen že projekty nebudou úspěšné, ale navíc se při dosahování těchto neúspěchů hodně zapotíte.
7. Přehled použité odborné literatury Knižní publikace [1]
ADAMEC, F. Řízení projektů pomocí MS Project 2000. Grada v roce 2001, ISBN 80-7169-793-1
[2]
FIALA, P. Projektové řízení – modely, metody, analýzy. Professional Publishing v roce 2004, ISBN 80-86419-24-X.
[3]
GOLDRATT, E. M. Kritický řetěz. Interquality v roce 1999, ISBN 80-902770-0-4.
[4]
HYNDRÁK, K. Microsoft Office Project - Hotová řešení pro verze 2000 -2007 Computerpress v roce 2007, ISBN 978-80-251-1681-4.
[5]
KALIŠ,
J.,
HYNDRÁK,
K.,
TESAŘ,
V. Microsoft
Project
–
kompletní
průvodce
pro verze 2003 a 2002. Computer Press v roce 2003, ISBN 80-251-0074-X. [6]
ROSENAU, M. D. Řízení projektů. Computer Press v roce 2000, ISBN 80–7226-218-1.
Standardy Projektového řízení [7]
ČSN ISO 10 006: Management jakosti – směrnice jakosti v managementu projektu. Praha, Český Normalizační Institut. Listopad 1998.
[8]
DUNCAN, W. R., A Guide to the Project Management body of knowledge. Project Management Institute v roce 1996, průběžně aktualizováno na www.pmi.org.
[9]
GRADUA CEGOS S. R. O.: Projektový manažer – příprava k certifikaci IPMA. Praha, PM Consulting s. r. o. Rok 2001.
[10] GRADUA CEGOS S. R. O.: Příprava a řízení projektů v průmyslu – studijní texty. Praha, PM Consulting s. r. o. Rok 2002. Vlastní články autora [11]
DVOŘÁK, D., Než rozjedete projektové řízení, zkontrolujte semafor! Praha, www.projektoverizeni.spaces.live.com, rok 2007
[12]
DVOŘÁK, D., Manažerské využití Kritické cesty Praha, www.projektoverizeni.spaces.live.com, rok 2007
[13]
DVOŘÁK, D., Myšlenkové mapy v Microsoft Project Praha, www.projektoverizeni.spaces.live.com, rok 2007
[14]
DVOŘÁK, D., Hledá se doba trvání úkolu. Zn. Jen reálně Praha, www.projektoverizeni.spaces.live.com, rok 2007
Články ostatních autorů [15]
CHUDOBA, R. Formulace projektu metodou logického rámce. Praha, www.teamtechnologies.cz. Rok 2001.
[16]
I.C.C.C.: Metoda kritického řetězu. Praha, www.iccc.cz. Rok 2004.
Internetové zdroje [17] [18]
DIVADLO JÁRY CIMRMANA, www.djc.cz MICROSOFT: Produktová stránka Microsoft Office Project 2007. Redmond, http://office.microsoft.com. Rok 2007.
[19]
MICROSOFT: Produktová stránka Microsoft Office Project Server 2007. Redmond, http://office.microsoft.com. Rok 2007.
[20]
MICROSOFT: Produktová stránka Microsoft Office Sharepoint Server2007 . Redmond, http://office.microsoft.com. Rok 2007.
[21]
MICROSOFT: Intranetová stránka Microsoft office system. Redmond, http://officesystem. Rok 2007.