Projektový Underground

Jak zjistíte, kdy je nutné eskalovat rozhodnutí na projektového sponzora? Následující anketa, zpracovaná podle PM network, časopisu PMI(R), ukazuje promítání kulturních rozdílů do úvah na toto téma. A jak jste na tom vy? Položili jste si také otázku kdy eskalovat a kdy ne? Třeba Vám některé z informací a postupů v anketě pomohou najít pro Vás správnou odpověď.

DODRŽUJ PRAVIDLA
Eskaluji rozhodnutí, je-li mimo moje oblasti kontroly nebo dohodnuté tolerance. Například v nedávném projektu, který přinesl procesní změnu, jsme si uvědomili, že konkrétní řešení schválené sponzorem nebude v každé situaci fungovat. Věděli jsme, že se musíme vrátit k základu. Ale protože to znamenalo změnu přístupu k projektu a odchýlení se od schváleného řešení, bylo to rozhodnutí, které měl udělat sponzor. Jakmile sponzor přezkoumal nový postup a schválil ho, byl tým schopen pokročit v projektu.
-Elizabeth Herrin, ředitel, skupina Otobos, Horsham, Anglie

PŘIPRAVENO K ŘEŠENÍ
Nikdy nechci, aby byli sponzoři a klíčoví akcionáři překvapeni. Pokud je třeba eskalovat něco, obvykle je to riziko, a je třeba mluvit o možnostech jeho zmírnění. Pokud se objeví překvapení, budu s týmem rychle hledat možnosti řešení a naše oficiální doporučení předložím sponzorovi. Moje konverzace s ním je proto krátká a věcná a vyhýbá se hledání viny. Našim společným úkolem v tomto okamžiku je vyřešit problém.
Jason Orloske, PMP, manažer, odd. projektového managementu, Aldevron, Fargo, Severní Dakota, USA

KRITICKÁ KRITÉRIA
Především by měl projektový manažer získat důvěru sponzora a podporovat ho od začátku až do konce. Tím je zajištěno, že jakýkoliv problém může eskalovat ve správný čas. Ale nelze eskalovat na sponzora každé rozhodnutí, tím ztratíte jeho pozornost v okamžiku, když je eskalace skutečně nutná. Projektoví manažeři by měli eskalovat rozhodnutí na sponzora, když nastaly následující problémy
– Problém ovlivňuje schopnost získat financování, vynakládat zdroje nebo dosáhnout úspěchu projektu.
• V celé organizaci není podpora projektu.
• Rozhodnutí vyžaduje oprávnění ke změně rozsahu.
• Rozhodnutí vyřeší situaci typu „go / no-go“.
Ipek Sabra Ozgöler, PMP, projektový manažer, kancelář pro řízení projektu, Halkbank, Ankara, Turecko

PLÁN PRO DISKUSE
Mám setkání se sponzory na dvoutýdenní bázi, kde mluvíme pouze o rozhodnutích nebo jak řešit rizika a problémy. Tyto schůzky představují typický prostor, kde eskaluji problémy – pokud riziko není tak velké, aby nemohlo počkat na setkání. Ale eskaluji pouze takové problémy nebo rizika, která silně ovlivní časovou osu, rozpočet nebo rozsah.
Fernando Perez, PMP, regionální projektový manažer, Citi, Buenos Aires, Argentina

PODMÍNĚNÉ PROBLÉMY
Jakékoli rozhodnutí, které může mít vliv na náklady, harmonogram nebo rozsah by mělo být eskalováno na sponzora. Abyste získali okamžitou pozornost a rychlou odpověď, eskalace by měla být přímo nebo telefonicky. Následný e-mail může obsahovat požadavek na rozhodnutí a detily k předmětu rozhodnutí.
Charanjeet Singh, PMP, projektový manažer, pojišťovna Wawanesa, Winnipeg Manitoba, Kanada

NEBEZPEČNÉ RIZIKO
Eskalovat pouze tehdy, když klíčový účastník záměrně brání implementaci plánu projektu. Jedním z příkladů je klient, který odmítá formálně přijmout výsledky během procesu validace rozsahu, a to i poté, co výsledky prošly procesem kontroly kvality. Identifikoval jsem všechna rizika s tím spojená a připravil jsem rezervu na tato rizika v plánu, který jsem předal sponzorovi ke schválení.
Talal Benothman, PMP, generální ředitel, Design, inženýrství a architektura Dar At Rijádu, Rijád, Saúdská Arábie

Víme, že existuje řada projektů. Například při tvorbě metodiky je velkou otázkou, jak kategorizovat projekty – dost často se to udělá pouze na základě finančně vyjádřených nákladů, a postupně se ukáže, že to není dobré. Správné definování kategorií projektů v dané organizaci je ale užitečné z několika důvodů. Proces řízení životního cyklu projektu se v jednotlivých kategoriích značně liší a pro každý projekt je třeba aplikovat nejvhodnější postup. Rozvojem a neustálým zlepšováním procesu pro každou kategorii projektů mohou manažeři zajistit jistý stupeň standardizace, který bude použit pro řízení jejich projektů.

Existuje mnoho způsobů kategorizace projektů; například: velikost, komplexnost, zeměpis, technologie, riziko (ekonomické, technologické, politické), povaha konečného produktu nebo výsledku, podnikatelský nebo průmyslový sektor, zúčastněný hospodářský nebo politický sektor a další.

Základní typy projektů s podobnými procesy řízení projektů

Deset doporučených základních kategorií projektů je uvedeno v následující tabulce. Projekty v rámci každé z těchto kategorií mají během svého životního cyklu velmi podobné fáze a využívají velmi podobnou autorizaci, plánování, rozpočtování, sledování a kontrolní postupy a nástroje. Ve většině z 10 základních kategorií jsou také identifikovány podkategorie, protože mezi procesem řízení životního cyklu základní kategorie a podkategorií mohou existovat rozdíly, v některých případech významné.

Tyto kategorie se nemusí nutně vzájemně vylučovat: mnoho projektů bude zahrnovat aspekty dvou nebo více kategorií. Například většina projektů telekomunikačních systémů zahrnuje přizpůsobení softwaru informačního systému. Mnohé staqvební projekty, jakkoliv z jiné katefgorie, rovněž zahrnují telekomunikační systémy a naopak. V takových případech by měl být projekt pravděpodobně zařazen do dominantnější kategorie nebo, pokud je to odůvodněno jejich velikostí, složitostí nebo definovaným rizikem, jako dva nebo více projektů (různých kategorií) v rámci programu.

Kategorizace programů

Programy často obsahují projekty a ty jsou ze dvou nebo více základních kategorií. Mezi hlavní programy telekomunikačních systémů patří nejen projekty v kategorii telekomunikace ale například i zařízení, letectví či informačních systémů. Každý projekt musí být naplánován a řízen pomocí jeho individuálního procesu řízení, nad tím je na úrovni programu integrace, která spojuje jednotlivé projekty na příslušných bodech nebo v událostech.

KLASIFIKACE PROJEKTŮ V RÁMCI KATEGORIE

V rámci jednotlivých kategorií projektů se často ve velkých organizacích vyskytuje široká škála projektů – od malých po velké. Proces řízení projektu pro každou kategorii projektů musí tak0 reflektovat dal39 aspekty a poskytnout flexibilitu při výběru správné úrovně plánování a kontroly.

Velikost projektu

Velikost projektu může být měřena v několika směrech: nejvíce hmatatelné a zřejmé je množství peněz, lze však využít i množství dalších vzácných zdrojů (lidé, dovednosti nebo zařízení), velikost rozsahu (například počedt use-case v analytickém dokumentu) či geografický záběr. Větší projekty obvykle přinášejí větší rizika – ale ne vždy.

Složitost projektu

Složitost projektu je charakterizována rozmanitostí, která je součástí cílů a rozsahu projektu, a počtem různých zúčastněných interních a externích organizací a oddělení, což je obvykle ukazatel počtu požadovaných odborných dovedností, zdrojů technologií nebo zdrojů financování. Projekt, který vyžaduje pouze dovednosti a další zdroje jedné provozní divize, je obvykle z hlediska řízení méně složitý než projekt společného podniku podporovaný dvěma samostatnými společnostmi. Složitost vzrůstá exponenciálně s počtem zúčastněných organizací. Běžným zdrojem složitosti projektu je i míra interakce s operacemi mimo projekt. Projekty, které jsou prováděny pod dohledem regulační agentury jsou obvykle složitější než projekty bez dozoru.

Externí nebo interní zákazník

Je-li projekt realizován na základě formální smlouvy s externím zákazníkem, bude řízení poněkud jinak než kdyby byl zaměřen na interního zákazníka. Smluvní podmínky mají přímý vliv na míru rizika spojeného se smluvním projektem; a pokud jsou dobře navrženy pak mohou rizika zmírnit. Interní projekty obvykle nejsou provázeny právními omezeními a postihy, což může vést k podcenění plánování a kontroly projektů. To zvyšuje riziko, že projekt nesplní požadované cíle.

Relativní význam daného zákazníka má často velký vliv na prioritu projekt a způsob jeho řízení.

Stupeň zapojení zákazníka do projektu

Na mnoha projektech se může zákazník podílet výraznou měrou. Obvykle dělá důležitá rozhodnutí a poskytuje klíčové know-how. Nesoučinnost zákazníků je častými příčinami zpoždění a zvýšených nákladů. Je proto nezbytné, aby byly zákaznické části projektu naplánovány tak, aby byly dobře integrovány se zbytkem projektu. To znamená, že projektový manažer zákazníka se aktivně účastní zasedání týmu, hodnocení projektu a že je především zodpovědný za součinnost poskytovanou do projektu.

Úrovně rizik v projektech

Rizika spojená s projekty se liší v rámci jednotlivých kategorií projektů. Některé z hlavních faktorů, které ovlivňují riziko, jsou:

• Novost a neznámost (nízká míra zkušeností) daného typu projektu pro organizaci.

• Velikost, jak bylo popsáno výše.

• Doba trvání a naléhavost dokončení: Vyšší riziko v případě krátkého trvání s pevným datem ukončení nebo dlouhého trvání s pravděpodobnými nepředvídatelnými ekonomickými nebo politickými změnami.

• Složitost, jak bylo popsáno dříve.

• Technologie: stupeň inovace a nejistota ohledně technologie výrobku nebo jeho výrobního procesu (může souviset s novostí).

• Externí zákazník (projekt na zakázku) nebo interní zákazník, jak bylo uvedeno výše, a jejich celkový význam pro organizaci.

• Smluvní podmínky: sankce, záruky, směnky.

• Potřebný regulační dohled a schválení.

• Stupeň zapojení zákazníků do projektu.

• Volatilita trhu.

• Dostupnost omezených zdrojů: kvalifikovaní, zkušení lidé, specializovaná zařízení.

Hlavní a drobné projekty v rámci kategorie

Je vhodné identifikovat nejméně dvě třídy projektů v každé kategorii. Obvykle se nazývají jako velké a malé projekty, ale organizace může využívat i jiná jména. V některých organizacích jsou dokonce definovány tři takové třídy (např. A, B a C). Rozdíl mezi velkými a malými třídami je uveden v následujících definicích:

• Velké projekty jsou ty, jejichž velikost, velká složitost a / nebo vysoké riziko vyžadují:

• • Nutnost formálního ustavení sponzora projektu.

  • Alokace manažera projektu (nebo programu) na plný úvazek.

  • Plné uplatnění procesu řízení projektů specifikované pro konkrétní projektovou kategorii pro velké projekty (všechny specifikované formuláře, schválení, plány, plány, rozpočty, kontroly, zpětné vyúčtování, časté schůzky pro přezkoumání projektů, se značnou mírou podrobnosti v každý).

• Malé projekty jsou projekty, jejichž velikost, jednoduchost a nízké riziko umožňují:

• Jeden projektový manažer může současně řídit dva nebo více projektů.

• Neúplné uplatnění celého procesu řízení projektů pro ¨danou kategorii (používají se pouze vybrané základní formuláře, schválení, plány, plány, rozpočty, kontroly, zprávy, méně časté přezkoumání projektů, s menšími podrobnostmi požadovanými v každém z nich).

• Někdy ani nevyžaduje formální ustavení role sponzora projektu.

Kromě těchto velkých a menších projektů se někdy můžeme potkat s tzv. mega projekty. Jedná se o mimořádně velké projekty, které obvykle zahrnují velké množství společností a / nebo agentur. Příklady takových mega projektů jsou mezinárodní společné podniky v oblasti vesmíru, dopravy, energetiky a dalších oblastí. Megaprojekty mohou být financovány z různých zdrojů: vládních, soukromých a mezinárodních rozvojových bank a obvykle překračují mezinárodní hranice. Mega projekty jsou mimo rozsah výše popsané velké klasifikace projektů, ale jsou spíše vzácné.

Zpracováno dle knihy Archibald R.D., Managing high-technology programs&projects

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ď.