Mért buknak el (majdnem) mindig a transzformációs projektek?
Rések a falon
Rések a falon
A valóság sokszor szürke, unalmas, és nem vág össze a terveinkkel. Mennyivel szebb akkor a magunk teremtette álomvilág, ahol minden a vágyaink szerint alakul, minden szép és jó! Az álomvilág szertefoszlása azonban mindig fájdalmas – különösen, ha egy nagy projektet építettünk erre a légvárra.
Előző bejegyzésünkben írtunk már arról, hogy miért csúsznak gyakran félre a nagy transzformációs projektek. A legfontosabb okok között említettük a hamis optimizmust, ami rózsaszín ködöt von a projekt megálmodójának szeme elé, bár talán pontosabb lenne azt mondani, hogy az érintettek gyakran maguk teszik a fejükre a rózsaszín szemüveget, és sokszor akkor is kapaszkodnak belé amikor az intő jelek sorakoznak… Ez addig folytatható, amíg meg nem érkezik a kőkemény realitás, és észre nem veszik, hogy a szépen felépített konstrukción bizony rések, repedések vannak. Mire ide eljutnak, már túl vannak jó néhány olyan körön, ahol nem vették figyelembe a vágyaik/elképzeléseik/ígéreteik/terveik és a valóság közötti különbségeket. Nézzük meg most közelebbről ezeket a különbségeket, amelyek előbb-utóbb tátongó réseket ütnek a projekt szilárdra tervezett és szilárdnak hitt alapján!
1. Rés: a nézőpontok szintkülönbsége: A nagy projektek ötlete sokszor valamelyik üzleti terület vezetőjétől származik. Ő a saját (és csapata) bőrén érzi, hogy milyen problémák vannak, és ezeket mindenképpen szeretné orvosolni. A csapatával részletesen kitalálja, hogy mit kellene megvalósítani – de a menedzsmentnek csak úgy tudja eladni, ha egyszerűsít rajta. Sőt, ahogy a múltkori bejegyzésben kifejtettük, néha még kozmetikázni is kell a számokat, hogy a menedzsment is belássa hogy mennyire szükséges a változtatás. Emiatt, ha a menedzsment áldását is adja a projektre, egészen más, óhatatlanul leegyszerűsített kép fog élni a fejekben az egész problémahalmazról és a megoldási tervekről.
2. Rés: az üzleti és az informatikai nézőpontok különbsége: Gyakorlatilag minden projekten együtt kell dolgoznia egy vagy több üzleti területnek és a vállalati informatikának. Ők békeidőben, a napi működés során sem feltétlenül értik meg egymást, de egy-egy új fejlesztésnél hatványozottabban megnő a nem tisztázott részletmegoldások és félreértések kockázata. Az üzlet elmondja saját értése szerint a problémát és az elvárt megoldást, az IT érti, de nem feltétlenül részleteiben ugyanazt, mindenki azt hiszi, hogy egyetértés van. A mindennapi munka mellett is vannak ilyen eltérések, láthatóan szükség van üzleti elemzőkre, hogy ezeket a néha kisebb, néha nagyobb eltéréseket csökkentsük. Ehhez járul még, hogy a napi munka és futó projektek mellette kell részt venni a nagyobb projekt v. program előkészítési feladatokban. Ezeknek ebben a fázisban a megvalósulási időtávja sem látszik, nyilván ezen van a legkevesebb figyelem és közös értésre törekvés, hisz „hol van az még”.
3. Rés: a céges és a szállítói nézet különbsége: Zöld utat kapott a projekt, írjuk ki a tendert! Igen ám, de a szállító, rendszerintegrátor kiválasztására a vezetői elvárások alapján írják ki a tendert, annak megfelelően határozzák meg a scope-ot, a büdzsét, a szükséges erőforrásokat, a határidőt, mindent. Csakhogy, mint láttuk, ez a vezetői nézet szükségszerűen elnagyoltabb, mint ahogy a projekt eredeti megálmodói elképzelték. A szállító azonban nem ismeri az eredeti elképzeléseket, ő a vezetői elváráshalmaz alapján tervezi meg a rendszert és fordítja le az igényeket saját megoldásaira. És itt jön szintén képbe az előző pontban is írt információ torzulás másik esete. Hiszen a szállítóknál is okos, kreatív szakemberek ülnek, akik az elnagyolt igények alapján, saját termékeik ismeretében gondolnak bele olyan részleteket az ajánlatba, amik nincsenek leírva, és élnek saját feltételezéseikkel, mert ez még csak ajánlati szakasz és „minden részletet nem lehet kibontani”.
4. Rés: a bevállalt és a leszállított rendszer közötti különbség: A tender elnyerése érdekében, a szállító mindent is megígér, csillámos csomagolópapírban, színes szalaggal átkötve adja majd át a teljesen integrált, kulcsrakész rendszert. Igen ám, de a tenderkiírásban szereplő elvárások nem mindegyikének tud maradéktalanul megfelelni, még ha akar is. Itt egy kicsit módosít, ott helyettesít egy komponenst egy másikkal, amott belefejleszt – jó esetben (de tényleg jó esetben!) az eredmény 90 százalékban megfelel az eredeti tenderkiírásnak. Még rosszabb a helyzet, ha nem egyetlen szállítóval, hanem egy konzorciummal kell szerződni, ahol mindenki más-más komponensért felel. Ebben az esetben az egyes szereplők feladat megértési szintje, a közös megoldás tervezettsége, az előre nem látott integrációs problémák (akár rendszer, akár folyamat) mind növelik a rést.
5. Rés: az eredeti elvárások és a leszállított rendszer közötti különbség: Hurrá, elkészült a megoldás, leszállítják az ügyfélnek tesztelésre. Ott jó esetben a projekt megálmodói, a szakterület átveszi. Ekkor mutatkozik meg igazán, hogy milyen különbségek voltak a feladat kiírása, a kinyilvánított felsővezetői elvárások, és az eredeti elképzelések között, főleg, hogy ezek az eredeti elképzelések kicsit átalakulnak, fejlődnek, így az elvárt eredmény képe is módosul, sokszor függetlenül a projekt lefolyásától. És itt jön a legnagyobb rés, hogy … „én nem ilyen lovat akartam!” Nagyon szép, amit hoztatok, de nem erre gondoltunk, nem erre van szükségünk. Minél nagyobb, minél bonyolultabb egy projekt, annál elementárisabb erejű lesz a rácsodálkozás, az aha!-élmény. Ám ilyenkor már a legritkább esetben lehet azt mondani, hogy vigyétek vissza, és csináljátok meg úgy, ahogy mi szeretnénk. Ami lehetőségként megmarad, az a próbálkozás a projekt faragásával: alulról próbálják beleerőltetni a kimaradt funkciókat, felülről nyomják az egyszerűséget, a gyorsaságot, míg végül születik egy olyan öszvér, ami többe kerül, mint amit a vezetés szeretett volna és kevesebbet tud, mint amit az üzleti terület elvárt, esetleg még az üzemeltethetőség szintjén is generál többlet költséget.
6. Rés: a szervezeti változásokból fakadó különbség: Egy transzformációs projekt rendszerint több évig is eltart, és nem ritka, hogy több projektgazdát is elfogyaszt. Az első (de legkésőbb a második) nagyobb csúszás után távozik a vezető, akitől az egész ötlet eredt, nem egyszer megy vele több kulcsember is. Távozik velük az a koncepció, szellemiség is, ami a projekt megszületését lehetővé, a sikerét pedig kívánatossá tette. Jön egy új garnitúra, amelyik csak megörökli a problémás projektet, de szívügyének
semmiképpen nem érzi. Az új vezető a leírt információkból tájékozódik, más szemszögből, más előzetes tudással szemléli a problémát és nagy valószínűséggel a megoldásról is mások az elképzelései. És miközben nem ő fogalmazta meg az eredeti követelményeket, a kész rendszert neki kell átvennie.
7. Rés: az igények változásából fakadó különbségek: Az a pár év, amíg a transzformációs projekt zajlik, rendkívül hosszú idő a mai üzleti környezetben, még ha nem is tör ki egy világjárvány közben. Változik a piac, változnak az ügyfelek elvárásai, új üzleti modellek tűnnek fel a színen, megerősödnek bizonyos vetélytársak, átalakul a szabályozói környezet – a sort mindenki tudja folytatni. Akár erre válaszul, akár csak a normál üzletmenet részeként, változnak a belső folyamatok és igények is. Egy ideális világban folyamatosan hozzáigazítanák a változásokhoz a projekt céljait, scope-ját, de csak Pangloss mester szerint élünk minden világok legjobbikában… Olyan projektet még nem láttunk, ahol lett volna (előre elkülönített) pénz, szakértelem, erőforrás, idő és nem utolsósorban szándék a tervek rendszeres és teljes körű felülvizsgálatára és kiigazítására (olyan mértékben ahogy arra szükség lett volna). Summa summarum: mire a rendszert bevezetik, valamilyen mértékben óhatatlanul elavult lesz, mert az élet
túllépett, vagy módosította az eredeti problémát.
8. Rés: a technológia változásaiból fakadó különbségek: Ha az üzleti életben soknak számít 3-4 év, az informatikában már felér egy emberöltővel. Elkezdik a fejlesztést egy adott operációs rendszerrel, architektúrával, és mire a cél közelébe jutnak, már a célnak sokkal jobban megfelelő, esetleg olcsóbb/biztonságosabb/rugalmasabb technológiai lehetőségek is rendelkezésre állnak. De három év fejlesztését nem lehet egy mozdulattal a kukába dobni, hogy az egészet újra kezdjék az időközben elérhető modernebb technológiai alapokon… Elég ha csak a felhő technológiák, vagy a konténerizáció villámgyors térhódítására gondolunk.
Nyolc különbség az elvárások és a realitás között. Ezek egyenként is tátongó rést képesek ütni a projekt elsőre masszívnak tűnő falán, együttes hatásukra pedig az egész építmény romba dőlhet, maga alá temetve sokakat, akik az építésében részt vettek.
Valószínűleg keletkez(het)nek más rések is a projektek falán.
Te milyeneket tapasztaltál és milyen módszerekkel próbáltad azokat betömködni? Néhány módszerről mi is szólunk majd a következő bejegyzésben.
