Aplikace projektového managementu

Bankovní institut vysoká škola Praha Katedra Managementu firem a institucí

Aplikace projektového managementu Diplomová práce

Autor:

Bc. Ondřej Čaněk, DiS. Finance, Finanční obchody

Vedoucí práce:

Ing. Zdeněk Čapek

Praha

Červen, 2012 1

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 ar chivovat 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 29. 6. 2012

Bc. Ondřej Čaněk, DiS.

2

Poděkování: Na tomto místě bych chtěl poděkovat vedoucímu mé práce, ţe mi poskytl zajímavé náměty, kterým jsem se mohl ve své práci věnovat. Dále bych rád poděkoval svým spolupracujícím kolegům, ţe byli ochotni mi věnovat čas nad diskusí o projektových principech a zákonitostech v naší společnosti.

3

Anotace Ve své diplomové práci se věnuji oblasti projektového managementu. V úvodu shrnuji základní informace z této oblasti, které je dobré znát. Tématu jsem se věnoval pohledem začínajícího člena projektového týmu. V praktické části představuji funkce útvaru projektové kanceláře ve velké finanční společnosti. Dále analyzuji jednotlivé projektové fáze implementovaného projektu eKliP a hodnotím úspěšnost jeho realizace. V poslední kapitole moţných trendů budoucího vývoje odhaduji, jakým směrem se bude projektový management ubírat ve střednědobém horizontu. Klíčová slova: projekt, projektový management, řízení, implementace

Annotation In my dissertation I describe the area of a project management. The introduction gives a summary of a basic information which are good to know. I devoted to the theme from perspective of a starting project team’s member. In a practical part functions of the Demand management office in the large financial company are introduced by me. Furthermore I analyse each p roject phase of implemented project eKliP and I also evaluate a success of its realization. I dedicated the last chapter to possible trends in the near future and estimated, which way will the project management go in the medium-term horizon. Keywords:project, project management, management, implementation

4

Obsah OBSAH .............................................................................................................................. 5 ÚVOD ............................................................................................................................... 8 1.

VÝVOJ A POUŽITÍ PROJEKTOVÉHO MANAGEMENTU ..................................................... 10 1.1.

D YNAMICKY SE MĚNÍCÍ TRŽNÍ PROSTŘEDÍ .......................................................................... 10

1.2.

V ÝZNAM PROJEKTŮ ..................................................................................................... 11

1.3.

E TAPY VZNIKU PROJEKTOVÉHO ŘÍZENÍ .............................................................................. 11

1.3.1.

První náznaky ve starověku a středověku ........................................................ 11

1.3.2.

Druhá polovina 20. století .............................................................................. 12

1.3.3.

Současnost .................................................................................................... 13

1.4.

S TANDARDY A STANDARDIZACE ...................................................................................... 14

1.4.1.

PMI ............................................................................................................... 15

1.4.2.

IPMA ............................................................................................................. 15

1.4.3.

PRINCE2 ........................................................................................................ 16

1.5.

P ROJEKTOVÉ ŘÍZENÍ A JEHO VYMEZENÍ ............................................................................. 16

1.5.1. 1.5.1.1.

Metody popisu cíle projektu .................................................................................. 18

1.5.1.2.

Úspěšnost projektu ............................................................................................... 19

1.5.2.

Organizace projektu ....................................................................................... 19

1.5.2.1.

Projektové řízení a tradiční liniové řízení................................................................ 21

1.5.2.2.

Členové projektu ................................................................................................... 23

1.5.2.2.1.

Sponzor ........................................................................................................... 23

1.5.2.2.2.

Projektový manažer ......................................................................................... 24

1.5.2.2.3.

Zainteresované strany ...................................................................................... 26

1.5.3.

2.

Cíl projektu .................................................................................................... 17

Projektové dokumenty a jejich význam ........................................................... 27

1.5.3.1.

Business Case ........................................................................................................ 27

1.5.3.2.

Zakládající listina projektu ..................................................................................... 28

1.5.3.3.

Plán řízení projektu ............................................................................................... 29

FÁZE PROJEKTOVÉHO MANAGEMENTU ....................................................................... 31 2.1.

Z AHÁJENÍ PROJEKTU .................................................................................................... 33

2.1.1.

Stanovení cílů projektu ................................................................................... 33

2.1.1.1.

Brainstorming ....................................................................................................... 34

2.1.1.2.

Myšlenková mapa ................................................................................................. 35

2.1.2.

Vyjasnění potřeby projektu u top managementu ............................................. 36

2.1.3.

Zpracování projektové dokumentace .............................................................. 36

2.1.3.1.

Schválení Business Case ......................................................................................... 36

5

2.1.3.2.

2.2.

P LÁNOVÁNÍ PROJEKTU ................................................................................................. 37

2.2.1. 2.2.1.1.

2.2.2. 2.2.2.1.

2.2.3. 2.2.3.1.

2.2.4. 2.2.4.1.

2.2.5.

Plánování dle techniky strukturovaného členění ..................................................... 38

Plánování času ............................................................................................... 39 Kritická cesta projektu ........................................................................................... 40

Plánování zdrojů ............................................................................................ 41 Optimalizace v oblasti lidských zdrojů .................................................................... 42

Plánování rozpočtu ........................................................................................ 43 Stanovení nákladů projektu ................................................................................... 43

Řízení a plánování kvality ............................................................................... 44 Definice kvality ..................................................................................................... 45

2.2.5.2.

Řízení kvality......................................................................................................... 45

Plánování řízení rizik a příležitostí .................................................................. 46

2.2.6.1.

Používané metody řízení rizik ................................................................................ 46

2.2.6.2.

Proces analýzy a řízení rizik ................................................................................... 47

2.2.6.3.

Řízení příležitostí .................................................................................................. 50

V LASTNÍ REALIZACE A MONITORING PROJEKTU ................................................................... 51

2.3.1.

Směřování a řízení realizace projektu ............................................................. 51

2.3.2.

Řízení změn ................................................................................................... 52

2.3.2.1.

Aplikace projektových změn na organizaci .............................................................. 52

2.3.2.2.

Změnové obchodní požadavky ............................................................................... 52

2.3.3.

2.4. 3.

Plánování provedení projektu ......................................................................... 37

2.2.5.1.

2.2.6.

2.3.

Vyhotovení Zakládající listiny projektu ................................................................... 36

Monitoring .................................................................................................... 53

2.3.3.1.

Kontrola provedení plánovaných úloh .................................................................... 53

2.3.3.2.

Řešení sporných bodů, problémů a rizik ................................................................. 54

2.3.3.3.

Pravidelný odečet naplňování PŘP ......................................................................... 55

2.3.3.4.

Reportování o projektu .......................................................................................... 55

U KONČENÍ PROJEKTU .................................................................................................. 56

SPECIFIKA A PRAXE VE VELKÉ FINANČNÍ SPOLEČNOSTI ................................................. 57 3.1.

F INANČNÍ SPOLEČNOST A PROJEKTOVÉ ŘÍZENÍ .................................................................... 57

3.1.1. 3.1.1.1.

Principy projektového řízení v Plavci ............................................................... 57 Vlastnictví používané projektové metodiky ............................................................. 58

3.1.1.1.1.

3.2.

Odlišnosti v pojetí projektové metodiky Plavce ................................................. 59

3.1.1.2.

Evidence a monitoring všech projektů .................................................................... 60

3.1.1.3.

Zajištění prioritizace a plánování projektů .............................................................. 60

3.1.1.4.

Reporting o projektovém portfoliu představenstvu ................................................. 61

P RAKTICKÁ UKÁZKA REALIZACE PROJEKTU V P LAVCI ............................................................. 62

3.2.1. 3.2.1.1.

Zahájení projektu – Idea clarification ............................................................. 62 Vstupy .................................................................................................................. 62

6

3.2.1.2.

Výstupy ................................................................................................................ 63

3.2.1.3.

Manažerské shrnutí ............................................................................................... 64

3.2.2. 3.2.2.1.

Prováděné aktivity ................................................................................................ 64

3.2.2.2.

Výstupy ................................................................................................................ 71

3.2.2.3.


3.2.3. 3.2.3.1.

Vlastní realizace a monitoring – work execution ............................................. 73 Prováděné aktivity ................................................................................................ 73

3.2.3.1.1.

Scope management .......................................................................................... 73

3.2.3.1.2.

Integration + quality management .................................................................... 75

3.2.3.1.3.

Risk management ............................................................................................. 76

3.2.3.1.4.

HR + cost management ..................................................................................... 77

3.2.3.1.5.

Communication management ........................................................................... 78

3.2.3.1.6.

Time management ........................................................................................... 79

3.2.3.2.

3.2.4. 3.2.4.1.

4.

Plánování projektu – Pre-study ....................................................................... 64


Follow-up projektu ......................................................................................... 80 Prováděné aktivity ................................................................................................ 80

3.2.4.1.1.

Archivace projektu v projektové kanceláři ......................................................... 81

3.2.4.1.2.

Převzetí dodávky vlastníkem ............................................................................. 82

PŘEDPOKLÁDANÉ TRENDY PROJEKTOVÉHO MANAGEMENTU ........................................ 84 4.1.

U PLATNĚNÍ AGILNÍ METODIKY ........................................................................................ 84

4.1.1.

Metodika řízená plánem ................................................................................. 84

4.1.2.

Agilní metodika ............................................................................................. 86

4.1.3.

Zhodnocení plánem řízených a agilních metodik .............................................. 87

4.1.4.

Shrnutí .......................................................................................................... 88

4.2.

U PLATNĚNÍ REALIZACE FORMOU PROGRAMŮ ...................................................................... 89

4.3.

R OZŠIŘOVÁNÍ CELOSPOLEČENSKÉ OSVĚTY .......................................................................... 90

ZÁVĚR ............................................................................................................................ 91 DOPORUČENÍ PRO SPOLEČNOST PLAVEC ............................................................................ 93 SEZNAM POUŽITÉ LITERATURY .......................................................................................... 94

7

Úvod Téma, které jsem si pro svou diplomovou práci vybral, je svým způsobem velmi rozšířené, ačkoliv to tak málokdo vnímá. Dovolím si tvrdit, ţe kaţdý dospělý člověk ve svém ţivotě nějaký projekt řídil, případně se jej účastnil. Vţdyť i taková dovolená je projekt. Musí vzniknout myšlenka, vybrat si vytouţenou destinaci, naplánovat harmonogram pobytu, dovolenou si uţít a rozmyslet, zda se příště vrátím nebo pojedu jinam. Pro oblast projektového managementu existuje mnoho obsáhlých publikací, představujících v nejrůznějších úrovních detailu zákonitosti projektů. Cílem mé práce je však představení nejdůleţitějších atributů, procesů a metod vyuţívaných při řízení projektu pohledem začínajícího člena projektového týmu. Naopak v práci se nezabývám zákonitostmi řízení programů, rozdíly mezi uţívanými projektovými metodikami, rozsahem nabízených certifikací jednotlivých standardů a detailním popisem agilních metodik. V úvodní kapitole stručně představuji historii vzniku a význam projektového managementu, charakterizuji klíčové aspekty a role účastníků projektu, definuji odlišnosti liniového a projektového řízení a popisuji nejdůleţitější role účastníků projektu. Další kapitola je zaměřena na popis prováděných aktivit a nejpouţívanějších technik v jednotlivých projektových fázích. Zároveň se věnuji představení nejznámějších disciplín manaţerského řízení v projektech. V praktické části se zabývám reálným prováděním projektů v anonymní finanční společnosti, pojmenované Plavec, a. s. (dále jen „Plavec“). Popisuji zde nutnost a důvody existence útvaru projektové kanceláře ve společnostech, velikostí srovnatelných s Plavcem. Dále přestavuji způsob provedení skutečného projektu na evidenci klientských podnětů se zajímavými okolnostmi ovlivňující jeho implementaci a výsledné hodnocení projektu. V poslední kapitole věnované předpokládaným trendům budoucího vývoje projektového managementu se zaměřuji na postupnou profilaci některých typů projektových metodik na úkor tradičních typů. Společně s tím očekávám i určitou změnu v přístupu k celospolečenské osvětě.

8

Závěrem své práce shrnuji projektová specifika, představuji výsledek svého bádání, odhaduji trendy budoucího vývoje projektového managementu .

9

1. Vývoj a použití projektového managementu 1.1.

Dynamicky se měnící tržní prostředí

V dnešním celosvětovém ekonomicky a informačně úzce propojeném prostředí, které nutí společnosti v nejrůznějších odvětvích stále rychleji inovovat a vylepšovat své sluţby a produkty, je velmi těţké drţet krok s konkurencí. Organizace, podniky i instituce se musí velmi agilně přizpůsobovat neustále se měnícím podmínkám, pokud chtějí přeţít. To byla jedna z věcí, které naučila západní svět hospodářská krize v třicátých letech 20. století. Trendům posledních let velí všudypřítomná globalizace, rostoucí sloţitost, dynamické trhy, technické i ekologické změny, marketingová propracovanost a také reakční rychlost. Pro představení měnícího se prostředí poslouţí příklad ze zemědělství. Dnes se velmi často stává vinou lesních poţárů, výkyvu počasí nebo přírodní pohromy, ţe úroda jednoho druhu obiloviny se v nějaké oblasti velmi sníţí 1. To má okamţitě za následek zvýšení cen této komodity po celém světě během několika hodin. Dá se však dále předpokládat i dopad v jiných závislých odvětvích, například sníţení produkce pečiva a dalších obilných výrobků a tím pádem zvýšení jejich cen. Opět celosvětově. Oproti tomu, pokud byla například v historii (před procesem vzniku globalizace) v nějaké oblasti neúroda, ostatních oblastí se problém příliš netýkal. Ve vleku těchto trendů se díky tomu začíná častěji objevovat stále více nejrůznějších manaţerských, marketingových, ekonomických a jiných teorií, pravidel a návodů, jak se co nejrychleji a nejsnáze stát lídrem na trhu. Jestliţe chtějí být jednotlivé společnosti v dnešní informační době úspěšné a generovat pro své vlastníky a investory dostatečný zisk a přinejmenším udrţovat trţní podíl, musí zejména velmi rychle inovovat a uvádět neustále nové podnikatelské produkty a sluţby, které si trh ţádá. Jinými slovy rychle reagovat na změny v chování trhu, protoţe společnost nereflektující změny je okamţitě vytlačena na okraj zájmu zákazníků.

1

Samozřejmě za předpokladu dostatečně znatelného sníţení úrody.

10

Právě proto z mnoţství nabízených teorií řízení začíná čím dál tím více vystupovat do popředí strategická oblast podnikového řízení a její důleţitá součást v podobě způsobu implementace taktických změn.

1.2. Hlavním

Význam projektů principem

představovaného

přístupu,

který

se

osvědčil

v

podnikatelských, institucionálních, mezinárodních, ale i v akademických sférách, je způsob realizace činností prostřednictvím řízení projektu. Obecně se jedná o definování cíle konkrétní činnosti, které se vymezí časový rámec, ale i potřebné materiální, technické, personální či finanční zdroje . Vše je poté nutné naplánovat a zkoordinovat tak, aby vynaloţené zdroje přinesly maximální uţitek. Výsledkem toho je mnoho nezanedbatelných výhod: -

přesné plánování podnikatelských zdrojů;

-

zefektivnění a podstatné zjednodušení vnitropodnikového řízení i řízení dodavatelsko-odběratelských vztahů;

-

internacionální harmonizaci podnikatelských aktivit, které budou navíc lehce napojitelné na národní i mezinárodní institucionální sféru;

-

srozumitelnou základnu pro reálné plánování rizik;

-

jasná struktura cílů reflektující stanovené vize a strategické záměry.

1.3.

Etapy vzniku projektového řízení

Tak jako kaţdý obor, i projektové řízení prošlo svým vývojem, který se oficiálně datuje do druhé poloviny 20. století. Ovšem oblast projektového řízení je v určitém smyslu patrná i z dřívějších dob.

1.3.1. První náznaky ve starověku a středověku Pokud se však podíváme do dávné minulosti, probíhalo i zde mnoho aktivit, které měly charakter projektu. Dobrým důkazem tomu mohou poslouţit například pyramidy či další známé starověké stavby. Zároveň je třeba zdůraznit, ţe tyto 11

aktivity se od těch současných projektových značně liší. Jedná se zejména o oblasti zdrojů, času a mnoţství. Dalo by se říci, ţe v dřívějších dobách, typicky ve starověku, bylo „neomezené“ mnoţství zdrojů. Pokud jich měl náhodou panovník málo, us pořádalo se válečné taţení, které zajistilo nové otroky, zlato a další prostředky. Nebylo proto nutné zdroje pečlivě plánovat a kontrolovat jejich čerpání. Kdyţ například otrok při výkonu práce zemřel, nahradil se buď novým otrokem, nebo se práce jednoduše navýšila ostatním. Pokud však náhrada ani rozdělení práce nebyla moţná, prodlouţila se doba zpracování. V dřívějších dobách čas plynul „pomaleji“. Realizace projektu (stavba katedrály, pyramidy, mostu…) trvala několik desetiletí. Bylo velmi běţné, ţe pyra mida pro faraona se stavěla celý jeho ţivot. I katedrály byly stavěny několik desítek let. Bylo to způsobeno nejrůznějšími faktory. Předně byl hlavní rozdíl v technickém pokroku. Co bylo tehdy nejmodernější, například vory, dřevěné jeřáby a poštovní holubi, je dnes naprosto neefektivní. Tehdy trvalo doručení pošty poštovním holubem několik dnů, dnes trvá prostřednictvím e-mailu několik vteřin. Stejně tak platí i pro dovoz materiálu, rychlost postupu prací, pouţité materiály, bezpečnostní předpisy atd. Z uvedeného vyplývá, ţe mnoţství prováděných aktivit nemohlo být tak velké a komplexní, jak to probíhá dnes.

1.3.2. Druhá polovina 20. století První náznaky vzniku projektového řízení a počátku vyuţívání projektové terminologie jsou datovány do období po konci druhé světové války, kdy docházelo k masivní obnově válkou zdevastovaných států. Přesto je však projektový management ve své současné podobě registrován aţ od počátku éry šedesátých let, kdy podniky a jiné organizace začaly shledávat p řínosy v organizaci práce pomocí projektů a pochopily urgentní potřebu komunikace a integrace práce napříč podnikovými útvary, různými profesemi a také zeměmi. Byla zde snaha se společně domluvit, pouţívat stejné procesy, efektivně spolupracovat => první pokusy o mezinárodní standardizaci v oblasti projektového řízení. Nutno však podotknout, ţe projektové řízení bylo v té době pouţíváno 12

převáţně pro velké a náročné projekty. Menší projekty se většinou prováděly prostřednictvím principů projektového řízení, které bylo zaloţeno spíše na směrnicích neţ na politikách a na nich navazujících postupech. V sedmdesátých letech bylo patrné stále větší pouţívání projektového přístupu i u jednodušších projektů menších společností. Dalo by se to vysvětlit postupným rozvojem informačních technologií, které se stalo ţivnou půdou pro jeho rozvoj. Vyuţívalo se především ve stavebnictví a průmyslu, kde se projektové řízení z velké míry velmi uplatňovalo, právě pro komplikovanost jednotlivých procesů a činností. Obecně se dá říci, ţe v oblasti ICT byl (a stále ještě je) projektový charakter rozhodující – od vývoje hardwaru přes jednoduché softwarové aplikace aţ po komplikované informační systémy. V průběhu osmdesátých let se projektové řízení postupně ujímá hlavní role ve všech podnikatelských oblastech a aktivitách, které nelze zařadit do kategorie procesních činností.

1.3.3. Současnost V současné době se proces přístupu prostřednictvím řízení projektu stal nedílnou součástí plánování a řízení široké škály nejrůznějších odvětví: průmysl, telekomunikace,

bankovnictví,

pojišťovnictví,

ICT,

státní

správa,

čerpání

evropských fondů, atd. Současné poţadavky však mnohdy vyţadují aplikaci metod projektového řízení ve zcela nových oblastech ţivota společnosti, neţ tomu bylo doposud. Jedná se o malé asociace, správy obcí, školy a dokonce i rodiny. Rozdíl oproti předchozím vývojovým etapám v této době nastává zejména ve zkracování potřebného času, přesnějšího plánování zdrojů, mnoţstvím současně běţících projektů a komplexností (provázaností) probíhajících aktivit. Tyto změny jsou poplatné neustále se zrychlující době, ve které pomalu začíná platit „uţ včera bylo pozdě“. Moţná vás napadne otázka: jak jsou tyto změny moţné? Je to dáno především lepšími, spolehlivějšími a dostupnějšími technolo giemi a také ucelenou metodologií projektového řízení.

13

1.4.

Standardy a standardizace

V současných moderních a rozšířených lidských činnostech je třeba vytvořit určitá opatření, vyhlášky, normy, standardy apod. Oblast projektové ho řízení není výjimkou, ačkoliv tato teorie je zaloţena na dosti obecném principu. Je k tomu hned několik dobrých důvodů: -

mnoţství nejrůznějších proměnných – není to stejné, jako definice velikosti šroubu M6x13;

-

jedná se především o práci s lidmi a o lidech, proto je třeba ke kaţdému přistupovat individuálně;

-

široké spektrum vyuţití, od sociálních projektů, koncertního turné lokální kapely po stavbu atomové elektrárny.

Z těchto důvodů se stává spíše určitým doporučením, jakou filozofii zvolit, jaké jsou osvědčené metody apod. Principy problematiky projektového řízení jsou tvořeny zejména z nejlepších zkušeností mnoha významných projektových manaţerů, tedy osobností, které si svá tvrzení vyzkoušely několikaletou vlastní praxí. Coţ však nevylučuje, ţe standardy mohou být formulovány a mohou vyznívat poněkud akademicky. Standardů projektového řízení je několik. Jedná se zejména o výstupy určitého nezávislého sdruţení profesní skupiny osob, vnášející do problematiky své myšlenky a zkušenosti, a to i v závislosti na sociálně-kulturním prostředí, ze kterého standard vychází. Základní vlastností projektu je především jeho jedinečnost. Díky tomu nemusí vţdy fungovat dobře v jednom projektu to, co se naplno osvědčilo v tom druhém. To, co se osvědčilo v Severní Americe, nutně nemusí fungovat v Evropě. Jak jsem jiţ zmiňoval, jedná se především o práci s lidmi. Jsou různí, různě se chovají, mají různé zvyky. Na druhou stranu téměř všechny standardy projektového řízení mají podobnou základní filozofii, pouţívají obdobné metody i názvosloví a mají obrovský přínos v tom, ţe si pracovníci na projektech dokáţou vzájemně porozumět, pochopit se a efektivně spolupracovat.

14

Mezi hlavní a nejznámější světové standardy patří PMBoK, ICB, PRINCE2. Do jisté míry i ISO 10 006. Liší se místem vzniku, podkladem, ze kterého byly vytvořeny, i způsobem zpracování. Základní filozofie je však téměř totoţná, většinou jde jen o jiný úhel pohledu na tutéţ oblast. Všechny výše uvedené standardy (vyjma ISO 10 006) poskytují a propagují moţnost certifikace projektových manaţerů.

1.4.1. PMI Project Management Institute je nezávislé a neziskové mezinárodní sdruţení, s členskou základnou čítající více neţ 500 tis. osob ve více neţ 185 zemích. Toto sdruţení bylo zaloţeno v roce 1969 skupinou PM na základě standardu Project Management Body of Knowledge (dále jen „PMBoK“), které bylo pouţíváno ve Spojených státech Amerických ve státních odvětvích (NASA, US Navy, US Army…). Mimochodem jedním z výsledků pouţití tohoto standardu je také přistání člověka na měsíci. Pouţití těchto standardů se rozšířilo také do průmyslových oblastí a bez výraznějších změn posléze i k dalšímu komerčnímu pouţití. Tento standard se fakticky skládá z procesního pojetí problematiky projektového řízení. Principem je koncepce pěti hlavních skupin procesů, devíti oblastí znalostí a jejich vzájemných vazeb. Jak uţ místo vzniku (armáda nebo NASA) napovídá, standard se vyznačuje poměrně detailními popisy pouţitých vstupů, výstupů a nástrojů transformace (úkony, metody, techniky). S tímto standardem se v tuzemsku setkáte především v oblastech ICT.

1.4.2. IPMA International Project Management Association je mezinárodní neziskové sdruţení osob, registrované ve více neţ 50 zemích světa s více neţ 40 tis. členy. Zaloţeno bylo v roce 1965 ve Vídni skupinou inovátorů. Základním mezinárodním standardem je IPMA Competence Baseline (dále jen „ICB“). Ten je poté dále rozpracován v kaţdé členské zemi do National Competence Baseline (dále jen „NCB“), coţ je rozdílné proti ostatním standardům, které udrţují jeden globální 15

standard. V České republice je tento standard prezentován českou modifikací Czech Competence Baseline (dále jen „CzCB“), který byl vydán v roce 2008 Společností pro projektové řízení o. s. (dále jen „SPŘ“). Jak uţ název standardu napovídá, není zaměřen tak detailně na popis jednotlivých procesů a vzájemných interakcí. Princip spočívá zejména v důrazu při definici potřebných schopností a dovedností - kompetencí jednotlivých PM. ICB pouţívá velmi podobné metody a postupy, jako ostatní standardy, ačkoliv přesné plnění těchto procesů není striktně vyţadováno. Jedná se spíš o doporučení určitých

procesních

kroků,

které

je

vhodné

aplikovat

prostřednictvím

individuálních schopností a dovedností PM. Základní problematika je rozdělena do třech kompetenčních oblastí: technické kompetence (metody, techniky, nástroje), behaviorální

kompetence

(chování,

charakter,

schopnosti)

a

kontextové

kompetence (integrační a systémové znalosti a dovednosti). Oblasti jsou dále rozděleny na tzv. elementy kompetencí, které popisují určitá témata, navrhují procesní kroky a definují poţadavky na uchazeče o certifikaci.

1.4.3. PRINCE2 Projects IN Controlled Environments neboli PRINCE2 je majetkem anglické státní organizace Office of Government Commerce (dále jen „OGC“). Standard však spravuje a udrţuje společnost APMG. Standard byl zaloţen v roce 1989, na základě poţadavku anglické vlády, která pouţívá tuto metodiku zejména pro veřejné projekty, jejichţ harmonogram je moţné kontrolovat podle jednotné metodiky. Metodika se však postupně rozšiřuje i mezi ostatními subjekty v Evropě i ve světě. Metodologie PRINCE2 rozděluje projektové řízení na čtyři základní elementy – pravidla, témata, procesy a projektové prostředí. Tyto elementy je třeba společně řádně integrovat.

1.5.

Projektové řízení a jeho vymezení

Existuje několik pohledů a výkladů definice projektového řízení. Přináším proto tři výstiţné definice: 16

„Projektové řízení (angl. termín Project Management) představuje způsob rozplánování a realizaci složitých, zpravidla jednorázových akcí, které je potřeba uskutečnit v požadovaném termínu s plánovanými náklady tak, aby se dosáhlo stanovených cílů“, citace z webových stránek Společnosti pro projektová řízení. „Řízení projektů změn a inovací je o řízení rizik a lidí. Vše ostatní je pouhá administrativa“, Colin Bentley. „A project is a temporary management environment created for the purpose of delivering one or more business products according to a specified Business Case.“, zdroj HEDEMAN Bert, VAN HEEMST Gabor Vis, FREDRIKSZ Hans Project management based on PRINCE2, 3rd edition. Van Haren Publishing 2006, 252 s. ISBN 978 90 77212 837.

1.5.1. Cíl projektu Z výše uvedeného je patrné, ţe v kaţdém projektu jsou vţdy klíčové minimálně tři faktory (tzv. trojimperativ), které ústí v jediný výstup – cíl projektu: -

splnění specifického cíle;

-

definování data začátku a konce projektu;

-

rámec

pro

čerpání

zdrojů

(finančních,

materiálních,

technických). Obrázek č.1 – Trojimperativ, základna projektového řízení Zdroje

Cíl projektu Čas

Náklady

Zdroj: literatura [1]

17

personálních,

V současné době existuje ještě jeden faktor, který zásadním způsobem ovlivňuje zpracování projektového cíle. Tímto faktorem je kvalita. Detailně se kvalitě budu věnovat v kapitole 2.2.5. Cíl projektu určuje celkový směr a konečný výsledek. Obsahuje strategickou potřebu zákazníka a hlavní účel, který má být realizací naplněn. Tento globální cíl by měl být poté rozpracován do podrobnější struktury určitých , dosaţitelných a vzájemně se nevylučujících taktických cílů, jejichţ přesná definice je předmětem zadání od zákazníka. Předpokladem toho je správné pochopení budoucího realizátora projektu.

1.5.1.1. Metody popisu cíle projektu V zadání cíle projektu je třeba se soustředit na popis předmětu, sluţby nebo jejich kombinace v podobě, v jaké má být k určitému budoucímu datu k dispozici, ne na činnosti, případně řešení, které k jeho splnění vedou. Detail popisu by neměl obsahovat ţádné technické detaily ani velké podrobnosti, aby mu rozuměli zástupci všech zúčastněných skupin, které na rozhodování v této fázi mají vliv. Na základě formulace zadání a popisu globálního cíle jsou na jedné straně projektu přiděleny priority a zdroje k realizaci a na straně druhé dostatečná a správná pozornost realizátora projektu. Vytvoření vhodných podmínek pro realizaci projektu jiţ ve fázi formulace zadání lze příznivě ovlivnit pouţitím techniky SMART. Tabulka č. 1 – Definice SMART S

Specifické

Cíle mají být specifické a konkrétní.

M

Měřitelné

Mají být opatřeny měřitelnými parametry, z nichţ musí být patrné, zda bylo cíle dosaţeno.

A

Akceptovatelný

Cíle

mají

být

akceptované

zainteresovaných stran.

18

většinou

R

Reálné

Cíle by měly být dosaţitelné s pouţitím disponibilních zdrojů a realistické.

T

Termínované

Cíle mají být časově ohraničené.

MO

MOtivace

Motivovat odměnami a benefity.


1.5.1.2. Úspěšnost projektu Kaţdý projekt je hodnocen dle kritérií úspěšnosti. Dle předchozích informací by měl být automaticky úspěšný v případě splnění trojimperativu (splnění cíle, v daném časovém horizontu a v limitu poskytnutých zdrojů). Skutečnost však nemusí být tak jednoznačná. Např. projekt, který splní vše, jak bylo poţadováno, avšak ukáţe se, ţe výsledné řešení je nepouţitelné. Je takový projekt úspěšný? Pro takové případy byla v praxi zavedena kritéria úspěšnosti projektu. O úspěšnosti nebo neúspěšnosti projektu musí rozhodovat akceptační kritéria, která budou definována před zahájením projektu a jsou předpokladem uzavření kontraktu, který správně popíše obchodní vztah mezi zákazníkem a dodavatelem. Tabulka č. 2 – příklady akceptačních kritérií úspěšnosti/neúspěšnosti projektu Úspěšná kritéria

Neúspěšná kritéria

výsledné řešení je funkční

překročení plánovaných termínů a nákladů

jsou uspokojeny potřeby zákazníka

nevyhovující kvalita výstupu

jsou uspokojeny všechny zúčastněné strany

nepředpokládané vlivy na ţivotní prostředí nespokojený

zákazník

a

další

zainteresované

výsledné řešení je na trhu včas

strany

předpokládaná návratnost je dosahována

výsledné řešení není moţné umístit na trh


1.5.2. Organizace projektu Projektové řízení je unikátní metoda pouţívaná k vytvoření jedinečného výstupu. Tohoto výstupu nelze efektivně dosáhnout díky pouze čistě liniové úrovni řízení v organizaci. Projektové týmy, které mají za cíl právě jedinečného výstupu

19

dosáhnout, jsou vlastně jakési nové, dočasné útvary v organizační struktuře s jediným úkolem. Pokud je dán poţadavek na vytvoření a spuštění nového produktu na trhu, např. mobilního telefonu, nejedná se pouze o práci jednostranně zaměřenou. Je nutné provést analýzu potřeby u budoucích zákazníků, definovat obchodní poţadavky, předat na vývoj, testovat prototypy, domyslet ochranné vlastnictví (registrace patentu), domluvit marketingovou strategii, komunikovat a spoustu dalších dílčích aktivit. Je zřejmé, ţe tento rozsah práce není moţné realizovat prostřednictvím jedné organizační sloţky. Je třeba definovat tým pracovníků, kteří jsou specialisté na konkrétní oblast a kteří se budou dočasně podílet na vývoji nového mobilního telefonu. Kaţdý člen projektového týmu má konkrétní odpovědnost za dílčí úkol. Někdo je zodpovědný za analýzu trhu a vytvoření uceleného výstupu, jiný za definici poţadavků na základě analýzy, další za technickou část výroby … Kaţdý takový projektový tým musí někdo řídit. Stejně jako v běţné liniové struktuře má kaţdý tým svého manaţera, projekty nejsou výjimkou. Projektový manaţer, který je právě tím vedoucím pracovníkem v konkrétním projektu, slouţí jako určitý tmelící a koordinační prvek projektového týmu. Velmi důleţitým prvkem, tvořícím projektový tým, je osoba sponzora. To je osoba definující úvodní obchodní potřebu, bez které by vlastně projekt ani nemohl vzniknout.

20

Obrázek č. 2 - příklad specifické org. struktury projektu ve stavebnictví Liniový manažer

Rozvoj podnikání

Manažer projektu

Projektová

Operace, projekty

Asistent manažera produktu

kancelář

Inženýring

Hlavní inženýr projektu

Stavební činnost

Vedoucí stavby

Příprava staveb

Inženýr – příprava stavebního místa

Řízení kvality

Kontrolor výroby

Nákup

Manažer nákupu

Služby

Kontrola harmonogramu a rozpočtu

Finance a účetnictví

Asistent – Účetní kontrola


1.5.2.1. Projektové řízení a tradiční liniové řízení Jedním z odlišujících faktorů mezi řízením projektovým a tradičním liniovým je systém jejich základních zájmů. Hlavní rozdíly uvádím v následující tabulce. Tabulka č. 3 - srovnání projektového a tradičního liniového řízení Projektové řízení:

Liniové řízení:

- uţití zdrojů

- zajištění zdrojů

- řízení v nejistotě

- předvídatelnost

- unikátnost

- uniformita

- kontrola čerpání nákladů

- hospodaření s majetkem

- kontrola skutečného postupu vůči plánu

- kontrola v měřítcích přijatelnosti výsledků

- řízení

kvality

prostřednictvím

plánu

a

- kvalita řízena na základě inspekce výstupu

preventivních opatření

21

- proměnný počet zaměstnanců

- stabilní počet zaměstnanců

- interní hlášení

- hlášení mimo podnikatelské uskupení

- hodnocení naplnění stanovených cílů

- hodnocení výkonů dle vybraných ukazatelů


Další rozdíl je ve vztahu mezi řízenou a řídící osobou. V tradičních, liniově řízených společnostech má kaţdá řízená osoba svého jediného nadřízeného a je zařazena do konkrétní funkční skupiny. Od nadřízeného přijímá veškeré pracovní úkoly a také mu pravidelně reportuje výsledek jejich splnění případně aktuální stav. Zařazení do funkční skupiny je zpravidla časově neomezené a spolupráce je vesměs orientovaná pouze na osoby uvnitř definované funkční skupiny. Proti tomu v projektu je jedinec, člen projektového týmu, zařazen do určitého týmu na časově omezenou dobu. Navíc jeho kapacita nemusí být projektem vytěţována na 100% a můţe libovolně kolísat, jak je vidět na obrázku č. 3. Tato osoba můţe navíc pracovat na více projektech najednou (pokud není jedním právě vytěţována na 100% své kapacity) a po skončení projektu je obvykle převeden a na jiný projekt. Spolupracuje většinou s osobami jiného zaměření, jak je definováno na obrázku č. 2. Nadřízenou osobou je zpravidla PM, ovšem zůstává stále začleněna v organizační struktuře společnosti. Obrázek č. 3 - obvyklé čerpání lidských zdrojů v průběhu projektu Nasazení lidských

Zahájení

Ukončení

Realizace

zdrojů

čas Zdroj: literatura [6]

22

1.5.2.2. Členové projektu Úspěšnost projektu je nejvíce ovlivněna sloţením a povahou osobností, které jsou součástí projektového týmu. Cíl daného projektu můţe být definován naprosto jasně a zřetelně, priorita nastavena nejvyšší, rozpočet přidělen dostatečný, zkrátka všechny podmínky mohou předpokládat úspěšné provedení projektu -> ale pokud nebude přidělen kompetentní, výkonný a motivovaný tým, je úspěšnost realizace velmi ohroţena. V následujících odstavcích uvádím obvykle nejdůleţitější role projektového týmu.

1.5.2.2.1.

Sponzor

Tuto roli představuje osoba, většinou na manaţerské pozici, která poţaduje vytvoření nové sluţby, produktu, procesu výroby nebo definuje nut nost provedení změny prostřednictvím projektu. Často také nazývána jako vlastník, či zadavatel. Níţe uvádím některé další klíčové oblasti odpovědností a pravomocí sponzora: -

poskytuje relevantní mnoţství finančních prostředků

-

potvrzuje účel pouţití finančních prostředků

-

podílí se na přípravě iniciální projektové myšlenky a obchodních poţadavků (idea clarification) 2

-

schvaluje časování projektu

-

schvaluje významné projektové změny

-

určuje strategické směřování

-

řeší eskalace, které projektový manaţer nemůţe řešit

-

provádí pravidelnou kontrolu postupu prací.

Sponzor je vţdy tím, kdo projekt zaštiťuje a obhajuje. Není jeho povinností sestavit projektový tým, ale kaţdý správný sponzor by měl vţdy velmi pečlivě vybírat zejména pozici projektového manaţera, coby své projektové pravé ruky.

2

Jedná se o úvodní manaţerský projektový dokument, který obsahuje definici potřeby a vyjmenování hlavních výhod případné realizace.

23

1.5.2.2.2.

Projektový manažer

Pokud si nějaká osoba z projektového týmu zaslouţí pozornost, pak je to určitě projektový manaţer (dále jen „PM“). PM je vţdy přímo odpovědný, a také finančně motivovaný, za kvalitu a termín realizace projektu. Jeho „jediným“ úkolem je dokončit projekt tak, aby byl sponzorem a zainteresovanými stranami hodnocen jako úspěšný. K činnostem PM především patří: -

plánování aktivit; o naplánování mnoţství zdrojů; o mapování zainteresovaných stran; o načasování fází projektu;

-

řízení týmu; o přidělování jednotlivých úkolů členům týmu; o koučink; o řešení kolizních situací mezi členy týmu nebo mezi zainteresovanými stranami; o stanovit jednoznačné kompetence, zabránit duplicitě (podrývá pracovní morálku);

-

řízení nákladů; o nastavení rozpočtu; o vykazování o čerpání;

-

organizace; o zařízení

potřebných

administrativních

úkonů

(povolení

k vjezdu,

přístupy do aplikací atd.); o zajištění dokumentace plnění projektového plánu; o jednání se zainteresovanými stranami; -

koordinace; o koordinace aktivit napříč ostatními projekty, útvary nebo společnostmi; o zajištění implementace konkrétních výstupů v poţadovaném čase;

-

komunikace; o srozumitelná písemná i ústní komunikace se všemi zainteresovanými (management, zainteresované strany, realizační tým…); 24

o schopnost přesvědčovat o správnosti cesty; o vyuţívání určitých technik projevu (např. kazatelská technika) ; o prezentace o stavu projektu; -

motivace; o umět správně pochválit; o odměnit dobré a výkonné; o povzbudit nepřesvědčené; o tvorba dobrého jména projektu u okolí;

-

vyjednávání; o alokace plánovaných zdrojů; o řešení nenadálých situací; o řešení sporných bodů (eskalační procedury);

-

rozhodování; o provádění prioritizace aktivit; o delegování pravomocí; o schvalování předloţené dokumentace; o potvrzování projektových milníků; o schvalování běţný provozních záleţitostí;

-

kontrolování; o ověřování provedených prací; o dohlíţet na kvalitu zpracování; o definice a nastavení kontrolních mechanismů; o provádět pravidelné i namátkové kontroly a vyhotovit zápis ;

o integrace zmíněných aktivit k dokončení projektu. Výše uvedené činnosti jsou tvořeny znalostí nástrojů projektové metodiky a také technik manaţerského řízení. Avšak hlavními předpoklady úspěšné realizace projektu jsou osobnost, charakterové vlastnosti a zkušenosti samotného PM. Stejně jako jiné specializované profese (např. politik, pilot, manaţer) je potřeba si uvědomit, ţe tato práce není určena pro kaţdého. Velmi rychle se pozná, zda se konkrétní osoba pro tuto profesi hodí, či nikoli.

25

1.5.2.2.3.

Zainteresované strany

Termín zainteresované strany (dále jen „ZaSt“) je uţíván pro všechny uţivatele, kteří jsou jakýmikoli výstupy projektu ovlivněni (negativně či pozitivně) nebo mají

zájem

na

výkonu

či

úspěchu

projektu.

Cizím

slovem

nazýváme

„stakeholders“. Mezi ZaSt většiny projektů vţdy především patří: zákazníci (interní nebo externí), vlastník, investoři a také zaměstnanci. Projekt jimi můţe být ovlivňován přímo či nepřímo, v závislosti na jejich zájmech, organizační zralosti, pouţitých postupech nebo vlivu. PM by měl vţdy včas zmapovat, zda jsou jednotlivé ZaSt ochotny podporovat projekt či nikoliv, zda mají vliv na výstup projektu nebo jestli jej dokonce nechtějí aktivně ovlivňovat. Kaţdému PM je následně doporučováno vyuţít takto získané informace a vytvořit matici, kde si vliv a zájem jednotlivých ZaSt načrtne dohromady. Z výsledku obrázku č. 4 je tak patrné, jaký přístup pro konkrétní ZaSt pouţít. Obrázek č. 4 - příklad kombinací vlivu/zájmu ZaSt a vhodného přístupu. největší

E D

Síla

Velmi pečlivě H koordinovat

Udrţovat spokojené

A

vlivu C

B

G

Pouze monitorovat

Informovat

E

nejmenší

F

Zájem

největší


Poté je nutné určit prioritu jejich poţadavků a rozhodnout se, jakým způsobem s jednotlivými ZaSt spolupracovat. Bylo by totiţ velkou chybou nespolupracovat s klíčovou ZaSt (například se zaměstnanci, potřební při realizační fázi projektu) 26

nebo naopak plýtvat energií při spolupráci s nekompetentní a projektem nezasaţenou ZaSt. Obrázek č. 5 - Postup spolupráce se zainteresovanými stranami Vyhotovit

Porozumět

Naplánovat

seznam ZaSt a

jejich

proces navázání

rozdělit je do

poţadavkům a

dialogu a

skupin

očekávání

spolupráce

Udrţovat Zahájit dialog

dialog, spolupracovat, zpětná vazba


1.5.3. Projektové dokumenty a jejich význam Uţití dokumentace v případě řízení projektů je stejně důleţité, jako v kterékoliv jiné výrobní nebo procesní činnosti, protoţe výsledkem projektu je vţdy „produkt“. Projekty však obvykle netrvají krátkou dobu, spíše se však setkáme s dobou blíţící se jednomu roku a více. Například stavba jaderné elektrárny je rozhodně práce na několik let (viz jaderná elektrárna Temelín). Kaţdý projekt by proto měl náleţitě zdokumentovat a odsouhlasit základní a nezbytné postupy a stanoviska, kterými se bude řídit. Bez existence těchto dokumentů se směr projektu můţe začít ubírat jiným směrem (finance, zdroje, čas, kvalita, cíl), neţ jaký byl záměr na začátku projektu. Nejdůleţitějšími a jednotlivými standardy nejběţněji pouţívanými dokumenty jsou: -

Business Case;

-

Zakládající listina projektu;

-

Plán řízení projektu;

-

Change request;

-

Closing evaluation report.

1.5.3.1. Business Case Dokument s anglickým názvem Business Case (dále jen „BC“) popisuje náklady projektu a následné očekávané přínosy, tj. zda budou tyto náklady „zaplaceny“ 27

jeho implementací. Dále uvádí rizika, které jsou s realizací projektem spojena. Je logické investovat do něčeho, co má návratnost a riziko je pod kontrolou. Dokument BC by měl obsahovat především tyto oblasti: -

manažerské shrnutí – stručné vysvětlení obsahu aktivity;

-

důvod implementace – vysvětlení nezbytnosti realizace v kontextu se strategií společnosti;

-

očekávaný přínos – zhodnocení finančních i nefinančních přínosů, úzce spojených s cíly a strategií;

-

očekávaná rizika – seznam rizik, jejich kvantifikace a opatření;

-

časování – základní rámec termínu implementace a indikace přínosů;

-

náklady – výše finančních i nefinančních (kapacity pracovníků) nákladů;

-

investiční ohodnocení – finančních analýzy k vyjádření přidané hodnoty projektu. Nejčastěji pouţívané - ROI 3, payback period 4, NPV 5 a DCF 6.

Ţádný projekt by neměl být spuštěn bez vyhotovení a akceptace tohoto dokumentu. Právě na jeho základě se především sponzor projektu rozhoduje, jestli bude investovat své peníze a kapacity na tuto aktivitu. Při změně podstatných náleţitostí (především trojimperativ) v průběhu ţivotního cyklu projektu, je vţdy nutno aktualizovat BC a seznámit s výsledkem sponzora i ZaSt. Protoţe pokud nebude aktualizovaný výsledek BC pozitivní, tzn. rizika jsou příliš vysoká nebo přínos nebude dostatečný, měl by se projekt zastavit a vyjasnit další vývoj.

1.5.3.2. Zakládající listina projektu Pro dokument Základní listina projektu je uţíván anglický název Project charter (dále jen „PCH“). Vyhotovuje se vţdy při zahájení jako oficiální potvrzení sponzora, ZaSt a PM o startu projektu. Autorem je vţdy PM. Jeho nejdůleţitější náleţitosti jsou:

3

Return on investement = celková návratnost/celková investice * 1 00%. Počet měsíců nebo roků po dodání projektu, kdy se náklady vrátí. 5 Net present value = [budoucí hodnota / (1 + úr. míra) poč. let ] – vstupní investice. 6 Discounted Cash flow - současná hodnota = budoucí hodnota / (1 + úr. míra) poč. let . 4

28

-

specifikace projektové aktivity – obsahem je definice cíle (předmětu) projektu a princip, který má být při realizaci projektu naplňován. Popis bez velkého mnoţství detailů, avšak výstiţná definice poţadavku. Součástí specifikace by měl být také Business Case, kterým bude vyhodnoceno, zda je přínos projektu dostatečný. Principy jsou myšleny například specifikace časového rámce nebo popis určitých strategických rámců, které je třeba brát v potaz;

-

rozsah projektu – nazýván anglicky Project scope (dále jen „PSc“), uvádí, které oblasti se budou v rámci projektu řešit a které ne, tzv. „in scope“ a „out of scope“;

-

představení projektového týmu – definice sponzora projektu, PM i jednotlivých členů projektového týmu. Zároveň nutno uvést schválené alokace jednotlivých členů od liniově nadřízených manaţerů;

-

přidělení rozpočtu – vyjádření výše a skladby finančních i nefinančních zdrojů, potřebných k realizaci;

-

organizace uvnitř projektu i napříč společností – jedná se o mapování klíčových ZaSt, nastavení předpokladů pro tvorbu projektového týmu a definici důleţitých manaţerských vazeb mezi organizační str ukturou společnosti a projektem;

-

akceptační kritéria – zahrnují proces a kritéria, která budou uţita k určení, zda dodávka projektu (produkt, sluţba, způsob dodání) je akce ptovatelná;

-

výčet základních omezení a předpokladů – pokud při realizaci projektu zadání počítá s něčím, co by mělo být splněno, aby mohlo být poţadovaného výsledku dosaţeno, je toto třeba v dokumentu uvést. V opačném případě nemusí být tato okolnost vzata v potaz při hodnocení úspěšnosti projektu.

1.5.3.3. Plán řízení projektu Plán řízení projektu (dále jen „PŘP“) zachycuje veškeré projektové aktivity, seřazené v čase. Je důleţitý výsledkem plánovací fáze a následně vyuţíván při kontrole realizační fáze. V PŘP jsou uvedeny všechny milníky, proto je nutné 29

pravidelně jej aktualizovat a s průběhem naplňování seznamovat všechny klíčové ZaSt i projektový tým. Poţadavkem je proto jednoduchá, graficky názorná vizualizace, ze které vyplývá, kde se projekt nachází a zda není v prodlení. PŘP zpracovává a aktualizuje PM, často je vyuţíván pro prezentaci. Právě pro účely jednoduché orientace byl vyvinut tzv. Ganttův diagram 7. Jedná se o druh pruhového diagramu, který se vyuţívá v projektovém řízení pro naplánování posloupnosti činností v čase. Je vyuţíván mnoha aplikacemi, nejznámějším programem je MS Project. Obrázek č. 6 - ukázka Ganttova diagramu

Zdroj: www.wikipedia.org

7

Ačkoliv je pojmenován po H. L. Ganttovi, byl vynalezen roku 1896 Karolem Adamieckym. Henry L. Gantt jej zpopularizoval na západě za první světové války a publikoval dříve neţ Karol, který navíc psal tehdy pouze v polském nebo ruském jazyce.

30

2. Fáze projektového managementu Kaţdý projekt je třeba rozplánovat a přiřadit správné zdroje na správné místo, ve správný čas, neboli rozčlenit projekt jako celek z časového hlediska a charakteru prováděných činností na několik etap, které dohromady tvoří životní cyklus projektu. Ačkoliv existuje několik různých standardů řízení projektů, v definici jednotlivých etap a potřebě prováděných aktivit se velmi podobají. Tyto etapy jsou: -

zahájení;

-

vlastní realizace a monitoring;

-

plánování;

-

ukončení.

Jednotlivé etapy na sebe navzájem navazují, jak ukazuje následující obrázek č. 7.

Zdroj: PMI

Jednotlivými

projektovými

etapami

navíc

prostupuje

několik

základních

manaţerských oblastí, které utváří definici projektového řízení. Tyto oblasti (anglicky Project management knowledge areas) v podstatě uvádí veškeré standardy a normy, které se projektovým řízením zabývají. Jedná se o následující oblasti: -

řízení projektového provedení (integration management);

-

řízení obsahu/záměru projektu (scope management);

-

řízení časování projektu (time management);

-

řízení nákladů projektu (cost management);

-

řízení kvality/jakosti projektu (quality management);

-

řízení lidských zdrojů v projektu (human resource management);

-

řízení rizik projektu (risk management);

-

řízení komunikace v projektu (communication management); řízení obstarávání a smluvních vztahů (procurement management). 31

Následující tabulka přináší strukturu vyuţití jednotlivých činností v určitých fázích projektu. Tabulka č. 4 - prováděné aktivity při jednotlivých projektových činnostech Projektové etapy Zahájení

Plánování

Realizace

Monitoring a

Ukončení

kontrola Řízení

Vyhotovit PCH Vyhotovit PŘP

provedení

Směrovat a řídit

Monitoring a kontrola Ukončit

projekt. realizaci

postupu prací

projekt

Provést revizi a sjednocení změn

Řízení

Sběr obch. poţadavků

Ověření a kontrola

obsahu

Definovat obsah

rámce obsahu

Vytvořit WBS

projektu

Řízení

Definovat a seřadit

Kontrola dodrţování

časování

prováděné aktivity

časového plánu

Odhadnout zdroje a časový rámec Vytvořit časový plán

Řízení

Odhadnout náklady +

Kontrola čerpaných

nákladů

určit rozpočet

nákladů

Řízení

Definovat parametry

Řídit kvalitu

Kontrola kvality

kvality

kvality

realizace

výstupů

Řízení

Vytvořit plán čerpání

Definovat, vytvořit

lidských

lidských zdrojů

a řídit projektový tým

zdrojů

Distribuce

Poskytovat informace

komuni-

informací

o postupu prací

kace

Řídit očekávání

Řízení

Mapování ZaSt Komunikační plán

ZaSt

Řízení rizik

Vytvořit plán řízení a

Monitoring a kontrola

identifikace rizik

rizik

Provést jakostní analýzu rizik Plán odezvy rizik

Řízení

Plán obstarávání sml.

Vést obstarávání a

Administrace

Ukončit

smluv.

vztahů

uzavírání sml.

obstarávání sml.

smlouvy

vztahů

vztahů

vztahů Zdroj: literatura [2]

Před vlastním představením projektových etap je dobré zopakovat, ţe aplikace metod projektového řízení se provádí v mnoha průmyslových i společenských 32

oblastech, proto jednotlivé úkony i etapy nemusí nutně platit na všechny. A nejsou ani povinné, nicméně jejich důslednou aplikací se můţe projekt vyvarovat zbytečných chyb nebo předejít moţným komplikacím. Výsledkem chybně nebo nedostatečně provedených procesů bývá velmi často překročení času splnění, přečerpání potřebného finančního rozpočtu nebo vyuţitých zdrojů, případně kombinace všech moţností.

2.1.

Zahájení projektu

Etapa zahájení, je fáze, jejíţ činnosti spočívají zejména ve stanovení cíle projektu a vytvoření základních předpokladů pro jeho realizaci. V některých literaturách se můţe pro tuto fázi také aplikovat název předinvestiční nebo předprojektová fáze. Je to zejména proto, ţe projektu zatím není znám strukturovaný cíl projektu a poţadovaný čas splnění. Charakteristická je v této fázi také jistá dávka nejistoty, vyplývající právě z ne zcela jasného cíle. Navíc poţadavky sponzora projektu i ZaSt mohou být v tu chvíli nepřesně definované, očekávání manaţerů nerealistické (ať uţ časově nebo finančně). Počáteční optimismus a nadšení je třeba zkonfrontovat s realitou. Na obrázku níţe vidíte procesní činnosti, které předcházejí fázi plánování. Obrázek č. 8 - diagram procesu inicializace a zahájení projektu

Rozhodování o strategických potřebách

Rozhodování o způsobu pořízení

Sestavení Zakládající listiny projektu

Vytvoření definice Předmětu projektu

Plánování


2.1.1. Stanovení cílů projektu Stanovení cíle projektu je třeba náleţitým způsobem zpracovat, aby mohl být představen a zdůvodněn. Platí, ţe důleţitá je stručnost a výstiţnost při vysvětlování podstaty projektového cíle, jak jsem popisoval v kapitole 1.5.1. 33

Vhodně pouţitou formou takového vysvětlení je například metoda PASOC, zahrnující popis důleţitých oblastí poţadovaného cíle. Principles

Pravidla a zásady platící o poţadavcích

Assumptions

Existující předpoklady podporující cíle projektu

Scope

Rozsah řešených/neřešených oblastí projektu

Objectives

Cíle vedoucí k naplnění zadání projektu

Constraints

Omezení způsobující rizika, definice závislostí.

Zdroj: vlastní zpracování

V situaci, kdy není cíl jednoznačně definován, je třeba jej maximálně upřesnit. Jelikoţ právě správná a reálná definice projektového cíle a na něj navázaných činností je povaţována za důležitý faktor úspěšnosti projektu. K vyjasnění cíle je vhodné vyuţít následující techniky: brainstorming;

brainwriting;

myšlenková mapa;

delfi.

2.1.1.1. Brainstorming Brainstorming je jedna z nejpouţívanějších technik pro určení příčiny, hledání řešení konkrétního problému, ale také definici zadání projektového cíle. Začíná se sestavením kompetentního týmu (ZaSt) a představením tématu a pravidel. Principem je soustředění maximálního počtu nápadů a myšlenek ke konkrétnímu tématu. Smyslem metody je extrahovat kvalitní nápady, které jsou následně rozvíjeny. V případě nutnosti lze setkání opakovat, měla by být plánována v intenzivním a krátkém časovém období po sobě, k zajištění připravenosti všech zúčastněných. Koordinaci setkání má na starosti PM. V případě větší komplexnosti poţadavků, to znamená například mnoţství sporných bodů (angl. issues) řešených napříč různými útvary/oblastmi, je vhodné jednotlivá setkání rozdělit na tematicky zaměřené oblasti a vytvořit tak pracovní skupiny z kompetentních ZaSt. Po vyjasnění nápadů všemi skupinami se uskuteční závěrečné setkání se zastoupením všech ZaSt, kde se prezentují závěry jednotlivých skupin, a schvaluje

34

se ucelený rámec poţadavků, které budou obsaţeny v dokumentu PCH. V případě neschválení se intenzivní setkání opakují aţ do výsledného souhlasu všech.

2.1.1.2. Myšlenková mapa Myšlenková mapa 8 je grafická

metoda zobrazující

strukturovaný záznam

myšlenek, slov, nápadů, úkolů a dalších prvků poskládaných hierarchicky kolem klíčového tématu, umístěného ve středu. Lze ji pouţít jako nástroj při analýze a řešení problémů, při studiu, organizování informací, přijímání rozhodnutí nebo při psaní. Smysl

vyuţití

myšlenkové mapy v procesech projektového řízení přináší

opodstatnění především ve fázi rozmýšlení a vyjasňování zadání (předmětu projektu). Procesně funguje stavba myšlenkové mapy následovně: klíčové slovo / výraz je uprostřed, navázaná témata se umisťují okolo a propojí se se středem spojnicemi. Témata se mohou větvit dle potřeby a pomocnými spojnicemi je moţno spojit vztahy, které jdou napříč hierarchií. K vyjádření jednotlivých témat by mělo být uţíváno krátkých slovních spojení, není doporučeno uţívat dlouhých vět. Jak uţ název definuje, jedná se o mapu, která vzniká z myšlenek. Hlavním úkolem je proto, neomezovat se ţádným faktorem, který brání soustředění a "rozmachu" kreativity tak, jak zobrazuji na následujícím obrázku. Obrázek č. 9 - myšlenková mapa

Zdroj: http://toncar.cz/Clanky/myslenkove_mapy1.html

8

Moderní forma vyuţití myšlenkové mapy je připisována anglickému psychologovi Tony Buzanovi a jeho bratrovi Barrymu, kteří ji poprvé zveřejnili na jaře 1974. Podobná schémata lze však nalézt ve starém Řecku, u novoplatónského filosofa Porfyrios z Tyru.

35

2.1.2. Vyjasnění potřeby projektu u top managementu Realizaci projektu je nutno vysvětlit top managementu společnosti. Pokud tento krok nebude učiněn, mohou nastat obtíţe při budoucí podpoře projektu, případně při jeho realizaci. Zároveň tak lze spolehlivě ověřit, ţe poţadovaný cíl je v souladu s celkovou strategií organizace, a má proto smysl pokračovat ve vynaloţen ém úsilí.

2.1.3. Zpracování projektové dokumentace Ve fázi zahájení projektu je nutná příprava či akceptace projektových dokumentů, kterými se projekt „institucionalizuje“. Tímto krokem se vytvoří psané závazky a argumenty, kterými se projekt bude řídit na straně jedné a zároveň jej bude opravňovat k uskutečňování plánovaných činností na straně druhé.

2.1.3.1. Schválení Business Case O parametrech a důleţitosti tohoto dokumentu jsem se zmiňoval v kapitole 1.5.3.1. Akceptace tohoto dokumentu, který je při zahájení projektu vytvořen, je nezbytným krokem k jeho uskutečňování.

2.1.3.2. Vyhotovení Zakládající listiny projektu Prvním úkolem zvoleného PM je především seznámení se s projektem a jeho obsahem. Pro toto období je pro PM typické časté jednání se zadavatelem projektu i jednotlivými ZaSt. Na základě získaných informací, především od zadavatele PM, vyhotoví PCH. Jak jsem zmiňoval v kapitole 1.5.3.2., jsou důleţitými částmi dokumentu především definice předmětu projektu, úvodní odhad trojimperativu, přiřazení rozpočtu sponzorem projektu, identifikace klíčových ZaSt a sestavení projektového týmu.

36

2.2.

Plánování projektu

Plánovací činnosti napomáhají v projektu při koordinaci a komunikaci, poskytují základ pro sledování průběhu a díky tomu umoţňují vyhnout se případným problémům. Plány jsou důleţitou součástí kaţdého strategického rozhodování manaţerů, nejen v oblasti projektů. Na jejich základě je moţné rozhodovat, v jaké fázi se projekt či jakákoliv jiná aktivita nachází a porovnat s odhadovaným (plánovaným) vývojem. Plány jsou simulací projektu, protoţe obsahují písemný popis toho, jak, kdy a kým budou splněny parametry „trojimperativu! V plánovací fázi projektu, jak můţete vidět i tabulce č.4, jsou především důleţité a neodmyslitelné tyto činnosti: -

plánování provedení;

-

plánování kvality;

-

plánování času;

-

plánování řízení rizik;

-

plánování zdrojů;

-

plánování komunikace.

-

plánování rozpočtu;

Nad těmito konkrétními procesními plány stojí PŘP, který poskytuje ucelený přehled o aktuálním stavu projektu. Pravidelně jsou s ním seznamováni všichni klíčoví účastníci projektu.

2.2.1. Plánování provedení projektu Cílem plánu provedení je zajistit, aby bylo provedeno vše, co je třeba pro splnění veškerých parametrů cíle projektu. Staré přísloví praví: „Kdyţ nevíš, kam chceš jít, kaţdá cesta tě tam dovede.“ – plán je proto relevantní tehdy, pokud je jasně vytyčený cíl projektu, ke kterému se směřuje.

37

2.2.1.1. Plánování dle techniky strukturovaného členění V okamţiku utváření cíle projektu a jednotlivých poţadavků je zapotřebí rozdělit projekt do pracovních balíků, úkolů nebo činností. K tomuto účelu se pouţívá především Technika strukturovaného členění, anglicky Work Breakdown Structure (dále jen „WBS“). Fakticky se jedná o rozpad jednotlivých prvků do niţších, detailnějších balíků. Tato technika především zajišťuje identifikaci a propojení všech projektových činností. Způsobem strukturovaného členění je moţné provádět rozpad balíků do nejrůznějších úrovní detailu. Ne vţdy je nutné jednotlivé prvky dekomponovat aţ na úplně nejniţší úroveň. Čím více pracovních balíků, tím náročnější vzájemná koordinace a řízení. Proto platí zásada, ţe prvky na nejniţší úrovni WBS by měly být tak detailní, aby je bylo moţné efektivně řídit a sledovat. Právě nejnižší pracovní balíky WBS se budou realizovat – veškeré nadřazené prvky jsou jen souhrnem níţe realizovaných prvků. Obrázek č. 10 - obrázek techniky strukturovaného členění (WBS)


Techniku WBS je moţné pouţít i jinak, neţ podle členění dle činností nebo úkolů. Lze ji vyuţít také například při členění podle: -

výstupů (produktů) projektu;

-

funkčních oblastí;

-

místa výkonu práce (např. jednotlivé bloky elektráren);

-

komponent nebo částí produktu; 38

-

zodpovědností (kombinace členění dle činností proti organizační struktuře) ;

-

projektových etap (obr. č. 11).

Obrázek č. 11 - Alternativní WBS dle etap projektu


Vytvořením WBS je provedena identifikace jednotlivých pracovních balíků. Následně je však nutné jednotlivé oblasti svázat také s časovým a rozpočtovým plánem, aby byly jednoznačně znázorněny termínové a finanční dopady u jednotlivých plánovaných aktivit.

2.2.2. Plánování času Časový rozpis jednotlivých projektových činností je nedílnou součástí PŘP. Tato část obsahuje všechny informace o tom, v jakých termínech a časových sledech budou práce na projektu probíhat. Sestavování časového plánu není činností nezávislou. Je nutno brát v potaz nejen ostatní aspekty trojimperativu (zdroje, náklady), ale také další důleţité elementy, jako například kvalitu a rizika. Při plánování času se obvykle vychází z předchozího kroku, definice činností určených k realizaci. Poté následuje seřazení jednotlivých činností a nalezení jejich logických návazností. Konkrétní činnosti mohou vzájemně navazovat pouze v určitých případech, které je právě nutno identifikovat. Vazby mezi jednotlivými činnostmi ovlivňují nejrůznější interní i externí faktory, jako například kapacita lidských zdrojů, technologická omezení, potřebné mnoţství zdrojů, finanční toky nebo 39

termíny dodání vstupů nebo výstupů. Existuje více typů vazeb mezi jednotlivými činnostmi. Mezi nejčastěji pouţívané se řadí: -

konec – začátek → nejčastější typ vazby, kdy předcházející činnost musí skončit, aby nová mohla začít;

-

konec – konec → předcházející činnost musí skončit, aby nová mohla skončit;

-

začátek – začátek → předcházející činnost musí začít, aby nová mohla začít;

-

začátek – konec → předcházející činnost musí začít, aby nová mohla skončit.

K procesu řazení, identifikace závislostí a následnému grafickému znázornění se pouţívá síťový graf.

2.2.2.1. Kritická cesta projektu Termín kritická cesta projektu, critical path method (dále jen „CPM“), se běţně pouţívá pro zvýraznění nejkratší moţné doby realizace projektu, která zahrnuje provedení všech identifikovaných činností s nulovou časovou rezervou. Vizualizaci kritické cesty vhodně zajistí tzv. síťový graf, který znázorní řazení a identifikace jednotlivých závislostí. Navíc síťový graf dodrţuje tyto základní parametry: -

má jeden začátek;

-

má jeden konec;

-

šipky jsou orientovány zleva doprava a representují tok času;

-

jsou znázorněny milníky (významné události projektu).

Obrázek č. 12 - síťový graf kritické cesty projektu


40

V dnešní době se díky přehlednějšímu uspořádání pouţívá především Ganttův diagram nebo Ganttův graf, který jsem jiţ představoval v kapitole 1.5.3.2.

2.2.3. Plánování zdrojů Při definici plánování zdrojů je uvaţováno především zajištění lidských zdrojů, tedy pracovníků různých profesí, pro doručení poţadovaného výstupu projektu. Zejména u sloţitých projektů zahrnujících celou řadu profesí poskládaných z několika organizačních jednotek, nebo dokonce různých organizací , je obsazení projektových rolí, zajištění potřebných specializací a současná optimalizace nákladů, jedním z nejsloţitějších úkolů, před které je projektový manaţer postaven. Rozhodující pro obsazení rolí jednotlivými pracovníky v rámci projektového týmu jsou tyto skutečnosti: -

odbornost a úroveň kvalifikace k poţadovanému výkonu;

-

dostupnost v čase vzhledem k harmonogramu;

-

náklady na výkon činnosti podle popisu vzhledem k rozpočtu.

O alokaci potřebných zdrojů ţádá PM jednotlivé liniové manaţery, kteří mají dostatečné znalosti o úrovni kvalifikace a časové dostupnosti jednotlivých pracovníků. V takovém případě hraje důleţitou roli vzájemná důvěra a otevřenost, protoţe v opačném případě můţe být do expertní projektové role obsazen pracovník, který své zkušenosti teprve získává nebo expert, bez dostatku volného času. Tím se riziko nerealizování projektu v poţadované kvalitě velmi zvyšuje. Takovým situacím nelze úplně zabránit, ale výrazně pomáhá, pokud společnost uchovává databázi, obsahující reference jednotlivých pracovníků – popisy rolí a hodnocení výsledků jednotlivých projektů, společně s mnoţstvím potřebného času. Údrţba takových údajů nemusí být pro organizaci velkou zátěţí, pokud existuje taková interní metodika, která podporuje tvorbu a průběţnou aktuali zaci jednotlivých informačních databází.

41

2.2.3.1. Optimalizace v oblasti lidských zdrojů Optimalizace v oblasti řízení lidských zdrojů se týká především vyjednávání o kapacitách jednotlivých členů projektového týmu a jejich průběţné usměrňování do míst s největší přidanou hodnotou. Vyţaduje vysokou míru flexibility a kreativity k řízení nasazení konkrétních jednotlivců spolu s konflikty priorit u nákladů, odborností a ostatních projektů. Doporučené postupy v oblasti optimalizace jsou: -

posuny činností v harmonogramu efektivním vyuţitím vazeb, překryvů a prodlev a jejich balancování podle disponibilní kapacity poţadovaných specialistů;

-

s alokací kapacit začínat od speciálních a nedostatkových zdrojů potřebných pro aktivity na kritické cestě projektu;

-

přesuny pracovních sil z větví harmonogramu s volnějším tempem do oblastí kritické cesty;

-

přidání dodatečných zdrojů pro krytí části pracovní kapacity;

-

prodlouţení pracovní doby;

-

přehodnocení časů na činnosti v problémových sekvencích projektu;

-

návrhy alternativních řešení a pouţití alternativních technologií.

Navíc PMI 9 shrnuje zajímavé zkušenosti jednotlivých PM do těchto zákonitostí lidských zdrojů: -

pokud je k dispozici na určitý pracovní úsek dvakrát více zdrojů, neţ je zapotřebí, pak je obvykle moţné zkrátit potřebnou dobu na polovinu;

-

posledních 10 % projektu často spotřebuje 30 % zdrojů.

Další důleţité informace týkající se například členů projektového týmu nebo rozdíly mezi liniovou a projektovou organizací jsem představoval v kapitole 1.5.2. Organizace projektu.

9

PMI = Project management institut, viz kapitola 1.4.1. PMI

42

2.2.4. Plánování rozpočtu Plánování rozpočtu, jako další součást PŘP, navazuje na zmíněné plánování času, společně s plánováním zdrojů. Kaţdý projektový rozpočet by měl obsahovat na jedné straně plánování nákladů a na druhé plánování výnosů 10. Obvykle bývají projekty naplánovány jako ziskové, coţ logicky znamená, ţe výnosy převýší vynaloţené náklady. V nejhorším případě by měly být projekty alespoň bilančně neutrální, ovšem v poslední době u projektů, vyvolaných zejména legislativní povinností, existují také projekty pasivní.

2.2.4.1. Stanovení nákladů projektu O nákladech se v této fázi projektu sice nemluví poprvé, ale zde je jednoznačně nezbytné, aby byly výsledné odhady co nejpřesnější. Známe totiţ detailní záměr projektu, sloţení projektového týmu a také časování. K definici odhadu nákladů projektu existuje mnoho technik: -

kvalifikovaný (expertní) odhad – prováděno zkušeným expertem;

-

analogický odhad – aplikován podobný odhad podobného projektu;

-

parametrický odhad – součet jiţ oceněných balíků aktivit z jiných projektů;

-

cenová nabídka od dodavatele;

-

vyuţití softwaru odhadujícího náklady;

-

…atd.

Pro vyuţití některé z výše uvedených technik je nutno také uvést, v jakých jednotkách či měnách se budou náklady vyjadřovat. V nejjednoduţším případě je moţné pouţívat české koruny, avšak v dnešním světě se stále častěji pouţívají nové, jiţ zaţité termíny – člověkohodina, člověkoden, člověkotýden. Často vyuţívaným termínem, samozřejmě po vyjádření v českých korunách, je dnes „člověkoden“, anglicky nazývaný manday (dále jen „MD“). Náklady projektu dělíme na přímé a nepřímé, jak ukazuje následující tabulka.

10

Detaily o způsobech identifikace nákladů a především výnosů jsem představoval v kapitole 1.5.3.1. Business Case.

43

Tabulka č. 5 - ukázka přímých a nepřímých nákladů Přímé náklady

Nepřímé náklady

osobní náklady na projektové členy

nepřímé osobní náklady

materiál, práce, sluţby

podnikový marketing

nákup technologií

provoz budov a technologií

cestovné projektového týmu

daně, odvody a poplatky

náklady na subdodávky licence, certifikace Zdroj z literatury [4]

S výsledným plánem nákladu projektu, který je časově rozdělen dle časové posloupnosti projektu, se následně pracuje s důrazem na dodrţování čerpání v rámci projektu. Je odpovědností PM, aby o plánu čerpání pravidelně seznamoval členy řídícího výboru, především pak sponzora projektu. Jakákol i změna rozpočtu projektu na nákladové straně znamená nutnost přehodnocení výhodnosti jeho realizace. Proto je tak důleţité připravit kvalitní plán nákladů projektu a důsledně dodrţovat jeho čerpání.

2.2.5. Řízení a plánování kvality Oblast řízení kvality prostupuje všechny fáze projektového řízení. Kvalita projektu je totiţ dána mírou, kterou splňují všechny předem definované, ale i později indikované komponenty. Tuto oblast velmi ovlivňuje především organizace, v rámci které se projekt zavádí, aplikováním náleţitého chování, mezi které patří: -

soustavná politika budování kvality;

-

operační definice a metriky pro kontrolní procesy řízení kvality;

-

seznamy a tabulky (tzv. checklisty), které jsou metodický m vodítkem pro provádění specifických kontrol.

Kvalita výrobků a sluţeb neovlivňuje jen spokojenost jejích uţivatelů, ale má závaţnější důsledky týkající se prosperity podniků i celkové úrovně ţivota společnosti. Jakékoliv opomíjení kvality v kterékoliv fázi projektu, můţe znamenat reálné riziko nedosaţení očekávaného cíle!

44

2.2.5.1. Definice kvality Parametry kvality je nutné jasně definovat, co konkrétně tato kvalita znamená pro klíčové konzumenty výstupu projektu neboli ZaSt. Právě těmi je následně akceptována míra kvality dodávky, jinak nazvané „akceptační kritéria“. Pojem akceptační kritéria je velmi podobný běţně známému pojmu ISO 11, který prakticky představuje míru kvality, jako souhrn všech znaků produktu nebo služby, které ovlivňují jejich schopnost uspokojit stanovené a předpokládané potřeby. Takto odsouhlasená akceptační kritéria rozhodují o úspěšnosti realizace projektu. O způsobu řízení kvality, anglicky nazvanému Quality management existuje nemálo obsáhlých publikací, pro účely této práce jsou dostačující výše uvedené všeobecné informace.

2.2.5.2. Řízení kvality Odpovědnost dosahování a řízení kvality je výhradně v kompetenci managementu organizace. Tomuto cíli pomáhá také vhodné organizační uspořádání struktury společnosti, s důrazem na vyuţití projektových týmů. Na druhou stranu jsou někdy konkrétní standardy řízení kvality vyţadovány, zejména v odvětvích jako např. potravinářství, zemědělství a chemický průmysl. Jedním z moţných způsobů zajištění kvality projektu je certifikace kvality dle norem ISO. S rostoucí náročností zákazníků však začíná být v jednotlivých organizacích pouţívána moderní koncepce Total Quality Management (dále jen „TQM“) neboli systém řízení kvality, jehoţ cílem je vytvoření a zavedení vlastní celopodnikové strategie kvality, která musí být v souladu s dalšími podnikovými strategiemi. TQM tak pomáhá eliminovat vznik úzkých míst a navyšování

11

Mezinárodní organizace pro standardizaci (ISO) byla zaloţena v Ţenevě a je celosvětovou federací národních normalizačních orgánů, jejichţ normy ISO 9000 slouţí jako standard pro řízení kvality.

45

provozních nákladů nejen u jednotlivých projektů, ale také vlastní provozní činnosti organizace.

2.2.6. Plánování řízení rizik a příležitostí Riziko

se

nachází

v kaţdé

oblasti

lidské

činnosti,

jedná

se

vlastně

o

pravděpodobnost vzniku negativně vnímané události neboli nebezpečí. Kaţdá taková událost/hrozba je jedinečná a můţe mít jinak škodlivé následky, jiný spouštěč, jiný průběh trvání případně pravděpodobnost vzniku. O riziku se však jiţ nemluví pouze v souvislosti s nebezpečím, ale také v souvislosti s příleţitostí. Protoţe kaţdá, byť i negativní událost, můţe v konečném důsledku znamenat přínos. A právě schopnost reakce na takové situace

vytváří v dnešním

konkurenčním prostředí zajímavé příleţitosti. Riziko je faktor prostupující všemi fázemi projektového cyklu. Jiţ v počáteční fázi projektu je o riziku zmínka v BC, viz kapitola 1.5.3.1. Kompletní analýzu rizik je třeba provést ve fázi plánování podrobného PŘP a dále jej sledovat a aktualizovat zejména v průběhu realizace a monitoringu. Kvalitní a aktualizované výstupy potom mohou být velmi uţitečné při analýze rizik u budoucích projektů.

2.2.6.1. Používané metody řízení rizik Při řízení rizik existují dvě hlavní kategorie postupů analýzy rizika, definující obsahově či hodnotově velikost rizik – kvalitativní a kvantitativní. Kvalitativní metody pátrají po tom, jak srovnat relativní významy rizik, kterým projekt čelí, v podmínkách vlivu jejich výskytu na výstupu projektu. Pozitiva tohoto přístupu jsou zejména ve schopnosti hodnotit dopady na organizaci nebo jedince, které nelze elementárně vyjádřit v peněţních jednotkách. Vyuţívá se především v úvodu projektu ke zjištění mnoţství a relativního rozsahu rizik, případně si s těmito metodami vystačí ten projekt, k jehoţ hodnocení takové analýzy stačí. Výstupem je především popisná škála a obsahová definice rizika.

46

Známé

a

pouţívané

kvalitativní

metody

jsou:

Brainstorming,

A nalýza

předpokladů, Delfi, Pohovory, HAZOP, FRAP, FMECA, Metoda plánování scénářů, Registry rizik, Mapování rizik, RIPRAN a Maticový diagram rizik. Kvantitativní

metody

jsou

zaměřené

především

na

určení

následků

a

pravděpodobností v číselných hodnotách. Je samozřejmě moţné kvantitativními metodami výstupy z těch kvalitativních dále rozpracovat. Výsledné hodnoty jsou zatíţeny neznámými a proměnnými faktory, které mohou výsledek ovlivnit významnou nejistotou. Z kvalitativních

metod

hodnotově

(kvantitativně)

zkoumají

riziko

metody

RIPRAN a Maticový diagram rizik. Dále existují metody např pojmenované Rozhodovací stromy, Simulace Monte Carlo a Analýza citlivosti.

2.2.6.2. Proces analýzy a řízení rizik Abychom mohli s rizikem efektivně pracovat je nutné také riziko poznat, umět jej analyzovat a také s ním dále pracovat. Identifikace ohroţeného místa Ohroţená místa lze hledat především tam, kde můţe dojít k nezanedbatelné ztrátě integrity, důvěryhodnosti, případně dostupnosti. V případě projektů se často jedná o oblasti trojimperativu a také kvalitu výstupu. Identifikace ohroţení Ohroţení je proces, reprezentující jakoukoliv událost, která svým provedením vyvolá nechtěnou, případně neočekávanou reakci, převáţně se škodlivými následky. Jako jednoduchý příklad můţe slouţit ohlášené propouštění, které způsobí nedostatek lidských zdrojů, alokovaných na projekt. Nebo například odchod klíčové členky projektového týmu na rizikové těhotenství. Obě tato ohroţení mohou způsobit nemalé škody. Z výše uvedených příkladů je zároveň patrné, ţe některá ohroţení jsou předem známá, naopak některé velmi překvapivé. Velká míra nejistoty je zde patrná. 47

Definice pravděpodobnosti vzniku Pravděpodobnost vzniku určuje, jak moc je reálný vznik zkoumané hrozby. K tomu se pouţívá číselné vyjádření, většinou v %, které ve výsledku určuje míru pravděpodobnosti jako např. v tabulce č. 6. Tabulka č. 6 - rozlišení míry pravděpodobnosti dle metody RIPRAN Vysoká pravděpodobnost

nad 66 %

Střední pravděpodobnost

33 – 66 %

Nízká pravděpodobnost

pod 33 %


Uvedená výše však nemůţe být z povahy názvu nikdy přesná, jedná se vţdy o kvalifikovaný odhad. Míra je odvozena na základě znalostí a zkušeností odhadce, případně

vypočítána

na

základě

dostupných

číselných

údajů.

Stanovení

pravděpodobnosti je většinou v kompetenci PM, v případě velkých projektů Risk manaţera. Kvantifikace rizika Míra rizika se u jednotlivých projektů z různých hospodářských odvětví liší. Například v oblasti stavebnictví, kde se výrobní procesy zpravidla opakují nebo jsou velmi podobné, je míra rizika poměrně dobře kvantifikována. Naproti tomu u projektů výzkumného nebo vývojového charakteru s vysokou mírou nejistoty, je kvantifikace velmi obtíţně predikovaná. Navíc je při kvantifikaci rizika nutné brát v potaz míru dopadu hrozby neboli rozsah škody. Velikost dopadu zkoumané hrozby je především důleţitá pro zjištění, jaká je váţnost případného rizika, viz následující tabulka . Tabulka č. 7 - definice nepříznivých dopadů na projekt dle metody RIPRAN Ohroţení cíle projektu nebo Velký dopad

Ohroţení koncového termínu projektu nebo Moţnost překročení celkového rozpočtu projektu nebo Škoda více neţ 20 % z hodnoty projektu

Střední dopad

Škoda 0,5 % – 19 % z hodnoty projektu nebo

48

Ohroţení termínu, nákladů, resp. zdrojů, coţ si vyţádá akční zásahy do PŘP Nízký dopad

Škody do 0,5 % z hodnoty projektu Dopady vyţadující určité zásahy do PŘP


Jestliţe známe dle tabulky č. 6 míru pravděpodobnosti a z výše uvedené tabulky velikost dopadu, lze jednoduchým přístupem určit hodnotu rizika (dále jen „HR“): HR = P (pravděpodobnost) x ROZSAH ŠKODY Vţdy je třeba kalkulovat také s určitou úrovní nepřesnosti. Dle změny míry P nebo dopadu je změna HR znázorněna v tabulce č. 8. Tabulka č. 8 - vazební tabulka HR dle metody RIPRAN Vysoký dopad

Střední dopad

Nízký dopad

Vysoká P

vysoká HR

vysoká HR

střední HR

Střední P

vysoká HR

střední HR

nízká HR

nízká HR

nízká HR

nízká HR

Nízká P Zdroj: literatura [1]

Nalezení opatření (proces prevence, případně neutralizace) Do oblasti řízení rizik patří také nalezení vhodných opatření, která buď eliminují samotný vznik rizika (spouštěč), nebo jej alespoň neutralizují, případně sníţí. Pro tuto oblast můţe být také pouţíván termín odezva na riziko. Například riziko zpoţděného termínu dodávky je moţné eliminovat nařízením přesčasů členů projektového týmu. Případně vyvarovat se riziku nedodání projektové subdodávky nespolehlivou firmou můţeme jednoduše vybráním jiného, prověřeného a spolehlivého subdodavatele. Opatření, především ta preventivní, je moţné aplikovat ještě před vznikem samotného rizika, právě pro jeho eliminaci. V ostatních případech se jednotlivá opatření uvádí do chodu aţ v okamţiku vzniku rizika. Zhodnocení Na závěr, kdy jsou známy všechny potřebné informace (finanční i nefinanční), je nutné rozhodnout o nasazení či pozastavení potřebného opatření. Ve většině 49

případů se navrhovaná opatření pouţijí, mohou však nastat situace, kdy je realizace opatření nákladnější nebo náročnější neţ způsobená škoda. V takovém případě, po zváţení, je moţné tuto škodu „obětovat“. Výše uvedené kroky analýzy rizik je moţné jednotlivě zpracovávat do různé hloubky, případně pouţitím jiných procesů přístupu. Z těchto odlišných přístupů vzniklo velké mnoţství známých a pouţívaných metod, které jsou aplikovány nejen v oblasti řízení projektových rizik.

2.2.6.3. Řízení příležitostí V rámci oblasti řízení rizika, které je vnímáno jako negativně vnímaná událost, je třeba také řídit moţné příleţitosti. Situační příklad: Projekt s napjatým rozpočtem se rozhodne zadat dodávku firmě, která nabízí niţší cenu o 130 tisíc korun, avšak máme informace, ţe z posledních 10 dodávek, byly dvě se závadou (pravděpodobnost = 20 %). Oprava závady stála 80 tisíc k orun. Hodnota rizika: 0,2 x 80 000 = 16 000 Kč. Avšak proti riziku stojí příleţitost, ţe v 80 % projekt ušetří 130 tisíc korun, kdyţ bude náhodou dodávka se závadou, tak alespoň 50 tisíc korun. Z uvedeného vyplývá, ţe v tomto případě příleţitosti převaţují nad riziky! Zdroj: literatura [1]

Řízení příleţitostí se velmi podobá řízení rizik. Příleţitosti je třeba také nejprve identifikovat, kvantifikovat a zorganizovat opatření k jejich vyuţití. Také proto se zároveň s definicí rizik uvaţuje i o případných příleţitostech. Proto platí: Pravděpodobnost příležitosti = 1 – pravděpodobnost rizika Popis pouţívaných metod a procesů není třeba uvádět pro jiţ několikrát zmiňovanou provazbu s riziky, o kterých jsem informoval výše.

50

2.3.

Vlastní realizace a monitoring projektu

Fáze plánování simulovala předpokládaný a očekávaný průběh projektových prací, fáze vlastní realizace odhalí, jak se připravené plány setkají se skutečností. Sledování plánů proti skutečnému stavu realizace zajišťuje monitoring. Tak je okamţitě patrné, jak si projekt aktuálně stojí. V okamţiku, kdy se udělené řídící pokyny mohou vinou neočekávaných faktorů ubírat jiným směrem, neţ bylo původně plánováno, aplikuje se proces řízení změn. Výstupy z uvedeného monitoringu jsou dále pouţity pro komunikaci na všechny ZaSt, včetně sponzora projektu. Těm je PM zavázán, pravidelně podávat zprávy.

2.3.1. Směřování a řízení realizace projektu Proces směřování a řízení realizace projektu obsahuje zejména následující procesy: -

dokončení definice projektových poţadavků;

-

tvorba projektových výstupů;

-

obstarat, vytrénovat a řídit členy projektu;

-

implementovat plánované metody a standardy;

-

řídit rizika;

-

řídit dodavatele a odběratele;

-

sbírat a implementovat náměty na zlepšení, za účelem efektivity řízení.

Pokud některá z činností neprobíhá dle očekávání nebo se objeví nové riziko, má PM za úkol situaci promptně zmapovat a stabilizovat, například pomocí krizového managementu. Hlavním úkolem krizového managementu je čelit aktuální hrozbě, vyřešit ji s minimálním dopadem na organizaci a zároveň učinit preventivní opatření, aby k podobným situacím nedocházelo. Jednoznačně nejdůleţitějšími faktory jsou čas reakce a komunikace, které nejlépe minimalizují hrozící škody. Krizový

management

však

neposkytuje

výběr

z mnoha

moţných

akceptovatelných řešení, ale aplikuje takové řešení, které způsobí nejméně škod.

51

a

2.3.2. Řízení změn Změny se v ţivotním cyklu projektu vyskytují dvojího typu: -

aplikace projektových změn na organizaci;

-

změnové poţadavky a jejich implementace do PŘP a cíle projektu.

2.3.2.1. Aplikace projektových změn na organizaci Aplikace projektových změn na organizaci zahrnuje: -

provedení dopadové analýzy;

-

definice vhodných úprav;

-

řízení implementace změn.

Implementací změn, například nových zákonných či jiných poţadavků, však proces nekončí. Je nutné především přijmout změnu v pojetí, ve vnímání, v kultuře a vlastním vyuţití této změny v celé organizaci. Proto je třeba naplánovat aktivity týkající se školení, úpravy existujících manuálů a postupů, převzetí do provozní správy, případně změny ovlivňující obchodní či výrobní procesy. Nezřídka se stává, ţe změna vyvolá nutné úpravy také v organizační struktuře společnosti.

2.3.2.2. Změnové obchodní požadavky Proces označování změnových obchodních poţadavků nastává v situaci, kdy je schválen PCH a nastaven PŘP, na jejichţ základě jsou alokovány potřebné zdroje a definován časový rámec implementace. V rámci identifikace takového poţadavku je třeba brát v potaz tyto aspekty: -

komplexnost poţadavku (co vše poţadavek ovlivní);

-

mnoţství potřebných zdrojů na implementaci;

-

priorita/důleţitost (co znamená, pokud poţadavek bude/nebude realizován);

-

zhodnocení rizik;

-

rychlost realizace; 52

-

rozsah nákladů;

-

v případě navýšení rozpočtu, finanční dopad do BC.

Návrh na změnu můţe dát člen projektového týmu, sponzor, případně jakákoli ZaSt. V kaţdém případě musí být poţadavek evidován jako Change request 12. Realizace či nerealizace poţadavku je závislá především na vyjmenovaných finančních aspektech, které pro své rozhodnutí vyuţije PM, v případě malého poţadavku, nebo sponzor, zejména pokud se jedná o jakýkoliv dopad do trojimperativu, případně zásadní strategické změny projektu.

2.3.3. Monitoring Účelem provádění monitoringu jsou především dokončování naplánovaných úloh a jejich pravidelná kontrola, pracovat se spornými body, problémy a riziky, provádět pravidelný odečet naplňování PŘP a reportovat progres sponzorovi a ZaSt. Sledují se tyto cíle: -

je kladen důraz na dodávku poţadovaného a naplánovaného výstupu a tak je zamezeno jakýmkoliv neplánovaným a nekontrolovatelným změnám;

-

známá rizika a sporné body jsou pod kontrolou;

-

veškerá ustanovení v dokumentu BC jsou pod kontrolou;

-

poţadovaného

výstupu

je

dosahováno

ve

schválených

nákladech

(finančních i kapacitních), čase i kvalitě tak, aby podporovali dosahování poţadovaných benefitů; -

jednotlivá očekávání všech ZaSt jsou pod kontrolou;

-

projektový tým je plně zaměřen na dodávku projektového výstupu.

2.3.3.1. Kontrola provedení plánovaných úloh V rámci kapitoly 2.2.1. Plánování provedení projektu (a jejích podkapitol) byla představena metoda členění WBS na pracovní balíky, které je třeba v realizační fázi zpracovat. Úkolem PM je rozdělit zpracování pracovních balíků mezi členy

12

Jedná se o dokument obsahující popis změny, viz kapitola 1. 5.3.

53

projektového týmu, delegovat jednotlivé odpovědnosti a následně nastavit vhodný způsob monitoringu. Jakmile je pracovní balík dokončen, měl by PM zkontrolovat jeho realizaci oproti nastaveným milníkům, které se většinou týkají: -

obsahu;

-

nákladů;

-

času;

-

kvality.

-

zdrojů;

2.3.3.2. Řešení sporných bodů, problémů a rizik Na úvod bude vhodné definovat rozdíl mezi sporným bodem (anglicky „issue“) a problémem a uvést souvislost s rizikem. Sporný bod je událost, která se neplánovaně stala a vyţaduje si řešení v rámci projektového týmu. Problém je situace, kterou projektový tým nedokáţe vyřešit, a proto řeší PM, případně eskaluje na vyšší manaţerskou úroveň. Riziko je nejistá událost či kombinace událostí, které se mohou stát a tím ovlivnit, případně znemoţnit, dosaţení poţadovaného cíle. Rizika,

která

mohou

projekt

ovlivňovat,

jsou

pečlivě

zadokumentována

z předchozích přípravných etap a projektový tým by s nimi měl počítat. Avšak při vlastní realizaci nastávají neplánované události, které musí projektový tým řešit. Jedná se právě o sporné body, případně problémy, jejichţ důsledkem můţe být vznik rizika. Pokud není projektový tým schopen problém vyřešit, je nutno včas eskalovat tuto situaci na vyšší manaţerské rozhodnutí. V takové situaci je však zároveň nutné dodat k poţadovanému rozhodnutí potřebné podklady: -

popsat eskalovaný problém;

-

definovat moţné dopady;

-

navrhnout varianty řešení.

54

2.3.3.3. Pravidelný odečet naplňování PŘP Kontrolu realizace projektu ve všech projektových fázích dle PŘP zajišťuje pravidelně prováděný odpočet aktuálního stavu. V případě odchylky od plánu, ať uţ časem, zdroji, kvalitou či obsahem, PM musí neprodleně reagovat. Pokud to není v jeho kompetenci, postupuje stejně, jako v předchozí kapitole s principem eskalace na nadřízené. V rámci kontroly naplňování PŘP proto není dostačující kontrolovat pouze splnění provedených pracovních balíků. Je také nutné plánovat před blíţícím se koncem spuštění následujících aktivit.

2.3.3.4. Reportování o projektu Úkolem PM je pravidelně poskytovat členům řídícího výboru důleţité a podstatné informace o stavu projektu a tím řídit jejich očekávání. K pravidelnému reportu se vyuţívají tyto informace: -

stav plnění důleţitých projektových milníků;

-

progres od posledního reportu;

-

stav rizik;

-

plán dalších kroků.

Tato činnost má pro PM několik důleţitých přínosů: -

členové řídícího výboru jsou obeznámeni se stavem projektu, především riziky i problémy;

-

členové řídícího výboru se podílejí na tvorbě projektu;

-

je řízeno očekávání všech ZaSt;

-

PŘP je pravidelně autorizován.

55

2.4.

Ukončení projektu

Ukončení projektu je nastartováno v situaci, kdy je v rámci realizační fáze dodán projektový cíl a začíná probíhat vyhodnocování jeho skutečných dopadů na výsledné uţivatele. Cílem této fáze jsou tyto výstupy: -

ověření akceptace projektové dodávky uţivateli;

-

zajištění pokračující podpory produktu (převzetí vlastnictví);

-

revidovat obsah dodávky projektu proti očekávání;

-

posoudit realizovaný uţitek, aktualizovat předpověď zbývajících přínosů a naplánovat ověření těch nerealizovaných;

-

zajistit pokračování monitoringu nevyřešených rizik a sporných bod ů;

-

evidovat všechny pozitivně vnímané aktivity, nápady, ověřené praktiky, zároveň však také slepé uličky, typické chyby případně systémová selhání.

Na samotnou dodávku projektu nemají jiţ tyto aktivity ţádný vliv. Provádí se především zhodnocení skutečné realizace, převzetí projektového výstupu do liniově-organizačního řízení a také se získává zpětná vazba, která slouţí jako ponaučení pro příští projekty. Popis a jednotlivé aktivity této fáze není třeba detailně rozepisovat v teoretické části práce, její přínosy budou prakticky představeny na následujícím reálném případu.

56

3. Specifika a praxe ve velké finanční společnosti V následující

kapitole

představím

pouţívané

principy

projektového

řízení

v existující finanční instituci nazvané Plavec na konkrétním realizovaném projektu, kterého jsem se účastnil. V oblasti finančnictví je vzhledem k ostrému konkurenčnímu prostředí nezbytné umět rychle reagovat a neustále nabídku produktů a sluţeb inovovat. Zpoţdění nebo dokonce opomenutí můţe mít pro společnost velmi ne gativní následky. Ztráta příleţitosti způsobí pokles zájmu o produkty společnosti, zhorší její konkurenceschopnost a logicky sníţí zisk. Realizované změny v nabídce společností musí být zároveň podpořeny z vnitra společnosti, coţ znamená zabezpečení školení pro klientské pracovníky, distribuci podpůrných materiálů, případně vybudování podpůrných útvarů na centrále společnosti, tj. případné změny organizační struktury. Uvedená kritéria poţadavků přesně splňují principy realizace dodání jednotlivých výstupů dle metodiky projektového řízení, proto je oblast finančnictví nakloněna jeho vyuţití.

3.1.

Finanční společnost a projektové řízení

Zkoumaná finanční společnost Plavec (dále jen „Plavec“) patří k nejznámějším společnostem na českém finančním trhu. Společnost je vlastněná mezinárodní finanční skupinou, která je významným poskytovatelem produktů a sluţeb v Evropě. Pouţívané principy projektového řízení byly převzaty z mateřské společnosti. Pro představu mnoţství otevřených projektů, které jsou ve společnosti Plavec vedeny, se ročně pohybuje mezi 70 - 100!

3.1.1. Principy projektového řízení v Plavci Projekty, které Plavec realizuje, lze rozdělit na tři základní skupiny: -

Technické - nevyţadována asistence obchodních útvarů, např. upgrade systémů; 57

-

Obchodní – bez nutnosti spolupráce s technickými útvary, např. marketing, kampaně, ankety;

-

Smíšené – vyţadována úzká spolupráce technických i obchodních útvarů (týká se níţe uváděného případu).

Mnoţství

realizovaných

systémů/procesů/segmentů,

projektů, je

kdy

nutno

kaţdý

v zájmu

zasahuje

do

společnosti

jednotlivých

koordinovat

a

monitorovat. Z toho důvodu existuje v Plavci útvar, který má na starosti evidenci projektů a koordinaci řízení celého projektového portfolia společnosti. Posláním útvaru je především: -

vlastnictví pouţívané projektové metodiky;

-

evidence a monitoring všech projektů (dodrţování metodiky);

-

zajištění plánování a prioritizace projektů;

-

reporting projektového portfolia představenstvu.

3.1.1.1. Vlastnictví používané projektové metodiky Útvar projektové kanceláře definuje metodické standardy projektového řízení, které sleduje, vyhodnocuje a pravidelně je v případě potřeby aktualizuje. Zároveň šíří osvětu o těchto standardech mezi jednotlivými útvary společnosti. Bez jednotně pouţívané metodiky by nemohla společnost pravidelně realizovat takové mnoţství projektů. Co však pojem projektová metodika znamená? Jedná se vlastně o principy, které pomáhají úspěšné realizaci jednotlivých projektů. Metodika definuje fáze projektu, odpovědné osoby a rozpis jednotlivých kroků a interakcí v jednotlivých projektových fázích. Názornou vizualizaci naleznete na obrázku č. 13.

58

Obrázek č. 13 - Ţivotní cyklus projektu ve společnosti Plavec

Zdroj: Útvar projektového řízení ve společnosti Plavec

3.1.1.1.1.

Odlišnosti v pojetí projektové metodiky Plavce

Metodika, uţívaná v Plavci, je z části adoptována od mateřské společnosti, vyuţívající tuto metodiku v rámci celé skupiny. Principy této metodiky jsou pouţívány především existujícími standardy PRINCE2 13 a PMI 14. Co se týká jednotlivého fázování, jak je patrné z obrázku, existují také 4 projektové fáze. Avšak od psaných standardů PRINCE2 a PMI se liší především v časování zpracování jednotlivých aktivit, jak je znázorněno v tabulce č.9. Tabulka č. 9 - odlišnosti metodiky Plavce od metodiky PMBoK Metodika Plavce Idea

-

Popis záměru

clarification

-

Hrubý odhad nákladů a pracnosti

-

Vyhotovení BC summary

-

Vyhotovení PŘP

-

Pre-study

13 14

Metodika PMBoK -

Vyhotovení PCH

-

Mapování ZaSt

-

Vyhotovení BC

-

Vyhotovení PŘP

Popis AS-IS a TO-BE

-

Definice obsahu

Definice obsahu

-

Schválení BC

Zahájení

Plánování

Viz kapitola 1.4.3. Viz kapitola 1.4.1.

59

-

Mapování ZaSt

-

Schválení BC

-

Vytvořit projektový tým

-

Vyhotovení Pre-study charteru

-

Vyhotovení PCH

Work

-

Řízení projektové integrace

Realizace a

-

Vytvořit projektový tým

execution

-

Kontrola

monitoring

-

Kontrola

-

Dodávka projektu

-

Dodávka projektu

-

Vyhotovení Closing reportu

-

Předání do linie

-

Ověření projektových očekávání

-

Vyhotovení Closing reportu

-

Předání do linie

-

Ověření projektových očekávání

Follow-up

Ukončení

Zdroj: vlastní vyhotovení

3.1.1.2. Evidence a monitoring všech projektů Vedení evidence všech běţících, plánovaných i ukončených projektů není třeba sloţitě obhajovat. Přidaná hodnota je zejména ve schopnosti reprodukovat evidovaná data o projektech ve statistických ukazatelích a také moţnosti hledat mezi jednotlivými projekty různé synergie. Z jiţ ukončených projektů je navíc vhodné vyuţít závěrečné hodnocení, inspirovat se dobrými nápady a poučit se z provedených chyb. Monitorovací činnost jednotlivých projektů má prakticky stejný cíl jako monitorovací fáze kaţdého jednotlivého projektu, pouze PŘP je třeba nahradit plánem kontroly projektové metodiky. Tedy pravidelně a včas evidovat, zda je některý projekt v problémech v jakékoliv oblasti a mít moţnost včas zareagovat.

3.1.1.3. Zajištění prioritizace a plánování projektů Ţádná

společnost,

ani

Plavec

není

výjimkou,

nedisponuje

neomezenými

finančními prostředky a kapacitami na realizaci všech poţadovaných projektů. Kaţdý projekt má odlišný cíl a poţaduje jiný trojimperativ. Zároveň má pro organizaci jiný efekt (přínos). Proto je důleţité jednotlivé projekty postavit vedle sebe a prioritizovat. Jako rozhodovací kritéria se berou:

60

-

obchodní přínos 15;

-

mnoţství celkových kapacit v organizaci;

-

mnoţství celkových finančních zdrojů;

-

dopady mezi jednotlivými projekty;

-

vyšší zájem.

Kritéria jednotlivých projektů jsou mezi sebou porovnána a kaţdému je dána priorita, ze které vyplývá, jak je daný projekt pro organizaci vnímán. Uvádím jako důleţitý parametr také tzv. vyšší zájem, který je sice obtíţně měřitelný, avšak velmi důleţitý. Pod tímto označením najdeme např. projekt jako součást strategického plánu, legislativně nutné změny, případně projekt implementující vnitřní kontrolní mechanismy. Uvedené informace, zpracované v ucelené formě (vyuţíván opět např. Ganttův graf)

jsou

následně

předkládány

i

s

uvedenými prioritami

k rozhodnutí

odpovědným manaţerům. Tento schvalovací cyklus se opakuje 4x ročně, coţ je dostatečná doba pro schopnost reakce i případnou pečlivou přípravu návrhu projektového portfolia. Na základě rozhodnutí managementu nastává fáze plánování realizace schváleného projektového portfolia, coţ je jiţ v rukách PM za jednotlivé projekty.

3.1.1.4. Reporting o projektovém portfoliu představenstvu Představenstvo společnosti je odpovědné za projektové portfolio, jelikoţ o něm rozhoduje. Právě proto je v pravidelných čtvrtletních intervalech poskytován jeho členům aktuální stav portfolia a také výhled na seznam plánovaných p rojektů. Ucelené informace slouţí jako:

15

-

konsolidovaný přehled;

-

podklad pro rozhodnutí;

-

statistika vyuţití lidských zdrojů;

-

statistika vyuţití finanční zdrojů.

viz kapitola 1.5.3.1. Business case

61

3.2.

Praktická ukázka realizace projektu v Plavci

Jako praktickou ukázku realizace projektu představím implementaci řešení Klientských podnětů, který jsem projektově vedl od konce fáze Pre-study a také zodpovídal za funkčnost ve vyvíjeném systému. Projekt byl realizován po vypuknutí finanční krize, kdy byl kladen velký důraz na strukturovanou správu zpětné vazby klientů, konkrétně podnětů, stíţností a reklamací.

3.2.1. Zahájení projektu – Idea clarification O strukturované a centralizované evidenci klientských podnětů (dále jen „eKliP) se začalo přemýšlet koncem roku 2009, v návaznosti na strategickou aktivitu, která měla za cíl umět zpracovat a následně analyzovat klientskou zpětnou vazbu v celé finanční skupině.

3.2.1.1. Vstupy Okolnosti strategického rozhodnutí: 1. Plavec provedl vlastní analýzu existujících pouţívaných procesů se stíţnostmi, reklamacemi a další klientskou zpětnou vazbou za účelem poskytnutí ucelené informace o typech podání (reklamace, stíţnost, podnět) a také oblastech podání (chování pracovníků, produkty, sluţby, vybavení poboček…).

Bylo

zjištěno, ţe neexistuje jednotné centralizované řešení, strukturovaně pracující s údaji získanými od klientů. Proces sběru a vyhodnocování stíţností, reklamací je prováděno jednotlivými útvary nezávisle na sobě. Práce s klientskou zpětnou vazbou prakticky neexistuje. 2. Výše uvedené závěry byly porovnány se stejnými ukazateli konkurenčních firem v odvětví i mimo něj. Následná zjištění byla taková, ţe Plavec není v této oblasti konkurenceschopný, dokonce je mezi posledními ze všech zkoumaných společností. 3. Významná poradenská firma provedla detailní analýzu aktuálních trendů ve finančním odvětví v celé Evropě a porovnávala mezi sebou jednotlivé oblasti, zejména střední a západní Evropu. Výsledky této analýzy jasně hovořili o 62

kladení velkého důrazu právě na oblast spokojenosti a loajali ty klientů. A právě správa klientské zpětné vazby je jedním z nástrojů, které toto podporují.

3.2.1.2. Výstupy Popis záměru – záměr projektu byl v Idea clarification definován následně: -

Vybudování efektivního systému správy klientských podnětů, umoţňující: o zadání podnětu a jeho jednoduché procesování pracovníky; o systém automatizace interakce s klientem (notifikace); o strukturované vyuţití zadaných informací pro účely analýzy a vyhodnocování jednotlivých parametrů; o moţnost zabudování implementovaného řešení také v ostatních segmentech společnosti; o manaţerský i provozní report vyhodnocující proces zadaných podnětů;

-

vybudování dostatečné kompetence a pozitivního vnímaní pracovníků (nebát se zadat klientskou stíţnost);

-

úprava organizační struktury v zájmu poţadovaného řešení;

-

sjednotit standardy uţívané pro komunikaci směrem ke klientům ;

-

měření spokojenosti klientů s řešením jejich podnětu dle interní metodiky Plavce musí mít trvale stoupající trend.

V rámci záměru byly dále rozpracovány obecné principy, proces sběru podání a také definovány jednotlivé role v procesu.

63

3.2.1.3. Manažerské shrnutí Obrázek č. 14 – shrnutí fáze Idea clarification


3.2.2. Plánování projektu – Pre-study V rámci realizace pre-study projektu byl dále rozpracován záměr projektu, vydefinován přesný obsah a postup realizace, byl sestaven PŘP, provedlo se mapování ZaSt, proběhla definice rizik, tvořil se projektový tým. Výsledkem této fáze byla finalizace PCH, kde jsou mimo jiné popsány veškeré výše uvedené oblasti.

3.2.2.1. Prováděné aktivity

64

Popis aktuálního a požadovaného stavu Aktuální stav

Požadovaný stav


65

Obsah projektu – tabulka č. 10 Nr

Functional requirements

Priority High Medium Low

Project scope (Y/N)

F/001

Handling of filings - search and display existing entry including history and statuses

High

Y

F/002

Reopening of closed filing - escalation process

High

Y

F/003

New filing creation and possibility to collect data required by business for the filing

High

Y

F/004

Electronic documents as attachment support

High

Y

F/005

Registration confirmation and response for the client - pdf and mail automatically generating

High

Y

F/006

Make relation between filing and client existing in the system if available

High

Y

F/007

High

Y

High

Y

F/009

Support for anonymous filing and client not registered in the system Rules support for automatic workflow (filing owner group, filing owner, solver group, solver, high priority for the VIP clients in the system or high risky filing) Administration of roles and user groups

High

Y

F/010

Administration of statuses - user as administrator over basic user

High

Y

F/011

Connection with Tasks in the system - on the screen with tasks to propose one single place to see all tasks and filing opened on specific user 3 types of filing handling: 1. solving immediately and on my own 2. solving on my own as the owner 3. solving with support of solving group Email notification for defined user groups and solvers without access to the system

High

Y

High

Y

High

Y

F/014

Comments support for all users

High

Y

F/015

Reports - for branches and managerial reports

Low

N

Nr

Non-functional requirements

F/008

F/012

F/013

NF/001

Handling of 100 000 filings per year (1000ks/1GB)

Priority High Medium Low Medium

NF/002

Archiving of filings - 10 years for clients, 2 years for non-clients

High

Y

NF/003

Only one front end solution

High

Y

NF/004

SLA creation

Medium

Y

NF/005

Introduce the system to members of solving groups. Those departments aren’t using the system so far and therefore they will become new users.

High

Y


66

Project scope (Y/N) Y

Tvorba rozpočtu / alokace zdrojů – na základě definice poţadovaných procesů a obsahu projektu, byl stanoven a v jednotlivých odpovědných útvarech společnosti schválen rozpočet projektu. V rámci této aktivity se společně řeší i potřebné kapacity lidských zdrojů jak na straně BUS, tak i ICT, protoţe většina projektů je tvořena interně. V následující tabulce uvádím ilustrační hodnoty 16, jelikoţ se jedná o důvěrnou informaci. Tabulka č. 11 - plánované kapacity k realizaci projektu typ zdroje

potřebné jednotky zdrojů

ICT zdroje

500 jednotek

BUS zdroje

600 jednotek


Mapování ZaSt – stanovením výsledných procesů a definicí obsahu projektu následně vykrystalizovaly jednotlivé ZaSt, které projekt evidoval: -

klienti;

-

distribuční síť (dále jen „DS“);

-

řešitelské skupiny (dále jen „ŘS“);

-

kancelář Gen. ředitele (dále jen „kGŘ“);

-

interní audit (dále jen „IA“).

S jednotlivými ZaSt byla v další fázi projektu navázána spolupráce, jak znázorňuje následující obrázek.

16

Uváděné hodnoty potřebných zdrojů jsou skutečné, avšak upravené o parametr.

67

Obrázek č. 15 - váha spolupráce se ZaSt největší

kG Klienti

Ř

DS

Udržovat

Velmi

spokojené

pečlivě

ŘS

koordinova

Síla vlivu

t IA

Monitorovat

nejmenší

Informovat

Zájem

největší


Vytvořit projektový tým – definicí mnoţství kapacit, zmapování ZaSt a navrţeném obsahu projektu byl sestaven projektový tým, viz obrázek č. …. Jednotlivým členům projektového týmu byly přiděleny role, kterými měl jasně deklarován rozsah zapojení a odpovědnost při realizace projektu. Na základě očekávané náročnosti realizace byly s nadřízenými uvedených zástupců domluveny potřebné alokace. Následné řízení členů projektového týmu bylo jiţ plně v mé kompetenci.

68

Obrázek č. 16 - projektový tým

Projektový manažer Ondřej Čaněk

Dodavatel technického řešení

SPOC za klientské centrum

Procesní manažer za DS

Aplikační manažer Ondřej Čaněk

BUS vlastník / gestor

Hlas poboček + kontakt na kGŘ

Řešitelské skupiny

Projektový manažer ICT

ŘS produktů

Analytický tým ICT

ŘS za jednotlivé příčiny

Vývojový tým ICT

Eskalační místo

...

ICT

Řízení

Řízení

Řízení

provozu

procesů

projektů

klientského

Distribuční

Distribuční

centra

sítě

sítě

Péče o pobočky a klienty

Provozní podpora Distribuční sítě

Jednotlivé produktové továrny (cca 20 útvarů)


Řízení kvality – v Plavci je kvalita řízena podle tzv. V-modelu, který je znázorněn na obrázku níţe a je pro všechny typy smíšených projektů stejný. Smyslem je rozdělení do vývojové a implementační fáze. Ve vývojové fázi je moţno kdykoli kontrolovat stav poţadavků proti předchozímu kroku. V implementační fázi je moţno kontrolovat stejným způsobem, navíc také proti poţadavku umístěnému na stejném stupni předchozí větve. Následná správa tohoto modelu a jeho rozvoj je v gesci specializovaného útvaru společnosti, který tím zajišťuje řízení kvality dle principů TQM. Definice skutečného hodnotového měření je dána akceptačními kritérii, která jsou stanovena podle mnoţství existujících chyb, nahlášených v průběhu testování podle testovacích scénářů. Následná akceptace spuštění projektu se z obchodního pohledu stává administrativní formalitou.

69

Obrázek č. 17 - pouţívaný V-model

Zadání Business požadavků

Spuštění Business požadavků Podpora provozu, převod do produkční správy

Přijetí Business požadavků, oponentura

Vyhotovení Funkční dokumentace Revize a akceptace Funkční dokumentace

Realizace funkčních testů, akceptace do produkce Podpora end-to-end testů (oprava chyb, koordinace)

Příprava a akceptace testovacích scénářů Vyhotovení Technické dokumentace

Integrační testy dle testovacích scénářů Akceptace ICT testů dle akceptačních kritérií

Legenda: Příprava plánu testování, definice akceptačních kritérií Vývoj požadovaných řešení

Vývojové testy, ladění

Business aktivita

Kontrola a akceptace prototypů

ICT aktivita


Mapování rizik – tabulka níţe znázorňuje seznam rizik, která byla odhalena a zhodnocena. Výsledná hrozba kaţdého rizika se hodnotí další parametrizací síly dopadu a míry pravděpodobnosti, jak je obvyklé. Výši hrozby dále neuvádím, protoţe se jedná o interní metodiku posuzování společnosti. Tabulka č. 12 - definice rizik projektu eKliP Risk ID:

Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Open

Risk description:

Owner of the eKliP is not yet appointed, requirements’ consistency is endangered

Action: Risk ID:

Project sponsor will nominate the owner with high priority

Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Open

Risk description: Action: Risk ID:

Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Open


Business will not arrange alignment with the bank project “ECHO” covering complaints handling within the Group Business requestor of the project shall validate interim results of the prestudy with the global project on ongoing basis and make sure, that the business requirements that are handed over to ICT as input for the project are in alignment with the global project.

Business will be overloaded by other work and will not provide capacities for requirements explanation. Business will plan capacities for the support in advance.

Owner:

Impact:

Probability:

Status:

ICT

2 = Moderate

2 = M(edium)

Open

Risk description:

Integration environment will not be operational for testing.

Action:

ICT will do the best effort to prepare FET in time.

70

Risk ID:

Owner:

Impact:

Probability:

Status:

Business, ICT

3 = Severe

2 = M(edium)

Open

Risk description:

Project timing is built on the critical path, planned project delivery is very optimistic .

Action: Risk ID:

Business and ICT PM will closely monitor and react.

Owner:

Impact:

Probability:

Status:

ICT

3 = Severe

1 = L(ow)

Open

Risk description: Action:

Upgrade of Web Sphere is scheduled during summer 2010. It is possible that it can interfere with implementation of this project. ICT project team will follow up this activity and consult the status.


Definice PŘP – obsah PŘP byl vytvořen za účelem evidence důleţitých milníků, jak ilustruje Tabulka č. 13, ze které vyplývá mimo jiné termín dodávky do distribuční sítě na konci listopadu. Tabulka č. 13 - první verze PŘP pro projekt eKliP Week: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 MAY JUNE JULY AUGUST SEPTEMBER OCTOBER NOVEMBER DECEMBER Monday: 3 10 17 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30 6 13 20 27 4 11 18 25 1 8 15 22 29 6 13 20 27

2010

Complaints handling - Project phase Content ICT Project Kick-off BUS Project Kick-off BUS Management of Change workshop BUS workshops - workflow/process adjustment Solution introduction to Consumer finance LTCs definition

2 2 2

2 2

2 2

2

2

2

2 2

Project Management CPHL Steering Committeee GO/NO GO Business readiness CPHL Promotion plan

2

2

2

2

2

2

2

2

2

2

2 2

2

ACC Tests Pilot start 25/10/2010 (5w) Full park start 29/11/2010 - baby sitting 4w

2

2

2 2 2

2

2

2

2

2

2 2

ICT Development plan Analysis Development DEV/INT tests 20/8/2010 (6w) ACC tests 15/10/2010 (5w) ACC freeze (1w) Pilot start 25/10/2010 (5w) Full park start 29/11/2010 - baby sitting 4w

2

2

2

2

2

2

2

2

2

2

2 2

2

2

2

2

2

2

2

2 2

2

2

2

2

2

2

2

2 2

2 2

2

2 2 2

2

2

2

2 2 2

Legend

2

2

2

2

2 = Activity 2 = Output

Zdroj: vlastní zpracování v MS Excel

3.2.2.2. Výstupy Vyhotovení PCH – náleţitosti PCH se v metodice Plavce příliš neliší od popisovaných standardů v kapitole 1.5.3.2. Obecně shrnuto PCH v Plavci pro eKliP obsahuje: -

Pozadí změny (spojitost s celospolečenskými cíli); 71

-

Cíl změny;

-

Definice poţadavků a obsahu projektu;

-

Specifikace řídících činností o Řízení nákladů; o Řízení organizačního uspořádání; o Řízení času; o Řízení komunikace; o Řízení kvality; o Řízení rizik.

3.2.2.3. Manažerské shrnutí Obrázek č. 8 - shrnutí fáze Pre-study


72

3.2.3. Vlastní realizace a monitoring – work execution V této kapitole upřesním, kterým aktivitám jsem se musel nejvíce věnovat, s jakými jsem se setkal situacemi a zakončím strukturovaným výstupem. Primární cíl této fáze se týkal hlavně exekuce známých řídících činností Project management knowledge areas, konkrétně: -

scope management;

-

integration management;

-

quality management;

-

risk management;

-

human resources (HR) management;

-

cost management;

-

communication management;

-

time management.

3.2.3.1. Prováděné aktivity Nyní budu strukturovat jednotlivé detaily k uvedeným řídícím činnostem následujícím stylem: a. vstup (z předchozí fáze);

c. opatření;

b. realita;

d. výstup.

3.2.3.1.1.

Scope management

Vstup – obsah projektu, definovaný v PCH jsem uváděl v tabulce č. 10. Realita 1. jednotlivé poţadavky nebyly konzultovány a představeny klíčovým řešitelským skupinám, jelikoţ avizovali nedostatek kapacit (neodhalené riziko) => při představení řešení od ICT vznikl návrh na rozšíření obsahu projektu; 2. jednotlivé poţadavky nebyly dostatečně v detailu vyjasněny mezi BUS (jako zadavatelem) a ICT (jako dodavatelem) => při prototypování vznikaly návrhy na rozšíření obsahu projektu. 73

Vzhledem k povaze a prioritě změnových poţadavků bylo rozhodnuto o pokračování projektu s rozšířeným scope. Opatření -

-

ze zaregistrovaných změnových poţadavků byly vybrány nejprioritnější, které byly po schválení s dodavatelem zahrnuty do scope => dopad do cost a integration management; zbylé poţadavky budou implementovány po skončení projektu jako followup => dopad do cost a integration management.

Výstup – rozšíření scope projektu o poţadavky vedené v následující tabulce č. 14. Nr

Project change requests

1

System will determine Solution Group based on Cause, Product,

Priority High Medium Low High

Project scope (Y/N) Y

or their combination 2

Adding of new fields - sex, academic title before and behind

High

Y

High

Y

name of person placing the filing on behalf of corporate body or entrepreneur - non client. 3

Keeping the history of client filing, comments, statement, and solution on the filing detail.

4

Displaying of old and new value in history table

High

Y

5

Adding "Justified complaint" field on filing detail.

High

Y

6

Alert when opening a filing already opened by another user.

High

Y

7

Selects from directly from DB for BUS reports

High

Y

8

Replacement of problem (problém) to recording (záznam)

High

Y

9

Modification of headers on filing registration screens

High

Y

10

Multiple e-mails for solver group

High

Y

11

Possibility of "immediate solving" for multi problem filing

High

Y

12

Modification of the logic for "immediate solving" link

High

Y

13

Modification on access rights - possibility to manually assign the

High

Y

owner for escalated filings 14

Information "transaction is not finished"

High

Y

15

Support of direct routing of filing to a solving group based on

High

Y

combination of reason and product 16

Mass assign of owner for multi problem filings

High

Y

17

Replacement of label "priorita" to "lhůta"

High

Y

18

Support of "multibrand" departments

High

Y

19

Enhancement of selects from directly from DB for BUS reports

High

Y

Nr

Follow-up requirements

1

Hiding of attachments by Escalation point.

Priority High Medium Low Medium

74

Project scope (Y/N) N

2

Adding of account and credit card number fields on problem detail.

Medium

N

3

Reporting tool implementation

High

N


3.2.3.1.2.

Integration + quality management

Vstup 1. dle původního scope projektu byl navrţen ICT architektonický model a také milníky implementace (viz obrázek č. 13) dle uţívaného V-modelu; 2. vzhledem k nedostatku kapacit na ICT nebyli do projektu alokováni seniorní vývojáři. Realita Ad 1) scope se díky změnovým poţadavkům rozšířil, coţ mělo dopad na změnu architekturního schéma => prodlouţení dokončení ICT vývoje (dopad do cost , time a HR managementu); Ad 2) rychlost a kvalita ICT vývoje byly alokací juniorních vývojářů zhoršeny => funkční testování BUS začalo o 2 týdny později + odhaleno mnoho zaznamenaných funkčních chyb (dopad do cost, time a HR managementu); Opatření Tuto oblast je třeba rozdělit do dvou částí: -

-

dílčí opatření o dokončení vývojové fáze bylo v ICT posíleno o kontrolu seniorními vývojáři; o akcelerace BUS funkčního testování bylo docíleno nařízenou prací přesčas a o svátky. manaţerské opatření o PŘP se dostal za kritickou cestu, proto jsem společně s ICT PM předloţil v říjnu výkonnému výboru návrh na odsun spuštění projektu o 4 měsíce s ohledem na prodlouţení funkčního testování.

Výstup Členové výkonného výboru návrh na odsun schválili s nutnými změnami do oblastí time, cost a HR managementu, viz následující kapitoly.

75

3.2.3.1.3.

Risk management

Vstup – jednotlivá rizika jsou uvedena v tabulce č. 12. Realita- rizika, která byla zmapována ve fázi pre-study, byla pravidelně monitorována, ovšem v rámci realizace vznikla nová rizika (viz kapitoly scope a integration + quality management), která bylo nutno ošetřit. Opatření – Nová rizika současně s kombinací stávajících způsobila zmíněný odsun spuštění projektu v distribuční síti. Výstup – došlo k update rizik/statusů rizik, viz následující tabulka č. 15. Risk ID:

Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Closed

Risk description:

Owner of the eKliP is not yet appointed, requirements’ consistency is endangered

Action: Risk ID:

Project sponsor will nominate the owner with high priority

Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Closed


Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Closed


Business will not arrange alignment with the company project “ECHO” covering complaints handling within the Group Business requestor of the project shall validate interim results of the prestudy with the global project on ongoing basis and make sure, that the business requirements that are handed over to ICT as input for the project are in alignment with the global project.

Business will be overloaded by other work and will not provide capacities for requirements explanation. Business will plan capacities for the support in advance.

Owner:

Impact:

Probability:

Status:

ICT

2 = Moderate

2 = M(edium)

Closed

Risk description:

Integration environment will not be operational for testing.

Action: Risk ID:

ICT will do the best effort to prepare FET in time.

Owner:

Impact:

Probability:

Status:

Business, ICT

3 = Severe

2 = M(edium)

Closed

Risk description:

Project timing is built on the critical path, planned project delivery with high risk.

Action: Risk ID:

Business and ICT PM will closely monitor and react, if situation changes.

Owner:

Impact:

Probability:

Status:

ICT

3 = Severe

1 = L(ow)

Closed

Risk description: Action: Risk ID: New

Upgrade of Web Sphere is scheduled during summer 2010. It is possible that it can interfere with implementation of this project. ICT project team will follow up this activity and consult the status.

Owner:

Impact:

Probability:

Status:

Business

3 = Severe

2 = M(edium)

Closed

Risk description:

Not enough capacities for appointing of key solver groups within detail analysis clarification.

Action:

In case of new requirements asked, they will be treated as change requests.

76

Risk ID: New

Owner:

Impact:

Probability:

Status:

ICT

3 = Severe

2 = M(edium)

Closed

Risk description:

No senior ICT developers have not been appointed.

Action: Risk ID: New

Regular code reviewing to be executed by the nominated ICT developer.

Owner:

Impact:

Probability:

Status:

ICT, Business

3 = Severe

3 = B(ig)

Closed

Risk description:

Application cannot be accept by BUS according to the acceptance criteria.

Action: Risk ID: New

Project release is postponed by 4 months and time, cost and HR dependencies need to be solved .

Owner:

Impact:

Probability:

Status:

ICT, Business

3 =Severe

3 = B(ig)

Closed

Risk description:

Due to postponing of project delivery, M24x7 freeze will limit bug fixing in piloting.

Action:

Acceptation criteria will become harder; piloting without bug fixing; postponing of Full Park by 4 weeks.

Risk ID: New

Owner:

Impact:

Probability:

Status:

Business

2 = Moderate

2 = M(edium)

Open

Risk description:

Reporting tool is not in the project scope, BUS follow-up could be therefore limited.

Action:

Data scripts will be temporary sent to BUS by ICT (treated as CHRQ) and full reporting tool implementation need to be done by another project.


3.2.3.1.4.

HR + cost management

Vstup – původní odhad mnoţství potřebných zdrojů, potaţmo rozpočtu, je uveden v tabulce č. 11. Realita – na plánované mnoţství potřebných zdrojů (BUS i ICT) a rozpočet měly vliv především následující faktory: -

změnové poţadavky;

-

prodlouţení testování.

Opatření – došlo k potřebě navýšení rozpočtu projektu a nutnosti jednotlivé členy projektového týmu alokovat na prodlouţené testování => členové výkonného výboru ţádost o navýšení rozpočtu schválili a samotní resource manaţeři (liniově nadřízení) jednotlivých členů projektového týmu re-alokaci také potvrdili. Výstup – nové mnoţství potřebných zdrojů znázorňuje tabulka č. 16. typ zdroje

původní rozpočet

∆ (změna)

nový rozpočet

ICT zdroje

500 jednotek

175

675 jednotek

BUS zdroje

600 jednotek

210

810 jednotek


77

3.2.3.1.5.

Communication management

Vstup – v této oblasti řízení byly nutné zejména následující aktivity: -

ţádat o potřebná rozhodnutí u členů výkonného výboru; řídit očekávání všech ZaSt.

Realita – zmíněné aktivity byly exekuovány následovně: 1. standardní setkání členů výkonného výboru na měsíční bázi, kde docházelo k prezentaci stavu projektu a schvalování ţádostí; 2. pravidelná i nahodilá komunikace o progresu projektu, zaměřena na ZaSt, které byly identifikovány, jak značí obrázek č. 15. Opatření  za účelem jednotné komunikace o nutných obchodních aktivitách týkajících se projektu jsem vytvořil „BUS roll-out plán“, zobrazený níţe. Výstup – Obrázek č. 19 - BUS roll-out plán Category done done Pilot

Activity LTCs preparation Training approach for full park Defining of pilot branches

Communication Testing Trainig Trainig Trainig Trainig Trainig Instruction Instruction Instruction Project release Project release Instruction Trainig Trainig E-learning

Finalizing of Promotion plan Acceptance testing Training of solution groups Training of Call centre Training of pilot lead users Train the trainers (IT) for full park Training within pilot branches Communication to pilots User guides draft Handout draft

Instruction Communication Trainig Communication Project release Communication Communication Communication Activity after application deployment

Date from Due date 10.09.10 10.09.10 04.10.10 04.10.10 06.12.10 10.12.10

Responsible MLE OČA, MLE, ŠJI Area managers

17.12.10 31.01.11 14.01.11 14.01.11 11.02.11 16.02.11 18.02.11 18.02.11 18.02.11 18.02.11

KTO, MLE OČA, MLE OČA, ABA OČA, ABA OČA, ABA OČA, MLE pilot lead users OČA, MLE MLE, ABA MLE

13.09.10 03.01.11 10.01.11 07.02.11 16.02.11 14.02.11 14.02.11 14.02.11 14.02.11

Start of first piloting

21.02.11

Start of other pilots User guides finalization Training the area lead users Training within areas Roll out of e-learnings

28.02.11 01.03.11 07.03.11 07.03.11

28.02.11 04.03.11 10.03.11 11.03.11 11.03.11

MLE, ABA internal trainers area lead users OČA, MLE

Handout finalization a distribution Pod lupou (release of S-Cube) Training within branches Aktualita

07.03.11 07.03.11 14.03.11 21.03.11

11.03.11 14.03.11 18.03.11 23.03.11

MLE KTO branch lead users MLE

Full park Manager magazine First AMM status Final AMM presentation

Ensure follow up of the project

Communication Kompas Activity after application deployment External comunication

Commentary done definition done - see below pilot branches nomination (should be RET and SME branch / area) Finalisation of promotion plan - document will consists of: - way of presentation the project - external marketing materials - internal marketing and operational materials - training/e-learning definition retesting deployment of PBC14

1/2 - 1 day training meeting room booked content of release, instruction for piloting, hotmails… draft to be used and revised in pilot branches draft to be used and revised in pilot branches first pilot branch + Call centre

28.03.11 ??? MLE 12.-13.1. 2011 KTO 9.-10.2.11 KTO

continuously MLE March/April 2011 MLE

to 12/2011 KTO, MLE


78

prepared for publishing will be proceeded in each area for 3-4 representatives, SSFs involved DOME will be part of Pod lupou Possibilities of handout distribution: 1) give out at the training 2) for pilot branches 3) when you run the project - annex to the Kompas Unusual form as a competition with rewards/ Jakub Dobal presentation on the regular branch meeting + e-learning reminder

detect who receive the magazine and period of distribution general info presentation Promotion plan presentation * collecting feedback from the branches and provide the necessary information to branch staff * subsequent supervision of the functioning of the entire project Changes for distribution of Kompas are expected/ planned. about 3-6 months after FP - posters, leaflets (at the cash desk), statements, web pages, help links, etc

3.2.3.1.6.

Time management

Vstup – úvodní verze PŘP znázorněna v tabulce č. 13. Realita – okolnosti uváděné v předchozích kapitolách způsobily také posun v časování projektu, zobrazený následující tabulkou č. 16. Milestone / Deliverable

Original

Proposed

M 4 - ACC tests finished

15.10.2010

31.12.2010

M 5 - Pilot - start

25.10.2010

21.2.2011

M 6 - Pilot finished

26.11.2010

15.4.2011

M 7 - Full park

29.11.2010

18.4.2011

M 8 - Baby sitting finished

17.12.2010

29.4.2011

M 9 - Project evaluation and closing

23.12.2010

29.4.2011

End of the project

23.12.2010

29.4.2011


Opatření – došlo k úpravě PŘP. Výstup – tabulka č. 17 - aktualizovaný PŘP 2010/2011

Week: 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 SEPTEMBER OCTOBER NOVEMBER DECEMBER JANUARY FEBRUARY MARCH APRIL Monday: 6 13 20 27 4 11 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 31 7 14 21 28 7 14 21 28 4 11 18 25

Complaints handling - Project phase Content ICT Project Kick-off BUS Project Kick-off BUS Management of Change workshop BUS workshops - workflow/process adjustment Solution introduction to solution groups LTCs definition Project Management CPHL Steering Committeee GO/NO GO Business readiness CPHL Promotion plan ACC Tests Training of PF Pilot start 25/10/2010 (5w) Full park start 29/11/2010 - baby sitting 4w

ICT Development plan Analysis Development DEV/INT tests 20/8/2010 (6w) ACC tests 15/10/2010 (5w) ACC freeze (1w) Pilot start 25/10/2010 (5w) M24x7 freeze in ACC Full park start 29/11/2010 - baby sitting 4w Legend

= = = = =

Activity Output Delay Expected delay Freeze in ACC

Zdroj: vlastní zpracování v MS Excel

79

3.2.3.2. Manažerské shrnutí Obrázek č. 20 - shrnutí fáze Work execution


3.2.4. Follow-up projektu Po skončení projektu následovaly tyto aktivity: -

archivace projektu v projektové kanceláři;

-

převzetí dodávky vlastníkem.

3.2.4.1. Prováděné aktivity Rozdíl této fáze oproti předchozím je patrná v těchto oblastech: -

mnoţství lidských zdrojů – podílí se PM dokončením projektové administrativy a především vlastník, plně přebírající proj ektové výstupy;

-

časování – konec není stanoven, protoţe probíhá kontinuálně. 80

3.2.4.1.1.

Archivace projektu v projektové kanceláři

Tento krok představuje:  dokončení všech projektových prací;  schválení potřebných projektových dokumentů (včetně Project evaluation);  archivace projektového adresáře na DVD;  předání kompletní projektové sloţky do projektové kanceláře ;  vyhodnocení naplnění projektových očekávání. Účelem tohoto kroku je sběr strukturovaných informací o všech realizovaných projektech v Plavci jedním útvarem. Ten můţe na jejich základě poskytnout komplexní

obrázek

organizace,

případně

představenstvu nejčastější

společnosti,

problémy

a

ilustrující provést

silné

stránky

potřebnou

úpravu

v projektové metodice, jak jsem popisoval v kapitole 3.1.1.1. Za zmínku v této kapitole stojí část vyhodnocení projektu. Tabulka č. 18 - silné / slabé stránky projektu eKliP Slabé stránky

Silné stránky

nekompletní poţadavky v pre-study

řízení kvality – testů

opoţděná spolupráce s klíčovými ZaSt

organizace a řízení lidských zdrojů

neexistence vlastníka při startu projektu

naplnění očekávání projektu

nekompetentní tým ICT vývojářů

nastavení nové obchodní kultury v Plavci

pozdě dokončený ICT vývoj

spolupráce BUS / ICT

T2M (time to market)

předání projektu do linie řešení závislostí jiných projektů


81

Obrázek č. 21 - hodnocení projektu Project Evaluation Organisation al control 5 Deployment

Time control

4 3 2

Configuration mgt

Financial control

1 0

Information control

Method/Tools

Software quality control

Requirement s Scope

Legend: 0 = Bad / 1 = Insufficient / 2 = Moderate / 3 = Sufficient / 4 = Good / 5 = Excellent Zdroj: vlastní zpracování

3.2.4.1.2.

Převzetí dodávky vlastníkem

Ukončením fáze Work execution došlo sice formálně k převodu výstupů projektu vlastníkovi, nicméně důleţitější je z tohoto pohledu faktické přijetí vlastníka a zahájení správy a trvalého rozvoje dokončeného modulu. Mezi hlavní činnosti se řadí: -

sběr zpětné vazby od uţivatelů;

-

vyhodnocování a prioritizace jednotlivých námětů na zlepšení;

-

prosazování a zajišťování implementace nejdůleţitějších změn;

-

trvalé šíření osvěty mezi zainteresovanými stranami.

82

Mohu neskromně uvést, ţe tento bod se podařilo beze zbytku splnit. Vznik nového útvaru, starajícího se především o správu klientské zpětné vazby je toho jasným důkazem! Funkčnosti projektu eKliP jsou nadále rozvíjeny drobnými či komplexnějšími změnami, jak znázorňuje tabulka č. 19. Drobné úpravy

Komplexní plánované úpravy

notifikační zprávy vlastníkovi, řešiteli

eKliP přes web

úprava lhůt pro poskytnutí odpovědi

kontrola spokojenosti klientů s řešením podnětu

úprava kategorizační matice

zjištění počtu klientů: vyhrožujících odchodem / odešlých

rozšíření mnoţství řeš. skupin

využití eKliPu ostatními segmenty Plavce / dceřinými a sesterskými společnostmi


83

4. Předpokládané trendy projektového managementu V této

kapitole

se

budu

zamýšlet

nad

předpokládanými

trendy

vývoje

projektového managementu. Kromě běţných, plánem řízených, projektových metodik se začínají pozvolna rozšiřovat další, které na způsob vývoje produktu / sluţby hledí jiným úhlem pohledu. Zde vidím potenciál dalšího rozvoje projektového řízení v budoucnosti. Postupem doby a růstem komplexnosti a provázanosti nejrůznějších systémů očekávám také zvyšující se počet formy realizace dodávky prostřednictvím portfolia projektů neboli programy. Konstatování, ţe mnoţství účastníků společně s růstem počtu realizovaných projektů neustále přibývá, není překvapující. Proto se bude dle mého názoru úměrně zvyšovat vzdělávání projektových zákonitostí na nejrůznějších stupních školní výuky. Zároveň předpokládám růst účastníků a tím i trţeb těch organizací, které se zaměřují na certifikaci členů projektových týmů či samotných projektových/programových manaţerů.

4.1.

Uplatnění agilní metodiky

Vznik agilních metodik vývoje produktu nebo sluţby lze přisuzovat stále se zrychlujícímu tempu doby a poţadavkům na vyšší míru spokojenos ti zadavatele. Ţivotní cyklus vyuţívané, plánem řízené, projektové metodiky, svázané vyšší procesní sloţitostí a niţší mírou flexibility, přestává v některých případech plnit nové poţadavky zadavatelů. Pro svou argumentaci o budoucím rozvoji agilních metodik pouţiji její srovnání s metodikou řízenou plánem a uvedu její výhody i nevýhody.

4.1.1. Metodika řízená plánem Jako typického zástupce plánem řízeného ţivotního cyklu vývoje v projektu představím

tzv.

vodopádový

model.

Vodopád,

anglicky

„waterfall“

je

charakteristický sekvenčně seřazenými kroky, bez iterací. Mezi jednotlivými 84

kroky vţdy existuje schvalovací proces, který vývoj posunuje na další krok. Model znázorňující popisované schéma vidíte na následujícím obrázku. Obrázek č. 22 – ţivotní cyklus vodopádu aktivity Provoz a správa Testování

Implementace

Funkční design Obchodní požadavek čas Zdroj: vlastní zpracování

Tento model je v současnosti jedním z nejvyuţívanějších způsobů projektového řízení. Jeho silné stránky kladou důraz na kontrolu, monitoring a spolehlivost jednotlivých kroků a tím předpokládaný výstup ve vyšší kvalitě s menšími riziky. Jak je z obrázku patrné, lze mezi jednotlivými kroky přeskakovat směrem dopředu i dozadu, avšak pouze o jeden stupeň. To z něj dělá neefektivní model v situaci, kdy například v okamţiku implementace vznikne změnový poţadavek. Ten se dá realizovat buď návratem zpět na začátek, nebo dokončením všech kroků a novou realizací. Další nevýhodou je obtíţnější vytěţování jednotlivých zdrojů, jelikoţ kaţdý krok je realizován jiným projektovým týmem především na straně ICT. Specifikaci obchodního poţadavku vyjasňuje architekt, funkční design zpracovává analytik, implementaci zajišťuje vývojář, testy provádí tester a provoz podporují obvykle provozní útvary. Obecně je princip vodopádu hodnocen jako časově a komunikačně náročnější . Zadavatel bývá obvykle, vzhledem k délce implementace, odtrţen od skutečného vývoje svého poţadavku, proto finální výsledek nemusí hodnotit pozitivně.

85

Na druhou stranu je velmi často vyuţíván u komplexnějších typů projektu, kdy lze stěţí postupovat iterativně a je nutno koordinovat poţadavky více neţ jednoho zadavatele.

4.1.2. Agilní metodika Principem agilního vývoje je způsob implementace poţadavku s důrazem na jednoduchost, rychlost a spokojenost zadavatele. Hlavní změny proti standardní projektové metodice jsou následující: -

Jeden společný BUS / ICT tým, všichni členové jsou alokováni na 100 %;

-

rozsah projektu není zafixován, změny jsou libovolně moţné;

-

rychlejší dodávky, v menších velikostech;

-

existuje plná důvěra mezi BUS a ICT;

-

rychlá zpětná vazba.

Tento princip se zpočátku aplikoval především v ICT odvětví při vývoji jednoduţších softwarových programů, případně webových stránek. Poţadavky byly distribuovány jedním zadavatelem a daly se očekávat změnové poţadavky v průběhu vývojové etapy. Zároveň byla splněna důleţitá preference zadavatele, coţ byla rychlost dodávky. Mezi pouţívané agilní metodiky patří: -

extrémní programování;

-

lean development;

-

vývoj řízený vlastnostmi;

-

vývoj řízený testy;

-

scrum;

-

crystal metodiky.

-

adaptivní vývoj software;

V současné době se agilní metodiky rozšiřují také do ostatních průmyslových odvětví, stejně jako v počátcích projektů metodika řízená plánem. Pro ilustraci agilního ţivotního cyklu projektu uvádím obrázek č. 23 - Scrum.

86


4.1.3. Zhodnocení plánem řízených a agilních metodik V kapitole se budu věnovat porovnání zmíněných metodik a vyhodnocení jejich uţitků a dopadů pouţitou SWOT analýzou. Tabulka č. 20- SWOT analýza vodopádu a Scrumu Vodopád Výhody

Scrum

- trvanlivost řešení;

- moţnost změn;

- lepší řízení rizik;

- T2M;

- kvalitnější zpracování architektury;

- větší angaţovanost zákazníka;

- spolehlivost řešení;

- společný projektový tým;

- dostatek kontrolních mechanismů;

- 100 % pozornost na dodávku; - jednodušší a efektivnější řízení zdrojů; - rychlá zpětná vazba;

Nevýhody

- T2M;

- trvanlivost řešení;

- malá moţnost změn;

- horší koordinace závislostí;

- potřeba koordinace jednotlivých týmů;

- nekompetentní zákazník = nekompetentní

- více dokumentace;

dodávka;

- náročnější řízení zdrojů;

- méně kontrolních mechanismů;

- menší angaţovanost zákazníka; - zpětná vazba aţ na konci;

Příležitosti

- zapojení členů i do ostatních projektů;

- sdílení znalostí;

- vhodné jako část programů – portfolia

- vylepšení organizace jiţ v následujícím

87

projektů;

Hrozby

sprintu;

- vhodné pro komplexnější projekty;

- levnější pro jednodušší poţadavky;

- moţná nespokojenost zákazníka;

- neustálená architektura;

- změnový poţadavek můţe ohrozit

- plýtvání zdrojů na nekompetentních

dodávku projektu;

poţadavcích;

- HR zdroje nelze kombinovat se Agilní

- špatná zastupitelnost; - HR zdroje nelze kombinovat s metodikou

metodikou;

řízenou plánem; - nekompetentní členové způsobí fatální rizika; Zdroj: vlastní zpracování

4.1.4. Shrnutí Pohledem na výše uvedenou tabulku se domnívám, ţe realizace projektů formou agilní metodiky se bude neustále rozšiřovat. V dnešní době především rychlost reakce podstatně zvyšuje konkurenceschopnost kaţdé společnosti, proto budou dle mého názoru tento trend akceptovat i doposud konzervativní soukromé organizace. Úmyslně zmiňuji ty soukromé! Předpokládám, ţe veřejné organizace budou na tento trend reagovat se zpoţděním, protoţe konkurenceschopnost není primární oblast zájmu. Detailní uţití znázorňuji na následující tabulce č. 21. metodika řízená plánem

předpoklad využití - středně velké a velké komplexní projekty; - projekty s komplikovanou architekturou; - projekty realizované konzervativní organizací.

agilní

- malé projekty; - drobný vývoj; - projekty rozdělitelné na nezávislé části; - technické projekty v ICT organizacích; - incident management; - projekty s nejasným zadáním.


Z výše uvedeného vyplývá, ţe tradiční, plánem řízené metodiky budou ustupovat těm agilním zejména u poţadavků jednoduchých, izolovaných a specializovaných. 88

To by předpokládalo efektivnější vyuţití zdrojů, rychlejší T2M, větší spokojenos t zákazníka a v konečném důsledku i levnější realizaci. Na druhou stranu je třeba uvést, ţe plánování zdrojů v jedné organizaci pro obě odlišné metodiky je velmi obtíţné, neefektivní a prakticky nerealizovatelné. Metodika vodopádu vyuţívá v průběhu projektu nejrůznější zdroje, navíc částečně. Naproti tomu agilní metodiky vyţadují 100 % alokaci zdrojů po celou dobu konání projektu. Kombinaci obou metodik je proto moţné aplikovat pouze v situaci, kdy agilní nebude kanibalizovat veškeré zdroje, tedy vyuţitím pouze některých principů agilního přístupu!

4.2.

Uplatnění realizace formou programů

V předchozí kapitole jsem předpokládal vyuţití agilních metodik na úkor těch tradičních při realizaci jednoduchých a izolovaných projektů. Zároveň se ale domnívám, ţe mnoţství takových projektů bude do budoucna poměrně klesat a naopak se bude zvyšovat množství komplexnějších projektů, realizovány pod záštitou jednotlivých programů. Vycházím z toho, co jsem popisoval na úvod této práce. V důsledku globalizace a integrace jednotlivých odvětví vznikají logicky také poţadavky na jejich vzájemnou provázanost. Názorně lze uvést na příkladu významného dodavatele elektřiny, který začal nabízet svým zákazníkům také plyn. Společně s tím také poskytuje prodej atraktivních spotřebních produktů na bázi nejrůznějších kampaní. To zcela jistě generuje mnoţství poţadavků na integraci systémů společnosti k potřebné komplexní produktové nabídce pracovníkem oné společnosti. Stejná situace je i v odvětví finančnictví, jehoţ jsem si všímal v praktické části. Pro upřesnění uvádím definici programu: „Program je skupina příbuzných projektů koordinovaná tak, aby bylo dosaženo výhody oproti samostatně řízeným projektům. Program může obsahovat části, které by nebyly obsaženy v předmětu samostatných projektů. Projekt může nebo nemusí být součástí programu, zatímco program se vždy sestává z jednotlivých projektů.“ citace z [6]. 89

4.3.

Rozšiřování celospolečenské osvěty

V rámci předpokládaných trendů budoucího rozvoje projektového řízení očekávám změny také v přístupu k celospolečenské osvětě tohoto fenoménu. Důvody pro své tvrzení spatřuji v těchto faktorech: -

zvyšující se mnoţství projektů;

-

pronikání projektového řízení do různých odvětví;

-

rozšiřování nových trendů projektových metodik;

-

profilace projektově orientovaných organizací;

-

vyšší četnost komplexních poţadavků – globalizace, integrace;

-

poţadavky společností na projektové kompetence uchazeče o zaměstnání .

Dle mého názoru se trend rozšiřování znalostí projektových metodologií bude promítat především do růstu absolventů certifikačních kurzů společností, poskytující tyto sluţby. V dnešní době existují certifikační kurzy zaměřené na: projektové členy, manaţery rizik a projektové a programové manaţery. Poptávka po certifikaci bude podle mě taţena především rostoucím mnoţstvím projektově orientovaných společností, které budou poţadované znalosti očekávat od svých zaměstnanců. Dále se domnívám, ţe ve střednědobém horizontu se také rozšíří výuka projektově orientovaných předmětů do niţších stupňů škol, nejen těch technicky zaměřených směrů jako doposud. Především absolventi obchodních směrů se v současnosti běţně setkávají s projektovými principy ve svém zaměstnání. Své by v této popularizaci mohli kromě zaměstnavatelů sehrát také samotné certifikační společnosti, případně i „projektová lobby.“

90

Závěr Projektový management je implementace unikátního řešení realizovaného za přiděleného mnoţství zdrojů, v určitém čase. Tento způsob vývoje produktu nebo sluţby se tak stává důleţitou součástí dnešní doby. Společnosti z nejrůznějších odvětví jsou proto schopny dodávat na trh své výrobky rychleji a tím se stávají konkurenceschopnějšími. Ačkoliv existuje několik standardů, základní principy řízení projektů jsou stejné. Důleţitá je vţdy úspěšná dodávka cíle projektu za přidělený trojimperativ (čas, náklady a zdroje) a v potřebné kvalitě. Nezastupitelnou úlohu má v úspěšnosti projektu projektový manaţer, který je za dodávku poţadovaného cíle přímo odpovědný. Zajišťuje zdroje, plánuje provedení, řídí prováděné aktivity i členy týmu, informuje o stavu projektu a předkládá návrhy k rozhodnutí. Informoval jsem také o jednotlivých fázích ţivotního cyklu projektu. Stručně popsáno: při inicializaci vzniká myšlenka, plánování simuluje implementaci, poté samotná realizace zjišťuje relevantnost plánu a monitoruje postup prací. Nakonec se, po dodání projektového cíle, ukončují jednotlivé aktivity, zhodnocuje úspěšnost realizace a předává výsledek vlastníkovi. Všemi projektovými fázemi prostupuje sedm manaţerských oblastí, které jsem popsal, jejichţ důsledné řízení je podmínkou úspěšné realizace V praktické části představuji společnost Plavec a její principy koordinace, řízení a prioritizace projektového portfolia. Vzhledem k počtu otevřených projektů, dosahující ročně čísla 100, má útvar projektové kanceláře a jeho náplň práce nezastupitelnou úlohu. Následně ukázkou realizace projektu eKliP (evidence Klientských Podnětů) ilustruji reálné vyuţití představovaných technik, principů a procesů ve skutečnosti. eKliP byl budován v podmínkách neexistujícího řešení strukturovaného sběru klientské zpětné vazby, navíc s velmi ambiciózním časovým plánem, díky čemuţ se především ve fázi vlastní realizace postupně objevovala nová rizika, která svou kombinací způsobila odsun spuštění projektu a navýšení plánované ceny. Po následné úpravě plánu projektu, byla funkcionalita spuštěna včas a v poţadované kvalitě.

91

K akceptačním kritériím projektu patřilo: -

vybudování efektivního systému správy klientských podnětů;

-

vybudování dostatečné kompetence a pozitivního vnímaní pracovník ů (nebát se zadat klientskou stíţnost);

-

úprava organizační struktury v zájmu poţadovaného řešení;

-

sjednotit standardy uţívané pro komunikaci směrem ke klientům ;

-

implementované funkčnosti nesmí vykazovat kritické chyby.

Tato kritéria se podařilo splnit, navíc v podstatě pomohly vystavět pouţitelné základy pro postupné rozšiřování a další integraci modulu eKliP s ostatními systémy společnosti. Vzhledem k plánovanému rozšíření tohoto modulu do ostatních segmentů a dokonce dceřiných a sesterských společností, l ze proto povaţovat implementaci eKliPu za úspěšnou. V kapitole zabývající předpokládanými trendy jsem představil agilní metodiku vývoje, která by dle mého názoru měla postupně převzít místo tradičních metodik řízených plánem především u menších, jednodušších a nezávislých projektů. Zároveň se domnívám, ţe bude přibývat mnoţství realizovaných programů, coţ přisuzuji

trendu

budování

komplexního

portfolia

produktů

jednotlivých

společností za účelem zvyšování trţního podílu. Společně s tím předpokládám zároveň rozšiřování celospolečenské osvěty v oblastech projektového řízení. Závěrem této práce chci podotknout, ţe mě zvolené téma baví. Mé povolání projektového manaţera mě donutilo pohlédnout na toto téma z určitého odstupu a poskytlo mi důmyslnou zpětnou vazbu na hodnocení mnou realizovaného projektu. Alespoň tak vím, co budu příště dělat jinak!

92

Doporučení pro společnost Plavec Přestoţe je hodnocení projektu eKliP povaţováno za úspěšné, doporučuji Plavci věnovat v budoucnu při vzniku dalšího strategického projektu více energie mapování poţadavků i ostatních segmentů, případně dceřiných/sesterských společností. Mohl by se tak vyhnout současné situaci, kdy se zmíněné úseky chystají adoptovat existující řešení eKliPu a v některých případech to znamená masivní úpravy do architekturního schéma, coţ má za následek dopady do T2M, zdrojů i zvýšenou nutnost koordinace závislostí jednotlivých streamů. Realizace eKliPu pro všechny zainteresované strany by byl ideální kandidát na zpracování poţadavků pomocí programového řízení. Pokud by se k takovému rozhodnutí dospělo v počátku projektu v roce 2009, existovalo by nyní koncepční řešení pro všechny uţivatele a troufám si tvrdit, ţe dalším pozitivním efektem by byly niţší pořizovací náklady.

93

Seznam použité literatury [1]

DOLEŢAL Jan, MÁCHAL Pavel, LACKO Branislav a kol. Projektový management podle IPMA. Praha, Grada Publishing 2009, 507 s. ISBN 97880-247-2848-3.

[2]

STACKPOLE Cynthia A User's Manual to the PMBOK Guide. Hoboken (USA), Wiley 2010, 240 s. ISBN 978 0 470 58489 7.

[3]

Project management institut A guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition. Pennsylvania (USA), Project management institut 2008, 467 s. ISBN 978 1 933890 51 7.

[4]

HEDEMAN Bert, VAN HEEMST Gabor Vis, FREDRIKSZ Hans Project management based on PRINCE2, 3rd edition. Van Haren Publishing 2006, 252 s. ISBN 978 90 77212 837.

[5]

HEDEMAN Bert, SEEGERS Ron PRINCE2 2009 Edition – A Pocket Guide. Van Haren Publishing 2009, 181 s. ISBN 978 90 8753 544 5.

[6]

SVOZILOVÁ Alena Projektový management. Praha, Grada Publishing 2006, 356 s. ISBN 80-247-1501-5.

[7]

BUZAN Tony, BUZAN Barry The mind map book. Essex, BBC Active 2006, 277 s. ISBN 978-1-4066-1020-8.

[8]

ROSENAU Milton D. Řízení projektů. Brno, Computer Press 2007, 344 s. ISBN 978-80-251-1506-0.

[9]

SCHWABER Ken, BEEDLE Mike Agile Software Development with Scrum. Pearson Education International, 2008, 158 s. ISBN 978 0 132 07489 6.

Vyuţité informace z diplomové práce: [10] HAJDIN Tomáš Agilní metodiky vývoje software. Masarykova univerzita v Brně, fakulta Informatiky 2005. Odkazované internetové stránky: http://www.systemonline.cz/clanky/projektovy-management-strategie-na-prezitinebo-chimera-1-dil.htm www.ipma.cz www.pmi.cz www.prince2.com 94

Aplikace projektového managementu

Recommend Documents