Asa cum am mentionat in postul anterior, una din principalele atributii ale managerului de proiect este indentificare, negocierea si obtinerea resurselor pentru proiectul sau. Cand ne referim la resurse gandul nostru trebuie sa zboare mai intai la materiale/echipamente si oameni si mai putin la bani sau timp. Banii in mod normal nu ar trebui sa constituie o problema daca proiectul a fost aprobat si bugetul alocat. Singura noastra grija este sa ne asiguram ca banii vor fi disponibili atunci cand vom avea nevoie de ei, este cunoscut faptul mai ales cand e vorba de sume importante ca contabilii obisnuiesc sa-i tina prin tot felul de depozite si ca s-ar putea sa ne trezim ca nu putem platii un furnizor tocmai datorita faptului ca " nu se poate abia am constituit un depozit avantajos si doar peste 3 saptamani ajunge la scadenta". Totusi consider ca daca iti faci temele cu grija banii ar fi in principiu resursa cea mai usor de gestionat. Am exclus aici din start ideea ca avem un proiect aprobat si pornit pentru care nu exista suficiente fonduri alocate desi cazul asta in romanica nostra s-ar putea sa-l intalnesti destul de des. Resursa timp in general nu este direct controlabila, ea depinde foarte mult de celelalte resurse materiale/echipamente si oameni.
Aceste resurse de fapt sunt marea problema a managerului de proiect. De exemplu pentru o anumita operatie avem nevoie de un excavator sau de o macara. Problema este ca nu intotdeauna avem disponibila macaraua in momentul in care ne dorim. Problema se complica de exemplu daca de exemplu avem nevoie de excavator si macara exact in acelasi timp. Iata deci ca e posibil sa intarziem proiectul pentru simplul motiv ca nu avem disponibile niste resurse exact la momentul planificat. Un astfel de caz dupa parerea mea se trateaza ca "RISC" si trebuie trecut in foaia de riscuri si monitorizat atent. Cu cateva zile inainte de necesitatea resursei respective trebuie sa ne asiguram ca o avem disponibila si ceea ce recomand eu, un plan de contingenta este bine venit, putem contacta mai multi furnizori de echipamente asfel ca sa ne asiguram ca macar unul din ei ne poate oferi la data stabilita de noi excavatorul sau macaraua dorita.
Cam acelasi lucru se intampla si in cazul oamenilor, e foarte probabil ca atunci cand avem nevoie de un electrician sau un inginer constructor el sa nu fie disponibil. Totusi in cazul oamenilor as dori sa ma opresc asupra unui alt aspect. Cand lucram cu furnizori externi sigur ca nimic nu ma opreste sa caut un alt electrician sau inginer constructor, dar ce ne facem cand ii avem angajati pe hartie in proiect iar proiectul nostru are o structura matriciala, adica oamenii sunt pe de o parte subordonati noua si pe de alta parte subordonati managerului departamentului din care face parte, adica lucreaza in proiect part time. Intotdeauna legatura omului cu seful direct este mai puternica si tendinta va fi sa neglijeze proiectul. Lucrurile sunt chiar mai rele in cazul in care managerul lui direct face parte din cei ce nu sustin proiectul. In cazul asta chiar avem o problema. Mentinerea unei comunicatii bune cu ceilalti manageri din firma este desigur regula de aur. Trebuie sa ne face timp intotdeauna de vizite de curtoazie pe la managerul X sau Y sau sa nu ne sfiim sa-l invitam la cafea si o mica palavrageala. Dar sa nu uitam niciodata sa aducem in discutie proiectul si sa-i sugeram ca succesul proiectului depinde si de el si de modul in care va stii sa-si implici si sa-si motiveze oamenii din subordine. Daca o anume persoana si-a facut bine treaba sa nu ne sfiim sa-i gadilam putin orgoliul " X a facut o treaba buna cred ca este si meritul dumnevoastra ....." si alte dulcegarii de genul asta.
In ceea ce priveste resursele, capacitatea de negociere a unui manager de proiect este serios pusa la incercare. Iata de ce trebuie permanent sa ne imbunatim capacitatea de negociere si totodata legat de ea capacitatea de comunicare in general.
luni, 20 septembrie 2010
luni, 13 septembrie 2010
Principalele activitati ale managerului de proiect
Fiecare proiect prin insasi natura lui este unic si are de cele mai multe ori loc intr-un cadru organizational unic, din acest motiv si sarcina pe care fiecare manager de proiect trebuie s-o indeplineasca este unica. Totusi analizand mai multe proiecte se poate structura un tablou de activitati pe care managerii de proiect trebuie sa le indeplineasca si asta independent de proiect.
1.Configurarea obiectivelor – in mare aceasta activitate are in vedere stabilirea sau insusirea obiectivelor si directiilor generale de actiune, interpretarea acestora, reactia la modificarea lor, clari ficarea problemelor si delimitarea zonelor problematice.
2.Obtinerea resurselor – identificarea resurselor, negocierea lor, gestionarea lor eficienta.
3.Configurarea rolurilor si a structurilor – clarificarea si modificarea rolurilor proprii si ale celorlalti specialisti.
4.Stabilirea unor comunicatii bune - crearea legaturilor dintre diversi indivizi si grupuri care contribuie la desfasurarea proiectului, astfel incat acestia sa poata sa-si manifeste sprijinul si implicarea
5. Vizualizarea imaginii de ansamblu – adoptarea perspectivei “din elicopter” , gestionarea timpului si a resurselor, anticiparea evenimentelor neprevazute si a actiunilor persoanelor implicate in proiect ( mai ales cele ale persoanelor care se opun)
6.Propulsarea proiectului – efectuarea de actiuni si asumarea riscurilor necesare pentru bunul mers al proiectului, mai ales in fazele lui dificile.
Importanta acestor activitati poate varia de la un proiect la altul, dar in mare acestea sunt capitolele pe care un manager de proiect trebuie sa le aiba in vedere in activitatea sa.
Voi reveni in viitor cu unele detalii asupra acestor activitati dand si unele exemple concrete.
1.Configurarea obiectivelor – in mare aceasta activitate are in vedere stabilirea sau insusirea obiectivelor si directiilor generale de actiune, interpretarea acestora, reactia la modificarea lor, clari ficarea problemelor si delimitarea zonelor problematice.
2.Obtinerea resurselor – identificarea resurselor, negocierea lor, gestionarea lor eficienta.
3.Configurarea rolurilor si a structurilor – clarificarea si modificarea rolurilor proprii si ale celorlalti specialisti.
4.Stabilirea unor comunicatii bune - crearea legaturilor dintre diversi indivizi si grupuri care contribuie la desfasurarea proiectului, astfel incat acestia sa poata sa-si manifeste sprijinul si implicarea
5. Vizualizarea imaginii de ansamblu – adoptarea perspectivei “din elicopter” , gestionarea timpului si a resurselor, anticiparea evenimentelor neprevazute si a actiunilor persoanelor implicate in proiect ( mai ales cele ale persoanelor care se opun)
6.Propulsarea proiectului – efectuarea de actiuni si asumarea riscurilor necesare pentru bunul mers al proiectului, mai ales in fazele lui dificile.
Importanta acestor activitati poate varia de la un proiect la altul, dar in mare acestea sunt capitolele pe care un manager de proiect trebuie sa le aiba in vedere in activitatea sa.
Voi reveni in viitor cu unele detalii asupra acestor activitati dand si unele exemple concrete.
vineri, 10 septembrie 2010
Proiecte cu finantare europeana - Fisa de proiect bat-o vina ...
In urma cu cateva zile un amic m-a rugat sa arunc o privire pe dosarul lui de proiect. Proiectul era unul ce se dorea cu finantare de la Comunitatea Europeana si fusese respins. Omul era destul de suparat deoarece cheltuise mai multe mii de euro cu intocmirea lui platind o firma de consultanta.
De mult doream sa pun mina pe un astfel de dosar, deoarece pana acum am fost implicat mai mult tangential in astfel de proiecte.
De cum am deschis dosarul din deformatie profesionala am cautat fisa de proiect. Spre surprinderea n-am gasit ceva ce sa semene cu o fisa de proiect ci doar o descriere destul de pompoasa a proiectului din care sincer n-am prea inteles mare lucru. M-am oprit a mai parcurge dosarul si am cerut interlocutorului meu lamuriri pentru a ma edifica asupra ceea ce doreste sa faca.
Atunci cand incepi un proiect cel mai important este intocmirea unei fise de proiect. Desi nu exista un tipic anume fisa de proiect trebuie sa raspunda clar si concis la niste intrebari de genul:
1. De ce ? - de ce faci proiectul
2. Care sunt obiectivele proiectului ? - ce probleme doresti sa rezolvi cu el
3. Cui se adreseaza proiectul? - cine este beneficiarul
4. Cu cine? - competentele si expertiza necesara
5. Unde ? - unde se doreste implementare proiectului
6. Care sunt rezultatele asteptate ? - la ce te astepti dupa terminarea proiectului
In functie de proiect sigur ca mai sunt si alte intrebari la care trebuie sa raspunzi atunci cand intocmesti o fisa de proiect.
In cazul amicului meu aceasta fisa era continuta intr-o asa zisa descriere a proiectului si care nu raspundea in mod clar la nicio intrebarea de genul celor mai de sus.
Oricine analizeaza un proiect, primul lucru pe care il face este sa vada despre ce este vorba in acel proiect, si vrea sa vada acest lucru intr-un mod clar si fara echivoc. Daca te apuci si scrii tot felul de povesti ca sa atarne greu dosarul la cantar cu siguranta locul proiectului tau este la cosul de gunoi. Sa fim intelesi un proiect nu este ca comentariul din scoala de la orele de limba romana in care fiecare vorbeste vrute si nevrute, oamenii care analizeaza astfel de dosare nu au timp sa citesca povestile noastre, ei vor dintr-o singura privire sa se edifice asupra proiectului nostru si daca i se pare interesant va trece mai departe cu analiza.
Una peste alta i-am spus amicului meu ca asa cum eu m-am oprit dupa primele pagini cu analiza asa si comisia care a analizat proiectul l-a respins pentru simplul motiv ca nu e clar si concis din capul locului ce vrea sa faca.
In final imi permit o remarca. In ultimul timp au aparut pe piata tot felul de experti si de consultanti care va iau bani grei pentru intocmirea dosarelor de proiect. Trebuie spus ca multi din ei au pus mana pe diverse documentatii si modele de proiecte si multi nu au niciun fel de competente in ceea ce priveste managementul de proiect ci nu fac altceva decat copy&paste in diverse template-uri, de cele mai multe ori lipsindu-le limbajul necesar. Inainte de a lua legatura cu o astfel de firma de consultanta cred ca mai util ar fi sa cheltuiti cativa banuti cumparand o carte de familiarizare in managementul de proiect care va va lumina putin in ceea ce priveste termenii si limbajul specific , astfel ca atunci ca aveti o discutie cu cineva pe aceasta tema sa va dati seama ca persoana respectiva este competenta sau nu in domeniul respectiv.
De mult doream sa pun mina pe un astfel de dosar, deoarece pana acum am fost implicat mai mult tangential in astfel de proiecte.
De cum am deschis dosarul din deformatie profesionala am cautat fisa de proiect. Spre surprinderea n-am gasit ceva ce sa semene cu o fisa de proiect ci doar o descriere destul de pompoasa a proiectului din care sincer n-am prea inteles mare lucru. M-am oprit a mai parcurge dosarul si am cerut interlocutorului meu lamuriri pentru a ma edifica asupra ceea ce doreste sa faca.
Atunci cand incepi un proiect cel mai important este intocmirea unei fise de proiect. Desi nu exista un tipic anume fisa de proiect trebuie sa raspunda clar si concis la niste intrebari de genul:
1. De ce ? - de ce faci proiectul
2. Care sunt obiectivele proiectului ? - ce probleme doresti sa rezolvi cu el
3. Cui se adreseaza proiectul? - cine este beneficiarul
4. Cu cine? - competentele si expertiza necesara
5. Unde ? - unde se doreste implementare proiectului
6. Care sunt rezultatele asteptate ? - la ce te astepti dupa terminarea proiectului
In functie de proiect sigur ca mai sunt si alte intrebari la care trebuie sa raspunzi atunci cand intocmesti o fisa de proiect.
In cazul amicului meu aceasta fisa era continuta intr-o asa zisa descriere a proiectului si care nu raspundea in mod clar la nicio intrebarea de genul celor mai de sus.
Oricine analizeaza un proiect, primul lucru pe care il face este sa vada despre ce este vorba in acel proiect, si vrea sa vada acest lucru intr-un mod clar si fara echivoc. Daca te apuci si scrii tot felul de povesti ca sa atarne greu dosarul la cantar cu siguranta locul proiectului tau este la cosul de gunoi. Sa fim intelesi un proiect nu este ca comentariul din scoala de la orele de limba romana in care fiecare vorbeste vrute si nevrute, oamenii care analizeaza astfel de dosare nu au timp sa citesca povestile noastre, ei vor dintr-o singura privire sa se edifice asupra proiectului nostru si daca i se pare interesant va trece mai departe cu analiza.
Una peste alta i-am spus amicului meu ca asa cum eu m-am oprit dupa primele pagini cu analiza asa si comisia care a analizat proiectul l-a respins pentru simplul motiv ca nu e clar si concis din capul locului ce vrea sa faca.
In final imi permit o remarca. In ultimul timp au aparut pe piata tot felul de experti si de consultanti care va iau bani grei pentru intocmirea dosarelor de proiect. Trebuie spus ca multi din ei au pus mana pe diverse documentatii si modele de proiecte si multi nu au niciun fel de competente in ceea ce priveste managementul de proiect ci nu fac altceva decat copy&paste in diverse template-uri, de cele mai multe ori lipsindu-le limbajul necesar. Inainte de a lua legatura cu o astfel de firma de consultanta cred ca mai util ar fi sa cheltuiti cativa banuti cumparand o carte de familiarizare in managementul de proiect care va va lumina putin in ceea ce priveste termenii si limbajul specific , astfel ca atunci ca aveti o discutie cu cineva pe aceasta tema sa va dati seama ca persoana respectiva este competenta sau nu in domeniul respectiv.
miercuri, 8 septembrie 2010
Atentie la frontiere !!!
M-am gandit sa scriu acest post avand in minte unele experiente personale de data recenta sau mai vechi.Cunoasterea foarte clara si precisa a frontierelor unui proiect poate determina in final succesul sau esecul unui proiect. De multe ori mai ales in cadrul proiectelor mari sau in care sunt implicate mai multe echipe de proiect granitele proiectului sunt undeva intr-un nor de ceata. Lucrul asta are o mai mica importanta in cadrul proiectelor interne ale unei companii ( proiectul are ca beneficiar un departament intern) deoarece pana la urma toti angajatii trag la acceasi caruta.Lucrurile se schimba radical in cazul in care benficiarul este unul extern.
Sa ma explic putin. Exista tendinata fireasca a membrilor echipei ca in elanul creator si din dorinta de a-si face cat mai bine treaba de a face si lucruri care nu sunt treaba lor ci sunt in sarcina exclusiva a beneficiarului.
In vine in minte un proiect mai vechi in care am fost implicat mai mult colateral si in care am fost invitat sa-mi spun o opinie. In cadrul unui proiect de implementare ERP membrii echipei din dorinta de a-si face cat mai bine treaba au inceput sa-i reorganizeze planul de conturi al benficiarului precum si alte treburi ce tineau de bucataria interna a acestuia. Deoarece oamenii beneficiarului erau slabi pregatiti acestia nu erau in stare sa furnizeze echipei de proiect datele necesare pentru implementarea modulul de contabilitate. Ei bine consultatii din echipa au inceput practic sa-i reorganizeze intr-un mod coerent beneficiarul inregistrarile contabile tocmai pentru a-si usura lor munca lor. Toate bune si frumoase dar proiectul a inceput sa intarzie si beneficiarul cu tupeu a inceput sa ceara penalizari. Pana la urma dupa un schimb mai dur de replici scandalul s-a aplanat. Gresala desigur a fost a managerului de proiect care trebuia sa opreasca proiectul si sa introduca o cerere de schimbare si dupa aprobarea ei sa reorganizeze proiectul.In cazul de fata evident membrii echipei de proiect si-au depasit obligatiile pe care le aveau prin contract si au oferit practic consultanta pe gratis.
Al doilea exemplu care imi vine in minte este unul de data recenta in care am fost implicat in mod direct. Un beneficiar dorea sa-si upgradeze sistemul informatic. Desi contractul avea clauze clare privind obligatiile ambelor parti, au aparut disensiuni cu privire la migrarea unor aplicatii proprietare ale beneficiarului pe noua platforma. Deoarece aplicatiile nu erau perfect compatibile cu noua platforma membrii echipei au inceput de capul lor sa gaseasca solutii de compatibilizare. Evident aceasta era sarcina beneficiarului sa ia legatura cu producatorul aplicatiei si sa ceara suport pentru noua platforma.
Aceste exemple cred ca sunt destul de edificatoare in ceea ce priveste depasirea granitelor unui proiect. Dupa cum se vede in ambele cazuri depasire granitelor s-a facut oarecum inconstient din dorinta de face proiectul sa mearga mai departe. De aceia m-am gandit sa trag un semnal de alarma fiti cu ochii in patru si ca un granicer "Atentie la frontiere".
Sa ma explic putin. Exista tendinata fireasca a membrilor echipei ca in elanul creator si din dorinta de a-si face cat mai bine treaba de a face si lucruri care nu sunt treaba lor ci sunt in sarcina exclusiva a beneficiarului.
In vine in minte un proiect mai vechi in care am fost implicat mai mult colateral si in care am fost invitat sa-mi spun o opinie. In cadrul unui proiect de implementare ERP membrii echipei din dorinta de a-si face cat mai bine treaba au inceput sa-i reorganizeze planul de conturi al benficiarului precum si alte treburi ce tineau de bucataria interna a acestuia. Deoarece oamenii beneficiarului erau slabi pregatiti acestia nu erau in stare sa furnizeze echipei de proiect datele necesare pentru implementarea modulul de contabilitate. Ei bine consultatii din echipa au inceput practic sa-i reorganizeze intr-un mod coerent beneficiarul inregistrarile contabile tocmai pentru a-si usura lor munca lor. Toate bune si frumoase dar proiectul a inceput sa intarzie si beneficiarul cu tupeu a inceput sa ceara penalizari. Pana la urma dupa un schimb mai dur de replici scandalul s-a aplanat. Gresala desigur a fost a managerului de proiect care trebuia sa opreasca proiectul si sa introduca o cerere de schimbare si dupa aprobarea ei sa reorganizeze proiectul.In cazul de fata evident membrii echipei de proiect si-au depasit obligatiile pe care le aveau prin contract si au oferit practic consultanta pe gratis.
Al doilea exemplu care imi vine in minte este unul de data recenta in care am fost implicat in mod direct. Un beneficiar dorea sa-si upgradeze sistemul informatic. Desi contractul avea clauze clare privind obligatiile ambelor parti, au aparut disensiuni cu privire la migrarea unor aplicatii proprietare ale beneficiarului pe noua platforma. Deoarece aplicatiile nu erau perfect compatibile cu noua platforma membrii echipei au inceput de capul lor sa gaseasca solutii de compatibilizare. Evident aceasta era sarcina beneficiarului sa ia legatura cu producatorul aplicatiei si sa ceara suport pentru noua platforma.
Aceste exemple cred ca sunt destul de edificatoare in ceea ce priveste depasirea granitelor unui proiect. Dupa cum se vede in ambele cazuri depasire granitelor s-a facut oarecum inconstient din dorinta de face proiectul sa mearga mai departe. De aceia m-am gandit sa trag un semnal de alarma fiti cu ochii in patru si ca un granicer "Atentie la frontiere".
sâmbătă, 12 iunie 2010
Estimarea si planificarea proiectului
Azi doresc sa ma opresc asupra unei etape foarte importante in ciclul de viata al unui proiect si anume estimarea si planificare. Desi sunt doua lucruri total diferite acestea merg de cele mai multe ori mana in mana, practic in momentul in care incepi sa estimezi un proiect trebuie sa faci si o planificare a activitatilor acestuia cat de cat.
Dupa parerea mea planificarea si estimarea unui proiect este poate cea mai importanta faza pentru ca ceva prost conceput din capul locului cu siguranta va fi esec.
Acest fapt fiind stiut foarte multi manageri de proiect cad in capcana, si ajung sa exagereze facand estimari si planificari cat mai riguroase. Nu spun ca o estimare riguroasa este un lucru rau dar atunci cand incepi sa estimezi de exemplu colile de hartie si pixurile folosite sau sa planifici activitati de genul insurbarea unui surub cu siguranta ca ai intrecut masura. Aici se naste desigur intrebarea, pana unde mergem cu estimarea sau cu planificarea, pana la ce nivel de detaliu. Greu de raspuns, aici intervine cu siguranta si experienta acumulata in timp a managerilor si estimatorilor. Dar ce pot sa faca cei mai putin experimentati?
Intrucat si eu am trecut prin aceasta dilema pot totusi sa dau unele sfaturi bazate mai mult pe o experienta practica.
In primul rand apelati la bunul simt ( desi si aceasta este o aptitudine care se dezvolta cu timpul), ca in exemplul de mai sus daca ajungi sa estimezi coli de hartie si pixuri cu siguranta ceva e putred.
In al doilea rand bazati-va pe faptul ca intotdeauna estimatorii mai pun din burta la cel putin un 10% deci in final poti sa te bazezi pe o marja aproape sigura de 10% daca nu mai mult.
Atentie in primul rand la bani. In general toata lumea accepta intarzieri dar cand e vorba de bani toti incep sa scartaie.
Daca timpul este problema ci nu banii atunci asigarativa o marja suficienta de timp.
Atentie la activitatile care se pot desfasura in paralel. Daca o activitate s-a incheiat mai devreme decat era planificat nu dormi linistit satisfacut ca esti in grafic, revizuieste diagrama de activitati si vezi daca nu poti faci o planificare mai buna cu alte cuvinte incearca sa castigi timp tot timpul. Daca termini mai devreme nu-i nici-o problema prefate ocupat si da un liber membrilor echipei ca sa fiti toti fresh cand beti sampania de final.
Dupa parerea mea planificarea si estimarea unui proiect este poate cea mai importanta faza pentru ca ceva prost conceput din capul locului cu siguranta va fi esec.
Acest fapt fiind stiut foarte multi manageri de proiect cad in capcana, si ajung sa exagereze facand estimari si planificari cat mai riguroase. Nu spun ca o estimare riguroasa este un lucru rau dar atunci cand incepi sa estimezi de exemplu colile de hartie si pixurile folosite sau sa planifici activitati de genul insurbarea unui surub cu siguranta ca ai intrecut masura. Aici se naste desigur intrebarea, pana unde mergem cu estimarea sau cu planificarea, pana la ce nivel de detaliu. Greu de raspuns, aici intervine cu siguranta si experienta acumulata in timp a managerilor si estimatorilor. Dar ce pot sa faca cei mai putin experimentati?
Intrucat si eu am trecut prin aceasta dilema pot totusi sa dau unele sfaturi bazate mai mult pe o experienta practica.
In primul rand apelati la bunul simt ( desi si aceasta este o aptitudine care se dezvolta cu timpul), ca in exemplul de mai sus daca ajungi sa estimezi coli de hartie si pixuri cu siguranta ceva e putred.
In al doilea rand bazati-va pe faptul ca intotdeauna estimatorii mai pun din burta la cel putin un 10% deci in final poti sa te bazezi pe o marja aproape sigura de 10% daca nu mai mult.
Atentie in primul rand la bani. In general toata lumea accepta intarzieri dar cand e vorba de bani toti incep sa scartaie.
Daca timpul este problema ci nu banii atunci asigarativa o marja suficienta de timp.
Atentie la activitatile care se pot desfasura in paralel. Daca o activitate s-a incheiat mai devreme decat era planificat nu dormi linistit satisfacut ca esti in grafic, revizuieste diagrama de activitati si vezi daca nu poti faci o planificare mai buna cu alte cuvinte incearca sa castigi timp tot timpul. Daca termini mai devreme nu-i nici-o problema prefate ocupat si da un liber membrilor echipei ca sa fiti toti fresh cand beti sampania de final.
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.
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.
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.
Abonați-vă la:
Postări (Atom)
