Projekty a metodiky

Možná to nezdravě zjednodušuji. Zabývám se řízením projektů už hodně dlouho a zatím se nikdy nic složitého neuplatnilo. Většinou je obtížné prosadit i ty nejjednodušší principy. Např.

• Jediný zodpovědný vedoucí.
• Nedělitelná zodpovědnost.
• Zpětná vazba.

Tyto naprosto základní principy řízení bezstarostně ignorujeme. Navíc často vycházíme z "vlastní" interpretace "projektů" (vytrháváme fragmenty z kontextu). Občas se snažíme nepatřičně řídit zakázky jako projekty - aniž to jsou skutečné projekty (tedy unikátní plnění). Nevidím prostor to dál komplikovat. Nejdřív základy, potom můžeme hledat báječné muže na létajících strojích.

Nechci jen poukazovat na chyby - na konci je to rozvedeno - základní doporučení je:

• Získat co nejvíce znalostí a dovedností (najít interního člověka pro strategický rozvoj - plný outsourcing správy projektového portfolia není reálný).
• Přestat ignorovat principy (dělat nesmysly) - potřebujete projektovou kancelář a projekty musí řídit kompetentní vedoucí. Pravidla + vymáhat/dodržovat.
• Systém/proces projektového řízení zdokonalovat (rozvíjet vlastní metodiku).

Reinkarnujeme školu projektového řízení.

Obvyklý přístup

Není jisté, jak moc reprezentativní jsou naše zkušenosti. Ovšem podivné návody, doporučení a koncepty, které různí rádoby experti šíří, spíše dosvědčují, jak zoufale projekty nezvládáme (jelikož jsme ochotni věnovat pozornost hodně obskurním nesmyslům). Typické omyly:

• Člověk, kterému říkáme "projektový manažer" nemá ani potřebné dovednosti, ani nezbytné "pravomoci" (pravidla nastavená tak, aby ostatní spolupracovníci měli povinnost při splnění daných podmínek dělat to, co je potřeba).
  Mimochodem toto je velmi obecný a rozšířený defekt nejen v projektovém řízení.
• Na to navazuje logicky to, že neexistuje přijatelně kvalitní plán práce. Navíc se plošně odkývává to, že vlastně nemá cenu dělat plán práce, protože neumíme přesně říci, co se bude dít ve vzdálenějších etapách a nakonec to stejně bude jinak. Takže uděláme jen jakýsi zcela formální rámec. Ten samozřejmě nemá smysl ani není možné upřesňovat.
  Což je porušení elementárních principů.
• Nepoužíváme odpovídající nástroje, takže je prakticky nemožné systematicky řídit zdroje. Neumíme zadávat úkoly (koordinovat práci, už vůbec neumíme stavět práci podle zdrojů), tedy ani vyhodnotit výsledky. Rezignujeme na akceptace (sjednání akceptačních kritérií & testů a jejich provádění). Neumíme řídit nejistotu (rezervy & odchylky) ani rizika.
  Což je ignorování elementární logiky.
• Neumíme oddělit projekt od projektového záměru. Čož je zásadní překážka pro stanovení limitů (samostatně).
  Což je fatální selhání.

Naprosté popření podstaty projektového řízení.

Ale ten hlavní problém je to, že jsme - vlastně celkem logicky v důsledku výše uvedených dílčích deformací - sami sobě povolili se obelhávat tím, že se projekt v průběhu své realizace nemá měnit. A na to jsme ochotni se donekonečna vymlouvat. Argumentovat tím, jak zadavatel na začátku neví, co chce... Jasně, že neví.

Zadavatel a projektový záměr

Na poradenských a podobných projektech je to průzračné. Zadavatel z logiky věci nemůže vědět, co má být výsledkem jakékoli akce. Na začátku to neví nikdo. Je potřeba zjistit, prověřit a promyslet spoustu věcí, najít závislosti, prostě nejdřív si ujasnit, v jakém stavu daná organizace je a poměrně namáhavě sjednat (vymezit - obvykle minimální) potřebné změny.

• Nikoli v podobě výstupů akce (projektu), ale výsledků na úrovni záměru. Co se má změnit v důsledku využití výstupů projektu.
• Teprve potom lze začít hledat vhodnou podobu toho, co je potřeba dělat, aby žádoucích změn bylo dosaženo.

Je legitimní se zeptat, jak se dohodnout s případným externím dodavatelem, pokud nemáme jasno v tom, co a jak se musí udělat. Pokud máme, je to práce ve mzdě a to je trošku jiná problematika (jak si sjednat a zapojit specialisty na správné úrovni). 

Když se nad tím zamyslíte, stejný princip funguje i u jiných typů projektů. Když vyvíjíte nový produkt, tak také je potřeba nejdřív průzkum a analýza trhu (budoucích potřeb budoucích zákazníků), potom rámcová specifikace vlastností (která se musí neustále upřesňovat a obvykle bude zahrnovat i požadavek na úroveň adaptability pro očekávanou dynamiku potřeb, které má produkt uspokojovat). Teprve potom se dá začít vymýšlet ten inovativní zázrak.

Vzhledem k nesprávnému pochopení / použití metod projektového řízení, nejspíše zejména pod vlivem snahy korporací označovat nákupy jako "projekt", došlo k tomu, že se zadavatel snaží s realizátorem předem dohodnout na výstupech projektu, aniž k tomu má potřebné znalosti a informace. Vychází z obvyklých principů funkčně řízené organizace a snaží se přesně definovat, co má být výsledkem - tím se zbavit zodpovědnosti (potažmo té účasti). Neochota dodavatelů přebírat zodpovědnost (nebo nastavit korektně podmínky spolupráce) za dosažení skutečných cílů (nikoli výstupů) vede nakonec k velmi vágně nastaveným pravidlům, což pochopitelně škodí oběma stranám.

Zadavatel nese zásadní díl zodpovědnosti za výsledek projektu.

A tuto roli musí naplnit (odpracovat) především v průběhu realizace projektu. Není rozumné "ukončit" projekt dřív, než je ověřeno, že to, co se vytvořilo, "funguje" (tedy přináší očekávaný užitek). Což je zásadní doporučení pro nastavení hranic projektu.

Tradiční přístup

Je jasné, že když je potřeba prodat nový hrnec, musí se najít dost důvodů, proč se má ten starý vyhodit. V průběhu času se díky intenzívní snaze konzultantů i samotných projektových manažerů výrazně zdeformovaly klíčové principy projektového řízení. Standardně se ovšem řízení projektu zabývá (má zabývat):

• Řízením odchylek = systematická aktualizace plánu prací. Viz výše.
  Moc práce.
  Nechce se nám. Tak to neděláme - máme špatný plán vedoucí k nekorektně definovaným (či vůbec nedefinovaným) výstupům. Protože jsme "dokázali" sjednat, že se bude hodnotit to, co je naplánováno, nezajímá nás nic moc jiného, než dodržet, co je popsáno. Každá případná změna plánu je "katastrofa". Takže je neděláme. Patláme páté přes deváté a doufáme, že to "nějak dopadne".
  • Primární aktualizace požadavků na výstupy (úpravy akceptačních testů).
  • Z toho vyplývají změny postupu.
  • Ty jsou vyvolávány i neočekávanými překážkami či změnami podmínek.
• Spoustou dalších aktivit. Smyslem je zvládání nejistoty, která je podstatou projektů. Děláme něco jedinečného. Na začátku nevíme přesně vůbec nic. Jenom to, že to téměř jistě bude jinak, než si nyní umíme představit.
  Dá se něco takového zvládnout jinak, než agilně?

Zjednodušeně řečeno - pokud nezapojíme zdravý rozum, nebude fungovat téměř nic.

Agilní přístup

Na toto téma určitě samostatná úvaha (viz též diskuse na LI). Zde pouze velmi zjednodušeně - pokud něčemu z doporučovaných postupů nerozumím, je potřeba to tak dlouho ověřovat a zkoušet, dokud si nejsme jisti, že chápeme všechna úskalí a podmínky.

Primární "problém" agility je, že je to buzzword. Móda. Zaklínadlo.

Víme, co to znamená? Co konkrétně je jinak, než velí zdravý rozum (pokud je to krycí název pro "dělejme to pořádně", tak je všechno v pořádku). Takže čím by se měl "agilní" přístup dle dostupných zdrojů vyznačovat.

• Efektivní komunikace a spolupráce.
  Což je moc pěkné. Ale nejspíš to není nic, co by bylo možné a potřebné jen v "agilním" prostředí. Není zřejmé, čím konkrétně to "agilita" umožní/zajistí. Velmi ošidné je v tomto kontextu zavrhování procesů a nástrojů (resp. to nedává smysl, protože efektivnější komunikace lze dosáhnout jen lepšími pravidly - je šílenství spoléhat na ukázněnost, dobrou vůli a samovolné sjednocení přístupu všech účastníků).
• Soustředit se na výstup.
  Platí to stejné. A stejně je sporné, jak moc pomůže zavržení plánování a dokumentace tomu, aby co nejdříve a co nejefektivněji vzniklo to, co má uspokojit potřeby zadavatele. Dle zdravého rozumu je to naopak - abychom získali to, co potřebujeme, musíme intenzívně upřesňovat, co to má být a co musíme dělat. Tady se dělají největší chyby - jelikož chybí formalizovaná specifikace a akceptační kritéria, tak se "dohody" o tom, co je potřeba "jinak", zapisují do záznamu z jednání... a mizí v propadlišti dějin. 
• Účast zadavatele.
  Viz výše. Stejně jako u předchozích deklarací se spoléhá na (samovolné) aktivní, vstřícné a kvalifikované zapojení zadavatele. Prostředkem k tomu má být rezignace na jednání ("contract negotiation"). Pokud se nepodaří vysvětlit/dohodnout, jak projekt bude probíhat, stejně se nic nekoná. Jistě, pro mnohé by bylo ideální pracovat beze smlouvy, pokud jsou placeni od hodiny. Ovšem pokud rozumný zadavatel chce platit jen za získaný užitek, nějakou smlouvu a pravidla spolupráce potřebujeme. Fakticky o dost náročnější, než při sjednávání spolupráce na tradičním půdorysu - protože bezpochyby se doba i charakter projektů a spolupráce mění.
• Flexibilita.
  Výstupu i postupu. Podstata projektového řízení. Zde bezpochyby platí, že nemá smysl se snažit dodržovat neplatný (neaktualizovaný) plán práce. To by dělal jen šílenec (byť je to obvyklý stav). Pracovat bez plánu také moc nedává smysl. Pokud máme rozhodovat o podobě/přijetí změn, potřebujeme co nejlepší představu o možnostech dalšího postupu (důsledcích).
  Tady by se hodila možnost alternativních scénářů, abychom ty důsledky mohli vyhodnotit, ale to většinou systémy pro podporu řízení projektů... No nevím, nebude to spíš tak, že je tímto způsobem neumíme používat?

No prostě tomu nerozumím. Taky chybí doporučení, jak těchto "světlých zítřků" dosáhnout. Významná část akcí, které se označovaly za "agilní", byly prostým a bezbřehým (občas bezcílným) blouděním v režimu pokus-omyl, aniž by někdo vynaložil potřebné úsilí na zjištění skutečných (budoucích) potřeb.

Rozhodně výše uvedené neznamená, že bych popíral či zpochybňoval užitečnost či spíše nezbytnost "agilního" přístupu. Spíš jsou to rozpaky nad tím, proč tyto samozřejmosti vydávat za cosi převratného. Navíc mě trápí následující podezření.

• Jestli už samotný "pokus-omyl" není jen "legitimizace" toho, že neumíme zjistit, co je doopravdy potřeba (možná samostatně, viz způsobilost zadavatele). Rezignace na chybějící kompetence (analýzu potřeb, správu požadavků, ...).
• Jestli chaos v tom, co kdo kdy má udělat (pozor, mluvíme o projektech obecně, nikoli pouze o vývoji software, kde se občas najde někdo osvícený), není zástěrka pro neochotu těch, kdo by měli projekty řídit, věnovat se práci s lidmi - s "alibi", že díky "agilnímu" přístupu musí všechno fungovat "samo".

Ono "řídit projekt" znamená totiž korektně a důsledně projednávat/přijímat změny jak v požadavcích na výstupy, tak v podmínkách realizace, což nezbytně vyžaduje úpravy jak specifikací (a akceptačních testů), tak plánu prací. Účelně vytvářet a využívat rezervy. To se bez součinnosti s členy projektového týmu zvládnou nedá.

Hybridní

Tak to je na mě trošku moc. Údajně má jít o to, že celek se naplánuje "přesně" a jednotlivé práce se budou porovádět "agilně". To mi hlava nebere. Ale asi se k tomu ještě vrátíme.

Zjednodušeně - nedělejte nesmysly ve jménu "metodik".

Rozumný přístup

Projekt je nutno řídit. Dělat to, co (nejvíce) zvyšuje pravděpodobnost získání potřebného užitku v definovaném čase a s limitovanými zdroji. Co se týče metodik - jedno nepohodlné, ale osvědčené doporučení

• Najděte způsob, jak vybudovat projektovou kancelář.
• Získejte z dostupných zdrojů co nejvíce informací.
• Vytvořte si vlastní metodiku. Na začátek ("agilně") nejjednodušší, jakou dokážete. Pozor - vytvořit něco "jednoduchého" je většinou násobně náročnější, než když pejsek s kočičkou pekli dort.

Dost často se stává, že díky počátečnímu nadšení a nedostatku zkušeností člověk navrhne něco, co by (teoreticky) mělo skvěle fungovat, ale v praxi to selhává. Není dobré snažit se to opravit, pokud není jasné, který předpoklad je nesprávný. Většinou naivně věříme, že se některé činnosti udělají "samy" nebo že se "z ničeho" dá vytvořit "něco". Např.

• Není potřeba specifikace / akceptační kritéria. Vždyť pracujeme "agilně"...
• Není potřeba plán práce... [dá moc práce, nedá se udělat].
• Projektový manažer zajistí splnění projektového trojimperativu (výstup, čas, peníze)...
  ...bez specifikace a plánu práce...
• Nejoblíbenější: "Není čas plánovat, je potřeba dělat..."
  Autentický citát z projektu s dopady v řádu desítek miliónů příspěvku na krytí.