1

C.S.I.DR.ING:TEFAN KOVACS,..

MANAGEMENTUL PROIECTELOR

2014-2015

5INTRODUCERE

14DEFINIII,CARACTERISTICI,ETAPE N DEZVOLTAREA UNUI PROIECT

14CE ESTE UN PROIECT?

15CARACTERISTICI ALE PROIECTELOR

17STRUCTURAREA UNUI PROIECT FOLOSIND CHECK-LIST-URILE

20VALORI CONSIDERATE N MANAGEMENTUL PROIECTELOR

23SUCCESUL I EECUL PROIECTELOR

26ETAPE DE REALIZARE A PROIECTELOR I MANAGEMENTUL ACESTORA

30CONDUCERE=MANAGEMENT ?

32ETAPELE DE DEZVOLTARE A UNUI PROIECT-IMAGINE GENERAL

33ETAPA DE DOCUMENTARE

34ETAPA DE DEFINIRE GENERAL A CERINELOR-NELEGEREA PROBLEMELOR UTILIZATORULUI

36PLANIFICAREA PROIECTULUI

37Calculul costului proiectelor

38Etapizarea proiectului

38Coninutul planului preliminar al proiectului

38Propunerea

38Aspecte negociabile ale unui proiect

39FAZA DE ANALIZ A PROIECTULUI

42FAZA DE PROIECTARE(DESIGN)

44Module structurate

44Coninutul specificaiei de design

44Testarea designului

45Planul de acceptan a testelor de design

46FAZA DE DEZVOLTARE A PROIECTULUI

47Faza de testare a sistemului rezultat n urma proiectului

50ETAPA DE IMPLEMENTARE LA UTILIZATOR I TESTARE A ACCEPTANEI PRODUSULUI FINIT

50FAZA DE OPERARE,NTREINERE,MENTENAN

51FAZE I PROCESE N MANAGEMENTUL PROECTELOR

51FAZELE PROIECTULUI

52a)Definirea strategiilor folosite n proiect i realizarea business case necesare

54b)Pregtirea

55c)Design-ul (proiectarea)

55d)Dezvoltarea i testarea

57e)Asigurarea instruirii personalului n utilizarea noului sistem

60STUDIU DE CAZ

81ANALIZA OPERAIONAL-BAZA UNUI MANAGEMENT DE PROIECT CORECT I OPTIMAL

92PLANIFICAREA PROIECTELOR

92ASPECTE GENERALE

94DEFINIREA SARCINILOR I ACTIVITILOR ELEMENTARE DIN CADRUL PROIECTULUI

94GRAFICE WBS

98Dependine(Dependencies)

99ntrzieri(Lag)

99Date de constrngere(Constraint Date)

99Tipuri de constrngeri(Constraint Type)

100EXEMPLU

103EVALUAREA EFORTULUI NECESAR PENTRU REALIZAREA PROIECTULUI

103MODELUL COCOMO DE CALCUL A COSTURILOR

106Distribuia efortului pe fazele de dezvoltare a proiectului

108Estimarea mrimii software-ului (numrul de linii de cod)

108Exemplu de aplicare Cocomo

109EVALUAREA BUGETULUI PROIECTULUI (COSTURILOR NECESARE PENTRU REALIZAREA PROIECTULUI)-MODELE DE COST PARAMETRICE

112Sarcini

114Parametrii

114Mecanismul Solver

115PLANIFICAREA TEMPORAL A PROIECTELOR

117GRAFICE GANTT

117GRAFICE PERT

118Fig..Model general de structur PERT

121PLANIFICAREA TEMPORAL A PROIECTELOR CU MICROSOFT PROJECT

126MANAGEMENTUL RESURSELOR UMANE N CADRUL PROIECTULUI

128PLANIFICAREA ORGANIZAIONAL

128Intrri n cazul planificrii organizaionale

129Instrumente i tehnici legate de planificarea organizaional

129Ieiri rezultate din planificarea organizaional

131CONSTITUIREA ECHIPEI DE LUCRU

1323.6.2.1.Intrri referitoare la constituirea echipei de lucru

132Instrumente i tehnici pentru achiziia personalului

132Ieiri ale fazei de achiziie a personalului

132DEZVOLTAREA ECHIPEI

133Intrri ale fazei de dezvoltare a echipei

133Instrumente i tehnici pentru dezvoltarea echipei

133Ieirile fazei de dezvoltare a echipei

134ROLUL MANAGERULUI DE PROIECT (PROJECT MANAGER)

138SPECIFICAREA CORECT A CERINELOR UTILIZATORULUI

138Aspecte generale

139Analiza problemei

139Structurarea informaiilor

140Diagrama fluxului de date

142Dicionarele de date

143Analiza structurat

143Prototipizarea

144Alte metode de analiz

146Specificarea cerinelor

146CARACTERISTICI ALE DSC

146COMPONENTE ALE DSC

147Cerine funcionale

148Cerine de performan

148Cerine legate de design

149Cerine referitoare la interfee externe

149LIMBAJE DE SPECIFICARE

150STRUCTURA UNUI DOCUMENT DE SPECIFICARE A CERINELOR

151VALIDAREA CERINELOR

151Citirea

151Construirea de scenarii

151Revizuirea cerinelor

152Referinele ncruciate automate

153METRICI ALE PROIECTULUI

154FOLOSIREA MODELRII N REALIZAREA I MANAGEMENTUL PROIECTELOR

154ASPECTE GENERALE

154MODELE I MODELARE

155MODELUL ENTITATE-RELATIE

157DIAGRAMA DE FLUX DE DATE (DFD) CA MODEL AL FLUXULUI DE DATE AL SISTEMULUI

159Procese

160Fluxuri de date

162DESIGNUL PROIECTULUI

162ASPECTE GENERALE

162PRINCIPII DE DESIGN

163CONCEPIA MODULAR

164INSTRUMENTE DE DESIGN

165ANALIZA RISCURILOR

168STUDIU DE CAZ

176.MONITORIZAREA I CONTROLUL PROIECTELOR

179ASPECTE GENERALE

182INSPECII I REVIZUIRI

185Procesul de revizuire

188GRAFURI COST-PLANIFICARE-PUNCTE CHEIE

189METODA VALORII CTIGATE (EARNED VALUE METHOD)

191TERMENI FOLOSII N METODA VALORII CTIGATE

193FIIERE DE DEZVOLTARE UNITAR

195MANAGEMENTUL RISCURILOR

195ASPECTE GENERALE

195ACTIVITI DE MANAGEMENT A RISCURILOR

200IDENTIFICAREA RISCURILOR

202ANALIZA I PRIORITIZAREA RISCURILOR

203METOD SIMPL DE EVALUARE A RISCURILOR N CADRUL UNUI PROIECT

204PROGRAMUL RISK TRAK

227MANAGEMENTUL SCHIMBRII I MANAGEMENTUL DE PROIECT

230ASPECTE SPECIFICE

232BENEFICII ALE MANAGEMENTULUI SCHIMBRII

233Cerine necesare pentru managementul schimbrii

239MANAGERUL DE PROIECT

243STUDIU DE CAZ- MANAGEMENTUL UNUI PROIECT DE SISTEM SSM PENTRU O UNITATE ECONOMIC

252Matrici de implicare

868.CONCLUZII

24INTRODUCERE

De ce proiecte ? Pentru c un proiect este modul relativ universal de a face bani. Fie c discutm despre proiecte cu finanare de la stat, proiecte cu finanare European sau proiecte cu finanare privat- toate au n comun termenul PROIECT. Proiect a devenit unul dintre cele mai utilizate cuvinte ale vocabularului de afaceri n general i ale vocabularului actual al limbii romne. Acest lucru se ntmpl deoarece ne confruntm cu o explozie real de proiecte la nivelul economiei mondiale. Tendina exist poate chiar mai pregnant i la nivelul Uniunii Europene. Proiectele de orice tip, mari sau mici, de anvergur sau la scar mai redus reprezint modalitatea prin care organizaiile supravieuiesc n mediul economic actual.

Figura urmtoare prezint ntr-un mod generic etapele unui proiect.

1. Un proiect pleac de la o idee- idee care se bazeaz pe experiena i cunotinele empirice ale propuntorului i evident pe nite surse de documentare. Nu putem avea proiecte din nimic.

2. Se genereaz o schi de proiect- sau un draft. Schia de proiect trebuie s plece de la obiectivele propuse, s valideze aceste obiective dup care s gseasc resursele necesare pentru realizarea acestor obiective. Schia ar trebui s conin i o planificare n timp a activitilor proiectului.

3. Draftul de proiect e validat- de obicei de ctre propuntor i instituia acestuia. Validarea constituie OK-ul pentru a merge mai departe- dac nu, proiectul trebuie reluat.

4. Se elaboreaz forma nominal (final) de proiect. Aici trebuie s fie selectat echipa care se ocup de proiect.

5. Proiectul este naintat spre validare- adic spre verificare. Aceast verificare poate avea loc printr-o competiie- gen POSDRU sau alte proiecte structurale- sau poate fi o validare intern atunci cnd instituia aloc resursele necesare.

6. Odat validat i aprobat- proiectul se pune n mod fizic n micare. Sunt alocate resurse pentru realizarea proiectului- i pe de alt parte realizarea se supune unor constrngeri clar definite.

7. Proiectul este implementat- i poate fi urmrit .

Figura Etapele unui proiect

Proiectele au devenit att de complicate, de diversificate i de complexe, nct s-a creat i o anumit team n jurul lor, un tip de percepie potrivit creia derularea unui proiect reprezint o performan aproape ieit din comun, care poate fi realizat doar de un numr restrns de iniiai. Ca i n cazul altor domenii, teama provine de multe ori din netiin.

Ce este managementul proiectelor ?

Managementul proiectelor poate fi definit ca un sistem de management, un proces dinamic cu o durata de actiune limitata, conceput in vederea solutionarii unor probleme complexe, cu un caracter inovational care implica aportul mai multor specialisti, din subsisteme organizatorice diferite

Managementul proiectelor poate fi perceput ca o tiin, ca o art sau ca o tehnic, prin care se realizeaz un anumit scop. Managementul proiectelor nu este nc pe deplin studiat, ns importana sa este deosebit de mare. Managementul proiectelor reprezint una din activitile omniprezente ale societii moderne, chiar dac sunt foarte puini cei care recunosc sau fac trimitere la o astfel de preocupare. De aceea, obiectivele urmrite vizeaz contientizarea beneficiilor pe care le aduce managementul proiectelor n orice domeniu de activitate, crearea unui vocabular specific domeniului, a abilitilor de concepere a proiectelor, indiferent de domeniul vizat, de gestionare, urmrire i evaluare a lor.

Proiectul reprezinta, n plan informational, modul de agregare sistematica a datelor privind resurse, activitati, costuri, riscuri, termene, n vederea obtinerii unui nivel de credibilitate asupra capacitatii realizatorului sau, pentru obtinerea finantarii efective .

Proiectul reprezinta un grup de activitati ce trebuie realizate ntr-o secventa logica, astfel nct sa se atinga obiectivele prestabilite, cerute de client. n , proiectul este definit ca fiind un ansamblu de activitati cu caracter temporar, ntreprinse cu scopul de a crea un produs sau serviciu unic. Din aceasta definitie, rezulta caracterul temporar al activitatilor din cadrul proiectului si caracterul de unicitate al serviciului sau produsului.

n general, un proiect se caracterizeaza prin:

obiectiv specific;

ciclu de viata;

data de nceput si o data de sfrsit;

un buget;

activitati care sunt unice si nu se repeta;

consum de resurse;

un singur punct de responsabilitate;

roluri si relatii n echipa.

Proiectele sunt activitati temporare, caracterizate de unicitatea conditiilor. Unicitatea este data de obiective, restrictii de timp, cost si performanta, organizatia contractoare, precum si de alte caracteristici. Principalele atribute ale proiectelor sunt complexitatea, noutatea, importanta si gradul de risc. Proprietarul proiectului mpreuna cu membrii echipei stabilesc obiectivele proiectului.

Proiectele se elaboreaza cu oameni, cu tehnica de calcul si, n final, pentru transpunere n practica, sunt necesare importante resurse. Managementul unui proiect da garantia realizarii lui.

Resursele cerute de un proiect variaza foarte mult, n functie de complexitatea acestuia. Astfel, un proiect se poate realiza n cteva saptamni sau poate dura mai multe luni; un proiect poate necesita de la o echipa de ctiva oameni pna la echipe de sute de oameni.

n general, un proiect se considera ca este finalizat cu succes daca sunt respectate restrictiile de timp, cost si performanta. n plus, trebuie avut n vedere ca realizarea proiectului sa se realizeze fara perturbarea fluxului de baza al organizatiei si fara modificarea culturii organizatiei.

Managementul proiectelor este planificarea, organizarea, urmarirea si controlul resurselor unei organizatii pentru un obiectiv pe termen scurt, care a fost stabilit pentru realizarea unor obiective si scopuri specifice .

Managementul proiectelor este definit ca fiind aplicarea de cunostinte, abilitati, instrumente si tehnici n scopul realizarii activitatilor proiectului, n conditiile n care sunt satisfacute nevoile si asteptarile diferitelor parti interesate, implicate n proiect.

Managementul proiectelor reprezinta o noua stiint, rezultat al sintezei unor domenii diferite, avnd ca obiectiv maximizarea eficientei sociale, indiferent de produsul / serviciul ce trebuie realizat.

Obiectivul de baza al managementului de proiect este minimizarea risipei generate de serviciile asupra unor operatii ncheiate, inserarea de operatii noi ntre operatii executate, repetarea executiei de operatii, gestiunea riscului si mentinerea sub control a elementelor de noncalitati. Toate acestea se concretizeaza prin definirea de termene, durate, cantitati, niveluri de calitate, momente de start si de finis, durate obiective de stationare.

Proiectul este rezultatul unor procese iterative de selectie, asa fel nct reprezinta cel mai bun mod de abordare al unui ansamblu de procese, n raport cu un context dat.

n dezvoltarea unui proiect, se iau n considerare aspectele structurilor organizationale, constituirea echipelor, functiile de management, aspectele conflictuale, tehnicile de planificare si variabilele care intervin, alocarea, nivelarea si ncarcarea resurselor pe traseul de tip graf si abordarile n plan economic prin intermediul preturilor estimate, controlului costurilor si, mai ales, prin dezvoltarea unor tehnici de analiza.

Realizarea unui proiect si managementul acestuia sunt procese dinamice, care se conecteaza si a caror eficienta trebuie urmarita continuu, analizndu-se latura calitativa si latura cantitativa a procesului de desfasurare, n raport cu continutul contractelor ncheiate.

Managementul de proiect reprezinta interactiunea elementelor incluse n figura

Figura.Interactiuni n managementul proiectelor Se structureaza managementul pe niveluri (superior, mediu si functional) si se urmaresc aspectele de planificare strategica, latura financiara, alocarea resurselor materiale, umane, financiare. Managementul functiunilor de planificare, de personal, de conformitate, de control si de urmarire a modului n care se efectueaza derularea fazelor activitatii, numai cteva dintre elementele care se regasesc n structura oricarui proiect. Acest nou mod de abordare trebuie sa-si regaseasca reflectare n dezvoltarea de tehnici noi, la nivelul contabilitatii operative, dar si n realizarea de modele de evaluare a desfasurarii proiectului. n acest fel, se vor crea instrumente prin care sa se masoare eficienta cu care se desfasoara proiectele si se aplica o serie de corectii pentru a obtine cresterea acesteia.

Managementul proiectelor presupune planificarea ,controlul si monitorizarea proiectului .

Planificarea proiectului consta n definirea cerintelor de lucru, definirea cantitatii si a calitatii muncii si definirea resurselor necesare.

Monitorizarea proiectului are n vedere urmarirea progresului, compararea rezultatelor actuale cu cele previzionate, analiza impactului si efectuarea de ajustari. Obiectivele managementului proiectelor sunt prezentate n figura urmtoare.

Figura Obiectivele managementului proiectelor

Obiectivele managementului proiectelor sunt:

realizarea cu succes a proiectului, n raport cu obiectivele acestuia,

controlul complexitatii si a dinamicii proiectului,

ajustarea continua a limitelor proiectului,

controlul relatiei dintre proiect si contextul acestuia,

prin realizarea eficienta a subproceselor managementului proiectelor. Figura urmtoare prezint tranziiile activitilor specifice unui proiect.Figura Tranziiile unui proiect

Preluarea proiectului are ca obiectiv definirea unei baze decizionale, luarea deciziilor privind proprietarul proiectului si a managerului proiectului. Preluarea proiectului se ncheie printr-un document scris, semnat de catre proprietarul proiectului ce contine obiectivele, limitele si contextul acestuia. Startul proiectului ncepe dupa ce proiectul a fost preluat si se ncheie o data cu elaborarea documentatiei necesara derularii proiectului. Este o etapa foarte importanta, de succesul acestuia depinznd evolutia viitoare a proiectului. n acest sub-proces, se selecteaza membrii echipei proiectului, precum si metodele si tehnicile ce se vor utiliza pe parcursul desfasurarii proiectului si se clarifica obiectivele acestuia. Principalele documente elaborate n acest sub-proces sunt: structura distribuirii muncii, planul punctelor majore ale proiectului, lista termenelor de realizare, specificarea pachetelor de lucru, diagramele GANTT ale proiectului, diagramele CPM, planul resurselor de personal ale proiectului, planul financiar al proiectului, planul de costuri al proiectului si analiza cost-beneficiu. Controlul proiectului se realizeaza pe baza planului proiectului si are n vedere starea proiectului n anumite perioade prestabilite. n cazul existentei abaterilor, se definesc actiunile corective necesare. Pe masura ce se realizeaza controlul proiectului, se elaboreaza un raport privind progresul proiectului. Coordonarea proiectului se realizeaza n mod continuu, pe toata durata desfasurarii acestuia. Managementul discontinuitatii proiectului poate sa apara n anumite situatii cnd, din diverse motive, desfasurarea proiectului este ntrerupta pentru o perioada de timp, urmnd ca acesta sa continue ntr-un moment ce urmeaza a fi stabilit. ncheierea proiectului are n vedere evaluarea realizarii cu succes a proiectului, efectuarea ultimelor activitati din cadrul proiectului si finalizarea documentatiei proiectului. Acceptarea proiectului se face de catre beneficiarul proiectului, pe baza obiectivelor prevazute n contractul de preluare a proiectului. Exista posibilitatea ca un proiect sa nu fie acceptat.

Rolul managerului de proiect este de a armoniza procesul de integrare a tuturor resurselor care se utilizeaza pentru realizarea unui obiectiv fie el produs sau serviciu. Managementul de proiect are rolul de a constitui o echipa complexa, formata din specialisti din domeniul caruia se adreseaza produsul / serviciul de realizat, din domeniul economic, precum si din domenii conexe, de care depind strict existenta produsului / serviciului.

Lucrarea de fa i propune s ofere o serie de cunotine solide n domeniul managementului proiectelor, care s conduc la nlturarea temerilor nscute din ideea c acest domeniu este un domeniu extrem de complicat i care s constituie un nsoitor de ncredere pe drumul ctre performan.Cu ct managementul unui proiect este mai performant, cu att proiectul respectiv are mai multe anse de reuit.

Acest manual i propune s se constituie ,de asemenea,ntr-un ndrumtor destinat n principal studenilor de la facultile cu profil tehnic, pentru a-i ajuta pe acetia n managementul optim i eficient al proiectelor de cercetare, design i dezvoltare, inclusiv a lucrrilor de diplom i masterat.

.

DEFINIII,CARACTERISTICI,ETAPE N DEZVOLTAREA UNUI PROIECTDicionarul Oxford prezint un proiect ca fiind O activitate individual sau n colaborare care este judicios planificat i urmrete obinerea unui obiectiv specific

Proiectul poate fi vzut i ca un concept de organizare a unei aciuni.

Termenul de proiect a fost folosit pentru prima dat n secolul XVI i vine din latinescul projicere care poate fi tradus prin a duce nainte.Prima dat cuvntul a fost folosit de ctre arhiteci.Bruneleschi n activitatea sa la catedrala din Florena a adus 2 inovaii:

-lucrul la aceast catedral fusese ntrerupt n secolul XIV i Bruneleschi a fost solicitat s reia acest lucru.nainte de a ncepe el a produs un progetto sau plan al domului.

-a separat planificarea de realizare,proiectarea de implementare.

Un proiect

este o metod care permite trecerea de la idee la aciune, structurnd diversele faze care apar n acest proces;

i propune s modifice mediul n care are loc;

are loc ntr-un anumit context social, spaial i temporal;

are n general o dimensiune educativ i permite oamenilor s nvee din experiment;

implic n mod general evaluare-stabilind legtura ntre idee i aciune;

CE ESTE UN PROIECT?Proiectul este rezultatul unor procese iterative de selectie, asa fel nct reprezinta cel mai bun mod de abordare al unui ansamblu de procese, n raport cu un context dat.

n dezvoltarea unui proiect, se iau n considerare aspectele structurilor organizationale, constituirea echipelor, functiile de management, aspectele conflictuale, tehnicile de planificare si variabilele care intervin, alocarea, nivelarea si ncarcarea resurselor pe traseul de tip graf si abordarile n plan economic prin intermediul preturilor estimate, controlului costurilor si, mai ales, prin dezvoltarea unor tehnici de analiza.

Ciclu: o problema, o persoana, o idee

Un proiect este realizat de doua ori de fiecare data: o data in mintea ta si a

doua oara in realitate

Un proiect este tot ceea ce se intampla intre idee din cap si ceea pe care o

simti

CARACTERISTICI ALE PROIECTELORFigura urmtoare definete cele mai importante caracteristici ale proiectelor.

Figura Caracteristici ale proiectelor

Proiectele au un scop-proiectele au obiective bine definite i sunt astfel setate nct s produc rezultate clar definite.Scopul lor este s rezolve o problem-acest lucru implicnd o analiz preliminar-sugernd una sau mai multe soluii, proiectele implic o schimbare a mediului.

Proiectele sunt realiste-elul proiectelor trebuie s fie realizabil-acest lucru presupune luarea n considerare att a obiectivelor ct i a resurselor existente.

Proiectele sunt limitate n timp i spaiu-ele au un nceput i un sfrit i sunt implementate ntr-un loc i context specific.

Proiectele sunt complexe-implicnd diverse abiliti legate de planificare i implementare ele implic parteneri diveri.

Proiectele sunt colective-proiectele sunt rolul unei activiti colective.Ele sunt conduse de echipe, implic diveri parteneri i se pliaz necesitilor altora.

Proiectele sunt unice-toate proiectele provin din idei noi, oferind rspunsuri specifice unei necesiti (probleme) ntr-un anumit context.Ele sunt inovative.

Proiectele pot fi considerate ca o aventur-fiecare proiect de diferit-ele implic totdeauna o anumit incertitudine i riscuri.

Proiectele pot fi evaluate-proiectele pot fi mprite n diviziuni msurabile-acestea trebuie s fie deschise pentru evaluare.

Proiectele sunt alctuite din etape-proiectele au etape distincte, identificabile.

De ce facem proiecte?

Dezvoltarea abilitatilor (management de proiect, management de echipa,

comunicare, etc.

Dezvoltarea atitudinii (receptivitate, gandire pozitiva, acceptarea greselilor,

acceptarea schimbarii, etc.)

Acumularea de cunostinte

Impact (participanti, studenti, etc)

Implinire personala (mandrie, auto-motivare, incredere de sine)

Ce tipuri de proiecte putem organiza ?

Orice proiect trebuie s aib un rezultat practic, concretizat ntr-un produs sau serviciu.

Seminarii in afara organizatiei din care facem parte (determini oamenii

sa-si schimbe atitudinea) sau interne (oamenii care participa castiga cunostinte)

Jocuri (simulari, studii de caz, etc)

Dezvoltarea unui anumit departament, o relatie cu un client

Cercetare / Raport (castigi cunostinte pe un anumit domeniu de interes)

Conferinte

Un proiect poate fi considerat ca o activitate a crei rezultat este un produs sau un serviciu.Proiectele ncep de obicei cu o problem ce trebuie rezolvat.Utilizatorul apeleaz la o echip cu solicitarea s-i fie rezolvat aceast problem.

Cnd un proiect este termiant el trebuie evaluat pentru a determina existena a patru elemente eseniale:

Produsul obinut rezolv problema utilizatorului ?

Utilizatorul a fost satisfcut cu procesul de dezvoltare al produsului ?Produsul poate fi perfect dar dac utilizatorul nu a fost satisfcut de procesul de dezvoltare el poate refuza produsul-prin urmare utilizatorul trebuie implicat n procesul de dezvoltare;

Managementul echipei de dezvoltare este satisfcut de produsul obinut ?

Echipa de dezvoltare este satisfcut ?Echipa trebuie s primeasc o recompens (de obicei bneasc) pentru ce a realizat.De asemenea, echipa trebuie s simt c experiena obinut va fi util.

STRUCTURAREA UNUI PROIECT FOLOSIND CHECK-LIST-URILEn continuare este prezentat un check-list de baz care poate fi folosit pentru o structurare general, nainte de lansarea proiectului.

Tabel

Aspect principalntrebare

Definirea elurilor, obiectivelor, contextului i grupului intn ce context se va desfura proiectul ?

Ce modificri va presupune realizarea proiectului ?

Cine va realiza proiectul ?

Care sunt rezultatele ateptate ?

Pentru cine e gndit proiectul ?

Care sunt problemele ridicate ?

Coninutul proiectuluiCare este tema proiectului ?

Ce va conine proiectul ?

Care este abordarea aleas ?

Ce activiti sunt implicate ?

Ce condiii necesit pornirea proiectului ?

Unde i cndUnde va fi implementat proiectul ?

Ct va dura ?

Cnd va ncepe ?

Cnd se va sfri ?

Aspecte practiceCe logistic este necesar ?

Ce aspecte practice trebuiesc tratate ?

FinanareCare este costul total (planificare/implementare/evaluare)?

De unde va proveni aceast finanare ?

ParteneriCine sunt partenerii ?

Care este rolul acestora ?

Care sunt aranjamentele de management n comun ?

Mijloace de aciuneSe calific proiectul pentru asisten financiar ?

Poate s utilizeze facilitile existente ?

ComunicareComunicri interne: cum circul informaia n echipa proiectului ?

Comunicri externe: necesit proiectul publicitate n mass-media ? De ce ?

Cum ?

Evaluare i continuareCum i unde trebuie evaluat proiectul ?

Ce aspecte trebuiesc evaluate ?

De ce ?

Ce continuare a proiectulu ieste apreciat ?

EXEMPLU

ntrebareRspuns

n ce context se va desfura proiectul ?

Ce modificri va presupune realizarea proiectului ?

Cine va realiza proiectul ?

Care sunt rezultatele ateptate ?

Pentru cine e gndit proiectul ?

Care sunt problemele ridicate ?Proiectul va presupune re-instruirea unor angajai trimii n omaj pe termen ndelungat

Nici una

S.C.Protect S.A. mpreun cu experii externi

Re-instruirea n tehnologii IT a 200 de omeri

omeri cu studii superioare i medii

Re-instruirea n tehnologii actuale i de interes

....

Ce va conine proiectul ?

Care este abordarea aleas ? Ce activiti sunt implicate ?

Ce condiii necesit pornirea proiectului ?.....Proiectul va conine modulele de instruire dezvoltate precum i dovezi (teste i rezultatele acestora) c persoanele din grupul int au fost instruite

Instruire clasic i de tip e-learning.

1. Designul coninutului educaional. 2.Designul metodologiei de instruire. 3.Dezvoltarea coninutului. 4. Selecia grupului int. 5.Implementarea coninutului. 6. Testarea participanilor

Unde va fi implementat proiectul ?

Ct va dura ?

....n Bucureti i n Regiunile de Nord-Vest i Sud-Est

24 de luni

.......

Ce logistic este necesar ?

Sedii pentru instruire. n fiecare locaie a proiectului va exista un server plus software-ul necesar pentru instruirea de tip e-learning plus o reea de 10 calculatoare cu soft-ul necesar pentru formarea cursanilor. De asemenea este necesar un proiector n fiecare sediu.

......

.......

Cine sunt partenerii ?

Care este rolul acestora ?

Care sunt aranjamentele de management n comun ?ANOFMGsirea grupului int i selectarea acestuia.

Acord de colaborare cu precizarea obligaiilor reciproce.

Se calific proiectul pentru asisten financiar ?

Poate s utilizeze facilitile existente ?DaDa

Comunicri interne: cum circul informaia n echipa proiectului ?

Comunicri externe: necesit proiectul publicitate n mass-media ? ...Proiectul folosete un site multi-rol care are i rolul de gestiune a informaieiDa, necesitatea e impus de ghid

......

Cum i unde trebuie evaluat proiectul ?

....... La sfritul fiecrei faze- pentru rambursare......

Este evident c n cazul unui proiect real un astfel de check-list va fi mult mai detaliat. Totui, exemplul de fa poate fi considerat ca un draft pentru dezvoltare ulterioar. VALORI CONSIDERATE N MANAGEMENTUL PROIECTELORFigura urmtoare prezint schematic aceste valori.Valorile pe baza crora se face monitorizarea i controlul l proiectului implic trei grupe de decizii:

-cum s se monitorizeze proiectul,pentru a verifica progresul desfurrii acestuia;

-cum s se evalueze performanele proiectului, prin compararea observaiilor monitorizate cu planul proiectului;

-cum s se intervin n proiect printr-o bucl de reacie invers, pentru a efectua schimbrile care l vor readuce la planul iniial.

Managerul de proiect poate monitoriza desfurarea proiectului pe baza rapoartelor asupra performanelor, care arat ce s-a realizat, fa de plan. Rapoartele asupra performanelor trebuie s conin informaii asupra schimbrilor scopului, asupra programrii, asupra costurilor i calitii.

Figura Valori considerate n managementul proiectelor

Eficien-tehnologiile de planificare a proiectelor(managementul tiinific al acestora) permit creterea eficienei prin focusarea obiectivelor proiectului pe nevoile concrete ale unui grup.Limitnd cmpul de intervenie i anticipnd rezultatele obinute ct mai concret posibil resursele vor fi folosite ntr-un mod mai optim i eficiena global a activitii va crete.Prin aceast focusare dispersia eforturilor depuse pentru realizarea proiectului scade iar implicarea n diversele activiti ale proiectului este mult mai coerent i mai bine coordonat.

Posibilitate de control i responsabilitate (mprit)-Se poate considera c toate proiectele sunt egale pentru c trebuie s ndeplineasc aceleai criterii.Toate organizaiile sunt astfel copnsiderate aprioric ca pornind de la acelai nivel-calitatea unui proiect fiind elementul decisiv pentru ca acesta s fie acceptat sau nu.

Economie i consisten-managementul tiinific al proiectelor permite finanatorilor s vad mai bine utilizarea fondurilor deviaiile n utilizarea acestor fonduri fiind mai repede observate.Prin alocarea tiinific a resurselor pentru a implementa obiectivele i activitile concrete ale proiectului este posibil s se creasc folosirea eficient a acestor resurse ,limitndu-se n acelai timp cheltuielile necontrolate i rezultatele inadecvate.Datorit faptului c proiectul are un cadru de timp bine stabilit i poate include diverse momente de evaluare i monitorizare, controlul funanciar al acestuia este mult mai facil , existnd posibilitatea acelerrii eventualelor corecii i intervenii.Necesitatea ca fiecare activitate s se alinieze cadrului proiectului determin coerena acestuia, fcndu-l mai uor de urmrit i n acelai timp limiteaz devierile sau distorsiunile.

Calitatea-calitatea ca rezultat al managementului tiinific al proiectului este mbuntit datorit posibilitilor extinse de optimizare a identificrii aptitudinilor, resurselor i procedurilor necesare pentru atingerea unui set de obiective.Resursele sunt identificate n relaie cu necesitile specifice i obiectivele proiectului.Monitorizarea i evaluarea sunt instrumente importante pentru msurarea calitii sau pentru a verifica nivelul de ndeplinire al obiectivelor.

Realismul-esena proiectelor este faptul c acestea trebuie s fie realiste, cu obiective care s poat fi atinse.Realismul este o valoare important deoarece se elimin proiecte care nu se pot realiza.

Flexibilitate-proiectele trebuie s fie planificate, implementate i evaluate.Managementul tiinific al proiectelor permite ca s fie introduse modificri ca rezultat al progresului proiectului i evalurilor regulate.

Transparen i vizibilitate-transparena presupune c alocarea de resurse publice i private i impactul acestora asupra programului este mult mai clar i poate fi urmrit.Ideea este c investitorii trebuie s vad ce primesc pentru banii investii.

Visiblitatea presupune c rezultatele obinute sunt tangibile pot fi artate i reinute uor.Vizibilitatea este foarte important de asemenea pentru marketingul proiectului i pentru a demonstra utilizarea corect a fondurilor.

Creativitate i inovare-managementul tiinific al proiectelor stimuleaz dezvoltarea creativitii la persoane i organizaii.

Competiia-proiectele cresc una din cele mai importante valori ale societii contemporane-respectiv competiia.Condiiile generale care trebuiesc ndeplinite de proiecte solicit aplicanilor s fie ct mai performani, eficieni i obiectivi.

Participare-managementul tiinific al proiectelor impune o participare sporit a realizatorilor acestora.

Mobilitate-managementul tiinific al proiectelor impune att o mobilitate fizic ct i una spiritual a celor care realizeaz aceste proiecte.Managementul proiectelor nu este:

Planificare strategic-orientare pe termen lung,ddefinirea politicilor, activitilor i dezvoltrii organizaionale.Implic o capacitate de anticipare i pregtire pentru modificri structurale pentru o perioad relativ lung de timp.Planificarea strategic ia n considerare modificri structurale sau infra-structurale.

Planificare tactic-se refer la diverii pai necesari pentru a atinge obiective strategice are loc prin adaptare i reaciune la modificri neprevzute.

Planificare ciclic sau recurent-tratarea evenimentelor existente sau previzibile ntr-un sistem regulat.

Planificare zilnic-tratarea aciunilor care trebuiesc realizate imediat sau ntr-un cadru de timp foarte scurt.

Planificarea contingenelor-msuri adoptate sau prevzute pentru a rspunde situaiilor neprevzute-dac acestea apar.

Management prin obiective(MBO-management by objectives)- o abordare a managementului sarcinilor consistnd n focusarea asupra obiectivelor care trebuiesc atinse-lsnd ecipei de realizare gsirea celor mai bune ci de atingere a acestor obiective.

Management la ntmplare (MBWA)-este un stil de management care presupune funcionarea normal pn la apariia unui eveniment neprevzut-antiteza managementului eficient.

Managementul crizelor-implic tratarea succesiv a crizelor-stil de management contraindicat-managementul trebuie s previn i nu s trateze aceste crize.

Majoritatea proiectelor (mai ales n domeniul software) sunt proiecte mici i medii.Din punct de vedere al resurselor umane nici un astfel de proiect nu depete 10 ani/om.Echipa cea mai efectiv de realizare pentru un astfel de proiect nu va depi 7 persoane.SUCCESUL I EECUL PROIECTELOR

Cauzele frecvente ale eecului unui proiect: Se ncepe programarea fr o descriere clar a motivelor pentru care proiectul e nceput i a ceea ce trebuie obinut-deci fr un plan bine pus la punct;

Nu a fost obinut acceptul utilizatorului pentru produs;

Termenele de realizare nu sunt realiste

Echipa de dezvoltare a proiectului nu nelege specificaiile utilizatorului;

Echipa de dezvoltare a proiectului nu este familiarizat cu cele mai eficiente instrumente de dezvoltare a unui astfel de proiect;

Transpunerea direct n program, fr etapele de analiz i proiectare necesare

Lipsa verificrilor i reviziilor

Un buget insuficient

Probleme cu personalul

Cauzele succesului unui proiect:Proiectele de succes au un nceput bine definit-un plan scris care definete rezultatul final, modul n care acesta este obinut i momentul n care acesta va fi livrat.

Criterii msurabile de acceptan a proiectului de ctre utilizator sunt formulate n scris i discutate mpreun cu acesta-astfel nct s poat constitui un set de criterii de performan definit.

n cursul dezvoltrii se realizeaz o monitorizare continu-pentru a se urmri respectarea planificrii.

Utilizatorul este satisfcut pentru c i-a fost livrat un produs aa cum a fost promis.Costul acestuia se apropie de costul preconizat.

Succesul unui proiect impune o evaluare continu, aa cum se poate observa i din urmtoarea figur.

Fig..Evaluarea continu a proiectelor

ETAPE DE REALIZARE A PROIECTELOR I MANAGEMENTUL ACESTORASchema general a structurrii unui proiect de-a lungul diverselor faze generice poate fi observat n figura urmtoare.Discuia despre fazele (etapele) unui proiect va fi detaliat n capitolul special referitor la aceast problematic. Aa cum s-a precizat i anterior, managementul proiectelor este focusat n principal asupra fazelor de planificare, implementare i monitorizare i control(evaluare).Managementul integrat, n sens larg, este un sistem de management care integreaz toate sistemele i procesele organizaiei ntr-un cadru complet, care permite funcionarea ca o singur unitate cu obiective unificate.

Managementul integrrii proiectelor sau programelor implic analiza valorii afacerii pe care proiectul o adreseaz, mobilizarea performanelor i dinamicii echipei de proiect, monitorizarea proiectului, rezolvarea conflictelor tehnice, de resurse i interpersonale la orice nivel, identificarea constrngerilor organizaiei i exploatarea lor etc.

Procesele majore ale managementului integrat al proiectelor (MIP) sunt: procesele de elaborare a planului proiectului, procese de execuie a planului proiectului i procese integrate de control al schimbrilor. Fiecare proces include un set de intrri i un set de ieiri. Derularea oricrui proces este facilitat prin utilizarea unui set de instrumente sau metode care constituie mecanisme aplicate intrrilor pentru a crea ieirile.Ghidul PMBOK, ediia din 2004, menioneaz c procesele de management al proiectelor sunt organizate n nou domenii de cunotine:

-managementul integrrii proiectelor;

-managementul coninutului proiectelor (project scope management);

-managementul termenelor proiectelor;

-managementul costului proiectelor;

-managementul calitii n proiecte;

-managementul resurselor umane;

-managementul comunicaiilor n proiecte;

-managementul riscurilor n proiecte;

-managementul achiziiilor n proiecte.

Fig..Faze de structurare a unui proiectFigura urmtoare prezint paii de planificare ai unui proiect.

Fig. Paii de planificare ai proiectului

Realizarea n practic a acestor pai de planificare depinde de mai multe aspecte, lundu-se n considerare n general mrimea i complexitatea proiectului.

O abordare diferit a procesului de planificare a unui proiect poate fi fcut i prin prism personal, aa cum se poate observa i din urmtoarea figur.

Fig..Interpretarea planificrii proiectelor din prism personal

CONDUCERE=MANAGEMENT ?

Fazele generale de conducere ale unui proiect pot fi observate n figura urmtoare.

Fig..Fazele conducerii unui proiect

Plecnd de la cele prezentate mai sus.fazele managementului unui proiect considernd proiecte de profil n domeniul cercetrii-dezvoltrii pot fi definite n modul urmtor:

-Definirea problemei ce trebuie rezolvat;

-Analiza problemei i a soluiilor anterioare ;

-Design-ul sistemului ;

-Programarea-Dezvoltarea sistemului;

-Testarea sistemului;

-Acceptana sistemului de ctre utilizatori;

-Operarea sistemului;

Se pot face urmtoarele diviziuni:

-Activiti:ce trebuie fcut n fiecare faz;

-Documente i termene de ieire:documentele care trebuiesc produse n fiecare faz;termenele ce trebuiesc respectate;

-Efort relativ:efortul uman care trebuie alocat:distribuia acestui efort este urmtoarea:mare->n primele faze;mai redus->n mijloc; mare->la sfritul proiectului;

-Echipa de realizare:

Pentru a nelege etapele de dezvoltare ale unui proiect putem compara construcia unui proiect cu construcia unei case

Activiti de definiie a unei case

n aceast faz sunt nregistrate toate cerinele utilizatorului.Dac acestea nu sunt scrise ele trebuiesc scrise pentru a obine Documentul de Specificaie.

Pe baza acestui document se face o prim evaluare a costurilor.Acestea, mpreun cu un calendar al construciei sunt prezentate utilizatorului ntr-o propunere.Pentru ca evalurile s fie ct mai corecte, utilizatorul ar trebui s atepte pn la sfritul fazei de analiz.

Activiti de analiz

Analistul realizeaz o specificaie funcional a casei.Specificaia funcional este un listing a ceea ce casa va face pentru utilizator.Intrrile, ieirile i interfeele ntre cas i utilizator.Specificaiile nu includ date despre modul efectiv de construcie al casei ci numai ceea ce utilizatorul va primi pe baze cererilor formulate n documentul de specificaie.

Activiti de design

Designerul unei case este arhitectul.Scopul designului este mprirea sistemului n componente funcionale i interconectarea eficient a acestor componente.

Designul arat modul de funcionare al sistemului.Acesta poate fi la rndul su divizat n:

-Designul general (conceptual) al sistemului;

-Designul logic al sistemului;

Tot acest design merge n Specificaiile de Design

Activiti de dezvoltare (programare).

Echivalentul acestei faze este construcia propriu-zis a casei.

Activiti de testare a sistemului.

n aceast faz toate componentele sunt asamblate i se testeaz funcionarea lor mpreun.

Activiti legate de acceptan

n aceast faz utilizatorul ia n primire casa construit i o accept aa cum este sau solicit modificri

Activiti legate de operare

n aceast faz utilizatorul se mut fizic n cas-considernd o garanie n care, dac se ntmpl ceva, constructorul asigur reparaiile i modificrile.

Analogia nu este 100% corect din dou motive:

-se cunoate foarte mult despre construcia unei case dar sunt puini utilizatori care s aib clare n minte specificaiile dorite-la fel ca i proprietarul unei case;

-industria construciilor este suficient de veche pentru a avea standarde bine puse la punct;

ETAPELE DE DEZVOLTARE A UNUI PROIECT-IMAGINE GENERAL

Pentru a nelege logistica de realizare a unui proiect trebuiesc nelese etapele i fazele pe care acesta le presupune pn ce se obine produsul sau serviciul dorit.

n continuare vor fi enumerate i descrise sumar principalele etape/faze de dezvoltare ale unui proiect cu comentariile de rigoare n ceea ce privete activitatea de management, aa cum sunt ele prezentate de marea majoritate a autorilor consultai.n general, orice fel de proiect este compus din urmtoarele etape:

Etapa de documentare-n care echipa de realizare a proiectului parcurge toat documentaia disponibil despre problema urmrit, pentru a se familiariza cu aceasta;

Etapa de analiz i stabilirea cerinelor (utilizatorului)-n aceast etap, pe baza documentrii fcute la punctul anterior se stabilesc specificaiile eseniale de realizare a proiectului; dac proiectul este fcut n mod specific la solicitarea unui utilizator, n urma conversaiilor cu acesta sunt stabilite i definitivate aceste cerine-de aceast etap se leag i etapa urmtoare-aceasta nu este o etap direct a proiectului i totui este strict necesar pentru realizarea acestuia;

Planificarea proiectului-n aceast etap, avnd bine definite cerinele, sunt stabilite i definitivate:

Echipa de realizare a proiectului;

Bugetul proiectului;

Sursele de informare-documentare;

Celelalte resurse necesare;

Designul proiectului-indiferent dac proiectul se refer la o component hardware sau o component software, pentru realizarea acestuia este necesar o etap de design; acesta la rndul su se poate divide, pentru proiectele informatice n:

Design(proiectare) conceptual() sau de ansamblu;

Design(proiectare) de detaliu; aceast etap se poate ncheia printr-o etap suplimentar, de testare a designului, folosind instrumente de modelare i simulare-a se vedea i capitolul dedicat acestei activiti;

Dezvoltarea propriu-zis a proiectului-n aceast etap este realizat produsul sau serviciul care constituie obiectivul proiectului;

Implementarea produsului la utilizator,testarea produsului i testarea acceptanei sale de ctre utilizator-dac utilizatorul nu este satisfcut el nu va plti costurile proiectului; ntreinerea-sau etapa de garanie;Aceste etape sunt ilustrate n urmtoarea figur.

Figura Etapele de realizare a unui proiectActivitatea de management a unui proiect este concentrat n primele sale faze, n special n ceea ce privete componenta de planificare, urmnd ca, n fazele ulterioare s se insiste mai ales pe componentele de monitorizare i control.

mprirea n etape i faze poate fi n general destul de subiectiv-baza pentru aceast mprire a fost n acest caz o surs anglo-saxon, respectiv documentul RANK intitulat 10 Minute Guide to Project Management.ETAPA DE DOCUMENTARE

Etapa de documentare presupune n general identificarea ultimelor apariii editoriale i a ultimelor articole i comunicri tiinifice semnificative referitoare la domeniul proiectului.Acest lucru este necesar pentru ca proiectul s aib un coninut valoros, fr a se ncerca s se reinventeze roata.Totodat, ultimele realizri n domeniu ofer termeni de referin pentru proiectul respectiv, testarea i validarea proiectului putndu-se face comparativ cu aceti termeni de referin.

ETAPA DE DEFINIRE GENERAL A CERINELOR-NELEGEREA PROBLEMELOR UTILIZATORULUI

Aceast faz mpreun cu faza de analiz este tratat ntr-un capitol separat n extenso.Aici vor fi definite cteva din caracteristicile sale principale.

Obiectiv:nelegerea suficient a problemelor utilizatorului pentru a putea estima costurile necesare i calendarul de timp.

Activiti majore:

-Stabilirea solicitrilor utilizatorului (Requirements)

-Decizia dac proiectul va fi sau nu realizat-trebuie stabilit dac proiectul este realizabil i dac are anse de succes (Go/No Go Decision);dac decizia realizrii proiectului este favorabil atunci trebui analizate toate riscurile posibile care ar putea mpieta asupra realizrii proiectului;

-Realizarea propunerii care conine ce va fi livrat utilizatorului, cnd i la ce costuri (include costurile legate de riscuri);

Documente i termene de referin:

-Document referitor la cerinele utilizatorului(RD-Requirement document-RFP-Request for Proposal)-trebuie s fie clar i complet astfel nct echipa de realizare a proiectului s neleag corespunztor problema utilizatorului i s poat estima costurile soluiei-acest document trebuie semnat de utilizator i de echipa de realizare a proiectului;

Coninut:

-Introducere;

-Obiectivele proiectului;

-Funcii majore;

-Ieiri generale;

-Intrri informaionale generale;

-Parametrii de performan;

-Dezvoltare;

-Operare i mediu de operare;

-Compatibilitate, interfee;

-Disponibilitate,fiabilitate;

-Interfa cu operatorul;

-Impact organizaional;

-ntreinere i suport;

-Documentaie i instruire;

-Avantaje;

-Termene i condiii

-Plan preliminar al proiectului(PPP-Preliminary Project Plan);

-Propunerea formulat pentru utilizator

Fazele managementului riscului:-Pas 1:Anticiparea riscului;

-Pas 2:Eliminarea riscurilor acolo unde este posibil;

-Pas 3:Reducerea impactului riscurilor;

-Pas 4:Meninerea controlului atunci cnd se produc evenimente neprevzuteManagementul riscurilor va fi tratat ntr-un capitol separat n detaliu.

Figura urmtoare prezint acest aspect.

Figura Etape generale n managementul riscurilor unui proiect

Riscurile pot fi:

-Generale legate de:

-o echip de realizare nepotrivit;

-un mediu de lucru impropriu;

-resurse furnizate de teri;

-proiecte care trebuiesc terminate urgent;

-buget nespecificat;

-Financiare:exist situaii n care costurile reale sunt mult mai mari dect cele anticipate.

-Tehnice care pot fi legate de:

-Soluii greite;

-Specificaii greite;

-Necunoaterea modului de operare al utilizatorului; pentru a evita apariia unor cerine nerealistge ale utilizatorului, contractul trebuie s evite includerea unor parametrii prea strici, care din diverse motive nu pot fi atini;

PLANIFICAREA PROIECTULUI

Aceast etap este principala etap logistic a proiectului i este tratat ntr-un capitol separat n extenso.Aici vor fi definite cteva din caracteristicile sale principale.

Planificarea este un proces iterativ-planul este revizuit n mod constant pe msur ce proiectul progreseaz i este stpnit mai bine de realizatori.Planificarea este foarte dificil-dar trebuie realizat corect.

Cheia oricrui plan o reprezint spargerea activitilor necesare n buci ct mai mici (Work Breakdown Structures-WBS).

Un WBS pleac cu listarea componentelor majore ale proiectului-acesta reprezint nivelul 1.

Nivelul 2 sparge fiecare component major definit la nivelul 1 n activitile sale componente.Urmtoarele niveluri realizeaz aceleai operaii de spargere pn ce se ajunge la cea mai mic component semnificativ.Acestea sunt sarcinile sau activitile proiectului.Aceast spargere se poate opri atunci cnd:

-o persoan sau un grup de persoane i poate asuma responsabiliti pentru sarcin sau poate ndeplini activitile aferente;

-se poate face o estimare aproximativ a efortului (persoane-zile) necesar pentru realizarea activitilor acest lucru trebuie realizat de persoana responsabil;

-se poate programa sarcina-innd seama de durata i de activitile precedente;

-sarcinile trebuie s fie de mici dimensiuni i s fie posibil de realizat;

Calculul costului proiectelor

Acest lucru nu trebuie detaliat n aceast etap dect dac se cunoate exact componena echipei de lucru.Un calcul de cost trebuie realizat pentru fiecare sarcin sau faz de nivel 1 a WBS-totalul acestor costuri d costul proiectului.

O schem acoperitoare pentru aceste costuri este prezentat n urmtoarea figur.

Figura Principalele categorii de costuri

n general un astfel de cost include:

-Costuri cu manopera;

-Costuri cu materialele;

-Materii prime;

-Consumabile;

-Piese de schimb;

-Dotri;

-Costuri generale :

-Regii, etc.

n aceste costuri trebuiesc aproximate i eventualele riscuri care pot fi identificate.Etapizarea proiectului

Pentru a realiza aceast etapizare (n termene concrete) planificatorul-de obicei managerul proiectului trebuie s traduc zilele estimate n zile calendaristice sau durate.

O sarcin complicat la acest punct o reprezint alocarea resurselor-mai ales atunci cnd sarcinile se desfoar simultan.O alt problem, mai dificil se refer la scurtarea duratei de execuie a unei sarcini prin alocarea a mai multor resurse.

Coninutul planului preliminar al proiectuluiPlanul preliminar al proiectului (PPP) trebuie s conin urmtoarele paragrafe:

1.Echipa de realizare a proiectului-aici se detaliaz organizarea echipei, structura, nivelurile de raportare i comunicare

2.Costurile proiectului-reprezint documente private care includ WBSurile cu estimrile costurilor pentru fiecare sarcin i activitate.

3.Graficul de timp al proiectului-diagrama Gantt pentru proiect

4.Verificri, cine le va executa i scopul acestora.Responsabiliti

PropunereaPropunerea care va fi realizat are 3 obiective:

conine prima estimare a echipei de realizare a proiectului, referitoare la costuri i durat;

pentru un proiect extern reprezint un document care arat intenia echipei de realizare de a duce la capt acel proiect;

este un instrument util pentru vnzri-vinde utilizatorului raportul costuri/beneficii referitor la proiectul respectiv;

Aspecte negociabile ale unui proiect

preul proiectului-dac preul propus este inacceptabil trebuiesc considerate mai puine funcii ale proiectului;exist chiar posibilitatea de a oferi mai multe versiuni ale unui proiect-versiunea 1 va conine doar funciile de baz-pentru preul minim-celelalte versiuni cu funcii adugate sau mbuntite cost mai mult;

durata proiectului;

funciile oferite;

FAZA DE ANALIZ A PROIECTULUI

Adeseori aceast faz este conexat primei faze constituind mpreun faza de specificare a cerinelor utilizatorului.Sub acest titlu ea va fi detaliat ntr-un capitol separat.n acest paragraf se consider c faza de analiz este ulterioar specificrii cerinelor- utilizatorul i-a definit cerinele, faza de analiz prezentnd modul n care aceste cerine pot fi satisfcute.Obiectiv:Definirea exact a ceea ce va realiza sistemul pentru utilizator i cum se va potrivi acest sistem n mediul utilizatorului.

Activiti principale:

Realizarea Specificaiilor Funcionale (FS-Functional Specification);

Revizuirea PPP i a estimrilor iniiale-statisticile arat c estimrile sunt aici de dou ori mai exacte dect cele din prima faz;

Scrierea propunerii de dezvoltare

Figura Faza de analiz a proiectului

Metoda de analiz Yourdon (a fluxului de date)

Este o metod grafic de documentare i desfurare a procesului de analiz.Analistul mpreun cu utilizatorul dezvolt o diagram ncepnd cu listarea n cercuri a tuturor utilizatorilor care au acces la interfaa sistemului-inclusiv utilizatori indireci.Apoi, aceti utilizatori sunt legai prin sgei care marcheaz informaiile sau datele schimbate.Sgeile pot reprezenta:

fluxul informaional;

fluxul de date;

deplasarea fizic a itemilor;utilizatorul i analistul detaliaz fiecare din itemii reprezentai de sgei realiznd descrierea interfeei utilizator ctre sistem-aceast abordare are dou obiective:

dobndirea unei nelegeri a doleanelor utilizatorului;

detalierea interfeei calculator;

Coninutul specificaiilor funcionale-specificaiile funcionale trebuie s conin minim urmtoarele puncte:

Pagina de titlu-numele proiectului, numele autorilor,numrul versiunii,data;

Pagina de cuprins;

Descrierea general a sistemului-trebuie inut seama de faptul c aceste specificaii sunt un document tehnic adresat utilizatorului neprofesionist-folosirea unor imagini grafice sugestive este deosebit de util aici;

Definirea obiectivelor majore-se listeaz obiectivele sistemului i legtura acestora cu modulele sistemului-se descrie modul n care noul sistem va afecta mediul de lucru al utilizatorului

Cerine speciale ale sistemului-sunt detaliate cerine cum ar fi:

lucrul n reea;

cerine de compatibilitate;

cerine de securitate;

cerine de fiabilitate;

cerine de uurin n funcionare;

Descrierea componentelor-include o descriere detaliat a fiecrei funcii;

Alte componente-n principal documentaia oferit i coninutul acesteia;

Aspecte referitoare la instruirea utilizatorilor;

Modificri ale specificaiilor-proceduri de control ale modificrilor i de stabilire a impactului viitoarelor modificri asupra proiectului;

Acceptana proiectului de ctre utilizator-trebuie s minimizeze nencrederea utilizatorului prin demonstrarea ctre acesta, pas cu pas, a funciilor care vor fi furnizate de ctre sistem;

Interfee utilizator i interfee proiectant;

Responsabilitile utilizatorului;

Termene,condiii i ipoteze de lucruFigura urmtoare prezint aspectele principale din acest coninut.

Figura Coninut specificaii funcionale

FAZA DE PROIECTARE(DESIGN)

Designul presupune doi pai majori:

-mprirea sistemului n componente funcionale;

-interconectarea acestor componente;

Activiti majore i puncte cardinale de dezvoltare:

dezvoltarea designului conceptual (general) al proiectului-de acest design depind urmtoarele aspecte:

costul sistemului;

durata necesar pentru construcia sistemului;

caracterul prietenos al sistemului;

performana;

mrimea sistemului;

posibilitatea de modificare a sistemului;

dezvoltarea designului de detaliu

nceperea planului de acceptan a testelor (ATP-Acceptance Test Plan)-document care listeaz testele care vor fi efectuate pentru a demonstra funciile sistemului ctre utilizator n faza de acceptan.

punct cardinal major-cnd specificaia de design este declarat fr erori;

punct cardinal minor-acceptabilitatea ATP de ctre utilizator;

Soluia cea mai bun pentru proiectare este proiectarea structurat.Figura urmtoare este ilustrativ n acest sens

Figura Componentele principale ale fazei de proiectare

Obiectivul major:Spargerea sistemului n pri mici, care pot fi considerate ca entiti distincte.

Metode folosite:

-Top Down Design;

-Bottom Up Design;

Designul trebuie revizuit de civa experi independeni-fiecare din variantele de design trebuie analizat pentru a sublinia avantajele i dezavantajele.

Module structurate

La nivelul inferior a descompunerii funcionale a unui sistem se afl un modul structurat-un astfel de modul are urmtoarele proprieti:

execut n mod complet o singur funcie;

are dimensiuni mici-50..100 linii de cod sau 2 pagini de listing maximum;

este previzibil-ntreg comportamentul modulului poate fi prezis prin parcurgerea codului;

este independent-modificrile aduse acestui modul nu modific alte module din sistem;

poate fi refolosit;

Beneficiul designului structurat se afl n zona costurilor-costurile pot fi reduse de pn la 5 ori folosind aceast modalitate;

Coninutul specificaiei de design

Pagin de titlu i coninut(cuprins);

Prezentare general;

Hardware/software folosit;

Prioriti ntlnite-n ordine descresctoare;

Diagrame ale design-ului;

Convenii de denumire a modulelor;

Transmiterea parametrilor i dicionare de date;

Tratarea erorilor;

Standarde utilizate n proiectarea structurat;

Instrumente de programare utilizate;

Designul conceptual;

Designul logic;

Dicionare de date;

Fiiere i tabele folosite;

Testarea designuluiObiectivele urmrite n aceast etap sunt urmtoarele:

verificarea faptului c toate cerinele specificaiilor funcionale sunt ndeplinite-pentru fiecare funcie menionat designerul trebuie s fie capabil s arate locul n care funcia respectiv este implementat;

verificarea uurinei de programare a designului realizat-dac au fost respectate standardele designului structural;

verificarea posibilitilor de implementare n timp i cu bugetul dat;

Planul de acceptan a testelor de designObiectivul acceptanei este obinerea unei declaraii scrise din partea utilizatorului c designul este corespunztor.

Perioada de prob sau rulajul paralel sunt cele mai uzuale abordri ale acceptanei.

n perioada de prob sistemul este instalat pentru a fi rulat de ctre utilizator.

Rulajul paralel las sistemul vechi s funcioneze n paralel cu sistemul cel nou.n ambele cazuri clientul ruleaz sistemul cel nou pentru un interval de timp X.Dac nu este nici o problem clientul accept sistemul; dac exist probleme acestea sunt remediate i perioada de prob rencepe.Acest mod de abordare prezint cteva inconveniente:

1.Micile probleme pot determina re-reluarea intervalului X pentru o perioad nedefinit.Exist softuri care nu sunt corectate 100% -defectele trebuiesc documentate ca trsturi specifice.

2.Poate fi dificil de stabilit cauza problemelor.Dac 10 utilizatori folosesc simultan sistemul atunci cnd acesta se defecteaz, este greu de determinat cu precizie ce a provocat defeciunea.

3.Nu exist nici o garanie c toate caracteristicile vor fi ncercate n X zile.

4.A lsa utilizatorul s interacioneze cu sistemul nc din prima zi n care acesta este implementat nu este ntotdeauna benefic.

O abordare mai eficient o reprezint elaborarea unei serii de teste care demonstreaz funciile promise.

Acceptana va reprezenta rularea acestor teste ctre utilizator-setul de teste i ordinea n care acestea vor fi rulate se numete Planul de Testare a Acceptanei (ATP-Acceptance Test Plan).

Aceast abordare prezint urmtoarele avantaje:

-toate funciile promise pot fi demonstrate;

-aciunile care cauzeaz probleme sunt totdeauna cunoscute;

-utilizatorul trebuie s dea o singur aprobare, referitoare la ntregul plan;

Dezavantajul major este c e nevoie de mult munc pentru a scrie ATP.

Urmtorul check-list ofer o idee asupra ATP.

Toate promisiunile fcute n specificaia funcional sunt verificate;

Da/Nu;

Sunt definite testele i seturile de testare;

Da/Nu;

Responsabilitatea pentru scrierea testelor este atribuit;

Da/Nu;

Responsabilitatea pentru datele de test este atribuit;

Da/Nu;

Clientul este contient de faptul c ATP poate fi revizuit i completat n funcie de cerinele sale;

Da/Nu;

FAZA DE DEZVOLTARE A PROIECTULUInainte de a ncepe aceast faz trebuiesc verificate urmtoarele aspecte:

Revizuirea designului impune o re-considerare a acestuia ? Dac da, aceasta trebuie re-programat iar nceperea fazei de dezvoltare amnat;

Resursele umane i materiale planificate sunt disponibile ?Dac s-au produs modificri de personal este cunoscut eficiena noului personal ?

Este personalul instruit ?Programatorii trebuie s cunoasc sistemul de operare, interfaa vizual, limbajele i instrumentele pe care le vor folosi.Ei trebuie s fie de asemenea familiarizai cu cerinele utilizatorului.

Este mediul de programare eficient ?

n continuare sunt prezentai paii uzuali de dezvoltare ai unui program.

Planificarea integrrii-planificarea ordinii n care modulele vor fi asamblate mpreun-sub-programele vor fi scrise n ordinea de integrare;

Designul modulelor-plecnd de la faza de design-rezultatele obinute n aceast faz sunt sparte la nivele din ce n ce mai reduse pn cnd se poate programa.Este bine ca designul elementar pentru fiecare modul s fie realizat de ctre programator.

Revizuirea designului elementar-aceast revizuire poate fi realizat de o echip restrns alctuit doar din programator i supervizorul acestuia.Scopul acestui pas este asigurarea unui design optim

Planificarea testrii modulului-aceast planificare trebuie s aib loc nainte de scrierea liniilor de cod.

Codificarea (scrierea programului propriu-zis)Un program structurat prezint urmtoarele atribute:

are dimensiuni reduse-aproximativ 100 de linii de cod executabil;

are o intrare i o ieire;

are referine globale minime;

folosete constructori structurali;

Testarea modulului-testarea se realizeaz prin pregtirea mediului de testare, asigurarea unor intrri, observarea i verificarea funcionrii acestuia.Testarea se realizeaz n 2 faze:

faza de testare white box programatorul alimenteaz modulul cu date astfel nct s fie executat fiecare bloc logic;

faza de testare black box-datele asigurate au structur i frecven identic cu datele reale

Testarea nivelelor cele mai sczute de integrare

Salvarea rezultatelor testelor-modulele finisate sunt trimise spre integrare-rezultatele testelor sunt utilizate pentru a obine date despre cauzele erorilor i posibilitile de remediere ale acestora-de obicei integrarea modulelor este realizat de directorul de proiect

Realizarea documentaiei de utilizare.Aceasta trebuie s includ:

Ghidul utilizator (User Guide)-cerin minim;

Ghidul de ntreinere al sistemului (Maintenance Guide)-documenteaz la nivel de modul tot ce este necesar pentru ntreinerea programului;

Faza de testare a sistemului rezultat n urma proiectuluiFie c vorbim despre proiecte informatice sau despre alte genuri de proiecte- se impune totdeauna o testare. Testarea se poate face dup faza de dezvoltare- pentru prototipul dezvoltat- sau dup faza de implementare- atunci cnd poate deveni ceva mai costisitoare- pentru c nu mai este vorba despre un prototip ci despre ntregul sistem.

Aceast faz este introdus ca i component a fazei de dezvoltare aici deoarece, n majoritatea cazurilor exist o faz de testare (aa numita testare alfa) imediat dup dezvoltare.Ea este bazat pe dou activiti majore:

-toate componentele sunt integrate ntr-un sistem unitar;

-acest sistem este testat;Figura urmtoare prezint fluxul testrii.

Figura Fluxul testrii

Planul de testare al sistemului

Acesta documenteaz nu numai ordinea n care prile sunt integrate ci i testele ce vor fi rulate la fiecare etap a integrrii.Coninutul acestui plan este prezentat n continuare:

planificarea testrii,echipa de testare,necesiti de resurse;

managementul configuraiei,integrarea i instrumentele de testare folosite;

ordinea integrrii-exist trei tipuri de ordonare a integrrii:

integrare top-down;

integrare bottom-up;

integrare dup ordinea dezvoltrii modulelor i funciilor

checklist de teste care s ruleze la fiecare pas al integrrii;sursa acestor teste;

checklist de posibile erori i proceduri de verificare a acestora;

procesul de regresie;

ncrcarea sistemului i teste de performan;

lista de livrabile (surse, documentaie, etc.);

Cteva aspecte referitoare la testarea sistemului sunt prezentate n continuare:

dac nimic nu s-a modificat din momentul integrrii vor trebui reluate cteva din testele folosite la sfritul integrrii-aceste teste urmresc n principal transmiterea parametrilor de la un modul la altul, parametrii returnai i comanda unor funcii (de exemplu salvarea unor fiiere) dintr-un modul n altul;

trebuie elaborat un set de teste apropiat de utilizatorul real-s emuleze modul n care utilizatorul real va folosi sistemul;

trebuie ncercat suprancrcarea sistemului pentru a se asigura c performanele preconizate sunt ndeplinite;

trebuie ncercat introducerea de date de intrare eronate; de asemenea trebuie ncercat simularea erorilor;

n acest moment ATP-ul trebuie s fie terminat-testele din ATP trebuiesc reluate acest pachet de teste va aduga o verificare suplimentar i de asemenea va asigura c sistemul nu produce probleme la testarea public n faza de acceptan;

ETAPA DE IMPLEMENTARE LA UTILIZATOR I TESTARE A ACCEPTANEI PRODUSULUI FINIT

n aceast etap produsul ajunge n mna utilizatorului; acum sunt rulate testele prevzute n ATP-pentru a demonstra utilizatorului funciile promise ale sistemului.Punctul cardinal al acestei faze este reprezentat de semntura utilizatorului.

n continuare este prezentat un checklist al acestei faze:

ATP a fost scris, acceptat de utilizator i revizuit dac acest lucru este necesar;

A fost stabilit o dat pentru demonstraia public;

Echipa necesar pentru rularea acestor teste a fost avizat-inclusiv specialitii care trebuie s fac corecii dac ceva nu funcioneaz;

Resursele necesare au fost pregtite-inclusiv formularele i alte documente scrise;

Exist disponibile copii dup documentaia utilizator

Setul ATP a fost deja testat i s-au realizat eventualele corecii;

Procedura de acceptan a fost stabilit de comun acord cu utilizatorul;

Problemele ntlnite n aceast faz pot fi minore sau foarte importante.Cele din urm pot proveni din interpretri greite ale cerinelor formulate de utilizator.

FAZA DE OPERARE,NTREINERE,MENTENAN

Activitatea major n cadrul acestei faze o reprezint asigurarea garaniei-perioada de timp n care echipa proiectului rezolv orice problem aprut.Punctele cardinale aici sunt un sistem complet funcional i dezvoltarea de noi sisteme.

Garania presupune rezolvarea problemelor cauzate de autorii sistemului, fr plat, pentru o perioad de timp.Garania poate fi asigurat n 3 moduri distincte:

-avnd n permanen un om la sediul utilizatorului;

-avnd pe cineva care s poat fi accesat prin telefon;

-avnd pe cineva care s rspund dup un anumit apel.De obicei persoanele aflate la sediul utilizatorului se ocup i de instruirea acestuia.n toate cazurile trebuie specificat faptul c cineva se va ocupa de problem (nu o va rezolva) ntr-o anumit perioad de timp.

Dac utilizatorul este mulumit, echipa de realizare poate s i propun oferirea urmtorului proiect-versiunea n+1.

Check-listul fazei de operare

Noul sistem este pregtit i funcioneaz;

Trecerea la noul sistem (de la sistemul anterior) este finalizat;

Utilizatorii finali sunt instruii i accept noul sistem;

Garania este asigurat;

FAZE I PROCESE N MANAGEMENTUL PROECTELOR

Indiferent de metodologia folosit se poate considera c :

1. Proiectele sunt realizate n stadii (de dezvoltare);

2. Procese comune de management ale proiectelor au loc n cursul acestor stadii.

Figura urmtoare ilustreaz acest aspect.

Figura Faze i Procese n Managementul ProiectelorFAZELE PROIECTULUI

Fazele sau stadiile sunt foarte importante pentru managementul de proiect. Gndind n termenii acestor faze ne putem asigura c livrabilele realizate la sfritul fiecrei faze i ating obiectivele i c echipa de proiect este pregtit pentru faza urmtoare.

Livrabilele pentru fiecare faz sunt identificate folosind WBS.

Figura urmtoare prezint diagrama WBS pentru un exemplu de proiect.

Figura Diagrama WBS-1Se poate observa c este o diagram simpl- de tip arbore ierarhic.

O diagram ceva mai complex este prezentat n figura urmtoare.

WBS-ul (a se vedea i paragraful dedicat din acest manual) este realizat ca parte a activitilor de pregtire i validat de echipa de proiect. La finalul fiecrei faze cineva semneaz pentru livrabilele respective. Este bine ca nc din faza de pregtire a proiectului s fie stabilii responsabilii pentru fiecare faz. Odat ce o faz e terminat se poate trece la faza urmtoare.

Fazele exacte ale unui proiect pot varia n funcie de necesitile proiectului. n general sunt ntlnite urmtoarele faze:

a.)Definirea strategiilor folosite n proiect i a business case

b)Pregtirea (planificarea) proiectului

c)Proiectare

d)Dezvoltare i testare

e)Instruirea utilizatorilor

f)Suport

g)nchiderea proiectului.

a)Definirea strategiilor folosite n proiect i realizarea business case necesare

n aceast faz sunt definite cerinele generale ale afacerii i sunt propuse abordrile care vor fi folosite pentru a trata aceste cerine. Poarta de la sfritul acestei faze este aprobarea propunerii de proiect precum i al business case care valideaz abordarea propus. Trebuie de asemenea artat c obiectivele proiectului pot fi dobndite n cadrul restriciilor materiale i de timp propuse.

Business case trebuie revizuit la sfritul fiecrei faze pentru a se confirma c mai este nc corespunztor modelului iniial sau pentru a fi modificat.

Business Case

Documentul care definete obiectivele unui proiect i n care ar trebui s se regseasc, printre altele, o analiz serioas cost / beneficiu este identificat de metodologiile de project management sub numele de Business Case.

Sub forma sa iniial, un Business Case este pregtit de ctre persoana care dorete s iniieze un proiect (Sponsor). n funcie de anvergura proiectului dorit, Sponsorul poate nominaliza o echip specializat care s finalizeze Business Case-ul. Acesta va fi apoi supus aprobrii companiei care iniiaz proiectul. Dar cum ajut un Business Case la evitarea problemelor? Prin:- documentarea motivaiei pentru realizarea unui proiect, pe baza costurilor estimate pentru implementare i a beneficiilor anticipate;- prezentarea justificrii bugetului necesar, din perspectiva efortului i a duratei estimate de realizare (se ia n considerare inclusiv opiunea de a nu face nimic);- oferirea posibilitii de monitorizare n permanen a Business Case-ului de ctre organizaie, pe ntreaga durat a derulrii proiectului.La rndul su, monitorizarea Business Case-ului are avantajul de a permite:- verificarea viabilitii Business Case-ului (mai exist nevoia care a dus la demararea proiectului?)- reconfirmarea faptului c proiectul va atinge obiectivele stabilite niiaz proiectul i, n urma acestei aprobri, va deveni certificatul de natere al proiectului.

Ce conine un Business Case?Este fundamental ca justificarea unui proiect s nu fie una tehnic, ci s plece de la o problem funcional i s identifice cea mai bun metod tehnic de rezolvare a acestei probleme. Astfel, un Business Case trebuie s conin:-Istoricul proiectuluii contextul acestuia (alinierea la strategiile generale ale companiei)-Beneficiilecare vor fi realizate (value proposition)-Modalitatea de realizare a beneficiilor(evaluarea opiunilor, justificarea alegerii finale, riscuri)-Faze, etape, planificarei activiti critice-Livrabile-Influene(stakeholders)-Evaluarea financiara investiiei-Necesarul de resursepentru supervizare strategic, project management, execuie, finanare.Pentru a fi util, un Business Case trebuie s fie orientat ctre aspectele economice i mai puin ctre cele tehnice, trebuie s cuprind toate elementele relevante pentru o evaluare complet, trebuie s prezinte beneficii msurabile i s arate modul n care investiia se va recupera (Return of Investment).

Ce poate cuprinde un business case:

managementul riscului pentru proiectul propus;

cerintele proiectului- i analiza acestora;

Realizarea activitilor proiectelor necesit diferite tipuri de resurse: personal, echipament, faciliti, materii prime, informaii, fonduri.

Pentru fiecare resurs necesar pentru sprijinirea sau ndeplinirea lucrrilor sau sarcinilor activitilor se determin:

- capacitatea: productivitatea pe unitate de timp;

- disponibilitatea: cnd anume va fi disponibil resursa.

definirea proiectului n detaliu;

Cnd estimai durata n timp a unei activiti, trebuie s avem n vedere mai nti urmtoarele componente ale activitii:

- munca realizat de resursa uman: activitile fizice i mentale ndeplinite de oameni. Exemple: scrierea unui raport, asamblarea unui echipament sau gndirea ideilor pentru o companie publicitar;

- munca realizat de resurse non-umane: timpul de procesare a unui material de ctre un utilaj sau capacitatea de transfer a echipamentelor;

- procesele de durat: reaciile fizice sau chimice ce impun ateptarea: uscarea vopselei, reacii chimice, instalarea vegetaiei pe un teren proaspt lucrat, etc.;

-timpul de ateptare: este datorat disponibilitii resurselor.

Cnd se descriu activitile, consultai urmtoarele surse de informaii pentru a estima mai corect durata:

- nregistrri mai vechi despre durata necesar pentru ndeplinirea aceleiai activiti n trecut;

- persoane care au ndeplinit astfel de activiti n trecut;

- persoane ce vor lucra la aceste activiti;

- experi familiarizai cu acest tip de activiti, chiar dac nu au mai lucrat pe aceeai problem mai nainte.

diagrame functionale;

functiile principale ale sistemului;

conceptul operational;

responsabilitatile clientului;

caracteristicile sau solutiile finale ale proiectului;

definitiile interfeelor functionale cu utilizatorul;

cash-flow si/sau ROI(Return on Investment);

constrangeri legale la nivel naional sau internaional; aspectele privind IPR (Intelectual Property Rights- Drepturile de Proprietate Intelectual);

specificatii si standarde inclusiv standardele de calitate folosite pentru proiect;

metodologii necesare

pregatirea livrarii

mentenanta si suport.

b)Pregtirea

n cadrul acestei faze :

-b.1.)se realizeaz un WBS la nivel de detaliu (vezi figura).

Figura Diagrama WBS-2-b.2.) Se determin planul detaliat al proiectului la nivel de puncte cheie (milestones)

-b.3.)Sunt stabilii membrii echipei de proiect.

-b.4.)Se realizeaz un document de iniiere al proiectului (acest document poate fi i contractul cadru cu finanatorul n cazul competiiilor interne i externe). Un astfel de document, cunoscut i ca PID (Project Initiation Document) trebuie s permit:

-Definirea proiectului i a scopului acestuia;

-Justificarea proiectului;

-Asigurarea finanrii pentru proiect (contractul cadru de care aminteam);

-Definirea rolurilor i responsabilitilor participanilor la proiect;

-Stabilirea informaiilor necesare pentru a fi productiv i efectiv nc de la startul proiectului ;

Prin dezvoltarea unui PID se rspunde la ntrebrile: Ce ? De ce ? Cine ? Cum ? Cnd ?

-b.5.)Selectarea terilor care vor fi folosii n etapele primare ale proiectului (dac este cazul);

-b.6.)Asigurarea resurselor cheie (alocare timpi de calculator, rezervri, etc.);

c)Design-ul (proiectarea)

n aceast faz activitatea ncepe cu crearea livrabilelor proiectului, utiliznd strategiile stabilite, business case-ul i PID ca puncte de plecare. Se presupune lucrul cu principalele persoane interesate (stakeholderi) pentru a dezvolta proiectul principalelor livrabile. n proiecte mai mari pot fi utilizai analitii de business. Echipa proiectului va aviza probabil proiectul final- este ns bine s implicm pe toi cei interesai i care pot s ofere o plus-valoare interesant. Designul este foarte important pentru calitatea urmtoarelor rezultate. Un design bun va determina o calitate bun- pe cnd cu un design prost vor trebui depuse eforturi suplimentare pentru a se atinge calitatea dorit. Pentru proiecte care prezint riscuri sau incertitudini tehnice relevante- este bine s se includ o faz de fezabilitate. Aceast faz va crete certitudinea c ceea ce este planificat va funciona- i va permite oprirea la timp a proiectului dac nu poate fi dovedit fezabilitatea acestuia.

d)Dezvoltarea i testarea

n aceast faz accentul trebuie pus pe deinerea IPR (Intelectual Property Rights-Drepturi de Autor) necesare pentru dezvoltare (licene de software, acorduri, etc.) iar dac IPR-urile rezultate n urma proiectului nu sunt stabilite- ele trebuiesc definite n mod clar.

Figura urmtoare prezint schema de care trebuie s se in seama la definirea i stabilirea IPR. Trebuie subliniat c spre deosebire de perioadele anterioare la toate proiectele finanate de ctre UE se pune un accent foarte serios pe aceast component- la majoritatea proiectelor din cadrul Horizon 2020 solicitndu-se prevederi speciale n ceea ce privete IPR.

Beneficiarii proiectului vor s se conving c:

-nu exist componente plagiate din diverse materiale- acest lucru putnd compromite att pe realizator ct i pe cel care verific proiectul i pe finanatori- dac nu observ plagiatul;

-nu exist instrumente de dezvoltare sau metodologii pentru care echipa de proiect s nu dein drepturi de autor;

-drepturile de autor pentru materialele care vor fi dezvoltate n cadrul proiectului sunt clar stabilite; aici trebuie luat n considerare finanatorul- dac proiectul este finanat n totalitate sau n marea sa majoritate din fonduri naionale sau din fonduri UE este recomandabil ca cel puin o parte din rezultate s fie cu acces public.

-drepturi de autor pentru dezvoltri viitoare;

Exemplu Un proiect dezvoltat n cadrul fondurilor Europene a realizat un sistem de formare n afara clasei (asemntor cu e-learning) folosind un soft pentru care se deinea o licen demo. Dup expirarea respectivei licene (30 de zile) aceasta n-a fost achiziionat- deoarece software-ul era deja realizat.

La momentul plilor pentru respectivul proiect- ofierul tiinific al UE este atenionat de ctre firma care deinea IPR pentru softul de dezvoltare c nu exist baz legal a deinerii i folosirii softului X de ctre echipa de dezvoltare- avertiznd c dac nu se rezolv acest aspect, firma va da n judecat Directoratul Cercetare al UE- n cazul n care rezultatele care au folosit produsul-program al firmei sunt fcute publice.

n aceste condiii s-a ntrunit comisia de decizie (Steering Comitee) a UE i au ajuns la concluzia c ultimele 2 trane de plat din cadrul proiectului trebuie stopate- pn la rezolvarea incidentului ntre echipa de realizare i productorul de soft.

Firma a solicitat despgubiri din partea echipei de realizare a proiectului- de circa 100 de ori valoarea licenei iniiale- precum i o cerere public de scuze care s apar n cel puin 3 cotidiene.

Figura Analiza deinerii de IPR n cadrul fazei de dezvoltaree)Asigurarea instruirii personalului n utilizarea noului sistemAcest stadiu se refer la prepararea lansrii proiectului- n acest faz:

-sunt instruii utilizatorii;

-se fac probe i exerciii cu date reale;

-identific necesitile ulterioare;

f)Suportul pentru utilizarea sistemuluiAsigurai-v c furnizai suport pentru utilizatori o dat ce proiectul e lansat i considerai lucrurile care mai trebuiesc fcute nainte de re-asignarea echipei. Exist situaii n care echipele de proiect sunt re-asignate prea repede- contribuind la ne-realizarea tuturor obiectivelor importante ale proiectului. Monitorizai obinerea beneficiilor i managementul acestora.Managementul beneficiilor

Managementul beneficiilor este procesul prin care realizatorii se asigur c proiectul ofer ceea ce este ateptat de la el. n managementul beneficiilor se rspund la ntrebri cum ar fi :

-De ce se realizeaz proiectul ?

-Ce obiective de business vor corespunde realizrii proiectului ?

-Au fost definite toate beneficiile ateptate ?

-Cum msurm beneficiile ?

-Este proiectul nc valid ?

-Sunt beneficiile nc relevante ?

Timpul investit n managementul beneficilor va permite reducerea riscurilor referitoare la proiect, oblignd realizatorii s analizeze aspectele organizaionale care pot afecta succesul proiectului i rezolvarea acestor aspecte ct mai curnd.

Punctul central al managementului beneficiilor este asigurarea obinerii a ceea ce dorii de la proiect- adic nu numai terminarea acestuia la timp i n resursele stabilite. Succesul managementului beneficiilor proiectului merge cu un pas mai departe dect managementul proiectului.

Etapele managementului beneficiilor sunt prezentate n urmtoarea figur.

-n etapa 1:

-stabilii cu stakeholderii la ce beneficii se ateapt i care din ele sunt realiste;

-dezvoltai o declaraie de beneficii;

-facei o list comparativ ntre beneficiile pe care ar fi frumos s le avem i cele pe care trebuie s le avem;

-identificai cum beneficiile se aliniaz cu strategia companiei i necesitile afacerii;

-decidei ce trebuie fcut pentru maximizarea beneficiilor;

-facei distincia ntre beneficiile tangibile i cele intangibile;

Figura Etapele Managementului Beneficiilor

-n etapa 2:

-Urmrii planul general al proiectului i asigurai-v c activitile necesare de suport sunt furnizate astfel nct beneficiile s poat fi obinute n timp (de exemplu raportarea corect i la timp a unei etape pentru a obine plata pentru etapa respectiv- chiar dac etapa a fost realizat n bune condiii- raportarea corespunztoare este necesar pentru a obine contravaloarea etapei)

-Urmrii posibile guri n beneficii ct i beneficii adiionale (de exemplu formarea managementului- pe lng formarea celor care lucreaz cu sistemul);

-Identificai cine este responsabil pentru activitile de suport menionate mai sus;

-Stabilii metrici pentru fiecare beneficiu i determinai cnd i cum putei determina c beneficiul a fost livrat.

-Includei un rezumat privitor la managementul beneficiilor n business case;

g)nchiderea proiectului

nchiderea proiectului nu este cea mai excitant faz dar, dac nu este fcut corespunztor- poate conduce la pierderi de beneficiu. Asigurai-v c ai fcut urmtoarele:

-Completarea i stocarea documentaiei de proiect;

-O revizuire post-implementare astfel nct experiena acumulat s fie folosit i n alte proiecte;

STUDIU DE CAZ

n continuare sunt prezentate cteva exemple dintr-o abordare profesionist a managementului de proiect n SUA.

n prima figur se poate observa un format folosit pentru Business Case

Figura Format folosit pentru Business Case

Se observ faptul c un Business Case presupune minim 3 opiuni- fiecare din aceste soluii trebuie ierarhizat pe o scal de la 1 la 10 (de preferin)- iar soluia cu evaluarea cea mai mare va constitui soluia aleas.

Figura urmtoare prezint un cuprins acoperitor al proiectului.

Figura Cuprinsul proiectului

Se poate observa c acest cuprins este acoperitor pentru majoritatea tipurilor de proiecte realizate n Romnia.

Planul de implementare conine:

-Descrierea abordrii folosite;

-Planificarea;

-Punctele cheie (milestone);

-Dependinele;

-Planificarea resurselor;

-Planificarea financiar;

-Planificarea aspectelor legate de calitate;

-Criterii de considerare a completitudinii;

Mrimea proiectului

Mrimea proiectului e definit plecnd de la:

-Resursele financiare disponibile;

-Mrimea echipei;

-Livrabilele care trebuiesc produse;

-Complexitatea acestor livrabile;

-Restriciile de timp;

Figura urmtoare prezint aceste mrimi

Figura Tipuri de proiecte n funcie de mrime i complexitate.Tabelul urmtor d mrimea proiectelor n funcie de numrul de ore alocat

.Tabel

MRIME PROIECTORE EFORT

MICI1-250

MEDII251-2500

MARI> 2500

Diagrama urmtoare ne d legtura ntre mrimea proiectului i fazele care trebuie incluse n proiect.

Figura Legtura ntre mrimea proiectului i fazele care trebuiesc incluse n proiectFigurile urmtoare dau o succesiune a etapelor pentru fiecare din fazele principale ale proiectului din studiul de caz. Este evident c pentru proiecte specifice pot fi selectate doar etapele relevante.

Figura Faza de iniiere a proiectuluiFigura urmtoare prezint faza de planificare.

Figura Faza de Planificare

Schema pentru planul de resurse este dat n figura urmtoare.

Figura Schema planului de resurseFigura urmtoare prezint planul de calitate

Figura Planificarea asigurrii calitiiFigura urmtoare prezint ultimele 2 faze din proiect.

Figura Fazele de execuie i nchidere ale proiectuluiSe poate vedea cum se realizeaz managementul timpului n figura urmtoare.

Figura Managementul timpuluiMembrul n echip:

-preia o sarcin;

-completeaz o foaie individual de timp (timesheet);

-solicit aprobarea pentru respectivul timesheet;

Managerul de proiect:

-aprob respectivul timesheet sau dac nu solicit recompletarea sa;

Administratorul proiectului:

-actualizeaz planul proiectului;

-verific dac proiectul e n limitele restriciilor de timp;

-notific managemetul de proiect dac exist probleme;

Figura urmtoare prezint schematic managementul cheltuielilor.

Figura Managementul cheltuielilorMembrul n echip:

-Identific categoriile de cheltuieli;

-Completeaz formularele necesare;

-Solicit aprobarea cheltuielilor;

Componentele din procesul de management al schimbrii sunt date n continuare.

Figura Componentele procesului de management al schimbriin figur se poate observa faptul c respectivele schimbri identificate sunt aprobate DOAR atunci cnd sunt critice (sau eseniale) pentru proiectul n curs. N-are nici un fel de rost s aprobi o schimbare , s o implementezi i s cheltuieti resursele aferente atunci cnd respectiva schimbare nu este relevant.

Exemplu

ntr-un proiect desfurat pe fonduri europene, dl. X i dl. Y- dup nceperea proiectului- i dobndesc noi titluri tiinifice. Dl.X i dl.Y solicit modificarea schemei de personal din proiect cu adugarea acestor noi titluri. Acest lucru presupune:

-realizarea unei scrisori din partea managementului de proiect ctre Directoratul Cercetare din UE;

-formularea unei cereri de aprobare pentru toi participanii multinaionali din cadrul proiectului;

-aprobarea cererii de ctre Steering Comitee-ul proiectului;

-aprobarea cererii de ctre ofierul tiinific al UE;

Se poate observa c efortul necesar este mult mai mare dect ar fi nevoie- schimbarea urmnd a fi efectuat la urmtorul proiect. Menionm c dac s-ar fi realizat- schimbarea nu aducea nimic nici pentru cele 2 persoane i nici pentru proiectul n sine.

Figura urmtoare prezint fluxul n cadrul managementului calitii.

Figura Managementul CalitiiAa cum se observ din figur, managementul calitii presupune urmtoarele faze i activiti:

a)Msurarea calitii:

-Revizuirea asigurrii calitii (n cursul proiectului, folosind referenialele stabilite);

-Revizuirea controlului calitii;

-Identificarea rezultatelor legate de calitate;

-Verificarea acestor rezultate prin comparaie cu referenialele;

-Identificarea aciunilor corective- dac e cazul;

-Identificarea necesitii unor schimbri (dac e cazul)- de exemplu, pe parcursul derulrii proiectului apar noi standarde sau alte refereniale de calitate;

b)mbuntirea calitii:

-Obinerea aprobrilor pentru schimbri;

-Implementarea aciunilor/schimbrilor corective;

Componentele din fluxul de management al riscurilor sunt date n urmtoarea figur:

Figura Procesul de management al riscurilorSe poate observa c dac riscurile nu sunt considerate ca avnd o prioritate nalt ele pot fi tratate de managerul de proiect i de membrii echipei. Dac riscurile au o prioritizare nalt atunci echipa de conducere a proiectului (echip n care, n mod normal, fac parte i alte persoane n afara celor din proiect- trebuie s decid cine rspunde de aciunile de implementare).Acest lucru poate fi semnificativ de exemplu, atunci cnd datorit unor astfel de riscuri posibile- finanatorul (de exemplu fondurile Europene) amenin c nu pltete n continuare sau nu ramburseaz o anumit etap. n aceast situaie- de exemplu n care managerul de proiect este considerat ca fiind insuficient de calificat e nevoie de o persoan n care finanatorul s aib ncredere- de exemplu un specialist n managementul financiar care s re-aeze lucrurile .

Figura urmtoare prezint fluxul pentru managementul achiziiilor.

Figura Managementul achiziiilorUn aspect special n aceste procese de management este deinut d