Managementul Proiectelor

Curs 3
 Executia Proiectului

• Managementul continutului
• Managementul problemelor
• Managementul riscurilor
• Managementul Indicatorilor
• Managementul calitatii
• Managementul documentelor
• Managementul resurselor umane
• Managementul comunicarii
 Managementul continutului
• Continutul (sfera de cuprindere) este
modalitatea de a descrie granitele proiectului.
Descrie ceea ce va livra si ceea ce nu va livra
proiectul. Pentru proiectele mari, poate
include organizatiile afectate, tranzactiile
afectate si alte informatii implicate, etc.
• Invocarea procesului de schimbare a continutului
implica faptul ca schimbarea este in afara continutului
convenit in Definitia Proiectului si in detalierea
cerintelor de business.
• Daca continutul este ambiguu sau lasa loc de
interpretari, clientul poate pretinde ca schimbarea este
in limitele continutului si managerul de proiect va avea
dificultati in a sustine managementul acestuia.
• Scopul managementului schimbarilor asupra
continutului este protejarea viabilitatii Definitiei
Proiectului in varianta curenta si aprobata, precum si a
cerintelor aprobate de business.
• Managerul de proiect poate crede ca
managementul continutului inseamna sa
spuna “nu” clientului. Aceasta il face pe
managerul de proiect sa se simta nervos si
discomfortabil. Oricum, vestea buna este ca
un management eficace al continutului consta
in arta de a-l face pe Sponsor sa spuna “nu”.
De vreme ce proiectele mici sunt mult mai usor de definit si de obicei
sunt incheiate foarte repede, ele nu au cerinte pentru schimbari
majore ale sferei de cuprindere a proiectului.Daca insa se produc,
acestea sunt modificari minore. Urmatorul proces ar trebui sa
poata fi urmat rapid:
– Schimbarile asupra continutului pot fi initiate de oricine din echipa
proiectului. Acestea trebuie trimise in scris managerului de proiect, fie
pe hirtie, fie prin email, etc. Nu este necesar un formular tipizat.
– Managerul de proiect valideaza daca cererea este cu adevarat o
modificare asupra continutului. In caz afirmativ, se executa restul
procesului.
– Managerul de proiect determina impactul schimbarii asupra
continutului, in ceea ce priveste costul, efortul si durata. Daca exista si
alte optiuni viabile, managerul proiectului determina de asemeni
impactul acestora.
– (Optional) Daca cererea de schimbare poate fi realizata in limitele
costului, efortului si duratei initiale, managerul de proiect si
managerul din partea clientului au flexibilitatea de a decide daca
schimbarea trebuie aprobata. Oricum, sponsorul trebuie sa fi aprobat
delegarea acestei responsabilitati, de obicei pina la o anumita limita in
ceea ce priveste banii si efortul.
– Analiza, alternativele si impactul sunt prezentate Sponsorului
Proiectului pentru rezolutie (daca cererea nu a fost deja aprobata in
pasul 4). Daca sponsorul nu aproba cererea si impactul acesteia, nu se
da curs cererii de schimbare a continutului.
– Din momentul in care rezolutia este convenita, activitatile
corespunzatoare sunt adaugate in planul de lucru pentru a asigura
implementarea cererii.
– Cererea, starea curenta si rezolutia trebuie documentate in Raportul
asupra Starii Proiectului.
 Managementul Continutului / Tehnici
• Controlul cererii minore de schimbare a continutului -Toata lumea
recunoaste si apreciaza ca procesul de gestionare a cererilor de
schimbare trebuie invocat pentru schimbarile mari asupra
proiectului.
– Cu toate acestea, este posibil sa intimpini rezistenta daca vrei sa impui
un proces formal de management al schimbarilor continutului pentru
schimbarile minore. Clientul poate considera ca nu este necesara o
asemenea supraincarcare pentru decizii minore.
– Exista trei tehnici care se pot folosi in cazul schimbarilor minore. Nici
una dintre acestea nu implica si nu sugereaza ca nu se aplica
managementul si urmarirea schimbarilor asupra continutului. Sunt
doar tehnici suplimentare.
– Daca nici una dintre aceste optiuni nu este aplicata, managerul de
proiect trebuie sa utilizeze procesul normal de management al
schimbarii continutului, pentru toate schimbarile.
1. Agregarea cererilor minore - Nu intotdeauna este practic
sa soliciti sponsorului aprobarea tuturor cererilor minore
de schimbare. Echipa proiectului nu are de obicei acces la
Sponsor in fiecare zi si este foarte greu sa-i retina acestuia
atentia pentru multe cereri minore. Este mai bine ca
acestea sa fie agregate in pachete.
– Aceasta inseamna ca se tine evidenta tuturor schimbarilor
minore, valoarea lor de business si impactul lor asupra
proiectului. Apoi, cind volumul lor atinge un anumit nivel, sunt
prezentate Sponsorului pentru aprobare.
– Chiar daca acestea sunt considerate schimbari minore, tot
trebuie supuse managementului schimbarilor asupra
continutului. Altfel, exista riscul dilatarii continutului. Beneficiul
aprobarii schimbarilor minore este aprobarea si a modificarilor
corespunzatoare de buget si timp pentru implementarea lor.
2. Hotarirea managerului de proiect - Din punct de vedere practic,
de obicei este bine ca managerul de proiect si managerul din
partea clientului sa aiba libertatea de a aproba cererile minore de
schimbare, pina la limita unui anumit prag de cost si ore de efort.
Oricum, aceasta abordare presupune ca proiectul se afla in
program sau inaintea programului si ca schimbarile nu conduc la
depasirea costurilor, efortului sau duratei agreate.
– Daca proiectul intimpina riscul neindeplinirii angajamentelor privind
costul, durata si efortul, aceasta libertate nu ar trebui utilizata, chiar
daca este vorba de cereri de schimbare care necesita doar o ora.
– Daca exista acest risc al neindeplinirii angajamentelor, toate cererile
de schimbare a continutului trebuie sa treaca pe la sponsor pentru
aprobare, individual sau in pachete.
– Daca Sponsorul aproba schimbarile, proiectul ar trebui sa
beneficieze de majorari corespnzatoare ale bugetului si termenului.
3. Rezerva bugetara pentru schimbarile continutului). In unele organizatii este o
practica comuna alocarea unei rezerve bugetare dedicata schimbarilor
continutului, pentru a face fata cererilor minore. De obicei nu este necesara nici
o justificare. Organizatia poate admite ca exista intotdeauna o serie de schimbari
ale continutului si poate aloca un procent din bugetul total al proiectului pentru
a le cuantifica. Spre exemplu, poti avea o rezerva de 5% adaugata la buget
pentru schimbari asupra continutului. Daca bugetul total este $500.000, rezerva
bugetara pentru schimbari va fi $25.000.
– Implicatia directa a acestei variante este ca aceasta rezerva bugetara reprezinta tot ce se
aloca pentru cereri de schimbare minore. Clientul trebuie sa gestioneze bugetul pentru a
putea fi sigur ca toate cererile minore de schimbare pot fi realizate. Daca se foloseste toata
rezerva inca de la inceputul proiectului, nu mai ramine nimic pentru a se putea rezolva
cererile care intervin mai tirziu.
– Aceasta il obliga pe client sa evalueze foarte atent schimbarile pentru a fi sigur ca numai
cele mai importante sunt aprobate. Aceasta rezerva bugetara este folosita doar pentru
cereri de schimbare situate sub un anumit prag, exprimat in bani sau ore. In continuare se
pot face si schimbari majore, dar acestea trebuie sa parcurga procesul normal de
management al schimbarilor continutului si trebuie evaluate de catre Sponsor. 
 Nu se utilizeaza rezerva de estimare
pentru schimbari ale continutului
• Unul din pasii procesului de estimare a fost adaugarea unei rezerve de ore
pentru a reflecta nivelul de incertitudine asociat cu estimarea (spre
exemplu, daca s-au estimat 5.000 de ore de efort, se pot adauga 500 de
ore ca rezerva, ceea ce reflecta un factor de incredere de 90%). Odata ce
rezerva este aprobata, managerul de proiect va fi presat sa o foloseasca
pentru a absorbi in proiect cerinte suplimentare. Clientul poate spune “De
ce trebuie sa invocam managementul schimbarilor asupra continutului
pentru o majorare cu 100 de ore? Avem o rezerva de 500 de ore
incorporata in estimare!”.
• Managerul de proiect trebuie sa reziste tentatiei si presiunii. Scopul
rezervei de estimare este de a reflecta incertitudinea asupra estimarilor.
Vor exista o sumedenie de ocazii pentru utilizarea rezervei cind activitatile
vor dura mai mult decit s-a prevazut. Nu folosi rezerva de estimare pentru
a accepta lucrari suplimentare. Daca estimarile au fost precise, rezerva va
fi inapoiata clientului la finalizarea proiectului (Sau se poate considera ca
rezerva se constituie in profit suplimentar, daca este vorba de un client
extern.)
 Inghetarea cererilor de schimbare
asupra continutului
• In functie de natura proiectului, aceasta inghetare poate fi implementata
la momente diferite, dar de obicei nu se face mai tirziu de testarea
sistemului. La acest moment, echipa trebuie sa se poata focaliza pe
testarea riguroasa a solutiei curente. Schimbarile suplimentare pot rezulta
in necesitatea de a reface toate testele. Pina la momentul efectuarii
testarii sistemului, ar trebui sa fi luat in calcul marea majoritate a
cerintelor.

• Se intimpla curent ca unele cereri de modificare sa rezulte din testarea

pentru acceptare de catre utilizator. Clientul poate observa diverse lucruri
pe care le doreste schimbate, ca urmare a testelor. O abordare mai buna
este suspendarea acestor schimbari intr-un jurnal si tratarea lor ca cereri
de extindere dupa ce solutia este implementata si stabila (aceasta se
refera la cereri de schimbare, nu la defecte. Utilizatorul poate descoperi
defecte si erori in cursul testelor pe care le realizeaza, care trebuie
eliminate inainte de implementare).
Doar Sponsorul poate aproba schimbarile – Nu
utilizatorii si managerii din partea clientului

• In conformitate cu un management corespunzator al schimbarilor

continutului, Sponsorul (sau reprezentantul acestuia) poate da
aprobarea.
• Utilizatorii proiectului pot cere modificarea sferei de cuprindere dar
nu o pot aproba.Utilizatorul final nu poate aloca finantare
suplimentara pentru acoperirea schimbarii si nu poate stii daca
impactul asupra proiectului este acceptabil.
• Daca schimbarea este suficient de importanta pentru Sponsor,
acesta o va aproba impreuna cu modificarile corespunzatoare
asupra bugetului si duratei. Daca schimbarea nu este suficient de
importanta, nu o va aproba.
• Oricum, Sponsorul este cel care va lua decizia, nu managerul de
proiect, managerul din partea clientului, echipa de proiect sau
utilizatorii finali.
 A spune “Da” cererilor de schimbare a
continutului arata orientarea catre client?

• Managerul de proiect si echipa considera uneori ca sunt orientati

catre client daca accepta schimbari ale continutului, incercind in
acelasi timp sa livreze in parametrii angajamentelor initiale.
• Oricum, daca proiectul va fi livrat cu intiziere si cu depasire de
buget, de obicei nu este suficient sa arati toate activitatile
suplimentare care s-au facut in numele “orientarii catre client”.
• In cele mai multe cazuri, proiectul nu va fi considerat un succes, de
moment ce nu a fost livrat in bugetul si la termenul promise.
• Sponsorul reprezinta clientul primar.Orientarea catre client este
demonstrata dindu-i Sponsorului ocazia sa ia deciziile asupra
schimbarilor continutului.
• Daca echipa sau managerul de proiect aproba singuri schimbari ale
continutului, nu demonstreaza orientarea catre client, mai ales
daca proiectul se incheie cu intirziere si cu depasire de buget.
 Oricine este responsabil pentru procesul
de management al continutului
• Multe procese de management al continutului merg bine la nivelul managerului de proiect, dar
sunt compromise la nivelul echipei.

• Daca managerul de proiect este eficient in impunerea regulilor de schimbare a continutului,

clientul poate incerca sa discute schimbarile direct cu membrii echipei. Spre exemplu, atunci cind
se livreaza spre analiza un raport convenit anterior, clientul poate solicita un al doilea raport
pentru a obtine mai multe clarificari. Un membru al echipei poate fi de acord sa faca aceasta
munca (pentru a dovedi “orientare catre client”). Rezultatul este ca activitatea dureaza prea mult
sau resursele care trebuiau utilizate la activitati cu prioritate mai mare sunt absorbite intr-o munca
aflata in afara continutului.

• Ideea centrala este ca toata lumea trebuie sa fie raspunzatoare pentru procesul de management al
continutului. Membrii echipei trebuie sa inteleaga procesul si motivele pentru care acesta este
important. Clientii trebuie sa inteleaga de asemeni procesul si importanta lui. Ar fi o greseala sa
consideri ca aceste proceduri sunt de interes doar pentru managerul proiectului si pentru Sponsor.
Asigura-te ca procedurile sunt comunicate intregii echipe.

• Atunci cind clientul solicita direct membrilor echipei schimbari ale continutului, supune acest lucru
atentiei managerului din partea clientului si sponsorului. Atunci cind membrii echipei se angajeaza
la lucrari care sunt in afara continutului, reactioneaza prompt. Cind se intimpla prima oara, poate fi
considerata o problema de instruire. Data viitoare s-ar putea sa fie o problema de performanta.
 Acumularea cererilor de schimbare

• Este posibil ca Sponsorul sa nu aprobe cereri de schimbare in

timpul proiectului, dar acestea pot fi cerinte viabile care pot fi
puse in practica mai tirziu.

• Acest tip de cereri de schimbare trebuie acumulate intr-o

lista.

• Dupa terminarea proiectului, cind solutia trece in productie,

pot exista ocazii pentru imbunatatiri sau pentru o a doua faza
a proiectului.

• Aceste schimbari vor fi implementate numai daca sunt

aprobate si daca exista finantare.
Managementul Continutului / Livrabile

Dimensiunea proiectului Informatii Necesare

Pentru proiectele mici, cererile de schimbare
ale continutului si starea lor curenta trebuie
identificate in Raportul asupra Starii
Proiectului. Deoarece de obicei nu sunt cereri
majore de schimbare a continutului in
Mica proiectele mici, nu sunt necesare livrabile
specifice pentru managementul schimbarilor
continutului. Oricum, revizuieste Jurnalul
Schimbarilor Continutului utilizat in proiectele
medii si mari. Poate fi util in cazul schimbarilor
multiple asupra continutului.
Managementul Continutului / Activitati
suplimentare privind Planul de Lucru
 Managementul
Problemelor (Situatiilor dificile)
• O situatie dificila este definita ca o problema care impiedica
progresul proiectului si nu poate fi rezolvata de catre
managerul de proiect si echipa proiectului, fara ajutor
extern.

• Managementul situatiilor dificile este unul din procesele

fundamentale si constituie una dintre abilitatile pe care toti
managerii de proiect trebuie sa le stapineasca.
• Majoritatea proiectelor de orice dimensiune intimpina
situatii dificile. Acestea nu pot fi ignorate si nu pot fi
aminate pentru mai tarziu. Situatiile dificile trebuie
rezolvate rapid si eficace.
• In general, nu ne asteptam ca proiectele mici sa intimpine situatii cu
adevarat dificile. Pot aparea probleme, dar acestea sunt de obicei
rezolvate rapid. Oricum, daca apare o situatie dificila care  nu poate fi
rezolvata cu usurinta, trebuie utilizat procesul urmator:
1. Problemele pot fi ridicate de catre orice membru al echipei. Acestea trebuie
transmise in scris managerului de proiect fie pe hirtie, fie prin email, etc. Nu
este necesar un formular tipizat.
2. Managerul de proiect determina daca problema poate fi rezolvata sau este
clasificata ca o situatie dificila.
3. Managerul de proiect pregateste un plan pentru rezolvarea situatiei si
determina optiuni daca pot exista mai multe cai de actiune. Trebuie
identificat si impactul asupra planului de lucru al proiectului.
4. Managerul de proiect trebuie sa prezinte analiza, impactul si alternativele
catre Sponsorul proiectului si alti participanti pentru discutare si rezolvare.
5. Daca rezolutia situatiei necesita o modificare a continutului, trebuie
invocata procedura de management al schimbarilor continutului pentru
proiecte mici, pe baza informatiilor colectate.
6. Odata ce rezolutia este convenita, actiunile corective potrivite sunt
adaugate in planul de lucru pentru a ne asigura ca situatia este rezolvata.
7. Situatia dificila, starea curenta si rezolutia trebuie documentate in Raportul
de Stare a Proiectului.
 Managementul Problemelor / Tehnici
• Analiza Cauza-Efect
– Aceasta tehnica pentru rezolvarea problemelor reprezinta o
modalitate de analiza a problemelor complexe care par a avea
mai multe cauze interdependente. Unul dintre aspectele cheie
ale acestei tehnici este folosirea diagramei cauza-efect. Datorita
felului in care arata diagrama, aceasta tehnica este de asemeni
numita si Diagrama Os de Peste (Fishbone Diagram). Un alt
nume al acestei tehnici este Diagrama Ishikawa. Acest nume
provine de la Prof. Kaoru Ishikawa, un japonez care a fost primul
utilizator al acestei diagrame, in 1943.
– Beneficiile acestei tehnici includ:
• Permite explorarea diferitelor categorii de cauze.
• Incurajeaza creativitatea prin intermediul procesului de brainstorming.
• Furnizeaza o imagine grafica a problemei si a potentialelor categorii de
cauze.
 Dezvoltarea diagramei Fishbone
• Deseneaza o linie orizontala directionata catre caseta cu problema. Aceasta sageata va servi
drept coloana vertebrala, pornind de la care cauze majore sau minore vor fi categorisite si
relationate.

• Identifica cauze potentiale si grupeaza-le in categorii principale. Exemple de categorii majore

includ oamenii, procesele, materiale, echipamente, mediu, etc. Categoriile principale sunt
identificate prin tehnica brainstorming, deci in acest punct nu te intereseaza daca
participantii nu sunt de acord asupra carei categorii contine cauza majora. Asigura-te ca
exista suficient spatiu intre ele pentru a putea adauga cauze individuale mai tirziu. Fiecare
dintre aceste categorii majore va fi explorata in detaliu.
• Continua brainstorming-ul asupra cauzelor prin analiza detaliata a explicatiilor pentru fiecare categorie
principala identificata. Scrie cauza detaliata pe o linie oblica conectata la categoria principala corespunzatoare.

• Uneori, cauza detaliata poate avea alte cauze, cu o granularitate crescuta. In acest caz, conecteaza liniile
suplimentare cu liniile de detaliu. In mod uzual, trei niveluri de detaliere sunt limita practica a acestei
diagrame.
• Atunci cind brainstorming-ul asupra categoriilor principale si a cauzelor detaliate s-a incheiat, incepe analiza
informatiilor. Evalueaza fiecare cauza majora si potentialele cauze detaliate asociate cu aceasta. Retine ca lista
initiala a fost realizata prin brainstorming, in care se include toate ideile aparute. Acum trebuie determinate
elementele care par a fi cauzele cele mai probabile (sau una dintre acestea). Incercuieste elementele cele mai
promitatoare in acest sens, pentru investigarea ulterioara.
• Daca nu exista consens asupra domeniilor principale de investigatie, foloseste un sistem oarecare de votare
pentru a ingusta gama catre alternativele cu cele mai multe sanse de succes.
• Pentru fiecare element incercuit, analizeaza impactul asupra problemei.
• Creaza un plan de actiuni pentru rezolvarea cauzei incercuite. Retine ca pot fi mai multe cauze potentiale care
interactioneaza in crearea problemei. Planul de actiune trebuie sa ia in considerare aceste interdependente. In
situatia in care cauzele detaliate sunt in continuare complexe, sau nu exista suficiente informatii, acestea pot fi
atribuite pentru analiza ulterioara uneia sau mai multor persoane.
 Analiza Cauzei Radacina

• Managerul unei fabrici inspecteaza o linie de asamblare si observa

la un moment dat o balta pe podea. Stiind ca apa reprezinta un risc
pentru siguranta, ii cere supraveghetorului sa cheme pe cineva
pentru a sterge apa.
• Managerul se simte mindru ca a rezolvat o problema legata de
siguranta fabricii.
• Supraveghetorul cauta cauzele intrebindu-se “de ce?” El descopera
ca balta provine de la o conducta supraincarcata. Se intreaba din
nou “de ce?” si descopera ca scurgerea este din cauza presiunii
prea mari a apei. Se intreaba inca o data “de ce?” si descopera ca
supapa de presiune a apei este defecta. Desi se mai intreaba inca o
data “de ce?”, nu poate gasi un raspuns. Asadar, supapa este
inlocuita si astfel se rezolva simptomul scurgerii apei in fabrica.
• Analiza cauzei radacina se face printr-o serie de intrebari de tipul
“de ce?”. Ca si in exemplul anterior, intreaba-te “de ce” exista
problema. Apoi descoperi una sau mai multe cauze. Pentru fiecare
din aceste cauze, intreaba-te din nou “de ce?”. Daca poti raspunde
din nou la intrebare, inseamna ca primul raspuns este probabil un
simptom. Continua cu intrebarea “de ce” pina cind nu mai poti gasi
un raspuns logic.

• Acest ultim nivel este cel mai probabil sa reprezinte cauza radacina
care a generat simptomele observabile. Prin analiza, poti descoperi
mai mult de o cauza radacina.

• Dupa ce ai identificat cauzele radacina, pregateste un plan de

actiuni pentru rezolvarea problemei. Simptomele ar trebui sa
dispara.
 Analiza Pareto
• Analiza Pareto poate fi folosita atunci cind intimpini
mai multe probleme cu legaturi intre ele sau cind o
problema are mai multe cauze.
• Cu ajutorul acestei tehnici se pot de asemeni colecta
metrici despre frecventa aparitiei problemei sau a
cauzei.
• Scopul analizei Pareto este observarea problemelor si
determinarea frecventei lor de aparitie.
• Aceasta furnizeaza informatiile necesare pentru
prioritizarea efortului, pentru a fi sigur ca timpul se
foloseste cu impact maxim
• Analiza Pareto se bazeaza pe regula clasica 80/20.
Acest lucru inseamna ca 20% din cazuri cauzeaza 80%
probleme.

• Sa presupunem ca ai o problema cu defectul unui

produs, bazata pe un numar de cauze. Prin observarea
si colectarea metricilor, rezulta ca sunt opt cauze. In
loc sa ataci la intimplare aceste cauze, analiza Pareto iti
poate arata ca 80% dintre probleme sunt create de
primele trei cauze.

• Unealta pentru aceasta tehnica este diagrama Pareto.

Este un grafic, sau o histograma care arata fiecare
problema si frecventa ei de aparitie. Se creaza astfel:
1. Se creaza un tabel in care se
listeaza toate problemele sau
cauzele observate.

2. Pentru fiecare problema,

identifica numarul de aparitii intr-
un interval fixat de timp.

3. Sorteaza problemele in ordine

descrescatoare, pe baza
numarului de aparitii.

• Adauga o coloana pentru totalul

cumulativ. (Frecvenţa cumulată
a fiecărei categorii reprezintă
frecvenţa acelei categorii
adăugată frecvenţelor tuturor
categoriilor superioare)
 Sarcini
• Rezolva Situatiile Dificile cit mai curind posibil

• Incearca sa rezolvi cauza radacina, nu doar

simptomele

• Alege raul cel mai mic

Managementul Problemelor / Livrabile
Managementul Problemelor / Activitati
suplimentare privind Planul de Lucru