microsoftproject.ru/articles.phtml?aid=500www.taurion.ru/project

Capitolul 1Introducere n managementul proiectelor........... 1

1.1.Conceptul de proiect1

1.2.Obiectivele proiectului3

1.3.Legaturile managementului proiectelor cu alte domenii4

1.4.Structuri organizatorice specifice n managementul proiectelor........... 7

1.5.Avantajele si dezavantajele utilizarii managementului proiectelor........... 11

Capitolul 2Descrierea continutului proiectelor13

2.1.Ciclul de viata si fazele sale13

2.2.Procesele proiectului si interactiunea lor14

Capitolul 3 Planificarea proiectului.............19

3.1.Definirea activitatilor........... 19

3.2.Definirea resurselor........... 20

3.3.nlantuirea activitatilor........... 21

3.4.Estimarea duratelor activitatilor........... 23

3.5.Estimarea costurilor resurselor alocate........... 24

3.6.Programarea activitatilor25

3.7.Controlul programarii activitatilor........... 26

3.8.Stabilirea bugetelor alocate activitatilor........... 27

3.9.Controlul costurilor........... 28

Capitolul 4 Managementul calitatii n cadrul proiectelor........... 29

3.10.Procesul de management al calitatii proiectelor........... 29

3.11.Planificarea calitatii proiectelor..................32

3.12.Asigurarea calitatii proiectelor........... 35

3.13.Controlul calitatii proiectelor........... 36

3.14.mbunatatirea calitatii proiectelor........... 40

Anexe42

Obiective:Conceptul de proiectObiectivele proiectuluiLegaturile managementului proiectelor cu alte domeniiStructuri organizatoriceAvantajele si dezavantajele utilizarii managementului proiectelor

Activitatile de productie sunt creatoare de bunuri si servicii. Dupa cantitatile realizate si dupa gradul de repetabilitate a unor activitati, produsele se pot obtine printr-o productie repetitiva sau prin realizarea unor proiecte unicat. Att productia repetitiva, ct si realizarea de proiecte au numeroase caracteristici comune, de exemplu:sunt efectuate cu ajutorul operatorilor umani;necesita alocarea unor resurse;necesita actiuni de planificare, executie si control.Prin obiectivele urmarite si prin modul de desfasurare cele doua modalitati de realizare a unor produse si servicii sunt nsa total diferite.n productia repetitiva obiectivul urmarit de o firma este profitul. Pentru obtinerea acestuia, firma realizeaza si comercializeaza produse diferite, n cantitati diferite. n acest scop firma desfasoara o activitatepermanentan domeniul n care s-a consacrat. Produsele sunt realizate prin aplicarea asupra materiei prime a unor operatii ce serepetade la produs la produs capatnd un caracter de rutina. Cele mai multe bunuri si servicii sunt realizate n cadrul productiei de serie.n cazul proiectelor, realizarea produsului atesta atingerea obiectivelor urmarite, firma ne mai continund activitatea din acel domeniu. Proiectul este un produs (serviciu) unic si complex. Realizarea proiectelor reprezinta un ansamblu de actiuni temporare ce conduc la obtinerea acelui produs.Atributul detemporaratesta ca realizarea proiectului se desfasoara ntr-o perioada de timp, avnd o data de nceput si una de sfrsit bine definite. Se considera ca un proiect a ajuns la final daca obiectivele au fost atinse satisfacator, daca se considera ca obiectivele nu mai pot fi atinse sau daca oportunitatea realizarii proiectului nu mai este prezenta. Atributul deunicatesta ca produsul se realizeaza ntr-o maniera unica, diferita de a altora, chiar daca aceste alte produse sunt din aceeasi categorie (domeniu) cu produsul vizat. Proiectul de executie al unei cladiri este unic chiar daca s-au realizat multe alte cladiri asemanatoare.Folosit initial n constructii si n industrie, conceptul de proiect a cunoscut o larga extindere. Sensul ce i se da este:Proces unic constnd ntr-un ansamblu de activitati coordonate, cu date de nceput si sfrsit, realizat pentru atingerea unui obiectiv corespunzator unor cerinte specifice si care include constrngeri de timp, cost si resurse.Exemple de proiecte:realizarea unui nou sistem informatic;reorganizarea/restructurarea unei companii;lansarea unui nou produs pe piata;ecologizarea unei zone montane;realizarea unei investitii industriale;proiectarea si implementarea unui sistem de management (al calitatii, al mediului, al sanatatii si securitatii muncii etc.).

Obiectivele proiectului sunt criterii cuantificabile ce permit aprecierea modului de realizare a proiectului.n general la realizarea unui proiect trebuie atinse trei obiective generale:obiective specifice produsului sau serviciului ce urmeaza sa fie realizat prin proiect;obiective de timp;obiective de cost.Aceste obiective generale sunt apoi divizate n obiective partiale. Aceasta divizare permite o mai buna monitorizare a realizarii acestora.1.Obiectivele finalespecifice produsului vizeaza atingerea caracteristicilor produsului la standardele de performanta si de calitate cerute.2.Obiectivele de timpvizeaza ncadrarea realizarii n termenul acordat att a ntregului proiect, ct si a fazelor de realizare a acestuia.3.Obiectivele de costvizeaza marimea costurilor realizate si ncadrarea acestor cheltuieli de realizare a proiectului ntr-un buget alocat.Obiectivele trebuie sa ndeplineasca urmatoarele criterii regasite sub acronimul SMARTER (figura 1.1):Sa fiespecifice- usor de nteles, legat de ceea ce se doreste sa se obtina prin proiect;Sa fiemasurabile- n termeni de calitate, cantitate; sa se exprime n cifre, procente;Sa fieaprobate- un obiectiv care nu a fost aprobat de catre finantator sau client risca sa conduca proiectul spre esec.Sa fierealiste, posibil de atins - sa existe capacitatea de a le atinge; factorii externi si interni sa permita realizarea lor;Timpfinit - sa se specifice intervalul de timp n care se asteapta realizarea lor;Evaluate- evaluare a gradului de atingere a obiectivelor;Revazute- pot fi revizuite, redefinite.

Figura 1.1Obiectivele SMARTERPractica demonstreaza, ca tocmai lipsa unor obiective clar definite, operationale, cuantificabile si controlabile determina adesea ncadrarea gresita a sarcinii de lucru n categoria de proiect, directionarea gresita a proiectului sau esecul acestuia. Pentru a evita aparitia unor astfel de riscuri trebuie scoase din calcul obiectivele care nu ndeplinesc aceste criterii.

Managementul proiectelor este un concept managerial ce presupune aplicarea (utilizarea) unor principii, metode si instrumente specifice la realizarea unor proiecte. Managementul proiectelor vizeaza atingerea celor trei obiective generale. Aceste trei obiective se constituie ntr-un adevarat triunghi (triada, figura 1.2) al managementului proiectelor.

Figura 1.2Triunghiul managementului proiectelorModificarea unui obiectiv dintre acestea atrage dupa sine modificarea celorlalte doua. Toate aceste obiective sunt importante, dar ntr-un proiect anume primeaza unul dintre acestea. n acest caz celelate obiective se vor ajusta de asa maniera nct obiectivul ce primeaza sa fie ct mai bine atins. De exemplu, cnd ntr-un proiect obiectivul de timp este prioritar, pentru atingerea acestuia se vor accepta obiective specifice si de cost mai putin performante.Pentru atingerea acestor obiective managementul proiectelor se dezvolta (desfasoara) de-a lungul urmatoarelor domenii (figura 1.3):managementul timpului;managementul costurilor;managementul calitatii;managementul resurselor umane;managementul riscului;managementul domeniului proiectului;managementul comunicarii;managementul aprovizionarii;managementul integrarii elementelor proiectului.

Figura 1.3Domeniile managementului proiectelorSfera cunostintelor necesare unui management eficace al proiectelor poate fi structurata n:cunostinte specifice managmentului proiectelor;cunostinte de management;cunostinte tehnico-aplicative n domeniul proiectului;abilitati n utilizarea calculatoarelor.

1.4.1 Organizarea functionala/pe departamente

Figura 1.4Organizarea functionala1.4.2 Organizarea matriceala

a)

b)

c)

d)Figura 1.5Tipuri de organizare matriceala1.4.3 Organizarea bazata pe proiecteOrganizarea bazata pe proiecte (figura 1.6) presupune realizarea proiectelor ntr-o structura organizatorica secundara cu totul independenta de structura primara a firmei.Aceasta noua structura permite rezolvarea interdisciplinara a unor sarcini de proiect ntr-o masura mult mai mare dect este posibil ntr-o structura organizatorica liniara.Att managerul de proiect ct si membrii echipei de proiect fac parte din noua structura. Organizarea primara nu intervine dect la cerere pentru rezolvarea unor aspecte de stricta specialitate. Toate competentele si raspunderile sunt localizate la nivelul organizatiei secundare, deci la nivelul managerului de proiect si a echipei sale.Avantajeleorganizarii pe proiecte sunt multiple. Managerul de proiect are competente si responsabilitati depline. Ca urmare la aparitia unor perturbatii managerul poate reactiona rapid efectund schimbarile ce se impun. Organizarea pe proiecte permite o identificare mai mare a membrilor echipelor de proiect cu obiectivele proiectelor ce le realizeaza. Aceasta identificare are efecte benefice asupra productivitatii muncii conducnd la scurtarea duratelor de executie a proiectelor. n cadrul acestei structuri organizatorice nu apar conflicte de competenta si nici pericolul dublei subordonari a membrilor echipei.Organizarea pe proiecte are sidezavantajece nu trebuie neglijate. Cheltuielile de realizare si implementare ale organizarii pe proiecte sunt mari. nainte de a deveni eficienta noua structura trebuie mai nti sa fie rodata. n aceasta perioada productivitatea echipei de proiect este redusa. Deoarece membrii echipei au fost recrutati din compartimentele functionale ale firmei, reintegrarea lor poate fi dificila datorita impactului posibil asupra carierei acestora. Realizarea unui proiect ntr-o structura organizatorica bazata pe proiecte si secundara n cadrul firmei poate crea probleme de acceptanta, de implementare a proiectului n compartimentele functionale din organizatia primara.

Echipa 1Echipa 2Echipa 3Echipa 4Figura 1.6Organizarea bazata pe proiecteStructura organizatorica bazata pe proiecte este o forma de organizare adecvata pentru realizarea proiectelor mari, cu un grad mare de complexitate, a acelor proiecte a caror realizare nu are o tangenta foarte mare cu structura organizatorica primara. Aceasta forma de organizare este folosita si n cadrul unor firme mari specializate n derularea unor proiecte (firme de consulting, de exemplu).Tipurile de structuri organizatorice specifice managementului proiectelor, precum si principalele caracteristici ale acestora sunt sintetizate n tabelul urmator:Tabelul1.1Caracteristicile structurilor organizatoriceCaracteristicile structuriiTipul structurii organizatorice

FunctionalaMatricialaPe proiecte

Autoritatea manageruluifoarte micamoderataridicata

Durata alocata proiectului din durata zilnica de lucruManagerMembrii echipeipartialpartialintegralpartialintegralintegral

Componente specifice structurii organizatorice primareintegral existentepartial existenteinexistente

Componente specifice structurii organizatorice secundare (de proiect)inexistentepartial existenteintegral existente

n principiu, managementul proiectelor, ca sistem de management, are o serie deavantaje:satisfacerea clientului - n sensul ca ntreaga actiune se bazeaza pe orientarea spre client, ale carui cerinte se regasesc exprimate prin obiectivele proiectului;coordonarea unitara a lucrarii, realizata de managerul de proiect, caruia i se adauga, n functie de marimea proiectului si alte persoane, cu responsabilitati definite (sponsorul proiectului, proprietarul proiectului, grupul de conducere a proiectului);organizarea pe echipe de proiect - grupuri pluridisciplinare ce reunesc participantii la realizarea proiectului. O astfel de structurare favorizeaza comunicarea si face posibila abordarea sistemica a problemelor, reducnd activitatile neproductive si erorile ce apar la rezolvarea etapizata, secventiala a problemelor, n structurile clasice;antrenarea oamenilor la rezolvarea problemelor, stimularea creativitatii, ce asigura nu doar rezultate mai bune, ci si dezvoltarea si motivarea personalului;folosirea unor instrumente moderne de planificare, monitorizare si control, ce conduc la optimizarea folosirii resurselor, cresterea rentabilitatii si reducerea riscurilor asociate proiectului;posibilitatea rezolvarii unor probleme complexe, n intervale de timp mult mai reduse comparativ cu versiunea clasica si cu rezultate economice superioare;promovarea unei structuri organizatorice de tip matriceal, favorizante schimbarii si eficientei organizationale;facilitarea contactelor de specialitate (tehnice, stiintifice, manageriale) ntre componentii echipei de proiect si ntre acestia si ceilalti specialisti ai societatii respective si ale altor societati;crearea unor premize favorabile pentru formarea de manageri profesionisti.Referitor ladezavantajeleutilizarii managementului proiectelor ies n evidenta urmatoarele:dificultatea selectiei managerilor de proiect buni si a convingerii lor sa-si asume riscurile impuse de proiect ct si a riscurilor profesionale pe care acest sistem le impune;aparitia si manifestarea unor duble subordonari ale specialistilor implicati n realizarea proiectului, aceasta fiind, de altfel, o limita a organizarii de tip matriceal;aparitia unor fenomene de nesincronizare a componentelor organizatorice specifice managementului proiectelor;aparitia de situatii conflictuale ntre compartimentele implicate n realizarea proiectului si componentii colectivului de proiect sau managerul de proiect.

Obiective:Ciclul de viata si fazele saleProcesele proiectului si interactiunile lor

n vederea realizarii lor proiectele sunt descompuse n mai multe faze. Descompunerea n faze a proiectului asigura o mai buna organizare, coordonare si control a realizarii acestuia, reducnd gradul de nesiguranta n realizarea acestuia. Totalitatea fazelor unui proiect se constituie n ciclul de viata al proiectului.O faza se constituie dintr-un ansamblu de activitati (lucrari) masurabile si verificabile, astfel nct la sfrsitul ei sa se poata decide daca proiectul poate sa continue n urmatoarea faza si daca sunt necesare eventuale corectii (de costuri efective, n special). Cunoasterea ciclului de viata al proiectului permite stabilirea:lucrarilor ce trebuie executate n fiecare faza;responsabililor cu executia fiecarei lucrari.Ciclul de viata al proiectului poate fi descris n termeni foarte generali sau foarte detaliati. Se prezinta n continuare ciclurile de viata (fazele de realizare) a unor proiecte din diverse domenii.1.n domeniul industriei farmaceutice. Proiectul de realizare a unui nou medicament presupune parcurgerea urmatoarelor faze:cercetarea fundamentala (de baza) si cercetarea aplicativa (cu identificarea bolilor ce vor putea fi tratate);obtinerea medicamentului n conditii de laborator (inclusiv cu testarea lui pe animale);testarea umana si avizarea medicamentului;obtinerea medicamentului n conditii industriale;nregistrarea noului medicament.2.n domeniul prelucrarii automate a datelor. Proiectarea unui sistem informatic se desfasoara n baza unui model de realizare. Sunt prezentate, n continuare, fazele de realizare a unui sistem informatic dupa modelul "n cascada" (cel mai cunoscut model):analiza sistemului existent si stabilirea cerintelor noului sistem;conceperea noului sistem;proiectarea logica;proiectarea tehnica;testarea si implementarea sistemului.n practica manageriala deseori se folosesc notiunile de ciclul de viata al unui produs sidurata acestui ciclu de viata. Aceste notiuni nu trebuie confundate cu ciclul de viata al unui proiect si durata ciclului de viata al proiectului. Durata ciclului de viata al unui produs reprezinta perioada de viata economica a produsului pe cnd durata ciclului de viata al unui proiect este perioada de realizare a acestuia.Subproiectele componente unui proiect au cicluri de viata distincte.

Un proiect se realizeaza printr-o succesiune de procese. Procesul este un ansamblu de activitati omogene. n cadrul proiectelor ntlnim doua categorii de procese: procese specifice realizarii produsului si procese specifice managementului proiectelor. Procesele specifice produsului sunt legate de realizarea unui anumit produs sau serviciu, fiind proprii acestuia (de ex. procese de consolidare a terenurilor n cadrul unui proiect de executie a unor drumuri). Procesele specifice managementului proiectelor sunt procesele ce se regasesc, n anumite proportii, n fiecare faza a proiectelor, indiferent de produsul sau serviciul ce se realizeaza. n cadrul fazelor ciclului de viata al proiectului ntlnim urmatoarele tipuri de procese ale managementului proiectelor:de initializare;de planificare;de executie;de control;de ncheiere.Procesele de initializaresunt procese de decizie prin care se autorizeaza nceperea proiectului sau a unei faze a acestuia.Initierea unui nou proiect poate fi demarata fie pentru a raspunde unei oportunitati pe piata, fie pentru a rezolva o anumita problema n afacerea respectiva. Principalii stimuli ce conduc la initierea unui nou proiect sunt:evolutia cererii pietii (lansarea unui nou produs pe piata);necesitatile firmei (cresterea profitului prin diversificarea unor activitati);evolutia tehnologiei (proiectarea unui calculator cu un procesor nou aparut);respectarea legislatiei curente sau a unor modificari ale acesteia (proiect de functionare ecologica a firmei);satisfacerea unor cerinte sociale (realizarea unei retele telefonice rurale);satisfacerea unei cerinte expres formulate de catre un beneficiar.Procesele de planificaredefinesc si redefinesc obiectivele, si selecteaza modalitatea cea mai buna de atingere a acestora.Procesele de executiecoordoneaza resursele (umane si materiale) n scopul atingerii obiectivelor propuse.Procesele de controlverifica cantitativ si calitativ masura n care obiectivele propuse au fost atinse.Procesele de ncheieresunt procese prin care este acceptat proiectul sau o faza a acestuia. n timpul realizarii proiectului (sau a unei faze a acestuia) aceste procese se deruleaza interconectat. Legaturile dintre procesele managementului proiectelor sunt prezentate n figura de mai jos.

Figura 2.1Derularea interconectata a proceselorn cadrul unei faze procesele nu se desfasoara discret, ci suprapus ca n figura de mai jos:

De-a lungul realizarii proiectului cele mai importante procese sunt cele de planificare. Dupa importanta lor aceste procese pot fi de baza sau auxiliare. n figura de mai jos sunt prezentate procesele de planificare si principalele legaturi dintre acestea.

Figura 2.3Legaturile dintre procesele de planificareManagementul proiectelor gestioneaza aceste procese de-a lungul domeniilor sale.Managementul timpuluise defineste ca ansamblul de procese de monitorizare a timpului n cadrul unui proiect. Aceste procese nu se desfasoara distinct, secvential, ci interactioneaza ntre ele, se suprapun partial si nu de putine ori se reiau. Aceste procese sunt:definirea activitatilor;nlantuirea activitatilor;estimarea duratelor de realizare a activitatilor;programarea activitatilor;controlul programarii activitatilor.Managementul costurilorinclude acele procese prin care se asigura realizarea proiectului cu bugetul alocat. Principalele procese sunt:definirea resurselor;estimarea costurilor resurselor alocate;stabilirea bugetelor alocate activitatilor (cost budgeting);controlul costurilor.Managementul risculuigestioneaza acele procese prin care se prevad si preiau evenimentele de risc. Principalele procese ce se deruleaza la managementul riscului sunt:planificarea managementului riscului;identificarea riscurilor;analiza calitativa a riscurilor;analiza cantitativa a riscurilor;planificarea masurilor de contracarare la riscuri;monitorizarea si controlul riscurilor.Aceste procese interactioneaza att ntre ele ct si cu alte procese specifice domeniului proiectului.Fiecare din aceste procese apare cel putin o data n cadrul unei faze a proiectului. Desfasurarea acestor procese nu este secventiala. Procesele interactioneaza reciproc, se suprapun partial si nu de putine ori se reiau. Desfasurarea unui proces este conditionata de desfasurarea altuia si invers. Deseori procesele se pot confunda. Spre exemplu, la realizarea proiectelor de mica anvergura, definirea resurselor, estimarea costurilor si cost budgeting sunt asa de strns legate nct pot fi considerate ca fiind un singur proces. Aceste procese interactioneaza si cu procese din alte domenii (tehnic, financiar etc.).

Obiective:Definirea activitatilorDefinirea resurselornlantuirea activitatilorEstimarea duratelor activitatilorEstimarea costurilor resurselor alocateProgramarea activitatilorControlul programarii activitatilorStabilirea bugetelor alocate activitatilorControlul costurilor

Definirea activitatilor implica identificarea si descrierea fiecarei lucrari din WBS. Cu ajutorul WBS se elaboreazalista activitatilor.

Activitatile pot fi grupate n trei categorii:activitati reale, propriu-zise, consumatoare de timp si resurse materiale si financiare;activitati consumatoare de resurse financiare, proportional cu bugetul alocat;activitati fictive, care nu consuma nici timp, nici resurse, dar care marcheaza nceputul sau sfrsitul unei faze a proiectului, sau a unor termene intermediare (milesstones).Fiecare activitate este caracterizata de cel putin urmatorii parametri:cod (numar) de identificare;descriere;durata;cod WBS;resursele necesare;sa aiba o data impusa de nceput sau de sfrsit (unde este cazul);restrictii de succesiune (unde este cazul).Acesta lista trebuie sa contina toate activitatile necesare, dar si suficiente, pentru atingerea obiectivelor proiectului. Includerea unor activitati inutile din punctul de vedere al obiectivelor urmarite prelungeste termenul de executie al proiectului si ncarca costurile de realizare ale acestuia. n cazul unor proiecte foarte complexe, WBS si lista activitatilor se vor elabora concomitent. Listei i se vor atasa descrierile activitatilor. Acestea trebuie sa permita cunoasterea de catre membrii echipei a modului n care activitatile se vor realiza. Lista activitatilor poate fi reutilizata, cu discernamnt si n alte proiecte.

Definirea resurselor are ca scop precizarea resurselor materiale si umane necesare realizarii fiecarei activitati din WBS. Resursele alocate activitatilor proiectului si nivelul acestora sunt sintetizate nlista resurselorsi/sau nlista activitatilor.

La definirearesurselor se precizeaza si nivelul fiecarei resurse astfel nct activitatea la care resursa a fost alocata sa poata fi executata. Alegerea unei resurse trebuie sa fie supervizata de costul estimat al acesteia. La alegerea unei resurse trebuie sa se tina seama de performantele acesteia (productivitatea, fezabilitatea etc.). Tipul resursei alese si nivelul alocat influenteaza n mod direct durata activitatii. Nivelul resurselor utilizate poate varia de la activitate la activitate, de la faza la faza. Modul n care sunt utilizate resursele alocate este evidentiat prinhistograma resurselor.

Aceasta histograma se construieste pentru fiecare resursa. Histograma arata nivelul utilizarii resursei pe fiecare interval de alocare, evidentiind si acele intervale n care resursa este suprancarcata.

Activitatile de realizare a unui proiect se desfasoara nlantuit. Realizarea fiecarei activitati poate, sa fie conditionata de realizarea altor activitati sau sa conditioneze realizarea altor activitati.Tipuri de relatii ntre activitati:FS(finish to start)- nceputul activitatii succesoare depinde de ncheierea activitatii precedente;

FF(finish to finish)- ncheierea activitatii succesoare depinde de ncheierea activitatii precedente;

SS(start to start)- nceputul activitatii succesoare depinde de nceputul activitatii precedente;

SF(start to finish)- sfrsitul activitatii succesoare depinde de nceputul activitatii precedente.

Ansamblul activitatilor nlantuite din cadrul unui proiect formeaza o retea. Acesta retea se poate reprezenta cu ajutorul uneidiagrame a retelei proiectului.n diagrama retelei proiectului sunt evidentiate activitatile de realizare a proiectului, precum si nlantuirea acestora. Se descrie, n acest fel, logica de executie a proiectului.

n aceasta diagrama activitatile proiectului sunt reprezentate cu ajutorul unor dreptunghiuri, iar relatiile dintre aceste activitati cu ajutorul unor sageti. Fiecare activitate poate sa fie conditionata sau sa conditioneze alte activitati. Diagrama debuteaza cu o activitate de nceput si se ncheie cu o activitate de sfrsit. ntre aceste activitati sunt plasate n ordinea logica a executiei lor restul activitatilor. Activitatile sunt legate ntre ele cu ajutorul unor sageti. Modul de trasare al sagetii si sensul acesteia sunt n concordanta cu tipul relatiei dintre activitatile legate.

Calculul (sau estimarea) duratei unei activitatii trebuie sa se faca cu considerarea obiectivelor specifice ale proiectului si a resursele alocate. Calculul trebuie efectuat sau avizat de acele persoane din echipa ce au calificare n domeniul respectiv. Stabilirea duratei activitati se realizeaza progresiv. Dupa o prima estimare se procedeaza la modificarea acesteia n concordanta cu resursele alocate. Alocarea unor resurse suplimentare pentru realizarea unei activitati conduce la reducerea duratei activitati nsa privind la nivelul ntregului proiect pot aparea suprancarcari ale unor resurse comune mai multor activitati. Asemanator, suplimentarea resurselor umane la realizarea unei activitati poate provoca scaderea productivitatii ca urmare a cresterii dificultatilor de comunicare si colaborare dintre operatorii nsarcinati cu relizarea acelei activitati. Durata activitati este puternic influentata si de calitatea resursei alocate (gradul de tehnicitate al utilajului si/sau calificarea operatorului). La stabilirea duratei activitati trebuie sa se tina seama si de timpul (elapsed time) calendatistic. Astfel, spre exemplu o activitate ce s-ar realiza n 3 zile s-ar putea ntinde pe o perioada calendaristica de 5 zile n cazul n care n acel interval calendaristic sunt doua zile nelucratoare.La stabilirea (estimarea) duratei activitati informatiile necesare pot proveni din diverse surse:literatura tehnica de specialitate;proiecte asemanatoare anterior realizate;baza de date a firmei;cunostintele persoanelor specializate n acel domeniu.Tehnicile de calcul (estimare) sunt variate ca metodologie si exactitate a rezultatelor obtinute. Cel mai adesea se utilizeaza:estimarea duratei de catre specialisti din domeniul respectiv;estimarea duratei prin analogie cu duratele unor activitati asemanatoare;determinarea duratei prin calcul analitic (metode deterministe sau probabilistice).Estimarea duratei este supusa riscului. Aceste riscuri trebuie identificate si evaluate (vezi managementul riscului). Pentru a prentmpina aceste riscuri duratelor activitatilor li se vor adauga rezerve de timp (procentual sau n unitati de timp). Pe masura ce modul de realizare a proiectului este mai cunoscut, procesul de planificare devine tot mai exact, rezervele pot fi diminuate sau chiar eliminate. Duratele activitatilor sunt nscrise n lista activitatilor.

Dupa definirea resurselor se trece la aproximarea costurilor implicate de folosirea lor. Costurile si variatiile acestora se vor estima pentru fiecare activitate de catre specialistii n domeniul respectiv. Cu aceasta ocazie se vor preciza si eventualele costuri pentru variante alternative de alocare. n multe cazuri trebuie precizate costurile folosirii resurselor n orele suplimentare regimului de lucru, deoarece aceste costuri sunt diferite de cele din orele normale de lucru. Durata executiei unei activitati influenteaza puternic nivelul resurselor si costul acestora. Managerul proiectului trebuie sa gaseasca un compromis ntre acestea. La estimarea costurilor se poate apela la diverse date istorice, comeciale sau la experienta unor specialisti.Tehnici de estimare a costurilor:metode analitice;estimarea prin analogie;modelare;metode statistice.

n vederea programarii activitatilor de realizare a unui proiect, un prim pas consta n esalonarea n timp a duratelor acestor activitati. Esalonarea n timp a duratelor unor activitati se poate realiza prinanaliza retelei.Cele mai cunoscute tehnici de analiza n retea sunt:Critical Path Method (CPM) - tehnica determinista;Program Evaluation and Review Technique (PERT) - tehnica nedeterminista;Metoda potentialelor.Procesul de programare este iterativ. Programul teoretic, preliminar, va fi n continuare ajustat si/sau refacut n stnsa legatura cu desfasurarea altor procese, ndeosebi cu estimarea duratelor activitatilor si a costurilor acestora.La elaborarea programarii trebuie cunoscute resursele disponibile pe fiecare interval de planificare, resursele comune alocate unor activitati diferite, resursele deficitare. Programul proiectului ramne preliminar pna cnd alocarea resurselor a fost confirmata.Programul proiectului poate fi prezentata n detaliu sau sumar. Obisnuit programul poate fi reprezentat sub doua forme diferite:graficul Gantt;graficul termenelor intermediare (milestone).Graficul Ganttsau graficul cu bare, reprezinta activitatile cu ajutorul unor bare. Lungimea unei bare este data de durata activitatii ce o reprezinta. Barele sunt plasate de-a lungul unei axe a timpului calendaristic. n acest fel se pot preciza, pentru fiecare activitate, datele de nceput si de sfrsit, precum si rezervele de timp ale acestora. Plasarea activitatilor n timp permite uneori depistarea dependentelor dintre activitati.

Graficul termenelor intermediare(milestone)este asemanator cu graficul Gantt, dar identifica numai datele intermediare de executie a principalelor faze sau lucrari ale proiectului. Este folosit ca interfata cu beneficiarul. n figura de mai jos se prezinta un grafic al termenelor intermediare pentru un proiect de constructii cu numai trei faze:Faze/lucrariLuni calendaristice

IFMAMIIAS

Sapaturi

Zidarie

Finisari

Figura 3.6Graficul termenelor intermediare

Controlul programarii monitorizeaza acei factori ce permit modificarea agreata a unei programari. Controlul programarii se refera la:continutul modificarilor;marimea modificarilor;operarea modificarilor;efectul modificarilor.Daca numarul si importanta modificarilor este mare se impune revizuirea proiectului. Proiectul revizuit trebuie supus aprobarii beneficiarului.n urma controlului se impun aplicarea unor masuri corective care sa permita continuarea proiectului n concordanta cu planul aprobat. Aplicarea masurilor corective trebuie sa permita realizarea activitatii n ntrziere la termen sau cu o ntrziere ct mai mica. Depistarea masurilor corective este obiectul unei analize. Cel mai adesea ntrzierile activitatilor necritice se pot compensa din rezervele acestei activitati sau din rezervele activitatilor necritice, succesoare acesteia.

Dupa realizarea unei programari se trece la stabilirea bugetelor alocate fiecarei activitati (cost budgeting). La stabilirea bugetelor alocate activitatilor se folosesc aceleasi tehnici ca la estimarea costurilor, procesul fiind o prelungire a celui din urma. Se stabileste n acest fel o baza pentru aprecierea modului de executie al fiecarei activitati si n final a proiectului. Nu de putine ori estimarea costurilor se face dupa ce bugetele pe activitati au fost aprobate, procesele derulndu-se n sens invers. Pentru monitorizarea costurilor ntregului proiect se va elaboradiagrama bugetului.

Figura 3.7 Diagrama bugetuluin acest grafic se vor evidentia evolutia n timp a costurilor planificate si realizate.

Controlul costurilor monitorizeaza factorii ce influenteaza marimea costurilor, determina valoarea modificarilor si a abaterilor de la valorile planificate. Controlul costurilor include:detectarea si analiza abaterilor;efectuarea modificarilor de costuri n consens cu bugetul alocat;prevenirea modificarilor neavizate sau incorecte;masuri de aducere a costurilor la limite acceptate.Pentru elaborarea asistata a planificarii activitatilor, pe piata sunt comercializate o serie deproduse software specializate. Dintre acestea, cele mai ntlnite sunt Primavera si Microsoft Project. Utilizarea unui produs soft confera o serie de avantaje: obtinerea mai multor variante de program si simularea executiei acestor variante, nivelarea automata a resurselor, operativitate, accesibilitate neinitiatilor, urmarire si control. Produsele permit afisarea si imprimarea rezultatelor dispunnd de o paleta larga de facilitati grafice.

Obiective:Procesul de management al calitatii proiectelorPlanificarea, asigurarea, controlul si mbunatatirea calitatiiproiectelor

Managementul calitatii proiectului include procesele necesare pentru asigurarea ca proiectul va satisface cerintele pentru care a fost lansat. Managementul calitatii proiectului include toate functiile de management care determina politica de calitate, obiectivele si responsabilitatile aferente proiectului si se realizeaza prin planificarea calitatii, asigurarea calitatii, controlul calitatii, mbunatatirea calitatii, cuprinse n sistemul calitatii. Procesele majore ale managementului calitatii proiectului sunt puse n evidenta n figura 4.1.Figura 4.1.Vedere generala asupra proceselor majore ale managementului calitatii proiectuluiAsa cum rezulta si din figura mai sus prezentata, managementul calitatii proiectului, prezinta patru componente distincte, fiecare dintre acestea fiind structurate pe: date de intrare, instrumente si tehnici de realizare a etapei calitative respective, resurse, precum si rezultatele finale, ce sunt prezentate sub forma unor date de iesire.Aceste patru procese interactioneaza att ntre ele ct si cu celelalte procese ale managementului proiectului. Fiecare proces impune eforturi din partea unuia sau a mai multor membri ai echipei, sau a altor structuri organizationale, n functie de necesitatile proiectului. Fiecare proces se regaseste cel putin o data n fiecare faza (etapa) a proiectului. Desi procesele sunt prezentate ca elemente distincte, cu interfete clar definite, n practica ele pot interactiona unele cu altele. Structura de baza a managementului calitatii proiectului este astfel realizata nct asigura compatibilitatea cu seria de standarde internationale ISO 9000 si ISO 10000, cu recomandarile initiatorilor proceselor de management al calitatii (Deming, Juran, Crosby si altii), precum si cu dezvoltarile ulterioare (TQM - managementul calitatii totale, cresterea continua a calitatii).Managementul calitatii proiectului se adreseaza att managementului proiectului propriu-zis ct si produsului /serviciului rezultat din proiect. Termenul de "produs" este generic utilizat n literatura referitoare la calitate, el referindu-se att la produse ct si la servicii.Absenta cerintelor de calitate, n fiecare faza a proiectului, poate avea consecinte negative asupra partenerilor implicati n proiect.De exemplu :Modificarile cerintelor clientului / utilizatorului proiectului, prezentate pe parcursul executiei proiectului, n reuniunile (sedintele) de faza, pot avea consecinte negative n sensul cresterii sarcinilor echipei de proiect.Devansarea inspectiilor de calitate planificate, stabilite n cadrul reuniunilor de modificare a duratelor de realizare a obiectivelor intermediare, poate avea consecinte negative prin aparitia unor erori neprevazute.Un aspect critic n managementul calitatii proiectului l reprezinta necesitatea ca obiectivele stabilite ale proiectului, prezentate n scopului proiectului, sa raspunda necesitatilor implicite si explicite ale clientului / utilizatorului.Echipa de proiect nu trebuie sa confunde "calitatea" cu "clasa". Clasa reprezinta o treapta sau un grad dat unor entitati care au functionalitati (utilizari) comune dar au caracteristici tehnice diferite.Calitatea slaba este ntotdeauna o problema. Clasa inferioara poate sa nu fie. De exemplu, un produs software poate fi de calitate superioara (fara defecte evidente) dar de clasa inferioara (cu numar limitat de caractere) sau poate fi de slaba calitate (defecte evidente numeroase, utilizare greoaie) si de clasa superioara (multiple caracteristici). Determinarea si stabilirea nivelelor cerute att de calitate ct si de clasa reprezinta responsabilitatea att a managerului de proiect ct si a echipei pe care acesta o coordoneaza.Echipa de proiect trebuie, de asemenea, sa constientizeze faptul ca un management modern al calitatii completeaza managementul proiectului. De exemplu, ambele discipline recunosc importanta:Satisfactiei clientului /utilizatorului - ntelegerea, specificarea si influentarea necesitatilor astfel nct ele sa raspunda asteptarilor acestuia. Acest lucru reprezintaconformitatea produsuluicu cerintele proiectului, care trebuie sa realizeze ceea ce s-a stabilit sa realizeze si sa satisfaca necesitatile reale ale clientului / utilizatorului).Actiunilor de prevenire, mai mult dect a acelora de corectie - costul actiunilor de prevenire a unor greseli este ntotdeauna mai mic dect costul corectarii lor.Responsabilitatea managementului - realizarea fazelor proiectului presupuneparticipareantregii echipe, darresponsabilitatea managementuluipresupune planificarea si estimarea resurselor necesare pentru realizarea fazelor.Similaritatea proceselor proiectului cu fazele acestuia - ciclul repetabil Plan-Do-Check-Act, descris de Deming si dezvoltat ulterior, este similar att pentru faze ct si pentru procese.n plus, calitatea presupune att cresterea calitatii managementului proiectului ct si cresterea calitatii produsului rezultat.Totusi exista o limitare n abordarea managementului calitatii, de care echipa de proiect trebuie sa tina seama. Durata limitata de realizare a proiectului presupune limitarea investitiilor n cresterea calitatatii produsului, mai ales n prevenirea aparitiei defectelor si n evaluarea lor.

Planificarea calitatii presupune identificarea standardelor de calitate, relevante pentru proiect si determinarea modalitatilor de satisfacere a acestora. Este una dintre cheile proceselor ajutatoare ale planificarilor proiectului. Poate fi realizata n mod regulat sau n paralel cu alte procese de planificare. De exemplu, schimbarile cerute asupra produsului necesita stabilirea standardelor de calitate aferente si poate necesita ajustari de costuri pe parcursul fazelor proiectului, sau calitatea dorita a produsului poate necesita o analiza de risc pentru identificarea problemelor ce pot apare la realizarea proiectului.Realizarea activitatilor care dezvolta cu prioritate seria de standarde ISO 9000 sunt detaliate n procesul de asigurare a calitatii.Tehnicile de planificare a calitatii sunt, n cea mai mare parte, cele utilizate n planificarea proiectului.Echipa de proiect trebuie sa respecte una din axiomele fundamentale ale managementului modern al calitatii - calitatea se planifica, nu se controleaza.A. Intrari ale procesului de planificare a calitatii1.Politica de calitate.Reprezinta intentiile si directiile generale ale organizatiei n ceea ce priveste calitatea, exprimate de conducerea acesteia. Politica de calitate adoptata de proiect poate fi cea a organizatiei pentru ca aceasta este. n cazul realizarii proiectului prin participarea mai multor organizatii, echipa de proiect si defineste propria politica de calitate. Echipa de proiect este responsabila de asigurarea ca partenerii implicati n proiect sunt constienti de politica de calitate adoptata.2.Obiectivele stabilite.Stabilirea obiectivelor reprezinta cheia intrarilor n procesul de planificare a calitatii. Obiectivele stabilite nca de la initierea proiectului trebuie sa serveasca definirii necesitatilor partenerilor implicati.3.Descrierea produsului.Descrierea produsului contine detalii si caracteristici tehnice care ajuta la stabilirea obiectivelor si care pot afecta planificarea calitatii.4.Standarde si reglementari.Echipa de proiect trebuie sa ia n considerare standardele si reglementarile relevante pentru proiect pentru ca acestea pot afecta calitatea acestuia.5.Iesirile altor procese.Alaturi de obiectivele proiectului si de descrierea produsului si iesirile altor procese pot fi integrate n planificarea calitatii. De exemplu, planificarea aprovizionarii poate identifica cerintele de calitate impuse furnizorului, cerinte ce sunt reflectate n planificarea calitatii.B. Instrumente si tehnici ale procesului de planificare a calitatii1.Analize beneficiu / cost.Analizele beneficiu / cost presupun estimarile costurilor si beneficiilor tangibile si intangibile ale diferitelor variante de proiect, utiliznd instrumente financiare cum ar fi: durata de recuperare a investitiei, valoarea neta actualizata a investitiei, rata interna de rentabilitate. Aceste analize sunt utile pentru evaluarea proiectului si identificarea alternativelor. Cel mai important beneficiu al stabilirii cerintelor de calitate l reprezinta efortul corectiv mai mic, productivitate mai mare, costuri de realizare a proiectului mai mici, satisfactie din partea partenerilor. Cel mai important cost se refera la cheltuielile asociate activitatilor de management al calitatii. Managementul calitatii nu se obtine fara costuri.2.Benchmarking.Benchmarking-ul este o metoda de management care presupune compararea proiectului actual cu practicile similare din alte genuri de proiecte, din organizatie sau din afara ei, avnd ca scop gasirea de solutii si stabilirea standardelor de masura a performantelor.3.Diagrame de fluxuri.Diagrama de flux prezinta, grafic, cum variaza, n timp, sistemul de resurse analizat. Tehnicile cele mai comune utilizate n managementul calitatii, pentru reprezentarea grafica a fluxurilor, includ:Diagrama cauza - efect, numita si diagrama Ishikawa. Aceasta tehnica permite identificarea cauzelor succesive ale aparitiei unei "probleme". Un exemplu generic de diagrama este prezentat n figura 4.2.Diagramele de fluxuri ajuta echipa de proiect pentru a prevedea ce si unde pot apare probleme de calitate n evolutia proiectului si ajuta la gasirea de solutii pentru anularea lor.

Figura4.2.Diagrama cauza-efect4.Simulari.Simularea este o metoda statistica care ajuta la identificarea factorilor care pot influenta variabilele specifice ale proiectului. Tehnica este aplicata cel mai mult asupra produsului proiectului.5.Costul calitatii.Costul calitatii se refera la costul total al eforturilor pentru realizarea calitatii produsului si include toate activitatile care asigura att conformitatea ct si neconformitatea produsului. Costul calitatii cuprinde trei tipuri de costuri: costuri de prevenire, costuri de evaluare, costuri datorate omisiunilor.C. Iesiri ale procesului de planificare a calitatii1.Planul de management al calitatii.Echipa de proiect trebuie sa prezinte, prin planul de management al calitatii, modalitatile de implementare a politicii de calitate. Sistemul calitatii proiectului, conform ISO 9000, cuprinde: "structura organizatorica, responsabilitati, proceduri, procese si resurse necesare pentru implementarea managementului calitatii". Planul de management al calitatii are ca intrari rezultatele (iesirile) tuturor proceselor de planificare si este orientat spre controlul calitatii, asigurarea calitatii si cresterea calitatii proiectului. Planul de management al calitatii poate fi formal sau informal, detaliat sau doar schematic, n functie de cerintele proiectului.2.Definirea specificatiilor de calitate.Specificatiile de calitate descriu, n termeni specifici, domeniile si limitele procesului de control al calitatii. De exemplu, planificarea duratei unei activitati nu este suficienta din punct de vedere al managementului calitatii. Echipa de proiect trebuie sa indice si data de nceput si de sfrsit a acesteia daca activitatea va fi masurata sau doar anumite rezultate ale ei si care anume.3.Liste de control.Lista de control este un instrument utilizat la verificarea si controlul realizarii activitatilor. Poate fi simpla sau complexa, n functie de specificul proiectului. Ea realizeaza legatura dintre rezultatele trecute si rezultatele viitoare, este un mijloc de apreciere si corectie a performantelor proiectului.4.Intrari pentru alte procese.Procesul de management al calitatii poate identifica necesitatile pentru realizarea altor activitati cuprinse n celelalte procese de management.

Asigurarea calitatii cuprinde evaluarea si demonstrarea ca toate activitatile planificate si realizate n sistemul calitatii satisfac standardele si reglementarile de calitate ale proiectului. Toate activitatile incluse n planul de management al calitatii fac parte integranta din sistemul de asigurare a calitatii.Asigurarea calitatii este deseori realizata de un compartiment specializat al organizatiei dar nu este obligatoriu. Poate fi realizata de echipa de proiect, n interiorul organizatiei din care face parte (asigurare interna a calitatii) sau de catre clienti sau colaboratori neimplicati n proiect (asigurare externa a calitatii).A. Intrari ale procesului de asigurare a calitatii1.Planul de management al calitatii.Planul de management al calitatii este descris n cadrul subcapitolului anterior, punctul C.2.Rezultatele controlului calitatii.Rezultatele controlului calitatii reprezinta nregistrarile ncercarilor, verificarilor si masuratorilor realizate, n format comparabil (valori comparabile) pentru realizarea evaluarilor.3.Definirea specificatiilor de calitate.Specificatiile de calitate sunt descrise n subcapitolul anterior, punctul C.B. Instrumente si tehnici pentru asigurarea calitatii1.Instrumente si tehnici deasigurarea calitatii.Instrumentele si tehnicile de planificare a calitatii descrise anterior pot fi utilizate si pentru asigurarea calitatii.2.Audituri ale calitatii.Auditul calitatii este o evaluare facuta asupra activitatilor de management al calitatii realizate (fie n acelasi proiect fie n altele), n vederea mbunatatirii performantelor proiectului actual. Poate fi planificat sau realizat ori de cte ori este necesar. Poate fi realizat de auditori interni sau externi ai organizatiei.C. Iesiri ale procesului de asigurare a calitatii1.mbunatatirea calitatii.mbunatatirea continua a calitatii include actiuni de crestere a eficacitatii si eficientei proiectului n vederea obtinerii de beneficii pentru parteneri si satisfactie pentru utilizator. Implementarea cresterii calitatii necesita actiuni preventive si corective, conform procedurilor de control stabilite n planul de executie a proiectului.

Controlul calitatii implica monitorizarea rezultatelor specifice ale proiectului n vederea masurararii conformitatii lor cu standardele si reglementarile de calitate de referinta si identificarea cailor de eliminare a cauzelor de neconformitate.Controlul calitatii se realizeza pe ntreg parcursul executiei proiectului. Rezultatele monitorizate se refera att la performantele produsului ct si la rezultatele managementului proiectului. Poate fi coordonat de un compartiment specializat al organizatiei din care face parte echipa de proiect sau chiar de catre aceasta. Echipa de proiect trebuie sa posede cunostinte de control statistic al calitatii sa fie capabila sa utilizeze notiuni ca:Prevenire (mpiedicarea aparitiei erorilor n executia proiectului) si inspectie (mpiedicarea detectarii erorilor de catre client).Caracteristici de referinta (rezultate statice fata de care se compara conformitatea) sau variabile de referinta (rezultate ce evolueaza continuu si fata de care se masoara gradul de conformitate).Evenimente aleatoare (evenimente neobisnuite) si evenimente previzionate (variatii normale ale proceselor proiectului).Tolerante (intervale limita de conformitate).A. Intrari ale controlului calitatii1.Rezultatele activitatilor.Rezultatele activitatilor, incluse n planul de executie a proiectului, cuprind att performantele produsului ct si rezultatele proceselor de management a proiectului. Rezultatele planificate trebuie sa fie disponibile pe tot parcursul executiei proiectului pentru compararea cu rezultatele obtinute sau n curs de realizare.2.Planul de management al calitatii.Este descris nsubcapitolul 3.1.2, punctul C.3.Definirea specificatiilor de calitate.Specificatiile de calitate sunt descrisen subcapitolul 3.1.2, punctul C.4.Liste de control.Listele de control sunt descrise n subcapitolul 3.1.2, punctul C.B.Instrumente si tehnici pentru controlul calitatii1.Inspectii.Inspectiile includ activitati precum masurare, examinare si testare n vederea stabilirii conformitatii rezultatelor proiectului cu cerintele acestuia. Inspectiile pot fi realizate la orice nivel (rezultatele unei singure activitati sau rezultatele produsului final).2.Diagrame de control.Diagramele de control (figura 4.3) reprezinta vizualizarea grafica, n timp, a rezultatelor produsului sau proceselor. Sunt utilizate pentru stabilirea momentului n care procesul este n control (apar erori previzionate sau aleatoare). Atunci cnd procesul este n control el nu trebuie adaptat. El poate fi schimbat, n vederea mbunatatirii calitatii lui, dar nu trebuie adaptat n timpul procesului de control.Diagramele de control pot fi utilizate pentru monitorizarea diferitelor variabile de iesire. Cel mai frecvent sunt utilizate pentru activitati repetitive, costuri sau variante de termene, erori n documentatii.

Figura 4.3.Diagrama de control pentru o caracteristica programataFigura 4.3 prezinta o diagrama de control pentru o caracteristica programata.Axa reprezinta axa timpului. Exista trei linii ale diagramei de control:I. Linia X, centrala, reprezinta media performantelor nregistrate;II. Linia superioara reprezinta limita maxima de abatere admisa, fata de care se poate masura varianta;III. Linia inferioara reprezinta limita minima de abatere admisa, sub care caracteristica este neconforma sau procesul este instabil.3.Diagrame Pareto.Principiul acestei tehnici consta n izolarea a 20% din parametrii unei activitati care explica 80% din problemele acesteia (figura 4.4). Este o metoda de decizie si control care permite utilizarea prioritatilor dupa diferite criterii, folosind statistici descriptive si analizarea lor. Ea ajuta la conducerea interventiilor n mod metodic abordnd succesiv punctele cele mai importante. Ea permite, deci, stabilirea unui plan de actiune eficient.4.Esantionare statistica.Esantionare statistica presupune alegerea unor categorii de activitati sau procese reprezentative, din lista completa, pentru inspectie. Acest tip de selectie reduce costurile controlului calitatii.5.Diagrame de fluxuri.Diagramele de fluxuri sunt prezentate n subcapitolul 3.1.2, punctul B. n cadrul acestui proces ajuta la analizarea cauzelor aparitiei disfunctionalitatilor.6.Analize de trend.Analizele de trend folosesc tehnici matematice si vizeaza evolutiile strict cantitative ale rezultatelor. Ele se bazeaza pe o extrapolare a datelor din trecut spre viitor. Sunt utilizate pentru monitorizarea:Performantelor tehnice - cte erori sau defecte au fost identificate si cte au ramas necorectate.Costul si programarea activitatilor - cte dintre activitatile dintr-o anumita perioada au fost realizate cu abateri semnificative.

Figura 4.4.Diagrama Pareto7.Tehnica Brainstorming. Tehnica Brainstorming (n traducere "cascada ideilor" sau "asaltul creierului") este o tehnica ce si propune simularea emisiei de idei a unui grup pluridisciplinar pentru rezolvarea unei probleme. Grupul reuneste de la 3 pna la 10 persoane solicitate sa rezolve o problema despre care nu au fost informate n prealabil. Numarul optim este de 5 sau 6 membri. Tehnica se desfasoara sub forma unei sedinte, a carei durata optima este de 30-40 minute.Principiile metodei sunt:Cantitatea poate genera calitate.Dat fiind faptul ca ntr-o sedinta sunt emise un numar mare de idei (ntre 30 si 200), exista de cele mai multe ori sansa ca ideea care va duce la rezolvare sa fie printre cele emise.Critica sau evaluarea nu este admisa n timpul sedintei.Datorita acestui fapt varietatea de idei creste, ca si neconventionalitatea lor.n grup se creeaza efectul de "reactie n lant".O idee a unui participant (chiar daca este ridicola, absurda, total nepractica etc.) prin procedeul asocierii (sau prin alt procedeu de creatie) genereaza o alta idee altui participant sau chiar celui ce a emis-o s.a.m.d.Evaluarea si selectarea ideilor se face ulterior, de un grup restrns de specialisti, retinndu-se solutiile mai valoroase cu un grad mare de aplicabilitate. Statisticile au aratat ca dintre ideile emise prin tehnica Brainstorming, 20% sunt aplicabile iar cca 4% sunt de o certa valoare.C. Iesiri ale controlului calitatii1.mbunatatirea calitatii.Cresterea calitatii este prezentata n subcapitolul 3.1.3, punctul B.2.Elaborarea deciziilor.Componentele neconforme ale activitatilor sau proceselor, identificate n timpul inspectiilor, pot fi acceptate sau eliminate. Componentele eliminate presupun aplicarea de activitati corective.3.Corectii.Corectiile sunt actiuni de eliminare a neconformitatilor. Ele intra n categoria activitatilor neprevazute si reprezinta una dintre cauzele cele mai frecvente de nerespectare a termenilor proiectului. Echipa de proiect trebuie sa depuna eforturi pentru minimizarea acestor tipuri de activitati.4.Completarea listelor de control.Listele de control, prezentate n subcapitolul 3.1.2, punctul C, odata completate, devin baza de nregistrari si de informatii pentru proiect.5.Procese de ajustare.Procesele de ajustare presupun actiuni preventive si corective imediate, ca urmare a rezultatelor controlului calitatii. n unele cazuri, aceste procese se desfasoara o data cu procesele de control integrat al proiectului.

Standardele ISO prezinta ca parti distincte ale managementului calitatii proiectelor asigurarea calitatii proiectelor si mbunatatirea calitatii proiectelor. mbunatatirea calitatii proiectelor este partea managementului calitatii proiectului ce se concentreaza pe cresterea abilitatii proiectului de a ndeplini cerinte ale calitatii.n opinia mea, asigurarea calitatii proiectului, respectiv mbunatatirea calitatii proiectului reprezinta doua secvente interdependente ale conducerii proiectului, ce reflecta satisfacerea cerintelor referitoare la calitate identificate la un moment dat, respectiv trecerea la un nivel nou de performanta pentru o mai buna satisfacere a asteptarilor. Astfel, mbunatatirea calitatii proiectului apare ca finalitate a unui ciclu de actiuni initiate pentru rezolvarea unor probleme de calitate.Realizarea acestui proces se bazeaza pe folosirea unor instrumente specifice. O importanta deosebita o au planurile de actiunePDCA, cunoscute si sub denumirea de "ciclul Deming" (sau "roata lui Deming"). PDCA (Plan-Do-Check-Act) sugereaza ca pentru a mbunatati calitatea, ciclulPlanifica-Executa-Verifica-Actioneazatrebuie reluat mereu.Roata lui Deming prezinta succesiunea activitatilor pentru mbunatatire evidentiind faptul ca este esential sa se evalueze corect realitatea nainte de a efectua mbunatatiri. n cadrul organizatiilor care si-au creat sisteme de management al calitatii acest mecanism se aplica n toate domeniile de activitate, nu numai n domeniul managementului proiectelor, parcurgndu-se cele patru faze astfel:Planificarea actiunilor, stabilirea unor indicatori de control (plan).Transformarea planului n actiuni individuale (do).Monitorizarea actiunii, colectarea de informatii cu privire la performantele realizate (check).Analiza abaterilor, identificarea cauzelor si stabilirea corectiilor (act).Munca n echipa, metodele de analiza si de creativitate, dar mai ales formarea unei atitudini favorabile mbunatatirii, astfel nct aceasta sa devina o stare de spirit a fiecarui lucrator, sunt elemente specifice managementului calitatii n general, si ale managementului calitatii proiectelor n particular, de care depinde succesul acestor actiuni.

Rezultatele cercetarilor grupului Standish sunt cele mai citate statistici n industria de IT si au avut si efecte, inclusiv schimbari guvernamentale majore. Cercetarea cumulata prezinta date prelevate, pe perioada unei decade, despre cauzele ce duc la esecul proiectelor: 50.000 de proiecte IT terminate, plus 450 de workshop-uri, focus grupuri si sesiuni de terapie ale grupurilor de proiect pentru a crea contextul calitativ pentru rezultatele studiilor.Grupul Standish a realizat mai multe studii ce s-au concluzionat prin rapoarte. Dintre acestea cele mai importante sunt:"CHAOS" n 1995."CHAOS: A Recipe for Success" n 1999."EXTREME CHAOS" n 2001."2004 THIRD QUARTER RESEARCH REPORT".Toate rapoartele CHAOS s-au concentrat consecvent pe identificarea:Scopului proiectelor software esuate.Factorii principali ce au cauzat esuarea proiectelor software.Ingredientele cheie ce pot reduce numarul proiectelor esuate.Rezultatele cercetarilor CHAOS dau o vedere globala asupra statisticilor de proiect, dar au tendinta sa se concentreze mai mult spre Statele Unite si Europa:58% dintre respondenti sunt din SUA,27% dintre respondenti sunt europeni,doar 15% reprezinta restul tarilor lumii."n USA se cheltuiesc mai mult de 275 bilioane de dolari n fiecare an pentru dezvoltarea de aplicatii IT prin aproximativ 200.000 de proiecte." "Costul mediu pentru un proiect de dezvoltare pentru o companie mare este de 2.322.000$, pentru o companie medie este de 1.331.000$, iar pentru o companie mica este de 434.000$. Multe dintre aceste proiecte vor esua. Proiectele de dezvoltare a softurilor sunt n haos."Cercetarea grupului Standish arata ca un zguduitor procent de 31,1% din proiecte au fost contramandate nainte de a fi terminante. Alte rezultate indica ca 52,7% din proiecte costa 189% din estimarea lor originala. Costurile oportunitatii pierdute nu sunt masurabile, dar s-ar putea usor estima la tilioane de dolari.Pe baza acestei cercetari, grupul Standish estimeaza ca n anul 1994 companiile americane si agentiile guvernamentale au cheltuit 81 bilioane de dolari pentru proiectele de software contramandate. Aceleasi organizatii au platit nca 59 de bilioane de dolari pentru proiectele de software ce au fost duse la bun sfrsit, dar depasesc estimarile originale de timp. Factorul de risc ntotdeauna va exista n cazul dezvoltarii de noi softuri, dar multe dintre aceste proiecte sunt banale, cum ar fi crearea unei baze de date pentru carnetele de conducere sau un nou pachet de contabilitate.Media proiectelor software ce sunt terminate la timp si n buget este de 16,2%. n companiile mari, procentul este si mai scazut: doar 9% din proiectele lor sunt terminate n timp si n bugetul planificat. si chiar si atunci cnd aceste proiecte sunt terminate, multe dintre ele nu sunt dect simple umbre ale cerintelor originale specificate. Proiectele terminate de cele mai mari companii americane detin doar aproximativ 42% din caracteristicile si functiile original propuse, n timp ce companiile mai mici o duc mai bine. Un total de 78,4% dintre proiectele de software vor fi derulate cu cel putin 74,2% din caracteristicile si functiile lor originale.Aceste date sunt descurajatoare, dar de fapt 48% dintre directorii IT executivi, ce au facut parte din esantionul cercetarii, cred ca actual exista mai multe esecuri dect acum 5 ani. Vestea buna este ca peste 50% cred ca n ziua de azi exista mai putine esecuri sau numarul lor este acelasi cu cel nregistrat cu 5, 10 ani n urma.Studiul facut de grupul Standish a fost ct se poate de minutios. Rezultatele se bazeaza pe ceea ce grupul Standish defineste ca "constatari cheie" ale studiului de cercetare si pe cteva interviuri personale. Respondentii au fost manageri executivi IT. Esantionul a inclus companii mari, medii si mici din principalele segmente industriale: bancare, asigurari, industria manufacturiera, vnzare en-detail si en-gros, sanatate, servicii si organizatii locale, de stat si federale. Dimensiunea esantionului n 1994 a fost de 365 de respondenti, ce reprezentau 8380 de aplicatii. n plus, grupul Standish a condus 4 focus groups si numeroase interviuri personale pentru a crea contextul calitativ pentru rezultatele studiului.Pentru a atinge scopul studiului, proiectele au fost clasificate n 3 tipuri n functie de gradul de reusita:Tipul 1 sau proiect reusit:Proiectul a fost terminat n timp si n buget, cu toate caracteristicile si functiile specificate initial.Tipul 2 sau proiect ncercat (provocat):Proiectul a fost terminat si este operational, dar a depasit timpul si bugetul estimat si are mai putine caracteristici si functii dect a fost original specificat.Tipul 3 sau proiect contramandat:Proiectul este anulat ntr-un anumit moment din derularea sa.n total, rata de succes (de reusita) a fost doar de 16,2%, n timp ce procentul proiectelor ncercate s-a ridicat la 52,7% si cel al proiectelor contramandate la 31,1%.Grupul Standish a segmentat mai departe aceste rezultate pe companiile mari, medii si mici. O companie mare este orice companie cu cifra de afaceri peste 500 milioane dolari pe an, o companie medie este definita ca avnd o cifra de afaceri ntre 200 milioane de dolari si 500 milioane dolari pe an, iar o companie mica nregistreaza o cifra de afaceri cuprinsa ntre 100 milioane de dolari si 200 milioane de dolari. Astfel:45% dintre companii sunt considerate ca fiind de tipul Fortuna 1000 (mari);35% dintre companii sunt medii;20% dintre companii sunt mici.Cercetarea include proiecte de diferite tipuri mpartite n categoriile prezentate n tabelul urmator.Tabelul I.1Repartizarea proiectelor incluse n cercetare pe categoriiCategorii de proiecteAnul

20002004

Dezvoltate pornind de la zero prin utilizarea limbajului si metodelor traditionale33%36%

Dezvoltate pornind de la zero prin utilizarea unui obiect model13%19%

Dezvoltarea unor componente si cumpararea celorlalte13%16%

Aplicatie cumparata si modificata15%13%

Componente cumparate si ansamblarea aplicatiei9%6%

Cumpararea aplicatiei si extinderea acesteia12%6%

Cumpararea aplicatiei si nemodificarea ei5%4%

Procentul de esec determinat este n mod egal descurajator att pentru companiile mari, ct si pentru cele medii si mijlocii (tabelul I.2).Tabelul I.2Ratele de reusita/insucces repartizate n functie de dimensiunea companiilorTipul proiectuluiDimensiunea companiilor

MareMedieMica

Proiecte reusite9%16,2%28%

Proiecte ncercate61,5%46,7%50,4%

Proiecte contramandate29,5%37,1%21,6%

Studiul pe o durata de 11 ani a grupului Standish arata o mbunatatire n managementul proiectelor IT (figura I.1).FiguraI.1Gradul de reusita al proiectelor (1994-2004)Figura I.1 arata ca ratele de succes (reusita) sunt n crestere. Acest grafic descrie gradul de reusita a 50.000 de proiecte de aplicatii derulate n companii mari, medii si mici testate de grupul Standish din 1994 pna n prezent.Cel mai important aspect al acestei cercetari este determinarea cauzelor ce duc la esecul proiectelor. Pentru aceasta grupul Standish a chestionat manageri executivi de IT pentru a afla opinia lor cu privire la cauzele care duc la reusita proiectelor. Principalele trei motive ce conduc la succesul unui proiect, n anul 1994, au fost: implicarea utilizatorilor, suportul conducerii executive si declararea clara a cerintelor (tabelul I.3). Exista si alte criterii de succes, dar ndeplinirea celor trei enumerate mai sus creste semnificativ sansele de succes ale oricarui proiect. Fara ele, sansele de reusita scad dramatic.Tabelul I.3Factorii de succes ai proiectelorNr. crt.Factorii de succes ai proiectelor% din raspunsuri

1.Implicarea utilizatorilor15,9%

2.Suportul conducerii executive13,9%

3.Declararea clara a cerintelor13,0%

4.Planificare adecvata9,6%

5.Asteptari realiste8,2%

6.Puncte de control intermediare mai apropiate7,7%

7.Personal competent7,2%

8.Proprietate5,3%

9.Viziune si obiective clare2,9%

10.Personal muncitor si concentrat2,4%

11.Altele13,9%

Participantii la sondaj au fost deasemenea ntrebati despre factorii ce cauzeaza ncercarea proiectelor (tabelul I.4).Tabelul I.4Factorii de ncercare ai proiectelorNr. crt.Factorii de ncercare ai proiectelor% din raspunsuri

1.Lipsa de input din partea utilizatorilor12,8%

2.Cerinte si specificatii incomplete12,3%

3.Schimbarea cerintelor si specificatilor11,8%

4.Lipsa suportului conducerii executive7,5%

5.Incompetenta tehnologica7,0%

6.Lipsa de resurse6,4%

7.Asteptari nerealiste5,9%

8.Obiective neclare5,3%

9.Cadre de timp nerealiste4,3%

10.Tehnologia noua3,7%

11.Altele23,0%

Opiniile despre cauzele ce duc la contramandarea proiectelor au adus pe primele locuri n lista cerintele incomplete si lipsa implicarii utilizatorilor (tabelul I.5).Tabelul I.5Factorii care conduc la contramandarea proiectelorNr. crt.Factorii de contramandare ai proiectelor% din raspunsuri

1.Cerinte incomplete13,1%

2.Lipsa implicarii utilizatorilor12,4%

3.Lipsa resurselor10,6%

4.Asteptari nerealiste9,9%

5.Lipsa suportului conducerii executive9,3%

6.Schimbarea cerintelor si specificatilor8,7%

7.Lipsa planificarii8,1%

8.Nu a mai fost nevoie de el7,5%

9.Lipsa de conducere IT6,2%

10.Necunoasterea tehnologiei4,3%

11.Altele9,9%

Motivele ce stau la baza cresterii ratei de succes a proiectelor variaza. Pentru nceput, costul mediu al unui proiect a fost redus la mai putin de jumatate. Au fost create metode si tehnici mai bune pentru a monitoriza si controla progresul proiectelor si sunt folosite procese de management mai performante conduse de manageri de proiect cu competente mult mai adecvate. Faptul ca sunt definite ca si procese este un imens pas nainte.Totusi, s-a nregistrat un numar de 137.000 de proiecte ce depasesc bugetul planificat si timpul estimat, n timp ce alte 65.000 de proiecte au esuat cu desavrsire.Motivul pentru care cele mai multe dintre acestea au esuat nu a fost lipsa banilor sau a tehnologiei, ci lipsa unei conduceri de proiect competente si a suportului conducerii executive.Lipsa suportului conducerii executive a nlocuit implicarea utilizatorilor ca si prima cauza de esec a proiectelor.O reteta pentru reusita proiectelor: The CHAOS Ten

Ce face un proiect sa reuseasca? Studiul CHAOS original, desfasurat n 1994, a identificat 10 factori de succes. Acestia au fost actualizati n anul 2000 si sunt prezentati n tabelul I.6. Chiar daca nici un proiect nu necesita ca toti cei 10 factori sa fie de succes, cu ct un numar mai mare de factori sunt prezenti n strategia proiectului, cu att nivelul de ncredere este mai ridicat.1. Suportul conducerii executive:Acesta influenteaza desfasurarea si progresul unui proiect, iar lipsa lui poate reprezenta un dezavantaj sever.2. Implicarea utilizatorilor:Chiar daca un proiect este predat n timp si n buget, el poate esua daca nu ntmpina asteptarile si nevoile utilizatorilor.3. Manageri de proiect cu experienta:97% dintre proiectele reusite au la crma un manager de proiect cu experienta.4. Obiective de afaceri clare:Acest factor se afla pe pozitia a patra, nu pentru ca este mai putin important, ci pentru ca statisticile arata ca managerii de proiect cu experienta maresc rata de succes a proiectului.5. Scop minimizat:Timpul este dusmanul tuturor proiectelor. Deoarece scopul are un impact asupra timpului, sau a duratei proiectului, ele sunt interdependente. Prin minimizarea scopului, timpul este redus si de aceea sansele de succes se maresc. Minimizarea scopului nlocuieste punctele de control mai apropiate. Acesti doi factori sunt similari, dar minimizarea scopului conduce la un succes mai mare dect crearea de puncte de control intermediare. Punctele de control intermediare sunt incluse n factorul "scop minimizat". Concentrarea asupra primilor cinci factori poate aduce pna la 70 de puncte de succes.6. Infrastructura software standard:Cerintele sunt ntr-o continua schimbare, dar infrastructura are nevoie de stabilitate. Prin utilizarea unei infrastructuri standard, echipa de dezvoltare a aplicatiei se poate concentra asupra regulilor de afaceri, mai mult dect pe tehnologie. Multe proiecte de dezvoltare a unor aplicatii esueaza nu n dezvoltarea aplicatiei care functioneaza independent, ci n integrarea aplicatiilor existente. Aici, infrastructura standard poate scurta integrarea aplicatiilor.7. Cerinte de baza ferme:Cheia ntelegerii acestui factor este cuvntul "de baza". Acesta se refera la cerintele nivelului de baza. Prin crearea unui minim de cerinte de baza, ce se poate obtine si apoi dezvoltarea acestor caracteristici, efectul schimbarii va fi diminuat. Livrarea aplicatiei cu un minim de caracteristici permite utilizatorilor si sponsorului proiectului sa vada rapid rezultatele. Un beneficiu n plus este acela ca managerii de proiect sunt mai bine pregatiti sa clarifice nevoile si prioritatile urmatoarei faze a proiectului.8. Metodologie formalizata:Managementul de proiect formalizat furnizeaza o imagine realista a proiectului si a resurselor angajate n el. Anumiti pasi (proceduri) pot fi reprodusi si reutilizati, si de aceea, efectul de reinventare a rotii este minimizat, iar consecventa proiectului este maximizata. Lectiile nvatate pot fi ncorporate n proiectele aflate n derulare. Procesul ncurajeaza un punct de control pentru a se lua o decizie de genulmergesaunu merge. O echipa de proiect poate merge mai departe cu un nivel de ncredere ridicat sau pasii (fazele) pot fi opriti sau schimbati pentru a corespunde cerintelor n schimbare. Aceasta abilitate de a se adapta n timp real sporeste abilitatile proiectului si reduce riscul acestuia. Studiul CHAOS arata ca 46% dintre proiectele reusite au folosit o metodologie formalizata, comparativ cu procentul de 30% rezultat pentru proiectele ncercate si contramandate. Astfel, putem concluziona ca acest factor ar trebui sa mareasca sansele de succes cu aproximativ 16%.9. Estimari de ncredere:A fi realist n estimari este necesar. Cum a fost mentionat mai nainte, managerii IT trebuie sa foloseasca cunostintele si experienta lor si ale persoanelor implicate pentru a ajunge la estimari ce reflecta efortul necesar cerut.10. Alte criterii:Pe ultimul loc se afla o colectie de alti factori. Acesti factori includ: puncte de control apropiate, planificare adecvata, personal competent si dreptul de proprietate. n trecut, fiecare dintre acesti factori reprezenta o categorie independenta.Folosind acest model grupul Standish evalueaza riscul proiectului. Pentru nceput este stabilit profilul proiectului si apoi sunt puse 100 de ntrebari referitoare la profil. Pentru a calcula riscul proiectului, profilul si raspunsurile sunt apoi comparate cu un set de 30.000 de studii de caz."Factorii de succes CHAOS Ten continua sa fie o unealta de valoare n estimarea potentialului de succes al proiectului. Chiar daca nu exista o formula magica ce poate garanta succesul proiectului, asigurarea prezentei factorilor CHAOS Ten poate creste sansele n favoarea unora."

Multe companii ncearca sa alinieze mai bine tehnologia cu scopurile firmei. Dar nca multe proiecte nu functioneaza. O parte din problema poate fi discrepanta dintre ideile originale si rezultatele finale. n Analiza Discrepantelor s-a studiat cum companiile gestioneaza procesul de generare a ideilor, crearea si executarea planurilor.Cine e seful?ntelepciunea conventionala spune ca individul sau grupul care are o idee originala de proiect ar trebui sa o implementeze.DiscrepantaAcesta poate fi scopul dar nu se ntmpla mereu asa. Multi directori sau comitete au idei si apoi delega responsabilitatea implementarii lor unor subordonati sau unor consultanti externi fara sa transmita valoarea strategica. Dar si ideile angajatilor pot deveni strategice pentru companie, caz n care un director preia comanda proiectului. Acesta poate fi cel mai practic mod dar de multe ori duce la esec.

Figura II.1Analiza Discrepantelor-rezultateEvident, proiectele sunt conduse diferit n functie de importanta lor pentru companie, dar este normal ca grupul sau individul care are idea sa fie implicat n implementarea proiectului si n mentinerea obiectivelor originale.MetamorfozaDaca o idee este destul de buna pentru a genera un proiect de companie, rezultatul final ar trebui sa ramna fidel conceptului original.DiscrepantaAm crede ca asa se ntmpla. Dar toata lumea cunoaste jocul de copii "telefonul fara fir" n care un copil sopteste ceva altui copil, iar acesta sopteste mai departe. Pna ajunge mesajul la ultimul copil este uneori foarte diferit de mesajul original. Desi ideile ntr-o corporatie si planurile de proiecte nu trec prin asa de multe nivele, rezultatul final este foarte diferit de ideea originala, asa cum au spus doua treimi din cei chestionati (figura II.2).

Figura II.2Analiza Discrepantelor-rezultateCnd ideile bune dau rezultate nesatisfacatoare sau proiectele esueaza din cauza executiei slabe, lipsei de conducere, lipsei de claritate, sau absentei srguintei, procesul trebuie re-examinat.Companiile trebuie sa se asigure ca acele concepte inovatoare nu sunt transformate n ceva ce nu aduce rezultate.Scopuri neclareStabilirea scopurilor este usoara; executarea este dificila.DiscrepantaCnd studiulOptimizea ntrebat de ce exista o discrepanta asa de mare ntre idea originala si rezultatul final (figura II.3) raspunsul a fost lipsa de obiective de proiect clar definite (61% din manageri). Pe lista mai erau si: lipsa investitiei n proiect (41%), utilizatorii nu sunt de acord cu ideea/modificarea idei la testarea pilot (34%), departamentul de marketing a modifiat directia proiectului (30%), management de proiect defectuos (28%).

Figura II.3Analiza Discrepantelor-rezultateStabilirea unor obiective clare este un pas important n orice proiect, mai ales daca este strategic pentru companie. Determinarea initiala a ceea ce proiectul trebuie sa faca, a costurilor, a termenului limita pentru finalizare si a modului de evaluare - si comunicarea acestora tuturor celor implicati - mareste sansele de succes.Management selectiv?Pentru a avea o sansa mai mare de succes proiectele ar trebui sa fie bine documentate, planificate si executate.DiscrepantaCam 2/3 din manageri au spus ca proiectele selectate de afaceri si cele tehnologice din compania lor sunt riguros documentate, planificate si executate. Doar 13% au spus ca toate proiectele sunt tratate n acest mod, iar 20% au spus ca majoritatea proiectelor sunt tratate ad hoc fara cercetari, planificari sau executii riguroase (figura II.4).Figura II.4Analiza Discrepantelor-rezultaten mod sigur nu toate proiectele sunt cntarite n valoare strategica pentru companie. Totusi, o buna analiza, planificare si executie ar trebui sa faca parte din orice proiect. Proiectele de afaceri si IT pot sa esueze din mai multe motive, inclusiv finantare inadecvata, schimbari de personal sau o conducere inadecvata; dar o cercetare si o planificare initiala sunt obligatorii pentru atingerea obiectivelor.Rasplata meritataCompaniile rasplatesc angajatii care sunt responsabili pentru executarea unor proiecte de succes.DiscrepantaAstazi multi angajati se multumesc doar sa ia un salariu. Chiar si asa, studiul arata ca organizatiile platesc bonusuri celor ce executa cu succes proiecte si ating anumite obiective (figura II.5).

Figura II.5Analiza Discrepantelor-rezultate