UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

UNICORN COLLEGE

Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE

Řízení IT projektů v prostředí telekomunikačního operátora

Autor BP: Miroslav Svoboda Vedoucí BP: Ing. Miloš Dvořák

2013 Praha

Cestné prohlášení Prohlašuji, že jsem svou bakalriřskou práci na téma ŘízeníIT projektů v prostředí telekomunikačníhooperátora lrypracoval samostatně pod vedením vedoucího bakalářské práce a s použitim qýhradně odbomé literatury a dalšíchinformačníchzdrojů, které jsou v práci citovrány a jsou také uvedeny v s eznamu literatary a

použi|ých zdrojů.

Jako autor této bakalářské práce dále prohlašuji, že v souvislosti sjejím vytvořením jsem neporušil autorská práva třetích osob ajsem si plně vědom následků porušení ustanovení § 11 a následujících autorského záy'<.ona é. 12112000 Sb.

v

praze dne

q.8,2a43 Miroslav svoboda

Poděkování Děkuji vedoucímu bakalářské práce Ing. Miloši Dvořákovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Řízení IT projektů v prostředí telekomunikačního operátora Telecommunications IT Projects management

5

Abstrakt Tématem mé bakalářské práce je řízení IT projektů v prostředí telekomunikačního operátora. V rámci práce jsou v teoretické části popsány jednotlivé aktivity projektového řízení tak, jak je popisuje PMBOK® ve svém čtvrtém vydání. Dále jsou zde popsány okolní procesy a služby definované v ITIL® což je metodika používaná pro tyto procesy u českých telekomunikačních operátorů. V praktické části vycházím z procesů a aktivit definovaných PMBOK® a nastavuji tyto procesy a aktivity vhodně pro telekomunikačního operátora s důrazem na iniciační fázi projektu a jeho průběžné schvalování až do fáze realizace, ve které je projekt implementován. Důraz na iniciační fázi kladu hlavně z důvodu možnosti upravovat vstupní parametry projektu před vlastní realizací, a tím tak reagovat na měnící se podmínky na trhu. Součástí mé práce je definování nezbytných výstupů pro úspěšnou realizaci projektu a začlenění projektového řízení do okolních procesů. Klíčová slova: PMBOK®, ITIL®, projektový management, projektový manažer, demand management, capacity management, release management, knowledge management, operation and support.

6

Abstract In my thesis I decided to focus on management of IT projects in the environment of telecommunication operator. In the theoretical part I describe individual activities of project management as they are described in the 4th edition of PMBOK®. Further I describe surrounding processes and services defined in ITIL®, method used for these processes in the environment of Czech telecommunication operators. In the practical part I build on the processes and activities defined by PMBOK® and I set up these for the environment of telecommunication operator with emphasis on the initiation phase and continuous approvals until the implementation phase. I emphasize this phase mainly due to having more chance to adjust the project before the implementation and thus quickly react to the changing conditions on the market. Definition of outputs necessary for successful implementation of the project and project management incorporation to surrounding processes are part of my thesis too. Keywords: PMBOK®, ITIL®, project management, project manager, demand management, capacity management, release management, knowledge management, operation and support.

7

Obsah Abstrakt

6

Abstract

7

Obsah

8

1

Úvod a záměr

11

2

Teoretická část

13

2.1

Role

13

2.2

Projektový trojimperativ (Rozsah, náklady, čas)

14

2.2.1

Řízení rozsahu

14

2.2.2

Řízení času

14

2.2.3

Řízení nákladů

14

Popis okolních procesů

15

2.3

2.3.1

Demand management

15

2.3.2

Knowledge management

15

2.3.3

Release management

16

2.3.4

Capacity management

16

2.3.5

Operation and Support

16

Proces projektového řízení

16

2.4

2.4.1 2.5

Modely organizačních struktur zahrnujících řízení projektů

Projektová kancelář

17 21

2.5.1

Funkce definiční

22

2.5.2

Funkce kontrolní

22

2.5.3

Funkce realizační

22

2.5.4

Funkce podpůrná

22

2.6

Realizace projektu

22

2.6.1

Iniciace a zahájení projektu

23

2.6.2

Plánování projektu

23 8

3

2.6.3

Vlastní realizace projektu

25

2.6.4

Monitoring a kontrola projektu

26

2.6.5

Uzavření projektu

28

Praktická část 3.1

30

Specifika telekomunikačního operátora

30

3.1.1

Rozdělení organizace

30

3.1.2

Typy projektů

31

3.2

Výběr organizačního modelu

32

3.3

Popis procesu řízení IT projektů

34

3.4

Organizační struktura

34

3.4.1

Odpovědnosti:

35

3.4.2

Pravidelné aktivity:

36

3.4.3

Identifikace projektů

37

3.5

Projektové aktivity

38

3.5.1

Příprava projektu – iniciační fáze

39

3.5.2

Schválení projektu do realizace – iniciační fáze

40

3.5.3

Zahájení projektu – iniciační fáze

41

3.5.4

Analytická příprava projektu – fáze plánování

42

3.5.5

Návrh architektury – fáze plánování

43

3.5.6

Opětovné schválení projektu – fáze plánování

44

3.5.7

Vlastní implementace – fáze realizace

45

3.5.8

Testování – fáze realizace

46

3.5.9

Nasazení – fáze realizace

47

3.5.10

Předání do provozu – fáze uzavření projektu

48

3.5.11

Ukončení projektu – fáze uzavření projektu

49

Začlenění procesu řízení IT projektů do svého okolí

50

3.6

3.6.1

Demand management

50 9

3.6.2

Knowledge management proces

50

3.6.3

Release management

50

3.6.4

Capacity management

50

3.6.5


51

3.7

Zhodnocení nejvhodnější varianty řízení IT projektů pro telekomunikačního

operátora

52

4

Závěr

53

5

Seznam použitých zdrojů

54

6

Seznam obrázků

55

7

Seznam tabulek

56

10

1 Úvod a záměr Tématem mé bakalářské práce je návrh nejvhodnějšího přístupu pro IT projektové řízení v prostředí telekomunikačního operátora. Vzhledem k dynamickým změnám v produktovém portfoliu a strategii telekomunikačních operátorů s ohledem na konkurenční boj je nezbytné veškeré požadavky na úpravy IT systémů řešit rychleji než v jiných odvětvích. V rámci této práce jsem navrhl přístup pro projektové řízení, který vychází z často používaných metodik pro řízení IT projektů (PMBOK, ITIL). Přístup vycházející z uvedených metodik byl upraven podle specifických parametrů, které se vyskytují v prostředí telekomunikačních operátorů. Nejvýznamnějšími specifiky telekomunikačních operátorů jsou požadovaná rychlost úprav a velké množství zapojených systémů. Nelze opomenout také obvyklé rozdělení IT telekomunikačního operátora na část zabývající se telekomunikačními systémy a zákaznickými systémy, kde tyto části u telekomunikačního operátora jsou striktně organizačně odděleny. Záměrem mé práce je tedy navržení nejvhodnějšího přístupu a následně začlenění procesů IT projektového řízení do okolních procesů, které s IT projektovým řízením úzce souvisejí. Okolními procesy rozumím zejména Demand management, Release management, Knowledge management, Operation and Support a Capacity management. Obr. č. 1 – Záměr práce

Zdroj: Vlastní zdroj

11

V teoretické části práce jsou shrnuty přístupy pro projektové řízení z již zmiňovaných metodik, kde se zaměřuji na vlastní proces řízení projektů a jeho začlenění do okolí. V praktické části práce následně vybírám vhodné přístupy pro jednotlivé části projektového řízení a navrhuji proces, který zabezpečí efektivní řízení projektů u telekomunikačního operátora. Definuji zde potřebné výstupy, odpovědnosti a časování jednotlivých kroků celého procesu projektového řízení a zasazuji jej do rámce okolních procesů.

12

2 Teoretická část V této části shrnu možné pohledy řízení projektů v IT. Nejdříve si musíme říci, co vlastně chápeme pod pojmem projekt. “Projekt lze charakterizovat jako časově omezenou snahu vytvořit jedinečný produkt, službu či výsledek. Informační projekt zahrnuje použití hardwaru, softwaru a-nebo sítí. Projekty jsou jedinečné, časově omezené, vytvářené postupně krok za krokem. Vyžadují zdroje, mají sponzora a jejich nedílnou součástí je nejistota. Projektový trojimperativ se vztahuje k řízení tří dimenzí projektu – rozsahu, času a nákladů.“ [1, s. 49] Tato uvedená definice projektu popisuje projekt s ohledem na řízení rozsahu, času a nákladů. Tyto tři dimenze chápu jako nejdůležitější součást projektového řízení. Budu se jim tedy věnovat i nadále a budou společným prvkem pro celou práci. „Je tedy nutné v rámci projektu uvažovat o rozsahu projektu, tj. jaký produkt je vlastníky či sponzory projektu očekáván. Dále je nutné zvážit, jak dlouho by měla práce na projektu trvat, jakým způsobem bude projekt monitorován, kdo bude schvalovatelem změn. A v neposlední řadě jaký je rozpočet projektu a jak budou náklady sledovány.“ [1, s. 23]

2.1 Role V předchozích odstavcích již bylo zmíněno několik zainteresovaných rolí, popíšeme je tedy blíže. „Sponzor – řeší problémy v oblasti finanční a v oblasti dodržení celkové koncepce informační strategie v rámci organizace. Kromě toho řeší celou řadu dalších úkolů, které jsou organizačního a koordinačního typu. Sponzor komunikuje jak s řešitelem, kde má vliv na globální otázky budování informačního systému (co a za kolik), tak i s Uživatelem a Objednatelem.“ [2, s.48] „Zadavatel – sestavuje podle pokynů a instrukcí od Sponzora zadání projektu a na základě představy o budoucí funkčnosti systému objednává takový systém od Dodavatele.“ [2, s.48] Je třeba rozlišovat běžného a klíčového uživatele. „Běžný uživatel se podílí na formulaci vlastního zadání vybrané funkcionality systému, výběru řešitele, objednávce systému resp. jeho určité části, kdy připomínkuje nabídky uchazečů o dodávku, i na vlastním řešení, kdy

13

konzultuje, spolupracuje s dodavatelem a případnými ostatními partnery na projektu.“ [2, s.48] „Klíčový uživatel má největší znalosti s během určité věcné oblasti ve firmě, je odborným garantem určité oblasti a zodpovídá za její realizaci na projektu, v průběhu komunikuje s Dodavatelem projektu o věcném řešení příslušné oblasti, účastní se školení pořádaných Dodavatelem a na jejich základě sám nebo ve spolupráci s Dodavatelem zaškoluje běžné uživatele, je pro ně guru dané oblasti.“ [2, s.48] „Manažer projektu řídí projekt za stranu Objednatele. Představuje za stranu Objednatele nejvyšší autoritu.“ [2, s.48] Dále na projektu spolupracují další členové projektového týmu - jedná se o pracovníky na projektu, kteří plní přidělené úkoly a předávají informace o plnění těchto úkolů projektovému manažerovi. Předávání informací obvykle probíhá dle velikosti týmu buď přímo, nebo u větších týmu přes vedoucí jednotlivých subtýmů.

2.2 Projektový trojimperativ (Rozsah, náklady, čas) V této kapitole se seznámíme s běžnými nástroji a technikami projektového řízení vedeného podle projektového trojimperativu. Níže uvedené informace vycházejí zejména z metodiky PMBOK®. 2.2.1

Řízení rozsahu

Běžnými nástroji a technikami pro řízení rozsahu jsou zejména deklarace rozsahu projektu, hierarchická struktura prací (známá jako WBS – work breakdown structure), definice cílů a rozsahu prací (známá jako SOW – Statement of Work) a v neposlední řadě analýza požadavků. 2.2.2

Řízení času

Pro řízení času jsou obvykle používány Ganttovy diagramy, metody síťové analýzy, metoda kritické cesty, crash analýza, metoda fast tracking a metody monitorování projektu z hlediska času. 2.2.3

Řízení nákladů

Řízení nákladů je řešeno pomocí Čisté současné hodnoty (NPV – net present value), návratnosti investice (ROI – return on investment), analýzy návratnosti, řízení získané hodnoty, odhady nákladů a plánování nákladů. 14

Dále je nutné v každém projektu řešit podpůrné oblasti, jejichž cílem je ve výsledku řízení rozsahu, času a nákladů. Jedná se o řízení kvality, řízení lidských zdrojů, řízení komunikace, řízení rizik a řízení dodávek. Začlenění projektu do okolních procesů se budeme věnovat v následující kapitole.

2.3 Popis okolních procesů U telekomunikačních operátorů na českém trhu jsou dále uvedené procesy řešeny pomocí ITIL®, což je zkratka pro IT Infrastructure Library®. Jedná se o sadu knih popisujících nejlepší praktiky správy služeb IT. Z mého pohledu pro navržení vhodného procesu projektového řízení je nutné blíže popsat následující procesy: •

Demand management

•


•

Release management

•

Capacity management

•


2.3.1

Demand management

„Správa požadavků (Demand management) představuje spojení mezi obchodními aktivitami a poskytováním služeb. Je to proces, který se snaží pochopit, předpovídat a řídit požadavky zákazníka, aby včas a hospodárně zajistil kapacity pomocí správy kapacit (Capacity management). Jak nadbytek kapacit, tak i špičky v poptávce vytváří pro obě strany – zákazníka i poskytovatele služeb – negativně vnímanou situaci. Ve spolupráci se zákazníkem by mělo plánování, analýza trendů, dohoda o úrovni služeb (SLA) a řízení snížit nejistotu a výkyvy v poptávce.“ [3, s.55] 2.3.2


„Aby bylo možné činit správná rozhodnutí ve správnou chvíli, je potřeba mít k dispozici rychle, přesně a srozumitelně podané informace – znalosti – ve správný čas na správném místě a v potřebné kvalitě. Tento proces zajišťuje, aby byly během životního cyklu služby k dispozici spolehlivé a bezpečné informace. Tyto informace jsou důležité pro správné vyhodnocení situací a kontextů. Úvahy o podpoře rozhodování a zprostředkování informací zahrnují identifikaci zainteresovaných stran, akceptovatelné úrovně rizika a očekávané výkonosti a tím i zdroje a harmonogramy.“ [3, s.139] 15

2.3.3

Release management

„Správa releasů a provozního nasazení plánuje a řídí sestavení (Build), testování a umístění (Deployment) release. Stará se, aby zákazník dostal službu tak, jak byla koncipována v návrhu služby, a aby ji zákazník mohl využívat, což pro něj tvoří hodnotu.“ [3, s.125] 2.3.4

Capacity management

„Správa kapacit je ústředním orgánem pro všechny aspekty služby a zdrojů týkajících se kapacity a výkonnosti. Z fáze strategie služeb mají význam ta rozhodnutí a analýzy obchodních požadavků, které mají vliv na vývoj vzorců obchodních aktivit a na varianty služby. Ty pak ovlivňují požadavky na kapacity služby.“ [3, s.90] 2.3.5


Tato služba se dále dělí na dvě části. Na vlastní správu provozu IT a na správu aplikací. Týmy pro tyto aktivity jsou oddělené. „Pojem Správa provozu IT popisuje oddělení, skupinu nebo tým, který provádí běžné denní činnosti, které jsou potřeba pro správu služeb IT a podporu infrastruktury IT. Úkolem této funkce je udržovat současnou stabilitu infrastruktury IT a konzistentnost služeb IT.“ [3, s.73] „Funkce správy aplikací je zapojena ve všech oblastech, ve kterých jde o správu a podporu provozních aplikací. Správa aplikací je zodpovědná za řízení aplikací po celou dobu jejich životního cyklu. Hraje ale také roli při návrhu, testování a zlepšování aplikací v rámci služeb IT. Správa aplikací je pro aplikace tím, čím je technická správa pro infrastrukturu IT.“ [3, s.175]

2.4 Proces projektového řízení V předchozích kapitolách jsem vymezil projekt, projektový trojimperativ, s rozpadem pohledů na řízení rozsahu, času a nákladů, a dále jsem popsal okolní procesy a služby se kterými projektové řízení spolupracuje v průběhu realizace projektu. V této kapitole se seznámíme s možným popisem organizace projektového řízení. Vhodně zvolený model organizace projektového řízení je jedním z klíčových faktorů, který rozhoduje o efektivitě a úspěšnosti dosahování jednotlivých cílů společnosti.

16

2.4.1

Modely organizačních struktur zahrnujících řízení projektů

„V závislosti na typu organizace, poměru úsilí věnovanému mezifunkčním aktivitám (projektům, programům) a dalších faktorech (např. komplexnost a rozsah projektů) je vhodný určitý způsob organizačního uspořádání, v němž může koexistovat trvalá a dočasná organizační struktura (projekt).“[4, s.455] „Mezi trvalou organizací a dočasnou, projektovou strukturou je nezbytné definovat určitá rozhraní a vazby, které umožní tok informací, koordinaci a řízení.“ [4, s.455] Je tedy možné uvažovat o několika druzích organizačního uspořádání a řízení. Jedná se o následující typy. 2.4.1.1 Útvarové projektové řízení „Tento model nevytváří požadavky na změny ve stávající organizační struktuře, jeho aplikace je tedy vhodná pro řízení menších projektů, které mohou být realizovány v rámci jednoho oddělení v podniku. Základním principem je konání pravidelných pracovních porad koordinačního charakteru pracovníků, kteří se na projektu podílejí, jinak ale zůstávají na svých stálých liniových pozicích a jsou řízeni prostřednictvím svých liniových vedoucích.“ [4, s.456] „Tato forma organizace je obvykle zaměřena na trvalé zachování existujících expertních skupin – pro projekt je obtížné překřížit funkční linie a získat potřebné zdroje. Jediné skutečné řídící místo projektu se nachází na vrcholu struktury v osobě vrcholového manažera útvaru, který však má obvykle jiné starosti, než řešit konflikty mezi jednotlivými útvary a odděleními.“ [4, s.455]

17

Obr. č. 2 - Útvarové projektové řízení

Zdroj: Projektový management podle IPMA [4, s.456] 2.4.1.2 Autonomní projektové řízení “Tato organizační struktura je vytvořena výhradně pro projektové účely při realizaci jednoho rozsáhlého projektu. V jejím rámci jsou jednotliví členové projektového týmu po celou dobu realizace projektu uvolněni ze svého stálého pracovního umístění a jsou zařazeni do projektu, který se v podstatě stává dočasnou organizační jednotkou trvalé organizace. Rozhodující zodpovědnosti a pravomoci za realizaci projektu se soustředí do jediné role manažera projektu, který je zodpovědný za vykonávání veškerých plánovacích, organizačních a kontrolních prací souvisejících s realizací projektu. Jednotlivá odborná projektová oddělení jsou vytvářena tak, aby jejich velikost, složení a odbornost odpovídali potřebám projektu.“[4, s.456]

18

Obr. č. 3 – Autonomní projektové řízení

Zdroj: Projektový management podle IPMA [4, s.456]

2.4.1.3 Maticové projektové řízení Autonomní řízení je velmi výhodné z pohledu projektového manažera, ve větších organizacích je však velmi obtížné dosáhnout uvolnění zdrojů pro takto řízený projekt. Toto může být řešeno Maticovým projektovým řízením. „Jedním z řešení je uvolňovat zdroje pro projekt pouze na omezenou dobu nebo na částečný úvazek. Jednotliví členové projektových týmů zůstávají na svých stálých funkčních pozicích v rámci stávající organizační struktury, na kterých plní (v rámci alokované kapacity) běžné i projektové úkoly (a to i z několika projektů!).“ [4, s.457] Toto rozdělení vede k vytvoření množin zdrojů a maticová organizační struktura definuje kompetence ohledně rozdávání úkolů mezi projektové a liniové manažery. „Vytváření organizačního prostředí a koordinace projektů je v kompetenci vrcholového vedení, které často tuto odpovědnost deleguje na osobu zodpovědnou za systém projektového řízení organizace z řad odborných ředitelů nebo specialistů – na manažera portfolia.“ [4, s.457]

19

V tomto modelu projektového řízení je obtížné rozdělit kompetence mezi jednotlivé projektové a liniové manažery. To, jestli je vhodné přidělit větší kompetence jedné nebo druhé straně, záleží na vlastní společnosti a jejím zaměření a hovoříme o slabě, resp. silně maticové struktuře. „Pokud má většinu pravomocí liniový manažer, jedná se o slabou maticovou strukturu, která je jen málo rozdílná od tradiční liniové struktury. Manažer projektu zde má pouze omezené pravomoci a jeho úloha je poměrně dost obtížná. Členové týmu se řídí především zájmy svého úseku a cíle projektu je už tolik nezajímají.“ [4, s.457] „Opačným extrémem je tzv. silně maticová struktura. Linioví manažeři mají pouze omezené pravomoci a téměř veškeré práce řídí a rozhodnutí dělají manažeři projektoví. Linioví manažeři zde mají roli správce zdrojů. Starají se svým lidem o potřebné vybavení, o vhodná školení a vůbec o co nejlepší připravenost svých lidí k vykonávání prací v projektech.“[4, s.458] Maticová organizační struktura vyžaduje přítomnost dobře fungujícího kontrolního mechanismu na úrovni vedení organizace. Jasné rozdělení kompetencí mezi projektové a liniové manažery je v tomto případě zásadní pro úspěch projektu a zachování liniových aktivit. Obr. č. 4 – Maticové projektové řízení

Zdroj: Projektový management podle IPMA [4, s.458] 20

2.4.1.4 Síťové projektové řízení Posledním typem organizační struktury dle IPMA je síťové projektové řízení. „Je vytvořeno vztahy mezi jednotlivými realizovanými projekty a kmenovou organizací, která je složena z vrcholového vedení a odborných oddělení. Tento model je vysoce flexibilní a umožňuje řešit složité projekty.“ [4, s.458] „Spočívá v řízení sítě paralelně probíhajících projektů, v řízení vztahů mezi kmenovou organizací a jednotlivými projekty, ve stanovení priorit projektů, v alokaci disponibilních zdrojů, komunikaci a motivaci.“ [4, s.458] Obr. č. 5 – Síťové projektové řízení

Zdroj: Projektový management podle IPMA [4, s.456]

2.5 Projektová kancelář Jestliže společnost nerealizuje pouze ojedinělé projekty, pak je vhodné založit samostatné oddělení (Projektovou kancelář), které vytvoří rozhraní mezi trvalou organizací (liniovým rozdělením) a dočasnými (projektovými) aktivitami. Projektová kancelář má několik hlavních funkcí, které definují její činnosti a zodpovědnosti v rámci společnosti. Jedná se o funkci definiční, kontrolní, realizační a podpůrnou. O těchto funkcích pojednávají následující kapitoly.

21

2.5.1

Funkce definiční

„Útvar slouží především k projektování struktur organizace řízení projektů a jejich implementaci do integrovaného manažerského systému.”[4, s.460] Projektová kancelář tedy hledá vhodný způsob začlenění projektů do typu organizační struktury definovaného společností a podle toho určuje organizační strukturu jednotlivých projektů. 2.5.2

Funkce kontrolní

Projektová kancelář má za úkol dohled nad jednotlivými projekty a audit těchto projektů s ohledem na metodiku a její použití na jednotlivých projektech. 2.5.3

Funkce realizační

V rámci projektové kanceláře funguje množina jednotlivých projektových manažerů, ze které je dle jejich předchozích zkušeností a momentální dostupnosti vybírán nejvhodnější kandidát pro řízení jednoho z realizovaných projektů. V období mezi projekty je také nutné pro dané projektové manažery zajišťovat vhodná školení a předávání zkušeností z právě realizovaných projektů mezi jednotlivými projektovými manažery. Účelem sdílení informací je zvýšení úspěšnosti budoucích projektů. 2.5.4

Funkce podpůrná

V neposlední řadě má projektová kancelář také odpovědnost za zajištění podpory pro jednotlivé projekty. Do této oblasti spadá jak vybavení informačním systémem používaným pro řízení projektů, tak také zajištění potřebné infrastruktury pro jednotlivé členy projektových týmů (sdílená úložiště, sdílené tiskárny, zajištění konferenčních místností, poskytnutí šablon pro jednotlivé výstupy).

2.6 Realizace projektu V předchozích kapitolách jsem popsal možnosti nastavení organizace pro projektové řízení, jednotlivé projektové role a procesy související s projektovým řízením. Máme tedy popsánu strukturu potřebnou pro vlastní projektové řízení. V této kapitole se zaměřím na vlastní realizaci projektu v rámci definovaných struktur. U každého projektu jsou realizovány následující fáze: •

Zahájení projektu

•


•

Vlastní realizace projektu 22

•


•

Uzavření projektu

Detailnější informace o jednotlivých fázích budou obsaženy v následujících kapitolách. 2.6.1

Iniciace a zahájení projektu

„Iniciace v projektovém řízení znamená schválení a zahájení projektu. Organizace by se měla výběru projektů řádně věnovat. Jen tak zajistí, že bude zahajovat správné projekty ze správných důvodů. Výběr projektů je proto klíčový, stejně jako výběr projektových manažerů. Ideálně se projektový manažer účastní projektu už ve fázi iniciace, v reálu však často k projektu přistupuje až ve chvíli, kdy byla provedena řada iniciačních rozhodnutí.“ [1, s.100] Je vhodné tedy ještě před vlastním započetím projektu definovat základní kostru projektu. Senior manažeři, kteří projekt připravují, musí před vlastním zahájením definovat limity rozsahu, času a nákladů projektu, identifikovat sponzora projektu, stanovit vhodného projektového manažera projektu a připravit obchodní případ daného projektu. Po připravení těchto výstupů musí proběhnout setkání s vybraným projektovým manažerem a společná revize procesu a očekávání souvisejících s řízením projektu. 2.6.2


Naplánování projektu je obvykle nejsložitějším procesem v rámci řízení projektu. Plánování projektu provádíme hlavně za účelem následně projekt úspěšně řídit. Pro efektivní řízení projektu je nutné plány stanovit reálně a s vhodnou mírou detailu pro další použití při řízení projektu. V následující tabulce je uveden seznam znalostních oblastí, procesů a výstupů souvisejících s plánem projektu. Tabulka vychází ze čtvrtého vydání PMBOK®.

23

Tab. č. 1 – Výstupy plánování projektu Znalostní oblast

Plánovací proces

Integrované

Vytvoření plánu řízení

řízení projektu

projektu

Řízení rozsahu

Sběr požadavků

Výstupy Plán řízení projektu

Dokumenty k požadavkům Plán řízení požadavků Matice sledovatelnosti požadavků

Definování rozsahu

Deklarace rozsahu projektu Aktualizace dokumentů

Vytvoření WBS

WBS Slovník WBS Směrný plán rozsahu Aktualizace dokumentů

Řízení času

Definování aktivit

Seznam aktivit Atributy aktivit Seznam milníků

Seřazení aktivit

Síťový graf harmonogramu projektu Aktualizace dokumentů

Odhad zdrojů jednotlivých

Požadavky na zdroje

aktivit

Hierarchická struktura zdrojů Aktualizace dokumentů

Vytvoření harmonogramu

Harmonogram projektu Směrný plán Termíny harmonogramu Aktualizace dokumentů

Řízení nákladů

Odhad nákladů

Odhad nákladů na aktivity Podklady odhadů Aktualizace dokumentů

Vytvoření rozpočtu

Metrika hodnocení výkonů podle nákladů Požadavky na financování projektů Aktualizace dokumentů

Řízení kvality

Plánování kvality

Plán řízení kvality Objektivně ověřitelné ukazatele kvality Kontrolní seznamy kvality Plán zlepšení procesů Aktualizace dokumentů

Řízení lidských

Plánování lidských zdrojů

Plán lidských zdrojů

Plánování komunikace

Plán řízení komunikace

zdrojů Řízení

24

komunikace Řízení rizik

Aktualizace dokumentu Plánování řízení rizik pro-

Plán řízení rizik projektu

jektu Identifikace rizik

Registr rizik

Realizace kvalitativní

Aktualizace registru rizik

analýzy Realizace kvantitativní


analýzy Plánování protirizikových


opatření

Aktualizace plánu řízení projektu Smluvní rozhodnutí související s riziky Aktualizace dokumentů

Řízení dodávek

Plánování dodávek

Plán řízení dodávek Definice cílů a rozsahu dodávek Rozhodnutí, zda si produkt/službu zajistit sám, či ji nakoupit Dokumenty vztahující se k dodávkám Kritéria výběru dodavatele Žádosti o změnu

Zdroj: Řízení projektů v IT [1, s.110-111] Všechny procesy plánování zahrnují řadu výstupů a jsou zohledněny všechny znalostní oblasti. Vzhledem k rozsahu jednotlivých projektů je vždy nutné zvolit vhodnou množinu z uvedených výstupů. 2.6.3

Vlastní realizace projektu

Vlastní realizace projektu zahrnuje provedení činností, které směřují k tomu, že všechny aktivity z plánu projektu budou dokončeny. Součástí je také kompletní dodání nového hardwaru, softwaru a postupů do normálního provozu. „Produkty projektu vznikají během jeho realizace, proto tento proces obvykle vyžaduje nejvíce zdrojů.“ [1, s.119] V následující tabulce jsou uvedeny znalostní oblasti, procesy a výstupy realizace podle čtvrtého vydání PMBOK®.

25

Tab. č. 2 – Výstupy realizace projektu Znalostní oblast

Proces realizace

Výstupy

Integrované

Řízení a vedení realizace

Informace o postupu projektu

řízení projektu

projektu

Žádosti o změnu Aktualizace plánu řízení projektu Aktualizace projektových dokumentů

Řízení kvality

Zajišťování kvality

Aktualizace aktiv organizačních procesů Žádosti o změnu Aktualizace plánu řízení projektu Aktualizace projektových dokumentů

Řízení lidských

Sestavení projektového

Pověření pracovníků projektu

zdrojů

týmu

Kalendáře zdrojů Aktualizace plánu řízení projektu

Rozvoj projektového týmu

Hodnocení práce týmu Modernizace faktoru/ů týkajících se podnikového prostředí

Řízení projektového týmu

Aktualizace aktiv organizačních procesů Aktualizace plánu řízení projektu Žádosti o změnu

Řízení komunika-

Distribuce informací

ce

Aktualizace aktiv organizačních procesů Žádosti o změnu

Řízení dodávek

Řízení očekávání zainte-

Aktualizace plánu řízení projektu

resovaných stran projektu

Aktualizace projektových dokumentů

Realizace nákupů

Vybraní prodejci Smlouvy na dodávky Kalendáře zdrojů Žádosti o změny Aktualizace plánu řízení projektu Aktualizace projektových dokumentů

Zdroj: Řízení projektů v IT [1, s.119-120] Shodně jako u plánování projektů, jedná se o výčet výstupů, který je vhodné upravit dle potřeb konkrétního projektu. 2.6.4


Tato aktivita zahrnuje procesy měření postupu projektu vůči stanoveným cílům, sledování odchylek od plánu a přijetí nápravných opatření, jejichž účelem je udržet realizaci projektu v souladu s plánem. Aktivita probíhá v průběhu celého životního cyklu projektu. 26

V následující tabulce jsou opět uvedeny znalostní oblasti, procesy a výstupy jak jsou definovány ve čtvrtém vydání PMBOK®. Tab. č. 3 – Výstupy monitoringu a kontroly projektu Znalostní oblast

Procesy monitorování a

Výstupy

kontroly Integrované

Monitorování a kontrola

Žádosti o změnu

řízení projektu

projektových prací

Aktualizace plánu řízení projektu

Realizace integrovaného

Žádosti o změnu

řízení změn

Aktualizace plánu řízení projektu Aktualizace projektových dokumentů

Řízení rozsahu

Ověření rozsahu

Přijaté výstupy Žádosti o změnu Aktualizace projektových dokumentů

Řízení rozsahu

Měření postupu projektu Aktualizace aktiv organizačních procesů Žádosti o změnu Aktualizace plánu řízení projektu Aktualizace projektových dokumentů

Řízení času

Kontrola harmonogramu


Řízení nákladů

Kontrola nákladů


Řízení kvality

Kontrola kvality

Měření kvality projektu Potvrzené výstupy Měření postupu projektu Aktualizace aktiv organizačních procesů Žádosti o změnu Aktualizace plánu řízení projektu Aktualizace projektových dokumentů

Řízení komunikace

Informování o postupu

Zprávy o postupu Aktualizace aktiv organizačních procesů Žádosti o změnu

27

Řízení rizik

Monitorování a kontrola

Aktualizace seznamu rizik

rizik


Řízení dodávek

Administrace dodávek

Dokumentace dodávek Měření postupu projektu Aktualizace aktiv organizačních procesů Žádosti o změnu Aktualizace plánu řízení projektu

Zdroj: Řízení projektů v IT [1, s.123-124]

Opět jako v předchozích případech, jedná se o výčet možných výstupů a je nutné vhodně zvolit jednotlivé výstupy pro konkrétní projekt. 2.6.5

Uzavření projektu

„Procesy uzavření projektu zahrnují schválení finálního produktu či služby zainteresovanými stranami a zákazníkem a konečné ukončení projektu či projektové fáze. Jejich součástí je ověření, zda byly všechny výstupy dokončeny. Mezi časté výstupy projektu patří závěrečná zpráva a prezentace. Ačkoliv se mnoho informačních projektů zruší před finálním dokončením, je důležité každý projekt formálně uzavřít a vyhodnotit jej. Poučení z projektů nám pomáhají zlepšit ty budoucí.“ [1, s.125] Důležitou součástí ukončení projektu je realizace hladkého přechodu projektu do normálního provozu společnosti. V následující tabulce jsou znalostní oblasti, procesy a výstupy uzavření projektu založené na PMBOK®.

28

Tab. č. 4 – Výstupy uzavření projektu Znalostní oblast Integrované

Proces uzavření Dokončení projektu či fáze

řízení projektu

Výstupy Konečný produkt, služba, výsledek Aktualizace aktiv organizačních procesů

Uzavření dodávek

Dokončené dodávky Aktualizace aktiv organizačních procesů

Zdroj: Řízení projektů v IT [1, s.126] „Uzavření projektu vyžaduje dokončení finálního produktu, služby či výsledku a aktualizaci procesních aktiv firmy, jakými jsou projektové soubory a zpráva s poučením z projektu. Pokud projektový tým během realizace obstarával některé jeho položky formou externích nákupů, musí formálně ukončit či uzavřít všechny smlouvy.“ [1, s.126]

29

3 Praktická část 3.1 Specifika telekomunikačního operátora 3.1.1

Rozdělení organizace

V této kapitole popíši specifika telekomunikačního operátora v oblasti IT. Telekomunikační operátoři patří šíří svého portfolia systémů a aplikací mezi největší společnosti na českém trhu. Telekomunikační operátoři mají stovky systémů a aplikací, řešících jednotlivé business oblasti. Tyto systémy jsou rozděleny na dvě hlavní součásti a to na telekomunikační část a část zákaznickou. Obr. č. 6 – Rozdělení systémů u operátora

Zdroj: Vlastní zpracování Struktura IT oddělení je taktéž organizačně oddělena a to opět na telekomunikační (Network) část a zákaznickou část. Telekomunikační část IT oddělení má u operátora na starosti vlastní integraci fyzických prvků telekomunikační sítě a to prostřednictvím integrace mezi jednotlivými prvky až po integraci do systému zvaného Mediace. Do Mediace jsou také zapojeny jednotlivé zákaznické systémy z druhé strany a Mediační systém má na starosti propojení uvedených dvou IT světů. Organizační začlenění systému Mediace může být řešeno třemi následujícími způsoby: •

Organizační začlenění do network části operátora

•

Organizační začlenění do zákaznické části operátora

•

Organizační oddělení nezávislé na obou zmíněných částech organizace

30

Všechny tři způsoby začlenění mají své výhody a nevýhody a na českém trhu se toto začlenění liší u každého operátora. Pro potřeby návrhu procesu projektového řízení není nutné mít přesně určené toto organizační rozdělení. Mediace bude vystupovat jako jeden z dotčených systémů v rámci projektu na té straně, kde je u konkrétního operátora do organizační struktury začleněna. Je však nutné na mediaci nezapomenout, jelikož se jedná o systém, kterým projdou data o veškerém použití sítě telekomunikačního operátora, a tímto se daný systém stává kritickým pro projekty, které na něj mají dopad. Nezávisle na systému Mediace je organizační rozdělení u jednotlivých operátorů vytvořeno na liniovém základu. Na nejvyšší úrovni se jedná o již zmíněné rozdělení na network a zákaznické systémy. Pro další úvahy v této práci je možné network část považovat za jednu homogenní jednotku, jelikož jednotlivé projekty s dopadem do obou částí mají dopad do network části vždy obdobný nezávisle na projektu. Vlastní část zákaznických systémů je obvykle rozčleněna až do úrovně jednotlivých skupin zákaznických systémů a jedná se o desítky oddělení s vlastním vedením, kde pod ředitelem IT společnosti jsou dále ředitelé jednotlivých úseků. Existuje zde až 5 úrovní řízení od pracovníka realizujícího jednotlivé úkoly na projektu po ředitele IT. Tuto strukturu je třeba brát v potaz v rámci projektového managementu a zvolit vhodnou organizační strukturu, včetně pravomocí jednotlivých projektových a liniových manažerů tak, aby byla zajištěna vysoká úspěšnost jednotlivých projektů a dostatečná efektivita jednotlivých součástí procesu. 3.1.2

Typy projektů

Prostředí telekomunikačních operátorů se dále od ostatních společností s obdobně velkým IT útvarem odlišuje také rychlostí realizace jednotlivých požadavků. Rychlost realizace jednotlivých požadavků, ať už se jedná o projekty či pouhé změnové požadavky v rámci demand managementu, je klíčovým faktorem pro úspěch implementovaných produktů a služeb na velmi konkurenčním trhu. Na příkladu zavedení neomezených tarifů na český trh pro retailové zákazníky v průběhu jara 2013 je důležitost rychlosti zavedení jasně pozorovatelná. V tomto uvedeném případě se jednalo o urychlení již běžících projektů, pomocí rychle realizovatelných alternativních řešení, provedených jako změnové požadavky. Vlastní projekty byly dokončeny následně dle upravených plánů 31

Specifika projektů u telekomunikačních operátorů je tedy možno shrnout do dvou základních prvků: •

velké množství systémů s odpovídající velmi širokou organizační strukturou,

•

rychlost zavádění změn a nových projektů (rychloobrátkové služby).

Dále se v prostředí telekomunikačních operátorů objevují rozsáhlé projekty, které mají zásadní vliv na nejdůležitější zákaznické systémy, které však nemají termíny navázané na konkrétní nabídky cílovým zákazníkům. Tyto projekty obvykle na několik let zaměstnají velkou část jednotlivých IT oddělení, a snižují tak kapacity pro realizaci rychlých projektů a změn. U těchto velkých projektů je kladen důraz na kvalitu plánování a nijak významně se neliší od velkých projektů, případně programů, ve společnostech z jiného oboru. Pro účely této práce je možné tyto projekty zanedbat, jelikož při dodržení navrhovaných postupů bude i pro tyto velké jednorázové projekty kladen důraz na ideální naplánování a průběžnou kontrolu.

3.2 Výběr organizačního modelu Na základě uvedených specifik telekomunikačních operátorů na českém trhu, s ohledem na specifické potřeby rychlosti realizace jednotlivých projektů a stávající mnohaúrovňové organizační strukturu liniového řízení navrhuji použití maticového organizačního modelu.

32

Obr. č. 7 – Maticové projektové řízení

Zdroj: Vlastní zpracování Společně s touto organizační strukturou je nutné vybudovat zvláštní oddělení projektové kanceláře, které vytvoří rozhraní mezi stávající trvalou organizací (liniovou strukturou) a dočasnými (projektovými) aktivitami. Vedoucí projektové kanceláře se bude zodpovídat přímo řediteli IT a bude mít k dispozici skupinu projektových manažerů pro realizaci jednotlivých projektů. Tento výběr maticové organizační struktury s doplněním projektové kanceláře eliminuje nevýhody útvarového projektového řízení (obtížné získávání zdrojů napříč liniovou organizací). Dále eliminuje nevýhody autonomního projektového řízení, kde ředitel IT není odpovědný za každý řešený projekt zvlášť. Pomocí struktury autonomního projektového řízení je možné řešit jeden zásadní projekt pro společnost, kdy je potřebné přímé zapojení ředitele IT do tohoto projektu. Při zvolení struktury maticového projektového řízení rozšířené o projektovou kancelář, můžeme řešit větší množství projektů, kde informace k řediteli IT filtruje projektová kancelář a předává pouze podstatné informace a ředitel IT tak není zahlcen zbytečnými detaily jednotlivých projektů. V rámci této struktury je také možné řešit i jednotky velkých projektů, kdy do řídících rolí jednotlivých projektů budou obsazeni zástupci patřičné liniové

33

úrovně a projektový manažer bude reportovat přímo řediteli IT, tak jak by bylo nastaveno v rámci autonomního projektového řízení. Síťové projektové řízení se pro organizaci tohoto typu nehodí, jelikož existuje nezanedbatelné množství liniových úkolů a je nutné projektové a liniové kapacity patřičně sdílet.

3.3 Popis procesu řízení IT projektů Jak jsem zhodnotil v předchozí kapitole, rozhodl jsem se pro maticové projektové řízení rozšířené o projektovou kancelář, která je přímo podřízena řediteli IT. Pro úplný obraz procesu projektového řízení nám pouhá organizační struktura a popis rolí nestačí, je také nutné upravit jednotlivé části procesu projektového řízení popsaného v kapitole (2.6 Realizace projektu) vycházejících tedy z PMBOK® pro konkrétní potřeby telekomunikačního operátora. Zároveň je nutné specifikovat jednotlivé aktivity a popsat kompetence dotčených rolí. Tato práce se zabývá procesem jako takovým, nepopisuje jednotlivé metody řízení rozsahu, času a rozpočtu. Tyto dílčí metody jsou dobře popsány v jednotlivých metodikách a je vždy na zvážení projektového manažera, jakou konkrétní metodu použije. Můj návrh tedy definuje Organizační strukturu projektu jako maticovou a popisuje jednotlivé kroky procesu včetně odpovědnosti a nutných výstupů, které jsou z mého pohledu bezpodmínečně nutné pro úspěšné realizace jednotlivých projektů.

3.4 Organizační struktura Organizační struktura tedy rozšiřuje popsané role v teoretické části o oddělení projektového managementu (Projektovou kancelář) a následně o aktivity spojené se schvalováním jednotlivých významných milníků v průběhu projektu (prioritizační komise, projektový board). Výše tedy navrhuji vytvořit stálou projektovou kancelář, která bude stát mimo liniovou strukturu jednotlivých oddělení a bude se zodpovídat přímo řediteli IT. Toto oddělení bude složeno z vedoucího týmu a jednotlivých projektových manažerů. V souladu s maticovou organizační

strukturou

budou

součástí

projektových

týmů

obvykle

pracovníci

z jednotlivých liniových oddělení, kteří budou plnit vlastní úkoly na projektu. Kapacity

34

jednotlivých pracovníků budou definovány v přípravných krocích projektu a projektová kancelář má pravomoc na základě priority projektu si dostatečnou kapacitu zdrojů vyžádat. 3.4.1

Odpovědnosti:

3.4.1.1 Vedoucí projektového oddělení: Vedoucí projektového oddělení má za úkol rozdělování úkolů mezi jednotlivé projektové manažery, včetně přidělování nových projektů. Dále je jeho odpovědností shrnovat informace o jednotlivých projektech a pravidelně informovat vedení IT o probíhajících projektech. Mimořádně eskalovat na své nadřízené problémy projektů, které vyžadují okamžitý zásah a mají nezanedbatelný dopad na rozpočet, kvalitu, rozsah nebo termín projektu. 3.4.1.2 Projektový manažer: Projektový manažer musí zejména odpovědně řídit přidělené projekty s cílem dodržet termín, rozsah, kvalitu a rozpočet daného projektu a informovat pravidelně svého nadřízeného o stavu přidělených projektů. V případě potřeby řešení akutních problémů, které není schopen projektový tým řešit sám, eskaluje projektový manažer na svého nadřízeného, který dohromady s vedením IT na projektovém boardu rozhodne o dalším postupu u daného projektu. 3.4.1.3 Členové projektového týmu: Člen projektového týmu musí odpovědně plnit jemu svěřené úkoly od projektového manažera v požadovaném rozsahu, kvalitě a termínu. Členové projektového týmu jsou obvykle součástí liniového oddělení ve společnosti a tudíž může nastat rozpor mezi projektovými úkoly a liniovými úkoly. V tomto případě musí člen projektového týmu okamžitě informovat svého liniového nadřízeného a projektového manažera. Řešení těchto rozporů je plně v kompetenci projektového manažera společně s liniovým vedoucím. Pokud tito dva pracovníci nenaleznou řešení kolizní situace, je nutné problém eskalovat na jejich nadřízené a to dle povahy problému buď na pravidelných schůzkách, nebo pokud je to nezbytné, pak ihned.

35

3.4.2

Pravidelné aktivity:

Jak již bylo zmíněno v odpovědnostech jednotlivých rolí zapojených do projektu, je nutné provádět pravidelné schůzky, kde budou prezentovány výsledky předchozích úkolů, budou zadávány další úkoly a budou eskalovány problémy. Z těchto pravidelných aktivit je nutné nastavit pravidla a výstupy pro následující schůzky: 3.4.2.1 Projektový board: Tato schůzka má za cíl pravidelně na týdenní bázi informovat o jednotlivých projektech na úrovni vedení IT. Schůzky se účastní ředitelé jednotlivých domén v IT (Network, Service Delivery, Enterprise IT oddělení) a vedoucí projektového oddělení, v případě potřeby je možno účastníky rozšířit o hosty z jednotlivých projektů, pokud je nezbytně nutná potřeba vysvětlení některých bodů napřímo. Za agendu schůzky je zodpovědný vedoucí projektového oddělení, který na této schůzce informuje vedení IT o probíhajících projektech, a to zejména o kvalitě, rozsahu, termínů a rozpočtu daného projektu. Dále prezentuje problémy, které v jednotlivých projektech nastaly a vyžadují rozhodnutí vedení IT o dalším postupu. Podklady na schůzku projektového boardu vedoucí projektového oddělení předává předchozí den, aby bylo možné připravit rozhodnutí pro eskalované problémy. Na této schůzce je také rozhodováno o možných termínech realizace projektů, které mají připravené zadání a hrubý rozsah projektu. 3.4.2.2 Řídící rada projektu: Tato schůzka má za cíl informovat vlastníky projektu mimo IT ohledně stavu projektu. Za IT se účastní projektový manažer řídící daný projekt a business vlastníci daného projektu. Na schůzce je projektovým manažerem prezentován stav projektu zejména s ohledem na kvalitu, rozsah, termíny a rozpočet projektu. Jsou zde probírána jednotlivá rizika projektu a business vlastníci zde mohou vznášet své požadavky na projekt. Tato schůzka je také na týdenní bázi, v případě potřeby může být frekvence nižší. 3.4.2.3 Projektový status: Tato schůzka má za cíl informovat projektového manažera o situaci na daném projektu. Na počátku projektu je určeno, jací členové projektového týmu se budou této schůzky účastnit. Na dané schůzce každý člen týmu informuje o plnění svých úkolů a eskaluje případné problémy, které nedokáže v požadovaném termínu samostatně vyřešit. Dále je určen plán úkolů na další období. Schůzka je na týdenní bázi. V případě menších projektů je možné 36

informace předávat i pomocí reportů o úkolech v elektronické verzi. Pokud jsou informace předávány pouze elektronicky, je nutné provádět schůzku s osobní účastí alespoň jednou měsíčně. 3.4.2.4 Prioritizační komise: Tato schůzka konaná v týdenním intervalu má za úkol v rámci demand management procesu definovat priority jednotlivých požadavků. Na schůzce jsou zástupci business vlastníků jednotlivých požadavků, IT demand managementu a projektového managementu. Všem novým požadavkům je na této schůzce stanovena priorita z číselné řady, a to tak, že každá hodnota je použita maximálně jednou. Nejnižší hodnota značí nejvyšší prioritu. Priorita je stanovována s ohledem na již běžící projekty a řešené požadavky a je vstupem pro rozhodnutí o realizaci připravených projektů a požadavků.

3.4.3

Identifikace projektů

V předchozí kapitole jsme si popsali základní strukturu organizace a sdílení informací s ohledem na roli projektového manažera. V této kapitole se dostaneme již blíže k vlastním projektům. V prvé řadě je nutné jednoznačně identifikovat požadavky, které vedou k vytvoření projektu v IT části telekomunikačního operátora. Všechny požadavky ať už projektové nebo jen změnové na IT musí být řádně vzneseny pomocí dedikovaného nástroje pro tento úkol. Pro požadavky od jednotlivých útvarů se obvykle používají nástroje na sdílení požadavků, kde nejrozšířenějším u českých telekomunikačních operátorů je HP Quality Center a HP Service Desk. Tato řešení poskytují i mnoho dalších funkčností pro jiné procesy. Vzhledem k již provedeným investicím do těchto řešení u jednotlivých operátorů a jejich kvalitě není nutné hledat jiná řešení pro tuto oblast. Dále doporučuji mít specializovaný portál pro evidenci projektů, který bude zároveň umožňovat i evidenci budoucích projektů. V této bakalářské práci popisuji řešení pouze pro projekty v IT, tudíž proces rozhodnutí o realizaci projektu na straně business zde nepopisuji a předpokládám dodání zadání projektu do projektového týmu v dostatečné kvalitě pro evaluaci projektu na straně IT. Business zadavatelem projektu může být v tomto případě i jiné IT oddělení, dále se o všech možných business zadavatelích budu vyjadřovat pouze jako o zadavateli. 37

IT projektové řízení tedy začíná převzetím požadavku od zadavatele. V mnou navrhovaném procesu je nutné informovat zadavatele o převzetí požadavku do zpracování v IT a informovat jej o následných krocích. Ideálně toho docílíme portálovým nástrojem, kde mohou zadavatelé dané požadavky ukládat s tím, že automaticky bude informován zadavatel o převzetí do IT a nutnosti ohodnocení daného požadavku v IT, které na základě stanovené priority bude provedeno v odpovídajícím čase. Vzhledem k omezeným zdrojům v IT je nutné stanovovat jednotlivým požadavkům priority, tato aktivita proběhne na již dříve zmiňované schůzce prioritizační komise, kde budou všechny požadavky obdržené od poslední komise stručně zhodnoceny vedoucím projektového oddělení, hlavním analytikem a hlavním architektem. Pokud požadavek na projekt splní všechny formální náležitosti, bude předán dále k prioritizaci. Požadavku je na této schůzce, jak je již popsáno výše, stanovena priorita. Na základě priority z prioritizační komise se průběžně zpracovávají požadavky v analytickém týmu, který požadavek přetlumočí do IT řeči a následně v architektonickém týmu, kde proběhne hrubé ohodnocení dopadů požadavku na stávající systémy, případně popis nově požadovaného systému. Toto ohodnocení u požadavků s prioritou nižší než 50 je provedeno do týdne od schůzky prioritizační komise. V případě rozsáhlých projektů, kde je ihned zřejmé, že bude překročena metrika pro rozhodnutí, co je ještě změnový požadavek a co je již projekt, je požadavku potvrzen status projektu ihned na prioritizační komisi a pokud je to možné, je přidělen projektový manažer. Pokud má požadavek ohodnocení na větší pracnost než 100 člověkodnů pro jakýkoliv dotčený systém, případně celkovou pracnost vyšší než 200 člověkodnů, pak je požadavek prohlášen za projekt a je mu přidělen projektový manažer. Pro menší požadavky než uvedené není nutné vytvářet projektový tým a je efektivnější dané požadavky vyřešit v rámci demand managementu jako změnu. V případě nižších pracností se tedy jedná o změnový požadavek a v této bakalářské práci se mu dále nevěnuji.

3.5 Projektové aktivity Projekt rozděluji na 4 základní fáze, jejichž součástí jsou jednotlivé projektové aktivity popsané v následujících kapitolách. U jednotlivých aktivit je uveden můj návrh výstupů a odpovědností s danou aktivitou spojených.

38

Obr. č. 8 – Rozdělení projektových fází

Zdroj: Vlastní zpracování

3.5.1

Příprava projektu – iniciační fáze

V předchozí kapitole jsem nastavil parametry pro určení, zda požadavek povede k vytvoření projektu, či zda zůstane pouhým změnovým požadavkem. Mnoho z aktivit provedených ve fázi rozhodování o kategorizaci požadavku souvisí s iniciační fází projektu. V této kapitole se budu dále věnovat požadavkům, které byly označeny jako projekt, a následným krokům potřebným pro realizaci vlastního projektu. 3.5.1.1 Přidělení projektového manažera Pro velké požadavky je projektový manažer přidělen již na prioritizační komisi, pro ostatní, o kterých je rozhodnuto na základě ohodnocení požadavků architektonickým týmem, je projektový manažer přidělen na následující prioritizační komisi. 3.5.1.2 Úvodní aktivity projektového týmu Obr. č. 9 – Příprava projektu

Zdroj: Vlastní zpracování Neprodleně po přidělení projektu se IT projektový manažer sejde s vlastníkem požadavku a nechá si projekt představit přímo od zdroje. Následně dle nastavené priority projektový manažer určí termín přípravy high level konceptu řešení v analytickém týmu. Termín pro projekty vyhodnocené na základě pracností z aktivity následující po prioritizační komisi je obvykle dva týdny od zadání do analytického týmu, u větších projektů je tento termín řešen 39

individuálně, neměl by však přesáhnout jeden měsíc. Po připravení high level konceptu projektu je tento koncept předán architektonickému týmu, který opět do dvou týdnů, resp. do měsíce, připraví high level koncept architektury. Dobu trvání těchto aktivit jsem stanovil na základě mé odsobní zkušenosti z oddělení demand managementu u telekomunikačního operátora. High level koncept projektu a architektury musí být následně schválen zadavatelem požadavku a společně se zadáním požadavku tvoří zadání projektu. Tab. č. 5 - Výstupy přípravy projektu Výstup High level koncept projektu High level koncept architektury Prvotní projektový plán Prvotní registr rizik

Zodpovědná role Hlavní analytik projektu Hlavní architekt projektu Projektový manažer Projektový manažer

Zdroj: Vlastní zpracování 3.5.2

Schválení projektu do realizace – iniciační fáze

Z předchozích aktivit máme schválené zadání a předpokládaný rozsah projektu a nyní je nutné rozhodnout o následné realizaci tohoto projektu. Obr. č. 10 – Schválení projektu do realizace

Zdroj: Vlastní zpracování Na projektovém boardu je určen na základě rozsahu a priority možný termín realizace projektu a je předán zadavateli projektu. Rozhodnutí o možných termínech realizace obdrží projektový manažer, který neprodleně informuje zadavatele o hrubém rozpočtu a možném termínu realizace. Zadavatel na základě informací obdržených od projektového manažera zajistí potřebný rozpočet a zajistí schválení projektu na jeho straně. V případě neschválení není projekt realizován, případně jsou upraveny vstupní parametry požadavku, který je následně přehodnocen podle předchozího procesu a proces schvalování se opakuje.

40

Tato aktivita je provedena na prvním možném projektovém boardu, v ideálním případě je tedy do týdne po ukončení úvodních aktivit v analytickém týmu, rozhodnuto o dalším pokračování projektu. Tab. č. 6 - Výstupy aktivity schválení projektu do realizace Výstup Zápis z jednání schvalující projekt Upravený harmonogram projektu Upravený registr rizik

Zodpovědná role Vedoucí projektové kanceláře Projektový manažer Projektový manažer


Zahájení projektu – iniciační fáze

Projekt, který je schválen do realizace, je možné zahájit. Projektový manažer se zodpovědnými zástupci dotčených systémů, analýzy a architektury společně nominují členy projektového týmu. V případě problémů s alokací jednotlivých členů týmu pro projekt je nutné tyto kolize řešit a na základě priority projektu a ostatních zpracovávaných požadavků rozhodnout o kapacitě věnované pro projekt a o případném dopadu na termíny. V případě dopadu na termíny je nutné získat souhlas zadavatele projektu. Obr. č. 11 – Zahájení projektu

Zdroj: Vlastní zpracování

V případě zapojení externího dodavatele do projektu je v rámci procesu projektového řízení s tímto dodavatelem zacházeno jako s jakýmkoliv jiným zdrojem projektu. Vlastní schválení a cenové jednání s externím dodavatelem pro projekty řízené projektovým manažerem telekomunikačního operátora není součástí této práce a je plně v gesci procurement oddělení, které musí mít dostatečnou odpovědnost pro výběr takového dodavatele. Výběr dodavatele obvykle proběhne ve spolupráci s dotčenými IT odděleními, ale odpovědnost za vlastní výběr dodavatele je na procurement oddělení. Po nominování členů projektového týmu s nimi proběhne zahajovací schůzka, kde budou nastavena pravidla pro komunikaci, bude tedy představena komunikační a eskalační 41

matice, dále budou představeny cíle projektu, harmonogram a rozsah celého projektu. Všem bude dále představen seznam rizik a budou informováni o postupu, jak doplňovat případná další rizika. Tab. č. 7 - Výstupy aktivity zahájení projektu Výstup Plán řízení projektu Plán lidských zdrojů Plán řízení komunikace včetně eskalační matice Deklarace rozsahu projektu Plán řízení dodávek

Zodpovědná role Projektový manažer Projektový manažer Projektový manažer Projektový manažer Projektový manažer


Analytická příprava projektu – fáze plánování

Vlastní realizace projektu je zahájena analytickou částí projektu, kde analytický tým společně se zadavatelem definují jednotlivé požadavky detailněji, než tomu bylo doposud. Výstupem této fáze je analýza popisující jednotlivé požadavky ve členění FURPS+ včetně popisu jednotlivých případů užití. Obr. č. 12 – Analytická příprava projektu

Zdroj: Vlastní zpracování V této fázi jsou zapojeni analytické zdroje, hlavní architekt projektu, zadavatel a projektový manažer. Pracnosti jednotlivých aktivit jsou nastaveny individuálně v souladu s high level harmonogramem, který byl připraven před zahájením projektu a prezentován členům týmu.

42

Tab. č. 8 - Výstupy analytické přípravy projektu Výstup Upravený plán řízení projektu Plán řízení požadavků Dokumenty k požadavkům Upravená deklarace rozsahu projektu Plán řízení kvality

Zodpovědná role Projektový manažer Hlavní analytik projektu Hlavní analytik projektu Projektový manažer Projektový manažer


Návrh architektury – fáze plánování

V této fázi je převzata analytická dokumentace od týmu analytiků a je zde zpracován architektonický rozpad jednotlivých požadavků na jednotlivé systémy, ve kterých budou realizovány, jsou zde popsány způsoby realizace jednotlivých rozhraní a jsou vyřešena nejzávažnější architektonická rizika. Součástí této dokumentace je také detailní odhad pracnosti jednotlivých aktivit potřebných pro vlastní realizaci projektu. Obr. č. 13 – Návrh architektury

Zdroj: Vlastní zpracování Z detailního rozpadu pracností je následně stanoven závazný harmonogram projektu, který je následně předán zadavateli. Harmonogram připravuje projektový manažer a nechává si jej schválit od odpovědných zástupců dotčených oddělení. V této fázi jsou zapojeny zdroje z týmu architektury, hlavní analytik projektu, zadavatel, test architekt a projektový manažer. Pracnosti jsou opět stanoveny na jednotlivé úkoly individuálně v souladu s harmonogramem. Při nutnosti posunu termínů je toto konzultováno se zadavatelem a je rozhodnuto o způsobu řešení úpravy termínů, a to buď navýšením kapacit a dodržením původních termínů, případně úpravou rozsahu, nebo posunem termínů.

43

Tab. č. 9 - Výstupy návrhu architektury Výstup Seznam aktivit Seznam milníků WBS Slovník WBS Směrný plán rozsahu Požadavky na zdroje Hierarchická struktura zdrojů Odhad trvání aktivit Upravený harmonogram projektu Odhad nákladů projektu Plán lidských zdrojů Upravený plán řízení komunikace Upravený registr rizik Plán řízení rizik projektu Definice cílů a rozsahu dodávek Kritéria výběru dodavatele Žádosti o změnu

Zodpovědná role Hlavní architekt projektu Projektový manažer Hlavní architekt projektu Projektový manažer Projektový manažer Projektový manažer Projektový manažer Hlavní architekt projektu Projektový manažer Hlavní architekt projektu Projektový manažer Projektový manažer Projektový manažer Hlavní architekt projektu Hlavní architekt projektu Projektový manažer Projektový manažer


Opětovné schválení projektu – fáze plánování

Po detailním vypracování architektonické dokumentace je k dispozici podrobné zadání pro vlastní implementaci projektu v jednotlivých vývojových týmech. S ohledem na dobu uběhlou od počátku projektu (v tomto okamžiku může dle velikosti projektu dosahovat od 3 do 5 měsíců při ideálním průběhu schvalování jednotlivých kroků) je nutné revidovat potřebu operátora ohledně realizace. Obr. č. 14 – Opětovné schválení projektu

Zdroj: Vlastní zpracování Projektový manažer zajistí na projektovém boardu finální schválení projektu za IT, včetně závazného harmonogramu. Následně informuje zadavatele o potřebném rozpočtu a závazných termínech realizace. Zadavatel zajistí schválení projektu a jeho rozpočtu na jeho straně a je možné přistoupit k vlastní implementaci. 44

Tab. č. 10 - Výstupy opětovného schválení projektu Výstup Zápis s rozhodnutím o realizaci Upravený harmonogram Upravený registr rizik Metriky chybovosti pro jednotlivé fáze projektu Schválený požadavek na financování projektu

Zodpovědná role Vedoucí projektové kanceláře Projektový manažer Projektový manažer Projektový manažer/zadavatel Zadavatel


Vlastní implementace – fáze realizace

Na základě opětovného schválení projektu, kde proběhlo i schválení harmonogramu daného projektu, projektový manažer společně s projektovým týmem rozdělí úkoly mezi jednotlivá oddělení a konkrétní pracovníky. Z počátku projektu se soustředí zejména na aktivity, které jsou spojeny s nejvýznamnějšími riziky, ať už z pohledu závažnosti dopadu, nebo z pohledu pravděpodobnosti výskytu daného rizika. V této fázi je obvykle zapojeno větší množství oddělení, která nemají společné liniové řízení. V prostředí telekomunikačního operátora se jedná zejména o rozdělení mezi část společnosti zabývající se telekomunikační sítí a část vlastního IT vývoje. Projektový manažer je tedy spojujícím prvkem mezi těmito částmi a řídí jednotlivé členy týmu s ohledem na cíle projektu. Obr. č. 15 – Vlastní implementace

Zdroj: Vlastní zpracování Výstupem této fáze jsou připravené součásti projektu k nasazení do testovacího prostředí, včetně dokumentace, která je ve společnosti předepsána. Dokumentace v tomto případě obsahuje i detailní plány aktivit potřebných pro nasazení do provozu a jejich harmonogram. V případě jakýchkoliv kolizí mezi skutečností a projektovým plánem je každý člen projektu povinen neprodleně informovat projektového manažera, který následně zajistí zdroje, či rozhodnutí potřebná pro dodržení harmonogramu. Pokud není možné v rozumném 45

rozpočtu dodržet stávající harmonogram, na projektovém boardu přednese projektový manažer možnosti řešení nastalé situace a projektový board rozhodne o dalším postupu. Tab. č. 11 - Výstupy vlastní implementace Výstup Vlastní výstupy definované WBS Informace o postupu projektu Žádosti o změnu Aktualizovaný plán řízení projektu Upravený registr rizik Aktualizace projektových dokumentů Strategie testování projektu Analýza testování Kalendáře zdrojů Instalační procedura Popis rollbacku nasazení Hodnocení práce týmů Smlouvy na dodávky Seznam vybraných dodavatelů

Zodpovědná role Odpovědní pracovníci jednotlivých týmů Projektový manažer Projektový manažer Projektový manažer Projektový manažer Odpovědní pracovníci jednotlivých týmů Test manažer Test manažer Projektový manažer Odpovědní zástupci jednotlivých týmů Hlavní architekt projektu Odpovědní pracovníci jednotlivých týmů Odpovědný manažer z procurement oddělení Odpovědný manažer z procurement oddělení


Testování – fáze realizace

Po vytvoření všech nutných součástí projekt přechází do fáze testování. V této fázi má projektový manažer za úkol sledovat bedlivě stav projektu. Testovací tým je zodpovědný za včasné hlášení všech nalezených chyb pomocí tomu určeného nástroje a eskalaci neřešených chyb na straně vývoje. Projektový manažer pravidelně reportuje o stavu chyb vedoucího projektového oddělení a v případě nutnosti společně na projektovém boardu eskalují potřebu řešení chyb, které se nedaří odstraňovat v dohodnutých termínech. Obr. č. 16 – Testování

Zdroj: Vlastní zpracování Projektový board má ve své pravomoci rozhodnutí o úpravě rozpočtu (pro navýšení zdrojů), posunu termínu, případně o vyjmutí některých částí projektu z obsahu projektu. 46

Testování je ukončeno po dosažení metriky nastavené v rámci analytické fáze pro tento projekt a je svolána schůzka, kde bude rozhodnuto o nasazení projektu do provozního prostředí. Tab. č. 12 - Výstupy testování Výstup Upravená testovací strategie projektu Report z testů Informace o nalezených defektech a řešeních Zapsané průběhy jednotlivých testů Souhrn chybovosti jednotlivých testovacích kol Upravený registr rizik Zápis z Go/Nogo schůzky

Zodpovědná role Test manažer Projektový manažer Test manažer Test manažer Test manažer Projektový manažer Vedoucí projektové kanceláře


Nasazení – fáze realizace

Po schválení nasazení projektu do provozního prostředí, projektový manažer společně se zástupci vývoje a provozu rozdělí úkoly, jejichž splnění vede k nasazení do provozního prostředí podle předem připraveného harmonogramu. Obr. č. 17 – Nasazení

Zdroj: Vlastní zpracování Po provedení vlastního nasazení do produkčního prostředí je provedeno ověření úspěšnosti nasazení na předem stanovených testovacích scénářích. V případě neúspěšného nasazení je provedena analýza příčin. Na základě analýzy příčin je rozhodnuto na projektovém boardu o dalším postupu.

47

Tab. č. 13 - Výstupy nasazení Výstup Aktualizované projektové dokumenty Upravená instalační procedura Upravený registr rizik Nainstalované výstupy projektu na produkčním prostředí

Zodpovědná role Odpovědní zástupci projektových týmů Hlavní architekt projektu Projektový manažer Odpovědný zástupce provozního oddělení

Zdroj: Vlastní zpracování 3.5.10 Předání do provozu – fáze uzavření projektu Projekt máme již kompletně nasazen na produkčním prostředí, v této fázi je dle postupů společnosti provedeno předání do provozu a převzetí projektu provozním oddělením. Je nutné zajistit předání kompletní dokumentace k vytvořenému projektu, aby bylo možné řešit podporu daného projektu. Obr. č. 18 – Předání do provozu

Zdroj: Vlastní zpracování Zároveň je vhodné určit, z členů původního projektového týmu, klíčové pracovníky, kteří v případě potřeby budou schopni zasáhnout a opravit chyby, které nebude možné opravit v provozním týmu. Součástí podpory je tedy po omezenou dobu po nasazení i část původního týmu. Vzhledem k oborovým nejlepším praktikám by doba potřebná pro úplné převzetí neměla přesáhnout 3 měsíce od nasazení projektu do provozního prostředí. Tab. č. 14 - Výstupy předání do provozu Výstup Upravená instalační příručka jednotlivých systémů Upravený registr rizik Seznam nalezených defektů ve fázi testování a jejich řešení Upravené požadavky na minimální konfiguraci Report z jednotlivých testů požadovaných provozem

Zodpovědná role Odpovědní pracovníci jednotlivých týmů Projektový manažer Test manažer Hlavní architekt projektu Test manažer

Zdroj: Vlastní zpracování 48

3.5.11 Ukončení projektu – fáze uzavření projektu Projekt je již nasazen a podpora pro provozní tým již byla ukončena. V tento okamžik projektový manažer připraví zprávu pro projektový board, kde shrne průběh projektu, čerpání rozpočtu, dodržení termínů a report ohledně chybovosti projektu. Obr. č. 19 – Ukončení projektu

Zdroj: Vlastní zpracování Projektový board vezme tuto zprávu na vědomí, v případě potřeby zajistí úpravy v procesech aby se vyvarovali opakování chyb z tohoto projektu a projekt definitivně ukončí. Tab. č. 15 - Výstupy ukončení projektu Výstup Konečný produkt, služba Dokončené dodávky

Zodpovědná role Projektový manažer Odpovědný zástupce procurementu

Zdroj: Vlastní zpracování 3.5.11.1 Vyhodnocení projektu – fáze uzavření projektu Součástí ukončení projektu je také vyhodnocení úspěšných a neúspěšných aktivit, které je nezbytně nutné pro další vylepšení budoucího procesu projektového řízení a vyvarování se minulých omylů. Projektový manažer tedy společně s hlavním architektem a analytikem projektu zhodnotí průběh celého projektu s ohledem na kritické okamžiky a navrhnou opatření, jakým se eliminuje riziko opakování shodných chyb v budoucích projektech. Tab. č. 16 - Výstupy vyhodnocení projektu Výstup Seznam opatření a návrhů pro budoucí projekty Návrh na úpravy procesu projektového managementu

Zodpovědná role Projektový manažer Vedoucí projektové kanceláře

Zdroj: Vlastní zpracování 49

3.6 Začlenění procesu řízení IT projektů do svého okolí V průběhu celého projektu je nutné vzít v potaz ostatní procesy ve společnosti a zajistit soulad procesu projektového řízení s těmito dotčenými procesy. Jedná se o následující procesy: •

demand management proces,

•

knowledge management proces,

•

release management,

•

capacity management,

•

operation and support.

3.6.1

Demand management

Demand management je začleněn do procesu na počátku projektu, kdy se rozhoduje o vytvoření projektu, případně pouze změnového požadavku. Následně v průběhu projektu je Demand management jedním ze zdrojů upravujících požadavků na projekt i okolní systémy a v průběhu analýzy je nutné tyto požadavky brát v potaz a reagovat na ně bez zbytečného odkladu. 3.6.2

Knowledge management proces

Ve společnosti je uchováváno mnoho informací o procesech, systémech a postupech spojených s tvorbou aplikací a informačních systémů, včetně informací o jednotlivých aplikacích a systémech. V rámci průběhu projektu vzniká množství dokumentace popisující vlastní projekt a jeho výstupy. Projektový management má za úkol zajistit vytvoření této dokumentace v souladu s pravidly pro udržování a tvorbu dokumentace vytvořenými. 3.6.3

Release management

Projekt obvykle zasahuje větší množství systémů a jeho závislost na release managementu spočívá hlavně v zajištění nekolizního stavu s ostatními požadavky. Již v průběhu plánovacích činností je toto nutno brát v potaz. Je nutno harmonogram projektu a architekturu vlastního řešení navrhnout tak aby byla zajištěna konzistence celkového řešení a kontinuita realizace ostatních požadavků. 3.6.4

Capacity management

V rámci projektového řízení dochází často v jednotlivých týmech ke kolizím mezi liniovými úkoly a projektovými úkoly. Je tedy nutné zajistit prioritu jednotlivých úkolů a pokud 50

je to možné vyčlenit pracovníky na liniové úkoly a pracovníky na projektové úkoly. V případě nutnosti je vhodné tým posílit o další pracovníky, kteří budou zajištěni pro řešení úkolů v jednotlivývh fázích projektu. Toto zajištění je nutné řešit již při tvorbě harmonogramu společně s oddělením lidských zdrojů. 3.6.5


Jak již bylo zmíněno v jedné z předchozích kapitol (2.6.3 Vlastní realizace projektu), je nutné zajistit v projektu vytvoření dostatečné dokumentace pro následný provoz a podporu systému a také podporu projektového vývojového týmu pro provozní tým. Toto musí být řešeno určením klíčových členů vývojového týmu pro podporu provozního týmu.

51

3.7 Zhodnocení nejvhodnější varianty řízení IT projektů pro telekomunikačního operátora V praktické části této práce je popsán proces, odpovědnosti, výstupy a fáze projektového řízení, založené převážně na PMBOK® s integrací procesu projektového řízení na okolní procesy a služby obvykle řešené dle ITIL®. Vzhledem k častým změnám na telekomunikačním trhu je nutné reagovat rychle a mít možnost doručit projekt od základní myšlenky do doby maximálně jednoho roku. V mnou navrženém procesu je kladen důraz na průběžné schvalování projektu, tj. delší iniciační a plánovací fáze a jeho záměru s ohledem na možné změny. Projektový board, ještě před zahájením vlastního vývoje projektu má dostatek informací pro rozhodnutí o pokračování projektu, případně pro navržení změny tohoto projektu. V průběhu realizace celého projektu je řídící rada průběžně informována a může efektivně reagovat na případné změny vyvolané vnějším prostředím. Vlastní projektové řízení se v průběhu projektu bude potýkat s celou řadou kolizí s ostatními projekty a z pohledu jednotlivých pracovníků neřešitelnými problémy. Projektový manažer má kompetenci a možnosti eskalovat tyto potíže na řídící radu projektu a prostřednictvím svého nadřízeného na projektový board, který je kompetentní rozhodnout o změnách v projektu s dopadem na harmonogram, obsah projektu a rozpočet. Toto jasné rozdělení kompetencí vede k věcnému řešení jednotlivých problémů na straně projektu a zajišťuje nejvhodnější řešení problému z pohledu celé společnosti bez zbytečných průtahů. Projekt je řízen hlavně podle rizik, kde jsou vždy řešeny úkoly s největšími riziky a je tím snížena pravděpodobnost neočekávaných chyb s velkým dopadem v pozdějších fázích projektu.

52

4 Závěr Projektové řízení je velmi rozsáhlá disciplína, ve které je možné pro každou část projektu

vytvořit množství kompetentních rolí, postupů a dalších výstupů a doporučení. Já jsem se v této práci soustředil zejména na popis procesu projektového řízení IT projektů s pohledem na jednotlivé fáze celého projektu a shrnul jsem z mého pohledu nejdůležitější milníky celého projektu a informace o realizovaných fázích, včetně kompetencí jednotlivých pracovníků vystupujících na projektu. Vycházel jsem zejména z přístupu řešeným

metodickými postupy PMBOK®. V prostředí telekomunikačního operátora je nutná flexibilita projektů s ohledem na změny na trhu a z tohoto důvodu je mnou navržený proces založen na častém průběžném hodnocení a schvalování dalších kroků projektu, aby bylo této flexibility dosaženo efektivně bez zbytečných průtahů. Tato průběžná schvalování jsou nově přidanými kroky do procesu popisovaného v PMBOK®. Mezi posledním schválením projektu do realizace a nasazením jsou v ideálním případě tři měsíce a toto je z mého pohledu nejkratší doba, které je možné dosáhnout klasickým způsobem řízení projektů. Další zefektivnění procesu projektového řízení by mohlo být dosaženo agilním přístupem. Tento přístup je dlouhodobě ověřen pouze na menších projektech. Pro větší projekty nebyl zatím nalezen agilní přístup, který by byl efektivnější než klasické metody řízení. Toto nicméně nevylučuje použití agilního přístupu v rámci jednotlivých oddělení na realizaci jejich vlastních úkolů. Pevně věřím, že použití uvedených postupů v prostředí telekomunikačního operátora povede k větší transparentnosti jednotlivých projektů a s tím spojené větší úspěšnosti jednotlivých projektů.

53

5 Seznam použitých zdrojů 1. SCHWALBE, K.: Řízení projektů v IT Kompletní průvodce. Hana Krejčí, 6. vyd. Brno: Computer Press, 2010. 632 s. ISBN 978-80-251-2882-4. 2. DOUCEK, P.: Řízení projektů informačních systémů. 2. vyd. Praha: Professional Publishing, 2006. 180 s. ISBN 80-86946-17-7. 3. BUCKSTEEG, M. a kolektiv: ITIL® 2011. Alois Brázda, 1. vyd. Brno: Computer Press, 2012. 216 s. ISBN 978-80-251-3732-1. 4. DOLEŽAL, J. a kolektiv: Projektový management podle IPMA. 2. aktualizované a doplněné vydání. Praha: Grada Publishing, 2012. 526 s. ISBN 978-80-247-4275-5.

54

6 Seznam obrázků Obr. č. 1 – Záměr práce, strana 11 Obr. č. 2 - Útvarové projektové řízení, strana 18 Obr. č. 3 – Autonomní projektové řízení, strana 19 Obr. č. 4 – Maticové projektové řízení, strana 20 Obr. č. 5 – Síťové projektové řízení, strana 21 Obr. č. 6 – Rozdělení systémů u operátora, strana 30 Obr. č. 7 – Maticové projektové řízení, strana 33 Obr. č. 8 – Rozdělení projektových fází, strana 39 Obr. č. 9 – Příprava projektu, strana 39 Obr. č. 10 – Schválení projektu do realizace, strana 40 Obr. č. 11 – Zahájení projektu, strana 41 Obr. č. 12 – Analytická příprava projektu, strana 42 Obr. č. 13 – Návrh architektury, strana 43 Obr. č. 14 – Opětovné schválení projektu, strana 44 Obr. č. 15 – Vlastní implementace, strana 45 Obr. č. 16 – Testování, strana 46 Obr. č. 17 – Nasazení, strana 47 Obr. č. 18 – Předání do provozu, strana 48 Obr. č. 19 – Ukončení projektu, strana 49

55

7 Seznam tabulek Tab. č. 1 – Výstupy plánování projektu, strana 24 Tab. č. 2 – Výstupy realizace projektu, strana 26 Tab. č. 3 – Výstupy monitoringu a kontroly projektu, strana 27 Tab. č. 4 – Výstupy uzavření projektu, strana 29 Tab. č. 5 - Výstupy přípravy projektu, strana 40 Tab. č. 6 - Výstupy aktivity schválení projektu do realizace, strana 41 Tab. č. 7 - Výstupy aktivity zahájení projektu, strana 42 Tab. č. 8 - Výstupy analytické přípravy projektu, strana 43 Tab. č. 9 - Výstupy návrhu architektury, strana 44 Tab. č. 10 - Výstupy opětovného schválení projektu, strana 45 Tab. č. 11 - Výstupy vlastní implementace, strana 46 Tab. č. 12 - Výstupy testování, strana 47 Tab. č. 13 - Výstupy nasazení, strana 48 Tab. č. 14 - Výstupy předání do provozu, strana 48 Tab. č. 15 - Výstupy ukončení projektu, strana 49 Tab. č. 16 - Výstupy vyhodnocení projektu, strana 49

56

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Recommend Documents