Projektový Underground

Víme, že pro úspěch realizace projektů neexistuje žádný kouzelný vzorec. Projekt řídíme na základě našich zkušeností, typu projektu, rizik, požadavků zúčastněných stran, zdrojů a omezení. Leckdo funguje tak, že jakmile zjistí nebo uslyší o nové technice, která funguje, vyzkouší ji a pokud se osvědčí, do svého projektového řízení je začlení.

Jedním z velkých problémů s projektem, se kterými se setkáváme, je nalezení optimálního tlaku na členy týmu, aby doručovali úkoly včas, ale nebyli ještě demotivováni nepřiměřeným nátlakem. Příliš velký tlak často dusí, příliš malý tlak vede k nedostatku zájmu a nedostatečné výkonnosti.

V březnovém čísle PM network (2019) se na toto téma v článku Right Mix rozepsal Felix Meyer. Podle jeho článku je zpracován i následující text.

Pro nedávný projekt implementace správy bankovních účtů, který se konal na konci roku 2018, jsem tento problém vyřešil mícháním technik, které vznikly ve výrobním světě (společná verze kanbanu), a technikami používanými při vývoji softwaru (setkání standup ) vytvořit úspěšný koktejl.

COLLABORATIVE KANBAN

Klasický kanban (doslovně znamená „značka“ nebo „billboard“) umožňuje výrobním týmům vizualizovat úrovně zásob ve výrobě podle objednávek zákazníků tak, aby mohli reagovat na změny v poptávce. Jedním z klíčových výhod kanbanu je to, že mapování úkolů spouští akci.

Řada výrobců nástrojů pro správu projektů nabízí vizuální elektronickou podobu kanbanu, která doplňuje plán projektu. Ze seznamu se stávají úkoly projektu.

V mém projektu zavedení nástroje kanban pro spolupráci přineslo několik výhod:

• Vylepšená transparentnost úkolů pro manažera projektu i členy týmu (co se děje nebo je třeba ještě udělat).
• Jasná komunikace o termínu každého úkolu.
• Flexibilita při vytváření nových položek pro seznam, pokud se stávající úkoly musí rozpadnout nebo se objevují nové položky.
• Lepší sledovatelnost a dokumentace na všech stupních pracovního cyklu.
• Schopnost členů týmu aktualizovat obsah kanban karet, takže kolegové a projektoví manažeři jsou informováni o aktuálním stavu.Dostupnost pro všechny členy týmu bez ohledu na jejich fyzickou polohu.

Stojí za to prozkoumat různé kanbanové nástroje a vzít na vědomí, jak vysokou flexibilitu nabízejí (např. zda můžete definovat vlastní kategorie, závislosti a vlastnictví, zda můžete získat automatické připomenutí e-mailem s termíny a zda se můžete integrovat s Ganttem a přehledy).

REQUIRED STANDUPS

Samotné nástroje však nemohou vyřešit všechny problémy. Pro tento projekt jsem také nastavil týdenní setkání. Na tuto techniku se spoléhají při vývoji softwaru – pravidelně rekapitulují úkoly, na kterých se pracuje, aby spolu diskutovali o zjištěných problémech, vytvořili tak problémy sdíleným a aby se na tento úkol zaměřili všichni.

Jakkoliv standupy okamžitě přinesly větší orientaci na projekt, zjistili jsme, že určité nastavení základních pravidel (ground rules) je činí ještě účinnějšími:

• Standupy se konaly jednou týdně, v pondělí, a nikdy nebyly přeplánovány.
• Účast byla povinná pro všechny členy týmu, s výjimkou pokud absence byla plánována předem.
• Položky nebo úkoly v tabuli Kanban musely být aktualizovány před standupem.
• Informace byly krátké, takže každý člen projektu měl omezený čas, aby rychle shrnul klíčové úspěchy a neúspěchy a zmínil, na jakých úkolech bude během týdne pracovat.
• Další témata byla diskutována mimo schůzku.

Pohledem zpátky si uvědomuji, že jsme mohli udělat některé věci lépe – mít časoměřič na setkáních a využívat více možností nástroje – například barevné kódování karet Kanban. Ale obecně jsme zjistili, že mix obou technik vedl k dobře informovanému a spolupracujícímu projektovému týmu. Pomohl vytvořit větší transparentnost a nastavit správnou rovnováhu mezi tlakem a plněním úkolů.

Komentář editora: nejde o nic teoreticky nového – je to určitá forma komunikace v týmu. Ale podle mých zkušeností by tato kombinace konkrétních praktik mohla v korporátech docela dobře fungovat.  

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.