1. managementul integrĂrii proiectului - …2+3.pdf · managementul proiectelor În dezvoltarea de...

Ioan-Dan FILIPOIU Constantin RNEA

49

1. MANAGEMENTUL INTEGRRII PROIECTULUI

Managementul integrrii proiectului asigur procesele necesare integrrii corecte a elementelor componente ale proiectului, care uneori pot fi contradictorii. Aceasta presupune recurgerea la un arbitraj ntre obiectivele propuse i soluiile adoptate pentru a putea satisface nevoile i a ndeplini ateptrile prilor interesate. MANAGEMENTUL INTEGRRII PROIECTULUI

1.1. Elaborarea planului

3. Date de ieire 1. Planul proiectului 2. Piese complementare

1. Date de intrare 1. Date de ieire ale altor

procese 2. Date istorice 3. Politici de organizare 4. Constrngeri 5. Ipoteze

2.Instrumente i metode 1. Metodologii de planifi-

care a proiectului 2. Competene ale prilor

interesate 3. Sisteme informatice ale

managementului de proiect

1.2. Aplicarea planului

3. Date de ieire 1. Activiti realizate 2. Cereri de modificare

1.Date de intrare 1. Planul proiectului 2. Detalii ajuttoare 3. Politica organizaiei 4. Aciuni corective

2.Instrumente i metode 1 Competene n management 2. Competene i cunotine

despre produs 3. Sisteme de autorizare a aplicrii 4. Raportri ale stadiului proiectului5. Sisteme informatice ale

managementului de proiect 6. Proceduri de organizare

1.3. Gestionarea modificrilor

3. Date de ieire 1. Rectificarea planului

proiectului 2. Aciuni corective 3. Diseminarea

experienei

1.Date de intrare 1. Planul proiectului 2. Raportri privind

stadiul proiectului 3. Cereri de modificare

2.Instrumente i metode 1. Sistemele de gestionare a

modificrilor 2. Managementul coninutului

proiectului 3. Msurarea performanelor 4. Planificarea

complementar 5. Sisteme informatice ale


Fig. 1.1. Schema de ansamblu a managementului inegrrii proceselor specifice proiectului

MANAGEMENTUL PROIECTELOR N DEZVOLTAREA DE PRODUS

50

Procesele specifice managementului integrrii proiectelor sunt prin esena lor integrative. n figura 1.1. este prezentat o vedere de ansamblu a principalelor trei procese ale managementului integrrii proiectelor:

1.1. Elaborarea planului proiectului 1.2. Aplicarea planului proiectului 1.3. Gestionarea modificrilor fa de planul iniial al proiectului Aceste procese interacioneaz ntre ele cu procesele altor domenii specifice

managementului de proiect. Fiecare proces necesit participarea unei persoane sau a ntregii echipe n funcie de nevoile etapei n care se afl proiectul. n general, fiecare din aceste procese au loc cel puin o dat n cursul fiecrei faze a proiectului.

Dei procesele descrise aici sunt activiti bine identificate, cu limite foarte clare, n practic, ele pot s se desfoare sau s interacioneze ntr-un mod care nu este descris aici. Interaciunile ntre procese sunt detaliate n capitolul 3 din partea nti.

Procesele, instrumentele i metodele frecvent utilizate pentru integrarea proiectului constituie subiectul acestui capitol. De exemplu, procesul de coordonare intervine atunci cnd o estimare a costurilor este necesar pentru cuantificarea riscurilor, sau cnd trebuie evaluate riscurile asociate diverselor variante ale strategiei adoptate n derularea proiectului. ntr-adevr, pentru ca un proiect s reueasc, coordonarea trebuie aplicat n numeroase alte domenii, ca de exemplu:

- munca la proiect trebuie s in seama de activitile curente ale organismului nsrcinat cu derularea proiectului;

- coninutul proiectului trebuie s fie coerent ca de altfel i materializarea funciilor impuse noului produs care rezult la finalizarea proiectului (diferenele ntre cele dou obiective sunt tratate n capitolului 2);

- serviciile de orice natur (de exemplu, planurile sistemului mecanic, hidraulic, electric, electronic i de automatizare, dintr-un proiect de studiu ingineresc) trebuie integrate.

1.1. ELABORAREA PLANULUI PROIECTULUI

Planul proiectului utilizeaz rezultatele proceselor de planificare ale diverselor

discipline pentru constituirea unui document logic i coerent, care poate fi folosit la fel de bine i pentru activitile de conducere a proiectului. Acest proces presupune totdeauna mai multe iteraii. De exemplu, ntr-o prim faz se pot descrie la modul general, mijloacele, fr s se precizeze durata activitii, n timp ce n faza final, se detaliaz toate resursele i se expliciteaz datele. Elaborarea planului proiectului urmrete realizarea unui document logic i coerent utiliznd celelalte procese de planificare i este utilizat pentru:

- a ghida execuia unui proiect;


51

- a meniona n scris ipotezele emise n procesul de planificare; - a justifica motivele alegerii uneia dintre variante; - facilitarea comunicrii ntre prile interesate; - fixarea obiectivelor principale (coninut, ateptri i date) ale proiectului; - furnizarea unui referenial (caiet de sarcini) pentru verificarea stadiului de

ndeplinire a obiectivelor proiectului i a modului cum acesta este condus.

1.1.1. Date de intrare pentru elaborarea planului proiectului

Elaborarea planului proiectului este prezentat n figura 1.2.

1.1. Elaborarea planului

3. Date de ieire 1. Planul proiectului 2. Piese complementare

1. Date de intrare 1. Datele de ieire ale

altor procese 2. Date istorice 3. Politici de organizare 4. Constrngeri 5. Ipoteze

2.Instrumente i metode 1. Metodologii de planifi-

care a proiectului 2. Competene ale prilor

interesate 3. Sisteme informatice ale

managementului proiectului

Fig. 1.2. Schema de elaborare a planului proiectului Datele de ieire ale altor procese de planificare, specifice altor discipline ale

managementului de proiect, servesc ca date de intrare n elaborarea planului de realizare a proiectului. n procesul de elaborare a planului se dispune de documente general valabile. Printre acestea pot fi enumerate structura de distribuie, n detaliu, a sarcinilor pe colectivele existente n cadrul echipei, precum i a repartizrii sarcinilor pe membrii echipei. Majoritatea proiectelor necesit i utilizarea unor documente specifice cum ar fi, de exemplu, elaborarea unui plan financiar previzional de repartizare a costurilor.

Datele istorice reprezint informaiile disponibile existente din derularea altor proiecte, absolut necesare la elaborarea planului de realizare a proiectului. De exemplu, arhivele proiectelor deja ncheiate, bazele de date privind estimrile, sunt consultate cu ocazia elaborrii planurilor altor procese ale managementului de proiect. Aceste informaii trebuie, de asemenea, s fie disponibile pentru a ajuta la verificarea ipotezelor i estimarea variantelor ce pot fi incluse n proiect odat cu ntocmirea planului proiectului.

Politicile de organizare cuprind toate regulile interne sau externe de funcionare, ale cror consecine trebuie luate n seam de toate organizaiile implicate n proiect. Printre politicile de organizare de care se ine seama n elaborarea planului de realizare a proiectului se pot enumera:


52

- managementul calitii avnd ca obiectiv ameliorarea continu obinut prin proceduri de audit a proceselor de management al proiectului;

- gestionarea personalului se impune prin proceduri de angajare i de concediere, de evaluare a colaboratorilor;

- controlul financiar realizat printr-un raport asupra stadiului proiectului, trecerea n revist a cheltuielilor, sistematizarea calculelor privind costurile, provizioane contractuale standard.

Constrngerile limiteaz libertatea de aciune a membrilor echipei din proiect. Impunerea bugetului este o constrngere care limiteaz considerabil opiunile echipei n elaborarea proiectului precum i coninutul acestuia. Reducerea bugetului poate conduce la diminuarea efectivului echipei i la ntrzieri. Atunci cnd execuia unui proiect rezult n urma unui contract, provizioanele contractuale constituie, n general, constrngeri.

Ipotezele reprezint presupuneri enunate pe baza experienei acumulate, care pentru nevoile procesului de planificare, se vor considera adevrate, reale sau existente. De exemplu, dac nu este sigur data la care o persoan cheie din echip poate fi disponibil, echipa va fixa arbitrar momentul de ncepere a activitii. Ipotezele antreneaz, n general, un anumit grad de risc.

1.1.2. Instrumente i metode de elaborare a planului proiectului

Metodologia de planificare a proiectului se poate considera ca fiind toate abordrile structurale, metodele de cercetare utilizate, pentru a ajuta echipa n elaborarea planului proiectului. Aceasta poate fi un simplu formular sau o schem, un plan standard (elaborat pe hrtie sau cu ajutorul tehnicilor de calcul, tipizate sau nu), sau mult mai complexe, cu o serie de simulri (de exemplu, analiza riscului de ntrziere prin metoda Monte-Carlo). Multe metodologii de planificare a proiectelor combin instrumente ca de exemplu: programe informatice i tehnici precum reuniuni i edine de lucru organizate odat cu lansarea proiectului.

Competenele fiecrei pri implicate n derularea proiectului pot fi utilizate cu succes n pregtirea minuioas a planului proiectului. Echipa de management al proiectului trebuie s creeze ambiana necesar tuturor prilor implicate pentru a-i aduce contribuia la dezvoltarea ct mai eficient a proiectului: cine contribuie, cu ce contribuie, i cnd trebuie s intervin (a se vedea, de asemenea, subcapitolul 5.4., Dezvoltarea echipei). n cele ce urmeaz sunt date dou exemple.

ntr-un proiect de dezvoltare a unui produs sau serviciu nou, realizat pe baz de contract, a crui valoare este tratat n mod forfetar (pentru care s-a stabilit dinainte o sum global i invariabil), controlorul gestionrii are o contribuie major asupra obiectivelor referitoare la profit. Faza de pregtire a propunerii ofertei de proiect este crucial deoarece, n timpul elaborrii ei se stabilete cadrul contractului.


53

ntr-un proiect n care efectivul echipei este cunoscut dinainte, fiecare participant poate contribui la ndeplinirea obiectivelor legate de costuri i termene, prin revizuirea estimrilor privind mijloacele i duratele de realizare a fiecrei activiti.

Sistemele informatice ale managementului proiectului sunt formate din instrumentele i metodele utilizate pentru strngerea, asimilarea i difuzarea datelor de ieire din toate procesele specifice managementului proiectului. Ele servesc pentru susinerea tuturor aciunilor proiectului, de la iniierea lui pn la finalizare. Corectarea i prelucrarea datelor presupune n general sisteme computerizate sau proceduri.

1.1.3. Date de ieire din procesul de elaborare a planului proiectului

Planul proiectului este un document tipizat i consimit, utilizat pentru a gestiona i a conduce execuia proiectului. El trebuie difuzat aa cum este prevzut n planul privind managementul comunicrii. De exemplu, managementul organizaiei economice nsrcinate cu elaborarea proiectului are o privire de ansamblu asupra tuturor activitilor pe care le prezint mai mult sau mai puin n detaliu, n timp ce un subcontractor are nevoie doar de un singur subiect, dar foarte detaliat precizat. n anumite domenii de aplicare, termenul planul proiectului integrat poate fi utilizat n egal msur.

Trebuie s se fac distincie clar ntre planul proiectului i referinele de baz ale proiectului. Planul proiectului este un document sau un ansamblu de documente care vor fi mbuntite pe msur ce sosesc informaiile despre proiect. Referenialul de msurare a performanelor este un instrument de control al managementului, care poate fi schimbat dect la modul intermitent i numai ca rspuns la o modificare a obiectivelor proiectului. De exemplu,n dezvoltarea de produs, elaborarea referenialului iniial are loc n etapa activitii de cercetare aplicativ, n timp ce definitivarea referenialului se realizeaz la finalizarea activitilor de dezvoltare tehnologic, dup ce a fost realizat i experimentat prototipul (vezi tabelul 2.1 din partea nti a lucrrii).

Exist multe moduri de organizare i de prezentare a planului proiectului, dar ele includ de obicei urmtoarele elemente (care sunt descrise n detaliu n cele ce urmeaz):

- schema (diagrama) de realizare a proiectului; - descrierea strategiei de management al proiectului (rezumatul planului

obinut prin corelarea cu alte discipline de management al proiectului); - enunul coninutului proiectului, cu livrabilele (furnizrile de materiale,

echipamente etc.) proiectului i obiectivele acestuia; - structura descompus a proiectului, pn la nivelul unde controlul poate fi

realizat efectiv; - estimarea costurilor, repartizarea responsabilitilor, stabilirea datelor de

ncepere i ncheiere, pn la nivelul la care se poate face efectiv controlul;


54

- elaborarea referenialului de msurare a performanelor referitoare la cost i ntrzieri;

- lista de personal care include att persoanele cheie ct i efectivul necesar al echipei;

- evidenierea jaloanelor principale, cu datele lor previzionale; - posibile riscuri principale, cu constrngerile i ipotezele corespunztoare

precum i soluiile propuse pentru rezolvare; - planurile de management anexate, nelegnd prin acestea planul de

management al coninutului proiectului, planul de management al calendarului de realizare a obiectivelor cu termenele scadente;

- lista problemelor curente i a deciziilor ce ateapt rezolvare.

Alte elemente pot, de asemenea, fi incluse n planul proiectului tipizat. De multe ori planul unui proiect mare comport, n general i o organigram funcional.

Piesele complementare sunt constituite din detaliile ajuttoare ale planului proiectului. Acestea conin:

- elementele altor planuri de proiect care nu sunt incluse n planul proiectului; - informaii complementare sau documente elaborate n cursul pregtirii

planului proiectului (de exemplu, constrngeri i ipoteze necunoscute anterior);

- documentaii tehnice, precum condiiile i specificaiile tehnice necesare realizrii proiectului;

- documente ce conin reglementrile legislative i normele aplicabile existente.

Aceste elemente trebuie prezentate de aa manier nct utilizarea lor s fie ct mai eficient pe toat durata propus pentru realizarea proiectului.

1.2. APLICAREA PLANULUI PROIECTULUI

Aplicarea planului de realizare a proiectului are drept int ndeplinirea tuturor

activitilor prevzute cu scopul realizrii n condiii optime a obiectivelor proiectului. Cea mai mare parte a bugetului proiectului va fi cheltuit n timpul derulrii acestui proces principal. Activitatea conductorului de proiect i a membrilor echipei, n acest proces, este de a coordona i pilota diferitele interfee tehnice i organizatorice ale proiectului, care se afl printre activitile de proiectare, dependente mai mult de domeniul aplicativ al cercetrii precum dezvoltarea tehnologic i transferul tehnologic. n aceast etap se creeaz efectiv rezultatul propus n proiect.


55

1.2. Aplicarea planului

3. Date de ieire 1. Activiti realizate 2. Cereri de modificare

1.Date de intrare 1. Planul proiectului 2. Detalii ajuttoare 3. Politica organizaiei 4. Aciuni corective

2.Instrumente i metode 1 Competene n management 2. Competene i cunotine despre

produs 3. Sisteme de autorizare a aplicrii 4. Raportri ale stadiului proiectului5. Sisteme informatice ale

managementului de proiect 6. Proceduri de organizare

Fig. 1.3. Aplicarea planului de realizare a proiectului

1.2.1. Date de intrare pentru aplicarea planului de realizare

Planul proiectului, descris n paragraful 1.1.3 constituie piesa principal pentru realizarea n bune condiii a proiectului . Planurile de management anexate (planul de management al coninutului proiectului, planul de management al riscurilor, programul de aprovizionare etc.) i referenialul de msurare a performanelor sunt date de intrare eseniale pentru execuie.

Detaliile ajuttoare (piesele complementare) sunt descrise, de asemenea, n paragraful 1.1.3.

Politicile organizaiei sunt descrise n paragraful 1.1.1. Fiecare organizaie implicat n proiect duce o politic formal sau informal, cu reguli interne sau externe de funcionare, care pot avea consecine mai favorabile asupra punerii n aplicare a planului proiectului.

Aciunile corective se efectueaz pentru a raporta performanele ateptate ale proiectului cuprinse n cadrul planului de realizare al lui. Aciunile corective sunt rezultatul ctorva procese de control i de conducere. Toate acestea se regsesc, de asemenea, ca date de intrare, ele participnd la feedback-ul necesar managementului efectiv al proiectului.

1.2.2. Instrumente i metode de aplicare a planului proiectului

Competenele de management n general, precum aptitudinea de a dirija, comunicarea i negocierea sunt eseniale pentru aplicarea eficient a planului proiectului. Aceste competene sunt descrise n subcapitolul 1.6 din partea nti a lucrrii.

Competenele i cunotinele necesare despre produs intr n atribuiile echipei de proiect care trebuie s posede cunotine tehnico-economice suficiente despre produsul ce va constitui rezultatul proiectului. Competenele necesare, ale membrilor echipei, fac parte din cele ce se regsesc n planificarea resurselor (vezi subcapitolul


56

4.1) i sunt strnse n cadrul procesului de obinere a resurselor umane (descrise n subcapitolul 5.2).

Sistemele de autorizare a aplicrii planului sunt constituite din proceduri tipizate i reglementri legislative care se aplic pentru a constata c lucrrile sunt bine realizate n timpul convenit i la un nivel corespunztor. Mecanismul rspunde esenial la necesitatea unei autorizri scrise pentru nceperea execuiei unei activiti, sau unui lot de lucru dat. Studiul sistemului de autorizare a lucrrii efectuate trebuie s in seama att de interesul supremaiei astfel obinute, ct i de costurile acestei supremaii.

Raportrile privind stadiul proiectului presupun reuniuni, edine de lucru, programate regulat pentru a schimba informaii privind proiectul. n multe proiecte, raportrile se fac cu o frecven variabil i la nivele diferite (de exemplu, echipa de management a proiectului poate organiza / edine interne sptmnale sau lunare cu beneficiarii proiectului).

Sistemele informatice ale managementului de proiect sunt descrise n paragraful 1.1.2.

Procedurile de organizare reprezint totalitatea regulilor organizatorice, interne i externe, aplicate de ctre fiecare unitate implicat n proiect.

1.2.3. Date de ieire din procesul de aplicare a planului proiectului

Activitile realizate se oglindesc prin munca prestat efectiv pe parcursul derulrii proiectului. Informaia privind munca efectuat este considerat ca element de aplicare a planului proiectului i alimenteaz procesul de raportare a stadiului proiectului. Raportrile privind stadiului proiectului cuprind, printre altele, detalii care s ateste buna desfurare a activitilor de aprovizionare, legate de costuri, de calitate etc.:

- care sunt livrabilele (furnizrile de materiale echipamente etc.) care au fost deja achiziionate i care urmeaz a fi achiziionate;

- n ce msur standardele de calitate au fost atinse; - ce costuri au fost angajate sau atrase.

Cererile de modificare sunt adesea inevitabile n timpul derulrii proiectului, urmare a coreciilor ce se impun a fi fcute la apariia unor factori interni sau externi perturbatori. De exemplu, creterea sau reducerea coninutului proiectului i a estimrilor privind costurile i termenele de realizare a activitilor impun efecturi de corecii ale planului.


57

1.3. GESTIONAREA MODIFICRILOR FA DE PLANUL

INIIAL AL PROIECTULUI

Gestionarea modificrilor se face pentru controlul, coordonarea i diminuarea efectelor cauzate de modificrile, inevitabile, survenite pe ansamblul proiectului i acioneaz asupra factorilor ce au condus la corecia planului de realizare a proiectului. Se urmrete ca acele modificri care s-au produs, s fie gestionate efectiv (cnd i cum s-au produs), cu scopul asigurrii c aceste schimbri sunt benefice pentru realizarea i finalizarea proiectului.

Gestionarea modificrilor implic:

- controlul modificrilor din diversele discipline ale managementului de proiect, aa cum este ilustrat n figura 1.5. (de exemplu, o cerere de modificare a scandenarului se va repercuta adesea asupra costurilor, riscurilor, calitii i cantitii);

- evidenierea i nregistrarea n planul de realizare a proiectului a tuturor modificrilor aprobate;

- meninerea integritii referenialului de msurare a performanelor; - modificrile de coninut pot s afecteze referenialul de msurare a

performanelor; - asigurarea c modificrile de coninut ale produsului se regsesc n definiia

coninutului proiectului (diferenele dintre coninutul proiectului i cel al rezultatului su sunt tratate n introducerea capitolului 2).

1.3. Gestionarea modificrilor

3. Date de ieire 1. Rectificarea planului

proiectului 2. Aciuni corective 3. Diseminarea experienei

1.Date de intrare 1. Planul proiectului 2. Raportri privind

stadiul proiectului 3. Cererea de

modificare

2.Instrumente i metode 1. Sistemele de gestionare a

modificrilor 2. Managementul coninutului

proiectului 3. Msurarea performanelor 4. Planificarea complementar5. Sisteme informatice ale


Fig. 1.4. Gestionarea modificrilor planului de realizare a proiectului


58

Fig. 1.5. Coordonarea modificrilor pe ansamblul proiectului

Raportri ale stadiului proiectului

Gestionarea modificrilor

GESTIONAREA MODIFICRILOR PE DISCIPLINE

Gestionarea modificrilor de coninut Gestionarea ntrzierilor

Gestionarea modificrilor costurilor Gestionarea calitii

Gestionarea modificrilor riscurilor Administrarea contractelor

1.3.1. Date de intrare n gestionarea modificrilor

Planul proiectului constituie referenialul n raport cu toate modificrile care au fost efectuate.

Raportrile privind stadiul proiectului (descrise n paragraful 8.3.) furnizeaz informaii referitoare la performanele proiectului. Raportrile privind performanele pot, de asemenea, alerta echipa de realizare a proiectului asupra unor evenimente care vor crea probleme n viitor.

Cererea de modificare poate s apar sub form oral sau scris, direct sau indirect, de origine intern sau extern avnd aplicare contractual sau opional.

1.3.2. Instrumente i metode de gestionare a modificrilor

Sistemele de gestionare a modificrilor sunt un ansamblu de proceduri scrise tipizate, care definesc condiiile n care documentele oficiale ale proiectului pot fi modificate. Acestea includ documentele, sistemele de urmrire i nivelele de aprobare necesare autorizrii modificrilor.

n cea mai mare parte a cazurilor, organizaia nsrcinat cu realizarea proiectului are deja un sistem de control i gestionare a modificrilor, care poate fi adoptat ca aplicabil n proiect. Dac nu este disponibil nici un astfel de sistem, echipa desemnat cu managementul proiectului trebuie s elaboreze unul n cadrul proiectului.

Sistemul de control al modificrilor presupune adesea un birou de control al modificrilor nsrcinat cu aprobarea sau respingerea cererilor de modificare. Puterea i responsabilitatea acestei comisii trebuie clar definit i aprobat de principalele pri


59

implicate n derularea proiectului. n proiectele complexe, de mare anvergur, pot fi create mai multe comisii cu responsabiliti diferite.

Sistemul de gestionare i control al modificrilor trebuie s conin proceduri care s permit aprobarea aplicrii unei modificri fr un examen prealabil, de exemplu n caz de urgen. Tipic, un sistem de control al modificrilor trebuie s permit autorizarea automat a unei anumite categorii de modificri. Aceste modificri trebuie listate i documentate pentru a evita viitoare probleme.

Managementul coninutului proiectului este constituit din procedura de documentare utilizat n conducerea i urmrirea att tehnic ct i administrativ. n numeroase domenii de aplicare, managementul coninutului proiectului este un subansamblu al sistemului de conducere i control al modificrilor planului iniial.

Acest termen se utilizeaz pentru a ne asigura c descrierea rezultatului proiectului este fcut corect i complet. El conine:

- identificarea i documentarea caracteristicilor funcionale i fizice ale elementelor i sistemelor;

- controlul tuturor modificrilor acestor caracteristici; - nregistrarea i definirea modificrilor i a aplicabilitii lor; - auditul elementelor i sistemelor pentru verificarea conformitii cu

specificaiile.

Totui, n anumite domenii, termenul de management al coninutului proiectului este utilizat ca un sistem riguros de control al modificrilor.

Msurarea performanelor prin diverse tehnici de msurare precum valoarea obinut (descris n paragraful 8.3.2.) permite estimarea devierilor fa de planul iniial. Aceste abateri necesit adesea aciuni corective.

Planificarea complementar este impus de modificrile survenite care solicit noi estimri i revizuiri. Schimbrile n secvenele diverselor activiti, apariia de alternativele ca rspuns la riscuri, sau a altor ajustri ale planului proiectului impun o planificare complementar. Proiectele se deruleaz rareori fr un program.

Sistemele informatice ale managementului proiectelor au fost descrise n paragraful 1.1.2.

1.3.3. Date de ieire din procesul de gestionare a modificrilor

Reactualizarea planului proiectului conine toate modificrile aduse planului proiectului i anexelor sale (descrise n paragraful 1.1.3.). Prile implicate n proiect trebuie s fie destinatare pentru att ct este necesar.

Aciunile corective au fost descrise n paragraful 1.2.1.


60

Diseminarea experienei este necesar att pentru proiectul considerat, ct i pentru alte proiecte actuale, sau viitoare, ale organizaiei responsabil cu proiectul aflat n derulare. Cauzele de abatere n aplicarea planului, demersurile ce justific tipurile de aciuni corective adoptate precum i alte tipuri de experien dobndit trebuie consemnate. Toate acestea fac parte din baza de date istorice ale proiectului ce trebuie s fie transmise deoarece constituie experiena acumulat de echip.


61

MANAGEMENTUL CONINUTULUI PROIECTULUI

Managementul coninutului proiectului include procesele necesare pentru a

confirma c n cadrul proiectului sunt prevzute activitile necesare pentru finalizarea cu succes a acestuia. Principala caracteristic a managementului coninutului o constituie definirea i controlul a ceea ce este sau nu inclus n proiect [6]. n figura 2.1. este reprezentat o privire general asupra principalelor procese ale managementului coninutului proiectului i anume:

2.1. Iniierea proiectului 2.2. Planificarea coninutului proiectului 2.3. Definirea coninutului proiectului 2.4. Verificarea coninutului proiectului 2.5. Controlul modificrii coninutului Aceste procese, enumerate mai sus, interacioneaz ntre ele i se ntreptrund cu

procesele din alte domenii ale managementului de proiect. Fiecare proces poate implica efort din partea unui singur membru al echipei sau a mai multor indivizi, sau grupuri de indivizi, n funcie de necesitile proiectului. n general, aceste procese se regsesc cel puin o dat n fiecare etap a proiectului. Cu toate c aici, procesele sunt prezentate ca fiind elemente distincte, cu funcii i limite foarte bine definite, n realitate, se suprapun i pot interaciona n diverse moduri. Interaciunile dintre procese sunt prezentate detaliat n capitolul 3 din partea nti a lucrrii. n contextul proiectului, termenul de coninut se poate referi la:

- coninutul proiectului realizat prin activitile ce trebuie ntreprinse pentru a obine un produs cu caracteristicile i funciile specificate, n conformitate cu tema i referenialul (caietul de sarcini) elaborat n prealabil;

- coninutul rezultatului proiectului (produsul rezultat din proiect) adic caracteristicile i funciile ce caracterizeaz noul produs sau serviciu.

Procesele, instrumentele i metodele folosite variaz n funcie de sfera de aplicare i servesc la gestionarea coninutului proiectului. De obicei, ele sunt definite ca parte a ciclului de via al proiectului (ciclul de via al unui proiect este prezentat n subcapitolul 2.1 din partea nti a lucrrii). La finalizarea proiectului se verific dac activitile sunt conforme cu planul proiectului, n timp ce produsul obinut se evalueaz dac este conform cu cerinele temei sau ale referenialului final.

n general, rezultatul unui proiect este un singur produs. ntr-o abordare sistemic un produs poate include mai multe subsisteme. Fiecare subsistem, sau subansamblu, are o structur proprie care va fi integrat n produsul de ansamblu. n timp ce conformitatea coninutului proiectului este verificat n raport cu planul proiectului, conformitatea coninutului produsului rezultat din proiect este verificat n raport cu


62

specificaiile impuse prin tem. Cele dou aspecte ale managementului coninutului trebuie s fie perfect integrate, pentru a se asigura c munca prestat de ntreaga echip va conduce la realizarea produsului specificat n tema de proiect.

2. MANAGEMENTUL CONINUTULUI PROIECTULUI

1.Date de intrare

1. Descrierea produsului 2. Planificarea strategic 3. Criterii de selecie a

proiectului 4. Date istorice

2.Instrumente i metode1. Metode de selecie a

proiectului 2. Prerea experilor

3. Date de ieire 1. Statutul proiectului 2. Desemnarea manage-

rului de proiect 3. Constrngeri 4. Ipoteze

2.1. Iniierea proiectului

1.Date de intrare 1. Descrierea produsului 2. Statutul proiectului 3. Constrngeri 4. Ipoteze

2. Instrumente i metode1. Analiza lucrrii 2. Analiza cost / beneficiu 3. Identificare alternative 4. Prerea experilor

3.Date de ieire 1. Definirea coninutului 2. Detalii ajuttoare 3. Planul de gestionare a

coninutului

2.2. Planificarea coninutului

2.3. Definirea coninutului

1.Date de intrare 1. Enunarea coninutului 2. Constrngeri 3. Ipoteze 4. Alte ieiri planificate 5. Date istorice

2.Instrumente i metode1. Modele ale structurii

descompuse a proiectului (SDP)

2. Descompunerea proiectului

3 Date de ieire 1. Structura descompus

a proiectului

2.4. Verificarea coninutului 1.Date de intrare 1. Activiti realizate 2. Documentaia privind

rezultatele obinute

2.Instrumente i metode1. Inspecie

3.Date de ieire 1. Acceptarea formal

2.5. Controlul modificrilor 1.Date de intrare

1. Structura descompus a proiectului

2. Rapoarte de avansare 3. Cereri de modificare 4. Planul de gestionare a

coninutului

2.Instrumente i metode 1. Sistemul de control al

modificrii coninutului 2. Msurarea performanelor3. Planificarea suplimentar

3.Date de ieire 1. Modificri ale

coninutului 2. Aciuni corective 3. Retur de experien

Fig. 2.1 Vedere general a managementului coninutului proiectului


63

2.1. INIIEREA PROIECTULUI

Iniierea se realizeaz cu scopul de a angaja organizaia s nceap proiectul sau o faz urmtoare a proiectului, este un proces de oficializare a faptului c exist un nou proiect, sau c o nou faz a proiectului trebuie s fie lansat (pentru o prezentare detaliat a etapelor unui proiect vezi subcapitolul 2.1 din partea nti a lucrrii). Aceast iniiere formal (oficializare) leag proiectul de activitile curente ale organizaiei mputernicit cu derularea proiectului. n anumite organizaii, un proiect nu este nceput n mod oficial naintea realizrii unui studiu de prefezabilitate, sau a oricrei alte forme echivalente de analiz tehnico economic, care constituie ea nsi o activitate separat.

Fig. 2.2. Vedere privind iniierea proiectului

2.1. Iniierea proiectului

1.Date de intrare 1. Descrierea produsului 2. Planificarea strategic 3. Criterii de selecie a

proiectului 4. Date istorice

2.Instrumente i metode1. Metode de selecie a

proiectelor 2. Prerea experilor

3. Date de ieire 1. Statutul proiectului 2. Desemnarea manage-

rului de proiect 3. Constrngeri 4. Ipoteze

Anumite tipuri de proiecte, n special proiectele interne i proiectele de dezvoltare a unui nou produs, sunt iniiate neoficial. Astfel, un numr limitat de activitii, se desfoar pentru obinerea aprobrilor necesare demarrii oficiale a proiectului. Proiectele sunt, n mod normal, autorizate ca rezultat a unuia sau mai multora din urmtoarele cazuri:

Inovarea poate conduce la dezvoltarea de noi proiecte care s posteze unitatea economic ntr-o poziie viitoare de succes.

Cererea pieei solicit un nou produs. De exemplu, o ntreprindere constructoare de automobile autorizeaz un proiect pentru realizarea unei noi variante de autoturism de mic litraj, sau hibrid avnd i acionare electric, pentru a rspunde cerinelor de reducere a polurii i n consecin, de protecie a mediului n condiiile prognozelor care estimeaz o majorare semnificativ a carburanilor la nivel mondial.

Unitatea economic dorete s-i diversifice activitatea i astfel s-i extind cifra de afaceri. De exemplu, o companie productoare de instrumentar medical autorizeaz derularea unui proiect de reconversie a personalului i restructurare a produciei pentru a-i crearea un nou domeniu de activitate (echipamente pentru fabricarea produselor cosmetice) care s-i sporeasc veniturile.

O solicitare a consumatorului poate conduce la dezvoltarea unui nou produs. De exemplu o societate de distribuie a energiei electrice autorizeaz un proiect


64

pentru realizarea unei noi staii de transformare care s deserveasc un parc industrial nou.

Progresul tehnologic poate autoriza dezvoltarea unui proiect. Astfel o firm productoare de telefoane mobile autorizeaz un nou proiect pentru dezvoltarea unui telefon care s aib ncorporat un aparat video ca urmare a performanelor tehnologice nregistrate n domeniul aparaturii video.

Proiectele pot fi demarate ca o cerin administrativ de constrngere. De exemplu, un productor de lacuri i vopsele autorizeaz un proiect nou, impus de condiiile de mediu, pentru neutralizarea substanelor toxice rezultate din procesul tehnologic.

Nevoia social poate autoriza o organizaie nonguvernamental, s dezvolte un proiect regional pentru furnizarea de oportuniti privind crearea de noi locuri de munc ntr-o anumit zon defavorizat.

Aceti stimuli pot fi numii, de asemenea, probleme, oportuniti sau cereri de afaceri. Tema fundamental a tuturor acestor termeni este c, n majoritatea cazurilor, conducerea organizaiei este aceea care trebuie s ia o decizie pentru a face fa att factorilor interni ct i externi.

2.1.1. Date de intrare pentru demararea proiectului

Descrierea produsului este prezentat n documentaia tehnic pentru care proiectul a fost conceput. Descrierea produsului, n cele mai multe cazuri, are o dezvoltare progresiv. n fazele iniiale sunt prezentate mai puine detalii ale produsului. n fazele urmtoare, pe msur ce caracteristicile produsului sunt elaborate, apar mai multe detalii ale acestuia. Descrierea produsului trebuie s sprijine prin documentaia ntocmit raportul dintre produsul sau serviciul care va fi creat i necesitile sau ali stimuli care conduc la iniierea proiectului. Chiar dac forma i coninutul descrierii produsului rezultat din proiect pot s varieze ca extindere, totui, trebuie s fie ndeajuns de detaliat prezentate pentru a permite planificarea ulterioar a proiectului.

Multe proiecte se realizeaz pe baz de contracte ncheiate cu teri. n aceste mprejurri, sunt implicate dou organizaii: una prestatoare (vnztorul) care semneaz cu alt organizaie beneficiar (cumprtorul) contractul. Aici descrierea iniial a produsului este, de obicei, furnizat de cumprtor i prezentat n tema de proiect.

Planificarea strategic a organizaiei trebuie s fie gndit ca un factor de decizie n selecia diverselor proiecte. Orice proiect trebuie s fie coerent, s concorde cu obiectivele strategice ale organizaiei care se angajeaz s l execute. Pentru aceasta se ntocmete un plan strategic de dezvoltare la nivelul organizaiei.

Criteriile de selecie a proiectului sunt definite, n mod specific, n termenii rezultatului proiectului i pot acoperi ntreaga sfer de interese manageriale posibile, cum sunt: analiza i evaluarea costurilor, a profitului financiar, a cotei de pia,


65

claritatea prezentrii i relevana obiectivelor proiectului, impactul economic, social, i asupra mediului, notorietatea membrilor echipei, condiii de parteneriat etc..

Datele istorice cuprind totalitatea informaiilor cu privire att la rezultatele deciziilor precedente de selecie a proiectelor, ct i la performanele obinute n alte proiecte derulate anterior. Toate aceste date arhivate, rezultate n urma experienei acumulate, trebuie luate n considerare n msura n care acestea sunt disponibile ntr-o baz de date. De remarcat c dac demararea se refer la o faz ulterioar a unui proiect, informaiile referitoare la rezultatele etapelor anterioare sunt adesea, decisive.

2.1.2. Instrumente i metode de demarare a proiectului

Metodele de selecie a proiectelor, se regsesc n general, ntr-una din cele dou categorii generale:

- metode de evaluare a profitului cu abordri comparative, prin modele de cuantificare, prin contribuia la beneficiu, sau alte modele economice;

- metode de optimizare a constrngerilor aplicate cu ajutorul modelelor matematice folosind algoritmi de programare liniar, neliniar, algoritmi dinamici, integrali i multicriteriali.

Toate aceste metode, n mod frecvent, se numesc modelele decizionale. Modelele decizionale includ att tehnici generalizate ca: arborele decizional, decizia forat etc. ct i tehnici specializate ca: procedee de analiz ierarhic, analiza cadrului logic i altele. Utilizarea criteriilor complexe de selecie a proiectelor prin modele sofisticate este adesea considerat ca o etap distinct, separat, a proiectului.

Prerea experilor va fi solicitat n majoritatea cazurilor, pentru a evalua intrrile n procesul de iniiere a proiectului. O astfel de expertiz poate fi asigurat de ctre o persoan sau grup de persoane ce dein cunotine de specialitate n domeniu, sau au pregtirea necesar i dispun de mai multe surse de informare incluznd:

- specialiti experi tehnico-tiinifici i economico-financiari; - acionari din cadrul organizaiei; - clieni, viitori beneficiari ai proiectului; - alte uniti din domeniul organizaiei n cauz, grupuri industriale; - asociaii profesionale i tehnice, organizaii nonguvernamentale.

2.1.3. Date de ieire din procesul de demarare

Statutul proiectului este un document oficial ce autorizeaz existena proiectului reglementnd structura i modul de lucru n cadrul acestuia. Statutul proiectului trebuie s fie emis de ctre conductorul unitii sau un director din afara proiectului i s fie elaborat la un nivel apropiat de cerinele temei. n acest fel, statut asigur managerului de proiect autoritate suficient pentru a folosi resursele organizaiei n activitile


66

desfurate n cadrul proiectului. Statutul trebuie s includ fie n mod direct, fie n mod indirect, referiri la urmtoarele documente:

- necesitatea pentru care proiectul a fost gndit; - descrierea produsului obinut n cadrul proiectului (vezi paragraful 2.1.1.).

Cnd un proiect este elaborat pe baz de contract, contractul semnat de ambele pri implicate i anexele la contract vor servi, n general, ca statut al proiectului.

Desemnarea managerului de proiect este ntotdeauna o activitate prioritar demarrii planului de execuie a proiectului (aa cum este descris n subcapitolul 1.2.) i, de preferat, cu mult nainte de ntocmirea planului de realizare a proiectului (procesele de planificare a proiectului sunt descrise n subcapitolul 3.3. din partea nti). De obicei, managerul de proiect va trebui identificat i numit n funcie ct mai repede, urmrindu-se astfel ca proiectul s rmn n continuare, fezabil. Aciunea de identificare i numire a managerului se face innd seama de calitile pe care trebuie s le ndeplineasc liderul echipei. Numirea n funcie a managerului de proiect are n vedere criteriile de baz ale principiilor managementului calitii cu scopul de a conduce echipa de lucru spre atingerea performanelor de calitate (vezi capitolul 6) [7].

Constrngerile sunt factori care vor limita opiunile echipei de lucru n proiect. De exemplu, un buget prestabilit constituie o constrngere deoarece limiteaz n mare msur opiunile echipei referitoare la coninutul proiectului, la numrul de persoane implicate i la termene. Atunci cnd un proiect funcioneaz pe baz de contract, prevederile contractuale sunt considerate, n cele mai multe cazuri, constrngeri.

Ipotezele reprezint un ansamblu de elemente care sunt presupuse ca fiind adevrate, reale, sau asiguratorii n proiect. De exemplu, dac o persoan cheie nu este disponibil la o anumit dat, sau data la care aceasta poate lucra efectiv la proiect este incert, se va stabili ipotetic o dat de demarare a activitii acesteia. Ipotezele implic un anumit risc, de aceea trebuie identificate, aici n acest proces, sau pot constitui date de ieire din procesul de identificare a riscului (vezi subcapitolul 7.1.).

2.2. PLANIFICAREA CONINUTULUI PROIECTULUI

n procesul de planificare a coninutului, se redacteaz un document scris privind

coninutul i scopul proiectului, se elaboreaz scheme, care vor servi drept referin i punct de plecare pentru viitoarele decizii ce se vor lua n cadrul proiectului. Acest document conine mai ales criteriile utilizate n etapa de monitorizare pentru a decide dac proiectul, sau etapa proiectului a fost ndeplinit n totalitate. El este elaborat att pentru proiecte ct i pentru subproiecte fiind necesar n procesele de desfurare a activitilor. De exemplu, o firm prestatoare de servicii care a semnat un contract pentru studiul tehnico-economic al unui echipament de compactat rumegu trebuie s stabileasc coninutul acestui subproiect definind limitele muncii sale n cadrul


67

studiului. Acest document constituie baza acordului ntre conducerea echipei de lucru i client, prin care se identific totodat obiectivele proiectului i livrabile principalele.

Fig. 2.3. Planificarea coninutului proiectului

2.2. Planificarea coninutului

1.Date de intrare 1. Descrierea produsului 2. Statutul proiectului 3. Constrngeri 4. Ipoteze

2. Instrumente i metode1. Analiza lucrrii 2. Analiza cost / beneficiu 3. Identificare alternative 4. Prerea experilor

3.Date de ieire 1. Definirea coninutului 2. Detalii ajuttoare 3. Planul de gestionare a

coninutului

Dac toate elementele privind coninutul proiectului sunt deja disponibile,

procesul de planificare a coninutului se rezum la oficializarea fizic a lui ntr-un document scris. De exemplu, printr-o cerere de ofert pot fi definite principalele livrabile, iar prin coninutul proiectului se definesc obiectivele.

2.2.1. Date de intrare ale planificrii coninutului

Descrierea produsului este fcut n cadrul documentaiei tehnice (vezi paragraful 2.1.1.).

Statutul proiectului reprezint documentul prin care proiectul este oficializat (este prezentat n paragraful 2.1.3.).

Constrngerile sunt factori importani n etapa de definire a coninutului prevzui i inclui, de cele mai multe ori, n clauzele contractuale mai ales atunci cnd un proiect funcioneaz pe baza unui contract (a se vedea paragraful 2.1.3.).

Ipotezele reprezint presupuneri enunate pe baza experienei acumulate, la nivelul organizaiei, din derularea altor proiecte (a se vedea paragraful 1.1.1.).

2.2.2. Instrumente i metode de planificare a coninutului proiectului

Analiza lucrrii trebuie realizat de ctre membrii echipei n cadrul proiectului. Analiza implic dezvoltarea unei cunoateri i concepii ct mai bune a produsului ce urmeaz a se realiza n cadrul proiectului. Aceasta include tehnici precum analiza morfologic a sistemului, analiza valorii, analiza funcional etc..

Analiza cost / beneficiu implic estimarea cheltuielilor (costurilor) directe i indirecte i a beneficiilor (ncasri) pentru diferite variante posibile de elaborare a proiectului i n consecin utilizarea de tehnici financiare, precum retururi din investiii sau termene de rambursare, pentru a evalua oportunitatea alternativelor identificate [3].

Identificarea alternativelor (variantelor) rezult n urma unor edine de analiz folosind diverse tehnici prin care s poat fi generate diferite abordri ale


68

proiectului. Exist o multitudine de tehnici manageriale generale folosite n aceste cazuri. Dintre cele mai des ntlnite se pot enumera gndirea colectiv i colateral.

Prerea experilor a fost prezentat n paragraful 2.1.2.

2.2.3. Date de ieire din procesul de planificare a coninutului

Definirea coninutului furnizeaz o baz de referin scris pentru luarea deciziilor viitoare i pentru confirmarea sau nelegerea coninutului proiectului ntre prile implicate. Odat cu avansarea proiectului, enunarea coninutului poate s necesite revizuiri sau precizri n funcie de modificrile care au intervenit. Aceast enunare a coninutului trebuie s includ, fie n mod direct, fie n mod indirect, referiri la urmtoarele aspecte:

Justificarea proiectului prin care se argumenteaz satisfacerea cerinelor pentru care proiectul a fost elaborat. Justificarea proiectului furnizeaz baza de evaluare a negocierilor viitoare.

Produsul ce va rezulta din proiect va fi caracterizat de o descriere concis a lui (manualul de prezentare, sau cartea tehnic a produsului). Unele aspecte privind descrierea produsului sunt prezentate n paragraful 2.1.1.

Livrabilele proiectului sunt constituite dintr-o list n care sunt prezentate subansamblurile produsului a cror grad de realizare i livrare complet marcheaz finalizarea proiectului. De exemplu, principalele livrabile ale unui soft elaborat ntr-un proiect informatic pot include codul de lucru al computerului, un manual de folosire i un ghid interactiv.

Obiectivele proiectului se obin dintr-o nsumare a criteriilor cantitative ce trebuie ndeplinite pentru a considera proiectul un succes. Obiectivele proiectului sunt elemente critice de reuit ale acestuia i includ, cel puin, costul, termenul de livrare i cerinele de calitate (figura 2.3 din partea I) ale produsului nou rezultat din proiect. Un obiectiv al proiectului trebuie s aib o mrime (exemplu: costul), o unitate de msur (exemplu:euro), i o valoare absolut sau relativ (exemplu: mai puin de 1,5 milioane). Criteriile privind calitatea, cum ar fi de exemplu, satisfacia clientului determin cele mai mari riscuri.

Detaliile ajuttoare completeaz coninutul proiectului. Enunul coninutului trebuie completat cu toate detaliile, documentele i structurile, pentru a facilita utilizarea lor n alte procese ale managementului de proiect. Detaliile ajuttoare trebuie s includ, ntotdeauna, documentaia cu privire la toate ipotezele i constrngerile identificate. Volumul detaliilor ajuttoare, care devin adiionale la coninutul proiectului, pot varia n funcie de domeniul de aplicare.

Planul de gestionare a coninutului descrie printr-un document, felul n care coninutul proiectului va fi gestionat i felul n care modificrile vor fi identificate, clasificate i integrate n cadrul proiectului. Acest lucru implic ipoteze asupra


69

stabilitii coninutului proiectului, ca de exemplu: probabilitatea de modificare a coninutului, frecvena modificrilor i mrimea acestora. De aceea aceast parte este absolut esenial, deosebit de dificil mai ales atunci cnd caracteristicile produsului nu sunt nc definitivate. Planul de gestionare a coninutului poate avea caracter oficial sau neoficial, poate fi amnunit sau doar schiat, n funcie de amploarea proiectului. El este o component subsidiar a planului proiectului prezentat n paragraful 1.1.3.

2.3. DEFINIREA CONINUTULUI PROIECTULUI

Deosebit de important pentru succesul proiectului, l constituie modul de definire

exact i suficient de detaliat a coninutului acestuia. n cazul unei definiri sumare i a unei elaborri superficiale a coninutului, este de ateptat obinerea unor costuri finale ale proiectului mult mai ridicate. Modificrile inevitabile, care apar pe parcursul derulrii proiectului, vor ntrerupe ritmul de lucru la proiect. Renceperea activitilor de la un nivel inferior, va conduce la creterea perioadei de timp destinat finalizrii proiectului, la scderea productivitii i a moralului membrilor echipei de lucru. Definirea coninutului implic descompunerea principalelor livrabile ale proiectului n elemente de dimensiuni mai mici, mult mai uor de gestionat. Toate acestea se realizeaz n scopul:

- mbuntirii i acurateei estimrilor privind resursele financiare, materiale, umane, a duratei diverselor activiti, precum i a termenelor;

- stabilirii liniei de baz pentru a msura i conduce performanele; - facilitrii unor responsabiliti precise privind sarcinile.

Fig.2.4. Definirea coninutului proiectului

2.3. Definirea coninutului

1.Date de intrare 1. Enunarea coninutului 2. Constrngeri 3. Ipoteze 4. Alte ieiri planificate 5. Date istorice

2.Instrumente i metode1. Modele ale structurii

descompuse a proiectului (SDP)

2. Descompunerea proiectului

3 Date de ieire 1. Structura descompus

a proiectului

2.3.1. Date de intrare pentru definirea coninutului

Enunarea coninutului a fost prezentat n paragraful 2.2.3.

Constrngerile sunt prezentate n paragraful 2.1.3.

Ipotezele au fost prezentate n paragraful 1.1.1.


70

Datele de ieire din procesul de planificare trebuie s fie luate n considerare n special pentru impactul acestora asupra definirii coninutului.

Datele istorice prin informaiile referitoare la proiectele anterioare, contribuie n mare msur la definirea ct mai complet a coninutului. Informaiile cu privire la eventualele erori fcute sau lipsuri ale proiectelor anterioare vor constitui un ajutor substanial la definirea coninutului noului proiect.

2.3.2. Instrumente i metode folosite pentru definirea coninutului

Modele de structuri descompuse ale proiectelor pot proveni din proiecte anterioare. Modele ale proiectelor deja ncheiate pot fi, deseori, folosite ca exemple pentru elaborarea unui proiect nou. Cu toate c fiecare proiect este unic n felul su, structura descompus a proiectului (SDP) poate, de multe ori, s fie refolosit deoarece majoritatea proiectelor, ntr-o anumit msur, seamn ntre ele mai ales prin activiti. De exemplu, multe proiecte realizate de o anumit societate pot avea cicluri de via identice sau asemntoare i astfel, pot avea i livrabile identice sau similare la sfritul fiecrei etape. Structura descompus a proiectului va fi prezentat, n continuare, n paragraful 2.3.3. n multe domenii de aplicative s-au stabilit structuri descompuse standard, sau normalizate la nivelul firmei, care pot fi reutilizate ca modele.

Descompunerea proiectului implic subdivizarea livrabilelor principale ale proiectului sau a unor componente ale acestuia, n unele de mai mici dimensiuni, mult mai uor de gestionat, astfel nct livrabilele s fie suficient de detaliat definite pentru a sprijinii dezvoltarea activitilor de planificare, controlul i finalizarea proiectului. Descompunerea include parcurgerea urmtoarelor patru etape principale:

Identificarea elementelor principale ale proiectului n general, elementele principale sunt livrabilele i managementul proiectului. n acelai timp elementele principale trebuie definite ntotdeauna n termenii managementului practic specific particularitilor proiectului aflat n derulare.

Decizia de detaliere a estimrilor costurilor i a termenelor fiecrei etape la nivelul dorit Termenele scadente se pot modifica pe parcursul derulrii proiectului. ntre planificare i realizare pot s apar unele decalaje care de cele mai multe ori sunt inevitabile. De aceea dac unele livrabile au fost furnizate cu ntrziere n cadrul unei etape anterioare descompunerea lor ntr-o etap precedent nu este posibil. nseamn c elemente diferite pot avea grade diferite de descompunere.

Identificarea elementelor constitutive ale livrabilelor Aceste elemente constitutive trebuie s fie descrise n termeni cu rezultate evidente i verificabile, pentru a facilita msurarea performanelor. Ca i pentru livrabilele principale, elementele constitutive ar putea fi definite n termenii executrii practice a proiectului. n mod cert, aceste rezultate, ce pot fi verificate cu uurin, pot include la fel de bine, att servicii, ct i produse. De exemplu, raportul de avansare poate fi


71

prezentat ca raport sptmnal al avansrii. Pentru un produs aflat n fabricaie elementele constitutive ar putea fi diversele componente specifice ale produsului, inclusiv asamblarea final.

Verificarea corectitudinii descompunerii urmrete: - dac elementele descompuse la nivelul inferior sunt necesare i suficiente

pentru a reconstitui ansamblul; - definirea clar i complet a elementelor constitutive, descompuse, la nivelul

proiectului; - dac exist o estimare corespunztoare ca termen de livrare i cost pentru

fiecare element component; - dac fiecare element al proiectului este atribuit unei structuri organizatorice

precise, unui serviciu, unei echipe, sau persoane care s accepte responsabilitatea de a duce la bun sfrit realizarea acelui element.

Dac nu sunt ndeplinite n totalitate condiiile de mai sus este necesar o revizuire privind descompunerea coninutului proiectului. Descompunerea structurii proiectului trebuie revzut i dezvoltat pentru a permite un controlul corespunztor de gestionare a proiectului.

2.3.3. Date de ieire din definirea coninutului

Structura descompus a proiectului (SDP) este o regrupare de livrabile ale proiectului prin care se organizeaz i se definete ntreg coninutul proiectului. O activitate care nu face parte din SDP este n afara coninutului proiectului. Ca i partea scris a coninutului, SDP este adesea utilizat pentru ca membrii echipei s neleag ct mai bine coninutul proiectului. Fiecrui nivel i corespunde o descriere ct mai detaliat a elementelor proiectului. n paragraful 2.3.2. este descris maniera clasic de realizare a SDP care este n general prezentat sub forma unei scheme. Modul de prezentare a unei liste de activiti structurat sub form de tabel nu constituie un SDP. n general, fiecare element al SDP este repartizat unui anumit reper. Aceast repartizare este adesea numit codul posturilor purttoare de costuri. Elementele din SDP, care figureaz la un nivel inferior, sunt numite locuri de lucru. Aceste locuri de lucru pot fi descompuse ulterior aa cum sunt descrise n subcapitolul 2.1. Descrierile activitilor elementare sunt adunate ntr-un registru de activiti care conine lista tuturor locurilor de lucru cu descrierea lor, alocarea lor cu personalul aferent, data prevzut i bugetul costurilor. Alte descompuneri utilizate n cteva domenii de aplicare sunt prezentate n cele ce urmeaz.

Descompunerea contractual (DC) care este utilizat pentru a defini nivelul de urmat i a se face neles c vnztorul este cel care furnizeaz cumprtorului. DC include n general, mai puine detalii dect SDP fiind utilizat de vnztor pentru a-i gestiona proiectul.


72

Organigrama funcional (OF) se folosete pentru a arata responsabilitile serviciilor funcionale asupra diverselor locuri de lucru.

Organigrama resurselor (OR) este structurat asemntor OF i se utilizeaz mai ales atunci cnd se repartizeaz personalul pe locurile de munc.

Lista componentelor (LC) sau arborescena tehnic a produsului prezint o descompunere ierarhic a ansamblurilor, a subansamblurilor i elementelor fizice componente necesare fabricrii produsului.

Organigrama proiectului (OP) este echivalent cu structura descompus a proiectului.

2.4. VERIFICAREA CONINUTULUI PROIECTULUI

Verificarea coninutul proiectului este un proces prin care prile implicate

(clieni, cumprtori, sponsori etc.) i dau acceptul oficial cu privire la activitile i procesele finalizate, precum i pentru cele viitoare propuse n proiect pentru a finaliza cu succes toate etapele. Dac proiectul a fost finalizat nainte de termen, procesul de verificare a coninutului trebuie s stabileasc i s aduc o documentaie suplimentar situaiei existente i gradului de finalizare. n timp ce controlul calitii se refer la corectitudinea rezultatelor activitilor, verificarea coninutului are ca principal preocupare acceptul rezultatelor activitilor desfurate pn la momentul verificrii. Aceste procese se deruleaz n paralel.

Fig. 2.5. Verificarea coninutului proiectului

2.4. Verificarea coninutului 1.Date de intrare

1. Activiti realizate 2. Documentaia privind

rezultatele obinute

2.Instrumente i metode1. Inspecie

3.Date de ieire 1. Acceptarea formal

2.4.1. Date de intrare ale verificrii coninutului

Activitile realizate se constituie din livrabilele care au fost total, sau parial realizate, costurile care au fost angajate, sau sunt n curs de angajare etc. Acestea se regsesc n datele de ieire ale aplicrii planului proiectului (tratat n subcapitolul 1.2.).

Documentaia privind rezultatele obinute se ntocmete pentru prezentarea produselor la care se refer proiectul. Aceast documentaie este absolut necesar i trebuie s fie disponibil n vederea revizuirilor ulterioare. Materialele coninute n documentaie planuri, specificaii, studii tehnico economice, schie, scheme tehnice, desene, buletine de analiz i ncercri etc. pot s difere n funcie de domeniul i sfera de aplicabilitate.


73

2.4.2. Instrumente i metode pentru verificarea coninutului

Inspecia include activiti cum sunt: msurarea, examinarea, sau testarea prin ncercri pentru a determina dac rezultatele sunt conforme cu cerinele. Inspeciile pot avea diverse denumiri ca de exemplu: revizii ale proiectului, revizii ale produsului, monitorizare, audit sau sondaje. n anumite domenii de aplicabilitate, termenii amintii mai sus au un neles specific, sau mai limitat.

2.4.3. Date de ieire din verificarea coninutului

Acceptarea formal reprezint documentul prin care clientul, sau sponsorul persoana juridic sau fizic dornic s achiziioneze produsul rezultat din proiect i d acceptul asupra lui. Ca rezultat al derulrii proiectului, sunt deja stabilite principalele inte ce trebuie atinse. O astfel de acceptare poate fi emis cu rezerve, n special, la sfritul unei etape intermediare.

2.5. CONTROLUL MODIFICRILOR CONINTULUI PROIECTULUI

n contextul condiiilor ntotdeauna schimbtoare, este dificil de realizat o

planificare exact a coninutului. De aceea condiiile n care se rezolv diversele probleme de management al coninutului sunt n majoritatea cazurilor diferite [2]. Controlul modificrilor coninutului urmrete gestionarea modificrilor coninutul proiectului precum i controlul acestor modificri i trebuie integrat perfect n celelalte procese de control, cum sunt: controlul termenelor de realizare a activitilor, al costurilor, al calitii etc.. Controlul modificrilor privind coninutul proiectului presupune:

- determinarea modificrilor care au intervenit; - acionarea asupra factorilor i cauzelor modificrilor, pentru a ne asigura c

modificrile ntreprinse sunt benefice; - gestionarea tuturor modificrilor care au aprut legate de coninutul

proiectului.

Fig. 2.6. Controlul i gestionarea modificrilor proiectului

2.5. Controlul modificrilor

1.Date de intrare 1. Structura descompus

a proiectului 2. Rapoarte de avansare 3. Cereri de modificare 4. Planul de gestionare a

coninutului

2.Instrumente i metode1. Sistemul de control al

modificrii coninutului 2. Msurarea performanelor3. Planificarea suplimentar

3.Date de ieire 1. Modificri ale

coninutului 2. Aciuni corective 3. Returul experienei


74

2.5.1. Date de intrare n procesul de control al modificrilor coninutului

Structura descompus a proiectului a fost descris n paragraful 2.3.3. Ea constituie documentul de referin al coninutului proiectului.

Rapoartele de avansare, prezentate n paragraful 8.3.3., furnizeaz informaii cu privire la starea proiectului. De exemplu, n cadrul unei faze intermediare rapoartele de avansare arat stadiul proiectului: rezultate obinute i ce obiective nu au fost atinse. Ele pot, de asemenea, s atrag atenia colectivului de lucru, asupra evenimentelor ce pot s creeze probleme n viitor.

Cererile de modificare pot solicita extensia coninutului sau micorarea lui. n general, ele se exprim n form oral sau scris, n mod direct sau indirect, pot fi iniiate din exterior sau din interior, sunt obligatorii sau opionale. Majoritatea modificrilor care intervin n derularea proiectului sunt rezultatul:

- evenimentelor externe (exemplu: modificarea legislaiei, a politicilor statale); - erori sau omisiuni n definirea coninutului produsului (de exemplu, omiterea

unei condiii absolut necesare n studiul unui sistem tehnic); - erori sau omisiuni n definirea coninutului proiectului (de exemplu,

utilizarea unei liste de componen n locul SDP); - ameliorri (de exemplu, prin utilizarea de tehnologii care nu erau disponibile

la momentul definirii iniiale a coninutului proiectului).

Planul de gestionare al coninutului a fost prezentat n paragraful 2.2.3.

2.5.2. Instrumente i metode de control al modificrilor coninutului

Sistemul de control al modificrilor stabilete modalitile prin care coninutul proiectului poate fi modificat. Acesta include partea redactat, sistemele de urmrire i nivelele de aprobare necesare pentru autorizarea modificrilor. Sistemul de control al modificrilor trebuie integrat n sistemul general de gestiune al modificrilor, descris n subcapitolul 1.3. i n mod deosebit oricrui sistem destinat s controleze coninutul produsului. Cnd proiectul se deruleaz pe baza unui contract, sistemul de control al modificrilor este necesar s fie compatibil cu toate prevederile contractuale enunate.

Msurarea performanelor ajut la evaluarea importanei oricror abateri ce ar putea apare n derularea proiectului. Un punct important al controlului modificrilor este de a determina care este cauza abaterii i de a decide dac sunt necesare aciuni corective. Tehnicile de msurare a performanelor sunt prezentate n paragraful 8.3.2.

Planificarea suplimentar este necesar deoarece un numr foarte mic de proiecte se desfoar conform planului stabilit iniial. Modificrile care intervin ulterior, n ceea ce privete coninutul proiectului necesit, de cele mai multe ori, modificri ale SDP, sau analiza unor variante alternative pentru activitile ce urmeaz a se desfura n cadrul proiectului.


75

2.5.3. Date de ieire din procesul de control al modificrilor coninutului

Modificrile coninutului proiectului cuprind totalitatea schimbrilor ce intervin n coninutul proiectului aa cum este definit n SDP. O modificare a coninutului antreneaz adesea reajustri asupra termenelor de livrare, a resurselor materiale, umane i financiare, a calitii, sau asupra altor obiective ale etapelor prevzute n planul proiectului. Modificrile coninutului sunt reintroduse n procesele de planificare, n documentaia tehnico economic i n calendarul activitilor. Ca urmare a modificrilor ntreprinse, este obligatorie reactualizarea documentelor privind coninutul proiectului. n continuare, se face o informare a tuturor prilor implicate, cu ceea ce este necesar s fie cunoscut, astfel nct acestea s poat lua msurile necesare.

Aciunile corective reprezint totalitatea operaiilor efectuate pentru a atinge performanele ateptate ale proiectului n conformitate cu planul de management al acestuia.

Returul experienei acumulate n proiect, urmrete diseminarea experienei i a cunotinelor obinute din procesele i activitile parcurse n derularea proiectului. Cauzele abaterilor, motivele alegerii aciunilor corective i toate celelalte nvminte ce au fost trase din controlul modificrilor, trebuie fcute n scris. Aceste informaii, de aici nainte, vor face parte din datele istorice, att pentru proiectul n cauz ct i pentru alte proiecte conduse de organizaia prestatoare.


76

3. MANAGEMENTUL TIMPULUI NECESAR PROIECTULUI

Managementul timpului necesar realizrii proiectului, a termenelor scadente de

ncepere i de ncheiere a activitilor, cuprinde procesele absolut necesare pentru a finaliza proiectul, n bune condiii, la termenul stabilit prin tem. Principalele procese specifice managementului timpului de realizare a proiectului sunt prezentate n cele ce urmeaz:

3.1. Identificarea activitilor 3.2. Secvenierea activitilor 3.3. Estimarea duratei activitilor 3.4. Elaborarea scadenarului activitilor 3.5. Controlul scadenarului activitilor Aceste procese interacioneaz ntre ele, precum i cu procesele din alte discipline

ale managementului de proiect. Fiecare proces intervine cel puin odat n fiecare din fazele i etapele proiectului. Dei procesele sunt prezentate separat n majoritatea cazurilor, cu interfee precise, n practic pot s se suprapun i s interacioneze ntre ele ntr-o manier diferit fa de cea prezentat n acest capitol. Interaciunile dintre procesele managementului de proiect au fost analizate n capitolul 3 din partea nti a lucrrii.

n funcie de necesitile proiectului, la fiecare din aceste procese pot participa una sau mai multe persoane ori ntreg efectiv al echipei. n anumite proiecte n special n proiectele mici secvenierea activitilor, estimarea duratei activitilor i ordonarea lor sunt astfel corelate nct se consider ca un singur proces care poate fi realizat de un singur individ ntr-un timp relativ scurt. Ele sunt prezentate aici de maniera distinct, deoarece nu opereaz prin aceleai instrumente i metode.

n prezent, nu exist un consens general acceptat n managementul proiectelor prin care s se fac distincie ntre activiti i sarcini. n multe domenii de aplicare, se consider c activitile sunt compuse din sarcini (vezi figura 1.1 din partea nti a lucrrii). Aceast abordare corespunde folosirii obinuite i este cea mai rspndit. n altele, sarcinile sunt concepute ca un ansamblu de activiti. Totui, punctul important nu este terminologia utilizat, ci descrierea precis a muncii ce urmeaz a fi efectuat de ctre fiecare membru al echipei de lucru.

n figura 3.1. este prezentat o vedere de ansamblu a tuturor proceselor specifice managementului timpului de realizare a proiectului pornind cu identificarea activitilor i ncheind cu controlul termenelor de ndeplinire a obiectivelor fiecrei activiti.


77

3. MANAGEMENTUL TIMPULUI NECESAR PROIECTULUI

1.Date de intrare 1. Structura descompus

a proiectului (SDP) 2. Descrierea coninutului 3. Date istorice 4. Constrngeri 5. Ipoteze

2.Instrumente i metode1. Descompunerea

proiectului 2. Modele

3. Date de ieire 1. Lista activitilor 2. Detalii ajuttoare 3. Reactualizarea

repartiiei sarcinilor

3.1. Identificarea activitilor

1.Date de intrare 1. Lista activitilor 2. Descrierea produsului 3. Legturi logice 4. Constrngeri 5. Ipoteze

2. Instrumente i metode1. Metoda antecedentelor 2. Metoda diagramei sgeat3. Metoda de reprezentare

condiionat 4. Reele tip

3.Date de ieire 1. Graficul proiectului 2. Reactualizarea listei

activitilor

3.2. Secvenierea activitilor

3.3. Estimarea duratei activitilor

1.Date de intrare 1. Lista activitilor 2. Constrngeri 3. Ipoteze 4. Necesarul de resurse 5. Capacitatea resurselor 6. Istoric

2.Instrumente i metode1. Metodele privind

prerea experilor 2. Estimri prin analogie 3. Simulri

3 Date de ieire 1. Estimarea duratei

activitilor 2. Bazele estimrii 3. Reactualizarea listei

activitilor

3.4. Elaborarea scadenarului activitilor 1.Date de intrare 1. Graful proiectului 2. Estimarea duratei

activitilor 3. Necesarul de resurse 4. Descrierea resurselor 5. Calendar 6. Constrngeri 7. Ipoteze 8. Anticipri i ntrzieri

2.Instrumente i metode1. Analiza matematic 2. Reducere a duratei 3. Simulare 4. Metodologii de nivelare

a resurselor 5. Programe de gestionare

3.Date de ieire 1. Planningul proiectului2. Detalii ajuttoare 3. Planul de gestionare a

planningului 4. Reactualizarea

histogramei sarcinilor

3.5. Controlul scadenarului activitilor

1.Date de intrare 1. Planningul proiectului 2. Rapoarte de avansare; 3. Cereri de modificare; 4. Planul de gestionare a

planningului

2.Instrumente i metode 1. Sistemul de control al

modificrii planningului2. Msurarea performanelor3. Planificarea suplimentar4. Programe de gestionare

3.Date de ieire 1. Planningul actualizat 2. Aciuni corective 3. Retur de experien

Fig. 3.1. Vedere de ansamblu a managementului timpului necesar proiectului


78

3.1. IDENTIFICAREA ACTIVITILOR

Identificarea activitilor urmrete enunarea, stabilirea i descrierea activitilor

specifice care trebuie realizate pentru elaborarea documentelor livrabile i a celorlalte elemente identificate n structura descompus a proiectului. Acest proces antreneaz implicit definirea activitilor astfel nct s fie atinse obiectivele proiectului.

3.1. Identificarea activitilor

1. Date de intrare 1. Structura descompus

a proiectului (SDP) 2. Descrierea coninutului 3. Date istorice 4. Constrngeri 5. Ipoteze

2. Instrumente i metode1. Descompunerea

proiectului 2. Modele

3. Date de ieire 1. Lista activitilor 2. Detalii ajuttoare 3. Reactualizarea

repartiiei sarcinilor

Fig. 3.2. Identificarea activitilor proiectului

3.1.1 Date de intrare n procesul de identificare a activitilor

Structura descompus a proiectului SDP se consider a fi principala dat de intrare a procesului de identificare a activitilor (informaii ample asupra SDP sunt prezentate n paragraful 2.3.3.).

Descrierea coninutului urmrete justificarea elaborrii proiectului i stabilirea obiectivelor sale. Coninutul trebuie ntotdeauna s serveasc ca referin explicit la identificarea activitilor (explicaii ale coninutului sunt date n paragraful 2.2.3.).

Datele istorice servesc pentru a putea definii mai uor activitile proiectului folosind experiena acumulat n derularea altor proiecte. Astfel se face referin la datele istorice pentru a tii ce activiti au fost absolut necesare n proiecte similare, derulate anterior.

Constrngerile sunt factori restrictivi. Constrngerile limiteaz libertatea de alegere din mulimea de variante posibile de ctre membrii echipei manageriale a proiectului.

Ipotezele reprezint un ansamblu de elemente care, din necesiti de planificare, trebuie considerate ca fiind adevrate, reale sau asiguratorii. Ipotezele sunt enunate pe baza unor fapte i legi cunoscute sau presupuneri cu caracter provizoriu. Ele pot fi formulate pe baza rezultatelor experimentale existente sau a intuiiei. Deoarece ipotezele urmeaz s fie confirmate ulterior ele implic, n general, un anumit risc i devin astfel date de intrare n procesul de identificare a riscului (subcapitolul 7.1.).


79

3.1.2. Instrumente i metode pentru identificarea activitilor

Descompunerea proiectului const n subdivizarea elementelor proiectului n elemente mai mici i mai uor de gestionat, pentru a obine o mai bun stpnire a managementului. Decuparea este descris n detaliu n paragraful 2.3.2. Diferena principal ntre descompunerea proiectului tratat aici i cea prezentat la definirea coninutului const n aceea c rezultatul este aici exprimat n termeni de activiti (ansamblu de operaii elementare) n loc de termeni de rezultate livrabile (elemente tangibile). n cteva domenii de aplicare, structura descompus a proiectului (SDP) i identificarea activitilor sunt efectuate n acelai timp.

Modelele sunt constituite din liste de activiti (vezi paragraful 3.1.3.) sau seciuni ale unor liste de activiti care provin din proiecte derulate anterior. n plus, lista activitilor pregtite pentru un element din structura descompus a unui proiect n curs poate fi utilizat ca model pentru un alt element similar sau asemntor al aceleai structuri descompuse a proiectului.

3.1.3. Date de ieire din procesul de identificare al activitilor

Lista activitilor reprezint documentul care conine toate activitile ce trebuie s fie ndeplinite n proiect. Ea este prezentat ca o completare a SDP. Prin mrimea sa, se asigur c sunt cuprinse numai activitile care sunt indispensabile coninutului proiectului. Ca i SDP, lista activitilor, conine o descriere a fiecrei activiti permind echipei s neleag mai bine cum trebuie efectuat munca n echip.

Detaliile ajuttoare completeaz lista activitilor. Acestea trebuie documentate i prezentate pentru a facilita utilizarea listei activitilor n toate procesele managementului de proiect. Ele includ ntotdeauna o documentaie asupra tuturor ipotezelor i constrngerilor identificate. Importana detaliilor ajuttoare variaz n funcie de domeniul de aplicabilitate.

Reactualizarea structurii de repartizare a sarcinilor are loc atunci cnd se utilizeaz o SDP pentru a identifica care activiti sunt necesare. Echipa proiectului poate gsi livrabile lips, sau constat c descrierea anumitor livrabile nu este clar prezentat, ori trebuie corectat. Acest tip de reactualizare are implicaii asupra structurii descompuse a proiectului i a documentelor care decurg din SDP cum ar fi estimarea costurilor. Reactualizrile sunt adesea numite "rafinamente" i sunt mai frecvente atunci cnd proiectul utilizeaz tehnologii de lucru moderne.

3.2. SECVENIEREA ACTIVITILOR

Secvenierea activitilor se face cu scopul identificrii i punerii n eviden a

legturilor, corelrilor i relaiilor de ordonare a activitilor. Ordinea de derulare a activitilor trebuie stabilit cu grij pentru a se putea elabora apoi, o planificare realist care s fie realizabil i uor de executat. Ordonarea activitilor poate fi efectuat cu


80

ajutorul instrumentelor informatice (utiliznd software de gestiune al proiectului) sau cu tehnici manuale. Tehnicile manuale de ordonare a activitilor sunt mai eficiente la proiectele de mai mic anvergur, sau la proiecte mari n fazele iniiale, atunci cnd informaiile existente sunt reduse. De multe ori, ordonarea activitilor poate fi realizat prin combinarea tehnicilor manuale cu cele informatice.

3.2. Secvenierea activitilor

1. Date de intrare 1. Lista activitilor 2. Descrierea produsului 3. Legturi logice 4. Constrngeri 5. Ipoteze

2. Instrumente i metode1. Metoda antecedentelor 2. Metoda diagramei sgeat3. Metoda de reprezentare

condiionat 4. Reele tip

3. Date de ieire 1. Graficul proiectului 2. Reactualizarea listei

activitilor

Fig. 3.4. Punerea n eviden a tuturor activitilor proiectului

3.2.1. Date de intrare n procesul de secveniere a activitilor

Lista activitilor este descris n paragraful 3.1.3.

Descrierea produsului este tratat la paragraful 2.1.1. Caracteristicile muncii realizate condiioneaz de cele mai multe ori secvenierea activitilor (de exemplu, planul de implantare al unui punct de lucru n construcii, sau interfaa subsistemelor ntr-un proiect software etc.). Dei aceste completri sunt adesea aparente n lista activitilor, descrierea produsului realizat trebuie n general revzut pentru a se asigura exactitatea realizrii lui.

Legturile logice obligatorii sunt acele legturi specifice naturii muncii prestate. Ele sunt adesea consecinele limitelor fizice (de exemplu, ntr-un proiect de construcie, fundaiile preced n mod logic suprastructurile; sau ntr-un proiect de dezvoltare de produs realizarea prototipului precede n mod logic testrile lui). Legturile logice obligatorii sunt adesea denumite "hard logic".

Legturile logice opionale sunt acelea care pot fi decise de conducerea echipei de lucru la proiect. Ele trebuie studiate cu grij, astfel nct s fie clar documentate, deoarece mai trziu, ele pot s restrng opiunile de secveniere. Legturile logice opionale numite adesea "logica preferat" sau "software logic" sunt:

- cele mai bune practici aplicabile n domeniul studiat; - anumite aspecte ale proiectului, prin care se dorete o secveniere specific,

chiar dac celelalte secvenieri sunt acceptabile. Legturile logice externe reprezint relaiile create ntre activitile proiectului i

alte activiti care nu fac parte din proiect. n cele ce urmeaz sunt exemplificate o serie de astfel de legturi:


81

- auditul asupra mediului trebuie fcut naintea nceperii pregtirii locului unde se va realiza o construcie;

- n dezvoltarea de produs n faza de concepie sunt analizate influena produsului asupra mediului i impactul acestuia asupra cerinelor i satisfacerii nevoilor clienilor;

- testrile unui proiect de software pot depinde de livrarea unui produs care este achiziionat de la un furnizor extern.

Constrngerile au fost prezentate n paragraful 3.1.1.

Ipotezele sunt de asemenea definite n paragraful 3.1.1.

3.2.2. Instrumente i metode de secveniere a activitilor

Metoda antecedentelor (Precedence diagramming method PDM) este metoda de reprezentare a grafului reea a unui proiect. Activitile sunt figurate prin noduri iar sgeile care le leag indic relaia lor de ordonare (conform paragrafului 3.2.3.). n figura 3.5. este reprezint diagrama unei reele a unui proiect simplu conform metodei antecedentelor.

Finalizarea proiectului

A B

D E

C

F

nceperea proiectului

Fig. 3.5. Graful reea reprezentat prin metoda antecedentelor Aceasta metoda este n mod egal numit activiti organizate pe noduri (AON) i

este utilizat n majoritatea software pentru managementul proiectului. Metoda poate fi utilizat manual sau cu ajutorul unor instrumente matematice. Ea utilizeaz patru tipuri de relaii de ordonare:

Legtura final nceput n care activitatea amonte trebuie s se termine nainte ca activitatea aval s nceap.

Legtura final final se caracterizeaz prin aceea c activitatea amonte trebuie terminat naintea terminrii activitii aval.

Legtura nceput nceput la care activitatea amonte trebuie s nceap nainte ca activitatea aval s nceap.

Legtura nceput final se caracterizeaz prin aceea c activitatea amonte trebuie s nceap nainte ca activitatea aval s se termine.

n metoda antecedentelor legtura final nceput este cea mai utilizat. Legtura nceput final este rar folosit i numai de profesionitii din planificare. Utilizarea legturilor final final, nceput-nceput sau nceput final cu ajutorul unor software de


82

gestiunea proiectului poate conduce la rezultate neateptate, dac aceste tipuri de legturi nu sunt corect introduse.

Metoda diagramei sgeat (Arrow diagramming method - ADM) constituie o metod de reprezentare a grafului de ordonare i realizare logic a activitilor, cu scopul scurtrii duratei proiectului. Activitile sunt figurate prin sgei, care se reunesc n noduri. Nodurile arat interdependenele diverselor activiti aa cum este prezentat n paragraful 3.2.3.

n figura 3.6. este reprezentat graful unui proiect simplu dup metoda diagramei sgeat. Aceast metod este de asemenea cunoscut ca metoda "activitilor pe sgei" (AOA) i dei nlocuit de metoda antecedentelor, este nc tehnica aleas n anumite domenii de aplicare. Metoda diagramei sgeat nu utilizeaz dect relaii de ordonare nceput final. Pentru a reprezenta corect anumite legturi i corelri ntre activiti metoda necesit utilizarea activitilor fictive care au o durata de desfurare nul. Metoda poate fi aplicat manual, sau cu ajutorul unui instrument informatic. Acest graf trebuie nsoit de o descriere sumar care explic motivele principale ale secvenierii. Pentru o mai bun nelegere orice secveniere neobinuit a activitilor trebuie explicat.

K (7)

A (6) B (5)

E (8) G (5)

F (7)

D (7)

J (4)

I (7)

L (8)

C (4)

1

4

32

5

7

6 8

9

H (6)

Fig. 3.6. Analiza drumului critic ntr-un graf reea Metodele de reprezentare condiionat sunt anumite metode de reprezentare,

precum GERT (Graphical Evaluation and Review Technique) i modelul System Dynamics care autorizeaz introducerea activitilor nesecveniale (de exemplu, o testare care trebuie repetat de mai multe ori) sau variante opionale (de exemplu, o reactualizare care nu este necesar dect dac n urma inspeciei se constat erori). Nici metoda antecedentelor, nici metoda diagramei sgeat nu autorizeaz buclele sau variantele opionale.

Reelele tip standard pot fi utilizate pentru accelerarea ntocmirii i elaborrii mai uoare a diagramelor reea. Acest lucru poate privi ntreg proiectul sau numai o parte a lui. Anumite pri ale reelei de realizare a proiectului sunt adesea numite sub reele. Sub reelele sunt n mod deosebit utilizate atunci cnd un proiect are mai multe operaii identice sau similare. De exemplu, realizarea etajelor unui imobil nalt, sau efectuarea ncercrilor clinice ale unui proiect de cercetare n domeniul farmaceutic, sau elaborarea modulelor de programare dintr-un proiect software.


83

3.2.3. Date de ieire din procesul de secveniere a activitilor

Graful proiectului este o reprezentare schematic a activitilor proiectului i a nlnuirii lor logice (legturi, sau relaii de ordonare). Figurile 3.5 i 3.6 ilustreaz dou abordri diferite ale modului de reprezentare a graficului unei reele de proiect. Acest grafic poate fi executat manual sau cu instrumente informatice. El poate detalia complet ansamblul proiectului, sau include rezumatul uneia sau mai multor activiti. Graful proiectului este adesea denumit incorect diagrama PERT (Program Evaluation and Review Technique).

Reactualizarea listei activitilor se face atunci cnd procesul de identificare a activitilor conduce la reactualizarea SDP. Elaborarea graficului proiectului poate pune n eviden activiti care trebuie fracionate i care se definesc diferit pentru a putea reprezenta legturi logice corecte.

3.3. ESTIMAREA DURATEI ACTIVITILOR

Estimarea duratei activitilor urmrete aprecierea numrului de uniti de timp

de lucru om or, sau om lun necesare pentru realizarea n bune condiii a fiecrei activiti identificate i planificate incluse n ciclul de via al proiectului. La estimarea numrului de uniti de timp necesare pentru efectuarea unei activiti se ia n considerare timpul calendaristic. De exemplu, dac timpul necesar pentru uscarea betonului este de 4 zile, acest lucru poate reprezenta o perioad cuprins ntre 2 i 4 zile lucrtoare. n calcul se va avea n vedere dac activitatea ncepe n primele zile ale sptmnii, sau dac weekend urile sunt incluse sau nu ca zile lucrtoare. Majoritatea software de gestiune a proiectelor trateaz aceast problem n mod automat.

3.3. Estimarea duratei activitilor

1. Date de intrare 1. Lista activitilor 2. Constrngeri 3. Ipoteze 4. Necesarul de resurse 5. Capacitatea resurselor 6. Istoric

2. Instrumente i metode1. Metodele privind

prerea experilor 2. Estimri prin analogie 3. Simulri

3. Date de ieire 1. Estimarea duratei

activitilor 2. Bazele estimrii 3. Reactualizarea listei

activitilor

Fig. 3.7. Estimarea duratei activitilor desfurate n proiect Durata global a proiectului poate fi estimat utiliznd instrumentele i

metodele prezentate aici, dar ea este mai corect evaluat ca rezultat al procesului de elaborare a scadenarului aa cum este prezentat n subcapitolul 3.4.

3.3.1. Date de intrare n procesul de estimare a duratei activitilor

Lista activitilor este prezentat n paragraful 3.1.3.


84

Constrngerile reprezint o serie de restricii impuse (vezi paragraf 3.1.1.).

Ipotezele privind estimarea duratei activitilor au fost tratate n paragraf 3.1.1.

Necesarul de resurse umane sunt dezvoltate n paragraful 5.1.3. Estimarea duratei majoritii activitilor va depinde, n mare parte, de resursele ce vor fi alocate. De exemplu, dou persoane care lucreaz mpreun pot termina o activitate de studiu ntr-o perioad de timp redus la jumtate fa de situaia n care ar lucra de una singur. Acelai rezultat se obine atunci cnd o persoan lucreaz cu norm ntreag fa de o persoan care lucreaz cu jumtate de norm. Aceasta din urm are n general nevoie de o durat dubl de zile lucrtoare.

Capacitatea resurselor influeneaz n mod deosebit durata proiectului. Timpul necesar pentru derularea numeroaselor activiti depinde considerabil de capacitatea persoanelor i a echipamentelor utilizate. De exemplu, n condiii de lucru identice de ndeplinire a aceleai sarcini, un membru experimentat al echipei are nevoie de mai puin timp dect un debutant.

Istoricul se constituie din datele istorice asupra duratei probabile a numeroaselor tipuri de activiti. Datele istorice pot proveni din urmtoarele surse:

Dosarele altor proiecte, cnd organizaia implicat a con

1. managementul integrĂrii proiectului - …2+3.pdf · managementul proiectelor În dezvoltarea de...

Documents