PROJEKTOVÉ ŘÍZENÍ – ZÁKLADNÍ PŘÍSTUPY Ing. Jindřich Koželuh Ing. Vít Maňhal
studijní materiál ke kurzu Projektový management
Fakulta informatiky a managementu Univerzity Hradec Králové Projekt Informační, kognitivní a interdisciplinární podpora výzkumu je spolufinancován Evropským sociálním fondem a státním rozpočtem České republiky.
Obsah 1
O projektu
2
1.1
Co je projekt
2
1.2
Atributy projektu
3
1.3
Cíle projektu
4
1.4
Rozsah projektu
4
2
Organizace projektu 2.1
2.1.1 2.1.2 2.1.3 2.1.4
Organizační složky projektu Řídící výbor Vedení projektu Projektový tým Pracovní skupiny
5 5 6 7 7 8
Komunikační matice
8
Plánování a průběh projektu
9
3.1
Cílový koncept řešení
9
3.2
Fáze projektu
9
2.2
3
3.2.1 3.2.2 3.2.3 3.2.4
3.3
3.3.1
Zahájení projektu Návrh řešení Výstavba a realizace řešení Zahájení provozu
Struktura projektu
Hierarchická struktura prací
9 10 10 10
11 11
3.4
Matice odpovědnosti
13
3.5
Harmonogram projektu
13
3.6
Plán řízení rizik projektu
14
3.7
Řízení změn v projektu
15
4
Vyhodnocení projektu
15
5
Příloha – hodnotící projektové ukazatele
16
1
O projektu
1.1
Co je projekt
Projektem označujeme množinu činností, která má daný čas určený na provedení projektu, stanovený začátek a konec a přidělené zdroje. Projekt je charakterizován jedinečností podmínek pro jeho provedení, jako jsou určený nebo omezený čas, definované náklady, ve kterých musí být projekt realizován, kvalitativní kritéria provedení projektu. Dalšími faktory, které definují projekt může být legislativní rámec, ve kterém se provedení projektu může pohybovat, obecně i klimatické
podmínky nebo roční doba atd.). Projekt je většinou charakterizován průběžnými změnami, které jeho realizaci provázejí a v neposlední řadě i specifickou organizací jak pracovních postupů, tak lidí, kteří se na realizaci projektu nějakým způsobem podílejí. Projekt tedy není opakovaná činnost, která probíhá ve stejných podmínkách v pravidelných nebo nepravidelných intervalech 1.2
Atributy projektu
Základními atributy projektu jsou:
Unikátnost postupů a podmínek – prakticky žádný projekt, i ten, který vychází z nějakého předcházejícího podobného řešení, není prováděn v identických podmínkách, ať už v čase, s týmiž účastníky, v naprosto stejném časovém rámci a za stejných podmínek nákladů. S měnícími se podmínkami je nutné volit i odpovídající úpravy postupů Necykličnost – projekt je realizován jako jednorázová akce, i když v čase může trvat různě dlouhou dobu, a její struktura podprojektů a činností může být velmi bohatá. V praxi to znamená, že projekt má svůj začátek, svůj průběh a jednoznačně definovaný konec a tato sekvence se neopakuje ani v jediném cyklu. Prostředí pro realizaci – i velmi podobné projekty, jako je například stavba rodinného domu podle stejné nebo velmi podobné výkresové dokumentace, naráží při své realizaci na různé vlivy prostředí. Stejný typ rodinného domu se nikdy nestaví na identickém místě (je zde nesporně vliv podloží), v identickou dobu (klimatické podmínky nebo roční doba) a s identickými lidmi, ať už na straně zástupce investora (zadavatele projektu), tak na straně týmu, který projekt realizuje. Prostředí navíc může ovlivňovat projekt jak kladně (příznivé okolnosti motivují účastníky k vyššímu výkonu), tak často záporně. Vymezení v čase – každý projekt má daný svůj časový rámec, do kterého je zasazen. Od zahájení projektu, přes realizaci dílčích podprojektů až po finalizaci díla k určitému termínu. Pro pohyby projektu mezi zahájením a koncem projektu je stanoven harmonogram průběhu s milníky, v nichž se hodnotí časové plnění projektu. Nadprůměrný výskyt rizik – v důsledku různých systémových, ale i nahodilých příčin vznikají nejrůznější rizika. Některá rizika lze předvídat a je možné s nimi počítat, mnohá rizika ale vznikají v průběhu trvání projektu nahodile. O řízení rizik, jako důležitém průvodci každého projektu, bude zmínka i v kapitole Plánování projektu. Zdroje projektu – každý projekt pracuje se zdroji, které mají většinou svá omezení Realizace projektovým týmem – pro většinu projektů platí, že projektový tým není, co se svého složení týká, univerzálně platná organizační jednotka, ale většinou se jedná o seskupení lidí, které je poplatné právě jedné unikátní
projektové realizaci. Projektový tým je pak stavěn s ohledem na dříve uvedené atributy projektu a jeho složení může být i v čase proměnné. 1.3
Cíle projektu
Cíle projektu většinou vycházejí ze strategie zadavatele (investora) projektu. Stanovení cíle je nutné formulovat co nejkonkrétněji tak, aby se pro výstupy z projektu dalo jednoznačně určit, zda cíle byly naplněny. V takové případě hovoříme o měřitelných cílech, ať v čase, nákladech, anebo v obou veličinách najednou. V souvislosti s projekty a projektovými cíli v závislosti na čase a nákladech používáme termín „Trojimperativ projektového řízení“. Trojimperativ si lze znázornit jako trojúhelník, jehož vrcholy jsou uvedené veličiny. V praxi to znamená, že jestli se změní jedna z veličin – cíl, čas, náklady – a další má zůstat zachována, pak se musí odpovídajícím způsobem změnit veličina třetí (zvýšení nákladů, zkrácení času, úprava cílů) Projekt může řešit jeden nebo více cílů jedné celkové strategie. V rámci jednoho projektu to pak v praxi znamená řešit dílčí podprojekty s konkrétními výstupy.
Cíle (max)
Čas (min)
Náklady (min)
Obr. 1: Trojimperativ projektového řízení
1.4
Rozsah projektu
Definování rozsahu projektu (Project Scope Definition) a jeho následné zafixování je základní podmínkou pro jednoznačné určení průběhu projektu a jeho výstupů v čase a nákladech. Rozsah projektu by tedy měl zahrnovat všechny požadované výstupy projektu. Při definování rozsahu projektu je také nezbytné přesně určit, co všechno má projekt řešit, a na druhé straně je vhodné určit, co projekt řešit nemá. Jako pomůcka může posloužit i technika, která přesně definuje vše, co není
součástí projektu, tedy to, co nebude v rámci projektu řešeno. Projekt tedy musí mít jednoznačně dané hranice, a to nejen z pohledu věcného, ale i pohledu časového a z pohledu výše nákladů. V průběhu realizace projektu není vhodné měnit rozsah projektu. Pokud již k úpravě rozsahu projektu musí dojít, pak je nutné, aby tato úprava prošla řádně zdokumentovaným změnovým řízením. V opačném případě hrozí nemalé riziko, neboť změna v rozsahu projektu v průběhu realizace může vést až ke ztrátě kontroly nad projektem. Změna rozsahu projektu má pak zásadní vliv i na chování části trojimperativu. Dobře definovaný rozsah (hranice) projektu a kvalitně řízená konfigurace výstupů projektu jsou nezbytným předpokladem úspěšného dosažení cílů, především u složitějších projektů. Správné vymezení hranic ušetří v průběhu realizace projektu, a především při jeho ukončování a předávání, nemálo konfliktů zadavatele a dodavatele. Bez definování rozsahu není podle čeho projekt vyhodnotit, neboť pak není zřejmé, zda bylo či nebylo dosaženo trojimperativu daného projektu. 2
Organizace projektu
Pro řešení projektu je při jeho zahájení nutno stanovit týmy projektu odpovědné za projektové činnosti a zároveň stanovit jednoznačné rozhodovací pravomoci. 2.1
Organizační složky projektu
Typickou strukturou projektů, a nejen projektů implementace informačních systémů, zobrazuje následující obrázek. Vlastní složení jednotlivých výborů nebo vedení projektu je pak poplatné problematice projektem řešené. Organizační složky projektu jsou pak stavěny s ohledem na dříve uvedené atributy projektu a jejich složení může být i v čase proměnné. Obsazení jednotlivých pracovních týmů je ale poplatné právě jedné konkrétní projektové realizaci a jejímu charakteru. Pro většinu projektů platí, že projektový tým není, co se svého složení týká, univerzálně platná, stálá organizační jednotka.
Obr. 2: Organizační schéma projektu
Povinnosti jednotlivých organizačních složek projektu jsou rámcově popsány v následujících kapitolách. 2.1.1 Řídící výbor Řídící výbor – Steering Committee (dále také ŘV) je nejvyšším orgánem projektu, s nejvyšší rozhodovací kompetencí. Skládá se většinou ze zástupců vedení zákazníka i dodavatele. Projektoví vedoucí se zúčastňují jednání ŘV jako přizvaní hosté. Další účastníci jednání mohou být v případě potřeby pozváni na základě dohody obou stran. Řídící výbor projednává stav projektu na základě zpráv předkládaných oběma vedoucími projektu. Příklad projektových povinností a pravomocí Řídícího výboru v projektu implementace informačního systému:
schvaluje hlavní výstupy projektu předložené vedoucími projektu, tj. dokumenty, které podmiňují zahájení následného kroku implementace
schvaluje všechny změny mající dopad na harmonogram a rozpočet projektu, vždy na základě návrhů vedoucích projektu
zajišťuje podmínky pro realizaci projektu v oblastech, které přesahují pravomoci vedoucích projektu (zadávání úkolů, přidělování kapacit, určování priorit) vždy na základě návrhů vedení projektu
rozhoduje o způsobu řešení závažných problémů na základě variantních návrhů předkládaných vedoucími projektu
sleduje kontrolu kvality a rizika projektu
stanovuje schvalovací pravomoci pro vedoucí projektu
2.1.2 Vedení projektu Projekt řídí vedoucí projektu zákazníka i dodavatele ve vzájemné součinnosti. Příklad projektových odpovědností a pravomocí vedení projektu v projektu implementace informačního systému:
Za naplánování a operativní řízení všech projektových aktivit pracovníků dodavatele, jako například termíny a obsah konzultací, školení, jednání projektového týmu, plánování kontrolních dnů, jednání řídícího výboru, atd., zodpovídá vedoucí projektu dodavatele tak, aby byly v určených termínech a potřebné kvalitě provedeny všechny plánované projektové aktivity každé fáze projektu. Za dodržení plánu a řízení všech projektových aktivit pracovníků zákazníka, jako například uvolňování garantů a klíčových uživatelů, případně dalších pracovníků na konzultace, školení, jednání projektového týmu, atd., zodpovídá vedoucí projektu zákazníka tak, aby bylo možné realizovat všechny plánované projektové aktivity v plánovaných termínech a náležité kvalitě. V případě, že vedoucí projektu nemohou v rámci své kompetence o nějaké záležitosti projektu rozhodnout (změna rozsahu, rozpočtu, časového plánu projektu, atd.), postupují příslušné projektové záležitosti k rozhodnutí na úroveň členů ŘV. Vedoucí projektu zákazníka i dodavatele se scházejí na pravidelných schůzkách vedení projektu, jejichž předmětem je projednání aktuálního postupu prací, úzká nebo kritická místa projektu a minimalizace jejich dopadů na projekt.
2.1.3 Projektový tým Projektový tým (nebo také Hlavní tým projektu – HTP) tvoří vedení projektu a garanti jednotlivých oblastí, a to jak ze strany dodavatele, tak ze strany zákazníka. Klíčovou úlohou schůzek Projektového týmu je koordinace činností jednotlivých pracovních skupin oblastí, jejichž garanti a klíčoví uživatelé se na implementaci řešení podílejí, a dále vzájemné informování členů Projektového týmu o postupu prací na projektu.
2.1.4 Pracovní skupiny Výkonné složky projektu (naplnění potřeb v řešených oblastech, uživatelská přizpůsobení a nastavení, testování, akceptace dokumentace), provádí reporting pro operativní .vedení projektu. V pracovních skupinách jsou realizovány úlohy projektu stanovené na nejnižších úrovních struktury projektu (viz kapitola Plánování projektu). 2.2
Komunikační matice
Komunikační matice je nezbytnou součástí projektu nejen pro vzájemnou informovanost všech členů projektových týmů o telefonním a mailovém či dalším spojení, ale zároveň informuje o pozicích jednotlivých účastníků projektu jak v projektu, tak případně v organizaci dodavatele nebo zákazníka. Důležitou součástí komunikační matice je kalendář plánované nepřítomnosti jednotlivých účastníků projektu, ať již z důvodů služebních nebo z důvodu čerpání dovolené. Nedílnou součástí komunikační matice je rozdělení účastníků podle příslušnosti do skupin podle různých pohledů. Jedná se o skupiny členěné následovně:
role v projektu – např. projektový manažeři, manažer rizik, manažeři podprojektů, technická skupina, atd. smluvní strany – např. pracovníci dodavatele, subdodavatelů, investora, stavební dozor, atd. pracovní skupiny – řídící výbor, vedení projektu, ekonomové, kopáči, programátoři, atd. distribuční skupiny – podle klíče příslušnosti k některé z takových skupin se řídí distribuce provozní projektové dokumentace, tzn. Zápisů z jednání, rozhodnutí řídícího výboru, záznamů o kontrole pracoviště, atd. eskalační skupiny – směrují účastníky projektu, kam se mají obracet v momentě, když nejsou kompetentní vyřešit nějakou situaci ze své pozice. Pravidlem v takovém případě bývá, že s příslušníci eskalační skupiny obracejí na členy eskalační skupiny nejblíže vyšší.
V praxi pak záleží na charakteru, rozměru a důležitosti projektu, zda jsou všechny komunikační skupiny využívány a v jakém rozsahu.
Komunikační matice projektu INKOV
PM RM Architekt řešení Majitel Ředitel Specialista HR
x x x
x
x x x
x x x x x
x x x
x
Eskalace 3. úroveň Infrastruktura
Eskalace 2. úroveň Infrastruktura
Eskalační skupiny
Distribuční skupiny
Eskalace 1. úroveň Infrastruktura
Zápis IHTP
Zápis HTP
Zápis ŘV
x x x x
x
Eskalač ní skupiny
Distribuční skupiny
Týdenní reporty
Kompetenční centrum
Interní řídící výbor (IRV)
Hlavní tým podpory projektu (HTPP)
Pracovní skupiny
x x x
x
Řídící výbor (RV)
Dodavatel
Zákazník
Incident Manager
Risk Manager
Novák Jan Nový Milan Starý Josef Mladá Jana Horká Andrea Kohout Karel
Funkce
Service Manager
ALFA BETA GAMA DELTA EPSILON OMEGA
E-mail
Smluvní strany
Role
Příjmení, Jméno Telefon
Quality Manager
Organi zace
Pracovní skupiny
Sml. Str.
Role
x x x
x x x
x x
x x
x x
Obr. 3: Příklad komunikační matice
3
Plánování a průběh projektu
3.1
Cílový koncept řešení
Cílový koncept řešení, často také nazývaný Definiční dokument řešení (Solution Definition Document – SDD), Popis řešení, Popis projektu, apod. je nejdůležitější dokument pro realizaci projektu. V dokumentu je řešení detailně rozpracované do konkrétních kroků a popisuje vlastní řešení předmětu projektu. Cílový koncept je v podstatě projektová dokumentace. Některé součásti cílového konceptu jsou uvedeny i v následujících kapitolách. 3.2
Fáze projektu
Projekt ve svém životním cyklu prochází několika fázemi, kterých literatura uvádí tři až pět. Jeden ze zdrojů uvádí fáze předprojektovou - definiční, projektová – realizační a nakonec poprojektovou – vyhodnocovací. Jiný zdroj uvádí fáze iniciační, mapovací, návrhovou, realizační a produkční. Co která z fází projektu obnáší je uvedeno dále. 3.2.1 Zahájení projektu Do fáze zahájení projektu spadá především studie proveditelnosti projektu a obchodní jednání zúčastněných stran, které vrcholí podpisem smluv. V této fázi dochází ke stanovení cílů, rozsahu projektu, dochází k definici projektových povinností a odpovědností, vznikají projektové týmy. Výstupem této fáze je definované řešení a jeho základní rozsah odsouhlasený smluvními stranami.
3.2.2 Návrh řešení Na základě mapování v rámci studie proveditelnosti dochází v této fázi k návrhu řešení, zpracování základní projektové dokumentace, upřesňuje se rozsah projektu, pokud se tak nestalo ve fázi zahájení. V fázi návrhu řešení navíc dochází k detailní analýze procesů, dochází k definici nadstandardních úprav, stanovují se akceptační kritéria projektu. Výstupem této fáze je odsouhlasení popisu řešení nebo výkresové dokumentace a postupu projektových prací. 3.2.3 Výstavba a realizace řešení V této fázi dochází k vlastní realizační části projektu – podle povahy projektu se staví dům, provádějí se uživatelské úpravy standardního řešení, školí se klíčoví a později koncoví uživatelé informačního systému, atd. Zde také dochází k testování řešení, zkouškám funkcí zařízení nebo systému, u informačních systémů probíhají akceptační testy řešení a jeho budoucích uživatelů. Výstupem této fáze je příprava předmětu projektu k užívání nebo akceptace řešení. 3.2.4 Zahájení provozu V této fázi dochází k zahájení provozu nebo užívání předmětu projektu. Někdy je to forma pilotního provozu, jindy živý běh informačního systému. V této době je předmět projektu pod zvýšeným dohledem řešitelů a odstraňují se méně závažné závady, které nebrání provozu. Výstupem této fáze je protokolární dokončení projektu, kolaudace a/nebo převzetí díla investorem. Příklad rozfázování projektu implementace informačního systému ukazuje následující obrázek:
Obr. 4: Fáze projektu implementace informačního systému
3.3
Struktura projektu
Projekty lze z různých pohledů rozložit na části (základní složky). Typické rozklady projektu jsou z pohledu:
strukturalizace prací (Work Breakdown Structure – WBS), organizace projektu (Organization Brekdown Structure – OBS) nákladů na projekt dokumentační a informační struktury
Strukturování v projektu je klíčový mechanismus, který v rámci projektu zajišťuje řád. Hierarchické struktury zajišťují, aby při realizaci projektu na nic nezapomnělo. Strukturování řešeného problému do menších podprojektů nebo dílčích celků je jedním ze základních stavebních kamenů každého projektu. Tyto celky, které se pak dělí do dalších prvků nebo úkolů, je možné lépe řídit, kontrolovat, a tedy i zvládnout. Mezi jednotlivými celky nebo prvky je nutné definovat i vzájemné vazby tak, aby byla zřejmá závislost, a v případě posunu některého celku nebo prvku v čase bylo hned zřejmé, jak takový posun ovlivní další zavazbené celky nebo prvky. 3.3.1 Hierarchická struktura prací Hierarchická struktura prací (WBS) je nejčastějším přístupem ke strukturalizaci projektu. Je to produktově orientovaný hierarchický rozpad cíle projektu na
jednotlivé produkty, až na úroveň jednotlivých pracovních balíků – úkolů, které musejí být v rámci projektu provedeny. Jedná se o stromovou strukturu, která je předpokladem toho, aby se se nezapomnělo na nic důležitého, a zároveň je určitou pojistkou, že nebudou v rámci projektu prováděny činnosti zbytečně. Pravidlem pro vytvoření hierarchické struktury prací je postup podle filozofie od shora dolů (TOP-DOWN), tedy postup od obecných popisů ke konkrétním činnostem a úkolům. Vždy se snažíme nalézt pokud možno všechny prvky dané úrovně a teprve následně rozpadáme na úroveň další – hierarchicky nižší. Ne všechny prvky je ale nutné rozpadat do všech úrovní. Dle povahy prvku – balíku činností nebo úkolů, dle zkušenosti členů projektového týmu nebo podle povahy organizačních zvyklostí je možné některé rozpady ukončit v určité úrovni, a další dekompozici zastavit. Nejnižší úroveň WBS je prakticky to, co se bude fakticky realizovat. Veškeré nadřazené prvky jsou ze struktury WBS jsou jen souhrnem k prvkům prováděným v nižších úrovních struktury. Obvykle, kvůli přehledu bývá WBS zpracovávaná do čtyř úrovní, v případě potřeby další hloubky strukturalizace se využívá podprojektů. Příklad stromové struktury projektu je následujícím obrázku.
PROJEKT
Souhrn 1
Souhrn 2
Souhrn 1.1
Výstup 1.1
Souhrn 2.1
Výstup 1.1.1
Výstup 1.1.2
Souhrn 1.1.1
Výstup 1.1.1.1
Výstup 1.1.1.2
Výstup 1.1.1.3
Výstup 2.1.1
Souhrn 3
Výstup 3.1
Výstup 3.2
Výstup 2.1.2
Souhrn 3.1
Souhrn 3.1.1
Výstup 3.1.1.1
Obr. 5: Hierarchická struktura prací (WBS)
Výstup 3.1.1
Výstup 3.1.1.2
WBS je používána zejména v úvodní fázi projektu jako specifikace všech možných činností a organizačních či řídících aktů. V dalších fázích projektu se struktura projektu promítá do času. Tím vzniká další možné formy pro řízení projektu, jako je například harmonogram projektu, mapa projektu (Road Map), o kterých bude ještě zmínka v další části textu. Matice odpovědnosti
3.4
Matice odpovědnosti (někdy také RACI matice = Responsible, Accountable, Cooperate, Informed) jasně vymezuje kompetence jednotlivých osob (funkčních míst projektu) k projektovým aktivitám – prvkům WBS. Vztah osob projektu k aktivitám může být následující:
Odpovídá – jediná odpovědná osoba Vykonává – může být více osob Spolupracuje – může být více osob Je informována – zainteresované osoby, které aktivitu nevykonávají ani na ní nespolupracují, ale aktivita se jejich práce dotýká nebo s ní jinak souvisí
Obecně platí, že za jednu konkrétní aktivitu je odpovědná právě jedna osoba. Spolupracujících osob nebo poradců může pak být více. Příklad matice odpovědnosti:
Obr. 6: Příklad RACI matice
3.5
Harmonogram projektu
Harmonogram projektu, je hierarchická struktura prací promítnutá do časové osy. Je nejsledovanější, a dost často nejvíce diskutovaný a změnovaný dokument v průběhu realizace projektu. Harmonogram se nejčastěji sestavuje v podobě
Ganttova grafu nebo ve tvaru síťového diagramu. V obou případech se využívá metody kritické cesty (CPM – Critical Path Method) k eliminaci časových rizik. Příklad harmonogramu projektu je na následujícím obrázku:
Obr. 7: Příklad rámcového harmonogramu projektu
3.6
Plán řízení rizik projektu
Rizika projektů dělíme podle jejich podstaty. Existují rizika vnitřní a vnější, tedy rizika, která vyplývají ze samotné realizace projektu a naopak z okolních podmínek ve kterých je projekt realizován. Omezující podmínky, které vyplývají z obchodní stránky projektu – dosažení kompromisu mezi investorem a obchodním představitelem dodavatele, často vytváří pro realizační tým značná rizika ještě před zahájením projektu. Rizika projektů v praxi dělíme podle toho, zda jim můžeme předcházet a alespoň částečně je eliminovat nebo je svým působením ovlivňovat, a na taková, která předvídat nebo ovlivňovat nelze. Ta rizika, která lze ovlivnit jsou rizika technická, bezpečnostní, finanční, lidský faktor, apod. Rizika, která ovlivnit nelze jsou rizika působení „vyšší moci“, především přírodní živly. Při plánování projektů zpracovává vedení projektu matici rizik, kde jsou známá rizika vyjmenovaná. U každého rizika je uvedeno:
jak se projevuje, jeho předpokládaný dopad, pokud lze, tak i finanční vyjádření rizika, procentní vyjádření pravděpodobnosti vzniku a od toho se odvíjí četnost kontroly na existenci rizika váha rizika a jeho dopad
Klíčovou informací v matici řízení rizik je pak návrh na opatření k eliminaci rizika, který vychází ze zkušeností z dříve realizovaných projektů. Příklad matice rizik je na následujícím obrázku. Id Název
Popis
Předpokládaný dopad
5 Neúčast klíčových lidí na projektu ze strany zákazníka
Klíčoví pracovníci se znalostmi jsou pověřeni jinými prioritními úkoly, například v rámci nové velké a významné zakázky.
Nedostatek kvalitních kapacit způsobí prodlužování termínů a ohrožení kvality a rozpočtu projektu.
75
Implementace IFS nesmí ohrozit realizaci zakázek zákazníka. V případě potřeby bude využíváno práce přesčas v rámci Zákoníku práce. Projekt implementace IFS je definován jako priorita číslo jedna mezi jinými podobnými projekty zákazníka.
7
V
10 Změna zaběhlých činností
Uživatelé nejsou ochotni připustit změnu zaběhlých činností vyvolanou nasazením nového ERP systému IFS.
Změny v procesech nejsou provedeny v dostatečném rozsahu. Nejsou tak využívány všechny možnosti systému.
50
7
V
15 Neporozumění Střední článek řízení nerozumí principům principům IFS, IFS a zaměňuje funkce IFS za kalkulační přecenění nebo poznámkový nástroj, … možnoistí ERP systému
Na systém jsou kladeny požadavky jiné, než pro které je určen, možnosti systému IFS jsou přeceněny a může dojít ke zklamání po jeho nasazení.
50
Od začátku budou v projektovém řízení uplatňovány zásady "Change managementu". Klíčoví uživatelé se budou podílet na přípravě a realizaci navrhovaných změn. Vedení společnosti podpoří navrhované změny organizace práce a kompetencí jednotlivých pracovníků. Změny jsou řešeny v rámci jednotlivých etap implementace. V průběhu realizace bude provedena řada workshopů s řídícími pracovníky s cílem detailně objasnit možnosti a přínosy IFS pro jejich každodenní práci.
14
V
20 Změna kompetencí pracovníků v organizaci procesů
Příslušní vedoucí pracovníci a jejich podřízení se nebudou chtít vzdát svých dosavadních kompetencí a/nebo přijmout nové.
25
7
V
Nasazení IFS vyvolá potřebu změny kompetencí a přerozdělení pravomocí mezi útvary.
Finanční Pravděp Návrh opatření na minimalizaci rizika vyjádření odobnost výskytu %
Změny kompetencí budou předem projednány s příslušnými vedoucími pracovníky a bude zajištěno jejich schválení všemi nutnými řídícími stupni. Vedení zákazníka potvrdí svůj zájem na provedení těchto změn a bude sledovat a podporovat tyto změny i v průběhu projektu. Nově definované změny náplně a přerozdělení práce budou promítnuty do popisu pracovních míst.
Termín Váha aktualizace (dní)
Důsledek
Obr. 8: Příklad matice rizik
3.7
Řízení změn v projektu
Veškeré změny v projektu by měly procházet změnovým řízením od návrhu změny přes její projednání ve skupině kompetentních účastníků změnového řízení, až po zápis o výsledku projednání. Zejména změny na vrcholech trojúhelníku projektového trjimperativu, a dále každá změna klíčových atributů projektu by měla projít odsouhlasením pří jednání řídícího výboru projektu. Součástí organizační struktury projektu by měla být písemně stanovená pravomoc a odpovědnost za provádění změnového řízení na různých úrovních organizace projektu. Zmínka o tomto byla i kapitole 2.3 Komunikační matice v popisu eskalačních skupin. 4
Vyhodnocení projektu
Controlling projektu - sledování postupu projektu podle různých ukazatelů: V průběhu projektu je důležité sledovat měřitelné ukazatele, zda je průběh projetu udržován v hodnotách potřebných pro jeho úspěšné dokončení.
Konečné vyhodnocení projektu probíhá podle kritérií, která byla definována na začátku projektu. Jedná se o měřitelná kritéria dosažení cílů (stojí dům je otevřena silnice, funguje systém sledování spotřeby a regulace medií, atd.), nákladů (nezdražily úvěry, nezadlužili jsme se více, než jsme předpokládali, atd.) a kvality výstupů (dům nepraská v základech, silnice se nevlní nebo netrhá, atd.. Kritériem hodnocení bývá dosažení parametrů, tzn. průběžný nebo konečný výpočet indexů finančních, časových a kvalitativních. Různá kritéria výpočtu stavu a průběhu projektu a hodnotící ukazatele jsou v příloze – v kapitole 6. Obecně, i bez výpočtu ukazatelů, lze považovat projekt za úspěšný, pokud:
Je projekt funkční Jsou splněny požadavky zákazníka Jsou uspokojena očekávání všech zainteresovaných stran Je výstupní produkt na trhu včas Je výstupní produkt v plánované jakosti a ceně Je dosahována předpokládaná návratnost vložených prostředků Je vliv na životní prostředí a okolí v obecné normě
Neúspěšný projekt se naopak vyznačuje tím že: 5
Byly významně překročeny plánované termíny a náklady Nebyla dosažena kvalita výstupního produktu Je naštvaný zákazník a další zainteresované strany Produkt má negativní vliv na životní prostředí Produkt projektu nenašel své místo na trhu Příloha – hodnotící projektové ukazatele
Pro hodnocení výkonnosti projektu, včetně trendů možného vývoje, se v projektech používají projektové ukazatele. Zde jsou uvedeny ve výčtu s některými příklady, hlubší popis a využití je mohou zájemci o tuto oblast dohledat v použité literatuře. BCWS - Rozpočtové náklady na naplánovanou práci Rozpočtové náklady na naplánovanou práci, vypočtené jako BAC × (Uplynulé dny/Doba trvání). Částka rozpočtu, která by měla být dokončena do daného dne, někdy vyjádřená jako procento rozpočtu. Např.: Pokud máme rozpočet na 500 $ a předpokládáme, že se na činnosti bude pracovat průběžně po dobu 5 dní, byly by BCWS po 2 dnech rovny 500 $ × (2 dny / 5 dní) = 200 $. BCWP Spotřebovaná hodnota Rozpočtové náklady na vykonanou práci, vypočtené jako Rozpočet při dokončení násobený odhadovaným průběhem, BAC × Průběh. Částka rozpočtu, která je
skutečně dokončena k danému datu. BCWP se liší od BCWS a ACWP. BCWS mohou být 200 $ a ACWP 150 $. Z toho plyne, že jsme utratili méně, než bylo k danému dni rozpočtováno. Otázkou však zůstává, jaká část činnosti již byla dokončena? Potřebujeme znát odpověď na tuto otázku, jinak nemáme žádný náznak toho, zda budou konečné náklady nad nebo pod rozpočtem a programem. Pro měření spotřebované hodnoty musí být použita objektivní kritéria; v opačném případě bude celá výkonnostní analýza a předpovědi pasivem. ACWP Skutečné náklady na vykonanou práci Skutečné náklady na vykonanou práci; rovnají se skutečným nákladům, které jsou vykázány pracovními objednávkami a jinými objekty. Jde o náklady zaznamenané k danému dni, někdy vyjádřené jako procento rozpočtu. Tyto náklady jsou zaznamenány např. pomocí časových tabulek. ACWP nejsou mírou toho, jak velká část činnosti byla již dokončena, ale jedná se o prostý záznam toho, kolik již bylo do daného data utraceno. Příklad: Ve srovnání s výše uvedenými BCWS ve výši 200 $ mohly být po dvou dnech zaznamenány náklady ve výši 150 $. Je důležité, aby zaznamenané náklady byly aktuální, v opačném případě jsou výsledky výpočtů výkonnostní analýzy nespolehlivé. BAC Rozpočet při dokončení Rozpočet při dokončení, který se rovná plánované hodnotě. Celková částka sloupce je zobrazena na poslední řádce. Rozpočet pro činnost může být 500 $ s plánovanou dobou trvání 5 dní. SPI Index plnění harmonogramu Index plnění harmonogramu, vypočtený jako BCWP/BCWS. Tento index udává, zda je průběh před nebo po termínu. Hodnota v tomto poli je vypočtená a nelze ji modifikovat. Pokud je hodnota rovna jedné (1), je plnění průběhu do daného dne v souladu s programem, tj. peníze jsou spotřebovány podle daného programu. Hodnota větší než 1 udává, že je průběh rychlejší než program, tj. peníze jsou spotřebovány rychleji než je v programu. Hodnota menší než 1 udává, že je průběh pomalejší než program, tj. peníze jsou spotřebovány pomaleji než v programu. SPI lze použít pro dobu trvání činnosti, např. činnost je XX dní před/za plánem. CPI Index plnění nákladů Index plnění nákladů, vypočtený jako podíl spotřebované hodnoty a skutečných nákladů na vykonanou práci, BCWP/ACWP. Tento index je koeficientem plnění plánu k danému datu a určuje, zda je průběh před/po termínu. Hodnota v tomto poli je vypočtená a nelze ji modifikovat. Pokud je hodnota rovna jedné (1), znamená to, že je index plnění nákladů do daného dne v souladu s rozpočtem. Jeden dolar je získáván za každý utracený dolar. Hodnota větší než 1 znamená, že
skutečnost je lepší než rozpočet, tj. za každý utracený dolar je získán více než jeden dolar. Hodnota menší než 1 znamená, že skutečnost je horší než rozpočet. Za každý utracený dolar je získáno méně než jeden dolar. Prostudováním indexu plnění nákladů je jednodušší zjistit významné odchylky než prostudováním odchylky nákladů (CV). IEAC Nezávislý odhad při dokončení Nezávislý odhad při dokončení, vypočtený jako Skutečné náklady na vykonanou práci plus Odhad pro dokončení, ACWP + ETC. Tento odhad představuje konečné náklady, jestliže procento utrácení zůstává na stejné úrovni. IEAC je odhadem revidovaných nákladů při dokončení. Základem pro odhad je předpoklad pokračování práce při stávající míře Spotřebované hodnoty a stávající míře skutečných nákladů. ETC Odhad pro dokončení Odhad pro dokončení, vypočtený jako původní Rozpočet při dokončení mínus Spotřebovaná hodnota, tento rozdíl je vydělen náklady, (BAC – BCWP) / CPI. ETC je odhad nákladů požadovaných pro dokončení. Základem pro odhad je předpoklad pokračování práce při stávající míře Spotřebované hodnoty. CV Odchylka nákladů Odchylka nákladů, vypočtená jako Spotřebovaná hodnota mínus Skutečné náklady na vykonanou práci, BCWP – ACWP. CV udává, zda jsou náklady k danému dni lepší nebo horší než rozpočtované náklady. Příklad: Nulová hodnota (0) udává, že jsou náklady k danému dni v souladu s rozpočtem. Kladná hodnota ukazuje, že náklady jsou k danému dni lepší než rozpočtované. Záporná hodnota ukazuje, že náklady jsou k danému dni horší než rozpočtované. SV Odchylka harmonogramu Odchylka harmonogramu, vypočtená jako Spotřebovaná hodnota mínus Rozpočtované náklady na naplánovanou práci, BCWP – BCWS. SV udává, zda jsou výnosy k danému dni nad nebo pod rozpočtem. Přitom je uvedeno, zda je průběh k danému dni před/za plánem. Příklad: Nulová hodnota (0) udává, že je průběh k danému dni v souladu s programem. Kladná hodnota ukazuje, že je průběh k danému dni lepší než plán. Záporná hodnota ukazuje, že je průběh k danému dni horší než plán. Odchylka harmonogramu se normálně vyjadřuje ve finančních výrazech, např. činnost je rovna xxx.xxx $ pod/nad plán.
VAC Odchylka při dokončení Odchylka při dokončení, vypočtena jako Nezávislý odhad při dokončení mínus původní Rozpočet při dokončení, IEAC – BAC. Celková částka tohoto sloupce je zobrazena na poslední řádce. VAC je odhadem nákladů, které ovlivní rozpočet v případě, kdy nebude změněna stávající míra spotřebované hodnoty a stávající míra skutečných nákladů. Kladná hodnota udává, že bude utraceno více, než bylo rozpočtováno. Záporná hodnota udává, že bude utraceno méně, než bylo rozpočtováno. Největší problémy ve výsledcích plnění pod/nad plán vznikají v případech, kdy problémové podprojekty a činnosti zůstávají neprozkoumané. Předpovězená doba trvání/dny Odhad doby trvání ve dnech vypočtený následujícím způsobem: Doba trvání dělená Indexem plnění harmonogramu (SPI). Odhad časového dopadu na projekt, jestliže práce pokračuje při stávající míře spotřebované hodnoty. Příklad: Původní doba trvání je 10 dní. SPI je 0,7 (činnost/podprojekt získává pouze 0,70 $ za každý rozpočtovaný 1,00 dolar). Doba trvání ve dnech je 10 dní / 0,7 = 14 dní. Jinými slovy, pokud zůstane tento potenciální problém neprozkoumán, pak podle ukazatelů bude činnost/podprojekt trvat o 40 % déle, než je rozpočtováno, což může mít vážný dopad na program projektu. Předpověď dnů před/po termínu Odhad počtu dnů před/po termínu, vypočítává se jako Doba trvání mínus Předpovězená doba trvání/dny. Předpovězené nejdříve možné ukončení Odhad data nejdříve možného ukončení, vypočítává se jako Nejdříve možné zahájení + Předpovězená doba trvání/dny – 1. Předpovězená zbývající doba trvání/dny Odhad zbývajících dní, vypočítává se jako Předpovězené nejdříve možné ukončení – Běžné datum (systémové datum) + 1. Zbývající doba trvání/dny Tato doba je definována jako počet dní od běžného data do data nejdříve možného ukončení Pokud je běžné datum větší než Nejdříve možné ukončení, má Zbývající doba trvání/dny hodnotu nula (0). Pokud je běžné datum menší než Nejdříve možné zahájení, má Zbývající doba trvání/dny hodnotu, která je rovna celkové době trvání ve dnech.
Příklad: Použijme výše uvedený případ a předpokládejme, že činnost byla zahájena před 5 dny; potom by byla Zbývající doba trvání ve dnech (RD) vypočtena takto: 14 – 5 = 9 dní. Zbývající pracovní dny Tato hodnota je definována jako počet pracovních dní od běžného data do data nejdříve možného ukončení. Pokud je běžné datum větší než Nejdříve možné ukončení, je zbývající pracovní dny hodnotu nula (0). Pokud je běžné datum menší než Nejdříve možné zahájení, potom je Zbývající pracovní dny rovno hodnotě, která je rovna hodnotě Pracovní dny celkem.
Literatura [1]
Doležal. Machal, Lacko a kol. Projektový management podle IPMA, Grada Publishing, a.s., 2009
[2]
IFS AIM (Aplication Implementation Metodology)
[3]
Dokumentace implementačních projektů ALTEC a.s. a IFS Czech s.r.o.
