facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
Dialog 3000Skylla
IT SYSTEMS 1-2/2014 , Projektové řízení

Řízení (nejen) IT projektů (4. díl)

Výsledky jsou to, co se počítá



PM ConsultingJeden náš lektor svého času používal citaci kačera Donalda ve znění: „Řítíme se tou nejvyšší rychlostí, ale nevíme kam…“ To je často až nečekaně přesným popisem stavu projektu. Situace je o to méně záviděníhodná, o co je rychlost řícení se (a tím pádem i čerpání rozpočtu) vyšší. Ve čtvrtém dílu seriálu o řízení projektů si představíme velmi účinný nástroj pro udržení projektu pod kontrolou.


Když je „co“ důležitější než „jak“

Byl jsem přítomen rozjezdu několika projektů, při kterých se v podstatě ihned po jejich spuštění, respektive oznámení, že se na něčem takovém bude dělat, začalo pracovat na věcném řešení. Byl znám termín, cíl a rozpočet, tak co dalšího vymýšlet, že? V podstatě u všech takových projektů se následně opakoval téměř totožný scénář. Několik týdnů pracovníci usilovně a podle svého nejlepšího vědomí a svědomí pracovali na požadovaném řešení. Dříve či později přišla jaksi bokem informace od obchodníka, který byl u příslušného zákazníka na jednání o něčem úplně jiném, že u oběda otevřeli i téma daného projektu a že by zákazník jen tak mimochodem chtěl z hranatého kulaté. A to nám přece nevadí, na cíli se nic nemění a rádi to pro zákazníka uděláme, že? Členům týmu, kteří do tohoto okamžiku pracovali na řešení, je ihned jasných několik věcí. Především to, že zhruba osmdesát procent vyvinutého úsilí bylo k ničemu, mohou v podstatě začít znovu a termín s rozpočtem jsou zcela nereálné.

Záměrně poněkud přeháním, byť i takové případy se najdou. Účinnou obranou proti takovému stavu je nejprve pro projekt specifikovat věcný rozsah tak, aby bylo zcela jasné, co má být projektem dodáno, jaké to má mít parametry atp., případně i definovat, co do projektu nepatří. Daný rozsah bude v dalších fázích oceněn lidskou prací a náklady na materiálové a další zdroje. Pouze o takto založenou specifikaci půjde následně opřít smysluplné řízení změn a jen tak nám kupením dodatečných požadavků a přání nepřeroste projekt přes hlavu.

Mantra jménem WBS

Zkratka z anglického work breakdown structure (WBS) již v našich domácích PM podmínkách dostatečně zakořenila. Nicméně, překlad a výklad daného sousloví je již značně různorodý. Nehledě na lingvistické a filosofické debaty, největší praktický smysl má pojetí blízké výkladu podle standardu PMI. V něm se jedná o strukturovaný, hierarchický rozpad věcné stránky projektu na jednotlivé výstupy, dodávky a pracovní balíky s tím, že se vždy jedná o definovaný celek hotové, předatelné práce – tedy výstup, dodávku, zrealizovanou službu apod. Nejedná se tedy o činnost, práci jako takovou, ale o její výsledky.

WBS umožňuje udělat si jasnou představu o tom, jaké výsledky je potřeba během projektu dodat. Zároveň kvalitně zpracovaná WBS vytváří pevný základ pro vytvoření harmonogramu, rozpočtu i přiřazení zodpovědností (viz další díly našeho seriálu). Správně vytvořené WBS zahrnuje výsledky veškeré práce, kterou je na projektu potřeba odvést, aby bylo dosaženo cíle. Pokrývá tedy sto procent věcného rozsahu projektu. Projektový tým tudíž dodá (respektive zajistí dodání) vše, co je obsahem WBS. Nic víc, nic míň. WBS je většinou sestavena způsobem „shora dolů“, tedy od větších, komplexních celků (např. konkrétních výstupů z logického rámce) do podrobnějších detailů (postupně, po jednotlivých úrovních). Alternativou je například způsob prvotního rozpadu dle životního cyklu vytváření produktu, a až poté rozpad na konkrétní výstupy (obr. 1).

Obr. 1: WBS může vypadat například takto
Obr. 1: WBS může vypadat například takto

Pro správnost sestavení je dobré dodržet zásady jako:

  • WBS na nejnižší úrovni obsahuje fyzicky předatelné výstupy (produkty) – výsledky práce.
  • Tyto pracovní balíky lze ocenit (práce nutná na jejich vytvoření, náklady, čas).
  • Zároveň se projektový tým pohybuje na přiměřené míře detailu, nikoli v příliš detailní nebo v příliš obecné rovině. Určitým kritériem pro určení hloubky rozpadu může být úvaha, zda je daný pracovní balík nezbytný a měl by být v každém případě nějak realizován. Například při nasazení nového softwaru by měli být uživatelé jistě proškoleni. Pracovní balík „Uživatelé proškoleni“ tedy do WBS nejspíš patří. Jakým způsobem to ale proběhne, již bude zřejmě jiná věc. Školení může probíhat u zákazníka, u dodavatele apod., někdo bude muset sezvat účastníky, zajistit občerstvení atd., to už jsou však detaily, které do WBS pravděpodobně nepatří – mohou se poměrně dynamicky měnit, aniž by to mělo na výsledek podstatný vliv.
  • Rozpracovanost pracovních balíků (nakolik jsou fyzicky dokončeny) a postup prací, jimiž budou výstupy vyprodukovány, jsou měřitelné.
  • K pracovním balíkům na nejnižší úrovni lze jednoznačně přiřadit zodpovědnost.
  • Popis pracovního balíku by měl vždy co nejpřesněji definovat příslušný výsledek. Nestačí nadepsat pracovní balík, například jako „Plán“, to umožňuje různé výklady (navržen, sestaven, proveden apod.). Vhodnější je například formulace „Plán schválen vedením pro realizaci“. Vždy je k předmětnému obsahu dobré doplnit alespoň sloveso ve vidu dokonavém a trpném rodu, které upřesní, co se s daným věcným obsahem má stát. Nejlepší formulace bývají takové, které přesně specifikují užitnou hodnotu pro přímého zákazníka daného pracovního balíku.

Ještě před vytvořením WBS je možné, a v některých případech vhodné, zpracovat slovní popis rozsahu projektu (scope statement). Informační potenciál samotné WBS je přeci jen omezen, a tak ve vhodných případech nelze než doporučit zhotovení samostatného popisného dokumentu o rozsahu projektu.

Když chceme mít věci opravdu pod kontrolou

Jako součást WBS je možné dále zpracovat popis pracovního balíku (WBS dictionary) s podrobnějším popisem konkrétního pracovního balíku. Takový popis je již významným vstupem do plánování projektu a může vypadat například tak, jak znázorňuje obrázek 2.

Obr. 2: Příklad popisu pracovního balíku
Obr. 2: Příklad popisu pracovního balíku


První část takto strukturovaného popisu pracovního balíku je určena především pro vedení projektu, případně řídící výbor. Obsahuje souhrn nejdůležitějších informací o pracovním balíku, tedy termíny, náklady a očekávaný výstup. Druhá část je zajímavá především pro plánování realizace daného pracovního balíku a dále nám poslouží jako vstup pro sestavení harmonogramu a rozpočtu. Poslední část umožňuje významně upřesnit zadání a očekávaní ohledně požadovaného výsledku.

Je zřejmé, že detailní definice pomocí popisu pracovního balíku je samozřejmě o dost náročnější, než jen zpracování WBS a následný rozpad na úkoly, které pravděpodobně bude potřeba splnit (což je samozřejmě také možné). Nicméně u složitějších pracovních balíků, obzvláště smluvně závazných, je rozhodně na místě takový pracovní balík popsat co nejpřesněji, včetně akceptačních kritérií a informací se vztahem ke smlouvě. Takovýto detailní popis je tím nejlepším prostředkem pro udržení změn pod kontrolou.

Příště

Po zpracování WBS již konkrétně a poměrně detailně víme, co vše má být v rámci projektu dodáno. V příštím dílu se tedy zaměříme na otázku, jak a za kolik by měla realizace onoho „co“ proběhnout.

Jan Doležal
Autor je ředitelem společnosti PM Consulting. Je držitelem certifikací PMI PMP a IPMA level B. Zabývá se především optimalizací systémů řízení projektů v různých firmách a organizacích.

 

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Helios
- inzerce -