1986 januárjában következett be a NASA történetének egyik legsúlyosabb katasztrófája. A Space Shuttle Challenger a start után 73 másodperccel megsemmisült. A későbbi vizsgálatok megállapították, nem egy látványos technológiai kudarc okozta a tragédiát, hanem egy ismert, dokumentált, ám félresöpört probléma: a szilárd hajtóanyag-gyorsítók ún. O-gyűrűinek a működési hatékonysága alacsony hőmérsékleten jelentősen romlott.

Az O-gyűrű valóban nem volt hibátlan alkatrész. A katasztrófa eredendő oka mégsem ez volt, hanem az, hogy a döntéshozatali folyamatban a projekt résztvevői nem hallották meg egymást, vagy másképpen fogalmazva: a kritikus figyelmeztetések elvesztek a szervezeti zajban.

Ez az alapvető hiba azóta is kísért – ha nem is az űriparban, annál inkább az IT-projektekben.

Egy sokszor újrakezdett nagyvállalati projekt

Példa történetünk egy nagyvállalatnál játszódik. A vezetőség döntött egy olyan stratégiai jelentőségű rendszer bevezetéséről, amely egy évek óta átfogó szoftveres támogatás nélkül működtetett kulcsfolyamatot tenne hatékonyabbá. A projekt többször leállt, de mivel a vezetőség fontosnak ítélte, mindig újraindították. Beszállítók jöttek-mentek, halomban álltak a félkész dokumentumok, mementói a rengeteg elodázott döntésnek.

Az utolsó bevezetési kísérlet is hasonlóan alakult. Az igények, a szállított megoldás és a beszállító működése köszönőviszonyban sem volt egymással. Kritikus üzleti helyzetek maradtak lefedetlenek, a követelménydokumentáció egy torzó volt – ám mindenki "haladt tovább".

Tanácsadók érkeztek, elvégeztek egy auditot, majd javaslatukra és felügyeletükkel megkezdődött a projekt újraépítése, most már agilis irányból:

– egyszerűsítették a csapatot;
– megszüntették a párhuzamos státuszokat és fórumokat; 
– a feladatokat egy kollaborációs platformra terelték, amitől olyan, évek óta függőben lévő feladatok gyors lezárását remélték, mint a dokumentáció elkészülte;
– a feladatokat iterációkba rendezték...

Ilyen helyzetben érkezik egy külső, szerződéses projektmenedzser, akinek hamarosan azzal kell szembesülnie, hogy egy klasszikus "mentőprojekt" kellős közepébe csöppent.

Amikor nem a megoldás a cél, hanem a konfliktus

Hiába jött új ember, hiába történt meg az “agilis átállás”, ez csak ideig-óráig működött, ugyanis alapvető konfliktusforrások maradtak a rendszerben. A felgyülelmett problémák egy tesztelésre szánt release átadása kapcsán törtek a felszínre. Egy megrendelői oldalon dolgozó kulcsszereplő viselkedése látványosan megváltozott. Ez a fókuszt is áthelyezte: a projekt lezárása helyett hirtelen a beszállítóval korábban lezáratlan konfliktusok újranyitása került előtérbe.

Ennek a napi munkában is látványos jelei voltak: az egyeztetések egyre gyakrabban torkolltak indulatos személyeskedésbe, előkerültek régi sérelmek és így tovább. Ez nem azt jelentette, hogy a kulkcsszereplő nyíltan blokkolta a projektet, hanem csupán bomlasztó mellékzajként volt jelen. Egy olyan állandó zavaró tényezőként, amely lassan, de biztosan szívta el az energiát a csapattól.

Mit tehet ilyenkor a projektvezető? Ha van rá lehetősége, beavatkozik. De valóban van? Történetünk projektvezetője pontosan tudta: szerződésesként formálisan nincs joga erőforrást "lecseréltetni". A szituációt bonyolította, hogy a problémás kolléga szakmai kvalitásait mindenki elismerte, szinte a kezdetektől részese volt a projektnek, amikor szükség volt rá, mindig ott volt a "tűzvonalban".

A projektmenedzser fejében azonban megszólalt a vészcsengő: ha nem lép, törés lesz, azaz elérkezett a projekt O-gyűrű pillanata.

Felhatalmazás papírok nélkül

Ilyen esetben az első lépés mindig a közvetlen visszajelzés: a projektvezető valahogy a munkatárs tudomására hozza, hogy hozzáállása nem járul hozzá a projekt sikerességéhez. De mi a megoldás akkor, ha a történetünkben szereplő kolléga nem érezi problémásnak saját szerepét?

A második lépés, hogy be kell vonni a közvetlen felettesét. Hármasban kell újraosztaniuk a projektben betöltött szerepeket, és olyan kompromisszumos megoldást találni, ami remélhetőleg hosszú távon működőképes. Ehhez azonban mindenkinek engednie kell. Jelen esetben például megoldás, ha a kolléga hivatalosan a projekt részese maradt, de kivonják a kritikus munkafolyamatból, azaz döntéshozó pozícióból támogató szerepbe kerül. Így a kecske is jóllakik, azaz szakértelmét be lehet csatornázni a projektbe, és a káposzta is megmarad, azaz nem akad el a projekt.

Nincs szükség látványos konfliktushelyzetekre, célt lehet érni az emberi viszonyokba történő finom, tervezett beavatkozással is.

Az O-gyűrűk nem mindig technikai problémák

Történetünk projektje haladt tehát a tervek szerint. A tesztelési fázis alatt ugyan lábra keltek mindenféle folyosói pletykák arról, hogy a rendszer élesítés után két hetet sem él meg. "Nem lett jól összerakva semmi", mert a projektvezető saját sikerét helyezte a megrendelő érdeke elé.

A rendszer azonban végül megérte az élesítést. Nem omlott össze. Ilyenkor nem kell arra számítani, hogy a projekt sikersztori lesz, bőven elég az az öröm, hogy a rendszer kielégítően működik, és nem jegyzik a vállalati rémtörténet-gyűjteményében sem.

És a tanulság? Ahogy a Challenger esetében, itt is beigazolódott: a problémák gyakran nem technikai, hanem szervezeti okokra vezethetők vissza. Azaz a kritikus kockázat sokszor nem ott van, ahol a hibajegyek, hanem a projekt kulcsszereplőinél. Ezt a projektmenedzsernek kell kezelnie. Ha szükséges, személyi kérdésekben nagyobb felhatalmazást kell adnia magának, mint amit a szerződése rögzít. Az apró gesztusokra is figyelnie kell, mert a projektek O-gyűrűi ritkán látványosak.

De ha figyelmen kívül hagyjuk őket, a következő törés csak idő kérdése.
 

_{(Illusztráció: Wikipedia)}