Projekty a jejich řízení

Na základě aktuálního implementace MS Project Online do jedné projektové kanceláře. Taky tak trošku coby základ reinkarnace školy projektového řízení.

Organizace a projekty

Některé organizace se snaží uplatnit principy projektového řízení v běžném provozu. Např. pro řízení zakázek. Zakázky jsou vždy proces. Jejich jednotlivé instance či části mohou mít charakter projektů - např. jedinečné stavby. Ovšem výroba turbíny, byť unikátní, téměř jistě nemá být řízena jako "projekt" (i když pro konstrukci či instalaci je to správné a výhodné). Prostě je potřeba používat nástroje k účelům, ke kterým jsou určeny. Procesy jsou pro běžné činnosti vždy vhodnější.

Pokud chcete zvládnout víc než jeden běžící projekt, potřebujete proces - pravidla, jak mají být projekty řízeny. Projektovou kancelář. Pro řízení projektů musíte vybudovat systém projektového řízení a přesně nastavit povinnosti lidí - nejen těch uvnitř projektu/-ů, ale zejména těch kolem. Nespoléhejte na žádné "zázračné" metodiky, rozumná cesta je budovat vlastní.

Bez procesů projekty nefungují.

Někdy může řízení zakázek pomocí projektů vypadat jako dobrý nápad, neznám však žádnou organizaci, ve které by se v provozním režimu efektivně používal systém řízení projektů. Byť by to byla stavební firma, ve které něco takového má bezpochyby opodstatnění. V jedné jsme byli nuceni se o to pokusit - ambicí bylo sdílení vzácných zdrojů, ale nedopadlo to - nepodařilo se přinutit vedoucí staveb, aby udržovali plány prací aktuální. Pokud něco takového budete chtít zkusit, je potřeba mít k dispozici velmi důkladné znalosti a rozsáhlé zkušenosti z obou oblastí a odpovídající technologie. I tak to bude chůze po ostří nože.

Metodika - pravidla

Je potřeba počítat s tím, že samo to fungovat nebude - potřebujete striktní metodiku - povinnosti. A sílu a vůli (a podmínky) na jejich vymáhání. Činnosti/lidé z obou oblastí (projekty × provoz/procesy) soutěží o stejné zdroje. Co není zakázáno, je dovoleno. Je potřeba zabránit bratrovražedné válce.

Projektové řízení je z logiky věci poměrně náročné - což vychází z podstaty projektů. Snažíme se řídit něco jedinečného, mimořádného. Něco, s čím máme jen omezené zkušenosti. Nemáme jistotu, co dopadne podle předpokladů a co jinak. Vlastně máme jistotu, že zcela jistě nepůjde vše podle plánu. Po prvním střetu s realitou buď bude jinak všechno, nebo budeme muset dostat "vlak zpátky na koleje". Možná na "vedlejší kolej", protože tahle už dál nevede.

Je zbytečné (nesprávné) používat nástroj, který je vybaven na zvládání mimořádných aktivit, na něco, co se ve své podstatě opakuje (proces). Projekt nepomůže. Pokud potřebujete zajistit např. optimální využití vzácného zdroje (zařízení nebo jiné kapacity, kterou není snadné získat) v běžném provozu, má přednost provozní efektivnost (výsledky celé organizace, nikoli lokální optimum). To je nutno zvládnout na procesní úrovni nebo úplně všechno ve firmě řídit projektově (což je naprostý nesmysl).

Musíte:

• Dělat to, co se dělá u projektů - plánovat. Ale proto to není projekt.
• Chápat plánování jako řídící proces pro uspořádání instancí (zakázek / aktivit). 
• Nastavit pravidla - ale trošku jinak, než v případě systému projektového řízení (správy projektového portfolia a jeho zdrojů).

Aneb pokud potřebujete sdílet zdroje (lidi, technologie) mezi provozem a projekty, musíte mít sdílený systém řízení zdrojů (byť by se dalo diskutovat o tom, že se to dá "nějak" zvládnout jinak, v praxi platí Murphy - co se může pokazit…).

Na co se projekt hodí

Když máte to, co odpovídá definici - mimořádná aktivita, směřující k nepříliš jistému, avšak důležitému cíli (v oblasti dopadů, ovšem ani výstup není 100% jistý), není proč váhat. Např.

• Vývoj nového produktu.
• Marketingová kampaň (nikoli "inovovat web").
• Firemní reorganizace, akvizice či sloučení, expanze na nový trh.
• Nasazení nového informačního systému.
• Každý strategický cíl představuje (měl by být formulován jako) projektový záměr = jeden nebo více projektů.

Potřebujete:

• Schopného vedoucího projektu (jaké dovednosti musí mít a jak má pracovat, je dlouhá diskuse bez jednoznačných závěrů). Striktní správa / vyčlenění zdrojů.
• MBO pro sjednávání práce (ideálně systém pro podporu projektového řízení).
• Detailní plán práce + systém řízení rizik, výstupů, problémů, času a peněz (což je součástí systému pro podporu projektového řízení). Míra detailu je kritický faktor a samostatné téma. Pokud nebude plán prací (rozumí se pro aktuálně realizované činnosti) na nezbytné úrovni (což závisí na tom, jestli jsou ve hře sdílené/nejisté zdroje), je celem zbytečně si namlouvat, že projekt řídíte.

Kdy se "projekt" hodí méně (přestože to z důvodu chybějící organizace/řízení kapacit & plánování výroby vypadá, že by mohl pomáhat):

• Zakázková výroba.
  • Výstup je jednoznačně definovaný a o jeho užitečnosti není pochyby.
  • Lidé své úkoly nemusí plnit samostatně, provádějí relativně jednoduché (známé) pracovní úkony podle nastavených pravidel.
  • Všechny činnosti, které mají být pro dodání zakázky provedeny, jsou definovány v procesním modelu (a pokud tam něco chybí, tak je účelné to tam doplnit, i kdyby se to mělo použít "jen na této zakázce").
• Vývoj software.

Co využití projektového přístupu brání:

• Lidé jsou ochotni vést projekty jen díky tomu, že o projektovém řízení vůbec nic neví (sarkasmus - reálně absence skutečných vedoucích projektů; velmi sporné téma, nakolik musí být vedoucí projektu schopen jednat o výstupech ~ samostatně).
• Nedokážeme závazně alokovat konkétní kapacitu na činnosti projektu.
• Neumíme definovat/sjednat výstupy (technické specifikace a/nebo akceptační kritéria). A už vůbec nechápeme, že se budou v průběhu projektu měnit.
• Nerespektujeme pravidlo mít pouze jeden výstup na jednu činnost (adresnost a nutný detail).
• Dohody jsou (v lepším případě) zaznamenávány v zápisech z jednání, které jsou navíc na takové úrovni, že ani jejich autor většinou není druhý den schopen interpretovat jejich obsah/význam (najít, co je potřeba).
• Změny (výstupů, průběhu prací) jsou uvedeny pouze v zápisech z jednání. Čím se stávají nedohledatelné a neprůkazné.
• Místo akceptačních testů se provádí "převzetí".
• Tváříme se, že dohoda o tom, že je opravdu potřeba, aby tamten kus fungoval nejpozději v září, je úkol. Za splnění má zodpovídat někdo, kdo nemůže dostatečně ovlivnit dostupnost zdrojů nebo hůř vůbec neví, co a jak je potřeba udělat.

Podstata projektů

Nerutinní aktivity (posloupnost činností směřujících k cíli - všichni to známe). K čemu je vlastně dobré definovat pojmy? Zkrátka proto, abychom mluvili o tom stejném. Proto je dost důležité vědět, jaké jsou obvyklé významy a pokud se někdo snaží základní pojmy překroutit nebo využívat jinak, je to velice podezřelé a nepraktické. Pozor, standardní význam nemusí být to, jak problém chápete vy. 

Je velmi užitečné jako projekt označovat takové aktivity, které skutečně projekty jsou. Poznáte je snadno: 

• Jedinečné zadání a výsledky.
• Nejistota (v průběhu, nikoli až tak moc ve výstupech).
• Předem neznámá spotřeba zdrojů. 
• Většina úkonů je jedinečná a nevratná.

Pro jejich řízení potřebujete určitou úroveň znalostí a dovedností - nejen při plánování a usměrňování práce, ale především musíte mít způsobilost pro vedení týmů, vedení jednání/schůzek, řízení pomocí cílů (zadávání úkolů a dohled nad jejich plněním) a řadu dalších oblastí. Nic z toho není jaderná fyzika, ovšem obvyklá úroveň je spíše nedostačující. 

Projekt se řídí od výstupů

Každý projekt musí mít projektový záměr. Ten definuje důvod, proč chceme získat ty výstupy, které má projekt přinést - definuje jejich použití / užitečnost. Tím také definuje limity času a zdrojů, které pro jejich získání lze spotřebovat. Techniky plánování a určování míry spolehlivosti jsou samostatným tématem - řízení rezerv je v projektovém řízení pravděpodobně nejvíce opomíjenou, přitom kriticky důležitou dovedností.

• Výstup doručí konkrétní činnost projektu (obvykle etapa - složená činnost). Nemůže vzniknout sám od sebe. Je rozumné sjednat a akceptovat i mezivýstupy.
• Jedna činnost může mít jenom jeden výstup. Pokud při jedné činnosti musí vznikat více výstupů (např. aplikace a její dokumentace/návody k použití), tak se nejedná o více výstupů, ale jeden složený. U složeného výstupu nemá jedna jeho část bez druhé smysl. Na každou část může či by měl být samostatný akceptační test.
• Činnost skončí až tehdy, kdy doručí svůj výstup.
• Definici výstupu lze měnit pouze změnovým řízením, které ověřuje přijatelnost nové verze výstupu z hlediska záměru (ten musí definovat škály, dle kterých lze měnit parametry výstupů a vztah k užitkům, které budou schopny vytvářet).
• To stejné (změnové řízení) platí pro situaci, kdy plán prací vyčerpává všechny dříve nastavené či získané rezervy v čase a penězích.

Všechno, co platí pro výstupy a akceptace, se týká "změn". Má to různá označení - issues, problémy, odchylky aj. Ve skutečnosti jde o správné úpravy plánu prací. Transparentní dohody změn specifikací a akceptačních kritérií. Navazující aktualizace termínů a rozpočtu.

Nejistota a rezervy

Nejistota je podstatou projektů. Děláme něco, co má přinést jedinečný výsledek. Něco, co tu ještě nebylo. Není zcela jisté, jak postupovat, takže ani nemůže být jisté, kolik to spotřebuje práce a ostatních zdrojů. Pokud musíme jít do nejisoty (to u projektů vždy), jsou rezervy povinné. Snažíme se je ovšem využívat, nikoli vyplýtvat.

• Nade vši rozumnou pochybnost musí být rezervy explicitně vyjádřeny. Musí být plánovány. A jejich spotřeba řízena. Zní to šíleně, že ano? Vychází se z limitů. Normativ podle typu projektu stanoví, jaká je povinná úroveň rezerv. Pokud se plán prací do určeného prostoru nevejde, je nutno změnit projekt nebo záměr (limity).
• Jednotlivé činnosti nesmějí mít ve svém odhadu žádné rezervy - musí být plánovány tak přesně, jak aktuální znalost problematiky umožňuje. Proto bude (vzhledem k pracnosti a výskytu nepředpokládaných komplikací) polovina plánovaných činností skončit před původně stanovenou lhůtou a polovina po ní. Dle normálního rozdělení. Viz TOC - Kritický řetěz.
• Úroveň plánovaných rezerv se přepočítá po skončení etapy, popř. po každé činnosti. Pokud se změnila, je nutno analyzovat příčiny a vyhodnotit, jak se projekt bude vyvíjet dál. Pokud hrozí nesplnění limitů, je potřeba projekt zastavit.
• Analogicky spotřeba zdrojů (materiálních i finančních).

Pokud by byla rezerva skrytá v činnosti, zákonitě musí být vyplýtvána. Pokud v činnosti žádná rezerva není, měl by příčetný realizátor začít na úkolu pracovat hned, jak to bude možné a snažit se jej dokončit co nejdřív (jak lidi stimulovat k tomuto chování samostatně). 

Elementární pravidla

• Pokud není možno definovat jasný výstup (specifikaci, akceptační kritéria), je nutno sjednat pouze tu část celkové aktivity, kde jednoznačné požadavky formulovat lze.
  Jinými slovy - když nevíme, co chceme, nemá smysl to schovávat za "agilitu" či cokoli jiného. Stačí to přiznat a připustit, že je rozumné nejdřív si to ujasnit. Může být, že si myslíme, že to víme, ovšem nejsme schopni definovat ani jednoznačný projektový záměr, natož akceptační kritéria. 
• Za každou činnost a její výstup někdo zodpovídá. Elementární činnosti musí být přiděleny realizátorovi. Složené činnosti mohou a nemusí být přiděleny některému ze specialistů (ten má potom pro tuto činnost veškeré povinnosti projektového manažera a nikdo mu do jejího řízení nesmí zasahovat - fakticky se jedná o podřízený projekt). Když není nikdo explicitně definován (měl by být), zodpovídá projektový manažer.
• Je potřeba správně nastavit činnosti, u kterých je potřebná součinnost více lidí.
• Trvání a další náležitosti určuje realizátor (nelze nařídit direktivně).

Bude jich víc, budou přibývat a budou se upřesňovat.

Rizika nejsou nejistota

To, že projekt nebude probíhat podle plánu, je jisté. S nejistotou se vypořádáváme pomocí rezerv. Jako rizika bychom měli chápat předem známé hrozby, které mohou a nemusí nastat.

[Předběžná verze - úvodní článek série - bude dokončeno.]