Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Optimalizace procesů řízení projektů ve společnosti poskytující ICT služby
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Podniková informatika
Autor: Bc. Daniel Vávra
Vedoucí diplomové práce: Ing. Dušan Chlapek, Ph.D.
Praha, květen 2021
Prohlášení
Prohlašuji, že jsem diplomovou práci Optimalizace procesů řízení projektů ve společnosti poskytující ICT služby vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Praze dne 2. května 2021 ...
[jméno a příjmení autora]
Poděkování
Rád bych poděkoval Ing. Dušanovi Chlapkovi, PhD za odborné vedení a cenné rady při zpracování této práce.
Abstrakt
Tato diplomová práce popisuje optimalizaci procesů řízení projektů ve společnosti zabývající se ICT službami. Cílem práce je zmapovat současnou metodiku řízení projektů včetně jejích procesů, zhodnotit zralost těchto procesů a na základě měření navrhnout postup, jak procesy optimalizovat a realizovat vybrané kroky v rámci optimalizace procesů projektového řízení. Na základě zmapování současné metodiky řízení projektů a změření zralosti jednotlivých procesů metodou CMMI-DEv je určena úroveň zralosti procesů na úvodní úroveň, kdy jsou procesy vykonávány nahodile a chaoticky, jeden proces pak není vykonáván vůbec. S ohledem na toto zjištění je navržen a managementem společnosti schválen harmonogram úprav metodiky který si klade za cíl metodiku řízení projektů přepracovat a dále upravovat tak, aby reflektovala potřeby společnosti pro efektivní řízení projektů. Z daného harmonogramu je realizována první fáze, zjištění reálného stavu procesů, kde dojde k šetření, jak jsou procesy skutečně vykonávány. Částečně je pak realizována druhé fáze optimalizace procesů, která již ukazuje nově navržené procesy, nebo návrhy na jejich úpravu.
Klíčová slova
Optimalizace procesů, Řízení projektů, Procesy, Projektová metodika
Abstract
This diploma thesis describes the optimization of project management processes in a company dealing with ICT services. The aim of the work is to map the current
methodology of project management, including its processes, evaluate the maturity of these processes and based on measurements to design a procedure to optimize processes and implement selected steps in the optimization of project management processes. Based on the mapping of the current project management methodology and measuring the maturity of individual processes using the CMMI-DEv method, the level of process maturity is determined to the initial level, where processes are performed randomly and chaotically, then one process is not performed at all. Regarding this finding, a schedule of adjustments to the methodology is proposed and approved by the company's
management, which aims to rework the project management methodology and further adjust it to reflect the company's needs for effective project management. From the given schedule, the first phase is realized, finding out the real state of the processes, where it is investigated how the processes are performed. The second phase of process optimization is then partially implemented, which already shows the newly designed processes or proposals for their modification.
Keywords
Process optimalization, Project Management, Processes, Project methodology
Obsah
Úvod...12
1 Rešerše literatury ... 14
1.1 Kvalifikační práce ... 14
1.2 Odborná literatura... 15
1.3 Internetové zdroje ... 16
2 Vymezení pojmů a metodických kroků ... 18
2.1 Vymezení pojmů ... 18
2.1.1 Projekt ... 18
2.1.2 Projektové řízení ... 18
2.1.3 Metodika projektového řízení ... 18
2.1.4 Agilní metodiky ... 18
2.1.5 Klasické metodiky řízení projektů ... 19
2.1.6 Metodika PRINCE 2 Waterfall ...21
2.2 Vymezení metodických kroků ... 23
2.2.1 Určení stupně zralosti procesů ... 23
2.2.2 Záznam procesů ... 24
3 Zmapování současného stavu ... 27
3.1 Popis firmy ... 27
3.1.1 Nejčastější typy realizovaných projektů ... 27
3.2 Aktuální metodika řízení projektů Proces projektu... 28
3.2.1 Procesy řízení projektů ... 28
3.2.2 Dokumenty v projektu...31
3.2.3 Role v projektu ... 33
3.2.4 Nástroje používané pro řízení projektu ... 35
4 Zhodnocení zralosti procesů ... 36
4.1 Zahájení projektu ... 36
4.2 Příprava projektu ... 36
4.3 Plánování projektu ... 36
4.4 Řízení projektu ... 37
4.5 Realizace projektu ... 37
4.6 Ukončení projektu ... 37
4.7 Interní zhodnocení ... 37
4.8 Shrnutí kapitoly ... 37
5 Rozhodnutí o dalším postupu ... 38
5.1 Možné varianty ... 38
5.2 Podklady pro rozhodnutí ... 38
5.3 Rozhodnutí ... 41
5.4 Další postup ... 42
5.4.1 Fáze 1 – Zjištění reálného stavu procesů ... 43
5.4.2 Fáze 2 – Optimalizace procesů ... 44
5.4.3 Fáze 3 - Zavedení metodiky do provozu ... 45
5.4.4 Fáze 4 - Revize metodiky ... 45
5.4.5 Běžný provoz ... 46
6 Fáze 1 – Zjištění reálného stavu procesů ... 47
6.1 Procesy řízení projektů ... 47
6.1.1 Zahájení projektu ... 48
6.1.2 Příprava projektu ... 50
6.1.3 Plánování projektu... 53
6.1.4 Řízení projektu ... 54
6.1.5 Realizace projektu... 55
6.1.6 Ukončení projektu ... 57
6.2 Využití dokumentů... 60
6.3 Využití rolí ... 61
7 Fáze 2 – Optimalizace procesů ... 63
7.1 Procesy řízení projektů ... 64
7.1.1 Zahájení projektu ... 66
7.1.2 Příprava projektu ... 71
7.2 Využití dokumentů ... 74
7.2.1 Dokument TS_PROJ_Online_HowTo ... 75
7.3 Využití rolí ... 75
7.4 Shrnutí ... 76
Závěr ... 77
Použitá literatura ... 78 Přílohy ... I Příloha A: TS_PROJ_Online_HowTo.pdf ... I
Seznam obrázků
Obrázek 1 - Ganttův diagram při řízení projektů vodopádovou metodou (SkillForge,
nedatováno) ... 20
Obrázek 2 - Magický trojúhelník (Dhillon, 2018) ... 20
Obrázek 3 - Metodika PRINCE 2 (AXELOS, nedatováno) ...21
Obrázek 4 - Procesy PRINCE 2 v životním cyklu projektu (AXELOS, nedatováno) ... 23
Obrázek 5 - Tokové objekty BPMN (Vytvořeno v nástroji draw.io) ... 24
Obrázek 6 - Spojovací objekty BPMN (Vytvořeno v nástroji draw.io) ... 25
Obrázek 7 - Plavecké dráhy BPMN (Vytvořeno v nástroji draw.io) ... 25
Obrázek 8 - Artefakty BPMN (Vytvořeno v nástroji draw.io) ... 25
Obrázek 9 - Agile vs. Waterfall dle produktu projektu (GSA, nedatováno) ... 40
Obrázek 10 - Agile vs. Waterfall dle prostředí projektu (GSA, nedatováno) ... 41
Obrázek 11 - Harmonogram jednotlivých fází ... 42
Obrázek 12 – Harmonogram Fáze 1 – Zjištění reálného stavu procesů ... 43
Obrázek 13 - Harmonogram Fáze 2 - Optimalizace procesů ... 44
Obrázek 14 – Harmonogram Fáze 3 – Zavedení metodiky do provozu ... 45
Obrázek 15 - Procesy projektového řízení (Reálný stav) ... 48
Obrázek 16 - Proces TS_PM_01 - Zahájení projektu ... 49
Obrázek 17 - Proces TS_PM_02 – Příprava projektu ... 51
Obrázek 18 - Proces TS_PM_03 - Plánování projektu... 53
Obrázek 19 - Proces TS_PM_04 – Řízení projektu ... 54
Obrázek 20 – Proces TS_PM_05 - Realizace projektu ... 56
Obrázek 21 - Proces TS_PM_06 - Ukončení projektu ... 58
Obrázek 22 - Fáze 2 Proces Projektového Řízení v1.1 ... 65
Obrázek 23 - Proces TS_PM_01_v1.1 - Zahájení projektu ... 67
Obrázek 24 - Proces TS_PM_02_v1.1 - Příprava projektu ... 72
Seznam tabulek
Tabulka 1 – VZOR Tabulka pro záznam procesů (Meloun, 2019) ... 26
Tabulka 2 – Využití dokumentů dle metodiky Proces Projektu ... 33
Tabulka 3 – Využití rolí dle metodiky Proces Projektu ... 35
Tabulka 4 - Proces TS_PM_01 - Zahájení projektu ... 50
Tabulka 5 - Proces TS_PM_02 – Příprava projektu ... 52
Tabulka 6 - Proces TS_PM_03 - Plánování projektu... 53
Tabulka 7 - Proces TS_PM_04 – Řízení projektu... 55
Tabulka 8 – Proces TS_PM_05 - Realizace projektu ... 57
Tabulka 9 - Proces TS_PM_06 - Ukončení projektu ... 59
Tabulka 10 - Využití dokumentů v jednotlivých procesech (Reálný stav)... 60
Tabulka 11 - Využití rolí v jednotlivých procesech (Reálný stav) ... 61
Tabulka 12 - Proces TS_PM_01_v1.1 - Zahájení projektu ... 68
Tabulka 13 - Sub-Proces TS_PM_01_sub01_v1.1 - Ověření, zda se jedná projekt ... 69
Tabulka 14 - Sub-Proces TS_PM_01_sub02_v1.1 - Výběr projektového manažera ... 70
Tabulka 15 - Sub-Proces TS_PM_01_ sub03_v1.1 - Sestavení projektového teamu ... 71
Tabulka 16 - Proces – TS_PM_02_v1.1 - Příprava projektu ... 73
Tabulka 17 - Využití dokumentů v jednotlivých procesech ve verzi metodiky 1.1 ... 74
Tabulka 18 - Využití rolí v jednotlivých procesech ve verzi metodiky 1.1 ... 75
Seznam zkratek
BP bakalářská práce DP diplomová práce
FIS Fakulta informatiky a statistiky
UNESCO Organizace OSN pro vzdělání, vědu a kulturu NATO Severoatlantická aliance
IT Informační technologie
ICT Informační a komunikační technologie
L1 Technická podpora na nižší úrovni schopná řešit problémy na základě předem daných scénářů, jako návody, nebo postupy.
L2 Technická podpora s hlubší znalostí problematiky schopná řešit problémy které nejsou zaznamenány v návodech nebo již existujících postupech.
L3 Technická podpora specialistů s perfektními znalosti problematiky, může se jednat i o vývojáře samotného technického řešení
SLA Service Level Agreement – Smlouva o poskytované službě
SIEM Security Information and Evenet Management, je management bezpečnostních informací a událostí.
HR Human Resources – Oddělení řízení lidských zdrojů PID Project Initiation Documentation
Stakeholder Zainteresovaná strana
CRM Customer Relationship Management
BPMN Business Process Model and Notation, Notace pro zaznamenání procesů
Úvod
Důvod výběru tématu
Důvodem pro výběr tématu diplomové práce je autorovo dlouholeté působení v oblasti ICT služeb a v posledních letech v projektovém řízení v oblasti dodávek ICT služeb. Díky těmto zkušenostem lze pozorovat stále zvyšující se potřebu projektového vedení, kdy firmy vyžadují plánované a řízené vedení svých projektů dle stanoveného rozpočtu a harmonogramu. Řízení takovýchto projektů je na druhé straně nutné podpořit jasně specifikovanými projektovými metodikami, které reflektují oblast, ve které jsou projekty realizovány. V praxi se autor setkal s řízením projektů dle metodiky Proces Projektu založenou na metodice řízení projektů PRINCE2 Waterfall, spadající pod klasické vodopádové metodiky řízení projektu. Jedná se o metodiku upravenou pro využití v konkrétní společnosti, nicméně v aktuální situaci metodika ani stav projektového řízení v organizaci neodpovídá požadavkům kladených organizací na ně. V důsledku toho se práce bude zabývat optimalizací procesů v oblasti projektového řízení.
Cíle a přínos práce
• Prvním cílem práce je zmapovat současný stav řízení projektů ve společnosti.
Nejdříve dojde k popisu samotné společnosti a následně ke zmapování aktuální metodiky pro řízení projektů, jejích procesů, dokumentů, rolí a nástrojů. Na základě zmapování aktuální metodiky budou u jednotlivých procesů projektového řízení určeny stupně zralosti. Metrikou splnění daného cíle je pak vytvoření detailního popisu využívané metodiky včetně projektové dokumentace a následně popis a určení stupně zralosti jednotlivých procesů projektového řízení ve společnosti
• Druhým cílem práce je na základě zjištěného stupně zralosti jednotlivých procesů projektového řízení rozhodnout o dalším postupu pro optimalizaci jednotlivých procesů. A dále rozvrhnout úpravy do jednotlivých kroků, kdy jednou z forem optimalizace může být implementace agilní metodiky řízení projektů do stávající metodiky. Metrikou splnění tohoto cíle je rozhodnutí o dalším postupu provedené na základě uvedených argumentů a plán dalšího rozvoje.
• Třetím cílem práce je realizace vybraných kroků optimalizace procesů navržených v rámci druhého cíle práce. Metrikou splnění daného cíle je provést minimálně 1 další krok pro optimalizaci procesů.
Hlavní přínos práce vidím v optimalizaci procesů projektového řízení, kdy optimalizované procesy mohou pomoc společnosti odhalit skryté problémy a chyby aktuální metodiky řízení projektů. Zároveň práce lépe přiblíží to, jak vypadá řízení projektů ve společnosti zabývající se poskytováním ICT služeb a jaké typy projektů jsou v takové společnosti vedeny.
Postup práce
V začátku se práce soustředí na vymezení jednotlivých pojmů a metodických kroků. V rámci pojmů se zaměřuje na klíčové pojmy pro oblast práce např. co to je projekt a projektové řízení, co to je metodika řízení projektů a jaké typy metodik řízení projektů jsou včetně představení klíčové metodiky pro tuto práci. Ve vymezení metodických kroků je v práci popsáno, jakým způsobem proběhne zhodnocení zralosti procesů a zároveň jakým způsobem jsou jednotlivé procesy projektového řízení ve společnosti zaznamenávány, jak graficky, tak písemně. Po dokončení vymezení pojmů a metodických kroků se práce soustředí na zmapování současného stavu řízení projektů ve společnosti, kdy je nejprve popsána samotná společnost a zároveň typy projektů, které jsou ve společnosti vedeny.
Následuje popis aktuální metodiky řízení projektů, jejích procesů řízení projektů, popsání jednotlivých dokumentů, které metodiky využívá, dále také rolí, které se na projektech podílejí a nástrojů, které společnost využívá pro podporu řízení projektů. Jakmile proběhne zmapování současného stavu, které slouží jako úvod do situace společnosti následuje zhodnocení zralosti procesů projektového řízení dle zvolené metody. Na základě zhodnocení zralosti a zjištění výsledků zralosti dojde k rozhodnutí o dalším postupu. Rozhodnutí o dalším postupu navrhuje možné varianty rozhodnutí a zároveň poskytuje potřebné podklady pro učinění takového rozhodnutí managementem společnosti. Po provedení a argumentaci rozhodnutí se práce soustředí na navržení jednotlivých kroků, jak procesy optimalizovat. Zároveň navrhuje harmonogram provedení optimalizace procesů řízení projektů. Na základě navrženého harmonogramu je vybrán seznam kroků, které jsou v rámci práce realizovány a realizace těchto kroků je v práci popsána a vysvětlena. V samém závěru práce autor rekapituluje jednotlivé cíle a mapuje tyto cíle na výstupy práce.
1 Rešerše literatury
Rešerše literatury je rozdělena do několika skupin dle typu literatury. První skupinou jsou kvalifikační práce studentů vysokých škol, zejména pak Vysoké školy ekonomické v Praze.
Další skupinou je odborná literatura, která je využívána jako primární zdroj pro práci.
Poslední skupinou jsou zdroje z internetu a zároveň interní dokumenty společnosti, ze kterých práce čerpá při zkoumání aktuálního stavu.
Další možnou variantou struktury rešerše by bylo rozdělit jednotlivé zdroje dle cílů, které by práce podporovala. Nicméně každý zdroj může být využit pro dosažení více cílů, dělení dle typu práce se tak jeví jako přehlednější volba.
1.1 Kvalifikační práce
Diplomová práce zabývající se agilními metodikami, zejména pak pro vývoj software je práce Problematika výběru agilní metodiky vývoje software (Fujdiar, 2014), která si kladce za cíl vytvořit rámec pro výběr agilní metodiky, tak aby co nejlépe reflektovala specifika uživatele tohoto rámce. I přes cílení na vývoj software lze tuto práci využít díky přehledu agilních metodik a čerpat z ní informace o obecných agilních metodikách.
Diplomová práce Optimalizace podnikových procesů v oblasti řízení projektů (Meloun, 2019) se zabývá zlepšováním procesů v rámci projektového řízení. Analytická část práce, kde autor popisuje jednotlivé procesy ve firmě jasnou a strukturovanou formou se může stát vzorem pro zaznamenání jednotlivých procesů projektového řízení organizace v tomto projektu. V začátku autor vytvořil procesní mapu v rámci řízení projektů a následně vytvořil pro každý proces tabulku popisu proces. Práce Optimalizace podnikových procesů v oblasti řízení projektů ve své analytické části do jisté míry kopíruje i cíle této práce samozřejmě s rozdílem v hodnocených společnostech, z tohoto důvodu je tato práce přínosem pro dané téma.
Práce Řízení softwarových projektů dle metodiky PRINCE2 Agile (Suchá, 2019) zabývající se implementací metodiky PRINCE2 Agile do společnosti zabývající se stavbou datových skladů. Práce popisuje agilní metodiky a soustředí se na detailní popis PRINCE2 Agile a tuto metodiky zároveň implementuje do řízení projektů ve společnosti. I přes rozdílný výchozí stav, kdy autorka práce implementuje metodiky na tzv. zelené louce, kdy ve výchozí situaci metodiky neexistovala má práce značný přínos k tématu této práce a jedná se o jednu z mála prací zabývajících se metodikou PRINCE2 Agile.
Diplomová práce Návrh generické agilní metodiky řízení projektů (Bazala, 2015) soustředící se na návrh generické agilní metodiky pro řízení projektů může být pro tuto práci základním stavební kamenem. Autor v práci popisuje aktuální situaci agilních metodik, kdy většina se soustředí zejména na vývoj software, ale už nikoliv na obecnou rovinu řízení projektu. Z toho důvodu navrhl generickou agilní metodiky, kterou lze využít
i v jiných projektech. Tato pak bude sloužit jako inspirace při implementaci jednotlivých principů a postupů, jelikož většina agilních metodik je přizpůsobena právě softwarovým projektům.
Diplomová práce Řízení IT projektu podle metodiky PRINCE2 (Klimeš, 2014) zabývající se zkoumáním již proběhlého projektu v organizaci, kde autor pracoval a zároveň porovnává, jak by projekt vypadal v případě, že by byl řízen pomocí metodikou PRINCE2 Waterfall.
Práce tak přináší detailní rozbor metodiky PRINCE2 Waterfall, který bude ve vztahu k této práci sloužit jako doplnění stávajících zdrojů k metodice PRINCE2.
Diplomová práce Zlepšování výkonnosti procesů organizace na bázi potenciálu zlepšení (Hemala, 2012) se zabývá aplikováním metodiky pro dosažení potenciálu zlepšení v prostředí výrobní společnosti. Autor v práci zároveň analyzuje zralost jednotlivých procesů dle metodiky CMMI, kdy zjištěný aktuální stav dále rozvádí a přetváří do budoucího řešení. Tato práce provede hodnocení stupně zralosti procesů dle metodiky CMMI pouze pro uvedení čtenáře do aktuálního stavu ve firmě pro získání většího přehledu o procesech firmy. Tato práce je užitečná z důvodu jasně popsaného hodnocení stupňů zralostí dle metodiky CMMI.
1.2 Odborná literatura
Publikace Agilní metodiky a správa požadavků (Buchalcevová, 2007) se zabývá správou požadavků v agilních a vodopádových metodikách. V úvodu práce popisuje rozdíly mezi vodopádovými a agilními metodikami, poté přechází k vysvětlení správy požadavků v rámci vodopádových metodikách a následně správu požadavků v agilních metodikách, jmenovitě v Extrémním programování, Feature Driven Development a Scrum. Publikace se soustředí zejména na vývoj software, který je zcela odlišný od dodávek ICT služeb, na kterou se tato práce soustředí.
Základní pravidla v rámci aplikování agilních principů a postupů jsou pak zaznamenána v Manifestu Agilního vývoje software (Beck, et al., 2001), která jasně udává svůj cil a principy vývoje software. I když se tato práce nezabývá vývojem software, tak jsou jednotlivé principy a myšlenky aplikovatelné i na projekty v rámci ICT trhu. Jako takovou přínos práce vidím zejména v řízení cílového stavu tak, aby aplikované principy a postupy skutečně splňovali kritéria agilních metodik.
Kniha Tvorba informačních systémů: Principy, metodiky, architektury (Bruckner, et al., 2012) popisují tvorbu informačních systémů přináší jasný pohled na metodu CMMI-DEv, která bude využita při určení stupně zralosti procesů projektového řízení v organizaci.
Kniha PRINCE2 Agile An Implementation Pocket Guide: Step-by-step advice for every project type (Cooke, 2016) vysvětluje princip metodiky PRINCE2 Agile a jak tuto metodiku implementovat na jakýkoliv projekt v organizaci. Práce zároveň upřesňuje implementaci metodiky dle počátečního stavu, kdy popisuje pět různých počátečních stavů, a to přechod z PRINCE2 Waterfall, implementaci do současné metodiky PRINCE2 Waterfall, přechod z existující Waterfall metodiky, implementaci bez počáteční metodiky a přechod z již
existující agilní metodiky na PRINCE2 Agile. Tato kniha bude mít zásadní přínos na tuto práci, jelikož bude sloužit jako průvode implementací metodiky PRINCE2 Agile, ale zároveň taky jako zdroj informací o PRINCE2 Agile.
Práce CMMI® for Development, Version 1.2 (Software Engineering Institute, 2006) obsahuje ověřené praktiky pro zlepšení procesů vývoje a uchování produktů a služeb vycházející z frameworku CMMI. Práce jasně definuje jednotlivé stupně zralosti metodiky CMMI, které budou využity při vyhodnocení stupně zralosti procesů projektového řízení v rámci zjišťování aktuálního stavu procesů projektového řízení ve společnosti v této práci.
Materiály k certifikačnímu kurzu PRINCE 2® Foundation (TAYLLORCOX, 2018) sloužící k výuce metodiky řízení projektů PRINCE 2 v rámci certifikačních kurzů budou sloužit jako základní zdroj dat o metodice PRINCE 2, která je aktuálně využívána ve společnosti pro řízení projektů, kdy dle stejných materiálů probíhalo školení všech projektových manažerů ve společnosti a na základě těchto školení proběhlo vytvoření aktuální metodiky projektového řízení. Tato práce má přínos v detailním vysvětlení problematiky PRINCE 2, popsání jejich principů a témat.
Dalším zdrojem v rámci metodiky PRINCE2 Waterfall je kniha Základy metody projektového řízení PRINCE2 (Bentley, 2016), která jako dvojjazyčná kniha přispívá k pochopení problematiky PRINCE2, ale zároveň i k pochopení terminologie která se v rámci metodiky vyskytuje. Pro tuto práci pak bude mít přínos při vysvětlení metodiky PRINCE2 a jejím detailním popsání. Jedná se o materiál pro projektové manažery, účastníky školení PRINCE2 Waterfall, úrovně Foundation, projektovým týmům apod.
Jako další zdroj budou využity studijní materiály pro předmět 4IT414 – Řízení projektů IS/ICT na Vysoké škole ekonomické v Praze Řízení projektů IS/ICT: (pracovní sešity k přednáškám a cvičením) (Chlapek, 2004) díky celkovému přehledu o řízení projektů, vysvětlením jednotlivých pojmů v rámci projektového řízení a zejména vysvětlení postupu implementace metodiky projektového řízení do organizace
1.3 Internetové zdroje
Odborný článek Apply agile methodology to non-software enterprise project (Vandersluis, 2014) se pak přímo zabývá aplikováním agilních metodik a jejich jednotlivých principů a postupů na projekty, které se nezabývají vývojem software. Práce nejdříve vymezuje Agilní metodiky a následně pojem non-software enterprise project, tedy nesoftwarové firemní projekty. Následně se již soustředí na specifické praktiky, které lze z agilních metodik převzít. V závěru se pak práce věnuje potencionálním hrozbám při implementaci agilních praktik do klasického způsobu vedení projektů. Tuto práci považuji ve vztahu k tématu aktuální práce jako velice přínosnou práce má přínos v jasnějším pohledu na implementaci agilní metodiky.
Odborný článek Applying Agile Project Management to Professional Services Projects (Benzakein, 2016) popisuje specifické využití agilních metodik a přetvoření do hybridní metodiky, kdy projekty musejí dodržovat základní pravidla pro akceptaci této metodiky
klienty, ale zároveň využití metodiky SCRUM v jádru. Tento článek považuji za přínosný díky vytvoření hybridní agilní metodiky, která respektuje všechna specifika trhu a zároveň ctí potřeby klienta, ale zároveň využívá agilní metodiku.
2 Vymezení pojmů a metodických kroků
Tato kapitola si klade za cíl popsat jednotlivé pojmy, které jsou dále využity v práci a zároveň vymezit jednotlivé metodiky a metodické kroky.
2.1 Vymezení pojmů
2.1.1 Projekt
Projekt je specifická množina činnost, s jasně definovaným začátkem a koncem, vytvořených za účelem dosažením určitého cíle, který musí být doručen v souladu s původně určeným rozpočtem, obsahem, kvalitě a čase. (PMI, nedatováno)
2.1.2 Projektové řízení
Projektové řízení je aplikování určitých procesů, metod, zkušeností a znalostí pro dosažení specifikovaného cíle dle předem dojednaných kritérií. Největším rozdílem projektového managementu oproti klasickému managementu je limitovaná doba trvání, kdy projekty mají jasně definovaný začátek i konec. (APM, nedatováno)
2.1.3 Metodika projektového řízení
Metodika projektového řízení je interní nástroj organizace, který definuje způsob řízení projektů v organizaci. Stanovuje podmínky, náležitosti a jednotlivé procesy spojené s řízením projektu v organizaci za účelem sjednocení způsobu vedení projektu pro dosažení největší efektivity při vedení projektu. (Jihomoravský Kraj, nedatováno)
2.1.4 Agilní metodiky
Agilní metodiky jsou takové metodiky pro řízení projektů, které dokážou pružně reagovat na změnu v rámci projektu a přijmout ji (Management Mania, 2016).
Agilní metodiky začali vznikat v druhé polovině 90 let, jako reakce na vysokou míru softwarových projektů, které nepřinášeli svému zákazníkovi požadovanou hodnotu. Agilní metodiky se soustředí na odlehčení a zjednodušení procesů tak, aby bylo výsledku dosaženo co nejefektivněji (Buchalcevová, 2007). V roce 2001 pak byli agilní metodiky definovány v Manifestu Agilního vývoje software, který zastává následující hodnoty shodné pro všechny agilní metodiky:
„Jednotlivci a interakce před procesy a nástroji, Fungující software před vyčerpávající dokumentací, Spolupráce se zákazníkem před vyjednáváním o smlouvě, Reagování na změny před dodržováním plánu
Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více.“ (Beck, et al., 2001) Agilní metodiky se zároveň řídí principy agilního vývoje software:
„Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje.
Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. Hlavním měřítkem pokroku je fungující software. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. Jednoduchost--umění maximalizovat množství nevykonané práce--je klíčová.
Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.“ (Beck, et al., 2001)
Zástupci agilních metodik jsou pak metodiky: SCRUM, Extreme Programming, Lean Development, Kanban a PRINCE2 Agile. Tato práce se dále soustředí na pouze na poslední zmíněnou metodiku, a to na PRINCE2 Agile, ostatní metodiky z tohoto důvodu nebudou dále rozvedeny.
2.1.5 Klasické metodiky řízení projektů
Klasické metody řízení projektů, nebo také vodopádové metodiky (angl. Waterfall), byli představeny v roce 1970 a jednalo se proces vývoje software rozděleného do 9 fází, kdy každá fáze závisí na dokončení předchozí fáze (Rerych, nedatováno). Pro grafické znázornění plánování jednotlivých úkonů v rámci projektu byl využíván Ganttův diagram, díky tomu se klasickým metodikám říká také vodopádové.
Obrázek 1 - Ganttův diagram při řízení projektů vodopádovou metodou (SkillForge, nedatováno) V reálném použití jsou pak vodopádové metodiky založeny na naplánování určitých kroků a následném dodržování postupů při realizaci projektu. Projekty mají přesně daný časový, obsahový i finanční rámec a prostor pro změny v rámci projektu je minimální. Klasický přístup pro řízení projektů je vhodný zejména pro ty projekty, kde lze před realizací jasně definovat jejich rozsah a minimalizovat jeho změny. Při řízení projektu vodopádovou metodikou řízení projektů je úkol projektového manažera udržet projekt v rámci stanoveného rozsahu, času a rozpočtu. Tyto tři hodnoty jsou označovány jako magický trojúhelník, popřípadě také jako trojúhelník projektového řízení (Management Mania, 2015).
Obrázek 2 - Magický trojúhelník (Dhillon, 2018)
Magický trojúhelník pak má graficky znázornit, že pokud dojde ke změně jedné ze sil působících v rámci trojúhelníku, může dojít ke destabilizaci projektu (Dhillon, 2018).
V reálném případě se tak může stát, že se zvětší rozsah (scope) projektu, v tu chvíli nebudou ostatní síly působící v trojúhelníku dostatečně silné, tak aby produkt projektu dokázali doručit za původní cenu a čas, jedna změny si tak vyžádá změnu ostatní sil.
Zástupci vodopádových metodik pro řízení projektů jsou: PRINCE2 Waterfall, PMBOK, MMDIS, RUP.
2.1.6 Metodika PRINCE 2 Waterfall
Metodika PRINCE 2 Waterfall, nebo také pouze PRINCE 2 je škálovatelná flexibilní metodika pro řízení projektů. Metodika PRINCE 2 sestává ze sedmi principů, témat a procesů (AXELOS, nedatováno).
Obrázek 3 - Metodika PRINCE 2 (AXELOS, nedatováno)
Principy metodiky PRINCE 2
1. Průběžné zdůvodňování projektu 2. Učení se ze zkušeností
3. Definované role a odpovědnosti 4. Řízená po etapách
5. Řízená výjimkami 6. Zaměřená na produkt
7. Přizpůsobená prostředí projektu
První princip, průběžné zdůvodňování znamená, že projekt musí mít důvod pro svou realizaci, pokud není důvod projekt by měl být ukončen. Druhý princip, učení ze zkušeností, říká, že projektový team by měl průběžně hledat a poučení ze své práce. Třetí princip definování rolí a odpovědností pak znamená, že projekt by měl mít jasnou organizační strukturu, kdo a jak je za daný úkol zodpovědný. Čtvrtý princip, řízen po etapách znamená,
že by projekt měl být rozdělen na jednotlivé etapy, které by měly být plánovány, řízeny a kontrolovány samostatně. Pátý princip řízen výjimkami, udává že lidé pracující na projektu by měli mít správnou úroveň oprávnění, tak aby řešili problémy, které jim náleží efektivně.
Šestý princip zaměřen na produkt říká, že projekt se má zaměřit na definic produktu, kvalitu a doručení. Poslední sedmý princip pak říká, že samotná metodika by měla být přizpůsobena prostředí, velikosti, komplexitě, důležitosti, schopnostem a rizikům projektu (AXELOS, nedatováno).
Témata metodiky PRINCE 2 1. Zdůvodnění projektu 2. Organizace
3. Kvalita 4. Plány 5. Rizika 6. Změna 7. Postup
Zdůvodnění projektu říká, že by mělo existovat a být aktualizováno odůvodnění, proč je projekt realizován. Organizace říká že by mělo existovat rozdělení rolí a odpovědností pro celý projektový team. Kvalita říká, jaké nároky na kvalitu jsou v projektu zakotveny a jak je projekt doručí. Rizika popisují, jaká rizika a příležitosti pro projekt existují a jak mohou projekt ovlivnit. Změna udává, jak projektový manažer řídí změny oproti původnímu zadání. Postup říká, kam projekt směřuje podle aktuálního plánu a zda by měl pokračovat (AXELOS, nedatováno).
Procesy metodiky PRINCE 2
1. Zahájení projektu (Starting up a project) 2. Nastavení projektu (Initiating a project) 3. Směřování projektu (Directing a project) 4. Kontrola etapy (Controlling a stage)
5. Řízení dodávky produktu (Managing product delivery) 6. Řízení přechodu mezi etapami (Managing stage boundaries) 7. Ukončení projektu (Closing a project)
Zahájení projektu je proces, který zajišťuje všechny předpoklady pro fázi nastavení (iniciace) projektu. Proces nastavení (iniciace) projektu řeší, zda má projekt dostatečné zdůvodnění, definuje kvalitu, harmonogram, náklady, analýzu rizik a zdroje. Směřování projektu umožňuje projektovému výboru dělat klíčová rozhodnutí a mít celkovou kontrolu, zatímco projektový manažer řeší denní operativu projektu. Kontrola etapy je proces, kde projektový manažer přiřazuje členům projektového teamu práci, monitoruje její průběh, řeší problémy a reportuje postup projektovému výboru. Řízení dodávky projektu je proces, který má za cíl řídit a kontrolovat práci mezi projektovým manažerem a teamovými manažery. Řízení přechodu mezi etapami je proces, který má za cíl poskytovat projektovému výboru přehled a postupu jednotlivých fází, aktualizovat projektový plán, obchodní případ a plán na další fázi. Projektový výbor reviduje aktuální fázi a schvaluje
přechod do nové fáze. Ukončení projektu je pak proces, kdy je potřeba ověřit, zda projekt dosáhl svých cílů a produkt byl akceptován (Turley, nedatováno).
Obrázek 4 - Procesy PRINCE 2 v životním cyklu projektu (AXELOS, nedatováno)
Na Obrázek 4 - Procesy PRINCE 2 v životním cyklu projektu (AXELOS, nedatováno) je možné pozorovat, jak na sebe jednotlivé procesy navazují v rámci životního cyklu projektu.
Cyklus má 5 částí, a to Před projektem (Pre-Project), Iniciace (Initiation stage), Následující etapy (Subsequent stage), Finální etapa (Final stage) a Po projektu (Post-Project). V rámci Pre-Project probíhá proces Zahájení projektu. V Iniciace probíhá Směřování projektu, Řízení přechodu mezi etapami a Nastavení projektu. V Následujících etapách probíhá Směřování projektu, Řízení přechodu mezi etapami, Kontrola etapy, Řízení dodávky produktu. Finální etapa pak obsahuje procesy Ukončení projektu, Kontrola etapy a Řízení dodávky produktu (AXELOS, nedatováno).
2.2 Vymezení metodických kroků
2.2.1 Určení stupně zralosti procesů
Pro určení stupňů zralostí procesů spojených s projektovým řízením je použita metoda CMMI for Development (CMMI-DEv), která je reprezentován 5 úrovněmi zralosti procesů:
• 1: Úvodní – Náhodné a chaotické procesy, výkon organizace spočívá na zaměstnancích, a ne na osvědčených postupech. Společnost často překračuje rozpočet a harmonogram.
• 2: Řízený – Definovány a zavedeny řídící procesy, procesy se provádějí dle popisu a plánu, jsou monitorovány.
• 3: Definovaný – Definovaný proces na úrovni organizace, popsán ve standardech, procedurách, nástrojích a metodách. Dosaženy předešlé úrovně zralosti.
• 4: Kvantitativně řízený – Procesy jsou řízeny pomocí statistických technik. Sub- Procesy mají jasně definované metriky, které jsou kontrolovány a vyhodnocovány.
Dosaženy předešlé úrovně zralosti.
• 5: Optimalizovaný – Optimalizovaný stupeň zralosti procesů dosáhl všech předchozích úrovní, procesy jsou neustále zlepšovány na základě vyhodnocování dosažených metrik a chápání příčiny změn v průběhu procesů
Pro každou úroveň zralosti procesů, kterou si společnost zvolí jako svůj cíl, již existují definované procesy, které společnost musí implementovat (Bruckner, et al., 2012).
2.2.2 Záznam procesů
V práci jsou zaznamenány procesy, a to jak grafickou formou, tak formou textového zápisu v tabulkách.
Model
Grafický model procesů je realizován pomocí notace BPMN, Business Process Model and Notation. Jedná se o notaci pro vytváření firemních procesních modelů, které jsou schopné obsáhnout požadovanou komplexnost. Jednotlivé prvky, ze kterých se notace skládá jsou pak snadno rozlišitelné a tvary snadno identifikovatelné (White, 2014).
Notace BPMN má 4 základní grafické prvky a to:
• Tokové objekty
• Spojovací objekty
• Plavecké dráhy
• Artefakty
Obrázek 5 - Tokové objekty BPMN (Vytvořeno v nástroji draw.io)
Obrázek 5 - Tokové objekty BPMN (Vytvořeno v nástroji draw.io) ukazuje jednotlivé tokové objekty jak události, kterými proces začíná a končí. Aktivita, ze kterých je proces tvořen, kdy Aktivita s malým plus uprostřed dole značí sub-proces. Brány jsou vyznačeny kosočtvercem, kdy vnitřní značka značí chování brány, exklusivní brána značí pouze jednou možnou cestu.
Paralelní brána značí tok více než jedné aktivity, nebo spojení z více aktivit. Inklusivní brána značí že jedna nebo více nebo žádná aktivita může být vybrána. Komplexní brána ukazuje komplexní toky, kdy vyžadují více popisného textu za účelem popsání chování brány (Lucidchart, nedatováno).
Obrázek 6 - Spojovací objekty BPMN (Vytvořeno v nástroji draw.io)
Obrázek 6 - Spojovací objekty BPMN (Vytvořeno v nástroji draw.io) ukazuje propojení jednotlivých objektů, kdy sekvenční tok spojuje aktivity a udává pořadí v jakém budou aktivity vykonávány. Tok zpráv pak zobrazuje zprávy, které si mezi sebou jednotlivé role posílají (White, 2014).
Obrázek 7 - Plavecké dráhy BPMN (Vytvořeno v nástroji draw.io)
Obrázek 7 - Plavecké dráhy BPMN (Vytvořeno v nástroji draw.io) ukazuje Bazén, který slouží pro oddělení aktivit mezi procesy. Dráha je pak pod úrovní bazénu a využívají se pro jednotlivé role nebo kategorizaci aktivit (White, 2014).
Obrázek 8 - Artefakty BPMN (Vytvořeno v nástroji draw.io)
Obrázek 8 - Artefakty BPMN (Vytvořeno v nástroji draw.io) pak ukazuje Datové objekty, jedná s o způsob, jakým vyjádřit jaké dokumenty a data jsou potřeba v rámci aktivit. Data
Store pak slouží pro zobrazení zachování dat jako jsou informační systémy. Seskupení slouží pro oddělení aktivit, ale nemá vliv na sekvenční toky procesů. Anotace pak poskytuje způsob, jak doplnit objekt o informační text.
Popis
Popis proces v tabulkách bude zaznamenán pomocí Tabulka 1 – VZOR Tabulka pro záznam procesů, kdy formát této tabulky byl převzat z práce Optimalizace podnikových procesů v oblasti řízení projektů (Meloun, 2019).
ID Procesu ID procesu slouží jako unikátní identifikátor procesu Název procesu Název procesu je vybrán dle názvu aktuálních procesů Cíl procesu Cíl procesu představuje, čeho se proces snaží dosáhnout
Vstupy Vstupy představují skutečnosti na základě, kterých proces může začít
Výstupy Výstupy jsou možné konce, jak daný proces může být ukončen
Vykonavatel Vykonavatel jsou všechny role, které se účastní na chodu procesu Vlastník
procesu Vlastník procesu je role, která je odpovědná za průběh procesu Zákazník
procesu Zákazník procesu je role, pro kterou je výstup procesu určen Popis procesu Popis procesu je pole, ve kterém je detailně vysvětleno, jak proces
funguje a jaké role, které kroky provádějí Tabulka 1 – VZOR Tabulka pro záznam procesů (Meloun, 2019)
3 Zmapování současného stavu
Tato kapitola se soustředí na uvedení čtenáře do aktuálního stavu v rámci společnosti.
Popsání společnosti, jejího podnikání a metodiky řízení projektů, kterou společnost využívá, její postup a využívané dokumenty.
3.1 Popis firmy
Společnost na jejíž metodiku projektového řízení se práce zaměřuje je jedním z větších poskytovatelů ICT služeb v České republice. Společnost má přes 100 zaměstnanců, rozdělných do 4 divizí, technická, obchodní, logistická a HR. Nabízené služby lze pak rozdělit do 2 kategorií.
První kategorií je podpora a rozvoj ICT u daného klienta na základě dojednané SLA smlouvy, která jasně definuje práva, povinnosti, rozsah a zodpovědnost každé strany pro poskytování a přijímání služby. Tyto služby jsou poskytovány techniky, jak v sídle klienta dle definovaného harmonogramu přítomnosti jednotlivých techniků na místě, tak i vzdáleně. Podpora pak probíhá v pracovní i mimopracovní době v úrovních L1, L2 a L3.
Služby techniků jsou běžně zaštitovány pozicí technického garanta, který garantuje úroveň dodávané služby dle potřeb klienta. Služba jako celek je pak zaštiťovaná account managerem jednajícím přímo s klientem. Práce poskytované pro SLA klienty čítají práce jako: správa koncových stanic, serverů, sítí, SIEM, správa domén a hostingu, call desk hotline podpora.
Další kategorií služeb společnosti je dodávka hardware, software a služeb (nad rámec sjednaného SLA, pokud existuje) na základě objednávek smluvních partnerů, pravidelných zákazníků, popřípadě veřejných zakázek.
3.1.1 Nejčastější typy realizovaných projektů
Ve společnosti je projekt chápán jako dodávka hardware, software, nebo služeb a jejich implementace v rozsahu nad 3 Man Day (MD), tedy na více než 3 člověko dny do prostředí zákazníka. Samotné projekty pak nejsou interně kategorizovány, ale pro lepší pochopení lze projekty rozdělit do dvou skupin, do které spadá většina projektů ve společnosti:
1. Projekty pro státní správu, tedy projekty vysoutěžené na základě výběrového řízení státní organizací. Takové projekty mají v uzavřené smlouvě zafixován rozsah, náklady a harmonogram. Tyto projekty zároveň vyžadují větší administrativní zátěž a dle obsahu projektu pak podléhají i zákonu o kybernetické bezpečnosti (181/2014 Sb.).
2. Projekty pro SLA klienty, jedná se o projekty dodávané pro stálé klienty v případě, že je potřeba obnovit infrastrukturu, popřípadě dodat nové technologie. Tyto projekty fungují ne vždy dodržují výše popsaný magický trojúhelník a lze na základě požadavku klienta a vzájemné shodě s jednotlivými body trojúhelníku pohybovat.
Produkty projektu pak lze kategorizovat do následujících oblastí:
1. Infrastrukturní práce, dodávky a implementace serverů, operačních systémů, sítových prvků, zálohovacích řešení. Obměna stávající infrastruktury, popřípadě budování nové infrastruktury pro klienta. Může se jednat o řešení pro menší klienty od 10 zaměstnanců až po vybudování synchronizovaných geograficky rozložených datových center s vysokou dostupností. Takové řešení pak může být využíváno pro tisíce uživatelů
2. Dodávky bezpečnostních řešení v podobě technologií SIEM – Security Information and Event Management, tedy Správy bezpečnostních informací a událostí. Takový produkt projektu spočívá v dodání a nasazení platformy pro SIEM a následný tailoring na potřeby klienta
3. Konzultační práce v oblasti informační a kybernetické bezpečnosti. Pomoc klientům tak, aby byli v souladu se zákonem o kybernetické bezpečnosti (181/2014 Sb.)., nasazení systému řízení bezpečnosti informací ISMS, hodnocení rizik primárních a podpůrných aktiv a spojení, dodávky služeb SMC – Security Management Center v podobě analýzy dat z řešení SIEM, doplnění o procesní data a vizualizace na jedné platformě pro podporu manažerských rozhodnutí
4. Dodávky koncových stanic a periferií pro klienty
5. Dodávky technologií pro interní komunikaci ve společnosti v podobě Cisco Webex, Cisco Webex Meetings a HW zařízení, která jsou určena do zasedacích místností.
3.2 Aktuální metodika řízení projektů Proces projektu
Aktuální metodika řízení projektů s názvem Proces Projektu byla odvozeny od metodiky PRINCE 2 Waterfall a dále upravena pro potřeby společnosti.
3.2.1 Procesy řízení projektů
Interní metodika je na základě PRINCE2 Waterfall rozdělena do 7 procesů tvořící jednotlivé fáze projektu. Následující odstavec pak popisuje chápání fází projektu v rámci organizace založeném na metodice PRINCE2 Waterfall.
Zahájení projektu
V této fázi dochází k identifikaci projektového záměru, jehož uskutečnění není z organizačních, časových nebo finančních důvodů možné řešit v rámci běžné operativy (u SLA klientů) a jeví se vhodné pro jeho realizaci ustanovit samostatný projekt. Cílem zpracování potencionálního projektu je identifikace námětu na nový projekt a definování základních bodů identifikovaného projektu tak, aby bylo možné stanovit cíl potenciálního projektu. Pokud je to možné, již v této inicializační fázi je nutná kompletní revize technické dokumentace daného klienta. Pokud je dokumentace neaktuální, neúplná nebo dokonce neexistuje, musí být tato skutečnost uvedena a měla být provedena revize prostředí.
Dle specifikace potencionálního projektu iniciátor projektu tento námět prokonzultuje s obchodním a technickým oddělením, které rozhodne o zpracování charty projektu. Po vypracování charty projektu, je tento dokument předložen ke schválení zákazníkovi.
Následně po odsouhlasení charty projektu dojde k vypracování obchodní nabídky.
Technická konzultace musí bezpodmínečně vždy předcházet té obchodní, aby nedošlo např.
k akvizici nevhodného HW, SW či celkově špatnému odhadu hodin nutných na realizaci projektu. Charta projektu je výchozí projektový dokument, který popisuje základní cíle projektu, jeho časový rámec a také výstupy, výsledky a dopady projektu a to vč. základních rizik spojených s realizací projektu.
V případě rozhodnutí o realizaci projektu je charta projektu dále postoupena příslušnému realizačnímu týmu k upřesnění jednotlivých bodů.
Příprava projektu
Fáze příprava projektu je realizována na základě schválené charty projektu, která popisuje základní parametry projektu ohodnocené v první fázi jako validní (tedy v daných podmínkách relevantní, vhodné, potřebné a proveditelné z hlediska dostupnosti zdrojů) a také po schválení obchodní nabídky.
V této fázi musí dojít k ustanovením pracovního týmu projektu dle typu, rozsahu a složitosti projektu. Kromě lidských zdrojů může nastat situace, kdy je nutné zajistit alokaci a následné uvolnění finančních prostředků pro nákup služeb třetích stran.
Původní schválení charty projektu se vyjadřovalo k projektu v parametrech, které byly v iniciační fázi pouhým odhadem. Po provedení všech analytických činností a zpracování prvotní verze charty projektu zpravidla dochází k změně některých parametrů projektu.
Realizační tým může zjistit nové informace a skutečnosti nezbytné pro úspěšnou realizaci projektu, které nebyly v okamžiku zpracování charty projektu známé.
V takovém případě musí dojít k informování všech zúčastněných stran a následném přepracování charty projektu do takové podoby, která bude relevantní, vůči nově zjištěným skutečnostem. Takto přepracovaná charta projektu musí být předložena ke schválení.
Plánování projektu
Cílem plánování projektu je definování projektu a vytvoření strategického plánu realizace s jeho základními parametry. Jde o podrobný popis jednotlivých fází projektu a splnění těchto klíčových bodů projektu. K jednotlivým fázím projektu je také nutné nadefinovat akceptační kritéria, dle který je možné hodnotit jednotlivé fáze projektu. Konečným výstupem je charta projektu, která z hlediska řízení projektu představuje zcela zásadní řídící dokument projektu.
Projektový manažer nadefinuje všechny aktivity nutné k plnění projektu. Seznam aktivit pokrývá veškeré aktivity spojené s celým projektem. Pro každou aktivitu projektu projektový manažer identifikuje potřebné lidské zdroje a definuje schopnosti a zkušenosti, které jsou potřebné k jejímu vykonání.
Projektový manažer ve spolupráci se členy realizačního týmu identifikuje potenciální rizika projektu. Je vhodné zvážit riziko zapojení každého konkrétního zdroje minimálně z několika hledisek (např. z hlediska dostupnosti, spolehlivosti, kvality výstupů apod.) a ověřit vůči rizikům veškeré předpoklady, na kterých projekt a jeho plán stojí. Ke každému identifikovanému riziku projektu realizační tým nadefinuje preventivní opatření pro zamezení jeho výskytu, popřípadě nápravná opatření pro minimalizaci jeho dopadů.
Veškerá rizika musí být uvedena v registru rizik projektu a porovnána s dokumentem
„Přehled získaných poznatků“ z předchozích projektů.
Řízení projektu
Projektový manažer řídí realizaci projektu v souladu s chartou projektu, za účelem úspěšné realizace projektu dle schválených podmínek a pravidel. Řízení projektu probíhá od přípravy projektu až po jeho předání. Je nutné jak řízení lidských zdrojů, tak i provedené práce v jednotlivých časových úsecích dle charty projektu.
Projektový manažer řídí a sleduje naplnění nadefinovaných indikátorů projektu, a to jak z pohledu plnění jednotlivých fází projektu, tak i z pohledu vykázané práce realizačního týmu.
V případě, že člen realizačního týmu zjistí, že je nutné projekt upravit z důvodu vyskytnutí se neočekávané situace, musí neprodleně informovat projektového manažera.
V případě zjištěných závažných chyb v průběhu projektu, zpracuje projektový manažer zprávu o tomto stavu a musí obeznámit všechny zúčastněné strany. Zároveň musí zajistit nápravu v co nejkratším časovém horizontu.
Realizace projektu
Realizace projektu je souhrnem činností vedoucích ke zhotovení věcných výstupů projektu v souladu s chartou projektu. Aktivity projektu jsou realizovány členy realizačního týmu pod vedením projektového manažera. Dle typu projektu monitoruje a kontroluje realizaci aktivit definovaných v chartě projektu. V průběhu realizace projektu je členy realizačního týmu projektu zpracovávána pracovní (operativní) dokumentace projektu (zápisy z jednání, status report atp.). Během realizace projektu je projektovým manažerem pravidelně realizován reporting o stavu realizace projektu (formou status reportu), jedná se zejména o poskytování informací o vývoji realizace projektu. Jednotlivý členové realizačního týmu vždy vykazují práci ve formě výkazu vykonané práce, a to v předem domluveném formátu.
Ukončení projektu
V rámci fáze Ukončení projektu dochází k akceptaci projektu a formálnímu a věcnému ukončení realizace. Finální projekt je prezentován dodavatelem. Na takovou prezentaci jsou projektovým manažerem povinně s dostatečným předstihem přizváni zástupci všech zúčastněných stran. Po finální akceptaci výstupů projektový manažer zpracuje závěrečnou zprávu (předávací protokol), ve které zhodnotí realizaci projektu a splnění či nesplnění jednotlivých fází projektu.
Interní zhodnocení
Po ukončení a předání projektu zadavateli dojde k internímu zhodnocení celého projektu.
Zároveň je finálně zpracován dokument „Přehled získaných poznatků“, ve kterém jsou uvedeny poznatky, které se objevily v průběhu projektu. V tomto hodnocení projektu jsou uvedeny přínosy, ztráty projektu, rozpad jednotlivých prací a vykázaných časů pro jednotlivé etapy projektu a formou strukturovaných dat je uvedeno i ponaučení z realizovaného projektu, tzv. Lesson Learned (Přehled získaných poznatků).
3.2.2 Dokumenty v projektu
Charta projektu
Charta projektu slouží ve společnosti jako základní dokument pro vedení projektu, obsahující všechny důležité informace. Projektová charta obsahuje 6 kapitol pokrývající jednotlivé náležitosti dokumentu pro vedení projektu.
Označení projektu, v této kapitole jsou uvedeny obecné věci ohledně správy dokumentu, jako jeho označení, název projektu a zákazníka, autor a verze. Zároveň je zde uvedena historie změn dokumentu, schválení dokumentu, distribuce a uvedené obchodní tajemství.
Definice projektu, kde je uveden mandát projektu, tedy informace vymezující zadání projektu. Zároveň zde jsou cíle projektu včetně časového rozsahu projektu. Určení jakosti, akceptační kritéria zákazníka, rozsah projektu, jakých technologií, infrastruktury a služeb se projekt bude týkat. Zároveň jsou v této kapitole uvedeny technické údaje specifické pro řešení, výpis možných rizik, pokud není k souboru přiložen registr rizik, omezení a předpoklady ze strany zadavatele a následně seznam uživatelů a zainteresovaných stran v rámci projektu.
Další kapitola Hrubý obchodní případ pak z pravidla udává rozpis jednotlivých prodaných prací včetně hodinových rozpočtů a zboží které bylo dodány. Tato kapitola bývá převzata z nabídky schválené klientem.
Kapitola Popis Produktu Projektu pak udává detailní popis řešení projektu, slovně popisující postup projektu tak, aby byl klientovi srozumitelný. Zároveň je zde uveden časový harmonogram jednotlivých prací, pokud není uveden v externím souboru. Kapitola dále zobrazuje seznam po instalačních prací, které nutně nespadají do projektu, ale v případě že zadavatel projektu je SLA klientem je nutné dohlédnout že tyto práce budou dokončeny po dokončení projektu. Zároveň jsou zde udávány celkové přehledy jednotlivých virtuálních serverů, fyzických serverů, aplikací, které se týkají produktu projektu.
Přílohy projektu je kapitola, kde je uveden soupis všech příloh, které v dokumentu budou figurovat jako registr rizik, harmonogram, Lessons Learned, externí seznamy dle vyžádání zadavatele.
Poslední kapitolou v rámci charty projektu je popis rolí, kde jsou specifikované oficiální role v projektu ze strany zadavatele a dodavatele, kdy je v obou případech uveden projektový tým.
Registr rizik
Registr rizik je dokument specifikující rizika, která mohou nastat v rámci projektu. Jedná se o tabulku, která specifikuje dané riziko, oblast, které se týká, popis rizika, jeho dopad, pravděpodobnost a nápravné opatření.
Lessons Learned
Lessons Learned je záznam všech chyb a ponaučení z nich ze všech projektů v organizaci.
Tento dokument umožňuje zaznamenávat chyby v projektech na jednom místě řazených dle kategorií, tak aby se při vzniku nového projektu mohl projektový manažer na základě existujících záznamů poučit a mohl tak některým chybám předejít. Dokument pak existuje ve dvou variantách, kdy globální Lessons Learned je uložen na sdíleném uložišti společnosti dostupný pro všechny projektové manažery a zároveň dokument specifický pro každý projekt je uložen jako součást projektové dokumentace.
Strategie komunikace
Strategie komunikace udává, jak bude probíhat komunikace v rámci projektu. Jak budou zadávány projektové úkoly, jak často budou probíhat jednotlivé schůzky jako řídící komise které se účastní zadavatel i dodavatel, stavová schůzka projektu kde, již nemusejí být všichni řídící představitelé jako při schůzce řídící komise. Dokument zároveň upřesňuje zápisy ze schůzek, otevřené body v projektu a status report zprávy.
Status report
Status report je dokument uvádějící aktuální stav projektu a rozpracovanost jednotlivých úkolů. Tento report má za úkol informovat všechny členy projektu o aktuálním stavu a případných potížích, které mohli nastat. Status report je pak upravován v rámci komunikační strategie, kde je upraveno, jak často má být připraven a komu je zejména určen.
Akceptační protokol
Akceptační protokol slouží k potvrzení/akceptování provedené práce. Akceptace probíhá na konci každé fáze a následně konci projektu, kdy se jedná o akceptaci projektu jako celek.
Zpráva o otevřeném bodu
Zpráva o otevřeném bodu má za úkol informovat zadavatele projektu o otevřeném bodu v rámci projektu, který je nutné dále řešit.
Zpráva o ukončení projektu
Jedná se o zprávu vytvořenou na konci projektu, měl by obsahovat kompletní detailní popis realizace projektu, uvedení veškerých realizačních fází projektu, popis otevřených bodů během realizace a celkové zhodnocení z pohledu naplnění akceptačních kritériích a splnění
cílů projektu. Zároveň by měl být zhodnocen obchodní případ a přezkoumání cílů projektu, zda projekt skutečně splnil cíle projektu.
Využití dokumentů v procesech řízení projektů
Přítomnost jednotlivých dokumentů v procesech je vyjádřena v Tabulka 2 – Využití dokumentů dle metodiky Proces Projektu .
Role/Procesy Zahájení projektu Příprava projektu Plánování projektu Řízení projektu Realizace projektu Ukončení projektu Interní zhodnocení
Charta projektu O I/O I/O I/O I/O I/O I/O
Registr rizik O I I I
Lessons Learned I I/O
Strategie komunikace O I
Status report O I
Akceptační protokol I/O
Zpráva o otevřeném bodu O I
Zpráva o ukončení projektu I/O
Tabulka 2 – Využití dokumentů dle metodiky Proces Projektu
Tabulka pak pomocí indikace I/O znázorňuje, jak jaké dokumenty do jednotlivých procesů vstupují a vystupují:
• I – Input = Dokument do procesu vstupuje
• O – Output = Dokument vystupuje z procesu, byl zde upraven nebo vytvořen
• I/O – Input/Output = dokument vstupuje a vystupuje z jednoho procesu
Z tabulky je pak možné rozpoznat základní problémy při práci s dokumenty, kdy dokument Registr rizik není využíván během řízení projektů, to je pak závažný problém, jelikož se jedná o tzv. živý dokument používaný během celého životního cyklu projektu.
3.2.3 Role v projektu
Aktuálně jsou ve společnosti na základě projektových dokumentů rozeznávány následující role.
Klient
Také označována jako sponzor je role zaměstnance ze strany zadavatele projektu, který projekt schvaluje a uvnitř organizace vytváří podmínky pro jeho uskutečnění.
Projektový manažer
Role osazená ze strany dodavatele, kdy projektový manažer na základě uzavřené smlouvy dle dojednaného rozsahu, harmonogramu a financí řídí práce tak aby bylo dosaženo smluveného výsledku.
Account manager
Role osazená ze strany dodavatele, kdy account manažer má na starosti obchodní stránku projektu, dojednává s klientem podmínky smlouvy, výslednou cenu a zároveň ověřuje, zda se projekt vyplatí realizovat po finanční stránce a na základě toho projekt schvaluje.
Projektový team
Zaměstnanci ze stran dodavatele, zadavatele a dalších subdodavatelů, pokud je v projektu využito, kteří se podílejí na projektu jak z pozice realizace dílčích částí, tak z pozice jejich ověřování a schvalování.
Iniciátor
Osoba, která dává podnět pro zpracování projektu. Touto osobou může být technik společnosti, může jím být account manager, nebo kontaktní osoba zadavatele, která vyjádří potřebu za společnost zadavatele.
Využití rolí v procesech řízení projektů
Přítomnost jednotlivých rolí je pak vyjádřena v Tabulka 3 – Využití rolí dle metodiky Proces Projektu.
Role/Procesy Zahájení projektu Příprava projektu Plánování projektu Řízení projektu Realizace projektu Ukončení projektu Interní zhodnocení
Klient R C C R
Projektový manažer R A A A A A A
Account manager A R I R
Projektový team R R R
Iniciátor R
Tabulka 3 – Využití rolí dle metodiky Proces Projektu
Tabulka ukazuje přítomnost jednotlivých rolí za pomoci RACI matice, kdy jednotlivá písmena představují následující:
• R – Responsible = osoba která na úkolu pracuje
• A – Accountable = osoba odpovědná za úkol jako celek
• C – Consulted = osoba, která může podpořit úkol konzultací
• I – Consulted = osoba informovaná o výsledku a průběhu RACI matice má za úkol detailněji přiblížit funkci dané role v procesu.
3.2.4 Nástroje používané pro řízení projektu
V současném stavu ve společnosti neexistuje žádný nástroj určený pro řízení projektů.
Projektový manažeři využívají pro řízení projektů kancelářský balíček MS Office a jeho aplikace Word, Excel a Outlook.
4 Zhodnocení zralosti procesů
Na základě zmapování současného stavu a je potřeba změřit zralost jednotlivých procesů popsaných v oddílu Procesy řízení projektů. Pro určení stupně zralosti jednotlivých procesů v oblasti projektového řízení byla vybrána metoda CMMI-DEv, která je popsána v oddílu Určení stupně zralosti procesů, kdy na základě rozhovorů s projektovými manažery pracujícími ve společnosti byl identifikován stupeň zralosti každého procesu.
4.1 Zahájení projektu
Proces zahájení projektu byl, na základě rozhovorů s projektovými manažery společnosti, stanoven na úroveň 1 dle metody CMMI-DEV. Takto určen je z důvodu, že proces není vykonáván jednotně, charta projektu je zpracovávána až po obchodní nabídce a projektový manažer je k projektů přiřazen až po dojednání obchodních podmínek a podepsání smlouvy. Zároveň není vždy dodržována konzultace s technickým oddělením pro ověření technických parametrů dodávaného řešení. Proces tedy není vykonáván dle jeho popisu, ale je vykonáván chaoticky a správné provedení spočívá na konkrétních schopnostech zaměstnance, a ne na osvědčených postupech.
4.2 Příprava projektu
Proces přípravy projektu, byl na základě rozhovorů s projektovými manažery společnosti, stanoven na úroveň 1 dle metody CMMI-DEV. Takto určen je z důvodu návaznosti na předchozí proces, kdy obchodní stránka projektu je uzavřena není možné dále upravovat parametry řešení. Proces zároveň popisuje alokaci lidských zdrojů na projekt, nicméně dále již nespecifikuje, jakým způsobem by k tomu mělo dojít. Nechává tak další prostor pro chaotické a nahodilé vykonávání, které záleží na konkrétním zaměstnanci, a ne na osvědčených postupech. Proces pak není monitorován pro dosažení na další úroveň.
4.3 Plánování projektu
Proces plánování projektu, byl na základě rozhovorů s projektovými manažery společnosti, stanoven na úroveň 1 dle metody CMMI-DEV. Takto určen je z důvodu, že proces není vykonáván v plném rozsahu, tak jak byl popsán v metodice. Proces řeší vytvoření harmonogramu projektu, ale již dále neudává, jak má být vytvořen. Řízení rizik, které metodiky popisuje pak není vykonáváno. Proces je tak vykonáván náhodně a chaoticky.
Monitorování tohoto procesu neexistuje, neexistuje tak ověření, že je proces skutečně vykonáván.
4.4 Řízení projektu
Proces plánování projektu byl, na základě rozhovorů s projektovými manažery společnosti, stanoven na úroveň 1 dle metody CMMI-DEV. Takto určen je, protože samotný proces je popsán moc obecně. Nevyplívá z něho tedy přesné zadání, co a kým by mělo být prováděno.
Reálně prováděný proces pak záleží na interpretaci projektového manažera a na jeho schopnostech, ne na osvědčených postupech. Proces zároveň není monitorován pro zajištění kvality.
4.5 Realizace projektu
Proces plánování projektu, byl na základě rozhovorů s projektovými manažery společnosti, stanoven na úroveň 1 dle metody CMMI-DEV. Tato úroveň je určena, protože proces realizace projektu není jednotně dodržován. Každý výstup v podobě status reportů, nebo zápisů ze schůzek se řídí dle daného projektového manažera, není centrálně určena podoba těchto dokumentů a pravidla pro nakládání s nimi.
4.6 Ukončení projektu
Proces plánování projektu byl, na základě rozhovorů s projektovými manažery společnosti, stanoven na úroveň 1 dle metody CMMI-DEV. Tato úroveň je určena, protože proces není v plné míře vykonáván. Na závěr projektu je vždy zpracován dokument akceptační protokol, ale ne v plné míře tak, jak je v procesu popsáno. Konec projektu zároveň není formou prezentace, ale jedná se pouze o podepsání dokumentu a zaslání jeho naskenované verze.
Tento proces pak není prováděn dle popisu a jeho provedení závisí na projektovém manažerovi, ne na odsvědčených postupech.
4.7 Interní zhodnocení
Proces plánování projektu byl, na základě rozhovorů s projektovými manažery společnosti, stanoven na není vykonáván. Proces tak není ani v částečném rozsahu ve společnosti vykonáván.
4.8 Shrnutí kapitoly
Na základě měření byl zjištěn výsledek pro všechny procesy, a to shodně na úrovni jedna, vyjma procesu Interní zhodnocení, který není vykonáván. Zralost procesů na úrovni jedna znamená, že procesy jsou náhodné, chaotické a výkon organizace závisí na schopnostech jedinců. Tento výsledek slouží managementu společnosti pro rozhodnutí o dalším postupu.
