facebook LinkedIN LinkedIN - follow
IT SYSTEMS 12/2017 , Projektové řízení

Jak uchopit zadání projektu?

Může pomoci Project Canvas

Eva a Zdeněk Macháčkovi


Project CanvasAť se nacházíte v roli zadavatele, nebo projektového manažera, na začátku každého projektu je potřeba vytvořit jeho zadání. To se může zdát jako jednoduchý úkol. Sepíšeme potřeby, stanovíme milníky a projektová metodika nám při tom pomůže. Jenže někdy to tak snadné není. Existují ale postupy, které nám pomohou porodní bolesti počátku projektů přežít.


Většina firem, které řídí změny projektově, má svoji interní projektovou metodiku a k ní příslušející šablony, které používá pro definici zadání projektů. U IT projektů se většinou začíná definicí business potřeb a požadavků, následně se popíše, jak na to bude v projektu reagovat IT, jaké termíny, rizika, předpoklady a omezení projekt má. Jenže často, než jsme schopni takovou šablonu vyplnit, musíme tyto detaily vymyslet. Málokdy totiž zadání dostaneme takto strukturované. V tom nám může pomoci Project Canvas. Jedná se o další z řady poslední dobou populárních Canvasů [1].

Project Canvas

Project Canvasů najdete na webu mnoho. Nám se líbí ten od Over the Fence [2], nebo ten, do Jima Kalbacha [3]. Oba jsou dostupné zdarma, a to i pro komerční použití. Je na vás, který zvolíte, případně si můžete vytvořit vlastní, který bude reflektovat vaše potřeby.

Project Canvas je inspirovaný Business Model Canvasem od Alexandera Osterwaldera, který se zaměřuje na vytvoření vize strategie pro startupy. Naproti tomu se Project Canvas zaměřuje na klíčové oblasti projektů a jejich vizuální zachycení, které vede lepšímu vzájemnému pochopení, ujasnění klíčových bodů hned na začátku projektu a tím pádem vyhnutí se problémům v pozdějších fázích projektu, které, čím později se objeví, tím horší mají negativní dopad, a to často exponenciálně.

Vizualizace oblastí v canvasu je klíčová silná stránka tohoto přístupu. Umožňuje lepší pochopení celku, i jeho částí a vzájemných vazeb, a to srozumitelnější formou než dlouhé dokumenty plné textu.

Jak vyplnit Project Canvas

Při vyplňování Project Canvasu je klíčové formulovat hlavní myšlenky projektu stručně a konkrétně, se zohledněním celkového kontextu projektu. Cílem je zachytit hlavní dodávky projektu, což umožňuje omezit scope jen na to nejnutnější – tím se také dobře vydefinují skutečně podstatné oblasti (funkčnosti produktu atp.) od těch zbytných, což se velmi hodí dále při řešení finanční stránky projektu.

Doporučujeme canvas vyplňovat fyzicky, na papíře o velikosti cca flipchartu a s použitím samolepících papírků. To přiměje všechny, kdo se vyplňování účastní, aby formulovali myšlenky stručně a jasně a utřídili si při tom priority. Výsledný canvas by měl být srozumitelný i pro někoho, kdo se s projektem setkává poprvé. Canvas má dvojí účel. Lze ho použít jako mobilizační cvičení pro přípravný tým projektu, kdy klíčoví aktéři projektu společně projdou jednotlivé oblasti canvasu a naplní ho obsahem. Druhé použití je pro křížové kontroly, kdy ověřujeme, zda zadání a navržené řešení je vzájemně konzistentní, případně jak změna jedné proměnné ovlivní další. Toho lze dobře využít i pro diskusi se zadavatelem či managementem, díky přehlednosti a jednoduchosti canvasu, shrnujícího hlavní myšlenky na jedné stránce.

Struktura Project Canvasu a vyplnění krok za krokem

Jak jsme uvedli výše, není jedna jediná nejlepší, nebo závazná struktura canvasu. My jsme na ukázku zvolili canvas Jima Kalbacha. Pro Project canvas není daný závazný způsob postupu vyplňování jednotlivých sekcí. Můžete začít zleva a postupovat doprava. My vám zde ale ukážeme náš vlastní přístup, který se nám osvědčil v praxi. Díky němu lze vysledovat určité logické závislosti mezi prvky canvasu a použít ho následně také pro křížové kontroly. Pro pochopení dalšího textu prosím sledujte čísla uvedená u jednotlivých sekcí Project Canvasu na obrázku. Dále popisujeme ve větším detailu některé klíčové oblasti, kterým je, dle našeho názoru, potřeba věnovat zvýšenou pozornost.

Project Canvas

Nejprve vyplníme základní hlavičku projektu, dvě horní sekce:
Project (Název projektu) – Projekt by měl mít, pokud možno výstižný, jednoduchý název, či zkratku, který se vztahuje k jeho obsahu.
Motivation (Záměr, motivace pro realizaci projektu) – Experiment sociální psycholožky Ellen Langerové z Harvardské univerzity [4] ukázal, že lidé raději vyhoví vašemu požadavku, pokud ho zdůvodníte. Stejně tak se budou daleko ochotněji účastnit projektu, pokud budou znát jeho celkový záměr a motivaci k realizaci. Kromě toho, jasný popis motivace se bude hodit i pro obhájení rozpočtu před managementem a k ujasnění toho, zda se projekt hodná zabývat skutečně smysluplnou oblastí. Odpovězte si na otázky:

  • Jaké jsou motivace pro projekt? (příčiny a potřeby)
  • Proč je projekt smysluplný a důležitý a pro koho?
  • Jak projekt změní budoucnost a pro koho?

Dále postupujeme ve vyplňování podle čísel sekcí canvasu na obrázku:
1. Assumptions (Předpoklady / podmínky) - Přestože je tato oblast, jak si ukážeme dále, zcela klíčová, bývá často podceňována nebo vynechávána. Přitom její transparentní a včasná komunikace může zabránit realizaci mnoha projektových rizik. Tyto teze, předpoklady, na kterých je projekt postaven, jsou formulovány jak z hlediska businessu, tak i technického. Byznysové předpoklady zahrnují takové oblasti jako cílovou skupinu produktu, oblast projektem řešenou, očekávané přínosy (finanční i nefinanční). Technologické předpoklady zahrnují použití určité technologie a její předpokládanou aplikaci pro projekt. S ohledem na to, že projekt může využívat technologii, se kterou nejsou předchozí znalosti, nebo není jisté, zda bude umět pokrýt všechny požadavky, případně projekt dodává nový produkt nebo službu, u kterého není zřejmá jeho úspěšnost na trhu, je zásadní, aby již na začátku projektu proběhlo ověření těchto tezí.

Při vyplňování sekce Assumptions popište obecné předpoklady, které mají vliv na vnímání zadání a postup realizace. Pokud je to možné, uveďte nejvíce rizikové předpoklady jako první. Do předpokladů uveďte i očekávanou součinnost jiných projektů.

Je klíčové, aby předpoklady, na kterých projekt stavíme, byly co možná nejvíce ověřené. Například, pokud zadáním projektu je vytvořit mobilní aplikaci pro klienty, protože se domníváme, že její neexistence je důvod, proč klienti odcházejí ke konkurenci, je potřeba tento předpoklad ověřit. Bylo by totiž více než zbytečné, kdyby se po ukončení projektu a vynaložení nemalých nákladů ukázalo, že to není pravý důvod nespokojenosti zákazníků. Efekt dosažený realizací projektu by byl nulový (nebo spíše záporný, pokud započítáme i neúčelně vynaložené finance). Na začátku projektu by tedy každá kritická teze, jejíž ne/naplnění může znamenat ne/úspěch projektu, měla být ověřena.

Pro ověření tezí je možné použít tyto nástroje:

  • Minimum Viable Product Canvas / Experiment Canvas [5] – Canvas, který se používá pro ověření business požadavků formou experimentu.
  • Impact Mapping – vizuální zachycení předpokladů a rozsahu projektu. Tento nástroj využijete pro ohodnocení jednotlivých předpokladů na zadání projektu. Detailně jsme tuto metodu popsali v jiném článku [6].
  • User Story Mapping - slouží pro vizuální organizaci rozsáhlého projektového backlogu. Tuto metodu jsme detailně popsali v předchozím článku [7].
  • Service Blue Print Canvas [8] – tento nástroj je používán pro inovaci služeb. Zachycuje podstatu a charakteristiky interakcí služby v dostatečném detailu pro zavedení a údržbu. Pomáhá zachytit způsob, jakým koncový zákazník vnímá výsledný produkt.

Pokračujeme ve vyplňování dalších sekcí canvasu:
2. Users (Uživatelé/ Zákazník) – Vyjmenujte cílové skupiny nebo segmenty uživatelů či zákazníků produktu či služby. Doplňte významné specifické informace o dané skupině, pokud jsou k dispozici. Teze by měly být platné pro tyto zákazníky/uživatele.

3. Activities & Deliverables (Aktivity a výstupy) – Vypište klíčové oblasti aktivit, které tým provede pro to, aby dosáhl projektových cílů. Pro každou aktivitu (skupinu aktivit) popište hlavní výstupy a případně výstupní dokumentaci (toto nezahrnuje pracovní projektovou dokumentaci jako projektový plán, analýzu atp.).

4. User Benefits (Přínosy pro uživatele/zákazníka) – Popište celkový přínos výstupů projektu pro cílového uživatele / zákazníka.

5. Goals (Cíle) - Popište cíle projektu a kontroly pro ověření, že bylo cíle dosaženo. Pokud je to potřeba, rozlište zvlášť cíle programu a projektu. Pro přesnou formulaci cílů můžete použít již zmíněnou metodu Impact Mapping [6].

6. Constraints (Omezení) – Popište omezení a podmínky, které přímo ovlivňují výstupy, aktivity, nebo projekt jako takový:

  • Zdroje – Uveďte klíčové hmotné i nehmotné zdroje, které bude projekt pro realizaci výstupů potřebovat (například hardware, licence, speciální vybavení a stroje, prostory). Neuvádějte pracovní tým, ani rozpočet, na které jsou separátní kapitoly.
  • Rozpočet – Pokud existuje rozpočtové omezení (máte předem jasně daný určitý strop), napište ho.
  • Technologie – u řady, zejména IT projektů, jsou nastaveny technologické omezení (programovací jazyk, aplikační server, databáze, komunikační protokoly…).
  • Právní, regulatorní omezení - další velkou skupinou omezení jsou otázky právního prostředí. Tato oblast je velmi citlivá zejména v případě projektů pro mezinárodní prostředí.

Tato omezení je dobré ověřit proti očekávaným cílům projektu. Poměrně často se setkáváme s rozporem v této oblasti např. se očekává vyřešení všech problémů s velmi omezenými zdroji. Canvas tady pomáhá vizualizovat tento rozpor a může sloužit jako dobrá pomůcka projektového manažera pro facilitaci dohody jednotlivých stakeholderů.

7. Scope (Rozsah) - Popište rozsah produktu nebo služby. Popište, co je a zejména co není předmětem projektu:

  • Výsledek projektu – Popište, co je očekávanou dodávkou projektu pro koncového zákazníka / uživatele. Jedná se o produkt, nebo službu, znalost? Zohledněte výstupy i s možnými variantami a kanály pro doručení k zákazníkovi (dle složitosti se může jednat i o více produtků/služeb).
  • Mimo rozsah projektu – Popište explicitně oblasti, které nejsou předmětem realizace projektu. Tato oblast může být silně ovlivněna dostupnými zdroji 6. Constraints (Omezení) projektu a jeho milníky – sekce 8. Milestones (Milníky / čas).

8. Milestones (Milníky / čas) – Do milníků zahrňte i vliv okolí (např. účinnost legislativních změn, milníky souvisejících projektů nezbytné pro koordinaci, atp.). Popište, nakolik je možné jednotlivé milníky posouvat v čase, či nikoliv (flexibilita časového plánu). Vypište klíčové časové milníky v průběhu celého projektu:

  • Začátek a konec projektu,
  • kdy budou průběžné / částečné výstupy (prototypy),
  • rozhodovací milníky,
  • viditelné / měřitelné výstupy.

9. Participants (Účastníci) - Účastníci projektu jsou přímí a nepřímí. Mezi přímé účastníky řadíme pracovníky alokované na projekt (projektový manažer, analytici, architekt, vývojáři, testeři, zástupci businessu, atd.), ale i management, který se účastní různých schvalovacích komisí, nebo jsou na něj reportovány informace o stavu a postupu projektu. Na nepřímé účastníky se často zapomíná, přestože nezapojení do projektu může být pro projekt rizikové. Mezi nepřímé účastníky patří například linioví nadřízení pracovníků na projektu, jiné projekty, se kterými je zapotřebí zajistit koordinaci, oddělení, na která může mít projekt negativní dopad, odbory a jiné zájmové skupiny. Dopad projektu na účastníky může být pozitivní, neutrální, nebo negativní. Zejména nepřímí účastníci projektu s negativními dopady výsledků projektu mohou pro projekt představovat riziko (např. bojkot ze strany pracovníků, kteří díky projektu ztratí svoje výsady nebo jistoty) a je potřeba si včas uvědomit, pokud taková skupina existuje.

Stakeholdeři a třetí strany:

  • Sponzor (vlastník projektu) – platí projekt, rozhoduje o důležitých aspektech projektu, je zodpovědný za business přínos projektu.
  • Dotčené skupiny – externí i interní v rámci organizace s pozitivním i negativním dopadem výstupů projektu.

Tým - Členové týmu, Vypište je jmenovitě a uveďte jejich roli na projektu. Můžete přidat i vzájemné závislosti, pokud existují:

  • Klíčoví členové týmu
  • Rozšířený tým
  • Externí partneři
  • Projektové vedení a management (steering komise atp.)

10. Risks (Rizika) – Popište možné budoucí události, které by mohly mít negativní dopad na projekt a tento dopad popište. Napište také opatření pro pokrytí těchto rizik, pokud je to možné. Pokud se jedná o oblasti, u který víte, že určitě nastanou, nebo je můžete ovlivnit, uveďte je do kapitoly 1. Assumptions (Předpoklady / podmínky).

Poslední sekcí je Project End (Konec projektu) - V jakém okamžiku může být projekt ukončen nikoliv z hlediska časového, ale z hlediska hotovosti práce, tedy „definition of done“.

Křížové kontroly

Project canvas máme nyní vyplněn. Pro ověření vzájemného souladu obsahu jednotlivých sekcí můžeme využít křížové kontroly. Začínáme u sekce 1 Assumptions a pokračujeme po číslech dále podle následující logiky: Na základě těchto Předpokladů (1 Assumptions) pro tyto Uživatele (2 Users) vytváříme určitý Produkt nebo službu (3 Activities & Deliverables), kterou realizujeme popsané Přínosy pro uživatele (4. User Benefits). To vede k naplnění Cílů projektu (5. Golas) při respektování daných Omezení (6. Constraints), dodržení popsaného Rozsahu (7. Scope) a Milníků (8. Milesotnes), se zapojením Účastníků projektu (9. Participants) a se zohledněním možných Rizik (10. Risks).

Při provádění křížových kontrol můžeme nalézt logické rozpory. Například, že produkt či služba dodávaný uživateli není v přímém souladu s cíli projektu. Nebo také můžeme argumentovat se zadavatelem, že při daných rozpočtových omezeních není možné naplnit požadovaný rozsah.

První verzi canvasu je dobré vyplnit hned při startu projektu a průběžně ji validovat a doplňovat. Jednotlivé verze dokumentujte (foťte), budete tak mít přehled, jak se jednotlivé aspekty projektu vyvíjely. Počáteční verze canvasu budou mít některé sekce vyplněné jen velmi stručně a k jejich zpřesnění bude docházet postupně. Vždy by však měla být zachována konzistence celého canvasu. Případná nekonzistence je jasným signálem trhliny v projektovém záměru. Doporučujeme se v takové chvíli zastavit a prioritně se věnovat odstranění, nebo vyjasnění tohoto nesouladu. Velkým přínosem Project Canvasu je jeho schopnost vyvolat diskuse o důležitých aspektech projektu a poukázat na problematické body v jeho konstrukci.

Eva Macháčková Zdeněk Macháček
Eva a Zdeněk Macháčkovi
Autoři článku, Eva a Zdeněk Macháčkovi, pracují jako konzultanti a projektoví manažeři. Zaměřují se na strategické poradenství, vzdělávání a popularizaci nových trendů businessu a podnikového IT.
http://bit.ly/evamachackova
http://bit.ly/zdenekmachacek

Zdroje:
[1] Macháčková E., Macháček Z.: Lean Canvas – Jak získat přehled a domluvit se o produktu v rekordně krátkém čase, IT Systems 10/2016, p.38-40
[2] Over the Fence: Project Canvas http://overthefence.com.de/tools/
[3] Jim Kalbach: Project Canvas http://thetoolkitproject.com/tool/the-project-canvas#sthash.of5Xs16r.dpbs
[4] Cialdini, R., B: Zbraně vlivu: Manipulativní techniky a jak se jim bránit, Jan Melvil Publishing 2012, str. 24, Langerová, E.J: Minding Matters (Na myšlení záleží). Advances in Experimental Social Psychology, sv. 22, upravil Berkowitz, L. New York: Academic Press. 1989
[5] Experiment Canvas - http://thetoolkitproject.com/tool/experiment-canvas
[6] Macháčková E., Macháček Z.: Impact Mapping – Jak uřídit vývoj nového produktu a nezbláznit se z toho, IT Systems 11/2016, p. 28-29
[7] Macháčková E., Macháček Z.: User Story Mapping – Organizujte rozsáhlý produktový backlog vizuálně, IT Systems 3/2017, p.2-3
[8] Service Blueprint Canvas - http://thetoolkitproject.com/tool/service-blueprint-canvas

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

Konec papírování, digitalizujte a usnadněte si práci!

IT Systems 3/2024V aktuálním vydání IT Systems jsme se zaměřili na vývoj digitalizace ve světě peněz, tedy v oblasti finančnictví a pojišťovnictví. Dozvíte se například, proč je aktuální směrnice PSD2 v inovaci online bankovnictví krokem vedle a jak by její nedostatky měla napravit připravovaná PSD3. Hodně prostoru věnujeme také digitalizaci státní správy a veřejného sektoru, která nabírá obrátky.