Ghid - Metodologic Licitatii Informatice

Faster and Better E-Government Solutions
Ghid Metodologic pentru Managementul

Proiectelor Informatice

Pagina 1 din 87

Acest Ghid este proprietatea ANIAP i este oferit membrilor ANIAP precum i tuturor funcionarilor publici
implicai n proiecte de Tehnologia Informaiilor i Comunicaii n scopul de a-i ajuta n scrierea Documentaiei
Standard pentru Elaborarea i Prezentarea Ofertei pentru aceste proiecte, precum i n derularea proiectelor. Acest
Ghid a fost elaborat pe baza metodologiilor de Management de Proiect recunoscute pe plan internaional i conine,
de asemenea, recomandri generale privind derularea proiectelor din partea membrilor ANIAP care au contribuit la
redactarea Ghidului.
ANIAP asigur asisten tehnic pentru implementarea acestui ghid la cererea autoritilor locale.
Utilizarea acestui Ghid este opional.
ANIAP nu este rspunztoare de rezultatele proiectelor n cadrul crora se vor folosi informaiile prezentate n
cadrul acestui Ghid sau modul n care acestea sunt utilizate.
TITLU: Ghid Metodologic pentru Managementul Proiectelor Informatice
DESCRIERE:
Aceast publicaie a fost tiprit cu sprijinul Ageniei Statelor Unite pentru
Dezvoltare Internaional,n cadrul contractului ARD Inc de "Asisten
acordat administraiei publice locale",Contractul Nr. AEP-I-00-00-00016-00,
Comanda Nr. 810.
Opiniile exprimate n cadrul ghidului aparin autorilor i nu reflect vederile
Ageniei Statelor Unite pentru Dezvoltare Internaional.
Acest ghid poate fi utilizat i copiat n scopuri necomerciale atta vreme ct
ANIAP este creditat ca surs i "USAID" este menionat ca finanator.
n acest context, documentul cuprinde recomandri n vederea
organizrii i conducerii proiectelor informatice derulate n cadrul
Administraiei Publice Locale din Romnia.
AUTORI:

Adrian Georgescu - Consiliul Judeean Dmbovia
Adrian Imireanu - Primria Municipiului Focani
Adrian Teac - Primria Municipiului Slobozia
Camelia Iordache - Primria Municipiului Cmpulung Moldovenesc
Ctlin Hristea - consultant
Ctlin Tiseac - consultant
Constantin Moga - Consiliul Judeean Mure
Dan Artimon - Consiliul Judeean Botoani
Delia Ariana Zupcu - Primria Municipiului Timioara
Diana Bondoc - Ministerul Transporturilor,Construciilor i Turismului
Dumitru Marian Popescu - Consiliul Judeean Gorj
Eugen Antal - Consiliul Judeean Bihor
Gabriela Gavri - Primria Municipiului Oradea
Ioana Raicu - Primria Municipiului Bucureti
Lucian Dorr Primria Municipiului Bucureti
Marcela Lcrmioara Zaharia - Consiliul Judeean Slaj
Marian Vrabie - Consiliul Judeean Brila
Mihaela olic - Centrul de Calcul Consiliul General Bucureti
Mikls-Pl Gbor - Consiliul Judeean Harghita
Mugurel Radu Predescu - Primria Municipiului Trgu Jiu
Natalia Ceptureanu - Consiliul Judeean Dmbovia
Nicu Vasile - Consiliul Judeean Prahova
Richina Balaci - Primria Municipiului Lugoj
Sevil Sumanariu - Consiliul Judeean Constana
Viorel Manca Primria Municipiului Galai



Pagina 2 din 87
Coninut:
1. CONTROLUL DOCUMENTULUI 5
1.1 Proprietarul documentului 5
1.2 Istoricul documentului 5
1.3 Modificri viitoare 5
1.4 Bibliografie 5
1.5 Abrevieri 5
2. INTRODUCERE 6
2.1 Necesitate 6
2.2 Structur i obiective 6
2.3 Grup int 7
3. ANALIZA SITUAIEI EXISTENTE CU PRIVIRE LA
IMPLEMENTAREA PROIECTELOR TIC 8
3.1 Introducere 8
3.2 Categorii de probleme identificate 9
3.2.1 Probleme identificate n organizarea proiectelor 9
3.2.2 Probleme identificate n planificarea proiectelor 10
3.2.3 Probleme identificate n controlul proiectelor 11
3.2.4 Probleme identificate n managementul calitii 12
3.2.5 Probleme identificate n managementul schimbrilor i al configuraiilor 12
3.2.6 Probleme identificate n managementul riscului 13
3.3 Concluzii 14
4. DOCUMENTE ELABORATE N VEDEREA LANSRII
PROIECTELOR 15
4.1 Introducere 15
4.2 Etapele demarrii proiectului 15
4.2.1 Etapa pregtitoare 15
4.2.2 Etapa de achiziie 16
4.3 Modele de documente 17
5. METODOLOGIA DE MANAGEMENT AL PROIECTELOR 18
5.1 Introducere 18



Pagina 3 din 87
5.1.1 Ce este un proiect? 18
5.1.2 De ce proiectele au nevoie de management? 18
5.1.3 Arie de aplicabilitate 18
5.1.4 Alte precizri 19
5.1.5 Organizarea acestei seciuni 19
5.2 Noiuni de baz privind managementul de proiect 20
5.2.1 Organizarea proiectului 20
5.2.2 Planificarea proiectului 26
5.2.3 Controlul proiectului 31
5.2.4 Management-ul Riscurilor 39
5.2.5 Calitatea 42
5.2.6 Management-ul Configuraiilor 44
5.2.7 Controlul Schimbrii 46
6. CAIETUL DE SARCINI CERINE SPECIFICE PRIVIND
MANAGEMENTUL PROIECTELOR 48
6.1 Organizarea proiectului (vezi 5.2.1) 48
6.2 Planificarea proiectului (vezi 5.2.2) 49
6.3 Controlul proiectului (vezi 5.2.3) 50
6.4 Management-ul riscurilor (vezi 5.2.4) 53
6.5 Calitatea (vezi 5.2.5) 53
6.6 Management-ul configuraiilor (vezi 5.2.6) 54
6.7 Controlul schimbrii (vezi 5.2.7) 54
6.8 Criterii de evaluare a ofertelor 55
7. ALTE RECOMANDRI 56
7.1 Clauze contractuale 56
7.2 Recomandri diverse 60
7.3 List de verificare a documentelor de proiect 62
7.3.1 Iniializarea proiectului 62
7.3.2 Planificare 63
7.3.3 Raportare 63
8. GLOSAR DE TERMENI 64
9. ANEXE 66
9.1 Anexa 1: Propunerea de Proiect 67
9.2 Anexa 2: Determinarea dimensiunii proiectelor 73



Pagina 4 din 87
9.3 Anexa 3: Livrabilele de Management ale Proiectului 75
9.4 Anexa 4: Descrierea principalelor roluri din proiect 76
9.4.1 Comitetul de Conducere al Proiectului 76
9.4.2 Managerul de Proiect 78
9.4.3 Coordonatorul de Proiect al Beneficiarului 79
9.5 Anexa 5: Model de Curriculum Vitae n conformitate cu HGR 1012/25.06.2004 81
9.6 Anexa 6: Formular de diagnoz 83
9.6.1 INTRODUCERE 83
9.6.2 ORGANIZAREA PROIECTELOR 84
9.6.3 PLANIFICAREA PROIECTELOR 85
9.6.4 CONTROLUL PROIECTELOR 85
9.6.5 MANAGEMENT-UL CALITATII 86
9.6.6 MANAGEMENT-UL SCHIMBARII 86
9.6.7 MANAGEMENT-UL RISCULUI 87



Pagina 5 din 87
1. CONTROLUL DOCUMENTULUI
1.1 Proprietarul documentului
Acest document a fost elaborat de ctre ANIAP.
1.2 Istoricul documentului
Revizia Data reviziei Autor Sumarul schimbrilor
Ver. 00.01 04.07.2005 ANIAP Prima versiune pentru discuii
Ver. 00.02 15.07.2005 ANIAP A doua versiune dup seminarul
ANIAP. ncorporarea tuturor
observaiilor i reorganizarea
documentului.
Ver. 00.03 16.07.2005 ANIAP Versiunea final pentru revizia
ANIAP.
Ver. 1.00 18.07.2005 ANIAP Revizia final versiunea 1.0
1.3 Modificri viitoare
n urma reviziei finale a ANIAP.
1.4 Bibliografie
Metodologia de Management de Proiect PRINCE2
Jack Meredith, Samuel J. Mantel, Jr, Project Management. A managerial
approach, fourth edition, 2000, John Wiley&Sons
Curaj Adrian, Apetroae Marin, Purnus Augustin, Scarlat Cezar, Munteanu Radu-
Practica Managementului de proiect.2004. Ed.Economic
http://www.stickyminds.com
http://www.qaforums.com
http://www.projectmanagement.tas.gov.au
1.5 Abrevieri
ANIAP Asociaia Naional a Informaticienilor din Administraia Public
TIC Tehnologia Informaiilor i Comunicaii
USAID United States Agency for International Development



Pagina 6 din 87
2. INTRODUCERE
2.1 Necesitate
Insuficienta aplicare a metodologiilor recunoscute de management al proiectelor
este una din principalele cauze ale disfuncionalitilor proiectelor informatice
derulate n cadrul administraiei publice locale. Fie c este vorba despre ntrzierea
proiectelor, despre alegerea greit a soluiei tehnice, despre atingerea parial a
obiectivelor stabilite sau despre neutilizarea sistemelor informatice implementate,
disfuncionalitile proiectelor TIC au influene majore asupra eficienei activitii i
a performanei nregistrate.
Din aceste motive, ANIAP consider c reglementarea modalitii de organizare,
demarare i conducere a proiectelor informatice poate constitui un instrument
efficient de minimizare a disfuncionalitilor i poate astfel ajuta la optimizarea
performanei proiectelor TIC .
2.2 Structur i obiective
Ghidul este structurat n 9 capitole, care urmresc urmtoarele obiective:
Analiza situaiei existente, cu privire la implementarea proiectelor TIC
identificarea principalelor probleme care apar n cadrul derulrii proiectelor
informatice din cadrul Administraiei Publice din Romnia. Plecnd de la
efectele sesizate n cadrul proiectelor, aceast seciune identific principalele
cauze care duc la materializarea disfunciunilor n cadrul proiectelor;
Lansarea proiectelor n interiorul organizaiei aceast seciune identific
modalitatea recomandat de control a evoluiei proiectului n etapa de
lansare, din momentul identificrii necesitii proiectului i pn la
finalizarea procedurii de achiziie public (acolo unde este cazul) ;
Metodologia de management al proiectelor seciunea prezint elementele
principale ale unei metodologii de management de proiect, care poate fi
utilizat pe perioada implementrii proiectului (din momentul finalizrii
procedurii de achiziie public prin semnarea unui Contract i pn n
momentul finalizrii tuturor activitilor de implementare prin obinerea
Certificatului de Acceptan);
Caietul de Sarcini aceast seciune identific recomandri privind cerinele
referitoare la managementul de proiect care pot fi incluse n caietele de
sarcini elaborate n vederea demarrii proiectelor TIC n cadrul
Administraiei Publice. Scopul acestor cerine este, pe de o parte, acela de a
stabili un prag minimal n domeniul managementului de proiect care s fie
respectat de ctre toi ofertanii , iar pe de alt parte de a permite departajarea
acestora n cadrul procedurii de achiziie public;
Alte recomandri aceast seciune prezint succint diferite recomandri ale
membrilor ANIAP n scopul derulrii mai eficiente a proiectelor TIC n
cadrul Administraiei Publice Locale. Aceste recomandri vin din experiena
personal a autorilor Ghidului, conin inclusiv recomandri privind diferite
clauze care pot fi introduse n cadrul Contractelor i trebuie interpretate ca
recomandri i nu ca impuneri;
Glosar de termeni avnd n vedere faptul c termenii specifici
metodologiilor de management al proiectelor nu sunt nc ncetenii n



Pagina 7 din 87
limba romn, aceast seciune prezint echivalentul n limba englez al
diferiilor termeni specifici folosii n cadrul acestui Ghid;
Anexe diferite anexe care pot ajuta la nelegerea acestui Ghid.
2.3 Grup int
Acest Ghid se adreseaz personalului din cadrul administraiei publice locale care
iniiaz/deruleaz proiecte de informatizare. De asemenea, seciuni din acest Ghid
pot fi incluse n Documentaia pentru Elaborarea i Prezentarea Ofertei n scopul
susinerii cerinelor pentru organizarea i conducerea proiectului, cerine la care
Ofertanii trebuie s rspund.



Pagina 8 din 87
3. ANALIZA SITUAIEI EXISTENTE CU PRIVIRE LA
IMPLEMENTAREA PROIECTELOR TIC
3.1 Introducere
Prima etap a proiectului finanat de ctre USAID-ARD: "Faster & Better e-
Government Solutions" a constat n analiza situaiei existente n proiectele TIC din
administraia public local din Romnia. Analiza a avut ca prim obiectiv stabilit
identificarea problemelor manifestate pe ntreg parcursul ciclului de via al
proiectelor, evaluarea cauzelor care determin aceste probleme, precum i impactul
produs de acestea .
A fost urmrit modul n care se aplic metodologia de management de proiect,
precum i existena unor procese i livrabile de management de proiect pe parcursul
implementrii proiectelor din administraia public local. Pe lng identificarea
problemelor, s-a avut n vedere i o evaluare a anvergurii acestora.
n vederea derulrii etapei de analiz, echipa de proiect a produs chestionarul
"Formular de diagnoz" (Anexa 6) care a fost trimis spre completare membrilo
ANIAP , formulare care au fost ulterior analizate n vederea evalurii situaiei
existente in implementarea proiectelor.
ntrebrile din cadrul chestionarului au fost astfel elaborate i grupate nct s
urmreasc componentele unei metodologii de management de proiect:
Organizarea proiectelor
Planificarea proiectelor
Controlul proiectelor
Managementul calitii
Managementul schimbrilor
Managementul riscului
Managementul configuraiilor
Scopul ntrebrilor chestionarului a fost evaluarea modului n care componentele de
management de proiect sunt aplicate i nu existena cunotinelor teoretice din
domeniu ale celor intervievai.
Prima seciune din chestionar a avut ca scop identificarea tipurilor de proiecte TIC
pe care administraia public local le deruleaz. Au fost identificate urmtoarele
tipuri de proiecte:
achiziii de echipamente
achiziii de licene standard
implementarea de soluii software
implementarea unor sisteme integrate (hardware & software)
n urma consolidrii informaiilor din aceast seciune a chestionarului a rezultat
faptul c n administraia public local, cel puin pn n prezent, majoritatea
proiectelor au constat n achiziia de hardware i software standard (cca. 60%).
Acest fapt tinde n prezent s se schimbe iar proiectele de soluii software sau chiar
de sisteme integrate ctig teren n faa proiectelor de achiziii de produse. Cele
mai des ntlnite proiecte n administraia public local sunt cele de implementare a



Pagina 9 din 87
aplicaiilor financiar-contabile (inclusiv de taxe i impozite), implementarea
aplicaiilor GIS i a portalurilor pentru instituiile administraiei publice locale.
n acest context, existena i aplicarea unei metodologii de management de proiect
n implementarea proiectelor din administraia public local devine vital pentru
succesul acestor proiecte i pentru atingerea obiectivelor instituiei.
3.2 Categorii de probleme identificate
n cadrul acestei seciuni vor fi prezentate tipul problemelor identificate, cauzele
posibile de producere i impactul pe care aceste probleme, odat manifestate, l
produc asupra proiectelor sau asupra instituiilor.
Urmtoarele probleme se manifest n cadrul proiectelor TIC derulate n cadrul
administraiei publice locale:
ntrzierea finalizrii proiectelor
creterea costurilor de implementare ale proiectelor
nerealizarea unor livrabile ale proiectelor sau ntrzierea lor
nerespectarea standardului de calitate pentru livrabile
nerespectarea (parial sau total) a cerinelor utilizatorilor
diminuarea gradului de ncredere n capacitatea de livrare a furnizorului
erodarea relaiilor dintre organizaia furnizorului i a beneficiarului sau dintre
membrii acestor organizaii
abaterea de la obiectivele stabilite ale proiectului
Aceste probleme determin n ultim instan eecul parial sau total al proiectelor
prin neatingerea obiectivelor propuse sau nerespectarea constrngerilor stabilite.
n gruparea problemelor identificate a fost respectat structura general a
componentelor oricrei metodologii de management de proiect.
3.2.1 Probleme identificate n organizarea proiectelor
Principalele probleme identificate pentru aceast component sunt urmtoarele:
nu este foarte clar stabilit fa de cine raporteaz managerul de proiect pe
parcursul implementrii proiectului
coordonatorul de proiect al beneficiarului nu are pregtirea necesar pentru a
monitoriza i evalua modul n care managementul de proiect este realizat de
ctre furnizor
organizaia care furnizeaz proiectul sau managerul de proiect nu are capacitatea
de a realiza managementul implementrii unor proiecte complexe
produsele rezultate n urma implementrii proiectului nu sunt folosite de ctre
utilizatorii finali
refuzul de colaborare i de acceptare a produselor din partea persoanelor care
utilizeaz produsele realizate n cadrul proiectului
indisponibilitatea sau dezinteresul resurselor beneficiarului fa de derularea
proiectului



Pagina 10 din 87
nerezolvarea la timp a problemelor aprute n proiect
specificaia cerinelor nu acoper corect sau complet cerinele utilizatorilor
nerecunoaterea sau subminarea autoritii managerului de proiect
Cauzele care produc aceste probleme sunt n general urmtoarele:
nu este stabilit un comitet de conducere al proiectului nainte de demararea
acestuia
coordonatorul de proiect al beneficiarului nu este ntotdeauna identificat de ctre
conducerea instituiei pe baza abilitilor i experienei de management de
proiect; de regul, acesta este ales din cadrul departamentului de TIC
nu exist o nominalizare oficial a membrilor echipei de proiect a
beneficiarului, cu descrierea rolului i a responsabilitilor specifice n proiect
departamentele care beneficiaz de pe urma proiectului sau utilizeaz produsul
acestuia nu sunt ntotdeauna implicate direct n derularea proiectului, sau nu
sunt reprezentate n comitetul de conducere al proiectului
furnizorii nu nominalizeaz ntotdeauna n mod oficial (n cadrul unui document
de proiect) echipa proprie de proiect i/sau managerul de proiect i nu descriu
rolurile i reponsabilitile pentru membrii echipei de proiect
nu ntotdeauna sunt folosite mijloacele (instrumentele) cele mai eficiente pentru
prezentarea problemelor aprute n derularea proiectului n vederea lurii de
decizii n timp util de ctre persoanele autorizate
n cele mai multe cazuri nu se solicit furnizorului prezentarea n cadrul ofertei
tehnice a metodologiei de management de proiect pe care acesta o va utiliza pe
parcursul proiectului
de foarte multe ori nu este solicitat furnizorului s fac dovada capacitii sale
de management de proiect, s prezinte CV-ul pentru managerul de proiect
propus i dovezile care s ateste experiena acestuia n managementul unor
proiecte de anvergur similar
caietele de sarcini nu prevd n mod explicit responsabilitatea conducerii
proiectului (a sarcinilor i a responsabilitilor organizaiilor furnizor i
beneficiar) i nu includ cerine specifice pentru managementul proiectului
nu este solicitat n caietele de sarcini identificarea n cadrul ofertei financiare a
ofertantului a costurilor asociate managementului de proiect
3.2.2 Probleme identificate n planificarea proiectelor
dependenele pentru proiect nu sunt corect sau complet identificate
estimarea nerealist a duratelor pentru activitile din cadrul etapei
alocarea resurselor este defectuoas (insuficient)
ntrzierea activitilor deoarece resursele nu sunt disponibile atunci cnd este
necesar



Pagina 11 din 87
nu sunt luate n considerare n cadrul proceselor de planificare toate elementele
care necesit planificare
nu sunt folosite metode sau instrumente specifice n cadrul planificrii
planificarea detaliat nu este ntotdeauna realizat la nceputul etapelor, atunci
cnd informaiile relevante necesare planificrii sunt disponibile
3.2.3 Probleme identificate n controlul proiectelor
problemele care apar pe parcursul derulrii proiectelor nu sunt identificate la
timp i/sau nu sunt soluionate optim sau n timp util
beneficiarul nu cunoate ntotdeauna care este stadiul real al proiectului, sau
care sunt problemele cu care furnizorul se confrunt la un moment dat
coordonatorul de proiect al beneficiarului nu are prghiile instituionale
corespunztoare pentru a controla n mod eficient un proiect
serviciile sau documentele care trebuie produse nu sunt ntotdeauna cunoscute
sau clar identificate n Contract
reponsabilitile prilor i dependenele reciproce sunt ambiguu exprimate
metodele de acceptare pentru livrabile nu sunt identificate n mod explicit
testele care trebuie realizate nainte de acceptarea unui produs sau serviciu nu
sunt identificate i rezultatele testelor nu sunt riguros documentate
nu sunt cunoscute ntotdeauna responsabilitile privind controlul i raportarea
progresului
nu se cunoate care este ordinea de prioritate a documentelor contractuale n
cazul n care exist contradicii ntre prevederile acestora
exist deseori nenelegeri cu reprezentanii furnizorului datorit ntelegerii
diferite a ceea ce trebuie livrat sau a modului n care trebuie livrat
contractele ncheiate nu conin suficiente detalii care s permit un control
eficient al proiectelor
furnizorii nu includ n ofertele lor detalii referitoare la: reponsabilitile prilor
i dependenele reciproce, testele care trebuie realizate, metodele de acceptare
pentru livrabile
caietele de sarcini nu prevd ntotdeauna responsabilitile prilor privind
controlul i raportarea progresului
nu exist n contract o clauz care s prevad ordinea n care diferitele
documente care fac parte din contract vor fi interpretate
modalitile i instrumentele de control nu sunt folosite ntotdeauna ntr-un mod
eficient de ctre coordonatorul de proiect al beneficiarului: edine de
identificare a progresului, edine de rezolvare a problemelor, edine de control
cu furnizorii, edine de raportare ctre conducere, rapoarte scrise i scrisori
(puncte de vedere)



Pagina 12 din 87
3.2.4 Probleme identificate n managementul calitii
livrabilele realizate de proiect nu corespund standardelor de calitate aplicabile i
stabilite pentru proiect
procesul de testare nu scoate n eviden toate neconformitile livrabilelor
livrabilele realizate de proiect nu pot fi folosite de ctre utilizatori datorit
disfuncionalitilor majore care apar imediat dup intrarea n perioada de
operare a acestora
furnizorul nu este n msur s asigure i s controleze calitatea pe perioada
desfurrii proiectului
organizaia beneficiarului sau a furnizorului nu nelege ntotdeauna ce
nseamn calitatea n mediul de proiect
caietele de sarcini nu conin ntotdeauna criterii de calitate pentru toate
livrabilele proiectului
nu sunt clar stabilite sau cunoscute criteriile de calitate care se aplic diferitelor
tipuri de livrabile (echipamente, licene software, servicii de analiz, servicii de
implementare, servicii de instruire, servicii de suport si asisten tehnic,
documente tehnice, documente de analiz, rapoarte, grafice de implementare
etc.)
nu se solicit n cadrul caietului de sarcini prezentarea de ctre ofertant a
modului n care acesta va asigura calitatea livrabilelor pe parcursul desfurrii
proiectului
furnizorii nu prezint n cadrul ofertelor tehnice modalitatea practic n care
acetia vor asigura i controla calitatea livrabilelor proiectului, menionarea
existenei certificrii ISO fiind de multe ori singura referire la calitate
necunoaterea n totalitate sau neaplicarea tuturor tipurilor de criterii n baza
crora se realizeaz n cadrul proiectelor testarea i acceptarea livrabilelor
3.2.5 Probleme identificate n managementul schimbrilor i al configuraiilor
modificarea cerinelor beneficiarului pe parcursul derulrii proiectului i
imposibilitatea furnizorului de a rspunde la aceste schimbri n mod eficient
neintegrarea unor sub-sisteme sau componente n sistemul final n urma
implementrii unor schimbri la nivelul acestora
apariia unor ntrzieri sau costuri neplanificate sau neaprobate n urma realizrii
unor modificri la specificaia livrabilelor
livrarea unor produse care s nu fie funcionale sau utilizabile
dei este acceptat de marea majoritate a intervievailor c existena unei
proceduri scrise care s documenteze exact toate elementele unei schimbari este



Pagina 13 din 87
perfect justificat, n foarte multe cazuri procedura de control a schimbrilor nu
este cunoscut sau nu este utilizat n cadrul proiectelor
nu sunt cunoscute toate componentele proiectului pentru care se aplic
managementul schimbrii
nu este clar definit autoritatea care ar trebui s aprobe implementarea unor
schimbri n cadrul proiectului
nu sunt cunoscute avantajele i riscurile pentru diferitele abordri n
implementarea schimbrilor pe parcursul ciclului de via a proiectului
3.2.6 Probleme identificate n managementul riscului
producerea de ntrzieri n derularea proiectului, pentru anumite activiti sau
livrabile, n urma apariiei unor probleme care nu au fost prevzute
depirea bugetului alocat pentru proiect datorit unor situaii neprevzute
crearea unor situaii tensionate n cadrul echipei de proiect comune furnizor-
beneficiar n urma manifestrii unor riscuri
realizarea unor compromisuri relativ la calitatea unor livrabile datorit apariiei
unor probleme care nu au fost prevzute
nu sunt clar definite sau nu sunt formal asumate de ctre pri responsabilitile
referitoare la managementul riscurilor
n marea majoritate a cazurilor nu este folosit, nici de ctre beneficiar i nici de
ctre furnizor, o procedur formal de realizare a managementului riscurilor
care s prezinte modalitatea practic de realizare a identificrii riscurilor, a
probabilitii de apariie i a impactului n cazul apariiei, a planificarii
activitilor de contracarare i a planurilor alternative n cazul materializrii
riscului
nu sunt stabilite responsabilitile n identificarea i controlul riscurilor pentru
persoanele cu autoritate de decizie din cadrul organizaiei beneficiarului
nu sunt identificate i disponibile modalitile concrete prin care pot fi
controlate riscurile n cadrul organizaiei beneficiare
nu sunt derulate edine de analiz comune (beneficiar i furnizor) n vederea
identificrii i evalurii riscurilor din proiect
nu sunt stabilite sau derulate planuri de aciune de ctre coordonatorul de proiect
al beneficiarului n vederea contracarrii riscurilor
nu este solicitat n cadrul caietului de sarcini prezentarea n cadrul ofertei
tehnice de ctre furnizor a unui plan concret de management al riscului pentru
principalele riscuri identificate
planul de riscuri nu este revizuit pe parcursul proiectului



Pagina 14 din 87
3.3 Concluzii
Pentru a putea evalua anvergura problemelor identificate s-a avut n vedere
determinarea frecvenei de manifestare a acestor probleme pe parcursul iniierii,
contractrii, demarrii i derulrii proiectelor. Astfel, n urma analizei informaiilor
i a consolidrii rezultatelor din chestionarele primite, s-au putut determina pentru
fiecare problem n parte frecvena de apariie i componenta de metodologie de
management de proiect creia aceasta i aparine. Componentele de metodologie au
fost ulterior grupate n trei categorii n funcie de numrul problemelor care au fost
semnalate.
Mai jos sunt prezentate componentele de management de proiect grupate pe cele trei
categorii:
Clasa 1 probleme foarte frecvente (peste 75% din proiecte):
probleme aparinnd componentei de management a riscului
probleme aparinnd componentei de organizare a proiectului
Clasa a 2-a probleme cu frecven medie (ntre 35% i 75% din proiecte):
probleme aparinnd componentei de control a proiectului
probleme aparinnd componentei de management al schimbrii
probleme aparinnd componentei de management al calitii
Clasa a 3-a probleme cu frecven redus (sub 35% din proiecte):
probleme aparinnd componentei de planificare a proiectului

Rezolvarea problemelor identificate n cadrul analizei prin utilizarea unei
metodologii de management de proiect de ctre organizaiile care furnizeaz
proiectul sau care beneficiaz de pe urma acestuia i utilizeaz produsul proiectului
reprezint un factor determinant n asigurarea succesului acestuia . Din acest motiv,
n cadrul seciunilor care urmeaz vor fi prezentate componentele generale ale unei
metodologii de management de proiect care s fie aplicate pe parcursul
implementrii proiectelor TIC din administraia public local.



Pagina 15 din 87
4. DOCUMENTE ELABORATE N VEDEREA LANSRII
PROIECTELOR
4.1 Introducere
Aceast seciune prezint paii recomandai pentru lansarea unui proiect TIC n
cadrul administraiei publice locale. Aceste etape sunt prezentate din punctul de
vedere al documentelor interne care trebuie pregtite de ctre instituia beneficiar.
4.2 Etapele demarrii proiectului
4.2.1 Etapa pregtitoare
4.2.1.1 Referatul de necesitate
Acest document este ntocmit de ctre viitorul utilizator al rezultatelor proiectului
(departamentul iniiator al proiectului). Prin acest document, utilizatorul prezint
problema aprut i fundamenteaz necesitatea i oportunitatea lansrii proiectului.
Documentul va identifica cerinele juridice sau instituionale care impun proiectul,
precum i cerinele funcionale.
Dup realizare, documentul este trimis spre aprobare efulului ierarhic superior sau
conducerii instituiei.
4.2.1.2 Nominalizarea echipei interne de proiect
Dup primirea Referatului de Necesitate, persoana care trebuie s ia decizia
demarrii sau nu a proiectului va numi o echip de proiect care s pregteasc o
Propunere de Proiect. Echipa de proiect va fi condus de un Coordonator de Proiect
i va fi compus din membrii departamentelor afectate de proiect (din postura de
utilizatori, furnizori sau suport). De asemenea, se va constitui un Comitet de
Conducere al Proiectului care va evalua Propunerea de Proiect i va decide
demararea sau nu a proiectului. Comitetul de Conducere al Proiectului va putea
aloca resurse suplimentare echipei de proiect n vederea finalizrii Propunerii de
Proiect. Structura proiectului n aceast etap este prezentat mai jos:

Figura 1: Organizarea de proiect a Beneficiarului



Pagina 16 din 87
Responsabilitatea Reprezentantului Utilizatorului (sau al Utilizatorilor) este aceea
de a identifica i detalia cerinele funcionale pentru proiect, n timp ce
Reprezentantul Beneficiarului are rolul de a analiza aceste cerine i de a aloca
resursele necesare pentru implementarea proiectului, n funcie de celelalte prioriti
ale instituiei.
4.2.1.3 Elaborarea Propunerii de Proiect
Sub conducerea Coordonatorului de Proiect, echipa de proiect va analiza toate
aspectele proiectului propus i va elabora Propunerea de Proiect, pe care o va nainta
spre aprobare Comitetului de Conducere al Proiectului. Aceast Propunere de
Proiect trebuie s nceap cu un scurt rezumat ce va reflecta i prezenta nevoile pe
care trebuie s le rezolve proiectul, modalitatea n care se vor satisface aceste nevoi
i rezultatele ateptate n urma implementrii proiectului. Propunerea de proiect
trebuie s ating urmtoarele aspecte:
natura problemei, din punct de vedere funcional i soluia tehnic pentru
rezolvarea ei;
planul de implementare al proiectului - cuprinde estimarea timpului de
desfurare a proiectului, a bugetului i a resurselor (inclusiv umane, cu
pregtire corespunztoare) care vor fi utilizate. Fiecare parte important
(etap) a proiectului va fi nsoit de bugetul aferent acesteia, indicatori de
calitate i perioada de realizare;
referate de specialitate n funcie de aria de cuprindere i de valoarea
proiectului, se vor solicita departamentelor economic, juridic, IT, patrimoniu
etc. referate privind posibilitile de finanare, implicaiile juridice,
dependenele de alte soluii existente, resursele disponibile, condiiile tehnice
IT care trebuie impuse. Din aceste referate trebuie s rezulte clar aria de
cuprindere a proiectului, dependenele, sursele de finanare, resursele umane,
logistice i tehnice implicate.
4.2.1.4 Proiect de Hotrre de Consiliu
n urma aprobrii Propunerii de Proiect, se va redacta un Proiect de Hotrre de
Consiliu care va cuprinde Propunerea de Proiect i care va avea ca anex referatele
anterioare de specialitate i expunerea de motive.
4.2.1.5 Hotrrea de Consiliu
Hotrrea de Consiliu este documentul care aprob angajarea instituiei n derularea
proiectului.
4.2.2 Etapa de achiziie
n cadrul etapei de achiziie se elaboreaz urmtoarele documente:
documentaia de elaborare i prezentare a ofertei, care va conine: caietul de
sarcini, propunerea de contract de achiziie, fia de date a achiziiei, modele
de formulare, alte anexe (poate conine i descrierea metodologiei de
management de proiect propuse vezi seciunea 5)
documentaia de evaluare a ofertelor
contractul de achiziie public



Pagina 17 din 87
dispoziie a preedintelui sau primarului de numire a structurii de
management, de coordonare i de execuie a proiectului (Comitetul de
Conducere al Proiectului, Coordonatorul de Proiect, Echipa de proiect),
mpreun cu identificarea clar a atribuiilor acestora
4.3 Modele de documente
n cazul proiectelor de anvergur, v recomandm s apelai la ajutorul unui
consultant care s realizeze un Studiu de Fezabilitate privind proiectul propus. n
acest caz, Studiul de Fezabilitate va avea structura standard a unui astfel de
document.
n cazul n care dorii s realizai singuri un astfel de Studiu, sau n cazul n care
implementarea proiectului se va realiza prin fore proprii (departamentul TIC al
autoritii locale), v recomandm utilizarea formularului din Anexa 1 pentru
concentrarea tuturor informaiilor necesare n vederea lurii unei decizii privitoare la
demararea proiectului.



Pagina 18 din 87
5. METODOLOGIA DE MANAGEMENT AL PROIECTELOR
5.1 Introducere
5.1.1 Ce este un proiect?
Un Proiect reprezint modalitatea de organizare funcional a resurselor (umane i
de alt natur) n vederea realizrii unui obiectiv bine stabilit.
Un proiect se definete ca o succesiune de procese nerepetitive n scopul realizrii
unor livrabile noi, bine definite, n cadrul unei organizaii special create pentru acest
scop, n cadrul unor constrngeri de timp, calitate i cost.
5.1.2 De ce proiectele au nevoie de management?
Indiferent de dimensiunea unui proiect sau de complexitatea acestuia, ndeplinirea
obiectivelor nseamn atingerea standardelor de calitate propuse, n limitele de timp
i de buget stabilite.
O metodologie de management de proiect pune la dispoziie o serie de componente
i procese care s ajute n procesul de planificare, monitorizare i control i care s
asigure c proiectul va fi realizat la timp, cu bugetul alocat, la nivelul de calitate
programat i cu atingerea tuturor obiectivelor propuse.
5.1.3 Arie de aplicabilitate
Metodologia de management de proiect prezentat n cadrul acestei seciuni se poate
aplica n cadrul oricrui tip de proiect TIC, fie el realizat cu ajutorul unui furnizor
fie numai cu resurse interne ale autoritii locale .
Din punctul de vedere al dimensiunii sau complexitii proiectelor n care aceast
metodologie se poate aplica, nu exist restricii generale. Indiferent de
considerentele de complexitate sau dimensiune, utilizarea unei abordri
metodologice crete ansele de succes ale proiectelor. Din acest motiv, singura
variabil n cazul folosirii unei metodologii este nivelul de detaliere i de
complexitate necesar deciziile n aceast direcie aparin Manager-ului de Proiect.
Metodologia de Management de Proiect are menirea de a ajuta Manager-ul de
Proiect n derularea proiectului i nu de a crea o povar administrativ asupra
acestuia i a echipei de proiect. Din acest motiv, este esenial ca procedurile i
cantitatea de documente administrative folosite n cadrul proiectului s fie justificate
de anvergura acestuia. Metodologia nu este un scop n sine; obiectivul nu este
aplicarea metodologiei, ci finalizarea cu succes a proiectului, iar metodologia este
doar o unealt n atingerea acestui obiectiv. Urmtorul tabel prezint o recomandare
n ceea ce privete gradul de detaliere a diferitelor componente ale metodologiei de
management de proiect n funcie de dimensiunea proiectului. Modalitatea de
determinare a dimensiunii proiectului este prezentat n Anexa 2:
Componenta metodologiei / Dimensiunea
proiectului
MIC MEDIU MARE
Organizarea proiectului Sumar Detaliat Detaliat
Planificare Sumar Detaliat Detaliat
Managementul riscurilor Sumar Sumar Detaliat
Managementul calitii Sumar Detaliat Detaliat



Pagina 19 din 87
Controlul proiectului Sumar Detaliat Detaliat
Managementul configuraiilor Sumar Sumar Detaliat
Managementul schimbrii Detaliat Detaliat Detaliat
ntruct majoritatea proiectelor TIC de anvergur din cadrul administraiei publice
locale sunt realizate cu ajutorul furnizorilor , iar conducerea i organizarea
proiectului sunt de obicei activiti n sarcina furnizorului, toate formulrile din
cadrul acestei seciuni a Ghidului sunt fcute n contextul unui furnizor . Cu toate
acestea, dup cum am precizat la nceputul acestei sub-seciuni, metodologia
prezentat se poate aplica i n cazul n care furnizorul este chiar Departamentul TIC
din cadrul autoritii locale .
5.1.4 Alte precizri
Seciunea 5 cuprinde noiuni de baz privind modul n care trebuie realizat
managementul de proiect pe ntreaga durat a desfurrii proiectului. Chiar dac
anumite sarcini de management de proiect vor fi ndeplinite i de ctre Beneficiar
prin intermediul unui Coordonator de Proiect numit de ctre acesta (din cadrul
organizaiei Beneficiarului sau angajat pe baza unui contract de consultan), acest
Ghid pleac de la ipoteza c responsabilitatea principal pentru furnizarea tuturor
serviciilor de management de proiect revine Furnizorului. Din aceast perspectiv,
n afara cazului n care se indic explicit altfel, orice referire (din cadrul acestui
Ghid) la Managerul de Proiect i la ndatoririle acestuia precum i la organizarea i
coordonarea activitilor de management al proiectului vor fi nelese ca fiind n
sarcina Furnizorului.
Att Furnizorul ct i Beneficiarul pot opta pentru folosirea acestei metodologii sau
a unei alte metodologii similare.
n situaia achiziiilor publice recomandm ca Ofertantului s i se cear prin Caietul
de Sarcini s prezinte detaliat n oferta sa modalitatea practic n care va implementa
n cadrul proiectului metodologia propus , n conformitate cu cerinele specifice
prezentate n seciunea 6. n acest sens, recomandm s nu se accepte n cadrul
ofertelor referirea la un standard de metodologie fr prezentarea detaliat a
modalitii n care se vor trata aspectele prezentate n aceast seciune.
5.1.5 Organizarea acestei seciuni
Aceast seciune prezint succesiv componentele principale ale unei metodologii de
management de proiect, precum i metodele prin care aceste componente se
regsesc n cadrul unui proiect. Astfel, aceast seciune a Ghidului trateaz
urmtoarele aspecte legate de managementul de proiect:
Organizarea proiectului
Planificarea proiectului
Controlul proiectului
Management-ul riscurilor
Calitatea
Management-ul configuraiilor
Management-ul schimbrilor



Pagina 20 din 87
5.2 Noiuni de baz privind managementul de proiect
5.2.1 Organizarea proiectului
Organizarea proiectului are la baz cteva roluri fundamentale, care sunt definite n
cele ce urmeaz:
Clientul este cel care definete rezultatul ateptat, care va folosi rezultatul
final i care va plti proiectul. n cadrul acestui rol, exist dou sub-roluri
importante: Beneficiarul i Utilizatorul. n cadrul acestui Ghid, prin
Beneficiar se nelege persoana sau departamentul care finaneaz proiectul,
n timp ce prin Utilizator se nelege persoana sau departamentul care va
utiliza n mod efectiv rezultatele proiectului. n cele mai multe situaii,
rolurile Beneficiarului i al Utilizatorului sunt diferite;
Furnizorul este cel care va furniza resursele umane i expertiza necesar
pentru obinerea rezultatului final dorit.

Stabilirea unei structuri organizaionale eficiente a proiectului este un factor
fundamental n vederea unui proiect de succes, deoarece proiectul are nevoie de
conducere, control i comunicare. Din acest motiv, structura de proiect este diferit
de structura normal de subordonare ierarhic din cadrul instituiei i include arii de
competen multidisciplinare, mai ales dac proiectul se adreseaz unui grup de
utilizatori care nu fac parte din aceeai sub-diviziune organizaional (departament).
Din acest punct de vedere, Manager-ul de Proiect (din partea organizaiei
Furnizorului) i Coordonatorul de Proiect (din partea organizaiei Clientului) trebuie
s aib autoritatea de a decide asupra modului n care toate resursele (umane i alt
fel) ale proiectului sunt folosite (att cele alocate n ntregime proiectului ct i cele
care sunt alocate proiectului pe o perioad limitat de timp).
Structura de conducere a proiectului trebuie s cuprind roluri i responsabiliti
care s reuneasc toate interesele existente i expertiza necesar proiectului.

n cele ce urmeaz, prin Structura organizaionala a proiectului se va nelege
structura comun a proiectului, incluznd att rolurile Clientului (Beneficiar i
Utilizator) ct i pe cele ale Furnizorului.
Structura organizaional a proiectului cuprinde att rolurile care au ca obiectiv
coordonarea proiectului, ct i pe cele care vor realiza efectiv livrabilele proiectului,
fiind mprit n 4 nivele responsabile cu:
stabilirea liniilor directoare ale proiectului
management-ul de zi cu zi al activitilor proiectului
management-ul echipei de proiect
realizarea livrabilelor proiectului - membrii echipei de proiect



Pagina 21 din 87

Figura 2: Organizarea proiectului

Primele trei nivele de organizare constituie Echipa de Management a proiectului.
Este esenial ca aceast echip s fie complet definit astfel nct s includ:
roluri de luare a deciziilor
management-ul excepiilor pentru rolurile de decizie
management-ul de proiect (full time sau part time)
delegarea controlat a unor sarcini de management de zi cu zi, acolo unde
este cazul, ctre efii de Echip
roluri pentru evaluarea independent a tuturor aspectelor de performan ale
proiectului
suport administrativ pentru Project Manager i efii de Echip
cunoaterea rolurilor i a atribuiilor acestora din cadrul proiectului de ctre
toi cei implicai
linii de comunicare ntre membrii Echipei de Management a proiectului.
5.2.1.1 Comitetul de Conducere al Proiectului
Comitetul de Conducere al Proiectului reprezint nivelele de conducere din cadrul
structurilor organizaionale angrenate n proiect: Beneficiarul, Utilizatorii i
Reprezentant
Utilizator
Reprezentant
Beneficiar
Reprezentant
Furnizor
Manager Proiect
Comitetul de Conducere al Proiectului
Sef Echipa

Sef Echipa

Rol 2

Rol 3

Rol 1

Rol 2

Rol 3

Rol 1

Asigurarea
Controlului
Proiectului

Echipa de Suport
a Proiectului

Coordonator
Proiect

Rol 1

Rol 3

Rol 2

Rol 4



Pagina 22 din 87
Furnizorul. Reprezentanii acestor structuri trebuie s aib nivelul necesar de
autoritate n cadrul structurilor pe care le conduc pentru a putea lua decizii i pentru
a putea controla alocarea de resurse materiale i financiare.
Nivelul de reprezentare n cadrul Comitetului de Conducere al Proiectului al celor
trei structuri menionate trebuie s in cont de importana i dimensiunea
proiectului, avnd n vedere c participarea n cadrul structurii de conducere a
proiectului este o sarcin suplimentar activitilor curente i n consecin nu
trebuie s afecteze foarte mult activitile curente ale celor implicai. Din acest
motiv, pe lng implicarea periodic necesar informrii asupra desfurrii
activitilor planificate ale proiectului, Comitetul de Conducere al Proiectului i va
realiza mandatul prin activiti de management al excepiilor, adic se va implica n
derularea proiectului numai atunci cnd planul de proiect aprobat nu mai poate fi
respectat i cnd este necesar luarea unor decizii strategice privind continuarea
proiectului.
Comitetul de Conducere al Proiectului:
aprob toate planurile importante ale proiectului i autorizeaz orice deviaie
major de la Planurile de Etap aprobate, conform limitelor de competen;
confirm oficial finalizarea fiecrei etape a proiectului i autorizeaz
demararea unei noi etape;
se asigur c nivelul necesar de resurse este alocat proiectului i arbitreaz
conflictele n interiorul proiectului;
asigur interfaa ntre proiect i mediul organizaional extern i gsete
soluii de rezolvare a eventualelor conflicte (de interese, de resurse, de
prioriti) ntre proiect i mediul exterior;
aprob oficial numirea Managerului de Proiect (din partea Furnizorului)
precum i responsabilitile i limitele de autoritate ale acestuia. De
asemenea, aprob oficial numirea Coordonatorului de Proiect din partea
Beneficiarului.

Comitetul de Conducere al Proiectului poate folosi resurse externe echipei de
proiect pentru a se asigura c proiectul i urmeaz cursul normal i c i va atinge
obiectivele propuse. Aceste resurse externe sunt organizate sub forma unei structuri
de Asigurare a Controlului Proiectului i cuprind expertiz n domenii precum:
management
asigurarea calitii
audit
expertiz tehnic specific ariilor de proiect
Cu toate c face parte din echipa de proiect, Coordonatorul de Proiect al
Beneficiarului ndeplinete i un astfel de rol de control din partea Comitetului de
Conducere al Proiectului, n sensul c ofer un punct de vedere separat de cel al
Managerului de Proiect privitor la modul n care se deruleaz proiectul.
5.2.1.1.1 Reprezentantul Beneficiarului
Reprezentantul Beneficiarului este n final responsabil de rezultatele proiectului,
avnd sprijinul Reprezentanilor Utilizatorilor i al Furnizorului. El trebuie s se



Pagina 23 din 87
asigure c proiectul va furniza avantajele economice scontate, la nivelul investiiei
fcute i c obiectivele iniiale ale proiectului se pstreaz pe durata derulrii
acestuia. n ndeplinirea acestor sarcini, Reprezentantul Beneficiarului trebuie s
poat realiza o balan just ntre interesele organizaiei, ale utilizatorilor i ale
furnizorului. Persoana desemnat pentru acest rol realizeaz i legtura cu structurile
superioare de management ale organizaiei, oferind vizibilitate proiectului la nivel
nalt.
Reprezentantul Beneficiarului trebuie s aib o poziie important n cadrul
instituiei, deoarece trebuie s poat controla bugetul i resursele alocate proiectului.
Prin poziia sa, acest rol trebuie s poat impune deciziile sale att Reprezentantului
Utilizatorilor ct i restului organizaiei sale.
5.2.1.1.2 Reprezentantul Utilizatorilor
Reprezentantul Utilizatorilor rspunde pentru producerea tuturor livrabilelor
furnizate de ctre utilizatori, cum ar fi asigurarea c cerinele funcionale au fost
definite corect i complet, c ceea ce va fi produs va fi util i va realiza beneficiile
ateptate. De asemenea, va monitoriza faptul c soluia dezvoltat va rspunde
cerinelor utilizatorilor n limita constrngerilor documentului de justificare
economic a proiectului.
Acest rol reprezint interesele tuturor celor care vor utiliza rezultatele finale ale
proiectului, ale celor care vor utiliza rezultatele proiectului n vederea atingerii unor
obiective, ale ceror care vor realiza beneficii suplimentare utiliznd rezultatele
proiectului, precum i ale tuturor celor care vor fi afectai de rezultatele proiectului.
Reprezentantul Utilizatorilor este responsabil pentru:
furnizarea resurselor necesare (din punct de vedere al utilizatorilor)
asigurarea faptului c proiectul produce rezultate care rspund cerinelor
utilizatorilor
asigurarea faptului c rezultatele proiectului ofer beneficiile ateptate de
ctre utilizatori
n cazul n care utilizatorii acoper mai multe departamente funcionale din cadrul
organizaiei, ceea ce ar necesita un numr mai mare de Reprezentani ai
Utilizatorilor n cadrul Comitetului de Conducere al Proiectului, atunci acest rol
poate fi realizat de mai multe persoane. Dac se consider c acest lucru ar fi
contraproductiv, atunci reprezentanii utilizatorilor pot organiza un comitet n care
problemele s se discute i s numeasc apoi un reprezentant care s susin punctul
de vedere comun n cadrul Comitetului de Conducere al Proiectului.
5.2.1.1.3 Reprezentantul Furnizorului
Rolul Reprezentantului Furnizorului este acela de a asigura realizarea rezultatelor
solicitate de Reprezentantul Utilizatorilor. Reprezentantul Furnizorului este
responsabil pentru calitatea tuturor livrabilelor livrate de ctre furnizor(i). Ca parte a
acestei responsabiliti, el trebuie s se asigure c propunerile privind proiectarea i
dezvoltarea produselor sunt realiste, adic ele vor atinge obiectivele solicitate de
ctre Reprezentantul Utilizatorilor n cadrul constrngerilor de timp i de buget
fixate de ctre Reprezentantul Beneficiarului. Acest rol reprezint interesele tuturor
celor care proiecteaz, dezvolt, procur i implementeaz produsele furnizate i



Pagina 24 din 87
trebuie s aib nivelul de autoritate necesar pentru a implica sau a obine resursele
necesare din partea Furnizorului.
5.2.1.2 Managerul de Proiect (al Furnizorului)
Managerul de Proiect are autoritatea din partea Comitetului de Conducere al
Proiectului de a conduce activitile de proiect de zi cu zi, n cadrul limitelor de
responsabilitate stabilite de ctre Comitetul de Conducere al Proiectului.
Responsabilitatea principal a Managerului de Proiect este de a se asigura c
proiectul produce toate livrabilele necesare, n cadrul constrngerilor de timp i de
buget i la standardele de calitate stabilite. Rolul Managerului de Proiect nu este
acela de a fi antrenat n cadrul activitilor zilnice de proiect, ci acela de a delega
sarcinile i responsabilitile din cadrul proiectului astfel nct obiectivele acestuia
s fie atinse, pstrnd ns o viziune de ansamblu asupra strategiei proiectului i a
evoluiei acestuia i alocnd timp sarcinilor de planificare, monitorizare i control.
5.2.1.3 Coordonatorul de Proiect (al Beneficiarului)
Chiar dac Managerul de Proiect din partea Furnizorului are responsabilitatea
principal pentru coordonarea proiectului, el nu poate controla resursele organizaiei
Beneficiarului. Din acest motiv este necesar un rol suplimentar cel al
Coordonatorului de Proiect din partea Clientului. Rolul acestei persoane este aceea
de a organiza resursele Clientului (Beneficiar i Utilizatori) astfel nct acestea s
fie utile proiectului i s fie disponibile conform necesitior planului de proiect.
Coordonatorul de Proiect asigur interfaa oficial de comunicare a problemelor de
zi cu zi ntre Managerul de Proiect i organizaia Clientului. Este important de
precizat faptul c relaia ntre Managerul de Proiect al Furnizorului i Coordonatorul
de Proiect al Beneficiarului nu este una de subordonare, ci una de colaborare.
Singura linie de raportare oficial a Managerului de Proiect este ctre Comitetul de
Conducere al Proiectului.
5.2.1.4 ef de Echip
Utilizarea acestui rol nu este obligatorie, folosirea sa depinznd de anvergura
proiectului i de organizarea pe care Furnizorul o va propune. De asemenea, n cazul
n care dimensiunea echipei de proiect i specializarea resurselor o impun, folosirea
acestui rol intermediar ntre Project Manager i membrii echipei de proiect este
recomandat n vederea uurrii comunicrii i a controlului. n cazul n care
Furnizorul va recomanda formarea unei echipe n oglind din partea
Beneficiarului, folosirea acestui rol intermediar va uura comunicarea ntre pri i
va minimiza punctele de contact oficial ntre echipe.
Responsabilitatea principal a unui ef de Echip este aceea de a asigura realizarea
unor livrabile n condiiile stabilite de ctre Project Manager, cruia i raporteaz.
De asemenea, un ef de Echip poate coordona realizarea unei ntregi etape de
proiect. Organigrama de proiect va identifica utilizarea efilor de Echip iar planul
de Proiect va descrie exact limitele atribuiilor i a responsabilitii acestora.
5.2.1.5 Asigurarea Controlului Proiectului
Pentru a realiza coordonarea proiectului i pentru a avea n permanen o privire
obiectiv asupra evoluiei proiectului, exist situaii n care Comitetul de Conducere
al Proiectului are nevoie de o prere obiectiv din partea unei entiti care nu este
implicat n activitatea de zi cu zi a proiectului. Aceast entitate independent este



Pagina 25 din 87
Echipa de Asigurare a Controlului Proiectului. Necesitatea unei astfel de structuri
vine pe de o parte din nevoia unei informri independente iar pe de alt parte din
limitarea timpului pe care membrii Comitetului de Conducere al Proiectului l pot
aloca investigrii acestor aspecte. Din aceste motive, membrii Comitetului de
Conducere al Proiectului pot delega aceste sarcini de monitorizare a calitii
activitilor proiectului unor persoane independente de echipa de proiect (individual
sau unitar). Sarcinile de monitorizare ale Echipei de Asigurare a Controlului
Proiectului pot acoperi urmtoarele zone ale proiectului:
integritatea justificrii economice a proiectului pe ntreaga durat a derulrii
sale
respectarea standardelor i a procedurilor stabilite i aprobate de ctre
Comitetul de Conducere al Proiectului
respectarea standardelor de calitate
atingerea obiectivelor Utilizatorilor proiectului
monitorizarea riscurilor
pstrarea obiectivelor iniiale ale proiectului i evitarea deviaiilor de la
aceste obiective
ntruct fiecare membru al Comitetului de Conducere al Proiectului urmrete
anumite obiective, fiecare dintre aceti membrii poate delega independent sarcina
monitorizrii respectrii acestor obiective. Este fundamental ns ca aceste roluri de
monitorizare s fie independente de personalul echipei de proiect, pentru evitarea
conflictelor de interese. Membrii Echipei de Asigurare a Controlului Proiectului pot
fi fie angajai din cadrul organizaiei Beneficiarului, a Utilizatorului sau a
Furnizorului, care nu sunt implicai n activitile de zi cu zi ale proiectului, fie
consultani independeni externi celor dou organizaii , contractai de ctre fiecare
din rolurile care formeaz Comitetul de Conducere al Proiectului.
O parte din rolurile Echipei de Asigurare a Controlului Proiectului pot fi realizate de
ctre Coordonatorul de Proiect al Beneficiarului. Chiar dac opinia acestuia nu este
obiectiv datorit implicrii efective n viaa de zi cu zi a proiectului, el poate oferi o
viziune alternativ asupra evoluiei proiectului fa de cea oferit de Managerul de
Proiect din partea Furnizorului.
5.2.1.6 Asigurarea Suportului Proiectului
Pe lng sarcinile de management i tehnice, un proiect are nevoie de asisten
administrativ. Aceasta se poate datora anvergurii proiectului i volumului de
sarcini administrative care trebuie realizate, sau necesitii utilizrii unor
instrumente specifice de planificare sau de control (inclusiv financiar sau de
management al configuraiilor) n utilizarea crora Project Manager-ul nu are
suficient experien.
Dac dimensiunea proiectului i numrul de livrabile necesit un control atent al
configuraiilor, atunci instrumente software pentru controlul configuraiei
produselor trebuie utilizate. Aceast sarcin administrativ poate ocupa mult timp i
n acest caz se recomand folosirea unui Birou de Proiect care s aib i aceast
sarcin. De asemenea, acest Birou de Proiect trebuie s asigure i alte funcii de
suport, cum ar fi meninerea tuturor documentelor de proiect (att n form
electronic cu istoricul versiunilor ct i n form tiprit pentru versiunile aprobate)
i furnizarea serviciilor de Registratur pentru toat corespondena de proiect.



Pagina 26 din 87
5.2.1.7 Funcionarea Comitetului de Conducere al Proiectului
Avnd n vedere timpul limitat pe care membrii Comitetului de Conducere al
Proiectului l pot aloca sarcinilor referitoare la asigurarea direciei proiectului, cea
mai mare parte a sarcinilor acestei structuri se realizeaz n mod informal, fr
necesitatea ntrunirii ntr-un cadru oficial. Comitetul de Conducere al Proiectului
este informat n mod regulat de ctre Managerul de Proiect asupra evoluiei
proiectului prin intermediul Rapoartelor pregtite de ctre acesta. Comitetul de
Conducere al Proiectului se ntrunete numai atunci cnd proiectul deviaz de la
planul aprobat, iar Managerul de Proiect pregtete un Raport de Excepie i un Plan
de Excepie pe care l supune aprobrii Comitetului de Conducere al Proiectului.
Cu toate c rolurile din cadrul Comitetului de Conducere al Proiectului sunt
concepute pentru a acoperi toate interesele celor implicai n proiect i pentru a
ncuraja consultarea ntre acetia n scopul lurii celor mai bune decizii privind
proiectul, funcionarea Comitetului de Conducere al Proiectului nu este neaprat una
democratic, n sensul c deciziile nu se iau prin vot. Rolul decizional este cel al
Reprezentantului Beneficiarului, care ns se consult cu Reprezentanii
Utilizatorilor i cu cel al Furnizorului nainte de a lua aceast decizie. Indiferent de
decizia Comitetului de Conducere al Proiectului, dac aceast decizie are implicaii
contractuale atunci ea nu poate fi pus n practic nainte de a se concretiza ntr-un
amendament la Contract.
5.2.2 Planificarea proiectului
Un plan este un document, structurat n conformitate cu o schem sau metod
predefinit, care descrie cum, cnd i de ctre cine va fi realizat un anumit obiectiv
(sau set de obiective) specific(e). Un plan arat cum se vor realiza anumite obiective
din punct de vedere al duratei de realizare, al costurilor i al calitii livrabilelor.
5.2.2.1 Componentele unui plan
n nelesul acestui document, un plan nu este o reprezentare grafic a activitilor
proiectului i a duratei acestora. Aceast reprezentare grafic a calendarului de
proiect este numai o component a unui plan, acesta trebuind s conin informaii
privind:
livrabilele care trebuie produse
activitile necesare n vederea realizrii acestor livrabile
activitile necesare n vederea validrii calitii acestor livrabile
resursele i timpul necesar pentru realizarea activitilor (inclusiv a
activitilor de control al calitii), precum i identificarea resurselor
specializate necesare
legturile i dependenele ntre activiti
eventuale dependene externe privind furnizarea unor informaii, produse sau
servicii
momentele de timp cnd se vor desfura diferitele activiti
punctele de control cnd se va realiza monitorizarea progresului



Pagina 27 din 87
Pe lng seciunile de prezentare i pe lng schemele logice sau grafice, un plan
trebuie s conin obligatoriu informaii narative referitoare la:
subiectul planului (de exemplu livrarea unor anumite produse)
abordarea aleas n vederea implementrii planului
modalitatea n care va fi monitorizat i controlat respectarea planului
care sunt rapoartele pentru management care vor fi produse pe durata
implementrii planului, pentru raportarea progresului
metodele folosite pentru controlul calitii i resursele care vor fi folosite n
acest sens
ipotezele pe care se bazeaz planul
orice condiie prealabil care trebuie satisfcut pentru ca planul s poat
demara
riscurile existente care pot mpiedica realizarea planului, precum i msurile
care trebuie luate pentru a gestiona aceste riscuri.
5.2.2.2 Nivelul de planificare
Avnd n vedere necesitatea planificrii activitilor i a resurselor, dar n acelai
timp innd cont i de acurateea redus a estimrilor cu ct acestea se refer la
activiti care se vor desfura ntr-un viitor mai ndeprtat, este important ca efortul
de planificare s fie bine ponderat pe ntreaga durat a desfurrii proiectului i la
nivelele ierarhice la care detaliile de planificare sunt necesare.
Chiar dac uneori este imposibil ca ntregul proiect s fie planificat n detaliu nc
din start, este important s existe un plan general asupra derulrii ntregului proiect,
plan care s fie aprobat de ctre Comitetul de Conducere al Proiectului i pe baza
cruia proiectul s poat fi controlat. Pe baza acestui plan general se vor realiza apoi
planuri secundare, pe perioade mai scurte de timp, pentru obiective concrete i la un
nivel mult mai detaliat.

Plan de Proiect
Plan de Etap
Plan de Lucru al
Echipei
Plan de Excepie

Figura 3: Nivelurile de planificare ntr-un proiect



Pagina 28 din 87
Pentru reflectarea nevoilor de planificare ale diferitelor nivele de management
implicate n proiect, se propun dou nivele principale de planificare: Planul de
Proiect i Planul de Etap. n cazul proiectelor n care o etap se poate sparge n
activiti realizate de echipe distincte, atunci pot fi realizate i planuri de nivel
inferior celor de etap (Planuri de Lucru ale Echipei) care vor fi folosite de ctre
sub-echipele de proiect pentru derularea activitilor zilnice.
Principiul de baz care trebuie luat n considerare este acela c planurile de nivel
mai jos acoper un orizont de timp mai restrns i conin mai multe detalii dect cele
de nivel mai nalt. n funcie de strategia aleas, Furnizorul va alege nivelul de
detaliu la care va realiza procesul de planificare a proiectului.
n momentul n care se estimeaz c un Plan de Etap i va depi toleranele
stabilite i aprobate de ctre Comitetul de Conducere al Proiectului nainte de
momentul demarrii etapei, Managerul de Proiect va realiza i va nainta spre
aprobare Comitetului de Conducere al Proiectului un plan alternativ (Planul de
Excepie) care, dup aprobare, va nlocui planul de Etap sau va putea declana
revizuirea ntregului Plan de Proiect.
5.2.2.2.1 Planul de Proiect
Planul de Proiect ofer o privire de ansamblu asupra ntregului proiect i face parte
din Documentele de Iniializare ale Proiectului. Realizarea unui astfel de Plan de
Proiect este obligatorie, ntruct constituie o referin fa de care va fi controlat
ntreaga evoluie ulterioar a proiectului, n cadrul fiecrei etape. Planul de Proiect
identific livrabilele principale, necesarul de resurse i totalitatea costurilor. De
asemenea, identific punctele principale de control n cadrul proiectului, cum ar fi
limitele de etape.
Dup acceptarea Documentelor de Iniializare a Proiectului, Planul de Proiect iniial
devine o referin contractual i constituie planul original pe baza cruia a fost
aprobat proiectul. Pe msur ce proiectul evolueaz, versiuni ulterioare ale planului
sunt elaborate la finalul fiecrei etape i ele reflect:
progresul deja nregistrat
orice schimbare aprobat fa de versiunea anterioar a planului
orice modificare a previziunilor anterioare referitoare la costurile sau durata
total a proiectului.

Versiunile iniial i curent ale Planului de Proiect sunt folosite de ctre Comitetul
de Conducere al Proiectului n vederea monitorizrii deviaiilor de la constrngerile
iniiale de timp, buget sau arie de acoperire.
Dac devine evident faptul c Planul de Proiect va depi toleranele stabilite de
ctre Comitetul de Conducere al Proiectului, atunci aceste deviaii vor trebui
semnalate Comitetului de Control al Proiectului, care va trebui s ia o hotrre n
acest sens. n aceste situaii, cererea de aprobare va fi nsoit de un Plan de
Excepie. Planul de Excepie are aceeai compoziie cu Planul de Proiect, ns este
un plan alternativ acestuia care ia n considerare deviaiile aprute i propune
modaliti pentru gestionarea acestor deviaii.



Pagina 29 din 87
5.2.2.2.2 Planul de Etap
Pentru fiecare etap identificat n Planul de Proiect este necesar un Plan de Etap.
Planul de Etap se realizeaz nainte de finalizarea etapei creia i se adreseaz i
este aprobat de ctre Comitetul de Conducere al Proiectului, care cu aceast ocazie
autorizeaz i demararea noii etape. Planul de etap va constitui baza controlului
exercitat de ctre Managerul de Proiect pe durata etapei respective.
Planul de Etap este similar n coninut Planului de Proiect, diferena fiind faptul c
fiecare element va fi descris la un nivel de detaliu suficient pentru a permite
controlul de zi cu zi al Managerului de Proiect. Validitatea presupunerilor fcute n
cadrul Planului de Proiect precum i riscurile identificate anterior vor fi revzute
pentru etapa respectiv, ntruct este posibil ca circumstanele proiectului s se fi
modificat ntre timp i noi riscuri s fi aprut, care s fie relevante pentru etapa
respectiv.
Planul de Etap trebuie s conin i o detaliere a Planului de Calitate care s
identifice metodele care vor fi utilizate pentru verificarea calitii fiecrui livrabil,
precum i resursele necesare pentru realizarea acestor verificri. Activitile legate
de asigurarea calitii i de verificrile de calitate trebuie s fie explicit identificate
n calendarul etapei respective (diagrama Gantt).
5.2.2.2.3 Planul de Excepie
Planul de Excepie este produs de ctre Managerul de Proiect n momentul n care
este previzibil faptul c un plan aprobat de ctre Comitetul de Conducere al
Proiectului nu mai poate fi finalizat n cadrul limitelor de toleran (timp, cost)
aprobate iniial. Planul de Excepie trebuie s aib acelai nivel de detaliu ca i
planul pe care l nlocuiete, prelund stadiul curent al etapei i prezentnd
modalitatea n care etapa va fi finalizat. Planul de Excepie nlocuiete de obicei un
Plan de Etap. Dac deviaiile din cadrul etapei sunt att de mari nct se afecteaz
ntreg Planul de Proiect, atunci Planul de Excepie poate nlocui ntregul Plan de
Proiect.
Planul de Excepie are acelai format cu planul pe care l nlocuiete, dar trebuie s
conin i informaii descriptive referitor la:
motivaia necesitii Planului de Excepie
impactul Planului de Excepie asupra ntregului Plan de Proiect (n cazul n
care Planul de Excepie nlocuiete un plan de Etap sau un alt plan de nivel
mai jos), asupra justificrii economice a proiectului i asupra riscurilor
proiectului
Planul de Excepie este prezentat spre aprobare Comitetului de Conducere al
Proiectului, mpreun cu un Raport de Excepie n care sunt descrise implicaiile
Planului de Excepie, conform descrierii de mai sus.
5.2.2.2.4 Planul de Lucru al Echipei
Folosirea acestui tip de planuri este opional i este la latitudinea Managerului de
Proiect, care va lua decizia folosirii lor n funcie de anvergura etapei respective i a
modului n care planific organizarea etapei. n principiu, un Plan de Lucru descrie
n detaliu modalitatea n care va fi obinut un anumit livrabil care face parte dintr-un
Plan de Etap. n cazul n care sunt folosite, Planurile de Lucru ale Echipelor vor fi
realizate n paralel cu Planul Etapei, pe care l vor detalia.



Pagina 30 din 87
5.2.2.3 Etapele planificrii
Calendarul de proiect elaborat de ctre Furnizor trebuie s identifice n mod clar
activitile legate de procesul de planificare. Planul de Proiect trebuie s prevad n
mod obligatoriu o Etap de Iniializare n cadrul creia se vor finaliza Documentele
de Iniializare ale Proiectului. Aceste documente vor identifica activitile de
management, resursele, livrabilele, activitile, aspectele legate de calitate i de
control. n funcie de dimensiunea proiectului, Etapa de Iniializare poate varia ca
durat i poate fi finalizat n mod oficial sau informal.
Pe lng Etapa de Iniializare, Planul de Proiect trebuie s prevad timp i resurse
pentru planificarea n detaliu a fiecrei etape a proiectului (nainte de finalizarea
etapei precedente).



Pagina 31 din 87
5.2.3 Controlul proiectului
Plecnd de la ideea c orice activitate din cadrul proiectului este planificat, apoi
monitorizat i apoi supus controlului, activitile de control au ca obiectiv
garantarea faptului c, la orice nivel al echipei de management, nivelul superior de
management poate:
monitoriza progresul
compara realizrile cu planificarea
identifica probleme
iniia msuri corective
autoriza activiti suplimentare
5.2.3.1 Mijloace de Control
La nivelul Comitetului de Conducere al Proiectului, controlul se va realiza prin
excepie. Dac Comitetul de Conducere al Proiectului a aprobat un Plan de Etap,
atunci Managerul de Proiect va raporta periodic progresul, fr a fi ns nevoie de
edine de evaluare a progresului. Managerul de Proiect are controlul activitilor de
zi cu zi ale proiectului n cadrul unei etape, n limitele de toleran aprobate. Numai
n momentul n care Managerul de Proiect consider c Planul de Etap nu mai
poate fi realizat n limitele de toleran care au fost aprobate de ctre Comitetul de
Conducere al Proiectului odat cu Planul de Etap, atunci el va realiza un Plan de
Excepie pe care l va nainta Comitetului de Conducere al Proiectului, mpreun cu
un Raport de Excepie.
Mijloacele principale de control la dispoziia Comitetului de Conducere al
Proiectului sunt:
Iniializarea Proiectului (Aprobarea documentelor de iniializare ale
proiectului, inclusiv a Planului de Proiect)
Verificarea de Sfrit de Etap (A fost ncheiat cu succes etapa precedent?
Proiectul se desfoar n continuare conform Planului de Proiect?
Justificarea economic a proiectului este nc viabil? Riscurile sunt sub
control? Se poate trece la o nou etap?)
Rapoarte de Stare (Rapoarte regulate pe parcursul unei etape)
Rapoarte de Excepie (ntiinarea n avans asupra previziunilor de deviere
de la limitele de toleran aprobate)
Verificare Intermediar de Etap (Comitetul de Conducere al Proiectului
analizeaz i hotrte ce poziie s adopte ca rspuns la un Raport de
Excepie)
nchiderea Proiectului (Proiectul a livrat tot ceea ce trebuia? Este nevoie de
activiti suplimentare? Care sunt concluziile n urma derulrii proiectului?)
5.2.3.2 Iniializarea Proiectului
Scopul etapei de Iniializare a Proiectului este aceea de a stabili toate detaliile
proiectului, nainte de a autoriza demararea acestuia :
obiectivele proiectului



Pagina 32 din 87
justificarea proiectului
identificarea Beneficiarului
cine are responsabilitatea i autoritatea n cadrul proiectului
limitele proiectului i interfeele proiectului cu exteriorul
modalitatea de atingere a obiectivelor
care sunt presupunerile care au fost fcute
care sunt riscurile existente care pot mpiedica atingerea obiectivelor
proiectului
cnd vor fi livrate principalele livrabile ale proiectului
ct va costa proiectul
cum se va realiza controlul proiectului
mprirea proiectului n etape
cum va fi fcut verificarea acceptabilitii livrabilelor proiectului

Toate aceste aspecte trebuie tratate n cadrul Documentului de Iniializare al
Proiectului, care este principalul livrabil al acestei etape.
Un alt livrabil important al etapei de iniializare este Planul de Etap al etapei
urmtoare celei de Iniializare, astfel nct dac Comitetul de Conducere al
Proiectului aprob Etapa de Iniializare, s se poat demara imediat prima etap a
proiectului.
Avnd n vedere faptul c la sfritul fiecrei etape Comitetul de Conducere al
Proiectului analizeaz rezultatele etapei i hotrte demararea unei noi etape,
fixarea numrului de etape i al componenei acestora este un important mijloc de
control al Comitetului de Conducere al Proiectului. Stabilirea etapelor are loc n
cadrul Etapei de Iniializare a proiectului.
5.2.3.3 Controlul progresului proiectului
Pe parcursul derulrii proiectului trebuie n permanen meninut controlul asupra
progresului. Cteva instrumente n acest sens sunt prezentate n cele ce urmeaz:
5.2.3.3.1 Tolerane
innd cont de faptul c nici un proiect nu se desfoar conform planificrii
iniiale, trebuie gsit o balan ntre un control prea strns care s oblige Managerul
de Proiect s raporteze n permanen Comitetului de Conducere al Proiectului orice
deviaie minor de la planul aprobat i un control prea mic, ceea ce ar putea nsemna
c Managerul de Proiect poate lua decizii importante privind deviaiile de la plan,
fr s fie necesar s se consulte cu Comitetul de Conducere al Proiectului. Pentru
stabilirea unei linii de demarcaie ntre cele dou situaii se folosete conceptul de
Toleran.
Cele dou elemente de baz ale Toleranei sunt:
timpul
costul



Pagina 33 din 87
Tolerana este deviaia permis de la Planul de Proiect sau de la Planul de Etap care
poate fi acceptat fr a fi necesar informarea Comitetului de Conducere al
Proiectului. Toleranele se stabilesc separat pentru durat i pentru cost i pot fi
diferite n cazul depirii sau al unei economii (plus 5% i minus 20% fa de 10%,
de exemplu).
Dac se previzioneaz depirea unei tolerane stabilite pentru o etap, Comitetul de
Conducere al Proiectului poate stabili noi tolerane pentru Etapa respectiv, atta
timp ct acestea se pstreaz n limitele toleranelor stabilite pentru ntregul proiect.
Dac se previzioneaz c toleranele ntregului proiect vor fi depite, atunci
Comitetul de Conducere al Proiectului trebuie s hotrasc modalitatea de
continuare a proiectului, n consultare cu conducerea instituiei Beneficiarului.

Atta timp ct evoluia proiectului (linia verde Planul de proiect curent) se
pstreaz n limitele de Toleran stabilite (liniile roii Limite de Toleran ), atunci
Managerul de Proiect poate conduce proiectul fr implicarea Comitetului de
Conducere al Proiectului. n momentul n care se previzioneaz faptul c deviaia
planului curent (linia verde - Planul de proiect curent) de la planul de proiect
aprobat (linia albastr Planul de proiect iniial) va depi limitele de toleran
aprobate (liniile roii - Limite de Toleran ), atunci Managerul de Proiect aplic
procedura de excepie i solicit decizia Comitetului de Conducere al Proiectului.
5.2.3.3.2 Descrierea livrabilelor
nainte de a ncepe dezvoltarea sau obinerea unui livrabil, nc din faza de
planificare, se documenteaz o descriere a fiecrui livrabil. Scopul realizrii acestor
descrieri este acela ca fiecare persoan implicat n procesul obinerii livrabilului s
cunoasc:
de ce este necesar un anumit livrabil
cum va arta un anumit livrabil
din ce surse va fi obinut livrabilul
care sunt specificaiile de calitate cu care trebuie s fie conform livrabilul
Cost
Timp
Planul de proiect
iniial
Planul de proiect
curent
Limite de
Toleran
Limite de
Toleran
Figura 4: Toleranele proiectului



Pagina 34 din 87
Descrierea livrabilului este un document de control, care este creat ca parte a
procesului de planificare. Documentul definete livrabilul, standardele care vor fi
folosite pentru obinerea sa i criteriile de calitate care vor fi aplicate pentru a se
verifica faptul c produsul este potrivit scopului pentru care a fost creat. Aceaste
informaii nu sunt importante numai pentru persoana responsabil cu obinerea
livrabilului, dar constituie i o prim gril de control a calitii livrabilului, odat
acesta realizat.
Descrierile Livrabilelor nsoesc Structura Defalcat a Livrabilelor proiectului, care
face parte din Planul de Proiect. Din acest motiv, Descrierile Livrabilelor sunt
aprobate de ctre Comitetul de Conducere al Proiectului. n momentul n care
Managerul de Proiect autorizeaz diferite Pachete de Lucru care vor fi executate de
persoanele din cadrul echipei de proiect, documentele de Descriere a Livrabilelor
vor nsoi aceste Pachete de Lucru.
5.2.3.3.3 Autorizarea Pachetelor de Lucru
Autorizarea unui Pachet de Lucru constituie aciunea prin care Managerul de Proiect
comand unei persoane sau unui grup demararea unui set de activiti n cadrul unei
Etape. Cu alte cuvinte, toate activitile din cadrul proiectului trebuie autorizate de
ctre Managerul de Proiect nainte de a fi demarate.
Pachetul de Lucru va conine Descrierea Livrabilelor, precum i constrngerile
referitoare la timp i cost, interfeele cu alte Pachete de Lucru, necesitile de
raportare, cerinele care trebuie realizate n vederea predrii livrabilului ctre
Beneficiar, precum i orice alt documentaie necesar n vederea nelegerii i a
implementrii Pachetului de Lucru. Toate activitile pe care Furnizorul le va sub-
contracta vor fi oficializate prin Pachete de Lucru.
5.2.3.3.4 Controlul calitii
Proiectul necesit proceduri i tehnici pentru controlul calitii livrabilelor pe care le
produce. Tipurile de controale de calitate difer n funcie de tipul de livrabil pentru
care sunt dezvoltate. Indiferent de modalitatea tehnic de realizare a controlului
calitii, exist un proces generic care se va aplica n toate aceste cazuri. Acest
proces este acela de edin de Verificare a Calitii.
edina de Verificare a Calitii face parte din metodele de control ale calitii. Este
o munc n echip prin care se asigur calitatea printr-un proces de verificare.
Obiectivul edinei de Verificare a Calitii este acela de a se inspecta livrabilul ntr-
o manier planificat, obiectiv, controlat i documentat. Documentele edinelor
de Verificare a Calitii formeaz o dovad documentar a faptului c livrabilele au
fost inspectate, c toate erorile identificate au fost corectate i c toate coreciile
fcute au fost, la rndul lor, verificate.
edinele de Verificare a Calitii pot fi utilizate pentru controlul calitii
documentelor (tehnice sau de management). n funcie de tipul de livrabil care este
inspectat, pot exista alte metode de verificare a calitii. Pentru un sistem informatic,
acestea pot fi:
teste de funcionalitate
teste de stres (testarea sistemului n condiii de ncrcare mare, din punct de
vedere al numrului de utilizatori)



Pagina 35 din 87
teste de volum (testarea rspunsului sistemului n condiiile simulrii unei
ncrcri masive a bazelor de date)
teste de vitez (de procesare, de rspuns, de transmisie etc.)
teste de securitate
alte tipuri de teste
5.2.3.3.5 Problemele de Proiect
Ca parte a mijloacelor de control, trebuie s existe o procedur care s trateze
posibilele deviaii de la specificaiile aprobate. Aceste deviaii pot apare din mai
multe motive:
schimbarea cerinelor utilizatorilor
schimbri legislative care duc la necesitatea modificrii livrabilelor
solicitarea din partea Beneficiarului sau a Utilizatorului de adugare a unui
nou criteriu de acceptan
oportunitatea introducerii de noi funcionaliti
modificri organizaionale care duc la necesitatea adaptrii livrabilelor
proiectului
imposibilitatea Furnizorului de a livra tot ceea ce este contractat n limitele
de timp i cost stabilite
eecul unui subcontractor de a-i ndeplini obligaiile asumate i planificate
incertitudine asupra posibilitii Furnizorului de a rezolva o anumit cerin
funcional
Folosirea procedurii de tratare a Problemelor de Proiect asigur c se va rspunde la
toate problemele, ntrebrile sau sugestiile, dar c astfel de activiti nu se
desfoar fr cunotina nivelelor de management relevante, inclusiv a
Comitetului de Conducere al Proiectului. Pe lng controlul asupra eventualelor
schimbri n cadrul proiectului, procedura furnizeaz o cale oficial prin care toate
ntrebrile sau cererile pot fi formulate. Procedura presupune nregistrarea i tratarea
tuturor Problemelor de Proiect semnalate pe durata proiectului. De asemenea,
procedura ofer control asupra modalitii de tratare a acestor probleme i asigur
comunicarea napoi ctre originatorul problemei a rezoluiei finale asupra problemei
n cauz.
5.2.3.3.6 Controlul Schimbrii
Proiectul trebuie s aib o procedur de tratare a nevoilor de schimbare. n lipsa
controlului schimbrii nu poate exista un control al proiectului. Toate schimbrile
solicitate sunt documentate sub form de Probleme de Proiect. Procedura de Control
al Schimbrii trebuie s trateze aspecte cum ar fi evaluarea impactului schimbrii
solicitate, prioritizarea schimbrilor, luarea deciziei i apoi implementarea.
Controlul Schimbrii este tratat pe larg n alt seciune a acestui document.
5.2.3.3.7 Registrul Riscurilor
Un alt mijloc important de control pe durata unui proiect este controlul riscurilor.
Toate riscurile identificate sunt pstrate ntr-un Registru al Riscurilor, mpreun cu



Pagina 36 din 87
analiza acestora, contramsurile planificate i starea fiecrui risc n parte. Acest
proces demareaz odat cu nceperea proiectului i se continu pe ntreaga durat a
desfurrii acestuia. Toate riscurile trebuie revzute n mod regulat (cel puin la
sfritul fiecrei etape, dar i pe durata desfurrii etapei).
Management-ul Riscurilor este tratat pe larg n alt seciune a acestui document.
5.2.3.3.8 Puncte de Verificare
Punctele de Verificare (edine de Control) sunt o modalitate periodic de verificare
de ctre Managerul de Proiect a stadiului unei anumite Etape a proiectului. La aceste
edine particip cei implicai n activitile etapei respective. n funcie de
anvergura proiectului i de organizarea acestuia, edinele de control pot fi
declanate de ctre Managerul de Proiect sau de ctre efii de Echip. Obiectivul
principal al unei edine de control este acela de a verifica toate aspectele proiectului
comparativ cu planurile, pentru a se asigura c nu exist probleme neidentificate
care pot afecta desfurarea proiectului.
Informaiile adunate n cadrul edinelor de Control formeaz baza documentar n
funcie de care Managerul de Proiect va pregti Raportul de Stare ctre Comitetul de
Conducere al Proiectului. Frecvena Punctelor de Verificare i a edinelor aferente
va fi stabilit de ctre Managerul de Proiect n funcie de complexitatea i durata
proiectului, astfel nct acesta s poat pstra un control eficient asupra progresului.
5.2.3.3.9 Rapoarte de Stare
Rapoartele de Stare sunt pregtite de ctre Managerul de Proiect i trimise ctre
Comitetul de Conducere al Proiectului cu o frecven stabilit de ctre Comitetul de
Conducere al Proiectului (bi-lunar sau lunar), n funcie de durata etapei curente sau
n funcie de riscurile existente n etapa respectiv. Coninutul Raportului de Stare
este definit de ctre Comitetul de Conducere al Proiectului i conine cel puin
urmtoarele informaii:
realizri n cadrul perioadei curente
realizri ateptate n cadrul perioadei urmtoare
probleme curente sau poteniale, mpreun cu sugestii privind rezolvarea lor.
Rolul unui Raport de Stare este acela de a permite Comitetului de Conducere al
Proiectului s realizeze management-ul prin excepie pe durata unei Etape de
proiect. n condiiile n care Planul de Etap i Toleranele etapei sunt stabilite,
Comitetul de Conducere al Proiectului este ntiinat asupra progresului realizat prin
intermediul Rapoartelor de Stare. n momentul n care se previzioneaz deviaii de
la Planul de Etap, Comitetul de Conducere al Proiectului este ntiinat prin
intermediul unui Raport de Excepie.
5.2.3.3.10 Raport de Excepie
Un Raport de Excepie este o avertizare din partea Managerului de Proiect ctre
Comitetul de Conducere al Proiectului referitor la faptul c o anumit etap (sau
ntreg proiectul) va devia n afara limitelor de toleran stabilite. Rapoartele de
Excepie trebuie documentate.
Un Raport de Excepie descrie o deviaie previzionat, furnizeaz o analiz att a
excepiei aprute ct i a variantelor de continuare i identific opiunea
recomandat. Un Raport de Excepie duce la organizarea unei Verificri



Pagina 37 din 87
Intermediare de Etap i constituie baza pentru realizarea unui Plan de Excepie
pentru opiunea recomandat n vedere continurii proiectului.
5.2.3.3.11 Verificarea de Sfrit de Etap
Unul din obiectivele mpririi proiectului n Etape este acela de a permite
Comitetului de Conducere al Proiectului aprobarea individual a fiecrei Etape a
proiectului. La sfritul fiecrei etape, Comitetul de Conducere al Proiectului
verific rezultatul etapei finalizate i decide condiiile de demarare a unei noi Etape.
Acest proces se numete Verificarea de Sfrit de Etap.
Indiferent de modalitatea n care se realizeaz (oficial sau informal), Verificarea de
Sfrit de Etap este obligatorie la sfritul fiecrei Etape. n cadrul verificrii se
trece n revist i se aprob activitatea desfurat pn n acel moment, justificnd
evoluia ntr-o nou faz a proiectului. O Etap de proiect nu va fi considerat
finalizat n lipsa unei aprobri oficiale a Comitetului de Conducere al Proiectului.
n cadrul unei Verificri de Sfrit de Etap se:
verific acurateea justificrii economice a proiectului
verific rezultatele Etapei comparativ cu Planurile de Etap
confirm calitatea livrabilelor obinute n cadrul Etapei
stabilete faptul c etapa curent a fost finalizat n mod satisfctor
realizeaz o analiz a riscurilor i se verific stadiul general al proiectului,
rezultatele fiind ncorporate n urmtorul Plan de Etap i n Planul de
Proiect
se revd toleranele pentru urmtoarea Etap
se autorizeaz trecerea proiectului n urmtoarea Etap
Comitetul de Conducere al Proiectului poate refuza aprobarea urmtorului Plan de
Etap, dac este nemulumit de unele din aspectele evaluate. n aceste condiii, poate
solicita Managerului de Proiect modificarea Planului de Etap, poate recomanda
nchiderea prematur a proiectului sau poate apela la arbitrarea unei autoriti
superioare de decizie.
5.2.3.3.12 Raportul de Sfrit de Etap
Raportul de Sfrit de Etap este modalitatea prin care Managerul de Proiect
informeaz Comitetul de Conducere al Proiectului asupra rezultatului unei Etape a
proiectului. Comitetul de Conducere al Proiectului va compara aceste rezultate cu
Planurile de Etap aprobate la nceputul Etapei.
5.2.3.3.13 Verificare Intermediar de Etap
O Verificare Intermediar de Etap are loc ntre Comitetul de Conducere al
Proiectului i Managerul de Proiect dup primirea unui Raport de Excepie.
Obiectivul acestei verificri este acela de a-i permite Managerului de Proiect s
prezinte Comitetului de Conducere al Proiectului un Plan de Excepie i s obin
aprobarea acestuia pentru implementarea planului.



Pagina 38 din 87
5.2.3.4 Controlul nchiderii proiectului
nainte de a aproba nchiderea proiectului, Comitetul de Conducere al Proiectului
are mijloacele de control pentru a se asigura c:
toate livrabilele agreate au fost furnizate i acceptate
acolo unde este cazul, au fost realizate aranjamentele necesare pentru
suportul i ntreinerea livrabilelor pe durata lor de via
nainte de nchiderea proiectului, Comitetul de Conducere al Proiectului trebuie s
confirme n scris acceptana sa referitor la ncheierea proiectului. Aceast acceptan
poate fi acordat chiar dac exist deficiene minore n livrabilele furnizate, cu
condiia ca s existe un plan de rectificare a acestor deficiene ulterior.
5.2.3.4.1 Recomandri privind activiti nefinalizate
La finalul proiectului mai pot exista un numr de activiti nefinalizate. De exemplu,
pot exista Cereri de Schimbare care nu au fost respinse de ctre Comitetul de
Conducere al Proiectului, dar a cror implementare a fost amnat pn dup
ncheierea proiectului; poate nu s-a finalizat transferul tuturor livrabilelor, sau poate
exist probleme nc nerezolvate la unele livrabile.

Documentul privind Recomandrile cu privire la activitile nefinalizate identific
toate activitile nefinalizate, permind Comitetului de Conducere al Proiectului s
atribuie aceste activiti persoanelor a cror sarcin va fi s revad aceste
recomandri i s decid cursul aciunii dup ncheierea proiectului.
5.2.3.4.2 Raportul de Sfrit al Proiectului
Raportul de Sfrit al Proiectului este similar celui de Sfrit de Etap, dar acoper
ntregul proiect. Acest Raport trece n vedere modul n care proiectul a fost condus,
inclusiv performana fa de Documentele de Iniializare ale Proiectului.



Pagina 39 din 87
5.2.4 Management-ul Riscurilor
Management-ul riscurilor reprezint o component esenial n cadrul management-
ului de proiect, ntruct riscurile reprezint factori majori ce trebuie luai n
considerare n procesul de planificare, monitorizare i control al proiectului.
Riscul poate fi definit ca fiind un eveniment nesigur sau un set de circumstane
care, odat aparut(e), are(au) efect (negativ) n atingerea obiectivelor proiectului.
Proiectele au ca scop implementarea schimbrilor, ceea ce determin ca efortul de
implementare s nu fie ntotdeauna predictibil i astfel probabilitatea materializrii
unui risc pe parcursul derulrii unui proiect nu poate fi ignorat.
5.2.4.1 Tipuri de riscuri
Cteva din riscurile tipice ale unui proiect IT sunt (cu titlu de exemplu):

probleme legate de furnizori:
o eecul identificrii unor furnizori corespunztori;
o eecul livrarii produselor de ctre furnizori i sub-contractori;
o probleme contractuale.
factori organizaionali:
o responsabiliti adiionale pentru personalul din proiect, pe lng
activitile de proiect;
o cultura educaional (sau lipsa ei) din cadrul organizaiei
Beneficiarului;
o probleme de instruire sau de experien a personalului;
o abiliti tehnice insuficiente ale membrilor echipei de proiect;
o conflicte de cultur organizaional ntre echipele Furnizorului
i Beneficiarului.
probleme tehnice (elemente specifice de proiect):
o ct de bine sunt formulate cerinele;
o probleme legate de tehnologie (noutatea tehnologic);
o imposibilitatea realizrii unor specificaii sau omiterea unor
specificaii;
o problemele legate de testarea calitii.
5.2.4.2 Metode de management al riscurilor
Management-ul riscurilor este una din ndatoririle fundamentale ale Managerului de
Proiect i ale Comitetului de Conducere al Proiectului. Sarcina Managerului de
Proiect este aceea de a identifica riscurile, de a le nregistra i apoi monitoriza.
Sarcinile Comitetului de Conducere al Proiectului sunt:
atenionarea Managerului de Proiect relativ la eventualele riscuri externe
care pot afecta proiectul



Pagina 40 din 87
luarea deciziilor pe baza recomandrilor Managerului de Proiect referitor la
diferitele riscuri
pstrarea unei balane ntre nivelul de risc al proiectului i beneficiile pe care
proiectul le poate aduce
sesizarea impactului pe care riscurile proiectului le pot avea asupra altor
proiecte derulate de Beneficiar
Managerul de Proiect are sarcina elaborrii i a modificrii planurilor pentru a
include aciuni identificate i agreate n vederea reducerii impactului riscurilor.
Fiecare risc va fi asociat unui responsabil, care va avea sarcina monitorizrii riscului
pe ntreaga sa perioad de existen.
Limitarea influenei riscurilor se face prin dou tipuri de activiti: analiz i
management.
5.2.4.2.1 Analiza riscurilor
Analiza riscurilor include trei activiti:
identificarea riscurilor care pot afecta proiectul;
estimarea riscului, adic determinarea importanei fiecrui risc pe baza unei
evaluri a consecinelor sale asupra proiectului;
evaluarea riscului, aciune prin care se decide dac nivelul riscului este
acceptabil, iar daca nu atunci se va hotr ce aciuni trebuie ntreprinse
pentru a aduce nivelul riscului la un nivel acceptabil prin:
o Prevenire n acest caz se pun n practic contramsuri care fie
opresc producerea riscului fie previn impactul su asupra
proiectului
o Reducere prin aceast aciune se reduce probabilitatea
materializrii riscului sau se limiteaz impactul su la un nivel
acceptabil
o Transfer aceast aciune este una de reducere prin care
impactul riscului se transfer ctre o ter parte (ex. Poli de
asigurare)
o Msuri de rezerv n acest caz aciunile se planific astfel nct
s se aplice n momentul apariiei riscului
o Acceptare Comitetul de Conducere al Proiectului accept
posibilitatea apariiei unui risc, bazndu-se fie pe faptul c riscul
nu va apare, fie considernd c alte activiti cost prea mult.
5.2.4.2.2 Management-ul riscurilor
Management-ul riscurilor se realizeaz prin patru activiti:
Planificarea - const n identificarea resurselor necesare derulrii aciunilor
stabilite n faza de analiz, n dezvoltarea unui plan de aciune i includerea
acestui plan n cadrul Planului de Etap i n obinerea aprobrii pentru acest
plan;
Alocarea resurselor - const n identificarea i alocarea resurselor care vor fi
utilizate pentru a aciona n scopul evitrii riscului sau a minimizrii



Pagina 41 din 87
impactului sau; aceste alocri vor fi incluse n Planul de Etap; resursele
necesare pentru ntreprinderea aciunilor de prevenire, reducere i transfer
vor fi suportate din bugetul proiectului;
Monitorizarea - const n verificarea faptului c aciunile planificate i puse
n practic au efectul dorit asupra riscurilor identificate; examinarea
semnalelor timpurii de apariie a riscului; prognozarea riscurilor poteniale;
verificarea faptului c management-ul riscului se realizeaz ntr-un mod
eficient;
Controlul adic aciunile care se iau i prin care se verific faptul c
planurile sunt respectate.



Pagina 42 din 87
5.2.5 Calitatea
n mediul de proiect, calitatea se refer la identificarea caracteristicilor produselor
sau a serviciilor care fac ca acestea s fie potrivite scopului pentru care sunt
realizate.
Managementul calitaii este procesul prin care se asigur realizarea dezideratelor de
calitate ale proiectului, iar acest proces cuprinde toate activitile de management de
proiect care definesc i duc la implementarea Planului de Calitate al Proiectului.
Fiecare tip de livrabil are propriile sale aspecte de calitate. Criteriile de calitate sunt
definite de ctre Beneficiar i se pot traduce prin:
Cerine funcionale
Performan
Securitate
Compatibilitate
Siguran
Uurin n ntreinere
Flexibilitate
Posibilitate de extensie
Claritate
Compararea cu un alt produs
Cost
Perioada necesar implementrii
5.2.5.1 Planul de Calitate al proiectului
Planul de Calitate trebuie s fie parte a Documentelor de Iniializare ale Proiectului
i definete n termeni generali modul n care proiectul va rpunde cerinelor de
calitate ale Beneficiarului. De asemenea, Planul de Calitate al proiectului trebuie s
identifice tehnicile i standardele care vor fi utilizate, precum i responsabilitile cu
privire la calitate din cadrul proiectului. n cazul n care Furnizorul are implementat
la nivel de companie o politic n domeniul calitii, atunci Planul de Calitate al
proiectului va identifica toate procesele i procedurile din cadrul acestei politici de
calitate care vor fi utilizate n cadrul proiectului.
n cazul n care Furnizorul are n cadrul companiei implementat o structur de
asigurare a calitii, atunci Planul de Calitate trebuie s descrie modul n care
aceast structur va realiza interfaa cu funciile de calitate ale proiectului.
5.2.5.2 Planul de Calitate al Etapei
Acest plan cuprinde detalii referitor la modul n care se va implementa Planul de
Calitate al Proiectului ntr-o anumit etap a proiectului. Pentru fiecare livrabil care
trebuie realizat n aceea etap se va defini modul n care se va testa sau verifica
calitatea produsului respectiv, precum i cine va fi implicat n cadrul fiecrei etape
de verificare.



Pagina 43 din 87
Planul de Calitate al Etapei trebuie s identifice n mod clar momentele n care
produsul va trebui revizuit n vederea verificrii calitii. Principiul de baz care
trebuie urmrit n aceast direcie este ca testarea i verificarea calitii livrabilelor
s se desfoare pe ntreaga perioad a realizrii acestora i nu numai n momentul
n care un livrabil este gata pentru acceptana final. O neconformitate descoperit
n acest ultim moment poate crea ntrzieri n calendarul de implementare, iar
rezolvarea ei cost mult mai mult dect n cazul n care ar fi descoperit n etapele
incipiente ale dezvoltrii livrabilului.
5.2.5.3 Descrierea Livrabilelor
n momentul ntocmirii Planului de Etap, acesta trebuie s includ descrierea
detaliat a tuturor livrabilelor care vor fi obinute n cadrul acelei etape. Descrierea
fiecrui livrabil trebuie s includ criteriile de calitate i nivelul de acceptan pentru
fiecare criteriu de calitate n parte.
Avnd n vedere faptul c Utilizatorul va fi cel care, n final, va realiza verificarea
criteriilor de calitate, este recomandat ca acesta s fie implicat inclusiv n activitile
de realizare a Descrierii Livrabilelor i a criteriilor de calitate ale acestora.
5.2.5.4 edine de Verificare a Calitii
Dup cum a fost deja prezentat ntr-o seciune anterioar, verificarea se realizeaz
prin revizuirea livrabilului ntr-o manier planificat, organizat i documentat de
ctre persoanele care au fost identificate n momentul realizrii Planului de Calitate
al Etapei.
5.2.5.5 Registrul de Calitate
Acest document va cuprinde informaii despre toate verificrile de calitate care s-au
efectuat pe parcursul derulrii proiectului, fiind actualizat de ctre eful de Echip
sau de ctre un membru al echipei nsrcinat cu dezvoltarea i testarea produsului.
Acest Registru va fi creat n timpul etapei de Iniializare a Proiectului.



Pagina 44 din 87
5.2.6 Management-ul Configuraiilor
5.2.6.1 Rol i funcii de baz
Management-ul Configuraiilor identific, urmrete i protejaz livrabilele
proiectului, fiind un proces la fel de important atunci cnd este aplicat documentelor
proiectelor sau oricrui alt livrabil de proiect.
Rolul managementului configuraiei este acela de a furniza:
un mecanism pentru management-ul, urmrirea i meninerea controlului pentru
livrabilele proiectului. Astfel, sunt pstrate evindene privind toate livrabilele
proiectului din momentul n care ele au fost verificate din punct de vedere al
calitii, se controleaz acesul la ele i se menin nregistrri privind stadiul n
care ele se gsesc;
un sistem pentru nregistrarea, urmrirea i pstrarea tuturor Problemelor
Proiectului;
informaii privind diferitele versiuni de livrabile care alctuiesc sistemul, la un
moment dat. Acest lucru permite realizarea de teste pariale sau ale ntregului
sistem.
Management-ul configuraiilor are cinci funcii de baz:
planificarea decizia asupra nivelului de management al configuraiei necesar
proiectului i stabilirea modului n care acest nivel va fi atins;
identificarea identific i specific toate componentele livrabilului final;
controlul abilitatea de a aproba i apoi de a inghea un anumit livrabil i
apoi de a face schimbri asupra sa numai avnd aprobarea unei autoriti clar
stabilite;
gestiunea strii nregistrarea i raportarea tuturor datelor actuale i istorice
legate de evoluia unui livrabil;
verificarea serie de verificri i audituri pentru a se asigura c exist o
conformitate ntre produs i starea autorizat a produsului, aa cum este ea
registrat n Registrul Configuraiilor Livrabilelor.
Management-ul configuraiei este parte integrant a controlului calitii, ntruct
fr aceast component Managerul de Proiect nu ar ti care este ultima versiune a
fiecrui livrabil din cadrul proiectului.
Configuraia unui proiect reprezint suma tuturor livrabilelor care vor face parte din
sistemul final. Toate produsele specializate ale unui proiect sunt parte a
configuraiei. Documentaia de mangement i calitate poate fi tratat i ea ca produs
al configuraiei n scopul controlului emiterii diverselor versiuni ale documentaiei
respective.
Management-ul Configuraiilor acoper urmtoarele funcii:
identific sub-livrabilele individuale ale sistemului final
identific acele livrabile de care va fi nevoie pentru a produce alte livrabile
stabilete un sistem de codare care va identifica n mod unic fiecare livrabil n
parte



Pagina 45 din 87
identific responsabilul pentru fiecare versiune a unui livrabil
identific persoana creia i-a fost delegat sarcina de a crea sau modifica
versiunea unui livrabil
nregistreaz, monitorizeaz i raporteaz stadiul curent al fiecrui livrabil
pstreaz toat documentaia produs pe parcursul ciclului de realizare a unui
livrabil
pstreaz originalele livrabilelor realizate
emite proceduri de asigurare a siguranei i securitii livrabilelor i a
controlului accesului la livrabile
distribuie copii ale tuturor livrabilelor i pstreaz informaii referitor la cei care
au primit o astfel de copie
pstrareaz nregistrarea relaiilor dintre livrabile, astfel nct nici un livrabil s
nu fie schimbat fr posibilitatea verificrii impactului posibil asupra
livrabilelor cu care el se relaioneaz
administreaz schimbarea pentru toate livrabilele
stabilete referinele livrabilelor (baseline)
realizeaz audit-uri de configuraie
5.2.6.2 Planul de Management al Configuraiilor
Acest plan face parte din Planul de Calitate al Proiectului i const n:
descrierea ariei de aplicare a management-ului configuraiilor
descrierea metodelor de management al configuraiei care vor fi utilizate
referina la orice alt sistem de management al configuraiei cu care se va
relaiona
identificarea persoanei responsabile cu Management-ul Configuraiilor
(Administratorul Configuraiilor)
identificarea livrabilelor, a nivelului livrabilelor sau claselor produselor care vor
fi controlate n cadrul management-ului configuraiei
un plan al documentelor i al bibliotecii de proiect care vor fi utilizate pentru a
pstra livrabilele
5.2.6.3 Management-ul Configuraiei i Controlul Schimbrii
Este foarte important s se poat verifica i controla diferitele versiuni ale fiecrui
livrabil. Un livrabil care face parte din referina proiectului (baseline) poate fi
modificat numai n urma unui proces oficial de control al schimbrii.
n momentul n care un livrabil a fost aprobat, versiunea lui nu va mai fi niciodat
modificat. Dac este necesar o modificare a unui livrabil aprobat, atunci se va crea
o nou versiune a livrabilului, care va cuprinde modificarea fcut. De asemenea, se
vor pstra informaiile referitoare la motivul care a dus la realizarea unei noi
versiuni a livrabilului.



Pagina 46 din 87
5.2.7 Controlul Schimbrii
Schimbarea necontrolat a specificaiilor sau a ariei de cuprindere pentru un proiect
pot duce uor la eecul proiectului, dac aceast schimbare nu este gestionat
corespunztor. Cu toate acestea, schimbrile n proiect sunt foarte probabile i nu
trebuie evitate.
Controlul schimbrii nseamn evaluarea impactului pe care o potenial schimbare
l poate produce, prioritatea, costul i o eventual decizie a management-ului privind
implementarea schimbrii.
nainte de a trece prin procesul de management al schimbrii, orice schimbare este
iniiat ca o Problem de Proiect. Aceasta este apoi analizat i, dac se ajunge la
concluzia c Problema respectiv nu constituie o disfuncionalitate sau c nu face
parte din setul oficial de cerine, atunci va fi tratat ca o schimbare.
n cazul n care un livrabil trebuie modificat, atunci trebuie verificat Descrierea
Livrabilului pentru a se face modificrile necesare. Dac un produs a fost aprobat de
Comitetul de Conducere al Proiectului, atunci acel produs nu mai poate fi modificat
fr aprobarea Comitetului de Conducere al Proiectului.
Controlul schimbrilor revine Comitetului de Conducere al Proiectului. n cazul n
care, n faza de Iniializare a Proiectului, se consider c proiectul va fi supus multor
schimbri i Comitetul de Conducere al Proiectului nu dispune de timpul necesar
pentru management-ul acestor schimbri, atunci sarcina management-ului
schimbrii poate fi delegat unui grup Comitet de Schimbare. Decizia de transfer
a responsabilitii Controlului Schimbriilor trebuie luat n faza de Iniializare a
Proiectului i aceste responsabiliti trebuie descrise corespunztor n fiele de
definire a rolului pentru persoanele implicate.
Orice schimbare va fi iniial privit ca o Problem de Proiect i va trebui tratat prin
acceai metod de abordare a controlului schimbrii. O Problem de Proiect poate
fi:
cerere de schimbare a specificaiilor
sugestie de mbuntire a unuia sau a mai multor livrabile din proiect
neconformitate
ntrebare de clarificare

Indiferent de tipul Problemei, ea trebuie nregistrat n Registrul de Probleme, unde
i se va aloca un numr unic, se va nregistra autorul, data i tipul problemei. Autorul
trebuie s indice prioritatea problemei:
obligatorie deoarece livrabilul final nu va funciona fr modificarea
respectiv;
important absena schimbri ar fi un inconvenient;
util dar schimbarea nu este vital;
cosmetic fr importan;
nu necesit schimbare.



Pagina 47 din 87
La orice Problem de proiect care apare sub form de ntrebare sau care are la baz
nelegerea greit a unor aspecte de proiect trebuie s se rspund imediat autorului
iar Registrul de Probleme trebuie actualizat pentru a reflecta aciunea ntreprins.

Este necesar apoi o analiz a impactului pentru fiecare Problem rmas pentru a
se identifica:
Ce trebuie s se schimbe
Ce efort presupune aceast schimbare
Care este impactul asupra Justificrii Economice a Proiectului
Care este impactul asupra riscurilor

Dup aceast analiz, prioritatea problemei va fi reevaluat de ctre reprezentantul
Utilizatorului i de ctre Furnizor.
Dac Problema este o neconformitate, atunci Managerul de Proiect va ncerca s o
rezolve n cadrul toleranelor Etapei curente. Dac acest lucru nu este posibil, atunci
se va folosi procedura de Excepie. Comitetul de Conducere al Proiectului poate
autoriza acceptarea unei neconformiti, caz n care acest lucru va fi nregistrat ca o
Concesie.
Managerul de Proiect poate decide care dintre Cererile de Schimbare vor fi
implementate n cadrul Planului de Etap curent, n funcie de constrngerile
existente. Chiar dac modificrile necesare nu necesit fonduri sau timp
suplimentar, Managerul de Proiect trebuie s poarte discuii cu reprezentantul
Utilizatorului i cu Beneficiarul referitor la aceste modificri. Managerul de Proiect
nu trebuie s autorizeze fr aprobarea Comitetului de Conducere al Proiectului nici
un fel de aciune care ar duce la modificarea unui livrabil care a fost deja aprobat de
Comitetul de Conducere al Proiectului.


Ghid Metodologic pentru Managementul Proiectelor
Informatice

Pagina 48 din 87
6. CAIETUL DE SARCINI CERINE SPECIFICE PRIVIND
MANAGEMENTUL PROIECTELOR

Aceast seciune a Ghidului identific un set de cerine specifice ale Beneficiarului unui
proiect TIC ctre potenialii Ofertani din punct de vedere al Managementului de Proiect.
Aceste cerine specifice corespund aspectelor generale prezentate n seciunea precedent i
pot face subiectul evalurii ofertantilor.
6.1 Organizarea proiectului (vezi 5.2.1)
C1.1 Ofertantul va prezenta n detaliu modalitatea n care proiectul va fi organizat,
incluznd cel puin urmtoarele elemente: Comitetul de Conducere al Proiectului, Manager
de Proiect, efi de Echip i alte roluri importante din cadrul echipei tehnice de proiect,
Echipa de Suport administrativ, propunerea privind Comitetul de Control al Calitii.
C1.2 Se va prezenta modalitatea de escaladare a problemelor n interiorul organizaiei
Ofertantului.
C1.3 n cazul n care Ofertantul va subcontracta activitile de obinere a unor livrabile de
proiect, atunci acesta va prezenta identitatea exact a Subcontractorilor, precum i
modalitatea n care Subcontractorii vor fi inclui n cadrul echipei de proiect.
C1.4 Se va prezenta componena propus pentru Comitetul de Conducere al Proiectului.
C1.5 Se va prezenta identitatea persoanei propuse pentru poziia de Manager de Proiect,
inclusiv un CV detaliat al acestei persoane. CV-ul va include informaii referitoare la
experiena anterioar, incluznd detalii referitoare la proiectele realizate, perioadele ntre
care a deinut poziii n cadrul unor echipe de proiect, poziia deinut n cadrul echipei de
proiect, numele angajatorului i pe cel al clientului, atribuiile i realizrile, numele i datele
de contact ale persoanelor care pot confirma experiena similar.
C1.6 Se vor prezenta i CV-urile efilor de Echip.
Avnd n vedere faptul c CV-ul Managerului de Proiect propus de ctre Ofertant va fi luat
n considerare ca parte a procesului de evaluare a ofertelor, Project Manager-ul nominalizat
nu va putea fi schimbat pe ntreaga perioad a derulrii proiectului, cu excepia situaiei n
care persoana nominalizat nceteaz s mai fie angajat al organizaiei Ofertantului. n
aceast situaie, Ofertantul va nominaliza un nlocuitor care va avea cel puin aceleai
calificri cu cele ale persoanei pe care o va nlocui. Nominalizarea unui nou Manager de
Proiect va fi supus aprobrii Comitetului de Conducere al Proiectului, care va trebui s
avizeze pozitiv aceast nou nominalizare.
C1.7 Se va prezenta organizarea propus pentru echipa Beneficiarului, cu prezentarea
rolurilor i a atribuiilor principale, precum i a nivelului de cunotine necesar. Resursele
identificate de ctre Ofertant ca fiind necesare n cadrul echipei de proiect a Beneficiarului
nu vor fi considerate de ctre Ofertant ca fiind disponibile, dect n cazul confirmrii
oficiale din partea Beneficiarului. n caz contrar, indisponibilitatea acestor resurse ale
Beneficiarului solicitate de ctre Ofertant nu va fi considerat ca fiind motiv de modificare a
ofertei.

Conducerea de nivel nalt a proiectului va fi asigurat de ctre Comitetul de Conducere al
Proiectului. Comitetul de Conducere al Proiectului va fi un organism prin care reprezentanii
Beneficiarului, al Utilizatorilor i al Furnizorului vor discuta i stabili liniile directoare ale
proiectului. Decizia final a Comitetului de Conducere al Proiectului va fi luat de ctre
Reprezentantul Beneficiarului, care din acest punct de vedere va avea rol de Preedinte al


Informatice

Pagina 49 din 87
Comitetului de Conducere al Proiectului. Funcionarea Comitetului de Conducere al
Proiectului nu va fi pe principii democratice i nu se va realiza pe baz de vot din acest
punct de vedere, prezena Reprezentantului Furnizorului are rol pur consultativ. Toate
deciziile Comitetului de Conducere al Proiectului care vor avea implicaii contractuale vor
trebui reflectate n amendamente la Contract.
6.2 Planificarea proiectului (vezi 5.2.2)
C2.1 Ofertantul va prezenta modalitatea n care propune s aplice procesul de planificare n
cadrul proiectului. De asemenea, se va prezenta responsabilitatea pentru producerea
planurilor care vor fi utilizate pe durata proiectului.
C2.2 Ofertantul va prezenta ca parte a ofertei sale varianta iniial a Documentelor de
Iniializare ale Proiectului. Componena acestor documente va fi:
Introducere prezentarea contextului proiectului i a motivului care justific necesitatea
proiectului
Definirea proiectului prezentarea rezultatelor pe care le urmrete proiectul:
o obiectivele proiectului
o aria de cuprindere a proiectului
o prezentarea modalitii generale de abordare (folosirea de produse
comerciale, configurare sau dezvoltarea de aplicaii de la zero, echip
proprie sau subcontractare etc.)
o livrabilele proiectului (produse, servicii, documentaie etc.) i alte rezultate
ateptate
o excluderi (ce nu face parte din proiect)
o constrngeri
o interfee cu alte proiecte
Structura Organizatoric a proiectului, cu prezentarea Echipei de Management a
Proiectului (organigram i descrierea rolurilor vezi C1.1)
Plan de Comunicare (ntre Comitetul de Conducere al Proiectului, Managerul de Proiect
i alte pri implicate n proiect)
o identificarea prilor implicate n proiect
o necesarul de informaie
o sursa informaiilor
o frecvena comunicrii i
o coninutul comunicrii
Planul de Calitate al Proiectului
o responsabilitile referitoare la asigurarea calitii
o referina la standardele care trebuie respectate
o identificarea criteriilor cheie de calitate care trebuie atinse
o metodele de control i audit pentru calitatea produselor de management de
proiect i a celor tehnice specializate
o procedura pentru management-ul schimbrii


Informatice

Pagina 50 din 87
o planul pentru management-ul configuraiilor
o alte instrumente pentru asigurarea calitii
Planul Iniial de Proiect, care va prezenta cum i cnd vor avea loc activitile
proiectului
o Descrierea planului i a activitilor acoperite de plan
o Dependene externe
o Ipoteze de planificare
o Calendarul Proiectului (Diagram Gantt) pentru ntregul proiect,
identificnd Pachetele de Lucru i Etapele de Proiect (etapele de control, nu
neaprat cele ale ciclului de via al proiectului); vor fi identificate
activitile, dependenele, datele de nceput i de sfrit, livrabilele, punctele
de control, activitile de testare i acceptan; se va evidenia calea critic a
proiectului.
o Structura Defalcat a Livrabilelor proiectului (Product Breakdown
Structure)
o fiele cu Descrierea Livrabilelor
o Pachetele de Lucru
o Resursele necesare
o Resursele necesare din partea Beneficiarului
Controlul Proiectului, care va prezenta modul n care vor fi exercitate funciile de
control n cadrul proiectului, precum i mecanismele de raportare i de monitorizare care
vor sprijini funciile de control
Procesul de tratare a excepiilor
Registrul Iniial al Riscurilor, prezentnd rezultatul analizei riscurilor identificate i
activitile de management al acestora
Planurile de rezerv, prezentnd modalitatea n care se propune gestionarea riscurilor
care se vor materializa
Structura Bibliotecii de Proiect, prezentnd modalitatea de pstrare i de recuperare a
elementelor de informaie i a livrabilelor produse de proiect

C2.3 Ofertantul va prezenta, ca parte a ofertei sale, Planul de Etap corespunztor primei
etape a proiectului (cea ulterioar iniializrii proiectului). Planul va avea aceeai
componen cu Planul de Proiect, dar va prezenta la un nivel mult mai detaliat aspectele
corespunztoare primei Etape a Proiectului
6.3 Controlul proiectului (vezi 5.2.3)
C3.1 Ofertantul va prezenta toleranele pe care le propune pentru Planul de Proiect i pentru
primul Plan de Etap. Ofertantul va prezenta modalitatea n care Managerul de Proiect va
realiza controlul toleranelor n cadrul fiecrei etape, precum i procedura care se va aplica
n momentul n care aceste tolerane vor fi depite.
Pentru acest proiect, Comitetul de Conducere al Proiectului nu va autoriza tolerane de cost,
bugetul proiectului fiind fix.
C3.2 Descrierea fiecrui livrabil va avea urmtorul coninut:


Informatice

Pagina 51 din 87
Numele sau codul
Motivaia (este un livrabil final sau este necesar n vederea obinerii unui alt livrabil?)
Compoziia livrabilului
Sursa livrabilului (un alt livrabil, un furnizor, o specificaie etc.)
Format i Prezentare (criterii vizuale)
Responsabil (cine este responsabil cu obinerea livrabilului)
Criterii de Calitate aplicabile (descrierea criteriilor de calitate pe care livrabilul trebuie
s le respecte, sau o referin la un alt document detaliat; de asemenea, descrierea
modalitii n care persoanele responsabile vor testa conformitatea cu aceste criterii de
calitate)
Tipul de verificare a calitii aplicabil (tipul de inspecie sau testare care se va aplica)
Resursele necesare n vederea testrii calitii livrabilului

Criteriile de calitate prezentate nu vor fi ambigue i vor prezenta aspecte msurabile.
Criteriile de acceptan pot fi, de exemplu:
data planificat pentru finalizarea livrabilului
funciile principale
prezentarea vizual
nivelul de pregtire necesar pentru folosirea produsului
nivelul de performan
capacitatea
acurateea
disponibilitatea
timpul necesar reparrii unui defect, timpul mediu ntre defectri
costuri de dezvoltare
costuri de ntreinere
securitate
uurin de utilizare
timpi de rspuns
C3.3 n cazul n care Ofertantul va subcontracta activitile de obinere a unor livrabile,
atunci va prezenta Pachetele de Lucru ataate acestor activiti. Structura unui Pachet de
Lucru va conine:
Data
Numele persoanei sau al echipei autorizate s realizeze pachetul de lucru
Descrierea pachetului de lucru
Descrierea Livrabilelor care fac parte din pachetul de lucru
Tehnicile, procesele i procedurile care trebuie utilizate
Necesitile de interfaare cu alte livrabile


Informatice

Pagina 52 din 87
Metodele de verificare a calitii care vor fi utilizate
Nivelul de resurse care va fi alocat, datele de nceput i de sfrit
Aprobrile necesare
Constrngeri
Modalitatea de raportare
Pachetele de Lucru care vor fi subcontractate vor fi prezentate n forma semnat att de ctre
Ofertant, ct i de ctre Subcontractorul propus.
C3.4 Ofertantul va propune o metod prin care Coordonatorul de Proiect al Beneficiarului i
eventual reprezentanii utilizatorilor s fie implicai n deciziile proiectului i s participe la
edinele de Control ale proiectului.
C3.5 Toat comunicarea Managerului de Proiect cu Comitetul de Conducere al Proiectului
va fi adus i la cunotina Coordonatorului de Proiect al Beneficiarului.
C3.6 Rapoartele de Stare prezentate periodic de ctre Managerul de Proiect ctre Comitetul
de Conducere al Proiectului vor avea urmtorul coninut minimal:
Data
Perioda de raportare
Starea bugetului proiectului
Stadiul graficului de implementare
Livrabilele finalizate
Probleme de Proiect i starea acestora
Livrabile care vor fi finalizate n cursul urmtoarei perioade de raportare
Cereri de Schimbare supuse aprobrii, precum i analiza de impact a acestora

C3.7 Rapoartele de Final de Etap pregtite de ctre Managerul de Proiect vor conine
urmtoarele informaii:
Planul Etapei Curente, cu datele la zi
Vedere de ansamblu asupra Planului de Proiect pentru perioada urmtoare
Analiza riscurilor
Starea Problemelor Proiectului
Registrul de Calitate al Proiectului
Analiza problemelor care au afectat etapa ncheiat

C3.8 Rapoartele de Excepie vor conine urmtoarele informaii:
descrierea cauzei care a dus la devierea de la Planul de Etap
consecinele devierii
opiunile de continuare a proiectului
analiza opiunilor existente i a implicaiilor acestora asupra toleranelor generale ale
proiectului


Informatice

Pagina 53 din 87
recomandrile Managerului de Proiect
6.4 Management-ul riscurilor (vezi 5.2.4)
C4.1 Ofertantul va prezenta un Registru al Riscurilor ca parte component a Documentelor
de Iniializare ale Proiectului. Registrul Riscurilor va fi completat cu riscurile specifice
proiectului i va conine, pentru fiecare risc identificat, cel puin urmtoarele informaii:
Numrul riscului (din cadrul Registrului)
Tipul riscului (de proiect, de etap)
Data identificrii
Data ultimei revizuiri
Descrierea riscului
Probabilitatea de apariie
Severitatea
Contra-msuri
Responsabilul cu verificarea implementrii contra-msurilor
Starea riscului (deschis, nchis)

C4.2 Ofertantul va descrie modalitatea practic n care va realiza management-ul riscurilor,
implicnd n aceast activitate i personalul echipei de proiect a Beneficiarului.
6.5 Calitatea (vezi 5.2.5)

C5.1 Ofertantul va ntreine pe ntreaga durat a proiectului un Registru de Calitate n care
va nregistra toate verificrile de calitate care vor fi realizate asupra livrabilelor proiectului.
Informaiile incluse n Registrul de Calitate vor cuprinde:
Numrul de referin
Livrabilul
Metoda de verificare a calitii
Persoanele responsabile cu verificarea calitii
Data planificat pentru testare
Data real a derulrii testelor
Rezultatele obinute
Activitile corective stabilite
Data planificat pentru aprobarea livrabilului
Data real a aprobrii livrabilului

C5.2 Ofertantul va include n cadrul Documentelor de Iniializare ale proiectului propunerea
sa privind Planul de Acceptan al proiectului. Acest plan va prezenta ntr-o form
condensat, pentru fiecare tip de livrabil n parte (produse sau servicii), tipul de teste care
vor fi realizate n vederea aceptanei. Pentru toate serviciile incluse n bugetul proiectului (n
oferta financiar) se vor prezenta livrabilele care vor rezulta n urma prestrii serviciilor,


Informatice

Pagina 54 din 87
precum i modalitatea de acceptare a acestora. Procesul de acceptan va avea loc att n
vederea aprobrii unor etape sau livrabile intermediare, ct i n vederea plii. Plata
serviciilor se va realiza numai n urma aprobrii livrabilelor rezultate, nu folosind criterii
temporale (ex: pli lunare etc.).
C5.3 Planul de Calitate iniial prezentat de ctre Ofertant va identifica tipurile de teste care
vor fi realizate, precum i momentele n care aceste teste vor fi realizate. Testele vor fi
grupate pe tipuri de funcionaliti, iar pentru fiecare funcionalitate se vor pregti ulterior
Scenarii de Test. Fiecare Scenariu de Test va include descrierea funcionalitii care se
testeaz, modalitatea de testare, datele de test folosite, rezultatele ateptate n urma testului.
Scenariul de Test va include de asemenea informaii referitor la versiunea livrabilului care
va fi testat, configurri ale livrabilului necesare n vederea realizrii testului, echipamente
necesare, precum i resursele umane necesare i pregtirea acestora. Scenariile de Test vor fi
pregtite n comun de ctre Furnizor i Beneficiar i vor trebui aprobate de ctre Comitetul
de Conducere al Proiectului nainte de nceperea testelor de acceptan.
6.6 Management-ul configuraiilor (vezi 5.2.6)
C6.1 Ofertantul va prezenta un Plan de Management al Configuraiilor ca parte component
a Planului de Calitate al Proiectului.
6.7 Controlul schimbrii (vezi 5.2.7)
C7.1 Ofertantul va ntreine un Registru al Problemelor de Proiect pe ntreaga durat a
derulrii acestuia. Registrul Problemelor va identifica urmtoarele informaii:
Data
Numrul de referin al problemei din registru
Descrierea problemei
Prioritatea
Analiza de impact
Decizia luat
Semntura persoanei care a luat decizia
Data la care s-a luat decizia

C7.2 Ofertantul va prezenta o procedur detaliat de tratare a Cererilor de Schimbare,
incluznd etapele de identificare, analiz, decizie i implementare. Procedura va identifica
etapele logice care vor fi urmate, precum i rolurile i responsabilitile tuturor prilor
implicate. O cerere de Schimbare va conine urmtoarele informaii obligatorii:
Data
Numrul din Registrul Problemelor
Starea
Descrierea schimbrii propuse
Impactul schimbrii solicitate
Evaluarea prioritii
Decizia
Responsabilitatea pentru implementarea schimbrii


Informatice

Pagina 55 din 87
Data cnd cererea de schimbare a fost alocat n vederea implementrii
Data cnd schimbarea a fost implementat

6.8 Criterii de evaluare a ofertelor
Aceast seciune cuprinde recomandri privind punctajele care se pot acorda seciunii
referitoare la managementul proiectelor din cadrul ofertei:

Project Management 100

Organizarea proiectului 30
Manager de Proiect 20
Echipa de proiect 10
Documentele de iniializare ale Proiectului 60
Planul de Calitate 15
Planul de Riscuri 10
Planul de Proiect 15
Descrierea Livrabilelor 5
Diagrama Gantt 10
Controlul proiectului (inclusiv raportarea) 10
Planul de Acceptan 10
Planul detaliat al primei Etape 10


Informatice

Pagina 56 din 87
7. ALTE RECOMANDRI
7.1 Clauze contractuale
Clauzele contractuale sunt un instrument foarte puternic de control al evoluiei proiectului i
de intervenie n cazul n care evoluia nu este conform cu planificarea. Din acest motiv, este
important s acordai o atenie deosebit variantei de Contract pe care o includei n cadrul
Documentaiei pentru Elaborarea i Prezentarea Ofertei.
La ncheierea contractului avei n vedere urmatoarele recomandri de clauze care, n funcie
de complexitatea proiectului, pot fi incluse n Contract. Acestea sunt doar cteva din
clauzele care pot fi folosite n cadrul unui Contract i n nici un caz nu formeaz un Contract
complet. Pentru redactarea Contractului, apelai la personal de specialitate .

1. OBIECTUL I DURATA CONTRACTULUI
1.1. Obiectul Contractului
a) Furnizarea Produselor conform descrierilor de produse prezentate n Anexa 1 la acest
Contract Descrierea Produselor.
b) Prestarea de Servicii conform descrierilor de servicii din Anexa 2 la acest Contract -
Descrierea Serviciilor.
1.2. Durata Contractului
Prezentul contract este valabil de la data semnrii sale de ctre pri i pn la data de
zz.ll.aaaa.

2. DREPTURILE I OBLIGAIILE PRILOR
2.1. OBLIGAIILE FURNIZORULUI
a. S furnizeze produsele i s presteze serviciile ce fac obiectul contractului, specificate n
detaliu n Anexele 1 si 2, conform graficului de ndeplinire prezentat n Anexa 4, pn la
data de zz.ll.aaaa.
b. S respecte n totalitate, pe toata durata implementrii proiectului, metodologia de
management de proiect descris n Ofert
c. S nominalizeze n termen de x zile de la data semnrii contractului o persoan pentru
poziia de Manager de Proiect, conform ofertei sale. Beneficiarul va valida persoana
nominalizat pentru rolul de Manager de Proiect i nu va refuza n mod nejustificat persoana
propus de ctre Furnizor.
d. Odat ce persoana propus este validat de ctre Beneficiar, Furnizorul nu poate schimba
aceast persoan pe parcursul derularii proiectului fr un motiv ntemeiat i fr acordul
Beneficiarului.
2.2 OBLIGAIILE BENEFICIARULUI
a. S efectueze plata produselor i a serviciilor conform graficului de pli.
b. S desemneze un reprezentant al su (Coordonator de Proiect) pentru toate aspectele
legate de comunicarea de zi cu zi ntre Furnizor i Beneficiar (Rapoarte, Notificri,
Probleme).


Informatice

Pagina 57 din 87
c. S desemneze reprezentanii si n cadrul Comitetului de Conducere al Proiectului i s
asigure nivelul corespunztor de autoritate al acestor persoane n vederea lurii deciziilor ce
privesc obiectul contractului.
d. S respecte toate obligaiile specifice proiectului (dependenele) descrise n Anexa 5 la
Contract.
e. S comunice furnizorului, conform procedurii de control a proiectului, orice problem
aprut pe parcursul implementrii proiectului.
2.3 OBLIGAII COMUNE
a. S pun la dispoziie pe toat durata prezentului Contract resursele critice necesare
identificate n Planul de Resurse descris n Anexa 6 la acest Contract i n conformitate cu
Graficul de ndeplinire prezentat n Anexa 4 la acest Contract.
b. S agreeze i s desfoare aciunile corespunztoare, conform rolurilor i a
responsabilitilor stabilite, pe durata contractului.
c. Prile au obligaia s colaboreze n vederea rezolvrii oricrei probleme aprute pe
perioada contractului.

3. TESTAREA I ACCEPTANA
3.1 Toate Produsele i Serviciile acestui Contract, identificate n Anexele 1 i 2 la acest
Contract, fac obiectul unui proces oficial de Testare i/sau Acceptan de ctre reprezentanii
desemnai ai Beneficiarului.
3.2 Testarea i Acceptana Produselor i a Serviciilor se vor derula conform Planului de
Calitate descris n Documentele de Iniializare ale proiectului. Acceptana va urmri toate
criteriile de calitate i performan specifice acestora, aa cum sunt ele definite n Planul de
Calitate aprobat.
3.3 Pentru Produse se vor obine de ctre Furnizor din partea Beneficiarului urmtoarele
Certificate de Acceptan:
Certificat de Acceptan Cantitativ n urma furnizrii produselor la sediul
Beneficiarului i a inspeciei cantitative a acestora n conformitate cu Anexa 1
Descrierea Produselor i a Listei de Ambalare (Colisaj).
Certificat de Acceptan Parial n urma instalrii i a configurrii Produselor
furnizate i dup ndeplinirea criteriilor de acceptan n urma testrii.
3.4 Pentru Servicii se vor obtine de ctre Furnizor din partea Beneficiarului Certificatul de
Acceptan pentru Servicii n urma:
prestrii serviciilor de ctre Furnizor;
acceptrii serviciilor de ctre Beneficiar, precum i a livrabilelor rezultate n urma
prestrii acestor servicii n msura n care acestea sunt identificate n Anexa 2
Descrierea Serviciilor;
3.5 n cazul unor neconformiti minore (de exemplu care nu afectecteaz funcionalitatea
general), beneficiarul poate decide acceptarea Produselor i/sau a Serviciilor cu observaii.
Aceste observaii se vor regsi n Certificatul de Acceptan i neconformitile vor trebui s
fie remediate de ctre Furnizor n termenele agreate de comun acord. Obinerea de ctre
Furnizor a Certificatului de Acceptan cu observaii nu poate determina efectuarea de pli
de ctre Beneficiar, dar va face inaplicabil plata de penaliti de ntrziere de ctre Furnizor
pentru Produsele i/sau Serviciile pentru care a fost obinut acceptana. n cazul n care


Informatice

Pagina 58 din 87
neconformitile identificate nu sunt remediate n termenele stabilite sau nu sunt acceptate
de ctre Beneficiar, atunci Certificatul de Acceptan cu observaii obinut anterior este
considerat nul. n acest caz, plata penalitilor de ntrziere se va calcula avnd ca referin
data la care Produsele i Serviciile trebuiau livrate conform Graficului de ndeplinire.
3.6 Serviciile de management de proiect sunt considerate acceptate de ctre Beneficiar
numai dac au fost prestate i s-au derulat conform cu metodologia descris n ofert. Pentru
Serviciile de management de proiect acceptate de ctre Beneficiar se poate oferi separat
Cerificat de Acceptan pentru Servicii.
3.7 La sfritul ndeplinirii contractului se va obine de ctre Furnizor din partea
Beneficiarului Cerificatul de Acceptan Final. Acest certificat nu este necesar s fie
obinut n urma unui proces de testare specific, dar va fi condiionat de obinerea tuturor
celorlalte acceptane pariale pentru Produsele i Serviciile care fac obiectul acestui
Contract. Obinerea Certificatului de Acceptan Final nu va exonera furnizorul de
obligaiile acestuia pentru buna execuie i garanie.
4. Garanii
Furnizorul se angajeaz:
4.1 S ofere o garanie de n ani pentru Produsele furnizate i o garanie de m ani pentru
Serviciile prestate n cadrul acestui Contract. n cazul Serviciilor, garania se aplic i la
produsele finite care reprezint rezultatul Serviciilor prestate.
4.2 S obin i s pun la dispozitia Beneficiarului o Scrisoare de Garanie Bancar pentru
Bun Execuie, n cuantum de xx% din preul acestui Contract.

5. PENALITI, DAUNE INTERESE
5.1 Orice ntrziere fa de termenul de plat prevzut n contract va fi penalizat
Beneficiarului cu 0,0x % pe zi de ntrziere din suma datorat i neachitat.
5.2 Orice ntrziere n furnizarea produselor sau n prestarea serviciilor fa de graficul de
implementare, din vina exclusiv a Furnizorului, va fi penalizat Furnizorului cu 0,0x % pe
zi de ntrziere din valoarea Produselor sau a Serviciilor care fac obiectul ntrzierii.
5.3 ntrzierea cu mai mult de nn zile calendaristice fa de data de finalizare a
implementrii proiectului, din vina exclusiv a Furnizorului, se consider neexecutare a
contractului.
5.4 n cazul neexecutrii contractului, din vina exclusiv a Furnizorului, Furnizorul are
obligaia de a despgubi Beneficiarul prin plata de daune-interese, n valoare de xx% din
Preul Contractului.

7. REZILIEREA CONTRACTULUI
7.1 Contractul se rezilieaz:
prin acordul prilor,
reziliere de drept n cazul nendeplinirii sau a ndeplinirii n mod necorespunztor a
obligaiilor contractuale de ctre furnizor, dup o prealabil notificare de 30 de zile. Pe
durata notificrii se vor calcula penalitile de ntrziere. La expirarea perioadei de
notificare, contractul se consider reziliat i se va executa garania de bun execuie.
declanrii procedurii falimentului.


Informatice

Pagina 59 din 87
7.2 n cazul rezilierii, Furnizorul va avea dreptul la plata contavalorii serviciilor i a
produselor acceptate de ctre Beneficiar pn la data rezilierii.

8. CLAUZE FINALE
8.1 Prezentul contract intr n vigoare la data semnrii lui de ctre ambele pri.
8.2 Toate modificrile i completrile la prezentul contract sunt valabile numai n scris,
semnate de ambele pri n cadrul unui act adiional.
8.3 Urmtoarele documente fac parte integrant din prezentul contract i vor fi interpretate
n urmtoarea ordine a precedenei lor:
Acest Contract i Anexele sale:
o Anexa 1 - Descrierea Produselor
o Anexa 2 - Descrierea Serviciilor
o Anexa 3 - Lista de Preuri
o Anexa 4 - Graficul de ndeplinire
o Anexa 5 - Obligaii Specifice (Dependene)
o Anexa 6 - Graficul de pli
Oferta Tehnic a Furnizorului
Caietul de Sarcini
8.4 Contractul a fost ntocmit i semnat n dou exemplare, de valoare juridic egal, cte
unul pentru fiecare parte.


Informatice

Pagina 60 din 87
7.2 Recomandri diverse
Stabilii care sunt prile interesate n proiect i ncercai s meninei o comunicare ct
mai bun cu ei, pentru a asigura viabilitatea proiectului.
Avei n vedere alternativa utilizrii consultanilor pentru: studiu de fezablitate, caiet de
sarcini, management de proiect, consultan tehnic etc.
Stabilii nc din faza de iniiere a proiectului (n hotrrea de consiliu) competenele
legate de proiect ale comitetului de conducere sau a echipei de proiect.
Includei n proiect (mai ales n cadrul proiectelor mari) cerina ca un consultant
independent s realizeze analiza de sistem sau studiul de fezabilitate al acestuia precum
i managementul de proiect dup metodologii recunoscute.
Dup acceptarea analizei de sistem (studiul de fezabilitate) iniiai un proiect de hotrre
de consiliu care s avizeze nceperea proiectului cu modificrile cuprinse n studiul de
fezabilitate (s-ar putea ca dup analiza de sistem s apar factori noi, riscuri majore,
modificri de costuri etc.)
consultai ct mai multe soluii de bun practic, studiai exemple viabile i transpunei
experiena lor n proiectul dumneavoastr
Componena recomandat a Comitetului de Conducere al Proiectului:
o Beneficiar: n funcie de aria de cuprindere i de complexitatea proiectului,
recomandm un membru al conducerii instituiei:
preedinte, vicepreedinte, primar, viceprimar pentru proiecte
complexe
director general, director executiv pentru proiecte cu sfer de
cuprindere limitat la nivelul unei direcii sau departament
o Reprezentantul Utilizatorilor:
director general, director executiv pentru proiecte complexe
ef serviciu, ef birou - pentru proiecte cu sfer de cuprindere
limitat la nivelul unei direcii sau departament
o Reprezentantul Furnizorului: director general/manager general sau
reprezentantul desemnat al acestuia
o exemplul 1: implementarea unui sistem informatic integrat la nivelul
instituiei:
reprezentant beneficiar: preedinte, vicepreedinte/ primar,
viceprimar
reprezentant utilizator: secretar general, director general, director
direcie economic, arhitect ef, director direcie
reprezentant furnizor: director general
o exemplul 2: implementarea unui sistem pentru eviden contabil
reprezentant beneficiar: director direcie economic
reprezentant utilizator: ef serviciu contabilitate, ef serviciu buget
reprezentant furnizor: director general


Informatice

Pagina 61 din 87
Cerei ca studiul de studiul de fezabilitate s cuprind detaliat:
o Identificarea ariei de cuprindere a sistemului (subsistemele instituiile
cuprinse)
o Identificarea resurselor existente (personal, echipamente) n cadrul
organizaiei ct i a pregtirii lor profesionale n domeniul informatiicii
(operatori, programatori, analiti, administratori de sisteme i baze de date
etc.)
o Identificarea tuturor costurilor care exist ntr-un subsistem legate de
sistemul informatic existent, comunicaii etc.
o Identificarea tuturor proceselor existente i a proceselor de schimb
informaional ntre procesele care sunt informatizate, necesitile de
adaptare,integrare
o Estimarea tuturor costurilor de adaptare, informatizarea proceselor i
informatizarea proceselor de schimb informaional ntre procesele din
cadrul unui subsistem informaional i a proceselor de schimburi
informaionale ntre subsisteme.
o Identificarea legislaiei n vigoare aplicabil fiecrui subsistem
informaional i a schimburilor informaionale dintre sisteme
o Identificarea metodelor de implementare a proiectului n regim de tip out-
sourcing, out-tasking etc.
o Previzionarea modificrilor legislative n context naional i internaional i
impactul acestora asupra realizrii proiectului
o Identificarea standardelor aplicabile i recomandarea de soluii n contextul
tendinelor de implementare la nivel naional sau internaional.
o Identificarea tuturor standardelor tehnice i tehnologii deschise aplicabile
pentru asigurarea schimbului informaional ntre procese n cadrul unui
subsistem informaional sau ntre subsistemele informaionale (asigurarea
integrabilitaii i a interoperabilitii)
o Identificarea tuturor metodelor de testare teste de stres, de volum, de
vitez de rspuns, user friendly, de securitate etc. care s stea la baza
acceptanei livrabilelor
o Identificarea tuturor arhitecturilor de sistem posibile i recomandarea celor
aplicabile
o Identificarea tuturor livrabilelor i a pachetelor de lucru (activiti),
estimarea costurilor, duratelor de implementare i a punctelor de control
o Identificarea soluiilor pentru Planul de implementare pentru ca acesta s
nu blocheze activitatea instituiei
o Identificarea cerinelor minimale pentru Planul de management al
riscurilor - identificarea riscurilor i descriere, cauze, impact (evaluarea lor
ca probabilitate i justificare), responsabili, msuri preventive i corective
etc.
o Identificarea cerinelor minimale pentru Planul de calitate
o Identificarea cerinelor minimale pentru Planul de control i instrumentele
acestuia


Informatice

Pagina 62 din 87
o Identificarea cerinelor minimale pentru Planul de management al
schimbrii
o Identificarea cerinelor minimale pentru asigurarea mentenanei
postimplementare. Identificarea contractelor de tip Service Level
Agreement (garantarea serviciilor i nivelul acestora)
o Identificarea modalitilor de protejare a investiiei. Identificarea modurilor
de pstrare a codurilor surs, a versiunilor acestora etc. (ex.: pstrarea lor de
ctre un ter escrow)
o Estimarea bugetului proiectului alctuit din suma bugetului de materiale i
de resurse umane, bugetului de risc, bugetului de management
o Identificarea procentului de pli n avans, plata parial, plata final pentru
a asigura un flux de numerar (cash flow) pozitiv
o Identificarea tuturor soluiilor de finanare a proiectului n funcie de
bugetul estimat (finanare de la bugetul local, fonduri speciale, finanare
guvernamental, finanare extern, finanare prin parteneriate publice
private sau mixt) i recomandri n acest sens
o Identificarea formelor recuperare a investiiei (ROI)
o Identificarea rolurilor structurii de conducere i execuie n realizarea
proiectului
o Identificarea soluiilor tehnice existente la diveri productori i a costului
acestora.
o Realizarea unui studiu de impact al proiectului att asupra cetenilor ct i
asupra funcionarilor instituiilor.
o Identificarea metodelor de instruire a personalului instituiilor n funcie de
regimul de implementare
o Identificarea modalitilor de auditare postimplementare pentru a asigura
utilizarea rezultatelor proiectului i dup finalizarea implementrii
Cerei consultantului s realizeze caietul de sarcini mpreun cu dumneavoastr n
funcie de cerinele care deriv din studiul de fezabilitate (analiza de sistem)
Solicitai furnizorului garanii bancare pentru avansurile acordate
Solicitai furnizorului garanii de bun execuie.
Solicitai furnizorului servicii de mentenan bazate pe contracte de tip SLA (Service
Level Agreement) , garantarea serviciilor i nivelul acestora
7.3 List de verificare a documentelor de proiect
Pentru identificarea livrabilelor de management ale proiectului recomandm analizarea
Anexei 3.
7.3.1 Iniializarea proiectului
La iniializarea proiectului, se produc urmtoarele documente:
Planul de organizare a proiectului
Planul de comunicare
Planul de calitate


Informatice

Pagina 63 din 87
Planul de Proiect, incluznd:
o dependene
o ipoteze
o diagrama Gantt (calendar de proiect)
o Structura defalcat a livrabilelor
o Descrierea livrabilelor
o Pachetele de lucru
o Planul de resurse
Controlul proiectului
Planul de riscuri
Structura bibliotecii de proiect
Aceste documente vor fi ntreinute pe ntreaga perioad a derulrii proiectului i vor fi
revizuite n cadrul fiecrei etape a proiectului.
7.3.2 Planificare
Din punct de vedere al planificrii:
la sfritul fiecrei etape se supune aprobrii planul detaliat al etapei urmtoare
n cazul apariiei unei deviaii de la planul aprobat, se produce un Plan de Excepie care
nlocuiete Planul curent de Etap
7.3.3 Raportare
Din punct de vedere al raportrii:
Managerul de Proiect produce n mod periodic Rapoarte de Stare ctre Comitetul de
Conducere al Proiectului
la sfritul fiecrei etape, Managerul de Proiect produce un Raport de Sfrit de Etap
n cazul apariiei unei deviaii de la planul aprobat, Managerul de Proiect produce un
Raport de Excepie
la finalizarea proiectului, Managerul de Proiect produce un Raport de Sfrit al
Proiectului i un Raport privind Activitile Nefinalizate


Informatice

Pagina 64 din 87
8. GLOSAR DE TERMENI

Termenul n limba romn Termenul n limba englez
Aria de Cuprindere a Proiectului Project Scope
Biblioteca de Proiect Project Library
Calendar de proiect (Diagrama Gantt) Project Schedule (Gantt Chart)
Cerere de Schimbare Change Request
Contramsur (referitor la risc) Contingency
Controlul Schimbrii Change Control
Comitet de Conducere al Proiectului Project Board sau Steering Committe
Descrierea livrabilului Product description
Documentele de Iniializare ale Proiectului Project Initiation Document
Escaladare (a unei probleme) Escalation (process)
Iniializarea Proiectului Project Initiation
Justificarea economic a proiectului Business Case
Livrabil Deliverable
Managementul Configuraiilor Configuration Management
Manager de Proiect Project Manager
Pachet de Lucru Work Package
Plan de Etap Stage Plan
Plan de Excepie Exception Plan
Plan de Lucru al Echipei Team Plan
Plan de Proiect Project plan
Presupunere Project Prerequisites
Problem de Proiect Project Issue
Puncte de Verificare Checkpoints
Raport de Stare Highlight Report
Raport de Excepie Exception Report
Raport de Sfrit de Etap End Stage Report
Raportul de Sfrit al Proiectului Project Closure Report
Recomandrile cu privire la activitile
nefinalizate
Follow-on action Recomendations
Referina proiectului Project Baseline
Registrul Riscurilor Risk Register
Reprezentantul Beneficiarului Executive
Reprezentantul Furnizorului Senior Supplier
Reprezentantul Utilizatorului Senior User
Scenariu de Test Test Script
Structura Defalcat a Livrabilelor Product Breakdown Structure


Informatice

Pagina 65 din 87
edin de Verificare a Calitii Quality Review
Toleranele Proiectului Project Tolerances
Verificarea de Sfrit de Etap End Stage Assessment
Verificare Intermediar de Etap MidStage Assessment
nchiderea Proiectului Project Closure


Informatice

Pagina 66 din 87
9. ANEXE

ANEXA 1 Propunerea de Proiect
ANEXA 2 Determinarea Dimensiunii Proiectelor
ANEXA 3 - Livrabilele de management ale proiectului
ANEXA 4 Descrierea principalelor roluri din proiect
ANEXA 5 - Model de Curriculum Vitae
ANEXA 6 Formular de diagnoz


Informatice

Pagina 67 din 87
9.1 Anexa 1: Propunerea de Proiect

Ctre:
Ref.:
Titlul proiectului:

Beneficiar:
Furnizor: Departamentul IT
Buget estimat (EUR):

Durata estimat:
Data:

Semnturile membrilor Comitetului de Conducere al Proiectului
Nume i prenume Semntura
1.
2.
3.

Rezoluia:

aprobat, fr comentarii
aprobat cu comentarii (vezi anexa)
mai sunt necesare informaii (vezi anexa)
respins
comentarii (vezi anexa)

Data:

Semnturi:


Informatice

Pagina 68 din 87
1. Numele proiectului i o scurt descriere a acestuia
(Facei un scurt rezumat al proiectului de cca. 1 pagin, care s cuprind scopul,
obiectivele, rezultateleateptate ale proiectului, perioada de implementare i posibilitatea
de continuare, contribuia local, punctele tari si punctele slabe ale acestuia)
2. Informaii despre organizaia/departamentul care va implementa proiectul
Demonstrai credibilitatea organizaiei care va implementa proiectul prezentnd experiena
acesteia i alte aspecte relevante pentru proiect. Demonstrai c organizaia este capabil
s abordeze i s rezolve problemele care au dus la generarea ideii de proiect.
3. Analiza persoanelor / organizaiilor care au un interes n proiect; identificarea
utilizatorilor proiectului i a beneficiarului
Grupul celor
interesai
Care este beneficiul sau
pierderea lor ca urmare
a realizrii proiectului?
Activitile necesare
pentru obinerea
sprijinului grupului
Modalitatea de
implicare n
proiect

4. Susinerea necesitii proiectului
(Analizai necesitatea proiectului: care sunt problemele care au generat ideea de proiect,
analiza i argumentarea acestora etc. Vezi. Explicai n ce stadiu se vor afla problemele
respective dup terminarea proiectului. Explicai ce s-ar ntmpla dac nu s-ar rezolva
aceste probleme.)
5. Scopul i Obiectivele proiectului
(Identificai Scopul i Obiectivele proiectului. Scopul reprezint rezolvarea problemei pe
termen lung, adic stadiul n care vrem s ajung problema n urma proiectului. Obiectivele
comunic ceea ce trebuie s realizeze proiectul pentru utilizatori, adic paii care trebuie
fcui pentru a realiza Scopul proiectului.)
6. Rezultatele estimate ale proiectului
(Identificai Rezultatele cantitative/msurabile - de ex: numr servicii noi, baze de date,
numr cursuri, numr absolveni cursuri, numr proiecte noi identificate, orice alte
rezultate n funcie de tipul proiectului -- i calitative ale proiectului, completnd tabelul
urmtor.)
Scopul Proiectului Obiectivele Proiectului Rezultatele proiectului
Rezultatul 1
Rezultatul 2
Obiectivul 1

...

Obiectivul 2
...

7. Modalitatea de evaluare a proiectului (indicatori de realizare a rezultatelor)
(Pentru fiecare rezultat identificai unul sau mai muli indicatori de msurare i completai
tabelul urmtor.)


Informatice

Pagina 69 din 87
Rezultate-Indicatori

Valoarea indicatorului planificat
la sfritul proiectului
Modaliti de verificare a
atingerii rezultatelor
Rezultatul 1:
Indicator 1:
Indicator 2:
.

Rezultatul 2:
Indicator 1:
Indicator 2:
.

..


Informatice

Pagina 70 din 87
8. Planificarea Activitilor, a Subactivitilor i a Punctelor de Control
(Pentru fiecare rezultat idenficai mai multe activiti, iar pentru fiecare activitate identificai i subactivitile necesare. Identificai i punctele de
control i completai tabelul urmtor.)

Rezultate Activiti/
Subactiviti
Data de ncepere Data de sfrit
L1 L2 L3 L4 L5 L6 L7 L8 L9
Rezultatul 1 Activitatea 1.1
Subactivitatea 1.1.1
Subactivitatea 1.1.2.
Activitatea 1.2.
Subactivitatea 1.2.1
Rezultatul 2 Activitatea 2.1.
.
Punct de Control 1
Rezultatul 3

Punct de Control 2
..
L1, L2, L3 etc. semnific luna n care se deruleaz activitatea respectiv.


Informatice

Pagina 71 din 87
9. Matricea de alocare a resurselor
(Completai Matricea de Analiz Logic conform tabelului de mai jos.)

Indicatori de msurare
a performanei
Metode de verificare Riscuri sau ipoteze
Scopul proiectului:

Obiectivele proiectului:

Rezultatul 1:

Activiti pentru
Rezultatul 1

Resurse Costuri

10. Diagrama de personal, descrierea echipei de implementare a proiectului (inclusiv fia
postului i CV), descrierea Comitetului de Conducere al Proiectului i alocarea sarcinilor.
(Pe baza Analizei de la punctul 9, identificai necesarul de personal pentru implementarea
proiectului i elaborai diagrama de personal care va indica: numrul de persoane necesare
pentru fiecare post n parte, felul contractului, numele persoanelor care vor ocupa aceste
posturi ( atunci cnd este posibil) sau specificaia "se va organiza selecie de personal". Avei
n vedere s existe cel puin o persoan cu norm ntreag n posturile cheie. Elaborai fiele
posturilor i specificaia de personal. Anexai CV-urile persoanelor care tii deja c vor
participa la implementarea proiectului. Descriei Comitetul de Conducere al Proiectului i
alocai sarcinile.)
11. Bugetul proiectului i ealonarea lunar a sumelor necesare
(Completai urmtoarele tabele n EURO. Bugetul proiectului reprezint suma costurilor
estimate n Matricea de Alocare a Resurselor completat la punctul 9.)

CATEGORIA DE CHELTUIELI UM Cantitate Preul
unitar
TOTAL

1 2 3 4 5=4 x 3
CHELTUIELI DE CAPITAL (investiii)
Echipament
Mobilier
Soft
Teren
Cladiri
Alte mijloace fixe


Informatice

Pagina 72 din 87
CATEGORIA DE CHELTUIELI UM Cantitate Preul
unitar
TOTAL

1 2 3 4 5=4 x 3
CHELTUIELI CURENTE
Amenajri
Chirie
Utiliti
Consumabile
Transport
Promovare
Salarii personal folosit in servicii
CHELTUIELI DE PRODUCTIE
(dac este cazul)

Materii prime
Materiale
Transport aferent produciei
Salarii personal direct productiv

TOTAL

12. Ealonarea lunar a sumelor necesare
Categoria
Bugetar
(*)
L1 L2 ... ... L9

Total

TOTAL
(*) Se trec categoriile din tabelul de la punctul 11 de mai sus.

13. Posibiliti de dezvoltare i durabilitate ale proiectului
(Durabilitatea este o cerin major pentru un proiect de succes. Prezentai modul n care vei
asigura continuarea activitilor i vei obine rezultate i dup terminarea proiectului.
Detaliai veniturile preconizate a se obine din activitatea proiectului, precum i cheltuielile
pentru primii 3 ani; Argumentai aceste estimri.)


Informatice

Pagina 73 din 87
9.2 Anexa 2: Determinarea dimensiunii proiectelor
Dimensiunea unui proiect este determinat de o multitudine de factori cerine tehnologice, gradul i nivelul riscurilor, numrul factorilor de
decizie implicai n proiect, durata proiectului, valoarea proiectului, nivelul de pregtire al echipei de proiect etc.
Pentru o exemplificare mai facil a modului de determinare a dimensiunii unui proiect recomandm urmtoarea clasificare :
MIC MEDIU MARE
Numrul de persoane
din echipa de proiect
1 - 2 2 5 5+
Durata < 6 luni 6 12 luni > 12 luni
Planificarea proiectului Planificarea etapelor proiectului
este flexibil
Planificarea etapelor poate avea mici
abateri de la planificarea iniial dar data
limit de realizare a acestora este ferm
Data limit de realizare a etapelor
proiectului este ferm i nu poate fi
schimbat , iar planificarea etapelor nu este
flexibil
Complexitate Problema este foarte uor
neleas , soluia este uor de
realizat i ndeplinit
Fie dificulti n nelegerea problemei , fie
o soluie neclar , fie o soluie foarte greu
de realizat
i problema i soluia sunt greu de definit
sau de neles iar soluia este greu de
realizat
Importana strategic Doar de interes intern al unui
departament
Are impact asupra unor departamente ale
instituiei i/sau relaionat cu strategia
general a instituiei
Afecteaz desfurarea/oferirea serviciilor
de baz ale instituiei i are relaie direct
cu strategia general a instituiei
Cost total < 25.000 25.000 250.000 250.000+
Nivel de implementare Implic un singur departament Implic mai multe departamente Implic toat instituia , mai multe instituii
, mai multe nivele de administraie
Dependine i proiecte
inter-relaionate
Nici o dependen major sau
influene asupra / dinspre alte
proiecte
Cteva dependene majore sau influene
asupra/dinspre alte proiecte dar considerate
de risc minim
Dependene majore cu risc nalt sau
influene asupra/dinspre alte proiecte


Informatice

Pagina 74 din 87
Tabelul se va utiliza prin selectarea coloanelor n conformitate cu situaia existent. Dup analiza acestor selecii se va putea spune ce fel de
dimensiune are proiectul respectiv.
Un proiect poate fi considerat MARE atunci cnd o selecie indic c proiectul implic toat instituia, mai multe instituii, mai multe nivele
de administraie, sau atunci cnd exist dou sau mai multe coloane selectate n rubrica MARE.
Un proiect poate fi considerat MEDIU atunci cnd exist patru sau mai multe coloane selectate in rubrica MEDIU, sau atunci cnd exist o
selecie din rubrica MARE i 3 sau mai multe coloane selectate n rubrica MEDIU.
Un proiect MIC acoper celelalte combinaii de selecii .


Informatice

Pagina 75 din 87
9.3 Anexa 3: Livrabilele de Management ale Proiectului


Informatice

Pagina 76 din 87
9.4 Anexa 4: Descrierea principalelor roluri din proiect
9.4.1 Comitetul de Conducere al Proiectului
9.4.1.1 Reprezentantul Beneficiarului
Reprezentantul Beneficiarului este direct responsabil de rezultatele proiectului, avnd
sprijinul Reprezentanilor Utilizatorului i al Furnizorului. El trebuie s se asigure c
proiectul va furniza avantajele economice scontate, la nivelul investiiei fcute, i c
obiectivele iniiale ale proiectului sunt conservate pe toat durata derulrii acestuia. n
ndeplinirea acestor sarcini, Reprezentantul Beneficiarului trebuie s poat realiza o balan
just ntre interesele organizaiei, ale utilizatorilor i ale furnizorului. n unele cazuri
persoana desemnat pentru acest rol realizeaz i legtura cu structurile superioare de
conducere ale organizaiei, oferind astfel vizibilitate proiectului la nivelul cel mai nalt.
Responsabiliti:
s asigure c sunt stabilite toleranele pentru proiect
autorizeaz plile i stabilete toleranele pentru etape
valideaz Raportul de Sfrit al Proiectului realizat de Managerului de Proiect
informeaz conducerea instituiei despre progresul proiectului
stabilete i conduce ntlnirile Comitetului de Conducere a Proiectului
recomand conducerii instituiei planul de aciuni, atunci cnd s-au depit toleranele
proiectului
aprob notificarea de nchidere a proiectului trimis conducerii instituiei

Reprezentantul Beneficiarului este responsabil de atingerea obiectivelor proiectului, mai
exact acesta trebuie s asigure: meninerea proiectului n limitele stabilite conform
planificrii iniiale, livrarea produselor care s aduc beneficiile economice asteptate i
nchiderea proiectului respectnd constrngerile de buget i timp agreate. Asigurarea
succesului proiectului acoper:
validarea i monitorizarea Justificrii Economice a Proiectului, innd cont de
evenimentele externe i de evolutia proiectului
meninerea proiectului n concordan cu strategia instituiei Clientului
monitorizarea financiar a proiectului pentru a avea permanent o imagine clar asupra
costului proiectului i asupra impactul acestuia asupra instituiei
monitorizarea evoluiei riscurilor proiectului pentru a se asigura c acestea sunt
meninute sub control
monitorizarea plilor efectuate ctre Furnizor
evaluarea impactului schimbrilor poteniale din proiect asupra Justificrii Economice a
Proiectului i a beneficiilor obinute de instituie
monitorizarea rezultatelor Etapei, n particular i a progresului proiectului, n general,
innd cont de toleranele stabilite.


Informatice

Pagina 77 din 87
9.4.1.2 Reprezentantul Utilizatorilor
Reprezentantul Utilizatorilor rspunde pentru producerea tuturor livrabilelor furnizate de
ctre utilizatori, cum ar fi asigurarea c cerinele funcionale au fost definite corect i
complet, c ceea ce va fi produs va fi util i va realiza beneficiile ateptate. De asemenea,
monitorizeaz faptul c soluia dezvoltat va rspunde cerinelor utilizatorilor n limita
constrngerilor Documentului de Justificare Economic a Proiectului.
Acest rol reprezint interesele tuturor celor care vor utiliza rezultatele finale ale proiectului,
ale celor care vor utiliza rezultatele proiectului n vederea atingerii unor obiective de
business, ale celor care vor realiza beneficii suplimentare utiliznd rezultatele proiectului,
precum i ale tuturor celor care vor fi afectai de rezulatele proiectului.
Responsabiliti:
asigur disponibilitatea resurselor necesare (din punctul de vedere al utilizatorilor)
aprob Descrierea Produselor pentru livrabilele intermediare sau finale realizate de ctre
Furnizor i care afecteaz utilizatorii n mod direct i valideaz produsele care au nevoie
de o aprobare din partea utilizatorului, imediat ce acestea au fost finalizate
prioritizeaz i prezint punctul de vedere al utilizatorului atunci cnd Comitetul de
Conducere al Proiectului ia decizii cu privire la implementarea schimbrilor propuse
prioritizeaz cerinele utilizatorilor i soluioneaz conflictele aprute
informeaz conducerea utilizatorilor asupra tuturor aspectelor importante din cadrul
proiectului.
asigurarea faptului c rezultatele proiectului ofer beneficiile ateptate de ctre
utilizatori

Responsabilitile Reprezentantului Utilizatorilor referitoare la asigurarea succesului
proiectului sunt:
s se asigure c specificaiile utilizatorilor sunt complete, corecte i uor de neles
s se asigure c rezultatele pe care proiectul le produce rspund cerinelor exprimate de
utilizatori
s evalueaze impactul potenialelor schimbri din prisma utilizatorului
s monitorizeze evoluia riscurilor, in special a celor aflate sub controlul sau n
responsabilitatea utilizatorilor
verific prin inspecii dac produsele ndeplinesc cerintele utilizatorilor pe parcursul
tuturor etapelor proiectului
verific dac procedurile de control al calitii sunt folosite corect pentru a asigura
concordana produselor cu cerinele utilizatorilor
9.4.1.3 Reprezentantul Furnizorului
Rolul Reprezentantului Furnizorului este acela de a asigura realizarea rezultatelor solicitate
de Reprezentantul Utilizatorilor i agreate formal cu Reprezentantul Beneficiarului.
Reprezentantul Furnizorului este responsabil pentru calitatea tuturor produselor i serviciilor
livrate de ctre furnizor. Ca parte a acestei responsabiliti, el trebuie s se asigure c
propunerile privind proiectarea i dezvoltarea produselor sunt realiste, adic ele vor atinge
obiectivele solicitate de ctre Reprezentantul Utilizatorilor n cadrul constrngerilor de timp
i de buget fixate de ctre Reprezentantul Beneficiarului. Acest rol reprezint interesele


Informatice

Pagina 78 din 87
tuturor celor care proiecteaz, dezvolt, procur i implementeaz produsele furnizate i
trebuie s aib nivelul de autoritate necesar pentru a implica sau a obine resursele necesare
din partea Furnizorului.
Responsabiliti:
s agreeze obiectivele pentru activitile furnizorului
s asigure faptul c, din perspectiva furnizorului, progresul proiectului este corelat cu
rezultatele produse
asigur disponibilitatea resurselor necesare n proiect (din puncul de vedere al
furnizorului)
valideaz Descrierea Produselor pentru livrabilele produse de furnizor
prezint opiunile posibile ctre utilizator atunci cnd Comitetul de Conducere al
Proiectului ia decizii cu privire la implementarea schimbrilor propuse
prioritizeaz cerinele furnizorului i rezolv conflictele aprute

Reprezentantul Furnizorului este responsabil pentru aspectele tehnice specifice produselor
proiectului. Responsabilitile Reprezentantului Furnizorului referitoare la asigurare
succesului proiectului sunt:
particip la dezvoltarea strategiei i a metodelor ce vor fi folosite n cadrul proiectului
se asigur de faptul c standardele de execuie definite pentru proiect sunt ndeplinite
monitorizeaz schimbrile poteniale i impactul lor asupra corectitudinii,
completitudinii i integritii produselor
monitorizeaz toate riscurile din proiect care sunt legate de realizarea produselor
proiectului i se afl sub controlul i n responsabilitatea furnizorului
se asigur c procedurile de control al calitii sunt folosite corect pentru a asigura
concordana produselor cu cerinele.
9.4.2 Managerul de Proiect
Managerul de Proiect are autoritatea din partea Comitetului de Conducere al Proiectului de a
conduce activitile de proiect de zi cu zi, n cadrul limitelor de responsabilitate stabilite de
ctre Comitetul de Conducere al Proiectului.
Responsabilitatea principal a Managerului de Proiect este de a se asigura c proiectul
produce toate livrabilele necesare, n cadrul constrngerilor de timp i de buget i la
standardele de calitate stabilite. Rolul Managerului de Proiect nu este acela de a fi antrenat
n cadrul activitilor zilnice de proiect pentru producerea livrabilelor, ci acela de a delega
sarcinile i responsabilitile din cadrul proiectului astfel nct obiectivele acestuia s fie
atinse, pstrnd ns o viziune de ansamblu asupra strategiei proiectului i a evoluiei
acestuia i alocnd timp sarcinilor de planificare, monitorizare i control.
Responsibiliti specifice:
monitorizeaz realizarea produselor stabilite n aria de acoperire a proiectului
ndrum i motiveaz echipa de proiect
planific, monitorizeaz i controleaz proiectul pe toat derularea sa
accept delegarea unor responsabiliti din partea Comitetului de Conducere a
Proiectului legate de asigurarea succesului proiectului


Informatice

Pagina 79 din 87
ntocmete Documentele de Iniializare ale Proiectului
realizeaz Planul de Proiect i de Etap i, dac este necesar, Planul de Excepie
asigur managementul riscurilor pentru proiect, rspunde de producerea i revizuirea
planurilor de aciune sau de rezerv pentru riscuri i monitorizeaz evoluia riscurilor
proiectului
este direct responsabil de progresul proiectului i de resursele utilizate n cadrul acestuia
i iniiaz aciuni corective dac este necesar
este responsabil pentru procesul de controlul al schimbrii i de orice modificare
determinat de managementul configuraiei
raporteaz Comitetului de Conducere al Proiectului prin rapoarte periodice care s
prezinte rezultatul evalurii stadiului n cadrul etapelor proiectului
valideaz strategiile tehnice i de calitate alturi de membrii Comitetului de Conducere
al Proiectului
ntocmete la sfritul proiectului Raportul de Sfrit de Proiect
identific i obine sprijin i informaii necesare pentru urmrirea, planificarea i
controlul proiectului
este responsabil cu administrarea proiectului
menine relaia cu subcontractorii.
9.4.3 Coordonatorul de Proiect al Beneficiarului
Reprezentantul Beneficiarului i Reprezentantul Utilizatorilor nu sunt implicai n
permanen n derularea proiectului, deoarece au n sarcina lor si activitile curente ale
instituiei. n monitorizarea evoluiei proiectului acetia se bazeaz pe informaiile primite
de la Managerul de Proiect, care le trimite periodic rapoarte de informare.
Pentru a realiza coordonarea proiectului i pentru a avea n permanen o imagine obiectiv
asupra evoluiei proiectului, Reprezentanii Beneficiarului i ai Utilizatorilor din Comitetul
de Conducere al Proiectului au nevoie i de un punct de vedere independent de al
Managerului de Proiect, care n principiu reprezint interesele Furnizorului. Un astfel de
punct de vedere alternativ este reprezentat de Coordonatorul de Proiect al Beneficiarului.
ntre Managerul de Proiect i Coordonatorul de Proiect al Beneficiarului nu exist o relaie
de subordonare.
Sarcinile de monitorizare ale Coordonatorului de Proiect al Beneficiarului pot acoperi
urmtoarele zone ale proiectului:
integritatea Justificrii Economice a proiectului pe ntreaga durat a derulrii sale
respectarea standardelor i a procedurilor stabilite i aprobate de ctre Comitetul de
Conducere al Proiectului
conservarea i atingerea obiectivelor Utilizatorilor proiectului
monitorizarea riscurilor n special ale celor care se afl sub controlul sau n rspunderea
instituiei beneficiarului
pstrarea obiectivelor iniiale ale proiectului i evitarea deviaiilor de la aceste obiective
implicarea persoanelor necesare n proiect din instituia beneficiarului i a utilizatorilor
meninerea viabilitii proiectului


Informatice

Pagina 80 din 87
comunicarea cu Comitetul de Conducere al Proiectului prin prezentarea unor puncte de
vedere referitor la rapoartele naintate de ctre Managerul de Proiect
observarea unor constrngeri legislative i sesizarea acestora
respectarea standardelor de calitate stabilite
asigurarea faptului c cerinele utilizatorilor i ateptrile acestora sunt luate n
considerare de furnizor i ndeplinite n limita ariei de acoperire a proiectului

Coordonatorul de Proiect al Beneficiarului trebuie fie un angajat din cadrul organizaiei
Beneficiarului sau/i a Utilizatorilor i care s aib cunostine i experien de management
de proiect. n anumite situaii ns acesta poate beneficia de ajutorul unor consultani
independeni, externi, contractai de ctre Comitetul de Conducere al Proiectului.


Informatice

Pagina 81 din 87
9.5 Anexa 5: Model de Curriculum Vitae n conformitate cu HGR 1012/25.06.2004

Model de Curriculum Vitae European | <numele aplicantului>
|
|
INFORMAII PERSONALE |
Nume | (Nume, prenume)
|
Adres | (numrul, strada, cod potal, ora,
| ara)
Telefon |
|
Fax |
|
E-mail |
|
Naionalitate |
|
Data naterii | (ziua, luna, anul)
|
EXPERIEN PROFESIONAL | (Menionai pe rnd fiecare experien
| profesional pertinent, ncepnd cu
| cea mai recent dintre acestea)
* Perioada (de la - pn la) |
|
* Numele i adresa angajatorului |
|
* Tipul activitii sau sectorul de |
activitate |
|
* Funcia sau postul ocupat |
|
* Principalele activiti i |
responsabiliti |
|
EDUCAIE I FORMARE |
* Perioada (de la - pn la) | (Descriei separat fiecare form de
| nvmnt i program de formare
| profesional urmate, ncepnd cu cea
| mai recent)
* Numele i tipul instituiei de |
nvmnt i al organizaiei |
profesionale prin care s-a |
realizat formarea profesional |
|
* Domeniul studiat/aptitudini |
ocupaionale |
|
* Tipul calificrii/diploma |
obinut |
|
* Nivelul de clasificare a formei |
de instruire/nvmnt |
|
APTITUDINI I COMPETENE PERSONALE |
dobndite n cursul vieii i |
carierei dar care nu sunt |
recunoscute neaprat printr-un |
certificat sau o diplom |
|
Limba matern |
Limbi strine cunoscute | (Enumerai limbile cunoscute i
* abilitatea de a citi | indicai nivelul: excelent, bine,


Informatice

Pagina 82 din 87
* abilitatea de a scrie | satisfctor)
* abilitatea de a vorbi |
|
Aptitudini i competene artistice | (Descriei aceste aptitudini i
Muzic, desen, pictur, literatur | indicai contextul n care le-ai
etc. | dobndit)
|
Aptitudini i competene sociale | (Descriei aceste aptitudini i
Locuii i muncii cu alte persoane,| indicai contextul n care le-ai
ntr-un mediu multicultural, ocupai| dobndit)
o poziie n care comunicarea este |
important sau desfurai o |
activitate n care munca de echip |
este esenial. (de exemplu cultur,|
sport etc.) |
|
Aptitudini i competene | (Descriei aceste aptitudini i
organizatorice | indicai n ce context le-ai
De exemplu coordonai sau conducei | dobndit)
activitatea altor persoane, proiecte|
i gestionai bugete; la locul de |
munc, n aciuni voluntare (de |
exemplu n domenii culturale sau |
sportive) sau la domiciliu. |
|
Aptitudini i competene tehnice | (Descriei aceste aptitudini i
(utilizare calculator, anumite | indicai n ce context le-ai
tipuri de echipamente, maini etc.) | dobndit)
|
Permis de conducere |
|
Alte aptitudini i competene | (Descriei aceste aptitudini i
Competene care nu au mai fost | indicai n ce context le-ai
menionate anterior | dobndit)
|
INFORMAII SUPLIMENTARE | (Indicai alte informaii utile i
| care nu au fost menionate, de exemplu
| persoane de contact, referine etc.)
|
ANEXE | (Enumerai documentele ataate
| CV-ului, dac este cazul).


Informatice

Pagina 83 din 87
9.6 Anexa 6: Formular de diagnoz

Management-ul Proiectelor IT
in Administratia Publica
- document de analiza -

Sectiune explicativa:
Scopul urmatorului chestionar este acela de a identifica problemele tipice ale proiectelor IT
derulate in cadrul Administratiei Publice din Romania care pot fi rezolvate prin
implementarea unui sistem mai eficient de Management al Proiectelor atat din partea
furnizorului cat si din partea organizatiei client. Va rugam sa raspundeti la intrebarile din
urmatorul chestionar folosind pe cat posibil fraze explicative (nu numai da si nu). Acest
lucru ne va permite sa analizam in profunzime problemele reale cu care va confruntati si sa
putem identifica cele mai eficiente metode de rezolvare.
Va multumim.

9.6.1 INTRODUCERE

1. Care este numarul de proiecte IT derulate in cadrul organizatiei dumneavoastra in ultimii 5 ani? Dati
detalii.

2. Care sunt caracteristicile proiectelor IT derulate in cadrul organizatiei dumneavoastra (ex. Buget,
durata, tip proiect achizitie de echipamente sau licente standard, solutie software, sistem integrat
hard-soft)?

3. Ce tipuri de proiecte de implementare de aplicatii software ati derulat sau intentionati sa derulati (ex.:
Sistem Financiar-Contabil, Resurse Umane si Salarizare, Taxe si Impozite, Management-ul
documentelor si al fluxului de documente, arhivare electronica, solutii geospatiale GIS, portal WEB,
altele)?

4. Ce intelegeti prin Project Management?

5. Considerati ca Management-ul Proiectului conform unei metodologii recunoscute si testate poate
influenta in mod pozitiv succesul unui proiect? Daca da, in ce fel?

6. Cine considerati ca are rolul principal in coordonarea proiectului: furnizorul sau beneficiarul? Va
rugam comentati.

7. In contextul intrebarii nr. 5, care credeti ca sunt indatoririle principale ale furnizorului si ale
beneficiarului (din punctul de vedere al conducerii proiectului)?

8. Exista personal in cadrul organizatiei dumneavoastra care sa fi beneficiat de cursuri de instruire in
domeniul Project Management-ului? Daca da, cate?
9. Criteriile de evaluare a ofertelor pe care le primiti de la potentialii furnizori includ si criterii care au
legatura cu capacitatea respectivului ofertant de a realiza Managament-ul proiectului? Daca da, care
este procentul de puncte pe care il acordati criteriilor de evaluare din perspectiva capabilitatii de
realizare a management-ului de proiect?


Informatice

Pagina 84 din 87
9.6.2 ORGANIZAREA PROIECTELOR

10. In momentul lansarii unui proiect, se nominalizeaza in mod formal o echipa de proiect din cadrul
organizatiei dumneavoastra, echipa care sa aiba responsabilitati clare in cadrul proiectului respectiv?

11. Care sunt conditiile de experienta (teoretica si practica) pe care le folositi pentru a alege persoana care
va fi responsabila cu coordonarea proiectului din partea organizatiei dumneavoastra?

12. In cazul unui proiect IT al carui beneficiar final nu este directia informatica, ci alte directii functionale
din cadrul organizatiei dumneavoastra, considerati ca persoana care va coordona proiectul din partea
organizatiei dumneavoastra trebuie sa fie un reprezentant al directiei informatice, sau un reprezentant al
directiei care va fi utilizatorul solutiei informatice achizitionate. Explicati raspunsul. Care este practica
in cadrul organizatiei dumneavoastra din acest punct de vedere?

13. Reprezentantii directiilor beneficiare a solutiilor informatice procurate sunt implicati in mod direct in
derularea proiectului? Daca da, in ce fel?

14. Daca pe parcursul implementarii proiectului aveti nevoie de o decizie a unei persoane din cadrul
organizatiei dumneavoastra care sa poata aloca resurse proiectului sau care sa ia o decizie atunci cand
membrii echipei de proiect nu pot sau nu vor sa ia o astfel de decizie, care este persoana la care apelati?

15. Care sunt parghiile pe care la aveti la indemana la nivelul proiectului pentru a face vizibila o problema
de proiect care necesita o astfel de decizie a unui esalon superior? Care sunt metodele pe care le
utilizati pentru a fi sigur ca o anumita decizie care poate afecta proiectul va fi luata in timp util?

16. Furnizorii selectionati in cadrul proiectelor dumneavoastra nominalizeaza in mod formal o echipa de
proiect condusa de un Project Manager care sa fie persoana unica de contact si care sa coordoneze
intreaga echipa a furnizorului?

17. Considerati ca reprezentantii furnizorilor dumneavoastra care coordoneaza echipele de implementare in
cadrul unor proiecte de complexitate medie si mare au pregatirea teoretica si practica de a o face?

18. Solicitati furnizorilor dumneavoastra prezentarea in cadrul ofertei tehnice a unei metodologii de
management de proiect care va fi utilizata pe parcursul proiectului (continand aspecte de organizare a
proiectului, de planificare si control, de management al calitatii, de management al riscurilor, de
management al schimbarii)?

19. Solicitati furnizorilor dumneavoastra includerea in cadrul ofertei tehnice a CV-ului persoanei care va fi
responsabila cu Management-ul Proiectului din partea Furnizorului?

20. Includeti in cadrul caietelor de sarcini pe care le pregatiti in vederea achizitionarii unor proiecte
informatice cerinte specifice referitoare la pregatirea teoretica si practica in domeniul Management-ului
de Proiect pe care trebuie sa le indeplineasca reprezentantul Furnizorului care va fi responsabil cu
Management-ul Proiectului?

21. Caietele de Sarcini pe care le pregatiti prevad in mod explicit responsabilitatea conducerii proiectului
(a sarcinilor si a responsabilitatilor organizatiilor furnizor si beneficiar)?

22. Caietele de sarcini pe care le pregatiti prevad in mod explicit identificarea costurilor de Project
Management pe intreaga durata a proiectului?


Informatice

Pagina 85 din 87
9.6.3 PLANIFICAREA PROIECTELOR

23. Solicitati furnizorilor dumneavoastra prezentarea unui grafic de implementare care sa contina toate
etapele proiectului si suficiente detalii despre activittile individuale care vor trebui realizate pentru
finalizarea proiectului?

24. Graficele de implementare folosite in cadrul proiectelor dumneavoastra identifica urmatoarele detalii
pentru fiecare activitate din cadrul planului: data de inceput, durata, dependentele logice de finalizarea
unor alte activitati din proiect, responsabilitatea realizarii activitatii (furnizor sau beneficiar), resursele
asociate realizarii activitatilor?

25. Considerati ca planificarea unui proiect este utila? De ce?

26. Exista pareri larg raspandite conform carora planificarea detaliata a unui proiect in etapa imediat
premergatoare demararii sale nu este folositoare, intrucat intotdeauna vor aparea situatii neprevazute
care vor afecta acest plan si care il vor face inutil. Care este parerea dumneavoastra relativ la acest
aspect? Care este cea mai eficienta abordare a procesului de planificare?

27. Care sunt aspectele care considerati ca necesita planificare in cadrul unui proiect?

28. Considerati ca procesul de planificare a unui proiect este o sarcina exclusiva a furnizorului sau a
beneficiarului?

29. Folositi instrumente speciale de planificare in cadrul organizatiei dumneavoastra? Daca da, de ce fel si
care sunt acestea?

30. Furnizorii dumneavoastra folosese instrumente de planificare a proiectelor pe care le deruleaza? Daca
da, care sunt acestea?

9.6.4 CONTROLUL PROIECTELOR

31. Ce modalitati de control folositi in cadrul proiectelor pe care organizatia dumneavoastra le deruleaza
(ex. Sedinte de identificare a progresului, sedinte de rezolvare a problemelor, sedinte de control cu
furnizorii, sedinte de raportare catre conducere, rapoarte scrise, scrisori etc.)? Va rugam dati exemple.

32. Considerati ca detineti toate parghiile necesare pentru a controla in mod eficient un proiect? Daca nu,
de ce?

33. Contractele pe care le incheiati contin suficiente detalii care sa va permita un control eficient al
proiectelor (ex.: identificarea clara a tuturor produselor, licentelor, echipamentelor, serviciilor,
documentelor care trebuie produse, identificarea fara echivoc a responsabilitatilor partilor si a
dependentelor reciproce, identificarea in mod explicit a metodelor de acceptare pentru echipamente,
licente, servicii, documente etc., identificarea explicita a tuturor testelor care vor trebui realizate
inaintea acceptarii unui produs/serviciu, responsabilitatile privind controlul si raportarea progresului
etc.)?

34. Furnizorii dumneavoastra includ in ofertele lor detalii referitoare la aspectele enumerate cu titlu de
exemplu in cadrul intrebarii nr. 32?

35. Odata cu semnarea Contractului pentru implementarea unui proiect, care din documentele
precontractuale (cerere de oferta, oferta, etc.) sunt preluate in cadrul Contractului?

36. In cazul in care, pe langa aspectele de legislatie si de clauze generale ale unui Contract, acesta prevade
si inglobarea unor documente precontractuale, se include si o clauza care sa prevada ordinea in care


Informatice

Pagina 86 din 87
diferitele documente care fac parte din Contract vor fi interpretate (ex.: primeaza cererea de oferta sau
oferta, primeaza clauzele din contractul principal sau conditiile puse de ofertant in oferta sa etc.)?

37. Vi s-a intamplat sa aveti neintelegeri cu furnizorii dumneavoastra datorita interpretarii diferite a
atributiilor partilor, sau datorita intelegerii diferite a ceea ce trebuie livrat sau a modului in care trebuie
livrat, sau a modalitatii in care se va face testarea si acceptarea? Va rugam dati exemple.

38. Daca raspunsul la intrebarea 36 a fost pozitiv, cum credeti ca ar fi putut fi evitate aceste neintelegeri?

9.6.5 MANAGEMENT-UL CALITATII

39. Ce intelegeti prin Calitate intr-un proiect?

40. Caietele de sarcini pe care le elaborati contin criterii de calitate pentru fiecare din livrabilele
proiectului?

41. Care credeti ca sunt categorii de criterii de calitate care se pot aplica urmatoarelor tipuri de livrabile:
echipamente, licente software, servicii de analiza, servicii de implementare, servicii de instruire,
servicii de suport si asistenta tehnica, documente tehnice, documente de analiza, rapoarte, grafice de
implementare. Va rugam sa dati exemple pentru fiecare din aceste categorii de livrabile tipice ale unui
proiect.

42. Folositi in mod activ in cadrul proiectelor dumneavoastra criteriile de calitate pe care le-ati identificat
in raspunsul la intrebarea 40? Daca nu, de ce?

43. Solicitati in cadrul Caietului de Sarcini prezentarea de catre furnizor a modalitatii practice in care va
asigura calitatea livrabilelor proiectului?

44. Furnizorii dumneavoastra prezinta in cadrul ofertelor tehnice modalitatea practica in care vor asigura
calitatea pe perioada derularii proiectului?

45. Considerati ca includerea in cadrul Caietelor de Sarcini a unor criterii de calitate detaliate impuse, sau
ca stabilirea pe durata proiectului a acestora poate ajuta la evitarea neintelegerilor intre furnizor si
beneficiar in etapa de acceptare a livrabilelor proiectelor?

46. Care sunt tipurile de criterii pe baza carora realizati in cadrul proiectelor dumneavoastra curente
testarea si acceptarea livrabilolor proiectelor? Ce tipuri de teste realizati? Cum realizati acceptarea
serviciilor de implementare? Dar a celor de instruire? Cum realizati acceptarea livrabilelor de tip
documente? Va rugam sa dati exemple.

9.6.6 MANAGEMENT-UL SCHIMBARII

47. Folositi in cadrul proiectelor pe care le derulati o procedura speciala de tratare a cazurilor in care
trebuie operate modificari in cadrul activitatilor sau al livrabilelor stabilote in cadrul proiectului (ex.:
introducerea unei noi functionalitati, a unui nou raport sau modificarea unuia existent, a continutului
unui curs sau a unui document deja aprobat)?

48. Daca raspunsul la intrebarea de mai sus este pozitiva, atunci va rugam sa descrieti pe scurt continutul
acestei proceduri.

49. Care componente ale proiectului credeti ca ar trebui supuse controlului schimbarii?


Informatice

Pagina 87 din 87
50. Credeti ca birocratia suplimentara introdusa de utilizarea unei proceduri scrise si de documentara
exacta a tuturor elementelor unei schimbari (ex.: originator, motiv, implicatii, solutia propusa, riscuri,
momentul propus pentru realizarea schimbarii etc.) este justificata din perspectiva beneficiilor pe care o
astfel de abordare le poate aduce?

51. Cine credeti ca ar trebui sa aprobe implementarea unor schimbari in cadrul proiectului?

52. Care abordare credeti ca este mai buna (va rugam sa comentati):
a. implementarea imediata a unui mare numar de schimbari pe perioada implementarii proiectului,
chiar daca acest lucru duce la decalarea semnificativa a calendarului de implementare, la intarzierea
aparitiei beneficiilor proiectului si potential la pierderea rabdarii utilizatorilor potentiali ai
proiectului, sau
b. implementarea proiectului in conditiile agreate si planificate initial si implementarea diferitelor
schimbari ulterior finalizarii proiectului, ca imbunatatiri, daca acestea nu afecteaza in mod critic
functionalitatea necesara utilizatorilor?

53. In contextul intrebarii 52, care abordare considerati ca este mai buna: o solutie perfecta, cu riscul
intarzierii substantiale a datei de finalizare a proiectului, sau o solutie functionala rapid si imbunatatirea
ulterioara a acesteia? Va rugam comentati avantajele si dezavantajele fiecarei abordari.

9.6.7 MANAGEMENT-UL RISCULUI

54. Ce intelegeti prin Management-ul Riscurilor in cadrul unui proiect?

55. Cine considerati ca are responsabilitatea realizarii management-ului riscurilor in cadrul unui proiect:
furnizorul sau beneficiarul? Comentati.

56. Folositi in cadrul proiectelor dumneavoastra o procedura formala de realizare a management-ului
riscurilor, care sa descrie modalitatea de realizarea a: identificarii riscurilor, a probabilitatii de aparitie
si a impactului in cazul aparitiei, a planificarii activitatilor de prevenire si a celor de recuperare in cazul
materializarii riscului, a controlului riscurilor etc.?

57. Furnizorii dumneavoastra folosesc o astfel de metoda descrisa la intrebarea 56?

58. Cine considerati ca are responsabilitatea identificarii si a controlului riscurilor interne organizatiei
dumneavoastra dar externe proiectului si care pot afecta in mod negativ proiectul (ex. Desfasurarea
unui alt proiect paralel care poate duce la conflicte de integrare, sau la accesul dificil la resursele
necesare etc.)

59. Care sunt modalitatile concrete prin care puteti controla riscuri interne organizatiei dumneavoastra, de
tipul: indisponibilitatea reprezentantilor utilizatorilor care trebuie sa participe la activitatiloe de proiect,
prelungirea excesiva (chiar daca justificata) a timpului necesar revizuirii si aprobarii unor livrabile de
proiect din cauza timpului insuficient acordat proiectului de catre membrii echipei de proiect.

Ghid - Metodologic Licitatii Informatice

Încărcat de

Informații document

Titlu original

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

Ghid - Metodologic Licitatii Informatice

Încărcat de

Drepturi de autor:

Formate disponibile

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul

S-ar putea să vă placă și