Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Vstup do projektového řízení v oblasti informačních technologií
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Informační management
Autor: Bc. Kateřina Kněnická
Vedoucí diplomové práce: Ing. Václav Oškrdal, Ph.D.
Praha, leden 2022
Poděkování
Ráda bych na tomto místě poděkovala Ing. Václavu Oškrdalovi, Ph.D. za vedení mé diplomové práce a za podnětné návrhy, které ji obohatily.
Děkuji též mým nejbližším za dlouholetou podporu během studií.
Abstrakt
Cílem diplomové práce je posoudit, do jaké míry jsou rozhodující projektové a technologické znalosti, metodiky (certifikace), behaviorální kompetence, vzdělání, zkušenosti či jiné charakteristiky při vstupu do projektového řízení v oblasti informačních technologií ve vývoji.
Teoretická část představuje základní informace o projektovém řízení, zaměřené na počátky a procesy projektového řízení, životní cyklus projektu nebo projektový trojimperativ. Dále se věnuje typologii projektů, modelům řízení projektu a roli PM v agilním i tradičním prostředí. V závěru se zabývá možnostmi projektových nástrojů a metodik (certifikací).
Praktická část obsahuje dva pohledy. První pohled je analyzován z pozice několika respondentů, kteří se v profesi IT projektového manažera ve vývoji již uplatnili. Druhý se soustředí na zaměstnavatele a jejich preference na tuto pozici. Pro analýzu bylo vybráno několik pracovních portálů, které nabízejí pozice v tomto oboru. Z těchto portálů byly poté vybrány vhodné pracovní nabídky, které byly následně kategorizovány podle vybraných aspektů. Na základě kvalitativních rozhovorů byla poté hledána spojitost mezi tím, co udávají zaměstnavatelé v požadavcích a tím, co respondentům při vstupu do projektového řízení opravdu pomohlo.
Klíčová slova
informační technologie, projektový manažer, projektové řízení, vývoj.
Abstract
The aim of the thesis is to assess how the project and technology knowledge, methodologies (certifications), behavioural competencies, education, experience, or other characteristics are decisive when entering project management in the field of information technology in development.
The theoretical part presents basic information on project management, focusing on the origins and processes of project management, the project life cycle or iron triangle. It also discusses project typologies, project management models and the role of PM in agile and traditional environments. It concludes with a look at the possibilities of project tools and methodologies (certifications).
The practical part contains two perspectives. The first perspective is analysed from the position of several respondents who have already worked in the IT project management in development. The second focuses on employers and their preferences for this position.
Several job portals that offer positions in this field were selected for analysis. From these portals, suitable job openings were then selected and then categorized according to the selected aspects. Based on qualitative interviews, a link was then sought between what the employers indicated in their requirements and what helped the respondents in entering project management.
Keywords
information technology, project manager, project management, development.
Obsah
Úvod...12
Cíle práce...12
Struktura práce ...13
Metody práce ...13
Přínosy práce ... 14
1 Projektové znalosti ... 15
1.1 Počátky projektového řízení ... 15
1.2 Životní cyklus projektu ... 17
1.3 Projektový trojimperativ ... 19
1.4 Procesy projektového řízení ... 20
1.4.1 Iniciační proces... 20
1.4.2 Proces plánování... 24
1.4.3 Realizační proces ... 25
1.4.4 Procesy monitorování a kontroly ... 25
1.4.5 Proces uzavření ... 26
1.5 Typologie projektů ... 26
1.5.1 Softwarový vývoj ... 27
1.5.2 Infrastrukturní projekty ... 27
1.5.3 Migrace systémů ... 28
1.5.4 Rozvoj systémů ... 28
1.5.5 Implementace balíkových řešení ... 28
1.6 Modely řízení projektu a role PM ... 29
1.6.1 Sekvenční přístup – vodopádový (tradiční) vývoj ... 30
1.6.2 Role projektového manažera ve vodopádovém modelu ...31
1.6.3 Iterativní přístup – agilní vývoj ...31
1.6.4 Role projektového manažera v agilním modelu ... 32
1.6.5 Agilní vs. tradiční ... 32
1.7 Shrnutí ... 35
2 Projektové nástroje ... 37
2.1 Atlassian ... 37
2.1.1 Jira ... 37
2.1.2 Confluence ... 38
2.1.3 Trello ... 39
2.2 Microsoft Office 365 ... 39
2.2.1 Outlook ... 40
2.2.2 Word ... 40
2.2.3 PowerPoint ... 40
2.2.4 Excel ... 40
2.2.5 OneDrive ... 40
2.2.6 Teams... 40
2.3 MS Project ... 41
2.4 Shrnutí ... 41
3 Metodiky (certifikace) ... 42
3.1 IPMA ... 42
3.1.1 Individuální kompetence ... 42
3.1.2 Projektová excelence ... 45
3.1.3 Organizační kompetence ... 46
3.1.4 Výhody certifikátu IPMA ... 46
3.2 PRINCE2 ... 47
3.3 PMI ... 49
3.3.1 Soubor znalostí projektového řízení – průvodce PMBOK ... 50
3.4 Shrnutí ... 51
4 Praktická část ... 52
4.1 Projektové znalosti ... 53
4.1.1 V1: Vyžadují zaměstnavatelé od začínajících PM alespoň základní projektové znalosti?... 53
4.1.2 V2: Je rozdíl mezi kompetencemi agilních a vodopádových PM? ... 54
4.2 Technologické znalosti ... 56
4.2.1 V3: Vyžadují zaměstnavatelé od začínajících PM alespoň základní technologické znalosti? ... 56
4.2.2 V4: Vyžadují zaměstnavatelé od začínajících PM znalosti projektových nástrojů? ... 58
4.2.3 V5: Je potřeba, aby projektový manažer uměl programovat?... 59
4.3 Metodiky (certifikace) ... 59
4.3.1 V6: Je potřeba, aby uchazeč o pozici PM znal nějakou metodiku? ... 59
4.3.2 V7: Je certifikace pro začínající PM důležitá? ... 60
4.4 Behaviorální kompetence ... 61
4.4.1 V8: Jaké behaviorální kompetence jsou dle zaměstnavatelů potřebné? Mají
pro ně projektoví manažeři silné předpoklady? ... 62
4.5 Vzdělání ... 63
4.5.1 V9: Je vysokoškolské vzdělání v tomto oboru potřebné? ... 63
4.6 Zkušenosti... 65
4.6.1 V10: Je potřeba, aby začínající PM měli předešlé zkušenosti v IT/PM? ... 65
4.6.2 V11: Měl by mít začínající projektový manažer zkušenosti s agilním prostředím? ... 66
4.6.3 V12: Měl by mít začínající projektový manažer předešlou zkušenost s vývojem? ... 67
4.7 Jiné charakteristiky ... 68
4.8 V13: Jaké jsou další aspekty pro přijetí na pozici IT projektový manažer ve vývoji? 68 4.9 Shrnutí ... 69
Závěr ... 71
Použitá literatura ... 72 Přílohy ... I Příloha A: Rozhovory s PM ... I Martin W. ... I Martin M. ... III Lucie F. ... VI Ondřej M. ... IX Michal P. ... XI Příloha B: Nabídky na juniorní IT PM pozice ve vývoji ... XIV Project support... XIV Junior Projektový manažer ... XV Project Manager (Junior) ... XVI Učenlivý junior projekťák pro šťavnaté aplikace ... XVIII Junior IT projektový manažer ... XIX Junior sales / projektový specialista (IT SW řešení) ... XXI
Seznam obrázků
Obrázek 1 Životní cyklus projektu (Plánování projektu před a po startu – Projektový
Underground nedatováno) ... 18
Obrázek 2 Riziko budoucích změn (Životní cyklus projektu a fáze projektu Martin Cupal Podnikatelský záměr a projektový management. - ppt stáhnout nedatováno) ... 18
Obrázek 3 Projektový trojimperativ (bARTvisions.cz nedatováno) ... 19
Obrázek 4 Procesy projektového řízení (Amirov 2015)... 20
Obrázek 5 Matice zainteresovaných stran (stakeholderů) (Doležal et al. 2012) ... 23
Obrázek 6 Tradiční model (Vodopádový model 2021) ... 30
Obrázek 7 Jira – stránka s problémem (What is the new Jira issue view? | Jira Work Management Cloud 2021)... 38
Obrázek 8 Oko individuálních kompetencí (Máchal et al. 2017) ... 43
Obrázek 9 Klíčové oblasti PEB (IPMA nedatováno) ... 45
Obrázek 10 Vnější kontext organizace (IPMA nedatováno-upraveno autorkou) ... 46
Obrázek 11 PRINCE2 7 principů (PRINCE2 ® - představení metodiky Benešov 2.června 2010 PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and. - ppt stáhnout nedatováno)... 48
Obrázek 12 PRINCE2 témata (PRINCE2 ® - představení metodiky Benešov 2.června 2010 PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and. - ppt stáhnout nedatováno)... 49
Seznam tabulek
Tabulka 1 Přehled projektu (Wysocki K. Robert 2009) ... 22
Tabulka 2 Rozdíly mezi tradičním a agilním modelem (Stoica, Mircea, Ghilic-Micu 2013) ... 34
Tabulka 3 Pohled PM projektové znalosti ... 53
Tabulka 4 Pohled zaměstnavatele projektové znalosti ... 54
Tabulka 5 Pohled PM agile vs. vodopád ... 55
Tabulka 6 Pohled zaměstnavatele agile vs. vodopád ... 56
Tabulka 7 Pohled PM technologické znalosti ... 57
Tabulka 8 Pohled zaměstnavatele technologické znalosti ... 57
Tabulka 9 Pohled PM projektové nástroje ... 58
Tabulka 10 Pohled zaměstnavatele projektové nástroje ... 58
Tabulka 11 Pohled PM programování... 59
Tabulka 12 Pohled zaměstnavatele programování ... 59
Tabulka 13 Pohled PM metodiky ... 60
Tabulka 14 Pohled zaměstnavatele metodiky... 60
Tabulka 15 Pohled PM certifikace ... 61
Tabulka 16 Pohled zaměstnavatele certifikace ... 61
Tabulka 17 Pohled PM behaviorální kompetence ... 62
Tabulka 18 Pohled zaměstnavatele behaviorální kompetence ... 63
Tabulka 19 Pohled PM vzdělání... 64
Tabulka 20 Pohled zaměstnavatele vzdělání ... 64
Tabulka 21 Pohled PM zkušenosti v IT/PM ... 65
Tabulka 22 Pohled zaměstnavatele zkušenosti v PM ... 66
Tabulka 23 Pohled zaměstnavatele zkušenosti v IT ... 66
Tabulka 24 Pohled PM seniorita ... 66
Tabulka 25 Pohled PM agile zkušenosti ... 67
Tabulka 26 Pohled zaměstnavatele agile zkušenosti ... 67
Tabulka 27 Pohled PM zkušenost s vývojem ... 67
Tabulka 28 Pohled zaměstnavatele zkušenost s vývojem ... 68
Tabulka 29 Pohled PM jiné charakteristiky ... 68
Tabulka 30 Pohled zaměstnavatele jiné charakteristiky ... 69
Seznam zkratek
IT – Informační Technologie
PM – Projektový Manažer/Projektový Management PMI – Project Management Institute
PERT – Program Evaluation and Review Technique CPM – Critical Path method
SW – Software
IPMA – International Project Management Association PRINCE2 – PRoject IN Control Enviroment 2
SMART – Specific, Mesurable, Accepted, Realistic, Timed SDLC – Software Development Life Cycle
ASD – Adaptive Software Development MS – Microsoft
ICB – IPMA Competence Baseline PEB – Project Excellence Baseline
OCB – Organisational Competence Baseline WBS – Work Breakdown Structure
PMBOK – Project Management Body of Knowledge ITIL – Information Technology Infrastructure Library HTML – Hypertext Markup Language
IoT – Internet of Things
Úvod
Přestože jsou projektoví manažeři (PM) v oblasti informačních technologií (IT) ve vývoji velmi žádaní, je někdy obtížné uspět u vstupního pohovoru na tuto pozici. Zaměstnavatelé mají vysoké nároky a od PM očekávají víc než jen manažerské schopnosti. To lze vyvodit už jenom z nabídek, které různé společnosti inzerují. Firmy často hledají člověka, který bude zapadat do jejich týmu, bude splňovat kombinaci adekvátního vzdělání, technologických znalostí a zkušeností. Například, jak má člověk uspět, pokud má o tento obor zájem, ale předešlé zkušenosti mu třeba chybí? Je to opravdu tím nejdůležitějším faktorem? Co rozhoduje o tom, že někteří kandidáti uspějí a jiní ne?
Sama autorka má zkušenost s hledáním práce v tomto oboru a ví, že dostat se na takovou pozici není jednoduché. To bylo také hlavním důvodem, proč si vybrala téma vstup do projektového řízení v oblasti informačních technologií. Zajímalo ji, jak se projektoví manažeři stávají projektovými manažery a co tomu předchází.
Cíle práce
Hlavním cílem diplomové práce je posoudit, do jaké míry jsou rozhodující projektové a technologické znalosti, metodiky (certifikace), behaviorální kompetence, vzdělání, zkušenosti či jiné charakteristiky při vstupu do IT projektového řízení ve vývoji.
Cíl je rozdělen do několika dílčích částí, a to jak z pohledu teoretického, tak i praktického.
Cílem teoretické časti je:
1. Představit základní projektové znalosti, které mohou kandidátům při vstupu do IT projektového řízení ve vývoji pomoci.
2. Ukázat začínajícím projektovým manažerům, jaké existují nástroje nebo metodiky (certifikace) pro zvýšení jejich úspěšnosti při řízení projektů.
Cílem praktické části je:
1. Provést kvalitativní rozhovory s vybranými projektovými manažery a zjistit, jak se respondenti k této pracovní činnosti dostali.
2. Zanalyzovat požadavky vybraných zaměstnavatelů na juniorní pozice v IT projektovém řízení ve vývoji.
3. Najít spojitost mezi tím, co udávají zaměstnavatelé v požadavcích a tím, co respondentům při vstupu do projektového řízení opravdu pomohlo.
Struktura práce
Práce je rozdělena do dvou částí – teoretické a praktické. Teoretická část představuje čtenáři základní projektové znalosti. Mezi ně patří například počátky projektového řízení, životní cyklus projektu, projektový trojimperativ, procesy projektového řízení, typologie projektu nebo modely řízení projektu a role PM (rozdíly mezi agilním a tradičním PM/vývojem). Poté se věnuje nejpopulárnějším projektovým nástrojům, které podporují řízení projektu, a na závěr se zaměřuje na projektové metodiky a jejich certifikace.
V praktické části byly respondentům pokládány otázky týkající se 7 témat (projektové a technologické znalosti, metodiky/certifikace, behaviorální kompetence, vzdělání, zkušenosti či jiné charakteristiky). Nejprve se věnuje tomu, zda zaměstnavatelé od začínajících PM vyžadují alespoň základní projektové znalosti. Poté zjišťuje, jestli zaměstnavatelé a PM rozlišují kompetence agilních a vodopádových PM a jestli se požadavky zaměstnavatelů liší. Další část se zabývá tím, zda zaměstnavatelé vyžadují od začínajících PM alespoň technologické znalosti, zda musejí znát nějaké projektové nástroje nebo dokonce musí na takovéto pozici umět programovat. Následující oblast analyzuje znalost metodik a jejich potřebnost pro práci PM. S tím je spojena i případná certifikace.
V neposlední řadě práce porovnává i behaviorální kompetence podle mezinárodního projektového standardu IPMA ICB v.4. Dalším důležitým aspektem je vzdělání, kde autorka zjišťuje, do jaké míry je vysokoškolské vzdělání v tomto oboru důležité.
Předposlední analyzovanou oblastí jsou zkušenosti. Ty jsou rozděleny do čtyř úrovní – zkušenosti v IT, v projektovém řízení, v agilním prostředí a ve vývoji. V závěru práce autorka analyzuje, jaké jsou další charakteristiky, které rozhodují při vstupu do IT projektového řízení ve vývoji.
Metody práce
Oblast výzkumu je zúžena na Prahu, ačkoliv si je autorka vědoma, že projektoví manažeři alokovaní v Praze nemusí být vždy spjati s touto lokalitou. Důvodem jsou mezinárodní projekty a dnes již oblíbený „home-office“, které umožňují zaměstnancům pracovat téměř odkudkoliv. Autorka se dále zaměřuje na juniorní pozice, jelikož při vstupu do projektového řízení se neočekává příliš zkušeností. Věnuje se zejména pozicím určeným pro vývoj, neboť tato oblast ji nejvíce zajímá.
Pro zjištění pohledu projektových manažerů bylo provedeno několik strukturovaných rozhovorů. Respondenti museli splňovat dvě kritéria – být z Prahy a mít zkušenosti s pozicí IT projektového manažera ve vývoji. Během kvalitativního výzkumu byly projektovým manažerům pokládány otázky ohledně jejich začínající kariéry v tomto oboru. Autorku zajímalo, co všechno tomu předcházelo, jak se k dané práci dostali a co jim k ní pomohlo. Otázky pokládala tak, aby vycházely z analyzovaných témat.
Pro zjištění pohledu zaměstnavatelů autorka prošla několik pracovních portálů. Tam, kde to bylo možné, zúžila výběr pomocí filtrů: město – Praha, obor – projektový manažer v IT
a zkušenosti – juniorní. Dále vybrala vhodné nabídky tak, aby pozice, které se nevěnovaly vývoji, byly automaticky vyřazeny.
Metodou tematické analýzy poté autorka hledala spojitost mezi osobní zkušeností projektových manažerů a požadavky zaměstnavatelů.
Přínosy práce
Výsledky práce by měly pomoci zájemcům o tento obor, a to v několika ohledech:
1. Udělat si představu o tom, co IT projektové řízení ve vývoji obnáší.
2. Zjistit, jak nejlépe uspět u vstupního pohovoru na tuto pozici.
1 Projektové znalosti
Tato kapitola slouží jako souhrn základních znalostí, jež jsou pro projektové řízení důležité. V první podkapitole je vysvětlena definice projektu, na níž postupně navazuje historie a vznik projektového řízení. Poté práce pokračuje životním cyklem projektu, vysvětlením projektového trojimperativu, procesů projektového řízení (iniciace, plánování, realizace, monitorování/kontrola a ukončení), typologie projektu (softwarový vývoj, infrastrukturní projekty, migrace systémů, rozvoj systémů a implementace balíkových řešení) a přístupů vývojových projektů (tradiční vs. agilní vývoj).
Autorka se v praktické části věnuje pozicím zaměřeným na vývoj, a proto se i v teoretické části soustředí na rozdíly mezi projektovými manažery v agilním a tradičním vývojovém prostředí.
1.1 Počátky projektového řízení
Pokud souhlasíme s definicí, kterou nabízí Project Management Institute1 (PMI), že projekt je „dočasné úsilí o vytvoření jedinečného produktu, služby nebo výsledku“
(Project Management Institute 2021) a projektové řízení je „aplikace znalostí, dovedností, nástrojů a technik na projektové činnosti s cílem splnit požadavky projektu (Project Management Institute 2021), pak lidé začali pracovat na projektech již v dávné historii.
V průběhu let geniální architekti a inženýři realizovali působivé projekty, jako jsou například Velká pyramida v Gíze, Velká čínská zeď, Koloseum, visuté zahrady v Babylonu, Stonehenge a další. Aby projekty uspěly, museli se tito architekti a inženýři změnit v projektové manažery, kteří pečlivě promýšleli všechny procesy projektu, počínaje fází zahájení a plánování, přes realizaci a monitorování, až po uzavření projektu.
Mark Kazak-Holland ve své knize The History of Project Management2 tvrdí, že projektové řízení není disciplínou 20. století a navzdory všeobecnému přesvědčení je historie plná mnoha projektů, které měly projektového sponzora, projektový tým a praktikované projektové procesy. Autor tvrdí, že bez dobrého pochopení všech těchto principů by takové projekty nikdy neuspěly. Kniha také vyvrací čtyři mylné představy o historických projektech: historické projekty měly neomezené rozpočty bez ekonomické návratnosti;
historické projekty měly převážně otrockou pracovní sílu; historické projekty měly neomezený časový harmonogram; historické projekty používaly koncepty, které nejsou spojovány s moderními projekty (Kozak-Holland M. 2011).
1 Project Management Institute = Institut projektového řízení
2 The History of Project Management = Historie projektového řízení
Při čtení knihy člověk pochopí, že současné projektové řízení je výsledkem přirozeného vývoje a bylo praktikováno po celou historii lidstva. Postupně, s dokončením každého úspěšného významného projektu, postupovaly znalosti, dovednosti, nástroje a techniky, které připravovaly půdu pro další projekty.
Navzdory úspěchům všech velkých historických projektů, kterých bylo kdysi dosaženo, jsou záznamy o těchto projektech vzácné. To lze přičíst kombinaci několika faktorů.
Zaprvé, vzdělanou vyšší společnost zajímal spíše konečný výsledek projektu než metodika tvorby. Existenci záznamů nepomohlo ani to, že za realizaci takových projektů byli zpravidla zodpovědní řemeslníci, kteří nemuseli být nutně vzdělaní nebo mít zájem na tom, aby se o jejich metodách dozvěděli ostatní. Naopak, u mnoha těchto projektů byly detaily provedení drženy v tajnosti mezi určitým kmenem nebo rodinou, která se specializovala na řemeslnou výrobu a předávala si je z generace na generaci (Sreejith 2008). Jiní autoři zas tvrdí, že profese, jako je architektura, medicína, ekonomie, matematika a teoretické vědy, jsou zdokumentovány lépe než projektové řízení, „protože termín projekt se ve starověkých textech nevyskytuje, tento obor byl méně uchopitelný než jiné profese“ (Chiu Y. C. 2011).
Zdá se, že neexistuje shoda na tom, kdy přesně moderní projektové řízení začalo. Různí autoři nabízejí různé názory. V knize An introduction to the History of Project Management3 Chiu prohlašuje, že praotci projektového řízení jsou Henri Fayol a Henry Gantt (Chiu Y. C. 2010).
Henri Fayol (1841-1925) byl francouzský inženýr v železářské a ocelářské společnosti. Tato společnost byla největší ve Francii a měla zásadní význam pro ozbrojení francouzské armády těsně před první světovou válkou. Fayol úspěšně vedl společnost po mnoho let, během nichž se stále více zajímal o problematiku managementu (Witzel M. 2003). Na základě pozorování Fayol identifikoval pět funkcí řízení, které považoval za univerzální.
Fayol se domníval, že tyto funkce vykonává v různé míře každý manažer při své každodenní práci. Fayolových pět funkcí řízení jsou: plánování, organizování, velení, koordinace a kontrola. Fayol také formuloval 14 zásad, které manažerům poskytují návod, jak těchto pět manažerských funkcí efektivně vykonávat. Fayolovo dílo bylo mnohými kritizováno kvůli tomu, že jeho teorie nevystihuje skutečnou složitost manažerské práce, s níž se manažeři každodenně setkávají. Přesto Fayolova práce významně přispěla k rozvoji managementu. V článku Fayol Stands the Test of Time4 se například tvrdí, že Fayolovy prvky managementu nejsou vyvráceny, ale spíše posíleny novějšími poznatky. Článek dochází k závěru, že Fayolovo dílo obstálo ve zkoušce času (Fells M. J. 2000). Navzdory nedostatkům pět funkcí stále poskytuje strukturovaný přehled úkolů, které jsou pro management důležité, a poskytuje prvotní přehled hlavních funkcí, s nimiž se manažeři denně setkávají.
3 An Introduction to the History of Project Management = Úvod do historie projektového řízení
4 Fayol Stands the Test of Time = Fayol obstál ve zkoušce času
Druhým praotcem moderního projektového řízení je podle Y. C. Chiu Henry Gantt. Henry Gantt (1861-1919) byl americký inženýr a později konzultant v oblasti řízení. Je známý především jako autor Ganttova diagramu. Ganttovy diagramy jsou v historii moderního projektového řízení významné, protože rozdělují velké projekty na menší zvládnutelné úkoly. Počítají také s tím, že některé úkoly mohou být na sobě závislé. Ganttovy diagramy se používají dodnes a jsou považovány za důležitý nástroj ve výbavě projektového manažera.
Podle Snydera a Klinea (1987) začala éra moderního projektového řízení teprve v roce 1958 vývojem Critical Path Method5 (CPM)/Program Evaluation Review Technique6 (PERT) (Kwak Y. H. 2003). CPM/PERT byl právem přikládán význam při rozvoji a pravděpodobně i při zahájení moderního projektového řízení. Ačkoli se CPM/PERT do jisté míry překrývají, byly vyvinuty ve dvou paralelních liniích ve velmi odlišných oblastech: v námořnictvu a v chemickém průmyslu. V roce 1958 vedlo americké námořnictvo projekt Polaris, což byly první balistické rakety odpalované z ponorek nesoucí jaderné hlavice. Díky projektu Polaris se americké námořnictvo zasloužilo o rozvoj jedné z dnes nejpoužívanějších technik, kterou je technika PERT. Vzhledem k vysoké složitosti a nejistotě spojené s plánováním projektu se PERT dobře hodil k vizualizaci různých scénářů plánování projektu. CPM byla vynalezena téměř současně s metodou PERT. Její vznik byl důsledkem toho, že společnost E. I. du Pont de Nemours and Company realizovala velký stavební projekt. Projekt zahrnoval výstavbu velkého chemického závodu. CPM vznikla v důsledku toho, že společnost potřebovala přesně odhadnout náklady a čas projektu. Původně se metoda, kterou vyvinuli, označovala jako plánování a rozvrhování projektů, ale později se tato technika vyvinula v dnes již známou metodu CPM.
1.2 Životní cyklus projektu
Stejně jako každodenní činnost, kterou jako lidé děláme a která musí projít určitými procesy, abychom v určité fázi dospěli k závěrečnému bodu, i projekty procházejí určitým procesem, aby bylo možné dodat produkt, službu nebo výsledek, pro který se projekt realizuje. Životní cyklus projektu je řada fází nebo činností, kterými projekt prochází od začátku do konce a které na sebe obvykle navazují. PMI ve svém pátém vydání tyto fáze životního cyklu identifikoval a popsal. Je to: zahájení projektu, plánování, realizace a uzavření projektu jako celku (PMI 2013). Tyto fáze tvoří životnost projektu bez ohledu na jeho velikost, povahu nebo umístění.
5 Critical Path Method = Metoda kritické cesty
6 Program Evaluation Review Technique6 = Technika hodnocení programu
Obrázek 1 Životní cyklus projektu (Plánování projektu před a po startu – Projektový Underground nedatováno)
Jednotlivé etapy jsou ve většině případů spojeny s náklady na projekt a personálním obsazením. Obecně platí, že na začátku projektu jsou náklady a počet zaměstnanců nízké, v průběhu realizace prací dosahují vrcholu a s koncem projektu klesají. To znamená, že ve fázi zahájení a plánování je riziko projektu relativně nízké a zvyšuje se ve fázi realizace nebo provádění. Proto čím dříve jsou změny identifikovány a opraveny, tím nižší jsou náklady na projekt. Proto je důležité, aby ve fázi zahájení a plánování byly zváženy názory, požadavky a žádosti všech zainteresovaných stran, aby se minimalizovalo riziko budoucích změn.
Obrázek 2 Riziko budoucích změn (Životní cyklus projektu a fáze projektu Martin Cupal Podnikatelský záměr a projektový management. - ppt stáhnout nedatováno)
Riziko projektu se v průběhu jeho trvání snižuje s tím, jak jsou přijímána rozhodnutí a jak jsou výstupy akceptovány zainteresovanými stranami (PMI 2013). Je však důležité si uvědomit, že některé projekty jsou v počátečních fázích mnohem nákladnější, protože je třeba vynaložit více prostředků a času pro plánování než k samotné realizaci.
1.3 Projektový trojimperativ
Wysocki identifikoval pět parametrů, které ovlivňují každý projekt: rozsah, výsledky, náklady, čas a zdroje. Úspěch projektu do značné míry závisí na tom, jak jsou tyto parametry řízeny, jelikož jsou na sobě závislé a změna jednoho parametru může ovlivnit parametr jiný. (Wysocki K. Robert 2009).
Na obrázku 3 níže je znázorněn projektový trojimperativ.
Obrázek 3 Projektový trojimperativ (bARTvisions.cz nedatováno)
Všech těchto pět parametrů by mělo být udržováno v rovnováze. Například budoucí požadavky zainteresované strany nebo odstoupení klíčového člena týmu bez okamžité náhrady povede k nerovnováze trojimperativu, což automaticky ovlivní konečný produkt nebo výsledek projektu.
1.4 Procesy projektového řízení
Každý správně nastavený projekt má své fáze (zahájení, plánování, realizaci, monitorování/kontrolu a uzavření) a v každé fázi by se měly dodržovat určité procesy.
Projektový manažer musí dokázat rozeznat, v jaké fázi se projekt nachází, a posléze by měl i vědět, jak jednotlivé procesy aplikovat.
Obrázek 4 Procesy projektového řízení (Amirov 2015)
Na obrázku 4 můžete vidět obecný životní cyklus každého projektu bez ohledu na jeho velikost nebo složitost. Iniciační proces definuje nový projekt nebo nové fáze stávajícího projektu.
Proces plánování představuje stanovení rozsahu projektu, definování cílů a také určení požadovaných činností, které jsou třeba provést k dosažení cílů projektu.
Realizační proces představuje činnosti, které jsou prováděny za účelem dokončení prací definovaných ve fázi plánování.
Procesy monitorování a kontrola jsou procesy potřebné ke „sledování, přezkoumávání a regulaci postupu a výkonnosti projektu; identifikaci oblastí, v nichž jsou nutné změny plánu, a k zahájení odpovídajících změn“ (PMI 2013).
Uzavírající proces představuje činnosti, které je třeba provést, aby byl projekt definitivně uzavřen.
1.4.1 Iniciační proces
Zahájení projektu je první fází každého projektu poté, co si jednotlivec nebo organizace uvědomí potřebu realizovat projekt za určitým účelem. Tato skupina procesů zahrnuje všechny procesy související s odpovědí na otázku „co potřebujete udělat?“. (Wysocki K.
Robert 2009). Skládá se z takových procesů, jako je počáteční definice rozsahu,
identifikace zainteresovaných stran (interních i externích) a také výběr projektového manažera. Všechny tyto informace jsou zachyceny v „project chartu“7 a v registru zainteresovaných stran (PMI 2013).
Podle Wysockého se zahájení projektu skládá z náboru projektového manažera, zjištění skutečných potřeb klienta, zdokumentování potřeb klienta, jednání s klientem o tom, jak budou tyto potřeby naplněny, sepsání prohlášení o přehledu projektu (jednostránkový popis projektu) a získání souhlasu vrcholového vedení s plánováním projektu (Wysocki K.
Robert 2009).
Posláním každého projektu je dosáhnout vize, která odpovídá potřebám zadavatele. Tyto potřeby musí být definovány, ačkoliv sponzor projektu nemusí hned od začátku vidět danou vizi. Proto je důležité, aby do definice rozsahu projektu bylo od samého počátku zahrnuto co nejvíce zainteresovaných stran, aby bylo možné co nejvíce zachytit jejich požadavky, i když se mohou v průběhu projektu měnit. To pomáhá minimalizovat riziko, že někteří „stakeholdeři“8 vznesou později v průběhu projektu obavy nebo nové požadavky, které by mohly mít negativní dopad na celý projekt.
V této fázi je také důležité vyhodnotit alternativy pro určení proveditelnosti projektu formou jasného popisu cílů projektu, včetně důvodů, proč je konkrétní projekt nejlepší alternativou pro uspokojení požadavků zadavatele. Dokumentace pro toto rozhodnutí může také obsahovat úvodní prohlášení o rozsahu projektu, výstupy, dobu trvání projektu a prognózu zdrojů pro analýzu investic organizace (PMI 2013).
Přehled projektu
Přehled projektu je výstup ze strukturovaného rozhovoru mezi zadavatelem projektu a projektovým manažerem, jehož cílem je jasně definovat, o co v projektu jde. „Přehled projektu je krátký dokument (ideálně jednostránkový), který stručně uvádí, co se má v rámci projektu udělat, proč se to má udělat a jakou obchodní hodnotu to podniku přinese po dokončení“ (Wysocki, 2009, s. 91). K tomu, aby bylo možné postoupit do další fáze projektu (plánování) je potřeba, aby byl tento dokument odsouhlasen potřebnými zástupci managementu. Jasně uvádí problém nebo příležitost, cíle projektu, kritéria úspěšnosti, předpoklady, rizika a překážky projektu.
7 Project chart = schéma projektu
8 Stakeholder = jinými slovy zainteresovaná strana
Tabulka 1 Přehled projektu (Wysocki K. Robert 2009)
Přehled projektu Název projektu: Sponzor projektu: Projektový manažer:
Problém/Příležitost:
Cíl:
Úkoly:
Kritéria úspěchu:
Předpoklady, rizika, překážky:
Připraveno: Datum: Schváleno: Datum:
Přehled projektu usnadňuje práci, protože management si jej může rychle přečíst a rozhodnout se, zda má smysl navrhovaný projekt dále zvažovat. Pokud přehled projektu dává managementu smysl, dají projektovému manažerovi zelenou, aby pokračoval ve fázi plánování projektu. V opačném případě jej mohou rychle zamítnout, aby případně nepromarnili čas a peníze, které původně mohly být na projekt vyhrazeny.
Zainteresované strany projektu (stakeholdeři)
Zainteresovaná strana projektu „je každá strana, která má zájem na procesu nebo výsledku projektu“ (Maylor Harvey 2010). Tedy ti jednotlivci, skupiny nebo organizace, které se aktivně zapojují nebo mají zájem na výsledku projektu. Řízení zainteresovaných stran je klíčové pro úspěch každého projektu v každé organizaci a zapojení správných lidí ve správný čas je velmi důležité pro jeho úspěch. „Většina projektů má více než jednu zainteresovanou stranu nebo skupinu zainteresovaných stran, což staví projektového manažera před velkou výzvu – vyřešit jejich často rozdílné a potenciálně protichůdné požadavky.“ (Maylor Harvey 2010). Úspěch projektu nejčastěji závisí na schopnosti projektového manažera, aby tyto protichůdné zájmy dokázal zvládnout.
Maylor identifikoval tři kategorie zainteresovaných stran projektu:
Interní tým – zahrnuje osoby a skupiny, které se přímo podílejí na projektu, jsou nejdůležitější a je třeba je řídit
Externí subjekty – stojí mimo projekt, ale jsou důležití pro jeho úspěch
Zbytek světa – osoby a skupiny, které nejsou přímo spojeny s projektem, ale vyžadují monitorování
Při provádění analýzy zainteresovaných stran v projektu existují tři kroky:
1) Prvním krokem je „brainstorming“9 mezi členy projektového týmu s cílem identifikovat, kdo jsou zainteresované strany projektu. Přitom se myslí na všechny lidi, kterých se projekt tak či onak dotýká a jejichž vliv nebo moc ovlivňuje konečný výsledek projektu.
2) Poté projektový manažer seřadí podle důležitosti identifikované stakeholdery a zakreslí je do matice zainteresovaných stran. Viz příklad níže.
Obrázek 5 Matice zainteresovaných stran (stakeholderů) (Doležal et al. 2012)
Lidé s vysokým vlivem a zájmem: jsou ti, které musí projektový manažer plně zapojit a vynaložit velké úsilí, aby je uspokojil.
Lidé s vysokým vlivem, méně zainteresovaní: pro ně musí projektový manažer udělat vše, aby byli spokojeni, ale ne natolik, aby je sdělení projektového manažera začalo obtěžovat.
Lidé s nízkým vlivem, kteří se zajímají: tyto lidi musí PM přiměřeně informovat a hovořit s nimi, aby se ujistil, že z jejich strany nevznikají žádné zásadní problémy.
Lidé s nízkým vlivem, méně zainteresovaní: opět je třeba tyto lidi sledovat, ale nesmí být obtěžováni nadměrnou komunikací.
3) Projektový manažer musí rozumět klíčovým stakeholderům, aby věděl, jak budou na projekt pravděpodobně reagovat. Musí také vědět, jak je nejlépe zapojit do projektu a jak s nimi nejlépe komunikovat, aby získal jejich podporu.
Shromažďování požadavků na projekt
Před fází plánování by měl každý projektový manažer zjistit požadavky na projekt, které jsou zásadní pro definici výstupů. Tyto požadavky slouží pro pochopení skutečných potřeb klienta projektu. Schopnost jasně identifikovat požadavek projektu naznačuje, že zadavatel a poskytovatel, v tomto případě projektový manažer, jasně chápe, jaký výsledek má projekt přinést. K identifikaci těchto požadavků je zapotřebí jak zadavatele, tak projektového manažera.
9 Brainstorming: skupinové přemýšlení nad daným tématem, přicházení s novými ideami
Toho lze dosáhnout pomocí určitých nástrojů. Jako je například prototypování, rozhovory, vedené schůzky, dotazníky a průzkumy, pozorování nebo „business case“10.
Cíl projektu
Účelem vypracování cíle projektu je definovat konečný produkt nebo výsledek tak, aby mu všichni (zainteresované strany) rozuměli. Jedním ze způsobů, jak toho dosáhnout, je použití strategie SMART. Zkratka SMART znamená: Specific11, Measurable12, Achievable13, Relevant14, and Time-Oriented15.
Specifický cíl: určuje, co se má udělat a jak poznáme, že je to hotovo. Výsledky práce mají být popsané tak, aby si je každý vyložil stejně.
Měřitelný cíl: říká, jak poznat, že splňujeme očekávání stakeholderů. Odkazuje na rozsah, v jakém lze něco hodnotit na základě určitých standardů (množství, kvalita, četnost, náklady, termíny atd.).
Dosažitelný cíl: odpovídá na otázky, zda osoba, která práci vykonává, tuto práci může vykonávat, zda má zkušenosti, znalosti nebo schopnosti splnit daná očekávání. Odpovídá také na otázku, zda to lze provést s ohledem na časový rámec a zdroje.
Relevantní cíl: definuje, proč by to mělo být provedeno a jaký to bude mít dopad. Je cíl v souladu se strategickými plány organizace?
Časová orientace: odpovídá na otázku, kdy bude cíl proveden. Odkazuje na skutečnost, že cíl má v sobě zabudovány koncové a kontrolní body. To dává projektovému manažerovi a jeho týmu pocit naléhavosti celého projektu (Wysocki K. Robert 2009).
Hledání odpovědí na tyto otázky pomáhá projektovému manažerovi zjistit, zda je projekt proveditelný a zda by měl být realizován, či nikoliv.
1.4.2 Proces plánování
Podle Wysockého zahrnuje skupina plánovacích procesů všechny procesy související s odpovědí na otázku „jak to uděláte?“ (Wysocki K. Robert 2009). Tyto procesy jsou následující: definování všech úkolů v projektu, odhad, jak dlouho bude trvat dokončení jednotlivých úkolů a celého projektu, odhad zdrojů potřebných k dokončení práce, odhad celkových nákladů na práci, stanovení pořadí úkolů, sestavení počátečního harmonogramu projektu, analýza a úprava harmonogramu projektu, sepsání plánu řízení
10 Business Case = obchodní případ
11 Specific = specifický
12 Measurable = měřitelný
13 Achievable = dosažitelný
14 Relevant = relevantní
15 Time-Oriented = časově orientovaný
rizik, dokumentace plánu projektu, získání souhlasu vyššího vedení se zahájením projektu (Wysocki K. Robert 2009).
PMI popisuje skupinu procesů plánování jako „procesy prováděné za účelem stanovení celkového rozsahu úsilí, definování a upřesnění cílů a vypracování postupu činností potřebných k dosažení těchto cílů“ (PMI 2013). Tento proces pomáhá vypracovat plán řízení projektu a projektové dokumenty, které budou použity pro realizaci celé projektové práce.
To znamená, že proces plánování slouží k určení strategie, která umožní úspěšné dokončení projektu. Skupina procesu plánování vytváří plán řízení projektu a další projektové dokumenty jako výstup, který obsahuje podrobnosti o rozsahu projektu, čase, nákladech, kvalitě, komunikaci, lidských zdrojích, rizicích, veřejných zakázkách a zapojení zainteresovaných stran.
Při vlastní realizaci je však pravděpodobné, že se původní plán změní, což vyžaduje nezbytné aktualizace, aby vyhovoval zamýšlenému výsledku. Proto je důležité, aby v této fázi projektový manažer a jeho tým zapojili všechny potřebné stakeholdery za účelem získání co nejvíce požadavků od nich. Tímto způsobem zainteresované strany s největší pravděpodobností přijmou konečný produkt nebo výsledek, protože si budou vědomy toho, co projekt pravděpodobně přinese. Plán projektu musí schválit příslušné orgány, aby mohl pokračovat do fáze realizace.
1.4.3 Realizační proces
PMI definuje skupinu procesů realizace jako „procesy prováděné za účelem dokončení prací definovaných v plánu řízení projektu, aby byly splněny specifikace projektu. Tato skupina procesů zahrnuje koordinaci lidí a zdrojů, řízení očekávání zainteresovaných stran a také integraci a provádění činností projektu v souladu s plánem řízení projektu“
(PMI 2013). Právě v této fázi dochází k mnoha změnám původního plánu projektu, které vyžadují nezbytné aktualizace, aby byly splněny specifikace projektu.
Patří sem změny očekávaného trvání činností, změny v produktivitě a dostupnosti zdrojů a nepředvídaná rizika. Tyto změny obvykle ovlivňují plán řízení projektu takovým způsobem, že mohou vyžadovat další analýzu a opatření, která mohou vést ke změně plánu projektu. Stojí za zmínku, že právě v této fázi dochází k převážné části výdajů projektu a reakce na nové změny ovlivňují výstupy projektu negativně nebo pozitivně v závislosti na tom, jak na tyto změny reaguje projektový manažer.
1.4.4 Procesy monitorování a kontroly
Institut projektového řízení definuje skupinu procesů monitorování a kontroly jako
„procesy potřebné ke sledování, přezkoumávání a organizování postupu a výkonu projektu; identifikaci oblastí, v nichž je třeba provést změny plánu, a zahájení příslušných změn“ (PMI 2013). Sledováním a kontrolou projektu je projektový manažer schopen identifikovat všechny odchylky od plánu řízení projektu a přijmout nápravná
opatření tak, aby bylo dosaženo zamýšleného konečného produktu nebo výsledku. Tato skupina procesů se skládá z následujících částí:
1) Kontrola změn, doporučování nápravných nebo preventivních opatření při předvídání možných problémů.
2) Sledování a porovnávání probíhajících úkolů projektu s plánem řízení projektu a měřením výkonnosti projektu.
3) Ovlivňování těch faktorů, pomocí kterých se lze vyhnout dodatečným změnám.
(PMI 2013)
Proces monitorování a kontroly poskytuje projektovému manažerovi a projektovému týmu ucelený obraz o projektu, pomáhá jim identifikovat oblasti, které vyžadují hlavní pozornost, a tam, kde existuje pravděpodobnost, že projekt může sklouznout do problémů, jsou přijímána nápravná nebo preventivní opatření. To může opět vést k aktualizaci plánu řízení projektu, která může vyžadovat schválení ze strany vedení projektu zúčastněných stran.
1.4.5 Proces uzavření
Jedná se o závěrečnou fázi projektu, kdy jsou provedeny všechny nezbytné činnosti ve všech skupinách procesů projektového řízení, tak aby byl projekt oficiálně ukončen.
PMI identifikovala následující činnosti, které se provádějí za účelem ukončení projektu:
1) Získání souhlasu zákazníka nebo sponzora k formálnímu uzavření projektu nebo fáze.
2) Provedení přezkoumání po ukončení projektu nebo fáze.
3) Zdokumentování získané zkušenosti.
4) Aplikování příslušné aktualizace na aktiva organizačních procesů.
5) Uložení archivních dokumentů projektu v informačním systému pro řízení projektů, aby mohly být použity jako historické údaje.
6) Uzavření všech činností souvisejících se zadáváním veřejných zakázek a zajištění ukončení všech příslušných smluv.
7) Hodnocení členů týmu a uvolnění projektových zdrojů.
(PMI 2013)
Výše uvedené procesy se provádějí bez ohledu na to, zda byl projekt zcela dokončen, či nikoli. V případech, kdy dochází k předčasnému ukončení, je nutné zdokumentovat důvody, proč byl projekt ukončen.
1.5 Typologie projektů
V oblasti informačních technologií existuje velmi široká škála typů projektů, které lze realizovat. Ačkoli obecné principy projektového řízení jsou v zásadě společné pro všechny IT projekty a vlastně i pro projekty ve všech oborech, přesto existují způsoby, kterými se
jednotlivé typy IT projektů od sebe liší. V této kapitole si představíme 5 základních typů projektů dle Jamese Cadla a Donalda Yeatese (2008), s tím, že pro diplomovou práci budou zásadní projekty softwarového vývoje.
1.5.1 Softwarový vývoj
Vývojové projekty mají v zásadě mnoho společného s projekty stavebních prací a lze na ně aplikovat většinu tradičních metod a technik projektového řízení. Jedna konkrétní potíž, se kterou se manažeři stavebních projektů obvykle nesetkávají, se však týká zásadní nehmotnosti softwarového systému. U mostu nebo budovy lze projekt reprezentovat pomocí plánů a výkresů a ty jsou srozumitelné tomu, kdo projekt zadal. Pro uživatele softwaru je obvykle poměrně obtížné jasně vyjádřit svá přání a pro podnikové analytiky je zase obtížné je jednoznačně zachytit. Ať se o to všechny strany snaží sebevíc, určitě se najdou oblasti, kde mají dodavatel a zákazník odlišné představy o tom, co se má udělat, a kde se specifikace ukáže jako nejednoznačná.
To znamená, že manažeři softwarových projektů musí mít:
• Pružný přístup, který je připraven revidovat specifikaci a vyjednávat se zákazníkem v průběhu projektu.
• Dobře rozvinuté dovednosti v oblasti mezilidských vztahů a řízení zainteresovaných stran.
Vznik „agilního“ vývoje (viz kapitola 1.6.3) je částečně reakcí na obtížnost specifikace požadavků na software. Agilní přístup, kdy dodavatelé a zákazníci úzce spolupracují na zpřesnění svého chápání potřeb, může být lepším způsobem, jak se vypořádat s přirozenými nejistotami a neurčitostmi vývoje softwaru.
1.5.2 Infrastrukturní projekty
Tento typ projektů zahrnuje například zavádění nebo výměnu hardwaru, serverů nebo počítačů, zavádění komunikačních infrastruktur a někdy také fyzickou výstavbu, například počítačových sestav nebo vybavení a zařízení nové kancelářské budovy.
Na tento typ projektů se vztahují obecné zásady projektového řízení a jejich výhodou je, že výsledky projektu jsou obvykle hmatatelné na rozdíl od některých jiných IT projektů.
Existují však určité problémy, které musí manažeři tohoto typu projektů zvážit, včetně těchto:
• Obvykle je potřeba zachovat běžný provoz při zavádění nové infrastruktury. To může být složité například tam, kde je omezený prostor pro to, aby se staré a nové věci mohly umístit vedle sebe.
• V těchto projektech hraje velkou roli řízení dodavatelů, proto je důležité stanovit pevné a realistické termíny dodání a pečlivě prozkoumat vzájemné závislosti mezi jednotlivými úkoly. Pokud se tak nestane, může dojít k promarnění času, úsilí a peněz.
1.5.3 Migrace systémů
Tento typ projektu se objevuje v případech, kdy stávající systém již není podporován a je třeba ho přesunout do nového provozního prostředí. Během takovýchto změn je nutné provést určité přeškolení uživatelů, aby mohli využívat nové prostředí.
Úspěch projektu z uživatelského pohledu bude posuzován podle hladkosti přechodu a absence přerušení provozu během jejich práce.
1.5.4 Rozvoj systémů
Tento typ projektů vzniká, když uživatelé nebo vlastníci stávajícího systému chtějí, aby byl rozšířen o nové vlastnosti nebo funkce nebo aby splňoval nějaké vnější požadavky.
Například soulad s legislativou nebo předpisy. Takovéto projekty nemusí být rozpoznány nebo řízeny a jsou řešeny jako „běžná činnost“ podpory a údržby. Rozsáhlá vylepšení je však třeba řídit jako skutečné projekty, protože často jde o značný objem práce, času a nákladů. Existují některé specifické problémy, kterým projektový manažer může v tomto případě čelit:
• Obtížnost udržení stávajícího systému v provozu během prací na vylepšení.
• Skutečnost, že vývojáři, kteří se podílejí na vylepšení, se často věnují také podpoře systému, kdy může být obtížné vyvážit a sladit konkurenční požadavky na jejich čas.
• Potřeba důsledného „regresního testování“, aby se zajistilo, že nová vylepšení nepoškodí části stávajícího systému, které fungovaly dobře.
Jako vždy je klíčem k úspěchu pečlivá analýza požadavků a důkladné plánování projektu.
1.5.5 Implementace balíkových řešení
Nákup již existujícího softwarového balíčku a jeho instalace představuje alternativní a obvykle rychlejší a levnější způsob, jak splnit systémové požadavky zákazníka.
Implementace balíčku je v zásadě jednoduchá: balíček se koupí, nainstaluje, zapne a používá, podobně jako se kupuje a instaluje televizor nebo mikrovlnná trouba. Při pořizování softwarového balíčku však existují některé problémy, které se obecně netýkají televizorů a mikrovlnných trub, a to zejména:
• Pro zákazníka je obtížné vybrat si správný balíček. Rozsah funkcí televizoru nebo mikrovlnné trouby je relativně malý ve srovnání s podnikovým systémem, který je obvykle velmi složitý a musí se vypořádat s nesčetnými „výjimečnými situacemi“, které se liší od způsobu, jakým mají procesy fungovat. Důkladná analýza požadavků je součástí odpovědi, ale je třeba se smířit s tím, že zůstanou některé otázky týkající se detailů, které se objeví až při testování balíčku nebo dokonce po jeho instalaci a používání.
• Pro dodavatele může nastat problém, když je požádán, aby balíček upravil nebo přizpůsobil tak, aby odpovídal způsobům práce zákazníka. Většina balíčků umožňuje určitou míru přizpůsobení, ale někteří zákazníci mohou mít velmi
specifické způsoby práce, které nelze snadno přizpůsobit. Pokud nejsou očekávání zákazníka pečlivě řízena, mohou být uživatelé balíčku velmi zklamáni.
• Pro obě strany je důležitá otázka integrace balíčku s jinými stávajícími systémy. V dnešní době je velmi vzácné, aby byl jakýkoli systém zcela samostatný, a integrace balíčku do stávající IT infrastruktury může být velmi složitá. Velmi pečlivá analýza požadavků na integraci a podrobné plánování integračních prací jsou zde jednoznačně důležité.
Hlavními výzvami pro projektového manažera při implementace balíkových řešení jsou proto:
• Řízení řady dílčích projektů, přizpůsobení a úpravy balíčku, migrace a čištění dat, školení uživatelů, přechod ze starého na nový systém.
• Zajištění toho, aby dodavatelé splnili všechna svá tvrzení, která uvedli v procesu prodeje ohledně schopností svého produktu a jeho vhodnosti pro organizaci, v níž má být nasazen.
• Ale také to, aby kupující a uživatelé balíčku byli realističtí ve svých požadavcích na změny a přizpůsobení.
V konečném důsledku je nákup balíčku vždy pravděpodobně kompromisem mezi idealizovanými požadavky koncových uživatelů systému a tím, co si organizace může dovolit z hlediska času, úsilí a peněz. Vedle dobrých plánovacích schopností tak bude projektový manažer potřebovat vysoce rozvinuté interpersonální dovednosti, zejména pokud jde o řízení dodavatelů a zákazníků, vyjednávání a řešení konfliktů.
1.6 Modely řízení projektu a role PM
Pochopíme-li nejprve evoluční změny v řízení softwarových projektů, bude snazší pochopit rostoucí popularitu agilních přístupů. Korsaa a další (2001) rozdělili různé modely řízení softwarových projektů na vodopádové nebo agilní. S využitím chronologie Matkoviče a Tumbase (2010) budou následující podkapitoly pojednávat o dvou hlavních přístupech řízení softwarových projektů - sekvenčních a iterativních. Procházením dalších podkapitol bude také zpřístupněn kontext o tradičních rolích projektových manažerů a jejich porovnání s potřebami agilních projektových manažerů.
Tradiční sekvenční řízení projektů vyžaduje, aby se projektový manažer věnoval plánování, velení a kontrole, zatímco iterativní agilní řízení projektů vyžaduje, aby se projektový manažer vzdal větší kontroly nad týmem, trénoval jej k samostatnosti a převzal roli „servant-leadera“16 (Tripathi, Goyal 2014). Někteří autoři však tvrdí, že to jsou nepřiměřená očekávání, která je třeba hledat u jediného člověka, a tvrdí, že některé z těchto kompetencí by měly převzít jiné formy manažerů (Loufrani-Fedida and Missonier, 2015;Hodgson and Paton, 2016). Základní znalosti disciplíny projektového řízení spolu s
16 Servant-leader = vedoucí, který slouží svým lidem
nezbytnými měkkými dovednostmi a doplněné specializovanou praxí různých metodik a rámců tedy zvyšují náročnost zastávání pozice projektového manažera.
1.6.1 Sekvenční přístup – vodopádový (tradiční) vývoj
Vodopádový model definoval Winston W. Royce v roce 1970. Je také známý jako lineárně- sekvenční model životního cyklu. Tento model je snadno pochopitelný a použitelný. Každá etapa musí být dokončena, aby mohla začít další. Na konci každé etapy je projekt přezkoumán, aby se zajistil soulad s požadavky.
Obrázek 6 Tradiční model (Vodopádový model 2021) Mezi výhody tohoto modelu patří:
• dokumentace a struktura projektu je srozumitelná pro nově příchozí členy
• je snadno pochopitelný a použitelný
• je snadno koordinovatelný díky své rigiditě – každá fáze má očekávaný výsledek a proces hodnocení
• etapy se realizují postupně, jedna za druhou
• doporučuje se pro projekty s jasně srozumitelnými požadavky Mezi nevýhody patří:
• některé požadavky se mohou objevit až po dokončení jejich prvotního sběru, což negativně ovlivňuje vývoj produktu
• ne všechny problémy zjištěné v průběhu etapy jsou v téže etapě zcela vyřešeny
• neexistuje žádná flexibilita při rozdělování projektu na etapy
• nové požadavky přidané klientem vedou k dodatečným nákladům
• je obtížné odhadnout čas a rozpočet pro každou fázi
• neexistují žádné prototypy až do konce životnosti cyklu
• pokud testování odhalí nějaké problémy, je velmi obtížné vrátit se do fáze návrhu
• existuje vysoké riziko a nejistota, že zadavatel po skončení projektu nebude s výsledkem spokojen
• nedoporučuje se pro složité a objektově orientované projekty Vodopádový model se doporučuje v následujících případech:
• požadavky jsou dobře srozumitelné, jasné a konečné
• definice produktu je stabilní
• technologie je srozumitelná
• neexistují žádné nejednoznačné požadavky
• zdroje, které zahrnují odborné znalosti, jsou volně dostupné
1.6.2 Role projektového manažera ve vodopádovém modelu
V centru projektu využívající vodopádový model stojí projektový manažer. Tripathi a Goyal (2014) tvrdí, že projektový manažer je přímo zodpovědný za celkový výsledek projektu, dodržování plánu projektu a delegování práce na členy týmu. Shastri a další (2017) na tento bod navazují a diskutují o tom, že projektový manažer nosí ve vodopádovém projektovém týmu plášť velitele a kontrolora, který drží vše pohromadě pomocí kombinace tvrdých a měkkých dovedností, jako je komunikace, rozhodování, vedení, komunikace a plánování.
1.6.3 Iterativní přístup – agilní vývoj
Agilní vývoj softwaru se stal řešením výrazného růstu a vývoje technologií na konci 20. století, který vedl k neustále se měnícím požadavkům na software a projektům, které byly pravidelně dodávány s překročením rozpočtu nebo po termínu (Matkovic, Tumbas 2010). Nakonec to bylo v roce 2001, kdy se vůdčí osobnosti zastánců používání flexibilních a odlehčených metodik z předchozího desetiletí (Scrum, extrémní programování, adaptivní vývoj softwaru, metodika vývoje dynamických systémů nebo vývoj řízený funkcemi) spojily a přišly s názvem „agilní“. Poté stanovili 12 agilních principů, které budou sloužit jako základ pro různé varianty tohoto obecného agilního přístupu (Fowler, Highsmith 2001).
Podle Shastriho a dalších (2021) je model Agile Software Development17 (ASD) zastřešujícím termínem pro různé metodiky a rámce, které využívají iterativní a inkrementální přístupy, jež se zaměřují na lidi v týmu a principy podporující plynulé přizpůsobování se změnám v projektu. Tento bod podporují i Matkovic a Tumbas (2010),
17 Agile Software Development = agilní vývoj softwaru
když tvrdí, že ústřední roli v projektu hrají lidé v projektových týmech, nikoliv proces, a proto je třeba věnovat odpovídající pozornost jednotlivým členům, kteří tvoří tým, a zajistit, aby byli dobře vybaveni potřebnými kompetencemi, dovednostmi a zkušenostmi pro usnadnění diskusí, formulování rozhodnutí a vytváření řešení. Proto se procesu přikládá jen malý význam, protože se vychází z představy, že bez ohledu na to, jak je dobrý, nikdo nic nezmůže, pokud lidé nemají potřebné dovednosti. Nízká důležitost je přikládána také hierarchii řízení, protože ta stojí v cestě optimálnímu rozhodování. To vše je dobře podpořeno v původním Manifestu agilního přístupu, kde je výměna zkušeností mezi zkušenými odborníky projektového týmu upřednostňována před dokumentací, nástroji nebo procesy, stejně jako další tři hodnoty, kterými jsou zaměření na dodání funkčního softwaru před přílišnou pozorností věnovanou detailní dokumentaci, podpora zapojení zákazníka před smlouvami a přizpůsobení se změnám před rigidním dodržováním plánu (Fowler, Highsmith 2001).
Kromě těchto čtyř hodnot manifest zahrnuje také 12 již zmíněných agilních principů, které tvoří základ každé agilní metodiky vývoje.
1.6.4 Role projektového manažera v agilním modelu
Shastri a další (2016) ve své studii, jejímž cílem bylo zjistit, zda projektový manažer v agilní praxi skutečně existuje, zjistili, že téměř 70 procent jimi zkoumaných agilních týmů má stále projektového manažera. V následném výzkumu role projektového manažera v agilních softwarových týmech Shastri a další (2021) zjistili, že v těchto skupinách stále plní roli facilitátora, mentora, vyjednavače, ochránce a koordinátora.
Bez ohledu na prokázanou přítomnost projektových manažerů v agilních prostředích začínají být odpovědnosti projektového manažera v teoriích agilního modelu zpochybňovány. Kompetence projektových manažerů, které bývaly základem ve vodopádovém řízení projektů (např. role příkazce a kontrolora, plánování, řízení, realizace nebo rozhodování), již v agilním vývojovém modelu nepatří jedné osobě, ale přenechávají se většinou týmu. Ačkoli určitá míra plánování zůstává zachována, projektový tým nyní sdílí odpovědnost za rozhodování, řízení rizik, řízení změn a další povinnosti, které dříve zastával současný projektový manažer. Pro doplnění tohoto argumentu lze uvést, že některé metodiky ASD zcela odepsaly roli projektového manažera, například extrémní programování a převážně populární rámec Scrum (Schwaber and Sutherland Jeff, 2020;Beck and Andres, 2004;Barker, 2019).
1.6.5 Agilní vs. tradiční
Agilní metody jsou založeny na adaptivních metodách vývoje softwaru, zatímco tradiční modely Software Development Life Cycle18 (SDLC) jsou založeny na prediktivním přístupu. V tradičních modelech SDLC pracují týmy s podrobným plánem a mají k
18 Software Development Life Cycle = životní cyklus vývoje softwaru
dispozici úplný seznam charakteristik a úkolů, které musí být splněny v následujících několika měsících nebo v celém životním cyklu produktu. Prediktivní metody zcela závisí na analýze požadavků a pečlivém plánování na začátku cyklu. Každá změna, která má být zahrnuta, projde přísným řízením změn a stanovením priorit. Agilní model využívá adaptivní přístup, kdy neexistuje žádné podrobné plánování a jasné jsou pouze budoucí úkoly související s vlastnostmi, které je třeba vyvinout. Tým se přizpůsobuje dynamickým změnám požadavků na produkt. Produkt je často testován, čímž se minimalizuje riziko závažných chyb v budoucnu. Silnou stránkou agilní metodiky je interakce se zákazníky a typickými znaky agilního vývojového prostředí jsou otevřená komunikace a minimální dokumentace. Týmy úzce spolupracují a často se nacházejí ve stejném geografickém prostoru.
Zatímco agilní SDLC je vhodnější pro malé a střední projekty, u velkých projektů je stále lepší volbou tradiční SDLC. Proto je důležité, aby si vývojový tým vybral SDLC, které je pro daný projekt nejvhodnější. Existují kritéria, podle kterých může vývojový tým určit rozměr požadovaného SDLC. Patří mezi ně velikost týmu, geografická poloha, velikost a složitost softwaru, typ projektu, obchodní strategie, inženýrské schopnosti atd. Také je velmi důležité, aby tým před rozhodnutím prostudoval rozdíly, výhody a nevýhody jednotlivých SDLC. Kromě toho musí tým před vyhodnocením SDLC prostudovat kontext podniku a požadavky odvětví. Je důležité mít proces hodnocení a výběru SDLC, protože maximalizuje šance na vytvoření úspěšného softwaru. Proto je výběr a přijetí vhodného SDLC manažerským rozhodnutím s dlouhodobými důsledky.
Ačkoli agilní metodiky vítězí nad tradičními v několika ohledech, existuje mnoho obtíží při jejich zavádění do praxe. Jedním z nich je výrazné omezení dokumentace a tvrzení, že dokumentací by měl být samotný zdrojový kód (Vijayasarathy, Turk 2008). Vývojáři zvyklí na agilní metody tak mají tendenci vkládat do zdrojového kódu více komentářů za účelem vysvětlení a objasnění. Pro začínající vývojáře nebo nové členy týmu je obtížné plnit úkoly, když nemohou projektu plně porozumět. Pokládají zkušenému vývojáři spoustu otázek, což může zpozdit dokončení iterace, což může vést ke zvýšení nákladů na vývoj.
Na druhou stranu tradiční metody kladou důraz na dokumentaci při orientaci a objasnění projektu vývojovému týmu, takže odpadá obava z neznalosti detailů projektu nebo z toho, že vývojáři nemají dostatečné znalosti.
Pro každou dodanou verzi uspořádá vývojový tým a klienti schůzku, na které tým představí práci vykonanou v aktuální iteraci a klienti poskytnou zpětnou vazbu k dodanému softwaru (vylepšení stávajících funkcí nebo přidání nových).
Vývojáři většinou považují pravidelnou schůzku (obvykle jednou týdně) za nudnou a únavnou, protože musí moduly prezentovat opakovaně novým členům a klientům. V každé iteraci může dojít ke změnám na žádost klientů.
Na druhou stranu tradiční metodiky mají před zahájením procesu implementace a kódování dobře definovaný model požadavků, který slouží vývojovému týmu jako reference během procesu kódování. Klienti se této fáze životního cyklu vývoje neúčastní.
Vývojový tým provádí kódování podle dokumentace poskytnuté obchodními analytiky, dokud není systém dokončen, a teprve poté je prezentován klientům jako finální produkt.
