Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Projektové řízení v mezinárodních společnostech (srovnání projektových přístupů) Bakalářská práce
Autor:
David Jelínek Informační technologie, Manaţer projektů IS
Vedoucí práce:
Ing. Václav Šebek, CSc.
Praha
Prosinec, 2011
1
Prohlášení: Prohlašuji, ţe jsem bakalářskou a v seznamu uvedl veškerou pouţitou literaturu.
práci
zpracoval
samostatně
Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen/a se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Chýni
1.6.2012
2
David Jelínek
Poděkování: Za odborné vedení bakalářské práce, cenné připomínky a rady bych chtěl poděkovat panu Ing. Václavu Šebkovi, CSc. a Janu Törokovi, projektovému manaţerovi společnosti IBM ČR.
3
Anotace: Bakalářská práce se zabývá problematikou projektového řízení v mezinárodních společnostech. Je zaměřena na srovnání společností vyuţívající uznávané postupy a společností, které se rozhodli jít vlastní cestou a ţádné metodiky nevyuţívat. V první části jsou popsány nejrozšířenější mezinárodní metodiky. Dále je podrobněji pojednáno o přístupu společnosti IBM a zejména Huawei Technologies. Závěr práce je věnován konkrétní případu z praxe.
Klíčová slova: projektové řízení, metodika, portfolio, náklady, kontrola
Annotation: This thesis deals with project management in international companies. It is focused on the comparison of the companies using standard recognized methods and companies that have decided to go their own way and not using any method. The first section describes the most common international methods. Next part includes detailed information about IBM´s methodology and Huawei Technologies approach. Last section is devoted to a particular case from practice.
Key words: project management, method, portfolio, costs, control
4
Obsah 1. 2. 3.
Úvod ................................................................................................................................... 6 Základní pojmy projektového managementu ..................................................................... 6 Metodiky projektového řízení ............................................................................................ 8 3.1 Project Management Body of Knowledge (PMBOK) ................................................. 8 3.2 PRINCE2 ................................................................................................................... 12 3.3 PMBOK nebo PRINCE2 ........................................................................................... 14 3.4 IPMA ......................................................................................................................... 14 3.4.1 Elementy technických kompetencí ..................................................................... 14 3.4.2 Elementy behaviorálních kompetencí ................................................................ 20 3.4.3 Elementy kontextových kompetencí .................................................................. 22 3.5 Ostatní metodiky ........................................................................................................ 23 3.5.1 Agilní metodiky .................................................................................................. 23 3.5.2 RUP .................................................................................................................... 23 3.5.3 Six Sigma............................................................................................................ 23 4. World Wide Project Management Metodology................................................................ 24 4.1 Co je to WWPMM ..................................................................................................... 24 4.2 Koncept ...................................................................................................................... 27 4.3 Organizace ................................................................................................................. 28 4.4 Procesy a postupy ...................................................................................................... 28 4.5 Řízení projektů v IBM ČR ......................................................................................... 29 6. Asijský model projektového řízení ................................................................................... 30 6.1 Projektové řízení ........................................................................................................ 31 6.2 Výběr projektů ........................................................................................................... 32 6.3 Plánování projektů ..................................................................................................... 34 6.4 Řízení a koordinace realizace projektu ...................................................................... 39 6.5 Monitorování a kontrola projektových prací ............................................................. 40 6.6 Řízení nákladů projektu ............................................................................................. 41 6.7 Uzavření projektu či fáze ........................................................................................... 41 7. Případová studie – projekt realizovaný ve vybrané asijské společnosti ........................... 42 7.1 Popisovaný projekt..................................................................................................... 42 7.2 Projektová idea .......................................................................................................... 42 7.3 Příprava projektu ............................................................................................................ 43 7.3 Realizace projektu...................................................................................................... 44 7.4 Vývoj projektové strategie v zajišťování sluţeb údrţby............................................ 45 8. Vlastní úvaha a doporučení .............................................................................................. 46 9. Závěr ................................................................................................................................. 47 Citace a pouţité zdroje ............................................................................................................. 49 Seznam pouţitých obrázků a zkratek ....................................................................................... 49
5
1.
Úvod
Cílem této bakalářské práce je popsat základní pojmy projektového managementu, celosvětově uznávané standardy projektového řízení jako jsou PMI a PRINCE2, kterou jsou brány jako nejrozšířenější a nejuznávanější metodiky v dané oblasti. Půjde zejména o jejich principy, cíle a nástroje. Na tyto metodiky naváţe popis metodiky společnosti IBM, která vychází z metodiky PMBOK. Na závěr této části se pokusím popsat průběh projektů v rámci IBM Česká republika. Druhým cílem této práce je vysvětlit chápání projektového řízení z pohledu čínské společnosti, která nevyuţívá ţádné běţné standardy a metodiky. Práce se zaměří zejména na chybějící kontrolní mechanismy, nejednotné postupy a z toho plynoucí problémy a nedostatky. Tento přístup se pokusím vysvětlit na reálném projektu, který společnost realizuje od roku 2010. Případová studiem ukáţe postup přípravy projektu, samotnou realizaci aţ po průběţné vyhodnocování. Závěr bakalářské práce věnuji zhodnocení a porovnání přístupu společností IBM a Huawei Technologies. Snahou bude nalézt výhody a nevýhody obou přístupů a moţná doporučení plynoucí z pouţívaných procesů, nástrojů atd. Nezbytnou nutností pro zpracování této práce bylo seznámení se s obsahem jednotlivých metodik a jejich aplikací. Velkým přínosem byly konzultace přímo s jednotlivými uţivateli a projektovými manaţery. Na základě těchto informací bylo moţné vytvořit si přehled o výhodách a nevýhodách různých postupů. Pro potřeby této práce byla stanovena základní hypotéza: „Podmínkou úspěšně zvládnutého projektového řízení je vyuţívání standardizovaných postupů.“
2.
Základní pojmy projektového managementu
Projektový management obsahuje řadu pojmů – projekt, atributy projektu, projektový trojimperativ, projektové řízení, program, portfolio a další. Projekt lze definovat jako časově omezené úsilí vynaloţené na vytvoření unikátního produktu, sluţby nebo výstupu. Informační projekty vyuţívají k vytvoření produktu, sluţby či výstupu hardware, software nebo sítě. Projekty existují v nepřeberném mnoţství tvarů a velikostí. Projekt nám mohou pomoci definovat určitě atributy – jedinečný účel (jedinečným účelem projektu můţe být například vytvoření zprávy tvořené nápady a myšlenkami lidí z celé firmy, 6
výsledek by byl pouţit pro další diskuzi a projekty), dočasnost (kaţdý projekt má jednoznačný začátek a konec), postupné rozpracování (na začátku jsou projekty často definovány velmi obecně a zeširoka, postupem času se jednotlivé činnosti a detaily stávajíc konkrétnější), zdroje (zahrnují lidi, hardware, software), sponzor (obvykle určuje směr projektu a poskytuje finance), nejistota (vzhledem k jedinečnosti kaţdého projektu je někdy obtíţné definovat cíle, odhadnout, jak dlouho bude trvat jeho dokončení atd.). Kaţdý projekt je ovlivněn třemi atributy – rozsahem, časem a náklady. Tyto atributy se v projektovém řízení označují jako projektový trojimperativ. Aby všechny tyto činnosti mohli efektivně fungovat, je třeba je řídit. V současné době je pro projektový trojimperativ charakteristické, ţe alespoň jeden z těchto atributu nebude splněn. Chceme-li dodrţet náklady, obvykle musíme akceptovat zdrţení, chceme-li dodrţet rozsah a čas, pravděpodobně budeme muset počítat s vyššími náklady. Projektové řízení je aplikací znalostí, dovedností, nástrojů a technik při realizaci projektových aktivit, kdy cílem je dosaţení poţadavků projektu. Mezi znalosti a dovednosti patří například řízení rozsahu, času, nákladů, kvality, lidských zdrojů apod. Při řízení projektů je třeba usilovat o splnění čtyř pilířů – plánovaného rozsahu, času, nákladů a kvality. Projektů se obvykle účastní velké mnoţství zainteresovaných stran. Patří mezi ně sponzor projektu, projektový tým, podpůrný personál, zákazníci, uţivatelé, dodavatelé a oponenti projektu. Sponzorem projektu je obvykle vlastník aplikace, který je ochoten projekt financovat a který je zákazníkem projektového manaţera. Projektový manaţer nese z hlediska zadavatele odpovědnost a vykonává k tomu příslušné pravomoci, proto je vţdy velmi důleţitá důvěryhodnost a spolehlivost. Projektový manaţera je odpovědný za projekt ve všech jeho fázích, definuje projektový tým, zpracovává projektový plán, řídí projekt, monitoruje a hodnotí dosaţené cíle. Ve větších společnostech je součástí týmu oponent. Úkolem oponenta je dotazovat projektového manaţera ohledně plánovaných akcí, stanovených cílů atd. a hledat moţná rizika, nereálné cíle a přínosy projekty. Program je skupina projektů, které spolu souvisejí a které jsou řízení koordinovaně za účelem získání větší efektivity, kontroly a zisku – toto by nebylo moţné, pokud by projekty byly řízení zvlášť. Typickými příklady programů v oblastí informačních technologií jsou infrastruktura, vývoj aplikací a uţivatelská podpora.
7
Řada společností rovněţ zavádí nové obchodní strategie řízení portfolia projektů. Řízení portfolia se zaměřuje na otázky, které se týkají práce na správných projektech, investic do správných oblastí, revize zdrojů pro dosaţení konkurenceschopnosti.
3.
Metodiky projektového řízení
3.1
Project Management Body of Knowledge (PMBOK)
PMBOK je nejznámější a nejrozšířenější standard pro oblast projektového řízení. Byl navrţen institutem PMI (Project Management Institute) v roce 1987. Poskytuje ucelený pohled na problematiku, snaţí se obsáhnout a obecně popsat všechny aspekty projektového řízení a sniţuje míru vágnosti a obecnosti. PMBOK je v první řadě zaměřen na společnosti, které dodávají produkty, resp. sluţby pomocí projektů. Struktura standardu je rozdělena do několika částí – Obecný rámec projektového managementu (úvod, ţivotní cyklus a organizace), Standardy projektového managementu (procesy), Znalostní oblasti (integrační řízení, fáze projektu). Poslední část je věnována přílohám (změny v jednotlivých vydáních, vývoj standardu). Obecný rámec popisuje způsob řízení projektů a jeho základní vlastnosti. Úvod standardu se zabývá definicemi projektu a vymezení projektového řízení. Popisuje také terminologii charakteristickou pro projektový management. V další části je popsán ţivotní cyklus projektu. Velmi zajímavé je uvedení příkladů z praxe, kterými vysvětluje své definované rozfázování projektu. Jednotlivé fáze popisují stavy a aktivity skupin procesů v průběhu projektu. Projekt začíná přípravnou fází, kde dochází k rozhodnutí o realizaci. Po ukončení příprav a akceptaci projektu nastává část plánování. Plánování zahrnuje především rozvrţení činností a jejich rozdělení jednotlivým členům týmu. Dalším krokem je plánování nákladů a příprava rozpočtu projektu. Během všech fází je projekt monitorován a kontrolován. Kontrola se zaměřuje především na změny, rizika, čas, náklady a kvalitu. Podle PMBOK je u fáze kontroly velmi důleţitá zpětná vazba s fází realizace a plánování. Zpětná vazba poskytuje ujištění, ţe výstupy kontrolních procesů při realizaci jsou promítnuty do aktualizace plánu. Fáze uzavření projektu navazuje na výsledky jednotlivých kontrol a vyhodnocuje projekt jako celek. Standard také zdůrazňuje skutečnost, ţe popsané fáze projektu jsou definovány na obecné úrovni. Uvedené rozdělení fází projektu je podle autorů
8
PMBOK provedeno podle věcných činností projektu, kdy například při vývoji softwaru mohou mít fáze řadu jiných podob – úvodní studie, analýzy návrhu, implementace, testování, zavádění a provoz. Hlavní význam tohoto tvrzení je skutečnost, ţe i kdyţ není ţivotní cyklus rozdělen do obecných fází projektu, ale do specifických fází určité skupiny projektů, kaţdá fáze obsahuje tzv. řídící cyklus skupin procesů popsaných standardem PMBOK. PMBOK definuje několik desítek procesů (konkrétní počet se mění podle aktualizací standardu), které navazují na definované fáze ţivotního cyklu a zároveň jsou zahrnuty v některé ze znalostních oblastí. Obecné fáze rozdělují procesy do procesních skupin. V kaţdé skupině jsou popsány tzv. hlavní a pomocné procesy. Podle standardu by pomocné procesy neměly být opomíjeny, protoţe jejich výstupy slouţí jako opora hlavním procesům. Procesní skupiny obsahují tyto procesy – inicializační procesy (dokument popisuje pouze jeden proces a to proces inicializační, ve kterém jde zejména o odsouhlasení projektu, případně další fáze projektu), plánovací procesy (tato skupina popisuje 10 hlavních a 9 podpůrných procesů, které zasahují do všech znalostních oblastí, jde o významnou skupinu procesů), realizační procesy (obsahují jeden hlavní proces, který je zaměřen na řízení dílčích činností definovaných v projektovém plánu a sedm podpůrných procesů jako např. distribuce informací, dosahování kvality atd.), kontrolní procesy (skupina těchto procesů je rozdělena na dva hlavní a šest pomocných procesů, hlavní procesy se zabývají zejména zajištěním kvalitního reportování a integrovanou kontrolou změn, pomocné procesy detailněji popisují dílčí kontroly jako např. kontrola změn, rizik, kvality nákladů) a ukončovací procesy (jsou rozděleny do dvou hlavních procesů označovaných administrativní zakončení a uzavírání smluv). Kaţdý z procesů je standardem dále rozpracován ve v části, která je věnována znalostním oblastem. Jednotlivé části znalostních oblastí obsahují tzv. data flow diagram. Data flow diagram je souhrn zobrazení vstupů a výstupů procesů, které prochází směrem dolů přes všechny procesy v rámci určité oblasti znalostí. Znalostní oblasti představují podstatnou část standardu PMBOK. Jednotlivé znalostní oblasti jsou popsány jejich vlastnostmi a pouţitím. Znalostní oblasti jsou rozděleny do několika částí: 1)
Integrace projektu – zahrnuje procesy a aktivity potřebné pro identifikaci,
definování, spojení, sjednocení a koordinaci různých procesů a projektových aktivit v rámci procesních skupin. Integrační management zahrnuje rozhodování o alokaci zdrojů, kompromisy mezi konkurenčními cíli a alternativami a řízení vzájemných závislostí mezi znalostními oblastmi projektového managementu. Mezi integrační procesy patří: rozvoj
9
zadávacích dokumentů projektu (proces rozvoje dokumentu, který formálně schvaluje projekt nebo fáze a dokumentuje počáteční poţadavky, které jsou ve shodě s poţadavky zainteresovaných stran), rozvoj projektového plánu (proces dokumentace akcí nezbytných pro definování, přípravu, integraci a koordinaci všech přidruţených plánů), řízení a správa realizace projektu (proces provádění prací definovaných v projektovém plánu), monitorování a kontrola projektových prací (proces sledování, revizí postupu tak, aby došlo ke splnění cílů definovaných v projektovém plánu), provádění integrovaného řízení změn (proces přezkoumávání všech poţadavků na změny, schvalování a řízení změn, projektová dokumentace a řízení projektového plánu na základě změn) a uzavření projektu, resp. fáze (proces finalizace všech aktivit napříč všemi procesními skupinami vedoucí k formálnímu ukončení projektu či fáze). Potřeba integrovaného projektového řízení je zřejmá v situaci, kdy jsou jednotlivé procesy v interakci. Jako příklad je moţné uvést situaci, kdy očekávané náklady potřebné pro pohotovostní plán zahrnují integraci procesů v nákladech, času a riziku znalostních oblastí. Jsou-li zjištěny další rizika spojená s různými věcnými alternativami, pak jeden nebo více z těchto procesů můţe být upraven. Zkušení projektový manaţeři vědí, ţe neexistuje jediný způsob jak řídit projekty. 2)
Řízení rozsahu - zahrnuje procesy, které vyţadují ujištění, ţe projekt zahrnuje
všechny poţadované práce, nikoliv práce nutné k úspěšnému dokončení projektu. Řízení rozsahu je primárně zaměřeno na definování a řízení toho, co je a co není zahrnuto v projektu. Řízení rozsahu zahrnuje sběr poţadavků, definování rozsahu, vytvoření WBS (proces dělení výstupů projektu a projektových prací na menší, lépe zvládnutelné komponenty), ověření rozsahu a kontrola rozsahu. Tyto procesy jsou také ve vzájemné interakci. 3)
Řízení času – zahrnuje procesy potřebné pro včasné dokončení projektu. Procesy
zahrnuté v této části jsou definování aktivit, návaznost činností, očekávané zdroje pro jednotlivé aktivity, předpokládané zdroje pro jednotlivé aktivity, rozvoj plánu aktivit a jeho kontrola. Procesy řízení času a jejich nástroje a techniky jsou zdokumentovány v plánu aktivit, který je obsaţen v plánu projektovém a můţe být formální či neformální, stejně jako více či méně detailní, podle konkrétních podmínek projektu. 4)
Řízení nákladů – zde jsou popsány procesy zabývající se odhadováním,
rozpočtováním a kontrolou nákladů tak, aby projekt mohl být dokončen v rámci schváleného rozpočtu. Řízení nákladů zahrnuje procesy, které obsahují očekávání nákladů, stanovení 10
nákladů a kontrolu nákladů. Vţdy je také nutné brát v úvahu poţadavky vlastníka projektu na zachycení nákladů. Primárně se řízení zaměřuje na náklady zdrojů potřebných pro dokončení projektových aktivit. 5)
Řízení kvality – představuje procesy a aktivity, které určují poţadavky na kvalitu a
odpovědnosti tak, aby projekt uspokojil potřeby, kvůli kterým byl uskutečněn. Patří sem plánování kvality, zajištění kvality a kontrola kvality. Je třeba rozeznávat kvalitu a jakost. 6)
Řízení lidských zdrojů – zahrnuje procesy organizace, řízení a vedení projektového
týmu. Projektový tým je sloţen z lidí s přidělenými rolemi a odpovědnostmi za dokončení projektu. Procesy řízení lidských zdrojů jsou tvořeny rozvojem plánu lidských zdrojů, získání projektového týmu, rozvoj projektového týmu a jeho řízení. 7)
Řízení komunikace – představuje procesy nezbytné pro zajištění včasného a
vhodného sběru, distribuce a uchovávání informací o projektu. Projektový manaţeři tráví většinu svého času právě komunikací s členy týmu a jinými zainteresovanými stranami. Patří sem zejména identifikace zainteresovaných stran, plán komunikace, distribuce informací, řízení očekávání zainteresovaných stran a reporting výkonu. 8)
Řízení rizik – zahrnuje procesy plánování rizik, identifikace, analýzy, monitorování a
kontroly rizik na projektu. Cíle řízení rizik jsou zvýšit pravděpodobnost a dopad pozitivních událostí a sníţit pravděpodobnost a dopad negativních událostí v projektu. 9)
Projektový nákup (řízení dodávky) – obsahuje procesy nezbytné pro nákup nebo
získání produktů a sluţeb potřebných pro projekt od třetích stran. Do projektového nákupu patří plánování nákupu, vedení nákupu, administrace nákupu a jeho uzavření. Po prostudování standardu PMBOK je moţné konstatovat, ţe standard v konkrétních oblastech podporuje ISO 9001. Je přehledný a úroveň detailu je na dostatečné úrovni. Z negativních poznatků je moţné zmínit obecnost v některých částech, pouze nastínění některých technik a některé z činností jsou popsány povrchně.
11
3.2
PRINCE2
Metodika PRINCE vznikla v roce 1989 a byla zaloţena na předchozí verzi PROMPT II, která byla pouţívána téměř výhradně pro podporu projektů v IT. Od té doby prošla metodika mnoha úpravami a aktualizacemi, aţ byla v roce 1996 přejmenována na PRINCE2. Poslední a současně aktuální verze je z roku 2009. Garantem a vlastníkem standardu je Office of Government Commerce. Jde o ucelený přístup k řízení projektů jakéhokoliv druhu projektů. PRINCE2 stojí na sedmi principech, tvoří ji sedm procesů a popisuje sedm témat. Vzhledem k moţnosti přizpůsobit metodiku PRINCE2 v rámci aktuálního prostředí projektu, je nutné porozumět principům, které jsou páteří metodiky. Dokumenty je moţné sdruţovat, zjednodušovat, případně vůbec nepouţívat. Procesy mohou být velmi zjednodušeny a kaţdý z nich má mnoho moţností pouţití podle velikosti projektu. Principy ale zůstávají a zaručují, ţe projekt je projektem PRINCE2. Podpora přizpůsobení metodiky zahrnutá přímo v manuálu je významnou předností oproti PMBOK.
Principy PRINCE2 jsou průběţné zdůvodnění
projektu, poučení ze zkušeností, definování role a zodpovědnosti, řízení pomocí etap, dohled na projektem na základě výjimek, důraz na produkty, nutnost upravit metodiku podle aktuálního prostředí. Další důleţitou předností PRINCE2 je opisnost nejen na úrovni procesů, ale i dokumentů. Standard sice nechává na jedné straně prostor pro přizpůsobení, na druhé straně se však snaţí vést projektového manaţera klíčovými činnostmi od projektového mandátu, který projekt spouští, aţ po schválení ukončení projektu řídící radou. Podobně jako PMBOK rozděluje začátek projektu na dva kroky. V prvním kroku dává projektový manaţer dohromady základní podklady pro projektový výbor, aby mohl posoudit, zda se vůbec pouštět do nákladného plánování. Je-li řídící výbor přesvědčen o smysluplnosti a finanční návratnosti projektu, dává schválení a začíná fáze stanovení projektových strategií, plánování projektu, nastavení komunikace, projektových kontrol a v neposlední řadě naplánování projektu a sepsání obchodního případu.
12
Obrázek 1 - Procesy PRINCE2
Na rozdíl od PMBOK existuje v PRINCE2 proces určující fungování řídícího výboru. Pravomoci a zodpovědnosti za vývoj projektu jsou jednoznačně stanoveny a rozděleny mezi projektového manaţera a řídící výbor projektu. PRINCE2 dává plnou zodpovědnost za projekt do rukou sponzora projektu, který vede řídící výbor a nikoliv projektovému manaţerovi. Toto rozdělení se snaţí vnést do celé metodiky jasný řád a méně zkušeným projektovým manaţerům vymezuje pravidla pro vedení projektů. Po naplánování projektu a vypracování obchodního případu přichází opět schválení řídícího výboru, která dává pokyn k zahájení etapy. Právě striktní rozdělení projektu na etapy dává zodpovědným manaţerům moţnost včas identifikovat případné problémy a zasáhnout. V projektech řízených podle standardu PRINCE2 by tedy nemělo docházet k tomu, ţe vedení projektu pozná příliš pozdě nevyhnutelné překročení rozpočtu nebo zásadní nedodrţení časového harmonogramu. Kromě sedmi dříve zmíněných procesů identifikuje PRINCE2 sedm témat a rozpracovává je tak, aby dávaly projektovému manaţerovi dostatečné vodítko při zachování prostoru pro modifikaci – business case (vysvětluje, jak postavit smysluplné zdůvodnění projektu), organizace (popisuje jednotlivé role a vazby mezi nimi), plány (mluví o jednotlivých úrovních plánu a ukazují způsoby a techniky, jak postavit kvalitní plán), progress (nabízí nastavení kontrol mezi řídícím výborem a projektovým manaţerem), rizika (definují případné hrozby nebo příleţitosti a navrhuje, jak takové hrozby identifikovat a proaktivně se jim bránit), kvalita (staví do popředí zákazníkem definované očekávání kvality výsledného produktu a ukazuje cestu projektem tak, aby na konci byla kvalita zajištěna a prokázána), změny (pomáhají projektu vyrovnat se se změnami rozsahu v průběhu dodávky a pomocí navrţeného řízení konfigurací udrţuje pořádek ve verzích a dodávce jako takové.
13
3.3
PMBOK nebo PRINCE2
Z uvedených specifik je zřejmé, ţe metodiky jsou si velmi podobné a jako nejlepší se jeví kombinace obou. Přesto existuje několik doporučení. Pro evropské společnosti bez firemní metodiky, které potřebují, aby je metodika vedla a nabídla postup na úroveň rolí, procesů a dokumentů, se doporučuje metodika PRINCE2. Naopak pro americké společnosti, které se zajímají o nejlepší praxe řízení projektů a zlepšení jednotlivých oblastí, je vhodnější PMBOK.
3.4
IPMA
Standard IPMA je standardem International Project Management Association. Ve srovnání s předchozími standardy je IPMA kompetenční. Není tedy zaměřen na přesnou podobu definovaných procesů a jejich konkrétní aplikaci, ale na schopnosti a dovednosti (kompetence) projektových, programových a portfolio manaţerů a členů projektových týmů. Standard nediktuje procesy, ale doporučuje určité procesní kroky, které je třeba vhodně aplikovat do konkrétní projektové situace. Hlavním významem je právě schopnost vhodné aplikace konkrétními osobami. Ponechává se tedy značný prostor pro kreativitu a vlastní názor. Základní myšlenka této metodiky je velmi podobná ostatním standardům. Problematika je rozdělena do tří základních kompetenčních oblastí – technické kompetence (metody, techniky, nástroje, např. úspěšnost řízení projektu, zainteresované strany, poţadavky a cíle projektu, kvalita), behaviorální kompetence (tzv. měkké dovednosti, např. vůdcovství, sebekontrola, asertivita, uvolnění) a kontextové kompetence (integrační a systémové znalosti a dovednosti, např. orientace na projekt, orientace na program, realizace projektu, finance, právo). Tyto oblasti jsou pak členěny na tzv. elementy kompetencí.
3.4.1 Elementy technických kompetencí a)
Úspěšnost řízení projektu je dána oceněním výsledků projektů zainteresovanými
stranami. Hlavním cílem projektových manaţerů je dosáhnout úspěchu a vyhnout se nezdaru. Na řízení projektu lze nahlíţet jako na podprojekt celého projektu. Pro úspěch řízení projektu je velmi důleţitá integrace, která spočívá v kombinaci poţadavků, aktivit a výsledků projektu s úmyslem dosáhnout cílů a úspěšných výstupů projektu. Projektové řízení dohlíţí na aktivity, které jsou potřebné k sestavení podrobného plánu řízení projektu. Moţné procesní kroky jsou
14
analýza projektu a jeho kontextu, vytvoření koncepcí řízení projektu na základě poţadavků projektu, vytvoření plánu řízení projektu a sestavení týmu, plánování integračních postupů, provádění a kontrola plánů řízení projektu, shromaţďování dosaţených výsledků a jejich vysvětlení, vyhodnocování úspěchů a nezdarů řízení projektu. V praxi se pro projektové řízení pouţívají tzv. kritéria úspěchu projektu, která jsou měřítkem, podle kterého poměřujeme poměrný úspěch nebo neúspěch projektu. Hlavním poţadavkem je jejich srozumitelnost, jednoznačnost a měřitelnost. Existují tři základní soubory kritérií – kritéria vlastníků projektu, tradiční kritéria konečného provozovatele a zisková kritéria financujících subjektů a dodavatelů. Příkladem kritérií úspěšnosti můţe být skutečnost, ţe projekt je funkční, jsou splněny poţadavky zákazníka, výstupní produkt je na trhu včas, v plánované jakosti a ceně a řada dalších. Obecně se tato část kompetencí zabývá finančními kritérii (návratnost investic, čistá současná hodnota), integrací, systémovým myšlením, neustálým zlepšováním řízení projektu, kdy a kdo projekt vyhodnocuje, co vyhodnocujeme v projektu, doporučené postupy vyhodnocení projektu
b)
Zainteresované strany jsou lidé nebo skupiny, které mají zájem na výkonu nebo
úspěchu projektu nebo které jsou projektem ovlivněny či omezeny. Termín zainteresované strany byl do standardu přijat jako oficiálně definovaný termín ISO 14000, v mezinárodních společnostech se častěji pouţívá termín stakeholders. Přihlédnutí k tomuto kompetenčnímu elementu můţe pomoci zvýšit šance na úspěch projektu. Obsahem tohoto elementu jsou informace o identifikaci, analýze a práci se zainteresovanými stranami. Element uvádí tyto aktivity do souvislosti s kontextem projektu či programu. Projekt je ovlivněn a omezen svým vlastním kontextem, proto je vhodné projekt upravit tak, aby splňoval potřeby a očekávání zainteresovaných stran, která je také třeba řídit. Procesní kroky moţné v rámci tohoto elementu jsou například identifikace a stanovení priorit zájmů zainteresovaných stran, analýza zájmů a poţadavků, vytvoření strategie pro jednání se zainteresovanými stranami, zařazení ohroţení a příleţitostí, které zainteresované strany představují, zajištění uspokojení zainteresovaných stran v kaţdé fázi projektu. . Na začátku projektu je nutné provést analýzu zainteresovaných stran a jejich rozčlenění. Element rozděluje zainteresované strany podle významnosti na dvě skupiny – primární a sekundární. Primární jsou reprezentovány vlastníky a investory, zaměstnanci, zákazníky, obchodními partnery a místní komunitou, mezi sekundární patří veřejnost, vládní instituce a samosprávní orgány, konkurence, lobbyisté a různé nátlakové skupiny, média, občanská a obchodní sdruţení. Některé z uvedených stran je
15
také zvykem označovat jako strany dotčené projektem. Na základě provedené analýzy je třeba zváţit jak konkrétně a do jaké míry jednotlivé strany zapojit a jak nastavit jejich spoluúčast na projektových procesech dle jejich vlivu a očekávání. Následuje vytvoření koordinované komunikační strategie, která hraje velmi důleţitou úlohu zejména u významných projektů velkého rozsahu. Komunikační strategie by měla pokrývat minimálně tyto body – popis projektu, cíle komunikace, zainteresované strany, klíčová sdělení, komunikační nástroje, rozpočet, harmonogram, rizika spojená s komunikací a vyhodnocení. c)
Požadavky a cíle projektu vychází z potřeb zákazníků, které jsou zase směrovány
příleţitostmi a riziky. Rozvíjí se obchodní případ (tzv. business case) a strategie projektu. Strategie se reviduje jednak v různých časových intervalech a jednak v určitých specifických oblastech. Strategie projektu by měla představovat pohled z vyšší úrovně na to, jakým způsobem můţeme dosáhnout záměrů projektu. Specifický a měřitelný cíl projektu je tvořen souborem cílových podmínek a parametrů, které manaţeři projektu, programu nebo portfolia musí dosáhnout proto, aby zainteresovaným stranám poskytli očekávané přínosy. Úvodní (přípravná) fáze projektu zahrnuje vytvoření plánů projektu a vyhotovení studie proveditelnosti. Nezbytným předpokladem v úvodní fázi projektu totiţ je, abychom měli zajištěnou dostatečnou podporu pro rozhodnutí projekt skutečně vykonat. Jakmile je investice do projektu schválena, musí vlastník projektu vytvořit identifikační listinu projektu, která vymezuje rozsah projektu, jeho cíle a jeho výstupy, rozpočet, časový rámec, kontrolní body a členství v týmu projektu. Moţnými procesními kroky je shromáţdění a zdokumentování poţadavků projektu, vytvoření obchodního případu k potenciálnímu projektu, definování cílů, komunikace se všemi zainteresovanými stranami, validace poţadavků v kaţdém klíčovém bodě ţivotního cyklu projektu, určení, nakolik vytvořená strategie, studie a plány souhlasí s původními cíli, zahájení procesu kontinuálních revizí a dokumentace získaných poznatků. d)
Řízení rizik a příležitostí je neustálý proces, který se odehrává ve všech fázích
ţivotního cyklu projektu. V této části standard představuje základní principy analýzy rizik a jejich aplikace do řízení projektu. Dále popisuje základní metody analýzy rizik pro pouţití v projektech. Často pouţívaná metoda sniţující neurčitost provázející kaţdé jednotlivé riziko je zaloţena na tzv. principu postupnosti, tj. sníţení neurčitosti odhadu tím, ţe odhadovanou poloţku rozloţíme na menší části. Stejnou metodu lze pouţít pro odhady délky trvání činností, které určují časový harmonogram projektu. Procení kroky vyuţitelné pro tuto část jsou identifikace a provedení odhadu rizik a příleţitostí, vytvoření plánu odezvy na rizika a 16
příleţitosti, aktualizace všech projektových plánů, na které má plán odezvy vliv, vyhodnocení pravděpodobnosti dosaţení časových a nákladových cílů, neustálá identifikace nových rizik, řízení a kontrola odezvy na rizika a příleţitosti a dokumentace získaných poznatků. e)
Management kvality projektu prostupuje všechny fáze a součásti projektu. V této části
se standard zaměřuje na základní přístupy, techniky a metody pro řízení kvality projektu. Zamýšlená funkce produktu musí být v průběhu projektu průběţně validována. Aby byla zajištěna shoda s poţadavky na produkt, účastní se obvykle těchto validačních kroků zákazník nebo uţivatel produktu. Validace kvality projektu se provádí pomocí postupů jako jsou Quality Assurance, Quality Kontrol a audity projektu a produktu. Je-li to vhodné, pouţívají se pro validaci a pro přizpůsobení návrhu produktu projektovým poţadavkům různé CAD systémy, modely v patřičném měřítku nebo prototypy. Procení kroky pro tuto oblast jsou vytvoření plánu kvality, výběr a testování prototypů, verzí a dokumentací, získání schválení pro konečnou verzi, provedení procesů Quality Assurance a Quality Kontrol, testování a dokumentace, pouţívání korekčních opatření a dokumentace získaných poznatků. f)
Organizace projektu nebo programu je jedinečnou a dočasnou organizací, která je
podle standardu neustále přizpůsobována fázím a podmínkám ţivotního cyklu projektu. Většinou je součástí liniově-štábního uspořádání. Tento element uvádí informace o organizaci projektu a projektového týmu. Zmiňuje základní informace o vztahu k trvalé organizaci. Doporučenými procesními kroky jsou určení typu organizace projektu, identifikace všech organizačních jednotek, které pro projekt poskytují zdroje, definice rolí, odpovědností, pravomocí, získání zdrojů, definice komunikačního rozhraní, komunikace rozhodnutí, udrţování a aktualizace organizace projektu, vyhledávání moţností vylepšení organizace projektu a dokumentace získaných poznatků. g)
Element kompetence týmová práce zahrnuje řízení a vedení při vytváření týmu,
fungování v týmech a skupinovou dynamiku. Standard popisuje budování projektového týmu například pomocí projektových schůzí, workshopů a seminářů. Vývoj týmu se řídí definovaným procesem, který lze popsat například fázemi formování, konfliktů a polarizací, normování a výkonu. V případě, ţe výkon určitého člena týmu nedosahuje poţadovaného standardu, je třeba přikročit k nápravnému opatření.
17
h)
Řešení problémů je dalším elementem. Je zde představen systematický přístup k řešení
problémů a jeho aplikace v řízení projektů, včetně některých praktických metod. K řešení problémů lze pouţít různé metody. Můţe to být například zavedení systematických postupů, podpora tvorby nápadů a alternativ řešení problémů, hodnocení nápadů a výběru nejlepších moţností. Existuje také skupina speciálních problémů, které se mohou ojediněle vyskytnout v určitém projektu, jako zcela nový a nikdy neřešený problém. V takovém případě je potřeba pouţít k řešení problémů kreativní přístup. i)
Struktury projektu jsou klíčovým mechanismem, který v rámci projektu zajišťuje řád.
Hierarchické struktury zajišťují, aby se v projektu nic neopomenulo. V této kapitole standardu jsou popsány informace o strukturalizaci projektu, především hierarchické struktuře prací (WBS – work breakdown structure). j)
Rozsah projektu definuje hranice projektu. Kapitola obsahuje informace o potřebě
vymezení hranic projektu, jehoţ součástí je i přesné vymezení dodávaných výstupů projektu. Z pohledu zainteresovaných stran zahrnuje rozsah projektu úplně všechny výstupy projektu. Řešení projektu se v rámci rozsahu projektu postupně vyvíjí od počáteční koncepce projektu aţ k výsledné, a tento vývoj je zachycen v dokumentech, které definují výstupy projektu ve větším a větším detailu tak, jak se postupně prohlubuje poznání v průběhu projektu. Dobře definovaný rozsah – hranice projektu – a kvalitně identifikovaná a řízená konfigurace výstupů projektu jsou nezbytným předpokladem úspěchu, zejména u komplikovanějších projektů. Rovněţ správné vymezení hranic ušetří v průběhu realizace projektu mnoho zbytečných nekonstruktivních konfliktů. k)
Čas a fáze projektu zahrnuje strukturalizace, řazení, trvání, odhady a časové rozvrţení
činností nebo pracovních balíků, a to včetně přiřazování zdrojů činnostem, stanovování koncových termínů, monitoringu a controllingu jejich vykonání ve stanoveném čase. V tomto elementu jsou tedy popsány základní přístupy k pojetí a řízení času v projektech. Jsou zde uvedeny základní metody pro plánování projektu a jsou naznačeny vztahy s plánováním zdrojů. Cílem časového plánování je určit, které činnosti je třeba vykonávat a kdy, a tyto činnosti seřadit na časovou osu do logické posloupnosti. l)
Zdroje zahrnují personál v rámci projektu, stejně jako zařízení, materiál a vybavení
potřebné pro provádění činností, prací nebo projektu. Plánování zdrojů zahrnuje definování 18
poţadovaných zdrojů a optimalizované plánování s ohledem na veškeré dostupné a dosaţitelné zdroje. Pro účely kvalifikovaného posouzení zdrojů poţadovaných pro projekt uvádí standard analytický odhad, konzultace s odborníky a kalkulační schémata. m)
Plánování nákladů navazuje na časové plánování projektu. Rozpočet projektu chápe
standard jako celkový objem prostředků přidělených na projekt, obvykle rozdělený do výdajových kategorií a rozfázovaný v čase. Náklady projektu obvykle dělíme na přímé a nepřímé. Pro plánování nákladů a sestavení rozpočtu projektu můţeme vyuţít různé metody a postupy, které projektové řízení převzalo z ekonomických oborů. Kaţdý rozpočet projektu by měl obsahoat rezervy pro krytí zvýšených nebo nepředvídaných výdajů. n)
Sekce obstarávání a smluvní vztahy definuje základní parametry dodavatelských
smluv. Je-li potřeba získat do projektu určité vstupy, uplatní se kompetence v obstarávání. Při nákupu od externího subjektu je třeba věnovat velkou pozornost výběru dodavatele, stanovit jasně specifikaci poţadavků a kritéria výběru dodavatele. Smlouvy definované ve standardu jsou
kupní
smlouva,
smlouva
o
dílo,
mandátní
smlouva,
příkazní
smlouva,
zprostředkovatelská smlouva a smlouva o smlouvě budoucí. o)
Změny se vyskytují v kaţdém projektu, mohou být důsledkem poţadavků zákazníka,
změn legislativních předpisů, nedostupnosti zdrojů atd. Podle standardu musí účinné řízení změn vycházet z účinného mechanismu změn projektu, který můţeme rozdělit na shromaţďování podnětů ke změnám, změnové poţadavky, hodnocení změnových poţadavků a povolování změn, provádění změn a dohled nad prováděním a evidence a dokumentace změn. Standard také rozlišuje tři třídy změn podle jejich vlivu – významné, podstatné a méně podstatné.
p)
Obsahem elementu kontrola, řízení a podávání zpráv jsou informace se vztahem
k vykazování stavu projektu a jeho průběţného vyhodnocování. Jsou popsány hlavní metody sledování projektu. q)
Informace a dokumentace jsou elementem, kde jsou uvedeny základní pojmy řízení
informací a dokumentace. Specifická pozornost je věnována IT technologiím pro zpracování informací a tok dokumentů.
19
r)
Komunikace je uţívána k vytvoření dobrých předpokladů pro motivaci, prácí a
rozhodování. Komunikační dovednosti jsou obvykle chápány a vysvětlovány jako umění jednat s lidmi. s)
Iniciace, resp. zahájení projektu je procesem, jehoţ účelem je rozběhnout projekt nebo
program. Bývá zahájen schválením zakládací listiny projektu. Podstata zahájení je v tom, ţe během velmi krátkého času jsou vytvořeny nezbytné interpersonální vztahy v přípravném projektovém týmu. t)
Obsah elementu ukončení informuje o procesu ukončení projektu nebo jeho fází.
Uvádí tento proces do souvislosti napříč ţivotním cyklem projektu.
3.4.2 Elementy behaviorálních kompetencí a)
Vůdcovství samo o sobě negarantuje úspěch. Jeho absence je však tou nejčastější
příčinou neúspěchu projektů. Bez dobrého vedení nelze očekávat, ţe projekty povedou k excelentním a udrţitelným výsledkům. Standard popisuje základní skutečnosti týkající se vůdcovství.
b)
Z národního standardu kompetencí projektového řízení podle IPMA je zhruba patrné,
co je účelem zainteresovanosti a motivace a co pro jeho naplnění dělat – motivovat tým a jednotlivce. c)
Sebekontrola je důleţitou kompetencí všech členů týmu v případě, je-li pro organizaci
důleţitý dlouhodobý, trvale udrţitelný nebo dokonce rostoucí výkon projektového týmu. Za tuto kompetenci a její praktické uplatnění odpovídá projektový manaţer.
d)
Uvolnění je schopnost zmírnit napětí v obtíţných situacích. Obsahem tohoto elementu
je rozbor druhů stresu, jejich stádií, stresových faktorů i způsob zvládnutí stresu, způsobů boje proti stresu a druhů relaxačních technik. e)
Národní standard kompetencí projektového řízení definuje otevřenost jako schopnost
přimět ostatní, aby cítili, ţe jejich vyjádření se k věci je vítáno. Pod otevřeností lze také
20
rozumět nadprahovou míru informovanosti členů týmu nebo nadprahovou dostupnost projektového manaţera individuálním potřebám členů týmu. f)
V elementu kreativita jsou popsány techniky, které slouţí k řízení týmové spolupráce.
Existuje několik desítek technik, standard popisuje například brainstorming, brainwritting, myšlenkové mapy nebo Crawfor slip. g)
Element orientace na výsledky se zaměřuje zejména na tzv. měkké aspekty výsledků.
Jsou zde popsány významy výsledků, hierarchie priorit nebo měření výsledků. h)
Výkonnost je základní komponentou řízení projektů s cílem zajištění efektivního
vyuţití všech zdrojů dostupných pro projekt. i)
Kompetence diskuze představuje schopnost logicky argumentovat, uvádět pádné
argumenty, naslouchat názorům ostatních a vnímat jejich pohledy na věc, vyjednávat a nacházet společná řešení. j)
Kompetence vyjednávání jsou popsány prostřednictvím způsobů a taktik. Kromě toho
standard popisuje i základní faktory vyjednávání. k)
Standard se zabývá popisem moţných konfliktů a variant jejich řešení, včetně
doporučení pro praxi. Mnoho souvisejících informací je uvedeno v elementech vůdcovství, kreativita a diskuze. l)
V elementu spolehlivost se standard zabývá teorií spolehlivosti, spolehlivostí
manaţera, charakterovými vlastnostmi, důvěrou a morálkou. m)
Porozumění hodnotám je element, který se zabývá definicí pojmu hodnoty a dálek pak
moţnou prací s hodnotami a vyuţitím hodnot v praxi projektového týmu. n)
Pomocí elementu etika získávají v současné době firmy komparativní výhodu na trhu.
IPMA definuje etiku jako řízení projektů, během něhoţ si projektoví manaţeři jsou vědomi důsledků svých činů a jsou za ně zodpovědní.
21
3.4.3 Elementy kontextových kompetencí a)
Orientace na projekt se zabývá definováním projektu a projektovým řízením.
Zdůrazňuje zásadní odlišnosti od obvyklého liniového způsobu řízení.
b)
Kapitola orientace na program obsahuje informace o programech a programovém
řízení a klade si za cíl především vysvětlit pojmy v kontextu s ostatními úzce souvisejícími tématy. c)
Orientace na portfolio vysvětluje pojem portfolio, jeho smysl ve vztahu k organizaci a
otázky spojené s potřebou portfolia a jeho řízením. d)
Implementace projektu, programu a portfolia vysvětluje informace o zavádění –
implementaci řízení PPP do organizace. Jsou zde popsány důvody k takové aktivitě a hlavní zásady pro její realizaci. e)
Dalším elementem je trvalá organizace, který obsahuje informace o trvalé organizaci
a jejím vztahu s dočasnými organizačními strukturami – projekty. Element popisuje mimo jiné koncept řízení trvalé organizace, modely organizačních struktur a projektovou kancelář. f)
Poţadavek realizovat projekt nebo program vzniká vţdy v byznysu. Z tohoto důvodu
je značná část řídících procesů projektu svázána se způsoby, jak subjekt, který je nositelem tohoto byznysu, funguje. Tento element obsahuje základní informace o pojmu byznys a jeho moţném chápání ve vztahu k trvalé organizaci a k PPP. g)
Systémový úhel pohledu a systémové myšlení obecně je jedním z nejzákladnějších
principů celého standardu IPMA. Proto jsou informace uvedené v tomto elementu v úzké vazbě na všechny ostatní elementy a především elementy kontextových kompetencí, které uvádí vzájemné vztahy mezi systémy projektů, programů, portfolií, trvalé organizace a dalšími, většími systémy.
22
h)
Předmětem elementu personální management jsou společné, obecně platné prvky.
Popisuje účel personálního managementu, výběr pracovníků a jejich rozvoj, hodnocení pracovníků a globální trendy v personálním managementu. i)
Element finance pokrývá finanční kontext, v jehoţ rámci organizace funguje. Standard
vychází z obecných principů financování soukromých projektů a představuje úvod do dané problematiky. j)
Posledním elementem je právo. Popisuje vliv práva a předpisů či směrnic na projekty
či programy.Vzhledem k rozsahu a vazbám na celou řadu elementů se standard zabývá pojmy jako právní vědomí, právo na pracovišti a právní kontext projektu
3.5
Ostatní metodiky
3.5.1 Agilní metodiky Mezi ostatní metodiky můţeme zařadit agilní metodiky, které se vztahují k agilnímu softwarovému vývoji. Typickým pro ně je iterativní průběh práce a pravidelné dodávky částí softwaru po krátkých iteracích. Mezi nejpouţívanější agilní metodiky patří extrémní programování, scrum, Feature Driven Development, Atole Unified Process.
3.5.2 RUP Metodika RUP je metodika agilního vývoje softwaru, která se zaměřuje na produktivitu týmu a poskytuje nejlepší softwarové postupy všem jeho členům. Podle některých názorů RUP spojuje standardní management a odborné metody a techniky s cílem zajistit procesy systémového inţenýrství konkrétně přizpůsobené tvorbě a údrţbě softwarových systémů zaloţených na komponentách.
3.5.3 Six Sigma Některé organizace realizují projekty za pomocí metodiky Six Sigma, která vznikla za výrazného přispění odborníků zabývajících se kvalitou projektů. Mezi hlavní metodiky patří DMAIC (devone, measure, analyze, improve, control), která se pouţívá ke zlepšení existujících obchodních procesů, a DMADV (devone, measure, analyze, design, verify) slouţící k výrobě nových produktů a zpracování návrhů procesů vedoucích k předvídatelným a bezchybným výkonům.
23
4.
World Wide Project Management Metodology
4.1
Co je to WWPMM
World Wide Project Management Metodology (WWPMM) je metodika projektového řízení společnosti IBM, o které se poprvé začalo mluvit v roce 1996. WWPMM je výsledkem rozhodnutí řídit společnost IBM jako projektově orientovanou. Vzhledem k existenci mnoha metodik vznikla v IBM potřeba tyto metodiky integrovat do jednoho rámce, který bude zohledňovat potřeby a cíle společnosti a zároveň nastaví stejný rámec pro všechny pobočky po celém světě. Všechny zainteresované strany se tak řídí stejnými pravidly, která je moţné najít na jednom místě a která budou reflektovat poţadavky jednotlivých projektů. Metodika tak vznikla spojením existujících standardů, metodik a nejlepších praktik. Nejvíce čerpá WWPMM ze standardu PMBOK, coţ je patrné z řady převzatých definic a pojmů. IBM pak tuto metodiku doplňuje na základě vlastních zkušeností. Jako příklad je moţné uvést definici programu, kterou PMBOK popisuje jako skupinu projektů řízených koordinovaných způsobem tak, aby bylo dosaţeno přínosů, které by nebyly dosaţeny při individuálním řízení projektů. Samotná organizace PMI konstatovala, ţe tato definice není pro dnešní organizace dostačující. Z tohoto důvodu se IBM rozhodla tuto definici doplnit dalšími charakteristikami, která činí definici vhodnější pro účely IBM. Rozšíření říká, ţe program je kromě předchozího, dlouhodobá snaha o zavedení strategie nebo poslání plnit obchodní cíle nebo organizační cíle, program je realizován prostřednictvím různých projektů a probíhajících aktivit, rozsah programu můţe být definován obecně a rozvíjen v průběhu času podle toho, jak organizace rozvíjí svou programovou strategii nebo vizi, v některých případech můţe být rozsah programu specificky definován na začátku k dosaţení a odsouhlasení souboru cílů. Pro úspěšnou implementaci programů v prostředí WWPMM, musela IBM přijmout takovou správu přístupu, která vyuţívá základní procesy a struktury, které se pouţívají pro řízení projektů a rozšiřuje je do komplexnějšího prostředí. Z pohledu IBM se jedná o aplikaci holistického přístupu projektového řízení, obchodu a znalosti vztahů se zákazníkem, dovedností, znalostí a technik tak, aby bylo dosaţeno cílů programu.
24
ISO 10006, ....
PMI
IPD / ISD IBM MITP
IEEE/ACM
IBM PMM Symeris (France) Software Engineering Institute
ADC (Japan) Bird (CGI) Euromethod Others
Obrázek 2 – Přehled pouţitých metodik a standardů
Seven Keys to Success™ (PWCC)
WWPMM je postavena na třech souvisejících hlavních komponentách – pracovní vzory (Work Patterns), domény (Domains) a nástroje (Work Products). Pracovní vzory popisují řadu kroků, které reagují na určité typické situace nebo události projektového managementu. Domény zahrnují oblasti znalostí, jako je řízení rizik nebo sledování cíle. Konečně nástroje popisují oblasti jako jsou plány, harmonogramy, záznamy, atd., které projektový manaţer pouţívá k řízení projektů.
Obrázek 2 – 13 domén WWPMM, jejich názvy a zkratky
25
Domény obsahují 13 oblastí znalostního managementu, které sdruţují 150 procesů rozdělených do skupin. Sada procesů vţdy pokrývá stejnou oblast znalostí. Kaţdá z domén je identifikována jménem a zkratkou (např. Change Management – ChM, CoM – Communications Management). Domény jsou organizovány do samostatných „knih“, které obsahují detailní návody co zvaţovat nebo co dělat s mnoţstvím poloţek v rámci domény. Tyto poloţky se označují jako procesy. WWPM domény jsou srovnatelné se znalostními oblastmi PMBoK, nicméně WWPMM je mnohem komplexnější a zaměřuje se na oblasti obchodu, kterými se IBM zabývá.
Obrázek 4 – Procesy v rámci domény Quality Management
Pracovní nástroje jsou úzce spojeny s procesy. Shromaţďují informace, které projektový manaţer pouţívá, vytváří nebo aktualizuje při provádění procesů. Jako příklad takových nástrojů je moţné uvést definování projektu, plán řízení rizik, atd. Tyto nástroje je moţné nalézt stejně jako předešlé domény na jednom centrálním místě zřízeném pro účely hromadného sdílení. Nejedná se o kompletní výčet nástrojů, které projektový manaţer můţe pouţívat na konkrétních projektech. Některé nástroje jsou rozděleny do technických metod, politik a obchodních procesů, které se vztahují k projektu. WWPMM popisuje pouze takové nástroje, které se váţí k základní práci projektového manaţera. Přesný počet popsaných nástrojů se liší podle aktualizace WWPMM, nicméně jako přibliţné číslo je moţné uvést padesát. Pro pochopení pracovních modelů je dobré si představit pracovní ţivot projektového manaţera, který musí řešit několik problémů současně. Modelová situace – před několika týdny vyvstal problém, který stále čeká, ale potřebuje být nutně vyřešen, dodávka proběhla včas, kvalita se zdá dobrá, ale projektový manaţer je zneklidněn, protoţe akceptační proces ze strany sponzora projektu neprobíhá podle představ. Dodavatel musí začít s další navazující 26
dodávkou během tří týdnů a projektový manaţer potřebuje nastavit harmonogram tak, aby hned na začátku nedošlo k časově prodlevě. Pro kaţdou z takových situací WWPMM popisuje standardní reakci, kterou by měl projektový manaţer zváţit pro vyřešení problémů. Na pracovní modely můţeme nahlíţet jako na soubor činností ovládaných paralelně, ale které spolu obvykle nemusí souviset. I pro pracovní modely existuje jednotné úloţiště, kde je moţné všechny nalézt. Je zde popsáno čtyřicet pracovních modelů. Opět je třeba zdůraznit, ţe zde nejsou popsány všechny moţné situace a všechny moţné reakce. Lze zde úspěšně praktikovat Paretovo pravidlo – 20% typických situací/reakcí umoţňuje identifikovat 80% procesů uvedených v doménách. Modely jsou uspořádány do několika skupin, které se vztahují k obecně přijímaným skupinám činností projektového managementu a které definují – co by mělo být dodáno, plány, rozpočty proti kterým budou sledovány pokroky, řízení dodávek, analýzy získaných poznatků, uzavření.
4.2
Koncept
WWPM definuje způsoby, kterými jsou řízeny projekty v rámci společnosti IBM. Metody, které pomáhají vytvářet WWPM jsou zaloţeny na dlouholetých zkušenostech, získaných z mnoha různých typů projektů v různých regionech. Metodika je sponzorována Project Management Center of Excellence, aby podporovala
směrnici Corporate Executive
Committee, navrhovala a zaváděla jednotný a společný postup pro řízení projektů a programů IBM po celém světě. Uvnitř IBM definuje politika pro řízení projektů minimální soubor pravidel, které musí být implementovány u kaţdého projektu. Kaţdá část IBM můţe do této politiky přispívat. V rámci interních pravidel je odpovědností projektového manaţera přizpůsobit metody projektového řízení tak, aby vyhovovaly kaţdému konkrétnímu projektu. Cílovou skupinou pro WWPMM jsou osoby, jejichţ hlavním úkolem je řízení projektů a jednotlivci s jinými rolemi, například personální manaţer, technický architekt, kteří plní úkoly řízení projektů Řízení projektů vyţaduje celou řadu dovedností a znalostí. To také vyţaduje, aby projektový manaţer aplikoval řadu pravidel, procedur a technik, které jsou obvykle definovány konkrétními kompetencemi, oblastí obchodu a/nebo geografií. Ty jsou popsány v různých business procesech, politikách a procedurách (například vývoj aplikací nebo metody vývoje výrobku). WWPMM nepopisuje tento úplný a variabilní soubor dovedností, ale soustředí se na to, co je povaţováno za hlavní práci projektového manaţera, to znamená na obecné 27
znalosti a profesi projektového manaţera. Na druhou stranu, všechny činnosti popsané v metodice jsou obecně více neţ je obecně třeba pro řízení konkrétních projektů v daném kontextu.
4.3
Organizace
Projekty mohou být rozděleny do dílčích projektů, protoţe tento způsob umoţňuje jednodušší řízení a jasněji se definují odpovědnosti. Tyto sub-projekty by měly být definovány tak, ţe v maximální moţné míře budou kompletní a na sobě nezávislé. Projekty a sub-projekty jsou přiřazeny organizačním jednotkám, které jsou uspořádány hierarchicky a oznamovací vztahy mezi nimi jsou popsány v organizační struktuře členění. Projektová organizační jednotka můţe mít jednu ze tří rolí – provedení části projektu, řízení prací jedné nebo více organizačních jednotek nebo provádět část projektu a řídit jednu nebo více projektových organizačních jednotek. Kaţdá projektová organizační jednotka je tvořena projektovým týmem a lidmi, potřebnými pro výkon práce určené organizační jednotce.
4.4
Procesy a postupy
Procesy projektového managementu jsou navrţeny tak, aby zajistily, ţe kaţdý projekt je zaloţen na kvalitním obchodním zpracování, rozsah a cíle jsou srozumitelné a zdokumentované před tím neţ jsou vypracovány podrobné plány, komplexní Project Management Systém je vymezen a implementován před tím, neţ je vynakládáno úsilí na daném projektu a potřebná schválení jsou udělována v klíčových kontrolních bodech projektu. Projektové aktivity jsou rozděleny do čtyř skupin – definování, plánování, provádění a uzavírání. Ve fázi definování jsou dohodnuty cíle projektu, rozsah a struktura projektu, výchozí organizace, přidělení odpovědností a úvodní vyhodnocení rizik. Během plánování jsou vytvořeny detaily prací a plány rizik. Při provádění jsou plány a kontroly pouţívány ke spuštění a řízení projektu a dochází k provádění prací.
V průběhu uzavírání dochází
k ukončení jednotlivých aktivit, je dosaţeno dohody se sponzorem projektu a je vytvořena hodnotící zpráva, tzv. Project Evaluation Report. Ačkoliv jsou tyto činnosti v metodice popsány jako sekvenční, ve většině projektů bude určitá míra jejich opakování a jednotlivé činnosti se budou překrývat.
28
4.5
Řízení projektů v IBM ČR
Společnost IBM je procesně řízenou organizací z čehoţ vyplývá důraz kladený na dodrţování stanovených postupů. Ve chvíli, kdy je identifikován projekt, dochází k sestavení zkušeného týmu. Vedením týmu je pověřen projektový manaţer, od kterého se vyţadují zkušenosti s obdobnými projekty, například z hlediska pouţitých technologií nebo rozsahu projektu. Během diskuzí s projektovými manaţery jsem zjistil, ţe není moţné, aby se nezkušený pracovník stal projektovým manaţerem na velkých projektech. Obvykle je třeba projít různými niţšími pozicemi, seznámit se s metodikami a procesy například v rámci projektové kanceláře. Ve chvíli, kdy je určen projektový manaţer, je jeho první odpovědností identifikovat potřebné interní zdroje, které budou na projektu participovat a tyto zdroje si zajistit. Co povaţuji za velmi přínosné je vytvoření projektových týmů na úrovni regionů pro projekty jako je například outsourcing celých IT oddělení, rozsáhlé systémové integrace a další. Tento způsob organizaci umoţňuje reagovat na specifické poţadavky v jednotlivých zemích, kde nejsou dostatečné zdroje. Zároveň je tak moţné vyuţívat zkušeností a know-how z předchozích projektů a je tak moţné pozorovat, ţe projekty jsou řešeny velmi podobným způsobem. Opět tento přístup odpovídá holistickému pojetí řízení společnosti. Dalším krokem je analýza realizovatelnosti a příprava řešení. Před tím, neţ je investováno do samotného řešení je zadání projektu podrobeno detailnímu rozboru. Cílem je zjistit, zda projekt odpovídá strategii organizace a její orientaci, můţe pomoci organizaci v dalším růstu a rozvoji, jaká jsou moţná rizika ať uţ finanční či časová. Jednotlivé kroky jsou průběţně komunikovány v rámci pravidelných tzv. řídících výborů. Během těchto jednání je řešení zkoumáno z hlediska rizik, úplnosti, správné posloupnosti kroků řešení, nákladů atd. Pokud není projekt, resp. řešení schváleno řídícím výborem není moţné projekt realizovat. Jestliţe řešení splňuje technické poţadavky, je zde ještě finanční stránka celého projektu. Pro tyto účely společnost IBM vyuţívá interní systém, ve kterém projektový manaţer definuje veškeré interní a externí zdroje, které plánuje vyuţívat. Pro interní zdroje jsou zde jiţ nastaveny sazby jednotlivých rolí, v případě externích zdrojů je třeba uvést náklady odhadované na spolupráci s třetími stranami. Celý systém obsahuje sloţité algoritmy, které jsou schopny na základě vloţených dat dopočítat potřebné finanční ukazatele, zejména ziskovost projektu a návratnost investic. V této souvislosti jsou nastaveny minimální poţadavky na realizaci projektu. Pokud výsledek nedosahuje těchto limitů, je projekt zastaven nebo je schválení projektu řešeno ve zvláštním módu, kde je nutné obhájit přínosy takového projektu.
29
Samotný průběh projektu probíhá podle kroků, které jsou shodné s ostatními běţně uznávanými metodikami, zejména s dříve zmíněnou PMBOK. Vývoj projektu je kontrolován na základě předem stanovených milníků a kritérií. Kaţdý projekt je na konci vyhodnocen a úspěšné projekty jsou vyuţívány a prezentovány v rámci organizace jako tzv. best practise. I přes všechna opatření, procesy a postupy není zaručen úspěch projektu, neboť vše je stále ovlivňováno a řízeno lidských faktorem.
6.
Asijský model projektového řízení
V následující části se pokusím popsat přístup k projektovému řízení v asijské, resp. čínské společnosti. Tento přístup se od výše popsaného anglosaského modelu, reprezentovaného metodikami IBM, PMI či PRINCE, liší velmi podstatným způsobem. Tyto odlišnosti je na jedné straně moţné pochopit, asijská mentalita, přístup k obchodu, kultura, atd. je výrazně odlišná od evropské či americké. Na druhou stranu asijské firmy stále více a více pronikají na evropské trhy a z tohoto důvodu bychom očekávali, ţe se přizpůsobí „lokálním“ podmínkám, zvykům a kultuře. Ke škodě některých firem se tak neděje a tyto firmy zde existují jen jakousi setrvačností. Nikoliv díky inovacím a rozvoji. Určitě je také důleţité rozlišovat přistup například japonských a čínských společností. Jestliţe obzvláště japonské firmy jsou známé zaváděním nových technologií, novými přístupy ve výrobě, logistice a dalších oblastech, pak čínské firmy se více soustředí na pouhé přebírání úspěšných postupů, případně jejich částí. Pokud bychom se podrobněji zaměřili na čínské firmy, narazili bychom na několik zdánlivě nepodstatných problémů, které mají ale výrazný vliv na řízení projektů, rizik a koordinaci jednotlivých činností. Jedná se zejména o nastavení vzájemně spolupracujících procesů včetně potřebných IT systémů, sestavování projektových týmů, jejich znalosti a zkušenosti. Popisovanou čínskou firmou je jedna z největších firem poskytujících řešení v oblasti telekomunikací, která byla zaloţena v roce 1989. Mezi odborníky z oblasti IT a telekomunikací je často povaţována za státní firmu coţ, jak bude moţné vidět dále, má významný vliv na řízení nejen projektů. Společnost Standish Group provedla v roce 2001 studii, ve které uvádí pořadí faktorů dle důleţitosti, které jsou z hlediska dosaţení úspěchu informačních projektů nejpřínosnější. 30
Nejdůleţitějším faktorem byla vyhodnocena podpora vedení. Dalšími faktory byly zapojení uţivatelů, zkušený projektový manaţer, jasné obchodní cíle, minimalizovaný rozsah, standardizovaná softwarová infrastruktura, stálé základní poţadavky, formální metodika, spolehlivé odhady a ostatní kritéria jako například milníky, řádné plánování atd.
6.1
Projektové řízení
Jak jiţ bylo zmíněno, čínské firmy, jejichţ přístup je zde popisován, nepouţívají ověřené a kompletní metodiky řízení projektů. Co je toho příčinou? Důvodů bychom jistě našli několik. Mezi ty nejvýraznější patří „věk“ firem a vlastnická struktura. Čínské firmy ještě nedávno nepatřili k významným hráčům, ale dynamický rozvoj v posledních 10 letech je aţ neuvěřitelný. Tyto subjekty se tak stále učí a vyvíjí. Na rozdíl od IBM, Hewlett-Packard a dalších, které za sebou mají desítky let rozvoje a zlepšování. Druhou stranou mince však je, ţe o to více by měly být motivovány vyuţívat metodiky a postupy vyzkoušené těmito projektovými matadory a prověřené tisícovkami projektů. Naproti tomu se snaţí vyuţívat jen malé útrţkovité části těchto procesů bez potřebné návaznosti. V projektovém řízení tak vznikají mezery, které se projevují v jeho kvalitě. Tomuto projektovému řízení není těţké porozumět. Co však těţké je, je jeho implementace v různých typech prostředí. Projektový manaţeři musí při řízení projektů zvaţovat celou řadu otázek. Stejně, jako je jedinečný kaţdý projekt, je jedinečné i jeho prostředí. Pokud projektový manaţeři realizují projekty bez ohledu na prostředí, jen těţko budou jejich výsledky potřebám organizace. Proto musí projekty reflektovat širší prostředí organizace a projektový manaţeři zvaţovat celkový kontext, v němţ projekty vznikají. Tyto organizace velmi málo vyuţívají holistický pohled, který vyjadřuje, jak projekty v kontextu organizace realizovat. Vyuţívání systémového přístupu je pro úspěch projektového řízení klíčové. Aby pochopili, jak projekty souvisí s celou organizací, musí top management a projektový manaţeři systémové myšlení přijmout. Systémová analýza a problémy řešící přístup jsou pak nezbytné pro identifikaci potřeb. Top management a projektoví manaţeři musí při pojmenovávání klíčových obchodních, technologických a organizačních otázek vztahujících se ke kaţdému projektu vyuţívat systémové řízení. Jen tak mohou identifikovat a uspokojit zainteresované strany a dělat to, co je pro celou organizaci nejlepší. Ačkoli je jednodušší zaměřit se na okamţité a někdy zúţené zájmy konkrétního projektu, projektový manaţeři a
31
ostatní pracovníci by měli mít neustále na mysli dopady jakéhokoli projektu na zájmy a potřeby celého systému či organizace. Systémový přístup vyţaduje, aby projektoví manaţeři vţdy projekt vnímali v kontextu celé organizace. Organizační otázky jsou při řízení a realizaci projektů často tou nejsloţitější záleţitostí. Projektový manaţeři často nevěnují dostatek času identifikaci zainteresovaných stran projektu, a to zvlášť těch, které jsou vůči němu v opozici. Projektový manaţeři se rovněţ často dostatečně nevěnují úvahám o politickém kontextu projektu či podnikové kultuře. Aby zvýšili úspěšnost svých projektů, měli by se projektový manaţeři snaţit lépe pochopit lidi a organizace. Schopnost řídit projekty ovlivňuje i kultura organizace. Organizační kulturou rozumíme sdílené předpoklady, hodnoty a typy chování, které jsou pro fungování organizace charakteristické. Organizační kultura je velmi mocná a v případě čínských firem je skrytou příčinnou velkého mnoţství problémů. Tento organizační přístup postrádá identifikaci zaměstnanců se společností, realizaci pracovních činností skupinami, kde existuje silné propojení oddělení, odměňování na základě výkonu, systém otevřený změnám a orientaci na účel. Dalším problémem je nedostatek standardů a pravidel, jejichţ implementace by pomohla zlepšit projektové řízení. Jako i jiné části projektového řízení i tato musí být aktivně prosazována top managementem, který si musí vynutit jejich aplikování. Stávající praxe ukazuje, ţe kaţdá ze zemí, kde popisovaná organizace působí, pouţívá odlišný přístup a i v rámci jedné země je moţné pozorovat rozdílné zpracování projektů.
6.2
Výběr projektů
Prvním krokem projektového řízení by mělo být rozhodnutí, které projekty chceme realizovat. Jak jiţ bylo zmíněno, popisovaná firma nemá jasně stanovenu projektovou strategii. Donedávna se firma soustředila pouze na oblast telekomunikací, kde dosahovala velmi dobrých výsledků. Je však nutné podotknout, ţe se tak ve velké části projektů stalo pomocí nízkých cen, někdy hraničících s dumpingovými. Firma se však dopustila velmi závaţného prohřešku. Uspokojila se s výsledky v oblasti výstavby telekomunikačních sítí a ačkoliv je jiţ delší dobu producentem dalších produktů a
32
sluţeb (síťových prvků, řešení pro datová centra, mobilních telefonů, cloud computing) nezabývala se propagací těchto produktů a sluţeb. Skutečnost byla taková, ţe tuto firmu znala jen hrstka odborníků pohybujících se v telekomunikacích a IT. Začátkem roku 2011 se firma rozhodla proniknout i do oblasti IT. Nepříjemný překvapením byl neúspěch. Ten se musel zákonitě dostavit vzhledem k tomu, ţe od roku 2001, kdy firma vstoupila na evropský trh, neinvestovala ţádné prostředky do propagace svých sluţeb a produktů. Aby teď firma dokázala dohnat tuto ztrátu, rozhodla se ze dne na den získávat i projekty, se kterými nemá dosud ţádné zkušenosti a nedisponuje ani vyškoleným personálem (výstavba datových center na klíč, outsourcing správy telekomunikačních sítí, datové sály). To vede pouze k jedné věci a tou je agresivní cenová politika, kdy cílem je splnit stanovený cíl obratu bez ohledu na dosaţený zisk. Dobrým příkladem takového projektu je outsourcing technického oddělení telefonního operátora, které zajišťuje kompletní údrţbu sítě. Na počátku se skutečně projekt mohl zdát zajímavým a za jistých okolností jako strategický pro vstup do této oblasti sluţeb. Problémy se začaly objevovat jiţ v době přípravy finančního plánu. Tento projekt je ze značné části závislý na dodávkách třetích stran. V plánu však bylo počítáno s pouhými odhady a přáními. Nikdo ze zainteresovaných stran se nezabýval návratností investice. Došlo tak k situaci, kdy původní plán, vytvořený před začátkem projektu, počítal se ztrátou 15 miliónů USD za dobu 5 let, na které byla smlouva s operátorem podepsána. Během pouhých 3 měsíců provozu byla tato ztráta zrevidována a navýšena na 25 miliónů USD. Ukázalo se tak, ţe projektový tým nevěnoval dostatek času SWOT analýze a plánování projektu, které by s největší pravděpodobností odhalily tyto problémy. Rovněţ nedošlo k nastavení vnitřní struktury a procesů pro takový typ projektu, strategické cíle nebyly dostatečně identifikovány – došlo pouze k jejich vágnímu vyjmenování. Z mého pohledu by projekt, chápaný organizací jako strategický, měl mít jasně definované cíle a z finančního pohledu by měl být kalkulován v nejhorším moţném případě s nulovým ziskem. V našich podmínkách je projekt se ztrátou přibliţně 500 mil CZK (celkový obrat projektu předpokládán ve výši 2 mld. CZK za dobu 5 let) spíše špatnou vizitkou organizace. Nutným předpokladem pro zlepšení situace je plánování projektů, které bude vycházet ze dvou důleţitých principů, které pomáhají naplňovat cíle organizace. Jsou jimi vyuţívání programů a řízení portfolia projektů. Vyuţívání programů, coţ jsou skupiny souvisejících projektů, umoţňuje koordinované řízení za účelem získání většího zisku a kontroly, které při řízení kaţdého jednotlivého projektu samostatně není ve většině případů moţné. Osobou
33
odpovědnou za takové řízení je programový manaţer, který se stará o vedení a řízení projektových manaţerů tak, aby všechny projekty v rámci programu probíhaly v souladu s programem. V mnoha společnostech organizační struktura podporuje zavádění obchodní strategie řízení portfolia projektů. Společnosti slučují a řídí projekty a programy jako portfolio investic, jehoţ cílem je přispět k celkovému úspěchu firmy. Úkolem manaţerů portfolia je výběr projektů a jejich analýza z hlediska dlouhodobé perspektivy. Při hledání rozdílů mezi projektovým řízením a řízením portfolia projektů je třeba se zaměřit na taktické a strategické cíle. U taktických cílů, které jsou mnohem specifičtější a krátkodobější, si projektové řízení klade otázky typu: „Realizujeme projekty dobře?, Realizujeme projekty včas a v souladu s rozpočtem? Ví zainteresované strany projektu, co by měly dělat?“ Strategické cíle naopak zdůrazňují dlouhodobé cíle společnosti, na základě kterých si řízení portfolia klade otázky jako: „Pracujeme na správných projektech? Investujeme do správných oblastí?“ Máme správné zdroje k tomu, abychom byli konkurenceschopní?“ Optimální cestou dosahování stanovených cílů nebo účelu je dobrá praxe. Jeden z přístupů k řízení portfolia popisuje situaci, kdy v celé organizaci existuje jedno velké portfolio projektů, coţ umoţňuje managementu společnosti vidět a řídit všechny projekty na úrovni podniku. Následuje rozdělení portfolia na jednotlivé části, coţ zlepšuje řízení projektů v kaţdém oddělení. Hlavními kategoriemi portfolia společnosti mohou být například marketing, IT, lidské zdroje atd. Kaţdá z těchto kategorií je dále rozdělena na tak, aby se jednotlivé části mohly lépe zaměřit na konkrétní zájmy a účel.
6.3
Plánování projektů
Velmi podceňovanou částí projektového řízení je plánování projektů. Není zavedené strategické plánování, které by definovalo dlouhodobé cíle, zaloţené na silných a slabých stránkách organizace, analýze příleţitostí a hrozeb v daném podnikatelském prostředí. Pokud bychom se o takovou analýzu SWOT pokusili, mohla by vypadat takto: silné stránky: -
zkušený technický tým pro realizaci projektů v oblasti telekomunikací
-
silná finanční pozice
-
účast na velkých projektech v oblasti telekomunikací
-
můţeme nabídnout produkty pro datová centra, podnikové sítě, atd.
34
-
zázemí pro další technologie, např. cloud computing
slabé stránky: -
neexistuje marketingová strategie k produktům a sluţbám
-
neochota učit se z vlastních chyb
-
nedostatek zdrojů pro projekty mimo oblast telekomunikací
příleţitosti: -
rostoucí poţadavky na nová datová centra, cloud computing, atd.
-
rostoucí „obliba“ outsourcingu
hrozby: -
na trhu existují firmy s většími zkušenostmi
-
uspokojení se stávající situací
-
oblast telekomunikací prochází obdobím útlumu
Často se odpovědné osoby staví k plánování negativně vzhledem k tomu, ţe ne vţdy se pouţívá ke zjednodušení činností. Není ţádnou výjimkou stanovení nerealizovatelných plánů, kterým není věnován dostatek času a námahy lidmi znalými danou problematiku. Základním problém plánování je neefektivní zahájení projektu, kdy nejsou představeny klíčové zainteresované strany, nejsou jasně definovány projektové cíle, resp. milníky. Rovněţ nedochází
k revizi
dokumentů
souvisejících
s daným
projektem
(např.
zadávací
dokumentace). Jedním z nejdůleţitějších a současně nejtěţších aspektů řízení projektů je definice jeho rozsahu. Rozsah projektu je stanoven na obecné úrovni, ze které je někdy obtíţné zjistit, jaké práce budou a nebudou součástí projektu. To vede k situaci, kdy projektový tým a zainteresované strany chápou rozdílně produkty, které budou v rámci projektu vytvořeny, a procesy, které k produktům povedou. Mezi pět hlavních procesů řízení rozsahu projektu by měl patřit: sběr poţadavků, definování rozsahu, vytvoření WBS (work breakdown structure), ověření rozsahu a kontrola rozsahu.
35
První krok řízení rozsahu projektu, tedy sběr poţadavků, je obvykle nejsloţitější. Sběr poţadavků je prováděn pouze omezeným okruhem lidí bez další koordinace s ostatními zainteresovanými stranami. Můţe tak nastat situace, kdy projektový manaţer nebo obchodník vyţaduje zajištění externích zdrojů. Odpovídající oddělení nemůţe vyhovět takovému poţadavku neboť nemá všechny potřebné vstupy. Hlavním důsledkem špatně definovaných poţadavků je nutnost je přepracovat. Celý proces se tak zpoţďuje a my se musíme vrátit zpět ke sběru poţadavků, coţ stojí další náklady a čas. Proces se tak stává neefektivním a těţkopádným. Na takový přístup je moţné nahlíţet spíše jako na selhání lidského faktoru neţ projektového přístupu. Lidé často nemají přesnou představu o poţadavcích a neví, jak je sbírat a následně dokumentovat. Tímto jsme odhalili další slabou stránku – nemáme k dispozici ţádné kontrolní mechanismy, které by takovým stavům předcházely, případně je limitovaly. Jedním z takových nástrojů, velmi jednoduchým, můţe být matice sledovatelnosti poţadavků. Poţadavky je nutné v detailní míře a odpovídajícím způsobem dokumentovat tak, aby je bylo moţné v průběhu realizace projektu hodnotit a měřit. Existuje několik způsobů, jak sbírat poţadavky. Organizace aţ příliš spoléhá pouze na dva způsoby sběru dat. Jedním z nich jsou rozhovory s jednotlivými zástupci zainteresovaných stran. Ty ovšem nebývají tak efektivní a jsou časově náročné neboť těchto jednání se účastní pouze obchodníci, kteří nemají vzdělání v oblasti dodávaných sluţeb a jsou schopni zajistit pouze obecné informace, které nevedou k poţadovanému výsledku. Tím je schopnost sestavit plán projektu na základě technických poţadavků, návrh řešení, atd. Druhým vyuţívaným zdrojem jsou informace třetích stran. Opomíjenými metodami jsou facilitační workshopy, vyuţití skupinové kreativity. V kaţdém případě je vţdy důleţité propojit rozsah a klíčový aspekt celého projektu s obchodní strategií. Stejně jako existuje několik způsobů, jak sbírat poţadavky, existuje i řada cest, jak je dokumentovat. Na prvním místě by měl projektový tým zrevidovat zadávací listinu, neboť můţe obsahovat významné poţadavky projektu nebo významné odkazy na další dokumenty, které se poţadavky zabývají. Ačkoliv tyto revize jsou prováděny, neexistuje ţádný univerzální postup, jak tyto revize evidovat, není ţádný formát dokumentace poţadavků zainteresovaných stran, které se k poţadavkům vyjádřily. Namísto pouţití profesionálního softwaru pro řízení projektů se dokumentace zpracovává v běţných jednoduchých kancelářských aplikacích. Co velmi postrádám při řízení projektů v čínské organizaci je zpracování plánu řízení poţadavků a matici sledovatelnosti poţadavků. Chybí tak popis, jak budou projektové
36
poţadavky analyzovány, dokumentovány a řízeny. Absence matice sledovatelnosti poţadavků neumoţňuje mít přehled o všech poţadavcích projektu. Snadno tak můţe dojít k opomenutí či vynechání důleţitého prvku projektu. Dalším krokem řízení rozsahu projektu je detailní definování rozsahu projektových prací. Je zde snaha tento krok řešit, nicméně je velmi limitována zkušenostmi a znalostmi odpovědných pracovníků. Odhady času, nákladů a zdroj, stejně jako směrné plány pro měření výkonu a kontrolu projektu jsou tak pouze hrubé, často se jedná o přání a snahu připravit pro zákazníka líbivý plán, neţ reálný odhad. Členové týmu jsou vystavováni situacím, kdy nerozumí zadávací dokumentaci, ta je postupována třetím stranám, které mají více zkušeností s danými projekty. Celý tým je v takovém případě zcela nebo z velké části závislý na loajalitě a schopnostech externích partnerů. Po sběru poţadavků a definování rozsahu následuje vytvoření hierarchické struktury prací. Zde je vhodné zmínit snahu organizace vyuţívat WBS, i kdyţ se jedná o vlastní formu a způsob vytváření. Nejsou vyuţívány aplikace tomuto účelu určené, např. Microsoft Project, Gantt project a další. Moţným nedostatkem by mohlo být obecné rozčlenění úkolů u sloţitějších projektů. Pokud je však stávající model pro organizaci přijatelný a úkoly jsou jasně komunikovány, je moţné tento způsob akceptovat. Vţdy však musí být WBS správně strukturována, aby byla dobrým základem pro časový plán projektu.
Obrázek 5 - Ganttův diagram (Gantt project, zdroj www.linuxexpres.cz)
37
Zřejmě jedinými dvěma výtkami by zde mohl být fakt, ţe za jednu poloţku WBS odpovídá někdy více pracovníků. Domnívám se, ţe výhodnější se jeví uvádět vţdy pouze jednu odpovědnou osobu, ačkoli se na dané poloţce můţe podílet více osob. Druhá výtka se týká zapojení všech členů projektového týmu tak, aby bylo moţné dosáhnout souladu a spolupráce. Ověřování a kontrola rozsahu jsou dalšími kroky řízení rozsahu projektu. Projektové týmy jiţ od začátku tuší nebo dokonce s jistotou vědí, ţe je rozsah jejich projektu velmi neurčitý a ţe při navrhování a realizaci předmětů plnění musí úzce spolupracovat se zákazníky či dalšími zapojenými stranami. V takovém případě by měl projektový tým nastavit proces ověřování rozsahu, který by zajistil, ţe projekt naplní poţadované potřeby. Ke škodě organizace nejsou nastaveny pečlivé postupy, které by zabezpečily, ţe zákazník dostane to, co chce, a ţe tým bude mít dostatek času a peněz na zajištění poţadovaných produktů a sluţeb. Je moţné se tak setkat s případy, kdy jsou během realizace projektu měněny poţadavky ze strany zákazníka. Ty však nejsou komunikovány se všemi členy týmu a v některých případech jsou bez dalšího zváţení dopadů akceptovány projektovým manaţerem, obchodním zástupce či členem managementu společnosti. Naprosto stejným způsobem je přistupováno k řízení času, nákladů, kvality, komunikace a rizik. Vše je řešeno pouze neformální cestou. Příčinou konfliktů v harmonogramu jsou odlišné styly práce a kulturní rozdíly, které jsou patrné zejména ve srovnání asijských a evropských pracovníků. Velmi často se můţeme setkat s tím, ţe pro kaţdý projekt je sestaven harmonogram projektu, jen velmi zřídka je však kontrolován a dodrţován. Etika práce je rovněţ asijskými pracovníky vnímána jinak – existují pouze dva zájmy, získat projekt a dodat projekt. Ţádné další kroky mezi těmito dvěma body nejsou sledovány a nemají takovou podporu. Vzhledem k těmto příčinám konfliktů v harmonogramech projektů je nezbytné, aby projektový manaţeři pouţívali správné metody řízení času v projektech a dokázali tak zlepšit svou práci. Co lze brát částečně jako krok správným směrem je odhadování doby trvání jednotlivých aktivit. Opět se však dostáváme k omezeným znalostem řešených projektů. Plány odpovídají primárně přání zákazníka a jen částečně odráţení reálnost těchto přání a poţadavků. Jednou z prvních kontrol, které by měl projektový tým provést, je zhodnocení návrhu plánu obsaţeného v zadávací listině projektu. Dalším krokem, který by měl manaţer spolu s týmem učinit, je připravit detailnější časový plán a nechat jej schválit všemi zainteresovanými stranami. Zapojení a souhlas všech členů týmu, top managementu, zákazníka a ostatních 38
zainteresovaných stran jsou pro stanovení reálného harmonogramu klíčové. Projekty, u kterých chybí realistické odhady časového plánu, jsou předem odsouzeny k neúspěchu, ať uţ se jedná o ztrátu dobrého jména, finanční ztráty, apod.
6.4
Řízení a koordinace realizace projektu
Řízením projektu je pověřen projektový manaţer. Ten se nachází v odlišné pozici ve srovnání s projektovými manaţery v IBM. Projektový manaţer se během realizace projektu musí soustředit nejen na vedení samotného projektu, ale také na výkon jednotlivých aktivit, které by za běţných okolností byly vykonávány dalšími členy týmu. Odpadá zde jedna z hlavních a klíčových aktivit projektového řízení, kterou je řízení lidských zdrojů. Pokud je součástí projektu významné mnoţství rizika nebo dodávek třetích stran, musí být projektový manaţer zběhlý v řízení rizik a řízení dodávek. Na tomto místě je nutné zdůraznit flexibilitu a kreativitu, kterou projektový manaţeři disponují. O integrovaném řízení projektu, které pohlíţí na plánování a realizaci projektu jako na dvě vzájemně propojené aktivity, nemůţe být řeč. Hlavním úkolem by zde mělo být zpracování dobrého plánu, který by pomohl vytvořit kvalitní výsledky. Reálný přístup je takový, ţe tyto dvě části jsou absolutně oddělené. Plán je připraven na obecné úrovni, neexistují dílčí etapy, nejsou identifikována rizika, chybí protikrizová opatření. Jediný zájem je upřen na dodrţení termínu stanoveného zákazníkem. Téměř vţdy zákazník poţaduje nereálné termíny. Protoţe však příprava projektu byla ochuzena o analýzu reálnosti poţadovaných termínů, je v průběhu realizace velmi obtíţné pracovat s milníky. Ty je sice moţné stanovit, nicméně jsme jiţ svázáni smluvními podmínkami a finálním termínem. Termíny etap tak směřuji opět k nereálným termínům. Klíčovou roli hraje při řízení projektu silné vedení a podporující organizační kultura. Vedoucí pracovníci by měli být ostatním příkladem, je třeba, aby ukázali, proč je třeba vytvořit kvalitní plán projektu. Plán vytvořený projektovým manaţerem je však často upravován nadřízenými bez znalosti skutečných podmínek, bez bliţší znalosti dodávek třetích stran, atd. Organizace sama tak dostává svůj projektový tým do problémů. Neexistují jasná a smysluplná pravidla pro řízení projektů, které by pouţívala celá organizace. Současná pravidla jsou zmatečná a byrokratická a dokončení práce či hodnocení postupu projektu spíše komplikují. Projektový tým začíná být demotivovaný a jeho výkonnost a efektivita klesá.
39
Běţnou podmínkou úspěšné realizace projektu je vedle vůdčích a komunikačních dovedností také znalost produktu, oboru podnikání a aplikační oblasti. Kultura a nepsaná pravidla organizační kultury říkají, ţe nelze sestavit projektový tým bez pracovníků mateřské části organizace. Tito pracovníci mají nedostatečné odborné zkušenosti a rovněţ postrádají praktickou znalost produktů. Opět zde naráţíme na jiţ zmíněný problém správného výběru projektů. Organizace agresivně vstupuje do projektů, o kterých nemá dostatečné znalosti a stává se závislou na třetí straně, která toto know-how má. Vzniká tak velmi omezený prostor pro vyjednávání podmínek spolupráce. Třetí stana během organizačních schůzek záhy zjistí, jak výhodná je její vyjednávací pozice. Vrcholový management firmy si stále neuvědomil, ţe velké nebo významné projekty vyţadují zkušené manaţery, kteří dobře rozumí oboru, aplikačním a obchodním podmínkám.
6.5
Monitorování a kontrola projektových prací
Monitorování projektových prací zahrnuje sběr, vyhodnocení a distribuci informací vztahujících se k postupu projektu. Projektový tým by měl postup projektu monitorovat průběţně, coţ je aktivita, která je v současné době prováděna pouze projektovým manaţerem a která není podpořena odpovídajícími procesy. Projektový manaţeři disponují jen velmi jednoduchými nástroji na sběr a vyhodnocení dat o projektu. Tyto informace nejsou dostupné celé organizaci, tzn. ţe další pracovníci, kterým by pomohli v jejich práci (např. strategický nákup, controlling), nemohou tato data vyuţívat. Projekty nejsou vyhodnocovány průběţně, díky čemuţ projektový tým není schopen vyhodnotit celkový stav projektu a identifikovat oblasti, kterým je třeba věnovat zvýšenou pozornost nebo které indikují blíţící se rizikovou událost. Opět jsou tyto informace sdíleny pouze v úzkém okruhu lidí, zbývající členové dostávají informace náhodně a příleţitostně. Důleţitým výstupem monitorování a kontroly prací na projektu by měl být změnový poţadavek, který by obsahoval potřebná nápravná opatření a nápravu chyb. Za závaţný nedostatek bychom mohli rovněţ povaţovat chybějící systém řízení změn. Změnová řízení nejsou řízena systémově, jsou neformální, bez potřebné dokumentace. Organizační kultura v tomto případě motivuje projektové manaţery k tomu, aby takto postupovali. Nastavená byrokracie by téměř jistě způsobila prodlevy a zpoţdění způsobené časem potřebným pro schválení či zamítnutí navrţených změn. Projektový manaţer se
40
dostává do situace, kdy změnové poţadavky řeší sám bez dalších vstupů a snaţí se je začlenit do existujícího řešení.
6.6
Řízení nákladů projektu
Řízení nákladů projektu by mělo zahrnovat procesy, jejichţ cílem je zajistit, aby projektový tým dokončil projekt v rámci schváleného rozpočtu. Součástí řízení nákladů jsou tři procesy: a) odhadování nákladů – je velmi komplikované, protoţe neexistuje ţádný nástroj, který by obsahoval historické zkušenosti, popisy předchozích projektů, nákladů, atd. b) vytvoření rozpočtu – je často prováděno vzdáleně, bez detailní znalosti podmínek projektu, obvykle je rozpočet sestavován vědomě se ztrátou jen za cenu získání projektu c) kontrola nákladů – nastavené procesy jsou velmi nedostatečné, dochází k úmyslnému zkreslování výsledků tak, aby odpovídali poţadovaným cílům (např. započítávání DPH do příjmů z projektu, přepisování skutečných dat „natvrdo“) Zkreslování nákladů je součástí téměř kaţdého projektu. Toto je moţné dokumentovat na jednom z nedávno realizovaných projektů. Na počátku byla ztráta z projektu odhadnuta na 15 milionů dolarů v průběhu 5 let. Po pouhých 3 měsících prací na projektu byla tato ztráta navýšena na 23 milionů dolarů. V podmínkách jiných společností nepředstavitelná situace. Kontrola skutečných nákladů managementem společnosti je téměř nemoţná. Neexistuje ţádný softwarový nástroj, který by jasně ukázal, jaký je stav projektu po finanční stránce. Běţným nástrojem pro odhadování nákladů, tvorbu rozpočtu a řízení nákladů jsou tabulkové procesory.
6.7
Uzavření projektu či fáze
Posledním procesem projektu je jeho uzavření, případně uzavření jeho fáze. Velkým pozitivem této společnosti je snaha udělat maximum pro včasné dodání projektu. To se ve většinu případů daří. Sponzoři projektu se v okamţiku konečného schvalování projektu obvykle nejvíce zajímají o to, zda byl poţadovaný produkt či sluţba dodána včas. Nicméně je to pouze jedna z podmínek úspěšného dokončení projektu. Pouze zřídka dochází ke kontrole kvality odpovědným pracovníkem (např. manaţer kvality). Vše musí být zajištěno projektovým manaţerem bez jakékoliv další podpory, případně za podpory třetí strany, která 41
poskytovala subdodávky. Také nejsou zpracovány historické informace vzniklé za doby realizace projektu. Informace tohoto charakteru jsou základem učící se organizace a zcela jistě je můţeme povaţovat za velice cenná aktiva pro budoucí projekty.
7.
Případová studie – projekt realizovaný ve vybrané asijské společnosti
7.1
Popisovaný projekt
V roce 2010 se největší telefonní operátor v České republice rozhodl pro redukci nákladů na provoz celé telefonní sítě. Z tohoto důvodu vypsal výběrové řízení na outsourcing údrţby a správy celé telefonní sítě v České republice. Výběrového řízení se účastnili čtyři největší dodavatelé v oblasti telekomunikací – Alcatel Lucent, Nokia Siemens Network, Huawei Technologies a Ericsson. Délka projektu byla vypsána na 5 let s dvouletou opcí. Jednou z podmínek bylo převzetí 120 zaměstnanců telefonního operátora, zajištění dostatečného vozového parku, technické vybavení pro všechny zaměstnance, atd. Vzhledem ke klesajícím investicím telefonních operátorů do nových technologií a výstavby, se společnost Huawei Technologies zaměřila na získání projektu za jakoukoliv cenu. Organizace by se měla výběru projektu řádně věnovat. Jen tak mohla zajistit, ţe bude zahajovat správné projekty ze správných důvodů. Je lepší dosáhnout mírného či malého úspěchu v důleţitém projektu neţ velkého úspěchu v projektu nedůleţitém.
7.2
Projektová idea
Od začátku bylo zřejmé, ţe neexistuje jasná vize, jak by se měl projekt, resp. projekty tohoto typu sluţeb vyvíjet, jak dosáhnout cílů a řídit projekt směrem k efektivnímu vynakládání zdrojů, jak finančních, tak i lidských. Společnost se tímto projektem chtěla dostat na trh servisních sluţeb, coţ byla ke škodě celého projektu jediná myšlenka, která nebyla dále rozpracována do potřebného a nezbytného detailu. Organizace se nezabývala ţádnou studií trţních moţností. Ze dne na den tak vznikl plán poskytovat oursourcingové sluţby v oblasti správy telekomunikačních a energetických sítí. Z tohoto důvodu byl projekt brán jako strategický a jiţ od začátku bylo deklarováno, ţe finanční stránka není brána jako klíčové kritérium. Jak bude zřejmé z dalšího textu, měl a stále má tento postup vliv na řízení a realizaci projektu. Velmi záhy bylo moţné pozorovat absenci strategického plánování, které 42
by slouţilo jako základ definující vizi, poslání, účel, cíle a strategie. Společnost připravila velmi zjednodušený plán rozvoje, zaloţený na získání všech tří největších operátorů v České republice, který jsou TO2, T-mobile a Vodafone. Myšlenka byla velmi zajímavá, nicméně nepracovala s ţádnými riziky. Pokud by organizace kalkulovala alespoň se základními riziky, nemohla by nastat situace, která je v současné době. Vedení organizace se nezabývalo důleţitými preiniciačními úkoly, které zahrnují: - definici limitů rozsahu, času a nákladů projektu - identifikaci sponzora projektu - volbu projektového manaţera - zpracování obchodního případu, resp. strategie - revize procesů a očekávání souvisejících s řízením projektu Předem tak bylo moţné odhadnout budoucí problémy – kdo bude za projekt odpovědný, jaké jsou pravomoci a odpovědnosti jednotlivých členů týmu, jaký je očekávaný výsledek a řada dalších.
7.3 Příprava projektu Ihned po obdrţení zadávací dokumentace byl sestaven projektový tým, který byl odpovědný za přípravu celé strategie, cílů, finančních předpokladů a komplexní nabídky. Jiţ v této fázi nastal dle mého názoru problém. Tým byl sloţen výhradně z pracovníků, kteří neměli s obdobnými projekty zkušenosti, neměli znalost potřebné legislativy ani prostředí. Celý tým byl společně poprvé a byl poskládán z pracovníků různých poboček v rámci regionu Střední a Východní Evropy. Vedení celého projektu pak bylo sestaveno pouze ze zaměstnanců mateřské společnosti v Číně. Z toho plynula řada sloţitých situací – rozdílné chápání projektu, prostředí, rámcové představy o moţnostech zajištění zdrojů a v neposlední řadě také jazyková bariéra. Jakmile se podařilo tým sestavit, bylo dalším krokem sestavení harmonogramu projektu, přidělení úkolů a cílů. Harmonogram projektu vycházel zejména z termínu, který stanovil operátor pro odevzdání kompletní nabídky. Harmonogram lze hodnotit kladně, stejně jako rozdělení úkolů a cílů. Snad jediným problémem bylo jeho sdílení v rámci všech zainteresovaných stran a jeho forma. Všechny strany by měli mít kdykoliv přístup k detailům celého projektu, není moţné pracovat jen s částmi a získávat přehled o celku pouze ze společných jednání. Pro takto sloţitý projekt by bylo rovněţ vhodné pouţívat software tomu 43
určený. Vyuţívání MS Excel pro tyto účely je samozřejmě jedna z moţností, otázkou však zůstává její vhodnost a přehlednost. Velmi jednoduchým řešením by bylo vyuţití cenově nenákladného a účinného softwaru, kterým je například MS SharePoint. Prvním společným úkolem, který musel tým provést byl tzv. due diligence audit. Cílem tohoto auditu mělo být ověření informací poskytovaných zadavatelem. Ačkoliv existuje celá řada due diligence auditů, zde měl být pečlivě proveden alespoň jeden z moţných způsobů a to provozní due diligence. Cílem tohoto auditu mělo být zjištění efektivnosti provozu zadavatele a posouzení, zda-li je moţné tuto efektivitu zlepšit a být schopen dosáhnout svých plánů. Zde můţeme identifikovat další, z mého pohledu chybný krok. Organizace nedisponovala zdroji, které by měly zkušenosti s prováděním takových auditů. Jednoznačným řešením tak měla být spolupráce s třetí stranou, která má potřebné znalosti. Ačkoliv byla v rámci moţností zjištěna celá řada závaţných nedostatků, organizace se rozhodla nebrat tento stav v potaz a pokračovat v přípravě. Jedním z problémů byla například nemoţnost ověřit stávající náklady, coţ bylo pro přípravu finančních plánů velmi zásadní vzhledem k tomu, ţe nikdo z projektového týmu neměl představu ani znalosti, aby dokázal odhadnout náročnost jednotlivých sluţeb. Jediným zdrojem tak stále zůstávaly informace poskytnuté v zadávací dokumentaci. Z těchto údajů vycházela i příprava cenové kalkulace. Při celkovém objemu nákladů v přibliţné výši 300 miliónů Kč ročně tak bylo velmi obtíţné odhadnout, jaké je moţné zefektivnění nákladů a sluţeb. Vzhledem ke zmíněných nedostatečným zkušenostem týmu k této kontrole nedošlo. Navzdory tomu organizace začala s přípravou nabídky, harmonogramem realizace a plánem zvýšení efektivnosti. Celý projekt byl postaven na velmi pozitivních očekáváních a předpokladech. Projektový tým se zabýval pouze myšlenkou úspěchu a všechny činnosti tak směřovaly k přípravě velmi optimistické varianty řešení. Konzervativní či rizikové varianty nebyly zvaţovány, coţ se v současné době ukazuje jako velký problém.
7.3
Realizace projektu
Pravděpodobně díky velmi rizikovému zpracování řešení, které obsahovalo sníţení stávajících nákladů (tzv. cost baseline) o přibliţně 40%, se podařilo tento rozsáhlý projekt získat. Vzhledem k tomu, ţe firma neměla ţádné zdroje pro fyzickou realizaci sluţeb, byla nucena převzít všech 120 stávajících zaměstnanců operátora a tyto zaměstnance kompletně vybavit, rozšířit kanceláře, atd. Sluţby jsou díky tomu v současné době zajišťovány bez větších 44
provozních problémů. Co však neprobíhá jsou pravidelná hodnocení jednotlivých částí projektu – náklady třetích stran, kvalita dodávek třetích stran, vlastní náklady, efektivita poskytování sluţeb, atd. Běţným standardem, který by měl u takto rozsáhlých projektů, je nastavení jednoznačných a měřitelných KPI (Key Performance Indicators) a SLA (Service Level Agreement). Jejich jasná definice, která by měla být součástí smluvní nebo alespoň projektové dokumentace, můţe včas indikovat moţné problémy nebo odhalit slabiny projektu. Rovněţ je moţné z těchto měření získat podklady pro další zlepšování procesů a řízení, odhalit dodávky třetích stran, které neodpovídají poţadované kvalitě a další velmi důleţité ukazatele. Bohuţel ke škodě celého projektu tento způsob kontroly není nastaven. Jedním z důvodů je absence softwaru, který by veškeré incidenty zaznamenával a vyhodnocoval je od jejich vzniku aţ po jejich uzavření. Tento stav nemusí znamenat okamţité problémy, ty ale s největší pravděpodobností nastanou ve chvíli, kdy se například navýší počet incidentů. V tu chvíli organizace nebude schopna identifikovat jejich příčinu, resp. hledání příčin bude vyţadovat více času, zdrojů a tím pádem i nákladů. Velmi dynamickým vývojem prošla finanční stránka projektu. Skutečnost, ţe při přípravě projektu nebyly známy potřebné detaily, organizace neměla ţádné zkušenosti a některé oblasti podcenila, se nyní obrací proti samotné organizaci. Původní finanční plán, který počítal se ztrátou přibliţně 15 milionů dolarů za dobu pěti let, byl po pouhých 4 měsících přehodnocen a celková ztráta se navýšila na 25 milionů dolarů. Další část projektového plánu také počítala se sníţením počtu zaměstnanců o 30 z celkových 120 po prvním roce poskytování sluţeb. I toto předsevzetí se ukázalo jako nereálné a ke sniţování stavu zaměstnanců nedošlo.
7.4
Vývoj projektové strategie v zajišťování služeb údržby
Koncem roku 2011 organizace získala stejný outsourcingový projekt u třetího největšího operátora v České republice. Zde uţ si je moţné všimnout, ţe původní strategie nebyla kvalitně a podrobně zpracována a nepočítala s negativním vývojem. Nastavené cíle byly velmi ambiciózní. I u tohoto operátora došlo k převzetí stávajících zaměstnanců, tentokrát se jednalo o 65 zaměstnanců. Jednou ze smluvních podmínek je převzetí těchto zaměstnanců za naprosto stejných podmínek, jaké jim poskytuje operátor včetně veškerého vybavení, vedoucím pracovníkům musí být zachovány pracovní pozice a řada dalších velmi omezujících poţadavků. Z hlediska projektového řízení opět došlo k podcenění významných atributů a soustředění se pouze na jediný cíl – získat dalšího zákazníka za jakoukoliv cenu. Nabídka,
45
která znamenala získání tohoto zákazníka obsahovala slevu ze stávajících nákladů 30%. Stále zde však existovala naděje, ţe získání třetího operátora můţe přinést tak očekávaný zisk. Nicméně většina členů projektového týmu jiţ byla značně skeptická a to díky faktu, ţe poslední operátor měl moţnost připravit si podmínky spolupráce na základě výsledků dvou předchozích operátorů. Projektový tým v současné době bojuje s tvrdými poţadavky, které zní jasně – minimální očekávaná sleva je 30%. Na základě těchto výsledků je moţné konstatovat několik závěrů. Čínská společnost pokračuje v deformaci trhu dumpingovými cenami a zneuţívá dotací čínských bank. Jiţ nyní je moţné pozorovat klesající kvalitu sluţeb, projevující se například v niţším počtu preventivních
kontrol
jednotlivých
technologií
a
v neposlední
řadě
nedodrţování
legislativních předpisů vztahujících se například k nakládání s nebezpečnými odpady. To vše vede k rostoucí demotivovatnosti zaměstnanců a jejich neochotě se na projektu podílet.
8.
Vlastní úvaha a doporučení
V projektovém managementu se pohybuji posledních 5 let. Jako součást projektových týmů jsem odpovědný za náklady a řízení dodávek třetích stran. Tato odpovědnost zahrnuje několik dílčích etap – od provádění analýzy trhu a kalkulace nákladů externích zdrojů, přes přípravu obchodních smluv a nastavení kritérií dodávek, aţ po kontrolu plnění stanovených SLA. Součástí je také vyhodnocení spolupráce s dodavateli. Jako v kaţdé oblasti řízení, i v projektovém řízení má kaţdý přístup své výhody a nevýhody. Někdy je to větší míra flexibility, jindy větší znalosti nebo vyhovující procesní řízení. Z mého pohledu je pro organizaci velmi důleţité pouţívat osvědčené postupy, procesy a standardy (ISO, ITIL, COBIT). Vymýšlet v dnešní dynamické době nové metodiky je velmi náročné a vyţaduje to velmi zkušené pracovníky a vysoké finanční náklady. Toto si mohou dovolit organizace, které se na tuto oblast specializují a mají potřebné know-how a zdroje. Velmi důleţité je také nebrat ţádnou metodiku či standard jako nezměnitelné dogma. Metodiku je třeba brát jako návod, resp. rámec, který je třeba přizpůsobit prostředí, kultuře a cílům organizace. Ani nejdokonalejší metodika nezaručí úspěch projektů a organizace. Ve srovnání „západního“ a čínského přístupu k projektovému řízení, stojím spíše na straně tradičního západního chápání. Během psaní této práce jsem se pokusil projít řadu materiálů z různých společností, které popisovali jejich přístup k řízení projektů, vyuţívání standardů 46
nebo nejlepších praktik. Pro čínský přístup byla charakteristická snaha převzít celosvětové standardy společnosti IBM, tato snaha je však omezována vlastnickou strukturou, cíly a vizemi společnosti. Snahou čínské společnosti je co nejrychleji proniknout na nové trhy bez ohledu na náklady, restrikce a často i právní předpisy. Nedochází ani k přebírání standardů jako celku, ale jsou pouze vytrhávány části z celkového kontextu. Typická je i snaha investovat do nových postupů co nejméně finančních prostředků. Ačkoliv čínské společnosti působí na první pohled úspěšným dojmem, v tomto konkrétním případě se tak děje na úkor deformace trhu nerealistickými finančními podmínkami. Jen zřídka jsem se setkal s tím, aby úspěchu bylo dosaţeno díky zkušenému projektovému manaţerovi a kvalitně připravenému projektu. Čínské společnosti také velmi málo nebo spíše téměř vůbec neinvestují do zvyšování kvalifikace zaměstnanců. Dle mého názoru se tak nemohou dále rozvíjet tak, jak by bylo moţné. Naproti tomu západní společnosti vyuţívají osvědčených postupů a zavedených metodik. Jedním ze základních poţadavků pro práci projektového manaţera je některá z mezinárodně uznávaných certifikací, nejčastěji PMI nebo PRINCE2. Při dotazování v několika společnostech jsem se nesetkal s tím, aby pozici projektového manaţera zastával zaměstnanec bez předchozích zkušeností. Je téměř pravidlem, ţe budoucí projektový manaţer pracuje nejdříve na jakési asistentské pozici, kdy zajišťuje především administrativní podporu projektovému manaţerovi. Poté je mu svěřen některý z menších projektů. Toto trvá přibliţně tři roky neţ je projektový manaţer povaţován za schopného samostatného vedení projektů. Pozitivním standardem je také investování do školení a zvyšování úrovně kvalifikace všech zaměstnanců.
9.
Závěr
Cílem této bakalářské práce bylo popsat rozdíly mezi přístupy k projektovému řízení v různých kulturních prostředích pomocí uznávaných standardů. Pro zpracování jsem pouţil různých přístupů projektového řízení. V první části jsem se zaměřil na nejpouţívanější postupy – PMBOK, PRINCE2 a IPMA. U kaţdého postupu jsem se pokusil popsat charakteristické rysy, přednosti a rozdíly oproti ostatním metodikám. K porovnání jednotlivých přístupů jsem vyuţil zejména dotazování mezi projektovými manaţery třech společností – IBM ČR, Huawei Technologies (Czech) a Raiffeisenbank ČR.
47
Ve druhé části jsem se zaměřil na srovnání dvou rozdílných chápání projektového řízení – jeden vyuţívající metodiku společnosti IBM, kde jsem čerpal přímo z materiálů této organizace a praktických zkušeností s těmito postupy, a druhý, který nevyuţívá ţádnou z běţně uţívaných metodik a představuje především značné nevýhody. Třetí část je věnována praktickému příkladu bez vyuţití standardizovaných postupů. Na základě těchto srovnání je moţné konstatovat, ţe původní hypotéza: „Podmínkou úspěšně zvládnutého projektového řízení je vyuţívání standardizovaných postupů.“ byla potvrzena.
48
Citace a použité zdroje [1] PITRA, Z. Jak dobře připravit a zpracovat diplomovou resp. bakalářskou práci zaměřenou na management organizace. Česká manaţerská asociace, 2008, 31 s. [2] SCHVALBE, K. Řízení projektů v IT. 1. vyd., Computer Press, a.s., 2011. 632 s. ISBN 978-80-251-2882-4. [3] DOLEŢAL, J.; MÁCHAL, P.; LACKO, B. Projektový management podle IPMA. 1. vyd., Grada Publishing, a.s., 20009. 507 s. ISBN 978-80-247-2848-3 [4] Project management institut: A guid to the project management body of knowledge.Vydává Project Management Institut, Inc. 2008, 4. vyd., ISBN 978-1-93389051-7 [5] Office of Government Commerce: Managing Successful Projects with PRINCE2. Vydává TSO. 2009, 1. vyd., ISBN 978-0-11-331059-3 [6] IBM Corp.: World Wide Project Management Methodology. Vydává International Business Machine Corp. 2001, 2. vyd., [7] LIPKOVÁ, Helena. Standardy projektového managementu a projekt PARTSIP. Inflow: information journal [online]. 2010, roč. 3, č. 5 [cit. 2012-06-21]. Dostupný z WWW:
. ISSN 1802-9736.
Seznam použitých obrázků a zkratek Obrázek 1 - Procesy PRINCE2 Obrázek 2 - Přehled pouţitých metodik a standardů Obrázek 3 - 13 domén WWPMM, jejich názvy a zkratky Obrázek 4 - Procesy v rámci domény Quality Management Obrázek 5 - Ganttův diagram PMBOK IBM PRINCE2 PMI WBS CAD IPMA PPP RUP DMAIC DMADV WWPMM
- Project Management Body of Knowledge - International Business Machine - PRojects IN Controlled Environments - Project Management Institut - Work Breakdown Structure - Computer aided design - International Project Management Association - Project Program Portfolio - Rational Unified Process - Define, Measure, Analyze, Improve, Control - Define, Measure, Analyze, Design, Verify - World Wide Project Management Methodology
49