Metodologia PRINCE 2

Workshop - Managementul proiectelor informatice
Bucureşti, 27 octombrie 2004
Metodologia PRINCE 2 (PRojects IN Controlled Environments)
Cătălin TISEAC2,
Diana PASAT IORDACHE3
Rezumat: Articolul prezintă metodologia Prince2 (structura, procesele, componentele, tehnicile,

documentele si livrabilele), din perspectiva unei companii care lucrează în mod curent cu aceasta
metodologie.
Cuvinte cheie: Prince2, componente metodologice, procese, tehnici, livrabile.
1. Introducere
• Este o metodologie scalabila si flexibila de management de proiect dezvoltata in Marea

Britanie si folosita initial in proiectele guvernamentale.
• Actualmente este acceptata ca standard general de management al proiectelor la nivel
European.
• Este orientata pe produs si include procese verificate de project management
• Un proiect trebuie sa aiba la baza o justificare economica (Business Case) iar controlul
implementarii trebuie sa fie facut relativ la scopul si parametrii economici stabiliti initial.
2. Structura metodologiei PRINCE
Metodologia PRINCE este structurata in trei parti:
• Procese: metodologia PRINCE ofera un set de procese care asigura un mediu controlat
pentru inceputul, derularea si inchiderea proiectelor si definesc ce trebuie sa se intample si
cand. Torodata este prezentata si succesiunea logica si dependentele intre procese;
• Componente: explica “filozofia” diferitelor aspecte ale proiectului, de ce este nevoie de ele
si cum pot fi acestea utilizate. Aceste componente sunt implementate cu ajutorul proceselor
specifice;
• Tehnici: metodologia PRINCE ofera cateva tehnici care sa vina in ajutorul Managerului de
proiect si a caror utilizare este optionala. Exceptie face tehnica specifica PRINCE –
„Planificarea bazata pe produs” si care este o parte importanta a metodologiei. Utilizarea
acestei tehnici creaza un beneficiu considerabil si de aceea ea trebuie inteleasa si aplicata
corespunzator.
In capitolele care urmeaza aceste trei structuri vor fi abordate in detaliu si se va prezenta
modul in care PM Solutions aplica aceasta metodologie in proiectele sale.
2
Professional Management Solutions SRL, catalin.tiseac@pm-solutions.ro
3
Professional Management Solutions SRL diana.pasat@pm-solutions.ro
3. Procesele metodologiei PRINCE 2

Pasii in managementul proiectelor sunt descrisi de cele opt procese prezentate mai jos.
Orice proiect care se deruleaza conform metodologiei PRINCE 2 trebuie sa adreseze aceste
procese. Pentru a utiliza cu succes aceasta metodologiee, modelul este adaptat specificului
fiecarui proiect. Fiecare proces de mai jos este subiectul evaluarii de catre managerul de proiect
a modului in care este acesta aplicat pentru proiectul respectiv.
Management-ul organizatiei sau al programului
Ma
Conducerea Proiectului Q
Project
START Initierea Management-ul
Proiectului Limitelor Etapei
Controlul
Etapei Incheierea
Proiectului
Management-ul
Realizarii Produselor
Planificare
4. Componentele metodologiei
In figura urmatoare sunt prezentate componentele metodologiei PRINCE 2 care sunt
pozitionate in jurul modelului proceselor:
Controlul Business
Schimbarii Case
Configuration
Organizare
Management
Calitatea in
mediul de Planuri
proiect
Risk Mijloace
Management de Control
5. Tehnicile metodologiei PRINCE 2
Tehnica specifica metodologiei PRINCE este Planificarea bazata pe produs (Product

Based Planning)
Tehnicile metofologiei PRINCE 2 specifica doar liniile indrumatoare generale si ofera
raspunsul la intrebarea „Cum se face?”. Aceste tehnici cuprind:
• Planificarea produselor
• Controlul calitatii
• Controlul schimbarilor
• Controlul documentatiei
6. Procese importante in livrarea proiectelor
In viziunea PM Solutions urmatoarele procese sunt critice in livrarea cu succes a oricarui

proiect:
6.1 Initerea proiectului
Documentul de initiere a proiectului (PID) se elaboreaza pentru fiecare proiect in parte

definind modalitatile prin care acesta va fi livrat.
6.2 Managementul Nivelului de Referinta (Baseline Management)
Baseline management este necesar pentru a asigura ca toate informatiile de start ale
proiectului sunt corecte, se cunosc, sunt in concordanta cu realitatea, sunt acceptate si intelese de
catre toti cei implicati in proiect (clienti, subcontractori ai PM-Solutions, alte parti implicate).
6.3 Definirea cerintelor proiectului
Cerintele proiectului trebuiesc foarte clar definite. Acest lucru se face intr-un acord formal
cu clientul, de obicei in Faza de Initiere a Proiectului. Definirea cerintelor proiectului considera
angajamentele contractule ca referinta si constituie la randul sau o referinta de verificare pana in
momentul in care se obtine acceptanta finala din partea clientului.
6.4 Desemnarea Comitetului de Conducere al priectului (Project Board)
Comitetul de Conducerea al Proiectului este alcatuit, de obicei, dintr-un reprezentant din

top managementul furnizorului, clientului si al utilizatorului si managerul de proiect al PM-
Solutions.. Acest comitet este organismul suprem in proiect care ofera madatul managerului de
proiect care raspunde direct in fata celor trei reprezentanti pentru succesul proiectului. Totodata
acest comitet are autoritatea de a lua decizile care sunt in afara mangatului managerului de proiect si
sa aprobe modificare ariei de acoperire a proiiectului (project scope).
6.5 Managementul Riscurilor

Pentru toate proiectele se elaboreaza un Plan al Riscurilor. Pentru producerea acestuia se

utilizeaza un model de referinta de plan al riscurilor, model recomandat de metodologia PRINCE2.
Dupa validarea planului, acesta este revizuit periodic de catre echipa de proiect pe parcursul
derularii proiectului, de obicei la sfarsitul fiecarei luni. Procesul de management al riscurilor este in
conformitate cu procedurile interne specifice ale PM Solutions definite si revizuite de catre
comunitatea managerilor de proiect din cadrul organizatiei .
6.6 Planurile proiectului
Planul de Proiect este parte integranta din Documentul de Initiere a Proiectului (PID) si
informeaza Comitetul de Conducere al Proiectului in legatura cu: durata proiectul, care vor fi
livrabilele si produsele proiectului, termene de livrare, care sunt resursele implicate in realizarea
proiectului, cum se va exercita controlul, cum vor fi respectate criteriile de calitate, care sunt
riscurile asociate proiectului.
Planul de Etapa este optional. Se elaboreaza in cazul in care proiectul este de dimensiuni
ceva mai mari si este necesara o impartire a proiectului pe etape.
Planul de Resurse este optional. Necesitatea realizarii acestui plan este dictata de marimea,
complexitatea si riscurile asociate proiectului. In cele mai multe cazuri resursele sunt prezentate
detaliat in cadrul pachetelor de lucru unde se specifica pentru fiecare din activitatile din cadrul
pachetului care sunt resursele necesare si gradul de alocare a fiecarei resurse in parte.
Planul de Exceptii se realizaeza in cazul in care este inregistrata o exceptie fata de planul
proiectului care poate genera depasirea duratei si costului aprobat. Acest plan descrie in detaliu cum
va fi tratata aceasta exceptie, impactul estimat asupra proiectului precum si necesarul de resurse
suplimentare (daca este cazul).
6.7 Managementul calitatii
Toate proiectele au asociat un Plan al Calitatii in care sunt descrise procesele si metodele
de lucru necesare asigurarii calitatii livrabilelor proiectului. Toate livrabilele sunt verificate daca
indeplinesc criteriile de calitate inainte de a fi predate clientului spre testare si acceptare. In functie
de complexitatea proiectului, Planul de Calitate este cuprins intr-o sectiune a PID-ului iar pentru
proiecte complexe se nominalizeaza un Responsabil cu Calitatea.
6.8 Controlul schimbarilor
Metodologia PRINCE II acorda o foarte mare importanta nevoii de schimbare in derularea

proiectelor. Schimbarile pot fi implementate intr-un proiect daca aceste sunt rezultatul unui proces
de control al schimbarilor. Toate cererile de schimbare sunt inregistrate intr-un registru al
schimbarilor in care sunt completate pe parcursul procesarii cererilor toate detaliile referitoare la
acea cerere de schimbare: justificare, impact, solutie, resurse etc. Procedurile care guverneaza acest
procesul sunt detaliate sau se face referire la ele in PID sau in Planul de Calitate.
6.9 Managementul Configuratiei
Planul pentru Managementul Configuratiei descrie structura initiala a proiectului si

modalitatile in care procesul de control al configuratiei este condus si controlat. Tehnicile si
metodele de implementare a Managementul Configuratiei trebuie sa fie identificate in functie de

specificatiile fiecarui proiect in parte.
6.10 Managementul documentelor si biblioteca proiectului
Biblioteca proiectului cuprinde toate documentele proiectului. Evidenta documentelor este

tinuta intr-un registru al documentelor. Starea fiecarui document este periodic revizuita pentru a
asigura si controla concordanta acestora cu situatia existenta.
6.11 Revizuirea design-ului
In proiectele in care este necesar design-ul unui sistem, un proces formal de revizuire a
design-ului trebuie derulat in conformitate cu standardul ISO9001. Rolul unui astfel de proces este
acela de a asigura verificarea formala a modului in care solutia propusa corespunde cerintelor
contractuale.
6.12 Urmarirea si auditul proiectului
Progresul fiecarui proiect este urmarit in permanenta la nivel de detaliu de catre managerul
de proiect pentru a asigura concordanta intre cerinte si ceea ce s-a realizat. In unele cazuri, in
etapele cheie, proiectele sunt audite de catre un organism estern care are rolul de a furniza un raport
obiectiv referitor la starea proiectului la acel moment si a modului in care s-a efectuat managementu
proiectului.
6.13 Arhivarea
Politica de arhivare sustinuta de responsabilitati clare este impetuos necesara pentru a

asigura ca informatiile proiectului sunt in siguranta. In cazul in care informatiile din proiect sunt
stocate intr-un sistem informatic (instrument software) atunci inregistrarile de informatii noi ale
proiectului sunt oprite iar partii software i se face o copie. Aceste copii sunt arhivate separat de
locul in care sistemul informatic se gaseste si sunt pastrate si dupa finalizarea proiectulu pentru o
perioada pentru a asigura posibilitatea consultarii lor in cazul in care acest lucru este necesar.
6.14 Conducerea echipei
Managerul de proiect are rolul de conducator al echipei de proiect. In aceasta pozitie el are
obligatia de a face cunoscut tuturor membrilor echipei obiectivele personale si de echipa. Tot
managerul de proiect este responsabil pentru definirea si comunicarea rolurilor pentru membrii
echipei precum si de stabilirea nivelurilor de autoritate in cadrul echipei.
6.15 Evaluarea proiectelor si raportarea
Fiecare Project Manager are responsabilitatea sa raporteze lunar stadiul proiectului pe care
il conduce urmarind urmatoarele criterii: starea proiectului in timp (la momentele de referinta),
situatia financiara a proiectului, resusele alocate in proiect, riscurile materializate si problemele
critice. Acest raport este rezultatul unei sedinte periodice de evaluare a progresului proiectului la
care participa conducerea echipei de proiect si este obtinut in urma consolidarii rapoartelor primite
de la liderii echipelor din proiect, in cazul proiectelor mai complexe.
6.16 Dependente
In toate proiectele exista dependente interne sau externe proiectului care conditioneaza
realizarea livrabilelor din proiect. Aceste dependente sunt inregistrate intr-un registru specific iar
pentru fiecare dependenta in parte este nominalizat un responsabil. Dependentele externe
proiectului pentru care controlul nu poate fi exercitat de catre managerul de proiect sunt incluse in
documentul de initiere al proiectului, fiind astfel comunicate formal catre comitetul de conducere al
proiectului care trebuie sa desemneze responsabili pentru aceste dependente. Registrul de
dependente este revizuit periodic impreuna cu persoanele si organizatiile implicate in proiect pentru
a putea urmari evolutia lor si pentru a stabili actiuni corective daca este cazul.
6.17 Managementul problemelor
Managerul de proiect are obligatia de a implementa o procedura care sa adreseze modul in

care se va face managementul problemelor din proiect. Toate problemele semnalate trebuiesc
inregistrate in registrul de probleme si analizate in vederea furnizarii cel putin a unei solutii. In
cazul in care solutia oferita este acceptata se stabilesc actiunile necesare implementarii solutiei si
responsabilii. Dupa finalizarea implementarii poblema poate fi inchisa numai de persoana care a
semnalat acea problema.
6.18 Acceptantele
Pentru toate proiectele se defineste un Plan de Acceptanta care descrie ce componente

trebuie sa primeasca acceptanta si modul cum aceasta va fi obtinuta. Acest document este agreat
formal cu clientul. Planul de acceptanta trebuie sa contina: strategia de acceptanta, lista livrabilelor
care trebuiesc supuse acceptantei, criterile de acceptanta pentru aceste livrabile si modul in care
aceste criterii sunt verificate, persoanele care sunt autorizate se ofere acceptanta.
6.19 Strategia pentru suport
In general perioada de suport (mentenanta) este de obicei o faza post-acceptanta in ciclul de

viata al proiectelor. Strategia pentru suport detaliaza nivelul de suport, cerintele concrete suport si
transferul de cunostinte pe care echipa de suport trebuie sa le ofere si este inclusa in contractul cu
clientul. Responsabilitatea pentru oferirea serviciilor de suport nu este a managerului de proiect, dar
acesta trebuie sa se asigure ca tranzitia de la proiect la perioada de operare se face fara a altera
obiectivele proiectului si nivelul de satisfactie al clientului.
6.20 Inchiderea proiectului
Toate proiectele se finalizeaza cu un Raport Final al Proiectului care trebuie sa cuprinda

minimal informatii despre: evolutia proiectului, rezultatul proiectului, in ce masura obiectivele au
fost atinse, calitatea estimarilor initiale, schimbarile efectuate, problemele importante cu care
proiectul s-a confruntat, prezentarea principalelor riscuri care s-au materializat, calitatea proiectului
precum si „lectiile invatate” de catre managerul de proiect pe parcursul derularii proiectului.
6.21 Conformitatea cu standardul ISO 9001
Pentru proiectele care au ca obiectiv dezvoltarea de produse software, procesele orientate pe

acest tip de produs trebuie sa fie in conformitate cu standardul de calitate ISO9001.
7. Documentul de initiere a proiectului (PID)

La demararea unui nou contract, planificarea proiectului se face la un nivel cat mai detaliat.
Scopul fazei de definire si initiere a proiectului este acela de a stabili planul proiectului la nivel de
detaliu acoperind toata aria de responsabilitati manageriale. Ceea ce rezulta in urma acestei faze
este Documentul de Initiere a Proiectului.
Project Manager-ul trebuie sa tina cont de angajamentele din Contract in definirea
proiectului precum si in urmatoarele etape pentru a putea prevedea ce trebuie produs/facut si, in
cazul unor extensii, care sunt pasii de urmat.
In cadrul Procesului de Initiere a unui proiect echipa manageriala:

• Accepta planurile, bugetul si termenele proiectului;
• Accepta riscurile asociate proiectului;
• Confirma rolul, nivelul de autoritate si responsabilitatea project manager-ului;
• Asigura faptul ca in proiect vor fi alocate resursele adecvate;
• Identifica modalitatile prin care va fi masurat aportul project manager-ului si
modalitatile de control a proiectului;
• Seteaza modalitatile de raportare si revizuire din cadrul proiectului;
• Isi recunoaste responsabilitatile;
• Autorizeaza demararea proiectului.
PID cuprinde urmatoarele documente:

• Documentul de definire a proiectului care contine: obiectivele proiectului, definirea
metodelor de abordare a proiectului, scopul proiectului, livrabilele proiectului,
excluziunile, constrangerile, interfetele si supozitiile.
• Structura de organizare a proiectului
• Bugetul proiectului
• Planul de comunicare
• Planul de calitate al proiectului
• Tolerantele proiectului (abaterile permise)
• Modalitati de control
• Justificare economica initiala (Business Case)
• Planul initial al proiectului
• Registrul initial al riscurilor
Documentul de Initiere a Proiectului raspunde la intrebarile: pentru cine, de ce, ce, care
este succesiunea, cu ce riscuri, cat costa etc, intrebari ce definesc urmatoarele caracteristici ale
proiectului:
• Scopul proiectului si modelul ciclului de viata care va fi folosit;
• Descrierea proceselor din cadrul proiectului si a dependentelor dintre acestea;

• Livrabilele proiectului la nivel de individ: produsele si serviciile cerute;
• Structura organizatorica, descrierea rolurilor si a responsabilitatilor;
• Identificarea riscurilor si a modalitatilor de diminuare a acestora;
• Elaborarea planului de resurse pentru fiecare etapa din cadrul proiectului;
• Criteriile de acceptanta si mijloacele de verificare folosite pentru fiecare livrabil in
parte;
• Constrangeri si supozitii din cadrul proiectului;
• Graficul de realizare a proiectului, costurile si beneficiile asteptate ;
• Configuratia proceselor de management care vor fi utilizate.
In cazul proiectelor complexe, Planul de Management de Proiect este mult mai amplu si
cuprinde un numar mai mare de documente pentru a putea descrie la nivel de detaliu toate procesele
si procedurile folosite in proiect.
Fiecare proiect urmeaza procese si proceduri standard, acestea fiind sustinute si de

experianta acumulata in domeniu de catre consultantii PM Solutions.
8. Livrabile si dependente
8.1 Responsabilii cu definirea livrabilelor si dependentelor dintre acestea
In cazul fiecarui proiect in parte, livrabilele (produse si servicii) sunt schimbate intre partile
implicate in proiect. Managerul de proiect este responsabil sa identifice, sa definesca si sa agreeze
impreuna cu reprezentantii clientului, ai furnizorului si cei ai subcontractorilor livrabilele
proiectului. Pentru aceasta, este foarte important sa se cunoasca:
• Care sunt livrabilele proiectului

• Cine si ce anume va livra
• Cine va face receptia livrarii
Aceste informatii trebuie sa se defineasca in faza de pre-contract a proiectului, tinandu-se o

evidenta clara a acestora pe toata perioada de implementare a proiectului. De asemenea, este foarte
important sa se cunoasca inca de la inceput care sunt criteriile de acceptanta a livrabilelor.
8.2 Care sunt livrabilele unui proiect?
Project Manager-ul trebuie sa identifice tipurile de livrabile si dependentele dintre acestea,

sa defineasca ce va fi livrat si cum. Livrabilele cele mai frecvente intalnite in cadrul proiectelor PM
Solutions sunt:
• Hardware
• Software
• Documentatie (ex: caiete de sarcini, specificatii, rapoarte)

• Servicii (ex: consultanta, training, servicii de suport, mentenanta)
• Constructii (implementare spatiu de birouri)
• Resurse (ex: recrutare, training)
8.3 Cui livram?
Managerul de proiect trebuie sa identifice care sunt persoanele responsabile cu procurarea

si livrarea produselor sau serviciilor catre client, catre PM Solutions si catre alte parti implicate in
proiect. In cazul situatilor in are livrabilele provin direct de la furnizori si subcontractori ai PM
Solutions acestea sunt considerate livrabilele companiei PM Solutions.
O buna intelegere a cerintelor livrabilelor necesare in proiect este de importanta majora
pentru a putea controla si finaliza cu rezultatele dorite proiectul.
8.4 Dependente
Dependentele se evidentiaza atunci cand PM Solutions solicita livrarea unor produse sau
servicii din partea altor parti implicate in proiect. Spre exemplu, urmatoarele doua situatii creaza
dependente:
• Livrabilele din partea clientului catre PM Solutions
• Livrabilele din partea subcontractorilor catre PM Solutions
8.5 Structura detaliata orientata pe activitati sau produse (Work Breakdown Structure
or Product Breakdown Structure)
Structura detaliata orientata pe activitati sau produse este metoda prin care este descris
aria de acoperire a proiectului. Structura detaliata orientata pe activitati (WBS) descrie sarcinile
care trebuie indeplinite pentru a putea livra solutia proiectului, in timp ce structura detaliata
orientata pe produse (PBS) defineste produsele, componentele sau livrabilele in sine. Amandoua
creaza o structura ierarhica identificand unitatile de livrat, definind partile hardware, software si
serviciile la cel mai mic nivel de detaliere.
Crearea lor trebuie sa fie facuta in faza de pre-contract iar pe toata perioada de
implementare a proiectului trebuie sa se tina o evidenta clara a acestora. Structura detaliata
orientata pe activitati sau produse furnizeaza informatiile necesare unei prime analize a
proiectului fiind un element important pentru orice faza de inceput deoarece prin intermediul lor se
poate estima, planifica, se pot aloca sarcinile, se pot identifica riscurile, se poate masura progresul,
se poate evalua bugetul proiectului, costurile si preturile aferente.
Este foarte important de mentionat faptul ca, WBS –ul reprezinta o parte importanta in
definirea proiectului, dar acesta nu substituie alte documente elaborate in cadrul unui proiect (ex:
planuri, specificatii sau contracte).
Scopul elaborarii structurii detaliate orientata pe activitati:

• Sa defineasca produsele si sa identifice sarcinile si pachetele de lucru necesare
desfasurarii proiectului. Piramida activitatilor dependente va da o imagine de baza
asupra organizarii proiectului si implicit asupra costurilor aferente;
• Nivelul de referinta (baseline) al proiectului este un plan initial de dimensiuni mici dar
de o importanta majora unde sunt definite sarcinile necesare realizarii proiectului
• Sa defineasca sarcinile, sa identifice riscurile
• Sa se poata aloca responsabilitatile aferente sarcinilor identificate
Structura detaliata orientata pe activitati sau produse sunt structuri ierarhice ce ajuta la
descrierea la nivel de detaliu a pachetelelor de lucru si bugetului acestora.
Din punct de vedere al complexitatii unei astfel de structuri ierarhice, numarul maxim de
niveluri utilizate la elaborarea WBS-ului este 4 (maxim 6 in cazul proiectelor mai complexe).
Fiecare pachet din cadrul WBS-ului contine:
• Un titlu si un identificator
• O descriere simpla a sarcinilor de indeplinit
• Descrierea resurselor
• Identificarea livrabilelor ce vor fi produse
• Identificarea dependentelor interne si externe
• Criterii de acceptanta a livrabilelor
• Responsabilul (managerul) pentru pachetul de lucru
• Riscurile asociate acelui pachet
• Graficul de realizare si bugetul alocat
9. Managementul nivelului de referinta (Baseline Management)
9.1 Descriere
Mmanagementul nivelului de referinta descrie tehnicile folosite in stabilirea

monitorizarii si controlului tuturor activitatilor care constituie proiectul. Conceptul de baza este
acela de a stabili un nivel de referinta fata de care se poate masura progresul, detecta variatiile si
deviatiile si identifica munca suplimentara si modificarile necesare. Sarcina principala este aceea de
a pastra proiectul in directia corespunzatoare.
Este imperativ ca nivelul de referinta sa reflecte cerintele contractuale si sa nu urmareasca

sa se livreze mai mult, sau mai putin, fata de angajamentele contractuale. Managerul de proiect
trebuie sa urmareasca ca modul in care se livreaza sa fie corespunzator celor stipulate in contract.
Daca este necesara o schimbare atunci aceasta trebuie adresata printr-un proces formal de control al
schimbarii.
Scopul managementului nivelului de referinta este:

• Sa asigure ca toate intrarile care influenteaza dezvoltarea proiectului sunt corecte,
cunoscute, la zi, agreate si intelese;
• Controlul simplu prin simplificarea tuturor proceselor de control necesare si stabilirea

unui set de rutine structurate care necesita cat mai putin consultarea documentatiei;
• Structura clara prin furnizarea unui mediu cunoscut pentru toti participantii la proiect in
care acestia isi pot indeplini sarcinile respective;
• Obtinerea angajamentului din partea tuturor membrilor proiectului referitor la sarcinile
si perioada de timp in care acestea trebuie indeplinite;
• Standarde inalte prin crearea unui climat care sa incurajeze oamenii sa performeze la
cele mai inalte standarde profesionale;
Orice modificare in cerinte trebuie sa fie reflectata in modificari corespunzatoare acceptate

ale nivelului de referinta si vice versa.
Nivelul de referinta al proiectului reprezinta definitiile curente si aprobate ale:

• Ariei de cuprindere a proiectului – asa cum este prezentat in contract;
• Planul de implementare si bugetul aferent;
• Structura si procesele de management de proiect;
• Interfetele pentru organizatiile externe ale echipei de proiect;
Este utilizat de care managerii de proiect ai PM Solutions pentru a controla proiectul si

pentru a permite monitorizarea acestuia pe intreg parcursul ciclului sau de viata.
9.2 Crearea si controlul
Colectarea de informatii pentru nivelul de referinta incepe odata cu faza de ofertare si pre-
contract si rezulta in crearea de catre Managerul de Proiect a versiunii initiale a nivelului de
referinta (Initial Baseline) ca parte a activitatilor de incepere a proiectului. Dupa aceea managerul
de proiect este responsabil pentru producerea versiunilor revizuite ale nivelului de referinta care sa
prezinte progresul si schimbarile produse pe durata proiectului.
In documentul de definire a nivelului de referinta a proiectului trebuie incercat sa se evite

repetarea informatiilor continute in documentele care formeaza nivelul de refinta. Ideal este ca acest
document sa cuprinda o lista a documentelor existente (cu referinte si versiuni) impreuna cu o
explicatie minimala despre aria de cuprindere si aplicabilitatea fiecarui document. In plus,
documentul de definire a nivelului de referinta trebuie sa includa sau sa faca referire la procedurile
de control a schimbarii si la modul in care aceste schimbari sunt autorizate. Aceste proceduri se
aplica inclusiv la schimbarile din documentul de definire a nivelului de referinta. Trebuie acordata
atentie revizuirilor regulate al nivelui de referinta a proiectului si acelor elemente ale nivelui de
referinta care trebuie partajate cu clientul.
9.3 Continutul nivelului de referinta (Baseline)
Nivelul de referinta al proiectului trebuie sa adreseze urmatoarele arii, dintre care multe
sunt tratate mai in detaliu in sectiunile urmatoare ale acestui document:
Aria de cuprindere a proiectului (Project Scope)
• Valorile si livrabilele continute in documentul de aprobare a activitatii economice

(Business Approval)
• Prevederile contractului
• Cerinte si specificatii
• Livrabilele si criteriile de acceptanta
• Alte documente (ex. cele propuse de PM Solutions)
Planurile de proiect
• Structura detaliata orinetata pe activitati - WBS (definitie si buget)
• Activitatile si planul de resurse
• Momentele de referinta principale (milestones)
• Presupunerile si dependentele
• Planul de riscuri, inclusiv modul prin care se va face managementul riscurilor
Aspectele financiare
• Declaratia financiara la momentul aprobarii contractului si cea curenta
• Graficul pentru momentele de recunoastere a veniturilor
• Graficul pentru termenele de plata
• Fluxul de numerar
Organizare
• Echipa de proiect
• Echipa clientului si intefetele cu echipa de proiect
• Echipa subcontractorilor si interfetele cu echipa de proiect
• Caile de escaladare a problemelor (client, PM Solutions, subcontractori)
• Modul de delegare a autoritatii de decizie
• Planul de cheltuieli
• Modul de declansare a planurilor alternative
• Biroul de control a schimbarilor
Procese
• Sedintele de evaluare si rapoartele de progres catre client
• Managementul schimbarilor si raportarii
• Procesele interne principale ale proiectului
10. Controlul schimbarii
10.1 Necesitatea schimbarilor
Chiar daca nivelul de referinta (baseline) furnizeaza o definitie clara proiectului, mediul de
afaceri al clientului este supus la schimbari continue si, pentru a maximiza beneficiile clientului,
proiectul trebuie sa tina pasul cu eventualele nevoi de schimbare. De aceea schimbarea este
inevitabila (si dorita), si reprezinta un proces care trebuie controlat activ daca se doreste ca proiectul
sa ramana sub control. Pentru a extinde valoarea de business a PM Solutions, un management real
al schimbarii trebuie sa permita maximizarea valorii solutiei livrate clientului in timp ce proiectul
ramane tot timpul sub control.
Este esential ca orice schimbare a nivelului de referinta (cerinte functionale, livrabile, grafic
de implementare, performanta) sa fie controlata intr-o maniera formala. In particular este
responsabilitatea Manager-ului de Proiect sa se asigure ca o procedura formala de control al
schimbarilor este implementata din momentul de inceput al proiectului.
O schimbare este intotdeauna mai dificila de implementat decat modelul original si, daca nu
este corespunzator controlata, poate reprezenta o amenintare serioasa pentru proiect. Manager-ul de
proiect trebuie sa puna permanent in balanta necesitatea de a creste castigurile finaciare si implicit
profitul cu necesitatea de a livra o solutie in graficul de timp solicitat de catre client.
10.2 Contextul producerii schimbarilor
Contextul pentru managementul schimbarii trebuie agreat si definit in mod formal in

contractul cu clientul. Intr-o formulare simpla, trebuie sa fie prezentata intelegerea despre ceea de
trebuie facut si cand trebuie facut, precum si mecanismmul prin care aceste intelegeri pot fi
modificate si identificarea persoanelor care pot autoriza implementarea acestor schimbari. Cererile
de schimbare implica un efort suplimentar necesar investigatiilor, si deci implicit si costuri, si de
aceea valoarea acestor costuri cu investigatiile, prioritizarea si planificarea implementarii
schimbarilor trebuie stipulate in contract. Unde nu este posibil ca aceste aspecte sa fie acoperite in
contract, trebuie agreata o solutie clara cu clientul inainte de a angaja cheltuieli semnificative sau de
a modifica graficul de implementare.
10.3 Procesul de control al schimbarilor
Procesarea efectiva a schimbarilor necesita o procedura care sa acopere managementul

cererilor de schimbare, producerea propunerilor de schimbare si implementarea schimbarilor
aprobate:
• Inregistrarea cererilor de schimbare primite de la client;
• Crearea unui plan sau modificarea unui plan pentru a obtine schimbarea;
• Evaluarea costurilor si a impactului in cazul implementarii schimbarii;
• Pregatirea si aprobarea propunerii de schimbare;
• Predarea propunerii de schimbare catre client;
• Agreerea de catre client a costurilor, graficului, performantei si impactului schimbarii;
• Inregistrarea acceptarii schimbarii;
• Comunicarea schimbarii tuturor partilor implicate;
• Revizuirea nivelului de referinta a proiectului pentru a reflecta schimbarea;
• Implementarea schimbarii;
Este recomandat sa fie stabilit cu clientul un consiliu de control al schimbarii (Change

Control Board) care sa opereze intr-un mod formal. In plus, pentru schimbarile necesare in
interiorul proiectului se poate folosi un consiliu intern de control al schimarilor (ex. pentru
schimbarile care nu afecteaza clientul).
11. Specificatia cerintelor functionale
Cerintele functionale sunt continute intr-un document formal si sunt rezultatul unei prime
investigatii complete a cerintelor clientului. Acest document reprezinta un livrabil (produs) care este
adresat top managementului dar si o legatura cu fazele de dezvoltare ulterioare. Obiectivul acestui
document este acela de a adresa sistematic problemele, solutiile si recomandarile unde este cazul,
reprezentand totodata si o justificare pentru costul proiectului (ex. ce rezolva sistemul si de ce este
necesar).
12. Planificarea si alocarea resurselor
12.1 Definirea responsabilitatilor
Planul de livrare a proiectului prezinta succesiunea activitatilor care sunt necesare in

vederea finalizarii proiectului precum si modul in care aceste activitati interactioneaza intre ele.
Este folosit de catre Manager-ul de Proiect pentru initierea activitatilor si la planificarea necesarului
de resurse. Reprezinta un model fata de care progresul realizat este masurat iar cel viitor este
prevazut si este foarte strans legat de modul in care lucrarea este definita.
Managerul de Proiect este responsabil de crearea planului de proiect si al planului de

resurse asociat la inceputul proiectului si de rafinare si modificare a acestora pe parcursul ciclului
de viata a proiectului.
12.2 Realizarea planului de proiect
Crearea unui plan de proiect bun necesita o intelegere clara a proiectului in ansamblul sau
dar si o conceptie clara asupra modului in care acesta va fi derulat. Cu siguranta acest plan nu este
doar rezultatul programarii pachetelor de lucru din WBS si corelarea acestora ci trebuie luate in
considerare organizatia, constrangerile relevante si abordarea implementarii. Pentru proiectele mari
este necesar sa existe o ierarhie corespunzatoare a planurilor, inclusiv un plan general (top-level
plan).
Toate planurile de activitati ale proiectului trebuie sa fie bine structurate si sa includa:
• Etapele si fazele principale care sa reflecte modelul ales pentru ciclul de viata al
proiectului;
• Activitatile necesare producerii livrabilelor in conformitate cu structura detaliata
orientata pe activitati (WBS);
• Punctele de decizie la sfarsitul fiecarei etape;
• Jaloanele (punctele) de masurare a progesului;
• Jaloanele (momentele de timp) pentru livrabile;
• Termenele de plata;
• Identificarea dependentelor principale (interne si externe);
Sarcina planificarii trebuie indeplinita prin implicarea echipei de proiect pentru a obtine
angajamentul fata de plan atat de la echipa cat si de la fiecare individ in parte. Managerul de proiect
al PM-Solutions se foloseste de diferite instrumente software in vederea realizarii planului si a
modului in care acesta este reprezentat grafic. Aceste instrumente corespund standardului de firma
dar, in unele situatii, si cerintelor specifice ale clientului.
12.3 Realizarea planului de resurse
Analiza si consolidarea tipului si a numarului de resurse (oameni si materiale) necesar in

vederea elaborarii planului de activitati se materializeaza intr-un plan de resurse. De multe ori sunt
necesare mai multe iteratii in vederea obtinerii unui plan de resurse rezonabil si realist iar in unele
cazuri este necesara folosirea unui instrument software in sprijinul planificarii. Este foarte rar sa
poti indeplini cerintele unui plan real de resurse doar prin simpla alocarea a unor resurse ipotetice si
prin adaugarea costurilor aferente la bugetul pachetului de lucru deoarece in realitate programarea
resurselor si a perioadelor de lucru trebuie sa tina seama de gradul de disponibilitate a acestora in
organizatie. Planul de resurse furnizeaza o intrare esentiala pentru elaborarea bugetului proiectului.
12.4 Alocarea resurselor
In vederea planificarii cu succes a livrarii proiectului, Managerul de Proiect trebuie sa

identifice cerintele pentru resursele umane din proiect. Aceste cerinte sunt prezentate in documentul
Organizarea proiectului care include:
• Specificatia pentru pozitie - identifica rolul persoanei care va ocupa aceasta pozitie,
responsabilitatile si nivelul de autoritate delegat precum si cerintele speciale legate de
pozitia respectiva (ex. program de lucru, necesitatea deplasarilor etc);
• Specificatia pentru persoana – identifica persoana ideala care sa corespunda acelui rol
si descrie nivelul de cunostinte cerut, abilitatile, atitudinea si experienta necesara;
Cu cat Managerul de Proiect identifica mai devreme necesitatea unei anumite resurse si trimite
specificatia pozitiei / rolului catre managerul acelei resurse cu atat creste probabilitatea de a
identifica si aloca o persoana care sa corespunda cat mai mult pozitiei descrise.
Cu toate acestea, este foarte probabil sa fie ales un compromis intre cerintele legate de rolul in
proiect si persoanele care sunt disponibile la acel moment.
Persoanele alocate pentru proiect trebuie intervievate de catre Managerul de Proiect sau de catre o
persoana delegata de acesta.
13. Estimarea
Estimarea este o activitate importanta in determinarea viabilitatii comerciale a unui proiect

si un contribuant esential la stabilirea pretului care trebuie sa genereze profitul dorit pentru
organizatie dar si care sa-i permita acesteia sa ramana competitiva pe piata. Scopul unei estimari
este acela de a ajunge la un cost care sa fie cat de aproape posibil de cel real daca proiectul este
finalizat. Acest lucru daca chiar se intampla, se intampla foarte rar.
Estimarea este strans legata de resursele necesare pentru indeplinirea activitatii planificate,
ca de exemplu oameni, materiale sau timp. Trebuie utilizate unitati de masura relevante pentru
fiecare tip de resursa in parte, ca de exemplu zile-om sau ore pentru efort, numar de saptamani
pentru durata estimata a activitatilor, cantitati pentru materiale, unitati de calcul sau stocare in cazul
computerelor. Estimarea, cu toate ca este rezultatul unei judecati, ramane totusi o opinie despre
ceva. Procesul de estimare face uz nu numai de experienta si cunostinte dar si de un set de reguli
specifice. Aceste reguli se aplica pentru datele disponibile estimatorului.
O estimare este valabila intre anumite limite de probabilitate si este rezultatul unor tehnici
si metode de estimare.
Intotdeauna exista o asociere intre estimare si cost. Managerul de proiect nu poate evalua
costul unui proiect fara o estimare a componentelor sale. Estimarea proiectelor de dezvoltare a unei
aplicatii sau integrarii de sisteme implica estimarea atat a anvergurii cat si a costurilor generate de
efortul cheltuit pentru dezvoltarea solutiei.
O „buna estimare” este aceea in care:

• Exista un nivel acceptabil de incredere ca estimarea nu va fi depasita;
• Nivelul de referinta pentru cerinte este documentat si agreat de parti;
• Nivelul de referinta pentru solutie este documentat si agreat;
• Produsele proiectului si munca necesara livrarii lor este identificata si definta;
• Estimarea acopera tot ceea ce este necesar in acoperirea cerintelor;
• Estimarea a fost facuta de catre „experti”;
• Bazele estimarii sunt documentate si sunt catalogate drept „rezonabile”;
• Factorii care determina costurile sunt identificati (acele elemente putine care au o
pondere insemnata in cost); si cel putin pentru aceste elemente exista garantia unor
oferte ferme;
• Estimarile pentru resurse, cost si timp sunt garantate contractual de catre furnizori;
• Durata estimata este rezultatul unui proces formal de planificare;
• Calitatea estimarilor si experienta estimatorilor a fost calificata si estimarea este „cea
mai buna evaluare care putea fi facuta in acea circumstanta”;
• O evaluare a riscurilor a fost facuta si planurile au fost modificate corespunzator tinand
cont de aceste riscuri;
• A fost identificata o rezerva de timp si cost necesara sa acopere riscurile;
• Estimarile au fost validate dupa o dubla verificare;
• Estimarile sunt structurate astfel incat sa poata fi revizuite cu date reale pe perioada
executiei. Acest lucru permite ca estimarea duratei si costului final al prooiectului sa
poata fi revizuita si rafinata pe masura ce mai multe informatii devin disponibile.
Totodata permite crearea unor metrice care sa ajute la estimarea unor proiecte viitoare;
O metoda de estimare de succes este aceea care:

• Metoda are in mod constant rezultate bune ale estimarilor furnizand rezultate pozitive
repetabile;
• Mtoda foloseste procese si instrumente care sunt documentate in totalitate;
• Tehnicile sunt relativ usor de folosit permitand realizarea unor estimari bune cu un efort
proportional si intr-un timp resonabil;
• Oricine este interesat in realizarea, validarea si aprobarea estimarilor poate intelege
regulile care guverneaza acest proces. Managementul este mult mai increzator cand
procedurile de estimare sunt usor de inteles;
• Exita cursuri si materiale suport pentru metodele si tehnicile de estimare;
• Procesul de estimare are asociat un nivel de recunoastere si de accea echipa de proiect
si managementul sau au incredere in informatiile rezultate. Acest lucru ajunta la
obtinerea consensului si a angajarii pentru toti aceia care sunt interesati de estimare;
• Managementul care este responsabil cu acceptarea estimarilor aproba metoda;
• Metoda sau tehnica permite rafinarea estimarilor pe parcursul ciclului de viata a

produsului. O acuratete mai mare poate fi obtinuta prin monitorizarea si re-estimarea
proiectului de fiecare data atunci cand mai multe informatii sunt disponibile;
• Furnizeaza fundamentul pentru comparatii viitoare si masurarea variatilor;
Reguli ale estimarii:
1 Estimarea nu reprezinta doar o re-utilizare a informatiilor istorice sau o preluare automata a

informatiilor din terte surse.
1. Estimarea este diferita de o negociere.
2. Estimarea nu este subiect de disputa.
3. O estimare nu reprezinta doar o impartire a unei durate fixe in parti componente.
4. Orice intarziere produsa intr-o faza implica o intarziere proportionala in toate fazele
urmatoare.
5. Daca doresti sa realizezi o estimare semnificativa pentru cineva, nu-i spune acestuia direct
„rezultatul”.
6. O estimare utila a proiectului are un rezultat pe cat de optimist pe atat de pesimist .
7. Raportul dintre o estimare optimista si o utila estimare a proiectului este cvasi-constanta
pentru orice persoana.
8. Estimarea se face de catre o echipa si trebuie solicitata parerea oricui intelege sau cunoaste
aria sau munca respectiva.
Trebuie documentate toate ipotezele pentru a se putea obtine invataminte data viitoare prin
revederea lor .
14. Managementul riscului
14.1 Cerinte
Proiectele intotdeauna au si parti incerte (riscuri) deoarece nimeni nu poate prevedea cu

exactitate ce se poate intampla in viitor. Riscul poate fi identificat, controlat si diminuat dar nu
poate fi intotdeauna inlaturat.
Pentru a putea controla riscurile este necesar ca acestea sa fie identificate mai intai. In etapa
urmatoare se trece la partea de exercitare a controlului si de prevenire a riscurilor. Acolo unde
exista probabilitatea ca riscurile sa nu poata fi prevenite se iau masuri de diminuare a impactului si
de contingenta stabilind care sunt limitele aferente legate de timp, cost si resurse suplimentare.
14.2 Planificarea riscului
Este responsabilitatea Project Manager-ului sa identifice, planifice si controleze potentialele

riscuri printr-un proces de management al riscurilor. Acest proces se face inca din faza de
ofertare si pre-contractare si pana in faza de finalizare a proiectului pe toata perioada de derulare a
acestuia.
Riscurile sunt eliminate sau reduse pe cat este posibil inainte de a agrea orice contract.
Project Manager-ul intocmeste planuri care sa raspunda riscurilor ramase cu actiuni de contracarare
si contingenta pentru a inlatura esecul proiectului.
Project Manager-ul trebuie sa se asigure ca:

• Riscurile sunt identificate si clasificate (este definita sursa si natura riscurilor)
• Este facuta evaluarea impactului pentru fiecare risc in parte
• Riscurile sunt prioritizate in functie de gradul de importanta
• Unde se poate, riscurile sunt transferate detinatoriilor sau partajate cu acestia ( cei
detin controlul riscurilor)
• Modalitatile de prevenire sunt identificate si documentate (planificarea actiunilor ce
vor fi luate pentru a preveni sau inlatura riscurile)
• In cazul acelor riscuri care nu pot fi prevenite, diminuate, inlaturate se elaboreaza
planuri de rezerva (contingenta) pentru a diminua impactul; se stabileste care este
declansatorul planului, actiunile si responsabilii si bugetul alocat
• Sunt nominalizati responsabili pentru fiecare risc din cadrul echipei de proiect
• Riscurile sunt inregistrate in Registrul de Riscuri
Pentru o buna identificare si evaluare a tuturor riscurilor asociate unui proiect, in afara
procedeelor de planificare si estimare a riscurilor, PM Solutions foloseste frecvent tehnica
brainstorming implicand toti membrii echipei de proiect sau ai comunitatii de management de
proiect din cadrul organizatiei.
14.3 Alocarea resurselor aferente riscurilor
Dupa ce riscurile potentiale au fost inregistrate in Registrul de Riscuri, planurile de

prevenire si control sunt introduse in planul de proiect fiind alocate costurile si resursele necesare
implementarii lor.
Project Manager-ul trebuie sa se asigure ca implicatiile financiare (bugetul de contingenta)

sunt incluse in bugetul proiectului. Planul de contingenta se refera la riscurile ramase dupa ce s-au
luat masurile de prevenire si inlaturare a riscurilor.
In procesul de negociere / agreare a planurilor de contingenta trebuie sa se tina cont de

faptul ca exista posibilitatea ca proiectul sa mearga intr-o directie pozitiva dar si negativa. Balanta
dintre cele doua directii de evolutie ofera posibilitatea luarii unei decizii potrivite, tinand cont de
factorul de masurare a riscului dat de relatia impact x probabilitate.
Utilizarea unor programe de modelare a incertitudinilor din cadrul unui proiect este foarte
folositoare pentru a putea elabora un plan de contingenta cat mai apropiat nivelului de risc existent
in cadrul proiectului. Metoda de modelare folosita de PM Solutions este Monte Carlo.
14.4 Actiuni de prevenire a riscurilor
Determinarea riscurilor nu este suficienta. Esential in managementul riscurilor este luarea

actiunilor eficiente de reducere a riscurilor si protejare a proiectului.
Pe perioada de desfasurare a proiectui, Managerul de proiect este responsabil sa controleze

planul de riscuri monitorizand rezultatul actiunilor luate de catre echipa. Acest proces presupune:
• Mentinerea Registrului de riscuri la zi ;

• Examinarea frecventa a riscurilor identificate pana cand acestea au fost indepartate;
• Monitorizarea progresului pe perioada de prevenire si inlaturare a riscului;
• Monitorizarea actiunilor de contingenta si a momentului de declansare ;
• Revizuirea frecventa si actualizarea planurilor de management al riscului;
• Identificarea noilor riscuri aparute;
• Actualizarea elementelor de contingenta din evidenta financiara si a planului de proiect
pentru a reflecta situatia curenta;
• Raportarea planurilor de risc, a actiunilor luate precum si monitorzarea progresului.
15. Managementul Configuratiei
Indiferent care este ciclul de viata al unui proiect, pe toata durata acestuia se produc
multiple modificari si versiuni ale iesirilor. Acestea determina existenta unui proces de
management al configuratiei livrabilelor care ofera posibilitatea echipei de proiect sa urmareasca
starea si locatia livrabilelor pe intregul lor ciclu de viata.
Planificarea managementului de configuratie este adesea omisa in stadiul de definire a

produsului din cadrul unui proiect, dar daca nu se planifica un control in cadrul unor arii ca
securitatea, integritatea si, poate cel mai important, stadiul de intretinere, atunci controlul
proiectului este practic imposibil.
Planificarea managementului configuratiei este la fel de importanta ca si orice alta activitate
de planificare din cadrul proiectului proiectului.
15.1 Scop
Componente hardware
Pentru fiecare echipament hardware, echipa de proiect tine evidenta urmatoarelor

informatii:
• O definitie a echipamentului hardware: descriere (inclusiv identificatorul unic),
numarul modelului, seria acestuia si configuratia sa;
• Locatia unde sa gaseste sau se afla instalat;
• Starea si evidenta modificarilor si a defectiunilor;
Componente software
Gradul de detaliere al informatiei inregistrate va depinde dupa cum software-ul

este dezvoltat sau achizitionat ca produs standard, dar detalierea trebuie sa ajunga cel putin pana la
elementele constituente.
Pentru cel mai mic nivel al elementelor, echipa de proiect trebuie sa detina
urmatoarele informatii referitoare la compomentele software:
• Versiune
• Descriere
• Istorie modificari
Componentele sunt agregate intr-un „tot unitar” care este definit dupa:
• Versiune
• Descriere (inclusiv identificatorul unic)
• O lista a componentelor si versiunea acestora
Documentatia
Documentatia include specificatii, contracte, manuale, scrisori, notite si orice alte informatii
care sunt inregistrate pe hartie sau alt suport. In general exista doua categorii de documentatii:
documente primite in cadrul proiectului si documente produse in cadrul proiectului.
Proiectul trebuie sa detina un registru al problemelor si al documentelor primite si trebuie sa

se stabileasca o metoda sistematica de inregistrare si depozitare a acestora. Este foarte important ca
aceste informatii sa fie copiate si pe suport optic sau magnetic.
Instrumentele
Project Manager-ul trebuie sa se asigure ca sunt selectate cele mai potrivite mijloace si /sau
proceduri care sa ajute urmarirea configurarii obiectelor proiectului. In plus, proiectul trebuie sa
separe o schema si o metoda de alta, prin alocarea unui numar de referinta unic.
Mijloacele folosite depind de cantitatea obiectelor urmarite si de rata de schimb a

informatiilor urmarite. Editoarele de text, aplicatiile tabelare si bazele de date pot fi toate unelte
potrivite, dar este intotdeauna de dorit sa selectam instrumentele care acopera intregul ciclu de
viata a proiectului, sau cel putin tot ciclul de viata pentru categorii de articole de configurare, pentru
evitarea introducerii duble a datelor.
16. Managementul calitatii
Calitatea este”totalitatea trasaturilor si caracteristicilor unui produs sau serviciu, care se

bazeaza pe abilitatea sa de a satisface o nevoie”. In consecinta calitatea imbratisaza conceptele de
valoare si conformitate cu cerintele. Pentru asigurarea calitatii la nivel de proiect este nevoie ca
aceste concepte sa fie integrate in metoda de lucru a proiectului. In timp ce Project Managerul
trebuie sa preia conducerea calitatii, sprijinit la nevoie de specialisti, responsabilitatea pentru
calitate apartine tuturor.
16.1 Controlul calitatii
In cadrul managementului de proiect controlul calitatii este responsabilitatea Project

Manager-ului si implica asigurarea faptului ca tot ceea ce se produce este conform cu cerintele,
adica specificatii si metode de productie.
Toti membrii echipei de proiect sunt raspunzatori pentru respectarea calitatii in aria lor de
responsabilitate; calitatea nu este responsabilitatea doar a celor care au inscris termenul de calitate
in titlul functiei lor, iar controlul calitatii nu este ceva pe care sa-l efectuezi doar la sfarsitul unei
activitati. Conceptul de calitatea trebuie sa fie prezent pe tot parcursul proiectului.
Project Managerul trebuie sa stabileasca si documenteze un sistem de control al calitatii

(adica un set de procese si proceduri) pentru a se asigura ca in livrabilele proiectului se regaseste
calitatea specificata. In mod normal ascest sistem se va regasi documentat in Planul Calitatii sau
inclus in Documentul de Initiere al Proiectului si va cuprinde:
• Cerintele stipulate clar pentru totate livrabilele

• Un sistem defint, care sa controleze activitatile intreprinse
• Alocarea responsabilitatilor
• Evaluarile regulate
16.2 Asigurarea calitatii:
Cerintele esentiale pentru asigurarea functiei calitatii presupun sa se realizeze independent

urmatoarele:
• Sa se asigure ca sistemul de management al calitatii este conform cu cerintele
contractuale
• Sa se asigure functionalitatea sistemului de management al calitatii
• Sa se initieze orice actiune de imbunatatire necesara in vederea gestionarii scopului de
asigurare a calitatii
• Sa se asigure ca toate inregistrarile referitoare la asigurarea calitate sunt corespunzator
gestionate in cadrul proiectului
Organizatia in cadrul careia se deruleaza proiectul detine responsabilitea pentru asigurarea

calitatii. Activitatile de asigurare a calitatii sunt esentiale pe toata perioada de desfasurare a
proiectului, dar in general aceste activitati vor atinge punctul maxim in etapele majore de tranzitie,
cum ar fi: inceput sau sfarsit de etapa.
17. Managementul financiar
17.1 Necesitatea controlului financiar
Banii reprezinta esenta busines-ului si de accea managemntul financiar este o componenta

critica a responsabilitatilor Managerului de Proiect. Situatia financiala pentru nivelul de referinta
(cost, pret, venit, profit si flux de numerar) este stabilita la inceputul proiectului iar performantele
ulterioare sunt masurate relativ la acest nivel de referinta. Comenzile de schimbare genereaza
modificari ale acestui nivel de referinta pe durata proiectului, dar nivelul initial este intotdeauna
pastrat ca punct de referinta.
17.2 Responsabilitatile project managerului
Managerul de proiect are responsabilitatea controlului starii financiare a proiectului si el

este autoritatea care aproba toate cheltuielile dintr-un proiect.
Dupa nominalizarea sa pentru un proiect, chiar din primul moment, este de asteptat ca
Managerul de proiect sa obtina un raport financiar al proiectului (buget) dupa care acesta este
responsabil pentru toate aspectele finaciare ce tin de acel proiect.
Pe durata proiectului Managerul de Proiect cu ajutorul unor specialisti finaciari, daca este
cazul, trebuie sa intretina starea financiara curenta cel putin pentru urmatorii indicatori:
• Bugetul aprobat
• Cheltuielile la zi – actuale sau angajate
• Rezerva bugetara (contingency) – consumata si ramasa
• Valoarea facturata pana in prezent
• Valoarea veniturilor recunaoscute pana in prezent
• Valoarea profitului recunoscut pana in prezent
• Fluxul de numerar cumulat
Un responsabil din cadrul departamentul financiar-contabil este alocat pentru fiecare proiect
(de obicei partajat intre proiecte) pentru a asista si oferi sprijin in producerea rapoartelor fara insa ca
acest lucru sa insemne transferul de responsabilitate catre acesta pentru rezultatele financiare.
Echipa de vanzari continua sa detina responsabilitatea ofertelor si acestia pot avea obiective
de extindere a valorii proiectului. In acest sens acestia au un interes evident in rezultatele finaciare
ale proiectului dar numai Managerul de Proiect are responsabilitatea financiara pentru evolutia
proiectului.
Managerului de proeict i se poate solicita furnizarea unor rapoarte periodice referitor la
platile, incasarile si fluxul de numerar din proiect. De aceea este necesar ca acesta sa poata detine
controlul procesului de facturare, aprobarii platilor, comenzilor de achizitie, costurile personalului
propriu sau cel subcontractat. Este recomandat in acest sens sa existe o verificare periodica a
valorilor actuale.
In plus, Managerul de Proiect trebuie sa mentina un sumar al schimbarilor financiare
produse sau anticipate fata de valorile de la inceputul proiectului (ex. cele care au rezultat din
negocierile cu clientul pentru schimbarile controlate din proiect)
Este de asteptat ca Managerul de Proiect sa raporteze situatia lunara pentru Profit si
Pierdere (P&L) utilizand in acest sens un Raport al Situatiei Finaciare al carui format poate sa
difere de la un proiect la altul in functie de cerintele specifice ale departamentului financiar-
contabil. Regulile de recunoastere a veniturilor sunt diferite de cele pentru numerar si de aceea
trebuie stabilite cu managementul departamentului financiar-contabil si poate determina ca in unele
cazuri veniturile sa fie recunoscute mai tarziu decat data de facturare sau incasare.
Alocarea si utilizarea rezervei bugetare a proiectului trebuie agreata impreuna cu Managerul
de Business care este responsabil pentru proiect din partea organizatiei, iar aceasta rezerva trebuie
inclusa in P&L pentru a fi la dispozitia Managerului de Proiect in cazul in care trebuie folosita
In orice moment proiectul trebuie sa fie pregatit pentru un audit financiar care in orice
situatie trebuie sa fie finalizat fara a fi identificate discrepante majore.
17.3 Bugetul
Nivelul de referinta pentru situatia financiara (uneori denumita buget sau P&L) este stabilit
in faza de pre-contract sau de aprobare a ofertei. Situatia produsa in momentul ofertarii se poate
schimba uneori pe perioada negocierii, dar situatia asociata momentului in care contractul este
semnat devine practic bugetul proiectului.
Bugetul include toate metricile financiare pentru proiect (pret, costul total, rezerva si
profitul). El totodata contine detaliile de cost, venit si flux de numerar pentru fiecare etapa, de
obicei pentru fiecare luna sau trimestru, care sunt consolidate apoi pentru fiecare an al perioadei de
implementare a proiectului. Deoarece bugetul contine si rezerva pentru situatii neprevazute inclusa
in cost, uneori managerul de business doreste ca utilizarea acestei rezerve sa fie validata si de el.
Orice salvare realizata in fondul de rezerva poate creste profitul proiectului.
17.4 Previziuni
Previziunea asupra starii financiare a proiectului la sfarsitul acestuia reprezinta situatie

cheie pentru Managerul de Proiect care trebuie sa fie pregatit sa justifice aceasta situatie auditorilor
externi. Aceasta situatie trebuie sa tina cont de evolutia curenta a starii financiare a proiectului si
trebuie sa indice clar care va fi costul total al proiectului la incheierea ciclului sau de viata. Unde
este cazul, trebuie indicat si care va fi valoarea previzionata pentru fiecare an din ciclul de
implementare.
Pentru a fi realista, previzionarea trebuie sa includa si consideratiile Managerului de Proiect
asupra valorii fondului de rezerva ramas care va trebui utilizat pentru a incheia proiectul cu
respectarea obligatilor prevazute in contract.
Este esential ca previziunea asupra costului la finalizare (Forecast Cost At Completion) si
veniturilor la finalizarea proiectului sa tina cont de toate angajamentele contractuale, spre exemplu,
nu este permis sa fie previzionate venituri din angajamente aditionale care sa nu reflecte si costurile
asociate pentru livrarea acestor angajamente suplimentare. Daca previziunea asupra costului la
finalizare (FCAC) tine cont de costurile realizate pana in acel moment, atunci:
FCAC = Costul actual + Angajamentele + Costul necesar finalizarii

Unde costul necesar finalizarii include si evaluarea pentru utilizarea fondului de rezerva.
18. Raportarea si Evaluarea

18.1 Raportarea
Scopul realizarii rapoartelor este acela de a ajuta partile implicate intr-un proiect sa aiba in
permanenta informatii despre starea proiectului, evolutia acestuia, cat si despre potentialele
probleme. Rezultatul acestui proces de raportare permite ca atentia persoanelor implicate in
managementul proiectului sa fie indreptata catre problemele importante sau acolo unde implicarea
lor activa este ceruta. De asemenea, raportarea reprezinta un mijloc esential de comunicare formala
periodica.
In vederea realizarii rapoartelor periodice Managerul de Proiect trebuie sa tina cont de trei
aspecte (cine trebuie sa raporteze si ce, cui si cand):
• Cerintele clientul – a se vedea asemenea cerintele in cadrul contractului
• Metodele de management a PM Solutions
• Cerintele proiectului
Pe langa raportarea periodica managerul de Proiect trebuie sa:

• Intocmesca rapoarte predefinite cerute de aparitia unui anumit eveniment (ex. raport
pentru incheierea unei anumite etape)
• Intocmeasca rapoarte ca raspuns la o anumita solicitare
• Producerea de rapoarte in vederea escaladarii problemelor aparute (ex. de exceptie)
• Rapoarte de stare pentru evenimentele importante din proiect (ex. acceptante)
18.2 Rapoarte lunare
Raportarea formala in cadrul unui proiect reprezinta un element esential in conducerea

proiectului. Scopul sau este de a crea si mentine o linie de comunicare eficienta intre proiect,
organizatie si management, care sa permita urmatoarele actiuni:
• Informare – cu privire la situatia curenta si la evolutia proectului, si care sa permita o
evaluare activa
• Alertare – cu privire la potentialele probleme
• Suport – pentru rezolvarea problemelor curente
18.3 Evaluare
Pentru ca beneficiile unui proces de evaluare sa fie maxime este important ca cei implicati
in acest proces sa cunoasca urmatoarele aspecte:
• Scopul evaluarii
• Persoanele care vor lua parte la evaluare
• Informatiile de intrare necesare
In urma oricarui proces de evaluare se recomanda ca actiunile stabilite sa se desfasoare,

punctele de vedere, intelegeri sau aprobari sa fie documentate si sa fie prezentate celor care au
participat sau au fost invitati la sedinta de evaluare.
18.4 Evaluare proiectului
Project Managerul stabileste la inceputul proiectului o schema pentru evaluarile periodice

ale stadiului proiectului. Pentru evaluarile determinate de anumite situatii speciale vor trebui
stabilite care sunt factorii sau evenimentele care pot declansa acest proces. Ca cerinta minima,
evaluarile trebuie sa evidentieze:
• Evolutia proiectului – situatia curenta fata de plan, problemele aparute, riscurile
materializate
• Situatia financiara curenta, bugetul proiectului
• Design-ul solutiei – conformitate, stadiu de indeplinire
• Cererile de schimabare
19. Acceptanta
Acceptanta este documentul pe care PM Solutions il obtine de la clientul sau in momentul

in care produsele specificate sau intregul proiect indeplinesc cerintele contractuale. In mod similar,
acceptanta este si documentul pe care PM Solutions il da unui subcontractor al sau in urma
indeplinirii cerintelor contractuale. Acest proces este deseori asociat cu efectuarea platii catre sau de
catre PM Solutions.
19.1 Criterii de acceptanta
Criteriile de acceptanta furnizeaza baza pentru a se stabili daca produsele care au fost
livrate indeplinesc cerintele de acceptanta. Criteriile trebuie sa fie:
• Cuantificabile, adica trebuie stipulat ce se va masura
• Verificabile, trebuie sa se poata determina indeplinirea lor
• Documentate
In scopul protejarii intereselor PM Solutions, este foarte important sa se:

• Defineasca criteriile cat mai devreme posibil
• Stabileasca si implementeze metodologia de control al schimbarii conform cu criteriile
alese
• Sa se asigure acoperirea tuturor livrabilelor importante ale proiectului.
Uneori nu este posibil sa se defineasca criteriile de acceptanta in detaliu inainte de inceprea

efectiva a activitatilor cerute de proiect. Este insa foarte important sa se stabileasca criteriile de baza
si sa se agreeze un plan pentru detalierea mai tarzie a acestora.
19.2 Procesul de acceptanta
Planul de acceptanta trebuie sa includa o descriere clara pentru urmatoarele:

• Cum se va demonstra acceptanta, ce teste vor fi facute pentru a demonstra respectarea
criteriilor stabilite;
• Cand si unde va avea loc acceptanta
• Cine va efectua acceptanta
• Cum vor fi documentate rezultatele procesului de acceptanta
• Cum va fi rezolvat un proces de acceptanta incomplet
20. Inchiderea proiectului
Proiectele au si ele o faza de inceput, o perioada de derulare, de mijloc, si etapa de sfarsit.

Aceasta ultima faza – inchiderea proiectului – trebuie astfel realizata incat sa asigure o concluzie
clara si sa previna situatiile de confuzie. Astfel este recomandat sa se intocmeasca un Raport de
Inchidere si sa se organizeze o Evaluare de Inchidere.
20.1 Raportul de inchidere a proiectului
Raportul trebuie sa includa:

• Un rezumat al situatiei financiare de la sfarsitul proiectului realizat in comparatie cu
situatia financiara stabilita la inceputul acestuia
• Un rezumat al rezultatelor proiectului comparativ cu planurile si obiectivele stabilite la
inceputul acestuia
• Cum s-a realizat controlul schimbarii si cum a influentat schimbarea linia de baza a
proiectului
• Nivelurile de satisfactie ale clientului si problemele aparute
• Situatii ce trebuiesc retinute: ceea ce a mers bine; ceea ce nu a mers – si de ce

• Recomandari si actiuni ce vor urma sa fie intreprinse
20.2 Evaluarea de Inchidere
Evaluarea de Inchidere trebuie efectuata in concordanta cu evaluarile altor proiecte aflate in

faza de sfarsit, iar deciziile si actiunile sa fie documentate. Project Managerul trebuie sa pregateasca
raportul si sa-l prezinte la intalnirea de evaluare.
Evaluarea trebuie sa cuprinda:
• Performantele proiectului comparativ cu linia de baza si obiective
• Situatia financiara a proiectului
• Facturi si plati ce urmeaza a fi efectuate
• Conformitatea cu cerintele produsului finit
• Produsele ce trebuiesc livrate/transferate
• Documentatia ce cuprinde acceptanta si certificatele
• Satisfactia clientului
• Confirmarea incheierii activitatilor stabilite sa se efectueze de-a lungul proiectului
• Lista cu orice alte probleme sau actiuni ce pot fi rezolvate sau inteprinse de
management in viitor
• Cerintele pentru actiunile viitoare de control al schimbarii
• Cererea pentru retinerea de documente si rapoarte
• O colectie de statistici si metrice in vederea revizuirii criteriilor de estimare
• Eficienta actiunilor sau deciziilor rezultata din procesul de management al riscului
• Identificarea initiativelor de mbunatatire a calitatii
• Daca se poate da aprobarea pentru incheierea proiectului
20.3 Incheierea proiectului
In momentul in care se da aprobarea pentru incheierea proiectului, Managerul de proiect

transfera responsabilitatea echipei de suport (acolo unde suportul este o cerinta contractuala),
elibereaza membrii echipei de proiect si da o Notificare de Incheiere de Proiect celor care au
furnizat resurse pentru proiect si tuturor celor care trebuie sa fie anuntati ca proiectul a luat sfarsit.
21. Suport si mentenanta
Incheierea livrarilor cerute prin contract reprezinta sfarsitul livrarii unei solutii. Nu trebuie
insa considerat ca acesta este si sfarsitul relatiei dintre PM Solutions si client.
Daca solutia oferita va fi utilizata de catre client ca suport pentru activitatea sa atunci este
foarte posibil ca el sa aiba nevoie de suport din partea furnizorului, constand in urmatoarele:
• Cursuri
• Suport utilizatori si consultanta
• Incarcare date / conversie
• Intretinere pentru produsele hardware
• Trecerea la versiuni noi pentru produsele software
• Corectare erori (bug-uri) in perioada de garantie sau in afara ei
Aceste activitati sunt importante pentru ca un proiect livrat cu succes sa se transforme intr-o
solutie de succes pentru client. In unele situatii este nevoie sa se realizeze un plan de transfer al
capabilitatilor de la echipa de proiect catre organizatia clientului, dar foarte important este ca
intotdeauna sa se planifice activitatile suport si sa se desfasoare de-a lungul proiectului, nu sa se
astepte livrarea si incheierea lui pentru a se lua in discutie aceste probleme.
In momentul in care clientul poate aprecia beneficiile oferite de solutie este foarte posibil sa
se poata:
• Dezvolta functionalitatea solutiei
• Extinde aria de utilizare a solutiei
Aceste oportunitati pot duce la lucru suplimentar comparativ cu activitatile de desfasurat in

cazul solutiei originale. Daca proiectul implica livrari in faze sau activitati pilot, este foarte posibil
ca oportunitatile de extindere a solutiei sa apara inainte de ultimele faze ale proiectului.
Pe langa imbunatatirea solutiei originale, clientul poate identifica si alte oportunitati legate
de solutia oferita si care sa duca la proiecte viitoare alaturi de PM Solutions si partenerii sai.

Metodologia PRINCE 2

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Metodologia PRINCE 2

Încărcat de

Drepturi de autor:

Formate disponibile

Workshop - Managementul proiectelor informatice

Bucureşti, 27 octombrie 2004

Metodologia PRINCE 2 (PRojects IN Controlled Environments)

Rezumat: Articolul prezintă metodologia Prince2 (structura, procesele, componentele, tehnicile,

• Este o metodologie scalabila si flexibila de management de proiect dezvoltata in Marea

2. Structura metodologiei PRINCE

Metodologia PRINCE este structurata in trei parti:

3. Procesele metodologiei PRINCE 2

Management-ul organizatiei sau al programului

5. Tehnicile metodologiei PRINCE 2

Tehnica specifica metodologiei PRINCE este Planificarea bazata pe produs (Product

In viziunea PM Solutions urmatoarele procese sunt critice in livrarea cu succes a oricarui

6.1 Initerea proiectului

Documentul de initiere a proiectului (PID) se elaboreaza pentru fiecare proiect in parte

6.2 Managementul Nivelului de Referinta (Baseline Management)

6.3 Definirea cerintelor proiectului

6.4 Desemnarea Comitetului de Conducere al priectului (Project Board)

Comitetul de Conducerea al Proiectului este alcatuit, de obicei, dintr-un reprezentant din

6.5 Managementul Riscurilor

Pentru toate proiectele se elaboreaza un Plan al Riscurilor. Pentru producerea acestuia se

6.6 Planurile proiectului

6.7 Managementul calitatii

6.8 Controlul schimbarilor

Metodologia PRINCE II acorda o foarte mare importanta nevoii de schimbare in derularea

6.9 Managementul Configuratiei

Planul pentru Managementul Configuratiei descrie structura initiala a proiectului si

metodele de implementare a Managementul Configuratiei trebuie sa fie identificate in functie de

6.10 Managementul documentelor si biblioteca proiectului

Biblioteca proiectului cuprinde toate documentele proiectului. Evidenta documentelor este

6.11 Revizuirea design-ului

6.12 Urmarirea si auditul proiectului

Politica de arhivare sustinuta de responsabilitati clare este impetuos necesara pentru a

6.14 Conducerea echipei

6.15 Evaluarea proiectelor si raportarea

6.17 Managementul problemelor

Managerul de proiect are obligatia de a implementa o procedura care sa adreseze modul in

Pentru toate proiectele se defineste un Plan de Acceptanta care descrie ce componente

6.19 Strategia pentru suport

In general perioada de suport (mentenanta) este de obicei o faza post-acceptanta in ciclul de

6.20 Inchiderea proiectului

Toate proiectele se finalizeaza cu un Raport Final al Proiectului care trebuie sa cuprinda

6.21 Conformitatea cu standardul ISO 9001

Pentru proiectele care au ca obiectiv dezvoltarea de produse software, procesele orientate pe

7. Documentul de initiere a proiectului (PID)

In cadrul Procesului de Initiere a unui proiect echipa manageriala:

PID cuprinde urmatoarele documente:

• Descrierea proceselor din cadrul proiectului si a dependentelor dintre acestea;

Fiecare proiect urmeaza procese si proceduri standard, acestea fiind sustinute si de

8.1 Responsabilii cu definirea livrabilelor si dependentelor dintre acestea

• Care sunt livrabilele proiectului

Aceste informatii trebuie sa se defineasca in faza de pre-contract a proiectului, tinandu-se o

8.2 Care sunt livrabilele unui proiect?

Project Manager-ul trebuie sa identifice tipurile de livrabile si dependentele dintre acestea,

• Documentatie (ex: caiete de sarcini, specificatii, rapoarte)

8.3 Cui livram?

Managerul de proiect trebuie sa identifice care sunt persoanele responsabile cu procurarea

Scopul elaborarii structurii detaliate orientata pe activitati:

9. Managementul nivelului de referinta (Baseline Management)

Mmanagementul nivelului de referinta descrie tehnicile folosite in stabilirea

Este imperativ ca nivelul de referinta sa reflecte cerintele contractuale si sa nu urmareasca

Scopul managementului nivelului de referinta este:

• Controlul simplu prin simplificarea tuturor proceselor de control necesare si stabilirea

Orice modificare in cerinte trebuie sa fie reflectata in modificari corespunzatoare acceptate

Nivelul de referinta al proiectului reprezinta definitiile curente si aprobate ale: