luni, 12 aprilie 2010

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.

joi, 8 aprilie 2010

Stiluri personale in managementul de proiect - micul tiran sau ghiolbanul de romania

Richard Newton in "The Project Manger -Mastering the art of delivery" ( cine doreste o poate citi si in limba romana la editura Codecs) face referire la un anume stereotip intalnit in randul managerilor de proiect " ... genul de manager care isi intimideaza subordonatii si atunci cand lucrurile nu merg bine incepe sa urle. Metoda generala de lucru a micului tiran este sa aiba grija ca toata lumea sa-l recunoasca drept sef. Micii tirani vorbesc intotdeauna despre respect, pe care il confunda cu puterea. Ei inteleg gresit atributiile de conducere, in mintea lor a-i conduce pe oameni inseamna sa-i faci sa-si cunoasca lungul nasului. Plesnesc de satifactie cand oamenii cedeaza in fata lor si de obicei sunt obsedati de titulaturi pompoase si de pozitii ocupate in ierarhia organizatioanala. Micul tiran este varianta adulta a batausului clasei".
Ei bine cu parere de rau trebuie sa recunosc ca acest stil in Romanica noastra cea de toate zilele am avut ocazia sa-l intalnesc mai des decat mi l-as fi dorit. Micul tiran in varianta mioritica are multe in comun cu un alt personaj celebru noua si anume ghiolbanul de romania. Ghiolbanul de Romania (am scris cu litere mari desi nu merita) nu stie niciodata nimic, cv-ul lui este intotdeauna impresionant mai pe limba noastra "la fatat masa sef". El are intotdeauna dreptate, sedintele lui de proiect sunt intotdeauna lungi (are pretentia ca toata lumea sa ia notite) si se termina fara nicio concluzie. La el toata lumea trebuie sa stea peste program, si sa simuleze ca trage din greu ca se impauneze superiorilor ca "ce tare e el". Culmea este ca in cazul lui nu conteaza ca proiectul merge prost sau ca s-a depasit bugetul sau este in intarziere, el este intotdeauna acoperit de hartii ba mai mult da vina pe echipa " astia sunt oamenii pe care-i am, fac si eu ce pot". De fapt este un mare zero profesional, acest model fiind o reminiscenta a vremurilor trecute si adaptat perfect la economia de tranzitie unde promovare pe criterii de pile sau de apartenenta la un anume grup tine loc de compententa. De fapt pe el nu-l intereseaza proiectul in sine, el este acolo pentru simplul si unicul motiv ca postul pe care il ocupa este bine retribuit si ii aduce faima.
Daca din intamplare proiectul merge bine, asta nu este nici pe departe meritul lui ci al prostilor care trage pentru el de frica sa nu fie dati afara si sa ramana pe drumuri.
As putea vorbi zile intregi despre acest subiect dar nu asta este scopul acestui post. Desigur ca multi au intalnit acest stereotip in activitatea lor si poate au simtit o mare frustrare personala. Eu mi-am permis sa vorbesc despre acest fapt pentru ca cred ca cineva trebuie sa spuna si lucrurilor pe nume. In Romania din pacate putini dintre cei care conduc o afacere, un proiect, etc ... au o pregatire in ceea ce priveste lucrul cu oamenii. Cheia succesului sta tocmai aici, si va asigur ca este poate cel mai difil lucru. Daca a conduce o masina, a lucra cu un software etc... ajunge la un moment dat sa fie un lucru usor, ei bine a lucra cu un om este cel mai dificil lucru, tot timpul vei constata ca ai ceva de invatat, in plus omul se schimba cu trecerea timpului iar comportamentul sau poate fi diferit chiar de la o zi la alta in functie de stare de sanatate, de starea lui interioara, etc ...
Atunci cand vom invata sa pretuim "Omul" ca toate lucrurile lui bune si rele atunci cu siguranta se va schimba ceva in mentalul colectiv din Romania.