Existují heuristické postupy, jak slabě strukturovaný projekt zvládnout. Vyžadují však aplikovat při řízení jiné zásady než ty, které metodické standardy označují jako „osvědčená praxe“. Pokud nejste ve schématu modelové situace, začnete ve skutečnosti provádět zaručeně „správnými postupy“ zcela „nesprávné věci“ a dočkáte se jen zklamání, která nejlépe vystihuje slogan „skutek utek“.

Otevřený systém projektového trojimperativu

Kde je příčina problému klasických metod projektového řízení? V klasickém pojetí je projekt uzavřen do tzv. projektového trojimperativu čas – náklady – požadavky (resp. kvalita). Máte-li na projektu zadán čas, do kdy máte řešení vytvořit, a náklady, jaké můžete čerpat, pak je potřeba v trojimperativu rovněž pečlivě vybalancovat, jaké jsou k tomu přiměřené požadavky na řešení. A ty nejsou u slabě strukturovaných projektů známy. Alespoň ne v době, kdy se nastavuje a balancuje rovnováha vrcholů trojimperativu. Osvědčená praxe nás v tomto případě sama nedovede k úspěchu a zavede nás do patové situace, kdy není jasné, jak dále. Postup se stane podobným metodě pokusů a omylů.

Jak na slabě strukturované projekty?

Přístupy potřebné pro uřízení slabě strukturovaných projektů se opírají o zkušenosti a heuristický přístup „zdravého rozumu“, přičemž slabá strukturovanost a nejistota je dána neznalostí požadavků na řešení. Praktická doporučení pro uřízení slabě strukturovaných projektů jsou koncentrována do následujících principů, které si v dalším textu blíže představíme:

• Definujte smysl a hodnotu projektu v intervalu „nejhůře až nejlépe“.
• Orientujte se na příležitosti, ne jen na rizika.
• Hledejte „nevyřčené požadavky“.
• Konfliktní požadavky řešte ihned.
• Kombinujte metody shora–dolů a zdola–nahoru.
• Validujte, kde jen je to možné, namísto verifikace.
• Nastavte životní cyklus projektu tak, aby se k výsledku iterovalo (přibližovalo).
• Do životního cyklu zařaďte rozhodovací brány.

Definujte smysl a hodnotu projektu v intervalu „nejhůře až nejlépe“

Základním smyslem každého projektu je vytvořit hodnotu pro zainteresované strany. Hodnota je kontextově specifická a usuzuje se na ni z rozdílu mezi očekávanými přínosy, které vzniknou po ukončení projektu využíváním výsledku projektu, a vynaloženým úsilím na dosažení tohoto výsledku. Potíž je v tom, že hodnota je často postavena na nehmotných aktivech, jakým je třeba zlepšení renomé na trhu či zvýšení loajality zákazníků. Příkladem mohou být očekávání od projektu vývoje systému šitého na míru. Rozhodnutí o vývoji systému na míru má zpravidla smysl, pokud v dané společnosti existují kritické procesy, které se výrazně liší od standardního způsobu jejich provádění a jsou tzv. měkké, tj. ovlivňuje je řada těžce uchopitelných faktorů. Do těchto procesů patří například znalostně-intenzivní proces výzkumu a vývoje. Přechod na dobrou strukturovanost zadání projektu je třeba nalézt ve správné identifikaci unikátních kritických procesů a jejich optimalizace na chtěný stav před jejich fixací systémem. Nejsou-li na začátku projektu procesy známy, osvědčuje se pracovat se scénářem pro hodnotu projektu v intervalu „nejhůře až nejlépe“. Znamená to určit, jaká je nejhorší přípustná varianta naplnění očekávání, předpokládaná hodnota a optimistická hodnota. Při řízení rozsahu projektu se pak pracuje s předpokládanou hodnotou projektu, ze které se stanovují cíle projektu.

Orientujte se na příležitosti, ne jen na rizika

Rizika zpravidla vztahujeme k potenciálu utrpení nějaké škody nebo ztráty. Neadresují potenciál zisku. Příležitosti jsou naopak zaměřeny na pozitivní události, jejichž důsledkem je zisk. Umožňují tak zlepšit (stávající) očekávanou situaci. Klíčem k uchopení příležitostí je hledání umožňujících faktorů, jež individuálně nebo kolektivně ovlivňují, zda pozitivní události na projektu nastanou. Příkladem orientace na využití příležitosti je hledání nových technologií, které v době zahájení projektu nebyly k dispozici. Jakkoliv jsou s nimi spojena rizika (negativní dopady), nabízejí možnost zisku (pozitivní dopady). U slabě strukturovaných projektů je hledání příležitostí minimálně stejně důležité jako řízení rizik. Pro jejich správné uchopení je ale musíte nalézt a řídit.

Hledejte „nevyřčené požadavky“

Základním předpokladem dosažení kvality projektového výsledku je identifikace a zapracování tzv. nevyřčených požadavků do jeho řešení. Zdrojem nevyřčených požadavků zainteresovaných stran bývá znalost předmětné oblasti a zkušenosti z realizace obdobných projektových řešení. Schopnost projektového týmu převést nevyřčené požadavky do specifikovaných (zdokumentovaných) požadavků silně determinuje kvalitu architektonického návrhu, a tím i úspěšnost realizace celého systému. Kupodivu nejlepší návod na zjišťování a práci s nevyřčenými požadavky dávají normy ISO pro řízení kvality, v praxi jsou ovšem pohříchu tyto návody zcela ignorovány i u certifikovaných společností. Norma ISO 9001 mluví o „požadavcích, které zákazník neuvedl, ale které jsou nezbytné pro specifikované nebo zamýšlené použití, je-li známo“.

S příklady nevyřčených požadavků se setkáváme v běžné projektové praxi. Požadavek na splnění všech blíže nevyjmenovaných souvisejících norem a standardů, legislativní nevyjímaje, straší mnohé projektové manažery až do závěrečné akceptace. Dalším názorným příkladem nevyřčených požadavků je logický požadavek, aby projektem vytvořený systém byl následně provozovatelný stávajícími pracovníky zákazníka. V době outsourcingu či cloud computingu je takovým nevyřčeným požadavkem například rychlá převoditelnost outsourcovaných služeb do cloudu, čemuž samozřejmě původní poskytovatel služeb nebude jen ze své vůle aktivně nápomocen. Klasickým příkladem nevyřčeného požadavku je požadovaná reakční odezva systému na akci uživatele.

Konfliktní požadavky řešte ihned

Zainteresované strany mají své zájmy a ty mohou vést k předkládání konfliktních požadavků. Navíc své protichůdné zájmy prosazují v různém stadiu rozpracovanosti projektového řešení. Rozhodně se nevyplatí spoléhat na to, že kolizní požadavky se v průběhu projektu samy nějak vyřeší. Dobrou praxí, kterou doporučuje například TOGAF nebo COBIT, je klasifikovat zainteresované strany podle pozice a síly, kterou mohou v dané organizaci nařídit, změnit či blokovat danou oblast, a podle toho, zda je v jejich zájmu se do prací na dané oblasti aktivně zapojit, či nikoliv. Výsledkem takové jednoduché analýzy je skupina klíčových hráčů, která představuje ty zainteresované strany, u kterých je potřeba explicitně dojednat konsenzus. Názorným příkladem konfliktních požadavků je požadavek zákona číslo 101, o ochraně osobních údajů, který zabraňuje propojování databází s osobními údaji k jiným než specifikovaným účelům, versus požadavek obchodního oddělení na sledování osob klientů a systematické propojování a zpracování dat o nich získávaných z různých zdrojů. Konflikt zájmů se také často objeví, pokud si bezpečnostní politika organizace vynucuje omezení přístupu uživatelů k datům, která přímo nepotřebují pro svoji práci, ale občasně by je chtěli využívat.

Kombinujte metody shora-dolů a zdola-nahoru

Pokud neumíme zadat cílový výsledek projektu, musíme se soustředit na přístup, kterým se k definici výsledku dostaneme. Osvědčuje se kombinovat přístup shora-dolů vycházející z rozpadu možných představ a očekávání až na realizovatelnou úroveň versus přístup zdola-nahoru, který naopak z toho, co je realizačně možné a dosažitelné, kombinuje vyšší celky. Na styku obou metod hledejte inovativní myšlenky, které posunou řešení do lepší představy k chápání definice problému. Například zadání projektu, který má zajistit, aby byl cloudový systém pro vás bezpečný, není dostatečně tvrdé, aby bylo dobře strukturované. Zcela jistě vede k různému vnímání požadované úrovně bezpečnosti od různých zainteresovaných stran na obou smluvních stranách a také například uvnitř organizace. Dokonce i samotná definice toho, co znamená „bezpečný“, bude vnímána z různých hledisek. Zde lze při řešení využít konceptuální model, který ukazuje na hlavní komponenty řešení, ze kterých pak vznikají aktiva potřebná ke stanovení a řízení bezpečnosti.

Validujte, kde jen je to možné, namísto verifikace

Verifikace je proces kontroly kvality zjišťující, že požadavky a specifikace na řešený systém stanovené při zahájení jeho vývoje jsou splněny. Verifikujeme nejčastěji ověřením splnění požadavků oproti jejich kontrolnímu seznamu. Pokud je produkt nevyužitelný k zamýšlenému užití, verifikací se to jednoduše nepozná. Validace je proces zajištění kvality prokazující, že systém je využitelný k zamýšlenému užití a plní vytčený účel. Dochází k ověření jeho užitné hodnoty ve smyslu vytvoření správné věci. Validací tak můžeme ověřit i ty požadavky na systém, které jsme do jeho záměru nezahrnuli, ale přesto jsou pro užívání systému potřebné. Příkladem validačního ověření je testovací provoz systému. Oproti tomu verifikace se uplatňuje při odsouhlasení návrhu systému. To, že do návrhu řešení nebyl zahrnut „nevyřčený“ požadavek na reakční odezvu systému, se verifikací zpravidla nezjistí. Validačním testováním zátěžovými testy se nesplnění tohoto požadavku zjistí ihned. Validace tak představuje mnohem hodnotnější ověření projektového řešení či výsledku než verifikace.

Nastavte životní cyklus projektu tak, aby se k výsledku iterovalo

Pokud existuje jen mlhavá představa o projektovém výsledku, nezbývá než se k němu postupně přibližovat. Projektový manažer je nucen přistoupit k iteračnímu životnímu cyklu projektu, který je pak mnohem bezpečnější než klasický „vodopádový“ z hlediska možnosti vrátit se znovu na začátek a dotvořit slabě strukturované zadání. V první iteraci navrhneme řešení, které se následně ověřuje a sbírají se požadavky na jeho úpravu. Tyto požadavky společně s těmi předchozími vytvoří základnu, na kterou je řešení znovu navrženo, zrealizováno a ověřeno. Je zřejmé, že požadavky nejlépe zjistíme validací, a proto se vyplatí prototypovat. Nevýhody iteračního životního cyklu jsou dány náklady a časem na opakující se iterace. Za úspěch se považuje, pokud je konečného výsledku dosaženo v několika málo iteračních krocích. Je to ale leckdy jediná možnost, jak se dostat ke kvalifikovaně vzneseným požadavkům na řešení projektového výsledku.

Do životního cyklu zařaďte rozhodovací brány

Projektové brány nebo také rozhodovací milníky jsou umístěny do životního cyklu projektu zpravidla po etapách, které jsou nejvíce hodnotné z hlediska získání znalostí o vhodném dalším postupu na projektu. V branách se aktivně rozhoduje o dalším postupu na projektu na základě vytyčených pravidel. Zpravidla v projektové bráně dochází k rozhodnutí o smyslu, cílech a zadání projektu (business case), o projektových rizicích a příležitostech, o optimálním postupu ve smyslu dosažení progresu na projektu a o vhodných zdrojích pro další postup. Může docházet ke změně zadání projektu, ke směrování prioritních cílů nebo třeba i k rozhodnutí o předčasném ukončení projektu.

Branou bývá typicky ukončena návrhová etapa projektu, ve které se ukazuje, zda navržené řešení odpovídá požadavkům a v projektu je vhodné pokračovat beze změn v původním plánu. U iteračně řízených slabě strukturovaných projektů se brány vyskytují zpravidla před každým rozhodnutím o další iteraci. Typickou chybou u slabě strukturovaných projektů je přílišná orientace vedení projektu na plánovaný postup a ztráta kontroly nad hodnotou projektu, tedy základním smyslem toho, proč byl projekt spuštěn.

Petr Hujňák, Jaroslav Hujňák
Autoři jsou certifikovanými senior projektovými managery a ve společnosti Per Partes Consulting se zabývají krizovým projektovým managementem.