MANAGEMENT DE PROIECT

IV.MANAGEMENTUL DESFURRII PROIECTULUI

Consideraii generale Se pornete de la premisa c proiectul beneficiaz deja de o programare eficace i c toi participanii la proiect tiu i sunt de acord cu ceea ce se ateapt de la ei. n acest context, proiectul este tratat ca sistem. O cerin esenial pentru orice sistem este existena uneia sau a mai multor metode prin care s se msoare efectul unei comenzi date. Informaiile astfel obinute pot fi folosite ca feedback de sursa comenzii, astfel nct erorile s poat fi corectate prin modificarea comenzii iniiale.

Culegeri de date Pentru orice proiect aflat n desfurare trebuie pus la punct un sistem de comunicare n dublu sens ntre managerul de proiect i managerii departamentelor implicate n realizarea proiectului. Prin acest sistem se trimit instruciunile de lucru de la managerul de proiect i se primesc periodic napoi informaii de feedback despre evoluia lucrrilor. Dac instruciunile de lucru sunt trimise de managerul de proiect ctre participani prin listele de activiti, nu exist nici un motiv pentru care nu s-ar folosi aceeai rut, dar n sens invers. Singura verig lips este un document care s fie complementar listei de activiti. Aceast verig poate fi: un formular special conceput cu rolul de fi de comunicare a evoluiei unei lucrri; informare introdus direct n reeaua de computere; adnotri ale listei de activiti fcute de ctre managerii de departamente. Formularele de raport care cuprind listele de activiti se pot obine uor cu ajutorul unor pachete software specializate dar i cu ajutorul unui simplu editor de text (Word, Word Perfect, Lotus Word etc.), prin concepia machetei i salvarea acesteia ca ablon (template). Capul de tabel al formularului este elaborat n funcie de specificul companiei sau/i al activitilor din cadrul proiectelor. Frecvena colectrii datelor privind desfurarea proiectului depinde de la caz la caz, ns cel mai adesea se utilizeaz intervalele sptmnale. Dac intervalele sunt prea lungi, unele probleme ar putea s nu ias la suprafa suficient de rapid nct msura corectiv s aib efect. n companiile actuale, managerii de departamente (dar i ali angajai!) au adesea acces direct la reeaua de computere. Ei pot cunoate i oferi informaii "n timp real" privind desfurarea proiectului. Managerii de proiect trebuie ns s se asigure c informaiile despre proiect care sunt introduse direct n computer fr s fie supuse mai nti verificrii i examinrii provin doar de la persoane de ncredere. Orice informaie fals sau inexact poate provoca erori privind alocarea de resurse i n listele de activiti. Indiferent de metoda folosit pentru obinerea feedback-ului privind desfurarea proiectului, trebuie evitate ambiguitatea informaiilor i complicaiile inutile. Se ntmpl de foarte multe ori ca un proiect s nu poat fi controlat n mod adecvat tocmai pentru c acest proces nu a fost bine pus la punct. Indiferent dac informaiile privind desfurarea proiectului sunt raportate pe baza unui chestionar tiprit sau sunt introduse direct n computer, sunt necesare de obicei urmtoarele date sau estimri pentru fiecare activitate: 31

MANAGEMENT DE PROIECT

1. Data efectiv a nceperii lucrrilor care au pornit dup ultimul raport; 2. Pentru lucrrile aflate n desfurare: n ce proporie pot fi deja finalizate la data curent a revizuirii; ce durat estimat ar avea dup data curent a revizuirii. 3. Dac activitatea a fost deja finalizat. 4. Pentru o activitate finalizat, care a fost data finalizrii. Dac informaiile privind desfurarea proiectului se strng pe formulare tiprite apare o alt ntrebare pentru care un bun manager de proiect trebuie s gseasc un rspuns potrivit pentru fiecare sarcin raportat ca finalizat. Aceast ntrebare vital este: "Poate s nceap activitatea care urmeaz imediat dup cea n discuie?". Dac logica organizrii este corect, atunci o activitate nu poate fi raportat ca 100% finalizat dect dac cea imediat urmtoare poate s nceap. n realitate se ntmpl de multe ori ca unele activiti s se raporteze ca ncepute, dei exist una sau mai multe activiti predecesoare nc nefinalizate, ceea ce contravine logicii pe care se bazeaz proiectul. O asemenea situaie trebuie acceptat i raportat ca atare ns va avea explicaia (n cazul programelor pe computer eticheta) "n afara secvenei". Practica verificrilor privind desfurarea proiectului a validat i alte metode precum mana gementul prin deplasarea n teren i verificrile statistice. Prima dintre ele precizeaz c un bun manager de proiect trebuie s fie dispus din cnd n cnd s renune la rutin: el va trebui s-i prseasc biroul ca s fac vizite i controale la faa locului i s urmreasc evoluia concret a lucrurilor cu proprii lui ochi. A doua metod presupune verificri ocazionale. Cifrele aflate pot fi apoi comparate cu cele planificate pentru data respectiv. Se pot afla lucruri interesante privind folosirea corect sau incorect a resurselor. Stabilirea prioritilor Pot aprea situaii n care departamentele de producie s nu poat executa lucrrile ntr-o ordine care s convin tuturor proiectelor aflate n desfurare. Dac departamentul de urmrire a produciei ar avea posibilitatea s adune toate comenzile i s le ncar ce succesiv sau conform propriilor grafice de lucru ale oamenilor i utilajelor, nu ar aprea nici o problem serioas. Dar, mai devreme sau mai trziu, apare precis o comand urgent sau o reealonare n avans a unei comenzi existente, iar departamentul de urmrire a produciei este nevoit s amne alte comenzi n favoarea ei. n unele organizaii se ncearc s se stabileasc o ordine de proiritate pentru comenzi, crora li se aplic un cod sau o liter, de exemplu A, B sau C care s indice urgena cu care trebuie executate. Nu este greu de imaginat de ce un asemenea sistem nu are sori de izbnd. O comand notat cu C ajunge s tot fie amnat pn devine ea nsi critic i, cu toate acestea, rmne tratat ca grad C. Pn la urm, toat lumea i consider comenzile ca fiind de grad A, toate lucrrile trebuie s fie gata n acelai moment i nimic nu mai poate beneficia de o atenie special. Un aranjament mai bun este programarea comenzilor pe baza termenelor de predare. Departamentul de urmrire a produciei poate ncerca s programeze lucrrile astfel nct s respecte aceste date sau s i informeze pe cei care nu i pot primi lucrarea la timp. Apoi, dac una sau alta dintre lucrrile proiectului risc s depeasc o dat de predare critic, se poate lua n considerare subcontractarea ei la o alt companie.

32

MANAGEMENT DE PROIECT

n seciile de producie se ntmpl ca de foarte multe ori lucrrile care fac parte dintr -un proiect s i gseasc loc n paralel cu activitatea de producie obinuit sau cu comenzile pentru alte proiecte. Astfel, pot aprea conflicte ntre mai multe comenzi cu aceleai prioriti. De multe ori este nevoie de o persoan care s intervin n conflictul dintre doi manageri de proiect care se lupt pentru aceleai resurse. Calea logic de conciliere a prioritilor lucrrilor din mai multe proiecte este aplicarea unor metode corecte de programare a resurselor. Din pcate, dac vd c proiectul le este amnat n favoarea altor activiti, unii manageri de proiect nu sunt deloc sensibili la logic. Dac aceste conflicte nu pot fi rezolvate pe loc fr s degenereze, o abordare neleapt este s se recurg la un arbitru imparial preferabil un manager din ealonul superior, capabil s evalueze prioritile relative ale comenzilor n cauz. Programarea resurselor: principii, realizare practic Programarea resurselor este un subiect complex care poate fi privit din mai multe puncte de vedere. La nivel de strategie, ea este considerat un element important folosit de majoritatea companiilor industriale mari n constituirea planurilor pe termen lung. n continuare ns, acest subiect este tratat din punctul de vedere al managerului de proiect. n companiile care se bucur de for de munc stabil, unde securitatea locului de munc i posibilitatea planificrii unei lungi cariere profesionale sunt plasate sus pe scara factorilor de motivare a personalului, programarea resurselor poate fi privit ca procesul de identificare a resurselor disponibile pentru proiecte i apoi de distribuire eficient a acestora n aa fel nct s se poat realiza obiectivele propuse. ns numrul organizaiilor care mprtesc aceast viziune a devenit tot mai mic n ultimii ani. Multe ncep acum s-i examineze cerinele de organizare i i ajusteaz numrul de angajai n funcie de rezultate ceea ce duce, cel mai adesea, la reduceri de personal. n sectoarele sau n companiile unde se folosete n proporie mare mna de lucru sezonier sau unde o mare parte a activitii se realizeaz prin subcontractri, programarea intern i n detaliu a resurselor se poate limita la personalul relativ mic angajat permanent. Dar chiar i aici este nevoie s se cunoasc dinainte cam care va fi necesarul de resurse, pentru a se putea averiza subcontractorii. Organizaiile care execut proiectele cu ajutorul forei lor de munc permanente, ocupat fie n cercetare, fie n producie sau n construcii, trebuie s trateze foarte serios problema pro gramrii resurselor. Ele vor trebui s alctuiasc programe de lucru detaliate care s satisfac necesarul fiecrui proiect n parte i care s ofere, totodat, o privire de ansamblu asupra solicitrilor exercitate asupra volumului de munc. Efectul posibil al prognozelor ar trebui testat, de preferin cu ajutorul modelului "ce s-ar ntmpla dac?". Ori de cte ori se discut despre programarea resurselor, numit uneori i alocare, ajustare sau distribuire, se constat c aproape toat lumea se gndete c resursele sunt, de fapt, oamenii. Dar programarea poate viza i alte resurse, cum ar fi instalaiile, mainile, materiile prime i banii. Tratamentul acestor resurse non-umane este similar programrii forei de munc, singurele lucruri care difer fiind denumirile i unitile de msur. Spaiile de lucru sunt o resurs foarte dificil sau poate chiar imposibil de programat din cauz c suprafeele sau volumele de lucru necesare sunt, foarte adesea, complexe.

33

MANAGEMENT DE PROIECT

Studiu de caz: proiect pentru construirea unui garaj Principiile programrii resurselor i cteva dintre problemele care apar pot fi ilustrate cu ajutorul unui proiect de construcii foarte simplu construirea unui garaj. Definirea proiectului o firm de construcii primete comanda s monteze un garaj. Cldirea trebuie s fie de crmid i cu un acoperi din plci ondulate. n acoperi trebuie ncorporate folii ondulate din material transparent care s serveasc drept luminatoare. Uile trebuie s fie din lemn, cu rame i balamale metalice. Proiectul nu prevede ridicri de greuti i nici o activitate nu necesit mai mult de doi oameni. Resursele disponibile se angajeaz o mic firm pentru realizarea proiectului, firm la care lucreaz o echip format din tat i fiu. Tatl este un om policalificat, cu mult experien iar fiul este harnic, plin de energie dar fr nici o experien sau pricepere special. Lista resurselor disponibile ale firmei const dintr-un lucrtor calificat i unul necalificat. Aa cum s-a spus ntr-un capitol anterior, o alt metod de programare i planificare este analiza de reea. Reeaua acestui proiect este prezentat n fig.IV.1. Varianta cu sgei a acestei reele este prezentat n fig. IV.2. Pentru simplificare se presupune c materialele i utilajele necesare se afl deja pe antier atunci cnd este nevoie de ele. Fig.IV.1 urmrete claritatea i nu este standard. Toate duratele au fost estimate n zile i presupun prezena unui singur meter policalificat ajutat acolo unde este cazul de un muncitor necalificat. Rezultatele analizei timpilor sunt redate n tabelul IV.1 unde sunt definite i caracteristicile sarcinilor. Dac se presupune c toate termenele minime de execuie pot fi respectate i dac se ignor posibilele limitri de resurse, tot proiectul va dura 24 de zile lucrtoare. Dar n reea sau n analiza timpilor din ea nu exist nici o indicaie direct privind numrul de muncitori necesar pentru a realiza acest lucru.
Tabelul IV.1. Rezultatele analizei timpilor pentru proiectul garajului
ncepe cel mai trziu ncepe cel mai devreme Se termin cel mai devreme Se termin cel mai trziu Codul DP Codul DS Marja total 0 0 4,5 4,5 0 0 16,5 3 0 0 2 17 17 19,5 19,5 11 11 16,5 16,5 4 0 0 2 Durata

Denumirea

Resurse

START G0102 G0205 G0103 G0305 G0508 G0810 G0110 G016 G1012 G1214 G1216 G0104 G0411 G1115 G1518 G0509 G0913 G0107 G0713 G1317 G1718 G1417 G1618 STOP

1-2 2-5 1-3 3-5 5-8 8-10 1-10 10-16 10-12 12-14 12-16 1-4 4-11 11-15 15-18 5-9 9-13 1-7 7-13 13-17 17-18 14-17 16-18 -

nceperea proiectului Sparea fundaiei Betonarea fundaiei Confecionarea i ajustarea cadrului uilor Poziionarea cadrului uilor Asezarea crmizilor Asezarea grinzii la u Tierea grinzilor pentru acoperi Acoperirea grinzii de la u i construirea streinii Montarea grinzilor pentru acoperi Podirea tavanului Aezarea tablei pe acoperi Sparea anului de scurgere Turnare pietri i aezare eav n an de scurgere Umplere an de scurgere Astuparea anului cu un capac de beton Turnare pardoseal Finisarea pardoselii Confecionarea uilor Ajustarea uilor Montarea uilor Vopsire Montarea jgheaburilor i a burlanelor de scurgere Izolarea acoperiului Predarea proiectului

4 2 1 0,5 10 1 0,5 2 2 1 1 2 1 0,5 1 2 1 3 0,5 1 3 1 1

0 4 0 1 6 16 0 17 17 19 19 0 2 3 3,5 6 8 0 3 16 21 20 20

4 6 1 1,5 16 17 0,5 19 19 20 20 2 3 3,5 4,5 8 9 3 3,5 17 24 21 22

0 4 4,5 5,5 6 16 16,5 20 17 19 21 17 19 21 17 19 22,5 23 17 19 16,5 20 22

4 6 5,5 6,0 16 17 17 22 19 20 22 19 20 23 24 19 20 19,5 20 21 24 21 24

1N 1N 1C 1C 1C, 1N 1C, 1N 1C 1C, 1N 1C, 1N 1C 1C 1N 1C, 1N 1N 1N 1N 1C 1C 1C 1C, 1N 1C 1C 1C

34

MANAGEMENT DE PROIECT

35

MANAGEMENT DE PROIECT

36

MANAGEMENT DE PROIECT

Primul pas care se face pentru stabilirea necesarului de for de munc este s se converteasc reeaua ntr-o diagram cu bare, prezentat n tabelul IV.2. Fiecare bar orizontal reprezint o activitate din reea i are lungimea proporional cu durata estimat a acesteia. Scara de timp a fost fcut astfel nct s se in seama de zilele libere. Nu s-a inut seama de srbtorile legale, dar, dac ntr-o situaie real ar aprea, va trebui neaprat s se in seama de ele. Prin adugarea zilelor libere, durata minim a realizrii garajului este de 32 de zile calendaristice.
Tabelul IV.2. Programarea resurselor n proiectul garajului ACTIVITATEA (*=activitate critic)
1-2 2-5 1-3 3-5 5-8 * Sparea fundaiei * Betonarea fundaiei Confecionarea i ajustarea cadrului uilor Poziionarea cadrului uilor * Aezarea crmizilor

MAI
4 5 6

IUNIE
7 10 11 12 13 14 17 18 19

13 14 15 16 17 20 21 22 23 24 27 28 29 30 31 3

8-10 * Aezarea grinzii la u 1-10 10-16 Tierea grinzilor pentru acoperi Acoperirea grinzii de la u i construirea streinii

10-12 * Montarea grinzilor pentru acoperi 12-14 * Podirea tavanului 12-16 Aezarea tablei pe acoperi 1-4 Saparea anului de scurgere 4-11 11-15 15-18 5-9 9-13 1-7 7-13 13-17 Turnarea pietriului i aezarea evii de scurgere n an Umplerea anului de scurgere Astuparea anului cu un capac de beton Turnarea pardoselii Finisarea pardoselii Confecionarea uilor Ajustarea uilor Montarea uilor

17-18 * Vopsire 14-17 * Montare jgheaburi i burlane de scurgere 16-18 Izolarea acoperiului Echivalenele cu zilele din reea Muncitor calificat Muncitor necalificat

1 3 2

2 2 2

3 2 2

4 1 2

5 2

6 1

7 1 2

8 1 2

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 1 1 -

Dac proiectul trebuie s se termine la timp, contractorul poate decide s foloseasc smbta dimineaa (nu apare n diagram) ca marj de timp pentru situaiile neprevzute. Serile pot constitui o alt marj de timp. Dar aceste ore suplimentare de lucru posibile sunt nite rezerve acunse i nu trebuie incluse n planul iniial. Toate activitile ilustrate n diagrama cu bare din tabelul IV.2 ncep la cea mai devreme dat posibil i resursele necesare la realizarea lor zi de zi se obin simplu prin nsumarea barelor de o anumit culoare (sau haur) n coloana fiecrei zile. Utilizarea zilnic a resurselor este n partea de jos a tabelului, dar apare mult mai clar n histograma din tabelul IV.3. Rezultatul este nesatisfctor deoarece n unele zile fora de munc este complet nefolosit iar n altele este nevoie de trei oameni. Volumul de munc este distribuit inegal, cu vrfuri i goluri.

37

MANAGEMENT DE PROIECT

Tabelul IV.3. Histograma resurselor n proiectul garajului DATA MAI

13 14 15 16 17 20 21 22 23 24 27 28 29 30 31 3 4 5 6

IUNIE
7 10 11 12 13 14 17 18 19

Muncitor calificat Muncitor necalificat

3 2 1 3 2 1

Aceasta nseamn fie c executantul proiectului poate i vrea s i mute tot timpul oamenii de pe un antier pe altul, fie c accept alternativa perdant de a plti i pentru timpul nemun cit, situaii ntlnite foarte des, din pcate. Cauza dezechilibrului este faptul c palnificatorul a reprezentat fiecare activitate ca ncepnd la cea mai devreme dat posibil, indiferent de necesitate i de prioriti. Planurile de acest tip se numesc "planuri cu resurse agregate", utilitatea lor practic fiind c reprezint o etap spre realizarea altui tip de plan, mai practic, numit "plan cu resurse repartizate". Dac proiectul garajului este executat doar de echipa format din tat i fiu, este clar c programul din tabelul IV.2 nu poate fi aplicat. El trebuie rearanjat n aa fel nct puinele resurse s nu apar simultan de dou ori. Aceasta se poate face mutnd activitile pn nu mai avem n nici o coloan mai mult de cei doi oameni existeni. Trebuie ns avut n vedere logica reelei, cu respectarea tuturor constrngerilor existente. Astfel tabelul IV.4 reprezint diagrama cu bare a proiectului garajului dup nivelarea fcut pentru a putea programa resursele disponibile, care sunt limitate. Constrngerea provocat de limita de resurse prelungete scara de timp cu 12 zile calendaristice, mrind durata proiectului de la 32 de zile la 44. n schimb, avem un program uniformizat, perfect pentru firma cu cei doi oameni. Noul program s-ar putea s nu fie acceptabil pentru client, care ateapt s i se livreze un automobil scump i vrea neaprat s i-l in, n siguran, n garaj. Dac garajul nu este gata la timp, clientul poate hotr, pe bun dreptate, s recurg la un alt contractor. n aceste condiii, firma format din tat i fiu poate aciona astfel: 1. S lucreze conform programului cu resurse limitate, de 44 de zile, promind ns clientului livrarea garajului n 32 de zile. Nu este ns recomandabil s se mint i s se fac promisiuni false, att din motive comerciale ct i morale. 2. S-l anune pe client c proiectul nu poate fi terminat n 32 de zile i s piard comanda n chip de pedeaps pentru spunerea adevrului aa cum este el. 3. S revin la primul program, cel n care resursele sunt "agregate" i s mai angajeze civa lucrtori, indiferent de costuri, pentru a putea termina proiectul n 32 de zile. 4. S-i planifice s-i termine proiectul n cele 32 de zile impuse, s accepte ideea c s-ar putea s trebuiasc angajai mai muli lucrtori, dar s revizuiasc i s modifice programul cu resurse agregate n aa fel nct optimizarea ncrcrii forei de munc s se fac mai eficient din punctul de vedere al costurilor. De obicei se alege opiunea a 4-a i, chiar i aici, n proiectul garajului, ea funcioneaz bine. Trebuie reinut c reprogramarea activitilor se poate face doar n limitele constrngerilor dictate de logica reelei, astfel nct s nu se programeze nceperea unei activiti nainte de terminarea celei care o precede. Mai mult, dac termenul de predare rmne acelai, nici o 38

MANAGEMENT DE PROIECT

activitate nu trebuie planificat mai trziu de timpul su maxim admis de pornire, adic dincolo de cea mai trzie dat la care i se poate permite s nceap n cadrul analizei timpilor de reea. Aceasta nseamn c activitile care nu sunt critice pot fi ntrziate att ct le permite marja de timp. Activitile critice au marja zero, de aceea trebuie programate s nceap ct mai devreme posibil.
Tabelul IV.4. Optimizarea programului prin folosirea resurselor disponibile ACTIVITATEA (*=activitate critic) MAI
13 14 15 16 17 20 21 22 23 24 27 28 29 30 31 3 4 5 6

IUNIE
7 10 11 12 13 14 17 18 19 20 21 24 25

1-2 * Sparea fundaiei 2-5 * Betonarea fundaiei 1-3 Confecionarea i ajustarea cadrului uilor 3-5 Poziionarea cadrului uilor 5-8 * Aezarea crmizilor 8-10 * Aezarea grinzii la u 1-10 10-16 Tierea grinzilor pentru acoperi Acoperirea grinzii de la u i construirea streinii

10-12 * Montarea grinzilor pentru acoperi 12-14 * Podirea tavanului 12-16 Aezarea tablei pe acoperi 1-4 Saparea anului de scurgere 4-11 11-15 15-18 5-9 9-13 1-7 7-13 13-17 Turnarea pietriului i aezarea evii de scurgere n an Umplerea anului de scurgere Astuparea anului cu un capac de beton Turnarea pardoselii Finisarea pardoselii Confecionarea uilor Ajustarea uilor Montarea uilor

17-18 * Vopsire 14-17 * Montare jgheaburi i burlane de scurgere 16-18 Izolarea acoperiului Echivalenele cu zilele din reea Muncitor calificat Muncitor necalificat

1 1 1

2 1 1

3 1 1

4 1 1

5 1 1

6 1 1

7 1 1

8 1 1

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 -

Tabelul IV.5 reprezint histograma versiunii nivelate a programului cu resurse limitate care ilustreaz clar rezultatul nivelrii consumului unor resurse. Programul rezultat este numit program cu resurse limitate.
Tabelul IV.5. Histograma versiunii nivelate a programului cu resurse limitate MAI DATA
13 14 15 16 17 20 21 22 23 24 27 28 29 30 31 3 4

IUNIE
5 6 7 10 11 12 13 14 17 18 19 20 21 24 25

Muncitor calificat Muncitor necalificat

3 2 1 3 2 1

39

MANAGEMENT DE PROIECT

edinele de proiect Organizarea unei edine intr n atribuiile persoanei care o conduce i aceasta este de cele mai multe ori nsi cea a managerului de proiect. n cazul proiectelor de producie, edinele de analiz a stadiului de execuie pot fi conduse de ctre managerul departamentului de producie. n cazul oricror edine trebuie fcute unele aranjamente de natur administrativ: se rezerv o sal de edine; se verific materialele de prezentare i cele audio-vizuale; se verific dac ventilaia este adecvat; se ntmpin participanii i invitaii; se fac aranjamente speciale pentru a evita ntreruperile (de exemplu se pun afie pentru deconectarea telefoanelor mobile); se asigur bufet sau cafea, dup caz. Toi invitaii la edin trebuie s primeasc din timp agenda edinei, pentru a avea timp s i pregteasc materialele. Dac exist participani din alte localiti trebuie s li se asigure cazarea iar ora de ncepere trebuie aleas astfel nct acetia s poat participa. edina nu se programeaz dimineaa devreme pentru a nu dezavantaja pe cei ce vin de la distan mai mare. Unii sunt de prere s se fixeze edina spre sfritul dup-amiezei pentru ca s nu se prelungeasc inutil. Pe de alt parte, participanii sunt mai activi i mai creativi n timpul zilei, avnd mai multe anse s rezolve n comun problemele care se ivesc. Oricum, managerul de proiect sau persoana desemnat cu organizarea edinei va trebui s decid cnd este cel mai bine s convoace oamenii, n funcie de situaie i de participanii avui n vedere. O modalitate simpl de a conduce edina este utilizarea unei fie concepute de ctre Trevor Bentley n 1976 i prezentat n fig.IV.3. Persoana care conduce edina trece pe fi agenda i lista participanilor dup care, eventual, stabilete de comun acord cu ei locul i data desfurrii. Apoi trebuie s distribuie tuturor participanilor cpii dup acest formular, de preferin cu o sptmn nainte de edin. n timpul edinei, conductorul acesteia i folosete fia pentru a nota ceea ce s-a discutat, dup ce verific, pe baza ei, prezena la ntlnire. Poriunile referitoare la decizii i msuri sunt completate pe parcursul edinei. Fi de edin
Data, ora i locul: Nr. ref. edin/proiect:

Participani

Sedin programat de: Scopul edinei i agenda:

Decizii:

La ncheierea edinei, fiecare participant primete o copie dup fia completat. n plus, Msuri convenite Rspunde toate deciziile i msurile adoptate sunt notate exact aa cum au fost formulate n timpul edinei. Bentley recomand trimiterea unei cpii dup fi i superiorului celui care a condus edina. Astfel dac o edin nu ajunge Fig.IV.3 Model de fi de edin la decizii sau msuri corespunztoare, conductorul ei este obligat s justifice de ce a mai convocat-o.

Termen

40

MANAGEMENT DE PROIECT

Conflicte ntr-o edin pot aprea uneori conflicte, ceea ce ntotdeauna este un lucru ru. edinele trebuie s i pstreze un ritm alert, iar entuziasmul oamenilor trebuie ncurajat cu condiia ca tensiunea pe care o genereaz s nu depeasc anumite limite dup care un conflict nu mai poate fi aplanat. Totui este bine ca un conflict care apare n timpul unei edine s fie rezolvat n timpul aceleiai edine, nainte ca participanii s se risipeasc. Altminteri pot aprea friciuni care nu mai au nimic comun cu entiziasmul i cooperarea n echip. n timpul desfurrii unui proiect, responsabilitile sunt adesea mprite ntre mai multe departamente, iar atunci cnd apar deficiene sau se produc neglijene, ele pot arunca vina unul pe altul. De multe ori se ntmpl ca defectele de fabricaie s fie cauzate de greeli de proiectare, iar ntrzierea unei execuii poate fi pus pe seama zelului nejustificat al unui inspector de calitate. Uneori asemenea critici sunt justificate, alteori nu, ns atunci cnd apar conflicte, ele trebuie rezolvate prompt i nu trebuie lsate s persiste i s perturbe armonia echipei de lucru. Managerul de proiect este obligat s depisteze cauzele reale ale unei deficiene i s afle precis din ce departament provin, i aceasta nu pentru a da vina unul sau pe altul, ct pentru a se asigura c mersul lucrrilor nu va mai fi perturbat. De multe ori apar mai multe justificri, diferite i incompatibile, din partea mai multor departamente. Astfel de conflicte pot fi depite ntr-un singur fel: confruntarea deschis a adversarilor n prezena unui mediator. n astfel de situaii participanii se sfiesc s abuzeze de scuze sau explicaii care se abat de la strictul adevr pentru c se pot atepta la reacii i critici prompte de la ceilali. n plus, comunicarea direct elimin ntrzierile pe care le-ar crea mesajele impersonale ntre departamente, permind gsirea pe loc a unor soluii sau compromisuri. Raportri privind stadiul proiectului Raportrile interne privind stadiul unui proiect, adresate conducerii, trebuie s precizeze aspectele tehnice curente, stadiul de execuie al lucrrilor i situaia financiar, comparnd rezultatele acestora cu prevederile din plan. Pentru proiectele mai ndelungate de 1-2 luni, astfel de rapoarte sunt ntocmite periodic i sunt prezentate de managerul de proiect n edinele de proiect. Discutarea acestor rapoarte declaneaz uneori decizii manageriale importante care pot fi urmate de schimbri majore n sistemul contractual al companiei sau n modul de organizare a proiectului. Prin urmare, rapoartele trebuie s se refere la date relevante pentru situaia i managementul de proiect, care s fie bine documentate i susinute, acolo unde este nevoie, de estimri atente i explicaii judicioase. Aceste rapoarte pot conine i detalii de natur confidenial motiv pentru care ele trebuie s aib o circulaie limitat doar la membrii conducerii companiei. Rapoartele asupra excepiilor se refer doar la aspectele critice ale proiectului care genereaz cele mai mari griji i care impun atenia cea mai mare. Atunci cnd se refer la costuri, excepiile sunt numite "abateri" pentru c reprezint diferene n plus sau n minus ale rezultatelor fa de prevederile bugetului. nainte de a lsa ca un astfel de raport s ajung la nivelul conducerii, managerul de proiect trebuie s se asigure c nu gsete singur remediul. Dar odat ce stabilete fr putin de ndoial c lucrurile i scap de sub control, managerul de proiect are datoria s ntiineze conducerea fr ntrziere.

41

MANAGEMENT DE PROIECT

Rapoartele ctre clieni sunt de obicei stipulate n clauzele contractuale. Pentru acestea se pot utiliza aceleai surse de date ca i pentru rapoartele interne. ns clientul ar putea s nu fie interesat n mod special de unele detalii tehnice sau s le considere irelevante. Prin urmare, rapoartele ctre clieni pot fi versiuni prescurtate ale celor interne. Obligaia de a prezenta i rapoarte financiare intermediare variaz de la caz la caz. n anumite condiii, estimrile privind costurile i profitul sunt considerate confideniale i nu se comunic n afara organizaiei. n alte cazuri, managerul de proiect are obligaia de a prezenta informaii generale sau estimri mai detaliate despre costuri. Chiar dac rapoartele ctre clieni trebuie ntocmite mai sintetic, ele nu trebuie totui s creeze impresii eronate, sau mai ru, s nele cu bun tiin. Clientul trebuie neaprat informat cu privire la evoluia real a lucrrilor, mai ales dac apar ntrzieri care nu pot fi recuperate la timp. Orice tentativ de camuflare a greelilor prin previziuni optimiste sau promisiuni nefondate are n cele din urm efecte nedorite.

Mecanisme de control ale schimbrii Nu exist nici un proiect care s se desfoare de la nceput pn la sfrit fr nici o schim bare. Un asemenea proiect ar fi realmente utopic. n acest context, convenim s numim modificare orice abatere de la specificaiile sau planurile iniiale ale proiectului. Astfel de modificri pot surveni ca urmare a cererilor clientului, pot fi aduse de autori sau pot fi abateri ale execuiei fa de planul, specificaiile sau instruciunile adoptate pentru proiect. Un mod de clasificare a modificrilor este de a le eticheta ca finanate sau nefinanate. Pentru o modificare finanat, clientul i asum responsabilitatea i pltete; pentru o modificare nefinanat, contractorul trebuie s suporte costurile asociate i risc s depeasc bugetul sau s rmn fr prea mult profit. Dac o modificare este sau nu finanat determin n mare msur felul n care este tratat i autorizat. Modificrile finanate, cu alte cuvinte cele cerute de client, implic automat o m odificare a contractului, deoarece specificaiile reprezint o component a documentaiei contractului. Dac este aa cum se ntmpl de obicei, modificrile au ca efect creterea costurilor: n aceste cazuri preul proiectului trebuie i el negociat. De asemenea, trebuie discutat i convenit noul calendar al lucrrilor. Pe de o parte, modificrile finanate de client pot avea efecte perturbatoare asupra desfurrii logice a unui proiect. Pe de alt parte, ele pot fi compensate printr-o cretere a preului i eventual o cretere a profitului. Oricum ar fi modificrile cerute de client, de obicei acestea se soldeaz cu acte adiionale la contract. Modificrile nefinanate, adic acelea dorite de contractor, nu vor fi suportate de ctre client dect n unele situaii care au fost prevzute din start n contract. Prin urmare, contractorul trebuie s-i suporte costurile din resursele proprii, s claseze lucrrile ncepute i devenite inutile i s rspund n faa clientului fa de eventualele ntrzieri. Din acest motiv, un contractor este foarte precaut s autorizeze asemenea modificri. De obicei, modificrile nefi nanate sunt lansate prin diferite tipuri de documente interne, cum sunt comenzile de modifi care a proiectului. n producie, problemele pe care le detecteaz cei implicai n execuie sau n controlul de calitate sunt transmise celor de la proiectare, cu documente justificative.

42

MANAGEMENT DE PROIECT

Modificrile mai pot fi clasificate ca permanente i temporare. Modificrile permanente sunt cele ncorporate definitiv n concepia i execuia proiectului. Dup terminarea proiectului, ele rmn nregistrate n desenele de execuie, schie sau specificaii, pentru a se pstra o imagine real a produsului, aa cum este el realizat. Modificrile temporare sunt cele care ar putea fi utile pentru accelerarea execuiei proiectului; ele urmeaz s fie ndeprtate din proiect sau s fie convertite n modificri permanente, la momentul potrivit. Indiferent dac o modificare este cerut sau nu de client, efectele ei pot fi simite i n alte puncte, nu numai n aria direct afectat. Acest lucru este deopotriv de valabil pentru aspectele tehnice, financiare sau de calendar. Un proiect trebuie privit ca un sistem comercial i tehnic n care o modificare la una din componente poate produce o reacie n altele, ducnd la consecine pe care iniiatorul modificrii nici nu le-a putut bnui. Prin urmare, este prudent ca orice modificare s fie analizat cu atenie de cel puin un membru cheie al fiecrui depar tament implicat n proiect, pentru ca efectul total s fie estimat ct mai corect. Foarte multe companii procedeaz la analiza modificrilor de ctre o comisii de experi. Cnd se prezint o cerere de modificare la proiect, nainte de a lua deciziile, cel numit sau comisia trebuie s cntreasc toate consecinele posibile. Vor trebui luate n considerare elementele de mai jos: Poate fi adoptat modificarea cerut? Cine a cerut modificarea clientul sau executanii proiectului? Dac modificarea nu este cerut de client, este ea realmente necesar? Care este costul estimativ al modificrii? Cum se modific preul proiectului? Va suporta clientul costul modificrii? Care va fi efectul asupra desfurrii proiectului? Cum vor fi afectate sigurana i performana produsului/serviciului realizat? Dac producia se refer la o serie de produse identice, n ce punct al fluxului de fabricaie trebuie introdus modificarea? Se ateapt la rebuturi i deeuri? Exist componente deja executate i care trebuie modificate? Ce desene de execuie, specificaii sau alte documente trebuie modificate? Dup ce se d cte un rspuns la fiecare dintre ntrebrile de mai sus, se poate lua una dintre urmtoarele decizii: S se autorizeze modificarea aa cum a fost cerut. S se dea o aprobare limitat i/sau modificarea s se aplice doar ntre anumite limite. S se refuze pentru moment cererea pn la obinerea unor clarificri suplimentare sau pn la gsirea unei soluii alternative. S se resping modificarea, oferind motivaii. n orice organizaie este bine s existe o persoan nsrcinat special cu coordonarea modificrilor care poate avea i alte atribuii. Aceasta trebuie s se ocupe cu urmtoarele: nregistrarea cererilor de aprobare a modificrilor i repartizarea numerelor de referin. Distribuirea i ndosarierea cpiilor cererii de aprobare a modificrii. Aducerea cererilor de aprobare a modificrii n faa comisiei de aprobare, fr ntrzieri nejustificate. Distribuirea i ndosarierea documentelor privind aprobarea modificrii.

43

MANAGEMENT DE PROIECT

Urmrirea implementrii modificrilor aprobate i a actualizrii desenelor, schielor, schemelor, documentaiei etc.

La primirea unei cereri de aprobare a modificrii, coordonatorul trebuie s noteze ntr-un registru cteva detalii care se pot dovedi utile ulterior. Tabelul IV.6 ilustreaz o fil formular cu destinaie universal dintr-un asemenea registru.
Tabelul IV.6 Formular dintr-un registru privind o modificare la un proiect Nr. proiect REGISTRU Pentru modificri de proiect i aprobri de lansare n fabricaie Nr. Iniiat de: serie Descriere/Denumire Data cererii Aprobare (Da/Nu) Data distribuiei finale Modificare de pre (+/-) Nr. pagin

. . .

. . .

. . .

. . .

. . .

. . .

. . .

O organizaie care lucreaz pe baz de proiecte poate ajunge uneori la concluzia c a ajuns ntr-un moment dup care orice modificare de concepie este prea greoaie, neconvenabil sau chiar perturbatoare pentru a fi acceptat. ntr-o Modificare la proiect Nr. proiect: asemenea situaie se poate decreta "nghearea Nr. versiune proiectului", comisia de aprobri refuznd s mai Data emiterii ia n considerare vreo cerere de modificare, n Coninutul modificrii: lipsa unor motive extrem de serioase, cum ar fi sigurana n exploatare a produsului sau cererile exprese ale clientului. Ideal ar fi ca i clientul s Efectul scontat asupra calendarului lucrrilor: accepte la un moment dat c proiectul nu mai poate fi schimbat. Modificrile cerute de client care au impact asupra preului, termenului de predare sau orice alt aspect al contractului iniial necesit o documentaie formal. Aceasta, ilustrat n fig. IV.4, trebuie s ndeplineasc urmtoarele funcii: s indice i s descrie schimbrile n contract sau n comand; s autorizeze contractorul s realizeze modificarea; s conin o clauz privind plata lucrrilor suplimentare; s indice noile termene de predare convenite.

Emise de: Efecte asupra costurilor:

Data:

Viz client: Se distribuie la:

Aprobat:

Fig.IV.4 Model de act adiional pentru modificarea unui proiect

44