Documente Academic
Documente Profesional
Documente Cultură
Ghid Metodologic
Ghid Metodologic
TITLU:
DESCRIERE:
AUTORI:
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.
CONTROLUL DOCUMENTULUI
1.1
Proprietarul documentului
1.2
Istoricul documentului
1.3
Modificri viitoare
1.4
Bibliografie
1.5
Abrevieri
2.
INTRODUCERE
2.1
Necesitate
2.2
Structur i obiective
2.3
Grup int
3.
ANALIZA SITUAIEI EXISTENTE CU PRIVIRE LA
IMPLEMENTAREA PROIECTELOR TIC
3.1
Introducere
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
8
8
9
9
10
11
12
12
13
Concluzii
14
4.
DOCUMENTE ELABORATE N VEDEREA LANSRII
PROIECTELOR
4.1
Introducere
4.2
Etapele demarrii proiectului
4.2.1
Etapa pregtitoare
4.2.2
Etapa de achiziie
4.3
5.
Modele de documente
15
Introducere
Pagina 2 din 87
15
15
15
16
17
18
18
Ce este un proiect?
De ce proiectele au nevoie de management?
Arie de aplicabilitate
Alte precizri
Organizarea acestei seciuni
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
18
18
18
19
19
20
20
26
31
39
42
44
46
6.
CAIETUL DE SARCINI CERINE SPECIFICE PRIVIND
MANAGEMENTUL PROIECTELOR
48
6.1
48
6.2
49
6.3
50
6.4
53
6.5
53
6.6
54
6.7
54
6.8
55
ALTE RECOMANDRI
56
7.
7.1
Clauze contractuale
56
7.2
Recomandri diverse
60
7.3
List de verificare a documentelor de proiect
7.3.1
Iniializarea proiectului
7.3.2
Planificare
7.3.3
Raportare
62
62
63
63
8.
GLOSAR DE TERMENI
64
9.
ANEXE
66
9.1
67
9.2
73
Pagina 3 din 87
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
75
76
76
78
79
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
81
83
83
84
85
85
86
86
87
1.
CONTROLUL DOCUMENTULUI
Data reviziei
Autor
Sumarul schimbrilor
Ver. 00.01
04.07.2005
ANIAP
Ver. 00.02
15.07.2005
ANIAP
Ver. 00.03
16.07.2005
ANIAP
Ver. 1.00
18.07.2005
ANIAP
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
Pagina 7 din 87
3.
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
Pagina 9 din 87
Pagina 10 din 87
Pagina 11 din 87
Pagina 12 din 87
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.
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
Pagina 15 din 87
Pagina 16 din 87
Pagina 17 din 87
5.
5.1 Introducere
5.1.1 Ce este un proiect?
Un Proiect reprezint modalitatea de organizare funcional a resurselor (umane i
de alt natur) n vederea realizrii unui obiectiv bine stabilit.
Un proiect se definete ca o succesiune de procese nerepetitive n scopul realizrii
unor livrabile noi, bine definite, n cadrul unei organizaii special create pentru acest
scop, n cadrul unor constrngeri de timp, calitate i cost.
5.1.2 De ce proiectele au nevoie de management?
Indiferent de dimensiunea unui proiect sau de complexitatea acestuia, ndeplinirea
obiectivelor nseamn atingerea standardelor de calitate propuse, n limitele de timp
i de buget stabilite.
O metodologie de management de proiect pune la dispoziie o serie de componente
i procese care s ajute n procesul de planificare, monitorizare i control i care s
asigure c proiectul va fi realizat la timp, cu bugetul alocat, la nivelul de calitate
programat i cu atingerea tuturor obiectivelor propuse.
5.1.3 Arie de aplicabilitate
Metodologia de management de proiect prezentat n cadrul acestei seciuni se poate
aplica n cadrul oricrui tip de proiect TIC, fie el realizat cu ajutorul unui furnizor
fie numai cu resurse interne ale autoritii locale .
Din punctul de vedere al dimensiunii sau complexitii proiectelor n care aceast
metodologie se poate aplica, nu exist restricii generale. Indiferent de
considerentele de complexitate sau dimensiune, utilizarea unei abordri
metodologice crete ansele de succes ale proiectelor. Din acest motiv, singura
variabil n cazul folosirii unei metodologii este nivelul de detaliere i de
complexitate necesar deciziile n aceast direcie aparin Manager-ului de Proiect.
Metodologia de Management de Proiect are menirea de a ajuta Manager-ul de
Proiect n derularea proiectului i nu de a crea o povar administrativ asupra
acestuia i a echipei de proiect. Din acest motiv, este esenial ca procedurile i
cantitatea de documente administrative folosite n cadrul proiectului s fie justificate
de anvergura acestuia. Metodologia nu este un scop n sine; obiectivul nu este
aplicarea metodologiei, ci finalizarea cu succes a proiectului, iar metodologia este
doar o unealt n atingerea acestui obiectiv. Urmtorul tabel prezint o recomandare
n ceea ce privete gradul de detaliere a diferitelor componente ale metodologiei de
management de proiect n funcie de dimensiunea proiectului. Modalitatea de
determinare a dimensiunii proiectului este prezentat n Anexa 2:
Componenta metodologiei / Dimensiunea
proiectului
MIC
MEDIU MARE
Organizarea proiectului
Sumar
Detaliat
Detaliat
Planificare
Sumar
Detaliat
Detaliat
Managementul riscurilor
Sumar
Sumar
Detaliat
Managementul calitii
Sumar
Detaliat
Detaliat
Pagina 18 din 87
Controlul proiectului
Sumar
Detaliat
Detaliat
Managementul configuraiilor
Sumar
Sumar
Detaliat
Managementul schimbrii
Detaliat Detaliat Detaliat
ntruct majoritatea proiectelor TIC de anvergur din cadrul administraiei publice
locale sunt realizate cu ajutorul furnizorilor , iar conducerea i organizarea
proiectului sunt de obicei activiti n sarcina furnizorului, toate formulrile din
cadrul acestei seciuni a Ghidului sunt fcute n contextul unui furnizor . Cu toate
acestea, dup cum am precizat la nceputul acestei sub-seciuni, metodologia
prezentat se poate aplica i n cazul n care furnizorul este chiar Departamentul TIC
din cadrul autoritii locale .
5.1.4 Alte precizri
Seciunea 5 cuprinde noiuni de baz privind modul n care trebuie realizat
managementul de proiect pe ntreaga durat a desfurrii proiectului. Chiar dac
anumite sarcini de management de proiect vor fi ndeplinite i de ctre Beneficiar
prin intermediul unui Coordonator de Proiect numit de ctre acesta (din cadrul
organizaiei Beneficiarului sau angajat pe baza unui contract de consultan), acest
Ghid pleac de la ipoteza c responsabilitatea principal pentru furnizarea tuturor
serviciilor de management de proiect revine Furnizorului. Din aceast perspectiv,
n afara cazului n care se indic explicit altfel, orice referire (din cadrul acestui
Ghid) la Managerul de Proiect i la ndatoririle acestuia precum i la organizarea i
coordonarea activitilor de management al proiectului vor fi nelese ca fiind n
sarcina Furnizorului.
Att Furnizorul ct i Beneficiarul pot opta pentru folosirea acestei metodologii sau
a unei alte metodologii similare.
n situaia achiziiilor publice recomandm ca Ofertantului s i se cear prin Caietul
de Sarcini s prezinte detaliat n oferta sa modalitatea practic n care va implementa
n cadrul proiectului metodologia propus , n conformitate cu cerinele specifice
prezentate n seciunea 6. n acest sens, recomandm s nu se accepte n cadrul
ofertelor referirea la un standard de metodologie fr prezentarea detaliat a
modalitii n care se vor trata aspectele prezentate n aceast seciune.
5.1.5 Organizarea acestei seciuni
Aceast seciune prezint succesiv componentele principale ale unei metodologii de
management de proiect, precum i metodele prin care aceste componente se
regsesc n cadrul unui proiect. Astfel, aceast seciune a Ghidului trateaz
urmtoarele aspecte legate de managementul de proiect:
Organizarea proiectului
Planificarea proiectului
Controlul proiectului
Management-ul riscurilor
Calitatea
Management-ul configuraiilor
Management-ul schimbrilor
Pagina 19 din 87
Pagina 20 din 87
Reprezentant
Utilizator
Reprezentant
Beneficiar
Reprezentant
Furnizor
Rol 1
Rol 3
Rol 2
Rol 4
Manager Proiect
Echipa de Suport
a Proiectului
Sef Echipa
Sef Echipa
Rol 1
Rol 1
Rol 2
Rol 2
Rol 3
Rol 3
Pagina 21 din 87
Pagina 22 din 87
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)
Pagina 24 din 87
Pagina 25 din 87
Pagina 26 din 87
Plan de Proiect
Plan de Etap
Plan de Excepie
Plan de Lucru al
Echipei
Pagina 27 din 87
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
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
Pagina 29 din 87
Pagina 30 din 87
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
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
Pagina 33 din 87
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
Pagina 34 din 87
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
Pagina 36 din 87
Pagina 37 din 87
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
Cteva din riscurile tipice ale unui proiect IT sunt (cu titlu de exemplu):
probleme legate de furnizori:
o
probleme contractuale.
factori organizaionali:
o
Pagina 39 din 87
Pagina 40 din 87
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
Pagina 42 din 87
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
Pagina 44 din 87
cu
Management-ul
Configuraiilor
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
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.
Pagina 48 din 87
obiectivele proiectului
constrngeri
necesarul de informaie
sursa informaiilor
frecvena comunicrii i
coninutul comunicrii
Pagina 49 din 87
Planul Iniial de Proiect, care va prezenta cum i cnd vor avea loc activitile
proiectului
o
Dependene externe
Ipoteze de planificare
Pachetele de Lucru
Resursele necesare
Pagina 50 din 87
Pagina 51 din 87
Pagina 52 din 87
Pagina 53 din 87
Pagina 54 din 87
100
Organizarea proiectului
30
Manager de Proiect
20
Echipa de proiect
10
15
Planul de Riscuri
10
Planul de Proiect
15
Descrierea Livrabilelor
Diagrama Gantt
10
10
Planul de Acceptan
10
Pagina 55 din 87
60
10
7.
ALTE RECOMANDRI
Pagina 56 din 87
Pagina 57 din 87
Pagina 58 din 87
Anexa 1
- Descrierea Produselor
Anexa 2
- Descrierea Serviciilor
Anexa 3
- Lista de Preuri
Anexa 4
- Graficul de ndeplinire
Anexa 5
Anexa 6
- Graficul de pli
Pagina 59 din 87
Reprezentantul Utilizatorilor:
Pagina 60 din 87
general/manager
general
sau
reprezentant beneficiar:
viceprimar
Pagina 61 din 87
subsistem
Pagina 62 din 87
dependene
ipoteze
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
Project Scope
Biblioteca de Proiect
Project Library
Cerere de Schimbare
Change Request
Contingency
Controlul Schimbrii
Change Control
Descrierea livrabilului
Product description
Escalation (process)
Iniializarea Proiectului
Project Initiation
Business Case
Livrabil
Deliverable
Managementul Configuraiilor
Configuration Management
Manager de Proiect
Project Manager
Pachet de Lucru
Work Package
Plan de Etap
Stage Plan
Plan de Excepie
Exception Plan
Team Plan
Plan de Proiect
Project plan
Presupunere
Project Prerequisites
Problem de Proiect
Project Issue
Puncte de Verificare
Checkpoints
Raport de Stare
Highlight Report
Raport de Excepie
Exception Report
Recomandrile
nefinalizate
cu
privire
la
Referina proiectului
Project Baseline
Registrul Riscurilor
Risk Register
Reprezentantul Beneficiarului
Executive
Reprezentantul Furnizorului
Senior Supplier
Reprezentantul Utilizatorului
Senior User
Scenariu de Test
Test Script
Pagina 64 din 87
Quality Review
Toleranele Proiectului
Project Tolerances
MidStage Assessment
nchiderea Proiectului
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
Ctre:
Ref.:
Titlul proiectului:
Beneficiar:
Furnizor:
Departamentul IT
Pagina 67 din 87
Semntura
Activitile necesare
pentru obinerea
sprijinului grupului
Modalitatea de
implicare n
proiect
Obiectivele Proiectului
Rezultatele proiectului
Obiectivul 1
Rezultatul 1
Rezultatul 2
Obiectivul 2
...
...
Pagina 68 din 87
Rezultate-Indicatori
Rezultatul 1:
Indicator 1:
Indicator 2:
.
Rezultatul 2:
Indicator 1:
Indicator 2:
.
..
Pagina 69 din 87
Modaliti de verificare a
atingerii rezultatelor
Rezultate
Activiti/
Data de ncepere
Subactiviti
Rezultatul 1
Activitatea 1.1
Subactivitatea 1.1.1
Subactivitatea 1.1.2.
Activitatea 1.2.
Subactivitatea 1.2.1
Rezultatul 2
Activitatea 2.1.
.
Punct de Control 1
Rezultatul 3
Punct de Control 2
..
L1, L2, L3 etc. semnific luna n care se deruleaz activitatea respectiv.
Pagina 70 din 87
Data de sfrit
L1
L2
L3
L4
L5
L6
L7
L8
L9
Scopul proiectului:
Obiectivele proiectului:
Rezultatul 1:
Activiti pentru
Rezultatul 1
Resurse
Costuri
UM
Cantitate
Preul
unitar
TOTAL
5=4 x 3
CATEGORIA DE CHELTUIELI
UM
Cantitate
Preul
unitar
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
L1
L2
...
...
L9
Total
(*)
TOTAL
(*) Se trec categoriile din tabelul de la punctul 11 de mai sus.
13. Posibiliti de dezvoltare i durabilitate ale proiectului
(Durabilitatea este o cerin major pentru un proiect de succes. Prezentai modul n care vei
asigura continuarea activitilor i vei obine rezultate i dup terminarea proiectului.
Detaliai veniturile preconizate a se obine din activitatea proiectului, precum i cheltuielile
pentru primii 3 ani; Argumentai aceste estimri.)
Pagina 72 din 87
MEDIU
MARE
Numrul de persoane 1 - 2
din echipa de proiect
25
5+
Durata
< 6 luni
6 12 luni
> 12 luni
Planificarea proiectului
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
Complexitate
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
Importana strategic
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
Cost total
< 25.000
25.000 250.000
250.000+
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
Pagina 75 din 87
Pagina 76 din 87
Pagina 77 din 87
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
Pagina 79 din 87
Pagina 80 din 87
|
|
|
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
|
Pagina 81 din 87
<numele aplicantului>
(Nume, prenume)
(numrul, strada, cod potal, ora,
ara)
|
|
|
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
|
|
Pagina 82 din 87
satisfctor)
(Descriei aceste aptitudini i
indicai contextul n care le-ai
dobndit)
(Descriei aceste aptitudini i
indicai contextul n care le-ai
dobndit)
Management-ul Proiectelor IT
in Administratia Publica
- document de analiza -
Sectiune explicativa:
Scopul urmatorului chestionar este acela de a identifica problemele tipice ale proiectelor IT
derulate in cadrul Administratiei Publice din Romania care pot fi rezolvate prin
implementarea unui sistem mai eficient de Management al Proiectelor atat din partea
furnizorului cat si din partea organizatiei client. Va rugam sa raspundeti la intrebarile din
urmatorul chestionar folosind pe cat posibil fraze explicative (nu numai da si nu). Acest
lucru ne va permite sa analizam in profunzime problemele reale cu care va confruntati si sa
putem identifica cele mai eficiente metode de rezolvare.
Va multumim.
9.6.1 INTRODUCERE
1.
Care este numarul de proiecte IT derulate in cadrul organizatiei dumneavoastra in ultimii 5 ani? Dati
detalii.
2.
Care sunt caracteristicile proiectelor IT derulate in cadrul organizatiei dumneavoastra (ex. Buget,
durata, tip proiect achizitie de echipamente sau licente standard, solutie software, sistem integrat
hard-soft)?
3.
Ce tipuri de proiecte de implementare de aplicatii software ati derulat sau intentionati sa derulati (ex.:
Sistem Financiar-Contabil, Resurse Umane si Salarizare, Taxe si Impozite, Management-ul
documentelor si al fluxului de documente, arhivare electronica, solutii geospatiale GIS, portal WEB,
altele)?
4.
5.
6.
Cine considerati ca are rolul principal in coordonarea proiectului: furnizorul sau beneficiarul? Va
rugam comentati.
7.
In contextul intrebarii nr. 5, care credeti ca sunt indatoririle principale ale furnizorului si ale
beneficiarului (din punctul de vedere al conducerii proiectului)?
8.
9.
Pagina 83 din 87
Pagina 84 din 87
Pagina 85 din 87
Pagina 86 din 87
Pagina 87 din 87