Dialoog elust enesest, ühe tarkvara auditi läbiviimise käigus.
Mina: “Hästi, vaatame nüüd üle projekti riskid hetkeseisuga.”
Nooremapoolne projektijuht: “Tead, ega mind need riskid tegelikult üldse ei huvita, ma tahaks ainult asja ägedalt valmis teha.”

Ütlen ausalt, et ohkasin mõttes ikka sügavalt. Projektijuht, kes ei saa aru riskide teadvustamise ja jälgimise tähtsusest, lihtsalt ei ole veel Projektijuht. Võib panna kogu oma noorusliku poweri ja entusiasmi projekti vedamisse – kaasata, suhelda, läbi rääkida, koordineerida jne, aga pahatihti ei lähe projekt ikkagi ägedalt. Kui sa riskide realiseerumiseks valmistunud ei ole, tabavad nad sind alati ootamatult ja löövad jalad alt kogu su tiimil.

Allolev jutt on päris pikk, sest tahtsin olla põhjalik. Olen nooremana läbi käinud samasuguse faasi nagu ülaltoodud projektijuht ja täna ma tean, et just professionaalne riskihaldus on see, mis on vähegi suurema projekti eduks hädavajalik.

Riske ei ole võimalik kunagi täielikult vältida, aga neid saab suures mahus varakult maandada. Kindlasti peab riske hindama regulaarselt kogu projekti jooksul ja nii kui mõni neist pead tõstab, tuleb kiirelt tegutseda ja see pea maha raiuda.

Tegelikult ei ole risk midagi hirmsat ja seda ei pea kartma. Kogenud tiimis ei realiseeru paljud riskid üldse. Samas ei ole ma näinud seni ühtegi projekti, kus ainsatki riski poleks realiseerunud.

Riskide teadvustamine ja õigete meetmete kasutamine on juba pool võitu.

Levinumad tarkvaraprojekti riskid

Iga projekti riskid, esinemise tõenäosused ja mõjud on erinevad, aga esineb ka palju sarnasusi. Siin on ülevaade tarkvaraprojektide enim levinud riskidest, mille hulgast saad enda projekti jaoks valiku teha ja oma projekti spetsiifilisi riske juurde lisada.

Planeerimine ja juhtimine

• Nõrk kommunikatsioon ja projektistaatuse ebapiisav läbipaistvus
• Ebareaalne ajakava
• Tellija projektijuhi (PO) liiga väike ajaressurss
• Tellija projektijuht lahkub töölt
• Täitja meeskonna liige lahkub töölt
• Puhkuseplaanid on kooskõlastamata
• Täitja meeskonna liige haigestub
• Tellijapoolsete osaliste hulk on suur

Nõuded ja skoop

• Täitja jaoks on nõuded ebaselged või ta ei ole neist õigesti aru saanud
• Erinevad ootused projekti skoobi ja tulemite suhtes
• Tööde üleandmine kuhjub projekti lõppu
• Arenduste maht on oodatust suurem
• Nõuded muutuvad tihti, muudatuste juhtimine on nõrk
• Tellijapoolne vahetulemuste kinnitamine hilineb

Kompetents

• Täitja meeskonnas puudub vajalik kompetents
• Tellija projektijuhil puudub vajalik kompetents

Liidestused

• Liidestuse nõuded on ebaselged ja suhtlus kolmandate osapooltega aeglane
• (Siin all saab olla rohkelt eri riske, sõltub kui palju keerukust ja liidestusi arenduses on)

Enamasti realiseeruvad riskid nõrga planeerimise ja projektijuhtimise tulemusel, seetõttu on arendusmetoodika ja tööprotsessi kvaliteet tarkvara projektis tähtsusega number üks.

Alusta riskide kirja panemisest

Riskiplaan tuleb koostada täitja projektijuhi poolt kohe projekti alguses. Jah, see tuleb teha kirjalikult. Ei, sellest ei piisa absoluutselt kui sa ainult oma peas riskidele mõtled. Esimese riskiplaani võid koostada üksi, järgmise sammuna saad selle tiimiga läbi arutada – milliseid riske nemad näevad ja kuidas neid hindavad?

Kui tegu on riigihankega ja pakkumises küsiti riskiplaani, siis on sul mingi põhi juba olemas. Aga pakkumises sisaldunud plaan on ainult oletus, tegelikult sa ei tea millised on tõenäolised riskid enne kui oled kohtunud kõigi osapooltega. Lisa projekti avakoosoleku agendasse riskiplaani arutelu  ja varu selle läbivaatamiseks ja hindamiseks piisavalt aega. 

Blogiposti lõpus on allalaetav näidis riskiplaanist, sellega koos on vahest kasulik koostada ka riskimaatriks, mis annab sulle visuaalse ülevaate. Näiteks võib riskimaatriks näha välja selline:

Planeeri, hinda ja tegutse!

Täitja projektijuhi kohustus on koordineerida riskide hindamist ja maandamise tegevusi alates projekti esimesest päevast. Juhul kui tegevused on tehtud ja need ei andnud soovitud tulemusi, tuleb proovida teisi tegevusi. Kaasa alati ka oma tiimi liikmed, et saada kõigilt ettepanekuid ja ideid. Kui ka need tegevused ei toimi ja risk läheb järjest punasemaks, tuleb risk eskaleerida juhtgrupi või juhtkonna tasemele. On ääretult tähtis, et ei jäädaks probleemse olukorra otsa lihtsalt istuma või nö kummi venitama. Kui probleemi lahendada ei õnnestu, siis eskaleeri ja lahenda see kõrgemal tasemel. Kiiresti.

Hinda riske perioodiliselt iga 2 nädala tagant, see on paras aeg, et jõuaksid riskide esile tõusmisel neile õigeaegselt reageerida. Mõni risk ilmutab end äkitselt, aga tihemini esineb nö hiilivat punasesse minemist ja sa märkad ning tegutsed liiga hilja. Selle vältimiseks lisa riskide hindamise slaid igasse juhtgrupi või projektikoosoleku agendasse. Nii on sul riskid silme ees, teadvustatud ja on kerge hetkeseisu üle hinnata.

Riskide slaid võib välja näha näiteks selline:

Riskiplaani näidis

Riskiplaani dokumendis on järgmised lehed:

• Riskiplaan – tuleb koostada kohe projekti alguses
• Riskimaatriks – aitab riskiplaani visualiseerida ja paremat ülevaadet saada
• Esiletõstetud riskid /kuupäev/ – hetkeseisuga kõige tõenäolisemad riskid, vastutajad ja tegevused, kasuta regulaarseks jälgimiseks

Head kasutamist!

Samal teemal