Když dnes v některých firmách řeknete slovo „projekt“, manažeři dostanou kopřivku. A přitom je historie projektového řízení možná tak stará, jako lidstvo samo. Výsledky projektu stavby pyramid můžeme kupříkladu vidět i dneska … a to i navzdory tomu, že místo projektového manažera tam prý více působil projektový diktátor.
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.
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.
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.
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.
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.“
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“.
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.
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.
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.
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)
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.
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.
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é
Další informace Vám rádi poskytneme prostřednictvím EduCity, prosíme kontaktujte p. Bartičku info@educity.cz nebo na tel. (+420) 731 169 890
Vytisknout rozhovor