eWay System
facebook LinkedIN LinkedIN - follow
Exkluzivní partner sekce
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

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 >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

č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
Dialog 3000Skylla
IT SYSTEMS 5/2014 , Projektové řízení

Řízení (nejen) IT projektů (7. díl)



PM ConsultingLatinské přísloví „finis coronat opus“ má i svou tuzemskou obdobu „konec dobrý, všechno dobré“. Vzhledem k této staletími prověřené zkušenosti nelze než souhlasit, že závěr projektu je z hlediska jeho hodnocení a vnímání nejvýznamnější etapou. Abychom se ke konci zdárně dostali, je však třeba ještě uřídit rizika. V sedmém dílu se budeme zabývat řízením projektových rizik, správným procesem ukončení projektu a předáním jeho výstupů.


Vysoká rizikovost je projektům vlastní

S každým projektem jsou spojena určitá rizika, tedy nejisté události, které mohou nastat a ovlivnit, zpravidla negativně, jeho průběh. Je zřejmě tuzemským specifikem, že se rizika obecně moc neřídí, respektive že se neřídí formálně. Na rozdíl od některých jiných národů a etnik je u nás poměrně vyvinutý jakýsi šestý smysl, intuice, která tak nějak sama o sobě řadu rizik identifikuje, analyzuje, vyhodnotí a navrhne vyšším hladinám vědomí adekvátní řešení. V malých projektech a týmech to i docela dobře funguje. Komplikace nastávají ve chvíli, kdy tým není tvořen konzistentní skupinkou lidí, kteří jsou z jednoho oddělení, každý den se opakovaně potkávají, mohou věci diskutovat při obědě apod. Pak se vytrácí schopnost vzájemného upozorňování se na vlastní postřehy a úhly pohledu na věc s výsledkem, že je méně rizik identifikováno a dále řešeno, což následně vede k většímu výskytu reálně dopadnuvších rizik na projekt. Ještě náročnější je situace v rozsáhlých a mezinárodních týmech. Ona schopnost intuice a improvizace opravdu není dána všem.

Ve výsledku i v malém a čistě tuzemském týmu je vždy prospěšné si ta nejvýznamnější rizika alespoň sepsat, základně rozebrat, a především určit každému riziku majitele. Vyhnete se tak situacím typu: „No, já si od začátku myslel, že by tento problém mohl nastat, ale měl jsem za to, že to řeší někdo jiný...“ Dobrým nástrojem pro takový počin může být například registr rizik, jehož možnou podobu ukazuje tabulka 1.
 

Tab. 1

Tab. 1

Nejprve provedeme základní identifikaci a popis dané nejisté události. Zde je velmi důležité popsat scénář, který se může uskutečnit až do konkrétního, nejlépe vyčíslitelného dopadu na projekt. Následně se v rámci protiopatření snažíme preventivně zajistit, aby se daný scénář nejlépe vůbec nerealizoval nebo aby pravděpodobnost či dopad takového scénáře byly minimalizovány. U nejvýznamnějších rizik je pak vhodné zamyslet se i nad situací, kdy prevence selže, jak to co nejdřív poznáme (spouštěč) a co s tím potom dál. Na proces řízení rizik existují i mnohem sofistikovanější metody a nástroje, i výše uvedený postup však v drtivé většině případů plně postačuje, a to za předpokladu, že se s ním průběžně pracuje a není brán jen jako formalita.

Proč se zabývat koncem?

V některých případech se setkávám se situací, kdy v organizacích a firmách nejenže není jasné, kdy projekt vlastně začal, ale ono není zřejmé, ani kdy skončil. Typickým příkladem je nějaká zakázka, která vlivem změn a dalších faktorů výrazně změnila svůj harmonogram. Když už byla situace nějakým způsobem fakturačně kritická, tak se něco zakceptovalo, s významnými připomínkami, které byly následně více či méně rychle dále zpracovávány. I zde pak třeba došlo ke změnám, částečné akceptaci atd., až se projekt jaksi vytratil do ztracena, respektive nepřehledné změti oprav původního řešení, změnových a nových požadavků.

Tento postup je typický pro IT projekty, ale není to zdaleka uzavřená množina. I v dalších oblastech tomu tak často je. Příčiny přitom leží většinou na začátku projektu: vágní zadání, nejasný rozsah projektu, díky tomu obtížné řízení změn (a následné chaotické změny), chybí definice akceptačních kritérií apod. Poté vlastně není výsledek s čím srovnávat a vzniká velký prostor pro ono vyšumění do ztracena a neschopnost projekt jakkoliv vyhodnotit. To, jak tyto úvodní věci pohlídat, jsme si ukázali v předchozích dílech našeho seriálu. Dále tedy předpokládejme, že jsme dané kroky byli schopni uspokojivě zvládnout.

Kdy je začátek konce?

Procesní pojetí standardu PM BoK od PMI pěkně rozděluje procesy na projektu do skupin zahajovacích, plánovacích, realizačních, ukončovacích a monitorovacích. Tyto procesy spolu cyklicky souvisí, a to na různých úrovních detailu (viz obrázek 1). Dané schéma shodně platí pro projekt, etapu realizace projektu i pro dílčí činnost. Uvedené pojetí velmi dobře ilustruje fakt, že něco bude ukončováno již od začátku. Například již sestavení Identifikační listiny projektu musí být v některém okamžiku zřetelně ukončeno. Stejně tak plánování projektu jako takové (alespoň co se výchozích směrných plánů týče) a pak i postupná realizace jednotlivých činností a pracovních balíků. Obsah procesů ukončování je vždy založen na předání výsledku osobou zodpovědnou za danou dodávku zadavateli, který prověří, že předávané odpovídá dříve domluveným parametrům a je bez vad. A toto v nejlepším případě platí již na úrovni jednotlivých činností, nejhůře na nejnižší úrovni WBS. V projektu tedy dochází k aplikaci ukončovacích procesů v podstatě průběžně a neustále. Je dobré mít to na zřeteli již při sestavování plánu řízení projektu.
 

Obr. 1
Obr. 1


Dobrá dokumentace dělá přátele

V případě předávání, přebírání a akceptace jednotlivých výsledků a dodávek více než kdy jindy platí zásada kvalitní dokumentace těchto kroků. Přitom stejně jako v jiných případech nemusí jít o složité dokumenty a formuláře. Pro akceptaci dílčího výsledku, nebo i celého díla stačí jednoduchý formulář, ve kterém bude uvedeno, co, kdo, kdy a s jakým výsledkem (bez výhrad, s výhradami) akceptoval nebo ne. Velký pozor je třeba dát na rozdíl mezi výhradami oproti zadání a nově vniklými požadavky. Zatímco první skupina je jednoznačně k dořešení tvůrcem, druhá by měla vždy projít adekvátním změnovým řízením. Jen tak lze projekt udržet pod kontrolou. V některých případech (smluvně dané termíny předání apod.) je pak výhodné mít i jednoduchý předávací protokol, který potvrdí především termín předání výsledku, který musí být nejprve prověřen a třeba i několik týdnů testován, než může dojít k vlastní akceptaci.

V samotném závěru projektu je pak vhodné vypracovat i vyhodnocení, nejlépe ve formě jednoduchého dokumentu, který porovná zadání projektu s jeho výsledky, například ve formě, kterou ukazuje tabulka 2. Poslední řádek, tedy upřesnění kontextu, je velmi důležitý. Na projektech se děje velká řada dynamických jevů, které je potřeba v rámci vyhodnocení reflektovat. Nejčastěji jde o nejrůznější změny, ať už volitelné či takové, vůči kterým bylo zkrátka nutné se přizpůsobit. Pouhé porovnání tvrdých kritérií úspěšnosti může být poněkud zavádějící. V některých případech mohou být odchylky od plánu velmi významné nebo může jít i o předčasné ukončení projektu. I v těchto případech je vhodné projekty řádně, formálně ukončit. A třeba nastartovat projekt další, který dořeší nedodělky. Pokud to neuděláme, dostaneme se do kolotoče starých a nových požadavků zmíněného v úvodu.

V každém případě je třeba si uvědomit, že docela dobře platí i další z bonmotů projektových manažerů: úspěšný projekt je takový, který je tak vnímán. A to především klíčovými zainteresovanými stranami. Vše výše uvedené plně platí jak pro projekty na komerční bázi, tak pro ryze interní projekty. Byť se to může zdát nadbytečné, i v projektech typy „firma sama sobě“ je velmi užitečné akceptovat dílčí i celkové výsledky.

Vyhodnocení projektu
Zpracoval: Kdo je autorem dokumentu? Datum: Kdy byl dokument vytvořen / naposledy změněn?
Název projektu: Jak byl projekt nazván?
Identifikační číslo projektu: Jaké bylo identifikační číslo v rámci organizace (pokud bylo)?
Přínosy: K čemu měl projekt přispět? Co bylo důvodem jeho realizace
Cíl projektu: K jaké konkrétní změně mělo dojít? Jaký měl být stav řešené problematiky na konci realizace projektu?
Výstupy projektu: Jaké jsou konkrétní výstupy daného projektu? Co vyprodukoval (dodal) projektový tým?
Kritéria úspěšnosti: Podle čeho jsme měli posoudit, že bylo cíle projektu dosaženo?
Skutečné výsledky: Čeho jsme ve sledovaných kategoriích skutečně dosáhli? Jakých odchylek sledované parametry dosáhly?
Vyhodnocení: Jak lze výsledky stručně interpretovat?

Tab. 2


Osobní zkušenost zvyšuje hodnotu člověka, sdílená posiluje organizaci

Hospodaření se zkušenostmi v rámci firmy (knowledge management) je dnes velmi diskutované téma, které velmi přesahuje možnosti tohoto článku i seriálu. Nicméně alespoň v souvislosti s oblastí projektového řízení zmiňme několik bodů a zásad pro předávání zkušeností mezi projektovými manažery v organizaci:

  • Vycházet lze nejlépe ze seznamu bodů k řešení nebo z registru rizik.
  • Smysl dává předávat dál především takové informace, které nejsou nedílně spjaté pouze s jedním konkrétním řešením (projektem), ale spíše zkušenosti obecnějšího charakteru.
  • Záznam „naučených lekcí“ (lessons learned) je nejlepší dělat do nějakého vhodného online systému založeného na databázi, ve které se dá vyhledávat. Klidně to může být i formulář či seznam na bázi Sharepoint webu apod. Slohové dílo ve Wordu si kromě tvůrce už nejspíš nikdo nepřečte. Vhodným formátem pro záznam zkušeností může být třeba jednoduchá tabulka (viz tabulka 3).
Oblast Typ Popis Dopad na projekt Doporučení
Jakých oblastí projektového řízení se poučení týká (integrace, rozsah, finance, lidské zdroje, změny, rizika, nakupování atp.)? Výstižně a stručně charakterizujte zkoumaný problém či úspěch. Jaká událost se stala příčinou problému, či naopak úspěchu projektu? Jaký dopad bude mít událost na projekt, zejména na výstupy, čas a rozpočet? Jakými opatřeními by bylo možné zajistit, aby se daná chyba příště neopakovala?
... ... ... ... ...

Tab. 3

Závěr

Náš seriál je tímto na svém konci. Neměl ambici poskytnout vám komplexní metodiku pro řízení projektů, spíše ukázat, že řadu věcí lze správně dělat i jednoduše, a naopak že ani složité postupy aplikované bezmyšlenkovitě, nemusí vést k cíli. Pokud vás zaujaly některé z prezentovaných nástrojů, tak je spolu s dalšími ve formě řešených příkladů naleznete v naší knize 5 kroků k úspěšnému projektu, kterou vydala Grada na jaře roku 2013. Přeji mnoho úspěšných projektů!

Jan Doležal
Autor je ředitelem společnosti PM Consulting. Je držitelem certifikací PMI PMP a IPMA level B. Zabývá se především optimalizací systémů řízení projektů v různých firmách a organizacích.

 

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Průvodce software defined storage

AlefV dnešní době hledá stále více organizací způsob, jak získat volnost v nákupu hardwaru pro podnikové úložiště. Slibují si, že se při použití Software Defined Storage zbaví takzvaného vendor lock in a současně získají finančních úsporu, protože SDS vytváří z běžných komoditních serverů připojených k Ethernet síti úložiště s plnohodnotným data managementem. Snížení nákladů také bývá jeden z častých důvodů, proč sáhnout po SDS řešení.