6.7.1 Návrh na zlepšení
Opět zde autorka promítne body, které vnímá jako problematické v rámci této fáze a na které je potřeba projektovému manažerovi se zaměřit.
Bod 7.1: Správné sledování a kontrola projektových prací
Již bylo v práci promítnuto, jak správně sestavit harmonogram. Jedná se ale o první krok k tomu, aby se projekt dal správně řídit. Dodržování tohoto harmonogramu, a obecně sledování a kontrola všech projektových prací, je mnohdy přehlíženo. Často projektový manažeři spoléhají na to, že všechny termíny mohou udržet v hlavě, a hlavně že všichni členové týmu jsou na tolik poctivý, aby tyto termíny dodržovali. Není tomu tak.
Je potřeba již při zahájení projektu nastavit jednoznačně jasnou spolupráci v týmu. Pomoci k tomu může kick – off schůzka na které projektový manažer představí očekávanou
spolupráci v týmu a jasně vykomunikuje na všechny členy týmu o dodržování těchto pravidel. Nejlepším možným řešením je připravit prezentaci dostupnou pro všechny členy týmu, ve které bude mít tyto části:
1. Shrnutí a cíle projektu
a. Proč a za jakým účelem tento projekt děláme.
b. V čem je jeho přínos.
c. V jakém stavu se momentálně nacházíme a jakého stavu chceme tímto projektem dosáhnout.
d. Časování projektu 2. Organizační struktura projektu
a. Projektové role: projektový manažer, delivery manažer, integrační manažer, change manažer, atd.
3. Jak budeme pracovat – Pravidla
U tohoto bodu je potřeba se zastavit, jelikož se jedná právě o autorkou vytyčený problém, kdy není jasné, jak se projektové práce a úkoly budou sledovat. Autorka navrhuje zahrnout tyto slidy do prezentace:
60
Obrázek 8 Projektová pravidla
Na Obrázku 8 je vidět, že je potřeba jasně definovat, kdy a v jakém intervalu se budou konat projektové schůzky. Dále jaká je úroveň eskalace a za kým je potřeba jít v případě jednotlivých eskalačních úrovní. Jaký je rozpočet projektu a jaká jsou pravidla tohoto rozpočtu – často se odkazuje na jiný dokument, který vzniká v rámci schválení projektu a ve kterém je vidět rozpis rozpočtu. Dále projektový tým musí vědět, kde dohledá veškerou projektovou dokumentaci a zároveň i celkový plán projektu.
V případě velkých projektů je jasné, že schůzek v rámci tohoto projektu nebude málo. Na Obrázku 9 je vidět, o jaké typy schůzek na pravidelné bázi se může jednat a zároveň je to přehledně zobrazeno na jednom místě pro pochopení všech členů týmu.
Čísla za jednotlivými schůzkami znamenají místnosti, kde se schůzky konají. Tyto schůzky jsou zároveň promítnuty do společného kalendáře, který je sdílený pro všechny členy týmu.
Obrázek 9 Schůzky kalendář
61
Status Projektu – jedná se o hlavní schůzku všech participujících členů týmu v rámci organizační struktury. Na této schůzce se vždy minimálně procházejí oblasti: analýza, vývoj, testy
V rámci této schůzky vznikají hlavní zápisy pro projekt. Určitě je doporučené sepisovat zápisy ze všech schůzek, každopádně zápis z tohoto jednání je obzvlášť důležitý, jelikož z tohoto zápisu plynou hlavní úkoly, které se následně musí splnit a všichni členové projektu se hlavně budou v rámci zbytku týdne odkazovat na tento zápis.
Bod 7.2: Návrh struktury zápisu z projektových schůzek
Zde, na Obrázku 10, autorka navrhuje doporučenou strukturu takových zápisů. Číslo zápisu je nutné pro následnou identifikaci, například úkoly z dané schůzky se zapisují do seznamu úkolu způsobem: 1/38, což by znamenalo, že se jedná o první úkol v rámci schůzky číslo 38 a daný úkol lze dohledat jak v seznamu úkolů (o tomto seznamu bude pojednáváno dále), tak i v rámci zápisu, který pasuje na tuto schůzku a je vedený pod identifikačním číslem 38. Dále se jedná o pole, jejichž potřeba je patrná z názvu. Co se týče agendy, zde je navržena základní agenda takových projektových schůzek. Dále v rámci jednotlivých sloupců lze každé pole rozdělovat dle jejich informací, které nesou:
a. Information – obecná informace,
b. Issues – vniklý problém, který je následně zanesen též do příslušného Issue logu,
c. Task – úkol, též zaneseno do seznamu úkolů a
d. Decision – neboli rozhodnutí, které na schůzce jednoznačně padlo.
Další sloupec nese název oblasti/ řešeného problému a tato informace je v následujícím sloupci detailněji popsána. Předposlední sloupec pak slouží pro identifikaci osoby, která buď danou informaci říká, nebo je mu přiřazen úkol. Poslední sloupec slouží pro případné komentáře.
Obrázek 10 Vzor struktury zápisu
1. Issue, Risk Projektu – jedná se o schůzku vybraných členů týmu, kde se probírají aktuální problémy projektu a rizika a jejich řešení. Tím se dostáváme k dalšímu problémovému bodu a to:
62 Bod 7.3: Správné vedení rizik projektu
Zde, na Obrázku 11, autorka krátce navrhne strukturu zanesení rizik projektu. Rizika projektu a jejich vyčíslení je samostatná a dost obsáhlá oblast. Autorka nebude rozepisovat, jak se rizika měří a vyčíslují, ale úkolem je prakticky ukázat, jak takové vedení rizik může vypadat v rámci projektové dokumentace.
Obrázek 11 Vzor vedení rizik
Zde vidíme, že každé riziko je identifikováno číslem. Dále je vepsána oblast, které se riziko týká. Následně samotný popis rizika a skoré v rámci pravděpodobnosti jeho naplnění a skoré dopadu tohoto rizika na projekt. Závažnost je pan násobek těchto dvou čísel a pojednává o míře celkového dopadu tohoto rizika na samotný projekt. Podle tohoto čísla lze filtrovat rizika od nejvíce závažných po méně závažné a řešit je dle této míry.
Opatřením se navrhují kroky, které se udělají pro minimalizaci tohoto rizika. Zde je nutné dodat, že historie komentářů se nemaže, ale ponechává a nová informace se vždy zapisuje jako první s datumem zápisu informace a iniciálami osoby, která informaci zapisuje. Tato forma komentářů platí nejen pro identifikaci rizik, ale i pro veškerou dokumentaci, kde se vyskytují časté komentáře.
V rámci dalších buněk se zapisuje zodpovědný řešitel rizika, stav, vytvoření a termín, ke kterému se musí riziko minimalizovat.
2. PM/Asistent sladění – jedná se o doporučenou schůzku, kdy projektový manažer spolu s asistentem projektu procházejí aktuální úkoly, které vzešli z pravidelných schůzek a které jsou vedeny v projektových registrech (doporučená struktura Projektových registrů je v následujících odstavcích lépe rozebrána) a jejich aktualizace případně upomenutí řešitelů na tyto úkoly.
3. Change management – z názvu je tedy patrné, že se jedná o pravidelnou schůzku, která se koná ohledně změnových požadavků na projektu.
4. Business Analýza status – jedná se pravidelnou schůzku hlavního analytika a jím vybraných účastníků. Často se jedná o analytiky jednotlivých oblastí projektu, kteří hlavnímu analytikovi reportují stav svých analýz a případných problémů.
5. Komunikace – u velkých projektů je doporučené jednotlivé úspěchy komunikovat mimo projekt. Komunikace mimo projekt slouží i pro to, aby i jiní v bance věděli, co se na projektu odehrává a jaké dopady to má na zbytek banky.
Hlavním důležitým dokumentem projektu, který byl již několikrát zmíněn, je dokument Projektové registry. Co by měl tento dokument obsahovat je vidět na Obrázku 12 a 13.
Jedná se o dokument, ve kterém všichni členové týmu najdou potřebné informace a odkazy
63
na jednotlivé dokumenty. Přínosem tohoto dokumentu je, že se jedná o jedno místo, ze kterého se členové projektu mohou dostat k potřebným informacím. Tento dokument musí být často aktualizován, ať už aktualizace jednotlivých odkazů nebo aktualizace úkolů.
Zajistit tuto aktualizaci musí projektový manažer (ať už sám, nebo přes asistenta projektu).
Součástí tohoto dokumentu jsou i archivní úkoly, issues, rizika apod. Nesmíme zapomínat, že nelze splněné úkoly a jiné práce pouze smazat, ale je potřeba vše evidovat pro případ, že bude potřeba zpětně některé informace a jejich posloupnost dohledat.
Obrázek 12 Projektové registry 1
Obrázek 13 Projektové registry 2
Bod 7.4: Správná komunikace a nastavení Demand a Change procesu (Řízení požadavků a změn)
Dále, dle Obrázku 14, se projektovému manažerovi doporučuje jednoznačně říct, jakých pravidel se v rámci Demand a Change procesu má projekt řídit. Je správné, aby všechny
64
požadavky byly zadány v relevantním na to nástroji (často se ve společnostech využívá JIRA). Zároveň je doporučením vždy nastavit schůzku týmu, která se bude konat před CAC termínem (Change Advisory Committee – jedná se o celobankovní schůzku, kde se probírají jednotlivé požadavky, které se budou realizovat v daném releasu)
Obrázek 14 Demand, change management
Co se týče change management procesu, zde je nejlepším doporučením pro projektového manažera se podívat do některé z literatury, jak je potřeba změny řídit. Pro projektový tým je ale opět dobré znát hlavní fakta, které jsou v rámci change managementu důležitá.
Bod 7.5: Správné vedení a kontrola rozpočtu projektu v jeho průběhu
V návrhu na zlepšení v rámci fáze Realizace projektu bylo navrženo, jak sestavit správně business case. V průběhu projektu je velice důležité, aby se finance daného projektu udržely na 0 Kč. Nesmí dojít ani k jeho přečerpání ani k jeho nedočerpání, jelikož v obou případech projektového manažera čeká vysvětlení, proč k tomu došlo.
Aby se dařilo projektovému manažerovi udržet finance projektu pod kontrolu, je na Obrázku 15 zobrazen jeden ze způsobů sledování rozpočtu projektu. Vidíme v prvním sloupci jednotlivé oblasti (které autorka podrobněji rozebírala v návrhu na zlepšení v rámci plánovací fáze). Dále je pro přehlednost uvedeno, zda se jedná o OPEX či CAPEX (OX – provozní náklady, CX – Kapitálové náklady). Následně, ve sloupci tři, je rozdělen
položkově rozpočet projektu, který se schválil v rámci exekuční fáze. Ve sloupcích čtyři a pět je vidět reálné čerpání a kolik zbývá financí v rámci jednotlivých oblastí. Sloupec šest definuje předpoklad k uvedenému datumu. Je to důležité, jelikož je jasné, že schválení rozpočtu v rámci jednotlivých položek v exekuční fázi se může v průběhu projektu měnit.
U některých položek může docházet k jejich navýšení u jiných opět ke snížení – tento fakt je následně vyobrazen ve sloupci sedm, kde vidíme zeleně podbarvené ty položky, kde došlo k úspoře a červeně položky, kde došlo naopak k přečerpání v rámci oblasti. Důležité však je, aby celkový rozpočet projektu byl dodržen. Pokud tedy projektový manažer vidí, že v rámci některé oblasti dochází k přečerpání, musí zahájit vyjednávání o úspoře v oblasti jiné. Rozhodně může dojít i k takovému stavu, kdy přečerpání u oblastí je vyšší
65
než rozpočet, pak je potřeba žádat příslušné schvalovací orgány o navýšení rozpočtu. Jedná se o samostatný definovaný proces v rámci banky.
Obrázek 15 Způsob sledování rozpočtu – úroveň 1
Ukázali jsme si tedy, jak v rámci jedné tabulky zanést všechny potřebné údaje na jedno místo, které jsou pro projektového manažera z pohledu financí důležité. Pod touto tabulkou by se však měla skrývat další tabulka, která ukazuje položkový rozpad dle jednotlivých požadavků. Z této tabulky se následně čerpají data tabulky na Obrázku 15 (doporučené je používat vzorečky excelu).
Tato tabulka úrovně dvě je vyobrazena na Obrázku 16. První sloupec promítá identifikaci požadavku v rámci JIRA. Druhý sloupec ukazuje zodpovědnou osobu za daný požadavek a osobu, která reálně finance na požadavek požaduje. Zkratka SoM v tomto případě znamená Solution Manager a často je to právě tato osoba, která požadavek zaštiťuje. Třetí sloupec promítá číslo v rámci finanční aplikace. Toto číslo slouží jako identifikátor k dohledání objednávky v rámci finančního systému. Často slouží ke zpětným dohledávkám, a i pro komunikaci s finančním partnerem projektu. Zároveň tento sloupec definuje, jaké
požadavky byly již objednány a jaké požadavky jsou zatím pouze požadovány žadatelem, neboli zadané v JIRA. Ve chvíli, kdy políčko požadavku je prázdné, znamená to, že
požadavek je zatím zadaný pouze v JIRA a finančně není ještě objednaný. Ve chvíli, kdy je již zde číslo, pak je již požadavek objednaný v rámci finančního systému. Pro
projektového manažera je toto důležité, aby viděl, kolik je předpoklad a kolik je reálné čerpání. Zároveň ke konci projektu je důležité, aby byly všechny plánované objednávky vystaveny a vyfakturovány. Tudíž je potřeba hlídat, aby docházelo k pravidelnému objednávání. Doporučením je vždy začátkem releasu dosáhnout toho, aby se plánované požadavky pro daný release objednaly. Na konci releasu je doporučené odpracované požadavky zkontrolovat a řádně vyfakturovat (nesmí chybět akceptační protokol).
Čtvrtý sloupec definuje release požadavku. V následujícím sloupci je pak samotná částka.
Šestý sloupec slouží pro název požadavku. Předposlední sloupec definuje projekt, tento sloupec samo sebou není požadovaný, pokud projektový manažer má na starosti pouze jeden projekt. Tento sloupec slouží pro vedení financí v rámci programu, kdy součástí programu je více projektů. Poslední sloupec definuje aplikaci.
Tato tabulka umožňuje pohodlně filtrovat dle požadovaných údajů. Například projektový manažer je schopen na jeden klik vyčíslit, kolik ho stály jednotlivé releasy, nebo kolik bylo čerpáno v rámci jednotlivých aplikací apod.
66
Obrázek 16 Způsob sledování rozpočtu – úroveň 2
Bod 7.6: Správné nastavení business – rolloutu projektu
Již byl business – rollout zmíněn v rámci fáze Plánování. Připomeneme si, že tato aktivita v sobě obnáší přípravu příslušných business útvarů k novému/změněnému řešení. Skoro vždy změna v systémech za sebou nese i změny v businessu banky a tyto změny je potřeba též brát v potaz a businessově s tím pracovat.
Autorka vypozorovala v praxi, že tato oblast je často opomíjena a málo kdy řešena důkladně. Nejčastěji se setkáváme s přístupem, kdy projektový manažer jaksi spoléhá na to, že předávka businessu bude zahájena až po realizaci a řeší tuto záležitost na poslední chvíli, kdy již projekt je ve fázi uzavírání. Tento aspekt nese za následek to, že business například nemusí být zcela spokojený a může nové řešení zcela odmítnout z relevantních důvodů.
Aby k tomuto nedocházelo, autorka navrhuje návrh na zlepšení v dané oblasti následujícím způsobem. Každopádně tento návrh platí pouze pro projekty, které obsahují business dodávku.
V rámci projektu je vytvořen samostatný stream business – rolloutu, který je pod vedením Busrollout team leadra. Za každý uživatelský útvar, který používá staré řešení, které je projektem nahrazováno, je nominován SPOC. Tento SPOC si následně v rámci svého útvaru určí skupinu spolupracovníků Superusers. Jádro týmu doplňuje Change expert.
Obrázek 17 Organizační struktura business – rolloutu
Každý člen týmu má svojí roli a odpovědnost.
Change expert
67
• Primární nositelé know-how nového řešení
• Mapují business procesy a definují změny v procesech
• Vysvětlují tyto změny dotčeným útvarům (SPOCs a Superusers)
• Pomáhají SPOCům a Superuserům s implementaci změn do banky
• Pomáhají s přípravou testovacích scénářů (business testy)
• Pomáhají s přípravou školení SPOCs
• Hlavní „spojky“ mezi projektem a bankou
• Identifikují změny v oblastí jejich kompetence
• Zajišťují analýzu dopadu a přípravu implementace změn
• Zajišťují implementaci těchto změn
• Nominují Superusery a organizují jejích práci
• Mají primární zodpovědnost za realizaci změn v bance
• Mají zodpovědnost za naplánování a zajištění proškolení uživatelů v dané oblasti Superusers
• První z uživatelů, kteří získají know how nového řešení
• Podílejí se na testech a pilotu a poskytují zpětnou vazbu IT
• „Baby – sitting“ a „Help desk“ pro uživatelé z jejich oblasti
• školení uživatelů Uživatelé nového řešení
• Všichni uživatelé nového řešení ve všech útvarech
Obrázek 18 Role a odpovědnosti členů business rolloutu
Pro lepší pochopení případných změn a orientaci v dokumentech business analýz a návrhů řešení na úrovni aplikací, budou pro každý releas tyto změny představeny SPOCům formou prezentací vždy po finalizaci uvedených dokumentů.
Následně SPOC za základě těchto vstupů zpracuje za svůj útvar plán business – rolloutu včetně časového plánu jednotlivých částí identifikace, analýzy dopadů, přípravy
implementace a termínu nasazení změny (uvedení v platnost). Na základě těchto plánů SPOC zajistí provedení naplánované aktivity v daném čase a vytvoření a zpracování požadovaných výstupů, které jsou vydefinovány.
68
Výstup za každý útvar je ve formě tabulky, kde je uveden plán, seznam změn, jejich stav (identifikováno, analýza dopadu, příprava, připraveno k realizaci, storno, pozastaveno), odpovědná osoba, řešitel změny. Za každou analytickou oblast je zpracována tabulka pro příslušný útvar.
Co se týče podpory během pilotu, v průběhu busines – rolloutu a v období po rolloutu, je koncept navržen tak, aby v rámci pilotu a po rolloutu, měl každý koncový uživatel rychle dostupnou podporu, připravenou rychle pomoci, aby nebyla negativně narušena běžná uživatelská činnost.
V rámci podpory bude využita standardní podpora, která je obecně vydefinována, je procesně nastavena pro běžný režim banky, tzn. řešení IT incidentů a problémů v běžném provozu a po releasech. Tuto podporu tvoří Funkční podpora, IT Help Desk a Produktový Help Desk. Tato standardní podpora bude rozšířena následujícím způsobem.
• Pro pobočkovou síť budou tuto zvýšenou podporu vykonávat podpory na pobočkách. Ne všechny pobočky tuto podporu mají vzhledem ke své velikosti, proto bude ještě podpora rozšířena a bude dostupná na více telefonních číslech, než je standard s tím, že pro každou regionální oblast bude přiřazeno konkrétní
telefonní číslo.
• Podpora pro útvary centrály bude zajištěna na místě, tzn. přímo v daném útvaru.
Tuto podporu budou zajišťovat SPOCové a jimi nanominovaní Superuseři, kteří v rámci činnosti Business rolloutu potřebnou znalost k poskytnutí podpory získají.
Obrázek 19 Koncept podpory v rámci Business – rolloutu
6.8 Uzavírání projektu
Cílem procesů Uzavírání projektu je provést všechny aktivity pro formální uzavření a vyhodnocení projektu vč. uzavření smluvních vztahů.
Zahrnuje tyto procesy: vyhodnocení výkonnosti zdrojů (Resource Performance
Appraisal), kdy cílem procesu je vyhodnotit zapojení lidských zdrojů v projektu a formálně jejich zapojení ukončit.
Vstupy: Výstupy:
69
• Plán lidských zdrojů
• Projektový plán
• Členové projektového týmu jsou informováni o naplnění cílů projektu a také o naplnění očekávání
• Liniový manažer získá zpětnou vazbu od projektového manažera na práci jeho podřízených v projektu
• Projekt je zakončen závěrečným setkáním členů projektového týmu