Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Řízení mezinárodního projektového týmu a projektu
Diplomová práce
Autor:
Bc. Martin Matějka Informační technologie
Vedoucí práce:
Praha
Ing. Václav Šebek, CSc.
duben, 2013
Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen 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 Praze, dne
Martin Matějka
Poděkování: Na tomto místě bych rád poděkoval všem, kteří mi při zpracování této práce poskytli pomoc a potřebné informace. Především děkuji Ing. Václavu Šebkovi CSc. za odbornou pomoc a poskytnutí cenných rad při zpracování práce. Dále bych rád poděkoval své rodině, zejména manţelce za podporu a trpělivost po celou dobu mého studia.
Anotace Tato diplomová práce popisuje řízení mezinárodních projektů a projektových týmu. V úvodu se zaměřuje na metodiky projektového řízení a jejich vyuţití v praxi. V další části jsem popsal činnost projektové kanceláře a její přínos pro řízení projektu. V závěru jsou popsány mé osobní zkušenosti s řízením mezinárodního projektu a doporučení, kam by tento styl řízení měl v budoucnu směřovat. Klíčová slova: Projekt, projektový tým, projektový manaţer, vzdálené řízení projektu.
Annotation This thesis deals with describing project management of international projects and project teams. The introduction describes project management methodologies and their use in real work. The further part describes work of a project office and its contribution to the management of the project. The final part depicts my personal experience with project management of international project and recommendation which way this mode of project management could be aimed at. Key words: Project, project team, project manager, distant project management.
Obsah
Úvod ........................................................................................................................................... 8 1 Základy projektového řízení .................................................................................................... 9 1.1 Metodiky........................................................................................................................... 9 1.2 Základní pojmy ................................................................................................................. 9 1.3 Nástroje (software) vyuţívané v projektovém řízení ..................................................... 11 2 Zahájení projektu ................................................................................................................... 13 2.1 Sestavení projektového týmu ......................................................................................... 14 2.1.1 Výběr vhodných pracovníků do jednotlivých týmů ................................................ 14 2.1.2 Nastavení pravidel interní komunikace ................................................................... 14 2.1.3 Nastavení pravidel komunikace se zákazníkem. ..................................................... 14 2.2 Projektová kancelář ........................................................................................................ 15 2.2.1 Řízení změn ............................................................................................................. 15 2.2.2 Řízení rizik .............................................................................................................. 17 2.2.3 Plánování (scheduling) ............................................................................................ 18 2.2.4 Reporting ................................................................................................................. 20 2.2.5 Správa společných dokumentových úloţišť ............................................................ 21 2.2.6 Školení ..................................................................................................................... 22 3 Projektové řízení v průběhu projektu .................................................................................... 24 3.1 Činnosti projektového manaţera .................................................................................... 24 3.1.1 Detailní zmapování současného stavu a příprava migrace ...................................... 24 3.1.2 Přesunutí HW nebo SW a příprava na cílový stav .................................................. 25 3.2 Činnosti projektového týmu ........................................................................................... 26 3.3 Podpůrné činnosti ........................................................................................................... 28 5
4 Ukončení projektu ................................................................................................................. 30 4.1 Předání do ověřovacího provozu .................................................................................... 30 4.2 Rutinní provoz ................................................................................................................ 31 4.3 Vyhodnocení projektu .................................................................................................... 31 5 Komunikace uvnitř mezinárodního týmu .............................................................................. 33 5.1 Pracovní setkání tváří v tvář ........................................................................................... 33 5.1.1 Workshopy se zákazníkem ...................................................................................... 33 5.1.2 Interní setkání projektového týmu ........................................................................... 34 5.2 Pracovní porady ze vzdálených pracovišť ...................................................................... 35 5.2.1 Konferenční telefonáty ............................................................................................ 35 5.2.2 Virtuální místnosti ................................................................................................... 36 5.2.3 Interní komunikátor ................................................................................................. 38 5.2.4 Sdílená úloţiště ........................................................................................................ 39 6 Příklad vyuţití metodiky na konkrétním projektu ................................................................. 40 6.1 Zavedení metodiky ......................................................................................................... 40 6.2 Dodrţování metodických postupů .................................................................................. 41 6.3 Nestandardní poţadavek zákazníka ................................................................................ 42 6.4 Změnové řízení ............................................................................................................... 43 6.5 Akceptace ....................................................................................................................... 44 6.6 Řízení mezinárodního týmu ........................................................................................... 45 6.6.1 Základní pravidla ..................................................................................................... 45 6.6.2 Team building .......................................................................................................... 46 6.6.3 Zdroje konfliktů ....................................................................................................... 47 6.6.4 Matice zodpovědností .............................................................................................. 47 6.6.5 Způsoby vedení ....................................................................................................... 48 6.6.6 Proces řešení problémů ............................................................................................ 49 6.7 Řízení mezinárodního projektu ...................................................................................... 50 6
6.7.1 Sledování dodrţení plánu ........................................................................................ 51 6.7.2 Časová rezerva......................................................................................................... 52 6.7.3 Změnové řízení ........................................................................................................ 53 6.7.4 Změna kontraktu ...................................................................................................... 53 7 Vyhodnocení.......................................................................................................................... 55 7.1 Zkušenosti a doporučení ................................................................................................. 55 7.1.1 Výhody a nevýhody mezinárodních projektových týmů ......................................... 56 7.1.2 Porovnání úspory nákladů a času versus efektivita ................................................. 59 7.1.3 Shrnutí výsledků ...................................................................................................... 61 7.1.4 Doporučení .............................................................................................................. 62 7.1.5 Komunikační nástroje .............................................................................................. 62 Závěr ......................................................................................................................................... 65 Mezinárodní projekt ......................................................................................................... 65 Mezinárodní projektový tým ............................................................................................ 66 Odhad vývoje do budoucna .............................................................................................. 66 Seznam pouţité literatury ......................................................................................................... 68 Elektronické zdroje ............................................................................................................... 68 Seznam pouţitých obrázků ....................................................................................................... 69 Seznam pouţitých tabulek ........................................................................................................ 70 Seznam zkratek ......................................................................................................................... 71 Přílohy ...................................................................................................................................... 72 Dotazník Řízení mezinárodního projektu ............................................................................. 72 Grafické vyjádření odpovědí: ............................................................................................... 73
7
Úvod Cílem této práce je popsat způsob řízení projektu, který probíhá na mezinárodní úrovni. Projektu, do kterého jsou zapojeni pracovníci z více různých zemí, pracující z různých lokalit, případně i časových pásem. Z toho vyplývá, ţe nejen na projektu jako celku, ale i v rámci jednotlivých projektových týmů pracují kolegové, kteří nemají šanci se scházet na pravidelných projektových schůzích v jedné místnosti. Veškerá komunikace, tedy i řízení probíhá vzdáleně, často v jazyce, který není rodným pro ţádného z členů týmu. V rámci této práce bude pro řízení pouţita a popsána metodika řízení projektu PMP – Project Management Profesional, která je zaštiťována The Project Management Institute, který zajišťuje certifikaci pro tuto metodiku. je jednou z hlavních světových asociací, která se zabývá projektovým vedením. Celosvětově získalo PMP certifikaci přes 350.000 projektových manaţerů.
8
1 Základy projektového řízení Základy projektového řízení, myslím tedy ty úplně nejniţší, které musí být vlastní kaţdému projektovému manaţerovi nejsou postavené na ţádné metodice. Tyto základy jsou postaveny na tak zvaném „selském rozumu“. Podle mého názoru je umění vyuţití tohoto základu to nejdůleţitější pro úspěšného projektového manaţera. Metodiky, které jsou pro řízení projektů vypracované, dávají uţitečné rady a návody jak vést projekt. Dobrý projektový manaţer se od toho méně úspěšného odlišuje právě tím, ţe jen slepě nesleduje metodiku, kterou nastudoval, ale dokáţe se na vedení projektu podívat s jistým nadhledem a dát do vedení projektu i něco ze své hlavy a ze svých zkušeností. Tím rozhodně nechci sníţit přínos metodiky pro řízení projektu. V mnoha případech jsou pro projektového manaţera oporou. Dalším přínosem je, ţe pokud se při zahájení projektu jasně definuje metodika, která bude během projektu pouţita, bude pro všechny zúčastněné, jasné, které události, v jakém pořadí a z jakého důvodu mohou během projektu očekávat.
1.1 Metodiky V srpnu 2012 byla schválena norma ISO 21.500 – Guidance on project management, v září 2012 pak začala tato norma mezinárodně platit. Vychází ze standardu PMBoK od PMI, ale není určena k certifikaci. Mezi nejvíce rozšířené metodiky, jejichţ studium můţe být ukončeno certifikací, která je mezinárodně uznávaná patří PRINCE2, PMP, FocusPM nebo PRIMAVERA. Metodikou rozumíme soubor postupů a pravidel, která jsou buď doporučená nebo závazná a napomáhají nejen řízení projektu, ale i komunikaci v projektovém týmu, mezi projektovým manaţerem a managementem nebo zákazníkem.
1.2 Základní pojmy Projekt – je nejzákladnějším pojmem – je to sled po sobě jdoucích činností, které vedou k vytvoření nějakého výrobku nebo sluţby. Projekty se liší svým rozsahem, zaměřením, dobou trvání a počtem lidí, kteří na projektu pracují. Malé projekty bývají obvykle 9
realizovány v rámci firmy s vyuţitím vlastních zdrojů. Větší projekty mohou být také realizovány uvnitř firmy, ale uţ k nim mohou být přizváni externí pracovníci ať uţ v roli člena projektového týmu nebo externího projektového manaţera. V rámci této práce bude popisován velký projekt, který je dodáván jednou mezinárodní firmou do jiné firmy se sídlem v zahraničí. V projektovém týmu jsou zapojeni pracovníci sídlící v různých zemích Evropy. Projektový tým - další z důleţitých pojmů. Do projektového týmu jsou přijímáni pracovníci podle rolí, které bude tým potřebovat k výkonu činnosti vedoucích k dodání poţadovaného výsledku. Je důleţité sestavit projektový tým tak, aby byl vyváţený. To znamená, ţe výkonnost jeho jednotlivých členů je srovnatelná. Pokud tomu tak není, projeví se to na výkonnosti celého týmu a také to vede ke vzniku konfliktů v rámci týmu. Role – reprezentuje činnost, která má být na projektu vykonávána. Řídící role jako Sponzor projektu nebo Projektový manaţer by měly být součástí všech projektů, ale odborné nebo technické role uţ se liší podle zaměření projektu. Sponzor projektu – je nejvyšší autoritou na projektu. Je za projekt plně zodpovědný, má právo schválit změnu v rozsahu, rozpočtu nebo v klíčových termínech. Zodpovídá za to, ţe změna, která má být projektem realizována bude dodána včas a v odpovídající kvalitě. Projektový manaţer – je zodpovědný za projekt jako celek. Musí mít dostatečné pravomoci k rozhodování a řízení projektu. Zajišťuje komunikaci mezi všemi rolemi v projektovém týmu a managementem. Navrhuje projektový tým, má právo vyměnit členy týmu a také řeší vzniklé problémy týkající se projektu. Dobrý projektový manaţer musí také umět odmítnout převzetí projektu, o jehoţ smyslu není přesvědčen nebo vidí, ţe projekt je neefektivní. Musí umět tento svůj názor vyjádřit, prezentovat ho managementu a před managementem ho také patřičně obhájit. Člen projektového týmu – vykonává odbornou práci v souladu s cílem projektu, musí být seznámen s patřičnou dokumentací. Zároveň můţe identifikovat případná rizika nebo iniciovat projektové změny.
10
1.3 Nástroje (software) využívané v projektovém řízení Hlavním nástrojem pro řízení projektu je aplikace, která umoţní zadat jednotlivé milníky nebo projektové dodávky s jejich počátečním termínem a datem kdy má být dodávka realizována. Zároveň by zde mělo být moţné identifikovat vazby mezi dodávkami nebo jejich návaznosti. Tento software by měl umět vygenerovat i přehledný graf, kde je vidět zda nedochází ke konfliktům mezi jednotlivými dodávkami. V současné době je nejrozšířenějším nástrojem pro toto plánování a sledování průběhu projektu aplikace Microsoft Project. Tento nástroj umí sledovat návaznosti mezi jednotlivými činnostmi projektu, kontroluje, zda nejsou některé dodávky po termínu plnění a zda tím neohroţují nějaké další návazné dodávky. Pokud jsou k činnostem přiřazeny i lidské zdroje, tento nástroj kontroluje zda nedochází k přetíţení pracovníků a upozorní, ţe některý z členů týmu je vytíţen na více neţ 100%. Obrázek 1 - Projektový plán
Zdroj: Vlastní tvorba autora
11
Pro projekty malého rozsahu je moţné plánovat a řídit s pomocí nějakého jednoduššího nástroje, jako je například Microsoft Excel, ale tím se pak projektový manaţer připravuje o pomoc, kterou mu specializovaný software nabízí. Naopak ke sledování finančních toků v rámci projektu je MS Excel velmi vhodný, je vybaven velkým mnoţstvím funkcí, které se na tuto činnost zaměřují. Na vedení zápisů z porad, akceptační protokoly, změnové poţadavky a další projektové dokumenty není jednoznačně doporučený speciální software. Pouţívá se textový editor typu Microsoft Word. V průběhu projektu je nutné prezentovat průběh projektu managementu firmy, případně zákazníkovi. Na to bych doporučil připravit jednoduchou prezentaci v nástroji typu Power Point. Podle mého názoru není dobré v této prezentaci vyuţívat různých efektů, které tento nástroj nabízí. Podstatné je sdělení, které tato prezentace přináší, nikoli efekt. Příliš efektní prezentace můţe odvádět pozornost od smyslu sdělení nebo vyvolávat dojem, ţe velkým mnoţstvím efektů se snaţí autor zakrýt nepříjemné skutečnosti, které ve sdělení jsou. Pouţíváním vhodných nástrojů, vhodným způsobem ušetří projektovému manaţerovi mnoho práce a usnadní vedení celého projektu.
12
2 Zahájení projektu Projekt je zahájen ve chvíli, kdy organizace začne uvaţovat o změně. V této chvíli se začíná řešit co má být výstupem, jaký bude výsledek změny a jakými prostředky se tohoto cíle dosáhne. V rámci této práce bude popsán mezinárodní projekt, kdy se zákazník rozhodl přestěhovat své datové centrum a změnit poskytovatele sluţeb, s datovým centrem spojených. Projekt zahrnoval postavení nových serverů, migraci jednotlivých aplikací a jejich databázi a také vybudování dostatečně silné datové linky mezi datovým centrem sídlícím ve Frankfurtu nad Mohanem a centrálou zákazníka, která se nachází v Brémách. Zahájením projektu tedy v tomto případě není podepsání smlouvy se zákazníkem a zahájení dodávek. Na tomto projektu se začalo pracovat jiţ ve chvíli, kdy dodavatel na základě poptávky zákazníka vypracoval nabídku, kde byl popsán návrh řešení a s plánovanou realizací a cenová nabídka. Pro tuto činnost byl vytvořen malý projektový tým sloţený z bid manaţera, architekta technického řešení a obchodníka. Tento tým provedl tak zvanou due dilligence, coţ je proces, kdy je v rámci moţností co nejdetailněji prozkoumána současná situace datového centra, které zákazník pouţívá. Na jakých jeho aplikace běţí strojích, jak velký je objem dat, která jsou denně v datovém centru zákazníka zpracována a po síti mezi jednotlivými pracovišti zákazníka posílána. Na základě těchto informací byl vypracován návrh technické řešení a cenová nabídka. Ta u zákazníka zvítězila a došlo k podepsání smlouvy. V tuto chvíli je moţné zahájit sestavování projektových týmů. Nejvíce viditelnou částí zahájení projektu je Kick-off meeting, kde je oficiálně managementu zákazníka představeno plánované řešení, termíny dodávek a také je představen projektový tým. To neznamená, ţe zde byli všichni členové projektových týmů, ale sponzor projektu, hlavní projektový manaţer a projektoví manaţeři – tak zvaní tower leadeři. Ti jsou zodpovědní za řízení jednotlivých sub-projektů, například dodávky síťových sluţeb, dodávky serverů nebo migrace aplikací. 13
2.1 Sestavení projektového týmu Programový manaţer, společně s projektovým manaţerem připraví plán projektu. Sestaví seznam rolí, které bude na daný projekt nutné obsadit a v jakém počtu. Poté zahájí výběr vhodných kandidátů podle jejich odbornosti a také dostupnosti v poţadovaném čase.
2.1.1 Výběr vhodných pracovníků do jednotlivých týmů Vzhledem k rozsahu zakázky nebylo moţné pokrýt dodávky jedním lokálním týmem, ale bylo nutné sestavit projektové týmy z volných kapacit a odborníků sídlících v různých státech Evropy. U techniků, kteří nejtěsněji spolupracovali s techniky zákazníka byl kromě odbornosti kladen důraz také na to, aby byli schopni hovořit německy na velmi dobré úrovni. U projektových manaţerů a sponzora projektu byla jako projektový jazyk zvolena Angličtina.
2.1.2 Nastavení pravidel interní komunikace Jako oficiální jazyk projektu byla zvolena Angličtina, coţ znamená, ţe veškerá psaná komunikace uvnitř týmů, mezi týmy i mezi dodavatelem a zákazníkem musí být vedena v anglickém jazyce. I kdyţ se to můţe uvnitř technického týmu, který celý sídlí například v Německu zdát zbytečné, je to důleţité proto, ţe například můţe být později do týmu přijat pracovník z jiné země, který německy neumí a nebude schopen zjistit, co bylo uvnitř týmu nebo s techniky zákazníka komunikováno. Dalším z důleţitých pravidel je, ţe hlavním komunikačním nástrojem byla stanovena elektronická pošta a rozhodnutí vyjádřené v elektronické poště je závazné pro všechny zúčastněné strany.
2.1.3 Nastavení pravidel komunikace se zákazníkem. Jako základní komunikační nástroj byla také stanovena elektronická pošta a oficiálním komunikačním jazykem Angličtina. Pro kaţdý z projektových týmů byl pro potřeby zákazníka stanoven tak zvaný „Single point of contact“, osoba která je pověřená komunikací se zákazníkem, tedy jeho odpovědným pracovníkem na stejné úrovni v organizační struktuře. Pokud bylo učiněno nějaké rozhodnutí ať na straně dodavatele nebo zákazníka, jako závazné bylo povaţováno aţ ve chvíli, kdy 14
navrhující strana dostala potvrzení od protistrany, ţe toto rozhodnutí přijímá a ţe s takovým rozhodnutím souhlasí. Elektronickou poštou docházelo i ke schvalování jednotlivých subdodávek – například zprovoznění nové datové linky nebo migrace dohodnuté sady aplikací. V takovém případě dodavatel zaslal zákazníkovi vyplněný Schvalovací protokol. Zodpovědný pracovník zákazníka jej vytiskl, podepsal, naskenoval a naskenovaný dokument ve formátu PDF poslal zpět dodavateli.
2.2 Projektová kancelář Na základě zkušeností, získaných mou účastí na různých projektech, mohu prohlásit, ţe správně fungující projektová kancelář je nepostradatelnou součástí projektového týmu. Náplní práce projektové kanceláře je podpora projektových týmů a projektových manaţerů. Činnosti projektové kanceláře se nezaměřují na odborné práce vykonávané v jednotlivých projektových týmech, ale zastřešují je a zajišťují administrativní úkony, potřebné ke správnému chodu projektu. Kontrolují dodrţování metodologických postupů a poskytují vzory dokumentů, které jsou během řízení projektu generovány. Činnost projektové kanceláře musí být jasně definována. Všichni pracovníci kanceláře musí být velmi dobře seznámeni s metodikou řízení projektu. Pokud je to moţné, tak je nejlepší, pokud jsou na pouţívanou metodiku certifikováni. Podle velikosti projektu se odvíjí i velikost projektové kanceláře. U malých projektů můţe být veškerá činnost vykonávána pouze jedním člověkem. Na projektech velkého rozsahu má projektová kancelář členy specializované na jednotlivé, níţe uvedené činnosti.
2.2.1 Řízení změn V kaţdém projektu dochází během jeho realizace k určitým změnám. Změny se mohou týkat rozsahu práce, rozpočtu, v počtu členů týmu nebo změna finálního termínu dodávky. Nemusí se jednat o změnu termínu celé dodávky, ale jen jednoho ze sub projektů nebo jen dodávky v rámci projektového týmu, která je uvedena v projektové dokumentaci. Kaţdá z výše uvedených změn musí být řádně dokumentována. K tomu slouţí proces řízení změn, který zajišťuje, ţe k nim bude docházet po zralé úvaze a také koordinovaně. Při schvalování změny 15
je nutné dohlédnout na to jaké má dopady primární, tedy výslovně uvedené v dokumentaci, ale také na to, zda poţadovaná změna nebude mít dopad na ostatní projektové dodávky, které s ní mohou přímo či nepřímo souviset. Za tuto činnost je v projektové kanceláři zodpovědný člověk ve funkci change manaţera. Pro tuto funkci se český překlad manaţer změn pouţívá jen velmi ojediněle. Proto se všeobecně vyuţívá anglický termín, který budu pouţívat i v rámci své práce. Change manaţer musí zajišťovat dohled nad všemi změnami v rámci projektu. Musí shromaţďovat poţadavky na změnu, zajistit, aby byla projektovým manaţerem řádně zdokumentována. V poţadavku musí být uveden rozsah změny, její rozsah, očekávaný termín provedení, otestování, a postup v případě neúspěšných testů k navrácení systému do původní podoby. Takto zdokumentovanou změnu předává ke schválení. Pokud je schválena, oznámí tuto skutečnost tomu, kdo poţadavek vytvořil. Tím práce change manaţera nekončí. Musí sledovat ţivotní cyklus změny aţ do jejího nasazení. Teprve ve chvíli, kdy je nasazena a řádně otestována, můţe být poţadavek na změnu uzavřen a označen za kompletní. Ţivotní cyklus změnového řízení se skládá z těchto kroků:
Iniciace – projektový manaţer nebo člen projektového týmu dojde k závěru, ţe v rámci projektu je nutné zahájit změnové řízení. Tuto skutečnost oznámí projektové kanceláři.
Příprava – ţadatel o změnu ve spolupráci s change manaţerem připraví poţadavek na změnu, kde je změna důkladně zdokumentována i se svými dopady.
Schválení – change manaţer předá změnu ke schválení programovému manaţerovi, který řídí celý projekt včetně sub projektů.
Implementace – podle typu změny dojde k jejímu nasazení. To můţe znamenat, ţe je pozměněn programovaný kód, ale také můţe být navýšen rozpočet projektového týmu nebo je do projektového týmu přijat nový člen. Také můţe být v projektové dokumentaci pozměněn termín dodávky, jeho akceptační kritéria a tak dále. Záleţí na typu změny.
Uzavření – změna je implementována, řádně otestována nebo jak jsem výše uvedl podle typu změny můţe dojít k různým činnostem, které se změnou souvisí.
Zrušení změny – z kaţdého z výše uvedených stavů, kromě stavu „Uzavření“ můţe být změna převedena do stavu „Zrušení změny“. To znamená, ţe změna nebude 16
implementována. Opět k tomu můţe vést více důvodů, jako například se ukáţe, ţe další člen do projektového týmu není nutný, není třeba navyšovat finanční prostředky, jelikoţ tento poţadavek vzešel z chybných předpokladů a tak podobně. Pokud se jedná o malou změnu, která nemá dopad mimo konkrétní projekt, na rozpočet ani celkový plán projektu, můţe být, podle PMP metodologie, tato změna schválena přímo projektovým manaţerem, který změnu iniciuje. Pokud se jedná o změnu většího rozsahu, zejména pak změny do rozpočtu projektu nebo jeho časování, musí být tato změna schválena sponzorem projektu. Jelikoţ realizace změny mívá dopad do rozpočtu projektu, je moţné uvést do smlouvy klauzuli, kde bude uvedeno jaké mnoţství změnových poţadavků ze stany zákazníka bude provedeno dodavatelem v rámci rozpočtu projektu. Další poţadavky nad dohodnutý rámec budou znamenat navýšení částky, kterou musí klient za projektové dodávky zaplatit. Opravdu je nutné, aby kaţdá změna byla zdokumentována a potvrzena schváleným změnovým poţadavkem. Jedině tak se zamezí tomu, aby docházelo k nekoordinovaným změnám, byť třeba na základě poţadavku zákazníka. I zákazník musí být s procesem řízení změn seznámen a musí jej dodrţovat.
2.2.2 Řízení rizik Kaţdý projekt v rámci jeho ţivota provázejí rizika. Rizika mohou být předem známá, ale také neznámá. Mohou to být rizika, které dokáţeme ovlivnit a rizika neovlivnitelná. Při přípravě rozpočtu na kaţdý projekt musí být určitá část plánovaných financí připravena na pokrytí rizik. Nedokáţi přesně definovat, jak velká část z rozpočtu projektu by měla být vyčleněna na případné pokrytí rizik. V metodikách není uvedeno exaktní číslo, jako například odhadovaný rozpočet na projekt by měl být navýšen o 10%, tato částka bude vyčleněna na pokrytí případných rizik. Výše této částky je stanovena podle rozsahu projektů, cíle projektu, definování rizikových faktorů a také zkušenosti projektového manaţera, který dokáţe předvídat a odhadnout jakými riziky je projekt ohroţen. Pro hodnocení rizika není nejpodstatnější velikost finanční částky, na kterou případný dopad rizika ohodnotíme, ale pravděpodobnost, ţe toto riziko skutečně nastane. Pokud tedy odhadneme riziko s dopadem 1.000.000,- Kč a pravděpodobností výskytu 20%, dále pak 17
riziko s dopadem 500.000,- Kč a pravděpodobností výskytu 60%, musíme se primárně zabývat tím druhým rizikem, protoţe projekt ohroţuje daleko víc. V projektové kanceláři se touto činností zabývá risk manaţer. Je zodpovědný za identifikaci moţných rizik, sledování jejich výskytu a dopadů na projekt. Úzce spolupracuje s projektovým manaţerem. Kromě výše uvedených činností také navrhuje jak rizika eliminovat. Zda je dobré posunout termín dodávky, navýšit počet členů projektového týmu nebo nějaké jiné řešení, které zabrání tomu, aby byl projekt ohroţen. Risk manaţer vede detailní evidenci identifikovaných rizik. Zde je uvedena odhadovaná pravděpodobnost výskytu, dopad na projekt, časový odhad, kdy můţe riziko nastat a navrhované řešení. Také eviduje objem finančních prostředků, který byl na odstranění rizik během projektu čerpán. Výše uvedené ovšem neznamená, ţe ţádný jiný člen projektového týmu nemůţe identifikovat riziko. Kterýkoli pracovník na projektu můţe odhalit riziko, v takovém případě musí o vzniku rizika informovat svého projektového manaţera, který pak zajistí standardní proces řízení rizik s tímto pracovníkem a risk manaţerem. Je vhodné, aby risk manaţer pravidelně informoval projektového manaţera o výskytu rizik, odstranění rizik a čerpání finančních prostředků. Z mé zkušenosti doporučuji naplánovat pravidelnou schůzku kaţdý druhý týden, kde risk manaţer seznámí projektového manaţera s vývojem rizik za uplynulé období a výhledem výskytu rizik do budoucnosti. Pokud nastane neočekávané riziko, musí samozřejmě projektového manaţera informovat ihned.
2.2.3 Plánování (scheduling) Plánování je nedílnou součástí kaţdého projektu. Plán činností na projektu musí být vytvořen uţ před jeho zahájením, aby bylo moţné stanovit jeho rozsah a návaznost jednotlivých činností. Kvalitně vypracovaný plán můţe ušetřit mnoho nákladů, které by musely být vynaloţeny později. V případě, ţe plánování nebude provedeno kvalitně, je pravděpodobné, ţe v průběhu projektu bude docházet ke kolizím činností v jednotlivých projektových týmech. Případně některý člen týmu bude mít naplánováno více činnosti zároveň v jednom čase. Tím je bude hůře zvládat a dojde ke skluzu, který můţe mít dopad nejen v rámci týmu,
18
ale i na další projektové týmy, které budou čekat na jeho dodávku, aby na ni mohly navázat svojí činností. V projektové kanceláři je za plánování zodpovědný scheduler – plánovač. Ve spolupráci s projektovým manaţerem vytváří projektový plán v nástroji Microsoft Project nebo jemu podobném a sleduje průběh projektu, plnění jednotlivých termínů nebo jejich zpoţdění. Na velkých projektech, kterých jsem se účastnil, jsme dospěli k závěru, ţe nestačí jeden celkový projektový plán, ale existoval zde samostatný plán pro kaţdý sub projekt. Plánovač z projektové kanceláře spolu s jednotlivými projektovými manaţery, zodpovědnými za jednotlivé sub projekty, na pravidelné bázi – doporučuji kaţdý týden – kontroloval postup prací a dodrţování těchto plánů. Z těchto jednotlivých plánů pak vytvoří souhrnný plán kde je postup prací zohledněn a můţe být prezentován na nejvyšších řídících úrovních projektu. Je vhodné, aby plánovač úzce spolupracoval s change manaţerem. Můţe být otevřen poţadavek na změnu, který má dopad na plánování projektu a termíny jednotlivých dodávek, které plánovač sleduje. V takovém případě je vhodné, aby change manaţer upozornil plánovače, ţe v dohledné době bude implementována změna, která bude mít dopad na jeho činnosti. Samozřejmě je vhodné informovat i obráceně, pokud plánovač vidí, ţe v některých dodávkách dochází k velkému zpoţdění měl by o této skutečnosti informovat change manaţera, který pak iniciuje nový poţadavek na změnu, kterou budou posunuty termíny dodávek. Je vhodné, aby o těchto skutečnostech byl informován i risk manaţer, který bude evidovat vznikající riziko. Scheduler má nástroje k tomu, aby vytvářel přehledy o stavu projektu a plnění jednotlivých dodávek. Z nástroje Microsoft Project vygeneruje mnoho různých přehledů, jako například procentní plnění dodávek, průměrné procento zpoţdění dodávek, přehled všech dodávek, které byly dodány včas, které mají zpoţdění a které mají být dodány v budoucnosti. Všechny tyto sestavy jsou pro projektového manaţera a sponzora velmi uţitečné a poskytnou mu rychlý přehled o aktuálním stavu projektu.
19
Tyto sestavy je vhodné generovat ve dvou verzích, jedna je interní, kde je přehled všech dodávek a subdodávek a pak externí, kde jsou informace podstatné pro zákazníka. To neznamená, ţe bychom chtěli něco před zákazníkem tajit, ale v rámci projektu mohou probíhat interní činnosti, o který zákazník nemusí být informován nebo o nich bude informován později, aţ bude připravena například nová sluţba v kompletní verzi tak, aby zákazníka zaujala. Obrázek 2 - Přehled stavu dodávek jednotlivých sub projektů
Zdroj: Michał Siuda, PMP®, Schedules analysis Takto fungující projektová kancelář je jasným důkazem pro zákazníka, ţe projekt je řízen koordinovaně, jednotlivé činnosti nevznikají chaoticky a je jen minimum moţností vzniku nějakých kolizí.
2.2.4 Reporting Pro potřeby kaţdého projektu je nutné vytvářet různé reporty a dokumenty s kterými projektovému manaţerovi pomáhá projektová kancelář. Připravuje vzorové dokumenty, formuláře, akceptační protokoly nebo zápisy ze schůzí. 20
Na základě poţadavku projektového manaţera pracovníci projektové kanceláře organizují projektové schůzky, na které připravují podklady a informují jednotlivé účastníky schůzky o její náplni. Z těchto schůzí připravují zápisy, které pak posílají všem účastníkům ke schválení a dohlíţí na plnění stanovených úkolů případně informují pracovníky, kteří se schůze nezúčastnili, ţe jim byl přidělen úkol. Zatím jsem se nesetkal s tím, ţe by tato role v projektové kanceláři měla nějaký specifický název jako například change manaţer. Podle mého názoru by pro tuto roli byl vhodný název administrativní pracovník. Tento pracovník nejen ţe připravuje výše uvedené dokumenty, ale také kontroluje, zda se správně vyplněné vrátily zpět do projektové kanceláře a má na starosti jejich uloţení na příslušné místo, nejlépe na sdíleném úloţišti. Velmi významná je tato činnost při evidenci akceptačních protokolů a to jak těch, které byly vyplněny pouze elektronicky nebo u významných dodávek došlo k jejich fyzickému podepsání a je ukládána papírová verze. V případě
akceptačních
protokolů
musí
administrativní
pracovník
spolupracovat
s plánovačem, jelikoţ ţádná z dodávek, ať uţ dílčích nebo celkových nemůţe být v projektovém plánu označena za 100% dodanou, dokud nebyl do projektové kanceláře dodán akceptační protokol podepsaný projektový manaţerem dodavatele a zákazníka.
2.2.5 Správa společných dokumentových úložišť Na všech projektech je vhodné, aby byla dokumentace ukládána na nějakém sdíleném místě, tak aby k ní měli přístup všichni členové projektových týmů. V případě velkých projektů a projektů mezinárodních toto není pouze vhodné, ale je to naprosto nutné. Dobrým zvykem také je, ţe toto úloţiště – SharePoint – je alespoň částečně zpřístupněno i některým pracovníkům z projektového týmu zákazníka. Proto doporučuji rozdělit přístupovými právy SharePoint na interní a externí část. Není vhodné, aby zákazník viděl všechny dokumenty a zápisy z porad, které se projektu týkají, ale měl by mít moţnost vidět alespoň zápisy z porad, kterých se zúčastnil.
21
Na tomto úloţišti musí být moţné najít i veškerou dokumentaci k řízení změn, řízení rizik a plánování. Proto se o toto úloţiště musí, podle svých kompetencí, starat všichni členové projektové kanceláře, ale administrativní pracovník musí mít rozhodující slovo a dohlíţet, aby všechny dokumenty byly dodány včas a v odpovídající kvalitě. Pro potřeby sponzora projektu je vhodné vytvořit zde nástroj, kam budou projektoví manaţeři vyplňovat stav průběhu projektu ze svého pohledu. Je to zejména uţitečné, pokud se projekt dostává do potíţí a je třeba nějakého rozhodnutí. Toto zde bude jednoduše zaevidováno a sponzor projektu nemusí být zahlcen velkým počtem mailů, ve kterých bude ţádán o rozhodnutí. Také povaţuji za velmi uţitečné, kdyţ je na tomto úloţišti vedený projektový kalendář, kde jsou vyznačeny důleţité milníky projektu a důleţité schůze. Dalším z velmi přínosných dokumentů je ten, kde jsou evidovány plánované absence všech členů projektového týmu. Tento dokument by měl být sdílen a vyplněn i členy projektového týmu zákazníka, aby byl celkový přehled a podle něj se daly organizovat například schůze. Obzvláště je to důleţité v době hromadných dovolených, jako je například období letních prázdnin.
2.2.6 Školení Projektová kancelář má také na starosti proškolení jednotlivých členů projektových týmů a jejich seznámení s procesy a praktikami uţívanými na daném projektu. U velkých projektů, které trvají několik měsíců nebo třeba i let je celkem samozřejmé, ţe dochází k obměnám pracovníků na jednotlivých postech. Pokud je do projektového týmu přijat nový pracovník, doporučuji, aby byl členy projektové kanceláře proškolen. Pokud je přijat nový projektový manaţer, je toto naprosto nutné. Zkušený projektový manaţer samozřejmě ví, co je řízení změn, řízení rizik a tak dále, ale kaţdý projekt má svá specifika a třeba sponzor projektu vyţaduje výstupy ve specifickém formátu nebo nevyţaduje kompletní proces řízení změn pro interní změny. Toto je potřeba naprosto jasně vysvětlit, aby později nedocházelo k nedorozuměním nebo neshodám, které bude třeba řešit.
22
Také mám zkušenost, ţe je lepší tato školení provádět jednotlivě, pokud moţno tváří v tvář. Na mezinárodním projektu, bohuţel, toto moţné není. Proto je vhodné, aby kaţdý pracovník ve své specializaci vedl proškolování jednotlivě. I v případě kdy na projekt přichází více pracovníků najednou je uţitečné nezvat na školení více lidí najednou. Pokud se takového školení účastní více „nováčků“ najednou, většinou je to jen monolog pracovníka projektové kanceláře a nově příchozí jen poslouchají. Pokud je na školení pracovník sám, většinou se toto změní v dialog, kde jsou diskutovány jednotlivé postupy mnohem detailněji a nový pracovník je porovnává se zkušenostmi z předchozích projektů. Takovéto školení je pak mnohem efektivnější.
23
3 Projektové řízení v průběhu projektu Během projektu je třeba řídit velký počet lidí, řešit mnoho plánovaných i neplánovaných situací, zabývat se riziky, navrhovat a schvalovat změny. O všech těchto činnostech jsem se zmínil v předchozích kapitolách a také jsem zde uvedl, ţe zodpovědnou osobou, která za běh celého projektu zodpovídá je projektový manaţer. Na projektech velkého rozsahu bývá projektových manaţerů více, kaţdý je zodpovědný za svůj sub projekt a všechny činnosti zastřešuje hlavní projektový manaţer, taktéţ nazývaný programový manaţer. Jejich prací se budu zabývat v následujících kapitolách.
3.1 Činnosti projektového manažera V optimálním případě se projektový manaţer věnuje projektu od jeho zahájení aţ do předání veškeré funkcionality zákazníkovi. Takto dokáţe snadněji udrţet kontinuitu prací a má přehled o návaznosti jednotlivých kroků i o důvodech proč byly tyto kroky naplánovány, tak jak byly naplánovány.
3.1.1 Detailní zmapování současného stavu a příprava migrace Jak uţ jsem uvedl výše, tato práce se zabývá projektem na přesunutí aplikací zákazníka z datového centra jednoho dodavatele do datového centra dodavatele jiného. Tento projekt je velkého rozsahu, proto vyţaduje zapojení více projektových manaţerů a programového manaţera. V tomto případě došlo k optimálnímu průběhu prací a programový manaţer byl přizván k projektu ještě před podepsáním smlouvy se zákazníkem. Díky tomu měl šanci účastnit se přípravných prací a průzkumu současného stavu a funkcionality aplikací u prvního dodavatele, kterému smlouva končila. Tím měl velmi dobrý přehled o tom, kolik práce bude potřeba na projektu odvést, kde jsou pro zákazníka kritická místa a kde je hlavní výhoda dodávek nového dodavatele. Tato znalost mu výrazně usnadnila vedení celého projektu a také lépe věděl, jaké pracovníky bude do jednotlivých projektových týmů potřebovat. Hlavní náplní práce programového manaţera tedy bylo sestavení projektového týmu, který bude schopný zajistit široké spektrum prací, které mají být během projektu dodány. 24
Koordinovat činnosti jednotlivých projektových týmů a také komunikovat na nejvyšší úrovni se zákazníkem, podepisovat akceptace dodávek, které jsou výslovně uvedeny ve smlouvě a informovat o průběhu sponzora projektu spolu s vrcholným managementem dodavatele. Jednotliví projektoví manaţeři pak řídili své týmy, koordinovali jejich činnosti a také působili jako komunikační prostředník mezi svým týmem a týmem vykonávající podobnou činnost na straně zákazníka. Zajišťovali komunikaci mezi jednotlivými týmy dodavatele, zejména pokud měly činnosti těchto týmů na sebe navazovat. V rámci své zodpovědnosti na tomto projektu jsem řídil migraci aplikací, které nebyly napojeny na systém SAP a také jejich databázových serverů. Během práce svého týmu jsem musel úzce spolupracovat s týmem, který zajišťoval síťové propojení datového centra a pracovišť zákazníka, dále pak s týmem, který měl na starosti dodávky hardware do datového centra nového dodavatele, s týmem, který má na starosti operační systém serverů a jejich zálohování. Toto byla pouze interní část projektu. Kromě komunikace uvnitř firmy dodavatele, jsem musel zajistit komunikaci se zákazníkem, s původním dodavatelem zákazníka a také třetími stranami. To byli například dodavatelé aplikací nebo firma zajišťující přepravu médií s daty zákazníka. Objem dat byl tak velký, ţe nemohl být poslán po síti a musel být na externím datovém disku fyzicky přepraven z datového centra v Brémách do datového centra ve Frankfurtu nad Mohanem.
3.1.2 Přesunutí HW nebo SW a příprava na cílový stav Během projektu, kterým se zabývá tato práce nedošlo k fyzickému přesunutí hardware z jednoho datového centra do druhého. V datovém centru dodavatele byla vybudována zcela nová infrastruktura, jen pro potřeby zákazníka. Toto přineslo zákazníkovi výhodu nových, výkonnějších serverů a větší kapacity datových úloţišť. V mnou řízené části projektu jsme přesouvali aplikace zákazníka. Některé si vyvinul zákazník sám, jiné byly zakoupeny od třetích stran. Ve smlouvě bylo zakotveno, ţe dojde pouze k přesunutí aplikací nikoli jejich povýšení na novější verze. Tím se bude později zabývat samostatný projekt. Důvodem bylo zúţení rozsahu plánovaných prací a také případné zjednodušení návratu k původnímu fungování aplikací v případě neúspěšného převodu aplikace do nového data centra. 25
Tyto aplikace byly v produkčním reţimu, coţ znamená, ţe zaměstnanci zákazníka s nimi denně pracovali. Proto nebylo moţné datové centrum na nějakou dobu odstavit, převést aplikace do nového datového centra, tam je nainstalovat, otestovat a později spustit. Z tohoto důvodu jsem navrhl rozčlenění aplikací do dvou skupin. V první byly aplikace, které bylo moţné zastavit na část pracovního dne. V druhé skupině byly aplikace tak zvaně kritické, které není moţné zastavit v pracovní době. Od zákazníka jsme zjistili, ţe pro tyto aplikace mají vymezený čas na údrţbu, takţe po předchozím oznámení je moţné je odstavit o víkendu. Zákazník souhlasil s tím, ţe pro migraci vyuţijeme tohoto okna a pracovníci z projektového týmu zákazníka budou své spolupracovníky informovat o termínu odstávek. Ve spolupráci s projektovým týmem zákazníka jsme připravili plán migrací s tím, ţe začneme těmi méně kritickými, jejichţ činnost je moţné ukončit během pracovního dne. Následně pak provedeme migrace aplikací kritických.
3.2 Činnosti projektového týmu Přechod ze současného stavu na stav cílový. Při migraci zákaznických aplikací je nutné pracovat postupně. Není moţné v datovém centru dodavatele vybudovat kompletní infrastrukturu pro zákaznické aplikace pouze na základě úvodního průzkumu současného stavu datového centra. Tento průzkum není nikdy zcela úplný a nelze očekávat, ţe všechno bude v pořádku fungovat. V dostatečném časovém předstihu je nutné zajistit, aby všechny podpůrné týmy připravili potřebnou infrastrukturu. Proto musí projektový manaţer absolvovat řadu schůzek, kde se ujistí, ţe všechny týmy jsou schopné dodat to, co poţaduje a ţe jsou schopné to dodat v odpovídajícím čase. Po vyjasnění konkrétního plánu činností musí projektový manaţer seznámit svůj projektový tým s tímto plánem, rozdělit úkoly s jasnými termíny a zodpovědnostmi jednotlivých členů týmu. Kdyţ byl tento plán projednán v rámci projektového týmu a byl dostatečně detailní, mohl být představen projektovému týmu zákazníka, abychom mohli synchronizovat činnosti potřebné k úspěšnému dodání zadaných úkolů. 26
Jak uţ jsem zmínil výše, v tuto chvíli bylo se zákazníkem dojednáno, ţe řídící činnosti budou komunikovány na úrovni projektových manaţerů, ale detailní technické problémy mohou být řešeny jednotlivými členy projektových týmů dodavatele s technickými pracovníky zákazníka. Z tohoto důvodu měl klient poţadavek, aby členové projektových týmů byli schopni komunikovat v německém jazyce. Schopnost komunikace v německém jazyce jsme v průběhu realizace projektu vyuţili také pro komunikaci s dodavateli aplikací, které zákazník nakoupil. Některé z těchto aplikací byly zakoupeny od menších lokálních firem, kde komunikace v anglickém jazyce nebyla moţná. V takovém případě jsem si vyţádal souhlas zákazníka, ţe s těmito dodavateli můţe komunikovat mnou vybraný pracovník. Zákazník musel v předstihu informovat své dodavatele, aby tito nebyli později překvapeni a byli připraveni poskytnout nezbytné informace. Jako projektový manaţer jsem se se členy svého týmu dohodl, ţe mne mohou s jakýmkoli problémem kontaktovat okamţitě, abychom jej mohli bez prodlevy začít řešit. Zároveň jsem zavedl pravidelné projektové schůzky, kde jsme diskutovali průběh projektu, jak se činnosti shodují s časovým plánem nebo jestli zákazník nepřišel s nějakým dalším poţadavkem. Také jsme zavedli pravidelné schůze se zákazníkem, kde jsme demonstrovali naši připravenost k dodávce nejbliţšího milníku, přednesli naše poţadavky na spolupráci. Účast členů projektového týmu byla na těchto schůzkách variabilní. Podle mého názoru nejsou schůze, kde je například 20 účastků, příliš efektivní. Většina lidí se nedostane ke slovu, někteří pracovníci před takto velkým plénem neradi hovoří a tak podobně. Proto bylo pevně stanoveno, ţe jako povinní účastníci jsou projektový manaţer dodavatele a zákazníka a v případě potřeby jsou přizváni další členové projektových týmů. Tento způsob schůzek ale vyţaduje od projektového manaţera mít vţdy dopředu připravenou podrobnou agendu toho, co má být projednáno a o tomto plánu informovat svoji protistranu na straně zákazníka, aby mohli být na schůzku přizváni ti správní pracovníci. Zde bych rád zmínil, ţe tyto schůze neprobíhají tváří v tvář, ale vzdáleně, pomocí nástrojů, které jsou zmíněny později. Tady se ukázala výhoda virtuálních místností, kde schůze probíhali. Kdyţ zákazník projevil přání v rychlosti projednat bod, který nebyl na programu a bylo potřeba přizvat dalšího člena projektového týmu dodavatele, ten byl schopen se připojit v rámci desítek vteřin. 27
Zákazník se připojoval na tyto schůze z jednací místnosti, kde promítal virtuální místnost na plátno a ke komunikaci vyuţíval telefon s hlasitou reprodukcí. V této místnosti se vţdy sešli předem pozvaní pracovníci. Přizvat dalšího člena jejich projektového týmu a vyčkat jeho fyzického příchodu, trvalo mnohem déle.
3.3 Podpůrné činnosti V této kapitole nemyslím na podpůrné činnosti vykonávané projektovou kanceláří, ale činnosti, které musí být vykonány, aby mohla migrace aplikací a dat úspěšně proběhnout. Pokud to šlo, snaţili jsme se veškerá data přenášet po síti, ale někdy byl jejich objem tak veliký, ţe jsme spočítali, ţe jejich přenos by trval několik dní, coţ nepřipadalo v úvahu. Tato data musela být přenesena da pevném médiu. Pro naše potřeby jsme zvolili NAS1 disk, který se pomocí USB kabelu připojil k serveru. Na první pohled toto vypadá jako jednoduché řešení, ale znamenalo to zapojit do spolupráce pracovníky původního dodavatele, nového dodavatele a také třetí stranu, která zajistí převoz disku z Brém do Frankfurtu nad Mohanem. Kvůli velké vzdálenosti mezi oběma datovými centry probíhala přeprava disku přes noc z pátku na sobotu. Data na disku byla důvěrná, proto byl operační systém disku chráněný heslem. Tím bylo zajištěno, ţe během přepravy nemá nikdo moţnost tato data získat. Heslo bylo samozřejmě zasláno do cílového datového centra elektronicky, odděleně od fyzického disku. Projektový manaţer tedy musel zajistit, ţe bude NAS disk s dostatečným časovým předstihem doručen do datového centra původního dodavatele sluţeb, kde jej převezme zodpovědný pracovník. Technik zde bude připraven nakopírovat data na disk a později jej předá přepravní firmě. Ta zajistí doručení disku do nového datového centra, kde opět bude čekat pracovník, který jej převezme, připojí ho k serveru a předá informaci, ţe kopírování dat na cílové místo můţe začít. Později, v průběhu migrací byl projektový manaţer dodavatele centrálním bodem, kde se sbíhaly všechny informace o provedených činnostech, případně řešil vzniklé komplikace.
1
NAS - Network Attached Storage - datové úloţiště, které je připojené k síti. NAS úloţiště je disk, nebo více disků v serveru, který má vlastní operační systém a můţe být snadno připojen k serveru.
28
Proto musel mít kontaktní matici, kde bylo uvedeno telefonické spojení a mailové adresy na všechny zúčastněné pracovníky a eskalační body.
29
4 Ukončení projektu Po úspěšném provedení všech migrací a všech souvisejících činností mohlo být zahájeno oficiální ukončování projektu. Po kaţdé migraci je nutné dodat akceptační protokol, kde je jasně uvedeno a odpovědným pracovníkem zákazníka podepsáno, ţe aplikace z nové lokality běţí a splňují všechny poţadované parametry, jako například dostupnost nebo dobu odezvy. V tuto chvíli byl informován původní dodavatel, ţe činnost aplikací z jejich serverů je ukončena a aplikace mohou být vypnuty. Jakmile byly všechny akceptační protokoly dodány do projektové kanceláře, projekt mohl být ukončen. To znamená, ţe hlavní projektový manaţer se fyzicky sešel s manaţerem zákazníka a společně podepsali dokument o ukončení projektu.
4.1 Předání do ověřovacího provozu Předání aplikací do ověřovacího provozu znamená, ţe aplikace běţí z nového datového centra, vykonávají všechny činnosti jak mají. Dozor nad nimi je zvýšený a všechny problémy jsou řešeny okamţitě s vysokou prioritou. Help desk je instruován, ţe v případě jakýchkoli problémů kontaktuje tým, který měl na starosti migraci. Tento tým také musí připravit přenos svých znalostí do týmu, který bude mít na starosti provoz aplikací v rutinním provozu. Tato dokumentace musí obsahovat stručný popis funkcionality aplikace a jejího pouţívání na uţivatelské úrovni. Dále zde musí být detailně popsána technická specifikace dané aplikace a nároky na vyuţití hardware, na kterém běţí. Stejně by zde měly být zdokumentovány nároky na síťový provoz. Velmi důleţitou kapitolou je popis chyb, které během ověřovacího provozu vznikly a jejich řešení. Z toho vzniká znalostní databáze, která později velmi usnadní správu aplikace v rutinním provozu. Toto je velmi důleţitá činnost, která nesmí být za ţádných okolností zanedbána. Technici projektového týmu získali během realizace projektu hluboké znalosti, které musí předat pracovníkům aplikační podpory. Pokud by je tito měli získat během produkčního provozu,
30
omezilo by to běh aplikací. To by mělo určitě negativní dopad na spokojenost zákazníka s poskytovanými sluţbami.
4.2 Rutinní provoz Rutinní provoz je uţ mimo rozsah této práce, proto jej zmíním jen velmi stručně. Po předání aplikace do rutinního provozu nemá projektový tým za tuto aplikaci ţádnou další zodpovědnost. Po předání všech aplikací, které byly součástí projektu, a potvrzení akceptačních protokolů je projekt ukončen. Po ukončení projektu je ukončena i činnost projektového týmu. Kaţdý z členů se začne věnovat jiným činnostem, na dalších projektech, s novými spolupracovníky. Samozřejmě se můţe stát, ţe do projektového týmu byl vybrán pracovník, který normálně pracuje v oddělení, které má na starosti správu aplikací v rutinním provozu. Ten pak má výhodu, ţe tuto aplikaci uţ velmi dobře zná a přináší z projektu velmi cenné zkušenosti. Toto však není pravidlem a velmi často se stane, ţe po ukončení jednoho projektu nastupuje pracovník na projekt další, kde se musí seznámit s naprosto jinou strukturou aplikací.
4.3 Vyhodnocení projektu Po ukončení projektu je nutné provést jeho vyhodnocení. Toto vyhodnocení je dobré učinit co nejdříve, pokud jsou členové týmů ještě pohromadě a nejsou pohlceni jiným projektem. Z vyhodnocení lze získat mnoho velmi cenných informací, které mohou být vyuţity na dalších projektech a zvýšit kvalitu dodávaných sluţeb. Vyhodnocení je nutné rozdělit do jednotlivých kapitol, které jsou zaměřeny na části projektu jako jsou finance, lidské zdroje, plánování prací, plánování jednotlivých návazností a konsekvencí. Při vyhodnocení je nutné ve všech kapitolách najít to, co bylo v rámci projektu provedeno dobře a to, kde je nutné situaci zlepšit. Z dobře zvládnutých situací a akcí se mohou ostatní týmy a projektoví vedoucí poučit, vzít si příklad a tuto zkušenost přenést na jiný, jimi řízený projekt. Situace, které nebyly zvládnuty dobře a vyţadují zlepšení musí být popsány, analyzovány a je vhodné najít řešení, jak by se situace měla pro příště zlepšit. 31
Z těchto údajů je opět nutné vytvořit znalostní databázi, která musí být uloţena na nějakém sdíleném místě, kam má komunita projektových manaţerů přístup a můţe se zde poučit. Jako nutnost povaţuji, aby se těchto vyhodnocení účastnili i pracovníci projektové kanceláře. Tito pracovníci mohou být zapojeni do více projektů najednou nebo po ukončení konkrétního projektu přejdou na jiný a mohou pracovat s jiným projektovým manaţerem, kterému můţe být znalost úspěchů nebo neúspěchů z jiného projektu uţitečná.
32
5 Komunikace uvnitř mezinárodního týmu Projekt řešený v této diplomové práci byl mezinárodní, a jak uţ jsem uvedl, účastnili se jej v mém týmu pracovníci dodavatele sídlící v Německu, Polsku, České republice a na Slovensku. Projektový tým zákazníka celý sídlil v Německu, ale prováděné práce měly dopad i na jeho pobočky v různých zemí Evropy, ale i v Austrálii. Z výše uvedeného vyplývá, ţe komunikace nebyla vůbec jednoduchá a také došlo k tomu, ţe někteří spolupracovníci se po celou dobu projektu nikdy fyzicky nesetkali.
5.1 Pracovní setkání tváří v tvář V dnešní době, která se zaměřuje na sniţování nákladů ve všech oblastech, je velmi těţké prosadit investici do pracovního setkání, které je spojeno s cestováním pracovníků a jejich ubytováním v místě tohoto setkání. Při plánování rozpočtu na projekt jsem přesto zahrnul cestovní náklady do těchto plánů, jelikoţ osobní setkání, přes všechny moţnosti moderních komunikačních technologií, povaţuji za nenahraditelné.
5.1.1 Workshopy se zákazníkem Za naprosto nenahraditelné povaţuji úvodní pracovní setkání – workshop – po podpisu smlouvy, kdy je projekt zahájen. Tohoto setkání by se měli účastnit řídící pracovníci projektu ze strany dodavatele i zákazníka. Zde se, kromě jiného, dohodnou základní pravidla vzájemné komunikace a připraví se komunikační matice, kam obě strany uvedou telefonní čísla a emailové adresy, na kterých jsou k zastiţení. Tento workshop bývá velmi oficiální, zvláště proto, ţe mnozí účastníci se zde vidí poprvé, ale jak jsem uvedl, je naprosto nutný. I proto, ţe po osobním setkání si při další komunikaci lépe kaţdý představí s kým komunikuje a tato komunikace je pak efektivnější. Z mého pohledu je velmi efektivní setkání projektových týmů dodavatele a zákazníka, které spolu budou na projektu spolupracovat. Tito lidé spolu bývají, i přes velkou vzdálenost jejich pracovišť, ve velmi častém kontaktu, někdy i na denní bázi. Z vlastní zkušenosti mohu uvést, 33
ţe i kdyţ s někým pracuji a komunikuji například po telefonu, je tato osoba pro mě stále jen jakýmsi hlasem v telefonu. Po osobním setkání se způsob komunikace v naprosté většině případů velmi změní a lidé spolu komunikují mnohem vstřícněji. Další výhodou osobního setkání je větší interaktivnost. Pokud prezentuji nějaké informace pomocí virtuální místnosti (bude popsáno v kapitole 5.2.2), nemohu si nikdy být jistý, jak pozorně moji prezentaci posluchači sledují, ale také nemohu číst z jejich výrazů ve tvářích, jak moc mé prezentaci rozumí. Toto se týká i diskuze nad technickými specifikacemi aplikací. Pokud jsou tyto informace vzdáleně prezentovány, vzniká mezi zúčastněnými stranami podvědomý odstup. Pokud jsou dva technici vedle sebe nad jedním terminálem, tato bariéra velmi rychle odpadne a pracovníci se mnohem lépe koncentrují na diskutovaný problém.
5.1.2 Interní setkání projektového týmu Jak uţ jsem uvedl výše, v současné době prosadit náklady na cestování a ubytování pracovníků je velmi sloţité a setkává se odmítáním managementu firem. Já s tímto přístupem nesouhlasím a vţdy usiluji o to, aby alespoň k jednomu fyzickému setkání všech interních členů projektového týmu došlo. Podobně jako u setkání s pracovníky zákazníka i při tomto setkání dojde k podvědomému prolomení komunikačních bariér mezi členy týmu. Na základě zkušeností z různých projektů vím, ţe po takovém setkání začne tým mezi sebou komunikovat mnohem ochotněji a efektivněji a také jsou členové projektového týmu mnohem loajálnější ke svému projektovému manaţerovi. Na vztazích uvnitř projektového týmu, se pozitivně projeví, pokud porady nejsou striktně zaměřeny jen na pracovní témata. Pokud se porada uvede krátkou debatou, kde se diskutuje něco z mimopracovního ţivota, pomůţe to uvolnění atmosféry. Lidé v týmu si začnou být bliţší a vzdálení pracovníci se více stmelí do týmu.
34
5.2 Pracovní porady ze vzdálených pracovišť U projektových týmů, které sídlí v různých lokalitách a různých státech, se pracovním poradám, které jsou vedeny vzdáleně bohuţel nedá vyhnout. Současné informační a komunikační technologie pro to nabízejí řadu prostředků. Já zde popíšu jen ty, s kterými jsem se osobně setkal.
5.2.1 Konferenční telefonáty Nejčastějším způsobem, kterým jsou vedeny vzdálené porady je vyuţití konferenčních linek. Tento nástroj je poskytován dodavatelem, jako podpora činnosti jeho zaměstnanců. Ti jej mohou vyuţívat pro organizování konferenčních telefonních hovorů mezi zaměstnanci dodavatele, ale i externími pracovníky a klienty. Linky jsou zřízeny téměř po celém světě. Kaţdý kdo je přizván, aby se zúčastnil konferenčního hovoru můţe volat na místní telefonní linku a šetřit tak náklady za mezinárodní hovory. Konferenčního hovoru se můţe tedy zúčastnit skoro kaţdý člověk na světě. Jen v zemích, které nemají zcela demokratický reţim, jako je například Čína, existuje omezení, ţe ke konferenčnímu hovoru se mohou účastníci připojit pouze z předem definovaných linek. Převáţně zavedených do kanceláří dodavatele, působících v těchto zemích. Maximální počet účastníků konferenčního hovoru je omezen na 250. Otevřít linku nebo lépe konferenční místnost však mohou pouze zaměstnanci dodavatele. Ti se nejprve musí registrovat na intranetových stránkách dodavatele, po úspěšné registraci obdrţí na pracovní emailovou adresu unikátní identifikační číslo své konferenční místnosti a šestimístný PIN kód, kterým tuto místnost musí před kaţdým konferenčním hovorem otevřít. Pokud tedy organizuji nějakou schůzku, musím svým kolegům poslat ID své konferenční místnosti. Kdyţ organizuji konferenční hovor, kam jsou přizváni i pracovníci zákazníka, musím jim poskytnout i lokální číslo, které je platné pro jejich zemi. Po zavolání na tuto linku, jsou volající vyzváni k zadání ID konferenční místnosti a poţádání o sdělení svého jména, kterým budou v místnosti představeni. Jelikoţ je tato linka mezinárodní, komunikace je v anglickém jazyce. Organizátor konferenčního hovoru je po zadání ID místnosti vyzván k zadání svého PINu, aby byla místnost otevřena. Vlastník místnosti má řadu moţností, jak chování virtuální 35
místnosti upravit. Například je moţné vypnout oznamování jména toho, kdo se do místnosti přihlásil. Další z moţností je ztlumení linek všech účastníků konferenčního hovoru, kromě vedoucího. Obě tyto moţnosti se vyuţívají zejména při velkých prezentacích, na které se připojuje několik desítek pracovníků a prezentující si nepřeje být vyrušován. Výše jsem uvedl maximální počet účastníků konferenčního hovoru, proto musím zmínit, ţe je zde i limit na minimální počet účastníků a ten je stanoven na 3. Pokud se na hovor, který je plánovaný pro více účastníků připojí pouze dva, jsou tito po pěti minutách vyzvání k ukončení hovoru, jelikoţ počet účastníků nedosáhl minimálního poţadovaného počtu. V případě, ţe v konferenčním hovoru pokračují, je tento po dvou minutách automaticky ukončen.
5.2.2 Virtuální místnosti Výše popsané konferenční místnosti jsou sice velice uţitečné pro komunikaci projektového týmu, ale poskytují moţnost pouze hlasové komunikace. To ve většině případů schůzek projektového týmu nebo řídících schůzí nestačí. Často je potřeba otevřít nějaký dokument, časový plán, tabulku úkolů a tak podobně a je nutné, aby kaţdý účastník porady měl moţnost do tohoto dokumentu nahlíţet. Někteří kolegové volí moţnost, ţe dokument pošlou všem účastníkům porady emailem, před zahájením projektové schůze a kaţdý si pak otevře lokální kopii na svém počítači. Nad těmito kopiemi porada probíhá a kaţdý si dělá své vlastní poznámky. Toto řešení nepovaţuji za optimální, protoţe můţe vést k roztříštěnosti a nejasnostem v zadání úkolů nebo dohodnutých bodech a akčních plánech. Proto pouţívám na svých poradách tak zvané virtuální místnosti. Tyto místnosti jsou přístupné přes webové rozhraní. Podobně jako v případě konferenčních místností jsou i tyto virtuální místnosti připraveny dodavatelem pro potřeby jeho zaměstnanců, ale mohou být přístupné i externím pracovníkům a klientům. Jelikoţ se tento nástroj ukázal být velmi uţitečný a zákazníky oceňovaný, je moţné si jej v současné době zakoupit. Lépe řečeno, za měsíční poplatek si pronajmout virtuální místnost a podporu virtuálních schůzí, jako například, ţe během porady je vše, co je zde prezentováno,
36
nahráváno. Funkcionalitu těchto místností však podrobně neznám, jelikoţ jsem ji nikdy nevyuţil. Vţdy jsem sem přistupoval přes svůj zaměstnanecký přístup. Zaměstnanec dodavatele, podobně jako u konferenční linky, musí provést registraci a tím je mu zpřístupněna jeho virtuální místnost. Do této místnosti se přihlašuje pomocí uţivatelského jména a hesla. Těm, koho chce na schůzi ve virtuální místnosti přizvat musí zaslat URL 2 adresu, pomocí které se do příslušné místnosti přihlásí. Do těchto místností jsou dva způsoby přihlášení, tedy spíš přidělení práv vlastníkem místnosti. Buď je přizvaná osoba oprávněna se přihlásit jako prezentující nebo jako účastník. Účastník má právo dění v místnosti pouze sledovat. Má však moţnost přihlásit se o slovo stisknutím ikony znázorňující ruku. Ta se zobrazí vedle jména účastníka jednání a prezentující ví, ţe se někdo hlásí o slovo. Prezentující má práva širší. Pokud se rozhodne zde ukázat prezentaci vyrobenou v programu Microsoft Power Point, můţe jí do místnosti nahrát a pak při jejím přednášení ostatním účastníkům lze pouţít nástroje, jako ukazovátko, zvýrazňovač nebo pomocí myši psát. Pokud je třeba účastníkům představit jiné typy dokumentů, je moţné ve virtuální místnosti sdílet určenou aplikaci nebo i celou pracovní plochu počítače. Toto pouţívám zejména v situacích, kdy se diskutuje technické řešení nebo časový plán. V části obrazovky je prezentace a v další mám otevřený textový editor, kam zapisuji připomínky účastníků porady a dohodnuté body. Kaţdý tak hned vidí, co jsem do zápisu z jednání poznamenal, zda jeho připomínka byla zaznamenána správně a hlavně kaţdý vidí napsané to, na čem jsme se usnesli, takţe to nemůţe později zpochybňovat. Další z uţitečných vlastností je předání práva řízení počítače některému z účastníků porady. Tím prezentující umoţní, ţe vybraný pracovník můţe vykonávat činnosti na jeho počítači. Tato moţnost je nejvíce uţitečná při technických poradách, kdy můţe zkušenější pracovník snadno ukázat jak například ovládat nějakou aplikaci.
2
URL, celým názvem Uniform Resource Locator („jednotný lokátor zdrojů“) je řetězec znaků s definovanou strukturou, který slouţí k přesné specifikaci umístění zdrojů informací (ve smyslu dokument nebo sluţba) na Internetu.
37
Nevýhodou sdílené celé pracovní plochy je, ţe všichni zúčastnění, tedy i zaměstnanci zákazníka, kteří se porady účastní, vidí všechny dokumenty, které mohu mít zrovna otevřené. Některé z nich mohou být interního charakteru. Proto je dobré si před zahájením takovéto porady vše pečlivě zkontrolovat, případně interní dokumenty raději zavřít. Ještě nebezpečnější je, pokud prezentující po konci porady zapomene, ţe sdílí svoji pracovní plochu s ostatními pracovníky, kteří virtuální místnost neopustí a mohou sledovat, co prezentující dále dělá. Je znám případ, kdy si prezentující neodpustil v interním komunikátoru (kapitola 5.2.3) nelichotivou poznámku na adresu pracovníka klienta, který však ještě byl přítomen ve virtuální místnosti a tuto poznámku si přečetl. Toto rozhodně neprospělo k vzájemným vztahům a projektový manaţer musel tuto situaci řešit, jelikoţ postiţený pracovník si oficiálně stěţoval. Proto je dobré na konci porady všechny účastníky z virtuální místnost vyřadit. Tuto moţnost má pouze vlastník místnosti.
5.2.3 Interní komunikátor K rychlé komunikaci mezi interními pracovníky dodavatele pouţíváme Microsoft Office komunikátor. Je to rychlý textový komunikátor, jehoţ hlavní výhodu spatřuji v grafickém znázornění toho, zda mohu kolegu vyrušit – v takovém případě má vedle svého jména zelené znamení, pokud je zaneprázdněn, je toto znamení červené. Pokud si nepřeje být rušen můţe si nastavit vedle svého jména značku podobnou dopravní značce „Zákaz vjezdu do jednosměrné ulice“. Kdyţ pracovník není delší dobu u svého počítače, je toto znamení ţluté, pokud má počítač nebo komunikátor, vypnutý je toto znamení šedivé. Oproti klasické mailové komunikaci má pouţití komunikátoru tu výhodu, ţe hned vidím, jestli kolegu mohu rušit, případně, ţe nemá cenu očekávat rychlou odpověď, protoţe není u svého počítače. Tento komunikátor je napojen na mailového klienta Microsoft Outlook a jeho adresář. Díky tomu má přístup ke všem firemním kontaktům a proto je snadné nalézt spojení na pracovníka, s kterým se potřebuji spojit. V komunikátoru je moţné nastavit, zda se mají komunikace ukládat. V případě, ţe tuto funkci povolím, jsou veškeré zprávy uloţeny do vyhrazené sloţky v Outlooku. Pokud se k nim potřebuji později vrátit, není problém je vyhledat.
38
5.2.4 Sdílená úložiště I kdyţ se nedá tvrdit, ţe sdílené úloţiště je nástrojem pro komunikaci při pracovních poradách, je jej nutné také zmínit. Projektový manaţer, ve spolupráci s projektovou kanceláří zde vytváří různé sloţky pro všechny typy dokumentů, které při práci na projektu vznikají. Mezi těmito sloţkami rozhodně poţaduji za nutné mít sloţku pro zápisy z porad a ukládání prezentací, které byly během porad spolupracovníkům představeny. Samozřejmě nestačí pouze vytvořit sloţku, ale je nutné ji také plnit poţadovanými dokumenty. Proto zde musí být uloţeny zápisy z kaţdé porady a všechny prezentace. Pak není nutné dokumenty posílat všem účastníkům projektové porady, ale pošlu pouze odkaz na dokument. Tím není zbytečně čerpána kapacita schránky jednotlivých pracovníků a tito se také vţdy dostanou k nejaktuálnější verzi dokumentu. Na projektech s účastí třetích stran, ať uţ klienta nebo externího dodavatele je vhodné sdílené úloţiště rozdělit na interní a externí a pomocí přístupových práv definovat která skupina dokumentů je přístupná pro koho. Toto je popsáno v kapitole 2.2.5.
39
6 Příklad využití metodiky na konkrétním projektu Správně řízený projekt, zvláště projekt velkého rozsahu jako je popisovaný v této práci, je projekt vedený podle nějaké metodiky. Ta zajistí, ţe během realizace projektu nevzniká chaos, ale všechny kroky mají svůj řád a smysl.
6.1 Zavedení metodiky Jak jsem uvedl v kapitole 1.1, je moţné vyuţít z několika druhů metodik, které jsou pro řízení projektů vypracovány a také pouţívány. Na tomto projektu byla pouţita metodika PMP, jelikoţ tato metodika je v dodavatelské firmě zavedena jako standard. S překvapením jsem v průběhu řízení projektu zjistil, ţe zákazník není zvyklý pro řízení svých projektů metodiku pouţívat, některé termíny mu nejsou jasné a nerozuměl tomu, proč trvám na jejich dodrţování. Jako příklad mohu uvést anglický termín baseline – coţ mohu přeloţit jako základní plán projektu. Zákazník povaţoval za dostačující, ţe máme v kontraktu definované datum zahájení projektu a datum jeho ukončení. To pro něj znamenalo, ţe jasně ví, kdy má projekt skončit a další termíny není třeba stanovovat. Baseline je plán, s jasně stanovenými mezníky. Je pouţíván k hodnocení průběhu projektu. Zde mohou být definovány cíle projektu, načasování, náklady a měření kvality. Na některých projektech zde můţe být uvedeno i plánované vyuţití lidských zdrojů nebo technické výkonnosti. Projekt, který se odchýlí od tohoto plánu musí vyhodnotit rizika, která tato odchylka přináší. Baseline můţe být změněn pouze změnovým poţadavkem, který schválí sponzor projektu. Proto jsem mu musel vysvětlit, ţe vést projekt bez tohoto plánu není moţné. Mohli bychom zjistit, ţe týden před plánovaným ukončením zbývá řada úkolů, které nejsou vyřešené a jejich řešení bude trvat delší dobu, neţ kterou do konce projektu ještě máme. Přesně jak doporučuje metodika, jsme si projekt rozdělili na řadu postupných kroků, s jasně definovanými milníky, které je třeba kontrolovat a stanovit, zda jsou tyto milníky hotové včas nebo jsme s jejich plněním zpoţděni. 40
6.2 Dodržování metodických postupů Naštěstí nebylo pro zákazníka těţké pochopit jaké výhody tento způsob vedení projektu přináší a rychle jsme se na tomto postupu dohodli. Představil jsem mu jednoduchý způsob vyhodnocení, jak průběh projektu sledujeme. Vyuţívá se tak zvaný „Color coding“, tedy hodnocení projektu barvami. Pokud jsou všechny milníky a sledované výstupy řádně plněny, jsou v reportu o plnění plánu označeny zeleně. Pokud projektový manaţer nebo pracovník projektového týmu zjistí, ţe sice plnění je zatím dodáváno dle plánu, ale můţe být z jakéhokoli důvodu opoţděno je toto v projektovém reportu označeno ţlutě a pokud je nějaká dodávka opoţděna, je toto v reportu označeno červeně. Ţlutá barva je také vyuţita, pokud byla nějaká část projektu označena červeně, ale řešení se začíná ubírat správným směrem, tak nepřechází rovnou na zelenou, ale opět na ţlutou. Obrázek 3 - Projektový report - využití color codingu
Zdroj: Vlastní tvorba autora Projekt, který probíhá podle plánu je tedy reportován jako zelený a kaţdý kdo se na projektový report podívá, hned ví, ţe je všechno v pořádku. U ţlutých dodávek ví, ţe se něco děje a u červených je jasné, ţe je na ně třeba se zaměřit se zvýšeným úsilím.
41
Toto úsilí je podle metodiky nazýváno „G2G plan“ podle anglického termínu „Go to Green plan“. Během řízení tohoto projektu jsem musel G2G vytvořit. Znamená to vytvoření velmi detailního plánu činností pro všechny členy projektového týmu a tento plán je sledován na denní bázi. V praxi to znamenalo, ţe jsem naplánoval na kaţdý den pro projektový tým menší úkoly a kaţdý pracovní den jsme zahájili poradou projektového týmu, kde jsme nejprve prodiskutovali, zda za uplynulý den bylo dosaţeno poţadovaného pokroku a stanovili si cíle na další den. Z mého pohledu má tento způsob dva efekty. První, jsou jasně definované úkoly na kaţdý den, pokud se je nedaří plnit, je toto zjištěno hned den následující a můţe být téměř okamţitě zjednána náprava, v případě potřeby můţe dojít k okamţité eskalaci problému. Dalším efektem je efekt psychologický. Osobně neznám ţádného pracovníka, který by měl rád denní porady se svým nadřízeným, který bude kontrolovat práci za uplynulý den a dávat úkoly na den další. Proto se kaţdý snaţí odevzdat maximum, aby se situace vrátila k normálu a porady nebyly tak časté. Ač se tento plán netýkal pracovníků zákazníka a řešil naši interní dodávku, která byla v prodlení, představil jsem jej své protistraně u zákazníka. Bylo to v rámci naší pravidelné porady. Velice jej potěšilo, ţe jsme se k problému postavili tímto způsobem a ocenil profesionální přístup k řešení problému. G2G plán nemusí znamenat jen detailní plánování a denní porady. Můţe zde být například zahrnuto navýšení počtu členů projektového týmu nebo uţší zapojení pracovníků z jiného týmu s odborností nebo rolí, která běţně nebyla v konkrétním projektovém týmu vyţadována. Záleţí na typu problému a způsobu jeho řešení.
6.3 Nestandardní požadavek zákazníka V průběhu realizace projektu na migraci aplikací se ukázalo, ţe během přípravy projektu a smlouvy došlo k opomenutí části aplikací, které zákazník pouţívá. Jednalo se o aplikace, které si zákazník sám vyvinul, proto nebyly podloţeny ţádnými fakturami ani kontrakty s dodavateli. Zřejmě proto nebyly do obsahu projektu zahrnuty. Problémem nebyla velikost nebo sloţitost těchto aplikací, ale jejich mnoţství.
42
Ve chvíli, kdy zákazník zjistil, ţe tyto aplikace nejsou naplánovány v rozsahu ţádného projektu, obvinil nás jako dodavatelskou firmu z chyby. Zejména pak mě, jako projektového manaţera řídícího migraci aplikací, z nedostatečné přípravy projektového plánu a špatného řízení projektu. Byl jsem si jistý, ţe moje příprava byla přesně dle zadání, které jsem při zahájení projektu dostal, proto jsem problém okamţitě eskaloval k programovému manaţerovi. Metodika je samozřejmě připravena i na takovou situaci -
my jsme tento poţadavek
vyhodnotili jako Non Standard Service Request a zahájili NSSR proces. Zjednodušeně by se dal popsat podobně jako G2G plán zmíněný v kapitole 6.2. Tentokrát se však nejednalo o schůze projektových týmů, ale porady na úrovni projektových manaţerů a sponzorů projektu, jak ze strany dodavatele, tak ze strany zákazníka. Jako první bod jsme si ujasnili, ţe tyto aplikace nespadají do rozsahu dodávek stanovených ve smlouvě. Ve chvíli kdy sponzor projektu klienta potvrdil, ţe i on smlouvu chápe stejně, proto je rozsah projektu rozšířit, otevřel se prostor k věcnému jednání. My, jako dodavatelská firma, jsme samozřejmě chtěli zákazníkovi nabídnout co nejlepší sluţby a pomoci mu přesunout všechny aplikace ze starého datového centra do našeho. Zváţili jsme všechny dopady tohoto rozšíření a nakonec jsme souhlasili, ţe bude vytvořen dodatek ke smlouvě a přesunutí aplikací zajistíme. Dále bylo rozhodnuto, ţe tyto aplikace budou přiřazeny do mnou řízeného projektu. Tím se mi rozsah rozšířil o 114 aplikací, běţících na 13 virtuálních serverech.
6.4 Změnové řízení Metodika PMP jasně říká, ţe takováto změna v projektu musí být ošetřena pomocí změnového řízení. Jednalo se o externí poţadavek na změnu, proto musel být schválen i zákazníkem, coţ v tomto případě nebyl problém, jelikoţ se jednalo o změnu v jeho zájmu. Ve své praxi jsem se setkal se zákazníkem, který byl zvyklý své projekty řídit dle metodiky. Takový zákazník by podal návrh na změnové řízení sám, ale jak jsem uvedl výše, současný zákazník nebyl zvyklý na svých projektech takto postupovat, proto jsem v zájmu urychlení činností připravil poţadavek na změnu sám.
43
Poţadavek byl poměrně obsáhlý, protoţe jsem musel změnit původní rozsah projektu, přijmout do projektového týmu odborníka na virtuální servery, změnit časový plán projektu a navýšit jeho rozpočet. Nejvýznamnější dopad tato změna měla na časový plán projektu, jelikoţ většinu z těchto aplikací bylo moţné migrovat pouze mimo pracovní dobu zákazníka. V souladu s metodikou, jsem provedl analýzu poţadavků zákazníka a jejich technickou náročnost. Na následujícím workshopu jsme aplikace rozdělili do skupin, které mohly být migrovány společně. Výstupem byl plán na 5 víkendových migrací a dvě migrace během pracovního týdne. Jak říkají metodiky, a dá se říct, ţe velí selský rozum, k tomuto odhadu jsem přidal ještě dva další víkendy jako rezervu, pro případ, ţe bychom potřebovali čas navíc. Tuto rezervu jsme nakonec beze zbytku vyuţili, kvůli chybám zaviněným externí firmou, která zajišťovala transport NAS disků z jedné lokality do druhé.
6.5 Akceptace Po kaţdé úspěšné migraci jsem vypracoval Akceptační protokol, který musel být podepsán zákazníkem. Opět je to krok, který je uvedený v metodických postupech, ale pro mě znamenal hlavně to, ţe zákazník souhlasí s provedenou změnou. V protokolu jsem uváděl jména aplikací, označení serverů, na které byly přesunuty a ţe zákazník provedl akceptační testy. Tento poslední bod je velmi podstatný, protoţe znamená, ţe ve chvíli předání jsou aplikace funkční. Tato funkcionalita je zákazníkem ověřena a projekt se jimi nemusí dále zabývat. Tento dokument byl podepsán mnou a mojí protistranou na straně zákazníka. Při ukončení celého projektu projektová kancelář vytvořila ještě celkový akceptační protokol, který stvrzoval, ţe všechny dodávky v rámci projektu byly dodány a zákazník je akceptoval. Tento celkový akceptační protokol byl podepsán sponzory projektu, ze strany dodavatele i ze strany zákazníka. Protokoly shromaţďují pracovníci projektové kanceláře, zajišťují jejich archivaci jak v papírové, tak elektronické formě. Kdyţ je plně akceptován a ukončen některý ze sub projektů, projektová kancelář provede off-boarding – uvolnění pracovníků projektového týmu z projektu. Také jejich vyřazení z komunikační matice, například, aby dále nebyli zváni na projektové schůze a nebyli jim zasílány projektové reporty. 44
6.6 Řízení mezinárodního týmu Mezinárodní projektový tým má svá specifika, kterými se liší od týmů lokálních, ale stále je to projektový tým. Proto není nutné, aby existovala speciální metodologie, která by řízení takového týmu popisovala. Plně vyhovuje ta standardní.
6.6.1 Základní pravidla Do projektového týmu by projektový manaţer neměl přijímat zaměstnance podle toho, jaký s nimi má osobní vztah nebo proto, ţe se mu s nimi na minulém projektu dobře pracovalo. Jak uţ jsem uvedl v kapitole 2.1, nejdříve musíme nadefinovat role, které budeme v průběhu realizace projektu potřebovat a teprve následně hledáme konkrétní pracovníky, kterými tyto role obsadíme. Na projektu, který v této práci popisuji, jsem musel do výběrových kritérií na členy projektového týmu zohlednit poţadavek klienta, ţe techničtí pracovníci musí ovládat aktivně němčinu. Jelikoţ pracuji v nadnárodní firmě, bylo nejjednodušší získat pracovníky, kteří pocházejí přímo z Německa. Získal jsem kontakt na liniového manaţera pracovníků s odpovídající kvalifikací a vyţádal si poskytnutí zdrojů. Zde se skrývá riziko, ţe bude do projektového týmu poskytnut pracovník, který není dostatečně kvalifikovaný a liniový manaţer bude rád, ţe pro něj našel nějaké uplatnění. Naštěstí jsem se s tímto problémem osobně nesetkal a všichni pracovníci, které jsem do týmu získal byli dostatečně odborně vybaveni a odváděli výbornou práci. Výše jsem popsal situaci, kdy jsme museli řešit dodatečný poţadavek zákazníka, poměrně velkého rozsahu, navíc v co nejkratším čase. Tentokrát nebylo moţné získat kvalifikovaného pracovníka z Německa v dostatečně krátkém čase, proto jsem pouţil volné kapacity pracovníků, kteří se specializují na virtuální servery, ale sídlí v Bratislavě. Zákazník v tomto případě na jazykové vybavenosti netrval. Pro mě, jako projektového manaţera to mělo více výhod. První a pro projekt nejméně významná - alespoň s jedním členem týmu odpadla jazyková bariéra. Další výhodou bylo, ţe náklady na pracovníka ze Slovenska jsou niţší, neţ na pracovníka z Německa. Největší výhodou pro projekt bylo, ţe pracoviště v Bratislavě je specializované, takţe jsme měli k dispozici nejlepší odborníky, kterými dodavatel disponuje. 45
U dlouhodobých projektů metodiky doporučují vypracovat plán lidských zdrojů. Coţ znamená, ţe projektový manaţer vypracuje přehled kdy, kterou roli bude na projektu potřebovat a kdy ji ze svého projektového týmu uvolní. V tomto plánu by mělo být uvedeno, jestli je potřeba zajistit členům projektového týmu nějaké školení. Zde nemám na mysli jen školení odborná, ale můţe se jednat například o školení ochrany zdraví a bezpečnosti práce. Takovéto školení musí člen týmu absolvovat s předstihem, aby v den jeho plánovaného nástupu byl plně připraven začít vykonávat svoji činnost.
6.6.2 Team building Ačkoli většina IT společností směřuje k vyuţívání vzdálené komunikace a minimalizaci nákladů na cestování svých pracovníků, já osobně s tímto trendem nesouhlasím. Podle mého názoru je osobní kontakt mezi členy projektového týmu nenahraditelný pro vznik kvalitní pracovní atmosféry uvnitř týmu a vznik potřebných sociálních vazeb. Hlavním cílem team buildingu je vybudovat důvěru mezi jednotlivými členy projektového týmu a také důvěru ve svého projektového manaţera. Projektový manaţer, který nemá důvěru svého projektového týmu můţe těţko tento tým řídit a dosahovat s ním dobrých výsledků. Proto je potřeba, aby si důvěru snaţil získat od prvního společného setkání. Jelikoţ pracovníci v mém týmu nebyli na projekt přiděleni na 100 % svého pracovního času, neuvaţoval jsem o Team buildingu, který je spojen s nějakou organizovanou mimopracovní aktivitou, jak bývá běţně zvykem. Musel jsem jej omezit na nutné minimum a vyuţil jsem k tomu úvodní workshop u zákazníka. S kolegy z týmu jsme se tedy setkali ve městě, kde sídlí zákazník jiţ odpoledne dne, který předcházel workshopu. Společně jsme si dali neformální večeři, kde jsme se alespoň trochu vzájemně poznali. Následující den jsem tuto příleţitost ocenil, protoţe jsme se vyhnuli situaci, kdy bychom se jako jeden tým pracovníků dodavatele, vzájemně představovali a seznamovali přímo před zraky zákazníka. To by z mého pohledu nepůsobilo profesionálně ani důvěryhodně. Takto jsme předstoupili jako tým, který se zná a nemá ţádný problém mezi sebou komunikovat.
46
6.6.3 Zdroje konfliktů V týmu, který spolu nesídlí na jednom pracovišti a nestýká se na denní bázi, je vznik konfliktů výrazně omezen, jelikoţ vzájemná komunikace je omezena pouze na věcné diskuze k problematice projektu. Je téměř vyloučeno, aby problémy vznikaly na sociální úrovni. Jistá moţnost je, ţe začnou vznikat problémy na úrovni pracovní. K tomu můţe dojít ve chvíli, kdy činnost jednoho pracovníka je úzce závislá na činnosti kolegy z projektového týmu. V případě, ţe ten druhý neplní své úkoly včas nebo v poţadované kvalitě. Proto jsou později na kolegu, který na jeho činnost navazuje, zvýšené nároky aby smazal prodlení, které nezavinil, můţe vzniknout konflikt. Proto je důleţité, aby byla činnost jednotlivých rolí rozplánována co nejdetailněji. Díky tomu se můţe brzy odhalit, ţe pracovník má se svojí dodávkou nějaký problém a ten se můţe začít řešit hned v zárodku. Mnoho projektových manaţerů si myslí, ţe nejčastější příčinou vzniku konfliktů na projektu jsou osobní odlišnosti jednotlivých pracovníků. Překvapivě toto je výjimečně se vyskytující příčina. Podle PMP metodologie jsou nejčastější důvody konfliktu tyto: Harmonogram projektu Projektové priority Zdroje Technické moţnosti Konflikt nemusí být vţdycky špatný. Lépe neţ strávit mnoho času snahou zamezit vzniku konfliktů, je se ze vzniklé situace poučit a vzít ji jako prostor pro zlepšení.
6.6.4 Matice zodpovědností Tuto matici je vhodné sestavit hned při zahájení činnosti projektového týmu. Matice znázorňuje jednoduchým a přehledným způsobem všem členům týmu kdo je za jaký úkol zodpovědný, případně zda se o nějaký úkol spolu dělí. Samozřejmě pomáhá i projektovému manaţerovi k tomu, aby měl přehled o tom, který člen týmu má jakou činnost vykonat nebo v případě nějaké nenadálé události, například onemocnění, kdo je schopen koho zastoupit. Všichni členové projektového týmu musí být s touto maticí seznámeni. 47
Tabulka 1 – Matice zodpovědnosti Úkol
Freidoon P
Člen týnu Mark
Ivan
1 2 S 3 S 4 P Zdroj: PMP exam preparation, vlastní úprava autora
Michal S
P P S
6.6.5 Způsoby vedení Řízení projektu je v první řadě řízení lidí. Proto by měl projektový manaţer zvolit takový styl, který odpovídá potřebám projektu, fázi ve které se projekt nachází a také sloţení projektového týmu. Mezi základní způsoby řízení patří: Direktivní – manaţer nařizuje ostatním co mají dělat Nápomocný – koordinuje členy projektového týmu a jejich názory Koučing – radí ostatním jak postupovat Podpůrný – poskytuje podporu členům týmu Autokratický – vydává rozhodnutí bez studia skutečné situace Konsultační – poţaduje nápady od ostatních Dohoda – rozhodnutí a řešení problémů se odehrává na základě týmové dohody V metodologiích nepanuje jednoznačná shoda, který z přístupů je správný v jednotlivých fázích projektu. Obecně platí, ţe během zahájení činnosti projektového týmu je musí mít manaţer spíše direktivní přístup, protoţe je to on kdo zná v tuto chvíli nejlépe plán projektu a projektové cíle. Během další práce na projektu by měl tým podporovat, konsultovat s jednotlivými členy a pomáhat jim podat co nejlepší výkon. Vedení mezinárodního týmu se od vedení týmu lokálního liší hlavně v tom, ţe jako projektový manaţer nemám moţnost osobního a denního kontaktu s členy svého týmu. V mezinárodním týmu je vyšší pravděpodobnost, ţe můţe dojít k setkání více kultur nebo náboţenství. S tímto problémem jsem se setkal, jelikoţ jeden z členů mého projektového týmu, ač ţil v Německu, měl své kořeny v Turecku. Projekt to nijak zásadním způsobem neovlivnilo, pouze v rámci plánování jsem musel zohlednit jeho poţadavek, ţe v polovině 48
července odjíţdí na měsíc do Turecka za svoji rodinou a jelikoţ na tu dobu spadá některý z místních náboţenských svátků, není moţné s tímto termínem jakkoli hnout. Proto jsem v projektovém plánu musel toto zohlednit a naplánovat pro něj činnosti tak, aby vše dodal před svým odjezdem. Samozřejmě musel tento kolega zajistit svého zástupce, kterému předal maximum informací, aby byl schopen ho nahradit v době jeho nepřítomnosti. Osobně jsem si z toho odnesl poučení, ţe je vhodné se s kaţdým členem projektového týmu, nějakým vhodným způsobem, v rámci vzájemného seznamování, zmínit o moţnosti vzniku časového a pracovního konfliktu u zvyků a svátků, které nejsou v Evropě zcela běţné. Zde opět musím zmínit, ţe v případě osobního setkání s členy svého týmu se moţnost těchto komplikací odhaluje mnohem jednodušeji, neţ po telefonu.
6.6.6 Proces řešení problémů Metodologie říká, ţe nejlepším způsobem řešení problémů je moderovaná konfrontace stran, mezi kterými problém vznikl. V praxi to znamená, ţe si projektový manaţer pozve pracovníky, mezi kterými došlo ke konfliktu. Řídí jejich diskuzi tak, aby byla co nejvíce věcná a co nejméně emotivní. Při této diskuzi je nutné odhalit jádro problému a dohodnout se na krocích, které povedou k jeho řešení a odstranění. Metodologie popisuje tento postup jako konfrontaci. Projektový manaţer musí tento postup sledovat, aby měl jistotu, ţe problém byl zaţehnán. K tomu je vhodné vyuţít win-win strategii. Tedy, ţe se ţádná ze zúčastněných stran necítí poraţená a všichni mají pocit, ţe dosáhli svého. Další z moţných postupů je hledání kompromisu. Při společném setkání se hledá řešení, které přinese alespoň částečné uspokojení zúčastněným stranám. Toto je lose-lose strategie. Ani jedna ze stran konfliktu není plně uspokojena. Z toho vyplývá, ţe to není nejlepší způsob řešení problémů, ale můţe být vyuţit jako alternativa, kdyţ konfrontační postup selţe. U mezinárodního týmu je postup osobního setkání tak finančně nákladný, ţe je prakticky nerealizovatelný. Tím jsou kladeny vyšší nároky na projektového manaţera, aby takový problém zvládl. Vhodným řešením situace je nejdříve si promluvit s kaţdou ze zúčastněných stran odděleně, aby si mohl udělat co nejvíce reálný obraz toho, jak jednotlivé strany problém vnímají a na základě toho mohl objektivně rozhodnout, jak se bude problém řešit. Toto řešení 49
pak představí na telefonní konferenci, kterou musí mezi všemi stranami zorganizovat a moderovat. To, co jsem popsal v předchozích odstavcích se týká situace, kdy vznikne problém mezi dvěma nebo více členy projektového týmu. Můţe nastat i situace, kdy problém vzniká jen u jednoho pracovníka, který nestačí zvládat poţadavky, které jsou na něj kladené, ať uţ z nedostatku odbornosti nebo kvůli mnoţství práce, které musí odevzdat. V optimálním případě by takový pracovník měl kontaktovat svého projektového manaţera, ale ještě jsem nezaţil, ţe by nějaký pracovník za mnou přišel a přiznal se, ţe kvůli nedostatku odbornosti na svoji práci nestačí. Pokud si stěţuje na mnoţství poţadavků, které jsou na pracovníka kladeny, toto se stává poměrně běţně a ne vţdy je tato stíţnost oprávněná. Proto musí dobrý projektový manaţer tyto problémy odhalovat sám a být připraven je řešit. Kdyţ je mnoţství práce na jednoho pracovníka příliš veliké, můţe zkusit některé úkoly předat jinému členovi projektového týmu, pokud on na ně má čas a poţadovanou kvalifikaci. Pokud pracovník nestačí svou odborností a je pravděpodobné, ţe je to moţné napravit konzultací se zkušenějším kolegou, měl by mu ji zajistit. Jestli však vidí, ţe je problém závaţnější, nesmí se bát člena svého projektového týmu vyměnit za zkušenějšího. Zvyšování kvalifikace pracovníků by neměla být starostí projektového manaţera a neměla by být hrazena z rozpočtu projektu. Zvyšování kvalifikace je zodpovědností liniového manaţera, který by měl mít na toto vyhrazené prostředky. Řešení problémů v projektovém týmu je tedy plně v kompetenci projektového manaţera. Pokud nastanou problémy mezi projektovými týmy, musí být řešeny na úrovni projektových manaţerů, nikoli členů projektových týmů. Pokud projektoví manaţeři nemohou dojít ke vzájemné shodě, musí problém eskalovat ke sponzorovi projektu, který má pravomoc o řešení rozhodnout.
6.7 Řízení mezinárodního projektu Jazyková bariéra je největším problémem, který na mezinárodních projektech vyvstává. Během zahájení projektu je nutné stanovit, jaký bude oficiální komunikační jazyk. V tomto jazyce musí být vedena veškerá projektová dokumentace a také smlouva. Pokud existuje více jazykových mutací projektové smlouvy, musí být jasně uvedeno, která jazyková verze je závazná, jelikoţ při překladu smlouvy můţe dojít k chybám nebo nepřesnostem. 50
6.7.1 Sledování dodržení plánu Na kaţdém projektu je nutné sledovat, zda je plán dodrţován nebo jestli se projekt dostává do zpoţdění bez ohledu na to, jestli se jedná o malý projekt v rámci jednoho podniku nebo jestli je to projekt mezinárodní. Kaţdý projektový manaţer musí sledovat plán pro svůj projekt a projektový tým, sponzor projektu a programový manaţer sledují plán pro celý projekt, který můţe být rozdělen do více menších projektů. Se sledováním plánu pomáhá projektová kancelář, která jednotlivé projektové plány ukládá, vede evidenci jednotlivých dodávek a akceptací. Na projektu, který v této práci popisuji, jsme sledování plánu prováděli tím způsobem, ţe zodpovědností kaţdého projektového manaţera bylo vyplnit na sdíleném úloţišti postup projektu za uplynulý týden. Informace musely být vyplněny kaţdý čtvrtek do 13:00. Pokud některý z projektových manaţerů svoji povinnost nesplnil, byl poţádán emailem z projektové kanceláře, aby informace urychleně vyplnil. Tento mail byl poslán v kopii i programovému manaţerovi. Díky tomu působil jako eskalační prvek. Ve čtvrtek odpoledne a v pátek dopoledne zorganizovala projektová kancelář krátké schůze se všemi projektovými manaţery, kde jsme provedli rychlou revizi vyplněných dat, odstranili případné chyby nebo si vyjasnili nejasné body. Následně projektová kancelář připravila celkový report o průběhu projektu, kde byly jasně zobrazeny projekty dodávající včas zeleně, projekty postiţené nějakou komplikací oranţově, projekty se zpoţděním červeně. Více je o tomto způsobu hodnocení uvedeno v kapitole 2.2.4. Kaţdé páteční odpoledne proběhla schůze všech projektových manaţerů, za účasti programového manaţera, případně i sponzora projektu. Zde kaţdý projektový manaţer stručně shrnul postup své části projektu a vyslechl si postup ostatních týmů. Takováto schůze je velmi uţitečná, jednak proto, ţe kaţdý účastník můţe mít celkový přehled o průběhu projektu, ale také proto, ţe si týmy, které spolu mají spolupracovat mohou ve stručnosti prodiskutovat postup spolupráce. Také můţe nastat to, ţe činnost jednoho týmu můţe nepřímo ovlivnit činnost jiného, aniţ by si to projektový manaţer uvědomil a díky interaktivitě této schůze můţe dojít k zamezení kolize. Osobně si myslím, ţe na projektech velkého rozsahu je takovéto setkávání nutné. I kdyţ má velký projekt velmi zkušeného programového manaţera, který se snaţí dohlédnout na 51
všechny souvislosti a vazby mezi týmy, můţe mu nějaká informace uniknout. Případně jí nebude přikládat takový význam, jako projektový manaţer, jehoţ týmu se informace bezprostředně týkají. Speciální pozornost je nutné věnovat projektům, které jdou po tak zvané kritické cestě – z anglického termínu critical path. To znamená, ţe při plnění dodávek byla zvolena nejdelší moţná cesta, například kvůli vazbám na jiné projekty nebo externí dodávky. Jakékoli zdrţení jedné dodávky bude mít za následek zpoţdění celého projektu. Identifikace kritické cesty pomůţe projektovému manaţerovi určit, kterým dodávkám je třeba věnovat mimořádnou pozornost a která událost vyţaduje okamţitou reakci.
6.7.2 Časová rezerva V metodologiích, zabývajících se projektovým řízením je uvedeno, ţe při tvorbě časového plánu průběhu projektu je nutné vytvořit časovou rezervu, která bude pokrývat neočekávané situace, které mohou na projektu nastat. Můţe dojít k onemocnění některého z členů projektového týmu, dodávky se mohou zdrţet kvůli jejich sloţitosti a tak podobně. V metodologii není přesně uvedeno, ţe bychom naplánovaný čas měli vynásobit nějakým konkrétním koeficientem, který nám vypočítá vhodnou časovou rezervu. Tato rezerva se vytváří na základě sloţitosti projektu, jeho vazbám na dodávky ostatních týmů, případně dodávek třetích stran. Jak jsem uvedl výše, při svém plánu dodávek jsem časovou rezervu vytvořenou měl a nakonec jsem jí beze zbytku vyuţil. Dalo by se říct, ţe jsem plánoval efektivně a díky tomu, ţe projekt byl dodán včas, byl můj časový plán i odhad rezervy správný, sám jsem s tímto plánem spokojený nebyl. Ne snad proto, ţe bych chtěl dodat projekt před plánovaným termínem, ale proto, ţe při poslední dodávce muselo všechno proběhnout bez nejmenší chyby a nemohli jsme si dovolit nejmenší zaváhání. To bylo pro členy týmu, včetně mě, stresující. Díky vzniklému stresu se zvýšilo riziko chyb. Z předchozí zkušenosti jsem navíc věděl, ţe mohu mít všechny členy připravené provést jejich činnost ve stanovený čas a v nejlepší moţné kvalitě, přesto můţe zasáhnout třetí strana, která i nejlépe připravený plán víkendové migrace překazí.
52
Konkrétně nastala situace, kdy jsme o přepravu NAS disku s daty a aplikacemi poţádali logistickou firmu. Ta disk v pátek večer na stanoveném místě vyzvedla. V sobotu dopoledne jej měla doručit do datového centra ve Frankfurtu nad Mohanem. Ve 12:00 mi volal technik, ţe na disk stále čeká. Okamţitě jsem zahájil pátrání po důvodu zpoţdění, abych nakonec zjistil, ţe pracovník logistické firmy dal NAS disk do jiného kontejneru, který je v uzamčeném skladu. Tento sklad bude odemčen aţ v pondělí ráno. Přes veškerou snahu se mi nepodařilo zajistit nikoho, kdo by toto změnil a následně jsem musel celou migraci zrušit. V pondělí ráno jsem se musel za vzniklé komplikace zákazníkovi omluvit. Ten poţadoval záruku, ţe se podobná situace nebude opakovat. Tuto záruku jsem mu bohuţel dát nedokázal. Proto jsem problém eskaloval k pracovníkovi, který uzavíral smlouvu s touto logistickou firmou a poţadoval po něm projednání s managementem firmy. Management přislíbil, ţe napříště budou našim zásilkám věnovat zvýšenou pozornost.
6.7.3 Změnové řízení Proces řízení změn na mezinárodním projektu nemá ţádná specifika nebo odlišnosti od projektů lokálních. Za všech okolností je nutné vypracovat poţadavek na změnu, ve kterém bude změna jasně popsána, bude popsán důvod změny a její dopady. Poţadavek na změnu musí být schválen programovým manaţerem nebo sponzorem projektu dodavatele, v případě, ţe má změna dopad na klienta, musí být schválena i z jeho strany. Tento popis zní velmi jasně a jednoduše, ale v praxi jsem se setkal se změnovými řízeními, při kterých byl schvalovací proces ze strany zákazníka provázen velkými průtahy, jako dodavatel jsme museli vypracovat několik verzí poţadavků na změnu a celý tento proces trval několik měsíců. Více jsem o změnovém řízení uvedl v kapitole 6.4.
6.7.4 Změna kontraktu Poţadavek na změnu můţe být někdy takového rozsahu, ţe nestačí, aby byl pokryt standardním změnovým řízením. Změna má dopad i na dříve podepsaný kontrakt. Poţadavek na změnu kontraktu můţe být podán ze strany zákazníka, coţ jsem popsal v kapitole 6.3, častějším případem je, ţe tento poţadavek vychází ze strany dodavatele. Toto se děje v případě, ţe během realizace projektu se ukáţe, ţe poţadavky klienta jsou mnohem vyšší, neţ bylo plánováno a proto nejsou způsobem uvedeným v kontraktu realizovatelné nebo je 53
realizace těchto poţadavků natolik nákladná, ţe nemůţe být pokryta částkou, která je v kontraktu uvedena. Jednání o změně kontraktu, zvláště pak ta, která znamenají pro zákazníka zvýšení částky, kterou musí za dodání projektu zaplatit, bývají velmi sloţitá. Jsou vedena na úrovni sponzora projektu nebo managementu firmy. Proto jsem se jich nikdy přímo neúčastnil. Jako projektový manaţer jsem musel připravit sponzorovi projektu podklady, kde bylo jasně zdůvodněno proč ke změně dochází, jaké dopady má na projekt, jaká rizika vznikají, pokud nebude změna schválena, případně jaké výhody tato změna zákazníkovi přinese.
54
7 Vyhodnocení Na předchozích stranách jsem popsal reálný projekt, kterého jsem se účastnil. Jednalo se o poměrně velký mezinárodní projekt, který se nám podařilo dodat včas, dokonce i v mírně větším rozsahu, neţ bylo původně nasmlouváno. V následujících kapitolách se pokusím popsat, jaké poučení jsem si z projektu odnesl a jaká doporučení na zlepšení bych rád uvedl v praxi na svých dalších projektech.
7.1 Zkušenosti a doporučení Jelikoţ zmiňovaný projekt byl můj první mezinárodní, odnesl jsem si mnoho nových zkušeností. Projekty, kterých jsem se dříve účastnil, byly pouze lokální, ale některé se zapojením externích dodavatelů. Takţe jsem měl základ, ze kterého jsem mohl vycházet, ale v mnoha případech byla metodologie řízení projektu hlavním vodítkem, o které jsem se mohl opřít. Naprosto poprvé jsem zaţil situaci, ţe jsem se nikdy nesetkal se členem svého projektového týmu, který se mnou dva měsíce pracoval. Setkávali jsme se pouze na telefonních konferencích a ve virtuálních místnostech. Takţe vlastně dodnes nevím, jak můj kolega vypadá. Díky úvodnímu workshopu jsem měl moţnost se setkat s celým projektovým týmem zákazníka, který s mým týmem úzce spolupracoval. Za to jsem velmi vděčný, a jak jsem popsal výše, usnadnilo to spolupráci mezi námi a komunikace nebyla po workshopu tak oficiální, jako před ním. Nepříjemným překvapením pro mne bylo, ţe jsem organizoval workshop přibliţně měsíc před ukončením projektu, kde jsem chtěl provést vyhodnocení projektu. Cílem bylo detailně prodiskutovat kroky, které nás čekají a ujistit se, ţe nenastane ještě jednou situace, kdy má zákazník ve svém portfoliu aplikace, které nejsou pokryty ţádným projektem. Tento workshop jsem měl schválený od sponzora projektu, měl jsem na něj v rozpočtu připravené peníze, proto jsem o svém plánu informoval zákazníka, který byl touto myšlenkou překvapen. Později jsem vypracoval plán workshopu, s tématy, která hodlám diskutovat a proč. Ze strany 55
dodavatele projevil i sponzor projektu zájem se zúčastnit, ale k našemu překvapení nám zákazník oznámil, ţe k tomuto setkání nevidí důvod a nemá na něj čas.
7.1.1 Výhody a nevýhody mezinárodních projektových týmů Hlavní výhodou, kterou mají přinášet mezinárodní projektové týmy je úspora finančních nákladů. Některé činnosti mohou mezinárodní korporace přesunout ze zemí s draţší pracovní silou do zemí levnějších. Coţ je například výše zmíněný tým, který má na starosti instalaci a podporu virtuálních serverů, který sídlí v Bratislavě a instaluje virtuální servery ve všech datových centrech naší společnosti. Jako další příklad mohu uvést sebe samotného. Projektový manaţer z České republiky jistě stojí v nákladech naši společnost méně, neţ stejně zkušený projektový manaţer z Německa. Podobné je to i s programátory, kteří nyní sídlí převáţně v Indii a ve velkých společnostech programátorský tým, který by sídlil v některé ze zemí západní Evropy, prakticky není moţné najít. Výhodou také je, ţe není nutné drţet v kaţdé zemi odborníky na celé spektrum sluţeb, které naše firma dodává. Zejména činnosti, které nevyţadují přímou interakci se zákazníkem jsou přesouvány do zemí s levnější pracovní silou, za které jsme stále povaţováni i my v České republice a na Slovensku. Pro mne osobně vidím výhodu vzniku mezinárodních projektových týmů v tom, ţe se mohu účastnit projektů, ke kterým bych se v České republice neměl šanci nikdy dostat. Takto sbírám pracovní zkušenosti ze spolupráce s kolegy z různých zemí Evropy. Mohu se účastnit projektů, jejichţ rozsah přesahuje moţnosti projektů v rámci České republiky a zcela přirozeně tím prohlubuji i své jazykové znalosti. Zde bych rád zmínil ještě jednu výhodu vzdáleně řízeného týmu. Ale hned v úvodu musím říct, ţe osobně si nejsem jistý, jestli kromě finanční úspory pro zaměstnavatele, má toto nějaký pozitivní dopad na projekt. Jedná se trend, který některé firmy v posledních letech zavádějí a to je práce z domova. Je pravda, ţe pokud má projektový manaţer svůj projektový tým rozmístěný v různých městech nebo i zemích, odpadá bezprostřední nutnost dojíţdět na pracoviště. Telefonovat, a pokud zaměstnavatel umoţňuje vzdálené připojení, posílat pracovní maily můţe i z domova. Tím ušetří čas za dojíţdění do práce a můţe se věnovat 56
svému projektu. Zaměstnavatel ušetří náklady na zřízení pracovního místa, ale na druhou stranu takový pracovník přichází o sociální kontakt se svými kolegy. O moţnost bezprostředně diskutovat různé pracovní situace třeba i se zkušenějším kolegou nebo svým manaţerem. Pracovník, kterému je umoţněno pracovat z domova, musí projevit velkou dávku sebekázně, aby se věnoval opravdu pracovním činnostem a nerozptyloval se jinými aktivitami, ke kterým můţe pobyt doma, i kdyţ v pracovní době, svádět. Nevýhod práce v mezinárodních projektových týmech vidím několik a pokusím se na příkladech uvést, ţe ona deklarovaná úspora nákladů není vţdy tak efektivní, jako se na první pohled zdá. Vrátím se k příkladu s instalací virtuálních serverů. Máme na to odborníky sídlící v Bratislavě, proto je jako levnější pracovní sílu mohu vyuţít. Ale datový disk, ze kterého se aplikace instalují, je logistickou společností přepraven přímo do datového centra ve Frankfurtu nad Mohanem. Jak jsem zmínil, některé migrace probíhaly o víkendu a disk byl do datového centra doručen v sobotu dopoledne. V takovém případě to pro mne jako projektového manaţer znamená, ţe musím zajistit odborníka z týmu v Bratislavě a dále technika ve Frankfurtu, který disk převezme, zajistí jeho fyzické připojení ke správnému serveru a otestuje, ţe vše správně funguje. Pak předá zprávu do Bratislavy. Tím výhoda úspory na pracovníka z levnější lokality odpadá. Myslím si, ţe toto je ale extrémní případ, v drtivé většině pracovních situací ke zdvojování pracovních rolí nedochází. Mezi závaţnější negativa práce ve vzdálených mezinárodních týmech jsou sociální dopady, které tato skutečnost přináší. Z týmů se ztrácí vazby mezi jednotlivými pracovníky a ke vzniku týmu jako takového, tedy skupiny lidí, kteří se společnými silami snaţí dosáhnout nějakého cíle vlastně ani nedojde. Existuje jakási skupina jednotlivců, kteří pracují na společném úkolu, bez společného cítění a snahy si navzájem pomáhat a motivovat se ke společnému výkonu. Pro takovéto pracovníky je vţdy týmem skupina lidí, se kterými sdílí jednu kancelář nebo v současné době spíše mají pracovní místa poblíţ sebe v open-space, ale nemusí mít společný ţádný pracovní úkol. Skutečný projektový tým je pro ně jen pár hlasů v telefonu. Pro posílení sociálních vazeb v mezinárodním týmu jednoznačně doporučuji uspořádat společný team building nebo pracovní workshop. Pokud to není moţné, měl by projektový manaţer připravit schůzku, na kterou si vyţádá od všech členů projektového týmu jejich 57
fotografie, na nichţ budou všichni zachyceni v neformálních situacích. S rodinou, při sportu, na dovolené nebo tak podobně. Kaţdý z členů o sobě řekne pár slov a tím se představí i z jiné, neţ pracovní stránky. Pokud je projekt dlouhodobý, doporučuji takovouto neformální schůzku udělat vícekrát. Z osobní zkušenosti mohu potvrdit, ţe takováto schůzka i kdyţ není na osobní úrovni, týmu pomůţe. Další nevýhodou práce ze vzdálených lokalit je ztráta kreativity z pracovních jednání. Pokud je vedeno jednání, kde jsou všichni členové projektového týmu v jedné místnosti, stává se, ţe člen týmu, který není přímo zainteresován do diskutované problematiky, přijde s myšlenkou, která díky jeho pohledu jakoby z venku, můţe posunout řešení tím správným směrem. Nebo dá nový impuls diskuzi a problém se tím vyřeší. Při jednání tváří v tvář je takové jednání méně formální a pro kaţdého ze zúčastněných je jednodušší se zapojit a přispět svoji myšlenkou. A to ať váţně míněnou nebo i míněnou v legraci, pro pročištění atmosféry během jednání. Pokud je takovéto jednání vedeno vzdáleně, pouze po telefonu je příspěvek do diskuze sloţitější. Mnoho lidí má zvyk a někteří projektoví vedoucí to i vyţadují, aby ten kdo právě nemluví, vypnul mikrofon svého telefonu, kvůli zamezení neţádoucích zvuků z okolí jednotlivých pracovníků. Tím je interaktivita významně omezena. Protoţe to co by některý z členů týmu na společné poradě jen tak prohodil, vůbec nezazní, jelikoţ je to spojeno s nutností zapnutí mikrofonu svého telefonu. Proto si to mnoho pracovníků rozmyslí a svojí myšlenkou do diskuze nepřispějí. Na svých jednáních jsem proto raději, pokud mají všichni členové týmu mikrofony svých telefonů zapnuté a jsou připraveni do diskuze kdykoli přispět. Při vypnutých mikrofonech se často stává, ţe některý z pracovníků začne mluvit, ale zapomene, ţe není pro ostatní slyšet. Pokud se jedná o interní jednání, není to zvláštní problém, pokud je pracovník tázán, tak ho upozorníme, ţe není slyšet, ale je to nepříjemné při jednáních se zákazníkem, který můţe nabýt dojmu, ţe neumíme pracovat s komunikačním nástrojem, který jsme k vedení jednání sami, jako dodavatel doporučili. Dalším z nedostatků vzdáleně vedených jednání je, ţe dochází ke ztrátě efektu brainstormingu3. Při lokálně vedené projektové schůzi se tým sejde v jedné zasedací místnosti a tam probírá dané téma, bez toho, aby do jednání kdokoli vstupoval. Tím jsou všichni soustředění na dané téma, přispívají na základě podnětů ostatních kolegů. Zde není podstatná
3
Brainstorming – volně přeloţeno do češtiny jako „burza nápadů“
58
kvalita jednotlivých nápadů, ale jejich mnoţství. Kvalitu nápadů nikdo bezprostředně nehodnotí. Proto je vhodné, aby zde vládla přátelská a uvolněná atmosféra, aby se odhodlal do diskuse přispět opravdu kaţdý člen projektového týmu. Tuto atmosféru je při jednáních, vedených vzdáleně, velmi těţké, ne-li nemoţné vyvolat. I při lokálním brainstormingu je obtíţné některé pracovníky přimět k soustředění a příspěvkům, protoţe mají pocit, ţe kdyţ jejich příspěvek není hodnocen, nemusí se snaţit. To, ţe se účastní jednání pouze po telefonu, několik set kilometrů daleko od svého projektového manaţera tento pocit ještě posiluje. Tabulka 2 - Shrnutí výhod a nevýhod mezinárodního týmu Mezinárodní tým Výhody
Nevýhody
Finanční úspora
Sociální dopady
Neduplikují se odbornosti
Ztráta kreativity
Možnost práce z domova
Odpadá efekt brainstormingu Jazyková bariéra
Zdroj: Vlastní tvorba autora
7.1.2 Porovnání úspory nákladů a času versus efektivita Jak jsem uvedl v předchozí kapitole, k vytváření mezinárodních projektových týmů vede snaha o úsporu nákladů dodavatelských společností. Z mého pohledu je však tato úspora mnohem menší, neţ se na první pohled zdá. Například přijmeme projektového manaţera z levnější země – tím ušetříme v přímých nákladech na tuto osobu. Ale naproti tomu, tento projektový manaţer není rodilý mluvčí ze země zákazníka. Proto vzniká jazyková bariéra při komunikaci a také jsou vyšší náklady na jeho cesty k zákazníkovi. Tím trpí vzájemný vztah mezi zúčastněnými stranami. Pokud by projektový manaţer mohl zákazníka navštěvovat častěji, coţ by jistě prospělo práci na současném projektu, mohl by lépe poznat prostředí ve firmě, kam projekt dodává a rozpoznat příleţitosti na další návazné projekty. Mezinárodní vedení projektu nepřispívá k navazujícím obchodním příleţitostem. Pokud zákazník zástupce svého dodavatele dobře zná a je s ním v pravidelném osobním kontaktu, 59
bude u dalších obchodních příleţitostí velice pravděpodobně volit stejného dodavatele. Díky zkušenosti z přímého kontaktu můţe poměrně přesně odhadnout, jak bude další spolupráce probíhat. Pokud je pro zákazníka dodavatel jen jakýsi hlas v telefonu, který navíc nemluví dobře jeho rodnou řečí, nebude mít problém si na další projekt zvolit dodavatele jiného. Z tohoto pohledu je jasné, ţe finanční úspora na jednom konkrétním projektu můţe být velkou ztrátou pro navazující obchodní moţnosti. Dalším diskutabilním bodem je časové hledisko. Můţeme říct, ţe díky řízení projektu na dálku odpadá cestování projektového manaţera ze svého pracoviště za zákazníkem a zpátky. Připraví podklady, ty přes virtuální místnost zákazníkovi prezentuje a po skončení jednání můţe téměř okamţitě pokračovat ve své práci. Jenţe při tomto přístupu se pracovní diskuze většinou omezují jen na jeden konkrétní problém. Ale pokud se sejdou lidé tváří v tvář, vyuţívají čas mnohem efektivněji a otevírají i témata, která na programu jednání původně nebyla, ale oni cítí, ţe je potřeba se jim věnovat. Osobně jsem zaţil mnohokrát situaci, kdy jsem opouštěl sídlo zákazníka a u výtahu nebo po cestě jsme ještě stihli prodiskutovat několik bodů, které nebyly v plánu, protoţe je pracovníci zákazníka nepovaţovali za podstatné, ale při neformální diskuzi se rozhodli je otevřít a nakonec se ukázalo, ţe jsou pro projekt velmi důleţité. V metodice se uvádí, ţe 55% vzájemné komunikace mezi lidmi probíhá neverbální cestou. Při komunikaci přes telefonické konferenční místnosti tedy přicházíme o nadpoloviční většinu informací, které bychom získali při osobním kontaktu se zákazníkem.
60
Tabulka 3 - Porovnání výhod a nevýhod mezinárodního řízení projektu Mezinárodní řízení projektu Výhody Levnější pracovní zdroje
Nevýhody Jazyková bariéra Chybí osobní kontakt Omezená možnost nalezení dalších obchodních příležitostí
Úspora času
Cílená jednání bez osobní interakce Nemožnost neoficiální diskuze
Úspora cestovních nákladů
Nevznikají sociální vazby Nekonkrétní dodavatelsko-odběratelské vztahy
Zdroj: Vlastní tvorba autora
7.1.3 Shrnutí výsledků Projekt, který je tématem této práce, byl úspěšný. Měřítkem úspěšnosti je podle metodiky to, ţe jsme dodali vše, co bylo uvedeno ve smlouvě a dokonce ještě něco navíc. Dodávky proběhly včas a v poţadované kvalitě. To znamená, ţe aplikace byly pro pracovníky zákazníka dostupné, bez časové prodlevy a mohl s nimi bez omezení pracovat. Klient provedl veškeré akceptační testy a podepsal akceptační protokoly. Tím jsou splněna měřitelná kritéria úspěchu projektu. Mé subjektivní pocity nejsou tak pozitivní, jak by mohlo z předchozího odstavce vypadat. Můţu být spokojený, ţe jsme spolu s projektovým týmem splnili to, co se od nás očekávalo. Na druhou stranu mne mrzí, ţe dnem podepsání akceptačních protokolů tento projektový tým ukončil svoji činnost a je dost málo pravděpodobné, ţe bychom se v budoucnu potkali na dalším projektu, i kdyţ všichni stále pracujeme u stejného zaměstnavatele. Věřím tomu, ţe tento tým by mohl být zákazníkovi prospěšný i v dalších činnostech a mohl by přispět k větší efektivitě jeho ICT4. Bohuţel velké vzdálenosti mezi námi a pouze oficiální vazby mezi pracovními týmy nenabízejí další kooperaci.
4
ICT – Information and Communications Technology – informační a komunikační technologie
61
Myslím si, ţe pokud by stejnou zakázku dodával lokální tým, který by měl sídlo v blízkosti zákazníka, a všichni zúčastnění pracovníci hovořili stejným rodným jazykem, byla by spolupráce mnohem těsnější a také dlouhodobější. Pokud odhlédnu od přínosů pro dodavatelskou firmu a zaměřím se na výhody, které tento projekt přinesl mě osobně, tak musím přiznat, ţe to byla jedinečná příleţitost zapojit se do projektu mezinárodního rozsahu a sbírat zkušenosti na mezinárodním pracovním poli. Takto velkých projektů se v rámci České republiky mnoho nevyskytuje, proto jsou takto získané zkušenosti pro mne nenahraditelné a věřím tomu, ţe je mohu ve své další kariéře zúročit.
7.1.4 Doporučení Budování mezinárodních projektových týmů má jistě svoji budoucnost a nadnárodním korporacím přináší nemalou úsporu nákladů. Projekty, které mohou být nasmlouvány s niţší marţí, jelikoţ je moţné role v týmech obsadit pracovníky ze zemí s levnější pracovní silou. Tím se zvyšuje moţnost zisku z takového projektu, který je nabídnut za niţší cenu. Ale narůstá riziko komplikací, kvůli jazykové bariéře a menším zkušenostem takových pracovníků. Pro zdárný průběh projektů a případné vyuţití dalších obchodních příleţitostí, které můţe projektový manaţer u zákazníka odhalit rozhodně doporučuji, aby pracovníci, kteří připravují podklady ke smlouvě nebo manaţeři, kteří jsou v častém kontaktu se zákazníkem, byli schopní komunikovat v rodném jazyce zákazníka. U členů projektového týmu uţ není nutné na jazykovém vybavení trvat, protoţe nejsou s pracovníky zákazníka v častém kontaktu a pokud spolu musí být v kontaktu, většinou řeší odborné věci, kde jsou termíny mezinárodní, ţe si porozumí velice dobře i pokud budou nuceni pouţívat jazyk, který jim není úplně vlastní.
7.1.5 Komunikační nástroje Komunikačním nástrojům, které při mezinárodních projektech můţeme pouţívat jsem se podrobně věnoval v kapitole 5.1. Zde popíšu svůj názor na tyto moţnosti a také odhad dalšího vývoje těchto nástrojů v budoucnosti. 62
Konferenční místnosti (viz kapitola 5.2.1) jsou velmi uţitečným nástrojem, který umoţňuje spojení členů projektových týmů dodavatele i zákazníka při vynaloţení minimálních nákladů. Mnoţství lidí není v těchto místnostech limitováno, respektive je limitováno počtem 250 účastníků, coţ je pro projektové porady více neţ dostačující. Významnou nevýhodou těchto místností je to, ţe přenášejí pouze hlas, proto jsou neosobní a často se stane, ţe někteří účastníci konferenčního hovoru vůbec netuší, kdo k nim právě promlouvá a tak jeho příspěvku nevěnují pozornost. Přes jejich nespornou výhodu pro úsporu nákladů, si myslím, ţe tento nástroj bude muset být nástrojem, který bude schopen kromě zvuku přenášet i obraz. Non-verbální komunikace je nedílnou součástí vyjadřování a proto bychom ji neměli z pracovních jednání vylučovat. Virtuální místnosti (viz kapitola 5.2.2) jsou nástroj, bez kterého si vzdálené řízení projektu a pracovní porady se zákazníkem vůbec neumím představit. Poskytují moţnost vzdáleně pracovat nad stejným dokumentem nebo prezentovat informace klientovi. Uţití jsem se věnoval v předcházejících kapitolách. Výše zmíněné komunikační prostředky jsou bez diskuze velmi uţitečné a pro projektové manaţery jsou dobrým pomocníkem. Podle mého názoru jim však stále chybí moţnost sledovat ostatní účastníky porady, řeč jejich těla nebo mimiku. Proto si myslím, ţe pokud tento styl řízení projektů bude i v budoucnu pokračovat, lze očekávat přechod k video konferencím. Myslím si, ţe videokonference budou zřejmě mít v počátku celou řadu odpůrců, protoţe lidé se většinou neradi vidí na obrazovce, ale aţ se počáteční ostych překoná, budou velmi uţitečným pomocníkem. Při interních poradách projektový manaţer lépe uvidí, kdo z členů jeho týmu se aktivně účastní diskuze, snaţí se přispět ke společnému cíli a kdo sedí v pozadí a porady se příliš neúčastní. Při jednáních se zákazníkem video konference určitě pomůţe k navázání uţších vztahů mezi pracovníky dodavatele a zákazníka, podle mě i vybudování větší důvěry mezi pracovníky, kteří jinak mají velmi omezenou moţnost se setkat. Většímu rozšíření video konferencí dosud bránila cena vybavení a rychlost internetového připojení. To se v současné době hodně změnilo, kamera pro video hovor a mikrofon je ve 63
standardní výbavě většiny pracovních notebooků. Jiţ jsem viděl i software, který umoţňuje propojení obrazů z více videokamer do jednoho společného video hovoru, takţe si myslím, ţe se v brzké době dočkáme posunu tímto směrem a osobně to velice vítám. Abych své názory na současný způsob řízení mezinárodního projektu a odhady budoucího vývoje podpořil, připravil jsem krátký dotazník s pěti otázkami. Rozeslal jej mezi své kolegy, v České republice a pro porovnání jsem jej poslal i kolegům v zahraničí. Dotazník je detailně popsán v příloze této práce s názvem: „Dotazník řízení mezinárodního projektu“ Otázky zněly: 1. Přináší vzdálené řízení projektu úsporu nákladů? 2. Má vzdálené řízení dopad na spokojenost zákazníka? 3. Povaţujete za nutnost provést úvodní workshop u zákazníka? 4. Jaký je váš názor na vyuţití virtuálních místností?
5. Jaký je váš názor na vyuţití video konferencí? Mezi kolegy i mnou panuje shoda v tom, ţe vzdálené řízení projektů přináší významnou úsporu nákladů, ale jazyková bariéra má negativní dopad na spokojenost zákazníka. 86% respondentů uvedlo, ţe úvodní workshop má zásadní vliv na úspěšnost spolupráce. 100% shoda panovala v otázce vyuţívání virtuálních místnost. Všichni dotázaní je, stejně jako já, povaţují za naprostou nutnost. 64% respondentů povaţují zavedení video konferencí jako správný směr vývoje vzdálené komunikace. Grafické znázornění odpovědí je uvedeno v příloze této práce.
64
Závěr Ve své práci jsem popsal zkušenosti z řízení mezinárodního projektu a mezinárodního projektového týmu. Tento způsob práce se stává trendem v nadnárodních společnostech během posledních let. Důvodem ke vzniku takových týmů je úspora nákladů dodavatelských organizací. Na tomto projektu jsem pracoval jako projektový manaţer, zodpovědný za migraci aplikací klienta. Ty byly přesouvány z datového centra v Brémách do datového centra ve Frankfurtu nad Mohanem. Pro úspěšné řízení takovýchto projektů je nutné vyuţít metodologii, která je pro řízení projektů
vypracovaná.
Poskytuje
projektovému
manaţerovi
vedení
v podobě
standardizovaných kroků, které vedou k úspěšnému dodání projektu včas a kvalitně.
Mezinárodní projekt Z předchozích kapitol vyplývá, ţe zaměstnávání pracovníků ze zemí s levnější pracovní silou můţe na první pohled vypadat ekonomicky výhodně. Můţe se ale odrazit v menších zkušenostech takového pracovníka s řízením velkých projektů a také se můţe setkat s nelibostí zákazníka. Pokud projektový manaţer, s kterým má primárně vést jednání o stavu projektu, neumí hovořit jeho rodnou řečí vzniká zde jazyková bariéra, která všechny zúčastněné svazuje a ti se necítí na projektových jednáních dobře. Zde mohu uvést příklad z praxe. Byl jsem přítomen na projektové schůzi a dostali jsme se k poměrně detailní diskuzi mezi členy projektových týmů dodavatele a zákazníka o funkčnosti některých aplikací, jejich technických nárocích a poţadavcích na infrastrukturu. Poznal jsem, ţe diskuze začíná váznout, techničtí odborníci měli zájem vést diskuzi, ale necítili se dostatečně silní v anglickém jazyce. Proto jsem jim nabídl, ať technické detaily vyřeší v jejich rodné Němčině, kde budu schopen většině technických termínů rozumět a jim to usnadní jednání. Následně mi pak předají stručné shrnutí, jak problém vyřešili. Atmosféra na jednání se výrazně zlepšila, techničtí pracovníci rychle nalezli shodu a my jsme se mohli posunout k dalším bodům jednání. 65
Takto se dá postupovat v případě projednávání technických detailů, ale nikoli při vyjednávání kontraktu, dodatku ke smlouvě nebo o podobných administrativních tématech. Jazyková bariéra při řízení mezinárodních projektů bude vţdy rizikovým faktorem, který bude ovlivňovat efektivitu práce a hlavně manaţerských činností. Proto by měl management nadnárodních společností zváţit, zda se úspora na pozicích projektových manaţerů, obchodních zástupců nebo sponzora projektu opravdu vyplácí. Podle mého názoru nikoli a pracovník, který pravidelně jedná se zákazníkem, kdyţ uţ není rodilý mluvčí, měl by znát jazyk zákazníka na takové úrovni, aby tímto jazykem mohl se zákazníkem jednat.
Mezinárodní projektový tým V projektovém týmu, sloţeném z pracovníků z různých zemí jsem se nikdy s výraznou jazykovou bariérou nesetkal. Pravděpodobně je to tím, ţe zaměstnanci organizace zaměřující se na ICT mají k angličtině velmi blízko a jsou zvyklí ji pouţívat. Odstranění jazykové bariéry velmi pomůţe, pokud projektový manaţer má zkušenost s technologií, kterou má ve svém projektu dodávat. Pokud má zkušenosti například s databázemi a bude mu přidělen projekt, který má za úkol posílení databázových serverů, bude se v něm snadno orientovat. Brzy najde s odborníky na databáze jazyk, který ostatním nemusí být úplně srozumitelný, kvůli záplavě odborných termínů, ale projektový tým bude schopen efektivně vykonávat svoji činnost. Z mého pohledu můţe být mezinárodní projektový tým efektivní. Při vhodné volbě projektového manaţera, který se bude orientovat v problematice, kterou se projekt zabývá, nevidím konkrétní problém, který by měl činnost projektového týmu omezovat.
Odhad vývoje do budoucna V předchozích kapitolách jsem popsal, ţe velké vzdálenosti mezi členy týmu a nemoţnost jejich osobního setkávání na pracovních poradách můţe nepříznivě ovlivňovat řešení pracovních problémů ale i konfliktů.
66
Na trhu se jiţ objevují technologie, které se snaţí toto odbourat. Myslím si, ţe doba, kdy budeme schopni vést vzdálené porady tak, ţe se na monitorech svých počítačů s účastníky jednání v reálném čase uvidíme je blízko. Zatím tomu bránila nedostatečná rychlost datového připojení a vysoká cena hardwarového vybavení. HW pro pořádání video hovorů je dnes jiţ téměř standardem všech pracovních notebooků. Rychlost datového připojení také přestává být překáţkou. Na rozšíření tohoto způsobu komunikace se těším. Myslím si, ţe přinese větší míru lidskosti do tohoto způsobu řízení projektů a do vzájemné komunikace se opět vrátí i mimoverbální komunikace. Další z moţností vývoje je, ţe se velké dodavatelské ICT firmy poučí například z vývoje komunikace bank. Ty hromadně rušily své pobočky a chtěly komunikovat převáţně po internetu. Časem se ukázalo, ţe klientům moţnost osobního kontaktu chybí. Proto by mohlo dojít i v ICT firmách k poznání, ţe osobní kontakt s klientem je nenahraditelný a budeme se k němu postupně vracet.
67
Seznam použité literatury 1. DOLEŢAL, Jan, Pavel MÁCHAL a Branislav LACKO. Projektový management podle IPMA. 2., aktualiz. a dopl. vyd. Praha: Grada, 2012, 526 s. Expert (Grada). ISBN 978-80-247-4275-5.
2. KOMZÁK, Tomáš, Pavel MÁCHAL a Branislav LACKO. Řízení IT projektů pro úplné začátečníky. 1. vyd. Brno: Computer Press, 2013, 213 s. Pro úplné začátečníky. ISBN 978-80-251-3791-8.
3. MULCAHY, Rita,. PMP Exam Prep: accelerated learning to pass PMI's PMP exam - on your first try! ; [Rita's course in a book for passing the PMP exam]. 5. ed., 4. pr. Burnsville: RMC Publ, 2005, 323 s. Pro úplné začátečníky. ISBN 19-327-3500-3.
4. ROSINSKI, Philippe, Pavel MÁCHAL a Branislav LACKO. Koučování v multikulturním prostředí: nové nástroje využití národních, firemních a profesních odlišností. Vyd. 1. Praha: Management Press, 2009, 323 s. Pro úplné začátečníky. ISBN 978-80-7261-195-9.
Elektronické zdroje 1. LUKEŠ, Pavel. Datová úložiště pro domácnosti a malé firmy. Praha, 2013. Bakalářská práce. Bankovní Institut Vysoká Škola. Vedoucí práce Růţička Bohuslav. 2. Ing. ŠEBEK, Václav CSC. Projektové řízení: Učební materiály. Praha, 2012.
3. Uniform Resource Locator. In: CS Wikipedia [online]. 2013 [cit. 2013-04-12]. Dostupné z: http://cs.wikipedia.org/wiki/Uniform_Resource_Locator
68
Seznam použitých obrázků Obrázek 1 - Projektový plán ..................................................................................................... 11 Obrázek 2 - Přehled stavu dodávek jednotlivých sub projektů ................................................ 20 Obrázek 3 - Projektový report - využití color codingu ............................................................. 41
69
Seznam použitých tabulek Tabulka 1 – Matice zodpovědnosti ........................................................................................... 48 Tabulka 2 - Shrnutí výhod a nevýhod mezinárodního týmu ..................................................... 59 Tabulka 3 - Porovnání výhod a nevýhod mezinárodního řízení projektu................................. 61
70
Seznam zkratek G2G – Go to Green plan, plán na zefektivnění činností na zpoţděném projektu, aby byl co nejdříve s souladu s časovým plánem HW – hardware – pevné součásti výpočetní techniky, jako počítače, notebooky, servery ICT – Information and Communication Technology – Informační a komunikační technologie ID – Identification, jednoznačné identifikační označení uţivatele MS – Microsoft software NAS - Network Attached Storage - datové úloţiště, které je připojené k síti. NSSR – Non Standard Service Reques – nestandardní poţadavek v průběhu projektu PDF – Portable Document Format – přenosný formát dokumentů PIN – Personal Identification Number – osobní identifikační číslo PM – Projektový Manaţer PMI – Project Management Istitute – jedna z nejvýznamnějších světových institucí, zabývající se projektovým managementem a certifikací projektových manaţerů PMP – Project Management Professional, certifikace pro projektové manaţery SAP – z německého „Systeme, Anwendungen, Produkte in der Datenverarbeitung“ – software zabývající se účetnictvím, plánováním lidských zdrojů a vztahů se zákazníkem SW – software – aplikační vybavení a operační systém výpočetní techniky URL – Uniform Resource Locator, adresa internetové stránky USB – Universal Serial Bus je univerzální sériová sběrnice, moderní způsob připojení periferií k počítači.
71
Přílohy
Příloha č.1
Dotazník Řízení mezinárodního projektu
72
Grafické vyjádření odpovědí:
73
