Scrigroup - Documente si articole

     

HomeDocumenteUploadResurseAlte limbi doc
ComunicareMarketingProtectia munciiResurse umane

FINALIZAREA PROIECTULUI

management



+ Font mai mare | - Font mai mic



FINALIZAREA PROIECTULUI

Metodologia incheierii unui proiect



1.1 Sarcinile managerilor de proiect in faza finalizarii proiectului

1.2 Procesul de finalizare a proiectului

1.3 Forme de finalizare a proiectului

1.4 Etapele finalizarii propriu-zise a proiectului

1.5 Dizolvarea echipei de proiect

1.6 Inchiderea bazelor de date

1.7 Finalizarea activitatilor

2. Documentatia de inchieiere a proiectului

2.1 Istoria proiectului

2 Auditul postimplementare si raportul final

2.3 Recompensarea succesului si invatarea din greseli

3. Succesul sau esecul proiectului

3.1 Definirea succesului sau esecului unui proiect

3.2 Produs final, rezultate si asteptari

3.3 Rezultatele cercetarilor

3.4 Factori care contribuie la succesul perceput al unui proiect

3.5 Factori care contribuie la esecul perceput al unui proiect

3.6 Obiective si abateri

  1. Metodologia incheierii unui proiect

Sa presupunem ca planificarea si implementarea proiectului s-au incheiat.

Suntem deci in etapa in care acesta ajunge la finalul ciclului de viata al proiectului. Dar cine decide finalizarea unui proiect si cum ? Raspunsul il veti putea gasi in paginile urmatoare, in care va fi tratat acest subiect.

Atingerea rezultatelor si obiectivelor stabilite in etapa de planificare a proiectului semnaleaza faptul ca, cel putin din perspectiva indeplinirii planului, proiectul trebuie incheiat.

In ciuda apropierii de finalul ciclului de viata al proiectului, volumul de munca este ridicat. Entuziasmul caracteristic demararii proiectului este scazut, membrii echipei sunt preocupati de revenirea la sarcinile anterioare proiectului, sau de responsabilitatile legate de viitorul proiect la care vor participa.

Etapa finala a proiectului reprezinta o piatra de incercare pentru managerii de proiect. Din anumite puncte de vedere, dificultatile cu care se confrunta managerii sunt mai mari decat cele intalnite in alte faze ale ciclului proiectului.

Sarcinile managerilor de proiect in faza finalizarii proiectului

Asa cum am mai precizat, pentru a fi eficient, managerul de proiect trebuie sa aiba

capacitatea sa conduca, sa comunice, sa motiveze, si sa negocieze. In aceasta faza a proiectului, aceste calitati sunt la fel de mult solicitate ca si celelalte etape ale ciclului de viata al proiectului.

De exemplu, managerul de proiect trebuie sa conduca si sa motiveze o echipa de proiect al carei numar este in scadere. Sarcina managerului este cu atat mai dificila, cu cat cei care urmeaza sa paraseasca echipa isi pierd interesul fata de sarcinile ramase si manifesta un nivel scazut de motivare. In plus, ei pot fi preocupati mai mult de viitorul lor personal, decat de succesul proiectului.

O alta sarcina dificila a managerului de proiect este, in aceasta faza, comunicarea cu stakeholderii. Conducerea organizatiei client demonstreaza un interes din ce in ce mai scazut fata de proiect. Prezenta managerilor organizatiei client la sedintele de proiect este din ce in ce mai redusa, iar ei sunt mai putin disponibili pentru consultare, decat in primele etape ale proiectului. In schimb, creste interesul compartimentelor operationale fata de proiect si fata de detaliile legate de rezultatele acestuia.

In ciuda dificultatilor inerente, managerii trebuie sa duca la bun sfarsit proiectul. Ei trebuie sa urmareasca obtinerea rezultatelor asteptate, sa verifice finalizarea contractelor si a comenzilor de lucru si sa supravegheze cesiunea sau conservarea activelor corporale utilizate in cadrul proiectului. Managerul de proiect trebuie sa realizeze toate acestea in timp ce echipa de proiect se micsoreaza, iar autoritatea sa este din ce in ce mai putin recunoscuta de catre stakeholderi. Din acest motiv, in cazul proiectelor deosebit de complexe, se opteaza pentru desemnarea, in mod special, a unor manageri responsabili cu finalizarea proiectului.

Procesul de finalizare a proiectului

Incheirea unui proiect implica finalizarea tuturor comenzilor de lucru, finalizarea

contractelor cu partenerii, disponibilizarea angajatilor, vanzarea, redistribuirea sau conservarea echipamentelor utilizate, eliminarea surplusului de resurse materiale etc.

Toate aceste activitati trebuie planificate si incluse in bugetul de cheltuieli, in mod similar celorlalte activitati de proiect. Intreruperea sau incheierea in mod neplanificat a proiectului conduce nu numai la nefinalizarea unor sarcini si la pierderi de informatii, dar, mai ales, poate diminua increderea clientului in echipa de proiect si in rezultatele acestuia.

Intrarile si iesirile procesului de finalizare a unui proiect sunt prezentate in figura 7.1.

Informatii de control  Arhiva

Echipa de proiect  Personal disponibilizat


Predarea si acordul 

formal al clientului Beneficii si invataminte

Active ale proiectului  Informatii cu privire la

rezultatul proiectului

Baza de date a proiectului Cedarea activelor utilizate in

cadrul proiectului

Figura 7.1 - Intrarile si iesirile procesului de finalizare a proiectului

Proiectul se poate incheia indiferent daca obiectivele stabilite in momentul demararii sale au fost atinse, sau nu. In acest ultim caz, nu va exista un proces de predare-primire a rezultatelor proiectelor, insa toate celelalte elemente ale procesului de finalizare se mentin. Registrele si documentatia proiectului se vor completa, baza de date se va arhiva, activele proiectului se vor ceda, sau se vor conserva, iar membrii echipei de proiect vor fi disponibilizati, sau repartizati pe alte posturi.

Finalizarea intr-o maniera organizata a proiectului permite participantilor sa invete din greseli si sa valorifice beneficiile obtinute prin participarea la realizarea proiectului.

Finalizarea proiectului vizeaza urmatoarele aspecte :

incheierea formala a relatiilor contractuale cu furnizorii, producatorii, clientii si alte terte parti care contribuie la realizarea proiectului si care solicita o instiintare prealabila a finalizarii proiectului ;

incheierea formala a responsabilitatilor echipei de proiect ;

obtinerea avizului clientului cu privire la activitatile si rezultatele proiectului ;

verificarea faptului ca activitatile si rezultatele proiectului s-au incadrat in termenele de executie, in limitele bugetelor si ale specificatiilor tehnice ;

colectarea informatiilor si completarea documentatiei ce poate fi utilizata in viitor pentru imbunatatirea altor proiecte ;

elaborarea si semnarea unui raport final, care sa demonstreze ca obiectivele proiectului au fost finalizate intr-o masura satisfacatoare ;

incheierea tuturor relatiilor interne si externe.

De asemenea, tot in etapa de finalizare a proiectului trebuie sa se realizeze un audit al

implementarii proiectului, ale carui rezultate vor fi incluse in raportul final.

Cine decide finalizarea proiectului si cand ?

Avizul formal cu privire la termenul de finalizare a proiectului trebuie semnat atat de catre managerul de proiect, cat si de managerii aflati pe niveluri ierarhice superioare acestuia.

Data de finalizare trebuie sa fie in acord cu planul general al proiectului. De asemenea, managerul de proiect initiaza incheierea proiectului cu acordul si cu cooperarea organizatiei client.

Forme de finalizare a proiectului

Jack Meredith si Samuel Mantel au identificat trei tipuri de finalizare a proiectelor :

Extinctia

Includerea

Integrarea

a)      Extinctia se intalneste in cazurile in care proiectul se finalizeaza conform termenului

final de executie prevazut in planul initial, indiferent daca obiectivele proiectului au fost atinse sau nu. Indiferent de situatie, relatiile contractuale, de colaborare, ierarhice etc. intre participantii la proiect trebuie sa se incheie, iar raportul final trebuie realizat. Aceasta forma de finalizare poate fi o sursa importanta de stres, deoarece exista posibilitatea ca proiectul sa se incheie inaintea atingerii obiectivelor.

b)      Finalizarea proiectului prin includere se intalneste in cazurile in care implementarea

acestuia s-a soldat cu un succes si, in consecinta, echipa de proiect este institutionalizata sub forma unui compartiment special, in cadrul organizatiei.

Rezultatele proiectului se transforma treptat intr-un activ al organizatiei. Proiectul este treptat absorbit de catre organizatia client, iar rezultatele sale intra in faza de productie in masa.

c)      Finalizarea proiectului prin integrare este cea mai intalnita forma de finalizare a unui

proiect. In plus, este si cea mai complexa. Echipamentele, resursele materiale si umane se returneaza organizatiei mama. Contrar finalizarii prin includere, proiectul nu mai reprezinta un concurent al celorlalte compartimente ale organizatiei in lupta pentru resursele limitate ale acesteia.

Responsabilitatea managerului de proiect este semnificativa in toate cele trei forme de finalizare a proiectului. Cunoasterea detaliata a proiectului si a modalitatilor de finalizare permite managerului sa planifice operatiunile de includere, sau de integrare.

O alta forma de finalizare a proiectului, neplanificata de aceasta data, este renuntarea la proiect. In cest caz nu vom intalni un proces de predare-primire a rezultatelor proiectului intre echipa de proiect si client.

Abandonarea proiectului poate avea diferite cauze : rezultatele proiectului pot cadea in obsolenta, sau pot fi depasite tehnologic de variante dezvoltate de catre alte firme ; versiunile realizate de alte firme pot fi mai ieftine, mai rapide si mai performante; prototipul poate esua in atingerea perfomantelor asteptate ; costurile sau termenele de realizare pot depasi limitele prevazute etc.

Chestionar de verificare

Urmatoarea lista de intrebari elaborata de Jack Meredith si Samuel Mantel poate servi ca ghid pentru managerii care doresc sa determine momentul potrivit pentru finalizarea proiectului (facand exceptie de termenele prevazute in programul de executie) :

Proiectul corespunde obiectivelor organizatiei ?

Proiectul este practic ? Util ?

Managementul organizatiei este suficient de entuziast incat sa continue

sprijinirea acestuia ?

Amploarea proiectului tine seama de situatia financiara a organizatiei ?

Proiectul este ' echilibrat ' din punct de vedere tehnic ? Din punct de vedere al

noutatii ? Din punct de vedere al costului ?

Proiectul beneficiaza de sprijinul tuturor departamentelor (de exemplu, productie, marketing,etc.) necesar implementarii sale ?

Proiectul are foarte putin sprijin din partea firmei ?

Sprijinul acordat acestui proiect este suficient pentru succesul acestuia ?

Proiectul prezinta un avans mare fata de tehnologia curenta ? Avansul este redus ?

Echipa de proiect se caracterizeaza prin inovativitate ? Sau, dovedeste lipsa de

creativitate ?

Inovatiile realizate pot fi protejate prin brevet, drepturi de autor sau secret comercial ?

Proiectul poate fi dezvoltat fara a inregistra pierderi calitative ?

Echipa de proiect este pregatita pentru a continua proiectul ?

Organizatia detine competentele necesare pentru implementarea completa a proiectului ?

Domeniul de activitate in care se incadreaza proiectul a fost suficient studiat ?

Un membru important a parasit echipa de proiect ?

Echipa de proiect spera in succesul proiectului ?

Se obtin rezultate mai bune daca activitatile de proiect sunt desfasurate de catre echipa de proiect, decat daca aceste activitati ar fi fost subcontractate sau prestate de parteneri externi ?

Exista posibilitatea ca proiectul sa atinga cel putin o parte a obiectivelor prestabilite ? Executia proiectului se incadreaza in termenele prestabilite ?

Indiferent de forma pe care o ia finalizarea proiectului, managerul de proiect trebuie sa cunoasca etapele procesului de finalizare. Dupa completarea chestionarului prezentat anterior si stabilirea oportunitatii deciziei de finalizare a proiectului, se poate trece la finalizarea propriu-zisa a acestuia.

Etapele finalizarii propriu-zise a proiectului

Procesul de finalizare poate fi indelungat si complicat, pe masura marimii, complexitatii si amplorii proiectului. Din acest motiv, managerul de proiect trebuie sa urmareasca etapele unui proces sistematic, care asigura incheierea tuturor contractelor si relatiilor de afaceri.

Principalele etape de finalizare a unui proiect sunt :

pregatirea logisticii de finalizare a proiectului ;

documentarea proiectului ;

realizarea auditului postimplementare si elaborarea raportului final ;

obtinerea acordului clientului ;

inchiderea activitatii.

Aceste etape includ efectuarea mai multor lucrari :

stabilirea unei structuri organizatorice destinate finalizarii proiectului :

stabilirea unui manager responsabil cu finalizarea proiectului ;

- stabilirea unei echipe de finalizare a proiectului ;

organizarea unei sedinte de finalizare in vederea revizuirii procesului si stabilirea sarcinilor finale ;

elaborarea documentelor de disponibilizare a angajatilor care au participat la proiect, dizolvarea compartimentelor administrative si a structurii ierarhice destinate proiectului ;

finalizarea tuturor rapoartelor financiare, incheierea tuturor platilor si cheltuielilor, colectarea tuturor datoriilor, elaborarea raportului financiar de inchidere a proiectului ;

finalizarea tuturor comenzilor de lucru, insarcinarilor si obligatiilor furnizorilor si clientilor ;

completarea documentatiei proiectului, inclusiv cu rapoartele oferite de furnizori si subcontractanti ;

inchiderea locatiilor destinate proiectului si returnarea echipamentelor utilizate in cadrul acestuia ;

realizarea si finalizarea auditului postimplementare ; completarea raportului final catre client ;

obtinerea avizului clientului ;

inchiderea tuturor locatiilor fizice si disponibilizarea angajatilor ramasi.

In derularea procesului de finalizare trebuie sa se colaboreze permanent cu conducerea organizatiei mama si cu clientul. Succesul finalizarii proiectului depinde de satisfactia clientului si, implicit, de calitatea serviciilor furnizate.

1.5 Dizolvarea echipei de proiect

Derularea proiectului este idisolubil legata de resursele umane. Actiunea umana este prezenta din primele etape ale proiectului pana la finalul acestuia. Creativitatea, flexibilitatea si energia membrilor echipei determina cursul initierii, planificarii si executiei proiectului.

In ultima faza a ciclului proiectului, membrii echipei de proiect incep sa isi puna intrebari de genul : 'Cand voi parasi echipa de proiect ? ' sau ' Care va fi urmatorul proiect la care voi lucra ? ' sau ' Ma voi putea reintoarce la vechiul meu post ? '. Angajatii ramasi sa finalizeze proiectul vor observa cum componenta si marimea echipei se modifica pe masura ce unele persoane - de regula, experti - sunt repartizate altor proiecte. Angajatii pot vedea chiar cum managerul de proiect paraseste echipa, sarcinile sale fiind preluate de un alt membru al echipei, mai putin experimentat.

Toate acestea sunt insotite de pierderea ambitiei si a angajamentului ce a caracterizat echipa la inceput. Odata cu acestea se pierde spiritul de cooperare si de incredere reciproca ce a caracterizat derularea proiectului, pana la finalizarea sa.

Pentru a evita aceste probleme, managerul de proiect trebuie sa se asigure ca membrii echipei de finalizare impreuna cu clientii si cu ceilalti stakeholderi isi concentreaza eforturile si angajamentul catre sarcinile de inchidere a proiectului. Cea mai eficienta metoda de a realiza acest lucru este aceea de a forma echipe de lucru mixte, echipe care sunt incurajate sa stabileasca si sa implementeze masurile de finalizare a proiectului. (De exemplu, o echipa mixta formata din membrii echipei de proiect, clienti si stakeholderi poate realiza in comun o evaluare a rezultatelor proiectului pentru a elabora, ulterior, o lista a sarcinilor de lucru nefinalizate si a eventualelor corectii necesare. Sau, managerul de proiect impreuna cu consumatorul pot elabora impreuna un plan de aplicare in productie a rezultatelor proiectului.)

In final, echipa de proiect se va dizolva. Asemenea, altor forme de lichidare a structurilor organizationale, trebuie sa se manifeste atentie deosebita dizolvarii echipei de proiect. Este important ca in aceasta faza a proiectului sa se satisfaca atat cerintele membrilor, cat si cele ale proiectului. Din prisma proiectului, trebuie sa se mentina, pana la finalizarea completa a acestuia, o echipa de proiect eficienta. In ceea ce priveste membrii echipei, trebuie sa se recompenseze performanta individuala a fiecarui membru. Timpul consumat de catre managerul de proiect in planificarea viitorului membrilor echipei - mergand chiar pana la elaborarea unui plan de redistribuire a fortei de munca - va fi recompensat prin angajamentul si performantele membrilor ramasi.

1.6 Inchiderea bazelor de date

Faza finala a proiectului se caracterizeaza, in general, prin :

cheltuirea tuturor fondurilor financiare ;

obtinerea rezultatelor asteptate ;

consumarea celei mai mari parti din resursele alocate.

In plus, se colecteaza un mare volum de informatii. Natura acestor informatii este

foarte variata. Acestea curpind, de exemplu :

schite, specificatii tehnice, manuale de utilizare a echipamentelor achizitionate pentru proiect ;

planurile si schitele produselor ce fac obiectul proiectului ;

planuri si programe de executie ;

registre de cheltuieli ;

contracte cu furnizorii si subcontractantii.

Informatiile de baza sunt continute in specificatiile de proiect, planul proiectului

si bugetul proiectului. Continutul lor este modificat si extins in functie de circumstantele reale in care se desfasoara activitatile de proiect si in raport cu modificarile impuse de aplicarea procedurilor de control.

Intrebarea care se ridica in acest context este, probabil : ' La ce ne foloseste un volum atat de mare de informatii ? ' Toate aceste informatii ne sunt necesare pentru :

a identifica si a finaliza activitatile restante ;

a inregistra performantele obtinute ;

a evidentia istoria proiectului ;

a verifica daca s-au realizat obiectivele prestabilite.

Analizand informatiile detinute, putem determina daca scopul pentru care s-a initiat

proiectul a fost atins.

1.7 Finalizarea activitatilor

Inainte de a demara finalizarea propriu-zisa a proiectului, trebuie sa determinam ce anume a mai ramas de facut. Pentru aceasta trebuie sa stabilim :

ceea ce s-a realizat pana acum ;

ceea ce ar fi trebuit sa se realizeze.

Diferenta dintre aceste elemente ne releva ceea ce a mai ramas de facut. Ambele

elemente mentionate anterior pot fi regasite in documente precum specificatiile de proiect, sistemul de control al proiectului, reteaua activitatilor etc. Pornind de la aceste documente, o echipa mixta formata din membrii echipei de proiect, client si stakeholderi poate demara auditul proiectului. Aceasta echipa compara ceea ce s-a realizat efectiv cu ceea ce ar fi trebuit sa se realizeze.

Clientul trebuie sa se asigure ca rezultatele estimate la demararea proiectului au fost, sau urmeaza a fi obtinute. Cand apar diferente intre specificatiile proiectului si rezultatele efective, managerul de proiect trebuie sa stabileasca, impreuna cu toti cei implicati, un program de finalizare a activitatilor ramase. Acest program trebuie sa cuprinda o ierarhie a prioritatilor, un calendar de lucrari si rezultate care asigura indeplinirea specificatiilor proiectului. In cazul proiectelor complexe, procesul de finalizare poate fi considerat un proiect in sine, motiv pentru care, asa cum am mai precizat, se desemneaza un manager responsabil cu finalizarea proiectului.

Comunicarea este deosebit de importanta in toate etapele proiectului, iar etapa finala nu face exceptie. Presiunile si dificultatile ce caracterizeaza aceasta etapa pot accentua, chiar, nevoia de comunicare. De exemplu, constatarile echipei mixte trebuie comunicate celorlalti participanti la proiect. Pe baza lor se vor stabili masurile necesare, masuri a caror aplicare va trebui supravegheata si raportata.

Mijloacele de comunicare sunt variate. Ele cuprind sedintele si rapoartele cu frecventa predeterminata, ce fac parte din sistemul uzual de monitorizare si control al proiectului. In faza de finalizare, se impune o crestere a frecventei acestor sedinte precum si abordarea mai detaliata a unor probleme cum ar fi cele legate de constatarile echipei mixte si de lucrarile restante. Componenta participantilor la sedinta se modifica si ea, incluzand membrii ramasi ai echipei de proiect, reprezentantii organizatiei client si alti stakeholderi.

Documentatia de inchieiere a proiectului

Intre informatiile obtinute in timpul derularii proiectului se regasesc informatiile

referitoare la rezultatele acestuia. In cazul proiectelor ale caror produse (rezultate) au un caracter tangibil, aceste informatii se regasesc sub forma de schite sau specificatii tehnice. Echipamentele achizitionate sunt insotite de documente ce prezinta procesul de fabricatie si perfomantele tehnice inregistrate. Chiar si in cazul proiectelor ale caror obiective sunt mai putin tangibile putem constata existenta unor suporturi informationale precum ar fi, de exemplu, materialele publicitare utilizate in cadrul unei campanii politice, sau chestionarele completate, in cazul unor cercetari de marketing.

Toate aceste materiale si suporturi informationale trebuie puse la dispozitia clientului, deoarece, pe viitor, clientul va fi cel care va utiliza sau va suplimenta aceste informatii. Daca produsul proiectului are un caracter tangibil, cum ar fi un nou tip de masina, sau de computer, atunci clientul - si nu membrii echipei de proiect - se va ocupa cu intretinerea, reparatia sau modificarea produsului. Unele informatii pot fi necesare clientului imediat dupa procesul de predare-primire, pentru a permite acestuia punerea in functiune si utilizarea produselor proiectelor. In cazul proiectelor ale caror produse au caracter complex, predarea produsului este precedata de furnizarea manualului de utilizare, pentru a permite clientului sa-si pregateasca proprii angajati.

Informatiile necesare realizarii documentatiei proiectului trebuie colectate, organizate si stocate incepand cu primele etape ale proiectului. De exemplu, comenzile de achizitionare de echipamente trebuie sa cuprinda clauze referitoare la furnizarea manualelor de utilizare, programului de intretinere, listelor cu piese de rezerva, instructiunilor de identificare a defectelor. Livrarea acestei documentatii trebuie urmarita si controlata, sub aspect calitativ, in mod similar verificarii livrarii echipamentelor.

Exista situatii in care echipa de proiect participa la implementarea produsului proiectului. Acest lucru se intampla in cazurile in care punerea in functiune a produsului impune detinerea unor cunostinte de specialitate, pe care angajatii firmei client nu le detin.

In cazul unor produse complexe, cum ar fi o instalatie petrochimica sau o cladire pentru birouri, se formeaza si se pregateste o echipa speciala de instalatori chiar din faza de executie a proiectului, echipa ce se va mentine si dupa dizolvarea echipei de proiect. In cazul produselor de complexitate redusa, cum ar fi un computer, sau un automobil, procesul de predare-primire este insotit, de regula, de un scurt seminar de instruire a utilizatorului.

2.1 Istoria proiectului

Toate proiectele au o istorie. Aceasta este reflectata de registrele si documentele proiectului, ce ne furnizeaza informatii cu privire la durata si termenele de executie, ne reamintesc modificarile si corectiile aduse planului proiectului, ne releva contributia fiecarui participant la proiect si ne evidentiaza metodele si procedurile utilizate. Aceste documente inregistreaza intregul ciclu de viata al proiectului.

In cazul proiectelor complexe, cu perioada de executie indelungata, istoria proiectului ne ofera informatii valoroase cu privire la metodele si tehnicile de management al proiectelor. Aceasta istorie poate servi chiar si pregatirii membrilor echipei unui nou proiect. Totusi, in general, elaborarea unei istorii complete a proiectului este considerata, in general, un lux. Costul implicat si durata limitata a proiectului impiedica uneori inregistrarea unei istorii complete a acestuia. In aceste conditii, elemente istorice ale proiectului pot fi intalnite in raportul elaborat in urma auditului.

Proiectul poate fi auditat in oricare faza a ciclului sau de viata. Obiectivele unui astfel de audit sunt relativ simple si se refera la :

analizarea situatiei proiectului ;

identificarea riscurilor care caracterizeaza faza in care se afla proiectul;

determinarea modificarilor ce trebuie aduse managementului sau planului proiectului;

Totusi, auditul este mai putin practicat in primele faze ale proiectului -

planificare, design sau executie. Se poate intampla insa ca intarzierile accentuate, sau depasirea puternica a bugetului de cheltuieli sa starneasca ingrijorarea conducerii firmei si, implicit, sa o determine sa solicite realizarea unui audit. Cea mai frecventa forma este insa auditul postimplementare, care se realizeaza dupa finalizarea tuturor activitatilor de proiect si dupa predarea rezultatelor proiectului clientului.

2.2 Auditul postimplementare si raportul final

Auditul post-implementare consta in evaluarea proiectului si a rezultatelor sale sub aspectul respectarii planului de proiect, bugetului, termenelor de executie, calitatii produselor, specificatiile tehnice si al satisfacerii cerintelor clientilor. Tabloul de bord, instrument managerial frecvent utilizat, poate servi ca sursa informationala pentru demararea auditului. Principalele intrebari ridicate in cadrul acestuia sunt :

Au fost realizate obiectivele proiectului ?

Activitatile de proiect s-au desfasurat in termenul specificat, in limitele bugetului si cu respectarea specificatiilor tehnice ?

A fost clientul satisfacut de rezultatele proiectului ?

In final, rezultatele auditului trebuie prezentate sub forma unui raport formal.

Marimea si structura acestui raport este influentata de costurile, natura si rezultatele proiectului. In cazul proiectelor complexe, auditul este realizat de catre echipe mixte de auditori cu specializare diferita si se finalizeaza cu rapoarte extinse, destinate, de regula, acoperirii cerintelor informationale ale stakeholderilor. In cazul proiectelor de mica amploare, sau cu buget de cheltuieli redus, rapoartele vor avea un caracter sumar, general. Daca echipa de proiect si consumatorul apartin aceleiasi organizatii, auditul poate fi realizat de catre persoane din interiorul acesteia. In cazul in care intre echipa de proiect si client exista relatii contractuale, se recomanda ca auditul sa fie realizat de o echipa impartiala, formata din experti externi.

Raportul final al evaluarii proiectului serveste ca mijloc de inregistrare a  istoriei proiectului. Acesta este documentul pe care terte persoane poate sa il consulte in vederea studierii progresului si a impedimentelor ce au caracterizat proiectul. Exista mai multe forme de elaborare a raportului final. Cu toate acestea urmatoarele elemente specifice apar in toate rapoartele finale :

  • succesul sau performantele generale ale proiectului (determinate pe baza rezultatelor auditului postimplementare) ;
  • organizarea si administrarea proiectului, tehnicile utilizate in vederea atingerii obiectivelor proiectului ;
  • evaluarea punctelor forte si slabe ale proiectului ;
  • recomandari ale managerului sau ale echipei de proiect cu privire la continuarea sau incetarea proiectului.

In cazul proiectelor de mare complexitate, acest raport surprinde evolutia proiectului

de la primele etape ale acestuia pana la finalizare, precum si, in continuare, urmatorii doi-trei ani.

2.3 Recompensarea succesului si invatarea din greseli

Finalizarea proiectului prin recompensarea rezultatelor este ultima etapa a proiectului. Sarcina finala a managerului de proiect este aceea de a reuni echipa de proiect in vederea reviziuirii activitatilor desfasurate. Aceasta este forma de dizolvare formala si informala a relatiilor dintre participantii la proiect.

Nu toate proiectele se incheie intr-o nota de succes. Dar, cu toate acestea, din fiecare proiect se pot trage o serie de invataminte. Intalnirea, petrecerea, dineul sau gala de final incheie ciclul de viata al proiectului.

3. Succesul sau esecul proiectului

Nimeni nu isi propune sa esueze in realizarea unui proiect. Evident, orice proiect se doreste a fi un succes. Totusi, nu este intotdeauna foarte clar ce se intelege prin succes, sau prin esec.

3.1 Definirea succesului sau esecului unui proiect

Cea mai frecvent utilizata definitie este urmatoarea : 'un proiect este considerat un esec daca nu se ating criteriile de performanta, cost, timp si/sau sfera de activitati stabilite in momentul planificarii lui '. Totusi, aceasta definitie are cateva deficiente. In primul rand se pune problema modului in care au fost stabilite criteriile proiectului :daca acestea nu au fost conturate in mod realist, mai este vorba oare de esec ? In al doilea rand, chiar daca criteriile sunt indeplinite, proiectul rezolva oare problema pentru care a fost conceput ? Daca nu, mai putem considera ca proiectul reprezinta un succes ?

R. L. Schultz, Dennis Steven si Jeffrey Pinto, autorii lucrarii Strategy and Tactics in Process Model of Project Implementation, au identificat patru tipuri de erori ce pot interveni in solutionarea problemelor. Intrucat proiectele au ca obiect, prin definitie, rezolvarea unor probleme, concluziile celor trei cercetatori se aplica foarte bine in acest domeniu. Aceste erori sunt:

A nu actiona atunci cand este necesar

A actiona atunci cand nu este necesar

A rezolva o problema enuntata gresit

A identifica corect problema, dar a nu implementa corect solutia.

Pornind de la aceste patru tipuri de erori enuntate anterior, putem spune ca, daca un proiect respecta criteriile de performanta, cost, timp si sfera de activitati prevazute, insa rezultatele nu sunt utile beneficiarului, atunci este posibil sa se fi produs o eroare de tipul 3 sau 4.

In unele cazuri, eroarea 3 poate determina aparitia erorii 4. De exemplu, daca problema a fost gresit enuntata, solutionarea problemei este inutila, caci utilizatorii finali nu pot valorifica rezultatul proiectului. Aceasta se intampla in proiectele de informatizare dintr-o firma, cand managerii unor departamente solicita implementarea unui anumit sistem, insa anagajatii, care sunt, in definitiv, utilizatorii acestui sistem, nu il pot folosi, deoarece nu corespunde nevoilor lor.

In lucrarea Learning for Failure: The System Approach, Joyce Fortune si Geoff Peters afirma ca esecul poate fi definit ca: "ceva ce nu a functionat, sau care nu s-a ridicat, la nivelul asteptarilor". Ei au identificat patru tipuri de esecuri, corespondenta acestora cu cele patru tipuri de erori descoperite de R.L. Schultz, Dennis Steven si Jeffrey Pinto fiind prezentata in figura 7.2.

Primul tip de esec, nerealizarea obiectivelor, este cel mai des intalnit. Exemple ale unor astfel de esecuri sunt programele soft ce nu functioneaza corespunzator sau produsele lansate de curand, ce nu se vand.

Pentru al doilea tip de esec, obtinerea unor efecte secundare nedorite, se caracterizeaza prin faptul ca obiectivul initial este atins, insa realizarea proiectului este insotita de consecinte neplacute, sau de efecte adverse.

Majoritatea problemelor de poluare a mediului, in prezent, sunt, de fapt, consecinte ale

solutiilor la problemele rezolvate in trecut. Un alt exemplu de efecte nedorite sunt medicamentele, care, desi sunt eficiente in tratarea unor afectiuni, pot cauza malformatii copiilor ai caror mame s-au aflat sub tratament in timpul sarcinii. Un alt exemplu este oferit de efectele neasteptate ale implanturilor.

Tipuri de erori

Categorii de esecuri

A nu actiona atunci cand este necesar

Nerealizarea obiectivelor

A actiona atunci cand nu este necesar

Efecte secundare nedorite

A rezolva o problema enuntata gresit

Esecuri predeterminata

A rezolva problema, dar a nu implementa corect solutia

Obiective eronate

Figura 7.2 - Prezentarea categoriilor de esecuri identificate de Joyce Fortune si Geoff Peters

Al treilea tip de esec este cel predeterminat, motiv pentru care nu se considera ca fiind negativ. (De exemplu, sigurantele electrice sunt proiectate sa cedeze atunci cand este depasita o anumita intensitate a curentului, iar sistemele sprinkler sunt proiectate sa deschida automat conducta de apa, in momentul in care senzorii indica declansarea unui incendiu).

Al patrulea tip de esec consta in urmarirea unor obiective gresite. In aceasta categorie pot fi incluse produsele care functioneaza conform parametrilor tehnici prestabiliti, dar care nu satisfac nevoile de pe piata. (De exemplu, instalarea unui conveior pentru diminuarea deteriorarii bunurilor in timpul transportului nu rezolva problema deteriorarii in sine, ci asigura transportul corespunzator al produselor in cadrul fabricii).

De asemenea, calculatorul Apple III, care era probabil superior din punct de vedere tehnic

calculatorului produs de IBM la acea data, nu a fost acceptat de piata din cauza renumelui mai puternic al companiei IBM si a faptului ca nu existau aplicatii software compatibile cu Apple III destinate activitatilor economice.

Conform opiniei exprimate de Joyce Fortune si Geoff Peters, interpretarea esecurilor este

subiectiva, aceasta fiind influentata de circumstante, de perceptiile si asteptarile fiecarui individ in parte. Acest lucru se poate constata atunci cand mai multe persoane participante la realizarea proiectului au pareri impartite cu privire la succesul, sau esecul, acestuia. Pentru a evita o astfel de situatie, este important ca, inaintea inceperii proiectului, sa se ajunga la un consens in ceea ce priveste criteriile de evaluare a succesului, sau a esecului, proiectului.

3.2 Produs final, rezultate si asteptari

Exista trei elemente in functie de care putem aprecia reusita, sau esecul, unui proiect. Acestea sunt : produsul final, rezultatele si asteptarile stakeholderilor. Combinatiile posibile ale acestora sunt prezentate in figura 7.3. In cazul succesului total (vezi cazul 1 din figura 7.3), produsele si rezultatele sunt cele preconizate, iar asteptarile stakeholderilor sunt satisfacute.

In cel de al doilea caz, produsele si rezultatele sunt cele preconizate, dar, cu toate acestea, interesele stakeholderilor nu sunt satisfacute. Aceasta se poate intampla daca componenta stakeholderilor se modifica pe parcursul desfasurarii proiectului, iar noii stakeholderi au alte pretentii de la proiect. Prin urmare, managerii de proiect trebuie sa urmareasca toate modificarile ce pot interveni in asteptarile stakeholderilor si sa nu porneasca de la ipoteza ca acestea vor ramane neschimbate pana la finalizarea proiectului.

Un exemplu de modificare a asteptarilor ne poate fi oferit de tehnologia informatica. La aparitia primelor computere personale, majoritatea utilizatorilor erau coplesiti de rapiditatea cu care se puteau utiliza foile de calcul.

Dupa cativa ani, utilizatorii nu au mai fost multumiti de viteza de procesare a datelor. Motivul ? Asteptarile utilizatorilor privind performantele unui calculator s-au dezvoltat continuu.

A treia varianta prezentata in figura 7.3 este cel putin interesanta. Desi produsele sunt cele promise, nu s-au atins rezultatele prevazute. Dar, cu toate acestea, asteptarile au fost satisfacute. Prin urmare, daca s-a considerat ca prin obtinerea produselor dorite se vor atinge si rezultate urmarite, s-a comis o eroare. Daca insa asteptarile au fost satisfacute, acest lucru se poate explica prin faptul ca stakeholderii au fost foarte indulgenti cu privire la rezultatele proiectului, fie prin faptul ca au constatat cu mult timp inainte de finalizarea proiectului ca rezultatele urmarite nu vor putea fi atinse.

A patra varianta este similara cu cea de a treia, cu exceptia faptului ca stakeholderii nu au fost ingaduitori cu privire la neatingerea rezultatelor si, ca urmare, asteptarile lor nu au fost satisfacute.

A cincea varianta este deosebita. Produsele nu corespund cu cele initial planificate si, cu toate acestea, rezultatele se considera a fi satisfacatoare, iar asteptarile indeplinite. Acest lucru se intampla atunci cand managerii constata in faza de implementare a proiectului ca trebuie aduse schimbari produselor planificate, pentru a se putea obtine rezultatele dorite.


Produsele Rezultatele Asteptarile Evaluare

sunt cele sunt cele sunt finala

promise? promise? satisfacute? DA

1. Succes total

DA

2.Nesatisfacerea

NU asteptarilor

stakeholderilor

DA

DA 3.Indulgenta sub

NU aspectul obtinerii

rezultatelor

NU

4.Neconcordanta

intre produs si

rezultate

5. Neconcordanta

DA intre produs si

rezultate, insa

DA rezultatele dorite au

fost atinse

NU

6. Proiectul este

evaluat doar in

NU functie de produs

DA

7.Indulgenta fata de

produs si rezultate

NU

NU

8. Esec total


Figura 7.3 - Combinatii intre elementele de apreciere a succesului unui proiect

Analizand cea de a sasea varianta, putem constata ca produsele nu sunt cele planificate, asteptarile nu sunt satisfacute si, cu toate acestea, rezultatele prevazute sunt atinse.

In acest caz, stakeholderii solicita managerului de proiect obtinerea produselor prevazute, in ciuda faptului ca rezultatele dorite au fost obtinute, prin adoptarea unei alternative.

In varianta a saptea este vorba despre un stakeholder foarte indulgent. Nici produsele si nici rezultatele nu sunt cele asteptate, dar, cu toate acestea, asteptarile sunt indeplinite. Poate fi cazul unui proiect condus de o ruda, sau apropiat al stakeholderului.

In sfarsit, cea de-a opta varianta este un esec total, niciunul dintre elementele de apreciere a succesului unui proiect nefiind atins.

3.3 Rezultatele cercetarilor

Pentru a determina factorii care influenteaza succesul unui proiect, David Murphy, Bruce Baker si Dalmar Fisher au realizat un studiu asupra a 650 de proiecte.

Cercetatorii au cautat sa raspunda la doua intrebari cheie : ' De ce unele proiecte sunt considerate esecuri, cu toate ca indeplinesc criterile de P (performanta), C(cost), T(timp), S(sfera de activitati) ?' si 'De ce alte proiecte sunt considerate un succes, chiar daca se inregistreaza intarzieri in executie sau depasiri ale bugetului de cheltuieli ?'

In urma acestui studiu, cercetatorii au ajuns la concluzia ca succesul poate fi definit astfel : 'Proiectul poate fi considerat un succes total daca respecta specificatiile tehnice, indeplineste misiunea pentru care a fost dezvoltat, iar membrii organizatiei mama, ai organizatiei client, ai echipei de proiect, precum si utilizatorii finali sunt satisfacuti'.

Se poate constata deci, ca succesul unui proiect este, in fond, o problema de perceptie. Putem observa, de asemenea, ca definitia nu include, ca elementele de apreciere a succesului, respectarea criteriilor de timp si de cost. Potrivit lui Bruce Baker, acest lucru se poate explica prin faptul ca cercetarea a avut ca obiect numai proiecte finalizate. Cand o activitate este in desfasurare, costul si timpul sunt o permanenta sursa de presiune. Dupa ce activitatea a fost finalizata, daca satisface nevoile celor ce au solicitat-o, costurile si termenele isi pierd din importanta.

Studiul identifica un numar de parametri ce permit identificarea unui proiect de succes, pentru recunoasterea esecului fiind valabili, in mod evident, alti parametri. Un aspect important pentru considerarea unui proiect ca fiind un succes, il constituie necesitatea ca majoritatea, daca nu chiar toti parametrii asociati esecului, sa fie absenti.

3.4 Factori care contribuie la succesul perceput al unui proiect

In urma studiului intreprins de cei trei cercetatori s-a constatat ca exista sapte factori determinanti ce contribuie la evaluarea succesului unui proiect :

1.Coordonarea ;  

Adaptarea structurii organizatorice a proiectului si controlul ;

Unicitatea proiectului, importanta si expunerea publica ;

Importanta si concordanta intre criteriile de evaluare ale succesului ;

Competitivitatea si presiunile exercitate in directia respectarii limitelor bugetare ;

Optimism exagerat si dificultati de conceptualizare ;

Capacitati interne de realizare.

Deoarece unul dintre cei mai importanti factori il constituie coordonarea, este indicat sa

cunoastem care sunt elementele ce contribuie la realizarea eficienta a acesteia :

Consensul intre managerul de proiect si managerii functionali ;

Spiritul de echipa, intelegerea misiunii, competenta si angajament pentru atingerea scopului ;

Consensul intre managerul de proiect si autoritatile publice, clienti si managerii superiori ;

Calitatile interumane si administrative ale managerului de proiect ;

Rapoartele realiste ale progreselor realizate ;

Relatiile informale intre membrii echipei ;

Autoritatea managerului de proiect ;

Stabilirea unor proceduri adecvate de introducere a schimbarilor ;

Satisfacerea nevoii de siguranta a locului de munca ai membrilor echipei de proiect ;

10.Participarea echipei de proiect la adoptarea deciziilor si la rezolvarea problemelor

importante ;

11.Sprijinul companiei mama ;

12.Existenta unor strategii de sustinere.

3.5 Factori care contribuie la esecul perceput al unui proiect

Exista anumiti factori ce contribuie la perceperea unui proiect ca fiind un esec.

Subliniem, inca o data, ca managerul de proiect trebuie sa urmareasca amplificarea elementelor care determina succesul unui proiect si sa le evite pe cele care determina esecul. Dintre acestea din urma se pot enumera:

Insuficienta utilizare a analizelor de stare si a progreselor ;

Utilizarea superficiala a analizei de stare ;

Calitatile interumane si competenta tehnica neadecvate ale managerului de proiect ;

Insuficienta autoritate si influenta ale managerului de proiect ;

Lipsa de colaborare cu clientul ;

Lipsa de informare a clientului sau organizatiei mama ;

Dezinteresul clientului fata de respectarea bugetului alocat ;

Lipsa de participare a echipei de proiect la adoptarea deciziilor si la rezolvarea problemelor ;

Formalizarea excesiva a structurii echipei de proiect ;

Lipsa de siguranta a locului de munca perceputa de membrii echipei de proiect ;

Firma mama imobila, lipsita de dinamism si de schimbari strategice ;

Coordonare redusa fata de firma mama ;

Noutatea unui proiect ;

Initierea unui proiect cu o complexitate superioara comparativ cu proiectele anterioare ;

Finantare initiala insuficienta ;

Incapacitatea stabilirii specificatiilor tehnice definitive in timp util ;

Incapacitate de finalizare a proiectului ;

Stabilirea unor termene de executie nerealiste ;

Promovarea unor proceduri inadecvate de introducere a schimbarilor.

Conform studiului, managerii de proiect au tendinta sa creada ca conjunctura potrivnica le impiedica succesul. Totusi, Bruce Baker si ceilalti participanti la studiu concluzioneaza ca, de fapt, managerii de proiect pot avea succes, chiar in situatii nefavorabile, daca tin seama de factorii prezentati anterior.

3.6 Obiective si abateri

Am mentionat la inceputul capitolului ca, in general, esecul unui proiect este

identificat cu neatingerea criteriilor de performanta, cost, timp si/sau sfera de activitati, stabilite in momentul planificarii lui. Acest lucru este valabil numai in conditiile in care criteriile mentionate au fost stabilite in mod realist.

Daca un manager de proiect stabileste criterii nerealiste sub presiunea exercitata de superiorul sa, atunci proiectul va esua, chiar si in conditiile in care aceste criterii au fost indeplinite. Prin urmare, managerul de proiect are obligatia de a urmari stabilirea unor obiective credibile si realiste.

Cum putem sti daca un obiectiv este sau nu realist ? Prin determinarea acestuia pe baza experientelor trecute. Daca nu detaliem programul de executie pana la nivelul posturilor individuale, unde sarcinile sunt intr-o anumita masura repetabile, si daca nu tinem seama de experienta anterioara in executarea acestor sarcini, putem doar sa presupunem ca obiectivele stabilite sunt realiste. Trebuie sa subliniem ca duratele de timp ale tuturor activitatilor de proiect sunt probabilistice si nu deterministe: de exemplu, putem stabili duratele unor activitati cu o anumita probabilitate si, apoi, putem face calcule deterministe pentru a stabili drumul critic, marjele de timp etc. Principalele cauze ce determina variabilitatea duratelor de executie sunt:

estimarea duratei activitatii se bazeaza pe o experienta nereprezentativa;

persoana pentru care s-a facut estimarea nu este disponibila pentru indeplinirea sarcinii respective, atunci cand este necesar;

repartizarea resurselor intre mai multe proiecte determina prelungirea termenelor de executie si, implicit, o scadere proportionala a eficientei;

probleme tehnice neprevazute produc intarzieri.

Multi manageri cu experienta in stabilirea bugetelor considera ca si pentru bugetele proiectelor trebuie sa se stabileasca tolerante stricte, asemenea bugetelor stabilite pentru compartimentele functionale ale organizatiei. Dar bugetele proiectelor nu se pot stabili similar bugetelor compartimentelor. Bugetul anual al unui compartiment se stabileste pe baza costurilor previzionate - se estimeaza cresterile salariale ce se vor acorda pe parcursul anului, se adauga costurile cu materialele consumabile prognozate etc. De cele mai multe ori, bugetul unui departament poate fi respectat cu o toleranta de doar cateva procente.

Pe de alta parte, in cazul unui proiect trebuie sa se stabileasca in primul rand volumul de munca implicat de realizarea proiectului si, cum acesta nu poate fi perfect anticipat, costul fortei de munca nu poate fi determinat cu precizie. Previziunile devin mai precise, pe masura ce proiectul se apropie de finalizare.

Prin urmare, trebuie sa acceptam variabilitatea parametrilor unui proiect. Aceasta este inerenta oricarui proces. In timp, ea se poate reduce, dar niciodata nu se poate elimina.



Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 3678
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved