Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Metodika PRINCE2 v praxi Diplomová práce
Autor:
Bc. Dana Čapkovičová Ekonomika a management, Informační technologie a management
Vedoucí práce:
Praha
Ing. Bc. Jiří Rezler
Červen 2012
Prohlášení: Prohlašuji, ţe jsem tuto diplomovou práci zpracovala samostatně a v seznamu uvedla veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámena se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
...................................... V Praze, dne 17. června 2012
Bc. Dana Čapkovičová
Poděkování Tímto bych chtěla poděkovat vedoucímu mé diplomové za cenné připomínky k mé diplomové práci. Taktéţ bych chtěla vyjádřit své díky kolegům za jejich tvrdou práci na realizaci projektu, který je náplní mé diplomové práci. Jedná se jak o interní tým (HK, HG, SB, DP, VB, LP, JS) tak i o tým dodavatele (ZA, PČ, MCH, TK), který vţdy v případě potřeby podal pomocnou ruku. Jmenovitě bych chtěla poděkovat vedoucímu týmu dodavatele (ZA) jehoţ mnoholeté zkušenosti s metodikou PRINCE2 mi často pomohly jak v praxi tak při psaní mé diplomové práce.
Anotace Tato diplomová práce se zabývá primárně aplikací metodiky PRINCE2 pro řízení projektů v praxi. V teoretické části se zabývám teorií projektového řízení a vznikem metodiky PRINCE2. V praktické části popisuji na reálném projektu, jehoţ jsem projektovým manaţerem, jakým způsobem byla metodika PRINCE2 konkrétně aplikována v praxi. Praktickým přínosem této práce je popis, jak mohou být vybrané principy, procesy a témata metodiky PRINCE2 pouţity v praxi. Annotation This diploma thesis primarily deals with application of project management PRINCE2 methodology in practice. In the theoretical part is described the base of the project management theory and also historical evolution of the PRINCE2 methodology. In the practical part is than described on a real project which I am managing as a project manager in my job how the PRINCE2 methodolgy was applied on concrete examples. The benefit of this thesis is a description how particular principles, processes and themes recognized by PRINCE2 methodology can be applied in the practice.
Obsah 1
Úvod .............................................................................................................................. 7
2
Teoretická část .............................................................................................................. 9 2.1
Řízení projektů a metodiky ................................................................................ 9
2.1.1
Definice základních pojmů projektového řízení ................................................ 9
2.1.2
Historie projektového řízení ............................................................................ 11
2.1.3
Metodiky řízení projektů ................................................................................. 14
2.2
Vývoj metodiky PRINCE2................................................................................ 16
2.2.1
Metodika PROMPT II ..................................................................................... 16
2.2.2
Metodika PRINCE........................................................................................... 18
2.2.3
Metodika PRINCE2......................................................................................... 20
2.3
3
Metodika PRINCE 2 ......................................................................................... 21
2.3.1
„The Principles“ (Principy) ............................................................................. 21
2.3.2
„The Themes“ (Témata) .................................................................................. 25
2.3.3
„The Processes“ (Procesy) .............................................................................. 26
Praktická část .............................................................................................................. 27 3.1
Projekt FIM ....................................................................................................... 27
3.1.1
Prostředí společnosti QUIMPER ..................................................................... 27
3.1.2
QES Program ................................................................................................... 30
3.2
Aplikace metodiky PRINCE2 ........................................................................... 34
3.2.1
„Project Lifecycle“ (Ţivotní cyklus projektu) ................................................. 34
3.2.2
„Pre-project“ (Před projektem) ........................................................................ 36
3.2.3
„Project initiation stage“ (Etapa nastavení projektu) ...................................... 45
3.2.4
„Subsequent delivery stages“ (Dílčí dodávkové etapy) .................................. 58
3.2.5
„Final delivery stage“ (Etapa konečné dodávky) ............................................ 69
3.2.6
„Processes“ (Procesy) ...................................................................................... 70
3.2.7
„Themes“ (Témata) ......................................................................................... 76
3.2.8
Cena (strávený čas).......................................................................................... 79
3.2.9
Harmonogram .................................................................................................. 81
3.2.10
„Lessons learned“ (Poučení) ....................................................................... 83
4
Závěr............................................................................................................................ 86
5
Seznam použité literatury ........................................................................................... 87
6
Seznam obrázků .......................................................................................................... 90
7
Seznam tabulek ........................................................................................................... 91
8
Slovník pojmů ............................................................................................................. 92
9
Seznam příloh ............................................................................................................. 93
1 Úvod Cílem této práce je seznámit čtenáře s metodikou projektového řízení PRINCE2 a aplikováním jejich myšlenek v praxi na reálném projektu. Projektové řízení má podle metodiky PRINCE2 čtyři aspekty: Principy („Principles“) Témata („Themes“) Procesy („Processes“) Prostředí / Okolí („Project Environment“).
Obrázek 1 - Struktura Metodiky PRINCE2 [1]
V rámci své práce se zaměřuji na popis ţivotního cyklu skutečného projektu, který ve stávající době vedu ve svém zaměstnání a popisuji jakým způsobem byly nástroje definované metodikou PRINCE2 v praxi. Projekt, který ve své práci popisuji v současné době ještě není ukončen a proto se ve své práci zaměřuji především na fázi přípravy projektu, nastavení projektu a průběţných dodávek projektu. Vyhodnocení projektu, které je uvedeno na konci mé práce, se vztahuje ke stavu projektu ke dni 10. června 2012. Konkrétně se ve své práci zabývám: Historickým vývojem metodik pro řízení projektů Popisem hlavních myšlenek metodiky PRINCE2 7
Popisem prostředí, ve kterém byl projekt řízen Jednotlivými fázemi ţivotního cyklu popisovaného projektu Aplikací principů, témat a procesů jak je definuje PRINCE2 Vyhodnocením projektu. Protoţe se principy, témata, procesy a prostředí (jak k nim přistupuje metodika PRINCE2 během ţivotního cyklu projektu) prolínají, pro lepší přehlednost je aplikace konkrétního principu / tématu / procesu v textu označena obrázkem (viz. níţe). PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
Obrázek 2 - Příklad obrázku použitého pro zpřehlednění práce (vlastní tvorba)
Jelikoţ metodika PRINCE2 je původem britská metodika řízení projektů, originální názvosloví je v angličtině. Vzhledem k tomu, ţe v praxi projektového řízení je nejčastěji pouţívano původní anglické názvosloví a pouţití českého překladu by mohlo vést k nepřesnému pouţívání, pouţívám anglické názvosloví ve své práci i já. Slovníček nejdůleţitějších pojmů (překlad anglických názvů do češtiny) je uveden v příloze mé práce. Z důvodu anonymizace mé práce poţadované mým zaměstnavatelem pouţívám ve své práci fiktivní jména společností a osob. Jejich přehled je taktéţ uveden v příloze mé práce.
8
2 Teoretická část 2.1 Řízení projektů a metodiky 2.1.1 Definice základních pojmů projektového řízení Projektové řízení lze definovat jako proces plánování a řízení zdrojů (lidských, finančních atd.) s cílem dosáhnout poţadovaných výstupů za pomoci různých technik (metodik) a nástrojů určených pro řízení projektů. Projekt lze definovat jako řízenou činnost, při které je prováděna řada různorodých koordinovaných aktivit za účelem vyvinutí či modifikace procesu, produktu či sluţby v rámci předem daných omezení a za průběţného působení rizikových faktorů. Riziko lze definovat jako libovolný faktor, který můţe ohrozit úspěšné dokončení projektu. Riziko není moţné zaměňovat s problémem. Zatímco problémem je situace, která jiţ nastala, riziko definuji jako rozpoznání problému, který můţe nastat. Na základě rozpoznání potenciálních problémů se projektový manaţer můţe pokusit zamezit problémům vhodnými akcemi . Omezení projektu lze definovat jako riziko, které se vyskytne se 100 % pravděpodobností. Projektová omezení mohou ohrozit úspěšné dokončení projektu. Příklady běţných projektových omezení jsou následující: předem stanovené termíny, limitované finanční či lidské zdroje, lokalita nasazení řešení, speciální poţadavky a vazby na dodávky z jiných projektů. Projektový plán je dokument, který popisuje kdy (hrubý časový harmonogram) a jak (organizace projektu) by měl být projekt realizován, monitorován a kontrolován. Tento dokument se pak pouţívá jako vodítko pro realizaci projektu. Primárním účelem projektového plánu je zdokumentovat předpoklady, rozhodnutí, rozsah, cenu a harmonogram a usnadnit komunikaci mezi zúčastněnými stranami. Dále pak můţe obsahovat plán rizik (analýza rizik včetně návrhu eliminačních opatření), schvalovací procedury, poţadavky na změny, způsob zpracování projektové dokumentace, akceptační kritéria, finanční plán projektu atd. Projektový plán by měl odpovědět na následující otázky: „Proč?“, „Co?“, „Kdo?“ a „Kdy?“, které jsou zásadní pro správné porozumění
9
mezi zadavatelem a realizátorem projektu. Projektovým plánem můţe být jeden či více dokumentů. [2] Harmonogram projektu – časový plán projektu, definující kdy bude která aktivita vykonána, kým, za jaké časové období a v jakých návaznostech, nejčastěji vytvořená pomocí Ganttova diagramu. Projektový manažer – osoba s odpovídajícími pravomocemi odpovědná za řízení projektu na denní bázi v rámci limitů nastavených a odsouhlasených pro daný projekt. Sponzor projektu – osoba zodpovědná za naplnění stanoveného cíle projektu, očekávaných přínosů, udrţení obchodního záměru a stanovení pravomocí. Sponzor projektu zastupuje zákazníka a jeho zájmy a je vlastníkem obchodního případu.[3]
10
2.1.2 Historie projektového řízení [4,5] Kdyţ se hovoří o historii projektového řízení, jedním z často uváděných příkladů nejstarších projektů je stavba egyptských pyramid. Avšak historie projektového řízení, tak jak ho známe teď, započala v 50. letech 20. století. 2.1.2.1 Konec 19. století a počátek 20. století Jedním z impulzů pro vznik metodologií projektového řízení byly rozsáhlé vládní projekty, kdy podnikatelé museli najednou čelit rostoucímu mnoţství úkolů spojených s organizací manuální práce stovek aţ tisíců dělníků a velkými objemy materiálu pro zpracování a montáţ. Jedním z nejznámějších příkladů je stavba transkontinentální ţeleznice, která započala v 60. letech 19. století v USA. Frederick Taylor (1856 – 1915) na přelomu 19. a 20. století započal svou studii o zvyšování produktivity práce zaměřením se na dílčí části práce, na jejímţ konci představil koncept zvýšení produktivity práce pomocí navýšení její efektivity. Namísto toho, aby zaměstnanci pracovali dlouze a těţce, pracovali rychleji a efektivněji, coţ v té době byla naprosto nová myšlenka. Frederick Taylor je právem povaţován za „otce vědeckého managementu“ (jak má ostatně uvedeno i na svém náhrobku). Henry Gantt (1861 – 1919), kolega Fredericka Taylora podrobně zkoumal pořadí jednotlivých úkonů při vykonávání práce se zaměřením na výstavbu lodí námořnictva během první světové války. Ganttovy diagramy tvořené pruhy a znaky zastupujícími milníky načrtávají pořadí a trvání všech úkolů, potřebných pro dodání produktu. Ganttův diagram je velmi silným analytickým nástrojem, jenţ se v téměř nezměněné podobě pouţívá aţ dodnes. V dalších desetiletích na počátku 20. století aţ do počátku 2. světové války zaujaly v projektovém řízení své místo disciplíny jako marketing, psychologie a mezilidské vztahy. Během 2. světové války vznikla kvůli nedostatku pracovních sil a komplexních vládních a armádních projektů potřeba nových organizačních struktur. PERT (komplexní síťové diagramy) a metoda kritické cesty daly manaţerům více kontroly nad obrovskými projekty. Tyto techniky se záhy rozšířily do všech moţných odvětví, jelikoţ manaţeři v té době hledali vhodné strategie a nástroje jak úspěšně řídit své společnosti v rychle se měnícím a konkurenčním prostředí. 11
2.1.2.2 60. léta 20. století Během 60. let 20. století se stalo součástí projektového managementu i řízení nákladů a s tím související plánování projektových zdrojů. Projektové řízení bylo zaloţeno na aplikování systémových teorií v praxi, konkrétně např. síťové techniky pro plánování, časování a kontrolování projektu. V knize „Theory and Management of Systems“ Richard Johnson, Fremont Kast a James Rosenzweig popsali, jak se moderní podnikání podobá lidskému organismu – má svou kosterní soustavu, svalový systém, cévní soustavu, nervovou soustavu atd. Projektový management byl v té době stále pouţíván hlavně v odvětví obrany, stavitelství a letectví. [4,5] Vznikly první profesní organizace zabývající se projektovým řízením. Evropská IPMA (1965, International Project Management Association, dříve IMSA) vznikla původně jako fórum pro profesionály v síťovém plánovaní, aby mohli sdílet své znalosti a zkušenosti. V dnešní době zastřešuje 15 převáţně evropských národních asociací zaměřených na projektové řízení. V roce 1969 vznikl v USA PMI (Project Management Institute). V dnešní době působí PMI převáţně v USA a Kanadě a má přibliţně 50 poboček. 2.1.2.3 70. léta 20. století Během 70. let minulého století se vyuţití projektového řízení rozšířilo do téměř všech odvětví podnikání. Dále se rozvíjely nástroje a techniky pro projektové řízení včetně WBS (Work Breakdown Structure), OBS (Organization Breakdown Structure), matice pro přirazení zodpovědnosti, atd. Dále byl kladen důraz na řešení konfliktů na projektech. V 70. letech začal být projektový management vnímán jako profese. 2.1.2.4 80. léta a počátek 90. let 20. století V této době bylo projektové řízení rozšířeno o řízení rozsahu projektu, kvality, rizik, lidských zdrojů a komunikace. Začalo se klást mnohem více důrazu na řízení počátečních fází projektu jako například identifikace potřeb zákazníka, studie proveditelnosti, analýza hodnot, strategie řízení rizik, analýza zájmových skupin (stakeholders analysis), omezení daných vnějším prostředím, atd. Projektové řízení začalo být vnímáno jako vhodná metodologie pro odpověď na změnu nebo pro vyvolání změny. Během 80. a 90. let bylo taktéţ vyvinuto mnoho úsilí na 12
prezentaci projektového managementu jakoţto strukturované disciplíny (např. PMBOK vydaný PMI). Vznikly také programy pro registraci a certifikaci projektových manaţerů. Na rozvoj projektového řízení mělo značný vliv rozšíření počítačů a moţnost připojit je do sítě. Toto umoţnilo zvýšit schopnost kontroly vlastní práce stejně jako koordinaci s ostatními členy týmu. Byly vyvinuty nové a efektivnější počítačové programy, které taktéţ usnadnily vykonávání i řízení projektů. 2.1.2.5 Blízká minulost a současnost [6] Rozvoj projektového řízení se stále nezastavil. Během posledních 10 let se objevily dva výrazné a důleţité trendy: Plánování zdola-nahoru – tento trend dává důraz na jednodušší návrhy projektů, kratší projektové cykly, efektivní spolupráci mezi členy týmu a jejich angaţovanost a rozhodování. Tento trend je obecně znám jako agilní projektové řízení a spadají pod něj metodologie jako Scrum, Crystal, Extrémní programování, Unified Process atd. Plánování a revize shora-dolů – tento trend je charakteristický rozhodováním o portfoliu projektů, které by podnik měl mít napříč celým podnikem stejně tak jako různými technologiemi pro dolování dat vyuţívaných pro zvýšení transparentnosti projektového portfolia. Nejnovější trendy v projektovém řízení ukazují rostoucí konzolidaci štíhlých („lean“) metodologií, vzrůstající vyuţívání technologií, plošší organizace, zmocněné zaměstnance a lepší spolupráci v prostředí globalizace.
13
2.1.3 Metodiky řízení projektů [7,8] 2.1.3.1 Tradiční projektové řízení Všechny projekty, nezávisle na metodologii projektového řízení, mají pět základních fází: zahájení, plánování, realizace, monitorování a dokončení. Kaţdá z těchto fází je rozdělena do menších částí a následující fáze projektu můţe začít pouze po ukončení fáze předcházející, i kdyţ v praxi je běţné, ţe se jednotlivé fáze mohou cyklicky vracet k předchozí fázi. Tato metodologie je běţná ve stavebnictví, kde práce postupuje lineárně a změny bývají minimální. 2.1.3.2 Metoda kritické cesty (CPM) Metoda kritické cesty (Critical Path Method, CPM) přiřazuje kaţdému úkolu dobu trvání a určuje zdroje nezbytné k dokončení projektů v nejkratším moţném čase.
Pro lepší
pochopení – pokud dojde v jednom z úkolů v rámci projektu, který je řízen dle metodiky kritické cesty, k jednodennímu zpoţdění, tak se také datum dokončení projektu posune o tento jeden den (nejsou ţádné časové rezervy a prostoje). 2.1.3.3 Metoda kritického řetězce (CCPM) [9] Metoda kritického řetězce na rozdíl od metody kritické cesty klade důraz spíše na zdroje neţ na časová omezení. Zjednodušeně je kritický řetězec sekvencí úkolů, které jsou pracovníci schopni efektivně zvládnout. Metoda kritického řetězce je vhodná pro projekty, kde jsou omezené zdroje a poţadavky na čas potřebný k dodání produktů projektu nejsou příliš přísné. Základním principem plánování projektu je určit kritickou cestu projektu a přidat časovou rezervu (na konec plánu). Důraz je kladen na dodrţení naplánovaného termínu ukončení projektu, na rozdíl od jiných metod, kde je důraz kladen na dodrţení termínů splnění jednotlivých úkolů. 2.1.3.4 Metoda řetězce událostí (ECM) Metoda řetězce událostí (ECM) se vyuţívá pro projekty, jejichţ jednotlivé úkoly vyvolávají řetězce událostí. Ukončení kaţdého úkolu vyvolává novou událost, která se musí zpracovat jako nový úkol. Události mohou být jako očekávané, tak neočekávané; bez následků i riskantní. Proto je nutné řídit tyto projekty s velkou obezřetností.
14
2.1.3.5 Agilní řízení projektů [10] Metoda agilního řízení projektů je iterativní metoda pro určení poţadavků v technických odvětvích a v IT projektech. Na rozdíl od iterativního řízení projektů se doby trvání dodání dílčích dodávek pohybují v týdnech a ne měsících. Agilní řízení projektů je velmi flexibilní a interaktivní. Tato metoda je vhodná pro menší projekty nebo části větších programů, případně pro projekty, které jsou příliš komplexní a zákazník není schopen jasně definovat své poţadavky předtím, neţ jsou mu dodány první prototypy. Agilní metoda řízení projektů ma vazby na štíhlé (lean) techniky a metodiku Six Sigma. Vzledem k tomu, ţe metoda agilního řízení projektů je odvozena od agilního vývoje softwaru, její techniky týkající se spolupráce a dokumentace vycházejí ze standardů stanovených v agilním manifestu. Mezi další známé metodiky projektového řízení, pouţívaných především v oblasti informačních technologií patří Six Sigma, Scrum, XP („Extreme Programming“), Crystal, FDD („Features Driven Development“), DSDM („Dynamic Systems Development“), Adaptive Software Development, RUP („Rational Unified Process“) a PRINCE2, kterým se ve své práci dále zabývám.
15
2.2 Vývoj metodiky PRINCE2 [11,12] Metodika PRINCE2 vznikla v roce 1996 na základě revize metodiky PRINCE. Ta se vyvinula v roce 1989 z metodiky PROMPT II, která vznikla jiţ roku 1975. 1975 PROMPT II
1989 PRINCE
1996 PRINCE 2
1974
2009 PRINCE 2: 2009 Refresh
2012 2006 - 2009 Revize metodiky PRINCE 2
Obrázek 3 - Vývoj metodiky PRINCE2 (vlastní tvorba)
2.2.1 Metodika PROMPT II Za prvního přímého předchůdce metodiky PRINCE2 se dá označit metodika PROMPT II (Project Organization, Management and Planning Techniques). Tato metodika byla určena výhradně pro řízení IT projektů. 2.2.1.1 Vznik metodiky PROMPT II Metodika PROMPT II vznikla ve Velké Británii roku 1975 ve společnosti Simpact Systems Ltd. O její vznik se zaslouţila především skupina bývalých projektových manaţerů ze společnosti IBM. Hlavním impulsem pro vývoj této metodiky byla skutečnost, ţe náklady i časová náročnost většiny IT projektů v té době několikanásobně překračovaly původní odhad vzniklý na základě studie proveditelnosti. 2.2.1.2 Sedm etap životního cyklu IT projektů dle PROMPT II Hlavním cílem metodiky PROMPT II bylo stanovit zásady jednotlivých etap ţivotního cyklu IT projektu. Podle PROMPT II má ţivotní cyklus IT projektu následujících sedm etap: 1. Studie proveditelnosti [13] („Feasibility study“) jejímţ primárním účelem je ověření reálnosti podnikatelského záměru (v našem případě vývoj nového informačního systému atd.). Ověření reálnosti je dosaţeno prověřením všech 16
hledisek,
které
jsou
významné
pro
daný
podnikatelský
záměr.
Studie
proveditelnosti by měla zodpovědět tyto hlavní otázky: Měl by být projekt vůbec realizován? Je technicky moţné projekt realizovat? Je zvolené technologické řešení vhodné? Bude navrhnuté řešení v praxi fungovat? Přinese to, co od něj očekáváme? 2. Počáteční etapa projektu (Initial stage) během které by se měla ustanovit organizace projektu. 3. Tvorba uživatelských specifikací (Specification stage) – definice uţivatelských poţadavků na systém (funkční i nefunkční). 4. Návrh (Design stage) – detailní analýza uţivatelských poţadavků a následný technický návrh řešení. 5. Vývoj (Development stage) – vývoj a testování řešení na základě podkladů vzniklých v předchozích dvou fázích. 6. Instalace (Installation stage) – akceptace funkčního řešení uţivatelem. 7. Provoz (Operations stage) – provoz nového a odladěného systému v reálném prostředí. 2.2.1.3 Další vývoj metodiky PROMPT II Roku 1979 byla metodika PROMPT II přijata jako oficiální metodika řízení IT projektů v britské vládní Agentuře pro výpočetní techniku a telekomunikace (Central Computing and Telecommunications Agency (CCTA)), která se v roce 2000 stala součástí Úřadu pro vládní obchodování (Office of Government Commerce (OGC)). Metodika PROMPT II prošla v roce 1989 rozsáhlou revizí a na základě této revize vznikla metodika PRINCE (Projects in Controlled Environment).
17
2.2.2 Metodika PRINCE Metodika PRINCE (PRojects In Controlled Environment) vznikla roku 1989 z metodiky PROMPT II v CCTA a stala se oficiální metodikou řízení veškerých britských vládních IT projektů. 2.2.2.1 Základní kameny metodiky PRINCE Metodika PRINCE byla postavena na čtyřech níţe uvedených základních principech: 1. Jasně definovaná struktura pro řízení projektu. 2. Systém plánů pro řešení problémů se zdroji a technickými potíţemi. 3. Sada kontrolních procedur. 4. Zaměření se na produkty projektu (produkt dodaný zákazníkovi i produkty určené pro řízení projektu). Naprostou novinkou, kterou zavedla metodika PRINCE a kterou neobsahovala v té době ţádná jiná metodika, byla myšlenka zajištění vývoje projektu ze tří různých, ale propojených pohledů: obchodního, technického a uţivatelského. Kaţdý z těchto pohledů byl zajištěn osobou (případně více osobami), která zaujímala v projektu specifickou roli: Koordinátor pro zajištění obchodního pohledu („Business Assurance Coordinator“ (BAC)) – Úlohou této role je dohlíţet, ţe projekt je v souladu se zájmy firmy. Tato role byla v metodice PRINCE2 nahrazená rolí Sponzor projektu („Executive“). Koordinátor pro zajištění technického pohledu („Technical Assurance Coordinator“ (TAC)) – Úlohou této role je dohlíţet nad technickými aspekty projektu a zajišťovat, ţe nenastanou během ţivota projektu technické problémy. Tato role byla v metodice PRINCE2 nahrazená rolí Hlavní dodavatel („Senior Supplier“). Koordinátor pro zajištění uživatelského pohledu („User Assurance Coordinator“ (UAC)) - Úlohou této role je reprezentovat případné budoucí uţivatele systému a hájit jejich zájmy. Tato role byla v metodice PRINCE2 nahrazená rolí Hlavní uţivatel („Senior User“).
18
2.2.2.2 Kritika metodiky PRINCE Metodika PRINCE byla podrobena mnohé kritice, především kvůli své těţkopádnosti, zkostnatělosti (neohebnosti) a aplikovatelnosti pouze na velké projekty. Z toho důvodu byla metodika PRINCE podrobena revizi a tato revize dala vzniknout metodice PRINCE2.
19
2.2.3 Metodika PRINCE2 Metodika PRINCE2 vznikla roku 1996 na základě revize metodiky PRINCE. Narozdíl od metodiky PRINCE je metodika PRINCE2 generická a aplikovatelná na téměř jakýkoliv projekt (nikoliv pouze na IT projekty jako tomu bylo u metodiky PRINCE). Metodika PRINCE2 pak velmi rychle nahradila v celé britské státní správě metodiku projektového řízení PROMPT II. V letech 2006 aţ 2009 provedla OGC zásadní revizi metodiky PRINCE2. Původní metodiku PRINCE2, která vznikla v roce 1996, bylo třeba přizpůsobit nové podobě podnikatelského prostředí, které se za 10 let podstatně změnilo. Mezi další změny, vycházející z revize, patří zjednodušení a “odlehčení” metodiky, vylepšení slabých stránek a vyjasnění nejasností. Revidovaná verze metodiky PRINCE2 umoţňuje taktéţ jednodušší integraci s jinými metodikami, které zavedla OGC (např. ITIL, P3O, P3M3, MSP, M_o_R atd.). V roce 2009 byla zveřejněna nová verze, známá jako PRINCE2: 2009 Refresh. Název PRINCE2 schválně nebyl nahrazen názvem PRINCE3 nebo něčím podobným, aby se zdůraznilo, ţe nová verze zůstala věrná principům deklarovaným v PRINCE2 jiţ v roce 1996. V současné době je PRINCE2 mezinárodně uznávanou metodikou pro řízení projektů v různých odvětvích.
20
2.3 Metodika PRINCE 2 [14, 15, 16, 17, 18] Tři základní pilíře metodiky PRINCE2 tvoří: Principy („Principles“), Témata („Themes“) a Procesy („Processes“), které dále popisuji v této kapitole.
2.3.1 „The Principles“ (Principy) Metodika PRINCE2 definuje 7 principů: Neustálé obchodní opodstatnění („Continued business justification“) Učení se ze zkušeností („Learn from experience“) Definované role a zodpovědnosti („Defined roles and responsibilities“) Řízení po etapách („Manage by stages“) Řízení po výjímkách („Manage by exceptions“) Zaměření se na produkty („Focus on products“) Uzpůsobení na míru prostředí projektu („Tailor to suit the project environment“). Tyto principy byly definovány na základě zkušeností z dřívějších projektů, jak těch úspěšných, tak těch neúspěšných. Osvojení si těchto sedmi principů v praxi je to, co určuje, zda je projekt řízen opravdu podle metodiky PRINCE2 či je tomu tak pouze na papíře. 2.3.1.1 „Continued business justification“ Základním poţadavkem metodiky PRINCE2 je opodstatněnost projektu; projekt musí mít své opodstatnění pro vlastní spuštění, toto opodstatnění by mělo být platné během celého ţivotního cyklu projektu. Opodstatnění projektu musí být zdokumentováno a schváleno jako součást Obchodního případu („Business Case“). Cíle projektu se mohou s postupem času změnit a proto je důleţité, aby se opodstatnění vyvíjelo ruku v ruce s projektem a bylo s projektem konzistentní. V okamţiku, kdy projekt ztratí své opodstatnění, by měl být zastaven nebo změněn. 2.3.1.2 „Learn from experience“ Kaţdý projekt je unikátní a jelikoţ členové projektového týmu nemusí mít předchozí zkušenosti z podobných projektů, je důleţité zkušenosti zaznamenávat. 21
Na počátku projektu je vhodné si zpětně projít předcházející či podobné projekty (můţe se jednat i o projekty externí) a pokusit se najít lekce, které by mohly být aplikovány na právě začínající projekt. V průběhu projektu by se projekt měl nadále „učit“. Lekce by měly být zahrnuty ve všech reportech a revizích. Zaznamenané lekce by měly vyvolat i změnu – cílem je najít moţnosti k zavedení zlepšení během ţivota projektu. 2.3.1.3 „Defined roles and responsibilities“ Pro úspěšnou realizaci projektu je třeba, aby všichni zúčastnění věděli, co se od nich očekává a co mohou očekávat od ostatních. U kaţdého projektu existují následující tři primární zájmové skupiny: Obchodní („Business“) sponzoři, kteří schvalují cíle projektu a zajišťují, ţe projekt přinese za vynaloţené náklady odpovídající hodnotu. V řídícím projektovém výboru jsou zastoupeni rolí Sponzor projektu („Executive“). Uţivatelé („Users“) budou po dokončení projektu vyuţívat jeho produkty. V řídícím projektovém výboru jsou zastoupeni rolí Hlavní uţivatel („Senior User“). Dodavatelé („Suppliers“) zajišťují zdroje a znalosti, potřebné k dodávní produktů projektu. V řídícím projektovém výboru jsou zastoupeni rolí Hlavní dodavatel („Senior Supplier“). Takto jasně daná organizace Výboru projektu zajišťuje stejné cíle pro různé skupiny lidí, podílejících se na projektu, a odpovídá na otázku „Co se ode mě očekává?“. 2.3.1.4 „Manage by stages“ Řízení po etapách umoţňuje pravidelnou kontrolu při ukončování kaţdé etapy, kdy se zhodnotí stav projektu a zreviduje Business case a plány a vyhodnotí další ţivotaschopnost projektu. Plánování po etapách je také výhodné , jelikoţ není moţné naplánovat práci příliš dopředu (např. na rok) tak, aby byl plán následně dodrţen. PRINCE2 vyuţívá high-level projektový plán a detailní plán stávající řídící etapy. PRINCE2 vyţaduje minimálně dvě řídící etapy – iniciační etapu a jednu nebo více dodávkových etap. 22
2.3.1.5 „Manage by exceptions“ Řízení po výjímkách spočívá v delegaci pravomocí o manaţerskou úroveň níţe a nastavení tolerancí pro kaţdý ze šesti projektových cílů, konkrétně: Čas („Time“) Náklady („Costs“) Kvalita („Quality“) Rozsah („Scope“) Riziko („Risk“) Přínosy („Benefits“) Pokud je pravděpodobné, ţe tolerance pro některou z proměnných bude překročena, je situace eskalována okamţitě o úroveň výše kde se rozhodne jak pokračovat. Toto pouţití velmi efektivně šetří čas vyššího managementu, který se tak musí zabývat pouze událostmi, které opravdu vyţadují jejich pozornost. 2.3.1.6 „Focus on products“ Úspěšný projekt by se měl zaměřit na produkty, nikoliv na aktivity. PRINCE2 pouţívá Popis produktu pro kaţdý produkt k definici jeho účelu, skladby, původ, strukturu, kvalitativní kritéria a kvalitativní metody. Tento popis umoţňuje určit odhad pracnosti, poţadavky na zdroje, vzájemné závislosti a harmonogram aktivit. Zaměření se na produkt PRINCE2 podporuje téměř kaţdým svým aspektem: plánováním, zodpovědností, reportováním stavu, kvalitou, kontrolou změn, rozsahem, řízením konfigurace, akceptací produktu a řízením rizik. Pokud není kladen dostatečný důraz na produkty, vystavuje se projekt rizikům, např. problémům s akceptací, předělávkám, nekontrolovatelným změnám, nespokojenosti uţivatelů a podcenění akceptačních aktivit. 2.3.1.7 „Tailor to suit the project environment“ Hodnota PRINCE2 spočívá v tom, ţe tato metodika můţe být přizpůsobena prostředí jakéhokoliv projektu. Pokud PRINCE2 není přizpůsoben prostředí daného projektu, je velmi pravděpodobné, ţe úsilí vynakládané na řízení projektu není adekvátní (roboticky a 23
bez přemýšlení je vykonáváno vše – příliš snahy pro nic). Jak konkrétně bude danému prostředí PRINCE2 přizpůsoben, musí být zdokumentováno v Dokumentu o nastavení projektu („PID“, „Project Initiation Document“).
24
2.3.2 „The Themes“ (Témata) V projektu musí být aplikováno všech sedm témat, ovšem v takové míře, která je vhodná pro daný projekt. Přizpůsobení můţe být oboustranné – jak rozšíření (např. další velmi detailní dokumentace u rozsáhlých projektů), tak zúţení (neformální procesy u malých projektů s nízkým rizikem). Témata, kterými se PRINCE2 zabývá konkrétně, jsou následující: Obchodní případ („Business Case”) - Téma Obchodní případ odpovídá na otázku Proč? Organizace („Organization”) - Téma Organizace odpovídá na otázku Kdo? Kvalita („Quality”) - Téma Kvalita odpovídá na otázku Co? Plány („Plans“) - Téma Plány odpovídá na otázky Jak? Za kolik? Kdy? Riziko („Risk“) - Téma Riziko odpovídá na otázku Co když? Změna („Change“) - Téma Změna odpovídá na otázku Jaký je dopad? Vývoj („Progress“) - Téma Vývoj odpovídá na otázky Kde teď jsme? Kam jdeme? Měli bychom pokračovat?
25
2.3.3 „The Processes“ (Procesy) Metodika PRINCE2 definuje následující procesy napříč ţivotním cyklem projektu: Zahájení projektu („Starting up a project“) – cílem tohoto krátkého procesu je nasbírat informace potřebné k zahájení projektu. Směrování projektu („Directing a project“) – vlastníkem tohoto procesu je vyšší management (řídící výbor projektu) a jeho cílem je umoţnit řídícímu výboru projektu, aby byl zodpovědný za úspěch projektu tím, ţe se bude věnovat pouze klíčovým rozhodnutím a běţné aktivity kaţdodenního řízení budou delegovány na projektového manaţera. Nastavení projektu („Initiating a project“) - cílem tohoto procesu je ověřit, ţe projekt má obchodní opodstatnění a definování parametrů projektu (v rámci dokumentu o nastavení projektu). Řízení přechodu do další etapy („Managing a stage boundary“) – cílem procesu je kontrolovaně ukončit jednu etapu projektu a naplánovat etapu následující. Kontrola etapy („Controlling a stage“) – tento proces popisuje především kaţdodenní aktivity projektového manaţera pro monitorování průběhu projektu a kontrolu jednotlivých aktivit. Řízení dodávky produktů („Managing product delivery“) – cílem tohoto procesu je zajistit dodání produktů projektu, které pak budou vyuţity uţivateli.
26
3 Praktická část 3.1 Projekt FIM Cílem této kapitoly je seznámit čtenáře s pozadím projektu FIM, kterým se ve své práci zabývám a na kterém popisuji aplikaci metodiky PRINCE2 v praxi. Název projektu „FIM“ vznikl podle vybrané technologie pro realizaci řešení v průběhu projektu. Původní název projektu byl FIM. Pro zjednodušení budu ve své práci pouţívat název projektu „FIM“. Tato kapitola popisuje skupinu QUIMPER, způsob řízení, projekty s projektem FIM úzce související a progam QES, který všechny tyto projekty zastřešuje.
3.1.1 Prostředí společnosti QUIMPER Skupina QUIMPER se specializuje na poskytování sluţeb v oblasti péče o zákazníky. Tyto sluţby jsou provozovány v několika centrech péče o zákazníky po celém světě, ve 27 jazycích pro více neţ 15 významných společností pohybujících se v letecké dopravě, turismu, kultuře, médiích, bankovnictví a pojišťovnictví. Sluţby poskytované skupinou QUIMPER pokrývají oblasti rezervací – prodeje, řešení stíţností, podpory věrnostních programů, podpora webu a konzultace. Zaměstnanci komunikují s koncovými zákazníky všemi běţnými komunikačními kanály – telefon, email, webové formuláře, běţná pošta, faxy, sociální média atd. Pro ilustraci výše zmíněného uvádím několik údajů, týkajících se skupiny QUIMPER (údaje z roku 2010): 4,36 mil. obslouţených hovorů 0,84 mil. odchozích hovorů 2,5 mil. vyřízených e-mailů, dopisů, faxů atd. cca 1200 interních zaměstnanců 3.1.1.1 Kontaktní centra skupiny QUIMPER QUIMPER obsluhuje své zákazníky ve svých kontaktních centrech rozmístěných po celém světě. QUIMPER rozlišuje dva typy kontaktních center: “Excellence centres” – centra vlastněná přímo skupinou QUIMPER 27
o Paříţ (Francie, dále označováno jako PAR) – zde sídlí i ředitelství skupiny QUIMPER o Praha (Česká republika, dále označováno jako PRG) o Ebene (Mauricius, dále označováno jako EBE) o Sydney (Austrálie, dále označováno jako SYD) “Service centres” – centra, která jsou ke skupině QUIMPER v roli dodavatele vybraných sluţeb poskytovaných koncovým zákazníkům. o Lens (Francie, dále označováno jako LEN) o Amsterdam (Nizozemí, dále označováno jako AMS)
Obrázek 4 - Pobočky společnosti QUIMPER (převzato z interní prezentace spol. QUIMPER)
V rozsahu projektu FIM, který ve své práci popisuji je zahrnut i jeden externí dodavatel zabývající se zpracováváním dokumentů, v textu je dále označován jako SAF. Skupina QUIMPER spolupracuje i s dalšími dodavateli, ale ti stojí mimo rozsah popisovaného projektu a proto o nich v této práci nebudu hovořit. 3.1.1.2 Organizace řízení v rámci skupiny QUIMPER Skupina QUIMPER i všechny její pobočky jsou řízeny primárně liniově (funkcionální struktura). V menších pobočkách (EBE, SYD) často řídí jeden top manaţer více oddělení. S rostoucím mnoţstvím projektů se však postupně způsob řízení v PRA a v PAR mění v maticové řízení (kombinace funkcionální a divizové struktury). 28
Celá skupina QUIMPER je řízena korporátním managementem (generální ředitel a viceprezidenti pro danou oblast), top manaţeři na jednotlivých pobočkách jsou primárně řízeni ředitelem dané pobočky, avšak podávají hlášení i korporátnímu viceprezidentovi zodpovědnému za danou oblast.
29
3.1.2 QES Program V roce 2009 otevřelo vedení skupiny QUIMPER korporátní program nazvaný QES, zahrnující několik projektů s cílem inovovat svou platformu pro distribuci hovorů a dalších typů příchozích kontaktů (e-mail, fax atd.). Program QES zahrnuje následující projekty: TELCO – nejrozsáhlejší projekt v rámci programu QES, jedná se o projekt zavedení nové platformy pro sběr, směrování, přidělování a vyřizování převáţně příchozích telefonních hovorů (v menší míře i pro některé druhy e-mailů, faxů atd.). DWH – projekt pro vybudování nového skupinového datového skladu určeného pro sběr a agregaci převáţně operativních dat ze všech kontaktních center v rámci skupiny QUIMPER. REC – projekt pro zavedení nástroje pro nahrávání a online monitorování hovorů a vyhodnocování jejich kvality. FIM – projekt, jehoţ cílem je zavedení centrálního nástroje pro správu identit uţivatelů různých systémů, převáţně spadajících do rozsahu QES programu. GAD – projekt pro zavedení centrálního Active Directory v rámci všech center patřících skupině QUIMPER včetně vybraných dodavatelů. OWL – projekt pro zavedení nástroje pro evidenci produktových školení a získaných dovedností (projekt realizovaný pouze v Praze a s dopadem pouze na PRA uţivatele).
30
QES Program OWL Projekt
GAD Projekt
FIM Projekt
GAD Projekt
DWH Projekt
TELCO Projekt
REC Projekt
OWL Projekt
Obrázek 5 - QES Program: vazby mezi projektem FIM a ostatními projekty (vlastní tvorba)
Jak je vidět ze schématu výše, projekt FIM má vazbu se všemi projekty v rámci programu QES. Produkty dvou projektů (GAD a OWL) jsou nezbytné pro naplnění cílů projektu FIM. Produkty projektu FIM umoţňují naplnění cílů 4 projektů (GAD, DWH, TELCO a REC). V brzké době (na podzim 2012) je plánovano produkovat vstupy i pro projekt OWL. 3.1.2.1 Geografický rozsah programu QES a souvisejících projektů Vzhledem k různým, převáţně technickým omezením, se geografická oblast působení projektů v rámci programu QES a s nimi souvisejících liší. Přehled projektů a jejich geografické oblasti působení je uveden níţe. Projekt
Oblast působení
TELCO
PAR, PRA, EBE, LEN, AMS.
DWH
Celosvětově.
REC
PAR, PRA, EBE, LEN, AMS.
OWL
PRA, v budoucnu je pravděpodobné rozšíření do dalších poboček.
GAD
Celosvětově.
FIM
Obecně celosvětový, některé prokukty projektu pouze pro užší oblast. Tabulka 1 - Geografický rozsah projektů programu QES
31
3.1.2.2 Potřeba nástroje pro řízení identit Všechny výše zmíněné projekty a nástroje, které jsou produkty těchto projektů potřebují k úspěšnému provozu data o uţivatelích. Na základě předchozích nepříliš dobrých zkušeností se samostatně udrţovanými databázemi uţivatelů pro kaţdý nástroj a následnými problémy provozování jednotlivých uţivatelských identit na úrovni reportingu vznikla potřeba pro centralizované a automatizované řešení pro nástroje v rámci QES programu, s moţným rozšířením rozsahu na další (primárně produkční) nástroje pouţívané ve skupině QUIMPER. Dalším důvodem pro vznik potřeby pro automatizované řízení uţivatelských identit je neustále rostoucí počet zaměstnanců v rámci skupiny QUIMPER. Pro ilustraci uvádím odhad počtu zaměstnanců a PC ve skupině QUIMPER pro druhé pololetí roku 2012. Pobočka Počet PC
Počet uživatelů
PAR
570
600
EBE
120
185
SAF
50
50
AMS
100
100
LEN
75
75
PRA
375
400
SYD
75
75
Celkem
1365
1485
Tabulka 2 - Přehled počtu zaměstnanců v jednotlivých pobočkách skupiny QUIMPER
3.1.2.3 Cíle řešení umožňující správu identit (FIM) Na základě vzniklé potřeby pro nalezení řešení pro správu identit byly formulovány následující cíle (na vysoké úrovni) budoucího nástroje pro správu identit: Centralizované řešení pro získávání z rozličných zdrojů, ukládání a distribuci uţivatelských dat s důrazem na přístupová práva a znalosti do různých aplikací (primárně pro aplikace v rozsahu QES programu) jak pro zaměstnance QUIMPER, tak pro externí dodavatele.
32
Umoţnit pobočkám, ze kterých není moţno získat uţivatelská data automatizovaně (např. nemají vlastní nástroje pro řízení lidských zdrojů atd.) zadat uţivatelská data přes uţivatelské rozhraní řešení a pracovat dále s těmito daty tak, jako by byly získány automaticky. Homogenizovat toky uţivatelských dat napříč celou skupinou pro všechna kontaktní centra (i ta, která jsou mimo rozsah TELCO projektu, např. SYD). Automatizovat ţivotní cyklus zaměstnance a sníţit náklady na manuální administraci s tím spojené. Dodat nástroj, který bude snadno spravovatelný interními administrátory bez potřeby předchozí hluboké znalosti (např. pro změnu konfigurace atd.). Jak uţ jsem zmínila výše, skupina QUIMPER se zabývá péčí o zákazníky a provozuje několik kontaktních center. Jak je pro toto odvětví obvyklé, i skupina QUIMPER se musí potýkat s vysokou fluktuací zaměstnanců. Vzhledem k neustálému růstu skupiny QUIMPER, vysoké fluktuaci zaměstnanců především na agentských pozicích a stále vyššímu počtu informačních systémů, je automatizace procesů týkajících se ţivotního cyklu zaměstnance nezbytná.
33
3.2 Aplikace metodiky PRINCE2 Tato kapitola pojednává o tom, jakým způsobem jsem aplikovala metodiku PRINCE2 pro řízení projektu FIM. Průběh projektu popisuji v chronologické posloupnosti rozdělené do jednotlivých etap ţivotního cyklu projektu (příprava projektu – „před projektem“, nastavení projektu, etapy dílčích dodávek projektu a závěrečná etapa projektu). Na konkrétních oblastech / situacích, pak popisuji jak byla metodika PRINCE2 pouţita v praxi. Pro lepší přehlednost je konkrétní princip, téma či proces znázorněn graficky.
3.2.1 „Project Lifecycle“ (Životní cyklus projektu) Ţivotní cyklus projektu se obecně dá rozdělit do následujících čtyř fází: Před projektem („Pre-project), Nastavení projektu („Project initiation“), Fáze dílčích dodávek projektu („Subsequent delivery stages), Fáze závěrečné dodávky projektu („Final delivery stage“). Návaznosti mezi jednotlivými fázemi jsou zachyceny na schématu níţe. PRINCE2 Pre-project
Initiation stage
Subsequent delivery stages Etapa I
.....
Final delivery stage
Etapa n
Obrázek 6 - Fáze životního cyklu projektu (vlastní tvorba)
Před projektem („Pre-project”) – během této fáze vzniká poţadavek na zahájení projektu. Produktem této fáze je projektový mandát (více, či méně formalizovaný), který je spouštěčem zahájení přípravy projektu v další fázi. Nastavení projektu („Initiation stage”) – během této fáze se definují nastavení projektu. Produktem této fáze je dokument o nastavení projektu, který dále slouţí jako základ pro řízení projektu, jelikoţ definuje základní parametry projektu. Fáze dílčích dodávek („Subsequent delivery stages”) – během této fáze vznikají (mezi)produkty projektu. Tato fáze můţe být pro usnadnění řízení rozdělena do
34
několika etap, kdy pro kaţdou etapu by měl být jasně definován očekávaný výstup (produkt) z dané etapy. Fáze konečného dodání („Final delivery stage”) – cílem této fáze je předání produktů projektu jejich konečnému uţivateli (zákazníkovi) do provozu a uzavření projektu včetně jeho vyhodnocení či alespoň naplánování revize naplnění očekávaných benefitů projektu.
35
3.2.2 „Pre-project“ (Před projektem) Pre-project
Subsequent delivery stages
Initiation stage
Etapa I
Etapa II
Final delivery stage
Etapa III
Dvě hlavní aktivity fáze „Pre-project“ jsou: Definice projektového mandátu (“Project mandate”), který stojí jako takový mimo metodiku PRINCE2 (z pohledu PRINCE2 slouţí jako zdroj informací pro vytvoření „Project Brief“). Proces Zahájení projektu („Starting up a project“) (PRINCE2) jehoţ hlavním cílem je jasně definovat rozsah projektu, ověřit ţe projekt za námahu opravdu stojí a ţe je projekt ţivotaschopný. 3.2.2.1 „Project mandate“ Cílem mandátu projektu je spustit projekt, ať uţ myšlenka nového projektu vznikla jakýmkoliv způsobem (nové obchodní cíle, odpověď na konkurenční tlaky, změny v legislativě, nález auditu atd.). Mandát projektu bývá většinou stručný dokument, definující pouze hlavní parametry projektu, které jsou dále rozpracovány po schválení projektu v rámci procesu „Starting up a project“. Projekt FIM byl spuštěn na základě projektového mandátu, který vznikl jiţ počátkem roku 2010. Tento mandát projektu se zabýval následujícími body: cíly projektu, rozsahem projektu (jak geografickým, tak aplikačním), rozhraními projektu, časovým omezením projektu, hlavními funkčními i nefunkčními poţadavky na řešení, budoucími uţivateli systému. Výše zmíněné body, kterými se zabýval projektový mandát, byly definovány do hlubšího detailu ve fázi nastavení projektu. Proto nejsou popsány zde, ale dále v kapitole zabývající se právě nastavením projektu. 36
Na základě tohoto projektového mandátu byl spuštěn projekt FIM, jenţ je objektem zájmu této diplomové práce. 3.2.2.2 „Starting up a Project“ PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
„Starting up a project“ je prvním z procesů, který řeší metodika PRINCE2 (jak z pohledu výkladu, tak z pohledu chronologického v ţivotním cyklu projektu). Výstupy procesu „Starting up a project“ by se daly shrnout následujícím způsobem: organizace projektu („Project Organization“) - autority projektu a osoby podílející se na řízení projektu, jasně definované obchodní opodstatnění („Business Justification“), rozsah projektu („Project Scope“) včetně akceptačních kritérií, způsob dosaţení cílů projektu („Project Approach“), plán etapy (“Stage plan”) pro etapu nastavení projektu (“Project initiation stage”). 3.2.2.2.1 „Project Organization“ (Organizace projektu) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Vzhledem k tomu, ţe projekt FIM je součástí programu QES, bylo rozhodnuto, ţe projekt bude podléhat také programovému výboru stejně jako ostatní projekty v rámci QES programu. Vzhledem k vytíţenosti jednotlivých členů výboru programu bylo také rozhodnuto, ţe pouze závaţná rozhodnutí (např. výběr dodavatele, schválení nákupu nad určitý limit, navýšení nákladů nad limit atd.) musí být schváleny přímo výborem programu, rozhodnutí menšího dopadu byla delegována na ředitelku QES programu a na řídící výbor projektu FIM.
37
Řídící výbor programu QES Sponzor programu QES
Hlavní uživatel programu QES
Hlavní dodavatel programu QES
Externí náklady
Ředitelka programu QES
Rozhodování na úrovní PROGRAMU
Rozhodování na úrovní PROJEKTU
Řídící výbor projektu FIM Hlavní uživatel projektu FIM
Hlavní dodavatel projektu FIM
Sponzor projektu FIM
Manažer projektu FIM
Obrázek 7 - Organizace projektu FIM a programu QES (vlastní tvorba)
Na počátku byl jako projektový manaţer projektu FIM jmenován MOS, jeden z projektových manaţerů IT v PAR. Jelikoţ se jednalo o skupinový projekt a na projektu se podíleli pouze zástupci francouzské pobočky, byla jsem ředitelkou QES programu koncem roku 2010 přizvána k projektu jakoţto zástupce zájmů české pobočky a také budoucí team leader pro dodávky produktů projektu realizované v PRA. 3.2.2.2.2 „Business Justification“ (Obchodní opodstatnění a rozsah projektu) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Cíle projektu, přínos projektu a navrhovaný způsob řešení projektu bohuţel nebyly původním sponzorem projektu ani projektovým manaţerem srozumitelně prezentovány a proto se zahájení projektu po dobu téměř jednoho roku odkládalo.
38
Během tohoto odkladu byl opětovně revidován jak rozsah projektu, tak jeho cíle a váhy jednotlivých cílů. Po mnoha diskusích se všemi zúčastněnými stranami jsme došli k závěru, ţe některé z dříve definovaných cílů spadají funkčně do jiných projektů a cíle dříve prezentované jako druhotné cíle projektu by se měly stát cíly primárními. Po korekci cílů projektu bylo rozhodnuto, ţe bude osloven externí specialista, aby vypracoval krátkou studii dosaţitelnosti na základě námi definovaných cílů projektu, jejímţ cílem bylo upřesnit obchodní opodstatnění projektu, zvolit vhodný přístup a vybrat technické řešení. Průběh a výstupy z této studie dosaţitelnosti jsou popsány v následující kapitole. Kromě upravených cílů projektu a obchodního opodstatění byl výstupem revize opodstatněnosti projektu také seznam poţadavků na budoucí řešení společně s akceptačními kritérii projektu, které jsou také popsány v následující kapitole. Po této úpravě cílů projektu a následné korekci obchodního opodstatnění projektu byl jiţ projekt přijat a zahájen. 3.2.2.2.3 „Feasibility study“ (Studie dosažitelnosti) Vzhledem k mnoţství nástrojů pro správu identit, dostupných na trhu a nedostatku zkušeností s automatizovanou správou identit, poţádalo vedení IT v PAR firmu zabývající se implementací těchto nástrojů o konzultaci, resp. krátkou analýzu prostředí skupiny QUIMPER a výběr vhodného nástroje. Výstupem této krátké analýzy byla studie proveditelnosti, porovnávající pět nástrojů pro správu identit, konkrétně: Microsoft – MS FIM 2010 (více na: http://www.microsoft.com/en-us/servercloud/forefront/identity-manager.aspx) Calendra / BMC - Calendra Enterprise Identity Management (více na: http://www.techieindex.com/techie/whitepapers/wp_details.jsp?id=78, http://www.bmc.com/news/press-releases/2005-archive/34366846-4425.html) IBM – Tivoli Identity Manager (více na: http://www01.ibm.com/software/tivoli/products/identity-mgr/) Oracle – Oracle Identity Management (více na: http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.html) 39
Novell – Novell Identity Manager (více na: http://www.novell.cz/cs/produkty/novell-identity-manager/) Řešení od společností IBM, Oracle a Novell byla vyhodnocena jako nevyhovující pro potřeby skupiny QUIMPER (příliš drahé nebo určené pro správu mnohem většího počtu uţivatelů příp. nesplňovaly některé z hlavních poţadavků na funkčnost definované zástupci skupiny QUIMPER). Jako vyhovující byla vyhodnocena řešení od společnosti Microsoft (MS FIM 2010) a řešení od společnosti Calendra (dnes součástí BMC). Níţe uvádím hlavní charakteristiky těchto dvou nástrojů, které pak byly pouţity jako vodítko pro finální rozhodnutí, který nástroj bude ve skupině QUIMPER pouţíván. Calendra Enterprise Identity Management Řešení známé pro zaměstnance PAR (jeden z modulů je jiţ vyuţíván místním HR oddělením). Uţivatelské rozhraní je jednoduše upravitelné. Propojení s Active Directory, databázemi atd. by vyţadovalo vývoj. Řešení je postaveno na Javě, která se ve skupině QUIMPER netěší velké oblibě. Nejasná mapa dalšího vývoje produktu z důvodu akvizice společnosti integrátorem, který se sám vývojem nezabývá, poslední nová verze vyšla před třemi lety, další verze se očekává v polovině roku 2012, ale její obsah není znám a očekávání jsou spíše pesimistická. MS Forefront Identity Manager 2010 Řešení postavené na technologiích Microsoftu, která jsou ve skupině QUIMPER hojně pouţívané. V případě potřeby dalšího rozvoje nástroje v budoucnosti by bylo moţné vyuţít interní vývojový tým. Propojení s Active directory nebo databázemi je standardizované a součástí řešení – není třeba ţádný výjoj, stačí konfigurace existujících konektorů. Synchronizace dat v obou směrech, moţnost asynchronní synchronizace. Tvorba uţivatelského rozhraní je komplikovanější neţ pro Calendru. 40
Na základě výstupů studie proveditelnosti interní IT experti učinili následující doporučení týkající se nasazení řešení pro řízení uţivatelských identit v prostředí skupiny QUIMPER: Nástroj: MS FIM 2010 (MS technologie postavená na technologii Sharepoint, podpora výrobcem, lepší cenové podmínky, standardizované konektory). Implementace: Externí dodavatel z důvodu nedostatku interních lidských zdrojů (způsobeno náročností souběţně běţících projektů především v rámci QES programu). Výběrové řízení: Přizvat dodavatele jak francouzské, tak české, z důvodu rozdílů v cenách za práci (větší konkurence mezi dodavateli). Součásti poptávky by měla být implementace (povinná část) a nákup licencí (dobrovolná část, pouze pokud by dodavatel nabídl lepší podmínky, neţ by QUIMPER získal při přímém nákupu licencí). Hostování řešení: Řešení by mělo být hostováno ve stejné zemi, z jaké bude vybraný dodavatel (jednodušší komunikace a zvýšení flexibility). Řízení projektu implementace: Projekt by měl být také řízen lokálně, tzn. projektový manaţer by měl být ze stejné země jako vybraný dodavatel z důvodu usnadnění komunikace a následné vyšší flexibility. Rozsah projektu: Projekt by měl mít geografický rozsah a splňovat funkční a nefunkční poţadavky definované níţe (přehled uvádí i v jakém pořadí by poţadavky měly být splněny): ID
Typ
Požadavek
Fáze
F_1
Funkční
Řešení musí umět získat data o uživatelích z různých
1, 2
zdrojů. F_2
Funkční
Řešení musí umět transformovat, generovat a
1, 2
ukládat získaná data v požadovaném formátu. F_3
Funkční
Řešení musí umožnit export dat ve formátu .csv.
1, 2
F_4
Funkční
Řešení
s Active
3
Řešení musí umožnit automatizaci životního cyklu
4
musí
umožnit
synchronizaci
Directory. F_5
Funkční
zaměstnance.
41
F_6
Funkční
Řešení musí umožnit vkládání uživatelských dat
3
včetně zakládání nových uživatelů přes grafické rozhraní. F_7
Funkční
Řešení musí umožnit správu uživatelů nástroje a
3
jejich přístupových práv. F_8
Funkční
Řešení musí umožnit základní administraci účtu
3
přímo koncovým uživatelem (editace základních údajů o zaměstnanci, změna hesla atd.). F_9
Funkční
Řešení
musí
umožnit
konfiguraci
základních
4
číselníků nutných pro generování či transformaci dat nutných pro tvorbu exportních souborů. F_10
Funkční
Řešení musí umožnit evidenci změn v nastavení
4
systému i jednotlivých zaměstnanců (konfiguračních položek). NF_1
Nefunkční
Řešení musí obsahovat 2 plně oddělená prostředí –
1
jedno produkční a jedno pro vývoj a testování. NF_2
Nefunkční
Součástí dodání řešení musí být zdrojový kód a
4
popis veškeré konfigurace. NF_3
Nefunkční
Součástí dodání řešení musí být kompletní technická
4
a funkční dokumentace. NF_4
Nefunkční
Uživatelské
rozhraní
musí
být
dvojjazyčné
–
4
Řešení musí umožňovat automatické zálohování a
4
Angličtina a Francouzština. NF_5
Nefunkční
obnovení řešení včetně kompletní dokumentace. D_1
Funkční / data
Řešení
musí
umět
pracovat
s osobními
daty
N/A
Řešení musí umět pracovat s jazykovými znalostmi a
N/A
zaměstnanců. D_2
Funkční / data
jejich úrovní. D_3
Funkční / data
Řešení musí umět pracovat s business znalostmi a
N/A
jejich úrovní. D_4
Funkční / data
Řešení musí umět pracovat s informacemi a prací naplánovanou
pro
jednotlivé
stávající a pro příští den.
42
zaměstnance
za
N/A
D_5
Funkční / data
Řešení musí umožňovat správu přístupových práv
N/A
zaměstnanců v různých systémech. D_6
Funkční / data
Řešení
musí
umožňovat
správu
organizační
N/A
Řešení musí umožňovat správu identit zaměstnanců
N/A
hierarchie napříč celou skupinou. D_7
Funkční / data
do různých systémů. TR_1
Technický
Dodavatel musí nabídnout optimální technickou
N/A
architekturu berouc v potaz velikost QUIMPERu a strukturu Active Directory napříč celou skupinou. TR_2
Technický
Navrhnutá technická architektura musí respektovat
N/A
cílovou architekturu pro Active Directory napříč skupinou (kořenový Active Directory hostovaný v Paříži a 5 subdomén hostovaných lokálně). Tabulka 3 - Přehled požadavků pro FIM řešení
Tyto poţadavky byly základem pro následně vypracovanou poptávku a jsou kostrou celého zadání. 3.2.2.2.4 „Project approach“ (Způsob dosažení cílů) Na základě doporučení plynoucích z výše popsané analýzy bylo rozhodnuto, ţe: Projekt bude realizován ve spolupráci s externím dodavatelem formou dodání díla. Vzhledem k tomu, ţe se jedná o skupinový projekt a také vzhledem k rozdílům cen na českém a francouzském trhu, budou poptáni jak francouzští, tak čeští dodavatelé. Projekt bude dále řízen projektovým manaţerem ze země, kde sídlí budoucí dodavatel projektu (tzn. pokud by byl vybrán francouzský dodavatel, projekt bude nadále řízen původním projektovým manaţerem, pokud by byl vybrán český dodavatel, projekt by byl řízen českým projektovým manaţerem, tedy mnou). Jako technické řešení bude na základě doporučení poskutných jak interními, tak externími experty pouţit MS Forefront Identity Manager 2010.
43
3.2.2.2.5 „Lessons log“ (Přehled získaných poznatků) PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
Součástí procesu „starting up a project“ by mělo být i vytvoření Přehledu získaných poznatků („Lessons log“) avšak tento dokument byl vytvořen aţ v pozdější fázi projektu, nejvýznamnější
poznatky
(„Lessons“)
jsou
vyhodnocením projektu.
44
uvedeny
v kapitole
zabývající
se
3.2.3 „Project initiation stage“ (Etapa nastavení projektu) Pre-project
Subsequent delivery stages
Initiation stage
Etapa I
Etapa II
Final delivery stage
Etapa III
Druhá fáze ţivotního cyklu projektu je Etapa nastavení projektu („Project initiation stage“). V rámci této fáze probíhají dva PRINCE2 procesy: Proces Nastavení projektu (“Initiating a project”) – který jasně definuje aktivity pro úspěšné nastavení projektu. Proces Řízení přechodu etap (“Managing a stage boundary”) – který se zabývá aktivitami, které musí být vykonány neţ můţe být zahájena další etapa projektu. Cílem této fáze ţivotního cyklu projektu je projekt detailně naplánovat, získat finanční prostředky pro realizaci projektu a nastavit kontroly, které zajistí, ţe projekt přinese očekávané výsledky v naplánovaném čase a za schválené finanční prostředky. Součástí této etapy je také vypracování detailního obchodního opodstatnění. Všechny výstupy této etapy by pak měly být shrnuty do Dokumentu o nastavení projektu („Project initiation document“), který by měl v rámci procesu Řízení přechodu etap slouţit jako podklad pro schválení či zamítnutí spuštění projektu. 3.2.3.1 „Project Initiation Document“ (Dokument o nastavení projektu) Cílem této kapitoly je seznámit čtenáře s obsahem Dokumentu o nastavení projektu („Project Initiation Document“, dále referencován jako PID), jelikoţ tento dokument definuje projekt, kterým se ve své diplomové práci zabývám. Cílem PID, který vznikl jako výstup z fáze Nastavení projektu bylo jasně definovat parametry projektu a také zajistit jejich pochopení všemi účastníky projektu. Konkrétně se PID zabýval definicí cílů a přínosů projektu, rozsahem (jak geografickým, tak aplikačním), plánem dodávek projektu, řízením rizik, kvality a změn, způsobem monitorování a kontrolování stavu projektu a také komunikační strategií. V době, kdy tento PID vznikal, jsem projekt FIM ještě nevedla, ale na přípravě tohoto dokumentu jsem se značně podílela z pověření ředitelky programu QES (jako záruka pro naplnění přeformulovaných cílů projektu).
45
3.2.3.1.1 „Project Goals and Benefits“ (Cíle a přínosy projektu) Jako hlavní cíl projektu byla definována automatizace ţivotního cyklu zaměstnance napříč téměř celou skupinou QUIMPER a sjednocení procesů a homogenizace dat spojených se správou uţivatelských identit (především pro aplikace spadající pod QES program). Konkrétně bylo automatizací ţivotního cyklu zaměstnance myšleno: Automatické zakládání účtů (identit) zaměstnance v různých aplikacích na základě zaloţení nového zaměstnance v lokálním personálním systému. Automatická změna přístupových práv zaměstnance v různých aplikacích na základě změny pracovní náplně (vyvolaná změnou pozice, organizační jednotky či role (rolí) přiřazených zaměstnanci v personálním systému). Automatická deaktivace a následné smazání identit zaměstnance po jeho odchodu ze společnosti zaznamenané v lokálním personálním systému. Jako další cíl projektu bylo definováno umoţnění správy zaměstnanců přes grafické rozhraní pobočkám společnosti QUIMPER, které nevyuţívají ţádný personální systém, ze kterého by data mohly být čerpány a tím umoţnit částečnou automatizaci ţivotního cyklu zaměstnance z pohledu správy identit na základě uţivatelských vstupů přes grafické rozhraní. Očekávané přínosy projektu byly definovány následujícím způsobem: Sníţení nákladů na správu uţivatelských identit, které byly dosud v mnohých aplikacích zakládány ručně. Sníţení chybovosti při zakládání a správě uţivatelských identit a následné sníţení nákladů na odstranění těchto chyb. Sjednocení procesů a homogenizace dat spojených se správou uţivatelských identit umoţňující
zavedení
společných
bezpečnostních
QUIMPER a tím vedoucí ke zvýšení bezpečnosti.
46
politik
napříč
skupinou
3.2.3.1.2 „Project Scope“ (Vymezení rozsahu projektu) Do geografického rozsahu projektu byly zahrnuty následující pobočky skupiny QUIMPER: PRA, PAR, SYD, EBE, LEN, AMS. Jelikoţ se aplikační rozsah projektu lišil pro mnoho poboček, uvádím v tabulce níţe přehled čerpání vstupních dat a jejich distribuci do dalších aplikací pro kaţdou pobočku zvlášť. Pobočka
Vstupní data z
Výstupní data do
PRA
Lokální personální systém, OWL
TELCO (CME, Odigo, Gedeon), DWH, REC, GAD, do budoucna OWL
PAR
Lokální personální systém
TELCO (CME, Odigo, Gedeon), DWH, REC, GAD
SYD
Ručně vytvořený datový soubor nebo
grafické
rozhraní
DWH, GAD
řešení
projektu. SYD
Ručně vytvořený datový soubor
TELCO (CME, Odigo, Gedeon), DWH,
nebo
REC, GAD
grafické
rozhraní
řešení
projektu. LEN
Ručně vytvořený datový soubor
TELCO (CME, Odigo, Gedeon), DWH,
nebo
REC, GAD
grafické
rozhraní
řešení
projektu. AMS
Ručně vytvořený datový soubor
TELCO (CME, Odigo, Gedeon), DWH,
nebo
REC, GAD
grafické
rozhraní
řešení
projektu. Tabulka 4 - Rozsah projektu FIM pro jednotlivé pobočky
Aplikační rozsah byl také definován seznamem funkcionalit, který byl jiţ uveden dříve. Pobočky a aplikace, které nejsou zmíněny v seznamu výše, nespadají do rozsahu projektu. V dokumentu o nastavení projektu byla také definována následující moţná budoucí rozšíření rozsahu projektu: Nová kontaktní centra příp. stávající kontaktní centra spolupracující se skupinou QUIMPER, ale v současné době vyuţívající pouze vlastní aplikace.
47
Automatizovaná správa uţivatelských identit v dalších systémech vyuţívaných především v PRA, PAR a SYD. 3.2.3.1.3 „Deliveries plan“ (Plán dodávek projektu) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Plánování dodávek projektu FIM muselo odpovídat plánování jednotlivých kroků (milníků) projektu TELCO v rámci QES programu. Původně stanovené milníky projektu TELCO důleţité pro projekt FIM jsou vyznačeny na obrázku níţe.
Feb Spuštění pilotního provozu pro Telco řešení (podmínka: datové soubory o uživatelích)
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
Jun Spuštění velkých produktů (podmínka: plná automatizace životního cyklu zaměstnanců)
May
Jun
01-Jun-11 Nov Zahájení testování Telco platformy
Apr Generalizace pro Telco platformu
Jul
Aug
31-Aug-12 Aug Ukončení fáze Generalizace pro Telco platformu
Obrázek 8 - Milníky programu QES (vlastní tvorba)
Na základě výše uvedených milníků byly společně s ředitelkou programu QES a sponzorem projektu FIM definovány milníky pro projekt FIM. Tyto milníky jsou vyznačeny v časové ose na obrázku níţe. 01-Oct-11 Zahájení spolupráce s dodavatelem 01-Sep-11 Výběr dodavatelů pro další vyjednávání 12-Jul-11 Zahájení výběrového řízení
01-Jul-11
01-Jun-11
01-Aug-11
01-Sep-11
01-Oct-11
01-Nov-11
01-Dec-11
01-Jan-12
01-Feb-12 01-Mar-12
01-Apr-12
30-Apr-12 20-Apr-12 Nejzašší termín pro dodání celého řešení
18-Aug-11 Poslední možný den pro zaslání nabídky 20-Jan-12 Nejzašší termín pro dodání datových souborů (musí být připraveno pro pilot Telca)
15-Sep-11 Výběr dodavatele a uzavření výběrového řízeni
Obrázek 9 - Milníky projektu FIM (vlastní tvorba)
48
Na základě milníků pro projekt FIM byl později vytvořen harmonogram projektu. Subdodávky řešení byly rozděleny do čtyř fázi, které jsou popsány níţe. Toto rozdělení do fází umoţnilo průběţné testování dílčích dodávek. Fáze
Termín
Obsah dodávky za danou fázi
1
20/10/2011
Datové soubory s uživatelskými daty pro aplikace CME, Odigo, Gedeon.
2
20/11/2011
Datové soubory s uživatelskými daty pro aplikace REC a DWH.
3
20/1/2012
Zakládání uživatelů přes grafické rozhraní aplikace. Propojení s Active Directory (jako příprava pro fázi 4).
4
20/4/2012
Plná automatizace životního cyklu zaměstnance (především zakládání,
deaktivace
účtů
v Active
Directory)
a
ostatní
funkcionality. Tabulka 5 - Fáze dodávek pro řešení projektu FIM dodaného externím dodavatelem
Co se týká celkového detailního plánu (harmonogramu projektu), ten ještě nemohl být v této fázi vytvořen, jelikoţ dosud nebyl vybrán dodavatel a nebyla známa přesná forma spolupráce s dodavatelem. PID proto obsahoval pouze projektový harmonogram na vysoké úrovni (viz. milníky výše) a do detailu byla vypracován plán pouze pro první etapu dodávek projektu. Dále byl na základě studie dosaţitelnosti provedené v předchozí fázi projektu určen rozpočet projektu. Jelikoţ se jedná o citlivou informaci, konkrétní částku v této práci neuvádím. 3.2.3.1.4 „Project products breakdown“ (Rozpad produktů projektu) PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
V PID jsme definovali s MOSem i jednotlivé produkty pro kaţdou z fází projektu. S postupem času byly některé produkty ještě doplněny. Obrázek níţe poskytuje ukázku produktů identifikovaných pro projekt FIM.
49
Obrázek 10 - Ukázka "Project products breakdown structure" (vlastní tvorba)
Tabulka níţe uvádí příklad definice jednoho konkrétního produktu projektu FIM a to Datového souboru pro CME. Identification
DS_1
Title
Datový soubor pro CME Datový soubor s uživatelskými daty umožňující automatizovanou
Purpose
správu uživatelských identit v cílových systémech spadajících pod CME (AD, CCP, CCM, OCM).
Derivation Format
Funkční specifikace. and
presentation Development
skills
required
.csv soubor ukládaný jednou denně na dedikované FTP.
N/A (záležitost dodavatele)
Quality
MOS – testování .csv souborů na základě odpovídajícího
responsibilities
testovacího scénáře
Quality expectations
100 % - kritické pro byznys.
Acceptance criterions
1/ datový soubor je správně integrován do cílové aplikace
50
& Quality tolerance
2/ v případě, že cílové FTP není dostupné, datový soubor je uložen na náhradní uložiště 3/ datový soubor obsahuje správná data Testování .csv souborů: 1/ testování na základě sepsané specifikace
Acceptance method
2/ integrační test (datový soubor je zpracován cílovou aplikací a výsledky integrace odpovídají očekáváním) Acceptance
PM na základě dvojího (2 na sobě nezávislí testeři) testování
responsibilities
Tabulka 6 - Ukázka definice produktu projektu
3.2.3.1.5 „Project Organization“ (Organizace projektu) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
V rámci přípravy nastavení projektu byla navrhnuta následující struktura řídícího výboru projektu („Project Board“). Řídící výbor projektu FIM Senior User (SLA)
Executive (DPE)
Senior Supplier (Dodavatel)
Project Manager (MOS / DCA)
Obrázek 11 - Organizace projektu (řídící výbor a projektový manažer) (vlastní tvorba)
Sponzor projektu („Executive“) byl určen jiţ během předchozí fáze projektu. Do role Hlavního uţivatele („Senior User“) byl nominován SLA (IT Manager skupiny QUIMPER). Do role Hlavního dodavatele („Senior Supplier“) byl navrhnut zástupce dodavatele. V případě, ţe by projekt byl realizován s českým dodavatelem, převzala bych roli projektového manaţera já a MOS by se projektu účastnil jako vedoucí týmu dodávek za PAR. 51
PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
V rámci definice organizace projektu byly stanoveny i limity pro eskalaci k vyššímu řídícímu orgánu. Náklady o Interní náklady – navýšení o více jak 10 MDs interních zdrojů pro etapu projektu. o Externí náklady – jakékoliv navýšení nákladů na dodavatele muselo být eskalováno ke sponzorovi projektu. Finální schválení zvýšení externích nákladů muselo být autorizováno řídícím výborem programu QES. Čas o Zpoţdění neohroţující úspěšné spuštění provozu TELCO platformy – eskalace pokud by bylo moţné zpoţdění delší neţ 2 týdny. o Zpoţdění ohroţující úspěšné spuštění provozu TELCO platformy – zpoţdění jakékoliv délky (v závislosti na dříve nabraných zpoţděních, změnách v plánování pro TELCO platformu). Rozsah – jelikoţ změny rozsahu mívají obvykle dopad na náklady a čas, byly pro změny rozsahu nastaveny stejné limity pro eskalaci jako pro náklady a čas. Vzhledem k velmi napjatému plánování bylo určeno, ţe limity budou eskalovány ke sponzorovi projektu okamţitě při identifikaci rizika jejich překročení, aby situace mohla být co nejrychleji vyřešena. V případě potřeby hlubší diskuse a/či analýzy problému bude svolána schůzka řídícího výboru projektu, kde bude problém prodiskutován a bude rozhodnuto o řešení problému. Rozhodnutí, zda je potřeba svolat schůzku řídícího projektu výboru, je na sponzorovi projektu na základě doporučení projektového manaţera. Jelikoţ pro celý program QES bylo určeno, ţe náklady na externí zdroje musí být také schváleny řídícím výborem programu, bylo nastaveno dvouúrovňové schvalování. Na základě doporučení projektového manaţera by měl rozhodnout řídící výbor projektu o dalších krocích. Rozhodnutí řídícího výboru projektu pak následně ještě musí být schváleno řídícím výborem programu QES. 52
3.2.3.1.6 „Quality Management“ (Řízení kvalit) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Základním vstupem pro řízení kvality byl určen seznam akceptačních kritérií, který byl definován dříve. Na základě těchto akceptačních kritérií a plánování dodávek produktů projektu byl vytvořen seznam produktů projektu a následně popis jednotlivých produktů, včetně jejich kvalitativních kritérií. Ověření dosaţení kvality jednotlivých produktů bude dosaţeno následujícím způsobem: Dodávky ze strany QUIMPER – dvojí kontrola výstupů jak členem projektového řídícího týmu, tak někým mimo řídící projektový tým (např. ověření srozumitelnosti specifikace pro dodavatele analytikem, který se sám na dodávce nepodílí). Dodávky ze strany dodavatele – dvojí testování výstupů na základě testovacích scénářů, které byly vytvořeny na základě specifikace dodané týmem QUIMPER dodavateli. Plánování kvality (verifikace specifikací, testování) bude zahrnuto do tvorby detailního harmonogramu projektu. Případné problémy s kvalitou dodávek budou registrovány v seznamu otevřených bodů. Výsledky jednotlivých testů budou zaznamenány v testovacích scénářích, které budou přiloţeny k seznamu otevřených bodů. Výsledek finální akceptace dodávky od dodavatele bude zaznamenán v akceptačním protokolu. Po předání řešení dodavatelem společnosti QUIMPER můţe být řešení akceptováno, akceptováno s výhradou nebo neakceptováno. Pro akceptování řešení musí být splněna všechna akceptační kritéria bez výhrad. Pro akceptování řešení s výhradou musí být všechny akceptační kritéria akceptovány alespoň s výhradou a musí být dodrţeny následující podmínky: Výhrada k ţádnému akceptačnímu kritéria nemá závaţnost klasifikovanou úrovní A.
53
Maximálně jedno akceptační kritérium má klasifikovanou závaţnost výhrady úrovní B. Maximálně dvě akceptační kritéria mají klasifikovanou závaţnost výhrad úrovní C. Řešení můţe být akceptováno s výhradou pouze pokud se dodavatel zaváţe (v termínu vyhovujícímu společnosti QUIMPER) k odstranění závad. Závaţnost výhrad byla definována následujícím způsobem: úroveň A – velmi závaţný defekt, zabraňující provozu řešení úroveň B – závaţný defekt, ale existuje způsob, jak problém obejít úroveň C – defekt nemající vliv na provoz řešení. 3.2.3.1.7 „Risks Management“ (Řízení rizik) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Jako největší rizika projektu byly hned na počátku vyhodnoceny následující: Čas – výstupy projektu FIM jsou nutné pro úspěšný provoz nové TELCO platformy. Nedostatek interních zdrojů. Moţné změny v zadání, jelikoţ specifikace pro dodání řešení výstupů se odvíjí od specifikace dodavatele řešení pro novou TELCO platformu, a které se mohou v průběhu času změnit, jelikoţ řešení ještě nebylo vyvinuto a otestováno. Pro řízení rizik bude zaloţen registr rizik, do kterého budou průběţně rizika zaznamenávána. Registr rizik je detailně popsán v kapitole Registr rizik.
54
3.2.3.1.8 „Change Management“ (Řízení změn) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Pro podporu řízení změn v projektu byl definován následující proces: na základě rozpoznání poţadavku pro změnu ţadatel změny vyplní formulář ţádosti o změnu (důvod změny, poţadovaná změna, dopad pokud se změna neprovede, příp. provede později neţ je ţádáno). Na základě informací poskytnutých ţadatelem bude změna posouzena (dopad na pracnost, plánování, cenu) projektovým manaţerem a případně řídícím výborem projektu (pokud by byly přesaţeny limity pro eskalaci stanovené výše). Pokud má změna dopad na dodávku od externího dodavatele řešení, bude poţadavek na změnu posuzován společně se zástupcem dodavatele. Všechny poţadavky na změnu musí být také zaregistrovány v seznamu otevřených bodů. Pro menší poţadavky na změnu, především ty, které nemají vliv na dodávku externího dodavatele (nebo je jejich vliv minimální), je moţné poţadavek na změnu pouze zaregistrovat a popsat v seznamu otevřených bodů (z důvodu sníţení adminstrativní zátěţe a vyšší flexibility). Tento proces byl detailněji specifikován během implementační fáze. Více informací o řízení změn je k nalezení v kapitole Změna (Change). 3.2.3.1.9 „Issues Register“ (Řízení otevřených bodů) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Všechny rozpoznané otevřené body musí být zaznamenány v registru otevřených bodů a pravidelně revidovány. Struktura a obsah registru otevřených bodů je detailně popsán v kapitole Registr otevřených bodů (Issue Register).
55
3.2.3.1.10 „Monitoring and Controlling“ (Monitorování a kontrola průběhu projektu) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Průběh projektu bude kontrolován na pravidelných týdenních schůzkách projektového řídícího týmu. Obsahem těchto schůzek bude revize toho, co se udělalo během minulého týdne, validace detailního plánu pro týdny nadcházející a revize harmonogramu, otevřených bodů a rizik. Záznam ze schůzky a aktualizované artefakty pro řízení projektu, budou po schůzce poslány také řídícímu výboru projektu. Týdenní schůzky řídícího týmu v praxi jsou detailně popsány v kapitole Týdenní schůzka řídícího týmu projektu. Průběh projektu bude kontrolován také řídícím výborem projektu na schůzích řídícího výboru projektu, který by se měly konat jednou za měsíc. Jednou měsíčně bude také vypracován report stavu projektu pro účely kontroly stavu projektu řídícím výborem programu QES. 3.2.3.1.11 „Communication Strategy“ (Komunikační strategie) Komunikační strategie pro širší publikum není v dokumentu nastavení projektu řešena, jelikoţ je řešena na úrovni programu QES. Komunikační strategie pro interní účely projektu byla nastavena následujícím způsobem: veškerá komunikace a dokumentace musí být v anglickém jazyce. S dodavatelem komunikuje primárně projektový manaţer. Pokud některý člen týmu potřebuje kontaktovat dodavatele přímo, projektový manaţer musí být v kopii e-mailové komunikace. Pokud se komunikace odehrávala telefonicky či osobně, projektový manaţer musí být o průběhu či rozhodnutích informován.
56
3.2.3.2 „Manage stage boundary“ (Řízení přechodu do další etapy) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Manage product delivery
Controlling a stage
Closing project
Poté co jsme zkompletovali Dokument o nastavení projektu a ten byl schválen řídícím výborem projektu byl také vypracován harmonogram první dodávkové etapy projektu. 3.2.3.2.1 Detailní harmonogram první etapy projektu Cílem první dodávkové etapy projektu bylo vybrat externího dodavatele pro implementaci řešení pro správu uţivatelských identit (konkrétně MS FIM 2010) a také připravit detailní specifikaci poţadavků pro první dodávku od budoucího dodavatele. Milníky výběrového řízení byly stanoveny následujícím způsobem: 21-Jul-11 Výběr dodavatelů, kteří budou osloveni
15-Aug-11 08-Sep-11 Nejzašší termín pro zaslání otázek Oznámení výsledku výběrového řízení
12-Jul-11 1. verze podkladů pro výběrové řízení
19-Aug-11 Nejzašší termín pro zaslání nabídek
01-Aug-11
01-Sep-11
01-Jul-11
30-Sep-11 28-Jul-11 Rozeslání poptávek vybraným dodavatelům
16-Sep-11 Uzavření smlouvy o dílo s dodavatelem 31-Aug-11 Vyhodnocení nabídek a výběr 2 dodavatelů pro další vyjednávání
Obrázek 12 - Milníky výběrového řízení (vlastní tvorba)
Od těchto milníků se následně odvíjel harmonogram pro etapu I. následující fáze projektu. Jedním z cílových produktů etapy I. byla i specifikace pro datové soubory CME, Odigo a Gedeon a taktéţ vytvoření specifikace pro datové pohledy s uţivatelskými daty, které budou slouţit jako zdroj dat pro MS FIM 2010 pro PAR a PRA. Poté, co jsme harmonogram vypracovali, postoupili jsme jej k připomínkování řídícímu výboru projektu. Harmonogram byl následně po menších úpravách (převáţně v rozloţení potřebných kapacit z důvodu plánovaných dovolených) schválen a bylo autorizováno zahájení další fáze projektu.
57
3.2.4 „Subsequent delivery stages“ (Dílčí dodávkové etapy) Pre-project
Initiation stage
Final delivery stage
Subsequent delivery stages Etapa I
Etapa II
Etapa III
Etapa IV
V této kapitole se věnuji jednotlivým etapám (I. – IV.) dodávek v rámci fáze „Subsequent delivery stages“. Na začátku projektu byly definovány pouze fáze I. – III., ale po rozšíření rozsahu projektu byla na základě domluvy s Dodavatelem definována také etapa IV. jejíţ náplní bude dodat funkcionality, které jsou mimo původní rozsah řešení. 3.2.4.1 Etapa I. Pre-project
Initiation stage
Final delivery stage
Subsequent delivery stages Etapa I
Etapa II
Etapa III
Etapa IV
Cílem Etapy I. bylo uskutečnění výběrového řízení na externího dodavatele řešení a také sepsání specifikace poţadavků pro dodávku, která by měla být realizována během II. etapy projektu. První část Etapy I probíhala dle plánu. Několikrát došlo ke zdrţení v rozsahu 2-3 dnů, které byly následně dohnáno, takţe nemělo negativní vliv na průběh projektu. Tato zdrţení byla způsobena především průtahy ve schvalování podkladů pro výběrové řízení. Ve druhé části Etapy I jiţ došlo k výraznému zpoţdění dvou týdnů a to konkrétně při přípravě detailních specifikací a podpisu kontraktu s vybraným dodavatelem. Jelikoţ byl nakonec pro dodání řešení projektu vybrán český dodavatel a mezi českými a francouzskými obchodními zvyklostmi jsou jisté odlišnosti, kvůli nejasnostem / nepochopením došlo k průtahům v přípravě kontraktu a jeho podpisu. Kvůli časové náročnosti přípravy kontraktu nabrala zpoţdění také příprava specifikací (na obou úkolech pracovali stejní lidé). Vzhledem k napjatému časovému harmonogramu a překročení stanoveného limitu bylo toto zpoţdění eskalováno ke sponzorovi projektu a ředitelce programu QES a po dohodě s vybraným dodavatelem byla přijmuta následující opatření vedoucí k minimalizaci dopadu vzniklého zpoţdění: Dopad zpoţdění v uzavření smlouvy byl minimalizován rozhodnutím o zahájení spolupráce (na základě předchozích oboustranných dobrých zkušeností z jiných projektů realizovaných s vybraným dodavatelem) ještě před podepsáním kontraktu. 58
Dopad zpoţdění v dodání detailních specifikací byl minimalizován drobnou korekcí v projektovém harmonogramu připraveném dodavatelem (změna pořadí úkolů, místo přípravy schéma datových toků byla práce zahájena instalací serverů, které jiţ byly připraveny podle poţadavků specifikovaných dodavatelem v nabídce dodavatele). Jak uţ jsem výše zmínila, pro dodání řešení byl vybrán český dodavatel, proto jsem roli projektového manaţera převzala já a MOS zaštítil roli manaţera týmu pro dodání specifikací a testování a ostatní PAR dodávky. Na hlavního dodavatele projektu („Senior Supplier“) byl nominován zástupce dodavatele (ředitel divize společnosti dodavatele, pod kterou projekt spadal). Řídící výbor projektu IDM Senior User (SLA)
Executive (DPE)
Senior Supplier (MCH)
Project Manager (DCA)
Project Support (HGA)
Manažer týmu pro technickou podporu (HKO)
Manažer týmu pro specifikace a testování (MOS)
Manažer týmu dodavatele (ZAT)
Obrázek 13 - Organizační struktura projektu (vlastní tvorba)
Během Etapy I byl ve spolupráci s dodavatelem vypracován detailní harmonogram dodávek projektu (ještě před uzavřením kontraktu) a byly doladěny detaily týkající se artefaktů potřebných pro řízení projektu (pravidelné týdenní schůzky, způsob komunikace, detailní organizační struktury projektu). Detailní harmonogram dodávek realizovaných dodavatelem vycházel z rozdělení projektu do 4 fází, avšak dodávky 1+2 byly sloučeny do jedné etapy (etapa II) projektu a dodávky 3+4 byly sloučeny do další etapy (etapa III) projektu.
59
Přehled níţe uvádí mnoţství zdrojů plánovaných pro etapu II a III projektu. Detailní harmonogram je uveden v Příloze 1.
Zdroje potřebné pro etapu II a III Zdroj
Aktivita
Celkem
D
design dokumentace Instalace projektový management školení vývoj
D Celkem Q
9 6 4 12 7 48 86
Instalace projektový management školení specifikace testing vývoj
Q Celkem
3 25 11 22 15 5 81
MDs Celkem 167 Tabulka 7 - Přehled zdrojů potřebných pro etapu II a II
60
Na základě harmonogramu dodávek dodavatele jsme společně s vedoucím týmu dodavatele vypracovali projektový harmonogram pro etapu II a III (především časování dodávek detailních specifikací ze strany QUIMPER a testování dílčích dodávek řešení). Etapa II
Etapa III
Specifikace požadavků pro fázi 2
Specifikace požadavků pro fázi 4
Realizace požadavků pro fázi 1
Realizace požadavků pro fázi 3 Realizace požadavků pro fázi 2
Testování dodávky fáze 2
Realizace požadavků pro fázi 4 Testování dodávky fáze 3
Testování dodávky fáze 1 Specifikace požadavků pro fázi 3
Testování dodávky fáze 4
Obrázek 14 - Přístup k realizaci projektu (návaznosti aktivit mezi QUIMPER a dodavatelem (vlastní tvorba)
Výše uvedený harmonogram dodávek pro další fáze byl součástí následně uzavřeného kontraktu. THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Součástí kontraktu byl i seznam akceptačních kritérií a jejich vazba na původní poţadavky a jednotlivé fáze dodávek (1-4). Ukázka akceptačních kritérií je uvedena v tabulce níţe. Milník
1
1
AK #
AC_1.1
AC_1.2
Req #
Popis akceptačního kritéria
F_1
FIM získává uživatelská data z různých zdrojů - PRA, PAR, EBE, SYD, LEN, AMS, SAF - zdrojem dat je buď datový pohled nebo datový soubor získaný z dedikovaného FTP
F_2
Data jsou transformována, generována a ukládána v požadovaném formátu: - uživatelská osobní data - znalosti uživatelů (jak jazykové, tak business) společně s úrovněmi těchto znalostí - informace o práci plánované pro uživatele - přístupová práva uživatele - organizační zařazení uživatele - identity uživatele v různých systémech
1
AC_1.3
1
AC_1.4
1
AC_1.5
F_3
Uživatelská data jsou následně exportována v požadovaném formátu (.csv) a ukládána automaticky na dedikovaná FTP za použití SSH: - CME datový soubor (1x) - Odigo datový soubor (1x) - Gedeon datový soubor (1x) - REC datový soubor (4x) - DWH datový soubor (2x)
F_4
FIM je synchronizován s Active Directory pro všechny pobočky QUIMPER v rozsahu projektu. - Oboustranná synchronizace - FIM do AD: uživatelská data - AD do FIMu: struktura OU, SG
F_6
Řešení umožňuje zadat uživatelská data přes webové rozhraní. - Pro každou pobočku lze určit pro každou datovou položku primární zdroj dat (datový pohled nebo portál).
Tabulka 8 - Ukázka akceptačních kritérií
Po vypracování finální verze kontraktu byla smlouva schválena jak řídícím výborem projektu, tak řídícím výborem programu QES (dříve zmiňované dvou-úrovňové schvalování externích nákladů na projekt). Podpisem smlouvy (ředitelkou programu QES) byl autorizován přechod do další etapy projektu. Vzhledem k tomu, ţe zpoţdění, které vzniklo během Etapy I, bylo minimalizováno nápravnými opatřeními, dá se říci, ţe Etapa I byla úspěšná. 3.2.4.2 Etapa II Pre-project
Initiation stage
Final delivery stage
Subsequent delivery stages Etapa I
Etapa II
Etapa III
Etapa IV
Na etapě II se jiţ podílel jak tým zaměstnanců QUIMPERu, tak externího dodavatele. Cíle etapy II byly následující: 1. QUIMPER: Příprava databázových pohledů s uţivatelskými daty, ze kterých by MS FIM čerpal data pro další distribuci. 2. QUIMPER: Příprava specifikace poţadavků pro dodávku dodavatele, která měla být realizována během 2. poloviny etapy II a etapy III. 62
3. Dodavatel: Dodání části řešení, jak bylo definováno ve specifikaci poţadavků dodaných QUIMPERem pro etapu II. 4. QUIMPER / Dodavatel: Průběţné testování řešení dodávaného dodavatelem a společné dolaďování objevených nedostatků. Na základě detailní specifikace vytvořené během etapy I byly vytvořeny datové pohledy sjednocující data z různých systémů a různých poboček společnosti QUIMPER. Po předání uţivatelských pohledů dodavateli byly objeveny drobné chyby, které byly zaregistrovány v registru otevřených bodů a následně dořešeny. Během přípravy datových pohledů došlo ke zpoţdění při integraci dat z ostatních poboček (data nebyla ostatními pobočkami včas připravena) a z toho důvodu jsme se rozhodli, ţe dodavatel začne pracovat s pohledy, i kdyţ obsahují pouze praţská data a data z ostatních poboček budou dodatečně přidány. Tímto rozhodnutím se nám podařilo eliminovat riziko zpoţdění první dodávky ze strany dodavatele, jelikoţ ten bez konkrétních dat nemohl začít pracovat na přípravě jeho části řešení. Příprava specifikace pro 2. část etapy II se bohuţel neobešla bez zpoţdění, jelikoţ oba projekty, pro které jsme dodávali řešení, byly ve značném zpoţdění a nebyly zcela jasné poţadavky na námi dodávané řešení. Dodání specifikací pro 2. část etapy II se proto opozdilo o cca dva týdny, ale toto zpoţdění bylo kompenzováno přípravnými pracemi pro etapu III (které byly původně naplánovány na počátek etapy III) a také opravami chyb objevených interním týmem v první dílčí dodávce řešení dodaného dodavatelem. PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
Dodávka ze strany dodavatele pro 1. fázi II. etapy (datové soubory pro CME, Odigo, Gedeon) byla dodána s dvoutýdenním zpoţděním oproti původnímu plánu. Toto zpoţdění bylo zapříčiněno jak podceněním náročnosti ze strany dodavatele, tak ne zcela srozumitelnými formulacemi komplexnějších poţadavků ve specifikaci (dáno tím, ţe autor i čtenář nejsou silní v angličtině – viz. „lessons learned“). Vzhledem ke zpoţdění ostatních projektů v rámci QES programu bylo toto zpoţdění řídícím výborem projektu vyhodnoceno tak, ţe i kdyţ přesahuje limit pro eskalaci nemá na projekt velký dopad, byl přesto odsouhlasen „exception plan“ vypracovaný společně mnou a týmovým manaţerem
63
dodavatele. V rámci tohoto plánu byl aktualizován harmonogram projektu a jednotlivé úkoly byly posunuty s ohledem na nabrané zpoţdění. THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Během doby, kdy dodavatel pracoval na dodání řešení pro fázi 2 (datové soubory pro REC a DWH), tým QUIMPERu testoval datové soubory dodané na konci fáze 1. Bohuţel se během testování objevilo mnoho chyb a také několik poţadavků na změnu. Všechny chyby objevené během testování byly zaznamenány do registru otevřených bodů pod kategorii „Error“. Chyby byly dodavatelem průběţně odstraňovány, ale odstranění chyby jedné mělo bohuţel často za následek objevení chyby jiné. Jelikoţ dodání datových souborů pro CME, Odigo a Gedeon mělo nejvyšší prioritu, primárně se pracovalo na odstranění chyb a z toho důvodu vzniklo další zpoţdění projektu. Datové soubory pro DWH a REC (fáze 2) byly proto dodány téměř o měsíc později oproti původnímu plánu. Po dodání datových souborů pro DWH a REC se situace s mnoţstvím chyb objevených během testování opakovala. Z důvodu sníţení negativního dopadu zpoţdění na projekt jsem vypracovala ve spolupráci řídícím týmem projektu „exception plan“ jehoţ náplní tentokrát nebyla pouze změna harmonogramu projektu, ale i návrh na posílení kapacit projektového týmu dvěma novými členy, kteří by dostali za úkol vypracování částí chybějících specifikací a testovacích scénářů. Tento „exception plan“ byl následně schválen řídícími výbory projektu i programu. Vzhledem k dalším a mnohem větším zpoţděním, které v té době nabraly ostatní projekty v rámci QES programu, nebylo ani toto zpoţdění kritické z pohledu času a bylo učiněno rozhodnutí, ţe na dodavatele nebude vytvářen zbytečný tlak, jelikoţ tento tlak by mohl vést k dalším problémům, kterým jsme jeho sníţením mohli zabránit (chyby způsobené stresem z nedostatku času, neochota zapracovávat poţadavky na změnu, atd.). Jelikoţ dodavatel měl na projekt alokovaného pouze jednoho experta, nebylo moţné přijmout ţádné nápravné opatření pro posílení kapacit dodavatele (více viz. „lessons learned“).
64
PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Počátkem února autorizoval řídící výbor projektu přechod do etapy III i přes to, ţe ještě nebyly odstraněny veškeré chyby z datových souborů, které měly být odstraňovány dále během etapy III na základě výsledků testování průběţně prováděného členy projektového týmu souběţně s přípravou pro etapu III. Tyto opravy byly v harmonogramu pro etapu III také reflektovány delšími časovými prodlevami mezi jednotlivými úkoly dodavatele. Přesný plán testování zaměstnanci QUIMPERu nebylo moţné určit, jelikoţ testování bylo ad-hoc na základě dodání oprav dodavatelem (byla však vymezena časová dotace na testování na týdenní bázi). Vzhledem k tomu, ţe na konci etapy II nebyly datové soubory bez chyb, bylo také rozhodnuto, ţe jejich akceptace proběhne během etapy III stejně jako jejich nasazení do produkce (dle momentálního stavu). 3.2.4.3 Etapa III Pre-project
Initiation stage
Final delivery stage
Subsequent delivery stages Etapa I
Etapa II
Etapa III
Etapa IV
Hlavní náplní etapy III bylo: QUIMPER: dokončení specifikace pro automatizaci ţivotního cyklu zaměstnance. Dodavatel: vytvoření konfiguračních obrazovek dle dodané specifikace. Dodavatel: odstranění chyb z datových souborů a jejich nasazení do produkčního prostředí. Dodavatel: automatizace ţivotního cyklu zaměstnance. QUIMPER: průběţné testování dílčích řešení dodaných dodavatelem. PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
Během etapy III se nadále pracovalo na dokončení specifikace ţivotního cyklu zaměstnance. Kvůli nesrovnalostem ve specifikaci, které nebyly autorem odstraněny i přes četná upozornění, jsem navrhla další rozšíření týmu o analytičku, která se doposud na projektu nepodílela a která by tvorbu chybějící specifikace převzala. Toto rozšíření kapacit 65
bylo schváleno sponzorem projektu. Na základě autorizace sponzora projektu jsem vyjednala s jejím nadřízeným její uvolnění na projekt a práce jí byla předána. Specifikace byla následně předána sice se zpoţděním vůči původnímu časovému harmonogramu, ale vzhledem ke zpoţdění dodavatele toto zpoţdění nezpůsobilo další prodlouţení projektu. Z důvodu zvýšení efektivity a eliminace dalších zpoţdění ze strany dodavatele způsobených občasným neporozuměním specifikace a nutnou komunikací s kolegy, pokud pracoval na našem projektu vzdáleně, bylo dohodnuto, ţe nadále bude na našem projektu pracovat přímo v sídle společnosti QUIMPER, kde můţe případné nesrovnalosti konzultovat rovnou a případně učinit nutná rozhodnutí. Tento způsob spolupráce se narozdíl od práce na dálku osvědčil (více viz. – „lessons learned“). K odstranění téměř všech chyb z datových souborů došlo aţ v půlce dubna 2012 a první část řešení jsem akceptovala s výhradou (dvě výhrady). Tyto rezervace byly odstraněny počátkem května. Na základě úspěšného odstranění chyb potrvrzeného otestováním (objevily se nějaké drobnosti, ty však nebyly závaţné) bylo 16. května uděleno GO pro nasazení řešení pro tvorbu datových souborů do produkčního prostředí. Nasazení do produkčního prostředí proběhlo několik dní před spuštěním pilotní fáze projektu TELCO, takţe naše zpoţdění nemělo dopad na ostatní projekty v rámci programu QES. Vzhledem k napjatému harmonogramu pro nasazení do produkce a rozhodnutí téměř na poslední chvíli byl připraven i záloţní plán jak neohrozit spuštění pilotu TELCO projektu v případě, ţe by nebylo moţné doručit řešení před jeho počátkem. Tento záloţní plán byl schválen jak na úrovni řídícího výboru projektu, tak programu QES. Záloţní plán spočíval v pouţití datových souborů, ve kterém by chyby byly odstraněny ručním zásahem dedikovaným členem týmu, coţ pro počáteční etapu pilotu projektu TELCO bylo dobře zvládnutelné (cca 10 zaměstnanců). V současné době dodavatel pracuje na řešení pro plnou automatizaci ţivotního cyklu zaměstnance, která zatím běţí podle harmonogramu. Testování automatizace ţivotního cyklu zaměstnance je plánováno na konec června 2012 a následná akceptace na druhý týden v červenci 2012. Na základě výsledků testování bude zrevidován harmonogram pro III. etapu a bude také vytvořen harmonogram pro IV. etapu projektu, během které budou dodavatelem dodány funkcionality, které byly vyhodnoceny jako mimo rozsah projektu (srpen – září 2012). 66
Z důvodu nepřipravenosti projektu GAD na některých pobočkách bude v nejbliţší době také připraven „exception plan“ pro nasazení celého řešení do produkce. Původně bylo počítáno s nasazením řešení na všechny pobočky současně, avšak to nebude moţné a proto po zváţení a předběţném schválení sponzorem projektu bude nasazení řešení nejspíše uskutečněno v krocích, kdy pilotní provoz začne v praţské pobočce ještě v rámci III. etapy projektu. Nasazení řešení na další pobočky pak bude součástí IV. etapy projektu. 3.2.4.4 Etapa IV Pre-project
Initiation stage
Final delivery stage
Subsequent delivery stages Etapa I
Etapa II
Etapa III
Etapa IV
Hlavní náplní etapy IV bude: QUIMPER: postupné nasazování řešení na ostatní pobočky (srpen – září 2012). Dodavatel: dodání funkcionality “Roles management” (součást řešení pro automatizaci ţivotního cyklu zaměstnance, srpen 2012). Dodavatel: dodání funkcionality “automatické vytváření e-mailových schránek pro nové zaměstnance” (součást řešení pro automatizaci ţivotního cyklu zaměstnance, září 2012). QUIMPER: průběţné testování dodávek uskutečněných dodavatelem. THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Pro etapu IV počítáme s vyuţitím následujících kapacit: Úkol
Zdroje – QUIMPER
Zdroje – dodavatel
Kdy
Nasazení řešení na ostatní pobočky
3 MDs (řízení projektu)
0
5 MDs (nasazení celkem)
2 MDs (není vícenáklad)
srpen – září 2012
2 MDs (řízení projektu)
0.5 MD (řízení projektu)
3 MDs (testování)
12 MDs (vývoj - nárůst nákladů pouze o 5.5 MDs)
srpen 2012
2 MDs (řízení projektu)
0.5 MD (řízení projektu)
2 MDs (testování)
6.ř MDs (vývoj)
září 2012
„Roles management“ Automatické vytváření emailových schránek
Tabulka 9 - Kapacity potřebné pro realizaci etapy IV
67
Harmonogram v příloze 7 zachycuje naplánovaný rozpis prací pro etapu IV - konkrétně „Roles management“ a automatické vytváření e-mailových schránek. Nasazení řešení na ostatní pobočky není v harmonogramu zatím zachyceno, jelikoţ pevné datumy ještě nebyly stanoveny
68
3.2.5 „Final delivery stage“ (Etapa konečné dodávky) Pre-project
Initiation stage
Final delivery stage
Subsequent delivery stages Etapa I
Etapa II
Etapa III
Etapa IV
Náplní „Final delivery stage“ bude příprava uzavření projektu, předání správy produktů projektu internímu týmu podpory, vyhodnocení projektu a samotné uzavření projektu. „Final delivery stage“ bude započata po akceptaci řešení dodaných dodavatelem v rámci etapy IV. Jednotlivé aktivity pro přípravu uzavření projektu a jeho samotné uzavření jsou popsány procesem „Closing a project“ proto se tady jimi nebudu zabývat. Vzhledem k tomu, ţe řešení bylo nasazováno do provozu průběţně jiţ během etap II aţ IV a tím předáváno internímu zákazníkovi, tato aktivita bude vynechána. Avšak vzhledem k tomu, ţe velká část řešení byla dodána externím dodavatelem, musí být během uzavíraní projektu kladen velký důraz na kompletnost předání správy řešení internímu IT týmu společnosti QUIMPER. Proces přípravy předání internímu týmu podpory jsem jiţ započala tím, ţe jsem zajistila vytvoření vývojového prostředí MS FIM 2010, který je kopií prostředí, ve kterém vyvíjí dodavatel a ve kterém se interní tým můţe začít seznamovat s tímto řešením. Na počátku května se jiţ také konalo první školení interního týmu dodavatelem, jehoţ náplní bylo seznámit tým s řešením tak, aby si interní tým pomalu mohl začít budovat znalost tohoto řešení. V současné době jiţ jeden člen interního týmu dostává chybová hlášení a učí se sám hledat řešení problémů, které se mohou vyskytnout (v případě potřeby mu je samozřejmě k dispozici expert od dodavatele). Taktéţ jsem jiţ na něj přesměrovala zapracovávání drobných úprav v řešení, opět s cílem vybudovat si co nejdříve interní znalost řešení. Na konec června 2012 je naplánováno velké školení od dodavatele, které se bude zaměřovat především na předání znalostí o tom, jak řešit problémy, které mohou v řešení nastat a také zodpovězení otázek, které identifikoval interní tým, kdyţ se s řešením seznamoval vlastními silami. Původní náplní školení mělo být pouhé seznámení s řešením, ale vzhledem k tomu, ţe toto se nám podařilo zvládnout díky naší proaktivitě jiţ v průběhu dodávek, po domluvě s dodavatelem jsme náplň školení upravili tak, aby nám školení přineslo co největší uţitek. Školení administrátorů, kteří budou mít na starosti jednodušší úkoly (např. drobné úpravy konfigurace přes GUI, vytváření uţivatelů atd.) bude provedeno interními zdroji, které se podílely na testování řešení a mají výhodu jak znalosti řešení, tak hluboké znalosti kontextu projektu a skupiny QUIMPER. 69
3.2.6 „Processes“ (Procesy) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Tato kapitola se detailně zabývá vybranými procesy a jejich aplikací v praxi na popisovaném projektu, konkrétně se jedná o procesy: Řízení etapy (“Controlling a stage”) Řízení dodávky produktu (“Manage product delivery”) Konkrétní způsob aplikace ostatních procesů je popsán v jiných částech této práce a nebude v této kapitole znovu zmiňován. Jelikoţ aplikace těchto aktivit je téměř stejná pro všechny etapy, popisuji je pro všechny etapy v rámci této kapitoly. 3.2.6.1 „Controlling a stage“ (Řízení etapy) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Proces „Controlling a stage“ se zabýva především denními aktivitami projektového manaţera v těchto třech oblastech: Monitorování průběhu a reportování stavu („Monitoring and Reporting“), Řešení problémů (otevřené body a rizika a jejich případná eskalace, nápravná opatření), Balíky práce („Work packages“) - autorizace, revize, převzetí.
70
3.2.6.1.1 „Monitoring and Reporting“ (Monitorování a reportování) Tato kapitola dále popisuje jakým způsobem byl projekt monitorován a jak byl reportován status projektu. 3.2.6.1.1.1 Týdenní schůzka řídícího týmu projektu
Jedním z hlavních nástrojů, pomocí kterého jsme řídili projekt, byly pravidelné týdenní schůzky řídícího týmu projektu (za účasti jak interního týmu QUIMPERu, tak i zástupce dodavatele). THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Cílem týdenních schůzek bylo sdílení aktuálního stavu projektu s týmem, shrnutí úkolů, na kterých se pracovalo v předešlém týdnu a validace úkolů, na kterých by se mělo podle projektového plánu pracovat příští týden. Dalším cílem bylo projít společně s týmem registrem otevřených bodů a rizik a v případě, ţe by se objevil nový otevřený bod či riziko, které nebylo do registrů zaznamenáno před schůzkou, zaznamenat jej a ohodnotit. Největší důraz byl kladen na registr rizik, jelikoţ vzhledem k velmi těsným termínům mohlo mít kaţdé neidentifikované riziko drastický dopad na dodrţení termínů dodávek projektu, na kterých byly závislé jiné projekty. Jako podklad pro revizi stavu projektu slouţil aktualizovaný týdenní report (obsahující shrnutí stavu projektu, harmonogram, registr otevřených bodů a rizik), zaslaný týmu před schůzkou. Dodrţování výše zmíněných cílů týdenních schůzek nám umoţnilo projekt řídit pruţně a reagovat velmi flexibilně na změny plynoucí převáţně z okolních projektů. Hlavním artefaktem těchto týdenních schůzek byl Týdenní report. Všechny důleţité informace, rozhodnutí a úkoly plynoucí z týdenní schůzky byly zaznamenány v Zápise z jednání. 3.2.6.1.1.2 Organizace týdenních schůzek řídícího týmu projektu
Pevný termín schůzky byl ustaven jiţ během zahajovací schůzky (kick-off meeting) na pátek v deset hodin dopoledne. Schůzky jsem se vţdy účastnila já jakoţto projektový manaţer, a vedoucí balíku práce vykonávané týmem dodavatele. V případě, ţe se schůzky nemohl jeden z nás zúčastnit, schůzka se vţdy přeplánovala. Schůzek se pak dále většinou účastnil HKO (IT Operations Manager), MOS (koordinace za PAR) a HGA (podpora 71
projektu). Schůzka se většinou konala v praţském sídle společnosti QUIMPER a MOS se vzdáleně připojil z PAR. 3.2.6.1.1.3 Role zúčastněných na týdenních schůzkách THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Má role na týdenních schůzkách byla zkoordinovat další společný postup všech zúčastněných stran (jak jednotlivých poboček společnosti QUIMPER, tak týmu dodavatele). Úkolem vedoucího balíku práce vykonávané týmem dodavatele bylo sdílet s týmem, na čem dodavatel aktuálně pracuje, zda se nevyskytly nějaké problémy (ty pak byly dále diskutovány a případně zaznamenány do registru otevřených bodů či registru rizik a zápisu ze schůzky) a případná domluva na spolupráci ze strany QUIMPER potřebná pro vykonání dalších úkolů (např. instalace serverů atd.). MOS se účastnil týdenních schůzek jakoţto jeden z hlavních přispěvatelů projektu a řídil dodávky některých balíků práce (převáţně vypracování specifikací pro dodavatele). Jeho účast na schůzkách byla důleţitá také proto, ţe byl osobou, která měla koordinovat práce v PAR. Bohuţel se však schůzek často neúčastnil (bez předchozí omluvy) coţ vedlo k časté neefektivitě schůzek a nutnosti řešit mnoho věcí individuálně a občas vedlo ke zbytečným průtahům. HKO se schůzek účastnil jakoţto zástupce budoucích uţivatelů a vlastník mnoha procesů, které byly naším projektem optimalizovány a také jako záštita technické podpory projektu. Účast HKO na týdenních schůzkách byla důleţitá také kvůli jeho informovanosti o jiných projektech (např. GAD), s nimiţ jsme museli naše kroky pečlivě sladit. Ukázka zápisu z týdenní schůzky je uvedena v Příloze 2.
72
3.2.6.1.2 „Weekly status report“ (Týdenní report) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Základním artefaktem, pomocí kterého byl řízen projekt FIM, byl týdenní report ve formě MS Excel sešitu, který měl následujících 5 listů: shrnutí současného stavu projektu (“project highlight”), aktualizovaný harmonogram projektu, aktualizovaný registr otevřených bodů, aktualizovaný registr rizik, seznam poţadavků na změnu vznesených ze strany QUIMPERu a jejich aktuální status.1 Z důvodu zpětné dohledatelnosti vznikl kaţdý týden nový soubor s týdenním reportem, který popisoval aktuální stav projektu pro daný týden. Týdenní reporty se stejně jako veškerá ostatní dokumentace týkající se projektu FIM ukládá na sdílené uloţiště vybudované na MS Sharepointu. Týdenní report byl rozesílán e-mailem na projektový řídící tým a také na řídící výbor projektu společně se schváleným zápisem z týdenní schůzky řídícího týmu projektu. Ukázka týdenního reportu je uvedena v Příloze 3. 3.2.6.1.3 „Issues Register“ (Registr otevřených bodů) Pro účely projektu FIM jsme strukturu registru otevřených bodů upravili tak, aby vyhovovala potřebám našeho projektu. Struktura se v průběhu projektu ještě několikrát změnila. Ve všech případech se jednalo o přidání dodatečného atributu či číselníkové hodnoty, která nám chyběla. Finální podoba registru otevřených bodů je uvedena v Příloze 4.
1
Tento seznam byl přidán ve III. etapě projektu.
73
PRINCIPLES Continued business justification
Learn from exporience
Defined roles and responsibilities
Manage by stages
Manage by exceptions
Focus on products
Tailoring
Rozdíly oproti registru otevřených bodů, jak jej definuje PRINCE2, jsou především dány přidáním několika atributů dle konkrétních potřeb projektu FIM. Co v registru otevřených bodů definovaném pro projekt FIM schází, je evidence autora reportu o otevřeném bodu. To je dáno tím, ţe tento artefakt – Report o otevřeném bodu, resp. jeho číslo, bývá zmíněno v titulu otevřeného bodu. Vzhledem k tomu, ţe během projektu bylo potřeba formálně řešit otevřené body pouze typu Poţadavek na změnu, byl report o otevřeném bodu vytvářen pouze pro poţadavky na změnu v podobě Formuláře pro poţadavek na změnu („Change request form“). 3.2.6.1.4 „Risks Register“ (Registr rizik) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Pro správu rizik byl pouţíván registr rizik v podobě tabulky, která byla také součástí týdenního reportu. Součástí registru rizik byl i eliminační plán rizika a návrh řešení co dělat, pokud riziko nastane ve skutečnosti. Finální podoba registru rizik je uvedena v Příloze 5. 3.2.6.2 „Work Packages“ (Balíky práce) PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Tato kapitola popisuje „Work Packages“ a práci s nimi jak z pohledu projektového manaţera, tak z pohledu manaţera týmu. Proto se v ní prolínají dva procesy „Controlling a stage“ a „Manage product delivery“.
74
3.2.6.2.1 „Work Packages“ z pohledu projektového manažera PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Na základě produktů a harmonogramu projektu byly definovány balíky práce („Work Packages, dále označovány jako WP) pro etapu II a III. Poté, co byl WP vydefinován, byl autorizován a předán. Průběh práce na jednotlivých WP byl monitorován na týdenní bázi během týdenní schůzky řídícího týmu projektu (v průběhu týdne jsem také kontrolovala stav jednotlivých úkolů, obzvláště u těch rizikových). Reportování stavu jednotlivých WP bylo součástí týdenního reportu. Převzetí vyhotoveného WP předcházela verifikace, ţe veškerá práce je hotová a nejsou ţádné defekty. Konkrétně: Specifikace: revize dalším člověkem před předáním dodavateli s cílem odhalit případně nekonzistence / chybějící informace. Zjištěné defekty byl zaznamenány přímo do dokumentu. Technická řešení: testování dalším člověkem s cílem odhalit případné chyby v řešení. Zjištěné defekty byly zaznamenány do registru otevřených bodů. V případě, ţe byly objeveny defekty, byl balík práce vrácen k přepracování. WP byl přijat jako kompletní aţ po odstranění veškerých objevených defektů. 3.2.6.2.1.1 „Work Packages“ z pohledu manažera týmu PROCESSES Directing a project Starting up a project
Initiating a project
Stage boundary
Controlling a stage
Manage product delivery
Closing project
Po autorizaci byl WP předán osobě zodpovědné za dodávku specifikovanou v daném WP. WP byl přijmut poté co byly vyjasněny případné nejasnosti (např. nejasné zadání očekávané dodávky, nerealistické plánování, nejasný způsob předání, atd.).
75
Vzhledem k tomu, ţe se většinou jednalo o malé WP, nepracoval na WP celý tým, ale pouze jeden člověk, který tím pádem plnil roli jak „týmového“ manaţera, tak dodavatele práce. V případě, ţe se během práce na WP objevily další nejasnosti (případně rizika), byl objevený problém konzultován s projektovým manaţerem (mnou) a následně zaregistrován do registru otevřených bodů nebo rizik v případě, ţe nebylo moţné problém vyřešit okamţitě. Poté, co byl WP práce zkompletován, mi byl předán. WP práce jsem nepřijala, dokud neproběhla úspěšná verifikace (popsáno v předcházející kapitole). V případě zjištěných defektů byl manaţer týmu zodpovědný za jejich odstranění. WP obsahující technické řešení byly předávány postupně tak, aby mohlo probíhat testování na jiţ hotových částech řešení v době, kdy dodavatel technického řešení pracoval na další části balíku (z důvodu minimalizace administrativy nebyly tyto menší části WP rozděleny do samostatných WP).
3.2.7 „Themes“ (Témata) Tato kapitola explicitně popisuje téma změn („Change“). Ostatní témata a jejich aplikace v praxi jsou popsány v jiných částech této práce a nebudou zde znovu popisovány. 3.2.7.1 „Change“ (Změna) THEMES Business case
Organization
Quality
Plans
Risk
Change
Progress
Během etapy II a III se objevilo zhruba 25 významnějších poţadavků na změnu (většina byla vznesena ze strany QUIMPERu). Proces zpracovávání poţadavků na změnu probíhal následujícím způsobem: 1. Člen projektového týmu, který poţadavek na změnu vznesl / identifikoval vyplnil formulář pro poţadavek na změnu s přesným popisem poţadované změny a jejím dopadem a zaznamenal nový poţadavek na změnu do registru otevřených bodů (kategorie „poţadavek na změnu“). Ukázka vyplněného formuláře pro poţadavek na změnu je uvedena dále v této kapitole.
76
2. Poté byl poţadavek buď schválen projektovým manaţerem (mnou), nebo byl navrácen k dalšímu upřesnění, případně zamítnut s odůvodněním (obvykle se jednalo o poţadavek nesouvisející nijak s projektem). 3. Poté co jsem poţadavek na změnu schválila, projednala jsem dopad implementace daného poţadavku s dodavatelem. a. Pokud se jednalo o drobnou změnu, tak byla změna zpracována téměr okamţitě (max. do dvou týdnů). b. Pokud se jednalo o větší změnu, která však nebyla vyhodnocena jako „mimo rozsah“ projektu, bylo provedení změny naplánováno na dobu, kdy dodavatel např. čekal na výsledky testů nebo po uzavření dané etapy projektu. c. Pokud se jednalo o velkou změnu, která byla vyhodnocena jako „mimo rozsah“ projektu, a dodavatel za provedení této změny poţadoval rozšíření rozsahu projektu a dokoupení dodatečných mandays na její zapracování, byl poţadavek na změnu postoupen dále ke sponzorovi projektu. Na základě jeho doporučení byl poţadavek na změnu dále podstoupen řídícímu výboru projektu a následně řídícímu výboru programu ke schválení dodatečných externích nákladů na projekt. Realizace těchto změn byla odsunuta na dobu po akceptaci původně nasmlouvaného rozsahu řešení. 4. Po schválení poţadavku na změnu všemi zúčastněnými stranami byl poţadavek na změnu
odeslán
oficiálně
dodavateli
společně
s novou
verzí
specifikace
s vyznačenými změnami v textu (pokud bylo třeba). 5. Po zapracování poţadavku na změnu dodavatel změnil stav poţadavku v registru otevřených bodů na „vyřešený“ a pověřená osoba QUIMPER otestovala, zda řešení se zpracovanou změnou splnila očekávání. Pokud nebyl poţadavek na změnu správně zpracován, byl otevřený bod vrácen dodavateli s udáním důvodu k dopracování. Ukázka formuláře pro poţadavek na změnu je uvedena v Příloze 6. Součástí poptávky i následné nabídky vítězného dodavatele byla integrace dat z jednotlivých poboček skupiny QUIMPER do MS FIM dodavatelem. Po bliţším 77
prozkoumání dodavatel zjistil, ţe pokud by tuto integraci měl provést, mělo by to velmi negativní vliv na harmonogram projektu (zpoţdění min. 2 týdny). Po vzájemné dohodě mezi mnou a zástupcem dodavatele a následným schválením předloţeného návrhu sponzorem projektu jsme se rozhodli, ţe integraci dat z jednotlivých poboček připraví jeden z našich databázistů a dodavatel nás následně bude kompenzovat bezplatným provedením poţadavků na změnu v odpovídajícím rozsahu na konci projektu. Z toho důvodu byly téměř všechny poţadavky na změnu realizovány dodavatelem bezplatně. Dodatečné náklady?
Etapa / Stav
ano
Celkem
ne
Etapa II hotovo
19
19
zrušeno
3
3
hotovo
1
1
nejasný
1
1
Etapa III
schváleno
1
1
schváleno sponzorem
1
1
Celkem 2 24 26 Tabulka 10 - Přehled požadavků na změnu a jejich stav
Z výše uvedené tabulky je patrné, ţe téměř všechny poţadavky na změnu byly zapracovány jiţ v průběhu projektu. Po domluvě s dodavatelem a následným schválením řídícím výborem projektu bylo odsouhlaseno, ţe poţadavek č. 10 bude zpracován aţ po akceptaci původního rozsahu řešení a budou dokoupeny dodatečné mandays. Poţadavek č. 26 je v současné době ve fázi schvalování (jiţ byl schválen řídícím výborem projektu, v nejblizší době bude předloţen ke schválení řídícímu výboru programu). Pokud bude schválen, bude zapracován v rámci etapy IV.
78
3.3 Vyhodnocení projektu Vzhledem k tomu, ţe projekt ještě nebyl ukončen, není moţné vyhodnotit celý projekt jako takový a proto v této kapitole uvádím vyhodnocení projektu podle aktuálního stavu k 10. červnu 2012.
3.3.1 Cena (strávený čas) Tabulka níţe uvádí přehled nákladů na lidské zdroje plánované a reálný čas strávený na projektu (per aktivita). Vzhledem k tomu, ţe s dodavatelem byla uzavřena smlouva o dílo, reálný čas strávený dodavatelem na projektu nebyl dodavatelem poskytnut. Zdrojem počtu MDs reálně strávených na projektu zaměstnanci QUIMPER je databáze Microsoft TFS, kam členové projektového týmu zaznamenávali čas strávený na projektu.
Zdroj
D
Q Celkem Celkem
Pilot R vs. [MDs] P [%]
Realita [MDs]
R vs. P [%]
design
9
9
100%
11
122%
11
122%
dokumentace
6
6
100%
8
133%
8
133%
Instalace projektový management
4
4
100%
5
125%
5
125%
12
12
100%
13
108%
13
108%
školení
7
7
100%
8
114%
8
114%
vývoj
48
48
100%
54
113%
56
117%
86
86
100%
99
115%
101
117%
Aktivita
D Celkem
Q
Po změně rozsahu R vs. [MDs] P [%]
Plán [MDs]
Instalace projektový management
3
3
100%
3
100%
8
267%
25
52
208%
56
224%
59
236%
školení
11
11
100%
18
164%
18
164%
specifikace
22
39
177%
41
186%
41
186%
testing
15
27
180%
32
213%
37
247%
vývoj
5
10
200%
10
200%
10
200%
81
142
175%
160
198%
173
214%
167 228 137% 259 155% 274 Tabulka 11 - Vyhodnocení nákladů na projekt (etapa II – IV)
164%
Z tabulky uvedené výše vyplývá, ţe náklady na projekt, týkající se vyuţití lidských zdrojů, jsou vyšší neţ bylo plánováno. Nárůst nákladů ze strany dodavatele ve výši 17% je dán tím, ţe v průběhu projektu jsme objevili nové poţadavky, které nebyly v rozsahu zakoupeného díla. 79
Nárůst interních personálních nákladů o 64% byl způsoben především vysokou chybovostí dodávaného řešení a tím pádem nutným opakovaným časové náročným testováním. Vysokou chybovost není moţné přičítat pouze externímu dodavateli, velká část chyb byla způsobena nepřesným pochopením poţadavků ze strany QUIMPER (nepřesné formulace). Vliv na nárůst personálních nákladů měla i jazyková bariéra mezi některými členy projektu, která měla za následek téměř nekonečné řešení některých problémů (především nárůst aktivit projektového řízení). Nárůst interních zdrojů na projekt není řídícím výborem projektu ani programu povaţován za neúspěch, jelikoţ se nám díky projektu podařilo optimalizovat mnoho procesů okolo ţivotního cyklu zaměstnance (např. řízení a správa znalostí zaměstnanců), které ani nebyly původním záměrem projektu. Nárůst nákladů na externí dodávky ve výši 17 % byl očekávaný. Jelikoţ práce dodavatele byla nakoupena za téměř poloviční cenu neţ konkurenční nabídka (cena za MD byla téměř stejná, značně se však lišil počet MDs), která odpovídala původní výši schváleného rozpočtu na externího dodavatele, ani s tímto 17 % navýšením jsme stanovený rozpočet nepřesáhli.
80
3.3.2 Harmonogram Harmonogram níţe uvádí porovnání původního harmonogramu a reality. Pro lepší čitelnost jsou v harmonogramu zaznamenány pouze významné produkty projektu. Úkol
Trvání
Zdroj
Plán Počátek
Realita Konec
Počátek
Konec
IDM (FIM) Project Stage II Research configuration for export to CSV for applications ODIGO, CME, GEDEON in test env. Research configuration for export to CSV for applications DWH, REC in test environment Research configuration for export to Active Directory and self services in test environment
10 dní
D
18-102011
31-102011
18-102011
21-112011
7 dní
D
14-112011
22-112011
21-112011
1-122011
12 dní
D
24-112011
9-122011
16-22012
30-42012
6-12012
17-52012
21-52012
Export files I in production Export to CSV for applications ODIGO, CME, GEDEON in production environment
2 dny
D
5-1-2012
Stage III Export files II in production Export to CSV for applications Group 11-112-118-522-5Datawarehouse, Recording 2 dny D 2012 2012 2012 2012 tool in production environment Export to Active Directory 16-120-121-522-5and running self services in 5 dní D 2012 2012 2012 2012 production environment Research configuration user lifecycle and revision history 23-11-228-5srpen 8 dní D of changes in test 2012 2012 2012 '12 * environment Running user lifecycle and 21-222-2revision history of changes in 2 dny D srpen '12 * 2012 2012 production environment Tabulka 12 - Porovnání původního a reálného harmonogramu projektu (etapa II – IV)
* Část řešení bude dodána již počátkem července. Chybějící funkcionalita během srpna 2012 („Roles management“). Vzhledem k jiţ dříve zmiňovaným zpoţděním ostatních projektů v rámci QES programu nemělo toto zpoţdění negativní dopad na ostatní projekty. Časové zpoţdění projektu mohlo být menší v případě, kdybych na členy týmu vyvíjela vyšší tlak, ale vzhledem ke 81
zpoţděním na ostatních projektech toto nebylo třeba a dala jsem přednost kvalitě a komfortu projektového týmu (jehoţ důsledkem byla například ochota dodavatele zpracovávat poţadavky na změnu téměř okamţitě).
82
3.3.3 „Lessons learned“ (Poučení) Během projektu jsme zaznamenali mnoho lekcí. Velká část z nich byla dána tím, ţe projektový tým byl tvořen různými národnostmi a během práce na projektu jsme museli čelit jak kulturním odlišnostem (jiné pracovní návyky, vnímání času, atd.) tak i jazykovým bariérám. Samozřejmě všechny lekce, které jsme během projektu zaregistrovali, nebyly dány jen mezinárodním prostředím projektu. Níţe uvádím přehled lekcí, které já osobně povaţuji za nejdůleţitější: Zastupitelnost – vzhledem k tomu, ţe dodavatel měl v dané oblasti pouze jednoho experta, nebylo moţné rozšířit kapacity dodavatele rozšířit a tím sníţit zpoţdění. V případě, ţe by expert z jakéhokoliv důvodu musel přerušit práci na našem projektu, projekt by to váţně ohrozilo a mohlo vést k jeho předčasnému ukončení. o Poučení pro příště: budovat tým takovým způsobem, aby existovala zastupitelnost. U projektů realizovaných ve spolupráci s externím dodavatelem trvat na zastupitelnosti jeho zaměstnanců taktéţ jiţ před zahájením spolupráce. Časová rezerva – díky mírně laxnímu přístupu francouzských kolegů k plnění dohodnutých termínů (obecný problém kulturního rázu) došlo k několika zpoţděním či vypjatým situacím. o Poučení pro příště: plánovat s mnohem větší časovou rezervou, která nebude prezentována ostaním kolegům. Ověření porozumění – díky jazykovým bariérám (ani autor specifikací ani jejich hlavní čtenář – expert dodavatele nebyli příliš silní v angličtině) nebyly části specifikací s komplexní logikou občas správně pochopeny, coţ vedlo k mnoha nedorozuměním a průtahům. o Poučení pro příště: ve specifikacích co nejvíce uvádět příklady, na kterých bude jasně demonstrováno co je očekáváno (pokud čtenář přesně neporozumí logice, na příkladu očekávaného výsledku si pak můţe ověřit své porozumění). Prezentace cílů a benefitů – jelikoţ na počátku nebyly správně prezentovány cíle projektu a očekávané benefity (důraz byl kladen na podruţné cíle, které by mohlo 83
mnohem lépe zajistit jiné řešení, reálné benefity nebyly prezentovány téměř vůbec) došlo ke značným průtahům před schválením projektu a vedlo k mnoha nedorozuměním v průběhu. o Poučení pro příště: je třeba klást důraz na správnou prezentaci cílů projektu, jejich váhu i pořadí. Benefity by měly být pokud moţno měřitelné (alespoň některé). V případě, ţe cílům není správně porozuměno, je třeba zjistit proč a cíle případně přeformulovat, lépe vysvětlit atd. Jazykové bariéry – při přípravě byl podceněn moţný dopad nepříliš dobrých jazykových znalostí jak některých členů interního týmuů tak i experta dodavatele. Tato jazyková bariéra pak měla za důsledek to, ţe někteří členové našeho týmu měli problém vyjádřit přesně svůj poţadavek (jak ve psané podobě, tak v mluvené) a tým dodavatele často neporozuměl některým poţadavkům (obzvláště pokud za nimi stála komplexnější logika). Tato neporozumění pak často musela být řešena mnou a často jsem musela figurovat jako tlumočník pro obě stranyů coţ mělo negativní vliv na mé osobní časové zdroje dedikované pro projekt FIM. o Poučení pro příště: nepodceňovat moţný dopad nízké úrovně jazykových znalostí členů týmu s tím, ţe se řešení u mezinárodních projektů najde samo a trvat na takové formě spolupráce, která rizika spojená s jazykovými bariérami eliminuje (členové týmu pouze s dobrými jazykovými znalostmi, větší důraz kladený na verifikaci porozumění všemi stranami). Práce externího dodavatele mimo sídlo QUIMPER – na začátku projektu jsme týmu dodavatele odsouhlasili, ţe jejich expert můţe většinu času strávit ve své kanceláři a do sídla naší společnosti v PRA bude docházet pouze na předem domluvené schůzky. Toto rozhodnutí mělo za následek, ţe expert dodavatele byl neustále vyrušován poţadavky z jiných projektů a nemohl se plně koncentrovat na náš projekt (chyby, zpoţdění). Nejasnosti ve specifikacích byly dlouze vysvětlovány po telefonu nebo e-mailem, coţ také nebylo příliš efektivní. Po několika měsících takovéto spolupráce bylo rozhodnuto, ţe expert dodavatele bude pracovat přímo na naší PRA pobočce. o Poučení pro příště: v případě rizika, ţe dodavatel neporozumí přesně zadání nebo nebude mít moţnost se plně koncentrovat na projekt, navrhnout 84
okamţitě, aby pracoval přímo u zákazníka (u nás) a s tímto návrhem zbytečně neotálet.
85
4 Závěr Cílem mé práce bylo seznámit čtenáře s metodikou pro řízení projektů PRINCE2 a demonstrovat vyuţití jejích myšlenek na reálném projektu. V teoretické části své diplomové práce jsem čtenáře seznámila se základními pojmy z oblasti řízení projektů. Dále jsem se zabývala historickým vývojem metodiky PRINCE2 a jejich principů, témat a procesů. V praktické části své diplomové práce jsem se jiţ zabývala konkrétním způsobem aplikace metodiky PRINCE2 na projekt FIM, který v zaměstnání řídím. Popis projektu jsem rozdělila do částí odpovídajících jednotlivým fázím ţivotního cyklu projektu. Pro kaţdou fázi jsem pak popsala její průběh a zdůraznila, jakým způsobem byly v praxi aplikovány jednotlivé aspekty metodiky PRINCE2. Na konci své diplomové práce jsem provedla průběţné hodnocení aktuálního stavu projektu k datu 10. června 2012. Jelikoţ projekt oproti původnímu plánu stále ještě není ukončen, nebylo moţné provést jeho kompletní vyhodnocení. Následné kroky, které ještě bude třeba vykonat, jsou v mé práci popsány. Během práce na projektu a jeho zpětném vyhodnocování při psaní mé diplomové práce jsem došla k názoru, ţe „největší výzvou“ tohoto projektu byl projektový tým - řízení projektu v mezinárodní prostředí s mnoha kulturními odlišnostmi (např. přístup k plnění termínů), jazykovými bariérami a nevraţivostí mezi některými členy týmu bylo občas opravdu velmi náročné. Přes veškeré problémy, kterými jsme s týmem během projektu prošli, i přes tříměsíční zpoţdění projektu, je projekt FIM hodnocen jako nejúspěšnější projekt v rámci programu QES. Náplň projektu FIM je hodnocena pozitivně i ze strany dodavatele, který náš projekt přihlásil do mezinárodní soutěţe, pořádané spoelčností Microsoft. V současné době není výsledek soutěţe znám.
86
5 Seznam použité literatury Elektronické monografie [1]
PRINCE2 - The Method. OGC. PRINCE2 - PRojects IN Controlled Environments [online].
16.1.2012
[cit.
2012-06-10].
Dostupné
z:
http://www.prince-
officialsite.com/AboutPRINCE2/PRINCE2Method.aspx [2]
Plán projektu (Project Plan). MANAGEMENTMANIA. ManagementMania.com [online].
2011,
23.12.2011
[cit.
2012-06-10].
Dostupné
z:
http://managementmania.com/cs/plan-projektu [3]
PRINCE2:2009 Glossary of Terms – Czech. POTIFOB. POTIFOB: Projekty dodané včas, v dohodnutém rozsahu a kvalitě, s dodržením rozpočtu - mýtus či realita? | Projekty včas, v plném rozsahu a s dodržením rozpočtu [online]. 2011, 21.11.2011 [cit. 2012-06-10]. Dostupné z: http://www.potifob.cz/files/CZ%20%20PRINCE2%202009%20Glossary%20of%20Terms%20%20Czech%20v1.1.pdf
[4]
A quick history of project management: Applies to: Microsoft Project 2010, Project 2007. MICROSOFT. Microsoft Office [online]. ©2012 [cit. 2012-06-10]. Dostupné z:
http://office.microsoft.com/en-us/project-help/a-quick-history-of-project-
management-HA010351563.aspx [5]
A Short History of Modern Project Management. STRETTON, Alan. IT Project Management – Holistic View, Practical Tips, Interpersonal Skills [online]. 2. vyd. 2007
[cit.
2012-06-17].
Dostupné
z:
http://stanyanakiev.files.wordpress.com/2011/04/stretton-10-07.pdf [6]
NAYEB, N. A Review of the Latest Trends in Project Management. Bright Hub: The hub for bright minds [online]. 2011 [cit. 2012-06-17]. Dostupné z: http://www.brighthub.com/office/project-management/articles/47469.aspx
[7]
Methodologies for Project Management Compared. ELZAS CONSULTANCY BV. Elzas Consultancy BV: Character in Project Management [online]. 2010 [cit. 201206-17].
Dostupné
z:
http://www.elzasconsultancy.net/wp-
content/uploads/2010/11/Methodologies-for-Project-Management-Compared.pdf
87
[8]
Project Management Methodologies. ATTASK. Project Management Software | Portfolio and Task Management Software | AtTask, Inc. [online]. 2011 [cit. 201206-17].
Dostupné
z:
http://www.attask.com/topics/project-management-
methodologies [9]
KATOLICKÝ, Arnošt. Critical Chain (CCPM). System Online: S přehledem ve světě informačních technologií [online]. 2001 [cit. 2012-06-17]. Dostupné z: http://www.systemonline.cz/clanky/critical-chain-ccpm.htm
[10]
Agile management. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2006, 14.6.2012 [cit. 2012-06-17]. Dostupné z: http://en.wikipedia.org/wiki/Agile_project_management
[11]
PRINCE2 - PRojects IN Controlled Environments. ITSM PORTAL. ITSM Portal [online].
2006
[cit.
2012-06-17].
Dostupné
z:
http://www.itsmportal.com/frameworks/prince2-projects-controlled-environments [12]
HAUGHEY, Duncan. The History of PRINCE2. Project Smart: Exploring trends and developments in project management today. [online]. ©2000-2012 [cit. 201206-17]. Dostupné z: http://www.projectsmart.co.uk/history-of-prince2.html
[13]
Feasibility study. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2005, 6.12.2012 [cit. 2012-06-17]. Dostupné z: http://en.wikipedia.org/wiki/Feasibility_study
Tištěné monografie [14]
OGC. Managing successful projects with PRINCE2. 5. vyd. London: TSO, 2009. ISBN 978-011-3310-593.
[15]
OGC. Directing successful projects with PRINCE2. London: TSO, 2009. ISBN 978-011-3310-609.
[16]
GRAHAM, Nick. PRINCE2 for dummies. 2. vyd. Chichester (West Sussex, England): Wiley, 2010. ISBN 978-047-0710-258.
[17]
TAYLOR, Sue. PRINCE2 Pocketbook. 4. vyd. London: TSO, 2009. ISBN 978011-3311-996.
88
[18]
STICHTING PARTNERS IN BUSINESS. PRINCE2: 2009 Foundation: Foundation event manual based on PRINCE2 version 2009. Enschede (Netherlands), 2010.
89
6 Seznam obrázků Obrázek 1 - Struktura Metodiky PRINCE2 [1] ..................................................................... 7 Obrázek 2 - Příklad obrázku pouţitého pro zpřehlednění práce (vlastní tvorba) .................. 8 Obrázek 3 - Vývoj metodiky PRINCE2 (vlastní tvorba) .................................................... 16 Obrázek 4 - Pobočky společnosti QUIMPER (převzato z interní prezentace spol. QUIMPER) .......................................................................................................................... 28 Obrázek 5 - QES Program: vazby mezi projektem FIM a ostatními projekty (vlastní tvorba).................................................................................................................................. 31 Obrázek 6 - Fáze ţivotního cyklu projektu (vlastní tvorba) ................................................ 34 Obrázek 7 - Organizace projektu FIM a programu QES (vlastní tvorba) ........................... 38 Obrázek 8 - Milníky programu QES (vlastní tvorba) .......................................................... 48 Obrázek 9 - Milníky projektu FIM (vlastní tvorba) ............................................................ 48 Obrázek 10 - Ukázka "Project products breakdown structure" (vlastní tvorba) ................. 50 Obrázek 11 - Organizace projektu (řídící výbor a projektový manaţer) (vlastní tvorba) ... 51 Obrázek 12 - Milníky výběrového řízení (vlastní tvorba) ................................................... 57 Obrázek 13 - Organizační struktura projektu (vlastní tvorba) ............................................. 59 Obrázek 14 - Přístup k realizaci projektu (návaznosti aktivit mezi QUIMPER a dodavatelem (vlastní tvorba) ............................................................................................... 61 Obrázek 15 - Harmonogram pro etapu IV (vlastní tvorba) ................. Chyba! Záložka není definována.
90
7 Seznam tabulek Tabulka 1 - Geografický rozsah projektů programu QES ................................................... 31 Tabulka 2 - Přehled počtu zaměstnanců v jednotlivých pobočkách skupiny QUIMPER ... 32 Tabulka 3 - Přehled poţadavků pro FIM řešení .................................................................. 43 Tabulka 4 - Rozsah projektu FIM pro jednotlivé pobočky ................................................. 47 Tabulka 5 - Fáze dodávek pro řešení projektu FIM dodaného externím dodavatelem ....... 49 Tabulka 6 - Ukázka definice produktu projektu .................................................................. 51 Tabulka 7 - Přehled zdrojů potřebných pro etapu II a II ..................................................... 60 Tabulka 8 - Ukázka akceptačních kritérií ............................................................................ 62 Tabulka 9 - Kapacity potřebné pro realizaci etapy IV......................................................... 67 Tabulka 10 - Přehled poţadavků na změnu a jejich stav ..................................................... 78 Tabulka 11 - Vyhodnocení nákladů na projekt (etapa II – IV) ........................................... 79 Tabulka 12 - Porovnání původního a reálného harmonogramu projektu (etapa II – IV) .... 81
91
8 Slovník pojmů Business case Change Change management Continued business justification Controlling a stage Defined roles and responsibilities Directing a project Executive Final delivery stage Focus on product Initiating a project Issue register Learn from experience Lessons log Manage by exceptions Manage by stages Managing a stage boundary Managing product delivery Organization Plans Pre-project Progress Project approach Project initiation Project Lifecycle Project Manager Project mandate Project products breakdown Project scope Project Support Quality Risk Risks register Senior Supplier Senior User Stage plan Starting up a project Subsequent delivery stages Work package
Obchodní případ Změna Řízení změn Neustálé obchodní opodstatnění Řízení a kontrola průběhu etapy Definované role a zodpovědnosti Směrování projektu Sponzor projektu Fáze závěrečné dodávky projektu Zaměření se na produkt Nastavení projektu Registr otevřených bodů Učení se ze zkušeností Registr ponaučení Řídit na základě výjimek Řídit po etapách Řízení přechodu do další etapy projektu Řízení dodávky produktů projektu Funkční organizace projektu Plány Období před zahájením projektu Vývoj Způsob dosaţení cílů projektu Nastavení projektu Ţivotní cyklus projektu Manaţer projektu Mandát / charta projektu Rozpad produktů projektu Rozsah projektu Podpora projektu Kvalita Riziko Registr rizik Hlavní dodavatel Hlavní uţivatel Plán etapy Zahájení projektu Etapy dílčích dodávek Balíček práce 92
9 Seznam příloh Příloha A - Původní harmonogram etap projektu realizovaných společně s Dodavatelem Příloha B - Ukázka ze zápisu z týdenní schůzky ("Weekly status meeting minutes") Příloha C - Ukázka týdenního reportu ("Project hightlight") Příloha D - Ukázka registru otevřených bodů ("Issue register") Příloha E - Registr rizik ("Risk register") Příloha F - Ukázka formuláře pro poţadavek na změnu ("Change Request Form") Příloha G- Harmonogram pro etapu IV
93
Příloha A Úkol
Trvání
Konec
12-09-11 8:00 12-09-11 8:00 12-09-11 8:00 12-09-11 8:00 15-09-11 8:00 19-09-11 8:00 19-09-11 8:00 19-09-11 8:00 20-09-11 8:00 28-09-11 8:00 06-10-11 8:00 10-10-11 8:00 30-09-11 8:00 30-09-11 8:00 04-10-11 8:00 15-11-11 8:00 15-11-11 8:00 21-09-11 8:00 21-09-11 8:00 21-09-11 8:00 23-09-11 8:00 04-10-11 8:00 06-10-11 8:00 18-10-11 8:00
20-03-12 17:00 13-01-12 17:00 16-09-11 17:00 14-09-11 17:00 16-09-11 17:00 18-11-11 17:00 11-10-11 17:00 19-09-11 17:00 20-09-11 17:00 29-09-11 17:00 07-10-11 17:00 11-10-11 17:00 05-10-11 17:00 03-10-11 17:00 05-10-11 17:00 18-11-11 17:00 18-11-11 17:00 27-09-11 17:00 07-10-11 17:00 22-09-11 17:00 27-09-11 17:00 05-10-11 17:00 07-10-11 17:00 24-11-11 17:00
10 days
18-10-11 8:00
31-10-11 17:00
7
D
3 days
01-11-11
03-11-11
25
Q
FIM (FIM) Project
137 days
Stage II
90 days
Testing environment setup
5 days
Servers preparation (test and prod environment) Installation of test environment
3 days 2 days
Specifications (Stage II)
45 days
Specifications - batch I
17 days
PRA data sources
1 day
PAR data sources
1 day
CME export
2 days
Odigo export
2 days
Gedeon export
2 days
Specifications - batch II
4 days
DWH export
2 days
REC (rec. tool) export
2 days
Specifications - batch III
4 days
AD and self services portal (conf. screens)
4 days
Data views creation
5 days
Solution design
13 days
DataFlow Concept
2 days
Metadirecory design
3 days
DataFlow Model
2 days
Design synchronization rules
2 days
Delivery I - Export files Research configuration for export to CSV for applications ODIGO, CME, GEDEON in test env. Testing - export files CME,
Předch ůdce
Počátek
28 days
Zdroj
Q 4
D
Q Q Q Q Q
Q Q
Q 8,9
Q
8,9
D
20
D
21
D
22
D
19
Odigo, Gedeon Research configuration for export to CSV for applications DWH, REC in test environment Testing - export files for REC, DWH Delivery II - AD connection and self services portal Research configuration for export to Active Directory and self services in test environment
7 days 2 days 15 days 12 days
8:00
17:00
14-11-11 8:00
22-11-11 17:00
23-11-11 8:00 24-11-11 8:00
24-11-11 17:00 14-12-11 17:00
24-11-11 8:00
09-12-11 17:00
12-12-11 8:00 03-01-12 8:00 05-01-12 8:00
14-12-11 17:00 04-01-12 17:00 09-01-12 17:00
13,19
D
27
Q
D
Testing
3 days
Installation of production environment
2 days
Export files I in production
3 days
Export to CSV for applications ODIGO, CME, GEDEON in production environment
2 days
05-01-12 8:00
06-01-12 17:00
26
D
Testing in production
1 day
09-01-12 8:00
09-01-12 17:00
34
Q
1MD Training basic functionalities + 1 MD preparation
2 days
10-01-12 8:00
13-01-12 17:00
D
06-01-12 8:00 06-01-12 8:00 11-01-12 8:00
20-03-12 17:00 17-01-12 17:00 13-01-12 17:00
Q
2 days
11-01-12 8:00
12-01-12 17:00
28
D
1 day
13-01-12 8:00
13-01-12 17:00
40
Q
6 days
16-01-12 8:00
23-01-12 17:00
29
5 days
16-01-12 8:00
20-01-12 17:00
31
D
23-01-12 8:00 23-01-12 8:00
23-01-12 17:00 06-02-12 17:00
43
Q
8 days
23-01-12 8:00
01-02-12 17:00
3 days
02-02-12 8:00
06-02-12 17:00
Stage III
53 days
Specifications batch IV - User lifecycle
6 days
Export files II in production
3 days
Export to CSV for applications Group Datawarehouse, Recording tool in production environment Testing of export files in production AD connection and self services portal in production Export to Active Directory and running self services in production environment Testing in production Delivery III - user lifecycle (test) Research configuration user lifecycle and revision history of changes in test environment Testing
1 day 11 days
30
Q D
39 D 46
Q
User lifecycle in production Running user lifecycle and revision history of changes in production environment Testing user lifyecyle in prodution Documentation
3 days
21-02-12 8:00
23-02-12 17:00
2 days
21-02-12 8:00
22-02-12 17:00
23-02-12 8:00 28-02-12 8:00
23-02-12 17:00 06-03-12 17:00
1 day 6 days
45 D 49 D
2MD Training FIM 14-03-12 20-03-12 Administrators + 3MD 5 days D 8:00 17:00 preparation Příloha A - Původní harmonogram etap projektu realizovaných společně s Dodavatelem
Příloha B
Příloha B - Ukázka ze zápisu z týdenní schůzky ("Weekly status meeting minutes")
Příloha C
Příloha C - Ukázka týdenního reportu ("Project hightlight")
Příloha D
Příloha D - Ukázka registru otevřených bodů ("Issue register")
Příloha E
Příloha E - Registr rizik ("Risk register")
Příloha F
Příloha F - Ukázka formuláře pro požadavek na změnu ("Change Request Form")
Příloha G
Příloha G- Harmonogram pro etapu IV
