“0% Closing” – proiecte neterminate?

“Clientul proiectului are o nevoie. Implementam proiectul, obtinem rezultatul (care, speram, satisface nevoia clientului), il predam clientului si…cam asta e, nu? Am terminat!”

“Cand consideram ca am terminat (inchis) un proiect?”

– o intrebare (aparent) simpla la care am cautat raspuns la peste 150 de manageri de proiect din peste 25 de companii (medii si mari) activand in domenii diferite (de la IT&C pana la cercetare de piata si productie de anvelope…).

90% dintre managerii de proiect chestionati considera ca proiectul se incheie imediat ce clientul a acceptat livrabilul (rezultatul) proiectului.

Din pacate, o asemenea abordare este incorecta din mai multe puncte de vedere. Si iata-le pe cele mai importante dintre ele:

1. Managerul de proiect primeste un “mandat” de a implementa/livra un proiect de la Sponsorul proiectului. Acest mandat (care poate fi considerat chiar similar unui contract) este formalizat prin “Carta Proiectului”, document ce se semneaza in etapa de initiere a proiectului. Orice contract trebuie si el “inchis” la terminarea activitatilor prevazute. Pentru managerul de proiect, acest lucru se realizeaza in etapa de incheiere a proiectului. Managerul de proiect construieste un raport de incheiere care stipuleaza daca toate conditiile “contractului” au fost indeplinite (obiectivele au fost implementate cu succes, scopul atins etc.).
2. Acceptarea livrabilului (rezultatului) proiectului de catre client se realizeaza in etapa de monitorizare si control. Oprirea proiectului imediat dupa acest moment ar insemna eludarea etapei de incheiere si, implicit, a raportului de incheiere. Prin urmare, “contractul” intre managerul de proiect si sponsor nu ajunge la final (fara o inchidere formala si normala). Si atunci, din punctul nostru de vedere, cu (cel putin) un contract “in aer”, proiectul nu poate fi considerat finalizat (inchis).
3. Mai mult, pe tot parcursul planificarii, ne bazam foarte mult (si) pe estimari analogice construite pe date istorice. Aceste date istorice ar trebui sa se regaseasca (intr-o proportie foarte mare) in lectiile invatate ale unui proiect. Lectiile invatate ar trebui adunate pe tot parcursul proiectului (desi, uneori, timpul nu este suficient). Insa, de formalizat, ele sunt formalizate in etapa de incheiere a proiectului. Daca noi consideram proiectul incheiat la acceptarea livrabilului, echipa va trece la un alt proiect (asa cum este si normal). Cine va mai avea timpul necesar sa ofere informatiile despre un proiect anterior in conditiile in care este (cel mai probabil) ocupat pana peste cap cu proiecte curente?

Prin urmare, “saritul” peste etapa de incheiere a unui proiect aduce numai deservicii.

Sub pretextul unei “optimizari/eficientizari” a timpului petrecut in proiect, de cele mai multe ori, in cadrul companiilor, etapa de incheiere are prioritate foarte mica, fiind trecuta la “si altele daca avem timp”. Este considerata ca fiind doar consumatoare de timp fara a aduce un beneficiu palpabil rezultatului, proiectului, clientului...

Din pacate, efectele acestei politici (paguboase) – pe care foarte multi manageri de proiect o accepta – nu se vor simti pe moment (pentru acel proiect specific). Dimpotriva, ele vor afecta toate proiectele ulterioare. Ne vom “lupta” iarasi pe estimari (desi, de multe ori, ele au mai fost facute anterior), ne vom stoarce creierii pentru solutii la riscuri (desi ele au fost gasite deja in proiecte similare anterioare) si asa mai departe.

Si ne mai miram ca viata managerului de proiect e grea…