TenStep - Servicii de Consultanta si Training pentru Managementul Proiectelor, Bucuresti

De cate ori n-ai auzit sau n-ai fost implicat intr-un proiect care a esuat lamentabil? Sau poate doar nu a fost atat de performant pe cat trebuia. Ai investit vreodata timp sa analizezi retrospectiv ce a determinat proiectul sa evolueze pe calea gresita? Daca da, este posibil sa fi spus: "Ar fi trebuit sa investim mai mult timp in planificare".Majoritatea proiectelor au termene limita si se pare ca acestea devin tot mai scurte. Tintirea unor termene limita agresive il preseaza pe managerul de proiect sa demareze proiectul cat mai curand posibil. Totusi, inainte de a incepe munca trebuie sa investesti timp in planificarea preliminara pentru a te asigura ca activitatile sunt intelese corect si convenite. Acesta nu este un timp pierdut sau o ‘supraincarcare'. Este timpul investit de managerul de proiect pentru a se asigura ca echipa de proiect si clientul au perceptii comune asupra livrabilelor proiectului, termenului de livrare, costurilor, responsabilitatilor si modalitatilor de executie a activitatilor.

La finalul unui proiect dificil, beneficiile planificarii ar putea fi evidente. Dar beneficiile sunt cunoscute chiar dinainte. La un nivel general, aceste beneficii includ:

• Intelegerea si obtinerea acordului asupra obiectivelor proiectului, livrabilelor, sferei de cuprindere, riscurilor, costurilor, abordarii, etc. (din Documentul de Definire a Proiectului). Prin aceasta se asigura pur si simplu acordul dintre echipa de proiect si sponsor asupra muncii necesare.
• Se determina daca scenariul de business original mai este inca valid. La momentul aprobarii initiale a proiectului, costurile si durata au fost probabil estimate la un nivel general - probabil in limita a ± 50%. Acum, la demararea proiectului, estimarile trebuie revalidate astfel incat sa se apropie de marja de ± 10%. Aceasta rafinare suplimentara poate determina obtinerea unor estimari mai mari iar acestea pot face scenariului de business neatractiv. De exemplu, un proiect care presupune un efort de10,000 de ore ar putea avea sens din punct business. Daca procesul de planificare mai detaliata determina rafinarea estimarii la 20,000 de ore, proiectul ar putea sa nu mai aiba sens din punct de vedere business.
• Asigurarea disponibilitatii resurselor atunci cand ai nevoie de ele. Aceasta este determinata de intelegerea organizatiei ce deruleaza proiectul si de elaborarea programului de activitati incluzand alocarea resurselor.
• Furnizarea unui nivel general de referinta in raport cu care se poate compara evolutia. Aceasta este determinata de elaborarea unui cadru temporal al reperelor intermediare in baza programului de activitati mai detaliat.
• Validarea incipienta a proceselor utilizate pentru managementul proiectului impreuna cu clientul. Procedurile utilizate pentru managementul proiectului trebuie discutate si explicate clientilor si membrilor echipei.

Ar trebui sa fie logic ca proiectele de mica anvergura necesita un ciclu de planificare mai scurt iar cele de mare anvergura un ciclu de planificare mai lung. Efortul necesar planificarii proiectului depinde de volumul informatiilor si de gradul de detaliere ce trebuie intelese si documentate. Durata necesara definirii proiectului depinde de timpul necesar pentru descoperirea si documentarea informatiilor precum si pentru obtinerea acordului si aprobarii clientului. Uneori, managerul de proiect poate deveni frustrat din cauza dificultatii de a obtine acordul clientului asupra sferei de cuprindere, programului de activitati si costurilor proiectului. Dar tocmai din acest motiv aceste lucruri trebuie facute dinainte. Gandeste-te la problemele ce le vei intampina incercand sa obtii acordul clientului asupra sferei de cuprindere, programului de activitati sau costurilor cand proiectul a inceput deja iar livrabilele sunt produse efectiv.

1.0.P2 Inainte de Inceperea Ciclului de Viata 

Inainte de inceperea ciclului de viata al proiectului (analiza, proiectare, constructie, etc.), o serie de elemente ale procesului de planificare trebuie sa fie stabilite. In cazul proiectelor mai mici, multe din aceste conditii sunt indeplinite informal sau implicit. Totusi, cu cat proiectul este mai mare, cu atat este mai important ca aceste criterii sa fie indeplinite formal si explicit.

• Clientul aproba demararea planificarii. In mod normal, se presupune ca proiectul a ajuns pana in acest stadiu in urma unei aprobari implicite. Totusi, daca nu a fost pregatit un scenariu de business pentru proiect si daca acesta nu a parcurs un proces de autorizare, atunci inainte de a incepe planificarea proiectului, trebuie cautata o aprobare explicita.
• Proiectul este definit in mod formal. Aceasta se documenteaza in Documentul de Definire a Proiectului, care cuprinde obiectivele, sfera de cuprindere, presupunerile, livrabilele, bugetul, etc. (In cazul proiectelor medii sau mici poate fi vorba despre Documentul de Definire Abreviata a Proiectului sau Cererea de Serviciu.)
• Programul de activitati al proiectului este creat. Un program de activitati trebuie pregatit si utilizat pentru managementul efortului. Acesta include puncte de verificare sau repere intermediare la care proiectul poate fi evaluat pentru a fi siguri ca este potrivit sa continue.
• Clientul aproba inceperea proiectului. Aceasta este consemnata prin Documentul aprobat de Definire a Proiectului. Sponsorul trebuie sa semneze documentul pentru a asigura acordul.
• Procedurile de management de proiect sunt definite si aprobate. Proceduri trebuie instituite pentru a descrie modalitatile in care managerul de proiect va realiza managementul problemelor, al comunicarii, riscurilor, calitatii, sferei de cuprindere, etc. Aceasta este in special valida pentru proiectele mari si mai putin importanta pe masura ce proiectele scad in dimensiuni.
• Resursele echipei de proiect sunt alocate. Trebuie sa dispui de oamenii potriviti pentru a executa proiectul. Uneori proiecte valide si aprobate trebuie intarziate pentru ca oamenii cu abilitatile potrivite nu sunt disponibili.

1.0.P3 Intelegerea Proiectelor 

Inainte de a invata cum se defineste munca dintr-un proiect trebuie clarificata definitia teoretica a proiectului in sine. Astfel se va intelege mai clar cand sunt necesare tehnici formale de management de proiect. Astfel, este indicat sa revizuiesti:

• 1.0.1 Ce este un Proiect?
• o 1.0.1.1 Momentele de Start si de Final ale Proiectului
• 1.0.2 Managementul Proiectelor vs. Ciclul de Viata al Proiectului
• 1.0.3 Managementul de Proiect vs. Managementul de Produs
• 1.0.4 Rolul Managerului de Proiect.

Procesele folosite in managementul de proiect trebuie sa fie scalabile in functie de dimensiunea proiectului. Proiectele de mare anvergura trebuie conduse mai riguros si mai structurat decat cele de mica anvergura.

1.0.P4 Dimensionarea Proiectului (Mic, Mediu, Mare)

Procesul TenStep contine indrumare specifica pentru managementul proiectului in functie de dimensiunea lui. Dar la inceput trebuie sa-ti clasifici proiectul. In unele companii, un proiect de sase luni si 10,000 de ore ar putea fi considerat un proiect de mare anvergura. In alte organizatii, acelasi proiect ar putea fi considerat un proiect de mica anvergura. Noi am furnizat cateva indicatii generale dar fiecare organizatie trebuie sa determine indicatiile care au sens pentru ele.

1.0.5 Dimensionarea Proiectului tau (Mic, Mediu, Mare)

Dupa ce ai revizuit informatiile anterioare, continua cu informatiile privind definirea proiectului tau.

1.1 Definirea Proiectului / Procesul

1.2 Definirea Proiectului / Technici

1.3 Definirea Proiectului / Breviar

Managerul de proiect nu va succes daca nu mentine programul de activitati la zi. A se retine ca programul de activitati este doar un livrabil. Programul de activitati cuprinde activitatile de realizat, ordinea acestora, efortul necesar etc. Managementul programului de activitati presupune intelegerea activitatilor, cunoasterea persoanelor responsabile de activitati, cunoasterea termenele limita etc.

Programul de activitati ar trebui sa reprezinte cele mai bune estimari, in orice moment al proiectului, despre activitatile ce trebuie realizate. Cu cat complexitatea unui proiect este mai mare cu atat vor fi modificate estimarile pe durata acestuia. De aceea managementul programului de activitati este o abilitate importanta a managementului proiectului. Managerul proiectului evalueaza programul de activitati continuu (de obicei saptamanal) si determina starea curenta a proiectului. In functie de aceasta si intelegerea activitatilor ramase va fi necesara restabilirea sirului de activitati astfel incat acestea sa fie terminate in bugetul si la termenul limita initial.

In majoritatea proiectelor programul de activitati va trebui revizuit saptamanal. In cadrul acestei analize managerul proiectului updateaza programul de activitati cu sarcinile completate sau in curs de desfasurare. Activitatile ramase ar trebui evaluate astfel incat proiectul sa fie terminat in efortul, costul si durata estimate initial. Actiuni corective sunt aplicate in caz ca estimarile sunt depasite.

Managementul programului de activitati este una dintre abilitatile fundamentale necesare managementului proiectelor. In functie de dinamica proiectului managerul va trebui sa-si foloseasca experienta si creativitatea pentru a-l termina la timp. O saptamana proiectul poate rula conform planului insa in urmatoarea pot exista activitati amanate si situatii dificile.  Daca o activitatea critica a intarziat cu o saptamana, managerul proiectului nu poate permite ca intregul proiect sa intarzie cu o saptamana. Managerul proiectului trebuie sa evaleze resursele si optiunile disponibile pentru a readuce proiectul la zi. Managementul programului de activitati este unul dintre cele mai interesante si lucrative aspecte ale managementului proiectelor. Unui manager de proiect ii va fi greu sa obtina succes daca nu este atras de munca minutioasa. 

3.0.P2 Integrarea Proiectului si a Proceselor Managementului de Proiect

In Pasul  1 - Definirea Activitatilor, nu se definesc numai caracteristicile proiectului ci si Planul Managementului Proiectului pentru managementul acestuia. Acest plan include procesele pentru managementul scope-ului, managementul riscului, managementul comunicarii, managementul calitatii etc.

Odata ce proiectul este  executat toate procesele managementului de proiect sunt integrate in Managementul Programului de Activitati si a  Bugetului. Integrarea are loc aici deoarece filozofia proceselor  TenStep spune " Activitatile prezente in programul de activitati se realizeaza!". Cu alte cuvinte daca o activitate nu se afla in programul de activitati, aceasta nu va fi realizata.

 (insert picture)

Programul de activitati este punctul central al managementului proiectelor si al proceselor managementului proiectelor integrate in programul de activitati.  In cadrul programului de activitati ar trebui sa fie alocate activitati si timp pentru comunicare, managementul scope-ului, updatarea  programului de activitati si a celorlalte activitati din cadrul proiectului. Integrarea are loc cand procesele managementului proiectelor se intersecteaza sau cand managementul proiectului si ciclul de viata al acestuia se suprapun.

• Schimbarea majora aprobata a scope-ului ce va duce la cresterea efortului si a costurilor reprezinta un exemplu caracteristic a integrarii managementul proiectului cu ciclul de viata al proiectului. Impactul se va reflecta in programul de activitati updatat si in buget.
• Se identifica riscurile si se creeaza Planul Managementului Riscurilor. Planul rezultat va fi comunicat tuturor participantilor la proiect pentru feedback. Aceasta reprezinta o sinteza intre managementul riscurilor si managementul comunicarii. Deoarece toate aceste activitati dureaza, vor fi incluse in programul de activitati, iar integrarea are loc in acest pas.
• Apare o situatie dificila cu calitate redusa. Procesele Mangementului Situatiilor Dificile sunt folosite si toate activitatile potrivite sunt adaugate programului de activitati. Pentru rezolvarea problemei se decide adunarea mai multor indicatori, activitatile de colectare a indicatorilor fiind adaugate programului de activitati. Analiza indicatorilor duce la modificarea proceselor de munca si la adaugare de activitati de verificare a calitatii sarcinilor. Astfel toti participantii la proiect vor fi atenti la respectarea estimarilor. Toate aceste activitati vor fi cuprinse in programul de activitati si buget.

Toate activitatile proiectului ar trebui sa fie reflectate in programul de activitati si buget. Prin urmare acest pas se refera la managementul si controlul proiectului si cuprinde executarea, urmarirea si integrarea activitatilor corespunzatoare ciclului de viata al proiectului dar si a managementului proiectelor.

3.0.P3 Demararea si Incheierea Proiectului

Programul de activitati reprezinta coordonata principala in managementul si controlul proiectului. Dupa definirea si planuirea proiectului incepe executia acestuia, urmand ca livrabilele sa fie realizate. Aceste activitati sunt cunoscute ca ciclul de viata al proiectului. Ciclul de viata este inconjurat de doua evenimente - o intalnire pentru demararea oficiala a executiei proiectului si o serie de activitati de final pentru incheierea oficiala a acestuia. Ambele evenimente sunt descrise mai detaliat in cadrul acesei sectiuni. ( Vezi 3.1.3.1 Demararea Proiectului si  3.1.3.2 Incheierea Proiectului) 

3.1 Managementul Programului de Activitati si a Bugetului / Procese

3.2 Managementul Programului de Activitati si a Bugetului / Tehnici

3.3 Managementul Programului de Activitati si a Bugetului / Referinte Rapide

O situatie dificila este o problema definita formal care va impiedica progresul proiectului si nu poate fi in totalitate rezolvata de catre managerul de proiect si echipa fara ejutor exterior. 

Daca o problema pe care managerul de proiect si echipa nu o pot rezolva apare, este doar unul dintre multele focuri care se vor aprinde si vor fi stinse intr-o saptamana. Totusi, o „situatie dificila " apare daca problema impiedica progresul proiectului si daca este necesar ajutor extern pentru rezolvarea acesteia. Acesta este momentul in care trebuie sa va asigurati ca un proces este la locul lui pentru a atrage atentia persoanelor potrivite asupra situatiei dificile si apoi sa o rezolvati cat mai repede posibil.        

Managementul situatiilor dificile este una dintre partile fundamentale ale Procesului de Management al Proiectelor TenStep si este una dintre aptitudinile pe care toti managerii de proiect trebuie sa le aiba. Multe proiecte au situatii dificile e rezolvat. Nu pot fi ignorate si nu pot fi amanate. Situatiile dificile trebuie rezolvate rapid si eficient. 

4.1 Managementul situatiilor dificile / Proces

4.2 Managementul situatiilor dificile / Tehnici

Se spune ca singura constanta din lume este „schimbarea". Poti face planuri perfecte, dar nu pot garanta pentru fiecare schimbare care ar putea interveni. Cu cat proiectul este mai lung, cu atat este mai probabil sa va confruntati cu schimbari. Acesta este unul intre motivele pentru care procesul TenStep intelege ca procesul de definire initial (Pasul 1) si de planificare (Pasul 2) nu trebuie sa fie perfecte. Dumneavoastra si echipa dumneavoastra trebuie sa faceti cea mai buna treaba dat fiind ceea ce stiti la acel moment. Acest lucru este indeajuns de bun. Dupa aceea aplicati managementul schimbarilor.

Exista un numar de aspecte legate de schimbare care pot aparea intr-un proiect.

• Schimbari de continut
• Schimbarile de configurare
• Alte schimbari

Aceasta sectiune a procesului TenStep acopera toate aspectele schimbarii. La majoritatea proiectelor, aspectul cel mai important al schimbarii este managementul schimbarii continutului, si acesta este aspectul acoperit in acest pas.

5.0.P2 Schimbarea continutului

Continutul este termenul folosit pentru a descrie limitele poiectului. Continuul este folosit pentru a defini livrabilele documentului. La proiectele mai mari, poate include organizatiile afectate, tranzactiile afectate, tipurile de date incluse etc.

Daca priviti la motivele pentru care proiectele nu au succes, sunt de obicei rezultatele a doua probleme. Ori echipa nu a petrecut destul timp definind lucrul si/sau a fost o lipsa de management al continutului. Chiar daca managerul de proiect a facut o treaba buna in definirea continutului, partea cea mai grea consta in managementul proiectului avand in vedere continutul acceptat.

Scopul managementului schimbarii continutului este de a proteja viabilitatea cartei de proiect aprobate si cererile de afaceri aprobate. Cu alte cuvinte, carta proiectului defineste continutul generalal proiectului iar cererile de afacere definesc detaliile livrabilelor. Echipa proiectului s-a angajat la o data limita si un buget bazat pe aceasta definitie a continutului la nivel inalt si detaliata. Daca livrabilele se schimba pe parcursul proiectului (de obicei asta inseamna ca respectivul client vrea articole noi), estimarile de cost, efort si durata pot sa nu mai fie valabile. Daca sponsorul accepta sa includa noul lucru in continutul proiectlui, managerl de proiect are dreptul de a se astepta ca bugetul si datele limita sa fie modificate (de obicei marite) pentru a reflecta munca aditionala. Acest nou cost estimat, efort si durata devin tinta principala. 

Uneori managerul de proiect se gandeste ca managementul continutului inseamna sa trebuiasca sa spui clientului „nu". Acest lucru il face pe managerul de proiect nervos si agitat..

Totusi, vestea buna este ca manageentul continutului are legatura convingerea sponsorului sa ia deciziile care vor rezulta cu schimbari ale continutului proiectului.

Acest lucru este foarte important. Putini clienti pot vedea si exprima fiecare cerere initial. Din acest motiv apar de obicei schimbari care trebuie introduse in proiect. Aceste schimbari pot fi foarte necesare pentru solutii si ar putea fi motive valide de afaceri  pentru care acestea ar trebui incluse. Managerul de proiect si echipa trebuie sa recunoasca cand aceste schimbari sunt  cerute. Apoi trebuie sa urmeze un proces predefinit de schimbare a continutului. Acest proces aduce informatia potrivita catre sponsor si ii permite sa decida daca modificarea trebuie aprobata pe baza valorii afacerii si a impactului asupra proiectului in termenii costului si planificarii. 

5.0.P3 Schimbarea de configurare

Managementul configurarii este termenul dat identificarii, gasirii si managementului tuturor bunurilor proiectului, si a caracteristicilor (metadata) bunurilor. In unele organizatii acest proces este mai ingust denumit numai ca managementul bunurilor materiale.

5.0.P4 Toate celelalte schimbari

Proiectul dumneavoastra poate intampina schimbari care nu apar in mod neaparat sub managementul schimbarii continutului sau managementului configurarii. Aceste schimbari pot fi grupate intr-o categorie generala de management al schimbarii. De exemplu, sa presupunem ca unul dintre membrii echipei pleaca si trebuie sa fie inlocuit. Acesa nu este un exemplu de schimbare a continutului si nici de schimbare a configurarii. Este o schimbare generala. In acest caz puteti avea nevoie sa documentati faptul ca a aparut o schimbare a resurselor, sa determinati impactul schimbarii si sa puneti un plan in aplicare pentru managementul schimbarii etc. In multe privinte, veti urma un proces similar celui de cerere de schimbare a continutului, chiar daca aceasta schimbare si impactul ei asupra proiectului nu este rezultatul unei cereri de schimbare a continutului. 

Una dintre diferentele cheie dintre managementul schimbarii si managementul schimbarii continutului este ca te astepti ca daca schimbarea de continut este ceruta si verirficata, veti schimba bugetul si planificarea pentru a va acomoda cu schimbarea. Nu trebuie sa va asteptati la acelasi lucru si de la schimbarile care nu au legatura cu continutul. De exemplu, in exemplul de mai sus atunci cand un membru al echipei trebuie sa fie inlocuit, este intr-adevar o schimbare si probabil va avea un impact asupra proiectului. Totusi, nu exista asteptari ca aceasta schimbare va rezulta intr- schimbare de buget sau planificare. De fapt, ar putea exista un impact asupra bugetului si planificarii. Totusi, nu ar trebui sa existe ideea ca o schimbare a bugetului si planificarii va avea loc.

O comunicare adecvata in cadrul unui proiect este un factor de succes critic in managementul asteptarilor sponsorilor si ale participantilor la proiect. Daca aceste persoane nu sunt tinute la curent cu regularitate in legatura cu progresul proiectelor, probabilitatea de a intampina probleme cauzate de existenta unor asteptari diferite creste. De fapt, in multe dintre cazurile in care apar conflicte, nu problemele in sine sunt cauza, ci nepregatirea clientului sau a managerului pentru o astfel de situatie.

 (insert picture) 

In toate proiectele ar trebui comunicat stadiul, incluzand raportarile echipei de proiect catre managerul de proiect si raportarile managerului de proiect catre sponsori si participantii la proiect. Sedintele de Stadiu si Rapoartele de Stadiu sunt doua modalitati generale de a comunica stadiul unui proiect. In proiectele mai mari, sau orice alte proiecte care conduc catre diversii participanti la proiect trebuie sa fie mult mai sofisticata. Aceasta abodare mai complexa este definita intr-un Plan de Comunicare.

6.1 Managementului Comunicarii/ Proces

6.2 Managementul Comunicarii/ Tehnici

6.3 Managementul Comunicarii/ Breviar

Procesele folosite in managementul riscului sunt descrise in aceasta sectiune. Aceste procese pot fi modificate pentru a fi utile in cadrul proiectului si apoi inserate in planul de management al proiectului care este creat in 1.0 definirea proiectului. Inainte sa incepem trebuie sa avem definitii mai precise ale riscului si sa le comparam cu presupunerile. Vezi 7.1.3. Presupuneri si riscuri pentru o vedere de ansamblu.

7.1.P2 Proiecte Mici

Proiectele mici nu au de obicei multe riscuri. Tineti minte ca riscul implica probleme care pot aparea in viitor. Din moment de proiectele mici nu au o durata mare, nu este o oportunitate pentru probleme viitoare. Daca managerul de proiect face o evaluare a riscului si descopera unele riscuri ale proiectului, pot fi folosite procedurile de risc ale proiectelor medii.

7.1.1 Proiecte Medii

7.1.2 Proiecte Mari

Managerul de proiect este 100% responsabil de procesele folosite pentru a conduce un proiect. Managerul de proiect are si responsabilitati de management echipei, desi acestea sunt impartite cu managerii functionali ai membrilor echipei. Unii specialisti considera chiar ca managementul echipei de proiect este cea mai solicitanta si cea mai importanta dintre responsabilitatile managementului de proiect.

Managerii care pot face managementul proceselor dar nu se descurca foarte bine cu oameni, pot totusi finaliza cu succes proiecte. Si managerii de proiect care nu se descurca bine la managementul proceselor dar sunt abili in managementul echipei de proiect pot experimenta succesul, desi probabil la o intensitate mai scazuta decat in primul caz. Cei mai buni manageri de proiect se descurca foarte bine atat la managementul proceselor de management de proiect cat si la angajarea, dezvoltarea si managementul echipei de proiect. 

8.1 Managementul Echipei de Proiect / Procesele

8.2 Managementul Echipei de Proiect / Tehnici

8.3 Managementul Echipei de Proiect / Referinte

Calitatea este definita de catre client si reprezinta cat de aproape ajung proiectul si livrabilele de nivelul asteptarilor si cererilor clientului.

Vechiul proverb in legatura cu calitatea fiind in ochii celui care o detine este adevarat-calitatea este masurata de client. Telul dumneavoastra este sa intelegeti cererile clientului si asteptarile acestuia-si apoi sa le satisfaceti.

Acesta este un concept critic despre calitate. Uneori exista tendinta de a crede ca „calitatea" inseamna cel mai bun material, cel mai bun echipament si absolut zero defecte. Totusi, in majoritatea cazurilor, clientul nu se asteapta si nu isi poate permite o solutie perfecta. Daca sunt cateva piedici in proiect sau cateva defecte in livrabile, clientul inca poate spune ca solutia a fost livrata cu un nivel ridicat al calitatii. Pe de alta parte, o solutie perfect imaginata, fara defecte care nu atinge asteptarile clientului nu este considerata de nivel inalt. Scopul managementului calitatii este sa inteleaga pentru inceput asteptarile clientului in termeni de calitate si apoi sa aplice un plan proactiv pentru a atinge acele asteptari.

Din moment ce calitatea este definita de catre client, poate parea ca este complet subiectiv. Totusi, sunt multe lucruri despre calitate care pot fi facute obiectiv. Cest lucru cere intai impartirea termenului generic de „calitate" in aspectele speicifce ale calitatii care sunt importante pentru client. Apoi, va uitati la fiecare aspect individual si stabiliti una sau mai multe metrici cre pot fi adunat pentru a masura caracteristicile. De exemplu, una dintre trasaturile unei solutii de calitate poate fi ca are un numar minim de greseli. Aceasta caracteristica poate fi masurata prin numararea erorilor si defectelor dupa ce solutia devine publica.

In plus fata de intelegerea definitiei clientului asupra calitatii, este important sa recunoasteti interesele altor participanti de asemenea. In functie de rolurile participantilor, pot avea alte cereri de calitate care trebuie satisfacute. De exemplu:

• Compania-solutia ajunge la scopurile strategice
• Cumparatori-solutia atinge specificarile
• Utilizatori finali-solutia ii ajuta sa isi faca lucrul mai bine, mai repede, mai usor.
• Organizatia de suport IT-solutia este stabila, are cateva defecte, este inteligibil si poate fi modificat usor.

Pentru proiecte mari, colectarea metricelor poate fi vitala pentru a pune pe roate procesul de management al calitatii. Asadar, pasii 9, 10, si procesele de management al proiectului TenStep sunt inchise bine. Daca vreti sa faceti o treaba buna prin managementul calitatii, trebuie sa masurati. Daca nu capturati metricele, va fi greu sa imbunatatiti procse prin initiativa de management al calitatii.

Adunarea indicatorilor intr-un proiect este cel mai sofisticat proces de management al proiectelor si poate fi cel mai dificil. Din cauza ca indicatorii sunt greu de definit si adunat, sunt de obicei ignorati.

Toate proiectele trebuie sa stranga informatii de baza legate de indicatori in legatura cu costul, efortul si durata. Pasul 10.0, totusi, se concentreaza pe colectarea indicatorilor pentru a determina cat de bine multumesc livrabilele asteptarile clientului si cat de bine functioneaza procesele interne de livrare . in functie de rezultate, actiunile de corectie si activitatile de imbunatatire a procesului pot fi initia pentru a face procesele mai eficiente si efective.

Managementul indicatorilor si managementul calitatii sunt legate. Este foarte dificil sa imbunatatiti calitatea livrabilelor proceselor dumneavoastra daca nu colectati indicatori. Indicatorii sunt folositi pentru a oferi anumite informatii in legatura cu stadiul incipient al calitatii si daca aceasta calitate creste sau scade.

Managementul indicatorilor poate fi utilizat eficient pe proiecte medii sau mari din cauza ca exista destul timp pentru  prelua informatiile, analiza rezultatele si facerea schimbarilor potrivite. Strangerea indicatorilor sofisticati in proiecte mici va avea valori limitate in cazul in care indicatorii nu pot raportate intr-un regim de organizatie.

Echipele de proiect trebuie sa aiba o idee in legatura cu ceea ce vor face o data ce au captat indicatorii. Daca nu vreti sa ridicati indicatorii pentru a ajuita la managementul proiectului, ar putea sa nu fie un motiv pentru a strange orice in afara de costul de baza, efortul de baza si durata informatiei. (in cazul in care indicatorii nu sunt ceruti si utilizati la nivel organizational).

Indicatorii proiectului sunt importanti,dar cea mai mare valoare in captarea indicatorilor este conducerea imbunatatirilor intr-un regim organizational. Acumularea indicatorilor consistenti din toate proiectele poate fi folosita la conducerea imbunatatirea proceselor in organizatie. In ultimul rand informatia poate fi folosita pentru a crea un set de practici si standarde care vor ajuta in cadru tuturor proiectelor.

De cate ori n-ai auzit sau n-ai fost implicat intr-un proiect care a esuat lamentabil? Sau poate doar nu a fost atat de performant pe cat trebuia. Ai investit vreodata timp sa analizezi retrospectiv ce a determinat proiectul sa evolueze pe calea gresita? Daca da, este posibil sa fi spus: "Ar fi trebuit sa investim mai mult timp in planificare".Majoritatea proiectelor au termene limita si se pare ca acestea devin tot mai scurte. Tintirea unor termene limita agresive il preseaza pe managerul de proiect sa demareze proiectul cat mai curand posibil. Totusi, inainte de a incepe munca trebuie sa investesti timp in planificarea preliminara pentru a te asigura ca activitatile sunt intelese corect si convenite. Acesta nu este un timp pierdut sau o ‘supraincarcare'. Este timpul investit de managerul de proiect pentru a se asigura ca echipa de proiect si clientul au perceptii comune asupra livrabilelor proiectului, termenului de livrare, costurilor, responsabilitatilor si modalitatilor de executie a activitatilor.

La finalul unui proiect dificil, beneficiile planificarii ar putea fi evidente. Dar beneficiile sunt cunoscute chiar dinainte. La un nivel general, aceste beneficii includ:

• Intelegerea si obtinerea acordului asupra obiectivelor proiectului, livrabilelor, sferei de cuprindere, riscurilor, costurilor, abordarii, etc. (din Documentul de Definire a Proiectului). Prin aceasta se asigura pur si simplu acordul dintre echipa de proiect si sponsor asupra muncii necesare.
• Se determina daca scenariul de business original mai este inca valid. La momentul aprobarii initiale a proiectului, costurile si durata au fost probabil estimate la un nivel general - probabil in limita a ± 50%. Acum, la demararea proiectului, estimarile trebuie revalidate astfel incat sa se apropie de marja de ± 10%. Aceasta rafinare suplimentara poate determina obtinerea unor estimari mai mari iar acestea pot face scenariului de business neatractiv. De exemplu, un proiect care presupune un efort de10,000 de ore ar putea avea sens din punct business. Daca procesul de planificare mai detaliata determina rafinarea estimarii la 20,000 de ore, proiectul ar putea sa nu mai aiba sens din punct de vedere business.
• Asigurarea disponibilitatii resurselor atunci cand ai nevoie de ele. Aceasta este determinata de intelegerea organizatiei ce deruleaza proiectul si de elaborarea programului de activitati incluzand alocarea resurselor.
• Furnizarea unui nivel general de referinta in raport cu care se poate compara evolutia. Aceasta este determinata de elaborarea unui cadru temporal al reperelor intermediare in baza programului de activitati mai detaliat.
• Validarea incipienta a proceselor utilizate pentru managementul proiectului impreuna cu clientul. Procedurile utilizate pentru managementul proiectului trebuie discutate si explicate clientilor si membrilor echipei.

Ar trebui sa fie logic ca proiectele de mica anvergura necesita un ciclu de planificare mai scurt iar cele de mare anvergura un ciclu de planificare mai lung. Efortul necesar planificarii proiectului depinde de volumul informatiilor si de gradul de detaliere ce trebuie intelese si documentate. Durata necesara definirii proiectului depinde de timpul necesar pentru descoperirea si documentarea informatiilor precum si pentru obtinerea acordului si aprobarii clientului. Uneori, managerul de proiect poate deveni frustrat din cauza dificultatii de a obtine acordul clientului asupra sferei de cuprindere, programului de activitati si costurilor proiectului. Dar tocmai din acest motiv aceste lucruri trebuie facute dinainte. Gandeste-te la problemele ce le vei intampina incercand sa obtii acordul clientului asupra sferei de cuprindere, programului de activitati sau costurilor cand proiectul a inceput deja iar livrabilele sunt produse efectiv.

1.0.P2 Inainte de Inceperea Ciclului de Viata 

Inainte de inceperea ciclului de viata al proiectului (analiza, proiectare, constructie, etc.), o serie de elemente ale procesului de planificare trebuie sa fie stabilite. In cazul proiectelor mai mici, multe din aceste conditii sunt indeplinite informal sau implicit. Totusi, cu cat proiectul este mai mare, cu atat este mai important ca aceste criterii sa fie indeplinite formal si explicit.

• Clientul aproba demararea planificarii. In mod normal, se presupune ca proiectul a ajuns pana in acest stadiu in urma unei aprobari implicite. Totusi, daca nu a fost pregatit un scenariu de business pentru proiect si daca acesta nu a parcurs un proces de autorizare, atunci inainte de a incepe planificarea proiectului, trebuie cautata o aprobare explicita.
• Proiectul este definit in mod formal. Aceasta se documenteaza in Documentul de Definire a Proiectului, care cuprinde obiectivele, sfera de cuprindere, presupunerile, livrabilele, bugetul, etc. (In cazul proiectelor medii sau mici poate fi vorba despre Documentul de Definire Abreviata a Proiectului sau Cererea de Serviciu.)
• Programul de activitati al proiectului este creat. Un program de activitati trebuie pregatit si utilizat pentru managementul efortului. Acesta include puncte de verificare sau repere intermediare la care proiectul poate fi evaluat pentru a fi siguri ca este potrivit sa continue.
• Clientul aproba inceperea proiectului. Aceasta este consemnata prin Documentul aprobat de Definire a Proiectului. Sponsorul trebuie sa semneze documentul pentru a asigura acordul.
• Procedurile de management de proiect sunt definite si aprobate. Proceduri trebuie instituite pentru a descrie modalitatile in care managerul de proiect va realiza managementul problemelor, al comunicarii, riscurilor, calitatii, sferei de cuprindere, etc. Aceasta este in special valida pentru proiectele mari si mai putin importanta pe masura ce proiectele scad in dimensiuni.
• Resursele echipei de proiect sunt alocate. Trebuie sa dispui de oamenii potriviti pentru a executa proiectul. Uneori proiecte valide si aprobate trebuie intarziate pentru ca oamenii cu abilitatile potrivite nu sunt disponibili.

1.0.P3 Intelegerea Proiectelor 

Inainte de a invata cum se defineste munca dintr-un proiect trebuie clarificata definitia teoretica a proiectului in sine. Astfel se va intelege mai clar cand sunt necesare tehnici formale de management de proiect. Astfel, este indicat sa revizuiesti:

• 1.0.1 Ce este un Proiect?
• o 1.0.1.1 Momentele de Start si de Final ale Proiectului
• 1.0.2 Managementul Proiectelor vs. Ciclul de Viata al Proiectului
• 1.0.3 Managementul de Proiect vs. Managementul de Produs
• 1.0.4 Rolul Managerului de Proiect.

Procesele folosite in managementul de proiect trebuie sa fie scalabile in functie de dimensiunea proiectului. Proiectele de mare anvergura trebuie conduse mai riguros si mai structurat decat cele de mica anvergura.

1.0.P4 Dimensionarea Proiectului (Mic, Mediu, Mare)

Procesul TenStep contine indrumare specifica pentru managementul proiectului in functie de dimensiunea lui. Dar la inceput trebuie sa-ti clasifici proiectul. In unele companii, un proiect de sase luni si 10,000 de ore ar putea fi considerat un proiect de mare anvergura. In alte organizatii, acelasi proiect ar putea fi considerat un proiect de mica anvergura. Noi am furnizat cateva indicatii generale dar fiecare organizatie trebuie sa determine indicatiile care au sens pentru ele.