UNICORN COLLEGE. Katedra informačních technologií BAKALÁŘSKÁ PRÁCE. Měření efektivity fix price fix time projektů

UNICORN COLLEGE

Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE

Měření efektivity fix price – fix time projektů

Autor BP: Jan Zeithaml Vedoucí BP: Ing. Miloš Dvořák

2013 Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Měření efektivity fix price – fix time projektů vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V……………………. dne ………..

……………….…………………………… Jan Zeithaml

Poděkování Děkuji vedoucímu bakalářské práci Ing. Miloši Dvořákovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce. Dále bych chtěl poděkovat managementu Unicorn Systems za poskytnutá data pro účely této práce a možnost využít interního know-how společnosti k vypracování této práce.

Měření efektivity fix price – fix time projektů Measuring the effectiveness of fix price - fix time projects

5

Abstrakt Cílem práce je zhodnotit aktuálně používané metriky efektivity pro dodávky softwarových projektů ve společnosti Unicorn Systems. K dosažení tohoto cíle práce nejdříve definuje pojem efektivita fix-time fix-price projektu a způsoby jejího měření. Pro průběžné měření aktuálně běžících projektů práce popisuje techniku Earned Value Management. Dále práce popisuje část metodiky projektového řízení ve společnosti Unicorn Systems, týkající se efektivity projektů. Práce je zaměřena zejména na průběžné hodnocení, navrhuje drobné vylepšení průběžného hodnocení s využitím techniky Earned Value Management. Toto vylepšení ilustruje na příkladech z vybraných existujících projektů.

Klíčová slova: projekt, kvalita, scope, termín, rozpočet, náklady, efektivita, produktivita, Earned Value Management, Unicorn Systems, status assesment

Abstract The aim of the study is to evaluate currently used metrics of software project effectiveness for software projects delivered at Unicorn Systems. To achieve this goal, the study first defines the efficiency of fix-time fix-price project and methods of its measurement. For ongoing measurement of running projects work describes a Earned Value Management technique. Study also describes the methodology of project management at Unicorn Systems, only part affecting the project efficiency is described. The work is mainly focused on regular project status assessment and suggests some minor improvements using Earned Value Management technique. This suggested improvement is illustrated with examples based on selected existing projects.

Keywords: project, quality, scope, term, budget, cost, effectivity, productivity, Earned Value Management, Unicorn Systems, status assesment

6

Obsah 1.

Úvod

9

2.

Měření efektivity fix-price fix-time projektů 2.1. Vymezení rozsahu

3.

4.

10 10

2.1.1. Definice projektu

10

2.1.2. Způsob dodání projektu

11

2.1.3. Fix-price fix-time projekt

11

2.2. Definice efektivity

14

2.3. Měření efektivity

17

2.3.1. Základní ukazatele

17

2.3.2. Odvozené ukazatele

18

2.3.3. Měření běžících projektů

20

Metoda Earned Value Management

22

3.1. Základní ukazatele

22

3.2. Odvozené ukazatele

23

3.3. Používání EVM při řízení projektu

25

3.3.1. Podpora techniky EVM v nástroji Microsoft® Project

27

3.3.2. Příklad použití techniky EVM

29

Měření ve společnosti Unicorn Systems 4.1. Projektová metodika Unicorn Systems

34 34

4.1.1. Pravidelný reporting

34

4.1.2. Nástroje pro hodnocení stavu

38

4.2. Doporučení

41

4.3. Vybrané projekty

44

4.3.1. Divize 1 – Produkční stream 1

45

4.3.2. Divize 2 – Produkční stream 2

46

5.

Závěr

54

6.

Conclusion

56

7.

Seznam použitých zdrojů

58

8.

Seznam obrázků

59 7

9.

Seznam tabulek

60

8

1. Úvod Prudký rozvoj ICT technologií v posledních dvaceti letech umožnil vznik nového typu společností, které poskytují zakázkové služby v oblasti IT. Hlavní oblastí činnosti těchto společností je realizace projektů pro svoje zákazníky formou dodávky na míru vytvořeného software. Schopnost firem řídit efektivně softwarové projekty a tím i efektivně poskytovat své služby je klíčová a poskytuje jim nezanedbatelnou konkurenční výhodu. Jednou z největších a dlouhodobě nejúspěšnějších společností tohoto typu na českém trhu je společnost Unicorn Systems. Autor této práce ve společnosti Unicorn Systems pracuje na různých pozicích již přes patnáct let a účastnil se desítek projektů. Cílem této práce je zhodnotit způsob průběžného měření a řízení efektivity projektů ve společnosti Unicorn Systems, případně navrhnout jejich vylepšení. V teoretické části práce definuje klíčové pojmy používané při řízení projektů a seznámí čtenáře s nejpoužívanějšími ukazateli a metrikami pro řízení projektů. Teoretická část je primárně zaměřena na průběžné měření veličin – tj. měření hodnot na běžících, ještě neukončených projektech. Průběžně měřitelné ukazatele poskytují manažerům projektů nástroj, díky kterému jsou schopni předpovídat další průběh a případně správně ovlivnit celkové směřování projektu a tedy i jeho celkový výsledek. Práce se zaměří na nejpoužívanější techniku průběžného řízení efektivity – metodu Earned Value Management (Řízení vytvořené hodnoty) – a předpoklady jejího správného používání. V další části práce popíše část metodiky projektového řízení ve společnosti Unicorn Systems, která se týká řízení, reportování a hodnocení efektivity projektu. Vzhledem k tomu, že celá metodika projektového řízení je interním know-how společnosti Unicorn Systems, budou uvedeny pouze vybrané části, které mají přímý vztah k tématu práce. Uvedené části projektové metodiky Unicorn Systems budou zhodnoceny v souladu s teoretickou částí práce, výsledkem zhodnocení bude doporučení ke změnám. Navržené změny budou v rámci práce následně ilustrovány na vybraném vzorku dat z reálných běžících projektů, bez uvedení jejich bližší identifikace.

9

2. Měření efektivity fix-price fix-time projektů V této teoretické kapitole vymezíme rozsah řešeného problému a definujeme základní pojmy, se kterými budeme nadále pracovat.

2.1. Vymezení rozsahu Bakalářská práce se zabývá zkoumáním projektového řízení v konkrétním sektoru služeb – vytváření a dodávání ICT řešení na zakázku. Tato oblast služeb má následující charakteristiky: 

Vytváření ICT řešení na míru je převažující dodávanou službou společnosti.



Služby jsou dodávány zejména externím zákazníkům na základě obchodního vztahu (smlouvy o dílo).



Dodávaná řešení jsou unikátní a specifická pro každého zákazníka – tj. nejedná se o implementace balíkových řešení.



V jeden čas společnost dodává několik služeb rozdílným zákazníkům.



Převažujícím zdrojem používaným k dodání služby je lidská práce.

Společnosti vyhovující těmto charakteristikám lze přeneseně pojmenovat jako „továrny na software“ (UNICORN SYSTEMS‚ 2012). Jako průmyslové podniky řeší problémy optimalizace výrobních linek1, tak tyto softwarové společnosti řeší svoji organizaci a metodiku práce tak, aby s minimálními náklady poskytovaly maximální množství přiměřeně2 kvalitních služeb. 2.1.1. Definice projektu Projekt je „časově omezená pracovní činnost, jejímž cílem je vytvoření unikátního produktu, služby nebo dosažení jiného výsledku“. (PROJECT MANAGEMENT INSTITUTE‚ 2004, s. 5) Projekt bývá organizačně zajištěn dočasnou organizační jednotkou, která po dosažení cíle projektu zaniká (KOVÁŘ et. al.‚ 2009, s. 26).

1 Např. Štíhlá výroba – viz http://businessworld.cz/business-rizeni-podniku/rizeni-aoptimalizace-vyrobnich-procesu-stihla-vyroba-6398 2

Je ekonomicky neefektivní překračovat požadavky kladené na kvalitu zákazníkem.

10

Z pohledu softwarové společnosti lze zjednodušeně říci, že jeden projekt se rovná jedné zakázce. Takových zakázek realizuje typická společnost paralelně více a u všech musí dbát na jejich správné řízení a optimální využívání zdrojů. 2.1.2. Způsob dodání projektu Při dodávání řešení formou projektu může být využíváno různých metod smluvního pokrytí. Nejrozšířenější formy jsou: 

Fix-price fix-time – dodavatel se zavazuje dodat ICT řešení na klíč, za předem danou pevnou cenu a v pevném termínu. Při této variantě náklady rizik a nepředvídaných situací nese zejména dodavatel.



Time & Material – dodavatel dodává lidskou práci, rizika překročení termínu nebo rozpočtu nese zadavatel, který si také projekt většinou řídí.



Různé kombinace výše uvedených forem – např. pevná část dodávky ve formě fix-price fix-time a veškeré vícepráce formou time & material.

Pro účely této práce se budeme zabývat pouze první variantou – tj. fix-price fixtime projektem, protože nás zajímá měření a řízení efektivity na straně dodavatele. Nicméně veškeré techniky popisované v této práci lze používat nezávisle na způsobu dodání. 2.1.3. Fix-price fix-time projekt Fix-price fix-time projekt je řízenou činností, u které jsou sledovány čtyři základní charakteristiky: kvalita, kvantita, termín a rozpočet (KOVÁŘ et. al.‚ 2009, s. 107-8). 

Kvalita – je úspěšnost vyrobeného produktu, který splňuje nebo převyšuje předem dohodnuté požadavky. Kvalitu softwarového díla nelze jednoduše měřit (JøRGENSEN‚ 1999) – asi nejčastěji používaná metrika je „spokojenost

uživatele“

–

tj.

schopnost

produktu

být

používán

k zamýšleným účelům za předem definovaných podmínek. Tato metrika umožní poznat překročení definovaného cíle (minimální požadované kvality), ale neumožní jednoduše zjistit, o kolik byl cíl překročen. Existují i další metriky kvality, které jsou přímo měřitelné – například počet odhalených chyb nebo počet řádků kódu. Nicméně pro fix-price fix-time projekt je klíčová taková metrika, na jejímž základě je zadavatel ochotný výsledný software převzít. To se děje nejčastěji na základě splnění

11

akceptačních kritérií, které ve velké míře sledují absolutní počty chyb a splnění dalších formálních náležitostí. Splnění akceptačních kritérií má většinou výsledek „splněno“, „nesplněno“, někdy se můžeme setkat i s výsledkem „splněno s výhradami“. Používání akceptačních kritérií tedy odpovídá metrice „spokojenost uživatele“, včetně nemožnosti změřit o kolik byla akceptační kritéria překročena. 

Kvantita- představuje rozsah, ve kterém je výsledný produkt požadován. Typicky je měřen pokrytím požadavků zadavatele – to je relativní metrika. Existují způsoby absolutního měření velikosti softwarového produktu – například metoda funkčních bodů (UK SOFTWARE MEASUREMENT ASSOCIATION‚ 1998) nebo počítání řádků kódu v metodě Cocomo II (CONELL‚ 2006, s. 83-91). Tyto způsoby měření jsou používané zejména pro odhadování velikosti a nákladů projektů, většinou celkovou velikost upravují pomocí řady faktorů, jejichž hodnoty jsou stanoveny zejména na základě statistických analýz velké řady měřených projektů.



Termín – definuje časový horizont, který je vymezen na realizaci celého softwarového produktu. Pokud není termín dodržen, lze odchylku měřit absolutně i relativně.



Rozpočet – určuje finanční prostředky, které jsou na realizaci softwarového produktu plánované a vyhrazené3. Tuto charakteristiku lze jednoznačně a jednoduše měřit.

Je nutné si uvědomit, že pro každý jednotlivý projekt existuje množina přípustných řešení, která je ohraničena minimálními a maximálními hodnotami jednotlivých charakteristik. Tuto množinu můžeme zobrazit jako body na hranách čtyřhranného jehlanu (KOVÁŘ et. al.‚ 2009, s. 108), červeně jsou označeny limity jednotlivých charakteristik.

Rozpočet je významově odlišný od ceny zakázky, kterou zaplatí konečný zákazník. V této práci je termín rozpočet výhradně uváděn ve smyslu sumy prostředků, které má k dispozici projektový tým a které jsou určeny na realizaci zakázky. 3

12

Obrázek 1- Množina přípustných řešení Quality

Budget B max

Q max Time Scope T max

Přípustná řešení

S max

B min

T min

Q min

S min

KKTR (QSTB)

0

Zdroj: (KOVÁŘ et. al.‚ 2009, s. 108)

Z pohledu množiny přípustných i nepřípustných řešení můžeme zavést následující pojmy: 

Úspěšný projekt je takový fix-price fix-time projekt, který splnil požadavky na kvalitu Qmin a kvantitu Smin a zároveň nepřekročil omezení termínu Tmax a rozpočtu Bmax.



Dokončený projekt je takový fix-price fix-time projekt, který splnil požadavky na kvalitu Qmin a kvantitu Smin, ale překročil jedno nebo obě z omezení termínu Tmax a rozpočtu Bmax.



Nedokončený projekt je takový fix-price fix-time projekt, kterému se nepodařilo splnit jeden z požadavků na kvalitu Qmin nebo kvantitu Smin.

Přirozeným zájmem softwarových společností je mít všechny projekty úspěšné nebo přinejmenším dokončené, pouze v těchto případech dostávají od zadavatele zaplacenou dohodnutou cenu.

13

2.2. Definice efektivity I v případě úspěšného projektu je množina přípustných řešení stále rozsáhlá. Pokud bychom chtěli v rámci této množiny přípustných řešení tato řešení seřadit podle výhodnosti pro výrobce a tedy i výrobní priority, musíme stanovit jednoznačnou metriku, která nám umožní jednotlivá řešení mezi sebou porovnávat. V grafickém zobrazení množiny přípustných řešení na Obrázku 1 můžeme použít jako klíčový ukazatel vzdálenost řešení (reprezentovaného bodem v rámci přípustných řešení) od vrcholu jehlanu (bodu 0). V praxi při řízení projektu takto jednoduchou pomůcku nemáme k dispozici. Základem pro stanovení takového ukazatele může být vztah mezi jednotlivými charakteristikami fix-price fix-time projektu: 

Navyšování kvantity nad minimální nutnou úroveň si vyžádá dodatečné náklady na implementaci zbytných funkčností. Projeví se tedy ve vyšších nákladech.



Zvyšování kvality nad akceptovatelnou úroveň zvyšuje náročnost testování.

Vyšší

pracnost

zajištění

kvality

se

projeví

opět

ve

vyšších nákladech. 

Protahování projektu v čase znamená delší alokaci jednotlivých členů týmu. Větší alokace se opět projeví ve vyšších nákladech.

Náklady projektu tedy můžeme vyjádřit jako funkci ostatních charakteristik: (

)

(1)

Na základě výše uvedených dopadů změn jednotlivých charakteristik můžeme předpokládat, že průběh funkce při změně pouze jedné charakteristiky je neklesající. S tímto předpokladem, i když nejsme schopni funkci přesně definovat, můžeme porovnávat například míru změnu nákladů na základě míry nebo velikosti změny rozsahu. Klíčovou sledovanou charakteristikou pro porovnání efektivity projektu tedy bude nákladová položka projektu, konkrétněji vztah plánovaného rozpočtu a jeho skutečného čerpání. Vlastní efektivitu v oblasti výrobního procesu (z pohledu softwarové firmy tedy realizace projektu) můžeme popsat jako „účinnost prostředků vložených do výroby hodnocenou z hlediska jejich výsledků“ (PETRÁČKOVÁ et. al.‚ 1998, s. 185). Efektivita je bezrozměrná veličina, její hodnotu můžeme vyjadřovat v procentech. 14

Prostředky vložené do výroby jsou náklady vynaložené na realizaci fix-price fixtime projektu – tj. náklady odvedené lidské práce, náklady na pracovní vybavení, licence vývojových nástrojů, cestovné a další položky. Tyto náklady jsou odvozeny od skutečně dodaného rozsahu, skutečně dosažené kvality a výsledného termínu dodání. Za výsledek výroby považujeme přinejmenším dokončený projekt4. Z pohledu měření a vyhodnocování výrobní efektivity je hodnota výsledku rovna hodnotě plánovaného rozpočtu na výrobu. Tím dojde k očištění měření od obchodních vlivů – každá zakázka může být obchodována s jinou obchodní marží, každá zakázka ale bude mít určen realizační rozpočet. Efektivita realizace fix-price fix-time projektu je tedy míra účelnosti využití plánovaných

zdrojů

k dosažení

přípustného

řešení

v rámci

stanovených

mantinelů. Porovnávány jsou skutečně vynaložené náklady odrážející míru splnění jednotlivých kritérií s plánovanými náklady vyjadřujícími plánovanou míru splnění těchto kritérií. Čerpání nákladů a tím i efektivitu realizace fix-price fix-time projektu nejvíce ovlivňují dva faktory: 

Způsob organizace práce a její plánování přímo ovlivňuje čerpání jednotlivých zdrojů. Tímto řízením nákladů na zdroje je ovlivněna i možná dosažitelná efektivita.



Vlastní způsob řešení problému – tedy návrh systému, jeho komponent a architektury. Chytrý návrh řešení umožní výrazně ušetřit zdroje na jeho pozdější realizaci.

Pokud oddělíme fázi návrhu řešení od fáze jeho konstrukce a tyto fáze řídíme a rozpočtujeme odděleně5, pak klíčovým faktorem dosahování efektivity konstrukční fáze (vlastní realizace projektu) zůstává způsob organizace a plánování práce. Aby mohly softwarové společnosti s tímto faktorem cílevědomě pracovat, musí mít prostředky jak ho měřit a sledovat.

Nedokončené projekty nebudeme uvažovat, nedošlo k jejich převzetí zákazníkem a tedy ani k uhrazení dohodnuté obchodní ceny. Primárním zájmem softwarových firem je projekty dokončovat tak, aby minimalizovaly případné celkové ztráty. 5 Například metodika IBM Rational Unified Process takto odděluje fáze projektu, nazývá je Elaborace (Elaboration) a Konstrukce (Construction). 4

15

Zjednodušeně můžeme efektivitu realizace fix-price fix-time projektu zapsat s využitím plánovaného rozpočtu a známých nákladů následujícím vzorcem: (2) Takto definovaný vztah má následující vlastnosti: 

Projekt realizovaný přesně v plánovaném rozpočtu dosahuje účinnosti (efektivity) 100 %.



Překročení plánovaného rozpočtu se projeví poklesem výsledné efektivity do intervalu (0 % - 100 %). Čím nižší výsledná efektivita, tím větší bylo překročení plánovaného rozpočtu.

Z pohledu softwarové firmy je žádoucí, aby výsledná efektivita ve skutečnosti překračovala 100 %. To je dané zejména tím, že v době sjednávání zakázky pracuje s odhady pracnosti, které jsou běžně zatíženy nějakou chybou. Tato chyba bývá v rozpočtech eliminována rezervními položkami, určenými na krytí všech realizačních rizik. Prakticky lze říci, že: (3) Rezervu na krytí rizik (a tím i nepřesnost odhadů) můžeme vyjádřit i pomocí koeficientu: (4) Každý správně řízený projekt, který nevyčerpá všechny rezervy na krytí rizik, by tak měl skončit s efektivitou vyšší než 100 %. Je-li Rizikový koeficient vyjádřen v procentech (jeho hodnota je větší než 100 %), firmou očekávaná efektivita projektu se pak pohybuje v intervalu <100 %, Rizikový koeficient>. V řídkých případech pak může být výsledná efektivita i vyšší. Podle dosažené efektivity pak můžeme opět projekty rozdělit do již jednou zmíněných kategorií (Tabulka 1).

16

Tabulka 1- Charakteristiky projektu

Charakteristika projektu

Výsledná efektivita

Úspěšný projekt

<100 %, Rizikový koeficient a více)

Dokončený projekt

(0 %, 100 %)

Nedokončený projekt

0% Zdroj: Vlastní zpracování

Je nutné si uvědomit, že Tabulka 1 obsahuje jistá zjednodušení. Je pominut rozměr dodání v termínu – mohou existovat projekty, které nevyčerpají rezervní část rozpočtu (vycházejí jako úspěšné) a přitom překročí plánovaný termín dodání. Ve většině případů ale překročení termínu sebou přináší další dodatečné náklady, tedy tyto projekty budou nakonec hodnoceny správně jako dokončené, nikoliv jako úspěšné. Nedokončené projekty mají nulovou efektivitu, výsledek výroby je nezávisle na plánovaném rozpočtu reálně nulový.

2.3. Měření efektivity Základním předpokladem pro měření efektivity projektu je existence dostupných a měřitelných dat, na jejichž základě lze pak určit hodnoty měřených veličin. Realizace projektu je dynamický proces. To znamená, že se podkladová data a měřené veličiny mění v průběhu času. Výjimku tvoří základní projektová omezení (kvalita, kvantita, termín a rozpočet) – ta jsou neměnná, pomineme-li možnost změnové řízení. Pro zjednodušení nejprve definujeme ukazatele na dokončeném projektu, kde již nedochází k žádným změnám ve sbíraných datech a měřených ukazatelů. 2.3.1. Základní ukazatele Základní ukazatele uvedené v Tabulce 2 jsou přímo měřitelné a slouží zejména ke stanovení odvozených ukazatelů, které mají větší vypovídací hodnotu. Tato práce je v dalších kapitolách zaměřena zejména na práci se základními ukazateli a jejich měření. Případné odvozené ukazatele je při existenci naměřených hodnot základních ukazatelů vždy možné jednoduše dopočítat.

17

Tabulka 2 - Základní ukazatele

Základní ukazatel

Jednotka

RozpočetPlánovaný

Měna

Význam Plánovaný rozpočet na realizaci projektu. Zároveň vyjadřuje celkovou realizační hodnotu projektu.

NákladyVynaložené

Měna

Celková suma nákladů vynaložených na realizaci projektu.

HodinyOdpracované

-

Jednotky lidské práce vynaložené na realizaci projektu

Délka projektu

Dny

Celková délka projektu

Velikost scope

Bod

Stanovení velikosti rozsahu projektu – například

(dle typu

metodou funkčních bodů, UCP nebo COCOMO II.

měření) Zdroj: Vlastní zpracování

Do základních ukazatelů pak patří i jejich části – zejména se to týká rozpočtu a nákladů. Můžeme tedy používat i dílčí složky těchto ukazatelů jako jsou NákladyCestovné, NákladyLicence a další. 2.3.2. Odvozené ukazatele Odvozené ukazatele v Tabulce 3 lépe ilustrují skutečnou charakteristiku projektu z pohledu efektivity. Kromě vlastní Efektivity, definované v kapitole 2.2 Definice efektivity, dalšími důležitými ukazateli pro srovnání s dalšími projekty jsou ukazatele realizačního zisku a produktivity – tu můžeme definovat jako „množství produkce vyrobené za určitou dobu“ (PETRÁČKOVÁ et. al.‚ 1998, s. 621).

18

Tabulka 3 - Odvozené ukazatele

Odvozený

Jednotka

Odvození

ukazatel EfektivitaCelková

%

ZiskRealizační

Měna

Ziskovost

%

ProduktivitaFinanční

⁄

ProduktivitaRozsahu

⁄ Zdroj: Vlastní zpracování

Realizační zisk (ZiskRealizační) je objem úspor proti plánovanému rozpočtu. Těchto úspor projekt může dosáhnout nečerpáním nějaké plánované položky nebo správným řízením rizik a tím i nečerpáním rezervy na krytí rizik. Realizační zisk je možné udávat v relativní míře – Ziskovosti. Dosazením do odvození jednotlivých ukazatelů lze dospět k tomu, že Ziskovost je pouze jiným úhlem pohledu na celkovou efektivitu: (5) Přičemž platí, že: 

Pokud je Efektivita > 100 %, je Ziskovost v procentech kladná.



Pokud je Efektivita = 100 %, je Ziskovost v procentech nulová.



Pokud je Efektivita < 100 %, je Ziskovost v procentech záporná.

Ukazatele produktivity slouží zejména k porovnání s jinými projekty se zohledněním různých faktorů a jsou založené na odpracovaných hodinách. Jejich podstatou je jeden z vymezujících rysů softwarových společností – výrazná převaha lidské práce ve struktuře nákladů. Produktivita

rozsahu

(ProduktivitaRozsahu) se

používá

k porovnání

projektů

s podobnou efektivitou, které mají řadu typických znaků podobnou a jeden z nich odlišný. Typické znaky jsou použité technologie, velikost projektu, etapa projektu (jedná se o první etapu nebo rozvoj již existujícího systému). Pomocí produktivity rozsahu tedy můžeme porovnávat a sledovat vlivy: 19



Vliv rozsahu projektu na jednotkovou produktivitu (odlišný znak je rozsah projektu).



Produktivity jednotlivých technologií (porovnávány jsou podobné projekty, realizované na různých technologiích).



Míru odlišnosti produktivity prvních a dalších etap na velkých projektech.

Ukazatel finanční produktivity (ProduktivitaFinanční) slouží naopak k porovnání složení realizačních týmů. V rámci jednoho rozpočtu může projektový manažer dosáhnout stejného cíle a efektivity jak s týmem seniorních specialistů, tak s týmem obsahujícím větší počet méně zkušených zaměstnanců. V prvním případě dosáhne mnohem vyšší finanční produktivity. Nicméně zájmem softwarových společností je i výchova nových specialistů, tedy preferují kombinaci zaměstnanců zkušených s méně zkušenými v jednom realizačním týmu. Tato preference se projevuje v očekávané hodnotě finanční produktivity. Odchylka nahoru pak znamená využití příliš seniorního týmu, odchylka dolů znamená, že tým byl nevyvážený z pohledu velkého množství méně zkušených zaměstnanců. 2.3.3. Měření běžících projektů Složitější je situace při měření ukazatelů v průběhu realizace projektu, jejich použití pro vyhodnocení stavu a případné nápravné akce. Používaná metoda měření musí umět poskytovat základní ukazatele, které umožní změřit, v jakém stavu projekt je a v jakém stavu měl být k datu měření. Tyto základní otázky ilustruje Obrázek 2. Obrázek 2 – Měření běžících projektů Čas měření

Projekt Kde jsme měli být?

Kde jsme?

Zdroj: Vlastní zpracování

Samotná odpověď na otázku „Kde jsme?“ nedává dostatek informací pro skutečné vyhodnocení stavu projektu. Až možnosti porovnání s odpověďmi na otázku „Kde jsme měli být?“ přináší skutečně použitelné výsledky měření. Při měření běžícího projektu hrají podrobnější plánování a jeho jednotlivé složky mnohem významnější roli, protože právě

úroveň

plánování

určuje

úroveň 20

možností

dynamického

měření.

Z projektového plánu musí být v každém okamžiku zřejmé, v jakém stavu by měl projekt v daném termínu být, ze způsobu průběžného hodnocení projektu musí být zřejmé, v jakém stavu v daném termínu projekt skutečně je. Pouze po splnění těchto předpokladů lze provádět vlastní měření na běžícím projektu a hodnocení naměřených hodnot. Toto průběžné hodnocení je ale nutné provádět pravidelně, například na týdenní bázi, protože právě pravidelnost měření umožňuje odhalit trendy ve vývoji jednotlivých ukazatelů. Nejrozšířenější metodou takového průběžného měření a hodnocení je technika Earned Value Management.

21

3. Metoda Earned Value Management Metoda Earned Value Management (dále jen EVM, v češtině bývá označována jako Řízení vytvořené hodnoty) se objevila již v 60. letech 20. století ve vládních programech Spojených států jako nástroj finanční analýzy vládních programů (Wikipedia‚ 2001). Poté se rozšířila ze státní správy i do soukromých společností a uznávaných metodik projektového řízení (PMI), zůstává například nedílnou součástí řízení všech projektů v rámci NASA (NASA‚ 2010). Podpora této techniky je i součástí produktu Microsoft® Project (SCHWALBE‚ 2007, s. 313-4). Metoda Earned Value Management je metoda měření projektu, která odráží kombinaci rozsahu, času a nákladů – jejím základem je směrný plán efektivity nákladů, který je porovnáván s informacemi o skutečném průběhu. Pro větší přehlednost v této kapitole budou uváděny české termíny, používané v Microsoft® Project, spolu s jejich anglickými ekvivalenty, které jsou zdrojem zkratek pro jednotlivé ukazatele. Popis metody je založen na kapitole Řízení vytvořené hodnoty (SCHWALBE‚ 2007, s. 304-12).

3.1. Základní ukazatele Směrný plán (Baseline) je schválený plán projektu, který je složen z jednotlivých položek. Tyto položky jsou založeny na rozpadu prací, dle použité projektové metodiky se můžeme potkat s termíny WBS (Work Breakdown Structure) nebo PBS (Product Breakdown Structure). Součástí směrného plánu jsou i celkové plánované náklady projektu BAC (budget at completion) a jejich rozložení v čase. Směrný plán obsahuje všechny informace nutné ke stanovení odpovědi na otázku „Kde jsme měli být“. Skutečný stav je sada informací na úrovni jednotlivých položek rozpadu prací – míra dokončenosti jednotlivé položky, náklady jednotlivé položky, kdy byly práce zahájeny a kdy byly dokončeny. Na základě Skutečného stavu jsou vypočítávány následující klíčové základní ukazatele, nejprve pro jednotlivé položky a potom sumárně pro celek: 

Plánovaná hodnota (planned value, PV) – tato hodnota byla dříve označována BCWS (Budgeted costs of work scheduled) a označuje tu část schválených nákladů, která měla být vynaložena na projekt během měřeného období a vychází ze Směrného plánu k datu měření. Prakticky

22

odpovídá hodnotě ukazatele RozpočetPlánovaný k datu měření. Zjednodušeně lze vypočítat jako: (6) 

Skutečné náklady (actual cost, AC) – tato hodnota byla dříve označována ACWP (actual cost of work performed) a představuje součet všech nákladů, vynaložených za měřené období, tj. od počátku projektu k datu měření. Odpovídá

ukazateli

NákladyVynaložené.

Zjednodušeně

lze

vypočítat

následovně: (6) 

Vytvořená hodnota (earned value, EV) – dříve byla označována BCWP (budget cost of work performed). Určení její hodnoty je nejsložitější – vyjadřuje rozpočtové náklady na skutečně provedenou práci. Pokud známe náklady na jednotlivou položku, musíme správně určit míru jejího dokončení. K tomu slouží různé techniky, nejjednodušší technika je přímý odhad dokončenosti, pak můžeme počítat EV takto: (7)

Ukazatel Vytvořená hodnota je novým základním ukazatelem, u dokončeného projektu jeho hodnota odpovídá hodnotě RozpočetPlánovaný. U běžícího projektu odráží aktuální stav kombinace rozsahu a nákladů k datu měření – jedná se vlastně o odhad hodnoty odvedené práce. Hodnotu tohoto ukazatele právě nejvíce ovlivňuje struktura rozpadu prací a způsob určení míry dokončení, tedy způsob plánování a hodnocení.

3.2. Odvozené ukazatele Odvozené ukazatele slouží k vyhodnocení dosavadního průběhu a odhadu budoucího vývoje. Způsob jejich výpočtu je uveden v Tabulce 4.

23

Tabulka 4 - Odvozené ukazatele EVM

Odvozený ukazatel Odchylka nákladů (CV) Relativní odchylka nákladů

Jednotka

Odvození

Měna %

(CV%) Odchylka časového plánu

Měna

(SV) Relativní odchylka časového

%

plánu (SV%) Index efektivity nákladů

%

(CPI) Index efektivity časového

%

plánu (SPI) Odhad nákladů na dokončení

Měna

(EAC) Odhad času na dokončení

Čas

(ESC) Index efektivity nákladů do

%

dokončení (TCPI) Index efektivity časového

%

pláno do dokončení (TSPI) Zdroj: Vlastní zpracování

Odchylka nákladů (cost variance, CV) je vytvořená hodnota minus vynaložené náklady. Záporná hodnota znamená, že byly vynaloženy větší než plánované náklady, kladná hodnota značí úsporu proti původnímu plánu. Odchylka nákladů je absolutní hodnota, lze použít relativní hodnotu, která vyjadřuje míru odchylky. Odchylka časového plánu (schedule variance, SV) je rozdíl vytvořené a plánované hodnoty. Při záporné hodnotě trvalo provedení déle, při kladné hodnotě byly práce provedeny dříve, než bylo plánováno. Opět lze sledovat v absolutní hodnotě nebo relativní míře odchylky. Index efektivity nákladů (cost performance index, CPI) je poměr vytvořené hodnoty ke skutečným nákladům, zároveň podle něj lze odhadovat budoucí vývoj

24

a náklady potřebné k dokončení projektu. Hodnota indexu je vykládána následujícím způsobem: 

CPI = 100 % - projekt probíhá přesně podle plánovaného rozpočtu.



CPI < 100 % - projekt překračuje plánované náklady.



CPI > 100 % - došlo k úsporám proti plánovanému rozpočtu.

Index efektivity nákladů svojí konstrukcí odpovídá odvozenému ukazateli efektivity. Ukazatel Earned Value by na konci projektu měl mít hodnotu plánovaných nákladů (tedy plánovaného rozpočtu) a ukazatel Actual Cost je na konci projektu rovný vynaloženým nákladům. Proto by měl být index efektivity nejsledovanějším odvozeným ukazatelem pro řízení efektivity v průběhu projektu. Index efektivity časového plánu (schedule performance index, SPI) vyjadřuje poměr vytvořené hodnoty k plánované hodnotě a opět lze použít k předpovědím budoucího vývoje. Význam hodnot je podobný jako u CPI, tedy při hodnotě SPI menší než 100 % je projekt ve skluzu z pohledu časového plánu. Odhad nákladů na dokončení (estimate at completion, EAC) je projekce původních plánovaných nákladů BAC s pomocí vypočítaného indexu CPI. V přímém vztahu k EAC je ukazatel Index efektivity nákladů do dokončení (to complete cost performance indicator, TCPI), který ukazuje způsob budoucího využívání nákladů tak, aby cílové hodnoty projektu byly co nejlepší. Hodnota větší než 100 % znamená, že do konce projektu by náklady měly být kontrolovány a řízeny přísněji. Hodnota menší než 100 % znamená existenci rezerv v rámci projektového rozpočtu. Odhad času na dokončení (estimate schedule at completion, ESC) je podobné využití vypočítaného indexu SPI jako u nákladů k dokončení. Analogicky k nákladovému pohledu existuje ukazatel Index efektivity časového plánu do dokončení (to complete schedule performance indicator, TSPI). Význam jeho hodnot je ale přesně opačný – tj. hodnota větší než 100 % znamená, že zdroje by měly být řízeny přísněji než doposud.

3.3. Používání EVM při řízení projektu Technika Earned Value Management vyžaduje pro své používání podrobné plánování a hlavně průběžnou práci na udržování plánu a aktuálních hodnot u jednotlivých položek plánu. Bez pravidelné aktualizace projektového plánu podle skutečného průběhu není možné tedy tuto techniku používat. Přesnost poskytovaných údajů záleží

25

více na struktuře rozpadu jednotlivých pracovních položek, než na přesnosti určení míry dopracování jednotlivých položek. Velikost plánovaných pracovních položek by měla být odvozena z délky pravidelné reportovací periody projektu. Pravidelné aktualizace a údržba projektových informací vypadají jako nákladné a neefektivní činnosti. Je nutné si ale uvědomit, že pro použití této techniky není potřeba udržovat mnoho informací, při vhodné struktuře detailních pracovních položek stačí i určování míry dokončení na stupnici 0 % (nezahájeno) - 50 % (rozpracováno) - 100 % (dokončeno). Naopak, používání této techniky přináší následující možnosti: 

Vizualizace vývoje projektu v čase. Rychlým pohledem na vývoj hodnot ukazatelů lze zjistit stav projektu v průběhu času. Z konstrukce odvozených ukazatelů EVM vyplývá i čtení jejich grafické interpretace. Porovnáváním křivek EV a AC hodnotíme odchylku nákladů Cost Variance (EV – AC) – a tedy vlastní efektivitu projektu. Porovnáním křivek PV a EV zase hodnotíme odchylku časového plánu Schedule Variance (EV-PV). Na Obrázku 3 je vidět projekt, který je efektivní z pohledu nákladů, nicméně se dostává do časového skluzu.

26

Obrázek 3- Příklad vizualizace vytvořené hodnoty

Zdroj: Earned Value Management (Wikipedia‚ 2001)



Určování ukazatelů EVM nejen na úrovni celého projektu, ale i na jeho částech, definovaných rozpadem pracovních položek. V typickém projektu některé úkoly jsou splněny s menšími náklady, na jiné úkoly je potřeba vynaložit více úsilí než bylo plánováno.



Sledování čerpání rezerv projektu – dokud je ukazatel EAC menší než (BAC + Rezervy na krytí rizik), bude projekt pravděpodobně dokončen v rámci plánovaného rozpočtu. Nejčastěji používané nástroje na řízení projektů, jako je Microsoft® Project,

přímo obsahují podporu správy aktuálního i směrného plánu, správy aktuálních hodnot, výpočty ukazatelů EVM i vizualizaci průběhu v čase. Jsou tedy ideálním nástrojem pro měření a řízení efektivity fix-price fix-time projektů. 3.3.1. Podpora techniky EVM v nástroji Microsoft® Project Nejrozšířenější nástroj na řízení projektů – Microsoft® Project – umožňuje jednoduchým způsobem používat techniku Earned Value Management. Po vlastním prvotním naplánování projektu, přiřazení zdrojů a dalších nákladů k jednotlivým úkolům, můžeme celý kompletní plán uložit jako Směrný plán. Existence Směrného plánu je předpokladem pro další používání techniky Earned Value Management.

27

Po vytvoření Směrného plánu pak periodicky v průběhu řízení projektu aktualizujeme stav jednotlivých úkolů, nastavujeme míru jejich splnění a očekávání zbylé pracnosti. Zároveň můžeme sledovat automaticky počítané hodnoty jednotlivých ukazatelů týkajících se vytvořené hodnoty. Česká lokalizace Microsoft® Project používá důsledně termín Vytvořená hodnota, nicméně označení jednotlivých ukazatelů vychází z anglické terminologie uvedené v této práci. Vypočítané hodnoty jsou vždy udávány k aktuálnímu dni, který je možné v rámci nástroje změnit. Počítané hodnoty jsou ilustrovány Obrázkem 4. Obrázek 4 - Ukazatele EVM v Microsoft Project


Tyto podrobné průběžné hodnoty můžeme z Microsoft® Project přímo tisknout jako sestavy, viz Obrázek 5. Obrázek 5 - Sestava vytvořené hodnoty


Nebo jejich časové řady můžeme exportovat do Excelu jako datový zdroj pro grafickou vizualizaci vývoje celkových ukazatelů, viz Obrázek 6.

28

Obrázek 6 - Grafická vizualizace vytvořené hodnoty


Používání techniky EVM není v Microsoft® Project tedy složité, vyžaduje však důslednost při plánování a aktualizaci údajů u jednotlivých úkolů. 3.3.2. Příklad použití techniky EVM Na jednoduchém příkladu můžeme ilustrovat použití techniky Earned Value Management. Nejprve je potřeba vytvořit směrný plán malého projektu, sloupec Týden v Tabulce 5 určuje časový plán – ve kterém týdnu má být úkol dokončen, hodnotu Planned Value lze jednoduše kumulativně počítat podle jednotlivých týdnů.

29

Tabulka 5 - Příklad EVM - Směrný plán

Úkol

Zdroj

Cena

Pracnost (h)

Týden

Náklady

(Kč/Hod) UC Specifikace

Analytik

500,00 Kč

24

1.

12 000,00 Kč

Kód

Vývojář

400,00 Kč

36

2.

14 400,00 Kč

Test analýza

Analytik

500,00 Kč

9

2.

4 500,00 Kč

Exekuce testů

Tester

200,00 Kč

22

3.

4 400,00 Kč

Opravy chyb

Vývojář

500,00 Kč

8

4.

4 000,00 Kč

Retest

Tester

200,00 Kč

8

4.

1 600,00 Kč

Instalační

Vývojář

500,00 Kč

6

4.

3 000,00 Kč

balíček Celkem

113

43 900,00 Kč


Během prvního týdne analytik připraví UC specifikace a podaří se mu i připravit část analýzy testů, zároveň vývojář začne v předstihu pracovat na vlastním kódu. Tabulka 6 - Příklad EVM - Stav po 1. týdnu

Týden 1.

Odpracováno (h)

Hotovo

25

100%

12 000,00 Kč

12 500,00 Kč

Kód

6

10%

1 440,00 Kč

2 400,00 Kč

Test analýza

4

40%

1 800,00 Kč

2 000,00 Kč

Exekuce testů

0

0%

- Kč

- Kč

Opravy chyb

0

0%

- Kč

- Kč

Retest

0

0%

- Kč

- Kč

Instalační

0

0%

- Kč

- Kč

15 240,00 Kč

16 900,00 Kč

UC Specifikace

Earned Value

Actual Cost

balíček Celkem


Po prvním týdnu tedy vypadá situace podle Tabulky 6 takto: 

Earned Value je vyšší než Planned Value (ta byla 12 000,00 Kč) – projekt je tedy v mírném předstihu.

30



Actual Cost je vyšší než Earned Value – dochází k většímu než plánovanému čerpání nákladů. Hodnota indexu efektivity nákladů CPI je 90,2 %, odhad celkových nákladů na dokončení projektu je 48 700,00 Kč.

Během druhého týdne analytik dokončí analýzu testů, vývojář dodá požadovaný kód a navíc si stihne připravit část instalačního balíčku. Stav po druhém týdnu je uveden v Tabulce 7. Tabulka 7 - Příklad EVM - Stav po 2. týdnu

Týden 2.

Odpracováno (h)

Hotovo

Earned Value

Actual Cost

UC Specifikace

25

100%

12 000,00 Kč

12 500,00 Kč

Kód

42

100%

14 400,00 Kč

16 800,00 Kč

Test analýza

8

100%

4 500,00 Kč

4 000,00 Kč

Exekuce testů

0

0%

- Kč

- Kč

Opravy chyb

0

0%

- Kč

- Kč

Retest

0

0%

- Kč

- Kč

Instalační

3

50%

1 500,00 Kč

1 500,00 Kč

32 400,00 Kč

34 800,00 Kč

balíček Celkem


Po druhém týdnu je stále Earned Value vyšší než Planned Value, projekt je tedy stále v předstihu díky přípravě instalačního balíčku, která je plánována až na později. Actual Cost je stále vyšší než Earned Value, hodnota indexu CPI stoupla na 93,1 % a odhad celkových nákladů k dokončení projektu tedy klesnul na 47 200,00 Kč. Během třetího týdne tester otestuje dodaný kód, vývojář opět v předstihu stihne opravit nalezené chyby a pokračuje v přípravě instalačního balíčku.

31

Tabulka 8 - Příklad EVM - Stav po 3. týdnu

Týden 3.

Odpracováno (h)

Hotovo

UC Specifikace

25

100%

12 000,00 Kč

12 500,00 Kč

Kód

42

100%

14 400,00 Kč

16 800,00 Kč

8

100%

4 500,00 Kč

4 000,00 Kč

Exekuce testů

20

100%

4 400,00 Kč

4 000,00 Kč

Opravy chyb

2

50%

2 000,00 Kč

1 000,00 Kč

Retest

0

0%

- Kč

- Kč

Instalační

4

80%

2 400,00 Kč

2 000,00 Kč

39 700,00 Kč

40 300,00 Kč

Test analýza

Earned Value

Actual Cost

balíček Celkem


Podle dat v Tabulce 8 je projekt stále v předstihu, hodnota Earned Value je vyšší než Planned Value. Actual Cost stále překračují Earned Value, ale hodnota indexu CPI se postupně zvyšuje na 98,5 %, s tím klesá i celkový odhad nákladů na dokončení projektu na 44 600,00 Kč. Poslední týden jsou všechny plánované práce dokončeny. Vzhledem k vysoké kvalitě kódu bylo nalezeno velmi málo chyb. Jejich opravy a opětovné testy spotřebovaly tedy méně zdrojů. Celkový výsledek po čtvrtém týdnu uvádí Tabulka 9.

32

Tabulka 9 - Příklad EVM - Stav po 4. týdnu

Týden 4.

Odpracováno (h)

Hotovo

UC Specifikace

25

100%

12 000,00 Kč

12 500,00 Kč

Kód

42

100%

14 400,00 Kč

16 800,00 Kč

8

100%

4 500,00 Kč

4 000,00 Kč

Exekuce testů

20

100%

4 400,00 Kč

4 000,00 Kč

Opravy chyb

3

100%

4 000,00 Kč

1 500,00 Kč

Retest

4

100%

1 600,00 Kč

800,00 Kč

Instalační

5

100%

3 000,00 Kč

2 500,00 Kč

Test analýza

Earned Value

Actual Cost

balíček Celkem

43 900,00 Kč

42 100,00 Kč


Protože jsou již dokončeny všechny práce, je Earned Value rovna Planned Value. Na konci projektu, díky úspoře při opravách chyb a jejich testování, došlo k poklesu Actual Cost pod hodnotu Earned Value. Index efektivity nákladů CPI tak dosahuje konečných 104,2 %. Celková vizualizace průběhu projektu po týdnech pomocí ukazatelů vytvořené hodnoty je vidět na Obrázku 7. Obrázek 7 - Příklad EVM - Vizualizace průběhu


33

4. Měření ve společnosti Unicorn Systems Způsob řízení a měření projektů je interní know-how společnosti Unicorn Systems. Právě způsob řízení projektů a důraz na tuto složku dodávky odlišuje Unicorn Systems od ostatních společností. Z tohoto důvodu jsou v této práci uvedeny pouze vybrané části metodiky řízení projektů. Kompletní projektová metodika, včetně využívaných zdrojů, je popsána a udržována v interním informačním systému společnosti a není tedy přístupná všem čtenářům.

4.1. Projektová metodika Unicorn Systems Projektová metodika Unicorn Systems je specifickou implementací založenou na vlastnostech známých metodik, ze kterých si bere podstatné části. Tato metodika vznikla v druhé polovině 90. let 20. století, od té doby je neustále rozvíjena a aktualizována tak, aby podporovala produkční schopnosti Unicorn Systems. Nejvíce je ovlivněna metodikou Rational Unified Process6, z této metodiky přebírá velkou část terminologie, oddělení fází a částí projektu a zejména iterativní přístup. Další podstatnou metodikou, ze které projektová metodika Unicorn Systems vychází, je PRINCE27. Z této metodiky pochází využití Product Breakdown structure a Product flow, používané při celkovém i operativním plánování projektu. Z pohledu měření efektivity fix-price fix-time projektů je pro tuto práci klíčová část pravidelného reportingu stavu projektu, včetně nástrojů a podkladových dat, které projektoví manažeři mají k dispozici. 4.1.1. Pravidelný reporting Projektová metodika ve společnosti Unicorn Systems klade důraz na pravidelný reporting stavu projektu (KOVÁŘ et. al.‚ 2009, s. 36-38,111). Projektový manažer je zodpovědný za pravidelné vytváření dokumentu Status Assesment, který obsahuje jak strukturované, tak slovní zhodnocení stavu projektu a jeho vývoje za poslední sledované období (standardně jeden týden). Struktura Status Assesment obsahuje tři klíčové sekce, které mají vztah k řízení a měření efektivity.

Nyní IBM Rational Unified Process, viz: http://www-01.ibm.com/software/rational/rup/ PRINCE2 je registrovanou obchodní známkou společnosti AXELOS Limited, http://www.prince-officialsite.com/ 6 7

34

viz:

4.1.1.1. Status Assesment – Status Overview Status Overview slouží k rychlému seznámení se stavem projektu pro nadřízené manažery, je uváděn ve struktuře vhodné pro agregaci vyššími organizačními jednotkami (KOVÁŘ et. al.‚ 2009, s. 37). Obsahuje zhodnocení čtyř základních charakteristik projektu: 

Q – kvalita (Quantity)



S – kvantita (Scope)



T – termín (Time)



B – rozpočet (Budget)

Každá charakteristika je ohodnocena pouze barevnou ikonou reprezentující jeden ze čtyř možných stavů, seřazených dle významu (Vynikající stav, Řešitelný problém, Závažné problémy, Na dané úrovni nezvladatelné problémy). Nadřízený tak během okamžiku vidí, jestli je nutné na daném projektu řešit nějaké problémy a která charakteristika je aktuálně problémová. Projektový manažer tyto charakteristiky hodnotí jak podle výsledků měření, tak podle dalších událostí, proběhlých jednání a podobně. 4.1.1.2. Status Assesment – KPI KPI (Key Performance Indicator) jsou stanoveny před začátkem projektu a jsou měřítkem interní úspěšnosti projektu. Projektový manažer tedy musí projekt realizovat v externích měřítkách úspěšnosti (Kvalita, Kvantita, Termín) a také interních. Interní měřítka úspěšnosti jsou založena zejména na Rozpočtu. Ze zmiňovaných ukazatelů jsou podstatné: 

Náklady – odpovídají nákladům jako hlavnímu prostředku řízení efektivity. Jedná se o základní ukazatel.



Hodiny – jsou nejpodstatnější složkou nákladů, z toho důvodu jsou sledovány samostatně. Jedná se o základní ukazatel.



Hodinová produktivita – významově odpovídá odvozenému ukazateli finanční produktivita.

U každého ukazatele projektový manažer uvádí hodnotu aktuální ke dni hodnocení, hodnotu plánovanou a hodnotu odhadovanou – jedná se o odhad hodnoty ukazatele po ukončení projektu. Vzhledem k tomu, že se jedná o průběžně se měnící

35

ukazatele, podstatné jsou hodnoty plánované a odhadované. Jejich porovnání vypovídá o stavu projektu a předpokládaném dalším vývoji. Uvádění aktuální hodnoty nemá u těchto ukazatelů efektivity význam, u finanční produktivity může být i matoucí. Nicméně existují v rámci KPI i ukazatele, nehodnocené touto prací, kde má smysl i aktuální hodnota. 4.1.1.3. Status Assesment – Burndown graph Burndown graph představuje grafickou reprezentaci plánovaného a skutečného rozsahu projektu, včetně plánovaných a odpracovaných hodin. Obrázek 8 - Burndown Graph

Zdroj: Metodika Unicorn Systems (UNICORN SYSTEMS‚ 2000)

Veškeré hodnoty ukazatelů v rámci tohoto grafického zobrazení na Obrázku 8 jsou uváděny v hodinách, tj. hodiny prezentují osu Y. Na časové ose X jsou vyznačeny klíčové milníky jednotlivých iterací a fází vývoje. Popis jednotlivých křivek uvádí Tabulka 10.

36

Tabulka 10 - Ukazatele Burndown Graph

Ukazatel Kontrakt

Význam Zobrazuje pouze celkovou výši plánovaných hodin, bez jejich distribuce v čase.

Plán hodin

Představuje kumulativně původní plán čerpání hodin po jednotlivých týdnech.

Výkaz hodin

Představuje kumulativně skutečně odpracované hodiny po jednotlivých týdnech.

Odhad hodin

Kumulativní odhad spotřeby hodin do konce projektu po jednotlivých týdnech.

Plán práce

Představuje původní plán práce po jednotlivých týdnech, vycházející z operativního plánu. V grafu jsou kumulativně zobrazeny úbytky v čase.

Zbývá práce

Představuje aktuální plán práce z operativního plánu, bez již odpracovaných hodin. V grafu jsou kumulativně zobrazeny úbytky v čase.

Odhad práce

Odhad čerpání zbývající práce po týdnech do konce projektu podle operativního plánu.

Bilance hodin

Obsahuje po týdnech vývoj rozpočtu, hodnota je určena jako Kontrakt – (Výkaz hodin + Zbývá práce). Zobrazuje tedy rozdíl mezi plánem a skutečným a odhadovaným čerpáním hodin. Zdroj: Vlastní zpracování

Grafická reprezentace je generována z tabulkového kalkulátoru, nicméně hodnoty tam za každý týden vkládá projektový manažer ručně, na základě výstupů z dále popsaných nástrojů – tabulky KKTR. Ruční vkládání hodnot je záměrné, aby případné historické hodnoty nebyly deformovány použitím vzorců a přepisováním některých dat. 4.1.1.3.1 Vztah hodnot Burndown Graph k EVM Veškeré hodnoty používané v Burndown Graph jsou uváděny v hodinách. Ty jsou používány jako jednotka nákladů. Vyjdeme-li z předpokladů, uváděných na začátku práce, že náklady lidské práce jsou vysoce převažujícím typem nákladu a budeme předpokládat jednotnou hodinovou sazbu, lze odpracovanou hodinu považovat i za 37

jednotku nákladů. Potom můžeme definovat v Tabulce 11 jednotlivé základní ukazatele, které mají svůj obraz v technice Earned Value Management, protože neměnné hodnoty v Burndown Graph odpovídají Směrnému plánu. Tabulka 11 - Vztah ukazatelů EVM a Burndown Graph

Ukazatel EVM Plánovaná hodnota (PV)

Vztah k Burndown Graph Existují dva možné ukazatele PV, založené na Plánu hodin nebo Plánu práce. Vzhledem k tomu, že Plán práce vychází z podrobnějšího operativního plánování, je lepší použít tento ukazatel. Tedy platí:

Skutečné náklady (AC)

Jsou zachyceny ukazatelem Výkaz hodin.

Vytvořená hodnota (EV)

Ukazatel Zbývá práce je de facto ukazatelem, kolik hodnoty zbývá vytvořit. Vytvořenou hodnotu je tedy možné zapsat jednoduše:

Odchylka nákladů (CV)

Prostým dosazením do způsobu výpočtu Bilance hodin lze dovodit, že tento ukazatel je ve skutečnosti Odchylkou nákladů. ( (

) )


Je tedy zřejmé, že ukazatele používané v Burndown Graph mají své ekvivalenty k ukazatelům v metodě Earned Value Management a lze je použít k určení dalších odvozených ukazatelů. Možnému využití této skutečnosti se věnuje kapitola 4.2 Doporučení. 4.1.2. Nástroje pro hodnocení stavu Aby byl projektový manažer schopen věrohodně každý týden vyplnit Status Assesment, používá některé základní nástroje. Opět jsou zmíněny pouze ty, které mají vztah k měření nebo řízení efektivity fix-price fix-time projektu.

38

4.1.2.1. Výkaz práce Každý zaměstnanec je povinen vykazovat průběžně svoji práci. Zaměstnanec tento výkaz vytváří v informačním systému Unicorn Systems, v rámci položky výkazu eviduje: 

Časové údaje – tj. datum, čas od, čas do s přesností na 15 minut. Požadovanou granularitu si určuje projektový manažer, obvyklým standardem je, aby jedna položka nepřesahovala 4 hodiny.



Pracovní položka – určuje položku, definovanou projektovým manažerem, která odpovídá jím připravenému rozpadu prací. Z položky tedy lze určit část dodávky projektu i vlastní projekt. Granularitu jednotlivých pracovních položek si určuje projektový manažer podle své potřeby.



Popis činnosti – zde je možné uvést skutečný popis provedené práce

Projektový manažer každý týden musí výkazy pracovníků na projektu potvrdit v systému. Ve vybraných případech může odmítnout potvrzení položky výkazu – pokud danou práci například neplánoval a nepožadoval – nebo ji pouze potvrdit částečně. Jednou týdně se automaticky pro každou organizační jednotku (fix-price fix-time projekt) vygeneruje souhrnný report, který obsahuje výkazy pracovníků za poslední období. Tento report je klíčovým vstupem pro určování odpracovaných hodin na projektu a jejich přiřazení jednotlivým položkám v rozpadu prací. 4.1.2.2. Tabulka KKTR Tabulka KKTR je základním nástrojem pro detailní operativní řízení projektu v Unicorn Systems. Aktuální revize obsahuje 12 pracovních listů, nicméně pro plánování, měření a řízení efektivity jsou důležité pouze některé z nich. List Parametry obsahuje nastavení celé tabulky pro plánování. Obsahuje termíny startu a konce projektu, definici počtu a délky iterací. Iterace jsou pro zjednodušení plánovány stejně dlouhé. Tyto parametry ovlivňují nastavení dalších tabulek. List Capacity slouží ke kapacitnímu plánování obsazení v čase. Obsahuje plán kapacit po lidech a jejich zapojení v čase. Kromě plánu obsahuje i čerpání kapacit, založené na výkazu odpracovaných hodin. List TSR je pouze pracovní, slouží ke zpracování exportu výkazů pracovních položek a jejich spárování s lidmi na záložce Capacity a s pracovními úkoly. List Scope je nejdůležitějším listem v celé tabulce. List obsahuje seznam všech plánovaných pracovních položek. Na základě tohoto seznamu jsou pak v záhlaví listu

39

vytvořeny celkové součty a kontrolní součty. U každé pracovní položky jsou evidovány následující data: 

Vazba na PBS (Product Breakdown Structure)



Řešitel



Iterace, ve které má být daná pracovní položka vyřešena



Procento dokončení – to určuje projektový manažer podle jím zvolené metriky. Může použít různá kritéria od pocitového odhadu až po striktní pravidla 0 %/50 %/100 %. Podle procenta dokončení se aktualizuje další položka – Zbývá práce.



Plán práce obsahuje hodinový plán pro jednotlivé řešitelské týmy, které si projektový manažer nadefinoval. Ty si mohl nadefinovat podle sebe, typicky se oddělují analytici, vývojáři, testeři a další role.



Vykázáno obsahuje sumu výkazů vykázaných na danou pracovní položku.

Aby bylo operativní řízení s pomocí tohoto nástroje efektivní, každá pracovní položka by měla obsahovat pouze relativně nezávislé úkoly s pracností do 40 hodin, které může řešit právě jeden zaměstnanec. Projektový manažer na začátku projektu vytvoří seznam úkolů, které musí v rámci projektu splnit. Jedná se o úplný seznam, nutný pro dokončení projektu nebo aktuální fáze projektu. Každý úkol musí ocenit počtem hodin nutných pro jeho dokončení. Následně si připraví plán alokace zdrojů na základě harmonogramu a alokovaných kapacit. Plánování končí iterativním ladění plánu alokace zdrojů a seznamu pracovních úkolů tak, aby každý úkol měl svého řešitele a stanovené další vlastnosti. Pokud má projektový manažer v souladu kapacitní plány s pracovními plány, může projekt považovat za naplánovaný. Následně každý týden reviduje na základě podkladů od řešitelů stav jednotlivých pracovních úkolů a aktualizuje klíčové informace – procento dokončení, předpokládaný termín dokončení. Modifikovat původní plánované hodnoty je možné pouze na základě změnového řízení, kdy došlo po dohodě s klientem ke změně rozsahu, kvality nebo termínu. Při změně rozsahu jsou ale typicky přidávány nebo ubírány celé pracovní úkoly. Po týdenní aktualizaci má projektový manažer k dispozici souhrnné vstupy pro Burndown Graph a další projektové metriky. Zároveň mu tabulka KKTR poskytuje

40

podkladová data pro vyhodnocení aktuálního stavu. Tedy jestli plánované kapacity stačí na dokončení projektu v termínu, jestli nejsou ohroženy dílčí milníky a jestli je potřeba nějaký zásah, například přidání nebo ubrání pracovních kapacit. 4.1.2.2.1 Vztah EVM a tabulky KKTR Struktura listu Scope umožňuje u každého úkolu určit základní EVM ukazatele, jako tomu bylo u Burndown Graph, pro který je tabulka KKTR podkladem. Projektový manažer tedy má k dispozici techniku EVM i na úrovni jednotlivých pracovních úkolů, jak ukazuje Tabulka 12. Tabulka 12 - Vztah základních ukazatelů EVM a úkolu v KKTR

Ukazatel EVM Plánovaná hodnota (PV)

Vztah k pracovnímu úkolu KKTR Plánovaná hodnota u jednotlivého úkolu je daná jeho pracností

a

naplánováním

v čase.

Nejhrubším

naplánováním v čase je plán iterace a jeho délka, projektový

manažer

může

použít

i

jemnějšího

plánování v čase. Skutečné náklady (AC)

Jsou zachyceny ukazatelem Vykázáno, založeném na sumarizaci dat z pracovních výkazů (List TSR).

Vytvořená hodnota (EV)

Ukazatel Zbývá práce je počítaným ukazatelem z Plánu práce a Procenta dokončení. Nicméně platí stejný vztah: Zdroj: Vlastní zpracování

4.2. Doporučení Popsaná část metodiky Unicorn Systems je pro řízení projektů a jejich efektivity z mého pohledu dostatečná a ucelená. Klade důraz na detailní plánování, pravidelné aktualizace operativního plánu a projektových informací a pravidelný reporting aktuálního stavu. Projektový manažer má dostatečné informace v každém okamžiku projektu – kde aktuálně je a kde měl být podle plánu. Navíc tyto informace efektivně sdílí se svojí nadřízenou řídící strukturou, ta má dostatek informací, aby se efektivně věnovala pouze projektům, kde jsou indikovány problémy.

41

Další pozitivní vlastností metodiky projektového řízení Unicorn Systems je její kodifikace v interním informačním systému a její průběžná aktualizace. Dochází k jejím aktualizacím na základě zpětné vazby od manažerů projektů nebo jejich nadřízených. Z mého pohledu by mělo dojít k hlubší integraci techniky Earned Value Management do projektové metodiky Unicorn Systems. Ve vlastním popisu metodiky a práce s KKTR jsou již nyní přímo používány názvy některých ukazatelů odpovídající názvům metody Řízení vytvořené hodnoty – jmenovitě EAC (estimate at completion) pro Aktualizovaný odhad, ETC (estimate to completion) pro Zbývá práce a ACWP (starší termín pro AC, actual cost of work performed) pro Vykázané hodiny. Odkazy na zdroje, ze kterých bylo čerpáno při popisu metodiky, jsou v některých případech shodné se zdroji této práce, největší shoda je v případě (SCHWALBE‚ 2007). Z toho důvodu mě překvapuje aktuální vzhled Burndown Graph (viz Obrázek 8 – Burndown Graph). Uvedenému zobrazení bych vytknul dvě základní věci: 

Výkaz hodin, odpovídající Actual Cost (AC) je zobrazován odděleně a s jinou orientací od ukazatelů plánované a zbývající práce. Použitý způsob zobrazení vypovídá více o vztahu mezi odpracovanými hodinami a kapacitním plánem (Plán hodin), není možné jednoduše vyčíst vztah vynaložených nákladů k ukazatelům plánované a zbývající práce.



Zobrazení plánu hodin a plánu práce je z informačního pohledu redundantní, jedná se o významově velmi podobné položky, pouze vycházející z různých datových podkladů.

Osobně bych doporučil pouze změnit vzhled Burndown Graph včetně zvolení vhodné terminologie. Návrh možného vzhledu je obrázku 9, návrh vychází ze stejné datové základy jako u obrázku 8.

42

Obrázek 9 - Návrh Burndown Graph


V rámci navrženého zjednodušení zobrazení jsem provedl následující změny: 

Odstranil jsem Plán hodin, který by zbytečně snižoval přehlednost zobrazení.



Křivku Výkaz hodin jsem přejmenoval na Actual Costs – toto přejmenování slouží zejména pro účely této práce.



Křivku Plán práce jsem nahradil křivkou Planned Value podle vztahu definovaného v kapitole 4.1.1.3.1



Křivku Zbývá práce jsem nahradil křivkou Earned Value podle vztahu definovaného v kapitole 4.1.1.3.1.



Křivku Bilance hodin jsem přejmenoval na Cost variance a protáhl na základě odhadů až do konce projektu. Křivku lze úplně vypustit, neboť v navrhovaném zobrazení je již jasně patrný rozdíl mezi křivkami Earned Value and Actual Cost. Nově navržené zobrazení dle mého názoru lépe ilustruje skutečný stav projektu

a jeho vývoj v čase než aktuálně používané zobrazení a je čitelnější pro širší spektrum rolí. Minimálně čtení vztahu mezi Planned Value and Earned Value je přirozenější, možnost jejich přímého jednoduchého porovnání s křivkou Actual Cost je velkou přidanou hodnotou navrhované změny. V optimální variantě, po zrušení křivky Cost

43

Variance, navržené zobrazení potřebuje méně křivek k poskytnutí více informací. Navíc způsob zobrazení je v souladu s technikou Earned Value Management, ke které lze dohledat množství zdrojů, informací a příkladů k použití, je tedy jednodušší pro adaptaci novými projektovými manažery i nadřízenou organizační strukturou. Případná aplikace navržených změn do projektové metodiky Unicorn Systems musí zejména vyřešit terminologii jednotlivých ukazatelů EVM. Pro snazší přijetí změny lze začít s českými názvy, které budou významově podobné současné terminologii a až později přejít na obecně známé termíny z metody Earned Value Management.

4.3. Vybrané projekty V této kapitole je na vybraných reálných projektech (bez uvedení jejich bližší identifikace) demonstrována doporučená změna zobrazení Burndown Graph. U každého projektu je doplněn krátký komentář k jeho stavu, každý projekt je pro ilustraci zasazen i do anonymizované realizační struktury. Ve společnosti Unicorn Systems je výrobní část organizačně rozčleněna do více částí, toto rozdělení vychází ze stylu řízení společnosti a projektů. Prvním stupněm dělení je rozdělení na produkční streamy. Ty lze chápat jako samostatné jednotky, z nichž každá obchoduje zakázky a realizuje zakázky. Rozdělení na produkční streamy vychází z reálných možností managementu těchto jednotek řídit efektivně určitý objem prací. Každý produkční stream je dále rozdělen do realizačních divizí, což jsou organizační jednotky, ve kterých jsou realizovány projekty. Každá realizační divize je schopna opět efektivně zvládat omezený počet projektů. Takto organizovaná dělba práce ponechává managementu streamu a divizí jistou volnost, spojenou s odpovědností za celkové výsledky těchto jednotek. V souladu s agregací pravidelného hodnocení (KOVÁŘ et. al.‚ 2009, s. 37) jsou pravidelná hodnocení projektů dostupná řediteli produkční divize, dále řediteli produkčního streamu spolu s pravidelným hodnocením výsledků celé realizační divize. Top managementu Unicorn Systems jsou pak dostupné všechny údaje, včetně pravidelného hodnocení výsledku celého streamu. Do celkového hodnocení jsou zapojeny projekty ze dvou různých realizačních divizí, každá z jiného produkčního streamu. Toto rozdělení je záměrné, ilustruje relativní samostatnost, kterou jednotlivé realizační jednotky mají v rámci organizační struktury. Tato samostatnost se týká i míry dodržování metodiky řízení projektů.

44

4.3.1. Divize 1 – Produkční stream 1 Divize 1 je součástí produkčního Streamu 1. V rámci celého produkčního streamu 1 jsem našel jediný projekt, který v rámci svého hodnocení poskytuje i silně modifikovaný Burndown Graph. Ostatní projekty ho ve svém Status Assesment neuvádějí. V době přípravy této práce došlo v produkčním streamu 1 k organizačním změnám, které se týkaly i produkčních divizí, z tohoto pohledu se jedná o pochopitelný stav. 4.3.1.1. Projekt 1 Projekt 1 je rozvojový projekt, jedná se o jednu z mnoha etap rozvoje jednoho rozsáhlého informačního systému. Takový rozvoj probíhá více než deset let. Níže uvedený graf na Obrázku 10 je aktualizován měsíčně, ačkoliv pravidelný Status Assesment probíhá standardně každý týden. Obrázek 10 - Projekt 1 - stávající stav


Z podkladů poskytnutých Projektem 1 vyplývá, že pro projekt není vedena standardní tabulka KKTR. Projekt je řízen na základě plánu kapacit a sledování jejich čerpání – položky Plán PBC + rizika, Plán PBC bez rizik a Skutečnost celkem. Konkrétní vztah k vytvořené hodnotě ilustruje křivka Stav prací, ta je aktualizována týdně. Stav

45

prací je počítán pouze do milníku FAT, včetně oddělené části rozpočtu na dosažení tohoto milníku. Další plány jsou už jen kapacitní. Pokud bychom se pokusili aplikovat techniku Earned Value Management na obdržená data, dostaneme prakticky identický graf. Křivka Plán PBC bez rizik odpovídá Planned Value, křivka Skutečnost celkem odpovídá Actual Cost a křivka Stav prací odpovídá křivce Earned Value. Problémem při aplikaci techniky Earned Value Management je nepřímý vztah kapacitních plánů (Plán PBC bez rizik) a Stavu prací, kapacitní plán obsahuje i další nákladové položky, které nejsou zahrnuty do rozpočtu milníku FAT. Celkově lze hodnotit Projekt 1 jako řízený nedostatečně, respektive způsob řízení neumožňuje dostatečně měřit průběžně efektivitu projektu. Naopak způsob grafické reprezentace sledovaných ukazatelů je přehlednější než standardní vzhled předepsaný metodikou Unicorn Systems a nemá v rámci této práce žádnou přidanou hodnotu na tento vzhled aplikovat navržená vylepšení. 4.3.2. Divize 2 – Produkční stream 2 Divize 2 je vybraná záměrně, jako zástupce úspěšného produkčního streamu. Celý produkční stream 2 má aktuálně nejlepší výsledky v počtu, objemu i výsledcích realizovaných projektů. 4.3.2.1. Projekt 2 Projekt 2 ilustrovaný Obrázkem 11 je již ukončeným a uzavřeným projektem. Obrázek 11 - Projekt 2 - stávající stav

46


Projekt 2 byl dokončen v termínu a rozpočtu – i ze stávajícího zobrazení je zřejmý rozdíl mezi plánovanými hodinami a odpracovanými hodinami. Rozdíl mezi křivkami Plán práce a Zbývá práce ukazuje, že většinu času byly plánované dodávky v předstihu. Podle mého názoru lze tento průběh lépe vyčíst ze zobrazení vycházejícího z techniky Earned Value Management. Obrázek 12 - Projekt 2 - navržené zobrazení

Předstih dodávek v čase Úspora nákladů


Obrázek 12 ukazuje, že křivka Earned Value je po celou dobu projektu nad křivkou Planned Value, to znamená, že práce postupovaly rychleji než bylo plánováno, dodávky byly v předstihu. S výjimkou prvních týdnů projektu byly náklady Actual Cost vždy pod křivkou Earned Value. Tedy projekt vynakládal zdroje efektivněji, než bylo původně plánováno. Celkově lze hodnotit průběh Projektu 2 jako optimální z pohledu výsledků, průběh v prvních týdnech projektu naznačoval možné problémy s efektivitou, ty ale mohly být způsobeny postupným zpřesňováním operativního plánu na začátku projektu. 4.3.2.2. Projekt 3 Projekt 3 na Obrázku 13 je těsně před dokončením – již je nasazen do produkčního prostředí, zbývá projekt pouze stabilizovat a předat do standardního servisního režimu.

47

Obrázek 13 - Projekt 3 - stávající stav


Ze stávajícího zobrazení lze jednoduše vyčíst, že projekt spotřebovával méně hodin, než bylo plánováno, ale nakonec dojde k překročení rozpočtu. Graf obsahuje i chybu projektového manažera, který neaktualizoval odhad hodin do konce projektu – tato chyba je zobrazena poklesem křivky Odhad hodin na konci projektu. Nízká spotřeba hodin byla způsobena zpožďováním prací – křivka Zbývá práce se stabilně pohybovala nad křivkou Plán práce. Na konci července došlo k upřesnění operativního plánu, které se projevilo nárůstem křivky Zbývá práce. Zobrazení s využitím techniky Earned Value Management na Obrázku 14 je z pohledu hodnocení průběhu projektu výrazně čitelnější. Upřesnění operativního plánu na konci července se projeví poklesem křivky Earned Value. Na první pohled je zřejmé, že vytvářená hodnota odpovídá nákladům – čerpání lidských zdrojů. Z rozdílů Planned Value a Earned Value lze okamžitě poznat, že projekt byl z pohledu dodávání ve zpoždění od poloviny července, maximální hodnota zpoždění proti plánu dosahovala až 6 týdnů.

48

Obrázek 14 - Projekt 3 - navržené zobrazení

Upřesnění plánu Zpoždění dodávek v čase


Z pomocí navrženého zobrazení jsme tedy schopni lépe sledovat skutečný průběh projektu. Dodávky, které měly vstupovat do milníku UAT (Uživatelské akceptační testy) byly dodělávány až v průběhu těchto testů, některé z nich i po nasazení do produkčního prostředí. Projekt nakonec mírně překročí plánovaný rozpočet, ale z průběhu projektu je vidět, že projektový manažer upřednostnil při řízení nákladovou stránku před dodržením milníků. Tento postup lze ale považovat za nejefektivnější z pohledu celkového výsledku. 4.3.2.3. Projekt 4 Projekt 4 ilustruje průběh projektu s navýšením scope v průběhu projektu. Dojde tedy ke změně Směrného plánu. Vzhledem k tomu, že manažer projektu nepoužívá ve stávajícím zobrazení křivku Kontrakt, což je ekvivalent hodnoty Směrného plánu, je těžší se ve výsledných grafech zorientovat, jak ukazuje Obrázek 15.

49



Ve stávajícím zobrazení je trend do poloviny října jasný – projekt byl v předstihu, spotřebovával ale více zdrojů než bylo původně plánováno. Po polovině října došlo k výraznému navýšení scope, od této chvíle ale projekt byl ve zpoždění. Za zmínku stojí plán hodin, který překračuje hodnotu kontraktu, tedy při navyšování scope už bylo zřejmé, že dojde k překročení rozpočtu.

50


Změna scope není z grafu zřejmá.


V nově navrženém zobrazení na Obrázku 16 ale není vidět zmíněná změna Směrného plánu. Z průběhu křivek lze pouze vyčíst, že z počátku projekt byl v časovém předstihu, náklady byly čerpány adekvátně odvedeným pracím. Od poloviny září ale projekt začíná nabírat zpoždění, změna směrného plánu se na průběhu křivek nijak neprojeví – museli bychom mít k dispozici verzi grafu před změnou plánu a po změně, abychom mohli navýšení scope identifikovat. Předpokládaný průběh konce projektu je podobný Projektu 3, pouze dojde k většímu překročení rozpočtu. Toto překročení je sice plánované, z nového zobrazení ale tuto informaci nelze vyčíst bez existence křivky Kontrakt. V této situaci by hodnota Planned value překračovala křivku Kontrakt, pak by bylo zřejmé, že Směrný plán počítá s plánovaným překročením rozpočtu a v jakém rozsahu. 4.3.2.4. Projekt 5 Projekt 5 opět ilustruje projekt, u kterého došlo k navýšení rozsahu. V tomto případě ale manažer projektu využívá křivku Kontrakt, takže je z Obrázku 17 na první pohled zřejmé, kdy a v jakém rozsahu došlo ke změně.

51



Ve stávajícím zobrazení je přehledně vidět změna rozsahu, k posunu křivky Kontrakt ale dochází až o týden později než ke změně v plánu prací, to je pravděpodobně způsobeno nepozorností manažera. Z pohledu vývoje projektu lze říci, že se před změnou scope začal dostávat do zpoždění, přitom čerpání zdrojů bylo větší než plánované. Podle odhadovaných hodnot se po rozšíření projektu podaří toto zpoždění odstranit, pravděpodobně i v plánovaném rozpočtu.

52


Navýšení scope

Problémy s náklady ještě před změnou scope


V tomto případě s využitím změny křivky Kontrakt je v navrženém zobrazení na Obrázku 18 jasně vidět změna rozsahu. Tato změna se projevila také poklesem hodnot Planned Value and Earned Value, které jsou způsobeny změnou Směrného plánu. Z průběhu ale lze vidět, že před vlastní změnou se projekt dostával do skutečných problémů – byl ve zpoždění a výrazně překračoval plánované náklady. Dá se předpokládat, že právě tyto problémy byly jedním z důvodů, proč došlo ke změně scope projektu. Výsledkem změn je aktualizovaný plán, který umožní projekt dokončit v nově plánovaných nákladech a i termínech.

53

5. Závěr Záměrem práce bylo zhodnotit současnou metodiku řízení projektů ve společnosti Unicorn Systems z pohledu měření a řízení efektivity fix-price fix-time projektů. Součástí hodnocení je i navržení úprav této metodiky a ilustrace těchto úprav na anonymizovaných datech z vybraných existujících projektů. V teoretické části práce definuje vlastní efektivitu fix-price fix-time projektů jako míru účelnosti vynaložených zdrojů k dosažení jednoho z přípustných řešení projektu. Přípustná řešení se mohou lišit v základních charakteristikách – kvalitě, kvantitě, termínu a rozpočtu. Z pohledu měření efektivity se míra splnění jednotlivých charakteristik odráží ve vynaložených nákladech. Míra efektivity je pak definována poměrem plánovaných a vynaložených nákladů. Aby bylo možné sledovat ukazatele efektivity i dynamicky, na běžících projektech, musí takový projekt splňovat takové předpoklady v oblasti způsobu plánování a průběžného hodnocení, které umožní v libovolném okamžiku porovnat plánovaný stav se stavem skutečným k danému datu. Na takových projektech lze měřit aktuální i předpokládanou efektivitu a s touto hodnotou dále pracovat. Nejrozšířenějším způsobem průběžného hodnocení efektivity a průběhu projektu je technika Earned Value Management, která je dlouhodobě používána na různé, nejen softwarové projekty, a je podporována i nejrozšířenějšími nástroji pro řízení projektů, jako je Microsoft® Project. Projektová metodika Unicorn Systems, jejíž část byla popsána v této práci, poskytuje dostatečné nástroje pro řízení a měření efektivity realizovaných projektů. Je postavena na podrobném plánování pomocí tabulky KKTR, která umožňuje porovnávat plánovaný a skutečný stav projektu v libovolném časovém okamžiku. Po ukončení projektu lze spočítat všechny ukazatele efektivity a produktivity, tyto jsou používány pro závěrečné hodnocení projektu. Zároveň je nastavena pravidelná týdenní aktualizace informací v tabulce KKTR a jejich reportování nadřízeným organizačním složkám. Projektová metodika Unicorn Systems tedy umožňuje i dynamické měření ukazatelů efektivity, projektoví manažeři mají k dispozici všechny potřebné informace, zároveň metodika předepisuje i jejich vizualizaci v čase pomocí grafu Burndown Graph. V oblasti vizualizace vývoje ukazatelů projektu navrhuji výrazné zjednodušení Burndown Graph založeném právě na technice Earned Value Management, protože

54

podkladová tabulka KKTR obsahuje všechny potřebné informace pro použití této techniky. Nově navržené zobrazení je dle mého názoru čitelnější pro všechny role, které se účastní projektu nebo jsou čtenáři pravidelného hodnocení projektu. Na příkladech existujících projektů jsem porovnával vypovídací hodnotu stávajícího a nového zobrazení Burndown Graph. Pro ilustraci všech možností stačí tři základní křivky – vývoj Planned Value, Earned Value a Actual Cost – doplněné o křivku nazývanou Kontrakt, která zachycuje změny rozsahu projektu a tím i změnu celkové hodnoty Směrného plánu. Celkově lze tedy hodnotit metodiku řízení projektů v Unicorn Systems jako dostačující a ucelenou z pohledu řízení efektivity projektů. Osobně bych doporučil postupně v rámci aktualizací metodiky větší příklon k použití techniky Earned Value Management. Prvním krokem by měla být změna zobrazení Burndown Graph a nastavení všeobecně chápané terminologie pro jednotlivé ukazatele. Jsem přesvědčen, že tato drobná změna by zvýšila použitelnost vizualizace Burndown Graph takovým způsobem, že ho budou manažeři streamů a realizačních divizí více požadovat po manažerech projektů, než je tomu v současném stavu.

55

6. Conclusion The aim of the study was to evaluate the current project management methodology at Unicorn Systems in terms of fix-price fix-time project efficiency measurement and control. The study is also proposing modifications to this methodology and illustrates these changes on anonymized data from selected existing projects. In the theoretical part study defines effectiveness of fix-price fix-time projects as a measure of the effectiveness of resources spent to achieve one of the acceptable project solutions. Acceptable solutions can vary in the basic characteristics - quality, scope, time and budget. In terms of measuring the effectiveness the compliance rate of individual characteristics is reflected in the realized project costs. The effectiveness rate is then defined by the ratio of planned and realized costs. In order to monitor the efficiency indicators dynamically on running projects, such projects must meet such requirements in the way of planning and regular assessment that will allow compare planned state with actual state at any time. On such projects current and expected efficiency can be measured and this value can be used further. The most common way of evaluating the effectiveness and progress of the project is the technique Earned Value Management, which has been used long time for a variety, not just software projects, and is supported by the most widely used project management tools such as Microsoft ® Project. Unicorn Systems project management methodology, part of which was described in this study, provides sufficient tools for managing and measuring the effectiveness of implemented projects. It is based on detailed planning using the QSTB table, which allows you to compare planned and actual project status at any time. On finished projects all the indicators of efficiency and productivity can be counted, these are used for the final evaluation of the project. There is also set up regular weekly update of information in the QSTB table and its reporting to the superior departments. Unicorn Systems project management methodology therefore allows also dynamic measurement of effectiveness indicators; project managers have all the necessary information available. The methodology also describes indicator visualization over the time using Burndown Graph. In the field of presentation project indicators development I propose a significant simplification of Burndown Graph. New presentation is just based on the Earned Value

56

Management technique, because the underlying QSTB table contains all the information needed to use this technique. In my opinion the newly designed visualization is better readable by all the roles that participate in the project or by the readers of regular project status assessment. On the examples from existing projects I compared the informative value of existing and new style of Burndown Graph. To illustrate all the characteristics of project state just three basic curves are needed – development of Planned Value, Earned Value and Actual Cost - complemented by a curve called a Contract, which records changes in project scope, and thus the change in the total value of the Baseline plan. I can evaluate the project management methodology in Unicorn Systems as sufficient and complete in terms of project efficiency management. Personally I would recommend partially updating the project management methodology with greater focus on Earned Value Management technique. The first step should be to change proposed change of Burndown Graph and setting universally understood terminology for each indicator used. I am convinced that this small change would increase the usability of Burndown Graph in such a way, that stream managers and division managers will require from more project managers to fulfill Burndown Graph in project status assessment compared to current state.

57

7. Seznam použitých zdrojů CONELL, S. M.‚ 2006. Odhadování softwarových projektů. Brno: Computer Press. ISBN 80-251-1240-3. Earned Value Management (EVM)‚ 2010. In: NASA [online].2010 [cit. 2013-1130]. Dostupné z: http://evm.nasa.gov/ Earned Value Management‚ 2001. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikipedia Foundation, 2001, naposledy upraveno 26.10.2013 [cit. 2013-11-30]. Dostupné z: http://en.wikipedia.org/wiki/Earned_value_management JøRGENSEN, M.‚ 1999. Software quality measurement. In: Advances in Engineering Software. 30, s. 907–12. KOVÁŘ, V. et al.‚ 2009. Unicorn ES Powered Company - Management. 1. revidované vydání. Praha: Unicorn College, 120 s.. ISBN 978-80-87349-01-4. PETRÁČKOVÁ, V. J. KRAUS a KOLEKTIV‚ 1998. Akademický slovník cizích slov. 1. (dotisk). Praha: Academia, 834 s.. ISBN 80-200-0607-9. PROJECT MANAGEMENT INSTITUTE‚ 2004. A guide to the project management body of knowledge : (PMBOK guide). 3rd edition. Newton Square: Project Management Institute, Inc, 338 s.. 193069945X. SCHWALBE, K.‚ 2007. Řízení projektů v IT. Překlad David KRÁSENSKÝ. Brno: Computer Press, 720 s.. ISBN 978-80-251-1526-8. Autorizovaný český překlad z z originálního anglického vydání Information Technology Project Management, 4th Edition. UK SOFTWARE MEASUREMENT ASSOCIATION‚ 1998. MkII Function Point Analysis: Counting Practices Manual. version 1.3.1. UKSMA Metrics Practices Committee. UNICORN SYSTEMS‚ 2000. USY Production Methodology. Unicorn Information System [online], verze 2013 [cit. 2013-11-30]. Dostupné z: https://plus4u.net UNICORN SYSTEMS‚ 2012. Profil společnosti. Web Unicorn Systems [online] [cit. 2012-08-07]. Dostupné z: http://www.unicornsystems.eu/cz/o-spolecnosti/profilspolecnosti.html

58

8. Seznam obrázků Obrázek 1- Množina přípustných řešení ............................................................................... 13 Obrázek 2 – Měření běžících projektů.................................................................................... 20 Obrázek 3- Příklad vizualizace vytvořené hodnoty .......................................................... 27 Obrázek 4 - Ukazatele EVM v Microsoft Project ................................................................. 28 Obrázek 5 - Sestava vytvořené hodnoty ................................................................................ 28 Obrázek 6 - Grafická vizualizace vytvořené hodnoty ....................................................... 29 Obrázek 7 - Příklad EVM - Vizualizace průběhu ................................................................. 33 Obrázek 8 - Burndown Graph .................................................................................................... 36 Obrázek 9 - Návrh Burndown Graph ...................................................................................... 43 Obrázek 10 - Projekt 1 - stávající stav .................................................................................... 45 Obrázek 11 - Projekt 2 - stávající stav .................................................................................... 46 Obrázek 12 - Projekt 2 - navržené zobrazení ...................................................................... 47 Obrázek 13 - Projekt 3 - stávající stav .................................................................................... 48 Obrázek 14 - Projekt 3 - navržené zobrazení ...................................................................... 49 Obrázek 15 - Projekt 4 - stávající stav .................................................................................... 50 Obrázek 16 - Projekt 4 - navržené zobrazení ...................................................................... 51 Obrázek 17 - Projekt 5 - stávající stav .................................................................................... 52 Obrázek 18 - Projekt 5 - navržené zobrazení ...................................................................... 53

59

9. Seznam tabulek Tabulka 1- Charakteristiky projektu ...................................................................................... 17 Tabulka 2 - Základní ukazatele ................................................................................................. 18 Tabulka 3 - Odvozené ukazatele .............................................................................................. 19 Tabulka 4 - Odvozené ukazatele EVM .................................................................................... 24 Tabulka 5 - Příklad EVM - Směrný plán ................................................................................. 30 Tabulka 6 - Příklad EVM - Stav po 1. týdnu .......................................................................... 30 Tabulka 7 - Příklad EVM - Stav po 2. týdnu .......................................................................... 31 Tabulka 8 - Příklad EVM - Stav po 3. týdnu .......................................................................... 32 Tabulka 9 - Příklad EVM - Stav po 4. týdnu .......................................................................... 33 Tabulka 10 - Ukazatele Burndown Graph ............................................................................. 37 Tabulka 11 - Vztah ukazatelů EVM a Burndown Graph .................................................. 38 Tabulka 12 - Vztah základních ukazatelů EVM a úkolu v KKTR ................................... 41

60

UNICORN COLLEGE. Katedra informačních technologií BAKALÁŘSKÁ PRÁCE. Měření efektivity fix price fix time projektů

Recommend Documents