Záchrana projektu – Varovné signály, rizika a strategie zmírnění problémů

70% of all IT projects fail — and in many cases, they don’t have to

‍
Ve společnosti Moravio se služba Project Rescue stala jednou z našich nejúspěšnějších. Příliš často za námi přicházejí klienti s pocitem, že narazili na slepou uličku – rozpočet je vyčerpaný a produkt se ani zdaleka nepodobá původní vizi. Nedokážeme dělat zázraky přes noc a nepracujeme zadarmo, ale dokážeme projekt zanalyzovat, vytvořit strategii, naplánovat kroky a provést jeho obnovu.

Pomohli jsme mnoha klientům nejen dostat jejich projekty zpět na správnou cestu, ale také přepracovat ověřování obchodního záměru (business validation) a definici minimálního životaschopného produktu (MVP scoping). V tomto článku se podíváme na varovné signály, rané i pozdní indikátory problémů, víceúrovňové strategie pro jejich zmírnění a další klíčové aspekty spojené s Project Rescue.

Proč 70 % všech IT projektů selže? 

Mnoho důvodů jsme již popsali v našem dalším článku - Project Rescue – častější, než si myslíte . V tomto článku jsme sdíleli naše zkušenosti, které se velmi shodují s tím, co pozoruje zbytek IT světa.

• 70 % míra neúspěchu

• 80 % organizací uvádí, že tráví alespoň polovinu svého času přepracováváním již hotové práce.

• 44 % projektů selže kvůli nedostatečnému sladění mezi obchodními a projektovými cíli.

• 47 % projektů nesplní své cíle kvůli špatnému řízení požadavků.

 (source 1, source 2)

Co si z toho můžeme vzít? Musíte přesně vědět, co chcete, kolik můžete utratit, musíte mít kontrolu nad průběhem práce a mít dobrý důvod věřit v úspěch projektu. Je nutné hlídat rozšiřování rozsahu projektu (scope creep), pečlivě plánovat a aktivně se zapojit. Nenechávejte rozhodování pouze na projektových manažerech – zainteresované strany musí být naprosto jasné ve svých očekáváních a zapojení.

A samozřejmě, je potřeba vybrat dobrého poskytovatele IT služeb. 

Rané varovné signály

ak poznáte, že projekt není na správné cestě? Jak odhalit problém i tehdy, když je první milník splněn a tým plánuje a dodává to, co bylo slíbeno?

• Zainteresované strany nechtějí dělat POC / MVP a chtějí jít hned naplno. Někdy to nemusí být problém, ale většinou je. Zejména pokud chcete rozumně využít rozpočet.

• Nejasné milníky, projektové řízení se prakticky zabývá jen administrativou. Chybí Product Owner a tým je ponechán sám na sebe. Někdy se to mylně prezentuje jako důvěra, ale není – jde jen o nedostatek znalostí, jak projekt vést. Dobrý poskytovatel IT služeb může nahradit prakticky všechny role, ale musí být aktivně přítomen..

• Příliš mnoho funkcí. Někdy jsou klienti příliš nadšení z toho, co by bylo možné nebo „hezké mít“, a nezaměřují se na nezbytné funkce a jádro produktu

• Šetření na QA. Ve skutečnosti je šetření na čemkoli kromě rozsahu projektu trochu riskantní. V IT totiž neplatí, že drahé je vždy dobré, ale často platí, že levné je problémové

• Nápad není otestován s reálnými uživateli.

Z pohledu klienta – nejběžnější varovné signály, že je čas vše zastavit a projekt znovu přehodnotit.

Rané signály – stále je čas zasáhnout 

• Nejasné, co znamená „hotovo“.
  Chybí jasná definice dokončení, obchodních cílů nebo rozsahu MVP? To je recept na nesoulad

• Neúčastníte se pravidelných revizí nebo demo ukázek.
  Pokud týdny ubíhají, aniž byste viděli testovatelný pokrok, komunikace pravděpodobně selhává

• Dodavatel nikdy neodporuje.
  Tým, který stále říká „ano“, ale nikdy nevyzývá předpoklady, nemusí myslet strategicky

• Nepotvrdili jste nápad s reálnými uživateli.
  Pokud stavíte před testováním – zejména na novém trhu – riskujete čas a peníze

• Soustředíte se na funkce, ne na problémy.
  Pokud je diskuse „co by to mělo dělat?“ místo „jaký problém to má vyřešit?“, priority mohou být špatně nastavené.

• Chybí plán pro spuštění, iterace nebo zpětnou vazbu.
  Přístup „postavme vše hned“ bez roadmapy pro vydání nebo zpětnou vazbu z trhu je skrytý červený praporek..

• Nejasné role a odpovědnosti.
  Pokud není jasné, kdo je za co zodpovědný (Product Owner, Project Manager, Dev Lead), utrpí zodpovědnost i dodání výsledku.

Pozdní signály – situace může být komplikovaná a záchrana je urgentní

• Většina rozpočtu je utracena, ale produkt není použitelný
  Pokud po významné investici neexistuje funkční prototyp nebo demo, jde o kritický problém.

• Termíny byly opakovaně nedodrženy a další bude také.
  Zmeškané milníky bez realistického plánu nápravy signalizují, že projekt je mimo dráhu.

• Nikdo jasně nedokáže vysvětlit, co je hotovo, co je rozbité a co bude dál.
  Nedostatek přehledu o pokroku, překážkách nebo směru naznačuje ztrátu kontroly.

• Nedostatek přehledu o pokroku, překážkách nebo směru naznačuje ztrátu kontroly.
  Vysoká fluktuace, nejasné role a slabá kontinuita indikují nestabilitu a neřízené riziko.

• Požadují se stále další peníze nebo čas bez zvýšené hodnoty.
  Rozšiřování rozsahu a překročení rozpočtu bez jasného ROI signalizuje špatné řízení nebo nepřesné odhady..

• Přestali jste věřit, že produkt bude spuštěn nebo uspěje
  Pokud psychicky „odcházíte“, důvěra se ztratila a záchrana může vyžadovat nové vedení nebo tým

• Bojíte se ukázat produkt uživatelům nebo investorům.
  Pokud ho skrýváte i před testery, problém už není jen technický, ale strategický

Strategie záchrany softwarového projektu 

Když nastane čas (ať už vaším rozhodnutím nebo okolnostmi) a zjistíte, že projekt potřebuje pomoc, bez ohledu na jeho fázi, následuje u Moravia strukturovaný a transparentní proces.

Nejprve je nutné pozastavit vývoj. Může být potřeba nezávislý audit, včetně kontroly kódu a ověření obchodní validity. Výsledkem tohoto procesu je detailní posouzení záchrany projektu. V této fázi je důležité být připraven na nepříjemné zprávy. Naším cílem je vždy navrhnout co nejpraktičtější řešení, s ohledem na vaše cíle, dostupný rozpočet, dokončenou práci a aktuální stav architektury a vývoje. Někdy jsou náklady na opravu příliš vysoké a nejudržitelnější cestou vpřed může být projekt restartovat

Pokud souhlasíte s doporučeným směrem, přistupujeme k vytvoření jasného plánu obnovy. Vaše plná spolupráce a transparentnost jsou zásadní – a z naší zkušenosti jsou klienti v této fázi obvykle připraveni se plně zapojit. Důraz klademe na otevřenou komunikaci, pravidelnou synchronizaci a průběžnou zpětnou vazbu z obou stran.

Během samotného provádění záchrany může být potřeba refaktorovat, přepsat nebo restrukturalizovat části systému. Naplánujeme pravidelné schůzky a budete zapojeni do mnoha rozhodnutí (jak byste ideálně byli od začátku). Můžete si všimnout, že proces vývoje bude nákladnější, než jste zvyklí. Je to proto, že důrazně doporučujeme přítomnost dedikovaného QA, aktivní zapojení projektového manažera nebo product ownera a úroveň komunikace a dohledu, která zajistí, že nic nepřijde nazmar.

Software project rescue strategy 

Závěrečné zamyšlení Moravia

Klienti, kteří byli zklamáni špatnými poskytovateli IT služeb, často nejlépe chápou hodnotu kvalitní práce. Soustředit se pouze na nejnižší cenu je nesmírně rizikové a mnoho z nich se to naučilo tvrdou cestou.

U Moravia neslibujeme zázraky. Slibujeme zkušenosti, transparentnost a strukturovaný, poctivý přístup, který vašemu projektu poskytne druhou šanci, kterou si zaslouží