Ce este MP? Părerile sunt împărțite. PMI (Project management Institute – o organizație cu peste 500.

000
membrii în 171 țări și care stabilește standardele pentru domeniul MP) afirmă că este o profesie. Alții
afirmă că Managementul Proiectelor nu este o profesie în sine. Nu este ceva precum contabilitatea,
auditul sau consultanța. MP este o disciplină complementară care ne ajută să derulăm foarte ușor
proiectele. În plus aproape toate profesiile – contabili, ingineri, medici, regizori sau IT-ști pot folosi MP.
Practic este aplicabilă în orice profesie, în orice domeniu (transport public, furnizare utilități, sănătate,
educație, IT, etc.). Dar ce este important este că practic toată lumea participă în proiecte (și chiar le
administrează), doar că nu întotdeauna sunt conștienți de acest lucru.
Certificatul PMP (Project management professional) emis de PMI este certificatul cu cea mai largă
recunoaștere mondială, care atestă că titularul certificatului posedă educația, experiența și competențele
necesare conducerii unui proiect.
Această parte a prezentării are ca scop înțelegerea fundamentelor/elementelor MP, după care, pe acest
fundament este foarte ușor de construit. De îndată ce înțelegeți elementele constitutive, totul devine mai
ușor de asimilat.
Suportul acestei prezentări este PMBOK 5 care cuprinde o parte a ansamblului de cunoștințe ale MP.
Ghidul nu acoperă toate cunoștințele specifice MP, dar prezintă procesele, instrumentele și tehnicile care
sunt general considerate ca bune practici. În plus, PMBOK promovează un vocabular/dicționar al
termenilor utilizați în MP, un element esențial pentru fiecare profesie.
Totuși țineți cont că ghidul PMBOK 5 (PM body of knowledge – ghidul ansamblului de cunoștințe ale
MP) are peste 600 de pagini (5 grupuri de procese, 10 arii de cunoaștere, 47 de procese), și evident
această prezentare nu poate conține toate informațiile existente în ghid.
Să începem. Ce este un proiect?
Iată o definiție: Un efort (demers) temporar (are un start și un final) întreprins pentru a crea un produs,
serviciu sau rezultat unic (proiect de cercetare, raport, document, sondaj). Sau asta este definiția
operațiunilor? Nu, diferența dintre un proiect și operațiuni este relativ simplă: un proiect se termină, are
un caracter temporar. Implementați un proiect, îl finalizați, obțineți un produs/serviciu/sau rezultat unic,
și gata, în timp ce operațiunile sunt continue, repetitive.
În plus proiectul este elaborat progresiv, în timp. La momentul în care începem un proiect nu cunoaștem
toate detaliile.
Indiferent de mărimea lui, un proiect are 3 componente: un OBIECTIV specific (un produs, serviciu sau
rezultat unic), un program (date de începere și finalizare bine determinate), și resursele necesare. Fiecare
componentă le afectează pe celelalte (de ex. extinderea caracteristicilor produsului dorit fie va conduce la
prelungirea termenului de finalizare al proiectului fie la costuri suplimentare datorate orelor suplimentare
plătite membrilor echipei proiectului sau creșterii numărului acestora)

De ce doar 3 componente:
- singurul motiv pentru care există un proiect este pentru a genera rezultatele specificate în
scopul proiectului.
 - Date de finalizare este esențială, întrucât rezultatul dorit trebuie livrat până la un termen pentru
a satisface nevoia.
- Disponibilitatea resurselor configurează natura produsului care poate rezulta din execuția
proiectului.
PMBOK pune accent pe ideea că riscul (probabilitatea ca nu totul să meargă conform planului) joacă un
rol important în definirea proiectului, iar conducerea cu succes a unui proiect implică gestionarea
continuă a compromisurilor între cele 3 componente ale proiectului.
Poate ați auzit de termenii program și portofoliu, haideți să lămurim termenii. Programele sunt mai multe
proiecte combinate (proiecte legate: grup de proiecte, subprograme, activități administrate într-o manieră
coordonată în vederea obținerii de beneficii care nu ar putea fi obținute prin administrarea individuală a
acestora), iar portofoliul este ceva similar ca structură, mai multe programe combinate (grupuri de
programe în vederea atingerii obiectivelor strategice).
Să presupunem că organizația Dvs. dorește să inițieze un program de reducere a costurilor de operare cu
20%. Pentru aceasta se vor derula mai multe proiecte. Un proiect ar putea fi gestionarea eficientă a
portofoliului de clienți, un alt proiect ar putea fi eficientizarea activităților de logistică, alt proiect
reducerea costului total de producție. Deci obiectivul programului de reducere a costurilor presupune ca
activitățile de eficientizare să nu conducă la creșterea costurilor. La nivelul de programe se administrează
și eventualele conflicte dintre proiecte.
Aprobarea unui proiect nou vine de la nivelul decizional al portofoliului. Resursele financiare sunt
întotdeauna limitate, ca urmare organizația trebuie să decidă ce mix de proiecte, programe și operațiuni
generează maximul de beneficii sau asigură atingerea obiectivelor strategice. Obiectivul strategic poate fi
maximizarea profitului dar ar putea fi de ex. și atingerea unei cote de piață, creșterea satisfacției clienților,
etc.
Proiectele însă pot fi și independente, nu neapărat parte a unor programe.
Deci avem pe nivele de complexitate proiect, program și portofoliu.
Înainte de a continua trebuie să înțelegeți ceva foarte important: pentru a derula orice proiect, aveți nevoie
de 2 metodologii (ansamblu de metode de cercetare folosite într-o știință). Prima este ciclul de viață al
proiectului iar a doua este grupul de procese al MP. Adesea cele două metodologii sunt confundate,
ceea ce nu este acceptabil.
Pentru a administra proiecte avem nevoie de un manager de proiect. Acesta trebuie să aibă anumite
competențe. Competențele pot fi grupate în 3 categorii: cunoștințe, performanțe (realizări deosebite într-
un domeniu de activitate) și aptitudini interpersonale. Deci simpla acumulare a cunoștințelor din
domeniul PM nu este suficient pentru a fu un bun MP. Este necesar să aplicați aceste cunoștințe
acumulate în proiectele pe care le administrați. Deci MP trebuie să aibă aptitudinea de a aplica
cunoștințele din domeniu în administrarea și execuția proiectului. O mare parte a timpului MP
interacționează cu oameni, gestionează comunicarea, deci sunt necesare aptitudini pentru a motiva,
comunica, influența, direcționa, negociere, asculta, atenua conflicte, controla resursele umane.
Să începem cu ciclul de viață al proiectului.
Ciclul de viață al unui proiect este o succesiune de faze prin care trece proiectul de la începere până la
încheiere. O fază (etapă) este o colecție de activități aferente proiectului corelate logic și care au ca punct
culminant finalizarea a una sau mai multe livrabile ale procesului. Indiferent de mărimea lor, fiecare
proces trece prin următoarele 4 faze (o structură generală): inițierea proiectului, pregătirea și organizarea,
execuția lucrărilor proiectului, încheierea.
Ciclul de viață al unui proiect este unic pentru acel proiect, pentru o industrie sau pentru nevoile Dvs. El
poate fi personalizat. Gândiți-vă în felul următor: dezvoltarea Dvs. personală este un proiect. Deci ciclul
Dvs. de viață constă din: concepere, naștere, copilărie, adolescență, maturitate și deces. Dacă ne gândim
la un proiect din domeniul IT ciclul de viață ar putea fi: proiectul general, proiectul detaliat, codificarea,
testarea, instalarea, încasarea (dacă a fost derulat pentru un client). Deci acesta este ciclul de viață al unui
proiect, și probabil de aici vine confuzia: termenul de ciclu generează confuzia, pentru că după ce mori nu
trebuie să fi din nou conceput, deci nici născut din nou. Cel puțin așa cred. Dar cine știe. Deci în
momentul în care predai produsul clientului, nu trebuie să-l proiectezi din nou, deci nu este de fapt un
ciclu, este doar un termen folosit dar care poate crea confuzie. Este secvențial de fapt. Este o secvență
(înșiruire) ale diferitelor faze/etape ale proiectului. Și aceste faze sunt unice pentru proiectul respectiv sau
pentru nevoile Dvs. Deci un ciclu de viață poate avea o fază sau mai multe precum în exemplele date
anterior. Nu există o singură cale pentru a defini structura ideală a unui proiect. De exemplu o companie
ar putea trata un studiu de fezabilitate ca prima fază a unui proiect, o altă companie ar putea să o trateze
ca pe a doua fază a unui proiect, în timp ce o altă companie ar putea să nici nu includă studiul de
fezabilitate în proiectul său. Asta înseamnă personalizarea.

Acum să vorbim despre al doilea element de care aveți nevoie pentru a derula orice proiect, iar acesta este
Procesele MP sau grupurile de procese. Dacă urmăriți ghidul, veți observa că nu puteți personaliza
grupurile de procese. Puteți personaliza procesele din cadrul unui grup, dar nu grupul în sine.
Sunt 5 grupuri de procese: Inițierea, planificarea, execuția, monitorizarea și controlul, iar în final
încheierea. Aceste grupuri sunt fixe.

Am pomenit că ciclul de viață este - într-o foarte mare măsură - personalizabil. În realitate, pentru
proiectele mici simplificăm lucrurile. În loc să atașăm grupuri de procese fiecărei faze /etape a ciclului de
viață al unui proiect (pentru realizarea proiectului detaliat cele 5 grupuri, pentru codificare din nou cele 5
grupuri, implementare iar cele 5 grupuri, etc.), în realitate atașăm grupurile de procese unei singure faze a
ciclului de viață al unui proiect. Această simplificare ușurează derularea proiectelor. Deci ciclul de viață
al unui proiect nu constă în succesiune grupurilor de procese de inițiere, planificare, execuție,
monitorizare/control și încheiere.

În continuare vom vorbi despre grupurile de procese și în paralel voi prezenta modul de documentare al
unui proiect pentru a demonstra cum stau lucrurile în realitate.
Proces: o serie de etape (pași) necesare pentru a realiza o funcție particulară (procesul de aprovizionare,
procesul de bugetare). Un proces nu este o activitate unică care generează un rezultat specific, ci este o
descrierea a modului în care o funcție particulară trebuie executată pentru a se obține rezultatul dorit.
Primul grup de procese este INIȚIEREA (Procese efectuate pentru a defini un nou proiect sau o nouă
fază a unui proiect deja existent, în cursul cărora se obțin autorizațiile necesare pentru a demara
proiectul sau faza de proiect). Vom folos ca exemplu construirea unei bărci. În acest grup avem două
procese: primul proces este crearea cartei proiectului iar al doilea este identificarea stakeholderi-lor
(părților interesate).
Carta proiectului este un document relativ simplu care schițează câteva lucruri. Este ca un mini-plan al
proiectului, o schiță simplificată a viitorului proiect. În esență în acest document găsiți răspunsul la
întrebarea de ce faceți ceea ce faceți.
În cazul nostru, dacă ar trebui să elaborăm carta proiectului pentru construirea unei bărci, aceasta ar
include premisele (argumentele - este un proiect realizat din hobby pentru ocuparea timpului liber din
weekenduri), obiectivele proiectului (realizarea unei copii la scara 1:15 a unei bărci cu motor cu
telecomanda), livrabilele majore ale fazei de execuție (rezultate unice verificabile pentru finalizarea
unui proces, fază sau proiect), rolurile și responsabilitățile (cine va lucra la proiect și ce responsabilități
va avea – nu trebuie făcute nominalizări în această fază, se face referire doar la rol), stakeholderii cheie,
estimarea brută a costului și timpului necesar (bugetul de cheltuieli în linii mari). În cadrul inițierii nu
dorim ca documentul să fie foarte detaliat. Vom detalia toate aspectele mai târziu, în cadrul grupului de
procese de planificare.
Așadar, și în cazul Dvs., carta proiectului poate fi la fel de simplă ca să explicați de ce luați în considerare
extinderea către piețele externe, de ce aveți în vedere construirea unei noi fabrici, etc. Mai repet încă o
dată. Acesta nu este momentul pentru a intra în detalii. Vorbim despre premisele afacerii și poate
obiectivele generale ale proiectului, livrabilele majore, despre roluri și responsabilități. Dar aș dori să
subliniez încă o dată: dacă proiectul dvs. nu este unul foarte mare, încercați să evitați să cuprindeți prea
multe detalii în carta proiectului.
Întrebarea evidentă este atunci: de ce să o mai facem? Adică, dacă nu este detaliată și nici nu are prea
multe informații, de ce să mai pierdem timpul pentru a o pregăti?
Motivul pentru care facem asta este să avem un argument pentru a susține decizia de realizare a
proiectului (buy-in). Vrem să obținem sprijin din partea conducerii/sponsorului pentru a petrece mai mult
timp și poate pentru a cheltui mai mulți bani pentru a-l planifica corect.
De fapt dorim să aflăm dacă - mult stimatul sponsor – este de acord să explorăm un pic mai mult acest
proiect? Este ca un punct de control. Este posibil ca sponsorul proiectului nostru să nu dorească deloc
acest proiect. Dacă spune nu, de ce să mai pierdem timpul cu planificarea. Și fiți convinși, planificarea nu
este o sarcină ușoară.
Așadar, este o oportunitate excelentă pentru conducerea superioară să oprească în fașă proiectul, înainte
de a petrece mult timp planificând un proiect care va sfârși doar ca un dosar într-o arhivă. Poate că nu vor
să se extindă pe o nouă piață, poate că nu vor să deschidă acea nouă fabrică. Deci, opresc proiectul
devreme.
Dar vreau să deschid o paranteză aici și să mă contrazic puțin. Ceea ce trebuie să faceți sau cât de multe
detalii doriți să includeți în fiecare grup de procese, inclusiv în grupul de procese de inițiere depinde în
mare măsură de complexitatea proiectului și de domeniul în care se derulează. Așadar, dacă proiectul
Dvs. creează o stație spațială internațională, atunci etapa de inițiere va include mult mai multe detalii, va
fi aproape ca o planificare detaliată. Iar motivul pentru asta este că planificarea unui asemenea proiect, a
Stației Spațiale Internaționale costă peste 10 miliarde de dolari. Și vorbim doar de planificare ei. Așadar,
vi se va solicita să prezentați mult mai multe informații sponsorului dvs. de proiect pentru a obține o
aprobare pentru o planificare ce valorează 10 miliarde.
Al doilea proces din cadrul grupului de proces de inițiere, este Identificarea părților interesate. O parte
interesată („stakeholder”) este o persoană, un grup sau o organizație care poate afecta sau poate fi afectată sau
are percepția că poate fi afectată de o decizie, activitate sau un rezultat al proiectului.

În această etapă, veți limita conținutul acestui document (registrul părților interesate) la ceea ce este strict
necesar și cât mai simplu. Nu veți categoriza toate părțile interesate pe baza influenței lor. Veți face asta
mai târziu, în etapa de planificare. Acum, așa cum am menționat anterior, vrem doar să știm dacă ar trebui
să continuăm sau nu. Este tot un punct de control.
Așadar, tot ce trebuie să faceți este să creați o listă în Excel, să prezentați părțile interesate cu care veți
relaționa și să faceți a analiză sumară a acestora pentru a le înțelege mai bine nevoile, pentru a înțelege
nivelul lor de influență și interes în proiect. Denumirea acestei liste este Registrul stakeholderilor (părților
interesate).
În cazul exemplului nostru, părțile interesate vor fi: soția mea ea va fi sponsorul proiectului. Apoi vecinii
mei pentru că voi da multe găuri, voi ciocăni și șlefui o grămadă, deci voi face mult zgomot. Prin urmare,
trebuie să-i includ ca părți interesate. Și voi fi eu ca manager de proiect.
Pentru majoritatea proiectelor, principala parte interesată este sponsorul proiectului. Cine este sponsorul
Dvs.? Cine vă dă sau nu acordul pentru continuarea proiectului? Apoi cine este managerul de proiect?
Dvs. sunteți managerul de proiect? Cine va face parte din echipa de proiect? Cine va face parte din echipa
de management a proiectului? Echipa de management a proiectului poate fi diferită de membrii echipei
proiectului.
Bun. În momentul în care avem carta proiectului și registrul părților interesate putem trece la planificare.
Desigur, cu condiția să obținem în prealabil toate aprobările pentru a continua.
Ca urmare, după ce am inițiat proiectul și am primit aprobările necesare este timpul să-l planificăm.
Planificarea proiectului (Procese necesare pentru a stabili conținutul proiectului, detalierea obiectivelor și
pentru a defini strategia de acțiune necesară pentru a atinge obiectivele asumate prin proiect )

Planificarea este mult mai detaliată și cuprinzătoare decât inițierea. Vom discuta o mulțime de detalii și
vom face apel la câteva domenii (arii) de cunoaștere (knowledge area – procese, practici, tehnici,
metode folosite).
În planificare dorim să aflăm răspunsul la trei întrebări principale: Ce urmează să facem? Cum vom face?
De unde știm că proiectul a fost finalizat? Această ultimă întrebare este foarte importantă, pentru că în
realitate multe proiecte nu se finalizează niciodată. Deci la finalul procesului de planificare vom avea un
plan complet/cuprinzător al proiectului. Acest plan va include câteva elemente: cerințele proiectului,
definirea conținutului proiectului (project scop), structura ierarhizată a lucrărilor WBS (Work
Breakdown Structure), vom avea programul de execuție al proiectului (programarea în timp a lucrărilor),
vom avea costul, bugetul și calitatea. În realitate mai există și alte domenii de cunoaștere pe care nu le
abordăm acum. Ghidul PMBOK include mult mai multe procese cu intrările și ieșirile lor (domenii de
cunoaștere), dar acum simplificăm lucrurile, pentru a înțelege fundamentele, ca atunci când citiți ghidul
restul să fie ușor de înțeles.
Deci primul proces al grupului de planificare este colectarea cerințelor proiectului: Colectarea cerințelor
implică înțelegerea a ceea ce-și doresc stakeholderii. Dacă vă aduceți aminte, am făcut asta când am
elaborat carta proiectului. Așadar vom porni de la carta proiectului pe care o vom DETALIA și vom da
mai multe specificații. Așadar în proiectul nostru de construire a unei bărci este super simplu, avem puțini
stakeholderi care contează: soția și cu mine. Dar în cazul uni proiect mare, va trebui să aveți o întâlnire cu
principalii stakeholderi și să vă asigurați că includeți cerințele lor în plan.
De unde știm cine ne sunt PI? Păi să ne uităm în registrul PI.
Aceasta nu este o sarcină foarte simplă în realitate. Colectarea cerințelor este partea mai ușoară, ce este
mai greu este să-ți menții judecata sănătoasă (sănătatea mentală), pentru că în momentul în care începi să
colectezi cerințele, toți vor dori să aibă ce e mai bun în toate, fără să țină cont de buget, calitate sau
programă. Ca urmare vom avea o serie de cerințe contradictorii. Vor fi conflicte. Iar în acest punct nu
știm încă bugetul sau calitatea sau programa. Avem o idee vagă, dar nu știm detaliile. Ca urmare, trebuie
să culegem cerințele pe baza estimărilor noastre, iar asta nu este simplu de realizat. Dacă de exemplu soția
zice hai să cumpărăm o mașină nouă, a sosit momentul și mă întreabă ce mașină îmi doresc, prima mașină
care îmi vine în minte este un Porsche Cayenne. Nu voi lua în considerare bugetul familiei, sau costurile
de mentenanță, voi spune doar ce-mi doresc. La fel este și în MP. Când îi întrebi pe stakeholderi ce-și
doresc, vor cere luna de pe cer, vor dori tot ce este mai bun. Ca manager de proiect trebuie să ți lucrurile
în frâu, și să explici oamenilor că întotdeauna trebuie să facem compromisuri în viață. Un mic sfat: atunci
când colectați cerințele, sunt așa de multe metode disponibile: puteți realiza interviuri față în față, puteți
utiliza tehnica Delphi, puteți folosi metoda grupului nominal (https://jurnaluldeafaceri.ro/tehnici-de-luare-
a-deciziilor-tehnica-grupului-nominal/), sau alte metode. Dar dacă este posibil adunați-i într-o cameră sau
la o teleconferință și colectați cerințele colectiv. Dacă faceți interviuri față în față veți avea o serie de
cerințe contradictorii. Adunați-i la un loc, lăsați-i să-și prezinte argumentele, lăsați-i să se lupte, dar în
final veți avea cerințele stabilite.
Următorul proces este realizarea definirea conținutului proiectului (project scope). Aceasta se face
selectând elemente necesare, clare și excluderea elementelor nerelevante (ca atunci când privim printr-un
binoclu, vedem doar ce este în orizontul binoclului). Pentru aceasta avem nevoie de carta proiectului, apoi
de documentul cu cerințele proiectului, apoi orice estimări ale riscurilor, ale constrângerilor, orice
informații avem care să ne ajute să detaliem obiectivele. Definirea conținutului proiectului este una dintre
cele mai importante procese, pentru că ce se întâmplă în realitate este că manageri de proiect slabi fie
includ în proiect tot ce cuprinde documentul de cerințele proiectului respectiv carta proiectului fie
definesc foarte vag conținutul. Rezultatul este că planul proiectului este imposibil de realizat. Deci dacă
faci o treabă de mântuială când detaliezi conținutul proiectului, atunci nu vei fi capabil să duci la bun
sfârșit planul. Conținutul proiectului trebuie să fie foarte clar specificat. Deci declarația conținutului
proiectului (Project scope statement - document în care se descriu conținutul, livrabilele, ipotezele și
constrângerile majore ale proiectului.) poate include justificarea proiectului, detalierea conținutului
proiectului, livrabilele proiectului, criteriile de succes. Documentul nu ar trebui să includă nimic
interpretabil.
Acum să vorbim despre un concept denumit Referinţa conţinutului / Scope Baseline (Versiunea
aprobată a definirii conținutului, a WBS și a dicționarului WBS, care poate fi schimbată doar prin
proceduri formale de control al schimbărilor și este folosită ca bază de comparație.)
Referința conținutului: cuprinde 3 elemente: declarația conținutului proiectului, WBS (work breakdown
structure - structura ierarhizată a lucrărilor) și dicționarul structurii ierarhizate a lucrărilor.
WBS poate fi considerată inima MP. Indiferent ce metodologie folosiți la elaborarea lui, ea este foarte
foarte importantă.
WBS descompune proiectul în părți mai mici, mai ușor administrabile. În fapt descompunem livrabilele
iar rezultatul sunt WORK Packages – pachete de lucrări. Vreau să subliniez un lucru: dacă urmăm
strict cadrul PMI atunci pachetele de lucrări trebuie să fie lucruri. Nu pot fi acțiuni. Trebuie să fie
livrabile: pot fi documente, clădiri, obiecte palpabile. Totuși în practică nu se întâmplă așa. Se folosesc
metode hibride, în care pachetele de lucrările conțin și activități.
Nivelul de detaliere/descompunere până la care se ajunge (câte nivele are structura ierarhizată) se află
răspunzând la următoare întrebare: puteți estima cu un grad acceptabil de certitudine necesarul de timp și
bani pentru pachetul de lucrări respectiv? Dacă nu puteți, trebuie să descompuneți la un nivel și mai
detaliat până când puteți face estimări ale necesarului de timp și bani. În cazul exemplului nostru, nu
putem spune la nivelul de detaliere de până acum cât ne va lua să-l finalizăm, dar putem estima cât timp
ne va lua să-l laminăm, cât durează operațiunile de tâmplărie, construirea cadrului, etc. Deci detaliem
până la nivelul la care putem estima costurile după care prin agregare obținem costul total (și durata
totală).
Deci să elaborăm WBS-ul. Pe nivelul 1 trecem denumirea proiectului, apoi segmentăm proiectul în
diverse lucrări (tipuri de lucrări). În exemplul nostru proiectul bărcii, producția, partea electronică,
echiparea (catarg, vele, parâme) și testarea. Numerotăm fiecare lucrare (1.1, 1.2, etc.). Și acest nivel este
încă prea complex pentru a putea estima costurile și durata, deci trebuie să continuăm detalierea. La un
proiect de această complexitate nu avem nevoie de sub-segmente, dar la proiecte mai complicate, da.
Acum urmează să identificăm pachetele de lucrări. Pentru proiectare avem nevoie de proiectul original al
bărcii în mărime naturală, apoi trebuie realizat proiectul la scara machetei, apoi trebuie finalizat proiectul
(să-l modific după gustul meu) ca să fie gata de execuție. Pentru producție, pachetele de lucrări sunt: în
primul rând alegerea materialelor folosite pentru construcția bărcii, apoi trebuie să le aprovizionez, apoi
trebuie să decupez pentru a construi structura, montarea punții și a carenei, laminarea (cu fibră de sticlă),
apoi asamblarea celor 2 subansamble, șlefuirea, vopsirea. La partea electronică adoptarea deciziei privind
componentele folosite și achiziționarea lor, apoi asamblarea lor și testarea componentelor. Echiparea va
conține pachetele decizia asupra elementelor de echipare și achiziția lor, apoi instalarea acestora. Iar pe
ultimul segment testarea părții electronice, testarea echipamentelor, testarea completă în bazin, testarea pe
lac.
Mai subliniez o dată importanța elaborării WBS. Tot ce se execută de acum încolo în cadrul grupelor
proceselor de planificare (calculul costurilor, programare, evaluarea riscurilor), are la bază această
diagramă/document. Nu facem calcule de costuri la nivelul proiectului, o facem la nivelul pachetelor de
lucrări. Înainte de a merge mai departe să revenim la referința conținutului care avea 3 componente. Le-
am prezentat pe primele două, a mai rămas de prezentat dicționarul WBS.
Dacă nu definim corect pachetele de lucrări, suntem predispuși/expuși la devieri de la obiective. Vă
aduceți aminte de exemplu cu Porsche Cayenne? Dacă nu ținem sub control și scăpăm lesa din mână,
ajungem să cumpărăm un Porsche Cayenne Turbo S-E Hybrid. Părțile interesate ne vor împinge
întotdeauna să facem mai mult, extinzând obiectivele/limitele. Așa că în calitate de manager de proiect,
vom crea un dicționar pentru fiecare pachet de lucrări din WBS. De exemplu ce înseamnă pachetul de
lucrări construirea structurii calei, adică explicăm fiecare pachet punând limite. În acest mod, nimeni nu
poate extinde.
PMBOK cuprinde și alte domenii de cunoaștere precum RU, comunicarea, managementul riscului (poate
partea cea mai complexă – spre fericire nu este utilizată în 99 % din proiectele mici), calitatea,
aprovizionarea, etc.
Să continuăm cu managementul timpului sau programarea lucrărilor. Începem prin a estima duratele
pachetelor de lucrări. Un aspect important de luat în considerare la acest punct: dacă nu puteți estima cu
un grad ridicat de certitudine cât va dura finalizarea unui pachet de lucrări particular din WBS, atunci
trebuie să descompunem mai departe pachetul respectiv până la nivelul de activități componente. Acum
urmează partea distractivă: stabilirea succesiunii lucrărilor (condiționărilor, determinarea drumului critic,
etc). În realitate se folosește MS Project. Pentru proiectele simple însă este nevoie doar de diagrama
Gantt. Diagrama Gantt este o cale foarte simplă de a lista pachetele de lucrări pe o scară a timpului
potrivită proiectului. Fiecare pachet de lucrări este reprezentat sub forma unei bare care ne indică
momentul începerii pachetului de lucrări, durata și momentul finalizării. Durata este reprezentată prin
lungimea barei. Putem folos MS Project, MS Excel sau PP, în funcție de complexitatea proiectului. În
cazul proiectului nostru se poate face manual în PP.
Acum să vorbim pe scurt despre 2 termeni pe care-i veți auzi des utilizați. Paralelizarea unui proiect
(Fast tracking) înseamnă execuția simultană (în paralel) a mai multe activități (grupe de lucrări), adică
pe graficul Gantt mai multe bare vor intersecta aceeași axă verticală. Accelerarea proiectului (project
crashing) înseamnă scurtarea duratei grupului de lucrări prin adăugarea de resurse suplimentare. De
exemplu dacă 2 persoane termină o lucrare in 30 zile, în câte zile vor termina lucrarea 4 angajați?
Bineînțeles accelerarea vin cu un cost suplimentar (costul resurselor suplimentare implicate). Poate ați
văzut construirea unui bloc turn în China în 30 de zile pentru ca nu au lipsă nici de forță de muncă nici de
resurse financiare.
Managementul costurilor. Pornind din nou de la WBS, dar de data această în loc să estimăm durata
pachetului de lucrări estimăm costurile fiecărui pachet. Este ceva foarte similar programării lucrărilor.
Pentru aceasta e bine să folosiți EXCEL. După ce însumați costurile directe și indirecte variabile sau fixe,
puteți crea un buget. Să nu uităm că în cazul proiectelor complexe, trebuie elaborat registrul riscurilor,
estimate contingența riscurilor (posibilitatea ca un risc să aibă sau nu loc) care vor fi incluse în buget sau
Rezervă managerială / Management Reserve (Sumă prevăzută ca rezervă de management în bugetul
proiectului cu scop de control din partea managementului. Acestea sunt bugete rezervate pentru lucrări
neprevăzute ce pot apărea în domeniul de aplicare a proiectului.) Se agregă costurile obținându-se o
valoare aproximativă pentru bugetul proiectului. Se includ apoi estimările contingențelor care provin din
studiul riscului și se obține referința costurilor (cost baseline). Apoi se include rezerva managerială și
se obține bugetul costului. În realitate, în 99% din cazuri nu facem analiza contingențelor ci agregăm
costurile pachetelor de lucrări și adăugăm o rezervă de 20% și am terminat planificarea.
Urmează grupul de procese Execuția (Grup de procese efectuate cu scopul de a finaliza activitățile definite
în planul de management al proiectului, astfel încât obiectivele proiectului să fie îndeplinite. )

Scopul acestui grup de procese este realizarea lucrărilor definite prin planul proiectul și atingerea
obiectivelor. Aici facem munca efectivă. Focusul Dvs. în calitate de manager de proiect este acum pe
managementul echipei proiectului, urmărirea proceselor, și administrarea schimbului de informații. În
esență rolul Dvs. este de ghidare a echipei ca această se se țină de planul elaborat. Dacă planificarea a fost
corectă, de calitate, execuția este simplă. Chiar dacă durează mult mai mult decât planificarea, este mai
simplă, ca un joc de lego de a pune piesele la locul lor. Dacă în schimb planificare nu a fost bună, atunci
execuția va și un coșmar. Dacă procesele de execuție nu le efectuați Dvs. ceea ce trebuie să faceți este să
administrați în mod continuu așteptările stakeholderilor. Trebuie să vă protejați obiectivele. Veți realiza
foarte repede că stakeholderii vor să placați totul în aur (adică să faceți schimbări ale proiectului care sunt
înafara limitelor stabilite). De exemplu în loc să folosiți materiale de calitatea normală așa cum s-a
convenit, să folosiți materiale de calitate superioară. Aceasta este o problemă pentru că nu ați bugetat
costurile și nici estimat timpul pentru procurarea unor astfel de materiale. Deci trebuie să preveniți
devierile de la obiective (să le protejați împotriva oricăror schimbări nenecesare). Evident dacă cerințele
sunt legitime, le puteți evalua și aproba.
Următorul grup de procese este monitorizarea și controlul. Monitorizare și control înseamnă măsurarea
performanțelor proiectului relativ la plan, administrarea cererilor de modificare și asigurarea atingerii KPI
(Key Performance Indicator) dacă au fost incluse în plan. Un aspect important: monitorizarea și controlul
încep cu grupul de procese de execuție, deci rulează în paralel. Deci monitorizare și controlul se fac în
timpul execuției și nu după finalizare. Monitorizăm obiectivele, ne asigurăm că nu apar abateri de la
obiective, monitorizăm programarea lucrărilor și facem prognoze dacă considerăm că vor fi întârzieri.
Aceasta este simplu de realizat întrucât avem deja programarea lucrărilor (puse în graficul Gantt). Apoi
trebuie să monitorizăm costurile calitatea, riscurile și aprovizionarea. Este relativ simplu, de exemplu ați
încheiat un pachet de lucrări, și puteți privi retrospectiv dacă toate se încadrează în limitele stabilite. Dacă
nu, analizați cauzele, de ce am depășit bugetul sau durata? Apoi în mod evident rezolvați problemele ca să
nu se repete. Și vă asigurați că documentați totul. Atunci când aprofundați MP, vă loviți de calculele
Calculul valorii dobândite (earned value calculation). Este foarte important în acest stadiu al
proiectului. Să vorbim puțin despre valoarea dobândită. Valoarea dobândită se calculează ca valoarea
totală a bugetului înmulțit cu procentul de realizare al proiectului. De ex. în cazul unui proiect de 1 milion
de dolari care a fost realizat în proporție de 20% valoarea dobândită este de 200.000 USD. Această
metodă este utilizată mai ales în domeniul construcțiilor și proiectelor software, și este un concept
important în MPI. Dar în realitate, nu are mare valoare înafara câtorva domenii. Motivul este că valoare
dobândită nu poate fi evaluată pe măsură ce proiectul progresează, întrucât evoluția costurilor nu este
liniară. În cele mai multe cazuri, evoluția valorii dobândite a proiectului are o evoluție exponențială. Deci
concluzia este oricare ar fi proiectul nu renunțați dacă nu vedeți rezultatul imediat. Rezultatele vor veni
conform acelei evoluții exponențiale.
Ultimul grup de procese este finalizare (Toate procesele executate pentru finalizarea tuturor activităților din
toate grupurile de procese în vederea încheierii în mod oficial a unui proiect sau a unei faze )

Am obținut produsul, serviciul rezultatul (în cazul nostru barca). Este proiectul terminat? NU. Mai este
puțin de lucrat, în general chestiuni administrative, plictisitoare. Ce facem în cadrul acestui grup depinde
de nevoile și complexitatea proiectului. Dar sunt câteva elemente importante de făcut: în primul rând
predăm produsul clientului și trebuie să obținem o aprobare, o semnătură a acestuia. Apoi finalizăm
procesele de achiziție, adică facem plățile finale și înregistrăm costurile. Adunăm lecțiile învățate, adică
documentăm ce a mers prost și ce am învățat din asta? Apoi deblocăm (realocăm) resursele, permit
membrilor echipei de proiect să se întoarcă la echipele din care provin și în final sărbătorim.
12 termeni pe care trebuie să-i cunoașteți:
1. RAG status – statusul proiectului (red, amber (chihlimbar – galben), green) – indică dacă ceva este ăn
parametrii sau înafara parametrilor proiectați – roșu – ceva este foarte greșit
2. WBS – structura ierarhică a lucrărilor- unul din primele livrabile ale proiectului
3. Graficul Gantt (programarea Gantt) – o succesiune logică a lucrărilor
4. Triplele constrângeri (timp, cost, obiectiv – un triunghi, se influenteaza reciproc)
5. Metodologia – cadrul pentru administrarea proiectului (PRINCE 2, PMBOK, AGILE, combinații ale
acestora)
6. Business case – studiul de fezabilitate (carta proiectului) – un document fundamental al proiectului ???
7. Requirement (cerințele proiectului) – ce trebuie să producă proiectul (3 compoennte, afacere, părți
interesate, soluție)
8. Risc – poate sau nu să aibă loc, dacă are loc poate avea efect pozitiv sau negativ asupra proiectului.
Riscul poate fi sau nu controlabil.
9. Issue (probleme) – ceva ce se întâmplă cu proiectul Dvs. chiar acum, asemănător unui foc intens, ceva
ce nu a fost identificat ca un potențial risc dar care trebuie rezolvat acum
10. Milestone – Repere – sutn ancore, care de obicei se reprezintă pe diagrama Gantt sub forma unor
trapeze, este doar o referințpă vizuală
11. Părțile interesate – persoană sau grup de persoane care vor fi sau cred că vor fi influențate direct sau
indirect de proiect
12. Steering committee – un grup de persoane care au sarcina să ofere îndrumare strategică MP, și au
rolul de a-l sprijină pe acesta
Glosar de termeni:

ACCEPTANCE CRITERIA – Criterii de acceptanță – acele criterii, inclusiv cerințele de performanță și

alte constrângeri care trebuie îndeplinite înainte ca livrabilele proiectului să fie acceptate de către client
BUSINESS CASE – STUDIU DE FEZABILITATE
PROJECT CHARTER - Carta proiectului Document emis de iniţiatorul sau de sponsorul
proiectului ce autorizează în mod formal existenţa unui proiect și furnizează managerului proiectului
autoritatea necesară de a utiliza resursele organizaţiei pentru implementarea activităţilor.
BASELINE – Referinţă Versiune aprobată a unui produs sau a lucrărilor ce poate fi modificată
numai prin proceduri formale de control al schimbărilor și este folosită ca bază de comparație.
DELIVERABLE – Livrabil Produs / Rezultat unic și verificabil sau capacitate/aptitudine unică și
verificabilă de a efectua un serviciu necesar pentru finalizarea unui proces, fază sau proiect.
PMI – PROJECT MANAGEMENT INSTITUTE – Institutul de management de proiect – organismul
internațional care gestionează emiterea de standarde de management de proiect și oferă certificarea
internațională PMP (Project Management Professional)
PMBOK – Ghidul ansamblului de cunoștințe ale managementului de proiect
PROGRAM / Program Grup de proiecte, subprograme i activităţi interrelaţionate, administrate
într-o manieră coordonată în vederea obţinerii de beneficii care nu ar putea fi obţinute prin
administrarea individuală a acestora.
PORTOFOLIO / Portofoliu Proiecte, programe, subportofolii i operaţiuni administrate ca grup în
vederea atingerii obiectivelor strategice.
PROJECT CHARTER – Carta proiectului – (Propunere de proiect)
PROJECT SCOPE – Aria de cuprindere, domeniul de aplicare, cerințele, specificațiile proiectului
SCOPE STATEMENT – caiet de sarcini – descrierea livrabilelor, presupunerilor, constrângerilor,
descrierea efortului necesar pentru atingerea obiectivelor
SCOPE – aria de acoperire a proiectului – ansamblul produselor, serviciilor și rezultatelor pe care
proiectul trebuie să le livreze
A work package (Pachete de lucrări)
WBS – work break down structures – Structura ierarhizată a lucrărilor Lista de livrabile într-o structura
ierarhică a livrabilelor. Împărțirea pe livrabile a a activității necesare a fi executate de către echipa de
proiect. Organizează și definește aria de cuprindere a proiectului.
ISSUE LOG - Problemele apar frecvent în cursul conducerii echipei proiectului. Un registru al problemelor
(“Issue Log”) poate fi utilizat pentru a documenta și monitoriza CINE este responsabil pentru rezolvarea unor
probleme specifice (CE) și la ce termene (CÂND).

https://www.youtube.com/watch?v=ZKOL-rZ79gs
https://www.youtube.com/watch?v=DxRrG4pAdJ0
În definirea proiectului vom avea 10 componente necesare pentru o definire bună a unui proiect.
1. Scopul proiectului – este răspunsul la o întrebare simplă – ce este ceea ce vă doriți să faceți – ar fi
bine să fie ceva inspirațional pentru echipa Dvs.
2. Obiectivele – stabilesc constrângeri asupra modului în care vom livra scopul proiectului, ca să
știm dacă am avut succes. Pentru fiecare proiect trebuie decis care sunt obiectivele relativ cu
termene, costuri și calitate. Stabiliți deci criteriile prin care măsurați succesul proiectului.
3. Descrierea conținutului proiectului (SCOPE) – tot ceea ce trebuie să faceți pentru ca proiectul să
fie un succes (lucrările, activitățile pe carele veți derula împreună cu membrii echipei de proiect)
4. Excluziunile din proiect sau lucruri aflate înafara conținutului proiectului, pe care în mod voit nu
le includem în proiect (cerințele nejustificate al părților interesate)
5. Livrabilele proiectului (la scară mare, fără detaliere)
6. Dependențe și constrângeri – dependențele sunt lucruri externe proiectului, dar de care acesta
depinde în timp ce constrângerile sunt limitările ale opțiunilor Dvs. (ex. de dependente: alte
proiecte care rulează în paralel și care fac ca resursele să fie limitate; ex. de constrângeri:
legislația)
7. Riscuri sau probleme care pot afecta proiectul (doar cele mari). Riscurile sunt incertitudini care
pot afecta ieșirile proiectului. Problemele nu sunt incertitudini ci certitudini, care se vor întâmpla
și de care trebuie să ne ocupăm.
8. Incertitudini și presupuneri (ipoteze). Incertitudinile trebuie eliminate atunci când trecem la
planificare
9. Părțile interesate
10. Echipa de proiect – fără nominalizare, doar identificarea rolurilor principale din proiect