Ghid Metodologic Pentru Managementul Proiectelor TIC

Faster and Better E-Government Solutions
Ghid Metodologic pentru Managementul Proiectelor Informatice
TITLU:

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.
DESCRIERE:
AUTORI:
n acest context, documentul cuprinde recomandri n vederea organizrii i conducerii proiectelor informatice derulate n cadrul Administraiei Publice Locale din Romnia. 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
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.
Pagina 1 din 87
Coninut:
1.
1.1 1.2 1.3 1.4 1.5
CONTROLUL DOCUMENTULUI
Proprietarul documentului Istoricul documentului Modificri viitoare Bibliografie Abrevieri
5
5 5 5 5 5
2.
2.1 2.2 2.3
INTRODUCERE
Necesitate Structur i obiective Grup int
6
6 6 7
3. ANALIZA SITUAIEI EXISTENTE CU PRIVIRE LA IMPLEMENTAREA PROIECTELOR TIC

3.1 Introducere 9 10 11 12 12 13
8
8 9
3.2 Categorii de probleme identificate 3.2.1 Probleme identificate n organizarea proiectelor 3.2.2 Probleme identificate n planificarea proiectelor 3.2.3 Probleme identificate n controlul proiectelor 3.2.4 Probleme identificate n managementul calitii 3.2.5 Probleme identificate n managementul schimbrilor i al configuraiilor 3.2.6 Probleme identificate n managementul riscului 3.3 Concluzii
14
4. DOCUMENTE ELABORATE N VEDEREA LANSRII PROIECTELOR

4.1 Introducere 15 16
15
15 15
4.2 Etapele demarrii proiectului 4.2.1 Etapa pregtitoare 4.2.2 Etapa de achiziie 4.3 Modele de documente
17
5.
5.1
METODOLOGIA DE MANAGEMENT AL PROIECTELOR

Introducere
18
18
Pagina 2 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 Ce este un proiect? De ce proiectele au nevoie de management? Arie de aplicabilitate Alte precizri Organizarea acestei seciuni 18 18 18 19 19 20 20 26 31 39 42 44 46
5.2 Noiuni de baz privind managementul de proiect 5.2.1 Organizarea proiectului 5.2.2 Planificarea proiectului 5.2.3 Controlul proiectului 5.2.4 Management-ul Riscurilor 5.2.5 Calitatea 5.2.6 Management-ul Configuraiilor 5.2.7 Controlul Schimbrii
6. CAIETUL DE SARCINI CERINE SPECIFICE PRIVIND MANAGEMENTUL PROIECTELOR

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 Organizarea proiectului (vezi 5.2.1) Planificarea proiectului (vezi 5.2.2) Controlul proiectului (vezi 5.2.3) Management-ul riscurilor (vezi 5.2.4) Calitatea (vezi 5.2.5) Management-ul configuraiilor (vezi 5.2.6) Controlul schimbrii (vezi 5.2.7) Criterii de evaluare a ofertelor
48
48 49 50 53 53 54 54 55
7.
7.1 7.2
ALTE RECOMANDRI
Clauze contractuale Recomandri diverse 62 63 63
56
56 60 62
7.3 List de verificare a documentelor de proiect 7.3.1 Iniializarea proiectului 7.3.2 Planificare 7.3.3 Raportare
8. 9.
9.1 9.2
GLOSAR DE TERMENI ANEXE

Anexa 1: Propunerea de Proiect Anexa 2: Determinarea dimensiunii proiectelor
64 66
67 73
Pagina 3 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 9.3 Anexa 3: Livrabilele de Management ale Proiectului 76 78 79 81 83 83 84 85 85 86 86 87 75 76
9.4 Anexa 4: Descrierea principalelor roluri din proiect 9.4.1 Comitetul de Conducere al Proiectului 9.4.2 Managerul de Proiect 9.4.3 Coordonatorul de Proiect al Beneficiarului 9.5 Anexa 5: Model de Curriculum Vitae n conformitate cu HGR 1012/25.06.2004
9.6 Anexa 6: Formular de diagnoz 9.6.1 INTRODUCERE 9.6.2 ORGANIZAREA PROIECTELOR 9.6.3 PLANIFICAREA PROIECTELOR 9.6.4 CONTROLUL PROIECTELOR 9.6.5 MANAGEMENT-UL CALITATII 9.6.6 MANAGEMENT-UL SCHIMBARII 9.6.7 MANAGEMENT-UL RISCULUI
Pagina 4 din 87
1.
CONTROLUL DOCUMENTULUI
1.1 Proprietarul documentului Acest document a fost elaborat de ctre ANIAP. 1.2 Istoricul documentului Revizia Ver. 00.01 Ver. 00.02 Data reviziei 04.07.2005 15.07.2005 Autor ANIAP ANIAP Sumarul schimbrilor Prima versiune pentru discuii A doua versiune dup seminarul ANIAP. ncorporarea tuturor observaiilor i reorganizarea documentului. Versiunea final pentru revizia ANIAP. Revizia final versiunea 1.0
Ver. 00.03 Ver. 1.00 1.3 Modificri viitoare
16.07.2005 18.07.2005
ANIAP ANIAP
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 RaduPractica 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 5 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 6 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 7 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 eGovernment 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 8 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 9 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 Principalele probleme identificate pentru aceast component sunt urmtoarele: 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 Cauzele care produc aceste probleme sunt n general urmtoarele:
Pagina 10 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 Principalele probleme identificate pentru aceast component sunt urmtoarele: 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 Cauzele care produc aceste probleme sunt n general urmtoarele: 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 11 din 87
3.2.4 Probleme identificate n managementul calitii Principalele probleme identificate pentru aceast component sunt urmtoarele: 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 Cauzele care produc aceste probleme sunt n general urmtoarele: 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 Principalele probleme identificate pentru aceast component sunt urmtoarele: 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 Cauzele care produc aceste probleme sunt n general urmtoarele: dei este acceptat de marea majoritate a intervievailor c existena unei proceduri scrise care s documenteze exact toate elementele unei schimbari este
Pagina 12 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 Principalele probleme identificate pentru aceast component sunt urmtoarele: 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 furnizorbeneficiar n urma manifestrii unor riscuri realizarea unor compromisuri relativ la calitatea unor livrabile datorit apariiei unor probleme care nu au fost prevzute Cauzele care produc aceste probleme sunt n general urmtoarele: 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 13 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 14 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 15 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 16 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 17 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 Organizarea proiectului Planificare Managementul riscurilor Managementul calitii MIC Sumar Sumar Sumar Sumar MEDIU MARE Detaliat Detaliat Sumar Detaliat Detaliat Detaliat Detaliat Detaliat
Pagina 18 din 87
Controlul proiectului Managementul configuraiilor
Sumar Sumar
Detaliat Sumar
Detaliat 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 19 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 20 din 87
Reprezentant Utilizator
Reprezentant Beneficiar
Reprezentant Furnizor
Comitetul de Conducere al Proiectului Asigurarea Controlului Proiectului Coordonator Proiect
Manager Proiect Echipa de Suport a Proiectului
Rol 1 Rol 2
Rol 3 Rol 4
Sef Echipa
Sef Echipa
Rol 1 Rol 2 Rol 3
Rol 1 Rol 2 Rol 3
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
Pagina 21 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 22 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 23 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 24 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 25 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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 26 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 Excepie
Plan de Lucru al Echipei
Figura 3: Nivelurile de planificare ntr-un proiect
Pagina 27 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 28 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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 29 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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 30 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 31 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 32 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.
Limite de Toleran
Planul de proiect iniial
Timp
Limite de Toleran Planul de proiect curent Cost Figura 4: Toleranele proiectului
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
Pagina 33 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 subcontracta 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 ntro 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 34 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 35 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 36 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 37 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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 38 din 87
5.2.4 Management-ul Riscurilor Management-ul riscurilor reprezint o component esenial n cadrul managementului 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 o o o o o o o eecul identificrii unor furnizori corespunztori; eecul livrarii produselor de ctre furnizori i sub-contractori; probleme contractuale. responsabiliti adiionale pentru personalul din proiect, pe lng activitile de proiect; cultura educaional (sau lipsa ei) din cadrul organizaiei Beneficiarului; probleme de instruire sau de experien a personalului; abiliti tehnice insuficiente ale membrilor echipei de proiect; conflicte de cultur organizaional ntre echipele Furnizorului i Beneficiarului. ct de bine sunt formulate cerinele; probleme legate de tehnologie (noutatea tehnologic); imposibilitatea realizrii unor specificaii sau omiterea unor specificaii; problemele legate de testarea calitii.
factori organizaionali:
probleme tehnice (elemente specifice de proiect): o o o o
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 39 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 Reducere prin aceast aciune se reduce probabilitatea materializrii riscului sau se limiteaz impactul su la un nivel acceptabil Transfer aceast aciune este una de reducere prin care impactul riscului se transfer ctre o ter parte (ex. Poli de asigurare) Msuri de rezerv n acest caz aciunile se planific astfel nct s se aplice n momentul apariiei riscului 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.
o o
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 40 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 41 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 42 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 43 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 44 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 (Administratorul Configuraiilor) cu Management-ul 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 45 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 46 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.
Pagina 47 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
Pagina 48 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 o o obiectivele proiectului aria de cuprindere a proiectului prezentarea modalitii generale de abordare (folosirea de produse comerciale, configurare sau dezvoltarea de aplicaii de la zero, echip proprie sau subcontractare etc.) livrabilele proiectului (produse, servicii, documentaie etc.) i alte rezultate ateptate excluderi (ce nu face parte din proiect) constrngeri interfee cu alte proiecte
o o o o
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 o o o o o o o o o identificarea prilor implicate n proiect necesarul de informaie sursa informaiilor frecvena comunicrii i coninutul comunicrii responsabilitile referitoare la asigurarea calitii referina la standardele care trebuie respectate identificarea criteriilor cheie de calitate care trebuie atinse metodele de control i audit pentru calitatea produselor de management de proiect i a celor tehnice specializate procedura pentru management-ul schimbrii
Planul de Calitate al Proiectului
Pagina 49 din 87
o o
planul pentru management-ul configuraiilor alte instrumente pentru asigurarea calitii
Planul Iniial de Proiect, care va prezenta cum i cnd vor avea loc activitile proiectului o o o o Descrierea planului i a activitilor acoperite de plan Dependene externe Ipoteze de planificare 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. Structura Defalcat a Livrabilelor proiectului (Product Breakdown Structure) fiele cu Descrierea Livrabilelor Pachetele de Lucru Resursele necesare Resursele necesare din partea Beneficiarului
o o o o o
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:
Pagina 50 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
Pagina 51 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
Pagina 52 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,
Pagina 53 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
Pagina 54 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 Organizarea proiectului Manager de Proiect Echipa de proiect Documentele de iniializare ale Proiectului Planul de Calitate Planul de Riscuri Planul de Proiect Descrierea Livrabilelor Diagrama Gantt Controlul proiectului (inclusiv raportarea) Planul de Acceptan Planul detaliat al primei Etape 5 10 10 10 10 15 10 15 20 10 60 100 30
Pagina 55 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).
Pagina 56 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
Pagina 57 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.
Pagina 58 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 o o o o o Anexa 1 Anexa 2 Anexa 3 Anexa 4 Anexa 5 Anexa 6 - Descrierea Produselor - Descrierea Serviciilor - Lista de Preuri - Graficul de ndeplinire - Obligaii Specifice (Dependene) - 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.
Pagina 59 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: o preedinte, vicepreedinte, primar, viceprimar pentru proiecte complexe director general, director executiv pentru proiecte cu sfer de cuprindere limitat la nivelul unei direcii sau departament director general, director executiv pentru proiecte complexe ef serviciu, ef birou - pentru proiecte cu sfer de cuprindere limitat la nivelul unei direcii sau departament general/manager general sau
Reprezentantul Utilizatorilor:
o o
Reprezentantul Furnizorului: director reprezentantul desemnat al acestuia
exemplul 1: implementarea unui sistem informatic integrat la nivelul instituiei: reprezentant beneficiar: viceprimar preedinte, vicepreedinte/ primar,
reprezentant utilizator: secretar general, director general, director direcie economic, arhitect ef, director direcie reprezentant furnizor: director general reprezentant beneficiar: director direcie economic reprezentant utilizator: ef serviciu contabilitate, ef serviciu buget reprezentant furnizor: director general
exemplul 2: implementarea unui sistem pentru eviden contabil
Pagina 60 din 87
Cerei ca studiul de studiul de fezabilitate s cuprind detaliat: o o Identificarea ariei de cuprindere a sistemului (subsistemele instituiile cuprinse) 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.) Identificarea tuturor costurilor care exist ntr-un subsistem legate de sistemul informatic existent, comunicaii etc. Identificarea tuturor proceselor existente i a proceselor de schimb informaional ntre procesele care sunt informatizate, necesitile de adaptare,integrare 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. Identificarea legislaiei n vigoare aplicabil fiecrui informaional i a schimburilor informaionale dintre sisteme subsistem
o o
o o o o o
Identificarea metodelor de implementare a proiectului n regim de tip outsourcing, out-tasking etc. Previzionarea modificrilor legislative n context naional i internaional i impactul acestora asupra realizrii proiectului Identificarea standardelor aplicabile i recomandarea de soluii n contextul tendinelor de implementare la nivel naional sau internaional. 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) 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 Identificarea tuturor arhitecturilor de sistem posibile i recomandarea celor aplicabile Identificarea tuturor livrabilelor i a pachetelor de lucru (activiti), estimarea costurilor, duratelor de implementare i a punctelor de control Identificarea soluiilor pentru Planul de implementare pentru ca acesta s nu blocheze activitatea instituiei 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. Identificarea cerinelor minimale pentru Planul de calitate Identificarea cerinelor minimale pentru Planul de control i instrumentele acestuia
o o o o
o o
Pagina 61 din 87
o o
Identificarea cerinelor minimale pentru Planul de management al schimbrii Identificarea cerinelor minimale pentru asigurarea mentenanei postimplementare. Identificarea contractelor de tip Service Level Agreement (garantarea serviciilor i nivelul acestora) 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) Estimarea bugetului proiectului alctuit din suma bugetului de materiale i de resurse umane, bugetului de risc, bugetului de management Identificarea procentului de pli n avans, plata parial, plata final pentru a asigura un flux de numerar (cash flow) pozitiv 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 Identificarea formelor recuperare a investiiei (ROI) Identificarea rolurilor structurii de conducere i execuie n realizarea proiectului Identificarea soluiilor tehnice existente la diveri productori i a costului acestora. Realizarea unui studiu de impact al proiectului att asupra cetenilor ct i asupra funcionarilor instituiilor. Identificarea metodelor de instruire a personalului instituiilor n funcie de regimul de implementare Identificarea modalitilor de auditare postimplementare pentru a asigura utilizarea rezultatelor proiectului i dup finalizarea implementrii
o o o
o o o o o o
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
Pagina 62 din 87
Planul de Proiect, incluznd: o o o o o o o dependene ipoteze diagrama Gantt (calendar de proiect) Structura defalcat a livrabilelor Descrierea livrabilelor Pachetele de lucru 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
Pagina 63 din 87
8.
GLOSAR DE TERMENI
Termenul n limba englez Project Scope Project Library Project Schedule (Gantt Chart) Change Request Contingency Change Control Project Board sau Steering Committe Product description Project Initiation Document Escalation (process) Project Initiation Business Case Deliverable Configuration Management Project Manager Work Package Stage Plan Exception Plan Team Plan Project plan Project Prerequisites Project Issue Checkpoints Highlight Report Exception Report End Stage Report Project Closure Report la activitile Follow-on action Recomendations Project Baseline Risk Register Executive Senior Supplier Senior User Test Script Product Breakdown Structure
Termenul n limba romn Aria de Cuprindere a Proiectului Biblioteca de Proiect Calendar de proiect (Diagrama Gantt) Cerere de Schimbare Contramsur (referitor la risc) Controlul Schimbrii Comitet de Conducere al Proiectului Descrierea livrabilului Documentele de Iniializare ale Proiectului Escaladare (a unei probleme) Iniializarea Proiectului Justificarea economic a proiectului Livrabil Managementul Configuraiilor Manager de Proiect Pachet de Lucru Plan de Etap Plan de Excepie Plan de Lucru al Echipei Plan de Proiect Presupunere Problem de Proiect Puncte de Verificare Raport de Stare Raport de Excepie Raport de Sfrit de Etap Raportul de Sfrit al Proiectului Recomandrile nefinalizate cu privire
Referina proiectului Registrul Riscurilor Reprezentantul Beneficiarului Reprezentantul Furnizorului Reprezentantul Utilizatorului Scenariu de Test Structura Defalcat a Livrabilelor
Pagina 64 din 87
edin de Verificare a Calitii Toleranele Proiectului Verificarea de Sfrit de Etap Verificare Intermediar de Etap nchiderea Proiectului
Quality Review Project Tolerances End Stage Assessment MidStage Assessment Project Closure
Pagina 65 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
Pagina 66 din 87
9.1 Anexa 1: Propunerea de Proiect
Ctre: Ref.: Titlul proiectului: Beneficiar: Furnizor: Buget estimat (EUR): Durata estimat: Data: Semnturile membrilor Comitetului de Conducere al Proiectului Nume i prenume 1. 2. 3. Rezoluia: aprobat, fr comentarii aprobat cu comentarii (vezi anexa) mai sunt necesare informaii (vezi anexa) respins comentarii (vezi anexa) Data: Semnturi: Semntura Departamentul IT
Pagina 67 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 Obiectivul 1 Rezultatele proiectului Rezultatul 1 Rezultatul 2 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.)
Pagina 68 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: . ..
Pagina 69 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 Rezultatul 1
Activiti/ Subactiviti Activitatea 1.1 Subactivitatea 1.1.1 Subactivitatea 1.1.2. Activitatea 1.2. Subactivitatea 1.2.1
Data de ncepere
Data de sfrit
L1
L2
L3
L4
L5
L6
L7
L8
L9
Rezultatul 2 Punct de Control 1 Rezultatul 3 Punct de Control 2 ..
Activitatea 2.1. .
L1, L2, L3 etc. semnific luna n care se deruleaz activitatea respectiv.
Pagina 70 din 87
9. Matricea de alocare a resurselor (Completai Matricea de Analiz Logic conform tabelului de mai jos.)
Indicatori de msurare Metode de verificare a performanei Scopul proiectului: Obiectivele proiectului: Rezultatul 1: Activiti pentru Rezultatul 1 Resurse Costuri
Riscuri sau ipoteze
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
4
TOTAL
5=4 x 3
CHELTUIELI DE CAPITAL (investiii) Echipament Mobilier Soft Teren Cladiri Alte mijloace fixe
Pagina 71 din 87
CATEGORIA DE CHELTUIELI
UM
Cantitate
Preul unitar
4
TOTAL
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 (*) 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.) L1 L2 ... ... L9 Total
Pagina 72 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 Numrul de persoane 1 - 2 din echipa de proiect Durata Planificarea proiectului < 6 luni MEDIU 25 6 12 luni MARE 5+ > 12 luni
Planificarea etapelor proiectului Planificarea etapelor poate avea mici Data limit de realizare a etapelor abateri de la planificarea iniial dar data proiectului este ferm i nu poate fi este flexibil schimbat , iar planificarea etapelor nu este limit de realizare a acestora este ferm flexibil Problema este foarte uor Fie dificulti n nelegerea problemei , fie i problema i soluia sunt greu de definit neleas , soluia este uor de o soluie neclar , fie o soluie foarte greu sau de neles iar soluia este greu de realizat i ndeplinit de realizat realizat Doar de interes intern al unui Are impact asupra unor departamente ale Afecteaz desfurarea/oferirea serviciilor instituiei i/sau relaionat cu strategia de baz ale instituiei i are relaie direct departament general a instituiei cu strategia general a instituiei < 25.000 Implic un singur departament 25.000 250.000 Implic mai multe departamente 250.000+ Implic toat instituia , mai multe instituii , mai multe nivele de administraie
Complexitate
Importana strategic
Cost total Nivel de implementare
Dependine i proiecte Nici o dependen major sau Cteva dependene majore sau influene Dependene majore cu risc nalt sau influene asupra / dinspre alte asupra/dinspre alte proiecte dar considerate influene asupra/dinspre alte proiecte inter-relaionate proiecte de risc minim
Pagina 73 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 .
Pagina 74 din 87
9.3 Anexa 3: Livrabilele de Management ale Proiectului
Pagina 75 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.
Pagina 76 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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
Pagina 77 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 completitudinii i integritii produselor i impactul lor asupra corectitudinii,
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
Pagina 78 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
Pagina 79 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.
Pagina 80 din 87
9.5 Anexa 5: Model de Curriculum Vitae n conformitate cu HGR 1012/25.06.2004

| | | INFORMAII PERSONALE | Nume | | Adres | | Telefon | | Fax | | E-mail | | Naionalitate | | Data naterii | | EXPERIEN PROFESIONAL | | | * 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) | | | | * 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 | * abilitatea de a citi | Model de Curriculum Vitae European <numele aplicantului>
(Nume, prenume) (numrul, strada, cod potal, ora, ara)
(ziua, luna, anul) (Menionai pe rnd fiecare experien profesional pertinent, ncepnd cu cea mai recent dintre acestea)
(Descriei separat fiecare form de nvmnt i program de formare profesional urmate, ncepnd cu cea mai recent)
(Enumerai limbile cunoscute i indicai nivelul: excelent, bine,
Pagina 81 din 87

| | | Aptitudini i competene artistice | Muzic, desen, pictur, literatur | etc. | | Aptitudini i competene sociale | Locuii i muncii cu alte persoane,| ntr-un mediu multicultural, ocupai| 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 | organizatorice | De exemplu coordonai sau conducei | 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 | (utilizare calculator, anumite | tipuri de echipamente, maini etc.) | | Permis de conducere | | Alte aptitudini i competene | Competene care nu au mai fost | menionate anterior | | INFORMAII SUPLIMENTARE | | | | ANEXE | | * abilitatea de a scrie * abilitatea de a vorbi satisfctor) (Descriei aceste aptitudini i indicai contextul n care le-ai dobndit) (Descriei aceste aptitudini i indicai contextul n care le-ai dobndit)
(Descriei aceste aptitudini i indicai n ce context le-ai dobndit)
(Descriei aceste aptitudini i indicai n ce context le-ai dobndit)
(Descriei aceste aptitudini i indicai n ce context le-ai dobndit) (Indicai alte informaii utile i care nu au fost menionate, de exemplu persoane de contact, referine etc.) (Enumerai documentele ataate CV-ului, dac este cazul).
Pagina 82 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. 2. Care este numarul de proiecte IT derulate in cadrul organizatiei dumneavoastra in ultimii 5 ani? Dati detalii. 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)? 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)? Ce intelegeti prin Project Management? Considerati ca Management-ul Proiectului conform unei metodologii recunoscute si testate poate influenta in mod pozitiv succesul unui proiect? Daca da, in ce fel? Cine considerati ca are rolul principal in coordonarea proiectului: furnizorul sau beneficiarul? Va rugam comentati. In contextul intrebarii nr. 5, care credeti ca sunt indatoririle principale ale furnizorului si ale beneficiarului (din punctul de vedere al conducerii proiectului)? Exista personal in cadrul organizatiei dumneavoastra care sa fi beneficiat de cursuri de instruire in domeniul Project Management-ului? Daca da, cate? 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?
3.
4. 5. 6. 7. 8. 9.
Pagina 83 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?
Pagina 84 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
Pagina 85 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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?
Pagina 86 din 87
Ghid Metodologic pentru Managementul Proiectelor Informatice 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.
Pagina 87 din 87

Ghid Metodologic Pentru Managementul Proiectelor TIC

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ghid Metodologic Pentru Managementul Proiectelor TIC

Încărcat de

Drepturi de autor:

Formate disponibile

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

3. ANALIZA SITUAIEI EXISTENTE CU PRIVIRE LA IMPLEMENTAREA PROIECTELOR TIC

4. DOCUMENTE ELABORATE N VEDEREA LANSRII PROIECTELOR

METODOLOGIA DE MANAGEMENT AL PROIECTELOR

Faster and Better E-Government Solutions

6. CAIETUL DE SARCINI CERINE SPECIFICE PRIVIND MANAGEMENTUL PROIECTELOR

GLOSAR DE TERMENI ANEXE

Faster and Better E-Government Solutions

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Ver. 00.03 Ver. 1.00 1.3 Modificri viitoare

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

ANALIZA SITUAIEI EXISTENTE CU PRIVIRE LA IMPLEMENTAREA PROIECTELOR TIC

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

DOCUMENTE ELABORATE N VEDEREA LANSRII PROIECTELOR

Figura 1: Organizarea de proiect a Beneficiarului

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

METODOLOGIA DE MANAGEMENT AL PROIECTELOR

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Controlul proiectului Managementul configuraiilor

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Comitetul de Conducere al Proiectului Asigurarea Controlului Proiectului Coordonator Proiect

Manager Proiect Echipa de Suport a Proiectului

Rol 1 Rol 2 Rol 3

Rol 1 Rol 2 Rol 3

Figura 2: Organizarea proiectului

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions

Ghid Metodologic pentru Managementul Proiectelor Informatice

Faster and Better E-Government Solutions