cuprins -...

Cuprins

Introducere

Motivele eşecurilor proiectelor software

1. Definirea proiectului

2. Planificarea activităţilor

3. Managementul planului de lucru

4. Probleme de conducere

5. Managementul scopului

6. Managementul riscurilor

7. Gestiunea comunicaţiilor

8. Managementul documentaţiei

9. Managementul de calitate

10. Managementul metricilor

Concluzii

Bibliografie

Managementul proiectelor informatice - pag. 1

Introducere

Managementul proiectelor software cuprinde cunoştinele, tehnicile şi uneltele necesare

pentru dezvoltarea produselor software. Acest material discută planul dezvoltării produselor

software folosind o estimare efectivă a mărimii şi efortului precum şi executarea acestui plan cu

menţinerea productivităţii şi calităţii. În acest context, topici ca managementul riscului, modele

alternative la ciclul de viaţă (al produselor software), organizarea echipelor de dezvoltare şi

managementul tehnicienilor sunt deasemeni discutate.

Managementul proiectelor software rămâne oarecum diferit de managementul proiectelor

din alte domenii dintr-un număr de motive: software-ul este un "produs exclusiv mental",

neconstrâns de legile fizicii sau limitele proceselor de producţie. Este dificil să se detecteze şi să se

prevină defectele în produsele software. Software-ul poate fi foarte complex. În fine, ca disciplină,

dezvoltarea software este relativ recentă astfel întât tehnicile de măsurare efectivă nu sunt încă pe

deplin disponibile iar acelea care există nu sunt bine calibrate.

În ciuda acestor dificultăţi, există o bază solidă de cunoştinte despre managementul

proiectelor software.

Managementul proiectelor software este implementat în programe pentru ingineria software

din cauză că dezvoltarea software este strâns legată de tehnicile de management. Ceea ce este

descris aici ca primul nivel de management de producţie este cel mai înalt nivel din managementul

predat la şcolile de afaceri.

Proiectele mici nu necesită foarte multe cunoştinţe de management al proiectului sau

disciplină în managementul proiectului. Dar, pe măsură ce proiectul devine mai mare, procesele

formale şi tehnicile devin esenţiale. Pentru organizarea şi structurarea acestor procese prin

managementul proiectelor există diferite metodologii dar sunt esenţiale zece arii de interes, descrise

mai jos în acest document. În general, dacă putem stăpâni aceste arii, putem avea succes în cele mai

multe proiecte. Pentru un proiect mic, nu trebuie să ne facem griji despre managementul

documentaţiei sau aprecierea calităţii dar pe măsură ce proiectul avansează va trebui să ne

focalizăm în toate cele zece procese.

De notat că lista noastră nu include analiza, proiectarea, testarea sau implementarea. Aceia

care au lucrat cu proiecte ştiu probabil că ele includ analiza şi testarea. Totuşi, trebuie să facem o


distincţie majoră. Analiza şi testarea sunt părţi din efortul pentru realizarea proiectului propriu-zis

(denumit deasemeni durata de viaţă a proiectului). Aceste faze se schimbă în funcţie de tipul

proiectului. Dacă avem un proiect complet, putem executa toţi paşii de analiză, proiectare,

construcţie, testare şi implementare. În alte proiecte însă putem avea de realizat doar anumite

componente. De exemplu, dacă avem un proiect de cercetare şi dezvoltare (engl. R&D), nu vom

face implementarea. Dacă facem un studiu, proiectul ar putea să se sfârşească după faza de analiză.

Lipseşte ceva?

Câteodată două alte procese sunt incluse ca parte a managementului proiectului de bază:

managementul resurselor umane şi managementul contractului şi achiziţiilor. Managementul

resurselor umane este o pricepere valoroasă pentru managerii de proiect, dar nu este specifică

managementului de proiect. De fapt, toate relaţiile subordonate managementului necesită

managementul forţei de muncă. Distincţia este că este o îndemânare a unui manager de proiect dar

nu o secţiune separată din managementul proiectelor.

Deasemeni am exclus contractul de management şi achiziţii din listă. În cele mai multe

companii, managerii de proiect trebuie să aibă cunoştinţă despre managementul contractelor şi

vânzărilor, dar nu sunt responsabili pentru el. Pentru acestea, de obicei există un departament juridic

care este responsabil cu aceste discipline.

Temporizarea şi secvenţierea proceselor

Cu excepţia primelor două categorii - definirea proiectului şi planificarea lucrului - cele zece

faze ale managementului de proiect nu se realizează într-o anumită ordine. Procesele de la trei la

zece pot fi aranjate în orice ordine şi de fapt, sunt executate în paralel şi odată cu proiectul. De

exemplu, dacă apare o problemă majoră, trebuie mai întâi să se folosească managementul

problemelor indiferent ce alte aspecte ale managementului proiectelor s-au folosit înainte, în timpul

sau după acest timp.


Motivele eşecurilor proiectelor software

Mai întâi trebuie să spunem că proiectele informatice au astăzi o şansă de succes de 32%,

44% este procentul pentru cele eşuate care nu s-au încadrat în timp, buget sau nu au respectat

cerinţele şi 24% au fost anulate înainte de a fi terminate sau au fost livrate şi nu s-au folosit

niciodată (Chaos Report 2009 - Standish Group).

Proiectul mediu este terminat cu 222% mai târziu, cu 189% peste buget şi livrează doar 61%

din funcţiile specificate.

Timp insuficient

De multe ori data începerii proiectului este fixată înainte de începerea proiectului şi nu este

negociabilă. Asta duce la graba de a începe proiectul făcând presupunerea că dacă se va începe

codarea mai repede rezultatul va fi disponibil mai devreme.

Aceasta este aproape întotdeauna alegerea eronată. Este vital să se folosească timpul pentru

a crea un bun design. Dacă nu aveţi un proiect bun asta va conduce la modificări de-a lungul fazei


Ce a înţeles managerul de proiectCum a explicat clientul

Cum a proiectatanalistul

Ce a scris programatorul

Cum îl descriebusiness-consultant-ul

Cum a fost documentat Ce au instalat operatorii

Cum a fost facturatclientul

Cum este suportul Ce voia de faptclientul

de dezvoltare. Când se întâmplă asta timpul şi bugetul sunt consumate cu o viteză foarte mare.

Soluţie: Rezervaţi-vă timp pentru a face un proiect bun. Rezistaţi tentaţiei de a scurta timpul şi a

începe scrierea codului. Alocaţi-vă timp pentru aceasta şi restul proiectului va decurge mult mai

bine. Vă va creşte reputaţia când veţi livra proiecte care îndeplinesc aşteptările clienţilor şi

funcţionează bine de prima dată.

Buget insuficient

Multe proiecte au o politică de "cel mai mic preţ este cel mai bun candidat" sau un buget

nerealistic de mic, care nu se bazează pe cerinţele reale. Când se întâmplă asta, totul tinde să dureze

mai mult. Resursele ajung mai târziu sau niciodată, se fac improvizaţii, reduceri şi calitatea suferă.

Soluţie: Fiţi realişti asupra bugetului necesar şi asiguraţi-vă că se bazează pe cerinţele actuale.

Evitaţi să vă bazaţi doar pe un furnizor care are cel mai mic preţ. Mergeţi cu un furnizor sau echipă

care a demonstrat că livrează în bugetul estimat.

Slaba comunicare

O zicală veche spune "niciodată să nu presupui nimic" şi acesata este foarte adevărat pentru

proiectele software. Comunicarea corectă este vitală pentru succesul proiectului, clienţii, utilizatorii

şi în special cu echipa de dezvoltare. Vă înţelege toată echipa? Ştiu exact ceea ce se aşteaptă de la ei

sau aţi presupus că ştiu? Comunică bine între ei, cu utilizatorii şi cu alte departamente?

Soluţie: Identificaţi imediat lacunele în comunicare. Acestea pot duce la confuzii şi complicaţii mai

târziu. Niciodată nu presupuneţi că a înţeles toată lumea. Rezervaţi-vă timp pentru a crea un mediu

care va aduce proiectul în timp, în buget şi conform cerinţelor clienţilor.

Nu revizuiţi progresul proiectului

Pe măsură ce un proiect progresează apar modificări şi acestea pot avea un impact

semnificativ. Este important să monitorizaţi progresul din când în când astfel încât problemele pot fi

rezolvate mai repede şi clienţii avertizaţi de posibilele întârzieri şi schimbări în produs.

Soluţie: Fixaţi puncte de reper frecvente în timpul proiectului unde puteţi revizui progresul

împreună cu echipa şi puteţi face ajustările necesare pentru a rămâne în cursă. Staţi aproape de

echipă astfel încât să înţelegeţi ce se întâmplă şi cu ce probleme se confruntă.


Testare insuficientă

Când se execută presiuni pentru livrare, de obicei testarea este cea care suferă Toate testările

sunt amânate până la sfârşitul ciclului de dezvoltare şi când nu mai sunt decât bani pentru service.

Foarte des produsul are multe erori ceea ce duce la un client nesatisfăcut.

Soluţie: Faceţi testări de-a lungul întregului ciclu de dezvoltare, testaţi fiecare modul sau

componentă de îndată ce a fost produsă. Aceasta lasă ca numai integrarea să fie testată la sfârşitul

ciclului de dezvoltare.

Testarea în mediul de producţie

Este surprinzător câte organizaţii testează produsele în mediul de producţie. Aceata este o

stragegie cu risc mare care poate duce la probleme de securitate şi livrări fără testare care pot afecta

mediul de producţie.

Soluţie: Creeaţi un proces pentru asigurarea calităţii şi livrarea de noi produse. Oferiţi un mediu

separat de producţie, numai pentru testare.

Lipsa asigurării calităţii

Adesea asigurarea calităţii suferă la livrearea produselor software. Schimbările în cod nu

sunt documenteate, proiectarea conţine erori fatale şi implementarea poate fi incompletă. Toate

acestea pot duce la refacerea muncii, pierderea de timp şi în cele din urmă a clienţilor.

Soluţie: Asiguraţi-vă timp pentru controlul de calitate şi documentaţi software-ul înainte de a fi

livrat.

Neconformitate faţă de standardele industriale

Conformitatea proiectelor software cu standardele din industrie se pot dovedi eficace la

asigurarea accesibilităţii, portabilităţii, uzabilităţii, robusteţii şi reducerea problemelor acum şi în

viitor.

Soluţie: Asiguraţi-vă timp pentru a introduce standardele în proiecte. Identificaţi ceea ce merge bine

şi schimbaţi ceea ce nu merge bine. Revizuiţi şi împrospătaţi standardele de câte ori este nevoie.


1. Definirea proiectului

Ca manager de proiect, trebuie să vă asiguraţi că obiectivul este înţeles corect şi asumat de

sponsorul proiectului şi acţionarii principali înainte de începerea proiectului. Pentru aceasta, se va

lucra cu sponsorul şi acţionarii pentru ca echipa de proiectare şi clientul să aibă o viziune comună

asupra a ceea ce va livra proiectul, când va fi complet, cât va costa, cine va face munca, cum va fi

completată lucrarea şi care vor fi beneficiile.

Cu cât un proiect este mai mare, cu atât mai important este ca această informaţie să fie

stocată formal şi explicit. Toate proiectele ar trebui să înceapă cu acest tip de planificare anterioară

pentru a preveni problemele cauzare de diferite puncte de vedere asupra termenilor de bază din

proiect. Cea mai mare parte din acest pas este "Definirea proiectului" (unele companii îl numesc

"Graficul proiectului").

La un nivel superior, scopul definirii activităţii include:

• Înţelegerea şi obţinerea aprobării obiectivelor proiectului, livrarea, scopul, riscul, costul,

modalitatea de realizare, etc. Aceasta este cea mai importantă parte a definirii activităţii şi

este locul unde se consumă cel mai mult timp pentru realizarea aprobării.

• Determină actualitatea proiectului, dacă afacerea originală mai este încă validă. De exemplu,

un proiect care cere 10.000 ore de efort poate face obiectul unei afaceri. Dacă după o

definire a procesului mai în detaliu rezultă un efort estimat de 20.000 ore, proiectul poate să

nu mai fie fezabil.

• Asiguraţi-vă că resursele de care este nevoie sunt disponibile atunci când este nevoie de ele.

• Asigurarea unui nivel de bază înalt din care poate fi comparat progresul şi din care scopul

poate fi controlat.

• Obţinerea aprobării clientului în procesul utilizat de conducere a proiectului.

Efortul necesar definirii muncii depinde de cantitatea de informaţie şi nivelul de detaliere

care trebuie înţeles şi documentat. Timpul necesar pentru definire depinde de timpul necesar

descoperirii şi documentării informaţiei, ca şi timpul cerut de obţinerea aprobării şi acordului

clientului. Poate fi dificil să se definească exact cum vor arăta cerinţele finale pentru proiecte mari

şi complexe. Este deasemeni dificil să se estimeze costul total şi data predării. Dacă acesta este

cazul, proiectul curent se poate diviza în proiecte mai mici. Proiectele care sunt realizate mai întâi

pot fi mai uşor de definit. Proiectele care vor fi completate în viitor pot fi definite în detaliu pe

măsură ce se apropie de execuţie.


La sfârşitul părţii de definire, trebuie să aveţi un capitol de definire care să definească

aşteptările proiectului în termenii obiectivelor, scopului, riscurilor, costurilor, datei de predare şi

rolurilor. Acest document trebuie aprobat formal de sponsorul proiectului şi alţi contribuitori cheie

înainte ca echipa de proiectare să înceapă lucrul. Câteodată puteţi fi frustrat de dificultăţile în

obţinerea aprobării clientului în ceea ce priveşte scopul, termenul de predare şi costul. Dar acesta

este motivul exact pentru care definirea muncii este făcută înainte. Gândindu-vă la probleme vă veţi

trezi fără îndoială încercând să obţineţi aprobarea clientului asupra scopului, calendarului sau

costului când începeţi lucrul şi se produc de fapt rezultate.

2. Planificarea lucrului

Când definiţi proiectul, asiguraţi-vă că aveţi o aprobare a sponsorului proiectului asupra

muncii care trebuie făcută în acest proiect. În această etapă, veţi determina cum va fi făcută munca.

Aceasta implică construirea Planului de lucru. Veţi folosi diverse metode în conformitate cu

mărimea proiectului. De exemplu, un plan de lucru pentru proiecte mici poate fi făcut folosind un

pachet de management al proiectelor cum ar fi Microsoft Project, o foaie de calcul sau chiar o foaie

de hârtie.

Dacă nu aveţi un şablon pentru planul de lucru puteţi folosi Structura de descompunere a

lucrului (engl. Work Breakdown Structure - WBS), o tehnică de descompunere a unui proiect de la

un nivel înalt şi descompunerea în componente din ce în ce mai mici până când aveţi o privire de

ansamblu asupra muncii. La acest exerciţiu poate colabora întreaga echipă. Se recomandă

descompunerea lucrului în nivele din ce în ce mai mici până când fiecare activitate rămasă este mai

mică decât 80 de ore şi când este clar care sunt cerinţele pentru completarea activităţii.

Odată ce toate aspectele sunt descoperite, puteţi crea secvenţa activităţilor şi identifica

dependenţele dintre ele. În acest punct, planul de descompunere poate fi transformat într-un grafic

de tip reţea.

În pasul următor, adăugaţi resurse (personal) pentru fiecare activitate. Dacă aveţi cunoştinţă

despre anumite resurse, le puteţi adăuga după nume. Dacă nu, puteţi folosi nume generice ca să le

ţină locul. Adăugaţi apoi orele alocate şi datele de început şi sfârşit pentru fiecare activitate.

Planul de lucru este gata de pornire. Ştiţi ce muncă trebuie să faceţi (Definirea proiectului) şi

cum îl veţi face (Planul de lucru).


Relaţia dintre definirea şi planificarea proiectului

Puteţi descoperi că nu puteţi completa Definirea proiectului fără crearea de ansamblu a

Planului de lucru. În multe cazuri, va trebui să lucraţi cu acestea două simultan. Pe măsură ce

obţineţi informaţii despre scop şi ceea ce trebuie realizat, va trebui să gândiţi un calendar astfel

încât să puteţi lucra cu efortul şi durata estimată. Când ceea ce trebuie finalizat, scopul,

presupunerile şi metodele sunt completate, trebuie să aveţi suficiente informaţii în Planul de lucru

pentru a estima bugetul, efortul şi durata pe care le veţi folosi mai apoi la Definirea proiectului.

3. Conducerea planului de lucru

În acest punct, aţi terminat definirea proiectului şi planificarea muncii. Ceea ce aţi obţinut

până acum sunt Definirea proiectului şi Planul de lucru. Unii manageri de proiect cred că definirea

şi planificarea muncii înseamnă că partea dificilă a conducerii proiectelor s-a terminat. Cu siguranţă

că nu aceasta este situaţia.

Nu veţi fi niciodată un manager de proiect de succes dacă nu ţineţi la zi planul de lucru.

Reţineţi, planul de lucru este doar o parte a problemei. El descrie munca ce trebuie făcută, ordinea

în care se face, cât efort este necesar şi cine trebuie să îl facă dar este doar cea mai bună apreciere a

cum trebuie să se completeze munca rămasă la orice moment particular din proiect.

Cu cât proiectul este mai complex, cu atât mai mult va trebui să modificaţi planul de lucru

de-a lungul timpului.Ca manager de proiect, trebuie să evaluaţi planul de lucru pe bază de

modificări (probabil săptămânal) şi să determinaţi starea curentă a proiectului.

În timpul acestei revizuiri săptămânale, veţi modifica planul la starea curentă a muncii

completate şi în progres. Veţi evalua munca rămasă pentru a vedea dacă proiectul va fi completat cu

efortul, costul şi durata planificate. Dacă puteţi, sunteţi într-o formă bună. Dacă nu puteţi, trebuie să

implementaţi acţiuni corective.

Din toate calităţile managerului de proiect, acesta este poate cel mai fundamental.

Depinzând de dinamica proietului, puteţi fi în poziţia de a trebui să folosiţi constant experienţa şi

creativitatea proprii pentru a completa proiectul conform aşteptărilor. Într-una din săptămâni,

proiectul poate să fie în termeni. În altele, veţi descoperi că anumite segmente sunt întârziate şi au

apărut probleme.


Dacă activitatea dintr-o zonă critică este întârziată cu o săptămână, nu puteţi ignora aceasta

şi să permiteţi întregului proiect să fie întârziat cu o săptămână. Trebuie să evaluaţi resursele şi

opţiunile disponibile şi să aduceţi proiectul din nou pe şine. Dacă sunteţi bun la asta, conducerea

planului de lucru poate fi unul din cele mai interesante şi recompensante aspecte ale

managementului proiectului. Dacă nu realizaţi munca detaliată de care este nevoie, puteţi găsi că

este mult mai dificil să aveţi succes.

4. Managementul problemelor

O "problemă" apare când apare ceva care va împiedica progresul proiectului şi nu poate fi

rezolvat de managerul de proiect şi echipa de proiectare fără ajutor din afară. Dacă apare o

problemă majoră, nu aveţi încotro şi trebuie să o rezolvaţi. Singura întrebare va fi dacă veţi aplica

managementul problemelor pentru a le rezolva situaţia sau să plutiţi între indecizie şi incertitudine

despre cum trebuie rezolvată problema.

Managementul problemelor are două componente majore. Prima este procesul de a

descoperi problemele, determinarea impactului asupra proiectului, examinarea alternativelor şi

aducerea personalului în măsură să ia cele mai bune decizii în circumstanţele date. Aceasta este

parte a procedurilor de management care trebuie definită şi asupra căreia să se ajungă la un acord

din timp. Aceste proceduri asigură recunoaşterea problemelor şi rezolvarea lor cât mai rapidă.

A doua componentă a managementului erorilor este aplicarea tehnicilor specifice pentru

rezolvarea problemelor. Aceasta include înţelegerea tehnicilor cum ar fi diagramele Fishbone,

graficele Pareto, şi analiza cauzelor iniţiale. Având o înţelegere a unora sau tuturor acestor tehnici

vă permite ca împreună cu echipa să înţelegeţi natura şi cauza problemei, care sunt opţiunile

disponibile şi ce alternative vor da curs celei mai bune căi de rezolvare.

Un lucru important pe care toţi managerii de proiect îl descoperă este de că a avea un proces

de rezolvare a problemelor nu înseamnă că veţi rezolva cu succes toate problemele. În general, sunt

alternative mai bune pentru probleme şi activitatea este de a descoperi cea mai bună alternativă. În

alte cazuri, nu există o rezolvare mai bună la o problemă majoră. Câteodată, alegerea finală este de

a alege soluţia ce cauzează cea mai puţin dăunătoare sau care este cea mai bună din alternativele

proaste. Totuşi, procesul de rezolvare şi tehnicile de rezolvare a problemelor vă vor permite să

determinaţi ce soluţii sunt disponibile astfel încât cel puţin să înţelegeţi repercursiunile.


5. Managementul scopului

Scopul descrie limitele proiectului şi defineşte ceea ce va livra proiectul, care sunt datele

necesare şi ce organizaţii sunt implicate. Fiind dat un set de resurse şi timp nelimitat, pot fi livrate

un număr infinit de lucruri.

Gestiunea scopului începe cu definirea modificării scopului. Dacă managerul de proiect nu a

făcut o treabă bună atunci când a definit scopul, va fi dificil să gestioneze scopul de-a lungul

proiectului. Scopul gestionării acestei schimbări este de a proteja viabilitatea Definiţiei proiectului

curentă şi aprobată. Când a fost definit un proiect, s-au fixat anumite aşteptări pentru proiectul în

desfăşurare pentru pentru un anumit cost şi pentru o limită de timp stabilită. Managerul de proiect şi

sponsorul au deopotrivă aceste aşteptări în minte atunci când este creeată şi aprobată Definiţia

proiectului.

Trebuie să se ia în calcul că în timpul de viaţă al unui proiect, poate fi nevoie de componente

care sunt diferite de sau nu sunt incluse în Definiţia proiectului. Dacă apare acest fenomen, clientul

nu trebuie să se aştepte ca aceste componente să fie livrate folosind constrângerile de timp şi resurse

care au fost aprobate în prealabil. Echipa de proiectare va identifica noile cerinţe şi va determina

impactul asupra proiectului dacă noile cerinţe vor fi incluse. Informaţia este apoi adusă la cunoştinţa

sponsorului pentru aprobare.

Reţineţi, sponsorul este acela care a aprobat finanţarea muncii cu care se porneşte. Deci, el

or ea este acela care ar trebui să aprobe orice schimbări asupra înţelegerii iniţiale. Dacă valoarea

afacerii schimbate este deajuns de înaltă, sponsorul ar trebui să aprobe adăugarea noilor cerinţe la

proiect, ca şi incrementarea bugetului şi timpului estimat de lucru necesar pentru a completa munca.

Toţi vor fi în acest fel de acord şi aşteptările tuturor vor fi reiniţializate.

Sigur, aceasta nu se întâmplă întotdeauna fără hopuri. Problemele comune includ:

• Schimbări necontrolate. Schimbările largi în destinaţie sunt uşor de descoperit. Totuşi,

când toate schimările sunt mici câteodată aflaţi că le-aţi inclus fără să realizaţi asta.

Schimbările necontrolate înseamnă că aţi acceptat modificări mici care au un efect cumulativ

semnificativ asupra proiectului. Dumneavoastră şi întreaga echipă trebuie să fiţi educaţi

pentru a observa toate schimările destinaţiei, mici şi mari.

• Aprobarea utilizatorului final. Sponsorul proiectului este persoana ce plăteşte proiectul.

Totuşi, odată ce proiectul a început, echipa consumă mai mult timp cu clienţi de nivel mai

redus şi utilizatori finali. Unii dintre membrii echipei de proiectare cred că schimbările


destinaţiei sunt în regulă dacă utilizatorul final le aprobă. Nu este corect să procedaţi direct

la schimbări. Dacă sponsorul nu a delegat specific autoritatea de aprobare, aceste persoane

nu pot aproba modificările scopului. Ei pot ridica cereri de modificare a destinaţiei, dar doar

dacă sponsorul are autorizarea de a creşte finanţarea pentru munca suplimentară.

• Membri ai echipei de care nu se ţine cont. O cauză comună a termenelor de livrare

depăşite este că membrii echipei lucrează mai mult decât s-a cerut iniţial. De exemplu, unui

membru al echipei i s-a cerut să facă un raport. Când el sau ea l-au creat, clientul cere noi

informaţii. Membrul echipei încearcă să satisfacă clientul şi lucrul este întârziat. Asta se

întâmplă când membrii echipei cred că doar managerul de proiect trebuie să se îngrijească de

managementul schimbărilor de destinaţie. Ei trebuie să înţeleagă că este responsabilitatea

tuturor.

Cauza majoră a multor proiecte eşuate este managementul inferior al schimării destinaţiei.

Definirea şi gestionarea scopului vor creşte efectiv şansele ca proiectul să fie dus la bun sfârşit.

6. Managementul riscurilor

Riscul se referă la condiţiile sau circumstanţele viitoare care există în afara controlului

echipei de proiectare şi care au un impact negativ asupra proiectului dacă apar. În alte cuvinte, ori

de câte ori apare o problemă care trebuie să fie rezolvată, apare o potenţială problemă de risc.

Managerii de proiect reactivi rezolvă problemele atunci când apar. Managerii de proiect proactivi

încearcă să identifice şi rezolve problemele potenţiale înainte ca acestea să apară. Aceasta este

ştiinţa şi arta managemenului riscurilor.

Deoarece proiectele mici nu au în general durate mari de timp, există o probabilitate mică ca

să apară probleme. Proiectele mari însă au de obicei riscuri mari la orizont. Managementul riscurilor

implică identificarea tuturor riscurilor potenţiale ale proiectului, determinând cum este mai probabil

să apară şi înţelegerea impactului asupra proiectului dacă apar.

Cu această informaţie, echipa de proiectare poate determina care sunt riscurile ce trebuiesc

conduse activ. De exemplu, un risc cu o rată mare a probabilităţii de apariţie şi un impact major

asupra proiectului trebuie să fie gestionat preventiv. Pe de altă parte un risc cu o mare probabilitate

de apariţie dar un impact marginal asupra proiectului poate fi probabil ignorat.

Odată identificate riscurile ce trebuiesc gestionate activ, puteţi folosi cinci răspunsuri

generale:


• Ignorare. Puteţi să ignoraţi un risc dacă consideraţi că proiectul nu va fi periclitat în cazul

apariţiei riscului sau dacă nu a poate fi făcut nimic care să reducă riscul şi doriţi să vă

asumaţi riscul că nu va apare.

• Monitorizarea riscului. În acest caz, nu luaţi măsuri pentru prevenirea riscului dar

monitorizaţi situaţia pentru a vedea dacă şansa sa de apariţie creşte pe măsură ce trece

timpul. Dacă şansa de apariţie mai târziu creşte, echipa trebuie să prevină la acel timp.

• Evitarea riscului. Evitarea riscului înseamnă eliminarea condiţiei care cauzează problema.

De exemplu, riscurile asociate cu un furnizor anume pot fi evitate dacă se foloseşte alt

furnizor.

• Mutarea riscului. În unele cazuri, responsabilitatea pentru gestionarea riscului poate fi

eliminată din proiect prin atribuirea riscului unei alte entităţi sau unei alte firme.

• Luaţi măsuri: În cele mai multe situaţii, aceasta este măsura pe care trebuie să o luaţi. Dacă

a fost identificat un risc şi sunteţi îngrijorat puteţi dezvolta un plan de prevenire pentru a vă

asigura că nu apare.

În afară de schimbarea scopului, nimic din ceea ce apare inerent nu elimină apariţia

riscurilor din proiect. Clienţii nu se aşteaptă ca un proiect să nu aibă riscuri. Ceea ce contează este

gestiunea răspunsului managementului proiectului. Dacă sunt identificate riscurile şi sunt gestionate

preventiv, proiectul are o şansă mai mare de succes. Dacă riscurile sunt ignorate, proiectul va fi

afectat negativ când riscurile devin probleme. În acel moment, vor fi mai puţine opţiuni pentru

rezolvare fără a se afecta proiectul.

7. Gestiunea comunicaţiilor

Comunicaţiile corecte dintr-un proiect sunt critice pentru gestiunea clienţilor şi a

investitorilor. Dacă nu sunt bine informaţi asupra progresului proiectului, creşte şansa de a apare

probleme datorită diferenţelor în nivelele de aşteptări. De fapt, în multe cazuri, când apar conflicte,

aceasta nu este din cauza problemei curente ci pentru că clientul sau managerul au fost luaţi prin

surpriză.

Există două nivele de comunicare în proiecte. Mai întâi, toate proiectele trebuie să comunice

starea. Al doilea, dacă proiectul este mai mare, mai complex sau mai divizat în tabere, aveţi nevoie

de un nivel al Planului de comunicare mai complex şi sofisticat.


Şedinţele operative şi rapoartele de stare

Toate proiectele au nevoie de comunicare de la echipa de proiecare la managerul de proiect

şi de la managerul de proiect la investitori. Rapoartele de stare şi şedinţele operative trebuie să facă

mai mult decât să confirme că proiectul este în calendar. Acesta este momentul în care comunicaţi

tot ceea ce credeţi că trebuie ştiut despre proiect. Trebuiesc comunicate aderenţa la bugetul şi

calendarul proiectului, realizările de la ultima perioadă raportată, realizările planificate pentru

următoarea perioadă, noile riscuri, problemele curente şi cererile de modificări.

Informaţia şi prezentarea trebuiesc făcute având în minte audienţa. Din această cauză, se

aşteaptă o şedinţă săptămânală cu echipa ce va include discuţii la un nivel suficient de larg şi

detaliat. Rapoartele de situaţie pe care le trimiteţi sponsorului şi managerilor va fi scurt şi la nivel

înalt.

Planul comunicaţiilor

Iniţiativele mari, în special acelea care cer schimbarea organizaţională, trebuie să includă un

Plan de comunicaţii, care cuprinde o abordare multilaterală a comunicaţiilor. Procesul construirii

acestui plan include definirea tuturor investitorilor, determinarea informaţiilor de care au nevoie,

efortul de a găsi căile pentru livrarea informaţiei şi deciderea unui set de moduri de comunicare ce

trebuie să acopere cât mai mulţi investitori posibili în maniera cea mai economică şi eficientă.

Depinzând de audienţă, comunicaţiile sunt într-una din aceste trei arii.

• Obligatorii. Aceasta include rapoartele de stare, rapoartele de buget, cele legale şi cererile

de audit.

• Informaţional. Aceasta este comunicaţia care oferă informaţii extinse pentru persoanele

care trebuie să ştie mai mult. Exemple sunt librăria de documente, întrebări puse frecvent

(engl. FAQ), şi un site web ce conţine informaţii relevante asupra proiectului.

• Marketing. Aceasta este comunicaţia proiectată să aducă entuziasmul în proiectul dvs.

Exemple includ descrieri ale ideilor de succes, construirea unei imagini pozitive, distribuirea

rapoartelor manageriale şi folosirea unui logo al proiectului.

Comunicaţia trebuie să fie condusă proactiv de managerul de proiect şi trebuie planificată şi

executată cu un scop. Dacă comunicaţi efectiv şi proactiv, veţi găsi că întregul proiect se desfăşoară

mai uşor şi cu mai puţine conflicte şi frustrări.


8. Managementul documentelor

Mulţi manageri de proiect nu iau în serios managementul documentelor până când nu sunt

inundaţi cu sute de documente. Este mai bine să estimaţi volumul proiectului şi să faceţi

managementul documentaţiei proiectului pentru cele ce vor fi produse de proiect, stabilirea

proceselor potrivite şi regulile de organizare a documentelor şi apoi managementul documentaţiei în

timpul desfăşurării proiectului pentru a vă asigura că acesta nu scapă necontrolat.

Managerii de proiecte mici nu au nevoie să acorde foarte multă atenţie managementului

documentelor. Pe măsură ce proiectele sunt mai mari, documentaţia trebuie să fie gestionată activ.

Problemele cele mai simple includ documentaţiile care se pierd sau care sunt greu de găsit şi munca

ce va trebui duplicată din aceste cauze. În cel mai rău caz, versiuni apar versiuni de documente care

nu mai sunt de actualitate, documente trimise de mai multe ori şi pierdute precum şi incertidudinea

conţinutului acestora.

Acest aspect al managementului proiectelor poate fi gestionat cu un program cum ar fi un

fişet cu documente. Totuşi, mijloacele tehnice pot fi tot atât de confuze dacă nu se folosesc tehnici

adecvate pentru păstrarea documentelor într-o manieră care să permită găsirea lor rapidă.

Managementul documentelor implică sarcini. O simplă activitate, de exemplu, este o

convenţie de numire a documentelor. Dacă aveţi 10 persoane în echipă şi fiecare trimite câte un

raport de stare în fiecare săptămână, în scurt timp veţi avea sute de documente. Este mai uşor să

organizaţi documentele dacă toţi folosesc o convenţie de numire. Ar trebui ca numele

documentelelor să înceapă cu prima literă a numelui fiecărei persoane? Dacă este aşa, istoricul

rapoartelor va fi mai uşor de gestionat dacă ele sunt sortate după nume. Poate doriţi să căutaţi

fiecare raport la anumite perioade de timp. În acest caz, rapoartele vor trebui să fie clasificate după

dată şi toate rapoartele de stare pentru un ciclu de raportare vor fi grupate împreună.

O altă parte a managementului documentelor este înţelegerea mijloacelor de gestionare a

documentelor pe care le veţi folosi. De exemplu, aţi putea defini Microsoft Word ca şi editor de

documente standard. Dacă echipa este formată din specialişti cu diferite specializări şi includeţi

clienţi furnizori şi vânzători, aceste tipuri de reguli ale managementului de documente devin vitale.

Pentru gestionarea cu succes a documentelor trebuie avuţi în vedere şi alţi factori. Aceştia

includ unde veţi depozita documentele, cum sunt organizate, regulile de acces şi securitate,

indexarea, standardele de denumire, starea de completare, reţinerea/distrugerea, crearea copiilor de

siguranţă şi formatele matriţă standard.


9. Managementul calităţii

Calitatea este reprezentată prin aprecierea distanţei dintre aşteptările clienţilor şi ceea ce

livrează proiectul. În alte cuvinte, calitatea este măsurată în cele din urmă de client.

Echipa de proiectare trebuie să se străduiască să atingă sau să depăşească cererile şi

aşteptările clienţilor. Câteodată există o tendinţă să se creadă că, calitatea înseamnă cele mai bune

echipamente şi zero defecte. Totuşi, în cele mai multe cazuri, clientul nu se aşteaptă şi nu îşi poate

permite o soluţie perfectă. Dacă sunt chiar şi câteva probleme în proiect, clientul poate totuşi să

afirme că proiectul a fost livrat la un nivel înalt de calitate. Pe de altă parte, un proiect fără erori, o

soluţie care nu are defecte dar nu îndeplineşte cerinţele clientului nu este considerată de înaltă

calitate. Scopul managementului calităţii este de a înţelege de prima oară aşteptările clientului în

termeni de calitate şi conceperea unui plan şi a proceselor care să respecte sau să depăşească aceste

aşteptări.

Din motivul definirii calităţii de către client, se poate avea impresia că aceasta este complet

subiectivă. Totuşi, o mulţime de factori din calitate pot fi obiectivi. Aceasta presupune ca mai întâi

să se descompună termenul generic de "calitate" într-un număr de arii care definesc caracteristicile

calităţii.

De exemplu, vă puteţi gândi la o aplicaţie software de calitate în termenii timpului de

răspuns, interfeţei grafice, uşurinţei în folosire, nivelul documentaţiei de ajutor şi lipsa defectelor.

Odată ce aţi definit caracteristici mai tangibile de calitate, vă puteţi uita la fiecare dintre ele astfel

încât să poată fi măsurate cu mai multă obiectivitate.

Managementul de calitate nu este un eveniment, este un proces şi un mod de gândire. Un

produs de înaltă calitate nu poate fi produs de un proces deficitar. Trebuie să aveţi un ciclu repetitiv

de măsurare a calităţii şi actualizare a proceselor. Colectarea metricilor este vitală în asigurarea

funcţionării procesului de management al calităţii. În acest fel, cel de-al nouălea şi al zecilea aspect

al managementului de proiect sunt strâns legate. Dacă vreţi să faceţi un bun management al calităţii,

trebuie să măsuraţi.

La definirea iniţială a proiectului, echipa de proiectare trebuie să înţeleagă aşteptările

clientului în termenii de calitate şi să îndeplinească aceste aşteptări în Planul de calitate. Planul de

calitate conţine criteriile de corectitudine şi îndeplinire pe care echipa de proiectare trebuie să le

cunoască pentru a îndeplini aşteptările de la calitate.

Planul de calitate conţine deasemeni două procese de calitate generale: controlul calităţii şi


asigurarea calităţii. Activităţile de control a calităţii asigură că ceea ce se produce prin proiect

corespunde cu aşteptările clientului. Un exemplu de activitate pentru controlul calităţii este

inspecţia fiecărei componente ce va fi folosită pentru asamblarea finală. Activităţile de asigurare a

calităţii asigură că procesele folosite pentru a produce proiectul sunt de o calitate înaltă. Un

exemplu de tehnică pentru asigurarea calităţii este un opis ce conţine toţi paşii pe care un produs

trebuie să le aibă complete înainte de a primi acceptarea finală.

Unul din scopurile managementului calităţii este de a găsi erorile şi defectele din proiect cât

mai curând posibil. Prin urmare, un proces pentru managementul calităţii va cere mai multe ore de

efort şi costuri din proiect. Totuşi, focalizarea pe calitate încă de la începutul proiectului, are un

impact masiv pe măsură ce proiectul avansează. De exemplu, este mult mai eficient să depistaţi

problemele cu privire la cereri în timpul fazei de analiză a proiectului decât să refaceţi munca pentru

a adăuga cerinţele care nu au fost îndeplinite în timpul testării produsului. Este deasemeni mult mai

ieftin să se găsească o problemă, de exemplu când se face proiectarea unui program soft decât să se

facă atunci când clientul aduce produsul pentru debug.

10. Managementul metricilor

Obţinerea metricilor dintr-un proiect este cel mai sofisticat proces de management al

proiectului şi poate fi cel mai dificil. Din cauză că metricile pot fi dificil de definit şi colectat, ele

sunt de obicei ignorate sau gestionate insuficient. Toate proiectele ar trebui să adune informaţii de

bază asupra costului, efortului şi timpului. Totuşi, trebuie să se colecteze deasemeni date pentru a

determina modul în care produsele satisfac aşteptările clienţilor şi cât de bine funcţionează

procesele interne de livrare din proiect. În funcţie de rezultate, puteţi face acţiuni corective sau

activităţi de îmbunătăţire a activităţilor pentru a face procesele mai eficiente.

Gestionarea metricilor şi managementul calităţii sunt strâns corelate. Este dificil să

îmbunătăţiţi calitatea produselor sau proceselor dacă nu aveţi cu ce să le măsuraţi. Metricile sunt

folosite pentru a oferi o oarecare indicaţie pentru începerea stadiului de calitate şi a verifica dacă

calitatea creşte sau scade.

Pentru un proiect pot fi adunate multe măsurători. Echipa de proiectare trebuie să identifice

şi să colecteze un set echilibrat care să asigure cea mai mare valoare. Pentru a determina

măsurătorile corecte pentru proiect trebuie să:

• Identificaţi criteriile de succes ale proiectului în termeni de produse livrate şi execuţia


proiectului. Adică să determinaţi la ce trebuie să vă uitaţi pentru ca proiectul să fie de succes.

Deasemeni trebuie să determinaţi cum trebuie să fie completat proiectul pentru a fi de

succes, de exemplu respectarea bugetului şi termenul de livrare.

• Străduiţi-vă să găsiţi un set de măsurători care să asigure o indicaţie pentru starea fiecărui

criteriu de succes.

• Căutaţi un set balansat de metrici care asigură indicaţiile succesului în termenii de cost,

livrare, calitate şi satisfacţia clientului.

• Daţi prioritate metricilor care aduc o listă ce asigură cea mai mare valoare în cea mai puţin

costisitoare manieră.

• Fixaţi-vă ţintele pentru a putea determina succesul. Măsurătorile sunt de foarte puţine ori

valoroase în sine. Valoarea vine din compararea stării preferate sau cu care s-a ajuns la un

acord cu ţinta actuală.

• Adăugaţi o colecţie de activităţi pentru a vă asigura că persoanele răspund de colectarea

măsurătorilor şi analiza proceselor.

În general, managementul metricilor este de mai mică valoare în proiectele mici deoarece nu

este timp suficient pentru colectarea datelor, analiza rezultatelor şi execuţia schimbărilor potrivite

pentru îmbunătăţiri. Proiectele mai lungi vă dau timp să faceţi o buclă de răspuns. Cea mai mare

valoare este obţinută când măsurătorile sunt folosite pentru a conduce îmbunătăţirile la un nivel de

firmă.


Concluzii

Natura managementului proiectelor pentru producţie software este diferit de managementul

pentru proiectele ce conţin componente fizice din cauza naturii diferite a software-ului însuşi.

Produsele software sunt în general mult mai complexe decât calculatoarele pe care rulează.

Problemele prea complexe sau prea costisitoare care trebuiesc rezolvate electronic sunt

transmise software-ului de suport - poziţionarea rotorului pentru un motor pas cu pas, poziţionarea

carului la o imprimantă liniară, poziţionarea unui satelit în direcţia unei stele, etc. Nu există o bază

pentru procesul de producţie. Procesul de dezvoltare se termină cu livrarea la utilizator. Problemele

sunt descoperite în general în timpul producerii şi trebuie să fie găsite în acest timp. Inspecţiile

(reviziile) care fac parte în mod normal din procesul de producţie au fost mutate în faza de

dezvoltare.

Dezvoltarea produselor software necesită mai multe planuri dintre care unele nu există în

alte tipuri de proiecte:

• Planul principal al programului

• Planul de management

• Planul de dezvoltare

• Planul de management al configuraţiei

• Planul de asigurare a calităţii

• Planul de întreţinere

• Planul de testare

• Planul de integrare

• Planul de documentaţie

• Planul de tranziţie la o nouă versiune

• Planul de dezvoltare dispozitive hardware

Deoarece software-ul produce frecvent interfaţa cu utilizatorul, orice frustrare cu privire la

sistem tinde să se focalizeze pe software. Ca rezultat, pot fi schimbate frecvent cerinţele pentru

produsul software.


Iată motivele principale pentru eşecurile proiectelor software

Motiv Procent

Lipsa informaţiilor de la utilizator 12,8%

Cerinţe şi specificaţii incomplete 12,3%

Schimbarea cerinţelor şi specificaţiilor 11,8%

Lipsa suportului executivului 7,5%

Incompetenţă tehnologică 7,0%

Lipsa resurselor 6,4%

Cerinţe nerealiste 5,9%

Obiective neclare 5,3%

Perioade de timp nerealiste 4,3%

Tehnologii noi 3,7%

Altele 23.00%

Se pare că cei mai mulţi consideră că este mai ieftin să se schimbe software-ul decât

hardware-ul, aceste cerinţe de modificare sfârşesc prin a face modificări numai în software, ceea ce

este de obicei o eroare în cazul dispozitivelor complexe.

Pentru rezolvarea problemelor importante de software se folosesc un mare număr de

programatori, adeseori distribuiţi geografic. Aceasta cere un mecanism de comunicaţii extensiv

pentru finalizarea produsului software.

De multe ori inginerii software nu deţin cunoştinţele necesare pentru a înţelege pe deplin

cerinţele. De obicei nu există nici o cale de a afla cât timp este necesar pentru a acumula aceste

cunoştinţe. Ca rezultat, este dificil să se planifice, estimeze mărimea, schimba sau produce software.

Pentru a face lucrurile şi mai dificile, de obicei nu există o disciplină riguroasă în procesul

de dezvoltare şi documentaţie asociat cu proiectele software mici. Multe proiecte software ample

sunt în aceeaşi situaţie dar ele sunt deteriorate şi mai mult de complexitatea organizaţiei, în plus faţă

de complexitatea produsului. Aceasta este de obicei adevărat pentru proiecte mari, dar dezvoltarea

software are dezavantaje suplimentare. Sunt puţine unelte disponibile pentru a ajuta la dezvoltarea

software iar profesia nu este matură la acelaşi nivel ca în alte discipline inginereşti

Obiectivele cheie ale managementului efectiv

Un manager pentru proiecte software trebuie să aibă în minte calitatea, productivitatea şi

reducerea riscurilor în tot timpul planificării şi execuţiei produsului dezvoltat.

a. Calitatea

Calitatea se obţine cel mai uşor prin aderarea la standarde şi tehnici eficiente de dezvoltare şi


revizuirea tehnică periodică prin procesul de management. Japonezii pun un mare accent pe

asigurarea continuă a îmbunătăţirii calităţii şi de aici rezultatele remarcabile ce oferă lecţii

importante pentru dezvoltatorii de software.

b. Productivitatea

Creşterea productivităţii scade costurile. În stadiul actual al tehnologiei de dezvoltare, cel

mai important factor de creştere a productivităţii este abilitatea personală a inginerilor software,

uneltele cu care ei dezvoltă şi mediul de lucru.

c. Reducerea riscurilor

Managerii trebuie să identifice cele mai dificile părţi ale dezvoltării şi să aducă soluţiile cele

mai eficiente. Cerinţele care pot bloca proiectul trebuie să fie abordate cât mai devreme în proces.

Rolul managerului de proiect software

Rolul "manager-ului" este de a planifica, organiza, direcţiona şi controla. El sau ea folosesc

idei, lucruri şi oameni. Totuşi în dezvoltarea software, implică mai multă creativitate planificată

decât în alte domenii.


Bibliografie

1. James E. Tomayko (The Wichita State University),

Harvey K. Hallman (Software Engineering Institute) - Software Project Management -

SEI-CM-21-1.0 - Iulie 1989

2. Margo Visitacion (Giga Information Group, Inc.) - Project Management Best Practices: Key

Processes and Common Sense - Ianuarie 2003

3. Andrew Stellman, Jennifer Greene - Applied Software Project Management - Noiembrie

2005

4. Duncan Haughey (PMP) - Why Software Projects Fail and How to Make Them Succeed -

Februarie 2010

5. Standish Group - Chaos Report 2009


cuprins -...

Documents