Implementace metodiky řízení projektu do konkrétní firmy

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Implementace metodiky řízení projektu do konkrétní firmy Diplomová práce

Autor:

Bc. Jiří Krůta Informační technologie a management

Vedoucí práce:

Praha

Ing. Václav Šebek, CSc.

červen 2011

Prohlášení Prohlašuji, ţe jsem diplomovou práci 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

Bc. Jiří Krůta

Poděkování Na tomto místě bych rád poděkoval vedoucímu mé práce Ing. Václavu Šebkovi za jeho trpělivost, ochotu, odborné rady a podnětné připomínky při tvorbě práce.

Anotace práce Při zavádění projektového řízení v organizacích je výběr vhodné metodiky projektového řízení velmi důleţitý. Stejně tak důleţitý je samotný projekt implementace projektového řízení. Práce popisuje vybrané metodiky pro řízení projektů a jejich srovnání včetně rozhodnutí pro implementaci jedné konkrétní. Na reálném projektu je prezentován celý projekt implementace vybrané metodiky projektového řízení do konkrétní firmy, popis jednotlivých fází a řešených situací. V závěru práce je pak na tomto projektu poukázáno na problémy a výzvy, které bylo nutné v průběhu projektu řešit. Samozřejmě nechybí ani hodnocení projektu jako celku a jeho přínosů.

Annotation During project management implementation it is very important to choose project management methodology seriously. The implementation project itself is important as well. This paper describes and compares selected project management methodologies including decision for implementation one of them. Real project represents a real implementation of chosen methodology for a concrete company. The last chapter of the main body describes practical issues which arose during the projects. Of course, project results and benefits are included.

Obsah Úvod ...................................................................................................................................... 6 1.

2.

Pouţití projektového řízení ............................................................................................ 7 1.1.

Důvody a vhodnost pouţití projektového řízení ..................................................... 7

1.2.

Přínosy projektového řízení .................................................................................... 8

1.3.

Zavedení projektového řízení ................................................................................. 8

Metodiky pro projektové řízení .................................................................................... 10 2.1.

PMI – PMBOK ..................................................................................................... 10

2.2.

PRINCE 2 ............................................................................................................. 13

2.3.

Srovnání metodik .................................................................................................. 15

2.4.

Výběr metodiky .................................................................................................... 17

3.

Představení konkrétní organizace................................................................................. 19

4.

Projekt .......................................................................................................................... 21

5.

4.1.

Inicializační fáze projektu ..................................................................................... 21

4.2.

Plán projektu ......................................................................................................... 25

4.3.

Zavedení projektového řízení v oddělení vývoje software ................................... 31

4.4.

Zavedení projektového řízení v dalších odděleních.............................................. 42

4.5.

Reálné pouţívání metodiky................................................................................... 51

Vyhodnocení projektu .................................................................................................. 58 5.1.

Cíle projektu a jejich naplnění .............................................................................. 58

5.2.

Problematické body a výzvy do budoucna ........................................................... 60

Závěr .................................................................................................................................... 64 Seznam pouţité literatury .................................................................................................... 65 Seznam obrázků................................................................................................................... 66 Seznam tabulek .................................................................................................................... 67

5

Úvod Tématem této práce je implementace metodiky projektového řízení do konkrétní firmy. Ve své bakalářské práci jsem se zabýval tématem Metodiky řízení projektů střední velikosti, porovnáním vybraných metodik projektového řízení a demonstrací a diskusí postupů, které jsem pouţil při řízení konkrétního projektu. V rámci zpracování bakalářské práce jsem výrazně prohloubil svou znalost těchto metodik, především pak metodiky organizace PMI (Project Management Institute), která je publikována jako PMBOK (Project Management Body Of Knowledge). Díky seznámení se s danou metodikou, která mne oslovila svým zpracováním a logickou stavbou, jsem se rozhodl, a to i na základě předchozí zkušenosti se řízením projektů, implementovat tuto metodiku v organizaci, ve které pracuji na pozici projektového manaţera a vedoucího oddělení vývoje sw. Výběr tématu pro diplomovou práci byl jiţ poté velmi jednoduchý a sám se nabízel. Implementace metodiky projektového řízení je sama o sobě projektem. V této práci se budu věnovat popisu tohoto projektu – z pohledu definice cílů a očekávání, plánování projektu, implementačních prací a především s důrazem na samotný výsledek projektu, jeho reálné přínosy a dopady, řešené problémy, odchylky reality oproti plánu a očekáváním. Věřím, ţe tyto informace mohou být podnětné pro kaţdého, kdo by podobný projekt implementace projektové metodiky zvaţoval nebo připravoval. Informace z této práce ovšem nejsou přenositelné stoprocentně, vţdy je nutné přihlíţet ke specifikům dané organizace, pracovního týmu, potřebám společnosti atd.

6

1. Pouţití projektového řízení 1.1.

Důvody a vhodnost pouţití projektového řízení

Důvodů pro zavedení projektového řízení v organizacích můţeme najít velké mnoţství. Na začátek je však nutné uvést, ţe ne pro kaţdou společnost je pouţití projektového řízení vhodné. Pouţití projektového řízení je vhodné pro aplikace a problémy typické pro návrh a realizaci projektů [6]: vývoj nových výrobků inovace a rekonstrukce výrobků zavádění nových technologií zavádění nových výrobků do výroby a na trh návrh a realizace investičních akcí návrh a realizace stavebních akcí návrh a realizace informačních systému tvorba programových produktu zavádění systému řízení jakosti podle ISO 9000 příprava marketingových akcí zpracování a realizace podnikatelských záměru generální opravy strojů plán a realizace reorganizace firmy příprava a realizace zakázek v kusové výrobě Naopak projektové řízení není vhodné zavádět v situacích a společnostech, kdy se jedná o periodicky opakované činnosti např. operativní plánování výroby, periodické prohlídky strojů, kaţdodenní kontrolní činnosti apod. Pro tyto případy je vhodnější zavést jiné typy řízení (např. řízení podle odchylek, extremální řízení, programové řízení, apod.). Projektové řízení se také nehodí na jednoduché, bezrizikové akce, na které stačí rutina nebo tzv. selský rozum. Projektové řízení není vhodné pouţívat v mimořádných situacích (technické katastrofy, ţivelné pohromy, bezprostřední válečné operace, firemní a jiné krize). Pro takové případy jsou k dispozici jiné specializované postupy (např. krizový management). Pro aplikace projektového řízení nejsou vhodné příliš dlouhodobé akce, přesahující období dvou let. Projektové řízení se těţko prosazuje v podmínkách, kde vládne bezradnost, chaos, emoce a převládá nevzdělanost. 7

1.2.

Přínosy projektového řízení

Jako přínosy projektového řízení jsou obecně uváděny [4], [6], [13]: Zvýšení jistoty v dosahování cílů (sníţení rizika neúspěchu při dosahování cílů) Sníţení nákladu na firemní akce Zkrácení termínů firemních akcí Úsporu vynaloţené námahy Moţnost lepšího dorozumění se západními firmami Příleţitost podílet se na zahraničních zakázkách a projektech Zpřístupnění zahraničních půjček Připravit firmu na certifikaci z hlediska aplikace projektového řízení

1.3.

Zavedení projektového řízení

Projektové řízení by ve firmě mělo být zaváděno jako projekt, odpovídajícím způsobem připravený a řízený. Vzhledem k tomu, ţe se jedná o strategické rozhodnutí vysoké důleţitosti, měl by mít tento projekt absolutní podporu vrcholového vedení firmy, přesvědčení managementu o účelnosti a nutnosti realizace a odhodlání všech vedoucích úspěšně zavést projektové řízení ve firmě do kaţdodenní praxe. Zároveň bychom měli dát přednost profesionálnímu přístupu k projektovému řízení před amatérským přístupem. Proto základem by mělo být vyškolení všech zaměstnanců firmy, ať vedoucích nebo řadových pracovníku, ideálně v certifikovaných kurzech, ve kterých by absolventi získali příslušné vědomosti. Na zavedení projektového řízení je třeba navázat a podpořit jej i po stránce organizační, ať uţ vhodnou úpravou organizační struktury či pravomocí, tak i např. zavedením podnikové směrnice o vyhlašování, navrhování a řízení firemních projektů a jejich dokumentování, materiální (zřízení místností pro práci týmu), publikační (účelové publikace, odborné časopisy), účastí na odborných kongresech, apod., aby byly vytvořeny vhodné podmínky pro práci projektových týmu a fungování projektového řízení. Opravdu velmi důleţitým a významným krokem je zakoupení pečlivě vybraného softwarového produktu pro podporu projektového řízení, jeho kompletní implementace,

8

vyškolení

všech

uţivatelů

v jeho

obsluze

a sladění

všech

procesů

s procesy

implementované metodiky projektového řízení. Velmi vhodné je do projektu účelně zapojit různé poradenské subjekty k překonání případných problému a úskalí při zavádění a pouţívání projektového řízení. Tyto subjekty mohou přinést vítané know-how a zkušenosti z jiţ realizovaných podobných projektů, umoţní vyvarovat se nejčastějším chybám a jejich doporučení předejdou mnoha problematickým zkušenostem a postupům pokus – omyl. Kaţdý, kdo implementuje metodiku, si musí uvědomit, ţe metodika není šablona. Metodika není postupem, kuchařkou, která by stanovovala postup činností, které je třeba realizovat k úspěšnému výsledku projektu. Šablona v kontextu metodiky je pouze prostředek, který umoţňuje zpracovávat dokumenty, jeţ jsou vstupem nebo výstupem procesu, jednotným a přehledným způsobem a vedou uţivatele metodiky při formální dokumentaci.

9

2. Metodiky pro projektové řízení Metodik pro projektové řízení je poměrně velké mnoţství, liší se oblastí svého pouţití, hloubkou informací, svojí strukturou, sloţitostí a komplexností či oblíbeností. Mezi nejčastěji pouţívané patří metodiky PRINCE2 a IMPA se svým popisem PMBOK, na jejichţ stručný popis a srovnání se v této kapitole zaměřím. Část informací o těchto metodikách čerpám ze své bakalářské práce [8], ovšem tato práce si zaslouţí jejich rozšíření i s ohledem na výběr metodiky při zavádění projektového řízení.

2.1.

PMI – PMBOK

PMBOK (Project Management Body of Knowledge) [13] je metodika vytvořená PMI (Project Management Institute) a dnes dostupná jiţ ve své čtvrté revizi. Metodika je placená a lze ji objednat na www.pmi.org. Historie vzniku metodiky sahá do roku 1986, kdy byla v USA společností PMI vydána první verze knihy PMBOK. K dnešnímu dni je certifikováno na úroveň PMP (Project Management Professional) více neţ 500.000 projektových manaţerů na celém světě. PMBOK je rozděleno na 9 znalostních bází, které tvoří dohromady model projektového řízení v podání této metodiky. Metodika rovněţ poměrně podrobně definuje jednotlivé činnosti v průběhu celého ţivotního cyklu projektu, jeho fáze a popisuje vazby mezi těmito fázemi – přípravou, plánováním, realizací, kontrolou, ukončením. Příprava

Plánování

Realizace

Kontrola

Ukončení

Obrázek 1: Vazba jednotlivých činností projektu (nebo fáze) dle PMBOK

Dále PMBOK [11] definuje dalších několik desítek procesů, které jsou napojeny na jednotlivé ţivotní fáze projektu. Procesy jsou děleny do pěti procesních skupin, v kaţdé 10

pak jsou procesy hlavní a pomocné. Skupiny obsahují inicializační, plánovací, realizační, kontrolní, ukončovací procesy – v originále Initiation, Planning, Executing, Monitoring & Controlling, Closing. Obrázek 2 zobrazuje rozloţení aktivit souvisejících s jednotlivými skupinami v čase.

Úroveň aktivity

Realizační procesy

Inicializační procesy

Plánovací procesy Kontrolní procesy

Začátek fáze

čas

Ukončovací procesy

Konec fáze

Obrázek 2: Aktivita jednotlivých skupin procesů v čase

Jednotlivé procesy jsou standardem definovány podrobněji v přesné struktuře, která obsahuje: Cíle (popis procesu, jeho cíle a smysl) Vstupy (obsahují poţadavky, které jsou pro realizaci procesu třeba) Výstupy (definují výstupy pro ostatní procesy nebo okolí projektu) Nástroje a techniky (rozšiřují proces a metody dosaţení cíle, stanovují nároky na osoby zapojené do projektu) Metriky (umoţňují měřitelnost a určují jak vyhodnocovat daný proces) Jak bylo uvedeno, metodika definuje 9 znalostních oblastí, které je potřeba v kaţdém projektu realizovat. Pro tyto oblasti pak jsou opět definovány procesy a kaţdá znalostní báze je rozdělena na další části. Těmito znalostními bázemi jsou: Project integration management (integrace projektu a její řízení) Obsahuje metody pro koordinování a plánování projektu, změny a změnová řízení a jejich zpracování v projektu, změny plánu času, zdrojů, rozpočtu a obsahu projektu (scope). Jako jediná znalostní oblast je integrována v kaţdé procesní skupině, coţ odpovídá její podstatě – spojuje a integruje všechny ostatní oblasti. Project scope management (řízení obsahu a rozsahu projektu) Obsahuje procesy pro stanovení a plánování rozsahu projektu, sběr poţadavků, tvorbu harmonogramu, validace rozsahu a to v různých fázích a etapách projektu. 11

Project time management (řízení času) Obsahuje procesy pro plánování času ve vztahu k ostatním atributům projektu (zdroje, finance, rozsah), odkazuje na nástroje pro plánování času projektu, metody pro časové odhady náročnosti. Project cost management (řízení nákladů a financí) Procesy zaměřené na odhadování a plánování nákladů a zdrojů, odhadování nákladů, jejich kontrolu a vazby na další atributy projektu. Project quality management (řízení kvality) Obsahuje procesy s důrazem na řízení a kontrolu kvality projektu, nikoli produktu samotného (to je předmětem první znalostní oblasti). Project human resource management (řízení lidských zdrojů) Obsahuje procesy zaměřené na organizování lidských zdrojů, jejich získávání, rozvoj a motivování, tzv. soft skills. Project communications management (řízení komunikace) Definuje procesy pro plánování komunikace, distribuci informací. Nastavuje podobu reportingu a dalších administrativních úkolů s vazbou na všechny subjekty do projektu zapojené. Project risk management (řízení rizik) Risk management zahrnuje procesy pro hledání, klasifikaci a kvantifikaci rizik, jejich sledování, definování zodpovědností a identifikaci nových rizik. Project procurement management (řízení dodávky) Procesy pro řízení dodávky spočívají v dokumentaci dodávky (produktu), procesech směrem k dodavatelům, výběrových řízeních, sledování dodávek, uzavírání a správě smluv. Jak je vidět ze stručného přehledu vlastností metodiky, obsahuje všechny důleţité prvky pro komplexní řízení projektu. Jejími výhodami jsou navíc velmi dobrá přehlednost, popis technik řízení projektů, návaznost na ISO 10006, vazba metodiky na soft skills, propojení všech ţivotních fází projektu s oblastmi řízení a jednotlivými etapami projektů. Někteří kritici této metodice vytýkají přílišnou univerzálnost a malou konkrétnost v některých částech. Metodika nenabízí vzory a šablony a její implementace je tak velmi otevřená směrem k uţivatelům.

12

2.2.

PRINCE 2

PRINCE2 [4], [6] je metodika více zaměřená na ICT projekty. Jak napovídá název, jedná se o druhou revizi. Tato metodika vznikla ve Velké Británii a je zde také pouţívána jako standard pro projekty ve státní správě. Poslední aktualizace metodiky proběhla v roce 2009 a doplňujícími publikacemi v němčině, vlámštině, francouzštině a dalších jazycích, čeština bohuţel na tomto seznamu chybí a vzhledem k rozsahu metodiky a četnosti aktualizací to zřejmě i nadále tak zůstane. Metodika poskytuje rámec, který je primárně zaměřen na definování správných procesů, rolí, odpovědností a ţivotního cyklu projektu, nicméně jiţ příliš neakcentuje manaţerské dovednosti, řízení lidí, vyjednávání, řešení konfliktů. Ţivotní cyklus je v kontrastu k metodice dle PMI definován trochu odlišně, coţ je dáno specifickým navázáním procesů a komponent (viz Obrázek 3). Příprava

Řízení

Realizace

Kontrola

Plánování

Ukončení

Obrázek 3: Vazba jednotlivých činností projektu dle PRINCE2

Struktura metodiky staví na procesech, kterých je stejně jako v případě PMBOK také několik desítek. Dále je v metodice několik komponent, které ohraničují jednotlivé oblasti projektového řízení a jsou velmi blízké znalostním oblastem z PMBOK. Procesy jsou definovány velmi podrobně a kaţdý proces obsahuje: Základní informace (popis procesu, jeho cíle a smysl) Definice procesu a jeho popis Škálovatelnost (varianty procesu dle různé projekty) Role, odpovědnosti Vstupy (obsahují poţadavky, které jsou pro realizaci procesu třeba) Výstupy (definují výstupy pro ostatní procesy nebo okolí projektu) 13

Metriky (jak vyhodnocovat daný proces) Návody (doporučení a techniky k danému procesu) Na následujícím obrázku je zobrazen procesní model v kontextu k fázím projektu.

Předprojektem

Nastavení projektu

Vedení

Následné realizační fáze

Závěrečná realizační fáze

Vedení/směřování projektu Zahájení projektu Řízení hranic etap

Řízení

Řízení hranic etap

Nastavení projektu

Dodávka/ realizace

Ukončení projektu

Kontroling etapy

Kontroling etapy

Řízení dodávky produktu

Řízení dodávky produktu

Obrázek 4: Procesní model PRINCE2 v čase

Komponenty jsou rozčleněny na: Organization (organizace) Komponenta se zaměřuje na vymezení vztahů mezi subjekty, jednotlivými členy týmů. Plan (plánování) Obsahuje techniky a metody pro plánování projektů včetně všech vazeb s plánem souvisejících a komplexně pokrývá celým ţivotní cyklus projektu. Control (řízení a kontrola projektu) Komponenta obsahuje procesy pro řízení a monitoring projektu, včetně reportingu. Business case (obchodní případ) Prolíná ţivotní cyklus projektu s obchodním pohledem na projekt, obsahuje procesy pro rozfázování projektu, správu fází a dohled nad ţivotním cyklem projektu. Management of Risk (řízení rizik) Stejně jako v PMBOK se komponenta zaměřuje na řízení rizik, jejich sledování, vyhodnocování a ošetření. Configuration management (řízení konfigurace)

14

Definuje procesy pro kontrolu konfigurace – výsledného produktu. Obsahuje vazbu na další procesy, které se týkají ostatních oddělení, jako např. marketing, logistika, výroba, finance. Change control (řízení změn) Obsahuje procesy zaměřené na identifikaci a řízení změn, jejich vazbu na plánování. Řízení a kontrola projektu

Obchodní případ

Organizace

PRINCE2 PROCESY

Řízení změn

Řízení rizik

Řízení konfigurace

Plánování

PRINCE2 TÉMATA

PRINCE2 PRINCIPY Obrázek 5: Struktura PRINCE2 a její komponenty

Metodika PRINCE2 navíc obsahuje poměrně rozsáhlé přílohy, které se dělí na 5 částí a popisují detailně všechny procesy, role, rizika, šablony dokumentů a další doporučení pro samotné zpracování projektů.

2.3.

Srovnání metodik

Z popisu obou metodik vyplývá, ţe jsou velmi komplexní. Kaţdá má své zastánce i odpůrce. Následující srovnání je tedy spíše průřezem vlastností obou metodik a v další tabulce pak častých výtek nebo pozitiv uváděných v odborné literatuře a článcích [6], [7], [10], [13]. PMI Lokalita a příslušnost

PRINCE 2

Vazba na americké společnosti,

Více pouţíváno evropskými

pouţívanější v USA.

společnostmi (vznik ve Velké Británii).

15

PMI Úroveň hloubky

Šablony

PRINCE 2

Zaměření na vědomosti o nejlepší

Vedení ze strany metodiky,

praxi řízení projektů a zlepšení

postupy na úrovni rolí, procesů

jednotlivých oblastí.

a dokumentů.

Komplexní.

Zaměřuje se na klíčové oblasti.

Dokumenty jsou zde popsány

Obsahuje řadu šablon

mnohem obecněji.

k projektovým dokumentům.

PMBOK definuje obecná pravidla, které si organizace můţe dle specifik upravit. Připravenost metodiky

Slouţí jako stavební kámen pro

Připravená metodika.

firemní metodiku.

Nařizující závazné podmínky

Široce popisující, spíše

(procesy, struktury).

doporučující. Rozsah projektů Názvosloví

Širší rozsah záběru pro více typů

Nevhodná pro menší projekty.

projektů včetně malých projektů.

Zaměřena čistě na IT projekty.

Názvosloví je velmi blízké zaţité

Názvosloví úplně neodpovídá

praxi.

běţným standardům v projektovém řízení.

Silná vazba na oblasti řízení

Vazba na soft skills

Není.

lidských zdrojů a řízení komunikace. Role a kompetence

Zaměřena na sponzory

Hluboký záběr v oblasti rolí,

a stakeholders (účastníky

kompetencí. Čisté projektové

projektu).

vlastnictví a řízení top managementem.

Řízení životního cyklu

Projekt řízen požadavky

Kontinuální obchodní

zákazníka.

zdůvodnění.

Tabulka 1: Přehled vlastností metodik PRINCE2 a PMI

PMBOK

PRINCE2

Pozitiva:

Pozitiva:

Širší rozsah záběru pro více typů projektů.

Hlubší záběr v oblasti rolí, kompetencí.

Slouţí jako stavební kámen pro firemní Zaměření na produkt, zákazníka, uţivatele. metodiku.

Šablony a vzory dokumentů. 16

Přehlednost, struktura.

Kvalitní

řízení

změn,

ţivotní

cyklus

Vhodně propojuje ţivotní fáze projektu projektu. s řídícími strukturami. Podporuje ISO 10006. Negativa:

Negativa:

Neexistence šablon.

Někdy

Částečně obecnost.

svázanost (pro čtenáře bez zkušeností

přílišná

sloţitost,

provázanost,

s metodikami). Názvosloví

úplně

neodpovídá

běţným

standardům v projektovém řízení. Nevhodný pro menší projekty. Tabulka 2: Srovnání pozitiv a negativ metodik PRINCE2 a PMI

2.4.

Výběr metodiky

Rozhodnutí o pouţití konkrétní metodiky je vţdy individuální a je podmíněno mnoha faktory. Naše společnost se rozhodla implementovat metodiku dle PMI a vyuţít její popis PMBOK. Ţádná metodika není dokonalá a nemůţe stoprocentně vyhovovat kaţdé organizaci, proto jsme museli přijmout metodiku jako takovou se všemi výhodami a nevýhodami, výhody se pokusit vyuţít a nevýhody důkladně analyzovat a v průběhu projektu maximálně potlačit. Za výhody lze v našem případě povaţovat šíři záběru metodiky a poskytovaný rámec vědomostí, moţnost jejího pouţití pro menší projekty, orientaci na soft skills, velmi srozumitelné názvosloví. Velmi důleţitým argumentem pro rozhodování byla její znalost z mé strany. Díky tomu bylo pochopitelně moţné projekt lépe plánovat, byly jasnější a očekávatelnější cíle a daleko lépe bylo moţné pracovat s riziky, která by byla u neznámé metodiky hůře analyzovatelná. Nicméně je potřeba upozornit i na negativa, která výběr této metodiky v našem prostředí přináší. Těmi jsou neexistence šablon a dokumentace, které bude nutné v průběhu projektu vytvořit, a menší počet odborných společností, které se v ČR této metodice věnují. Nutné je rovněţ propojit rámec metodiky s existujícími procesy a metodami (v našem případě např. s interní metodikou vývoje software) a vytvořit tak na bázi této metodiky vlastní framework.

17

Větší volnost metodiky můţe být povaţována za výhodu i nevýhodu. S touto vlastností je třeba pracovat a vhodně ji vyuţít, nelze ji tedy zařadit ani do jedné kategorie, představuje však pro projekt také určité riziko.

18

3. Představení konkrétní organizace Společnost Apollo servis, ve které byl projekt realizován, se dlouhodobě zabývá poskytováním komplexních IT sluţeb pro své zákazníky – nejčastěji střední a větší společnosti. Historie společnosti sahá do počátku 90. let a společnost tak staví na pevných základech, jak v oblasti personální, tak i z pohledu zákaznického portfolia. Postupem času vrůstala orientace směrem k poskytování sluţeb a kompletních řešení. Hlavní předměty činnosti jsou vývoj informačních systémů, systémová integrace, komplexní správa IT, outsourcing, informační bezpečnost. Společnost zaměstnává zhruba 40 interních a externích spolupracovníků. Její organizační struktura je poměrně plochá s převaţující liniově-štábní strukturou. Společnost je členěna do oddělení, která mají vţdy svého vedoucího. Ten je zodpovědný řízení obchodní, personální, projektové a operativní agendy oddělení. V rámci oddělení jsou více či méně formálně definováni jednotliví vedoucí pracovníci dle oblasti nebo projektu. Jejich role mohou být aktuálně posíleny nebo utlumeny v závislosti na aktuálně řešených projektech a skladbě projektových týmů. Všechna oddělení společnosti realizují jak projektové úkoly (budování nových řešení, realizace projektů, komplexní dodávky a implementace), tak i operativní činnosti (podpora, servis a drobný rozvoj existujících řešení). Podíl těchto činností se mění v čase a liší se pro jednotlivá oddělení. Oddělení SW a kabeláţí realizují aţ 80% projektů, zatímco oddělení správy a pobočka Praha, zabývající se outsourcingem, věnují novým projektům zhruba 10 aţ20% kapacity, coţ ovšem nesniţuje důleţitost a potřebu úspěšné realizace projektů, protoţe ty jsou základním stavebním kamenem pro další dlouhodobou činnost u zákazníků. Společnost je drţitelem certifikátů ISO 9001:2000, ISO 27001 a prověrky NBÚ na stupeň Vyhrazené.

19

Ředitel společnosti

Asistentka

Vedoucí oddělení vývoje software

Zástupce ředitele

Vedoucí oddělení kabeláží

Specialista aktivních prvků

Specialista realizací

Externisti...

Kabeláže, LAN/WAN

Obchodní zástupce

Ředitel pobočky Praha

Analytik, konzultant

Programátor Vedoucí týmu

Obchodní zástupce

Vedoucí realizací

Programátor Vedoucí týmu

Programátor

Koordinátor, administrátor

IT administrátor

Programátor

Programátor

IT administrátor

IT administrátor

Programátor

Programátor

IT administrátor

IT administrátor

Vedoucí realizací

Helpdeskový operátor

IT administrátor

IT administrátor Žatec

IT administrátor

Externisti... Externisti... IT správa Plzeň

Obrázek 6: Schéma struktury rolí společnosti

20

Externisti...

4. Projekt 4.1.

Inicializační fáze projektu

V rámci inicializační fáze projektu bylo nutné stanovit cíle projektu a očekávání, stanovit projektový plán, časovou a finanční náročnost a vyhodnotit, zda je projekt pro společnost přínosný. V rámci inicializační fáze byla rovněţ provedena analýza rizik s realizací projektu spojených, byly vytvořeny návrhy na jejich odstranění a eliminaci. Zároveň však tato rizika byla brána v potaz při rozhodování, zda a jak projekt realizovat. Pro projekt byla vytvořena i jednoduchá SWOT analýza.

4.1.1. Cíle projektu Implementace metodiky byla motivována několika důvody. Jedním z nich je růst společnosti, který znamená zvýšené nároky na vedení týmů a projektů ruku v ruce s realizací větších a komplikovanějších projektů. Dalšími nikoli nezanedbatelnými je potřeba kontinuálního zvyšování efektivity realizace projektů, určitá standardizace postupů a také zachování nebo lépe zvyšování kvality realizovaných projektů, tzn. zvyšování konkurenceschopnosti a zajištění rozvoje společnosti. Cílem projektu bylo rovněţ stanoveno efektivnější a přesnější řízení rizik. Tyto poměrně obecně poloţené cíle, či spíše vize, bylo nutné transformovat na jednotlivé hmatatelnější body, které budou jak v průběhu, tak po skončení projektu vyhodnotitelné. Bohuţel z části se jedná o pojmy subjektivní a obtíţně měřitelné, vyhodnotitelné např. jen dotazníkovým průzkumem u zákazníků nebo zaměstnanců a vedení společnosti. Přesto bylo nutné najít a vybrat taková kritéria, která jsou alespoň částečně měřitelná. Základní projektové cíle byly stanoveny takto: Zavedení projektového řízení, zavedení metodiky projektového řízení a její navázání na současné procesy, metody a metodiky Nastavení rolí jednotlivých pracovníků a jimi odpovídající zvládnutí metodiky pro jejich role v projektech Realizace organizačních změn podporujících projektové řízení organizace a týmů Implementace silného softwarového nástroje pro podporu projektového řízení Nastavení jasného a přehledného systému sledování a reportingu projektů pro všechny úrovně řízení Zároveň s cíli byly stanoveny i jejich metriky: 21

Spustit projektové řízení v oddělení vývoje software do 6 měsíců od zahájení projektu Implementace nespotřebuje více neţ 12% kapacity pracovníků, kteří budou do projektu zapojeni Nasazení pouţívání pro další oddělení během následujících 6 měsíců tj. do 1 roku od začátku projektu Dosaţení vysoké úrovně znalosti projektového řízení alespoň 6 osob – jejich zapojení do pilotního projektu a plné vyuţití projektového řízení a metodiky z jejich strany Následující tabulka popisuje kritéria, která jsme se rozhodli vyhodnocovat pro vybrané projekty. Stejně tak jsme podle těchto kritérií vyhodnotili zpětně za 2 roky vybrané projekty (resp. jsme převedli existující hodnotící zprávy do jednotné podoby), tak abychom byli schopni odhalit změny, kterých bylo dosaţeno. Kritérium Profitabilita

Škála hodnocení %

Mnoţství změn projektu

%

Spokojenost zákazníka

1 aţ 10

Dodrţení termínu

%

Dodrţení pracnosti Naplnění zadání

% %

Poznámka Profitabilita vyjádřena poměrem příjmů a nákladů projektu; Personální náklady a interní firemní náklady jsou rozpočítány vţdy podle utilizace jednotlivých pracovníků Subjektivně definovaná procentuální hodnota reprezentující odchylku finálního produktu od původně navrţeného a plánovaného včetně vysvětlení důvodů odchylek (od změny zadání aţ po chybný návrh nebo pochopení zadání) Subjektivně hodnocená spokojenost na základě pohovoru se zákazníkem při dokončení projektu; 10 znamená nejlepší Procentuální vyjádření reálného času projektu oproti plánovému včetně odůvodnění prodlouţení termínů (cizí vlivy, navýšení pracnosti, chybné zadání, …); 100% znamená přesné dodrţení termínu, hodnota můţe být menší i větší neţ 100%, více100% znamená nedodrţení termínu Stejně jako předchozí bod Splnění poţadavků zákazníka na funkcionalitu (můţe nabývat vyšší hodnoty neţ 100%) včetně odůvodnění; 100% znamená splnění všech poţadavků

22

Kritérium Opětovná pouţitelnost řešení

Úspěšnost projektu

Škála hodnocení %

1 aţ 10

Poznámka Jaká část projektu je opětovně pouţitelná a mající přímý vliv na budoucí úsporu zdrojů; včetně odůvodnění; za pouţitelné je povaţované pouze dokumentované Subjektivně hodnocená spokojenost s průběhem projektu ze strany PM a vysvětlení nespokojenosti; Hodnota 10 je nejlepší

Tabulka 3: Kritéria pro hodnocení projektů

4.1.2. Pouţití metodiky a příjemci Ihned na začátku projektu bylo jasné, ţe způsob pouţití metodiky projektového řízení se musí lišit v závislosti na velikosti projektu a na pozici konkrétního pracovníka. Jinak s metodikou musí pracovat a vyuţívat ji vedoucí pracovník, jinak pracovník realizace aktivně zapojený do projektu a jinak dílčí zdroj projektu s jasně definovaným vstupem a výstupem. Zapomenout nesmíme ani na příjemce projektu – zákazníka, který sice do projektu vstupuje aktivně, nicméně ve vztahu k implementované metodice vţdy zprostředkovaně přes pracovníka naší společnosti. Bylo tedy nutné zohledni tyto čtyři skupiny pracovníků: Projektový vedoucího popř. management Projektový manaţer (PM) je vţdy hlavním koordinátorem a hybnou silou projektu. Předpokládá se u něho zapojení do většiny procesů a vyuţití nejvíce nástrojů, které jsou poskytovány. Management společnosti můţe být zapojen mnoha způsoby, nicméně jeho přístup je ve srovnání s PM vţdy orientován pasivněji – je příjemce informací případně dohledovým orgánem, který zasahuje pouze ve specifických případech. Pracovník aktivně zapojený do projektu Pracovník aktivně zapojený do projektu je na projekt dedikován výraznou částí své kapacity, je seznámen s rozsahem celého projektu, účastní se projektových schůzí, zná projektový plán, aktivně realizuje jednotlivé části, reportuje PM a je s ním v pravidelném kontaktu. Pracovník pasivně zapojený do projektu Pracovník pasivně zapojený do projektu je interním nebo externím zdrojem, který většinou dostává jasné zadání svého úkolu tj. s jasně definovaným vstupem a výstupem. Vzhledem k rozsahu a povaze jeho činnosti nezná celý projektový 23

záměr a postup projektu, nicméně jeho vstupy do projektu musí být v souladu s pouţitou metodikou. Zákazník V rámci zákazníka mohou být dle velikosti projektu definovány různé role. Stejně tak můţe být zapojen různý počet pracovníků, od situace kdy jeden pracovník plní zároveň všechny role, aţ po rozloţení činností na několik osob s různými kompetencemi, oprávněními a zodpovědnostmi u zákazníka. Na základě tohoto rozloţení vznikl další poţadavek na konkrétní implementaci metodiky – její maximální srozumitelnost a intuitivnost pro poslední dvě skupiny. Zatímco první dvě skupiny jsou součástí společnosti a mohou být tak školeny a vzdělány v oblasti pouţívání metodiky, u posledních dvou skupin je nutné intuitivní pochopení všech vstupů a výstupů, se kterými musí tyto skupiny pracovat. Nelze připustit situaci, ţe by pro tyto skupiny museli pracovníci projektového týmu fungovat jako prostředníci, kteří budou zajišťovat interface mezi interně pouţitou metodikou s nesrozumitelnými procesy a vstupy a vnějším prostředím.

4.1.3. SWOT V rámci přípravné fáze projektu jsme vytvořili SWOT analýzy, která popisovala hlavní očekávané přínosy implementace metodiky, ale stejně tak i rizika a hrozby, které je nutné v rámci projektu ošetřit a přijmout. Silné stránky

Slabé stránky

Implementace ověřeného a velmi funkčního modelu Široká pouţitelnost napříč obory a předměty podnikání Připravenost společnosti pro zavedení projektového řízení, stabilita Silné personální základy

Příležitosti

Poţadavek na zodpovědné pouţívání a dodrţování metodiky Nejsou definovány přesné vzory a šablony Bez předchozí zkušenosti s implementací metodiky Potřeba nastavit mezi operativou a projekty jasnou mez

Hrozby

Reálné zkvalitnění sluţeb Zvýšení efektivity fungování společnosti Otevření nových způsobů práce, řízení projektů a realizace zakázek Marketingové vyuţití

Deformace metodiky a pouţívání v čase Odpor zaměstnanců k „papírování“ Nevhodná implementace metodiky s moţnými výraznými škodami Pouţití metodiky i v situaci, kdy to není třeba

Tabulka 4: SWOT analýza

24

4.1.4. Analýza rizik V rámci analýzy rizik byla vytipována rizika projektu a popsány metody jejich prevence a sníţení, ale stejně tak i způsoby detekce (tj. ţe riziko nastalo a je nutné řešit dopad). Tato rizika pak byla brána v potaz při rozhodování o realizaci projektu, neboť projekt nepřináší jen naplnění cílů, ale při negativním průběhu samozřejmě můţe vést k projevům důsledků jeho rizik. Následující tabulku tuto analýzu ve stručnosti shrnuje. Riziko Nevhodná implementace metodiky, velká volnost metodiky Odpor zaměstnanců k pouţití

Nenaplnění očekávání

Zvýšení administrativní zátěţe; Sloţité a komplikované pouţití Deformace metodiky v čase

Dopad Zvýšení nebo zmaření investice; Prodlouţení doby nasazení; Demotivace zaměstnanců k pouţívání Ignorování projektu; Prodlouţení doby realizace

Zmaření investice; Rollback projektu (navrácení zpět); Ztráta času, který mohl být věnován jiným projektům Demotivace zaměstnanců k pouţívání; Sníţení efektivity

Sníţení efektivity; Zhoršení kvality

Prevence Rozdělení implementace na etapy a jejich pečlivé vyhodnocení; Nepodcenění úvodní analýzy a návrhu

Komunikace změn, cílů a přínosů pro jednotlivé pracovníky; Monitoring; Naslouchání názorům Realistické plánování cílů; Rozdělení na etapy a průběţné hodnocení

Vytvoření širšího týmu osob zapojených do projektu; Pečlivé filtrování způsobem „must be“ a „nice to have“ Zavedení pravidelného monitoringu a vyhodnocení pouţívání; Revize pouţívání a poţadavků na změny i po skončení implementace; Vytvoření plánu školení a seznamovací dokumentace pro nové pracovníky

Tabulka 5: Analýza rizik

4.2.

Plán projektu

Na základě předchozích analýz byl vytvořen plán implementace metodiky resp. projektového řízení. Vzhledem k tomu, ţe jsme si uvědomovali náročnost celého projektu, šíři záběru metodiky a rizika, která plynula z případných chyb v projektu, rozhodli jsme se projekt rozdělit na několik částí.

25

Implementovat metodiku ihned pro celou organizaci by bylo příliš náročné. Jako nejlepší variantu řešení jsme vyhodnotili naimplementovat a začít pouţívat metodiku nejdříve v oddělení vývoje software, které má k pouţití metodiky nejblíţe díky zavedeným metodám vývoje software, díky specifické základně projektů a samozřejmě také synergickému efektu personální spojení – projekt implementace metodiky jsem prosazoval já, řídil jsem jej a zároveň jsem tedy mohl nejefektivněji implementovat ve vlastním oddělení. Následně po této implementace a zavedení projektového řízení pro oddělení vývoje software byla naplánována implementace pro všechna ostatní oddělení. Díky tomu bylo moţné první část implementace vyhodnotit a v klidu naplánovat pokračování v dalších odděleních, vyuţít know-how z předchozí etapy, poučit se a sladit představy s reálnými potřebami a výsledky jiţ provedené práce, vyvarovat se chyb a problémů. Po zavádění jakéhokoli projektu nebo systému je vţdy nutná jistá doba pro zaběhnutí všech procesů při reálném pouţití, vyladění nesrovnalostí, optimalizaci detailů nebo doplnění funkcionality nepokrývající nějakou oblast. To představovalo poslední pilotní fázi.

Apollo servis Vývoj SW

Pobočka Praha

IT správa Plzeň

LAN/WAN

Projektový záměr, plánování, nastavení cílů, …

Inicializační fáze

Příprava, školení Používání, monitoring

1. etapa

Příprava, školení

Příprava, školení

Příprava, školení

2. etapa

Reálné použití, nastavení procesů udržitelnosti a rozvoje

3. etapa

Vyhodnocení, ukončení projektu

Ukončovací fáze

Obrázek 7: Schéma implementace napříč společností v kontextu k etapám projektu

26

4.2.1. Časový plán Projekt byl spuštěn v lednu roku 2010 a dle výše uvedeného principu byl rozdělen na tři etapy. Inicializační fáze probíhala do konce února a jejím obsahem byly především interní diskuse managementu, příprava projektového plánu, analýza rizik a samozřejmě i stanovení cílů projektu. První etapa projektu pak byla realizována v oddělení vývoje software. Její trvání bylo naplánováno na 6 měsíců. Během těchto 6 měsíců měla být týmu kompletně představena vybraná metodika, vytvořeny interní šablony a směrnice pro práci s metodikou a uvedeno v ţivot projektové řízení podle vybrané metodiky, a to v pilotním provozu. V rámci této fáze bylo nutné rutinně zvládnout pouţití metodiky, nastavit vhodnou úroveň (hloubku) pouţití metodiky a dobře nastavit vazby metodiky na současné procesy a pouţívané metodiky pro vývoj software. Ve druhé etapě pak měla proběhnout příprava a implementace metodiky pro další oddělení společnosti, na základě první etapy být zvolen rozsah implementace metodiky, vybráni pracovníci ostatních oddělení a definovány jejich role v projektu. Další kroky přípravy jiţ pak měly proběhnout velmi obdobně jako v první etapě, pouze s tím rozdílem, ţe bylo čerpáno z pozitivních zkušeností první etapy a do etapy se jiţ aktivně zapojili pracovníci vývoje software, kteří jiţ měli zkušenost s pouţitím metodiky z předchozí etapy. Paralelně s těmito procesy pak mělo probíhat pilotní pouţívání v oddělení vývoje software. Ve třetí etapě projektu mělo jiţ dojít k pouţívání projektového řízení všemi odděleními, mělo dojít k integraci činností jednotlivých oddělení, otevření otázek organizační struktury, provázanosti těchto oddělení na úrovni projektů atd. V závěru třetí etapy resp. celého projektu pak bylo plánováno zaměření se na problematické oblasti a korekce pouţití metodiky, ať uţ ve vztahu k rozsahu, pouţitým prostředkům nebo organizačním principům. Na závěr projektu pak proběhlo vyhodnocení implementace metodiky zvlášť pro jednotlivá oddělení v kontextu ke stanoveným cílům, plánu, očekáváním. Stejně tak byly analyzovány problémy, které se v průběhu projektu vyskytly a jejich vztah k analýze rizik. Zvláštní důraz byl kladen na nastavení dalších mechanismů, které by měly zajistit bezproblémové pouţití metodiky v budoucnu, její efektivní vyuţívání, návaznost na další inovační projekty atd.

27

Obrázek 8: Harmonogram projektu

4.2.2. Pouţité prostředky Pro vedení projektů, tvorbu a údrţbu projektových plánů byl zvolen produkt Microsoft Project ve verzi 2010 Server. Důvodem pro výběr tohoto produktu byla jeho široké rozšíření a tím i logicky velká základna dostupných informací, školení, kurzů, znalostních bází atd., bezproblémová integrace do prostředí Microsoft (vazba na SharePoint, Office) a z titulu partnerství se společností Microsoft i výhodné pořizovací náklady. Navíc díky předchozím

zkušenostem

s přípravou

jednoduchých 28

úloh

a projektových

plánů

realizovaných v této aplikaci bylo výrazně jednodušší implementovat novou verzi a na strany uţivatelů zvýšit a prohloubit znalosti a schopnosti pouţití systému. Program Project společnosti Microsoft představuje snad nejznámější software pro řízení projektů. Vyvíjel se od jednoduché aplikace na jednom počítači aţ k dnešnímu stavu robustního serverového systému umoţňujícího plnou týmovou spolupráci všech zainteresovaných subjektů. MS Project Server 2010 spolu s MS Project Professional 2010 tvoří systém podnikového řízení Microsoft Enterprise Project Management. Automatizace činností v projektovém řízení je nejlépe propracována v nejvyšší úrovni licence, MS Project Server 2010. Celá řada akcí vedoucího projektu nebo členů týmu má za následek automatické procesy u dalších účastníků projektu, připojených přes SharePoint Server. Celý systém umoţňuje jednotlivým členům týmu pracovat s harmonogramem dle jejich rolí, reportovat odvedené práce a činnosti, vykazovat svou činnost, a to i vzdáleně přes internet. Součástí MS Project je kromě běţných funkcionalit (harmonogram, Ganttův diagram, dynamické plánování projektu, kritické cesty atd.) i řada analýz ve finanční oblasti, testování scénářů „co kdyby“ a další.

4.2.3. Personální zajištění Vzhledem k tomu, ţe projekt byl iniciován mnou a z mé strany proběhla argumentace důleţitosti a uţitečnosti celého projektu pro společnost, definoval jsem část projektových cílů a navrhoval způsob realizace, byl jsem zcela logicky

pověřen vedením

a zodpovědností za celou realizaci projektu. Moje know-how a znalosti oblasti projektového řízení byly v rámci společnosti největší, včetně teoretické i praktické znalosti metodiky PMI. V roce 2008 jsem absolvoval certifikaci Společnosti pro projektové řízení, která je lokální partnerskou organizací IPMA (International Project Management Association) a jejíţ metodika je PMI docela blízká. Znalost PMI a PMBOK jsem poté dále rozšířil při dalším studiu této metodiky během přípravy své bakalářské práce a při jejím částečném pouţití při řízení projektů. Důleţitá pro úspěch projektu byla podpora ostatních členů vedení společnosti – majitele společnosti a vedoucích jednotlivých oddělení, takţe logicky prvním krokem v projektu bylo přesvědčit je o nutnosti této podpory a jejich aktivním zapojení do projektu. Jejich role tak byly definovány především pro druhou a třetí etapu projektu. První etapa se odehrávala mimo jejich oddělení a sféry jejich působnosti, zatímco druhá a třetí etapa zasahovaly přímo do fungování jejich oddělení a měly i jistý integrační prvek napříč celou 29

společností a znamenaly i organizační změny, i kdyţ nikterak výrazné. Pro druhou a třetí etapu projektu museli tito moji kolegové definovat ze svých oddělení pro jednotlivé pracovníky role a způsob účasti v projektu. Výběr osob a úrovně jejich zapojení do projektu však nebyl nikterak náročný a neznamenal ţádné komplikace – jiţ historicky a víceméně přirozeně byli v těchto odděleních pracovníci, kteří díky svým přirozeným schopnostem, rozhledu, profesní odbornosti a přirozenému respektu kolegů byli pověřování vedením realizací větších či menších projektů. Implementace projektového řízení tak měla jejich znalosti prohloubit a vhodně podpořit. Další zaměstnanci, kteří se projektovému řízení a vedení menších či větších projektů nevěnují, ale jsou členy projektových týmů, však museli být do projektu také zapojeni – alespoň na úroveň orientace v jednotlivých procesech metodiky, schopnosti provádět reporting dle metodiky, znalosti názvosloví, pochopení jednotlivých kroků vedoucích projektů tak, aby byli schopni se svými partnery adekvátně komunikovat a na projektech spolupracovat. Do projektu nebyli vůbec zapojeni zaměstnanci, kteří se nevěnují činnosti, která je předmětem podnikání, nevytvářejí produkty a sluţby, tedy např. asistentka ředitele, jejíţ náplň práce je spíše administrativní, účetní atd. Na následujícím schématu jsou vedoucí oddělení vyznačeni červeně, projektoví vedoucí pak modře. Vedoucí oddělení jsou zároveň i projektoví vedoucí. Ředitel společnosti

Asistentka

Vedoucí oddělení vývoje software

Zástupce ředitele

Vedoucí oddělení kabeláží

Specialista aktivních prvků

Specialista realizací

Externisti...

Kabeláže, LAN/WAN

Obchodní zástupce

Ředitel pobočky Praha

Analytik, konzultant

Programátor Vedoucí týmu

Obchodní zástupce

Vedoucí realizací

Programátor Vedoucí týmu

Programátor

Koordinátor, administrátor

IT administrátor

Programátor

Programátor

IT administrátor

IT administrátor

Programátor

Programátor

IT administrátor

IT administrátor

Vedoucí realizací

Helpdeskový operátor

IT administrátor

IT administrátor Žatec

IT administrátor

Externisti... Externisti...

Externisti...

IT správa Plzeň

Obrázek 9: Schéma struktury rolí organizace společnosti s vyznačením rolí v projektu

30

4.2.4. Externí konzultace V počátcích projektu jsme uvaţovali o podpoře ze strany konzultantů specializujících se na implementaci dané metodiky. Bohuţel jsme pro nás překvapivě narazili na skutečnost, ţe poradenských společností, které by poskytovaly podporu při zavádění metodiky dle PMI, není mnoho. Daleko širší základna je u nás pro metodiku PRINCE2, ale spíše v segmentu firem specializujících se na školení a přípravu certifikačních zkoušek, neţ na podporu a samotnou implementaci. Po několika schůzkách se společnostmi, které alespoň částečně nabízejí školení popřípadě pomoc při zavádění vybrané metodiky, jsme se rozhodli pro implementaci vlastními silami. Postupem času jsme nabyli přesvědčení, ţe všechny nabídky jsou zaměřeny velmi povrchně a společnosti se soustředí především na plnění určitých ukazatelů, které jsou na začátku projektu vydefinovány a které prokáţí odvedení úspěšné práce konzultantů, avšak úroveň výsledného produktu není úplně komplexní a zůstává spíše na začátku. Moţná je to způsobeno snahou aplikovat své ověřené postupy a spíše opakovat implementace, neţ se zaměřovat a řešit reálné potřeby. Anebo je tento stav do určité míry způsoben zákazníky, kteří nejsou ochotni zaplatit vyšší hloubku a úroveň. Kaţdopádně bylo nutné situaci přijmout a reálně s ní pracovat v projektovém plánu.

4.3.

Zavedení projektového řízení v oddělení vývoje software

Jak bylo popsáno v předchozí kapitole, první fáze projektu byla realizována v oddělení vývoje software a měla tak být pilotním zavedením projektového řízení, podle níţ pak budou realizovány implementace do dalších oddělení.

4.3.1. Zaškolení Nezbytným předpokladem pro implementaci metodiky je její znalost ze strany uţivatelů, pochopení principů projektového řízení, jednotlivých fází projektu, procesů realizovaných v jednotlivých fázích, znalostních bází, jejich vazeb atd. Aţ na tyto znalosti pak můţe navazovat pouţití šablon a dokumentů připravených pro daný účel. Studium a osvojení metodiky pouhým přečtením dokumentu o čtyřech stech stranách není úplně optimální cesta k nastudování a osvojení metodiky. Naopak by tento postup mohl působit přesně opačným efektem a vytvořit ihned z počátku ve všech zúčastněných odpor. Seznámení s metodikou tak proběhlo formou několika workshopů, kdy byla metodika představena sice dle PMBOK dokumentace, ale postupně a interaktivně s odpovídajícím komentářem 31

a vysvětlením jednotlivých pojmů a obtíţnějších kapitol. To navíc pomohlo překonat i případnou jazykovou bariéru. Jako doplněk k PMBOK byl jako český alternativní materiál pouţit dokument Projektové řízení (standard ČR dle IPMA) [12]. V oddělení jsou zastoupeny všechny kategorie příjemců – od projektových vedoucích, přes pracovníky aktivně zapojené do projektu aţ po externisty, kteří metodiku budou pouţívat pouze pasivně a zprostředkovaně přes ostatní vývojáře. Jejich rychlé proškolení bylo realizováno aţ v průběhu nasazování a pouţívání, a to jiţ samotnými vývojáři, aby byly hned od počátku nastaveny správné komunikační kanály. Situaci zjednodušilo, ţe jejich zapojení je v podstatě na úrovni přijímání zadání, reportingu výsledků, práce s knihovnami a obsahem repositářů či správců kódu. Změnil se tak pro ně především způsob, tedy technika, lehce se rozšířil způsob a objem reportingu tak, aby bylo získáváno více informací pro řízení.

4.3.2. Šablony Metodika dle PMI sice neobsahuje dokumentové šablony, nicméně k dispozici je několik různých zdrojů, ze kterých lze čerpat a šablony dokumentů dotvořit dle vlastních potřeb. Je však třeba upozornit, ţe ţádné z těchto šablon nejsou „oficiální“. Jedná se zřejmě o úmysl vzhledem k otevřenosti metodiky a jejímu moţnému pouţití napříč mnoha obory. Z dostupných zdrojů jsme vybrali šablony na http://www.projectmanagementdocs.com/, které jsme upravili dle vlastních potřeb a v průběhu projektu lehce dolaďovali dle interaktivních workshopů, vyhodnocování priorit informací v dokumentech a reálných potřeb. Nad šablonami jsme provedli tyto úpravy: Přejmenování do podoby anglický / český název včetně názvů hlavních kapitol dokumentů. Redesign podle tzv. corporate identity tj. nastylování do podoby odpovídající firemním dokumentům a standardům. Zavedení systému časových značek a verzování dokumentů, u obsáhlejších dokumentů zavedení kapitoly „Change log“ tj. seznamu změn, ze kterého je patrné, která část dokumentu se měnila a kým byla změněna. Sloučení některých dokumentů nebo zjednodušení jejich obsahu, vytvoření některých nových dokumentů resp. začlenění jiţ pouţívaných typů dokumentů.

32

Zavedení vloţených tabulek v některých dokumentech pro automatické výpočty (např. v Cost Management Plan zavedení vloţených XLS tabulek pro jednodušší práci a výpočty). Rozdělení dokumentů na interní a veřejné – interní dokumenty obsahují informace, které nemusí nebo nesmí (např. finanční) znát koncový zákazník, naopak veřejné dokumenty jsou vytvářeny s cílem jejich distribuce k zákazníkovi a slouţí jako komunikační kanál se zákazníkem.

4.3.3. Projekty a operativa V představení společnosti bylo zmíněno, ţe činnost firmy je rozdělena na projektové a operativní úkoly, jejichţ zastoupení se odlišuje především v závislosti na konkrétním oddělení. První etapa implementace probíhala pouze v oddělení vývoje software, nicméně i v rámci této implementace bylo nutné řešit způsob oddělení a zpracování projektových a operativních úkolů. Projektově je vhodné řídit činnosti, mající charakter projektů, představující určitá rizika realizace, vyţadující jisté plánování, řízení a monitoring. Naopak nemá cenu projektové řízení aplikovat na úkoly natolik rutinní, jednoduché a malé, kde by projektové řízení nepřineslo ţádnou výraznou přidanou hodnotu, celou realizaci by časově prodluţovalo, komplikovalo organizačně a také výrazně navyšovalo náklady takového řešení. Na základě diskusí jsme rozdělili činnosti do tří kategorií: Operativní požadavky a údržba Nejčastěji se jedná o přímé poţadavky zákazníků na drobné změny a opravy systémů a aplikací, které představují pracnost v řádu hodin. Do operativních poţadavků jsou zahrnuty i incidenty (hlášení problémů, nefunkčnosti a jejich odstraňování). Údrţba pak představuje dlouhodobou, pravidelnou a automaticky vykonávanou činnost, která je plánovaná a neinicializovaná vnějším zdrojem. Operativní poţadavky představují zhruba 20%, údrţba pak zhruba 10% vytíţení kapacit. Absolutní počty jsou však ve srovnání s počty projektů několikanásobné. Projekty Projekty jsou automaticky všechna nová řešení, vývoj a budování systémů nebo aplikací, pokud se nejedná o natolik jednoduchá řešení, jejichţ náročnost je v řádu hodin či desítek hodin a nevyţadují ţádné či jen omezené řízení a dohled. Do projektů jsou ovšem zahrnuty i poţadavky nazývané „rozvojem“ systémů, aplikací 33

či řešení, pokud se jedná o natolik komplexní poţadavky, kdy je třeba projít (i v omezené míře) všechny ţivotní cykly projektu a pro úspěšné vyřešení aplikovat projektové činnosti a procesy. Operativa s prvky projektového řízení Kdesi na pomezí mezi oběma výše zmíněnými skupinami leţí operativní poţadavky, jejichţ rozsah jiţ představuje pro realizaci určité výzvy, rizika a případné komplikace s potřebou plánování, monitoringu a řízení, avšak nelze na ně striktně aplikovat všechny postupy projektového řízení, jednoduše proto, ţe by to znamenalo zbytečnou neefektivitu a plýtvání zdroji a toto řešení by právem bylo moţné nazývat „s kanónem na vrabce“. Navíc by tento postup zcela oprávněně vyvolával negativní reakce jak příjemců takových projektů, tak i určitou demotivaci nad zbytečnou prací a byrokracií ze strany jednotlivých pracovníků. V těchto případech je tak nutné najít vyváţené pouţití projektových postupů, avšak bez jejich nasazování v neopodstatněných situacích nebo jen v „odlehčené“ variantě. Najít tento poměr je z dlouhodobé zkušenosti velmi obtíţné, obecně však vyţaduje citlivý monitoring řešeného problému s aplikací projektového řízení (ať uţ komunikační strategie, sledování a hodnocení rizik, plánování a revize plánů, change management atd.) kdykoli, kdy by jiný postup vedl k problematickým a neuspokojivým výsledkům.

4.3.4. Pouţívání metodiky Kaţdý, kdo kdy řídil projekt bez znalosti metodiky projektového řízení, pouţil částečně techniky, které se v metodikách objevují. To je dáno historií všech metodik projektového řízení a jejich základu v tzv. best practices. Metodiky tak určitým způsobem rozšiřují řízení a rozhodování o podrobněji precizované a popsané kroky, měřitelné veličiny, rozšiřují např. i škálu vnímaných a posuzovaných vlivů a okolností, zavádějí pokročilejší komunikační a řídící techniky. Pochopení metodiky tak není pro člověka s určitými zkušenostmi a znalostmi neřešitelný problém. Naopak. Metodika přináší popsatelným a uchopitelným způsobem něco, co daný člověk – projektový vedoucí dělal intuitivně nebo našel jako jednu cest na základě svých předchozích zkušeností, pokusů a omylů. Stejnou zkušenost zaţili i naši projektoví vedoucí a vedoucí týmu, kteří se své znalosti, zkušenosti a zaţité postupy konfrontovali s metodikou a jejími nástroji a procesy. Nová metodika pro ně přinesla určité změny, které lze velmi hrubě rozdělit do tří skupin: Úprava a prohloubení současných postupů 34

Metodika přináší ucelený popis procesů, jejich vztahy, vstupy a výstupy a výrazně tak prohlubuje a rozšiřuje zaţité postupy. S ohledem na velikost projektu je tak moţné jednotlivé procesy řešit opravdu do hloubky podle jasného, avšak dostatečně flexibilního schématu. Změny priorit, zavedení opomíjených technik a procesů Metodika otevřela nové pohledy na mnoho činností, které byly realizovány pouze okrajově nebo vůbec ne, ať uţ z důvodu nedostatečného know-how, jak je řešit, tak moţná i z důvodu nejasných vazeb a vyuţití. Implementace tak přinesla velkou výzvu pro relativně opomíjené oblasti, jejichţ začlenění však přináší zvýšení přidané hodnoty. Odhalení silných vazeb napříč všemi procesy a důraz na jejich integraci Procesy a skupiny procesů jsou kontinuální aktivity, přičemţ intenzita jejich aplikace se mění v průběhu projektu. Nelze tedy na ně pohlíţet jako na izolované činnosti, které se provádějí jedna po druhé a po skončení se k nim jiţ nevrací – jsou splněné. Právě jejich provázanost, operativní vyuţívání popsaných procesů metodiky, které je iniciováno událostmi nebo monitoringem a postupem projektových prací, je to, co napomáhá výsledné kvalitě projektu. Na straně pracovníků aktivně zapojených, avšak stojících mimo projektové řízení, přineslo seznámení

s metodikou

určité

rozšíření

rozhledu

a výrazně

napomohlo

jejich

efektivnějšímu fungování v projektu. Důvodem tohoto posunu je zřejmě schopnost více chápat souvislosti celého projektu a ne pouze izolovaně řešit své úkoly. Největší posun byl zaznamenán v těchto oblastech: Koordinace úkolů Díky alespoň částečné znalosti metodiky, její struktury, procesů, vazeb a činností vykonávaných ze strany projektových vedoucích mohou jednotlivý výkonní pracovníci lépe chápat začlenění svých úkolů, návaznost na ostatní činnosti, důleţitost plánování a designu při realizaci projektů. To se promítá jednak jejich vyšší aktivitou na projektových poradách a především jejich konstruktivním přístupem k řešení problémů nebo upozorňováním na problematické oblasti. Výkonní pracovníci jsou nyní velmi často zapojeni do plánovacího procesu při návrhu jednotlivých dílčích řešení nebo jejich dekompozici. Zde je opět patrná lepší komunikace a vazba na ostatní činnosti, projektový plán a vyšší pochopení návazných akcí. 35

Reporting a dokumentace Díky výše popsaným efektům došlo ke zlepšení komunikace i na úrovni reportingu. Pracovníci jsou schopni lépe vykazovat stav svých úkolů, jejich pokrok, případně problémy, vícepráce, zdrţení, neshody a odchylky oproti plánu. Výrazně jim situaci usnadňují i dokumentové šablony, které jsou vhodnými průvodci při reportingu a zajišťují jednotnou podobu. Značná část reportingu probíhá přímo v softwarovém nástroji MS Project. Change management, Risk management Změnová řízení jsou efektivnější opět díky znalosti vazeb projektu a principů jejich řízení. Stejně tak risk management – při znalosti rizik mohou tato rizika identifikovat i jednotliví členové týmu, upozorňovat na ně a případně i navrhovat ze svého pohledu optimální řešení. Většinou je ve všech negativech nebo rizicích implementace jakékoli metodiky jmenováno navýšení administrativní zátěţe a byrokracie jako prvek, který můţe sniţovat motivaci pracovníků, zatěţovat je administrativou na úkor času věnovanému realizaci a řešení. I v tomto projektu bylo nutné tento negativní prvek řešit, a to nejenom proto, ţe byl uveden v analýze rizik, ale samozřejmě a především proto, aby byl výsledek projektu co nejlepší a i po zavedení bylo dosahováno vysoké efektivity při zvýšení kvality. Bylo velmi obtíţné navrhnout způsob a rozsah vedení dokumentace projektu v kontextu k rozsahu projektu a volnost v jednotlivých poloţkách tak, aby dokumentace vyhovovalo poţadavkům na řízení projektů různé velikosti a povahy. Tento bod se stal jedním z důleţitých témat diskuse workshopů tak, abychom společně s celým týmem navrhli řešení a to v případně potřeby v průběhu projektu korigovali. Tento postup zajistil, ţe se všichni členové týmu cítili zodpovědní za rozhodnutí, bylo moţné si vysvětlit své postoje a rozhodnutí bylo společné. V případě problémů, komplikací nebo nesouhlasu v budoucnu tak byli všichni motivováni opět nacházet společně řešení.

4.3.5. Organizační změny V rámci první etapy nepřinesl projekt zásadní organizační změny v rámci oddělení vývoje software, coţ bylo dáno tím, ţe v rámci oddělení jiţ byly z velké části nastaveny projektové role a zodpovědnosti jednotlivých pracovníků před implementací projektu. Byla posílena formální stránka přidělování jednotlivých pracovníků na projekty, alokační řízení a nastavování rolí v rámci projektu, a to především díky nástroji pro podporu projektového 36

řízení MS Project, kde pro kaţdý projekt vznikala vlastní entita, jednotliví pracovníci byli na projekt alokováni dle projektových plánů atd.

4.3.6. Implementace MS Project Microsoft Project byl jiţ před spuštěním projektu pouţíván, ovšem pouze v edici Professional bez vazby na projektový server. To znamená, ţe projekty byly plánovány izolovaně a nástroj byl spíše pouţíván k dekompozici jednotlivých činností, zachycení jejich vazeb, sledování náročnosti a pracnosti oproti plánu, dokumentaci hotovosti jednotlivých úkolů a jako komunikační prostředek se zákazníky. V projektech byly plánovány zdroje pouze částečně a spíše staticky, tj. přiřazení zdrojů bylo na základě jejich alokace k projektu a z důvodu vizualizace na výstupu, nikoli z důvodu vazby na mnoţinu zdrojů a jejich kapacitu. V nové implementaci byl naplno vyuţit Microsoft Project Server jako serverová a centrální platforma pro uloţení všech projektů, sdílení zdrojů, kalendářů alokací atd. V rámci implementace byly vytvořeny šablony projektů, ve kterých jsou definovány časté činnosti a milníky (analýzy a specifikace, uzavření smlouvy, koordinační schůzky, testování, pilotní provoz, školení, instalace, předávání atd.) a liší se strukturou (např. byla vytvořena šablona pro projekty webových stránek, sloţitějších webových portálů, vývoje informačních a workflow systémů, rozvoje vlastních produktů, …). Aby bylo moţné nasadit Project Server opravdu komplexně, implementace obsáhla: Plné převedení všech projektů do jednotného prostředí Aby bylo moţné spravovat jednotně všechny projekty a řídit celé portfolio projektů, sdílet zdroje napříč projekty a plánovat jejich vytíţení mezi projekty, bylo nutné postupně všechny projekty importovat nebo vytvořit na projektovém serveru. Tato jednotnost pak umoţnila řízení celého portfolia projektů, řešení projektového workflow i ve vztahu k jiným projektům (některé činnosti nemohou probíhat na více projektech současně právě díky omezenosti zdrojů), modelování vytíţenosti zdrojů a vyuţití zdrojů. Díky analýzám typu What – If je moţné simulovat předpokládaná zpoţdění a jejich vliv na dostupné zdroje a jejich vytíţenost, ovlivnění kritické cesty atd. Správné řízení všech zdrojů a kapacit projektu i ve vztahu k operativě Při kompletním projektovém portfoliu je moţné řídit přidělování zdrojů mezi projekty, ovšem za předpokladu, ţe všechny kapacity jsou vyhrazeny pouze pro projekty, coţ je v případě naší společnosti nereálná situace. Část kapacit vţdy 37

připadá na interní agendu, operativní činnost nebo neproduktivní čas (nemoc, dovolená atd.). Pro jednotlivé pracovníky tak byly zavedeny kalendáře jejich dostupnosti pro projekty, které byly definovány na určitý počet hodin denně (např. namísto standardních 8h na 6h, přičemţ 2h denně jsou alokovány pro ostatní operativu). Z těchto kalendářů jsou pak vyjmuty dny osobního volna nemoci, popř. je upravena hodinová dostupnost, pokud krátkodobě naroste objem operativní činnosti, kterou je nutné řešit. To umoţnuje mít k dispozici reálnou kapacitu členů projektových týmů pro veškeré plánování a průběţné vyhodnocování. Začlenění systému již do fáze plánování Aby bylo moţné projekty efektivně plánovat a především řídit kapacity a zdroje napříč rozpracovanými a nově plánovanými projekty, bylo nutné začlenit do prostředí MS Project jiţ plánovací fázi projektů tak, aby výsledné harmonogramy nebyly jen odhadem, ale odpovídaly reálné situaci a moţnostem. Stejně tak je moţné vyhodnocovat vliv nově spouštěných projektů na existující a v případě potřeby vhodně redistribuovat zdroje tak, aby byly optimálně vyuţity a docházelo k nejmenším moţným zpoţděním i při přetíţení kapacit. Interními projekty a rozvojem vlastních produktů (tzn. produktů, které nejsou řešeny na základě poţadavků zákazníka) je pak moţné vhodně vytěţovat volné kapacity a rezervy a toto plánovat s časovým předstihem. Nastavení modelu reportingu a údržby plánů v MS Project MS Project disponuje několika moţnostmi reportingu stavu projektu a plnění úkolů – pomocí klienta Project Professional a přes webové rozhraní. Právě druhá varianta je velmi vhodná pro reportování stavu ze strany členů týmu a externistů pracujících na projektu. Vykazovat práci lze jak celkovým objemem odvedení práce, tak i po jednotlivých dnech. Vykazování lze téţ rozšířit i o neprojektové aktivity, vícepráce a přesčasy (tj. informace, ţe plnění úkolu zabralo více času, neţ bylo předpokládáno). Je moţné vykazovat procentuální hotovost úkolu a strávený čas, z čehoţ lze opět odvozovat přepokládanou celkovou náročnost úkolu a promítnou do revizí plánu a reportingu aktuálního stavu dokončení jednotlivých úkolů, etap nebo celého projektu. Integrace Integrace představuje velmi silnou stránku MS Project 2010. Krom integrace na aplikace Outlook, kam lze synchronizovat úkoly kategorizované po jednotlivých projektech, je velmi silným nástrojem integrace s portálem SharePoint. Ta přináší 38

z pohledu implementace metodiky projektového řízení velmi uţitečnou vlastnost – existenci projektu a jeho dokumentů v jediném úloţišti. Všechny dokumenty vzniklé na základě dokumentových šablon tak mohou být společně s vazbou na projekt, jeho harmonogram a další vlastnosti z MS Project, uloţeny na dokumentovém serveru a díky asociaci s projektem různým způsobem přístupné pro členy týmu. Odpadá tak nutnost pouţívat nástroje plánování a dokumentace odděleně. Výstupy Moţnosti výstupů patří k silným stránkám systému MS Project. Krom jiţ zmíněné integrace dokumentů a projektového plánu stojí za zmínku nová funkcionalita „Časová osa“, která umoţňuje velmi přehledně exportovat podstatné části harmonogramu a vkládat je do prezentací, mailů, dokumentů. Zákazník se tak nemusí zaobírat desítkami či stovkami jednotlivých úkolů a jejich vazbami, ale získá přímo z projektu souhrn nejdůleţitějších úkolů a milníků ve velmi příjemné vizuální podobě. Dalšími pohledy na projekt jsou tzv. Dashboards, které přinášení managementu a projektovým vedoucím velmi rychlý přehled nad celým projektovým portfoliem, stavem jednotlivých projektů a klíčových ukazatelů, především z pohledu plnění plánu nebo nákladů. Systém obsahuje desítky sestav, nejzajímavější pro naše pouţití jsou pohledy na lidské zdroje, ať uţ z úhlu kapacitního či výkonnostního, a finanční pohledy, které umoţňují sledovat reálnou nákladovost projektu i se započítáním nákladů na pracovní sílu např. při měnící se pracnosti. Po spuštění systému naopak nebyly z naší strany aplikovány analytické funkce nad portfoliem projektů, výběry projektů z pohledu strategické hodnoty nebo finanční návratnosti. Tyto funkcionality jsou vhodné spíše pro organizace, které řídí pomocí toho nástroje vlastní portfolio projektů a rozhodují se pro realizaci konkrétních interních projektů z určité mnoţiny na základě omezených zdrojů.

4.3.7. Celková integrace Nezbytnou součástí implementace metodiky byla integrace všech operativních i projektových procesů s metodikou resp. procesy vývoje software, s dokumentací vytvářenou před a na začátku projektu (analýzy, studie, scope, plány, design, …), dokumentací vznikající v průběhu projektu (změnová řízení, dokumentace kódu, 39

dokumentace produktu a projektu, uţivatelská dokumentace), dokumentací ukončující projekt (předávací protokoly, akceptační protokoly, testovací předpisy atd.). Nejdůleţitějším nástrojem pro tuto integraci byl výše zmíněný a popsaný Project Server a SharePoint portál. Nástroj jako takový však integraci zajistit nemůţe, tu zajišťuje nastavený systém práce, postupy atd. Stojící stranou však zůstávají fyzické výsledky vývoje – zdrojový kód a deployment, coţ je dáno specifičností tvorby zdrojového kódu a jeho nasazování. Pro efektivní správu zdrojových kódů jsou pouţívané tzv. SVN (subversion) nástroje, buď integrované přímo do vývojového prostředí (např. v případě Microsoft Visual Studia) nebo stojící mimo a pracující nad souborovým systémem (např. TortoiseSVN). Tyto nástroje řeší kompletní správu verzí zdrojových kódů, zamykání části obsahu, propojování jednotlivých částí a verzí několika vývojářů atd. Tento proces musí z důvodu své specifičnosti a sloţitosti zůstat oddělený. Nicméně v rámci projektu bylo zavedeno shodné verzování projektové dokumentace a SVN, tzn. kaţdá vývojová verze, kaţdé sestavení má své unikátní inkrementální číslo, na které se odkazuje veškerá dokumentace projektu – průběţný reporting, testování, předávání, akceptace, change management atd.

4.3.8. Vliv na zákazníky Cílem projektu bylo posílení pozice u zákazníků, zvýšení kvality projektů, zlepšení plánování a kontrolních procesů, zodpovědnější řešení změnových řízení atd. Přímý vliv na zákazníky lze definovat v několika bodech: Zpřehlednění plánovací fáze Zavedené procesy plánování jednoznačně vytvořily podklad pro zodpovědnější přístup k plánovací fázi. Zákazník tak dostává kompletnější a ve svém důsledku i relevantnější informace o provedených a plánovaných pracích. Stejně tak dostává daleko kompletnější podklady a poţadavky na jeho součinnost, návaznost akcí atd. Efektivnější reporting Efektivní reporting je snad nejsilnějším přínosem projektu z pohledu zákazníka. Reporty mají standardizovanou podobu, která je i díky lokalizaci informací do češtiny velmi přehledná. Detailnost a věrohodnost informací je na vyšší úrovni ve srovnání s obdobím před zavedením projektu, navíc i hodnota informací je vyšší a informace jsou přesnější. Výrazné zlepšení change managementu 40

Veškeré změny, které v průběhu projektu přicházejí, je moţné daleko efektivněji do projektu začleňovat a daleko lépe a komplexněji plánovat dopady na projekt, termíny, ale i samotného zákazníka, poţadavky na něj či jeho součinnost a fungování. Sestavení aktuálních reportů je navíc velmi rychlé a pohodlné. Formalizovanější přístup Formalizovanější přístup samozřejmě můţe být vnímán pozitivně i negativně, vţdy záleţí na situaci. V případě malých projektů můţe působit zbytečně přehnaně, naopak u větších a komplexnějších projektů a u větších a formálněji fungujících organizací je velmi vítán. Z dlouhodobého pohledu pomáhá předcházet veškerým konfliktním situacím, které mohou vznikat. Do budoucna je tak nutné míru této formálnosti vhodně řídit.

4.3.9. CMM (Capability Maturity Model) Model SW-CMM je model vzniklý v 80. letech za účelem hodnocení softwarových společností při výběrových řízeních pro ministerstvo obrany. Byl vytvořen pracovníky Institutu softwarového inţenýrství Carnegie Mellon Univesity a je dnes nejrozšířenějším prostředkem pro posuzování kvality procesů při tvorbě software. Původní označení CMM (Capability Maturity Model) je dnes spíše upraveno na SWCMM, protoţe později začaly vznikat jeho modifikace pro různé jiné oblasti (PM-CMM pro projektové řízení, TMM – model stupně zralosti procesu testování atd.). Model definuje firemní procesy v softwarových firmách do pěti úrovní spolu s klíčovými oblastmi: 1:

Initial Level: ad hoc proces.

2:

Repeatable Level (opakovatelná úroveň): řízení poţadavků, plánování sw

projektu, sledování a řízení sw projektu, řízení subdodávek softwaru, zajištění jakosti softwaru, konfigurační řízení. 3.

Defined Level (definovaná úroveň): zaměření organizace na proces, definice

procesu organizace, program školení a vzdělávání, integrované řízení vývoje softwaru, aplikace softwarového inţenýrství, koordinace mezi skupinami, přezkoumání (Peer reviews). 4.

Managed Level (řízená úroveň): řízení jakosti softwaru, kvantitativní řízení

procesu.

41

5.

Optimizing Level (optimalizující úroveň): prevence defektů, řízení změny

technologií, řízení změny procesu. Zatímco ISO 9000 je zaměřeno spíše na výrobní společnosti, zatímco SW-CMI a CMMISW jakoţto jeho nástupce jsou zaměřeny výhradně na proces vývoje software. Posouzení úrovně probíhá standardní metodou SCAMPI, která je rozdělena na varianty a aţ C. Ve variantě a se však jedná o poměrně dlouhý a náročný proces, při němţ musí asistovat autorizovaní autorizovaný posuzovat. Zřejmě by bylo zajímavé v rámci projektu sledovat úroveň dle SW-CMM resp. CMMISW, bohuţel pro to nebyl prostor. Mohu tak pouze odhadovat, ţe projekt posunul společnost z úrovně 2 velmi blízko úrovně 3 a její splnění je spíše otázkou implementace modelu a nadefinování cílů dle CMMI-SW, ale nevyţadovalo by jiţ zásadní kroky. Zaměření na CMMI-SW nyní chápu jako další stupeň zlepšení procesů, posouzení alespoň dle varianty C (interní audit) a dosaţení úrovně 3 je dalším logickým krokem, který na tento projekt můţe navazovat.

4.3.10. Hodnocení etapy V průběhu první etapy jsem se maximálně snaţil drţet projektového plánu a případné změny korigovat tak, aby byl projektový plán naplněn případně upraven v kontextu k aktuálnímu průběhu, problémům či zjištěním. Samozřejmě bylo nutné řešit mnoho nových otázek, výzev a problémů, které v průběhu etapy přicházely, nicméně ve své podstatě se nejednalo o problémy zásadního charakteru, které by ohroţovaly projekt. Bylo tak moţné se soustředit na co nejúplnější zvládnutí a dotaţení všech částí, ať uţ se jednalo o školení a řízení lidských zdrojů, návrh šablon, sladění se všemi ostatními procesy nebo nasazení nástroje MS Project, který, jak se v průběhu ukázalo, hrál pro úspěšnou implementaci jednu z klíčových rolí.

4.4.

Zavedení projektového řízení v dalších odděleních

Pro další etapy implementace byly vyuţity všechny zkušenosti a poznatky z první etapy. Na základě nich bylo moţné implementaci v dalších odděleních daleko lépe připravit a vyvarovat se chybám, jejichţ náprava by byla při plošné implementace daleko náročnější. Vzhledem k tomu, ţe ostatní oddělení byla vlastně z pohledu projektu jakýmsi interním zákazníkem, bylo nutné, aby projekt probíhal bezproblémově a nebyly prováděny zbytečné kroky. 42

Před začátkem druhé fáze tak byly doladěny všechny detaily projektového plánu, upřesněny kompetence, zodpovědnosti a poţadavky zúčastněných pracovníků dotčených oddělení, s vedoucími pracovníky diskutován rozsah a způsob implementace v kontextu k průběhu a výsledkům první etapy a hledán optimální postup ve všech oblastech.

4.4.1. Rozsah implementace Implementace probíhala pro tři samostatná oddělení společnosti – praţskou pobočku, která se zabývá především outsourcingem, správou IT/IS a dodávkou komplexních řešení, plzeňské oddělení správy, jehoţ náplň je velmi podobná, s výraznějším podílem správy IT/IS na úkor dodávky řešení, a oddělení kabeláţí, kde naopak nad servisem převaţují nové realizace strukturované kabeláţe, síťových a komunikačních řešení. Pro tato oddělení byl domluven základní rámec implementace, avšak odlišný resp. redukovaný ve srovnání s úrovní implementace v oddělení vývoje software. Vývoj software je ve srovnání s produkty a sluţbami poskytovanými ostatními odděleními daleko lépe zdokumentovaný a dokumentovatelný proces, a pokud odhlédneme od specifičnosti projektů na úrovni funkcionality, jsou jednotlivé kroky projektů více podobné a podobají se určitému základnímu scénáři. Navíc v oddělení software jsou všichni pracovníci do projektů více zapojeni. V ostatních odděleních je situace poněkud odlišná – nositeli hlavního know-how jsou většinou jen vedoucí projektu a hlavní realizátoři, řízení jednotlivých činností a kapacit je daleko nárazovější, obecně je zkušenost s pouţitím jakýchkoli metodik menší a procesy nejsou natolik popsány a uchopeny, jako je tomu při vývoji software. Určitou motivací pro toto omezení a zjednodušení ze strany vedoucích oddělení byla i obava z přílišného formalizování nebo navýšení byrokracie při realizaci na úkor efektivity a operativního řízení. Dohodli jsme se tedy pouze na implementaci a aplikaci některých klíčových prvků, u nichţ byl přínos dopředu jasný s tím, ţe ostatní body zůstanou otevřené a aţ po určité době a vyhodnocení rozhodneme o případném dalším rozšíření a prohloubení implementace blíţe k rozsahu první etapy.

4.4.2. Školení Školení probíhalo velmi podobně jako v případě první etapy, s týmem bylo pracováno velmi interaktivně, byl kladen větší důraz na pochopení, porozumění a schopnost aplikace jednotlivých procesů neţ na pouhé prostudování materiálů, v tomto případě PMBOK. Díky absolvované první etapě se do školení velmi aktivně zapojili projektoví vedoucí z oddělení 43

vývoje software, kteří tak mohli lépe předat svoje znalosti, zprostředkovat čerstvé zkušenosti se vstřebáváním problematiky atd. Jednotlivé procesy byly dokumentovány nad vybranými příklady jak z projektů vývoje software, tak po konzultaci s vedoucími dalších oddělení i z projektů oddělení, kterých se školení týkalo. Cílem bylo pracovníkům těchto oddělení maximálně přiblíţit techniky a postupy obsaţené v metodice pomocí příkladů jejich aplikace na reálné situace. Školení bylo spojeno s pouţitím konkrétních firemních šablon pro dokumentaci. Popisované procesy tak měly své hmatatelnější výsledky. Nicméně bylo důleţité se neustále drţet principu, který definuje proces jako techniku, rámec řešení, kontext situace a vstupů tzn. ţe metodika není aplikace konkrétní šablony nebo dokumentu ve správný čas.

4.4.3. Šablony Šablony byly mírně upraveny tak, aby vyhovovaly všem specifikům dalších oddělení, která je měly pouţívat. Jednalo se např. o rozšíření v oblasti Procure Management (řízení dodávek), coţ byla oblast, kterou SW oddělení neřeší nebo jen velmi vzácně a zjednodušeně. Uţ na počátku diskusí o úpravách šablon bylo stanoveno, ţe veškeré úpravy šablon musí být realizovány ve společném konsenzu vedoucích oddělení, aby nedocházelo k situacím, ţe budou vznikat deriváty pouze pro specifické účely a správa šablon a dokumentů a jejich další pouţití a rozšíření se do budoucna natolik znepřehlední, ţe bude nutné časem přistoupit k reengineeringu.

4.4.4. Projekty versus operativa Jak bylo popsáno na začátku práce, zastoupení projektů a operativy se v jednotlivých odděleních poměrně dost liší. Pro oddělení správy a outsourcingu výrazně převaţuje operativa, v oddělení kabeláţí zase nové projekty. Ani pro jedno oddělení nebyl implementován sofistikovaný nástroj plánování zdrojů a kapacit, tak jako v oddělení software. V oddělení kabeláţí by se to zdálo jako jasný krok, ovšem na druhé straně stojí fakt, ţe oddělení je poměrně malé, na jednotlivé zakázky působí mnoho vnějších vlivů, které vţdy zakázky komplikují (změny termínů dodávek, návaznost na další subjekty – další kontraktory zákazníka, posuny sledu dodávek, ale třeba i počasí). V odděleních správy nemá exaktní plánování také význam, protoţe operativa, různé provozní problémy, havárie a incidenty, které pracovníci řeší, mají samozřejmě vţdy prioritu a realizace projektů probíhá v časových oknech, kdy je jejich vytíţení menší. Plánování zdrojů na 44

pokročilejší úrovni by bylo moţné pouze v případě, ţe by byly týmy fyzicky rozdělené na realizaci a servis, jako je tomu v některých společnostech. Taková reorganizace ale sahá za moţnosti a hranice této implementace. Plánovat tak nelze stejně jako u software, kde je vnějších vlivů minimum a spíše se pracuje s optimálním rozvrţením kapacit a nutností dodrţení termínů.

4.4.5. Organizační změny Jako v první etapě byla posílena formální stránka přidělování jednotlivých pracovníků na projekty a nastavování rolí v rámci projektu. Za důleţité však povaţuji zmínit se o otázce organizační struktury společnosti jako takové. Velmi často se v souvislosti se zaváděním projektového řízení v organizaci hovoří o změně či spíše rozšíření organizační struktury na projektovou resp. maticovou. Častější je rozšiřování liniové, liniově-štábní nebo divizní skupiny. Nasazení čistě maticové struktury je velmi vzácné. Základem maticové organizační struktury organizační struktury je klasická vertikální liniová struktura, která je kombinována s horizontálně fungujícími adhoc vytvářenými týmy, které se věnují projektům [1], [2].

Projekt XY Obrázek 10: Schéma maticové (projektové) organizační struktury

Apollo servis má ve své podstatě liniově-štábní organizační strukturu, kdy jsou jednotlivá oddělení velmi autonomní, ať uţ v otázkách finančních, obchodních, personálních, technických, coţ vychází z historického vývoje a evoluce růstu jednotlivých oddělení. V průběhu projektu a postupem rozšíření projektového řízení do dalších oddělení tak přišla

45

na řadu diskuse případných zásahů do organizační struktury či vytváření nových rolí pro projekty. Aby bylo moţné diskutovat samotný proces změny organizační struktury, je třeba vzít do úvahy všechny výhody a nevýhody, které současné uspořádání přináší a diskutovat jej se změnami, které je organizace schopna dosáhnout při úpravě struktury. Byla proto vytvořena jednoduchá analýza. Současný model přináší autonomii jednotlivých oddělení, maximálně zrychluje a zefektivňuje rozhodovací procesy v rámci oddělení. Na druhou stranu při projektech a úkolech, kterých se účastní pracovníci napříč společností, jsou občas patrné problémy, ať uţ v komunikaci, tak i v nedostatečném přiřazení priority a nasazení pracovníků pro podporu poskytovanou interně. V rámci projektů realizovaných pro zákazníky je model funkční, pracovníci jsou zvyklí projekty řešit zodpovědně a uvědomují si důleţitost kvality ve vztahu k zákazníkům. Stejně tak je velmi funkční a dobře organizována obchodní synergie a vyuţití potenciálu zákazníků jednotlivými odděleními a předávání si obchodních příleţitostí. Bohuţel u interních projektů a poţadavků je situace poněkud sloţitější. Dříve bylo nutné u zákazníků řešit situaci, kdy probíhalo několik projektů současně a zákazník tak měl několik kontaktních osob z různých oddělení dle typu projektu. To však jiţ bylo odbouráno mechanismem, který zajišťuje přiřazení klíčové osoby pro zákazníka z oddělení, které u zákazníka realizuje největší objem obchodů, ostatní oddělení pak tohoto pracovníka informují o provádění své činnosti a dílčí záleţitosti jsou jiţ se zákazníkem řešeny napřímo. Rozšíření o maticovou strukturu přináší moţnost rychle vytvářet, měnit a rušit týmy bez zásahu do hlavní organizační struktury. Týmy disponují větším know-how a mohou operativněji reagovat na vzniklé situace a umoţňují zvyšovat kvalifikaci a schopnosti jednotlivých členů týmů pracovat v týmu nebo jej vést. Naopak nevýhodami jsou vytvoření dvojích vztahů podřízenosti – ke svému liniovému vedoucímu a vedoucímu projektu, coţ často vede k nedorozumění a konfliktům, způsobuje problémy v distribuci kapacity pracovníka pro řešení úkolů, případně vyvolává boj těchto dvou vedoucích o moc. Zároveň vzniká i určitá zvýšená náročnost rozhodování a komunikace – členové týmů k sobě mají dál, neţ v rámci oddělení. Současný model Výhody: Autonomie jednotlivých oddělení. Rychlost

všech

rozhodovacích

Rozšíření o maticovou strukturu Výhody: Vytváření, změny a rušení týmů velmi rychle bez zásahů do hlavní organizační struktury. procesů Větší know-how a rychlejší reakce na vzniklé

46

Současný model v oddělení. Přiřazení klíčových osob k zákazníkům, fungující komunikační kanály. Předávání si obchodních příleţitostí. Nevýhody: Špatná koordinace úkolů a projektů řešených napříč společností Niţší kvalita interně poskytovaných sluţeb, slabší motivace – priorita poskytovaná zakázkám pro zákazníky

Rozšíření o maticovou strukturu situace. Rozvoj schopností členů týmu.

Nevýhody: Distribuce pracovních kapacit. Konflikty liniových vedoucích a projektových vedoucích. Náročnější rozhodování a komunikace.

Tabulka 6: Shrnutí výhod a nevýhod současné a maticové organizační struktury

Z historické zkušenosti jsme se při řešení projektů napříč společností potýkali se dvěma typy problémů – buď byl projekt natolik nejednoznačně definován, ţe jej řešilo pouze jedno oddělení a vztah druhého oddělení byl natolik vágní, ţe selhávala podpora a získat spolupráci bylo obtíţné, nebo pokud jiţ byl projekt formálněji definován a vytvořena horizontální ad-hoc projektová struktura, projevily se všechny nevýhody uvedené výše tj. konflikty při přiřazování zdrojů, obtíţná komunikace, boj o moc. Situace není kritická, mnoţství takto realizovaných projektů není velké, nicméně i tak tento projekt přináší potenciál změnit a posunout dál tuto oblast fungování společnosti. Po diskusích managementu a pojmenování problému jsme se rozhodli zavést několik pravidel a opatření, která by měla umoţnit maticovou strukturu plnohodnotně zavést a úspěšně pouţívat: Formální vyhlašování projektů Projekty jsou formálně vyhlašovány, tj. k projektu je definován jeho obsah (scope), postupy, cíle, prostředky včetně poţadavků na lidské zdroje a součinnost jednotlivých členů projektu. Toto formální vyhlášení zajistí vedoucím projektů větší mandát při naplňování projektů. Vedení nebo dohled ze strany vedoucích oddělení Vedoucím projektu bude pokud moţno vedoucí oddělení, protoţe pak lze napřímit komunikaci napříč odděleními, případné problémy řešit s vedoucími jiných oddělení, tj. osobami na stejné úrovni atd. Samozřejmě i respektování osoby vedoucího oddělení ze strany všech členů týmu je vyšší neţ v případě kolegy na stejné pozici, avšak z jiného oddělení. V případě, ţe projekt je menší a je delegován

47

na pracovníka oddělení, musí si vedoucí oddělení ponechat nad projektem dohled. Do řešení problémů pak aktivně vstupuje. Reporting V rámci kaţdého projektu vznikají tzv. status reporty – průběţné zprávy monitorující aktuální stav projektu. Tento reporting obdrţí všichni vedoucí oddělení, jejichţ pracovníci jsou zapojeni do projektu. V případě, ţe se v reportech objevují body, které jsou označeny jako závaţné (např. nedodrţení termínu, neposkytnutí součinnosti, technické problémy, změnová řízení měnící koncept nebo náročnost atd.), jsou povinni se do projektu aktivně zapojit a situaci diskutovat s projektovým vedoucím. Velmi dobře dokumentuje různé organizační struktury samotný PMBOK v kapitole 2. Dle terminologie této dokumentace došlo ke změně z funkční organizace na vyváţenou maticovou strukturu (angl. Balanced Matrix Organization), přičemţ role vedoucích oddělení jsou na úrovni Sponsor a Stakeholders.

Obrázek 11: Functional Organization dle PMBOK [13]

48

Obrázek 12: Balanced Matrix Organization dle PMBOK [13]

4.4.6. Implementace MS Project Stejně zavedení procesů projektového řízení, i implementace MS Project neproběhla natolik komplexně jako v první etapě. Důvody jiţ byly naznačeny v přechozích kapitolách – bylo upuštěno od modelu vedení všech projektů na jednotné platformě, plánování a přiřazování zdrojů v MS Project. Software tak pouţíván k plánování a řízení projektů jako jednotlivých izolovaných celků bez vyuţití synergie porovnávání vytíţení zdrojů, analýz „what if“ atd. Při plánování projektu je tak ke všem úkolům (angl. tasks) přiřazována doba trvání úkolu (tj. jak dlouho bude dokončení úkolu trvat) a hodnota práce (tj. počet hodin nebo dní, které musí pracovník úkolu věnovat pro jeho dokončení). V rozdílu těchto časů pak vedoucí plánující projekt zohledňuje očekávané přiřazení zdroje, rezervu na jiné činnosti či prostě jen rezervu pro případ komplikovanějšího a delšího času na vyřízení. Tyto projektové plány jsou samozřejmě ukládány na projektový server a vykazování jiţ probíhá velmi shodně jako v oddělení vývoje software – je evidován čas strávený nad řešením konkrétního úkolu či procentuální hotovost řešení, časy nad rámec plánu atd.

4.4.7. Vliv na zákazníky Pozitivní efekty vlivu na zákazníky jsme se pokusili přenést i při implementaci projektového řízení v dalších odděleních. V zásadě lze říci, ţe vliv na zákazníky byl ve stejných oblastech jako u vývoje software, tedy: Zpřehlednění plánovací fáze 49

Efektivnější reporting Formalizovanější přístup Jeden bod byl však výrazně patrnější, a to i pro zákazníky výraznější oddělení projektové činnosti od operativy. Zatímco operativní záleţitosti (drobné poţadavky, havárie, incidenty, …) zákazníci hlásí přes webový helpdeskový systém, projekty mají naprosto odlišné schéma řešení. Díky tomu si zákazníci daleko více uvědomují přidanou hodnotu společnosti při projektové přípravě, znají a uvědomují si svoji roli v projektu (tzn. ţe musí aktivně spolupracovat a ne pouze zadat poţadavek a vše se jiţ provede bez jejich přičinění), zapojují se do projektových schůzek, aktivně spolupracují při předávání projektu. To výrazně posiluje pozici společnosti jako partnera při rozvoji IT a posouvá vnímání z pozice pouhé servisní organizace. V oblasti vývoje software je tato pozice lepší vzhledem ke struktuře projektů a postavení vývoje software v očích zákazníků obecně, v oblasti outsourcingu a správy byl toto zajímavý – a nutno říct – velmi příjemný a pozitivní efekt.

4.4.8. Hodnocení etapy Implementace v odděleních kabeláţí, praţské pobočce a plzeňském oddělení správy přinesla pozitivní efekt a další naplnění cílů, i kdyţ na druhou stranu rozsah implementace nenaplnil má očekávání a některé metody, procesy a nástroje bych osobně rád viděl v pokročilejší úrovni implementace. Za velmi důleţité povaţuji, ţe zavedení projektového řízení rozšířilo znalosti a schopnosti členů týmu, kteří se s metodikou seznámili, metodiku a obecně celý projekt přijali velmi vstřícně a vítají ji jako nástroj, který pomůţe především jim samotným lépe řídit a zvládat projekty. Nepřímo i tím, ţe zlepší fungování společnosti a jich samotných směrem k zákazníkům a jejich projektům. Pokud jsem se zmiňoval o nenaplněných představách o rozsahu implementace, je to moţná způsobeno porovnáním rozsahu implementace v mém vlastním oddělení vývoje software, kde naopak rozsah implementace a celkové integrace všech nástrojů a úrovně jejich pouţívání a dopadů na celkovou práci překonal původní představy. I druhou fázi implementace do dalších oddělení je třeba s odstupem času vnímat pozitivně, implementace znamenala jednoznačný posun. A moţná lépe menší posun neţ se zarputile snaţit o příliš výrazný zásah, který by ve svém důsledku mohl přinést nečekaná negativa, zbytečné komplikace a např. vyústit aţ v odpor všech zainteresovaných. V dalších fázích lze postupně rozsah rozšiřovat tak, jak ukáţe praxe a jaké potřeby vyjdou z kaţdodenního pouţití. Realizovat změny iniciované samotnými uţivateli je daleko snazší a vhodnější. 50

4.5.

Reálné pouţívání metodiky

4.5.1. Zavedení project Management Office V souvislosti s projektovým řízením se poměrně často objevuje pojem projektová kancelář (angl. Project Management Office nebo PMO). Jedná se o určitou entitu v rámci společnosti, jejímţ cílem je podpora projektů, projektových manaţerů a projektového řízení jako takového. Konkrétní podoba vţdy závisí na potřebách organizace. PMO můţe být zcela virtuální, aţ po vlastní oddělení s personálem přiřazeným PMO v případě velkých projektově orientovaných organizacích. Hlavními funkcemi projektové kanceláře jsou: Správa a řízení sdílených zdrojů napříč projekty Zajištění a rozvoj metodiky projektového řízení, best practices a standardů Koučing, tréning a dohled, řízení shody projektů s metodikou Správa, údrţba a rozvoj projektových politik, procedur, postupů, šablon a další sdílené dokumentace Koordinace komunikace napříč projekty a projektovým portfoliem Z popisu PMO je patrné, ţe velmi neformální projektová kancelář vznikla víceméně automaticky i v naší organizaci. Jedním z jejích primárních úkolů bylo zajištění a podpora samotného projektu nasazení projektového řízení, především v bodech týkajících se přípravy metodiky, politik, procedur, šablon, best practices a firemních standardů. Nicméně PMO zajišťuje i koordinaci všech projektů napříč – v případě oddělení vývoje software je to celá správa portfolia projektů, přiřazování s právy zdrojů napříč projekty atd., v případě projektů napříč odděleními pak zajišťuje veškeré vazby a podporu těchto projektů.

4.5.2. Plné pouţití projektového řízení Ve třetí etapě probíhalo jiţ plné vyuţívání metodiky všemi odděleními, znalost všech zainteresovaných pracovníků byla na dostatečné úrovni, veškeré dokumenty a šablony byly vytvořeny a k dispozici a všechny procesy a procedury související s projektem byly, alespoň po teoretické stránce nastaveny. Právě třetí etapa měla za úkol za zvýšeného dohledu nad pouţíváním a za intenzivní komunikace s jednotlivými týmy a manaţery zajistit co nejlepší reálné nasazení, převedení všech principů do praxe, otupení případných hran a nesrovnalostí. Samozřejmě bylo nutné řešit mnoho situací. Identifikaci a vyplynutí problematických bodů na světlo je třeba brát 51

velmi– jejich vyřešení pomáhá projekt zkvalitnit. Pokud by se neobjevovaly, znamenalo by to, ţe implementace byla naprosto dokonalá a bezchybná (a to není nic a nikdy) nebo ţe problémy nebyly identifikovány. Ze seznamu řešených bodů vybírám jen ty nejdůleţitější: Formální vyhlašování projektů, definice rolí, hodnocení členů týmů Změnou, na kterou bylo nutné si ze strany všech členů týmů zvykat, bylo formálnější vyhlašování projektů a pořádání tzv. kick-off meetingů – schůzek, které zahajují projekt. Obsahem těchto schůzek je kromě řešení obsahu projektu i nastavení projektových rolí, komunikačních pravidel, způsobu reportingu, intervalů pro schůzky atd. Pro projektové vedoucí bylo poměrně komplikované pracovat s novou strukturou týmu, která můţe být naprosto odlišná od organizační hierarchie firmy. Nadřízený projektového vedoucího tak můţe zastávat pozici člena týmu (zdroj), se svými povinnostmi a úkoly, coţ je pro některé projektové vedoucí z počátku špatně uchopitelné a omezuje je ve fungování vůči přímému či nepřímému nadřízenému jako členovi jejich týmu. Aby byl dostatečně podpořen mandát projektových vedoucích, jsou projektové role definovány formálně a veřejně, rozděleny úkoly a povinnosti. Jako nástroj zpětné vazby pak byl dodatečně zaveden mechanismus hodnocení jednotlivých členů týmů jako součást hodnocení projektu (samozřejmě pro projekty odpovídající velikosti). V hodnocení se pak objevují kritéria invence (přínosů a aktivity), plnění termínů, kvality plnění úkolů atd. Pomocí tohoto hodnocení je moţné předávat zpětnou např. nadřízenému nebo kolegovi z jiného oddělení. Replikace dokumentace a projektových plánů Jak narůstal objem projektů řešených více dle metodiky a za pomoci připravených nástrojů, nepříjemně se zvyšoval podíl dokumentace, která byla velmi podobná a vlastně vycházela jiţ z realizovaných projektů. Kopírování informací probíhalo v projektových záměrech, struktuře nebo i jednotlivých bodech plánů (úkoly), analýzách rizik, rozdělení rolí atd. Pokud by šlo o vyuţívání toho nejlepšího z předchozích projektů, nejednalo by se o problém, nicméně toto kopírování bylo způsobeno spíše nedostatkem invence nebo prostě jenom určitou leností vytvářet a vymýšlet něco nového. Negativním vlivem však bylo, ţe při takovém kopírování byly podstatné části projektů opomenuty, analýzy rizik neřešily specifické body, nebyla hledána řešení vhodná pro projekt – byl popřen základní princip projektů, a to jejich jedinečnost a potřeba individuálního přístupu. 52

Jako řešení situace byl trochu upraven proces přípravy a schvalování větších projektů, kde tento problém hrozil největšími škodami. U projektů je tak uváděn seznam podobných projektů (zdrojů informací), které jsou vyuţity při přípravě jakýchkoli dokumentů. Znovupouţité části jsou označovány (nejčastěji barevně) a tým je pak schopen rozlišit (a v podstatě i kontrolovat), které části plánů, konceptů, designu, analýz vznikly individuálně a které jsou přejaty. V tomto kontextu pak všichni nad projektem mohou přemýšlet (tedy i sponzor nebo gestor), zda unikátní části obsáhly vše potřebné, zda řeší všechny specifické otázky atd. Navíc se lze na dokumentaci dívat i z druhého pohledu a poloţit si otázku, zda lze ze zdrojových projektů vyuţít něco dalšího. Projektová schémata Velmi často jsme naráţeli na diskuse, jaké dokumenty a v jakém rozsahu by měly být optimálním výstupem procesů řízení, aby byl rozsah dokumentace odpovídající situaci a potřebám. Bohuţel pohled na optimální rozsah je velmi individuální a bylo potřeba nastavit určitý standard. Na vzorových či spíše reprezentativních projektech různého rozsahu jsme vydefinovali vhodný rozsah dokumentace – aţ uţ z pohledu jednotlivých dokumentů, které mají být a budou vytvořeny, tak i z pohledu rozsahu jejich struktury a podrobnosti. Vznikla tak 3 schémata rozsahu vytvářené dokumentace. Důleţité je upozornit na to, ţe tato schémata nejsou šablony, jaké dokumenty mají vzniknout, pouze definují určitý rámec rozsahu, který je v závislosti na předpokládané náročnosti a komplikovanosti projektu na začátku určen, avšak – a to je důleţité – společně s poţadavky dalších dílčích specifik a úrovně podrobnosti. Řízení rozsahu, change management, risk management Change management (změnová řízení) jsou oblastí, jejíţ špatné zvládnutí můţe způsobit krach i velmi dobře vedeného a naplánovaného projektu nebo vede ke zvýšení nákladů, zpoţdění projektu atd. Navíc změny projektu realizované v pozdějších fázích představují pro projekt výraznější komplikace neţ změny realizované na začátku. Change management obsahuje techniky, které přicházejí na řadu v okamţiku, kdy vyvstává poţadavek na změnu nebo je identifikován, nicméně snahou projektového týmu by mělo být počet takových incidentů elimininovat – nikoli tím, ţe je budou tým resp. PM odmítat, ale správným plánováním projektů, předprojektovou přípravou, specifikací project scope i jednotlivých detailů. Kvalitní přípravou je moţné ovlivnit i mnoho změn, které 53

pocházejí jakoby „ad hoc“ od zákazníka. Pak se tým díky řízení rozsahu vyhne i případným konfliktům, kdy sice poţadavek přichází od zákazníka, nicméně ten jej poţaduje začlenit do původního projektu s tím, ţe danou věc mohl řešitel předpokládat. V rámci udrţení vztahů pak nezbývá, neţ toto přijmou nebo hledat kompromisní řešení. Ve finále to však vţdy znamená komplikaci projektu a navyšování náročnosti. Vliv investora, rizika a nejistota

úroveň

vysoká

nízká

Náklady na změnu čas projektu

Obrázek 13: Vliv změn a náklady na ně v průběhu projektu podle PMBOK

Ve fázi, kdy projekty byly realizovány dle metodiky, jsme se tedy velmi podrobně zaměřili na techniky, které by pomohly tuto problematickou oblast zlepšit, coţ ve finále zajistí vylepšení ekonomiky projektů. Úroveň analýz a specifikací je oblast, kterou neřeší metodika řízení projektu, jejich zlepšování je otázkou jiných nástrojů a technik, např. v softwarovém inţenýrství je toto velmi hluboce řešená a diskutovaná otázka, ovšem stojící mimo rozsah této práce a v podstatě i projektu. Dle mého názoru lze úspěšně pouţít nástroje a procesy metodiky v otázkách analýzy rizik, formalizace projektu a řízení změn a rozsahu v kontextu k definovanému project scope. Při analýze rizik je třeba zahrnout rizika moţných změn a variant a ty v rámci analýzy a specifikace popsat. Tím dojde k určitému omezení mnoţiny změn, nebo pokud se objeví změna resp. poţadavek na změnu z jiţ definované mnoţiny, je jiţ dopad změny popsán nebo alespoň částečně zachycen důsledek. Díky zvýšené formalizaci komunikace se zákazníkem resp. vlastníkem projektu, je jiţ projektový tým při změně rozsahu v určité výhodě, 54

protoţe daná změna resp. poţadavek byly zachyceny v analýze, specifikaci či analýze rizik a v rámci formalizovaného odsouhlasení rozsahu nebyl daný poţadavek zahrnut. V případě nutnosti začlenit nějaký poţadavek do projektu nebo realizovat změnu jiţ nastupuje Change Management. Na jeho zvládnutí, zkušenostech týmu a samotného PM je závislá náročnost a ve svém důsledku cena realizace takové změny, její dopady na další části projektu, časovost, návaznost dalších akcí a v podstatě všechny prvky, které s projektovým managementem a ţivotním cyklem projektu souvisí. V této rovině jsme se zaměřili na hlubší řešení tématu, jeho podrobnější diskuse nad reálnými situacemi a příklady. Revize plánů, administrace kapacit a správa portfolia I sebelépe naplánovaný a připravený projekt neběţí stoprocentně podle plánu, vţdy jsou nutné větší či menší zásahy, korekce, zahrnutí změn, vnějších vstupů atd. Nicméně plán je vzor, kterému by se měl průběh projektu přibliţovat, se kterým je porovnáván a podle kterého je řízen. V okamţiku, kdy dojde k odchylce od plánu, musí být tato odchylka zachycena a plán dalších kroků adekvátně upraven – vzniká revidovaný plán na základě jiţ proběhnutých událostí. Pokud by k tomuto řízení nedocházelo, projekt by rázem přestal být řízen. Abychom tedy zajistili neustálou aktuálnost v bodech nutných pro řízení projektu, musely být naprosto funkční procesy aktualizace projektových plánů. Vzhledem k tomu, ţe většinu projektových činností provádějí interní pracovníci1, je jedním ze stěţejních bodů řízení jejich kapacity revize projektových plánů v kontextu k aktuálním potřebám a dostupnosti těchto zdrojů. Nad celým tímto mechanismem pak stojí správa celého projektového portfolia, tj. vykrývání jednotlivých kapacit, prioritizace úkolů napříč projekty, sledování plnění a predikce kapacit v čase atd. V tomto ohledu povaţuji za vynikající nástroj MS Project, ovšem za předpokladu, ţe je efektivně vyuţíván a aktualizován správnými daty. Vyhodnocovat je tak nutná všechna zpoţdění nebo práce trvající déle, neţ bylo plánováno, s dostatečným předstihem plánovat všechny výpadky lidských zdrojů (dovolené, vzdělávání, …) a samozřejmě pracovat i s určitými rezervami například na zvýšenou podporu při spouštění projektů. Bohuţel vţdy mohou přijít neočekávané události, jako nemoc, urgentní poţadavky, nejrůznější incidenty. V takovém případě je opět nutné projít a případně revidovat plány na základě odhadu náročnosti řešení, výpadku atd. 1

Pro účely projektů mezi interní pracovníky pracující na základě smlouvy, ať uţ zaměstnanecké nebo o provedení práce,

55

V průběhu projektu jsme se snaţili zajistit, aby všichni pracovníci získali jakýsi cit pro identifikaci těchto situací a byli schopni je společně analyzovat a přijímat odpovídající řešení. Právě rychlost a včasnost opatření je velmi důleţitá pro efektivitu dalšího postupu. Ukončování projektů a vyhodnocování projektů Před zavedením projektového řízení a metodiky nebylo ukončování projektů prováděno dobře a byl v této ţivotní fázi projektu velký prostor pro zlepšení. Na rozdíl od zahajování projektů, které fungovalo podle určitých pravidel a schémat, bylo ukončování projektů pro všechny zainteresované velmi špatně uchopitelné. Sice většinou existuje podle smlouvy milník, kdy je projekt předán, tj. je podepsán předávací protokol, ale uţ jen dokončit všechny části projektu tak, aby splňovaly parametry pro předání, oddělit od sebe fázi projektu nebo jeho dolaďování a fázi, kdy vstupuje projekt do běţného provozu a servisní podpory, bylo velmi problematické. Někdy je tato situace způsobena i zákazníky, jejichţ snahou (a někdy bohuţel i nekompetentností) jsou na poslední chvíli do projektu zanášeny změny, poţadavky, není dostatečně zajištěna spolupráce při uvádění do provozu (a námi nedostatečně vyţadována), takţe v celkovém důsledku se celé ukončení a předání projektu rozmělní natolik, ţe je pak velmi ztíţen přechod do běţného provozu. S tím pak mohou souviset i servisní smlouvy a v krajním případě finanční ztráty způsobené odloţeným inkasem plateb za projekt a servis. Ukončovacím procesům jsme tedy, stejně jako dalším výše jmenovaným oblastem, věnovali zvýšenou pozornost při zavádění metodiky a navazování procesů metodiky na další interní procesy a potřeby. Z výše jmenovaných problémů jsou některé body jiţ částečně řešeny – především řízení rozsahu a změn ke konci projektu, jiné spadají čistě do ukončovacích procesů. V rámci kaţdého projektu je tedy nutné precizně definovat hranici a parametry, které musí projekt vykazovat, aby bylo moţné jej povaţovat za dokončený. Díky tomu je pak moţné směřovat aktivitu a řídící procesy k dokončení a naplnění těchto parametrů – přeneseně můţeme mluvit o tahu na branku. Ale jen za předpokladu, ţe víme, kde branka je. Jedna část je teorie, druhá pak praktické provedení, kde je často nutné projevit velké nasazení a odhodlání vše potřebné dotáhnout. Na konci větších projektů se můţe projevovat i určitá únava týmu, která navíc kontrastuje s nadšením pro nový projekt, který je výzvou. Ze strany managementu je tak nutné toto monitorovat a zajistit úspěšné dokončení. S ukončením projektu 56

souvisí i jeho hodnocení, které provádí jak PM, tak se v dílčích otázkách vyjadřují i členové týmu. Hodnocení projektu má ještě jeden velmi důleţitý efekt – je motivačním faktorem pro všechny zúčastněné, v rámci něho probíhá závěrečné hodnocení členů týmu, jejich přínosů, nasazení, kvality a včasnosti odváděné práce a je podkladem pro výplatu projektových bonusů.

4.5.3. Udrţitelnost projektu Na závěr projektu bylo nutné nastavit pravidla pouţívání metodiky a její údrţby tak, aby byl projekt a jím dosaţené hodnoty udrţitelné do budoucna a nedocházelo k postupné degradaci pouţívání zavedených nástrojů a metod, zmenšování rozsahu uţívaných procesů a výstupů atd. Do této koncepce bylo nutné zahrnout i pravidla zaškolení nových zaměstnanců a projektových vedoucích a jejich osvojení si jak firemní kultury a principů práce, tak i principů pouţití specifické implementace metodiky a její návaznosti na všechny další procesy z oddělení, kde budou realizovat své projekty. Plán školení ve své podstatě vyšel z principů zaškolení pracovníků při zavádění metodiky a zapojení kolegů, kteří jiţ projekty realizují dle zavedených principů. Aby však nedocházelo k předání jenom části know-how, byla zpracována dokumentace, zachycující nutný rozsah, specifika, vazby na interní nástroje (dokumenty a šablony, MS Project, SharePoint, …), která slouţí jako studijní materiál (samozřejmě společně s PMBOK) a také jako kostra pro pořádání těchto školení a workshopů. Pro obnovování a rozšiřování znalostí, tj. zabránění deformací v pouţití metodiky, je zpracován koncept práce s jiţ proškolenými pracovníky. Počítá s určitými pravidelnými workshopy, při nichţ na základě zpětné vazby z projektů – aţ uţ samotných pracovníků, hodnotících zpráv projektů nebo názoru managementu – budou opakována a prohlubována opomíjená nebo problematická témata, analyzovány jednotlivé situace nebo projekty, společně hledány nové postupy nebo způsoby řešení. Tato dokumentace by tak měla být neustále ţivá a na základě těchto workshopů naopak rozšiřována nebo upravována, aby odpovídala i posunu v práci firmy, nabízeným sluţbám, změnám struktury nebo situaci na trhu. V budoucnu uvidíme, jak bude tato koncepce naplněna, a podle aktuální situace bude případně upravena.

57

5. Vyhodnocení projektu 5.1.

Cíle projektu a jejich naplnění

Dovolím si stručně zopakovat stanovené projektové cíle, i kdyţ definované obecně. Zavedení projektového řízení, zavedení metodiky projektového řízení a její navázání na současné procesy, metody a metodiky Nastavení rolí jednotlivých pracovníků a jimi odpovídající zvládnutí metodiky pro jejich role v projektech Realizace organizačních změn podporujících projektové řízení organizace a týmů Implementace silného softwarového nástroje pro podporu projektového řízení Nastavení jasného a přehledného systému sledování a reportingu projektů pro všechny úrovně řízení Věřím, ţe z předchozího textu je patrné, ţe tyto cíle byly naplněny. Vzhledem k obecné definici a neměřitelnosti těchto cílů je nutné podívat se na projekt i z pohledu zavedených měřitelných ukazatelů a srovnání projektů realizovaných před zavedením projektového řízení s vyuţitím metodiky PMI s projekty realizovanými v průběhu a po dokončení implementace. Definovaná kritéria byla: Profitabilita (%) Mnoţství změn projektu (%) Spokojenost zákazníka (1-10) Dodrţení termínu (%) Dodrţení pracnosti (%) Naplnění zadání (%) Opětovná pouţitelnost řešení (%) Úspěšnost projektu (1-10) Srovnání projektů před zavedením projektového řízení a po něm není úplně jednoduché. Kaţdý projekt je specifický, takţe výsledné hodnoty hodnocení projektů nejsou ovlivněny jen pozitivními efekty zavedení projektového řízení, ale mnoha dalšími okolnostmi. Z porovnávané mnoţiny jsme vyloučili projekty, které se svým rozsahem nebo vlastnostmi výrazně vymykaly, jednotlivé hodnoty jsme pak průměrovaly. Následující tabulka zobrazuje srovnání obou mnoţin.

58

Před zavedením

Po zavedení

projektového řízení

projektového řízení

Počet projektů ve srovnání

15

8

Profitabilita (%)

nelze publikovat v této práci

Mnoţství změn projektu (%)

23%

11%

Spokojenost zákazníka (1-10)

6

7,5

Dodrţení termínu (%)

125%

106%

Dodrţení pracnosti (%)

132%

108%

Naplnění zadání (%)

96%

98%

Opětovná pouţitelnost řešení (%)

35%

52%

Úspěšnost projektu (1-10)

6,4

8,2

Tabulka 7: Srovnání sledovaných ukazatelů před a po zavedení projektového řízení

Pro účely této práci bohuţel nelze publikovat hodnotu profitability jednotlivých projektů, protoţe se jedná o velmi citlivý údaj, který je předmětem obchodního tajemství společnosti. Nicméně mohu konstatovat, ţe profitabilita lehce narostla, coţ si vysvětlujeme spíše jako sekundární efekt vyšší efektivity řešení projektů a sníţení celkové pracnosti. Samozřejmě se negativně projevují i trendy určitého útlumu poptávky a vyšší nasycenosti trhu v době po finanční krizi. Ve své podstatě se tak díky projektu podařilo sníţit ceny srovnatelných projektů díky niţší pracnosti a zvýšit tak konkurenceschopnosti i při zachování profitability. Subjektivní kritéria spokojenost zákazníků a úspěšnost projektu jsou po ukončení projektu u vybraných řešení hodnocena výrazně pozitivněji, otázkou však je vliv nadšení z přínosů projektu, které toto hodnocení můţe lehce deformovat a posouvat výše. Naopak neoddiskutovatelně lepší jsou hodnoty týkající se dodrţení termínů. Zde se právě promítá výše zmíněná efektivita mající vliv i na profitabilitu. Schopnost naplnění zadání byla i před projektem na vysoké úrovni, bohuţel za cenu právě zvýšení pracnosti a prodluţování termínů realizace a vysokého počtu změn v projektech. Vysoký nárůst vykazuje hodnota opětovné pouţitelnosti řešení. Do budoucna bude se zvyšujícím se počtem projektů přinášet další efektivitu. Je ovšem potřeba uvědomit si, ţe i kdyţ jsou některá řešení hodnocena jako znovupouţitelná, jsou natolik unikátní, ţe je velmi malá pravděpodobnost jejich další aplikace ve stejné podobě. I tak je však znuvupouţitelnost řešení a jejich dokumentace umoţňující jejich další vyuţití velmi pozitivní a lze z ní těţit.

59

5.2.

Problematické body a výzvy do budoucna

Od ukončení projektu uběhlo několik měsíců, lze tedy bilancovat a hodnotit projekt i z pohledu negativ a bodů, kde spatřuji rezervy. Odhalit negativa nebo slabá místa je vţdy náročnější, obecně však povaţuji za důleţité znát a pídit se po místech, kde je moţné něco zlepšit, místech, kde nebylo něco správně, anebo zda byly některé části projektu vnímány negativně jakýmkoli účastníkem. Teprve potom je moţné přijmou opatření, pokoušet se o nápravu, a pokud náprava není moţná, s daným negativem pracovat a udělat vše pro minimalizaci jeho vlivu. Rád bych otevřel několik bodů, které osobně a po konzultaci s kolegy vnímám jako problémy projektu nebo pouţití implementované metodiky. Na závěr seznamu naopak uvádím oblasti, které jsou výzvou do budoucna a hodnotíme je jako otevřené. Jazyková bariéra Moţná trochu překvapivě na prvním místě uvedu jazykovou bariéru. PMBOK je k dispozici v angličtině a několika dalších západoevropských jazycích. Pro anglicky mluvící spolupracovníky toto nebyl problém, naopak někdy jsou anglické pojmy a vysvětlení jasnější a přímočařejší. V případě jazykové bariéry však nastává nemalý problém – překládat dokument nelze a tlumočit a vysvětlovat kaţdou jednotlivou část dokumentu v češtině není moţné. Proto byli kolegové s horší znalostí angličtiny omezeni v samostudiu nebo práci s dokumentem. V rámci workshopů bylo nutné ke kaţdé části přistupovat daleko obšírnější a detailněji a prezentovat alespoň stručný výtah. Bohuţel toto má negativní vliv i pro budoucí pouţití metodiky – při znalosti struktury a obsahu dokumentu PMBOK je velmi vhodné se čas od času k dokumentu vrátit. Na druhou stranu je nutné říct, ţe všichni projektoví vedoucí mají alespoň částečnou znalost angličtiny a studium dokumentu pro ně bylo motivací pro další rozvoj jazykových znalostí v případě, ţe běţně angličtinu nepouţívají. Oblasti ke zlepšení Stejně jako se domníváme, ţe některé části a procesy byly implementovány velmi dobře, zbývají stále procesy či procesní skupiny, které si i do budoucna zaslouţí naši pozornost. Jsou to ukončovací (closing) procesy, change management a řízení rozsahu projektu. Byrokracie

60

V souvislosti se zavedením systému dokumentace projektů, jejich plánováním a monitoringem samozřejmě vzrostl objem dokumentů, které pro projekt vznikají a je nutné je udrţovat. Z počátku projektu byl tento nárůst dokumentace vnímán negativně, a to ze strany pracovníků zapojených do projektu. Snaţili jsme se proto tvorbu dokumentů zjednodušit, a to formou dokumentových šablon, schémat pouţité dokumentace, pouţitelností dokumentů napříč projekty. Ve finále jsme se dostali do zajímavé situace – dokumentace je vytvářeno víc, její tvorbě je věnováno i více času, nicméně tvorba dokumentů je výrazně jednodušší tzn. nikdo nepřemýšlí, co v kterém dokumentu musí a nemusí být, jak popsat či zmapovat ten který poţadavek nebo situaci atd. S postupem projektu navíc projektový tým poznal uţitečnost a pouţitelnost dokumentace ve vztahu ke všem situacím a ve své podstatě tak ve srovnání s předchozím způsobem a úrovní tvorby dokumentace všichni oceňují vyšší uţitečnost tvořené dokumentace. To se týká především dokumentů vztahujících se k zadání projektu, monitoringu stavu a řízení projektu, předávání a finalizaci. Jednotlivé dokumenty, které jsou součástí samotného řešení projektu nebo vývoje, tedy např. analýzy a specifikace byly jiţ předtím na dobré úrovni a svoji podobu a úroveň tedy příliš nezměnily, spíše byla prohloubena jejich vazba na ostatní projektovou dokumentaci. Rozsah implementace v jednotlivých odděleních Jak uţ jsem zmínil v předchozích kapitolách, v oddělení vývoje software proběhla implementace výrazně v rozsáhlejší podobě, v ostatních odděleních pak některá nástroje a techniky zůstaly mimo předmět zájmu. Tyto dva způsoby jsou moţná ještě ve větším kontrastu, protoţe implementace v oddělení software byla opravdu komplexní, minimálně v otázkách správy portfolia projektů, plánování zdrojů napříč projekty, pravidelného hlášení a revize odvedené práce atd. Musím přiznat, ţe v této oblasti jsem byl aţ překvapen, do jaké úrovně se podařilo projekt dotáhnout, z velké části díky moţnostem MS Project. Právě v kontrastu k tomu není integrace do dalších oddělení tak hluboká. Vše však je motivováno logickými důvody a aţ čas ukáţe, zda je úroveň správná nebo je potenciál pro další rozšíření. Určitě je vhodnější v tomto případě postupovat po menších krocích neţ napáchat nezvratné chyby. Náročnost správy portfolia Správa portfolia projektů, jak jsem ji popisoval, není jednoduchá. Vyţaduje o všech týmů velkou kázeň při evidenci a zadávání všech údajů o aktuálním stavu úkolů, 61

pravidelný monitoring dat a rozhodování o dalším postupu, případné koordinační schůzky a revize plánů, operativní přesuny kapacit, plánování událostí, které dříve nebyly brány v potaz atp. Nicméně domnívám se, ţe i přes všechny negativa a náročnost přináší tento proces výrazné výsledky, navýšení kvality a efektivity, systematičtější řešení všech projektů, úkolů a poţadavků. A v důsledku méně stresů a větší klid na práci, kontinuálnější činnost bez zbytečných přesunů zdrojů mezi úkoly a zodpovědnější přidělování zdrojů i na základě schopností pracovníků k řešení jednotlivých úkolů. I tak tato agenda stále představuje nemalou zátěţ všech pracovníků. Použití poradenského subjektu Otázka vyuţití sluţeb poradenského subjektu jiţ byla diskutována v kapitole přípravy projektu. Řešení projektu vlastními silami přineslo výsledky, domnívám se, ţe uspokojivé. Pouţití poradenského subjektu mohlo do projektu přinést zkušenost z dalších implementací, mohlo ušetřit čas a v důsledku i prostředky. Jak to ale v projektech bývá, důsledky alternativní varianty se nedozvíme, pokud není varianta realizována. Vhodné by nyní bylo zaměřit se na oblasti, které zde byly jmenovány jako problematické, kde je zřejmě rezerva k dalšímu posunu a vylepšení. Do budoucna by tak mohlo být zajímavé konfrontovat aktuální stav se zkušenostmi poradenského subjektu, spustit jakousi další etapu, v níţ by byl realizován rozvoj současné implementace na základě vnějšího posouzení stavu a na základě doporučení. Pak bychom i ještě přesněji zjistili, jak velký prostor pro další rozšiřování současný projekt nevyuţil. Certifikace osob Vzhledem k tomu, ţe všichni projektoví vedoucí se podrobně seznámili s metodikou PMI, nastudovali, byť i s částečnou jazykovou bariérou, PMBOK a především aktivně pouţívají metodiku pro projektové řízení, rozumí ji a chápou všechny důleţité vazby a procesy projektového řízení, bylo by velmi vhodné podpořit tuto jejich znalost odpovídající certifikací. Ta by byla zajímavá jak osobně pro pracovníky (zvýšení know-how a vylepšení CV), tak i pro společnost jako způsob prokázání kvality řešení a řízení projektů. Jako sekundární efekt lze vnímat i pozitivní dopad na marketingové a propagační vyuţití. CMMI-SW 62

CMMI-SW nabízí také moţnost certifikace, zajímavější mi však připadá moţnost podrobněji nastudovat model a jednotlivé jeho úrovně, stanovit cíle dle metodiky a dotáhnout všechny procesy a sledované vlastnosti do úrovně jasného splnění kvalitativní úrovně bodu 3 podle modelu. Takový projekt by mohl posunout kvalitu procesu vývoje software a pomohl určitým způsobem vyváţit kvalitu jednotlivých činností a procesů na podobnou úroveň. Měl by tedy zachytit ty, které nejsou na odpovídající úrovni v kontextu ke kvalitě ostatních.

63

Závěr Po dokončené implementaci projektového řízení jsem velmi rád, ţe jsme projekt realizovali a ţe jsem mohl stát u jeho zrodu i jej vést. Výsledky projektu jsou velmi dobré, domnívám se, ţe posunuly naši společnost výrazně kupředu a pomohly nastartovat a iniciovat i další dílčí změny, které mohou na projekt do budoucna navázat. Za projekt jsem rád i z osobního hlediska, mohl jsem v něm zúročit svoje znalosti projektového řízení a metodik, včetně znalostí a dovedností získaných studiem na BIVŠ, a díky celému postupu projektu a všem činnostem v rámci projektu je i rozšířit. Realizovaná implementace je výrazně hodnotnější zkušeností neţ pouhé nastudování několikaset stránkové dokumentace. V projektu se podařilo dosáhnout i vyšší integrace činností oddělení ve společnosti, zavést maticovou organizační strukturu, která se dynamicky mění s novými projekty. Věřím, ţe projekt byl přínosný i pro všechny mé kolegy, jimţ jsem mohl předat část svých znalostí a pomoci jim do budoucna zlepšit jejich vlastní projekty. I přesto, ţe jsem projekt navrhl, plánoval, řídil a částečně jsem se stal i školitelem, patří úspěch projektu ve značné míře i jim. Jak se v projektu ukázalo, implementace a znalost projektového řízení není dobrá jen pro vedoucí pracovníky a vedoucí projektů, ale všechny pracovníky do projektů zapojené, protoţe pak mohou tento rozhled vyuţít k efektivnějšímu fungování uvnitř týmu. Implementací ţádného projektu nic nekončí, ale právě začíná. V případě implementace projektového řízení to platí dvojnásob. Kaţdý projekt otevírá nové otázky, nové moţnosti, a bohuţel, i nové problémy. Důleţité je teď pro naši společnost výsledky projektu zuţitkovat, udrţet a případně rozvíjet, v ţádném případě však nedopustit vyčpění a postupné degradování na úroveň obyčejného pracovního postupu.

64

Seznam pouţité literatury 1. DĚDINA, J., MALÝ M.: Organizační architektura. Victoria Publishing, Praha 1996. 2. DĚDINA, J.: Podnikové organizační struktury. Victoria Publishing, Praha 1996. 3. GILB, T. Principles of Software Project Mangement. Addison-Wesley, 1988 4. ILX GROUP PLC, Webové stránky Prince 2, [cit. 2011-06-02], Dostupný z WWW: http://www.prince2.com/what-is-prince2.asp 5. INTERNATIONAL PROJECT MANAGEMENT ASSOCIATION. ICB – IPMA Competence Baseline, Version 3.0. Nizozemí, 2006. ISBN 0-9553213-0-1 6. IT Governance Ltd., Webové stránky Prince 2, [cit. 2011-06-02], Dostupný z WWW: http://www.itgovernance.co.uk/prince2.aspx 7. KLUSOŇ, Martin: PRINCE2 nebo PMI. IT Systems, Vydává: CCB spol. s r.o., roč. 2010, č. 3. 8. KRŮTA, Jiří: Metodika řízení projektů střední velikosti, Bakalářská práce, BIVŠ, 2009. 9. LACKO, Branislav, Doc. Ing., CSc., Zásady moderního projektového řízení, [cit. 2011-05-31], Dostupný z WWW: http://lacko.otw.cz/eseje/Co_je_projektoverizeni.doc.pdf 10. MAULE, Pavel. Porovnání PRINCE2 a PMBOK. Systémová integrace. Vydává: Česká společnost pro systémovou integraci, roč. 2004, č. 4. 11. MAULE, Pavel. Project Management body of knowledge. Systémová integrace. Vydává: Česká společnost pro systémovou integraci, roč. 2004, č. 3. 12. MÜLLER, Václav Ing. a kol. Projektové řízení (standard ČR dle IPMA). 2. vyd. Praha, Společnost pro projektové řízení, 2005. 13. PROJECT MANAGEMENT INSITUTE. Project Management body of knowledge, 4rd edition. USA, 2008.

65

Seznam obrázků Obrázek 1: Vazba jednotlivých činností projektu (nebo fáze) dle PMBOK ....................... 10 Obrázek 2: Aktivita jednotlivých skupin procesů v čase .................................................... 11 Obrázek 3: Vazba jednotlivých činností projektu dle PRINCE2 ........................................ 13 Obrázek 4: Procesní model PRINCE2 v čase...................................................................... 14 Obrázek 5: Struktura PRINCE2 a její komponenty ............................................................ 15 Obrázek 6: Schéma struktury rolí společnosti ..................................................................... 20 Obrázek 7: Schéma implementace napříč společností v kontextu k etapám projektu......... 26 Obrázek 8: Harmonogram projektu ..................................................................................... 28 Obrázek 10: Schéma struktury rolí organizace společnosti s vyznačením rolí v projektu .. 30 Obrázek 11: Schéma maticové (projektové) organizační struktury .................................... 45 Obrázek 12: Functional Organization dle PMBOK [12] ..................................................... 48 Obrázek 13: Balanced Matrix Organization dle PMBOK [12] ........................................... 49 Obrázek 14: Vliv změn a náklady na ně v průběhu projektu podle PMBOK ..................... 54

66

Seznam tabulek Tabulka 1: Přehled vlastností metodik PRINCE2 a PMI .................................................... 16 Tabulka 2: Srovnání pozitiv a negativ metodik PRINCE2 a PMI....................................... 17 Tabulka 2: Kritéria pro hodnocení projektů ........................................................................ 23 Tabulka 3: SWOT analýza .................................................................................................. 24 Tabulka 4: Analýza rizik ..................................................................................................... 25 Tabulka 5: Shrnutí výhod a nevýhod současné a maticové organizační struktury.............. 47 Tabulka 6: Srovnání sledovaných ukazatelů před a po zavedení projektového řízení ........ 59

67