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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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č
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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č
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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ů.
(
(
)
)
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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ů
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Zdroj: Vlastní zpracování
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
Obrázek 15 - Projekt 4 - stávající stav
Zdroj: Vlastní zpracování
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
Obrázek 16 - Projekt 4 - navržené zobrazení
Změna scope není
z grafu zřejmá.
Zdroj: Vlastní zpracování
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
Obrázek 17 - Projekt 5 - stávající stav
Zdroj: Vlastní zpracování
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
Obrázek 18 - Projekt 5 - navržené zobrazení
Navýšení scope
Problémy s náklady
ještě před změnou
scope
Zdroj: Vlastní zpracování
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