Najčastejšie dôvody zlyhania IT projektu a ako ich spoznať včas

Ako sme vybrali poradie dôvodov zlyhania IT projektu?

Poradie sme neurčili podľa dojmu, ale podľa toho, čo v praxi najčastejšie poškodí hodnotu projektu: najprv biznisový cieľ, potom analýzu, plán, ľudí, komunikáciu a napokon spôsob nasadenia. Vyššie sme zaradili faktory, ktoré vedia projekt pokaziť skôr a s drahším dopadom.

Pri poradí sme pracovali so 4 kritériami:

1. Ako skoro problém zničí hodnotu projektu - či zmení smer ešte pred vývojom, alebo sa prejaví až počas nasadenia.
2. Aký má dopad na rozpočet a termín - či spôsobí menšie trenie, alebo rozsiahle prepracovanie.
3. Ako často sa prejavuje vo firemných IT projektoch - najmä pri CRM, interných systémoch, webových aplikáciách a automatizáciách.
4. Ako ľahko sa dá otočiť späť - či stačí jedno rozhodnutie, alebo je potrebné prepísať backlog, architektúru a procesy.

Preto sú na prvých miestach stratégia a analýza, nie technológia. Keď firma presne nevie, aký výsledok očakáva, alebo požiadavky opíše len povrchne, ani kvalitný tím nevie dodať správny systém. Pri rastúcej komplexite sa riziko zvyšuje výrazne. PMI uvádza, že 97 % profesionálov riadilo za posledný rok aspoň jeden komplexný projekt, približne tretina komplexných projektov nedosiahne pôvodne zamýšľané ciele a tímy, ktoré zvládajú komplexitu efektívne, zvyšujú pravdepodobnosť úspechu 5-násobne.

Tento rebríček preto nesleduje iba chyby projektového manažmentu. Zahŕňa aj chyby na strane vedenia firmy, ownershipu, priorít a rozhodovania, pretože práve tieto oblasti pri IT projektoch určujú, či sa vyvíja užitočný nástroj, alebo len nákladný zoznam funkcií.

Prečo sú nejasné ciele a nemerateľný výsledok dôvod číslo 1?

Dôvod číslo 1 je nejasný cieľ, pretože ovplyvní všetko ostatné ešte pred prvou vývojovou úlohou. Ak tím nevie, čo má projekt zmeniť v biznise, nevie správne rozhodovať o rozsahu, prioritách ani architektúre. Výsledkom býva softvér, ktorý technicky funguje, ale neprináša očakávaný výsledok.

Najtypickejší symptóm je, že každý stakeholder opisuje úspech projektu inak. Obchod očakáva viac leadov, prevádzka menej ručnej práce, manažment reporting a používateľ rýchlejšie schvaľovanie. Všetko môže byť oprávnené, no ak z toho nevznikne jedna spoločná definícia výsledku, backlog sa zmení na kompromis bez jasného smeru.

V praxi odporúčame pred analýzou pomenovať 3 veci:

• jeden hlavný biznisový cieľ, napríklad skrátiť schvaľovanie objednávok,
• tri merateľné ukazovatele úspechu, napríklad čas spracovania, chybovosť, počet ručných krokov,
• jasné out of scope, teda čo tento release nerieši.

Pri projektoch ako CRM na mieru je toto základ, pretože bez definície výsledku sa z CRM rýchlo stane len sklad kontaktov, nie nástroj, ktorý riadi obchodný proces. Ak teda vo vašom tíme zaznieva veta „uvidíme počas vývoja“, problém veľmi pravdepodobne nezačína v kóde, ale v nejasnom cieli.

Prečo je povrchná analýza požiadaviek a procesov dôvod číslo 2?

Dôvod číslo 2 je povrchná analýza, pretože vytvára nákladný typ chyby: projekt určitý čas pôsobí zdravo, ale po prvých demách sa ukáže, že systém neodráža reálnu prevádzku firmy. Vtedy už nejde o malé úpravy, ale o prepracovanie workflow, rolí, integrácií a dát.

Firmy často opíšu iba ideálny proces. Vynechajú výnimky, schvaľovacie pravidlá, duplicity v dátach, exporty do účtovníctva, prepojenia na e-shop, práva používateľov alebo situácie, keď zákazník urobí niečo neštandardné. Práve tieto detaily rozhodujú, či systém prácu zjednoduší, alebo ju ešte viac skomplikuje.

Dobrá analýza požiadaviek preto nemá zbierať iba zoznam funkcií. Má rozobrať:

• kto robí ktorý krok,
• odkiaľ prichádzajú dáta,
• čo spúšťa výnimky a schvaľovanie,
• ktoré integrácie sú kritické,
• podľa čoho sa bude výstup preberať.

Pri vývoji na mieru je to rozdiel medzi systémom, ktorý rešpektuje reálne procesy firmy, a systémom, ktorý firmu núti obchádzať vlastné pravidlá. Rovnako to platí pri automatizačných riešeniach: ak nepoznáte presný tok dát a výnimiek, neautomatizujete proces, iba presúvate chaos do nového nástroja.

Ak sa zásadné požiadavky objavia až po prvom prototype, projekt pravdepodobne netrpí slabým vývojom, ale slabou analýzou.

Ako sa nerealistický rozsah, termín a rozpočet stávajú dôvodom číslo 3?

Dôvod číslo 3 je nerealistický plán, pretože aj dobrý projekt vie zmeniť na sériu núdzových kompromisov. Keď je rozsah príliš široký, termín príliš pevný a rozpočet príliš tesný, tím nezačne robiť lepšie rozhodnutia. Začne skracovať analýzu, testovanie, dokumentáciu a kvalitu.

Typický scenár vyzerá takto: firma chce v jednom release spustiť nový CRM workflow, reporting, mobilný prístup, viacero integrácií, migráciu historických dát aj nový zákaznícky portál. Na papieri to pôsobí efektívne, v realite sa však hromadí závislosť na závislosti. Stačí jedno meškanie a padá celý plán.

Najspoľahlivejšia korekcia nie je „pracovať rýchlejšie“, ale zmenšiť prvý cieľ. V prvom release by mal zostať iba taký rozsah projektu, ktorý:

1. rieši jeden hlavný proces end to end,
2. dá sa otestovať na reálnych používateľoch,
3. prináša merateľný výsledok,
4. nevytvára technický dlh len preto, aby sa stihol termín.

Ak je v projekte všetko kritické, v skutočnosti nie je prioritizované nič. Ak sa plán rozpadá ešte pred prvým funkčným výstupom, problém nebýva disciplína tímu, ale zlý odhad rozsahu voči času a kapacitám.

Prečo je chýbajúci vlastník projektu na strane firmy dôvod číslo 4?

Dôvod číslo 4 je slabý ownership, pretože bez človeka na strane firmy, ktorý projekt vlastní, rozhoduje a prepája biznis s implementáciou, začne projekt stáť aj pri silnom dodávateľovi. Bez tejto roly sa neuzatvárajú priority, schvaľovanie sa vlečie a tím čaká na odpovede.

Najčastejšie sa to prejaví tak, že na workshope sú ľudia, ktorí vedia opísať problém, ale nemajú mandát rozhodnúť. Alebo naopak, rozhoduje manažment, ktorý proces nevidí v každodennej realite. Výsledok je rovnaký: backlog sa mení, ale projekt sa neposúva.

Projekt potrebuje minimálne tieto roly na strane klienta:

• vlastníka cieľa, ktorý určí prioritu,
• kľúčového používateľa, ktorý pozná proces v detailoch,
• človeka pre dáta a integrácie, ak systém siaha do viacerých nástrojov,
• schvaľovateľa rozhodnutí, aby sa zmeny nehromadili v inboxe týždne.

Nejde len o súkromnú skúsenosť dodávateľov. MIRRI SR medzi 5 princípov riadenia IT projektov výslovne uvádza dostatočné interné odborné kapacity, vymenúva kľúčové projektové roly a pri národných projektoch ráta minimálne s 15 % rozpočtu na interné kapacity pre návrh, riadenie a odovzdanie do prevádzky.

Ak teda dodávateľ pravidelne čaká na vstupy, nie je to administratívny detail. Je to jeden z hlavných dôvodov, prečo sa IT projekt rozpadá zvnútra.

Ako sa slabá komunikácia a neriadené zmeny menia na dôvod číslo 5?

Dôvod číslo 5 je slabá komunikácia, pretože projekt neničí jedným veľkým incidentom, ale priebežným rozchádzaním reality. Málokedy je prvotnou príčinou, no veľmi často zrýchli pád projektu, ktorý už trpí nejasným cieľom, slabou analýzou alebo slabým ownershipom.

Problém nebýva v tom, že tím má málo meetingov. Problém je, že neexistuje jeden zdroj pravdy. Požiadavky sú čiastočne v mailoch, čiastočne v chate, časť zostane povedaná na calle a časť sa „nejako dorozumie“ počas vývoja. Po 2 týždňoch už nikto nevie, čo bolo schválené, čo je iba návrh a čo je nový nápad.

Najviac pomáhajú 4 jednoduché pravidlá:

• každé rozhodnutie má majiteľa a dátum,
• každá zmena rozsahu ide do change logu,
• každá priorita má jedného schvaľovateľa,
• každé demo končí jasným zoznamom ďalších krokov.

Ak sa po každej prezentácii otvoria úplne nové témy, ak si obchod s prevádzkou odporujú a ak tím počúva 3 rôzne verzie zadania, komunikačný problém už nie je mäkká zručnosť. Je to priamy dôvod rastu ceny, termínu aj frustrácie.

Prečo je megalomanský štart bez fázovania dôvod číslo 6?

Dôvod číslo 6 je príliš veľký štart, pretože naraz zvyšuje riziko vo všetkých ostatných oblastiach. Čím viac modulov, integrácií, tímov a očakávaní vložíte do prvého release, tým ťažšie sa projekt testuje, schvaľuje, koriguje aj nasadzuje. Big bang prístup často iba odkladá spätnú väzbu.

Tento vzorec sa opakuje aj v odbornej literatúre. Podľa štúdie na ResearchGate bývajú mnohé e-commerce projekty „príliš komplexné a megalomanské“, aby sa dali rozumne zaviesť do praxe. Rovnaký mechanizmus vidíme aj pri interných systémoch, CRM či automatizáciách.

Lepší prístup je fázovanie projektu podľa hodnoty a rizika:

1. najprv spustiť proces, ktorý prinesie výsledok najskôr,
2. potom doplniť integrácie s najvyšším dopadom,
3. až následne rozširovať reporting, automatizácie a doplnkové roly.

Ak si firma nevie predstaviť prvý release bez desiatich „nutných“ oblastí, je to skôr signál slabej prioritizácie než reálnej potreby. Pre inšpiráciu, ako pomáha postupné doručovanie, majú zmysel aj ukážky realizácií, kde je dobre vidieť, že funkčný systém nemusí vzniknúť naraz.

Ako sa tieto dôvody porovnávajú v jednej tabuľke?

Najrýchlejšie sa v príčinách zorientujete porovnaním podľa skorých signálov, typického dopadu a prvého zásahu. Vďaka tomu uvidíte, či váš projekt zlyháva skôr na stratégii, analýze, kapacitách alebo spôsobe doručovania. Tabuľka slúži ako rýchla diagnostika pre vedenie aj projektový tím.

Poradie	Dôvod	Ako ho spoznáte skoro	Typický dopad	Prvý rozumný zásah
1	Nejasné ciele a nemerateľný výsledok	Každý definuje úspech inak, chýba out of scope	Projekt doručí funkcie, nie výsledok	Zjednotiť 1 cieľ, 3 KPI a ownera
2	Povrchná analýza požiadaviek a procesov	Výnimky, dáta a integrácie sa objavujú až počas vývoja	Drahé prepracovanie workflow a logiky	Dopísať procesy, roly, edge cases a akceptačné kritériá
3	Nerealistický rozsah, termín a rozpočet	Všetko je priorita, plán je natlačený bez rezervy	Skrátené testovanie, technický dlh, meškanie	Zmenšiť prvý release na jeden hlavný proces
4	Chýbajúci vlastník projektu na strane firmy	Dodávateľ čaká na rozhodnutia, workshopy nemajú záver	Blokované úlohy, pomalé schvaľovanie, chaos v prioritách	Určiť ownera, kľúčového používateľa a schvaľovací rámec
5	Slabá komunikácia a neriadené zmeny	Požiadavky sú v mailoch, calloch a chate naraz	Rast ceny a termínu po malých dávkach	Zaviesť change log, decision log a jeden zdroj pravdy
6	Megalomanský štart bez fázovania	Prvý release má riešiť priveľa oblastí súčasne	Zložitý testing, rizikové nasadenie, slabá spätná väzba	Rozdeliť projekt na fázy podľa hodnoty a rizika

Ak sa vám pri čítaní tabuľky hodí viac než jeden riadok, je to bežné. Väčšina zlyhaných IT projektov nepadá na jednej chybe, ale na reťazci príčin, ktoré sa navzájom zosilňujú. Najčastejšie ide o kombináciu dvoch až troch problémov, napríklad nejasného cieľa, slabej analýzy a neriadených zmien.

Ako si vybrať správny prvý krok, keď už na projekte vidíte varovné signály?

Správny prvý krok nezávisí od toho, čo vás najviac frustruje, ale od koreňa problému. Ak diagnózu netrafíte, budete riešiť symptómy. Ak trafíte príčinu, často stačí jeden zásah do ownershipu, rozsahu alebo analýzy a projekt sa stabilizuje.

Použite tieto skratky:

• Tím pracuje, ale nikto nevie povedať, čo je úspech: vráťte sa k cieľu, KPI a out of scope.
• Požiadavky sa objavujú až počas vývoja: zastavte rozširovanie backlogu a dopracujte analýzu procesu.
• Projekt mešká ešte pred prvým reálnym výstupom: zmenšite scope prvého release, nie iba tempo tímu.
• Dodávateľ čaká na feedback a rozhodnutia: určte ownera a schvaľovací režim na strane firmy.
• Každé demo otvára nové zásadné témy: zaveďte change log a prioritizačné pravidlá.
• Prvý release má riešiť všetko naraz: rozdeľte projekt na fázy podľa hodnoty a rizika.

Keď je problém hlbší, oplatí sa začať discovery a návrhom riešenia, nie ďalším improvizovaným sprintom. Cieľom nemá byť „rozhýbať projekt za každú cenu“, ale znovu nastaviť architektúru, priority a očakávania tak, aby systém rástol spolu s firmou.

Ak si nie ste istí, ktorá príčina je vo vašom prípade dominantná, v BeCode vám pomôžeme rýchlo oddeliť symptómy od koreňa problému na nezáväznej konzultácii, aby ďalší krok podporil výsledok, nie iba ďalšie míňanie kapacity.

Časté otázky

Pomôže agilný prístup znížiť riziko zlyhania IT projektu?

Áno, ale iba vtedy, keď agile nie je zámienkou na nejasné zadanie. Agilný prístup znižuje riziko skoršou spätnou väzbou, lepšou prioritizáciou a delením projektu na menšie hodnotné kroky. Nezachráni však projekt, ktorý nemá ownera, ciele ani poctivú analýzu.

Zlyhávajú CRM, ERP a e-shop projekty z rovnakých dôvodov?

Vo veľkej miere áno, líši sa najmä miesto, kde sa problém prejaví ako prvý. Pri CRM býva kritická práca s procesom a adoption tímu, pri ERP integrácie a dáta, pri e-shope výkon a zákaznícka cesta. Koreň býva podobný: cieľ, analýza, priority, ownership a riadenie zmien.

Dá sa IT projekt zachrániť, keď už mešká a rozpočet rastie?

Vo väčšine prípadov áno, ak sa najprv zastaví rozširovanie chaosu a až potom pokračuje vývoj. Projekt treba znovu diagnostikovať, určiť cieľ, zmenšiť scope najbližšej fázy, doplniť ownership a upratať rozhodnutia. Najväčšia chyba je predpokladať, že viac práce automaticky napraví zlý smer.