Buturuga mica care rastoarna carul mare ...

Managementul riscurilor reprezinta unul din aspectele cele mai importante pe care le comporta managementul de proiect. De multe ori cand auzim despre un proiect ca a esuat sau ca si-a depasit bugetul sau a intarziat foarte mult ne gandim la cine stie ce catostrofe. Realitatea cruda este ca proiectele se impiedica de cele mai multe ori in lucruri marunte si care de cele mai multe nu li se acorda importanta cuvenita la momentul potrivit. La lucruri grave intotdeauna se actioneaza energic, din pacate nu acelasi lucru se intampla si in cazul lucrurilor marunte si cu un grad redus de risc ....
Acest comportament tine mai degraba fiinta umana si se manifesta in toate domeniile, as aminti aici cazul banal cand o usoara raceala netratata ajunge sa dea complicatii, in loc sa administram un banal paracetamol ajungem mai tarziu sa luam un antibiotic mult mai costisitor si mai nociv pentru organism.

Atunci cand se intocmeste planul de riscuri intotdeauna sunt identificate si monitorizate riscurile cu impact mare asupra proiectului sau riscurile a caror de probabilitate de producere este mare. Din pacate riscurile cu impact nesemnificativ sau cu probabilitate mica de producere sunt trecute in umbra sau chiar am intalnit ingnorarea lor totala. Nimic mai gresit. Aceste riscuri trebuie intotdeauna identificate si monitorizate de-a lungul vietii proiectului poate cu mai multa raspundere decat riscurile din clasa superiora. De ce? Hai sa analizam o situatie cu care m-am confruntat chiar eu ca manager de proiect.
In cadrul unui proiect software unul din programatori sesizeaza unele erori la compilarea unui modul. Fiind un programator cu mare experienta considera ca eroarea care afecteaza unele iesiri in mod aleator este o chestiune simpla si cu siguranta o va remedia in timp util si astfel merge mai departe cu celelalte module. Culmea intr-una din sedintele de proiect mentioneaza ca are o mica problema la un modul (deci nu poate fi acuzat ca a tinut "gunoiul sub pres") dar ca spera sa o remedieze in timp cat mai scurt. Toata echipa ignora cu desavarsire acest lucru, lucru normal ca sa zic asa, pana la urma in procesul de programare apar tot felul de erori care apoi sunt remediate, fiind de altfel o chestiune normala mai ales cand se merge pe metodologia "agile". Proiectul merge mai departe si in momentul in care se intra cu el in testare se constata ca eroare nu a fost remediata si asfel apar unele erori aleatoare ce e drept in modulele superioare de raportare. Programatorul semnaleaza ca nu reuseste sa remedieze eroarea desi dupa parerea lui codul este corect din punctul lui de vedere. In acest moment situatia devine critica, mai multi colegi din echipa analizeaza eroarea si constata ca codul este corect.Dupa o saptamana de analiza profunda se emite ipoteza ca este ceva in neregula cu mediul de dezvoltare folosit. Este contactat producatorul framework-ul iar dupa alte 3 zile acesta confirma ca eroarea se datoreaza framework-ului si ca nu poate furniza un patch si ca foarte probabil bug-ul va fi remediat odata cu o noua versiune. In acest moment proiectul intra in intarziere si evident in depasire de buget. Dupa o analiza serioasa se ajunge la concluzia ca modulul cu pricina trebuie rescris intr-un alt framework si modificate inputurile la alte 2 module care depind de el. Una peste alta se ajunge in final la o intarziere de circa de doua luni a proiectului.
Poveste de mai sus v-am spus-o tocmai pentru a vedea cum un lucru aparent neinsemnat a avut in impact devastator asupra unui proiect.
Gresala a fost evident facuta in momentul in care programatorul a semnalat eroarea. Toata lumea a fost de acord ca este o chestiune minora si ca experienta programatorului va face ca eroare sa fie remediata in timp util. Din pacate n-a fost chiar asa, chiar daca codul era corect eroarea s-a datorat altor cauze. Daca nu s-ar fi trecut mai departe pana cand aceasta eroare era remediata, evident ca nu s-ar fi pierdut timp util, sa nu uitam ca practic pentru 2 module s-a muncit de doua ori.
Morala acestei intamplari este ca chiar si riscurile neinsemnate trebuie monitorizate cu maxima atentie, nu se stie niciodata cand un risc minor aparent, devine critic si poate duce in finala la esecul unui proiect.