by Ok, esti PMP. Adica un Project Manager profesional. Si inainte ai fost Project Manager insa acum se presupune ca faci Project Management in mod profesionist, dupa reguli si principii. Si inainte conduceai si finalizai proiecte, cu succes desigur. Insa acum incep sa se deschida ochii si sa rememorezi episoade relevante din activitatea ta anterioa de PM ‘amator’, episoade nu atat de reusite…
Ce n-am facut in cutare moment cand acest lucru a dus la nemultumirea sponsorului?
Aaaa, da, acum stiu, n-am avut un plan de comuniare caci am uitat sa-l informez despre evolutia proiectului; eu trageam din greu, insa toate parca se gramadisera pe mine atunci si efectiv am uitat sa mai trimit statusul. Pe care de altfel il trimisesem anterior de cateva ori asa cand ma simteam eu ‘in the mood’ insa de data asta chiar am fost ocupat, si dealtfel nu stiu ce s-a enervat asa sponsorul, ca doar s-a muncit si nimeni n-a stat degeaba.
Daca as fi avut un plan de comunicare as fi stiut cu siguranta cand, ce si cum sa trimit, iti zici tu acum in sinea ta, bucuros ca ai identificat radacina problemei si solutia ei, dand relaxat un Join pe un grup de PM de pe Linkedin, ca sa fie bine.
Sau ce trebuia sa fac in cutare moment, cand acest lucru a dus la reactii negative din partea utilizatorilor legat de produsul proiectului care a fost respins in momentul dezvelirii lui?
Poate ca trebuia sa fac cu ei scope verification mai des, sa ii fi tinut aproape de dezvoltarea produsului si sa le fi gestionat asteptarile sau sa fi initiat change requests, sa fi chemat integrated change control, sa fi implementat corrective actions inainte de a fi prea tarziu.
Si uite asa incepi sa faci conexiuni si sa iti proiectezi experientele anterioare (mai ales cele nereusite) peste tabelul cu cele 42 de procese de PM ale lui Mendeleev si sa iti dai seama ce ai facut (bine sau nu) sau mai bine zis ce n-ai facut deloc.
Ce as recomanda eu celor care tocmai sau certificat (si nu numai), ca unul ce am trait si traiesc pe deplin chinurile transformarii din omida paroasa in molie si apoi in fluture cu aripi mari si multicolore pe care scrie PMP:
- In primul rand sa ai foarte clar in cap separarea activitatilor de PM de cele care duc la realizarea nemijlocita a produsului proiectului (operationale); putini sunt fericitii care traiesc intr-o organizatie matura din punct de vedere PM. Majoritatea evoluam in niste medii care considera managementul de proiect ca fiind una din multele sarcini pe care cineva trebuie sa le indeplineasca.
Adica PM-ul care face 100% PM in activitatea lui zilnica trebuie sa se considere un fericit si un ales. In practica esti numit PM insa trebuie in numeroase cazuri ‘sa pui osul’, muncitoreste, lucru care de multe ori takes you off balance adica te confuzeaza si nu stii cand sa te opresti din operational si sa te transferi in PM.
Intotdeauna sa-ti fie clara postura in care te aflii; ce fac eu acum, cine sunt? Sunt project managerul acestui proiect sau sunt una din resursele activitatii X?
Si tine minte, un PM Professional face in mare parte a timpului doar PM asa ca si tu trebuie sa te straduiesti sa faci la fel, incearca sa te rupi din executia propriuzisa a produsului proiectului.
- Incearca sa gandesti PMBOK-istic; ai 42 de activitati; ce fac eu acum? Orice gest, miscare sau respiratie de-a ta trebuie s-o poti incadra/s-o proiectezi intr-una dintre cele 42. Vei observa ca acest lucru iti aduce un confort mental cum ca esti in control, te-ai gandit la toate si stii ce urmeaza. La inceput depui efort apoi vine de la sine.
What is ‘The Answer To Life, The Universe, And Everything’? 42, evident (pentru cei ce cunosc povestea). Iar eu nu cred in coincidente!
De exemplu esti intr-un proiect in care trebuie sa livrezi o aplicatie de emitere de facturi si vine un stakeholder la tine la tine cum ca mai vrea sa apara o floricica embosata pe fiecare factura acolo unde clientul are un istoric de bun platnic pe ultimele 6 luni de zile. Tu ca PM ‘amator’ realizand imediat ce inseamna asta, iti vine sa ii faci ceva pe loc astfel incat sa nu mai vina nicodata cu nici o cerinta, ever. Ca PM Professional insa ai un declick mental si raspunzi cu un zambet discret: sigur, e o idee excelenta, hai sa urmam change management planul, pune in scris exact ce inseamna asta, cum vrei sa se intample (adica fa un change request formal – lucru firesc, output firesc de la Direct si Manage Project Execution, ne asteptam sa se intample in orice proiect acest lucru) iar apoi (imediat cand specialistii se vor elibera – nu acum pe loc ca nu sunt pompieri) o vom analiza din punct de vedere time, cost etc (adica vom face Integrated change control) si iti vom prezenta rezultatele (adica vom face change request status update). Aint that beautiful? In plus de multe ori cand il pui sa scrie ce vrea, fuge si nu mai vine.
Sau iesi in curte acolo unde doi membrii din echipa de proiect sapau o groapa “si-asa lunga si-asa lata” (http://www.youtube.com/watch?v=YB0umK0PWyQ) si ii urmaresti, la mimica, la reactii, la vorbe etc. ii intrebi ce mai fac cum se simt, de sanatate, de campionat…; ce faci in acel moment? Simplu, faci Observation and Conversation dezvoltand echipa. Dupa care te uiti la groapa daca-i lunga, daca-i lata (asa cum se specifica in Project Scope Statement); ce faci in acel moment? Clar, inspection (de la perform Quality Control); si pentru ca PM-ul e acolo ‘to be of service’ vorba Ritei, mai primeste si niste intrebari “…păi unu pune o-ntrebare/ce facem cu pământul care/rezulta de la sapare”, moment in care incepi sa te ingrijorezi putin: o asemenea intrebare nu trebuia pusa in mod normal; muncitorul trebuia sa aiba agatat de gat actvity list-ul pentru ziua respectiva. Tu deschizi mapa si rasfoiesti la project schedule si vezi ce activitati succed saparii gropii; daca nu zice nimic acolo, inseamna ca wbs-ul e prost, s-au omis work pakageuri; daca se specfica totusi, trebuie sa revizuiesti planul de comunicare si sa vezi de ce informatia nu a ajuns la muncitor. Vezi cum se leaga? Adica tot ce faci ca PM e bine sa incadrezi in tabelul celor 42 de elemente. Te ajuta sa nu uiti ceva din indatoririle tale de PM, iti da siguranta ca ceea ce faci e ceea ce trebuie si numai ceea ce trebuie, ca PM.
- Putini sunt PM-ii care au experienta in mai multe domenii si de obicei ne specializam pe un anume segment; eu de exemplu am facut toata viata mea sisteme informatice; altul a facut proiecte de dezvoltare organizationala, whatever that means. Altul a condus proiecte de constructii, altul de inginerie. Astfel fiecare stie in detaliu specificul si ciclul de viata al produsului pentru care a condus proiectele. Fiecare din aceste proiecte are outputuri/milestoane specifice si este foarte indicat ca fiecare sa realizeze o corespondenta intre acestea si outputurile din cele 42 de activitati de PM.
Sa iau exemplul proiectele de implementare de sisteme informatice; toata lumea din aceasta bransa cred ca face documentarea cerintelor beneficiarului. Cate organizatii, metodologii si pemei, atatea denumiri pentru acest document. Insa el are o corespondenta sigura si ferma in “Requirements documentation” de la procesul de “Collect requirements”; ok poate ca aici corespondenta e evidenta. Sa luam UAT-ul (User Acceptance Testing) – ca proces de data asta; care e corespondenta lui? Scope Verification as zice. Iar formularele de acceptanta a procesului de UAT ar putea fi considerate “Accepted Deliverables”. Prinzi ideea unde bat? E vorba de un mindset.
Incearca sa gasesti o corespondenta dinre outputurile/milestoanele proiectele tale zilnice si toate outputurile celor 42 de procese. Rezultatul: visible peace of mind pentru ca atunci iti vei da seama cum trebuie executate cel mai eficient activitatile proiectului si cum trebuie urmarite si produse livrabilele avand ca reper best practice-urile promovate de PMBOK.
Agata-te si lasa-te condus de flowul lin al celor 42 de procese (cu inputurile, T&T-urile si outputurile fiecaruia) din PMBOK, leaga-le de concretul si specificul proiectului tau si nu vei gresi, nu vei omite nimic, nu vei lasa nimic in urma si, mai ales, vei fi relxat, lucru mare pentru un PM.
Alte sfaturi, intr-o ordine aleatoare:
- Warm and fuzzy; de multe ori PM-ul intalneste situatii neclare, in care se pot identifica unele probleme insa ele sunt esompate de o senzatie de “stiu ca nu e gata azi asa cum ar fi trebuit da las’ c-o sa fie bine, uite tragem tare si maine e gata”. Tu trebuie sa dai statusul la sponsor (care vrea semafoare, nu promisiuni de genul asta), ce faci? Rosu, Galben sau Verde? Sfatul meu, Rosu all the way. Nu e gata, simplu, indiferent de cat se jura echipa ca uite ce putin mai e pana sa fie gata.
In general PM-ul trebuie fie clinic si sa se straduiasca ca din paienjenisul de informatii care i se arunca (mai mult sau mai putin involuntar) sa taie si sa transeze informatii simple si relevante; ‘Da’ sau ‘Nu’, asa se discuta. Clar si fara echivoc. Daca ‘Nu’, de ce? Care e root cause?
- What’s next; PM-ul e aruncat uneori intr-o valtoare de evenimente si se asteapta de la el sa dea directie, sa spuna ce urmeaza, ce trebuie facut. Cea mai neplacuta senzatie e sa vezi un PM care nu stie ce are de facut in continuare sau emana nesiguranta. De multe ori m-am simtit in aceasta ipostaza. Recomand doua abordari (presupunand ca suntem inainte de scope/time planning):
- Prima e ‘know your 42’ – plaseazate in tabelul lui Mendeleev de procese si vezi unde te afli iar ele te vor ghida
- Foloseste-te de prerogativele tale; cheama echipa la o discutie informala si intreaba-i ca pe niste specialisti ce sunt, care e parerea lor, ce trebuie facut, fara rusine, recunoaste-le valoarea. Imi vine in minte figura lui Leonardo DiCaprio din “Catch me if you can” cand se pretindea doctor si a fost pus in fata unui caz grav, lumea astepta guidance de la el si evident ca el habar n-avea ca era un impostor. Ce a facut? Simplu, a chemat pe doctori si i-a intrebat direct “tu ce-ai face in aceasta situatie?”. Visul meu e sa fiu un PM de succes fara sa stiu nici un pic despre ciclul de viata specific al prosusului/proiectului respectiv, adica sa ma bazez doar pe abilitatile de organizare, leadership, comuniare etc.
- Organizatia proiectului, roluri si responabilitati. Foarte multe probleme apar (in proiecte mai mici, cand formalizarea project managementului nu e atat de mare) de la lipsa definire clara a unei organizatii de proict si a rolurilor si responsabilitatilor; de la inceput asigura-te ca proiectul are o echipa si ca fiecare isi cunoaste rolul. Daca nu, te vei trezi la un moment dat ca toata lumea a fugit si ca ai ramas singur. Lipsa de definire clara a responsabilitatilor este, pentru un membru al echipei care are si alte indatoriri zilnice pe langa proiect, precum umezeala pentru mucegai; abia asteapta sa scape si sa zica ca n-a stiut sau ca nu i s-a spus. Si inca ceva: sponsorul e unul singur, la fel si project managerul. Astea sunt roluri care nu se pot imparti. Mai sunt cazuri in care unii vor sa se sustraga si dupa numele lor mai pun un slash si apoi pe altcineva, vezi Doamne se completeaza reciproc. Nu cadea in aceasta capcana, pe cat se poate. Responsabilitatea e indivizibila.
- Stakeholderii; nu este un bla bla – desi ti se poate parea ca sunt alte lucruri mai importante de facut, investeste timp consistent in identificarea stakeholderilor; iti vei multumi la sfarsit cand vei constata ca n-a sarit pe tine nici un sarpe din tufisuri pe parcursul proiectului, cee a ce nu este putin lucru.
- Cunoaste-ti puterile; daca cineva te-a pus PM, act as one. Acest rol iti da puterea de a discuta de la egal la egal cu greii din companie si de a negocia cu ei. Cunoaste-ti calea si lupta-te sa ramai pe ea caci multi vor incerca sa te impinga in afara ei. Fi ferm pentru ca e singura ta sansa de a duce lucrrile la bun sfarsit. Ai puterea de a chema sedinte, de a schimba destine, de a muta resurse si munti, do it. Know your power. Daca te blochezi escaladeaza, cere ajutorul sponsorului.
- “Balegarul vanturat se transforma in ingrasamant iar cel bagat sub pres se impute” si nimeni nu vrea miros neplacut; acest citat l-am retinut odata de la un mare sponsor… Transforma problema, daca nu intr-o oportunitate, intr-o situatie in care si altii isi asuma din responsabilitate si pun umarul la rezolvare. Nu o tine sub pres ca intrun final doar tu te vei impiedica de ea. Chiar daca e vina ta in principal, pune accentul pe rezolvarea ei, arata-te intens preocupat de acest lucru si mai putin de greutatea vinei; cu timpul lumea va uita, bucurandu-se de succes.
- ABC, Always Be Closing; asta e si un indemn de viata… personal nu am prea inteles la inceput cand invatam de PMP ce tot se pune accent pe inchiderea fazei; ma rog, cu inchiderea proiectului mai treaca mearga, dar in rest ce tot atata inchidere? Insa mai tarziu am inteles pe pielea mea ca totul trebuie finalizat formal; milestoanele trebuie acceptate formal, proiectul/faza trebuie inchisa. Oamenii isi aduc aminde de ceea ce inseamna responsabilitate. De multe ori lucrurile incep sa treneze, nu mai sunt resurse, nevoia proiectului dispare iar lumea tinde sa lase lucrurile in coada de peste. Tu insa trebuie sa le inchizi, indiferent daca e vorba de un succes sau nu.
Intr-un context mai general, asta inseamna si ca la sfarsitul unui proces, discutii, etc. sa fortezi concluzii, decizii, actiuni, agreement, semnaturi, validari, etc.
Multe se pot spune insa doar atat mai vreau sa amintesc: cunoaste raspunsul la viata, la univers, la orice – 42.
Un mic disclaimer: toata aceasta expunere s-a nascut din galceava unui proaspat PMP cu organizatia functionala, pentru care project managementul e ceva ce e bine sa fie pe acolo insa pentru care nu aloca deloc resurse si timp. Adica it may not apply to everyone.
