Autor: Anca Mehedințu Master: Managementul Afacerilor electronice Anul I

Autor: Anca Mehedințu

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


3

I. Introducere în Project Management

1. Concepte despre proiecte. Factorii de succes şi eşec ai proiectelor


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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

http://www.trilex.ro/Method123/www.pmi.org

http://www.trilex.ro/Method123/www.prince2.org.uk

Anul I Master: MAE


21


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


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


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.


- Stabilirea organizării şi modalităţilor de comunicare în proiect

MPIT

Anul I Master: MAE


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.


- 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


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


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


27


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


28


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


29

II. Instrumente software folosite în managementul de proiect

1. O introducere în mediul Microsoft Project








9. Diagrama reţea











20. Mai multă informaţie



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


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

http://translate.googleusercontent.com/translate_c?hl=ro&prev=/search%3Fq%3DMicrosoft%2Bproject%2B2010%26hl%3Dro%26sa%3DG%26prmd%3Dimvnsb&rurl=translate.google.ro&sl=en&u=http://www.microsoft.com/project/en/us/project-professional-2010.aspx&usg=ALkJrhhRuvJPkpj8EgcvCrvGDjsfVCNjVA

Anul I Master: MAE


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

http://translate.googleusercontent.com/translate_c?hl=ro&prev=/search%3Fq%3DMicrosoft%2Bproject%2B2010%26hl%3Dro%26sa%3DG%26prmd%3Dimvnsb&rurl=translate.google.ro&sl=en&u=http://www.microsoft.com/project/en/us/default.aspx&usg=ALkJrhhCVzKZhDAKi29UvqH3kYRMnsDM7Q

http://translate.googleusercontent.com/translate_c?hl=ro&prev=/search%3Fq%3DMicrosoft%2Bproject%2B2010%26hl%3Dro%26sa%3DG%26prmd%3Dimvnsb&rurl=translate.google.ro&sl=en&u=http://www.microsoft.com/project/en/us/project-professional-2010.aspx&usg=ALkJrhhRuvJPkpj8EgcvCrvGDjsfVCNjVA

http://translate.googleusercontent.com/translate_c?hl=ro&prev=/search%3Fq%3DMicrosoft%2Bproject%2B2010%26hl%3Dro%26sa%3DG%26prmd%3Dimvnsb&rurl=translate.google.ro&sl=en&u=http://www.microsoft.com/project/en/us/solutions.aspx&usg=ALkJrhhprsPkb9XJHGD_uZ1Mlitly1g3aQ

http://translate.googleusercontent.com/translate_c?hl=ro&prev=/search%3Fq%3DMicrosoft%2Bproject%2B2010%26hl%3Dro%26sa%3DG%26prmd%3Dimvnsb&rurl=translate.google.ro&sl=en&u=http://www.microsoft.com/project/en/us/solutions.aspx&usg=ALkJrhhprsPkb9XJHGD_uZ1Mlitly1g3aQ

Anul I Master: MAE


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


33

Fig. 2


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


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


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


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


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


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).


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


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


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


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.


Î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


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


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.


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


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ǎ).


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


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


45


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


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


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


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


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


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


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


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


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


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


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).


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


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


55

Fig. 38


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


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).


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


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


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


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


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


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


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


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


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


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


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


65

Fig. 53


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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

http://www.echipaa.ro/

Anul I Master: MAE


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


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.


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


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


82

Fig. 82

Observaţie: Aşa cum adǎugǎm o notiţǎ unui task, la fel putem adǎuga notiţe şi

subproiectelor.


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


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


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


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


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


MPIT

Anul I Master: MAE


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

Autor: Anca Mehedințu Master: Managementul Afacerilor electronice Anul I

Documents

Transcript of Autor: Anca Mehedințu Master: Managementul Afacerilor electronice Anul I