Miért buknak el az IT projektek? (És hogyan ismerd fel időben)

Ha már belevágtál egy szoftverfejlesztési projektbe, és az eredmény nem az lett, amit vártál, nem vagy egyedül. Az építőipari cégek vezetőivel különösen sokszor találkozunk ezzel a történettel: valaki egyszer megrendelt egy egyedi rendszert (árajánlat-kezelőt, projektnyilvántartót, anyagrendelést), a fejlesztés hónapokig húzódott, a végeredmény pedig félkész maradt, vagy senki nem használja. Mi a Cognivusnál sokszor pont ilyen helyzetben lévő cégekhez érkezünk — nem azért, mert az IT rossz ötlet volt, hanem mert a projekt menete csúszott félre valahol az elején.

Egy tipikus történet egy kivitelező cégnél

Egy 23 fős kivitelező cég ügyvezetője elhatározza, hogy véget vet annak, hogy az árajánlatokat Excelben készítik, a projektstátuszokat WhatsApp-üzenetekben egyeztetik, az anyagrendeléseket pedig telefonon intézik a beszerzővel. Megbíz egy fejlesztőcéget egy egyedi rendszerrel. Az első megbeszélésen minden lelkes: lesz benne projektkövetés, anyagnyilvántartás, ütemezés, minden egy helyen. Fél év múlva a rendszer elkészül — csak épp a projektvezetők nem használják, mert az adatbevitel bonyolultabb, mint amit korábban csináltak, és a mobilon való használat, ami a helyszíni munkához elengedhetetlen lett volna, valahogy kimaradt a végleges verzióból.

A fejlesztőcég hiába volt kompetens és agilis, a projektből mégis elejétől kezdve hiányzott valami, és ez a valami szinte minden elbukott IT-projektnél ugyanaz. Ez nem azért történt, mert a fejlesztőcég inkompetens volt.

A leggyakoribb okok, amiért egy IT-projekt elbukik

Nem a napi munkafolyamatból indultak ki, hanem egy elképzelt, ideális állapotból. Ha a fejlesztés nem azzal kezdődik, hogy pontosan megnézik, hogyan dolgozik ma egy projektvezető a helyszínen, a végeredmény szép lesz papíron, de a gyakorlatban használhatatlan.
Túl nagy volt a lépés egyszerre. Ha az első verzió megpróbál mindent egyszerre megoldani — árajánlat, projektkövetés, anyagrendelés, számlázás —, a fejlesztés elhúzódik, és mire elkészül, már senki nem emlékszik pontosan, mit is akartak eredetileg.
A leendő felhasználókat nem vonták be a folyamatba. Ha a projektvezetők és a beszerzők csak a kész terméket látják meg, nem meglepő, ha az nem passzol a napi munkájukhoz — ők tudják a legjobban, mi működik és mi nem a helyszínen.
Hiányzott a rendszeres visszacsatolás a fejlesztés közben. Ha fél évig senki nem lát semmit, csak a végén derül ki, hogy valami nem stimmel, addigra már késő olcsón korrigálni.
Nem volt egyértelmű, mérhető cél a projekt elején. Ha a cél csak annyi, hogy „legyen egy rendszerünk”, nehéz eldönteni, mikor kész a munka, és mikor sikeres.

Hogyan néz ki, amikor ez jól működik?

Az egyik építőipari ügyfelünknél a projektkövető rendszer fejlesztését azzal kezdtük, hogy egyszerűen csak megfigyeltük, hogyan dolgoznak a projektvezetők a helyszínen — mit írnak fel papírra, mit fényképeznek le, mikor és honnan küldenek üzenetet az irodának. Ebből állt össze az első, szándékosan egyszerű verzió, ami csak a legfájóbb pontot oldotta meg: a helyszíni státuszjelentést egy mobilon is használható felületre vittük át. Ezt két hét után már élesben tesztelték a projektvezetők, és a visszajelzéseik alapján bővítettük tovább a rendszert — anyagrendeléssel, majd ütemezéssel. A teljes folyamat egy nagy ugrás helyett apró, ellenőrizhető lépések sorozata lett.

A tipikus félelmek — és amiért nem kell megijedni tőlük

„Egyszer már belefutottunk egy sikertelen projektbe, nem akarjuk megint.” — Ez érthető, de a hiba jellemzően nem magában az IT-fejlesztésben van, hanem abban, hogyan zajlott a projekt. Egy jól strukturált, kis lépésekben haladó folyamat kockázata sokkal kisebb.
„Nincs időnk aktívan részt venni benne, csak szeretnénk, ha megoldanák.” — Pont ez az a hozzáállás, ami a legtöbb bukott projekt mögött áll. Nem kell sok időt rászánni — de a felhasználók (a projektvezetők, a beszerzők) rövid, rendszeres visszajelzése nélkül a fejlesztés vakon halad.
„Ez biztos drágább lesz, mint amit terveztünk.” — Egy szakaszolt, kis lépésekben haladó fejlesztés pont azért olcsóbb hosszú távon, mert időben kiderül, ha valami rossz irányba megy, mielőtt sokba kerülne a javítás.
„A csapatunk amúgy is ellenáll az új rendszereknek.” — Ha a felhasználók a fejlesztés részesei, nem csak a végén szembesülnek a kész termékkel, az ellenállás jellemzően minimálisra csökken — hiszen olyat kapnak, amit ők maguk formáltak.

A tanulság

Az IT-projektek nem attól buknak el, hogy az adott technológia rossz, hanem attól, ahogyan a projektet felépítik. A kulcs nem a nagy, mindent megoldó tervben van, hanem abban, hogy kis, tesztelhető lépésekben haladva, a tényleges felhasználók bevonásával épül fel a rendszer.