facebook LinkedIN LinkedIN - follow
Tematické sekce
 
Branžové sekce
Přihlášení SystemNEWSPřehledy
 
Tematické seriály

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 
Nové!

RPA - automatizace procesů

Softwaroví roboti automatizují obchodní procesy.

články >>

 
Nové!

IoT – internet věcí

Internet věcí a jeho uplatnění napříč obory.

články >>

 
Nové!

VR – virtuální realita

Praktické využití virtuální reality ve službách i podnikových aplikacích.

články >>

 
Nové!

Bankovní identita (BankID)

K službám eGovernmentu přímo z internetového bankovnictví.

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
 
Partneři webu

Škola projektového řízení

Poradna projektového řízení

Zapojte se také do výměny zkušeností a posílejte své dotazy, připomínky k naší škole projektového řízení nebo jiné názory na zde prezentované odpovědi na adresu skola_pm@contros.cz

Jak vyjádřit souhrnně výsledek projektu?

Výsledek projektu je dán splněním zadání. Zadání musí obsahovat všechny složky trojimperativu. Lze využít například logický součin. Projekt potom skončí jako "splněno", nebo "nesplněno". To nám ve většině případů nebude stačit. Zejména pokud bychom chtěli motivovat projektový tým k "co nejlepšímu" splnění projektu. To by mělo obvykle znamenat "co nejdříve", "s co nejnižší spotřebou zdrojů" a "s co nejkvalitnějšími výstupy". Potřebovali bychom tedy sloučit míru plnění jednotlivých složek trojimperativu do míry plnění. Toho lze relativně snadno dosáhnout, pokud si vytvoříme a budeme rozvíjet metodiku pro ocenění času, popřípadě kvality výstupů. Spotřebu času lze hodnotit jako nenahraditelný zdroj nebo jako složku kvality výstupu - více na webu a v diskusi.

Dodavatel informačního systému nabízí, že bude řídit implementaci. Je to správně?

Obecně rozhodně nikoliv. Zodpovědný dodavatel by měl trvat na tom, že inovace informačního systému je interním projektem zadavatele, do kterého se on jako externí účastník musí začlenit. Může se to zdát sporné, ale záleží na tom, jestli budete předpokládat, že zodpovědnost za spolehlivost a efektivnost využívání informačního systému ponese do budoucna jeho dodavatel (což by byla velmi zajímavá pokročilá forma outsourcingu), nebo zda "s tím" bude muset "žít". Kdo stavěl či rekonstruoval dům nebo třeba podkroví, ví, o čem je řeč. V případě, že předpokládáte, že zodpovědnost ponese dodavatel, NEJDE o projekt, protože akce končí až okamžikem, kdy přestanete spolupracovat - jedná se o trvalou službu, nikoli jednorázovou dodávku. Pokud však zodpovědnost za produktivitu práce, kvalitu informací a vše, co s tím souvisí, zůstává "doma", je to projekt, který musíte řídit sami, sami vědět, čeho chcete dosáhnout, sami zajistit dostatečně náročná akceptační kritéria a sami si převzít výsledek implementace. Pokud to budete dělat takto, záleží na tom, jestli máte interně k dispozici metodiku projektového řízení a příslušné nástroje. Pokud ne, je nejvýhodnější urychleně systém vytvořit, a pokud skutečně "hoří", tak je možná myslitelné nechat dodavatele, aby projekt byl "řízen" s využitím jeho systému. Vedoucí projektu musí být pouze jeden a rozhodně interní.

Co je MBO?

MBO znamená "management by objectives". Většinou se překládá jako "řízení pomocí cílů" a možná i díky tomuto překladu se dostalo do zcela absurdních poloh (kdy je například zisk vydáván za cíl, jehož pomocí lze něco řídit). Lepší překlad je "řízení pomocí úkolů". Jeho podstatou je (nezbytná) formalizace zadávání úkolů (práce). Ta směřuje k tomu, aby se realizátor snažil s využitím své způsobilosti co nejlépe pochopit, co zadavatel očekává a předložil mu návrh postupu prací a upřesnění výstupů a podmínek. Podle něj si zadavatel ověří, jestli realizátor pochopil, co po něm chce, a hodlá pracovat na tom, co potřebuje. Většinou zadání dále písemně upřesňují. Tak vznikne detailní, naprosto konkrétní zadání úkolu včetně výstupů a plánu prací. Něco jako mikroprojekt. Úkol staví na možnostech a dovednostech jediného subjektu, nepředpokládá se žádná ("viditelná") koordinace s dalšími subjekty (aktivitami) . Realizátor po schválení zadání úkol zcela samostatně splní. Intenzita dohledu ze strany zadavatele závisí na významu úkolu a zkušenostech s realizátorem. Výsledek si zadavatel převezme a měl by jej vyhodnotit pro potřeby motivačního systému.

Co je pro projekt nejdůležitější?

Těžiště a logika podmínek úspěchu projektu je z větší části uvedena v článku. V praxi jsou (pokud odhlédneme od kvality systému podpory řízení projektů, respektive správy projektového portfolia) nejčastější překážkou chybějící systém centrální správy kapacit (zdrojů obecně) a mechanismy pro jejich efektivní alokaci. Jde o to, že dle schopností vedoucího a možností systému by měly být ke každé činnosti již ve fázi návrhu přiřazeny obecné zdroje, u kritických (viz později) předběžně označeny i konkrétní. Před schválením etapy musí být zdroje rezervovány. Systém musí umožnit "vyjednávání" (přesuny zdrojů). Musí uchovávat obecný zdroj, definovat jeho dílčí předpoklady (požadavky), hledat náhrady atd. Hlavně však musí obsahovat úplná pravdivá data o dostupnosti/vytížení zdrojů. Bez takového systému (sdíleného s procesní oblastí) nelze projekty efektivně řídit.

Lze se projektové řízení "naučit"?

Na tuto otázku možná neexistuje odpověď. Rozhodně ne jednoduchá, jednoznačná a obecně platná. Existuje řada kurzů, které lze navštívit. Pár knih, které je dobré přečíst. Na druhé straně existují názory, že jediný způsob získání potřebných dovedností je osobní zkušenost. Dokonce se tvrdí, že tyto zkušenosti nelze předat - že si každý musí rozbíjet nos sám. Obecné kurzy jsou z podstaty věci nepřípustně daleko od reality, preferováním osobní zkušenosti děláme zbytečně mnoho chyb. Řešením se může zdát podnikové vzdělávání - pokud se pojme správně, je to asi nejméně špatná volba. Vnucuje se ale otázka - co má vlastně potenciální projektový manažer umět? Opravdu se někdo má učit, jak vypadá ideální organizace a motivace? A spoustu další teorie? Nebylo by lepší ve firmě vybudovat systém řízení, který jasně formuluje všechny povinnosti a postupy, mim jiné i ty při řízení aktivit projektového charakteru? Mají být metody řízení uplatňovány formou "lidové tvořivosti"? Jaká je role a jaké jsou možnosti jednotlivce? Logika věci říká, že pokud nám na výsledcích projektů záleží, musíme se naučit je řídit. Co nejlépe. Nikoliv však jako jednotlivec, nýbrž jako organizace.

Co je úspěšný projekt?

Toto je jen zdánlivě triviální otázka. Úspěch může být, když je hotovo alespoň zhruba to, co se mělo dělat, doba trvání nevyčerpala trpělivost zadavatelů a plýtvání zdroji nebylo neúnosné. Ve skutečnosti to není tak jednoduché, zejména pokud se nám stále plete projektový záměr a projekt. V takovém případě nám bude komplikovat život to, co do projektu nepatří - ekonomická efektivnost. Samozřejmě mají být projekty realizovány hospodárně, ale ekonomika projektu nemá přímou souvislost s ekonomickými důsledky záměru. Pokud budeme brát výstupy jako konstantu, balancujeme mezi dobou trvání a spotřebou zdrojů. Ve většině aktivit, které se dnes řídí projektově, má výraznou převahu čas (více na webu a Kritický řetěz). Pro úspěch projektu platí logický součin úplnosti výstupů (respektive jejich kritických požadavků) a splnění časového limitu.

Kolik práce ušetří software?

Dobrý nástroj pro správu projektových dat je nezbytný. Nikoli ovšem proto, že by šetřil práci oproti tradičnímu pojetí plánování a řízení projektů. Náš problém totiž není a nesmí být "Jak rychle a co nejjednodušeji vyrobit (jednoduchý) plán prací", ale "Jak sestavit kvalitní plán realizovatelného projektu". A takový návrh, který by respektoval všechna doporučená hlediska, prostě ručně sestavit nelze. Navíc potřebujeme již ve fázi návrhu rezervovat a dynamicky udržovat alokované kapacity. Protože nám tedy přibylo obrovské množství práce, kterou je nezbytně nutné udělat, bude jí i s velmi kvalitním a správně nasazeným řešením více než dříve.

Co je to "proces" projektového řízení?

Souslednost úkonů, které se musí provádět v jasně definovaných situacích při realizaci každého projektu. Instance procesu začíná spouštěcí událostí - to je ona "definovaná situace". Proces je předem určený postup, který stanovuje předem známé a nezbytné kroky, které je nezbytně nutno dělat. Proces projektového řízení stanovuje náležitosti a postupy úkonů při řízení projektů. Technicky jsou to pravidla a evidence na dvou úrovních - jednak "nad" a mezi projekty, jednak uvnitř projektu. Nad projektem pracují mechanismy pro správu projektových záměrů, jejich výběr, schvalování, monitorování a hodnocení projektů. Mezi projekty jde především o řízení využívání zdrojů. Uvnitř projektu usilujeme o dodržení projektové metodiky. Ta dle možností jasně určuje většinu úkonů, které musí vedoucí projektu v roli koordinátora udělat. Jde především o sledování postupu, údržbu plánu prací, zadávání úkolů a jejich hodnocení, řešení konfliktů všeho typu atd.

Jak zvládnout naléhavý projekt?

Říkáme, že bychom neměli (zvenčí) měnit běžící projekty. Nemáme přemýšlet o prioritách (více v části Komunikace), ale dodržovat sjednané termíny. Jenže život je pes a určitě se objeví něco, co se prostě musí udělat. Vzniká požadavek na spuštění nového projektu a jsou deklarovány katastrofické scénáře. Především musíme rozlišit naléhavé a důležité. Pokud je to záležitost pouze naléhavá, většinou nebudou mít „katastrofy“ závažné ekonomické důsledky. V takovém případě se snažíme zvládnout situaci za každou cenu pouze s aktuálními volnými kapacitami. Pokud se jedná o závažnou komplexnější (skutečně důležitou) záležitost, stojíme před nutností přeplánovat projektové portfolio. Samozřejmě v případě, kdy již nemáme k dispozici kapacitní rezervy, které bychom mohli využít. Každá rezerva totiž jednou dojde. Rozhodnutí o tom je téměř jistě individuální záležitost. První scénář je najít jeden nejméně důležitý projekt (využívající zdroje, které chybí) a ten přerušit, naplánovat nový projekt a potom znovu naplánovat pokračování přerušené akce (popřípadě co lze, předat externím kapacitám). Druhá možnost je přerušit a přeplánovat všechny běžící projekty. Tímto způsobem se pravděpodobně lze dopracovat k technicky „lepšímu“ řešení, ale záleží na charakteru projektů a na tom, zda pro automatické přeplánování jsou v systému všechny potřebné informace s aktuálními hodnotami. Tím se rozumí zejména informace o dostupnosti všech využívaných zdrojů. U běžících projektů se jedná o konkrétní zdroje. Samozřejmě by bylo možné využít náhradní zdroje, ale ty nelze zahrnovat do automatického přeplánování, je nutno je doplnit při řešení přetížení zdrojů.

Co jsou souběžné úkoly?

Také se říká „multitasking“ – jde o situaci, kdy požadavky na jeden zdroj nejsou koordinovány. Logicky je to možné pouze v případě lidských zdrojů, protože u žádného stroje či jiného prostředku by nikoho nenapadlo chtít, aby chvíli používali destilační zařízení pro jeden projekt a měl by se předat jinému projektu dříve, než je destilace dokončena. Spoléháme na schopnost lidí zorganizovat si práci a hádat se s ostatními oprávněnými osobami. Pokud tento scénář připustíme, jeden zdroj vykazuje současně práci na více projektech. Už toto je nesmysl a kvalitní systém pro podporu řízení by měl této situaci zabránit. Částečně je to i důsledek deformací v motivaci (více příště), kdy se projektový manažer doprošuje součinnosti členů týmu, a proto přistoupí na nesmyslný rozsah a délku úkolu místo toho, aby plán prací přizpůsobil tomu, kdy příslušný člověk skutečně bude na svém úkolu pracovat. Nemá smysl zadávat jako celek práci, kterou lze rozdělit. Nemá smysl pracovat na více úkolech současně.

Odborník, nebo manažer?

Pochybnost, zda je pro vedoucího projektu důležitější odborná, nebo manažerská způsobilost, se vyskytuje až příliš často. V praxi na takovou otázku neexistuje jednoznačná odpověď. Většina projektových manažerů pohrdavě krčí rameny. Vědí, že pokud by nebyli zcela neoddiskutovatelně věcně nejkompetentnější osobou, neměli by nejmenší šanci projekt řídit. Nebo dovede si někdo představit stavbyvedoucího bez komplexních odborných znalostí? Trošku jinak vypadá situace v sofistikovanějších aktivitách. Vedoucí vývoje softwaru asi už nemusí být nejlepší programátor ani analytik. Ten, kdo zodpovídá za výstavbu atomové elektrárny, by asi měl být především dobrý manažerem – stavebnictví, energetika či jaderná fyzika mu příliš užitečné nebudou. Když se zamyslíme nad zdánlivě jednoduchou stavbou domu, není jisté, zda se z hlediska stavbyvedoucího jedná o projekt. Tento přístup je důsledkem toho, že lidé v projektech nejsou správně motivováni. Proto vedoucí spíše své spolupracovníky nutí a přemlouvá k tomu, aby dělali, co je nezbytně nutno. Proto musí být i odbornou autoritou. Jeho rolí by však mělo být usměrňování jejich iniciativy. Při korektním pojetí projektů otázka odborné způsobilosti zmizí. Vedoucí projektu znalosti věcné stránky nemůže a z vlastního zájmu ani nechce ignorovat, ale většinu své energie musí věnovat řízení akce. Z logiky věci také vyplývá, že pokud bude příliš angažován v odborném problému, nebude dostatečně objektivní a pravděpodobně ztratí nadhled.

Jaká úroveň odměn?

Zjednodušeně řečeno odměny za práci na projektech by měly být výrazně vyšší než mzda za výkon rutinních činností. Ale včetně rizika, že pokud nebude projekt úspěšně dokončen, nedostane nikdo nic. Tento přístup je ale velice sporný – je nebo není žádoucí odlišit práci, která má spíše výkonný charakter? Takoví členové týmu nemají šanci celkové výsledky ovlivnit. A zadanou práci vykonat musí. Takže by měli dostat za práci, která jim byla v podstatě nařízena, zaplaceno bez ohledu na výsledek projektu. Ovšem toto v jistém smyslu platí pro úplně všechny. Proto je nastavení pravidel pro odměňování práce na projektech velmi náročné a velmi důležité. Musí respektovat technickoorganizační podmínky firmy a přístup jejích spolupracovníků. Podstatné je, aby bylo v celopodnikovém kontextu jasné, jaký je reálný význam mimořádných aktivit. Důležitější projekty by tedy na stejné plánované množství práce měly dostat více peněz než ty méně důležité. Význam projektu vyplývá z jeho strategických důsledků, respektive ekonomického dopadu projektového záměru.

A co počasí?

Neplánujte, co plánovat nelze. Nelze řídit nezávislými faktory, proto nejsou součástí plánu prací. Měly by ovšem být identifikovány – přesně to dělá (globální) správa strategických faktorů úspěchu. Stanoveným způsobem monitoruje informační zdroje, ze kterých lze získat informace umožňující odhadovat pravděpodobnost výskytu sledovaných jevů. Závěry zpracování těchto informací předává uživatelům-manažerům v projektové i procesní oblasti. Projekty (i procesy) by měly počítat s působením identifikovatelných faktorů. Míru optimismu při přípravě krizových scénářů či velikosti vytvářených rezerv stanoví metodika ve vazbě na význam projektu. Platí, že pokud jsme přistoupili na krizové scénáře, odpovídá předpokládaná délka projektu a jeho rozpočet nejhorší možné variantě. Pokud vytváříme rezervy, znamená to, že řešení bude možné hledat až v případě konkrétního výskytu krize. Je nutné si uvědomit, že příprava krizového scénáře nikdy nemůže být dokonalá a má smysl plánovat pouze to, co je známo. Příprava řešení krize předem je samozřejmě mnohonásobně efektivnější než řešení problémů v průběhu projektu.

Jak zajistit řízení cash flow?

Například pro stavební projekt nebo jiný typ investičního celku je jeho financování složitou záležitostí a je bytostně spjato s plánem prací a dalšími informacemi projektu. Zdá se být přirozené přenést zodpovědnost za řízení finančních toků na projekt. Pokud ovšem přijmeme v tomto seriálu prosazovaný princip smysluplné dělby práce, dopadne to jinak. Projekt se zabývá svými interními záležitostmi a pro klasifikované požadavky využívá součinnost okolí. Je zbytečné, aby se v rámci každého projektu zaváděly procesy, které standardně běží (typicky mzdy, zásobování, komunikace atd.). Navíc by to bylo absurdní, protože pro provedení příslušné činnosti jsou nutné specializované kapacity, zkušenosti, kontakty a samozřejmě koordinace souvisejících aktivit. Jediné, co je potřeba, jsou kvalitní informace o finančních potřebách projektu. To znamená jasně definované rozhraní – lhůty, náležitosti a podmínky. Například stanovený čas pro reakci na změnu požadavku – které potom vedoucí projektu může použít pro aktualizaci plánu prací. A je nesporné, že zajistit financování není povinnost vedoucího projektu, ale zadavatele (prostřednictvím vlastní infrastruktury); povinností vedoucího projektu je říci, kdy bude kolik peněz potřebovat.

Neomezuje projektové řízení iniciativu?

Jistě – pokud nebudeme mít alespoň trošku rozumné projektové manažery a potřebné kontrolní mechanismy, stane se to, že místo řízení projektů se lidé budou věnovat hledání chyb systému a vytváření alibi proto, že se to tak prostě dělat nedá. Možná to vypadá jako odpověď na něco trošku jiného, ale ve skutečnosti jde o oblíbenou výmluvu. Dobrá pravidla iniciativu a kreativitu neomezují, ale podporují. Samozřejmě nedomyšlená pravidla či nefunkční systém znamenají katastrofu a potom je mnohem lepší mít volnost k improvizaci. To ale znamená velkou spotřebu energie na pouhou existenci, protože zajištění každého kroku či požadavku projektu si musí projektový manažer doslova vybojovat. Stejně tomu je i při realizaci úkolů projektu. Typickou komplikací je to, že se stále upřesňuje zadání nebo se nedodržuje disponibilita zdrojů. V takovém případě jsou aktivita a tvůrčí schopnosti zaměřeny na překonávání překážek, nikoli na optimální řešení úkolů či hledání a využívání synergických a vedlejších efektů. Argumentace omezením iniciativy signalizuje prostředí, ve kterém aktuálně neplatí žádná pravidla. Lidé se podvědomě brání tomu, aby se vystavili povinnostem a sankcím. Často se i manažeři brání tomu, aby dodržování pravidel vymáhali.

Není to příliš složité?

Pokud nepoužijeme dobrý nástroj pro podporu řízení projektu, je zpracování a udržování korektní projektové dokumentace velice náročné, možná nereálné. Pokud chceme používat nástroj a neumíme s ním správně zacházet, je to ještě náročnější. To je obvykle způsobeno tím, že ten, kdo nástroj implementoval, vůbec nechápal naše pracovní postupy, popřípadě nezná či nerespektuje pravidla projektového řízení. Dost často je problém v tom, že sám řídí projekty bez využití nástroje, takže neumí se systémem správně zacházet (doporučení: ke každé implementaci přizvěte nezávislého experta). Což následně vede k tomu, že hledáme způsob, jak obejít to, co je nesmyslné a nepochopitelné, popřípadě nedodržovatelné. Možná něco málo zjednodušíme, ale ve skutečnosti jen komplikujeme život všem ostatním a v konečném důsledku i sami sobě. Když nástroj nepoužíváme, je řízení (či spíše „neřízení“) mnohem jednodušší. Jenže většinou nedostačující. Kdyby to, s čím potřebujeme pomoci, bylo jednoduché, nepotřebovali bychom silný nástroj. Pokud je nástroj silný, je obtížnější jej zvládnout. Všichni tedy úpěnlivě lpí na svých ověřených postupech. Ale složité není změnit způsob práce – složité bude udržet si stávající místo, pokud jej nezměníte!

Ceník inzerce portálu SystemOnLine