Autor: Anca Mehedințu Page 1
Master: Managementul Afacerilor electronice
Anul I
Note de curs
Managementul proiectelor IT
Cuprins:
I. Introducere în Project Management
1. Concepte despre proiecte. Factorii de succes şi eşec ai proiectelor
2. Profesia de manager de proiect. (Project manager). Definiţii. Descriere
3. Participanţii în proiecte. (Project stakeholders). Tehnici de analiză şi influenţare a participanţilor în proiect
4. Managementul proiectelor. Metodologii pentru managementul proiectelor
5. Ciclul de viaţă al proiectului ( Project Life Cycle)
II. Instrumente software folosite în managementul de proiect 1. O introducere în mediul Microsoft Project
2. Definirea proiectului şi a task-urilor acestuia
3. Conceptul de legǎturǎ între douǎ activitǎţi
4. Structura ierarhicǎ a proiectului
5. Crearea legǎturilor între task-uri
6. Drumul critic al proiectului
7. Sensibilitatea unui proiect
8. Întârzieri între activitǎţi
9. Diagrama reţea
10. Resursele proiectului
11. Task-uri eveniment
12. Definirea vacanţelor şi a sǎrbǎtorilor
13. Tehnici de printare a proiectului
14. Schimbarea tipului de task folosit
15. Resurse supraalocate
16. Detaliile financiare ale resurselor
17. Generarea rapoartelor
18. Task-uri recurente
19. Sortarea, gruparea şi filtrarea informaţiilor
20. Mai multă informaţie
21. Proiecte structurate
22. Analiza progresului într-un proiect
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
2
Introducere
Acest curs îşi propune să prezinte un concept managerial şi o metodă de lucru modernă,
care să vină în sprijinul acestui proces de transformare – managementul proiectelor.
Acest curs va oferi masteranzilor:
conceptele şi cunoştinţele necesare unui manager de proiect pentru iniţierea, planificarea,
derularea şi încheierea cu succes a proiectelor coordonate.
deprinderea tehnicilor specifice managementului de proiect privind definirea cerinţelor,
planificarea, controlul riscurilor şi a problemelor, utilizarea resurselor şi a bugetelor,
controlul livrabilelor şi facilitarea echipei de proiect.
bazele formării managerilor de proiect şi a echipelor de proiect pentru derularea proiectelor
în buget, în timp şi cu livrarea rezultatelor aşteptate.
prezentarea practică de crearea a unui plan de proiect cu Microsoft Project.
Derularea unui proiect impune cerinţe complexe echipei de proiect, în general, şi
managerului de proiect, în special. Activitatea echipei de proiect este asemenea activităţii unei
orchestre, în care managerul de proiect este dirijorul. Sub bagheta acestuia, echipa se pregăteşte
pentru o reprezentaţie prin care va încerca să câştige inima publicului – a clientului.
Modificările intervenite în tehnologia informaţiei şi-au pus amprenta şi pe activitatea de
conducere a proiectelor. Unul dintre efectele cele mai importante ale progresului tehnologiei
informaţiei îl constituie modificarea profilului cerinţelor pentru conducătorul de proiect. Nu mai
este suficient ca acesta să stăpânească bine procesele care se desfăşoară în firmă; el trebuie să
aibă abilitatea de a-şi eficientiza munca prin folosirea tehnicilor şi instrumentelor moderne ale
managementului proiectelor şi ale comunicării.
Alegerea unor instrumente tehnice nu rezolvă de la sine problemele din cadrul unui proiect.
Obţinerea unor rezultate performante se bazează în primul rând pe factorul uman, pe aptitudinile
conducătorului de proiect şi ale echipei de lucru.
Oamenii rămân cheia succesului unui proiect. Angajamentul lor pentru o idee, motivaţia
de a lucra în echipă şi de a obţine rezultate de înaltă performanţă, deschiderea spre nou,
perseverenţa şi răbdarea de a trece peste situaţiile dificile, interesul pentru dezvoltarea
profesională sunt numai câteva calităţi indispensabile pentru munca de proiect.
Obiectivul urmărit prin acest curs va fi acela ca la sfârşitul acestui curs, masteranzii să fie
capabili să aplice cu succes metodologia managementului de proiect:
iniţierea, planificarea, derularea şi încheierea unui proiect
elaborarea unui plan integrat de proiect
managementul riscurilor, al problemelor şi al schimbărilor din proiect
participarea şi lucru eficient în echipe de proiect.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
3
I. Introducere în Project Management
1. Concepte despre proiecte. Factorii de succes şi eşec ai proiectelor
2. Profesia de manager de proiect. (Project manager). Definiţii. Descriere
3. Participanţii în proiecte. (Project stakeholders). Tehnici de analiză şi influenţare a participanţilor în
proiect
4. Managementul proiectelor. Metodologii pentru managementul proiectelor
5. Ciclul de viaţă al proiectului ( Project Life Cycle)
1. Concepte despre proiecte. Factorii de succes şi eşec ai proiectelor. Ce este un
proiect?
În activitatea curentă a organizaţiilor - instituţii şi întreprinderi de: stat, companii şi firme
particulare au loc activităţi şi acţiuni foarte diverse, atât din punct de vedere al complexităţii cât
şi din cel al repetabilităţii lor.
Exemple:
într-o fabrică de automobile, în atelierul de montaj se asamblează caroserii prin
repetarea aceloraşi operaţii la fiecare automobil nou. Activitatea de asamblare a unei caroserii,
este una complexă, care se bazează pe mai multe operaţii: fixarea subansamblelor prin
înşurubare, nituire, lipire etc.
la ghişeul de casă al unei bănci se efectuează zilnic sute de operaţiuni de încasare şi de
plată.
Acţiunile de mai sus - indiferent de domeniul de-activitate în care se desfăşoară şi de
gradul de complexitate – au un caracter-permanent şi repetitiv.
Situaţia este diferită dacă se doreşte, de exemplu, introducerea unui nou produs sau
înlocuirea unor procedee.
Înlocuirea modelului de autoturism aflat în fabricaţie cu altul, mai modern, cere o altă
abordare a activităţilor, acestea având un caracter cu totul nou: noul model de autoturism
trebuie mai întâi proiectat. Trebuie realizat şi testat prototipul, elaborată tehnologia şi
metodologia de asamblare şi reorganizat fluxul tehnologic în secţia de asamblare.
Introducerea operaţiunilor în valută la ghişeul de casă al unei bănci presupune
elaborarea unei metodologii noi, stabilirea fluxului informaţional pentru acest gen de activitate,
alegerea unui suport informatic adecvat, pregătirea personalului.
Toate aceste activităţi au caracteristici comune, care le încadrează în categoria proiectelor.
Proiectele sunt activităţi unice, orientate spre obiectiv, cu un grad ridicat de noutate şi cu o
sarcină de lucru complexă. Ele sunt limitate în timp şi din punct de vedere al resurselor materiale
şi umane, necesitând de obicei o colaborare interdisciplinară în cadrul unei structuri
organizatorice speciale, precum şi metode speciale şi riscuri specifice. Obiectivul urmărit îl
reprezintă crearea unei valori noi (produs, serviciu, structură).
sau
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
4
Proiectul presupune efectuarea unei activităţi temporare în scopul creării unui
produs/serviciu nou.
Proiectele apar la toate nivelurile de organizare. Ele pot implica o singură persoană sau
echipe de persoane.
Proiectele sunt activităţi unice, orientate spre obiectiv, cu un grad ridicat de noutate şi cu o
sarcină de lucru complexă. Ele sunt limitate în timp şi din punct de vedere al resurselor materiale
şi umane, necesitând, de obicei, o colaborare interdisciplinară în cadrul unei structuri
organizatorice speciale, precum şi metodici speciale implicând riscuri specifice.
Obiectivul urmărit îl reprezintă crearea unei valori noi (produs, serviciu, structură etc.);
mai pe scurt, proiectul presupune efectuarea unei activităţi temporare în scopul creării unui
produs sau serviciu nou. În limbajul comun, practic, termenul de proiect se foloseşte pentru
pachete de lucru sau activităţi interdisciplinare, în care sunt implicate mai multe persoane sau
domenii de activitate. Această colaborare inter/supra departamentală este obişnuită în practica
zilnică a organizaţiilor. De obicei este vorba de activităţi cu caracter de proiect şi nu de proiecte
în sensul strict al cuvântului.
Operaţiile sunt activităţile primare, cu caracter de rutină. Ele se regăsesc atât în activitatea
de proiect cât şi în cea funcţională, obişnuită într-o întreprindere. Secvenţa de derulare a
operaţiilor este însă diferită în cadrul unui proiect faţă de activitatea funcţională (în linie)
obişnuită.
Încadrarea corectă a unei sarcini de lucru în categoria de proiect, program sau operaţie este
importantă din punct de vedere practic pentru că, în funcţie de încadrarea sarcinii de lucru,
aceasta necesită o anumită organizare structurală, anumite procedee de derulare specifice, tehnici
şi instrumente de suport, alocări de resurse şi produce anumite costuri.
Să încercăm să clarificăm ce este şi ce nu este un proiect, pornind de la această definiţie. În
primul rând, un proiect este temporar, aceasta însemnând că există o dată de încheiere a acestuia.
Proiectele sunt diferite de operaţiile curente, deşi cele două au foarte multe lucruri în comun.
Diferenţa dintre managementul proiectelor şi managementul operaţiunilor curente este dată în
primul rând de diferenţa dintre proiect şi operaţiune curentă.
Aceasta din urmă se derulează într-un timp nedefinit, nefiind stabilită o dată finală de
încheiere (de exemplu, activităţile contabile sau cele care aparţin departamentelor de resurse
umane). Persoanele care derulează operaţiuni curente ar putea coordona şi proiecte; de exemplu,
managerul unui departament de resurse umane al unei organizaţii mari poate organiza un târg de
locuri de muncă pentru absolvenţi de studii superioare.
Proiectele se disting de operaţiile curente printr-o dată de finalizare aşteptată, cum ar fi în
exemplul de mai sus data la care are loc târgul de locuri de muncă.
Conform definiţiei, un proiect este un efort care este întreprins de o echipă sau de o
organizaţie, deci proiectele sunt evenimente intenţionate, planificate. Proiectele de succes nu se
produc spontan, în primul rând are loc o pregătire, o planificare a lor.
În final, fiecare proiect creează un produs sau un serviciu unic. Acesta este livrabilul
proiectului, motivul pentru care proiectul a fost întreprins.
Când vorbim de un proiect?
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
5
Există un obiectiv clar definit? Succesul unui proiect depinde de definirea corectă a
obiectivelor. Practic se pot diferenţia trei tipuri de obiective de bază (Fig. 1):
Fig. 1
Exemplu: elaborarea unui soft integrat care să asigure derularea plăţilor în valută la ghişeu.
Termen de implementare: 4 luni după elaborarea caietului de sarcini, cel târziu pe data de 31-12-
2009.
Care sunt restricţiile şi limitările proiectului? Resursele sunt – de obicei – limitate.
Deseori, încă din faza de definire a obiectivelor rezultă foarte clar anumite restricţii şi
limitări legale, financiare, de timp, de personal sau altele.
Exemplu: realizarea softului integrat pentru derularea plăţilor în valută are restricţii de
buget, de timp şi de personal, fiind puşi la dispoziţia proiectului de ex. 4 programatori şi 2
analişti.
Ce particularităţi trebuie respectate? Caracteristicile importante ale proiectelor sunt
caracterul de noutate al sarcinilor de lucru şi al metodelor de lucru aplicate; complexitatea
proiectului şi caracterul de unicitate al activităţilor desfăşurate. Aceste particularităţi
conduc la un grad sporit de risc. Pentru reducerea complexităţii, proiectele pot fi divizate
în componente mai uşor de coordonat, numite subproiecte, care pot fi contractate de către
o întreprindere externă sau unitate funcţională separată. În derularea lor, subproiectele vor
fi şi ele tratate ca nişte proiecte având obiective, termene şi costuri bine precizate.
Ce structură organizatorică distinctă este necesară pentru realizarea cu succes a unui
proiect? La demararea uni proiect se instituie, de regulă, o echipă de proiect. Relaţiile între
membrii echipei, între aceştia şi conducătorul de proiect şi atribuţiile acestora sunt diferite
de cele funcţionale din cadrul instituţiei. Este posibil chiar ca din echipa de proiect să facă
parte persoane externe sau anumite persoane să participe limitat la activitatea de proiect.
Care sunt procesele în cadrul unui proiect? Proiectele sunt alcătuite dintr-un ansamblu
de procese. Derularea unui proiect parcurge nişte faze tipice, care se regăsesc la fiecare
proiect în parte.
Un proces reprezintă o sumă de acţiuni, de secvenţe corelate care duc la un rezultat concret.
Obiective de specialitate:
- ce trebuie realizat
- ce funcţionalităţi trebuie
îndeplinite
- care sunt cerinţele calitative
care trebuie îndeplinite
Obiective de cost:
- care e bugetul alocat
Obiective de
termen
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
6
Caracteristici ale proiectelor
a) Mărimea proiectului reprezintă măsura costurilor proiectului. Aceasta este un
indicator pe baza căruia se poate aprecia dacă folosirea managementului proiectului se justifică
sau nu. La un proiect foarte mic, se poate ajunge în situaţia în care costurile cu managementul
proiectului să fie mult prea mari în raport cu valoarea întregului contract. Mărimea proiectului
are în vedere şi componenta temporală, în sensul necesarului de resurse financiare sau de
personal pe toată perioada de derulare a proiectului.
b) Gradul de inovare şi complexitatea proiectului depind de următoarele criterii:
- caracterul de noutate al proiectului;
- mărimea proiectului;
- numărul de unităţi organizatorice interne şi externe implicate în proiect;
- dependenţa între sarcinile de lucru individuale;
- implicaţiile sociale;
- riscul în atingerea obiectivului proiectului care rezultă din cota componentelor de proiect
cu grad mare de noutate ştiinţifică şi din implicaţiile sociale ale acestora.
Exemple:
o Elaborarea şi implementarea unui program soft pentru plăţile în valută la o bancă
este un proiect standard. Gradul de noutate este redus, implicaţiile sociale şi relaţionale sunt de
asemenea reduse.
o Cercetarea posibilităţilor de utilizare a Internetului în domeniul bancar este un
proiect care vizează descoperirea de noi oportunităţi, deci reprezintă o temă deschisă. Gradul de
noutate este mare, iar implicaţiile sociale nu sunt cuantificabile într-o primă fază.
Alte elementele caracteristice ale unui proiect sunt:
are un început şi un final bine definite;
implică un număr de activităţi, evenimente şi sarcini;
utilizează o serie de resurse;
are un anumit grad de autonomie faţă de activităţile curente ale organizaţiei;
are ca scop o schimbare percepută ca durabilă de iniţiatorii săi.
Un proiect mai poate fi caracterizat prin:
Scop. Proiectul este o activitate cu un set bine precizat de obiective, este destul de
complex pentru a putea fi divizat în sarcini care necesită coordonare şi control ai termenelor,
succesiunii îndeplinirii sarcinilor, costurilor şi performanţelor.
Ciclu de viaţă. Proiectele trec printr-o etapă lentă de iniţiere, cresc apoi rapid, ating
apogeul, încep declinul şi în final se încheie.
Interdependenţe. Proiectul interacţionează cu operaţiunile curente ale organizaţiei şi,
adesea, cu alte proiecte.
Unicitate. Fiecare proiect conţine elemente care îl fac unic.
Conflict. Realizarea unui proiect presupune utilizarea unor resurse umane şi materiale
utilizate deja în cadrul departamentelor funcţionale ale organizaţiei; foarte adesea, proiectul
concurează proiecte sau acţiuni similare propuse sau derulate de alte organizaţii.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
7
Tipuri de proiecte
După Dennis Lock, proiectele pot fi clasificate în patru mari categorii:
o proiecte de construcţii, petrochimice, miniere, extractive;
o proiecte industriale;
o proiecte de management
o proiecte de cercetare.
După alţi autori, proiectele pot fi clasificate în trei grupuri mari:
o proiecte de investiţii (construcţia unei clădiri noi, restaurarea unui monument istoric,
retehnologizarea unei bănci),
o proiecte de cercetare şi dezvoltare (dezvoltarea unui produs nou, a unei noi tehnologii,
elaborarea unui nou software) şi
o proiecte de organizare (introducerea unui nou concept de marketing, introducerea
managementului proiectelor ca formă alternativă de conducere, lărgirea segmentului de piaţă,
outsourcing-ul unei anumite activităţi).
Factorii de succes şi eşec ai proiectelor
În conformitate cu literatura de specialitate în domeniu, cauzele tipice pentru eşecul unui
proiect ar putea fi următoarele:
obiectivele companiei/organizaţiei nu sunt cunoscute la nivelurile inferioare;
planurile îşi propun prea mult în prea puţin timp;
estimarea financiară nu a fost corespunzătoare;
planurile s-au bazat pe date insuficiente, planificarea nu a fost abordată sistematic;
nu se cunosc obiectivul final, necesarul de personal, punctele cheie, inclusiv ce şi când
trebuie raportat;
estimările sunt mai degrabă ghicite, nu se bazează pe experienţa anterioară sau pe
standarde;
nu a fost alocat suficient timp pentru estimarea corectă;
nu s-a verificat dacă există personal disponibil care să deţină competenţele şi cunoştinţele
dorite;
nu toate persoanele lucrează după aceleaşi specificaţii;
există o fluctuaţie prea mare a personalului de proiect;
nu există consecvenţă în muncă, nu se ţine seama de termene;
managerul de proiect nu a participat activ şi efectiv la planificare, la preluarea
responsabilităţilor;
în anumite cazuri, dacă a trecut prea mult timp de la aprobarea proiectului până la
demararea acestuia, este posibil ca nivelul tehnologic să nu mai corespundă sau obiectivele
şi priorităţile de la nivelul organizaţiei să se fi schimbat, sau situaţia actuală să nu mai
coincidă cu cea considerată punct de plecare în planificarea făcută;
anumite detalii au fost uitate (nu au fost înştiinţate la timp anumite persoane asupra unor
schimbări survenite, anumite materiale nu au ajuns la cine trebuia, anumite persoane nu au
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
8
fost informate din timp asupra unor discuţii/şedinţe/acţiuni la care ar fi trebuit să ia parte
etc.);
managerul de proiect este prea ambiţios şi impune un ritm prea accelerat pentru întreaga
echipă – chiar dacă performanţele şefului sunt deosebite, dacă întreaga echipă nu ţine pasul,
se ajunge în situaţia de „călăreţ singuratic“, în care comunicarea în cadrul echipei lipseşte
sau este necorespunzătoare şi, în lipsa şefului, totul se năruie sau se opreşte.
referindu-ne la proiectele IT, se spune că acestea eşuează datorită unei slabe rezonanţe
între departamentele IT şi utilizatorii aplicaţiilor.
Primii 5 factori identificaţi ca premise ale succesului unui proiect sunt:
implicarea beneficiarului,
sprijinul managementului executiv,
o declaraţie clară a cerinţelor,
o planificare adecvată,
aşteptări realiste.
Aceste elemente nu pot asigura însă singure obţinerea succesului. Dar dacă acestea sunt
îndeplinite în bune condiţiuni, un proiect, va avea o probabilitate mai mare de succes.
Cercetătorii au studiat 24 de zone ale managementului de proiect şi au descoperit că 3
dintre acestea, dacă sunt realizate corespunzător, conduc în mod clar la apariţia unei probabilităţi
ridicate de reuşită a proiectului.
Conform studiului «se poate afirma că aceste 3 variabile (planificarea corespunzătoare,
responsabilizarea clară a membrilor echipei, controlul planificărilor) au cel mai important impact
asupra performanţei proiectului;
Concluzia ar fi că există mulţi factori care duc la succes şi mulţi care duc la eşec. Un bun
management de proiect este un proces aflat într-o continuă îmbunătăţire. Este un proces în care
se fac greşeli şi în care se învaţă din acestea. Este un proces de studiere şi învăţare continuă.
Pentru aceia care nu se pot devota acestui nesfârşit proces, succesele vor fi foarte rare.
2. Profesia de manager de proiect. (Project manager). Definiţii. Descriere
Managerul de proiect este o persoană adecvat pregătită care coordonează toate activităţile
de proiect în vederea finalizării acestuia cu îndeplinirea cerinţelor şi obiectivelor stabilite.
Este evident din cele prezentate mai sus că rolul diferenţiator, factorul care poate influenţa
decisiv şansele de reuşită ale unui proiect este managerul acestuia şi măsura în care acesta are
profilul, pregătirea şi experienţa potrivite pentru un astfel de rol.
În primul rând, este fundamental să se înţeleagă faptul că abilităţile pe care trebuie să le
aibă un Project Manager sunt diferite de cunoştinţele tehnice necesare proiectului, iar aceste
abilităţi se dobândesc prin cărţi şi studiu (în mică măsură), experienţă, imitare şi talent.
Prezentăm în continuare câteva din zonele în care un Project Manager trebuie să fie
competent:
1. Comunicare:
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
9
deoarece aprox. 90 % din timpul unui Project Manager este dedicat comunicării prin
întâlniri şi şedinţe, documente, exprimarea cerinţelor;
arta comunicării vine din experienţă şi prin practică.
2. Management financiar (buget)
bugetul aprobat trebuie controlat;
munca depusă trebuie cuantificată şi plătită corect;
resursele financiare trebuie planificate;
responsabilitatea este împărţită cu Directorul Financiar.
3. Organizarea proiectului - este o abordare metodologică de păstrare şi de regăsire a
informaţiei atunci când este nevoie de ea, evitând astfel timpul şi resursele pierdute datorită
lipsei informaţiei.
4. Abilităţi de negociere - Project Manager-ul trebuie să aibă abilitatea şi prestanţa de a
negocia cu Furnizorii, cu Clientul şi cu Propriul management.
5. Conducerea echipei (leadership) - este abilitatea de a crea o legătură între Project
Manager şi restul echipei care să îi "inspire” pe aceştia şi să îi conducă spre atingerea
obiectivelor proiectului.
În concluzie, competenţele cheie ale unui project manager de succes sunt:
Viziune de ansamblu pe termen lung asupra proiectului
Scopuri clare
Inovare şi creativitate
Participativitate la soluţionarea problemelor
Gândire şi planificare sistematică
Bun strateg
Bun evaluator al riscului
Capacitate de comunicare
Spirit de echipă
Permisivitate, delegare de autoritate şi capacitate de recunoaştere a
performanţelor.
3. Participanţii în proiecte (Project stakeholders)
Participanţii la proiect sunt cei care determină gradul de succes al proiectului. Cei care
participă la proiect deseori se pot afla în stare tensională şi chiar conflictuală. Cunoaşterea de
către managerul de proiect a tuturor participanţilor cât şi a rolului şi aşteptărilor acestora va duce
la găsirea soluţiilor de compromis care să nu blocheze derularea proiectului şi finalizarea pentru
a se întâmpina aşteptările participanţilor. E bine să se deosebească din categoriile participanţilor,
participanţii cheie - cei care vor determina gradul în care proiectul finalizat, a întâmpinat
aşteptările participanţilor sau nu.
Echipele care lucrează în cadrul unor proiecte sunt formate adesea din oameni proveniţi
din diferite domenii, care urmează să lucreze împreună doar pe durata proiectelor. Acest lucru
poate fi privit ca un beneficiu, deoarece conlucrarea poate aduce membrilor grupului o
diversificare a cunoştinţelor
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
10
În afară de managerul de proiect şi de membrii echipei, există un număr surprinzător de
mare de persoane care pot fi implicate într-un fel sau altul. Toate aceste persoane sunt importante
într-o anumită măsură, fie pentru că sunt afectate de rezultatele proiectului, fie pentru că pot ele
însele afecta rezultatele - în sens pozitiv sau negativ. Participanţi la "jocul" proiectului, implicaţi
numai periferic, sunt totuşi importanţi. Este important să-i cunoaştem şi să aflăm ce rol
îndeplinesc ei în mediul în care se desfăşoară proiectul.
Participanţii implicaţi în proiect, pot fi persoane fizice sau juridice.
Categoriile cele mai des întâlnite sunt:
Managerul de proiect (Project manager) - decide şi alocă resursele de proiect.
Sponsorul/Susţinătorul Proiectului (Project Sponsor) - decide şi alocă resursele de
proiect. Pentru aproape orice proiect (sau, înaintea acestuia, propunere) există cineva in
rolul de sponsor. Morris a definit acest rol după cum urmează: Sponsorul este persoana
care furnizează resursele necesare proiectului: persoana care este responsabilă cu
asigurarea succesului proiectului atât la nivelul lucrării propriu-zise, cât şi la nivel
instituţional. Rolul sponsorului este similar cu al Preşedintelui Consiliului director dar este
diferit de al promotorului proiectului.
Promotorul proiectului. Promotorul proiectului sau al propunerii de proiect poate (sau nu)
să fie aceeaşi persoană cu sponsorul. Promotorul este o persoană care acţionează în
sprijinul unui proiect sau al unei propuneri; această persoană este ascultată de factorii de
decizie şi promovează în faţa acestora cauza unui proiect sau propuneri. În lucrarea Preiei
conducerea se folosesc la caracterizarea rolul promotorului termeni ca "insistenţă",
"influenţare", 'sprijin în împrejurări dificile', 'impunerea unor schimbări" etc.
Beneficiarul - client sau consumator beneficiază direct de rezultatele proiectului.
Consumatorul este un termen similar cu cel de client, pentru că, de regulă, îl desemnează
pe cel care cumpără ceva; de regulă, se înţelege prin consumator o persoană cu care avem
de-a face. În discuţiile despre calitate se obişnuieşte să se folosească expresia "satisfacerea
exigenţelor consumatorului". Astfel la implementarea unui sistem informatic de facturare
cei care vor introduce datele în computer vor fi utilizatorii.
Clientul. Termenul de client este utilizat adesea în contracte pentru a desemna persoana
sau organizaţia care recurge la un contract formal pentru obţinerea unor servicii
profesionale. Clientul este persoana sau organizaţia aflată în poziţia de cumpărător al
serviciilor furnizate de o altă persoană sau organizaţie contractantă. Clientul poate fi şi
sponsor sau promotor; se poate totodată ca aceste roluri să fie jucate de mai multe persoane
diferite. Vom utiliza termenul de client pentru a-l desemna pe cel care plăteşte pentru a
beneficia de serviciile stabilite printr-un contract chiar şi în cazurile în care contractul este
informal - cum este cel dintre două departamente din aceeaşi organizaţie, să spunem.
Cercul de comandă/Statul Major/Board-ul Director (Board of Directors).
Managerii Executivi (Executive Managers).
Managerii departamentali/operaţionali (Department Managers)
Distribuitorii (Vendors) - furnizează clienţilor produsul. Sunt implicaţi în depozitare,
promovare, livrare.
Furnizorii (Suppliers) - vor participa la obţinerea tuturor resurselor necesare proiectului.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
11
Alte persoane interesate şi afectate de derularea şi /sau rezultatele proiectului. În această
categorie se înscriu : instituţii publice, comunitatea, angajaţii etc.
Deseori participanţii la proiect au conflicte de interese sau ajuns pe poziţii generatoare de
tensiuni. Cunoaşterea completă a participanţilor, intereselor cât şi cunoaşterea aşteptărilor
participanţilor va diminua şansele de blocare a proiectului, project managerul fiind în situaţia de
a găsi soluţia minimă care să nu blocheze derularea proiectului. Ca situaţie limită nu trebuie
neglijaţi beneficiarii proiectului, tot ceea ce va fi întreprins în cadrul managementului
conflictelor interne, fiind făcut în aşa fel încât să favorizeze beneficiarii proiectului.
4. Managementul proiectelor. Metodologii pentru managementul proiectelor.
Managementul proiectelor este procesul prin care managerul proiectului planifică şi
controlează etapele şi activităţile proiectului şi resursele pe care organizaţia le pune la dispoziţia
proiectului.
Managementul proiectului este procesul de organizare şi supraveghere a proiectului
pentru a asigura realizarea acestuia conform planificării, în limitele bugetului şi conform
specificaţiilor stabilite.
Avantajele şi dezavantajele utilizării managementului pe proiecte
Managementul pe proiecte permite:
un control foarte bun asupra utilizării resurselor, fiind extrem de util în situaţiile când
resursele disponibile în activitatea unei organizaţii sunt restrânse;
relaţii mai bune cu clienţii;
timpi reduşi de dezvoltare a organizaţiei, costuri mai mici, calitate mai înaltă şi marje de
profit mai mari;
creşterea eficienţei activităţii în ansamblu, prin orientarea spre rezultate, îmbunătăţirea
coordonării interdepartamentale şi îmbunătăţirea moralului angajaţilor.
Managementul pe proiecte poate duce, în acelaşi timp, la:
creşterea complexităţii organizaţiei;
apariţia unei tendinţe mai accentuate de încălcare a unor componente ale politicii interne a
firmei, dat fiind gradul ridicat de autonomie a personalului implicat în activităţile
organizate pe bază de proiecte;
creşterea costurilor anumitor activităţi, apariţia unor dificultăţi în organizare, utilizarea
incompletă a personalului în intervalul de timp dintre finalizarea unui proiect şi iniţierea
următorului proiect.
Instrumente utilizate în elaborarea unui proiect: Alături de instrumentele utilizate in
mod curent pentru colectarea, sistematizarea şi analiza informaţiilor privind organizaţia
solicitantă şi mediul economico-social în care aceasta funcţionează (bilanţ, cont de profit şi
pierderi, alte evidenţe financiar-contabile ale organizaţiei, studii de piaţă etc.), managementul
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
12
proiectelor utilizează o serie de instrumente şi tehnici specifice (de exemplu: metoda cadrului
logic, diagramele de tip Gantt sau de tip PERT sau analizele SWOT).
Managementul proiectelor s-a dezvoltat inclusiv ca urmare a creşterii accesului la
tehnologii informaţionale moderne, astfel încât în prezent au devenit instrumente curente
tehnologiile care facilitează lucrul în echipe multidisciplinare (groupware), utilizarea unor
sisteme informaţionale dedicate managementului proiectelor (care utilizează lucrul în cadrul
unor birouri virtuale, programe pentru planificarea, realizarea şi evaluarea proiectelor, evaluarea
riscurilor aferente unui proiect etc.).
Un instrument la fel de util, chiar dacă de o natură diferită, îl reprezintă asociaţiile
profesionale pentru managementul proiectului, care facilitează accesul la informaţii de ultimă oră
relevante pentru organizaţiile care utilizează - sau intenţionează să-şi dezvolte - o organizare
managerială bazată pe proiecte.
Managementul proiectelor IT răspunde aceloraşi cerinţe fundamentale referitoare la
competenţele necesare dar, ca pentru oricare alt domeniu, există un anumit specific al proiectelor
IT care trebuie luat în calcul atunci când procesele de project management sunt gândite şi
planificate. Identificarea acestor aspecte de specificitate nu este însă acoperită nici de cerinţele
referitoare la competenţele managerului de proiect (întrucât ţine de experienţa fiecărui manager
de proiect în parte) şi nici de cerinţele metodologiilor standard de project management (care ne
spun “ce” trebuie făcut, dar nu şi “cum” trebuie făcut).
Managementul proiectelor IT este o componentă importantă de management, datorită
complexităţii soluţiilor şi dificultăţilor care pot apare în implicarea utilizatorului final. Succesul
este asigurat de folosirea unor metode performante şi experienţa echipei.
Practica arată că există multe situaţii în care managerii de proiect nu reuşesc să treacă
pragul dintre teorie şi practică şi nu înţeleg modul practic şi pragmatic în care anumite cerinţe ale
managementului de proiect trebuie să se regăsească într-un proiect real. Este evident faptul că
marea majoritate a implementărilor de proiecte software nu se poate face fără un management
adecvat. Dar ce înseamnă cu adevărat management de proiecte software? Într-un număr mare
de situaţii Managerul de Proiect Software este un fel de "one man show": el este atât
coordonatorul proiectului cât şi Technical Lead Developer, System Analyst, Database designer,
Web designer şi multe altele. Aceste aspecte sunt reale pentru firmele mici care, deşi propun
soluţii software atractive atât ca preţ cât şi ca facilităţi oferite, neavând suficient personal angajat,
mizează întreaga încărcare pe o singură persoană. Din această cauză, deşi Managerul de Proiect
este o persoană suficient de calificată în toate domeniile enumerate mai sus, acesta sfârşeşte, din
cauză de supraîncărcare, prin a nu mai reuşi să-şi execute funcţia iniţială, şi anume de a aplica
metodologii prin care să garanteze livrarea produsului în parametrii stabiliţi de timp şi de buget.
Această problemă tinde să se extindă şi către case de software dedicate, unde rolul de Technical
Lead Developer, System Architect şi Project Manager încep să devina una şi aceeaşi funcţie în
cadrul unui proiect.
Prezentăm în continuare câteva propuneri care pot duce la succesul activităţii desfăşurate
de echipa de proiect:
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
13
În primul rând sarcina Managerului de Proiect este să convingă stakeholderii proiectului
că el este implicat în proiect strict ca persoană delegată să supravegheze, măsoare,
raporteze şi să ia orice măsură necesară păstrării proiectului pe linia de lucru necesară. Nu
de puţine ori Managerii Români de Proiecte Software provin din rândul celor care, cândva,
au dezvoltat aplicaţii sub conducerea unui alt Manager, şi uită că munca lor trebuie să se
focuseze de la acest nivel pe partea managerială şi mai puţin pe lucruri tehnice. Mulţi încă,
forţaţi de împrejurări sau nu, se implică la nivel de codare, şi, uneori, intră atât de tare în
procesul de dezvoltare încât uită să-şi mai exercite atribuţiile de bază ale funcţiei lor.
În al doilea rând sarcina Managerului de Proiect este să "ia pulsul" echipei pe care o
conduce. O echipă care este suprasolicitată pierde automat motivarea şi concentrarea
necesară dezvoltării produselor conform planningului iniţial. Totodată implicarea activă în
rândul echipei ar trebui, pe de o parte, să ofere suficiente informaţii despre moralul echipei,
şi pe de altă parte să asigure rolul de leader pe care trebuie Managerul trebuie să-l
sublinieze echipei.
În al treilea rând un bun Manager de Proiect trebuie să-şi asume greşelile şi mai ales să
înveţe din ele.
Proiectele nereuşite au devenit ceva comun astăzi. Motivele nereuşitelor pot fi:
lipsa sau slaba coordonare a resurselor şi activităţilor;
lipsa sau slaba comunicare între părţile implicate, ducând către un produs care nu
îndeplineşte cerinţele Clientului;
proasta estimare a duratei şi costului, rezultând un timp mai îndelungat şi costuri mai mari
decât cele aşteptate;
prea puţini indicatori măsurabili;
planificare inadecvată a resurselor, activităţilor şi a momentelor de execuţie;
lipsa punctelor de control intermediare privind progresul, astfel că proiectele nu arată
statusul exact decât prea târziu;
lipsa controalelor de calitate, rezultând în livrări de produse inacceptabile sau nefolositoare.
O metodă bună va ghida proiectul printr-un set de activităţi vizibile, controlate şi bine
conduse către scopul propus. Fără o metodă, toţi cei care conduc un proiect şi cei care lucrează la
el vor avea idei diferite despre cum cred ei că trebuie organizat şi cum trebuie acoperite diferite
aspecte ale proiectului. Toţi cei implicaţi nu vor cunoaşte clar câtă autoritate şi responsabilitate
au, ceea ce va duce la o confuzie totală legată de proiect. Fără o metodă, proiectele rar sunt duse
la capăt la timp şi cu costuri acceptabile - valabil în special pentru proiectele mari.
Rezultatul schimbării nu este întotdeauna perceput ca ceva benefic de către participanţii
implicaţi într-un proiect. “De ce să schimb când merge şi aşa? O schimbare în procesul de lucru
poate afecta rezultatele acestui trimestru! “ Acestea sunt numai câteva din cele mai des utilizate
formulări în momentul în care intervin schimbări. Psihologic vorbind, schimbarea determină
modificarea unor automatisme din viaţa de zi cu zi, ceea ce poate produce fie un sentiment de
teamă, fie un sentiment de reticenţă. Cel mai grav este sentimentul de nepăsare, ceea ce poate
indica o lipsă totală de interes a subiectului în ceea ce priveşte efortul depus pentru schimbarea
în mai bine.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
14
Schimbarea într-un proiect software poate surveni din mai multe direcţii:
- beneficiarii proiectului realizează că cerinţele iniţiale nu se mai potrivesc cu nevoile
actuale;
- echipa de dezvoltare trebuie să facă faţă unei schimbări majore în aplicaţie;
- cei care vor utiliza aplicaţia nu doresc înlocuirea celei existente cu aceasta.
Sarcina echipei de proiect este să orchestreze totuşi schimbarea. Vom analiza puţin prima
situaţie: intervine o cerere de schimbare în arhitectură / interfaţă / conţinutul aplicaţiei cu impact
major în livrarea proiectului în parametrii stabiliţi iniţial. Situaţie concretă: clientul realizează că
modulul de CRM dezvoltat conţine gestionarea unui flux informaţional inconsistent cu realitatea
din firmă, drept pentru care lansează o cerere de schimbare în aplicaţie. Managerul de Proiect
înştiinţat trebuie în primul rând să identifice motivaţia cererii de schimbare: este vorba despre un
proces care, deşi a fost modelat corect, a fost greşit implementat? Sau este vorba despre o analiză
greşită de la început? Sau pur şi simplu schimbarea din firmă a generat o nouă nevoie care
trebuie acoperită cât mai urgent?
Oricare ar fi motivul trebuie livrată o soluţie documentată şi care trebuie acceptată de client,
şi abia după ce documentul poartă semnătura clientului se poate continua cu dezvoltarea
soluţiilor care să corespundă schimbării. În toate cazurile este recomandat ca documentul propus
clientului să conţină descrierea cât mai clară a problemei raportate, a soluţiilor propuse (dacă
există mai multe variante), şi a impactului asupra proiectului (exprimat în cost financiar şi de
timp). Este bine ca oferta să aibă soluţii multiple (în general trei ar trebui să fie suficiente) astfel
încât să se ofere clientului posibilitatea de a decide, funcţie de buget sau timp, care este soluţia
ideală din punctul lui de vedere. În nici un caz nu trebuie propuse soluţii gen "nu se poate".
Clientul mulţumit este clientul care primeşte ceea ce şi-a dorit pentru banii pe care i-a plătit. În
marea majoritate a cazurilor aceştia se vor axa pe aspectul financiar al soluţiei, şi vor alege, în
general, modalitatea de rezolvare a problemei care costă cel mai puţin. Nu trebuie cedat
presiunilor de genul "am discutat la început costul proiectului, aşa că nu vreau să aud de costuri
suplimentare". Există suficientă motivaţie pentru a cere modificare de buget în cazul în care
există o dovadă a acceptanţei planului iniţial de către client. Schimbarea odată acceptată trebuie
mai apoi comunicată echipei de dezvoltare, ceea ce ne conduce la situaţia a doua.
Echipa de proiect este reticentă schimbării în aplicaţia deja dezvoltată. Este o problemă cu
care firmele de outsourcing se confruntă destul de des: ce facem cu programatorii care sunt în
pragul unei revolte cauzate de desele schimbări care au loc în direcţia de dezvoltare? În general
Managerul de Proiect trebuie să înţeleagă faptul că programatorul se "ataşează" de rezultatul
muncii sale, iar schimbarea acestuia este percepută, uneori, ca o lovitură luată personal (există
cazuri extreme de acest gen). Alţi programatori îşi motivează rezervarea faţă de schimbarea
cerinţelor prin temerea de a nu fi traşi la răspundere pentru întârzierea pe care o pot genera
proiectului implementând schimbările cerute. Oricare ar fi motivele, rezultatul este aproape
acelaşi: încep să apară fricţiuni între programatori şi persoana care comunică nevoia de
schimbare, fricţiuni ce pot degenera în conflicte sau demisii.
Este imperativ necesar ca Managerul de Proiect să se implice în dezamorsarea conflictelor
apărute în echipa de dezvoltatori. Demisia unei persoane însărcinate cu dezvoltarea unei părţi din
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
15
aplicaţie poate genera costuri mult mai mari decât cele anticipate, la pierderea credibilităţii
Managerului de Proiect în faţa echipei şi, în cel mai rău caz, chiar la concedierea acestuia.
Managerul de Proiect trebuie să comunice echipei de dezvoltare schimbarea, şi mai ales
motivaţia acesteia. Evident ca în enunţarea propunerii de soluţii ale schimbării au fost deja
implicate persoane tehnice din proiect (arhitectul sistemului, team-lead developeri, etc), deci
exista şanse ca aceştia să fi comunicat deja echipei, corect sau distorsionat, posibilele schimbări
ce pot fi aduse proiectului. Se recomandă o discuţie anterioară purtată cu aceştia prin care să fie
convinşi de faptul că s-a analizat în detaliu impactul asupra proiectului şi că noul plan de proiect
conţine modificările necesare.
Ultima situaţie este cea a Managerului de Proiect de implementare a soluţiei software
dezvoltată, cel care are "ingrata" misiune de a comunica viitorilor utilizatori ai sistemului că au
un nou tool de care trebuie să se folosească în activitatea zilnică. Revenind la o situaţie concretă:
compania X tocmai a primit in folosinţă sistemul A care va înlocui sistemul B existent de ceva
vreme în firmă; majoritatea angajaţilor au deja experienţă în utilizarea sistemului B, drept pentru
care încearcă orice în a-şi convinge superiorii că investiţia nu a rentat. Unul din motivele cel mai
des invocate este acomodarea cu noul sistem: "Noul sistem informatic mi se pare mult mai
complicat, din cauza noilor facilităţi introduse". Afirmaţia poate fi demontată de echipa de
traineri aducând următoarele motive:
- sistemul nou este menit să reducă timpul petrecut înainte cu introducerea informaţiei in
sistemul existent deoarece a fost analizat fluxul de informaţie din cadrul companiei şi au
fost eliminate toate bottleneck-urile descoperite
- se evidenţiază ergonomia noii interfeţe comparativ cu cea veche
- se precizează faptul că orice noutate durează până devine automatism.
Un alt motiv invocat este "Aplicaţia asta nouă nu ştie să facă ... aşa cum ştiam eu că se face
în sistemul vechi". Da, într-adevăr, poate că procedura de lucru s-a schimbat, însă trainerii
trebuie să demonstreze că noua procedură de lucru este mult mai. Formarea operatorilor
sistemului poate fi un proces de durată, dar odată încheiat astfel de obiecţii ar trebui să dispară de
la sine. Oricum ar sta lucrurile echipa de proiect trebuie să dea dovadă de tact. Implementarea nu
înseamnă numai câştigarea utilizatorilor, ci şi a echipei de maintenanţă (IT Helpdesk, Sysadmin,
etc). De aceea, trebuie pregătite programele de training adecvat pentru fiecare tip de utilizator.
Trebuie pregătită perfect tema de acasă (procedura de import date, use-case-uri adecvate fiecărui
utilizator, etc) pentru a nu fi puşi în situaţia jenantă de a explica o funcţionalitate şi a fi întrerupţi
de o eroare a sistemului care nu a fost tratată şi duce la închiderea completă a aplicaţiei.
Metodologii pentru managementul proiectelor
Fiecare metodologie îşi are propriul mod de organizare a proceselor, procedurilor, a celor
mai bune practici şi şabloanelor necesare gestionarii cu succes a proiectelor. Dacă ne uităm mai
detaliat la aceste metodologii vom observa multe asemănări. Există şi deosebiri, nu atât datorită
incompatibilităţilor cât datorită accentului care se pune pe acestea.
De exemplu, există câteva metodologii care fac parte din managementul proiectelor şi care
includ asimilarea unor cunoştinţe de business. Astfel, dacă un volum mare de muncă este
împărţită pe mai multe etape, un întreg proiect poate fi etapa de analiza, iar un alt proiect poate fi
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
16
etapa de design şi constituire. În cel de-al doilea proiect nu ar fi necesară asimilarea unor
cunoştinţe de business.
A) Una din metodologiile standard recunoscute în managementul proiectelor o reprezintă
Project Management Body of Knowledge (PMBOK), care reprezintă un standard elaborat
de Project Management Institute (PMI). PMBOK asigură baza necesară înţelegerii cum să
gestionăm munca ca şi un proiect, dar nu reprezintă în mod necesar o metodologie care
poate fi utilizată direct în gestionarea proiectelor. De exemplu, conţine informaţii, dar nu
proceduri; conţine definiţii dar nu practici sau tehnici; conţine output-uri dar nu şi
template-uri utilizabile.
B) O altă metodologie este AGILE folosită în managementul proiectelor software care
asigură livrarea la timp, în marjele de calitate, a proiectelor, optimizând rezultatele echipei
prin cresterea productivităţii, a gradului de planificare şi prin optimizarea structurilor
existente în organizaţie.
AGILE presupune respectarea următoarele principii:
1. Prioritatea este satisfacerea nevoilor clientului prin lansări susţinute şi în timp de software
cu valoare.
2. Cererile de schimbare sunt binevenite, chiar şi în stadiile avansate ale dezvoltării.
Procesele AGILE trebuie să poată conduce aceste cereri către un avantaj competitiv al
clientului.
3. Se livrează frecvent software funcţional, cu o frecvenţă săptămânală spre lunară, cu
preferinţă pentru termenii mai scurţi.
4. Software-ul funcţional livrat este principala măsură a progresului.
5. Cele mai bune arhitecturi, cerinţe şi pattern-uri de dezvoltare reies din echipe care ştiu să
se organizeze.
6. La intervale regulate, echipa reflectă asupra modalităţilor de îmbunătăţire a eficienţei, apoi
îşi ajustează perfomanţa.
Metodologia AGILE există în mai multe feluri: XP (eXtreme Programming), SCRUM,
DSDM, Crystal, Feature Driven Development, Lean Software Development (au fost
menţionate doar câteva). Toate folosesc principii de bază ale filozofiei AGILE, dar o
implementează în moduri diferite.
Tehnica sugerată (fiind cea mai comună) este SCRUM. Nu e un acronim, este doar un
process wrapper, general şi scalabil, gândit să rezolve unele din cele mai des întâlnite probleme
în dezvoltarea de proiecte software, cum ar fi:
Haos datorită schimbării cerinţelor - cerinţele reale sau percepute ale unui proiect se
schimbă dramatic din momentul în care produsul este în faza de design până la faza de
lansare. În mai toate metodologiile de dezvoltare, analiza este făcută în partea de început a
proiectului, şi nici o schimbare nu mai este permisă până spre final.
Estimări nerealiste de timp, cost şi calitate a produselor - managerul de proiect şi
dezvoltatorii tind să subestimeze cât timp şi resurse sunt necesare pentru un proiect, şi câte
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
17
funcţionalităţi pot fi livrate în aceste constrângeri. Acestea nu pot fi niciodată prevăzute
100% în faza de început a ciclului de dezvoltare.
Dezvoltatorii trebuie să mintă când se discută progresul proiectului - când managementul
subestimează timpul şi costul necesar atingerii unui anumit nivel de calitate, dezvoltatorii
fie vor altera realitatea referitoare la progresul dezvoltării produsului, fie vor fi nevoiţi să
facă faţă indignării managerului de proiect.
Valorile SCRUM sunt derivate din cele ale metodologiei AGILE de software
development:
Indivizii şi interacţiunea primează proceselor şi instrumentelor de dezvoltare - deşi acestea
din urmă sunt de folos, nu vor aduce nici un plus în progresul dezvoltării dacă echipa nu
învaţă să comunice şi să colaboreze într-o manieră constructivă.
Software-ul funcţional livrat primează unei documentaţii stufoase - documentarea
progresului este importantă, dar este mult mai important ca rezultatul final să funcţioneze
conform nevoilor clientului.
Colaborarea cu clientul primează negocierii de contracte - ideea de bază este că nu trebuie
să se urmărească contractarea unui proiect pentru a primi bani, ci pentru a rezolva
problema ridicată de client.
Răspunde schimbărilor conform planului - dacă cerinţele se schimbă, şi planul de proiect şi
design-ul trebuie actualizate.
Metodologia de Management a Proiectelor Software SCRUM se bazează pe SPRINT-uri.
Aşa cum un alergător de maraton încearcă să obţină un ritm constant pentru a ajunge linia de
finish, echipele SCRUM trebuie să dezvolte produse cu o anumită viteză pentru a reuşi livrarea
în timpul alocat proiectului.
Un SPRINT are o dată de start şi una de încheiere. Sunt evenimente fixate în timp, în care
nici o modificare nu este permisă. Terminarea unui SPRINT poate fi considerată milestone
pentru proiect, deoarece livrează rezultatele muncii depuse pe durata timpului de execuţie:
versiune intermediară, actualizarea planului de proiect sau project backlog, status report-uri, etc.
Se recomandă folosirea de SPRINT-uri egale ca durată, pentru a putea uşura munca de
măsurare a progresului proiectului. Acestea ar trebui să nu fie mai lungi de 3 săptămâni, nici mai
scurte de o săptămână. Dimensiunea unui sprint variază de la proiect la proiect, funcţie de
numărul de pachete de lucru incluse.
Pentru a defini sprinturile se împarte timpul total de execuţie al proiectului în ferestre egale
folosind regula de mai sus şi păstrând în atenţie toate pachetele de lucru definite în planul de
dezvoltare. De exemplu, pentru o versiune de aplicaţie care trebuie livrată în 3 luni, se
recomandă 9 sprint-uri (de 7 zile lucrătoare) şi unul final (ultimele 5 zile) pentru a pregăti
versiunea de release şi documentaţia aferentă. Project Managerul ar trebui să păstreze ultimul
sprint atât de scurt cât să se simtă confortabil în a-şi rezolva sarcinile legate de închiderea
proiectului, şi este şi ultima şansă de a asigura un release bug-free, documentat, etc. În această
ultimă etapă, în cazul în care mai există probleme, doar cele majore se mai pot rezolva.
Primul sprint ar trebui întotdeauna consacrat etapei de analiză. În această fază SCRUM
Master-ul şi Product Owner-ul ar trebui să se întâlnească să discute despre ce trebuie executat,
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
18
care sunt priorităţile şi ce resurse se pot aloca. Principalul scop este livrarea unui Project
Development Plan coerent, pe care dezvoltatorii să-l poată urmări.
Numărul de pachete de lucru sau conţinutul acestora nu se mai modifică odată ce un
SPRINT a fost demarat. În cazul în care se descoperă probleme sau apar cereri de schimbare pe
pachetele existente, acestea vor fi incluse în planul de dezvoltare pentru SPRINT-urile următoare,
astfel încât să nu existe interferenţe în planul curent de lucru.
C) Method 123 Project Management Methodology ('MPMM') este o metodologie de
management de proiect care descrie în detaliu fazele şi activităţile necesare pentru a derula
proiectele cu succes.
Ciclul de viaţă al proiectului care este încorporat în metodologia MPMM™ are 4 faze (Fig.
2):
Iniţierea presupune demararea proiectului, documentarea business case-ului, studiului de
fezabilitate, termenii de referinţă ai proiectului şi numirea echipei iniţiale.
Planificarea presupune planificarea şi crearea planurilor asociate: project plan, planul de
resurse, planul finaciar (bugetul), planul de obţinere a acceptanţelor şi planul de
comunicare.
Execuţia presupune crearea livrabilelor proiectului şi controlul diverselor elemente cum ar
fi livrabilele, aria de cuprindere a proiectului (scope), calitatea, riscurile şi problemele
(issues).
Închiderea presupune dezalocarea resurselor, predarea către client şi recepţia livrabilelor
proiectului şi realizarea analizei post implementare a proiectului.
Fig. 2
Iniţierea proiectului (Project Initiation).
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
19
Iniţierea proiectului (Project Initiation) reprezintă prima fază a ciclului de viaţă al
proiectului şi înseamnă demararea proiectului. Proiectul este iniţiat definind obiectivele şi aria lui
de cuprindere (scop), făcând justificarea economică pentru iniţierea lui şi prezentând pe larg
soluţia care va fi implementată. De asemenea, se va identifica managerul de proiect care este
potrivit să conducă acest proiect, şi se va organiza proiectul, iar la sfârşitul acestei faze se va face
o analiză (review) cu ce a mers bine şi ce nu în timpul acestei faze de iniţiere. Faza de iniţiere a
proiectului are 6 etape principale (Fig. 3):
Fig. 3
Planificarea (Project Planning)
După definirea proiectului şi numirea echipei de proiect se intră în faza de planificare
detaliată (Project Planning phase). Aceasta necesită crearea unui set de documente de planificare
care să ghideze echipa de proiect în derularea proiectului. Faze de planificare (Planning Phase)
presupune realizarea celor 10 etape principale (Fig. 4):
Fig. 4
Execuţia (Project Execution)
După definirea proiectului şi obţinerea setului de documente de planificare a proiectului,
proiectul intră în faza de execuţie. (Execution phase). Aceasta este faza în care livrabilele
proiectului sunt realizate (construite, dezvoltate, elaborate) şi apoi prezentate clientului (intern
Dezvoltă o
afacere
Stabilirea termenilor de
referinţă
Configurează
planul de proiect
Elaborează studiul de
fezabilitate
Stabileşte echipa
de proiect
Efectuează
revizuirea
Creează planul
de proiect
Creează planul
de resurse
Creează planul
financiar
Creează planul
de calitate
Creează planul
de risc
Creează planul
de aprobare
Creează planul
de comunicare
Creează planul
achiziţii
Contractele cu
furnizorii
Efectuează
revizuirea
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
20
sau extern) pentru acceptanţă. În timpul realizării livrabilelor, un set de procese (secvenţa de paşi,
de activităţi) sunt întrebuinţate pentru a monitoriza şi controla livrabilele pe care proiectul le va
livra. Aceste procese includ managementul timpului, costurilor, calităţii, schimbării în proiect,
problemelor (issues), riscurilor, furnizorilor şi comunicării între membrii echipei de proiect. În
momentul în care toate livrabilele proiectului au fost produse şi clientul a acceptat soluţia finală,
proiectul este gata să fie închis (Fig. 5).
Fig. 5
Închiderea (Project Closure)
Închiderea proiectului (Project Closure) presupune predarea livrabilelor către client,
predarea documentaţiei rezultate, închiderea contractelor cu furnizorii, dealocarea resurselor din
proiect, şi comunicarea către toţi participanţii din proicet (stakeholders) a închiderii proiectului.
Ultima etapă din proiect este analiza post implemntare a proiectului (Post Implementation
Review) pentru a determina nivelul de succes al proiectului şi a identifica ce a mers bine şi ce nu
a mers (Fig. 6).
Fig. 6
Observaţie: Mai mult de 45.000 de profesionişti din 50 ţări folosesc în mod curent ciclul
de viaţă de proiect MPMM Project Life Cycle pentru a derula proiecte. Metodologia de project
management MPMM are la bază standardele: PMBOK® (www.pmi.org) and Prince2®
(www.prince2.org.uk) .
Construirea
livrabilelor
Monitorizare&
Control
Efectuează
revizuirea
Execută manag. timpului
Execută manag. costurilor
Execută manag. calităţii
Execută manag. schimbării
Executa manag. riscului
Executa manag. conflictelor
Executa manag. achiziţiilor
Executa manag. aprobării
Execută manag. comunicării
Efectuează închiderea
proiectului
Finalizează revizuirea
proiectului
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
21
5. Ciclul de viaţă al proiectului ( Project Life Cycle)
Fig. 7 Ciclul de viaţă al unui proiect
Etapa 1 – Conceperea proiectului (iniţierea). În faza de elaborare a proiectului o parte
dintre informaţiile necesare au un caracter informal, fiind colectate, într-o mare măsură, din
mediul extern, astfel încât să se asigure o justificare cât mai fundamentată a problemei
identificate, o încadrare cât mai corectă în obiectivele şi strategiile firmei, dar şi pentru
identificarea şi verificarea potenţialilor parteneri sau furnizori de servicii.
Tot în această etapă, se folosesc destul de multe informaţii şi din mediul intern, necesare
identificării şi analizei soluţiilor, pentru a se putea stabili, în final, scopul şi obiectivele
proiectului. Se apelează la datele existente în bazele de date ale altor sisteme din cadrul
organizaţiilor, cum ar fi sistemul comercial, de producţie, cel financiar sau de resurse umane.
Datele interne sunt utilizate, cu precădere, la elaborarea studiilor de fezabilitate, pe baza
cărora se fundamentează decizia de adoptare a unei soluţii.
Pentru etapa de concepere, nu se poate vorbi încă de un sistem informaţional care să poată
fi uşor formalizat şi automatizat, întrucât informaţiile care se colectează şi prelucrează sunt din
diverse surse, se diferenţiază în funcţie de natura şi scopul proiectului, iar cele mai multe sunt
informale, greu de structurat sub forma unor baze de date.
Totuşi, există şi componente care pot fi automatizate, aşa cum sunt cele specifice
calculelor de fezabilitate economică.
În contextul prezentat, apar o serie de instrumente software ce asigură o eficientizare a
activităţilor etapei de concepere, cum ar fi:
instrumente de căutare şi colectare a datelor: motoare de căutare, servere cu baze de
informaţii, browsere web etc.;
instrumente de comunicare între membrii echipei: e-mail, chat, grupuri de discuţii, video-
conferinţe;
instrumente pentru procesarea textelor, cu posibilitatea de control al versiunilor şi de
urmărire a modificărilor efectuate de membrii echipei proiectului (Word);
proces de
control
proces de
iniţiere
proces de
planificare
proces de
execuţie
niv
el de a
ctiv
itate
începutul
proiectului
sfârşitul
proiectului timp
proces de
încheiere
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
22
instrumente pentru calculul diferiţilor indicatori economici, pentru analizele de tip „What-
if”, pentru interpretarea statistică a datelor. Cele mai folosite instrumente sunt cele de
calcul tabelar (Excel) sau cele statistice (SPSS);
aplicaţii economice din care se pot exporta datele necesare efectuării diferitelor analize.
Vom sintetiza activităţile acestei faze în:
- Colectarea datelor
- Identificarea nevoilor
- Stabilirea obiectivelor, eficienţei şi fezabilităţii economice a proiectului, stakeholderilor,
nivelului de risc implicat, strategiei şi potenţialilor membri ai echipei de proiect
- Estimarea resurselor
- Identificarea alternativelor
- Prezentarea propunerii de proiect
- Obţinerea aprobărilor pentru faza (etapa) următoare.
Etapa 2 – Planificarea proiectului. Prin planificarea proiectului se detaliază soluţia
adoptată pentru rezolvarea problemei, se stabilesc elementele de referinţă pentru implementarea
proiectului. Volumul de informaţii gestionat în această etapă este destul de mare. Pe baza
rezultatelor etapei se asigura gestiunea şi controlul implementării proiectului, monitorizările,
evaluările şi modificările care vor conduce la finalizarea proiectului.
În etapa de planificare este necesar să se înregistreze informaţiile privind:
jaloanele sau rezultatele intermediare prevăzute pentru proiect, astfel încât să poată fi
controlat modul lor de obţinere;
activităţile în care se descompune proiectul, cu datele estimative de început şi de sfârşit, cu
dependenţele dintre activităţi/subactivităţi;
resursele necesare pentru derularea activităţilor, cele disponibile şi care trebuie atrase;
costurile pe care le presupun resursele implicate de proiect;
echipa de implementare a proiectului, rolurile şi responsabilităţile fiecărui membru;
riscurile potenţiale, efectele asupra proiectului, măsurile pentru eliminarea sau diminuarea
influenţei lor;
indicatorii prin care se monitorizează şi evaluează proiectul.
Este etapa în care cea mai mare parte a activităţilor de culegere, prelucrare şi stocare a
informaţiilor poate fi formalizată şi automatizată cu ajutorul software-ului specializat de
managementul proiectelor, putând să se apeleze la următoarele categorii:
instrumente pentru planificarea activităţilor, alocarea resurselor, cum ar fi: Microsoft
Project, Primavera, Plan View, Project Scheduler, Artemis View; Open Plan Suite etc;
instrumente de stabilire a costurilor pe proiecte: Cost Xpert, Price Estimating,
KnowledgePlan, în condiţiile în care softurile specializate de planificare şi alocare a
resurselor nu suportă astfel de posibilităţi;
instrumente specializate de analiză a riscurilor: @Risk Professional, Monte Carlo for
Primavera;
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
23
instrumente de procesare a textelor pentru descrierea ipotezelor de lucru (riscuri şi
restricţii ale proiectelor), a indicatorilor de monitorizare şi evaluare finală, precum şi
instrumente de reprezentare grafică.
Categoriile enumerate anterior vor fi folosite şi în etapele de implementare şi evaluare a
proiectelor, pentru că reprezintă baza de date de la care se porneşte în urmărirea evoluţiei
proiectului, analiza abaterilor de la planurile iniţiale, precum şi în monitorizarea activităţilor,
resurselor, costurilor, riscurilor etc.
Vom sintetiza activităţile acestei faze (etape) în:
- Numirea membrilor cheie ai echipei de proiect
- Realizarea studiilor
- Dezvoltarea schemelor cu detaliile ce stau la baza realizării scopului proiectului
- Designul Produselor/Serviciilor rezultate
- Stabilirea standardelor de calitate
- Stabilirea resurselor
- Stabilirea activităţilor
- Stabilirea Master Planului Proiectului, Bugetului, cashflowului, Structurii de lucru (Work
Breackdown Structure), Politici şi proceduri de desfăşurare a activităţilor în proiect
- Evaluarea Riscului
- Stabilirea proceselor de aprobare
Etapa 3 – Implementarea proiectului (execuţia). Cum aceasta este etapa în care se
colectează informaţiile necesare pentru analiza modului de derulare a proiectului, volumul
informaţiilor care se prelucrează este unul impresionant.
Informaţiile, de cele mai multe ori, se stochează în cadrul bazelor de date deja create la
planificarea proiectului. Dar, apar şi alte aplicaţii care solicită informaţii despre punerea în
practică a proiectului, în special aplicaţiile economice, pentru integrarea datelor din diferitele
compartimente implicate în derularea proiectelor.
Astfel, sistemul informaţional al MP trebuie să fie capabil să asigure:
colectarea datelor privind evoluţia proiectului;
efectuarea de analize planificat/realizat;
analiza variaţiei costurilor;
analiza riscurilor;
înregistrarea tuturor schimbărilor care au intervenit în planul iniţial;
generarea diferitelor rapoarte solicitate de membrii echipei sau alte persoane interesate de
proiect.
Aşa cum spuneam anterior, instrumentele informatice utilizate în planificarea proiectului
vor fi folosite şi în etapa de implementare, la care se adaugă, într-o proporţie mult mai mare,
instrumentele de comunicare.
Vom sintetiza activităţile acestei faze (etape) în:
- Stabilirea organizării şi modalităţilor de comunicare în proiect
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
24
- Motivarea echipei
- Stabilirea şi realizarea detaliilor tehnice
- Stabilirea pachetelor de activităţi, sistemelor de informare şi control
- Procurarea de bunuri şi servicii
- Executarea pachetelor de activităţi
- Monitorizarea/Controlul principalelor coordonate ale proiectului, scop, calitate, timp, cost
- Soluţionarea problemelor.
Etapa 4 – Evaluarea proiectului (controlul). Pe baza datelor culese şi stocate în etapa de
implementare, SIMP poate să ofere suficiente elemente pentru elaborarea rapoartelor finale,
sintetizând toate analizele planificat/realizat, evaluarea riscurilor, a indicatorilor de monitorizare,
pentru a fi elaborat raportul final. Sistemul informaţional trebuie să permită înregistrarea lecţiilor
învăţate, să păstreze procedurile, regulile create pentru a putea fi utilizate în proiectele viitoare.
Vom sintetiza activităţile acestei faze (etape) în:
- Finalizarea produsului/serviciului ce face obiectul proiectului
- Revizuirea şi acceptanţa
- Decontările finale
- Transferarea responsabilităţii asupra obiectului/livrabilului final al proiectului către
beneficiar
- Evaluarea proiectului
- Documentele/Raportările finale
- Eliberarea/redirecţionarea resurselor
- Reasignarea membrilor echipei de proiect.
În sinteză, în tabelul următor (Tabelul 1) sunt prezentate etapele ciclului de viaţă al
proiectului şi principalele instrumente informatice care vin în sprijinul sistemului informaţional
al MP.
Tabel 1. Etapele ciclului de viaţă al proiectelor şi instrumentele informatice
Etape
Tipuri de instrumente
Soft specializat Soft generalizat
Planifi
care
Costuri Riscuri Aplicaţii
dedicate
Procesoare
de texte
Calcul
tabelar
Comunic
are
Concepere
(iniţiere)
Planificare
Implementare
(execuţie)
Evaluare
(control)
Ca o concluzie, putem afirma că pe baza regulilor stabilite de Project Management Institute,
cele mai multe informaţii generate de o etapă a ciclului de viaţă reprezintă intrări ale celorlalte
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
25
etape, potrivit tehnicii HIPO (Hierarchical Input Processing Output), aşa cum rezultă şi din
diagrama simplificată din figura de mai jos (Fig. 8).
Fig 8. Diagrama fluxurilor de date pentru sistemul informaţional al MP
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
26
Dicţionar şi glosar de termeni Management de proiect
Deoarece informaţiile de referinţă din acest domeniu provin din limba engleză şi nu există
încă o echivalenţă oficială în română a termenilor din engleză folosiţi în project management în
România, cursul vă propune un glosar şi un dicţionar de termeni în română.
Termen în engleză Termen în
română
Explicaţii
Acceptance Criteria Criterii de
acceptanţă
Acele criterii, inclusiv cerinţele de performanţă şi alte
constrângeri, care trebuie îndeplinite înainte ca livrabilele
proiectului să fie acceptate de către client.
Baseline Plan de proiect
aprobat
În cadrul planului de proiect aprobat se urmăresc variaţiile de
costuri, efort şi durată
Business Analysist Analist Persoana care extrage, analizează, comunică şi verifică
cerinţele. Persoana care cunoaşte tehnici şi metode pentru
crearea documentelor de cerinţe.
Change Control System Sistemul de
control al
modificărilor
Un set de proceduri care definesc modul în care livrabilele şi
documentaţia proiectului sunt controlate, modificate şi
aprobate
Change Request Cerere de
modificare,
Solicitare de
modificare
Solicitarea de a mări sau reduce aria de cuprindere a
proiectului. Modificarea procedurilor, proceselor, planurilor,
costurilor, bugetelor şi duratelor.
Critical Path Drumul critic Secvenţa de activităţi care determină durata proiectului.
Deliverable Livrabile Orice componentă, rezultat sau capacitate de a presta un
serviciu care trebuie executate şi verificate în proiect.
Earned Value (EV) Valoare dobândită Valoarea efortului efectuat. Bugetul alocat pentru munca
efectuată.
Effort Efort Nu este acelaşi lucru cu durata unei activităţi. Reprezintă
valoarea rezultată din înmulţirea numărului de oameni alocaţi
pe activitatea respectivă cu durata activităţii. Se exprimă în
zile*om, luni*om, etc.
Issue Aspect, problemă,
discuţie
Un aspect asupra căruia nu s-a ajuns la o decizie şi este încă în
discuţie şi asupra căruia există puncte contradictorii.
Problema care împiedică derularea proiectului.
Matrix Organization Organizaţie de tip
matrice
Orice structură organizaţională în care project managerul şi
managerii funcţionali au responsabilitatea împărţită pentru
alocarea priorităţilor şi managementul persoanelor alocate în
proiect.
Milestone Termen Orice eveniment sau moment important în proiect (ex.
semnarea unui contract, finalizarea unei faze din proiect, etc).
PM (Project Manager ) Manager de
proiect,
coordonator de
proiect
Persoana desemnată pentru coordonarea proiectului şi
responsabilă pentru atingerea obiectivelor proiectului.
PMBOK (Project
Management Body of
PMBOK Un document care descrie metode, procese, instrumente care
îmbunătăţesc şansele de succes ale unui proiect.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
27
Termen în engleză Termen în
română
Explicaţii
Knowledge)
PMI (Project
Management Institute)
Institutul de
Management de
Proiect
Este organismul internaţional care gestionează emiterea de
standarde de project management şi oferă certificarea
internaţională PMP (Project Management Professional)
PMO (Project
Management Office)
Departament de
Coordonare
Proiecte
Un departament care se ocupă cu organizarea derulării
proiectelor, instituţionalizarea procedurilor de derulare a
proiectelor, alegerea şi implementarea metodologiilor de
proiect şi a instrumentelor software. De asemenea, poate avea
project manageri care sunt alocaţi diverselor proiecte din
organizaţii. În plus poate organiza trainning-uri interne pentru
echipele de proiect.
PMP (Project
Management
Professional)
Project Manager
Certificat
PMP reprezintă certificarea care se acordă persoanelor care au
o experienţă de cel puţin 4.500 de ore de condus proiecte, au
35 de ore de training de project management şi au demonstrat
că stăpânesc aspectele teoretice şi practice prin susţinerea
unui examen. Certificarea este acordată de către PMI (Project
Management Institute).
Project Proiect Un efort cu durata limitată efectuat cu scopul de a crea un
produs, un serviciu sau un rezultat unic.
Project Charter Document de
iniţiere proiect,
propunere de
proiect
Un document emis de iniţiatorul proiectului sau sponsor.
Acest document descrie pe scurt proiectul, desemnează
project managerul, îi conferă autoritate de a aloca resurse pe
proiect şi poate fi folosit pentru lansarea oficială a proiectului.
Project Life Cycle Ciclul de viaţă a
unui proiect
Structura, numele şi numărul fazelor unui proiect. Ciclul de
viaţă se determină în funcţie de complexitatea proiectului şi
există metodologii care specifică aceste aspecte.
Project Phase Faza de proiect,
etapa de proiect
Un set corelat de activităţi de proiect care conduc la obţinerea
unui livrabil important în proiect. Fazele de proiect pot fi
secvenţiale sau suprapuse. Mai multe faze de proiect formează
ciclul de viaţă al proiectului.
Project Scope Aria de
cuprindere,
cerintele,
specificatiile
proiectului
Efortul care trebuie efectuat pentru a livra produsul, serviciul
sau rezultatul cu specificaţiile, cerinţele stabilite de către
client.
Project Scope
Statement
Caiet de sarcini Descrierea livrabilelor, presupunerilor şi constrângerilor,
descrierea efortului necesar pentru atingerea obiectivelor
proiectului.
Requirement Cerinţă O condiţie sau capabilitate care trebuie să fie îndeplinită de un
sistem, produs, serviciu, livrabil pentru a satisface condiţiile
contractuale, un standard, specificaţii sau alte documente.
Reserve (Buffer) Rezerva de timp O rezervă în planul de proiect cu scopul de a compensa
riscurile, necunoscutele privind termenele şi/sau costurile.
RFP (Request for
Proposal)
Cerere de ofertă Un tip de document folosit pentru obţinerea ofertelor de la
furnizori, în vederea subcontractării anumitor livrabile din
proiect.
Risk Risc Un eveniment probabil care dacă apare are un impact pozitiv
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
28
Termen în engleză Termen în
română
Explicaţii
sau negativ
Rolling Wave Planning Planificare
progresivă
O metodă de planificare în care activităţile din perioada
următoare sunt planificate în detaliu iar fazele de proiect mai
îndepărtate sunt planificate în mare (cu mai puţine detalii).
Schedule Grafic de execuţie,
plan de proiect,
program, orar
Activităţile şi evenimentele importante din proiect, împreună
cu datele la care trebuie să înceapă şi să se finalizeze acestea.
Scope Aria de acoperire
a proiectului
Ansamblul produselor, serviciilor şi rezultatelor pe care
proiectul trebuie să le livreze.
Sponsor Sponsor,
finanţator, client
Persoana sau organizaţia care oferă resurse financiare sub
formă de bani sau resurse echivalente.
Stakeholder Participant din
proiect
Persoana sau organizaţia implicată activ în proiect şi a cărei
interese pot fi afectate pozitiv sau negativ de derularea
proiectului (ex. client, sponsor, manageri, etc.)
Subproject Subproiect O secţiune a unui proiect.
Team member Membru al echipei Membrul căruia i se alocă activităţi de realizat în proiect.
Template Model, sablon Informaţii prezentate într-un format predefinit (document,
formular, plan de proiect, foaie de calcul, etc), care oferă o
structură bine definită pentru colectarea, organizarea şi
prezentarea informaţiilor.
WBS (Work
Breakdown Structure)
Lista de livrabile,
Structura
ierarhică a
livrabilelor
Împărţirea pe livrabile a activităţii necesare a fi executată de
către echipa de proiect. Organizează şi defineşte aria de
cuprindere a proiectului.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
29
II. Instrumente software folosite în managementul de proiect
1. O introducere în mediul Microsoft Project
2. Definirea proiectului şi a task-urilor acestuia
3. Conceptul de legǎturǎ între douǎ activitǎţi
4. Structura ierarhicǎ a proiectului
5. Crearea legǎturilor între task-uri
6. Drumul critic al proiectului
7. Sensibilitatea unui proiect
8. Întârzieri între activitǎţi
9. Diagrama reţea
10. Resursele proiectului
11. Task-uri eveniment
12. Definirea vacanţelor şi a sǎrbǎtorilor
13. Tehnici de printare a proiectului
14. Schimbarea tipului de task folosit
15. Resurse supraalocate
16. Detaliile financiare ale resurselor
17. Generarea rapoartelor
18. Task-uri recurente
19. Sortarea, gruparea şi filtrarea informaţiilor
20. Mai multă informaţie
21. Proiecte structurate
22. Analiza progresului într-un proiect
Introducere
Chiar dacǎ nu ne dǎm seama, noi toţi aplicǎm teoria managementului în viaţa de zi cu zi.
Când ? Când ne ducem la şcoalǎ sau la muncǎ, înainte sǎ mâncǎm, când lucrǎm, şi în orice facem
în fiecare moment al vieţii noastre. Cum aşa ? De exemplu, înainte sǎ mâncǎm (unii din noi) ne
gândim ce mâncǎruri putem pregǎti sau ce mâncǎruri avem deja, şi alegem mâncarea care ne
satisface cel mai bine în funcţie de anumite criterii. Aşadar, înainte sǎ mâncǎm, ne gândim la
toate variantele de mâncǎruri, iar apoi luǎm o decizie care reprezintǎ varianta cea mai potrivitǎ
(în funcţie de cât de foame ne este, de ce orǎ este, ş.a.m.d.).
Proiecte care pot fi realizate cu Microsoft Project
Iatǎ câteva exemple de proiecte care se realizeazǎ zilnic:
Realizarea unui produs software
Publicarea unui ziar sau revistǎ
Implementarea unui program de antrenament
Pregǎtirea unei petreceri
Aşadar, cum ne poate ajuta Microsoft Project în cazul realizǎrii unui proiect ? Microsoft
Project ne ajutǎ sǎ realizǎm un plan de acţiune, ne dǎ posibilitatea introducerii şi organizǎrii
informaţiilor şi detaliilor care definesc activitǎţile ce trebuiesc terminate pentru a atinge
obiectivul propus. Microsoft Project ne ajutǎ începând cu definirea proiectului şi detaliilor
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
30
acestuia, continuând apoi cu definirea activitǎţilor şi resurselor care alcǎtuiesc proiectul,
pregǎtirea pentru publicarea acestuia, urmǎrirea progresului şi al stadiului în care se aflǎ, analiza
costurilor, a calitǎţii proiectului, ş.a.m.d.
Noţiuni de bazǎ
Să reamintim pentru început trei termeni foarte folosiţi în teoria managementului
proiectelor (pe scurt, teoria managementului), şi pe care îi vom folosi destul de des.
Task (activitate, sarcinǎ) - este o diviziune a întregii munci necesare pentru a realiza
obiectivul proiectului.
Scop - scopul oricǎrui proiect este o combinaţie a tuturor task-urilor şi a obiectivelor
acestora.
Resurse - pot fi oameni, echipamente, materiale sau servicii necesare pentru finalizarea
anumitor task-uri. Ca o observaţie, cantitatea de resurse afecteazǎ scopul şi timpul de
realizare al unui proiect.
Paşii realizǎrii şi finalizǎrii unui proiect
Înainte de a începe un proiect, trebuie sǎ ţinem cont de urmǎtorii paşi care apar în
realizarea unui proiect:
1. Conceptualizarea şi identificarea scopului proiectului
2. Definirea obiectivelor proiectului
3. Finalizarea scopului proiectului
4. Identificarea activitǎţilor proiectului
5. Asocierea la fiecare activitate a resursele necesare
6. Determinarea unei estimări a duratei şi costului proiectului
7. Identificarea factorilor ce ar putea afecta durata şi costul proiectului
8. Discutarea scenariile posibile şi întocmire unui plan de remediere.
Microsoft Project nu ne va putea ajuta cu paşii (1), (2), (7) şi (8), însǎ ne poate ajuta foarte
bine la ceilalţi paşi, uşurându-ne munca foarte mult.
1. O introducere în mediul Microsoft Project
Microsoft ® Project Professional 2010 oferă un sistem de management de proiect, cu
facilităţi puternice, vizual îmbunătăţite pentru a gestiona în mod eficient o gamă largă de proiecte
şi programe. De la respectarea termenelor, selectarea resurselor şi responsabilizarea echipelor de
proiect, Microsoft Project Professional 2010 ajută profesioniştii din domeniul managementului
de proiect prin oferirea de experienţe, mai uşor şi mai intuitiv, să fie mai productivi şi să
realizeze rezultate uimitoare.
Caracteristicile produsului Microsoft Project Proffesional 2010:
1. Familiar şi intuitiv. Panglica face mai simplă găsirea şi utilizarea instrumentelor preferate iar
cu noile meniuri grafice asigură o experienţă familiară pentru a vă ajuta să creaţi şi să
gestionaţi cu uşurinţă proiecte. În noul Microsoft Office ® Backstage ™ se pot vizualiza,
salva pur şi simplu, imprima sau publica proiectele de la o singură locaţie.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
31
2. Economie de timp şi efort. Economisiţi timp şi efort cu funcţii esenţiale cum ar fi: încadrare
de text, filtrare, auto-complete, defilare şi zoom-ul. Inserarea coloanelor noi cu privire la
tipurile de date este uşor de realizat, astfel încât aveţi posibilitatea rapid şi eficient de a
organiza şi de a analiza detaliile proiectului. Poate partaja rapid detaliile proiectului prin
operaţii de copiere şi lipire şi să păstreze formatarea elementelor între Project 2010 şi alte
aplicaţii Microsoft Office.
3. Flexibil şi puternic. Platforma vă oferă controlul şi reuneşte flexibilitatea şi uşurinţa de
utilizare a unui instrument precum Microsoft Excel ® 2010 cu puterea motorului de
planificare Project 2010. Se poate lucra cu date rezumat sau se poate trece la o abordare mai
detaliată, atunci când este convenabil.
4. Mai uşor de vizualizat. În diferite tipuri de vederi/view-uri, noi şi îmbunătăţite vizual, veţi
avea o imagine mai clară a sarcinilor, reperelor şi fazelor. Există palete, recent extins, de
culoare şi efecte de text care vă ajută să realizaţi orice cronologie şi un plan de proiect cu un
aspect mai bun; astfel puteţi să vedeţi rapid şi să partajaţi datele importante şi rezultatele.
5. Planificare uşoară. A se vedea combinaţia potrivită de oameni şi de resurse: pur şi simplu
trageţi pentru a planifica în mod eficient sarcinile de lucru pentru întreaga echipă şi de proiect.
Noul View Planificator de Echipă Project Professional 2010 prezintă resursele şi durata de
muncă de-a lungul proiectului, pentru a vă ajuta să gestionaţi la faţa locului problemele. Un
element nou în Project 2010, Inspectorul de lucru oferă o analiză suplimentară şi o orientare
intuitivă pentru a rezolva conflictele de programare derivate din atribuirea sarcinilor şi
resursele alocate.
6. Control financiar performant. Compară rapid la nivel de buget, valorile reale versus
prognozate, pentru a măsura progresul proiectului. Controlează costurilor proiectului prin
compararea bugetelor pentru activităţile terminate şi totalurile prognozate. Utilizează metrici
de valoare câştigată pentru analiză predictivă şi un management al performanţei integrat.
7. Evaluarea scenariilor. De multe ori, va trebui să evaluaţi scenarii şi opţiuni atunci când se ia
în considerare planificarea de noi proiecte sau monitorizarea lucrărilor în curs. Folosind
instrumentul Sarcini inactive, noi introdus în Project Professional 2010, puteţi experimenta cu
uşurinţă planul de proiect şi să efectuaţi analize de tipul What-If.
8. Facilităţi de colaborare. Se pot conecta echipele de proiect aflate la distanţă prin
sincronizarea cu Microsoft SharePoint ® Foundation 2010. Utilizând Project Professional
2010, aveţi posibilitatea de a sincroniza SharePoint Foundation 2010 şi Project 2010
Professional astfel încât se actualizează starea proiectului în timp real, indiferent de
localizarea şi timpul de lucru al membrilor echipei. De asemenea, se pot salva fişierele de
proiect pentru site-urile SharePoint Team Foundation 2010, pentru a comunica planurile şi a
colabora cu privire la progresul proiectului.
9. Conectare la Project Server 2010. Se poate obţine un proiect unificat şi un management de
portofoliu, prin combinarea Project Professional 2010 cu Microsoft Project Server 2010.
Împreună, Project Server Professional 2010 şi Project 2010 pot crea Microsoft Enterprise
Project Management (EPM) Solution, şi să livreze end-to-end capabilităţi pentru a ajuta
organizaţiile în implementarea proiectelor şi optimizarea resurselor, să aibă control asupra
timpului de muncă, precum şi să vizualizeze performanţa prin utilizarea tablourilor de bord.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
32
10. Creşterea performanţei. Utilizaţi opţiunile pe 64 de biţi ale Project 2010 pentru a îmbunătăţi
performanţa şi pentru a sprijini proiecte foarte mari şi programe. Project Standard 2010 şi
Project Professional 2010 sunt oferite în opţiuni 32-bit şi 64-biţi pentru a sprijini o gamă
diversă de tipuri de proiecte cu dimensiuni diferite. Opţiunea pe 64-biţi asigură extinderea
memoriei şi foloseşte capabilităţile optimizate ale celor mai recente procesoare şi versiuni pe
64 de biţi de Windows 7 şi Windows Vista. 64-bit Project Professional 2010 oferă, de
asemenea, o performanţă îmbunătăţită în gestiunea fişierelor extrem de mari şi lucrează cu
uşurinţă atunci când este conectat la Project Server 2010.
În aceastǎ fază ne vom familiariza cu mediul de lucru din Microsoft Project 2010. Dupǎ ce
deschidem Microsoft Project 2010, vom vedea următoarea interfaţă de lucru (Fig.1):
Fig. 1
În stânga ferestrei este panglica File, unde putem ori sǎ deschidem un proiect existent, ori
sǎ creem unul. În acest panou de vizualizare al proiectului în format Gantt Chart avem un
formular tabelar (aşa cum putem vedea şi în Excel) şi zona de reprezentare a diagramei Gantt,
ambele zone fiind despǎrţite printr-o barǎ mobilǎ cu care se poate stabili procentul de spaţiu
vizibil din fiecare zonǎ. Dupǎ cum puteţi vedea în panglica Gantt Chart Tools, în secţiunea
View apare butonul/pictograma Gantt Chart, fapt ce ne spune cǎ ne aflǎm în modul de
vizualizare al diagramei Gantt.
Formularul tabelar din modul de vizualizare Gantt Chart este alcǎtuit din mai multe
coloane, printre care şi Task Name unde vom introduce task-urile/sarcinile care alcǎtuiesc
proiectul, durata acestora, ş.a.m.d. Diagrama Gantt din dreapta formularului este alcǎtuitǎ şi ea
dintr-un antet care ne permite sǎ observǎm relaţiile şi durata task-urilor, subtask-urilor, şi chiar a
proiectului.
Panglica File care încorporează noua tehnologie Microsoft Office Backstage oferă
posibilitatea de a crea proiecte dezvoltate de utilizatori sau de a folosi template-uri din colecţia
Office (Fig.1).
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
33
Fig. 2
2. Definirea proiectului şi a task-urilor acestuia
Introducerea datelor
Sǎ presupunem cǎ am întocmit o schemǎ a proiectului şi a task-urilor acestuia iar acum
trebuie sǎ introducem informaţiile în Microsoft Project. Vom introduce toate datele în ordinea
apariţiei acestora în cadrul schemei în coloana Task Name astfel (Fig. 3):
Fig. 3
Pe prima linie a tabelului avem numele proiectului, în cazul acesta un Sistem Mobil de
raportare (un fel de aparat mobil - precum un telefon mobil). Fiind un proiect software,
trebuiesc întocmite cerinţele de performanţǎ a sistemului pe care se va instala (ce componente
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
34
fizice îl vor alcǎtui încât sǎ fie atât performant cât şi ieftin), însǎ pentru acest lucru trebuie sǎ
aflǎm care sisteme se folosesc cel mai mult. Pentru a afla acest lucru, trebuie sa intervievăm
utilizatorii (potenţialii cumpǎrǎtori ai acestui produs), dupǎ care putem defini cerinţele de
performanţǎ (determinǎm exact ce componente ne trebuiesc). Fiind un sistem software, trebuie
sǎ realizǎm o logicǎ a design-ului acestui software (logicǎ adicǎ planul programului încât sǎ fie
cât mai uşor şi cât mai optim de implementat), design-ul bazei de date (structura bazei de date
care va fi accesatǎ din cadrul programului), mai trebuie sǎ implementǎm codul de program A (o
bucatǎ de cod care va forma programul final) care va fi realizat de o echipǎ şi respectiv codul B
realizat de altǎ echipǎ. Pentru acest software trebuie sǎ cumpǎrǎm componentele (resursele)
hardware (adicǎ acele componente fizice care fac sistemul funcţional) necesare funcţionǎrii
acestuia, iar apoi sǎ le asamblăm. Dupǎ aceasta, pentru a obţine un prototip al proiectului, va
trebui sǎ integrăm partea software (programul) în partea hardware (aparatul).
Stabilirea datei de începere a proiectului
Acum cǎ am introdus task-urile care alcǎtuiesc proiectul, trebuie sǎ definim la fiecare task
durata desfǎşurǎrii acestuia.
Anumite task-uri sunt alcǎtuite din mai multe subtask-uri. La aceste task-uri nu se va defini
durata de desfǎşurare aceasta fiind calculatǎ automat de Microsoft Project după definirea
duratelor fiecărui subtask ce alcǎtuieşte acel task. Aşadar, la task-urile alcǎtuite din mai multe
subtask-uri se va defini durata de desfǎşurare doar a subtask-urilor!
Înainte însǎ de a defini duratele de desfǎşurare a task-urilor şi subtask-urilor, trebuie sǎ
definim perioada de început a proiectului, data când proiectul startează. Pentru acest lucru
selectǎm din panglica Project, secţiunea Properties, butonul Project Information şi va apǎrea
urmǎtoarea fereastrǎ (Fig. 4):
Fig. 4
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
35
Aici vom alege 21.10.11 ca datǎ de început a proiectului (Start date) sau orice altǎ datǎ
acesta fiind doar un exemplu.
Proiectului nu i se va da data de finalizare, aceasta fiind calculatǎ în funcţie de mai multe
criterii. Dacǎ selectam de la Schedule from din fereastra Project Information opţiunea Project
Finish Date, durata proiectului ar fi fost calculatǎ de la terminarea acestuia, iar proiectului i s-ar
fi putut defini doar data de sfârşit, însǎ nu ne intereseazǎ acest caz.
Stabilirea duratelor fiecarui task şi subtask
Dupǎ ce am setat data de începere a proiectului, putem defini durata task-urilor şi subtask-
urilor ca în imaginea urmǎtoare (Fig. 5):
Fig. 5
Durata task-urilor o aflǎm în funcţie de experienţele anterioare sau dupǎ ce vorbim cu
experţii care vor desfǎşura task-urile, ca aceştia sǎ ne estimeze durata de desfǎşurare a task-ului
respectiv.
În imaginea de mai sus am definit durata doar la task-urile care sunt simple (nu sunt alcǎtuite
din mai multe subtask-uri), cât şi la subtask-urile task-urilor pe care încǎ nu le-am evidenţiat.
Task-urile care conţin subtask-uri sunt task-uri structurate. În acest proiect avem 5 astfel de
task-uri structurate. Primul task structurat este de fapt chiar primul nivel din proiect, Sistem
mobil de raportare, iar la acesta nu definim durata (fapt pentru care apare 1day? în loc de 1day).
Acel semn de întrebare reprezintǎ faptul cǎ nu a fost specificatǎ o duratǎ pentru task-ul respectiv.
Nu este absolut necesar ca primul nivel sǎ fie un task structurat, acest lucru depinzând de
modul de organizare al proiectului.
Project poate memora durata atât în zile, cât şi în ore (la duratǎ scriem 1 h de exemplu),
minute (1m), sǎptǎmâni (1w), ş.a.m.d., însǎ sfatul este de a folosi aceeaşi mǎsurǎ de timp pentru
fiecare task şi subtask.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
36
Urmǎtoarele patru task-uri structurate sunt Cerinte de performanţǎ, Software, Hardware
şi Prototip. Evident, nici la acestea nu s-a stabilit o duratǎ, aceasta fiind calculatǎ mai încolo de
cǎtre Microsoft Project, dupǎ ce evidenţiem task-urile structurate.
Evidenţierea task-urilor structurate
Pentru a evidenţia faptul cǎ primul nivel din tabel este un task structurat, folosim panglica
Task, secţiunea Schedule, de unde alegem butonul Indent Task (fig. 6):
Fig. 6
şi îl apǎsǎm dupǎ ce selectǎm toate subtask-urile care vor aparţine task-ului structurat de pe
primul nivel ca mai jos (selecţia se face ca şi în Excel, făcând click pe al doilea task, apoi ţinând
apǎsatǎ tasta Shift şi fǎcând click pe ultimul task) (Fig. 7). Dupǎ ce apǎsǎm butonul de indentare
la dreapta va trebui sǎ obţinem semnul minus în dreptul task-ului structurat Sistem mobil de
raportare: MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
37
Fig. 7
La fel procedǎm pentru urmǎtoarele task-urile strucurate: selectǎm cele 2 subtask-uri
(urmǎtoarele 2) ale cerinţelor de performanţǎ şi le indentǎm la dreapta, la fel cu software şi
urmǎtoarele patru subtask-uri ale sale, task-ul hardware cu urmǎtoarele 2 subtask-uri ale sale, şi
task-ul prototip cu singurul subtask rămas. Rezultatul trebuie sǎ arate astfel (Fig. 8):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
38
Fig.8
Şi astfel am structurat proiectul pe 3 nivele ierarhice, şi dupǎ cum se poate vedea, Microsoft
Project a calculat automat durata task-urilor structurate în funcţie de subtask-urile acestora.
Aşa cum indentǎm (mutǎm) anumite task-uri mai la dreapta pentru a le transforma în
subtask-uri, le putem indenta şi la stânga (în caz cǎ greşim undeva sau se modificǎ structura
proiectului).
3. Conceptul de legǎturǎ între douǎ activitǎţi
Legǎturi între activitǎţile unui proiect
Sǎ presupunem cǎ avem mai multe activitǎţi ce vor fi desfǎşurate. Acestea nu se vor
desfǎşura neapǎrat simultan, ci unele dintre ele pot fi dependente de altele. Sǎ presupunem cǎ
avem un proiect de management pentru organizarea unei petreceri. Printre activitǎţile ce se vor
desfǎşura se numǎrǎ crearea unei liste cu persoanele invitate, crearea şi distribuirea invitaţiilor,
cumpǎrarea alimentelor şi sucurilor pentru petrecere, stabilirea datei şi orei de începere a
petrecerii, ş.a.m.d. Aşadar, nu putem în cazul acesta sǎ cumpǎrǎm alimentele şi sucurile pentru
invitaţi fiindcǎ nu ştim câţi invitaţi vor fi, nu putem stabili când începe petrecerea exact fiindcǎ
nu ştim cât va dura crearea invitaţiilor, distribuirea acestora, cumpǎrarea alimentelor şi sucurilor,
ş.a.m.d. Dupǎ cum observaţi, existǎ activitǎţi care sunt dependente de altele, adicǎ anumite
activitǎţi nu pot fi începute pânǎ nu se terminǎ altele.
Aici apare noţiunea de legǎturǎ între activitǎţi (sau task-uri).
Existǎ 4 tipuri de legǎturi ce pot apǎrea între 2 activitǎţi:
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
39
Legǎturǎ Cod Descriere
Finish-Start FS Predecesorul se terminǎ şi începe urmǎtorul
Start-Start SS Activitǎţile încep simultan
Finish-Finish FF Activitǎţile se terminǎ simultan
Start-Finish SF Activitatea care începe determină momentul terminării
predecesorului
Numerotarea task-urilor şi a subtask-urilor
Pentru a ataşa numere de identificare a task-urilor şi subtask-urilor alegem din panglica
Gantt Chart Tools - Format, secţiunea Show/Hide, opţiunea Outline number ca în
imaginea alǎturatǎ şi ne vor apǎrea task-urile numerotate în mod unic (Fig. 9):
Fig. 9
4. Structura ierarhicǎ a proiectului
Pentru a întocmi structura ierarhicǎ a proiectului se recomandă folosirea acelor notiţe
galbene pe care le poţi lipi pe un anumit suport. Pe fiecare notiţǎ veţi scrie subtask-urile doar,
fiindcǎ acestea se executǎ de fapt, nu task-urile strucurate. Dupǎ ce scrieţi fiecare subtask pe o
notiţǎ, puteţi sǎ lipiţi pe o coalǎ albǎ în ordinea execuţiei fiecǎrui subtask, dar începând de la
ultimul subtask pânǎ la primul, dupǎ care veţi putea trasa cu un marker sǎgeţile de legǎturǎ în
ierarhia subtask-urilor. În continuare este prezentată ierarhia proiectului nostru (Fig. 10):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
40
Fig. 10
Acum sǎ explicăm cum am ajuns la structura ierarhicǎ de mai sus. Gândind logic (de la
ultimul subtask pânǎ la primul), pentru a integra software/hardware în cazul Sistemului mobil
de raportare, trebuie să asamblăm componentele hardware, însǎ pentru aceasta e nevoie sǎ
cumpǎrǎm componentele hardware pentru a avea ce asambla. În ce priveşte integrarea software,
ne trebuie codul programului care a fost împǎrţit în douǎ module pentru câte o echipǎ de
programatori. Aşadar, pentru integrarea software ne trebuie Codul program A şi Codul program
B, însǎ codul acesta nu se poate realiza fǎrǎ o bazǎ de date, iar baza de date nu poate fi realizatǎ
fǎrǎ a gândi logica design-ului software-ului (fiindcǎ trebuie sǎ existe logicǎ în orice program
sau bazǎ de date). Dar, pentru ca toţi aceşti paşi sǎ poatǎ fi realizaţi, trebuie sǎ ştim care sunt
cerinţele de performanţǎ ale utilizatorilor, iar pentru a şti acest lucru trebuie sǎ intervievǎm
utilizatorii. Şi iatǎ structura ierarhicǎ a proiectului nostru.
5. Crearea legǎturilor între task-uri
Între activitǎţi pot exista 4 tipuri de legǎturi, care le-am enumerat mai sus, însǎ cel mai
folosit tip de legǎturǎ este cel Finish-Start, adicǎ o activitate va începe imediat ce se terminǎ o
altǎ activitate. De asemenea, foarte folositǎ este şi legǎtura Start-Start, unde douǎ activitǎţi pot
începe simultan. Celelalte douǎ legǎturi rǎmase, Start-Finish şi Finish-Finish sunt de fapt cazuri
particulare la primele douǎ. Aşadar, în proiectul nostru mutǎm bara dintre tabel şi diagrama
Gantt spre dreapta pânǎ putem vedea coloana Predecessors în tabel (Fig. 11).
Dupǎ cum putem vedea, Microsoft Project asociazǎ fiecǎrui task şi subtask un cod de
identificare în prima coloanǎ a tabelului. Aceste coduri vor putea fi folosite pentru a marca un
predecesor în coloana Predecessors. Aşadar, întorcându-ne la proiectul nostru, ştim din structura
ierarhicǎ pe care am fǎcut-o mai devreme cǎ Definirea cerinţelor de performanţǎ se poate face
abia dupǎ ce intervievǎm utilizatorii. Aşadar, pe linia subtask-ului definirea cerinţelor de
performanţǎ vom scrie în coloana predecesorilor codul liniei unde se aflǎ subtask-ul intervievare
utilizatori, adicǎ 3 în cazul nostru. Iatǎ cum va arǎta tabelul (Fig. 12):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
41
Fig. 11
Fig. 12
Observǎm de altfel cǎ imediat ce am introdus predecesorul subtask-ului de definire a
cerinţelor de performanţǎ, diagrama Gantt s-a modificat punând automat acest subtask mai la
dreapta, pentru a marca faptul cǎ definirea cerinţelor de performanţǎ se poate realiza decât dupǎ
ce intervievǎm utilizatorii. În continuare, ştim cǎ subtask-ul logica design-ului va putea fi
executat abia dupǎ ce s-au definit cerinţele de performanţǎ, aşadar predecesorul acestui subtask
va fi 4 şi vom obţine o legǎturǎ Finish-Start. Dupǎ cum putem vedea în structura ierarhicǎ
întocmitǎ mai devreme, dupǎ ce definim cerinţele de performanţǎ putem trece la subtask-ul
cumpărarea componentelor hardware, acesta având ca predecesor, evident, tot 4. Aici se
realizeazǎ prima noastrǎ legǎturǎ Start-Start, fiindcǎ logica design-ului poate fi realizatǎ în
timpul cumpǎrǎrii componentelor hardware. Mai departe, subtask-ul design-ul bazei de date
poate fi realizat dupǎ ce se întocmeşte logica design-ului, aşadar predecesorul pentru acest
subtask este 6. Dupǎ ce se realizeaza design-ul bazei de date, se poate trece la crearea codului de
program. Acesta însǎ este împǎrţit pe douǎ echipe, minimizând astfel durata creǎrii codului de
program. Aşadar, Codul program A se va realiza în acelaşi timp cu Codul program B, ambele
având acelaşi predecesor 7. Asamblarea hardware se va realiza dupǎ ce se vor cumpǎra
componentele hardware, deci va avea ca predecesor 11. Şi în cele din urmǎ, integrarea
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
42
software/hardware se va putea realiza abia dupǎ ce se asambleazǎ hardware-ul şi dupǎ ce se
creazǎ codul program. Aşadar, aici vom avea 3 predecesori, 12, 8, şi 9 pe care îi vom scrie
separaţi prin “;”. Iatǎ cum va arǎta tabelul final şi diagrama Gantt (Fig. 13):
Fig. 13
Observaţie: Dacă veţi constata că sistemul nu a calculat automat data finală a proiectului
(coloana Finish) va trebui să activaţi din panglica Gantt Chart Tools – Task, secţiunea Tasks,
butonul Auto Schedule, care va actualiza automat duratele de desfăşurare a task-urilor.
Dupǎ ce am determinat şi introdus predecesorii subtask-urilor, şi dupǎ ce am obţinut
diagrama Gantt, putem vedea şi durata de desfǎşurare a proiectului în prima linie din tabel, în
cazul nostru fiind 16 zile (21.10.2011 – 11.11.2011). Bineînţeles, aceastǎ duratǎ ar putea fi
afectatǎ de mai mulţi factori, printre care lipsa de resurse, întârzieri apǎrute pe parcursul
desfǎşurǎrii subtask-urilor, ş.a.m.d.
Barele negre din diagrama Gantt reprezintǎ durata task-urilor structurate, iar benzile
albastre sunt subtask-urile. În acest mod putem vedea zilele sau lunile în care încep/se termină
anumite activitǎţi.
6. Drumul critic al proiectului
Drumul critic dintr-un proiect este alcǎtuit din toate activitǎţile care nu pot avea întârzieri,
iar orice întârziere care ar apǎrea în aceste activitǎţi ar duce la prelungirea termenului de
finalizare al proiectului. Microsoft Project poate sǎ determine care sunt aceste activitǎţi care
formeazǎ drumul critic. Pentru aceasta, selectǎm din panglica Gantt Chart Tools – Format,
secţiunea Bar Styles, opţiunea Critical Tasks care va determina drumul critic al proiectului (Fig.
14).
(Fig. 14):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
43
Iatǎ cum va arǎta diagrama Gantt (Fig. 15):
Fig. 15
Aşadar, putem trage de aici concluzia cǎ pot apǎrea întârzieri în realizarea Codului
program B, în cumpǎrarea componentelor hardware şi în asamblarea hardware fǎrǎ a
afecta în vreun fel durata proiectului, însǎ, dacǎ una din aceste activitǎţi durează mai mult decât
este disponibil, se va afecta durata proiectului (despre acest caz vom discuta ulterior). Restul
activitǎţilor sunt critice şi orice întârziere care ar apǎrea în desfǎşurarea acestora poate afecta
durata desfǎşurǎrii proiectului (poate decât sǎ se prelungeascǎ, fiindcǎ durata calculatǎ de
Microsoft Project pentru proiectul nostru este cea minimǎ).
7. Sensibilitatea unui proiect
Una din marile probleme ale managementului unui proiect este sensibilitatea unui proiect,
adicǎ probabilitatea ca drumul critic al proiectului sǎ se schimbe, sau cu alte cuvinte,
probabilitatea ca proiectul sǎ dureze mai mult decât a fost plǎnuit. Pentru a determina
sensibilitatea unui proiect, trebuie sǎ ne punem o întrebare: avem mai mult de un singur drum
critic în proiect ? Dacǎ avem mai mult de un drum critic, creşte posibilitatea ca dacǎ unul din
drumuri dureazǎ mai mult, celelalte sǎ devinǎ non-critice. În cadrul proiectului nostru putem
vedea cǎ existǎ un singur drum critic dominant, aşadar avem de-a face cu o sensibilitate scǎzutǎ.
Apoi mai trebuie sǎ ne punem o întrebare: cum rǎmâne cu activitǎţile non-critice ? Care e
probabilitatea ca dacǎ acestea ar dura mai mult sau ar începe mai târziu decât a fost plǎnuit sǎ
devinǎ critice ? Pentru a rǎspunde la aceastǎ întrebare trebuie sǎ aflǎm care este rezerva de timp
(timp extra) care acestea o au la dispoziţie pentru a se desfǎşura. Acest lucru îl aflǎm folosind
instrumentele Microsoft Project 2010.
Vom activa din panglica Gantt Chart Tools – Format, secţiunea Bar Styles, opţiunea
Slack, care va afişa în grafic rezervele de timp disponibile, dar mult mai interesant, pentru
aceasta analiză este să customizăm diagrama Gantt pentru a afişa indicatorii specifici. În tabel
adăugăm cu opţiunea Insert Column, următoarele coloane: Late Start, Late Finish, Free Slack,
Total Slack (Fig. 16):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
44
Fig. 16
Coloanele care ne intereseazǎ sunt Free Slack şi Total Slack. Se observǎ cǎ toate task-urile
critice (adicǎ cele care formeazǎ drumul critic) au valoarea 0 în aceste coloane. Coloana Free
Slack reprezintǎ cu cât poate fi întârziat un task fǎrǎ a întârzia task-urile succesoare (care depind
de acesta) iar Total Slack reprezintǎ cu cât poate fi întârziat un task fǎrǎ a întârzia proiectul.
Aşadar, putem demonstra cǎ acest proiect nu este foarte sensibil (adicǎ sunt mici şansele ca
drumul critic sǎ se schimbe) luând urmǎtoarele cazuri particulare (Fig.17):
• Codul program B (9) este estimat a dura 3 zile, şi putem vedea cǎ poate avea o
întârziere de 2 zile, adicǎ mai mult de 60%.
• Asamblarea hardware (12) este estimatǎ a dura o zi, şi poate întârzia 7 zile!
Fig. 17
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
45
8. Întârzieri între activitǎţi
Un alt caz posibil este apariţia (sau impunerea) unei întârzieri între douǎ activitǎţi
consecutive (Finish-Start). Sǎ presupunem cǎ poate apǎrea o întârziere între cumpǎrarea
componentelor hardware (11) şi asamblarea hardware (12). Pentru a realiza acest lucru în
Microsoft Project, facem dublu click pe numele task-ului care va avea întârziere (în cazul nostru
succesorul, fiindcǎ avem legǎturǎ Finish-Start), adicǎ pe asamblare hardware, şi vom vedea
urmǎtoarea fereastrǎ (Fig. 18):
Fig. 18
O altă variantă pentru a activa caseta Task Information este să folosiţi panglica Gantt
Chart Tools – Task, secţiunea Properties, butonul Information.
Putem vedea (pagina Predecessors) în cǎsuţa din colţul din stânga al ferestrei numele task-
ului (Asamblare hardware), durata mai la dreapta (1 zi), iar sub aceste cǎsuţe putem vedea lista
activitǎţilor de care depinde (predecesorii), în acest caz cumpararea componentelor hardware.
În aceastǎ listǎ vom selecta coloana Lag şi vom introduce durata întârzierii dintre aceste douǎ
activitǎţi, adicǎ 3d (3 zile). De asemenea, în aceastǎ listǎ putem modifica şi tipul legǎturii dintre
activitǎţi în coloana Type selectând unul din cele patru tipuri puse la dispoziţie. Apǎsǎm OK şi
vom vedea în diagrama Gantt cum subtask-ul asamblare hardware s-a mutat mai la dreapta cu
3 zile (Fig. 19).
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
46
Fig. 19
9. Diagrama reţea
Vom putea vedea cum Microsoft Project poate genera structura ierarhicǎ pe care am
creat-o noi mai devreme, adică Diagrama Reţea cu legăturile dintre activităţi. Pentru a face acest
lucru, în panglica Task, secţiunea View, selectǎm Network Diagram şi vom vedea urmǎtoarea
imagine (Fig. 20):
Fig. 20
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
47
Putem vedea acum o parte din schema ierarhicǎ fǎcutǎ de noi, doar cǎ aici fiecare “notiţǎ”
conţine şi detaliile activitǎţii respective. Pentru a vedea toate activitǎţile, putem derula zona de
vizualizare cu sǎgeţile de pe marginea ferestrei. Bineînţeles, şi aici cǎsuţele roşii reprezintǎ
drumul critic, iar cele albastre drumul non-critic. Pentru a vedea întreaga reţea, alegem din
panglica Network Diagram Tools – View, secţiunea Zoom, butonul Zoom. Rezultatul este
prezentat în Fig.21:
Fig. 21
Putem vedea în stânga cǎsuţele care nu au legǎturi între ele, acestea fiind task-urile
structurate, iar cele cu legǎturi între ele sunt, evident, subtask-rile. Evident, nu putem înţelege
mare lucru fiindcǎ Microsoft Project a micşorat foarte mult cǎsuţele datǎ fiind mǎrimea structurii.
Existǎ însǎ o şmecherie: punând cursorul mouse-ului deasupra unei cǎsuţe, acea cǎsuţǎ se va
mǎri pentru a putea vedea detaliile (ca mai jos), iar dupǎ ce mutǎm cursorul mouse-ului în altǎ
parte acea cǎsuţǎ se va micşora înapoi.
Sǎ zicem cǎ nu avem nevoie de cǎsuţele care reprezintǎ task-urile structurate. Pentru a
scǎpa de ele, alegem panglica Network Diagram Tools – Format, secţiunea Show/Hide,
debifǎm opţiunea Summary task. Vom vedea cǎ toate cǎsuţele din stânga care nu aveau legǎturi
între ele dispar din diagrama reţea (Fig. 22).
Fig. 22
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
48
Un alt lucru pe care l-am mai dori este sǎ putem muta cǎsuţele cum vrem noi. Dacǎ
încercǎm acest lucru, vom vedea cǎ în loc sǎ se mişte, apare o nouǎ cǎsuţǎ, fiindcǎ Microsoft
Project considerǎ cǎ am vrut sǎ creem un subtask nou dependent de acela.
Dacǎ facem o greşealǎ, sau se întâmplǎ ceva neprevǎzut în cadrul proiectului dintr-o
manevrǎ greşitǎ, putem corecta apǎsând Ctrl+Z (Undo) din bara de acces rapid a aplicaţiei.
Pentru a permite mutarea cǎsuţelor, folosim panglica Network Diagram Tools – Format,
secţiunea Layout. În fereastra care ne apare, sus avem douǎ opţiuni, Automatically position all
boxes (poziţioneazǎ automat toate cǎsuţele) şi Allow manual box positioning (permite
poziţionarea manualǎ a cǎsuţelor). Vom bifa a doua opţiune. Acum poziţionǎm mouse-ul pe
marginea unei cǎsuţe (va trebui sǎ se schimbe cursorul mouse-ului într-un fel de sǎgeţi negre),
dupǎ care putem muta cǎsuţa.
Un alt lucru care s-ar putea sǎ nu ne placǎ sunt sǎgeţile de legǎturǎ între cǎsuţe, fiindcǎ se
suprapun. Pentru a schimba acest lucru, în fereastra Layout bifǎm opţiunea Straight. Acum vom
vedea diagrama exact cum trebuie: cu legǎturile nesuprapuse, exact ca în structura ierarhicǎ pe
care am fǎcut-o şi noi (Fig. 23).
Fig. 23
10. Resursele proiectului
Tipuri de resurse
Odatǎ ce avem nevoie sǎ includem resurse în cadrul proiectului, trebuie sǎ rǎspundem la
urmǎtoarele întrebǎri:
De ce tipuri de resurse avem nevoie ?
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
49
De câte resurse avem nevoie ?
De unde putem lua aceste resurse ?
Cum determinăm costul proiectului ?
Resursele sunt de douǎ tipuri:
Resurse de muncǎ - acestea terminǎ activitǎţile în decursul timpului. De obicei aici intrǎ
oamenii şi echipamentele.
Resurse materiale - acestea sunt stocuri şi costuri de care este nevoie pentru a termina
proiectul.
În Microsoft Project, ca şi în realitate, oamenilor care alcǎtuiesc resursele de muncǎ li se
pot atribui un program corespunzǎtor cu ore libere sau vacanţe. De asemenea, Microsoft Project
poate determina resursele suprasolicitate (cele cǎrora li s-au atribuit prea multe activitǎţi, sau
prea puţin timp de desfǎşurare).
Crearea stocului de resurse
Stocul de resurse reprezintǎ totalitatea resurselor disponibile care pot fi alocate unei
activitǎţi. Pentru a edita stocul de resurse, vom selecta din panglica View, secțiunea Resource
Views, opţiunea Resource Sheet şi vom vedea urmǎtorul tabel (Fig. 24):
Fig. 24
Vom încerca sǎ menţinem lucrurile cât mai simple, aşadar, în acest tabel, pe coloana
Resource Name vom introduce 2 resurse: Inginer de design şi Inginer Software.
Pentru a seta moneda națională în care vom exprima salariile angajaților folosim panglica
File – Option și din secțiunea Display introducem datele corespunzătoare la rubricile Symbol,
respectiv Currency (Fig. 25).
Tabelul nostru va trebui sǎ arate astfel (Fig. 26):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
50
Fig. 26
Aşa cum se poate vedea în Fig. 26, Microsoft Project mǎsoarǎ o resursǎ în procente (vezi
coloana Max. Units).
Ca o interpretare în tabelul nostru de resurse, putem spune, de exemplu, cǎ un singur
inginer de design îşi poate aloca activitǎţilor asociate 100% din timpul sǎu. Dacǎ am fi dorit sǎ
avem 3 ingineri de design, am fi introdus la coloana Max. Units valoarea 300%. Dacǎ, de
exemplu, avem 2 ingineri software din care unul lucreazǎ part-time (cu jumǎtate de normǎ),
atunci am introduce valoarea 150% în coloana Max. Units.
De asemenea, putem atribui fiecǎrei resurse o iniţialǎ pentru o identificare mai uşoarǎ
introducând în coloana Initials iniţiala doritǎ, ca în Fig. 27:
Fig. 27
În cadrul proiectului nostru, dacǎ avem 3 ingineri de design, aceştia pot executa aceleaşi
activitǎţi în acelaşi timp, aşadar nu îi putem diferenţia. Pentru a-i putea diferenţia, putem
introduce în loc de inginer de design numele unuia din ei, şi pentru ceilalţi la fel, vom introduce
câte un nume pentru fiecare în cadrul coloanei Resource name. Aşadar, sǎ zicem cǎ mai
adaugǎm 2 resurse în proiectul nostru, Ionescu şi Teodor şi vom obţine (Fig. 28):
Fig. 28
Astfel putem specifica ce resursǎ lucreazǎ part-time şi ce resursǎ lucreazǎ full-time. În
cazul nostru, Teodor lucreazǎ part-time, iar Ionescu full-time. Dupǎ cum puteţi vedea în coloana
Group am asociat un grup fiecǎruia, ID de la Inginer de Design. Aşadar îi putem identifica o
resursǎ şi dupǎ grupul din care face parte, nu numai dupǎ iniţiale sau nume.
Acum însǎ, pentru proiectul nostru vom şterge ultimele 2 resurse, şi le vom lǎsa doar pe
primele. Cum putem şterge o resursǎ ? Facem click dreapta pe numǎrul unic asociat acesteia
(valoarea din prima coloanǎ a tabelului) şi selectǎm Delete Resource (Fig. 29).
Stocul nostru de resurse va trebui sǎ arate astfel (Fig. 30).
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
51
În concluzie, am ales 3 ingineri de design fiecare fiind plǎtit cu 50 lei/orǎ iar orele extra se
vor plǎti cu 1,5 lei/orǎ. Mai avem 3 ingineri software care sunt plǎtiţi cu 100 lei/orǎ, fǎrǎ
bonusuri pentru orele extra.
Fig. 30
Alocarea resurselor pentru fiecare activitate
Acum ne vom întoarce la modul de vizualizare al
diagramei Gantt alegând din panglica View
butonul Gantt Chart. Vom selecta primul subtask
(intervievare utilizatori) cǎruia îi vom atribui o
resursǎ şi vom selecta în Resource butonul care
are ca imagine doi oameni - Assign Resources
(Fig. 31).
Dacǎ nu găsiţi acel buton, puteţi folosi
combinația de taste Alt+F10 (Fig. 32):
Fig. 31
Fig. 32
Avem aici lista resurselor disponibile alcǎtuitǎ din coloana cu numele resurselor, şi coloana
Units unde vom introduce numǎrul de resurse alocate subtask-ului ales de noi. În cazul nostru,
vom asocia 2 ingineri de design pentru a intervieva utilizatorii, aşadar scriem în coloana Units
valoarea 200% (sau mai simplu, 200). Dupǎ aceasta apǎsǎm butonul Assign. Dacǎ se întâmplǎ
sǎ greşiţi sau sǎ nu mai vreţi sǎ fie alocatǎ o resursǎ unui subtask, puteţi selecta în aceastǎ
fereastrǎ resursa pe care vreţi sǎ o retrageţi şi apăsaţi butonul Remove.
Acum, cu aceastǎ fereastrǎ încǎ deschisǎ, facem click în tabelul de task-uri pe urmǎtorul
subtask cǎruia îi vom aloca o resursǎ, în cazul nostru Definirea cerinţelor de performanţǎ.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
52
Dupǎ cum putem vedea din lista de resurse a fereastrei de mai sus a dispǎrut valoarea unitǎţilor
de resurse alocate de noi mai devreme. De ce ? Fiindcǎ ne-am mutat la un alt subtask care nu are
nici o resursǎ asociatǎ. Dacǎ facem înapoi click pe subtask-ul intervievare utilizatori, vom vedea
cǎ apare din nou valoarea 200 la inginer de design. Revenind la subtask-ul Definirea cerinţelor
de performanţǎ, acestuia îi vom da 3 ingineri de design (adicǎ toţi, fiindcǎ doar trei avem în
stocul de resurse). Mai departe vom aloca subtask-urilor urmǎtoarele resurse:
Logica design-ului 300% Inginer de design
Design-ul Bazei de date 200% Inginer de design,
200% Inginer software
Codul program A 200% Inginer software
Codul program B 200% Inginer software
Cumpǎrǎ componentele
hardware
100% Inginer de design
Asamblare hardware 200% Inginer de design
Integrare Sw/Hw 200% Inginer de design
Acum putem închide fereastra de alocare a resurselor apǎsând butonul Close. Revenim la
modul de vizualizare al diagramei Gantt (panglica View butonul Gantt Chart), inserăm două
coloane Resource Names și Duration, iatǎ care va fi rezultatul (Fig. 33):
Fig. 33
Putem vedea în ultima coloanǎ (Resource Names) numele resurselor alocate fiecǎrui
subtask cât şi unitǎţile alocate din fiecare resursǎ. Se poate observa la subtask-ul cumpără
componente hardware cǎ nu apare numǎrul de unitǎţi alocate din resursa respectivǎ. Acest
lucru se întâmplǎ fiindcǎ am alocat decât un singur inginer de design (100%) acestui subtask.
Acum sǎ presupunem cǎ mai e nevoie de încǎ 2 ingineri de software la ultimul subtask de
integrare software/hardware, aşadar facem click pe butonul de alocare a resurselor şi
introducem 200 la resursa inginer software. Iatǎ rezultatul (Fig. 34):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
53
Fig. 34
Trebuie observat cǎ durata ultimului subtask acum a scǎzut de la o zi la o jumǎtate de zi (în
funcție de cum este configurat Microsoft Project). De asemenea, se poate observa cǎ dupǎ ce
alocǎm resurse anumitor subtask-uri, şi durata de desfǎşurare a proiectului scade, lucru normal
de altfel, fiindcǎ am alocat destule resurse încât sǎ scurtǎm durata proiectului. Una e când o
activitate este realizatǎ de o persoanǎ, şi alta e când este realizatǎ de mai multe persoane. Însǎ
acest lucru nu este mereu valabil, chiar dacǎ Microsoft Project aşa presupune! Dacǎ ştim cǎ
durata unui task va rǎmâne aceeaşi indiferent de câte resurse îi alocǎm, putem sǎ modificǎm în
tabel durata task-ului ignorând calculele fǎcute de Microsoft Project. În cazul nostru vom scrie în
loc de 0,5 days, 1d. Aşadar, trebuie sǎ aveţi mereu grijǎ de douǎ aspecte când alocaţi resurse
anumitor activitǎţi:
durata activitǎţilor sǎ fie corectǎ
unitǎţile de resurse alocate sǎ fie corect introduse
Dacă duratele task-urilor şi a subtask-urilor s-au modificat în proiectul nostru şi vrem sǎ nu
se modifice, schimbăm acum duratele task-urilor corespunzător imaginii din Fig.34 (proiectul va
avea o durată totală de 16 zile lucrătoare).
11. Task-uri eveniment
Ce este un task eveniment? Este un subtask care are ca duratǎ de timp valoarea 0, şi care
marcheazǎ finalizarea unui task. Acest task eveniment este reprezentat cu un romb în diagrama
Gantt, şi poate fi legat de alte task-uri sau subtask-uri aşa cum legǎm şi activitǎţile între ele.
În proiectul nostru, de exemplu, un astfel de task eveniment este terminarea subtask-ului
definirea cerinţelor de performanţǎ. Pentru a introduce un astfel de task eveniment în
proiectul nostru, selectǎm celula care urmeazǎ dupǎ subtask-ul care finalizeazǎ task-ul structurat.
În cazul nostru, task-ul eveniment va fi introdus dupǎ subtask-ul definirea cerinţelor de
performanţǎ, fiindcǎ la finalizarea acestui subtask se finalizeazǎ şi task-ul structurat Cerinţe de
performanţǎ. Aşadar, pentru a putea introduce task-ul eveniment, selectǎm celula care urmeazǎ
dupǎ definirea cerinţelor de performanţǎ, în cazul nostru aceastǎ celulǎ fiind task-ul structurat
Software, şi ori folosim meniul contextual cu opțiunea Insert Task, ori din panglica Task,
secțiunea Insert alegem butonul Milestone. Iatǎ cum va arǎta figura (Fig. 35):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
54
Fig. 35
În celula nou introdusǎ vom scrie la numele task-ului Finalizare cerinţe de performanţǎ,
iar în coloana de duratǎ a task-ului vom scrie 0 iar la coloana Start vom selecta data de începere
a proiectului (cea de pe primul nivel). Rezultatul va trebui sǎ arate astfel (Fig. 36):
Fig. 36
Dupǎ cum puteţi vedea în diagrama Gantt, a apǎrut rombul care reprezintǎ task-ul
eveniment tocmai creat care încǎ nu este legat de nici o activitate. Cum legǎm acest task
eveniment de ultimul subtask care finalizeazǎ task-ul structurat Cerinţe de performanţǎ? Ştim
cǎ, fiind un eveniment, trebuie sǎ aparǎ dupǎ ce se finalizeazǎ ultimul subtask (definirea
cerinţelor de performanţǎ), aşadar predecesorul task-ului eveniment va fi 4. Iatǎ cum va arǎta
diagrama Gantt dupǎ crearea legǎturii (Fig. 37):
Fig. 37
De asemenea, subtask-urile care erau înainte legate de predecesorul 4 acum vor fi legate de
5 (adicǎ de task-ul eveniment) ca în imaginea din Fig. 38:
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
55
Fig. 38
12. Definirea vacanţelor şi a sǎrbǎtorilor
Evident, ca şi în viaţa realǎ, trebuie sǎ asociem resurselor de muncǎ (oamenii) anumite zile
în care vor fi liberi (zile de sǎrbǎtori, de vacanţǎ, etc). Pentru a face acest lucru, selectǎm din
panglica Project butonul Change Working Time şi vom vedea urmǎtoarea fereastrǎ (Fig. 39):
Fig. 39
Putem vedea o listǎ ascunsǎ sus în fereastrǎ unde este selectat implicit calendarul standard
de proiect, în care se presupune cǎ oamenii lucreazǎ de luni pânǎ vineri, de la 8:00 dimineaţa
pânǎ la 12:00 dupǎ-amiaza, şi de la 13:00 pânǎ la 17:00 seara. Aşadar, sǎ luǎm un exemplu de zi
liberǎ în care se presupune cǎ nu se va lucra: 1 Noiembrie - zi liberă. Apǎsǎm pe sǎgețile de
derulare din bara de derulare a calendarului pentru a ne muta în calendar la ziua de 1 Noiembrie,
selectǎm ziua de 1, iar în dreapta ferestrei folosim butonul Details, opțiunea Nonworking time
precizând astfel lui Microsoft Project cǎ de 1 Noiembrie nu se va lucra în cadrul proiectului
nostru (Fig. 40):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
56
Fig. 40
Trebuie reţinut cǎ aceste modificǎri în cadrul calendarului nu vor fi aceleaşi în fiecare an,
aşadar, dacǎ doriţi sǎ daţi liber de Crǎciun în fiecare an, va trebui sǎ derulezi în jos calendarul şi
sǎ specificaţi că va fi liber în fiecare Decembrie a urmǎtorilor ani fǎcând modificǎrile anterioare.
Puteţi modifica pânǎ şi intervalul de ore în care se va lucra în anumite zile, editând pur şi
simplu orele din dreapta ferestrei. La fel puteţi seta ca anumite sâmbete sǎ se lucreze, ş.a.m.d.
De asemeni, puteţi selecta mai multe zile ţinând apǎsatǎ tasta Shift.
După customizarea calendarului de lucru vom observa că proiectul nostru se va derula tot
în 16 zile lucrătoare, dar din punct de vedere calendaristic proiectul va începe pe data de
21.10.2011 și se va termina pe 14.11.2011 (perioada calendaristică se prelungește datorită
introducerii unei zile nelucrătoare).
13. Tehnici de printare a proiectului
Printarea diagramei reţea
Microsoft Project are tendinţa sǎ printeze mai multe pagini decât este nevoie, aşa cǎ vom
prezenta cum sǎ printeţi mai eficient şi mai pe înţelesul tuturor. De exemplu, sǎ zicem cǎ vreţi sǎ
printaţi diagrama reţea a proiectului (cea micşoratǎ de noi cu cǎsuţele acelea care le fǎcusem sǎ
le putem mişca). Selectǎm aşadar din panglica View butonul Network Diagram dupǎ care vom
selecta din panglica File opţiunea Print pentru a vedea câte pagini vor fi printate din diagrama
noastrǎ. Ne va apǎrea urmǎtoarea fereastrǎ (Fig. 41):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
57
Fig. 41
Dupǎ cum observǎm din bara de stare (cea din josul ferestrei), ce vedem noi este prima
paginǎ dintr-un total de 3 pagini care vor fi printate. Nu ne convine, aşa cǎ apǎsǎm pe butonul
Page Setup, şi ne va apǎrea fereastra de setǎri ale paginii unde în campul Adjust to vom alege
55% pentru a micşora totul dupǎ care apǎsǎm butonul Print Preview şi iatǎ rezultatul (Fig. 42):
Fig. 42
Acum ne-au rǎmas decât douǎ pagini, una cu diagrama reţea, iar cealaltǎ cu legenda. În loc
sǎ fi modificat acea valoare, puteam mult mai simplu sǎ bifǎm a doua opţiune din fereastra Page
Setup, adicǎ opţiunea Fit to, unde lǎsam valorile implicite (1 şi 1), şi am fi obţinut o încadrare
perfectǎ într-o paginǎ a diagramei. Aşadar, metoda a doua este cea mai potrivitǎ pentru încadrare
perfectǎ în paginǎ.
Printarea diagramei Gantt şi/sau a tabelului de task-uri
Pentru a printa atât tabelul de task-uri cât şi diagrama Gantt, vom selecta opțiunea Print
din panglica File şi vom vedea rezultatul printǎrii într-o altǎ fereastrǎ. Dacǎ însǎ dorim sǎ
printǎm decât tabelul de task-uri, vom trage bara despǎrţitoare dintre tabel şi diagrama la dreapta
exact pânǎ în bara de derulare verticalǎ pentru a nu mai vedea deloc diagrama Gantt, dupǎ care
vom alege din nou opțiunea Print şi vom vedea cǎ în fereastra cu rezultatul printǎrii se aflǎ doar
tabelul de task-uri. Dacǎ vrem însǎ sǎ printǎm diagrama Gantt şi task-urile proiectului, tragem
acea barǎ despǎrţitoare exact la capǎtul drept al coloanei Task Name, iar în fereastra Print
Preview vom obţine exact ce am dorit. Dar, tot mai e o micǎ problemǎ: legenda ne apare pe o
altǎ paginǎ, iar noi dorim ca legenda sǎ aparǎ pe aceeaşi paginǎ cu diagrama. Pentru a face acest
lucru, apǎsǎm butonul Page Setup din fereastra Print, alegem eticheta Legend din partea de sus
a ferestrei, şi vom bifa opţiunea Every page din secţiunea Legend on a ferestrei. Dacǎ dǎm Ok,
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
58
vom vedea cǎ acum legenda apare pe aceeaşi paginǎ cu diagrama, şi totul este doar pe o singurǎ
paginǎ, aşadar am fǎcut atât economie de foaie, cât şi de toner (Fig. 43).
Fig. 43
Setarea antetului şi a subsolului unei pagini
Cel mai indicat este ca orice paginǎ printatǎ sǎ aibǎ un text de antet şi subsol. Pentru a seta
aceste texte, folosim panglica File, opțiunea Print, butonul Page Setup, iar în partea de sus a
ferestrei care apare vom vedea nişte etichete (mai multe butoane alǎturate) ca în imaginea din Fig.
44:
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
59
Fig. 44
Vom selecta eticheta Header pentru a seta antetul, iar al doilea câmp de text putem
introduce textul care va apǎrea în fiecare antet al paginilor printate. Mai mult de atât, putem seta
textul din mijlocul antetului selectând eticheta Center, apoi selectând eticheta Left vom putea
seta textul din stânga antetului, şi la fel putem seta şi în dreapta antetului. De exemplu, am putea
scrie în stânga antetului numǎrul de paginǎ (selectând eticheta Left dupǎ care apăsaţi butonul
Add din dreptul listei ascunse cu Page Number), în mijlocul antetului putem scrie numele
proiectului (selectând eticheta Center şi scriind numele proiectului în câmpul de editare), iar în
dreapta putem afișa ora curentă. Iatǎ cum va arǎta fereastra dupǎ ce vom face aceste setări (Fig.
45):
Fig. 45
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
60
Vom proceda în acelaşi mod pentru setarea textului din subsolul paginii, doar cǎ va trebui
sǎ selectǎm eticheta Footer. Imaginea următoare avem butonul Print Preview care ne va arǎta
pagina întreagǎ dupǎ printare (Fig. 46).
Fig. 46
14. Schimbarea tipului de task folosit
Microsoft Project oferǎ trei tipuri de task-uri cu care poate calcula mai exact durata
proiectului în funcţie de resursele asociate. Aceste trei tipuri sunt:
• Unitǎţi fixe (Fixed Units) • Muncǎ fixǎ (Fixed Work) • Duratǎ fixǎ (Fixed Duration) Formula utilizată de MS Project pentru a determina
durata, resursele şi efortul este:
Pentru primul tip de task Microsoft Project va recalcula munca şi durata de fiecare datǎ
când este necesar, însǎ unitǎţile de muncǎ vor rǎmâne fixe. Asemǎnǎtor, în task-urile cu duratǎ
fixǎ, dacǎ unitǎţile sunt schimbate, munca va fi recalculatǎ corespunzǎtor.
Tipul implicit de task este cel cu unitǎţi fixe. Spre exemplu, dacă dublăm numărul de
unităţi de resurse asignate pentru un task, MS Project poate echilibra ecuaţia în două variante:
• împarte Durata la 2;
• creşte Munca de 2 ori.
Dacă aplicaţia e setată la Durată fixă atunci e modificată Munca, dacă e setată la Muncă
fixă, atunci e recalculată Durata.
Durată x Unităţi = Muncă
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
61
Exemple: Durată fixă (termenul de 25 a lunii următoare, stabilit prin lege, pentru raportări
privind contribuţiile salariale ale angajatorilor); Muncă fixă (cel mai des întâlnit tip de task-
producerea unui document: carte de vizită, invitaţie); Unităţi fixe (mai rar întâlnit acest tip de
task - activităţi de supervizare a altor activităţi cum ar fi 10% din timpul alocat unei activităţi pe
toată durata ei).
Pentru a schimba tipul de task folosit într-un proiect, selectǎm Options din panglica File,
iar în fereastra Project Options ce va apǎrea vom selecta eticheta Schedule. În listǎ ascunsǎ
(Default task type) vom selecta tipul de task ce va fi folosit în proiect (Fig. 47).
Fig. 47
15. Resurse supraalocate
Moduri de determinare a resurselor supraalocate
Dupǎ ce alocǎm resurse unui proiect, este bine sǎ verificǎm dacǎ existǎ anumite resurse
supraalocate. Ce înseamnǎ cǎ o resursǎ este supraalocatǎ ? Înseamnǎ cǎ acesteia i s-a atribuit mai
multǎ muncǎ decât poate executa, a fost atribuitǎ la prea multe activitǎţi, ş.a.m.d.
Pentru a vedea care resurse sunt supraalocate, vom selecta Resource Sheet din panglica View
pentru a vedea stocul de resurse. Iatǎ care va fi rezultatul în cazul proiectului nostru (Fig.
48):
Fig. 48 Ambele tipuri de resurse sunt marcate cu roşu spunându-ne astfel cǎ aceste resurse sunt
supraalocate. Pentru a afla mai multe detalii, vom alege Other views - Resource Graph din
panglica View şi iatǎ ce vom vedea (Fig. 49):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
62
Fig. 49
Aici putem vedea pentru fiecare tip de resursǎ când este supraalocatǎ. În imaginea de mai
sus putem observa cǎ între 21 octombrie 2011 şi 27 octombrie 2011 este nevoie decât de 2
ingineri de design, pe 28 octombrie 2011 și 2 noiembrie 2011 e nevoie de 3 ingineri, de
asemenea, pe intervalul 3 - 14 noiembrie 2011 este nevoie de 2 ingineri de design. Însǎ pe 31
octombrie 2011 este nevoie de încǎ un inginer de design (în total 4), resurse de care nu dispunem,
ş.a.m.d. Pentru a vedea graficul de supraalocare pentru inginerii de software, facem click pe
sǎgeata din dreapta a panoului din stânga, cel cu legenda, şi iatǎ rezultatul (Fig. 50):
Fig. 50
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
63
În cazul inginerilor de software, putem vedea cǎ în perioada 7 noiembrie 2011 – 9
noiembrie 2011 mai este nevoie de câte un inginer software (4 în total), ş.a.m.d.
Pentru a putea analiza modul de alocare a resurselor pe diferite intervale de timp, puteți
alege din panglica View, butonul Timescale, opțiunea Days. În acest caz, analiza se poate face
zilnic.
Mai existǎ un alt mod de vizualizare al resurselor supraalocate mult mai detaliat. Pentru
acesta vom selecta din panglicaView butonul Resource Usage (Fig. 51).
Fig. 51
Aici nu numai cǎ putem vedea şi activitǎţile, dar putem vedea exact timpul de lucru
(valorile negre), timpul de care mai este nevoie (valorile roșii), şi putem de asemenea sǎ vedem
ce resurse sunt asociate fiecǎrui task. Acest mod de vizualizare este cel mai util în caz cǎ dorim
mai multe detalii. Dacǎ vrem sǎ determinǎm rapid ce resurse sunt supraalocate, putem opta la
varianta a doua, cea cu graficul de alocare al resurselor.
Pentru a rezolva problema supraalocǎrii avem 3 opţiuni:
ori întârziem un task,
ori împǎrţim un task pe mai multe zile sau resurse,
ori în cel mai rǎu caz (din punct de vedere al costului) facem rost de noi resurse pentru a
le aloca proiectului.
Rezolvarea problemei de supraalocare
Metoda cea mai automatizatǎ de rezolvare a acestei probleme este metoda nivelǎrii.
Nivelarea se poate face în douǎ variante:
nivelare fǎrǎ extinderea duratei proiectului, şi
nivelare cu extindere a duratei.
Pentru prima variantǎ selectǎm butonul Leveling Options din panglica Resource şi vom
vedea urmǎtoarea fereastrǎ (Fig. 52):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
64
Fig. 52
Aici avem mai multe opţiuni, iar pe noi ne intereseazǎ momentan sǎ putem rezolva
supraalocarea fǎrǎ a extinde durata proiectului, aşadar bifǎm prima opţiune din cele 4 de jos,
Level only within available slack, adicǎ nivelarea va produce eventuale întârzieri ale task-ului
încât sǎ nu fie depǎşitǎ rezerva de timp disponibilǎ şi, deci, fǎrǎ a întârzia proiectul. Apoi apǎsǎm
butonul Level Resource dupǎ care vom fi întrebaţi dacǎ nivelǎm întregul stoc de resurse sau
doar resursele selectate. Pe noi ne intereseazǎ întregul stoc, aşadar alegem pe rând fiecare resursă
şi butonul Level Now. Dupǎ cum vom observa, proiectul nu mai are resurse supraalocate pentru
inginerii de design, acestea fiind distribuite optim încât sǎ nu fie întârziat proiectul, dar avem
resurse supraalocate la inginerii software. Sistemul afișează un mesaj de eroare prin care ne
semnalează că pe data de 9 noiembrie 2011 nu putem nivela resursele fǎrǎ sǎ întârziem proiectul,
apǎsăm butonul Skip All şi observăm eventual o nivelare slabǎ, adicǎ nu toate resursele sunt
nivelate. În acest caz, fiindcǎ am rǎmas cu resurse supraalocate, alegem din nou butonul
Leveling Options, debifăm prima opţiune din cele 5 şi apǎsat din nou OK, dupǎ care apelăm
butonul Level Resource sau Level All și observăm cǎ nivelarea a avut succes însǎ proiectul are
o duratǎ de desfǎşurare mai mare, se va termina pe 17 noiembrie 2011 și nu pe data de 14 cum a
fost planificat inițial cu o durată de 19 zile lucrătoare (Fig. 53).
Aşadar, dacǎ durata proiectului este criticǎ vom folosi nivelarea fǎrǎ extinderea duratei
proiectului, dacǎ ar fi fost posibilǎ, iar dacǎ nu, am fi recurs la a doua variantǎ. Dacǎ însǎ ne-am
fi permis o extindere a duratei proiectului, am fi putut alege de la început varianta a doua. De
asemenea, am fi putut rezolva problema supraalocǎrii manual, alocând noi resurse activitǎţilor la
care ar fi fost nevoie, însǎ cu costuri suplimentare. Decizia vă aparţine, fiindcǎ în asta constǎ
managementul proiectelor: în luarea de decizii.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
65
Fig. 53
16. Detaliile financiare ale resurselor
Introducerea datelor financiare pentru fiecare resursǎ
Pentru a atribui un anumit salariu şi un anumit mod de platǎ al salariului şi alte detalii de
genul acesta, va trebui sǎ editǎm stocul de resurse. Aşadar, selectǎm Resource Sheet din
panglica View şi va apǎrea stocul de resurse (Fig. 54).
Fig. 54
În acest tabel ne intereseazǎ coloanele de la Std. Rate pânǎ la ultima. Sǎ le explicăm pe
rând:
Std. Rate - aici se va introduce salariul. Dacǎ acesta este calculat pe orǎ de lucru, se
introduce xx/hr iar dacǎ este calculat pe an se introduce xx/yr.
Ovt. Rate - cu cât va fi plǎtitǎ resursa de muncǎ pentru orele lucrate în plus. La fel,
valoarea poate fi exprimatǎ în ore, zile, etc.
Cost/Use - în caz cǎ o resursǎ de muncǎ oferǎ şi servicii de consultanţǎ sau alte servicii
de genul, aici specificǎm cât cere acea persoanǎ pentru acele servicii (de obicei se lasǎ 0
aici).
Accrue At - tipul de platǎ. Se poate alege Start (plata la început), End (plata la sfârşit)
sau Prorated (plata pe mai multe rate).
Base Calendar - tipul de calendar al resursei. Poate fi cel standard, unul definit de noi,
ş.a.m.d.
Aşadar, în proiectul nostru vom atribui resurselor valorile din imaginea de mai sus pentru
fiecare coloanǎ descrisǎ anterior.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
66
Determinarea costului fiecǎrui task şi a costului total
Pentru a afla costurile de realizare ale fiecǎrui task, subtask şi chiar costul total al
proiectului, vom selecta de la butonul Tables al panglicii View, opţiunea Summary. Iatǎ
rezultatul pentru proiectul nostru (Fig. 55):
Fig. 55
Aşadar, pentru terminarea proiectului putem vedea cǎ este acum nevoie de 19 zile şi
proiectul va avea un cost total de 28.800 lei.
Pentru a afla costul total pentru utilizarea resurselor, vom selecta butonul Resource Sheet
din panglica View, iar apoi de la butonul Tables vom selecta opţiunea Cost (Fig. 56).
Fig. 56
17. Generarea rapoartelor
Pentru a genera un raport, selectǎm din secțiunea Reports butonul Reports folosind
panglica Project şi vom vedea urmǎtoarea fereastrǎ (Fig. 57):
Fig. 57
Aici sunt prezentate câteva din cele mai folosite tipuri de rapoarte, iar pentru mai multe
tipuri de rapoarte veţi selecta iconiţa Custom. Printre rapoartele cele mai folosite sunt cele
despre date generale, despre activitǎţile unui proiect, costurile proiectului, resursele proiectului,
ş.a.m.d. Deocamdatǎ sǎ selectǎm iconiţa Costs, fiindcǎ vrem un raport cu detaliile despre
costurile activitǎţilor şi a proiectului şi apǎsǎm butonul Select. Ne va apǎrea încǎ o listǎ de
iconiţe cu mai multe subtipuri de rapoarte referitoare la costuri, din care o vom alege pe prima,
Cash Flow şi apǎsǎm Select. Iatǎ cum va arǎta raportul (Fig. 58):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
67
Fig. 58
Putem vedea în acest raport atât activitǎţile proiectului, cât şi costurile necesare pentru
fiecare task grupate pe sǎptǎmâni. În ultima coloanǎ putem vedea totalurile task-urilor structurate,
iar pe ultimul rând din ultima coloanǎ se aflǎ costul total al proiectului.
Dacǎ proiectul însǎ ar fi durat o perioadă mai mare, poate cǎ nu ne-am dori sǎ vedem
costurile sǎptǎmânale, ci lunare, de exemplu. Pentru a schimba acest lucru, vom reveni la
fereastra Reports, de alegere a tipului de raport. Din aceastǎ listǎ vom selecta Cash Flow, apoi
apǎsǎm butonul Edit şi se va deschide fereastra de mai jos (Fig. 59):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
68
Fig. 59
Aici putem schimba unitatea de timp implicitǎ, selectând Months în loc de Weeks. Putem,
de asemenea, sǎ sortǎm elementele raportului în funcţie de anumite criterii sau putem filtra
raportul după anumite cerințe. Dupǎ ce am schimbat unitatea de timp pentru raport, apǎsǎm OK,
vom reveni la fereastra cu lista rapoartelor în care apǎsǎm Select şi vom vedea noul raport dar cu
costurile pe luni (Fig. 60).
Fig. 60
18. Task-uri recurente
La fel cum introducem un task simplu putem introduce de asemenea şi un task recurent.
Ce este un task recurent ? Este un task care se repetǎ la un anumit interval în timpul
desfǎşurǎrii proiectului. De exemplu, la o firmǎ de construcţii care lucreazǎ la un proiect de
dimensiuni mari este nevoie de foarte mult beton. Acest beton, evident, nu se va aduce tot
deodatǎ, ci câte puţin, în mod repetat, sǎ zicem o datǎ pe zi. Acesta este un task recurent!
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
69
Evident, şi acesta poate fi legat de alte task-uri sau subtask-uri, fiindcǎ, de exemplu, acea firmǎ
de construcţii ar avea nevoie de beton abia dupǎ terminarea unui anumit task, aşadar, dupǎ ce se
va termina acel task, va începe transportul zilnic de beton.
Sǎ presupunem cǎ, în exemplul nostru cu sistemul mobil de raportare vom avea nevoie de
vizita unui consultant expert în sisteme software o datǎ la trei zile pentru a verifica proiectul şi
stadiul în care s-a ajuns. Aşadar, vom introduce un task recurent numit Consultanţǎ care se va
repeta o datǎ la trei zile. Pentru a face acest lucru, comutăm în fereastra Gantt Chart, selectǎm
task-ul structurat Cerinţe de performanţǎ şi alegem panglica Task, secțiunea Insert, selectǎm
de la butonul Task opțiunea Recurring Task, moment în care ne va apǎrea urmǎtoarea fereastrǎ
(Fig. 61):
Fig. 61
Aici vom introduce informaţiile referitoare la task-ul recurent. În primul rând va avea
numele Consultanţǎ, durata de o zi, fiind o vizită la 3 zile. Alegem în stânga opţiunea Daily, iar
în lista ascunsǎ ce urmeazǎ mai la dreapta selectǎm Every 3 şi vom bifa opţiunea Workday din
dreapta listei ascunse. De ce? Fiindcǎ vrem ca acesta sǎ vinǎ doar în zilele lucrǎtoare. Dacǎ
bifam opţiunea Day, s-ar fi presupus cǎ acea persoanǎ venea chiar mai des decât odatǎ la 3 zile
pentru a recupera zilele de weekend în care nu se lucreazǎ în cadrul proiectului nostru.
Activitatea se va repeta de 7 ori pe durata proiectului. Apǎsǎm OK şi iatǎ rezultatul (Fig. 62):
Fig. 62
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
70
Evident cǎ acel consultant cere bani pentru vizitele fǎcute şi pentru informaţiile pe care le-
ar putea da cu privire la proiect şi progresul proiectului. Aşadar trebuie sǎ alocǎm o resursǎ nouǎ
special pentru acest task. Se procedeazǎ la fel ca într-o lecţie precedentă.
Observaţie: Când introduceţi un task recurent în proiect trebuie sǎ aveţi grijǎ ca acest task
sǎ fie executat în funcţie de calendarul resurselor, asta dacǎ aşa impune proiectul.
19. Sortarea, gruparea şi filtrarea informaţiilor
Pentru fiecare tip de vizualizare pus la dispoziţie, Microsoft Project ne oferǎ încǎ o
modalitate de a organiza informaţiile: sortarea, gruparea şi filtrarea.
Dacǎ ni se va cere sǎ printǎm un raport cu structura de task-uri a proiectului ordonatǎ
crescǎtor dupǎ cost, vom face o sortare.
Dacǎ ni se va cere sǎ printǎm toate task-urile în funcţie de prioritatea acestora, vom face o
grupare, iar dacǎ ni se vor cere doar task-urile critice cu diagrama Gantt, vom face o filtrare. Iar
fiecare dintre aceste trei funcţii se pot aplica la aproape toate modurile de vizualizare ale
proiectului.
Sortarea informaţiilor
În cazul proiectului nostru sǎ presupunem cǎ ni se cere sǎ afişǎm structura task-urilor
ordonatǎ dupǎ cost. Ne asigurǎm cǎ suntem în modul de vizualizare al diagramei Gantt, şi ne
ducem în meniul Project, alegem submeniul Sort şi selectǎm opţiunea by Cost. Vom vedea cǎ
tabelul de task-uri s-a ordonat dupǎ cost, chiar dacǎ nu putem vedea costul fiecǎrui task. Pentru a
vedea costul ne ducem la meniul View în submeniul Table şi alegem Cost. Vom observa cǎ
sortarea s-a fǎcut descrescǎtor dupǎ cost. Dacǎ dorim sǎ fie crescǎtor, alegem din meniul Project
-> Sort opţiunea Sort by şi ne va apǎrea o fereastrǎ cu trei liste ascunse şi câte douǎ opţiuni
pentru fiecare (Fig. 63).
Fig. 63
Selectǎm în prima listǎ Cost şi bifǎm opţiunea Ascending dupǎ care apǎsǎm OK. Acum
vom vedea task-urile în ordine crescǎtoare dupǎ cost.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
71
Alte opţiuni de sortare puse la dispoziţie sunt dupǎ Data de începere a unui task, Data de
sfârşire a unui task, dupǎ prioritatea unui task, ş.a.m.d. Dar pentru sortǎri mai avansate, vom
folosi opţiunea Sort by pentru a edita în fereastra de mai sus exact dupǎ ce vrem sǎ sortǎm şi
cum.
Gruparea informaţiilor
Pentru a grupa task-urile în task-uri critice şi non-critice, fiind încǎ în modul de vizualizare
Gantt, alegem din Project -> Group by opţiunea Critical şi iatǎ rezultatul grupǎrii (Fig. 64):
Fig. 64
Ca şi la sortare, avem şi aici mai multe opţiuni implicite de grupare (dupǎ duratǎ, duratǎ şi
prioritate, task-uri eveniment, etc), însǎ pentru o mai complexǎ grupare, vom alege din meniul
Project -> Group by opţiunea Customize Group, şi vom vedea urmǎtoarea fereastrǎ (Fig.65):
Fig. 65
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
72
Aici putem introduce toate criteriile dupǎ care se va face gruparea. Ca un exemplu, în
fereastra de mai sus am introdus sǎ se facǎ o grupare dupǎ task-urile critice şi non-critice, iar
pentru fiecare tip de task, o altǎ grupare dupǎ cost, sortat crescǎtor. Iatǎ rezultatul (Fig. 66):
Fig. 66
Putem vedea cǎ bara galbenǎ de culoare mai intensă indicǎ cele douǎ grupuri de task-uri,
critice şi non-critice, iar bara galbenă mai deschis indicǎ grupurile de task-uri care au un anumit
cost (400 lei, 800 lei, etc).
Filtrarea informaţiilor
Ce înseamnǎ filtrare ? Filtrarea presupune eliminarea informaţiilor care nu aparţin
anumitor criterii. De exemplu, putem face o filtrare dupǎ task-urile critice, obţinând astfel o listǎ
doar cu task-urile critice, cele non-critice fiind eliminate (nu şi fizic, ci doar temporar). Aşadar,
în proiectul nostru dezactivǎm gruparea selectând din meniul Project -> Group by opţiunea No
Group, revenind la modul de vizualizare Gantt. Acum vom selecta din meniul Project -> Filter
for opţiunea Critical. Iatǎ rezultatul (Fig. 67):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
73
Fig. 67
Putem vedea cǎ au dispǎrut task-urile non-critice doar privind diagrama Gantt, care ne
aratǎ doar task-urile critice. Pentru a elimina filtrul, selectǎm din acelaşi meniu Project -> Filter
for opţiunea All Tasks reafişând toate task-urile. Prin opţiunile de filtrare implicite putem gǎsi
filtrarea dupǎ task-uri evenimente, filtrarea task-urilor care încep şi se terminǎ într-un anumit
interval, care folosesc anumite resurse, ş.a.m.d. Şi aici putem, evident, sǎ alcǎtuim filtrele noastre
personalizate. Pentru a face acest lucru, selectǎm din meniul Project -> Filter for opţiunea More
filters şi va apǎrea o fereastrǎ cu o listǎ mǎricicǎ de filtre disponibile. Pentru a crea un nou filtru,
apǎsǎm butonul New, şi va apǎrea o fereastrǎ ca mai jos (Fig. 68):
Fig.68
Mai sus am introdus un nume de filtru care va descrie filtrul nostru, am bifat Show in
menu pentru a introduce acest filtru în lista de filtre implicite din cadrul submeniului Filter for,
iar în tabelul de mai jos am introdus douǎ linii astfel:
Am selectat din prima lista ascunsǎ elementul Critical şi am specificat ca acesta sǎ fie
egal cu Yes selectând opţiunea equals, fǎcând astfel sǎ afişǎm toate taskurile critice.
Apoi am selectat And din prima coloanǎ fiindcǎ mai impunem o condiţie: taskurile sǎ se
execute dupǎ o anumitǎ datǎ. Aşadar, am selectat Created din coloana Field Name
pentru cǎ ne intereseazǎ când a fost creat task-ul, în coloana Test am ales is greater than
or equal to (adicǎ mai mare sau egal) pentru cǎ dorim ca task-ul sǎ înceapǎ dupǎ o
anumitǎ datǎ, iar în ultima coloanǎ am introdus o valoare parametrizatǎ. Aceastǎ valoare
parametrizatǎ ne permite sǎ afişǎm o fereastrǎ la selectarea filtrului, în care utilizatorul
poate introduce o valoare. În cazul nostru am specificat între ghilimele ce mesaj sǎ aparǎ
utilizatorului în acea fereastrǎ şi dupǎ ghilimele am specificat operatorul ? pentru ca
Microsoft Project sǎ ştie cǎ este o valoare parametrizatǎ. Apǎsǎm OK, Close la fereastra
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
74
de filtre, iar din meniul Project -> Filter for vom alege filtrul tocmai creat de noi,
Critice după o anumită perioadă, şi vom vedea urmǎtoarea fereastrǎ (Fig. 69):
Fig. 69
În aceastǎ fereastrǎ vom introduce o datǎ dupǎ care vrem sǎ vedem task-urile critice, dupǎ
care apǎsǎm OK şi dacǎ am introdus bine data, vom vedea task-urile critice care au început dupǎ
acea datǎ introdusǎ.
Observaţie: Este bine de ştiut cǎ toate aceste trei operaţii (sortare, grupare şi filtrare) pot fi
combinate în funcţie de cerinţe. Aşadar putem face o sortare a unor grupǎri asupra datelor
obţinute dintr-un filtru.
20. Mai multǎ informaţie
Modul dual de vizualizare
Avem în Microsoft Project o opţiune de a putea vedea tabelul de task-uri cu diagrama
Gantt şi informaţiile despre resursele alocate fiecǎrui task. Vom face click dreapta pe diagrama
Gantt (într-o zonǎ neocupatǎ de vreun task) şi vom alege din meniu ultima opţiune, Split. Vom
vedea urmǎtoarea schimbare (Fig. 70):
Fig. 70
Putem vedea cǎ fereastra a fost împǎrţitǎ în douǎ, sus având modul de vizualizare Gantt iar
jos modul de vizualizare al Resurselor şi predecesorilor acestora. Fǎcând click pe un subtask
putem vedea cum se modificǎ informaţiile din panoul de jos. În fereastra de mai sus am fǎcut
click pe subtask-ul definirea cerinţelor de performanţǎ, şi putem vedea jos ce resurse au fost
alocate acestui subtask în lista din stânga, iar în lista din dreapta putem vedea subtask-urile
predecesoare, de care depinde subtask-ul selectat.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
75
Pe lângǎ faptul cǎ putem vedea mai multe informaţii deodatǎ, putem de asemenea sǎ
modificǎm resursele alocate cât şi legǎturile acestui subtask (predecesorul, tipul legǎturii, cu cât
va întârzia).
Fǎcând click dreapta pe partea gri din partea dreaptǎ a celei de-a doua liste, vom vedea un
meniu de unde putem alege tipul de vizualizare al resurselor task-urilor selectate. În imaginea de
mai sus ne aflǎm în modul de vizualizare Resources & Predecessors. Putem alege, de asemenea,
sǎ vedem orarul resurselor alocate task-ului (Resource Schedule), costul acestora (Resources
Cost), ş.a.m.d.
Dacǎ facem click pe partea inferioarǎ (în zona gri din dreapta) vom face din acest panou
inferior, panoul curent. La ce bun ? Acum putem selecta din meniul View tipul de vizualizare din
panoul inferior. Selectând Resource Graph putem vedea graficul de lucru al resurselor asociate
doar task-ului selectat din tabel, ca în imaginea urmǎtoare (Fig. 71):
Fig. 71
Cum facem sǎ scǎpǎm de panoul inferior ? Simplu: la fel cum am fǎcut ca acesta sǎ aparǎ.
Facem click dreapta pe diagrama Gantt şi vom alege Remove Split. Dacǎ însǎ nu vă aflaţi în
modul de vizualizare al diagramei Gantt, vă puteţi folosi de meniul Window unde aveţi aceleaşi
opţiuni: Split sau Remove Split.
Modificarea unitǎţii de timp folositǎ în diagrama Gantt
Am vǎzut cum putem modifica unitatea de timp într-un raport, dar cum putem modifica
unitatea de timp a diagramei Gantt? Avem douǎ motive pentru care am dori modificarea unitǎţii
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
76
de timp: dorim sǎ vedem întreaga diagramǎ a proiectului fǎrǎ a o derula, sau avem nevoie de mai
multe detalii (sau mai puţine).
Dacǎ avem un proiect de dimensiuni considerabile, am putea încadra întreaga diagramă în
acea micǎ fereastrǎ a diagramei. Cum? Vom face click dreapta pe bara unitǎţii de timp a
diagramei (cea cu iniţialele zilei, etc.) şi vom alege Zoom. Din fereastra care va apǎrea vom bifa
opţiunea Entire Project dupǎ care apǎsǎm OK. Rezultatul? Unitatea de timp de afişare a
diagramei se va mǎri (sau micşora) aşa încât sǎ putem vedea întreaga diagramă.
Pentru a schimba unitatea de timp folositǎ în afişarea diagramei, ori facem click dreapta pe
bara unitǎţii de timp şi alegem Timescale, ori selectǎm opţiunea cu acelaşi nume din meniul
Format. Ne va apǎrea urmǎtoarea fereastrǎ (Fig. 72):
Fig. 72
În prima listǎ ascunsǎ (Units) din aceastǎ fereastrǎ putem stabili care va fi unitatea de timp
implicitǎ care se va folosi în diagramǎ. Putem schimba sǎ afişǎm pe luni, pe trimestre, pe
semestre, zile, ore, minute, etc. În urmǎtoarea listǎ (Label) putem alege modul de afişare al datei
în funcţie de preferinţele fiecǎruia, putem de altfel sǎ o şi aliniem la stânga, dreapta sau pe mijloc
(în lista de dedesubt), iar în lista Show putem alege pe câte nivele va fi reprezentatǎ unitatea de
timp.
Inserarea unei alte coloane de informaţii în tabelul de task-uri
Dacǎ vrem sǎ afişǎm mai multe informaţii în tabelul de task-uri al modului de vizualizare
Gantt, nu trebuie decât sǎ facem click dreapta pe
capul de tabel pe una din coloane şi sǎ alegem
Insert Column, sau selectând din meniul Insert
opţiunea cu acelaşi nume. Aşadar, sǎ presupunem
cǎ vrem sǎ inserǎm în tabel coloana Cost pentru a
putea vedea costul fiecǎrui task fǎrǎ a schimba
modul de vizualizare. Dupǎ ce selectǎm Insert
Column, vom vedea urmǎtoarea fereastrǎ (Fig. 73):
Fig. 73
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
77
Aici vom alege din prima listǎ ascunsǎ coloana pe care vrem sǎ o includem în tabel, în
cazul nostru fiind Cost, specificǎm titlul coloanei (titlul din capul de tabel) sau lǎsǎm gol iar
titlul va fi cel din prima listǎ ascunsǎ. Apoi putem sǎ alegem alinierea titlului cât şi a valorilor
din coloanǎ, dupǎ care apǎsǎm OK şi iatǎ care va fi rezultatul (Fig. 74):
Fig. 74
Notiţe despre task-uri
Oricǎrui task i se pot asocia anumite notiţe care nu pot fi descrise în altǎ parte. La ce ne
folosesc astfel de notiţe ? Poate cǎ vom da acest proiect realizat în Microsoft Project unei alte
persoane care va analiza proiectul, şi aceasta va avea nevoie de anumite informaţii la fiecare task
pentru a şti exact ce reprezintǎ acel task. Sǎ zicem cǎ o astfel persoanǎ nu ar înţelege ce e cu
task-urile Codul program A şi Codul program B. Vom selecta unul din aceste douǎ subtask-uri,
vom face click dreapta pe el şi vom selecta Task Notes din meniu. Ne va apǎrea fereastra de
informaţii ale task-ului, însǎ cu eticheta Notes selectatǎ. Aici vom introduce un text descriptiv
despre acest task, gen “Codul program este împǎrţit în douǎ module A şi B fiind realizat de douǎ
echipe”. Apǎsǎm OK şi vom vedea cǎ în prima coloanǎ în dreptul subtask-ului a apǎrut o
imagine cu o notiţǎ galbenǎ. Vǎzând acea imagine, vom şti cǎ task-ul respectiv are anumite
informaţii, şi pentru a accesa acele informaţii procedǎm la fel: click dreapta pe task şi selectǎm
Task Notes (Fig. 75).
Fig. 75
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
78
Task-uri cu referinţe
Pe lângǎ notiţe, task-urile pot reţine şi adrese de internet, scurtǎturi la modurile de
vizualizare, ş.a.m.d. Sǎ zicem cǎ echipa A care realizeazǎ codul program A are un site pe internet
şi dorim sǎ putem accesa siteul cu ajutorul lui Microsoft Project. Vom face click dreapta pe
codul program A şi vom alege ultima opţiune, Hyperlink. Ne va apǎrea urmǎtoarea fereastrǎ
(Fig. 76):
Fig. 76
În aceastǎ fereastrǎ putem asocia subtask-ului o referinţǎ la un fişier extern sau o adresǎ de
internet, la un mod de vizualizare Microsoft Project, putem crea un nou document Project sau
putem asocia o adresǎ de e-mail. Deocamdatǎ vom introduce în câmpul de text de jos la Address
o adresǎ de internet, sǎ zicem http://www.microsoft.com. Apǎsǎm OK şi vom vedea cǎ în prima
coloanǎ în dreptul subtask-ului a apǎrut o imagine care ne spune cǎ acest subtask are o referinţǎ
la ceva. Acum, dacǎ facem click pe acea imagine ni se va deschide browser-ul de internet la site-
ul introdus de noi.
Acum sǎ alegem alt task sau subtask, sǎ zicem asamblare hardware. Vrem sǎ îi asociem
o referinţǎ la modul de vizualizare Resource Graph pentru a vedea graficul resurselor alocate.
Facem click dreapta pe subtask, alegem Hyperlink şi în panoul din stânga vom selecta Place in
This Document, adicǎ al doilea buton de sus. Ne va apǎrea o listǎ cu toate modurile de
vizualizare, din care noi vom alege Resource Graph şi apǎsǎm OK. Acum, dacǎ vom face click
pe imaginea din dreptul subtask-ului, vom vedea cǎ se schimbǎ modul de vizualizare exact aşa
cum am dorit (Fig. 77). La fel putem proceda şi cu celelalte douǎ tipuri de referinţe.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
79
Fig. 77
Personalizarea aspectului task-urilor
Oricǎrui task sau subtask îi putem modifica aspectul. Cum? Schimbând fontul, culoarea,
mǎrimea textului, ş.a.m.d. De ce am face acest lucru? Poate cǎ vrem sǎ scoatem în evidenţǎ un
anumit task/subtask. Pentru a face acest lucru, facem click dreapta pe task-ul dorit, şi alegem
Font. Ca sǎ scoatem în evidenţǎ acel task, sǎ zicem cǎ trebuie sǎ mǎrim dimensiunea fontului şi
culoarea acestuia. Schimbând aceste setǎri, iatǎ ce rezultat am putea obţine (Fig. 78):
Fig. 78
Mai multe despre resurse Fig. 79
La fel cum adǎugǎm o notiţǎ unui task,
putem adǎuga şi la resurse. Pentru a face acest
lucru, ne ducem în modul de vizualizare al
stocului de resurse (Resource Sheet), şi facem
click-dreapta pe o resursǎ, şi selectǎm Resource
Notes. Aici însǎ nu vom mai vedea vreo imagine
cu o notiţǎ galbenǎ în dreptul resurselor. Cum
facem sǎ aflǎm ce resursǎ are o notiţǎ asociatǎ în
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
80
caz cǎ avem de-a face cu un stoc mare de resurse ? Selectǎm modul de vizualizare Resource
Usage, unde putem vedea exact ce resursǎ are o notiţǎ asociatǎ, ca în imaginea de mai sus (Fig.
79).
Pe lângǎ notiţe, unei resurse îi putem asocia chiar şi o legǎturǎ externǎ, la fel cum am fǎcut
la task-uri. Unei resurse îi pot fi asociate aceleaşi tipuri de legǎturi externe ca şi la task-uri!
Un lucru important la resurse este cǎ putem edita pentru fiecare resursǎ în parte orarul
acesteia (când va lucra, când nu va lucra, etc.). Pe lângǎ orarul acesteia putem defini chiar şi un
interval de timp în care aceasta va fi disponibilǎ, tipul resursei (de muncǎ sau materialǎ), detaliile
referitoare la cost, ş.a.m.d.
21. Proiecte structurate
De multe ori avem de-a face cu proiecte mult mai complexe, mai vaste, proiecte
dependente chiar de alte proiecte. Microsft Project ne vine în ajutor chiar şi în acest caz!
Putem spune cǎ un proiect care conţine un alt proiect la rândul lui este ca un proiect care
conţine un task structurat, dar cu anumite diferenţe. Aşa cum un proiect poate avea mai multe
task-uri strucurate, el poate avea mai multe proiecte în el, fiecare din acele proiecte putând avea
la rândul lor alte proiecte în ele. Putem crea o întreagǎ ierarhie continuând aşa, însǎ ne vom
limita în acest paragraf doar la un proiect care conţine un alt proiect simplu în el.
Sǎ presupunem în exemplul nostru cǎ, înainte de a trece la începerea proiectului, avem
nevoie de resurse, adicǎ de angajaţi pe posturile de inginer de design şi inginer software. Pentru
aceasta am întocmit urmǎtorul proiect (Fig. 80):
Fig. 80
În acest proiect am definit pe prima linie titlul proiectului (Colectare resurse), unde avem
douǎ task-uri structurate care se ocupǎ de angajarea inginerilor software şi inginerilor de design,
iar dupǎ angajare putem întocmi lista de resurse pentru a putea continua proiectul implicit,
Sistemul mobil de raportare. Pentru a angaja ingineri software avem nevoie sǎ publicǎm
anunţuri de angajare, task ce va dura 5 zile estimat (publicare şi primirea de rǎspunsuri). Pentru a
seta o duratǎ estimatǎ unui task scriem pur şi simplu valoarea urmatǎ de ?, ca de exemplu 5?.
Apoi, dupǎ ce vom primi rǎspunsuri la anunţuri, vom putea intervieva persoanele ce doresc
postul respectiv. Dupǎ interviul care va dura o zi, vom da o testare celor intervievaţi pentru a
pǎstra persoanele cele mai potrivite. Pentru a angaja ingineri de design trebuie doar sǎ publicǎm
anunţurile, şi sǎ îi intervievǎm. Dupǎ toate acestea putem întocmi lista de angajaţi, moment în
care se va putea începe proiectul nostru. În stocul de resurse vom avea nevoie doar de 2
manageri, iar fiecǎrui task simplu îi vom aloca o singurǎ resursǎ manager, cei doi manageri fiind
distribuiţi automat task-urilor acestui proiect.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
81
Cum facem sǎ includem şi sǎ legǎm acest proiect de angajare în proiectul nostru ? Facem
click în proiect pe task-ul care va depinde de data finalizǎrii angajǎrii personalului, şi din meniul
Insert alegem Project şi ne va apǎrea fereastra de deschidere a unui proiect existent. Alegem
proiectul de angajare şi iatǎ cum va apǎrea în proiectul nostru (Fig. 81):
Fig. 81
Putem observa cǎ subproiectul de angajare are fontul îngroşat pentru a scoate în evidenţǎ
cǎ este un subproiect. Putem vedea exact structura şi diagrama Gantt întocmitǎ mai devreme
pentru acest subproiect. Mai mult, acum vom modifica predecesorul task-ului Intervievare
utilizatori şi introducem valoarea de pe prima coloanǎ a liniei unde apare subproiectul, în cazul
nostru fiind 2 (Fig. 82). Atenţie însǎ, fiindcǎ dacǎ ne uitǎm mai bine în prima coloanǎ apar de
douǎ ori numerele de la 1 la 9, fiindcǎ avem de-a face cu un subproiect în care numerotarea
începe tot de la 1. Nu putem sǎ legǎm un task din proiect cu un task dintr-un subproiect exact din
aceastǎ cauzǎ, dar putem lega un task din proiect de acel subproiect. Putem observa cǎ s-a
modificat şi drumul critic, şi deci, şi durata proiectului, iar din drumul critic fac parte chiar şi
task-urile din subproiect. Datoritǎ task-urilor cu durata estimatǎ în cadrul subproiectului putem
vedea, de asemenea, cǎ proiectul nostru are o duratǎ tot estimatǎ, lucru normal, de altfel, fiindcǎ
nu ştim cât va dura pânǎ se primesc rǎspunsuri la anunţurile de angajare. MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
82
Fig. 82
Observaţie: Aşa cum adǎugǎm o notiţǎ unui task, la fel putem adǎuga notiţe şi
subproiectelor.
22. Analiza progresului într-un proiect
Salvarea liniei de bazǎ a proiectului
De fiecare datǎ când terminaţi de realizat un proiect în Microsoft Project, trebuie sǎ
salvaţi o linie de bazǎ (o copie a proiectului), aceasta fiind folositǎ pentru a observa cât a durat
de fapt proiectul faţǎ de cum aţi plǎnuit iniţial sau care este costul proiectului într-un anumit
stadiu, putând astfel sǎ evaluaţi calitatea proiectului.
Microsoft Project nu ne ajutǎ doar sǎ facem estimǎri, ci ne ajutǎ chiar şi în timpul
desfǎşurǎrii proiectului. Putem, de exemplu, sǎ precizǎm la fiecare subtask cât la sutǎ s-a realizat,
şi putem vedea costurile pânǎ în acel moment, etc. Dar sǎ trecem la fapte, luând ca exemplu
proiectul nostru, Sistemul mobil de raportare.
Sǎ presupunem cǎ am terminat de realizat proiectul în Microsoft Project. Pentru a salva
linia de bazǎ, apǎsǎm pe săgeata din dreptul butonului Track din bara de instrumente şi selectǎm
primul element, Save a baseline plan to compare with later versions. Va apǎrea un nou panou
în stânga cu titlul Save Baseline unde putem vedea o listǎ, nişte opţiuni, ş.a.m.d. Din acea listǎ
selectǎm primul element, Save a new baseline, lǎsǎm bifatǎ opţiunea The entire project pentru
a crea o linie de bazǎ pentru întreg proiectul nu pentru task-uri individuale din moment ce ne va
interesa progresul proiectului, apǎsǎm pe butonul Save Baseline, iar apoi apǎsǎm pe Done. Iatǎ
cum putem sǎ salvǎm o linie de bazǎ (Fig. 83).
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
83
Fig. 83
Actualizarea progresului
Dupǎ ce salvǎm linia de bazǎ putem începe editarea progresului fiecǎrui task al proiectului.
Sǎ presupunem cǎ am ajuns aproape de sfârşitul proiectului. Ce înseamnǎ asta? Proiectul nostru a
început pe 20 aprilie 2009, şi se va sfârşi pe 27 mai 2009. Deci sǎ presupunem cǎ data curentǎ
este 23 mai 2009. Selectǎm Project Information din meniul Project şi la câmpul Status Date
alegem data de 23.05.2009, iar la Current Date alegem aceeaşi datǎ. Acum vom alege din
submeniul Table al meniului View opţiunea Tracking. Iatǎ ce vom vedea (Fig. 84):
Fig. 84
Vom introduce pe coloana % Comp. la subtaskul Intervievare utilizatori valoarea 100,
aceastǎ valoare având semnificaţia cǎ subtask-ul a fost finalizat. Sǎ presupunem cǎ a durat 6 zile,
nu 5 cum plǎnuisem. Vom introduce la acelaşi subtask pe coloana ActDur. valoarea 6. La fel
vom preciza cǎ subtask-ul Definirea cerintelor de performanţǎ a fost finalizat în procent de
100%, dar în loc de o zi a durat 2. La task-ul eveniment Finalizare cerinţe de performanţǎ vom
completa progresul cu valoarea 100, iar la subtask-ul Logica design-ului vom completa cu 25%
precizând astfel cǎ s-a realizat doar un sfert din acest subtask. Dupǎ cum putem vedea în coloana
Act.Dur., Microsoft Project a calculat cǎ 25% din acest subtask se realizeazǎ în jumǎtate de zi,
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
84
de aceea şi valoarea 0.5 days. Iniţial am stabilit cǎ va dura 2 zile acest subtask, motiv pentru care
putem vedea valoarea 1.5 days în coloana Rem.Dur., adicǎ timpul rǎmas pentru a finaliza
subtask-ul. Este şi logic: dacǎ 100% reprezintǎ 2 zile, 25% reprezintǎ o jumǎtate de zi. Dar sǎ
presupunem în cazul nostru cǎ a durat o zi sǎ se realizeze subtask-ul în proporţie de 25%. Vom
introduce în coloana Act.Dur. valoarea 1, dar vom vedea cǎ se schimbǎ automat valoarea de
25% în 50%, fiindcǎ o zi din douǎ reprezintǎ jumǎtate. Dar noi vrem sǎ îi spunem lui Microsoft
Project cǎ într-o singurǎ zi am realizat doar 25%. Pentru a face acest lucru, modificǎm valoarea
din coloana Rem.Dur. cu 3, fiindcǎ o zi din patru (1+3) reprezintǎ un sfert, adicǎ 25%. Ce putem
vedea pânǎ acum? Sǎ ne uitǎm la imaginea urmǎtoare (Fig. 85):
Fig.85
Putem vedea costul asociat progresului pânǎ în momentul de faţǎ, putem vedea câte ore de
lucru au fost efectuate de fapt, iar în diagrama Gantt putem vedea nişte linii negre în interiorul
benzilor colorate. Ce sunt aceste linii negre? Aceste linii negre ne aratǎ pe diagramǎ cât la sutǎ a
fost efectuat din subtask-urile respective. Putem vedea cǎ pe primele douǎ bare albastre apare o
linie neagrǎ lungǎ cât bara, iar pe cea roşie putem vedea cǎ subtask-ul nu a fost complet finalizat.
Un alt lucru interesant pe care îl putem face în acest moment este sǎ vedem dacǎ am
depǎşit sau nu suma disponibilǎ pentru realizarea acestui proiect, şi chiar cu cât am depǎşit-o sau
cât am economisit. Pentru a face acest lucru, selectǎm din meniul View opţiunea Reports iar din
fereastra de rapoarte alegem categoria Costs iar apoi subcategoria Earned Value. Vom vedea
urmǎtorul raport (Fig. 86):
Fig. 86
Acum ne uitǎm la coloana CV (Cost Variance) care este negativă, putem vedea cǎ avem o
depăşire a bugetului de 2.600 lei (5800 lei – 8400 lei) pânǎ la data curentǎ, iar în coloana SV
(Schedule Variance) putem vedea cât de în urmǎ suntem cu proiectul, dar în termeni de cost.
Coloana ACWP sau AC (Actual Cost on Work Performed / Actual Cost) ne aratǎ cât am plǎtit
deja pentru acest proiect pânǎ la data curentǎ.
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
85
AC or ACWP = Hourly Rate * Total Hours Spent = 8400 lei
EV or BCWP = Baselined Cost * % Complete Actual = 5800 lei
unde BCWP=Budgeted Cost of Work Performed sau EV=Earned Value
BCWS = Hourly Rate * Total Hours Planned or Scheduled = 22000 lei
unde BCWS=Budgeted Cost of Work Scheduled
Cost Variance (CV) = Earned Value (EV) - Actual Cost (AC) = BCWP – ACWP =
5800 lei-8400 lei = -2600 lei
CV ne indică în cât de mult suntem peste sau sub bugetul proiectului.
Dacă CV este pozitiv avem economii la buget (suntem sub bugetul estimat), dacă este
negativ avem depăşire (suntem peste bugetul planificat).
Schedule Variance (SV) = Earned Value (EV) - Planned Value (PV) = BCWP –
BCWS = 5800 lei – 22000 lei = -16200 lei
SV ne indică cât de mult suntem înainte sau înapoi faţă de planificarea proiectului.
Dacă SV este pozitiv suntem înaintea planificării, dacă este negativ suntem în urma
planificării, în termeni de cost.
Estimate At Completion (EAC): acest indicator determină costul proiectului până la
sfârşitul implementării.
EAC = AC + ( BAC -EV ) = 8400 lei + (29400-5800 lei) = 8400 + 23600 = 32000 lei
BAC = Baselined Effort-hours * Hourly Rate
Aceastǎ sumǎ o putem vedea şi în modul de vizualizare Tracking folosit mai devreme, la
coloana Act.Cost.
Un alt mod de a vedea aceste informaţii este cu ajutorul tabelelor. Vom selecta din
submeniul Table al meniului View opţiunea More tables, iar în fereastra care va apǎrea vom
selecta Earned Value din listǎ. Vom vedea în cadrul proiectului un nou mod de vizualizare care
ne aratǎ aceleaşi coloane ca şi în raportul generat mai sus (Fig. 87).
Fig. 87
Compararea progresului faţǎ de linia de bazǎ
Am vǎzut în subcapitolul anterior cum putem interpreta progresul proiectului în termeni de
cost. Dar cum facem sǎ interpretǎm pe înţelesul tuturor ? Vom selecta din submeniul Table al
meniului View opţiunea Variance şi vom vedea urmǎtorul tabel (Fig. 88):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
86
Fig. 88
În acest tabel putem coloanele Baseline Start (data de începere a task-ului în linia de bazǎ)
şi Baseline Finish (data de terminare a task-ului în linia de bazǎ). Aceste douǎ coloane ne ajutǎ
sǎ comparǎm progresul proiectului cu linia de bazǎ, pentru a putea spune cu cât suntem în urmǎ
sau dacǎ proiectul a decurs conform planului. Pentru acest lucru ne uitǎm la ultimele douǎ
coloane: Start Var. şi Finish Var. Dacǎ ne uitǎm pe tabelul de mai sus, iatǎ care este
interpretarea: subproiectul de angajare a început la timp (0 în penultima coloana), şi s-a
terminat la timp (0 în ultima coloanǎ). Intervievarea utilizatorilor a început la timp, dar a durat
cu o zi mai mult decât am plǎnuit (1 în ultima coloanǎ). Definirea cerinţelor de performanţǎ a
început cu o zi mai târziu decât a fost plǎnuit (1 în penultima coloanǎ), şi a durat cu o zi mai mult.
Logica design-ului a început cu 2 zile mai târziu şi a durat cu 2 zile mai mult decât am
plǎnuit. Design-ul bazei de date a început cu 4 zile mai târziu, dar nu a avut întârziere. Dacǎ ne
uitǎm la Codul Program A şi B putem vedea cǎ au început cu 4 zile întârziere, şi au durat cât am
plǎnuit (valorile de pe ultimele 2 coloane sunt egale). Acum, pe prima linie putem vedea cǎ
proiectul nostru a fost plǎnuit sǎ înceapǎ pe 20.04.09 şi a început pe în aceeaşi zi, 20.04.09. În
ultima coloanǎ putem vedea cǎ proiectul nostru va dura 4 zile în plus (diferenţa între ultimele
douǎ coloane). Dar acest lucru este deocamdatǎ relativ, fiindcǎ nu s-au terminat toate subtask-
urile iar Microsoft Project presupune implicit cǎ acestea vor respecta planul de desfǎşurare fǎrǎ
a avea întârzieri. Dar dacǎ vor apǎrea întârzieri, evident cǎ şi proiectul nostru ar putea dura cu
mai mult decât 4 zile în plus.
Informaţii statistice despre proiect
Pentru a vedea detaliile pe scurt despre un proiect, vom selecta Project Information din
meniul Project şi în fereastra care va apǎrea vom apǎsa butonul Statistics. Vom vedea
urmǎtoarea fereastrǎ (Fig. 89):
MPIT
Anul I Master: MAE
Disciplina: Managementul proiectelor IT
87
Fig. 89
În panoul de sus putem vedea informaţiile legate de datele de începere şi terminare ale
proiectului fǎcându-se referinţǎ şi la linia de bazǎ. Putem vedea chiar şi cu cât mai târziu începe
proiectul, şi cu câte zile în plus se terminǎ. Apoi, în panoul de jos putem vedea cât dureazǎ
proiectul, câtǎ muncǎ s-a depus, cât costǎ proiectul, cât mai a rǎmas din proiect de finalizat, la fel
cu referinţe la linia de bazǎ, ş.a.m.d. În stânga jos putem vedea chiar şi progresul proiectului.
MPIT
Top Related