Projektový Underground

Pokud jste se připravovali k projektové certifikaci, určitě jste se s těmito pojmy setkali. Asi jste našli i definici. Umíte si ale pod těmito pojmy něco rozumného představit? A co víc – umíte je ve svých projektech využít, nebo to jsou pouze faktory, které vás trápí? Pojďme se na ně podívat podrobněji.

Enterprise Environmental Factors (EEF)

Jsou to interní a externí faktory, které obklopují váš projekt. Stejně jako s počasím – proti chladu a vlhku je třeba se chránit, tak musíte i svůj projekt přizpůsobit EEF.

Příklad č. 1 – kultura organizace

Podnikatelskou kulturu definují přijaté a sdílené organizační hodnoty, chování, postoje, přesvědčení a zvyklosti ve firmě. Vyzkoušejte si. Pokud zvolíte „a“ na většinu vašich odpovědí na následující otázky, tak se firma vyznačuje „podnikatelskou“ kulturou a bude mít úspěch minimalistický management projektů – zajišťujte jen klíčové postupy. Naopak, pokud máte více odpovědí „b“, dostáváte se do stavu, který jsem zažil např. ve velkých bankách, které vytváří byrokratickou kulturu.

1. Zaměřuje se vaše organizace na a) výsledky nebo b) procesy?

2. Poskytuje Vám organizace a) rozhodovací pravomoci nebo b) naopak potlačuje osobní iniciativu?

3 Podnikání firmy a) vyžaduje neustálé inovace a zdokonalování nebo b) staví na efektivních procesech?

4. V tom, jakým způsobem lidé pracují, převažuje a) interní politika a konflikty nebo b) spolupráce?

Příklad č. 2 – strategický plán

Zkusili jste zjistit, zda organizace, v níž působíte, má písemný obchodní strategický plán. Možná budete šokováni, když zjistíte, že nemá. V takové situaci je projekt, pokud se pokouší dosáhnout výsledků vyplývajícího z nepochopeného nebo neexistujícího strategického plánu, skutečnou výzvou. Bez strategie nebude váš projekt ovlivňován těmi zájmy, které jsou nejlepší pro celou společnost, tedy nebude v souladu se zastřešující strategií. Pomoc může spočívat v doplnění určitého časového bufferu (rezervy). Ale hlavně v základní listině projektu (project charteru) dokumentujte klíčové aspekty neexistující strategie, z nichž vycházíte – a to jako předpoklady. Tedy pokud je to možné, zkuste „vrtět psem“ tím, že sami definujete klíčové strategické prvky, které jsou na kritické cestě projektu.

Příklad č. 3 – Regulatorní komplikace

Regulační orgány a jejich požadavky mohou radikálně ovlivnit organizaci a tím i projekt. Pokud nemáte odpovědi na tyto čtyři klíčové otázky, doporučuji je co nejdřív získat:

1. Víte, které obchodní procesy, které jsou v současnosti ovlivněny regulatorními problémy, ovlivňují váš projekt?

2. Existuje spolehlivá stopa změn v procesech? Kdy a jakými projekty?

3. Je váš projektový plán opravdu v souladu s regulatorními právními požadavky?

4. Existují potenciální interpretace pravidel, které by mohly ovlivnit projekt?

Například v projektu reagujícím na kritickou regulaci v bankovnictví, jeden z kolegů – projektový manažer nepřetržitě zaměřoval zainteresované strany na řešení stávajících i očekávaných regulačních interpretací. Pokud by to neudělal, mohl by být brzy problém s jiným výkladem pravidel, než se zdál na začátku.

Příklad č. 4 – lidské zdroje

Za všemi problémy jsou lidé. Lidé, ač jako jednotlivci nebo ve skupinách, jsou však také vždy klíčem k vítězství. Lidské zdroje jsou velmi důležité. Co k nim poradit:

1. Řiďte vlastníka i svého šéfa.

2. Objevte „hvězdy“ mezi pracovníky firmy a snažte se je získat – ale ne všechny, protože tým ze samých hvězd obvykle nepodává dobrý výkon.

3. Seskupte do svého týmu patřičné dovednosti i týmové role.

4. Snažte se je získat pro projekt lidi, které vám byli přiděleni. Pokud je to možné (což je bohužel málokdy), získejte pro všechny tyto osoby stejný trénink tak, aby se utužily i kolektiv (viz článek v předminulém Zpravodaji).

5. Pokud můžete, hrajte roli, kterou mám rád – roli, v níž nejen vedete projekt, ale také vyučujete a mentorujete.

6. Jak říkají markeťáci, nejdříve „otrhejte nízko visící ovoce“ – tedy zabývejte se tím, co můžete ovládat – tedy sebou samými. Buďte na sebe přísní. Ohodnoťte se, a to ve vztahu k uvedeným zručnostem, a zlepšete se tam, kde jsou mezery.

Příklad č. 5 – externí drivery

V každém odvětví průmyslu, ve výrobě, v bankovnictví, v médiích, v dopravě, v těžbě a samozřejmě i v IT běží projekt v rámci řady externích sil a podmínek.  Konkurenční síly, trendy a měnové pohyby jsou některé z mnoha, které je třeba zvážit.

Je znám osvědčený postup z analýzy rizik – uvažte politické, ekonomické, sociální, technologické, právní a environmentální (ve smyslu obecné okolí projektu) trendy. Jde o metodiku – P.E.S.T.L.E. používanou v analýze rizik. Analyzujte trendy a jejich vliv na vás. Vzhledem k tomu, že trendy jsou jako rizika, protože se v budoucnosti mohou měnit, doporučuje se je také jako rizika spravovat. Tedy využijte metody pro práci s riziky – zabránění, zmírnění, přenos a případně přijetí pro negativní trendy. A nezapomeňte, že rizika mohou být i pozitivní, a trendy samozřejmě také.

Příklad z praxe: v projektu pro malou mediální společnost je vhodné zdůraznit společenské a demografické trendy publika a čtenářů.

Organizational Process Assets (OPA)

Není to jen kultura státu, v němž projekt probíhá, například dochvilnost, pečlivost, obecná kreativita, vzdělanost. Jsou to například i nejlepší postupy v oblasti průmyslu, místní zkušenosti, zásady, postupy a pokyny. Tedy například brány („gejty“) pro schválení projektů, procesy hodnocení výkonu či přístupy k financování. PMI výslovně doporučuje projektovým manažerům, aby OPA využívali k „ovlivnění přístupu k projektu“. Doporučuji, abyste je rozpoznali a pro úspěch projektu je využili. Pojďme si jich pár představit.

Příklad č. 1 – OPM3

Setkali jste se s měřením vyspělosti organizace v projektovém řízení? PMI jej nazývá jako model zralosti organizace (OPM3). Vzhledem k tomu, že OPM3 představuje celopodnikový rámec a systém hodnocení portfolia, řízení programu a řízení projektů, pomáhá rozpoznat skutečnost, zda procesy firmy ulehčí nebo naopak zničí projekt. Bohužel, u nás je to zatím většinou „španělská vesnice“. Potřebujete více informací? Podívejte se třeba na wikipedii.

Příklad č. 2 – Project Portfolio Management (PPM)

Norma PMI pro správu portfolia definuje portfolio jako „Centrální řízení jednoho nebo více portfolií, které zahrnují prioritizaci, schvalování a kontrolu projektů, programů a další související práce k dosažení konkrétních strategických a obchodních cílů.“ PPM umožňuje vedoucím činit časově a fakticky lepší rozhodnutí. Tedy i racionálněji rozhodovat o všech projektech v nejlepším zájmu celé organizace. Rozčarování a stížnosti by se měly zmenšit, když se například dozvíte, že projekt bude odložen, protože jste ztratili cenný zdroj na určitou dobu určený kvůli projektu vyšší priority. Je to totiž objektivní důvod a racionální a zdůvodnění.

Tam kde PPM neexistuje, organizační prostředí zpomaluje exekutivní podporu v pravý okamžik, protože dochází ke srovnání s typicky stovkami konkurenčních priorit. Budete se muset více spoléhat na vašeho sponzora, aby efektivně eskaloval a problémy s řešením problémů. A asi se nevyhnete i „interní politice“ abyste získal větší prioritu.

Příklad č. 3 – programové řízení

Nepoužívejte kladivo k řezání dřeva a nepoužívejte projektové řízení na program. Program je skupina vzájemně propojených projektových a neprojektových komponentů, které jsou lépe spravovány společně, aby získaly výhody, na které by nedošlo, kdyby byly spravovány jednotlivě. Ale pozor, program se nepozná podle toho, že je velký, ale podle jiných kritérií (ve skutečnosti ani velký být nemusí, zatímco např. implementace SAPu je typicky velký projekt a nikoliv program). Více o tom proběhlo na samostatných přednáškách projektového Undergroundu a na našem WEBu je možno dohledat prezentaci, případně též viz http://www.ippproject.com/skoleni-a-priprava/od-rizeni-projektu-k-programu/. Praktická podskupina postupů spojených řízením programu, z nichž každá jde radikálně za rámec svých projektových protějšků, jsou: Governance, Řízení podílníků a Řízení benefitů.

Příklad č. 4 – COBIT a ITIL

V dnešní době se mnoho projektů zabývá malými, středními a často i velkými částmi z IT. Uvedené metodiky poskytují hodnocení a rámec pro řízení s důrazem na správnou správu IT, a to směrem k realizaci podnikání, nikoliv pouze technicistních cílů. Projekt je třeba této metodice přizpůsobit – formálně i prakticky. Výhodnou je leckdy navedení na správnou cestu k řešení problémů.

Příklad č. 5 – životní cyklus produktu

Pochopení a zajištění toho, aby všechny zúčastněné strany pochopily své role v životním cyklu, je jedna z prvních věcí v chápání vašem i podílníků projektu. Strojírenství, IT, stavebnictví a tak dále mají modely životního cyklu výrobku. V IT to může být například ITIL, zmíněný v předchozím bodu. Tyto modely charakterizují etapy, aktivity, role, odpovědnosti, nástroje a techniky. Při neexistenci metodologie životního cyklu se očekávání liší od pracovních postupů – kdo dělá co, jak a kdy, a může vést k dysfunkčnímu chaosu. A co dál? Dejte si pozor na stav těchto klíčových faktorů. Pomozte je změnit, je-li to potřeba, a můžete-li. Dokonce i dětské krůčky mohou pomoci. Nemůžete-li je změnit, pak je identifikujte, vyřešte problémy a přizpůsobte se jim. C�q���

Řízení benefitů je aktuální téma Project Management Institutu. Ukazuje se, že malé, střední a zejména velké firmy jsou zahlceny množstvím projektů a programů. Nicméně sleduje někdo skutečný přínos těchto projektů a programů? Neslouží pouze k vyplnění času a k prokázaní nepostradatelnosti manažerů, leaderů a jiných vedoucích pracovníků? Kdo má vlastně benefity hlídat? Pojďme se na to podívat detailněji.

Úlohou projektového manažera je dodat projekt v požadovaném čase, rozsahu, nákladech a v odpovídající kvalitě. Předmětem projektu je v názvosloví PMI myšleno „OUTPUT“. Může to být produkt, služba nebo jiný výsledek činnosti. Projektoví manažeři dle mých zkušeností cítí za dodání požadovaného outputu odpovědnost a jsou připraveni za něj položit život. Ale co dál, když je projekt hotov, přinese zákazníkovi potřebný užitek? Má pro něj očekávanou hodnotu a přínos? Daný výsledek realizovaný pomocí „outputu“ je v terminologii PMI definovaný jako „OUTCOME“.

Demonstrujme následujícím příkladem.

Zadáním v chartě projektu je aplikovat systém na správu projektové dokumentace v daném čase, nákladech a ve specifikovaném rozsahu. Tímto je tedy definován „output“. Při definici tohoto projektu bylo hlavním cílem sponzora projektu snížení chyb v dokumentaci o 10 procent, čehož chtěl docílit právě výše uvedenou implementací nového informačního systému zaručující správný tok dokumentace. Snížení počtu chyb v dokumentaci o 10 procent je tedy plánovaný „outcome“ projektu.

Daný projekt může být součástí programu, který je úzce spojený se strategií společnosti.  Programy jsou realizovány tak, aby přinesly společnosti očekávaný „BENEFIT“. Benefit může být definován jako měřitelné vylepšení dosáhnutého díky výsledku „outcome“ z projektu/programu. Toto vylepšení musí být chápáno jako výhoda jednou nebo i více zainteresovanými stranami projektu/programu, která přispívá k dosažení cíle společnosti. Právě hlídání dosažitelnosti benefitů je jedním z  úkolů programového manažera. Během programu musí neustále posuzovat, zda dané projekty přispívají k plánovanému benefitu . A nejen projekty. Musí sledovat vnitřní i vnější vlivy a soustavně vyhodnocovat jejich vliv na program a jeho plánované benefity.

V našem případě může být projekt implementace nového IT systému součástí strategického programu na snížení nákladů společnosti o 5%. Snížení chybovosti v dokumentaci přinese menší počet hodin na opravu dokumentů a tím přispěje k danému strategickému cíli.

Posledním výrazem používaným v terminologii PMI je „VALUE“, tedy hodnota. Hodnota je definována jako čistý zisk z realizovaných benefitů , tj. zisk programu mínus jeho náklady. V praxi to poté vypadá tak, že projektový manažer je ze své pozice odpovědný za implementaci systému na správu dokumentace a zároveň spolupracuje s programovým manažerem, aby to vedlo k požadovanému snížení počtu chyb v dokumentaci o 10 procent. Programový manažer ze své pozice vyhodnocuje, jak dané snížení chybovosti vede ke snížení provozních nákladů společnosti. Odečteme-li od zisku získaného z úspor provozních nákladů společnosti náklady na implementaci daného systému, dostaneme hodnotu „value“, kterou daný projekt přinesl.

Daniel Chára

Zde najdete rady jak postupovat v situacích, které byly uvedeny v předchozím příspěvku publikovaném včera.

První situace: Autonomie

Tato hranice je daná kulturou firmy, není obecně definována. Otázka souvisí s autoritou PM. Ta formální je dána (metodikou, zvyklostmi, atd.), neformální je třeba postupně získávat. Některé postřehy pro udržení autority:

    • Udržet si nezávislost v srdci. Nebýt vydíratelný.

    • Nezapomenout, že každý šéf má svého šéfa.

    • Jenom hloupý šéf si myslí, že si kupuje zaměstnance a dovozuje, že ho tak trochu vlastní.

    • Hned na začátku kriticky zhodnotit situaci a rozhodnout se, zda tu práci berete nebo nikoli, resp. stanovit si podmínky – plná moc, právo veta, atp.

Druhá situace: Akceptace

Rozumná a v praxi využívaná je akceptace na dvě kola, ve druhém již se pouze potvrzuje zapracování změn. Při extrémním důrazu na kvalitu se přidávají další kola, ale s dopady do plánu.

Třetí situace: Zkušenosti

Jak je organizováno využití Lessons Learned Reportu dalšími projekty a je nějaký proces, který se tímto využitím ve firmě  systematicky zabývá? Jde o to aby tyto informace nebyly využívány pouze projekťákem nebo projekťáky, ale aby nějak regulérně probublávaly.

Pro přenos lessons learned je těžké najít posluchače. Důležitá je ochota naslouchat, proto ani formální záznam včetně jeho navázání na hodnocení PM se neosvědčuje. Důležitá je podobnost problémů reportovaného projektu s tím, co posluchači znají z aktuální praxe. Pro vlastní přenos know-how jsou důležité status meetingy. Úspěšný přenos zkušeností lze dokumentovat na příkladu dvojice postimplementačních review, jednak na úrovni PM a jednak na úrovni vlastníka (tedy business vyhodnocení). Hodnotí se úroveň splnění předpokladů v oblasti business. Toto vyhodnocení udává kvalitu odhadů vlastníka a tento údaj by měl vstupovat jako důležitý parametr do výběru dalších projektů – čím přesnější odhady, tím větší preference pro projekty tohoto vlastníka. Celý tento postup však vyžaduje funkční řízení portfolia ve firmě.

Pokračujeme v seriálu, který čerpá a bude čerpat z ohromného rezervoáru rad a zkušeností získaných na nesčetných diskuzích, které již v rámci Projektového Undergroundu proběhly. Nejde o teoretické rozbory, ale naopak o zcela praktické situace a jejich řešení. Snažíme vybrat situace, které se na diskuzích opakovaly, a také postupy, které v praxi pomohly.

Nejprve najdete popis situace a odpověď či doporučené řešení je až dále v textu Zpravodaje. To proto, abyste si mohl(a) vyzkoušet, jak byste takovou situaci řešil(a) 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: Autonomie

Kde je vhodné aby končily pravomoci PM a kde by měly začínat pravomoci dalších subjektů (řídící rada, PMO, představenstvo firmy, …)?

Druhá situace: Akceptace

Kolik kol (připomínky-zapracování) považujete za optimální pro akceptaci dokumentů (dokumentace, analýzy, cílový koncept, apod.)

Třetí situace: Zkušenosti

Jak je organizováno využití Lessons Learned Reportu dalšími projekty a je nějaký proces, který se tímto využitím ve firmě  systematicky zabývá? Jde o to aby tyto informace nebyly využívány pouze projekťákem nebo projekťáky, ale aby nějak regulérně probublávaly.

Agilita hýbe Českem. Aktuálně se řada bank rozhodla pro přechod svého projektového řízení na agilitu. Jak na tuto módní vlnu reaguje PMI? Specifika agilního řízení jsou uvedena v samostatné příloze PMBOK V6 a zároveň se i pomalu doplňují do certifikačních testů. Uvádíme přehled samostatné přílohy PMBOK ve znění, které je obsahem příručky certifikačního školení viz http://www.ippproject.com/skoleni-a-priprava/priprava-k-certifikaci-pmp/.

Agilita není „tvrdá“ metodika, ale spíš pohled na způsob vedení týmu, doplněný různými rámcovými postupy určenými k úpravě dle specifik konkrétní situace. Agilního řízení je vhodné na komplexní a komplikované úlohy. Tyto pojmy jsou definovány na dvojrozměrné ploše definované nejistotou technického řešení a vágností požadavků. Blíže viz obrázek:

Je možno uvést příklady. Agilní vývoj a řízení jsou vhodné:

• kde je vyžadován výzkum nebo vývoj
• obsahuje časté změny
• požadavky jsou neznámé nebo nejisté, nebo cíl je těžko popsatelný
• obsahují velké množství rizik.

Existují 4 druhy životního cyklu projektů, agilní je jedním z nich. Ale málokdy lze najlézt jednoznačný životní cyklus, v každém projektu jsou nějak více či méně obsaženy, málokdy je v projektu je jeden:

• prediktivní
• iterativní (reakce na zpětnou vazbu z ještě nedokončeného výsledu, např. prototypování)
• inkrementální (dodávky po částech)
• agilní.

Rolí projektového manažera je sloužit týmu, zametat cestičku, což ve výsledku vede k úspěchu celého týmu. Jde tedy o vedení metodou „servant teadership“. Z toho vyplývají i role členů agilního týmu:

• Product owner – vedení technického vývoje produktu
• facilitátor – tedy výše zmíněná podpora týmu. V různých agilních metodikách je nazývána různě, např. scrum master.
• člen týmu. V této souvislosti jsou odborníci, členové týmu, tříděni do dvou kategorií:
  • I-shaped znamená úzké specialisty, s hlubokou avšak nepříliš širokou znalostí
  • T-shaped jsou více obecně zaměření specialisté a pro agilní týmy jsou obvykle výhodnější

Vztah agilního řízení a metodiky Kanban je ten, že jsou konkrétním implementaceni principu Lean. Před rozhodnutím o agilním řízení projektu je vhodné si odpovědět na čtveřici otázek:

• Vize projektu – proč jej děláme?
• Kdo z projektu bude benefitovat?
• Co znamená, že projekt je hotov – odtud se odvíjí kritéria pro release?
• Jak budeme spolupracovat?

Další pojem je retrospektiva. Obvykle se dělá při náselujících příležitostech:

• release
• prošlo již několik týdnů od minulé
• když viditelně klesá výkon týmu
• nebo při dosažení nějakého milníku.

Backlog je tříděný seznam úkolů, nad nimiž tým pracuje. O třídění se stará product owner, zvláště pokud je využit iterativní životní cyklus.

Další pojem je standup. Provádí se denně, hlavním cílem je mikrosouhlas členů týmu s následujcí prací v nejbližší době. Každý člen během standu odpovídá na následující otázky:

• Co jsem od minule udělal / dokončil?
• Co plánuji na dobu do příštího standupu?
• Jaké vidím problémy nebo rizika?

 

Nejznámější metodiky agilního řízení:

název	charakteristika
Scrum	·         U nás nejběžnější ·         Vlastník produktu odpovídá za maximalizaci produktu ·         Team je multidisciplinární a piokrývá celou potřebnou znalostní oblast ·         Scrum master odpovídá za proces (servant)
Extreme programming	·         Celý tým sedí pohromadě ·         Programování v páru – z důvodu testování ·         Desetiminutové úkoly ·         Test-first
Kanban	·         Vizualizace postupu ·         Omezený počet aktivit ·         Spolupráce a zpětná vazba
Crystal method	·         Časté dodávky ·         Uzavřená komunikace ·         Pocit komfortu členů týmu a snadný přístup k odborníkům
Scrumban	·         Na pomezí Scrum a Kanban
FDD (Feature-driven development)	·         Role PM, hlavního architekta, vedoucího vývoje, šéfrogramátora, vlastníka a doménového experta ·         5 procesů: ◦     vývoj cerlkového modelu ◦     vytvoření seznamu vlastností ◦     rozplánování rysů ◦     návrh rysů ◦     realiazce po jednotlivých rysech
AgileUP (Unified Process)	·         Koncentrace na high-level aktivity ·         Nezávislost na nástrojích ·         Infomovanost týmu
Scrum of Scrum	·         Koordinace více malých týmů na velkém úkolu ·         Využítí postupů Scrum
Scaled Agile Framework	·         Pro velké úkoly ·         Inkrementální vývoj s krátkými cykly ·         Systémové mšlení, rozhodování zásadně z ekonomického hlediska
LeSS (Large Scale Scrum)	·         Organizace několika vývojových týmů na společném velkém vývoji ·         Koordinace přes týmy ·         Retrospektiva orientovaná na zlepšení mezitýmové spolupráce
Enterprise Scrum	·         Využití metody Scrum přes celou organizaci
DA (Disciplined Agile)	·         People first ·         Learning-oriented ·         Goal-driven ·         Cykly pro kompletní dodávku

 

Statistika je ošidná věc. Už známá scéna Felixe Holzmanna ukazovala, že pokud jeden sní dvě husy a druhý žádnou, tak vyjde, že husu měli oba. Ale přesto mi zvědavost nedala a zajímal jsem se, kolik je na celém světě nositelů nejprestižnější projekťácké certifikace PgMP (Program Management Professional) a podělil jsem jejich počet obyvatelstvem na planetě. Vyšlo mi, že na desetimiliónovou zemi, jako je ČR, by to měli být tři. A na Slovensko tedy jeden a půl. Jak jsme na tom? V ČR jsme tři nositelé tohoto titulu, tedy přesně podle statistiky, ale na Slovensku zatím o žádném nevím. Vím ale, že je v Evropě i řada větších zemí, kde „svůj průměr“ ani zdaleka neplní, zatímco taková Inde jej výrazně překračuje. Tedy neobávám se říct, že ČR je v počtu certifikovaných programových manažerů vztažených na počet obyvatel na špici Evropy. Nepochybně je to zásluhou společné přípravy k této certifikaci, která pod záštitou České komory PMI již dvakrát v rámci Projektového Undergroundu proběhla.

V příštím běhu přípravy k certifikaci PgMP se budeme účastnit spolu s kolegy ze Slovenska. Přinese to i nové uspořádání, kdy přípravný tým se nebude, jako dosud, scházet face-to-face, ale prostřednictvím videokonference. Přináší to výhodnou možnost se účastnit zájemcům nejen z Prahy, jako dosud, ale i z Brna, Bratislavy či Košic či odkudkoliv jinde. To je zajímavá příležitost, ne?

Jak taková příprava probíhá? Celá oblast programového řízení je rozdělena do cca 25 okruhů. V dohodnutém čase se tým potkává nad dvojicí z těchto okruhů, přičemž čtyři účastníci si připravili a prezentují informace, každý z nich k jednou z okruhů. Následně jsou v celém týmu diskutovány, jednotliví členové mohou porovnávat své zkušenosti a informace s tím, co bylo prezentováno a diskutují o tom. Samozřejmě je přítomen certifikovaný programový manažer, aby mohl korigovat případnou diskuzi v duchu standardu PgMBOK. Ukazuje se, že toto je nejefektivnější cesta k přípravě účastníků, zvlášť pokud je na konci ještě doplněna společným boot-campem, kde se všechna témata projdou ještě jednou společně.

Celá příprava probíhá ve vzájemné spolupráci, tedy zcela zdarma. Tentokrát poběží pod „federální“ záštitou České i Slovenské komory PMI. Jako bonus ještě každý účastník získá program, jehož pomocí si může zkoušku až třikrát vyzkoušet nanečisto na svém počítači. Samozřejmě otázky se liší od těch, s nimiž se při zkoušce setká, ale je ověřeno, že jsou velice podobné. Při opakování testu se otázky mění – v zásobě jich aktuálně mám asi 2500 a z nich si program pro každé sezení vybere jiné. A ke každé odpovědi se dostane i informace, zda volba byla správně, proč je odpověď správná či špatná, a případně jaká je správná odpověď. Tedy je zde zdarma nabízena možnost zkoušky klidu – tedy bonus, který je jinak pouze součástí komerčních kursů k přípravě k certifikaci (viz http://www.ippproject.com/skoleni-a-priprava/priprava-k-certifikaci-pmp/).

Řízení programů je něco jiného než řízení projektů. Praxe jednoznačně ukázala, že projekty charakteru programu řízené metodikou pro řízení projektů představují riziko jak pro firmu, v nichž probíhají, tak pro manažery těchto programů. Pro manažera spočívá riziko ve vyšší pravděpodobnosti neúspěchu, pro firmu je jistě bolestnější. Příčiny toho spočívají v trojici základních rozdílů mezi projekty a programy:

• Programy jsou primárně orientované na výnosy, projekty na náklady.
• Řízení projektů projevuje obecně menší flexibilitu reakcí na vnější vlivy, které naopak jsou v programech určující.
• Relativní uzavřenost projektů – pokud více projektů vzájemně souvisí, vyžaduje vzájemnou koordinaci a pokud taková koordinace není, přenáší se na liniový management.

Není ale ani pravda druhý extrém, že vše jsou programy, právě naopak. Ale to nic nemění na nezbytnosti detekce programů v portfoliu projektů firmy a přizpůsobení metody řízení jejich existenci. Platí přitom, že vlastní název nemá obvykle vůbec žádný vztah k tomu, zda jde skutečně o program nebo o projekt. Je na tomto poli ještě hodně k edukaci prostředí a to je a bude role manažerů programu. A co Vy? Řídili jste již rozsáhlý projekt nebo program? Nechcete se přidat a být průkopníkem programového řízení ve své komunitě? Příprava k certifikaci není jednoduchá (tak jak to odpovídá tomu, že jde o nejprestižnější certifikaci PMI), ale stojí to za to! 17. prosince večer proběhne první call zájemců, kde si dohodneme provozní záležitosti – jak, kdy atd. Tak neváhejte se ozvat!

Mimochodem – pokud organizace ve Vašem okolí uvažuje o zavedení programového řízení nikoliv podle názvu, ale tak, aby opravdu programy byly řízeny jako programy, neváhejte se obrátit o radu či pomoc – na mail Igor.Luhan@ippmeasure.com.

Poznámka: první video-schůzka účastníků proběhne 10.1.2019 od 18 hodin