Revista >> Iulie-August 2010 [Nr. 127] >> Project Management

Managementul riscurilor în proiecte IT

Luiza Sandu

25 Iulie 2010

Cum aducem riscul la un nivel acceptabil?

„Există riscuri cu probabilitate mare de apariţie şi impact major în planul de implementare, costuri sau calitatea livrabilelor – în acest caz un sistem de «early-warning» este util, precum şi un plan de acţiune cu roluri clar stabilite. Pentru riscurile cu probabilitate medie de apariţie prefer, în general, să aleg metode prin care să evit să ajung la concretizarea riscului în fapt, iar pentru cele cu probabilitate minoră de apariţie întotdeauna pun în balanţă costurile de a implementa un «plan B» (de contingenţă) faţă de costul total al proiectului. Pentru riscurile cu impact mediu am un plan de contingenţă, iar riscurile cu impact mic prefer să le discut cu clienţii şi iau acţiuni în funcţie de gradul lor de toleranţă la risc”, explică Bogdan Ciungu.

Hilde Corbu crede că, dacă ajungem să ne gândim la acţiuni de reducere a riscului unui proiect, înseamnă că am reuşit să cuantificăm ce înseamnă «nivel acceptabil» de risc şi, de asemenea, am făcut primii paşi în analiza de risc şi am stabilit care este riscul proiectului nostru.

„Se pot selecta apoi strategiile pe care le aplicăm pentru fiecare risc stabilit a fi în «top N» pentru proiectul în discuţie, strategii consacrate deja: eliminare, reducere sau transfer (în cazul riscurilor cu impact negativ) sau exploatare, îmbunătăţire sau colaborare (în cazul oportunităţilor). Odată aleasă strategia, Project Managerul împreună cu echipa va gândi diverse acţiuni posibile, alegând acel set final de acţiuni în funcţie de costuri, competenţele necesare, timpul de implementare şi, nu în ultimul rând, având grijă să nu introducă riscuri secundare în proiect, riscuri generate tocmai de planul de acţiune stabilit”, avertizează Hilde Corbu.

Cu aceste strategii, riscul proiectului poate fi adus sub nivelul de toleranţă stabilit, dar important este nu numai să se stabilească acţiunile, ci să fie şi planificate în timp, să se aloce resurse şi să fie incluse costurile de implementare a acestor acţiuni în total cost proiect. Altfel, vor rămâne doar nişte acţiuni pe hârtie, la capitolul de risc management din cadrul planului de proiect.

Şi Hilde Corbu menţionează importanţa planului B, de contingenţă: „O a patra strategie, cea de aceptare a riscului, nu presupune realizarea unor acţiuni concrete acum, ci gândirea planului «B», de contingenţă, pe care să îl aplici numai în cazul în care sunt semnale clare că riscul se va concretiza la un anumit moment în proiect”.

Stabilirea planului de contingenţă cu toate elementele lui se face la momentul la care riscul a fost identificat, aplicarea lui urmând a fi declanşată la un moment ulterior în proiect, în eventualitatea în care riscul apare. Costurile planurilor de contingenţă formează rezervele de risc, care şi ele trebuie aprobate alături de costul estimat al proiectului. „Din păcate, pentru multe proiecte analiza de risc se opreşte aici, lipsind partea de monitorizare şi control a riscurilor, proces în care ar trebui să verificăm că acţiunile planificate au fost realizate cu efectul scontat, că planul de contingenţă a funcţionat conform aşteptărilor, că am redus expunerea proiectului la nivelul gândit, că procesul în sine de risc management este eficient, iar în cazuri contrare să luăm măsuri. De asemenea, se uită faptul că analiza de risc este un proces iterativ şi că toţi paşii ar trebui reluaţi la momente cheie în proiect, conform procedurii stabilite în acest sens. În esenţă, fiecare întâlnire de proiect ar fi bine să aibă pe agendă discuţia despre statusul riscurilor la acel moment”, subliniază Hilde Corbu.

Cine realizează managementul riscurilor în cadrul unui proiect IT?

Unele teorii de management/supply chain management consideră furnizorii o extensie a organizaţiei şi că riscurile induse de aceştia sunt astfel considerate riscuri interne în proiect, spre deosebire de riscurile induse de clienţi, care sunt văzute ca riscuri externe proiectului.

„Dacă avem în vedere o legătură contractuală, responsabilitatea realizării managementului de risc în proiecte (nu numai în cele IT) revine acelei părţi a cărei metodologie de management de proiect s-a agreat că va fi aplicată şi respectată de către toate părţile implicate. Deci, o parte (furnizorul sau beneficiarul) are metodologia şi gândeşte şi gestionează procesul de risc management, la derularea şi aplicarea căruia contribuie însă toate celelalte părţi. Responsabilitatea aplicării strategiilor de răspuns la risc este stabilită de comun acord şi poate reveni oricărei părţi”, spune Hilde Corbu.

Depinde, evident, şi din ce perspectivă priveşti. În mod real, atât furnizorul, cât şi beneficiarul vor avea fiecare lista lui de riscuri, planuri de acţiune etc., care nu vor fi neapărat transparente celeilalte părţi, urmând a gestiona împreună, conform contractului, acele riscuri cu impact asupra performanţei contractuale a ambelor părţi şi ale căror strategii de răspuns la risc depind sau pot fi mai bine implementate de către cealaltă parte.

Rezolvarea problemelor identificate în cadrul analizei prin utilizarea unei metodologii de management de proiect de către organizaţiile care furnizează proiectul sau care beneficiază de pe urma acestuia şi utilizează produsul proiectului reprezintă un factor determinant în asigurarea succesului acestuia.