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".
Abonați-vă la:
Postări (Atom)
