Nejčastější důvody selhání IT projektu a jak je poznat včas

Jak jsme vybrali pořadí důvodů selhání IT projektu?

Pořadí jsme neurčili podle dojmu, ale podle toho, co v praxi nejčastěji poškodí hodnotu projektu: nejprve byznysový cíl, pak analýza, plán, lidé, komunikace a nakonec způsob nasazení. Výš jsme zařadili faktory, které dokážou projekt pokazit dřív a s dražším dopadem.

U pořadí jsme pracovali se 4 kritérii:

1. Jak brzy problém zničí hodnotu projektu – zda změní směr ještě před vývojem, nebo se projeví až během nasazení.
2. Jaký má dopad na rozpočet a termín – zda způsobí menší tření, nebo rozsáhlé přepracování.
3. Jak často se projevuje ve firemních IT projektech – zejména u CRM, interních systémů, webových aplikací a automatizací.
4. Jak snadno se dá vrátit zpět – zda stačí jedno rozhodnutí, nebo je potřeba přepsat backlog, architekturu a procesy.

Proto jsou na prvních místech strategie a analýza, ne technologie. Když firma přesně neví, jaký výsledek očekává, nebo požadavky popíše jen povrchně, ani kvalitní tým nedokáže dodat správný systém. S rostoucí komplexitou riziko výrazně stoupá. PMI uvádí, že 97 % profesionálů řídilo za poslední rok alespoň jeden komplexní projekt, přibližně třetina komplexních projektů nedosáhne původně zamýšlených cílů a týmy, které komplexitu zvládají efektivně, zvyšují pravděpodobnost úspěchu 5násobně.

Tento žebříček proto nesleduje jen chyby projektového managementu. Zahrnuje i chyby na straně vedení firmy, ownershipu, priorit a rozhodování, protože právě tyto oblasti u IT projektů určují, zda se vyvíjí užitečný nástroj, nebo jen nákladný seznam funkcí.

Proč jsou nejasné cíle a neměřitelný výsledek důvod číslo 1?

Důvod číslo 1 je nejasný cíl, protože ovlivní všechno ostatní ještě před první vývojovou úlohou. Pokud tým neví, co má projekt změnit v byznysu, neumí správně rozhodovat o rozsahu, prioritách ani architektuře. Výsledkem bývá software, který technicky funguje, ale nepřináší očekávaný výsledek.

Nejtypičtějším symptomem je, že každý stakeholder popisuje úspěch projektu jinak. Obchod očekává více leadů, provoz méně ruční práce, management reporting a uživatel rychlejší schvalování. Všechno může být oprávněné, ale pokud z toho nevznikne jedna společná definice výsledku, backlog se změní v kompromis bez jasného směru.

V praxi doporučujeme před analýzou pojmenovat 3 věci:

• jeden hlavní byznysový cíl, například zkrátit schvalování objednávek,
• tři měřitelné ukazatele úspěchu, například čas zpracování, chybovost, počet ručních kroků,
• jasné out of scope, tedy co tento release neřeší.

U projektů jako CRM na míru je to základ, protože bez definice výsledku se z CRM rychle stane jen sklad kontaktů, ne nástroj, který řídí obchodní proces. Pokud tedy ve vašem týmu zaznívá věta „uvidíme během vývoje“, problém velmi pravděpodobně nezačíná v kódu, ale v nejasném cíli.

Proč je povrchní analýza požadavků a procesů důvod číslo 2?

Důvod číslo 2 je povrchní analýza, protože vytváří nákladný typ chyby: projekt určitou dobu působí zdravě, ale po prvních demech se ukáže, že systém neodráží reálný provoz firmy. Tehdy už nejde o malé úpravy, ale o přepracování workflow, rolí, integrací a dat.

Firmy často popíší jen ideální proces. Vynechají výjimky, schvalovací pravidla, duplicity v datech, exporty do účetnictví, propojení na e-shop, práva uživatelů nebo situace, kdy zákazník udělá něco nestandardního. Právě tyto detaily rozhodují, zda systém práci zjednoduší, nebo ji ještě více zkomplikuje.

Dobrá analýza požadavků proto nemá sbírat jen seznam funkcí. Má rozebrat:

• kdo dělá který krok,
• odkud přicházejí data,
• co spouští výjimky a schvalování,
• které integrace jsou kritické,
• podle čeho se bude výstup přebírat.

U vývoje na míru je to rozdíl mezi systémem, který respektuje reálné procesy firmy, a systémem, který firmu nutí obcházet vlastní pravidla. Stejně to platí u automatizačních řešení: pokud neznáte přesný tok dat a výjimek, neautomatizujete proces, jen přesouváte chaos do nového nástroje.

Pokud se zásadní požadavky objeví až po prvním prototypu, projekt pravděpodobně netrpí slabým vývojem, ale slabou analýzou.

Jak se nerealistický rozsah, termín a rozpočet stávají důvodem číslo 3?

Důvod číslo 3 je nerealistický plán, protože i dobrý projekt dokáže změnit v sérii nouzových kompromisů. Když je rozsah příliš široký, termín příliš pevný a rozpočet příliš těsný, tým nezačne dělat lepší rozhodnutí. Začne zkracovat analýzu, testování, dokumentaci a kvalitu.

Typický scénář vypadá takto: firma chce v jednom release spustit nový CRM workflow, reporting, mobilní přístup, několik integrací, migraci historických dat i nový zákaznický portál. Na papíře to působí efektivně, v realitě se však hromadí závislost na závislosti. Stačí jedno zpoždění a padá celý plán.

Nejspolehlivější korekce není „pracovat rychleji“, ale zmenšit první cíl. V prvním release by měl zůstat jen takový rozsah projektu, který:

1. řeší jeden hlavní proces end to end,
2. dá se otestovat na reálných uživatelích,
3. přináší měřitelný výsledek,
4. nevytváří technický dluh jen proto, aby se stihl termín.

Pokud je v projektu všechno kritické, ve skutečnosti není prioritizováno nic. Pokud se plán rozpadá ještě před prvním funkčním výstupem, problém nebývá disciplína týmu, ale špatný odhad rozsahu vůči času a kapacitám.

Proč je chybějící vlastník projektu na straně firmy důvod číslo 4?

Důvod číslo 4 je slabý ownership, protože bez člověka na straně firmy, který projekt vlastní, rozhoduje a propojuje byznys s implementací, začne projekt stát i při silném dodavateli. Bez této role se neuzavírají priority, schvalování se vleče a tým čeká na odpovědi.

Nejčastěji se to projeví tak, že na workshopu jsou lidé, kteří umí popsat problém, ale nemají mandát rozhodnout. Nebo naopak rozhoduje management, který proces nevidí v každodenní realitě. Výsledek je stejný: backlog se mění, ale projekt se neposouvá.

Projekt potřebuje minimálně tyto role na straně klienta:

• vlastníka cíle, který určí prioritu,
• klíčového uživatele, který zná proces v detailech,
• člověka pro data a integrace, pokud systém sahá do více nástrojů,
• schvalovatele rozhodnutí, aby se změny nehromadily v inboxu týdny.

Nejde jen o soukromou zkušenost dodavatelů. MIRRI SR mezi 5 principů řízení IT projektů výslovně uvádí dostatečné interní odborné kapacity, vyjmenovává klíčové projektové role a u národních projektů počítá minimálně s 15 % rozpočtu na interní kapacity pro návrh, řízení a předání do provozu.

Pokud tedy dodavatel pravidelně čeká na vstupy, není to administrativní detail. Je to jeden z hlavních důvodů, proč se IT projekt rozpadá zevnitř.

Jak se slabá komunikace a neřízené změny mění v důvod číslo 5?

Důvod číslo 5 je slabá komunikace, protože projekt neničí jedním velkým incidentem, ale průběžným rozcházením reality. Málokdy je prvotní příčinou, ale velmi často urychlí pád projektu, který už trpí nejasným cílem, slabou analýzou nebo slabým ownershipem.

Problém nebývá v tom, že tým má málo meetingů. Problém je, že neexistuje jeden zdroj pravdy. Požadavky jsou zčásti v mailech, zčásti v chatu, část zůstane řečená na callu a část se „nějak dorozumí“ během vývoje. Po 2 týdnech už nikdo neví, co bylo schváleno, co je jen návrh a co je nový nápad.

Nejvíc pomáhají 4 jednoduchá pravidla:

• každé rozhodnutí má majitele a datum,
• každá změna rozsahu jde do change logu,
• každá priorita má jednoho schvalovatele,
• každé demo končí jasným seznamem dalších kroků.

Pokud se po každé prezentaci otevřou zcela nová témata, pokud si obchod s provozem odporují a pokud tým poslouchá 3 různé verze zadání, komunikační problém už není měkká dovednost. Je to přímý důvod růstu ceny, termínu i frustrace.

Proč je megalomanský start bez fázování důvod číslo 6?

Důvod číslo 6 je příliš velký start, protože naráz zvyšuje riziko ve všech ostatních oblastech. Čím více modulů, integrací, týmů a očekávání vložíte do prvního release, tím hůř se projekt testuje, schvaluje, koriguje i nasazuje. Big bang přístup často jen odkládá zpětnou vazbu.

Tento vzorec se opakuje i v odborné literatuře. Podle studie na ResearchGate bývají mnohé e-commerce projekty „příliš komplexní a megalomanské“, aby se daly rozumně zavést do praxe. Stejný mechanismus vidíme i u interních systémů, CRM či automatizací.

Lepší přístup je fázování projektu podle hodnoty a rizika:

1. nejprve spustit proces, který přinese výsledek nejdřív,
2. pak doplnit integrace s nejvyšším dopadem,
3. a teprve následně rozšiřovat reporting, automatizace a doplňkové role.

Pokud si firma nedokáže představit první release bez deseti „nutných“ oblastí, je to spíš signál slabé prioritizace než reálné potřeby. Pro inspiraci, jak pomáhá postupné doručování, mají smysl i ukázky realizací, kde je dobře vidět, že funkční systém nemusí vzniknout naráz.

Jak se tyto důvody porovnávají v jedné tabulce?

Nejrychleji se v příčinách zorientujete porovnáním podle časných signálů, typického dopadu a prvního zásahu. Díky tomu uvidíte, zda váš projekt selhává spíš na strategii, analýze, kapacitách nebo způsobu doručování. Tabulka slouží jako rychlá diagnostika pro vedení i projektový tým.

Pořadí	Důvod	Jak ho poznáte brzy	Typický dopad	První rozumný zásah
1	Nejasné cíle a neměřitelný výsledek	Každý definuje úspěch jinak, chybí out of scope	Projekt doručí funkce, ne výsledek	Sjednotit 1 cíl, 3 KPI a ownera
2	Povrchní analýza požadavků a procesů	Výjimky, data a integrace se objevují až během vývoje	Drahé přepracování workflow a logiky	Dopsat procesy, role, edge cases a akceptační kritéria
3	Nerealistický rozsah, termín a rozpočet	Všechno je priorita, plán je natlačený bez rezervy	Zkrácené testování, technický dluh, zpoždění	Zmenšit první release na jeden hlavní proces
4	Chybějící vlastník projektu na straně firmy	Dodavatel čeká na rozhodnutí, workshopy nemají závěr	Blokované úlohy, pomalé schvalování, chaos v prioritách	Určit ownera, klíčového uživatele a schvalovací rámec
5	Slabá komunikace a neřízené změny	Požadavky jsou v mailech, callech a chatu naráz	Růst ceny a termínu po malých dávkách	Zavést change log, decision log a jeden zdroj pravdy
6	Megalomanský start bez fázování	První release má řešit příliš mnoho oblastí současně	Složitý testing, rizikové nasazení, slabá zpětná vazba	Rozdělit projekt na fáze podle hodnoty a rizika

Pokud se vám při čtení tabulky hodí víc než jeden řádek, je to běžné. Většina selhaných IT projektů nepadá na jedné chybě, ale na řetězci příčin, které se navzájem zesilují. Nejčastěji jde o kombinaci dvou až tří problémů, například nejasného cíle, slabé analýzy a neřízených změn.

Jak si vybrat správný první krok, když už na projektu vidíte varovné signály?

Správný první krok nezávisí na tom, co vás nejvíc frustruje, ale na kořenu problému. Pokud diagnózu netrefíte, budete řešit symptomy. Pokud trefíte příčinu, často stačí jeden zásah do ownershipu, rozsahu nebo analýzy a projekt se stabilizuje.

Použijte tyto zkratky:

• Tým pracuje, ale nikdo neumí říct, co je úspěch: vraťte se k cíli, KPI a out of scope.
• Požadavky se objevují až během vývoje: zastavte rozšiřování backlogu a dopracujte analýzu procesu.
• Projekt se zpožďuje ještě před prvním reálným výstupem: zmenšete scope prvního release, ne jen tempo týmu.
• Dodavatel čeká na feedback a rozhodnutí: určete ownera a schvalovací režim na straně firmy.
• Každé demo otevírá nová zásadní témata: zaveďte change log a prioritizační pravidla.
• První release má řešit všechno naráz: rozdělte projekt na fáze podle hodnoty a rizika.

Když je problém hlubší, vyplatí se začít discovery a návrhem řešení, ne dalším improvizovaným sprintem. Cílem nemá být „rozhýbat projekt za každou cenu“, ale znovu nastavit architekturu, priority a očekávání tak, aby systém rostl spolu s firmou.

Pokud si nejste jistí, která příčina je ve vašem případě dominantní, v BeCode vám pomůžeme rychle oddělit symptomy od kořene problému na nezávazné konzultaci, aby další krok podpořil výsledek, ne jen další utrácení kapacity.

Časté otázky

Pomůže agilní přístup snížit riziko selhání IT projektu?

Ano, ale jen tehdy, když agile není záminkou pro nejasné zadání. Agilní přístup snižuje riziko dřívější zpětnou vazbou, lepší prioritizací a dělením projektu na menší hodnotné kroky. Nezachrání však projekt, který nemá ownera, cíle ani poctivou analýzu.

Selhávají CRM, ERP a e-shop projekty ze stejných důvodů?

Ve velké míře ano, liší se hlavně místo, kde se problém projeví jako první. U CRM bývá kritická práce s procesem a adopce týmu, u ERP integrace a data, u e-shopu výkon a zákaznická cesta. Kořen bývá podobný: cíl, analýza, priority, ownership a řízení změn.

Dá se IT projekt zachránit, když už se zpožďuje a rozpočet roste?

Ve většině případů ano, pokud se nejprve zastaví rozšiřování chaosu a teprve potom pokračuje vývoj. Projekt je třeba znovu diagnostikovat, určit cíl, zmenšit scope nejbližší fáze, doplnit ownership a uklidit rozhodnutí. Největší chybou je předpokládat, že více práce automaticky napraví špatný směr.