facebook LinkedIN LinkedIN - follow
IT SYSTEMS 10/2013 , Projektové řízení

Kritická místa implementačního projektu

Jak jimi úspěšně projít?



DeloittePodle světových statistik končí téměř 35 procent implementačních projektů neúspěšně. Za neúspěch se přitom obecně považuje především nenaplnění požadavků na funkcionalitu, významné zpoždění v termínech nasazení a výrazné navýšení investice v průběhu realizace. Kde se na projektové dráze skrývají ty nejzáludnější zatáčky a šikany, na jejichž projetí je třeba si dát dobrý pozor a možná někdy raději přibrzdit? O tom je následující článek.


Příprava před startem

Podceňovanou aktivitou je často příprava před startem projektu. Je běžnou praxí, že zákazník i dodavatel si ujasňují obsah a rozsah zadání projektu až v momentě, kdy se snaží za doprovodu vzájemných kompromisů podepsat smlouvu. Způsob, jak se tomuto momentu vyhnout, je sice časově a kapacitně náročný (vyžaduje mimo jiné zapojení všech sponzorů a hlavních „stakeholderů“), ale vrátí se stejně jako dřina na tréninku před závodem. Řeč je o úsilí věnovaném kvalitní definici záměru projektu, který bude vycházet ze strategie organizace, a následné specifikaci v poptávkovém dokumentu. Už v tomto momentu je třeba myslet na to, že kvalita obdržených nabídek se zpravidla úměrně rovná kvalitě vypsané poptávky.

Z pohledu zákazníka je možné považovat poptávkový dokument za kvalitní a úplný v případě, že mimo standardních formálních a obligatorních náležitostí také odpovídá na následující otázky:

  • Jakých ekonomických, organizačních a technologických cílů má být pomocí dodávky dosaženo a jak tyto cíle korespondují s celkovou firemní strategií?
  • Jaké jsou funkce současného systému, které z nich chceme zachovat? Jak funkce zapadají do současné organizační struktury či útvarů a jaké procesy jsou klíčové?
  • Jaké jsou funkční požadavky pro každý business proces nebo soubor těchto procesů? (Zde se vyplatí ujasnit si, které funkcionality jsou „must have“, a které pouze „nice to have“, dále je třeba zohlednit i požadavky budoucí – například legislativní.)
  • Jaké jsou nefunkční požadavky (např. infrastrukturní, datové) na budoucí systém?
  • Jaké reference, kvalifikační předpoklady a nároky na řešitelský tým musí zájemce splnit?
  • Další otázky týkající se míry detailu návrhu implementace ze strany zájemce, metodického přístupu k realizaci, postupu přechodu do cílového stavu, ceny a harmonogramu projektu.

Procesu tvorby poptávkového dokumentu by se měli účastnit IT specialisté, experti obchodních procesů i představitelé širšího vedení. Zapojení všech dotčených organizačních jednotek firmy již v tomto momentě zvyšuje všeobecný zájem o konečné řešení a pomáhá vytvořit předpoklady pro nezbytnou budoucí spolupráci týmů napříč celou organizací. Pro celé výběrové řízení by také mělo být vyhrazeno adekvátní množství času, tak aby proběhlo efektivně, ale s co nejmenším množstvím nejasností.

První průběžné hodnocení výsledků

Ačkoli k monitoringu, hodnocení výsledků a aktivit dochází od začátku projektu průběžně, kompletní „servisní prohlídku po první etapě“ představuje vždy až moment ukončení analytické fáze, respektive akceptace návrhu řešení, které slouží jako podklad pro vývoj nového systému. Často jde o jeden ze zásadních milníků projektu, ve kterém je nutné vyhodnotit dosavadní průběh realizace, identifikovat problematické oblasti a jejich dopad na řešení dalších fází projektu. V implementační praxi platí, že v případě, kdy dojde k posunutí milníku ukončení analýzy, respektive návrhu řešení, je tento posun třeba akceptovat, neboť je nepravděpodobné, že by se toto zdržení dalo absorbovat v rámci některé z následujících fází. Náročnost této etapy projektu podtrhuje také fakt, že v tomto momentě je do projektu obvykle zapojeno maximální množství kapacit, jak na straně zákazníka, tak na straně dodavatele. Dochází k předávání obsáhlých dokumentů, které musí být systematicky revidovány ze strany zástupců všech zainteresovaných stran, vznikají sady připomínek a revizí, jejichž zpracování musí být efektivně a transparentně řízeno, dochází k validaci vazeb napříč dokumenty funkčních specifikací a technických návrhů řešení a vznikají spory o prioritizaci zakládání změnových požadavků na funkcionality, které byly či nebyly zamýšleny v rozsahu dodávky.

Pravděpodobně neexistuje přesný návod, jak se typickým problémům, rizikům a krizovým situacím v této etapě projektu vyhnout. Existuje však řada best practices, které je vhodné aplikovat již v průběhu analýzy, a které by měly pomoci projektovým manažerům snížit dopady těchto problémů, nebo se jim vyhnout:

  • Od začátku projektu je třeba komunikovat vlastníkům obchodních procesů a expertům odborných útvarů fakt, že konečná verifikace a validace funkčních specifikací je součást jejich odpovědností.
  • Čím detailněji a specifičtěji budou stanovena akceptační kritéria všech výstupů, tím transparentnější diskuse bude probíhat nad tématem „kvalita dodávaných výstupů“.
  • Pro konečnou revizi výstupů návrhu řešení je vhodné počítat s časovou a kapacitní rezervou.
  • Od začátku je nutnou podmínkou detailní nastavení procesu práce s výstupy a jejich vzniku, stanovení lhůt pro revize, způsob sběru připomínek a definice nesdílených odpovědností za tyto aktivity vedoucí k finální akceptaci výstupů.
  • V rámci nastavení metodiky řízení projektu je třeba detailně vydefinovat proces změnového řízení a tolerance pro změny stávajících a nových funkcionalit. V rámci tohoto procesu je třeba stanovit odpovědnosti i pro experty procesních oblastí a vedoucí pracovníky, kteří by měli spolurozhodovat o potřebách změn funkcionalit ve vztahu k možným finančním a časovým dopadům.

Zatáčka před cílovou rovinkou

Za předpokladu, že projektovým cílem je termín nasazení systému do provozu, je poslední zatáčkou před cílovou rovinkou bezesporu otestování správné funkčnosti nového systému. Reálná praxe implementačních projektů ukazuje, že fáze testování je ve většině případů podceňovaná. Podle průzkumů se také jedná o projektovou aktivitu s nejvyššími nároky, jak na plánování a přípravu, tak na samotné provedení a kontrolu.

Typickým důsledkem špatného plánování fáze testování je neúplné otestování veškerých funkčností nebo nedokončení všech testů. To vede k odhalení kritických chyb až ve fázi uživatelských akceptačních testů a ke zvýšené potřebě času či vzniku vícenákladů nutných pro jejich odstranění.Typickým příkladem jsou kompromisy a ústupky učiněné ve smyslu nedodržování základních pravidel při realizaci systémových a integračních testů, které se jako bumerang obratem vrátí při testování end-to-end procesů klíčovými uživateli.

Jaká jsou základní pravidla pro úspěšné otestování nového systému? Je důležité, aby příprava testování byla jednou z aktivit, která je realizovaná v průběhu celého životního cyklu projektu. Při implementaci rozsáhlých systémů je třeba počítat s dostatečným časem pro kompletní otestování nového systému (například u projektů s celkovou délkou trvání dva roky, by se pro fázi testování mělo počítat s minimální délkou 19 týdnů). Je vhodné si dát záležet na detailním popisu obsahu jednotlivých typů testů a testovacích scénářů, aby pokrývaly veškeré požadované funkcionality. V neposlední řadě je nutné včas nastavit celkový proces testování, tedy nástroje, úrovně reportingu, role a odpovědnosti.

Od začátku projektu je samozřejmě nutné komunikovat požadavky na zdroje, nejen co do počtu potřebných odpovědných osob, ale i v souvislosti s požadovanými kompetencemi. Tým odpovědný za testování musí být složen jak z manažerů odpovědných za nastavení procesu a řízení aktivit, tak z IT expertů a zástupců klíčových uživatelů.

On time, in full, on budget

Pokud se v rámci projektů podaří mitigovat startovní rizika spojená s definicí zadání, správně připravit obsah, rozsah a míru detailu v poptávkovém dokumentu, připravit a realizovat náročnou analytickou fázi s ohledem na kapacity i organizační zajištění a následně nepodcenit potřebný rozsah testování, je pravděpodobné, že projekt prošel těmi nejkritičtějšími místy. To ovšem neznamená, že se v průběhu jeho realizace neobjeví další problémy, kterým musí každý projektový manažer na denní bázi čelit. Závěrem připomeňme, že obecně vnímaným měřítkem úspěchu, podle kterého je nakonec každý projekt hodnocen, zůstává kritérium OTIFOB (on time, in full, on budget). Výše uvedená doporučení týkající se kritických míst v projektu jsou tedy pouze prostředky, které povedou k jeho snazšímu dosažení.

Romana Hůlková

Autorka působí jako senior konzultantka ve společnosti Deloitte. Je součástí týmu zaměřeného na IT governance, projektové řízení v IT a řízení rizik. Má zkušenosti s prováděním funkčních analýz v oblasti ICT, s implementací systémů ERP a core banking systémů, se zaváděním metodik projektového řízení a působí na projektech kontroly kvality při implementacích softwarových řešení.

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

Konec papírování, digitalizujte a usnadněte si práci!

IT Systems 3/2024V aktuálním vydání IT Systems jsme se zaměřili na vývoj digitalizace ve světě peněz, tedy v oblasti finančnictví a pojišťovnictví. Dozvíte se například, proč je aktuální směrnice PSD2 v inovaci online bankovnictví krokem vedle a jak by její nedostatky měla napravit připravovaná PSD3. Hodně prostoru věnujeme také digitalizaci státní správy a veřejného sektoru, která nabírá obrátky.