V současnosti je v hodně firmách doslova přeprojektováno. Stále více aktivit je zadefinováno jako projekt, jejich počet roste doslova exponeciální řadou a všichni v tom ztrácejí přehled. Jak je možné se s tím vypořádat?
Nedělal bych z toho zase takovou vědu. Ve skutečnosti mnoho těchto projektových aktivit jsou spíš samostatné úkoly s tzv. projektovým charakterem – to znamená, že je sice řídíme jako standardní projekty, ale rozsáhlá projektová dokumentace není vyžadována. Běžně ve své praxi postupuji tak, že si se svými klienty obvykle stanovím minimální rozsah pro to, co už bude projekt. Pro ostatní samostatné úkoly logicky nemusí probíhat žádná grémia ani nemusí být definován sponzor, atd ...
Na druhou stranu - pokud má firma opravdu hodně (standardních) projektů, je potřeba připravit odpovídající strukturu řízení. A to je skutečně potřeba dobře promyslet a navrhnout. Běžně se to týká firem nebo byznysových jednotek, které se věnují výstavbě a nebo vývoji jakéhokoliv druhu. Například firem, které staví ocelové konstrukce, lokální teplárny, nebo vyvíjí vlastní díly pro automobily.
Mluvíme tedy o multiprojektovém managementu?
Ano, to zcela jistě. A s tím souvisejícím nastavením vhodné organizační struktury, podpory a architektury firemních IT systémů, apod.
A jaký je podle Vás nejčastější problém, se kterým se firmy v této oblasti setkávají?
Jsou možná dva největší: nefunkční anebo neexistující systémy, které by měly podporovat efektivní využití zdrojů – mám na mysli zejména kapacity interních specialistů. A hodně velkým problémem jsou i dnes nekorektní a zastaralá data. Traduje se, že jednou dostal Charlese Babbage (anglický matematik, filozof, vizionář a strojní inženýr, který jako první přišel s nápadem sestrojit programovatelný stroj) dotaz: „Prosím vás, pane Babbage, když do stroje vložíte špatná čísla, vyjdou z něj správné odpovědi?" na což on odpověděl: „Nejsem schopen správně pochopit druh zmatení myšlenek, které by mohlo takovou otázku vyvolat.“
A pro to nejlépe platí – jak já říkám: „Garbage in – Garbage out“ („smetí dovnitř, smetí ven“). To vzhledem k projektovému řízení znamená: výstupy projektu mohou být jenom tak přesné, jak přesné jsou informace, které do něho zadáváme.
Projektové řízení je charakteristické svým „Waterfall“ přístupem. Ten vyžaduje, aby byl jeden úkol dokončen před tím, než bude zahájen další. Projekty jsou ale stále složitější a komplexnější. Je možné ještě efektivně řídit tímto (waterfall) způsobem?
On čistý waterfall stejně nikdy neexistoval,dokonce ani v těch dřevních dobách. Nikdy vám to totiž nedovolil požadavek na včasné dokončení termínu. Za svou praxi jsem „čistý waterfall“ projekt nikdy neviděl. Podle mne je to stejný mýtus jako „čistý agile“. Nicméně platí, že většinový waterfall v podstatě vyžadují projekty, které mají velmi přesně definovaný výstup a jeho kvalitu. Agilní prvky tam můžeme použít jenom v určitých situacích.
Projektové řízení významně ovlivnila digitalizace. Jak konkrétně se to projevilo, projevuje a co se ještě očekává?
Obecně myslím, že IT je podpůrný nástroj, který má pomáhat. Není středobodem, protože to, o co skutečně jde, je vlastní výstup projektu. Když mi v tom IT nástroje pomohou, chci je. Pokud mi nepomáhají – počkám si, až někdo vymyslí něco lepšího. Nemá smysl lámat to přes koleno, protože „to jinde funguje“. Ze své praxe mohu uvést hodně příkladů, kde projekt bez IT nástrojů trval 3 měsíce, s nimi 5. Je to krásná ilustrace Murphyho zákona v praxi: „Počítač je stroj, který dělá naši práci rychleji a efektivněji než my, a to hlavně tu, kterou bychom vůbec nedělali, pokud by počítače neexistovaly.“
Jeden ze známých Murphyho zákonů taky říká, že „90% projektu spotřebuje 90% času. Zbývajících 10% projektu spotřebuje dalších 90% času.“ Co dělat, aby se to nestávalo?
Znám různé verze tohoto výroku.Také se tomu říká cibulový syndrom a jde o jednoduchou věc: co na začátku projektu ošidíš, v realizaci ti to pak desetinásobně „nafackuje“.
Hodně odborníků říká, že pozice projektového manažera je srovnatelná s dinosaury – teď jim patří celý business, ale nástupem umělé inteligence zaniknou. Co si o tom myslíte vy?
Zatím 100% nevěřím na inteligentní umělou inteligenci – vím totiž, jak (ne)funguje. Nechal bych ji zatím někde v matrixu. Její místo teď vidím zejména v práci s daty – když ji nakrmíte VHODNÝMI A SPRÁVNÝMI, ušetří vám otravnou práci. Jen tu pak opět máme ten známý problém z předchozích otázek: DATA DATA DATA... a jsme tam, kde jsme byli před tím.
Můžete prosím ve zkratce vysvětlit hlavní rozdíly mezi „vodopádovým“, agilním a hybridním způsobem projektového řízení? Který z nich se hodí pro jaké projekty?
Už jsem krátce zmiňoval, ale doplním - agilita se tím více uplatňuje, čím více prozkoumáváme na výstupu projektu „neprobádaná teritoria“ a naopak, pokud vyžadujeme přesný výstup, tak se hodí spíš waterfall.
Reálné situace ve firmách jsou mnohdy někde mezi, a tak tam patří hybridní přístup. V podstatě si přitom řekneme, co na projektu můžeme a co nesmíme dělat agilně. Mnoho agilních ceremonií lze prakticky převzít i v těch nejtvrdších waterfallech. Velmi hezkým příkladem je zejména „daily stand-up“ nebo backlog.
Je vhodné v praxi kombinovat více rolí v jednom člověku? Například: může být projektovým manažerem produktový manažer, nebo scrum master?
Já si moc nepotrpím na terminologii. Dle mého názoru totiž v praxi na názvu až tak moc nezáleží. Stejný název pozice/role má v jiné firmě mnohdy úplně jiný význam a odpovědnosti. To co skutečně rozhoduje, je obsah. Chcete-li totiž konkrétní produkt/výstup, vše ostatní se tomu musí podřídit. Ale co je skutečným a opakujícím se problémem je, že ty role a pozice nemají jasné odpovědnosti, jasná zadání a taky pravomoci.
Kdyby jste měl dát dnešním projektovým manažerům 5 rad, tipů, jaké by to byly?
- Zjistěte si kdo všechno má na (tento) projekt vliv.
- Pořádně se jich zeptejte, co od projektu očekávají.
- Co se nekontroluje, to se nedodržuje.
- Nespoléhejte se jen na reporty, přesvědčte se na místě.
- Nezavítejte se v detailu projektu, musíte mít přehled i o externích vazbách.
Může být projektové řízení realizováno i při práci projektového týmu na dálku?
Ano – pro celkové zadání úkolů a monitoring
Ne – pro kontrolu kvality projektu (gemba princip – je potřeba se jít podívat do provozu)
V současné energetické krizi se možná bude zvyšovat počet firem, které půjdou do úpadku, do insolvence. V čem může v tomhle případě pomoct projektové řízení? Např: projekt na úsporu energie, apod.
Toto už asi trochu přesahuje téma o klasických projektech (vývoj, výstavba, IT, administrativa). Zde se jedná o projekty zlepšování, v kterých je možné uplatňovat další přístup - a to jsou DMAIC (define, measure, analyze, improve, control) projekty a filosofie lean. Ale to asi až jindy.
Jak je to u projektového řízení s improvizací?
Improvizace je rozporuplně přijímána hlavně v německy mluvícím prostředí. Dalo by se říci, že v takovém prostředí je doslova nežádoucí. Naopak na východ a na jih od nás je typická.
Z mého pohledu je užitečné nebát se improvizovat i v projektovém řízení. Musíme se ale dohodnout se všemi zainteresovanými stranami, že v nějaké konkrétní situaci je možné si dovolit improvizovat. Improvizace však nesmí být důvodem pro lajdáckou přípravu projektu. Zde plně souhlasím s našimi německými kolegy. Již zmíněný cibulový syndrom je právě důsledkem přílišného spoléhání se na improvizaci.
V jakémkoliv řízení existuje jeden prvek, který je všem společný, a to jsou lidi. Projektové řízení je vlastně o řízení lidí. Máte nějaký tip na to, aby bylo co nejefektivnější a fungovalo?
Komunikace – nikoliv jako krasomluva ale:
-
Předávání informací
-
Získávání informací
-
Ověřování informací
Jinak řečeno, proč lidé mají problém? Protože:
-
Nikdo se jich na nic nezeptá
-
Nikdo jim nic nikdy neřekne
-
Informace které dostanou jsou špatné