IT Project Portfolio Management a úspěšnost projektů

IT Project Portfolio Management a úspěšnost projektů Libor Měsíček Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií nám. W. Churchilla 4, 130 67 Praha 3 e-mail: [email protected] Abstrakt: Článek se zabývá problematikou řízení portfolia projektů v IT. Zaměřuje se na vybraná pojetí řízení portfolia (MMDIS, ITIL a CobiT). Dále popisuje vztah mezi charakteristikou projektu a vhodnými metrikami k měření splnění sledovaných cílů. V závěru je naznačena možnost zlepšení kvality odhadů pomocí vytěsnění procesů řízení portfolia projektů do specializované společnosti zajišťující identifikaci, vyhodnocení a do jisté míry i doporučení nejvhodnějších projektů. Klíčová slova: projekt, úspěšnost projektů, procesní řízení, řízení portfolia projektů, portfolio, ITIL, COBIT, PPM, project management office, outsourcing, Abstract: This paper discusses the problems of IT Project Portfolio Management. It summarises main points of portfolio management presented by three approaches. After that it is described relationship between characteristic of projects and metrics for measurement of goals achievement. As conclusion possibility of improvement of estimations by outsourcing IT Project Management Office by specialised company is discussed. Key words: Project, success rate of projects, process management, Project Portfolio Management, portfolio,ITIL, COBIT, PPM, Project Management Office,outsourcing

1. Úvod IT Project Portfolio Management (IT PPM) se zabývá procesem hodnocení a výběru IT projektů, sleduje již běžící projekty, průběžně je vyhodnocuje a hledá optimální složení běžících projektů uvnitř organizace s vazbou na jejich přínosy. K této činnosti je nutné získávat informace nejen o projektových záměrech, o průběhu projektů, ale i čerpat a vyhodnocovat informace ze společnosti a především z jejího okolí. K tomu slouží řada kritérií a metrik. Ty se ovšem musí lišit v závislosti na povaze hodnoceného projektu. V současné době dochází vzhledem k vývoji globální ekonomiky k růstu významu procesů rozhodování o realizaci a o změnách projektů. To vytváří prostředí pro přechod od nejasných způsobů výběru projektů na přesně definované postupy a pravidla. Tento tlak je způsoben mimo jiné horší dostupností úvěrů firmám na jejich plánované projekty. Řada studií prokázala souvislost mezi implementací IT Project Portfolio Managementu a kvalitou výstupů projektů [1]. Zároveň je třeba si uvědomit, že IT projekty lze jen obtížně dělit z hlediska úspěšnosti. Při výběru projektů je třeba sledovat změny v požadavcích na IT oddělení. Podle výzkumu pravidelně prováděného společností Gartner [2] se v roce 2012 očekává od IT oddělení zlepšování procesů a snižování nákladů. Roste důležitost projektů, SYSTÉMOVÁ INTEGRACE 2/2010

7

Libor Měsíček

které umožní nalezení a získání nových zákazníků. Dále se očekává růst významu IT oddělení při inovacích produktů. Cílem této práce je popis a hodnocení vybraných teoretických přístupů k řízení portfolia projektů v oblasti informačních technologií, dále obsahuje diskusi možností využití metrik a kritérií v procesu hodnocení projektů v závislosti na charakteristice zvažovaných projektů a možnosti zlepšení kvality odhadů prostřednictvím nezávislé projektové kanceláře.

2. Vybrané metodiky obsahující prvky řízení portfolia MMDIS (Multidimensional Management and Development of Information System) “Cílem MMDIS je vývoj, údržba a provoz komplexního a integrovaného informačního systému podniku, který optimálně využívá potenciálu dostupných informačních technologií a informatických služeb k maximální podpoře podnikových cílů.”[5] Jde o komplexní metodiku, složenou z 11 principů a 6 konceptuálních modelů. Proces tvorby projektových záměrů, jejich hodnocení a výběru spadá podle referenčního modelu ITGPM do oblasti strategického řízení podnikové informatiky. Obrázek 1 ilustruje schéma procesu Plánování projektu a příprava projektového záměru. Toto schéma popisuje procesy od identifikace příležitostí a požadavků přes vytvoření projektového záměru, sledování ostatních projektů, návrhu realizace projektu a konečně rozhodnutí o projektu.

Obrázek 1: Schéma procesu Plánování projektu a příprava projektového záměru [5] Pro charakterizaci projektů slouží řada kritérií a metrik k jejich sledování. Jedná se především o počty uživatelů ovlivněných projektem, pracnost, trvání projektu, 8

SYSTÉMOVÁ INTEGRACE 2/2010

IT Project Portfolio Management a úspěšnost projektů

náklady a efekty dosažené řešením projektu. Metriky jsou tedy vesměs odhadované. Na toto schéma navazuje schéma Procesy řízení rozvoje IS/ICT a systémové integrace na Obrázku 2.

Obrázek 2: Procesy řízení rozvoje IS/ICT a systémové integrace [5] Řízení portfolia projektů a jeho vazbu na informační strategii řeší tato vodopádová metodika komplexně, především díky multidimenzionálnímu pohledu na problematiku a zapojení s TQM. Je třeba zvážit, zda nepřiblížit schéma procesu Plánování projektu a příprava projektového záměru blíže agilnějším metodikám. V současnosti dochází k velice rychlému vývoji a změnám v okolí společnosti a dozajista je na to potřeba, pokud to okolnosti dovolují, co nejpružněji reagovat. ITIL 3 (Information Technology Infrastructure Library) V ITIL 3 je řízení portfolia zařazeno převážně do čtvrté části Service strategy. ITIL zavádí pojem Portfolio služeb (bod 4.2.3), což je “souhrn všech závazků a investic realizovaných poskytovatelem služeb pro všechny zákazníky a trh. Představuje současné smluvní závazky, nové služby, vyvíjené služby a plánovaná vylepšení služeb.” [4] Portfolio služeb se dělí na tři podmnožiny. Těmi jsou Katalog služeb, Service Pipeline a Vyřazené služby.  Katalog služeb slouží především jako souhrn aktuálně nabízených služeb pro současné a potenciální zákazníky.  “Service Pipeline” je další podmnožinou Portfolia služeb. “Jedná se o služby vyvíjené pro určitého zákazníka nebo oblast trhu”. [4]  Poslední podmnožinou Katalogu služeb jsou Vyřazené služby. Tyto služby jsou po ukončení jejich provozu vytěženy do znalostní báze a jejich části připraveny k případnému znovupoužití. Toto členění portfolia tedy popisuje stav služeb, jejich nejbližší vývoj a jejich vazbu na okolí. Pokud jde o metody měření návratnosti investice, využívá ITIL 3 především finanční nástroje jako je čistá současná hodnota a vnitřní výnosové procento. Řízením portfolia služeb se ITIL zabývá v části 5.3. Uvádí pět otázek, které pomáhají ujasnit řízení portfolia služeb. Jedná se o:  Proč by si měl zákazník tyto služby koupit?  Proč by si tyto služby měl koupit od nás? SYSTÉMOVÁ INTEGRACE 2/2010

9

Libor Měsíček

 Jaký je model placení?  Jaké jsou naše silné a slabé stránky, priority a ohrožení?  Jakým způsobem použít naše zdroje a schopnosti? Samotné metody pro řízení portfolia je možné nalézt v následující části 5.4. Zde se popisují jednotlivé kroky při tvorbě portfolia. Postup vytváření portfolia ilustruje Obrázek 3. Service Strategy

Define

Inventories Business Case

Analyse

Value Proposition Prioritazion

Approve

Service Portfolio Authorization

Charter

Communication Resource allocation

Obrázek 3: Proces vytváření portfolia služeb podle ITIL 3 [4] Prvním krokem je popsání současných a možných budoucích služeb a jejich provázání s obchodními procesy. Následuje analýza, v jejímž průběhu jsou služby oceněny a rozděleny mimo jiné podle poměru nákladů k výnosům. Investice do služeb lze dělit do tří základních kategorií podle zaměření:  Provoz  Růst  Transformace

10



Podle rozhodnutí managementu je sestaveno portfolio služeb. Tato část procesu tedy umožňuje pochopit současný stav a z něj odvodit budoucí složení služeb. Během procesu jsou rozděleny existující služby do 6 kategorií v závislosti na jejich technické a ekonomické hodnotě. V poslední části je sděleno rozhodnutí o tom, které služby budou zachovány, měněny, ukončeny a nově vytvořeny. Zároveň je navržen nebo upraven rozpočet. Tento proces se periodicky opakuje v závislosti událostech v okolí a uvnitř společnosti. Pojetí řízení portfolia služeb v ITILu v3 je silně zaměřeno na čistě ekonomické a finanční dopady služeb a projektů. Toto zřejmě pramení z orientace metodiky převážně na technologickou stránku informatiky. Právě přílišné zacílení IT oddělení na technickou a formální stránku vede často ke konfliktům s ostatními částmi organizace. Je tedy vhodné upozornit, že toto pojetí přehlíží řadu přínosů jako je vztah a postoj zákazníka ke službě, přivyknutí a zkušenosti při využívání existující služby. CobiT 4.1 a Val IT 2.0 Obdobně jako ITIL, je i CobiT 4.1 postaven na provázanosti mezi strategií podniku a její realizaci za pomoci informačních technologií. CobiT 4.1 doporučuje postupovat od strategického plánu podniku, přes definování taktických plánů IT až po jednotlivé plány projektu. Řízením portfolia se zabývá část Plane and Organize v procesu PO1.6. Proces PO5 se zaměřuje na řízení investic do IT. Prvním krokem je vytvoření finančního rámce. Ten sleduje služby a investice pomocí portfolií investic, vazbu na obchod a rozpočet IT. Následuje výběr projektů a tvorba jejich rozpočtů. Dále jsou řízeny náklady a přínosy. Samotným řízením a vyhodnocováním projektů se zabývá proces PO10. Pro vyhodnocování kvality a výkonu se používá především procento projektů, které naplnily očekávání klíčových zákazníků projektu, míry dodržení standardů pro řízení projektů a také zpětná vazba od uživatelů S rostoucím významem řízení portfolia projektů v oblasti informačních technologií nedostačovalo pokrytí problematiky pomocí CobiTu a vyšel doplněk v podobě knihy Val IT 2.0. Tato publikace doplňuje a zpřesňuje některé procesy spojené s hodnotou a přínosy informačních technologií pro společnost. Portfolio management navazuje podle Val IT na další dva procesy. Jedná se o proces investování a proces dohledu nad hodnotami (Value Governance). Řízení portfolia je složeno ze šesti částí.  Dosažení strategického rozhodnutí a požadovaného složení investic.  Určení dostupnosti zdrojů  Řízení dostupnosti lidských zdrojů  Ohodnocení a výběr programů, které budou financovány.  Sledování výkonu portfolia  Optimalizace výkonu portfolia Každá z těchto částí se dále rozpadá na několik procesů.


11

Libor Měsíček

Pohled CobiTu 4.1 na projekty je díky rozšíření o Val IT 2.0 mnohem širší než u předchozích metodik. Pokrývá větší spektrum aspektů vstupujících do procesu řízení portfolia. Přesto je zde kladen důraz na finanční pohled na projektové záměry a běžící projekty. Finanční metody posuzování projektů jsou v současném ekonomickém prostředí jen obtížně použitelné, vzhledem k téměř nepředvídatelnému vývoji makroekonomických ukazatelů (jak ukazují chybné odhady inflace, růstu HDP a obchodní bilance za poslední dva roky) a obtížného odhadu nákladů na budoucí financování projektů z půjček od bankovního sektoru. V okamžiku nepředvídatelného vývoje inflace je třeba preferovat širší pojetí srovnávání projektů a jejich přínosů.

3. Klasifikace IT projektů a kritéria Projektové záměry a IT projekty je možné klasifikovat z mnoha pohledů (příklad klasifikace v Tabulce 1) a díky tomu vzniká velké množství různých kombinací. Parametr projektu

Rozsah

Rozpočet

<=100 tis. Kč <= 30 dní <=500 h Technologie

<= 500 tis. Kč <= 90 dní <= 2000 h Aplikace

<= 2 mil. Kč <= 180 dní <= 10000 h Procesy

Převážně na počátku projektu <= 7

Převážně na konci projektu <= 14

Periodické

Žádný

Doba trvání Pracnost Hlavní zaměření projektu Čerpání rozpočtu Počet pracovníků přidělených na projekt Vliv na okolí společnosti Požadavky na zkušenosti pracovníků Míra inovace Zaměření projektu Podpora projektu zaměstnanci

<= 5 mil. Kč <= 365 dní <= 20000 h Kombinace předchozích Rovnoměrné

> 5 mil. Kč > 365 dní >20000 h

<= 32

<=65

>65

Malý

Střední

Velký

Zásadní

Minimální

Nízké

Střední

Vysoké

Maximální

Žádná Opuštění trhu

Nízká Udržení pozice na trhu Nízká

Střední Růst podílu na trhu

Vysoká Expanze na nové trhy Vysoká

Zásadní

Minimální

Střední

Nepravidelné

Maximální

Tabulka 1 : Vybrané parametry projektů Projekty se mohou svoji povahou výrazně lišit. Některé technologické projekty (např. rozšíření kapacity datového uložiště) trvají maximálně několik týdnů a mají pracnost v řádu stovek hodin, střední rozpočet, malý počet zapojených pracovníků a minimálním přímý vliv na okolí společnosti. Na druhou stranu existují projekty se zásadním vlivem na okolí společnosti s dlouhou dobou trvání a nízkou intenzitou prací a malým rozpočtem. Je zřejmé, že při takovém širokém spektru projektů je

12



velmi obtížné, ne-li nemožné, na všechny typy projektů použít stejné metriky a kritéria a tím zajistit jejich vzájemnou porovnatelnost pro potřeby IT PPM. V Tabulce 2 je navrženo několik vhodných metrik pro vybraný pohled (Hlavní zaměření projektu) na projekt. Kritérium

Metrika

Tech. projekt

Aplik. projekt

Procesní /BPR

Kombinace

Skutečný čas /plánovaný čas na projekt Skutečné náklady / Plánované náklady Počet závažných odchylek od standardů a požadavků Procento z pracovní doby, kdy pracovník čeká na událost

x

x

x

x

Průměrný počet hodin školení pracovníka Procento dodaných funkcí z požadovaných funkcí Skutečný počet operací/maximální možný počet operací za období Procento uživatelů používajících alespoň 1x za posledních 30 dnů alespoň 50% z nových funkcí Obrat po uvedení/obrat před uvedením Zisk po uvedení/Zisk před uvedením Tržní podíl po uvedení/Tržní podíl před uvedením

Projekt Minimalizace doby trvání projektu Minimalizace nákladů na projekt Dodržení požadované kvality Maximalizace využiti pracovníků Produkty dodané projektem Nové dovednosti pracovníků IT Požadovaná funkcionalita Využití kapacit

Využití nových funkcí

Růst obratu Růst zisku Růst tržního podílu


x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

13

Libor Měsíček

Kritérium

Metrika

Tech. projekt

Aplik. projekt

Procesní /BPR

Kombinace

Náklady po uvedení/ Náklady před uvedením Spokojenost uživatelů po uvedení/spokojenost uživatelů před uvedením (průzkum) Procento uživatelů využívajících produkt Průzkum veřejného mínění po uvedení produktu/Průzkum veřejného mínění před uvedením produktu

x

x

x

x

x

x

x

Projekt Pokles nákladů Spokojenost uživatelů

Přijetí projektu Zlepšení dobrého jména společnosti

x

x

x

x

x

x

Tabulka 2 : Vhodné metriky podle typu IT projektu – Hlavní zaměření projektu Jak je vidět z Tabulky 2 rozděluji kritéria na dvě části. První část se týká samotného projektu a jeho parametrů. Druhá část sleduje produkty anebo efekty které jsou výstupem projektu. Jde o kombinaci měkkých i tvrdých metrik, zároveň se snažím i o postihnutí vedlejších efektů projektů (např. vliv na kvalifikaci zaměstnance v oblasti IT). V následující Tabulce 3 je použito stejných kritérií, ale z pohledu času. Jsou zde projekty trvající do 30 dnů, 90 dnů, 180 dnů, 365 dnů a projekty nad 365 dnů. V závislosti na tom zda jde o krátkodobý nebo dlouhodobý projekt je rozumné sledovat odlišná kritéria. Je zřejmé, že u dlouhodobých projektů je pravděpodobnost správného odhadu doby trvání projektu relativně nízká, proto význam této metriky klesá, stejně tak je velmi obtížné odhadnout náklady na projekt trvající déle než jeden rok. Tento odhad nákladů může být výrazně ovlivněn budoucí změnou cenové hladiny, kurzy a mnoha dalšími riziky, proto toto kritérium u dlouhodobých projektů není vhodné. Kritérium Projekt Minimalizace doby trvání projektu Minimalizace nákladů na projekt Dodržení požadované kvality

14

Metrika

Skutečný čas /plánovaný čas na projekt Skutečné náklady / Plánované náklady Počet závažných odchylek od standardů a požadavků

<= 30 dní

x

<= 90 dní

<= 180 dní

<= 365 dní

x

x

x

x

x

x

x

x

> 365 dní

x



Kritérium Projekt Maximalizace využiti pracovníků Produkty dodané projektem Nové dovednosti pracovníků IT Požadovaná funkcionalita Využití kapacit

Využití nových funkcí

Růst obratu Růst zisku Růst tržního podílu Pokles nákladů Spokojenost uživatelů

Přijetí projektu Zlepšení dobrého jména společnosti

Metrika

<= 30 dní

<= 180 dní

<= 365 dní

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Procento z pracovní doby, kdy pracovník čeká na událost Průměrný počet hodin školení pracovníka Procento dodaných funkcí z požadovaných funkcí Skutečný počet operací/maximální možný počet operací za období Procento uživatelů používajících alespoň 1x za posledních 30 dnů alespoň 50% z nových funkcí Obrat po uvedení/obrat před uvedením Zisk po uvedení/Zisk před uvedením Tržní podíl po uvedení/Tržní podíl před uvedením Náklady po uvedení/ Náklady před uvedením Spokojenost uživatelů po uvedení/spokojenost uživatelů před uvedením (průzkum) Procento uživatelů využívajících produkt Průzkum veřejného mínění po uvedení produktu/Průzkum veřejného mínění před uvedením produktu

<= 90 dní

> 365 dní

Tabulka 3 - Vhodné metriky podle typu IT projektu – Hlavní zaměření projektu SYSTÉMOVÁ INTEGRACE 2/2010

15

Libor Měsíček

Prolnutím Tabulky 2 s Tabulkou 3 lze vyvodit závěry o vhodnosti využití konkrétního kritéria pro sledování určitého projektu. Je ovšem zřejmé, že při vysoké rozmanitosti projektů si musí konkrétní podnik množinu kritérií upravit podle konkrétní situace. Řada průzkumů upozorňuje na vysokou neúspěšnost IT projektů1. Míra nespěšnosti se v závislosti na zdrojích liší, uvádí se, že minimálně 70% IT projektů selže. Toto číslo se za poslední desetiletí nedaří výrazně snižovat. Je třeba si uvědomit, že průměr nebo procentní zastoupení v tomto případě nemá téměř žádnou vypovídací hodnotu. Mohlo dojít k situaci, kdy se u malého projektu zpozdila dodávka hardwaru pro zařízení prodejen o několik dnů. Projekt vybavení prodejen díky překročení plánované doby realizace spadl do kategorie neúspěšných, přestože škody jsou minimální a prodejny úspěšně fungují, generují obrat a potažmo zisk. Na druhou stranu velký projekt s významným dopadem na okolí společnosti může být úspěšně dokončen a předán do užívání, ale produkt po skončení reklamní kampaně bude stažen z nabídky pro nedostatek zákazníků. Lze tedy dělit projekty na úspěšné či neúspěšné podle toho zda se jim podařilo naplnit plány a předat produkt? Jak je vidět z výše uvedených příkladů, projekt může být podle klasických měřítek neúspěšný a přesto jeho produkt může mít úspěch a plnit svoji funkci. Mnohokrát slýcháme, že role IT se mění. Už nejde o technologie, v centru pozornosti je především produkt a služby byznysu. Proto je třeba revidovat i vyhodnocování IT projektů a podřídit ho trendům. IT se stalo nástrojem k dosažení cílů a tvorbě nových produktů. Projekty jsou realizovány nikoli kvůli projektu jako takovému, ale především kvůli efektu, který má projekt dodat. Proto je třeba hodnotit projekty nikoli pouze podle toho, zda jejich produkt splnil požadavky zadání projektu, ale především podle jeho úspěchu v delším časovém období. Zároveň je třeba sledovat nejen procento neúspěšných projektů, ale především jejich velikost a rozsah problémů, které případný “neúspěšný projekt” provází. V průběhu přípravy projektu je většina parametrů odhadována s určitou přesností a na základě předchozích zkušeností. Ovšem v závislosti na finálním složení týmu a jeho zkušenosti a znalosti může být například zadaná aplikace tvořena několik dní anebo týdnů podle toho zda již tým podobnou aplikaci řešil nebo ne. Protože složení projektového týmu není při první fázi posuzování záměru jasné lze jen velice těžko odhadnout čas nutný ke skutečné realizaci projektu. Dalším důležitým faktorem je firemní kultura. Ta silně omezuje možnosti použití některých nástrojů pro řízení projektů, nebo naopak některé nástroje upřednostňuje. Pokud je povaha metodiky řízení a hodnocení projektů v souladu s podnikovou kulturou, to znamená, že například míra formálnosti komunikace vyžadovaná metodikou odpovídá formálnosti a způsobu komunikace v podniku, je odpor vůči jejímu zavedení a používání nižší, než u konkurenčních metodik s odlišnou mírou formálnosti. 1

Překročení plánovaného rozpočtu, času nebo nedodání požadované funkcionality v požadované kvalitě. 16



4. Řešení několika problémů: Konzultace, externisté nebo outsourcing Jak již bylo zmíněno, řada společností se potýká s problémy jak v projektovém řízení, tak v řízení portfolia projektů. Při hledání příčin, respektive řešení, tohoto stavu je třeba zvážit, zda stejně jako v případě vývoje a provozu informačních systémů není vhodné vyhledat pomoc specializované externí společnosti. Obrázek 4 popisuje situaci, kdy je interní Project Management Office (PMO) vyčleněna ze společnosti a zajišťuje provoz pro několik nezávislých společností.

Obrázek 4: Sdílení PMO několika společnostmi Na tuto externí společnost lze poté převést smluvně podložené činnosti spojené s procesy řízení portfolia a provozem externí Project Management Office. Důvodů ke zvážení nového, metodikami zatím přímo nepodporovaného, pojetí je celá řada. Nově vzniklá specializovaná firma může akumulovat mnohem rychleji zkušenosti s vedením portfolia několika klientů a dosáhne pravděpodobně lepších výsledků. Zároveň vzroste míra využití stávajících nástrojů pro řízení portfolia v porovnání s nezkušeným oddělením firmy a projektové kanceláře. Procesy řízení portfolia jedné firmy mají často velké výkyvy/špičky ve využití technických zdrojů a pracovní síly v průběhu roku. Střídají se období rutinního sběru dat s obdobími přehodnocování a změn v portfoliu projektu. Náklady spojené s provozem PMO, ať už jde o kancelářské prostory a jejich vybavení, zaměstnance, licence na specializované programy, tvoří významné SYSTÉMOVÁ INTEGRACE 2/2010

17

Libor Měsíček

procento nákladů na provoz projektové kanceláře. Pokud by došlo k vyčlenění samostatné PMO a její sdílení několika společnostmi vedlo by to k rozdělení těchto nákladů. Dalším výrazným přínosem by bylo získání globálnějšího pohledu na projektové záměry a korekce odhadů prostřednictvím specialisty z externí společnosti. Pokud by došlo k akumulaci zkušeností a znalostí do jednotné báze, lze předpokládat výrazné zlepšení dodávaných efektů oddělením IT. Důležitý faktor ovlivňující vysokou míru neúspěchů IT projektů spočívá podle [3] nikoli v technické stránce, ale v měkkých faktorech. Tedy ve vztazích a postojích zaměstnanců. Průzkum [6] provedený v ČR v roce 2009 opět potvrdil, že problémem po implementaci metodik v oblasti chování zůstává “Nedostatečné zapojení businessu při definování požadavků a testování”. U osobních postojů je problém ještě výraznější. Nejčastější problémy stále zůstávají:  IT není vnímáno jako partner s přidanou hodnotou pro business  Neexistující porozumění obchodním prioritám a dopadům  Žádný partner se nesnaží porozumět druhému Nasazení odborníků z externí společnosti a rozšíření jejich působnosti z čistě technické oblasti na oblast měkkých faktorů může do značné míry tyto problémy redukovat a odstranit třecí plochy mezi jednotlivými odděleními, vytvořit zprostředkovatele komunikace a vyjednávání. Externí pracovník rozšířené PMO může tedy plnit úlohu neutrální třetí strany zajišťující vzájemné porozumění několika odlišných kultur. Navrhované řešení ovšem nese všechna potenciální rizika a problémy spojené s outsourcingem. V tomto případě jde především o důvěryhodnost a stabilitu poskytovatele služeb, únik informací, technickou odbornost a sociální kompetenci externích pracovníků. Zároveň může docházet k problémům plynoucím z různých podnikových kultur a způsobu řízení ve společnostech, pro které bude pomocí PMO zajišťováno řízení portfolia. Možnost vzniku externích PMO, rozšíření jejich působnosti o zprostředkování komunikace mezi rozdílnými kulturami v jednotlivých odděleních podniku a celkovou životaschopnost tohoto konceptu je nutné dále ověřovat.

5. Závěr Přestože existuje řada metodik k řízení portfolia projektů nedochází k výraznému zlepšení míry úspěšnosti IT projektů. To lze přičíst na vrub dvěma faktorům. Měříme především počet neúspěšných projektů a nikoliv podíl jejich rozpočtů, důležitosti, míry problémů a závažnosti jejich dopadů. Za druhé samotný projekt není cílem proč byznys projekt spouští. Jde mu o efekt který má projekt dodat. Má tedy smysl především zpětně hodnotit projekty podle toho, jak se osvědčil jeho produkt. Řada projektů přináší neplánované přínosy, které v době jejich spuštění nebylo možné odhalit a ohodnotit. Zlepšení kvality, relevance a nezávislosti odhadů, maximalizaci synergického efektu a minimalizaci rizik lze pravděpodobně dosáhnout vytěsněním procesu vytváření a částečně i rozhodování o projektových záměrech ze společnosti za pomoci specializované firmy. Ta pak ve spolupráci s vedením společnosti

18



uskutečňuje proces řízení portfolia od počáteční identifikace příležitostí až po ohodnocení a sledování jednotlivých projektů. Přístup externí PMO zatím není zapracován do metodik zaměřených na řízení portfolia a jeho případnou životaschopnost v prostředí kultury České republiky je nutné dále zkoumat a postupně ověřovat v praxi.

6. Literatura [1] Brache, A.P., Boodley-Scott, S. Which Initiatives Should You Implement?. Harvard: Harvard Business School Publishing, 2009. Roč. 14, číslo 4, ISSN: 1525-9595 [2] Gartner, Executive Summery. [On-line] [cit.2009-11-15] Dostupný z WWW: http://www.gartner.com/resources/165000/165048/executive_summary_meetin g_th_165048.pdf [3] Nunno, T. Top Political Landmines Faced by CIOs: Surviving and Thriving [online][cit. 2010-02-02]Dostupný z WWW: < http://agendabuilder.gartner.com/esc20/WebPages/SessionDetail.aspx?EventS essionId=844 > [4] OGC. ITIL Service Strategy, London: Stationery Office, 2007, ISBN 978-0-11-331045-6 [5] Voříšek, J. Principy a modely řízení podnikové informatiky, Praha: Oeconomica, 2008. ISBN 978-80-245-1440-6 [6] ITIL ”worst practice” – výsledky průzkumu Česká společnost pro systémovou integraci [on-line][cit. 2010-02-01] Dostupný z WWW:


19

IT Project Portfolio Management a úspěšnost projektů

Recommend Documents