Projektový management pro inženýrství. Charles Lessard, Joseph Lessard

Transkript

1 Projektový management pro inženýrství Charles Lessard, Joseph Lessard 1

2 Překlad: Pro předmět IRP Řízení projektů informačních systémů na Fakultě informatiky VUT v Brně přeložil z anglického originálu: tým MOC LaM (Martin, Ondra, Cyril, Lenka a Martina) Fialová Lenka xfialo01@stud.fit.vutbr.cz kapitoly: 3, 4, 8 Procházková Martina xproch69@stud.fit.vutbr.cz 6, 7, 11, 13 Soukup Ondřej xsouku09@stud.fit.vutbr.cz 1, 5, 15, biografie, abstrakt Valenta Martin xvalen12@stud.fit.vutbr.cz 12, 14, 16 Vojáček Cyril xvojac00@stud.fit.vutbr.cz 2, 9, Údaje o originální knize: Copyright 2007 by Morgan & Claypool Project Management for Engineering Design Charles Lessard (Texas A&M University) and Joseph Lessard (Globeleq Inc.) ISBN-10: paperback ISBN-13: paperback ISBN-10: ebook ISBN-13: ebook DOI /S00075ED1V01Y200612ENG002 A Publication in the Morgan & Claypool Publishers Series SYNTHESIS LECTURES ON ENGINEERING #2 Lecture #2 Series ISSN: X print Series ISSN: electronic First Edition 2

3 Abstrakt Tato učebnice je úvodem do řízení projektů. Bude sloužit studentům technických oborů při konstrukčním návrhu ve všech technických disciplínách, rovněž může být ale cenným pomocníkem již pracujících inženýrů. Málo studijních programů dá studentům průpravu v metodách konstrukčního návrhu a konfiguračního řízení používaných v praxi v průmyslu či vládě. Tato kniha v celém svém rozsahu zdůrazňuje týmy, stejně jako pokrývá úvod do projektového řízení, definice projektů, zkoumání duševního vlastnictví (patentový výzkum), rozsah projektu, idealizaci a konceptualizaci návrhu, převod požadavků na produkt do podoby technické specifikace, integraci projektu, řízení komunikace v rámci projektu a vedení revizí návrhu. Hlavním posláním knihy je, aby čtenáři svým projektům porozuměli a dokázali je řídit se zapojením dobrých návyků používaných zdravotnickými a jinými průmyslovými subjekty při návrhu a vývoji zdravotnických zařízení, technických produktů a systémů. Cílem je, aby inženýři i studenti pracovali dobře na velkých projektech vyžadujících týmové prostředí a efektivně komunikovali technické záležitosti, jak v písemných dokumentech, tak slovní prezentaci. Klı c ova slova Konstrukční návrh, týmy, řešení konfliktů, rozhodování, řízení projektů, řízení času, řízení ceny, řízení rizik, analýza zisku. 3

4 Obsah Abstrakt... 3 Klíčová slova Úvod do konstrukčního návrhu Týmy Definice projektu nebo problému Pozadí Fáze návrhu Shrnutí Zdroje Přehled řízení projektu Oblasti znalostí řízení projektu Životní cyklus projektu a fáze projektu Životní cyklus produktu Organizační struktury Pracovní funkce v projektovém řízení Zdroje Integrace řízení projektu Plán vývoje projektu Plán realizace projektu Řízení průběhu a změn v projektu Systém řízení změn Konfigurační management Potřeby pro úspěšný závazkový management Zdroje Řízení rozsahu projektu Řídící procesy rozsahu projektu Výběr projektů Model váženého vyhodnocování Listiny projektu Struktura rozpisu práce (WBS work breakdown structure) Přístupy k tvorbě struktur rozpisu práce (WBS) Zdroje

5 5. Personální a časové řízení projektu Řízení osobního času Pracujte lépe, ne více [1] Řízení projektového času Procesy řízení projektového času Diagramy projektové sítě Metoda diagramů přednosti (PDM) Výpočet času činnosti (trvání) Vytváření rozvrhu Metoda hledání kritické cesty (CPM) Vyhodnocení programu a kontrolní technika (PERT) Shrnutí Zdroje Management ceny projektu Procesy Plánování zdrojů Odhadování ceny Techniky odhadování ceny Problémy v odhadování ceny Vytváření rozpočtu Vodítka pro přípravu rozpočtu Kontrola ceny Zdroje Analýza získané hodnoty (EVA) Struktura členění práce (WBS Work Breakdown Stucture) Výpočet získané hodnoty Management získané hodnoty Nástroje a techniky Shrnutí Zdroje Řízení kvality projektu Řídící procesy kvality projektu Plánování kvality Zajišťování kvality

6 8.4 Kontrola kvality Paretova analýza Diagramy kontroly kvality Statistický odběr vzorků a směrodatná odchylka Základní statistická měření Testování Zlepšování kvality projektu Modely zralosti Cena kvality Mezinárodní organizace pro normalizaci Správná výrobní praxe Shrnutí Zdroje Řízení obstarávání v projektu Procesy řízení obstarávání Plánování obstarávání Typy kontraktů Plánování poptávek Výkaz práce (SOW) Poptávání Volba zdroje Smluvní administrativa Finální fáze obstarávání Zdroje Řízení lidských zdrojů v projektu Řízení lidí Zlepšení efektivity: Coveyho sedm návyků Sedm návyků Nástroje osobnosti a chování Shrnutí Zdroje Management komunikace Procesy managementu komunikace Plánování komunikace

7 11.3 Rozšiřování informací Rozpětí kontroly Zaznamenávání výkonu Zdroje Řízení rizik v rámci projektu Řízení projektových rizik Typy rizik v projektu Kvantifikace rizik Reakce na rizika Příčiny rizika Plány při řízení rizik Kontrola reakcí na rizika Souhrn Zdroje Uzavření projektu Uzavírací procedury a výstupy Administrativní uzavření Potvrzení přijetí Uzavření veřejné zakázky Schůze pro zhodnocení výsledků Záznam z vyhodnocovací schůze Plán přechodu Archivované dokumenty Kritické faktory úspěchu Shrnutí Zdroje Hodnocení návrhu projektu Úvod do vedení schůzí hodnotících návrh projektu Vstupní kritéria pro hodnocení návrhu Vedení hodnocení návrhu Výstupy hodnocení návrhu Ukončovací kritéria Zdroje Technická rozhodnutí

8 15.1 Proces skupinového rozhodování Racionální model Politický model Procesní model Model odpadkového koše Prostředí námořnictva podporující výkonné rozhodování Rozhodovací matice nebo funkce užitečnosti Vyhodnocení vážené funkce Autorská doporučení Funkce užitečnosti Váhy Známkovací stupnice Shrnutí Zdroje Zvládání týmového konfliktu Poskytování zpětné vazby Metody řešení konfliktu Souhrn Zdroje Autorova biografie

9 Kapitola 1 1. U vod do konstrukc nı ho na vrhu Postup konstrukčního návrhu je podobný procesu řešení problémů vyučovanému na technických univerzitách. Většina komerčních produktů začíná identifikací potřeby inovací na trhu. Proto mohou první kroky tvorby produktu zahrnovat 1. Inovaci nebo potenciální potřeby trhu. 2. Sestavení týmu, protože nejkomplexnější problémy či projekty nejsou vyvíjeny jednotlivci. 3. Obecné sestavení širších produktových požadavků: a. Obecně, uživatelské nároky nemusí být příliš technické; např. lékař požaduje měření teploty nebo veterinář požaduje odstranit hučení ve stetoskopu, aby slyšel tlukot srdce kočky. Jaká je ale technická specifikace? 4. Definice požadavků na vstupy a výstupy. 5. Definice výsledného užití produktu: a. Kdo ho bude používat? Jaké budou vstupy? b. Jak změříme požadovaný výsledek? c. Jak otestujeme požadovaný výsledek? d. Jaká budou kritéria pro přijetí produktu? 1.1 Týmy Webste r [1] definuje slovo tým různým způsobem: 1. Dvě nebo více zvířat zapřažených za vůz nebo jiný zemědělský stroj. 2. Vůz se zvířetem nebo zvíře zapřažené za vůz. 3. Skupina zvířat představených nebo vystupujících společně. 4. Skupina hráčů hry na stejné straně. 5. Jakákoli skupina organizovaná ke společné práci. Technika rozšířila definici na Tým je malá skupina lidí s navzájem se doplňujícími dovednostmi se stejným zájmem, cíli a přístupem, který je vzájemně zavazuje [2]. Můžete přemýšlet, proč pracovat v týmu. Někdo by mohl říci: Týmové dovednosti jsou v průmyslu ceněny. nebo že jediná osoba nemůže do hloubky ovládat všechny znalosti a postupy, aby mohla vytvořit například vesmírnou stanici. K tomu je zapotřebí tým lidí s různým vzděláním v potřebných oblastech techniky. Jednoduše, týmy potřebují inženýry s širokým záběrem, s vlastnostmi jako např.: 1. Technické znalosti 2. Kreativita 3. Práce s lidmi 4. Schopnost plánování 5. Manažerské dovednosti 9

10 Různé schopnosti a způsoby myšlení a různé pohledy na problém jsou silou dobře fungujícího týmu. Protože tým hraje zásadní roli v úspěchu projektu, projektový manažer mu musí nejen rozumět, ale také si uvědomovat pět úskalí budování týmu. 1. Vzájemná závislost: Problém spočívá v závislostech výstupů každého člena týmu, alespoň z části, na práci ostatních členů týmu. Nezávislé fungování nebo naopak soutěžení jednotlivých členů týmu může vést k neoptimálním nebo dokonce až katastrofickým výsledkům pro tým i projekt. 2. Specifikace cíle: Všichni členové týmu musí sledovat stejný cíl, ale stejně tak je nutné jasně komunikovat individuální cíle, které mohou mít. 3. Soudržnost: Termín naráží na atraktivitu členství v týmu. Tým drží pohromadě, pokud má členství v něm pro členy nějaký pozitivní přínos. Vzory členského zapojení do týmu jsou ve velmi osobních zájmech. Problém udržení soudržnosti týmu poukazuje na způsob, jakým musí být propleteny schopnosti a dovednosti jednotlivých členů týmu, aby mohl efektivně fungovat. 4. Role a normy: Každý tým si časem potřebuje stanovit role a vnitřní normy. a. Role: Týmu studentů umožní struktura rolí spolupracovat efektivněji při řešení požadavků zadané úlohy. Role mohou rotovat, aby každý získal zkušenosti a naučil se pohledu na problém z různých úhlů. Velmi důležité je, aby byly role všemi správně chápány a přijímány. b. Normy: V týmu studentů normy určují chování členů týmu a zahrnují systém odměn za dodržování svých požadavků, stejně jako sankce za jejich porušení. Normy se mohou vyvíjet mezi členy týmu, aniž by byly prodiskutovány. Nicméně, je vždy lepší mít veškerá pravidla sepsána a odsouhlasena jako ucelený dokument, kodex spolupráce, zahrnující požadované chování členů týmu společně s odměnami, ale také sankcemi. Kodex spolupráce stanoví normu přijatelného chování každého člena a zároveň stanovuje, jak budou mezi sebou členové týmu komunikovat. Může být vytvořen, převzat, vylepšen nebo měněn členy týmu a jeho kopie budou snadno přístupné celému týmu. 5. Komunikace: Efektivní mezilidská komunikace je zásadní pro hladké zvládnutí jakéhokoli týmového úkolu. Stejně tak je pro tým důležité vybudování efektivní komunikační sítě: kdo komunikuje s kým; je někdo mimo smyčku? Řízení komunikace bude opět stanoveno normami. Přimějí tyto normy každého k podílu nebo umožní jednomu či dvěma dominantním členům obsáhnout celý vysílací čas? [3]. Klíčové týmové role jsou následující: 1. Koordinátor schůzí: Řídí a připravuje agendu (např. co je třeba dokončit, ustanovuje proces, atd.); koordinuje čas, datum a místo setkání; zajišťuje, že budou k dispozici veškeré potřebné zdroje pro setkání; udržuje kodex spolupráce (případně nechává diskutovat); sleduje rozhodovací proces; koordinuje kontrolu procesu. Nicméně, tato osoba není šéf. 2. Zapisovač: Zapisovač zodpovídá za zápisy, zatímco je práce dokončována, čímž umožňuje maximální zapojení ostatních členů týmu, protože nikdo jiný si o to nemusí dělat starosti. Pokud je třeba, zapisovač také zajišťuje, že provedené akce budou zaznamenány anebo připravuje seznam činností pro udržení záznamu o přidělených činnostech. Zapisovač navíc zajišťuje, aby se kopie jejich práce dostaly ke zbytku týmu. 10

11 3. Správce času: Tato role zodpovídá za dodržování časového plánu, stejně tak musí dbát, aby se práce pohybovala kupředu a mohla být dokončena včas. 4. Podpora/strážný: Povzbuzuje zbytek týmu. Stejně tak dbá na rovnoměrné zapojení všech členů týmu. Musí se snažit dodat odvahu méně průbojným členů a usměrnit dominantní. 5. Ďáblův advokát: Zastává opačnou pozici, než celý tým, aby zajistil, že jsou zváženy všechny strany problému. Tuto roli by měli zastávat všichni členové týmu [4]. Ve výukovém prostředí jako jsou týmy studentů by měly role kolovat přes všechny členy týmu. V kostce, efektivní týmy používají role, používají kodex spolupráce, pojistky zajišťující, že všichni členové jsou na stejné straně, pracují na schopnosti naslouchání stejně jako na efektivní zpětné vazbě, používají agendu pro plánování setkání, využívají mimopracovní kontakt umožňující mimo pracovní diskuzi, definují rozhodovací proces jako součást agendy, umožňují ale zároveň diskutovat témata, která aktuálně nejsou zahrnuta v agendě, používají seznam činností pro uchování záznamu přidělené práce, soustavně kontrolují vývoj procesu a závazky všech členů. Jakmile je tým ustanoven, cíl a zadání by mělo být definováno a zdokumentováno. Následně musí být adekvátně definován celý projekt. 1.2 Definice projektu nebo problému Jedním z nejdůležitějších aspektů vývoje produktu a konstrukčního návrhu je adekvátní definice rámce problému. Často je problém ve stavu vágních projektových požadavků. Tým musí předefinovat požadavky na produkt podle vstupů, výstupů a výskytu, poté změnit a propojit požadavky do technické specifikace, např. výkon, přesnost, tolerance atd. Každý by měl mít na mysli, že celá specifikace musí být testována. Navíc musí tým vytvořit a dokumentovat kritéria pro přijetí nebo odmítnutí pro každou specifikaci, stejně jako cíl nebo úspěch a omezení (část rámce). Typické cíle nebo kritéria úspěchu zahrnují estetiku, výkon, kvalitu, lidský faktor, náklady ( vstupní kapitál stejně jako životní cyklus ), bezpečnost, operační systém, rozhraní s dalšími systémy, vliv na okolí, logistiku, spolehlivost, udržovatelnost (preventivní a poruchovou údržbu), opravitelnost a dostupnost. Omezení obvykle zahrnují následující faktory: rozpočet, čas, lidské zdroje, legislativu, materiálové vlastnosti, dostupnost materiálů na skladě versus výroba/konstrukce, soutěžení a vyrobitelnost (může být produkt vůbec vyroben?) [5]. 1.3 Pozadí Investoři nebo společnosti marketingového průzkumu mohou vyjádřit potřebu nového nebo lepšího produktu jako nápad nebo velmi obecné podmínky, ale inženýři pracující na projektu musí mít hlubší znalosti pozadí problému. Znalosti ve formě publikací o podobném projektu lze nalézt v 1. Literatuře 2. Internetu 3. Mezi patenty Hledání mezi patenty je klíčovým elementem při vývoji komerčních produktů, protože porušení patentového práva může vyústit až v soudní proces. Bez pochyby hledání znalostí zabere mnoho času a výsledky musí být analyzovány, dokumentovány a připojeny na pozadí nabídky, jako nabídka 11

12 malého podnětného obchodního výzkumu (anglicky nabídka SBIR). Tento krok zabere také mnoho času - obvykle měsíce; může se prolínat s vývojem produktu. 1.4 Fáze návrhu Většina studentských týmů považuje návrh za jednorázovou činnost, což není. Průmyslový návrh je mnoha krokový proces zahrnující různé fáze: konceptualizační fáze, studie proveditelnosti, fáze předběžného návrhu a fáze detailního návrhu. Při studii proveditelnosti, konceptualizaci nebo brainstormingu jsou nastíněny hlavní myšlenky. Při hledání řešení tým rozhoduje o výběru nejproveditelnějšího návrhu. Následující heuristiky jsou často uplatněny při hledání řešení: 1. Osvojení základů kritiky 2. Užití analogií 3. Identifikace kritických parametrů 4. Funkce přepínače 5. Změněná posloupnost kroků 6. Obrácení problému 7. Separace nebo kombinace funkcí 8. Použití vize 9. Užití základů konstrukčních principů Ve fázi předběžného návrhu je většina nadějných návrhů prozkoumána a analyzována do detailu. Obrázek 1.1: Metodologie návrhu IWT na reálných zkušenostech Nakonec ve fázi detailního návrhu prototypu tým vyvíjí vysoce detailní náčrtky s konečnou specifikací připravené pro návrh nejlepší varianty. Ve všech fázích návrhu jsou opakovány následující čtyři kroky: 12

13 1. Analýza každého potenciálního řešení 2. Výběr nejlepších výsledků nebo řešení 3. Dokumentace výsledků nebo řešení 4. Probrání výsledků nebo řešení s managementem Fáze detailního návrhu obvykle bývá, když společnost vyrobí prototyp. Marketingové strategie by měli být ve vývoji paralelně s prototypem. Jakmile je prototyp dokončen, podstoupí verifikaci nebo alfa testování a vyhodnocení specifikací návrhu, parametry výkonu, bezpečnost, atd. Výsledky jsou srovnávány s kritérii přijetí. Pokud výsledky kritérii neprojdou, prototyp musí být přepracován. Pokud naopak výsledky testů kritérii projdou, produkt může podstoupit validaci nebo beta testování, což znamená zaslání produktu různým uživatelům, aby produkt otestovaly i subjekty mimo společnost. Testování v průmyslu není stejné jako testování prováděné studenty v akademických laboratořích. Tým musí vytvořit plán testů a testovací procedury ještě před vytvořením modelu nebo prototypu. Při verifikačním testování je prototyp (hardware a software) také verifikován v integrovaném testovacím prostředí s veškerým nutným testovacím vybavením pro EMI/EMC a před-fcc verifikací. 1.5 Shrnutí Projektoví manažeři a jejich týmy by měli zaměřit svou pozornost i úsilí k naplnění zadání projektu a produkci pozitivních výsledků. Pokud dojde k problémům, doporučujeme místo obviňování členů týmu hledat jeho řešení. Projektový manažer by měl také zavést pravidelná, efektivní a otevřená jednání, kde může tým projednat veškerou agendu. Část manažérské práce také spočívá ve výchově týmu, vedení jeho členů ke vzájemné pomoci a obecnému uznání individuálních i společných úspěchů. Další informace o týmové práci naleznete v [7,8]. 1.6 Zdroje [1] Webster s New Collegiate Dictionary. Springfield, MA: G. & C. Merriam, [2] J. R. Katzenbach and D. K. Smith, The Wisdom of Teams. Boston, MA Harvard Business School Press, [3] Surviving the Group Project: A Note on Working in Teams [Online]. Dostupné na [4] D. A. Nadler, Designing Effective Work Teams. New York: Delta Consulting Group, [5] G. P. Shea and R. A. Guzzo, Group Effectiveness: What realy matters, Sloan Manage. Rev., vol. 3, pp , [6] Inovative Wireless Technologies (IWT) Design Methodology [Online]. Dostupné na [7] V. R. Johnson. (březen 2005). Understanding and assessing team dynamics. IEEE-USA Today s Eng. [Online] Dostupné na [8] V. R. Johnson. (listopad 2004). Understanding and assessing team dynamics. IEEE-USA Today s Eng. [Online] Dostupné na 13

14 Kapitola 2 2. Pr ehled r ıźenı projektu Před tím, než se pustíme do řízení projektu, položme si jednoduchou otázku. Co je to projekt? Projekt je dočasné úsilí, kterým jsme se zavázali ke splnění jedinečného účelu. Projekty můžeme mít od těch jednodušších, jako je vývoj automatického analyzátoru EEG, až po složitější za vysoké částky, jako je instalace obraného vzdušného systému Španělska. Přesto, bez ohledu na složitost, všechny projekty mají podobné vlastnosti: 1. Každý projekt má svůj vlastní jedinečný účel. 2. Projekty jsou dočasné, kvůli jejich časovému omezení. 3. Projekty vyžadují zdroje (lidské zdroje, finance, materiály), často z různých oblastí. 4. Komerční projekty by měly, a obvykle mají, primárního sponzora a/nebo zákazníka. 5. Všechny projekty provází nejistota. 6. Každý projekt je různým způsobem omezen svým a. Rozsahem b. Časem c. Cenou Je zodpovědností každého projektového vedoucího správně vyvážit tyto tři cíle projektu (rozsah, čas, cena). Takže co je vlastně řízení projektu? Řízení projektu je aplikace znalostí, dovedností, projektových nástrojů a technik do činnosti na projektu, aby se splnila nebo předčila očekávání zainteresovaných stran [1]. V terminologii řízení projektu často dochází k chybnému pochopení pojmů investor, což je člověk s akciemi ve společnosti, a zainteresované osoby. Zainteresovaná osoba je člověk, který se podílí na projektu nebo z něj těží. Můžeme mezi ně zařadit sponzory, všechny členy projektového týmu, zákazníky, uživatele, dodavatele a dokonce i odpůrce projektu. 2.1 Oblasti znalostí řízení projektu Oblasti znalostí popisují devět klíčových kompetencí, které musí vedoucí projektu rozvíjet. Čtyři oblasti vedou ke specifickým cílům projektu (rozsah, čas, náklady a kvalita). Další čtyři oblasti slouží ke snadnějšímu dosažení požadovaných cílů (lidské zdroje, řízení komunikace, rizikové řízení a řízení obstarávání). Poslední oblast (řízení integrace projektu) ovlivňuje a je ovlivněna všemi osmi oblastmi znalostí. Ačkoli je hodně znalostí potřebných ke zvládnutí projektu jedinečných pro jeho řízení, musí mít vedoucí projektu také znalosti a zkušenosti s obecným řízením a aplikací jednotlivých oblastí do projektu. V poslední řadě se také vedoucí projektu musí soustředit na splnění cílů projektu. Tato kniha popisuje jednotlivé oblasti znalostí v samostatných kapitolách. 14

15 Existuje několik technik a nástrojů pro řízení projektů, které pomáhají vedoucím projektů a jejich týmům v různých aspektech řízení projektu. Některé specifické nástroje zahrnují: 1. Projektové dokumenty 2. Plán projektu 3. Ganttův diagram, PERT grafy, metodu kritické cesty 4. Odhad nákladů a jeho analýzu Většina z těchto nástrojů je vyvíjena v softwarových programech, jako je např. Microsoft Project Jaká je tedy výhoda použití projektového řízení v projektu? Výhody, které řízení nabízí, mohou zahrnovat to, že lídři projektu, zákazníci a další zainteresované osoby nemají rádi překvapení, hlavně potom špatné zprávy. Dobré řízení projektů poskytuje jistotu a snižuje riziko neúspěchu nebo velké překročení nákladů. Projektové řízení poskytuje nástroje a prostředí pro plánování, monitorování, sledování a správu rozpisů, zdrojů, financí a kvality produktu (projektu). Projektové řízení také nabízí pohled do historie pro využití při budoucím plánování. Některé knihy tvrdí, že moderní projektové řízení začalo s projektem Manhattan, který vedla americká armáda při vývoji atomové bomby. Přesto mnozí argumentují, že moderní projektové řízení přišlo až v 50. letech se systémovým přístupem. Systémový přístup k řízení projektu zahrnuje tři části: 1. Systémová filozofie: vedoucí projektu by měli projekt vidět jako systém, navzájem související komponenty, které pracují v určitém prostředí vhodném pro splnění účelu. 2. Systémová analýza: vedoucí projektu by měli využívat přístup pro řešení projektu, který se učí studenti inženýrství. 3. Systémové řízení: vedoucí projektu by se měli zabývat obchodními, technologickými a organizačními záležitostmi před provedením změn v systému. Projektoví manažeři musí přijmout buď komplexní anebo systémový pohled na projekt a pochopit, jak to funguje ve větších organizacích, jelikož vyvinuté projekty musí fungovat v širokém organizačním prostředí. To znamená, že projekty nemohou být spuštěny v izolaci. 2.2 Životní cyklus projektu a fáze projektu Životní cyklus projektu je kolekce fází, které se liší podle projektu nebo průmyslu. Tabulka 2.1 ukazuje několik obecných fází, které zahrnují koncepci, vývoj, implementaci a podporu. Proveditelnost projektu Přínos projektu Koncepce Vývoj Implementace Uzavření Plán řízení Projektový plán Závěrečné práce Kompletační práce Předběžný Definitivní Odhad rozpočtu odhad nákladů odhad nákladů Poučení 3 úrovně WBS 6+ úrovně WBS Většina času strávená Zákazníkovo přijetí v této fázi Tabulka 2.1: Fáze životního cyklu projektu 15

16 2.3 Životní cyklus produktu Produkty mají také své životní cykly. Systémový vývoj životního cyklu (SDLC) je určitým rámcem pro popis jednotlivých fází zapojených do rozvoje a udržování informačních systémů. Typické SDLC fáze zahrnují plánování, analýzu, návrh, implementaci a podporu. Existuje několik SDLC modelů, jako je: 1. Vodopádový model, který má dobře definované, po sobě jdoucí systémové fáze rozvoje a podpory. 2. Spirálový model, ve kterém jsou výrobky vyráběny s použitím iteračního přístupu namísto lineárního. Navíc existují inkrementální a prototypové modely, které se používají pro vytvoření prototypů, které slouží pro objasnění požadavků uživatele. Životní cyklus se vztahuje na všechny projekty, bez ohledu na vyráběné produkty. Konkrétní model životního cyklu závisí na povaze výrobku. Většina velkých projektů je realizována jako sada menších projektů, které jsou v závěru sloučeny. Řízení projektu probíhá během všech fází životního cyklu a projekt by měl úspěšně projít všemi fázemi. Chceme-li se ujistit, že byly všechny fáze úspěšně dokončeny, měl by programový manažer pro předem dané milníky vypracovávat zprávu o provedené práci. Tato zpráva by se měla vypracovat po každé fázi a slouží k vyhodnocení jejího průběhu a kontrole, zda se v rámci projektu postupuje úspěšně. 2.4 Organizační struktury Pokud chceme pochopit, jak mohou programovému manažerovi pomoci různé organizační struktury a rámce, je třeba porozumět organizacím. Zde jsou čtyři základní organizační rámce: 1. Strukturní rámec, který se zaměřuje na role a odpovědnosti, koordinaci a kontrolu. Organizační schémata pomáhají definovat tento rámec. 2. Politický rámec, kde se předpokládá, že organizace je koalice složená z různých jednotlivců a zájmových skupin. Moc a konflikt jsou klíčovými otázkami v tomto rámci. 3. Rámec lidských zdrojů se zaměřuje na vytváření harmonie mezi potřebami organizace a potřebami lidí. 4. Symbolický rámec, který se zaměřuje na významy různých událostí. V tomto rámci je důležitá kultura. Většina manažerů rozumí tomu, co jsou to organizační schémata. Přesto se najde mnoho nových manažerů, kteří se pokouší změnit organizační struktury, místo aby se snažili změnit to, co je opravdu nutné. Existují tři základní organizační struktury: funkční, projektové a maticové, jak je uvedeno v tabulce 2.2. V prvním sloupci je uveden seznam projektových vlastností, v řádcích potom jejich vliv na projekt v závislosti na typu organizační struktury. Tabulka také ukazuje, že projektově orientovaná organizační struktura zajišťuje vedoucímu projektu nejvyšší úroveň pravomocí a jak on, tak i administrativní pracovníci pracují na plný úvazek. Ačkoli organizační struktura ovlivňuje autoritu projektového vedoucího, musí projektový vedoucí pamatovat na zmiňované rámce lidských zdrojů, politické a symbolické. 16

17 Připomeňme si, že zainteresované strany v projektu jsou osoby, které jsou přímo zapojené do projektu, či je projekt nějakým způsobem ovlivňuje. Proto musí projektoví manažeři strávit nějaký čas, aby poznali, pochopili a řídili vztahy mezi všemi účastníky projektu. K tomu aby splnili všechna očekávání zainteresovaných stran, by jim měly pomoci organizační rámce. Projektové charakteristiky Autorita projektového vedoucího Zastoupení pracovníků na plný úvazek Role Projektového vedoucího Označení vedoucího projektu role Projektové řízení administrativních pracovníků Funkční Malá nebo žádná Prakticky žádné Částečný úvazek Koordinátor projektu, vedoucí projektu Částečný úvazek Organizační typ Maticové Slabě Středně maticové maticové Omezená Slabá až mírná Silně maticové Mírná až vysoká Projektové Vysoká až totální 0-25% 15-60% 50-95% % Částečný úvazek Koordinátor projektu, vedoucí projektu Částečný úvazek Plný úvazek Plný úvazek Plný úvazek Projektový manažer, vedoucí projektu Částečný úvazek Tabulka 2.2: Vliv organizační struktury na projekt Projektový manažer, programový manažer Plný úvazek Projektový manažer, programový manažer Plný úvazek 2.5 Pracovní funkce v projektovém řízení V tomto okamžiku se čtenář zřejmě ptá: Co tedy projektový manažer dělá? Většina organizací vytváří pracovní místa s konkrétním popisem funkcí a povinností. Popis práce na pozici projektového manažera obvykle vyžaduje definovat rozsah projektu, vytvořit tým, identifikovat zainteresované strany a stanovit postupy pro případ, že se projekt dostane do vážných problémů. Je také zodpovědný za vytvoření podrobného seznamu úkolů a plánu projektu. Musí vytvořit časový odhad pro celý projekt a všechny jeho dílčí části. Je zodpovědný za vytvoření odhadu nákladů a jeho plnění. Také hodnotí požadavky projektu, identifikuje a hodnotí rizika a připravuje pohotovostní plány. Programový manažer musí identifikovat závislosti uvnitř i vně organizace. Je povinen vytvořit a sledovat kritické milníky a podílet se na hodnocení jednotlivých fází projektu. Má zodpovědnost za včasné zajištění potřebných zdrojů. Musí provádět případné změnové řízení. V závěru musí sesbírat potřebné informace a vytvořit prezentaci na vyšší úrovni programového hodnocení [2]. Projektový manažer tedy musí ovládat následující dovednosti: 17

18 1. Komunikační dovednosti: naslouchat a přesvědčovat. Od základních tříd jsme se učili jak mluvit, číst a psát, ale neučili jsme se jak naslouchat. Komunikace vyžaduje tři základní prvky: vysílač (mluvčí), společné médium (jazyk) a přijímač (naslouchající). 2. Organizační dovednosti: plánování, stanovení cílů a analýza. 3. Schopnost sestavit tým: lidské dovednosti, empatie a motivace. 4. Vůdčí schopnosti: uvést příklady, být energetický, mít vizi, být pozitivní. 5. Řídicí dovednosti: flexibilita, kreativita, trpělivost a vytrvalost. 6. Technické dovednosti: technické znalosti, projektové znalosti a zkušenosti. V souhrnu lze projektové řízení považovat za několik navzájem propojených procesů. Patří mezi ně zahájení, plánování, vykonávání, řízení a uzavírání projektu. Tabulka 2.3 ukazuje vztah mezi oblastmi znalostí a jednotlivými procesy. Z tabulky můžeme předpokládat, že vedoucí projektu využije všechny oblasti znalostí v plánovací fázi. Musí ale všechny ostatní znalosti použít během celého životního cyklu [3]. Na druhou stranu členové týmu stráví nejvíce času během vykonávající fáze životního cyklu projektu. Oblast znalostí Integrace Procesy projektu Inicializace Plánování Vykonávání Kontrola Uzavírání Vývoj projektového plánu Vykonávání projektového plánu Rozsah Zahájení Plánování rozsahu Ověření rozsahu Čas Cena Definice činností, časový odhad, vývoj rozvrhu Plánování zdrojů Odhad nákladů, rozpočet Kvalita Plánování kvality Záruka kvality Lidské zdroje Komunikace Riziko Obstarávání Plánování organizace, Získání personálu Plánování komunikace Identifikace rizik, kvantifikace Plánování obstarávání Plánování nabídek Vývoj týmu Distribuce informací Kontrola Nabízení, výběr zdroje Smluvní administrativa Celkové změnové řízení Změnové řízení rozsahu Kontrola nákladů Kontrola kvality Provádění hlášení Reakce na rizika Tabulka 2.3: Vztahy mezi projektovými procesy a oblastmi znalostí Administrativní uzavření Smluvní uzavření 18

19 2.6 Zdroje [1] Project Management Body of Knowledge (PMBOK Guide), Program Management Institute, Newtown Square, PA, 1996, p. 6. [2] Building a Foundation for Tomorrow: Skills Standards fot Information Technology, Northwest Center for Emerging Technologies, Belleview, WA, [3] Project Management, Univ. Washington [Online]. Dostupné na

20 Kapitola 3 3. Integrace r ı zenı projektu Projektoví manažeři, kteří mají tendenci se zaměřovat na příliš mnoho detailů, pak mají problémy s komplexním pohledem na celkovou situaci. Jak bylo uvedeno v předchozí kapitole, projektoví vedoucí musí koordinovat všechny různé znalostní oblasti v celém životním cyklu projektu [1]. Tabulka 2.3 v kapitole 2 ukazuje, že plánování projektu vývoje je součástí integrace znalostních oblastí, které probíhají během celého procesu plánování projektu. Plánování vývoje projektu vyžaduje přijetí výsledků z jiných plánovacích procesů a jejich vložení do konzistentní, souvislé dokumentace (plán projektu, také označovaný jako program vedoucího plánování projektu). Integrace během realizačního vývoje zahrnuje provádění plánování projektu (realizace plánu projektu) a během řídícího procesu programový manažer dohlíží na celkové změny regulačního procesu a zajišťuje koordinaci změn napříč celým projektem. Rozhraní managementu zahrnuje identifikaci a řízení bodů spolupráce mezi různými prvky projektu. Vedoucí projektů musí vytvořit a udržovat dobrou komunikaci a dobré vztahy mezi organizačními složkami. 3.1 Plán vývoje projektu Plán projektu je dokument, užívaný ke koordinaci všech dokumentů pro plánování projektu. Hlavním smyslem plánu projektu je jakýsi návod projektové realizace, který má pomoci vedoucímu projektu ve vedení projektového týmu a vyhodnocení stavu projektu. Plány projektu jsou jedinečné, stejně jako jsou jedinečné projekty. Hlavními atributy jsou plány projektu, které by měly být: - Dynamické - Flexibilní - Aktualizovány stávajícími změnami - V první řadě návodem na realizaci projektu Je třeba zdůraznit poslední bod. Plány jsou vodítka, která mohou být změněna a neexistují pro ně závazná pravidla. Nejběžnější prvky projektového plánování jsou úvod nebo úvodní přehled projektu, část popisující jak je projekt organizován, oddíl řízení a technických procesů použitých na projekt a sekce popisující práci, která má být provedena, tj. část obsahující pracovní harmonogram s detailním rozpisem work breakout schedule (WBS) obsahující informace o rozpočtu. Tabulka 3.1 obsahuje jednoduchou osnovu řízení plánu projektu. Úvodní sekce by měla začít uvedením problému, což by mělo být hned na začátku dokumentu. Následuje zdůvodnění proč má smysl na projektu pracovat. Tato část by měla obsahovat pasáže o celkovém přehledu projektu, ohlédnutí za předchozími a podobnými projekty, všechny referenční materiály, jaké očekáváme vstupy a jaké výstupy, slovník s definicemi pojmů a případné vysvětlení zkratek [2]. Struktura projektu by měla obsahovat část popisující vývojový model, jeho odůvodnění, organizační strukturu, její hranice a rozhraní. Jednotlivé odpovědnosti za části projektu by měly být jasně přiděleny a popsány. Část zabývající se řídícím procesem by měla 20

21 obsahovat podrobně vysvětlené manažerské cíle, priority, předpoklady, závislosti, omezení, monitorování a kontrolu mechanismů, které jsou použity. Navíc by měla tato část obsahovat detailní popis personálního plánu a procesu řízení rizik. Část technického procesu by měla obsahovat detailní informace o metodách, nástrojích a technikách v projektovém vývoji, stejně tak dokumentaci návrhu hardware a software, nákresy, popis operace a údržbu. Tato část by měla projednat podpůrné složky projektu. Poslední část obsahuje popisy pracovních balíčků, závislosti, požadavky na zdroje s odůvodněním, rozpočet, alokace zdrojů a program projektu. 3.2 Plán realizace projektu Plán realizace projektu zahrnuje správu a vykonání práce popsané v plánu projektu. Obecně je většina času a peněz obvykle vynaložena na realizaci, protože produkty projektu jsou produkovány během realizace. Projektoví manažeři budou používat tyto dovednosti v průběhu realizační fáze: 1. Obecné manažerské dovednosti, mezi které patří vedení, komunikace a politické dovednosti 2. Znalost produktu Navíc fáze realizace projektu vyžaduje zkušenosti s používáním speciálních nástrojů a znalost technik. Mezi techniky ulehčující práci projektového manažera během realizace projektu zahrnujeme práci autorizačního systému, který poskytuje metody pro zajištění toho, aby správní lidé pracovali ve správný čas na správném místě a dále organizování schůzky pro revizi stavu podle pravidelného harmonogramu (týdně, měsíčně), kde se navzájem informují o projektu a hodnotí jeho prozatímní průběh. Autoři dávají přednost týdenním osobním schůzkám s měsíčně vypracovávanými zprávami o stavu projektu. Jednotlivá témata: Úvod Organizace projektu Řídící proces Technický proces Pracovní balíčky, harmonogram, rozpočet přehled projektu, očekávané výsledky, vývoj PMP, referenční materiály, definice a zkratky model vývoje, organizační struktura, hranice a rozhraní, odpovědnost a odpovědnost za projekt cíle managementu a jeho priority, předpoklady závislosti omezení, řízení rizik, kontrolní procesy, personální plán metody, nástroje a techniky, hardwarová dokumentace, softwarová dokumentace, podpůrné funkce projektu pracovní balíčky, závislosti, požadavky na zdroje, rozpočet a dotace, harmonogram Tabulka 3.1: Vzorová osnova pro plán řízení projektu (PMP) Na pomoc vedoucím při řízení projektů slouží speciální software pro řízení projektů, např. Microsoft Office Project. Konečný proces projektu vyžadující integraci znalostních oblastí je projekt řízení 21

22 procesu, který vyžaduje projektový manažer a bude dohlížet kontrole produktu nebo změnám v projektu. Pro lékařské přístroje FDA (Food and Drug Administration, americký úřad pro kontrolu potravin a léků) vyžaduje papírovou dokumentaci pro jakékoliv změny produktu. 3.3 Řízení průběhu a změn v projektu Celková změna řízení se týká identifikace, hodnocení a řízení změn během životního cyklu projektu. Tři hlavní cíle řízení změn jsou: 1. Ovlivnit faktory, které vytvářejí změny s cílem zajistit jejich prospěšnost 2. Určit, že došlo ke změně 3. Plánovat aktuální změny, kdy a jak k nim dojde Změny v projektu nebo produktu mohou vyplývat z nutnosti přijmout nějaké opatření k nápravě, ze změny požadavků nebo z hodnocení stavu a zpráv o pokroku. Vytvořené dokumenty se základním plánem a zápisem o aktuálním stavu a zprávě o pokroku se začínají srovnávat s plánem, je-li zjištěno, že došlo ke změnám nebo že by měly nastat. Pokud je nutné přijmout některá opatření, tak to vyžaduje vždy jisté aktualizace v dokumentaci plánu projektu. Aktualizace plánu projektu se stává současně novým plánem vývoje. Průběh není tak jednoduchý jak by se mohlo zdát, protože vládní předpisy nařizují formální systém kontroly změn. 3.4 Systém řízení změn Změna systému řízení je formální, dokumentovaný proces, který popisuje, jak a kdy mohou být oficiální projektová dokumentace a projektové práce změněny. Systém řízení změn popisuje, kdo je oprávněn provádět změny a jakým způsobem se změny provádějí. Každý projektový manažer musí založit CCB (Change Control Board), tzn. vytvořit kontrolní výbor, složený z pracovníků a navrhnout plán řízení a zavést proces sdělující změny všem zúčastněným stranám. CCB je formální skupina lidí zodpovědná za schválení nebo odmítnutí změn v projektu. Komise CCB stanovuje obecné zásady pro vypracování nebo změny požadavků, které vyhodnocuje a řídí realizaci schválených změn. Výbor by měl zahrnovat zúčastněné strany z celé organizace. Protože se některé komise schází jen občas, může to trvat příliš dlouho na to, aby ke změnám docházelo včas. Proto mají některé organizace zavedeny vhodnou politiku pro časově citlivé změny. Tzv. 48-hodinová politika dovoluje členům projektového týmu, aby udělali rozhodnutí, a pak mají dalších 48 hodin na to ho zvrátit, než ho vedení odsouhlasí. 3.5 Konfigurační management Konfigurační management zajišťuje, že produkty a jejich popisy jsou správné a úplné. Dále se zaměřuje na identifikaci a kontrolu funkčních a konstrukčních vlastností výrobků. Specialisté řízení konfigurace identifikují a dokumentují požadavky na konfiguraci, řízení změn a prověřují výrobky s cílem ověřit, jestli odpovídají požadavkům. Kvůli jeho významu autoři naznačují, že projektoví manažeři se dívají na projektový management jako na proces neustálé komunikace 22

23 a vyjednávání. Manažer by měl dohlížet na využití dobrého konfiguračního managementu s definovanými postupy pro včasné rozhodování o menších změnách. Manažeři by neměli spoléhat pouze na verbální komunikaci, ale měly by využít písemné a ústní zprávy o výkonnosti, aby jim pomohli identifikovat a zvládat změny. Měli by se naučit používat program pro řízení projektů a další software, aby jim pomohl řídit a oznámit změny. 3.6 Potřeby pro úspěšný závazkový management Několik studií uvádí top závazkový management jako jeden z klíčových faktorů spojených s úspěšností projektu. Studie od Pinto a Slevin z roku 1987 uvádí jako klíčové faktory: 1. Podporu top managementu 2. Jasné poslání projektu 3. Dobrý projektový harmonogram/plán 4. Dobré projednání s klientem Zatímco Standish Group Study (1995) uvádí za klíčové faktory: 1. Výkonnou podporu řízení 2. Jasně stanovené požadavky 3. Správné plánování 4. Zapojení uživatele Top management může vedoucím projektů zajistit odpovídající zdroje, získat souhlas pro unikátní projekt v potřebném čase, zajistit spolupráci od lidí v celé organizaci a naučit je být lepšími vůdci. Projektoví manažeři by měli splňovat potřeby organizačních norem. Vyšší vedení by mělo podporovat užívání standardních formulářů a software pro řízení projektů, vývoj a používání pokynů pro psaní plánu projektu nebo poskytování informací o jeho stavu a vytvoření oddělení řízení projektu nebo centra pro zajištění vysoké kvality. Je osvědčeným pravidlem, že normy pomáhají projektovým manažerům být efektivnější. 3.7 Zdroje [1] Project Integration, Project Management, University of Washington [Online]. Dostupné na [2] Project Plan, Management, University of Washington [Online]. Dostupné na

24 Kapitola 4 4. R ı zenı rozsahu projektu Studie z poloviny devadesátých let uvádějí, že pro úspěch projektu je velmi důležité stanovit jasné cíle projektu s jasnými požadavky. Například, The Keler Graduate School of Management uvádějí nesprávnost definice projektů a jejich rozsahu jako hlavní důvody jejich selhání. Při definování projektu, produktu nebo problému bychom se neměli omezovat jen na to, čeho má být dosaženo, ale mělo by být zahrnuto i to, čeho nebude dosaženo; tj. nastavit hranice mezi tím, co se od produktu očekává a naopak k čemu už není výrobek určen. Takže co znamená řízení rozsahu projektu? Rozsah projektu se vztahuje na všechny činnosti podílející se na vytváření produktů projektu a procesů používaných k jejich vytváření. Je důležité, aby řízení rozsahu projektu zahrnulo procesy, které se podílejí na definování a kontrole co je a nebo co není součástí projektu. Proto je důležité, aby si projektový tým a všechny zúčastněné strany dobře porozuměli v tom, jaké produkty budou výsledkem projektu a jaké procesy budou použity při jejich výrobě. 4.1 Řídící procesy rozsahu projektu V oddílu 2.4 v kapitole 2 bylo zmiňováno, že projektoví manažeři budou využívat rozsah oblasti znalostí v průběhu celého procesu projektu. Zahájení zpracování projektu se odehrává na jeho začátku nebo na počátku další fáze - pokud projekt pokračuje od ukončené fáze. Prvním krokem při zahájení projektů je pohlédnout komplexně na firmu nebo strategický plán organizace. Strategické plánování zahrnuje stanovení si dlouhodobých obchodních cílů a zajištění, aby manažeři těchto projektů podporovali strategické a finanční cíle podniku. Mnoho organizací sleduje při výběru projektu plánovací proces. Prvním krokem je vytvořit strategický plán založený na celkovém strategickém plánu organizace. Druhým krokem je provést analýzu oblasti obchodu, poté jsou stanoveny potencionální projekty, rozsah projektu, přínosy a omezení. Posledním krokem je vybrat co nejvíce realizovatelných projektů a přiřadit zdroje. V průběhu plánování, vedoucí projektu vyvíjí dokumenty o plánování rozsahu projektu, které pak poskytnou základ pro budoucí rozhodnutí o projektu. Během tohoto procesu, kdy projektoví vedoucí vyvíjí definice, se rozdělí hlavní výstupy projektu na menší, lépe zvládnutelné části. Během provádění procesu, jsou vyvíjeny dokumenty o ověřování rozsahu projektu a převedeny ve formalizaci přijetí rozsahu projektu. Dokumenty o řízení změn v rozsahu projektu jsou vyvíjeny a používány v průběhu řízení procesu, aby zajistily shodu při kontrole změn rozsahu projektu. 4.2 Výběr projektů Existuje obvykle více projektů, než kolik dostupného času a prostředků máme k jejich implementaci. Proto je při vybírání projektu, na kterém budeme pracovat, důležité zachovat logický postup. Mezi 24

25 metody pro výběr projektů, na kterých budeme pracovat, patří zaměření na širokou škálu potřeb, kategorizace projektů, finanční metody a vážené bodování modelů. Často je obtížné poskytovat silnou podporu pro mnoho projektů, ačkoliv všichni souhlasí s tím, že mají vysokou cenu. Přístup zaměření se na široké organizační potřeby je založen na splnění tří důležitých kritérií pro projekty: 1. Musí existovat potřeba pro realizaci projektu 2. Musí být k dispozici prostředky pro projekt 3. Musí existovat silná vůle, aby se projekt podařil Přístup ke kategorizaci projektů je založen na následujících kategoriích: 1. Co daný projekt řeší? a. Problém b. Příležitosti c. Pokyny pro vyšší management 2. Jak dlouho bude trvat udělat projekt a kdy je potřeba, aby byl hotový? 3. Jaká je celková priorita projektu v rámci organizace Přístup k finanční analýze projektů je založen na předpokladu, že finanční hledisko je důležitým faktorem při výběru projektů. Existují tři primární metody pro stanovení odhadu ceny projektu: Analýza čisté současné hodnoty (NPV net present value), návratnost investic (ROI return on investment) a analýza návratnosti. NPV je metoda výpočtu očekávaných budoucích peněžních zisků a ztrát do tohoto časového bodu. Pokud je finanční hodnota klíčovým kritériem, pak projekty s pozitivní NPV by měly být hodnoceny: Čím vyšší je NPV, tím lépe. ROI je podíl příjmu a investic, jak je uvedeno v rovnici. 4.1: é é ří é é á á (4.1) Většina organizací má potřebnou míru výnosnosti nebo minimální přijatelnou míru návratnosti investic u projektů, tedy čím vyšší ROI, tím lépe. Dalším důležitým finančním ohledem je analýza návratnosti. Čas návratnosti investice je doba, kterou bude trvat kompenzace v podobě čistých peněžních toků, dolarů investovaných do projektu. Návratnost nastane, když kumulativní diskontované přínosy a náklady jsou větší než nula. Mnoho organizací chce, aby projekty měli poměrně krátkou dobu návratnosti. 4.3 Model váženého vyhodnocování Model váženého vyhodnocování je nástroj, který zajišťuje systematický postup pro výběr projektů na základě mnoha kritérií. Prvním krokem v modelu váženého vyhodnocování je identifikovat kritéria důležitá pro proces vybírání projektů. Druhým krokem je přiřadit váhu (procenta) každému kritériu, tak aby celková váha byla 100 procent. Dalším krokem je sestavit hodnotící tým, kde každý člen vyhodnotí a přiřadí skóre každému kritériu pro každý projekt. V posledním kroku jsou skóre 25

26 vynásobena váhami, výsledné hodnoty jsou sečteny a dávají celkové vážené skóre. Projekt s vyšším váženým hodnocením je při výběru nejlepší možností, platí čím vyšší vážené skóre, tím lépe. 4.4 Listiny projektu Po organizaci nebo poté, kdy se vedoucí projektu rozhodl, na jakém projektu se bude pracovat, je důležité formalizovat projekty do oficiálních dokumentů. Listina projektu je dokument, který formálně uznává existenci projektu a stanoví směr na projektovém cíli a řízení. Je důležité, aby klíčoví účastníci projektu a vyšší vedení (řídící management) podepsali dohodu o potřebě a záměru projektu. A to buď listinu projektu, nebo projektový plán řízení, které by měly obsahovat formální řízení rozsahu projektu. Deklarace rozsahu projektu je dokument používaný k vytvoření a potvrzení společného chápání rozsahu projektu a měl by obsahovat následující části: zdůvodnění projektu, stručný popis produktů projektu, souhrn všech výstupů projektu a prohlášení o tom, jakým způsobem se určí úspěch projektu (jaká jsou kritéria pro úspěch projektu). 4.5 Struktura rozpisu práce (WBS work breakdown structure) Po dokončení plánování rozsahu projektu je dalším krokem k vymezení prací to, že je rozdělíme na zvládnutelné části. Dobré definování rozsahu pomáhá zvýšit přesnost časových nákladů a odhadů zdrojů, definuje osnovu pro měření výkonnosti a řízení projektů a pomáhá v komunikaci jasné pracovní povinnosti. Hierarchická struktura prací je na výsledek zaměřená analýza prací zapojených do projektu, která určuje celkový rozsah projektu. Příklad hierarchické struktury prací v tabulkové formě 1.0 Koncept 1.1 Zhodnocení stávajícího systému 1.2 Definice požadavků Definice uživatelských požadavků Definice požadavků na obsah Definice požadavků na výrobky 1.3 Definice specifických funkcí 1.4 Definice rizik a přístup k řízení rizik 1.5 Vypracování plánu projektu 1.6 Informovat vývojový tým webu 2.0 Návrh produktu 3.0 Vývoj produktu 3.1 Testování produktu 4.0 Zavedení 5.0 Podpora 6.0 Výsledky Tabulka 4.1: Příklad hierarchické struktury prací v tabulkové formě To je základní dokument v oblasti projektového řízení, neboť poskytuje základ pro plánování a řízení projektových plánů, nákladů a změn. Příklad hierarchické struktury prací je uveden v tabulce

27 4.6 Přístupy k tvorbě struktur rozpisu práce (WBS) Existují čtyři základní přístupy k rozvoji WBS: 1. Postup použití obecných zásad: Některé organizace, jako je ministerstvo obrany, stanovují obecné zásady pro vypracování WBS. 2. Analogický postup: Pomáhá k přezkoumání struktur rozpisu práce z podobných projektů. 3. Postup shora-dolů: Začít s největšími úkoly v projektu a rozebrat je. 4. Postup zdola-nahoru: Začít s podrobnými úkoly a rozvinout je. Většina projektových vedoucích využívá postupu shora-dolů a může začít řešit větší úkoly a další stanovit podle potřeby. Zde jsou některé základní zásady pro vytváření WBS [1]: 1. Pracovní jednotka (tým) by se měla objevit pouze v jednom místě WBS. 2. Pracovní rozsah úkolu ve WBS je součet úkolů WBS pod ním. 3. Za každý úkol ve WBS nese odpovědnost pouze jeden jedinec, i když na něm může pracovat více lidí. 4. Struktura rozpisu práce musí být v souladu s tím, v jaké oblasti ve skutečnosti bude používána; to by mělo sloužit projektovému týmu a dalším praktickým účelům. 5. Členové projektového týmu by měli být zapojeni do rozvoje WBS, aby se zajistila soudržnost a zapojení. 6. Každá položka WBS musí být zdokumentována, aby se zajistilo přesné pochopení rozsahu prací, které jsou do této položky zahrnuty, a které nejsou. 7. WBS musí být flexibilním nástrojem k přizpůsobení nevyhnutelných změn a zároveň k správnému udržení kontroly nad obsahem práce na projektu podle deklarace rozsahu projektu. Je velmi obtížné vytvořit dobrou deklaraci rozsahu projektu a WBS pro projekt a ještě těžší je ověřit rozsah projektu a minimalizovat změny v rozsahu. Mnoho projektů trpí něčím, co se označuje jako natahování rozsahu a nedostatečným ověřováním rozsahu. K natahování rozsahu dochází, když se přidávají další požadavky (specifikace nebo změny konfigurace) na projekt, aniž by byly součástí oficiální procesu konfiguračního řízení. Johnson [2] zveřejnil seznam 10-ti nejčastějších faktorů, způsobujících problémy v projektu. Tento seznam je uveden v tabulce 4.2. Faktory na druhém a třetím místě se zabývají nedostatečnou definicí rozsahu, případně rozsahem dotváření. 10 nejčastějších faktorů, způsobujících problémy v projektu 1. Špatná komunikace s uživatelem 2. Nekompletní požadavky a specifikace 3. Měnící se požadavky a specifikace 4. Nedostatek výkonné podpory 5. Nezpůsobilost technologií 6. Nedostatek zdrojů 7. Nerealistická očekávání 8. Nejasné cíle 9. Nereálné časové rámce 10. Nové technologie Tabulka 4.2: 10 nejčastějších faktorů, způsobujících problémy v projektu 27