1.2 Definirea Proiectului / Tehnicile

1.2.P1 Lucreaza simultan la Documentul de Definire a Proiectului si la Planul de Proiect

Nu exista neaparat o ordine secventiala in definirea proiectului (Pasul 1.0) si elaborarea planului de proiect (Pasul 2.0). Inseamna ca nu trebuie, mai intai, sa definesti complet proiectul si, apoi sa elaborezi planul de proiect. Unele sectiuni din Documentul de Definire a Proiectului, precum estimarile de efort si durata, nu pot fi terminate fara a incepe schitarea planului general de proiect. In acelasi timp, nu poti termina planul de proiect fara sa obtii acordul asupra Documentului de Definire a Proiectului. De exemplu, nu poti elabora planul de proiect fara a obtine acordul de principiu asupra livrabilelor si continutului. Definirea proiectului implica, de asemenea, si descrierea abordarii generale a proiectului, care este de ajutor inainte de terminarea planului de proiect.


Pana la un anumit punct, definirea proiectului si elaborarea planului de proiect trebuie realizate simultan. Principalele doua livrabile, Documentul de Definire a Proiectului si Planul de Proiect trebuie, de asemenea, dezvoltate in paralel. Vei descoperi ca pe masura ce colectezi informatii despre sfera de cuprindere si livrabile, poti incepe schitarea unui plan general de proiect. Pe masura ce aduni mai multe informatii despre lucrare, poti completa mai multe detalii in planul de proiect. Cand livrabilele, continutul, presupunerile si abordarea sunt complete, ar trebui sa ai suficiente informatii pentru a termina un plan de proiect general. Apoi, poti folosi planul general de proiect pentru a estima bugetul, efortul si durata necesare, care sunt apoi folosite pentru a finaliza Documentul de Definire a Proiectului.


1.2.P2 Descompune proiectele mari in componente mai mici

In zilele noastre, mega-proiectele nu mai sunt tratate monolitic. Managementul si executia cu succes a proiectelor foarte mari sunt pur si simplu prea dificile. Exista o serie de probleme asociate proiectelor foarte mari:

  • Cu cat este mai indepartata in viitor, munca este cu atat mai neclara. Proiectele mari de obicei dureaza mult intotdeauna, facand planificarea lor cu succes foarte dificila.
  • Din moment ce munca viitoare este mai putin clara, este mai dificil sa faci estimari precise pentru efort, durata si cost.
  • Conditiile tehnice si de business se pot modifica in timp, astfel ca presupunerile folosite in planificare devin foarte incerte. Realitatile tehnice si de business curente se pot schimba radical in timp.
  • Exista riscul de a pierde sprijinul organizatiei daca primele rezultate tangibile ale proiectului intarzie un interval lung de timp. Este foarte dificil sa mentii entuziasmul si sprijinul organizational pentru perioade lungi de timp.
  • Este foarte dificil sa faci predictii pe termen lung privind cerintele si disponibilitatea resurselor. Inca o data, pe masura ce te referi la perioade mai indepartate in viitor, devine tot mai dificil sa faci estimari precise.

Eforturile foarte mari sunt prea complexe si managementul lor sub forma unui singur proiect este dificil. O tehnica mai buna este descompunerea lor in componente mai mici care se pot gestiona mai bine, fiecare reprezentand un proiect in sine, cu propriile Document de Definire a Proiectului si Plan de Proiect. 

De exemplu, un efort IT de amploare poate fi descompus in proiecte secventiale separate in baza ciclului de viata. Se va initia un proiect pentru faza de analiza. Spre finalul acestuia, se stabileste un al doilea proiect, pentru faza de proiectare, in baza a ceea ce se cunoaste la acel moment. Apoi se initiaza un proiect pentru constructie/testare si, in cele din urma, un proiect pentru implementare. Alte initiative de anvergura se pot descompune in proiecte mai mici, care pot fi derulate in paralel. Unele initiative de anvergura pot include o serie de proiecte mai mici, unele putand fi derulate secvential iar altele in paralel. Fiecare echipa va munci sa-si termine propriul proiect, dar volumul de munca total va fi coordonat astfel incat efort total sa fie de succes.


1.2.P3 Stabileste un program pentru a coordona un set de proiecte interconectate

Daca descompui un efort mare intr-un numar de proiecte interconectate, va trebui, in continuare, sa pastrezi un management si o coordonare unitare. Acesta este scopul stabilirii unui "program". Un program este o structura sub umbrela careia se face managementul unei serii de proiecte interconectate. Fiecare proiect are un manager de proiect cu norma partiala sau intreaga. Programul este condus de catre un manager de program. Programul in sine nu produce niciun livrabil. Echipele de proiect produc toate livrabilele. Scopul unui program este sa:

  • Furnizeze indrumare, directionare si conducere de ansamblu pentru proiecte.
  • Asigure o comunicare eficace intre proiectele interconectate.
  • Asigure un punct unic de contact si focalizare pentru client si echipele de proiect.
  • Identifice cum trebuie definite proiectele individuale pentru a asigura ca intreg volumul de munca este indeplinit cu succes

1.2.P4 Colaboreaza cu clientul cand nu poate defini integral proiectul

Managerul de proiect are, uneori, asteptari prea mari asupra viziunii clientului. In multe cazuri, managerul de proiect va pune intrebari clientului pentru a-l ajuta sa defineasca proiectul, dar clientul nu va avea toate informatiile necesare. Aceasta se intampla mereu si nu inseamna ca clientul nu stie ce face. In special in proiectele mari, in multe cazuri clientul are o viziune asupra a ceea ce trebuie sa fie rezultatele finale, dar nu o poate inca articula in livrabile concrete. De asemenea, el poate sa nu aiba toate raspunsurile asupra continutului, riscurilor, organizarii proiectului, etc. 

Avand informatii nu tocmai complete, managerul de proiect poate fi tentat sa ghiceasca unele detalii. Aceasta nu este o solutie buna. In schimb, daca te confrunti cu aceasta situatie, exista trei variante la dispozitie pentru a continua.

  • Specifica de la inceput tot ceea ce stii si ce nu stii. Daca ti se solicita estimari de efort, cost si durata, va trebui sa furnizezi o interval de valori, in functie de gradul de incertitudine.
  • Descompune munca intr-o serie de proiecte mai mici (asa cum este descris anterior). Chiar daca rezultatele finale nu pot fi definite clar, un anumit volum de munca trebuie sa fie bine definit, pentru a conduce la informatiile necesare pentru definirea solutiei finale. Trebuie sa definesti un proiect care sa acopere doar ceea ce poti anticipa, intr-o maniera rezonabila, la momentul curent. Apoi, pe masura ce vei cunoaste mai multe detalii defineste si planifica proiectele ulterioare pentru a acoperi munca ramasa. De exemplu, poti crea un proiect pentru colectarea cerintelor si apoi sa utilizezi rezultatele acestuia pentru definirea unui al doilea proiect, dedicat dezvoltarii livrabilelor finale.
  • Daca nu poti descompune proiectul in componente mai mici, trebuie sa ai macar informatii suficiente pentru a planifica munca pentru primele 90 de zile. In cadrul acestei a treia abordari planifici mai in detaliu munca pe termen scurt si lasi efortul pe termen lung mai putin definit. In fiecare luna trebuie sa redefinesti si sa planifici munca ramasa. Pe masura ce descoperi mai multe informatii, vei putea planifica mai in detaliu munca ramasa.

1.2.P5 Asigura-te ca rolurile si responsabilitatile sunt intelese

Organizarea proiectelor mici este destul de simpla - pot fi implicati doar managerul de proiect si clientul/sponsorul. Persoana responsabila pentru managementul proiectului poate fi de fapt si singura persoana care lucreaza efectiv in proiect.

Totusi, pentru proiecte mari, este necesara o structura organizatorica mai elaborata si mai formala. Poti avea membri ai echipei, un sponsor executiv, un sponsor al proiectului, un manager din partea clientului, un director de proiect, un comitet de conducere a proiectului, furnziori, clienti si alte parti implicate. Nu este recomandabil sa complici excesiv structura, dar cu cat sunt mai multi oameni implicati in proiect, cu atat este mai important ca fiecare sa stie clar ce roluri si responsabilitati are in proiect. De exemplu, ultimul lucru pe care ti l-ai dori este ca oamenii sa-ti dea indicatii ca si cum ar fi sponsori, cand de fapt ei nu sunt decat parti interesate de proiect din cadrul managementului.

Unul dintre aspectele definirii proiectului este definirea structurii organizatorice si a rolurilor si responsabilitatilor pentru toti participantii principali. De obicei, rolurile si responsabilitatile tipice pot fi definite dinainte in cadrul organizatiei si, apoi, reutilizate dupa cum este necesar, de la un proiect la altul. Multe dintre rolurile si responsabilitatile uzuale sunt descrise in sectiunea 1.2.2 Definirea Proiectului / Roluri si Responsibilitati.


1.2.P6 Obtine aprobarile proiectului de la persoanele potrivite

Odata ce proiectul a fost definit, managerul de proiect trebuie sa solicite aprobarea formala de la sponsor si de la participantii la proiect din cadrul managementului. Exista mai multe moduri de obtinere a aprobarii formale. Ca in cazul multor activitati din Metodologia TenStep, un dram de planificare este cheia reusitei. Pentru proiecte mici, o semnatura de la client sau de la Sponsorul Proiectului este probabil suficient pentru a semnifica aprobarea de a incepe munca. Aceasta aprobare poate fi trimisa si printr-un email de confirmare. Oricum, nu trebuie sa fie doar verbala.

In proiectele mai mari, solicita managerului si Sponsorului Proiectului sa identifice cine va aproba explicit Documentul de Definire a Proiectului, cine va il aproba implicit si cine trebuie sa primeasca doar o copie a documentului, pentru scopuri pur informative. In general, utilizeaza urmatoarea abordare ca punct de pornire: 

  • Sponsorul proiectului si principalele parti interesate in proiect. Obtine aprobarea explicita. Aceasta aprobare poate fi semnatura oficiala pe o copie de hartie a Documentului de Definire a Proiectului. Poate fi, de asemenea, un mesaj electronic specificand explicit aprobarea proiectului. De asemenea, poti avea aprobarea asupra unui anumit flux de lucru. Important este ca aprobarea sa fie explicita si sa pastrezi dovada acesteia. Inainte de a distribui versiunea finala a documentului, Sponsorul si alte parti relevante in proiect trebuie sa fi primit copii ale versiunilor anterioare. Aceasta aprobare finala trebuie sa fie o simpla formalitate. Nu e recomandabil sa incerci sa obtii aprobarea finala iar Sponsorul sa mai aiba, totusi, preocupari sau intrebari pe marginea proiectului.
  • Alte parti interesate din cadrul managementului. Obtine o aprobare implicita. Implicit inseamna ca presupui ca Documentul de Definire a Proiectului este aprobat daca acestia nu se exprima altfel. La inceput le trimiti o copie electronica sau imprimata a Documentului de Definire a Proiectului. Ii anunti ca vrei sa revizuiasca materialul si sa-ti trimita feedback, mai ales daca au intrebari sau alte preocupari. Apoi le dai un termen pana la care sa raspunda si le spui ca daca nu primesti raspunsul inainte de data respectiva, vei presupune ca iti acorda aprobarea. Daca formuleaza diverse observatii, adreseaza-le sau discuta-le cu Sponsorul Proiectului pentru a gasi o rezolutie. Este important ca aceste persoane sa fi primit versiunile anterioare ale documentului si sa fi avut posibilitatea de furniza observatii. Cand trimiti Documentul de Definire a Proiectului spre aprobarea finala este recomandabil ca toate observatiile sa fi fost deja exprimate. Nu vei vrea sa intampini probleme, preocupari sau incertitudine cand incerci sa obtii aprobarea finala a Sponsorului.
  • Alte parti interesate. Trimite-le o copie a Documentului de Definire a Proiectului. Anunta-i ca l-au primit doar pentru propria lor informare. Trebuie sa fii disponibil sa discuti continutul materialului astfel incat ei sa-l inteleaga mai bine, dar nu le trimiti documentul spre aprobare. Este posibil sa fie prima data cand aceste persoane vad Documentul de Definire a Proiectului. Totusi, nu ai autoritatea sa colectezi cereri de modificare a documentului din moment ce probabil ai obtinut deja aprobarea Sponsorului. Daca exista observatii majore, persoane care le exprima trebuie sa le discute direct cu Sponsorul.

1.2.P7 Stabileste Tripla Constrangere cand Documentul de Definire a Proiectului este aprobat

La finalul procesului de definire si planificare a proiectului (Pasii 1 si 2), ar trebui sa existe deja un acord cu sponsorul referitor la continutul proiectului, precum si asupra costului si duratei necesare finalizarii proiectului. Aceste trei elemente formeaza un concept denumit "tripla constrangere". Aspectul cheie al triplei constrangeri este ca daca unul din cele trei elemente se modifica, cel putin unul daca nu ambele celelalte elemente trebuie sa se schimbe, de asemenea. (Tripla constrangere se poate exprima in cateva feluri similare. Costul poate fi exprimat drept efort, ceea ce are sens daca toata manopera este interna si nu exista alte categorii de costuri. Uneori, continutul este definit in termeni de calitate, ceea ce inseamna focalizarea pe indeplinirea unui anumit nivel de calitate, pentru un cost si o durata date. Acesta este un aspect mai restrans al triplei constrangeri, dar conceptul general ramane in continuare valid.)

Acest concept este simplu de vizualizat daca asociezi tripla constrangere cu un triunghi ale carui laturi reprezinta costul, durata si continutul proiectului.

(insert picture)

In cazul in care continutul creste, costul si/sau durata trebuie sa creasca de asemenea. Are sens. Daca se lucreaza mai mult, costul (efortul) va fi mai mare si, probabil va dura mai mult. (Similar, daca se reduce continutul proiectului, costul (efortul) si/sau durata ar trebui sa scada si ele.)

(insert picture)

Daca este necesara accelerarea proiectului si reducerea duratei, ar fi logic ca si munca in sine sa se reduca. Daca insa trebuie sa livrezi acelasi continut intr-un timp mai scurt, a treia latura a triplei constrangeri va creste, pentru a mentine echilibrul. Este logic, de asemenea. Va fi necesara sporirea efortului, ceea ce duce la cresterea costului, poate prin ore peste program sau prin aducerea mai multor resurse in proiect, pentru finaliza mai repede acelasi volum de munca.

(insert picture)

1.2.P8 Integreaza toata documentatia de Management de Proiect in Planul de Proiect

Planul de proiect este un document unitar creat pentru a include toate livrabilele de management de proiect realizate in Pasii 1.0 Definirea Proiectului si 2.0 Elaborarea Planului. Desi, cu siguranta, ne putem referi si individual la aceste documente, Planul de Proiect poate fi utilizat pentru a le agrega. In mod specific, Planul de Proiect include:

  • Documentul de Definire a Proiectului (Project Charter)
  • Roluri si responsabilitati, etc.
  • Programul activitatilor, Structura de Descompunere pe Activitati, reperele temporale
  • Procedurile de Management de Proiect
  • Planul de Management al Continutului, Planurile de Management al Costului si al Programului activitatilor
  • Planul de Management al Calitatii, Planul de Management al Personalului
  • Planul de Comunicare, Planul de Management al Riscurilor
  • Aprobarile Proiectului
  • Alte documente de management de proiect

Planul Proiectului poate fi un document efectiv sau o agenda de planificare sau un fisier care contine celelalte documente. De exemplu, Planul de Proiect poate fi sub forma unui biblioraft cu mai multe sectiuni. De asemenea, Planul de Proiect poate fi un fisier pe un server unde poti stoca copiile electronice ale tuturor documentelor.


1.2.P9 Incearca sa intelegi nevoile exprimate si cele reale ale clientului

Documentul de Definire a Proiectului descrie proiectul la un nivel generic, incluzand nevoile clientului, precum si estimarile de efort, durata si cost facute de echipa de proiect pentru indeplinirea acestora. Nevoile clientului sunt apoi detaliate in cadrul procesului de colectare a cerintelor de business.

Este important pentru echipa si pentru managerul de proiect sa inteleaga ca nevoile reale ale clientului nu coincid intotdeauna cu cele exprimate in Documentul de Definire a Proiectului si in documentele care contin cerintele. In multe situatii, clientul nu isi intelege propriile nevoi inainte de a incepe proiectul. Uneori, nevoile reale se contureaza pe masura ce proiectul evolueaza. In alte situatii, clientul poate avea o viziune clara asupra nevoilor sale, dar are dificultati in a le exprima intr-un limbaj inteligibil pentru echipa de proiect. Intr-o buna masura, acesta este scopul existentei procesului de Management al Continutului - respectiv, sa permita clientului operarea de modificari asupra cerintelor pe parcursul derularii proiectului.


Tot ce poate face echipa de proiect este sa documenteze nevoile exprimate ale clientului si sa le foloseasca apoi ca baza pentru a obtine aprobarile pentru Documentul de Definire a Proiectului si Cerintele de Business. Totusi, echipa trebuie sa incerce pe cat posibil sa descopere nevoile reale ale clientului. Aceasta presupune utilizarea unor tehnici specifice de adresare a intrebarilor potrivite, de colectare a cat mai multor opinii din partea principalelor parti interesate in proiect, de adresare de intrebari suplimentare cand cerintele nu par a fi logice, etc. In mod evident, echipa de proiect trebuie sa faca tot ce este posibil in incercarea de a despoeri nevoile reale ale clientului. Cu cat nevoile exprimate ale clientului corespund mai mult celor reale, cu atat mai mari vor fi sansele ca proiectul sa se finalizeze cu succes.


1.2.P10 Foloseste un "proiect de identificare" separat pentru a defini un proiect de mare anvergura

In cazul proiectelor mari, activitatea de definire a proiectului tinde sa dureze foarte mult si sa nu mai fie bine focalizata. Pentru ca dureaza suficient de mult timp, definirea proiectelor foarte mari ar trebui structurata drept un proiect de sine statator. Acesta este scopul definirii unui Proiect de Identificare separate.

Ar trebui sa fie logic. Daca, in cele din urma, se constata ca un proiect va necesita 50,000 de ore de efort, definirea si aprobarea lui ar putea dura cateva luni. In aceste situatii, se stabileste un prim proiect distinct, cu scopul de a-l defini pe al doilea, respectiv proiectul mai mare, in sine.  Livrabilele Proiectului de Identificare sunt versiunile finale ale Documentului de Definire a Proiectului, Planului de Management al Proiectului si programului de activitati al proiectului mai mare ulterior. Toate celelalte livrabile vor fi produse in cadrul urmatorului proiect.


Ca toate proiectele, Proiectele de Identificare au dimensiuni variate. Trebuie estimate efortul si durata unui astfel de proiect. In functie de efortul necesar, Proiectele de Identificare pot fi si ele clasificate drept proiecte mici / medii / mari, folosind aceleasi criterii, descrise mai devreme. Tine minte ca aceasta este dimensiunea relativa Proiectului de Identificare, nu a proiectului final. In functie de dimensiunea Proiectului de Identificare, ai, din nou, trei optiuni pentru a-l defini. 

Pentru un Proiect de Identificare mic poate fi creata o cerere de servicii, dar nu este necesar. Pentru un efort de aceasta dimensiune se continua, pur si simplu, definirea proiectului asa cum am descris-o in sectiunea 1.1.2 Definirea Proiectului / Proiecte Medii. Daca definesti un Proiect de Identificare, se presupune ca proiectul final este suficient de mare pentru a necesita un Document de Definire a Proiectului complet. 


In cazul unui Proiect de Identificare mediu trebuie urmata metodologia TenStep pentru proiectele de dimensiuni medii. Proiectul de Identificare trebuie sa aiba un Document de Definire Abreviata a Proiectului si un program de activitati si sa fie condus similar oricarui proiect de dimensiuni medii, incluzand managementul problemelor, managementul continutului, managementul riscurilor, etc. (Nu este neaparat nevoie sa fie creat Planul de Management al Proiectului pentru Proiectul de Identificare in sine.) Documentul de Definire a Proiectului, Planul de Management al Proiectului si programul de activitati al proiectului ulterior trebuie create dupa incheierea Proiectului de Identificare. Procesul de aprobare al acestor documente trebuie sa faca parte din cadrul Proiectului de Identificare. Presupunand ca Documentul de Definire a Proiectului a fost aprobat, proiectul ulterior de dimensiuni mari poate incepe oricand. Totusi, Pasii 1.0 Definirea Proiectului si 2.0 Elaborarea Planului vor fi deja finalizati (acestia au facut obiectul Proiectului de Identificare). Procesul de management de proiect pentru proiectul ulterior poate incepe cu Pasul 3.0 Managementul Planului.


Daca, de fapt, Proiectul de Identificare este un proiectmare, trebuie urmati pasii necesari definirii proiectelor de mare anvergura. Sa luam un exemplu. Sa spunem ca incerci sa definesti un proiect foarte mare - poate chiar un program (o serie de proiecte interconectate, conduse sub forma unui intreg). Sa presupunem, in continuare, ca Proiectul de Identificare in sine este estimate la 5,000 de ore. Daca Proiectul de Identificare este mare, proiectul ulterior, care tocmai ce este definit, ar trebui sa fie imens. Atunci, Proiectului de Identificare i se vor aplica tehnicile de management al proiectelor de mare anvergura. Cand Proiectul de Identificare este finalizat poate incepe proiectul mai mare intrucat livrabilele sale includ Documentul de Definire a Proiectului, programul de activitati si Planul de Management al Proiectului.