Projekt kockázatok

Projekt kockázatok

Tegnap láttam egy tudósítást a híradóban, ami ráirányítja a figyelmet az IT projekt kockázatkezelésének fontosságára.

Január 1-től megváltozott az anyakönyvezetés rendszere, ezért azok a szülők, akik nem házasok és nem is élnek regisztrált élettársi kapcsolatban, a korábbiaktól eltérő módon igazolhatják az apaságot és anyakönyveztethetik a gyereküket. Az új jogszabályhoz azonban nem készült el időben az informatikai rendszer, ezért a szülők nem tudják anyakönyveztetni a gyereket, így addig nem vehetik igénybe a támogatásokat, szülési szabadságot. Bővebben az esetről a következő linken: http://www.rtlhirek.hu/cikk/302029

A kockázatok kezelése érdekében első lépésként fel kell mérnünk a potenciális fenyegetéseket, bekövetkezési valószínűségüket, és azok várható hatását. A bekövetkezési valószínűséget százalékban mérhetjük, a hatás nagyságát pedig általában valamilyen előre meghatározott skálán becsüljük. Ha a médiában cikkeznek egy projekt sikertelenségéről ezen a skálán elég magasra szokták értékelni.

A kockázat súlyosságát a bekövetkezési valószínűség és a várható hatás szorzata adja meg. A kockázatokhoz kezelési terveket készítünk. A kezelési tervek a kockázat súlyosságának csökkentését célozzák, ez elérhető egyrészt a bekövetkezési valószínűség csökkentésével, másrészt a várható hatás csökkentésével. Sosem lehet azonban minden kockázatot teljesen megszüntetni, mindig lesznek maradék kockázatok.

Kicsit hasonló ez a projekt portfólió menedzsmenthez, hiszen a kockázatkezelés nyilván plusz költséggel jár, arra kell tehát törekednünk, hogy megfelelően mérjük fel a potenciális kockázatokat, a súlyosságuknak megfelelően priorizáljuk azokat, és a prioritásaik mentén döntsük el, hogy figyelembe véve a lehetőségeinket, mely kockázatok kezelésére fordítjuk szűkös erőforrásainkat.

A cél az, hogy a maradék kockázatok súlyossága a kockázattűrő képességünket ne haladja meg. Véleményem szerint, ha egy projekt sikertelensgéről és annak következményeiről az esti híradóban hallunk, az nem tekinthető elfogadható maradék kockázatnak, itt tehát valószínűleg érdemes lett volna valamilyen módon csökkenteni ennek súlyosságát.

Nézzük meg milyen terveket lehetet volna kidolgozni jelen esetben:

A fejlesztő IT cég szempontjából:

• Elképzelhető, hogy már a szerződéskötés pillanatában látszik, hogy a fejlesztést nem lehet határidőre elkészíteni. Ebben az esetben lehet, hogy jobb nem elvállalni a feladatot, hiszen a médiában megjelenő hírek jelentősen rontják a fejlesztő jó hírét, ezzel súlyos károkat okozva. (Bár jelen esetben nem nevezték még meg a fejlesztőt)
• Agilis fejlesztési módszertan alkalmazása. Az agilis módszertanok többek között abban segítettek volna, hogy a határidőt szentnek és sérthetetlennek tartva inkább a nem annyira lényeges követelményekből engedve a rendszer biztosan üzembe helyezhető lett volna a kitűzött határidőben. Bizonyos kényelmi funkciókat aztán meg lehetett volna valósítani a későbbiek során is.
• ...

Fentiek a bekövetkezési valószínűséget képesek csökkenteni jelen esetben. A fejlesztő IT cég persze nem tud tenni semmit, ha még csak most kötnek vele szerződést, és így ezután kezdi csak a munkát. Kockázat kezelésre tehát a megrendelő oldalán is szükség van:

• A kockázat bekövetkezése esetén a hatás nagyságát tudja csökkenteni a megrendelő azzal, hogy felkészül arra az esetre, ha az IT rendszert nem lehet üzembe helyezni határidőre. Ebben az esetben is végre kell tudni hajtani a legfontosabb üzleti/ügyviteli folyamatokat, ehhez pedig üzletmenet folytonossági terv szükséges, ami megmondja, hogy hogyan lehet papíron, kézi munkával kiállítani a szükséges igazolásokat. Ez nyilván lassabban és kevésbé hatékonyan fog működni, de a családok legalább megkaphatják a nekik járó támogatásokat, és az eset valószínűleg nem kerül be a híradóba. (Az üzletmenet folytonossági terv a későbbiekben is jól fog jönni, ha az informatikai rendszer valamilyen okból kifolyólag működésképtelenné válik)
• Körültekintő projekttervezéssel lehetne arról gondoskodni, hogy a jogszabályt csak akkor léptessék hatályba, amikorra annak feltételeit biztosítani lehet. Persze ez már vezetői, sőt jelen esetben politikai döntés, amit gyakran nagyon nehéz befolyásolni.
• ...

A konkrét esetről nem tudok többet, mint ami a fenti linken olvasható, ezért ez a cikk csupán a kockázatkezelés fontosságára hívja fel a figyelmet, elképzelhető hogy ebben az esetben egyébként egész más okok játszottak szerepet a végkimenetelben.