Stim cu totii ca in cadrul unui proiect avem de interactionat cu mai multe tipuri de stakeholderi, incepand cu project sponsor-ul, steering committee, pana la colegii de echipa.

In cadrul procesului de comunicare, o componenta importanta este partea de raportare de status.
Un template foarte util pentru aceasta activitate gasiti disponibil pentru download aici.

Principalul avantaj este ca acest document poate fi adaptat pentru oricare nivel de intelegere si/sau decompozitie a proiectului.

—————————————————————————————————————————————-

*Mihnea are experienta ca Project Manager in online de peste  cinci ani si un număr impresionant de proiecte livrate pentru clienti  din Romania, Germania, Austria, SUA – în sectorul bancar, telecom,  retail, automotive si din sectorul public.

- alocare de resurse suplimentare (crashing). Un PM poate suplimenta resursele alocate daca activitatile au o natura care sa permita lucrul in echipa, si daca bugetul proiectului permite o astfel de “extravaganta”. Nu uitati gluma cu managerul de proiect care crede ca 9 femei pot naste un copil in 1 luna .

- simultaneitate (fast tracking). Foarte pe scurt: in loc sa astepti finalizarea activitatii A ca sa incepi activitatea B, le desfasori in paralel. Desigur, ai nevoie de o analiza care sa iti arate daca natura activitatilor permite o astfel de abordare (intreaba echipa!)

- reducere de scope. Poti sa negociezi cu clientul/sponsorul renuntarea la unele functionalitati, si ar fi varianta preferata, celelalte doua comportand riscuri suplimentare pentru proiect.

Daca nu poti aplica niciuna dintre variantele de mai sus, anunta toate partile implicate (echipa, client, beneficiari etc) si pregateste-te sa iti asumi nerespectarea termenului.

Cine a luat pana acum contact cu vreun materiale despre/de la PMI, sigur a auzit termenul de PMI-ism. Ce inseamna pe scurt? Niste afirmatii cheie la care prestigioasa institutie tine foarte mult. Din viata de zi cu zi, recomand sa vedeti comentariile mele la:

- Gold plating is a sin – Asta e pe bune – “intinde un deget si ti se ia toata mana”.

- PM skills are transferable to any industry, you do not need industry-related skills – Mai greu. Desi personal am lucrat ca si PM in event set-up, constructii, si web mi-am dat seama ca daca nu simti un pic industria ai multe zone sensibile in care poti derapa.

- Confrontation is the best way in conflict resolution – De retinut: “Confrontation” insemana rezolvarea problemei.

- PM is the most important job in the world – Sa lasam pe altii sa laude aceasta meserie .

- PM is proactive – managing change, a powerful decision maker, spent >90% of his/her time communicating – Important. Comentarii si semne de intrebare doar la partea de decizii…as intreba mai intai macar in ce tip de organizatie activam. Si chiar daca este projectized, tot as zice ceva mai safe in loc de “powerfull” .

- Scope, roles and responsibilities need to be clearly defined – Cel mai important dintre pmi-isme si cel mai aplicat. Impreuna cu wbs, wbs, wbs este cel mai usor mod de a tine sub control un proiect.

- WBS WBS WBS – Fara el nu se poate. Nu incepeti nici o conversatie cu stakeholderii fara un minim de highlevel wbs. Este ca si cum v-ati duce la piata sa cumparati ingrediente pentru un fel de mancare, dar nu stiti care.

- *PMI-ism (ne)favorit : without PMP you are not a PM

—————————————————————————————————————————————-

*Mihnea are experienta ca Project Manager in online de peste  cinci ani si un număr impresionant de proiecte livrate pentru clienti  din Romania, Germania, Austria, SUA – în sectorul bancar, telecom,  retail, automotive si din sectorul public.

Este diferit managementul unui proiect web de managementul unui proiect de constructii sa zicem ?

Nu stiu care este parerea universal valabila, dar PMI spune in primele randuri ale PMBok-ului ca fiecare proiect este unic. Putem extrapola spunand ca fiecare dintre proiecte necesita o abordare adaptata de project management.

Status qvo

Proiectele in general necesita anumite adaptari ale tehnicilor consacrate de project management. Exista abordari de PM pentru web cu performanta dovedita , dar cele mai multe proiecte (si aici vorbesc de relatia agentie-client, nu de proiecte in-house ale publisherilor) duc lipsa de o abordare matematica a tuturor proiectelor.

Nimic rau la prima vedere, toata lumea este obisnuita sa modifice design, specificatii, aceste modificari se “prind” in estimari, se mai strang cu usa colegii de echipa pentru a mai lucra cateva ore in plus pe o bere si tot asa…

Desi colegii de peste ocean par in teorie sa accepte faptul ca sansele de a rata un proiect sunt cele mai mari la inceput,  un procent important de proiecte web par a scartai la finalul proiectului, cand deja resursele alocate au fost considerabile.

In loc sa analizez situatia, parca as pune 3 intrebari retorice:

1) Care este dimensiunea proiectului ? ore/om , buget alocat .

Calculul numarul 1: ore/om total * 20 % = ore MINIME necesare de project management

2) Cine sunt toti stakeholderii din proiect?

Calculul numarul 2: planul de comunicare al proiectului : n*(n-1))/2 si pe fiecare din acest canal … emails, telefoane, sedinte interne…

3) Intrebarea care genereaza concluzia si reactia:  Acopera cei 20% de la punctul 1 macar nevoile de comunicare ale proiectului ?

—————————————————————————————————————————-

*Mihnea are experienta ca Project Manager in online de peste cinci ani si un număr impresionant de proiecte livrate pentru clienti din Romania, Germania, Austria, SUA – în sectorul bancar, telecom, retail, automotive si din sectorul public.

- În cazul în care proiectul are cerinţele foarte detaliate şi clare, termene flexibile, foloseşte tehnologii bine cunoscute, prezintă un grad de complexitate scăzut şi schimbările în specificaţii sunt puţin probabile, atunci ai putea fi mai bine deservit în activităţile de project management de o abordare tradiţională a managementului de proiect (de exemplu: PMBOK Guide, Prince2 , Waterfall, Props).
- În cazul în care proiectul are cerinţele flexibile, termene strânse sau fixe, implică un grad sporit de inovaţie, tehnologii noi sau complexe, ori prezintă risc ridicat de schimbare a specificaţiilor, atunci ar trebui să încerci o abordare Agile (de exemplu: XP, Scrum, Crystal, DSDM).

În concluzie, important e să îţi pui întrebările corecte înainte de a îmbrăţişa o metodologie care nu se potriveşte proiectului tău. Mai dureros este că nicio metodologie de project management nu va face toate problemele tale să dispară, şi în acelaşi timp niciun proces nu ar trebui să devină mai important decât proiectul în sine, deci încearcă să nu faci din metodologie un scop distinct, ci doar să priveşti metodologia ca instrument ce te poate ajuta.

Clientul se schimbă – devine mult mai exigent în ceea ce priveşte studierea ofertelor, îşi doreşte proiectele livrate şi mai repede, şi mai ieftin, şi asta nu doar din cauza crizei, ci pentru că aceasta este evoluţia firească în business. Viteza cu care aceste schimbări se produc face ca multe dintre companii să treacă de la procese operaţionale la o orientare mult mai focusată pe lucrul cu proiecte. Tot viteza de schimbare este în acelaşi timp şi unul dintre motivele pentru care un procent prea mare de proiecte eşuează în a-şi atinge obiectivele în parametrii iniţiali de timp, cost ori calitate.

Multe dintre aceste eşecuri sunt datorate unei abordări heirupiste a proiectului, care are la bază lipsa unei metodologii formale acceptată, susţinută şi practicată de întreaga echipă. Fără adoptarea unei metodologii clare sau a unui cadru pentru livrare, cele mai multe echipe de proiect încep construirea rezultatelor preconizate înainte de a avea foarte clar definită sfera lor de aplicare ori obiectivele. Echipele resimt lipsa unor procese structurate- cadru al activităţilor proiectului, nereuşind să gestioneze în mod eficient timpul, costul, calitatea, riscurile, problemele sau schimbările din cadrul proiectului. Este inevitabil ca aceste proiecte să sufere din cauza întârzierilor, a slabei calitati a livrabilelor, din lipsa domeniul de aplicare, conducând la o nemulţumire a clienţilor drept prima consecinţă. Folosirea unei metodologii în mod repetat pentru iniţierea, planificarea, execuţia şi închiderea proiectelor în mod eficient ar putea fi un prim răspuns la întrebările privind modurile în care rata de proiecte de succes se poate îmbunătăţi.

Care ar fi problemele majore ale companiilor care dezvoltă proiecte într-un cadru neorganizat, ca să nu zic haotic ?

- proiectele îşi ating obiectivele într-un procent insuficient

- viziunea asupra proiectului este diferită între membrii echipei de dezvoltare

- nu se pot face estimări realiste asupra efortului depus

- aceste proiecte sunt de multe ori planificate în neconcordanţă cu obiectivele companiei

- transparenţa în cadrul acestor proiecte este scăzută (unori se poate vorbi chiar de opacitate)

- este cazul proiectelor care implică într-o măsură mult prea mică utilizatorul final

- livrarea acestor proiecte nu creşte gradul de satisfacţie a clientului, din contră

- proiectele nu se pot adapta în funcţie de schimbările apărute în perioada dezvoltării

- aceste proiecte îşi ating cel mai rar deadline-urile, nu îşi respectă aproape niciodată bugetele iniţiale, nu au o rentabilitate crescută a investiţiei.

Care ar fi soluţia?

- Project manageri care îşi scriu singuri metodologiile. Ştiu că se lasă cu protest – nu au timp de scris metodologii, au proiecte de livrat. Şi-atunci?

- Project manageri care se bazează pe bunele practici ale industriei în care activează. Şi totuşi, fiecare proiect este unic prin definiţie, şi atunci bunele practici nu vor fi niciodată suficiente pentru a susţine livrarea cu succes a unui proiect ce comportă o serie întreagă de particularităţi.

Cert este că în prea multe dintre ocazii project managerii sunt puşi în situaţia de a începe dezvoltarea unui proiect fără a avea resursele necesare dezvoltării unui cadru potrivit, care să le asigure livrări de succes.

- când s-a introdus compoziţia la cuptor – e gata din punct de vedere al domnei sau domnişoarei care a muncit la compoziţie

- când s-a finalizat coacerea – e “gata” din punct de vedere al persoanei care a supravegheat procesul

- când consumatorul, sătul de atâta prăjitură, laudă creaţia şi ovaţionează creatorul cu un “sărut mâna pentru masă”

- când tava e goală şi unicul lucru la care se mai gândeşte cineva din punct de vedere gastronomic este alegerea reţetei pentru următoarea.

Nu, eu nu fac prăjituri, dar cunosc câteva doamne care sunt în posesia unor reţete absolut delicioase. Eu sunt consumator – pentru mine prăjitura este “gata” după ce am mulţumit pentru porţie.

Paralela la proiecte, şi la modul în care definim, în mod evident diferit, conceptul “gata” – un proiect capătă acest atribut cel puţin în următoarele ocazii:

- când business analyst-ul şi arhitectul au pus ultimul punct în specificaţii

- când developerii/integratorii de sistem consideră că au pus şi ultimul caracter în sintaxa

- când echipa de testare şi-a dat ok-ul final

- când clientul constată că cerinţele au fost complet îndeplinite

- când utilizatorul final are acces la funcţionalităţi.

În mod curent echipa de proiect are în componenţa sa cel puţin câte un membru din cei menţionaţi mai sus, şi atunci definirea unanim acceptată se constituie în muncă de mediere pentru project manager. În condiţiile în care este responsabilitatea project managerului să conducă proiectul catre stadiul final, este esenţial ca în fazele incipiente ale dezvoltarii acestuia întreaga echipă să aibă aceeaşi înţelegere a cuvântului “gata”.

Ce am văzut însă la prima întâlnire PMI România Chapter la care am putut să particip a fost în linii largi fix ceea ce ar trebui să fie o asociaţie profesională – oameni cu profil asemănător din punct de vedere profesional, strânşi în acelaşi loc şi discutând în pauze despre teme care privesc project managementul sau asociaţia în sine. Între pauze s-au ţinut prezentări ale candidaţilor pe posturile libere din board, s-a văzut în mod evident o încercare de contestare sau măcar punere sub semnul întrebării a validităţii rezultatelor (că suntem români şi în PMI Ro Chapter), s-au făcut publice rezultatele şi s-a prezentat şi versiunea iniţială de raport anual.

Ce mi-a plăcut şi ţin să subliniez este faptul că nu se făceau discriminări pe bază de vârstă, nivel de experienţă etc. Sunt unul dintre cei mai tineri români certificaţi PMP şi membru PMI România Chapter de aproximativ jumătate de an. Ca atare am acordat tot respectul cuvenit (pe lângă doza de admiraţie pe plan profesional) veteranilor PMI România Chapter, şi am primit o reacţie ca de la egal la egal, lucru care m-a făcut să mai cresc un pic nivelul de încredere în forţele proprii.

Ce nu mi-a plăcut – mă aşteptam la mai mult de 35-40 de persoane prezente, dar fiind decembrie şi lumea ieşind din casă doar pentru cadouri şi ultimele cumpărături, e de înţeles. Poate data viitoare ne vom aduna mai mulţi.

Rezultatele alegerilor le găsiţi aici.

Mai mult decât atât, teoria de project management tradiţională include 4 etape standard prin care un proiect îşi urmează drumul către deadline, şi un sistem de control. Practic, cam toate metodologiile au la bază delimitarea activităţilor cam în modul următor: iniţiere, planificare, execuţie şi închidere. Simultan cu planificarea şi execuţia se suprapune un sistem de monitorizare şi control al activităţilor. Fiecare dintre aceste etape presupune un număr de procese desfăşurate de către echipă împreună cu PM-ul (PMI chiar defineşte aceste etape că “grupuri de procese”).

Şi-atunci logica mea devine cam aşa: PM = Project Owner şi Project = suma rezultatelor proceselor, rezultă că Project Managerul este Process Owner, sau ba?