google plus
Tematické sekce
 
Branžové sekce
Přehledy
Siemens SE zdarma (Indigoprint)
 
Tematické seriály

Dotace na vývoj ICT

Vývoj nových ICT řešení a ICT nástrojů je v dnešní době zásadní, ale finančně velice náročný proces.

1. až 2. díl >>

 

Komplexní svět eIDAS

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

1. až 6. díl >>

 

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...

1. až 5. díl >>

 

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é...

1. až 11. díl >>

 

Podnikové portály

Portály patří k oblíbeným technologiím, na kterých staví společnosti svá řešení. Ta jsou vstupní branou...

1. až 5. díl >>

 

Pokročilá analýza provozu datových sítí

V tomto čtyřdílném seriálu vás seznámíme s různými metodami a přístupy...

1. až 4. díl >>

 

Cesta k efektivnímu identity managementu

Správa identit a přístupů (IAM) je klíčová oblast pro zaručení bezpečnosti...

1. až 9. díl >>

IT SYSTEMS 12/2015 , Řízení projektů

Tipy a triky pro WBS: Jak správně poskládat šablonu projektu



WBSWBS projektu, tedy hierarchická struktura prací (Work Breakdown Structure), představuje jeden z nejčastěji užívaných akronymů v projektovém řízení. Na druhou stranu ne každý manažer projektu umí udělat WBSku správně. Přitom zvolená struktura členění prací na projektu vám může ušetřit nemálo času a starostí.

Soutěž - Trust (USB rozbočovač)

Jedno ze základních přikázání týkajících se projektového plánu říká, že projektový harmonogram musí být transparentní. Tato skutečnost fakticky znamená, že plán musí být pochopitelný nejen pro členy projektových týmů, ale i pro ostatní podílníky projektu. Pokud tomu tak není, pak se musíte v rámci řízení projektu připravit hned na několik nepříjemností:

  • Když něčemu nerozumím, tak se zeptám – první a paradoxně nejméně bolestivý důsledek špatně postaveného projektového plánu souvisí s neustálým dotazováním ve smyslu co tím chtěl básník vlastně říci. Uvědomte si, že jako manažeři projektu stojíte proti násobně větší přesile podílníků, kteří vás mohou připravit v součtu o nemálo času. A toho je vždy nedostatek. Obětovat své volno, nebo ukrojit z času plánovaného na faktické řízení, není možné donekonečna.
  • Když něco nechápu, tak to nečtu – mnozí členové týmu „trpí“ mnohdy až bezmeznou ochotou něco dobrého vykonat kombinovanou s vírou v sebe sama. Tento koktejl vás však snadno dostane do stavu, kdy v projektu dosáhnete výstupů, které zadavatel vůbec nepožadoval, v čase, který je neakceptovatelný a o nákladech ani nemluvě. A kárat svůj tým je v takové situaci hodně složité s ohledem na to, že s těmi samými lidmi budete podnikat i další projekty.
  • Když něco zkazím, řeknu, že jsem to špatně pochopil – třetí a nejhorší důsledek špatných projektových plánů představuje alibismus. Pokud svůj tým nemáte naladěný pozitivně, pak počítejte s tím, že jakýkoliv problém se budou snažit přenést na vás. Další smutnou skutečností pak je, že se o problému dozvíte pozdě – zpravidla až v okamžiku, kdy s ním nemůžete nic dělat.

Plán projektu tedy musí být transparentní a při WBS hraje při dosahování tohoto cíle klíčovou úlohu. Jedná se o proces, který dekomponuje komplexní cíl projektu na menší a uchopitelnější celky. A právě struktura těchto celků může zvýšit buď porozumění ze strany podílníků, nebo míru projektového chaosu. Tvorbu hierarchie projektového plánu postavte na ideálně na 3 základních rovinách: vhodně zvolte klíč WBS projektu, přizpůsobte rozsahy jednotlivých úrovní WBS a prostřednictvím zásad utužujte projektovou governance.

Stanovte a udržte klíč WBS

Základním stavebním kamenem pro proces dekompozice projektového cíle pomocí hierarchické struktury činností je stanovení tzv. WBS klíče. Rozklad projektu můžete provádět podle nejrůznějších hledisek, v praxi se však nejčastěji setkáte s přístupy odpovídající projektovému trojimperativu:

  • Produkt/objekt – toto hledisko rozkladu odpovídá struktuře jeho výstupu (Product Breakdown Structure). S tímto přístupem se setkáte v praxi často u projektů, jejichž výsledek je dobře popsatelný formou jasných požadavků. Výsledný seznam fází může vypadat např. jako seznam modulů dodávky.
  • Čas – časový rozklad projektu je nejčastěji používá u agilních projektů, nebo pro projekty související s IT Release managementem. Fázování projektu dle času je pak tvořeno jednotlivými sprinty, nebo releasy.
  • Náklady/zdroje – toto členění je pak časté u projektů, kde prim hrají externí zdroje – a to jak finanční, tak i pracovní. Struktura projektu plánovaného přes tuto rovinu trojimperativu tak může vypadat např. Práce – firma 1, Práce – firma 2 apod.

Nepochybně přijdete i na další možné varianty toho, jakým klíčem lze projekt rozkládat. To však není z pohledu tohoto článku podstatné. Mnohem závažnější je fakt, že zvolený klíč (ať už ho definujete jakkoliv) musíte na dané úrovni osnovy (viz dále) udržet po celou dobu rozkladu projektu. Každá změna klíče WBS tedy musí vést k provedení kontroly a případné realizaci nového rozkladu.

Definujte poslání jednotlivých úrovní WBS

V praxi zpravidla budete řešit projekty, které bude třeba rozložit do menších celků ve víceúrovňové hierarchii. Ta se odborně nazývá osnova projektu. Kromě toho, že pro jednotlivé úrovně hierarchie platí pravidlo dodržení jednotného klíče WBS, je vhodné myslet při rozkladu také na účel jednotlivých úrovní:

  • Manažerská úroveň osnovy – první úroveň osnovy je vyhrazená manažerskému reportingu. Pro komplexní projekty může být do manažerského reportingu zahrnuto i více úrovní, nicméně je vhodné udržovat počet fází cca do 10 řádků tak, aby se přehled projektu vešel s rezervou na 1 slide prezentace. Management pracuje s touto úrovní pro získání rychlého přehledu o projektu.
  • Projektová úroveň osnovy – fázování na druhé nejvyšší úrovni slouží projektovému týmu jako základní orientační pomůcka. Pro zajištění přesné a rychlé navigace je vhodné, aby počet řádků této úrovně nepřesáhl 30. Pomocným měřítkem může být 1 stránka A4 na šířku, nebo 1 obrazovka počítače. Tato úroveň je základem pro Project Status Report.
  • Operativní úrovně osnovy – další úrovně osnovy jsou definovány s ohledem na specifické potřeby projektu a podílníků. Mohou být uzpůsobeny např. pro tisk konkrétních částí, nebo sdružovat práci vykonávanou jednotlivými týmy apod. Co do počtu lze doporučit jako hranici vymezení max. 10 operativních úrovní na 1 projektovou úroveň.

Každá z úrovní osnov v rámci projektové WBS by také měla směřovat „odněkud někam“. Čím zřetelněji je tato cesta naznačena, tím stoupá schopnost podílníků projektu se v plánu zorientovat svépomocí. Je tedy vhodné, abyste jim rozpad každé z fází naservírovali identicky. Ideálem takové struktury je milník – souhrnný úkol 1, souhrnný úkol 2, souhrnný úkol X – milník. Tento princip je dobře patrný na obrázku.

Obr. 1: Ukázka šablony WBS vytvořené v aplikaci Microsoft Project
Obr. 1: Ukázka šablony WBS vytvořené v aplikaci Microsoft Project


Použijte WBS jako základ projektové Governance

Poslední ze základních oblastí souvisejících s tvorbou hierarchie projektu pak představuje manažerské využití WBS. Tak jako plán projektu, i WBS přeci tvoříte ne proto, že ji někdo požaduje, ale především proto, abyste na jejím základě mohli efektivně řídit projekt. Následující doporučení související s WBS vám pomohou zvýšit projektovou kulturu vaší organizace:

  • Specifikace požadovaných výstupů – výstupem každé z hierarchicky uspořádaných fází může být buď dílčí produkt, nebo provedení spektra činností. O způsobech, jakými je požadováno referovat o dosažených výsledcích, se mohou podílníci dočíst např. z poznámek připojených ke každé fázi WBS. buď díl
  • Kontrola plánovacího detailu – v kontextu řízení projektů dle metodiky platné pro vaší organizaci, lze na základě sestavené WBS snadno ověřovat dodržení maximálního povoleného rozsahu fází projektu. Obecně lze konstatovat, že fáze na projektové a operativní úrovni s rozsahem nad 100 dní trvání, nad 100 člověkodní práce není snadno řiditelná a je vhodné, abyste jí rozdělili. A moderní nástroje umožňují zvolený detail kontrolovat pomocí vlastních indikátorů (viz obrázek)
  • Řízení toku projektu – v současné praxi se nezřídka setkáte s harmonogramy, které nemají jednoznačně identifikovanou posloupnost činností, nebo jí mají velmi složitou. Vazby mířící přes 20 a více řádků zpravidla nikomu nic neřeknou a tým spíše matou. Strukturu WBS lze tedy snadno využít také z pohledu definice vzájemných závislostí, které vymezují vazby mezi celky předtím, než budou propojeny jednotlivé úkoly projektu.

Pokud se vám podaří v rámci organizace standardizovat WBS pro jednotlivé typy projektů, pak pokládáte základ pro standardizovaný a automatizovaný reportingů stavu a průběhu projektů v portfoliu. To v konečném důsledku šetří váš čas i čas pracovníků projektové kanceláře, či controllingu nad rámec úspor naznačených v úvodu tohoto textu.

Ing. Drahoslav Dvořák, Ph.D., Mainstream technologies Drahoslav Dvořák
Autor článku řídí divizi Enterprise Project Management ve společnosti Mainstream Technologies, kde realizuje implementační projekty Projektových kanceláří a IT podpory projektového řízení. Dále přednáší Řízení projektů a Podnikovou informatiku na Vysoké škole Škody Auto v Mladé Boleslavi. Je certifikovaným projektovým manažerem (PMP) a jediným specialistou Microsoft Most Valuable Professional pro oblst Projectu v ČR.
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.


Inzerce

OR-SYSTEM ve výrobě se stal v SAPELI základem výroby řízené zákazníkem

SapeliAkciová společnost SAPELI je největší výrobce dveří a zárubní v České republice. Úspěch staví na inovacích, špičkovém designu, precizní kvalitě, zakázkové výrobě a exportu na náročné trhy Rakouska, Německa, Slovenska, Maďarska a dalších zemí.