4IT450 CASE - Computer Aided Systems Engineering Závěrečná práce na téma: Řízení projektů metodou PRINCE2 s vazbou na Nástroje CASE

4IT450 CASE - Computer Aided Systems Engineering Závěrečná práce na téma: Řízení projektů metodou PRINCE2 s vazbou na Nástroje CASE

Vypracovaly: Čapková Lenka, Hanusová Lucie, Klápová Nikola, Kulíšková Romana, Peterková Kateřina, Šímová Marie

1

LS 2010/2011

Obsah Obsah ......................................................................................................................................... 2 Seznam použitých obrázků ...................................................................................................... 5 Uvedené tabulky ....................................................................................................................... 6 Úvod ........................................................................................................................................... 7 1.

2.

Nástroje CASE.................................................................................................................. 8 1.1

Historie nástrojů CASE ............................................................................................... 8

1.2

Nástroje CASE ............................................................................................................ 8

1.2.1

Druhy nástrojů CASE........................................................................................... 9

1.2.2

Komponenty nástrojů CASE .............................................................................. 11

1.2.3

Příklad nástroje CASE - QPR ProcessGuide ..................................................... 12

Řízení projektů ............................................................................................................... 17 2.1

Definice slova projekt ................................................................................................ 17

2.2

Vlastnosti projektu ..................................................................................................... 17

2.3

Řízení projektů a jeho cíle ......................................................................................... 17

2.4

Fáze projektu ............................................................................................................. 18

2.4.1

PMBOK .............................................................................................................. 18

2.4.2

PRINCE2 ............................................................................................................ 20

2.4.3

RUP .................................................................................................................... 20

2.5

Metody řízení projektů .............................................................................................. 21

2.5.1 2.6

PMBOK (Project Management Body of Knowledge) ....................................... 22

PRINCE2 (Projects in controlled environment) ........................................................ 23

2.6.1

Metodika EPMS (Equilibrium - Project Management Solutions)...................... 25

3.

Jak souvisí Nástroje CASE s řízením projektů ........................................................... 26

4.

Témata k modifikaci ...................................................................................................... 28 4.1

Business Case ............................................................................................................ 28 2

4.1.1

Průběh Business Case......................................................................................... 29

4.1.2

Definování rolí v Business Case ........................................................................ 30

4.1.3

Ukázky z programu Project in a box .................................................................. 30

4.2

Organizace (Organization) ........................................................................................ 33

4.2.1

Projekt ................................................................................................................ 33

4.2.2

Struktura projektového managementu a její odpovědnosti dle PRINCE2® ...... 34

4.3

Plány (Plans) .............................................................................................................. 36

4.3.1

Plánování ............................................................................................................ 37

4.3.2

Dělení projektu ................................................................................................... 37

4.3.3

Ukázky z programu Project in a box .................................................................. 38

4.4

Pokrok (Progress) ...................................................................................................... 42

4.4.1

Účel .................................................................................................................... 42

4.4.2

Co je to „Progress“? ........................................................................................... 42

4.4.3

Co jsou to „Progress“ kontroly? ......................................................................... 42

4.4.4

Výjimky a odchylky ........................................................................................... 43

4.4.5

PRINCE 2 - koncepce ........................................................................................ 44

4.4.6

Ukázky programu - část „Progress“ ................................................................... 45

4.5

Riziko (Risk).............................................................................................................. 47

4.5.1

Cíl ....................................................................................................................... 47

4.5.2

Co je riziko ......................................................................................................... 47

4.5.3

Co je ohroženo ................................................................................................... 47

4.5.4

Co je řízení rizik ................................................................................................. 47

4.5.5

Projektová rizika ................................................................................................ 48

4.5.6

Rozpoznání rizika ............................................................................................... 49

4.5.7

Vyhodnocení rizika ............................................................................................ 49

4.5.8

Vytvoření rizikových plánů ................................................................................ 49

4.5.9

Sledování a řízení rizika ..................................................................................... 49 3

4.5.10 4.6

Ukázky z programu PROJECT in a box ............................................................ 50

Kvalita (Quality) ........................................................................................................ 53

4.6.1

Účel .................................................................................................................... 53

4.6.2

Co je to kvalita?.................................................................................................. 53

4.6.3

Plánování kvality ................................................................................................ 54

4.6.4

PRINCE2 a přístup ke kvalitě ............................................................................ 55

4.7

Změna (Change) ........................................................................................................ 57

4.7.1

Účel .................................................................................................................... 57

4.7.2

Řízení změn ........................................................................................................ 57

4.7.3

Správa konfigurace ............................................................................................. 58

4.7.4

Issues .................................................................................................................. 58

4.7.5

PRINCE2 a přístup ke změnám ......................................................................... 58

Závěr ........................................................................................................................................ 61 Použité zdroje ......................................................................................................................... 63

4

Seznam použitých obrázků 1 Vzhled programu QPR 2 Vzhled programu QPR 3 Vzhled programu QPR 4 Vzhled programu QPR 5 Životní cyklus projektu metodiky PMBOK podle Widermana 6 Životní cyklus projektu metodiky PMBOK podle Morrise 7 Životní cyklus projektu metodiky PMBOK podle Morrise 8 Průběh projektu z pohledu Business Case 9 Popis dokumentace 10 Celkový pohled na procesy 11 Sedm etap projektu 12 Definování organizace 13 Tvorba plánu 14 Úvodní obrazovka 15 Microsoft Project 16 Microsoft Excel 17 Přidělení rolí 18 Rozpracovanost plánů 19 Grafy 20 Výchozí obrazovka manažerského nástroje sloužícího pro kontrolu projektů 21 Excelový výstup ukazující splnění plánu podle osob v % 22 Excelový výstup pro řízení rizik 23 Analýza a řazení rizika 24 Vyhodnocení rizika 25 Ukázka dashboards 26 Registr rizik 27 Přehled o stavu a plnění projektu 28 Ukázka spravování projektové dokumentace

5

Uvedené tabulky 1 Porovnání metodik Prince2 a PMBOK 2 Odchylky

6

Úvod Semestrální práce se zabývá tématem „Řízení projektů“ a možnou vazbou na „Nástroje CASE“. Na začátku dokumentu jsou vysvětleny základní pojmy týkající se tohoto tématu, tedy co jsou to nástroje CASE, jaké je jejich členění, k čemu se používají a dále jsou vysvětleny pojmy týkající se řízení projektů – co je to projekt, řízení projektů, jaké jsou vlastnosti projektu, jaké existují metody řízení projektu a na jaké fáze se rozpadají, následně jsou tyto metody na základě konkrétních kritérií porovnávány. K bližšímu představení řízení projektu byla vybrána metoda PRINCE2, která je detailně popsána v další části dokumentu, včetně doprovodné ilustrace z programu PROJECT in a box, který přímo podporuje řízení projektu touto metodou. Jako možný nástroj CASE, podporující projektové řízení byl vybrán program QPR od společnosti Software Plc a to z toho důvodu, že kromě snadného modelování procesů a hierarchických struktur umožňuje také funkce podporující sledování projektu a manažerské rozhodování.

7

1. Nástroje CASE V první kapitole se zabýváme vysvětlením toho, co jsou nástroje CASE – jejich historií, druhy i jejich komponentami. Pojem nástroje CASE označuje takovou skupinu nástrojů, která se zaměřuje na podporu vývoje informačních aplikací. CASE je zkratkové slovo složené ze čtyř anglických slov Computer Aided Software Engineering.

1.1 Historie nástrojů CASE Historie těchto nástrojů není jen otázkou nového tisíciletí, ale začala již se vznikem odvětví zvané softwarové inženýrství (kolem roku 1960). Softwarové inženýrství odstartovalo éru systému pro podporu vývoje – zejména softwarů pro analýzu. Mezi první nástroje CASE patřily nástroje, které můžeme nazývat Lower Case. Tyto nástroje jsou dodnes určeny pro fázi implementace např. generování kódu. Původní myšlenka nástrojů CASE byla taková, že už nebude zapotřebí programátorů, čímž bylo míněno to, že CASE nástroj vygeneruje již samotný kód, který nebude potřeba upravovat a rovnou použít. Takováto myšlenka ovšem nenašla své místo ve světě a nástroje CASE se dále vyvíjely. Rozmach zapříčinilo až vytvoření uživatelského rozhraní pro Nástroje CASE kolem roku 1980. Do té doby byly dostupné pouze samostatně malé nástroje, poté bylo možné vše integrovat na univerzální pracovní ploše (History of CASE, 15).

1.2 Nástroje CASE Těchto nástrojů existuje celá řada. Jedná se buď o strukturované anebo objektově orientované metody vývoje podporující určité fáze vývoje, především analýzu a návrh. Jednotlivé nástroje CASE vycházejí z konkrétní metodologie, díky které umožňují materializovat představu o zpracovávaném problému – formou diagramů. Nejčastěji jsou nástroje CASE používány pro datové a funkční modelování. Některé nástroje CASE jsou integrovány do moderních prostředí pro vývoj software (Borland, Oracle). Nástroje CASE jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému, zajišťují sdílení rozpracovaných fragmentů, správu vývoje, sledují konzistenci modelu systému, automatizují některé procesy, hlídají dodržování zvolené metodiky, některé umožňují řízení celého životního cyklu aplikací. 8

Nástroje CASE by měly podporovat komponentové a distribuované aplikace či aplikace založená na webových službách. Podmínkou každého nástroje CASE je splnění obecné podmínky otevřenosti a nezávislosti na hardwaru. Každý nástroj CASE by měl umožňovat podporu požadavků na modelování v reálném čase. Přestože vypadá, že tvorba diagramů v těchto nástrojích je jednoduchá, opak je pravdou. Vyžaduje vysokou znalost a profesionálnost tvůrce modelů i těch, kdo nástroj používají. Druhým předpokladem úspěchu je vhodnost použitých metod, na kterých je CASE založen (Procházka, 14), (Řezníček, Kollárovitz, Holba, Pešková, Soukup, Šafránek, Školník,16). . Je dobré mít na paměti, že nástroje CASE nejsou metodologií, ale používají již zavedené metodologie. Nástroje CASE také nejsou náhradou programovacích jazyků (může generovat části kódu, ale programovací jazyky nenahrazuje) a používání nástrojů CASE automaticky nezlepší práci vedoucích pracovníků podniku nebo specialistů pro IT (pouze zlepšuje produktivitu práce). Nástroje CASE odstraňují potřebu disciplíny a přísného vývoje aplikací IT, ale CASE systémy často selhávají právě díky nedisciplinovanosti uživatelů. Od nástrojů CASE se často očekává jako výstup tvorba aplikačního programového vybavení. Hlavní přínos přitom je v úplném poznání fungování podniku a vytváření úplných podkladů právě pro programování aplikací (Procházka, 14). 1.2.1 Druhy nástrojů CASE Jak bylo uvedeno výše, existuje několik druhů nástrojů CASE. Je to dáno nejen podporovanou metodikou, ale také tím, v jaké fázi vývoje je nástroj používán. Nástroje CASE se využívají ve fázích specifikace požadavků, analýzy, návrhu, kódování a údržby. Nástroje použité v různých etapách se liší, a proto je obvyklé, že pokrývají jen určité činnosti. Stírají se také hranice mezi nástroji CASE a integrovanými vývojovými nástroji, například CASE a současně také integrovaný vývojový nástroj QI Builder, který je součástí informačního systému QI od společnosti DC Concept a celý informační systém je v něm vytvořen (Procházka, 14). Podle životního cyklu vývoje software lze nástroje CASE rozdělit do následujících skupin: • Pre CASE – podporují tvorbu globální strategie. • Upper CASE – podporují plánování, specifikaci požadavků, modelování organizace podniku a globální analýzu IS. Hlavním úkolem nástrojů je analýza organizace, 9

zachycení procesů v organizaci, definice klíčových informačních toků a dokumentace zjištěných požadavků. Z těchto údajů je jasné použití při specifikaci cílů, počáteční specifikaci požadavků a řízení projektů. Použité nástroje mohou být DFD (Data Flow Diagram) a ERD (Entity Relationship Diagram) bez podrobných atributů, prostředky pro řízení projektů a sledování ekonomických ukazatelů, popis základních vlastností systému prostředky objektově orientovaného modelování. • Middle CASE – podporují podrobnou specifikaci požadavků a vlastní návrh systému. Tato třída nástrojů CASE je nejúspěšnější. Používají se pro podrobnou specifikaci požadavků, návrh systému, dokumentaci a vizualizaci systému. Použité metody a nástroje jsou DFD včetně podrobného popisu procesů, datových úložišť, podrobné ERD, ale také diagramy tříd, instancí, přechodové diagramy apod. Nástroje CASE této skupiny obsahují systém správy dokumentů a konfigurace, systém pro vyhodnocování metrik, vývoj prototypů, návrh rozhraní. Mohou obsahovat také generátory obrazovkových formulářů a tiskových sestav a také generátory (kostry) definic dat. Tento druh nástrojů CASE je jádrem komerčně dodávaných CASE systémů. • Lower CASE – obsahují nástroje pro podporu kódování, testování, údržby a reverzního inženýrství. Integrovány jsou takové nástroje, jako jsou generátory kódu (mohou generovat jen kostru nebo až 75 procent výsledného kódu, kde programátor doplňuje většinou jen detaily). Dále pak jde o prostředky pro reverse engineering (rekonstrukce dokumentace a modelů z existujícího SW), prostředky pro sledování a vyhodnocení metrik, prostředky plánování a zjištění kvality SW (sběr informací o průběhu testování, vyhodnocení výsledků testů, řízení testování), pro správu konfigurace, prostředky sledování a vyhodnocování práce systému. Funkce nástrojů CASE této kategorie se často překrývají s funkcemi obecných vývojových prostředí (Procházka, 14). Je ovšem nutné podotknout, že třídění podle životního cyklu je možné brát i z jiného pohledu – i podle toho, zda jsou využívány nástroje CASE během celého životního cyklu softwarové aplikace: • vertikální nástroje CASE - nástroje podporující jen dílčí krok životního cyklu software či dílčí oblast – např. zjišťování uživatelských požadavku nebo kódování

10

• horizontální nástroje CASE - nástroje podporující několik kroku životního cyklu software či více oblastí – např. nástroje pro tvorbu dokumentace či řízení konfigurace (Procházka, 14). Životnímu cyklu je velice podobná kategorizace nástrojů CASE podle fáze projektu vývoje softwarové aplikace, v níž jsou využívány: • Front-end nástroje CASE - využívány v dřívějších fázích projektu – např. nástroje na podporu návrhu • Back-end nástroje CASE - využívány v pozdějších fázích projektu – např. kompilery a nástroje podporující testování (Procházka, 14). Předešlé kategorizace jsou si velice podobná, avšak v jistých ohledech se neshodují. Ale rozdělení nástrojů CASE může být provedeno i podle jiných hledisek, kterými jsou interaktivita a integrace. Rozdělení nástrojů CASE podle interaktivity se míní: • ástroje CASE, které jsou interaktivní ze své podstaty - např. nástroje podporující metodu návrhu • ástroje CASE, které nejsou interaktivní - tzv. vývojové nástroje, např. překladače Podle stupně integrace se Nástroje CASE dělí na: • CASE tools - nástroje zabezpečující automatizovanou podporu libovolné úlohy životního cyklu software • CASE toolkits - soubor integrovaných softwarových nástrojů, který poskytuje částečnou či komplexní podporu jen v rámci jedné fáze životního cyklu software • CASE workbenches - množina integrovaných CASE tools nebo CASE toolkits, která poskytuje částečnou či komplexní podporu v minimálně dvou fázích životního cyklu software • I – CASE - představuje nejvyšší stupeň integrace; představuje propojení několika CASE tools, CASE toolkits a CASE workbenches (Procházka, 14). 1.2.2 Komponenty nástrojů CASE Z obecných funkcí čili vlastností nástrojů CASE a požadavků, které jsou na ně kladeny, vyplývá také, z jakých komponent se nástroje CASE skládají. Mezi důležité funkce a vlastnosti CASE patří:

11

• soudržné grafické ovládací prostředí (podle zásad tvorby GUI) – jednotný vzhled obrazovek, popisků, tlačítek, jednotné ovládání, použití symbolických ikon atd. centrální databáze (repository) pro uchování informací o všech objektech IS (tímto způsobem se zaručí, že informace je použitelná i pro libovolné další kroky a fáze projektování) • prostředky verifikace konzistentnosti dat a podpora normalizace dat • textový editor pro popis jednotlivých objektů – pro účely technické a uživatelské dokumentace systému, možnost jejího přímého generování ze systému • možnost rychlého návrhu uživatelských obrazovek včetně simulace vstupů a výstupů (je vyžadováno pro prototyping) • generátor zdrojových programů (pro případy častého znovupoužití daného kódu) • export / import dat – pro práci s modely a dokumentací, které byly vytvořeny v jiných programech nebo jsou v jiných programech dále využívány a zpracovávány. • Slovník - je důležitou částí každého nástroje CASE. Je v něm obsažena definice datových struktur - použitých datových entit, definice vztahů v hierarchii procesů typu rodič / potomek a v neposlední řadě také relace mezi daty a procesy (Procházka, 14). V některých nástrojích je slovník automatický - jakmile vytvoří uživatel objekt diagramu, je ve slovníku automaticky o tomto objektu vytvořen záznam. Velikost slovníku definuje maximální počet procesů, toků, datových objektů. Existují různé metody navigace - přístup k položkám databáze - ve slovníku, přístup pomocí diagramu, přímý přístup do slovníku apod. Slovník funguje většinou také jako textový procesor pro účely dokumentace (Procházka, 14). 1.2.3 Příklad nástroje CASE - QPR ProcessGuide Následující nástroj CASE jsme vybraly jako velice vhodný nástroj pro procesní modelování, jelikož jeho uživatelské prostředí je graficky přívětivé a uživatel se v něm rychle zorientuje. QPR ProcessGuide je manažerský nástroj, který slouží pro práci související s procesním řízením. Nabízí procesní modelování, dokumentaci, publikaci, měření a analýzu procesů. Jeho jednoduché ovládání, přizpůsobitelnost a přehlednost patří k hlavním vlastnostem, díky kterým si získal oblíbenost uživatelů. Dále lze ProcessGuide charakterizovat jako interaktivní nástroj pro plánování, komunikaci a zapojování lidí do zlepšování procesů. Nástroj umožňuje také určení zodpovědností, kompetencí a cílů (QPR, 18).

12

Další charakteristiky nástroje ProcessGuide: • Dynamická publikace procesů prostřednictvím Internetu • Široká škálovatelnost • Provázanost na strategické řízení • Cenově dostupný • Optimalizace a zvyšování kvality procesů (QPR, 18) ProcessGuide má i široké využití jako nástroj pro elektronickou dokumentaci systému řízení jakosti podle ISO 9001:2008. Poskytuje měření a hodnocení výkonnosti a efektivnosti procesů. Měření lze měnit a analyzovat s výstupem do grafů a tabulek. Zajímavá je tvorba simulace procesů, která přináší konkrétní pohled na chod podniku. Simulace je využívána pro analýzu budoucích alternativ, napomáhá tak strategickým a taktickým změnám. Práce s QPR ProcessGuide je na straně uživatele snadno zvládnutelná pro manažery a nevyžaduje žádné speciální IT schopnosti (QPR, 18). Na následujícím obrázku je výchozí obrazovka programu QPR. Uživatelské prostředí je navrženo tak, aby bylo co nejvíce intuitivní, i z toho důvodu je celkový vzhled a ovládání navrženo tak, aby připomínalo MS Office, se kterým mají zkušenosti téměř všichni. Vlevo se nachází adresář jak uložených modelů, tak i souvisejících materiálů, které je možno v programu přiřadit jednotlivým objektům. Vpravo je umístěna paleta nástrojů, avšak program je natolik intuitivní, že při najetí myší na objekt sám nabídne vhodné nástroje k použití v souvislosti s daným objektem.

13

Obrázek 1 – Vzhled programu QPR (Řízení projektů – QPR Software, 17)

Program umožňuje vytvářet subprocesy jako dílčí části modelu, stačí jen danou část označit a pojmenovat ji jako novou entitu, která nově v modelu zastoupí celý subproces. Tento subproces se pro budoucí použití objeví v adresáři ve stejné větvi jako hlavní proces.

14

Obrázek 2 – Vzhled programu QPR (Řízení projektů – QPR Software, 17)

K jednotlivým entitám program umožňuje připojovat dokumenty, které se zobrazí při kliknutí myší na malé i v pravém dolním rohu příslušné entity. Podporovány jsou formáty doc, xls. ppt, pdf a html. Přiřazení dokumentu se provádí pouhým přetáhnutím ikony do prostoru výskytu entity.

Obrázek 3 – Vzhled programu QPR (Řízení projektů – QPR Software, 17)

15

Veškerý vytvořený obsah je možné sdílet na webu a včetně připojených dokumentů. Každý uživatel má svůj vlastní profil, na který může ukládat soubory a komunikovat s dalšími členy týmu.

Obrázek 4 – Vzhled programu QPR (Řízení projektů – QPR Software, 17)

16

2. Řízení projektů V druhé kapitole se věnujeme pojmům souvisejícím s řízením projektu. Tato část tedy obsahuje volnou definici slova „projekt“, uvádí jeho hlavní vlastnosti, cíle a fáze pro vybrané tři metodiky (PMBOK, PRINCE2, RUP).

2.1 Definice slova projekt Projekt může být definován jako „časově ohraničené úsilí, směřující k vytvoření unikátního produktu nebo služby.“ Od procesů se liší právě díky časovému omezení a jedinečnosti výstupů. Projektem lze nazvat činnost, která má jasně definovaný konec z pohledu času a výstupu. Projektem však již není činnost, která se opakuje a je prováděna ověřeným postupem (Wikipedie, otevřená encyklopedie, 18).

2.2 Vlastnosti projektu • Cíl a kvalita – cíl a kvalita produktu by měly být jasně stanoveny před zahájením projektu např. ve smlouvě. Po započetí projektu, se dají provádět menší úpravy, cíl již lze měnit jen obtížně resp. vůbec. V souvislosti s dodržením cíle a kvality by měl a být vedena kvalitní dokumentace. • Čas a náklady – Dodržet stanovený čas a náklady není povinné, pokud tak není uvedeno ve smlouvě. Úzce souvisí s riziky a větším čerpáním zdrojů. • Omezení a rizika – Měly by být definovány již ve fázi plánování, tzn. vyhodnotit okolnosti, které mohou projekt ovlivnit, omezit je a zabránit tak ohrožení projektu. Měla by být provedena analýza rizik, vyhodnocující míru pravděpodobnosti a velikosti dopadu na projekt, pro případ že nastane nežádaná situace, kde by pro vyřešení této situace měl být definován další postup (Řízení projektů – Project management, 16).

2.3 Řízení projektů a jeho cíle Při řízení projektů dochází k rozplánování a následné realizaci složitých a zpravidla jednorázových akcí, které je třeba uskutečnit v požadovaném termínu s plánovanými náklady tak, aby došlo ke splnění stanovených cílů.

17

Předmětem řízení je projekt, který byl již definován v podkapitole „Definice slova projekt“. Cílem řízení projektů je zajištění naplánování a realizace úspěšného projektu, tj. projekt dokončený v plánovaném čase a s plánovanými náklady, který naplňuje stanovené cíle a nevyvolává negativní reakce. Řízení projektů je prováděno v projektovém týmu, který bývá veden projektovým manažerem. Při řízení projektů se využívá celá řada metod pro zvýšení pravděpodobnosti úspěchu projektu. Tyto metody představují ověřené a popsané postupy, řešící problémy vzniklé při návrhu a implementaci projektu (Wikipedie, otevřená encyklopedie, 18).

2.4 Fáze projektu Fáze projektu jsou souhrnně označovány pojmem „životní cyklus projektu“ (project life cycle). Tyto fáze se jednotlivě liší podle použité metodiky (Řízení projektů – Project management). 2.4.1 PMBOK Známý a rozšířený obecný životní cyklus navržený v roce 1991 Warrenem Allenem, který bohužel nebyl v PMBOK publikován. • Zahájení (Initiation) • Definice (Definition) • Implementace (Implementation) • Uzavření (Completion)(Řízení projektů – Project management).

18

Obrázek 5 - Životní cyklus projektu metodiky PMBOK podle Widermana (Řízení projektů – Project management, 16)

V obecné rovině se rozlišují pouze tři hlavní fáze: • Počáteční (Initial) • Střední (Intermediate) – může být jedna i více • Závěrečná (Final)(Řízení projektů – Project management). Další fáze, dělení dle Morrise: • Proveditelnost, • Plánování a návrh, • Zavedení a spuštění, • uzavření (Řízení projektů – Project management).

19

Obrázek 6 - Životní cyklus projektu metodiky PMBOK podle Morrise (Řízení projektů – Project management, 16)

Jednotlivé další metodiky pak používají různé obměny výše uvedených fází, nebo je detailněji rozpracovávají. 2.4.2 PRINCE2 Metodika PRINCE2 rozděluje projekt na dílčí fáze (stages), pojmenování těchto fází se však vyhýbá. Zaměřuje se především na procesy uvnitř podniku. Dělení na fáze je ponecháno manažerovi s ohledem ke konkrétnímu projekt tak, aby byl rozdělen do logických celků (Řízení projektů – Project management, 16). 2.4.3 RUP RUP (Rational Unified Process) byl vyvinut společností IBM a dělí se do čtyř hlavních fází: • Založení, • Rozpracování • Budování 20

• Zavedení (Řízení projektů – Project management).

Obrázek 7 - Životní cyklus projektu metodiky PMBOK podle Morrise (Řízení projektů – Project management, 16)

2.5 Metody řízení projektů V této podkapitole popisujeme dvě nejčastěji používané metody řízení projektů Project Management Body of Knowledge a Projects IN Controlled Environments. Pro podrobnější seznámení s těmito metodami uvádíme oblasti, kterými se zabývají a také, pro které společnosti jsou obecně vhodné. Dále jsme k vybraným metodám uvedly další metodiku pro řízení projektů s názvem Equilibrium - Project Management Solutions, která vychází z dvou hlavních a nejčastěji používaných PMBOK a PRINCE2. Metody řízení projektů, někdy se také můžeme setkat s názvem metody projektového řízení, tyto metody představují ověřené a popsané postupy, které slouží k realizaci činností s cílem zavést nějakou změnu. Dnes existuje řada oborových a dílčích metodik pro řízení projektů. Obecně nejznámější a světově nejrozšířenější metodiky a standardy pro řízení projektů jsou: • PMBOK (Project Management Body of Knowledge) • PRINCE2 (Projects IN Controlled Environments)

21

Tyto metodiky jsou pro řízení projektů využívány nejčastěji, jelikož obsahují standardy pro projekty různého charakteru. Každá organizace by měla uvažovat několik základních faktorů, které napomáhají při rozhodnutí, jakou zvolit metodu řízení projektu: • Druh organizace a její kultura • Vyspělost a velikost organizace • Způsob řízení organizace • Volba projektového manažera (jeho zkušenosti s metodikou) • Cíle projektu • Rozpočet a rizika • Harmonogram projektu (Management mania, 7) K řízení projektu se také vztahují některé normy ISO: • ISO 10006 (norma ISO pro řízení projektů) • ISO 21500 (připravovaná norma ISO pro řízení projektů)

2.5.1 PMBOK (Project Management Body of Knowledge) Tento mezinárodně uznávaný standard pro řízení projektů vydává institut PMI. PMI (Project Management Institute) je světové sdružením profesí projektového řízení, které čítá více jak půl milionu členů po celém světě. PMI definuje odborné standardy, provádí průzkumy a poskytuje přístup k množství informací a zdrojů (Management mania, 7). PMBOK je mezi ostatními standardy a metodikami nejstarší a nejobecnější. Tento standard je nejvíce rozšířen v USA. PMBOK popisuje všechny aspekty projektového řízení a zaměřuje na výrobní firmy, které své výrobky a služby dodávají prostřednictvím projektů. Standard PMBOK je založen na pěti procesních skupinách (Planning, Executing, Monitoring, Controlling a Closing) a devíti znalostních oblastech (Klusoň Martin, 6). Mezi znalostní oblasti PMBOK patří: • Project Integration Management (spojuje a integruje všechny ostatní oblasti)

22

• Project Scope Management (definuje kroky vedoucí k vytvoření rozsahu projektu a k jeho udržení. Zahrnuje i řízení změn. Prvním krokem je sběr požadavků) • Project Time Management (vytváření harmonogramu na základě činností) • Project Cost Management (vytvoření rozpočtu, kalkulace postupu a odhadování výsledku projektu v čase a penězích) • Project Quality Management • Project Human Resources Management • Project Communications Management (detailní řízení komunikace) • Project Risk Management • Project Procurement Management (stručné pojednání o řízení smluv) PMBOK je vhodná pro: • americkou společnost • zlepšení vlastní kvalifikace • zlepšení vědomostí o nejlepších praxích řízení projektů a zlepšení jednotlivých oblastí

2.6 PRINCE2 (Projects in controlled environment) PRINCE2 je v současnosti nejvíce rozšířenou metodikou pro řízení projektů v Evropě. Tato metodika je vydávána OGC. OGC (Office of Government Commerce) je nezávislý úřad britského Ministerstva financí (Management mania, 7). PRINCE2 se opírá o sedm principů, tvoří ji sedm procesů a popisuje sedm témat. Metodiku je nutné v závislosti na konkrétním projektu přizpůsobovat. Znamená to ale, že principy zůstávají zachovány, mění se pouze jednotlivé procesy. Toto přizpůsobování se je jednou z předností metodiky PRINCE2 (Prince Official Site, 9). Principy PRINCE2: • Průběžné zdůvodnění projektu • Poučení se ze zkušeností • Definované role a zodpovědnosti • Řízení pomocí etap 23

• Dohled nad projektem na základě výjimek • Důraz na produkty • Nutnost upravit metodiku podle aktuálního prostředí (Prince Official Site, 9) Procesy: • Starting Up a Project • Initiating a Project • Directing a Project • Controlling a Stage • Managing Product Delivery • Managing a Stage Boundary • Closing a Project (Prince Official Site, 9)

Témata pro modifikaci: • Business Case (popis významu projektu) • Organization (stanovení rolí a vazeb) • Plans (způsoby sestavení plánu) • Progress (autority mezi řídícím výborem a projektovým manažerem) • Risk (definování hrozby nebo příležitostí) • Quality (upřednostnění kvalit zákazníkem) • Change (řízení změn v projektu) (Prince Official Site, 9) PRINCE2 je vhodná pro: • evropské společnosti či společnosti s evropskou centrálou • společnosti účastnící se veřejných tendrů v ČR nebo SR • společnosti bez firemní metodiky Nevýhody: Nepokrývá např. oblasti vedení lidí, manažerské dovednosti, podrobné pokrytí nástrojů pro řízení projektů, které jsou podrobně popsány již existujícími a osvědčenými metodami. Stručné souhrnné porovnání obou metodik nabízí následující tabulka:

24

PRINCE2

PMBOK

Metoda řízení projektů

Souhrn nejlepších praxí pro řízení projektů

Normativní

Není normativní

Ucelený souhrn procesů a témat

Z každého tématu čerpá nezávisle

Pokrývá všechny role řízení projektů

Je zaměřen na projektové manažery

Nezahrnuje mezilidské vztahy

Popisuje soft skills

Odvolává se na techniky

Popisuje techniky řízení projektů

Tabulka 1 – Porovnání metodik Prince2 a PMBOK (Klusoň Martin, 6)

2.6.1 Metodika EPMS (Equilibrium - Project Management Solutions) Tato metodika, kterou vyvinula společnost Equica, a.s., je postavena nad obecnými principy normy systému řízení kvality ISO 9001 a její aplikace na projektové řízení ve smyslu normy ISO 10006 (Equica,1). EPMS vychází principů metodik již zmíněných metodik PRINCE2 A PMBOK. Na rozdíl od těchto metod EPMS odráží specifický stav českého prostředí. EPMS si klade za cíl vnitřní i vnější rovnováhu projektu s využitím objektivního pohledu projektových manažerů. Životní cyklus projektu se skládá z šesti fází (Identifikační, Ověřovací, Přípravné, Realizační, Provozní a Likvidační), při čemž celým projektem prochází proces stabilizace. Stabilizace je zajištěna zpětnou vazbou od zadavatelů. Další kontrolu a dohled zajišťuje proces Audit a dohled projektu (Equica,1). „EPMS je metodika jednoznačně a pragmaticky zaměřená do české praxe, vystavěná za využití letitých koncentrovaných zkušeností s maximální srozumitelností a tahem na branku.“ (Equica,1)

25

3. Jak souvisí Nástroje CASE s řízením projektů Spojení mezi CASE nástroji a řízením projektů je velice nepatrné. Obě linie jsou od sebe poměrně vzdáleny a najít cestu k jejich propojení je těžký úkol. Předešlé práce se marně snažily o určité výrazné propojení těchto dvou paradigmat, což jsme my shledaly špatným pokusem. My jsme toho názoru, že zde jisté propojení existuje. Je bohužel v praktickém využití nevýrazné. Vazbu shledáváme pouze tak, že manažer řídí pomocí svého programu celý projekt, přičemž má přehled o dílčích aktivitách (času, pracovnících, procesech, atd.) v rámci projektu IS/ICT. Vhledem k faktu, Nástroje CASE jsou používány v prvotní fázi projektu (čili v datovém a funkčním modelování IS/ICT), což je samozřejmě dílčí činnost projektu, může tedy manažer sledovat i práci zaměstnanců pracujících s CASE nástroji. Tudíž může ovlivňovat jejich práci s CASE nástroji (například z časového hlediska nebo počtu zaměstnanců pracujících s CASE nástroji), čímž dochází k určitému propojení mezi řízením projektu a CASE nástroji. Jak už je napsáno výše, nejčastěji jsou Nástroje CASE používány pro datové a funkční modelování. A Nástroje CASE jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému. Ano při vývoji systému nikoli řízení projektu. Také vyžaduje vysokou znalost a profesionálnost tvůrce modelů i těch, kdo nástroj používají. Takže bychom po manažerovi, který řídí nějaký IS/ICT projekt mohli asi jen těžko chtít, aby se naučil s těmito nástroji zacházet, když má pod sebou zaměstnance a kolegy a někteří z nich s těmito nástroji pracují, protože to patří k náplni jejich práce. A manažerovi jsou posléze předávány výsledky této práce. Jinak by si vlastně mohl dělat všechnu zadanou práci sám. Proto jsme si zvolili na popsání metodu PRINCE2, která je určena pro řízení projektů a program Project in a box, který umí zpracovávat výstupy do aplikace MS Excel, ve kterém si můžeme data uspořádat do různých grafů a diagramů, na kterých je vidět, jak si projekt stojí. Nejedná se tedy vůbec o CASE nástroj, který generuje kód, ale z našeho hlediska nic nevyvíjíme, ale řídíme. Pro řízení projektu je tedy tato možnost dostačující. Protože právě grafy a diagramy popisující daný stav budou manažera zajímat. Ve většině již zpracovaných prací, většina autorů tak nějak přešla v názvu „řízení projektů“ a rozepsala se o některém z Nástrojů CASE či je porovnávala. Ať již komerční či open source. My jsme se na toto téma podívali zase z trochu jiného úhlu pohledu a zaměřili se právě na

řízení projektů a to, že řídit projekt za podpory Nástrojů CASE nejde. Možná už jen proto, že jsou primárně určeny pro vývoj IS/ICT. Hodit by se nám mohly možná v počáteční fázi, kdy chceme znát situaci před zahájením projektů, v rámci nějaké analýzy. Ale jinak nám v řízení nijak nepomohou.

27

4. Témata k modifikaci V kapitole Témata k modifikaci popisujeme jednotlivé části metodiky PRINCE2 pro řízení projektů. Jedná se o části metodiky, které se vyskytují v celém životním cyklu projektu. Zároveň zde připisujeme vazbu mezi částmi řízení projektu ICT dle metodiky PRINCE2 na nástroje CASE. Témata jsou seřazena podle toho, kdy vstupují do řízení projektu dle zvolené metodiky.

4.1 Business Case Účelem této části metodiky PRINCE2 - Obchodní případ - je vytvořit mechanismy, které by posoudily, zda je projekt žádoucí (tj. náklady a rizika musí odpovídat následnému zisku), životaschopný a dosažitelný (projekt IS/ICT může poskytovat určité výchozí produkty) jako prostředek pro podporu rozhodování ohledně jeho investic. Důležitý je zde také fakt, aby projekt byl nejen žádoucí z hlediska rozjezdu projektu, ale aby projekt byl stálý v celém jeho životním cyklu – platí zde zásada, že projekt musí mít obchodní odůvodnění (Project in a box, 12). Business Case je realizován na počátku projektu, ale je zahrnován do ostatních fází životnosti projektu. Obchodní případ shromažďuje a analyzuje podklady, proč projekt vůbec rozjet. Proto i projekt IS/ICT je realizován pouze v případě, když bude budoucí hotový projekt prospěšný z hlediska podnikových cílů. Cíle se liší od samotného projektu až po firemní strategii; tzn. některé IS IS/ICT lze posuzovat z hlediska jeho benefitu a některé lze posuzovat i jiné, než finanční stránky (Project in a box, 12). V této části se stanovují hranice Business Case a zároveň všech ostatních částí metodiky.

28

4.1.1 Průběh Business Case

Obrázek 8 - Průběh projektu z pohledu Business Case (Project in a box, 12)

Business Case je vytvořen na počátku projektu a bude zachován po celou dobu životnosti projektu, přičemž v něm může dojít k určitým úpravám během definování dalších fází motodiky. Každý bod obou etap Business Case (Develop a Maintain) je formálně ověřen projektovou radou, jako jsou posudky na konci každé části, které potvrdí, že všechny části odpovídají stanoveným vstupním cílům. Etapa Maintain znamená aktualizaci nákladů a výnosů s ohledem na minulý a budoucí vývoj projektu. Obrázek také ukazuje, že výhody z projektu budou plynout až po zakončení projektu tzv. post-projektově (Project in a box, 12). Prvotní část projektu stanovuje veškeré (nebo většinu) kompetence a úlohy v rámci celého projektu (od analytiků až po projektového manažera). Startovací část projektu je rozdělena na dva procesy. První je tzv. koncesní projekt, který je odvozen od popisu procesů v projektu a tzv. před-projektu čili zahajovacího procesu projektu. Jde tedy o nastartování procesu projektu s cílem získat schválení projektu radou zainteresovanou v řízení IS/ICT projektu (Project in a box, 12).

Následuje podrobná analýza vyplývající ze studie proveditelnosti, projektového plánu (náklady, časový harmonogram, výrobky) a přehledu rizik. Podrobná analýza slouží k seskupení a zhodnocení všech relevantních informací, aby se v projektu dále pokračovalo stejným způsoben nebo zda je nutné projektový přístup (či určité jeho části, procesy, atd.) přeplánovat (Project in a box, 12). 29

4.1.2 Definování rolí v Business Case Každý projekt musí obsahovat (pokud možno správné) definování rolí a určení jejich kompetencí, proto ani projekt IS/ICT není výjimkou. Objevují se tu jak role speciálně určené pro IS/ICT projekt, například programátor nebo datový modelář, tak jsou zde i role specifické pro vedení projektu, například projektový manažer (Project in a box, 12). Metodika PRINCE2 definuje v rámci etapy Business Case tyto role: -

The Senior User – odpovídá za realizaci a následného udržení výhod/benefitu v postprojektové fázi

-

Executive – jeho účelem je odpovídat zato, aby projekt byl v souladu s firemní strategií společnosti, a zároveň musí dohlížet na životaschopnost projektu

-

Projektový manažer – hodnotí, analyzuje a každé vzniklé aktualizace na konci každé etapy realizace projektu (Project in a box, 12).

4.1.3 Ukázky z programu Project in a box

Obrázek 9 – Popis dokumentace (Project in a box, 12)

Obrázek číslo 9 ukazuje na popis dokumentace ke třem základním částem projektu – Star, Doručení, Závěr. Tyto tři fáze jsou znázorněny v levé tabulce s třemi odpovídajícími čtverečky. Každý čtverec čili každá fáze se dá rozkliknout, čímž je umožněn přístup 30

k nahlédnutí do jednotlivých dokumentací v rámci etapy. Seznam dokumentů (pro etapu doručení), který se dále samozřejmě člení, je zobrazen v pravé tabulce (Project in a box, 12).

Obrázek 10 – Celkový pohled na procesy (Project in a box, 12)

Obrázek 10 znázorňuje celkový pohled (například z pozice projektového manažera) na procesy v rámci celého projektu (viz. levá horní tabulka), přičemž každý proces lze dále dělit na další podprocesy, které jsou zobrazeny na prostřední tabulce. Pravá, největší tabulka ukazuje na detail procesu, respektive na jeho plán, rizika, atd., týkající v tomto případě projektu – vývoj CRM systému (Project in a box, 12).

31

Obrázek 11 – Sedm etap projektu (Project in a box, 12)

Obrázek číslo 11 zobrazuje veškerých sedm etap projektu dle metodiky PRINCE2, včetně fáze Business Case. Jednotlivé etapy lze dále rozdělovat, nahlížet do nich a analyzovat dle nich projekt z různých pohledů, například z pohledu již dosažených cílů či z pohledu dokumentace (Project in a box, 12).

32

4.2 Organizace (Organization) Cílem tématu Organization je definovat a stanovit projektům organizační strukturu, společné cíle a odpovědnosti. To vše pro efektivní řízení projektu a rozhodování. PRINCE2 ® je založen na prostředí kolem zákazníka i dodavatele. To znamená, že zákazník specifikuje své požadavky na výsledek projektu a dodavatel se zavazuje poskytovat své zdroje a dovednosti. Základem úspěchu každého projektu je vytvoření týmu, který bude efektivně řídit projekt skrze celý jeho životní cyklus (Prince2. Organization, 10). Důležité body pro úspěšný projektový tým: • Složení týmu v zastoupení obou zúčastněných stran • Definování odpovědností za řízení projektu na každé úrovni a definování odpovědnosti poskytovatele • Stanovení strategie pro komunikaci mezi zúčastněnými stranami • Hodnocení všech projektových rolí k zabezpečení si jejich práce po celou dobu projektu (Prince2. Organization, 10) 4.2.1 Projekt PRINCE2 ® definuje projekt jako dočasnou organizace, která je vytvořena za účelem poskytování jednoho nebo více produktů na základě dohodnutého Business Case. Každý projekt vyžaduje určitou míru flexibility a disponování širokou škálou dovedností i na velmi krátkou dobu, pro zajištění těchto požadavků je nutné vytvoření rolí a určení odpovědností => Projektový tým. Podle PRINCE2 ® by měl projekt zahrnovat zájmy obchodní, uživatelské i zájmy ze strany dodavatele (Prince2. Organization, 10).

Obrázek 12 – Definování organizace (Prince2. Organization, 10)

33

4.2.2 Struktura projektového managementu a její odpovědnosti dle PRINCE2® Corporate management Tato úroveň je zodpovědná za uvedení projektu do provozu a dále jmenuje Projektového manažera (zastává výkonnou moc) a definuje rámec pro Project Board (Rada projektu). Všechna stanovení musí být samozřejmě řádně dokumentována (Prince2. Organization, 10). Project Board Rada projektu je zodpovědná za veškeré řízení a management projektu v rámci omezení, které jsou stanovena podnikovým managementem. Dále Rada projektu schvaluje hlavní plány, zdroje projektu, dokončení a započetí jednotlivých etap, je zodpovědná za komunikaci se zhotoviteli. Rada se skládá ze členů zastupující postavení Senior User(s) a Senior Suplier(s). Senior User poskytuje informace ostatním uživatelům a definuje uživatelské požadavky a očekávání. Rada zastává i funkci určité záruky tzv. Project Assurance pro kontrolu, sledování kvality a poradenství při výběru členů týmu (Prince2. Organization, 10). PRINCE2 ® definuje pro Radu projektu následující povinnosti: • Zodpovědnost za úspěchy i neúspěchy projektu • Poskytuje rady udávající směr projektu, což je klíčové pro všechny členy týmu, aby měli jednotný názor • Zprostředkovává zdroje a prostředky nezbytné pro dokončení projektu • Zajišťuje efektivní rozhodování • Trvalá podpora pro Projektového manažera • Zajištění efektivní komunikace jak v rámci projektového týmu, tak i s externími zainteresovanými stranami (Prince2. Organization, 10)

Project Manager Projektový manažer zodpovídá za to, že projekt se vyvíjí v souladu se stanovenými náklady, cíly a časem. Musí být schopen zajistit kvalitu a požadované přínosy, reagovat na možná rizika a udržovat je ve stanovených mezích. Jeho práce spočívá v každodenní odpovědnosti, pokud není určena jiná kvalifikovaná osoba, zastává funkci i pro podporu projektu. Osoba projektového manažera většinou pochází ze strany zadavatele, ale existují i projekty, kde je

34

vedoucím projektu někdo z dodavatelského týmu. V kompetencích projektového manažera je i jmenování dalších členů týmu (Prince2. Organization, 10). Team members Zodpovědnost členů týmu se odvíjí od uskutečněných cílů projektu v odpovídající kvalitě, čase a dle stanovených nákladů. V závislosti na velikosti a složitosti projektu, odpovědnosti za plánování a řízení mohou být odpovědnosti delegovány na manažera týmu (Prince2. Organization, 10).

35

4.3 Plány (Plans) Cílem plánů je usnadnění komunikace a řízení tím, že definuje způsoby poskytování produktů (kde a jak, kým a odhadem kdy a kolik). Efektivní řízení projektu závisí na efektivním plánování, neboť bez plánu neexistuje žádná kontrola. Plánování poskytuje všem pracovníkům zapojených do projektu informace o: • Co je zapotřebí? • Jak a kdo bude k dosažení používat speciální vybavení a zdroje? • Kdy k události dojde? • Jsou cíle (jako čas, náklady, kvalita, rozsah, rizika a benefity) dosažitelné? (Prince Official Site, 9) Při projektu se tvoří různé plány různých úrovní. Nejde jen o Ganttovy diagramy, ale také o manažerské plány řízení kvality, konfiguraci, rizika apod. Základem plánování je samozřejmě Projektový iniciální dokument, podmínky a vytvořené systémy, které obsahuje. Většinu je možné převzít od zákazníka, když u něj existují systematické přístupy k řízení i mimo projekt (například kvalita). Na nejvyšší úrovni vzniká Plán projektu, který představuje základní rámec pro projekt a který vzniká při jeho inicializaci jako klíčový harmonogram s přidělením všech potřebných zdrojů. Detailní plán nazýváme Plán etapy. Každá etapa projektu má mít svůj vlastní a konkrétní plán, což je v principu rozpracování Plánu projektu do kratšího období a na nižší úroveň. V rámci realizační etapy může vzniknout také potřeba plánovat práci konkrétního realizačního týmu a času jeho členů stráveného na projektu v podobě plánu práce týmu. Plány se tvoří po celou dobu trvání projektu v samostatném, průběžném procesu plánování. Metodika určuje, které plány kdy je potřeba udělat a také určuje ty, které jsou volitelné. Důležité je zachovat a udržet konzistenci mezi úrovněmi jednotlivých plánů tak, aby plán na nižší úrovni byl vždy v souladu s plánem na vyšší úrovni. To je úloha projektového manažera a týmových manažerů. (Janáč, Tvorba plánov, 4).

36

Obrázek 13 – Tvorba plánu (Janáč, Tvorba plánov, 4).

4.3.1 Plánování Plánování v projektu se podaří málokdy bez nutnosti pozdější změny a aktualizace. Práce s plány je proto jedním ze základních komponentů a technik projektového manažera. V metodice je plánování založené na produktu, který se má v projektu dodávat a odvíjí se od něj. Vytváří se dekompozice finálního produktu na produkty elementární a sestaví se sekvenční diagram toku produktu. Tím vznikne dobrý základ pro tvorbu plánů projektu a etap. 4.3.2 Dělení projektu Projekt se rozděluje na etapy technické a řídící. Technické etapy představují součet všech prací, potřebných k vytvoření partikulárního produktu. Jedná se o horizontální pohled. Řídící etapy představují součet některých prací na různých produktech, které byly vytvořeny ve stejné době. Jde o vertikální pohled. Plán projektu obsahuje řídící etapy. Důležitým atributem tvorby plánů je návrh řídící etapy tak, aby bylo možné v diskrétních okamžicích kontrolovat přechod jedné etapy do druhé s možností nepokračovat v projektu v případě, když to okolnosti vyžadují (Janáč, Tvorba plánov, 4).

37

4.3.3 Ukázky z programu Project in a box

Obrázek 14 – Úvodní obrazovka (Project in a box, 12)

Obrázek 15 – Microsoft Project (Project in a box, 12)

38

Obrázek 16 – Microsoft Excel (Project in a box, 12)

Obrázek 17 – Přidělení rolí (Project in a box, 12)

39

Obrázek 18 – Rozpracovanost plánů (Project in a box, 12)

Obrázek 19 – Grafy (Project in a box, 12)

Na obrázku 14 vidíme úvodní obrazovku pro plány, kde pro ně vybíráme zdrojová data. Je zde ukázána kompatibilita s produkty od společnosti Microsoft a to programy Project a Excel. Obrázek 17 nám umožňuje přidělování rolí, tedy přiřazení určitého člověka ke konkrétnímu projektu. Na obrázku 18 máme stav našich plánů a obrázek 19 umožňuje vytváření různých 40

grafů, ze kterých se například dozvíme, kdo kolik na jakém projektu strávil času. Máme zde možnost vytvářet různé grafy, které zrovna potřebujeme k nějaké analýze. (Project in a box, 12)

41

4.4 Pokrok (Progress) 4.4.1 Účel Účelem tématu „Progress“ je vytvořit mechanismy ke sledování a porovnávání skutečných úspěchů proti těm, které byly plánované, dále pak stanovit prognózu o cílech projektu a jeho následné životaschopnosti a kontrolovat nepřijatelné odchylky. Dva z principů PRINCE2 ® jsou řízení po oblastech a navazující obchodní zdůvodnění. Téma „Progress“ poskytuje mechanismy pro monitorování a kontrolu, umožňující kritické zhodnocení další možné uskutečnitelnosti projektu. Téma „Progress“ poskytuje mechanismy pro všechny úrovně řízení (doručování, správu, řízení) v rámci týmu řídícího projekt, stejně tak i pro firemní nebo programové řízení mimo projekt (PRINCE2 2009, 9). Další PRINCE2 zásadou je, že projekty jsou řízeny výjimkou, tj. nastavením tolerance pro projektové cíle ke stanovení omezení pověřeným orgánem. Tolerance stanovuje míru uvážení tak, že každá úroveň řízení může konat bez nutnosti odkazovat se na vyšší úroveň kvůli schválení. Téma „Progress“ poskytuje mechanismus pro sledování vývoje ve srovnání s dovolenými odchylkami kontrol eskalujících na vyšší úroveň, kde jakékoli prognózy naznačují, že jedna nebo více odchylek bude překročena. Kontrola vývoje je především o rozhodování a je stěžejní pro řízení projektů, k zajištění, aby projekt zůstal uskutečnitelný navzdory svému schválenému obchodnímu případu (PRINCE2 2009, 9). 4.4.2 Co je to „Progress“? „Progress“ je míra dosažení plánovaných cílů. Může být sledován na úrovni „work package“ (podmnožina projektu, která může být určena konkrétní straně k provedení), oblasti a úrovně projektu (PRINCE2 2009, 9). 4.4.3 Co jsou to „Progress“ kontroly? „Progress“ kontroly zajišťují, že u každé úrovně projektového řídícího týmu další úroveň managementu může: • Sledovat vývoj, • porovnávat úroveň dosaženého výkonu s plánem, • přezkoumávat plánů a možností s ohledem na budoucí situace, • detekovat problémy a identifikovat rizika, 42

• přijímat nápravná opatření, • dávat svolení k další práci (PRINCE2 2009, 9). 4.4.4 Výjimky a odchylky Výjimkou je situace, kdy je možné předpovědět, že dojde k odchylce nad rámec dohodnutých úrovní odchylek. Odchylky jsou přípustné odchylky nad a pod plánovaným cílem pro čas a náklady, aniž by eskalovala odchylka do další úrovně řízení. Stejně tak tam mohou být také toleranční úrovně pro kvalitu, rozsah, výhody a rizika (PRINCE2 2009, 9). Pokud není zavedena žádná odchylka, není ani žádná jasná míra pochybností, že věci nejdou podle plánu. Například, pokud každá menší odchylka eskaluje k projektové radě, projektový manažer pouze sleduje práci a nevyvíjí žádné úsilí k provedení nápravných opatření, což je zjevně neuspokojivé z pohledu členů správní rady. Ve skutečnosti se pak projektová rada zabývá prací, kterou má odvádět manažer. Na druhou stranu, snaží-li se projektový manažer dát věci do pořádku a provádí nápravná opatření, existuje riziko, že členové projektové rady budou toto jednání vnímat jako překročení jeho kompetencí vázaných k projektu, a vyvstane otázka, proč nebyly problémy eskalovány dříve. V tomto případě je projektový manažer viděn, jako že přejímá roli, kterou by měla zastávat projektová rada. Následující diagram označuje, kde je možné použít odchylky, a ukazuje, v jakém řídícím produktu jsou dokumentovány (PRINCE2 2009, 9).

43

Tabulka 2 – Odchylky (OGC, 8)

4.4.5 PRINCE 2 - koncepce „Progress“ kontrola zahrnuje měření skutečného vývoje vůči výkonnostním cílům v čase, nákladech, kvalitě, rozsahu, výhodách a rizicích, a následné použití těchto informací pro rozhodování (např. schválení fáze nebo „Work Package“, zda eskalovat odchylky, předčasně ukončit projekt atd.) a zároveň přijmutí požadovaného opatření (PRINCE2 2009, 9). PRINCE2 ® poskytuje kontrolu vývoje prostřednictvím: • Přenesení pravomocí z jedné úrovně řízení na úroveň nižší, • rozdělení projektu na řídící oblasti a schvalování vždy jen jedné oblasti projektu, • časem a událostmi řízený „Progress-reporting“ a kontroly, • zvyšování výjimek. Projektové kontroly by měly být zdokumentovány v projektové dokumentaci (PRINCE2 2009, 9).

44

4.4.6 Ukázky programu - část „Progress“

Obrázek 20 – Výchozí obrazovka manažerského nástroje sloužícího pro kontrolu projektů (PRINCE2 Software and Methodology led Project Support Offices, 12)

Obrázek 21 - Excelový výstup ukazující splnění plánu podle osob v % (PRINCE2 Software and Methodology led Project Support Offices, 12)

45

Obrázek 22 - Excelový výstup pro řízení rizik (PRINCE2 Software and Methodology led Project Support Offices, 12)

46

4.5 Riziko (Risk) 4.5.1 Cíl Cílem tohoto tématu v metodice PRINCE2 je riziko včas identifikovat, ohodnotit a mít nejistotu projektu pod kontrolou. Hlavním cílem ovšem zůstává zvýšení schopnosti projektu na úspěch. U projektů je naprosto nevyhnutelné mluvit o rizikách, jelikož u projektů jako takových předpokládáme nějaké změny a tyto změny s sebou přináší nejistotu a tudíž i riziko. Projekt by měl vytvořit a udržovat cenově přínosný a efektivní postup při řízení rizika. Cílem by především měla být podpora lepšího rozhodování díky dobré znalosti rizik, kam patří jejich příčiny, pravděpodobnost uskutečnění, dopad na projekt a ohrožení cílů a samozřejmě i správné načasování (OGC, 8). 4.5.2 Co je riziko

Riziko je nejistá událost nebo soubor událostí, ke kterým, kdyby došlo, měly by vliv na dosažení cílů. Riziko se skládá z kombinace pravděpodobnosti, kterou vnímáme, že může být rizikem nebo příležitosti, která se v danou chvíli vyskytuje a velikost dopadu na předem určené cíle. V této souvislosti také používáme pojmy hrozba a možnost. V případě hrozby se o nejistou událost, která by mohla mít negativní dopad na stanovené cíle. Možnost chápeme jako nejistou událost, která by ovšem mohla mít příznivý dopad na předem stanovené cíle (OGC, 8). 4.5.3 Co je ohroženo V rámci projektu jsou to především projektové cíle, které jsou ohroženy. Ty zahrnují čas, náklady, kvalitu, rozsah, výhody a rizika. 4.5.4 Co je řízení rizik Řízení rizik je kontinuální činnost, která probíhá po celou dobu životního cyklu projektu. Bez průběžného a efektivního řízení rizik nemůžeme spoléhat na to, že projekt bude schopen splnit všechny své cíle. Efektivní řízení rizik je tedy nezbytným předpokladem pro podnikání. Tento termín zahrnuje systematické uplatňování postupů a má za úkol identifikovat a hodnotit rizika a následně plánovat provádět rizikové odpovědi. Tyto všechny potřeby poskytuje disciplinované prostředí pro proaktivní rozhodování. Řízení rizik je bezesporu nevyhnutelnou součástí projektového řízení. Nic není tak často zanedbáváno a zároveň tak důležité v projektu, jako je právě řízení rizik. Základním 47

předpokladem pro úspěšný projekt je poznat jeho rizika a vyhýbat se jim (Janáč, Hatrák, 2). Analýza rizika

Řazení rizika

Rozpoznání rizika Registr rizik

Vyhodnocení rizika

Sledování a řízení rizika

Identifikace opatření Ošetření rizika Výběr opatření

Vytvoření rizikových plánů

Obrázek 23 - Analýza a řazení rizika (autor)

4.5.5 Projektová rizika Riziko, které plyne ze špatného řízení projektu, je rizikem, které se může vyskytnout jak například u budování programových systémů, tak i při projektu podnikové inovace IT. Hodnocení a řízení rizika projektu obsahuje 4 základní kroky, které musí být opakovaně prováděny. U velmi významných projektů tyto kroky musí být dokonce prováděny nepřetržitě. Mezi tyto kroky v metodě PRINCE2 patří (Rais, Smejkal, 14): • Rozpoznání rizika • Vyhodnocení rizika • Vytvoření rizikových plánů • Sledování a řízení rizika

48

4.5.6 Rozpoznání rizika Mezi nejvhodnější a nejlepší způsoby, jak rozpoznat riziko, patří kontrola seznamů úkolů a časového plánu a v neposlední řadě také diskuse a rozhovory s odborníky v určité problematice.

4.5.7 Vyhodnocení rizika Vyhodnocení rizika je tvořeno několika kroky (Rais, Smejkal, 14): • Určení úrovně tolerance – jaké náklady a jaké zpoždění je přijatelné • Přiřazení pravděpodobnosti jednotlivým rizikům – pravděpodobnost rizika můžeme určit buď na základě zkušeností z dřívějších projektů, nebo podle vyhodnocení stávajícího stavu (expertním odhadem) • Přiřazení priorit jednotlivým rizikům – priority přiřazujeme na základě úrovně tolerance, potenciálních nákladů na riziko a pravděpodobnosti, že k riziku dojde (pokud náklady na riziko přesahují úroveň tolerance a je velice pravděpodobné, že k němu dojte, je nutné přiřadit riziku velkou prioritu – pomocí těchto priorit poté určíme, na která rizika je zapotřebí se soustředit nejdříve) 4.5.8 Vytvoření rizikových plánů Vytvoření rizikových plánů především představuje rozpoznání aktivačních procedur pro jednotlivá rizika. Aktivační procedury jsou indikátory toho, že došlo nebo že může dojít k riziku, takže nejlepší aktivační procedury s předstihem upozorní na blížící se problém. Pro jednotlivá rizika vytvoříme seznam sledovaných položek, který by obsahoval možné aktivační procedury, spolu s údaji o tom, kdy pravděpodobně nastanou a kdo by měl danou aktivační proceduru sledovat. Vytvoření rizikových plánů může dále představovat stanovení aktivních, rezervních či zmírňujících plánů pro jednotlivá rizika (Rais, Smejkal, 14).

4.5.9 Sledování a řízení rizika Sledováním a řízením rizika je míněno to, že se sleduje seznam určených položek, aby bylo možno zjistit, zda se neobjevují aktivační procedury. V případě potřeby je poté možno použít rezervní plány a pravidelně znovu vyhodnocovat rizika. Pokaždé, když se skutečný průběh projektu významně odchýlí od plánu, znovu je možné si stanovit rizika a přehodnotit plán na řízení rizika. 49

4.5.10 Ukázky z programu PROJECT in a box

Obrázek 24 - Vyhodnocení rizika (Project in a box, 12)

Každý nástroj má možnost svého vlastního hodnocení a výstupu v podoknech. Na obrázku č. 18 je možné vidět výstup z programu PROJEKT in a box v Excelu. Je zde zobrazeno shrnutí současného stavu rizika nebo šíření možného rizika. Díku tomu máme možnost okamžitě vidět, jaký dopad může mít riziko na náš projekt. Tyto podokna jsou uzamčeny, aby byla zajištěna jednotná a důsledná analýza všech projektů.

50

Obrázek 25 - Ukázka dashboards (Project in a box, 12)

Uživatelé mohou v programu PROJECT in a box vytvářet hlášení a “dashboards“ (vývěsky) a zároveň si mohou vybrat, jak je zveřejnit. V tomto případě zveřejněný dashboard obsahuje veškeré informace o aktuálním stavu projektu a nejnovější data z rizik, financí, problémů, kvality a plánů projektu a výstup je proveden ve Wordu.

51

Obrázek 26 – Registr rizik (Project in a box, 12)

Obrázek č. 26 ukazuje práci uživatele v průzkumníku souborů (vlevo), které se týkají současného procesu. Vpravo je registr rizik, kde je možné vidět přehled identifikovaných rizik. Uživatel má možnost prohlížení, odhlašování, přihlašování, možnost změn, distribuci emailem, přidání nového obsahu pro vytvoření a oznámení akcí.

52

4.6 Kvalita (Quality)

4.6.1 Účel Účelem kvality je definovat a implementovat prostředky, pomocí kterých je projekt vytvořen, a které ověří produkty, jež jsou pro daný účel vhodné. „Zaměření produktu“ je ústředním přístupem PRINCE2 ke kvalitě. Poskytuje explicitní chápání toho, co projekt vytvoří (rozsah) a kritérií, podle kterých budou projektové výrobky posuzovány (kvalita). Bez tohoto porozumění, by byl projekt vystaven rizikům, jako jsou např. spory, přepracování, nekontrolovatelné změny, nespokojenost uživatelů (OGC, 8). Teprve po stanovení kritérií kvality pro výrobky a další činnosti, které musí být zahrnuty do projektového plánu, můžeme odhadovat celkové náklady a časovou náročnost projektu. Odhadování nebo vynechání činností souvisejících s řízením kvality může vést ke skluzům či přehnaným nebo zcela špatným výsledkům. Téma kvality se zabývá metodami a odpovědností nejen pro specifikaci, vývoj a schvalování projektových produktů, ale také pro řízení projektu. Dále se také zabývá neustálým zlepšováním již v průběhu projektu, např. hledá způsoby, které by vedly k větší účinnosti a efektivnosti řízení projektu a projektových produktů (OGC, 8). 4.6.2 Co je to kvalita? Kvalita je obecně definována jako celkový souhrn funkcí a základních nebo přidělených vlastností určitého výrobku, osoby, procesu, služby a/nebo systému, který splňuje očekávání a uspokojuje dané požadavky a specifikace (OGC, 8).

Řízení kvality a systémy řízení kvality Řízení kvality můžeme definovat jako souhrn koordinovaných činností pro řízení a kontrolu organizace s ohledem na kvalitu. Systém řízení kvality zahrnuje kompletní soubor norem, postupů a odpovědností pro organizaci. Často se stává, že do projektu je zapojeno více organizací, což znamená, že každá může mít svůj vlastní systém řízení kvality. Pokud má projekt klíčového sponzora, nebo je velice 53

pravděpodobné,

že

zde

bude

existovat

pouze

jeden systém

řízení

kvality.

Tyto různé okolnosti, musí být řešeny při určování projektového přístupu ke kvalitě (OGC, 8). 4.6.3 Plánování kvality Chceme-li vše kontrolovat, včetně kvality, musí existovat plán. Plánování kvality je o definování požadovaného produktu spolu s příslušnými kritérii kvality, metodami kvality (včetně práce potřebné pro kontrolu kvality a přijetí produktu) a odpovědností za kvalitu (OGC, 8). Plán kvality projektu Plán kvality projektu je v podstatě dokument, který dává jasnou představu o tom, jakým způsobem projekt splní zákazníkova očekávání. Plán je součástí dokumentace projektu a je vytvořen na počátku projektu. Dokument obsahuje použité normy a manuál (pokud již existuje). Dále stanovuje odpovědnost za kvalitu pro projektového manažera a povinnosti pro projektové vedení. Kontrola kvality Kontrola kvality zajišťuje to, že výrobky dosahují normy kvality, která byla nastavena. Kontrola kvality je zaměřena na provozní techniku a činnosti, které jsou zapojeny do projektu. Kontrolu provádíme za účelem (OGC, 8): • ověření splnění požadavků na kvalitu (např. testování kvality) • identifikace příčin neuspokojujícího výkonu Zabezpečení kvality Pro zajištění kvality je vhodné sestavit nezávislý tým. Zabezpečování kvality zajišťuje kontrolu toho, že cíl projektu a jeho řízení jsou přiměřené charakteru projektu a vše je v souladu s danými normami. Zabezpečení kvality je o nezávislém ověření, že organizace a procesy jsou vhodné pro plánování a kontrolu kvality. Tím zajistíme splnění požadavků na kvalitu.

Termín „kvalita“ se používá ve dvou významech (OGC, 8). • jako funkce v rámci organizace (nebo programu), která vytváří a udržuje systém řízení kvality

54

• Jako činnost přezkoumání projektové organizace, procesů a/nebo výrobků k nezávislému posouzení, zda kvalitativní požadavky budou splněny. V obou smyslech, zabezpečování kvality, zahrnuje přínosy, které jsou nezávislé na řízení projektového týmu, poněvadž plánování kvality a kontrola kvality jsou realizovány v rámci projektu. Přesto řízení projektu vyžaduje zajištění adekvátní kvality. Zabezpečení kvality by nemělo být zaměňováno se zabezpečením projektu. Zabezpečení projektu se týká odpovědnosti za celý projekt nebo za to, že je proveden správně. Zabezpečení projektu je nezávislé na projektovém manažerovi, ale zabezpečení kvality není nezávislé na projektu. Zabezpečení projektu a zabezpečení kvality se překrývají. 4.6.4 PRINCE2 a přístup ke kvalitě Specifické

řešení kvality u

PRINCE2 je zaměřeno na produkty od

samého

počátku.

To vyžaduje systematické činnosti jako (OGC, 8): • identifikaci všech projektových produktů • vymezení produktových vlastností včetně kritérií kvality, podle kterých budou produkty posuzovány (kvalitativní metody používané při navrhování, vývoji a schvalování) • sledování kvality v průběhu projektu První dvě činnosti jsou zahrnuty v plánování jakosti a poslední činnost v řízení kvality a jejím zabezpečování. Plánování kvality Cílem plánování kvality je poskytnout bezpečný základ pro (OGC, 8): • dohodnutí se mezi vedením projektu na celkové očekávané kvalitě, požadovaných produktech (včetně kritérií kvality), na způsobu dosažení požadované kvality, na způsobu posouzení kvality a na přijetí kritérií, podle kterých bude produkt hodnocen. • komunikaci těchto dohod jednoznačně tak, aby všechny zúčastněné strany projektu správně chápaly, čím se projekt zabývá a čeho má dosáhnout • kontrolu, tj. vytvoření účinného základu pro kontrolu kvality projektu (včetně tolerance kvality) a zabezpečení prostředků k dosažení produktů, které jsou vhodné pro daný účel 55

Pokud jsou tyto aspekty plánování zanedbány, může dojít ke konfliktům ohledně rozsahu řešení, ohledně toho, co představuje úspěšný výsledek, o rozsahu požadovaných činností, o účasti lidí na projektu a o charakteru jejich rolí.

Obr 27 - Přehled o stavu a plnění projektu (Project in a box, 12)

Plánování kvality zahrnuje (OGC, 8): • pochopení zákazníkových očekávání na kvalitu • definování projektových kritérií přijatelnosti • zdokumentování zákazníkových očekávání na kvalitu a projektových kritérií přijatelnosti • zformulování strategie řízení kvality • sepsání produktové dokumentace obsahující kritéria kvality, toleranci, kvalitativní metody • odpovědnost za kvalitu nastavení registru kvality

56

4.7 Změna (Change) 4.7.1 Účel Účelem tématu změny je identifikovat, hodnotit a kontrolovat všechny potenciální a provedené změny. Změna je v průběhu trvání projektu nevyhnutelná a každý projekt potřebuje systematický přístup k identifikaci, hodnocení a řízení otázek, které mohou mít za následek změnu. Změny mohou nastat na základě žádostí a stížností členů projektového týmu, nebo na základě celé řady dalších faktorů. PRINCE2 stanoví společný přístup k otázkám řízení změn. PRINCE2 nabízí systematický a společný přístup, který zajišťuje, že otázky případného vlivu na projektové výkonnostní cíle (čas, náklady, kvalita, rozsah, rizika a přínosy) jsou řádně spravovány. Řízení změn je kontinuální činnost prováděná po celou dobu „životnosti“ projektu. Každá změna musí být schválena příslušným orgánem před tím, než bude provedena. Předpokladem efektivního řízení změn je zavedení vhodného systému správy konfigurací, který zaznamenává základní linie pro projektové produkty a zajišťuje, že jsou zákazníkům dodávány správné verze (OGC, 8). 4.7.2 Řízení změn Postupy pro řízení změn zajišťují, že všechny problémy a změny, které mohou mít vliv na dohodnuté projektové linie, jsou identifikovány, hodnoceny a buď schváleny, zamítnuty nebo odloženy. Snažíme se docílit efektivního řízení změn. Všechny projekty mají přirozenou tendenci se rozpínat a řešit otázky, které nebyly položeny na samém začátku. Některé změny v rozsahu jsou přípustné a pravděpodobně i žádoucí. Avšak pokud tomu tak není, projekt nezadržitelně roste, náklady nevyhnutelně také a to vše má nepředvídatelné dopady. Změna jakéhokoliv produktového materiálu by měla být dostatečně odůvodněna, řádně povolena a efektivně řízena. Postup schvalování a provádění změn musí být řádně zdokumentován včetně hodnocení změn.

57

4.7.3 Správa konfigurace Řízení konfigurace je technická a administrativní činnost zabývající se vytvářením, udržováním a řízením změny konfigurace po celou dobu životnosti výrobku (nebo položky). Konfigurační položka je entita, která je předmětem řízení konfigurace. Entita může býtsoučástí výrobku, může to být samotný výrobek nebo soubor výrobků, které tvoří výstup. Například (OGC, 8): •

součást výrobku: elektronický motor, který je součástí strojního zařízení

•

produkt: strojní zařízení

•

výstup: školicí materiály, nezbytné zdravotní a bezpečnostní certifikáty

Výstup je kompletní a ucelený soubor produktů, které jsou spravovány, testovány a nasazeny a jako jediná entita pak předány uživateli. Postup řízení změn musí být integrován se systémem řízení konfigurace používaným v projektu (OGC, 8). 4.7.4 Issues PRINCE2 používá termín „issue“ pro všechny důležité události, které se staly, nebyly plánované a vyžadují řízení. Může se tak jednat o problém, dotaz, žádost o změnu nebo návrh vznesený v průběhu projektu. Dotahy mohou být vzneseny kdykoliv v průběhu projektu kýmkoliv, kdo má zájem na projektu nebo jeho výsledcích (OGC, 8). 4.7.5 PRINCE2 a přístup ke změnám Strategie řízení konfigurace Efektivní vydávání a řízení změn je možné pouze v případě, že je podporována konfigurace systému řízení, která usnadňuje posouzení dopadu (vztahy mezi výrobky) a udržuje produktové linie. Výchozím bodem pro všechny projekty je zjistit, zda existují nějaké společné nebo programové zásady a postupy, které je třeba použít, a začlenit je do vlastní strategie řízení konfigurace. Projektová strategie řízení konfigurace by měla definovat (OGC, 8): 58

• konfiguraci řídícího postupu (např. plánování, identifikace, řízení, vykazování stavu, kontroly a auditu) • postup vydávání a řízení změn (např. zachycení, zkoumání, navrhování, rozhodování, provádění) • nástroje a techniky, které budou použity • záznamy, které budou vedeny • jak se budou vykonané procesy vykazovat • načasování konfigurace a činností řízení změn • role a odpovědnosti za řízení konfigurace a činnosti řízení změn Strategie řízení konfigurace by měla vymezovat způsoby řešení problémů. V počáteční fázi se musí projektový manažer a projektové vedení dohodnout na (OGC, 8): • stupnici pro stanovení priorit • stupnici pro hodnocení závažnosti problému • jaké závažné otázky mohou být řešeny na jednotlivých úrovních řízení Při rozhodování, jak závažné otázky mohou být řešeny na které úrovni řízení, může vedení projektu zvažovat delegování některých rozhodnutí pro přijetí/zamítnutí žádostí o změnu na orgán s pravomocí změny, který zváží, zda poskytnout prostředky na úhradu změny. Orgán s pravomocí pro změnu Vedení projektu odpovídá za posouzení a schválení žádosti o změnu. U projektu, kde se nepředpokládá mnoho změn, je rozumné ponechat odpovědnost za rozhodování o změnách na vedení projektu. Ovšem u projektů, kde je pravděpodobný výskyt mnoha změn, je lepší delegovat rozhodnutí na osobu nebo skupinu osob, které vedení projektu určí jako rozhodovací orgán za změnu. Projektový manažer a/nebo osoby s odpovědností delegovanou vedením projektu, mohou také působit jako orgán změny (OGC, 8).

59

Obr 28 - Ukázka spravování projektové dokumentace (Project in a box, 12)

Změna rozpočtu Jedná se o částku, která je zákazníkem a dodavatelem odsouhlasena, a která bude použita na financování nákladů žádostí o změnu, a případně i na analýzu. Pokud je předpokládaná úroveň změn u projektu nízká, je vhodné stanovit rozpočet, který bude nastaven tak, aby se zaplatily všechny změny. V případě změny rozpočtu může vedení projektu stanovit limit pro náklady na jednotlivé změny. Vše musí být samozřejmě řádně zdokumentováno (OGC, 8).

60

Závěr Řízení projektu může být do jisté míry nezávazné, co se týká pojetí projektu, přístupu k jeho řízení a konečnému výsledku. Při výběru metody řízení projektu hraje důležitou roli mnoho okolností, jako např. rozměr projektu, malá zakázka nebo rozsáhlý projekt, vyžadující mnoho zdrojů… dále je důležitý výstup projektu a jak se mění nároky na něj v čase. Neméně důležitou roli hraje také zastoupení osob, pracujících na projektu. Některý projekt je možné uskutečnit s minimálním počtem osob, např. pouze s jednou osobou zastupující určitou fázi projektu a samozřejmě jedním manažerem, zastřešujícím tento projekt v průběhu všech jeho fází nebo může projekt vyžadovat účast několika dílčích týmů dohromady spolupracujících na projektu. Každopádně ve všech případech dochází k využívání softwaru podporujícího dílčí procesy v rámci celého projektu. V počáteční fázi projektu, kdy dochází k analyzování zákaznických potřeb a požadavků jsou nástroje CASE využívány nejvíce. V této části vystupují zejména analytici, jejichž následnou prací je tyto požadavky namodelovat a navrhnout jejich řešení. Tyto modely jsou dále postoupeny vývojářům, kteří za pomoci programovacího software realizují toto řešení. Vyjmenován byl pouze základní software, ale míra jeho využití a stejně tak využití dalších programů v rámci projektu je závislé na charakteru daného projektu a rozhodnutí zúčastněných osob. Každopádně pro každý projekt by měla být vybrána zodpovědná osoba pověřená jeho řízením, pro tuto osobu se používá označení „Projektový manažer“. Úkolem projektového manažera je dohlížet nad činností dílčích procesů a koordinovat týmy i jednotlivé osoby. Projektový manažer přichází do kontaktu se zákazníkem nejvíce a je jeho povinností navrhnout mu projektový plán, který by měl být v průběhu projektu dodržován. V případě, že tomu tak není, měl by informovat vedení, uvést důvody proč tomu tak je a provést nápravná opatření. Metoda PRINCE2 byla zvolena především proto, že je nejpoužívanější metodou pro řízení projektů v Evropě. Bohužel v této metodě, není využíváno nástrojů CASE, nýbrž nástrojů pro řízení výkonnosti, času a nákladů, které jsou všechny obsaženy v kompletním nástroji určeného přímo pro řízení projektů, konkrétně i pro metodu PRINCE2, a tímto nástrojem je software PROJECT in a box. Co se týká Nástrojů CASE, jejich primární účel je zachytit 61

procesy a data, jejich využití managementem pro řízení projektů plní pouze doplňkovou funkci. V tomto dokumentu je představen CASE nástroj QPR od společnosti Software Plc, který nabízí několik užitečných funkcí využitelných manažerem. Tento systém je navržen tak, aby vyhovoval střednímu a vyššímu managementu, protože umožňuje pouze základní návrh, nikoli detailní funkce, jakými je definování datových typů a operací, mapování objektů a samozřejmě následné generování kódu. Tyto pro manažera zbytečné funkce jsou nahrazeny adekvátnějšími

matematickými

a

statistickými

62

funkcemi

a podporou

logistiky.

Použité zdroje 1. Equica [online]. c2011 [cit. 2011-05-08]. Metodiky řízení projektu. Dostupné z WWW: . 2. History of CASE. Knowledge sharing communities [online]. Jun 19, 2007, [cit. 201105-22]. Dostupný z WWW: http://it.toolbox.com/wiki/index.php/History_of_CASE. 3. http://panrepa.org/CASE/zima2009/case_v_rizeni_projektu_zima2009.pdf. 4. JANÁČ, Rastislav; HATRÁK, Michal; MADARASSI, Zuzana. Tvorba plánov [online]. 2009 [cit. 2011-04-28]. Dostupné z WWW: . 5. JANÁČ, Rastislav; HATRÁK, Michal; MADARASSI, Zuzana. Prince2 [online]. 2009 [cit. 2011-04-28]. Dostupné z WWW: . 6. KLUSOŇ, Martin. Prince2 nebo PMI?. IT Systems [online]. 2010, 3/2010, [cit. 201105-08]. Dostupný z WWW: . 7. Management mania [online]. c2011 [cit. 2011-05-08]. Metody řízení projektu. Dostupné z WWW: . 8. OGC. Managing successful projects with PRINCE2 [online]. Ireland : TSO, 2009 [cit. 2011-04-27]. Dostupné z WWW: . ISBN 978011310593. 9. Prince Official Site [online]. c2011 [cit. 2011-06-12]. Prince2 - The method. Dostupné z WWW: .

10. Prince2-2009-basics [online]. c2010 [cit. 2011-05-08]. Prince 2009 - Organization. Dostupné z WWW: http://www.prince2-2009basics.com/PRINCE2_2009_036_Organization_Organization_defined.shtml 11. PROCHÁZKA, Jaroslav. [online]. 27.5.2004 [cit. 2011-05-22]. Nástroje CASE? Co? Proč? Jak?. Dostupné z WW: http://www.dbsvet.cz/view.php?cisloclanku=2004052702. 63

12. Project in a box [online]. 2005 - 10 [cit. 2011-05-26]. PRINCE2. Dostupné z WWW: . 13. QPR [online]. c2011 [cit. 2011-06-12]. QPR ProcessGuide. Dostupné z WWW: . 14. RAIS, Karel; SMEJKAL, Vladimír. Řízení rizik ve firmách a jiných organizacích : 3., rozšířené a aktualizované vydání. Praha : Grada Publishing a.s, 2009. 360 s. ISBN 97880-247-3051-6. 15. ŘEZNÍČEK, Mirek. HOLBA, Jakub. KOLLÁROVITZ, Radek. PEŠKOVÁ, Barbora. SOUKUP, Tomáš. ŠAFRÁNEK, Jan. ŠKOLNÍK, Petr. Použití CASE při řízení projektů IS/ICT [online]. Hh : Hh, 2009. 47 s. Semestrální práce. Vysoká škola ekonomická v Praze. Dostupné z WWW: 16. Řízení projektů - Project management [online]. 12. 09. 2005 [cit. 2011-04-22]. Co je projekt a jaké má vlastnosti. Dostupné z WWW: . 17. Services and Software for Developing Processes and Enterprise Architecture - QPR Software [online]. 2011 [cit. 2011-06-12]. Process Management Software QPR ProcessGuide - QPR Software. Dostupné z WWW: . 18. Wikipedie, otevřená encyklopedie [online]. 28. 2. 2011 [cit. 2011-04-22]. Projekt Wikipedie. Dostupné z WWW: . 19. Wikipedie, otevřená encyklopedie [online]. 3. 5. 2011 [cit. 2011-05-22]. Řízení projektů - Wikipedie. Dostupné z WWW: .

64