ghid_metodologic

8/7/2019 Ghid_Metodologic

1/87

Faster and Better E-Government Solutions

Ghid Metodologic pentru ManagementulProiectelor Informatice

Pagina 1 din 87

Acest Ghid este proprietatea ANIAP i este oferit membrilor ANIAP precum i tuturor funcionarilor publiciimplicai n proiecte de Tehnologia Informaiilor i Comunicaii n scopul de a-i ajuta n scrierea Documenta ieiStandard pentru Elaborarea i Prezentarea Ofertei pentru aceste proiecte, precum i n derularea proiectelor. AcestGhid 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 laredactarea 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 ncadrul acestui Ghid sau modul n care acestea sunt utilizate.

TITLU: Ghid Metodologic pentru Managementul Proiectelor Informatice

DESCRIERE:

Aceast publicaie a fost tiprit cu sprijinul Ageniei Statelor Unite pentru

Dezvoltare Internaional,n cadrul contractului ARD Inc de "Asisten

acordatadministraiei publice locale",Contractul Nr. AEP-I-00-00-00016-00,

Comanda Nr. 810.Opiniile exprimate n cadrul ghidului aparin autorilori nu reflect vederile

Ageniei Statelor Unite pentru Dezvoltare Internaional.

Acest ghid poate fi utilizat i copiat n scopuri necomerciale atta vreme ctANIAP este creditatca sursi "USAID" este menionatca finanator.

n acest context, documentul cuprinde recomandri n vedereaorganizrii i conducerii proiectelor informatice derulate n cadrulAdministraiei Publice Locale din Romnia.

AUTORI:

Adrian Georgescu - Consiliul Judeean DmboviaAdrian Imireanu - Primria Municipiului FocaniAdrian Teac - Primria Municipiului SloboziaCamelia Iordache - Primria Municipiului Cmpulung MoldovenescCtlin Hristea - consultantCtlin Tiseac - consultantConstantin Moga - Consiliul Judeean MureDan Artimon - Consiliul Judeean BotoaniDelia Ariana Zupcu - Primria Municipiului TimioaraDiana Bondoc - Ministerul Transporturilor,Construciilori TurismuluiDumitru Marian Popescu - Consiliul Judeean GorjEugen Antal - Consiliul Judeean BihorGabriela Gavri - Primria Municipiului OradeaIoana Raicu - Primria Municipiului BucuretiLucian Dorr Primria Municipiului BucuretiMarcela Lcrmioara Zaharia - Consiliul Judeean SlajMarian Vrabie - Consiliul Judeean BrilaMihaela olic - Centrul de Calcul Consiliul General BucuretiMikls-Pl Gbor - Consiliul Judeean HarghitaMugurel Radu Predescu - Primria Municipiului Trgu JiuNatalia Ceptureanu - Consiliul Judeean DmboviaNicu Vasile - Consiliul Judeean PrahovaRichina Balaci - Primria Municipiului LugojSevil Sumanariu - Consiliul Judeean ConstanaViorel Manca Primria Municipiului Galai


2/87


3/87



Pagina 3 din 87

5.1.1 Ce este un proiect? 185.1.2 De ce proiectele au nevoie de management? 185.1.3 Arie de aplicabilitate 185.1.4 Alte precizri 195.1.5 Organizarea acestei seciuni 19

5.2 Noiuni de baz privind managementul de proiect 205.2.1 Organizarea proiectului 205.2.2 Planificarea proiectului 265.2.3 Controlul proiectului 315.2.4 Management-ul Riscurilor 395.2.5 Calitatea 425.2.6 Management-ul Configuraiilor 445.2.7 Controlul Schimbrii 46

6. CAIETUL DE SARCINI CERINE SPECIFICE PRIVINDMANAGEMENTUL PROIECTELOR 48

6.1 Organizarea proiectului (vezi 5.2.1) 48

6.2 Planificarea proiectului (vezi 5.2.2) 49

6.3 Controlul proiectului (vezi 5.2.3) 50

6.4 Management-ul riscurilor (vezi 5.2.4) 53

6.5 Calitatea (vezi 5.2.5) 53

6.6 Management-ul configuraiilor (vezi 5.2.6) 54

6.7 Controlul schimbrii (vezi 5.2.7) 54

6.8 Criterii de evaluare a ofertelor 55

7. ALTE RECOMANDRI 56

7.1 Clauze contractuale 56

7.2 Recomandri diverse 60

7.3 List de verificare a documentelor de proiect 627.3.1 Iniializarea proiectului 627.3.2 Planificare 637.3.3 Raportare 63

8. GLOSAR DE TERMENI 64

9. ANEXE 66

9.1 Anexa 1: Propunerea de Proiect 67

9.2 Anexa 2: Determinarea dimensiunii proiectelor 73


4/87



Pagina 4 din 87

9.3 Anexa 3: Livrabilele de Management ale Proiectului 75

9.4 Anexa 4: Descrierea principalelor roluri din proiect 769.4.1 Comitetul de Conducere al Proiectului 769.4.2 Managerul de Proiect 789.4.3 Coordonatorul de Proiect al Beneficiarului 79

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

9.6 Anexa 6: Formular de diagnoz 839.6.1 INTRODUCERE 839.6.2 ORGANIZAREA PROIECTELOR 849.6.3 PLANIFICAREA PROIECTELOR 859.6.4 CONTROLUL PROIECTELOR 859.6.5 MANAGEMENT-UL CALITATII 869.6.6 MANAGEMENT-UL SCHIMBARII 869.6.7 MANAGEMENT-UL RISCULUI 87


5/87



Pagina 5 din 87

1. CONTROLUL DOCUMENTULUI1.1 Proprietarul documentului

Acest document a fost elaborat de ctre ANIAP.

1.2 Istoricul documentuluiRevizia Data reviziei Autor Sumarul schimbrilor

Ver. 00.01 04.07.2005 ANIAP Prima versiune pentru discuii

Ver. 00.02 15.07.2005 ANIAP A doua versiune dup seminarulANIAP. ncorporarea tuturorobservaiilor i reorganizareadocumentului.

Ver. 00.03 16.07.2005 ANIAP Versiunea final pentru reviziaANIAP.

Ver. 1.00 18.07.2005 ANIAP Revizia final versiunea 1.0

1.3 Modificri viitoaren urma reviziei finale a ANIAP.

1.4 BibliografieMetodologia de Management de Proiect PRINCE2

Jack Meredith, Samuel J. Mantel, Jr, Project Management. A managerialapproach, fourth edition, 2000, John Wiley&Sons

Curaj Adrian, Apetroae Marin, Purnus Augustin, Scarlat Cezar, Munteanu Radu-Practica Managementului de proiect.2004. Ed.Economic

http://www.stickyminds.com

http://www.qaforums.com

http://www.projectmanagement.tas.gov.au

1.5 AbrevieriANIAP Asociaia Naional a Informaticienilor din Administraia Public

TIC Tehnologia Informaiilori Comunicaii

USAID United States Agency for International Development


6/87



Pagina 6 din 87

2. INTRODUCERE2.1 Necesitate

Insuficienta aplicare a metodologiilor recunoscute de management al proiecteloreste una din principalele cauze ale disfuncionalitilor proiectelor informaticederulate n cadrul administraiei publice locale. Fie c este vorba despre ntrziereaproiectelor, despre alegerea greit a soluiei tehnice, despre atingerea parial aobiectivelor stabilite sau despre neutilizarea sistemelor informatice implementate,disfuncionalitile proiectelor TIC auinfluene majore asupra eficienei activitii ia performanei nregistrate.

Din aceste motive, ANIAP consider c reglementarea modalitii de organizare,demarare i conducere a proiectelor informatice poate constitui un instrumentefficient de minimizare a disfuncionalitilor i poate astfel ajuta la optimizareaperformanei proiectelor TIC .

2.2 Structuri obiectiveGhidul 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 proiectelorinformatice din cadrul Administraiei Publice din Romnia. Plecnd de laefectele sesizate n cadrul proiectelor, aceast seciune identific principalelecauze care duc la materializarea disfunciunilor n cadrul proiectelor;

Lansarea proiectelor n interiorul organizaiei aceast seciune identificmodalitatea recomandat de control a evoluiei proiectului n etapa delansare, din momentul identificrii necesitii proiectului i pn lafinalizarea procedurii de achiziie public (acolo unde este cazul) ;

Metodologia de management al proiectelor seciunea prezint elementeleprincipale ale unei metodologii de management de proiect, care poate fiutilizat pe perioada implementrii proiectului (din momentul finalizriiprocedurii de achiziie public prin semnarea unui Contract i pn nmomentul finalizrii tuturor activitilor de implementare prin obinereaCertificatului de Acceptan);

Caietul de Sarcini aceast seciune identific recomandri privind cerinelereferitoare la managementul de proiect care pot fi incluse n caietele desarcini elaborate n vederea demarrii proiectelor TIC n cadrulAdministraiei Publice. Scopul acestor cerine este, pe de o parte, acela de astabili un prag minimal n domeniul managementului de proiect care s fierespectat 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 ncadrul Administraiei Publice Locale. Aceste recomandri vin din experienapersonal a autorilor Ghidului, conin inclusiv recomandri privind diferiteclauze care pot fi introduse n cadrul Contractelori trebuie interpretate carecomandri i nu ca impuneri;

Glosar de termeni avnd n vedere faptul c termenii specificimetodologiilor de management al proiectelor nu sunt nc ncetenii n


7/87



Pagina 7 din 87

limba romn, aceast seciune prezint echivalentul n limba englez aldiferiilor termeni specifici folosii n cadrul acestui Ghid;

Anexe diferite anexe care pot ajuta la nelegerea acestui Ghid.

2.3 Grup intAcest Ghid se adreseaz personalului din cadrul administraiei publice locale careiniiaz/deruleaz proiecte de informatizare. De asemenea, seciuni din acest Ghidpot fi incluse n Documentaia pentru Elaborarea i Prezentarea Ofertei n scopulsusinerii cerinelor pentru organizarea i conducerea proiectului, cerine la careOfertanii trebuie s rspund.


8/87


9/87



Pagina 9 din 87

aplicaiilor financiar-contabile (inclusiv de taxe i impozite), implementareaaplicaiilor 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 pentrusuccesul acestor proiecte i pentru atingerea obiectivelor instituiei.

3.2 Categorii de probleme identificaten cadrul acestei seciuni vor fi prezentate tipul problemelor identificate, cauzeleposibile de producere i impactul pe care aceste probleme, odat manifestate, lproduc asupra proiectelor sau asupra instituiilor.

Urmtoarele probleme se manifest n cadrul proiectelor TIC derulate n cadruladministraiei 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 dintremembrii acestor organizaii

abaterea de la obiectivele stabilite ale proiectului

Aceste probleme determin n ultim instan eecul parial sau total al proiectelorprin neatingerea obiectivelor propuse sau nerespectarea constrngerilor stabilite.

n gruparea problemelor identificate a fost respectat structura general acomponentelor 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 peparcursul implementrii proiectului

coordonatorul de proiect al beneficiarului nu are pregtirea necesar pentru amonitoriza i evalua modul n care managementul de proiect este realizat dectre 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 careutilizeaz produsele realizate n cadrul proiectului

indisponibilitatea sau dezinteresul resurselor beneficiarului fa de derulareaproiectului


10/87



Pagina 10 din 87

nerezolvarea la timp a problemelor aprute n proiect

specificaia cerinelor nu acoper corect sau complet cerinele utilizatorilor

nerecunoaterea sau subminarea autoritii managerului de proiect

Cauzele care produc aceste probleme sunt n general urmtoarele:

nu este stabilit un comitet de conducere al proiectului nainte de demarareaacestuia

coordonatorul de proiect al beneficiarului nu este ntotdeauna identificat de ctreconducerea instituiei pe baza abilitilor i experienei de management deproiect; de regul, acesta este ales din cadrul departamentului de TIC

nu exist o nominalizare oficial a membrilor echipei de proiect abeneficiarului, cu descrierea rolului i a responsabilitilor specifice n proiect

departamentelecare beneficiaz de pe urma proiectului sau utilizeaz produsulacestuia 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 documentde proiect) echipa proprie de proiect i/sau managerul de proiect i nu descriurolurile i reponsabilitile pentru membrii echipei de proiect

nu ntotdeauna sunt folosite mijloacele (instrumentele) cele mai eficiente pentruprezentarea problemelor aprute n derularea proiectului n vederea lurii dedecizii n timp util de ctre persoanele autorizate

n cele mai multe cazuri nu se solicit furnizorului prezentarea n cadrul oferteitehnice a metodologiei de management de proiect pe care acesta o va utiliza peparcursul proiectului

de foarte multe ori nu este solicitat furnizorului s fac dovada capacitii salede management de proiect, s prezinte CV-ul pentru managerul de proiectpropus i dovezile care s ateste experiena acestuia n managementul unorproiecte de anvergur similar

caietele de sarcini nu prevd n mod explicit responsabilitatea conduceriiproiectului (a sarcinilor i a responsabilitilor organizaiilor furnizor ibeneficiar) i nu includ cerine specifice pentru managementul proiectului

nu este solicitat n caietele de sarcini identificarea n cadrul ofertei financiare aofertantului a costurilor asociate managementului de proiect

3.2.2 Probleme identificate n planificarea proiectelor


dependenele pentru proiect nu sunt corect sau complet identificate

estimarea nerealist a duratelor pentru activitile din cadrul etapei

alocarea resurselor este defectuoas (insuficient)

ntrzierea activitilor deoarece resursele nu sunt disponibile atunci cnd estenecesar



11/87



Pagina 11 din 87

nu sunt luate n considerare n cadrul proceselor de planificare toate elementelecare necesit planificare

nu sunt folosite metode sau instrumente specifice n cadrul planificrii

planificarea detaliat nu este ntotdeauna realizat la nceputul etapelor, atuncicnd informaiile relevante necesare planificrii sunt disponibile

3.2.3 Probleme identificate n controlul proiectelor


problemele care apar pe parcursul derulrii proiectelor nu sunt identificate latimp i/sau nu sunt soluionate optim sau n timp util

beneficiarul nu cunoate ntotdeauna care este stadiul real al proiectului, saucare 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 prilori 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 nusunt identificate i rezultatele testelor nu sunt riguros documentate

nu sunt cunoscute ntotdeauna responsabilitile privind controlul i raportareaprogresului

nu se cunoate care este ordinea de prioritate a documentelor contractuale n

cazul n care exist contradicii ntre prevederile acestora exist deseori nenelegeri cu reprezentanii furnizorului datorit ntelegerii

diferite a ceea ce trebuie livrat sau a modului n care trebuie livrat


contractele ncheiate nu conin suficiente detalii care s permit un controleficient al proiectelor

furnizorii nu includ n ofertele lor detalii referitoare la: reponsabilitile prilori dependenele reciproce, testele care trebuie realizate, metodele de acceptarepentru livrabile

caietele de sarcini nu prevd ntotdeauna responsabilitile prilor privindcontrolul i raportarea progresului

nu exist n contract o clauz care s prevad ordinea n care diferiteledocumente care fac parte din contract vor fi interpretate

modalitile i instrumentele de control nu sunt folosite ntotdeauna ntr-un modeficient de ctre coordonatorul de proiect al beneficiarului: edine deidentificare a progresului, edine de rezolvare a problemelor, edine de controlcu furnizorii, edine de raportare ctre conducere, rapoarte scrise i scrisori(puncte de vedere)


12/87



Pagina 12 din 87

3.2.4 Probleme identificate n managementul calitii


livrabilele realizate de proiect nu corespund standardelor de calitate aplicabile istabilite pentru proiect

procesul de testare nu scoate n eviden toate neconformitile livrabilelor

livrabilele realizate de proiect nu pot fi folosite de ctre utilizatori datoritdisfuncionalitilor majore care apar imediat dup intrarea n perioada deoperare a acestora

furnizorul nu este n msur s asigure i s controleze calitatea pe perioadadesfurrii proiectului


organizaia beneficiarului sau a furnizorului nu nelege ntotdeauna censeamn calitatea n mediul de proiect

caietele de sarcini nu conin ntotdeauna criterii de calitate pentru toatelivrabilele proiectului

nu sunt clar stabilite sau cunoscute criteriile de calitate care se aplic diferitelortipuri de livrabile (echipamente, licene software, servicii de analiz, servicii deimplementare, servicii de instruire, servicii de suport si asisten tehnic,documente tehnice, documente de analiz, rapoarte, grafice de implementareetc.)

nu se solicit n cadrul caietului de sarcini prezentarea de ctre ofertant amodului n care acesta va asigura calitatea livrabilelor pe parcursul desfurriiproiectului

furnizorii nu prezint n cadrul ofertelor tehnice modalitatea practic n careacetia vor asigura i controla calitatea livrabilelor proiectului, menionareaexistenei certificrii ISO fiind de multe ori singura referire la calitate

necunoaterea n totalitate sau neaplicarea tuturor tipurilor de criterii n bazacrora se realizeaz n cadrul proiectelor testarea i acceptarea livrabilelor

3.2.5 Probleme identificate n managementul schimbrilori al configuraiilor


modificarea cerinelor beneficiarului pe parcursul derulrii proiectului iimposibilitatea furnizorului de a rspunde la aceste schimbri n mod eficient

neintegrarea unor sub-sisteme sau componente n sistemul final n urmaimplementrii unor schimbri la nivelul acestora

apariia unor ntrzieri sau costuri neplanificate sau neaprobate n urma realizriiunor modificri la specificaia livrabilelor

livrarea unor produse care s nu fie funcionale sau utilizabile


dei este acceptat de marea majoritate a intervievailor c existena uneiproceduri scrise care s documenteze exact toate elementele unei schimbari este


13/87



Pagina 13 din 87

perfect justificat, n foarte multe cazuri procedura de control a schimbrilor nueste 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 nimplementarea schimbrilor pe parcursul ciclului de via a proiectului

3.2.6 Probleme identificate n managementul riscului


producerea de ntrzieri n derularea proiectului, pentru anumite activiti saulivrabile, n urma apariiei unor probleme care nu au fost prevzute

depirea bugetului alocat pentru proiect datorit unor situaii neprevzute

crearea unor situaii tensionate n cadrul echipei de proiect comune furnizor-beneficiar n urma manifestrii unor riscuri

realizarea unor compromisuri relativ la calitatea unor livrabile datorit apariieiunor probleme care nu au fost prevzute


nu sunt clar definite sau nu sunt formal asumate de ctre pri responsabilitilereferitoare la managementul riscurilor

n marea majoritate a cazurilor nu este folosit, nici de ctre beneficiari nici dectre furnizor, o procedur formal de realizare a managementului riscurilorcare s prezinte modalitatea practic de realizare a identificrii riscurilor, a

probabilitii de apariie i a impactului n cazul apariiei, a planificariiactivitilor de contracarare i a planurilor alternative n cazul materializriiriscului

nu sunt stabilite responsabilitile n identificarea i controlul riscurilor pentrupersoanele cu autoritate de decizie din cadrul organizaiei beneficiarului

nu sunt identificate i disponibile modalitile concrete prin care pot ficontrolate riscurile n cadrul organizaiei beneficiare

nu sunt derulate edine de analiz comune (beneficiari furnizor) n vedereaidentificrii i evalurii riscurilor din proiect

nu sunt stabilite sau derulate planuri de aciune de ctre coordonatorul de proiectal beneficiarului n vederea contracarrii riscurilor

nu este solicitat n cadrul caietului de sarcini prezentarea n cadrul oferteitehnice de ctre furnizor a unui plan concret de management al riscului pentruprincipalele riscuri identificate

planul de riscuri nu este revizuit pe parcursul proiectului


14/87



Pagina 14 din 87

3.3 ConcluziiPentru a putea evalua anvergura problemelor identificate s-a avut n vederedeterminarea frecvenei de manifestare a acestor probleme pe parcursul ini ierii,

contractrii, demarrii i derulrii proiectelor. Astfel, n urma analizei informaiilori a consolidrii rezultatelor din chestionarele primite, s-au putut determina pentrufiecare problem n parte frecvena de apariie i componenta de metodologie demanagement de proiect creia aceasta i aparine. Componentele de metodologie aufost ulterior grupate n trei categorii n funcie de numrul problemelor care au fostsemnalate.

Mai jos sunt prezentate componentele de management de proiect grupate pe cele treicategorii:

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 uneimetodologii de management de proiect de ctre organizaiile care furnizeaz

proiectul sau care beneficiaz de pe urma acestuia i utilizeaz produsul proiectuluireprezint un factor determinant n asigurarea succesului acestuia . Din acest motiv,n cadrul seciunilor care urmeaz vor fi prezentate componentele generale ale uneimetodologii de management de proiect care s fie aplicate pe parcursulimplementrii proiectelor TIC din administraia public local.


15/87



Pagina 15 din 87

4. DOCUMENTE ELABORATE N VEDEREA LANSRIIPROIECTELOR

4.1 IntroducereAceast seciune prezint paii recomandai pentru lansarea unui proiect TIC ncadrul administraiei publice locale. Aceste etape sunt prezentate din punctul devedere al documentelor interne care trebuie pregtite de ctre instituia beneficiar.

4.2 Etapele demarrii proiectului4.2.1 Etapa pregtitoare

4.2.1.1 Referatul de necesitateAcest document este ntocmit de ctre viitorul utilizator al rezultatelor proiectului(departamentul iniiator al proiectului). Prin acest document, utilizatorul prezint

problema apruti 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 sauconducerii instituiei.

4.2.1.2 Nominalizarea echipei interne de proiectDup primirea Referatului de Necesitate, persoana care trebuie s ia deciziademarrii sau nu a proiectului va numi o echip de proiect care s pregteasc oPropunere de Proiect. Echipa de proiect va fi condus de un Coordonator de Proiecti va fi compus din membrii departamentelor afectate de proiect (din postura deutilizatori, furnizori sau suport). De asemenea, se va constitui un Comitet de

Conducere al Proiectului care va evalua Propunerea de Proiect i va decidedemararea sau nu a proiectului. Comitetul de Conducere al Proiectului va puteaaloca resurse suplimentare echipei de proiect n vederea finalizrii Propunerii deProiect. Structura proiectului n aceast etap este prezentat mai jos:

Figura 1: Organizarea de proiect a Beneficiarului


16/87



Pagina 16 din 87

Responsabilitatea Reprezentantului Utilizatorului (sau al Utilizatorilor) este aceeade a identifica i detalia cerinele funcionale pentru proiect, n timp ceReprezentantul Beneficiarului are rolul de a analiza aceste cerine i de a aloca

resursele necesare pentru implementarea proiectului, n funcie de celelalte prioritiale instituiei.

4.2.1.3 Elaborarea Propunerii de ProiectSub conducerea Coordonatorului de Proiect, echipa de proiect va analiza toateaspectele proiectului propus i va elabora Propunerea de Proiect, pe care o va naintaspre aprobare Comitetului de Conducere al Proiectului. Aceast Propunere deProiect trebuie s nceap cu un scurt rezumat ce va reflecta i prezenta nevoile pecare trebuie s le rezolve proiectul, modalitatea n care se vor satisface aceste nevoii rezultatele ateptate n urma implementrii proiectului. Propunerea de proiecttrebuie 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, cupregtire corespunztoare) care vor fi utilizate. Fiecare parte important(etap) a proiectului va fi nsoit de bugetul aferent acesteia, indicatori decalitate i perioada de realizare;

referate de specialitate n funcie de aria de cuprindere i de valoareaproiectului, se vor solicita departamentelor economic, juridic, IT, patrimoniuetc. referate privind posibilitile de finanare, implicaiile juridice,dependenele de alte soluii existente, resursele disponibile, condiiile tehniceIT care trebuie impuse. Din aceste referate trebuie s rezulte clar aria decuprindere 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 deConsiliu care va cuprinde Propunerea de Proiect i care va avea ca anex referateleanterioare de specialitate i expunerea de motive.

4.2.1.5 Hotrrea de ConsiliuHotrrea de Consiliu este documentul care aprob angajarea instituiei n derulareaproiectului.

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, modelede formulare, alte anexe (poate conine i descrierea metodologiei demanagement de proiect propuse vezi seciunea 5)

documentaia de evaluare a ofertelor

contractul de achiziie public


17/87


18/87



Pagina 18 din 87

5. METODOLOGIA DE MANAGEMENT AL PROIECTELOR5.1 Introducere5.1.1 Ce este un proiect?

Un Proiect reprezint modalitatea de organizare funcional a resurselor (umane ide alt natur) n vederea realizrii unui obiectiv bine stabilit.

Un proiect se definete ca o succesiune de procese nerepetitive n scopul realizriiunor livrabile noi, bine definite, n cadrul unei organizaii special create pentru acestscop, 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, ndeplinireaobiectivelor nseamn atingerea standardelor de calitate propuse, n limitele de timpi de buget stabilite.

O metodologie de management de proiect pune la dispoziie o serie de componentei procese care s ajute n procesul de planificare, monitorizare i control i care sasigure c proiectul va fi realizat la timp, cu bugetul alocat, la nivelul de calitateprogramat i cu atingerea tuturor obiectivelor propuse.

5.1.3 Arie de aplicabilitate

Metodologia de management de proiect prezentat n cadrul acestei seciuni se poateaplica n cadrul oricrui tip de proiect TIC, fie el realizat cu ajutorul unui furnizorfie numai cu resurse interne ale autoritii locale .

Din punctul de vedere al dimensiunii sau complexitii proiectelor n care aceastmetodologie se poate aplica, nu exist restricii generale. Indiferent de

considerentele de complexitate sau dimensiune, utilizarea unei abordrimetodologice crete ansele de succes ale proiectelor. Din acest motiv, singuravariabil n cazul folosirii unei metodologii este nivelul de detaliere i decomplexitate necesar deciziile n aceast direcie aparin Manager-ului de Proiect.Metodologia de Management de Proiect are menirea de a ajuta Manager-ul deProiect n derularea proiectului i nu de a crea o povar administrativ asupraacestuia i a echipei de proiect. Din acest motiv, este esenial ca procedurile icantitatea de documente administrative folosite n cadrul proiectului s fie justificatede anvergura acestuia. Metodologia nu este un scop n sine; obiectivul nu esteaplicarea metodologiei, ci finalizarea cu succes a proiectului, iar metodologia estedoar o unealt n atingerea acestui obiectiv. Urmtorul tabel prezint o recomandaren ceea ce privete gradul de detaliere a diferitelor componente ale metodologiei demanagement de proiect n funcie de dimensiunea proiectului. Modalitatea de

determinare a dimensiunii proiectului este prezentat n Anexa 2:Componenta metodologiei / Dimensiuneaproiectului

MIC MEDIU MARE

Organizarea proiectului Sumar Detaliat Detaliat

Planificare Sumar Detaliat Detaliat

Managementul riscurilor Sumar Sumar Detaliat

Managementul calitii Sumar Detaliat Detaliat


19/87



Pagina 19 din 87

Controlul proiectului Sumar Detaliat Detaliat

Managementul configuraiilor Sumar Sumar Detaliat

Managementul schimbrii Detaliat Detaliat Detaliatntruct majoritatea proiectelor TIC de anvergur din cadrul administraiei publicelocale sunt realizate cu ajutorul furnizorilor , iar conducerea i organizareaproiectului sunt de obicei activiti n sarcina furnizorului, toate formulrile dincadrul acestei seciuni a Ghidului sunt fcute n contextul unui furnizor . Cu toateacestea, dup cum am precizat la nceputul acestei sub-seciuni, metodologiaprezentat se poate aplica i n cazul n care furnizorul este chiar Departamentul TICdin cadrul autoritii locale .

5.1.4 Alte precizri

Seciunea 5 cuprinde noiuni de baz privind modul n care trebuie realizatmanagementul de proiect pe ntreaga durat a desfurrii proiectului. Chiar dacanumite sarcini de management de proiect vor fi ndeplinite i de ctre Beneficiarprin intermediul unui Coordonator de Proiect numit de ctre acesta (din cadrulorganizaiei Beneficiarului sau angajat pe baza unui contract de consultan), acestGhid pleac de la ipoteza c responsabilitatea principal pentru furnizarea tuturorserviciilor de management de proiect revine Furnizorului. Din aceast perspectiv,n afara cazului n care se indic explicit altfel, orice referire (din cadrul acestuiGhid) la Managerul de Proiect i la ndatoririle acestuia precum i la organizarea icoordonarea activitilor de management al proiectului vor fi nelese ca fiind nsarcina Furnizorului.

Att Furnizorul ct i Beneficiarul pot opta pentru folosirea acestei metodologii saua 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 implementan cadrul proiectului metodologia propus , n conformitate cu cerinele specificeprezentate n seciunea 6. n acest sens, recomandm s nu se accepte n cadrulofertelor referirea la un standard de metodologie fr prezentarea detaliat amodalitii 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 demanagement de proiect, precum i metodele prin care aceste componente seregsesc n cadrul unui proiect. Astfel, aceast seciune a Ghidului trateazurmtoarele aspecte legate de managementul de proiect:

Organizarea proiectului

Planificarea proiectului Controlul proiectului

Management-ul riscurilor

Calitatea

Management-ul configuraiilor

Management-ul schimbrilor


20/87



Pagina 20 din 87

5.2 Noiuni de baz privind managementul de proiect5.2.1 Organizarea proiectului

Organizarea proiectului are la baz cteva roluri fundamentale, care sunt definite ncele ce urmeaz:

Clientul este cel care definete rezultatul ateptat, care va folosi rezultatulfinal i care va plti proiectul. n cadrul acestui rol, exist dou sub-roluriimportante: Beneficiarul i Utilizatorul. n cadrul acestui Ghid, prinBeneficiar se nelege persoana sau departamentul care finaneaz proiectul,n timp ce prin Utilizator se nelege persoana sau departamentul care vautiliza 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 necesarpentru obinerea rezultatului final dorit.

Stabilirea unei structuri organizaionale eficiente a proiectului este un factorfundamental n vederea unui proiect de succes, deoarece proiectul are nevoie deconducere, control i comunicare. Din acest motiv, structura de proiect este diferitde structura normal de subordonare ierarhic din cadrul instituiei i include arii decompeten multidisciplinare, mai ales dac proiectul se adreseaz unui grup deutilizatori care nu fac parte din aceeai sub-diviziune organizaional (departament).Din acest punct de vedere, Manager-ul de Proiect (din partea organizaieiFurnizorului) i Coordonatorul de Proiect (din partea organizaiei Clientului) trebuies aib autoritatea de a decide asupra modului n care toate resursele (umane i altfel) ale proiectului sunt folosite (att cele alocate n ntregime proiectului ct i celecare sunt alocate proiectului pe o perioad limitat de timp).

Structura de conducere a proiectului trebuie s cuprind roluri i responsabiliticare s reuneasc toate interesele existente i expertiza necesar proiectului.

n cele ce urmeaz, prin Structura organizaionala a proiectului se va nelegestructura comun a proiectului, incluznd att rolurile Clientului (Beneficiar iUtilizator) ct i pe cele ale Furnizorului.

Structura organizaional a proiectului cuprinde att rolurile care au ca obiectivcoordonarea 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


21/87



Pagina 21 din 87

Figura 2: Organizarea proiectului

Primele trei nivele de organizare constituie Echipa de Management a proiectului.Este esenial ca aceast echip s fie complet definit astfel nct s includ:

roluri de luare a deciziilor

management-ul excepiilor pentru rolurile de decizie

management-ul de proiect (full time sau part time)

delegarea controlat a unor sarcini de management de zi cu zi, acolo undeeste cazul, ctre efii de Echip

roluri pentru evaluarea independent a tuturor aspectelor de performan aleproiectului

suport administrativ pentru Project Manageri efii de Echip cunoaterea rolurilori 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 ProiectuluiComitetul de Conducere al Proiectului reprezint nivelele de conducere din cadrulstructurilor organizaionale angrenate n proiect: Beneficiarul, Utilizatorii i

ReprezentantUtilizator

ReprezentantBeneficiar

ReprezentantFurnizor

Manager Proiect

Comitetul de Conducere al Proiectului

Sef Echipa

Sef Echipa

Rol 2

Rol 3

Rol 1

Rol 2

Rol 3

Rol 1

Asigurarea

ControluluiProiectului

Echipa de Suport

a Proiectului

Coordonator

Proiect

Rol 1

Rol 3

Rol 2

Rol 4


22/87



Pagina 22 din 87

Furnizorul. Reprezentanii acestor structuri trebuie s aib nivelul necesar deautoritate n cadrul structurilor pe care le conduc pentru a putea lua decizii i pentrua putea controla alocarea de resurse materiale i financiare.

Nivelul de reprezentare n cadrul Comitetului de Conducere al Proiectului al celortrei structuri menionate trebuie s in cont de importana i dimensiuneaproiectului, avnd n vedere c participarea n cadrul structurii de conducere aproiectului este o sarcin suplimentar activitilor curente i n consecin nutrebuie s afecteze foarte mult activitile curente ale celor implicai. Din acestmotiv, pe lng implicarea periodic necesar informrii asupra desfurriiactivitilor planificate ale proiectului, Comitetul de Conducere al Proiectului i varealiza mandatul prin activiti de management al excepiilor, adic se va implica nderularea proiectului numai atunci cnd planul de proiect aprobat nu mai poate firespectat i cnd este necesar luarea unor decizii strategice privind continuareaproiectului.

Comitetul de Conducere al Proiectului:

aprob toate planurile importante ale proiectului i autorizeaz orice deviaiemajor de la Planurile de Etap aprobate, conform limitelor de competen;

confirm oficial finalizarea fiecrei etape a proiectului i autorizeazdemararea unei noi etape;

se asigur c nivelul necesar de resurse este alocat proiectului i arbitreazconflictele n interiorul proiectului;

asigur interfaa ntre proiect i mediul organizaional extern i gsetesoluii de rezolvare a eventualelor conflicte (de interese, de resurse, deprioriti) ntre proiect i mediul exterior;

aprob oficial numirea Managerului de Proiect (din partea Furnizorului)precum i responsabilitile i limitele de autoritate ale acestuia. Deasemenea, aprob oficial numirea Coordonatorului de Proiect din parteaBeneficiarului.

Comitetul de Conducere al Proiectului poate folosi resurse externe echipei deproiect pentru a se asigura c proiectul i urmeaz cursul normal i c i va atingeobiectivele propuse. Aceste resurse externe sunt organizate sub forma unei structuride Asigurare a Controlului Proiectului i cuprind expertiz n domenii precum:

management

asigurarea calitii

audit

expertiz tehnic specific ariilor de proiectCu toate c face parte din echipa de proiect, Coordonatorul de Proiect alBeneficiarului ndeplinete i un astfel de rol de control din partea Comitetului deConducere al Proiectului, n sensul c ofer un punct de vedere separat de cel alManagerului 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


23/87



Pagina 23 din 87

asigure c proiectul va furniza avantajele economice scontate, la nivelul investiieifcute i c obiectivele iniiale ale proiectului se pstreaz pe durata derulriiacestuia. n ndeplinirea acestor sarcini, Reprezentantul Beneficiarului trebuie s

poat realiza o balan just ntre interesele organizaiei, ale utilizatorilor i alefurnizorului. Persoana desemnat pentru acest rol realizeazi legtura cu structurilesuperioare de management ale organizaiei, oferind vizibilitate proiectului la nivelnalt.

Reprezentantul Beneficiarului trebuie s aib o poziie important n cadrulinstituiei, deoarece trebuie s poat controla bugetul i resursele alocate proiectului.Prin poziia sa, acest rol trebuie s poat impune deciziile sale att ReprezentantuluiUtilizatorilor ct i restului organizaiei sale.

5.2.1.1.2 Reprezentantul Utilizatorilor

Reprezentantul Utilizatorilor rspunde pentru producerea tuturor livrabilelorfurnizate 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 beneficiileateptate. De asemenea, va monitoriza faptul c soluia dezvoltat va rspundecerinelor utilizatorilor n limita constrngerilor documentului de justificareeconomic a proiectului.

Acest rol reprezint interesele tuturor celor care vor utiliza rezultatele finale aleproiectului, ale celor care vor utiliza rezultatele proiectului n vederea atingerii unorobiective, ale ceror care vor realiza beneficii suplimentare utiliznd rezultateleproiectului, 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 cadrulorganizaiei, ceea ce ar necesita un numr mai mare de Reprezentani aiUtilizatorilor n cadrul Comitetului de Conducere al Proiectului, atunci acest rolpoate fi realizat de mai multe persoane. Dac se consider c acest lucru ar ficontraproductiv, atunci reprezentanii utilizatorilor pot organiza un comitet n careproblemele s se discute i s numeasc apoi un reprezentant care s susin punctulde 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 rezultatelorsolicitate de Reprezentantul Utilizatorilor. Reprezentantul Furnizorului esteresponsabil pentru calitatea tuturor livrabilelor livrate de ctre furnizor(i). Ca parte aacestei responsabiliti, el trebuie s se asigure c propunerile privind proiectarea idezvoltarea produselor sunt realiste, adic ele vor atinge obiectivele solicitate dectre Reprezentantul Utilizatorilor n cadrul constrngerilor de timp i de bugetfixate de ctre Reprezentantul Beneficiarului. Acest rol reprezint interesele tuturorcelor care proiecteaz, dezvolt, procur i implementeaz produsele furnizate i


24/87



Pagina 24 din 87

trebuie s aib nivelul de autoritate necesar pentru a implica sau a obine resurselenecesare din partea Furnizorului.

5.2.1.2

Managerul de Proiect (al Furnizorului)Managerul de Proiect are autoritatea din partea Comitetului de Conducere alProiectului de a conduce activitile de proiect de zi cu zi, n cadrul limitelor deresponsabilitate stabilite de ctre Comitetul de Conducere al Proiectului.

Responsabilitatea principal a Managerului de Proiect este de a se asigura cproiectul produce toate livrabilele necesare, n cadrul constrngerilor de timp i debuget i la standardele de calitate stabilite. Rolul Managerului de Proiect nu esteacela de a fi antrenat n cadrul activitilor zilnice de proiect, ci acela de a delegasarcinile i responsabilitile din cadrul proiectului astfel nct obiectivele acestuias fie atinse, pstrnd ns o viziune de ansamblu asupra strategiei proiectului i aevoluiei 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 responsabilitateaprincipal pentru coordonarea proiectului, el nu poate controla resursele organizaieiBeneficiarului. Din acest motiv este necesar un rol suplimentar cel alCoordonatorului de Proiect din partea Clientului. Rolul acestei persoane este aceeade a organiza resursele Clientului (Beneficiari Utilizatori) astfel nct acestea sfie utile proiectului i s fie disponibile conform necesitior planului de proiect.Coordonatorul de Proiect asigur interfaa oficial de comunicare a problemelor dezi cu zi ntre Managerul de Proiect i organizaia Clientului. Este important deprecizat faptul c relaia ntre Managerul de Proiect al Furnizorului i Coordonatorulde Proiect al Beneficiarului nu este una de subordonare, ci una de colaborare.Singura linie de raportare oficial a Managerului de Proiect este ctre Comitetul deConducere al Proiectului.

5.2.1.4 ef de EchipUtilizarea acestui rol nu este obligatorie, folosirea sa depinznd de anverguraproiectului i de organizarea pe care Furnizorul o va propune. De asemenea, n cazuln care dimensiunea echipei de proiect i specializarea resurselor o impun, folosireaacestui rol intermediar ntre Project Manager i membrii echipei de proiect esterecomandat n vederea uurrii comunicrii i a controlului. n cazul n careFurnizorul va recomanda formarea unei echipe n oglind din parteaBeneficiarului, folosirea acestui rol intermediar va uura comunicarea ntre pri iva minimiza punctele de contact oficial ntre echipe.

Responsabilitatea principal a unui ef de Echip este aceea de a asigura realizareaunor livrabile n condiiile stabilite de ctre Project Manager, cruia i raporteaz.

De asemenea, un ef de Echip poate coordona realizarea unei ntregi etape deproiect. Organigrama de proiect va identifica utilizarea efilor de Echip iar planulde Proiect va descrie exact limitele atribuiilori a responsabilitii acestora.

5.2.1.5 Asigurarea Controlului ProiectuluiPentru a realiza coordonarea proiectului i pentru a avea n permanen o privireobiectiv asupra evoluiei proiectului, exist situaii n care Comitetul de Conducereal Proiectului are nevoie de o prere obiectiv din partea unei entiti care nu esteimplicat n activitatea de zi cu zi a proiectului. Aceast entitate independent este


25/87



Pagina 25 din 87

Echipa de Asigurare a Controlului Proiectului. Necesitatea unei astfel de structurivine pe de o parte din nevoia unei informri independente iar pe de alt parte dinlimitarea timpului pe care membrii Comitetului de Conducere al Proiectului l pot

aloca investigrii acestor aspecte. Din aceste motive, membrii Comitetului deConducere al Proiectului pot delega aceste sarcini de monitorizare a calitiiactivitilor proiectului unor persoane independente de echipa de proiect (individualsau unitar). Sarcinile de monitorizare ale Echipei de Asigurare a ControluluiProiectului pot acoperi urmtoarele zone ale proiectului:

integritatea justificrii economice a proiectului pe ntreaga durat a derulriisale

respectarea standardelor i a procedurilor stabilite i aprobate de ctreComitetul de Conducere al Proiectului

respectarea standardelor de calitate

atingerea obiectivelor Utilizatorilor proiectului

monitorizarea riscurilor

pstrarea obiectivelor iniiale ale proiectului i evitarea deviaiilor de laaceste obiective

ntruct fiecare membru al Comitetului de Conducere al Proiectului urmreteanumite obiective, fiecare dintre aceti membrii poate delega independent sarcinamonitorizrii respectrii acestor obiective. Este fundamental ns ca aceste roluri demonitorizare s fie independente de personalul echipei de proiect, pentru evitareaconflictelor de interese. Membrii Echipei de Asigurare a Controlului Proiectului potfi fie angajai din cadrul organizaiei Beneficiarului, a Utilizatorului sau aFurnizorului, care nu sunt implicai n activitile de zi cu zi ale proiectului, fieconsultani independeni externi celor dou organizaii , contractai de ctre fiecaredin rolurile care formeaz Comitetul de Conducere al Proiectului.

O parte din rolurile Echipei de Asigurare a Controlului Proiectului pot fi realizate dectre Coordonatorul de Proiect al Beneficiarului. Chiar dac opinia acestuia nu esteobiectiv datorit implicrii efective n viaa de zi cu zi a proiectului, el poate oferi oviziune alternativ asupra evoluiei proiectului fa de cea oferit de Managerul deProiect din partea Furnizorului.

5.2.1.6 Asigurarea Suportului ProiectuluiPe lng sarcinile de management i tehnice, un proiect are nevoie de asistenadministrativ. Aceasta se poate datora anvergurii proiectului i volumului desarcini administrative care trebuie realizate, sau necesitii utilizrii unorinstrumente specifice de planificare sau de control (inclusiv financiar sau demanagement al configuraiilor) n utilizarea crora Project Manager-ul nu aresuficient experien.

Dac dimensiunea proiectului i numrul de livrabile necesit un control atent alconfiguraiilor, atunci instrumente software pentru controlul configuraieiproduselor trebuie utilizate. Aceast sarcin administrativ poate ocupa mult timp in acest caz se recomand folosirea unui Birou de Proiect care s aib i aceastsarcin. De asemenea, acest Birou de Proiect trebuie s asigure i alte funcii desuport, cum ar fi meninerea tuturor documentelor de proiect (att n formelectronic cu istoricul versiunilor ct i n form tiprit pentru versiunile aprobate)i furnizarea serviciilor de Registratur pentru toat corespondena de proiect.


26/87



Pagina 26 din 87

5.2.1.7 Funcionarea Comitetului de Conducere al ProiectuluiAvnd n vedere timpul limitat pe care membrii Comitetului de Conducere alProiectului l pot aloca sarcinilor referitoare la asigurarea direciei proiectului, cea

mai mare parte a sarcinilor acestei structuri se realizeaz n mod informal, frnecesitatea ntrunirii ntr-un cadru oficial. Comitetul de Conducere al Proiectuluieste informat n mod regulat de ctre Managerul de Proiect asupra evoluieiproiectului prin intermediul Rapoartelor pregtite de ctre acesta. Comitetul deConducere al Proiectului se ntrunete numai atunci cnd proiectul deviaz de laplanul aprobat, iar Managerul de Proiect pregtete un Raport de Excepie i un Plande Excepie pe care l supune aprobrii Comitetului de Conducere al Proiectului.

Cu toate c rolurile din cadrul Comitetului de Conducere al Proiectului suntconcepute pentru a acoperi toate interesele celor implicai n proiect i pentru ancuraja consultarea ntre acetia n scopul lurii celor mai bune decizii privindproiectul, funcionarea Comitetului de Conducere al Proiectului nu este neaprat unademocratic, n sensul c deciziile nu se iau prin vot. Rolul decizional este cel al

Reprezentantului Beneficiarului, care ns se consult cu ReprezentaniiUtilizatorilori cu cel al Furnizorului nainte de a lua aceast decizie. Indiferent dedecizia Comitetului de Conducere al Proiectului, dac aceast decizie are implicaiicontractuale atunci ea nu poate fi pus n practic nainte de a se concretiza ntr-unamendament la Contract.

5.2.2 Planificarea proiectului

Un plan este un document, structurat n conformitate cu o schem sau metodpredefinit, 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 obiectivedin punct de vedere al duratei de realizare, al costurilori al calitii livrabilelor.

5.2.2.1 Componentele unui plann nelesul acestui document, un plan nu este o reprezentare grafic a activitilorproiectului i a duratei acestora. Aceast reprezentare grafic a calendarului deproiect este numai o component a unui plan, acesta trebuind s conin informaiiprivind:

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 aactivitilor de control al calitii), precum i identificarea resurselorspecializate 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


27/87



Pagina 27 din 87

Pe lng seciunile de prezentare i pe lng schemele logice sau grafice, un plantrebuie 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 monitorizati controlat respectarea planului

care sunt rapoartele pentru management care vor fi produse pe durataimplementrii planului, pentru raportarea progresului

metodele folosite pentru controlul calitii i resursele care vor fi folosite nacest sens

ipotezele pe care se bazeaz planul

orice condiie prealabil care trebuie satisfcut pentru ca planul s poatdemara

riscurile existente care pot mpiedica realizarea planului, precum i msurilecare trebuie luate pentru a gestiona aceste riscuri.

5.2.2.2 Nivelul de planificareAvnd n vedere necesitatea planificrii activitilor i a resurselor, dar n acelaitimp innd cont i de acurateea redus a estimrilor cu ct acestea se refer laactiviti care se vor desfura ntr-un viitor mai ndeprtat, este important ca efortulde planificare s fie bine ponderat pe ntreaga durat a desfurrii proiectului i lanivelele ierarhice la care detaliile de planificare sunt necesare.

Chiar dac uneori este imposibil ca ntregul proiect s fie planificat n detaliu ncdin 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 apoiplanuri secundare, pe perioade mai scurte de timp, pentru obiective concrete i la unnivel mult mai detaliat.

Plan de Proiect

Plan de Etap

Plan de Lucru al

Echipei

Plan de Excepie

Figura 3: Nivelurile de planificare ntr-un proiect


28/87



Pagina 28 din 87

Pentru reflectarea nevoilor de planificare ale diferitelor nivele de managementimplicate n proiect, se propun dou nivele principale de planificare: Planul deProiect 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 nivelinferior celor de etap (Planuri de Lucru ale Echipei) care vor fi folosite de ctresub-echipele de proiect pentru derularea activitilor zilnice.

Principiul de baz care trebuie luat n considerare este acela c planurile de nivelmai jos acoper un orizont de timp mai restrns i conin mai multe detalii dect celede nivel mai nalt. n funcie de strategia aleas, Furnizorul va alege nivelul dedetaliu la care va realiza procesul de planificare a proiectului.

n momentul n care se estimeaz c un Plan de Etap i va depi toleranelestabilite i aprobate de ctre Comitetul de Conducere al Proiectului nainte demomentul demarrii etapei, Managerul de Proiect va realiza i va nainta spreaprobare Comitetului de Conducere al Proiectului un plan alternativ (Planul deExcepie) 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 partedin Documentele de Iniializare ale Proiectului. Realizarea unui astfel de Plan deProiect este obligatorie, ntruct constituie o referin fa de care va fi controlatntreaga evoluie ulterioar a proiectului, n cadrul fiecrei etape. Planul de Proiectidentific livrabilele principale, necesarul de resurse i totalitatea costurilor. Deasemenea, identific punctele principale de control n cadrul proiectului, cum ar filimitele de etape.

Dup acceptarea Documentelor de Iniializare a Proiectului, Planul de Proiect iniialdevine o referin contractual i constituie planul original pe baza cruia a fost

aprobat proiectul. Pe msur ce proiectul evolueaz, versiuni ulterioare ale planuluisunt 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 duratatotal a proiectului.

Versiunile iniiali curent ale Planului de Proiect sunt folosite de ctre Comitetulde Conducere al Proiectului n vederea monitorizrii deviaiilor de la constrngerileiniiale de timp, buget sau arie de acoperire.

Dac devine evident faptul c Planul de Proiect va depi toleranele stabilite dectre Comitetul de Conducere al Proiectului, atunci aceste deviaii vor trebuisemnalate Comitetului de Control al Proiectului, care va trebui s ia o hotrre nacest sens. n aceste situaii, cererea de aprobare va fi nsoit de un Plan deExcepie. Planul de Excepie are aceeai compoziie cu Planul de Proiect, ns esteun plan alternativ acestuia care ia n considerare deviaiile aprute i propunemodaliti pentru gestionarea acestor deviaii.


29/87



Pagina 29 din 87

5.2.2.2.2 Planul de Etap

Pentru fiecare etap identificat n Planul de Proiect este necesar un Plan de Etap.Planul de Etap se realizeaz nainte de finalizarea etapei creia i se adreseaz i

este aprobat de ctre Comitetul de Conducere al Proiectului, care cu aceast ocazieautorizeaz i demararea noii etape. Planul de etap va constitui baza controluluiexercitat de ctre Managerul de Proiect pe durata etapei respective.

Planul de Etap este similar n coninut Planului de Proiect, diferena fiind faptul cfiecare element va fi descris la un nivel de detaliu suficient pentru a permitecontrolul de zi cu zi al Managerului de Proiect. Validitatea presupunerilor fcute ncadrul Planului de Proiect precum i riscurile identificate anterior vor fi revzutepentru etapa respectiv, ntruct este posibil ca circumstanele proiectului s se fimodificat ntre timp i noi riscuri s fi aprut, care s fie relevante pentru etaparespectiv.

Planul de Etap trebuie s conin i o detaliere a Planului de Calitate care sidentifice metodele care vor fi utilizate pentru verificarea calitii fiecrui livrabil,

precum i resursele necesare pentru realizarea acestor verificri. Activitile legatede asigurarea calitii i de verificrile de calitate trebuie s fie explicit identificaten 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 careeste previzibil faptul c un plan aprobat de ctre Comitetul de Conducere alProiectului 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 iplanul pe care l nlocuiete, prelund stadiul curent al etapei i prezentndmodalitatea n care etapa va fi finalizat. Planul de Excepie nlocuiete de obicei unPlan 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 deProiect.

Planul de Excepie are acelai format cu planul pe care l nlocuiete, dar trebuie sconini informaii descriptive referitor la:

motivaia necesitii Planului de Excepie

impactul Planului de Excepie asupra ntregului Plan de Proiect (n cazul ncare Planul de Excepie nlocuiete un plan de Etap sau un alt plan de nivelmai jos), asupra justificrii economice a proiectului i asupra riscurilorproiectului

Planul de Excepie este prezentat spre aprobare Comitetului de Conducere alProiectului, 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 opionali este la latitudinea Managerului deProiect, care va lua decizia folosirii lor n funcie de anvergura etapei respective i amodului n care planific organizarea etapei. n principiu, un Plan de Lucru descrien detaliu modalitatea n care va fi obinut un anumit livrabil care face parte dintr-unPlan de Etap. n cazul n care sunt folosite, Planurile de Lucru ale Echipelor vor firealizate n paralel cu Planul Etapei, pe care l vor detalia.


30/87



Pagina 30 din 87

5.2.2.3 Etapele planificriiCalendarul de proiect elaborat de ctre Furnizor trebuie s identifice n mod claractivitile legate de procesul de planificare. Planul de Proiect trebuie s prevad n

mod obligatoriu o Etap de Iniializare n cadrul creia se vor finaliza Documentelede Iniializare ale Proiectului. Aceste documente vor identifica activitile demanagement, resursele, livrabilele, activitile, aspectele legate de calitate i decontrol. n funcie de dimensiunea proiectului, Etapa de Iniializare poate varia cadurati poate fi finalizat n mod oficial sau informal.

Pe lng Etapa de Iniializare, Planul de Proiect trebuie s prevad timp i resursepentru planificarea n detaliu a fiecrei etape a proiectului (nainte de finalizareaetapei precedente).


31/87



Pagina 31 din 87

5.2.3 Controlul proiectului

Plecnd de la ideea c orice activitate din cadrul proiectului este planificat, apoi

monitorizat i apoi supus controlului, activitile de control au ca obiectivgarantarea faptului c, la orice nivel al echipei de management, nivelul superior demanagement poate:

monitoriza progresul

compara realizrile cu planificarea

identifica probleme

iniia msuri corective

autoriza activiti suplimentare

5.2.3.1 Mijloace de ControlLa nivelul Comitetului de Conducere al Proiectului, controlul se va realiza prinexcepie. 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 deedine de evaluare a progresului. Managerul de Proiect are controlul activitilor dezi cu zi ale proiectului n cadrul unei etape, n limitele de toleran aprobate. Numain momentul n care Managerul de Proiect consider c Planul de Etap nu maipoate fi realizat n limitele de toleran care au fost aprobate de ctre Comitetul deConducere al Proiectului odat cu Planul de Etap, atunci el va realiza un Plan deExcepie pe care l va nainta Comitetului de Conducere al Proiectului, mpreun cuun Raport de Excepie.

Mijloacele principale de control la dispoziia Comitetului de Conducere alProiectului sunt:

Iniializarea Proiectului (Aprobarea documentelor de iniializare aleproiectului, 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 subcontrol? 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 devierede la limitele de toleran aprobate)

Verificare Intermediar de Etap (Comitetul de Conducere al Proiectuluianalizeaz 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 ProiectuluiScopul etapei de Iniializare a Proiectului este aceea de a stabili toate detaliileproiectului, nainte de a autoriza demararea acestuia :

obiectivele proiectului


32/87



Pagina 32 din 87

justificarea proiectului

identificarea Beneficiarului

cine are responsabilitatea i autoritatea n cadrul proiectului

limitele proiectului i interfeele proiectului cu exteriorul

modalitatea de atingere a obiectivelor

care sunt presupunerile care au fost fcute

care sunt riscurile existente care pot mpiedica atingerea obiectivelorproiectului

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 alProiectului, care este principalul livrabil al acestei etape.

Un alt livrabil important al etapei de iniializare este Planul de Etap al etapeiurmtoare celei de Iniializare, astfel nct dac Comitetul de Conducere alProiectului aprob Etapa de Iniializare, s se poat demara imediat prima etap aproiectului.

Avnd n vedere faptul c la sfritul fiecrei etape Comitetul de Conducere alProiectului analizeaz rezultatele etapei i hotrte demararea unei noi etape,

fixarea numrului de etape i al componenei acestora este un important mijloc decontrol al Comitetului de Conducere al Proiectului. Stabilirea etapelor are loc ncadrul Etapei de Iniializare a proiectului.

5.2.3.3 Controlul progresului proiectuluiPe parcursul derulrii proiectului trebuie n permanen meninut controlul asupraprogresului. 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 planificriiiniiale, trebuie gsit o balan ntre un control prea strns care s oblige Managerulde 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 nsemnac 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. Pentrustabilirea unei linii de demarcaie ntre cele dou situaii se folosete conceptul deToleran.

Cele dou elemente de baz ale Toleranei sunt:

timpul

costul


33/87



Pagina 33 din 87

Tolerana este deviaia permis de la Planul de Proiect sau de la Planul de Etap carepoate fi acceptat fr a fi necesar informarea Comitetului de Conducere alProiectului. 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 deConducere al Proiectului poate stabili noi tolerane pentru Etapa respectiv, attatimp ct acestea se pstreaz n limitele toleranelor stabilite pentru ntregul proiect.Dac se previzioneaz c toleranele ntregului proiect vor fi depite, atunciComitetul de Conducere al Proiectului trebuie s hotrasc modalitatea decontinuare a proiectului, n consultare cu conducerea instituiei Beneficiarului.

Atta timp ct evoluia proiectului (linia verde Planul de proiect curent) sepstreaz n limitele de Toleran stabilite (liniile roii Limite de Toleran ), atunciManagerul de Proiect poate conduce proiectul fr implicarea Comitetului deConducere al Proiectului. n momentul n care se previzioneaz faptul c deviaiaplanului curent (linia verde - Planul de proiect curent) de la planul de proiectaprobat (linia albastr Planul de proiect iniial) va depi limitele de toleranaprobate (liniile roii - Limite de Toleran ), atunci Managerul de Proiect aplicprocedura 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 acestordescrieri este acela ca fiecare persoan implicat n procesul obinerii livrabilului scunoasc:

de ce este necesar un anumit livrabil

cum va arta un anumit livrabil

din ce surse va fi obinut livrabilul

care sunt specificaiile de calitate cu care trebuie s fie conform livrabilul

Cost

Timp

Planul de proiect

iniial

Planul de proiectcurent

Limite deToleran

Limite deToleran

Figura 4: Toleranele proiectului


34/87



Pagina 34 din 87

Descrierea livrabilului este un document de control, care este creat ca parte aprocesului de planificare. Documentul definete livrabilul, standardele care vor fifolosite 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. Aceasteinformaii nu sunt importante numai pentru persoana responsabil cu obinerealivrabilului, dar constituie i o prim gril de control a calitii livrabilului, odatacesta realizat.

Descrierile Livrabilelor nsoesc Structura Defalcat a Livrabilelor proiectului, careface parte din Planul de Proiect. Din acest motiv, Descrierile Livrabilelor suntaprobate de ctre Comitetul de Conducere al Proiectului. n momentul n careManagerul de Proiect autorizeaz diferite Pachete de Lucru care vor fi executate depersoanele din cadrul echipei de proiect, documentele de Descriere a Livrabilelorvor 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 Proiectcomand unei persoane sau unui grup demararea unui set de activiti n cadrul uneiEtape. Cu alte cuvinte, toate activitile din cadrul proiectului trebuie autorizate dectre Managerul de Proiect nainte de a fi demarate.

Pachetul de Lucru va conine Descrierea Livrabilelor, precum i constrngerilereferitoare la timp i cost, interfeele cu alte Pachete de Lucru, necesitile deraportare, cerinele care trebuie realizate n vederea predrii livrabilului ctreBeneficiar, precum i orice alt documentaie necesar n vederea nelegerii i aimplementrii Pachetului de Lucru. Toate activitile pe care Furnizorul le va sub-contracta vor fi oficializate prin Pachete de Lucru.

5.2.3.3.4 Controlul calitii

Proiectul necesit proceduri i tehnici pentru controlul calitii livrabilelor pe care leproduce. Tipurile de controale de calitate difer n funcie de tipul de livrabil pentrucare sunt dezvoltate. Indiferent de modalitatea tehnic de realizare a controluluicalitii, exist un proces generic care se va aplica n toate aceste cazuri. Acestproces este acela de edin de Verificare a Calitii.

edina de Verificare a Calitii face parte din metodele de control ale calitii. Esteo munc n echip prin care se asigur calitatea printr-un proces de verificare.Obiectivul edinei de Verificare a Calitii este acela de a se inspecta livrabilul ntr-o manier planificat, obiectiv, controlati documentat. Documentele edinelorde Verificare a Calitii formeaz o dovad documentar a faptului c livrabilele aufost inspectate, c toate erorile identificate au fost corectate i c toate coreciilefcute au fost, la rndul lor, verificate.

edinele de Verificare a Calitii pot fi utilizate pentru controlul calitiidocumentelor (tehnice sau de management). n funcie de tipul de livrabil care esteinspectat, 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 devedere al numrului de utilizatori)


35/87



Pagina 35 din 87

teste de volum (testarea rspunsului sistemului n condiiile simulrii uneincrcri 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 tratezeposibilele deviaii de la specificaiile aprobate. Aceste deviaii pot apare din maimulte 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 livrabilelorproiectului

imposibilitatea Furnizorului de a livra tot ceea ce este contractat n limitelede timp i cost stabilite

eecul unui subcontractor de a-i ndeplini obligaiile asumate i planificate

incertitudine asupra posibilitii Furnizorului de a rezolva o anumit cerinfuncional

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 sedesfoar fr cunotina nivelelor de management relevante, inclusiv aComitetului de Conducere al Proiectului. Pe lng controlul asupra eventualelorschimbri n cadrul proiectului, procedura furnizeaz o cale oficial prin care toatentrebrile sau cererile pot fi formulate. Procedura presupune nregistrarea i tratareatuturor Problemelor de Proiect semnalate pe durata proiectului. De asemenea,procedura ofer control asupra modalitii de tratare a acestor probleme i asigurcomunicarea napoi ctre originatorul problemei a rezoluiei finale asupra problemein 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 schimbrilesolicitate sunt documentate sub form de Probleme de Proiect. Procedura de Controlal Schimbrii trebuie s trateze aspecte cum ar fi evaluarea impactului schimbriisolicitate, 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


36/87



Pagina 36 din 87

analiza acestora, contramsurile planificate i starea fiecrui risc n parte. Acestproces demareaz odat cu nceperea proiectului i se continu pe ntreaga durat adesfurrii acestuia. Toate riscurile trebuie revzute n mod regulat (cel puin la

sfritul fiecrei etape, dari 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 verificarede ctre Managerul de Proiect a stadiului unei anumite Etape a proiectului. La acesteedine particip cei implicai n activitile etapei respective. n funcie deanvergura proiectului i de organizarea acestuia, edinele de control pot fideclanate de ctre Managerul de Proiect sau de ctre efii de Echip. Obiectivulprincipal al unei edine de control este acela de a verifica toate aspectele proiectuluicomparativ cu planurile, pentru a se asigura c nu exist probleme neidentificatecare pot afecta desfurarea proiectului.

Informaiile adunate n cadrul edinelor de Control formeaz baza documentar nfuncie de care Managerul de Proiect va pregti Raportul de Stare ctre Comitetul deConducere al Proiectului. Frecvena Punctelor de Verificare i a edinelor aferenteva fi stabilit de ctre Managerul de Proiect n funcie de complexitatea i durataproiectului, 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 ctreComitetul de Conducere al Proiectului cu o frecven stabilit de ctre Comitetul deConducere al Proiectului (bi-lunar sau lunar), n funcie de durata etapei curente saun funcie de riscurile existente n etapa respectiv. Coninutul Raportului de Stareeste 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 alProiectului s realizeze management-ul prin excepie pe durata unei Etape deproiect. n condiiile n care Planul de Etap i Toleranele etapei sunt stabilite,Comitetul de Conducere al Proiectului este ntiinat asupra progresului realizat prinintermediul Rapoartelor de Stare. n momentul n care se previzioneaz deviaii dela Planul de Etap, Comitetul de Conducere al Proiectului este ntiinat prinintermediul unui Raport de Excepie.

5.2.3.3.10 Raport de Excepie

Un Raport de Excepie este o avertizare din partea Managerului de Proiect ctreComitetul de Conducere al Proiectului referitor la faptul c o anumit etap (sauntreg proiectul) va devia n afara limitelor de toleran stabilite. Rapoartele deExcepie trebuie documentate.

Un Raport de Excepie descrie o deviaie previzionat, furnizeaz o analiz att aexcepiei aprute ct i a variantelor de continuare i identific opiunearecomandat. Un Raport de Excepie duce la organizarea unei Verificri


37/87



Pagina 37 din 87

Intermediare de Etap i constituie baza pentru realizarea unui Plan de Excepiepentru opiunea recomandat n vedere continurii proiectului.

5.2.3.3.11 Verificarea de Sfrit de EtapUnul din obiectivele mpririi proiectului n Etape este acela de a permiteComitetului de Conducere al Proiectului aprobarea individual a fiecrei Etape aproiectului. La sfritul fiecrei etape, Comitetul de Conducere al Proiectuluiverific 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 deSfrit de Etap este obligatorie la sfritul fiecrei Etape. n cadrul verificrii setrece n revisti se aprob activitatea desfurat pn n acel moment, justificndevoluia ntr-o nou faz a proiectului. O Etap de proiect nu va fi consideratfinalizat 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 riscurilori se verific stadiul general al proiectului,rezultatele fiind ncorporate n urmtorul Plan de Etap i n Planul deProiect

se revd toleranele pentru urmtoarea Etap

se autorizeaz trecerea proiectului n urmtoarea Etap

Comitetul de Conducere al Proiectului poate refuza aprobarea urmtorului Plan deEtap, dac este nemulumit de unele din aspectele evaluate. n aceste condiii, poatesolicita Managerului de Proiect modificarea Planului de Etap, poate recomandanchiderea prematur a proiectului sau poate apela la arbitrarea unei autoritisuperioare de decizie.

5.2.3.3.12 Raportul de Sfrit de Etap

Raportul de Sfrit de Etap este modalitatea prin care Managerul de Proiectinformeaz Comitetul de Conducere al Proiectului asupra rezultatului unei Etape aproiectului. Comitetul de Conducere al Proiectului va compara aceste rezultate cuPlanurile 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 alProiectului i Managerul de Proiect dup primirea unui Raport de Excepie.Obiectivul acestei verificri este acela de a-i permite Managerului de Proiect sprezinte Comitetului de Conducere al Proiectului un Plan de Excepie i s obinaprobarea acestuia pentru implementarea planului.


38/87



Pagina 38 din 87

5.2.3.4 Controlul nchiderii proiectuluinainte de a aproba nchiderea proiectului, Comitetul de Conducere al Proiectuluiare 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 pentrusuportul i ntreinerea livrabilelor pe durata lor de via

nainte de nchiderea proiectului, Comitetul de Conducere al Proiectului trebuie sconfirme n scris acceptana sa referitor la ncheierea proiectului. Aceast acceptanpoate fi acordat chiar dac exist deficiene minore n livrabilele furnizate, cucondiia 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 dupncheierea proiectului; poate nu s-a finalizat transferul tuturor livrabilelor, sau poateexist probleme nc nerezolvate la unele livrabile.

Documentul privind Recomandrile cu privire la activitile nefinalizate identifictoate activitile nefinalizate, permind Comitetului de Conducere al Proiectului satribuie aceste activiti persoanelor a cror sarcin va fi s revad acesterecomandri 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 acoperntregul proiect. Acest Raport trece n vedere modul n care proiectul a fost condus,inclusiv performana fa de Documentele de Iniializare ale Proiectului.


39/87



Pagina 39 din 87

5.2.4 Management-ul Riscurilor

Management-ul riscurilor reprezint o component esenial n cadrul management-

ului de proiect, ntruct riscurile reprezint factori majori ce trebuie luai nconsiderare n procesul de planificare, monitorizare i control al proiectului.

Riscul poate fi definit ca fiind un eveniment nesigur sau un set de circumstanecare, odat aparut(e), are(au) efect (negativ) n atingerea obiectivelor proiectului.

Proiectele au ca scop implementarea schimbrilor, ceea ce determin ca efortul deimplementare s nu fie ntotdeauna predictibil i astfel probabilitatea materializriiunui risc pe parcursul derulrii unui proiect nu poate fi ignorat.

5.2.4.1 Tipuri de riscuriCteva din riscurile tipice ale unui proiect IT sunt (cu titlu de exemplu):

probleme legate de furnizori:o eecul identificrii unor furnizori corespunztori;

o eecul livrarii produselor de ctre furnizori i sub-contractori;

o probleme contractuale.

factori organizaionali:

o responsabiliti adiionale pentru personalul din proiect, pe lngactivitile de proiect;

o cultura educaional (sau lipsa e

ghid_metodologic

Documents