Bod 6.2: Správné nastavení harmonogramu projektu
Často se projektový manažer setká s komplexními projekty. U velkých a komplexních projektu je nutné, aby prvotní harmonogram projektu byl od začátku nastaven správně. Zde se setkáváme často s chybami, které vznikají z nezahrnutí všech faktorů a fází projektu.
Opět doporučením je poskytnout šablonu takového harmonogramu, který urči hlavní fáze projektu a pomůže projekt lépe řídit.
55
Obrázek 7 Vzor nastavení harmonogramu projektu
Na Obrázku 7 je zobrazena navrhovaná struktura pro harmonogram projektu. Jednotlivé termíny projektu jsou zaneseny do tří oblastí. Analýza, vývoj (aplikační analýza + vývoj), testy. Tyto jednotlivé oblasti jsou sice navrženy dle vodopádového modelu, nicméně mnohdy se tím projektový manažeři zapomínají řídit. Co se týče jednotlivých sloupců, tak:
1. Kategorie – pokud se jedná o komplexní projekt, pak nestačí mít rozpadlé
jednotlivé části dodávky do oblastí, potřebujeme mít úroveň, která je nad oblastmi a která spojuje jednotlivé, spolu související, oblasti do jednoho celku. Je to nutné z mnoha důvodu, ať už reporting, nebo přehlednost celkového harmonogramu projektu.
2. ID – toto pole je doporučováno opět pro komplexní projekty. Lépe se následně dohledávají jednotlivé oblasti dle filtrování. Je potřeba, aby projektový manažer myslela na to, že jednotlivý členové projektu si mohou a mnohdy i vedou své vlastní tabulky, ale vždy je potřeba mít společně definované názvy a klíče jednotlivých dodávek. Toto pole tomu pomáhá.
3. Název oblasti – je důležité vždy zvolit jednoduchý název oblasti, který se pak používá při všech reportech a při reportování ostatních členů projektu
projektovému manažerovi.
4. Epic – jedná se o terminologii JIRY, jinak řečeno, jedná se o interní identifikaci dodávané práce v rámci jednoho systému, případně útvaru.
5. Systém – Zde se již jedná o konkrétní systém, který uvádíme. Opět v běhu projektu je tento údaj vždy potřebný a mnohdy se k němu vracíme ve všech fázích dodávky.
6. Release – tento údaj je opět potřeba při větším projektu. Pokud se jedná o například roční projekt, pak je nutné, aby v harmonogramu bylo jasně uvedeno, kdy
jednotlivé dodávky budou implementovány. V ročním projektu se totiž setkáme až se čtyřmi releasy (JR, LR, PR, ZR).
7. Stav – tento údaj se vyskytuje ve všech fázích. Může se jednat o tyto stavy:
a. Not started – tento stav znamená, že v rámci dané fáze (analýza, vývoj, testy) se ještě na práci nezačalo dělat
b. in-process – znamená, že momentálně běží práce
c. on-hold – tento stav se udává v momentě, kdy je dodávka pozdržena či pozastavena z nějakého důvodu
d. done – dodávka byla v rámci fáze zrealizována
8. Plánovaný termín konec – důležitost této informace si mnohdy projektový manažer neuvědomuje. Každopádně datum plánovaného termínu konce je důležitý, jelikož
56
nám ukazuje deltu změny mezi plánovaným termínem a reálným termínem dodávky, ať už analýzy, vývoje nebo testů. Je potřeba vždy myslet na tři zásadní pilíře projektu, kterými je projekt omezený a to časem, cílem a rozpočtem. Toto pole nás tedy vždy usměrňuje v držení se časové osy.
9. Finální termín konec – tento datum na rozdíl od předchozího datumu nám říká termín finálního konce dodávky. V rámci reportu projektovému manažerovi od ostatních členů projektu je zásadní datumy reportovat a úlohou projektového manažera je vždy se na datumy ptát.
10. Celkem – tento údaj neukazuje nic jiného než procentuální vyčíslení dokončenosti v jednotlivých úsecích dodávky. Je na projektovém manažerovi, jak si procenta nastaví z pohledu naplňování, ale vždy musí umět odůvodnit při reportech, proč je daná číst splněna na XY % a co ještě zbývá.
11. Předáno na systém – tento údaj figuruje na rozmezí mezi analýzou a reálným vývojem. Údaj pomáhá projektovému manažerovi argumentovat při diskusích s některým ze systémů a mít vždy po ruce fakta toho, kdy se na daný systém analýza z pohledu projektu předala a kdy ji naopak systém převzal. Slouží jako směrodatný údaj mezi projektovým manažerem a jednotlivými systémy.
12. SPOC – SPOC neboli Single Point of Contact. Jedná se vždy o konkrétní jméno v rámci testů. Každý systém banky musí splnit testy na své straně a projektový manažer musí vědět, koho se případně ptát, pokud dochází ke zpoždění či k jiným problémům například v rámci testovacích scénářů.
13. E2E test – v tomto případě je opět uvedeno konkrétní jméno člena týmu, který řeší a zajišťuje test v rámci dané oblasti od začátku do konce. Má na starosti správnost E2E testu a projektový manažer má jasně dané, s kým se ohledně testů může v rámci dané oblasti bavit. Zabrání to časové ztrátě, ke které dochází v momentě, kdy projektový manažer zjišťuje, kdo danou oblast testuje.
14. Releas – tento údaj projektovému manažerovi vždy připomíná striktní datum bankovního releasu, který nemůže překročit. Jedná se o jeden ze záchytných bodů projektu a pomáhá celému týmu mít přehled.
6.7 Sledování a kontrola projektu
Cílem je poskytnout projektovému manažerovi nástroje na monitorování a vyhodnocování postupu a výkonnosti projektu.
Zahrnuje tyto procesy: sledování a kontrola projektových prací (Monitor and Control Project Work) a cílem procesu je sledování, revize a regulace postupu a výkonnosti projektu po celou dobu trvání projektu za účelem dosažení cílů definovaných v projektovém plánu.
Vstupy: Výstupy:
57
• Schválené požadavky na změnu
• Aktualizovaný projektový plán
• Aktualizovaná projektová dokumentace (např. předpovědi, zprávy o výkonnosti, seznam problémů – issue log apod.)
Tabulka 16 Vstupy a výstupy v rámci Sledování a kontroly projektových prací
Řízení změn (Change Request Management), kdy cílem procesu řízení změn je jednotně evidovat a vyhodnocovat všechny požadované změny a implementovat pouze schválené změny s jasně definovanými dopady do projektu.
Vstupy: Výstupy:
• Projektový plán
• Business case
• Změnový list projektu
společně se zápisem o schválení změny vč. schválení změny relevantním schvalovacím orgánem
• Aktualizovaný Projektový plán
• Aktualizovaný Business case
• Aktualizovaná Hodnotící kritéria projektu
• Aktualizované Klíčové ukazatele projektu (KGI)
Tabulka 17 Vstupy a výstupy v rámci Řízení změn
Kontrola rozsahu, harmonogramu a rozpočtu (Control Scope, Schedule and Budget) kdy cílem procesu je ujištění o plnění projektových aktivit v souladu se schváleným rozsahem, harmonogramem a rozpočtem a na základě pravidelných reportů o aktuálním plnění aktivit, odhadu pracnosti zbývajících aktivit nebo obsahu schválených změnových požadavků zajistit případné přeplánování.
Vstupy: Výstupy:
• Projektový plán vč. business case
• Reporty plnění jednotlivých projektových aktivit
• Informace o stavu a výkonnosti projektu
• Schválený změnový požadavek
• Aktualizovaný projektový plán (je-li potřeba)
Tabulka 18 Vstupy a výstupy v rámci Kontrola rozsahu, harmonogramu a rozpočtu
Kontroly kvality řízení projektu (Perform Quality Assurance) je proces, jehož cílem je monitorovat kvalitu jednotlivých procesů řízení projektu a jejich zlepšování a kontrola kvality výstupů projektu je proces, jehož cílem je ujištění, že kvalita výstupů odpovídá hodnotám definovaným v plánu kvality a nastavené standardy a požadavky na kvalitu jsou dodržovány a případně jsou přijata nápravná opatření.
58
Vstupy: Výstupy:
• Plán řízení kvality projektu
• Informace o výsledcích kontroly kvality projektových výstupů na projektu
• Informace o aktuálním stavu projektu (např. zápisy ze status meetingů, dokumentace z řídícího výboru)
• Projektový plán
• Zprávy o výsledcích kontroly procesů projektového řízení v projektu
• Hodnocení projektových výstupů s ohledem na stanovené
parametry kvality/akceptační kritéria
Tabulka 19 Vstupy a výstupy v rámci Kontroly kvality řízení projektu
Akceptace projektových výstupů (Verify Scope/Customer Acceptance), kdy cílem procesu je dosažení akceptace výstupů projektu obchodními vlastníky a sponzorem.
Vstupy: Výstupy:
• Projektový plán
• Detailní popis požadavků
• Výstupy projektu připravené k akceptaci
• Akceptační protokol
• Změnové požadavky
• Aktualizace projektové dokumentace
Tabulka 20 Vstupy a výstupy v rámci Akceptace projektových výstupů
Vyhodnocování / aktualizace rizik (Monitor and Control Risks) a cílem procesu je implementace opatření k omezení rizik, sledování vývoje již identifikovaných rizik a průběžná identifikace a vyhodnocování rizik nově vzniklých a přijímání opatření k jejich omezení. pokud je v projektu nastaveno
• Směrnice a platné předpisy BANK MONEY a.s.
• Aktualizovaná Analýza rizik, která obsahuje identifikovaná a kvantifikovaná rizika a návrh opatření k jejich omezení
• Aktualizovaný Plán řízení rizik
• Aktualizovaný Projektový plán
• Požadavky na změnu
Tabulka 21 Vstupy a výstupy v rámci Vyhodnocování a aktualizace rizik
Schvalování a kontrola nákupu (Monitor and Control Procurement), kdy cílem procesu je zajistit, aby BANK MONEY a.s. jako odběratel měla zajištěno splnění dohodnutých podmínek ve smlouvě a aby byly ochráněny její právní nároky.
Vstupy: Výstupy:
59
• Dokumenty týkající se procesů nákupu (SoW)
• Uzavřené smlouvy
• Plán nákupu projektu
• Změnové listy
• Ostatní relevantní dokumenty (například stav jednotlivých dodávek dodavatele)
• Aktualizované dokumenty týkající se procesů nákupu (včetně související dokumentace – poznámky a zápisy z jednání s dodavateli)
• Změnové listy, je-li potřeba
• Aktualizovaný Projektový plán
Tabulka 22 Vstupy a výstupy v rámci Schvalování a kontroly nákupu
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