Alokace a řízení zdrojů napříč projekty IT společností

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Alokace a řízení zdrojů napříč projekty IT společností DIPLOMOVÁ PRÁCE

PAVEL KRKOŠKA BRNO, 2011

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Poděkování Děkuji tímto svému vedoucímu diplomové práce panu RNDr. Jaroslavu Ráčkovi, Ph.D. za odbornou pomoc a cenné rady při vzniku této práce. Dále děkuji Stanislavu Filipčíkovi za finální revizi textu.

Shrnutí Tato práce je zaměřena na problematiku sdílení lidských zdrojů v projektově orientovaných IT společnostech. Práce čtenáře seznamuje s rozdíly mezi řízením lidských zdrojů (HRM) v tradičních společnostech a společnostech zaměřených na projektové řízení, u nichž identifikuje některé dodatečné požadavky na HRM procesy. Upozorňuje také na tzv. syndrom alokace zdrojů jako na jeden z hlavních problémů řízení násobných projektů. Součástí práce je případová studie výše zmíněného problému v prostředí konkrétní společnosti, jejímž výstupem je kompletní projektová dokumentace k nástroji pro efektivní řízení lidských zdrojů napříč projekty.

Klíčová slova HRM, alokace, lidské zdroje, projekt, projektové řízení, PM, portfolio, analýza, návrh, nástroj

Obsah 1

Úvod ...................................................................................................................................... 2

2

Řízení lidských zdrojů v kontextu projektového řízení......................................................... 3

3

4

5

6

7

2.1

Řízení lidských zdrojů................................................................................................... 3

2.2

Lidské zdroje v projektovém řízení............................................................................... 5

2.3

Lidské zdroje v projektově orientované společnosti ..................................................... 7

Alokace lidských zdrojů v projektovém řízení ................................................................... 11 3.1

Alokace zdrojů na projektech...................................................................................... 11

3.2

Alokace zdrojů a řízení násobných projektů ............................................................... 14

Sdílení zdrojů v rámci projektově orientované společnosti ................................................ 18 4.1

Metody pro řešení problému sdílení zdrojů ................................................................ 18

4.2

Nástroje pro řešení problému sdílení zdrojů ............................................................... 21

Alokace zdrojů napříč projekty v prostředí konkrétní společnosti...................................... 25 5.1

Popis prostředí konkrétní společnosti ......................................................................... 25

5.2

Definice projektu......................................................................................................... 26

5.3

Rozpis prací a harmonogram projektu ........................................................................ 31

Analýza a návrh nástroje ..................................................................................................... 33 6.1

Analýza požadavků a případů užití ............................................................................. 33

6.2

Analýza současného stavu........................................................................................... 38

6.3

Výběr nástroje ............................................................................................................. 40

6.4

Specifikace nástroje .................................................................................................... 42

Závěr ................................................................................................................................... 46

Použité zdroje.............................................................................................................................. 47 A

Příloha ................................................................................................................................. 50

1

Úvod

Řízení lidských zdrojů je jedním ze základních stavebních kamenů jakékoli společnosti, která chce uspět na trhu, IT společnosti nevyjímaje. Kvalitní řízení lidského potenciálu přináší nejen konkurenční výhodu, ale přispívá i k celkové spokojenosti a motivaci zaměstnanců. Stejně klíčovou roli hraje řízení lidských zdrojů také v projektovém řízení, kde jedním ze základních problémů je, jak správně přiřazovat zdroje na jednotlivé projekty. A pokud je až potud situace relativně jednoduchá a přímočará, začíná být komplikovaná, když potřebujeme adekvátně sdílet lidské zdroje napříč projekty v rámci našeho portfolia. Práce se pokusí poukázat na fakt, že právě sdílení lidských zdrojů napříč projekty je v kontextu řízení lidských zdrojů, projektového řízení i řízení projektových portfolií dosud problematikou nepříliš prozkoumanou a často neadekvátně řešenou. V teoretickém jádru práce se budeme snažit stanovit konkrétní postupy pro řešení problému alokace zdrojů napříč projekty s ohledem na charakteristiky projektového prostředí – z těch nejprve odvodíme potřeby jednotlivých typů projektově orientovaných společností a následně se pokusíme najít vhodné nástroje, se kterými budeme moci tyto potřeby pokrýt. Práce je zaměřena zejména na společnosti zabývající se informačními technologiemi, ale její teoretická východiska je možno využít i pro projektová prostředí v jiných oborech lidské činnosti. Cílem praktické části práce je na základě teoretických konceptů analyzovat situaci v konkrétní společnosti poskytující služby vývoje softwaru na zakázku a vytvořit kompletní projektovou dokumentaci k vytvoření nástroje pro efektivní řízení a alokaci zdrojů napříč projekty firemního portfolia.

2

2

Řízení lidských zdrojů v kontextu projektového řízení

V této přehledové kapitole vymezíme úlohu, jakou má řízení lidských zdrojů (HRM) v organizacích obecně a jaké dodatečné požadavky jsou na ně kladeny v projektovém řízení. Následně se zaměříme na specifika projektově orientovaných společností s důrazem na IT firmy a popíšeme si výzvy, se kterými se řízení lidských zdrojů v takových společnostech potýká.

2.1

Řízení lidských zdrojů

Řízení lidských zdrojů je dle moderní definice strategickým a souvislým přístupem k řízení lidí, kteří jsou chápáni jako nejcennější aktivum jakékoli společnosti, a kteří k dosažení jejích cílů individuálně nebo společně přispívají [13, str. 3]. Pohledů na problematiku řízení lidských zdrojů je mnoho, od tradičního přístupu, který je zaměřen výhradně na administrativní stránku věci, až po ekonomický pohled, který vnímá zaměstnance především jako využitelné zdroje. Pro účely práce se zaměříme na moderní přístup, který má za cíl lidské zdroje nejen řídit a správně využívat, ale zejména jim umožnit pracovat co nejefektivněji. Důležitým prvkem fungujícího firemního prostředí je poté synergie mezi vizí a strategií firmy, její organizační strukturou a managementem lidských zdrojů [14, str. 16]. Neboli jinak řečeno, nemohou existovat velké rozdíly mezi zájmy jednotlivých zainteresovaných skupin - například manažerů a zaměstnanců, pokud jejich práce slouží stejnému cíli, kterým je prospěch společnosti. Jednou z hlavních úloh HRM je soustavné rozšiřování a zkvalitňování lidského kapitálu s cílem zvýšit výkonnost firmy. Základními procesy k naplnění tohoto cíle jsou: • • •

Výběr a najímaní lidských zdrojů Rozvoj lidských zdrojů Hodnocení výkonnosti a odměňování

Výběr a najímání lidských zdrojů V procesu výběru jsou u každého uchazeče identifikovány jeho kvalifikace a následně porovnávány s požadavky na pracovní pozici se záměrem vybrat co nejkompetentnějšího kandidáta [16, str. 6]. Nezbytností pro efektivní průběh procesu je adekvátní analýza pracovní pozice, identifikace množiny možných kandidátů a správný výběr selekčních technik. Pokud nejsou tyto podmínky dodrženy, může dojít k výběru kandidáta, který nesplňuje požadavky nejlépe ze všech nebo dokonce takového, který není schopen danou práci zvládnout. Výsledkem je ztráta času i finančních prostředků.

Rozvoj lidských zdrojů V procesu rozvoje dochází k rozšiřování existujících kompetencí, znalostí a dovedností zaměstnanců, vše opět s cílem posílit jejich výkonnost a tím i konkurenceschopnost firmy. Mezi

3

základní úkoly patří zejména zaškolení nových zaměstnanců jakožto „syrového“ materiálu a jejich soustavné vzdělávání vzhledem k měnícím se pracovním požadavkům. Proces je zajišťován individuálními a skupinovými rozvojovými plány, které by měly být pravidelně revidovány vzhledem k potřebám firmy a potenciálu jednotlivých zaměstnanců. V první řadě musí existovat dlouhodobý plán vzdělávání, prostřednictvím kterého jsou ve shodě se záměry a cíli společnosti prezentovány zaměstnancům možné oblasti osobního rozvoje. Z těch jsou poté odvozeny individuální plány, které by měly také respektovat aktuální pracovní náplň každého zaměstnance a tedy zvyšovat jeho efektivitu na stávajících úkolech. Splnění jednotlivých úkolů učebního nebo tréninkového plánu musí být náležitě hodnoceno a odměňováno.

Hodnocení výkonnosti a odměňování Hodnocení a odměňování zaměstnanců patří mezi nejdelikátnější procesy HRM1. Jejich cílem je kromě samotného sledování výkonnosti také identifikace slabých míst – příležitostí pro rozvoj, posílení komunikace mezi nadřízenými a podřízenými a obecně slouží zvýšení motivace zaměstnanců. Pokud jsou hodnotící schůzky vedeny věcně vzhledem ke zlepšení do budoucnosti, mohou být velice prospěšné oběma stranám, tedy jak podřízeným, tak nadřízeným. U hodnocení výkonnosti je nutná existence jednotných hodnotících kritérií pro zaměstnance. Obecně lze říci, že povědomí o výkonnosti zaměstnance by měl mít nadřízený soustavně, pravidelné schůzky by se poté měly zaměřovat především na shrnutí stavu a dlouhodobé možnosti zlepšení z obou stran. Hodnotící schůzky můžou mít mnoho forem. Nutná je zejména správná příprava ze strany nadřízeného nebo manažera, jelikož se jedná o důležitý motivující prvek pro zaměstnance. Posláním odměňování je kromě zvýšení motivace také znovupřijetí nebo potvrzení závazku zaměstnance vůči firmě. Odměny mohou být finanční – ty tvoří povýšení nebo různé finanční bonusy, nebo nefinanční – ty mohou být vyjádřeny pocitem odpovědnosti, důležitosti pro firmu, vlivu na ostatní, osobního růstu nebo souznění mezi vlastními a firemními hodnotami (to, co dělám, má smysl). Aby odměňování sloužilo svému cíli, tedy zvýšení celkové výkonnosti, musí být nastaveno transparentně a objektivně a mít jasnou souvislost s hodnocením výkonnosti. Z autorovy zkušenosti z malé firmy čítající kolem deseti zaměstnanců vyplývá, že výběr zaměstnanců je proces, který se potýká jen s relativně malými obtížemi, naproti tomu procesy rozvoje a zejména hodnocení a odměňování jsou často řešeny nedostatečně a neadekvátně firemnímu prostředí. Právě špatný přístup k posledním dvěma jmenovaným procesům může, rovněž ze zkušenosti, vést k vážným problémům v motivaci a výkonnosti zaměstnanců. Proto by nemělo být odměňování zaměstnanců vnímáno jako proces přinášející dodatečné náklady zaměstnavateli, ale naopak v širším kontextu jako prostředek, který může dát firmě konkurenční výhodu a v neposlední řadě přilákat další kvalitní pracovní síly.

1

V literatuře jsou tyto procesy často rozdělovány (viz například [16]), dle názoru autora jsou však natolik provázány, že je vhodné je uvést dohromady

4

2.2

Lidské zdroje v projektovém řízení

Projektové řízení (project management, PM) je označení pro množinu procesů, ve kterých jednotlivci nebo organizace využívají své zdroje k realizaci projektů, tedy neopakovatelných činností, které mají svůj daný cíl, začátek a konec v čase [19]. Tak jako v tradičních organizačních a řídících strukturách, rovněž v projektovém řízení zastává řízení lidských zdrojů důležitou roli – Project Management Body of Knowledge (PMBOK)2 jej považuje za jednu z devíti základních znalostních oblastí projektového řízení [1, str. 43].

Základní HRM procesy v rámci projektu Projektový tým je složen ze zaměstnanců, kterým jsou přiřazeny projektové role a odpovědnosti, které dané role obnáší. Počet členů týmu a jim přiřazené role se mohou v průběhu projektu měnit. Pro správný průběh projektu je nutná adekvátní organizace a řízení lidí v těchto hlavních procesech [1, str. 217]: • • • •

Vytvoření plánu lidských zdrojů Zajištění projektového týmu Rozvoj projektového týmu Řízení projektového týmu

Osobou odpovědnou za tyto procesy je projektový manažer nebo řídící tým projektu (typicky pro velké projekty), bývá však žádoucí do plánování a rozhodování zapojit i ostatní členy projektového týmu. Obzvláště účast v počátečních fázích projektu přispívá k vyšší motivaci a zapojení týmu do projektu [1, str. 215]. Při vytváření plánu lidských zdrojů pracujeme s požadavky jednotlivých aktivit projektu, ze kterých odvozujeme schopnosti a kompetence členů projektového týmu nutné ke splnění těchto požadavků. Výstupem je plán lidských zdrojů ve vhodném formátu – může jít například o hierarchický diagram, maticový diagram nebo prostý text s označením role, odpovědnosti, autority a kompetencí. Ke konkrétním nástrojům na tvorbu plánu lidských zdrojů se vrátíme a podrobněji je popíšeme ve třetí kapitole. V rámci zajištění projektového týmu je zodpovědností projektového manažera obsadit do definovaných rolí konkrétní pracovníky, kteří se budou na projektu podílet. Je nasnadě, že získání pracovníků na projekt nemusí být jednoduché, zvláště pokud jsou potřeba specializované zdroje, projektové oddělení je nadměrně vytíženo nebo nejsou k dispozici zkušení zaměstnanci (senior staff). Právě obsazení projektu konkrétními lidmi může způsobit velké odchylky v plánovaném rozpočtu a časovém plánu, správné vyvážení týmu je tedy důležitým úkolem projektového manažera. Alokaci zaměstnanců na projekt se podrobně věnuje třetí kapitola textu.

2

PMBOK vydává Project Management Institute (PMI), viz [1]

5

Rozvoj projektového týmu je jedním z nejzajímavějších a přitom často opomíjených aspektů práce projektového manažera. Jedná se o soustavu činností, které by měly přinášet zvýšenou motivaci, rozvoj znalosti, ale i větší oddanost týmu tak, aby vzrostla jeho celková zkušenost a výkonnost. Mezi tyto činnosti patří například teambuildingové aktivity, školení, neformální schůzky týmu, zpětná vazba (feedback) k práci týmu a různé jiné. Existuje také spousta tzv. měkkých dovedností (soft skills), které lze pro budování týmu využít – o těch mluví Společnost pro projektové řízení jako o tzv. behaviorálních kompetencích [2]. Řízení projektového týmu samotné je více soustředěno na administrativní stránku. Zajišťuje sledování výkonnosti a hodnocení členů týmu, předchází konfliktům a přispívá k jejich řešení a reportuje zkušenosti s řízením pro další projekty. Stejně jako v předchozích případech lze využít velkého množství technik a metod k vedení lidí, efektivnímu rozhodování nebo předávání znalostí.

Faktory ovlivňující úspěch projektů a odvozené požadavky na HRM I když HRM v projektovém řízení vychází ze stejných konceptů, kvůli proměnlivosti a komplexnosti projektů jsou na ně kladeny dodatečné požadavky. I když napříč literaturou existuje shoda v potřebě zahrnutí PM specifik (omezení nákladů, času, kvality, řízení rizik) a dodatečného zkoumání této problematiky, stále v současné době chybí ucelený empirický výzkum v této oblasti [12]. Abychom měli lepší představu, co od řízení zdrojů na projektech očekávat, popíšeme si nejprve hlavní faktory (nezávislé proměnné), které ovlivňují jejich úspěch nebo neúspěch. Pinto a Kharbanda [17] identifikují tyto hlavní faktory: 1. 2. 3. 4. 5. 6. 7.

Orientace na vizi, poslání projektu Brzká a souvislá konzultace se zákazníkem Technologie Plánovací systém Projektový tým Podpora vyššího managementu Souvislý proaktivní přístup

Belout a Gauvreau ukazují, že faktory jsou silně závislé na prostředí firmy, konkrétním projektu a také na aktuální fázi jeho životního cyklu. Za hlavní faktory v přípravné (plánovací) fázi projektu například považují akceptaci klientem, misi projektu a podporu managementu, v realizační (konstrukční) fázi schopnost řešení chyb a opět akceptaci klientem [12, str. 7]. Tvrdí také, že pokud se jedná o projekt s velkým rizikem, jsou rozhodujícími faktory autorita projektového manažera, komunikace, týmová spolupráce a schopnost řešení chyb. Mezi rozhodující faktory bezesporu můžeme zařadit samotnou osobnost projektového manažera, která byla v projektové literatuře často opomíjena. Výzkum v této oblasti stále probíhá [18], více o kompetencích projektového manažera také viz [2]. Na základě faktorů ovlivňujících úspěch projektů můžeme odvodit dodatečné požadavky, které jsou kladeny na řízení lidských zdrojů v kontextu projektového managementu. Tyto požadavky jsou zejména kladeny na znalosti a schopnosti lidí – členů projektových týmů, ať už se jedná o komunikaci v rámci týmu nebo s klientem, vnímání mise projektu v širším rozsahu

6

nebo schopnost rychlého řešení chyb. Vzhledem k proměnlivé povaze projektů je rovněž žádoucí klást větší důraz na flexibilitu zaměstnanců. Ve zkratce by řízení lidských zdrojů v projektovém managementu mělo ve svých procesech reflektovat specifické požadavky projektového řízení na lidské zdroje.

2.3

Lidské zdroje v projektově orientované společnosti

Jak jsme již psali výše, úloha HRM je široce chápána jako jeden z hlavních nástrojů pro dosažení konkurenční výhody jakékoli firmy, přičemž samotné HRM procesy by měly být zarovnány horizontálně mezi sebou samými a vertikálně v souladu se strategií a vizí firmy. Pokud budeme považovat „řízení pomocí projektů“ za organizační strategii projektově orientované společnosti odlišující ji od společností řízených klasickým způsobem, přímo z toho vyplývá, že by se HRM politiky a procesy měly přizpůsobovat tomuto prostředí a lišit se tak od tradičních HRM procesů a praktik popsaných výše. V této podkapitole si popíšeme specifika projektově orientovaných společností a s nimi spojené výzvy pro HRM. Huemann et al [4, str. 2] definuje projektově orientované společnosti jako takové, jejichž zaměstnanci: • • • • •

definují „řízení pomocí projektů“ jako svou organizační strategii využívají projektů a programů pro vykonávání komplexních procesů spravují projektové portfolio různých interních a externích projektů mají specifické trvalé organizace jako je projektová kancelář (PM office) s integrační funkcí vnímají organizaci jako projektově orientovanou

Typicky se jedná o společnosti s plochou řídící strukturou a silnou kulturou projektového řízení. Lišit se mohou v míře projektové orientace, což může být dáno velikostí, počtem a typem realizovaných projektů. Projektově orientovány mohou být jak celé společnosti, tak pouze některé jednotky nebo oddělení (například konstrukční, výzkumu a vývoje a jiné). Mezi specifika takových společností patří [4, str. 2-3]: • • •

dočasný charakter projektů dynamika prostředí sdílení zdrojů napříč projekty, konkrétní zaměstnanec v nich zpravidla zastává více rolí

Výzvy pro HRM v projektově orientovaném prostředí Z výše uvedeného vyplývají některé dodatečné požadavky, kterým se HRM musí přizpůsobit. Kvůli dočasnosti projektů (v kontrastu s trvalými organizacemi „klasických“ firem) se především často, tedy při každém startu a konci projektu, mnohdy i v jeho průběhu, mění konfigurace zdrojů ve společnosti. Existuje tedy potřeba nových procesů, se kterými klasické HRM nepočítá, jako jsou přiřazení na projekt nebo uvolnění z projektu. Zajímavým aspektem jsou kariéry zaměstnanců – klasicky vnímaná kariéra se v projektovém prostředí vytrácí a je 7

tedy třeba nových procesů pro spojení úvazků na projektech s kariérou. V projektově orientovaných společnostech se mohou objevit některé nové jevy, jako jsou dlouhodobé přetěžování některých projektových rolí, konflikt mezi nimi a jiné – proto je velice důležité zaměřovat se na prospěch zaměstnanců a etické zacházení s nimi. Při podcenění těchto úkolů může docházet k dlouhodobému neuspokojení prací a vyčerpání zaměstnanců nebo syndromu vyhoření u mladších spolupracovníků, kteří se neumí vyrovnat s množstvím rolí a různorodostí úkolů. Jak jsme si již ukázali v přecházející podkapitole, v projektovém prostředí – a tedy nutně i v projektově orientovaných společnostech – existují dodatečné požadavky na schopnosti a kompetence zaměstnanců. Je to dáno zejména zmocněním řadových zaměstnanců v rámci projektů, procesní orientací, týmovou prací, orientací na zákazníky a dlouhodobým propojováním s klienty a dodavateli. Firma může dovednosti v těchto oblastech formálně vyžadovat nebo je přirozeně podporovat. Podle Huemann et al existují některé chybějící souvislosti v současné projektové a HRM literatuře [4, str. 7]. Ta se věnuje řízení lidských zdrojů na jednotlivých projektech, případně alokaci zdrojů mezi projekty, již méně teoretické koncepci o tom, co potřebuje projektově orientovaná společnost od HRM na projektech. V této souvislosti je již široce vnímán posun od technického projektového řízení k řízení zaměřeného na lidi, výzkum HRM v projektovém prostředí však teprve probíhá [4, str. 3]. Obzvláště literatura k řízení lidských zdrojů, z nichž vychází i úplný úvod práce, je zaměřena spíše na trvalé, velké organizace, i když i tento trend se začíná měnit.

HRM procesy v projektově orientovaných společnostech Nyní se konkrétně zaměříme na HRM procesy v projektově orientovaném prostředí. V podkapitole 1.1 jsme si představili některé ze základních procesů, jako je výběr zaměstnance, jeho rozvoj, hodnocení a odměňování. Podobné procesy jsou přítomny i v rámci každého projektu, vztah projektových a organizačních procesů je přehledně zobrazen na obrázku 2.1 – rozvoj, hodnocení a odměňování zaměstnance na projektu přispívá k jeho rozvoji, hodnocení a odměňování v rámci organizace.

8

Obrázek 2.1: upravený Michiganův model HRM, převzato z [4] Podobnou souvislost zachycuje také obrázek 2.2, který v jednoduchém modelu zachycuje rozdíl mezi řízení lidských zdrojů v projektově orientované a klasicky řízené společnosti. Z něj můžeme vidět, že přibyly tři dodatečné procesy (přiřazení na projekt, zaměstnání na projektu a uvolnění z projektu), změn se však dočkaly i stávající procesy.

Obrázek 2.2: tzv. jednoduchý model HRM, převzato z [4] 9

Minimální změny jsou v procesu selekce, i když jsme si již představili některé dodatečné požadavky na schopnosti a kompetence zaměstnanců. Výběr zaměstnanců lze provádět pro společnost jako takovou nebo pro konkrétní projekt, specifickou roli má výběr projektových manažerů. Větší změny nalezneme v procesech zaměstnaneckých, tedy těch souvisejících s rozvojem, hodnocením a odměňováním. Především je třeba počítat s tím, že projekty nemohou vzhledem ke své dočasnosti poskytnout přímočaré kariéry – ty jsou spíše založeny na rozšiřujících se zkušenostech ze širokého spektra prací, úkolů a rolí. Proto může projektové prostředí nabídnout zajímavé a různorodé kariéry – pozornost je však třeba ve větší míře věnovat procesům, které spojují zaměstnance s projekty a projekty s kariérami. Pokud nejsou tyto procesy dobře definovány a vedeny, může to snadno vést k pocitům nespravedlnosti nebo nedocenění u zaměstnanců. Mezi nové procesy patří přiřazení na projekt, zaměstnání na projektu a uvolnění z něj. Přiřazení vykazuje některé podobnosti s nabíráním zaměstnanců, ale také některé důležité rozdíly. Rozhodnutí o alokaci zdrojů jsou založeny na specifických požadavcích projektu a posouzení, jací lidé s jakými schopnostmi jsou dostupní v daném čase. Zaměstnanci mohou být na projekt přiřazováni také často až v jeho průběhu. Samotné zaměstnání na projektu je proces, který je nejlépe popsán ze všech tří, zejména v literatuře týkající se projektového řízení [6], [7]. Silně je ovlivněn zejména osobou a vedoucími schopnostmi projektového manažera. Zajímavým procesem je bezesporu uvolnění pracovníků z projektu, kterému není v HRM nebo PM literatuře věnováno příliš prostoru [4, str. 7]. Organizace musí v okamžiku uvolnění člena týmu rozhodnout, jestli ho přiřadit na jiný aktuálně probíhající nebo v blízké době začínající projekt, věnovat jeho čas učebním a jiným rozvojovým aktivitám nebo jej kupříkladu využít na vylepšení firemních procesů. Takové rozhodnutí je vhodné učinit po konzultaci se zaměstnancem samotným, který by měl také podat zpětnou vazbu k právě končícímu projektu.

10

3

Alokace lidských zdrojů v projektovém řízení

Ve třetí kapitole se dále zaměříme na problematiku přiřazení (alokace) lidských zdrojů na projektech, zejména z hlediska nástrojů, které k němu můžeme využít. Druhá část kapitoly je jakousi zápletkou celé práce, když dává do souvislosti alokaci zdrojů s řízením násobných projektů, a zároveň výchozím bodem pro teoretické jádro práce ve čtvrté kapitole.

3.1

Alokace zdrojů na projektech

Pro účely řízení projektu v softwarových i jiných společnostech hraje v rámci HRM procesů důležitou roli zejména obsazení projektových rolí a tedy schopnost plánovat a alokovat zdroje. Předpokladem pro to, abychom mohli obsadit lidské zdroje na projekt, je existence rozpisu prací (work breakdown structure, WBS), časového harmonogramu a vymezení rolí a kompetencí potřebných pro realizaci konkrétních projektových aktivit. Pro obsazení jednotlivých rolí projektového týmu jsou podle Svozilové [7, str. 154] rozhodující jejich: • • •

odbornost a úroveň kvalifikace vzhledem k požadovanému výkonu dostupnost v čase vzhledem k harmonogramu náklady na výkon činnosti podle popisu vzhledem k rozpočtu

Pokud nejsou výše uvedené body splněny vzhledem k potřebám projektu, je ohrožena kvalita výstupů projektu, včasnost dokončení i plánované náklady. Projektový manažer se tedy musí vždy snažit získat požadované zdroje napříč projektovým prostředím, kdy řeší dva problémy: • •

kteří ze zaměstnanců jsou pro danou roli vhodní? koho mohu v daném čase využít?

Odpověď na první otázku je jednoduchá v případě malých firem, kdy se většinou projektoví manažeři s ostatními zaměstnanci osobně znají. U středních a velkých firem se už jedná o netriviální problém, kdy se s výhodou uplatňují různé softwarové prostředky pro řízení znalostí a schopností jednotlivých zaměstnanců. Odpověď na druhou otázku může být ještě složitější, nacházíme-li se v projektově orientovaném prostředí, kdy mohou být jednotlivé projekty v různých fázích, a tedy mají různé a zejména dynamicky se měnící požadavky na zdroje. Navíc jsou problémem i specializované zdroje (v IT prostředí to může být například grafik, analytik nebo konzultant pro konkrétní technickou doménu), kteří jsou často alokováni na několika projektech současně. Důležitou roli v procesu alokace zdrojů hrají také linioví manažeři3, jejichž zodpovědností je schválit přiřazení podřízeného na dočasnou dobu do organizační struktury projektu. Linioví manažeři mají také nejlepší přehled o kvalifikaci svých podřízených (zvláště pokud neexistuje aktuální a pravidelně aktualizovaná databáze schopností) a mohou rozhodnout, jestli jsou 3

Také označováni jako manažeři prvního stupně

11

schopni zastat roli přidělenou rozpisem prací. Z výše uvedeného vyplývá, že jsou pro fungující alokaci na projekty klíčové otevřené vztahy mezi projektovými a liniovými manažery. Mezi další faktory v přidělování zdrojů na projekt patří dle Svozilové [7, str. 156] autorita projektového manažera, přiřaditelnost jednotlivých úkolů, rozsah odpovědnosti jednotlivých členů týmu a v neposlední řadě také explicitní přijetí osobního závazku, kterým dává zaměstnanec najevo, že rozumí zadanému úkolu a souhlasí s jeho rozsahem. Budoucí člen týmu jím přímá roli definovanou projektovým manažerem a schválenou jeho liniovým manažerem a stává se právoplatným členem týmu. Použití vhodných nástrojů může nejen ulehčit alokaci zdrojů, ale také odhalit případné problémy nebo dokonce nedostatek pracovníků k obsazení všech úkolů v rámci definovaného harmonogramu. Řešením takového nedostatku může být obsazení projektu zdrojem z jiného projektu, novými zaměstnanci, externími zdroji nebo ve vážném případě omezení rozsahu projektu nebo posunutí harmonogramu.

Optimalizace zdrojů Optimalizace zdrojů je komplikovanou a komplexní činností, jež je zpravidla motivována snahou snížit náklady na řízení projektu, minimalizovat možná rizika nebo vyřešit technické nebo technologické problémy, které na projektu mohou nastat a ohrozit tak jeho průběh. Optimalizace zpravidla nastupuje po vytvoření projektového týmu a obsazení veškerých rolí a bere tedy do úvahy konkrétní pracovníky (motivací například může být zkrácení doby důležitého zdroje na projektu). Vzhledem k její složitosti a sporně vnímaným výsledkům se neprovádí vždy, může však dopomoci předcházet problémům s alokací zdrojů. Jako konkrétní příklad, kdy a jak použít optimalizaci zdrojů, si představme tuto situaci: existuje kritická cesta vzhledem k limitovaným zdrojům na projektu, kteří ovšem spolupracují i na ostatních úkolech mimo ni. Problémem je, že v našem harmonogramu jsou tyto limitované zdroje na některé týdny alokovány na dvě třetiny své kapacity a jiné týdny překračují svou pracovní dobu o pár desítek procent. V jiném případě bychom nezasáhli a spoléhali na to, že se situace vyřeší zvýšeným úsilím pracovníka, nyní však víme, že zasažením kritické cesty riskujeme zpoždění celého projektu. Můžeme využít dvě metody: za prvé tzv. vyrovnání zdrojů (resource leveling), a tedy vyrovnat nebo normalizovat špičky ve vytížení konkrétních zdrojů4 nebo se pokusit co nejvíce zkrátit kritickou cestu s ohledem na tyto limitované zdroje. V ideálním případě se nám může podařit optimalizovat bez natažení harmonogramu, v praxi však takový zásah může vyvolat další potřebu kompenzací. I z výše uvedeného vyplývá, že optimalizace zdrojů je relativně náročná na zkušenosti projektového manažera. Obecně je možné říci, že neexistuje jasné ani samospasné řešení, ale že se vždy jedná o kompromis mezi zájmy zúčastněných stran včetně pracovníků samotných. Projektový manažer by měl k problému přistupovat pokud možno kreativně, flexibilně a přitom obezřetně.

4

Více viz [1, str. 156]

12

Nástroje na podporu alokace zdrojů na projektech Pro plánování a alokaci zdrojů na projektech je dostupná řada softwarových nástrojů. Vzhledem k tomu, že je jejich úplný výčet nad rámec této práce, a navíc se jim konkrétně budeme věnovat v další kapitole, popíšeme si nyní pouze, jak lze pomocí nástrojů problém alokace zdrojů řešit. Při plánování a alokaci zdrojů nejprve potřebujeme vytvořit tzv. kapacitní plán, tedy určitý rozvrh zdrojů na projektu, ze kterého vyplývá, kteří pracovníci budou vzhledem k časovému průběhu projektu přiřazeni na jakých úkolech. Bývá časté, že v okamžiku tvorby tohoto plánu neznáme konkrétní obsazení projektu lidskými zdroji, v tom případě pracujeme s rolemi. Kapacitní plán musí zejména odpovídat časovým nárokům jednotlivých činností a celého projektu na zdroje [6, str. 177]. Výstupy kapacitního plánování mohou být v tabulkové formě – tzv. číselná sumarizace zdrojů (víme, jaké množství zdrojů v daném okamžiku projektu potřebujeme na daný úkol), viz následující tabulka: Tabulka 3.1: Tabulka zdrojů – požadavek na mladší inženýry Úkol 1. 2. 3. 4. 5. 6. A 4 4 4 4 B 3 3 3 3 C 5 5 5 D E F 2 G H

7.

8.

9.

10.

6

6 3

6

4

4

3 6 2

* sloupce odpovídají jednotlivým týdnům, číselné hodnoty uvedeny v člověkodnech (man-day, dále MD)

Podobnou informaci nám mohou – a často přehledněji – poskytnout různé grafické nástroje, většinou ve formě sloupcových grafů (histogramů). V těch představuje vodorovná X osa časový průběh projektu, kdežto na svislé ose jsou uvedeny požadované kapacity jednotlivých plánovaných zdrojů – viz obrázek 3.1. Histogramy se obvykle provádějí podle druhu zdrojů nebo rolí na projektech, tedy v případě softwarových společností se může jednat například o testery, junior vývojáře nebo analytiky. 14 12 10 8 6 4 2 0

Obrázek 3.1: Histogram zdrojů – požadavek na inženýry (obsahově shodný s tabulkou 3.1) 13

Odhlédneme-li od striktně kapacitního plánování lidských zdrojů v čase, může nám dát dobrou představu o úkolech a odpovědnostech k nim vázaných také tzv. matice odpovědností. Jedná se o tabulkové vymezení odpovědností jednotlivých osob, většinou ji má tedy smysl tvořit až v okamžiku, kdy máme obsazeny všechny projektové role. Matice odpovědností odpovídá rozpisu prací, který by měla kompletně pokrývat a popisovat tak vztahy mezi organizační strukturou projektu a jednotlivými úkoly. Existuje několik implementací matice odpovědnosti, mezi nejrozšířenější patří matice RACI, jejíž příklad je zobrazen na obrázku 3.2. V matici jsou odpovědnosti k jednotlivým úkolům rozděleny takto: R=responsible (odpovědný za vykonání práce), A=accountable (odpovědný za splnění úkolu), C=consult (dostupný ke konzultaci) a I=inform (informován o průběhu).

Obrázek 3.2: Matice RACI pro jednu z aktivit z rozpisu prací, převzato z [1]

3.2

Alokace zdrojů a řízení násobných projektů

Dosud jsme se věnovali podstatě řízení lidských zdrojů v projektově orientovaném prostředí a alokaci těchto zdrojů na projektech. Nyní se pokusíme postoupit o krok dále a nastínit tak problém, k jehož řešení má diplomová práce přispět, a to je alokace zdrojů napříč portfoliem projektů.

Řízení projektového portfolia V každé projektově orientované společnosti musí existovat určitá organizační struktura, která zajišťuje výběr, prioritizaci a řízení množiny projektů vzhledem k obchodním cílům společnosti. V předcházející kapitole jsme popisovali projektovou kancelář jako trvalou organizaci s integrační funkcí. Pokud je ale řeč o projektově orientované společnosti, rozlišuje literatura mezi dvěma termíny – řízení projektového portfolia (Project Portfolio Management, PPM) a řízení násobných projektů (Multiple Project Management, MPM). Řízení projektového portfolia se soustřeďuje na středně- a dlouhodobé plánování, výběr a prioritizaci projektů, zatímco řízení násobných projektů na krátkodobé plánování s důrazem na alokaci zdrojů napříč projekty [10, str. 1].

14

Řízení projektového portfolia je většinou v odpovědnosti vyššího managementu, který rozhoduje o prioritizaci nových projektů, případně reviduje prioritu stávajících. Pokud PPM proces funguje správně, mělo by docházet při změně v cílech a směřování společnosti také ke změně v aktuálním složení běžících projektů [10, str. 3]. PPM pracuje s tvrdými ekonomickými metrikami, jako jsou celková cena projektu, celková spotřeba zdrojů, návratnost investice (return of investment, ROI) nebo celková ziskovost projektu. K ostatním metrikám patří shoda s obchodními a technickými cíli a závislosti mezi projekty v rámci portfolia. Teprve po výběru projektů „shora“ přebírá řídící roli řízení násobných projektů, tedy v našem případě projektová kancelář. Jejím posláním je mimo jiné zajistit standardizaci a opakovatelnost procesu řízení projektů, je zdrojem dokumentace, návodů, metrik a osvědčených postupů (best practices) pro výkon projektového řízení. Nejdůležitější dennodenní starostí projektové kanceláře je ovšem řízení zdrojů. Operujeme s tzv. bazénem zdrojů (resources pool), který nám umožňuje získat odpověď na otázku, které zdroje s jakými schopnostmi a dovednostmi máme v současné době k dispozici a tzv. proudem projektů (project pipeline) vybraných k realizaci v rámci PPM. Bazén zdrojů a proud projektů jsou vstupem procesu alokace zdrojů napříč projekty, jehož výstupem je přiřazení konkrétních zdrojů na konkrétní role konkrétních projektů v čase. V následující kapitole si ukážeme, jaký je vztah řízení lidských zdrojů, řízení násobných projektů a řízení projektového portfolia.

Syndrom alokace zdrojů jako primární výzva řízení násobných projektů Engwall a Jerbrant ve své práci [5] rozebírají rozhodující faktory, které ovlivňují proces řízení násobných projektů. Vycházejí z poznatku, že většina teoretických prací je postavena buď na zkušenostech autora nebo na závěrech výzkumu v konkrétní oblasti, typu projektu nebo organizace a snaží se rozlišit, jaké faktory jsou dány kontextem a tedy specifické, a jaké jsou obecně platné pro jakékoli projektově orientované prostředí. To autoři popisují především jako vysoce politické se stálým soupeřením mezi manažery a projekty ohledně priorit, zaměstnanců, pozornosti a zdrojů obecně. Zkoumáním dynamiky projektově orientovaného prostředí a koordinace projektů v rámci portfolia dospívají k tvrzení, že primární výzvou řízení násobných projektů je dále popsaný tzv. syndrom alokace zdrojů (resources allocation syndrome). Jejich studie je založena na soustavném zkoumání dvou společností s odlišnou velikostí i vyspělostí projektového prostředí5. Rozdíly ležely zejména v rozsahu projektů – v první firmě se jednalo o projekty pro externí zákazníky, kdežto v druhém případě šlo o interní rozvojové a výzkumné projekty. Dále se prostředí lišily komplexností projektů, sílou projektové orientace i skladbou projektového portfolia. Přesto existovalo velké množství podobných charakteristik, které autoři shrnuli do čtyř hlavních bodů [5, str. 4] : • • • •

silná závislost mezi projekty stanovování priorit a realokace zdrojů jako každodenní problém projektového portfolia tvrdé soupeření mezi projekty krátkodobé řešení problémů

5

Tyto dva faktory považuje autor této práce za jedny z hlavních měřítek, které definují prostředí projektově orientované firmy. Tato měřítka budou rozebírány v následující kapitole.

15

Silná meziprojektová závislost spočívá zejména v lidských zdrojích a tedy zvyšuje důležitost plánování jejich alokace. V obou společnostech existovala komise, která pravidelně revidovala složení projektového portfolia a priority projektů, což byl úkol mimo autoritu projektových manažerů. V důsledku bylo řízení projektového portfolia zahlceno požadavky na distribuci zdrojů směrem k projektům s vysokou prioritou nebo projektům v aktuální krizi, což přinášelo negativní efekty na nepředpokládaná místa portfolia. V důsledku této dynamičnosti prostředí a rozdílných zájmů různých stran docházelo k soupeřením a konfliktům, které opět musely být eskalovány až na úroveň projektového portfolia. Vše výše popsané vedlo ke stavu, kdy se PPM soustředilo na ad hoc řešení problémů a zanedbávalo rozvoj znalostí a dlouhodobé vylepšování procesu. V obou organizacích byl silně rozšířen pocit neefektivity. Syndrom identifikovaný v práci a popsaný v předchozím odstavci považují autoři za spojený s projektově orientovaným prostředí jako takovým, nezávisle na typu projektu, průmyslovém kontextu a individuálních projektových účastnících [5, str. 5]. Tento poznatek se snaží dále zdůvodnit prostřednictvím mechanismů ovlivňujících nabídku zdrojů a poptávku po nich. Na straně poptávky identifikovali problém v selhávajícím projektovém plánování. U obou společností existoval plánovací systém, který však nebyl schopen zastávat svou roli, pokud se jeden nebo více projektů zpozdily přes určitou hranici. Druhým problémem, který se vyskytoval se stejnou pravidelností, byl efekt přehnaného závazku (over commitment), tedy realizace příliš velkého množství projektů vzhledem k existující úrovni zdrojů6. Ergwall a Jerbrant přirovnávají tento přístup ke kleci na kanárky (doslova canary cage approach) v plánování portfolia, kdy dochází k přidávání nových projektů do „klece“, aniž by byl předem analyzován efekt na další aktuálně probíhající projekty. Na straně nabídky identifikovali autoři dva aspekty, které nejsou v projektové literatuře příliš zmiňovány. Za prvé, obě společnosti používaly manažerské evidenční systémy (management accounting systems), které byly dysfunkční v projektovém prostředí. Vzhledem k nastavenému procesu vykazování práce tak byl v první společnosti upřednostňován čas zaměstnanců strávený na konkrétních projektech – adekvátně finančně oceňován naopak nebyl čas věnovaný zvyšování osobní produktivity. V druhé společnosti nefungoval evidenční systém vůbec a manažeři portfolia nebo projektoví manažeři neměli žádnou představu o konkrétních činnostech, které zaměstnanci na projektech vykonávali. Jako druhou možnou příčinu na straně nabídky zdrojů poté autoři identifikovali oportunistické chování projektových manažerů, kteří se za každou cenu snažili pro svůj projekt vyjednat vysokou prioritu od vedení, a pokud toho nebyli schopni, dovedli projekt do stavu takové krize, že řízení portfolia bylo nuceno prioritu zvednout, pokud měl mít projekt vůbec šanci na přežití. Stejně tak si projektoví manažeři snažili chránit své zdroje za každou cenu a uměle je udržovali zaneprázdněné a nedostupné. Autor této práce není přesvědčen, že uvedené dysfunkční mechanismy nutně působí v jakékoli projektově orientované firmě, nicméně souhlasí s faktem, že se jedná o mechanismy, ke kterým projektově orientované prostředí v určitém smyslu směřuje a kterým je nutno předcházet. V tomto smyslu souhlasí se závěry Engwalla a Jerbrant, kteří shrnují, že minulý výzkum považoval sdílení zdrojů napříč projekty především jako problém plánování a tedy předcházející problému, kdežto současný ukazuje, že je toto vnímání příliš zjednodušující.

6

Více o tématu také ve výborném článku Petera Kretzmana, viz [20]

16

Argumentují především tím, že je alokování těchto zdrojů politickou záležitostí mnohem komplexnější, než tradiční literatura připouští [5, str. 6]. Závěrem této kapitoly můžeme konstatovat, že existence adekvátních plánovacích a evidenčních nástrojů (accounting systems) je nutnou, ale nikoli dostačující podmínkou pro fungující řízení násobných projektů a sdílení zdrojů napříč těmito projekty. Klíčovým je především zajistit, aby manažerské procedury a procesy byly vybudovány a přizpůsobeny od základu typu organizace, typu řízených projektů a dalším faktorům. Dále v práci se tedy budeme věnovat konkrétním metodikám a nástrojům, které lze pro sdílení zdrojů v různých projektových prostředích využít.

17

4

Sdílení zdrojů v rámci projektově orientované společnosti

Jak bylo řečeno, řízení násobných projektů potřebuje efektivní a dynamický proces k určení jak alokovat lidské zdroje a jak nastavit realizovatelný plán dokončení pro nové projekty. Efektivní alokace zdrojů napříč projekty znamená vybírat po dobu trvání všech projektů v portfoliu ty nejlepší kompromisy mezi zdroji a stanovovat správné priority [10] – v opačném případě může dojít k drastickému poklesu výkonnosti projektů a celé společnosti. Zatímco adekvátní určování projektové priority vzhledem k cílům a strategii firmy je nad rámec této práce, problém efektivní alokace je naopak jejím těžištěm.

4.1

Metody pro řešení problému sdílení zdrojů

Pozornému čtenáři by mělo být v této chvíli jasné, že výběr nástroje pro řešení problému alokace zdrojů napříč projekty musí nutně záviset na konkrétním projektovém prostředí. Gartner7 ve svém magickém kvadrantu PPM nástrojů mluví o nutnosti aplikovat „právě tak akorát procesu“ (doslova „just enough process“) k poskytnutí vhledu do nejkritičtějších záležitostí nabídky, poptávky a reportování na projektové úrovni [11]. Stejnou poučku můžeme vztáhnout i na alokaci zdrojů: vždy je třeba použít takové metody a nástroje, které nám podají klíčové informace a zajistí řešení základních problémů bez přílišného zatížení celého projektového oddělení. Máme-li za úkol implementovat nástroj, který nám má umožnit řešit alokaci zdrojů napříč projekty efektivně, je třeba si na začátku stanovit postup, v rámci kterého analyzujeme firemní prostředí a dostupné nástroje. Nejprve si tedy pokusíme stanovit hlavní faktory a proměnné, které nám umožní rozlišovat mezi různými druhy společností. Autor této práce považuje za hlavní faktory tyto: • • •

velikost společnosti vyspělost projektového prostředí druh podnikání

Vzhledem k tomu, že práce uvažuje zejména nad projekty softwarových společností – a to i přesto, že se snaží neztrácet na obecnosti – pokusíme se nyní popsat roli prostředí softwarového vývoje v celé problematice a následně se mu již věnovat výhradně. Dle názoru autora této práce vyniká IT prostředí zejména svou dynamikou – více než v jiných odvětvích se vývoj softwaru posouvá rychle vpřed, prozkoumává nové oblasti a využívá relativně nových metodik agilního vývoje software. A právě agilní metodiky jako jsou například SCRUM, Vývoj řízený vlastnostmi (Feature-driven development, FDD) a Vývoj řízený testy (Test-driven development, TDD) jsou dobrým příkladem, jak se softwarové inženýrství vyrovnává s flexibilními požadavky zákazníků, kteří se orientují na své obchodní cíle – a tedy rychlou dodávku fungující aplikace – a méně je zajímá detailní analýza nebo obsáhlá dokumentace. Trefně to shrnuje Peter Kretzman tvrzením, že úspěšný IT manažer se učí žít s mnohoznačností, nejistotou a hrubým odhadem a pracovat v jejich rámci [8]. Pokud jsme si tedy v první kapitole jmenovali dynamiku 7

Gartner, Inc. je výzkumná a poradenská společnost zaměřená na IT technologie

18

prostředí jako jednu z charakteristik projektově orientovaných společností, lze říci, že prostředí softwarového inženýrství tuto charakteristiku dále prohlubuje. I když druh podnikání může na nástroje pro alokaci zdrojů klást některé dodatečné požadavky, mnohem zajímavější se jeví další dvě proměnné a to velikost společnosti a vyspělost projektového prostředí. Pro rozlišení velikosti firmy nám pro naše účely postačí stanovit hranici sta zaměstnanců, která nám rozdělí společnosti na malé a velké. Pokud budeme chtít sledovat vyspělost prostředí, je situace složitější. Zvolíme model vyspělosti řízení projektového portfolia společnosti Gartner, který na základě pěti dimenzí rozlišuje šest základních stupňů vyspělosti projektového prostředí IT společností8: • • • • • •

neexistující (PPM) prvotní rozvíjející se definované řízené optimalizující

Nyní se pokusíme načrtnout rozdělení projektově orientovaných IT společností. Na obrázku 4.1 jsou zobrazeny čtyři základní typy projektově orientovaných společností v závislosti na jejich velikosti a vyspělosti projektového prostředí 9. Dále si blíže popíšeme jednotlivé typy a odvodíme si, jaké potřeby u nich vznikají vzhledem k nástrojům na alokaci zdrojů.

Obrázek 4.1: Typy projektově orientovaných IT společností Společnosti v prvním kvadrantu jsou malé společnosti, u kterých existují základní procesy, jsou používány nástroje pro plánování projektů a odhad jejich nákladů. Příkladem mohou být malé IT firmy specializující se na poskytování služeb s krátkodobými projekty na vývoj 8

Viz například [21] Podobný obrázek budeme používat i dále v práci, kdy navážeme na typy projektově orientovaných společností a budeme dále definovat jejich potřeby a nástroje pro pokrytí potřeb. 9

19

jednoduchých nástrojů. Takové společnosti budou mít minimální požadavky na nástroje pro alokaci zdrojů, většinou omezené na jednotlivé projekty s pouze malými přesahy do projektového prostředí jako celku. Naproti tomu společnosti v kvadrantu II mají přes svou velikost přítomnou trvalou organizaci ve formě projektové kanceláře, standardizovány procesy pro široké spektrum vedených projektů, používají sdílený bazén zdrojů, řídí rizika a v neposlední řadě jsou schopny odhadovat přínosy jednotlivých projektů v rámci portfolia – zde se může jednat o menší společnosti vyvíjející software na zakázku. Takové společnosti budou vyžadovat jednoduché nástroje, které jim umožní v pravidelném intervalu zobrazovat a plánovat alokaci zdrojů napříč portfoliem, vše spíše v hrubém měřítku než v přesných číslech. V třetím kvadrantu jsou velké společnosti, které nemají podobně jako v případě kvadrantu prvního standardizovány procesy projektového řízení. Typicky se může jednat o společnosti, u nichž vykazují charakteristiky projektového prostředí jen některá oddělení, a nejedná se tedy o čistě projektově orientované společnosti – například pobočky velkých firem poskytující pouze podporu produktů. Vzhledem k jejich velikosti je však potřeba, aby nástroje poskytovaly širší možnosti pro řízení portfolia. Posledním, čtvrtým kvadrantem je kvadrant velkých, projektově vyspělých společností, které mohou vést stovky projektů a zaměstnávat tisíce zaměstnanců. Takové společnosti se zaměřují na optimalizaci portfolia, detailně sledují ziskovost realizace projektů a jsou často lídry ve svém oboru. Nutností jsou prvotřídní balíky nástrojů s širokou funkcionalitou, možnostmi integrace s dalšími systémy a sledování přesných metrik v reálném čase. Na obrázku 4.2 rozšiřujeme předchozí obrázek o potřeby jednotlivých typů společností:

Obrázek 4.2: Potřeby jednotlivých typů projektově orientovaných společností

20

4.2

Nástroje pro řešení problému sdílení zdrojů

V této podkapitole si představíme některé základní typy nástrojů pro alokaci zdrojů napříč projekty a popíšeme si jejich hlavní zástupce. Následně se pokusíme jednotlivým typům projektově orientovaných společností rozdělených v obrázcích 4.1 a 4.2 přiřadit vhodné typy nástrojů. Již ze začátku je třeba upozornit na fakt, že výběr nástroje je pouze jedním článkem řešení problému alokace zdrojů – také proto jsme se nejprve zaměřili na metodu výběru, poté až na nástroje. Na současném trhu s nástroji pro řízení projektů a portfolií existuje spektrum nástrojů nabízející širokou funkcionalitu [11]. Není jednoduché se zorientovat a vybrat správný – mnohé společnosti právě v tomto okamžiku ztrácí tím, že volí jeden ze dvou extrémů: buď problém alokace zdrojů napříč projekty ignorují, nebo volí komplexní nástroj, který daleko přesahuje jejich potřeby [8]. My se pokusíme ukázat, že to jde jednodušeji – přesně podle poučky „just enough process“ nebo chcete-li principu KISS10. V každém případě ale platí, že nelze prostě začít používat nástroj pro řízení portfolia, je třeba se nejprve rozhodnout, jak zeširoka k problému přistupovat a jak hluboko se do něj ponořit. Peter Kretzman identifikuje pět kategorií nástrojů, které můžeme pro alokaci zdrojů napříč projekty využít [8]: • • • • •

improvizované, ad-hoc nástroje (anglicky doslova seat of the pants) tabulky zdrojů s přibližnými hodnotami instalované softwarové balíky webové produkty rozsáhlé softwarové balíky

Improvizované nástroje jsou výhradně intuitivním řešením problému alokace aktuálně volných lidí na projekty, nemají žádnou pevnou formu a nelze je využít na alokaci napříč projekty ani na delší časové období. Nejsou spolehlivé, pokud máme pevně stanovené procesy, protože jejich využití záleží na situaci a není opakovatelné. Tyto nástroje využijeme pouze v prostředí malé firmy, kde známe všechny zaměstnance a potřebujeme se rozhodnout, které z nich přiřadit jako zdroje na právě začínající nebo probíhající projekt. Příkladem takových nástrojů může být jakákoli tabulka nebo textový soupis volných zdrojů spolu s jejich dovednostmi a schopnostmi. Tabulky zdrojů s přibližnými hodnotami nám poskytují jednoduchý a přesto nezbytný přehled stavu alokace lidských zdrojů napříč projekty, a to jak aktuální, tak s výhledem do budoucna. Jejich velkou výhodou je přehlednost a relativně nenáročná údržba. Naopak nevýhodou je to, že poskytují jenom hrubé a většinou předem plánované hodnoty a nikoli hodnoty v aktuálním čase. Využijeme je tehdy, máme-li omezené množství zdrojů, malé závislosti na kritických zdrojích mezi jednotlivými projekty a nepotřebujeme-li znát přesné hodnoty. Příkladem tabulky alokace zdrojů je obrázek 4.3.

10

Keep It Stupid Simple – viz http://people.apache.org/~fhanik/kiss.html

21

Obrázek 4.3: Příklad říklad tabulky zdrojů zdro s přibližnými hodnotami, převz řevzato z [8] Instalované softwarové balíky poskytují mnohem rozsáhlejší funkcionalitu v širším kontextu projektového řízení. ízení. Dokážou pracovat s reálnými daty (a tedy ne jen odhady jako v případě tabulek), umožňují ují plánování a optimalizaci zdrojů zdroj na delší období a lze je využít pro větší v množství projektů. ů. Nevýhodou je ppředevším edevším jejich složitost na obsluhu – aby poskytovaly požadovaná data, je třeba řeba je neustále udržovat aktuální, a obecn obecně není jednoduché získat pohled v takové přehlednosti, ehlednosti, kterou nám poskytují tabulky. Mezi nejznámější ější nástroje toh tohoto typu patří MS Project nebo jeho open-source open alternativa OpenProj. Webové produkty vycházejí z předcházející edcházející kategorie, ale poskytují více možností a rychleji se rozvíjejí díky tomu, že jsou typicky distribuovány jako služby (software (software as a service, SaaS). S instalovanými balíky se dají srovnat také rozsahem funkcionality i nevýhodami ve formě složité obsluhy. Zástupci této kategorie jsou například nap íklad Serena, Zoho Projects, Projects on Demand (webová varianta OpenProj), Innotas, AtTask, AtTask Planview a mnohé další. dalš Produkty spadající do kategorie rozsáhlých softwarových balíků balíků se již v žádném případě neomezují pouze na výřez řez problém problémů řízení portfolia – jsou to vyspělé ělé nástroje na celostní řízení projektových portfolií tfolií jakékoli velikosti s bohatými možnostmi integrace. ace. Nevýhodou jsou samozřejmě náklady na implementaci a údržbu, a to jak finanční, tak časové. časové Tyto rozsáhlé balíky poskytují například říklad společnosti spole nosti CA (Clarity), Compuware (Changepoint) nebo Oracle (Primavera). I v této kategorii platí, že se výrobci softwaru soft snaží přiblížit řiblížit zákazníkovi a nabízet své produkty jako služby [11]. [11] Nyní se vrátíme ke čtyřem č definovaným typům projektověě orientovaných spole společností a pokusíme se každému z nich přiřadit p nástroje určité kategorie. V případě řípadě spole společností prvního kvadrantu je nasnadě, ě, že využijí improvizovaných nástroj nástrojů – přesně ř ě totiž odpovídají jejich požadavku vyřešit ešit aktuální problém a ned nedělá lá jim potíže jistá neopakovatelnost jejich použití. Pro společnosti nosti druhého kvadrantu (malé s rozvinutým projektovým prostředím) jsou již naopak tyto nástroje nevyužitelné – zejména proto, že jim nejsou schopny vyřešit řešit sdílení zdrojů napříč 22

projekty, ani jim nepodávají obrázek v horizontu týdnů nebo měsíců dopředu. Vezmeme-li do úvahy velikost takových společností a požadavek na finanční úsporu, můžeme považovat za pravděpodobné, že využijí druhé kategorie nástrojů, tedy tabulek zdrojů. Společnosti třetího kvadrantu (velké s rozvíjejícím se projektovým prostředím) se budou již poohlížet po komplexních nástrojích. Tabulky zdrojů jim již pravděpodobně nebudou stačit, jelikož vzhledem k velikosti firmy budou ztrácet na přehlednosti a velice složité bude udržet jejich aktuálnost. Takové společnosti se budou poohlížet po řešení, které bude standardizovat problém napříč projektovým prostředím a bude poskytovat podporu klíčovým procesům, použijí tedy zřejmě produkty z kategorií instalovaných balíků nebo webových produktů. U velkých, rozvinutých společností ve čtvrtém kvadrantu nebude překvapením, že budou volit z kategorie rozsáhlých softwarových balíků, které budou jako jediné schopny dostát kritickým požadavkům na výkon, integraci a komplexní podporu řízení projektů a portfolií. Hrubé grafické znázornění vztahu různých typů projektových společností a kategorií nástrojů poskytuje obrázek 4.4.

Obrázek 4.4: Vztah typů projektově orientovaných společností a nástrojů na alokaci zdrojů napříč projekty Shrneme-li tuto kapitolu, musíme opět poukázat na fakt, že výběru nástroje musí nutně předcházet analýza potřeb dané společnosti. My jsme si problém metody výběru ukázali obecně pomocí popisu typů projektově orientovaných společností a pokusili jsme se přiřadit jim odpovídající nástroje. Dle názoru autora je při výběru vždy nutné soustředit se na přidanou hodnotu (value added), kterou nám nástroje mohou poskytnout – cílem by vždy mělo být zabránit přehnaným závazkům nebo naopak nedostatečnému vytížení zdrojů a předejít zbytečným sporům. Mnohdy je výhodnější dle Paretova principu11 dosáhnout osmdesáti procent

11

Více viz http://www.bsu.edu/libraries/ahafner/awh-th-math-pareto.html

23

výsledku (například tím, že alokace zdrojů bude do určité míry odhadovaná) a časově přespříliš nezatížit projektové oddělení. K výběru nástroje na alokaci zdrojů napříč projekty se vrátíme v další kapitole, kdy již budeme problém řešit pro konkrétní společnost.

24

5

Alokace zdrojů napříč projekty v prostředí konkrétní společnosti

Praktická část této práce navazuje na teoretické poznatky a východiska předcházejících kapitol a řeší problém alokace zdrojů napříč projekty v konkrétní IT společnosti.

5.1

Popis prostředí konkrétní společnosti

Autor se na praktickém řešení problému alokace zdrojů podílel ve firmě IBA CZ, s.r.o. v rámci studentské stáže Interim Project oboru SSME Fakulty informatiky Masarykovy univerzity. Téma a zaměření stáže bylo Asistent projektového manažera, v rámci kterého se bylo možno zevrubně seznámit s modelem, procesy a fungováním projektového oddělení ve firmě. IBA CZ je českou pobočkou mezinárodní skupiny IBA Group, která je jedním z největších dodavatelů ICT služeb ve střední a východní Evropě12. Samotná česká pobočka čítá přes sto zaměstnanců a specializuje se především na vývoj profesionálních portálových aplikací na platformě Java EE. Firma zaujímá s 18letou tradicí pevné místo na českém trhu, mezi zákazníky společnosti patří například telekomunikační operátoři a bankovní instituce. IBA CZ má maticovou, plochou organizační strukturu a silnou projektovou kulturu. Jedna projektová kancelář čítá okolo šesti projektových manažerů, kteří vedou souběžně asi deset projektů, na kterých zaměstnává okolo šedesáti vývojářů a jiných technických pracovníků. Na projektech, které jsou jak interní, tak externí povahy, je přiřazena většina zaměstnanců – často na více projektech současně, někteří z nich také ve více projektových rolích. Projekty se liší svým rozsahem od několikaměsíčních interních projektů, přes rozsáhlé studie proveditelnosti až po komerční projekty s rozpočtem v řádu miliónů korun a několikaletou délkou trvání. I když se společnost orientuje na komplexní dodávku produktů a služeb, je část zaměstnanců alokována na projektech rakouské pobočky firmy IBM. Projekty jsou realizovány s využitím několika málo společných platforem, nicméně každý projekt je technicky komplexní a obsahuje aplikace přizpůsobené na míru konkrétním klientům. Společnost je držitelem stupně 4 standardu kvality organizace práce CMMI13 a několika ISO certifikací. Navážeme-li na předchozí kapitolu, ve které jsme rozdělili typy projektově orientovaných IT společností, můžeme s využitím faktů z předchozího odstavce zařadit firmu IBA CZ zhruba tak, jak je to ilustrováno na obrázku 5.1. Pokud se jedná o velikost, společnost lehce překračuje kritérium sta zaměstnanců, které jsme si stanovili v předcházející kapitole. Vyspělostí projektové orientace a mírou standardizace se jedná o spíše projektově vyspělou společnost, která se zabývá komplexními úkoly v rámci projektového portfolia a snaží se o soustavnou optimalizaci procesu řízení projektů. Společnost se tedy nachází ve čtvrtém kvadrantu s přesahy do druhého a třetího, z čehož vyplývají požadavky na nástroj pro alokaci zdrojů napříč projekty. Můžeme říci, že se společnost bude orientovat na komplexní nástroje pro správu projektových portfolií, ovšem bude klást důraz na jednoduchá řešení, případně hotové softwarové balíky s možností následné úpravy na míru. 12 13

Více viz http://www.ibacz.eu/-O-nasCapability Maturity Model Integration, více viz například http://www.sei.cmu.edu/cmmi/

25

Obrázek 5.1: Zařazení IBA CZ do typů projektově orientovaných společností

5.2

Definice projektu

Analýza a návrh nástroje byly realizovány v rámci projektu stážisty na téma Efektivní řízení zdrojů v rámci portfolia, jehož cílem bylo zavedení plánování zdrojů napříč projekty od konkrétního data. Projekt byl zadán vedoucím projektové kanceláře a autor této práce byl pověřen jeho vedením. V průběhu projektu se na revizi řešení, konzultaci i následné implementaci podílelo několik zaměstnanců společnosti – analytická a specifikační část projektu však byla plně v kompetenci stážisty. K realizaci projektu byly využity některé rozšířené metodiky a nástroje projektového řízení, analýzy a návrhu systémů, převážně přejaté ze zdrojů [1], [2], [3] a [6]. Mezi tyto metodiky, které popíšeme podrobněji dále v práci, patří: • • • • •

Metoda logického rámce Rozpis prací PERT Kritická cesta Analýza rizik

Projekt byl definován pomocí metody logického rámce (logical framework), která slouží k modelování, kontrole a vyhodnocení vývojových projektů [6, str. 64]. Metoda je používána v širokém spektru projektů, mimo jiné je vyžadována u programů a projektů Evropské komise [22, str. 57]. Základem metody je samotný dokument logického rámce, který tvoří tabulka o čtyřech řádcích a čtyřech sloupcích. Sloupce popisují klíčové elementy projektového plánu, což jsou hierarchicky seřazené projektové cíle (tzv. sloupec intervenční nebo také strom cílů), externí faktory nutné k úspěšnému splnění projektu (sloupec vnějších předpokladů a rizik) a způsoby hodnocení úspěšnosti jednotlivých projektových výstupů (sloupce objektivně ověřitelných ukazatelů a zdrojů k jejich ověření). Řádky naproti tomu představují události, které v projektu nastanou v průběhu jeho realizace – jsou to záměr projektu, cíl projektu, výstupy projektu a konečně projektové aktivity – viz následující tabulka: 26

Tabulka 5.1: Popis dokumentu logického rámce Sloupec intervenční (strom cílů)

Objektivně ověřitelné ukazatele

Zdroje informací k ověření

Záměr projektu14

Specifikuje, jak bude měřeno splnění záměru projektu (v rovině kvality, kvantity a času)

Specifikuje, kde, kdy a kým budou získány informace o objektivně ověřitelných ukazatelích (např. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy)

Specifikuje, jak bude měřeno splnění cíle projektu (v rovině kvality, kvantity a času)

Specifikuje, kde, kdy a kým budou získány informace o objektivně ověřitelných ukazatelích (např. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy)

Nezbytné předpoklady (mimo naši kontrolu), které musí být dodrženy pro splnění záměru projektu (v případě splnění cíle)

Specifikuje, jak bude měřeno splnění výstupů projektu (v rovině kvality, kvantity a času)

Specifikuje, kde, kdy a kým budou získány informace o objektivně ověřitelných ukazatelích (např. kde a kdy budou uloženy zprávy, statistiky a jiné výstupy)

Nezbytné předpoklady (mimo naši kontrolu), které musí být dodrženy pro splnění cíle projektu (v případě splnění výstupů)

Výčet měřitelných vstupů nezbytných pro zabezpečení aktivit projektu

Časový rámec každé z aktivit projektu

Nezbytné předpoklady (mimo naši kontrolu), které musí být dodrženy

Specifikuje důvod realizace projektu, k čemu chce projekt přispět v rámci firemních cílů

Cíl projektu Specifikuje, čeho chceme konkrétně dosáhnout, přímý užitek po úspěšné realizaci projektu

Výstupy projektu Specifikuje, jak chceme výsledku dosáhnout, konkrétní odevzdané produkty nebo služby

Aktivity projektu Specifikuje konkrétní úkoly, které je třeba 14

Vnější předpoklady / rizika

Oproti dokumentu logického rámce popisovanému ve zdrojích [6] a [22] jsou v námi používané verzi rozdílně pojmenovány buňky záměr projektu a cíl projektu. Naše pojmenování vychází z potřeby lépe rozlišit mezi záměrem, nad jehož splnění nemáme jako řešitelé projektu přímou kontrolu a cílem (cíli), na jehož naplnění přímo závisí úspěch projektu.

27

splnit pro splnění výstupů

pro splnění výstupů projektu (v případě splnění aktivit)

Předběžné vnější předpoklady, které musí být naplněny, aby mohla začít samotná realizace projektu

Jak již bylo řečeno, dokument umožňuje ve fázi plánování nejen projekt definovat, ale následně i ověřit konzistenci jeho záměru, cílů, výstupů a aktivit. Při tvorbě logického rámce postupujeme nejprve shora dolů postupným vyplněním stromu cílů, předpokladů a rizik a nakonec objektivně ověřitelných ukazatelů. Verifikace (čtení) logického rámce probíhá naopak po řádcích a směrem zdola nahoru – ptáme se například, zdali při splnění stanovených výstupů, jejich ověření pomocí objektivně ověřitelných ukazatelů a dodržení vnějších předpokladů budeme schopni splnit cíl projektu. V následující tabulce je zobrazen zkrácený logický rámec našeho projektu: Tabulka 5.2: Logický rámec projektu Efektivní řízení zdrojů v rámci portfolia Sloupec intervenční (strom cílů)

Objektivně ověřitelné ukazatele

Zdroje informací k ověření

Záměr projektu

Celková utilizace zdrojů na komerčních projektech alespoň 60% (měřeno 3 měsíce zpětně)

Systém pro evidenci docházky, tiketovací systém

Plán alokace lidských zdrojů na tři měsíce dopředu

Vytvořený nástroj pro plánování zdrojů

Efektivní řízení zdrojů v rámci portfolia

Cíl projektu Zavedení plánování zdrojů od 1. 2. 2011

Výstupy projektu • vytvořen harmonogram

• existuje dokument ve formátu MS Project,

• • • • 28

projektová wiki tiketovací systém procesní mapa interní

Vnější předpoklady / rizika

• dostatečná motivace členů projektové kanceláře k používání nástroje

• dostatečná motivace projektových manažerů a

• • • •

zavedení analyzovány případy užití specifikován nástroj definován proces realizován workshop

• • •

•

Aktivity projektu • odhad časové náročnosti aktivit • vytvoření WBS • kick-off meeting • identifikace případů užití • analýza případů užití • analýza současného stavu • definice nových požadavků na nástroj • vytvoření nástroje • identifikace zodpovědných role • definice procesu • příprava obsahu workshopu • příprava termínu

schváleno schváleny případy užití schválena definice nástroje proces zařazen do procesní mapy projektové kanceláře záznam o docházce workshopu

dokumentace projektové kanceláře

Vstupy na úrovni aktivit

Časový rámec aktivit

• lidské zdroje z projektové kanceláře • výstup ze status meetingů projektové kanceláře • přístup k současnému nástroji pro řízení lidských zdrojů • lidské zdroje vývojářů • vývojové a testovací prostředí • informace týkající se procesu od projektových manažerů • zasedací místnost, vybavení a lidské zdroje pro realizaci workshopu

29

• analýza a návrh nástroje listopad – prosinec 2010 • vytvoření nástroje leden 2011 • definice procesu leden 2011 • realizace workshopu přelom ledna a února 2011

ostatních pracovníků v zodpovědných rolích k zavedení plánování

• možnost dostatečného vhledu do problematiky rolí, utilizace zdrojů • účast všech PM na závěrečném workshopu • dostatek zdrojů (projektová kancelář, technické oddělení, vývojáři)

• zajištění zdrojů • realizace workshopu

Předběžné podmínky • souhlas PM s prací na projektu • přístup k základním nástrojům (tiketovací systém, wiki)

Jak můžeme vidět, jsou pomocí logického rámce definovány hlavní fáze projektu, kterými jsou vytvoření harmonogramu zavedení plánování, analýza případů užití, specifikace nástroje a vytvoření procesu – těmto se budeme věnovat na nadcházejících stranách. V rámci tvorby logického rámce byla ale učiněna rovněž analýza rizik – v první řadě došlo k odvození rizik na základě předpokladů ve čtvrtém sloupci logického rámce, následně byla rizika ohodnocena podle pravděpodobnosti projevení a míry jejich dopadu15. Výsledek analýzy rizik popisuje tato tabulka: Tabulka 5.3: Analýza a hodnocení rizik projektu Popis rizika

Pravděpodobnost

Míra dopadu

Členové projektové kanceláře budou nedostatečně nízká motivováni k používání nástroje

vysoká

Projektoví manažeři a ostatní pracovníci nízká v zodpovědných rolích budou nedostatečně motivováni k zavedení plánování

střední

Autor bude mít nedostatečnou možnost vhledu do nízká problematiky projektových rolí ve firmě a samotného procesu utilizace zdrojů

vysoká

Závěrečného workshopu se nezúčastní všichni střední projektoví manažeři

nízká

Na realizaci nástroje nebude vzhledem k prioritě vysoká projektu k dispozici dostatek technických zdrojů

vysoká

15

Vzhledem k rozsahu projektu byla použita jednoduchá třístupňová stupnice s hodnotami: nízká, střední a vysoká

30

Na základě analýzy byly učiněny kroky pro zmírnění nebo odstranění popsaných rizik. Rizikem, které šlo zcela odstranit včasnou komunikací, je problém vhledu autora do problematiky. Ostatní rizika se zcela odstranit nepodařilo, ale byly učiněny relativně úspěšné pokusy o jejich zmírnění – v případě motivace projektových manažerů k používání nástroje a samotnému zavedení plánování posloužila zahajovací schůzka (kick-off) se všemi zainteresovanými stranami, také byl včas naplánován závěrečný workshop. Jak vyplývá z tabulky 5.4, nejzávažnějším rizikem projektu byla jeho nízká priorita a s ní související možný nedostatek zdrojů, zejména technických – ke zmírnění rizika pomohlo včasné informování vedoucího projektové kanceláře o poptávaných zdrojích v rámci konkrétních časových intervalů realizace projektových výstupů.

5.3

Rozpis prací a harmonogram projektu

Pro vytvoření harmonogramu projektových prací bylo nejprve nutné vytvořit rozpis prací neboli WBS, o kterém jsme již mluvili v první kapitole. V našem případě, díky existenci logického rámce, již mohl být rozpis prací přímo odvozen – nejedná se totiž o nic jiného než o strom diskrétních projektových aktivit, které již ale byly popsány ve stromu cílů našeho logického rámce. Rozpis prací má v tomto případě tři úrovně – cílů, výstupů a aktivit. V druhém kroku byly stanoveny závislosti mezi jednotlivými aktivitami (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) a následně učiněn úvodní odhad jejich časové náročnosti – vzhledem k doménovým a technickým specifikám autor upřednostnil využití expertního posudku před jinými metodami. Samotné odhadování probíhalo s využitím kombinace technik plánovacího pokeru (planning poker) a PERT (program evaluation and review technique). Technika plánovacího pokeru, často používaná v metodice Scrum, předepisuje některá pravidla pro odhadování aktivit ve více účastnících16. Mezi nejdůležitější z nich patří časově omezená diskuze o každé odhadované položce, odhad nezávislý na ostatních účastnících a následná obhajoba extrémních hodnot – cílem je shoda všech účastníků na výsledném odhadu. Dle techniky PERT17 odhadoval každý z účastníků tři různé hodnoty: pro optimistické, normální a pesimistické očekávání průběhu každé z aktivit – z těchto tří hodnot pak byla podle vzorce vypočtena jejich očekávaná doba trvání. Aktivity, jejich vzájemné závislosti a odhadnuté doby trvání byly následně zaneseny do Ganttova diagramu plánovacího nástroje MS Project. Po vložení data zahájení první z aktivit a plánovaného úvazku autora práce a vývojáře na projektových pracích byla s pomocí nástroje odvozena očekávaná data pro jednotlivé projektové milníky. Identifikována byla rovněž kritická cesta projektu (critical path) [3]. Výsledný projektový harmonogram projektu je zobrazen na obrázku 5.2 – kritická cesta je v něm zobrazena červeně:

16 17

Více viz http://renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf Více viz http://www.netmba.com/operations/project/pert/ nebo [3]

31

Obrázek 5.2: Harmonogram projektu v nástroji MS Project s vyznačenou kritickou cestou

32

6

Analýza a návrh nástroje

V této kapitole popíšeme průběh analýzy a návrhu nástroje pro řízení alokace zdrojů napříč projekty ve společnosti IBA CZ. Popsán bude nejprve postup vytvoření případů užití, funkčních i nefunkčních požadavků na nástroj, následně přejdeme ke specifikaci nástroje a definici implementačních úkolů.

6.1

Analýza požadavků a případů užití

Sběr požadavků a jejich analýza probíhala formou analytických schůzek autora se zainteresovanými stranami – těmi byli dva projektoví manažeři, vedoucí projektové kanceláře a zástupce oddělení tzv. presale aktivit, kteří využívají lidské zdroje k realizaci různých obchodních příležitostí, tendrů a jiných předprodejních aktivit. V rámci analýzy byly identifikovány následující oblasti zájmu a rozhraní s dalšími útvary ve firmě: • • • •

informace o alokaci lidských zdrojů v různém měřítku z různých perspektiv informace o kapacitním plánu / bazénu lidských zdrojů pro vedení firmy revize a editace alokace zdrojů v krátkodobém a střednědobém měřítku žádosti o lidské zdroje z organizačních útvarů mimo projektovou kancelář18

V rámci analytických schůzek vznikl zápis, který byl v dalším kroku podroben analýze textu s využitím nástroje Visual Paradigm for UML19. V rámci této analýzy byli podle výskytu klíčových slov identifikováni aktéři (z podstatných jmen) a stejným způsobem také samotné případy užití na vysoké úrovni (ze sloves). Výstup z této analýzy pak byl za pomocí nástroje převeden do diagramu případů užití (use case diagram), který je přiložen na obrázku 6.1. Identifikováni byli tito aktéři přistupující k systému: • • •

projektový manažer (project manager, PM) vedoucí projektové kanceláře (overall project manager, OPM) zástupce oddělení předprodejních aktivit (presale)

Identifikovány byly tyto případy užití20: •

UC-1: HledejZdroje PM/presale hledá nevytížené nebo neúplně vytížené zdroje v konkrétní roli od konkrétního data nebo týdne

18

Tato oblast zájmu byla nakonec vyřazena z analýzy, jelikož svým je svým rozsahem nad rámec řešeného problému. 19 Více o nástroji viz http://www.visual-paradigm.com/product/vpuml/ 20 Pro potřeby přehlednosti této práce je budeme označovat zkratkami, které v původní dokumentaci nebyly obsaženy

33

•

UC-2: ZjistiDostupnostZdroje PM/presale zjišťuje kdy nejdříve, popřípadě v jakém intervalu je dostupný konkrétní zaměstnanec (nezávisle na jeho roli)

•

UC-3: ZobrazPrehledZdrojuProjektu OPM si zobrazuje přehled zdrojů podle projektů nebo projektových manažerů

•

UC-4: UpravAlokaciZdroju OPM upravuje alokaci jednotlivých zdrojů na projektech v měřítku ekvivalentu plné pracovní doby (full-time equivalent, FTE)21

•

UC-5: ZobrazStrednedobeInformaceoAlokaci OPM si zobrazuje informace o utilizaci zdrojů v jednotlivých rolích v perspektivě několika měsíců dopředu

Obrázek 6.1: Diagram případů užití nástroje Dalším logickým krokem nyní bylo rozepsat výše uvedené případy užití – autor však v této fázi cítil, že mu analytické schůzky nepřinesly dostatečné množství dat pro dokončení analýzy. Po konzultaci s projektovým manažerem tedy přistoupil ještě k dodatečnému sepsání požadavků na nástroj, které nebyly předány ze strany zákazníka při započetí projektu. Výsledné požadavky byly dodatečně odsouhlaseny zákazníkem a sloužily k dalšímu upřesnění případů užití a detailnějšímu návrhu obrazovek. Definované funkční požadavky na nástroj popisuje následující tabulka: Tabulka 6.1: Funkční požadavky na nástroj REQ-1

Systém bude zobrazovat přehled zdrojů podle projektů

Popis

V nástroji bude možno zobrazit celkový přehled zdrojů filtrovaný podle projektů – vybrat je možno jeden nebo více projektů, přičemž se zobrazí všichni zaměstnanci, kteří jsou v aktuálním časovém okamžiku přiřazeni na vybraný projekt nebo projekty. Druhou možností je omezení výpisu podle

21

Tento případ užití byl vyřazen z další analýzy, jelikož byl triviálně splněn existencí nástroje na alokaci zdrojů pro jednotlivé projekty, viz analýza současného stavu

34

kategorie projektu – opět je možno vybrat jednu nebo více z definovaných kategorií (komerční, ibm, investiční, servisní, operační). REQ-2

Systém bude zobrazovat přehled zdrojů podle lidí

Popis

Nástroj bude orientován na zobrazení podle zaměstnanců – ke každému z nich budou zobrazeny jeho projektové role (informace bude přebírána z aktuálního přiřazení na role aktivních projektů), seznam projektů, na kterých má aktuálně nenulový úvazek a údaj o celkovém FTE pro každou časovou jednotku (den, týden) vzniklý součtem jeho úvazků na jednotlivých projektech.

REQ-3

Systém bude zobrazovat přehled zdrojů podle rolí

Popis

Nástroj bude umožňovat omezit výpis zaměstnanců podle rolí – uživatel si může vybrat jednu nebo více rolí, přičemž se zobrazí všichni zaměstnanci, kteří jsou v aktuálním časovém okamžiku přiřazeni na jakémkoli projektu v dané roli nebo rolích.

REQ-4

Systém poskytne dvě měřítka k zobrazení FTE zdrojů – denní (implicitní) a týdenní

Popis

Nástroj bude umožňovat změnu časového měřítka pro výpis celkového FTE zaměstnanců. Ve výchozím stavu (denní měřítko) budou zobrazeny údaje všech dnů aktuálního měsíce, v případě přepnutí zobrazení na týdenní měřítko budou zobrazeny údaje po jednotlivých týdnech v rámci aktuálního a dvou následujících měsíců. Údaj o celkovém FTE a rozložení úvazku po projektech v každém týdnu bude vypočten jako aritmetický průměr pracovních dní daného týdne.

REQ-5

Systém bude poskytovat kapacitní plán zdrojů podle jejich aktuálního přiřazení na komerčních projektech

Popis

Nástroj bude pro jednotlivé týdny poskytovat souhrnné informace o kapacitním plánu lidských zdrojů ve firmě. V přehledu bude výpis rozdělen podle rolí – pro každou z nich bude po jednotlivých týdnech zobrazena informace o poměru jejich celkového úvazku na komerčních a servisních projektech vůči jejich maximálnímu možnému úvazku (tzv. utilizace zdrojů na projektech). Příklad: Máme-li ve firmě 30 vývojářů, pak jejich maximální možný úvazek je za týden 150 MD. Pokud sečteme hodnoty úvazků vývojářů na komerčních a servisních projektech za celý týden, dostaneme hodnotu 89 MD. Celková utilizace zdrojů na projektech je poté 59,3% Přehled bude zobrazen v tabulce s týdny současného a dvou následujících měsíců. Uživatel se může posouvat v čase po měsících směrem dopředu i dozadu. Tabulka bude doplněna o údaje o váženém průměru utilizace zdrojů na projektech napříč všemi rolemi a průměrné utilizaci pro danou roli za sledované období. Kromě přehledu ve formě tabulky bude systém obsahovat také spojnicový graf průběhu utilizace zdrojů na projektech v jednotlivých rolích.

35

Výčet rolí bude odpovídat požadavků REQ-7. REQ-6

Systém bude zobrazovat informace o celkovém úvazku zaměstnanců na jednotlivých aktivních projektech

Popis

Nástroj bude pro jednotlivé týdny poskytovat informace o celkovém úvazku jednotlivých aktivních projektů. Zobrazeny budou všechny aktivní projekty, pro které bude po jednotlivých týdnech zobrazen celkový úvazek alokovaných zaměstnanců souhrnně ve všech rolích – hodnota vznikne jako součet všech úvazků jednotlivých členů týmu ve všech dnech daného týdne. Přehled bude zobrazen v tabulce s týdny současného a dvou následujících měsíců. Uživatel se může posouvat v čase po měsících směrem dopředu i dozadu. Doplněn bude také celkový součet úvazku všech projektů pro jednotlivé týdny a přepočet na průměrný denní úvazek.

Definované nefunkční požadavky na nástroj popisuje následující tabulka: Tabulka 6.2: Nefunkční požadavky na nástroj REQ-7

Systém bude pracovat s konkrétním výčtem projektovými rolí

Popis

V systému bude obsažena tato množina projektových rolí: vývojář, projektový manažer, tester, analytik, presale konzultant, architekt

REQ-8

Systém bude napojen na tiketovací systém JIRA22

Popis

Systém bude získávat údaje o alokaci zaměstnanců a jejich úvazcích na jednotlivých projektech ze systému JIRA

Teprve v tomto okamžiku bylo možno přistoupit k rozepsání jednotlivých případů užití, které spolu s požadavky sloužily jako podklady pro specifikaci nástroje. Případy užití obohacené o vstupní podmínku (musí být splněna, aby mohl být případ užití v nástroji realizován), tok událostí (uspořádaný seznam událostí iniciovaný ze strany uživatele nebo systému) a výstupní podmínku (musí být splněna po realizaci případu užití) popisuje následující tabulka: Tabulka 6.3: Podrobně rozepsané případy užití na vysoké úrovni UC-1

PM/presale hledá nevytížené nebo neúplně vytížené zdroje v konkrétní roli od konkrétního data nebo týdne

Vstupní podmínka

Uživatel je v roli PM/presale

Tok událostí

1. Systém zobrazí stránku s přehledem zdrojů 2. Uživatel si vybere konkrétní role nebo roli, ve které chce zdroje vyhledat 3. Uživatel si vybere denní nebo týdenní měřítko zobrazení 4. Systém uživateli vrátí přehled alokace zdrojů pro vybranou roli a měřítko

22

Tiketovací systém, v rámci kterého jsou upravovány alokace zdrojů na jednotlivých projektech, více viz analýza současného stavu dále v kapitole

36

5. KDYŽ je zvoleno denní měřítko, uživatel si může zvolit jeden konkrétní měsíc, pro který chce přehled zobrazit 6. KDYŽ je zvoleno týdenní měřítko, uživatel si může zvolit tři konkrétní měsíce, pro které chce přehled zobrazit 7. Systém uživateli vrátí přehled alokace zdrojů pro konkrétní období se zachováním rolí a měřítka vybrané v krocích 2 a 3 Výstupní podmínka

Uživatel má možnost vynulování filtru a návratu do výchozí podoby přehledu

UC-2

PM/presale zjišťuje kdy nejdříve, popř. v jakém intervalu je dostupný konkrétní člověk (nezávisle na jeho roli)

Vstupní podmínka

Uživatel je v roli PM/presale

Tok událostí

1. Systém zobrazí stránku s přehledem zdrojů, na které může uživatel provádět operace popsané v UC-1 2. Uživatel řadí systémem vrácené zdroje podle jejich jména 3. Systém uživateli vrátí přehled alokace zdrojů na základě zvoleného řazení

Výstupní podmínka

Uživatel má možnost vynulování filtru a návratu do výchozí podoby přehledu

UC-3

OPM si zobrazuje přehled zdrojů podle projektů nebo projektových manažerů

Vstupní podmínka

Uživatel je v roli OPM

Tok událostí

1. Systém zobrazí stránku s přehledem zdrojů, na které může uživatel provádět operace popsané v UC-1 a UC-2 2. Uživatel filtruje systémem vrácené zdroje podle jejich aktuálního přiřazení na specifickém projektu/projektech nebo projektech konkrétní kategorie (investiční, komerční, IBM projekty) 3. KDYŽ je zvolen filtr specifických projektů, systém vrátí uživateli přehled alokace zdrojů na vybraném projektu / vybraných projektech 4. KDYŽ je zvolen filtr projektové kategorie, systém vrátí uživateli přehled alokace zdrojů na všech projektech vybrané kategorie

Výstupní podmínka

Uživatel má možnost vynulování filtru a návratu do výchozí podoby přehledu

UC-5

OPM si zobrazuje informace o kapacitním plánu zdrojů v perspektivě několika měsíců

Vstupní podmínka

Uživatel je v roli OPM

Tok událostí

1. Systém zobrazí stránku s přehledem o kapacitním plánu lidských zdrojů v jednotlivých rolích 2. Uživatel klikne na záložku spotřeba zdrojů na projektech 3. Systém zobrazí stránku s přehledem o spotřebě zdrojů na jednotlivých projektech

37

Výstupní podmínka

6.2

Uživatel má možnost návratu na stránku s kapacitním plánem lidských zdrojů

Analýza současného stavu

V této podkapitole popíšeme nástroje používané v IBA CZ k řízení projektů, projektového portfolia a zejména alokaci zdrojů ve stavu, v jakém byly před započetím projektu. Základním kamenem pro podporu projektového řízení a příbuzných procesů je tiketovací nástroj JIRA23, který je používán pro řízení projektových požadavků, výstupů, úkolů, řízení kvality, vykazování práce a mnoho dalšího. Vzhledem k silné projektové a procesní orientaci firmy je v něm vedena většina dennodenních aktivit společnosti. Mezi další podpůrné nástroje patří wiki nástroj Confluence24, systém pro správu dokumentů Alfresco25 a evidence docházky ve formě vlastní aplikace na portálu Liferay26 (viz obrázek 6.2). V aktuální době je ve vývoji systém pro evidenci znalostí a schopností pracovníků, rovněž ve formě portálové aplikace. Vzhledem k tomu, že v nástroji JIRA neexistuje adekvátní komponenta pro řízení projektového portfolia, vznikl v rámci interního projektu s názvem Insight plugin k tomuto nástroji, který měl za úkol sestavit databázi projektů a vytvořit přehledovou nástěnku (dashboard) pro zobrazení a agregaci portfolia projektů řešených v IBA CZ, včetně administračního rozhraní. Mezi další iniciativy patřilo napojení tiketovacího nástroje na infrastrukturu řízení projektů, účetní systém, firemní adresář osob a další.

Obrázek 6.2: Nástroje pro podporu projektového řízení, IBA CZ

23

Viz http://www.atlassian.com/software/jira/ Viz http://www.atlassian.com/software/confluence/ 25 Viz http://www.alfresco.com/ 26 Viz http://www.liferay.com/ 24

38

V rámci pluginu Insight byla rovněž vyvinuta komponenta pro alokaci zdrojů na projektech – ta umožňovala jednotlivým zaměstnancům na projektu přiřazovat úvazky (vyjádřené v měřítku FTE) pro konkrétní pracovní dny. Obsahovala rovněž jednoduchý nástroj pro alokaci zdrojů napříč projekty (tzv. Resource Allocation Report), který ovšem nebyl používán. Jedním z cílů analýzy bylo zjistit, proč tomu tak je. Nástroj ve své původní podobě poskytoval přehled projektů, k nim přiřazených pracovníků, výpis jejich rolí, projektových manažerů a zejména informaci o celkové alokaci jednotlivých zdrojů souhrnně napříč projekty. Veškeré informace byly zobrazeny na jedné stránce včetně grafického zobrazení alokace zdrojů v jednotlivých dnech – viz obrázek 6.3.

Obrázek 6.3: Původní stav nástroje Resource Allocation Report

39

Analýza současného stavu nástroje přinesla tyto závěry: • • • •

• • • • • • •

6.3

je zaměřen především na projekty, méně na jednotlivé osoby a role neumí zobrazit alokaci zdrojů v týdenním měřítku a obecně v granularitě pro vedoucího projektové kanceláře a vedení firmy v implicitním zobrazení obsahuje příliš mnoho informací – nadbytečné jsou informace o stavu projektu, projektové kategorii a projektovém manažerovi v implicitním zobrazení je tabulka zdrojů rozbalena – obsahuje jeden řádek pro každý projekt každého uživatele, navíc je takto seřazena podle uživatele a tedy velice nepřehledná v implicitním zobrazení je grafické znázornění alokace zdrojů příliš obsáhlé, vystupuje mimo obrazovku pro smysluplné zobrazení musí mít uživatel přístup ke všem projektům v systému – pokud je například vedoucím třech projektů, uvidí v tabulce pouze tyto tři projekty chybí možnost filtrování / změny zobrazení přímo v tabulce – nastavení parametrů zobrazení je provedeno jednorázově před zobrazením nástroje chybí možnost úpravy alokace zdrojů přímo v nástroji chybí jakékoli celkové součty, souhrnné informace o FTE a utilizaci zdrojů v systému JIRA nejsou definovány některé projektové role, jako například architekt, presale a jiné v systému JIRA je nesystémově vyřešeno přidělené zaměstnanců na jednotlivé projektové role

Výběr nástroje

Na tomto místě se na chvíli vrátíme na začátek čtvrté kapitoly, kde jsme specifikovali pozici, ve které se nachází společnost IBA CZ vzhledem k dříve definovaným typům projektově orientovaných společností. Mimo jiné bylo řečeno, že se firma „bude orientovat na komplexní nástroje pro správu projektových portfolií, ovšem bude klást důraz na jednoduchá řešení, případně na hotové softwarové balíky s možností následné úpravy na míru“27. V této souvislosti můžeme zavrhnout kategorii tabulky zdrojů s přibližnými hodnotami, která je již pro firmu této velikosti nedostačující. Vzhledem k dynamické povaze projektů budou preferovány webové nástroje, které jsou dostupné kdykoli a odkudkoli, před nástroji desktopovými. Důležitou roli v rozhodování bude hrát požadavek na integraci s tiketovacím nástrojem, do budoucna případně s dalšími systémy. Autor se v této fázi nechtěl omezovat na výběr z existujících nástrojů, proto proběhla krátká rešerše nástrojů Projects on Demand, Zoho Projects a AtTask28. Její závěry popisuje následující tabulka:

27 28

Strana 25 této práce Výběr množiny nástrojů pro rešerši byl proveden s využitím dokumentu společnosti Gartner, viz [11]

40

Tabulka 6.4: Výstupy z rešerše vybraných nástrojů Projects on Demand [23]

• obsahuje Ganntovy diagramy, síťové diagramy, tabulky získaných hodnot (earned values, EV), nástroje pro řízení násobných projektů a reportování • umožňuje zakládání bazénů zdrojů, sledování dostupnosti zdrojů, identifikaci konfliktů mezi nimi a řešení problémů přehnaného závazku • umožňuje přepínání zobrazení zdrojů – dají se zobrazit buď všechny zdroje nebo vypsat Ganntův diagram pro konkrétní zdroj • obsahuje histogramy (detaily o alokaci v grafickém zobrazení)

Zoho Projects [24], [25]

• obsahuje řízení úkolů, Ganntovy diagramy • obecně je zaměřený spíše na základní možnosti pro podporu projektového řízení a spolupráce s minimálními přesahy do řízení násobných projektů • snadno použitelný, problémem je relativní nedostatek funkcí • slabší možnosti pro řízení zdrojů a nákladů projektů

AtTask [26], [27]

• komplexní nástroj podporující projektové řízení i řízení násobných projektů • zaměřuje se na řízení cílů, časových plánů, dokumentů, zdrojů a obchodních údajů; klade důraz na komunikaci • umožňuje kapacitní plánování projektů • poskytuje rychlý přehled o dostupnosti zaměstnanců z hlediska jejich možného přiřazení na daný úkol v daném čase, automaticky vyhledává v zaměstnancích se stejnými projektovými rolemi a vyhodnocuje možné náhrady • umožňuje výpočet vhodného časového rámce pro realizaci projektu vzhledem k dostupným zdrojům

Shrneme-li výstupy rešerše, požadavky stanovené v předchozí kapitole by byly schopné zastávat dva ze tří vyjmenovaných nástrojů (Projects on Demand a AtTask). Hlavním problémem je nicméně přílišná rozsáhlost obou nástrojů – dochází zde nutně k funkčnímu překryvu se stávajícími nástroji používanými ve společnosti. Jednoduché řešení, které by umožňovalo čistě řešení problému alokace zdrojů napříč projekty, navíc s možností integrace se stávajícími nástroji, nebylo nalezeno. Proto byla po konzultaci s projektovými manažery zvolena cesta úprav na míru ve stávajícím nástroji JIRA v rámci pokračování interního projektu Insight.

41

6.4

Specifikace nástroje

Po výběru řešení následovala samotná specifikace implementačních úkolů pro úpravu stávajícího nástroje Resource Allocation Report. Tyto úkoly byly podle případů užití rozděleny do dvou vývojových iterací – v první byly připraveny k realizaci případy užití UC-1 a UC-2 a UC-3, v druhé poté případ užití UC-5. V rámci první vývojové iterace byly definovány úkoly popsané v následující tabulce: Tabulka 6.5: Implementační úkoly pro první vývojovou iteraci IST-1

Změnit umístění resource allocation reportu v JIRA

Popis

Report bude dostupný v horním menu JIRA, pod položkou Zdroje -> Zobrazení podle lidí. Z ostatních míst (záložka Insight, záložka souhrn u projektů) bude odkaz odstraněn. Právo k zobrazení nástroje budou mít všichni uživatelé v systémové roli projektový manažer, overall project manager nebo presale.

IST-2

Upravit počet a rozložení sloupců resource allocation reportu

Popis

Budou smazány sloupce stav projektu, kategorie projektu a projektový manažer, přibude naopak sloupec projektová role. Pořadí sloupců bude nastaveno takto: 1) 2) 3) 4)

Jméno Projektová role Projekt Grafické znázornění alokace zdrojů

V zobrazení podle lidí bude použito pouze jednoduché řazení podle jména (vzestupně, sestupně). IST-3

Upravit výchozí zobrazení dat v resource allocation reportu

Popis

Odstraněna bude stránka s nastavením, zobrazí se rovnou report. Ve výchozím zobrazení bude řazeno podle jména, budou se zobrazovat pouze aktivní, non-ibm projekty. Bude zapnuto týdenní měřítko. Zobrazeny budou pouze projekty, v rámci kterých má daný uživatel v daném časovém období nenulový úvazek.

IST-4

Upravit filtrování a ovládání resource allocation reportu

Popis

Budou přidány filtry pro výběr konkrétních rolí a projektů. Filtr se bude aplikovat pouze na lidi, u kterých se poté zobrazí veškeré (nefiltrované) informace. Bude zachován filtr podle kategorie projektu - ten se ale bude nově aplikovat na lidi. Zobrazováni budou tedy vždy pouze uživatelé, kteří mají v aktuálním čase nenulový úvazek na nějakém projektu vybrané kategorie. Přibude možnost měnit měřítko mezi týdenním a denním pohledem - v denním měřítku se zobrazí aktuální měsíc, v týdenním aktuální kvartál. V týdenním měřítku bude celková alokace vypočítána jako aritmetický průměr FTE v jednotlivých dnech týdne. Přibude posuvník na přesun tam a zpět v čase (po týdnech, resp.

42

měsících). Odstraněna bude možnost "seskupit podle lidí" (seskupení bude stále zapnuto). Aktuální nastavení filtrů bude ukládáno do session. IST-5

Přidat speciální znak při změně rozložení FTE na projekty

Popis

Pokud se pro daného uživatele změní rozložení FTE na projekty oproti předchozí buňce (předchozí den, týden), je tato buňka označena v rohu speciálním symbolem – hvězdičkou.

K implementačním úkolům – jmenovitě IST-2, IST-4 a IST-5 byla přiložena obrazovka grafického rozhraní načrtnutá v nástroji Balsamiq29. Její miniatura je přiložena jako obrázek 6.4:

Obrázek 6.4: Grafické rozhraní nástroje pro alokaci zdrojů napříč portfoliem V rámci druhé vývojové iterace byl definován jediný úkol, viz následující tabulka: Tabulka 6.6: Implementační úkoly pro druhou vývojovou iteraci IST-6

Přidat stránku se souhrnnými údaji o kapacitním plánu zdrojů a celkové spotřebě zdrojů na projektech v čase

Popis

Bude vytvořena stránka s dvěma záložkami, z nichž jedna bude obsahovat kapacitní plán zdrojů podle jejich rolí s tabulkovým a grafickým zobrazením údajů; druhá bude obsahovat tabulku s přehledem o spotřebě lidských zdrojů na jednotlivých aktivních projektech. Konkrétní požadavky na stránku definují požadavky REQ-5 a REQ-6 a jsou dále definovány na přiložených obrazovkách.

29

Viz http://balsamiq.com/

43

K implementačnímu úkolu olu IST-6 IST byly přiřazeny dvě obrazovky grafického rozhraní, které jsou přiloženy jako obrázky 6.5 a 6.6.

Obrázek 6.5:: Náčrt rt grafického rozhraní se pro obrazovku Kapacitní plán zdroj zdrojů Na základě vytvořených implementačních implementa úkolů bylo možné zrevidovat časový č harmonogram implementace a provéstt zpřesněnou zpř analýzu nákladů na úpravu nástroje. Upřesňujícího Upř odhadu se účastnil astnil autor práce spolu se zkušeným vývojářem, technikou plánoovacího pokeru bylo nakonec dosaženo těchto ěchto hodnot v člověkodnech30: Tabulka 6.7: Zpřesněné čaasové odhad implementačních nákladů: Implementační úkol

Časový odhad

IST-1

1 MD

IST-2

2 MD

IST-3

1 MD

IST-4

5 MD

IST-5

0,5 MD

Celkem za první iteraci

9,5 MD

IST-6 (celkem za druhou iteraci)

15 MD

30

Jedná se o odhad nákladůů čisté č implementace vývojářem

44

Celkové implementační ční náklady na úpravu nástroje tedy tvo tvořily 24,5 člově člověkodnů pro čistou implementaci, po přidání řidání idání 30% pro testování, dokumentaci a ostatní režii se vyšplhaly až na 32 člověkodnů.

Obrázek 6.6: Náčrt črt grafického rozhraní se pro obrazovku Spotřeba Spotřeba zdrojů na projektech

45

7

Závěr

V práci byla vytvořena projektová dokumentace nástroje pro sdílení zdrojů napříč portfoliem. Na základě této dokumentace nakonec došlo k samotné implementaci pod vedením autora této práce. Vzhledem k rozsahu druhé iterace bylo rozhodnuto, že v rámci konstrukční fáze projektu Efektivní řízení zdrojů napříč projekty bude realizována pouze první naplánovaná iterace. Vývoj probíhal bez větších problémů a podle stanoveného harmonogramu – pozitivní roli sehrála účast zkušeného vývojáře na implementačních úkolech, které byly dokončeny s malou rezervou oproti stanovenému plánu nákladů. Autor se věnoval testování uživatelského rozhraní nástroje před a v průběhu jeho nasazení. Výsledná aplikace je nasazena a používána v produkčním prostředí společnosti IBA CZ31. Dokladem úspěchu projektu je také zařazení konkrétních úkonů vykonávaných za pomocí nástroje do procesního rámce projektové kanceláře – mezi tyto úkony patří vyhledání volného zdroje, kontrola korektní alokace všech zdrojů v nástroji vzhledem k reálnému stavu, řešení přehnaného závazku zaměstnanců (over commitment) nebo kontrola včasného uvolnění zdrojů z projektu. Nástroj je rovněž využíván na pravidelných brífincích projektové kanceláře. V návaznosti na projekt autora této práce je počítáno s další úpravou a rozšířením možností stávajícího nástroje, mimo samotné druhé vývojové iterace zejména pro naplnění potřeb vedení společnosti a dalších organizačních útvarů mimo projektovou kancelář. Analýza a návrh řešení v této práci klade důraz především na jeho obecnost – v první řadě je provedena kategorizace společnosti a odvození jejích potřeb. Teprve poté jsou analyzovány případy užití konkrétního zákazníka, současný stav, odvozeny požadavky na nástroj a nakonec nástroj specifikován. Díky tomu lze použité řešení zobecnit a jeho části aplikovat také na další projektové společnosti podobné velikosti. Teoretické části práce rovněž poukazují na některé časté problémy týkající se problému alokace zdrojů napříč projekty nejen IT společností a jejich možná východiska.

31

Snímky obrazovky viz příloha, obrázky A.1 a A.2

46

Použité zdroje 1. Project Management Institute, Inc. A Guide To The Project Management Body Of Knowledge : PMBOK® Guide. Fourth Edition. Newtown Square, PA : Project Management Institute, Inc., 2008. 459 s. 2. PITAŠ, Jaromír, STANÍČEK, Zdenko, et al. Národní standard kompetencí projektového řízení : Webová verze. Brno : VÚT ve spolupráci s SPŘ, o.s., 2008. 275 s. Dostupné z WWW: 3. RÁČEK, Jaroslav, SOCHOR, Jiří. Studijní materiály k předmětům PA104 - Vedení týmového projektu a PB007 - Analýza a návrh systémů. Brno : Masarykova univerzita. Fakulta informatiky, 2011. 4. HUEMANN, Martina; KEAGAN, Anne; TURNER, J. Rodney. Human resource management in the project-oriented company: A review. International Journal of Project Management. 2006, 25, s. 315-323. Dostupné z WWW: . 5. ENGWALL, Mats; JERBRANT, Anna. The resource allocation syndrome: the prime challenge of multi-project management?. International Journal of Project Management. 2003, 21, s. 403-409. Dostupný také z WWW: 6. DOLEŽAL, Jan; LACKO, Branislav; MÁCHAL, Pavel, et al. Projektový management podle IPMA. Praha : Grada Publishing, a.s., 2009. 512 s. ISBN 978-80-247-2848-3. 7. SVOZILOVÁ, Alena. Projektový management. Praha : Grada Publishing, a.s., 2006. 360 s. ISBN 80-247-1501-5. 8. KRETZMAN, Peter. CTO/CIO Perspectives [online]. 16.2.2010 [cit. 2011-05-21]. Simple, more practical approaches to actual resource allocation. Dostupné z WWW: . 9. FITZGERALD, Donna. TechRepublic [online]. 2003 [cit. 2011-05-21]. The keys to resource allocation. Dostupné z WWW: . 10. DYE, Lowell D.; PENNYPACKER, James S. Managing multiple projects. New York : Marcel Dekker Inc., 2002. Project Portfolio Management and Managing Multiple Projects:Two Sides of the Same Coin?, s. 1-10. 11. STANG, Daniel B. Gartner [online]. Gartner, Inc., 2010 [cit. 2011-05-21]. Magic Quadrant for IT Project and Portfolio Management. Dostupné z WWW: .

47

12. BELOUT, Adnane; GAUVREAU, Clothilde. Factors influencing project success: the impact of human resource management. International Journal of Project Management. 2004, 22, s. 1-11. Dostupný také z WWW: . 13. ARMSTRONG, Michael. Strategic Human Resource Management : A Guide To Action. 3rd ed. London : Kogan Page, 2006. 194 s. 14. MATHIS, Robert L.; JACKSON, John H. Human Resource Management. 9th edition. Boston : South-Western College Publishing, 1999. 633 s. 15. BEARDWELL, Ian; HOLDEN, Len; CLAYDON, Tim. Human Resource Management : A Contemporary Approach. 4th ed. Leicester : Financial Times / Prentice Hall, 2003. 760 s. 16. JEREB, Janez. The Human Resource Cycle as Basis of Human Resource Development System [online]. [s.l.], 1995. 13 s. Reports - Research/Technical. Fakulteta za Organizacijske Vede Kranj. Dostupné z WWW: . 17. PINTO, J.K.; KHARBANDA, O.P. Successful project managers : Leading your team to success. [s.l.] : Van Nostrand Reinhold, 1995. 421 s 18. TURNER, J.R.; MÜLLER, R. The Project Manager’s Leadership Style as a Success Factor on Projects : A Literature Review. Project Management Journal. 2005, 36, s. 49-61. Dostupný také z WWW: . 19. VLACH, Miroslav. Na volné noze [online]. 2007 [cit. 2011-05-22]. Projektové řízení. Dostupné z WWW: . 20. KRETZMAN, Peter. CTO/CIO Perspectives [online]. 2009 [cit. 2011-05-22]. Nuts: the biggest trap of all for IT stakeholders. Dostupné z WWW: . 21. LIGHT, Matt. Practical Ways and Means [online]. 2008 [cit. 2011-05-22]. Boosting PPM Capability Maturity. Dostupné z WWW: . 22. European Commission [online]. 2004 [cit. 2011-05-22]. Aid Delivery Methods: Project Cycle Management Guidelines. Dostupné z WWW: . 23. Serena Software, Inc. Serena [online]. c2011 [cit. 2011-05-25]. Resource Management With Projects On Demand. Dostupné z WWW: . 24. ZOHO Corp. Features of Zoho Projects [online]. c2011 [cit. 2011-05-25]. Zoho Projects. Dostupné z WWW: . 25. TechMediaNetwork.com. TopTenREVIEWS [online]. 2011 [cit. 2011-05-25]. Zoho Projects 2011. Dostupné z WWW: . 48

26. AtTask, Inc. AtTask [online]. c2011 [cit. 2011-05-25]. Product Feature List. Dostupné z WWW: . 27. TechMediaNetwork.com. TopTenREVIEWS [online]. 2011 [cit. 2011-05-25]. AtTask 2011. Dostupné z WWW: < http://online-project-management-review.toptenreviews.com/attaskreview.html >.

49

A

Příloha

Obrázek A.1: Snímek obrazovky nasazeného nástroje ve výchozím zobrazení

50

Obrázek A.2: Snímek obrazovky nasazeného nástroje s filtrováním podle projektu a v týdenním měřítku zobrazení

51