Implementace projektového managementu

Bankovní institut vysoká škola Praha Katedra financí a ekonomie

Implementace projektového managementu Diplomová práce

Autor:

Jiří Chramosta finance

Vedoucí práce:

Praha

Ing. Petr Vaškovic

2016

2

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 30. 4. 2016

Jiří Chramosta

3

Poděkování: Touto cestou bych rád poděkoval vedoucímu své diplomové práce panu Ing. Petru Vaškovici za odborné a vstřícné vedení při zpracování této práce a pánům Ing. Janu Kousalovi a Ing. Lukáši Kadlecovi za konzultace a poskytnuté materiály.

4

Anotace: Diplomová práce se věnuje implementaci projektového řízení do liniových struktur reálné organizace. Na průběhu skutečného projektu vývoje informačního systému je popsána zvolená metodika zavedení projektového řízení.

Klíčová slova: projekt, agilní metodika, řízení projektu, vedoucí projektu, penzijní společnost

Annotation: This thesis was aimed at the implementation of project management into the linear structures of a real organization. The selected methodology of the implementation of project management is described using the course of an actual project of information system development.

Key words: project, agile methodologies, project management, project manager, pension company

5

Obsah: Úvod ................................................................................................................................................... 8 1.

2.

3.

Penzijní společnost ..................................................................................................................... 9 1.1.

Penzijní spoření .................................................................................................................. 9

1.2.

Penzijní společnost ........................................................................................................... 10

1.3.

Organizační struktura penzijní společnosti ...................................................................... 12

1.4.

Implementace nového informačního systému .................................................................. 16

1.5.

Cíle práce ......................................................................................................................... 17

Teorie projektového řízení ....................................................................................................... 18 2.1.

Projekt .............................................................................................................................. 18

2.2.

Metodiky řízení projektů .................................................................................................. 19

2.3.

Rigorózní (tradiční) metodiky .......................................................................................... 20

2.3.1.

Zahájení/iniciace projektu ........................................................................................ 21

2.3.2.

Plánování projektu.................................................................................................... 22

2.3.3.

Realizace, implementace, kontroling a monitoring .................................................. 24

2.3.4.

Uzavření, předání ..................................................................................................... 26

2.4.

Organizace projektu ......................................................................................................... 26

2.5.

Sponzor projektu .............................................................................................................. 28

2.6.

Projektový manaţer .......................................................................................................... 29

2.6.1.

Šéf (převládající manaţerské a řídící dovednosti).................................................... 31

2.6.2.

Odborník (převládající věcné odborné zázemí). ...................................................... 31

2.6.3.

Úředník (převládající administrace a techniky). ...................................................... 31

2.6.4.

Obchodník (převládající prezentační a komunikační dovednosti). .......................... 32

2.6.5.

Tahoun (převládající motivace, flexibilita, empatie). .............................................. 32

2.6.6.

Etický kodex projektového manaţera ...................................................................... 33

2.7.

Projektový tým ................................................................................................................. 34

2.8.

Agilní metodiky................................................................................................................ 36

2.9.

Metodika Scrum ............................................................................................................... 38

2.9.1.

Ţivotní cyklus ........................................................................................................... 40

2.9.2.

Scrum tým ................................................................................................................ 44

2.9.3.

Vlastník produktu ..................................................................................................... 44

2.9.4.

Vývojový tým ........................................................................................................... 45

2.9.5.

Scrum master ............................................................................................................ 45

Projekt výměny informačního systému .................................................................................... 47 3.1.

Zvolená metodika řízení projektu..................................................................................... 47 6

4.

3.1.1.

Zahájení projektu implementace nového informačního systému ............................. 49

3.1.2.

Plán projektu „Nový ISPS“ ...................................................................................... 51

3.1.3.

Realizace projektu .................................................................................................... 55

Analýza řízení projektu ............................................................................................................ 61 4.1.

5.

Identifikace a důsledky chyb v řízení projektu ................................................................ 61

4.1.1.

Projektový tým na straně Penzijní společnosti ......................................................... 61

4.1.2.

Projektový tým na straně dodavatele........................................................................ 63

4.1.3.

Výběr dodavatele...................................................................................................... 64

4.2.

Vyhodnocení činnosti projektového manaţera ................................................................ 66

4.3.

Vyhodnocení časového harmonogramu projektu ............................................................. 67

4.4.

Porovnání projektu s metodikou Scrum ........................................................................... 68

4.5.

Vyhodnocení úspěšnosti implementace projektového řízení ........................................... 70

Závěr ........................................................................................................................................ 71 5.1.

Cíle práce a jejich naplnění .............................................................................................. 71

7

Úvod Tato diplomová práce se věnuje uvedení projektového řízení do praxe v penzijní společnosti v souvislosti s projektem implementace nového informačního systému. První část práce seznamuje s Penzijní společností, objasňuje důvody změny způsobu řízení společnosti a definuje cíle, kterých by autor práce chtěl dosáhnout. Druhá část práce je zaměřena na teoretickou část oblasti projektového managementu. Popisuje nejen druhy metodiky projektového řízení, ale věnuje se i charakteristikám úloh jednotlivých členů projektového týmu. Ve třetí části se autor práce zaměřuje na samotný projekt výměny informačního systému a s ním spojenou implementaci projektového řízení do struktur liniového řízení. Tato část vymezuje časový harmonogram projektu, popisuje skladbu reálného projektového týmu, zvolenou metodiku řízení projektu a definuje ukončení projektu výměny informačního systému. Čtvrtá část se věnuje rozboru chyb v řízení projektu a jejich negativním dopadům na celkový výsledek projektu. Dále dochází k vyhodnocení činnosti projektového manaţera, zvolené metodiky řízení projektu a celkové vyhodnocení úspěšnosti nasazení projektového řízení do praxe. Poslední část provádí sumarizaci naplnění cílů práce a pojmenovává očekávané přínosy práce.

8

1. Penzijní společnost 1.1. Penzijní spoření Události v Československé republice v roce 1989 nastartovaly mnoho změn ve společnosti a vyţádaly si i změny v oblasti sociálního pojištění. Nově se v závěru roku 1994 pro širokou veřejnost objevila moţnost dobrovolného spoření na stáří za významné podpory státu prostřednictvím poskytovaných státních příspěvků. Snahou státu bylo motivovat občany k převzetí zodpovědnosti za svojí finanční situace a zabezpečení na stáří po jejich ekonomicky aktivní části ţivota. Nový finanční produkt, který vstoupil na trh, byl upraven zákonem číslo 42/1994 Sb., o penzijním připojištění se státním příspěvkem a o změnách některých zákonů souvisejících s jeho zavedením. V průběhu svého trvání v letech 1994 aţ 2012 prošel trh penzijního připojištění i upravující legislativa mnoha změnami. Z původních 46 penzijních fondů se počet poskytovatelů ustálil na deseti. Ve většině případů se jedná o společnosti úzce spjaté s velkými finančními skupinami. Rovněţ i samotný systém penzijního připojištění doznal určitých legislativních změn, které ve většině případů pouze kosmeticky upravovaly základní nastavení penzijního připojištění. Úspěšnost produktu a zájem o něj nejlépe vystihuje počet aktivních účastníků, kterých na konci roku 2012 bylo necelých pět miliónů. Demografické

prognózy

Českého

statistického

úřadu

dlouhodobě

vypovídaly

o dlouhodobě nepříznivém stárnutí České populace.[12] Nepříznivý poměr počtu obyvatel starších 65 let k počtu obyvatel v produktivním věku byl jedním z ukazatelů, který odhalil, ţe stávající systém důchodového zabezpečení je neudrţitelný. Důchodová reforma se tak stala jedním z hlavních témat politických stran. Důchodová reforma, která se v podobě tzv. malé důchodové reformy spustila v letech 2011 a 2012, měla za jeden z hlavních cílů zastavit růst schodku veřejných prostředků na důchodovém účtu. Hlavní důchodová reforma pak navázala od ledna 2013. Proměnila původní dvou pilířový systém důchodového spoření na tří pilířový systém. Reforma zachovala v platnosti státní průběţný systém. Účast v prvním pilíři je povinná pro zaměstnance a osoby samostatně výdělečně činné. Nově se zavedl druhý pilíř, který 9

měl umoţnit účastníkům vyvést část finančních prostředků z prvního průběţného pilíře na svůj důchodový účet vedený u soukromé penzijní společnosti prostřednictvím pravidelných měsíčních odvodů. Nastavení parametrů druhého pilíře nebylo šťastné, politický vývoj v České republice rovněţ nepřispíval k přijetí tohoto produktu širokou veřejností. Dnes jej jiţ známo, ţe druhý pilíř bude v průběhu roku 2016 zrušen.[7] Důchodová reforma zachovala původní systém penzijního připojištění s drobnými úpravami, jako tzv. třetí pilíř, a zároveň jej doplnila o systém doplňkového penzijního spoření. Nový důchodový systém měl sníţit negativní dopady na budoucí důchodce, ale zároveň měl zvýšit odpovědnost ekonomicky aktivního obyvatelstva za svou budoucnost.

1.2. Penzijní společnost Legislativní změny penzijního systému v České republice, které byly nastartovány v letech 2011 a 2012 měly za důsledek i legislativní proměnu původních poskytovatelů penzijního připojištění. V průběhu měsíce prosince 2012 většina původních penzijních fondů působících na trhu penzijního připojištění prošla tzv. transformací a z penzijních fondů se staly, na základě uděleného povolení k činnosti Českou národní bankou, penzijní společnosti. Penzijní společnost je akciová společnost se sídlem na území České republiky, jejímţ předmětem podnikání je shromaţďování příspěvků účastníka, příspěvků zaměstnavatele a státních příspěvků za účelem jejich umísťování do účastnických fondů, obhospodařování majetku v účastnických fondech a vyplácení dávek penzijního spoření.[6] Počáteční kapitál penzijní společnosti činí nejméně 50 000 000 Kč.[6] Penzijní společnosti musejí vykonávat svou činnost s odbornou péčí. K zajištění výkonu řádného hospodáře musejí být penzijní společnosti vybaveny řídícím a kontrolním systémem. Penzijní společnosti musí mít rovněţ dostatečné personální a organizační vybavení. Nově vzniklé Penzijní společnosti začaly od ledna 2013 poskytovat sluţby spojené s důchodovým spořením, které je široké veřejnosti spíše známo jako tzv. druhý pilíř 10

a řídím se dle zákona č. 426/2011 Sb. o důchodovém spoření. Dále začaly nabízet sluţby dle zákona č. 427/2011 Sb., o doplňkovém penzijním spoření a v neposlední řadě jim zůstaly povinnosti se zabezpečením poskytování sluţeb spojených s původním penzijním připojištěním, které se řídí zákonem č. 42/1994 Sb. o penzijním připojištění se státním příspěvkem a o změnách některých zákonů souvisejících s jeho zavedením. Všechny výše uvedené změny a nový rozsah poskytovaných sluţeb měly za důsledek, ţe Penzijní společnosti kromě prodělaných legislativních změn musely provést úpravy vnitřních procesů a pracovních postupů. Penzijní společnosti k zajištění svých činností, které jim ukládá legislativa, musely provést rozsáhlé úpravy stávajících informačních systému nebo v mnoha případech vybudovat nové informační systémy. Penzijní fond musel projít rozsáhlým transformačním projektem. Cílem projektu bylo transformovat Penzijní fond na novou Penzijní společnost v souladu s novou důchodovou reformou ČR. Zároveň bylo třeba změnit nabízené produkty, distribuční model a procesy dle pravidel a legislativy důchodové reformy včetně vybudování tzv. „nízkonákladové“ společnosti s potenciálem dlouhodobě udrţitelného rozvoje. K naplnění uvedených cílů byl v závěru roku 2011 zaveden v Penzijním fondu programový management. Finální rozsah programu byl sloţen z jednotlivých projektů takto: 01 Projekt – Legislativní poţadavky a Transformační projekt 02 Projekt – Vývoj produktů a Distribuce 03 Projekt – Back Office a ICT Podpora 04 Projekt - Lean Projekt „Legislativní poţadavky a Transformační projekt“ měl za úkol získat k povolení činnosti Penzijní společnosti udělované Českou národní bankou, upravit vnitřní předpisy společnosti, aby byla zajištěna právní přeměna Penzijního fondu na Penzijní společnost a získáno povolení k vytvoření účastnických a čtyř povinných důchodových fondů. Tento projekt byl specifický přesným časovým harmonogramem, který byl přímo dán legislativou. Projekt „Vývoj produktů a Distribuce“ měl na starosti přípravu nového marketingového plánu pro rok 2013. Měl zajistit výrobu nových formulářů, informací o produktech,

11

strategiích a společnosti. Projekt měl na starosti nastavení nové spolupráce s distribučními kanály včetně uzavření Mandátních smluv. Zabezpečit školení distribučních partnerů na nové produkty. Otevřít nové komunikační kanály ke klientům prostřednictvím sociálních sítí. Projekt „Back Office a ICT Podpora“ měl za hlavní úkol náhradu core systému penzijní společnosti a nastavení nových interních procesů v provozním úseku Penzijní společnosti. Jak jiţ bylo uvedeno, tento projekt byl vybrán pro demonstraci úspěšnosti implementace projektového managementu. Pro účely této diplomové práce bude projekt číslo 3 přejmenován na „Nový informační systém pro Penzijní společnost“ nebo také zjednodušeně „Nový ISPS“. Projekt „Lean“ si stanovil za cíl proměnu Penzijního fondu v novou, moderní a nízkonákladovou Penzijní společnost. Tento cíl měl být dosaţen prostřednictvím sběru poţadavků externího a interního zákazníka Penzijní společnosti. Hlas zákazníka neboli „voice off customer – VOC“ měl prostřednictvím focus group zjistit skutečné potřeby zákazníků Penzijní společnosti. Dalším cílem čtvrtého projektu byla definice strategických cílů Penzijní společnosti a jejich propojení se zjištěnými potřebami zákazníků. Součástí projektu byla příprava plánu školení zaměstnanců Penzijní společnosti na metody LEAN. Vybraní zaměstnanci měli být formou školení a workshopů zaškoleni do pozic tzv. lean metodologů a ostatní zaměstnanci měli být rovněţ s LEAN metodou seznámeni, aby mohli vyhledávat

v rámci

zpracování

běţných

denních

agend

vyhledávat

příleţitost

ke zjednodušování (zeštíhlování) procesů a tím dosáhnout větší efektivnosti při zachování stejné kvality finálního produktu.

1.3. Organizační struktura penzijní společnosti Zákon o obchodních korporacích č. 90/2012 Sb. upravuje systém vnitřní struktury akciové společnosti, kterou penzijní společnost je. Systém vnitřní struktury penzijní společnosti, které se bude tato práce věnovat, má zaveden dualistický systém, ve kterém je zřízeno představenstvo a dozorčí rada.[5] Valná hromada akcionářů volí členy představenstva a členy dozorčí rady. Představenstvo, které je statutárním orgánem penzijní společnosti, je 12

tříčlenné a volí nebo odvolává svého předsedu. Předseda představenstva je zároveň generálním ředitelem Penzijní společnosti. Penzijní společnost se řadí počtem svých zaměstnanců mezi střední podniky, které zpravidla pouţívají jednoduché organizační uspořádání (liniová nebo funkční organizační struktura).[1] K výhodám těchto struktur obvykle patří přímé kontakty mezi vedením a pracovníky, větší pruţnost a schopnost improvizace při změnách procesů a menší míra byrokracie. Organizační struktura vystupuje ve vztahu ke strategii podniku jako nástroj pro naplňování cílů stanovených ve strategii. Organizační strategie vychází ze strategické analýzy mikro a makro okolí podniku, zohledňuje organizační kulturu, obsahuje informace o portfoliu produktů a jejich objemů, velikosti organizace, pouţívaných technologiích apod. Organizační strategie vytváří zadání pro osnovu organizační struktury. Nové informační technologie silně ovlivnily vznik „nových“ organizačních struktur. Rychlý a levný transfer dat a informací prolomily bariéry času a vzdálenosti. Informační technologie

umoţňují

podnikům

provádět

v organizačních

strukturách

inovace

a racionalizace. V této části je nutné rovněţ zmínit personální obsazení vytvořené organizační struktury. Navrţenou organizační strukturu je třeba naplnit lidmi. Aby podnik mohl efektivně fungovat, musí do organizační struktury do pracovních pozic a útvarů dosadit pracovníky s odpovídající kvalifikací a vlastnostmi. Správný výběr a obsazení pracovních pozic v organizační struktuře přispívá ke stabilizaci, rozvoji a k funkčnosti organizační struktury. Pomocí optimálně nastavené a optimálně fungující organizační struktury podnik snáze dosahuje naplnění stanovených strategických cílů. Penzijní společnost zvolila pro naplnění svých cílů a úkolů organizační schéma, které je v odborné literatuře uváděno pod názvem „Liniově – štábní struktura“. Tato organizační struktura v sobě spojuje prvky klasického liniového řízení s prvky funkční struktury. Jsou zachovány principy liniového vedení v kombinaci s principy funkčních odborných vedoucích a určených vedoucích. Tato organizační struktura je sloţitější na vztahy, odpovědnosti a pravomoci. Přenáší více zodpovědnosti na funkční útvary nebo úseky, 13

které se podílejí na přípravě rozhodnutí, dále mají právo metodického řízení a dílčích kontrol. Mezi výhody „Liniové – štábní struktury“ patří zvýšená samostatnost a odpovědnost jednotlivých útvarů, rychlejší reakce na změny strategií nebo procesů. Nevýhodou je obtíţnější koordinace jednotlivých útvarů a rovněţ je třeba klást vyšší nároky na komunikační toky uvnitř společnosti. Mimo vertikální komunikace shora dolů a obráceně je třeba vytvořit i komunikaci horizontální mezi útvary na stejné úrovni, aby mohly svou práci a záměry koordinovat.

Obrázek 1 - Organizační struktura [zdroj autor]

Pokud se má projevit pozitivní efekt projektového managementu v organizaci, je nezbytné, aby měl reálnou podporu jejího vedení. První třecí plochou (avšak nikoliv jedinou), se kterou se projektový management musí se ctí vypořádat, je totiţ souběh s liniovým (funkčním) řízením. Na uvedeném schématu je tento souběh znázorněn:

14

Obrázek 2 - Koordinace projektu [zdroj ADAPMA.com]

Projekty často vyţadují alokaci zdrojů z vícera oborů a funkčních úseků organizace. To bývá jeden z důvodů pro zavedení tzv. maticové organizační struktury, která kombinuje vertikální model liniového řízení s horizontálním modelem projektového (ale také třeba produktového)

managementu.

Dle

váhy

projektového

managementu

v

tomto

kombinovaném systému řízení pak hovoříme o silné nebo slabé matici. Ve slabé matici projektový management zpravidla prohrává svůj boj o stanovení priorit i o zdroje a posléze ztrácí zcela smysl, protoţe jeho reálná podpora a tedy poptávka po něm, je ze strany vedení nedostatečná a nepřesvědčivá. Úkoly funkčních úseků plynou z jejich funkčního zaměření a odborné specializace. Z titulu této specializace zpravidla takové úseky také vznikly. To logicky vede k přesvědčení, ţe úkoly funkčního řízení musí mít prioritu nad úkoly přicházejícími z řízení projektového. Někdy to tak skutečně musí, alespoň občas, být. Liniové řízení však zpravidla není schopno efektivně a flexibilně koordinovat jednotlivé specializace, pokud chce reálně naplňovat strategii kontinuální a včasné inovace, která je dnes v mnoha oborech ţivotně důleţitá. Tehdy se tedy síla projektového řízení v organizaci můţe snadno stát i otázkou jejího přeţití či nepřeţití, kterou si musí vedení včas umět zodpovědět.

15

1.4. Implementace nového informačního systému Jak jiţ bylo uvedeno v kapitole 1.1, Penzijní společnosti, které se od ledna 2013 rozhodly poskytovat sluţby související s druhým a třetím pilířem a obdrţely potřebnou licenci, stály na rozcestí, zda se vydat směrem úprav a rozšíření stávajících informačních systémů, jejichţ prostřednictvím obhospodařovaly účastníky penzijního připojištění se státním příspěvkem anebo jít cestou nového softwarového řešení. Vedení Penzijní společnosti, se rozhodlo vydat cestou nákupu nového informačního systému, který byl pouţit v rámci důchodové reformy uskutečněné v roce 2005 na Slovensku. Jelikoţ podmínky důchodových reforem v obou zemích si byly velmi blízké, mohl být informační systém, po doprogramování odlišností české důchodové reformy, pouţit pro účely Penzijní společnosti. V penzijní společnosti vznikl projekt pod názvem „Nový informační systém pro Penzijní společnost“. Ke schválení důchodové reformy došlo v listopadu roku 2011 a její start byl naplánován na leden 2013. Výměna informačního systému byla rozsáhlý projektem s ambiciózním termínem splnění. Rozumné časové období pro projekty tohoto typu je uváděno zhruba 24 měsíců. Penzijní společnost však měla na jeho realizaci pouhých 12 měsíců. Projekt „Nový ISPS“ se od samého začátku vyznačoval striktním časovým omezením a zároveň velkým rozsahem. Důvody časového omezení byly dány legislativou a velký rozsah způsobovaly nové produkty a s nimi spojený vysoký počet funkcionalit, vazeb a stavů, které v informačním systému mohou nastat. Přestoţe Penzijní společnost vybrala řešení, které uţ jinde fungovalo, byla česká penzijní reforma v mnoha parametrech odlišná. Některé prvky slovenských systému bylo sice moţné pouţít, ale nebylo moţné softwarové řešení aplikovat jako celek. Rozhodnutí, které vedení Penzijní společnosti učinilo, sebou přineslo i nutnost zasáhnout do organizační struktury vedení Penzijní společnosti. Projekt výměny informačního systému svým rozsahem vyţadoval i implementaci projektového řízení do organizačních struktur Penzijní společnosti.

16

1.5. Cíle práce Autor této práce měl, jako zaměstnanec Penzijní společnosti na pozici vedoucího oddělení, moţnost se zúčastnit nejen prací na projektu „Nový ISPS“, ale zároveň měl příleţitost být přítomen zavádění projektového řízení. Z počátku projektu pracoval jako řadový člen projektového týmu a v určité fázi projektu se posunul na pozici business architekta informačního systému, coţ mu umoţnilo úzce spolupracovat s vedením projektu a získat více informací o způsobech, metodách vedení projektu. V průběhu projektu měl autor práce moţnost pracovat s několika projektovými manaţery, jak na straně Penzijní společnosti, tak na straně dodavatele nového informačního systému. Tato práci vychází z praktických zkušeností účasti na projektu. Práce je striktně rozdělena na teoretickou a praktickou část. Tato práce si stanovila několik cílů, které jsou níţe definovány. Přehled jejich splnění či nesplnění je uveden v závěrečné kapitole této práce. Jedním z cílů této práce je provedení analýzy chyb řízení projektu. V závislosti na reálném průběhu projektu provedu analýzu chyb, které dle názoru autora měly negativní vliv na průběh projektu. Autor práce by rovněţ rád označil konkrétní zodpovědné členy projektového týmu, kteří měli hlavní podíl na vzniklých chybách a důsledky těchto pochybení na celkový průběh projektu. Dále bude provedeno vyhodnocení činnosti jednotlivých projektových manaţerů, kteří se na projektu zúčastnili. Porovnáním typů osobností projektových manaţerů a jejich způsobů vedení projektu bude vyhodnocen jejich vliv na projekt. Dalším cílem diplomové práce je analýza, zda zvolená metodika pro vedení projektu byla vhodná. Bude provedeno porovnání reálného průběhu projektu „Nový ISPS“ s agilní metodikou Scrum. Posledním stanoveným cílem je vyhodnocení, zda implementace projektového řízení v Penzijní společnosti byla úspěšná. Zda nastavené projektové postupy byly úspěšné a zda nedocházelo k rozporům mezi liniovým a procesním řízením.

17

2. Teorie projektového řízení 2.1. Projekt Pojem projekt se stal fenoménem v posledních desetiletích. S pojmem projekt se jiţ dnes běţně potkávají děti v rámci školní výuky. Formou projektů se realizují rozsáhlé stavby, tvoří se nové výrobky nebo se provádí výzkum. Projektem můţe být za určitých předpokladů příprava nedělního oběda, ale také restrukturalizace nadnárodní společnosti. Projekt je nejdůleţitějším prvkem projektového managementu, a proto je nezbytně nutné uvést význam pojmu projekt. V odborné literatuře můţeme nalézt několik formulací definice projektu. Pro naše účely uvádím definici projektu od profesora Kerznera, která je obecnou definicí pro jakýkoliv typ projektu a rovněţ uvádím definici projektu ICT.[4] „Projekt je jakýkoliv jedinečný sled aktivit a úkolů, který má: dán specifický cíl, jenž má být jeho realizací splněn, definováno datum začátku a konce uskutečnění, stanoven rámec pro čerpání zdrojů potřebných pro jeho realizaci.“[4] „Projekt ICT je soubor technologicky a organizačně souvisejících činností vyvolaných za účelem pořízení nebo adaptace informačního systému či informačních a komunikačních technologií, které jsou určeny k vytvoření jedinečného záměru při předem definovaném čase, nákladech, zdrojích a kvalitě, přičemž končí předáním produktu (produktů) do užívání.“ [4] Jak je z výše uvedeného patrné, definice projektu ICT je mnohem konkrétnější neţ definice obecná, ale toto platí pouze proto, ţe projekt ICT je pouze podmnoţinou projektu. Pro ICT projekt samozřejmě platí i obecná definice projektu, ale díky své specializaci můţe být definice ICT projektu mnohem přesnější. Obecná definice projektu od profesora Kerznera byla vybrána úmyslně, protoţe jsou z ní velmi pěkně čitelné tři hlavní charakteristiky důleţité pro projektový management. Tyto tři charakteristiky vymezují prostor, v němţ se podle vytyčených cílů vytváří nová hodnota, 18

která je definována v projektu jako výstup nebo výsledek projektu. Mezi tyto tři charakteristiky patří čas, který je limitní pro plánování posloupnosti jednotlivých dílčích činností projektu. Další charakteristikou je dostupnost zdrojů, které jsou na projekt alokovány a které jsou průběţně pouţívány. Poslední charakteristikou projektu jsou náklady, které jsou finančním projevem uţití zdrojů v časovém rozloţení.

2.2. Metodiky řízení projektů Jelikoţ neexistuje nic jako “typický projekt” tak také neexistuje jediné vhodné pojetí k řízení projektu. To je vţdy nutné zvolit dle charakteru a podmínek daného projektu, respektive podle toho, jaký typ projektů v organizaci máme. Jiným způsobem se řídí projekty vývoje software a jinak například rozsáhlý developerský projekt nebo projekt stavby rodinného domu. V zásadě existují dva základní přístupy k řízení projektu, rigorózní (tradiční) a agilní. [1] Metodice řízení projektů se na mezinárodní úrovni věnují různé profesní organizace nebo organizace vydávající standardy. Mezi nejvýznamnější v tomto oboru se řadí PMI, IPMA, AXELOS Limited. Vyskytuje se rovněţ mnoho oborových a dílčích metodik pro řízení projektů. Obecně nejznámější a světově nejrozšířenější metodiky a standardy pro řízení projektů jsou: PMBOK (Project Management Body of Knowledge) - kterou vydává PMI PRINCE2 (PRojects IN Controlled Environment) - kterou vydává AXELOS Limited [11] Tyto metodiky a svým způsobem de-facto standardy obsahují vše potřebné k řízení projektů různého charakteru a různých velikostí. Rozhodnutí o tom, jakou metodu pro řízení projektů zvolit, je závislé především na třech základních faktorech: na organizaci, ve které projekt probíhá (na typu, velikosti a způsobu řízení organizace) na vymezení projektu (samotný objekt a cíl projektu, finance, harmonogram, priority, kapacity, rizika, souběh dalších projektů) 19

na projektovém manaţerovi (jeho zkušenostech s konkrétní metodikou)

2.3. Rigorózní (tradiční) metodiky Jedná se historicky o největší skupinu metodik, které se zabývají podrobným popisem procesu vývoje software. Rigorózní přístup je zaloţen na důkladném naplánování před zahájením projektu a řízení všech aktivit v průběhu projektu. Je vhodný pro projekty, které mají předem jasně danou podobu cíle a je třeba dobře naplánovat a odřídit všechny aktivity, návaznosti či subdodavatele. Tradiční přístup vyţaduje kvalitně popsaný cíl, výstupy a plán projektu. Celý proces je charakterizován tzv. Vodopádovým modelem definice posloupnosti jednotlivých činností během vývojového cyklu. Vývoj software je jasně definovaný proces, od kterého se nemůţeme odchýlit. V kaţdém projektu je nutné uvaţovat nad třemi základními konstantami - čas, náklady a rozsah projektu (zadání). Některé z nich jsou neměnné, jiné se naopak mění během projektu. V případě rigorózních metodik je neměnnou veličinou rozsah projektu - resp. to, co je zadáním od objednavatele. Tento přístup umoţňuje velmi dobré řízení projektu. Role a jednotlivé fáze během vývojového cyklu jsou jasně definované. Bohuţel z výše popsaného vyplývají i zřejmé nevýhody. Rigorózní metodiky jsou povaţovány za tzv. "těţké" - jsou velmi podrobné, obsahují hodně formalit a jsou specifické direktivním řízením. Procesy jsou opakovatelné a předpokládají definování všech poţadavků na řešení předem. Díky tomu se můţe ztrácet cíl vývoje - hlavním smyslem by mělo být vytvořit fungující předmět projektu nebo sluţbu na základě zákaznických potřeb a ne před nimi upřednostňovat procesy. Dále se také tyto metodiky neumí příliš dobře vypořádat s náhlými změnami. Je nutné všechny poţadavky specifikovat předem a během vývoje je jiţ neměnit. Mezi rigorózní metodiky můţeme zařadit kromě Vodopádu také ještě Spirální model, Unified Process, Rational Unified Process a Enterprise Unified Process. [1] V pojetí rigorózních metodik má projekt charakter procesu, který se vyvíjí. V době své existence se projekt nachází v různých fázích, pro které se ustálil název „ţivotní cyklus 20

projektu“. Základním znakem projektu je, ţe se jedná o činnost dočasného charakteru. Má jasně vymezený začátek a konec. Výstupem projektu je unikátní produkt, sluţba nebo výsledek. Projekt je obvykle realizován více organizačními jednotkami. Ačkoliv je kaţdý projekt jedinečný, z hlediska řízení projektů mají všechny projekty určité společné znaky. Zejména se jedná o shodné projektové etapy, které jsou analogickým způsobem definovány ve všech standardech a normách v projektovém řízení. Přestoţe se v určitých detailech mohou vzájemně lišit, shodují se na rozdělení 4 základních fází kaţdého projektu a to: Zahájení/iniciace Plánování/definice Realizace/implementace/monitoring a kontrola Uzavření/předání [3]

Obrázek 3 - Fáze projektu [zdroj autor]

2.3.1. Zahájení/iniciace projektu Zahájení nebo také iniciaci projektu předchází tzv. „předprojektová fáze“, jejímţ cílem je identifikace potřeb objednavatele. Potřeby nebo poţadavky objednavatele jsou v rámci iniciace transformovány do zadání projektu. Proces iniciace projektu má sekvenční charakter.[10] Prvním krokem je výběr projektového manaţera, který je osobou 21

zodpovědnou za přípravu podkladů slouţících k rozhodnutí, zda daný projekt realizovat. Určení projektového manaţera je provedeno bezprostředně po identifikaci potřeby objednavatele, která by potenciálně mohla být realizována formou projektu. Projektovému manaţerovi je formálně přidělena odpovědnost a pravomoc za řízení. Po ustavení projektového manaţera následuje analýza omezujících faktorů objednavatele, kterými mohou být organizační struktura, kultura a pouţívané existující systémy, a které mohou významně ovlivnit úspěšnost projektu. V rámci analýzy se provádí prvotní sběr informací o organizaci objednavatele a jejím vnitřním chodu. Tyto relevantní informace mohou slouţit při tvorbě zadání projektu. Zaţité procedury a pouţívané standardy mohou být vyuţity v rámci procesních skupin po celou dobu realizace projektu. Poznání vnitřních vazeb organizace odběratele umoţní rozdělit projekt do jednotlivých fází a je moţné tak učinit dle zvyklostí objednatele. Po provedení analýzy objednatele projektu, je prováděna analýza okolí projektu, jejímţ smyslem je ohraničení projektu z pohledu objednavatele a dopadu projektu na něj. Jsou identifikovány zúčastněné strany na projektu. Je posouzen jejich vliv na průběh projektu a jejich klíčovost pro jasné definování cílů a souvislostí projektu. Dalším krokem zahájení projektu by mělo být zdokumentování potřeb objednavatele, které byly identifikovány v rámci „předprojektové fáze“, a které byly získány v rámci analýzy firemní kultury a vnitřního chodu objednavatele.[10] Následně by měly být stanoveny cíle projektu. Je stanoveno ohraničení projektu z pohledu času, obsahu a zainteresovaných stran interních i externích. Předposledním krokem zahájení projektu by mělo být definování souvislostí projektu. Měly by být zodpovězeny otázky typu: Co se stalo před začátkem projektu? Co bude následovat po ukončení projektu? Co má vliv na projekt? Na co má projekt vliv? Kdo má vliv na projekt? Na koho má projekt vliv? Závěrečným výstupem ze zahájení projektu je vytvoření formálního zadání projektu, které definuje projektové ohraničení a souvislosti. Je identifikován projektový manaţer, sponzor projektu. Součástí formálního zadání projektu je předběţný předmět plnění, jsou vymezeny poţadavky na zdroje. Jsou identifikovány externí i interní předpoklady a omezení. Zadání projektu formuluje sponzor projektu jako zadání pro projektového manaţera.

2.3.2. Plánování projektu Plánování projektu je nejnáročnější ze všech fází projektu. Od kvality plánování projektu se odvíjí úspěšné naplnění cílů projektu. V rámci plánování se dále definují základní

22

manaţerské plány, jakým stylem bude celý projekt řízen. Procesu plánování se zúčastňují všechny na projektu zúčastněné strany. Poţadovaným výsledkem je ztotoţnění projektového týmu s projektem.[11] V této fázi projektu se celý projekt naplánuje do konkrétních činností. Granularita aktivit, do kterých se projekt plánuje, závisí na typu a velikosti projektu. Proces plánování je obdobně jako proces zahájení projektu sekvenční, ale na rozdíl od první fáze projektu je neustále se opakující. Výsledkem procesu plánování by měl být projektový plán. Prvním krokem procesu plánování je ověření, zda projektové zadání, které vzniklo v rámci iniciace projektu, je realizovatelné. Dalším postupným krokem této fáze projektu je zvolení metodologie, kterou bude vytvořen plán projektu. Následuje detailnější rozpracování definice zadání projektu. Je vytvořen popis výstupů projektu a rámcová definice nutných prací. Dochází k definici projektového týmu. Jsou jmenovaní členové týmu, kteří se budou podílet na samotné realizaci projektu. Po nominaci členů týmů přichází na řadu rozdělení zadání projektu na menší, lépe popsatelné části. V projektové terminologii se pro tyto menší části zadání projektu zaţil název „pracovní balíčky“. Kaţdému pracovnímu balíčku je určen „vlastník“, který odpovídá za jeho popis a následně i realizaci. Následně jsou pracovní balíčky seřazeny do logického sledu. Kaţdý z pracovních balíčků má svého předchůdce a následovníka. Je vytvořen síťový diagram určení posloupnosti aktivit. Přiřazením potřebných lidských zdrojů k jednotlivým aktivitám vzniká plán lidských zdrojů. Jedná se o velmi senzitivní krok procesu, protoţe alokaci lidských zdrojů na projekt je nutné odsouhlasit s jejich liniovými manaţery. Po přidělení lidských zdrojů by měl být pracovnímu balíčku přiřazen i časový odhad pracnosti. Měla by být stanovena kritická cesta projektu, která by měla identifikovat aktivity, jejichţ změnou by mohlo dojít k ohroţení časového harmonogramu projektu. Odhadem délky trvání projektu se vytvoří předběţný harmonogram projektu. Připraví se předběţný rozpočet projektu a je definován plán kvality, jehoţ součástí je určení definice standardů kvality a stanovení metrik, kterými se bude sledovat naplnění cílů, a kterými se bude vyhodnocovat kvalita vykonaných projektových prací. Následně musí být definovány role a odpovědnosti jednotlivých členů týmů s cílem transparentně nastavit a jasně komunikovat, kdo a za co je odpovědný. Je nutné vytvořit pravidla pro komunikaci v rámci projektového týmu. Součástí fáze plánování je identifikace rizik projektu, jedná se o návazný krok na identifikaci rizik z fáze zahájení projektu. Prostřednictvím kvalitativní analýzy by měly být určeny oblasti, které mohou být rizikem ovlivněny. U rizik se stanovují pravděpodobnosti jejich dopadu a plánuje se strategie eliminace rizik. Pro rozpočet projektu jsou vyčísleny náklady na eliminaci rizik. Dopracovává se 23

projektový plán. Dalším postupným krokem fáze plánování je u projektů, které jsou řešeny v součinnosti s externími dodavateli, definice předmětu, postup výběru dodavatelů, způsob stanovení výběrových kritérií a stanovení harmonogramu výběrového řízení. Pro výběrové řízení je nutná příprava tzv. nákupní dokumentace. Je připraveno RFI (Request for Information), případně RFP (Request for Proposal) [9] nebo další potřebná dokumentace, která bude popisovat všechny poţadavky na dodavatelské plnění. Nastaví se proces, kterým bude vykonáván projektový plán a zároveň se nastaví proces, kterým bude prováděn projektový kontroling a monitoring. Stanoví se projektové metriky a způsob jejich vyhodnocování. Vytvoří se finální projektový plán a zafixuje se harmonogram projektu. Předposledním krokem fáze plánování je získání formálního odsouhlasení znění projektového plánu ze strany sponzora projektu a obdrţení formálního schválení projektového plánu od členů týmu, kteří se podíleli na plánování a manaţerů zdrojů. Posledním

krokem

fáze

plánování

je

zorganizování

úvodního

setkání

všech

zainteresovaných stran projektu. Cílem úvodní schůzky je představení projektu, nastavení primárních očekávání a získání podpory pro projekt.

2.3.3. Realizace, implementace, kontroling a monitoring Realizace se sestává z procesů, kterými se odstartuje a provádí samotný výkon projektových prací a jsou uskutečňovány jednotlivé projektové cíle. Poté, co jsou ukončeny procesy fáze plánování, je definován rozpočet a zdroje, dochází k zahájení samotných projektových prací. S „finální“ platností je potvrzen projektový tým a kaţdý člen týmu je seznámen se svou projektovou úlohou. Dochází k distribuci informací na všechny zúčastněné strany. V případě projektů s externím dodavatelem, jsou osloveni a posléze i vybráni vhodní dodavatelé. Dále pak se realizuje samotná dodávka předmětu plnění projektu. Procesy obsaţené ve fázi realizace jsou vykonávány paralelně. [10] Jelikoţ mezi fází plánování a realizací můţe být větší časová prodleva, musí v takovém případě dojít na začátku fáze realizace k ověření kapacit členů projektového týmu. Dochází k realizaci plánu projektu. Jsou zahájeny práce na úlohách, které byly definovány v manaţerských plánech a jsou implementovány standardy kvality. Pro jednotlivé pracovní balíčky jsou zabezpečeny potřebné zdroje. Probíhá realizace předmětu projektu a plnění jednotlivých projektových cílů. Rovněţ musí probíhat řízení očekávání zainteresovaných

24

stran. Velmi důleţitým prvkem ve fázi realizace je distribuce informací. Sdílení a včasná distribuce informací mezi jednotlivými členy a týmy je velmi důleţitou sloţkou pro celkový úspěch projektu. Dochází k implementaci změnových poţadavků, nápravných a preventivních opatření, která byla zjištěna a popsána v rámci kontroling a monitoringu. Jsou přijímána opatření, která slouţí k eliminaci projektových rizik. V průběhu fáze realizace projektu jsou fyzicky vykonávány procesy projektového řízení. Díky výstupům z probíhajícího kontrolingu a monitoringu mohou být procesy projektového řízení neustále vylepšovány. Součástí fáze realizace je i práce s členy projektového týmu. Projektový manaţer by měl podporovat pozitivní myšlení, rozvíjet týmový duch a umoţňovat zvyšování kvalifikace členů týmů. Motivace členů týmů by měla být podporována prostřednictvím systému odměňování a dalších motivačních nástrojů, mezi něţ patří i vyslovení uznání nad odvedenou prací. V průběhu celého projektu probíhají schůzky jak na úrovni projektových týmů, tak i pravidelné schůzky s objednavatelem, na kterých je představen současný stav projektových prací, plán práce na další období a stav projektových rizik. Ve fázi realizace jsou pouţívány systémy, které slouţí jako podpora pro řízení projektu. V rámci pouţívaného systému je sledováno, zda dodávané plnění odpovídá poţadavkům, zda je předmět projektu dodáván v poţadovaném termínu a kvalitě. Jak bylo uvedeno v úvodu této kapitoly, ve fázi realizace probíhají jednotlivé procesní kroky souběţně, a proto je nutné zmínit, ţe jedním z prvních kroků fáze realizace je u projektů řešených prostřednictvím externích dodavatelů i distribuce zadání projektu k potencionálním dodavatelům. Probíhá vyhodnocení získaných nabídek reagujících na zadávací dokumentaci a sestavení seznamu kvalifikovaných dodavatelů. Následuje výběr vhodného dodavatele, negociace podmínek smlouvy a podpis smlouvy mezi objednavatelem a dodavatelem. Nedílnou součástí třetí fáze ţivotního cyklu projektu je kontrola a monitoring. Kontrolovány a monitorovány jsou v podstatě veškeré činnosti probíhající na projektu. Proces kontroly předmětu zadání je zaměřený na faktory, které ovlivňují změny zadání projektu a na kontrolu dopadů těchto změn. Zajišťuje, aby všechny změny, které ovlivňují zadání projektu, předcházely procesům řízení změn. Kontrola harmonogramu sestává z určení současného stavu, odhalení odchylek plánu od skutečnosti a neustálé korekce odchylek a změn v projektovém harmonogramu. Proces kontroly nákladů je zaměřený na aktivní vyhledávání odchylek nákladů od plánu, posouzení těchto odchylek a doporučení nápravných opatření. Kontroly kvality obsahují činnosti, jejichţ cílem je 25

sledování, zda jsou skutečně odevzdávané výstupy v souladu s plánem kvality, respektive zda projektové práce odpovídají plánu kvality. V návaznosti na identifikaci případných odchylek, popřípadě změn, dochází k identifikaci nápravných opatření. Monitoring a kontrola rizik je proces identifikace, analýzy a plánování v případě nových rizik. Sledují se identifikovaná rizika. Provádí se nová analýza sledovaných rizik, monitorují se spouštěče rizik. Monitorují se reziduální rizika a vyhodnocuje se úspěšnost nápravných opatření.

2.3.4. Uzavření, předání Poslední fází ţivotního cyklu projektu je uzavření projektu. Uzavření obsahuje procesy, kterými dochází k předání předmětu plnění projektu a k formálnímu ukončení projektu nebo jeho části. Ukončením uzavření dochází k verifikaci, ţe všechny předcházející procesy všech fází projektu byly vykonány. V rámci uzavření je fyzicky dodán a akceptován předmět plnění projektu. V rámci uzavření projektu dochází ke shromáţdění znalostí a zkušeností, které byly na projektu získány. Fáze uzavření se sestává z procesu ukončení projektu a ukončení vztahů s dodavateli. Proces uzavření projektu uzavírá všechny aktivity napříč celým projektem s cílem formálního uzavření projektu nebo projektové části. Tento proces obsahuje část plánování, čímţ se má na mysli, jakým způsobem bude projekt uzavřen. Je vytvořen postup pro administrativní uzavření a postup pro uzavření smlouvy. Předmět plnění projektu je předán objednavateli do uţívání. Uzavření projektu je formálně stvrzeno podpisem sponzora projektu. [10]

2.4. Organizace projektu Vhodné nastavení organizační struktury a organizačních postupů je nutným předpokladem pro zajištění hladkého a úspěšného průběhu projektu. Organizační struktura projektu reprezentuje základnu, pomocí které je moţné zkoordinovat rozdílné zájmy účastníků projektu. Jiná očekávání od průběhu a výsledku projektu můţe mít nejvyšší vedení společnosti, jednotlivé útvary nebo úseky ve společnosti a v neposlední řadě, u projektů s externím dodavatelem, budou diametrálně odlišná očekávání u dodavatele. 26

Často vyuţívaná struktura řízení projektů má tři stupně řízení: Řídící výbor Vedení projektu Projektové týmy U projektů, jejichţ výsledný produkt, je společným dílem dvou subjektů objednavatele a externího dodavatele, jsou v jednotlivých stupních řízení projektů vţdy zástupci strany objednatele i dodavatele. [2] Nejvyšším orgánem organizační struktury projektu je Řídící výbor, který je oprávněn činit veškerá rozhodnutí v rozsahu pravomocí jednotlivých členů řídícího výboru. Členy Řídícího výboru jsou sponzoři projektu. Jednání Řídícího výboru předsedá sponzor projektu za stranu objednavatele. Dalšími členy jsou obvykle oba projektoví manaţeři, ale mohou jimi být i další osoby a to na základě dohody mezi objednavatelem a dodavatelem. Řídící výbor především schvaluje rozsah a plán projektu, stanoví cíle a priority. Řídící výbor jmenuje a odvolává projektové manaţery. Další z jeho úkolů je řešení vzniklých problémů nebo sporných situací, jejichţ řešení není v kompetenci projektových manaţerů. Řídící výbor rovněţ rozhoduje o změnách projektu. Jak jiţ z názvu dalšího orgánu organizační struktury projektu vyplývá, hlavním úkolem Vedení projektu je koordinace práce jednotlivých projektových týmu. V čele Vedení projektu stojí oba projektoví manaţeři. Členy Vedení projektu jsou vedoucí jednotlivých projektových týmů. Vedení projektu hlavně koordinuje práce na projektu, kontroluje dodrţování termínů dle plánu projektu a vydává rozhodnutí v rámci přidělených kompetencí. Další činností je příprava materiálů pro jednání Řídícího výboru. Projektový tým nebo projektové týmy provádějí a řídí veškeré práce na svěřené části projektu. V čele projektového týmu stojí vedoucí týmu. Členy Projektového týmu jsou nominovaní pracovníci za objednavatele a dodavatele. [2]

27

2.5. Sponzor projektu Sponzor projektu reprezentuje nejvyšší manaţerskou úroveň projektu. Typické je, ţe se jedná o člena představenstva nebo manaţera na úrovni ředitele organizační jednotky, která bude výsledek projektu pouţívat.[4] Sponzor projektu je v konečném důsledku zodpovědný za úspěch projektu. Je zodpovědný za to, aby se projekt, během celého svého trvání soustředil na dosaţení svých cílů a na dodání produktu nebo produktů. Udrţuje v rovnováze poţadavky businessu, uţivatelů a dodavatelů. Sponzor projektu dohlíţí na tvorbu detailního Business Casu, jehoţ je vlastníkem a je za něho v průběhu celého projektu zodpovědný. Monitoruje a kontroluje postup projektu na strategické úrovni. Sponzor projektu zajišťuje financování celého projektu. Schvaluje projektový plán a stanovuje toleranční limity pro kaţdou fázi projektu. Stará se o to, aby byla identifikována, ohodnocena a řízena rizika, která jsou spojena s Business Casem. Sponzor projektu organizuje a předsedá Řídícímu výboru, jehoţ je povinným členem s rozhodovacím právem veta. Jmenuje manaţerský tým projektu, zejména Projektového manaţera a další členy Řídícího výboru. Odpovídá Projektovému manaţerovi na ţádosti o radu. Sponzor projektu rozhoduje ohledně eskalovaných případů, kdy nedošlo ke shodě na úrovni Vedení projektu nebo v případech, které jsou mimo rámec kompetencí Vedení projektu. Sponzor projektu jako předseda Řídícího výboru schvaluje, ţe všechna akceptační kritéria projektu jsou splněna a komunikuje uzavření projektu. Jak jiţ bylo zmíněno, na projektech, kde finální cíl nebo produkt je společným dílem objednavatele a externího dodavatele, je role Sponzora projektu zastoupena na straně objednavatele i na straně dodavatele. Jejich role mají pro projekt odlišný charakter. Sponzor projektu za stranu objednavatele je předsedou Řídícího výboru a je vlastníkem projektu. Sponzor projektu na straně dodavatele je zodpovědný za zajištění zdrojů a podpory pro Projektového manaţera na straně dodavatele. Je rovněţ členem Řídícího výboru

projektu

s cílem

zajištění

dodrţování

a

ovlivňování

směru

projektu.

Prostřednictvím komunikace s Projektovým manaţerem objednavatele aktualizuje stav projektu.

28

2.6. Projektový manaţer „Manažer projektu je osoba odpovědná za splnění cílů projektu při dodržení všech stanovených charakteristik projektu.“[4] Tolik jednoduchá definice pozice projektového manaţera, za kterou se však skrývá celá řada nezbytných dovedností, schopností a odpovědností manaţera projektu. Manaţer projektu je klíčovou osobou projektového managementu. Projektový manaţer je řídícím článkem celého projektu, který se pohybuje na kritické pozici rozhraní mezi projektovým a liniovým řízením.[4] V jeho gesci je veškeré projektové dění, počínaje tvorbou projektového plánu, obsazením jednotlivých odborných pozic projektu, koordinací úkolů, aţ po administrativní uzavření projektu. Od manaţera projektu se očekává, ţe kromě běţných činností plánování, sladění aktiv členů projektové skupiny a jejich kontroly, pro které je kvalifikován a má k dispozici nezbytná pravidla, technologie a podnikové metodiky, bude zároveň řešit většinu nestandardních nebo neočekávaných stavů nebo vlivů, které v průběhu projektových prací nečekaně nastaly, nebo jsou důsledkem působení rizikových činitelů a projektových změn. Manaţer projektu musí obsáhnout široké spektrum dovedností, které vyţadují potřebnou kvalifikaci, nabytí dostatečných zkušeností a značnou dávku talentu. V osobě manaţera projektu se musí snoubit mnoho dovednosti. Projektový manaţer by měl mít výrazné manaţerské schopnosti, aby dokázal motivovat a vést projektový tým, s dovedností rozvíjet mezilidské vztahy. Zároveň by měl být velmi schopným analytikem. Tuto dovednost uplatní pro vyhodnocení a porovnání skutečného stavu projektu vůči stanovenému plánu. Určitě by měl být dobrým stratégem s vyjednávacími schopnostmi. Tato dovednost je nezbytně nutná u projektů s dodavatelským subjektem. V neposlední řadě by měl mít všeobecnou znalost ekonomické oblasti, ve které působí a měl by být odborníkem ve vyuţívání technik a technologií pro realizaci projektu, včetně znalosti software pro řízení projektu. Jak z výše uvedeného výčtu dovedností a znalostí vyplývá, nároky na osobu ve výkonu projektového manaţera jsou velmi vysoké. Manaţerem projektu se tak nemůţe stát kaţdý, neboť předpoklady pro výkon funkce v této profesi spočívají současně v kvalifikaci, schopnostech, návycích a osobních charakteristikách. 29

Většina projektových manaţerů se rekrutuje z pozic bývalých technických odborníků nebo poradců ve své oblasti. Ve většině případů se jedná o seniorní zaměstnance se zkušenostmi na pozicích liniových manaţerů, kteří cítili jistá rozhodovací omezení na těchto pozicích. Typickým projektovým manaţerem bývá osoba mezi 30 a 40 lety [4], protoţe v tomto věku jiţ získal dostatek zkušeností v určitém ekonomickém sektoru, má znalost s fungováním podniků a s řízením lidí. Má dostatečnou autoritu i v neformálních vztazích. S nabytými zkušenostmi přijímá přiměřená rizika, zbytečně neriskuje a v neposlední řadě má dostatek fyzických sil a dobré zdravotní předpoklady, aby mohl čelit náročným úkolům a výzvám vyplývajících z jeho funkce. Jak jiţ bylo uvedeno v kapitole 2. 5, v průběhu projektu „Nový ISPS“ měl autor této práce moţnost spolupracovat s více projektovými manaţery, a proto se tato část práce vrací k jiţ zmíněným osobním charakteristikám projektových manaţerů. Jelikoţ jedním z cílů této práce je provést porovnání projektových manaţerů, kteří se účastnili na projektu „Nový ISPS“, bude představena jedna z mnoha metod ohodnocení jednotlivých typů projektových manaţerů. V rámci studia odborné literatury nebo odborných zdrojů je moţné se občas s typologií projektového manaţera setkat, ale zpravidla se jedná o výčet vlastností a dovedností ideálního projektového manaţera nebo naopak o velmi komplikovaný skóringový model. Z těchto důvodů byla zvolena metoda určení typů projektových manaţerů vycházející z kompetenčního profilu projektového manaţera.[13] Pro určení typů projektového manaţera se vychází z pěti opravdu charakteristických a zásadních oblastí kompetencí projektového manaţera, které tvoří: Manaţerské dovednosti Věcná odbornost Techniky administrace Prezentace, komunikace Motivace, flexibilita, empatie Na základě převládající charakteristické kompetence je moţné popsat 5 základních typů projektových manaţerů. [13]

30

2.6.1. Šéf (převládající manaţerské a řídící dovednosti). Typický šéf má projekt vţdy pevně v rukách, umí rozdělovat, delegovat a kontrolovat úkoly, dodrţuje termíny, schůzky atd. V týmu udrţuje autoritu a pořádek, pro řízení vyţaduje zpravidla detailní a precizní poklady. Pokud dochází ke změnám či konfliktům, jejich řešení probíhá vţdy ve formálním duchu, dle předem daných pravidel. Jeho silnou stránkou je řád a perfektní organizace projektu, slabou stránkou a rizikem můţe být potlačení kreativity a projektového stylu práce, tj. v konečném důsledku aţ potlačení výhod projektového přístupu, niţší motivace týmu a někdy vyšší úsilí potřebné k dosaţení stejného cíle díky náročnému stylu řízení.

2.6.2. Odborník (převládající věcné odborné zázemí). Typický odborník je perfektně znalý předmětné problematiky projektu, dovede detailně řídit a posoudit jednotlivé odborné aktivity v projektu, přináší podněty a nápady pro realizační tým. Protoţe se často rekrutuje z řad bývalých specialistů (typicky např. v IT projektech bývalý vývojář), nemusí mít zkušenosti s vedením týmu, prezentací, vyjednáváním atd. Jeho silnou stránkou je perfektní znalost předmětu dodávky projektu, slabou stránkou aţ rizikem můţe být právě přílišná koncentrace na věcný aspekt na úkor řízení projektu jako takového, vedení týmu, prezentace projektu atd.

2.6.3. Úředník (převládající administrace a techniky). Typický úředník má precizní pořádek v projektové dokumentaci, vţdy přesně zpracuje a odevzdá v termínu všechny potřebné reporty, umí exaktně určit procento rozpracovanosti, spočítat kritickou cestu, určit utilizaci pracovníků. Jeho silnou stránkou je perfektní projektové „řemeslo“, schopnost zdokumentovat, spočítat či určit libovolné ukazatele, parametry atd. Slabou stránkou můţe být opomenutí lidského faktoru, který do tabulek a reportů vţdy vnáší neţádoucí prvek náhody, změny, entropie a činí tak z kaţdého projektu podnik s nejistým koncem.

31

2.6.4. Obchodník (převládající prezentační a komunikační dovednosti). Jeho silnou stránkou je excelentní komunikace a marketing projektu směrem k zainteresovaným stranám. Projekt dokáţe „prodat“ v kaţdém vývojovém stadiu a zpravidla je orientován více na vnější vztahy v projektu. V přípravné fázi projektu se často účastní prezentací a tvorby nabídek. Jeho silné stránky jsou tedy v oblasti prezentace a marketingu projektu a zpravidla je také velmi schopným vyjednavačem a umí pracovat s týmem. Alespoň kousíček obchodníka by měl mít v sobě kaţdý projektový manaţer. Slabé stránky a potenciální rizika mohou spočívat v nedostatečném projektovém řemesle a také někdy v určitém „klouzání po povrchu“ bez zájmu o konkrétní detail.

2.6.5. Tahoun (převládající motivace, flexibilita, empatie). Typický tahoun je orientován na projektový tým, budování a udrţování dobré atmosféry, úspěch projektu, kreativitu a inovaci. Tento typ často velice tvrdě pracuje, aby tím povzbudil i ostatní k vysokému pracovnímu výkonu. Současně se ale zajímá i o názory a problémy kaţdého člena týmu, je otevřený k diskusi a vţdy trpělivě naslouchá, nemá problém s inovacemi a změnami, kaţdou přijímá jako „hozenou rukavici“ a s vervou se pouští do řešení. Silnou stránkou tohoto typu je často přirozená schopnost uplatnění výhod projektového řízení, výborná práce s týmem, který zpravidla za ním stojí jako sportovní tým za svým kapitánem. Slabou stránkou a rizikem můţe být menší ochota k řešení konfliktů, krizí, problémů či změn, a také ad-hoc přístup k „řemeslným“ technickým dovednostem řízení, projektu např. plánování, řízení rizik, rozpočtu apod.[13] Samozřejmě jako u kaţdé typologie, v praxi neexistují výše uvedené „čisté“ archetypy a kaţdý projektový manaţer je určitým mixem všech uvedených typů, ale pro účely vyhodnocení jednotlivých typů projektových manaţerů je výše uvedené členění dostatečné. Závěrem této podkapitoly věnující se pozici projektového manaţera je uveden „Etický kodex projektových manaţerů“, o který před několika lety rozšířil Project Management Institut (PMI) standardy projektového managementu. Etický kodex vychází z předpokladů, ţe projektový manaţer je osobou, která můţe výrazně ovlivnit kvalitu ţivota 32

ve společnosti. Z těchto důvodů vyplývá, ţe je velmi důleţité, aby projektoví manaţeři při své práci dodrţovali etické normy a tím uchovávali na vysoké úrovni důvěru členů projektových týmů, představitele zákazníků a okolní veřejnosti.[4]

2.6.6. Etický kodex projektového manaţera Etický kodex projektového manaţera lze rozdělit do jednotlivých bodů: Odpovědnost vůči profesi a společenství, které spočívá: o přijetí plné zodpovědnosti za své aktivity, o převzetí odpovědnosti za vedení projektu pouze v případě, ţe on sám (ona sama) má pro daný projekt kvalifikaci nebo zkušenosti, nebo ţe je projekt obsazen odborníky, kteří tyto předpoklady splňují, o přikládání velké důleţitosti úrovni své vlastní kvalifikace, její udrţování a další rozvoj, o uţívání pokročilých metod řízení ve všech fázích ţivotního cyklu projektu, o vykonávání své profese se ctí a důstojností, poskytování osobního příkladu integrity, morálky a prestiţe, o uţívání a rozšiřování etického kodexu, podpora společenství manaţerů projektů, motivování k následování a účasti v profesionálních sdruţeních o dodrţování zákonů země, ve které je projekt realizován, odpovědnost vůči spolupracovníkům, jeţ poţaduje: o být lídrem a vést tým k maximální produktivitě práce v projektu, o jednat s lidmi ve svém okolí slušně, čestně a spravedlivě a bet rasových, náboţenských nebo jiných předsudků, o přispět k vytvoření dobrých pracovních podmínek, chránit fyzické i duševní zdraví účastníků projektu, o napomáhat členům projektových týmů v jejich osobním profesionálním rozvoji, odpovědnost vůči zaměstnavateli a klientům, jeţ předpokládá: o důvěryhodnost konání a jednání vůči všem uvedeným partnerům,

33

o zachování důvěrnosti všech informací spojených s realizací projektu, a to po dobu výkonu prací i po jejich skončení, pokud tyto nejsou uvolněny pro veřejnost, o podání informací o všech okolnostech, které by u něj mohli vést o střetu zájmů, o nepřijetí ţádných přímých nebo nepřímých darů, plateb nebo jiných sluţeb mimo těch, které jsou součástí oficiálních vztahů s těmito partnery, o čestný a realistický přístup k podávání informací o stavu projektu, odpovědnost vůči veřejnosti, která zahrnuje mimo jiné: o důslednou ochranu bezpečnosti, ţivotního prostředí, veřejného prospěchu a zájmu, o vyhledávání moţností, jak rozšířit veřejné podvědomí o profesi manaţerů projektů a zvýšit hodnocení jejich dosaţených výkonů.[4]

2.7. Projektový tým Projektový tým je hlavním výkonným článkem projektu. Jeho sestavení je jedním z prvních plánovacích kroků projektu. Pro úspěch projektu je velice důleţité stanovení organizační struktury projektu a nastavení jejích vztahů vzhledem k mateřské organizaci. Projektový tým a jeho členové jsou nominováni příslušnými liniovými manaţery nebo team leadery v rámci nominace zdrojů do projektu. Členové projektového týmu jsou zodpovědní za řešení úkolů, které jsou jim v projektu přiděleny. Člen projektového týmu můţe být nominován jako zástupce svého útvaru pro koordinování aktivit v rámci projektu nebo specialista se specifickou rolí definovanou v řídících dokumentech projektu. Člen projektového týmu reportuje projektovému manaţerovi a aktivně jej informuje o rizicích, změnách oproti plánu a všech aspektech, které mohou ovlivnit implementaci projektu z pohledu jeho role nebo jeho útvaru a navrhuje řešení. Člen týmu aktivně spolupracuje na přípravě projektových plánů. Kaţdý člen týmu je ale přímo zodpovědný za plnění svých úkolů. [2] Různé pojetí metodik řízení projektů sebou přináší i různé pracovní skupiny, týmy a jejich organizační struktury. V období klasického vedení projektů vznikaly základní typové organizační struktury pracovních týmů. V začátcích projektového managementu byly 34

budovány strukturované nebo nestrukturované týmy. Jak jiţ z popisu rozličných typů pracovních týmů vyplývá, hlavním rozdílem mezi oběma typy týmů je jejich vnitřní skladba, formální ustanovení a formalizace procesů. Nestrukturované pracovní týmy mají několik základních charakteristik. Tyto týmy nejsou vnitřně strukturované, nemají definovány funkce jednotlivých členů, jejich pracovní úkoly, odpovědnosti a pravomoci. Vztahy mezi členy nestrukturovaného pracovního týmu vznikají postupně na základě shody všech členů týmu. Vztahy jsou neformální a pozice vedoucího takového kolektivu vzniká na základě uplatňování autority. Jelikoţ ustanovení vedoucího týmu je neformální, je velmi obtíţné vymáhat zodpovědnost po vedoucím týmu. Základní členění nestrukturovaných pracovních týmů je následující: Osamělý vlk Horda Demokratická skupina [2] Zvláštním typem pracovního týmu je Osamělý vlk, který má pouze jednoho člena. Jediný člen tohoto typu „pracovního týmu“ řeší sám veškeré úkoly, které vyplývají z projektu a spadají do přidělené oblasti projektu. Osamělý vlk bývá vyuţíván v rámci jednoduchých projektů nebo je nasazován na velmi specializované části projektů. U rozsáhlejších projektů není tento typ „pracovního týmu“ efektivní, a proto nebývá vyuţíván. Dalším typem nestrukturovaného pracovního týmu je Horda. Jak jiţ název napovídá, jedná se mnohačetný pracovní tým. Členové týmu jsou si rovni, mají přibliţně stejné znalosti a dovednosti. Členové Hordy mohou vykonávat na projektu v podstatě totoţné činnosti, ale ne všichni z nich sdílejí společné vize a hodnoty. Ve většině případů se pracovní týmy typu Horda pouţívají na určitý významný objem práce s představou, ţe více zapojených pracovníků rychleji úkol zpracuje. K vyuţití pracovního týmu Horda dochází ve chvílích, kdy se projektový manaţer snaţí zaţehnat hrozící riziko vyplývající z nedodrţení plánovaných termínů nebo naopak ve snaze zkrátit termín dokončení projektu. Manaţer projektu by si však měl uvědomit, ţe je nutné splnit určité předpoklady, které jsou pro úspěch týmu Horda nezbytné. Zvláště u projektů, kde se jedná o kvalifikovanou duševní práci, by měli mít pracovníci odpovídající vzdělání, aby členové týmu dobře rozuměli řešení problému a byli s ním dobře seznámeni. V neposlední řadě větší počet pracovníků 35

klade větší nároky na jejich řízení a nastavení komunikačních toků. Pokud není nasazení většího počtu pracovníků doprovázeno úpravou organizační struktury projektu, tak není prakticky moţné dosáhnout pozitivního efektu.[2] Posledním, jiţ zmíněným typem nestrukturovaného týmu, je Demokratická skupina. Tento tým funguje na obdobných principech jako výše uvedený tým Horda. Hlavním rozdílem je společné sdílení vize projektu u všech členů tohoto typu týmu. Rovněţ dělba práce uvnitř týmu je odlišná od týmu typu Horda. Úkoly se nedělí na stejné díly nebo náhodně, ale členové týmu se o úkoly hlásí samostatně dle svých odborných znalostí nebo zkušeností. Postupem času vzniká přirozená vnitřní struktura týmu dle specializace jednotlivých členů týmu [2] a z nestrukturovaného týmu se postupem času stává tým strukturovaný. Strukturované pracovní týmy jsou dalším evolučním krokem ve vývoji projektových organizačních struktur. Hlavním důvodem proč jsou dnes do řešení praktických projektů nasazovány strukturované pracovní týmy, je zvládnutí obchodního rozměru projektu a jeho propojení s technologickou a procesní dimenzí projektu. Strukturovaný pracovní tým má formálně jmenovaného vedoucího pracovníka. Vedoucí pracovník má společně se jmenování určeny odpovědnosti a pravomoci. Zároveň jsou mu přiděleny nástroje, které mu umoţňují efektivní vedení jednotlivých členů týmů. Dalším důvodem pro ustanovení strukturovaného týmu, jsou projekty, u kterých je nutné vytvořit společné týmy ze zaměstnanců vlastní společnosti a externího dodavatele. Volba vhodného typu projektového týmu do organizačních struktur projektu je závislá na velikosti projektu a rovněţ i na typech pracovníků, kteří jsou pro realizaci projektu určeni.

2.8. Agilní metodiky Agilní projektové řízení je interaktivní způsob řízení projektů. Je protikladem rigorózního řízení projektů, tzv. vodopádového řízení. Agilní přístup je zaloţený na průběţném upřesňování cíle projektu díky interakci a budoucím zákazníkem či s uţivateli výsledků projektu, na pruţných reakcích na změny, a průběţném rozvrhování práce v průběhu projektu. Agilní přístup je vhodný pro takové projekty, kde dochází k vývoji produktu 36

nebo cíli projektu. Agilní přístup k řízení projektů se uplatňuje v projektech, u kterých je jasný rámcový cíl, ale z nejrůznějších důvodů nelze přesně definovat všechny dlouhodobé poţadavky bez průběţných prototypů. Pouţívá se tedy, kdyţ nelze určit detailní plán projektu včetně detailních poţadavků, coţ je postup typický pro rigorózní přístup. Agilní přístup k řízení projektů je interaktivní, pruţný a přírůstkový. V praxi to znamená těsnou a neustálou (inkrementální) spolupráci mezi projektovým týmem, který vytváří průběţné prototypy a mezi zákazníkem, který dává zpětnou vazbu na základě, které se upřesňuje zadání. Agilní řízení projektů se proto uplatňuje u velmi komplexních systémů, u kterých se detailní poţadavky tvoří nebo upřesňují průběţně na základě zkušeností s prototypy z jednotlivých iterací. Při agilních metodách práce se realizují malé porce výsledků (prototypy) v kaţdém vývojovém cyklu v těsné spolupráci se zákazníkem.[11] Agilní přístup k řízení projektů vyţaduje schopné jednotlivce, kteří jsou schopni tento způsob řízení zvládnout. Není moţné jej univerzálně uplatnit vţdy, ve všech typech projektů a ve všech týmech. Uplatňuje se ve vývoji software, ale stejně tak dobře v ostatních oblastech, kde je projekt silně inovační, vyţaduje průběţné korekce a nápady a je moţné vše průběţně komunikovat se zákazníkem. Agilní přístup k řízení projektů má blízko k lean technikám a přístupům jako je Kaizen nebo Six Sigma, protoţe má silně prozákaznický charakter, všechny aktivity v průběhu vývoje jsou zaměřené účelově na dosaţení poţadovaného výsledku a tím je minimalizováno plýtvání výrazněji neţ u tradičních postupů. Stejně jako tradiční metoda řízení projektu se opírá o čtyři fáze, které jsou stavebními kameny pro rigorózní řízení projektu, tak agilní management stojí na třech základních pilířích.[8] Prvním z pilířů agilního projektového managementu je konsolidovaný seznam všech poţadavků a idejí týkající se činnosti organizace nebo jejich oddělení. Tento soupis poţadavků a nápadů je vhodné sbírat pomocí standardizovaného formuláře. K jednotlivým poţadavkům či ideám jsou přiřazeny priority. Přidělením priorit dochází k oddělení poţadavků na realizaci od idejí, které zůstávají zaparkovány do další prioritizace. 37

Stanovování priorit by mělo probíhat v pravidelných intervalech. Pro řízení poţadavků lze pouţívat jako podpůrné nástroje specializované systémy, ale i běţně dostupný kancelářský software. Druhým pilířem agilního vedení projektu je definice tzv. Sprintu. Sprint se skládá ze seznamu poţadavků s nejvyšší prioritou. Sprint je typicky definován pevně v délce jednoho aţ čtyř týdnů, ve kterém dochází k realizaci zahrnutých poţadavků. Výstupem Sprintu je prototyp, který je projednáván s objednavatelem projektu a na základě jeho ověření dochází k změně definice Sprintu nebo reprioritizaci poţadavků, které se řadí do dalšího Sprintu. Posledním, tedy třetím pilířem projektů vedených agilní metodou jsou pravidelné meetingy. Uskutečnění jednotlivých sprintů je řízeno prostřednictvím meetingů. Tyto schůzky se vyskytují v průběhu kaţdého sprintu v několika obměnách. Na začátku probíhá plánovací schůzka, kde dochází k vymezení poţadavků ze seznamu do daného sprintu. Na plánovací schůzku navazují krátké denní mítinky, kde se schází celý tým a prezentují se výstupy z předchozího dne, řeší se zjištěné problémy a stanovuje se plán na další den. Výstupní meeting pak obsahuje prezentaci prototypu, jehoţ bylo dosaţeno. Klíčovým nástrojem pro podporu jednotlivých typů schůzek je pouţívání reportu, který srovnává plánovanou a skutečnou práci zbývající do konce sprintu. Pojem agilní metodiky se začal pouţívat od roku 2001, přestoţe techniky agilní metodiky jiţ byly známy dříve. Původně byly agilní metodiky určeny k vývoji softwaru. Dnes jiţ agilní metodiky našly své uplatnění také v jiných oblastech neţ je programování. S agilním přístupem se můţeme setkat u marketingového plánování nebo v Business Intelligence. Mezi známé agilní metodiky patří Extrémní programování (XP), Scrum, Feature Driven Development (FDD) a Lean development.

2.9. Metodika Scrum Pro detailnější popis agilních metodik byla zvolena metodiku Scrum, která je následně pouţita pro komparaci s tradiční metodikou, kterou byl realizován v Penzijní společnosti projekt „Nový ISPS“. 38

Historie metodiky Scrum se váţe k roku 1986. V tomto roce se v časopise Harvard Business Review poprvé objevil článek popisující praktiky úspěšného vývoje produktu v týmech. Článek popisoval metodiku na praktikách hry rugby, která je rychlá a adaptivní. Díky přirovnání k rugby, ale hlavně k ragbyovému mlýnu tedy skrumáţi, vykrystalizoval během let název Scrum. Jako oficiální zaloţení metodiky se uvádí rok 1995, kdy byla metodika představena na konferenci OOPSLA (Object-Oriented Programming, Systems, Languages and Applications). V roce 2001 vyšla kniha Agile software development with Scrum, jejímţ autorem je Ken Schwaber, a která podává ucelený popis metodiky Scrum. Ken Schwaber v knize shrnul dosavadní práci na metodice Scrum, kterou spolu s kolegou Jeffem Sutherlandem od počátku 90. let na vývoji metodiky vykonali.[8] „Scrum je procesní rámec, který se používá na řízení vývoje komplexních produktů. Samotný Scrum není proces, ani technika pro vytváření produktů, ale je to pouze rámec, který umožňuje zapojení různých procesů a technik.“[8] Metodika Scrum se opírá o tři hlavní pilíře, kterými jsou transparentnost (Transparency), kontrola (Inspection) a adaptaci (Adaptation). Projekty řízené metodikou Scrum by se měly o tyto pilíře opírat. Transparentnost

znamená,

ţe

plánování,

cíle

a

výsledky

budou

jednoznačné

a srozumitelné. Krátkodobé a dlouhodobé cíle musí být jednoznačně formulované a hlavně musí být reálné. Měřitelnost dosaţených cílů musí být předem jasně definována. Transparentnost se netýká jen aspektů týkajících se finálního produktu či sluţby, ale i veškerého procesu vývoje a postupu týmu. Pro tyto účely jsou určeny grafy Release Burdown a Sprint Burdown, které obsahují aktuální informace o pokroku týmu. Transparentnost v reálném průběhu projektu znamená, ţe všichni účastníci projektu musí pouţívat stejnou terminologii týkající se projektu a definice cíle musí být konkrétní a stejná pro dodavatele i odběratele produktu. Dalším pilířem je Kontrola. Tento pilíř je významně napojen na pilíř Transparentnost. Pokud jsou správně nastavena v průběhu projektu pravidla transparentnosti, pak lze snadno nad těmito pravidly zavést kontrolu. Kontrola má svá pravidla. Revizi je dobré provádět v pravidelných intervalech a na procesech, které mají přímý dopad na dílčí nebo celkový 39

výsledek produktu. Kontrola je velmi často podceňovaným prvkem, ale ve skutečnosti se jedná o velmi důleţitou činnost. Z tohoto důvodu je třeba nepodceňovat tento pilíř Scrumu. Kontrolu by měli provádět odborníci na kontrolovanou činnost. Kontrolou průběhu projektových činností se dá předejít budoucím nepříjemnostem a včas identifikovat hrozící rizika. Podceněním kontroly můţe dojít v konečném důsledku ke značným časovým a finančním dopadům na celkový průběh a rozpočet projektu. Posledním pilířem je Adaptace. Tento pilíř je hlavním odlišujícím prvkem agilní metodiky vedení projektu od tradičního pojetí vedení projektu. V pojetí agilního vedení projektu jsou změny v poţadavcích vítaným prvkem, a to i v pozdějších fázích tvorby finálního produktu,

protoţe

agilní

procesy

podporují

změny

vedoucí

ke

zvýšení

konkurenceschopnosti finálního produktu a k získání konkurenční výhody. Tento přístup Scrum zpracovává pravidelnými poradami: Daily Scrum Meeting – jedná se o kaţdodenní setkání všech členů vývojového týmu v průběhu Sprintu. Účelem je kontrola a adaptace prováděných prací. Sprint Planning Meeting – je plánovacím meetingem pro Sprint. Záměrem meetingu je rozhodnout co se bude ve Sprintu realizovat a jakým způsobem absorbovat případné změny definovaných funkcionalit. Sprint Review – je hodnotící schůzkou po ukončení Sprintu a zhodnocení jeho celkového přínosu. Sprint Retrospective – tento meeting prověřuje, jak fungoval poslední Sprint z pohledu lidí, vztahů, nástrojů a procesů. [8]

2.9.1. Ţivotní cyklus Ţivotní cyklus projektu vedeného metodikou Scrum je oficiálně zahájen Release Planning Meetingem. [8] Cílem Reelease Planning Meetingu je stanovení plánu a cíle projektu, tak aby byl srozumitelný všem zúčastněným stranám projektu. Dalším cílem je vytvoření produktového backlogu a grafu Release Burndown. V rámci Realese Planning Meeting jsou rovněţ definována rizika projektu. Pro účely objednavatele je nastíněna časová a finanční náročnost celého projektu, ale vzhledem k tomu, ţe v průběhu projektu můţe dojít ke změnám, které jsou vítány, tak tato informace nemá pro samotný průběh projektu 40

vysokou důleţitost. Záměrem Realese Planning Meetingu je nastolení směru, kterým se bude projekt ubírat. Produktový backlog [8] tvoří základní kámen projektu. Můţeme si jej představit jako seznam, který obsahuje zdroj poţadavků pro jakékoli práce, úkony a změny projektu. Tento seznam není neměnný. Po celou dobu průběhu projektu se produktový backlog vyvíjí a v závislosti na něm se mění a vyvíjí celý projekt. Po celou dobu projektu se do tohoto seznamu zaznamenávají všechny poţadavky, rozšíření a opravy, čímţ se určují změny pro implementaci pro další nasazení. Produktový backlog je strukturovaný a kaţdá poloţka má své atributy mezi které patří popis dané poloţky, odhad časové náročnosti a určení priority. Priorita je velmi důleţitým atributem poloţky, protoţe seznam je řazen dle důleţitosti priority od nejdůleţitějších po méně důleţité. Přiřazením příslušné priority se řídí pořadí řešení úkolů. Důleţitým atributem je také popis dané poloţky. Čím detailnější popis dané poloţky seznamu existuje, tím vyšší je předpoklad pochopení úkolu, správné realizace a přesnosti odhadu časové náročnosti. Změny v produktovém backlogu provádí pouze Vlastník produktu, člen Scrum týmu s výjimečnou pozicí, jehoţ popisu se budu věnovat v jednom z následujících odstavců. Vlastník produktu je zodpovědný za obsah produktového backlogu, respektive je zodpovědný za určení časových odchylek mezi reálným průběhem projektu a plánovaným průběhem prací. K tomuto účelu slouţí graf Release Burndown,[8] který prostřednictvím tzv. Story points (alternativní časová jednotka pouţívaná v projektech) zobrazuje skutečný stav průběhu projektu.

Obrázek 4 - Ukázka Release Burndown grafu [zdroj scrumalliance]

41

Na příkladu grafu Release Burndown jsou modře označeny Story Points, které zbývá dodělat, červeně jsou označeny Story Points, které byly přidány a zeleně zbarvené Story Points zobrazují části, které byly odebrány. Ţlutá křivka zobrazuje ideální průběh projektu. Jestliţe produktový backlog je základním kamenem metodiky Scrum, pak srdcem Scrumu je Sprint.[8] Sprint vzniká z produktového backlogu , který se v rámci jednotlivých iterací rozdrobí na Sprint. Sprint začíná Sprint Planning Meetingem účelem kterého je stanovit sprintový backlog. Sprintový backlog má podobnou funkci jako produktový backlog, ale vztahuje se pouze ke konkrétnímu Sprintu. Jednotlivé poloţky spritového backlogu jsou rozepsány tak, aby jejich realizace netrvala déle neţ jeden člověkoden. Sprintový backlog specifikuje práci, kterou vynaloţí vývojový tým na to, aby přetvořil poloţky produktového backlogu na přidanou hodnotu celého projektu a tím dosáhl cíle Sprintu. Obvyklá délka kaţdého Sprintu trvá přibliţně dva aţ čtyři týdny a postup na vývoji je revidován denním Srum meetingem. Délka trvání Sprintu by neměla překročit jeden měsíc. Měsíční a kratší sprintové iterace jsou voleny z důvodu eliminace špatného časového odhadu prací a z důvodu průhlednosti řešení. Během Sprintu pracuje vývojový tým na přírůstku projektu. Výsledkem kaţdého sprintu by u IT projektů měl být nasaditelný předem definovaný produkt, který pro objednavatele má přidanou hodnotu. Obdobně jako produktový backlog má svůj graf, tak i sprintový backlog má svůj graf, kterým je Sprint Burndown. Jednotkou času jiţ však nejsou Story points, jak tomu bylo u Release Burndown grafu, ale hodiny, které zbývají vývojovému týmu na dokončení daného Sprintu. Graf Sprint Burndown neslouţí pouze k poskytnutí informací o aktuálním stavu prací na příslušném Sprintu, ale pomáhá při naplánování dalších Sprintů, především jejich časového harmonogramu. Díky několika absolvovaným Sprintům dokáţe vývojový tým lépe určit časovou náročnost dalších úkolů. V průběhu Sprintu se kaţdodenně setkává vývojový tým na krátké maximálně patnácti minutové schůzce tzv. Daily Scrum meetingu, jejímţ cílem je synchronizace aktivit a plán na další pracovní den. Součástí schůzky je i odečet stavu Sprintu ke grafu Sprint Burndown. Prostřednictvím kaţdodenních plánovaných schůzek se výrazně eliminuje riziko neúspěchu Sprintu a nemělo by docházet k situacím, ţe dodané řešení se rozchází s poţadavkem Vlastníka produktu. Po ukončení ať jiţ úspěšného nebo neúspěšného Sprintu následuje Sprint Review. V rámci Sprint Review probíhá celkové vyhodnocení Sprintu. Je prezentovaný vytvořený přírůstek produktu. Sprint Review se účastní i objednavatel, který si můţe ověřit postup prací na 42

projektu. Na základě představených výsledků, postupů, dosaţených úspěchů či neúspěchů se volí další postupy, které následně mohou mít dopad na změny v produktovém backlogu. Sprint Review má stanovenu, jak délku trvání, tak i strukturu. Při uvaţované délce Sprintu jeden měsíc, bývají pro Sprint Review vyhrazeny čtyři hodiny. Jak bylo zmíněno, Sprint Review je strukturovaný a jeho agenda se skládá z těchto bodů: Vlastníkem produktu je definováno, co je jiţ z jeho pohledu dokončeno a co ještě zbývá dokončit Vývojový tým v rámci diskuze provede zhodnocení Sprintu. Jsou diskutovány nejen problematické úseky Sprintu, kdy se nedařilo řešit problémy, ale jsou diskutovány i způsoby jak byly problémy řešeny. Dále se probírají i části Sprintu, které se vývojovému týmu dařilo řešit úspěšně. Tato diskuze má slouţit k definici vzniku příčin problémů v průběhu Sprintu a má napomoci vyvarování se jejich opakování v dalších Sprintech. Vývojový tým prezentuje přírůstek vytvořený v průběhu právě ukončeného Sprintu a zodpovídá případné dotazy objednavatele nebo Vlastníka produktu, které se týkají tohoto přírůstku. Vlastník produktu provádí aktuální zhodnocení stavu produktového backlogu. Na základě revize stavu produktového backlogu odhaduje Vlastník produktu pravděpodobný termín ukončení projektu. Závěry ze Sprint Review jsou současně vstupem pro nový Sprint. Účastníci Sprint review navrhují další postup prací na projektu. Výstupem Sprint Review je revidovaný produktový backlog, který je obohacen o doporučení, kterým poloţkám by se měl následující Sprint primárně věnovat. Tento výstup slouţí, jako podklad pro finální podobu sprintového backlog, o které rozhoduje Sprint Planning Meeting. Závěrečným zhodnocením ukončeného Sprintu je meeting Sprint Retrospective,[8] který slouţí členům Scrum týmu k sebekontrole a ke zlepšení činnosti v následujícím Sprintu. Vychází se z nabitých zkušeností z minulých Sprintů. Sprint Retrospectiva má přímou souvislost s dvěma pilíři metodiky Scrum a to konkrétně s Transparentností a Kontrolou. Smyslem Sprint Retrospective je provést kontrolu toho, jakým způsobem probíhal poslední Sprint z pohledu členů týmu, vztahů, procesů a pouţitých nástrojů. Měly by být 43

identifikovány aspekty, které fungovaly dobře a u kterých je potřeba zlepšení. Seznam navrţených zlepšení, která se budou aplikovat v nadcházejícím Sprintu, je výstupem z meetingu Scrum Retrospectvive. Pro úspěch projektu vedeného metodikou Scrum je nutná transparentní definice ukončení projektu, aby všichni účastníci projektu stejně chápali a byli schopni definovat okamţik, kdy je projekt u konce. Definice ukončení je ostatně důleţitá i pro jednotlivé Sprinty, jejichţ prostřednictvím se realizují průběţné přírůstky finálního produktu.

2.9.2. Scrum tým Další odlišností agilních metodik a konkrétně je tomu tak i u metodiky Scrum je definice Scrum týmu [8] a rolí v tomto týmu. Scrum tým lze rozdělit na vnější mnoţinu rolí, kterou tvoří uţivatel produktu, objednavatel produktu a management. Vnitřní mnoţinu rolí tvoří vývojový tým pod vedením tzv. Scrum Mastera. Spojnici mezi oběma mnoţinami tvoří Vlastník produktu, který musí komunikovat s vnitřními a vnějšími typy rolí v rámci projektu.

2.9.3. Vlastník produktu Vlastník produktu v metodice Scrum je v podstatě obdobou pozice Sponzora projektu v rigorózních metodikách, s přesahem do pozice Projektového manaţera. Vlastník produktu musí být respektovaný a podporovaný celou organizací. Je zodpovědný za maximalizaci hodnoty produktu tvořeného v průběhu projektu. Je jedinou osobou, která je odpovědná za správu produktového backlogu. Úkolem Vlastníka produktu je jasné specifikování poloţek a prioritizace poloţek produktového backlogu. Vlastník produktu dále musí zajistit, aby poloţky produktového backlogu byly srozumitelné pro vývojový tým. Tvůrci metodiky Scrum doporučují, aby Vlastníkem produktu byla jedna osoba, nikoli více osob. To má v praxi za následek, ţe pokud má skupina osob, například představenstvo společnosti objednavatele, poţadavky na úpravu produktového backlogu, musí o provedení změn nejprve přesvědčit Vlastníka produktu. Vzhledem ke skutečnosti, ţe produktový backlog je základním kamenem metodiky Scrum a Vlastník produktu je

44

osobou zodpovědnou za jeho obsah, je zcela zřejmé, ţe správná volba při obsazení pozice Vlastníka produktu je důleţitým krokem pro finální úspěch celého projektu.

2.9.4. Vývojový tým Úloha Vývojového týmu v metodice Scrum je jednoznačná. Úkolem týmu je vytvořit finální produkt prostřednictvím průběţných přírůstků produktu na konci kaţdého Sprintu. Vývojový tým má specifické vlastnosti, mezi které patří samostatnost. Do průběhu vývoje produktu respektive přírůstku produktu nikdo Vývojovému týmu nevstupuje. Organizace vývoje je plně v kompetenci Vývojového týmu. Skladba členů Vývojového týmu by měla být taková, aby znalosti jednotlivých členů týmu, pokryly veškeré potřeby vývoje produktu. Členové týmu se specializují díky své odbornosti na určité oblasti vývoje produktu, ale zodpovědnost za výsledek nese celý Vývojový tým. Členi Vývojového týmu jsou si rovni, a to bez ohledu na to, jakou činnost jednotlivý člen týmu na vývoji vykonává. Velikost Vývojového týmu je vţdy závislá na parametrech projektu. Obecná poučka říká, aby Vývojový tým byl tak malý, aby byl dostatečně pruţný, ale tak velký, aby odvedl významný objem práce. V praxi jsou tvořeny Vývojové týmy třemi aţ devíti členy, ale menší nebo větší počet členů Vývojového týmu není problémem pro úspěšné vedení projektu.

2.9.5. Scrum master Pozici Scrum Mastera [8] lze definovat jako vedoucího Vývojového týmu, ale bez formální autority. Scrum Master je součástí Vývojového týmu a jeho hlavním úkolem je, aby členové Vývojového týmu správně rozuměli metodice Scrum a dodrţovali postupy metodiky na projektu. Dalším a neméně důleţitým úkolem Scrum Mastera je zajištění komunikace mezi Vlastníkem produktu a Vývojovým týmem. Portfolio povinností Scrum Mastera vzhledem k ostatním účastníkům projektu je přehledně rozděleno do tří skupin dle poskytovaných sluţeb ostatním rolím na projektu či organizaci. Ve vztahu k organizaci vystupuje Scrum Master jako nositel znalosti metodiky Scrum a z této pozice napomáhá při implementaci metodiky Scrum do organizace. Představuje zaměstnancům organizace metodiku Scrum a pomáhá jim porozumět empirickému vývoji 45

produktu. Nabádá zaměstnance k vyhledávání a uskutečňování změn, které zvýší produktivitu vývojových prací a navýší hodnotu finálního produktu. Členům Vývojového týmu poskytuje Scrum Master podporu při samoorganizovaní Vývojového týmu a sloţení Vývojového týmu. Scrum Master zdokonaluje Vývojový tým v oblasti tvorby srozumitelných a výstiţných výstupů k jednotlivým poloţkám produktového backlogu srozumitelných. Pomáhá při odstraňování překáţek uvnitř Vývojového týmu a v případě potřeby dohlíţí na průběh a efektivnost Scrum meetingů. Scrum Master rovněţ funguje jako metodická podpora pro Vlastníka produktu při definování produktového backlogu.

46

3. Projekt výměny informačního systému 3.1. Zvolená metodika řízení projektu Základní principy projektového řízení ve finanční skupině, jejíţ součástí je Penzijní společnost, vychází z principů metodiky PRINCE2. Z tohoto důvodu byly při volbě metodiky řízení projektu zohledněny zásady a interní předpisy finanční skupiny. Pro řízení projektu náhrady informačního systému v Penzijní společnosti byla zvolena metodika PRINCE2. Jedná se o rigorózní metodiku řízení projektů. Projects in controlled environment – PRINCE je ve své podstatě strukturovaná metodika pro efektivní řízení projektu. Poprvé byla vydána v roce 1989 ve Velké Británii. Společnost CCTA (the Central Computers and Telecomunications Agency), která metodiku PRINCE představila, navázala na projekt PROMPTII , tedy metodiku pro řízení projektů vytvořenou v roce 1975. Společnost CCTA pokračovala na úpravách a vývoji metodiky a v roce 1996 vydala standard PRINCE2, který v té době odpovídal na nové problematické

oblasti

projektového

řízení.

PRINCE2

je

jednou

z

největších

a nejznámějších metodik projektového řízení. Projects in Controlled Environment byla zformulována více neţ sto padesáti společnostmi s několikaletými zkušenostmi z oboru projektového řízení. Jelikoţ metodika PRINCE2 vychází z evropského prostředí, je tudíţ velmi blízká smýšlení běţnému v evropských podmínkách. Počty certifikovaných projektových manaţerů na tuto metodiku se počítají na sta tisíce a jako metodiku organizace si PRINCE2 zvolily významné vlády zemí Evropy, ale i OSN, NATO nebo mnoho komerčních společností. [11] Metodika PRINCE2 je metodikou, která od svého vzniku prochází pravidelnými změnami, aby byla schopna řešit nové otázky vznikající v průběhu projektového řízení. Některé úpravy jsou kosmetické, ale přibliţně jednou za pět let projde metodika podstatnější revizí. Poslední takováto revize proběhla v roce 2009 na základě poţadavků mnoha uţivatelů a dala vznik nové edici – PRINCE2 2009.

47

Základní principy řízení projektu vycházely z definice 7 hlavních principů metodiky PRINCE2, kterými jsou: Průběţné zdůvodnění projektu (Continued business justification) – projekt běţí a je zařazen v portfoliu projektů na základě odůvodněných a obhajitelných přínosů, nákladů a je v souladu se strategií banky. Poučme se ze zkušeností (Learn from experience) – projektové týmy pracují s lessons learned (získanými zkušenostmi) z předchozích projektů, lessons learned jsou v rámci organizace sbírány, ukládány a jsou k dispozici stakeholderům projektového řízení. Definované role a zodpovědnosti (Defined roles and responsibilities) – projekty mají definované a schválené projektové zdroje a zodpovědnosti, včetně zástupců businessu, uţivatelů a dodavatelů. Řízení pomocí fází (Manage by stages) – projekty jsou plánovány, schvalovány a kontrolovány po jednotlivých projektových fázích/stage. Dohled nad projektem na základě výjimek (Manage by exception) – projekty jsou dodávány dle odsouhlaseného plánu. Jednotlivé řídící úrovně jednají a dodávají samostatně. Vyšší úrovně řízení jsou zapojovány pouze v případě eskalovaného rizika nebo reálného překročení tolerančních limitů na úrovních niţších. Důraz na produkty (Focus on products) – výstupy projektu jsou definovány jako produkty, které mají jasné kvalitativní parametry. Přizpůsobení metodiky prostředí, ve kterém se projekty řídí (Tailor to suit the project environment (tailoring)) – projektová metodika je univerzální pro různé typy, velikosti, priority, kondici a rizikovost projektů. Předchozí principy formují základy metodiky projektového řízení: Obchodní zdůvodnění projektu. Projekt je zdůvodněn pomocí Business Case, který je vytvořen ve dvou krocích. Nejprve na hrubo tak, aby mohlo být schváleno čerpání zdrojů (lidských i finančních) pro fáze procesu „Starting up a Project“ a následně „Initiating a Project“. Dále pak jako výstup fáze procesu „Initiating a Project“ a podklad pro schválení dalších fází proces „Controlling a stage“. Striktní oddělení projektových a liniových rolí. Do projektové role jsou jmenováni pracovníci maximálně na dobu trvání projektu a musí jim být jednoznačně

48

komunikovány zodpovědnosti spojené s projektem. Nelze očekávat, ţe rozsah projektové role implicitně vyplývá z liniové pozice. Rozdělení do fází/stage. Projekt musí respektovat rozdělení do fází/stage. Během iniciace projektu je vypracován projektový plán, který obsahuje návrh všech fází/stage, jejich obsah, scope a finanční rozpočet.

3.1.1. Zahájení projektu implementace nového informačního systému Před zahájením projektu implementace nového informačního systému pro Penzijní společnost, muselo vedení tehdy ještě Penzijní fondu předloţit a obhájit strategický plán před vedením mateřské společnosti. Penzijní společnost je součástí významné finanční skupiny působící v České republice a mateřská společnost je zároveň jediným akcionářem Penzijní společnosti. Strategický plán Penzijní fondu reagoval na legislativní změny v oblasti důchodového spoření. Představoval nové produkty, které úprava legislativy přinášela, a zároveň prezentoval nové obchodní příleţitosti na trhu penzijního spoření a s tím spojenou transformaci Penzijního fondu na Penzijní společnost. Obhajoba tohoto plánu nebyla jednoduchá, protoţe investice spojené s transformací Penzijní fondu a s uvedením dvou nových produktů na trh, byly z pohledu akcionáře velmi vysoké a návratnost těchto investic byla velmi nejistá. Nejistotu akcionáře prohlubovala i politická situace v České republice, kdy názory na důchodovou reformu nebyly jednotné a výrazně se lišily z pohledu pravicových a levicových stran. Nejvíce kontroverzní bylo zavedení tzv. 2. pilíře neboli důchodového spoření, o kterém levicové strany prohlásily, ţe v případě jejich vítězství v následujících volbách, bude jedním z jejich prvních kroků zrušení tohoto finančního produktu. Přes výše uvedenou nejistotu se podařilo Penzijnímu fondu získat souhlas akcionáře se zahájením přeměny Penzijního fondu na Penzijní společnost, která bude poskytovat doplňkové penzijní spoření, důchodové spoření a původní penzijní připojištění. Rozhodnutí o zahájení transformace Penzijního fondu padlo v říjnu roku 2011, kdy jiţ bylo jasné, ţe nové zákony upravující důchodové spoření vstoupí v platnost a ţe nabudou účinnosti od 1. 1. 2013. Penzijní fond představil v listopadu 2011 v rámci předprojektové fáze nutné potřeby k úspěšné přeměně organizace na nízkonákladovou Penzijní společnost. V tomto kroku příprav projektu bylo zjištěno, ţe Penzijní fond musí projít legislativní změnou a získat

49

novou licenci k poskytování sluţeb. Dále musí být provedena změna v oblasti distribuce produktů. Při seznámení se s rozsahem nových nabízených produktů bylo identifikováno, ţe stávající informační systém nedokáţe pokrýt veškeré nově vzniklé funkcionality a s přihlédnutím k další ambici, kterou byla přeměna na nízkonákladovou společnost, vyvstala potřeba získání nového informačního systému. Jelikoţ Penzijní fond neměl doposud zkušenosti s vedením takto rozsáhlého projetu a v jeho řadách nepracoval nikdo s dostatečnými profesními znalostmi pro obsazení pozice projektového manaţera, muselo vedení společnosti získat na tuto pozici externistu. Po identifikaci výše uvedených potřeb oslovil Penzijní fond projektovou kancelář, která je organizační sloţkou mateřské společnosti, se ţádostí o poskytnutí projektového manaţera na dobu realizace projektu, tedy do prosince 2012. Vedení Penzijního fondu obdrţelo nabídku dvou vhodných kandidátů a po mini interním výběrovém řízení se rozhodlo angaţovat do pozice projektového manaţera, kandidáta, který měl zkušenosti s vedením rozsáhlých projektů napříč celou finanční skupinou. Prvním z kroků projektového manaţera byl sběr informací o vnitřní struktuře, zvyklostech a chodu Penzijního fondu. Toto bylo realizováno jednak z oficiálních dokumentů, kterými jsou vnitřní řády a směrnice společnosti, ale i osobními rozhovory s členy vrcholového a středního managamentu Penzijního fondu. Následně projektový manaţer provedl analýzu okolí Penzijního fondu. Toto bylo prováděno z oficiálně dostupných zdrojů. Pokud se jednalo o smluvní partnery Penzijního fondu, tak zdrojem informací byly uzavřené mandátní smlouvy, prováděcí smlouvy nebo smlouvy o poskytnutí sluţeb. Pokud se jednalo o konkurenci na trhu důchodového spoření, byly tyto informace získány z veřejně dostupných zdrojů. Po získání ucelené představy o stávající situaci uvnitř a vně Penzijního fondu, představil projektový manaţer návrh dalšího postupu, který by měl úspěšně zrealizovat přeměnu společnosti. Ke zdaru transformace měl vést programový management, tedy organizování několika rozsáhlých projektů víceméně na sobě nezávislých. Transformační program dostal název „PETRUS“ (Pension TRansformation Under Speed). Jedním z projektů transformačního programu byla implementace nového informačního systému. Zadání projektu implementace nového informačního systému připravil sponzor projektu, kterým se stal člen představenstva a zároveň ředitel provozního úseku Penzijního fondu. Vzhledem k organizační struktuře Penzijního fondu byla volba sponzora projektu poměrně 50

jednoznačná, protoţe provozní úsek je tou částí organizace, která nejvíce vyuţívá sluţeb informačního systému a zároveň je svým nastavením interních procesů na informačním systému nejvíce závislá. Dalším dílčím důvodem je skutečnost, ţe v liniové organizační struktuře penzijního fondu, je součástí provozního úseku i oddělení informačních technologii. Součástí formálního zadání projektu byl předběţný popis finálního produktu, byly identifikovány poţadavky na zdroje a byl stanovený předběţný cíl projektu. Cílem projektu „Nový ISPS“ bylo vytvoření nové aplikace, která pokryje veškeré zákonem stanovené poţadavky na evidenci a správu účastníků důchodového spoření a doplňkového penzijního připojištění, ale zároveň pokryje i poţadavky Penzijní společnosti na výkon a efektivitu procesů nezbytných k obsluze účastníků spoření. Další podmínkou pro dosaţení cíle projektu bylo, aby nová aplikace byla podporována moderní softwarovou technologií. Posledním cílem projektu mělo být nahrazení stávajícího informačního systému vyuţívaného Penzijním fondem k obsluze původního produktu – penzijního připojištění.

3.1.2. Plán projektu „Nový ISPS“ Po ověření zda zadání projektu je realizovatelné, byl vytvořen plán projektu „Nový ISPS“. Prvním krokem byla nominace projektového týmu. Na základě rozhodnutí sponzora projektu byli jmenováni na pozice primárně zodpovědných osob za dílčí části projektu zaměstnanci provozního úseku. Ve většině případů se jednalo střední management nebo seniorní pracovníky provozního úseku. Důvodem, proč byli nominováni zaměstnanci provozního úseku, byla jejich dlouholetá uţivatelská znalost stávajícího informačního systému a zároveň dokonalá znalost interních procesů provozního úseku. Dalšími členy projektové týmu byli i zaměstnanci provozního úseku z oddělení informačních technologii, ale ti byli nominováni na pozici tzv. sekundárně zodpovědných osob za rozvoj dílčí části a jejich úloha byla spíše poradní a to v technických oblastech. V několika výjimečných případech byli do projektového týmu dosazeni i zaměstnanci Penzijního fondu z jiných úseků a to z důvodu, ţe části informačního systému podporují procesy v těchto úsecích. Například část informačního systému spravující účetnictví, evidenci distributorských sítí či nastavení provizních schémat pro výplatu provizí. Jak jiţ bylo uvedeno, projektový tým se

51

skládal z řadových zaměstnanců a manaţerů Penzijního fondu, kteří v organizační struktuře zastávali své běţné funkce a spravovali přidělené agendy. Z tohoto důvodu bylo provedeno vyčlenění jejich kapacit na projekt. Alokace kapacit určených pro projektové aktivity byl uveden v procentech. Vznikl plán lidských zdrojů přidělených na projekt. Po vytvoření projektového týmu a přidělení lidských zdrojů na projekt mohl vzniknout časový harmonogram projektu. V případě projektu „Nový ISPS“ však sestavování harmonogramu projektu bylo atypické a to z důvodu, ţe zde nebyl termín dokončení odhadován, ale byl pevně stanoven legislativou. Penzijní fond nebo posléze Penzijní společnost potřebovala pro výkon své činnosti dokončit projekt nejpozději do konce ledna 2013. Jiţ při sestavování jednotlivých fází projektu a jejich posloupností, byl při stanovení časové náročnosti pro jednotlivé fáze brán zřetel na nutný termín dokončení, coţ mělo vliv na časový odhad pro trvání fází a v některých případech byly odhady velice ctiţádostivé. Vzhledem ke skutečnosti, ţe k iniciaci projektu došlo v listopadu 2011, jednalo se z pohledu rozsahu projektu a časových moţností o velmi ambiciózní projekt. Čas byl také identifikován jako jeden z nejrizikovějších faktorů celého projektu. Pro sestavení plánu projektu „Nový ISPS“ byl pouţit standardní nástroj Microsoft Project Plan, do kterého byly vyznačeny etapy projektu a jejich jednotlivé kroky. Projekt byl rozdělen do tří hlavních částí neboli streamů. Stream A. měl za úkol uzavření smlouvy s vítězem výběrového a propojení projektových týmů objednavatele a dodavatele. Stream B., jehoţ úkolem byl vývoj a dodání nové aplikace pro Penzijní fond, byl dále rozdělen na čtyři následující etapy: Etapa I. – Funkční design Etapa II. – Vývoj a testování Etapa III. – Akceptační testy Etapa IV. – Pilotní provoz Stream C. pod názvem „Operační model pro Back Office“ měl pro Penzijní fond zajistit úpravu vnitřních předpisů a manuálů v souladu s nově nastavenými procesy v informačním systému. Další ambicí tohoto streamu bylo dodání výstupů z informačního systému, které slouţí pro účely managementu na sledování výkonnosti informačního systému a jeho uţivatelů. 52

Obrázek 5 - Ukázka Harmonogramu projektu v MPP [zdroj autor]

Zadání projektu bylo rozpracováno na menší části a popis těchto celků jiţ byl zpracován v detailnější podobě. Začal vznikat konkrétnější popis nové aplikace, zatím spíše z pohledu jednotlivých procesů, jejichţ výstupem je poţadovaná přidaná hodnota pro interního či externího zákazníka aplikace. Při rozdělení projektu na jednotlivé části se vycházelo z liniové organizační struktury Penzijního fondu a agend příslušných k jednotlivým úsekům, oddělením a týmům v této organizační struktuře. K jednotlivým dílčím celkům zadání byly přiřazeny zodpovědné osoby, které měly zajistit podrobnější popis poţadovaných funkcionalit na nový informační systém. Pověřenými osobami byly primárně zodpovědné osoby projektového týmu a jimi vytvořený popis se stal podkladem pro výběrové řízení na dodavatele informačního systému. Došlo k formálnímu schválení zadání projektu ze strany sponzora projektu. Penzijní fond vyhlásil výběrové řízení na konci listopadu 2011. Vybraným zájemcům Penzijní fond rozeslal dokument „Request for Information“, který slouţil budoucím dodavatelům jako podklad k vyjádření, zda jsou poţadovaný rozsah díla v poţadovaném čase

dodat.

Penzijní

fond

obdrţel

návrhy 53

řešení

na

dodání

nové

aplikace

od potencionálních dodavatelů a byla vytvořena hodnotící komise, která posuzovala předloţené řešení ze tří hlavních hodnotících kritérií, mezi která patřily: Proces implementace Cena řešení Dodavatel Kaţdému z kritérií byla přiděla odpovídající váha, která měla vliv na celkový výsledek hodnocení představené nabídky. Hodnotícímu kritériu „Proces implementace“ byla přiřazena nejvyšší váha vlivu na výsledek hodnocení a to ve výši 60%. Obsahem tohoto kritéria bylo hodnocení varianty z pohledu technické vyspělosti a naplnění funkčních i nefunkčních business poţadavků. Byla hodnocena i časová náročnost z pohledu funkční migrace a integrace do řešení do infrastruktur finanční skupiny.

Součástí posouzení tohoto kritéria byla i moţnost

vlastní definice procesů ze strany objednavatele tedy Penzijního fondu. Posuzována také byla kvalita poskytované uţivatelské a technické dokumentace. Z 30% se na vyhodnocení podílelo cenové kritérium. Nebyla zohledněna pouze celková cena dodávky, ale přihlíţelo se i k nabídnuté ceně za následnou správu aplikace. Musely být ohodnoceny i vedlejší náklady spojené s integrací aplikace do infrastruktur finanční skupiny a hlavně mateřské společnosti. Přihlíţelo se na výši infrastrukturních nákladů Penzijního fondu na projekt (např. zřízení testovacího prostředí a testovacích stanic) a zohledněny byly personální náklady na celý projektový tým. Poslední kritérium, které se na celkovém vyhodnocení předloţené nabídky podílelo z 10%, bylo kritérium „Dodavatel“. Hodnotícími prvky tohoto kritéria byly reference dodavatele, zda se jedná o stabilního partnera, který je jiţ etablován ve finanční skupině. Dále se hodnotil rozsah projektového týmu dodavatele a jeho odbornost. Při vyhodnocení tohoto kritéria se také posuzovala frekvence dodávek nových release. Hodnotící komise, která posoudila obdrţené nabídky dle výše uvedených kritérií, vybrala tři nejlepší nabídky, které naplňovaly poţadavky objednavatele. U všech třech předloţených nabídek byl výsledek hodnocení takřka shodný a lišil pouze minimálními 54

odchylkami v dílčích ukazatelích. Jednalo se o dvě společnosti ze Slovenské republiky a o jednoho dodavatele z České republiky. Oba slovenští dodavatelé jiţ měli zkušenosti s důchodovou reformou uskutečněnou u našich východních sousedů a jedna z těchto společností měla zkušenosti s českým trhem penzijního připojištění. Tato společnost byla dlouholetým dodavatelem informačního systému pro konkurenční Penzijní fond působící na trhu penzijního připojištění v České republice. Třetí společností byl překvapivě stávající dodavatel informačního systému, který těţil při tvorbě své nabídky z dobré znalosti vnitřního prostředí a potřeb Penzijního fondu díky dlouhodobé spolupráci. Standardně by Penzijní fond poţádal všechny tři potencionální dodavatele o zpracování jednoduchého zadání, které by rozhodlo o finálním výběru dodavatele, ale vzhledem k časovému tlaku Penzijní fond zvolil atypické řešení. Se slovenskými dodavateli se Penzijní fond dohodl, ţe do jejich sídla bude vyslán tým expertů z Penzijního fondu, kterému dodavatel představí stávající řešení, které je vyuţíváno pro obsluhu doplňkového důchodového systému v Slovenské republice a dále bude umoţněno týmu expertů vyzkoušet práci se systémem v testovacím prostředí. Návštěva českého dodavatele nebyla nutná, vzhledem k tomu, ţe produkt tohoto dodavatele byl Penzijnímu fondu dostatečně známý. Na základě výsledků hodnotící komise a předloţených doporučení týmu expertů byl vybrán dodavatel informačního systému ze Slovenské republiky, který měl zkušenosti pouze s produkty důchodového spoření na slovenském trhu. Rozhodnutí o výběru dodavatele padlo těsně před koncem roku 2011.

3.1.3. Realizace projektu Dne 2. 1. 2012 byl zahájen projekt výměny informačního systému. Konkrétně byla zahájena část projektu označena jako Stream A. Jelikoţ byl znám vítěz výběrového řízení, mohlo být prvním krokem projektu uzavření smlouvy o dílo mezi zhotovitelem a odběratelem Penzijním fondem respektive Penzijní společností. Součástí smlouvy, kromě standardních ustanovení o právech a povinnostech zhotovitele a odběratele, ceně díla a vymezení předmětu díla, byla i ustanovení o vedení projektu a koordinování spolupráce. Smlouva stanovila, ţe nejvyšším rozhodovacím orgánem pro celý projekt bude řídící rada projektu. Ve smlouvě byl specifikován jednací řád Řídící rady. Bylo ujednáno konání

55

Řídící rady s jednoměsíční frekvencí. Řídící rada se měla primárně v rámci své agendy věnovat monitoringu celkového stavu projektu, schvalovat rozsáhlejší změny analýzy a termínů dodávek. Dále do její kompetence patřilo schvalování hlavních projektových dokumentů včetně jednotlivých akceptačních protokolů a rozhodování případných sporů mezi vedoucími projektu. Ve smlouvě bylo určeno, ţe místo konání Řídící rady bude v sídle objednavatele a dále byli jmenování členi Řídící rady. V Řídící radě byli poměrově zastoupeni zástupci vrcholového vedení obou smluvních stran. Podrobné personální sloţení Řídící rady bylo uvedeno v příloze smlouvy. Nejvyšším výkonným orgánem pro řízení projektu byl určen vedoucí projektu neboli projektový manaţer. Smlouvou bylo určeno, ţe kaţdá ze smluvních stran jmenuje projektového manaţera zvlášť. Smlouva zároveň vyjmenovávala povinnosti a pravomoci projektových manaţerů. Vedoucí projektu odpovídali za metodické řízení a kontrolu pracovníků příslušných smluvních stran, komunikaci mezi stranami, za odbornou a včasnou realizaci plnění předmětu smlouvy. Smlouva určila, ţe za projekt jako celek bude zodpovědný projektový manaţer dodavatele. Mezi pravomoci obou vedoucích projektu patřilo oprávnění podepisovat protokoly v souvislosti s realizací projektu. Dalším koordinačním prvkem projektu, který byl zakomponován do smlouvy o díle, byla dohoda obou smluvních stran o konání kontrolních dnů. Periodicita kontrolních dní byla smlouvou rovněţ upravena a ukládala vedoucím projektu svolat kontrolní den minimálně dvakrát měsíčně. Úkolem kontrolních dní mělo být zhodnocení dosaţených výsledků a projednání dalších postupů. Z jednání kontrolního dne má být pořízen zápis, který po odsouhlasení obou smluvních stran bude archivován. Smlouva dále určovala akceptační kritéria pro převzetí díla. Smlouva obsahovala několik příloh, mezi které patřil harmonogram projektu a specifikace funkčních a nefunkčních poţadavků objednavatele. Tyto dvě přílohy jsou zmíněny úmyslně, protoţe v následném průběhu projektu byly často brány na jednání kontrolních dní nebo při eskalaci problémů na Řídící radu projektu, jako referenční bod pro další řízení projektu. Sestavení smlouvy o dílo bylo poměrně náročným procesem. K podpisu smlouvy po několika kolech připomínkování došlo dne 29. 2. 2012.

56

Stream B. byl zahájen kick off meetingem dne 12. 3. 2012. V rámci úvodní schůzky bylo provedeno představení jednotlivých členů projektových týmů, jak za stranu dodavatele, tak za stranu objednatele. Projektový tým byl seznámen s harmonogramem projektu a s obsahem jednotlivých etap projektu. Dále bylo představeno členění informačního systému na jednotlivé moduly. Dle zadání objednatele vzniklo celkem čtrnáct modulů, které měly tvořit finální dílo. V rámci úvodního meetingu byly projektovými manaţery představeny pracovní skupiny, které se skládaly z pracovníků objednavatele a dodavatele. Tyto pracovní skupiny měly pracovat na vývoji modulu. Kaţdý tým měl určeny primárně zodpovědné osoby ze strany dodavatele a ze strany objednavatele. Tyto osoby byly garanty vývoje a dodání přiděleného modulu. Vzhledem k omezeným personálním kapacitám na straně Penzijního fondu, bylo v několika případech přiděleno více modulů jedné primárně zodpovědné osobě. Ve většině případů byli Penzijním fondem nominováni do pozic primárně odpovědných osob zaměstnanci, jejichţ standardní pracovní náplní byla agenda shodná nebo velmi blízká vyvíjené oblasti. Jednalo se tedy o pracovníky s odborností v oblasti penzijního připojištění, ale s minimálními zkušenostmi práce na projektu a s vývojem informačního systému. Jen ve výjimečných případech měli tito zaměstnanci vzdělání z oboru informačních technologií. Za stranu dodavatele byli na shodné pozice jmenováni IT analytici. Součástí zahajovací schůzky bylo seznámení projektového týmu s principy komunikace uvnitř týmu, pravidla předávání a sdílení informací. Ihned po úvodní schůzce byla zahájena první etapa Streamu B. V první etapě Streamu B. pod názvem „Funkční design“ měly v období od 12. 3. 2012 aţ do 31. 5. 2012 probíhat analytické workshopy, jejichţ účelem bylo seznámí objednavatele se stávajícím řešením dodavatele. Následně jednotlivé pracovní týmy zahájily přípravu funkčních specifikací pro příslušné moduly. Tvorba funkčních specifikací probíhala rovněţ formou workshopů. Z workshopů vznikaly strukturované zápisy, které jednak slouţily jako informace pro vedoucí projektu o postupu projektových prací, ale zároveň slouţily jako podklad pro vznikající dokument Funkční specifikace daného modulu. V zápisech z workshopů byly evidovány také vzniklé úkoly, kterým byl přidělen vlastník a termín zpracování. Kaţdý tým pracoval na zadané oblasti samostatně a jeho úkolem byla finální akceptace dokumentu Funkční specifikace. Jiţ v první etapě Streamu B. došlo ke zpoţdění projektu o sedm aţ osm týdnů. Akceptace Funkčních specifikací proběhla s výhradou. Ze strany objednavatele byl vznesen poţadavek na dopracování dokumentace do hlubší úrovně funkčních zadání. 57

Na základě těchto zjištění přijala Řídící rada projektu dne 31. 7. 2012 příslušná opatření. Na návrh dodavatele bylo schváleno rozdělení předmětu projektu na dvě části. Do 1. 1. 2013 budou dodány funkcionality, které potřebuje Penzijní společnost nezbytně k zahájení činnosti a v druhé části do 1. 3. 2013 budou dodány zbývající funkcionality. Projektový tým měl být doplněn o roli Test leadera a celkově měly být posíleny personální kapacity projektového týmu dle adekvátních potřeb. Bylo připraveno přesunutí projektového týmu Penzijního fondu a dodavatele do jedné společné lokality za účelem lepší komunikace a pruţnější spolupráce. Zároveň byla identifikována nová rizika a externí dopady na projekt. Jelikoţ v daném období nebyly ještě zcela známy veškeré dopady důchodové reformy, hrozilo, ţe se bude nutné vrátit nebo upravovat jiţ uzavřená zadání. Penzijní fond byl dodavatelem poţádán, aby určil funkcionality, které musí být dodány od 1. 1. 2013 a označil funkcionality, které mohou být dodány aţ v pozdějším termínu. Po vyjmenování potřebných funkcionalit a jejich rozdělení do dvou skupin došlo k rozdělení scope projektu a zároveň k úpravě harmonogramu projektu. Penzijní fond za účelem zvýšení efektivity projektových prací pronajal a vybavil kancelářské prostory mimo své sídlo, kde se konaly dvou a více denní workshopy pracovních skupin. Projektový tým se primárně zaměřil na dopracování dokumentů popisující příslušné moduly. Po vzájemné dohodě došlo k nahrazení původních Funkčních specifikací novými podrobnějšími dokumenty nazvanými Detailní funkční design. K akceptaci Detailních funkčních specifikací modulů nebo přesněji funkcionalit vybraných do první skupiny, došlo na konci srpna 2012. Následoval vývoj funkčních oblastí dle schválených Detailních funkčních designů a jejich dodání do regresních testů dle testovacích scénářů. Přes výše přijatá opatření se nepodařilo dohnat časové zpoţdění projektu. Druhá etapa projektu byla sice zahájena dle původního harmonogramu, ale mohly být zahájeny pouze aktivity, které neměly závislost na předchozí etapě. Jednalo se o vybudování infrastruktury pro implementaci nové aplikace, zaškolení testerů objednavatele a příprava testovacích scénářů.

58

V této etapě projektu byl identifikován poměrně zásadní problém. Neobsazením pozice business architekta v projektovém týmu ze strany Penzijního fondu způsobilo, ţe jednotlivé moduly, jejichţ funkcionality měly navazovat na funkcionality jiných modulů, nejsou z pohledu business procesů nastaveny optimálně nebo spolu nekomunikují vůbec. Pozice business architekta byla obsazena v měsíci říjnu 2012. Jelikoţ byl do pozice business architekta dosazen člen projektového týmu, který byl primárně zodpovědnou osobou za vývoj tří modulů, tak muselo dojít ke změnám v projektovém týmu. Do projektového týmu musel Penzijní fond zapojit více svých zaměstnanců. K další změně v projektovém týmu Penzijního fondu došlo na sklonku roku 2012 a to na pozici projektového manaţera. Vedoucímu projektu, kterého si Penzijní fond najal od mateřské společnosti, končil kontrakt pro tento projekt a z důvodu alokace jeho kapacit na jiném projektu nebylo moţné prodlouţit jeho kontrakt. Nový projektový manaţer, kterého si Penzijní fond opět najal od mateřské společnosti, nastoupil do projektu výměny informačního sytému od 1. 12. 2012. Po dobu jednoho měsíce působili tedy na projektu za stranu objednavatele dva projektoví manaţeři za účelem převzetí a seznámí se s projektem. K obdobnému kroku došlo i na straně dodavatele, ale s jednoměsíčním zpoţděním. Pod vlivem časového tlaku v závěru roku rozhodla Řídící rada projektu o krizovém řízení projektu. Byl posílen projektový tým o další členy a u stávajících členů projektového týmu byla navýšena alokace jejich kapacit na projekt. Poslední týden v roce 2012 byla zahájena etapa číslo tři „Akceptační testy“. Přestoţe došlo rozdělení předmětu projektu na dvě části a první skupina funkcionalit byla rozsahem funkcionalit výrazně menší neţ druhá část, tak byla třetí etapa zahájena se šesti týdenním zpoţděním, o proti původnímu harmonogramu projektu, který navíc nepočítal s rozdělení scopu projektu. Časový pres zřejmě způsobil, ţe akceptační testy skončily nezdarem z důvodu závaţných chyb dodané verze aplikace a tím nebyla naplněna akceptační kritéria určená smlouvou o dílo. Na straně dodavatele absolutně selhal kontrolní mechanismu kvality, protoţe na závěr akceptačních testů bylo zjištěno, ţe do připravené verze nebyla dodána rozsáhlá funkcionalita modulu „Účetnictví“. K zahájení poslední čtvrté etapy projektu „Nový ISPS“ došlo aţ 15. 2. 2013 po předchozím úspěšném provedení akceptačních testů.

59

Paralelně s pracemi na dodání části jedna finálního produktu pokračovaly i práce na designu a vývoji části dvě. Jelikoţ došlo k časovému posunu projektu i vzhledem k upravenému harmonogramu ze srpna 2012, rozhodli se projektoví manaţeři předloţit Řídící radě projektu úpravu harmonogramu projektu. Řídící rada projektu souhlasila s úpravou časového harmonogramu projektu. Neustálé prodluţování dodání finálního produktu navyšovalo náklady Penzijního fondu, nyní jiţ úspěšně transformovaného na Penzijní společnost, spojené s projektem. Jelikoţ muselo být nedodání některých funkcionalit aplikace včas, řešeno v běţném provozu Penzijní společnosti náhradní způsobem zpracování, zvyšovala se tímto pracnost na projektu, protoţe zpracované transakce náhradním řešením musely být posléze zapracovány do stávajícího řešení. Takto vzniklé více práce a opravy chyb aplikace způsobily, ţe k zahájení rutinního provozu a k dodání finálního produktu došlo po několika úpravách harmonogramu projektu aţ v říjnu 2014. Závěrečná zpráva za projekt „Nový ISPS“ byla vypracována v listopadu 2014 a předloţena na závěrečné jednání Řídící rady, kde byla podepsána sponzorem projektu. Tím byl projekt „Nová ISPS“ formálně ukončen.

60

4. Analýza řízení projektu 4.1. Identifikace a důsledky chyb v řízení projektu V jednotlivých fázích ţivotního cyklu projektu „Nový ISPS“ došlo k několika rozhodnutím, které měly na průběh a výsledek projektu dopad.

4.1.1. Projektový tým na straně Penzijní společnosti Na pozice primárně zodpovědných osob byli vybráni zaměstnanci Penzijní společnosti, kteří měli malé nebo mizivé zkušenosti s projekty a prací na nich. Jednalo se o seniorní pracovníky nebo střední manaţery back office, kteří ve většině případů měli pouze uţivatelské znalosti při práci s informačním systémem. Při obsazení pozic vycházel sponzor projektu s chybné premisy, ţe dlouholetá znalost funkcionalit stávajícího informačního systému a jeho procesů je dostatečnou kvalifikací pro práci na designu a vývoji nového informačního systému. Dalším argumentem pro obsazení důleţitých pozic zaměstnanci provozního úseku byl předpoklad, ţe provozní úsek je hlavním uţivatelem informačního systému a tudíţ jeho zaměstnanci nejlépe vědí, jak by měl nový core systém pracovat. Toto rozhodnutí však bylo chybné. Penzijní společnost měla ve svých řadách zaměstnance, kteří tvořili IT oddělení a dokonce byli sloţkou Provozního úseku. Všichni tito zaměstnanci měli zkušenosti s vývojem informačního systému, protoţe pracovali jako analytici na vývoji původního informačního systému. Vzhledem k tomu, ţe jejich hlavní pracovní náplní byla běţná údrţba stávajícího informačního systému a zároveň komunikační propojení mezi Penzijní společností a dodavatelem původního core systému při jeho úpravách, tak byli velmi dobře seznámeni s interními procesy Penzijní společnosti. Tito zaměstnanci však byli nominováni do projektového týmu pouze jako konzultanti nebo na pozice sekundárně zodpovědných osob bez formální zodpovědnosti. Tato skutečnost měla jednoznačně vliv na jejich přístup a angaţovanost v projektu. Při obsazení pozic projektového týmu a hlavně pracovních skupin, měli být do pozic primárně zodpovědných osob nominováni zaměstnanci oddělení informačních technologií a zaměstnanci zbývajících oddělení back office měli být do pracovních skupin zařazeni jako konzultanti nebo sekundárně zodpovědné osoby. 61

Dalším problémem byla nedostatečná alokace kapacit na projektové práce. Kaţdé z primárně zodpovědných osob zůstala přidělena běţná denní agenda a na projektové práce byli alokováni pouze částečně. Rovněţ i v tomto případě by bylo přidělení pracovních kapacit na projektové práce u zaměstnanců oddělení informačních technologií výrazně snazší, protoţe jejich běţná pracovní náplň není přímo spojena se zpracováním příchozích transakcí. Špatná volba členů projektového týmu ze strany Penzijní společnosti, umocněna jejich nedostatečným kapacitním uvolněním na projektové práce, způsobily problémy při tvorbě zadání finálního produktu. Jednoznačně se zde projevil konflikt role sponzora projektu, kterým byl ředitel provozního úseku s jeho rolí liniového manaţera v organizační struktuře Penzijní společnosti. Uvolňováním kapacit na projektové práce docházelo ke sníţení kapacit na běţných provozních agendách a tím k neplnění klíčových výkonnostních limitů. Jednalo se o klasický střet zájmů, který měl být vyřešen ihned na začátku projektu v rámci sestavení projektového týmu a stoprocentním uvolněním vybraných zaměstnanců Penzijní společnosti na projektové práce. Po zahájení projektu jiţ byla tato diskuse o uvolnění klíčových zaměstnanců pro projekt velice obtíţná, protoţe poţadavek na navýšení lidských zdrojů předkládal vedoucí projektu sponzorovi projektu, který byl ochoten uvolňovat zaměstnance, ale aţ po splnění svých liniových cílů. Nevhodná volba obsazení pracovních týmů měla za důsledek, ţe při popisu Funkčních specifikací respektive Detailních funkčních designů jednotlivých modulů, nebyl popis funkcionalit dostatečně detailní a přesný. Přestoţe v pracovních týmech byli ze strany dodavatele nominováni IT analytici, tak ti v mnoha případech nedokázali vyhodnotit správně potřeby Penzijní společnosti z důvodu neznalosti vnitřních procesů a jejich návazností. Tato skutečnost se negativně projevila po ukončení první etapy projektu, kdy se v průběhu připomínkování funkčních specifikací a posléze i při vývoji funkcionalit neustále objevovaly nedořešené nebo vůbec nepopsané dílčí funkčnosti, coţ samozřejmě zpomalilo vývoj a finální dodání produktu. Závaţným pochybením při sestavení projektového týmu na straně objednavatele bylo neobsazení pozice Business architekta od zahájení projektu. Pozice Business architekta nebyla obsazena částečně z důvodu nedostatečných personálních zdrojů. Angaţovat na tuto 62

pozici externího pracovníka nebo na trhu práce získat nového zaměstnance s odpovídající kvalifikací nebylo z časových důvodů vhodné. S ohledem na specifičnost procesů spojených s penzijním spořením by se jednalo dlouhodobou záleţitost, neţ by dotyčný pracovník byl dostatečně erudován k výkonu funkce. Vybrat vhodného kandidáta z vlastních řad bylo komplikováno souběhem více rozsáhlých projektů v Penzijní společnosti a alokací zaměstnanců, kteří by splňovali nároky na pozici Business architekta, na jiných pro Penzijní společnost neméně důleţitých projektech. Pozice Business architekta byla obsazena těsně před dokončením druhé etapy, tedy ve chvíli, kdy jiţ byly některé popisy funkcionalit dokončeny a akceptovány. Neobsazením pozice Business architekta došlo k situaci, ţe při vývoji jednotlivých modulů aplikace nebyla zohledněna jejich integrita. Procesy, které měly přesah přes více modulů informačního systému, nefungovaly, protoţe nebyly správně nadefinovány vzájemné vazby mezi moduly. Toto pochybení způsobilo, ţe muselo docházet k otevírání jiţ definovaných funkčních celků, k jejich úpravám a přepracování, coţ mělo opět za důsledek navýšení pracnosti a prodlouţení termínu dodání.

4.1.2. Projektový tým na straně dodavatele Projektový tým dodavatele byl sestaven z profesionálů s vysokou kvalifikací. Všichni členové měli zkušenosti s prací na projektech. Projektový tým byl sloţen ze zaměstnanců, kteří pracovali na vývoji a implementaci obdobného produktu v rámci důchodové reformy ve Slovenské republice. Pracovní týmy dodavatele, které pracovaly na vývoji jednotlivých modulů, však nebyly soustředěny do jednoho místa, ale nacházely se v různých městech několik kilometrů vzdálených. Tento fakt komplikoval komunikaci mezi jednotlivými týmy dodavatele, coţ se významně negativně projevilo na funkčním propojení jednotlivých modulů aplikace. Jelikoţ znalost „end to end“ procesů byla na straně pracovníků Penzijní společnosti a ne v týmu dodavatele, byly chyby v komunikaci mezi jednotlivými moduly aplikace identifikovány aţ v průběhu regresních testů, které probíhaly v sídle Penzijní společnosti vţdy po nasazení nové verze aplikace. Následné opravy nefunkčního propojení jednotlivých modulů způsobily další vícepráce na projektu s dopadem na termíny projektu.

63

Negativní dopad na komunikaci mezi projektovými týmy dodavatele a odběratele měla vzdálenost mezi umístěním projektových týmů. Tím, ţe pracovní týmy neměly moţnost běţné denní spolupráce, docházelo k prodlevám při řešení vzniklých problémů. Většina otázek a problémů se řešila aţ v rámci plánovaných workshopů a v mnoha případech aţ s několika denním zpoţděním. Přestoţe byly vyuţívány všechny v současné době moţné komunikační kanály od běţné emailové korespondence aţ po videokonference, tak tyto nenahradily jednoznačnou výhodu, kterou přináší moţnost svolání operativních schůzek v případě umístění pracovní skupiny do jedné lokality. Neumístění obou projektových týmů do jednoho místa mělo opět negativní dopad na harmonogram projektu.

4.1.3. Výběr dodavatele Výběr dodavatele ovlivnily tři základní předpoklady, ze kterých vedení Penzijní společnosti vycházelo: dodavatel nabízí hotové řešení, které realizoval v rámci důchodové reformy na Slovensku odlišnost v legislativě a nastavení důchodové reformy v České republice a jiţ uskutečněné reformy na Slovensku není příliš veliká dodavatel zná současné řešení core systému objednavatele, protoţe krátce před zahájením projektu došlo k fúzi s původním dodavatelem informačního systému Ze strany Penzijní společnosti se jednalo o racionální předpoklady před zahájením projektu, které se ovšem posléze nepotvrdily a to proto, ţe nebyly zaloţeny na faktech. Předpoklad, ţe dodavatel nabízí hotové řešení, které se bude muset pouze neparametrizovat dle legislativy platné v České republice, byl naprosto mylný. Hned v úvodu projektu se ukázalo, ţe nastavení důchodkových společností a jejich legislativní úprava má na Slovensku mnoho diametrálně odlišných parametrů oproti nastavení produktů důchodové reformy v České republice. Počínaje stanovením hodnoty kurzu penzijních a důchodových jednotek a odlišnými typy nároků vyplývající z penzijního spoření konče. Jiţ úvodní workshopy odhalily tyto rozdíly. Vedení Penzijní společnosti vycházelo z předpokladu, ţe osmdesát procent řešení je hotovo a dopracovat se bude muset 64

pouze zbývajících dvacet procent. Skutečný stav však ukázal opačný poměr. Zhruba 20% bylo hotovo v rámci původního řešení a zbývajících 80% se muselo následně dopracovat dle poţadavku objednavatele. To, ţe se jednalo o chybný předpoklad, je jednoznačné pochybení ze strany Penzijní společnosti, která měla detailněji a důsledněji prostudovat fakta o realizované důchodové reformě ve Slovenské republice a identifikovat rozdíly. Ze strany dodavatele došlo k pochybení při zpracování rozdílové analýzy tzv. GAP analýzy. Pokud by dodavatel věnoval více úsilí provedení srovnávací analýzy, porovnáním nabízeného řešení s poţadovaným zadáním, identifikoval by rozdíly a navrhl postupy jejich implementace do nového informačního systému. Tím, ţe nebyla provedena detailnější GAP analýza při zahájení projektu z časových důvodů, protoţe její provedení by způsobilo zpoţdění projektových prací, vyvstala v průběhu projektu spousta nových událostí, se kterými dodavatel v původním harmonogramu projektu vůbec nepočítal. Předpoklad nízkého dopadu legislativních odlišností obou penzijních reforem částečně souvisí s předchozím předpokladem. Jestliţe Penzijní společnost nedokázala odhadnout programovou nástavbu nad nabízeným řešením dodavatele, tak obdobně nevyhodnotila zapracování legislativy do systému. Dodavatelova neznalost zákona byla dalším časovým zpoţděním na projektu, protoţe muselo dojít vysvětlení legislativy, která se musí stát součástí procesu v novém informačním systému. Poslední předpoklad, který vycházel z úvahy, ţe do projektového týmu dodavatele budou díky uskutečněné fúzi s původním dodavatelem informačního systému pro Penzijní fond, dosazeni analytici se znalostí procesů a potřeb Penzijní společnosti, byl také mylný. Většina původních zaměstnanců fúzované společnosti, krátce po fúzi obou společností, změnila zaměstnavatele. Většina těchto zaměstnanců byla specializována na programování a vývoj prostřednictvím technologie, která se při tvorbě nového informačního systému pro Penzijní společnost jiţ nepouţívala, a z tohoto důvodu opustili zaměstnání u dodavatele před zahájením projektu nebo v jeho průběhu. V čase výběrového řízení však pro objednavatele nebyla tato fakta známa a chyba vznikla na straně dodavatele, který nevyhodnotil klíčovou úlohu těchto osob pro další průběh projektu a tyto důleţité zaměstnance neudrţel ve svých řadách. Jestliţe k výběru dodavatele vedly tři mylné předpoklady, tak o to výrazněji ve výběrovém řízení chyběl prvek ověření konceptu nebo-li proof of concept. Pokud by Penzijní 65

společnost zadala v rámci výběrového řízení oběma společnostem, které předloţily nejlepší nabídky, jednoduchý úkol ke zpracování, mohlo dojít v průběhu vyhotovení tohoto úkolu k odhalení budoucích problémů. Penzijní společnost, opět z časových důvodů, upustila od tohoto kroku výběrového řízení a proof of concept nahradila sestavením expertního týmu. Úkolem expertního týmu bylo se během několika málo hodin seznámit stávajícím řešením obou dodavatelů a poskytnout vedení Penzijní společnosti doporučení k nabízeným řešením. Expertní tým však nemohl poskytnout informaci o organizaci projektových prací a způsobu uvaţování řešitelů zadaného úkolu, jak by tomu bylo v případě zpracování klasického proof of conceptu. Časový pres vytvořený v průběhu výběrového řízení, který měl vést k rychlejšímu zahájení projektu, způsobil, ţe byl sice dodrţen ambiciózní termín zahájení projektových prací, ale podcenění předprojektových příprav mělo finální dopad na navýšení pracnosti v průběhu projektu.

4.2. Vyhodnocení činnosti projektového manaţera Během projektu došlo na straně Penzijní společnosti k výměně projektového manaţera. Tato výměna nebyla způsobena nespokojeností s výkonem činnosti projektového manaţera, ale byla vynucena ukončením kontraktu, kterým si Penzijní společnost nakoupila projektového manaţera od mateřské společnosti. Přestoţe vedoucí projektu, který stál u zahájení projektu a vedl jej v průběhu prvního roku, měl moţnost předat svému nástupci veškeré informace během jejich společného působení na projektu v průběhu posledního měsíce a následně byl připraven poskytnout pomoc v podobě konzultací, tak výměna na pozici projektového manaţera měla dopad na průběh projektu. K výměně projektového manaţera došlo v nejméně vhodný okamţik, kdy byl projekt v časovém skluzu a dodavatel selhal při první dodávce funkcionalit potřebných k zahájení činnosti od 1. 1. 2013. Výměna projektového manaţera narušila kontinuitu projektu a to odlišným způsobem vedení projektu. Změna vedení projektových prací způsobena různými osobnostními typy manaţerů, kteří se ve vedení projektu vystřídali. S odkazem na kapitolu 2 této, práce by projektový manaţer působící na projektu od jeho zahájení, by typologicky nejvíce 66

odpovídal typu projektového manaţera „Tahoun“. Jelikoţ jiţ krátce po zahájení projektu se začaly projevovat problémy, které vznikly z nepřesných nebo dokonce chybných předpokladů, tak se projektový manaţer snaţil udrţet dobrou atmosféru v týmu a svým pozitivním přístupem při řešení vzniklých problémů povzbuzoval projektový tým k vyššímu nasazení. Zároveň neměl problém s řešením konfliktních situací a dokázal problémy vzniklé na projektu pojmenovat a nabízet vhodná řešení. Je nutné uvést také, ţe se dopustil několika zásadních chyb při řízení projektu. Nedokázal prosadit navýšení lidských zdrojů ze strany Penzijní společnosti a zároveň podcenil situaci s neobsazením pozice Business architekta od počátku projektu. Pro Penzijní společnost byl jeho odchod jednoznačnou ztrátou, protoţe by jeho přístup a jiţ získané znalosti o prostředí projektu, jak na straně Penzijní společnosti a dodavatele určitě napomohly v roce 2013 k dosaţení lepších výsledků projektu a sníţení časové zpoţdění v harmonogramu projektu. Na pozici projektového manaţera za Penzijní společnost byl od 1. 1. 2013 dosazen opět zaměstnanec mateřské společnosti, jehoţ kapacita byla uvolněna na celý projekt aţ do ukončení projektu. Typově odpovídal tento projektový manaţer nejvíce typu „Úředník“. Pod jeho vedením byl kladen velký důraz na dokumentaci celého projektu. Vyznačoval se perfektně zpracovanými podklady na jednání řídící rady nebo kontrolní dny, ale jiţ s menší intenzitou se věnoval projektovému týmu a jeho potřebám. Jeho velice slabou stránkou bylo řízení projektového týmu. Zpracování úkolů a kontrola dodrţování jejich plnění, se s jeho přístupem uvolnilo a docházelo k neustálému posouvání zadaných úkolů, jak ve vztahu k projektovému týmu na straně Penzijní společnosti, tak i na straně dodavatele. V době, kdy se projekt dostával do časového zpoţdění, a selhávala kontrola kvality na straně dodavatele, nebyl vhodným typem projektového manaţera pro projekt nacházející se v tomto stavu. Jeho pojetí řízení projektu způsobilo, ţe projekt nabral další časovou ztrátu.

4.3. Vyhodnocení časového harmonogramu projektu Časové zpoţdění bylo jedním z největších problémů celého projektu „Nový ISPS“. Pro přehlednost bylo provedeno porovnání původního, upraveného a reálného harmonogramu zjednodušeným přenesením harmonogramů na časovou osu s vyznačenými důleţitými milníky projektu. 67

Obrázek 6 - Harmonogram projektu [zdroj autor]

Z výše uvedených naměřených hodnot je zřejmé, ţe původní časový harmonogram, který byl velice ambiciózní, nebyl dodrţen a ke zpoţdění projektu došlo o více jak 22 měsíců. Dokonce ani upřesněný harmonogram ze dne 31. 7. 2012, kterým se korigoval původní harmonogram projektu, nebyl naplněn a k reálnému ukončení projektu došlo aţ po dvaceti měsících oproti upravenému harmonogramu.

4.4. Porovnání projektu s metodikou Scrum 68

Prostřednictvím níţe uvedené tabulky dochází k porovnání vybraných fází projektu „Nový ISPS“ s metodikou Scrum.

Fáze vývoje projektu podle metodiky Scrum

Release Planning Meeting

Produktový backlog

Sprint Sprint Planning Meeting

Metodika Scrum

Projekt "Nový ISPS"

• oficiální zahájení projektu • definice produktového backlogu kick of meeting projektu • nastínění finanční a časové náročnosti neustále aktualizovaný dokument slouţící, jako zdroj pro projektové práce porada pro zodpovězení základních otázek • jaký je obsah prací následujícího sprintu • jak se bude postupovat

dokumenty "Detailní funkční design" pro jednotlivé moduly

• workshopy pracovních týmů • kontrolní dny projektu

Sprint - sprintový backlog

zdroj pro práci na aktuálním sprintu

předem vybrané části dokumentu "Detailní funkční design" kaţdého modulu

Sprint - Daily Scrum Meeting

kaţdodenní setkání vývojového týmu

není ekvivalent

Sprint - Sprint Review

vyhodnocen Sprintu, prezentace přírůstku produktu

• kontrolní dny projektu • řídící rada projektu

Sprint - Sprint Retrospective

Ukončení projektu

zpětná vazba na průběh minulých Sprintů, návrh na zplepšení • kontrolní dny projektu postupů díky získaným zkušenostem • test funkcionalit bez výhrad napříč všemi moduly předem definovaný stav, který je • provoz aplikace v produkčním akceptován účastníky projektu prostředí bez chyb systému

Obrázek 7 - Porovnání projektu s metodikou Scrum [zdroj autor]

Z jednotlivých vybraných poloţek vyplývá, ţe projekt „Nový ISPS“ by teoreticky mohl být veden metodikou Scrum, protoţe vybrané fáze projektu tato metodika pokrývá, ale vzhledem k reálné situaci v okolí projektu „Nový ISPS“ jí nebylo vhodné pouţít. Prvním limitujícím prvkem pro pouţití metodiky Scrum je nastavení organizace projektů s preferencí rigorózních metodik uvnitř finančních skupiny, jejíţ je Penzijní společnost

69

součástí. Důleţitým prvkem metodiky Scrum je pozice Scrum mastera, který je klíčovou osobou pro úspěch projektu. Penzijní společnost by musela takovou osobu hledat na trhu práce, protoţe v době zahájení projektu nebyla k dispozici osoba s potřebnou kvalifikací uvnitř finanční skupiny. Získání Scrum mastera z prostředí mimo finanční skupinu by bylo komplikací vzhledem k jeho neznalosti prostředí skupiny. Dalším prvkem pro úspěchu projektu vedeným metodikou Scrum je sloţení pracovních týmů. U metodiky Scrum se předpokládá, ţe tým bude sloţen z odborníků pro danou oblast a se znalostí metodiky Scrum, coţ na straně Penzijní společnosti nebylo moţné zajistit. Přestoţe by agilní metodika byla v určitých fázích projektu „Nový ISPS“ vhodnější pro svou flexibilitu, vzhledem k okolnímu prostředí projektu a rozsahu projektu byla tradiční metodika vhodnějším způsobem řízení projektu „Nový ISPS“.

4.5. Vyhodnocení úspěšnosti implementace projektového řízení Z pohledu popisu vývoje projektu „Nový ISPS“ se Penzijní společnosti v podstatě podařilo nastavit principy projektového řízení do struktur organizace Penzijní společnosti. Z popisu průběhu projektu rovněţ vyplývá, ţe Penzijní společnost respektive projektový manaţer od počátku projektu postupoval v souladu se zvolenou metodikou pro řízení projektu. Obecně lze konstatovat, ţe všechny doporučené principy pro implementaci projektového vedení byly dodrţeny, přesto s přihlédnutím k výše uvedenému popisu průběhu projektu a identifikaci chyb vzniklých v různých fázích tohoto projektu, lze konstatovat, ţe implementace projektového řízení do organizačních struktur Penzijní společnosti nebyla v případě tohoto projektu úspěšná.

70

5. Závěr 5.1. Cíle práce a jejich naplnění Hlavním cílem této diplomové práce bylo vyhodnotit, zda se Penzijní společnosti úspěšně podařilo zavést způsob projektového řízení do organizační struktury. K naplnění tohoto hlavního cíle slouţily postupné cíle, jejichţ naplněním měl autor této práce získat dostatek argumentů k vyhodnocení úspěšné či neúspěšné implementace projektového vedení. Na základě teoretické části této práce, která popisuje standardy metodik projektového řízení a následnou deskripcí reálného průběhu projektu „Nový ISPS“ byly získány informace a identifikovány chyby v řízení projektu, čímţ byl naplněn jeden z cílů této práce. V rámci naplnění tohoto cíle byly označeny konkrétní pochybení při vedení projektu. Zároveň byly určeny osoby, jejichţ rozhodnutí a předpoklady měly negativní dopad na průběh projektu. Popisem typů osobností projektových manaţerů působících na projektu byl naplněn další ze stanovených cílů. Osobnost projektového manaţera byla identifikována, jako jedna z klíčových postav úspěšné implementace projektového řízení. Komparací metodiky projektu „Nový ISPS“ s metodikou Scrum došlo k naplnění dalšího cíle této práce. Získáním výstupů ze všech předem stanovených úkolů, mohl autor práce konstatovat, ţe zvolená metodika pro řízení projektu „Nový ISPS“ byla vhodně zvolená, byly nastaveny obecné principy řízení projektu prostřednictvím tradiční metodiky, ale vzhledem ke střetu zájmů mezi liniovým vedením a projektovým vedením nebyla implementace projektového řízení úspěšná.

71

Seznam pouţité literatury: 1. DOUCEK, Petr. MARYŠKA, Miloš. NEDOMOVÁ, Lea a kol. Informační management v informační společnosti. Vyd. 1. Příbram: Professional Publishing, 2013, 263 s. ISBN 978-80-7431-097-3 2. DOUCEK, Petr. Řízení projektů informačních systémů. Vyd. 1. Příbram: Professional Publishing, 2004, 185 s. ISBN 978-80-8641-971-8 3. DOSKOČIL, Radek. Metody, techniky a nástroje řízení projektů. Vyd. 1. Brno: Akademické nakladatelství CERM, 2013, 165 s. ISBN 978-80-7204-863-2 4. SVOZILOVÁ, Alena. Projektový management. Vyd. 2. Praha: GRADA Publishing, 2011, 377 s. ISBN 978-80-247-3611-2 5. Zákon č. 90/2012 Sb. o obchodních korporacích 6. Zákon č. 427/2011 Sb. o doplňkovém penzijním spoření 7. Zákon č. 376/2015 Sb. o ukončení důchodového spoření 8. https://scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide.pdf 9. http://www.works.gov.bh/English/ourstrategy/Project%20Management/Documents /Other%20PM%20Resources/PMBOKGuideFourthEdition_protected.pdf 10. http://www.rentel.cz/lms/kurzVolnyObsahFrameset/CHOMUTOV_PROJRI/22_pr ocesn_skupina__iniciace.html 11. https://managementmania.com/cs/metody-rizeni-projektu 12. http://duchodovareforma.mpsv.cz/cs/ 13. http://www.edunews.cz/a-305/typologie-projektovych-manazeru-v-praxi

Seznam pouţitých zkratek (obrázků, grafů, tabulek, příloh): OBRÁZEK 1 - ORGANIZAČNÍ STRUKTURA [ZDROJ AUTOR] ............................................. 14 OBRÁZEK 2 - KOORDINACE PROJEKTU [ZDROJ ADAPMA.COM] ..................................... 15 OBRÁZEK 3 - FÁZE PROJEKTU [ZDROJ AUTOR] ................................................................... 21 OBRÁZEK 4 - UKÁZKA RELEASE BURNDOWN GRAFU [ZDROJ SCRUMALLIANCE] ... 41 OBRÁZEK 5 - UKÁZKA HARMONOGRAMU PROJEKTU V MPP [ZDROJ AUTOR] ........... 53 OBRÁZEK 6 - HARMONOGRAM PROJEKTU [ZDROJ AUTOR] ............................................ 68 OBRÁZEK 7 - POROVNÁNÍ PROJEKTU S METODIKOU SCRUM [ZDROJ AUTOR] .......... 69

72