Projektový Underground

Pro vás jako vedoucí projektu je jistě lákavé vyřešit každý problém, který je před vámi. To však není realistické – a často je to dokonce škodlivé v prostředí, kde jsou role jasně definovány. Překročení pracovních povinností může narušit efektivitu týmu a poškodit organizaci. Obecně existují tři povinnosti, které by měli manažeři projektů ponechat ostatním. Na toto téma vyšel článek v posledním čísle časopisu PM Network (pro členy PMI), z něhož přinášíme hlavní myšlenky.

1. Technická rozhodnutí

Přizpůsobení se potřebě poskytování technických znalostí otevírá dveře
k nadměrnému rozšiřování, a dokonce k zneužívání projektového manažera a vytváří nebezpečný precedens. Schopnost organizovat úsilí týmu, schopnost vidět souvislosti a udržet projekt na vytyčené cestě – to vše může být ohroženo, pokud bude přesměrováno úsilí a čas manažera projektu na to, aby poskytoval technické know-how. Překročení této linie může také odcizit techniky v týmu ostatním a rychle poškodit důvěryhodnost a pověst projektového manažera.

2. Nastavení organizační strategie

Organizace, které jsou špatně řízené nebo jim chybí jasné strategie, se někdy dostanou do pasti představ, že projektové řízení může tyto problémy magicky vykompenzovat. Manažer projektu, který se pokouší jednostranně nastavit organizační strategii, však pouze podporuje a zesiluje problémy způsobené nedostatkem strategického řízení.

Co dělat? Někdy nechat projekt selhat z nedostatku strategie je způsob, jak uplatnit konstruktivní tlak na tvůrce rozhodnutí osvětlením těchto nedostatků. Nesmí to ale být spojeno se špatným řízením projektu.

3. Personální rozhodnutí

Projektoví manažeři v maticových organizacích jsou obvykle zodpovědní za dodání projektu bez formální autority nad členy týmu, které poskytují funkční manažeři. To může pro manažera projektu znamenat komplikovanou situaci, když nedostatečné dovednosti nebo špatná motivace člena týmu brání pokroku. Narazí-li PM na problematického člena týmu, nejprve si s ním promluví, aby porozuměl jeho perspektivě, poté odhalil hlavní příčiny nedostatečného výkonu a identifikoval řešení. Pokud problémy přetrvávají, pak je čas zahájit diskusi s vedoucím dané osoby – poté, co členovi týmu oznámí, že to udělá.

Je důležité omezit komunikaci otázek výkonu na pozorovaná chování a konkrétní dopad na projekt. Poskytnutí další zpětné vazby, když o to požádá jejich manažer, je v pořádku. Za odstranění nebo nahrazení zdroje projektu je však odpovědný funkční manažer. Je také ale možno poskytovat rady manažerům ohledně vhodnosti zaměstnanců pro jejich určitou roli.

Určitě existují situace, kdy vedoucí projektu musí být i trenérem. Menší organizace, zadání potýkající se se srozumitelností, či skupiny experimentující s řízením projektů, ti všichni by mohli potřebovat projektového manažera, který se rozkročí nad rolemi, aby dosáhl výsledků. Ale to je výjimka z pravidla.

Vysoce výkonní projektoví manažeři chápou hodnotu schopnosti identifikovat a porozumět problémům nad rámec projektu, ale také rozumět limitům jejich vlivu.

Velkou část dnešního čísla věnujeme jedné hybridní metodice spojující klasické vodopádové řízení s agilním. Agilní řízení je dnes buzzword, ale ne vždy a všude je tento styl vhodný. Ale zároveň platí – proč se nepoučit z agilních principů a proč je nevyužít? Metodika DSDM je jedna z prvních agilních metodik. Byla tu dokonce dřív, než se ukotvil termín „agilní“. Vznikla již v roce 1994 a vycházela částečně z RAD (Rapid Application Development), ve které projektovým manažerům přišla nedostatečná kontrola a disciplína. Tato metodika klade důraz na včasné dodání, což je dnes častý požadavek. Také klade velký důraz na to, aby se projekt podniku vyplatil z obchodního hlediska a aby bylo dosaženo co nejlepší ROI, ale i na dodržení rozpočtu. Pro dosažení těchto projektových cílů doporučuje používat tyto nástroje: workshopy, modelování a iterativní development, prioritizaci MoSCoW a timeboxing, neboli rozdělení na časové úseky. Podle průzkumu je metodika DSDM celosvětově z méně používaných. Na prvním místě je metodika Scrum, po ní následují metodiky Extreme Programming a Feature Driven Development a DSDM je s 4,166% trhu na čtvrtém místě, s metodikou Kanban ve velmi těsném závěsu. V české Republice není moc známá, ve světě se užívá především v korporátním prostředí.

Metodika DSDM je výjimečná tím, že jako jedna z mála agilních metodik popisuje průběh celého projektu a životního cyklu produktu. Metodiku lze také kombinovat vodopádovými s metodami jako je metodika PMI. Hlavní filosofií DSDM je „the best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people”. Toho je dosaženo, pokud všechny zainteresované strany jak uvnitř, tak mimo projekt, jsou plně zapojeny, mají možnost rozhodovat o věcech týkajících se jejich oboru, chápou vizi a cíle projektu, dodržují časový plán a akceptují, že během projektu může dojít ke změnám jak požadavků, tak způsobů řešení. S tím souvisí i parametry DSDM projektu. Obecně jsou hlavními parametry projektů náklady (finanční i časové), kvalita a užitné vlastnosti (features), které řešení nabízí. Tradiční projekty kladou důraz na dodané užitné vlastnosti, kde náklady se stanou proměnnými (jinými slovy cena i čas doručení se podřizují tomu, aby řešení mělo tyto vlastnosti). Pro DSDM metodiku jsou naopak nejdůležitější časové a finanční náklady a užitné vlastnosti jsou pouhou proměnou. Důraz je tedy na dodržení termínu dodání a finančního rozpočtu a tomu se podřizuje, jaké vlastnosti bude výsledné řešení mít, tak, aby byla zachována co nejvyšší možná kvalita a byly splněny cíle projektu. Právě to odpovídá požadavkům na projekt DMS.

DSDM metodika rozděluje projekt celkem do šesti fází. Čtyři hlavní fáze se nazývají Feasibility, Foundations, Evolutionary Development a Deployment. Před fází Feasibility se nachází ještě tzv. Předprojektová fáze a projekt je ukončen poprojektovou fází. Z Feasibility fáze, kde se ověřuje realizovatelnost záměru, přechází projekt do fáze Foundations, kde jsou vymezeny základní cíle celého projektu. Poté následuje Evolutionary Development, kde probíhá samotný vývoj aplikace. Když se rozhodne o nasazení aplikace, projekt přejde do fáze Deployment. Často (i dle doporučení metodiky) se aplikace nasazuje po částech, proto se fáze Evolutionary Development a Deployment mohou několikrát opakovat v iteracích. Pokud se v rámci fáze Deployment dojde k rozhodnutí, že je třeba přehodnotit požadavky na řešení, lze se vrátit i do fáze Foundations. V poslední iteraci je nasazen finální produkt a projekt je ukončen. Po jeho ukončení následuje tzv. poprojektová fáze.

Dle metodiky DSDM je důležité rozdělení rolí v týmu tak, aby každý člověk měl vymezenou část projektu, za kterou je zodpovědný. Nepočítá se tedy se sdílenou (týmovou) odpovědností, typickou např. pro metodiku SCRUM. Kvůli tomuto vymezení je velice důležitá komunikace mezi členy týmu a vzájemný respekt. Podle DSDM existuje dvojí dělení rolí – podle zaměření či podle postavení v rámci projektu. Role a jejich rozdělení v rámci projektu jsou detailněji popsány v následující kapitole.

Role

Role jde podle zaměření rozdělit do čtyř kategorií.

• První kategorie se sestává z rolí starajících se o zájmy podniku a obchodní pohled na řešení. Do této kategorie se řadí např. Obchodní Sponzor (Business Sponsor), který má mj. na starost financování projektu a dohled nad jeho směřováním v souladu s požadavky firmy, nebo Obchodní Vizionář (Business Visionary), který je zástupcem Obchodního Sponzora a jako takový komunikuje jeho požadavky napříč týmem a stará se o vizi celého projektu.
• Druhá kategorie rolí reprezentuje technický pohled na řešení. Jde především o Vývojáře, což jsou vývojáři řešení (softwaru), Testeři (Solution Testers – testeři kvality vyvíjeného řešení) nebo Technický koordinátor (Technical Coordinator), který je zodpovědný za technický stav projektu.
• V další kategorii jsou role managementu, které mají na starost řízení celého projektu. Projektový manažer (Project Manager), role zodpovědná za celý projekt, nebo Vedoucí týmu (Team Leader), zodpovědný za tým vývojářů.
• Poslední kategorií jsou procesní role. Některé role se mohou nacházet na rozhraní dvou kategorií a nemohou být jasně vymezeny, např. Obchodní Analytik, který je prostředníkem mezi managementem a vývojáři a řadí se proto jak do podnikových, tak do technických rolí.

Podle postavení se role dělí do tří kategorií – projektové role, tým vývojářů a podpůrné role.

• Projektovými rolemi se rozumí ty role, které rozhodují o směřování celého projektu a jsou za něj zodpovědné. Patří sem všichni manažeři a koordinátoři jako Projektový manažer, Technický Koordinátor nebo Obchodní Vizionář. Obchodní Analytik je na pomezí projektové role a týmu vývojářů.
• Tým vývojářů se skládá ze všech rolí, které se podílejí na dodání řešení, tedy kromě Vývojářů také např. Tester nebo Vedoucí týmu. Každý z týmu vývojářů je kompletně zodpovědný za svou část řešení. V rámci jednoho projektu se může vyskytnout i více týmů vývojářů.
• Do podpůrných rolí se řadí všechny ostatní role, např. poradci z různých oborů jako Obchodní poradci nebo Techničtí poradci.

Metodika nerozporuje obsazení více rolí jednou osobou ani obsazení jedné role více osobami – v tom případě je ale podmínkou že musí úzce spolupracovat.

U některých rolí se zastavme, protože mohou být obecně chápány trochu jinak než v této metodice, nebo jejich vysvětlení pomůže objasnit principy vlastní metodiky.

Obchodní vizionář je fakticky plnohodnotný zástupce vlastníka, protože metodika správně předpokládá, že vlastník obvykle nemá dostatek času věnovat se projektu naplno. Slovem plnohodnotný se rozumí i vybavení odpovídající autoritou dovnitř organizace. Jedná se o seniorní vedoucí roli na úrovni projektu, kterou by měla mít alokovánu pouze jedna osoba, protože projekt potřebuje jednu jasnou vizi, aby se předešlo nejasnostem a nesprávnému vedení. Angažuje se aktivněji než obchodní sponzor, protože je obvykle vyčleněn na full time. Je odpovědný za interpretaci požadavků obchodního sponzora, jejich předání do týmu. Obchodní vizionář zůstává zapojen do celého projektu, poskytuje týmu strategický směr a zajišťuje to, že dodané řešení umožní dosažení přínosů.

Odpovědnosti

• Definování obchodní vize projektu
• Komunikace a propagace obchodní vize všem zúčastněným a / nebo dotčeným stranám
• Sledování průběhu projektu v souladu s podnikatelskou vizí
• Řešení širších důsledků jakékoli business změny z organizačního hlediska
• Přispívání ke klíčovým požadavkům, návrhům a revizím, zejména tam, kde jsou aspekty řešení považovány za klíčové prvky obchodní vize
• Identifikace a vlastnictví podnikatelského rizika
• Definování a schvalování změn požadavků na high-level, tzn. jakékoli změny, která ovlivňuje základní rozsah nebo významně mění rovnováhu priorit
• Zajištění spolupráce napříč oblastmi podnikání v rámci projektu
• Zajištění obchodních zdrojů je pro projekt k dispozici podle potřeby
• Propagace převodu obchodní vize do pracovní praxe, tj. Zajištění úplného obchodního přijetí řešení vytvořeného projektem
• Posílení obchodních rolí v rámci týmu pro rozvoj řešení na odpovídající úrovni v rámci jejich odpovědnosti
• Tam, kde se vývojový tým nemůže dohodnout, jedná jako arbitr.

Obchodní analytik je garantem konzistentnosti řešení z byznysového hlediska. Je aktivní v podpoře rolí na úrovni projektu. Obchodní analytik primárně řeší vztah mezi obchodními a technickými rolemi, zajišťuje přesné a vhodné rozhodnutí o vyvíjejícím se řešení na každodenní bázi. Obchodní analytik zajišťuje, že byznysové potřeby jsou správně modelovány a analyzovány a jsou správně zohledněny v pokynech, které tým potřebuje k vytvoření řešení. Aktivní zapojení koncových uživatelů do procesu vývoje řešení je životně důležité pro úspěch projektu DSDM. Proto je důležité zajistit, aby se Obchodní analytik nestal zprostředkovatelem mezi členy vývojového týmu, ale místo toho komunikaci mezi nimi podporoval a usnadňoval.

Odpovědnosti:

• Pomoc obchodnímu vizionáři při formulaci a propagaci podnikatelské vize
• Modelování současného a budoucího stavu z hlediska identifikace příležitostí, rizik a dopadů
• Spolupráce s obchodním vizionářem a s vývojovým týmem pro formulaci a komunikaci možností řešení
• Podpora a usnadnění jednoznačné a včasné komunikace mezi obchodními a technickými účastníky projektu
• Zajištění kvalitně definovaných požadavků a jejich řádná analýza a řízení
• Řídit vývoj, distribuci a základní schvalování veškerých komunikací souvisejících s obchodními požadavky a jejich interpretací, se zvláštním zaměřením na zajištění toho, aby seznam prioritních požadavků byl průběžně aktualizován, protože se detaily rozšiřují a vyvíjejí.
• Zajištění toho, aby obchodní a organizační důsledky každodenního vývoje řešení byly správně modelovány a promyšleny
• Zajištění dopadu obchodních rozhodnutí je posuzováno v kontextu projektu
• Zajištění toho, aby obchodní a technické složky řešení společně poskytovaly soudržný celek pro podnik
• Spojení s obchodním vizionářem při organizaci podpory řešení prostřednictvím implementace do živého provozu

Technický poradce podporuje tým tím, že poskytuje konkrétní a odborný technický vstup do projektu, často pohledem manažerů odpovědných za provoz, provozní podporu, průběžnou údržbu atd.

Lektor workshopu je zodpovědný za řízení vlastního procesu workshopu. Je katalyzátorem pro přípravu a komunikaci. Je to facilitátor odpovědný za organizaci workshopů, které účastníkům umožní dosáhnout cíle. Facilitátor workshopu by měl být nezávislý na výsledku, kterého má být v projektu dosaženo.

Nástroje metodiky

Zde jsou podrobněji rozepsány některé nástroje specifické pro tuto metodiku, ostatní jsou jen vyjmenovány.

1. Prioritizace MoSCoW

Vzhledem k povaze DSDM projektu, který klade důraz na včasné dodání a kvalitu a proměnnou projektu jsou užitné vlastnosti, které bude mít dodané řešení, je důležité stanovit si priority, tj. jasně vytyčit, které vlastnosti dodávaného řešení jsou bezpodmínečně nutné a které jsou naopak pouze příjemným doplňkem. K tomu slouží právě priotizace MoSCoW, což je zkratka pro „must have, should have, could have, won’t have this time“. Prioritizace se používá v průběhu celého projektu –  ať už při tvoření cílů celého projektu, jednotlivých time-boxů či iterací. Díky tomu může docházet k přesunu požadavků z jedné kategorie do druhé – co během jedné iterace je zamítnuto a odsunuto do kategorie Won’t have this time může být v příští iteraci must have a naopak. Pokud se projekt ocitne v časovém skluzu, začne se upouštět od jednotlivých požadavků, aby byl dodržen termín dodání. V takovém případě se začíná „odspoda“, tj. nejprve se upouští od požadavků could have a pak až případně od should have požadavků.

Must have jsou minimální požadavky na dodané řešení, které musí být vždy splněny, bez kterých by řešení nebylo použitelné. Should have požadavky jsou ty, bez kterých by dodané řešení nemuselo být úplně komfortní, které jsou sice důležité, ale nejsou pro projekt životně důležité. Could have jsou požadavky takové, které jsou možné a mohly by být příjemným rozšířením, nicméně nejsou pro dodávané řešení tolik důležité. Nakonec won’t have this time (odložené) požadavky jsou požadavky, které nyní nebudou dodány. Je důležité si je uchovat, aby nebyly opakovaně navrhovány (a zamítány), což by znamenalo zbytečné plýtvání časem, anebo naopak pro případ, že by daný požadavek byl přehodnocen a přesunut do jiné kategorie.

• Timeboxing

Timeboxing je praktika, kdy se projekt (především ve fázi Evolutionary Development) rozdělí na menší časové úseky (timeboxy), které mají jasně stanovený cíl. Pro každý timebox je vhodné udělat MoSCoW prioritizaci, čímž se jasně vymezí, čím se bude tým v daném timeboxu zabývat a co naopak nyní řešit nebude. Jeden projektový inkrement se obvykle skládá z více timeboxů. Důležité je si uvědomit, že stejně jako sprint v metodice SCRUM timebox neskončí, když se dosáhne nastavených cílů (požadavků), ale když vyprší jeho čas. Pak se vyhodnotí úspěšnost timeboxu dle toho, kolik z naplánovaných požadavků tým stihl dodat. Doporučená délka timeboxu v DSDM projektu je dva až čtyři týdny.

Styly timeboxů jsou dva – strukturovaný DSDM styl a volný styl. Volba mezi styly závisí na povaze projektu a dodávaného řešení.

Strukturovaný DSDM timebox nabízí jasně dané fáze a revize, což napomáhá dlouhodobějšímu plánování (revize se budou opakovat pravidelně). Jednotlivé fáze se nazývají Investigation, Refinement a Consolidation. První a poslední fáze by měly každá zabrat okolo 10-20% celkového času timeboxu a zbylých 60-80% připadá na Refinement. Na konci každé této fáze je revize. Před první fází je kick-off, tedy Zahájení timeboxu, a na konci timeboxu je close-out (Zakončení).

Prosím povšimněme si, že na rozdíl od sprintu je zde jasně oddělena fáze nasazení do provozu a doladění na jejím základě (Refinement).

• Workshopy
• Modelování a prototypování
• User stories

Shrnutí

Autor nasadil tuto metodiku v projektu, který na základě požadavku zákazníka byl vyvíjen agilně, ale zároveň byl zasmluvněn smlouvou Fixed Time – Fixed Price. Obě strany kontraktu byly v určité době po startu značně nespokojeny se stavem, což vedlo k problémům a nedůvěře ve vzájemné komunikaci. Zavedení metodiky fakticky žádný velký průlom neudělalo, protože i tak se pracovalo intuitivně podobným způsobem. Ale pojmenování rolí a odpovědností, to, že jednotliví účastníci si byli vědomi svého úkolu, autority i omezení, ale i vyčištění backlogů (přinucení k pořádné prioritizaci) značně „vyčistilo vzduch“ a projekt se znovu rozběhl a běží ke spokojenosti obou stran.

Do podobné situace se může dostat kdokoliv. Nebo i se objeví stav, kdy se tato hybridní technika ukáže jako užitečný nástroj. Neváhejte se s ní proto seznámit, literaturu lze dohledat na internetu.

Zde najdete popis situace, odpověď či doporučené řešení je až v následujícím příspěvku, který bude publikován o den později. To proto, abyste si mohl vyzkoušet, jak byste takovou situaci řešil sám, kdybyste se s ní setkal – a pak si porovnat svoje zkušenosti se zkušenostmi ostatních. No a vůbec nejraději budeme, pokud se popisem „strefíme“ do problému, který vás aktuálně trápí, a přispějeme tak zkušenostmi k jeho řešení.

První situace: Rizika a neurčitost

Jak nejlépe naložit při plánování zdrojů s neurčitostí? Tzn. aktivity s jinou než 100% pravděpodobností zahrnovat/nezahrnovat/zahrnovat a násobit danou pravděpodobností? Konkrétní (velmi modelový) příklad: Kontrakt ještě není podepsán pravděpodobnost, že se podepíše je 50%, rozsah je 100 MD na 3 měsíce, práce mají být zahájeny dle předpokladu za 1 měsíc. Problém: PM musí mít zdroje rezervovány, pro případ, že se kontrakt podepíše. Pokud je ale má rezervovány a kontrakt se nepodepsal, vystavuje se situaci, že lidé již nebudou utilizováni jinde. Pokud si je rezervuje a zohlední pravděpodobnost 50%, tak jich má rezervovánu „pouze polovinu“. Snížil dopad rizika, ale téměř jistě má problém, protože kontrakt se buď nepodepíše nebo podepíše. V prvním případě má rezervováno zdrojů moc a ve druhém málo. Existuje nějaká 4tá možnost? Co je nejmenším zlem v modelovém příkladu? Jaké jsou vaše zkušenosti s obdobnými situacemi v praxi?

Druhá situace: Řešení konfliktů při plánování

Jaké jsou zkušenosti s řízením/řešením kolizí v čerpání lidských zdrojů v rámci firmy?

Třetí situace: Akceptace

Ideální stav je pokud lze konkrétní akceptační kritéria ve velmi raných stadiích projektu a nejlépe je spolu s popisem akceptačního procesu vložit jako přílohu ještě přímo do smlouvy se zákazníkem. Jak se ale postavit k situaci, kdy to z principu projektu před zahájením nelze udělat?