2.2.1 Crearea Programului de Activitati si a Bugetului/ Tehnici de Estimare

2.2.1.P1 Tehnici de Estimare

(Tehnicile de estimare sunt predate in cursuri cu durata de cinci zile bazandu-se pe statistica avansata si formule stiintifice aflate in afara scope-ului proceselor Tenstep.)

Urmatoarele tehnici pot fi folosite la nivelul proiectelor sau al activitatilor sau pentru orice alta sarcina. De exemplu, opinia unui expert poate fi folosita pentru intreg proiectul sau pentru o activitate specifica. Tehnicile de estimare avansate sunt cunoscute ca tehnici de sus in jos.  Aceste tehnici presupun experienta, analogii si rapoarte anterioare. Estimarile complete care au la baza o impartire minutioasa a activitatilor se numesc tehnici de jos in sus. Metoda Structurii de Descompunere a Activitatilor de exemplu este o tehnica de jos in sus.


Estimarile de sus in jos sunt de obicei mai rapide si mai usor de asamblat de vreme ce estimezi la nivelul intregului proiect. In aceasi timp au grad de precizie redus bazandu-se pe experientele anterioare plus analogii cu alte proiecte asemanatoare. Daca este posibil ar trebui utilizate mai multe tehnici de estimare pentru un proiect in special daca se foloseste tehnica de sus in jos.  

  • Experienta Anterioara. Este cea mai buna metoda de estimare a activitatilor. Daca organizatia tine evidenta orelor productive din proiectelor anterioare aceste informatii contribuie la estimarea noilor activitati. In aceasta metoda datele anterioare plus cele prezente sunt salvate intr-o baza de date sau sub alta forma putand fi accesate pentru noile proiecte. Angajatul care estimeaza noi activitati ar putea descrie caracteristicile proiectului pentru a cauta proiecte similare anterioare. Astfel angajatul poate verifica rezultate anterioare pentru a aproxima efortul necesar pentru viitoarele activitati.
  • Analogie. Chiar daca nu exista o evidenta a orelor depuse in proiectele anterioare activitatile acestora pot fi inca estimate. Analogia inseamna gasirea unor proiecte similare chiar daca membrii echipei nu au strans numarul orelor efectiv lucrate. Managerul proiectului anterior trebuie sa aiba cel putin o estimare initiala a efortului si a duratei necesare. Chiar daca nu a fost urmarit numarul efectiv a orelor lucrate managerul cunoaste durata proiectului. Daca durata efectiva se potriveste cu cea estimata se poate presupune ca numarul orele efective va fi in jurul celor estimate. Pe de alta parte daca termenul limita a fost deposit cu 20% atunci se poate presupune ca si numarul orelor effective a fost deposit cu acelasi procent.

De exemplu, sa presupunem ca un proiect anterior a fost estimat la o durata de sase luni si la 2000 de ore pentru a fi completat. Daca proiectul a fost terminat in sase luni exista o probabilitate ridicata ca acesta sa fi avut in jur de 2000 de ore efectiv lucrate. Pe de alta parte, daca proiectul a durat sapte luni pentru a fi terminat folosind toti membrii echipei poti estima numarul orelor lucrate efectiv la 2300.

  • Raport. Raportul este asemanator analogiei exceptia fiind existenta unor elemente pentru compararea activitatilor cu caracteristici asemanatoare dar la o scara mare sau mica. De exemplu efortul necesar instalarii unui soft pentru Biroul din Miami a fost de 500 ore iar unul din motivele acestui efort a fost numarul personalului din birou. Daca numarul personalului din biroul din Chicago este dublu se poate estima ca efortul necesar va fi de 1000 de ore.

•·         Opinia expertului. In multe cazuri este nevoie de ajutorul unui expert intern sau extern pentru a ajuta la estimarea activitatilor. De exemplu, daca este utilizata o noua tehnologie este nevoie de o firma de consultanta pentru estimarea activitatilor. De multe ori aceste estimari sunt bazate pe experientele celorlalte firme din industrie. Se poate apela si la ajutorul unui expert intern. Desi va fi prima data cand se va estima o anumita activitate poate altcineva are experienta.


  • Delphi. Tehnica Delphi este similara opiniei expertului exceptia fiind utilizarea mai multor experti si incercarea de a ajunge la un acord in urma cercetarilor efectuate. Se identifica doi sau mai multe (de preferat trei) persoane considerate experti in domeniul activitatilor estimate. Le sunt trimise informatiile relevante pentru a-si intelege atributiile, urmand sa trimita estimari asupra efortului necesar proiectului impreuna cu presupunerile, riscurile etc. identificate.

Daca estimarile sunt relativ aceleasi se poate realiza o medie bazata pe rezultatele cercetarilor pentru estimarea finala. Insa se intampla ca rezultatele sa fie diferite sau doar cateva dintre ele sunt apropiate ca cifre spre deosebire de altele. In acest caz se trimit toate estimarile incluzand presupunerile si riscurile inapoi la experti pentru recercetare. Experti ar trebui sa considere toate rezultatele celorlalte estimari, presupuneri si riscuri, urmand sa trimita al doilea set de estimari. Rezultatele estimarilor ar trebui sa fie apropiate de vreme ce fiecare expert a analizat celelalte cercetarile.   Bazat pe un set comun de presupuneri, riscuri experti pot stabili de comun acord estimarile. In caz opus daca majoritatea expertilor au estimari similare se folosesc cifrele respective. Un risc ce ar trebui luat in considerare este faptul ca expertii nu au cazut de acord asupra estimarilor.


Daca trei experti estimeaza activitatile in jurul a 1000 de ore dar unul dintre ei isi mentine estimarea de 2000 de ore ar trebui aleasa prima varianta si mentionata potentiala dublare a numarului de ore estimate, risc bazat pe cel putin parerea unui expert.

In caz ca exista timp si inclinare o a doua optiune ar fi apelarea la mai multi experti. Daca noile estimari sunt aproape de cea stabilita ar intari increderea in deciziile luate, in schimb daca ar fi diferite ar reduce increderea (aparitia mai multor riscuri).

Scenariile prezentate mai sus sunt exemple de ceea ce se poate intampla cand se cere opinia la mai multi experti. Tehnica Delphi utilizeaza multi experti si te indruma pentru viitoare actiuni cand estimarile nu coincid. 

  • Structura de Descompunere a Activitatilor. Procesul Tenstep pentru creerea unui program de activitati din Pasul 2.1 discuta fragmentarea activitatilor in subactivitati din ce in ce mai mici pentru a facilita estimarea activitatilor. Estimarea efortului unei activitati mari este dificila insa impartind activitatea in subactivitati, componentele individuale vor putea fi estimate mai usor. Adunand estimarile fiecarei activitati se obtine efortul total necesar. Daca exista timp pentru creerea unei structuri de descompunere a activitatilor de obicei rezultatul este o estimare reusita a efortului total necesar. Daca este posibil tehnica structurii de descompunere a activitatilor ar trebui folosita.

  • PERT (Tehnica de Evaluare si Analiza a Programului). Conceptul PERT se refera de obicei la o diagrama retelei. Insa este numele formal al unei tehnici de estimare folosind media aritmetica a trei numere pentru a calcula estimarea finala.

Folosind tehnica PERT pentru calcularea efortului necesar pentru incheierea unui proiect sau a unei activitati se determina trei  estimari - cea pesimista (P) caz in care totul merge gresit, cea optimista (O) caz in care totul merge bine si cea mai probabila (M) caz in care apar probleme si oportunitati. Rezultatul este calculat astfel (O + 4M + P)/6. De exemplu, sa presupunem ca estimarea unei activitati este de 10 ore.  Cazul optimist (totul merge bine) dureaza 6 ore. Cazul pesimist (totul merge prost) dureaza 26 de ore.

 Estimarea PERT este (6 + 4(10) + 26)/6. Raspunsul este 72/6, sau 12 ore. A se observa ca numarul a fost "tras" spre cazul pessimist dar nu prea mult de vreme ce rezultatul - since the result is still weighted heavily toward the most likely value. -

  • Modelarea Parametrilor. In aceasta tehnica trebuie sa existe un model care sa permita folosirea unui algoritm pentru determinarea estimarii totale. De exemplu, daca cunoastem ca un kilometru de autostrada costa un million de dolari prin analogie costul a zece kilometrii de autostrada cu patru benzi va fi de 40 de milioane de dolari. Sau daca trebuie create 40 de rapoarte noi prima data se estimeaza efortul crearii un raport mediu (poate media unui raport mic, mediu sau mare). Inmultind efortul mediu cu 40 pentru se obtine estimarea finala.
  • Timeboxing. Metoda prin care estimarile sunt incadrate intre anumiti parametrii prin concentrarea asupra unuia sau ambelor aspecte din "restrictia tripla". Aplicand tehnica timebox proiectul este fortat sa sa se incheie pana la un anumit termen limita. Pentru ca termenul limita sa fie respectat atentia trebuie indreptata catre costul si componentele scope-ului restrictiei triple.

De exemplu, sa presupunem ca se creeaza un program de activitati iar proiectul va fi completat in noua luni insa sponsorul doreste ca durata sa fie de sapte luni.  Cele sapte luni devin "timebox-ul" in care proiectul trebuie terminat. Pentru indeplinirea termenului resursele trebuie folosite mai repede decat anticipat. De asemenea va fi nevoie de mai multe resurse pentru efectuarea activitatilor in paralel, acestea la inceput fiind programate secvential. Exemplele enumerate vor mari costul proiectului iar daca bugetul nu este suficient ar trebui eliminate cateva activitati (scope). Se pot creste costurile, reduce scope-ul sau poate chiar o combinative intre cele doua pentru atingerea termenului limita.

  • Puncte de Functionare. Punctele de functionare sunt folosite de cateva companii de programare IT pentru estimarea activitatilor necesare pentru completare proiectelor de dezvoltare. Punctele de functionare ofera un mecanism pentru aproximarea complexitatii unui aplicatii. Complexitatea este exprimata printr-un numar de punct de functionare. O aplicatie de 1000 de puncte de functionare este de zece ori mai mare si mai complexa decat o aplicatie de 100 de puncte.

Fara a intra in multe detalii punctele de functionare analizeaza marimea aplicatiei din perspectiv utilizatorului. Utilizatorii observa rapoarte, ecrane si poate fisiere de date de asemenea analizeaza functionalitatea afacerii, interfatele catre alte aplicatii, baze de date, tabele etc. O aplicatie cu 80 de ecrane si 20 de rapoarte este probabil mai are decat o aplicatie cu 20 de ecrane si 5 rapoarte. Aceasta perspectiva este independenta de tehnologia folosita sau limbajul de programare. De fapt aplicatia cu ecrane mai putine are probabil nevoie de nivele de codare dar acest lucru nu mai este relevant dimensionarii calculelor.

Estimarea punctelor de functionare nu se poate realiza devreme in procesul de programuire. Insa din moment ce stii numarul de ecrane, rapoarte, fisiere de interfata, tranzactii etc., poti crea o estimare superioara a punctelor de functionare totala. Calculand punctele de functionare pentru mai multe proiecte se va putea estima efortul mediu necesar pentru un punct de functionare. Dupa aceea este vorba numai de folosirea matematicii pentru determinarea efortului total necesar, urmat de durata si cost.


2.2.1.P2 Estimarea in Faze

Determinarea activitatilor necesare in viitor este cel mai dificil aspect ce tine de estimarea proiectelor. Definirea si estimarea activitatilor pe urmatoarele trei luni poate fi complicata. Pentru noua luni este si mai greu. Deciziile si livrabile prouse timpuriu determina desfasurarea urmatoarelor activitati. Incertitudinea estimarilor creste pe masura ce se analizeaza activitatile indepartate.

Cea mai buna abordare consta in impartirea proiectelor mari intr-o serie de proiecte mai mici, astfel fiecare proiect poate fi programuit, estimat si coordonat separat avand o proabilitate mai ridicata de success. (Rationamente similare pot fi identificate in Pasul 1.0 Definirea Activitatilor, impartirea proiectelor mari in mai multe proiecte si coordonarea acestora ca un program).  Cel mai apropiat proiect poate fi estimat mai precis in timp ce la celelalte proiecte creste gradul de incertitudine. Cand un proiect este completat estimarea urmatorului proiect este realizata cu mai multa incredere, estimarile proiectelor ramase fiind revizuite. Aceasta tehnica ofera de asemenea puncte de verificare la sfarsitul fiecarui proiect astfel incat intreaga initiativa sa fie revalidata pe baza estimarilor curente  pentru viabilitate si continuitate.


2.2.1.P3 Estimarea Costurilor Fixe si  a Costurilor Variabile

Costurile fixe si variabile se folosesc la estimarea costurilor unui proiect. Costurile variabile sunt acele costuri a caror modificare este in functie de numarul unitatilor folosite. Un cost variabil evident este contractarea fortei de munca. Cu cat se folosesc mai multe ore de la un contractor sau consultant cu atat creste costul proiectului. Costul utilizarii fortei de munca contractate variaza in functie de numarul orelor lucrate. Cunoasterea costurilor fixe si variabile este importanta pentru determinarea impactului pe care il are cresterea sau scaderea costurilor unitatilor. De exemplu daca un proiect este in urma cu programul de activitati se poate apela la ore suplimentare. Creste numarului de ore lucrate de catre forta de munca contractata implica si cresterea costurilor, in schimb cresterea numarului de ore lucrate de catre angajati s-ar putea sa nu creasca costurile de vreme ce rata de compensatie este fixa.

Costurile fixe sunt aceleasi pentru proiect indiferent de resursele folosite. De exemplu, cantitatea de lemn si ciment folosita la construirea unei case ar fi constanta odata ce proiectarea a fost stabilita. Costul unui lot ar fi fix si nu s-ar modifica in functie de marimea casei construite. Externalizarea unei parti din proiect pentru un pret fix devine un cost fix al proiectului. (Chiar daca activitatile dureaza mai mult sau mai putin decat estimarea realizata, costul proiectului ar trebui continuare cel fixat.)


2.2.1.P4 Estimarea activitatilor constranse din punct de vedere al timpului si al resurselor

Activitatile constranse pot fi clasificate din punct de vedere al timpului sau al resurselor utilizate in functie de modificarea duratei bazata pe folosirea mai multor resurse. O activitate este constransa din punct de vedere al resurselor daca durata se modifica in functie de numarul de resurse utilizate. De exemplu, construirea unui acoperis de catre o singura persoana ar putea fi estimata la 200 de ore. Daca angajatul ar lucra 40 de ore saptamanal constructia ar dura cinci saptamani. Utilizand doi angajati se poate ca efortul sa fie tot de 200 de ore insa durata sa fie de 2 1/2 saptamani. Cinci persoane distribuite si activitatea ar fi terminata intr-o saptamana (desigur durata nu s-ar reduce atat de precis ca in exemplu). O activitate este constransa din punct de vedere al resurselor daca durata se bazeaza pe cantitatea de resurse folosite pentru o activitate.

Pe de alta parte daca o activitate este constransa din punct de vedere al timpului durata ramane aceeasi indiferent de numarul de resurse folosite. De exemplu, participarea la cursuri implica opt ore. Daca participa doua persoane nu se reduce timpul. De asemenea timpul necesar intaririi cimentului sau scrierii unui mail nu depinde de numarul oamenilor implicati. Acestea dureaza o perioada determinata de timp. Daca folosirea resurselor nu are impact asupra duratei proiectului (sau un impact redus) atunci activitatea este constransa din punct de vedere al timpului.


2.2.1.P5 Includerea in estimari a intalnirilor de proiect si a timpului propus colaborarilor

Intalnirile departamentelor sau intalnirile companiei nu pot fi controlate de catre manager si nu intra in programul de activitati sau estimari. Daca intalnirea departamentului a fost stabilita ad-hoc atunci nu exista alta optiune decat acceptarea intarzierilor. Se poate tine cont de intalniri daca se introduce un numar redus de ore disponibile zilnic pentru fiecare resursa (exemplu 6.5 ore pe zi). Desigur daca intalnirile departamentale sunt programate lunar sau trimestrial se poate tine cont de ele la realizarea programului de activitati. Timpul nu va conta mai mult decat bugetul, insa participarea la intalniri va influenta programul de activitati.

Pe de alta parte intalnirile legate de proiect trebuie incluse in programul de activitati si adaugate la estimarea efortului si a costului proiectului.  Echipa detine control asupra acestor intalniri. Managerul proiectului poate acorda saptamanal sau zilnic o ora intalnirilor.

De asemenea se poate apela la inregistrarea timpului total necesar participantilor la orice intalnire legata de proiect (collaborative project-related). De exemplu in explicarea detaliata a livrabilelor trebuie inclus si timpul tuturor participantilor. In cazul rularii documentelor pentru aprobare se include rubrica de feedback pentru persoanele implicate. Includerea de timp pentru fiecare participant este necesara in cazul intalnirilor de evaluare pentru fiecare jalon.


2.2.1.P6 Inceperea printr-un interval estimativ

Sunt multe cazuri in care trebuie estimate superior sarcinile unui proiect sau activitatile individuale. De obicei se cere determinarea unui numar, de exemplu 1000 de ore. Insa, daca este posibil, aceste estimari superioare ar trebui incluse intr-un interval estimativ. Gradul de incertitudine al estimarii este reflectat prin interval. De exemplu, se poate ca o estimare superioara sa fie precisa pana in 50%. In exemplul anterior cu 1000 de ore poti estima activitatile inre 500 si 1500 de ore. O alta metoda pentru acelasi exemplu este estimrea activitatii la 1000 de ore, plus sau minus 50%. In cazul unei incertitudini ridicate marginea de eroare poate fi plus, minus 100% poate chiar mai mult. Insa scopul intervalului este de a ajuta la stabilirea asteptarilor. Estimarea unei parti din munca la 1000 de ore va fi probabil estimarea finala iar indeplinirea acesteia poate fi dificila stiind informatiile de pana acum. Daca se ofera un interval estimativ sansele de reusita cresc pentru estimarile realizate si de asemenea exista o modalitate prin care gradul de incertitudine apare in cifre.



 (insert picture)

 Cu cat este mai precisa estimarea cu atat este mai mare intervalul estimativ.

2.2.1.P7 Folosirea Modelului Monte Carlo pentru Determinarea Riscurilor Programului de Activitati

 Una din metodele folosite pentru recunoasterea incertitudinii in estimari este adaugarea factorului de incertitudine. Factorul de incertitudine este crescut pentru a recunoaste gradul de incertitudine din estimari. Pentru majoritatea poiectelor mici si medii adaugarea unui grad de incertitudine rezonabil este normal si contribuie la o estimare finala realizabila. 

Pentru proiecte mari insa sunt mai multe tehnici bune disponibile pentru estimarea riscului. Cea mai intalnita este modelul Monte Carlo. Modelul Monte Carlo incepe precum tehnica de estimare PERT. In loc sa oferi doar o evaluare furnizezi o serie de estimari ce reprezinta cazul optimist, cazul pesimist si cazul cel mai probabil. Pentru fiecare dintre cazuri atribui de asemenea si o probabilitate.

De exemplu poate sa fie  un procent de 10% de a atinge cazul optimist, 80% cazul cel mai probabil si 10% cazul pesimist. Cu alte cuvinte exista un procent cumulativ de 90% pentru ca activitatea sa fie completata dupa cazul cel mai probabil (10% + 80%) si un procent cumulativ de 100% de realizare a activitatii dupa cazul pesimist (10% + 80% + 10%). Nu trebuie calculate procentul probabil pentru alte cazuri cid oar pentru cele trei. (Tehnic poti oferi estimari pentru toate probabilitatile.)

Urmatorul pas este determinarea acestor estimari pentru fiecare activitate importanta din programul de activitati. De exemplu, o activitate poate fi estimata la in cazul cel mai probabil la 60 de ore, in cazul optimist 50 de ore si in cazul pesimist 90 de ore.  Aceste trei estimari trebuie pregatite pentru sute de activitati din programul de activitati.


Dupa finalizarea estimarilor majoritatea instrumentelor folosite pentru programurile de activitati prezinta functia de simulare Monte Carlo. Modelele simularilor arata evolutia si termenul limita estimativ al proiectului. Programul proiectului este conturat din nou de data asta folosind diferite probabilitati si prin urmare calculand un alt termen limita. Rularea repetitiva a programului este pentru ca procentele de risc sa fie folosite in totalitate.   In exemplu de mai sus  daca simularea a fost rulata de 100 de ori se asteapta ca fiecare activitate  sa aiba cazul optimist de 10%, cazul cel mai probabil de 80% si cazul pesimist de 10%. Cum modelul alege la intamplare valori estimative bazate pe probabilitati diverse scenarii ruleaza. Insa un model de baza incepe sa se contureze permitand estimarea termenului limita. De obicei acest lucru este realizat cautand termenul limita unde proiectul se termina 80% din timp.

Desi in exemplu de mai devreme s-au folosit recurile programului de activitati aceata tehnica se poate folosi de asemenea pentru estimarea costurilor si a efortului de asemenea. Partea pozitiva a simularii Monte Carlo este ca prin estimarea activitatilor in intervale majoritatea instrumentelor vor putea efectua calculele statistice automat. Trebuie doar sa se asigure estimari valide si rezonabile pentru activitati. Toata munca suplimentara necesara in procesul de estimare determina ca acest model sa fie folosit numai pentru proiectele mari si riscante. Proiectele mici si medii nu ar gasi valoare in aceasta tehnica.


2.2.1.P8 Grija la cele mai dese greseli de estimare

Procesul de estimare este o arta si o stiinta in acelasi timp. Insa odata ce s-au invatat procese si tehnici bune de estimare managerul artrebui sa se bazeze mai mult pe partea de stiinta si mai putin pe partea artistica. Poti deveni din ce in ce mai bun la realizarea estimarilor insa nu poti fi perfect. Urmeaza o lista cu cele mai intalnite greseli de estimare ce ar trebui evitate.


  • Nu toate activitatile sunt luate in considerare. Aceasta este o greseala comuna mai ales in cazul estimarile timpurii de la nivelul superior. Se poate omite o parte majora a activitatilor deoarece nu s-a inteles ca acestea fac parte din proiect precum documentatia sau training-urile.

  • Gandire mult prea pozitiva. Oricine a furnizat estimari cunoaste presiunea din partea clientului de a avea costurile pe cat de mici posibile. In cele din urma clientul vrea sa obtina ceea ce are nevoie cu cel mai mic efort (si cost) posibil. In multe cazuri tendinta estimatorului este de a se lasa prins in aceasta gandire de asemenea. Estimatorul sfarseste prin a-si dori ca activitatile sa fie completate incadrandu-se in asteptarile clientului.
  • Orientarea catre cel mai bun scenariu posibil. Clientul doreste realizarea proiectului cat mai repede posibil. Managerul organizatiei doreste realizarea proiectului cat mai repede posibil. Managerul proiectului crede ca se poate realiza rapid. Insa probemele apar deoarece managerul proiectului se gandeste la ce ar fi necesar pentru ca proiectul sa fie terminat daca totul ar decurge conform programului. Managerul se poate gandi la un interval saptamanal al efortului necesar insa de prea mlte ori termina prin a estima la un nivel inferior sau optimist, catre sfarsitul intervalului.
  • Asumarea unor standarde superioare ce nu pot fi suportate. Estimarile se bazeaza pe executarea activitatilor la un anumit nivel de calitate de prima data. Pe masura ce proiectul este executat managerul realizeaza ca abilitatea de a construi la standarde inalte este limitata si ar implica ore suplimentare pentru refacerea activitatilor, repararea problemelor, retestare etc.
  • Programuirea bazata pe bugetul disponibil. Clientul dispune de un buget limitat. Managerul proiectului este de parere ca proiectul se poate realiza in limitele bugetului disponibil astfel incat se angajeaza acelei sume. Acest caz este similar celui mai bun scenariu posibil.
  • Nerecunoasterea estimating biases. Estimating biases se strecoara in estimari tot timpul. Cateva sunt positive in timp ce altele sunt pesimiste. Tendintele optimiste vor duce la subestimarea activitatilor si pot include:
  • o Tendinta de a crede ca activitatile sunt simple.
  • o Tendinta de a supraestima capacitatea echipei de a realize activitatile.
  • o Ignorarea riscurilor proiectului, a situatiilor dificile, a comunicarii deficitare, etc.
  • o Tendinta de a fi optimist in primul rand.

Tendintele pesimiste vor duce la supraestimarea activitatilor si pot include:

  • o Experienta negativa cu un proiect similar in trecut.
  • o Evitarea indeplinirii actvitatilor. Se va supraestima in speranta renuntarii la proiect.
  • o Tendinta de a fi pesimist.

Tendintele vor fi mereu prezente. Cheia consta in a le recunoaste si de a le contracara cand sunt intalnite. Acest lucru va ajuta la pregatirea estimarilor pentru a fi valide pe cat posibil.


2.2.1.P9 Validarea Vechilor Estimari de catre Noua Echipa de Proiect

Echipa de proiect este formata pentru definirea proiectului, creerea programului de activitati si a bugetului continuand cu executarea acestuia. Insa uneori efortul si durata acestuia sunt estimate timpuriu informatiile fiind necesare ca parte a bugetului anual. In aceste cazuri echipa de proiect este creata mai tarziu urmand sa foloseasca estimarile realizate mai devreme. 

Primul task al echipei de proiect este validarea estimarilor deoarece echipa nu ar trebui sa se afle in pozitia de a livra dupa estimarile altor persoane. Daca nu se doreste validarea sau contestarea estimarilor devreme se porneste cu gandul ca acestea sunt precise. Managerul proiectului ar trebuie sa puna estimarile timpuriu sub semnul intrebarii. Daca managerul este de acord cu estimarile trebuie sa te ridici la nivelul efortului, bugetului si a termenelor limita estimate deja. In caz contrar acum este momentul potrivit pentru a semnala aceasta problema.  Organizatia va beneficia in urma acestor verificari. De exemplu, daca estimarile proiectului sunt ridicate atunci costul proiectului / beneficiile proiectului nu sunt cele dorite. Din nou, e mai bine sa se descopere aceste lucruri timpuriu.


2.2.1.P10 A se decide daca se include costurile legate de timpul si efortul clientului

Efortul clientului include timpul pentru analiza si aprobarea livrabilelor, prezentarea cerintelor, participarea la intalniri, participarea la traininguri. Cateva organizatii vor sa inteleaga intregul efort si cost al proiectului, incluzand atat echipa de proiect cat si cerintele clientilor cu privire la resurse (client resource requirements). In alte organizatii costurile proiectului includ exact echipa proiectului. Daca se vor include sau nu orele clientului sau costurile acestuia este o situatie ce trebuie discutata cu managerul organizatiei si cu sponsorul acesteia. Daca estimarile proiectului include orele si costurile clientului, orele trebuie trecute separate. Desi numarul combinat ofera o estimare totala mai buna, managerul proiectului nu este responsabil de resursele clientului si nu ar trebuie sa raspunda de indeplinirea acestor obiective particulare.


2.2.1.P11 Justficarea estimarilor

Dupa efectuarea estimarilor ar trebui ca managerul sa le poata explica in caz in care clientul considera ca sunt prea ridicate. Justificarea ar trebui sa inceapa prin explicarea tehnicilor de estimare folosite, procesele urmate si presupunerile facute. In cazul in care clientul considera in continuare costurile ridicate sau nu-si permite solutia gasita exista cateva optiuni.

  • Sa se determine daca clientul detine informatii suplimentare care pot duce la modificarea presupunerilor si a estimarilor realizate. De exemplu, daca un termen limita critic poate fi revizuit in urma noilor informatii.
  • Sa se determine daca cerintele superioare si functionalitatea pot fi evaluate. In majoritatea cazurilor setul original de caracteristici si functii este mai mult o lista cu dorinte. Este foarte posibil ca clientul sa renunte la anumite facilitati dupa aflarea preturilor.
  • Daca a fost inclus un grad mare de incertitudine pentru a reflecta o un risc estimativ ridicat trebuie cerut clientului timp pentru adunarea mai multor informatii pentru estimare. Incertitudinea si riscurile vor fi reduse, gradul de incertitudine fiind mai mic. (fuzzy idea)
  • Restructurarea proiectului pentru a include numai etapa analizelor detaliate. Dupa completarea analizelor trebuie estimat ce a mai ramas din proiect dupa ce a fost primita confirmarea ca activitatile sunt numai cele cerute. Efortul ca si costul total poate fi mai mic sau nu dar se obtin mai multe informatii pentru sustinerea estimarilor.

2.2.1.P12 Salvarea estimarilor prin realizarea unui pachet estimativ complet

Atunci cand managerului i se cere estimarea unei activitati mari ar trebui prezentat un pachet cu informatii. Nu trebuie sa fie un document consistent, scopul sau fiind prezentarea operatiilor si pasilor urmati. Acest document trebuie prezentat mai ales daca activitatile sunt legate de politica sau daca exista dubii in privinta acceptarii estimarilor.  In locul unei estimari finale sau a unui interval estimativ ar trebui prezentate urmatoarele informatii.

  • Modul in care s-a inteles activitatea ceruta
  • Procesul folosit pentru estimari
  • Tehnicile de estimare folosite
  • Estimarea initiala a efortului ( si durata si cost daca sunt aplicabile)
  • Informatii detaliate despe estimari in caz ca sponsorul ar dori sa analizeze. De exemplu, in cazul crearii unei structure de descompunere a activitatilor se pot include estimarile detaliate ale activitatilor.
  • Presupunerile facute pentru dezvoltarea estimarilor.
  • Gradul de incertitudine din numere este reflectat in intamplari neprevazute sau marimea intervalului estimativ (mai multa incertitudine este reflectata printr-un interval mai mare)

Acesta ar fi un pachet puternic de informatii care sa fie trimis persoanei interesate. In caz ca exista contradictii cu privire la estimarile propuse dosarul ar oferi informatiile pentru a raspunde si in acelasi timp pentru a stopa provocarile contestarea informatiilor va fi dificila. In acelasi timp se poate cere modificarea presupunerilor si incercarea unei tehnici diferite de estimare. Acestea sunt cereri legitime estimarile fiind revizuite in functie de noile criterii.Insa provocarile sunt in legatura cu procesul de estimare si nu se discuta calitatea muncii depuse.


2.2.1.P13 Estimarea bazata pe intelegerea nivelelor de acuratete cerute

Exista mai multe nivele de estimare a acuratetii, in mod normal fiind realizate de catre managerul proiectului in functie de momentul la care estimarea a fost ceruta. Atunci cand proiectul este propus pentru prima data, de exemplu, clientul va cere o estimare generala a efortului, a costului si a duratei proiectului. Dat fiind faptul ca proiectul este vag la momentul respectiv, estimarea nu va fi prea detaliata. In multe cazuri estimarea este folosita numai pentru determinarea marimii astfel incat clientul sa inteleaga daca activitatea va dura 1000 de ore sau 100.000 de ore. Aceasta estimare se numeste ROM si poate sa fie cuprinsa intr-un sir de la -25% pana la +75%. Cu alte cuvinte daca estimarea preliminara aactivitatilor a fost de 1000 de ore poti propue ROM intre 750-1750 de ore. De fapt in acest moment poti sa fii cu 100% mai putin sau mai mult.

Pe masura ce proiectul avanseaza, estimatorul devine din ce in ce mai constient de asteptari si livrabile astfel incat estimarile sunt mai precise de asemenea. Cand un proiect este propus pentru sponsorizare ar trebuie estimate cu mai multa precizie de la -15% pana la +25%. Cu alte cuvinte daca estimarea a fost de 1000 de ore se poate propune un interval de 850 - 1250 de ore.

Cand proiectul incepe, managerul proiectului plus echipa sa trebuie revalidarea estimarilor dupa definirea formala a activitatilor si creerea programului de activitati si a bugetului. Rezultatul estimarilor ar trebui sa fie aproape de la -5% pana la +10%. Estimarea finala a proiectului fiind de 1000 de ore, iar realizarea efectiva a proiectului fiind intre 950 si 1100 de ore. 

ESTIMARE

ACURATETE

SCOP

ORDER OF MAGNITUDE (SCHEMATIC)

-25% - +75%

Evaluarea proiectelor sau a alternativelor

PRELIMINAR (BUGET)

- 15% - +25%

Stabilirea bugetului initial si a fondurilor de rezerva pentru proiect

DEFINITIV

- 5% - +10%

Stabilirea bugetului final dupa Definirea Proiectului


2.2.1.P14 Determinarea Necesarului de Resurse Rezerva

Daca este posibil, managerul proiectului ar trebui sa ceara si sa primeasca un grad de incertitudine estimativ pentru nesiguranta bugetului si a duratei estimate. Natura unor proiecte va cere managerul proiectului sa duca gradul de incertitudine si mai departe. In cadrul unor proiecte trebuie alcatuit un program pentru ceea ce inseamna resurse de rezerva?, cum arata si cum se pot obtine cand sunt cerute. Acestea pot fi resurse ce tin sau nu de forta de munca, precum component hardware, echipament sau materie prima.

Exista un numar de motive pentru care sa programuiesti inainte pentru resurse rezerva.

•·         Timpul este esential. Intr-un proiect general, daca activitatile dureaza mai mult decat fusese anticipat managerul va cere prelungirea duratei si a bugetului. Insa daca termenul limita este critic si nu poate fi devansat nu va exista timp pentru achizitia unor noi resurse atunci cand va nevoie de ele. In acest caz este nevoie de un program deja pregatit pentru a cunoaste de unde pot fi achizitionate si modalitatea de plata.Un exemplu ar fi proiectele YR2K de acum cativa ani. Daca ai fi ajuns in ultimele sase luni din 1999 si ai fi avut inca multe activitati de completat se prea poate sa fi avut un program pregatit din timp pentru completarea proiectului la termen si de asemenea un program pentru angajarea de personal suplimentar daca era nevoie.

•·         Cresterea rapida a costului resurselor. Sunt resurse ale caror cost individual este mult mai mare decat atunci cand sunt achizitionate la gramada. De exemplu, daca solutia folosita implica achizitionarea unor componente hardware, pretul pe bucata scade pe masura ce sunt achizitionate mai multe bucati. Componenetele necesare sunt 100 de rutere, plus minus 10. Vanzatorul poate sa aiba o oferta avantajoasa in cazul achizitionarii la gramada - poate 50 sau 60% din pretul pe bucata. In acest caz se pot cumpara cele 110 bucati imediat folosind 10 unitati ca rezerva. Pretul cumpararii celor zece unitati (parte din gramada) este mult mai mic decat cel al unei achizitionari viitoare, cand costul individual ar fi ridicat.


•·         Timp indelungat intre emiterea unei comenzi si executarea acesteia in cazul resurselor specifice. Resursele specifice se pot obtine dupa un timp indelungat de la emiterea unei comenzi de aceea in caz de necessitate trebuie sa existe reserve. De exemplu se poate lucre cu firme consultante anticipative pentru a gasi resursele specific, precum experti in tehnici complicate stiind ca necesitatea acestora nu este 100% sigura. Firmele lucreaza inainte pentru localizarea acestor persoane si gasirea unor persoane disponibile in caz ca va fi nevoie de ele mai tarziu in proiect.

In majoritatea proiectelor daca este nevoie de mai multe resurse managerul proiectului va vorbi cu sponsorul si revizui programul de activitati si bugetul daca este necesar. Insa in cateva proiecte nu iti permiti timp suplimentar de aceea managerul trebuie sa identifice riscurile din proiect si sa aiba un program pregatit astfel incat sa existe resurse de rezerva in caz ca va fi nevoie. Uneori este nevoie ca resursele sa fie disponibile din punct de vedere fizic. Alte dati trebuie sa se cunoasca locul de unde pot fi achizitionate rapid la nevoie. Nevoia de resurse in cadrul proiectului este in general identificata si coordonata prin procesele managementului de risc, resursele de rezerva fiind un raspuns la un risc specific identificat din proiect.