Využití metodiky PRINCE2 pro řízení projektů v podniku v Č.R

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

Využití metodiky PRINCE2 pro řízení projektů v podniku v Č.R. Diplomová práce

Autor:

Bc. Michal Půda

Vedoucí práce:

Ing. Václav Šebek, CSc.

Praha

Červen, 2009

Prohlášení:

Prohlašuji, že jsem diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze dne 25. června 2009

Michal Půda

Poděkování:

Rád bych poděkoval panu inženýru Václavu Šebkovi za odborné vedení a cenné rady při přípravě mé diplomové práce.

Anotace V této práci se zabývám britskou metodikou pro vedení projektů PRINCE2 s ohledem na její praktické využití v podniku v České republice. Popisuji základní filosofii metody a vlastnosti, které by při její implementaci v organizaci v Č.R. byly významným přínosem pro efektivní řízení projektů. Analyzuji možnosti jejího škálování pro malé projekty a zaměřuji se především na zadávací fázi projektu a klíčová projektová rozhodnutí. Na praktických ukázkách demonstruji možnosti zdokonalení zadávací etapy, zejména zavedením iterativního a interaktivního způsobu definice úvodního projektového zadání. Předkládám také příslušné modifikované projektové dokumenty. V oblasti projektových rozhodnutí se zabývám možností rozšíření klíčových projektových rozhodnutí, například do fáze schvalování uživatelských testů a ověření přínosu projektu.

Annotation In my thesis I deal with PRINCE2, a British method for managing projects with respect to its applicability to a company in the Czech Republic. I describe the essentials of the method and its qualities. When implemented in the organizations in the C.R., those would benefit from efficient project management. I analyse its scaling down to small projects. I especially focus on the specification phase of the project and the project’s key decission points. Using practical examples I demonstrate a potential of improvement of the specification phase. Especially introducing an iterative and interactive manner of development of specification. I also propose modified project documents. In the area of project decission points I deal with potential enhancements of the key decission points, for instance towards the user acceptance testing and the project benefit review.

Obsah OBSAH .................................................................................................................................................................... 5 1

2

ZÁKLADNÍ PRINCIPY ŘÍZENÍ PROJEKTŮ......................................................................................... 8 1.1

PROJEKT ................................................................................................................................................. 8

1.2

ŘÍZENÍ (VEDENÍ) PROJEKTU .................................................................................................................... 9

1.2.1

Rozdílné přístupy k projektovému managementu ........................................................................... 10

1.2.2

Techniky projektového managementu............................................................................................. 12

1.2.3

Zhodnocení vhodnosti přístupu....................................................................................................... 13

METODIKA VEDENÍ PROJEKTŮ......................................................................................................... 14 2.1 2.1.1

Identifikace projektu ....................................................................................................................... 15

2.1.2

Zahájení projektu............................................................................................................................ 15

2.1.3

Vykonání projektu........................................................................................................................... 15

2.1.4

Ukončení projektu........................................................................................................................... 15

2.2

Absence metodiky u malého podniku .............................................................................................. 16

2.2.2

Poučení se z chyb............................................................................................................................ 16 METODIKY ........................................................................................................................................... 17

2.3.1

PMBOK .......................................................................................................................................... 17

2.3.2

PRINCE2 ........................................................................................................................................ 20

2.3.3

Další metodiky ................................................................................................................................ 20

PRINCE2 – ZÁKLADNÍ MYŠLENKY.................................................................................................... 21 3.1

HISTORIE .............................................................................................................................................. 21

3.2

FILOSOFIE METODY .............................................................................................................................. 22

3.3

DŮRAZ NA OBCHODNÍ ZDŮVODNĚNÍ..................................................................................................... 23

3.4

ZKRÁCENÝ POPIS PROCESŮ A KOMPONENT PRINCE2.......................................................................... 24

3.4.1

Organizace projektu ....................................................................................................................... 24

3.4.2

Základní procesy metody ................................................................................................................ 26

3.5

4

VEDENÍ PROJEKTU BEZ POUŽITÍ METODIKY ......................................................................................... 15

2.2.1 2.3

3

FÁZE KONZERVATIVNĚ VEDENÉHO PROJEKTU ...................................................................................... 15

REVIZE PRINCE2 Z ROKU 2009........................................................................................................... 28

3.5.1

Motivace k revizi............................................................................................................................. 28

3.5.2

Popis revize 2009............................................................................................................................ 29

PRINCE2 PRO MALÉ PROJEKTY ........................................................................................................ 30 4.1

DEFINICE MALÉHO A VELMI MALÉHO PROJEKTU .................................................................................. 30

5

5

4.2

VHODNOST POUŽITÍ METODIKY PRO MALÝ PROJEKT ............................................................................ 31

4.3

MALÝ PROJEKT .................................................................................................................................... 32

4.3.1

Organizace ..................................................................................................................................... 32

4.3.2

Konfigurační management.............................................................................................................. 34

4.3.3

Řízení změn..................................................................................................................................... 34

4.3.4

Obchodní zdůvodnění ..................................................................................................................... 34

4.3.5

Plánování........................................................................................................................................ 34

4.3.6

Kontrola.......................................................................................................................................... 35

4.3.7

Rizika .............................................................................................................................................. 35

4.3.8

Kvalita ............................................................................................................................................ 35

4.4

VELMI MALÝ PROJEKT.......................................................................................................................... 35

4.5

SHRNUTÍ POZNATKŮ............................................................................................................................. 37

VYUŽÍVÁNÍ PRINCE2 V ČESKÉ REPUBLICE................................................................................... 39 5.1 5.1.1 5.2

6

PRAKTICKÉ POUŽÍVÁNÍ PRINCE2 V ČESKÉ REPUBLICE A V REGIONU ................................................. 39 Subjekty které PRINCE2 používají nebo plánují používat.............................................................. 40 ZÁVĚR K POUŽÍVÁNÍ PRINCE2 V ČESKÉ REPUBLICE A V REGIONU ..................................................... 41

PŘÍKLAD VYUŽITÍ PRINCE2 PRO ŘÍZENÍ KONKRÉTNÍHO PROJEKTU................................. 42 6.1

ZADÁVACÍ FÁZE PROJEKTU .................................................................................................................. 42

6.1.1

Srovnání aplikace zadávacího procesu........................................................................................... 42

6.1.2

Podnik A ......................................................................................................................................... 45

6.1.3

Podnik B ......................................................................................................................................... 74

6.1.4

Závěr k modifikaci zadávacího procesu PRINCE2......................................................................... 78

6.2

DŮLEŽITÁ PROJEKTOVÁ ROZHODNUTÍ.................................................................................................. 79

6.2.1

Projektová rozhodnutí podle PRINCE2.......................................................................................... 79

6.2.2

Modifikace a zhodnocení projektových rozhodnutí ........................................................................ 80

ZÁVĚRY A DOPORUČENÍ ............................................................................................................................... 88 SEZNAM POUŽITÉ LITERATURY ................................................................................................................ 90 SEZNAM OBRÁZKŮ A TABULEK ................................................................................................................. 92 OBRÁZKY ........................................................................................................................................................... 92 TABULKY ........................................................................................................................................................... 92

6

Úvod Desítky let v centrálně plánovaném hospodářství zanechaly na českých podnicích a v řadách českých manažerů velmi citelné šrámy. Zatímco v západních ekonomikách se v oblasti řízení podniků a vývoje produktů důsledně zaměřovali na kvalitu, efektivitu při nakládání s finančními prostředky a na nejvyšší možné zhodnocení investic, u nás šel vývoj zcela jiným směrem. Bez ohledu na skutečné potřeby trhu byla produkce průmyslu úplně podřízena státnímu rozpočtu ve snaze jej udržet za každou cenu vyrovnaný. Téměř neexistovala motivace pro to být úspěšnější než konkurence, nabídnout lepší služby za lepších podmínek. V takovém prostředí nebyl velký prostor pro uplatňování moderních metod řízení s využitím posledních vědeckých postupů. Není proto divu, že po roce 1989 celá řada českých společností po ztrátě východních trhů nebyla schopna konkurovat produktivnějším západním podnikům s vyspělejšími výrobky a začala mít vážné ekonomické problémy. V dnešní době již tomu tak není. I ryze české firmy se prosazují na světových trzích a ti nejúspěšnější z nich si dobře uvědomují, jakou výhodu před rivaly poskytuje fungující a efektivní řízení podniku i jednotlivých úkolů. Každý podnik při své činnosti běžně realizuje projekty, ať již se jedná o nákup zařízení, služeb či především o prodej zákaznických řešení. Jelikož o profitabilitě firmy mnohdy rozhoduje právě úspěšné vedení a ukončení těchto projektů, je pro řadu společností použití projektových metodik klíčové. Může i přímo rozhodovat o jejich hospodářském výsledku. Protože se domnívám, že je role metodik pro řízení projektů v České republice nedoceněná, rozhodl jsem se zaměřit právě na toto téma. Cílem

mé

diplomové

práce

bude

zmapovat

využívání

metodiky

PRINCE2

ve

vybraných podnicích v České republice. Ověřit její vhodnost zejména pro použití v zadávací fázi projektu a na klíčových projektových rozhodnutích.

7

1 Základní principy řízení projektů Řízením projektu rozumíme proces plánování, koordinování a řízení úloh a zdrojů pro dosažení definovaného projektového cíle1. Jedná se o komplexní a komplikovanou vědeckou disciplínu.

1.1 Projekt Slovo „projekt“ bylo do českého jazyka přeneseno z angličtiny, ze slova project. Podle slovníku2 pochází pojem projekt (project) z latinského projectum „něco vrženo dopředu“. Jde o podstatné jméno od slovesa projectus „vrhnout, postrčit dopředu“, které vzniklo složeninou předložky pro- „dopředu“ a slovesa jacere popřípadě jactus „vrhnout“. Význam bližší dnešnímu chápání „schéma, návrh, duševní (nehmotný) plán“ pochází z roku 1601. Kolem roku 1932 zazněl poprvé pojem housing project, veřejný projekt výstavby levných bytových domů, od tohoto okamžiku je termín „projekt“ (project) běžně používán. Definic pojmu „projekt“ jak mu rozumíme dnes, existuje celá řada. Projekt je časově ohraničené úsilí za účelem vytvoření unikátního produktu nebo služby3. Projekt popisujeme také tak zvaným projektovým trojimperativem: vytvoření definovaného výstupu za určitý časový úsek a za použití definovaných (omezených) zdrojů. U projektu musí být možné rozpoznat, že došlo k naplnění požadavků projektu, tedy k dodání předmětu projektu a že toto zadání splňuje požadované parametry. Projektem může být uspořádaní lékařské konference, stavba výškové budovy, napsání knihy o Španělsku či implementace nového bankovního systému. Ve všech těchto případech můžeme říci, že dokážeme popsat projektové zadání, pravděpodobně máme vyhrazené určité prostředky a další zdroje k jeho realizaci a definované množství času. Projekt může být součástí programu a může pomáhat naplňovat jeho vizi.

1

„Project Management“, Wikipedia, dostupné online na http://www.wikipedia.org Online Etymology Dictionary, dostupný online na http://www.etymonline.com. 3 Wikipedia, distupné online na http://www.wikipedia.org 2

8

1.2 Řízení (vedení) projektu Projektový management byl v určité formě praktikován již od počátků civilizace. Do konce 19. století byly však projekty zpravidla řízeny samotnými architekty nebo inženýry, kteří měli určitý úkol či stavbu na starost. Teprve od 50. let dvacátého století začínají společnosti aplikovat systematický, vědecký přístup k projektovému managementu. Jako samostatná disciplína se projektový management vyvinul z různých oborů, jako jsou průmyslová výstavba, návrh průmyslových zařízení či oblast obrany. Ve Spojených státech na počátku 20. století prezentoval svou teorii vědeckého managementu Frederick Winslow Taylor4, vědecký pracovník a manažerský konzultant z Pennsylvanie. Ještě slavnějšími se však stali jeho dva kolegové, Henry Gantt5 a Francouz Henri Fayol6. První z nich je považován za otce základních technik v oblasti manažerského plánování a řízení, jeho Ganttův diagram (Gantt Chart)7 je široce přijímaný a standardní způsob plánování projektu. Henri Fayol, autor desítek článků a knih, položil základy modernímu projektovému řízení. Sepsal své zkušenosti do Obecné teorie řízení podniku8 po svém třicetiletém působení ve vedení velké francouzské důlní společnosti. V padesátých letech zaznamenáváme významný pokrok v oblasti manažerského řízení. Objevuje se Metoda kritické cesty (Critical Path Mehod)9, kterou vytvořily společnosti DuPont10 a Remington Rand11. Vzniká Technika pro zhodnocení a ověření programu PERT (Program Evaluation and Review Technique)12. Tu prezentuje americké námořnictvo ve spolupráci s firmou Lockheed. Jak Metoda kritické cesty tak PERT se staly základem či součástí dalších metodik. Společným jmenovatelem pokrokových technik je jejich navázanost na vládní a zvlášť obranné struktury Spojených států. Právě tamní rozsáhlé a nákladné projekty pomohly uvést moderní metody řízení v život. V roce 1969 vzniká Institut pro projektový management (Project Management Institut, PMI) pro podporu zájmů oboru průmyslového managementu. Právě PMI vydal později příručku 4

Frederick Winslow Taylor: USA, 1856-1915. Henry Gantt: USA, 1861-1919. 6 Henri Fayol: Francie, 1841-1925. 7 Gantův diagram: Grafické vyjádření projektového plánu včetně závislostí mezi úkoly. 8 Obecná teorie řízení podniku: v originále „Administration industrielle et générale“, vyšlo 1916 v bulletinu Bulletin de la Société de l’Industrie Minérale. 9 Kritická cesta: matematický algoritmus pro plánování projektových úkolů. 10 DuPont: Americká chemická společnost, založena 1802. 11 Remington Rand: Bývalý americký průmyslový a zbrojní producent, 1927-1955. 12 PERT: Široce přijímaný model pro reprezentaci projektových úkolů. 5

9

PMBOK13. Evropská verze PMI nazvaná IPMA (International Project Management Association) vznikla v roce 1967. Její vývoj byl podobný jako PMI, ovšem v dnešní době se spíše zaměřuje na certifikaci odborníků v oblasti projektového managementu. V současné době obě organizace spolupracují na přípravě ISO14 standardu pro oblast projektového managementu. Souběžně probíhaly vývojové práce i v oblasti odhadování a řízení projektových nákladů a průmyslové ekonomiky. Z nejvýznamnějších subjektů v této oblasti jmenujme Americkou asociaci pro návrh nákladů AACE (American Association of Cost Engineers), dnes nazývanou AACE International (Association for Advancement of Cost Engineering International). Právě od této asociace pochází vůbec první integrovaný proces pro řízení a správu portfolia, programu a projektů publikovaný jako Rámec pro řízení úplných nákladů (Total Cost Management Framework). Nástroj z roku 2006 řeší za jakých podmínek a proč by mělo docházet k rozhodnutí o potřebě projektu v situaci, kdy jistě existuje celá řada dalších operačních, údržbových a investičních oblastí, do kterých by také bylo třeba vložit prostředky.

1.2.1 Rozdílné přístupy k projektovému managementu U Projektového managementu rozeznáváme několik odlišných přístupů, které se kromě způsobu jejich aplikace liší především vhodností jejich použití na konkrétní oblast, problém či typ projektu. Rozeznáváme především Konzervativní a Agilní přístup. 1.2.1.1 Konzervativní přístup U klasického konzervativního přístupu, nazýváme jej také “vodopádový” (Waterfall)15, probíhá životní cyklus projektu jako řada předem definovaných, na sebe navazujících kroků, například: 1. Zahájení → 2. Naplánování → 3. Provedení → 4. Kontrola → 5. Ukončení Po dokončení prvního kroku následuje krok druhý, poté krok třetí a tak dále. Na první pohled se jedná o nejpřirozenější způsob řízení úkolu. Takto byly jistě řízeny i výstavby dávných viaduktů, pyramid či hradů. 13

PMBOK: Project Management Body of Knowledge. Bude podrobněji popsáno dále. ISO: International Organization for Standardization - Mezinárodní organizace pro standardizaci. 15 Waterfall: model vodopádu – jednotlivé fáze projektu na sebe sériově navazují. 14

10

Nejpalčivějším problémem je, že skutečný svět není dokonalý, lidé nejsou neomylní. Ani při nejvyšší úrovni zkušenosti a znalosti problematiky nelze odhadnout a naplánovat celý běh projektu, odhalit všechny myslitelné problémy, které mohou nastat a připravit se na ně. Naopak je prakticky jisté, že k neočekávaným problémům dojde a bude potřeba je za cenu co nejmenších nákladů vyřešit. Bude-li se jednat o zásadní změnu koncepce, jež byla odhalena pozdě, bude nutné se vrátit ke druhému kroku a poté znovu pokračovat kroky tři, čtyři a tak dále. Projekt se tímto pochopitelně prodraží a prodlouží. I přes své nevýhody je tento přístup zdaleka nejpoužívanější, existuje pro něj největší množství nástrojů a byl vyzkoušen na nejvyšším počtu úkolů ze všech myslitelných oborů. 1.2.1.2 Agilní přístup Původně byl tento přístup typický pro vývoj počítačového software. Za ústřední dokument přístupu je považován Manifest pro agilní softwarový vývoj (Manifesto for Agile Software Development) vydaný sedmnácti jeho autory roku 2001. Klíčem k agilnímu přístupu je iterativní16 vývoj požadavků i výsledku a postupné dodávání výsledného produktu. Například od modelu, přes prototyp až po hotový a ověřený produkt. Důraz klade na vývojový tým, často mající téměř horizontální organizační strukturu. Zaměřuje se na kvality a motivaci jednotlivých individualit, ale individualit schopných pracovat v týmu. Motivuje k rychlé a efektivní adaptaci na změny (prostředí, zadání), nevyžaduje explicitní dokumentaci (dokumentován bývá programový kód případně model) a vybízí k úzké spolupráci se Zadavatelem17. Postupně došlo k rozšíření agilního přístupu a jeho filosofie a technik i do projektového managementu. Roku 2005 byla vydána tzv. Deklarace závislostí projektového managementu (PM Declaration of Interdependence), která vychází z agilního softwarového vývoje a promítá jeho atributy do projektového managementu.

16 17

Iterace: opakovaná, cyklická akce. Zadavatel: zákazník, budoucí uživatel a plátce nákladů na projekt. 11

1.2.2 Techniky projektového managementu Pro řešení dílčích úloh projektového managementu, jako je plánování, řízení rizik či nakládání se zdroji se zpravidla využívají další postupy a techniky, například: •

Řízení pomocí kritického řetězce

•

Kritická cesta

•

Řízení pomocí řetězce událostí

1.2.2.1 Řízení pomocí kritického řetězce Projektový management pomocí kritického řetězce (Critical Chain Project Management) je postaven na filosofii Teorie omezení od Dr. Goldratta18. Teorie omezení vychází z předpokladu, že ve společnosti či v jiném projektovém prostředí vždy existuje několik, nejméně však jedno omezení. Vyžaduje kladení zvýšeného důrazu na řízení prostředku, který tvoří identifikované omezení, aby jeho každé využití bez výjimky směřovalo k naplnění cíle. Základní myšlenkou pro Řízení pomocí kritického řetězce je se tomuto či těmto omezením přizpůsobit v řízení a plánování a dopředu s nimi počítat. 1.2.2.2 Kritická cesta Technika plánování pomocí kritické cesty je široce přijatá v řízení projektů v mnoha oblastech od softwarového inženýrství, přes vědecké projekty až po komplexní investiční projekty. Podstatou je identifikace všech činností nezbytných pro dokončení projektu společně se zjištěním (odhadem) délky jejich trvání a závislostí mezi těmito činnostmi. Poté je vytvořen matematický model běhu projektu s vyjádřeném vlivu mezi klíčovými činnostmi. Výsledkem je grafické vyjádření potenciálních úzkých (kritických) míst v mapě projektu, které pokud selžou či se protáhnou, ohrozí časový plán celého projektu. 1.2.2.3 Řízení pomocí řetězce událostí Tento přístup je vyspělejší variantou metod Řízení pomocí kritického řetězce a Řízení pomocí kritické cesty. Zohledňuje a kvantifikuje rizika spojená s výskytem jedné a poté dalších navazujících negativních událostí, které mohou ovlivnit průběh celého projektu. Vychází z předpokladu, že určitá událost či události na projektu pravděpodobně nastanou a než dojde 18

Eliyahu Moshe Goldratt: *1948, izraelský fyzik. 12

k jejich eliminaci či korekci způsobí problémy i v dalších sousedících oblastech. Analyzujeme-li a zdokumentujeme možné následky jedné události na další, jsme schopni snížit dopady na projekt odpovídajícími opravnými opatřeními.

1.2.3 Zhodnocení vhodnosti přístupu Není dost dobře možné prohlásit o některém z přístupu či technice, že je nejlepší či bezchybná. Vždy musíme říct, na základě jakých kriterií a pro jaký typ projektu je uváděný přístup nejvhodnější. Pro menší, nekomplexní softwarové projekty může být tím nejlepším řešením agilní technika ve formě Scrum19 či Extrémního programování20 (Extreme Programming). U výstavby jaderné elektrárny nebo řídícího počítačového systému pro ni pravděpodobně raději použijeme konzervativní přístup i za cenu zvýšení nákladů a prodloužení běhu projektu. Tato práce je zaměřena na aplikaci metodiky PRINCE2 a budu se tedy zabývat právě touto metodikou ze skupiny tak zvaných Vodopádových metodik.

19

Scrum: agilní technika s krátkými vývojovými cykly nazývanými Sprinty. Extrémní programování: zákaznicky orientovaná agilní technika, umožňuje přizpůsobování měnícím se požadavkům. 20

13

2 Metodika vedení projektů Jako o metodice hovoříme o uceleně zpracovaném postupu k výkonu určité činnosti, v našem případě řízení projektu, které zpravidla vychází z best practices (nejlepších, ověřených přístupů) a zapracovává nejnovější trendy z výzkumu i obchodní praxe. Důsledné a rozumné následování metodiky sice není dostačující podmínkou pro úspěšné vedení projektu, na druhou stranu významně zefektivní jednotlivé kroky a pomůže neopomenout žádnou z klíčových aktivit. Žádná projektová metodika (s výjimkou IPMA) není zaměřena úzce na osobu projektového manažera. Pamatuje i na další zúčastněné strany s tím, že jim říká jaká je jejich role, jaké činnosti a vstupy se od nich očekávají a kdy a na koho se mají v různých situacích obrátit. Bez ohledu na konkrétní metodiku má její existence ve společnosti ještě jeden významný přínos umožní vykonávat role junior projektových manažerů či projektových koordinátorů i méně zkušeným osobám. Zjednodušeně řečeno, projektová metodika společně s praxí pomáhá „vychovávat“ projektového manažera. Zaměřím se nyní se na konzervativní, tzv. Vodopádový (Waterfall) přístup k řízení projektu. U projektu podle takové metodiky rozpoznáváme čtyři základní fáze

•

Identifikace (zadání) projektu

•

Zahájení projektu

•

Vykonání projektu

•

Ukončení projektu

Každá z fází má svou vlastní charakteristiku a přestože navazuje na fázi předcházející a je vstupem pro fázi následující, má zcela odlišné cíle.

14

2.1 Fáze konzervativně vedeného projektu Projekt podle konzervativní filosofie můžeme rozdělit na fáze Identifikace, Zahájení, Vykonání a Ukončení.

2.1.1 Identifikace projektu Předtím, než můžeme zahájit přípravné fáze projektu, je třeba ověřit přínos zamýšleného projektu. Tuto fázi popisujeme otázkou „máme projekt?“.

Pokud neexistuje shoda o

jednoznačných přínosech projektu, vůbec nebudeme projekt zahajovat. V této fázi jsou také popsány požadavky projektu a specifikace výsledného produktu či produktů.

2.1.2 Zahájení projektu V okamžiku zahájení projektu již jsme si jisti přínosem (důvodem) pro náš projekt, máme projekt schválen od všech klíčových vlastníků projektu, máme k němu vyhrazené zdroje a na základě plánu zahajujeme a dále plánujeme provedení projektu.

2.1.3 Vykonání projektu V průběhu této části života projektu probíhají všechny činnosti které mají přímou souvislost s naplnění cílů projektu, jsou vytvářeny produkty které jsou požadovány, je ověřována jejich kvalita, jsou plánovány a schvalovány jednotlivé dílčí fáze.

2.1.4 Ukončení projektu Ukončení projektu definujeme jako předání výsledného produktu či produktů do rukou jejich uživatele nebo uživatelů, finální ověření přínosu projektu a rozpuštění všech projektových týmů společně s formálním schválením zakončení projektu.

2.2 Vedení projektu bez použití metodiky I rozsáhlý projekt v organizaci je možné uřídit bez projektové metodiky. V takovém případě však situace vyžaduje od vedoucího projektu a celého projektového týmu značné zkušenosti, bezchybnou znalost procesů ve firmě, přirozený mandát a autoritu ke změnám a k zadávání úkolů a vynikající schopnost rozhodovat.

15

2.2.1 Absence metodiky u malého podniku Tuto situaci si můžeme představit u malé až středně velké rodinné firmy, ve které všechny důležité posty zastávají rodinní příslušníci. Ti jsou prakticky jedinými vlastníky znalostí o chodu firmy a jejích potřebách. K problému dochází ve chvíli, kdy do projektu vstupuje dodavatel vně firmy, jehož dodávka je klíčová pro úspěch celého projektu. Takový externí dodavatel se již nedokáže přirozeně zapojit do vnitro firemních procesů a komunikačních toků. Potřebuje proto mít vyhrazeného člena vedení společnosti, který pro něj bude rozhraním do prostředí společnosti. To způsobuje nepružnost, především v procesech rozhodování a plánování. Dalším úskalím je vstup jakéhokoli nové osoby na důležitý post ve společnosti. V takovém případě, kdy žádný popis procesu, metodiky a uceleného know-how neexistuje, je zapojení nového pracovníka (vrcholového manažera) nesmírně zdlouhavý proces.

2.2.2 Poučení se z chyb Významným argumentem pro zavedení některé z uznávaných metodik či implementace vlastní s použitím nějakého dostupného rámce je možnost poučit se z chyb, které již někdo udělal před námi. Právě určité problémy, kterým někdo čelil opakovaně v minulosti jej vedly k vytvoření postupu, jak s těmito těžkostmi bojovat a ještě častěji k zavedení nástrojů k jejich předcházení. To je vlastnost, která platí jak pro obecně rozšířené metodiky - tam se učíme z chyb někoho jiného někde jinde v Evropě nebo ve světě. Ale bude to stejně platit i pro vnitřní metodiku vyvinutou přímo ve firmě. V tom případě byly do metodiky zakomponovány poučení od našich vlastních kolegů, kteří pravděpodobně řešili přesně stejné problémy jako řešíme nyní my; jejich projekt probíhal ve zcela totožném prostředí. Některé metody, například PRINCE2, zavádí postup Lessons Learned (Co jsem se naučil) i přímo do praxe projektového řízení. Je součástí vyhodnocení každého projektu a umožňuje se vyvarovat chyb, ke kterým došlo na předchozích projektech ve stejné organizaci či dokonce na našem právě probíhajícím projektu.

16

2.3 Metodiky V této kapitole se budu zabývat metodikami •

PMBOK

•

PRINCE2

•

IPMA Competence Baseline

2.3.1 PMBOK PMBOK je zkratka slovního spojení Project Management Body of Knowledge. Jedná se o velmi rozšířenou metodu (rámec), především u amerických společností a organizací. 2.3.1.1 Úvod a historie21 PMBOK poprvé vyšel v roce 1987 ve formě strukturovaného dokumentu (white paper) ve snaze zachytit běžně používané techniky, znalosti a informace v oblasti projektového managementu. První formální vydání se datuje do roku 1996, druhé do roku 2000, poté následovalo třetí v roce 2004 a poslední čtvrté v roce 2008. Podobně jako PRINCE2 i PMBOK má dlouhou, více než dvacetiletou historii. Vytvořila jej nevýdělečná profesní organizace Institut pro projektový management (Project Management Institute, PMI). 2.3.1.2 Struktura PMBOK PMBOK je tak zvaný framework (rámec). Popisuje techniky, nástroje a vstupní a výstupní dokumenty, které sdružuje do 44 izolovaných procesů v pěti skupinách. Pojem izolované vystihuje hlavní a zásadní rozdíl mezi PMBOK a například metodou PRINCE2.

21

Pojem „PMBOK“, Wikipedia – The Free Encyclopedia. 17

Obrázek 1: Základní schéma PMBOK

Zdroj: Příručka PMBOK, vlastní úprava

Zatímco metoda PRINCE2 je procesně orientovaná, provádí nás postupně všemi kroky nutnými k úspěšnému uřízení projektu, PMBOK nám naopak poskytne velmi detailní nástroje a techniky k jednotlivým krokům, které by se nám mohly hodit. Jak je uspořádáme do uceleného procesu, v tom nám PMBOK téměř neporadí. Tento typ rozdílu mezi dvěma metodikami můžeme nejlépe demonstrovat na jednoduchém příkladu: Mějme projekt Stavba domu. Budeme-li postupovat podle PRINCE2, pak nám bude řečeno: 1. krok – Získejte stavební povolení. 2. krok – Sežeňte si stavební plány. 3. krok – Vybetonujte základní desku. 4. krok – Postavte obvodové zdi. 18

...a tak dále. PMBOK nám naproti tomu poskytne rady v jednotlivých oblastech Takto se betonuje Takto se získává stavební povolení Takto se s využitím malty a cihel staví zdi Takto se zadávají stavební plány ...a tak dále. Obrázek 2: Přehled znalostních oblastí PMBOK

Zdroj: Příručka PMBOK, vlastní úprava

19

2.3.2 PRINCE2 Ve své práci se zaměřuji na PRINCE2, tato metoda bude podrobně popsána v dalších kapitolách.

2.3.3 Další metodiky Za určitou formu metodiky můžeme považovat také IPMA a její IPMA Competence Baseline (IPMA Základy kvalifikace). Na rozdíl od ostatních metodik se IPMA zaměřuje úzce na osobu projektového manažera, popřípadě jiného juniorního nebo seniorního člena projektového týmu s odpovídající zodpovědností a na kompetence, kterými by měl disponovat pro kvalitní výkon své role. IPMA definuje čtyři úrovně znalostí. Projektového manažera na základě příslušného přezkoušení certifikuje.

20

3 PRINCE2 – základní myšlenky PRINCE2 je zkratkou ze slovního spojení PRojects IN Controlled Environment „Projekty v kontrolovaném prostředí“, dvojka značí druhé revidované vydání. Pochází ze Spojeného království a jejím garantem a vlastníkem je Britská obchodní komora Office of Government Commerce, OGC. Vznikla z důvodu nutné standardizace projektového prostředí s hlavním důrazem na řízení veřejných zakázek.

3.1 Historie22 Původní metodu PROMPT (Project, Resource, Organisation, Management and Planning Techniques, Technika pro plánování a řízení zdrojů, organizace a projektu), předchůdce PRINCE, vyvinula společnost Simpact Systems Ltd. ve snaze pomoci firmám a jejím projektovým

manažerům

řešit

neustále

se

opakující

problémy

s mnohonásobným

překračováním rozpočtů a termínů. PROMPT v roce 1979 adoptovala britská vládní agentura CCTA (Central Computing and Telecommunications Agency), součást Britské obchodní komory. Později se z ní řadou přeměn stala PRINCE a ta se vyvinula do zmodernizované podoby PRINCE2. Název se již od té doby nezměnil; PRINCE3 zatím nevznikl a zdá se, že v dohledné době ani nevznikne. Přibývá jen označení roku poslední významné revize. 1975: PROMPT 1979: PROMPT adoptována Britskou obchodní komorou 1989: PRINCE 1996: PRINCE2 2005: PRINCE2 - revize z roku 2005 2009: PRINCE2 - revize z roku 2009

22

Historie PRINCE2: Oficiální stránka metody - http://www.ogc.gov.uk/prince2. 21

3.2 Filosofie metody Původně byla metodika určena pro projekty v oblasti informačních technologií a informačních systémů (IS/IT), ale brzy došlo k širokému přijetí metody i mimo oblast IS/IT. Jde o procesně orientovaný návod („kuchařku“) pro řízení jakkoli rozsáhlých projektů. Procesní orientovanost je zde klíčová, neboť prostupuje celou metodikou. Tvoří ji 45 podprocesů sdružených do osmi procesů. PRINCE2 je tzv. exceptions driven tedy „řízena výjimkami“. Tuto vlastnost můžeme chápat jako snahu o zbytečné nebyrokratizování projektového managementu neustálými a zbytečnými hlášeními o stavu projektu. Zodpovědným řídícím subjektem jsou stanoveny tolerance, především časové, finanční a kvalitativní, ve kterých se může nižší instance řízení pohybovat při svém rozhodování. O konání v tomto dovoleném rozsahu není potřeba v rámci jednotlivých etap (stages) vytvářet reporty směrem k vyšší instanci řízení. Teprve porušení tolerancí vyžaduje informovat nadřízenou instanci a požádat ji o radu či o rozhodnutí. Pozn.: V revizi 2005 byla pravomoc Projektového manažera rozšířena o možnost rozhodnout, zda vybočení ze schválených tolerancí má vliv na další běh projektu a teprve pokud vliv má, je povinen eskalovat. PRINCE2 nazývá projektové dokumenty „manažerskými produkty“ (management products). Týká se to všech dokumentů, které nejsou součástí produktů, ale jsou nutné pro samotné řízení a běh projektu. Za manažerský produkt tedy považujeme Projektový plán, Projektový mandát, Hlášení o výjimce a další. Naopak průvodní dokumentace, která je v přímé souvislosti s tvorbou produktu, jako jsou návody k použití, schéma řešení, podklady k patentovému řízení a jiné se za manažerské produkty nepovažují. Pro vedení projektu podle PRINCE2 platí, že všechny procesy a manažerské produkty, které metodika požaduje jsou povinné. Na druhé straně PRINCE2 neříká nic o formě těchto dokumentů ani o formě jednotlivých procesů. Pokud všechny zůčastněné strany souhlasí, aby forma Hlášení o výjimce mohla být ústní či přes elektronickou poštu, je tím tato povinnost splněna.

22

PRINCE2 je waterfall metodika, současně je třeba uvést, že kupříkladu autoři agilní metodiky DSDM (Dynamic Systems Development Method)23 se PRINCE2 inspirovali a obě metody jsou úspěšně kombinovatelné. Rovněž autor této práce má praktickou zkušenost z projektů, na kterých bylo projektové řízení založeno na PRINCE2 a vývoj software byl řízen agilně kombinací Scrum (s třítýdenními sprinty), Extrémní programování (Extreme Programming) a Párové programování (Pair Programming)24. Metodice PRINCE2 bývá vytýkáno, že se nedostatečně věnuje sledování vývoje prací na produktu, nepokrývá prakticky vůbec post-implementační fázi a také přizpůsobení metodiky velikosti projektu bylo doposud řešeno mimo rámec samotné metodiky. (více v kapitolách PRINCE2 pro malé projekty a Revize PRINCE2 z roku 2009). PRINCE2 je v některých firmách používána jako ucelená metodika, v některých firmách je interní metodika do větší či menčí míry PRINCE2 inspirována. Ve všech případech bez výjimky však platí, že PRINCE2, stejně jako jakákoli jiná externě vyvinutá metodika, musí být bezpodmínečne přizpůsobena podmínkám a požadavkům konkrétní společnosti.

3.3 Důraz na obchodní zdůvodnění Důraz na Obchodní případ (Business Case) je významnou výhodou PRINCE2 oproti jiným metodikám a frameworkům, které zapomínají provedení projektu – otázku Jak?- propojit s odpovídající odpovědí na otázku Proč? Obchodní případ můžeme zjednodušeně popsat jako zdůvodnění k investicím, ke kterým se rozhodujeme. Hodnotíme-li plánovanou investici s ohledem na její přínos pro společnost, potom analýzu provedeme navrhnutím více variant včetně tak zvané nulové varianty (nebudeme dělat nic), porovnáme aktivní varianty (budeme investovat prostředky) s variantou nulovou a provedeme výběr nejvhodnější z nich. Chceme-li být důslední a máme v plánu po skončení projektu zhodnotit skutečně dosažené přínosy, pak musíme také tyto přínosy v Obchodním případu přesně popsat a stanovit pro ně měřitelná kriteria. PRINCE2 nás k tomuto motivuje.

23 24

DSDM: Strukturovaná agilní metodika pro vývoj informačních systémů, využívá iterací a zapojení zákazníka. Pair Programming: dvojice vývojářů se stejnými znalostmi se střídá při psaní programového kódu. 23

Obchodní případ je důležitý nejen v okamžiku zahájení projektu, ale stejně tak by měl být revidován v jeho průběhu na jednotlivých milnících. Prostředí kolem projektu a kolem společnosti se neustále mění, konkurence může uvádět na trh nové produkty, mohlo dojít ke změně ekonomické či legislativní situace. To všechno mohlo způsobit, že výsledný produkt již není nebo v okamžiku dokončení nebude přínosem. Tím kdo sleduje aktuálnost Obchodního případu je Projektový manažer za podpory od Projektové rady.

3.4 Zkrácený popis procesů a komponent PRINCE2 Tato kapitola si neklade za cíl provést čtenáře celou mapou procesů PRINCE2 se všemi jeho nuancemi. Snahou je popsat ve zkratce hlavní komponenty, procesy a techniky, které se ve standardní, originální PRINCE2 vyskytují.

3.4.1 Organizace projektu V projektu vedeném podle PRINCE2 je jasně definovaná organizační struktura projektového týmu, ve které každá role má své (často nezastupitelné) místo. Obrázek 3: Organizační struktura projektového týmu

Vedení společnosti (programu)

Projektová rada Senior uživatel

Předseda proj. rady

Senior dodavatel

Zajištění projektu

Projektový manažer Podpora projektu

Vedoucí týmu Vedoucí týmu Vedoucí týmu

Zdroj: Manuál PRINCE2, vlastní úprava

24

Plná zodpovědnost za projekt je vedením společnosti nebo programu (Corporate/Programme Management) delegována na Projektovou radu (Project Board) prostřednictvím jejího předsedy (Executive). Dalšími dvěma členy Projektové rady jsou zástupce Dodavatele25 – Senior dodavatel (Senior Supplier) – a zástupce Zadavatele – Senior uživatel (Senior User). Senior dodavatel by měl mít plný vliv na tu část projektu, která zajišťuje přípravu a vývoj výsledného produktu (produktů). Naopak Senior Uživatel reprezentuje budoucí uživatele, měl by být schopen stanovit parametry produktu (produktů) a rozhodnout, zda došlo ke splnění zadání v oblasti dodávky produktů. Každodenní úkoly spojené s výkonem projektového managementu provádí Projektový manažer, který je podřízen Projektové radě. Plánuje a kontroluje průběh jednotlivých fází projektu, rozhoduje v rámci stanovených kriterií a informuje o případných úspěších či problémech Projektovou radu. Projektový manažer dílčí úkoly ve vedení projektu, ale především na přípravě a vývoji výsledných produktů zadává jednotlivým Vedoucím týmů (Team Managers). O dohled nad celým projektem se stará role Zajištění projektu (Project Assurance). Úkolem Zajištění projektu je odhalit případné nesrovnalosti zejména mezi zprávami o statusu projektu od Projektového manažera směrem k Projektové radě. Je povinna neustále ověřovat, zda projekt směřuje vytyčeným směrem z pohledu termínů, rozpočtu, kvality atd. Pro úspěšně dokončený projekt je role Zajištění projektu klíčová. Zodpovědnost za projekt a jeho kontrolu zůstává na Projektové radě, Zajištění projektu je jen výkonný kontrolní orgán. Svého zástupce by měl do Zajištění projektu delegovat každý člen Projektové rady. Není to však povinné, členové projektové rady mohou tuto roli vykonávat sami. Je nepřípustné delegovat kteroukoli z pravomocí Zajištění projektu na Projektového manažera. Naopak jmenování osob nebo osoby do role Podpory projektu není povinné. Jedná se o administrativní podporu Projektového manažera v úlohách, které nejsou klíčové a jsou časově 25

Dodavatel: ta část projektu, která se stará o přípravu a dodání výsledného produktu (produktů). 25

náročné případně vyžadují nějakou specifickou znalost (například informačního systému). Není-li Podpora projektu přítomna, jsou její úkoly zodpovědností Projektového manažera, včetně například Knihovníka konfigurací (Configuration Librarian)26.

3.4.2 Základní procesy metody Obrázek 4: Základní procesy metody PRINCE2 Management společnosti, programu

Vedení projektu

Zahájení projektu

Nastevení projektu

Kontrola etapy

Řízení hranic etapy

Uzavření projektu

Řízení dodávky produktu

Plánování

Zdroj: Manuál PRINCE2, vlastní úprava

3.4.2.1 Zahájení projektu Úvodní etapou je Zahájení projektu (Starting Up a Project), jejíž hlavním vstupem je Projektový mandát (Project Mandate) od vedení společnosti případně vedení programu, jehož je projekt součástí. Během Zahájení projektu je jmenován Předseda rady projektu (Project Executive) a Projektový manažer a také zbytek projektového týmu. Především je však Projektový mandát rozpracován do podoby Charty projektu (Project Brief).

26

Knihovník konfigurací: Udržuje záznamy o produktech, o jejich verzích a řešeních problémů s nimi spojených. 26

3.4.2.2 Schválení nastavení Charta projektu je poskytnuta Projektové radě (Project Board), která prostřednictvím Schválení fáze nastavení (Authorising Initiation) schválí Projektovou chartu jako vstup pro etapu Nastavení projektu (Initiating a Project). 3.4.2.3 Etapa nastavení projektu Úkolem projektového týmu a především Projektového manažera v etapě Nastavení projektu (Initiating a Project) je naplánovat v hrubých rysech celý projekt s využitím podprocesů Plánování (Planning), založit odpovídající projektovou dokumentaci a předložit ke schválení hlavní operační dokument projekt. Tím je Dokument o nastavení projektu (Project Initiation Document, ve zkratce PID)27. 3.4.2.4 Schválení projektu Schválením Dokumentu o nastavení projektu došlo fakticky ke schválení projektu a projekt může začít. Od této chvíle každé ukončení projektu i těsně po okamžiku jeho schválení vyžaduje veškeré kroky popsané v etapě Uzavření projektu (Closing a Project). 3.4.2.5 Kontrola etapy Ve fázi Kontrola etapy (Controlling a Stage) probíhají všechny důležité činnosti nutné k dodání výsledného produktu či produktů projektu. Jsou také zachycovány a odpovídajícím způsobem řešeny veškeré problémy (Project Issues) ke kterým může dojít. Tato etapa je úzce spjata s etapou Řízení hranic etapy (Managing Stage Boundaries) a s etapou Řízení dodávky produktu (Managing Product Delivery). 3.4.2.6 Řízení hranic etap Fáze Řízení hranic etapy (Managing Stage Boundaries) je dohlížitelem nad průběhem fáze Kontrola etapy a Řízení dodávky produktu. Zajištuje plánování etap, stará se o řešení odhalených rizik a komunikuje s Radou projektu prostřednictvím pozitivních a negativních hlášení. 3.4.2.7 Řízení dodávky produktu Etapa Řízení dodávky produktu (Managing Product Delivery) je podřízena fázi Kontrola etapy. Jedná se o rozhraní mezi Projektovým manažerem a Manažy týmů (Team Managers) 27

Dokument o nastavení projektu, PID: dokument zachycuje všechny důležité informace o projektu. 27

respektive mezi Projektovým manažerem a externím dodavatelem. Základní komunikace probíhá prostřednictvím Zadání práce (Work Package). 3.4.2.8 Uzavření projektu Poslední etapou každého projektu podle PRINCE2 je Uzavření projektu (Closing a Project). Hlavním úkolem Projektového manažera v této fázi je předat výsledný produkt nebo produkty zákazníkovi, zajistit vrácení všech prostředků jejich vlastníkům, zrevidovat očekávaný přínos projektu se skutečně dosaženým (z pohledu dodavatele) a sepsání odpovídajících závěrečných zpráv. 3.4.2.9 Plánování Během projektu jsou veškeré kroky spojené s plánováním prováděny prostřednictvím procesu Plánování (Planning), který se táhne celým projektem již od fáze Zahájení projektu. Všechny úkoly jako odhady, analýza produktů a příprava faktických plánů se děje právě tady. PRINCE2 motivuje k používání standardních plánovacích technik jako je Ganttova tabulka. 3.4.2.10 Vedení projektu Dalším průběžným procesem je Vedení projektu (Directing a project). Tento proces je vykonáván Projektovou radou v čele s Vedoucím projektové rady. Jejím úkolem je schvalovat důležité fáze projektu a dále rozhodovat a radit Projektovému manažerovi o strategických otázkách souvisejících s projektem v jeho průběhu. Stejně tak Uzavření projektu a tím konec celého projektu schvaluje Projektová rada prostřednictvím právě tohoto procesu.

3.5 Revize PRINCE2 z roku 2009 Jak jsem již zmínil v kapitole o historii, v tomto roce (2009) byla vydána významná revize metody PRINCE2.

3.5.1 Motivace k revizi Motivačních faktorů pro vydání této revize byla celá řada. Došlo a stále dochází ke změně obchodního prostředí a je nutné se mu přizpůsobit. Ovšem hlavním stimulem pro tuto změnu byly ohlasy z uživatelské obce o přílišné rozsáhlosti, komplexnosti a byrokratičnosti metody a složitosti jejího učení a uplatňování v praxi. Naopak chybějící rady a vodítka v oblasti

28

přizpůsobení metody menším nebo naopak větším projektům, nedostatečné pokrytí oblasti měkkých dovedností a další.

3.5.2 Popis revize 200928 Odpovědí na tyto otázky není zcela jiná a zcela přepracovaná metoda. Autoři šli v tomto případě cestou změny jejího podání, interpretace a přiblížení metody uživatelům. Dochází ke snížení počtu hlavních procesů z osmi na sedm, žádné podprocesy již nebudou mandatorní, mají pouze formu doporučení. Rovněž dochází k částečné změně terminologie. Na první pohled je nejnápadnější rozdělení manuálu PRINCE2 na dva oddělené manuály: Vedení úspěšných projektů s PRINCE2 (Directing Successful Projects with PRINCE2) a Řízení úspěšných projektů s PRINCE2 (Managing Successful Projects with PRINCE2). Aktivita „vedení“ projektu (directing) je vyhrazena managementu společnosti, v našem případě prostřednictvím Rady projektu. Tato odlehčená verze manuálu popisuje širší kontext projektu a projektového managementu ve společnosti, ale nepopisuje detailně všechny techniky a procesy metody. Naopak „řízení“ projektu (managing) je kompletní manuál, revize předchozího Řízení úspěšných projektů s PRINCE 2 z roku 2005. Nevynechává žádné důležité aspekty metody a zohledňuje změny filosofie a přístupu této revize. Další významnou změnou je uvedení tak zvaných sedmi Principů. Ty mají vstup do metody zjednodušit novým uživatelům a budou od této chvíle metodu charakterizovat. Neboť právě těchto sedm vlastností vystihuje čím se PRINCE2 odlišuje od ostatních metodik a rámců. Patří sem například důraz na stále existující obchodní zdůvodnění, aktivní řízení rizika a zdůraznění zaměření pozornosti na dodání kvalitního výsledného produktu. V nové revizi je rovněž kladen větší důraz na praktické, konkrétní příklady využití metody. Jsou také popsány způsoby škálování metody.

28

Zdroj: Best Management Practice – http://www.best-management-practice.com. 29

4 PRINCE2 pro malé projekty Metoda PRINCE2 se může zdát jako příliš rozsáhlá a robustní a pro nevelké projekty nepraktická. Objem byrokratické zátěže při práci na manažerských produktech, na dodržování pokynů a doporučení může u malých projektů velmi snadno přesáhnout objem práce na výsledném produktu. V takovém případě není účelné nutit Projektového manažera k následování všech procesů, tvorbě všech hlášení a podobně.

4.1 Definice malého a velmi malého projektu Je obtížné jednoznačně definovat, kdy je projekt ještě dostatečně velký, aby na něj bylo smysluplné aplikovat všechny procesy, techniky a manažerské produkty (dokumenty) které PRINCE2 nebo její aplikace ve společnosti vyžaduje a kdy již nikoli. Pro některou společnost může být malým projektem úkol s rozpočtem menším než 500 tisíc Kč, pro jinou je to již běžný projekt vyžadující plné řízení. Dalším kriteriem může být délka trvání kratší než například jeden měsíc. Za velmi důležité můžeme rovněž považovat posouzení strategičnosti projektu v návaznosti na vizi nadřízeného programu nebo společnosti. Jedno pravidlo však platí vždy: náklady na řízení projektu musí být v odpovídajícím poměru k nákladům na celý projekt. Pokud prostředky investované do řízení projektu tvoří výrazně více než přibližně 15% (u malého projektu přibližně 30%) celkového rozpočtu, je řízení zřejmě neefektivní a je potřeba se velikosti projektu přizpůsobit. Jako vhodné škálování se jeví zhodnotit projekt podle více různých parametrů a poté rozhodnout o míře přizpůsobení jednotlivých procesů a technik (tedy použitím přístupu rozděl a panuj29), například:

•

Velikost organizace

•

Složitost / počet produktů

•

Plánování

•

Řízení rizik

...a tak dále 29

Rozděl a panuj: latinsky divide et impera – rozdělení problému na menší pro efektivnější vyřešení. 30

I projekt s malým projektovým týmem může dodávat velmi komplexní výsledné produkty. Zatímco do organizace projektu bude možné zasáhnout a Vedoucí projektové rady může například tvořit celou projektovou radu, naopak zhodnocení rizik a plánování dílčích dodávek bude vzhledem ke složitostí produktů třeba pokrýt důsledně. Stanovení kriterií, kdy se jedná o „standardní“, „malý“ či „velmi malý“ projekt by mělo být zohledněno v pokynech pro projektové řízení v dané organizaci. Za velmi malý projekt považujme pro účely této kapitoly projekt, jehož trvání nepřekročí dva týdny a jeho rozpočet nebude vyšší než 200 tisíc Kč.

4.2 Vhodnost použití metodiky pro malý projekt I malý projekt (a „velmi malý projekt“ viz dále) může snadno selhat a jeho řízení jen za pomoci intuice může přinést celou řadu problémů. V takové situaci nemusí být možné projekt efektivně řídit - pokud neměříme, nemůžeme ani efektivně řídit. Může být problémem u projektu ověřit jeho úspěšné ukončení, neboť zpravidla nemáme jasné zadání. Ale především se stává náročným řešení jakýchkoli nečekaných problémů. Například v oblasti náhle nedostačujícího rozpočtu - bez rozpadu rozpočtu na položky nemusíme být schopni identifikovat, která jeho část byla překročena. Můžeme čelit nedostatečně kvalitním či pozdním subdodávkám - jak je zkontrolujeme bez stanovených kriterií? A v neposlední řadě uvažujme změnu prostředí, ve kterém se projekt pohybuje - jak důležitou změnu prostředí identifikujeme, když nemáme pravidelně aktualizovaný Business Case? Proto se domnívám, že i pro malý projekt se vyplatí používat standardizovaný postup, ač v některých případech významně odlehčený. Součástí implementace projektové metodiky v organizaci je zpravidla i zavedení nových a nebo přizpůsobení stávajících informačních systémů pro správu rozpočtu, přidělování prostředků a pracovníků na projekt a plánování projektů a programů. Je v zájmu vedení organizace, aby veškeré nakládání a plánování finančních prostředků a lidských zdrojů bylo

31

odpovídajícícím způsobem zohledněno v centralizovaných systémech. Správně navrhnutý informační systém by neměl umožnit přidělit (alokovat) pracovníka nebo jiný zdroj jinak, než na úkol, který je součástí projektu v odpovídajícím stavu – platný, schválený projekt s přiděleným rozpočtem. Jak již bylo zmíněno, PRINCE2 vyžaduje zapojení všech procesů, komponent a dokumentů, které jsou její součástí. Na druhé straně ale nenutí, aby dokumenty byly v písemné formě. Pokud například všechny zůčastněné strany považují za dostatečné, aby Plán etapy (Stage plan) byl ve formě přehledného a srozumitelného e-mailu, je tím tato povinnost splněna. Poté existují tzv. „malé“ a „velmi malé“ projekty, u kerých ani velmi zjednodušené dodržování všech částí metodiky není smysluplné. V takovém případě je potřeba postupovat s použitím zkušeností Projektového manažera a Projektové rady a jejich zdravého rozumu (popřípadě s podporou od projektové kanceláře) při rozhodování o tom, které dokumenty, komponenty a procesy mají a které naopak nemají pro daný projekt smysl. Pokud si nejsme jisti, zda konkrétní implementace či aplikace PRINCE2 splňuje klíčové aspekty metody, může nám být vodítkem tak zvaný Model vyspělosti aplikace PRINCE2 (PRINCE2 Maturity Model)30, který vydala Britská obchodní komora.

4.3 Malý projekt V této kapitole se budu zabývat možnostmi, jak snížit náklady a objem administrační zátěže na projektový tým vhodným a odůvodněným škálováním.

4.3.1 Organizace Hlavní pověřenou osobou, mající zodpovědnost za celý projekt je Předseda rady projektu. Disponuje zásadními a nenahraditelnými pravomocemi a zodpovědnostmi - zejména dosažení plánovaného přínosu projektu a celkový dohled nad všemi klíčovými aktivitami projektu. Stejně tak není možné opomenout roli Projektového manažera, který řídí a koordinuje každodenní činnosti na projektu.

30

Model vyspělosti aplikace PRINCE2: Hodnotí funkčnost aplikace jednotlivých procesů PRINCE2 a poskytuje „známkování“ 1 až 3. 32

Předseda projektové rady může v určitých případech zastávat i funkci Senior uživatele, tedy reprezentovat budoucí uživatele výsledného produktu, kteří budou z výsledku těžit. Senior dodavatel je další mandatorní role v Projektové radě. Zde může být obtížné stanovit vhodného reprezentanta všech důležitých subdodávek. Je třeba vzít v úvahu hlavní atributy této pozice: Senior dodavatel musí být schopen ovlivnit kvalitu všech dodávek kritických pro projekt. To znamená, že pokud při projektu implementace počítačové sítě bude 60% projektu tvořit instalace sítě a zbylých 40% nastavení uživatelských počítačů a školení uživatelů, nemůžeme roli Senior dodavatele svěřit zástupci firmy, která nám instaluje počítačovou síť. Takový zástupce by totiž neměl možnost ovlivnit dodávky ve zbylých 40% projektu. Nejvhodnější alternativou se pro tuto roli jeví volba Manažera nákupu. Ten téměř jistě bude tímto malým projektem vytížen jen z určité části a velmi cenné jsou pro projekt jeho zkušenosti z vyjednávání podmínek s dodavatelskými firmami. Vhodnost Manažera nákupu pro pozici Senior dodavatele neplatí jen pro malý projekt, ale pro jakýkoli projekt zahrnující z významné části externí dodávky. U menšího projektu také kontrolní roli Zajištění projektu (Project Assurane) mohou zastávat členové Projektové rady. Při postupném vypouštění jednotlivých rolí se dostáváme ke stále minimalističtějšímu obrazu projektového týmu. U velmi zjednodušeného pojetí může organizace projektu vypadat takto: Obrázek 5: Minimalizovaná organizace projektu podle PRINCE2

Předseda rady projektu (Project Executive)

Projektový manažer

Zdroj: Bentley, Colin. Managing Small Projects with PRINCE2, vlastní úprava

Na projektu je angažován Předseda projektové rady (Projekt Executive) za Zadavetele a Projektový manažer za Dodavatele. U malého projektu může tato dvojice snadno tvořit celý

33

projektový tým. Předseda projektové rady zadává práci a přebírá výsledek a Projektový manažer je ten, kdo zajišťuje a dodává (popřípadě i sám vytváří) výsledný produkt.

4.3.2 Konfigurační management U nerozsáhlých projektů se v konfiguračním managementu můžeme omezit na jednoduché verzování produktů, minimalistický popis produktů převzatý ze zadávací dokumentace a aktualizaci stavu jednotlivých produktů a jejich kvalitativních revizí.

4.3.3 Řízení změn Při rozhodování o tom, jak detailní a propracovaný bude proces řízení změn na našem konkrétním (malém) projektu bychom si měli položit otázku „Jak budou řízeny neočekávané změny?“. Odpovídajícím způsobem bychom si k tomu měli připravit potřebné dokumenty, či upravit stávající. U malých projektů bude nejspíše roli správce změn zastávat Projektový manažer či Knihovník konfigurací (Configuration Librarian).

4.3.4 Obchodní zdůvodnění Jednou z esencí PRINCE2 je její trvání na existujícím, aktuálním a „neprůstřelném“ Obchodním případu (Business Case). I u malého či velmi malého projektu musíme mít precizně zdůvodněno, proč se do projektu pouštíme. Jednou z jeho důležitých součástí je zhodnocení investice do projektu a jeho návratnost. I pro malý / velmi malý projekt je toto zcela nezbytné v případě, že plánujeme žádat o rozpočet.

4.3.5 Plánování V PRINCE2 je vždy vyžadován Projektový plán (Project Plan). Rovněž Plán etapy (Stage plan) je povinný. Ale v případě, kdy je projekt tak malý, že jej bude tvořit jen zahajovací fáze a jedna etapa, můžeme tyto dva plány sjednotit do jednoho. Pokud dokážeme jednoduše odhadnout náklady a čas potřebný pro dodání produktu bez toho, abychom museli produkty dále dělit, můžeme taktéž vypustit proces Identifikace aktivit a závislostí (Identifying Activities and Dependencies).

34

4.3.6 Kontrola Je potřeba zvážit, zda potřebujeme formální a pravidelná hlášení nebo nám postačuje v ústní podobě. Pokud budeme sdružovat etapy Zahájení projektu (Project Startup) a Nastavení projektu (Project Initiation), je smysluplné také sjednodit hlavní nosné dokumenty těchto dvou etap – Chartu projektu (Project Brief) a Dokument o nastavení projektu (Project Initiation Document, PID).

4.3.7 Rizika K identifikaci rizik u malého projektu nemusíme zavádět formální Přehled rizik (Risk Log), ale stačí nám rizika přímočaře identifikovat a průběžně dokumentovat přímo u produktů.

4.3.8 Kvalita Musí být jasné, jakou kvalitu u výsledné dodávky zákazník očekává a tato úroveň musí být také zdokumentována. Dostatečný je zápis do Popisu produktu (Product Description), další speciální dokumenty jako je Projektový plán kvality (Project Quality Plan) nebo Etapový plán kvality (Stage Quality Plan) můžeme vypustit.

4.4 Velmi malý projekt Je-li náš připravovaný projekt příliš malý i na předchozí zjednodušení metody PRINCE2, existuje ještě další způsob náhledu na metodu a na její přizpůsobení našemu velmi malému projektu. Celý projekt můžeme při jeho velmi malé velikosti uřídit jako jeden ucelený úkol, tedy prostřednictvím Zadání úkolu (Work Package). V tom případě využijeme všech možností, které nám Zadání úkolu nabízí. Zcela zásadní při škálování tímto způsobem je bezchybně pochopit analogii Zadání úkolu se standardními procesy, technikami, ale zejména zadávacími dokumenty podle PRINCE2. Zvlášť se soustředíme na část Popis produktu (Product Description), neboť je spolu s navazujícím informací o kvalitativní kontrole i pro velmi malý projekt klíčová.Část Popis produktu rozšíříme o následující položky, které nám umožní přesné zadání se stanovenými kvalitativními kriterii a poté průhlednou kontrolu výsledného produktu

35

•

Název produktu

•

Účel

•

Složení produktu Členění na případné menší oddělené úkoly

•

Kvalitativní kriteria V souladu se sekcí Složení produktu

•

Metoda kvalitativní kontroly Testy, inspekce, revize aj.

•

Předpoklady pro kvalitativní kontrolu, identifikace osob Kdo bude kontrolovat kvalitu výsledného produktu a jaké speciální znalosti u kontrolujících osob požadujeme Tabulka 1: Zadání úkolu

Zadání úkolu / Definice projektu Datum

20.3.2007

Název úkolu

Zorganizování tiskové konference za účelem prezentace nového produktu SOFTWARE1

Účel

Zvýšení povědomí o produktu SOFTWARE1 za účelem zvýšení jeho prodeje mezi odbornou veřejností

Zadavatel

Evžen Urban, produktový manažer

Zodpovědná osoba,

Jana Nováková, oddělení pořádání společenských akcí

osoby Složení produktu /

Připravit program tiskové konference

úkolu

Vybrat a pozvat zástupce medií Zajistit prostory pro konání konference Zajistit občerstvení pro konferenci

Kvalitativní kriteria

Program bude odpovídat formátu konference a produktu Dostaví se >60% pozvaných medií, produkt získá odpovídající mediální pokrytí Prostory budou odpovídat konferenci, vhodné ozvučení 36

Občerstvení bude kvalitou a množstvím odpovídat obecenstvu Metoda kvalitativní

Osobní inspekce, media monitoring

kontroly Předpoklady pro

Inspekce přítomným vedoucím marketingu,

kvalitativní

zhodnocení konference bude provedeno analýzou mediálního

kontrolu,

pokrytí a celkovým dojmem z konference a revizí termínů a

identifikace osob

nákladů konference

Nástroje, techniky,

Přenosné PC, případné doplňky a nábytek ze skladu

procesy, procedury Rozhraní

Tisk pozvánek a tiskovin zajistí reklamní oddělení

Náklady, časování

Rozpočet na tiskovou konferenci je 110 000,- Kč Začátek přípravy je 27.3.2007, ukončení úkolu v den konání konference Příprava konference bude hotova a prezentována týden před konáním

Schválení

Schválení na základě zhodnocení konference potvrdí vedoucí marketingu

Omezení

Vyvarujte se neodůvodněného překročení rozpočtu

Za zadavatele: V Praze dne ………. Podpis ……………………. Zdroj: Bentley, Colin. Managing Small Projects with PRINCE2 – vlastní úprava.

4.5 Shrnutí poznatků Předpokládáme-li, že v naší organizaci používáme pro řízení projektů metodiku PRINCE2, pak je její nepoužití pro malý i velmi malý projekt nezodpovědné. Ztrácíme přehled o volných a rezervovaných prostředcích, je obtížné sledovat průběh projektu, připravujeme se o nástroje ke sledování a řešení rizik a kvality a velmi často si ani nejsme jisti, zda dodaný produkt přinesl nějaký měřitelný užitek.

37

PRINCE2 nám toto vše umožňuje. Přizpůsobíme-li odpovídajícím způsobem metodu našemu projektu jsme schopni i nerozsáhlý projekt uřídit s použitím jádra metody PRINCE2 se zachováním klíčových vlastností a technik metody. V kontextu organizace nám tento přístup umožní také administrativní ošetření průběhu projektu, to znamená alokování zúčastněných osob v odpovídajících informačních systémech a zahrnutí projektu do vykazování směrem k vedení společnosti.

38

5 Využívání PRINCE2 v České republice U středních i velkých lokálních podniků v České republice panuje situace, že drtivá většina používá své vlastní standardy, které do značné míry odrážejí jejich historické vazby na zažitý způsob řízení, který bychom mohli zjednodušeně označit jako nevědecký, založený na technikách operativního řízení. Pro typického vlastníka společnosti nepředstavuje moderní způsob řízení motivaci pro nákladnou investici do implementace projektové metodiky. Nejčastějšími uživateli metody PRINCE2 v České republice jsou proto zastoupení zahraničních společností.

5.1 Praktické používání PRINCE2 v České republice a v regionu Přehled subjektů v této kapitole jsem sestavil z informací z vlastního osobního kontaktu s těmito organizacemi prostřednictvím přímých dotazů a doplnil je informacemi od konzultantských společností, zejména Pearce & Mayfield a Symphera. V České republice se na metodu PRINCE2 vyškolí každý rok více projektových manažerů než v jiných i mnohem větších evropských zemích, například ve Francii. Existují i české subjekty, které metodiku školí nejen v Čechách, ale i na západ od našich hranic. Kromě toho již vznikl oficiální překlad základních pojmů, procesů, komponent a dokumentů metodiky. Připravuje se česká verze závěrečných zkoušek na certifikaci metodiky úrovně Foundation a Practitioner. Rovněž je v přípravě český překlad manuálu Managing Successful Projects With PRINCE2. Stále však platí, že rozšíření této metody mezi subjekty v České republice není příliš vysoké, mimo jiné i díky jazykové bariéře. Subjekty v přehledu nejsou jen soukromé společnosti, záměrně jsem zahrnul i vlády evropských států, o kterých tuto informaci mám a které tvoří významnou skupinu uživatelů i v celoevropském měřítku.

39

5.1.1 Subjekty které PRINCE2 používají nebo plánují používat Česká republika Tabulka 2: Subjekty v Č.R. používající PRINCE2

Acision

Vnitřní metodika je postavena na PRINCE2

Cleverlance

Metodika PRINCE2

ČSOB


DHL


Fujitsu Siemens

PRINCE2 je zde mandatorní metodika

GTS Novera

Má vyškolené odborníky na PRINCE2, zvažuje implementaci

IBM

Má vyškolené odborníky na PRINCE2, zvažuje implementaci

ING


Lease Plan


Logica

vnitřní metodika je postavena na PRINCE2

Microsoft

Uvažuje o PRINCE2, aktuálně má metodiku využívající techniky z PMBOK

Ness


Rádio Svobodná Evropa PRINCE2 je zde mandatorní metodika Tesco Stores


Vláda České republiky

Uvažuje o PRINCE2 Zdroj: Vlastní.

Mimo Českou republiku Tabulka 3: Subjekty používající PRINCE2 mimo Č.R.

Deutsche Post


Orange

Uvažuje o PRINCE2

40

Vláda Slovenské

Bude od roku 2009 používat PRINCE2

republiky Holandsko

Používá PRINCE2

Německo

Používá PRINCE2

Velká Británie

Používá PRINCE2 (kolébka PRINCE2)

NATO

Používá PRINCE2

OSN

Používá PRINCE2

EU

O PRINCE2 se uvažuje jako o oficiální metodice Evropské Unie Zdroj: Vlastní.

5.2 Závěr k používání PRINCE2 v České republice a v regionu Z přehledu je vidět jaké obliby se metodika těší u nadnárodních uskupení a evropských vlád. Vláda Slovenské republiky se pro metodiku rozhodla jako pro mandatorní pro své ICT31 projekty, ale nakonec dochází k rozšíření záběru i mimo ICT. Je pravděpodobné, že vláda České republiky se také nechá tímto standardem v budoucnu přesvědčit. Většímu rozšíření mezi čistě českými podniky brání nedokončená lokalizace tištěných a elektronických materiálů, určitá nedůvěra k přijímání obecných standardů a především obava z příliš vysokých nákladů na její implementaci.

31

ICT: Information and Communication Technologies - Informační a komunikační technologie, běžně používaná zkratka, obdoba IS/IT. 41

6 Příklad využití PRINCE2 pro řízení konkrétního projektu Cílem této kapitoly je ukázat využití metodiky PRINCE2 v podnicích v České republice, a poukázat na významné a přínosné odchylky od PRINCE2 na příkladu konkrétního a zdokumentovaného projektu. Tato kapitola pokrývá dvě oblasti z metodiky: -

Zadávací fázi

-

Klíčové schvalovací body v celém procesu

Aplikaci metody budu prezentovant na příkladech dvou podniků: Podnik A je firma z oblasti zákaznických služeb, Podnik B je společnost z finančního sektoru.

6.1 Zadávací fáze projektu Zadávací fáze je klíčová pro úspěšné zvládnutí projektu. Bez kvalitního zadání prakticky není možné dodat kvalitní produkt.

6.1.1 Srovnání aplikace zadávacího procesu Tabulka 4: Srovnání zadávacího procesu

PRINCE2

Projektový mandát (Project Mandate) Zadavatel → Dodavatel

Podnik A

Podnik B

Žádost o informaci

Ideový návrh

(Request for Information)

(Idea Proposal)

Zadavatel→Dodavatel


42

Informace (Information) Zadavatel ←Dodavatel

Žádost o odhad pracnosti

Ideový dokument

(Request For Estimation)

(Idea Document)


Zadavatel ←Dodavatel

Nezávazný odhad (Non-Binding Estimate) Zadavatel ←Dodavatel

Žádost o kotaci

Charta úvodní studie

(Request For Quotation)

(Pre-study Charter)

Zadavatel → Dodavatel


Kotace

Úvodní studie

43

(Quotation)

(Pre-Study Report)



Objednávka resp. Smlouva (Order / Contract) Zadavatel ↔ Dodavatel Zdroj: Vlastní

Podle PRINCE2 je prvotním impulsem pro zahájení prací na přípravě projektu tzv. Projektový mandát (Project Mandate) od vedení společnosti nebo vedení programu, jehož je potenciální nový projekt součástí. Zpravidla by se mělo jednat o formalizovaný dokument. Součástí Projektového mandátu by mělo být hrubé zadání projektu, nástin důvodů pro projekt (bude později vstupem pro Obchodní případ (Business Case)) a také identifikace pracovníka odpovědného za projekt (Project Executive). Projektový mandát by měl dát přibližnou odpověď na otázky Kdo?, Co? a Proč? bude dělat. Takto by vypadal Projektový mandát pro obecný projekt podle standardní PRINCE2: Tabulka 5: Obecný Projektový mandát

Projektový mandát 1

Účel

2

Zodpovědná osoba

3

Pozadí projektu

4

Cíle projektu

5

Rozsah projektu

6

Omezení

7

Vnější vazby 44

8

Kvalitativní požadavky

9

Návrh Obchodního případu (Business Case)

10

Navržený Vedoucí projektové rady a Projektový manažer

11

Zákazníci a uživatelé

Zdroj: Britská obchodní komora, vlastní úprava

Tento dokument sice obsahuje základní popis položek zadání, avšak tyto informace poskytuje jednostranně Zadavatel a nestará se o to, zda Dodavatel skutečně bezchybně pochopil všechny atributy

zadání.

Navíc,

v reálném,

byť

kontrolovaném

prostředí

společnosti

je

nepravděpodobné, abychom zadavatele projektu vůbec přinutili k formalizovanému zadání ve formě Projektového mandátu. Z vlastní zkušenosti vím, že i pro velmi rozsáhlé projekty v řádech milionů EUR bude mít zadání často formu dvou řádků v e-mailové zprávě.

6.1.2 Podnik A Právě z tohoto důvodu je v Podniku A Projektový mandát nahrazen procesem, který se o preciznost zadání stará. Na procesu se dohodly obě strany poté, co analýza ukázala výhody kvalitně zpracovaného zadání projektu: dojde k ušetření nákladů oběma stranám, zadavateli (Business) i dodavateli (IT). Pro stranu Zadavatele a tím pro celý Podnik A je hlavním přínosem urychlení projektu a tedy dřívější implementace požadované změny a dřívější uvedení nového produktu na trh.

45

Obrázek 6: Zadávací proces v Podniku A

Posouzení příležitosti

Zahájení projektu

Kontrakt

Vyjednání, schválení

Žádost o kotaci

Kotace

Klasifikace příležitosti

Žádost o nabídku

Žádost o odhad

Nabídka

Nezávazný odhad

Formulace odpovědi

Žádost o změnu

Nabídka změny

Příležitost

Zákazník


Informace

Zákazník

Zdroj: Vlastní

Základem procesu je iterativní komunikace mezi Zadavatelem a Dodavatelem. Jejím výsledkem je dokument ve formě Kontraktu (smlouvy). 6.1.2.1 Prvotní analýza příležitosti Zjištěná příležitost je analyzována příslušným Obchodním architektem32 na straně Zadavatele za úzké spolupráce se sponzorem33 potenciálního projektu. Případné nejasné body technického charakteru nutné pro správné rozhodnutí jsou konzultovány s Dodavatelem prostřednictvím Žádosti o informaci. Poté je příležitost klasifikována na odpovídající typ žádosti, je rozhodnuto, jakou formou bude poptáván Dodavatel. 32 33

Obchodní architekt: člen organizace Zadavatele, specialista na produkty, služby, či cílovou skupinu. Sponzor: zpravidla senior manažer společnosti, z jehož rozpočtu bude projekt financován. 46

6.1.2.2 Klasifikace Žádosti Klasifikace probíhá prostřednictvím posouzení řady faktorů. Jedním z klíčů je velikost předpokládané investice, přičemž přibližně platí Kotace ≈ Nabídka > Odhad > Změna. Jednotlivé dokumenty a s nim spojené procesy budou detailněji popsány dále. Vliv má také předchozí zkušenost s Dodavatelem v této oblasti. I rozsáhlá investice do již běžícího systému, jehož je Dodavatel autorem je poptávána formou Žádosti o změnu popřípadě Žádostí o odhad. Dalším důležitým vodítkem může být existence rámcového kontraktu z přechozí zakázky na podobné téma, jehož se nová žádost stane další přílohou. Naopak zavedení zcela nového, i když nerozsáhlého systému v sobě může skrývat rizika, která bude nejlépe adresovat Žádost o kotaci. Ta pokrývá i témata jako reference či odbornou zdatnost důležitých členů projektového týmu. Dalším důležitým kriteriem je závaznost Žádosti nebo ještě lépe Odpovědi na ni. U Žádosti o informaci o žádnou závaznost nejde. Pokud je poskytnutá Informace pravdivá a naplňje požadavky Žádosti, Dodavatele k ničemu nezavazuje. Podobné to je u Žádosti o odhad. Odpovědí na ni je Nezávazný odhad (Non-binding Estimate), který nebývá ani časově omezen, neboť se nepředpokládá, že by přímo tato forma odpovědi byla použita jako vstup pro Kontrakt. Naopak všechny tři zbylé formy: Žádost o změnu, Žádost o nabídku a Žádost o Kotaci předpokládají, že ten kdo odpověď podává je připraven a schopen v tomto duchu také plnit. To znamená pro autora odpovědi důsledné zjištění nákladů na technologie a lidské zdroje, dostupnost manažerů i specialistů a rovněž před-alokaci (rezervací) odpovídající pracovní síly. Nezávazný odhad má ještě jedno specifikum. U každé odpovědi směřující od Dodavatele k Zadavateli je jasně definováno, v jakém procentuálním rozmezí by se měla pohybovat výsledná cena za projekt vůči jejímu předchozímu odhadu. U Nezávazného odhadu bude například stanoveno, že tolerance je plus minus 50%. To znamená, že Zadavatel může předpokládat navýšení či snížení finálního rozpočtu. Nakonec k navýšení pravděpodobně 47

dojde, ale nemělo by překročit o více jak 50% cenu odhadu. U Kotace či u nabídky je tato hodnota stanovena také, ale je úměrně nižší; může se jednat o plus minus 10% až 25%. 6.1.2.3 Kotace versus Nabídka Ještě uveďme rozdíl mezi dvěma velmi podobnými formami poptávek: Žádost o nabídku a Žádost o kotaci. Obě jsou nejpodrobnějšími formami poptávky / nabídky a liší se především účelem, pro jaký jsou zpracovávány. Zatímco Kotace obsahuje věcné informace týkající se projektu, předpokládá zájem zákazníka o službu Dodavatele a popisuje otevřeně náklady na konkrétní části projektu, otevřeně poukazuje na případné slabiny řešení, nezabývá se zpravidla příliš detailním popisem technického řešení. Jedná se o čistě vnitropodnikový způsob vyjednávání, pouze s určitými prvky tržního chování. Nabídka má charakter dokumentu s nímž se dodavatel účastní tendru na získání určité zakázky. Jedná se tedy o komparativní vstup do boje s jinými, v tomto případě externími, potenciálními dodavateli. V Nabídce bude daleko více kladen důraz vyzdvihnutí kladných stránek nabídky či řešení a naopak nelze předpokládat explicitní popis bodů, kterými si předkladatel není stoprocentně jist. Předkladatel popíše podrobně technické řešení, aby na příkladu ukázal jeho výhody či parametry. Také se zaměří daleko více na finanční stránku: nabídne atraktivně vypadající slevy či bezplatné služby. I forma nabídky a její prezentace bude významně poutavější, předkladatel se bude snažit zadavateli „prodat“ právě své řešení. Zcela shodně se totiž bude k poptávající straně chovat i kterýkoli jiný předkladatel. 6.1.2.4 Podání odpovědi Zpracování odpovědi na Žádost o kotaci, Žádost o nabídku, Žádost o odhad nebo Žádost o změnu dostává na starost (u nového projektu) jmenovaný Manažer nabídky (Bid Manager), což je další role Projektových manažerů; u již existujícího projektu či programu pak Projektový manažer předchozího projektu.

48

Obrázek 7: Organizační struktura a vazby na projektu v Podniku A

Zadavatel

Dodavatel

Programový manažer

Programový manažer

Obchodní architekt

Obchodní manažer

Produktový manažer

Projektový manažer (manažer nabídky)

Projektový manažer

Projektový tým Projektový tým Projektový tým

interní komunikace externí komunikace

Zdroj: Vlastní

Právě Manažer nabídky je osobou, jež provádí vyjednávání o detailech zadání (ale nikoli o kontraktu). Poté na základě konzultace se specialisty o hrubém návrhu řešení, po zjištění cen za technologie a hardwarové prostředky sestaví odpověď na některou ze žádostí. Jako nástroj využívá vnitřního informačního systému, ve kterém jsou vloženy ceny pro jednotlivé typy odborností a další složky řešení. Jednou z možností odpovědi na kteroukoli Žádost může také být odpověď negativní. To může být způsobeno například

•

Nevýhodností Žádosti pro dodavatele: dodavatel si uvědomí, že náročnost řešení je příliš velká bez dostupných specialistů a že nabídnutá cena bude zadavatelem neakceptovatelná

49

•

Požadavek je v rozporu s jiným probíhajícím nebo chystaným projektem nebo programem

•

Náklady na upgrade či úplnou změnu technologie jsou ve značné nerovnováze s měřitelnými přinosy pro Zadavatele

Garantem finálního rozhodnutí o tom, zda podat pozitivní nabídku je vždy Programový manažer na straně Dodavatele který může přenechat tuto odpovědnost příslušnému Produktovému manažerovi – právě tato dvojice manažerů musí mít natolik kvalitní přehled o svém produktovém portfoliu, aby byla schopna odhalit případné nesrovnalosti či překryvy a zákazníka na ně upozornit. Z osobní zkušenosti vím, že v případech komplexních, nepříjemných či jinak „nechtěných“ projektů Obchodní manažer34 (případně Projektový manažer nominovaný do role Manažera nabídky) záměrně stanoví vysoce nadsazenou cenu, zcela nevyhovující termíny a nebo popíše nesmyslné předpoklady (Assumptions), aby tím docílil neschválení nabídky zadavatelem a nezahájení projektu, ale aby současně splnil povinnost podat nabídku. Tím se ovšem Dodavatel přestává chovat tržně a v rozsáhlých organizacích přesně tato situace vede Zadavatele k získání nedůvěry v Dodavatele a hledání externí dodavatelské firmy. Přitom stačí otevřeně přiznat obavy z tématu, věcně je popsat a poté společně nalézt alternativní řešení ve formě odkladu projektu, společného nalezení externího dodavatele, angažování zkušenějšího Projektového manažera atp. 6.1.2.5 Iterativní proces upřesňování Iterativním a interaktivním prvkem v popisovaném procesu je postupný vývoj a upřesňování požadavku přes více než jednu formu Žádosti / Odpovědi. Uvažujme nový projekt. 1

V prvním kroku (v první iteraci) se Zadavatel zpravidla zeptá Dodavatele na nějakou důležitou vstupní informaci prostřednictvím Žádosti o informaci, kterou od Dodavatele coby Informaci získá. To Zadavateli pomohlo s upřesněním Příležitosti, kterou dále analyzuje

34

Obchodní manažer: Account Manager – obchodník, obchodní zástupce. 50

a. Odpověď: Informace 2

Poté se rozhodne podat některou z vyšších forem žádosti, například Žádost o odhad. Tímto Zadavatel získá z Nezávazného odhadu představu o přibližné výši investice. a. Odpověď: Nezávazný odhad

3

Dále podává Dodavateli další žádost, tentokrát buď Žádost o nabídku nebo Žádost o kotaci a. Odpověď: Kotace

4

Krokem číslo čtyři již bude pravděpodobně akceptace Kotace respektive Nabídky a dojednání odpovídajícího Kontraktu. a. Výsledek: Kontrakt

6.1.2.6 Finální vyjednávání Během poslední iterace v kroku Vyjednání, schválení jsou doladěny body, jež nebyly doposud pokryty v navzájem vyměněných dokumentech a jedná se o klasické obchodní vyjednávání. Výstupem je buď rozhodnutí Zadavatele oslovit Dodavatele s další Žádost a nebo pokračovat přímo směrem k uzavření smlouvy a zahájení projektu. Stranu Zadavatele zde zpravidla zastupuje Programový manažer vedoucí program, jehož je projekt součástí, Projektový manažer zadavatele a Obchodní architekt odpovídající domény. Jeden z těchto, zpravidla Programový manažer Zadavatele, bude v budoucí Projektové radě plnit roli Senior zákazníka. Za stranu Dodavatele jsou to pak budoucí členové Projektové rady: Executive a/nebo Senior dodavatel, dále Obchodní manažer dodavatele (Account Manager) a je-li již v tuto chvíli vybrán, tak rovněž budoucí Projektový manažer, například z předchozího projektu ve stejném programu. 6.1.2.7 Alternativní proces – pouze Kotace V Podniku A se používá ještě alternativní, zjednodušený, proces odpovědi na Žádost. To se týká situace, kdy Manažerem nabídky je Projektový manažer, jenž je již v kontaktu se Zadavatelem a má představu o jeho potřebách. Proto očekává, že po Žádosti o odhad nebo Žádosti o změnu bude jako další následovat Žádost o kotaci. Z tohoto důvodu nabídne Zadavateli rovnou Kotaci.

51

Obrázek 8: Zadávací proces v Podniku A - pouze Kotace

Zahájení projektu

Kontrakt

Posouzení příležitosti

Vyjednání, schválení

Žádost o kotaci

Klasifikace příležitosti

Žádost o nabídku

Žádost o odhad

Žádost o změnu

Příležitost

Zákazník


Informace Kotace

Formulace odpovědi

Zákazník

Zdroj: Vlastní

Toto můžeme označit jako určité tržní chování vůči zákazníkovi. Kotace totiž obsahuje více informací, než kolik by obsahoval Nezávazný odhad nebo Nabídka změny. Aby byla splněna povinnost závaznosti, musí si být autor Kotace natolik jist pochopením požadavku, aby dokázal před-alokovat (rezervovat) požadavané zdroje. V hodnocení zda tato cesta je či není korektní vycházejme z předpokladu, že reálný svět není černobílý. Neplatí, že při vypracování Nezávazného odhadu víme velmi málo o požadavku a naopak při tvorbě Kotace máme všechny potřebné informace pohromadě v odpovídající kvalitě. Mnohdy tomu může být téměr naopak. Výhodou je také snížení byrokratické zátěže přípravné fáze přeskočením jedné nebo více iterací a výměnou a upřesňováním jen jednoho široce používaného a přijatého typu dokumentu a dolaďování případných změn přímo v něm.

52

6.1.2.8 Příklad konkrétního projektu s dokumentací Jako ukázkový projekt pro demonstraci použití procesů a dokumentů v části specifikace zadání jsem si vybral projekt u Podniku A, který jsem nazval Projekt 1. Jeho účelem bylo umožnit zákazníkům, aby byli sami schopni jednoduchým způsobem zjistit cenu jimi požadované služby či produktu z portfolia Podniku A podle zadaných parametrů. Předpokladem byl centralizovaný informační systém pravděpodobně s webovým rozhraním. Ač se jedná o reálný projekt z prostředí Podniku A, přikročil jsem z důvodu zachování obchodního tajemství ke změně celé řady aspektů, detailů a osob a rovněž ke zjednodušení pro účely uvedení v této práci.

6.1.2.8.1

Úvodní analýza

V prvním kroku poté, co Zadavatel identifikoval potenciální příležitost získat výhodu před konkurencí, která tuto možnost svým zákazníkům doposud nenabízí, byla provedena detailní analýza problému. Na té se podílel budoucí předpokládaný sponzor – Programový manažer. Byly popsány a vyčísleny předpokládané přínosy pro společnost a bylo rovněž rozhodnuto o maximální výši investice. Neboť Zadavatel neměl dostatek informací pro rozhodnutí o přístupu k řešení problému, rozhodl se toto konzultovat s Dodavatelem, se svou servisní IT organizací.

6.1.2.8.2


Coby první komunikace směrem k Dodavateli byla tedy odeslána Žádost o informaci. Tento dokument stejně všechny další uvádím záměrně v autentické podobě obchodních dopisů, neboť právě takovouto formou konverzace mezi Zadavatelem a Dodavatelem v Podniku A probíhá.

53

Tabulka 6: Žádost o informaci

Podnik A Pan Jan Novák Národní 1 10100 Praha 1 Žádost o informaci

Vážený pane, v návaznosti na naši e-mailovou komunikaci zasíláme tuto Žádost o informaci pro náš projekt Projekt1. Úvod do problematiky

Naše oddělení uvažuje o zavedení nové služby pro zákazníky společnosti, která by umožnila na základě vstupních parametrů výpočet ceny produktů. Přestože by systém využíval databáze a systémy, které již v dnešní době existují a fungují pro telefonické poptávky a objednávky služeb, rádi bychom potřebné informace zavedli do nové centrální databáze.

Specifikace

Žádáme o posouzení možnosti vývoje a uvedení do provozu nové

požadavku

centrální databáze informací o produktech společnosti (ceny, parametry) s ohledem na Projekt1

Časování odpovědi

Vaši odpověď očekáváme do 10.11.2006

na Žádost o informaci Zodpovědná osoba

Pan Antonín Havel, tel. 123455667, e-mail [email protected]

za zadavatele V Brně dne 15.10.2006

Zdroj: Podnik A, vlastní úprava

Dotaz se týkal vhodnosti zavedení další databáze informací o produktech, jejich cenách a parametrech. Zadavatel měl představu, že databáze by se stala novým centrálním úložištěm pro ostatní systémy ve společnosti.

54

6.1.2.8.3

Informace

Dodavatel na dotaz reaguje strukturovanou odpovědí. Na straně Dodavatele se v tento okamžik již rozbíhá proces analýzy implikací případného projektu. Zpravidla v prostředí jedné společnosti nebude Dodavatel (zastoupen osobou Obchodního manažera) překvapen žádostí, bude ji s největší pravděpodobností po určité předchozí komunikaci se Zadavatelem očekávat a bude mít také již vybránu vhodnou osobu pro provedení technické analýzy a přípravu odpovědi. Tabulka 7: Informace

Podnik A Pan Antonín Havel

Severní 101 621 01 Brno 1 Informace

Vážený pane, děkujeme za Váš zájem o služby IT divize společnosti Podnik A. Níže posíláme požadovanou odpověď na Vaši Žádost o informaci k projektu Projekt1.

Předpoklady

Projekt se týká zavedení nové služby pro zákazníky společnosti, která by umožnila na základě vstupních parametrů výpočet ceny produktů. Systém by využíval databáze a systémy, které již v dnešní době existují a fungují pro telefonické poptávky a objednávky služeb a sám by informace ukládal do své „master“ databáze.

Navrhovaný přístup

Domníváme se, že pro popsaný problém by bylo vhodné použít přístup bez nové centrální databáze. Domníváme se tak z následujících důvodů •

Všechny předpokládané zúčastněné systémy disponují

55

Master databázemi pro svou informační doménu a jsou tedy důvěryhodnými zdroji pro jakýkoli typ požadavku. •

Rychlost odezvy jak bylo konzultováno v dokumentaci zúčastněných systémů a zjištěno z odpovídajících Smluv o úrovni služby (SLA) je dostatečná i pro případnou webovou povahu služby.

Osoba zodpovědná

Jan Novák

za zpracování Informace

V Praze dne 5.11.2006 Zdroj: Podnik A, vlastní úprava

Jádrem odpovědi je doporučení nepoužít další novou databázi, ale spolehnout se na kvalitu a rychlost stávajících systémů pomocí zavedení rychlého standardního rozhraní. Zmínka o Smlouvě o úrovni služby (SLA)35 je klíčová pro tuto problematiku, neboť nová služba bude muset také splňovat určitá kriteria rychlosti odezvy (definovaná opět pomocí SLA) a všechny důležité dodavatelské systémy je musí splňovat rovněž. Nový systém bude na nich závislý.

6.1.2.8.4

Žádost o odhad

V tomto okamžiku, po vyjasnění posledního sporného bodu technické povahy u projektu Projekt 1 přikročil Zadavatel k prvnímu kolu vyjednávání o nákladech a tím je Žádost o odhad. Tabulka 8: Žádost o odhad

Podnik A Pan Jan Novák Národní 1 10100 Praha 1

35 SLA: Service Level Agreement – Smlouva o úrovni služby, garantuje dohodnuté parametry služby.

56

Žádost o odhad Vážený pane, v návaznosti na naši předchozí komunikaci zasíláme tuto Žádost o odhad pro náš projekt Projekt1. Cíl projektu

Vytvořit centralizovaný informační systém umožňující zákazníkům výpočet ceny produktů, pravděpodobě přes webové rozhraní a využívající stávajících systémů

Časování Žádosti o

Váši odpověď očekáváme do 20.11.2006

nabídku Časování projektu

23.3.2007 - Zahájení analýzy a vývoje 31.7.2007 – Uvedení do provozu

Zodpovědná osoba

Pan Anonín Havel, tel. 123455667, e-mail [email protected]

za zadavatele

V Brně dne 10.11.2006


6.1.2.8.5

Nezávazný odhad

Nabídkový manažer shrnul informace, které dostal v Žádosti o nabídku společně s jeho předpoklady k úspěšnému vyřešení úkolu (projektu) a ocenil celkové řešení. Taková odpověď zcela naplňuje požadavky žádosti a je věcí Zadavatele, zda se mu podmínky a celková navrhovaná cena budou zdát odpovídající při jejich porovnání s obchodním přínosem. Tabulka 9: Nezávazný odhad

Podnik A Pan Robert Janek Severní 101 621 01 Brno 1 Nezávazný odhad

57

Projekt: Projekt1 Děkujeme Vám za Vaši Zádost o odhad. Popis Vytvoření centralizovaného informačního systému umožňujícího zákazníkům výpočet ceny produktů společnosti Podnik A Předpoklady, přístup Řešením bude nový informační systém s webovým rozhraním Rozsah projektu Zpracování a předložení systémové analýzy řešení Vývoj řešení Příprava technických a zátežových testů a podpora uživatelského testování Instalace a konfigurace řešení Hosting a post-implementační podpora Mimo rozsah projektu Obchodní analýza řešení Online objednávka služeb na základě spočítané ceny Odhad časového harmonogramu a milníků Hotový projektový plán

20.3.2009

Zahájení analýzy a vývoje

27.3.2007

Schválení uživatelský testů (UAT)

28.6.2007

Uvedení do provozu

20.8.2007

Předpoklady (Assumptions)

58

Informační systémy a databáze plánované pro využití budou mít k dispozici dostupné a dokumentované komunikační rozhraní umožňující připojení formou WebServices s odpovídající rychlostí odezvy. Náklady na projekt Celková cena za fázi implementace (build)

0,9 mil Kč *

Celkový roční náklad na hosting a podporu (run)

50 tis. Kč * ......................................... Nabídkový manažer

V Praze 20.11.2006. *) V souladu s platnými interními předpisy Podniku A je tolerance pro navrhovanou cenu v rozsahu +/- 50% Zdroj: Podnik A, vlastní úprava

Jak bude možné vidět níže, ve struktuře a obsahu dokumentů Kotace a Nezávazný odhad není přiliš velký rozdíl. Hlavní odlišnost tkví v povaze (zejména závaznosti) dokumentů a částečně odlišné úrovni detailu řešení a rozpadu ceny.

6.1.2.8.6

Žádost o kotaci

I v tento okamžik považoval Zadavatel informace dodané Dodavatelem za odpovídající a rozhodl se požádat o závaznou nabídku, o Kotaci. Tabulka 10: Žádost o kotaci


59

Žádost o kotaci Vážený pane, v návaznosti na náš telefonický rozhovor zasíláme tuto Žádost o kotaci pro náš projekt Projekt1.

1 Cíl projektu a. Vytvořit centralizovaný informační systém umožňující zákazníkům výpočet ceny produktů b. Systém bude k dispozici přes webové rozhraní c.

Řešení využije existující databáze a systémy

2 Časování Žádosti o kotaci a. Váš návrh očekáváme do 2.2.2007 b. Osobní setkání k diskusi nad Kotací formou Workshopu navrhujeme v týdnu od 22.1.2007.

3 Časování projektu a. 23.3.2007 - Zahájení analýzy a vývoje b. 22.6.2007 – Schválení uživatelský testů (UAT) c.

31.7.2007 – Uvedení do provozu

4 Požadavky na vývoj a. Bude využito externího dodavatele b. Externí dodavatel poskytne také testovací prostředí a podporu během testování

5 Zodpovědná osoba za zadavatele a. Pan Anonín Havel, tel. 123455667, e-mail [email protected]

6 Prezentace Kotace a. Celková finanční nabídka b. Popis technického řešení a architektury c.

Navrhovaný projektový tým

d. Reference V Brně dne 30.12.2006


60

6.1.2.8.7

Kotace

Dodavatel provedl další detailní analýzu řešení, které hodlá předložit Zadavateli. Hlavní zodpovědnost leži na osobě Manažera nabídky. Tabulka 11: Kotace

Podnik A Pan Robert Janek Severní 101 621 01 Brno 1 Kotace Projekt: Projekt1 Velmi si vážíme Vašeho zájmu o produkty a služby IT divize společnosti Podnik A, na něž níže následuje požadovaná Kotace. Věříme, že jsme plně pochopili Vaše zadání a naše divize udělá maximum pro to, abychom naplnili Vaše očekávání Popis Vytvoření centralizovaného informačního systému umožňujícího zákazníkům výpočet ceny produktů společnosti Podnik A Předpoklady, přístup Řešením bude nový informační systém s webovým rozhraním Databáze nového informačního systému nebude užívána k uchovávání informací o produktech, ale pouze pro konfiguraci inf. systému a pro zajištění konzistence výsledku vůči zákazníkovi V případě nedostupnosti některého z elektronicky poptávaných systémů bude použita informace z vyrovnávací paměti nebude-li starší než 24 hodin.

61

Rozsah projektu Zpracování a předložení systémové analýzy řešení Vývoj řešení Příprava technických a zátežových testů a podpora uživatelského testování Instalace a konfigurace řešení Hosting a post-implementační podpora Mimo rozsah projektu Obchodní analýza řešení Online objednávka služeb na základě spočítané ceny Odhad časového harmonogramu a milníků Hotový projektový plán

20.3.2007

Zahájení analýzy a vývoje

27.3.2007

Schválení uživatelský testů (UAT)

28.6.2007

Uvedení do provozu

20.8.2007

Předpoklady (Assumptions) -

Informační systémy a databáze plánované pro využití budou mít k dispozici dostupné a dokumentované komunikační rozhraní umožňující připojení formou WebServices.

-

Odezva poptávaných informačních systémů bude menší nebo rovna než 0,4 sek.

Akceptační kriteria -

Zobrazení stránky s cenou požadovaného produktu bude do 1 sek. od odeslání.

-

Implementovány budou všechny základní produkty (kategorie A) z portfolia

-

Dostupnost systému bude 99%

Náklady na projekt Analýza systému

120 tis. Kč

62

Vývoj systému

1,5 mil. Kč

Instalace a konfigurace

45 tis. Kč

Roční náklad na hosting a podporu

76 tis. Kč

Obchodní podmínky Kotace je sestavena v souladu s pravidly pro vnitropodnikové financování Podniku A. Podpisy V Praze dne ...... Nabídkový manažer

Obchodní manažer *) V souladu s platnými interními předpisy Podniku A je tolerance pro navrhovanou cenu v rozsahu +/- 10% Zdroj: Podnik A, vlastní úprava

Finální odpověď, Kotace, již obsahuje naprosto všechny dostupné informace o zadání, rekapituluje obsah projektu (scope), všechny předpoklady a rozepisuje také detailněji popis technického řešení a předkládá harmonogram plánovaného projektu. Aby všechny tyto informace mohly být Zadavateli poskytnuty, musí Dodavatel prostřednictvím svého Manažera nabídky (Projektového managera) vyjednat u jednotlivých oddělení dostupnost pracovníků a tyto předběžně na odpovídající období rezervovat (před-alokovat). Akceptační kriteria jsou v tomto případě návrh, jsou stanovena s ohledem na jejich splnitelnost z pohledu Dodavatele. Je na rozhodnutí Zadavatele, zda bude souhlasit se všemi parametry Kotace, nebo zda bude iniciovat další kolo jednání nad Kotací a bude se snažit vyjednat výhodnější podmínky. Po akceptaci Kotace je dalším krokem vyjednání a podepsání Kontraktu.

63

Dodáním Kotace skončila tato část ukázky. V další kapitole popíši možnou alternativní cestu. 6.1.2.9 Alternativní ukázka, alternativní cesta Zadavatel se mohl rozhodnout, že neosloví přímo svou servisní IT organizaci v rámci společnosti, ale že tentokrát se poohlédne po řešení na volném trhu. V takovém případě by komunikace s Dodavatelskou stranou (zde opět IT divize Podniku A jako jednoho z účastníka tendru) probíhala způsobem Žádost o nabídku → Nabídka

6.1.2.9.1

Žádost o nabídku

Zadavatel již má k dispozici dostatečně přesné informace, aby dokázal účastníky tendru oslovit přímo se Žádostí o nabídku. Tabulka 12: Žádost o nabídku


Žádost o nabídku Vážený pane, v návaznosti na náš telefonický rozhovor zasíláme tuto Žádost o nabídku pro účast ve výběrovém řízení na realizaci projektu Projekt1. 7

Cíl projektu a. Vytvořit centralizovaný informační systém umožňující zákazníkům

64

výpočet ceny produktů b. Systém bude k dispozici přes webové rozhraní c. Řešení využije existující databáze a systémy 8

Časování Žádosti o nabídky a. Váš návrh očekáváme do 2.2.2007

9

Časování projektu a. 23.3.2007 - Zahájení analýzy a vývoje b. 22.6.2007 – Schválení uživatelský testů (UAT) c. 31.7.2007 – Uvedení do provozu

10 Požadavky na vývoj a. Součástí dodávky bude také příprava testovacího prostředí a podpora během testování 11 Zodpovědná osoba a kontakt pro podání Nabídky a. Pan Antonín Havel., tel. 123455667, e-mail [email protected] b. Podnik A, Severní 101, Brno 1, 621 01 12 Náležitosti Nabídky a. Celková finanční nabídka b. Podrobný popis technického řešení a architektury c. Navrhovaný projektový tým d. Reference V Brně dne 30.12.2006 Zdroj: Podnik A, vlastní úprava

65

6.1.2.9.2

Nabídka

Přijetí Žádosti o nabídku dává Dodavateli signál, že pravděpodobně není jediným zájemcem o tento projekt. Jeho snaha se tedy soustředí na to, aby co nejvíce zaujal Zadavatele právě se svou Nabídkou, aby tato byla považována za lepší než konkurenční a bude se snažit především vyzdvihnout přednosti navrhovaného řešení. Obrázek 9: Nabídka

Zdroj: Vlastní

Jádrem budou stejné informace, jaké by se objevily v Kotaci (shrnutí zadání, technické řešení, nabídnutá cena). V případě nabídky půjde však do značné míry o „reklamní materiál“, než o pravdivou a precizní informaci, jaké řešení skutečně zvládne Dodavatel implementovat. Budou také nabízeny nejrůznější slevy či bonusová plnění. V konkurenčním boji jde o legitimní způsob vyjednávání. Ve finále bude záležet na šikovnosti zástupců Dodavatele, zda dokáží obhájit své případné nedokonalé navrhované řešení, navýšení původních termínů či zvýšení požadovaného rozpočtu. Při akceptaci Nabídky je dalším krokem vyjednání a podepsání Kontraktu.

66

6.1.2.9.3

Žádost o změnu

Další možnou variantou komunikace, která může vést k zadání zakázky ze strany Zadavatele je Žádost o změnu (Request for Change, RfC). Ta může být iniciována například uživateli, kteří buď odhalili chybu systému a nebo vznesli požadavek na rozšíření funkcionality systému. V každém případě odpadá fáze vyjednávání o tom, kdo bude zakázku provádět (bude to pravděpodobně autor celého systému, popřípadě autor předchozích změn). Stejně tak je zbytečné popisovat detaily systému, které jsou všem zúčastněným stranám dobře známy. Důležité je zmínit, že Žádost o změnu předpokládá odpověď v každém případě. To znamená, že pokud není technická překážka na straně Dodavatele, který by plnění této Žádosti skutečně znemožňovala, mělo by odpovědí být ocenení změny a nikoli odmítnutí provést změnu. Zadavatel totiž zpravidla nemá alternativní cestu na provedení změny jiným způsobem. Povinnost provádět opravy chyb a další vývoj na systému bývá zpravidla zakotven již v odpovídajícím Kontraktu. Tabulka 13: Žádost o změnu Podnik A Pan Jan Novák Národní 1 10100 Praha 1

Žádost o změnu Název systému

Systém 1

Základní popis

Lokalizace systému do Německého jazyka

Detailní popis

Žádáme o provedení kompletní lokalizace Systému 1 do německého jazyka. Lokalizace se bude týkat všech uživatelských rozhraní, chybových hlášek a varování a dokumentace.

Sdělte nám prosím náklady a časový harmonogram požadované změny.

67

V Brně dne 30.12.2006 Robert Janek tel. 123455667 e-mail [email protected] Zdroj: Podnik A, vlastní úprava

6.1.2.9.4

Nabídka změny

Nabídka změny, odpověď na Žádost o změnu, shrnuje informace ze zadání (včetně vyjmenování toho, co není předmětem změny), kvantifikuje náročnost změn, oceňuje časovou náročnost a nabízí konkrétní cenu za provedení změny. Tabulka 14: Nabídka změny

Podnik A Pan Robert Janek Severní 101 621 01 Brno 1 Nabídka změny Děkujeme Vám za Vaší Žádosti o změnu a v souladu se zadáním Vám posíláme tuto Nabídku změny Název systému

Systém 1

Základní popis zadání Lokalizace systému do Německého jazyka Detailní popis

Provedení kompletní lokalizace Systému 1 do německého jazyka. Lokalizace se bude týkat všech uživatelských rozhraní, chybových hlášek a varování a dokumentace.

Rozsah projektu

Překlad a lokalizace uživatelských obrazovek Překlad chybových hlášek a varování v databázi

68

Překlad uživatelské dokumentace Vytištění dokumentace v běžném počtu 100 kopií plus elektronická verze v PDF Mimo rozsah

Lokalizace administračních rozhraní

projektu

Lokalizace instalačního programu a dokumentace Lokalizace administrační dokumentace Lokalizace systémových chybových hlášek do logů (nevidí uživatel)

Cenová nabídka

13 obrazovek

15 MD36

Překlad chybových hlášek a varování

3 MD

Překlad, příprava a zlom uživatelské

7 MD

dokumentace Příprava a provedení funkčních testů

8 MD

Celkem 33 MD Celková cena: 138 000,- Kč

Časový

13 obrazovek

16 dní

harmonogram

Překlad chybových hlášek a varování

5 dní

Překlad, příprava a zlom uživatelské

10

dokumentace Příprava a provedení funkčních testů

5 dní

Celková doba trvání: 21 dní ................................... Nabídkový manažer Zdroj: Podnik A, vlastní úprava

36

MD: zkratka od Man Day, v Češtině někdy překládáno jako „člověkoden“. Představuje zjednodušenou účetní jednotku definovanou v dohodnutém ceníku. 69

V případě, že Zadavatel souhlasí s Nabídkou změny, je tato formálně podepsána, stává se součástí předchozího Kontraktu a řídí se podmínkami v něm obsaženými (například stanovená cena za 1 MD). 6.1.2.10 Kontrakt na projekt Posledním krokem v procesu definice a zadání projektu v Podniku A je vyjednání a podepsání Kontraktu na projekt. Jde o poměrně rozsáhlý dokument - v případě podniku A má jen prázdná šablona 24 stránek. Účelem je formalizovat a zachytit všechny do budoucna potenciálně sporné body do jednoho dokumentu a jeho podepsání zúčastněnými stranami. Kromě toho obsahuje Kontrakt také zjednodušený právní rámec (včetně například volby národního práva), kterým se uvádí zadání do širšího kontextu. Jediný případ, kdy je vznik dalšího Kontraktu zbytečný, je popsán v předchozí kapitole - Žádost o změnu. V takovém případě již nejspíše Kontrakt existuje. Tabulka 15: Kontrakt na projekt

Kontrakt na provedení projektu Tento Kontrakt se uzavírá mezi Podnik A – obchodní jednotka Se sídlem Severní 101 621 01 Brno 1 zastoupená panem Robertem Jankem jako Zadavatelem na straně jedné a Podnik A – divize IT Se sídlem Národní 1 11100 Praha 1

zastoupená panem Janem Novákem

70

jako Dodavatel na straně druhé Definice pojmů ... Důvěrnost informací ... Eskalační procedura ... Volba právního rámce ... Popis úkolu / projektu: Vytvoření centralizovaného informačního systému umožňujícího zákazníkům výpočet ceny produktů společnosti Podnik A Detailní zadání: Řešením bude nový informační systém s webovým rozhraním Databáze nového informačního systému nebude užívána k uchovávání informací o produktech, ale pouze pro konfiguraci inf. systému a pro zajištění konzistence výsledku vůči zákazníkovi V případě nedostupnosti některého z elektronicky poptávaných návazných systémů bude použita informace z vyrovnávací paměti nebude-li starší než 24 hodin. Požadované datum dokončení: 20.8.2007 Předpokládaná doba trvání projektu: 71

6 měsíců Projektový manažer: František Čech Místo výkonu práce na úkolu / projektu Praha Kriteria pro akceptační testování: Ověření dodání všech požadovaných funkcí Výkon schopný obsloužit 10 000 uživatelů denně Dostupnost systému podepsaná formou SLA jako 99% Obchodní manažer za Dodavatele: Petr Dvořák Plán implementace Zpracování a předložení systémové analýzy řešení Vývoj řešení Příprava technických a zátežových testů a podpora uživatelského testování Instalace a konfigurace řešení Hosting a post-implementační podpora Způsob a podminky platby: K platbě dojde po dokončení projektu a jeho schválení, elektronickou formou na základě vystavené faktury Podpisy V............ dne.............

72

................................

................................

Robert Janek

Jan Novák

za Zadavatele

za dodavatele


73

6.1.3 Podnik B Také v Podniku B je proces definice zadání projektu podle PRINCE2 modifikován a původní dokument Projektového mandátu byl coby nedostačující nahrazen detailně navrhnutým procesem specifikace a schválení projektového zadání. Jeho základem je postupný vývoj a potvrzování stále detailnější projektové specifikace: Ideový návrh → Ideový dokument → Charta úvodní studie → Úvodní studie Obrázek 10: Mapa zadávacího procesu v Podniku B

Zadavatel

Dodavatel

Příležitost

Identifikace příležitosti Ideový návrh Příprava Ideového návrhu

Příprava Ideového dokumentu

Ideový dokument Schválení Ideového dokumentu

Příprava Charty úvodní studie

Charta úv. studie Schválení Charty úvodní studie

Příprava Úvodní studie

Úvodní studie Schválení Úvodní studie

Zdroj: Vlastní

74

6.1.3.1 Popis zadávacího procesu Typickým aspektem modifikace zadávací fáze v Podnku B je mnohaúrovňové a velmi formální schvalování všech postupně navrhovaných a upřesňovaných dokumentů. V prostředí podniku z finanční sféry je to však pochopitelná vlastnost. K Podniku B se mi nepodařilo získat natolik rozsáhlé podklady, abych zadávací proces mohl prezentovat i pomocí ukázek důležitých dokumentů. Omezím se tedy na shrnutí klíčových okamžiků fáze zadání a popis odpovídajících artefaktů (dokumentů).

6.1.3.1.1

Ideový návrh

Poté, co byla na straně Zadavatele identifikována příležitost a bylo rozhodnuto, která funkční doména37 na straně Zadavatele bude mít případ na starost, je tato zdokumentována do podoby tak zvaného Ideového návrhu (Idea Proposal). Obsahuje především zdůvodnění pro projekt (Obchodní případ – Business Case) a ústřední myšlenku, cíl, kterého je třeba dosáhnout. Ideový návrh je poté předán Dodavateli.

6.1.3.1.2

Ideový dokument

Dodavatel na základě Ideového návrhu potvrdí, že je schopen pokračovat v řešení směrem k detailnějšímu zadání a dojde rovněž v výběru vhodného Manažera přípravné fáze. Ten je od tohoto okamžiku až po Zahájení projektu zodpovědný za všechny činnosti spojené s přípravou. Ideový dokument (Idea Document) obsahuje zejména identifikovanou doménu, v jejíž působnosti řešená problematika leží a jsou jmenováni základní členové projektového týmu přípravné fáze za obě strany (Manažer přípravné fáze za Dodavatele, Obchodní architekt za Zadavatele). V případě, že autor Ideového dokumentu identifikuje problém, který ohrožuje dosažení cíle projektu, nebo je v rozporu s jiným projektem, je tato informace do Ideového dokumentu zakomponována a může být důvodem pro předčasné ukončení přípravné fáze. Ideový dokument je předán ke schválení Zadavateli.

37

Funkční doména: část zadavatelské organizace zabývající se určitými produkty, službami, cílovou skupinou zákazníků atp. 75

6.1.3.1.3

Charta úvodní studie

Pokud Zadavatel schválil Ideový dokument, je Manažerem přípravné fáze sestavena tzv. Charta úvodní studie (Pre-Study Charter). Jejím účelem je pevně stanovit projektový tým, tentokrát již i pro celou fázi implementace projektu a potvrdit obsah projektu (tzv. fix scope). Rovněž ocenit náklady a délku trvání celé přípravné fáze, tedy především náklady na přípravu Úvodní studie, zejména pokud bude prováděna externě. Charta obsahuje i zjednodušený popis přístupu k projektu v takové úrovni detailu, který je v tento okamžik již bezpečně znám. Před poskytnutím Charty úvodní studie Zadavateli je dokument nejdříve schválen interním Řídícim výborem (Steering Commitee)38 na straně Dodavatele. Účelem je odhalení případných nesrovnatelostí, kterých si autor nemusel všimnout a především nalezení potenciálních překryvů a vlivů na ostatní chystané či běžící projekty. I v Chartě úvodní studie mohou být identifikovány problémy vedoucí k zastavení projektu ještě v přípravné fázi. Tím můž být i odhalený problém s realizací Úvodní studie. Poté je Charta úvodní studie postoupena Zadavateli.

6.1.3.1.4

Úvodní studie

Úvodní studie (Pre-Study Report) je základní průvodní dokument celé přípravné fáze. Shrnuje všechny doposud známé informace, které zdědil z Charty úvodní studie. Obsahuje ale především možné varianty řešení včetně varianty nulové. Řešení je v dokumentu rozpracováno do takové úrovně technického detailu, který umožňuje zodpovědné rozhodnutí o nejvhodnější volbě. Konzultováni jsou Obchodní architekti pro danou doménu a rovněž všichni specialisté, kteří se budou podílet na vývoji. U každé varianty jsou popsány náklady na její realizaci a také zhodnocena rizika spojená s konkrétními variantami. Například výše možné finanční pokuty od regulačního orgánu a riziko právního postihu v případě neimplementace nové legislativní úpravy K přípravě Úvodní studie je také přizván Projektový manažer implementační fáze, aby bylo zajištěno, že bude mít všechny potřebné informace k dispozici v požadované kvalitě v okamžiku předání. Také Úvodní studie je před předáním Zadavateli projednána a schválena

38

Řídící výbor: poradní a schvalovací orgán sestávající z několika úrovní vedení dodavatelské organizace. 76

interním Řídícím výborem. Jsou-li ve fázi přípravy Úvodní studie přípravné nalezeny problémy ohrožující realizaci projektu, jsou tyto informace předány Zadavateli. Okamžikem

přijetí

a

schválení

Úvodní

studie

Zadavatelem

je

možné

přikročit

k implementační fázi projektu. Manažer přípravné fáze oficiálně předává podklady a vedení projektového týmu Projektovému manažerovi implementační fáze a dále na projektu působí jako konzultant.

77

6.1.4 Závěr k modifikaci zadávacího procesu PRINCE2 Ve fázi zadávání projektu podle standardu PRINCE2 existují slabá místa. Patří mezi ně především direktivní zadání formou jediného formalizovaného nebo i neformalizovaného dokumentu. V takovém případě není zaručeno, že příjemce takového zadání (Dodavavel) jej bezchybně pochopil, bude se jím řídit a především dodá odpovídající výsledný produkt. Z praktických příkladů a ukázek z Podniku A a Podniku B je vidět, že nahrazení tohoto jednostranného aktu vyspělým zadávacím procesem konverzačního a nejlépe iteračního typu přináší značné výhody pro obě zúčastněné strany. Domnívám se, že postupným upřesňováním zadání od hrubého návrhu až po detailní specifikaci, od přibližného odhadu po podrobnou cenovou kalkulaci, umožní odhalit a napravit případné chyby již v ranné fázi vývoje. Takto se vyvarujeme situace, aby identifikace nepřesnosti těsně před faktickým začátkem startovní fáze projektu ohrozila naplánovaný harmonogram. Navíc zejména u komplexních projektů dojde uzavřením Kontraktu na projekt k velmi přesvědčivému potvrzení všech dohodnutých parametrů zadání.

78

6.2 Důležitá projektová rozhodnutí Projektovým rozhodnutím označujeme takový okamžik v životním cyklu projektu, ve kterém není možné pokračovat dále dříve, než dojde nadřízenou instancí k rozhodnutí o schválení či neschválení určitého předloženého návrhu, plánu či dokumentu.

6.2.1 Projektová rozhodnutí podle PRINCE2 PRINCE2 zavádí celkem čtyři klíčová projektová rozhodnutí, která jsou v zodpovědnosti Projektové rady: •

Schválení Nastavení projektu (Authorising Initiation)

•

Schválení projektu (Authorising Project)

•

Schválení plánu další etapy (Authorising a Stage Plan/ Authorising an Exception Plan)

•

Potvrzení o uzavření projektu (Confirming Project Closure)

Okamžikem Schválení Nastavení projektu je úspěšně dokončená fáze Zahájení projektu a je k dispozici potvrzená Charta projektu (Project Brief). Od této chvíle dochází k faktickému naplánování a výkonu samotného projektu. Další fází bude Nastavení projektu Ke Schválení projektu dojde ve chvíli, kdy je v předchozí fázi Nastavení projektu naplánován v hrubých rysech celý projekt, jsou známa a zachycena kvalitativní kriteria výsledného produktu (produktů) a je revidován Obchodní případ (Business Case). V předchozí fázi také vznikl hlavní operační dokument pro výkon projektu – Dokument o nastavení projektu. Schválení projektu je fakticky schválení Dokumentu o nastavení projektu. V průběhu projektu jsou Radou projektu autorizovány jednotlivé etapy (jejich plány, Stage Plans) prostřednictvím Schválení plánu etapy. Další variantou tohoto rozhodnutí je schvalování Výjimečného plánu (Exception Plan) v případě, že přístí etapa bude evidentně překračovat svá kriteria stanovená v celkovém plánu. V takovém případě Výjimečný plán nahrazuje Plán etapy.

79

Potvrzením o uzavření projektu Projektová rada stvrzuje, zda došlo k naplnění cílů projektu a především schvaluje Závěrečnou zprávu projektu (End Project Report). Ve zprávě jsou mimo jiné zhodnoceny problémy, které nastaly a jejich řešení a zrevidovány kvalitativní kontroly na produktech.

6.2.2 Modifikace a zhodnocení projektových rozhodnutí V této kapitole provedu zhodnocení aplikace projektových rozhodnutí dle PRINCE2 v Podniku A a Podniku B a popíši a zhodnotím další rozhodovací body, které se jsou v těchto podnicích navíc implementovány. Tabulka 16: Srovnání implementace projektových rozhodnutí

PRINCE2

Podnik A

Podnik B ¨

Schválení pokračovat k Zahájení projektu



(Authorisation to Proceed, Starting Up a Project)

Vyžadováno vždy

Odlehčený proces

Schválení pokračovat k



Nastavení projektu

Nastavení projektu

Zahájení projektu

(Authorisation to Proceed,

(Authorisation to Proceed,

Initiating a Project)

Initiating a Project)

80

Vyžadováno vždy

Odlehčený proces

Neimplementuje

Neimplementuje

Schválení

Schválení

testů

testů

Pilotní / ověřovací

Pilotní

provoz

Provoz

Potvrzení uzavření



projektu

projektu

projektu

Důsledná revize problémů Zdroj: Vlastní

6.2.2.1 Schválení nastavení projektu U Podniku A je tento proces odlehčen. Za důležitější než formální schválení je považována existence platného a podepsaného Kontraktu na projekt. Je-li projekt pouhou změnou, pak existence rámcového Kontraktu, který podmínky změn pokrývá. U projektů nad určitou hranici (danou částkou za rozpočet na celý projekt) je Schválení nastavení projektu od Projektové rady vyžadováno vždy. Výsledkem je posílení autority Projektového manažera, který musí sám rozhodnout, zda může nebo nemůže zahájit fázi Nastavení projektu.

81

V případě Podniku B je vždy vyžadováno, aby Projektový manažer vznesl k Radě projektu žádost o Schválení nastavení projektu. Podnik B nezavádí formalizovaný kontrakt. 6.2.2.2 Schválení projektu Toto projektové rozhodnutí je v Podniku A implementováno v odlehčené podobě obdobně jako Schválení nastavení projektu. U rozsáhlých projektů musí Projektový manažer požádat Radu projektu o schválení projektu a tím i první etapy projektu v souladu s projektovým plánem. U menších projektů jej nahrazuje existence podepsaného Kontraktu nebo rámcového Kontraktu. U Podniku B se toto rozhodnutí vyžaduje vždy. 6.2.2.3 Schválení plánu další etapy V Podniku A jsou procesy Kontrola etapy, Řízení dodávky produktu a Řízení hranic etapy sdruženy do jednoho procesu Vedení projektu (Manage Project). Z toho vyplývá, že projektové tozhodnutí se týká celého sdruženého procesu a nikoli jen procesu Kontrola etapy. Všechny ostatní atributy tohoto projektového rozhodnutí jsou u Podniku A obdobné jako u standardního procesu dle PRINCE2. V Podniku B schvalování každé další etapy projektu neprovádí jen Projektová rada, ale nejdříve Řídící výbor (Steering Committee) na straně Dodavatele. Kromě tohoto specifika je výkon rozhodnutí obdobný jako u PRINCE2. 6.2.2.4 Schválení Uzavření projektu Implementace tohoto rozhodnutí v Podniku A je obdobná jako u standardní metody PRINCE2. Hlavní odklon spočívá v důsledném revidování a dokumentování problémů vzniklých na projektu z pohledu jeho řízení a z pohledu aplikace odpovídající metodiky a standardů. Jako zdroj pro tuto revizi je použita Zpráva o získaných poznatcích (Lessons Learned Report). V okamžiku, kdy se podaří identifikovat problém, který ještě není zachycen v interním informačním systému získaných požadavků, je tento problém ve spolupráci s některým se senior projektovým manažerem dokumentován a jsou k němu navrhnuty způsoby řešení. Projektoví manažeři Podniku A jsou motivováni k pravidelnému čtení nových poznatků v Systému pro jejich předcházení.

82

Rovněž je systém používán oddělením Správy procesů jako vstup pro revize případných nevhodně navrhnutých procesů. U Podniku B jde o standardní implementaci procesu. 6.2.2.5 Schválení uživatelských testů Uživatelskými testy je ověřováno, zda výsledný produkt (produkty) splňuje na něj kladená kvalitativní měřítka z pohledu Zadavatele (uživatele). U PRINCE2 nejde o klasické hlavní projektové rozhodnutí. PRINCE2 se ověřením kvality zabývá prostřednictvím:

•

Stanovení a zdokumentování Kvalitativních očekávaní zákazníka (Customer Quality Expectations)

•

Během Nastavení projektu v podprocesu Plánování kvality (Planning Quality) během kterého je připraven Projektový plán kvality (Project Quality Plan) - ten se stává součástí Dokumentu o nastavení projektu - a je založen Deník kvality (Quality Log).

•

a především Technikou revize kvality (Quality Review Technique).

Okamžikem kontroly je předávání zadané práce zpět jako dokončené – Doručení zadané práce (Delivering a Work Package). Problémy jsou podle mého názoru následující: •

Absence celkové kvalitativní kontroly integrovaného výsledného produktu

•

Nízká formální váha tohoto schválení

Výsledný produkt je zpravidla tvořen více různými podprodukty a tedy více Zadáními práce (Work Packages), které je mají za úkol dodat. Autoritou, která v souladu se správně sestaveným Plánem kvality projektu provádí kontrolu je Zajištění projektu. Ta je delegována Projektovou radou, nebo může být některým členem Projektové rady i přímo vykonávána. Ovšem rozhodnutí o případném nesplnění kvalitativních kriterií nemá jasně stanovenou

83

přímou implikaci na další pokračování projektu. Výsledkem je pouze Hlášení o výjimce (Exception Report) a Výjimečného plánu (Exception Plan). Toto projektové rozhodnutí by podle mého názoru mělo předcházet začátku etapy implemetace a mělo by mít stejnou váhu jako další klíčová projektová rozhodnutí – mělo by se jednat o další povinné a zásadní projektové rozhodnutí v přímé pravomoci Projektové rady.

6.2.2.5.1

Podnik A

V Podniku A je ověření kvality produktů, tedy schválení uživatelských testů vždy řešeno jako jedna z předem naplánovaných etap projektu. Obrázek 11: Etapa 4 - testování

Etapa 1

Etapa 2

Etapa 3

Etapa 4 testování

Etapa 5 implementace

Etapa 6 pilot

Zdroj: Vlastní

Během této etapy jsou ověřeny všechny testovací scénáře pro ověření funkcionality, jsou provedeny zátěžové testy a především je produkt (zpravidla počítačový systém) předán k testování zákazníkovi. Výsledkem testovací etapy je vystavení formálního Certifikátu o akceptaci testů (Test Acceptance Certificate). Teprve poté následuje etapa implementace. Není-li Certifikát vystaven, jsou testy opakovány. Pokud ani po opakovaných testech nedojde ke splnění kriterií v některé z důležitých oblastí, je na Projektové radě, aby rozhodla, jakým způsobem má Projektový manažer postupovat dále: může doporučit ukončení projektu jako neúspěšného nebo může navrhnout vyčlenění neschváleného produktu z projektu. V každém případě musí Projektová rada svá rozhodnutí v takto důležité otázce konzultovat s vedením programu respektive organizace. Jednou z variant pro řešení negativního scénáře (neschválené testy) je v Podniku A „přepnutí“ projektu do tak zvaného Krizového módu. V takovém případě dojde k okamžité modifikaci obsazení Rady projektu - klíčové členy nahradí seniorní management Podniku A a významně se zvýší také četnost a detailnost Hlášení od Projektového manažera směrem k Projektové radě. A to včetně ústního podávání informací o stavu projektu na pravidelných schůzkách. 84

Teprve ve chvíli, kdy se projekt podaří dostat pod kontrolu, je vrácen zpět do standardního módu.

6.2.2.5.2

Podnik B

V Podniku B je proces ověřování výsledných produktů organizačně podobný jako v Podniku A. Je však velmi pečlivý a časově náročný. Jeho specifičnost tkví také v úplném předání řízení projektu Projektovému manažerovi Zadavatele, jakmile jsou připraveny uživatelské testy. Ten poté za podpory od Dodavatele vede všechny kroky uživatelského testování a zajišťuje vystavení potvrzení o úspěšném otestování. Poté předává řizení zpět Dodavateli a projekt pokračuje implementační fází. I zde má potvrzení o úspěšném testování váhu zásadního dokumentu. 6.2.2.6 Schválení ověřovacího (pilotního) provozu U některých projektů nebo produktů je obtížné ověřit jejich skutečný obchodní přínos před nebo při ukončování projektu. V PRINCE2 je tato problematika řešena jako návrh, aby součástí Po-projektových doporučení (Follow-On Recommendations) byl i plán na provedení případného ověření po určité době provozu. Podle mého názoru je opět hlavním problémem nízká faktická váha takového ověření. V takovém případě je výhodné přistoupit k ověření v pilotním provozu (také nazýván „pilot“) nebo v testovacím provozu. Pilotní provoz zpravidla ověřuje i další atributy řešení než čistý obchodní přínos pro společnost. Může jít o ověření praktické provozovatelnosti počítačového systému po jeho dodání do první cílové země z více plánovaných zemí. Pokud je pilotní provoz naplánován, jde zpravidla o poslední etapu projektu, tedy ještě před jeho skončením. Obrázek 12: Etapa 6 - pilot

Etapa 1

Etapa 2

Etapa 3

Etapa 4 testování

Zdroj: Vlastní

85


Etapa 6 pilot

Naproti tomu pokud je rozhodnuto o ověřovacím provozu, ten probíhá až po formálním zakončení projektu. Problémem tedy je administrativní ošetření takového schválení (ověření).

Obrázek 13: Etapa ověření

Etapa 1

Etapa 2

Etapa 3

Etapa 4 testování


Ověření

Zdroj: Vlastní

6.2.2.6.1

Podnik A

V Podniku A se pro ověření přínosu projektu uživají obě metody (pilotní provoz i ověřovací provoz). K rozhodnutí o použití někeré z nich dochází na základě posouzení povahy výsledného produktu a projektu. Pro ověření pilotního provozu u systému, který se bude například zavádět ve více zemích je vybrána vhodná země. Zejména menší nepříliš strategický trh, se zkušenými partnery na straně uživatele, kteří budou schopni formulovat potenciální problémy. Organizačně náročnější, ale pro obchodní aktivity bezpečnější je souběžné používání původního i nového systému. Po skončení doby vyměřené na pilotní provoz (zpravidla v řádech měsíců) je provedena analýza problémů, které se během pilotu objevily. Poté je vystaveno potvrzení o úspěšném pilotním provozu a dochází k distribuci aplikace i do dalších zemí. Schválení pilotního provozu je v přímé pravomoci Projektové rady s významným poradním hlasem Senior uživatele. Schůzka, na které jsou problémy diskutovány a dochází zde ke schválení, se nazývá PostMortem Review39. Po dokončení dodávky produktu do poslední z plánovaných zemí je projekt uzavřen. Součástí Závěrečné zprávy projektu (End Project Report) je i informace o problémech a úspěších spojených s pilotním provozem. Druhou variantou je ověřovací provoz. V takovém případě hlavní část projektu skončí dokončením etapy implementace, dojde k rozpuštění většiny projektového týmu, významnému 39

Post-Mortem Review: doslova „posmrtná revize“. 86

snížení úvazku zbývajících členů projektu včetně členů projektové rady a projektového manažera a projekt je „zmrazen“. Po dobu stanovené doby ověřovacího provozu nejsou na projektu prováděny žádné aktivity. Teprve po skončení naplánované doby je projekt znovu „oživen“. Jsou analyzovány výsledky ověřovacího provozu a získané informace se stávají jedním z klíčových vstupů do Závěrečné zprávy projektu (End Project Report).

6.2.2.6.2

Podnik B

V Podniku B je pilotní provoz využíván především jako prodloužené testování. K formálnímu ověřování skutečných přínosů dochází mimo rámec projektového řízení a výhradně na straně Zadavatele bez přispění strany Dodavatele.

87

Závěry a doporučení Ve své práci jsem došel k následujícím závěrům, jež poskytují odpovědi na klíčové body jejího zadání:

•

Metodiku PRINCE2 je vhodné použít i na projektech v podniku v České republice. Techniky

a

postupy,

které

metoda

zavádí

významně

pomáhají

organizacím

v systematickém (například plánování po etapách, jasné stanovení rolí) a důsledném (například kontrola kvality, řízení rizik) řízení jak méně rozsáhlých tak více rozsáhlých projektů. Důraz na kvalitní a aktualizované obchodní zdůvodnění (Business Case) přináší do řízení podniku další kontrolní prvek k efektivnímu nakládání se zdroji.

•

Metodika PRINCE2 je flexibilní a umožňje implementaci jak u nadnárodní společnosti, tak i u malé či střední lokální firmy. Právě propracovanost, šířka a rozsah procesů, komponent a technik PRINCE2 umožňuje při implementaci výběr vhodné kombinace procesů a komponent podle konkrétních potřeb firmy.

•

PRINCE2 je možné významně zjednodušit a použít i pro malé projekty bez toho, aby se z řízení projektu vytratily klíčové myšlenky metody. Škálování je možné provádět po různých vrstvách (organizace projektového týmu, řízení rizik, detailnost plánování) a rozhodnout o jejich škálování odděleně.

•

U velmi malého projektu považuji za výhodné postavit projekt kolem částečně revidovaného dokumentu Zadání práce (Work Package). Ani v této velmi odlehčené formě se nepřipravíme o žádné základní informace (zdůvodnění pro projekt, struktura projektového týmu, popis produktu, nastavení kvalitativních kriterií). Standardnost vstupu pro projekt nám opět umožňuje v odlehčené míře aplikovat techniky z metody (řízení kvality, plánování a další).

•

Podařilo se mi na konkrétních příkladech ukázat, že některé dokumenty a procesy fáze zadání projektu (zejména Projektový mandát jako vstup pro Zahájení projektu) neplní 88

dostatečně dobře svoji zamýšlenou funkci. Na praktických příkladech jsem ukázal možnost rozšíření a zkvalitnění klíčových procesů a dokumentů ve fázi definice a zadání projektu. Navrhuji, aby Projektový mandát byl nahrazen zadávacím procesem konverzačního (formalizovaná komunikace mezi stranami) a iterativního (upřesňování ve více krocích) typu.

•

Body projektových rozhodnutí (decission points) v metodě PRINCE2 nepokrývají některé zásadní okamžiky v životě projektu. Navrhuji rozšíření rozhodovacích bodů při aplikaci metody např. o schválení uživatelských testů a o schválení a ověření pilotního respektive ověřovacího provozu.

89

Seznam použité literatury [1] Office of Government Commerce. Managing Successful Projects with PRINCE2. 2008. ISBN 978 0 11 330946 7. [2] Project Management Institute. A Guide to the Project Management Body of Knowledge. 2007. ISBN 9781930699458. [3] Bentley, Colin. Managing Small Projects with PRINCE2. 2005. ISBN 978-0-9546635-3-0. [4] Caulkin, C; Davies G. PRINCE2 Process Model. 2007. ISBN 0-9544884-1-5. [5] Geddes & Grosset Ltd. Webster’s Universal Dictionary and Thesaurus. 1993. ISBN 289429-176-0. [6] Leinweber, Václav. Finanční a marketingové řízení v krizi. Praha : EuroAnalysis, 2009. Druhá část, Řeč businessu, s. 1-163. [7] Best Management Practice [online]. Best Management Practice – For Portfolio, Programme, Project, Risk and Service Management [cit. 2009-06-25]. Dostupný z WWW: < www.best-management-practice.com>. [8] Boucher, Collis; . PRINCE2 2005 Glossary of Terms – Czech. [online]. [cit. 2009-06-25]. Dostupný z WWW: . [9] Online Etymology Dictionary [online]. Online Etymology Dictionary [cit. 2009-06-25]. Dostupný z WWW: . [10] Wikipedia [online]. Wikipedia – The free encyclopedia [cit. 2009-06-25]. Dostupný z WWW: . 90

[11] Mira Vlach [online]. Mira Vlach – Projektové řízení, informatika a marketing [cit. 200906-25]. Dostupný z WWW: .

91

Seznam obrázků a tabulek Obrázky OBRÁZEK 1: ZÁKLADNÍ SCHÉMA PMBOK.............................................................................................................. 18 OBRÁZEK 2: PŘEHLED ZNALOSTNÍCH OBLASTÍ PMBOK......................................................................................... 19 OBRÁZEK 3: ORGANIZAČNÍ STRUKTURA PROJEKTOVÉHO TÝMU ............................................................................. 24 OBRÁZEK 4: ZÁKLADNÍ PROCESY METODY PRINCE2 ............................................................................................ 26 OBRÁZEK 5: MINIMALIZOVANÁ ORGANIZACE PROJEKTU PODLE PRINCE2 ............................................................ 33 OBRÁZEK 6: ZADÁVACÍ PROCES V PODNIKU A ....................................................................................................... 46 OBRÁZEK 7: ORGANIZAČNÍ STRUKTURA A VAZBY NA PROJEKTU V PODNIKU A...................................................... 49 OBRÁZEK 8: ZADÁVACÍ PROCES V PODNIKU A - POUZE KOTACE ............................................................................ 52 OBRÁZEK 9: NABÍDKA ............................................................................................................................................ 66 OBRÁZEK 10: MAPA ZADÁVACÍHO PROCESU V PODNIKU B..................................................................................... 74 OBRÁZEK 11: ETAPA 4 - TESTOVÁNÍ ....................................................................................................................... 84 OBRÁZEK 12: ETAPA 6 - PILOT ................................................................................................................................ 85 OBRÁZEK 13: ETAPA OVĚŘENÍ ................................................................................................................................ 86

Tabulky TABULKA 1: ZADÁNÍ ÚKOLU ................................................................................................................................... 36 TABULKA 2: SUBJEKTY V Č.R. POUŽÍVAJÍCÍ PRINCE2........................................................................................... 40 TABULKA 3: SUBJEKTY POUŽÍVAJÍCÍ PRINCE2 MIMO Č.R. .................................................................................... 40 TABULKA 4: SROVNÁNÍ ZADÁVACÍHO PROCESU...................................................................................................... 42 TABULKA 5: OBECNÝ PROJEKTOVÝ MANDÁT ......................................................................................................... 44 TABULKA 6: ŽÁDOST O INFORMACI ......................................................................................................................... 54 TABULKA 7: INFORMACE ........................................................................................................................................ 55 TABULKA 8: ŽÁDOST O ODHAD ............................................................................................................................... 56 TABULKA 9: NEZÁVAZNÝ ODHAD ........................................................................................................................... 57 TABULKA 10: ŽÁDOST O KOTACI............................................................................................................................. 59 TABULKA 11: KOTACE ............................................................................................................................................ 61 TABULKA 12: ŽÁDOST O NABÍDKU .......................................................................................................................... 64 TABULKA 13: ŽÁDOST O ZMĚNU ............................................................................................................................. 67 TABULKA 14: NABÍDKA ZMĚNY .............................................................................................................................. 68 TABULKA 15: KONTRAKT NA PROJEKT.................................................................................................................... 70 TABULKA 16: SROVNÁNÍ IMPLEMENTACE PROJEKTOVÝCH ROZHODNUTÍ ................................................................ 80

92

Využití metodiky PRINCE2 pro řízení projektů v podniku v Č.R

Recommend Documents