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”.

Acum să trecem la lucruri poate mai puţin interesante pentru voi, dar importante pentru mine. 4 ianuarie 2009 este data publicării primei însemnări pe acest blog – prin urmare azi bea şampanie sarbatorindu-şi primul anişor. Cam ignorat de multe ori de proprietară şi targetand un public poate prea ocupat cu alte activităţi decât cititul de bloguri, PMin.RO îşi face astăzi un platouaş cu cele mai savurate articole din primul său an:

- detaşat că şi număr de vizite, interviul cu 3 fete cucuiete. Încă nu mi-am făcut curaj pentru un articol cu 3 domni, dar am timp în 2010

- absolut contestat prin comentarii, interviul prin care am încercat să expun puţin mai mult din culisele MPI – ASE

- primul articol ca şi PMP – se pare că aţi fost curioşi să aflaţi cum e la examinare

- primul articol din seria “FM vs PM”

- un articol generat de ‘shpe persoane, mai încerc.

Pentru că am un oarecare simţ al echilibrului – cel mai neinteresant pentru voi a fost faptul că am schimbat templeta de design

Melaniei, Ioanei şi lui Daniel trebuie să le mulţumesc pentru cel mai mare aport extern adus traficului pe PMin.RO ( în ordine descrescătoare). Tot la capitolul mulţumiri îi înscriu şi pe cei care s-au abonat, cuminţi, la RSS.

Nu am planuri mari pe 2010 cu blogul, o luăm încet şi vedem unde ajungem. Sper totuşi ca anul acesta să citesc mai multe articole de profil scrise în limba romană.

Timeline cu toate mesele în familie, vizitele la neamuri şi vecini, chermezele sociale, bautele cu prieteni vechi. E greu să sincronizezi atâţia oameni cu atâtea dorinţe şi pretenţii.

Mai era ceva ?

Să aveţi Sărbători Fericite, să vină Moşu’ cu sacul plin, şi să vă relaxaţi cât mai mult în aceste zile. Să nu vă cadă greu mâncarea, să nu vă rămână maşinile blocate în zăpadă pe unde veţi merge, să găsiţi tot ceea ce căutaţi, acolo unde vă doriţi să fie!