Hlavní práce3617_xproj35.pdf, 378.8 kB Stáhnout

Fakulta informatiky a statistiky

Katedra informačních technologií

ANALÝZA METODIK PROJEKT MANAGEMENTU PRO MALÉ A ST Ř EDNÍ ICT FIRMY

BAKALÁŘSKÁ PRÁCE

Student : Jana Prochásková

Vedoucí bakalářské práce : Ing. Jakub Řídel

Recenzent bakalářské práce : Ing. Petr Kudláček rok: 2006

Poděkování

Na tomto místě bych ráda poděkovala vedoucímu mé práce Jakubu Řídelovi, za podporu a konzultace v průběhu psaní.

Prohlášení

Prohlašuji, že jsem bakalářskou práci zpracovala samostatně a že jsem uvedla všechny použité prameny a literaturu, ze kterých jsem čerpala.

V Praze dne 28. srpna 2006 ………...

podpis

Abstrakt

Tato práce se zabývá analýzou vybraných metodik projekt managementu. Konkrétně metodikou, jejímž autorem je Project Management Institute a která je sepsána v knize Project Management Body Of Knowledge a metodikou, jejímž autorem je britská vláda, PRINCE2 (PRojects IN Controlled Environment) a jejíž plnění vyžaduje od plnitelů vládních zakázek. Při popisu metodik jsem se zaměřila především na procesy během projektu, jejich interakci a vstupy a výstupy. V závěru analýzy je stručné porovnání obou metodik, které může čtenáři napomoci v orientaci mezi nimi.

Dalším cílem této práce je nastínit metodiku pro malou ICT firmu Memos Software, s. r. o., se kterou jsem na jejím návrhu spolupracovala. Metodika je zvolena s ohledem na malou velikost projektů a jejich vysokou prioritu.

Abstract

This work deals with analysis of project management methodologies. One of the methodologies is created by Project Management Institute and written in Project Management Body of Knowledge. The second one, PRINCE2 (stands for PRojects IN Controlled Environment) was developed by the Central Computer and Telecommunications Agency (CCTA) as a UK Government standard for information technology (IT) project management. I have focused on project processes, their interaction, inputs and outputs. There is a brief comparison of methodologies at the end of analysis, which might be helpful for orientation among them.

Another goal of this thesis is to suggest a methodology for small ICT company Memos Software, s. r. o., which I have cooperated with. Methodology is drawn out with attention on small size of projects and their high priority.

Obsah

ÚVOD... 8

1. PROJEKT MANAGEMENT... 9

1.1. PROJEKT... 9

1.2. PROJEKT MANAGEMENT... 10

1.3. PROJEKT MANAGER... 10

1.4. NEJČASTĚJŠÍ PŘÍČINY SELHÁNÍ PROJEKTU... 12

2. METODIKA PMI – PMBOK ... 13

2.1. PROJEKTOVÉ PROCESY... 13

2.1.1. Skupiny procesů... 13

2.1.2. Inicializace ... 14

2.1.3. Plánování ... 15

2.1.4. Provádění... 18

2.1.5. Kontrola ... 19

2.1.6. Uzavírání... 21

3. METODIKA PRINCE2... 23

3.1. MODEL PROJEKTOVÝCH PROCESU DLE METODIKY PRINCE 2 ... 23

3.1.1. Řízení projektu (DP) ... 23

3.1.2. Začátek projektu (SU) ... 24

3.1.3. Inicializace projektu (IP) ... 24

3.1.4. Řízení vymezení etap (SB) ... 25

3.1.5. Kontrola etap (CS) ... 25

3.1.6. Řízení dodávky výsledku (MP) ... 26

3.1.7. Ukončení projektu (CP) ... 26

3.1.8. Plánování (PL)... 26

3.2. KOMPONENTY... 27

3.2.3. Plány ... 28

3.2.4. Kontroly ... 28

3.2.5. Řízení rizik ... 29

3.2.6. Kvalita v prostředí projektu ... 30

3.2.7. Řízeni dodávky ... 30

3.2.8. Kontrola změn ... 30

3.3. TECHNIKY... 31

3.3.1. Plánování zaměřené na produkt... 31

3.3.2. Kontrola změn ... 31

3.3.3. Revize kvality... 31

3.4. SILNÉ A SLABÉ STRÁNKY... 32

4. SHRNUTÍ ANALÝZY METODIK PMBOK A PRINCE2 ... 33

5. SESTAVENÍ VHODNÉ METODIKY PRO MALOU ICT FIRMU ... 35

5.1. ANALÝZA SOUČASNÉHO STAVU FIRMY MEMOS SOFTWARE, S. R. O... 35

5.1.1. Organizační struktura. ... 35

5.1.2. Proces projektu ... 35

5.2. O^ČEKÁVANÝ PŘÍNOS... 37

5.3. VÝBĚR METODIKY... 37

5.3.1. Role ... 39

5.3.2. Nástroje... 39

5.3.3. Šablony projektové dokumentace ... 39

5.4. NASAZENÍ METODIKY... 40

5.4.1. Školení... 40

5.4.2. Pilotní projekt ... 41

5.5. SHRNUTÍ... 41

6. ZÁVĚR... 42

7. SEZNAM POUŽITÉ LITERATURY ... 43

Úvod

V dnešní době je velká část zakázek v podnicích a jiných organizacích prováděna formou projektů. Tyto projekty jsou často rozhodující součástí strategického řízení podniku. Dalo by se říci, že projekty v současnosti hýbou světem. Pokud chceme stručně vystihnout, co je takovým projektem, jednoduše můžeme říci, že projekt je organizované úsilí k dosažení určitého cíle.

Organizace používají projekty k řešení svých vlastních potřeb nebo je provádějí na základě smluv pro jiné organizace, využívají tím příležitostí na trhu. Projekty mají velké množství společných znaků, na jejichž základě je možné je řídit, avšak zacházení s nimi je třeba přizpůsobit jejich velikosti, rozpočtu a délce trvání.

V této práci se snažím zevrubně popsat dvě z nejčastěji používaných metodik pro řízení projektů, a to metodiku, jejímž autorem je Project Management Institute a která je sepsána v knize Project Management Body Of Knowledge (dále PMBOK) a metodiku PRINCE2 (PRojects IN Controlled Environment), jejímž autorem je britská vláda, která vyžaduje její užití pro plnění vládních zakázek. Jelikož metodiky jsou rozsáhlé a pokrývají takřka celý životní cyklus projektu, zaměřila jsem se při jejich analýze na popis projektových procesů. Dalším cílem této práce je nastínit metodiku, která pokryje fázi vývoje, v malé ICT firmě.

1. Projekt management

Projekt management jako samostatná disciplína nabírá na důležitosti díky velkému množství jednorázových projektů, které se v současné době ve společnostech provádí. Velkou měrou tomu přispěl i ústup čistě funkčních organizací společností a rozvoj procesně orientované organizace.

Projekty mohou být i součástí strategického řízení podniku. Společnosti používají projekty k řešení svých vlastních potřeb nebo, a to častěji, je provádí na základě smlouvy pro jinou společnost. Rozsah i velikost projektů jsou velmi různorodé.

1.1. Projekt

"projekt je dočasné úsilí s cílem vytvořit unikátní produkt nebo službu"[LIT1]

Řízení projektů odlišují od jiných manažerských činností tři typické znaky:

Dočasnost

Dočasností projektu rozumíme, že projekt má jasně stanovený termín začátku a konce. Konce projektu je dosaženo, jakmile jsou splněny jeho cíle nebo v případě, kdy je zjevné, že cílů projektu není možné dosáhnout, nebo není nutné, aby projekt nadále pokračoval.

Dočasnost se netýká výsledků projektu – služeb nebo produktů. Většina projektů je vedena se záměrem vytvořit trvalý výsledek.

Dočasnost se může týkat i dalších aspektů projektu:

- Obchodní příležitost nebo mezera na trhu jsou obvykle dočasné – většina projektů má omezený časový rámec, ve kterém má vzniknout výsledek projektu.

- Týmy pracující na projektu zřídkakdy přežijí po skončení projektu – většina projektů je vykonávána týmem, který byl pro tento účel vytvořen a po dokončení projektu je tým rozpuštěn.

Jedinečnost produktu, služby nebo výsledku

Každý projekt je jedinečný, protože se sám o sobě provádí pouze jednou a je dočasný. I přes to, že oblast, ve které je projekt prováděn je velmi široká nebo zadání jiného projektu je téměř shodné se zadáním jiného projektu. Vždy se najdou odlišnosti, které tvoří projekt unikátním – jiný zákazník, jiný čas, drobná odchylka v požadavcích atd.

Omezenost zdrojů

Projekty se realizují za použití zdrojů – lidských i materiálních. Manažer projektu musí dobře organizovat lidské zdroje, aby byly využity dostupné zdroje materiální.

1.2. Projekt management

Projekt management je užití znalostí, schopností, nástrojů a technik na projektové činnosti k dosažení projektových požadavků. Zjednodušeně lze projekt management shrnout do 5 kroků:

1. Definování 2. Plánování

3. Vedení

4. Monitorování 5. Ukončení

Detailnější popis projekt managementu a jeho technik se nachází v kapitolách o jednotlivých metodikách.

1.3. Projekt Manager

Projekt manager stanovuje cíle, připravuje plány, organizuje, shání vhodné pracovníky, kontroluje, vydává pokyny, tráví čas prací s velmi různorodou skupinou lidí a všestranně dohlíží na to, aby byl projekt dokončen s uspokojivým výsledkem, včas a v rámci daného rozpočtu. Manažer by se ale neměl zapojovat do úkolů pracovníků, i kdyby je sám vykonal efektivněji než jeho tým.

Připravoval by tím své pracovníky o motivaci a sám sebe o čas, který by měl věnovat řízení projektu.

Manažer projektu musí především umět pracovat s lidmi, efektivně jim přidělovat práci a kontrolovat její plnění. V praxi se člověk často stává manažerem projektu, protože byl výborným pracovníkem. Nicméně prokázaná technická nebo odborná kvalifikace ve skutečnosti znamená schopnost řešit odborné problémy nebo představuje technické dovednosti, které nezahrnují schopnost jednat s lidmi. Pro mnoho technicky vzdělaných lidí, kteří se náhle stanou manažery projektu, může být velmi obtížné naučit se jednat s lidmi. Chování měkkých systémů je o poznání složitější a méně předvídatelné než chování tvrdých systémů.

Motivace

Motivace pracovníků je pro práci na projektu naprosto klíčová. Pokud pracovníci ztratí motivaci, tak s vysokou pravděpodobností nebude projekt úspěšné dokončen (tj. s uspokojivou kvalitou, v rámci plánu a rozpočtu).

Teorie hierarchie potřeb

Teorie hierarchie potřeb Abrahama Maslowa tvrdí, že motivace nepřichází zvenčí, ale vzniká v samotném pracovníkovi, pokud není negativně ovlivněna nevhodným působením manažera.

Pracovník je motivován k dosažení určitého cíle v důsledku své vlastní vnitřní potřeby. Každý člověk má 5 úrovní potřeb, přičemž platí, že uspokojená potřeba ztrácí svůj motivační účinek:

1. fyziologické (potrava, spánek, domov …) 2. jistota a bezpečí

3. sociální potřeby

4. touha po uznání a ocenění 5. seberealizace

Ke každé úrovni potřeb existují jejich uspokojovače:

Úroveň Ve vztahu k práci Jiné

5. Stanovení vlastních cílů Koníčky nebo dobrovolná činnost 4. Získání ocenění firmy Zvolení do občanské rady

3. Schůzky zaměstnanců nebo práce ve výborech

Členství v klubech

2. Programy pojištění zaměstnanců Bydlení na bezpečném místě 1. Dostatečný plat na nákup nezbytných

potřeb a rozumná pracovní doba

Dostupnost vhodných obchodů

Tabulka 1:Uspokojovače potřeb

Zdroj: „Základy řízení pro technické a vědecké pracovníky“, Milton D. Rosenau, Jr. 1982, Univerzita Jižní Kalifornie.

1.4. Nej č ast ě jší p ř í č iny selhání projektu

Řada projektů končí neúspěšně a přináší tak svým investorům místo očekávaného přínosu velké ztráty. Příčiny neúspěchu vznikají nejčastěji již na začátku projektu, málokterý projekt skončí krachem kvůli chybě, která se stane v jeho závěru. Zde uvádím několik nejčastějších chyb, které zapříčiňují selhání projektu:

• Nedostatek v koordinaci zdrojů a činností

• Nedostatek komunikace mezi zainteresovanými stranami, který vede k tomu, že je dodán produkt jiný, než zákazník chtěl.

• Podcenění odhadů délky trvání činností a nákladů, které vede k prodloužení a prodražení projektu.

• Nedostatečné metriky a kontrola ukazatelů

• Podcenění plánování zdrojů, aktivit a v tvorbě harmonogramu

• Nedostatek kontroly průběhu projektu a prací na něm.

• Nedostatečná kontrola kvality, která zapříčiňuje dodání neakceptovatelného nebo nepoužitelného výsledku.

2. Metodika PMI – PMBOK

Standard PMBOK (Project Management Body Of Knowledge) byl vyvinut PMI (Project Management Institute). První verze vznikla již v roce 1987, ta měla standardizovat a zdokumentovat obecně přijímané informace a praktiky projekt managementu. V roce 2004 vyšla již třetí verze, která je základním studijním materiálem pro všechny, kteří se zajímají o projekt management.

PMBOK Guide je všeobecně považován za standard nebo základ projekt managementu.

2.1. Projektové procesy

Všechny projekty, nezávisle na odvětví, jehož se týkají, jsou složeny z procesů. Procesem můžeme rozumět sled akcí za běžným účelem vytvořit výsledek. Procesy se týkají všech zdrojů projektu, ale jsou to lidé, kteří je provádějí.

Rozlišujeme dva základní typy procesů, přičemž není možné v rámci projektu mít procesy pouze jednoho typu:

1. Orientované na produkt

Tyto procesy jsou činnosti, které vedou k dokončení fází projektu a životního cyklu projektu.

Odvíjejí se od odvětví, kterého se projekt týká. V IT se jim věnují metodiky vývoje softwaru (např. RUP, Extrémní programování ad.)

2. Orientované na projekt

V těchto procesech se jedná o univerzální činnosti společné všem projektům. Tyto činnosti tvoří jádro PMBOK.

2.1.1. Skupiny proces

Jednotlivé skupiny procesů jsou velmi úzce provázány, výstup jedné skupiny slouží jako vstup skupiny jiné. Některé skupiny procesů jsou průběžné a je možné je dekomponovat na dílčí procesy.

Aktivity v rámci jednotlivých skupin procesů vedou k jedné věci – dokončení projektu. Činnosti v jedné skupině umožňují přesunout se do skupiny další. Těchto 5 skupin – inicializace, plánování, provádění, kontrola a uzavírání – nejsou sledem událostí, ale integrovanými procesy, kde aktivity v rámci jedné skupiny se mohou překrývat s aktivitami ve skupině jiné.

Následující graf zobrazuje průběh jednotlivých skupin procesů v závislosti na čase a náročnosti na činnost. Logicky nejnáročnější skupinou procesů je samotné provádění projektu –

„Executing“.

Diagram 1:Graf skupin projektových procesů dle PMI. [LIT3]

2.1.2. Inicializace

Inicializace projektu přiznává existenci problému nebo obchodní příležitost, které je třeba řešit.

Inicializace je úvodní fází projektu, ve které se stanovuje autorita projekt manažera k zahájení projektu. Jakmile je promyšleno řešení problému, přenáší se zodpovědnost za projekt z vyššího managementu na projekt manažera.

Inicializační fáze sestává z několika činností:

- Identifikace potřeb

o Např. snížení nákladů, zvýšení výnosů, snížení ztráty, zvýšení produktivity, vyřešení obchodního nebo technického problému, využití příležitosti na trhu atd.

- Tvorba realizační studie

o Realizační studie slouží k dokázání existence problému, dokumentace příležitosti a určení, zda projekt vyřeší problém nebo využije onu podnikatelskou příležitost.

Realizační studie se také může zabývat náklady navrhovaného řešení ve vztahu k očekávaným výnosům.

- Identifikace obchodních potřeb

o Projekt musí podporovat vizi a strategii podniku. Identifikace obchodních potřeb nebo podnikatelské příležitosti slouží k přezkoumání problému, příležitosti a navrhovaného řešení, aby bylo zřejmé, že očekávaný přínos projektu je ve schodě s obchodní vizí a cíly podniku.

- Tvorba popisu produktu

o Úvodní popis produktu slouží k určení očekávaného výstupu projektu. Může se jednat o výrobek, službu, nebo o popis budoucího stavu. Úvodní popis produktu nemusí být přesnou specifikací toho, co má projekt vytvořit, avšak za jistých okolností to tak být může a je to i vhodné.

- Tvorba základní listiny projektu

o Tento dokument vytváří vyšší management a umožňuje projekt manažerovi zahájit práce na projektu s podporou, svolením a důvěrou vyššího vedení.

- Výběr projekt manažera

o Projekt manažer je oficiálně jmenován v základní listině projektu, ale jeho zapojení v projektu obvykle přichází dříve v této skupině procesů. Projekt manažer bude potřebovat znát očekávání od jeho role v organizační struktuře v daném podniku (funkční, maticová, projektová nebo složená). Role v organizační struktuře je důležitá, protože určuje míru autority a moci, kterou může projekt manažer v rámci projektu očekávat.

2.1.3. Plánování

Plánování je ze své podstaty iterativní činností. Projekt manažer i projektový tým se během průběhu projektu k plánování stále vracejí. Zvláště ve velkých projektech by do plánování měli zasahovat i investoři projektu. Zákazník pak má lepší přehled o průběhu prací na projektu a projekt manažer je naopak ujištěn, že práce na projektu pokračují v souladu se zájmy investora.

V rámci rozsáhlých projektů se přistupuje na takzvané „Rolling wave planning“ – plánování ve vlnách, kde se podrobně plánují spíše nejbližší činnosti projektu než činnosti, které se budou vykonávat v daleké budoucnosti.

Na trhu jsou k dispozici nástroje pro podporu plánování, např. MS Project. Pro podporu časového plánování projektu můžeme použít např. Ganttův diagram a síťové grafy.

Plánování sestává z mnoha činností:

- Stanovení rozsahu projektu

o Rozsah projektu je dokument, který popisuje nezbytné a požadované práce na projektu, aby bylo dosaženo stanoveného cíle projektu. Pokud jsou k tomu důvody, je možné během projektu měnit jeho rozsah.

- Vytvoření projektového týmu

o Je to právě projektový tým, který vytváří požadované hodnoty projektu. Proto je třeba brát zřetel na jeho výběr. Tým zároveň poskytuje informace projekt manažerovi – podklady pro plánování, informace o průběhu prací, o případných problémech atd.

Vedoucím projektového týmu je projekt manažer.

- Tvorba hierarchické struktury činností (Work Breakdown Structure)

o Hierarchická struktura činností obsahuje popis toho, co má být v rámci projektu dodáno. Tato činnost není pouze v rukou projekt manažera, ten k tomu potřebuje podklady a pomoc projektového týmu, protože ti jsou v každodenním kontaktu s pracemi na projektu a budou je vykonávat v průběhu jednotlivých fází. WBS je hlavním podkladem plánování, odhadů a tvorba harmonogramu během projektu.

- Počáteční odhad rizika

o Není možné se v rámci projektu riziku vyhnout, některá rizika mají dokonce pozitivní dopad na projekt. Obecně za riziko považujeme jakoukoli hrozbu (nebo v pozitivním případě příležitost), která by mohla ovlivnit dokončení projektu. Počáteční odhad rizik je zaměřen na rizika ohrožující zdroje, proveditelnost a požadavky na dokončení projektu.

- Síťový graf

o Síťový graf ilustruje sled/tok jednotlivých aktivit během projektu. V síťovém grafu musí být obsažen každý prvek hierarchické struktury činností (WBS)

- Časové a nákladové odhady

o Pokud časové odhady zaznamenáme do síťového grafu, můžeme stanovit poměrně přesný odhad celkové doby projektu.

o Kritická cesta je (časově) nejdelší možná cesta z počátečního bodu síťového grafu do koncového bodu grafu. Aktivity, které neleží na kritické cestě, nemohou zkrácením svého trvání konečný termín projektu zkrátit.

- Harmonogram projektu

o Harmonogram ovlivňuje především disponibilita zdrojů a časové omezení projektu.

Slouží k rozvržení práce v čase tak, aby byl projekt dokončen včas.

- Rozpočet projektu

o Rozpočet projektu shrnuje všechny náklady, cash flow a nakládání s penězi.

- Dokončení odhadu rizik

o Souhrnná kvantitativní i kvalitativní analýza rizik. Rizikům je přiřazena důležitost a pravděpodobnost toho, že ohrozí projekt.

- Přidělení zodpovědnosti za rizika

o Ke každému riziku v předchozím bodě je přiřazen jeho vlastník, který za něj nese odpovědnost.

- Quality management plán

o Quality management plán mapuje firemní politiku kvality na projekt. Např. ISO 9000.

- Analýza požadavků investorů

o Business analýza, při které se zjišťují požadavky investora / zákazníka a jeho očekávání od projektu. Jedná se o klíčové podklady, na jejichž základě bude vytvořen výsledek projektu. Proto je záhodno analýzu požadavků nepodcenit.

- Plán kontroly změn

o Plán kontroly změn je založen na stanoveném rozsahu projektu. Změnou rozumíme jakoukoli odchylku od stanoveného rozsahu. V plánu kontroly změn by mělo být napsáno, jak se může rozsah projektu měnit a jaké jsou procesy pro schválení změn.

- Organizační plán

o Zjednodušeněřečeno, organizační plán definuje, kdo dělá co a za co je zodpovědný.

- Plán komunikace

o Říká se, že projekt manažer stráví 90% času na projektu komunikací. Plán komunikace shrnuje, kdo potřebuje jaké informace a jak a kdy je dostane. Plán specifikuje schůzky týmu, reporty, očekávání od reportů a očekávání od každodenní komunikace členů týmu.

- Dokončení projektového plánu

o V tomto dokumentu je sepsáno vedení a vykonávání jednotlivých fází projektu. Plán musí být schválen vyšším vedením společnosti a investory/zákazníkem. Jeho účelem je shrnout předpoklady, rozhodnutí a rizika projektu stejně jako harmonogram, náklady, rozsah projektu a podklady.

- Oficiální spuštění projektu

o Jak už bylo řečeno výše, plánování je iterativní proces, ke kterému se projekt manažer vrací během všech fází projektu. Jakmile je plán schválen, mohou práce na projektu začít.

2.1.4. Provád

ní

Provádění je skupina aktivit, které tvoří samotné práce na projektu, které umožňují dodat výsledek projektu na základě plánu. Provádění je velmi úzce provázáno s plánováním a kontrolou. Je třeba mít na paměti, že projekty selhávají ze začátku ne v závěru.

- Autorizace prací na projektu

o Autorizací prací na projektu rozumíme jejich započínání v souladu s harmonogramem, předchozími a navazujícími pracemi.

- Výběr dodavatelů

o Většina projektů spolupracuje s dodavateli, proto je třeba uskutečnit jejich výběr a vést s nimi jednání.

- Sepsání smluv

o Smlouva typicky představuje nabídku a její podepsání oběmi stranami.

- Soulad s quality assurance

o V průběhu prací na projektu je třeba zajistit, aby práce byly v souladu s plánem kvality. Nedodržení plnu kvality může vést až k předělávání prací, placení smluvních pokut a zpoždění projektu.

- Šíření informací o projektu

o V souladu s plánem komunikace je třeba šířit potřebné informace o projektu.

Investoři projektu potřebují mít přehled o průběhu prací nebo případných problémech. Informace o projektu také potřebuje získávat vyšší vedení společnosti.

- Vedení týmové práce

o Práce projekt manažera spočívá i v komunikaci s projektovým týmem, ujišťování o jeho odbornosti, případně zajištění školení. Úspěch projektu se odvíjí od schopností členů týmu. Vedení týmu také ovlivňuje organizační struktura dané společnosti.

2.1.5. Kontrola

Kontrolou rozumíme činnosti, které ověřují, že se projekt ubírá správným směrem na základě plánu a případně zajišťuje nápravu v případě neshody s plánem. Projekt manažer ověřuje, že náklady projektu nepřekračují stanovený rozpočet a práce na projektu jsou v souladu s harmonogramem.

Manažer projektu zjišťuje stav prací prováděných přímo projektovým týmem a podpůrnými týmy.

Přesnému zjištění stavu projektu velmi napomáhá jeho rozdělení na malé úkoly.

- Kontrola kvality

o Kontrola kvality slouží k ověření toho, že výsledky práce jsou v souladu s přijatými standardy.

- Ověření rozsahu

o Ověření rozsahu je proces, který verifikuje výsledky práce oproti původně stanovenému rozsahu projektu. Typicky tak činí zákazník při dokončení fáze nebo milníku projektu, který formálně přebírá produkt. V případě, že výsledky neodpovídají plánovanému rozsahu, je třeba přistoupit k předělání, dodělání nebo jiným opatřením, které projekt zpozdí.

- Implementace kontroly změn rozsahu

o Kontrola změn rozsahu zabezpečuje řízení se dokumentovanými pravidly pro změnu rozsahu.

- Vedení managementu dodávky

o Tento proces zabezpečuje precizní dokumentaci, kompletaci a ověření kvality dodávaného produktu. Zároveň se tím sleduje proces změny rozsahu projektu – management dodávky hlídá a dokumentuje případné změny rozsahu. V některých projektech může být řízení dodávky i systémem řízení změn, v jiných je řízení změn jeho součástí.

- Dohled nad kontrolou změn

o Manažer projektu by měl chránit svůj projekt před zbytečnými změnami. Pokud je změna shledána za nutnou, je třeba ji ověřit, zdokumentovat a analyzovat její dopad na náklady a zdroje projektu. Projekt manažer musí jednat v souladu s plánem řízení změn.

- Sledování a kontrola rizik

o Sledování a kontrola rizik je proces pečlivého sledování identifikovaných rizik, monitorování zbytkových a identifikování nových rizik, zajišťování realizace rizikových plánů a hodnocení jejich účinnosti na omezení rizik. Při monitorování a řízení rizik se zaznamenávají metriky, související s implementací protirizikových plánů. Sledování a kontrola rizik je nepřetržitý proces v rámci životního cyklu projektu. Jak projekt pokračuje, rizika se mění, vznikají nová nebo dříve předpokládaná rizika mizí. Dobrý proces sledování a řízení rizik poskytuje informace, které pomohou dělat účinná rozhodnutí dříve, než se riziko objeví. Kvůli pravidelnému hodnocení přijatelnosti rovně rizikovosti projektu je nezbytná komunikace se všemi zúčastněnými stranami na projektu.

- Zabezpečení podávání informací o stavu projektu

o Projekt manažer je zodpovědný za včasné předávání informací o projektu vyššímu vedení společnosti a investorům projektu. Proto je třeba, aby byl obeznámen se stavem všech úkolu, problémy při jejich plnění nebo případnými dalšími požadavky nad rámec rozsahu. Informace nejsnáze dostane přímo od projektového týmu. Pro předání informací výše vypracovává manažer projektu hodnocení milníků, dodržování harmonogramu, průběžné rozpočty projektu atd.

2.1.6. Uzavírání

Uzavírání projektu je fáze, ke které se naše oči upínají v jeho začátku i v plánování, ale ve skutečnosti bývá mnohem hektičtější, než byly naše původní představy. Ukončení projektu vyžaduje velké úsilí projekt manažera, projektového týmu, projektových investorů a managementu, aby projekt mohl být oficiálně prohlášen za dokončený.

- Kontrola dokumentů

o Formální kontrola dokumentů slouží prověření účetních dokladů. Její intenzita je přímo úměrná manažerově autonomii: čím větší mocí a zodpovědností disponuje, tím více je zodpovědný za rozpočet projektu.

- Dokončení ověření rozsahu

o Ověření rozsahu je kontrolní proces, který zpětně prochází požadavky a porovnává, zda dodávaný produkt požadavkům odpovídá. Ověření rozsahu se typicky dělá na konci jednotlivých fází nebo milníků. Na konci projektu mu může odpovídat podepsání akceptačního protokolu. Když je dosaženo plánovaného rozsahu projektu, je projekt dokončen.

- Ukončení dodavatelských smluv

o Na konci projektu je třeba ověřit, že byly splaceny všechny dluhy dodavatelům.

- Uzavření administrativních záležitostí

o Jakmile je projekt dokončen, musí projekt manažer zkompletovat všechny reporty, zdokumentovat zkušenosti získané během projektu a zaevidovat akceptaci zákazníkem.

- Podání závěrečné zprávy

o Jakmile je dokončena dokumentace projektu, projekt manažer ji spolu se závěrečnými reporty předá zainteresovaným skupinám, které jsou uvedeny v komunikačním plánu.

- Archivace projektové dokumentace

o Projektová dokumentace by měla sloužit i k budoucímu užití jinými projekt manažery, kteří by během své práce narazili na obdobné problémy. Proto je záhodno ji někam archivovat, případně v ní umožnit vyhledávat potřebné informace.

- Uvolnění projektového týmu

o Jakmile jsou dokončeny práce na projektu, tak již déle není třeba projektového týmu.

Ve většině organizačních struktur vytvoří pracovníci nové týmy na jiné projekty.

- Oslava

o Oslava slouží k poděkování týmu a dalším pracovníkům na projektu. Je také dobrou příležitostí pro získání malé zpětné vazby.

3. Metodika Prince2

PRINCE (PRojects IN Controlled Environments) je strukturovaná metodika pro efektivní řízení projektů. Původně byla vyvinuta v roce 1989 organizací CCTA (Central Computer and Telecomunication Agency) jako standard Britské vlády pro řízení projektů v IT. Nyní je metodika hojně využívána nejen v prostředí informačních technologií.

Metodika PRINCE byla v roce 1996 rozšířena na obecnou metodiku projekt managementu.

PRINCE2 se velmi rychle rozšířila a stala téměř standardem pro projektové řízení ve Velké Británii.

Nyní je rozšířena ve více než 50 zemích světa. Nejnovější revize metodiky byla vydána v roce 2005 Office of Government Commerce (OGC), který nahradil CCTA.

PRINCE2 je procesně orientovaná metodika projekt managementu, která nabízí jednoduchý a škálovatelný přístup k řízení různých typů projektů. Každý proces je definován jeho klíčovými vstupy a výstupy spolu s cíli procesu, kterých má být dosáhnuto a činností, která se má během procesu vykonávat.

3.1. Model projektových procesu dle metodiky Prince 2

Diagram 2:Model projektových procesu dle PRINCE2. [LIT2]

3.1.1.

ízení projektu (DP)

Řízení projektu je průběžnou činností, která probíhá od jeho začátku až po konec.

Součásti procesu „Řízení projektu“:

- DP1. Schválení zahájení - DP2. Schválení projektu

- DP3. Schválení etapy nebo „Exception Plan“

- DP4. Poskytování ad hoc pokynů - DP5. Potvrzení ukončení projektu

Tento proces nepokrývá každodenní řízení projektovým manažerem.

3.1.2. Za

átek projektu (SU)

Začátek projektu je první proces v PRINCE. Proces slouží pro zajištění nezbytných předpokladů k inicializaci projektu, jedná se vlastně o jakousi před projektovou činnost.

Očekávaným vstupem tohoto procesu je především cíl projektu a jeho výstupy.

Součásti procesu „Začátek projektu“:

- SU1. Jmenování projektového vedoucího (project executive) a projektového manažera - SU2. Návrh projektového týmu

- SU3. Ustanovení projektového týmu

- SU4. Příprava stručného popisu projektu (Project Brief) - SU5. Definice projektového přístupu (Project Approach) - SU6. Plánování fáze inicializace projektu

3.1.3. Inicializace projektu (IP)

Tato fáze slouží k pečlivému naplánování projektu a jeho průběhu, aby bylo umožněno dosáhnout cílů projektu.

Součásti procesu „Inicializace projektu“:

- IP1. Plánování kvality - IP2. Plánování projektu

- IP3. Dokončování a konečné úpravy případové studie (Business Case) a seznamu rizik

- IP5. Vytvoření projektových souborů

- IP6. Tvorba dokumentu o inicializaci projektu (Project Iniciation Dokument – PID)

3.1.4.

ízení vymezení etap (SB)

Dle principů PRINCE2 musí být každá etapa dokončená a odsouhlasená vedením projektu. Až poté je možné přejít k další etapě.

Cíle procesu:

- ujištění projektového vedení, že bylo dosaženo všech cílů na základě plánu etapy - poskytnutí informací potřebných k pokračování projektu projektovému vedení

- poskytnutí informací potřebných k ověření kompletnosti současné etapy a k autorizaci startu etapy následující spolu s přípustnými odchylkami

- zaznamenání všech měření a ponaučení, které mohou usnadnit práci na dalších etapách nebo projektech

Součásti procesu „Řízení vymezení etap“:

- SB1. Plánování etapy

- SB2. Aktualizace projektového plánu - SB3. Aktualizace případové studie - SB4. Aktualizace seznamu rizik - SB5. Hlášení konce etapy - SB6. Tvorba Exception Plan

3.1.5. Kontrola etap (CS)

Tento proces popisuje dohled a kontrolu projektového manažera, který se ujišťuje, že se etapa ubírá správným směrem a reaguje na neočekávané události. Tento proces tvoří jádro činnosti projekt manažera – jedná se o jeho každodenní činnost.

Součásti procesu „Kontrola etap“:

- CS1. Schválení odvedené práce - CS2. Zhodnocení postupu

- CS3. Zaznamenávání projektových issues

- CS4. Přezkoumání issues - CS5. Zhodnocení stavu etapy - CS6. Hlášení nejdůležitějších údajů

- CS7. Korektura a přijímání nápravných opatření - CS8. Eskalace projektových issues

- CS9. Příjem kompletní odvedené práce

3.1.6.

ízení dodávky výsledku (MP)

PRINCE2 je systém orientovaný na produkt / výsledek. Produkt může být jak fyzická věc jako kniha nebo nehmotná služba. Cokoli, co vznikne v rámci PRINCE2, i dokumenty, je považováno za produkt. Produkty definované metodikou PRINCE2 jsou produkty řízení, na rozdíl od odborných produktů. Kdokoli může vytvořit produkt. Tento proces dělá z projektu produkt a zde se využije nejvíce zdrojů.

Součásti procesu „Řízení dodávky výsledku“:

- MP1. Přijímání balíků odvedené práce - MP2. Odvádění práce

- MP3. Odevzdávání balíků odvedené práce

3.1.7. Ukon

ení projektu (CP)

Další podstatou PRINCE2 je, že projekt musí být kontrolovaně a řádně ukončen, což zahrnuje vyhodnocení výsledků projektu. Zde jsou zaznamenány všechna ponaučení z projektu, vytvořen předávací protokol a naplánovány post-implementační revize.,

Součásti procesu „Řízení dodávky výsledku“:

- CP1. Odstavení projektu

- CP2. Identifikace následných činností - CP3. Zhodnocení a revize projektu

3.1.8. Plánování (PL)

- nejkratší možný čas trvání projektu (souvisí také s náklady) - nejnižší náklady

- nejmenší riziko

- efektivní využití zdrojů

Těchto cílu by mělo být dosaženo zvolením vhodné varianty v závislosti na způsobu řešení a zajištěním rozumného kompromisu dle priority přiřazené výše uvedeným parametrům.

S plánováním aktivit zároveň souvisí plánování lidských zdrojů – tj. přiřazení konkrétních lidí z katalogu zdrojů ke konkrétním úkolům. Ze součtů člověkodnů jsou pak odvozeny požadavky projektu na lidské zdroje a náklady potřebné na tyto zdroje.

PRINCE poskytuje začátek plánování orientovaný na produkt a plánovací rámec aplikovatelný na jakýkoli typ projektu.

Součásti procesu „Plánování“:

- PL1. Návrh plánu

- PL2. Definice a analýza produktů

- PL3. Identifikace činností a jejich závislostí - PL4. Odhady

- PL5. Tvorba harmonogramu - PL6. Analýza rizik

- PL7. Dokončení plánu

3.2. Komponenty

PRINCE2 rozeznává 8 klíčových konceptů zvaných komponenty v projekt managementu.

3.2.1. P

ípadová studie

Případová studie je dokument, který definuje projekt – jeho účel a cíle. Řídí procesy projektu a ujišťuje, že procesy projektu jsou v souladu s cíli projektu a společnosti. Případová studie musí být platná po celou dobu trvání projektu.

3.2.2. Organizace

PRINCE2 zajišťuje podílení dodavatele i klienta na projektu. V organizaci se definují hlavní role osob participujících na projektu a jejich zodpovědnosti.

Hlavní role:

- Vedení projektu o Vedoucí o Uživatel senior o Dodavatel senior - Projekt manager

- Zajištění projektu - Doplňkové role:

o Vedoucí týmu o Podpora projektu

3.2.3. Plány

Plány dle PRINCE2 musí být odsouhlaseny než vstoupí v platnost. Rozlišují se zde 3 úrovně plánů:

- Projektové plány - Plány etap - Týmové plány

Čtvrtý typ plánu – Exception Plan – nahrazuje plán etap v případě, že nastane odchýlení v projektu.

3.2.4. Kontroly

Kontroly zajišťují, že se ve správný čas vytvářejí správné činnosti a že je projekt v souladu s případovou studií.

Hlavní typy kontrol:

- hlášení nejdůležitějších údajů - hlášení výjimek

- zhodnocení výjimek - zhodnocení konečné etapy - ukončení projektu

- tolerance

3.2.5.

ízení rizik

PRINCE definuje riziko jako:

„Možnost vystavení se nepříznivým důsledkům budoucích událostí“ [LIT6]

Řízení rizik je jednou z nejdůležitějších činností řízení projektů, kterou dělá vedení projektu a projekt manager. Projekt manager je zodpovědný za to, že rizika jsou identifikována, zaznamenána a pravidelně přezkoumávána. Mezi hlavní úkoly vedení projektu v oblasti řízení rizik patří:

- upozorňování projekt managera na podstatná externí rizika, která mohou ohrozit nebo jakkoli ovlivnit projekt

- rozhodování o reakcích na rizika, které doporučí projekt manager - udržování rovnováhy mezi rizikovostí a možnými přínosy projektu

Dobrý proces sledování a řízení rizik poskytuje informace, které pomohou dělat účinná rozhodnutí dříve, než se riziko objeví. Kvůli pravidelnému hodnocení přijatelnosti rovně rizikovosti projektu je nezbytná komunikace se všemi zúčastněnými stranami na projektu.

Cílem sledování rizik je určit jestli:

- byla protiriziková opatření implementována podle plánu

- byla protiriziková opatření tak účinná, jak se očekávalo, nebo jestli není třeba vypracovat nějaká nová opatření

- předpoklady projektu dosud platí

- se vliv rizik změnil oproti původnímu stavu s analýzou trendů - nastala spouštěcí událost rizika

- se postupovalo podle příslušných zásad a procedur

- nastala nebo se objevila rizika, která nebyly původně identifikována.

Řízení rizik může zahrnovat volbu alternativních strategií, implementaci plánu protirizikových opatření, provádění nápravných opatření nebo přeplánování projektu. Vlastník protirizikového opatření by měl podávat pravidelné zprávy manažerovi projektu a vedoucímu rizikového týmu o efektivnosti plánu, o libovolných nepředvídaných efektech a jakýchkoli úpravách v průběhu projektu, potřebných ke zmírnění rizika.

3.2.6. Kvalita v prost

edí projektu

Kvalitu produktu můžeme odvozovat od jeho libovolné měřitelné vlastnosti. Požadavky na kvalitu musí být stanoveny předem, stejně jako jejich měřitelnost. Účelem projektu je vytvořit produkt, který bude vyhovovat danému cíli a uspokojí potřeby a očekávání zákazníka. Požadavky na kvalitu jsou stanoveny v inicializační fázi projektu.

4 základní prvky řízení kvality:

1. Systém řízení kvality 2. Funkce záruky kvality 3. Plánování kvality 4. Kontrola kvality

3.2.7.

ízeni dodávky

Řízení dodávky je zaměřeno na kontrolu všech produktů projektu. Dodávka je množina produktů, se kterou je nutné nakládat jako s jedním celkem.

5 hlavních funkcí řízení dodávky:

1. Plánování

2. Identifikace

3. Kontrola

4. Evidence stavu

5. Ověřování

3.2.8. Kontrola zm

n

3.3. Techniky

PRINCE 2 rozeznává tři specifické techniky, které se používají při řízení projektů.

3.3.1. Plánování zam

ené na produkt

PRINCE2 používá plánování zaměřené na produkt na rozdíl od plánování zaměřeného na činnosti. Pokrok je měřen na základě změřitelných skutečností – produktů (např. je postavena zeď), ne na základě odhadnutých aktivit (např. je postaveno 55% zdi).

Plánování zaměřené na produkt zahrnuje tvorbu:

- Podrobné struktury produktu

- Podrobné popsání konečného produktu projektu a každého z produktů - Diagram toků produktů

3.3.2. Kontrola zm

n

V PRINCE2 se se všemi změnami zachází jako s projektovými issues, které dělíme na tři typy:

1. Požadavek na změnu. Ten je založen jako změna v požadavcích na produkt.

2. „Mimo specifikaci“. Zde produkt neodpovídá požadavkům.

3. Dotaz

Za všechny issues nese zodpovědnost projekt manažer a jsou vedeny v issue žurnálu.

Požadavek na změnu musí být odsouhlasen vedením projektu, které potřebuje analýzu dopadů změny. „Mimo specifikaci“ může být vyřízeno přímo projekt manažerem, pokud to spadá do před- definovaných limitů tolerance. Vedení projektu může uznat „mimo specifikaci“ beze změny nebo výhrady.

3.3.3. Revize kvality

PRINCE2 požaduje, aby byl výsledný produkt kvalitativně přezkoumán. Za tímto účelem se vedou schůze, na kterých se kvalita přezkoumává. Tyto schůze nemají za cíl vyřešit problémy s kvalitou, ale pouze je identifikovat.

3.4. Silné a slabé stránky

PRINCE2 je metodikou, která má za cíl řídit vysoce standardizované projekty. Je výsledkem letité zkušenosti s řízením projektů. Poskytuje všechny požadované dokumenty jako zdarma dostupné šablony a tím usnadňuje její přípravu. Je snadno přizpůsobitelná specifickým organizacím nebo projektům. Její použití je zdarma, organizace může uvádět používání metodiky PRINCE2 bez nutnosti platit jakékoli poplatky. PRINCE2 poskytuje referenční příručku i dokumentaci k metodice, takže organizace si nemusí vytvářet vlastní metodiku za účelem školení zaměstnanců.

Navzdory tomu existuje velké množství organizací, které trpí tzv. PINO (Prince In Name Only / Prince pouze ve jménu) - nešetrným způsobem vyberou části metodiky a vynechají její základní principy. Toto samozřejmě není slabou stránkou metodiky jako spíše jejích uživatelů. Další spornou stránkou je velmi silná dokumentace, kterou metodika poskytuje, což v některých organizacích může vést k produkování dokumentace, která k ničemu není a akorát komplikuje projekt. Stejně tak může být přílišná dokumentace na škodu při malých projektech, kdy by zabrala více času než samotné práce na projektu. Dokumentace k metodice poskytuje odškrtávací seznam bodů, které by se při jednotlivých fázích měly plnit, avšak jejich slepé, dalo by se říci až byrokratické následování, bez přizpůsobení konkrétnímu projektu, akorát projekt prodlouží a zahltí zbytečnými činnostmi.

4. Shrnutí analýzy metodik PMBOK a PRINCE2

PRINCE2 je metodika čistě zaměřená na životní cyklus projektu, která popisuje šest z osmi hlavních procesů od začátku projektu do jeho uzavření. Zbývající dva, plánování a řízení projektu, jsou průběžné procesy, sloužící k podpoře ostatních šesti. Dohromady zahrnuji 45 podprocesů. Dále jsou v systému tzv. komponenty, což můžou být jiné procesy nebo i dokumenty. A konečně, PRINCE2 popisuje tři techniky: „Plánování zaměřené na produkt“, „Revize kvality“ a „Kontrola změn“. Celá kniha „Managing Succesfull Projects with PRINCE2“ [LIT6] je snadno srozumitelná a poskytuje dokumentaci metodiky, diagramy procesů a rady a tipy.

Mezi filozofiemi PMBOKu a PRINCE2 je řada zajímavých odlišností. PRINCE2 rozlišuje mezi technickými fázemi a fázemi managementu. Technické fáze jsou obvykle typické odbornými činnosti, zatímco manažerské fáze obsahují spíše rozhodování, potvrzování a vykonávání autority.

Tyto fáze se mohou, ale nemusí krýt. Další odlišnosti jsou postřehnutelné v anglické terminologii.

PMBOK vnímá fázi jako „Množinu logicky souvisejících aktivit na projektu, obvykle vedoucí k dokončení významnější dodávky“ [LIT1]

Životní cyklus projektu dle PRINCE2 nezačíná původní potřebou, poptávkou po jejím řešení a studií proveditelnosti – tyto věci jsou brány jako vstupy nebo jako samostatné projekty. PRINCE2 předpokládá, že projekty existují ve smluvním kontextu a činnost uzavírání smluv a vyjednávání přenechává jiným, specializovaným, metodikám. "Většina fází projektu v terminologii PRINCE2 budou části 'Implementace' v rámci životního cyklu produktu“ uvádí [LIT6]. Naproti tomu PMBOK uznává vyjednávání a sepisování smluv jako plnohodnotnou součást projektu.

S tím souvisí i pohled na projekt jako celek. PRINCE2 nahlíží na projekt spíše ze strany dodavatele řešení. Oproti tomu PMBOK popisuje projekt od jeho prvopočátku a spíše ze strany majitele projektu – zákazníka.

Z pohledu životního cyklu produktu by se dalo hovořit o prostoru pro zlepšení v obou metodikách v oblasti podpory a následné péče po dodání produktu. Dodaný produkt může být vynikající a dle specifikace, ale pokud není pečlivě vyřešeno finální předání zákazníkovi, může být reakce na něj až odmítavá.

Obě metodiky jsou přínosným čtením popisující procesy během projektu, jejich vzájemnou interakci, vstupy, výstupy, aktéry a plno věcí, které by se během projektu neměli zanedbat, nicméně

je třeba míti na paměti, že pouhým slepým následováním metodik, bez ohledu na konkrétní podmínky projektu, nebude zaručen úspěch projektu. Metodiku je třeba volit s ohledem na velikost projektu a jeho rozpočet. Zároveň by měla být v souladu s metodikou orientovanou na vývoj produktu.

5. Sestavení vhodné metodiky pro malou ICT firmu

5.1. Analýza sou č asného stavu firmy Memos Software, s. r. o.

Memos Software, s. r. o. je dynamická společnost, která působí na trhu informačních technologií od roku 2003. Těžiště její činnosti spočívá v zakázkovém vývoji software dle konkrétních požadavků klientů (webové aplikace, SMS řešení, doplňky pro MS Outlook), v implementaci informačních systémů a personálním outsourcingu. Má několik vlastních produktů, které prodává. Zaměřuje se na zákazníky po celém světě a využívá výhody nízké ceny pro zahraniční zákazníky. Projekty jsou velmi malé a to jak finančně, tak personálně. V současné době má společnost 20 zaměstnanců. 5 na plný úvazek, zbytek jsou studenti.

Na pomoc při řízení projektů používá společnost vlastní CRM řešení eWay s modulem pro evidenci projektů, evidenci docházky a plánování zdrojů. Pro zadávání problémů během projektu a pro účely testování používá vlastní systém BugTracker. Projekt manažeři ke své činnosti používají Microsoft Project. Největším problémem ve své činnosti shledávají nedostatky v možnostech plánování zdrojů a v personálních zdrojích obecně. V současné době pracuje společnost celkem na 14 projektech. Zaměstnanci mohou pracovat v kancelářích v sídle společnosti, u zákazníka, nebo pokud to projekt dovoluje, tak z domova. Projekty jsou řízeny ad hoc stylem.

5.1.1. Organiza

ní struktura.

Vedení společnosti tvoří 2 společníci, z nichž jeden má na starosti projekty a řízení informatiky a druhý personální řízení a finance. Projekty vede celkem 6 projekt manažerů, kteří pracují ve společnosti na částečný úvazek při studiu vysoké školy. Zbytek společnosti jsou programátoři a testeři.

5.1.2. Proces projektu

Na následujícím diagramu je zobrazen proces projektu, jak je v současné době provozován ve společnosti Memos Software, s. r. o.

V procesu jsou v současné době zachyceny pouze inicializační fáze, tvorba plánů a detailních popisů produktu, samotná fáze vývoje produktu a dokončení produktu. Chybí zde popis procesu vývoje produktu a v celém projektovém procesu není kontrola. Odhady se tvoří již v inicializační fázi projektu v rámci tvorby nabídky a dále není jejich specifikace, také plánování je zde uvedeno pouze jako jedna činnost, ne průběžný proces. Tyto nedostatky spatřuji spíše v zaznamenání procesu než v tom, jak je proces ve firmě nastaven.

5.2. O č ekávaný p ř ínos

Společnost očekává metodiku, která pokryje fázi implementace v životním cyklu vývoje softwaru na zakázku. Očekává usnadnění řešení problémů vyplývajících z napjatých časových plánů, rozpočtů, malých týmu a nízkých priorit na straně zákazníka. Dále se očekává zavedení řízení rizik, zformalizování procesů kontroly a zabránění růstu malých projektů ve velké.

Mezi další očekávání od navržené metodiky patří:

- Snadnost implementace

- Zavedení standardizované dokumentace - Nezatížení běhu malých projektů

5.3. Výb ě r metodiky

S ohledem na velikost firmy, velikost projektů a jejich rozpočet doporučuji metodiku lehkou.

S tím, že je třeba brát ohled na to, že čím lehčí metodika je, tím větší disciplinovanost se očekává od jejich nositelů.

Průběh projektového procesu je navržen v následujícím diagramu, zachycujícím dokumenty a procesy během jednotlivých fází projektu.

Projektový proces

Předání produktu a podpora Inicializace Vývoj Testování

Obchodní fáze

Objednávka

Smlouva

Stručný popis projektu

Harmonogram projektu Analýza požadavků

Funkční specifikace

Plán komunikace

Seznam rizik Alokace zdrojů

Plán kvality

Vývoj produktu na základě funkční

specifikace

Kontrola kvality

Kontrola průběhu projektu

Kontrola změn

Kontrola rozsahu

Quality Assurance

Akceptační protokol Definiční

dokument

Management dodávky

Vedení jednání se zákazníkem

Zdrojový kód systému

Dokumentace systému

Legenda:

5.3.1. Role

Zde je sepsán seznam rolí vystupujících během projektového procesu. Díky velikosti firmy je jedním zaměstnancem vykonáváno více rolí. Typicky projekt manažer je zároveň obchodníkem, analytikem i architektem.

Název Zkratka Popis Projekt

manažer

PM PM má na starosti vedení projektu.

Vedení spol. Schvaluje projekt, jeho rozpočet a činí významná rozhodnutí během projektu.

Obchodník Jedná se zákazníkem o inicializaci projektu, jeho ceně ad.

Analytik Jedná se zákazníkem o jeho požadavcích na systém.

SW Architekt Navrhuje architekturu systému.

Developer Vyvíjí systém.

Tester Ověřuje kvalitu systému.

5.3.2. Nástroje

Pro podporu řízení projektu bude využito podpůrného softwaru.

Software Účel

MS Project 2003 - plánování - časové odhady

- přiřazení zdrojů k aktivitám - odhady nákladů

eWay - sledování docházky - evidence projektů - CRM

- Sledování kapacit zdrojů - Zadávání úkolů

- Úložiště projektové dokumentace - Reporty nad uloženými daty

BugTracker - Zadávání chyb ve vyvíjeném produktu - Zadávání nových požadavků

MS Visio - Tvorba diagramů

MS Word - Šablony projektové dokumentace - Tvorba nabídek a specifikací MS Excel - Kalkulace nákladů projektu

Tabulka 2: seznam podpůrného softwaru pro řízení projektu

5.3.3. Šablony projektové dokumentace

Součástí metodiky budou i šablony dokumentů pro MS Word.

Seznam šablon projektové dokumentace:

Název šablony Odpovědná role (autor

dokumentu)

Nadřízená role (schvalovatel dokumentu)

Popis

Definiční dokument projektu

PM Vedení spol. Dokument, který obsahuje

následující prvky:

− Rozsah

− Zdroje

− Časové vymezení

− Kvalita

− Rizika

Akceptační protokol PM Zákazník Dokument potvrzující předání díla bez nebo s výhradami a obsahující popis díla a seznam případných výhrad.

Zápis z jednání PM Zákazník/Vedení spol.

Dokument obsahuje body jednání a seznam přítomných. Je schvalován oběmi jednajícími stranami.

Plán komunikace PM Vedení spol. Dokument obsahující tok jednotlivých projektových dokumentů mezi aktéry projektu.

Analýza požadavků Analytik PM / Zákazník Dokument obsahující seznam klientských požadavků na vyvíjený systém, jejich

Požadavek na změnu Zákazník / PM PM / Vedení spol. Dokument obsahující požadavek na změnu systému. Obsahuje popis změny a odhad její náročnosti.

Funkční specifikace SW Architekt / Development Team

PM / Zákazník Vychází z analýzy požadavků, každému požadavku přiřazuje technický popis jeho řešení.

5.4. Nasazení metodiky

Metodika bude nasazena po schválení vedením společnosti speciálním týmem, pro tento účel vytvořeným.

5.4.1. Školení

Všichni aktéři projektového procesu budou seznámeni s metodikou formou prezentace.

5.4.2. Pilotní projekt

Navrhovaná metodika bude nejprve vyzkoušena na pilotním projektu, aby byla ověřena její proveditelnost v reálném prostředí.

Kritéria pilotního projektu:

- časové omezení 1 – 3 měsíce

- velikost projektového týmu: 1 – 3 pracovníci

- projekt manažer bude zaznamenávat své kroky při řízení projektu

5.5. Shrnutí

V této kapitole byla nastíněna metodika pro řízení projektů ve firmě Memos Software, s. r. o.

Předpokládá se její projednání vedením společnosti a otestováním ve formě pilotního projektu.

Předpokládanou silnou stránkou zavedení metodiky je zvýšení kontroly nad průběhem projektů, udržení jejich rozsahu a nákladů. Naopak očekávanou slabou stránkou bude zvýšení režijních nákladů projektu, které bude souviset s přechodem od ad hoc řízení na užití metodiky.

6. Závěr

Ve své práci jsem popsala dvě významné metodiky pro řízení projektů a zároveň nabídla možný pohled na jejich srovnání. Obě metodiky poskytují velmi obsáhlý popis životního cyklu projektu, i když z odlišného náhledu. Při jejich studiu je třeba míti na paměti, že metodiku je třeba volit s ohledem na velikost firmy a charakter projektů. Metodiky poskytují jakýsi náhled na to, co by se během projektu mělo dělat, avšak neodpovídají na otázku „JAK?“. Všechny techniky, které metodiky poskytují je třeba přizpůsobit konkrétním situacím. Zároveň jejich slepé následování nikdy nepovede k úspěchu projektu.

Druhou částí práce bylo nastínění metodiky pro malou ICT firmu – Memos Software, s. r. o.

Metodika byla navržena s ohledem na její začlenění na stávající procesy ve firmě a velikost jejích projektů. Brala jsem ohled i na to, aby nevznikala dokumentace sama pro sebe a následování metodiky nezabíralo čas na úkor řízení projektu a provádění prací na projektu. Jedná se o první nastínění metodiky, proto vidím další potenciál této práce v dalším projednávání metodiky, jejím rozvíjení a přizpůsobování konkrétním potřebám organizace a dále její uvedení v praxi za pomoci pilotního projektu.

7. Seznam použité literatury

[LIT1] Project Management Institute : A Guide to the Project Management Body of Knowledge (PMBOK Guide) -- 2000 Edition, ISBN 1-880410-23-0

[LIT2] www.prince2.com [LIT3] www.pmi.org

[LIT4] Joseph Phillips : PMP Project Management Professional Study Guide; McGraw-Hill/Osborne;

ISBN 0-07-223062-2

[LIT5] D. Rosenau Jr., Milton: Řízení projektů; Computer Press 2000; ISBN 80-7226-218-1 [LIT6] Managing succesful project with PRINCE2