Rozsah projektu – výchozí principy

| Jan Doležal

Rozsah projektu - Apollo_15

Představte si situaci, že máte před dovolenou, kterou hodláte strávit pod stanem ve vysokých horách a na Vás připadl úkol nakoupit veškeré potřebné vybavení a zásoby potřebné pro vaši výpravu. Jak nejlépe zajistíte, že na nic nezapomenete? Ano – sepíšete si seznam. Stejně, jako když jdete i na obyčejný nákup, udělat si seznam je ten nejlepší způsob, jak na nic nezapomenout a zároveň, na druhé straně, nekoupit něco, co nepotřebujete. V projektech je to do značné míry analogické, jen měřítko je poněkud větší. Rozsah projektu, respektive jeho řízení (Scope management) v projektech zahrnuje několik principů:

  • Strukturování problému
  • Oddělení CO od JAK
  • Bezezbytkový rozklad (100%)
  • Zákaznická perspektiva

Pojďme si je postupně projít.

Struktury v projektu

Jedním ze základních principů projektového řízení celkově, je strukturování problému do menších, lépe zvládnutelných celků a jejich jednotlivých prvků, spolu s definicí vzájemných vazeb – a rozsah projektu je v tomto ohledu na prvním místě. Navíc, pokud chceme o projektu, programu nebo portfoliu komunikovat, musíme jej být schopni popsat na různých úrovních abstrakce a nejlépe jej i vhodně vizualizovat.

Jeden z projektomanažerských bonmotů zní: „Jak sníst slona? Tak, že ho rozdělíme na malé kousky.“ To je esence strukturování v projektu.

Strukturovat tedy můžeme systémy a prvky náležející jedné nebo i více organizacím, do položek různé komplexity a úrovně detailu. Jedním z pojetí vertikální hierarchie může být rozdělení dle komplexnosti jednotlivých prvků a systémů:

  • trvalá organizace;
  • portfolio;
  • část portfolia (subportfolio);
  • program;
  • podprogram (subprogram);
  • komplexní projekt (projekt);
  • část komplexního projektu (subprojekt);
  • hlavní výstup;
  • výstup;
  • pracovní balík (work package).
rozsah projektu - struktury

Hierarchie prvků systému projekt, program, portfolio

Uvedený příklad samozřejmě není jediný možný. V rámci organizace jako celku např. nemusí být vůbec definovány programy nebo jiný z uvedených prvků.

Strukturovat lze vhodným způsobem i další součásti (aspekty) projektu, jako je např. rozpočet nebo organizace projektu z hlediska lidských zdrojů.

Vždy je důležité, aby v rámci jedné organizace byla strukturalizace provedena provázaně a vzájemně kompatibilně tak, aby se daly vysledovat všechny potřebné vertikální vazby a aby bylo možné vhodně komunikovat i o několika položkách na stejné úrovni dané hierarchie.

Oddělení CO od JAK – základ pro zvládnutý rozsah projektu

V příkladu s nákupem na hory uvedeným výše je názorně vidět rozdíl mezi CO a JAK. Zmíněný nákupní seznam zkrátka obsahuje položky, které se prostě musí v daný okamžik někde objevit. Jak to bude provedeno, není v tomto úhlu pohledu podstatné.

Představme si např. nákupní seznam:

  • pláštěnka pro dceru,
  • 2 bílé jogurty,
  • chleba,
  • lepicí páska,
  • vzrostlý rododendron,
  • krumpáč.

Záměrně uvádíme dost nesourodé položky, aby bylo zřejmé, že v jednom obchodu všechny položky pravděpodobně neseženeme. Avšak v daném kontextu to není důležité. Důležitým je udělat kompletní výčet všeho, CO je potřeba dodat. Jak to bude probíhat, budeme řešit až v dalších krocích. Dokud nebudeme mít kompletně vyřešené CO, nemá příliš smysl se JAK zabývat. Při pohledu na dvě poslední položky výše je zřejmé, že síťovka mi stačit nebude a ani moped asi nebude ten pravý dopravní prostředek.

Bezezbytkový rozklad

Rozsah projektu je potřeba popsat právě na 100% toho, co musí být dodáno k tomu, aby byl splněn cíl projektu a zároveň pouze to, co je potřeba dodat. Dodávkami jsou zde myšleny zrealizované výstupy, výsledky nebo provedené služby. Ty jsou co možná nepřesněji popsány, jsou definovány jejich parametry a hranice.

V našem příkladu s nákupním seznamem nám v tomto ohledu něco chybí. Pokud by byl „cíl“ definován jako „Všechny položky jsou na stanoveném místě nejpozději zítra v 16:00“, nezahrnuje prostý výčet položek k nákupu vše, co je potřeba dodat pro realizaci tohoto cíle. Je potřeba ještě nějak zahrnout zrealizovanou službu – „Nakoupeno“, která zahrne samotný proces nákupu a práci s tím spojenou.

Ve výsledku tedy budou dodány nejen dané položky, ale i úsilí (myšleno jako hotová, dokončená práce – tedy výsledek) nezbytné k dodání těchto položek.

Právě 100% rozklad je velmi účinnou obranou před tzv. scope creep, volně přeložitelným jako plíživě narůstající rozsah projektu. Nebo též po česku, salámová metoda. Udělejme v rámci projektu ještě toto. A když už to máme tak ještě toto. A velmi brzy se Vám projekt vymkne z kontroly.

Je zde velmi na místě ctít prastarou moudrost nazývanou Occamova břitva – princip logické úspornosti, od 19. století nazývaný podle anglického logika, františkána Williama z Ockhamu (1287–1347). Latinská definice tohoto principu zní: Entia non sunt multiplicanda praeter necessitatem. Tj. Entity se nemají zmnožovat více, než je nutné.

Použití slova „břitva“ má navozovat představu nástroje, kterým se „odřezávají“ nadbytečné entity.

rozsah projektu - ockham

William Ockham – kresba z rukopisu jeho Logiky (1341)

Zákaznická perspektiva

Při ctění tohoto principu jde o to, formulovat nejen cíl projektu, ale i rozsah projektu, tedy každý výstup, dílčí výstup atd. až po pracovní balíky, z perspektivy příjemce, zákazníka.

Může jít samozřejmě o koncového zákazníka, ale i o všechny interní zákazníky: přímé nadřízené v rámci projektu, kolegy z projektového týmu apod. Zákazníkem je zde myšlena osoba, která danou dodávku k něčemu potřebuje a bude s ní dále pracovat, osoba, která od nás příslušnou dodávku přebírá.

Např. při implementaci nějakého informačního systému může být potřeba vytvořit v rámci testovacího prostředí nějaký server. Je velký rozdíl, pokud danou dodávku formulujeme jako „testovací server vytvořen“, což je běžná perspektiva dodavatele nebo když zvolíme formulaci ve smyslu „server, na kterém můžeme testovat k dispozici“.

Mezi výše popsanými stavy je totiž určitá šedá zóna, ve které se mohou skrývat různá dodatečná nastavení a úpravy, které z úhlu pohledu realizátora nemusí být jasně zřetelné a zbytečně tak dochází během předávání ke konfliktům, dodělávkám apod.

Vždy je proto vhodné zaměřit se na „byznys hodnotu“ dané dodávky pro toho, komu je určena a právě tuto byznys hodnotu dodat. Testovací server, na kterém nejsou nastaveni potřební uživatelé je pro testování k ničemu.

Jiným příkladem může být rozdíl mezi „rukopis (nebo cokoliv podobného) odevzdán“ a „text schválen do tisku“. Nebo „výrobek vyvinut“ a „můžeme výrobek vyrábět“. Vždy jde o stav na konci, která zákazník potřebuje k tomu, aby mohl s daným výsledkem dále pracovat.

Rozsah projektu by tedy měl být vždy popsán z perspektivy „zákazníka“.

Závěr

Vše výše uvedené je vhodné následně respektovat, ať už budeme rozsah projektu volně popisovat, nebo sestavovat WBS. Pouze tak dosáhneme kvalitního výsledku.

Další užitečné rady a tipy naleznete v naší knize Projektový management.

O autorovi článku

Jan Doležal

Jan Doležal

V současné době se zabývá především hybridními přístupy, agilitou v organizacích (SCRUM, SAFe, LeSS, DAD) a vývojem simulačních her sloužících jako trénink projektového řízení nebo agilních přístupů.

Má víc jak 20 let zkušeností. Disponuje certifikací PMI PMP, DASSM, IPMA B, SAFe Program Consultant (SPC), Certified SCRUM Product Owner a Certified SCRUM Professional – ScrumMaster od SCRUM Alliance.

Je autorem knih, např. „Projektový management“ nebo „Agilní přístupy vývoje produktu a řízení projektu“.

Další podrobnosti čtěte zde.

Další zdroje informací

Komentáře (0)

Zatím žádný komentář.

Přidejte váš komentář

Vaše e-mailová adresa nebude zveřejněna. Pole označená hvězdičkou (*) jsou povinná.