Conf. dr. ing.

Florin Leon

Introducere

Managementul proiectelor devine rapid metoda de management utilizat

a de un num
ar din
ce n ce mai mare de industrii. Sunt realizate proiecte pentru construirea celor mai mari
zgrie nori sau pentru realizarea unor programe informatice foarte simple. Cei mai multi
manageri de proiect consider
a c
a tehnicile de management pot aplicate proiectelor indiferent
de dimensiune si c
a metodologia, metodele si pasii utilizati pentru management sunt aproape
aceleasi. Multe companii mari au n prezent o politic
a declarat
a de administrare folosind metode
de management al proiectelor.
Conform Ghidului PMBOK (Project Management Body of Knowledge, Corpul de cuno
stinte
al Managementului de Proiect), un proiect este un efort temporar ntreprins pentru a crea un
produs sau serviciu unic.
Cuvntul temporar nseamn
a c
a orice proiect are un nceput si un sfrsit. n general un
proiect ncepe cnd un anumit tip de document ocial declar
a c
a proiectul ia inta. Acest
document de obicei creeaz
a unele mijloace de realizare a cheltuielilor si costurilor proiectului.
Sfrsitul proiectului are loc de obicei atunci cnd toate obiectivele proiectului au fost realizate.
Unele proiecte se termin
a atunci cnd din diferite motive se decide abandonarea proiectului
pentru c
a scopurile sale nu pot realizate practic.
Cuvntul unic nseamn
a c
a bunurile sau serviciile create de proiect sunt ntr-o oarecare
m
asur
a diferite fata de orice a fost produs nainte. Acest lucru nu nseamn
a c
a proiectul este
complet unic, ci c
a unele p
arti sunt sucient de diferite pentru a necesita un proces de planicare
pentru organizarea efortului care trebuie f
acut.
Dac
a nu ar exista aceste p
arti diferite am vorbi de o repetitie de rutin
a care nu ar avea
nevoie de instrumentele si tehnicile de management de proiect.
Odat
a ce obiectivele au fost ndeplinite, resursele reunite n acest scop pot atribuite altor
proiecte. Aceasta nseamn
a c
a echipa unui proiect poate creat
a special pentru scopul acestuia.
Unul dintre principalele avantaje ale managementului de proiect este capacitatea de a forma
echipe multidisciplinare care contin oameni potriviti la momentul potrivit. Prin urmare, pot
aduse n proiect resurse deosebite atunci cnd sunt necesare.
Persoana (sau organizatia) care are un interes privind rezultatele unui proiect se numeste
parte interesata (engl. stakeholder). Proiectele vor avea ntotdeauna mai mult de o parte
interesat
a, ecare cu nevoi si astept
ari diferite. Clientul sau sponsorul este principala parte
interesat
a n proiect. F
ar
a acesta, proiectul probabil c
a nu s-ar realiza. Sponsorul asigur
a banii
necesari pentru proiect si are cel mai mare interes n succesul acestuia.
Managementul proiectelor reprezint
a aplicarea unor cunostinte, aptitudini si tehnici
pentru activit
atile proiectului cu scopul de a satisface sau dep
asi nevoile si astept
arile p
artilor
interesate. Deci, managementul de proiect utilizeaz
a o serie de instrumente si tehnici pentru a
gestiona proiecte.
1

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

MPS-01. Introducere n managementul

proiectelor

There is a story (probably true) about a project manager who went to work for
a company that produced computer software. This project manager was hired to
complete a project that was to produce a signicant amount of the companys income
for the year, and it had a strict deadline of twelve months.
As time went by, the project manager settled in, and after a couple of weeks the
project managers boss asked her how many lines of code had been written for the
project (a not too unusual measure for computer programming types).
She replied, Well, none at the moment. We are describing the users requirements and doing some planning for the project, but no, we have no lines of code
written.
This seemed to satisfy her manager for the time being, and the project manager
continued her work. After about a month the project managers boss showed up
again and asked the same question, How many lines of code have you and your
project team written?
The project manager, recognizing the concern of her manager, said, Well, none,
but we are getting organized. We have dened our deliverables for the project, and
we have made a work breakdown structure for the project, and we have started our
risk analysis, but no, we have no lines of code written. Somewhat shaken, the
manager left.
This went on for some time. The project manager did planning and organizing
for the project execution to take place, and her manager grew more and more frantic
with each passing day.
To make a long (twelve month) story shorter, after about eleven months, the
project was completed. The customer and all the stakeholders were happy. The
project was fully tested and it met or exceeded the requirements as specied. The
customer accepted the system and paid the bill.
The project managers boss decided to throw a party for the entire project team.
So, one Friday afternoon, the o ce was closed and everyone took a break for pizza
and beer. The project managers boss took her aside during the party and said, I
want to congratulate you on getting this project done within the time required, but it
seems to me that if you had not been messing around doing that planning stu and
gotten busy writing code from the start, we would have been done about two months
sooner.
This is the kind of reward you can expect when you follow good project management practices and you are working in an environment where all of this is new
to the management of your organization. Sometimes a little training in the ways
and methods of project management is in order. Often we nd companies that are
spending many thousands of dollars on training people who will manage projects and
not training any of the managers above those project managers. When the project
2

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Managerul de proiect este persoana responsabil

a n nal pentru succesul sau esecul
proiectului.
Se poate face o distinctie ntre termenii de proiect si program. Conform Ghidului PMBOK,
un program reprezint
a un grup de proiecte administrate ntr-un mod coordonat pentru a
obtine benecii care nu s-ar putea obtine dac
a proiectele ar administrate separat.
Este important de realizat faptul c
a terminarea unui proiect nu nseamn
a si terminarea
bunurilor sau serviciilor pe care le produce proiectul. De exemplu un proiect pentru construirea
unei centrale nucleare se termin
a cnd a fost ndeplinit scopul de construire a centralei si de
punere n functiune. Centrala continu
a s
a functioneze si dup
a ce proiectul a fost nalizat.

Func
tiile managementului

Managementul reprezint
a ndeplinirea unor obiective prin intermediul oamenilor si al altor
tipuri de resurse. Acesta se refer
a la procesul de stabilire si atingere a scopurilor prin cinci functii
de baz
a: planicare, organizare, selectie de personal, conducere si control, folosind resurse
umane, nanciare si materiale.

2.1

Planicarea

Priveste anticiparea situatiilor viitoare si determinarea celei mai potrivite modalit

ati de actiune
pentru ndeplinirea obiectivelor organizationale. Deseori considerat
a primafunctie a managementului, planicarea pune bazele tuturor celorlalte functii. Planicarea e un proces continuu
care implic
a stabilirea actiunilor necesare pentru a r
aspunde la ntreb
ari precum: ce trebuie
f
acut, cnd si cum. De asemenea, n aceast
a faz
a managerul trebuie s
a ia n calcul si factorii
care pot ajuta sau mpiedica atingerea scopului, precum si posibilele alternative disponibile
pentru atingerea sa.
Prin planicare se instituie o serie de actiuni care angajeaz
a indivizii, departamentele si
ntreaga organizatie timp de zile, luni sau chiar ani. De aceea, planicarea trebuie f
acut
a cu
atentie, lundu-se n calcul urm
atoarele aspecte:
1. Determinarea resurselor necesare;
2. Identicarea num
arului de oameni si a tipurilor de calicare (personal tehnic, de supervizare sau managerial);
3. Dezvoltarea mediului organizational n care se va lucra (ierarhia organizational
a);
4. Determinarea standardelor necesare pentru evaluarea evolutiei proiectului, astfel nct s
a
se poat
a face corectii atunci cnd acest lucru se impune.
n functie de amploare sau sfera de actiune, se pot evidentia trei categorii de planicare:
1. Planicarea strategica: Determin
a obiectivele majore ale organizatiei. Este initiat
a si
ghidat
a de un management de nivel nalt, ns
a toate nivelurile de management trebuie
s
a participe pentru ca planicarea strategic
a s
a dea rezultate. Acest tip de planicare
ndeplineste scopuri precum:
Stabilirea unor directii si angajamente pe termen lung pentru ntreaga organizatie;
Implicarea mai multor niveluri de management n procesul de planicare;
Dezvoltarea unui model organizational n care planurile subunit
atilor s
a e armonizate si consistente;
3

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

managers try to implement something new that they have learned, they are frequently
frustrated by upper managements resistance to change.
Sometimes it seems that getting these executive managers into some sort of
project management course is a lost cause. But it is imperative that we do so,
if only so that they will appreciate and understand some of the things that our new
project managers are trying to do. (Michael W. Newell Preparing for the project
management professional (PMP) certication exam).

3. Planicarea operationala: Se refer

a la ndeplinirea responsabilit
atilor la nivel de post sau
compartiment. Planurile pot singulare (pentru activit
ati care nu se repet
a, de exemplu
realizarea unui buget) sau continue (care includ anumite proceduri sau politici).

2.2

Organizarea

Organizarea este functia managementului care mbin

a resursele umane si materiale prin
proiectarea unei structuri formale a sarcinilor si autorit
atii. Organizarea stabileste deci relatiile dintre activitate si autoritate. n acest context, managerul trebuie s
a ndeplineasc
a patru
scopuri principale:
1. S
a determine ce activit
ati de lucru trebuie f
acute pentru atingerea obiectivelor organizationale;
2. S
a clasice tipurile de activit
ati si grupurile de lucru n unit
ati usor gestionabile;
3. S
a atribuie indivizilor sarcini de lucru si s
a-si delege autoritatea ntr-un mod adecvat;
4. S
a proiecteze o ierarhie a relatiilor pentru luarea deciziilor.
Procesul de organizare poate v
azut ca format din cinci pasi:
1. Studierea planurilor si scopurilor: Planurile dicteaz
a scopurile si activit
atile curente sau
viitoare. n unele situatii, ar trebui create noi unit
ati, alteori, unor unit
ati existente li
se confer
a noi atributii, iar unele unit
ati pot desintate. Pot ap
area noi relatii ntre
p
artile interesate. Organizarea creeaz
a o nou
a structur
a, noi relatii si le modic
a pe cele
existente;
2. Identicarea activitatilor necesare pentru atingerea obiectivelor: Trebuie creat
a o list
a de
sarcini ncepnd cu cele continue si terminnd cu cele singulare;
3. Clasicarea si gruparea activitatilor: Managerii trebuie s
a efectueze trei proceduri:
S
a examineze ecare activitate pentru a-i determina natura general
a (marketing,
productie etc.);
S
a grupeze activit
atile n ariile corespunz
atoare;
S
a stabileasc
a departamentele adecvate n cadrul structurii organizatiei;
4. Atribuirea sarcinilor si delegarea autoritatii: Un pas critic n care se stabilesc departamentele, natura, scopul si sarcinile ec
arui departament, mpreun
a cu performantele
asteptate;
5. Proiectarea unei ierarhii de relatii: Se hot
ar
asc relatiile de lucru verticale si orizontale. Structurarea vertical
a rezult
a ntr-o ierarhie de luare a deciziilor n care se stie
cine r
aspunde pentru ecare sarcin
a. Structurarea orizontal
a deneste relatiile de lucru
ntre departamente si stabileste num
arul de subordonati ai ec
arui manager.
4

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

2. Planicarea tactica: Priveste mai ales implementarea planurilor strategice printr-un management de nivel mediu. Tactica este mijlocul de ndeplinire a strategiei. Planurile se
refer
a la responsabilit
atile unit
atilor si n general se concentreaz
a pe activit
atile curente
si pe termen scurt;

Selec
tia personalului

Aceast
a functie priveste recrutarea, selectionarea, instruirea si desemnarea persoanei potrivite
pentru pozitia potrivit
a n cadrul organizatiei. n general, se consider
a c
a oamenii sunt cea
mai important
a resurs
a de care dispune organizatia. Prin selectia personalului, se doreste
identicarea, atragerea si p
astrarea personalului calicat pentru a ocupa pozitiile disponibile.
Selectia personalului poate v
azut
a ca un proces n opt pasi:
1. Planicarea resurselor umane: Trebuie s
a asigure faptul c
a nevoile de personal ale organizatiei vor satisf
acute. De obicei, se analizeaz
a planurile organizatiei pentru a vedea
ce competente anume vor necesare n viitor. Dup
a realizarea previziunilor, se stabileste
num
arul de persoane care trebuie recrutate (din afara organizatiei) sau instruite (din
interior);
2. Recrutarea: Se identic
a si se atrag candidati care ndeplinesc cerintele pentru posturile
vacante prev
azute. Ca rezultat al analizei posturilor, se ntocmesc descrierile si specicatiile acestora. Recrutarea efectiv
a se realizeaz
a prin site-uri Internet specializate, agenti
de ocupare a fortei de munc
a, leg
aturi cu universit
atile, anunturi publice n ziare etc.;
3. Selectionarea: Dup
a recrutare, candidatii interesati trebuie evaluati si selectionati cei ale
c
aror competente se potrivesc cu cerintele posturilor. Etapele urm
arite n evaluare pot
: completarea unor formulare, examinarea profesional
a, vericarea recomand
arilor si
interviul;
4. Instalarea si orientarea: Odat
a selectionati, noii angajati trebuie integrati n organizatie;
trebuie s
a li se prezinte grupul de lucru, precum si regulamentul intern sau normele
organizatiei;
5. Instruirea si dezvoltarea: Se ncearc
a mbun
at
atirea capacit
atii angajatilor de a contribui
la functionarea ecient
a a organizatiei. Instruirea se concentreaz
a asupra calic
arii angajatilor. Dezvoltarea implic
a preg
atirea lor pentru responsabilit
ati suplimentare sau
avansare;
6. Evaluarea performantelor: Un sistem proiectat s
a m
asoare performantele efective ale
angajatilor n comparatie cu standardele de performanta prestabilite;
7. Deciziile de recompensare: Pe baza evalu
arii performantelor, se pot lua decizii privind
recompensele nanciare, transfer
arile, promov
arile sau retrograd
arile;
8. ncetarea relatiilor de munca: Managementul trebuie s
a e preocupat si de demisii, pension
ari sau concedieri.

2.4

Conducerea

Dup
a crearea planurilor, structurii organizatiei si completarea personalului, urm
atorul pas al
procesului managerial este conducerea, adic
a dirijarea si motivarea angajatilor c
atre obiectivele
organizationale. Din acest motiv, conducerea este important
a mai ales la primul nivel de
supervizare, deoarece la acest nivel este concentrat
a majoritatea angajatilor organizatiei.
Caracteristicile cele mai importante ale functiei de conducere se refer
a la stilul de conducere
(autocratic, democratic) si la procesul de luare a deciziilor. Acestea sunt n strns
a leg
atur
a
cu o serie de factori precum urgenta situatiei sau motivarea subordonatilor. De asemenea,
managerul ca lider trebuie s
a cunoasc
a toate aspectele situatiei curente, s
a estimeze impactul
5

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

2.3

pe care l vor avea deciziile sale si s

a ia totdeauna n calcul elementul uman. El trebuie s
a
atribuie sarcinile initiale tuturor angajatilor, s
a dea ordine clare si concise si s
a urm
areasc
a
modul cum sunt ndeplinite sarcinile, dnd dac
a este nevoie ndrum
ari verbale sau scrise.

Controlul

Ultima functie a managementului se refer

a la evaluarea performantelor organizatiei pentru a
determina dac
a si ndeplineste sau nu obiectivele. n aceast
a faz
a trebuie luate urm
atoarele
m
asuri:
1. Stabilirea standardelor de performanta utilizate pentru a m
asura progresul c
atre scop.
Standardul reprezint
a un mecanism de m
asur
a cantitativ
a sau calitativ
a, destinat monitoriz
arii performantelor oamenilor sau proceselor. n general putem vorbi de:
Standarde manageriale: includ rapoarte, regulamente si evalu
ari de performanta.
De exemplu, un raport lunar din partea tuturor persoanelor implicate n vnz
ari,
centrat pe ariile cheie de interes pentru managerul de vnz
ari;
Standarde tehnice: se refer
a la metodele si procesele de productie, la materiale,
echipamente, componente si furnizori. Standardele tehnice pot veni din surse interne
sau externe. De exemplu, standarde de calitate dictate de reglement
ari guvernamentale sau specicatiile produc
atorului pentru echipamente;
2. Monitorizarea si evaluarea performantelor: sunt m
asurate performantele si se determin
a
dac
a respect
a standardele stabilite. Dac
a o asemenea comparatie indic
a faptul c
a rezultatele sunt acceptabile, nu este necesar
a nicio actiune. n caz contrar, se trece la urm
atorul
pas:
3. Corectarea deviatiilor de la standarde: m
asurile de corectie necesare se vor lua pe baza
a trei factori standardul, precizia m
asur
atorii care a indicat deviatia si diagnosticul
persoanelor care au investigat cauzele deviatiei. Standardele pot prea slabe sau prea
stricte. M
asur
atorile pot imprecise deoarece instrumentele de m
asur
a pot utilizate
defectuos sau prezint
a ele nsele defecte. Oamenii pot lua decizii gresite la hot
arrea
actiunilor corective necesare.

3
3.1

No
tiuni de baz
a
Deni
tii

n cele ce urmeaz
a, vom preciza cteva denitii esentiale pentru managementul de proiect:
Plan: Gracul datelor de ncepere si terminare ale activit
atilor mpreun
a cu informatii
despre resurse si costuri. Un plan de baz
a este planul initial, care se salveaz
a si se foloseste
pentru a monitoriza progresul. Un plan interimar este un set de date salvate n timpul
derul
arii proiectului, folosite pentru a le compara cu alte planuri interimare.
Buget: Costul estimat al proiectului care se stabileste n planul de baz
a (engl. baseline).
Cost: Costul total planicat pentru o activitate, resurs
a, sarcin
a trasat
a sau pentru
ntregul proiect. Uneori este denumit cost curent.

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

2.5

Resurse: Oamenii, echipamentele si materialele folosite pentru a naliza activit

atile din
proiect.

Supra-alocare: Rezultatul atribuirii mai multor activit

ati dect poate realiza o resurs
a n
timpul de lucru disponibil.
Activitate divizata: O activitate al c
arei grac de lucru este ntrerupt. De exemplu, o
activitate de dou
a zile, care nu necesit
a executia prin lucru continuu, poate mp
artit
a
astfel nct prima zi de lucru s
a e programat
a luni iar cea de-a doua zi joi.
Nivelare: Rezolvarea conictelor de resurse sau a supra-aloc
arilor prin ntrzierea sau
divizarea unor activit
ati. Cnd o resurs
a este nivelat
a, sarcinile sale sunt distribuite si
reprogramate.
Data de ncheiere: Data la care o activitate este programat
a pentru a nalizat
a. Aceast
a
dat
a depinde de data de ncepere a activit
atii, durata acesteia, calendarele dup
a care
se lucreaz
a, datele unor sarcini precedente, dependentele fata de alte activit
ati si alte
constrngeri.
ntrziere: Timpul dintre data planicat
a de ncepere a unei activit
ati si momentul n
care ncepe efectiv lucrul la aceasta. ntrzierile sunt deseori folosite pentru a rezolva
supra-aloc
arile de resurse.
Livrabil: Un rezultat concret si m
asurabil, produsul sau un element care trebuie produs
pentru a naliza proiectul sau o parte a proiectului. n mod normal, echipa proiectului si
p
artile interesate decid de comun acord livrabilele nainte de nceperea proiectului.

3.2

Triunghiul managementului de proiect

Managementul proiectelor este adesea rezumat ntr-un triunghi (gura 1). Principalii trei factori
sunt timpul, costul si domeniul de aplicare, numiti si tripla constrngere. Acestea formeaz
a
vrfurile triunghiului avnd calitatea ca tem
a central
a:

Figura 1. Triunghiul managementului de proiect

1. Proiectele trebuie s
a e livrate la timp.
2. Proiectele trebuie s
a se ncadreze n costuri.
7

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Tarif de plata: Costul resurselor pe or

a. Exist
a dou
a tipuri de tarife de plat
a: standard
si pentru ore suplimentare.

3. Proiectele trebuie s
a se ncadreze n domeniul de aplicare.

Dac
a timpul sau banii ar nelimitati, sau cerintele ar nule, nu ar mai nevoie de
management de proiect. Din p
acate, cele mai multe proiecte au o anumit
a limit
a de timp,
de buget si domeniu de aplicare. ntelegerea triunghiului proiectului permite luarea de decizii
mai bune atunci cnd trebuie f
acute compromisuri. Dac
a se ajusteaz
a o latur
a a triunghiului,
celelalte dou
a laturi sunt afectate. De exemplu:
1. Dac
a se decide sc
aderea timpului alocat pentru nalizarea proiectului, poate rezulta o
crestere a costurilor, precum si o restrngere a domeniului de aplicare;
2. Dac
a se decide sc
aderea bugetului proiectului, poate rezulta un grac de lucru mai lung
si o sc
adere a domeniului de aplicare;
3. Dac
a se decide extinderea domeniul de aplicare, proiectul poate s
a dureze mai mult timp
si s
a coste mai multi bani, de exemplu sub form
a de resurse umane.
Modic
arile din planul proiectului pot afecta triunghiul n diverse moduri, n functie de
circumstantele specice si de natura proiectului. De exemplu, de cele mai multe ori, scurtarea
timpului de executie al proiectului poate creste costurile. n alte cazuri, acestea se pot chiar
diminua.
Din punct de vedere al triunghiului proiectului, resursele sunt considerate un element de
cost. Deci, n functie de cum ajust
am resursele pentru mai mult sau mai putin efort de lucru sau pentru a reecta disponibilitatea acestora, costurile vor urca sau vor cobor n mod
corespunz
ator. Aceste costuri sunt bazate pe tarifele de plat
a ale resurselor. De asemenea,
se poate observa c
a pe m
asur
a ce se ajusteaz
a resursele, apar modic
ari n gracul de lucru.
De exemplu, dac
a avem un num
ar de resurse supra-alocate si se niveleaz
a proiectul, gracul
de lucru poate contine acum sarcini divizate si ntrzieri, care extind data limit
a a termin
arii
proiectului.
n cele mai multe proiecte, cel putin o latur
a a triunghiului este x
a. Pentru unele proiecte,
este latura bugetului: sub nicio form
a nu se vor primi mai multi bani pentru proiect. La altele,
este latura timpului: datele nu se pot schimba. Sau este domeniul de aplicare: nu va permis
a
nicio schimbare n livrabile. Ideea este de a g
asi p
artile blocate sau xe ale triunghiului
proiectului. Aceste p
arti ne spun ce se poate schimba sau ajusta dac
a exist
a o problem
a.
Enuntarea problemei ne poate ajuta s
a claric
am ce parte a triunghiului are dicult
ati.
Cunoscnd care parte a triunghiului nu poate schimbat
a ne poate ajuta s
a aam ce trebuie
ajustat. Asa c
a, atunci cnd se ncepe optimizarea, n primul rnd, se decide care dintre cele trei
elemente este x. Acesta este de obicei elementul cel mai important pentru succesul proiectului
(terminarea la timp, nedep
asirea bugetului sau respectarea domeniului de aplicare convenit).
Apoi, se determin
a pe care latur
a a triunghiului apare problema curent
a pentru a sti la ce
elemente trebuie lucrat pentru a relua bunul mers al proiectului.
Dac
a latura pe care a ap
arut problema si latura x
a a triunghiului coincid, r
amn celelalte
dou
a laturi ale triunghiului pentru a ajustate. De exemplu, dac
a proiectul trebuie s
a e
terminat la timp si problema este c
a proiectul necesit
a prea mult timp, se pot modica resursele
sau domeniul de aplicare.
Dac
a latura problemei este diferit
a de latura x
a, proiectul trebuie optimizat adaptnd
latura r
amas
a. De exemplu, dac
a proiectul trebuie s
a e terminat la timp, dar creste domeniul
de aplicare, mai r
amne s
a ajust
am numai latura costului, de exemplu, prin ad
augarea de
resurse.
8

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

4. Proiectele trebuie s
a ndeplineasc
a cerintele de calitate ale clientilor.

3.3

Ciclul de via
ta
al unui proiect

Proiectele de orice dimensiune, mici sau mari, pot gestionate folosind metodologia managementului de proiect. Pentru c
a toate proiectele sunt unice ntr-un fel, este util
a observarea
ciclului de viata al proiectelor pentru a vedea c
a exist
a multe asem
an
ari ntre proiecte si toate
trec prin faze similare. Ciclul de viata al unui proiect deneste nceputul si sfrsitul acestuia si
diferitele etape din cadrul lui. n diferite puncte ale ciclului de viata, aceste etape sunt reevaluate si este luat
a o decizie dac
a s
a se continue proiectul sau nu. Punctele dintre nceputul si
sfrsitul proiectului variaz
a considerabil n functie de specicul proiectului care urmeaz
a s
a e
realizat.
n Ghidul PMBOK sunt discutate procesele de baz
a ale managementului de proiect. Managementul de proiect este un proces n care intr
a anumite resurse, acestea sunt prelucrate si
sunt produse rezultate. n cadrul proceselor de management de proiect sunt incluse si alte
procese precum: initierea, planicarea, executia si ncheierea.
Pe parcursul duratei de viata a unui proiect, vor exista rezultate la ecare faz
a. ndeplinirea
acestor rezultate duce la crearea unui produs livrabil, tangibil, vericabil rezultatul muncii
depuse n cadrul proiectului. Produsele pot livrate n exteriorul proiectului, sau sunt necesare
pentru realizarea altor activit
ati din cadrul proiectului, ind considerate livr
ari interne.

Figura 2. Ciclul de viata al unui proiect

9

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Cnd se ajusteaz
a o latur
a a triunghiului, celelalte dou
a sunt susceptibile de a afectate,
pozitiv sau negativ.
Proiectele au ntotdeauna resurse limitate, dar uneori exist
a proiecte n care costul si cantitatea resurselor par a nelimitate. Ne putem gndi la proiectul Manhattan din anii 40 sau la
proiectul Apollo din anii 60, dar chiar si aceste proiecte au avut unele constrngeri de resurse.
Pentru managerul de proiect care ncerc
a s
a nalizeze un proiect cu resurse putine sau rare,
acesta poate p
area un mod minunat de a gestiona un proiect, dar de obicei aceste tipuri de
proiecte vin de obicei cu cerinte severe pentru gracul de lucru si termenele limit
a.

Exist
a mai multe modele ale ciclului de viata al proiectelor, n functie de specicul domeniului. Modelul tipic cuprinde patru stadii, din care ultimul poate compus din dou
a etape.
n gura 2 se prezint
a ciclul de viata generic al unui proiect.
Acesta contine urm
atoarele stadii:

Denirea specicatiilor proiectului

Denirea obiectivelor proiectului
Identicarea principalelor responsabilit
ati
2. Stadiul de planicare
Planicarea gracelor de lucru calendaristice
Planicarea resurselor umane, de timp si a bugetului proiectului
Managementul riscurilor
3. Stadiul de executie si control
Implementarea proiectului
Monitorizarea progresului nregistrat n implementare
Evaluarea, m
asurarea si controlul realiz
arilor intermediare
Elaborarea de previziuni si prognoze de dezvoltare
4. Stadiul de livrare si nalizare
Livrarea produsului proiectului c
atre beneciar, incluznd activit
ati de instruire,
transfer de documente etc.
Realizarea unei analize post-implementare
Realocarea resurselor
Raportul nal al proiectului.
Pe durata ciclul s
au de viata, proiectul trebuie s
a fac
a fata n principal la dou
a tipuri de
cerinte. Prima dintre acestea se refer
a la etapa de denire a problemei, n care eventualele erori
pot conduce la dezvoltarea unei solutii corecte pentru o problem
a denit
a gresit.
n faza initial
a a proiectului, nivelurile de costuri si de personal sunt mici. Exist
a doar ctiva
oameni cheie care si petrec timpul lucrnd la proiect. Au fost achizitionate putine materiale sau
deloc, iar angajamentul companiei cu privire la partea nanciar
a a proiectului nu este deplin.
n aceast
a etap
a exist
a cea mai mare probabilitate ca proiectul s
a nu e niciodat
a nalizat.
Multe proiecte ajung n aceast
a faz
a doar pentru a ntrerupte atunci cnd se stabileste c
a
nu se poate respecta costul de realizare sau costurile dep
asesc beneciile. n aceast
a etap
aa
proiectului, multe aspecte ale sale sunt necunoscute.
Cea de-a doua problem
a caracterizeaz
a etapa post-implementare. Orice proiect trebuie s
a se
nalizeze cu elaborarea unei analize post-implementare, cu scopul de a identica att aspectele
pozitive ale proiectului ct si aspectele ce trebuie mbun
at
atite.
n practic
a, aceast
a etap
a este deseori trecut
a cu vederea. Astfel, n cadrul conferintei Frontiers Conference on Proiect Management, unul dintre moderatori a ntrebat audienta format
a
10

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

1. Stadiul de denire

Managerul de proiect

Managementul proiectelor poate o profesie, o ocupatie, un rol sau o activitate. Unele companii
au manageri de proiecte a c
aror datorie este de a superviza proiecte ntregi cu sute de persoane.
Alte companii acord
a acest titlu unor manageri ncep
atori, ecare ind responsabil de o mic
a
parte dintr-un proiect mai mare. n functie de modul n care este structurat
a o organizatie, de
cultura sa organizational
a si de obiectivele proiectului, managementul de proiect poate avea un
rol informal (este realizat de c
atre oricine, ori de cte ori este necesar) sau clar denit (X,
Y si Z sunt manageri de proiect cu norm
a ntreag
a).
Uneori absenta unui manager de proiect dedicat nu pune probleme. Programatorii si sei lor
realizeaz
a planurile ingineresti cnd este nevoie si un specialist n marketing face planicarea sau
stabileste cerintele. Orice alt
a activitate de management de proiect pur si simplu se distribuie
n ntreaga echip
a. Poate c
a unii oamenii din echip
a au fost angajati pentru interesul lor
dincolo de scrierea de cod. Acestia nu vor refuza activit
ati precum planicarea, proiectarea
interfatei cu utilizatorul sau denirea strategiei de afaceri. Folosind acest mod de lucru se pot
realiza optimiz
ari semnicative. Atta timp ct toti membrii echipei sunt dispusi s
a accepte
responsabilit
ati pentru a face lucrurile s
a mearg
a n mod coordonat si s
a preia activit
atile unui
manager de proiect dedicat, aceasta nseamn
a un om mai putin, de care echipa se poate lipsi.
Ecienta si simplitatea trebuie apreciate.
Alteori, lipsa unui manager de proiect creeaz
a disfunctii. F
ar
a o persoan
a a c
arei principal
a
activitate este ghidarea efortului global, interesele individuale pot afecta directia echipei. n
jurul rolurilor tehnice si comerciale pot ap
area tensiuni care duc la ncetinirea progresului si
frustrarea celor implicati. De exemplu, n spitalele de urgenta un singur medic ia deciziile
privind actiunile efectuate pentru un pacient. Acest mod de lucru accelereaz
a luarea multor
decizii si claric
a rolul ec
arui membru din echip
a. F
ar
a o astfel de autoritate clar
a pentru
probleme de management al proiectelor, echipele de dezvoltare pot ntmpina dicult
ati. Dac
a
nu exist
a un responsabil pentru conducerea procesului de prelucrare si sortare a defectelor,
sau nimeni nu este direct responsabil pentru monitorizarea gracului de lucru si semnalarea
problemelor, aceste activit
ati pot r
amne mult n urma celor bazate pe programarea propriuzis
a.
11

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

din 400 de persoane: Cti dintre dumneavoastr

a au primit dispozitia ca, dup
a executarea
proiectului, s
a elaboreze un raport de evaluare care s
a cuprind
a concluziile nale?La aceast
a
ntrebare doar 10 persoane au ridicat mna.
A doua ntrebare a aceluiasi moderator a fost: Cti dintre dumneavoastr
a ati fost solicitati
s
a prezentati managementului companiei ce veti face ca s
a evitati repetarea n viitor a greselilor
f
acute n executarea proiectului?La aceast
a ntrebare numai 2 persoane au ridicat mna.
Concluziile nale dup
a executarea unui proiect sunt deosebit de importante, deoarece persoanele care nu cunosc istoricul proiectelor precedente au tendinta de a repeta greselile anterioare. Reticenta unor persoane de a face o trecere n revist
a a rezultatelor nale poate avea
mai multe cauze. n primul rnd, pe m
asur
a ce se apropie de nalizarea proiectului, managerii
devin ner
abd
atori s
a treac
a la realizarea altor sarcini sau proiecte. n al doilea rnd, ei nu
doresc s
a recunoasc
a faptul c
a la anumite aspecte trebuie aduse mbun
at
atiri. Uneori, aceast
a
atitudine este determinat
a de dorinta de a nu crea dicult
ati persoanelor a c
aror activitate
trebuie perfectionat
a.
Totusi, orict de bine este realizat
a o activitate, ntotdeauna este loc pentru mbun
at
atiri,
iar analizele nale trebuie conduse n acest spirit. Tendinta de a pedepsi persoanele a c
aror
activitate prezint
a deciente poate d
auna managerilor de proiect n elaborarea unor rapoarte
de evaluare corecte.

o stiinta deoarece presupune ntelegerea proceselor, instrumentelor si tehnicilor, precum

si denirea si coordonarea activit
atilor care trebuie efectuate;
o arta, datorit
a aspectelor inter-personale care se refer
a la conducerea oamenilor.
Instrumentele si tehnicile de management de proiect sunt ncercate si testate si pot folosite
cu succes la orice proiect. Aproape toate dintre acestea sunt disponibile de multi ani, dar au
fost oarecum dicil de utilizat f
ar
a ajutorul calculatoarelor personale.
De asemenea, prin organizarea ntr-o manier
a care canalizeaz
a eforturile depuse de echip
a
n directia de realizare a proiectului, se creeaz
a o stare de nalt
a motivatie. Aceasta permite
echipei s
a se concentreze asupra obiectivelor si s
a nu e distras
a de alte activit
ati din jur. P
artile
interesate trebuie s
a aib
a puncte de contact consecvente cu echipa de proiect, iar managerul de
proiect trebuie s
a e o surs
a sigur
a de informatii cu privire la proiect si tot ce se ntmpl
a n
cadrul acestuia.
Managerii de proiect pot v
azuti ca niste manageri de ntreprinderi mici. Multe din caracteristicile necesare n gestionarea unei mici afaceri sunt aceleasi cu cele necesare pentru un bun
management de proiect. n realitate, datorit
a faptului c
a multi manageri de proiect din ziua de
ast
azi au preg
atirea de baz
a n discipline tehnice, este surprinz
ator faptul c
a aptitudinile care
le sunt solicitate erau considerate anterior abilit
ati neobisnuite pentru managerii tehnici.
Ast
azi este de asteptat ca managerul de proiect s
a aib
a cunostinte considerabile din domeniul
nanciar, contabilitate, vnz
ari, marketing, productie, cercetare si dezvoltare, planicare strategic
a si operational
a, caracteristicile organizatiilor, resurse umane, administratie, gestionarea relatiilor de munc
a, motivare si alte competente inter-umane. Echipa multidisciplinar
a a proiectului devine o entitate n sine, axat
a pe nevoile proiectului si care ncearc
a satisfacerea acestor
nevoi n cel mai bun mod posibil.

4.1

Echilibrul atitudinilor

Managerii de proiect buni sunt greu de g

asit deoarece acestia trebuie s
a mentin
a un echilibru
al atitudinilor. Un manager de proiect trebuie nu numai s
a e constient de aceste tr
as
aturi,
dar si s
a si dezvolte instinctele adecvate pentru anumite situatii. Aceasta contribuie la ideea
c
a managementul de proiect este o art
a: necesit
a intuitie, hot
arre si experienta de a utiliza
aceste forte n mod ecient.
1. Orgoliul / lipsa orgoliului. Datorit
a responsabilit
atii mari pe care o au managerii de
proiect, acestia g
asesc o satisfactie personal
a n munca lor. Ei investesc o mare nc
arc
atur
a
emotional
a n ceea ce fac si, pentru multi, aceast
a legatur
a emotional
a este ceea ce i
determin
a s
a mentin
a intensitatea necesar
a pentru a ecienti. Dar n acelasi timp,
managerii de proiect trebuie s
a evite plasarea intereselor proprii naintea proiectului.
Ei trebuie s
a e dispusi s
a delege att sarcini importante ct si distractive, s
a mpart
a
premiile si recompensele cu ntreaga echip
a. Chiar dac
a mndria poate o rezerv
a de
energie, managerul de proiect trebuie s
a recunoasc
a momentul n care aceasta i st
a n
cale.
2. Autocratia / delegarea. n unele situatii, cele mai importante lucruri sunt o linie clar
a de
autoritate si un timp de r
aspuns rapid. Un manager de proiect trebuie s
a e ncrez
ator
12

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Desi multi programatori de vrf au sucient de multe cunostinte despre managementul de

proiect, nct ar putea face chiar ei acest lucru, acestia recunosc valoarea unic
a a unei persoane
competente, dedicate, care joac
a rolul de manager.
Managementul de proiect este n acelasi timp:

3. Tolerarea ambiguitatii / urmarirea perfectiunii. Primele faze ale oric

arui proiect contin
experiente deschise si de o uiditate mare, acolo unde necunoscutul surclaseaz
a cunoscutul. Ambiguitatea controlat
a este esential
a pentru scoaterea la suprafata a ideilor bune,
si un manager de proiect ar trebui cel putin s
a respecte acest lucru dac
a nu s
a l faciliteze
si s
a l controleze. Dar n alte momente, mai ales n fazele nale ale proiectului, disciplina
si precizia sunt vitale. Este nevoie de inteligenta pentru a discerne ntre cazul n care
perfectiunea este r
asplatit
a si cazul n care o solutie mediocr
a, rapid
a si neglijent
a este
sucient
a.
4. Comunicarea orala / scrisa. Indiferent ct este de axat
a o organizatie de dezvoltare software pe comunicarea electronic
a, aptitudinile de comunicare oral
a sunt de o importanta
critic
a pentru managementul proiectului. ntotdeauna vor ntlniri, negocieri, discutii
pe hol si sesiuni de brainstorming, iar managerul de proiect trebuie s
a e ecient att
la ntelegerea ct si la comunicarea ideilor fata n fata. Cu ct organizatia sau proiectul este mai mare, cu att abilit
atile scrise devin mai importante. n ciuda preferintelor
lui personale, un manager de proiect trebuie s
a si dea seama cnd este mai ecient
a
comunicarea scris
a si cnd este de preferat comunicarea oral
a.
5. Recunoa
sterea complexitatii / promovarea simplitatii. Multi oameni cad victime complexit
atii. Cnd sunt pusi fata n fata cu o provocare organizational
a sau inginereasc
a
complex
a, ei tind s
a se concentreze asupra detaliilor si s
a piard
a din vedere imaginea de
ansamblu. Altii refuz
a complexitatea si iau decizii proaste pentru c
a nu nteleg ntru
totul subtilit
atile problemelor ap
arute. Echilibrul aici poate g
asit v
aznd care perspectiv
a asupra proiectului e mai folositoare, prin schimbarea sau combinarea perspectivelor.
Managerii de proiect trebuie s
a determine echipa s
a urm
areasc
a simplitatea si calitatea,
f
ar
a a minimiza ns
a complexitatea necesar
a scrierii unui cod bun si de ncredere.
6. Rabdarea / nerabdarea. n cele mai multe cazuri, managerul de proiect este persoana care
mpinge la actiune, fortndu-i pe ceilalti s
a se concentreze asupra sarcinilor de lucru. Dar
n unele situatii, ner
abdarea se ntoarce mpotriva proiectului. Unele activit
ati politice,
birocratice sau inter-organizationale sunt consumatoare de timp. De exemplu, dac
a o
persoan
a important
a trebuie s
a vin
a la un moment dat la o ntlnire, managerul de
proiect trebuie s
a e r
abd
ator. A sti cnd s
a fortezi o problem
a si cnd s
a te retragi si s
a
lasi lucrurile s
a mearg
a de la sine este o calitate pe care trebuie s
a si-o dezvolte managerii
de proiect.
7. Curajul / frica. O idee gresit
a este aceea c
a oamenilor curajosi nu le este fric
a. De fapt,
curajosi sunt cei c
arora le este fric
a, dar cu toate acestea aleg s
a actioneze. Un manager
de proiect trebuie s
a aib
a o bun
a ntelegere a tuturor lucrurilor care pot merge r
au si s
a
le considere posibile. Dar, cu toate acestea, el trebuie s
a aib
a curajul necesar pentru a
accepta provoc
ari mari.
8. ncrederea / scepticismul. Nu este nimic mai important pentru moralul echipei dect
un lider respectat care crede n ceea ce face. Un manager de proiect trebuie s
a aib
a
ncredere n munca realizat
a si s
a vad
a adev
arata valoare a obiectivelor ce vor atinse.
n acelasi timp, este nevoie de o doz
a de scepticism (nu cinism) referitoare la modul n
care se fac anumite lucruri. Cineva trebuie s
a critice si s
a pun
a ntreb
ari, s
a conteste
13

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

si dispus s
a preia controlul si s
a forteze anumite actiuni ale echipei. Totusi, n general
scopul este s
a se evite asemenea situatii extreme. Un proiect gestionat bine trebuie s
a
creeze o atmosfer
a unde sarcinile pot delegate iar colaborarea este ecient
a.

Persoanele cu astfel de abilit

ati se g
asesc foarte rar, cu att mai mult cele care au capacitatea
de a le echilibra ecient. Multe dintre greselile pe care le face un manager de proiect sunt
cauzate de inecienta echilibr
arii acestor forte conictuale. Totusi, oricine poate deveni mai
bun n recunoasterea, ntelegerea si apoi n cresterea abilit
atilor sale de a tine fortele n echilibru.
Privind aceast
a list
a de forte conictuale inevitabile, managerul de proiect poate reconsidera
ce face si de ce, pentru a lua decizii mai bune.

4.2

Presiunile
si neaten
tia

Una din temerile managerilor de proiect ncep

atori este aceea c
a succesul necesit
a schimbare:
modicare, construire sau distrugere. Mentinerea st
arii curente, n afara unui scop explicit
pentru aceasta, este o practic
a inecient
a. Lumea se schimb
a tot timpul si dac
a un site web
sau orice alt proiect este la fel de bun ast
azi cum era anul trecut, asta nseamn
a c
a a r
amas
n urm
a deoarece atingerea scopurilor a fost r
au directionat
a sau executia proiectului a esuat
ntr-un fel.
Este greu de ignorat imensa presiune care cade pe umerii managerului de proiect, dar aceasta
este inevitabil
a. Exist
a ntotdeauna un mod nou de a gndi, altceva de nv
atat si aplicat, sau un
nou proces care face munca mai usoar
a si mai ecient
a. Un manager bun are nevoie de abilit
ati
de lider, iar un lider bun necesit
a abilit
ati de management. Oricine e implicat n managementul
proiectelor este responsabil de cte un pic din amndou
a, indiferent ce scrie n sa postului.
Revenind la chestiunea presiunii, sunt multi manageri care fug de momentele n care trebuie
s
a e si lideri, de exemplu cnd echipa are nevoie de cineva care s
a ia o decizie, si se complac
n a urm
ari eforturile altora n loc s
a faciliteze sau chiar s
a participe la ele. Dac
a cineva st
a
tot timpul si tine scorul sau priveste de pe margine, acesta este mai potrivit pentru un post de
contabil. Cnd cineva cu un rol de lider r
aspunde la presiune ferindu-se de ea, el nu conduce,
ci se ascunde. Managerii de proiect lasi sau inecienti tind s
a e mpinsi nspre periferia
proiectului, de unde aduc putin
a valoare acestuia.
Unii manageri n aceast
a situatie se rezum
a la a cuantica lucruri care nu trebuie cuanticate. Nesiguri de ce ar trebui s
a fac
a sau prea speriati s
a fac
a ce trebuie f
acut, ei si ocup
a
timpul cu lucruri secundare. Cu ct spatiul dintre manager si proiect creste, cu att mai mult
creste si timpul alocat veric
arii tabelelor, listelor sau rapoartelor. Este posibil ca managerul
de proiect s
a ajung
a s
a cread
a n timp c
a datele si procesele sunt chiar proiectul. El se bazeaz
a
pe lucruri mai putin importante cu care se lucrez
a mai usor precum se de lucru si rapoarte,
n poda lucrurilor importante care se rezolv
a mai greu, cum ar efortul de planicare sau
programare. Ar putea ajunge s
a cread
a c
a dac
a urmeaz
a perfect o anumit
a rutin
a si veric
a
rapoartele, proiectul este garantat s
a aib
a succes si, mai cinic, orice greseal
a care apare nu este
din vina lui.
Pentru a minimiza posibilitatea confuziilor, managerii de proiect buni rezist
a tentatiei de a
deni limite stricte asupra muncii pe care sunt dispusi s
a o fac
a sau nu. Ei evit
a s
a trag
a o linie
ntre sarcinile referitoare la managementul proiectului si proiectul n sine. Utilizarea listelor de
obiective implic
a faptul c
a exist
a un proces bine denit care garanteaz
a un anumit nal, ceea
ce nu este cazul. n realitate exist
a ntotdeauna trei lucruri: un scop, un volum de lucru si o
mn
a de oameni. Rolurile bine denite i pot ajuta pe acesti oameni s
a se organizeze privitor
la volumul de munc
a, dar formarea acestor roluri nu este scopul principal. O list
a de obiective
poate ajuta oamenii s
a lucreze ntr-un fel care atinge scopul, dar nu lista este scopul principal.
Confundarea proceselor cu scopurile este una din cele mai mari greseli de management.
14

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

presupunerile altora si s
a aduc
a problemele dicile la lumin
a. Cheia este capacitatea de a
pune ntreb
ari referitoare la presupunerile cuiva, de a-i contesta ipotezele f
ar
a a zdruncina
ncrederea echipei n munca pe care o face.

n loc s
a se concentreze pe procese sau metode, managerii de proiect ar trebui s
a se concentreze asupra echipei. n mod sigur trebuie folosite sisteme simple de planicare si monitorizare,
dar ele trebuie s
a e compatibile cu complexitatea proiectului si cultura echipei. Mai exact,
planicarea si monitorizarea trebuie s
a ajute echipa n atingerea scopului proiectului, nu s
a-i
mpiedice. Atta timp ct managerii de proiect sunt atenti si cstig
a ncrederea echipei, orice
sc
apare privind sarcinile, procesele, rapoartele sau listele necesare managementului de proiect
va iesi la lumin
a nainte ca problemele pe care acestea le pot rezolva s
a devin
a serioase.

4.3

M
asurarea performan
telor

Deseori exist
a presupuneri tacite sau chiar explicite despre modul n care un individ este recunoscut sau nu pentru performantele sale. Dezvoltatorii sunt premiati pentru terminarea
sarcinilor la timp. Testerii sunt recompensati pentru efectuarea a numeroase teste si g
asirea
multor defecte. Specialistii pentru suport telefonic sunt r
aspl
atiti pentru preluarea a numeroase
apeluri si rezolvarea lor si asa mai departe. Totusi, folosirea unor metrici liniare pentru m
asurarea performantelor unui individ poate neproductiv
a.
Asa cum reiese din gura 3, cnd un sistem de m
asurare este pus n aplicare, m
asurile
performantelor ncep s
a creasc
a. La nceput, valoarea real
a a organizatiei poate de asemenea s
a
creasc
a. Acest fenomen are loc ntr-o anumit
a m
asur
a pentru c
a angajatii nu nteleg sistemul
de m
asurare foarte bine la nceput, asa c
a aleg calea cea mai sigur
a de a atinge scopurile
organizationale. mbun
at
atiri reale pot ap
area si pentru c
a primele tinte sunt modeste si nu
determin
a angajatii s
a nsele sistemul. Cu trecerea timpului ns
a, cu ct standardele organizatiei
cresc prin m
arirea cotelor sau inducerea unei st
ari de competitie ntre angajati, sunt folosite c
ai
de atingere a scopurilor incompatibile cu politicile rmei. Cnd un grup de angajati vede alt
grup c
a prot
a de sc
ap
arile sistemului de evaluare, grupul mai lent simte presiunea de a-i imita.
Treptat, m
asurile si pierd relevanta pentru adev
aratele performante, indc
a angajatii cedeaz
a
presiunii de a nsela sistemul. Performantele m
asurate cresc, ns
a adev
aratele performante scad
dramatic. n acest mod sistemul de m
asurare devine disfunctional.

15

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Years ago, working on the Internet Explorer 4.0 project, I was the PM for several large areas of the user interface. I felt signicant pressure: it was the largest
assignment Id ever had. In response, I developed the belief that if I could write
everything down into checklists, Id never fail. While things do need to be tracked
carefully on a project, Id taken it too far. Id built an elaborate spreadsheet to show
multiple data views, and the large whiteboards in my o ce were covered with tables
and lists (and extra whiteboards were on the way).
My boss let me run with it because things were going well. That is, until he
saw me spending more time with my checklists and processes than I did with my
team a big red ag (warning sign). He came into my o ce one day, and seeing
the comically large matrix of checklists and tables Id written on every at surface
in my o ce, sat me down and closed the door. He said, Scott, this stu is nice,
but your project is your team. Manage the team, not the checklists. If the checklists
help you manage the team, great. But the way youre going, soon youll be using
your team to help you manage your checklists. (Scott Berkun The Art of Project
Management)

Imagine measuring programmer productivity based on lines of code written per

day. An individual has a choice of calling a framework method (perhaps 5 lines with
error handling) or of copying 200 lines of open-source example code. Which one
gets rewarded? Which one is easier to maintain, to code-review, to security-review,
to test, and to integrate? Or similarly, the individual has the chance to refactor
three overlapping methods into one, reducing the size of the code base.
Imagine measuring testers based on the number of bugs found. Do they look for
easy-to-nd, overlapping, simple bugs or go after signicant ones that require setting up complex customer data and congurations? Which approach gets rewarded?
Which one yields more customer value? (Robert D. Austin Measuring and Managing Performance in Organizations)

4.4

Implicarea corect
a

Managerii nu sunt angajati s

a contribuie n mod liniar la munca din organizatie, ca programatorii simpli, ci s
a amplice valoarea celor din jurul lor. Metodele prin care se poate ad
auga
aceast
a valoare difer
a de munca realizat
a la nivelurile inferioare. Dar pentru c
a multi manageri
sunt fosti programatori care au fost promovati, sunt sanse ca ei s
a aib
a mai mult talent la
scrierea codului dect la conducerea unor persoane.
Prezenta unui manager ar trebui s
a contribuie cu ceva de alt
a natur
a dect simpla ad
augare
a unei contributii individuale. Uneori aceast
a contributie vine din aplanarea conictelor si
izolarea echipei de partea politic
a. Alteori se refer
a la planicarea de nivel nalt sau g
asirea
unor c
ai de evitare a situatiilor neasteptate. Pentru c
a aceste contributii sunt mai greu de
m
asurat, multi manageri de proiect au o problem
a cu ambiguitatea rolului lor.
Cea mai bun
a metod
a de a g
asi punctele de echilibru este utilizarea diferentei psihologice
pe care o confer
a pozitia de pe un nivel superior. Un manager de proiect, n timpul activit
atilor
sale, va petrece n mod natural mai mult timp cu oamenii din echip
a dect altii, obtinnd astfel
mai multe surse de informare si o perspectiv
a mai larg
a asupra proiectului. Un manager de
proiect va ntelege att perspectiva comercial
a a proiectului ct si pe cea tehnic
a si va ajuta
echipa s
a comute ntre cele dou
a dac
a este necesar. Aceast
a perspectiv
a mai larg
a face posibil
a
oferirea unor informatii critice angajatilor la momentul potrivit.
16

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Figura 3. Efectul m
asur
arii unidimensionale a performantei

Managerii de proiect buni trebuie s

a cunoasc
a tot felul de lucruri utile referitoare la starea
echipei si a proiectului si apoi s
a le aplice pentru a ajuta oamenii s
a-si termine activit
atile.
Transferul la timp al informatiilor este ceea ce face o echip
a mediocr
a bun
a, iar o echip
a
bun
a excelent
a. Niciun sistem de monitorizare a unui proiect nu poate nlocui complet
nevoia oamenilor de a comunica ntre ei despre ce se ntmpl
a, pentru c
a retelele sociale sunt
ntotdeauna mai puternice si uneori mai rapide dect cele tehnice. Marile provoc
ari precum
viziunea asupra proiectului, listele de caracteristici si gracele de lucru se reduc la o serie de
numeroase provoc
ari mai mici care sunt inuentate de ct de bine curg informatiile ntr-o echip
a.
Managerii de proiect joac
a un rol critic n mentinerea activ
a a acestui ux de informatii.
Managerii de proiect petrec mai mult timp cu ecare persoan
a din echip
a dect oricine
altcineva. Ei particip
a la mai multe ntlniri, intr
a n mai multe birouri si vorbesc cu mai
multi colaboratori dect oricine altcineva din organizatie. Dac
a un manager de proiect e fericit,
sup
arat, motivat sau deprimat, ceva din aceste st
ari de spirit se va reecta si asupra oamenilor
pe care i ntlneste n ecare zi. Ceea ce un manager aduce proiectului, bun sau r
au, va
contagios pentru restul echipei.

Concluzii

Managerii de proiect buni cstig

a de obicei un anumit respect din partea proiectantilor, a programatorilor, a testerilor si a celorlalte persoane cu care vin n contact. Un manager de proiect
trebuie s
a e n stare s
a realizeze strategii, planuri, s
a aib
a idei si un mod de gndire si de
conducere cu un impact pozitiv asupra echipei. De obicei, aceasta implic
a g
asirea unor optimiz
ari inteligente n uxul zilnic de lucru sau aducerea unui impuls de entuziasm si ncurajare
n directia potrivit
a la momentul potrivit. Managerii de proiect nu trebuie s
a e supra-oameni
sau s
a e deosebit de inteligenti. Trebuie doar s
a nteleag
a avantajul perspectivei lor asupra
situatiei si s
a foloseasc
a acest lucru.
In the end, the core idea I believe in is that as long as no one gets hurt (except
perhaps competitors), and you involved people in the right way, nothing else matters
but the fact that good stu is made. It doesnt matter how many ideas came from you
or someone else, as long as the outcome is positive. Project management is about
17

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

As a habit, Ive always walked the halls and dropped in on programmers who had
their doors open. Id usually just make small talk, try to get them to laugh about
something, and ask them to show me what they were working on. If they oered,
Id watch a demo of whatever theyd show me. Doing this every few days, even for
a few minutes, often gave me a good idea of the real status of the project.
For example, one morning during the IE 5.0 project, I dropped by Freds o ce.
He was arguing with Steve, another programmer, about how they were going to get
the new List View control to work properly an unforeseen compatibility issue had
been discovered that morning. Neither one of them wanted to do the work. And
from what I could hear, it would take a half-day or more to x. I poked my nose in
and conrmed what they were talking about. They nodded their heads, as if to say,
Yeah, why should you care?I then told them to go talk to Bill down the hall. They
again asked why, thinking this was a very specic architectural issue that I couldnt
easily understand. I smiled and said, Because I just left his o ce, and he has the
new tree control working perfectly on his machine. He came across the problem last
night and xed it as part of another work item. (Scott Berkun The Art of Project
Management)

18

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

Florin Leon, Managementul proiectelor software, http://florinleon.byethost24.com/curs_mps.htm

using any means necessary to increase the probability and speed of positive outcomes.
A useful daily mantra Ive used is Make good stu happen. People would see me
in the hallway or working with a programmer at a whiteboard and ask, Hey Scott,
whatcha doing? And Id smile and say, Making good stu happen. It became a
dominant part of how I approached each and every day, and when I managed others,
this attitude extended out and across the team through them. (Scott Berkun The
Art of Project Management)