Projektový Underground

Jubilejní 5. ročník konference o projektovém řízení PMcon 2018 se již kvapem blíží! Dveře Studijního a informačního centra na ČZU se pro účastníky otevřou již 25. května a je toho opravdu spousta, na co se letos můžete těšit! Čeká vás den nabitý pozitivní atmosférou, zábavou, vzděláváním a společnými zážitky – to vše v duchu tématu „PMcon 5.0: Projekťák v digitálním věku“. Celodenní konference tentokrát nabídne plejádu 20 renomovaných odborníků z projektové praxe ve čtyřech přednáškách a devíti workshopech rozdělených do dvou běhů. Letošní ročník s sebou přináší i nové, zcela unikátní prvky programu, jako jsou diskuzní stoly s odborníky z praxe a interaktivní části pro sdílení zkušeností a znalostí nejen mezi účastníky navzájem, ale také s partnery, organizátory a řečníky. Ani letos nebude chybět již tradiční zakončení konferenčního dne spojené s neformálním večerním networkingem.

Organizátorem akce je Studentský klub projektového řízení (SKPŘ), jenž již tradičně připravuje konferenci PMcon pro všechny, kteří se zajímají o projektové řízení, chtějí získat vice znalostí a dovedností a dále se rozvíjet v tomto oboru.

Tématem „Projekťák v digitálním věku“ vás provedou odborníci ze společností, jako jsou např.: Česká spořitelna, Accenture, KOMIX, ČSOB, Microsoft, Vodafone, Wüstenrot, Notix ad.

V přednáškové části se dozvíte, jak se jako projektový manažer orientovat a na co se soustředit ve světě, kde vás nástroje pronásledují na každém online rohu, jak vypadají metodiky či systém projektového řízení v době digitalizace, zda se má projektové řízení digitalizaci přizpůsobit či jak využít vizuálního myšlení a usnadnit si tím život.

Ve workshopové části na vás čeká celá řada praktických ukázek, během kterých máte např.: příležitost dozvědět se, jak v dnešní uspěchané době načerpat klíčové informace o jakémkoli projektu do 2 minut, co je to Design Thinking a jak ho prakticky použít, budete mít také šanci vyřešit komplikace na mezinárodním projektu nebo zjistit, jak uchopit agilní řízení v prostředí korporátu. Seznámíte se s celým procesem metodiky SCRUM interaktivní a zábavnou hrou, dozvíte se, zda mají projektové schůzky smysl i v digitálním věku a naučíte se, jak lze v týmu pracovat efektivně, rychle a mít vše důležité pohromadě díky službě MS Teams. Zjistíte také jak řídit stakeholdery na projektu (zejména očekávání sponzora) a naleznete odpovědi na otázky, zda je projektový manažer ohroženým druhem či jaké jsou vlastnosti a dovednosti nezbytné pro přežití této profese!

Po celý den pro vás bude k dispozici nejen odborná strava ve formě programu, ale také se samozřejmě můžete těšit na občerstvení a lahodnou kávu.

Celou konferenci bude doprovázet festival pracovních příležitostí s názvem Talent Magnet (http://www.talentmagnet.cz/), jehož cílem je navázání kontaktů a vzájemné spolupráce mezi studenty, PMs a společnostmi. Kromě účastníků konference je festival otevřen i veřejnosti.

Tuto pozvánku i s obrázky si můžete stáhnout zde. Více informací o konferenci naleznete na webu https://www.pmcon.cz/ nebo na Facebooku https://www.facebook.com/pmcon.cz/

Registrace naleznete zde: https://www.pmcon.cz/vstupenky

Everest ne nejen hora, ale byl to i známý projekt. V historii našeho bankovnictví šlo možná o jeden z nejambicióznějších projektů vůbec. Byl nastartován po fúzi dvou bank, Raifeisenbank a eBanky v roce 2009 a neměl menších cílů, než nahradit stávající dva core banking systémy systémem novým. To vše za plného provozu banky při plnění aspirativních obchodních cílů.

Světový guru na core banking transformace, George Colwell říká, že taková transformace je srovnatelná s výměnou všech motorů Boeingu 747 během letu, anebo s otevřenou operací srdce u pacienta, který zrovna běží maraton. Své zkušenosti shrnul do osmi fází, kterými typicky taková transformace prochází a nazval je osm schodů poznání.

Tábor první – Vzrušení z Něčeho Nového

Většina bank prochází extrémně detailním, časově náročným a drahým RFP procesem, kdy vyhodnocuje jednotlivá dostupná core-banking řešení, integrátory a další periferie potřebné pro svůj transformační projekt. Euforie na konci RFP procesu s výběrem řešení (Dodavatele), integračního partnera (Integrátora) a dalších potřebných hardwarových komponent běžně vytváří obrovskou dávku vzrušení. V tomto bodě je Banka nadmíru optimistická a nový projekt začíná… je tu vzrušení z něčeho nového!

Tábor druhý – Proč je to tak těžké? Může za to integrátor!

Vzrušení přetrvává přesně tak dlouho, dokud Banka nezjistí, že je to daleko složitější, než předpokládala. Dosažení potřebného tahu a dynamiky v implementačním projektu zabírá déle, než se očekávalo. Zdá se, že jednotlivé strany nejsou zcela sehrány a zaznívají první falešné tóny. Banka se domnívá, že problémem je Integrátor, kterého si najala, aby jí pomohl implementovat systém. Přehodnotí svoji strategii, prozkoumá smlouvu, kterou s Integrátorem podepsala a pomalu oba dva spějí k přejednání podmínek, zatímco se Banka rozhlíží po alternativách. Mnoho času a peněz je prohýřeno hrou na hledání viníka. Na konci čeká zpravidla výměna vrcholového vedení projektu na straně Integrátora, dohoda o parciálních ústupcích a projekt pokračuje.

Tábor třetí – Výrobek Dodavatele je vadný a plný nedodělků!

Špatně definované procesy se postupně vynořují z mlhy. Banka začíná pomalu, ale jistě chápat funkčnosti a standardy zakoupeného řešení. Začíná identifikovat nutná vylepšení, rozšíření a přizpůsobení a jak pracnost, tak délka trvání projektu se dramaticky navyšují. „Slibovali jste nám, co nemůžete dodat“ říká Banka! „Požádali jste o nestandardní procesy či funkce, na což jsme vás v RFP upozornili“ reaguje na to Dodavatel. To vytváří šum a nejistotu v projektu, protože najednou je definice rozsahu na vodě, stejně jako vztah Banky a Dodavatele. Opět hledá Banka alternativy, mnoho času a peněz je prohýřeno hrou na hledání viníka. Na konci čeká zpravidla výměna vrcholového vedení projektu na straně Dodavatele, dohoda o parciálních ústupcích a projekt pokračuje.

Tábor čtvrtý – Možná bychom měli projekt zrušit a soudit se!

Banka je stále naštvaná! Cítí se podvedena a zrazena. Zvítězí pýcha, která dovede Banku až na pokraj zrušení projektu a přenechání celé věci právníkům. Naštěstí extrémní opatření obvykle také vede k extrémní introspekci. Zdravá sebekontrola obvykle dovede banku zpět ke strategickým rozhodnutím učiněným ve vztahu k výběru řešení s tím, že potřeba transformovat tu stále existuje a nikam nezmizela. To obvykle Banku stáhne zpět od okraje a projekt pokračuje.

Tábor pátý – Možná neznáme svoje vlastní procesy?

Čtvrtá fáze obvykle vede Banku k otázce vlastního chápání svých procesů. Pochopení, že celkový pohled na procesy v rámci organizace chybí, jim umožňuje zpochybňovat jejich status quo a otevírá postupný přechod k opravdové transformaci.

Tábor šestý – Možná je to naše organizace?

Přirozený vývoj zpochybňovat status quo procesů obvykle vede k prozření ve vztahu k celkové organizační struktuře Banky a zpochybnění managementu v duchu „silo“ mentality. Interně začíná boj o moc nad definicí a vlastnictvím jednotlivých business procesů a Banka si začíná uvědomovat, že to není IT projekt, ale dramatická transformace businessu s katalyzátorem v podobě výměny core bankingu.

Tábor sedmý – Všichni muži na palubu!

Organizace se probouzí. Výkonný sponzor si uvědomuje, že ve skutečnosti je třeba udělat něco jiného, než sedět na status mítincích. Myšlení ve stylu „Všichni muži na palubu“ se projevuje, jakmile Banka zjistí, že vnitřní rivalita jejich problémy nevyřeší. Normálně v tento okamžik dochází k několika drastickým změnám v seniorních řídících strukturách Banky.

Vrchol – Úspěšný Go-Live, vše je prominuto

Uplynuly dva nebo tři roky s několika mnoho meziverzemi, kdy je konečná transformace připravena k nasazení do produkce. Vždy budou přetrvávat parciální problémy k řešení, ale pro většinu agend je Go-Live úspěšný. Core-banking platforma byla nahrazena, procesy přebudovány a organizace se proměnila k lepšímu. Banka za-pomněla na strasti a bolesti během projektu a často se stává stoupencem Dodavatele a jejich řešení a domnívá se, že Integrátor je důvěryhodným obchodním partnerem do budoucna.

Závěr

S podobnou situací jste se možná již potkali – a nemuselo to být jen v bance, integrační projekty mívají obdobný průběh. Pojďte si tedy s námi těchto pomyslných osm schodů poznání projít společně s průvodci nanejvýš povolanými – s kolegy z Raiffeisenbank, kteří měli to „štěstí“ se této dobrodružné mise účastnit. Prvním z nich je Mirek Štěpnička, který na Everestu vedl stream core-bankingu. V současné době pracuje pro Rajfku jako programový manažer a má za sebou program úspěšné akvizice Citibank. Druhým je Michal Jauker, který se Everestu účastnil jako člen projektové PMO. Nyní Michal vede v Rajfce projektovou kancelář. Akce je pořádána Českou komorou PMI, takže členové PMI mají vstup zdarma. Členové Projektového Undergroundu, kteří do 17.4. pošlou otázku na přednášející, mají také zajištěnu účast zdarma. Pro ostatní platí vstupné 200 Kč. Diskuze proběhne 19.4. od 18:00, místo ještě není určeno.

Dnešní projekty se liší od projektů před 10 nebo 20 lety. Většinou díky zavedení internetu a následnému softwaru založenému na cloudových technologiích způsob, jakým pracujeme – a tedy i naše projekty – prošel revolucí. Charakteristika řady nynějších projektů je v tom, že požadavky na projekt se mohou dennodenně měnit a od odpovědných týmů se očekává, že s těmito situacemi budou pracovat plynule. Zúčastněné strany se chtějí více zapojit do projektů, zatímco jsou stále v procesu, což znamená, že mohou kdykoli změnit svůj názor (a vytvořit další práci pro týmy).

Tradiční (vodopádové) řízení projektů v takové situaci často nevyhoví. Jako řešení se nabízí agilní metodiky. Proto jsou i tématem příští schůzky Projektového Undergroundu. Agilní ale neznamená jenom Scrum. Seznamme se zde proto s další zajímavou metodikou, která pro některé typy projektů je nepochybně vhodnější.

Extreme Project Management (XPM – překlad do češtiny asi ani zatím neexistuje) je krátký a flexibilní tam, kde tradiční řízení projektů není. XPM umožňuje měnit projektový plán, rozpočet a konečný výsledek tak, aby vyhovoval měnícím se potřebám bez ohledu na to, v jaké fázi se projekt nachází, a obvykle zahrnuje projekty, které trvají jen několik týdnů nebo dokonce jen několik dní. Narozdíl od metodiky Scrum však není vázán povinným procesem práce, přesně danou délkou cyklu apod.

Tým, který chce použít XPM musí počítat s tím, že bude třeba učinit několik pokusů o přiblížení se ke správnému a optimálnímu řešení místo toho, aby se jednoduše zaměřil na dokončení všeho po prvním pokusu. Princip je ve využití zkoušek, aby se co nejdíve a nejsnadněji zjistilo, co funguje a co ne. Jde o proces se samočinnou korekcí – když se věci zhoršují, je třeba se vrátit zpět na původní cestu. To vyžaduje odstup od hierarchie při rozhodování, bez něho nelze postupovat rychle ani vytvářet neotřelé nápady. Jde tedy o projekty řízené lidmi, namísto procesu řízených (lidé neupravují své projekty podle modelu, přizpůsobují modely tak, aby odpovídaly projektu).

Plán projektu s ohledem na extrémní řízení znamená, že očekáváme změnu, uznáváme, že časové lhůty se mohou měnit a ponechat prostor pro chyby. To může být pro projektového manažera zvyklého na vodopádový přístup problém. Ale nejen pro něj, i pro jeho okolí.

XPM staví na velice kompetentním samořídícím se týmu. Zároveň má být svižný. Je třeba shromáždit tým lidí, kteří jsou ochotni a připraveni přijmout tuto metodu. Pokud by členové týmu preferovali pomalou práci a chtěli mít pro všechna rozhodnutí schválení vrchním managementem, tak to nebude fungovat.

Společné charakteristiky extrémních projektů, vhodných pro řízení metodou XPM, jsou:

• Požadována rychlá práce a brzký výsledek
• Vysoce komplexní potřeby, nejistota o nejvhodnějším řešení, neznámé výsledky projektu
• Časté změny projektových požadavků v průběhu projektu

XPM vychází z vodopádového modelu. Ale plán musí odpovědět na všechny následující otázky: Kdo to potřebuje co a proč? – Co to bude dělat? – Můžeme dostat to, co je pro dokončení potřeba? Stojí to za to?

Práce se plánujte v krátkých cyklech – několik týdnů maximálně. Během kick-off schůzky při zahájení projektu poskytněte všem plný přehled o dané práci. Nejdůležitější je motivace týmu. Je třeba tým přimět, aby se s prací na velkém novém projektu plně ztotožnil. Odpovězte členům týmu otevřeně na každou jejich otázku a jasně jim sdělte očekávání. V neposlední řadě od prvního dne musí být tento projekt prioritou.

S klientem se komunikuje často, pozorně se sledují jeho potřeby a okamžitě odesílají korigující informace týmu. Postupuje se v pracovních cyklech doprovázených kontrolami, review sessions a pokud se zdá, že se projekt zhoršuje, konají se speciální schůzky určené k novému vymezení projektu.

Protože o motivaci jde v první řadě, doporučuje se při ukončení cyklu udělat malou oslavu, která umožní pocítit, že si týmu vážíte díky této náročnou práci. Také každou schůzku se doporučuje zahájit uvedením úspěchů týmu od posledně.

Typické je, že se nenastavuje více procesů než je nezbytně potřeba. Je velice žádoucí držet takový projekt dle zásady KISS – keep it simple, stupid. Každý projekt obvykle vyžaduje a využívá různé kroky a různé šablony.

Pokud Vás tento popis zaujal, tak další informace o nástroji XPM najdete v knize eXtreme Project Management autora Doug DeCarlo. Jedná se o velmi podrobné informace o všem, co byste měli vědět, abyste mohli začít s XPM, včetně tipů na navrhované schůzky, jednání se zúčastněnými stranami a vyřešení projektových problémů. Knihu je možno koupit, případně ji mohu zapůjčit.

Na závěr si dovolím parafrázovat jeden z příkladů uvedených v této knize. Autor uvádí, že první použití této metody je svázáno s Noemem. Dozvěděl se totiž, že bude potopa. Obvyklé řešení povodní spočívá v tom, že se přesunete na vyšší místo, třeba na kopec. Tedy řešení potopy klasickým projektovým řízením by spočívalo v hledání nejvyšší polohy, kam voda nedosáhne. Případně, pokud by se ukázalo, že to nestačí, tak jako změnový požadavek by se na nejvyšším kopci ještě stavěla věž. XPM ale motivuje členy týmu hledat co největší škálu řešení, i ta neobvyklá. A proto v týmu řízeném metodou XPM se patrně dřív nebo později najde nápad nestavět věž, ale loď, protože pak je hloubka vody při potopě irelevantní. No a metodika XPM také nabízí postupy, jak najít z množství řešení to nejvhodnější – což je v případě potopy právě ta loď.

Co je to logický rámec projektu? Podrobně se o tomto nástroji dočtete v nejedné publikaci, mimo jiné i v metodice IPMA. Dnes Vám zde nebudu popisovat příliš teorie, ale rád bych Vám ukázal, jak mi tento nástroj pomáhá v praxi řízení projektů.

Na začátek tedy něco málo z teorie.

Logický rámec (také logická rámcová matice – LRM) slouží jako pomůcka při stanovení základních parametrů projektu. Jde o součást metodiky návrhu a řízení projektu označované jako „Logical Framwork Approach (LFA)“. Celkově jde o nástroj, který uceleně řeší všechny etapy projektu od přípravy, přes návrh a realizaci až po vyhodnocení projektu (Zdroj: http://www.pmconsulting.cz/pm-wiki/logicky-ramec/).

Tato metodika vznikla již v 70. letech minulého století ve spolupráci firmy Principals Concepts Inc. – PCI a USAID, tedy United States Agency for International Development. Díky své univerzální koncepci se velmi rychle se rozšířila do mnoha odvětví nejprve v USA a následně do více než 35 zemí  po celém světě. ^{(Zdroj: http://www.pmconsulting.cz/pm-wiki/logicky-ramec/)}

Jak logický rámec vypadá? Jde o tabulkový zápis rozkladu projektu do jednodušších celků, doplněný o akceptační kritéria každého z nich a podmínky, za kterých je možné jich dosáhnout. Zdroje (lidé i materiál, zboží, SW), se kterými projekt budu dodávat a náklady na tyto zdroje. Často se také do matice uvádí, co není součástí projektu.

Tabulka 1 – Obecná struktura Logického rámce projektu

Jak přesně s logickým rámcem projektu pracovat si můžete přečíst například v publikaci Projektový management podle IPMA, kde je celá problematika podrobně vysvětlena.

Jak mi v praxi logická rámcová matice pomáhá?

Logická rámcová matice (dále jen LRM) je velmi univerzální a jednoduchý nástroj pro řízení projektů. Osobně jej používám jak ve fází plánování, tak v dalších fázích projektu. Můj přístup je následující.

Ve fázi plánování sestavím základní strukturu LRM, to znamená, že dle požadavků, které mám od zákazníka projektu, stanovím jasný a měřitelný cíl, po dohodě se zákazníkem nastavím i očekávané přínosy. Navrhnu rozpad cíle do dodávek a sepíšu základní aktivity (tedy úkoly), které je třeba odpracovat a s kým, abych měl s projektovým týmem o čem diskutovat. Tato metoda se mi osvědčila hlavně proto, že nenechávám aktivitu pouze na projektovém týmu, ale povzbudím je hned na začátku tím, že něco je již hotovo. Ale jako projektový manažer nejsem schopen sám postavit celý věcný rozsah každého projektu, ani to není mým úkolem, proto se opravdu ani nesnažím LRM vymyslet sám – i když bych někdy mohl. Dokonce často úmyslně vynechám některé „dodávky“ nebo „aktivity“, abych podpořil diskusi týmu. Členové týmu mi potom sami doplňují dodávky, na které jsem „zapomněl“ a rozpadají je do aktivit, které je nutno odpracovat, aby vůbec dodávka vznikla. V rámci této diskuse již rovnou slýchám, čeho se projektový tým obává, tedy hrozby pro budoucí analýzu rizik. Tyto hrozby osobně přetavím do podmínek, za kterých jsme schopni projekt dodat. Ty zapisuji do 3. sloupce, a to i přesto, že to není úplně metodicky správně, protože v tomto sloupci by měly být pouze externí hrozby, které nemohu nijak ovlivnit. Nicméně v praxi se mi osvědčilo, že 3. sloupec v podstatě používám jako zjednodušený risk log.

Když mám tímto způsobem naplánovaný projekt s přiřazenými zdroji a náklady na ně, ptám se návodně týmu dál, abych dokázal vyplnit i 1. a 2. sloupec. To znamená, ověřitelné ukazatele, že byl úkol či dodávka nebo cíl splněn a dle čeho tak soudím. Používám aktivační dotazy. Jak mi dokážete, že je váš úkol splněn, tak, abych to pochopil, i když danou problematiku neznám? (to je dotaz na 1. sloupec) Proč mám věřit tomu, že dané měření je správné? (dotaz na 2. sloupec). Tímto způsobem vyplním ke každé dodávce i cíli měřitelné ukazatele a zdroje, na základě kterých tyto informace dodávám.

Uvedu příklad z praxe.

Otázka:

Jak mi dokážete, že jsme nakonfigurovali daný HW správně?

Odpověď:

Provedeme akceptační testy a doložíme, že zařízení funguje.

Otázka:

Proč mám věřit akceptačnímu testu, který jste provedli?

Odpověď:

Tento akceptační test byl proveden v souladu s ISO, požadavky zákazníka apod.

Otázka:

A kde to všechno naleznu?

Odpověď:

Existují akceptační scénáře, popsané například v příloze Zadávací dokumentace, nebo v normě, ISO.

Dále se ptám na hrozby.

Otázka:

Čeho se v rámci dodávky XY obáváte, co by se mohlo pokazit, nebo na čem je to závislé?

Odpověď:

V dané dodávce bývá problém s nestabilní kvalitou SW od výrobce.

Daný HW nemusí být plně kompatibilní se sítí zákazníka, i když je to v dokumentaci od výrobce napsané.

Existuje reálná možnost, že HW nedorazí v avizovaném termínu.

Bude nutná spolupráce s autoritou. Osvědčení, certifikace apod.

Tímto způsobem si udělám obrázek o tom, co všechno je třeba udělat, abych dodal všechny části projektu a následně tím splnil cíl. Také zjistím, co mi hrozí, na co se raději připravit předem a případně to i komunikovat se zákazníkem projektu. Kolik mne to bude nakonec stát nehledě na to, za kolik byl projekt prodán. Koho budu potřebovat do projektového týmu a co všechno musím objednat za zboží, nebo také podpůrné materiály a pomůcky pro členy týmu.

Po interní schůzce s projektovým týmem běžně s LRM odcházím k zákazníkovi projektu, kde mu na té stejné matici prezentuji realitu projektu. Opět formou dotazů.

Vážený zákazníku, pochopil jsem to tak, že to, proč to všechno děláme je, že potřebujete dosáhnout přínosu ve formě X. Počkám na souhlas.

Víte, že tyto přínosy nejsou v kompetenci projektu, který děláme, protože mimo dodání cíle našeho projektu musí nastat podmínky Y? Počkám na souhlas, případně vysvětluji.

Nyní k cíli. Je toto cíl, na kterém se stále shodneme? Dodat Z do 1.1 za peníze P? Počkám na souhlas, případně vysvětluji.

Nyní tedy k vysvětlení toho, jak cíle dosáhneme, co budeme potřebovat a za jakých podmínek můžeme cíl garantovat. Zde vysvětluji rozpad na dodávky, jak dokážeme, že jsme je splnili, kdy to budeme kontrolovat a jak.

Následně pouze rychle naznačím, že za dodávkami stojí celá řada úkolů, abych podpořil to, že projekt není jednoduchou záležitostí a ujistil zákazníka, že přesně víme, co všechno je třeba udělat, abychom společně uspěli.

Jako poslední věc shrnu, o čem jsme se bavili, a dodám, co není v rozsahu projektu řešeno, je to mimo scope.

Pokud je k tomu možnost, LRM si zákazníkem nechám podepsat.

Ve fázi realizace následně kontroluji jednotlivé úkoly, které mají přiřazeni konkrétní lidé a hlídám pracnost (a náklady), které na úkol byly odhadnuty, naplánovány.

Mám do celého projektu VHLED, vím, co se má stát, abych docílil jednotlivých dodávek a jak si ověřím a následně budu deklarovat, že byly splněny správně a v plném rozsahu. Dále monitoruji a řeším hrozby, případně rozpracované do rizik, které jsme zapsali v podmínkách.

Ve fázi ukončení a vyhodnocení projektu mám podklad pro akceptaci projektu jako celku, LRM použiji jako check list a součást akceptačního protokolu se zákazníkem projektu.

Interní vyhodnocení projektu provedu také na základě LRM, kdy mám prostor porovnat skutečné plnění, náklady, termíny s plánem pro jednotlivé celky i projekt celkově.

Článek připravil Jakub Vodička a byl publikován ve 3. čísle Zpravodaje 2018