Managementul Proiectelor

Curs 3

Executia Proiectului

• Managementul continutului• Managementul problemelor• Managementul riscurilor• Managementul Indicatorilor• Managementul calitatii• Managementul documentelor• Managementul resurselor umane• Managementul comunicarii

Managementul continutului

• Continutul (sfera de cuprindere) este modalitatea de a descrie granitele proiectului. Descrie ceea ce va livra si ceea ce nu va livra proiectul. Pentru proiectele mari, poate include organizatiile afectate, tranzactiile afectate si alte informatii implicate, etc.

• Invocarea procesului de schimbare a continutului implica faptul ca schimbarea este in afara continutului convenit in Definitia Proiectului si in detalierea cerintelor de business.

• Daca continutul este ambiguu sau lasa loc de interpretari, clientul poate pretinde ca schimbarea este in limitele continutului si managerul de proiect va avea dificultati in a sustine managementul acestuia.

• Scopul managementului schimbarilor asupra continutului este protejarea viabilitatii Definitiei Proiectului in varianta curenta si aprobata, precum si a cerintelor aprobate de business.

• Managerul de proiect poate crede ca managementul continutului inseamna sa spuna “nu” clientului. Aceasta il face pe managerul de proiect sa se simta nervos si discomfortabil. Oricum, vestea buna este ca un management eficace al continutului consta in arta de a-l face pe Sponsor sa spuna “nu”.

De vreme ce proiectele mici sunt mult mai usor de definit si de obicei sunt incheiate foarte repede, ele nu au cerinte pentru schimbari majore ale sferei de cuprindere a proiectului.Daca insa se produc, acestea sunt modificari minore. Urmatorul proces ar trebui sa poata fi urmat rapid:– Schimbarile asupra continutului pot fi initiate de oricine din echipa

proiectului. Acestea trebuie trimise in scris managerului de proiect, fie pe hirtie, fie prin email, etc. Nu este necesar un formular tipizat.

– Managerul de proiect valideaza daca cererea este cu adevarat o modificare asupra continutului. In caz afirmativ, se executa restul procesului.

– Managerul de proiect determina impactul schimbarii asupra continutului, in ceea ce priveste costul, efortul si durata. Daca exista si alte optiuni viabile, managerul proiectului determina de asemeni impactul acestora.

– (Optional) Daca cererea de schimbare poate fi realizata in limitele costului, efortului si duratei initiale, managerul de proiect si managerul din partea clientului au flexibilitatea de a decide daca schimbarea trebuie aprobata. Oricum, sponsorul trebuie sa fi aprobat delegarea acestei responsabilitati, de obicei pina la o anumita limita in ceea ce priveste banii si efortul.

– Analiza, alternativele si impactul sunt prezentate Sponsorului Proiectului pentru rezolutie (daca cererea nu a fost deja aprobata in pasul 4). Daca sponsorul nu aproba cererea si impactul acesteia, nu se da curs cererii de schimbare a continutului.

– Din momentul in care rezolutia este convenita, activitatile corespunzatoare sunt adaugate in planul de lucru pentru a asigura implementarea cererii.

– Cererea, starea curenta si rezolutia trebuie documentate in Raportul asupra Starii Proiectului.

Managementul Continutului / Tehnici

• Controlul cererii minore de schimbare a continutului -Toata lumea recunoaste si apreciaza ca procesul de gestionare a cererilor de schimbare trebuie invocat pentru schimbarile mari asupra proiectului. – Cu toate acestea, este posibil sa intimpini rezistenta daca vrei sa impui

un proces formal de management al schimbarilor continutului pentru schimbarile minore. Clientul poate considera ca nu este necesara o asemenea supraincarcare pentru decizii minore.

– Exista trei tehnici care se pot folosi in cazul schimbarilor minore. Nici una dintre acestea nu implica si nu sugereaza ca nu se aplica managementul si urmarirea schimbarilor asupra continutului. Sunt doar tehnici suplimentare.

– Daca nici una dintre aceste optiuni nu este aplicata, managerul de proiect trebuie sa utilizeze procesul normal de management al schimbarii continutului, pentru toate schimbarile.

1. Agregarea cererilor minore - Nu intotdeauna este practic sa soliciti sponsorului aprobarea tuturor cererilor minore de schimbare. Echipa proiectului nu are de obicei acces la Sponsor in fiecare zi si este foarte greu sa-i retina acestuia atentia pentru multe cereri minore. Este mai bine ca acestea sa fie agregate in pachete. – Aceasta inseamna ca se tine evidenta tuturor schimbarilor

minore, valoarea lor de business si impactul lor asupra proiectului. Apoi, cind volumul lor atinge un anumit nivel, sunt prezentate Sponsorului pentru aprobare.

– Chiar daca acestea sunt considerate schimbari minore, tot trebuie supuse managementului schimbarilor asupra continutului. Altfel, exista riscul dilatarii continutului. Beneficiul aprobarii schimbarilor minore este aprobarea si a modificarilor corespunzatoare de buget si timp pentru implementarea lor.

2. Hotarirea managerului de proiect - Din punct de vedere practic, de obicei este bine ca managerul de proiect si managerul din partea clientului sa aiba libertatea de a aproba cererile minore de schimbare, pina la limita unui anumit prag de cost si ore de efort. Oricum, aceasta abordare presupune ca proiectul se afla in program sau inaintea programului si ca schimbarile nu conduc la depasirea costurilor, efortului sau duratei agreate.

– Daca proiectul intimpina riscul neindeplinirii angajamentelor privind costul, durata si efortul, aceasta libertate nu ar trebui utilizata, chiar daca este vorba de cereri de schimbare care necesita doar o ora.

– Daca exista acest risc al neindeplinirii angajamentelor, toate cererile de schimbare a continutului trebuie sa treaca pe la sponsor pentru aprobare, individual sau in pachete.

– Daca Sponsorul aproba schimbarile, proiectul ar trebui sa beneficieze de majorari corespnzatoare ale bugetului si termenului.

3. Rezerva bugetara pentru schimbarile continutului). In unele organizatii este o practica comuna alocarea unei rezerve bugetare dedicata schimbarilor continutului, pentru a face fata cererilor minore. De obicei nu este necesara nici o justificare. Organizatia poate admite ca exista intotdeauna o serie de schimbari ale continutului si poate aloca un procent din bugetul total al proiectului pentru a le cuantifica. Spre exemplu, poti avea o rezerva de 5% adaugata la buget pentru schimbari asupra continutului. Daca bugetul total este $500.000, rezerva bugetara pentru schimbari va fi $25.000.

– Implicatia directa a acestei variante este ca aceasta rezerva bugetara reprezinta tot ce se aloca pentru cereri de schimbare minore. Clientul trebuie sa gestioneze bugetul pentru a putea fi sigur ca toate cererile minore de schimbare pot fi realizate. Daca se foloseste toata rezerva inca de la inceputul proiectului, nu mai ramine nimic pentru a se putea rezolva cererile care intervin mai tirziu.

– Aceasta il obliga pe client sa evalueze foarte atent schimbarile pentru a fi sigur ca numai cele mai importante sunt aprobate. Aceasta rezerva bugetara este folosita doar pentru cereri de schimbare situate sub un anumit prag, exprimat in bani sau ore. In continuare se pot face si schimbari majore, dar acestea trebuie sa parcurga procesul normal de management al schimbarilor continutului si trebuie evaluate de catre Sponsor.

Nu se utilizeaza rezerva de estimare pentru schimbari ale continutului

• Unul din pasii procesului de estimare a fost adaugarea unei rezerve de ore pentru a reflecta nivelul de incertitudine asociat cu estimarea (spre exemplu, daca s-au estimat 5.000 de ore de efort, se pot adauga 500 de ore ca rezerva, ceea ce reflecta un factor de incredere de 90%). Odata ce rezerva este aprobata, managerul de proiect va fi presat sa o foloseasca pentru a absorbi in proiect cerinte suplimentare. Clientul poate spune “De ce trebuie sa invocam managementul schimbarilor asupra continutului pentru o majorare cu 100 de ore? Avem o rezerva de 500 de ore incorporata in estimare!”.

• Managerul de proiect trebuie sa reziste tentatiei si presiunii. Scopul rezervei de estimare este de a reflecta incertitudinea asupra estimarilor. Vor exista o sumedenie de ocazii pentru utilizarea rezervei cind activitatile vor dura mai mult decit s-a prevazut. Nu folosi rezerva de estimare pentru a accepta lucrari suplimentare. Daca estimarile au fost precise, rezerva va fi inapoiata clientului la finalizarea proiectului (Sau se poate considera ca rezerva se constituie in profit suplimentar, daca este vorba de un client extern.)

Inghetarea cererilor de schimbare asupra continutului

• In functie de natura proiectului, aceasta inghetare poate fi implementata la momente diferite, dar de obicei nu se face mai tirziu de testarea sistemului. La acest moment, echipa trebuie sa se poata focaliza pe testarea riguroasa a solutiei curente. Schimbarile suplimentare pot rezulta in necesitatea de a reface toate testele. Pina la momentul efectuarii testarii sistemului, ar trebui sa fi luat in calcul marea majoritate a cerintelor.

• Se intimpla curent ca unele cereri de modificare sa rezulte din testarea pentru acceptare de catre utilizator. Clientul poate observa diverse lucruri pe care le doreste schimbate, ca urmare a testelor. O abordare mai buna este suspendarea acestor schimbari intr-un jurnal si tratarea lor ca cereri de extindere dupa ce solutia este implementata si stabila (aceasta se refera la cereri de schimbare, nu la defecte. Utilizatorul poate descoperi defecte si erori in cursul testelor pe care le realizeaza, care trebuie eliminate inainte de implementare).

Doar Sponsorul poate aproba schimbarile – Nu utilizatorii si managerii din partea clientului

• In conformitate cu un management corespunzator al schimbarilor continutului, Sponsorul (sau reprezentantul acestuia) poate da aprobarea.

• Utilizatorii proiectului pot cere modificarea sferei de cuprindere dar nu o pot aproba.Utilizatorul final nu poate aloca finantare suplimentara pentru acoperirea schimbarii si nu poate stii daca impactul asupra proiectului este acceptabil.

• Daca schimbarea este suficient de importanta pentru Sponsor, acesta o va aproba impreuna cu modificarile corespunzatoare asupra bugetului si duratei. Daca schimbarea nu este suficient de importanta, nu o va aproba.

• Oricum, Sponsorul este cel care va lua decizia, nu managerul de proiect, managerul din partea clientului, echipa de proiect sau utilizatorii finali.

A spune “Da” cererilor de schimbare a continutului arata orientarea catre client?

• Managerul de proiect si echipa considera uneori ca sunt orientati catre client daca accepta schimbari ale continutului, incercind in acelasi timp sa livreze in parametrii angajamentelor initiale.

• Oricum, daca proiectul va fi livrat cu intiziere si cu depasire de buget, de obicei nu este suficient sa arati toate activitatile suplimentare care s-au facut in numele “orientarii catre client”.

• In cele mai multe cazuri, proiectul nu va fi considerat un succes, de moment ce nu a fost livrat in bugetul si la termenul promise.

• Sponsorul reprezinta clientul primar.Orientarea catre client este demonstrata dindu-i Sponsorului ocazia sa ia deciziile asupra schimbarilor continutului.

• Daca echipa sau managerul de proiect aproba singuri schimbari ale continutului, nu demonstreaza orientarea catre client, mai ales daca proiectul se incheie cu intirziere si cu depasire de buget.

Oricine este responsabil pentru procesul de management al continutului

• Multe procese de management al continutului merg bine la nivelul managerului de proiect, dar sunt compromise la nivelul echipei.

• Daca managerul de proiect este eficient in impunerea regulilor de schimbare a continutului, clientul poate incerca sa discute schimbarile direct cu membrii echipei. Spre exemplu, atunci cind se livreaza spre analiza un raport convenit anterior, clientul poate solicita un al doilea raport pentru a obtine mai multe clarificari. Un membru al echipei poate fi de acord sa faca aceasta munca (pentru a dovedi “orientare catre client”). Rezultatul este ca activitatea dureaza prea mult sau resursele care trebuiau utilizate la activitati cu prioritate mai mare sunt absorbite intr-o munca aflata in afara continutului.

• Ideea centrala este ca toata lumea trebuie sa fie raspunzatoare pentru procesul de management al continutului. Membrii echipei trebuie sa inteleaga procesul si motivele pentru care acesta este important. Clientii trebuie sa inteleaga de asemeni procesul si importanta lui. Ar fi o greseala sa consideri ca aceste proceduri sunt de interes doar pentru managerul proiectului si pentru Sponsor. Asigura-te ca procedurile sunt comunicate intregii echipe.

• Atunci cind clientul solicita direct membrilor echipei schimbari ale continutului, supune acest lucru atentiei managerului din partea clientului si sponsorului. Atunci cind membrii echipei se angajeaza la lucrari care sunt in afara continutului, reactioneaza prompt. Cind se intimpla prima oara, poate fi considerata o problema de instruire. Data viitoare s-ar putea sa fie o problema de performanta.

Acumularea cererilor de schimbare

• Este posibil ca Sponsorul sa nu aprobe cereri de schimbare in timpul proiectului, dar acestea pot fi cerinte viabile care pot fi puse in practica mai tirziu.

• Acest tip de cereri de schimbare trebuie acumulate intr-o lista.

• Dupa terminarea proiectului, cind solutia trece in productie, pot exista ocazii pentru imbunatatiri sau pentru o a doua faza a proiectului.

• Aceste schimbari vor fi implementate numai daca sunt aprobate si daca exista finantare.

Managementul Continutului / Livrabile

Dimensiunea proiectului Informatii Necesare

Mica

Pentru proiectele mici, cererile de schimbare ale continutului si starea lor curenta trebuie identificate in Raportul asupra Starii Proiectului. Deoarece de obicei nu sunt cereri majore de schimbare a continutului in proiectele mici, nu sunt necesare livrabile specifice pentru managementul schimbarilor continutului. Oricum, revizuieste Jurnalul Schimbarilor Continutului utilizat in proiectele medii si mari. Poate fi util in cazul schimbarilor multiple asupra continutului.

Managementul Continutului / Activitati suplimentare privind Planul de Lucru

Managementul Problemelor (Situatiilor dificile)

• O situatie dificila este definita ca o problema care impiedica progresul proiectului si nu poate fi rezolvata de catre managerul de proiect si echipa proiectului, fara ajutor extern.

• Managementul situatiilor dificile este unul din procesele fundamentale si constituie una dintre abilitatile pe care toti managerii de proiect trebuie sa le stapineasca.

• Majoritatea proiectelor de orice dimensiune intimpina situatii dificile. Acestea nu pot fi ignorate si nu pot fi aminate pentru mai tarziu. Situatiile dificile trebuie rezolvate rapid si eficace.

• In general, nu ne asteptam ca proiectele mici sa intimpine situatii cu adevarat dificile. Pot aparea probleme, dar acestea sunt de obicei rezolvate rapid. Oricum, daca apare o situatie dificila care nu poate fi rezolvata cu usurinta, trebuie utilizat procesul urmator:

1. Problemele pot fi ridicate de catre orice membru al echipei. Acestea trebuie transmise in scris managerului de proiect fie pe hirtie, fie prin email, etc. Nu este necesar un formular tipizat.

2. Managerul de proiect determina daca problema poate fi rezolvata sau este clasificata ca o situatie dificila.

3. Managerul de proiect pregateste un plan pentru rezolvarea situatiei si determina optiuni daca pot exista mai multe cai de actiune. Trebuie identificat si impactul asupra planului de lucru al proiectului.

4. Managerul de proiect trebuie sa prezinte analiza, impactul si alternativele catre Sponsorul proiectului si alti participanti pentru discutare si rezolvare.

5. Daca rezolutia situatiei necesita o modificare a continutului, trebuie invocata procedura de management al schimbarilor continutului pentru proiecte mici, pe baza informatiilor colectate.

6. Odata ce rezolutia este convenita, actiunile corective potrivite sunt adaugate in planul de lucru pentru a ne asigura ca situatia este rezolvata.

7. Situatia dificila, starea curenta si rezolutia trebuie documentate in Raportul de Stare a Proiectului.

Managementul Problemelor / Tehnici

• Analiza Cauza-Efect– Aceasta tehnica pentru rezolvarea problemelor reprezinta o

modalitate de analiza a problemelor complexe care par a avea mai multe cauze interdependente. Unul dintre aspectele cheie ale acestei tehnici este folosirea diagramei cauza-efect. Datorita felului in care arata diagrama, aceasta tehnica este de asemeni numita si Diagrama Os de Peste (Fishbone Diagram). Un alt nume al acestei tehnici este Diagrama Ishikawa. Acest nume provine de la Prof. Kaoru Ishikawa, un japonez care a fost primul utilizator al acestei diagrame, in 1943.

– Beneficiile acestei tehnici includ:• Permite explorarea diferitelor categorii de cauze. • Incurajeaza creativitatea prin intermediul procesului de

brainstorming. • Furnizeaza o imagine grafica a problemei si a potentialelor categorii

de cauze.

Dezvoltarea diagramei Fishbone • Deseneaza o linie orizontala directionata catre caseta cu problema. Aceasta sageata va servi

drept coloana vertebrala, pornind de la care cauze majore sau minore vor fi categorisite si relationate.

• Identifica cauze potentiale si grupeaza-le in categorii principale. Exemple de categorii majore includ oamenii, procesele, materiale, echipamente, mediu, etc. Categoriile principale sunt identificate prin tehnica brainstorming, deci in acest punct nu te intereseaza daca participantii nu sunt de acord asupra carei categorii contine cauza majora. Asigura-te ca exista suficient spatiu intre ele pentru a putea adauga cauze individuale mai tirziu. Fiecare dintre aceste categorii majore va fi explorata in detaliu.

• Continua brainstorming-ul asupra cauzelor prin analiza detaliata a explicatiilor pentru fiecare categorie principala identificata. Scrie cauza detaliata pe o linie oblica conectata la categoria principala corespunzatoare.

• Uneori, cauza detaliata poate avea alte cauze, cu o granularitate crescuta. In acest caz, conecteaza liniile suplimentare cu liniile de detaliu. In mod uzual, trei niveluri de detaliere sunt limita practica a acestei diagrame.

• Atunci cind brainstorming-ul asupra categoriilor principale si a cauzelor detaliate s-a incheiat, incepe analiza informatiilor. Evalueaza fiecare cauza majora si potentialele cauze detaliate asociate cu aceasta. Retine ca lista initiala a fost realizata prin brainstorming, in care se include toate ideile aparute. Acum trebuie determinate elementele care par a fi cauzele cele mai probabile (sau una dintre acestea). Incercuieste elementele cele mai promitatoare in acest sens, pentru investigarea ulterioara.

• Daca nu exista consens asupra domeniilor principale de investigatie, foloseste un sistem oarecare de votare pentru a ingusta gama catre alternativele cu cele mai multe sanse de succes.

• Pentru fiecare element incercuit, analizeaza impactul asupra problemei. • Creaza un plan de actiuni pentru rezolvarea cauzei incercuite. Retine ca pot fi mai multe cauze potentiale

care interactioneaza in crearea problemei. Planul de actiune trebuie sa ia in considerare aceste interdependente. In situatia in care cauzele detaliate sunt in continuare complexe, sau nu exista suficiente informatii, acestea pot fi atribuite pentru analiza ulterioara uneia sau mai multor persoane.

Analiza Cauzei Radacina

• Managerul unei fabrici inspecteaza o linie de asamblare si observa la un moment dat o balta pe podea. Stiind ca apa reprezinta un risc pentru siguranta, ii cere supraveghetorului sa cheme pe cineva pentru a sterge apa.

• Managerul se simte mindru ca a rezolvat o problema legata de siguranta fabricii.

• Supraveghetorul cauta cauzele intrebindu-se “de ce?” El descopera ca balta provine de la o conducta supraincarcata. Se intreaba din nou “de ce?” si descopera ca scurgerea este din cauza presiunii prea mari a apei. Se intreaba inca o data “de ce?” si descopera ca supapa de presiune a apei este defecta. Desi se mai intreaba inca o data “de ce?”, nu poate gasi un raspuns. Asadar, supapa este inlocuita si astfel se rezolva simptomul scurgerii apei in fabrica.

• Analiza cauzei radacina se face printr-o serie de intrebari de tipul “de ce?”. Ca si in exemplul anterior, intreaba-te “de ce” exista problema. Apoi descoperi una sau mai multe cauze. Pentru fiecare din aceste cauze, intreaba-te din nou “de ce?”. Daca poti raspunde din nou la intrebare, inseamna ca primul raspuns este probabil un simptom. Continua cu intrebarea “de ce” pina cind nu mai poti gasi un raspuns logic.

• Acest ultim nivel este cel mai probabil sa reprezinte cauza radacina care a generat simptomele observabile. Prin analiza, poti descoperi mai mult de o cauza radacina.

• Dupa ce ai identificat cauzele radacina, pregateste un plan de actiuni pentru rezolvarea problemei. Simptomele ar trebui sa dispara.

Analiza Pareto

• Analiza Pareto poate fi folosita atunci cind intimpini mai multe probleme cu legaturi intre ele sau cind o problema are mai multe cauze.

• Cu ajutorul acestei tehnici se pot de asemeni colecta metrici despre frecventa aparitiei problemei sau a cauzei.

• Scopul analizei Pareto este observarea problemelor si determinarea frecventei lor de aparitie.

• Aceasta furnizeaza informatiile necesare pentru prioritizarea efortului, pentru a fi sigur ca timpul se foloseste cu impact maxim

• Analiza Pareto se bazeaza pe regula clasica 80/20. Acest lucru inseamna ca 20% din cazuri cauzeaza 80% probleme.

• Sa presupunem ca ai o problema cu defectul unui produs, bazata pe un numar de cauze. Prin observarea si colectarea metricilor, rezulta ca sunt opt cauze. In loc sa ataci la intimplare aceste cauze, analiza Pareto iti poate arata ca 80% dintre probleme sunt create de primele trei cauze.

• Unealta pentru aceasta tehnica este diagrama Pareto. Este un grafic, sau o histograma care arata fiecare problema si frecventa ei de aparitie. Se creaza astfel:

1. Se creaza un tabel in care se listeaza toate problemele sau cauzele observate.

2. Pentru fiecare problema, identifica numarul de aparitii intr-un interval fixat de timp.

3. Sorteaza problemele in ordine descrescatoare, pe baza numarului de aparitii.

• Adauga o coloana pentru totalul cumulativ. (Frecvenţa cumulată a fiecărei categorii reprezintă frecvenţa acelei categorii adăugată frecvenţelor tuturor categoriilor superioare)

Sarcini

• Rezolva Situatiile Dificile cit mai curind posibil

• Incearca sa rezolvi cauza radacina, nu doar simptomele

• Alege raul cel mai mic

Managementul Problemelor / Livrabile

Managementul Problemelor / Activitati suplimentare privind Planul de Lucru