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!

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.

Drept este că un PM nu are ca si primă calitate creativitatea, prin urmare există multe situaţii în care nici nu o apreciază.

Poate aţi văzut de curând un video cu project manageri sau despre project management care v-a plăcut? Lăsaţi un link la comentarii şi rămân datoare

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?

- să livreze la timp – Time Management

- să livreze în buget – Cost Management

- să livreze conform cerinţelor – Scope Management

- să livreze calitate – Quality Management

- să aibă clienţi mulţumiţi – (Stakeholder &) Communications Management

- să aibă echipă mulţumită – HR & Communications Management

Ce îi mai trebuie?

- să fie conştient de existenţa riscurilor, capabil să anticipeze şi să planifice reacţii la producerea lor – Risk Management

- să poată oricând să analizeze avantajul sau dezavantajul subcontractarii – evident, să ia decizii în consecinţă – Procurement Management

- să poată integra informaţia, schimbările, în aşa fel încât obiectivele (cele 5 de mai sus) să fie îndeplinite – Integration Management.

Şi totuşi, fiecare dintre noi, în funcţie de specificul domeniului în care profesează, neglijează mai mult sau mai puţin, măcar una dintre aceste arii. Pe care, şi de ce ?