Managementul riscurilor

Postat la iulie 12, 2013 de ThePMJournal

-Ce e asta?

-Este un nou risk, Andrew.

-Mai este o luna pana la finalul proiectului si tu abia acum imi spui ca a aparut un risk?

-Andrew, a avea un risc nu inseamna ca s-a si intamplat. In plus, eu nu pot prevedea toate riscurile unui proiect de la bun inceput. Riscurile apar sau dispar in functie de evolutia lucrurilor. Ce ai vrea sa fac? Sa spun ca proiectul nu are riscuri?

-Trebuie sa vorbim. Sunt destuli carcotasi care se plang ca nu ai proiectul sub control.

In multe companii, managementul riscului este un subiect tabu. Cand lumea aude de riscuri, parca aude de naiba; intra in panica si incepe sa gaseasca vinovati:

-Cum adica avem riscuri? Si noi abia acum stim? Si managerul de proiect ce face?

Aceste discutii au loc deoarece putini stiu ce inseamna un risc, putini stiu cum se gestioneaza un risc si cei mai multi considera ca gestiunea riscului apartine in totalitate Project Managerului. Toti se asteapta de la Project Manager sa fie un fel de super-zeu care stie dinainte ce se va intampla cu soarta proiectului, cu soarta omenirii, ca poate preveni tot raul din lume, ca poate lupta chiar si cu balaurii cei rai daca e nevoie, in asa fel incat toti stakeholderii cheie sa poata dormi noaptea linistiti. Project Managerul este mai tare decat Chuck Norris…

Lucram ca Program Manager la unul din cele mai ambitioase suita de proiecte din industria de securitate. Cand primisem programul, projects charterele fusesera deja aprobate (cel putin asa reiesea din spusele Sponsorului). Mai tarziu am realizat ce insemna pentru Sponsor „un project charter„: un email cu cateva idei notate dintre care asa zisele „obiective” (sub forma unor povesti utopice), deadline in patru luni de acum incolo, resurse limitate si la final „Mult succes!„. Mi-am pus mainile in cap. Stiam foarte bine ca proiectul fusese sub-evaluat, resursele vor fi supra-alocate, deadline-ul a fost impus fara a se consulta echipa tehnica si toate riscurile astea au fost ignorate. Probabil si-au imaginat ca atunci cand voi prelua proiectul (care de fapt era un program de proiecte interdependente), eu voi gestiona toate acele riscuri si, ca prin minune, eu voi salva onoarea companiei. De ce onoarea companiei? Pentru ca de fapt, de acele proiecte, depindea tot cash flowul companiei in urmatorul an, de el depindea si cotarea pe piata a companiei (companie care apropo trebuie vanduta urgent pe o suma cat mai mare unor noi investitori…), cu alte cuvinte ceea ce aveam eu de facut nu era numai ducerea la bun sfarsit a proiect „misiune imposibila”, dar si optimizarea costurilor operationale, implementarea unui PMO si alte lucruri din astea care il fac pana si pe Chuck Norris sa para mic.

Dintre stakeholderii cheie al programului erau directorii companiei, unul mai important ca altul (cu toate titlutile onorifice specifice): Chief of Products, Chief Marketing, Chief IT, Chief Engineering, Chief Operations, Chief Executive of Executives, etc. Toti isi faceau planuri de bugete, de strategie, de produse pe baza a ceea ce urma sa livrez eu in urmatoarele 4 luni. Cum puteam sa ating obiectivele proiectului in timp util cand existau cel putin zece riscuri majore identificate care puneau in pericol obiectivele proiectului?

M-am gandit ca daca fac cunoscute riscurile asociate obiectivelor, stakeholderii cheie vor intelege ca e nevoie de un efort colectiv, nu numai din partea mea (ca PM) ci si a lor, pentru a minimiza riscurile proiectului. Am cerut signoff-ul pentru planul de proiect cu toate riscurile asociate si aparent toata lumea a fost multumita. Peste cateva luni am inteles eu de ce era ei asa de multumiti: pentru ca nimeni nu citise planul de proiect, dar semnasera in orb planul. La Risk Owneri erau trecuti trei din directorii executivi, carora li se solicita sa minimizeze riscurile asociate resurselor (fie prin angajarea de personal, fie prin aprobarea muncii overtime), sa reduca scopului produselor (era nevoie de o renegociere a scopului si a deadline-urilor de marketing), sa aprobe bugete suplimentare. Dar toate aceste aspecte aparent „minore”, le-a scapat din vedere, pentru ca ei se asteptau de la mine la totul.

Nesolutionarea unor riscuri de catre Risk Owneri, bineinteles a dus la aparitia altor riscuri. Si pe masura ce proiectele se dezvoltau apareau alte riscuri noi. Superiorul meu, unul din directorii din board ma tot intreba:

-Ce sunt riscurile astea noi? De unde tot apar? Nu gestionezi bine proiectul.

La un moment dat, am ridicat problema ca scopul produselor se modifica de la o zi la alta si implicit va impacta obiectivele principale. Dar toata lumea a crezut ca este doar o exagerare de-a mea sau rea vointa si bineinteles ca riskul a fost ignorat. Vazand ca nimeni nu isi asuma riscurile proiectului, nu am mai tinut socoteala lor. Tratam problemele cum apareau, in stil „Agile”, de pe o zi pe alta. Si uite asa am inceput sa imi asum rolul de SuperMan care solutioneaza problemele din zbor („on the fly„). Totul a fost amuzant si provocator pentru mine, pana intr-o buna zi, cand CEO-ul a cerut un status al proiectului. Atunci cand a inteles ca vom depasi cu doua saptamani deadline-ul de marketing (doua saptamani era o nimica toata tinand cont prin ce probleme trecuse proiectul, cati bani se economisisera pentru ca munca overtime care nu fusese platita), a spus: Sunt nemultumit de Program Manager. Aceasta intarziere este inadmisibila! Cand CEO-ul a intrat in criza, toti ceilalti directori au intrat si ei in fibrilatii, caci jobul lor era pus in pericol si au inceput sa fie foarte atenti la desfasurarea proiectului.

Intr-una din zile (cu doar o luna inainte de a lansa produsele oficial pe piata), aparuse din senin un nou risc al proiectului: daca Microsoft nu obtinem certificarea pentru windows store 8.1 asa cum era planificat, nu vom putea lansa produsele pe windows in timp util. Mai era si un risc ca Microsoft poate amana update-ul de windows 8.1, insa pana la urma acest risk nu s-a materializat si nu au fost impactati userii care isi updatau windows-ul. Pentru a evita aceste riscuri, toata companiei a intrat in sevraj, caci erau impactati multi useri deja existenti. Toata povestea ne-a costat un weekend nedormit cu toata echipa tehnica.

Care este invatatura din aceste povesti?

Va spun de la bun inceput ca foarte putini au avut ceva de invatat din asta. In toata aceasta poveste, eu am fost gasit vinovat, ca manager de program. Exista cateva lectii care totusi pot fi invatate:

Lectia 1 despre cum se face inregistrarea riscurilor. Putini stiu ce componente obligatorii trebuie sa aiba un un risk in documentul Risk Register: denumire risc, impact, probabilitate de impact, cuantificarea impactului (in bani, resurse, scop, satisfacerea clientului, etc), categorie risc (urgent, mediu, putin important, etc), solutii de mitigare (eventual un plan cu doua solutii dintre care una de backup), Risk Owner (cine este responsabil cu riscul), Status Risc si mai pot fi adaugate si alte componente care depind de organizatie.

Lectia 2. Nimanui nu-i plac riscurile si nimeni nu vrea sa auda de riscuri. Asadar este nevoie de o atentie suplimentara a felului cum comunicam riscurile. Inainte de a trimite, pe email, un Risk Register cu 20 de riscuri inregistrate (dintre care 5 riscuri critice care sunt in decurs de desfasurare, 10 riscuri medii), e nevoie de cateva sedinte de pregatire (de informare si constientizare a sponsorului, a clientilor sau a altor stakeholderi cheie).

Lectia 3. Riscurile cunoscute sunt inregistrate in Risk Register si au impactul exprimat in bani, ore de lucru, timp, resurse, etc. Aceste riscuri sunt intotdeuna adaugate in planurile de proiect (buget, timp, etc). Sunt putini project manageri care adauga riscurile la planul de proiect intr-un mod adecvat (de exemplu: planul de buget trebuie sa contina intotdeuna banii alocati pentru a solutiona riscurile cunoscute; planul de timp contine intotdeauna activitati asociate monitorizarii riscurilor cunoscute). Cei mai multi atunci cand fac bugetul de proiect in loc sa evalueze riscurile, adauga un buffer de 30% la costul de lucru al echipei si spun ca ala e bugetul (inclusiv riscurile). Pe langa faptul ca acesta practica nu reprezinta o cuantificare realista a riscurilor (de ce 30% si nu 15% sau 85%?) nu justifica concret pe ce anume se vor cheltui banii proiectului. Bugetul asociat riscurilor cunoscute e numit Contingency Reserves si este gestionat direct de Project Manager.

Lectia 4. Riscurile necunoscute. Aceste riscuri nu le poti preveni si, de cele mai multe ori cand iti dai seama de ele, fie e prea tarziu, fie poti face prea putin pentru ele. Cea mai buna solutie pentru solutionarea/evitarea unor astfel de probleme (riscuri) este o comunicare buna indeaproape cu Sponsorul proiectului (daca te intelegi bine cu el, cand apare o problema va fi mai usor sa o accepte si sa iti ofere ajutorul). Riscurile din aceasta categorie nu se pot defini si nici evalua cu precizie, de aceea se adauga la bugetul de proiect ca un buffer special numit Management Reserves. De asemenea atunci cand se fac estimarile de buget pentru proiectele potential viitoare (operatiunile de pre-sales) intotdeuna trebuie sa cuprinda si estimarea de management reserves (indiferent de forma specificata: manhours, resurse, bani). Acest buget este in general gestionat de Sponsor sau de project manager, daca are autoritatea desemnata de la Sponsor.

Lectia 5. Lipsa managementului riscului sau o gestiune a riscurilor precara este un risk in sine. De asemenea, eliminarea riscurilor ca activitati din proiect cu scopul de a micsora bugetul sau timeline-ul proiectului, poate de fapt sa mareasca bugetul si durata proiectului. Activitatile de Risk Management sunt taskuri care nu pot fi scoase din planul de proiect (ele au un cost, o durata asociata si o serie de dependinte). Astfel spus eliminarea fortata a unui risc, implica alt risc. Vezi povestea Poti sa ii spui unui PM cum sa-si faca treaba?

Lectia 6. Agile este un risc in sine. Cand am primit rolul de Program Manager, mi s-a dat misiunea de a implementa Agile in companie. Ca sa va faceti o idee ce se vroia: numarul oamenilor care lucrau la proiecte erau peste 50, impartiti in diferite departamente (R&D, QA, IT, Marketing, Release, Fulfillment, Support, etc). Pe langa faptul ca unii din ei nici macar nu stiau cu ce se „mananca” Agile sau ca nici unul din echipa nu primisera un training corespunzator in acest sens, organizarea interna a departamentulelor nu permitea modul de lucru Agile (erau pozitionate pe etaje diferite, orarul de lucru era diferit, toolurile de lucru diferite, procesele departamentului diferite etc.). In aceste conditii am incercat implementarea Agile doar in cadrul departamentelor R&D si QA, ceea ce oricum a fost o provocare in sine, tinand cont de rezistenta la schimbare a echipelor (erau oameni de noua ani in companie care nu avusesera in viata lor un Project Manager; erau haiduci inascuti, inversunati impotriva conducerii neperformante, fiecare lucra dupa cum ii taia capul, iar orice forma de organizare, Agile sau traditionala, le repugna). Pana la urma am reusit intr-o forma simplista sa implementam Agile. Insa dupa cum stiti, in Agile nu exista conceptul de Risk Management, ci exista conceptul „manage the problem as you go„, insa la un proiect cu multe dependinte de activitati si resurse poti intra in belele mari cu aceasta strategie (unele probleme/riscuri trebuie prevenite cu 4-5 luni inainte de a se intampla, pe cand focusul in Agile este pentru cel mult 1 luna in avans; de asemenea, am constatat ca in practica, echipele Agile nu isi bat capul cu risk management in afara sedintelor daily scrum meeting si nici atunci riscurile nu sunt tratate corespunzator). Asa cum am aratat, lipsa gestiunii riscurilor este un risc in sine, inseamna ca un framework Agile care nu are un management de risk adecvat este un risc in sine.

Exemplu Risk Register

Teoria ne invata care sunt pasii principali in completarea unui risk register sunt: Identificarea riscurilor, Analiza Calitativa a riskurilor (fara cifre exacte), Analiza Cuantitativa (cifre exacte), Oferirea solutiilor si updatarea statusurilor riskurilor. Nu o sa intru in detalii cum se identifica riscurile, intrucat fiecare din noi o face chiar fara sa isi dea seama (in meetingurile zilnice, in pauzele de tigara, prin feedback-ul colegilor, auto-analiza etc.), insa voi descrie doua aspecte pe care majoritatea PM-ilor nu le trateaza cu atentie: analiza cantitativa si calitativa a riscurilor.

Analiza calitativa nu ofera cifre exacte ci doar o valoare relativa a Impactului si Probabilitatii. Din inmultirea celor doua valori se poate obtine o valoare relativa care determina cat de important este riscul si cat de repede trebuie tratat. De obicei doar riscurile importante trec mai departe in etapa de analiza cantitativa, insa e recomandat ca analiza cantitativa sa se aplice tuturor riscurilor identificate indiferent cat de neimportante par. Iata cum arata analiza cantitativa:

Cel mai important aspect care trebuie subliniat este ca analiza cantitativa ofera o analiza amanuntita a impactului asupra costului, timpului, scopului si a tuturor constrangerilor proiectului. O metoda care se foloseste in Analiza cantitatita este Expected Monetary Value Tree sau EMV (a nu se confunda cu EVM=Earned Value Management) care calculeaza care arbore de decizie ofera cea mai buna decizie (arborii de decizie sunt complementari, adica deciziile lor se exclud reciproc) . Fiecare arbore de decizie are un Impact (I) si o Probabilitate(P). EMV=I*P.

Iata cum arata un Risk Register cu toate datele integrate:

Nota: importanta riscurilor este marcata folosind notatia RGA (Red, Green, Amber).

Exemplu de Expected Monetary Value

Cum decidem care este cea mai buna decizie in cazul in care avem mai multe solutii de mitigare a riscurilor? Sa luam urmatorul exemplu: Evaluarea efortului noilor change requesturi poate pune in pericol depasirea bugetul proiectului cu 100 ore. Fiind vorba de doar 100h peste buget, pentru a nu pune o presiune suplimentara pe relatia dintre companie si client, se pune problema daca se merita negocierea cu clientul a unui aprobari de extrabuget pentru evaluarea change requesturilor sau compania sa isi asume costurile (fiind parte din costul de sales)? Avem doi arbori de decizie:

Arbore 1 (solutia 1). Compania accepta costul. Probabilitate de depasirea a bugetului este de 60%, impact 100h sau 40% probabilitate sa nu afecteze bugetul (nici un cost asociat). Asadar, EVM1 = 60%*100+40%*0=60 manhours.

Arbore 2 (solutia 2). Compania nu isi asuma costul. Conform contractului putem negocia costul; clientul poate plati intre 50%-100% din costul total. Impact: 100h. Aici avem mai multi arbori de decizie cu diferite costuri: in cel mai rau caz costul companiei este 50%*100 =50h si cel mai bun caz este 0 (cand clientul accepta 100% costul). EVM2 = maximum cost EVM = 50%*100h = 50 manhours.

Deoarece EVM2solutia 2 este mai buna si merita implementarea ei.

Note Finale

In Risk Register fiecare risk are asociata o solutie recomandata pentru evitarea, mitigarea sau rezolvarea riscului. Solutia este furnizata in coloana Contingency Plan. Daca aceasta solutie nu functioneaza ar trebui sa avem si un Fallback plan (plan de rezerva). Teoretic, bugetele pentru Contingency Plan si Fallback Plan trebuie sa fie acoperite din bugetul Contingency Reserves care se afla in gestiunea Project Managerului si se aloca la inceputul sprintului/fazei/proiectului, insa impactul riscurilor poate sa creasca in timp facand bugetul alocat initial pentru gestiunea riscurilor insuficient; cand Contingency Reserves devine insuficient pentru a solutiona riscul, se poate folosi o parte din bugetul „Management Reserves”, daca Sponsorul este de acord.

Deoarece riscurile pot avea un impact atat de important in bugetul proiectului, Contingency Reserves si Management Reserves, trebuie adaugate in oferta de pre-sales pentru clienti (in procesul de cerere-oferta/bid), pentru a se evita negocieri de buget suplimentare in timpul proiectului (pentru riscuri neprevazute).

Aceeasi abordare de Risk Management folosita in cadrul proiectelor, poate fi folosita in gestiunea programelor sau a operatiunilor afacerilor in general.