Bankovní institut vysoká škola Praha Katedra matematiky, statistiky a informačních technologií
Implementace metodiky řízení projektů do konkrétní firmy Diplomová práce
Autor:
Bc. Lumír Kváča Informační technologie a management
Vedoucí práce:
Praha
Ing. Václav Šebek, CSc.
Duben, 2012
Prohlášení: Prohlašuji, ţe jsem diplomovou práci na téma „Implementace metodiky řízení projektů do konkrétní firmy“ zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze dne 17. dubna 2012
Bc. Lumír Kváča
2
Poděkování Děkuji vedoucímu diplomové práce Ing. Václavu Šebkovi, CSc. za čas, který věnoval konzultacím a dále za odborné vedení a doporučení, které mi při konzultacích poskytl. Oceňuji obzvláště jeho odborné znalosti a zkušenosti, které mi v průběhu studia předával v poučných přednáškách. I ty byly inspirací pro mou diplomovou práci.
3
Anotace Diplomová práce zpracovává analýzu současného stavu řízení projektů v konkrétní firmě a navrhuje doporučení ke zlepšení v této oblasti na základě metodiky pro podporu projektového řízení a také pro podporu sledování ţivotního cyklu poţadavku na rozvoj informačního systému. Annotation This Thesis looks at the current situation in a common company and analyses how projects are managed in the company. The Thesis suggests recommendation for improvements in this field according to the project management methodology. The focus is to support enviromental monitoring requirement to develop an information system.
4
OBSAH ÚVOD ........................................................................................................................................ 8 1
PROJEKTY A JEJICH ŘÍZENÍ .................................................................................... 9 1.1
Definice projektu ...................................................................................................... 9
1.2
Trojimperativ projektu .......................................................................................... 10
1.3
Ţivotní cyklus projektu informačního systému ................................................... 11
1.3.1 1.4
Milníky projektu ..................................................................................................... 15
1.4.1 1.5
Kritická cesta .................................................................................................... 15
Pravomoci na projektu a projektové role ............................................................ 17
1.5.1
Projektový manaţer .......................................................................................... 17
1.5.2
Sponzor (gestor) projektu ................................................................................. 18
1.5.3
Organizační vedoucí ......................................................................................... 18
1.5.4
Řídící výbor projektu ........................................................................................ 18
1.5.5
Projektový tým ................................................................................................. 18
1.5.6
Projektová kancelář .......................................................................................... 19
1.6
Kritéria hodnocení projektu .................................................................................. 20
1.6.1
Jaká jsou kritéria úspěšného projektu? ............................................................. 20
1.6.2
Základní příčiny neúspěchu projektu ............................................................... 21
1.7 2
Fáze ţivotního cyklu projektu .......................................................................... 11
Ukončování a vyhodnocování projektů ................................................................ 23
METODIKY ŘÍZENÍ PROJEKTŮ PRINCE2 A PMBOK ....................................... 24 2.1
Profesní organizace věnující se projektovým metodikám .................................. 24
2.1.1
OGC (Office of Government Commerce) ........................................................ 24
2.1.2
PMI (Project Management Institute) ................................................................ 24
2.1.3
IPMA (International Project Management Association) .................................. 25
2.2
PRINCE2 (Projects in controlled enviroment) .................................................... 26
2.2.1
Historie metodiky PRINCE2 ............................................................................ 26
2.2.2
Principy PRINCE2 ........................................................................................... 26
2.2.3
Ţivotní cyklus PRINCE2 projektu ................................................................... 28
2.3
PMBOK (Project management body of knowledge) ........................................... 30
2.3.1
Historie metodiky PMBOK .............................................................................. 30
2.3.2
Koncept PMBOK ............................................................................................. 30
2.3.3
Procesy, komponenty a techniky PMBOK ....................................................... 30
5
2.4
3
4
2.4.1
Srovnání PRINCE2 a PMBOK se zaměřením na ţivotní cyklus projektu ....... 33
2.4.2
Srovnání PRINCE2 a PMBOK se zaměřením na dokumentaci ....................... 35
2.4.3
Srovnání dle přístupu k roli projektového manaţera ........................................ 35
2.4.4
Tabulkové porovnání PRINCE2 a PMBOK..................................................... 36
ZPŮSOB ŘÍZENÍ PROJEKTŮ V KONKRÉTNÍ FIRMĚ ........................................ 38 3.1
Představení společnosti ITQ, s. r. o....................................................................... 38
3.2
Motivace k implementaci metodiky řízení projektů ........................................... 38
3.3
Aktuální stav projektového řízení ......................................................................... 39
3.4
Model Projektového řízení v ITQ, s. r. o. ............................................................. 40
3.4.1
Zahájení projektu .............................................................................................. 40
3.4.2
Realizace........................................................................................................... 40
3.4.3
Uzavření ........................................................................................................... 40
3.5
Fungující projektové mechanismy ........................................................................ 41
3.6
Prostory pro zlepšení stávajícího projektového řízení ........................................ 42
3.7
Hlavní cíle implementace metodiky řízení projektů - priority ........................... 43
3.7.1
Zvýšení výkonnosti firmy................................................................................. 43
3.7.2
Optimalizace nákladů ....................................................................................... 43
3.7.3
Transparentní projektové prostředí pro zaměstnance i zákazníka .................... 43
3.7.4
Expanze na trhy mimo ČR................................................................................ 43
VÝBĚR KONKRÉTNÍ METODIKY NA ZÁKLADĚ POTŘEB FIRMY ............... 44 4.1
Shrnutí potřeb společnosti ITQ, s. r. o. ................................................................ 44
4.2
Seznámení se strukturou projektů v popisované firmě ...................................... 44
4.3
SWOT analýza popisovaných metodik řízení projektů v ITQ, s. r. o. ............. 46
4.3.1
PRINCE2 SWOT analýza ................................................................................ 46
4.3.2
PMBOK SWOT analýza .................................................................................. 46
4.4 5
Porovnání PRINCE2 s PMBOK ........................................................................... 33
Výběr metodiky a odůvodnění .............................................................................. 47
PROJEKT IMPLEMENTACE METODIKY DO FIREMNÍHO PROSTŘEDÍ ..... 48 5.1
Stanovení cílů projektu a návrh řešení ................................................................. 49
5.1.1
Cíl projektu ....................................................................................................... 49
5.1.2
Návrh řešení...................................................................................................... 49
5.1.3
Začlenění IS ...................................................................................................... 49
5.1.4
Dokumentace .................................................................................................... 50
5.2
Časový harmonogram ............................................................................................ 51 6
5.2.1
6
Klíčové termíny jednotlivých fází projektu ...................................................... 51
5.3
Projektové role v implementaci ............................................................................. 52
5.4
RACI matice odpovědností .................................................................................... 53
5.5
Informační kanály .................................................................................................. 54
5.6
Klíčové fáze projektu ............................................................................................. 55
5.6.1
Naplánování pracovní zdrojů............................................................................ 55
5.6.2
Příprava rozpočtu.............................................................................................. 55
5.6.3
Výběrové řízení – Projektový manaţer ............................................................ 56
5.6.4
Zpracování klíčové dokumentace ..................................................................... 57
5.6.5
Školení a certifikace ......................................................................................... 58
5.6.6
Výběr softwarového nástroje pro projektové řízení ......................................... 60
5.6.7
Výběr softwarového nástroje pro sledování ţivotního cyklu poţadavku ......... 66
5.7
Dopady na organizační strukturu ......................................................................... 71
5.8
Výstupy projektu implementace ........................................................................... 72
VÝSLEDKY .................................................................................................................... 74
ZÁVĚR .................................................................................................................................... 75
7
Úvod Diplomová práce se věnuje problematice projektů a jejich řízení. Ve své teoretické části se zaměřuje na základní projektové pojmy, kdy popisuje samou podstatu projektu, jeho předpoklady, mechanismy a rizika. Po seznámení s projektovými pojmy se věnuje metodikám projektového řízení PMBOK a PRINCE2. U obou metodik vyzdvihuje jejich základní charakteristiky, popisuje ţivotní cyklus projektu, detailně přibliţuje sloţení jednotlivých fází, procesů a podpůrných nástrojů a závěrem kapitoly o projektových metodikách dochází komparativní metodou k srovnání obou projektových standardů dle několika kritérií, čímţ začíná praktická část práce. Po praktickém srovnání PMBOK a PRINCE2 následuje seznámení s konkrétní firmou, analýzou jejích potřeb a motivace implementace samotného projektového řízení. Je navrţen detailní soupis všech činností, které je třeba pro úspěšné zavedení projektového řízení do firmy provést. Cílem práce je seznámit čtenáře s projektovou problematikou a metodikami projektového řízení a v praktické části pak poskytnout návod, jak efektivně a úspěšně implementovat projektové řízení do dané organizace, včetně výběru projektového manaţera, zaškolení pracovníků, výběr informačního systému pro podporu projektového řízení a také pro podporu sledování ţivotního poţadavku na rozvoj informačního systému.
8
1 Projekty a jejich řízení 1.1 Definice projektu Projektem lze nazvat v podstatě jakoukoliv činnost, jejímţ účelem je vytvoření něčeho nového. Jedná se o činnost jedinečnou, omezenou v čase. Projektem můţe být příprava nového modelu automobilu, projektem můţe být výstavba bytového komplexu, výzkumný program. Z laického pohledu je dobrým příměrem projektu také manţelství nebo zplození potomka. Pod pojmem projekt se schovává spousta dalších činností, které tento objekt aktivit zahrnuje. Cílem této práce je problematiku projektů a jejich řízení přiblíţit a rozebrat do niţší úrovně detailu. Zaměření bude primárně na projekty z oblasti informačních systémů/informačních technologií (IS/IT). Projekt dle IPMA (International Project Management Association): „Projekt je časově, nákladově a zdrojově omezený proces realizovaný za účelem vytvoření definovaných výstupu (rámec naplnění projektových cílu) co do kvality, standardu a poţadavku“. Projekt dle ISO 10 006 (International Organization for Standardization): „Projekt je jedinečný proces sestávající z rady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosaţení předem stanoveného cíle, který vyhovuje specifikovaným poţadavkům, včetně omezení daných časem, náklady a zdroji“. Projekt dle PMI (Project Management Institute): „Projekt je dočasné úsilí, které je prováděno k vytvoření jedinečného produktu, sluţby nebo výsledku.“ Velice dobře vystihuje problematiku IS/IT projektů portál cio.com – ‚Řízení IT projektů je jako ţonglování s kousky ţelé. Není to nic snadného ani hezkého. Informační technologie je obzvláště kluzké odvětví, protoţe je vţdy v pohybu, mění se a přizpůsobuje se.‘1
1
CIO magazine [online]. c2011 Reuters. [cit. 2012-04-01]. Phillips Joseph: Project Management Definition and Solutions. IT Project Management topics covering definition, objectives, systems and solutions. Dostupný z www:
9
1.2 Trojimperativ projektu Projekt představuje tři roviny, ve kterých se pohybujeme: čas, náklady a rozsah. Projekt je definován jako trojdimenzionální - tzv. trojimperativ. Úspěšný projekt tedy musí pro dosaţení poţadovaných cílů tyto tři roviny vyvaţovat věcně - CO se musí udělat, (JAK kvalitně), časově - KDY se to má udělat a nákladově - ZA KOLIK se to musí udělat, (spotřebovaná práce, finance). Pokud není omezení v rovnováze, projekt směřuje ke katastrofě. Mezi nejčastější překáţky patří: nejasnost poţadavků, cílů, problémy s časem - špatný harmonogram, změny zákonů, nedodrţení rozpočtu - cenový pohyb. Ne náhodou trojimperativ projektu odpovídá tomu, jak je v obchodním zákoníku vymezena smlouva o dílo. Kaţdá smlouva musí obsahovat specifikaci plnění (CO), termíny (KDY) a cenu (ZA KOLIK), aby to vůbec smlouva byla. 2
Obrázek 1 - Projektový trojimperativ3
2
STANÍČEK, Zdenko. Moderní management. [online], c2012. [cit. 2012-04-01]. Dostupný z WWW: http://www.ipma.cz/dokumenty_clanky/RP1.pdf 3 NOKES, Sebastian and KELLY, Sean: The Definitive Guide to Project Management: The Fast Track to Getting the Job Done on Time and on Budget. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007. ISBN 978 0 273 71097 4 Dostupný z WWW:
10
1.3 Ţivotní cyklus projektu informačního systému Ţivotní cyklus projektu se skládá z jednotlivých etap, které na sebe navazují a vedou ke zvolenému cíli našeho projektu, tedy správně fungujícímu informačnímu systému (IS). Kaţdý proces vývoje IS můţeme popsat prostřednictvím ţivotního cyklu. Jedná se o cyklus vývoje IS od jeho počátků, kdy zvaţujeme, zda IS inovovat či zavést, přes zjištění poţadavků na IS, tvorbu jednoho nebo více z modelů koncepce/implementace, implementaci samotnou, testování, dokumentace, hodnocení aţ po správu systému a jeho provoz popř. v některých případech i staţení IS z uţívání. Pro naši potřebu lze sled jednotlivých fází projektu shrnout do tří základních termínů: Inicializace (I) Plánování (P) Realizace (R) prozatím vyjádřené touto jednoduchou zkratkou IPR.
1.3.1 Fáze ţivotního cyklu projektu 1.3.1.1 Iniciace projektu (zadání) Podnět k zahájení projektu je většinou poptávka po nové funkčnosti, procesu, designu, návaznosti na jiné systémy, integrace s ostatními systémy, reakční doby nebo jakékoliv jiné inovaci, k jejímuţ dosaţení je zapotřebí koordinovat činnosti s jejím vznikem spojené. Na počátku by měly být zodpovězeny otázky typu ‚co‘ chci realizovat, ‚jak‘ toho chci dosáhnout, ‚koho‘ k tomu budu potřebovat, ‚v jakém čase‘ to chci stihnout a v neposlední řadě také ‚kolik‘ mě to bude stát. Pokud si tyto otázky zodpovíme, získáme rámcovou specifikaci projektu, jinými slovy a zjednodušeně Projektové zadání. Budeme-li se projektovému zadání věnovat pečlivě, pak budou výše uvedené otázky rozpracovány v těchto bodech: Rozsah projektu (projektové cíle, hlavní projektové výstupy) Klíčové projektové termíny
11
Koncepce řešení Odhad potřebných kapacit Harmonogram Klíčovou roli na projektech hrají lidé, lidé obsazení do projektových rolí. Detailně se projektovým rolím věnuje kapitola 1.3. Kompletní iniciaci projektu by měla uzavírat studie proveditelnosti (feasibility study). Jedná se o nejvyšší stupeň analýzy investičního nebo jiného záměru. Studie by měla obsahovat analýzu projektu samotného, návratnost investic a předpověď na další období. Studie je důleţitá nejen pro podporu projektu samotného, ale měla by zodpovědět hlavně finanční otázky a dopady, které budou projektem ovlivněny.4 1.3.1.2 Plánování projektu Plán projektu je jedním z mnoha klíčů k úspěchu. Plán se stanovuje z hlediska času a dosaţených cílů. Tyto dvě hodnoty spolu dohromady dávají milníky projektu. Projektový milník určuje body zlomu v projektovém plánu. Spolu s milníky projektu jsou důleţité také jeho etapy, kdy na sebe etapy mohou navazovat nebo běţí paralelně vedle sebe. Kritickou cestou, která je obvykle v plánu také zachycena, nazýváme nejdelší cestu projektu od začátku do konce. Obsahuje činnosti, které jsou pro projekt rizikové a je potřeba je obzvláště hlídat, jinak hrozí zpoţdění celého projektu. Dalším potřebným prvkem komplexního plánu je návrh řešení, vycházející ze zadání. Popisuje způsob realizace zadavatelovo potřeb, zvolenou metodiku a formu. V případě informačního systému vybrané technologie a platformu dodávaného řešení. Popisuje budoucí stav a potřebné kroky k jeho realizaci. Zvolený způsob řešení se promítne rovněţ do projektového rozpočtu, který je stanoven na rozsah činností definovaných v projektovém plánu. Obsahuje cenu za celé dílo a jednotlivé etapy, většinou vychází z nabídek, které zadavatel obdrţel ve výběrovém řízení nebo na základě svého přímého zadání konkrétní firmě. Projektový rozpočet musí počítat s určitou rezervou, jeho čerpání je navázané na projektové milníky a akceptaci dodaného díla. Harmonogram projektu zachycuje časovou osu činností, stanovuje základní orientaci v čase, promítá se v něm veškerá projektová činnost, kapacita zdrojů, časy čerpání rozpočtu i 4
THOMSON, Alan. Entrepreneurship and Business Innovation. The art of successful business start-ups and
business planning. [online], c2005. [cit. 2012-04-01]. Dostupny z WWW:
12
jednotlivé poţadavky na projektový tým. Harmonogram můţe být v průběhu projektu korigován po odsouhlasení řídícího výboru. Jedná-li se o projekt realizovaný ve spolupráci s externím subjektem, je vhodné do plánu projektu zahrnout i smluvní zajištění na dodávané práce nebo produkty. Součástí takovéto smluvní dokumentace by měly být jiţ výše uvedené body – datum, cena a komplexní návrh řešení. K projektovému plánování se většinou vyuţívají softwarové nástroje (nejrozšířenější asi Microsoft Project). Pomocí tohoto nástroje vzniká projektová plán, Gantův diagram a další (dále v kapitole Harmonogram). Kromě časových údajů, jednotlivých milníků a etap, by měl projektový plán obsahovat také jiţ údaje o projektovém týmu. Na základě těchto údajů je jiţ moţné v MS Project vytvořit projektovou sloţku, vytvořit pracovní tým a nastavit sdílenou sloţku pro dokumenty, vykazování prací a další. Pokud není vyuţitý softwarový nástroj, jedná se většinou o dokument, který musí mít k dispozici kaţdý člen projektového týmu. K tomuto účelu je moţné vyuţít řízenou distribuci pomocí zvoleného komunikačního kanálu (elektronická pošta, intranet). Jedná-li se o projekt komerční a je jako celek dodáván zákazníkovi, pak musí forma projektového plánu existovat i v papírové formě a často je takto i vyţadována, převáţně ve státní správě. Tento trend ale pomalu slábne a mnohem častěji se jiţ projektoví manaţeři setkávají pouze s elektronickým formátem projektového plánu.5 1.3.1.3 Realizace řešení V této fázi začíná samotná realizace projektu. Spouštějí se všechny potřebné mechanismy a věci se dávají do pohybu. Vhodným startem je seznámení členů projektového týmu s aplikovanou metodikou pro řízení právě toho konkrétního projektu. Řízení projektu do fáze realizace nesporně spadá. Během realizace se projektový tým pravidelně schází a pod vedením projektového vedoucího řeší naplánované i neočekávané úkoly. Důleţitou součástí řešení je průběţná analýza rizik, kdy jsou na pravidelných koordinačních schůzkách tato rizika vyslovována a vedením projektu se navrhují opatření pro jejich eliminaci. Příkladem projektového rizika můţe být například epidemie chřipky v podniku, která na určitý čas můţe vyřadit kaţdého člena projektového týmu a harmonogram projektu je tak narušen.
5
HAWDON, Cassie. Business IT course blog. [online]. c2011. [cit. 2012-04-01].
Dostupný z WWW:
13
Implementační fáze realizace zahrnuje samotnou instalaci projektových výstupu do prostředí zadavatele. Vezmeme-li jako příklad opět projekt informačního systému, jedná se o dodání prvního funkčního programového kódu, který je instalován do zákaznické IT infrastruktury. Pokud je vyţadováno, implementace je dodávána na klíč a zadavatel projektu obdrţí i funkční hardware pro instalaci. V momentě, kdy je prvotní implementace skončena, nastává čas pro úvodní seznámení se dodaným dílem. Opět na příkladu informačního systému je to hlavně představení IS všem uţivatelům a zahájení školení nových funkčností. Paralelně s tím rovněţ probíhá testování a zkušební provoz, ve kterém jsou odhalovány a rovnou předávány chyby k řešení dodavateli. Častou chybou v projektovém plánu a harmonogramu bývá vyčlenění malého času pro fázi testování. Většinou je to na úkor jiných činností. Efektivita testování v praxi není velká a v případě kratšího času se nepodaří odhalit veškeré nedostatky, které jsou zavlečeny do produkčního prostředí. U stavebního projektu probíhají pravidelné kontroly dodávek, zaměřené hlavně na kvalitu. V tomto případě obzvláště platí nepodceňovat důleţitost této fáze, některé neodhalené nedostatky mohou poté v akceptační fází způsobit značné komplikace.
Obrázek: Ţivotní cyklus projektu6
6
ŠEBEK, Václav. Plánování a řízení projektů IS [online] c2011. [cit. 2012-04-03]. Dostupné z WWW:
14
1.4 Milníky projektu Milníky projektu, rovněţ často pouţívaný anglický název „milestones“ . Jsou to speciální událostí, které v projektovém plánu poutají hlavní pozornost. V podstatě se jedná o začátky a konce jednotlivých etap, fází projektů. Velice důleţité je takové milníky stanovovat na začátcích jednotlivých fází, aby případně posunutí času jejich realizace bylo dopředu indikovatelné a projektový tým tak na něj mohl zareagovat. Kromě signalizace dokončení klíčových plnění můţe milník také znamenat důleţité rozhodnutí nebo odvození důleţité informace, která popisuje a ovlivňuje budoucnost projektu. Dobrý příkladem je přirovnání projektového milníku k jiţ dosaţené vzdálenosti (hlavní fáze projektu) a zároveň k ukazateli směru jízdy pro další aktivity dle projektového plánu. Milníky je třeba nastavit tak, aby byly realistické a dosaţitelné. Správné nastavení milníků můţe výrazně přispět k efektivnímu naplánování projektu. V kombinaci se sofistikovanou metodikou plánování (např. Kritickou cestou) umoţní milníky celkem přesné řízení projektu. Poskytují maximálně moţný náhled na dodrţování projektového plánu.
1.4.1 Kritická cesta Metoda kritické cesty (CPM – critical path method) je algoritmus pro plánování projektových aktivit. Oficiální vznik je datován do roku 1950. Její zakladatelé Morgan R. Wales ze společnosti DuPont (chemický průmysl) a E. Kelley ze společnosti Remington (zbrojní průmysl). Její první pouţití sahá ještě dále – v letech 1940 – 1943 přispěla metoda k výraznému úspěchu projektu Manhattan (vývoj 1. atomové bomby).7 Jejím cílem je stanovení doby trvání projektu na základě délky tzv. kritické cesty, coţ je sled vzájemně závislých činností s nejmenší časovou rezervou. Metoda CPM umoţňuje usnadnit efektivní časovou koordinaci dílčích, vzájemně na sebe navazujících činností v rámci projektu. Kritická cesta je definována jako (časově) nejdelší moţná cesta z počátečního bodu grafu do koncového bodu grafu. Kaţdý projekt má minimálně jednu kritickou cestu. Kaţdá kritická cesta se skládá ze seznamu činností, na které by se měl manaţer projektu nejvíce zaměřit,
7
University of South Carolina, Arnold School of Public Health, Dept. of Health Services Policy and Management Courses and Curricula, HSPM J716. Baker, S.L. Critical Path Method (CPM) [online]. c2004. [cit. 2012-04-04]. Dostupné z WWW:
15
pokud chce zabezpečit včasné dokončení projektu. Datum dokončení posledního úkolu na kritické cestě je zároveň datem dokončení projektu. Pro kritické úkoly platí, ţe jejich celková časová rezerva a tedy i volná časová rezerva je rovna nule, tzn., ţe zdrţení počátku tohoto úkolu nebo prodlouţení jeho doby trvání bude mít vliv na konečné datum projektu. Kritická cesta se promítá do časového plánování a řízení projektu prakticky ve všech fázích ţivotního cyklu projektu. 1.4.1.1
Praktické vyuţití metody kritické cesty
Tato metoda můţe slouţit jako nástroj zejména pro odhad doby trvání projektu. Pouţívá se u přímočarých projektů, kde lze doby trvání odhadnout s vysokým stupněm přesnosti, např. stavební průmysl. Doby trvání pro činnosti projektu jsou známy obvykle podle minulých zkušeností a znalostí z údajů o minulých projektech. Doby trvání nejsou statisticky určeny. Metodu je moţné pouţít i v oblasti logistiky a dopravy. 1.4.1.2
Zákony kritické cesty
Zpoţdění úkolu na kritické cestě se stoprocentně promítá do zpoţdění projektu jako celku Zrychlení prací na úkolu leţícím na kritické cestě zkracuje trvání projektu jako celku.8
8
Server ManagementMania.com. Metoda CPM (Critical Path Method) [online]. [cit. 2012-04-04].
Dostupné z WWW:
16
1.5 Pravomoci na projektu a projektové role 1.5.1 Projektový manaţer Má hlavní odpovědnost za projekt jako celek. Primárně zajišťuje dodání poţadovaných výstupů projektu se získanými zdroji v rámci dohodnutého času, nákladů a kvality. Specifikuje výstupy, dodávka, omezení a rizika projektu. Koordinuje návrh řešení a dodávku potřebných komponent k jeho dosaţení. Je klíčovým článkem pro komunikaci se všemi rolemi na projektu, s vrcholovým managementem a liniovými vedoucími. Řídí projektové zdroje a snaţí se předvídat a odstraňovat problémy. Řeší neodkladné konflikty a výjimky, které se vztahují k projektu. Provádí preventivní opatření k zamezení problémům a v případě nastalého problému eskaluje jeho řešení dle dané priority. 1.5.1.1 Ideální profil projektového manaţera Projektový manaţer by měl být člověk s praxí, který před pozicí projektového manaţera působil jako výkonná sloţka. Určitě není vhodné udělat projektovým manaţerem rovnou absolventa. Jeho hlavní devizou by měla být znalost projektového řízení, ideálně posvěcená certifikací. Důleţité je vcítění se do pozice zákazníka a umění porozumět jeho poţadavkům a očekáváním. Stěţejním je také psychologické minimum – musí umět lidi motivovat a vést k cíli. Jeho pozice stmeluje kolektiv a působí v podstatě ve vedoucí pozici, proto se očekává i přirozená autorita a všeobecný přehled. Z hlediska projektového rozhodování je vyţadován racionální přístup, umění správně volit priority řešených problémů, správné načasování a umění rozhodovat. Komunikační schopnosti uzavírají klíčové poţadavky na projektového manaţera. Jeho hlavním nástrojem je komunikace s okolím i projektovým týmem, musí naslouchat, reagovat na připomínky, věcně argumentovat a asertivně se prosazovat. Rovněţ je vhodné mít pozitivní přístup k věci a být iniciativní. Poţadavky na projektového manaţera jsou v kostce celkem obsáhlé a z toho také vyplývá, ţe projektovým manaţerem nemůţe být kaţdý, jak se hlavně ve velkých korporacích mylně děje a do pozic jsou obsazováni lidé juniorní, kteří nesplňují výše uvedené poţadavky na ně kladené. Ideál projektového vedoucí = kombinace analytika, technika, koncepčního pracovníka, moderátora, vůdce a obchodníka.
17
Vhodné zvolení osobnosti projektového manaţera je rovněţ klíčem k úspěchu projektu. Viz kapitola „Kritéria úspěšného projektu“
1.5.2 Sponzor (gestor) projektu Zadavatel projektu, většinou z řad nejvyššího vedení. Reprezentuje zadavatele nového produktu/sluţby/procesu, jehoţ se snaţí dosáhnout jím sponzorovaný projekt. Má rozhodovací pravomoc v momentě kdy je to třeba, je nadřazený projektovému manaţerovi. Pravidelně kontroluje průběh projektu a v neposlední řadě uvolňuje finanční prostředky na realizaci a dle projektových poţadavků.
1.5.3 Organizační vedoucí Vedoucí organizačního útvaru, který se podílí na projektu. Podílí se na kapacitních odhadech práce pracovníků svého útvaru a schvaluje je. Je podrobně informován o průběhu a stavu projektu (dostává zápisy z projektových týmů, měsíční zprávy o projektu). Zodpovídá za realizaci dohodnutých výstupů a činností svých podřízených pracovníků, pracujících v projektovém týmu (nejsou-li uvolněni na 100 % pro projekt). Je finančně nebo jinak motivován na projektových výstupech a jejich kvalitě (např. část jeho platu je závislá na akceptaci projektových výstupů, na kterých spolupracovali jeho podřízení)
1.5.4 Řídící výbor projektu Řídící výbor projektu je nejvyšší řídící orgán projektu, který rozhoduje o záleţitostech týkajících se projektu s výjimkou pravomocí, jeţ náleţí v souladu se stanovami a organizačním řádem statutárním orgánům podniku. Rozhoduje zejména o obsahu projektu, harmonogramu projektu, rozpočtu, případech přesahujících kompetence projektového vedoucího, resp. projektových vedoucích (při externí dodávce) a schvaluje jejich případné změny. Řeší problémy a rozhoduje spory, které mohou vzniknout v průběhu projektu zejména mezi dotčenými organizačními útvary resp. mezi podnikem a externími dodavateli
1.5.5 Projektový tým Zahrnuje skupinu lidí, která se podílí na projektu. Tým je veden projektovým manaţerem. Členové týmu mohou být i další pracovníci, kteří jsou přizváni k jednání podle potřeby vedení týmu (experti na vyţádání).
18
Tým plánuje jednotlivé fáze projektu, tj. vytvoření věcného a časového plánu vycházejícího z cílů projektu, včetně zajištění zdrojů potřebných k realizaci projektu. Kontroluje průběh projektu - plán je pravidelně vyhodnocován a případně upravován dle skutečného plnění. Provádí změnová řízení – projednávání nutnosti provádění změn mimo původní zadání projektu. V případech, kdy vedení týmu nedojde při řešení určitého problému ke shodě, eskaluje tento problém (explicitně uvedený ve zprávě o průběhu projektu) na "Řídící výbor". Zasedání týmu se konají pravidelně (obvykle 1x týdně) po dohodě všech členů týmu.
1.5.6 Projektová kancelář Provádí podpůrné a odborné činnosti pro jednotlivé projekty, resp. koordinaci projektů, jejichţ charakter je „nezávislý“ na konkrétních projektech. Tvoří srozumitelné projektové podklady (na základě poţadavku PM), zpracovává účelové dokumenty projektu. Je správcem knihovny projektových znalostí, určuje a garantuje projektovou metodiku. Účastní se kaţdého projektu prostřednictvím jejího zástupce a snaţí se koordinovat projektové portfolio v organizaci.
Obrázek 2 - Projektové role a pravomoci
19
1.6 Kritéria hodnocení projektu 1.6.1 Jaká jsou kritéria úspěšného projektu? Základní kritéria pro hodnocení úspěšného prjektu jsou: jeho realizace v předem stanoveném časovém plánu, jeho provedení bylo pokryto schváleným rozpočtem, který nebylo třeba navyšovat, výstupy projektu jsou dostatečně kvalitní a splňují předem nastavené parametry, realizace projektu byla citlivě implementována do organizačních kapacit organizace a významně nenarušila její provoz ani po konečném nasazení a zároveň bylo efektivně vyuţito všech zdrojů, nejen financí (lidská práce, materiál, zařízení, znalosti). Podmínky pro úspěch projektu podle Standish Group z roku 1994 (platí pro dnešní dobu):9 User involvement – zapojení uţivatelů Executive management support – podpora výkonného managementu Clear statement of requirements – jasná formulace (vymezení) poţadavků Effective planning – efektivní plánování Realistic expectations – realistická očekávání Rozhodujícími faktory pro úspěchy projektu:10 Podpora z vrcholového vedení Jasné realistické cíle Silný / podrobný plán aktualizován Dobrá komunikace / zpětná vazba Efektivní řízení změn Příslušný projektový manaţer / dobré vedení Dostatečné / a přidělené zdroje
9
ŠEBEK, Václav. Plánování a řízení projektů IS [online]. c2011. [cit. 2012-04-03].
Dostupné z WWW:. 10
Modernanalyst.com. BROWN, Craig. The Community Blog for Business Analysts [online]. c2008. [cit. 201204-03]. Dostupné z WWW:
20
Osvědčená / známá technologie Realistický harmonogram Rizika pod kontrolou Účinná kontrola / řízení Příslušný rozpočet Učit se od minulých zkušeností
1.6.2 Základní příčiny neúspěchu projektu Úvodem kapitoly je nutné uvést, ţe samotné přiznání neúspěchu projektu je vţdy těţké a často se i neúspěšné projekty označují jako úspěšné, protoţe je to politicky korektnější. Z mnoha důvodů však neúspěch projektu nelze skrýt a jeho zakrývání v powerpointových prezentacích většinou zasvěcení rychle odhalí. Schopnost přiznat neúspěch – ještě jeden z parametrů do ideálního profilu projektového manaţera. Zadání projektu – pokud neodpovídá skutečným potřebám zadavatele, nemůţe být úspěchem ani jeho výstup, který nesplní očekávání. Neuzavřený rámec projektu – pokud neustále přibývají změnové poţadavky, které mění původní zadání i sebe navzájem, není moţné se úspěchu dobrat. Špatný časový odhad – nerealistické doby na řešení poţadavku Podcenění nákladové sloţky – nedostatečné finanční zdroje a s tím související úsporná opatření zasahující do podstaty projektu. V neúspěšných projektech se většinou nepodařilo: zapojit odpovědné pracovníky (top management, IT, obchod) do všech etap projektu, proto některé útvary projekt bojkotují nebo „švejkují“, vyjasnit odpovědnost, v případě, ţe se pouţívá liniová organizační struktura a nejsou zřejmé kompetence projektového manaţera a vedoucího daných útvarů, specifikovat a dobře definovat správná akceptační kritéria převzetí produktu / systému do provozu, vhodně komunikovat napříč celou organizací a zamezit tak všemoţným aktivistům projekt za zády projektového týmu a manaţera pošpinit, efektivně řídit kapacity v organizaci v souvislosti s projektem, vhodně alokovat potřebné pracovníky napříč linií, správně nastavit řízení změnových poţadavků, které projekt v jeho vývojové fázi zahubily.
21
Snahou projektového vedení je často snaha o zásah do projektu, jeho plánu, rozpočtu nebo záběru. Níţe uvedené „rovnice“ ukazují, který zásahy ovlivní které z vrcholů projektového trojimperativu: Rozšířít záběr projektu = přidat čas a zvýšit náklady Sníţit časový harmonogram = zvýšit náklady a redukovat záběr Sníţit rozpočet = přidat čas a omezit záběr projektu Níţe přiloţený obrázek demonstruje poznatky z praxe podané humornou formou, kdy reprezentuje na deseti obrázcích způsob pochopení základního poţadavku „houpačky“. Výklad jednotlivých pozic v IS / IT prostředí odpovídá myšlení jednotlivých profesí. Na projektovém manaţerovi, jehoţ komunikační schopnosti jiţ byly výše vyzdvihovány, leţí odpovědnost, aby výklad za stranu zadavatele byl vţdy jednoznačně interpretovatelný. Závěrem kapitoly je tedy třeba ještě jednou zdůraznit, ţe klíčem k úspěchu je základní pochopení potřeb projektu všemi stranami a v jednom výkladu.
Obrázek 3 – Jak fungují IS projekty v praxi11
11
Projectcartoon.com. How Projects Really Work (version 1.5) [online]. [cit. 2012-04-03]. Dostupné z WWW:
22
1.7 Ukončování a vyhodnocování projektů Ukončení projektu je důleţitým krokem v jeho ţivotním cyklu. Význam formalizovaného ukončení projektu spočívá hlavně v organizačních, akceptačních a fakturačních milnících. Dále pak v eliminaci dalších nových poţadavků na projektový tým, které nejsou zahrnuty v původním projektovém plánu ani v projektovém rozpočtu. Ukončením projektu se uzavírá etapa a harmonogram, který byl při otevření projektu stanoven. Zároveň dochází k vyhodnocení úspěšnosti projektu, ze kterého je moţné vzít si do budoucna ponaučení. Důraz při vyhodnocování by měl být kladen především na porovnání plánovaného a skutečného stavu, a to z pohledu termínů dodávky, rozpočtu, vyuţití zdrojů a v neposlední řadě i z pohledu cílů projektu, zda byly cíle splněny či nikoliv. Výstupy z vyhodnocení jsou poté v budoucnu aplikovány v organizaci jako ponaučení a cílem všech organizací je neustále vylepšování projektového řízení, do kterého právě vyhodnocení jednotlivých projektů přináší nové vstupy a prostory pro zlepšení případně zefektivnění. Projekt by měl vţdy končit akceptací dodaného díla (produktu, sluţby) ze strany zadavatele. V okamţiku ukončení projektu je tento účetně uzavírán, jeho výstup je převeden do firemního účetnictví, případně předán zákazníkovi. Projektová dokumentace se zarchivuje a projektový tým je rozpuštěn, přičemţ liniový pracovníci se věnují své kaţdodenní operativní práci a projektový manaţer je převáţně převelen na nový projekt.
23
2 Metodiky řízení projektů PRINCE2 a PMBOK 2.1 Profesní organizace věnující se projektovým metodikám 2.1.1 OGC (Office of Government Commerce) Nezávislý úřad britského Ministerstva financí byl zaloţený s hlavním cílem pomáhat britské vládě zajistit maximální moţnou přidanou hodnotu všem vládním výdajům. OGC pracuje s centrální vládou a dalšími organizacemi veřejného sektoru tak, aby jim pomohl docílit šesti klíčových cílů: Tvorba vysoké přidané hodnoty z finančních prostředků z veřejných fondů Dodávka vysoce kvalitních projektů v určeném čase, kvalitě a nákladech včetně odpovídajících přínosů Co nejlepší vyuţití majetku státu Zlepšení udrţitelnosti vládního majetku a celého provozu pomocí vyšší výkonnosti managementu a vedení Podporovat dosahování dalších vládních cílů, včetně inovací, rovnosti a podpory malým a středním podnikům Prosazení a zlepšení schopnosti vlády v oblasti nákupu, projektového a programového řízení, správy majektu pomocí rozvoje lidských dovedností, zlepšení procesů a díky nástrojům. OGC mimo jiné vydává celou řadu standardů v oblasti managementu: ITIL (Information Technology Insfrastructure Library) - pro oblasti řízení ICT PRINCE2 (PRojects IN Controlled Environment) - pro oblast řízení projektů12
2.1.2 PMI (Project Management Institute) Přední světové sdruţení profesí projektového řízení s více neţ půl milionem členů ve 185 zemích. PMI působí aktivně směrem k uznání profese a role projektového řízení, definuje odborné standardy, provádí průzkumy a poskytuje přístup k mnoţství informací a zdrojů. PMI také podporuje kariérní a odborný rozvoj, nabízí certifikace, získávání kontaktů a další 12
Server ManagementMania.com. PRINCE2 (PRojects IN Controlled Environment) [online]. [cit. 2012-04-04].
Dostupné z WWW: < http://managementmania.com/prince2>
24
moţnosti komunikace v rámci odborné komunity. PMI vydává několik standardů, metodik a odborných publikací v oblasti řízení projektů, zejména Standard PMBOK (Project Management Body of Knowledge)13
2.1.3 IPMA (International Project Management Association) Je nadnárodní sdruţení projektových manaţerů. Jednou z hlavních funkcí je prosazovat povědomí o řízení projektů jako profesi, která má svou globální působnost, standardy, znalosti a schopnosti. IPMA sdruţuje projektové manaţery napříč všemi obory lidské činnosti. IPMA vydává ICB (IPMA Competence Baseline), standard kompetencí projektového řízení, tzn. standard profesionálního chování vedoucího projektu a projektového týmu. Českou národní organizací IPMA je Společnost pro projektové řízení (SPŘ = sdruţení firem a jednotlivců zabývající se řízením projektů). Ta překládá a vydává mimo jiné Národní standard kompetencí projektového řízení, coţ je lokalizace Competence Baseline pro Českou republiku. IPMA má zpracovaný certifikační systém pro projektové manaţery.
13
Project Management Institute. c2012. [cit. 2012-03-04].
Dostupné z WWW:
25
2.2 PRINCE2 (Projects in controlled enviroment) 2.2.1 Historie metodiky PRINCE2 PRINCE2 je odvozen z předchozí metody zvané PROMPT II a metodou Prince řízení projektů, která byla původně vyvinuta v roce 1989 centrální výpočetní a telekomunikační agenturou (CCTA) jako standardní metodika vlády Spojeného království pro řízení projektů informačních systémů. Brzy se ale začala uplatňovat i mimo IT prostředí. PRINCE2 byl vydán v roce 1996 jako obecné metody projektového řízení. PRINCE2 je stále populárnější a je nyní de facto standard pro řízení projektů ve Velké Británii. Od roku 2006 byla metoda revidována a aktualizovaná a publikována jako "PRINCE2: 2009 Refresh" v roce 2009. Jméno "PRINCE2" (místo "PRINCE3" nebo podobně), je zachováván z důvodu, ţe metoda zůstává věrná svým původním pilířům. Nicméně je zásadní revizi metody od roku 1996 ho přizpůsobit změně podnikatelského prostředí, aby byla metodika jednodušší a "lehčí", zaměřená na současné nedostatky a nedorozumění, a lepší integrace s jinými metodami OGC (ITIL, P3O, P3M3, MSP, M_o_R atd.).14
2.2.2 Principy PRINCE2 Vzhledem k potřebám přizpůsobit tuto metodiku aktuálnímu prostředí projektu, je nutné porozumět definovaným principům, které jsou páteří metodiky. PRINCE2 je tvořen sedmi principy. Jestliţe některý z nich není pouţit, pak takový proces není hodnocen jako PRINCE2 projekt: 1. Průběţné zdůvodnění projektu 2. Poučení se ze zkušeností 3. Definované role a zodpovědnosti 4. Řízení pomocí etap 5. Dohled nad projektem na základě výjimek 6. Důraz na produkty 7. Nutnost upravit metodiku podle aktuálního prostředí
14
Official PRINCE2® Website [online]. c2007-12 APM Group Ltd. [cit. 2012-03-04]. PRINCE2 - The Method. Dostupné z WWW
26
Obrázek 4 - Diagram procesu PRINCE2 (šipky zobrazují směr komunikace)15
Obrázek 5 - Projektové prostředí dle PRINCE216
15
Prince2.com [online]. c2012. [cit. 2012-03-04]. Dostupné z WWW: 16 Official PRINCE2® Website [online]. c2007-12 APM Group Ltd. [cit. 2012-03-04]. PRINCE2 - The Method. Dostupné z WWW:
27
2.2.3 Ţivotní cyklus PRINCE2 projektu 2.2.3.1 Projektová příprava (Starting up a Project) Start přípravy je většinou zahájen obdrţeným mandátem projektu a jednoduchým popisem projektového výstupu (produktu nebo sluţby). Součástí přípravy je i jmenování klíčových rolí. Je stanoven výkonný ředitel projektu (Executive) a projektový manaţer (Project Manager). Příprava zahrnuje i poohlédnutí do minulosti a sumarizace ponaučení a zkušeností pro současný projekt. Následně je projekt podroben základnímu zhodnocení, zda je realizovatelný, stojí za vynaloţené úsilí a zdroje a jako výstupem tohoto zhodnocení je výstupem jeho rámcové zdůvodnění (outline business case). Dalším výstupem této etapy je rámcový popis projektu (Project Brief) a naplánování iniciační etapy. 2.2.3.2 Iniciace projektu (Initiating a Project) Během procesu iniciace se pokládají základní kameny projektu , stanovují se pravidla a kontrolní mechanismy. Proces se zaměřuje rovněţ na rizika, za prvé na jejich popsání a za druhé na jejich eliminaci a řízení. Definuje se i komunikační strategie a matice, způsob řízení kvality výstupů. V rámci iniciační fáze rovněţ vzniká harmonogram s dekompozicí na jednotlivé sub produkty a termíny jejich dodání. Projektový manaţer jako výstup připravuje doplněné zdůvodnění projektu (business case) a předkládá je projektové radě, která autorizuje projekt. 2.2.3.3 Strategické řízení projektu (Directing a Project) Tento proces je v běhu po celý ţivotní cyklus projektu. Jedná se o strategické řízení projektu projektovou radou, přijímání rozhodnutí, která jsou nad rámec pravomocí projektového manaţer. Projektová rada rovněţ schvaluje začátek realizace i kaţdou další etapu, rozhoduje o výjimkách, dává doporučení projektovému týmu a jedná s vedením organizace. Projektová rada rovněţ projekt uzavírá. 2.2.3.4 Řízení etapy (Controlling a Stage) Řídící proces mající závislost na ostatních procesech, ve kterých projektový úkoluje vedoucí jednotlivých týmů, zjišťuje jejich postup kupředu. Řeší vzniklé problémy
sám nebo je
předává k řešení projektové radě, pokud ohroţují termíny jednotlivých etap. V pravidelných zprávách pak předává projektové radě průběh a aktuální stavy jednotlivých etap projektu.
28
Vedoucí projektu na začátku procesu akceptuje pracovní balík (popis toho co má dodat a jak při tom má postupovat) od projektového manaţera. Pracovní balík zrealizuje (v průběhu realizace podává projektovému manaţerovi zprávy o kontrolních bodech). V momentě, kdy je pracovní balík dokončený, předává ho projektovému manaţerovi, který v procesu Řízení etapy přijme dokončený pracovní balík. 2.2.3.5 Řízení hranic etapy (Managing a Stage Boundary) Proces, který začíná v termínu blízkém konci běţící etapy. V momentě, kdy etapa končí, je třeba jí vyhodnotit a naplánovat etapu další. Dalším případem je moţnost, kdy projektová rada posoudí vyjímku z termínu oznámenou projektovým manaţerem za tak závaţnou, ţe mu uloţí vypracovat Plán vyjímky. V tomto procesu se vytváří správa o ukončení etapy, plánuje se etapa nová a aktualizuje se Plán projektu. Vše podláhá opět schválení projektovou radou. 2.2.3.6 Ukončení projektu (Closing a Project) Na konci poslední etapy připraví projektový manaţer ukončení projektu, zabezpečí formální předání produktu – výstupu projektu, vyhodnocení projektu předkládá projektové radě spolu s návrhem na ukončení projektu. Projektová rada musí následně tento návrh schválit (proces Strategické řízení projektu), čímţ se projekt ukončí.
Obrázek 6 – Seskupení procesů PRINCE217
17
ict-123.com. PRINCE2. c2009-2012. [cit. 2012-03-04]. Dostupné z WWW:
29
2.3 PMBOK (Project management body of knowledge) 2.3.1 Historie metodiky PMBOK Metodika řízení projektů PMBoK je tvořena a udrţováno Project Management Institutem (PMI), coţ je profesní sdruţení firem a individuálních projektových manaţerů. Metodika vznikla v 70.tých letech 20. století v USA dle standardů americké armády. Ty byly převzaty i do standardů průmyslových (ANSI). Důvodem byl projektový potenciál americké armády, která v té době realizovala mnoho velkých projektů téměř ve všech oblastech. Základní filozofie těchto projektů je bez problémů aplikovatelná i na komerční a jiné projekty, vznikl tedy PMBoK verze 1. Nyní je standard jiţ ve své třetí verzi a PMI pracuje stále na dalším rozvoji.
2.3.2 Koncept PMBOK Základním přístupem PMI je procesní pojetí problematiky projektového řízení. Snaţí se popisovat a doporučovat nejlepší zkušenost „best practices“. PMBOK poskytuje obecný nadhled namísto detailního popisu všech procesů. Jádrem metodiky je pět hlavních mnoţin procesů, devět oblastí znalostí, jednotlivé procesy a jejich vazby. Vše má definováno vstupy, výstupy a nástroje transformace (úkony, metody, techniky). Jedná se o hlavní projektový standard ve Spojených státech amerických, a proto je metodika často implementována i v kmenových směrnicích amerických společností.
2.3.3 Procesy, komponenty a techniky PMBOK 2.3.3.1 Hlavní procesní skupiny PMBOK 1. Initiating Vytváří organizační schéma projektu a definují se projektové role. 2. Planning Je jádrem všech procesních skupin PMBOK, v rámci tohoto procesního bloku vzniká celkový plán projektu. Základem pro sestavení plánu je rozsah projektu, čas na realizaci a celkový rozpočet 3. Executing Fáze realizace popisující spouštěcí mechanizmy jednotlivých kroků, milníky. 4. Monitoring a controlling 30
Popisuje kontrolní a monitorovací nástroje, převáţně slouţící projektovému manaţerovi a projektovému výboru 5. Closing Definuje po projektové kroky a říká jakým způsobem se za projektem „ohlédnout“
Obrázek: PMBOK Procesy18
2.3.3.2 Znalostní oblasti PMBOK19 1. Project Integration Management Tato oblast je obsaţena ve všech procesních skupinách, propojuje a integruje všechny znalostní oblasti a tvoří tak nejdůleţitější část. 2. Project Scope Management Řízení rozsahu projektu zahrnuje procesy potřebné k zajištění, aby projekt obsahoval pouze práce a vstupy potřebné pro rámec. Řízení rozsahu projektu je primárně zaměřeno na definování a řízení, co je a není zahrnuto v projektu. 3. Project Time Management Znalostní oblast velice důleţitá, do jejího portfolia spadá časový harmonogram projektu na základě všech definovaných činností. Zahrnuje i popis kritické cesty. 4. Project Cost Management Rozpočtová oblast – zahrnuje vytvoření, čerpání a kontrolu projektového rozpočtu. Obsahuje i oblast tzv. Earned Value Management, coţ je metoda umoţňující komplexní pohled na nákladovou stránku řízení projektu (vývoj, současnost a budoucnost) 5. Project Quality Management
18
Method123 Project Management Methodology. Project Management Best Practices. [cit. 2012-03-02]. Dostupné z WWW: http://www.mpmm.com/project-management-best-practices.php 19 Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition. Project Management Institute 2008. ISBN13: 9781933890517
31
Znalostní oblast - kontrolní mechanismus kvality, zahrnuje řízení kvality jednotlivých vstupů a kontroly, zda byly splněna očekávání všech zúčastněných stran na projektu. 6. Project Human Resource Management Oblast se věnuje řízení lidských zdrojů a zároveň vedení lidí – projektových členů (motivace, metody vedení atd.) 7. Project Communications Management Komunikace na projektu je klíčovou činností a tato oblast popisuje komunikační procesy spojené s efektivním řízením projektu. Cílem je drţet všechny projektového týmu na stejné vlně a všem distribuovat ve stejný čas stejné informace. 8. Project Risk Management Riziko = kombinace omezení a nejistoty, proto se tato část PMBOK věnuje řízení všech potencionálních rizik, snaţí se o jejich eliminaci a řízení. 9. Project Procurement Management Popisuje řízení smluvních dokumentů a rozděluje typy smluv.
32
2.4 Porovnání PRINCE2 s PMBOK Srovnání obou metodik bude v této práci rozděleno do několika kapitol, přičemţ věnovány budou ţivotnímu cyklu projektu, dokumentaci a roli projektového manaţera. Rovněţ bude pouţito srovnání jednotlivých fází a cyklů obou metodik. Obecně lze říci, ţe PRINCE 2 je plnohodnotná metodika a PMBOK je souhrn nejlepších praxí pro projektové řízení. Jinými slovy PRINCE2 je více praktická příručka, PMBOK zase teoretická. PRINCE 2 se zaměřuje na klíčové oblasti, PMBOK je komplexní. Pokud bychom chtěli srovnávat číselně, PRINCE 2 popisuje svých 43 procesů, PMBOK 39. Dalším kontrastem mezi oběma standardy je jejich vyuţívání celosvětově, PMBOK je spíše americká standarta, domovinou PRINCE2 je zase Spojené království Velké Británie a Severního Irska. PRINCE2 se primárně věnuje problematice IS/IT projektům, z jejichţ řízení de facto metodika vznikla, na druhou stranu v dnešní době mnoho projektů jiţ je spojeno s informačním systémem, omezení pouze na IS/IT tak jiţ není tak horké. Naopak PMBOK je vyuţíván a doporučován napříč všemi odvětvími, navíc jeho základní znalost se předpokládá a je vhodným základním stavebním kamenem pro kaţdého projektového manaţera, i toho, který ve finále hodlá pouţívat PRINCE2.
2.4.1 Srovnání PRINCE2 a PMBOK se zaměřením na ţivotní cyklus projektu PRINCE2 definuje ţivotní cyklus velmi podrobně, dělí projekt na jednotlivé fáze. Vyuţívá dvou nadřazených cyklů – řízení a plánování, které zasahují do jednotlivých dílčích funkčních celků. Detail je v Obrázku 7.
33
Obrázek 7 - PRINCE2 - ţivotní cyklus20
PMBOK – dělí projekt na čtyři základní fáze a jeho definice je jen velmi obecná oproti PRINCE2. Detail je v Obrázku 8.
Obrázek 8 - Ţivotní cyklus projektu PMBOK21
20
Wordpress [online]. [cit. 2012-04-04]. Dostupné z WWW: http://simpleprocesses.files.wordpress.com/2009/11/prince2.jpg 21 WIDEMAN, R. Max:The Role of the Project Life Cycle (Life Span) in PM [online]. [cit. 2012-03-02]. Dostupné z WWW:
34
2.4.2 Srovnání PRINCE2 a PMBOK se zaměřením na dokumentaci Metodika PRINCE2 v šablonách navrhuje a tvoří strukturu dokumentů, u kterých je poţadováno vytvoření během projektu. Nutno říci, ţe řešení je komplexní a robustní a tvorba jednotlivých dokumentů předepsaných projektovým rolím, můţe tyto pracovníky zahltit a celý projekt zpomalit byrokratizací. Důvodem je původ metodiky z oblasti IS/IT, která je na dokumentaci přímo závislá. Ke zdaru všech zainteresovaných v PRINCE2 nutno podotknout, ţe metodiku si lze přizpůsobit na míru a na vedení záleţí, které všechny dokumenty bude vyţadovat. Naopak PMBOK nedefinuje šablony dokumentů ze svých jednotlivých procesů znalostních oblastí. Tvorba dokumentace je tak pouze obecně popisována, ale nevychází z předem definovaných šablon. Opět záleţí na organizaci, jakým způsobem chce s tvorbou projektové dokumentací naloţit.
2.4.3 Srovnání dle přístupu k roli projektového manaţera PRINCE2 umísťuje roli projektového manaţera do organizační struktury a chápe ho jako roli odpovědnou za řízení projektu. Nadřazeným orgánem projektového manaţera je projektová rada a on jí reportuje veškeré odchylky od normálu. Rozhodování o nich je rovněţ svěřeno projektové radě. Projektový manaţer je tak chápán jako výkonná sloţka, odpovědnost zůstává hlavně na vedení podniku a projektové radě, ve které má vedení své zastoupení. PMBOK vidí projektového manaţera jako osobu spjatou s projektem pro splnění cílů projektu a zároveň je to osoba, která má za projekt hlavní odpovědnost. Oproti PRINCE2 má projektový manaţer širší pole působnosti a rozhoduje i o nestandardních situacích na základě svého uváţení a svých zkušeností. Řídí celý projekt, zahajuje a ukončuje fáze a zároveň i projekt uzavírá. Zkrátka v PMBOK má role projektového manaţera větší důleţitost.
35
2.4.4 Tabulkové porovnání PRINCE2 a PMBOK Obecne praktiky PRINCE2
Obecne praktiky PMBOK
Prakticky zaměřený, striktně a přesně
Teoretické zaměření, postaveno na nejlepší
definuje jak projekty řídit
zkušenosti z projektového řízení
Zaměření na klíčové oblasti projektového
Široké pokrytí všech oblastí v projektovém
řízení
řízení
Největší uplatnění při aplikaci na IS / IT
Široká míra vyuţití napříč všemi obory
projekty Striktně vyţaduje dodrţovat strukturu
Není direktivní, je postaven na doporučeních
procesů Tabulka 1 - Základní srovnání PRINCE2 a PMBOK
Komponenty PRINCE2
Znalostní oblasti PMBOK
Planning, Controls
Project Integration Management
Plans
Project Scope Management
Business Case Change Control Configuration management Managing stage boundaries
Project Time Management
Plans
Project Cost Management
Quality
Project Quality Management
Configuration management Organisation
Project Human Ressource Management
Organisation
Project Communication Management
Controls Management of Risk
Project Risk management
Není definováno
Project Procurement management
Tabulka 2 - Mapování objektů PRINCE2 na znalostní oblasti PMBOK
36
Ţivotni cyklus PRINCE 2
Ţivotní cyklus PMBOK
Starting up a Project (start projektu)
Initiating (iniciace)
Directing a Project (řízení projektu) Initiating a Project (iniciace projektu)
Planning (plánování)
Planning (plánování) Managing Product Delivery (řízení dodávky)
Executing (exekuce, provádění)
Managing Stage Boundaries (řízení jednotlivých fází) Directing a Project (řízení projektu)
Controlling (kontrola)
Closing a Project (uzavření projektu)
Closing a Project (uzavření projektu)
Tabulka 3 - Ţivotní cykly projektu dle obou metodik
Certifikace PRINCE2
Certifikace PMBOK
PRINCE2 Foundation
Project Management Professional
PRINCE2 Practitioner
Certified Associate in Project Management
PRINCE2 Consultant Tabulka 4 - Certifikační stupně obou metodik
37
3 Způsob řízení projektů v konkrétní firmě 3.1 Představení společnosti ITQ, s. r. o. Máme společnost ITQ, s. r. o. působící na českém trhu od roku 2011. Jedná se o mladou organizaci, která se zaměřuje na IS/IT zákaznická řešení na míru, vyvíjí aplikační portály, portály pro elektronické obchody, rezervační systémy a internetové prezentace na míru. Součástí dodávaných řešení je i servisní podpora po nasazení do provozu. Vedlejší činností firmy jsou konzultantské sluţby a outsourcing IT servisu. Společnost ITQ, s. r. o. působí pouze v České republice, ale má ambice expandovat i do sousedních zemí střední a západní Evropy. Společnost má v současnosti jednoho majitele a 12 zaměstnanců. V loňském roce hospodařila s nepatrným ziskem, kdy většinu výdělků pokryly úhrady úvěrů na rozjezd podnikání. V roce 2012 chce společnost inovovat svoje interní procesy a stát se rovnocenným soupeřem konkurenci na trhu IS/IT v ČR.
3.2 Motivace k implementaci metodiky řízení projektů Firmu ITQ, s. r. o. motivuje k zavedení metodiky pro řízení projektů především získání několika významných zakázek pro státní správu, očekává se rovněţ nárůst poptávky na základě výtečných referencí od stávajících zákazníků a ocenění nabízených řešení. Aby bylo moţné tyto aktivity současně řídit, je třeba jasně definovat procesy a odpovědnosti. Další motivací je také snaha, zvládnout nárůst činností se současnými zaměstnanci a drţet mzdové náklady na úrovni z minulého roku. Důleţitým motivačním faktorem je rovněţ snaha vystupovat transparentně vůči zákazníkům a vzhledem k zapojení klíčových pracovníků od zadavatele do projektu, také jednoznačná metodika pro všechny členy projektového týmu.
38
3.3 Aktuální stav projektového řízení Společnost ITQ, s. r. o. doplatila na svou mladickou nerozváţnost a plnohodnotné projektové řízení nezavedla okamţitě po svém zaloţení. Plánování obchodních aktivit probíhá do současné chvíle přírůstkově, k zákazníkovi je komunikován základní rámec termínů a snaha společnosti je maximálně vyvíjena k jeho dodrţení. Termíny jsou však pouze jen střípky z projektového řízení, které si firma hlídá. Bohuţel není zavedeno kapacitní plánování – zdroje, jak lidské, tak technologické, jsou přetěţovány a často dochází ke stresovým situacím. Snaha o uspokojení zákazníka je vţdy na prvním místě, ovšem někdy firma ITQ, s. r. o. platí vysokou cenu za tuto snahu.
Obrázek 9 - Organizační struktura ITQ, s. r. o.
Matice odpovědností je nastavena velice jednoduše, veškerou odpovědnost za obchodní konání má jednatel a výkonný ředitel v jedné osobě. Coţ na jednu osobu generuje opět nebývalé mnoţství aktivit a úkonů, často na hranici splnitelnosti. Jednotná není ani šablona dokumentů a není popsán proces pro správu poţadavků na vývoj software, který by měl být nedílnou součástí pro projektové řízení IS / IT.
39
3.4 Model Projektového řízení v ITQ, s. r. o. ITQ, s. r. o. pouţívá svůj specifický jednoduchý model projektového řízení ZRU. Ten reflektuje členění ţivotního cyklu projektu pouze do 3 základních fází. Fáze modelu ZRU: Z = „Zahájení“
R = „Realizace“
U = „Uzavření“
3.4.1 Zahájení projektu Zahájením projektu ve společnosti ITQ, s. r. o. začíná akceptací nabídky zákazníkem. Dle nabízených parametrů je po podpisu smlouvy iniciován projekt, s jednotlivými vedoucími útvarů je domluvena účast jejich lidí na aktivitách s projektem souvisejícím. V rámci zahájení a dle smlouvy je určen harmonogram, kde nejdůleţitějším údajem je datum dodání a předpokládané datum akceptace díla zákazníkem.
3.4.2 Realizace Realizací se rozumí vývojové, konzultační práce nebo IT operativní činnosti. Do vývojových činností je započítána analýza, vývoj, testování a tvorba dokumentace. Zároveň je toto uvedeno v harmonogramu jako jeden balík bez hlubšího detailu. Realizací se také rozumí pravidelné projektové schůzky se zákazníkem, kde se vyjasňují jeho očekávání a potřeby a průběţně se řeší a odstraňují vzniknuvší problémy. Součástí realizace jsou buď postupné nebo jednorázové dodávky IS/IT produktů nebo sluţeb do prostředí zákazníka. Jako realizace je bráno i uţivatelské testování na straně zákazníka. Fáze realizace končí předáním hotového produktu nebo sluţby do prostředí zákazníka ve finální podobě a ukončení akceptačního testování.
3.4.3 Uzavření Samotným uzavřením projektu se rozumí hlavně akceptace díla na straně zákazníka a uhrazení vystavené faktury ve splatnosti. Pokud je součástí zakázky i podpora po nasazení do produkčního provozu, projekt se uzavírá aţ po skončení této pilotní podpory. V momentě uzavření projektu vyhodnocuje výkonný ředitel společnosti kaţdé projekty a snaţí se najít silné a slabé stránky v procesech, dodávkách i lidských zdrojích. Dochází také ke sběru zpětné vazby od zákazníka. Tyto důleţité faktory jsou pak devizou do budoucna pro další úspěšnější projekt.
40
3.5 Fungující projektové mechanismy Základ pro úspěšné projektové řízení byl jiţ poloţen. Firma se snaţí fungovat projektově a základní rámce projektového řízení jsou patrné. Existují základní milníky projektů a způsob jak projekt vést od začátku do konce. Pracovníci ITQ, s. r. o. jsou odborníky ve svém oboru a svou práci si organizují sami. Vývojové aktivity nejsou dělány chaoticky, kaţdý z pracovníků má však jiný způsob práce a jejich procesy jsou odlišné. Z tohoto důvodu je komunikace napříč jednotlivými úseky obtíţnější, protoţe transparentnost procesů druhé strany je často nízká. Funkční jsou rovněţ pravidelné projektové schůzky a způsob komunikace se zákazníkem. Důleţitým faktorem je také chuť všech pracovníků firmy inovovat a zavádět nové a efektivnější procesy pro jednodušší správu všech poţadavků na vývoj. Zároveň jsou si všichni vědomi sloţité hospodářské situace a chtějí efektivněji vyuţívat zdroje firmy k vytvoření kladného hospodářského výsledku.
41
3.6 Prostory pro zlepšení stávajícího projektového řízení Společnost ITQ, s. r. o. umí dobře pracovat s zakázkami s konstantním přírůstkem v čase, bohuţel pokud se objeví příleţitost na trhu, po které je třeba skočit, ITQ, s. r. o. není dostatečně pruţná z důvodu vytíţenosti výkonného ředitele a jednatele. Jeho časová zaneprázdněnost a odpovědnosti, které se u něj sbíhají, činí z ITQ, s. r. o. částečně nepruţnou IT firmu, která bojuje s nedostatkem řídících zdrojů. Potřeba inovace je cítit také v kapacitním plánování. Jednotlivý vedoucí úseků plánují kapacity svých podřízených pouze jednorázově na dané projekty, komplexní čísla s vytíţeností napříč projektovým portfoliem firmě chybí. Dalším motivačním prvkem k zavedení profesionální metodiky projektového řízení je také efektivní zpracování veškeré dokumentace a zjednodušení oběhu dokumentů mezi zákazníkem a firmou. O kvalitě výstupů je také potřeba se zmínit. Přetíţené zdroje jsou často způsobeny také nekvalitní dodávkou, díky které jsou pak jiné zdroje čerpány na zpracování oprav nekvalitních dodávek. Dalším aspektem, který potřebuje pozornost jsou náklady. Při zpracování nabídek se často stane, ţe je podceněna nákladová sloţka na straně ITQ, s. r. o.. a firma pak doplácí na špatné odhady při zahájení projektu. Cílem je tedy zoptimalizovat procesy a předkládat přesnější odhady a zároveň je nutno zavést účinnou kontrolu nákladů napříč celou organizací, ale i napříč jednotlivými projekty, aby bylo patrné, zda projekt drţí rozpočet nebo ho jiţ překračuje. V případě, ţe by hrozilo překročení, je nutné práce projektu omezit a komunikovat se zákazníkem dopady a způsob řešení nastalé situace. V neposlední řadě firmu ITQ, s. r. o. motivuje řízení rizik na projektech. Rizika jsou často podceňována a jsou řešena ad-hoc aţ v případě, ţe nastanou. To s sebou často přináší negativní dopad buď na výše uvedený rozpočet a náklady, zároveň to můţe způsobit i negativní vnímání na straně zákazníka. Pokud půjdeme ještě dál, podceněné riziko můţe způsobit i nabourání harmonogramu nebo kolaps celého projektu. Ve firmě ITQ, s. r. o. se uţ bohuţel tato událost dvakrát přihodila a byla také jednou z mnoha důvodů k motivaci zavést metodiku projektového řízení.
42
3.7 Hlavní cíle implementace metodiky řízení projektů - priority 3.7.1 Zvýšení výkonnosti firmy Jako prioritní cíl je analýza, jenţ předběţně vyhodnotí plnění stávající strategie, způsob řízení, základní vnější a vnitřní situaci ve firmě, provede identifikaci základních problémů a příleţitostí. Na základě této úvodní analýzy lze navrhnout další postup.
3.7.2 Optimalizace nákladů Pro většinu organizací zůstává optimalizace nákladů vysokou prioritou. Pro společnost ITQ, s. r. o. představuje optimalizace nákladů systematický přístup k technologiím napříč IT a organizační strukturou firmy. To ale neznamená pouze sniţování nákladů. Pokud se vhodně realizuje na strategické i taktické úrovni, můţe podpořit podnikové iniciativy vedoucí k poţadovaným výsledkům, vyšší konkurenceschopnosti a lepší výkonnosti.
3.7.3 Transparentní projektové prostředí pro zaměstnance i zákazníka Pro společnost ITQ, s. r. o. významně narůstá priorita pro vnesení řádu do výkonu všech jejích aktivit, zvýšení transparentnosti a zajištění dostatečné míry kontroly nad nimi, jakoţ i lidmi kteří se na jejich realizaci podílejí a tím sníţení rizik.
3.7.4 Expanze na trhy mimo ČR S ohledem na význam moţné expanze do zahraničí stojí za pozornost způsob, jímţ podnik analyzuje trhy mimo ČR. Spolehnutí na vlastní odhad bez konzultace s externím poradcem (příp. projektovým vedoucím) se zkušenostmi z mezinárodního prostředí a jeho podrobnou analýzou můţe v tomto případě mít poměrně nepříjemné důsledky: od neadekvátní ceny po dodatečné zjištění různých „kostlivců ve skříni“, které projekt zahraniční expanze značně prodraţí a zkomplikují.
43
4 Výběr konkrétní metodiky na základě potřeb firmy 4.1 Shrnutí potřeb společnosti ITQ, s. r. o. Implementace metodiky řízení projektů je nezbytná hlavně z důvodu nárůstu objemu prací a plánovaných zakázek pro státní správu. Firmu ITQ, s. r. o. rovněţ motivuje zvládat nárůst zakázek s co moţná nejmenším moţným nárůstem mzdových nákladů. Podmínkou účastí v otvíraných výběrových řízení se poslední dobou stává implementovaná projektová metodika a certifikovaní projektoví manaţeři. Aby byla firma do budoucna konkurenceschopná, je nutné reagovat včas. Další potřeby jsou ekonomické, firma ITQ, s. r. o. si od zavedení projektové metodiky slibuje nárůst efektivity práce a s tím spojený lepší hospodářský výsledek. S tím jsou spojené i očekávané redukce nákladů, pokud se zavede projektové řízení a procesy ve firmě budou transparentní a jasně dané.
4.2 Seznámení se strukturou projektů v popisované firmě Ve firmě je nyní otevřeno 5 projektů a jejich portfolio pokrývá všechny předměty podnikání ITQ, s. r. o. V oblasti vývoje internetových prezentací jsou nyní otevřené dva velké projekty zaměřené na redesign webových stránek pro dvě finanční instituce. Oba jsou jiţ ve fázi realizaci a pokrývají z 40 procent obratu firmy. Tyto dva projekty jsou řízeny společně s výkonným ředitelem a vedoucím úseku vývoje portálů. Kapacitně vytěţují lidské zdroje útvaru z 85%, přičemţ se oba projekty potýkají s neustálým upřesňováním a drobnými změnami ze strany zákazníka a má to negativní vliv na plnění časového harmonogramu. Internetové aplikace jsou v projektovém portfoliu ITQ, s. r. o. obsaţeny taktéţ. Jedná se o dva projekty, zaměřující se na v poslední době velmi populární aplikace pro chytré telefony. Projekt Secure Home se věnuje tvorbě aplikace umoţňující sledovat střeţené prostory pomocí webových kamer přímo v mobilním telefonu a firma ITQ, s. r. o. spolupracuje na tomto projektu s firmou dodávající právě kamerové zabezpečení. Druhým projektem zaměřeným na vývoj aplikací do mobilních telefonů je projekt TANK, který se věnuje vývoji aplikace pro srovnání cen pohonných hmot v České Republice a je dodáván pro společnost provozující tankovací karty. Oba projekty jsou rovněţ řízeny výkonným ředitelem a vedoucím úseku 44
vývoje aplikací a stejně jako projekty webových stránek vytěţují 85% kapacit vývojářů ITQ, s. r. o. Projektové portfolio uzavírá projekt na outsourcing IT Helpdesk sluţeb pro praţskou advokátní kancelář. Jedná se o kompletní převzetí správy a údrţby IT infrastruktury ve dvou praţských kancelářích spolu s implementací portálů pro hlášení problémů. Projektu se po obchodní stránce věnuje výkonný ředitel a také vedoucí úseku IT Servis. Pracovníci IT Servisu jsou zatím vytíţeni pouze na 25%.
45
4.3 SWOT analýza popisovaných metodik řízení projektů v ITQ, s. r. o. 4.3.1 PRINCE2 SWOT analýza Silné stránky
Slabé stránky
Jednoznačně definovaná metodika Primárně určeno na IT Projekty Praktické zaměření Příleţitosti
Příliš mnoho typů dokumentace Klade větší nárok na vedení organizace Určen převáţně na velké projekty Hrozby
Všeobecně uznávaná metodika v IT světě PRINCE2 certifikace zvýší úspěšnost ve výběrových řízeních Transparentnost všech procesů dle PRINCE2
Byrokratizace kvůli velkému počtu dokumentů Delegace na projektového manaţera pouze část pravomocí, rozhodovat musí stále vedení
Tabulka 5 - SWOT Analýza PRINCE2
4.3.2 PMBOK SWOT analýza Silné stránky
Slabé stránky
Komplexně pokrývá všechny projektové oblasti Pouţitelný na projekt jakékoliv velikosti Obsahuje mnoho doporučení a tzv. best practices Není svazující jako PRINCE2 Příleţitosti
Není určeno primárně pro IS/IT projekty Jasně nedefinuje strukturu procesů a dokumentů Úspěch implementace závisí na schopnosti organizace a uchopení metodiky pro pouţití v praxi Hrozby
Je řízen poţadavky zákazníka Mezinárodní standard pro projektové řízení Deleguje pravomoci na projektového manaţera
Pokud nebude zachyceno doporučení PMBOK ve firemních postupech, zůstává pouze teorií bez vyuţití v praxi Velká závislost na vstupní analýze, v případě jejího podcenění nebude metodika správně zacílena Pokrytí všech projektových oblastí závisí na implementační fázi a tvorbě dokumentace a modelování procesů.
Tabulka 6 - SWOT Analýza PMBOK
46
4.4 Výběr metodiky a odůvodnění Po zváţení všech aspektů obou metodik, po detailním vypracování obou SWOT analýz na obě metodiky a s přihlédnutím k velikosti firmy i projektů, které firma realizuje byla jako vzor pro implementaci metodiky řízení projektů zvolena právě metoda PMBOK, která se svou moţností přizpůsobení nejlépe hodí pro firmu velikosti ITQ, s. r. o. Důleţitým faktorem je také moţnost delegace vedení projektu přímo na projektového manaţera, od čehoţ si slibuje ředitel firmy „uvolnění“ rukou a nové moţnosti věnování se obchodnímu rozvoji společnosti. S přihlédnutím k určité snaze zachování svobody liniových pracovníků při jejich činnosti rovněţ vítězí PMBOK, který není jako PRINCE2 tak direktivní a umoţňuje přizpůsobit si metodiku pro potřeby vlastní organizace. Vedení organizace rovněţ zváţilo všechna rizika, která vyplývají z výše uvedené SWOT analýza, především je třeba zpracovat jasnou interní metodiku, ve které budou zapracovány základní principy PMBOK a která bude slouţit jako manuál pro všechny pracovníky firmy ITQ, s. r. o., podílející se na projektech. Zároveň bude tato norma komunikována i směrem k stávajícím i novým zákazníkům, aby měli přesné informace o realizovaných projektech a zároveň se byli schopni na projektech přímo podílet, a poskytovat potřebnou součinnost. Nezbytným předpokladem pro úspěšnou implementaci je kromě zpracované dokumentace, především otevření projektu pro zavedení metodiky, najmutí projektového manaţera a jeho začlenění do organizační struktury a vyjasnění odpovědností, investice do softwarového nástroje pro podporu projektového řízen. Této problematice se bude věnovat následující kapitola.
47
5 Projekt Implementace metodiky do firemního prostředí Úvodem projektu byl uspořádán brainstorming mezi pracovníky firmy ITQ, s. r. o. a jeho výsledkem je přiloţená myšlenková mapa.
Obrázek 10 - Myšlenková mapa projektu implementace
Obrázek 11 - Myšlenková mapa - rizika projektu implementace
48
5.1 Stanovení cílů projektu a návrh řešení 5.1.1 Cíl projektu Cíl implementace lze definovat v několika větách. Po ukončení projektu musí mít firma ITQ, s. r. o. jasně definovaná projektová pravidla, implementovaný software pro řízení projektů, alespoň jednoho certifikovaného projektového manaţera vsazeného do stávající organizační struktury. Dále bude existovat jednoznačný metodický dokument – manuál viz. Příloha 1, podle kterého bude moţné řídit jakýkoliv projekt a v souvislosti s implementovaným projektovým řízením budou upraveny i firemní procesy, převáţně pak proces pro sledování ţivotního cyklu projektového poţadavku na vývoj informačního systému nebo na opravu chyby v informačním systému. Tyto aktivity zároveň nepřesáhnou rozpočet projektu, který byl vedením firmy stanoven na 500.000 korun českých.
5.1.2 Návrh řešení Návrh řešení zahrnuje komplexní implementaci projektové metodiky do prostředí firmy. Součástí zavádění projektového řízení je nutnost obsazení role projektového manaţera, která nyní není ve firmě zastoupena. Vzhledem k tomu, ţe pracovníci firmy jsou čistě technicky zaměřeni a nemají s projektovým řízením velké zkušenosti, bylo rozhodnuto o najmutí člověka z venku, který jiţ s projektovým řízením zkušenosti má a bude přínosem i pro sníţení kapacitní vytíţenosti celé firmy.
5.1.3 Začlenění IS Dalším aspektem, který je třeba vzít v potaz je implementace informačního systému, který bude podporovat projektové řízení – a to ve dvou dimenzích. V první je nutné vybrat nástroj, který bude sledovat projekt jako celek – umoţní plánovat a sledovat vytíţenost zdrojů, umoţní sledovat projektové termíny a milníky a bude podporovat základní uţivatelské funkčnosti nástroje pro podporu projektového řízení dle PMI. V druhé řadě je třeba zavést i nástroj pro takzvaný issue tracking, coţ znamená sledování aktuálního stavu jednotlivého poţadavku. Zpravidla se jedná o poţadavky typu chyba nebo změna, pomocí kterých je rozvíjen informační systém. Firma se zaměruje právě na vývoj a správu informačních systémů a takovýto systém jí doposud chybí.
49
5.1.4 Dokumentace Další důleţitou součástí je i standardizace dokumentace a vznik manuálu pro projektové řízení. Stručný manuál projektového řízení bude výstupem projektu. Řízení projektu je třeba detailně popsat tak, aby vznikla jasná pravidla hry, ta budou následně pouţívána napříč firmou i u zákazníka, aby měl přehled o transparentnosti procesů u svého dodavatele. Cílem projektu je vytvořit i další sadu dokumentů (zápisy, objednávky, faktury, projektové zprávy), která bude jednoznačně daná a nebude třeba přemýšlet nad tím, kterou šablonu dokumentu mají pracovníci pouţít. Jednotný formát je vhodný i pro implementaci šablon dokumentů do informačního systému, kdy je nebude třeba udrţovat ve wordu, ale dokumenty bude moţné přímo tisknout z informačního systému pro podporu projektového řízení.
50
5.2 Časový harmonogram Časové zacílení projektu bylo zvoleno na období prázdnin, kdy je ve firmě nejmenší vytíţenost zdrojů a implementace metodiky projektového řízení tak neohrozí výrazně ţádnou z obchodních aktivit. S ohledem na tuto skutečnost bylo třeba vhodně naplánovat dovoleno zaměstnanců tak, aby co moţná největší počet z nich byl v době implementace přítomen a přímo se tak projektu zúčastnil. Nařízení dovolené však můţe přinést negativní motivaci do projektu a proto byl harmonogram projektu upraven tak, aby si pracovníci v období školních prázdni mohli vybrat alespoň ze tří týdenních termínů a nebyly tak ochuzeni o potřebný odpočinek s rodinou. Firma se zároveň rozhodla zaměstnancům vynahradit tuto letní aktivitu plánovaným celo firemní dovolenou v období mezi Vánoci a Silvestrem, čímţ alespoň částečně zaměstnancům zvýší motivaci. Tato skutečnost musí být rovněţ vhodně komunikována. Komunikaci samotné se bude věnovat kapitola 6.5
5.2.1 Klíčové termíny jednotlivých fází projektu Pro vypracování jednotlivých fází projektu lze vyuţít jednoduchý tabulkový rámec, ve kterém se definují jednotlivé kroky, začátek, konec a doba trvání viz. Tabulka 7. Nicméně sofistikovanější přehled projektového plánování lze vyuţít
Gantův diagram
projektu implementace viz Obrázek 12. Název kroku Stanovení cílů projektu Naplánování zdrojů Stanovení rozpočtu Schválení záměru vedením Návrh řešení Výběrové řízení – Projektový manaţer Zpracování klíčové dokumentace Školení a certifikace Výběr softwarového nástroje Implementace softwarového nástroje Nasazení a pilotní provoz na pilotním projektu
Start 2.7.2012
Konec 6.7.2012
Doba trvání 5d
9.7.2012 11.7.2012 13.7.2012
10.7.2012 12.7.2012 13.7.2012
2d 2d 1d
16.7.2012 16.7.2012
27.7.2012 27.7.2012
10d 10d
30.7.2012
3.8.2012
5d
6.8.2012 13.8.2012
10.8.2012 17.8.2012
5d 5d
20.8.2012
24.8.2012
5d
27.8.2012
28.9.2012
25d
Tabulka 7 - Harmonogram projektu
51
Obrázek 12 - Gantův diagram projektu implementace
5.3 Projektové role v implementaci Pověření vést projekt na sebe přijal sám jednatel a výkonný ředitel společnosti. Firma zatím nedisponuje projektovým manaţerem, jehoţ angaţování je jedním z kroků samotného projektu. Úspěch projektu implementace tak na sebe bere sám autor myšlenky, jediný zástupce vedení společnosti. Dílčí odpovědnosti jednotlivých liniových vedoucích jsou rovnoměrně rozděleny tak, aby byla do projektu zapojena kompletní manaţerská trojice. Po delších úvahách byl pro podpoření úspěšnosti projektového řízení a jeho zavedení na projekt implementace najat na projekt najat externí konzultant, který ponese rovněţ část odpovědností a ty budou zahrnuty ve smluvním vztahu s ním.
52
5.4 RACI matice odpovědností Pro jasnou definici odpovědností bude pouţita metoda odpovědnosti RACI, která popisuje přiřazení jednotlivých pozic k úkolu a stanovuje jejich stupeň odpovědnosti. Název RACI vychází z počátečních slov v anglickém jazyce: R
Responsible – určuje kdo je odpovědný za vykonání svěřeného úkolu
A
Accountable – určuje kdo je odpovědný za úkol jako celek
C
Consulted
– určuje kdo můţe poskytnout konzultaci nebo radu k úkolu
I
Informed
– definuje koho je třeba o průběhu nebo rozhodnutí informovat
Na níţe uvedené tabulce jsou rozepsány základní zodpovědnosti na projektu implementace mezi zaměstnance ITQ, s. r. o. Pro zpracování dokumentace a školení byl na projekt najat externí konzultant, který ponese rovněţ část odpovědností, které budou zahrnuty ve smluvním vztahu s ním Krok
Ředitel
Vedoucí vývoje aplikací R
Vedoucí IT Servisu R
Zaměstnanci Externí konzultant
A
Vedoucí vývoje portálů R
Stanovení cílů Naplánování zdrojů Stanovení rozpočtu Návrh řešení Implementace Zpracování dokumentace Školení a certifikace Výběr softwarového nástroje Výběrové řízení PM Nasazení a pilotní provoz Kontrola termínů a milníků
I
C
A
R
R
R
I
C
A, R
I
I
I
I
C
A A A
R R C
R C C
C C C
C, I I I
C C R
A
C
C
C
I
R
A
R
R
R
C, I
C
A, R
C
C
C
I
C
A
R
C
C
I
C
A, R
C
C
C
I
C
Tabulka 8- RACI matice projektových kroků
53
5.5 Informační kanály Komunikace je v projektové činnosti stěţejní a z tohoto důvodu je třeba zahrnout všechny pracovníky firmy do aktuálního dění. Jako nejvhodnějším informačním kanálem se jeví firemní email, do kterého budou zaměstnancům chodit aktuální zprávy o stavu projektu. Aby nezůstalo pouze u čtení, pro úspěch projektu bude vhodné uspořádat společné setkání zaměstnanců například u večeře, jejíţ součástí bude krátká prezentace. Její obsah by neměl přesáhnout časově jednu hodinu a důraz by měl být kladen hlavně na klíčové cíle projektu a na interakci mezi prezentujícím a posluchači. Dalším nástroje bude firemní intranet, kde zaměstnanci naleznou veškeré podklady k projektu – prezentace, projektový plán, uţivatelské příručky, odkazy na externí zdroje s projektovou metodiku. Informačním kanálem bude rovněţ školení zaměstnanců, které bude uspořádáno formou společného workshopu. Od zaměstnanců se očekává jejich aktivní zapojení do problematiky, protoţe je nezbytně nutné, aby projektově myslet začala celá firma. Školení tedy bude prakticky zaměřeno a zaměstnanci tak budou během školení pracovat jako na reálném projektu, včetně rozdělení projektových rolí, odpovědností, definování cílů a výstupů atd.
54
5.6 Klíčové fáze projektu 5.6.1 Naplánování pracovní zdrojů S ohledem na další obchodní aktivity firmy je třeba naplánovat kapacity jednotlivých vedoucích pracovníků tak, aby nebyl ohroţen chod firmy, a zároveň byly všichni klíčoví pracovníci do projektu maximálně zapojeni . Pracovník
Poţadovaná kapacita
Poţadovaná kapacita
Poţadovaná kapacita
v % pracovní doby
v % pracovní doby
v % pracovní doby
07/2012
08/2012
09/2012
70
60
50
30
50
50
Vedoucí vývoje portálů
60
40
40
Vedoucí IT Servisu
50
40
40
Výkonný ředitel ITQ, s. r. o. Vedoucí vývoje aplikací
Tabulka 9 - Alokace zdrojů na projektu
5.6.2 Příprava rozpočtu Jedná se v podstatě o plán činnosti společnosti na zvolené období, který přenáší cíle společnosti do jednotlivých středisek/poloţek a vyjadřuje jejich hodnotu v penězích. Ukazuje, kolik finančních prostředků musí společnost získat a kolik prostředků můţe vydat, aby v daném období dosáhla plánovaných cílů. Nákladová
Druh
T1
T2 T3
T4
T5
T6
poloţka
nákladu
Konzultant
Personální
Softwarové
Investiční
50.000
Hardware
Investiční
30.000
Certifikace
Investiční
12.500
Školení
Investiční
20.000
Občerstvení
Provozní
20.000 20.000 20.000
T7
T8
20.000 10.000
licence / rok
5.000
5.000
Celkem
5.000 217.500 Kč
Tabulka 10 - Rozpočet projektu implementace (v týdenních intervalech)
55
5.6.3 Výběrové řízení – Projektový manaţer Výběrové řízení na pozici projektového manaţera bude zorganizováno svépomocí, prostřednictvím internetové inzerce a přes portál linkedin.com. Pozice projektového manaţera je pro klíčová jak pro úspěch projektu, tak pro další směrování firmy a jejich aktivit. Bude třeba nalézt opravdu spolehlivého a zkušeného pracovníka, který pomůţe nastavit nové procesy. Inzerci je třeba zadat ihned po iniciaci projektu, aby mohlo výběrové řízení proběhnout v naplánovaném termínu. Výběrové řízení bude jednokolové, přičemţ u pohovoru budou všichni řídící pracovníci firmy ITQ, s. r. o. a externí konzultant, najatý na podporu projektu. Znění inzerátu bude následující: ITQ, s. r. o. Naše společnost je dravým hráčem na trhu s webovými aplikacemi, firemními portály a poskytováním IT servisních sluţeb. Rozšiřujeme náš mladý a progresivní kolektiv a hledáme právě Vás na pozici: Projektový manaţer Budete odpovědný/á za řízení projektů charakteru IS/IT v ČR a v Evropě, a to zejména za termínové a finanční řízení projektu. Náplň práce: •
Řízení projektů charakteru IS/IT v ČR a v Evropě
•
Odpovědnost za termínové a finanční řízení projektu
•
Řízení projektového týmu
•
Jednání se zákazníky
•
Analýza potřeb a spokojenosti zákazníků
•
Pravidelný reporting
Poţadavky: •
VŠ, příp. SŠ vzdělání technického směru
•
Praxe ve vedení týmu (nejlépe IS/IT) min. 2 roky
•
Výborné komunikační a vyjednávací schopnosti
•
Znalost anglického a německého jazyka
•
Odolnost vůči stresu
•
Flexibilita, kreativita,
•
Samostatné rozhodování,
•
Schopnost týmové spolupráce,
56
•
Důslednost a spolehlivost
Nabízíme: •
zajímavou práci ve stabilní a dynamické společnosti
•
moţnost profesního růstu
•
ohodnocení odpovídající dosaţeným výsledkům
Výhody: •
moţnost dalšího vzdělávání
•
sluţební telefon, sluţební notebook
5.6.4 Zpracování klíčové dokumentace 5.6.4.1 Příručka pro projektové řízení V rámci projektu bude projektovým týmem navrţena a poté zpracována firemní příručka pro vedení proejektů. Cílem vzniku této příručky je nutnost zanést základní stavební kameny projektového řízení v ITQ, s. r. o. do manuálu, který bude poté distribuován všem zaměstnancům firmy, ale i zákazníkům, se kterými bude ITQ, s. r. o. na projektech kooperovat. Součástí příručky musí být jednotlivé fáze projektu – ţivotní cyklus, očekáváné vstupy a výstupy při přechodu do další fáze projektu. Zpracovány budou taky odpovědnosti jednotlivých členů projektového týmu. Příručka musí být obsáhlá, jasně zacílená a srozumitelná všem čtenářům. Vycházet bude z metodiky PMBOK, coţ je cesta kterou se chce projektové řízení v ITQ, s. r. o. ubírat. 5.6.4.2 Smluvní dokumentace se zákazníkem Podle standardizovaného přístupu k projektovému řízení bude upravena i dokumentace, která bude pouţívána při komunikace se zákazníkem. Jednotný formát bude nastaven u oficiálních firemních nabídek, které budou odcházet k zákazníkovi. Standardizovanou formu budou mít rovněţ zápisy z projektových schůzek, průběţné zprávy o stavu projektu, které bude projektový manaţer reportovat výkonnému řediteli firmy a závěrečné zprávy o ukončení projektu. Nezbytnou součástí těchto reportu musí být srovnání plánu a skutečnosti, hlavně co se vyuţívání alokovaných zdrojů týče a dále pak plán versus realita u plánovaného rozpočtu. Tyto informace budou rovněţ zaneseny v informačním systému a dokumentace tak bude generováno právě informačním systémem pro projektové řízení.
57
5.6.5 Školení a certifikace Dalším krokem implementace projektového řízení je znalostní příprava projektového manaţera a dalších vedoucích pracovníků. Školení je nezbytnou součástí počátku úspěšného fungování a v počátku projektového řízení se vyplatí investovat do proškolení pracovníků finanční prostředky, ač se na první pohled mohou zdát nepřiměřené. Vybraná školení byla zvolena rychlým průzkumem trhu a byla vzata v potaz také doporučení externího konzultanta. 5.6.5.1 Školení vedoucích pracovníků Pro vedoucí pracovníky bude zajištěno školení Základy projektového řízení dle PMI. Školení je určeno účastníkům, kteří mají zájem získat základní odborné znalosti z oblasti projektového řízení, formalizovat a systematizovat své stávající znalosti v této oblasti a nebo připravit se na absolvování certifikace podle standardů PMI, úroveň Project Management Professional - PMP nebo Certified Associate in Project Management - CAPM. Cílem školení je poskytnout účastníkům základní znalosti a dovednosti nezbytné pro úspěšné řízení projektů v souladu s metodikou Project Management Institute (PMI) PMBOK Guide. Účastníci se seznámí se základní terminologií projektového řízení, získají přehled o organizačním uspořádání projektů, hlavních procesech projektového managementu dle PMBOK a aktivitách, které je v těchto procesech třeba provést. Kurz vede certifikovaný PMBOK profesionál se stupni certifikace - PMP, P2RP, CSPM.. Samotné školení nevyţaduje ţádné vstupní znalosti. Výhodou jsou však zkušenosti s prací na projektech. Po ukončení školení budou absolventi schopni: ovládat standardní terminologii projektového řízení podle metodiky PMI mít přehled o moţných způsobech organizačního uspořádání projektů vědět, jaké schopnosti musí mít projektový manaţer znát skupiny procesů projektového managementu dle PMBOK mít přehled o jednotlivých procesech projektového řízení podle PMBOK, jejich vstupech, výstupech, jakoţ i nástrojích a technikách pouţívaných v těchto procesech schopni aplikovat výše uvedená v praxi. Doba trvání školení – 2 dny Cena školení činí 12.000 Kč22
22
ONDEK, Štefan. Základy projektového řízení podle PMI [online]. c2010-2012. [cit. 2012-04-04]. Dostupné z WWW: http://www.projectman.cz/skoleni/329/detail
58
5.6.5.2 Školení projektového manaţera Pro projektového manaţera je připraveno školení, které ho připraví na certifikaci dle PMI, která je jedním z cílů projektu implementace. Kurz praktickým tréninkem připravuje na klíčová témata, která jsou předepsána pro certifikaci projektových manaţerů podle PMI ve stupni PMP®/CAPM®. Tématické bloky školení: The PMP/CAPM exam PM Framework, PM Processes Project Integration Management Project Scope Management Project Time Management Project Cost Management Project Quality Management Project Human Resource Management Project Communication Management Project Risk Management Project Procurement Management Professional & Social Responsibility V kurzu zazní vše podstatné, co je obsaţeno v PMBOK® Guide (Fourth Edition), podle které probíhá certifikace stupně PMP®/CAPM® od roku 2009. Školení je vhodnou přípravou k písemnému testu PMI® ve stupni PMP®/CAPM®. Zároveň se školení věnuje vybraným tématům ve struktuře PMBOK® Guide, která při certifikaci působí největší problémy. Procvičovány jsou komplexní znalosti a celkový přístup k řízení projektů podle PMI®. V rámci kurzu dochází i k seznámení s doporučenou literaturou a školení poskytuje praktické tipy pro individuální přípravu k certifikaci. Kurz je velmi dobře vyuţitelný k získání větší části povinných tréninkových hodin pro certifikaci PMI®. Cena školení: 18.000 Kč Doba trvání: 3 dny23
23
SHINE Consulting s.r.o. Příprava na certifikace PMP/CAPM [online]. c2010-2012. [cit. 2012-04-04]. Dostupné z WWW: http://www.projectman.cz/skoleni/397/detail
59
5.6.5.3 Certifikace stupně Project Management Proffesional Samotná certifikace se provádí elektronickou formou a
je třeba se k ní registrovat na
stránkách pmi.org. Podmínkou k připuštění k certifikaci je absolvování 35 hodin tréninku, coţ projektový manaţer prokáţe certifikátem, který obdrţí po absolvování svého školení. Certifikace probíhá formou testu v anglickém jazyce a obsahuje 200 otázek z oblasti PMBOK. Cena této certifikace je 375 USD. Cena je splatná před započetím kurzu a v tomto případě bude firma poţadovat, aby si ji uhradil sám projektový manaţer. Tato podmínka byla zmíněna i u přijímacího pohovoru. Před elektronickým testem je nutné vyplnit následující formulář: http://www.pmi.org/en/Certification/~/media/PDF/Certifications/PMP%20Application%20Fo rm.ashx
5.6.6 Výběr softwarového nástroje pro projektové řízení Aby bylo zaváděné projektové řízení efektivní, je třeba mít vhodně zvolený nástroj pro jeho podporu. V současné době jsou na trhu dostupné různé produkty, podporující základní projektové aktivity od plánování harmonogramu, rozdělování úkolů aţ po správu kompletního projektového portfolia v projektové kanceláři nebo kapitalizaci projektových nákladů. Poţadavky ITQ, s. r. o. na podpůrný nástroj projektového řízení jsou následující: Webová aplikace přístupná odkudkoliv Bez nutnosti instalace klientské aplikace na lokální pracovní stanice Nastavení oprávnění podle projektových rolí Moţnost editovat ţivotní cyklus projektu – workflow Podpora metodiky PMBOK Cenově přijatelný licenční model Po zváţení těchto kritérií doporučil externí konzultant na projektu následující dva rozšířené nástroje v českém prostředí: Microsoft Office Project Server Easy Project
60
5.6.6.1 Microsoft Office Project Server Skupina produktů Microsoft office project server zahrnuje komplexní aplikační architekturu pro projektové řízení, vykazování, sdílení dokumentů, kapitalizaci nákladů a dalších komponent. Maximalistická verze řešení zahrnuje níţe uvedené komponenty MS Office Project Server – jedná se o serverovou aplikaci, která zajišťuje komunikaci mezi klienty a informacemi ukládanými do databáze (MS SQL Server). Je postavena na WSS. MS Office Project Professional – aplikace (tlustý klient) slouţící pro plánování a práci s harmonogramy (projekty) uloţenými na projektovém serveru. Přes aplikaci jsou rovněţ spravovány zdroje, prováděny některé konfigurace atd. MS Office Project Web Access (PWA) – webový přístup k projektovému serveru, standardně poskytuje informace o uloţených projektech pro členy projektových týmů. Rovněţ umoţňuje přístup do tzv. pracovních prostorů projektů, ve kterých jsou ukládány dokumenty a formuláře. Přes PWA jsou také prováděny některé konfigurace systému. MS Windows SharePoint Services (WSS) – jedná se o „jádro“ aplikace MS Office Project Server. Je součástí MS Windows Serveru. Dále je Projektovým serverem vyuţívána pro ukládání dokumentů a formulářů - vytváří pracovní prostor projektu. Cenová náročnost MS Project Server 2010 – 161.370 Kč s DPH24
24
Microsoft. Orientační ceník produktů Office 2010 [online]. c2012. [cit. 2012-04-04]. Dostupné z WWW: http://www.microsoft.com/cze/office2010/orientacni-cenik.aspx
61
Obrázek 13 - MS Project server 2010 projektový harmonogram25
Obrázek 14 - MS Project server 2010 - plánování kapacit26
25
Microsoft. User-Controlled Scheduling [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW: http://www.microsoft.com/project/en-us/project-pro-2010-new-features.aspx 26 Microsoft. Team Planner [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW: http://www.microsoft.com/project/en-us/project-pro-2010-new-features.aspx
62
5.6.6.2 Easy Project Jedná se o webový portál určený pro řízení jednotlivých firemních projektů případně i k řízení celé firmy. Řešení je nabízeno v modulu software jako sluţba a je dostupné v cloudové verzi, kdy je moţné pořídit pouze licence za pouţívání a provozovat na hardwaru subjektu, který Easy Project vyvíjí. Prostřednictvím svých modulů umoţňuje organizovat práce a rozdělovat projektové úkoly. Tyto úkoly je moţné sledovat, nastavovat jim termíny plnění a s těmito termíny také manipulovat. Zároveň je moţné sledovat projektový rozpočet, stav jeho čerpání a dává tak online náhled na nákladovou sloţku projektu. Těmito funkčnostmi se pak stává i nástrojem, který poskytuje podklady pro účetnictví a fakturaci. Easy Project je nástrojem, který zjednodušuje komunikaci napříč projektem nebo firmou. Zároveň je evidována a je jasně průkazná historie na projektu. Jeho tvůrci se řídili Paretovo principem a 20% funkčností Easy Projectu zajišťuje 80% potřeb uţivatele. Cena pořízení – 49.990 Kč za instalaci a 1.990 Kč za kaţdý měsíc za cloudové provozování sluţby. 27
Obrázek 15 - Easy Project - výpis projektů28 27
Easy Project. Cena a způsoby pořízení [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW: http://www.easyproject.cz/cena-a-porizeni 28 Easy Project. Easy Project 2010 - řízení firmy, lidí a peněz v čase [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW:
63
Obrázek 16 - Easy Project - soupis úkolů29
29
Easy Project. Easy Project 2010 - řízení firmy, lidí a peněz v čase [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW:
64
5.6.6.3 Srovnání MS Project Server a Easy Project Srovnávací tabulka níţe hovoří pro Easy Project hlavně poslední poloţkou, kdy pořízení Easy Projectu pro ITQ, s. r. o. znamená více neţ třetinové náklady oproti MS Project Serveru. Zároveň není nutné při vyuţívání všech funkčností instalovat těţkého klienta, jako je tomu v případě Microsoft Projectu. To je nespornou výhodou. Microsoft rovněţ přímo nenabízí cloudová řešení a Microsoft Project Server je produkt cílený přímo do infrastruktury zákazníka. Z tohoto důvodu zcela přesvědčivě pro potřeby ITQ, s. r. o. se jeví jako vhodnější aplikace Easy Project a spolu s cloudovým řešením se její implementace stane téměř snadnou. Stačí jí pouze zapracovat do postupů a procesů pro pro řízení projektů ITQ, s. r. o. Parametr
MS Project Server 2010
Easy Project
Bez nutnosti těţkého klienta
Ne
Ano
Webový portál
Ano
Ano
Plánování zdrojů
Ano
Ano
Zadávání a sledování úkolů
Ano
Ano
Řízení přístupů
Ano
Ano
workflow Ano
Ano
Citovatelné
ţivotního cyklu projektu Podpora PMBOK metodiky
Ano
Ano
Cena pořízení
161.370 Kč
49.990 Kč
Tabulka 11 - Srovnání MS Project a Easy Project
65
5.6.7 Výběr softwarového nástroje pro sledování ţivotního cyklu poţadavku K řízení IS/IT projektům v dnešní době jiţ nezbytně patří systémy pro sledování ţivotního cyklu poţadavků. Aby byla implementace metodiky řízení projektu kompletní, je třeba vybrat do firmy ITQ, s. r. o. nástroj, pomocí něhoţ budou sledovány poţadavky na vývoj a chyby, které s sebou bude přinášet kaţdý projekt. Na doporučení externího konzultanta byly do uţšího výběru doporučeny dva nejrozšířenější nástroje v ČR, komerční software JIRA a open source nástroj Bugzilla. Tato kapitola se věnuje jejich stručnému srovnání a následně konečného výběru nástroje pro implementace do firemního prostředí. 5.6.7.1
JIRA
Softwarový nástroj od australské společností Atlassian. Podporuje a usnadňuje proces řízení projektů a poţadavků, nabízí flexibilní a uţivatelské nástroje pro řízení a sledování pracovníků při výkonu plnění úkolů. JIRA poskytuje dostupné informace pro tým přes webové rozhraní, v poslední verzi je dostupná i ve verzi pro mobilní telefony. Projektovým manaţerů pak přináší moţnost sledování a vyhodnocování alokace kapacit. Pomocí historie stavu poţadavků rovněţ zajišťuje průkaznou historii v projektové komunikaci a je schopna nahradit i cyklus akceptace. Jedná se o internetový portál, který je moţné provozovat jak v intranetu, tak v extraktu a z tohoto hlediska je moţné nástroj vyuţít i jako portál pro klientský servis či helpdesk. Jako nástroj je velice efektivní při sdílení komunikace, informací a dokumentace v rámci vývojového či projektového týmu. Projektovým manaţerům a liniovým vedoucím umoţňuje vytvářet reporty, sledovat statistiky a vyhodnocovat průběh projektu nebo vývoje. Nespornou výhodou je i prioritizace jednotlivých poţadavků a stanovování termínů a samozřejmě moţnost s těmito hodnotami hýbat dle potřeby. Ve své poslední verzi 5 JIRA umoţňuje velice dobře zpracované fulltextové vyhledávání, coţ usnadňuje práci všem uţivatelům. Aplikace má funkčnost, která umoţňuje vytvářet a přiřazovat workflow různým typům poţadavku.30
30
Atlassian. JIRA. Your Development Process, Your Rules [online]. c2012. [cit. 2012-04-04]. Dostupné z WWW:
66
Obrázek 17- JIRA ukázka poţadavku v nástroji JIRA31
Obrázek 18 - JIRA zobrazení homepage projektu32 31
Atlassian. JIRA. Your Development Process, Your Rules [online]. c2012. [cit. 2012-04-04]. Dostupné z WWW: 32 Atlassian. JIRA. Your Development Process, Your Rules [online]. c2012. [cit. 2012-04-04]. Dostupné z WWW:
67
5.6.7.2 Bugzilla Webová aplikace pro sledování poţadavků vyvinutá a pouţívaná organizací Mozilla. Jde o open source software s licencí Mozilla Public Licence. Principem aplikace je moţnost vloţit poţadavek nebo chybu kýmkoliv a přiřadit ji určenému řešiteli. U poţadavku lze sledovat a zadávat celou řadu parametrů, lze vkládat komentáře, kopie obrazovek, přílohy. Nástroj tak umoţňuje stejně jako u aplikace JIRA sledovat ţivotní cyklus poţadavku a mít v danou chvíli přesný náhled na stav řešení. Význam pojmu chyba (bug) je zde velmi obecný, neboť se tato aplikace pouţívá nejen pro evidenci chyb v pravém slova smyslu, ale i pro návrhy na vylepšení a poţadavky nových funkcí. Umoţňuje efektivní komunikaci mezi členy týmu, má v sobě zaimplementován i modul quality assurance, který umoţňuje kontrolovat dodaný kód pro úpravu nebo opravu aplikace. Aplikace umoţňuje verzování, přesouvání poţadavků z jedné do druhé verze. Workflow poţadavku je upravitelné, ale jedno workflow je aplikovatelné pro celý systém.33
Obrázek 19 - Bugzilla - úvodní stránka po přihlášení34
33
Bugzila.org [online]. c1998-2012. [cit. 2012-04-04]. Dostupné z WWW: 34 Bugzila.org [online]. c1998-2012. Bugzilla - úvodní stránka po přihlášení. [cit. 2012-04-04]. Dostupné z WWW:
68
Obrázek 20 - Zadání chyby do aplikace Bugzilla35
35
Bugzila.org [online]. c1998-2012. Zadání chyby do aplikace Bugzilla. [cit. 2012-04-04]. Dostupné z WWW:
69
5.6.7.3 Srovnání JIRA a Bugzilla Z níţe uvedeného srovnání a po zváţení všech aspektů bude jako nástroj pro řízení ţivotního cyklu poţadavku implementována aplikace JIRA v cloudovém řešení a pokud se osvědčí, bude investováno i do vlastní instalace ve firmě ITQ, s. r. o. Hlavním důvodem volby aplikace JIRA je její uţivatelská příjemnost, coţ je hlavním kritériem pro motivaci zákazníka k vyuţívání interní aplikace na řízení projektů. V případě Bugzilla její pořízení zdarma bohuţel nevyváţilo její primární zaměření spíše na IT svět, nikoliv svět obchodu, ze kterého se většinou zákazníci firmy ITQ, s. r. o. profilují. Současně je také u aplikace JIRA kvitována moţnost vlastní editace workflow poţadavků a moţnost nastavovat vícero typů těchto workflow. Parametr JIRA 5.0 Cena licence pro 20 uţivatelů 1200 USD / rok instalace, 100 USD / měsíc cloudové řešení36 Podporovaný operační Windows , Unix systém Podporované databáze MySQL / PostgreSQL / Oracle / MS SQL Server Podporovaný web server Apache/Tomcat Upravitelné workflow Ano poţadavku Více typů workflow Ano poţdavku v systému Česká lokalizace Ano
Bugzilla 4.3 Zdarma Windows, Unix MySQL / PostgreSQL / Oracle Apache/Tomcat, jboss Ano Ne Ano
Tabulka 12 - Srovnání JIRA 5 a Bugzilla 4.3
36
Atlassian. JIRA. Your Development Process, Your Rules [online]. c2012. [cit. 2012-04-04]. Dostupné z WWW:
70
5.7 Dopady na organizační strukturu Projekt přináší do organizační struktury novou pozici projektového manaţera, který bude přímo podřízen jednateli a výkonnému řediteli. Zároveň bude mít dostatečné pravomoci k tomu, aby byl schopen řídit i kolegy z ostatních útvarů a přitom nebyl odpovědný za jejich kaţdodenní pracovní výkony. Ty zůstávají na jejich přímých nadřízených. Projektový manaţer má pravomoc poţadovat kapacity jednotlivých programátorů nebo IT operátorů pro potřeby daných projektů. Určuje priority při řešení problémů na úrovni projektů a spolu s liniovými vedoucími vývoje portálů nebo aplikací a vedoucího IT servisu řídí pracovníky, kteří jsou zapojeni do daného projektového týmu. Projektový manaţer je přímo odpovědný za správný průběh projektu, za jeho ukončení a úspěšné uzavření. Je úkolován svým nadřízeným, ale zároveň funguje jako samostatná organizační jednotka, ačkoliv je zatím kvůli úsporám v personálních nákladech v útvaru sám. Jeho mzda je z 70 procent fixní a z 30% variabilní na základě úspěšnosti projektového vedení a projektových výstupů. Pokud se projektové řízení osvědčí, bude vedení firmy zvaţovat zřízení útvaru pro řízení projektů – projektové kanceláře, která by do budoucna spravovala celé portfolio projektů ve firmě ITQ, s. r. o.
Obrázek 21 - Organizační struktura s Projektovým manaţerem
71
5.8 Výstupy projektu implementace Finálním a ideálním výstupem výše popisovaných projektových aktivit je zavedená projektová metodika na bázi PMBOK, uchycení jejich základních prvků v uţivatelském manuálu nejen pro projektového manaţera. Ten samotný je také výstupem, neboť součástí projektu implementace je organizace výběrového řízení a stanovení základních kritérií pro pozici projektového manaţera. Po najmutí absolvuje projektový manaţer školení a následně certifikace, podobné školení absolvují i další vedoucí pracovníci firmy. Hmatatelným výstupem pak jsou rovnou dvě implementace informačního systému. V prvním případě se jedná o webovou aplikaci Easy Project, která v cloudovém řízení umoţní základní podporu projektových procesů, přiřazování, kontrolu a kompletaci úkolů, stanovování rozpočtu, projektových milníků, rozpočtu a vykazování projektových činností. Poskytne tak kompletní náhled na aktuální stav projektu odkudkoliv s počítačem nebo jiným zařízením připojeným na internet. Druhým informačním systémem, který bude rovněţ provozován v cloudovém řešení, je software pro sledování ţivotního cyklu poţadavku JIRA, který projektovému manaţerovi a vývojářům zajistí komunikaci se zákazníkem v detailu a zároveň bude zajištěna historie, zafixování zadání poţadavku na rozvoj nebo opravu chyby a dále bude takto elektronicky řešena i samotná akceptace a dodávky hotových aplikačních celků do infrastruktury zákazníka. Toto vše bylo navíc realizováno v rámci rozpočtu, který nebyl zcela vyčerpán. Detail čerpaného rozpočtu je v následující tabulce, původní rozpočet 500.000 byl vyčerpán ani ne z poloviny. Implementací tak byla splněna podmínka nutná k dalšímu rozvoji firmy, ke zvýšení její výkonnosti a optimalizaci nákladů.
72
Nákladová
Druh
poloţka
nákladu
Konzultant
Personální
Softwarové
Investiční
T1
T2 T3
T4
T5
T6
20.000 20.000 20.000
T7
T8
20.000 10.000 50.000
licence / rok
74.000 EP 24000 JIRA
Hardware
Investiční
30.000 0
Certifikace
Investiční
12.500
PMP Školení
0 Investiční
20.000
konzultantem Občerstvení
30.000 Provozní
5.000
5.000
Celkem
5.000 217.500 Kč 233.000 Kč
Tabulka 13- Rozpočet po realizaci projektových kroků
73
6 Výsledky Výsledkem diplomové práce je v první řadě porovnání metodik projektového řízení z několika dimenzí. I přes počáteční očekávání, ţe pro IS/IT zaměřenou firmu bude vhodnější metodika PRINCE2, jsem po zmapování potřeb firmy zvolil jako vhodnou metodiku PMBOK a toto rozhodnutí odůvodnil. Na základě výše uvedeného jsem navrhl postup a detailně rozpracoval jednotlivé kroky potřebné k dosaţení cíle. Přínosem pro čtenáře je především doporučený postup a také porovnání hlavních informačních systému pro podporu projektového řízení a informačního systému pro sledování ţivotního cyklu poţadavku. Srovnání – nejen finanční, můţe být vhodným materiálem pro podporu rozhodnutí jiného subjektu při řešení podobné problematiky. Porovnání jsem vypracoval na základě vlastních zkušeností, které jsem získal při instalaci, testování a aktivního pouţívání popisovaných informačních systémů doma i v zaměstnání. Dalším pozitivní přínos spatřuji v mapování trhu školení projektových metodik, kdy jsem zvolil optimální variantu školení a certifikace pro pracovníky firmy a projektového manaţera, u nichţ má vedení zájem je vzdělat v oblasti metodiky PMBOK. Přínosnou spatřuji také vypracovanou matici odpovědností, která často v projektech tohoto typu chybí a z vlastní zkušenosti mohu říci, ţe to bývá velmi často zásadní chybou. V pozitivních výsledcích práce spatřuji i osobní rozvoj v oblasti vědomostí projektového řízení, které bude inspirací pro mou další práci.
74
Závěr V první části diplomové práce byly popsány aspekty projektové problematiky IS od samotných kořenů – definice základních projektových pojmů aţ po detaily a srovnání světově uznávaných a rozšířených standardů pro projektové řízení. Dnešní doba si klade za cíl především realizaci plánů ve stanoveném čase, kvalitu výstupů a zároveň efektivní vyuţití zdrojů, a proto z tohoto srovnání vychází lépe agilní metodika. Důraz byl kladen především na metodiku PRINCE2 a PMBOK. Kritériem pro výběr vhodného standardu projektového řízení pro implementaci do konkrétní firmy byla zvolena SWOT analýza s ohledem na silné a labé stránky zvolené metodiky a příleţitosti a hrozby. Bylo zjištěno, ţe po zváţení všech aspektů analýzy obou metodik a s přihlédnutím k velikosti firmy i projektů, které firma realizuje, bude vhodnější jako vzor pro implementaci metodiky řízení projektu právě metoda PMBOK, která není jako PRINCE2 tak direktivní a umoţňuje přizpůsobit si metodiku pro potřeby vlastní organizace. Úvodem projektu implementace zvolené metodiky do konkrétní firmy byl uspořádán brainstorming interních zaměstnanců firmy k definování myšlenové mapy projektu a rizik tohoto projektu, které v průběhu implementace musely být brány v potaz. Na základě zvolené metodiky byl pak definován cíl projektu a pravidel, na jejichţ ţákladě byly specifikovány i firmení procesy s ohledem na organizační strukturu firmy, začlenění informačního systému, výběr a obsazení role projektového manaţera, která nebyla ve firmě zastoupena a dokumentace. Dále byl definován časový harmonogram s klíčovými termíny fází projektu, role a odpovědnosti specifikované pomocí RACI matice, kapacitní plány, plán rozpočtu a v neposlední řadě bylo vyhlášeno výběrové řízení na projektového manaţera. Dalším kritériem v postupu projektu bylo zvoleno vhodné školení projektového standardu vedoucích pracovníků a příprava nového projektového manaţera k certifikaci. Rovněţ byl zvolen informační systém pro podporu projektového řízení a sledování ţivotního cyklu poţadavku. Volba IS pro projektové řízení po porovnání MS Project server od firmy Microsoft a Easy Project padla volba na Easy Project především z hlediska nákladů. Výběr nástroje pro sledování ţivotního cyklu poţadavku byl zváţen systém JIRA od firmy Atlassiona a systém Bugzilla. Výběr padl na systém JIRA z hlediska uţivatelské přijatelnosti a pouţitelnosti především v IT prostředí.
75
Diplomová práce tak splnila svoje cíle – seznámila čtenáře s základní projektovou problematikou a na modelovém případu popsala aplikaci a zavedení projektového standardu do firemního prostředí.
76
Seznam pouţité literatury Bibliografie 1. DOKOUPIL, Otakar. Vztahy mezi zúčastněnými stranami v rámci řízení projektů IS/ICT. Praha, 2009. Diplomová práce. Vysoká škola ekonomická v Praze. Vedoucí práce Ing. Dušan Chlapek, Ph.D. 2. OGC, Office of Government Commerce. Managing successful projects with PRINCE2. 4th ed. London: TSO, 2005. ISBN 978-011-3309-467. 3. Project Management Institute. A guide to the project management body of knowledge: (PMBOK guide). 4th ed. Newton Square: Project Management Institute, c2008, 467 s. ISBN 978-1-933890-51-7.
Internetové stránky 1. Atlassian. JIRA. Your Development Process, Your Rules [online]. c2012. [cit. 2012-0404]. Dostupné z WWW: 2. Atlassian. JIRA. Your Development Process, Your Rules [online]. c2012. [cit. 2012-0404]. Dostupné z WWW: 3. Bugzila.org
[online].
c1998-2012.
[cit.
2012-04-04].
Dostupné
z
WWW:
4. Bugzila.org [online]. c1998-2012. Bugzilla - úvodní stránka po přihlášení. [cit. 2012-0404]. Dostupné z WWW: 5. Bugzila.org [online]. c1998-2012. Zadání chyby do aplikace Bugzilla. [cit. 2012-04-04]. Dostupné
z WWW:
FoodRep licator > 6. CIO magazine [online]. c2011 Reuters. [cit. 2012-04-01]. Phillips Joseph: Project Management Definition and Solutions. IT Project Management topics covering definition, objectives, systems and solutions. Dostupný z WWW: 7. Easy Project. Cena a způsoby pořízení [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW:
77
8. Easy Project. Easy Project 2010 - řízení firmy, lidí a peněz v čase [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW: 9. HAWDON, Cassie. Business IT course blog. [online]. c2011. [cit. 2012-04-01]. Dostupný
z
WWW:
managem ent.html.> 10. CHLAPEK, Dušan. Řízení komplexních projektů IS/ICT. [online]. 2005 [cit. 2012-04-24]. Dostupné z WWW: 11. ict-123.com. PRINCE2 [online]. c2009-2012. [cit. 2012-03-04]. Dostupné z WWW: 12. MAULE, Pavel. Porovnání PRINCE2 a PMBOK. [online]. 2004 [cit. 2012-04-24]. Dostupné z WWW: 13. Method123 Project Management Methodology. Project Management Best Practices [online]. [cit. 2012-03-02]. Dostupné z WWW: 14. Microsoft. Orientační ceník produktů Office 2010 [online]. c2012. [cit. 2012-04-04]. Dostupné z WWW: 15. Microsoft. User-Controlled Scheduling [online]. c2010. [cit. 2012-04-04]. Dostupné z WWW: 16. Microsoft. Team Planner [online]. c2010. [cit. 2012-04-04]. Dostupné
z
WWW:
http://www.microsoft.com/project/en-us/project-pro-2010-new-
features. aspx> 17. Modernanalyst.com. BROWN, Craig. The Community Blog for Business Analysts [online]. c2008. [cit. 2012-04-03]. Dostupné
z
WWW:
http://www.modernanalyst.com/Community/CommunityBlog/ta
bid/182/Default.aspx?ArticleType=ArticleView&ArticleID=439> 18. NOKES, Sebastian and KELLY, Sean: The Definitive Guide to Project Management: The Fast Track to Getting the Job Done on Time and on Budget. 2nd Ed.n. London (Financial Times / Prentice Hall): 2007. ISBN 978 0 273 71097 4 Dostupný
z
WWW:
managemen t.html> 78
19. Official PRINCE2® Website [online]. c2007-12 APM Group Ltd. [cit. 2012-03-04]. PRINCE2 - The Method. Dostupné z WWW: 20. ONDEK, Štefan. Základy projektového řízení podle PMI [online]. c2010-2012. [cit. 201204-04]. Dostupné z WWW: 21. Prince2.com [online]. c2012. [cit. 2012-03-04]. Dostupné z WWW: 22. Projectcartoon.com. How Projects Really Work (version 1.5) [online]. [cit. 2012-04-03]. Dostupné z WWW: 23. Project Management Institute. c2012. [cit. 2012-03-04]. Dostupné z WWW: 24. Server ManagementMania.com. Metoda CPM (Critical Path Method) [online]. [cit. 201204-04]. Dostupné z WWW: 25. Server ManagementMania.com. PRINCE2 (PRojects IN Controlled Environment) [online]. [cit. 2012-04-04]. Dostupné z WWW: < http://managementmania.com/prince2> 26. SHINE Consulting s.r.o. Příprava na certifikace PMP/CAPM [online]. c2010-2012. [cit. 2012-04-04]. Dostupné z WWW: 27. STANÍČEK, Zdenko. Moderní management. [online], c2012. [cit. 2012-04-01]. Dostupný z WWW: 28. ŠEBEK, Václav. Plánování a řízení projektů IS [online] c2011. [cit. 2012-04-03]. Dostupné z WWW:
z
WWW:
Study_ Outline.pdf > 30. University of South Carolina, Arnold School of Public Health, Dept. of Health Services Policy and Management Courses and Curricula, HSPM J716. Baker, S.L. Critical Path Method (CPM) [online]. c2004. [cit. 2012-04-04]. 79
Dostupné z WWW: 31. WIDEMAN, R. Max:The Role of the Project Life Cycle (Life Span) in PM [online]. [cit. 2012-03-02]. Dostupné z WWW: 32. Wordpress [online]. [cit. 2012-04-04]. Dostupné z WWW:
80
Seznam pouţitých obrázků Obrázek 1 - Projektový trojimperativ ....................................................................................... 10 Obrázek 2 - Projektové role a pravomoci ................................................................................. 19 Obrázek 3 – Jak fungují IS projekty v praxi ............................................................................. 22 Obrázek 4 - Diagram procesu PRINCE2 (šipky zobrazují směr komunikace) ........................ 27 Obrázek 5 - Projektové prostředí dle PRINCE2 ....................................................................... 27 Obrázek 6 – Seskupení procesů PRINCE2............................................................................... 29 Obrázek 7 - PRINCE2 - ţivotní cyklus .................................................................................... 34 Obrázek 8 - Ţivotní cyklus projektu PMBOK.......................................................................... 34 Obrázek 9 - Organizační struktura ITQ, s. r. o. ........................................................................ 39 Obrázek 10 - Myšlenková mapa projektu implementace ......................................................... 48 Obrázek 11 - Myšlenková mapa - rizika projektu implementace ............................................. 48 Obrázek 12 - Gantův diagram projektu implementace ............................................................. 52 Obrázek 13 - MS Project server 2010 projektový harmonogram ............................................. 62 Obrázek 14 - MS Project server 2010 - plánování kapacit ....................................................... 62 Obrázek 15 - Easy Project - výpis projektů .............................................................................. 63 Obrázek 16 - Easy Project - soupis úkolů ................................................................................ 64 Obrázek 17- JIRA ukázka poţadavku v nástroji JIRA ............................................................. 67 Obrázek 18 - JIRA zobrazení homepage projektu.................................................................... 67 Obrázek 19 - Bugzilla - úvodní stránka po přihlášení .............................................................. 68 Obrázek 20 - Zadání chyby do aplikace Bugzilla..................................................................... 69 Obrázek 21 - Organizační struktura s Projektovým manaţerem .............................................. 71
81
Seznam tabulek Tabulka 1 - Základní srovnání PRINCE2 a PMBOK .............................................................. 36 Tabulka 2 - Mapování objektů PRINCE2 na znalostní oblasti PMBOK ................................. 36 Tabulka 3 - Ţivotní cykly projektu dle obou metodik .............................................................. 37 Tabulka 4 - Certifikační stupně obou metodik ......................................................................... 37 Tabulka 5 - SWOT Analýza PRINCE2 .................................................................................... 46 Tabulka 6 - SWOT Analýza PMBOK ...................................................................................... 46 Tabulka 7 - Harmonogram projektu ......................................................................................... 51 Tabulka 8- RACI matice projektových kroků .......................................................................... 53 Tabulka 9 - Alokace zdrojů na projektu ................................................................................... 55 Tabulka 10 - Rozpočet projektu implementace (v týdenních intervalech) ............................... 55 Tabulka 11 - Srovnání MS Project a Easy Project ................................................................... 65 Tabulka 12 - Srovnání JIRA 5 a Bugzilla 4.3 .......................................................................... 70 Tabulka 13- Rozpočet po realizaci projektových kroků ........................................................... 73
82
Seznam pouţitých zkratek a symbolů IS
Informační systém
IT
Informační technologie
IS/IT
Informační systém/informační technologie
PMBOK
Project Management Body of Knowledge
PRINCE2
PRojects IN Controlled Environment
IPMA
International Project Management Association
ISO 10 006
International Organization for Standardization
PMI
Project Management Institute
CPM
Critical path method
OGC
Office of Government Commerce
CCTA
Centrální výpočetní a telekomunikační agentura
ITIL
Information Technology Insfrastructure Library
P3O
Portfolio, Programme and Project Offices
P3M3
Portfolio, Programme, and Project Management Maturity Model
MSP
Programme Management
M_o_R
Management of Risks
PMP
Project Management Professional
CSPM
Certified Software Project Manager
PWA
MS Office Project Web Access
WSS
MS Windows SharePoint Services
MS SQL
Microsoft Structured Query Language
CAPM
Certified Associate in Project Management
83
Přílohy Příloha č. 1
Manuál k projektovému řízení
84
Příloha č 1.
Projektové řízení ITQ, s.r.o.
Účel:
Definovat proces startu, plánování, realizace a ukončení projektu
Počátek platnosti:
01.09.2012
Konec platnosti: Určeno pro:
neurčeno Projektové manaţery, liniové manaţery, členy projektových týmů
Autor:
Jednatel a výkonný ředitel ITQ, s. r. o.
85
1 Úvod 1.1 Účel Účelem této interní normy je standardizovat postupy řízení a realizaci projektů ve firmě ITQ, s. r.o, včetně pouţívané dokumentace. Norma definuje závazný postup a náleţitosti pro plánování, řízení, reportování a ukončování projektů. Popisuje práci projektového manaţera, jednotlivé role a zodpovědnosti v rámci jednotlivých kroků procesu řízení projektu. Dokument nevysvětluje jednotlivé techniky plánování/řízení projektů. Proces řízení projektů v ITQ vychází z principů PMI.
1.2 Závaznost Tato interní norma je ode dne schválení závazná pro liniové manaţery ITQ, pro projektové manaţery a členy projektových týmů.
86
2 Základní pojmy Pojem
Vysvětlení
Projektový manaţer
Osoba zodpovědná za řízení a operativní vedení projektu (připravuje plány projektu, zadává práci členům projektového týmu, kontroluje průběh prací a plnění plánů). Je řízen Steering committee projektu (v rovině rámce Potřeby) a je odpovědný Projektovému výboru (v rovině Realizačního rámce). Skupina manaţerů firmy nominovaná do řízení jednotlivých projektů.
Projektový výbor Projekt
Projektová dokumentace
Projekt je jednorázová aktivita, která je prováděna za účelem dosaţení předem stanoveného cíle, v plánovaném čase a při vynaloţení jednorázových lidských a materiálních zdrojů. Účelem projektu je změna procesu/produktu/sluţby ITQ s co nejvyšším přínosem pro interního i externího zákazníka. Soubor povinných a nepovinných projektových dokumentů, které jsou definovány jako přílohy této normy. Tvoří nedílnou součást projektu ve formě výstupů jednotlivých fází.
Projektový rozpočet
Rozpočet projektu tvoří interní a externí náklady projektu. Pod pojmem náklady rozumíme nejen finanční náklady ale i zdroje (interní nebo externí), které je nutné vynaloţit při realizaci daného projektu. Externí náklady projektu jsou hrazeny třetím stranám (zpravidla dodavatelům), Interní náklady projektu tvoří především náklady na interní projektový tým.
Výstup
Hmotný či nehmotný výsledek projektu nebo dílčí projektové činnosti.
Zadavatel
Iniciátor změny. Popisuje v Projektové ideji především Potřebu a Přínosy, jako důvody pro realizaci.
Easy Project
Manaţerský informační systém pro podporu projektového řízení
JIRA
Informační systém pro sledování ţivotního cyklu poţadavku na rozvoj IS
87
3 Přehled pouţitých zkratek Zkratka
Vysvětlení
IS
Informační systém
IT
Informační technologie
PM
Project Manager (Projektový manaţer)
JRA
Software pro sledování ţivotního cyklu poţadavku
EP
Easy Project – manaţerský informační systém pro podporu projektového řízní
88
4 Projektové řízení v ITQ Metodologie pro řízení projektů, jejichţ výstupy jsou hlavně dodávané produkty nebo sluţby pro zákazník ITQ, s. r. o. Jedná se o souhrn aktivit spočívající v plánování, organizování, řízení a kontrole zdrojů společnosti s relativně krátkodobým cílem, který byl stanoven pro realizaci specifických cílů a záměrů
4.1 Cíle Projektového řízení Cílem projektového řízení je realizace projektu v souladu s jeho projektovým záměrem, časovým harmonogramem a rozpočtem za účelem dosaţení stanovených cílů projektu. Globální cíle projektu: Akceptace a platba projektového výstupu (produkt, sluţba) ze strany zákazníka Minimalizace nákladů, neshod/chyb a předcházení jejich vzniku Efektivní vyuţití zdrojů Eliminace a řízení rizik Plnění termínů
4.2 Definice projektu Projekt je definován jako jednorázová, organizačně náročná aktivita, která je prováděna za účelem dosaţení předem stanoveného cíle, v plánovaném čase a při vynaloţení jednorázových lidských a materiálních zdrojů. Účelem projektu je tvorba/změna procesu/produktu/sluţby ITQ s co nejvyšším přínosem pro zákazníka.
4.3 Organizace projektu/programu Projekt/program můţe mít organizační strukturu odpovídající jednomu ze dvou vzorů uvedených na následujícím obrázku nebo strukturu kombinovanou (z těchto vzorů).
89
Vedení projektu vyuţívajícího komplexní organizační strukturu sestává z PM přímo řídícího vedoucí týmů. Tito dále řídí jednotlivé členy týmů. (Tento způsob řízení se pouţívá pro rozsáhlé projekty s větším počtem zúčastněných pracovníků, které je vhodné sdruţit do týmů dle jejich zaměření resp. dle etap, na kterých se podílejí.) U projektů menšího rozsahu se pouţívá jednoduchá organizační struktura, ve které jsou členové týmu přímo řízeni manaţerem projektu.
4.3.1 Řídící výbor projektu (Project steering commitee) Členy Řídícího výboru projektu jsou: linioví manaţeři útvarů jejichţ pracovníci jsou členy projektového týmu, výkonný ředitel ITQ, s. r. o. Doporučený počet členů Řídícího výboru projektu je +/- 3. V takovém počtu je jednání maximálně efektivní a Řídící výbor projektu je schopen přijímat jasná rozhodnutí o jeho dalším směřování. Členové Řídícího výboru projektu se scházejí se na pravidelných jednáních, které svolává projektový manaţer. Frekvence a pravidelnost schůzek se stanoví při zahájení projektu dohodou mezi PM a členy Řídícího výboru projektu v Projektovém záměru.
4.4 Model Projektového řízení v ITQ Model projektového řízení reflektuje členění ţivotního cyklu projektu do 5 základních fází, včetně definovaných stavů a podmínek pro přechod z jedné fáze do druhé (tzv. Kontrolních bodů fáze projektu – kapitola 4.5.4).
90
4.4.1 Popis jednotlivých fází projektového řízení v ITQ Iniciace - příprava Zachycení zákaznické potřeby nového produktu nebo sluţby ve formě jednoduchého úvodního dokumentu. Jedná se o popis dané potřeby, stanovení přínosů a vyčíslení nákladů pro zákazníka. Součástí fáze příprava je předání oficiální nabídky zákazníkovi. Tento dokument by měl obsahovat: -
časový odhad realizace záměru
-
finanční stránku věci
-
potřebnou součinnost na straně zákazníka
Plánování
Naplánování aktivit dle náročnosti jednotlivých kroků. Výstupem této fáze by měl být časový harmonogram projektu, kapacitní plán jednotlivých pracovníků a zasazení jednotlivých milníků projektu v termínech (kalendáři). Takto zpracovaný plán projektu je nutné předat zákazníkovi a nechat si ho od něj schválit. Realizace Realizací se rozumí vývojové a další práce na podporu produktu nebo sluţby, která je cílem projektu. Jedná se i o projektové schůzky, kde se členové projektu setkávají se zákazníkem, vyjasňovaní nepřesností v zadání a řešení rutinních problémů vzniknuvších při realizaci díla. Akceptace Akceptací ze strany zákazníka nebo zadavatele projektu je podmínkou ukončení projektových prací, akceptací se rozumí nejen podpis akceptačního protokolu, ale i souhlasné stanovisko a spokojenost s dodaným výstupem projektu, v nejčastějším případě informačním systémem. Kontrola
91
Kontrolou se rozumí průběţné sledování plnění termínů, quality assurance u dodávaných kódů výpočetního systému, který neţ je předán zákazníkovi v jednotlivých dodávkách, musí být interně zkontrolován. Kontrola zahrnuje i pilotní provoz připravovaného informačního systému nebo produkut. Kontrola probíhá i během spuštění ostrého provozu, kdy je v rámci všech smluv podpora provozu ze strany ITQ v prvním týdnu ostrého provozu. Ukončení Ukončení projektu končí akceptací díla ze strany zákazníka. Zároveň je nutné mít splněny všechny cíle projektu, mít vyčerpaný projektový rozpočet případně zbylé prostředky mít převedené na jiné nákladové středisko. Ukončení zahrnuje také archivaci dokumentace v elektronické i papírové podobě, uzavření projektu v aplikaci JIRA a zároveň ukončení projektu v aplikaci EASY Project.
4.5 Identifikace a ošetření rizik projektu Prvotní seznam rizik je identifikován jiţ při tvorbě Projektového záměru a Projektovému manaţerovi je doporučeno zpracovat zároveň Analýzu rizik projektu – FMEA. V rámci této fáze projektu doplní Projektový manaţer rizika projektu do pracovního prostoru projektu v Easy Projectu a ke kaţdému riziku nadefinuje opatření, které riziku předchází nebo eliminuje jeho vliv na projekt. U kaţdého rizika musí být určen i dopad na projekt a pravděpodobnost výskytu. Během projektu pak pravidelně reviduje, zda se neobjevila nová rizika nebo zda se z původních rizik nenastaly problémy - riziko které nastalo je problémem.
92
4.6 Odpovědnosti Za tvorbu Projektového záměru je odpovědný Projektový manaţer. Kaţdý Projektový záměr podléhá schválení a podpisu: Projektovým manaţerem, Zadavatelem, členy řídícího výboru projektu, Za tvorbu Business specifikace je odpovědný Business Analytik (popř. Projektový manaţer). Kaţdá Business specifikace podléhá schválení a podpisu: Projektovým manaţerem, Zadavatelem, členy řídícího výboru projektu.
4.7 Shrnutí Po otevření projektu je třeba stanovit cíle projektu, identifikovat zákazníka a jeho potřeby, dále dopadené procesy a definovat návrh realizace jejich změn spolu s upřesněním jiţ dříve dodaných vstupů. Kontrolní list aktivit
Typ výstupu
Projektový záměr
Povinný
Analýza rizik projektu
Doporučený
Business specifikace (pro projekty s IT sloţkou)
Povinný
Komunikační plán
Doporučený
Harmonogram projektu (vč. milníků)
Povinný
Pravidelný Project Progress report
Povinný
93
5 Evidence projektových aktivit v aplikaci Easy Project 5.1 Přehledová obrazovka nastaveného projektu
94
5.2 Přidělené projektové úkoly
5.3 Evidence odpracovaného času
95
5.4 Projektové zprávy
5.5 Projektová dokumentace
96
5.6 Projektové milníky
5.7 Projektový kalendář
97
5.8 Ganttův diagram
5.9 Projektový rozpočet
98
5.10 Nastavení projektových rolí
5.11 Nastavení milníků
99
