Bankovní institut vysoká škola Praha Katedra Informatiky a kvantitativních metod
Projektové řízení v útvarech ICT Bakalářská práce
Autor:
David Štěpán Informační technologie
Vedoucí práce:
Praha
Ing. Václav Šebek, CSc.
duben, 2014
Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze dne
David Štěpán
Poděkování: Chtěl bych poděkovat panu Ing. Václavovi Šebkovi, CSc., vedoucímu bakalářské práce, za odborné vedení práce a cenné rady, které mi pomohly tuto práci zpracovat.
Anotace Tématem bakalářské práce je problematika projektového řízení v organizacích státní správy. Práce se zejména zaměřuje na plánování a závěrečnou fázi projektu. Podkladem pro práci je analýza konkrétního realizovaného projektu, uvedená pouţitá literatura a vlastní zkušenosti autora. Výsledkem práce je návrh realizace kroků, které by měly zajistit efektivnější řízení projektů a tím zvýšit úspěšnost realizovaných projektů.
Klíčová slova: projektové řízení, projekt, projektový tým, plánování projektu, řízení rizik, cíle projektu, organizační struktura
Annotation The topic of the bachelor’s thesis deals with project management in the sphere of state authorities. The thesis is focused mainly on planning and closing project phases. The work is based on particular project analysis, used quoted literature and author’s experience. The outcome of the thesis is the proposal of steps leading to more effective project management and thus ensuring successful project realization.
Key words: project management, project, the project team, project planning, risk management, project goals, organizational structure
Obsah Úvod ........................................................................................................................................................ 7 1.
2.
3.
4.
Základní pojmy řízení projektů ....................................................................................................... 7 1.1.
Úvod do projektového řízení ................................................................................................... 7
1.2.
Projekt ..................................................................................................................................... 9
1.3.
Ţivotní cyklus projektu ......................................................................................................... 10
1.3.1.
Předprojektová fáze ....................................................................................................... 10
1.3.2.
Projektová fáze .............................................................................................................. 11
1.3.3.
Poprojektová fáze .......................................................................................................... 11
1.4.
Projektové řízení ................................................................................................................... 11
1.5.
Techniky a nástroje projektového řízení ............................................................................... 13
1.6.
Metodiky pro projektové řízení ............................................................................................. 16
1.7.
Portfolio projektů a jeho řízení .............................................................................................. 18
1.8.
Řízení projektů v různých organizačních strukturách ........................................................... 18
1.9.
Projektové řízení a IT ............................................................................................................ 21
Specifičnost ICT projektů ve státní správě.................................................................................... 23 2.1.
Organizace státních podniků ................................................................................................. 24
2.2.
Lidské zdroje ......................................................................................................................... 24
2.3.
Financování ........................................................................................................................... 25
2.4.
Vstupní analýza ..................................................................................................................... 27
2.5.
Výběr zainteresovaných stran ............................................................................................... 28
2.6.
Absence některých činností při vedení projektu ................................................................... 29
2.7.
Souhrn specifik ...................................................................................................................... 30
Popis konkrétního projektu a jeho analýza.................................................................................... 31 3.1.
Popis a cíl projektu ................................................................................................................ 31
3.2.
Analýza potřeb a plánování projektu..................................................................................... 31
3.3.
Realizace projektu ................................................................................................................. 33
3.4.
Ukončení projektu a předání do provozu .............................................................................. 35
3.5.
Zhodnocení analyzovaného projektu..................................................................................... 36
Návrh optimálního řízení projektů ICT ve státní správě ............................................................... 37 4.1.
Propagace záměru projektu ................................................................................................... 37
4.2.
Zajištění podpory vedení ....................................................................................................... 39
4.3.
Důkladná analýza poţadavků ................................................................................................ 40
5
4.4.
Tvorba obchodního případu a důkladná analýza dopadů projektu ........................................ 42
4.5.
Zajištění kompetencí a organizační zabezpečení .................................................................. 43
4.6.
Plánování projektových zdrojů a řízení portfolia projektů .................................................... 45
4.7.
Průběţné sledování, vyhodnocování a řízení rizik projektu .................................................. 46
4.8.
Ukončení projektu a předání do provozu .............................................................................. 47
Závěrečné shrnutí .................................................................................................................................. 49 Pouţitá literatura ................................................................................................................................... 52 Seznam obrázků .................................................................................................................................... 52 Internetové zdroje.................................................................................................................................. 52 Pouţité SW nástroje .............................................................................................................................. 53
6
Úvod Cílem této práce je identifikovat problémy, které vznikají při realizaci ICT projektů v prostředí státní správy. Na základě tohoto zjištění se následně pokusit navrhnout řešení těchto problémů a navrhnout postup pro optimální řízení těchto projektů. Projektové řízení je poměrně mladá a velmi sloţitá věda. Spojuje dohromady řízení financí, lidí, dodavatelů a dalších zdrojů. Tato práce se snaţí postihnout ty nejzásadnější problémy, jejichţ včasným odhalením by se mohla úspěšnost a kvalita realizovaných projektů v prostředí státní správy zvýšit.
1. Základní pojmy řízení projektů 1.1.
Úvod do projektového řízení
Pojem „Projektové řízení“ je poměrně mladý, nicméně s jeho základní podstatou se setkáváme jiţ od nepaměti. Vezměme si například velkolepé stavby ve starověkém Egyptě. Při organizaci těchto staveb byl někdo, kdo řídil jak dodávky materiálu, tak i práci dělníků a dohlíţel také na celý průběh stavby. Takový člověk byl nejblíţe faraonovi a podával mu informace, jak stavba probíhá a případně i problémy, které při stavbě vznikaly. Toto bychom mohli hledat také v moderním pojetí řízení takovýchto staveb a nejen jich. V dnešní době je tato činnost nazývána projektovým řízením. Samotný pojem projektové řízení se začal formovat v 60. letech 20. století. Z počátku se projektové řízení provádělo na velkých a nákladných projektech. Teprve od 80. let 20. století se projektové řízení dostávalo postupně do běţné podnikatelské sféry i pro vedení menších projektů. Důvodem pro tak masivní rozšiřování řízení projektů byly zejména negativní zkušenosti s úspěšností v minulosti realizovaných projektů[2]. Tyto zkušenosti vedly k tomu, ţe projekty a jejich řízení jiţ nebyly brány na lehkou váhu a ze samotného projektového řízení se stala inţenýrská disciplína. Taktéţ i vedení společností začalo brát samotné řízení projektů a osobu projektového manaţera váţně[2]. Právě projektový manaţer a správné vedení
7
projektu můţe podnikům na jedné straně ušetřit nemalé peníze a na straně druhé pro změnu tyto peníze přinést. Projektové řízení se zabývá v podstatě plánováním. Plánují se činnosti, materiální a finanční zdroje a v neposlední řadě také lidé. Základem projektového řízení a tohoto plánování je tzv. projektový trojimperativ[1]. Tento trojimperativ zahrnuje čas, náklady a rozsah. Tyto tři veličiny musí projektový manaţer sladit tak, aby docílil úspěchu příslušného projektu. Někdy se ještě mluví také o čtvrté, neméně důleţité veličině, kvalitě. Kvalita v podstatě prochází všemi výše zmíněnými aspekty a také tyto aspekty významně ovlivňuje. Největším problémem v dnešní dynamické době je čas. Vzhledem k rychle se měnícím podmínkám je právě čas také nejproblematičtější veličinou kaţdého projektu. Projektový manaţer musí příslušný projekt dokončit ve stanovené lhůtě s přiděleným rozpočtem a v určeném rozsahu. Proto při plánování projektů je nutné umět počítat se všemi moţnými riziky a následně správně určit dobu a náklady realizace projektu. Tyto aspekty staví projektový management na úroveň vědecké disciplíny. Pro zajištění optimálního plánování bylo vytvořeno několik metodik, které se staly základem projektového řízení. Jednotlivé metodiky budou popsány dále.
Obrázek 1 - Projektový trojimperativ, zdroj: autor
8
1.2.
Projekt
Definic pojmu „projekt“ je mnoho. Jednoduše by se dal tento pojem definovat následovně: Projekt je souhrn činností, které vedou k nějakému jedinečnému cíli, produktu nebo sluţbě. Pro dosaţení tohoto cíle jsou k dispozici určité materiální, lidské a finanční zdroje a určitý čas. Na projektu spolupracuje tzv. projektový tým, coţ je skupina kooperujících lidí, kteří se svým úsilím snaţí naplnit cíle projektu. Projekt je neopakovatelný na rozdíl od procesu. Projekt mění stávající stav na nový. Projekt má povahu dočasných činností. Projekt můţeme charakterizovat pomocí následujících pěti atributů[2]: jedinečnost, komplexnost, vysoká míra nejistoty, vymezenost, tým.
Jedinečnost je vázána k cíli projektu. Tento cíl vypovídá o tom, jaký jedinečný výstup bude na konci projektu. Jedinečnost znamená také, ţe projekt není opakovatelný jako např. proces. To jej odlišuje od běţného provozu. Projekt jednou skončí a nebude moţné jej jiţ znovu opakovat. Neopakovatelnost je daná např. tím, ţe projekt, jak jiţ bylo uvedeno výše, mění nějaký stávající stav na nový. Důvodem rozhodnutí pro tuto změnu můţe být dosaţení konkurenční výhody oproti ostatním. Komplexnost je dána vyuţitím různých metod pro jeho řízení. Pro určitou část projektu se pouţije určitá metoda. Jednotlivé metody jsou určeny pro různé oblasti (IT, stavebnictví apod.). Vysoká míra nejistoty plyne z faktu, ţe se kaţdý projekt je originál a tudíţ neexistují ţádné předchozí zkušenosti nebo návody pro řízení příslušného projektu. Vše závisí na úspěšnosti či neúspěšnosti řízení projektu. Vymezenost je dána několika atributy. Projekt musí být proveden za určitou cenu, s určitými materiálními a lidskými zdroji a v neposlední řadě i za určitý čas. Nedodrţení některého z těchto aspektů můţe vést na neúměrné prodraţení a tím i neúspěch projektu. 9
Tým. Projekt je realizován projektovým týmem. Tento projektový tým realizující projekt vzniká na začátku projektu a při jeho ukončení zaniká. Projektový tým má tedy dočasnou povahu. Jak jiţ bylo zmíněno výše, základními aspekty projektu jsou čas, rozsah a náklady. Rozsah v sobě zahrnuje mj. cíle a kvalitu. V rámci projektu by měly být tyto tři aspekty udrţovány v rovnováze. Změna doby realizace (času) můţe vést na prodraţení projektu (náklady) nebo na sníţení jeho kvality (rozsahu). Podobně je tomu i u zbývajících dvou aspektů. Na druhou stranu zase musí být v rámci projektu vybrán ten správný aspekt tohoto trojimperativu v závislosti na konkrétní situaci, kterému bude dána vyšší priorita. Tento vyzvednutý aspekt logicky bude negativně ovlivňovat ty zbývající. Stručně shrnuto je realizace projektu v podstatě výsledkem kompromisů stanovených na základě určených priorit jednotlivých aspektů.
1.3.
Ţivotní cyklus projektu
Kaţdý projekt se rozděluje do určitých fází. Tyto fáze tvoří souhrnně tzv. ţivotní cyklus projektu. Jednotlivé fáze projektu jsou dle[2] rozděleny následovně: předprojektovou, projektovou, poprojektovou. Kaţdá fáze je závislá na té předcházející.
1.3.1. Předprojektová fáze V této fázi se nejprve identifikují potřeby, tvoří se obchodní případ a provádí se studie proveditelnosti. V rámci obchodního případu se vypočítávají přínosy a náklady, identifikují se náhradní řešení, hledají se optimální řešení a identifikují se rizika. Následně je vše prezentováno vedení organizace pro zajištění schválení. V případě schválení záměru se vytvoří plán projektu včetně plánu financí, času a zdrojů.
10
1.3.2. Projektová fáze V této fázi se samotný projekt realizuje podle schváleného plánu. Během celé realizace se provádí kontrola postupu prací se stanoveným plánem, řeší se případné problémy a volí se případné změny v realizaci projektu.
1.3.3. Poprojektová fáze V této fázi se provádí zhodnocení průběhu projektu, porovnávají se přínosy projektu, zda splnily očekávání a pokud ne tak se analyzuje, co bylo příčinou neúspěchu. Uzavírá se a archivuje se dokumentace projektu.
1.4.
Projektové řízení
Projektové řízení je soubor znalostí (komunikace, plánování, řízení), nástrojů (plánovací SW) a procesů (zahájení, plánování, realizace, kontrola, ukončení), které jsou potřebné pro úspěšné doručení produktů projektu[5]. Projektové řízení slouţí k řízení jednotlivých činností projektu ve všech jeho fázích ţivotního cyklu. Cílem projektového řízení je úspěšné dokončení projektu ve stanoveném čase, kvalitě a rozpočtu. Počátky moderního projektového řízení sahají do doby druhé světové války. Během této války vznikl a byl realizován projekt Manhattan, jehoţ výsledkem byla atomová bomba. Během realizace tohoto projektu si armáda uvědomila, ţe odborníci, kteří se podíleli na projektu, nejsou schopni tento projekt sami vést. Od tohoto okamţiku se řízení projektů chápalo jako určité umění, které vyţadovalo lidi se specifickými vlastnostmi pro řízení projektů[1]. Vzhledem k náročnosti jednotlivých projektů vznikaly v rámci těchto projektů projektové týmy. Tyto projektové týmy musel někdo vést, aby byly dosaţeny vytyčené cíle projektu. Vzniká nová role – projektový manažer. Osoba, která vykonávala tuto roli, musela nejen umět vést lidi, ale také plánovat. Následně musely být tyto plány kontrolovány a případně upravovány. Další schopností byla samotná komunikace s okolím. Toto jsou základní, ale ne jediné, dovednosti projektového manaţera.
11
Základní charakteristické znaky osobnosti projektového manaţera[2]: systémové myšlení, důvěryhodnost, autorita, proaktivnost, týmová spolupráce, odolnost proti stresu, ekonomický rozhled, organizační schopnosti, komunikativnost, umění řídit čas a lidi, schopnost vyjednávání, preciznost a pečlivost, optimismus.
Všichni, kdo se přímo či nepřímo realizace projektu účastní, jsou označováni jako zainteresované strany. Tyto zainteresované strany mají různé zájmy, protoţe se na projekt dívají ze svého pohledu. Je nutné brát během realizace projektu ohled na jejich potřeby a očekávání. Dále je pro úspěch projektu nezbytné udrţovat s těmito stranami stále dobré vztahy. Mezi zainteresované strany patří zejména sponzor projektu, zákazníci, uţivatelé, projektový tým a dodavatelé. Všichni tito účastníci se nějakým způsobem podílí na realizaci projektu nebo se jich realizace projektu nějakým způsobem můţe dotýkat. Sponzor projektu můţe také vystupovat jako zákazník. Je to hlavní osoba projektu, která má významný podíl a hlavní slovo při realizaci celého projektu. Stručně by se dalo shrnout, ţe je to ta osoba, která financuje celý projekt. Tato osoba, v případě potřeby vzniklé během realizace projektu, má hlavní slovo např. při schvalování poţadavků na změnu, které během realizace mohou vzniknout. Projektový tým a dodavatelé se přímo účastní samotné realizace projektu. Projektový tým je skupina lidí, kteří jsou zodpovědní za realizaci projektu. Projektový tým vzniká v okamţiku vzniku projektu formou nominace osob do jednotlivých rolí a zaniká v okamţiku ukončení celého projektu nebo části projektu, na které se podílí. V rámci jednoho projektu můţe být 12
nominováno i více týmů. Vše je závislé na velikosti rozsahu projektu. Dodavatelé na druhou stranu jsou ti, kteří odpovídají za zajištění materiálních a dalších zdrojů pro realizaci projektu. Uživatelé a zákazníci se samotné realizace projektu přímo neúčastní. Uţivatelé jsou osoby, které se realizace projektu nemusí aktivně účastnit, ale výsledek celého projektu je ovlivňuje. Mohou jimi být například zaměstnanci příslušného oddělení, kterého se výstup realizovaného projektu přímo nebo nepřímo dotýká. Příkladem mohou být zaměstnanci oddělení, kteří budou např. pouţívat nově vzniklou aplikaci. Zákazníci jsou zase ti, kteří si výstup z realizovaného projektu objednali. Můţe to být například oddělení, které si objednalo vytvoření nového informačního systému.
1.5.
Techniky a nástroje projektového řízení
Úspěch projektu závisí zejména na pečlivé přípravě. Tato příprava se provádí v předprojektové etapě projektu. V rámci této etapy se provádí příprava plánu realizace celého projektu. Pro vytvoření plánu existuje několik technik a nástrojů. Nejprve je nutné si uvědomit, co bude předmětem budoucího projektu. Předmět a rozsah projektu se stanoví zejména sběrem poţadavků a očekávaných výstupů projektu. Během tohoto sběru informací vytvoří projektový manaţer tzv. Statement of Work (SOW)[3]. SOW je v podstatě seznam, který zahrnuje zejména: identifikační údaje o projektu, stručný a výstiţný popis předmětu, charakteristika výsledků (výstupů) projektu, počáteční poţadavky na materiální, finanční a lidské zdroje, seznam kritérií, podle kterých se bude posuzovat úspěšnost projektu, prvotní soupis kritických bodů projektu.
Po vytvoření SOW se přistupuje k vytvoření hierarchické struktury prací – WBS (Work Breakdown Structure)[1]. Podstata WBS je dekompozice předmětu a rozsahu projektu na jednotlivé činnosti. Dekompozicí je projekt rozdělen na dílčí samostatné celky. Tyto celky představují podrobnější plán včetně časového plánu realizace celého projektu. Toto rozdělení 13
slouţí pro určení milníků projektu, na základě kterých se následně sleduje průběh realizace celého projektu. Tyto milníky slouţí v podstatě k rozdělení celého projektu na dílčí etapy. V rámci tohoto rozdělení jsou právě milníky dílčí cíle, které jsou monitorovány a kontrolovány a slouţí pro sestavení harmonogramu a rozpočtu projektu a jako podklady pro dílčí akceptaci projektu. Milníky jsou klíčovou součástí plánování a realizace celého projektu.
Tabulka 1 – Plán projektu (WBS) – příklad, zdroj: [3], úprava: autor
Označení úkolu
Milník – název úkolu
Trvání v týdnech Stručný popis úkolu
U01
Definice poţadavků
8
U02
Návrh řešení IS
10
U03
Implementace IS
16
Analýza a podrobná definice předmětu projektu Návrh řešení a příprava testů IS ve spolupráci s dodavatelem a uţivateli Instalace IS do testovacího prostředí a napojení na okolní systémy
Na základě WBS se vytvoří časový harmonogram realizace projektu. Tento harmonogram je zakreslen do tzv. Ganttova diagramu. Tento diagram vyvinul jiţ v roce 1917 Henry Gantt jako nástroj řízení práce v továrnách[1] a tvoří jádro všech nástrojů určených pro projektové řízení. Diagram popisuje jednotlivé činnosti (aktivity) projektu spolu s vyznačením okamţiků jejich zahájení a ukončení. Jednotlivé aktivity mohou na sebe navazovat nebo být zahájeny současně. V dnešní době je tento diagram součástí harmonogramu projektu.
14
Obrázek 2 - Ganttův diagram - příklad, zdroj: autor[SW_1]
Další technikou, která byla vyvinuta v padesátých a šedesátých letech 20. století, je síťová analýza. Výstupem z této analýzy jsou síťové grafy. Tyto grafy pomáhají znázornit závislosti jednotlivých aktivit v průběhu projektu. Z těchto grafů mnohou manaţeři projektů snadněji určit klíčové a rizikové okamţiky celého průběhu realizace projektu. Pomocí těchto grafů je moţné provést kontrolu jednotlivých aktivit a případně jejich sled ještě upravit tak, aby byly všechny aktivity prováděny co nejefektivněji z hlediska času.
Ze síťové analýzy se stanovuje tzv. kritická cesta. Pro určení této cesty se pouţívá metoda kritické cesty. Metoda vznikla v padesátých letech v době studené války, kdy a v podstatě dodnes je, byl nejdůleţitější čas[2]. Čím rychleji dokázal příslušný stát vyvinout a pouţít novou zbraň, tím více se blíţil k tomu, ţe se mohl stát vedoucí mocností. Tato metoda pomáhá určit nejdelší moţnou cestu k dokončení projektu z hlediska času. Pomocí kritické cesty je moţné stanovit rizikové aktivity, které by mohly zásadně ovlivnit realizaci celého projektu. Na základě této analýzy je pak moţné věnovat těmto aktivitám zvýšenou pozornost a následně včas reagovat v případě formujících se problémů během realizace projektu. Kritická cesta projektu souvisí s časovým harmonogramem projektu. Díky této cestě lze určit nejdelší dobu trvání celého projektu[1].
15
Obrázek 3 - Síťový graf s vyznačením kritické cesty - příklad, zdroj: [INT_1]
Další pouţívanou technikou pro vytvoření časového plánu je metoda PERT[2]. Tato metoda vznikla v šedesátých letech a zobecňuje metodu kritické cesty. Spolu s metodou kritické cesty jsou standardem projektového řízení. Metoda PERT je zaloţena na statistických výpočtech prováděných v rámci plánování velkých projektů. Během let, kdy se projektové řízení formovalo, vznikala také potřeba na vytvoření sw nástroje pro řízení projektů. Pro řízení projektů se dají vyuţít aplikace kancelářských balíků nebo přímo specifické nástroje určené pro tuto oblast řízení. Nejznámějším představitelem komerčních nástrojů v oblasti specifických aplikací je bezesporu produkt Microsoft Project. Tato aplikace pokrývá potřebné nástroje pro řízení projektů jakékoliv velikosti. Představitelem volně dostupných nástrojů je aplikace OpenProj, která vznikla jako komunitní produkt pod licencí open-source. Tento nástroj sice nedosahuje kvality výše zmiňovaného komerčního sw, ale je pouţitelný pro řízení malých aţ středně velkých projektů.
1.6.
Metodiky pro projektové řízení
S postupným vývojem a formováním projektového řízení vznikala různá sdruţení projektových manaţerů. Tato sdruţení vytvářela a vytváří různé standardy a metodiky pro řízení projektů. Dále umoţňují certifikaci osob na různých úrovních. První sdruţení bylo zaloţeno v roce 1965 a jmenuje se IPMA – International Project Management Association. V podstatě se jedná o neziskovou organizaci, která sdruţuje další
16
asociace projektového řízení. Cílem organizace je podporovat projektové řízení ve firmách a organizacích. V rámci této asociace vznikl standard IPMA Competence Baseline. Podle tohoto standardu nabízí asociace čtyři stupně certifikace. Na základě těchto stupňů je certifikovaná osoba schopna od aplikace znalostí projektového řízení jako člen projektového týmu (nejniţší stupeň D) aţ po samostatné řízení významných projektů (nejvyšší stupeň A)[2].
Druhou nejznámější metodikou je metodika PMBOK Guide – Project Management Body Of Knowledge Guide. Tuto metodiku vyvinula nezisková organizace PMI - Project Management Institute. Tato metodika je souborem nejlepších praktik z oblasti řízení projektů a byla vyvinuta převáţně pro pouţití v USA. Metodika obsahuje definované procesy pro jednotlivé etapy ţivotního cyklu projektu[INT_2]. Organizace PMI nabízí moţnost certifikace projektových manaţerů postavené na této metodice. Tato certifikace má celkem pět úrovní. Nejniţší úroveň zahrnuje základní znalosti v oblasti projektového řízení. Nejvyšší úroveň naopak pokrývá schopnost samostatného řízení projektů a odpovědnost za něj.
Třetí metodikou, která je velmi známá, je metodika PRINCE2 – Projects in Controlled Environment. Tato metodika je nejrozšířenější metodikou pro projektové řízení v Evropě. Tvůrcem metodiky je sdruţení OGC (Office Government Commerce). Tato metodika vznikla z britského poţadavku na standardizaci řízení projektů ve státní správě. Metodika popisuje potupy pro efektivní řízení projektů a je procesně orientovaná. Metodika je volně dostupná a postupy v ní popsané je moţné uplatnit v různém odvětví. Certifikace dle této metodiky má dva stupně. První stupeň PRINCE2 Foundation pojednává o základní znalosti pojmů z oblasti řízení projektů. Druhý stupeň PRINCE2 Practitioner poskytuje certifikované osobě praktické zkušenosti v řízení projektů[INT_3].
Pro řízení projektů byla ještě vydána norma ISO 10006. Tato norma se spíše zabývá výčtem ověřených praktik pro řízení projektů neţ na kompletní strategii jako je tomu u PRINCE2 a PMBOK. Zabývá se spíše managementem kvality projektů.
17
1.7.
Portfolio projektů a jeho řízení
V podniku se během jeho existence realizuje několik projektů. Některé projekty mohou být realizovány souběţně a také tomu tak v praxi bývá nejčastěji. Projektů, které se realizují souběţně, můţou být desítky, ale projektových manaţerů je pouze omezené mnoţství. Můţe se tak stát, ţe jeden projektový manaţer můţe řídit současně několik projektů najednou. Aby toto řízení bylo efektivní a aby byly omezené zdroje podniku určené pro realizaci projektů vyuţity efektivně a hospodárně, je potřeba nějakým způsobem toto řídit. Z tohoto důvodu vzniká portfolio projektů a programů. Některé projekty jsou spolu vzájemně provázány nebo na sebe například časově navazují. Tyto související projekty jsou zahrnuty do programu. Sloučení několika souvisejících projektů do jednoho celku a následně řízení tohoto celku má své výhody. Zejména to jsou výhody efektivnějšího řízení, finanční úspory a v neposlední řadě i řízení lidských zdrojů. Programy jsou zahrnuty spolu s projekty do portfolia projektů a programů. Do portfolia projektů a programů jsou projekty a programy zahrnovány na základě rozhodnutí vedení podniku. Toto portfolio je průběţně aktualizováno a kontrolováno. Pro řízení portfolia vznikla role manažer portfolia projektů. Tito manaţeři pomáhají vedení analyzovat a vybírat ty správné projekty z hlediska jejich přínosu do budoucna. Z tohoto důvodu musí mít tito manaţeři analytické schopnosti a finanční znalosti, aby mohli pomoci vedení podniku plnit vytyčené strategické cíle. Manaţeři portfolia projektů se zaměřují zejména na dlouhodobější strategické cíle. Naopak projektoví manaţeři se zaměřují na krátkodobější taktické cíle.
1.8.
Řízení projektů v různých organizačních strukturách
Pro úspěšné řízení projektů je důleţité pro projektového manaţera znát organizační strukturu podniku. Tato znalost je důleţitá zejména z důvodu zvolení správné komunikační strategie. Projektový tým bývá převáţně sestaven ze zaměstnanců z různých oddělení podniku a je nutné vědět, jaký způsob vyjednávání s nadřízenými členů projektového týmu zvolit.
V současné době jsou nejznámější základní tři typy organizačních struktur. Podnikatelská organizační struktura je velmi hrubě zaloţena na odpovědnosti a povinnostech jednotlivých 18
zaměstnanců. V podstatě by se dalo říci, ţe „všichni dělají všechno“ dle potřeby. S touto strukturou se můţeme setkat zejména u malých a rodinných podniků.
Hierarchická (funkční) organizační struktura je zaloţena zejména na povinnostech, odpovědnosti a náplni práce jednotlivých zaměstnanců. Kaţdý zaměstnanec má svého přímého nadřízeného. Výjimku tvoří nejvyšší vedení, které je zodpovědné akcionářům, majitelům nebo nadřízeným orgánům (státní práva). Tento typ organizační struktury je v našich zeměpisných šířkách nejčastější. Je uplatňován zejména u středních a velkých podniků a ve státní správě. Příklad takové struktury je uveden na obrázku číslo 4.
Obrázek 4 - Hierarchická struktura - příklad, zdroj: autor[SW_2]
19
Ad-hoc organizační struktura je zaloţena na okamţitém poţadavku splnění konkrétního úkolu nebo cíle a má omezené trvání.
Pro potřeby projektového řízení je nejvhodnější maticová organizační struktura. Maticová struktura je zaloţena na chápání řízení zaměstnanců ze dvou úrovní – z úrovně řízení vyplývající z funkční struktury a úrovni řízení vyplývající ze struktury řízení projektu. Členové projektového týmu mají v jeden okamţik dvě nadřízené osoby. Tento stav má statut dočasného charakteru do doby, neţ je projekt ukončen. Aby princip a myšlenky této organizační struktury mohl fungovat, je nutné, aby projektový manaţer disponoval příslušnými kompetencemi a zejména plnou podporou vedení podniku. Výhody tohoto pojetí řízení jsou viditelné – projektový manaţer můţe v případě potřeby přímo úkolovat konkrétního člena týmu a tím výrazně ušetří čas a síly, které by musel vynaloţit při zadávání úkolů prostřednictvím přímého nadřízeného příslušného člena projektového týmu. Tato struktura má ale také své nevýhody. Tou největší nevýhodou je moţný vznik situace, kdy člen projektového týmu obdrţí v rámci projektu úkol s jasným termínem jeho splnění a ve stejný okamţik můţe dostat úkol od svého nadřízeného v rámci funkční struktury. V tuto chvíli je člen týmu v jakési pasti a neví, kterému úkolu má dát přednost, protoţe oba zadavatelé úkolu jej například chtějí mít vyřešený co nejdříve nebo do stejného data. Na tomto místě by měl zakročit projektový manaţer a domluvit se s funkčním nadřízeným člena týmu o stanovení priorit zadaných úkolů. Někdy ale tato komunikace můţe být zdlouhavá a plná dohadů či hádek. V tomto případě by mělo následně zasáhnout vedení podniku co nejdříve, aby nedocházelo ke zbytečnému prodluţování projektu. Toto je jeden z důvodů, proč by měl projektový manaţer znát nejen členy svého projektového týmu, ale také jejich nadřízené pracovníky. Na základě těchto znalostí by měl následně zvolit tu „správnou“ komunikační strategii. Maticovou organizační strukturu lze vyuţít i v případě řízení více projektů najednou.
20
Obrázek 5 - Maticová struktura - příklad, zdroj: autor[SW_2]
Specifickým typem struktury je projektová organizační struktura[1]. Tato struktura je zaloţena na hierarchické struktuře s tím rozdílem, ţe řediteli podniku jsou podřízeni jednotliví programoví manaţeři. Ti pak jsou nadřízenými jednotlivým zaměstnancům, kteří mají specifické dovednosti, které uplatňují při realizaci jednotlivých projektů v rámci jednotlivých programů. S touto strukturou se můţeme setkat zejména u podniků zabývajícími se hlavně projektovým řízením dodávaným jako sluţby zákazníkovi.
1.9.
Projektové řízení a IT
ICT projekty mají oproti projektům z jiné sféry jednu velkou zvláštnost. Výstupy z těchto projektů jsou většinou nehmotné povahy. Z tohoto důvodu přináší řízení těchto projektů mnohé problémy a spory. Pro řízení projektů je důleţité brát v potaz nejen dotčené části organizace, ale organizaci jako celek. Většina projektů se totiţ dotýká celé organizace a ne pouze některých oddělení. Projekty mění způsoby práce všech zaměstnanců organizace. Z tohoto důvodu by se mělo k projektovému řízení přistupovat systémově. Tento přístup
21
spočívá v tom, ţe je potřeba se na projekt dívat komplexně. Komplexní pohled můţeme zajistit analýzou, která je prováděna ze všech moţných pohledů a ne pouze jen z jednoho. Tato analýza zajistí nejen identifikaci rozsahu projektu, ale také správnou následnou dekompozici na jednotlivé části projektu. Tento přístup je klíčový pro řízení projektů, protoţe jedině tímto přístupem je moţné zajistit správný výběr zainteresovaných stran, kterých se příslušný projekt bude přímo dotýkat. Tento přístup je také nazýván jako systémové řízení projektů[1]. Systémové řízení bere v úvahu tři druhy aspektů: technologické, obchodní a organizační[1]. Tyto aspekty mají nezanedbatelný vliv na průběh celého projektu. Jak jiţ bylo uvedeno výše, tak projekty se většinou dotýkají celé organizace. Toto zvláště platí u IT projektů. IT projekty jsou většinou různorodé. Některé IT projekty se mohou týkat pouze omezené části nebo skupiny zaměstnanců organizace, jako příklad můţe být pouţit projekt instalace nového počítačového vybavení. Jsou však projekty, a těch je převáţná většina, které ovlivňují chod celé organizace. Jako příklad můţe být uveden vývoj jakékoliv nové aplikace pro podporu a dosaţení podnikových cílů. IT projekty by se daly rozdělit na projekty hardwarové a softwarové[1]. Pro řízení takovýchto projektů je vyţadována různá úroveň znalostí projektového manaţera a celého projektového týmu. Kaţdý projekt si ţádá své a u IT projektů toto platí dvojnásob. Toto je ovlivněno zejména dnešním dynamickým rozvojem technologií a postupů v oblasti IT. Stručně by se to dalo shrnout tak, ţe to co bylo optimální před rokem, není optimální dnes nebo se to jako optimální dnes nemusí jevit. Nejvíc je toto vidět u technologií, jejichţ vývoj je v dnešní době značně dynamický. Proto je základním předpokladem pro úspěšné řízení projektů v oblasti IT neustálé zdokonalování, rozvoj a aplikace nových znalostí a postupů v projektovém řízení. Jedině tak lze úspěšně naplánovat, realizovat a ukončovat IT projekty. Dalším specifikem IT projektů jsou samotní lidé. Lidé mají různé znalosti v oblasti IT technologií, coţ ovlivňuje i samotné projekty. Tento vliv můţe být jak pozitivní, tak také negativní. Jedním z pozitivních přínosů této různorodosti je získání pohledu na věc i ze strany lidí, kteří nedisponují znalostmi v oblasti informačních technologií. Tento pohled můţe přinést projektu také i negativní vliv. Úkolem projektového manaţera je brát v potaz nejen pozitiva, ale také i tato negativa. V rámci projektu mohou lidé (členové projektového týmu) zastávat více profesí nebo mohou být pouze specializovaní v určité oblasti. Specializace těchto lidí můţe být například v oblasti databází, sítí, hardwaru, bezpečnosti, programování (Java, C++, atd.), kvality a analýzy. 22
V rámci realizace projektu pak můţe docházet ke komunikačním problémům z důvodu právě této specializovanosti jednotlivých členů týmu. Je opět na projektovém manaţerovi zvolit správný jazyk a styl komunikace s těmito specialisty. Na IT projekty, jak jiţ bylo uvedeno výše, má velký vliv různorodost vyuţívané technologie. Tato různorodost stěţuje práci projektovým manaţerům při sestavování a vedení projektových týmů. Technologie se velmi dynamicky rozvíjejí a tento fakt stěţuje při plánování projektů výběr technologie, která bude pouţita. Posledním aspektem, který má nezanedbatelný vliv na řízení projektů v IT, jsou samotné trendy dnešní doby. Zejména se jedná o globalizaci, outsourcing a vyuţívání virtuálních týmů[1]. Tyto trendy zajišťují vyšší flexibilitu v řízení a realizaci projektů, ale přináší také s sebou nové problémy. Jedním z těchto problémů je samotná komunikace mezi jednotlivými členy projektového týmu. Pro komunikaci jsou sice vyuţívány nejmodernější prostředky ve formě telekonferencí, videokonferencí a chatovacích nástrojů, ale na druhou stranu mohou být členy takového týmu lidé z různých koutů světa. To nese s sebou zvyšující se nároky na vlastnosti projektového manaţera. Tito lidé pochází ze zemí různých kultur a zvyklostí a s tímto faktem musí projektový manaţer počítat a dle toho volit správné komunikační metody a praktiky.
2. Specifičnost ICT projektů ve státní správě ICT projekty v prostředí státní správy se realizují obdobně, jako je tomu v komerční sféře. Bohuţel v průběhu realizace těchto projektů v tomto prostředí se vyskytují určité překáţky či specifika, které jsou způsobeny charakterem a povahou podniků a organizací řízených státem. V prostředí státní správy se pohybuji jiţ 5 let. Během této doby jsem se účastnil některých projektů jako člen projektového týmu nebo jako nadřízený pracovníků oddělení IT, kteří byli členy projektových týmů. Projekty, kterých jsem se účastnil, byly v rámci organizace zejména globálního charakteru. Z těchto mých účastí na projektech jsem posbíral nemálo zkušeností a na základě těchto zkušeností dále popíšu jistá specifika a slabiny tohoto prostředí v souvislosti s vedením projektů.
23
2.1.
Organizace státních podniků
Organizace státních institucí a podniků je postavena na hierarchickém modelu. Jak bylo uvedeno výše, tento model organizační struktury je nejméně vhodným pro řízení projektů. V důsledku podstaty tohoto modelu organizace vznikají pro řízení projektů mnohdy těţko překonatelné bariéry. Tyto bariéry jsou navíc podpořeny celkovou nepruţnou reakcí státní správy jako celku na změny, které jsou v dnešní turbulentní době velmi dynamické. Tato nepruţnost je ještě navíc umocněna i jistou mírou rezistence samotných lidí pracujících v této sféře. Tyto charakteristické vlastnosti státních organizací vedou ve vztahu k projektovému řízení zejména k opakovanému nedodrţování termínů realizace projektů nebo v horším případě k předčasnému ukončení nedokončených projektů. Další příčinou výše zmíněných problémů při řízení projektů můţe být i samotné umístění projektových manaţerů. Projektový manaţer, protoţe zodpovídá za celý projekt, nutně potřebuje v rámci řízení projektů disponovat určitými kompetencemi. Při nevhodném umístění v organizační struktuře nemusí tyto kompetence mít, coţ má za následek vzniku mnoha převáţně zbytečných konfliktů. Řešením těchto konfliktů se neúměrně prodluţuje doba realizace celého projektu.
2.2.
Lidské zdroje
V souvislosti s realizací projektů se poměrně dost často zapomíná na plánování lidských zdrojů pro projekty. Vedení organizace poţaduje a následně schválí realizaci několika projektů současně. V rámci „jakéhosi“ plánování projektů, jsou pak zaměstnanci jednotlivých oddělení nominováni do několika projektových týmů. Vzhledem k tomu, ţe se nikdo v přípravné fázi a fázi schvalování projektů nezabývá otázkou potřebných poţadavků na lidské zdroje pro dané projekty, se teprve aţ při samotné realizaci zjistí, ţe někteří zaměstnanci pracují na několika projektech současně a v podstatě tuto práci nestíhají. Toto má za následek nejen prodluţování doby realizace celého projektu nebo projektů, ale také tímto tzv. „sezením pracovníka na několika ţidlích“ dochází ke sniţování kvality odvedené práce a tím i kvality výstupů z celého projektu. Příčin nedostatečného nebo dokonce chybějícího plánování poţadavků na lidské zdroje můţe být hned několik. Jedním z důvodů můţe být jiţ zmiňovaná absence informací na potřebné 24
zdroje. Zaţil jsem však i situace, kdy tyto informace byly k dispozici, nicméně si vedení stálo za svým a poţadovalo realizaci několika projektů současně za kaţdou cenu. Toto rozhodnutí následně vedlo u některých pracovníků aţ k jisté frustraci a hlavně přepracování, coţ mělo za následek větší chybovost při plnění dílčích úkolů v rámci jednotlivých projektů a tím i několikanásobné jejich následné opravě. V krajních případech to můţe vést aţ k odchodu zaměstnance z organizace a tím ke ztrátě v danou chvíli potřebného odborníka pro probíhající projekty. Vše to samozřejmě vede na zbytečnou ztrátu času určeného pro projekty. Toto není pouze jediný důvod, kdy dochází k obměně členů projektového týmu v průběhu realizace projektu. Dalším příkladem můţe být například změna ve vedení organizace z politických důvodů nebo vyšší míra fluktuace zaměstnanců ve státní správě z důvodu jejich nespokojenosti s prací a zejména s finančním ohodnocením jejich práce ve státní organizaci. Z výše uvedených příčin se pak do projektového týmu dostávají lidé, kteří nedisponují příslušnou kvalifikací a odborností a nemají zkušenosti s prací v projektových týmech. Tato skutečnost je také následkem výběru členů projektového týmu přímo vedením organizace. Tento fakt následně můţe výrazně ovlivnit průběh realizace celého projektu, ale mnohdy také ostatní členy týmu. Navíc to přináší i nutnost zvýšeného úsilí samotného projektového manaţera.
2.3.
Financování
Financování ve státní správě má velmi specifické vlastnosti. Státní organizace jsou vesměs spotřebiteli finančních zdrojů a de facto ţádné finanční zdroje negenerují. Toto má za následek specifické finanční řízení ve státních organizacích. Toto řízení je postaveno na čerpání předem naplánovaného rozpočtu, kde tento plán je vytvářen s ročním předstihem. Na tomto principu není nic zvláštního, vţdyť většina firem plánuje dopředu. Specifikum ale přichází ve chvíli realizace výdajů finančních zdrojů ze státního rozpočtu. Proces těchto výdajů se musí řídit několika zákony a to zejména zákonem č.137/2006 Sb., o veřejných zakázkách. A právě v tomto zákoně je omezení, které při plánování a následné realizaci projektů můţe způsobit mnoho nepříjemností. Během plánování projektů se dle metodiky Prince2[6] vytváří několik rozpočtů: rozpočet pro aktivity projektu, rizikový rozpočet a rozpočet pro změny.
25
Rozpočet pro aktivity projektu je určen pro naplánované aktivity pro realizaci projektu. Tento rozpočet tedy pokrývá veškeré výdaje dle finančního plánu projektu. To znamená, ţe pokud realizace projektu tzv. „běţí“ hladce bez problémů, tak je vše hrazeno právě z tohoto rozpočtu. Rizikový rozpočet naopak slouţí pro pokrytí stavu, kdy nastane některé z identifikovaných rizik, s nímţ bylo počítáno během plánování projektu. Všechna rizika jsou ve fázi plánování evidována v registru rizik. Rozpočet pro změny slouţí pro eliminaci případných změn, které mohou nastat v průběhu realizace projektu. Těmito změnami mohou být nové poţadavky sponzora, hlavního uţivatele nebo poţadavky, které vzniknou na základě pouţití nových technologií a tyto technologie s sebou přináší nějaké dodatečné úpravy jiţ existujícího prostředí. V případě projektů ve státní správě se poměrně dost často stává, ţe se zadání velice dynamicky mění v průběhu realizace projektu, coţ většinou bývá důsledkem nedostatečně vypracované vstupní analýzy (zajímavé je, ţe tyto změny mnohdy jdou proti sobě a jsou neslučitelné s ostatními částmi zadání). V rámci této analýzy nebyly vzaty v potaz dopady změn, které se v průběhu realizace projektu provádí, na ostatní okolí a systémy. Tento fakt je většinou způsoben neexistencí nebo existencí nedostatečných popisů navazujících procesů. Další příčinou můţe být i nekompletní dokumentace architektury IT prostředí. Toto vše má pak za následek generování zbytečných vícenákladů (nejen finančních). V tuto chvíli přichází na řadu jiţ zmiňované omezení uvedeným zákonem. Zákon o veřejných zakázkách nepřipouští navyšování ceny díla, které bylo v rámci výběrového řízení soutěţeno. Stát jako správný hospodář můţe cenu díla dle tohoto zákona navýšit maximálně o 20% v rámci opce. V realitě však někdy, zejména při absenci kompletního zadání, tato částka nestačí. Toto omezení neumoţňuje při plánování projektů vytvářet výše zmíněné rozpočty. Tento fakt vede pak na to, ţe pokud je rozpočet velmi „úzký“ a během realizace projektu je poţadováno mnoho změn, se některé zdánlivě „nepodstatné“ aktivity zruší nebo jinak omezí. Toto má ale vliv na klesající kvalitu celého díla.
26
2.4.
Vstupní analýza
Pro správné plánování a realizaci projektu je potřeba nejprve identifikovat cíle a záměry projektu. Toto se nejlépe provede pomocí vstupní analýzy potřeb, vytvořením obchodního případu a studie proveditelnosti. Tato část je nejdůleţitější etapou při plánování projektu, jejíţ provedení či neprovedení rozhoduje o kvalitě realizovaného projektu a jeho budoucím úspěchu či neúspěchu. V prostředí státní správy bývá tato etapa velmi často opomíjena. Toto je způsobené absencí příslušných znalostí v řadách zaměstnanců i samotného vedení v oblasti projektového řízení. Na druhou stranu, pokud je tato etapa realizována, tak mnohdy jsou tyto analýzy velmi povrchní a nezahrnují všechny dimenze pohledu na připravovaný projekt. V rámci těchto analýz bývá opomíjen fakt, ţe realizace projektu ovlivní nejen dotčený útvar nebo oddělení, ale jak je tomu u ICT projektů, bývá ovlivněno širší prostředí a okolí organizace. Realizace projektu přináší nový způsob práce a někdy i nutnost změny organizační struktury organizace. V případě státních institucí je nutno brát také v potaz vliv na okolí organizace. V rámci vstupní analýzy potřeb jsou poţadavky na nové řešení mnohdy neúplně definovány. Není provedena analýza dopadů plánovaných změn na okolí. Příčinou absence těchto aspektů plánování můţou být i nedostatečně popsané procesy. Největším problémem bývá neexistence popisu interních procesů organizace. V takovém případě jsou činnosti vykonávány intuitivně na základě mnohaletých zkušeností zaměstnanců a dle aktuálních potřeb. Při takto postaveném způsobu práce je velmi obtíţné pamatovat na všechny moţné varianty. Také zde chybí i vazby na další činnosti, které by změnou formou realizace projektu, mohly být ovlivněny. K realizaci obchodního případu a studie proveditelnosti v podstatě dost často ani nedochází. Vedení je spokojeno s příslušnou obecnou definicí poţadavků. Na základě těchto poţadavků se připraví zadání a zahajuje se projekt. V případě, ţe je projekt realizován externím dodavatelem, coţ je nejčastější případ státní správy, slouţí tyto poţadavky jako podklady pro výběrové řízení. V rámci realizace projektu bývá sice poţadována analýza, ale tu většinou provádějí lidé, kteří nejsou znalí prostředí organizace a jejích interních procesů. Součinnost interních pracovníků bývá v tomto případě minimální nebo nulová. Mylně se v tomto případě zaměstnanci organizace domnívají, ţe analýza byla součástí objednávky, „tak ať ji za nás udělají“. Tento postoj můţe mít ale velmi negativní důsledky. Pracovníci externího 27
dodavatele mnohdy pak v případě neexistence popisů procesů „vaří z vody“ a následkem toho bývají výstupy zcela odlišné od představ organizace. Dalším důvodem zjednodušené analýzy je i cena celého projektu. Dodavatel, aby zakázku získal, nabídne nízkou cenu a následně mnohdy nepozorovaně „šidí“ jednotlivé aktivity, aby se dostal do příslušného rozpočtu. Následkem tohoto se pak zjišťuje, ţe projekt není v takové podobě vůbec realizovatelný, je ukončen a finance do něj vloţené jsou nenávratně ztraceny. Zjistí se, ţe výstupy projektu nejsou ve své konečné podobě pouţitelné. Na základě těchto analýz se následně určují i akceptační kritéria pro ukončení jednotlivých fází projektu a projektu samotného. V prostředí státní správy bývají tato akceptační kritéria velmi obecná nebo vůbec neexistují. Příkladem můţe být jediné akceptační kritérium a to funkčnost nové aplikace. Pro převzetí výstupů z projektu postačuje fakt, ţe je nová aplikace funkční a negeneruje závaţné chyby. Skutečností, ţe není aplikace uţivatelsky přívětivá a uţivatelům přináší práci navíc, se uţ dále nikdo nezabývá.
2.5.
Výběr zainteresovaných stran
Identifikace zainteresovaných stran úzce souvisí se vstupní analýzou. V rámci analýzy jsou často chybně nebo mylně identifikovány dotčené strany, coţ následně vede k mnoha nedorozuměním a nepochopením. Příkladem takového omylu můţe být to, ţe se identifikují jako dotčené útvary ty, jejichţ pracovníci budou do nové aplikace vkládat data. To, ţe tito pracovníci pouze do systému data zadávají a dále se systémem jiţ nepracují, není bráno na zřetel. Toto má za následek, ţe pracovníci, kteří pracují nebo budou pracovat s novou aplikací nebo s výstupy z této aplikace, ani nevědí, ţe se jejich pracovní nástroj bude měnit. Jsou pak postaveni před novou aplikaci aţ ve chvíli, kdy je naplánováno školení uţivatelů. Následně teprve aţ na školení jsou vyřčeny podstatné připomínky k jiţ hotové aplikaci. Výše uvedený příklad se zabývá interními stranami organizace. Při výběru těchto stran bývá dost často opomíjena strana externí. Nové systémy mají ve většině případů dopady i na externí uţivatele jako jsou veřejnost, ostatní organizace státní správy, evropské organizace a další. V případě omezeného pohledu na interní oblast organizace následně dochází k tomu, ţe pro externí prostředí není nový systém pouţitelný. V lepším případě se toto okolí o změně dozvídá poměrně pozdě a má velmi krátkou dobu na to, aby se novému prostředí přizpůsobilo. 28
Důvodem těchto nedostatků při vstupních analýzách můţe být také fakt, ţe některé změny musí být v souvislosti s novou legislativou aplikovány ve velmi krátké době.
2.6.
Absence některých činností při vedení projektu
Během samotné realizace projektu jsou některé činnosti opomíjeny. Velmi často se stává, ţe v plánu projektu jsou naplánovány pravidelné schůzky projektového týmu a řídícího výboru, nicméně zejména v případě řídícího výboru se tato setkání neuskutečňují. Toto bývá způsobeno přílišným pracovním vytíţením jejich členů nebo také jejich nízkým stupněm zájmu o průběhu projektu. Mnohokrát se stává, ţe na schůzky posílají členové výboru za sebe zástupce, kteří zpravidla o záměru a dosavadním průběhu realizace projektu nic nevědí. Tím je oslabená schopnost výboru správně rozhodovat o případných poţadavcích na změnu, které v průběhu projektu vznikají. Ještě závaţnějším případem je situace, kdy poţadavky na změnu nejsou s výborem konzultovány a změna je provedena na základě rozhodnutí projektového týmu anebo ještě hůře projektového manaţera. Absence eskalační procedury v případě vzniku poţadavku na změnu nebo řešení případných problémů je další slabinou vedení projektu. Při plánování a prvním setkání všech účastníků projektu nejsou jasně stanovena pravidla pro změnové řízení a postupu při řešení problémů včetně termínů pro jejich vyřizování. Někdy zase nastávají situace, kdy ač jsou tato pravidla nastavena a eskalace je skutečně provedena, není v adekvátním čase na tyto eskalace reagováno. V těch horších případech jsou tyto eskalace zodpovědnou osobou přehlíţeny. Samostatnou kapitolou je absence řízení rizik během realizace projektu. Ve fázi plánování jsou rizika identifikována a zanesena do registru rizik. Tato identifikovaná rizika a zejména popsané reakce na ně zůstávají potom ale pouze „na papíře“. Během realizace projektu se následně při vzniku případného rizika dle stanovených kroků nepostupuje. Reakce na vzniklé identifikované problémy jsou potom zejména intuitivní a ne vţdy správné. Navíc během realizace nejsou tato rizika aktualizována a monitorována. Dost často se stává, ţe tato rizika jsou nedostatečně identifikována a následně v průběhu realizace projektu nastane situace, kdy nastane riziko, které nebylo při plánování identifikováno a nikdo neví, jak na tuto vzniklou situaci reagovat. V této chvíli se začíná s analýzou rizika a tím dochází ke zbytečné ztrátě času, který je pro projekt klíčovou veličinou. Přitom by stačilo se ve fázi analýzy důkladněji na identifikaci moţných rizik zaměřit. 29
Reporting o stavu projektu nebývá také silnou stránkou při realizaci. Pro správné řízení a rozhodování v určitých okamţicích je nutné znát aktuální stav dosud realizovaných činností. Kvalita reportování bývá dost často velmi slabá. Informace jsou mnohdy neúplné nebo zkreslené, coţ můţe mít za následek špatné rozhodování v dalších etapách projektu. Důvody nekvalitního reportování bývají většinou obavy z případných postihů příslušné osoby za problémy, které se vyskytnou při realizaci projektu a se kterými se v plánovací fázi nepočítalo. Zde je opět vidět, jak je důleţité průběţně monitorovat a aktualizovat příslušná rizika. Při nedůsledné kontrolní činnosti nebo dokonce při její absenci se můţe stát, ţe si projekt řídí dodavatelé sami podle svého a uzpůsobují si ho tak, aby měli co nejméně práce. V takovém případě se projekt pohybuje mimo stanovený plán a můţe se stát, ţe původní záměr se úplně vytratí. Následně při dokončení projektu a jeho předávání vedení nejsou výstupy z projektu převzaty, protoţe nereflektují stanovené cíle při jejich zadávání na začátku projektu.
2.7.
Souhrn specifik
Níţe je seznam specifik prostředí státních organizací: povaha státní organizace jako organizace, která pouze spotřebovává finanční zdroje, chybné umístění projektových manaţerů v organizační struktuře, absence plánování zdrojů, zejména lidských, silná míra tzv. „politikaření“, nízká úroveň znalostí o projektovém řízení na všech úrovních, v některých případech absence role sponzora, tlak na co nejniţší cenu na úkor kvality, striktní mantinely při výběru realizátora projektu, absence vstupních analýz, analýz dopadů a obchodních případů, neadekvátní a často ovlivňovaný výběr zainteresovaných stran, krátká doba na realizaci změn na základě legislativních změn, absence některých činností, zejména řízení rizik.
30
3. Popis konkrétního projektu a jeho analýza Projekt, který bude dále popisován, byl realizován v organizaci, která se zabývá zejména kontrolní činností. Během své práce zaměstnanci organizace vyuţívali mnoho interních aplikací. Ke kaţdé aplikaci měli tito zaměstnanci přidělené různé přístupové údaje a role. Z důvodu potřeby zefektivnit a zejména zjednodušit práci při přihlašování do těchto aplikací vznikla potřeba sjednotit a zjednodušit přístupy zaměstnanců do těchto aplikací. Dalším poţadavkem bylo řídit veškeré přístupy k aplikacím z jednoho centrálního místa. Jako jedno z řešení se nabízelo zavedení jednotného systému pro správu identit a rolí v rámci organizace při zachování stávající úrovně bezpečnosti informací. Správa těchto rolí by se měla provádět pomocí portálu. Celý systém by byl napojený na personální systém, který by slouţil jako primární a jediný zdroj informací o identitách. Projekt byl nazván „Portál interních identit IIM“.
3.1.
Popis a cíl projektu
Cílem projektu bylo vytvořit portál pro správu identit interních uţivatelů organizace. Na základě rolí přidělených v portále by měli uţivatelé zpřístupněné jednotlivé aplikace pro svou práci. Přidělování jednotlivých rolí by záviselo na pracovní pozici daného zaměstnance. Součástí projektu bylo také napojení stávajícího personálního systému na tento portál jako výchozího a jediného zdroje informací o identitách. Systém by měl být otevřený a připravený pro následné postupné napojování dalších interních aplikací. Napojování dalších aplikací nebylo součástí tohoto projektu. Projekt byl rozdělen do tří etap. První etapa zahrnovala analýzu a návrh řešení, druhá etapa vývoj a implementaci do prostředí organizace a třetí etapa pilotní provoz a zaškolení uţivatelů a administrátorů včetně dodání příslušné dokumentace.
3.2.
Analýza potřeb a plánování projektu
Analýza potřeb byla provedena interními zdroji organizace. Výstupy z této analýzy byly poţadavky na základní funkcionalitu budoucího portálu. Mezi tyto základní funkcionality 31
patřily správa identit, napojení na stávající systém správy identit, napojení na stávající personální informační systém, definice zobrazovaných informací o identitě, definice jednotlivých rolí pro práci s portálem a jejich oprávnění, otevřenost řešení pro napojení dalších interních informačních systémů atd. V rámci této analýzy byly identifikovány základní poţadavky na komunikaci se stávajícími informačními systémy organizace a poţadavky na evidenci logů zachycujících všechny změny identit provedené portálem. Portál měl mít implementovány základní scénáře - zaloţení, změnu a zrušení identity. Jednotlivé scénáře byly popsány pomocí tabulky popisující jednotlivé kroky a obrázkem vytvořeným UML notifikací. Organizace disponovala standardizovaným procesem na projektové řízení. V rámci tohoto standardu bylo rozhodnuto, ţe tento projekt poběţí v reţimu zjednodušeného projektu. Tento reţim, dle zmiňovaného standardu, kromě projektového vedoucího a projektového týmu další projektové orgány nezřizuje. Pro tento projekt byli jmenováni dva projektoví vedoucí – jeden vedoucí za organizaci a druhý za dodavatele nového řešení. V etapě plánování projektu proběhla schůzka, na které byli představeni členové projektového týmu. Projektový tým by se dal rozdělit na dvě části. První část představovali zaměstnanci dodavatelské firmy, která v rámci projektu realizovala vytvoření samotného systému. Druhou část projektového týmu tvořili pracovníci organizace, kde se měl nový systém pro správu identit implementovat. Při rozboru tohoto sloţení projektového týmu vyšlo najevo, ţe v týmu chyběl zástupce dodavatele stávajícího personálního systému organizace. Vzhledem k tomu, ţe cílem projektu byla integrace portálu s tímto personálním systémem a bylo nutné tento systém přizpůsobit a upravit, absence tohoto člena projektového týmu by mohla způsobovat při realizačních pracích komplikace. Celková doba realizace projektu byla naplánována na celkem 93 dní. Pro etapu analýzy a návrhu řešení bylo stanoveno 17 dní, pro etapu realizace a testování to bylo 45 dní a pro etapu pilotního provozu a konečnou akceptaci bylo stanoveno 31 dní. Během plánování byl vytvořen registr rizik. Jako předloha tohoto registru byla vzata šablona registru rizik z jiţ zmiňovaného podnikového standardu pro projektové řízení. V rámci této šablony byla předdefinována obecná rizika. Tato rizika byla všechna vyloučena. V části, kde měla být zaznamenána jiná identifikovaná rizika, nebylo ţádné riziko uvedeno.
32
V rámci plánování byla také stanovena komunikační pravidla včetně komunikační matice, hlavní komunikátor a četnost pravidelných schůzek projektového týmu. Podoba a četnost pravidelných reportů vedení organizace stanoveno nebylo. Pro jednotlivé etapy byla stanovena a všemi stranami odsouhlasena akceptační kritéria.
3.3.
Realizace projektu
Realizace projektu začala analýzou stávajícího prostředí a na základě této analýzy návrhem řešení. Během analýzy byly upřesněny a doplněny poţadavky na nový systém. V rámci této analýzy bylo nutné vytvořit a popsat některé dosud neexistující procesy organizace. Během této etapy se narazilo na několik problémů, které bylo nutné řešit za pomoci třetích stran. Díky tomuto faktu a nezajištění si adekvátní rychlosti odezvy u třetích stran v rámci realizace tohoto projektu, začala první etapa nabírat zpoţdění. Vzhledem k tomu, ţe nebylo zajištěno pravidelné a strukturované reportování vedení organizace, dostávalo toto vedení mnohdy zkreslené informace. Informace o stavu projektu nebyly reportovány ani nadřízeným členů projektového týmu a tak neexistovala informace o skutečném stavu. Na toto zpoţdění nebyla podána adekvátní informace. V průběhu první etapy došlo také k výměně projektového vedoucího na straně organizace jejím vedením. Toto mohlo také způsobit vznik zpoţdění. Nový vedoucí projektu nebyl do projektu patřičně zasvěcen a tak nějakou dobu trvalo, neţ získal všechny potřebné informace od odstupujícího vedoucího projektu. V registru rizik nebylo toto riziko vůbec uvedeno a ani dodatečně doplněno. Harmonogram projektu byl náleţitě upraven. První etapa projektu měla zpoţdění o 25 dní. Zpoţdění bylo způsobeno zejména z důvodu chyb nebo nejasných popisů ve výstupním dokumentu, který byl jediným akceptačním kritériem této etapy.
V průběhu realizace druhé etapy projektu byly vydefinovány poţadavky na HW a SW. Bylo vytvořeno testovací prostředí a provedena příprava a nastavení infrastruktury. Dodavatel mezitím vyvíjel nový systém dle odsouhlasených a upřesněných poţadavků v průběhu analytické části. Následně byla zahájena instalace nového systému do testovacího prostředí. Jednotlivé úkoly druhé etapy byly vedeny ve formě otevřených bodů realizace. Kaţdému 33
tomuto bodu byla přidělena priorita dle jeho významu v projektu. Body, jejichţ včasné dokončení mělo významný vliv, byly označeny příznakem rizika. Co však chybělo, bylo zanesení dopadu těchto rizik na průběh realizace projektu nebo jeho dílčí části. Druhá etapa s sebou přinesla mnoho problémů a s těmito problémy související další zpoţdění. Zásadním problémem bylo zjištění, ţe testovací prostředí neodpovídá produkčnímu a není plně připraveno pro realizaci testování. Tento fakt s sebou přinesl nutnost upravit jiţ vyvinutou aplikaci a následně znovu nasadit do testovacího prostředí. Toto bylo způsobeno odlišnou konfigurací stávajícího systému pro správu identit v testovacím prostředí oproti konfiguraci v produkčním prostředí. Vzhledem k tomu, ţe tento systém byl jiţ „historický“ a organizace nedisponovala potřebným know-how, bylo rozhodnuto o úpravě nové aplikace. Chyběl popis stávající aplikace pro správu identit a také popis architektury jejího napojení na další systémy. Příčinou tohoto stavu mohl být fakt, ţe v řízení IT nebyly implementovány základní procesy např. dle rámce ITIL®. Další zpoţdění bylo nabráno z důvodu nekvalitních výstupů z první etapy. Při realizaci druhé etapy vyšlo najevo několik aspektů, které nebyly v první etapě vůbec zahrnuty. Jednalo se zejména o způsob dohledu nad novým systémem a v podobě testovacích scénářů. Na základě tohoto zjištění se musel vymyslet systém dohledu, implementovat a otestovat a stávající testovací scénáře musely být kompletně přepracovány. Na problémech druhé etapy se také podepsaly letní prázdniny. Nedostatečným personálním zabezpečením byly některé úkoly odkládány na další a další týdny. Zároveň pokulhávala aktualizace příslušných dokumentů a harmonogramu projektu. Například registr rizik nebyl stále aktualizován a v podstatě byl odsunut do pozadí. Seznam jednotlivých úkolů a jeho aktuálnost taktéţ zaostávala, coţ mělo za následek, ţe v době dovolených nebylo jasné, co se mělo přesně dělat, co mělo následovat apod. V této etapě začala spolupracovat externí firma, která dodala a spravovala v organizaci personální systém. Vzhledem k tomu, ţe tento dodavatel nebyl zastoupen v projektovém týmu, musel být záměr projektu tomuto dodavateli prezentován. V souvislosti s tímto muselo být zástupcům tohoto dodavatele vysvětleno, co je potřeba upravit. Úkoly byly převzaty k řešení včetně termínů, do kdy měly být vyřešeny. Protoţe dodavatel nebyl zastoupen v projektovém týmu a tudíţ neměl předem blokované kapacity pro realizaci obdrţených úkolů, byly výstupy z těchto úkolů předány s jistým zpoţděním. Zpoţdění realizace projektu se tak nadále zvětšovalo. Zapojením dalšího participujícího subjektu do projektu byly 34
identifikovány nové poţadavky na další úpravy a změny, se kterými se v průběhu analýzy vůbec nepočítalo. Poslední aktivitou druhé etapy byla příprava produkčního prostředí. Před samotným zahájením prací bylo zjištěno, ţe pro přípravu produkčního prostředí je potřeba dalších participujících stran z řad správců jednotlivých částí infrastruktury a úprava její konfigurace. Opět nebylo na začátku s těmito stranami počítáno. Při samotné realizaci této aktivity se zjistilo, ţe některé a v podstatě většina popisů stávajícího nastavení systémů, byly velmi obecné, a tudíţ se nedaly na tomto základě provádět další aktivity. Na základě tohoto zjištění se vypracovávaly podrobnější potřebné popisy tak, aby bylo moţné v pracích dále pokračovat. Lze si jednoduše představit, ţe v tomto případě, kdy tyto dodatečné práce nebyly plánovány, se termín dokončení této etapy pomalu ale jistě vzdaloval definovanému plánu. Do všech těchto problémů vstoupily nové poţadavky na úpravu personálního sytému, coţ samozřejmě vedlo i na úpravu navazujícího nového systému. Tímto neuváţeným krokem se v podstatě vývoj a implementace nového systému dostala do stavu, kdy bylo nutné udělat několik kroků zpět. Opět toto mělo vliv na další prodlouţení doby realizace. Druhá etapa trvala celkem 163 dní.
3.4.
Ukončení projektu a předání do provozu
Poslední etapa obnášela spuštění pilotního provozu po dobu 30 dní, zajištění školení uţivatelů systému a vedoucích pracovníků, zpracování a předání dokumentace systému. Posledními kroky této etapy měly být akceptace etapy a předání celého díla. Bohuţel vlivem chybějící koordinace vazeb na jiné projekty byl realizován před spuštěním pilotního provozu jiný projekt, který zásadně měnil stávající prostředí infrastruktury. Spuštění pilotního provozu bylo odloţeno. V dostupné projektové dokumentaci jsem nenalezl výstupy z této poslední etapy. Po spuštění pilotního provozu byl vytvořen plán školení jednotlivých zaměstnanců organizace. Školení bylo rozděleno do několika dnů dle povahy účastníků. Bylo rozděleno na tři typy – školení uţivatelů, vedoucích a administrátorů.
35
Během této etapy prošla dokumentace díla několika koly připomínkování a na poslední schůzce projektového týmu byla předána před akceptací této etapy. Poslední etapa trvala 75 dní. Po akceptaci poslední etapy byl projekt ukončen z důvodu naplnění všech cílů projektu. Bohuţel nedostatečným testováním integrace personálního systému do nového řešení bylo za nějakou dobu po ukončení projektu zjištěno, ţe integrace nepracuje tak, jak by měla. Toto bylo zejména způsobeno nedostatečnou analýzou všech moţných variant při práci s identitami v personálním systému.
3.5.
Zhodnocení analyzovaného projektu
Po ukončení projektu mělo být dílo předáno oddělení IT do správy. Na základě tohoto předání měly být realizovány činnosti pro připojení různých aplikací organizace na tento systém. Bohuţel k tomuto nedošlo. Z nevysvětlitelných důvodů k předání do provozu správcům oddělení IT nedošlo. K napojování dalších aplikací také nedošlo. V rámci realizace projektu byly napojeny na systém dvě aplikace a telefonní systém. Toto mělo za následek výskyt několika problémů během prvního roku od ukončení projektu. Během této doby měla sice aplikace vlastníka, ale neměla správce z řad pracovníků IT oddělení. V tomto období nedošlo k napojení dalších aplikací na nový systém a nebyl naplněn původní záměr, kvůli kterému byl projekt realizován. Z důvodu výměny vedení nebylo nic podniknuto ani z této strany. Po téměř roce a půl bylo dílo předáno oddělení IT a to pouze z důvodu odchodu projektového manaţera tohoto projektu z organizace. I přes poměrně velké zpoţdění byl projekt dokončen. Bohuţel nedošlo k závěrečnému hodnocení projektu a tak pro někoho byl projekt úspěšný a pro někoho naopak ne. Závěrem bych chtěl podotknout, ţe mnoho činností v tomto projektu bylo řízeno správně. V textu výše byly uvedeny zejména nedostatky nebo problémy, které se během realizace projektu vyskytly. Zdroje těchto problémů mohou být různé a byly zmíněny v kapitole 2. Analýza výše zmiňovaného projektu byla provedena na základě dostupné projektové dokumentace a vlastních zkušeností z realizace jiných projektů v prostředí státní správy. Můj příspěvek v rámci tohoto projektu bylo poskytnutí součinnosti pracovníků mého týmu, kteří byli členy projektového týmu nebo poskytovali technickou podporu při realizaci potřebných změn na infrastruktuře. Z mého pohledu, coby pracovníka provozu, byl tento projekt úspěšný 36
tak z 60%. S nedodělky, které vznikly z důvodu neodpovídající analýzy, se organizace potýká do současnosti.
4. Návrh optimálního řízení projektů ICT ve státní správě V této kapitole se pokusím navrhnout kroky, které by měly vést k lepšímu řízení projektu s cílem jej úspěšně dokončit, předat do provozu výstupy z tohoto projektu a následně zajistit nebo nastavit další rozvoj těchto výstupů v prostředí státní organizace.
4.1.
Propagace záměru projektu
Pro úspěšnou realizaci a hlavně dokončení projektu je nutné a nezbytné cíle projektu prezentovat zainteresovaným stranám. Cíle projektu musí být jasně definovány. Neměly by to být obecně vyřčené cíle. Zainteresované strany musejí cíle projektu vzít za své cíle. Jedině tak si projektový manaţer zajistí podporu všech zúčastněných stran a maximální úsilí těchto stran pro dokončení projektu. Je potřeba zdůraznit zejména přínosy, které realizace projektu přinese samotným zainteresovaným stranám i celé organizaci. V předešlé kapitole byla popsána realizace konkrétního projektu. U tohoto projektu nebyla ţádná propagace zainteresovaným stranám, coţ v tomto případě byla celá organizace, uskutečněna. To mělo za následek, ţe o projekt nikdo nejevil zájem a projekt byl realizován v podstatě v tichosti. Teprve v poslední etapě, kdy probíhala jednotlivá školení, většina zaměstnanců začala vnímat fakt, ţe se něco v brzké době bude měnit. Řádná prezentace nebyla provedena ani členům projektového týmu. V případě těchto členů nebyla zdůrazněna důleţitost a význam tohoto projektu pro celou organizaci. Jako formu tohoto seznámení se záměry a cíli projektu lze pouţít několika technik. Jednou z nejznámějších je workshop. Na tomto setkání je nutné nejen umět prezentovat projekt a zdůraznit jeho potřebu pro organizaci, ale také dát moţnost se ostatním vyjádřit. Aby se tento workshop nezměnil v nekonečné diskuzní fórum, měla by být provedena důkladná jeho
37
příprava. Na začátku samotného workshopu by měla být stanovena pravidla pro diskuzi, která bude umístěna v programu na konci setkání. Dalším moţným způsobem představení projektu je vyuţití například intranetových stránek. Na interních stránkách organizace by mohly být důleţité informace nebo přímo prezentace těchto informací vyvěšeny. Tento způsob komunikace nese s sebou jisté riziko. Toto riziko tkví v tom, ţe ne všichni zaměstnanci budou mít čas a mnohdy i chuť tyto informace si přečíst. Z tohoto důvodu bych upřednostňoval osobní kontakt se zainteresovanými stranami. V případě podávání informací o připravovaném projektu širokému spektru zaměstnanců organizace bude stačit zmínit základní informace a hlavně zdůraznit budoucí přínosy nejen pro organizaci, ale hlavně pro samotné její zaměstnance. Ukázáním budoucích výhod je dobrý začátek na cestě pro zisk zájmu a příslušné podpory. Naopak při propagaci projektu úzkému okruhu zainteresovaných stran je nutné jít více do detailu. Je nutné zajistit, aby záměry a cíle projektu byly pochopeny všemi členy projektového týmu před samotným zahájením projektu. Navrhuji před realizací kaţdého projektu připravit dva workshopy. První workshop by měl být zaměřený na obecné informace. Účastníky tohoto setkání by měli být zejména přímo dotčené strany v organizaci. Obsahem workshopu by mělo být následující: záměr projektu, důvody rozhodnutí pro realizaci projektu, očekávané přínosy pro organizaci, kdo se bude na projektu podílet, kdo bude během realizace a po ukončení projektu bezprostředně ovlivněn, co bude v návaznosti na projekt následovat, co se bude muset po ukončení projektu změnit, které další projekty nebo záměry budou navazovat na tento projekt, jaké přínosy a změny projekt přinese v běţné pracovní činnosti, zopakování záměru a přínosů projektu, zdůraznění zájmu vedení organizace na dokončení projektu, diskuse.
38
Následně navrhuji výstupy z tohoto setkání publikovat na stránkách intranetu organizace spolu se zápisem z diskuse. Druhé setkání navrhuji zaměřit na samotné členy projektového týmu. Na toto setkání navrhuji pozvat i zástupce dodavatelů. Obsahem tohoto setkání by mělo být výše uvedené plus podrobnější informace o představě o průběhu realizace projektu. Důleţité je členům projektového týmu, a to zejména z řad zaměstnanců organizace, zdůraznit důleţitost projektu a tím i důleţitost jejich práce na svěřených úkolech v průběhu realizace projektu. Tyto informace by měly být shrnuty do několika bodů a ty by měly být viditelné v průběhu realizace projektu. Například by tyto body mohli být připojeny k emailovému podpisu projektového manaţera, aby v případě zaslání úkolu cestou emailu měli řešitelé základní cíle stále před očima.
4.2.
Zajištění podpory vedení
Dalším důleţitým faktorem pro projekt je stálá podpora vedení organizace. Tato podpora je úzce spojena se zájmem vedení o projekt. Několikrát jsem se setkal s tím, ţe na začátku projektu je zájem vedení veliký a informace o vývoji projektu jsou vyţadovány někdy i na denní frekvenci. Bohuţel s postupem času, kdy se projekt rozběhl a probíhá, tento zájem postupně klesá. Projektový manaţer mnohdy usoudí, ţe není nutné podávat pravidelně informace o vývoji projektu a od této činnosti ustoupí. Toto můţe mít za následek, ţe vedení není pak informováno ani v případech vzniklých problémů a vzniku zdrţení při realizaci. Znovu se zájem zvyšuje s blíţícím se termínem dokončení projektu a mnohdy je následně vedení nemile překvapeno, ţe projekt není zdaleka u konce a nabral zpoţdění. Další kroky komunikace s vedením není nutné popisovat. Příčin poklesu zájmu můţe být několik. Jednou z těchto příčin můţe být fakt, ţe v případě krátké frekvence informování jsou podávané informace téměř stále stejné a vedení můţe usoudit, ţe se nic neděje. Další příčinou můţe být přesun zájmu k jinému problému nebo projektu. Při představení projektu vedení by mělo být stanoveno jakým způsobem a jak často budou podávány průběţné informace. Nesmí se zapomenout ani stanovení eskalačního procesu pro případ zajištění potřebného rozhodnutí v případě závaţných problémů. Pro pozdější dokumentaci vývoje a realizace projektu by bylo dobré si vést evidenci těchto eskalací spolu s reakcemi vedení v rámci zpětné vazby. V této evidenci by mělo být 39
evidováno datum, popis poţadavku, kdo jej předloţil, komu byl předloţen, kdy byl předloţen, kdy se vrátila zpětná reakce, jaká byla tato reakce. V případě ignorování eskalace by měla být moţnost tuto informaci do evidence zapsat.
4.3.
Důkladná analýza poţadavků
Analýza poţadavků a tím sestavení zadání projektu je spolu s plánováním projektů nejdůleţitější etapou projektového řízení. Mnohdy jsou tato zadání velmi stručně nebo obecně popsána. Na základě těchto „vágních“ popisů vzniká při realizaci projektu mnoho problémů a nedorozumění. Následkem toho je celé zadání přepracováváno v průběhu realizace projektu, čímţ projekt nabírá značné zpoţdění. Analýze poţadavků by mělo být věnováno dostatečné mnoţství času, aby bylo moţné touto analýzou postihnout pokud moţno vše včetně souvisejících aspektů. Pro analýzu by měl být ustanoven analytický tým. V tomto týmu by měli být zastoupeni odborníci ze všech moţných oborů, jichţ se bude budoucí projekt týkat. Jedině tak lze dosáhnout pohledu ze všech moţných dimenzí a zahrnout tak do zadání příslušné aspekty. Většina poţadavků, například na vytvoření nové aplikace, pocházejí ze strany byznysu. V tomto případě je nutné provést analýzu velmi důkladně, protoţe mnohdy pracovníci z této oblasti nejsou schopni formulovat dostatečně zadání. Je potřeba v rámci analýzy popsat všechny poţadované funkcionality, které jsou ţádoucí, potřebné a budou se skutečně vyuţívat. Plánováním dodatečných a většinou „zkrášlujících“ funkcionalit vede na budoucí moţné problémy, které mohou projekt prodraţovat a prodluţovat. Kaţdá funkcionalita musí být přesně a srozumitelně popsána, aby v budoucnu nevznikaly různé výklady daného poţadavku. V průběhu analýzy musí být postupně definována jednotlivá akceptační kritéria pro závěrečnou akceptaci. Tato kritéria musí být velmi podrobně popsána. V popisu musí být nejen popis kritéria, ale také činnosti, které je potřeba udělat, aby byla tato kritéria otestována. Akceptační kritéria jsou rozhodujícím prvkem ve fázi ukončení projektu a předání výstupu do produkce. Kritériím se přiřazuje priorita dle důleţitosti příslušné funkcionality. V rámci předávacího procesu se pak můţe určit hranice akceptovatelnosti výstupu z projektu dle splněných kritérií. Kritéria mohou být kvantitativní nebo kvalitativní. Kvantitativní kritéria 40
jsou jasně definována určitou hodnotou, kterou musí výstup z projektu dodrţovat. Stanovení těchto kritérií není tak sloţité. Problém můţe nastat při definici kvalitativních kritérií. Důvod případných potíţí je ten, ţe kaţdý člověk vnímá kvalitu různě. Je nutné se v rámci analýzy předem domluvit na parametrech těchto kritérií. Tyto parametry musí být jasně a srozumitelně definovány a hlavně zapsány. Jedině tak lze předejít do budoucna dohadům typu „takto to myšleno nebylo“ apod. Sepsaná kritéria musí být odsouhlasena všemi, kdo bude provádět akceptaci a zejména hlavním uţivatelem nového řešení. Vzhledem k faktu, ţe pracovníci byznysu kolikrát neumí správně definovat své poţadavky, je moţné v rámci organizace vytvořit pozici jakési styčné osoby, která bude jednotlivé poţadavky od pracovníků sbírat, dávat do společného kontextu a na základě toho vytvářet soupis logicky souvisejících poţadavků. Jedině tak lze zajistit, ţe poţadavky budou dávat dohromady smysl a nebudou si „protiřečit“. Tato pozice bývá obvykle označována jako byznys analytik. Problém je v tom, ţe dobrých byznys analytiků je v našich zeměpisných šířkách velmi málo a jejich práce je poměrně drahá. Jako druhá moţnost se nabízí, aby si organizace „vychovala“ vlastního takového člověka z interních zdrojů. V tomto případě se musí počítat s počátečními problémy, které se dají eliminovat dostatečným vzděláváním. Tento člověk by se měl nejprve podílet na menších projektech, aby získal potřebné zkušenosti. První lepší výsledky se mohou dostavit zhruba do půl roku. Při analýze by měla být identifikována rizika, která mohou ovlivnit realizaci projektu. Tato rizika by měla být zanesena do registru rizik. Tento registr bude slouţit jako vstupní dokument pro fázi realizace, během které bude průběţně aktualizován. Registr by neměl obsahovat pouze seznam moţných rizik, ale také popis reakcí či náhradních řešení pro případ jejich výskytu. Pro zajištění analýzy navrhuji zřídit funkční pozici byznys analytika na straně byznysu a jako protistranu z řad ICT stanovit hlavní osobu, která bude korigovat nebo případně upřesňovat poţadavky byznysu. Tyto dvě role by měly být základem analytického týmu, který by měl být ustanoven. Dalšími členy by měli být zástupci hlavního uţivatele a IT oddělení. Výstupem tohoto týmu by neměla být pouze analýza, ale také souhrn moţných dopadů na okolí včetně popisu moţných rizik. Identifikovaná rizika budou ohodnocena a zanesena do budoucího registru rizik projektu. Tato prvotní rizika by měla dát vzniknout registru rizik, který ve fázi plánování a realizace bude průběţně doplňován o rizika projektu.
41
4.4.
Tvorba obchodního případu a důkladná analýza
dopadů projektu Vytvořením obchodního případu se zjistí, zda je daný projekt v souladu s podnikovými cíli a strategií, zda realizovaný projekt bude mít plánované přínosy a zda je projekt realizovatelný za stávajících podmínek. Obchodní případ je předloţen vedení, které na jeho základě rozhodne, zda projekt přinese očekávané a poţadované přínosy a zda bude následně realizován či nikoliv. Z tohoto důvodu je nutné obchodní případ zpracovat velmi pečlivě a vzít v úvahu příslušné aspekty. Důleţitá pro přípravu projektu je analýza následných dopadů budoucího projektu. Tato analýza musí být nedílnou součástí přípravné fáze. Před samotnou realizací projektu je nutné, aby měl projektový manaţer dostatek informací o tom, jaké oblasti tento projekt bude ovlivňovat. Znalost negativních dopadů pak pomůţe projektovému manaţerovi určit takovou cestu realizace, aby tyto dopady byly co nejmenší. Analýza pomůţe také při formulaci a následném plánování činností v rámci projektu. Díky této analýze se podaří také lépe identifikovat zainteresované strany. Dále se zjistí návaznosti na další systémy nebo i projekty, které mohou být realizovány souběţně a mohou být plánovaným projektem ovlivněny. Dopady je nutné vztáhnout také k jiţ existujícím interním procesům organizace. Je potřeba analyzovat, zda nové řešení nebude mít za následek změnu stávajících interních procesů anebo dokonce nutnost vzniku nových procesů. Není nic horšího, kdyţ po úspěšném dokončení projektu nebude pro nové řešení připraveno prostředí organizace a výstupy z nového řešení nebude moţné dál vyuţívat. Tato situace vede pak na jakési zakonzervování nového řešení vzniklého dokončením projektu a tím na zvýšení rizika, ţe toto nové řešení nebude nikdy pouţito. Nejen ţe to povede na zbytečné plýtvání financí, ale také na plýtvání úsilí lidí. Bylo by velmi špatné, kdyby se po vykonané práci najednou zjistilo, ţe tato práce byla úplně zbytečná a pro výstupy z této činnosti by nebylo uplatnění. Toto zjištění vede na jakýsi druh frustrace všech, kteří se na projektu podíleli a s velkou pravděpodobností i na určitou nechuť se podílet na dalších budoucích projektech. Tento krok by měl přispět k rozšíření a upřesnění výstupů z analýzy poţadavků popsaných v kapitole 4.3.
42
4.5.
Zajištění kompetencí a organizační zabezpečení
Pro úspěšné řízení projektů je velmi důleţité, aby měl projektový manaţer potřebné kompetence a podporu ze strany vedení. Toho lze dosáhnout správným umístěním pozice projektového manaţera v organizační struktuře organizace. Vzhledem k tomu, ţe vedení projektu s sebou přináší i určité mnoţství administrativy, měl by mít projektový manaţer k ruce ještě další pomocníky. Nejlepším řešením tohoto problému nebo spíše této potřeby by bylo vytvoření oddělení pro vedení projektů nebo rovnou zřízení projektové kanceláře. Toto oddělení či kancelář musí být umístěna na takovém místě organizační struktury, které by zajišťovalo určité kompetence pro rozhodování v rámci řízení projektu. Nejlepší umístění projektového manaţera nebo projektové kanceláře v organizační struktuře je přímo pod ředitelem organizace. Tímto umístěním by byly získány odpovídající kompetence projektových manaţerů při vedení projektů a zaměstnanci by vnímali projektového manaţera jako vykonavatele vůle vedení. Jaké by vlastně měly tyto kompetence být? Zejména by to měly být kompetence pro dočasné řízení projektového týmu, který je sloţený z pracovníků z různých oddělení celé organizace. Příslušné kompetence by měly zajistit, aby případná rozhodnutí měla vyšší důleţitost a byla zavazující nejen pro členy projektového týmu, ale také pro jejich liniové vedoucí. Projektový manaţer by měl po dobu vedení projektu získat pravomoc vedoucích oddělení jednotlivých pracovníků z projektového týmu. Touto pravomocí se zajistí eliminace případných dohadů při zadávání úkolů mezi projektovým manaţerem a příslušným liniovým nadřízeným daného člena projektového týmu. Další neméně důleţitou kompetencí je moţnost práce s motivačními nástroji. Tato kompetence zajistí projektovému manaţerovi získat hybnou sílu pro ovlivňování výkonu jednotlivých členů projektového týmu. Samozřejmě pouze za předpokladu, ţe jsou tyto motivační nástroje v organizaci k dispozici. Pokud by tomu tak nebylo, je nejvyšší čas o tomto aspektu uvaţovat. Bez existence motivace není moţné řídit členy projektového týmu a tak dosahovat stanovených cílů. Je nutné si uvědomit, ţe členství v projektovém týmu lidé neberou jako odměnu, ale jako práci navíc nad svůj vymezený rámec své běţné pracovní činnosti. Tato práce navíc musí být nějak ohodnocena. V opačném případě nastanou případy, kdy pracovníci spíše pracují na svých běţných kaţdodenních úkolech, aby je splnili, a úkolům z projektu nevěnují velkou pozornost. To pak vede na pozdě odevzdávané výstupy mnohdy s horší kvalitou. To má za následek opakované přepracovávání těchto úkolů a tím i ztrátu tak 43
drahocenného času. V prostředí státní správy dost často bývá problém získat nějaké finance pro účely motivace. Motivační nástroje proto nemusí být pouze finančního rázu, ale také nefinančního. Jaké tyto nefinanční motivační nástroje mohou být, závisí na moţnostech příslušné organizace. Aby byl projekt úspěšný, je nutné jej také správně organizačně zabezpečit. V průběhu realizace projektu vzniká mnoho dokumentů. Dokumenty vznikají z jednotlivých schůzek a realizovaných aktivit. Tyto dokumenty je potřeba nějakým způsobem uchovávat, archivovat a zejména průběţně aktualizovat. Tyto dokumenty by měly nejen popisovat průběh projektu jako materiálu pro akceptační řízení a ukončení projektu, ale měly by také slouţit jako jakási studnice informací a znalostí pro budoucí projekty. Tyto praktické zkušenosti mohou být součástí nějaké znalostní báze. Dokumentace projektů, kterých jsem se přímo i nepřímo účastnil, je většinou zaměřena pouze na dokumenty, které byly důleţité pro akceptaci díla. U projektů, kde nebyl dodrţen plán a byly tak nějak „úspěšně“ ukončeny, není moţné s odstupem času zjistit, proč tomu tak bylo. Spolehnout se na paměť účastníků není moţné, protoţe lidé jednak zapomínají a jednak se jiţ nemusí v organizaci nacházet. Podobně tomu bylo i u analyzovaného projektu v předchozí kapitole. Nějaké informace lze sice získat z jednotlivých zápisů projektového týmu, ale tyto informace většinou bývají kusé. Například v případě řešení vzniklých konfliktů není moţné identifikovat příčinu, proč se daný konflikt řešil neúměrně dlouho. Jako jedno z moţných řešení by bylo udrţovat jakousi databázi jednotlivých eskalací vzniklých v průběhu projektu. Eskalace nevznikají pouze v případě konfliktů, ale také například při potřebě schválit změnu v rámci změnového řízení. Jak jiţ bylo uvedeno výše, součástí této databáze by měly být určité informace (popsáno v kapitole 4.2). Tato databáze by měla být přístupná vedení organizace, aby mohlo v případě nějakého se rýsujícího prodlení adekvátně projekt podpořit. Tato databáze můţe být ve formě obyčejného sešitu ve formátu MS Excel nebo to můţe být i sofistikovanější nástroj, který by spolu s ostatními nástroji projektového řízení vedení těchto projektů podporoval. Pro vedení projektů je potřeba zajistit kvalitu samotného projektového manaţera. Kvalita úrovně znalostí projektového manaţera se nedá naučit, ale získat na základě praktických činností. Proto je velmi důleţité, aby byl projektový manaţer neustále a pravidelně vzděláván. Vzhledem k tomu, ţe se oblast projektového řízení neustále mění a kaţdý projekt je jedinečný a neopakovatelný, nestačí pouze nechat vyškolit a certifikovat nového projektového 44
manaţera, ale je potřeba jej neustále dále rozvíjet. V rámci organizace by měl existovat plán vzdělávání pro získávání dalších znalostí z této oblasti. Nejedná se pouze o vzdělávání v oblasti řízení projektů, ale také v oblasti komunikace a jednání s lidmi. Na tento fakt by se nemělo zapomínat. Pro řízení projektů není důleţitá pouze znalost procesů, které musí být provedeny, ale zejména oblast komunikace a práce s lidmi.
4.6.
Plánování projektových zdrojů a řízení portfolia
projektů Plánování zdrojů pro projekt je velmi důleţité. Během přípravy projektu je sice na tento aspekt pamatováno, ale v globálním kontextu organizace je jiţ toto opomíjeno. V organizaci často nebývá realizován jen jeden projekt. Je realizováno několik projektů současně. Na těchto projektech ale většinou pracují stejní lidé. Můţe se tak stát, ţe v jednu chvíli jeden člověk je v několika týmech a některé úkoly z těchto týmů se setkají. Není pak moţné všechny úkoly dodat včas. Tento stav je způsoben absencí řízení portfolia projektů. Aby bylo předcházeno těmto situacím, je nutné tuto činnost v organizaci zavést. Je nutné znát nejen jak naplánovat zdroje, ale také souvislost jednotlivých projektů. Tato činnost zajistí, ţe nenastane stav, kdy je jeden projekt těsně před dokončením, ale vzhledem k tomu, ţe má vazbu na jiný projekt, který stále běţí a jeho dokončení ještě chvíli potrvá, jej není moţné předat a zavést do běţného provozu. Takový projekt se stává neakceptovatelným a nelze jej ukončit v plánovaném termínu. Pro zajištění schvalování a plánování projektů musí být ustanoven projektový výbor. Členy projektového výboru by měly být pracovníci na nejvyšších postech v organizaci, dále hlavní projektový manaţer nebo vedoucí projektové kanceláře. Ten by byl odpovědný za řízení portfolia projektů a v případě identifikovaných problémů při plánování realizace projektů by měl na tyto problémy výbor upozornit. Součástí komunikace s výborem by měly být i návrhy moţného náhradního řešení. Výbor by následně měl vybrané řešení schválit. Řízení portfolia projektů je spíše zaměřeno na strategické cíle organizace. Zajišťuje výběr těch „správných“ projektů se zajištěnými zdroji k realizaci v souladu s cíli organizace.
45
4.7.
Průběţné sledování, vyhodnocování a řízení rizik
projektu Projekt je nutné průběţně sledovat. Sledování není důleţité pouze na úrovni projektového manaţera, ale také ze strany vedení. V rámci projektu jsou určeny milníky v jednotlivých etapách. Při dosaţení takového milníku, by se mělo udělat jakési „zastavení“ a následná analýza dosud provedených činností. Analýza by měla zejména slouţit pro sumarizaci realizovaných činností, porovnání s plánem projektu a vyhodnocením aktuálního stavu projektu. Výstupy z analýzy mohou být i nově identifikovaná rizika nebo naopak zánik některých stávajících rizik. Informace z analýzy by měly být shrnuty do stručného popisu stavu projektu. V dokumentu by měly být zaneseny zejména klíčové a majoritní body. V případě řízení rizik je nutné si uvědomit rozdíl mezi rizikem a problémem. Riziko je něco, co by mohlo nastat a je dobré se na tato rizika předem připravit. Problém je naopak něco, co jiţ nastalo a je nutné to bez odkladu řešit. Řízení a monitorování rizik bývá velmi často v projektech opomíjeno. Přitom je to jedna z nejdůleţitějších částí v ţivotě projektu, která má podstatný vliv na jeho úspěšnost. Řízení rizik nespočívá pouze v identifikaci potenciálních rizik, ale také v jejich analýze a následném monitorování a vyhodnocování. V etapě analýzy by měla být identifikována rizika. Tato identifikace by měla spočívat v prvé řadě v prostudování jiţ realizovaných projektů. Projekty jsou sice unikátní a neopakovatelné, ale rizika se vyskytují v kaţdém projektu a do jisté míry lze konstatovat, ţe jsou velmi podobná s ohledem na prostředí organizace. Problémem můţe být jak tato rizika identifikovat. Studiem dokumentů z jiţ realizovaných projektů lze nějakou informaci získat, ale pokud v minulých projektech tato rizika řízená nebyla, tak to můţe být obtíţné. V tomto případě by se měl projektový manaţer obrátit na někoho, kdo se účastnil některých realizovaných projektů v minulosti. Nicméně i zde hrozí, ţe informace od dané osoby mohou být subjektivní a většinou tomu tak bývá. Je pak na projektovém manaţerovi, jak s takto získanými informacemi naloţí. Identifikovaná rizika by měla být zanesena do registru rizik. Jako moţné řešení do budoucna by se měl vytvořit jakýsi centrální registr rizik, který by byl průběţně aktualizován na základě realizace jednotlivých projektů. Existence takového registru by v budoucnosti mohla projektovému manaţerovi velmi pomoci při identifikaci rizik souvisejícími s organizační strukturou příslušné organizace. 46
Ve druhé fázi by měla být jednotlivá rizika analyzována. V rámci této analýzy se do registru rizik doplní další informace jako popis rizika, jeho příznaky, pravděpodobnost výskytu, vlastník daného rizika, postup pro jeho eliminaci nebo sníţení, stav rizika a další. Jednotlivá rizika by měla být obodována dle jejich závaţnosti a na základě tohoto hodnocení by jim měla být přidělena příslušná priorita. V případě, ţe riziko nastane a je nutný zásah, by měl být kontaktován vlastník rizika s ţádostí o provedení příslušného zásahu. Pro tento účel by mohl být vyuţit jiţ navrhovaný eskalační mechanismus. Ze záznamů tohoto mechanismu je pak moţné zjistit, kdy byl problém eskalován a zda se jím daný vlastník skutečně zabýval. V průběhu monitorování by měla být prováděna pravidelná kontrola rizik dle vytvořeného registru rizik. Některá rizika mohou během realizace zaniknout a naopak jiná se mohou nově vyskytnout. Monitorování rizik by měl aktivně provádět celý projektový tým. Všechny změny a události by měly být zaznamenávány do registru rizik včetně vyskytnutých problémů a jejich následného řešení.
4.8.
Ukončení projektu a předání do provozu
Poslední fáze projektu je neméně důleţitá. Výstupy z projektu musí být předány hlavnímu uţivateli k běţnému uţívání, aby mohl být celý projekt ukončen. Přípravu na tuto fázi je proto nutné udělat při plánování projektu. Aby bylo dílo řádně předáno, je nutné stanovit ta správná akceptační kritéria včetně plánu samotného předání výstupů z projektu. Tento plán je pak nutné aktualizovat těsně před závěrečnou fází projektu. Jedině tak je moţné připravit bezproblémové předání výstupů z projektu hlavnímu uţivateli. V rámci závěrečné revize je nutné nejen plán aktualizovat, ale také zhodnotit, které činnosti je potřeba ještě provést a je tedy nutné zajistit jejich dokončení. Vzhledem k tomu, ţe všichni členové projektového týmu jiţ vidí ukončení projektu v dohledné době, můţe klesat kvalita jejich odváděné práce. Je nutné i v této fázi jim připomenout důleţitost projektu a tím zajistit jejich plné nasazení aţ do ukončení projektu. Také zájem zainteresovaných stran s rostoucí délkou trvání projektu pomalu, ale jistě klesá. Je proto před samotným předáním výstupů projektu zajistit zvýšení pozornosti těchto stran. Jak jiţ bylo uvedeno výše, je nutné při plánování stanovit „správná“ akceptační kritéria. Tato kritéria by v lepším případě měla být jednoduše měřitelná. V případě stanovení subjektivních kritérií mohou nastat při předávání nečekané problémy. Důvodem je právě uvedená 47
subjektivita. Na začátku projektu mohla být situace jiná a stanovená kritéria odpovídala právě této situaci. V době ukončení projektu se mohla situace v organizaci výrazně změnit (například změna vedení) coţ následně můţe mít výrazný vliv na tuto fázi. Výstupy z projektu se tak mohou stát neakceptovatelnými. Je proto vhodné se těmto typům akceptačních kritérií velkým obloukem vyhnout. Pro předání výstupu z projektu je potřeba nejen připravit akceptační kritéria, ale také naplánovat samotný průběh předávání těchto výstupů. Tento plán by měl být odsouhlasen všemi zainteresovanými stranami. Obsahem takového plánu můţe být postup testování výstupů, předání dokumentace k výstupům, závěrečná zpráva z projektu, zaškolení uţivatelů apod. Kritickou částí předávání můţe být testování výstupů projektu. Zejména se jedná o testování nové aplikace. Pokud není zajištěna přítomnost hlavního uţivatele po celou dobu projektu, můţou v této závěrečné etapě nastat určité spory. Neţ se začne se samotným testováním aplikace, je nutné, aby hlavní uţivatel aplikace vybral uţivatele, kteří budou testování provádět. Projektový tým by měl následně připravit schválené testovací scénáře a před samotným testováním by mělo proběhnout důkladné proškolení uţivatelů, kteří budou testování realizovat. V rámci tohoto školení je potřeba tyto uţivatele seznámit s cíli a dopady projektu na organizaci. Uţivatele je nutné upozornit na důleţitost testování ve vztahu k celému projektu. Tímto způsobem si projektový manaţer zajistí dostatečnou pozornost těchto uţivatelů a tím i vysokou úroveň kvality samotného testování. Výstupem předání by měl být podepsaný závěrečný akceptační protokol. Aby mohl být podepsán, musí být podepsány všechny dílčí akceptační protokoly. To v případě, ţe během všech fází projektu vzniknou výstupy, které musí být před zahájením další fáze předány a schváleny. Příkladem můţe být ve státní správě velmi často poţadovaná vstupní analýza z důvodu absence znalostí v dané oblasti u pracovníků organizace. Teprve po schválení vstupní analýzy je moţné zahájit samotnou realizaci projektu. Pro závěrečné setkání všech zainteresovaných stran pro účely předání výstupů z projektu je nutné si zajistit účast všech příslušných osob. Na tomto setkání se nejen budou podepisovat závěrečné předávací protokoly, ale také bude probíhat hodnocení celého projektu. Pro zajištění objektivnosti tohoto hodnocení se musí vyjádřit všichni, kdo se projektu účastnili. Následně po předání výstupů z projektu začíná poslední etapa - poprojektová fáze. V rámci této etapy je nutné uzavřít zejména administrativu, provést závěrečné zhodnocení realizace
48
projektu a vyřešení všech eventuálních sporů. Všechny vytvořené dokumenty projektu jsou archivovány. Teprve následně je moţné vystavit závěrečnou fakturu.
Závěrečné shrnutí Projektové řízení v prostředí státní správy má svá určitá specifika, která jsou způsobena prostředím samotné státní správy a příslušných zákonných předpisů. Z tohoto důvodu je nutné s těmito specifiky počítat při realizaci projektů. Především se jedná o povahu veřejných soutěţí. V těchto soutěţích se vítězem stává nabídka s nejniţší cenou. Ve většině případů je ale nízká cena vykoupena horší kvalitou. Vzhledem k tomu, ţe v rámci poptávky je většinou poţadováno i provedení kompletní vstupní analýzy, je právě tato analýza dosti často provedena v niţší kvalitě a záběru neţ by se očekávalo. V tomto případě je nutná plná spolupráce zaměstnanců organizace s dodavatelem projektu. Toto ovšem bývá někdy poměrně problematické z důvodu neodpovídající úrovně znalostí těchto pracovníků. Je proto nutné, aby organizace zajistila neustálý rozvoj těchto znalostí formou trvalého vzdělávání příslušných zaměstnanců. Projekty jsou primárně řízeny právě těmito zaměstnanci organizace. Vstupní analýza je základem kvalitně řízeného projektu a jeho úspěšného zakončení. Výstupy z analýzy musí být odsouhlaseny všemi zúčastněnými. Bez souhlasu by se nemělo pokračovat dále. Této přípravné fázi by měla být věnována dostatečná pozornost. Dalším nedostatkem řízení projektů v tomto prostředí je neustálý tlak vedení organizace na co nejrychlejší realizaci projektu. Časový harmonogram se musí stanovit adekvátně a zodpovědně v souvislosti s cíli projektu. Umělé zkracování termínů vede na nedostatečnou implementaci a nedostatečné následné testování vede na výrazné sniţování kvality výstupů projektu. Aby bylo moţné důkladně testovat, musí IT oddělení organizace zajistit adekvátní testovací prostředí před samotným testováním. Aby se mohlo řádně testovat, musí být důkladně připravené testovací scénáře. Během realizace projektu velice rychle klesá zájem vedení organizace. Projektový manaţer musí zajistit trvalý zájem vedení, aby bylo moţné v případě nutnosti strategického rozhodnutí, rozhodnout co nejrychleji. Aby toho mohl docílit, musí být jeho postavení v organizační struktuře organizace na adekvátním místě. Lepším řešením je vytvoření oddělení projektové kanceláře, která bude umístěna na co nejvyšším místě v organizační struktuře. Tím bude zajištěna autorita jejích projektových manaţerů vůči 49
všem zaměstnancům. Členové projektového týmu se musí ztotoţnit s cíli projektu. Jedině tak je moţné zajistit dodávku kvalitních výstupů během celé realizace. Během realizace by měly být sledovány identifikovaná rizika, aby bylo moţné adekvátně na ně reagovat včas a s co nejmenší časovou ztrátou. V závěrečné fázi je nutné před samotným předáním výstupů projektu seznámit uţivatele důkladně s cíli projektu a záměry vedení organizace v souvislosti s cíli organizace. Výstupy projektu by měly být předány hlavnímu uţivateli, který je určený na začátku projektu. Etapa předání je jednou z nejdůleţitějších etap projektu. Před samotným předáním je nutné zajistit důkladné proškolení uţivatelů v pouţívání výstupů projektu a to zejména pokud je tímto výstupem nová aplikace. Lze očekávat, ţe právě ve fázi předání aplikace do provozu bude rezistence uţivatelů velmi vysoká. Důvodů je hned několik od nutnosti se učit něco nového aţ po obavu ze ztráty zaměstnání z důvodu zjednodušení a zefektivnění stávajících procesů organizace. Na základě zjištění navrhuji pro zlepšení projektového řízení v organizacích státní správy následující: zřízení projektové kanceláře a její umístění do nejvyšších míst v organizační struktuře organizace, v případě jiţ její existence zajistit její adekvátní umístění v organizační struktuře, před zahájením projektu připravit a realizovat minimálně 2 workshopy pro prezentaci cílů a záměrů projektu – jeden workshop pro „široký“ okruh zaměstnanců a druhý pro členy projektového týmu, v rámci projektu zřídit dočasně nebo trvale roli byznys analytika, která bude shromaţďovat poţadavky byznysu do ucelených celků a vytvářet analýzu poţadavků, zajistit si podporu vedení pro projekt včetně dostatečného mnoţství motivačních prostředků pro členy projektového týmu, ve fázi plánování vytvořit registr rizik a následně jej při realizaci projektu průběţně aktualizovat, včasné zajištění adekvátního testovacího prostředí pro testování výstupů projektu a zajistit, aby testování prováděli zejména budoucí uţivatelé výstupů projektu, vytvořit nástroj pro podrobnou evidenci eskalací pro dokumentaci případných problémů,
50
vytvořit centrální registr rizik, který by byl průběţně aktualizován v souvislosti s realizovanými projekty, vytvořit databázi známých problémů, které se vyskytly během realizace projektů, jako znalostní bázi pro budoucí projekty, zajistit dostatečné školení pro budoucí uţivatele výstupů projektu a tím zajistit prostředí pro jejich bezproblémové předání v závěrečné fázi projektu. Výše jsou popsány nejdůleţitější aspekty, na které by si měl projektový manaţer z řad zaměstnanců státní organizace dávat pozor. Uvedené by mu mělo pomoci dovést projekt úspěšně do zdárného konce v prostředí státní organizace. Projektový manaţer musí ale disponovat obecnými znalostmi z oblasti projektového řízení. Tyto znalosti můţe získat pomocí některých kurzů zakončenými certifikační zkouškou dle příslušné metodiky. Postupem času a realizací dalších projektů lze získat potřebné zkušenosti v tomto prostředí a tím zlepšovat kvalitu realizovaných projektů. Tyto zkušenosti je dobré trvale uchovávat v centrálním úloţišti znalostí jako např. formou nějaké databáze. Projekty jsou sice různé a neopakovatelné, ale problémy, které při jejich realizaci vznikají, jsou velmi podobné.
51
Pouţitá literatura [1] SCHWALBE K., Řízení projektů v IT - Kompletní průvodce, Brno: Computer Press, 2011. ISBN 978-80-251-2882-4 [2] ŠTEFÁNEK R., BOČKOVÁ K. H., BENDOVÁ K., HOLÁKOVÁ P. a MASÁR I., Projektové řízení pro začátečníky, Brno: Computer Press, 2011.ISBN 978-80-251-2835-0 [3] CHVALOVSKÝ V., Řízení projektů aneb překážkový běh na dlouhou trať, Praha: ASPI, 2005. ISBN 978-80-7357-085-9 [4] BARKER S. a COLE R., Projektový management pro praxi, Praha: Grada Publishing, 2009. ISBN 978-80-247-2838-4 [5] VITOUS M., Praktické řízení projektů - materiál ze školení, Praha: GOPAS, 2013. [6] TSO - The Stationery Office, Managing Successful Project with Prince2, London: OGC, 2009. ISBN 978-0-11-331059-3
Seznam obrázků Obrázek 1 - Projektový trojimperativ, zdroj: autor ................................................................................. 8 Obrázek 2 - Ganttův diagram - příklad, zdroj: autor[SW_1] ................................................................ 15 Obrázek 3 - Síťový graf s vyznačením kritické cesty - příklad, zdroj: [INT_1] ................................... 16 Obrázek 4 - Hierarchická struktura - příklad, zdroj: autor[SW_2] ....................................................... 19 Obrázek 5 - Maticová struktura - příklad, zdroj: autor[SW_2] ............................................................. 21
Internetové zdroje [INT_1] Citace. V: Wikipedie: Otevřená encyklopedie [online], Praha, poslední modifikace: 16.3.2013 [cit. 12.4.2014]. Dostupné z: http://cs.wikipedia.org/wiki/Kritick%C3%A1_cesta [INT_2] Citace. V: Wikipedie: Otevřená encyklopedie [online], Praha, poslední modifikace: 15.2.2014 [cit. 12.4.2014]. Dostupné z: http://cs.wikipedia.org/wiki/PMBOK_Guide
52
[INT_3] Citace. V: Prince2 Courses and Certification for Project Management [online], Praha, poslední modifikace: 2014 [cit. 12.4.2014]. Dostupné z: http://www.prince2.com/europe/training
Pouţité SW nástroje [SW_1] Microsoft Project Standard 2010, http://www.microsoft.com [SW_2] Aris Express, http://www.ariscommunity.com/aris-express
53
