IMPACTUL CALITATII ASUPRALOR

IMPACTUL CALITATII ASUPRALOR

Managementul calitatii proiectului include procesele necesare pentru asigurarea ca proiectul va satisface cerintele pentru care a fost lansat. Managementul calitatii proiectului include toate functiile de management care determina politica de calitate, obiectivele si responsabilitatile aferente proiectului si se realizeaza prin planificarea calitatii, asigurarea calitatii, controlul calitatii, imbunatatirea calitatii, cuprinse in sistemul calitatii. Procesele majore ale managementului calitatii proiectului sunt puse in evidenta in figura 1

Figura 1 Vedere generala asupra proceselor majore ale managementului calitatii proiectului

Asa cum rezulta si din figura mai sus prezentata, managementul calitatii proiectului, prezinta patru componente distincte, fiecare dintre acestea fiind structurate pe: date de intrare, instrumente si tehnici de realizare a etapei calitative respective, resurse, precum si rezultatele finale, ce sunt prezentate sub forma unor date de iesire.

Aceste patru procese interactioneaza atat intre ele cat si cu celelalte procese ale managementului proiectului. Fiecare proces impune eforturi din partea unuia sau a mai multor membri ai echipei, sau a altor structuri organizationale, in functie de necesitatile proiectului. Fiecare proces se regaseste cel putin o data in fiecare faza (etapa) a proiectului. Desi procesele sunt prezentate ca elemente distincte, cu interfete clar definite, in practica ele pot interactiona unele cu altele. Structura de baza a managementului calitatii proiectului este astfel realizata incat asigura compatibilitatea cu seria de standarde internationale ISO 9000 si ISO 10000, cu recomandarile initiatorilor proceselor de management al calitatii (Deming, Juran, Crosby si altii), precum si cu dezvoltarile ulterioare (TQM - managementul calitatii totale, cresterea continua a calitatii).

Managementul calitatii proiectului se adreseaza atat managementului proiectului propriu-zis cat si produsului /serviciului rezultat din proiect. Termenul de "produs" este generic utilizat in literatura referitoare la calitate, el referindu-se atat la produse cat si la servicii.

Absenta cerintelor de calitate, in fiecare faza a proiectului, poate avea consecinte negative asupra partenerilor implicati in proiect.

De exemplu :

     Modificarile cerintelor clientului / utilizatorului proiectului, prezentate pe parcursul executiei proiectului, in reuniunile (sedintele) de faza, pot avea consecinte negative in sensul cresterii sarcinilor echipei de proiect.

     Devansarea inspectiilor de calitate planificate, stabilite in cadrul reuniunilor de modificare a duratelor de realizare a obiectivelor intermediare, poate avea consecinte negative prin aparitia unor erori neprevazute.

Un aspect critic in managementul calitatii proiectului il reprezinta necesitatea ca obiectivele stabilite ale proiectului, prezentate in scopului proiectului, sa raspunda necesitatilor implicite si explicite ale clientului / utilizatorului.

Echipa de proiect nu trebuie sa confunde "calitatea" cu "clasa". Clasa reprezinta o treapta sau un grad dat unor entitati care au functionalitati (utilizari) comune dar au caracteristici tehnice diferite.

Calitatea slaba este intotdeauna o problema. Clasa inferioara poate sa nu fie. De exemplu, un produs software poate fi de calitate superioara (fara defecte evidente) dar de clasa inferioara (cu numar limitat de caractere) sau poate fi de slaba calitate (defecte evidente numeroase, utilizare greoaie) si de clasa superioara (multiple caracteristici). Determinarea si stabilirea nivelelor cerute atat de calitate cat si de clasa reprezinta responsabilitatea atat a managerului de proiect cat si a echipei pe care acesta o coordoneaza.

Echipa de proiect trebuie, de asemenea, sa constientizeze faptul ca un management modern al calitatii completeaza managementul proiectului. De exemplu, ambele discipline recunosc importanta:

    Satisfactiei clientului /utilizatorului - intelegerea, specificarea si influentarea necesitatilor astfel incat ele sa raspunda asteptarilor acestuia. Acest lucru reprezinta conformitatea produsului cu cerintele proiectului, care trebuie sa realizeze ceea ce s-a stabilit sa realizeze si sa satisfaca necesitatile reale ale clientului / utilizatorului).

    Actiunilor de prevenire, mai mult decat a acelora de corectie - costul actiunilor de prevenire a unor greseli este intotdeauna mai mic decat costul corectarii lor.

    Responsabilitatea managementului - realizarea fazelor proiectului presupune participarea intregii echipe, dar responsabilitatea managementului presupune planificarea si estimarea resurselor necesare pentru realizarea fazelor.

    Similaritatea proceselor proiectului cu fazele acestuia - ciclul repetabil Plan-Do-Check-Act, descris de Deming si dezvoltat ulterior, este similar atat pentru faze cat si pentru procese.

In plus, calitatea presupune atat cresterea calitatii managementului proiectului cat si cresterea calitatii produsului rezultat.

Totusi exista o limitare in abordarea managementului calitatii, de care echipa de proiect trebuie sa tina seama. Durata limitata de realizare a proiectului presupune limitarea investitiilor in cresterea calitatatii produsului, mai ales in prevenirea aparitiei defectelor si in evaluarea lor.

Planificarea calitatii presupune identificarea standardelor de calitate, relevante pentru proiect si determinarea modalitatilor de satisfacere a acestora. Este una dintre cheile proceselor ajutatoare ale planificarilor proiectului. Poate fi realizata in mod regulat sau in paralel cu alte procese de planificare. De exemplu, schimbarile cerute asupra produsului necesita stabilirea standardelor de calitate aferente si poate necesita ajustari de costuri pe parcursul fazelor proiectului, sau calitatea dorita a produsului poate necesita o analiza de risc pentru identificarea problemelor ce pot apare la realizarea proiectului.

Realizarea activitatilor care dezvolta cu prioritate seria de standarde ISO 9000 sunt detaliate in procesul de asigurare a calitatii.

Tehnicile de planificare a calitatii sunt, in cea mai mare parte, cele utilizate in planificarea proiectului.

Echipa de proiect trebuie sa respecte una din axiomele fundamentale ale managementului modern al calitatii - calitatea se planifica, nu se controleaza.

A. Intrari ale procesului de planificare a calitatii

Politica de calitate. Reprezinta intentiile si directiile generale ale organizatiei in ceea ce priveste calitatea, exprimate de conducerea acesteia. Politica de calitate adoptata de proiect poate fi cea a organizatiei pentru ca aceasta este. In cazul realizarii proiectului prin participarea mai multor organizatii, echipa de proiect isi defineste propria politica de calitate. Echipa de proiect este responsabila de asigurarea ca partenerii implicati in proiect sunt constienti de politica de calitate adoptata.

Obiectivele stabilite. Stabilirea obiectivelor reprezinta cheia intrarilor in procesul de planificare a calitatii. Obiectivele stabilite inca de la initierea proiectului trebuie sa serveasca definirii necesitatilor partenerilor implicati.

Descrierea produsului Descrierea produsului contine detalii si caracteristici tehnice care ajuta la stabilirea obiectivelor si care pot afecta planificarea calitatii.

Standarde si reglementari. Echipa de proiect trebuie sa ia in considerare standardele si reglementarile relevante pentru proiect pentru ca acestea pot afecta calitatea acestuia.

Iesirile altor procese Alaturi de obiectivele proiectului si de descrierea produsului si iesirile altor procese pot fi integrate in planificarea calitatii. De exemplu, planificarea aprovizionarii poate identifica cerintele de calitate impuse furnizorului, cerinte ce sunt reflectate in planificarea calitatii.

B. Instrumente si tehnici ale procesului de planificare a calitatii

Analize beneficiu / cost. Analizele beneficiu / cost presupun estimarile costurilor si beneficiilor tangibile si intangibile ale diferitelor variante de proiect, utilizand instrumente financiare cum ar fi: durata de recuperare a investitiei, valoarea neta actualizata a investitiei, rata interna de rentabilitate. Aceste analize sunt utile pentru evaluarea proiectului si identificarea alternativelor. Cel mai important beneficiu al stabilirii cerintelor de calitate il reprezinta efortul corectiv mai mic, productivitate mai mare, costuri de realizare a proiectului mai mici, satisfactie din partea partenerilor. Cel mai important cost se refera la cheltuielile asociate activitatilor de management al calitatii. Managementul calitatii nu se obtine fara costuri.

Benchmarking. Benchmarking-ul este o metoda de management care presupune compararea proiectului actual cu practicile similare din alte genuri de proiecte, din organizatie sau din afara ei, avand ca scop gasirea de solutii si stabilirea standardelor de masura a performantelor.

Diagrame de fluxuri. Diagrama de flux prezinta, grafic, cum variaza, in timp, sistemul de resurse analizat. Tehnicile cele mai comune utilizate in managementul calitatii, pentru reprezentarea grafica a fluxurilor, includ:

      Diagrama cauza - efect, numita si diagrama Ishikawa. Aceasta tehnica permite identificarea cauzelor succesive ale aparitiei unei "probleme". Un exemplu generic de diagrama este prezentat in figura 14.

Diagramele de fluxuri ajuta echipa de proiect pentru a prevedea ce si unde pot apare probleme de calitate in evolutia proiectului si ajuta la gasirea de solutii pentru anularea lor.

Figura 14. Diagrama cauza-efect

Simulari Simularea este o metoda statistica care ajuta la identificarea factorilor care pot influenta variabilele specifice ale proiectului. Tehnica este aplicata cel mai mult asupra produsului proiectului.

Costul calitatii. Costul calitatii se refera la costul total al eforturilor pentru realizarea calitatii produsului si include toate activitatile care asigura atat conformitatea cat si neconformitatea produsului. Costul calitatii cuprinde trei tipuri de costuri: costuri de prevenire, costuri de evaluare, costuri datorate omisiunilor.

C. Iesiri ale procesului de planificare a calitatii

Planul de management al calitatii Echipa de proiect trebuie sa prezinte, prin planul de management al calitatii, modalitatile de implementare a politicii de calitate. Sistemul calitatii proiectului, conform ISO 9000, cuprinde: "structura organizatorica, responsabilitati, proceduri, procese si resurse necesare pentru implementarea managementului calitatii". Planul de management al calitatii are ca intrari rezultatele (iesirile) tuturor proceselor de planificare si este orientat spre controlul calitatii, asigurarea calitatii si cresterea calitatii proiectului. Planul de management al calitatii poate fi formal sau informal, detaliat sau doar schematic, in functie de cerintele proiectului.

Definirea specificatiilor de calitate. Specificatiile de calitate descriu, in termeni specifici, domeniile si limitele procesului de control al calitatii. De exemplu, planificarea duratei unei activitati nu este suficienta din punct de vedere al managementului calitatii. Echipa de proiect trebuie sa indice si data de inceput si de sfarsit a acesteia daca activitatea va fi masurata sau doar anumite rezultate ale ei si care anume.

Liste de control. Lista de control este un instrument utilizat la verificarea si controlul realizarii activitatilor. Poate fi simpla sau complexa, in functie de specificul proiectului. Ea realizeaza legatura dintre rezultatele trecute si rezultatele viitoare, este un mijloc de apreciere si corectie a performantelor proiectului.

Intrari pentru alte procese. Procesul de management al calitatii poate identifica necesitatile pentru realizarea altor activitati cuprinse in celelalte procese de management.

Asigurarea calitatii cuprinde evaluarea si demonstrarea ca toate activitatile planificate si realizate in sistemul calitatii satisfac standardele si reglementarile de calitate ale proiectului. Toate activitatile incluse in planul de management al calitatii fac parte integranta din sistemul de asigurare a calitatii.

Asigurarea calitatii este deseori realizata de un compartiment specializat al organizatiei dar nu este obligatoriu. Poate fi realizata de echipa de proiect, in interiorul organizatiei din care face parte (asigurare interna a calitatii) sau de catre clienti sau colaboratori neimplicati in proiect (asigurare externa a calitatii).

A. Intrari ale procesului de asigurare a calitatii

Planul de management al calitatii. Planul de management al calitatii este descris in cadrul subcapitolului anterior, punctul C.

Rezultatele controlului calitatii. Rezultatele controlului calitatii reprezinta inregistrarile incercarilor, verificarilor si masuratorilor realizate, in format comparabil (valori comparabile) pentru realizarea evaluarilor.

Definirea specificatiilor de calitate. Specificatiile de calitate sunt descrise in subcapitolul anterior, punctul C.

B. Instrumente si tehnici pentru asigurarea calitatii

Instrumente si tehnici de asigurare a calitatii. Instrumentele si tehnicile de planificare a calitatii descrise anterior pot fi utilizate si pentru asigurarea calitatii.

Audituri ale calitatii. Auditul calitatii este o evaluare facuta asupra activitatilor de management al calitatii realizate (fie in acelasi proiect fie in altele), in vederea imbunatatirii performantelor proiectului actual. Poate fi planificat sau realizat ori de cate ori este necesar. Poate fi realizat de auditori interni sau externi ai organizatiei.

C. Iesiri ale procesului de asigurare a calitatii

Imbunatatirea calitatii. Imbunatatirea continua a calitatii include actiuni de crestere a eficacitatii si eficientei proiectului in vederea obtinerii de beneficii pentru parteneri si satisfactie pentru utilizator. Implementarea cresterii calitatii necesita actiuni preventive si corective, conform procedurilor de control stabilite in planul de executie a proiectului.

Controlul calitatii implica monitorizarea rezultatelor specifice ale proiectului in vederea masurararii conformitatii lor cu standardele si reglementarile de calitate de referinta si identificarea cailor de eliminare a cauzelor de neconformitate.

Controlul calitatii se realizeza pe intreg parcursul executiei proiectului. Rezultatele monitorizate se refera atat la performantele produsului cat si la rezultatele managementului proiectului. Poate fi coordonat de un compartiment specializat al organizatiei din care face parte echipa de proiect sau chiar de catre aceasta. Echipa de proiect trebuie sa posede cunostinte de control statistic al calitatii sa fie capabila sa utilizeze notiuni ca:

           Prevenire (impiedicarea aparitiei erorilor in executia proiectului) si inspectie (impiedicarea detectarii erorilor de catre client).

           Caracteristici de referinta (rezultate statice fata de care se compara conformitatea) sau variabile de referinta (rezultate ce evolueaza continuu si fata de care se masoara gradul de conformitate).

           Evenimente aleatoare (evenimente neobisnuite) si evenimente previzionate (variatii normale ale proceselor proiectului).

           Tolerante (intervale limita de conformitate).

A. Intrari ale controlului calitatii

Rezultatele activitatilor. Rezultatele activitatilor, incluse in planul de executie a proiectului, cuprind atat performantele produsului cat si rezultatele proceselor de management a proiectului. Rezultatele planificate trebuie sa fie disponibile pe tot parcursul executiei proiectului pentru compararea cu rezultatele obtinute sau in curs de realizare.

Planul de management al calitatii. Este descris in subcapitolul 1.2, punctul C.

Definirea specificatiilor de calitate. Specificatiile de calitate sunt descrise in subcapitolul 1.2, punctul C.

Liste de control. Listele de control sunt descrise in subcapitolul 1.2, punctul C.

B.Instrumente si tehnici pentru controlul calitatii

Inspectii. Inspectiile includ activitati precum masurare, examinare si testare in vederea stabilirii conformitatii rezultatelor proiectului cu cerintele acestuia. Inspectiile pot fi realizate la orice nivel (rezultatele unei singure activitati sau rezultatele produsului final).

Diagrame de control. Diagramele de control (figura 15) reprezinta vizualizarea grafica, in timp, a rezultatelor produsului sau proceselor. Sunt utilizate pentru stabilirea momentului in care procesul este in control (apar erori previzionate sau aleatoare). Atunci cand procesul este in control el nu trebuie adaptat. El poate fi schimbat, in vederea imbunatatirii calitatii lui, dar nu trebuie adaptat in timpul procesului de control.

Diagramele de control pot fi utilizate pentru monitorizarea diferitelor variabile de iesire. Cel mai frecvent sunt utilizate pentru activitati repetitive, costuri sau variante de termene, erori in documentatii.

Figura 15. Diagrama de control pentru o caracteristica programata

Figura 15 prezinta o diagrama de control pentru o caracteristica programata.

Axa reprezinta axa timpului. Exista trei linii ale diagramei de control:

I. Linia X, centrala, reprezinta media performantelor inregistrate;

II. Linia superioara reprezinta limita maxima de abatere admisa, fata de care se poate masura varianta;

III. Linia inferioara reprezinta limita minima de abatere admisa, sub care caracteristica este neconforma sau procesul este instabil.

Diagrame Pareto. Principiul acestei tehnici consta in izolarea a 20% din parametrii unei activitati care explica 80% din problemele acesteia (figura 16). Este o metoda de decizie si control care permite utilizarea prioritatilor dupa diferite criterii, folosind statistici descriptive si analizarea lor. Ea ajuta la conducerea interventiilor in mod metodic abordand succesiv punctele cele mai importante. Ea permite, deci, stabilirea unui plan de actiune eficient.

Esantionare statistica Esantionare statistica presupune alegerea unor categorii de activitati sau procese reprezentative, din lista completa, pentru inspectie. Acest tip de selectie reduce costurile controlului calitatii.

Diagrame de fluxuri. Diagramele de fluxuri sunt prezentate in subcapitolul 1.2, punctul B. In cadrul acestui proces ajuta la analizarea cauzelor aparitiei disfunctionalitatilor.

Analize de trend. Analizele de trend folosesc tehnici matematice si vizeaza evolutiile strict cantitative ale rezultatelor. Ele se bazeaza pe o extrapolare a datelor din trecut spre viitor. Sunt utilizate pentru monitorizarea:

     Performantelor tehnice - cate erori sau defecte au fost identificate si cate au ramas necorectate.

     Costul si programarea activitatilor - cate dintre activitatile dintr-o anumita perioada au fost realizate cu abateri semnificative.

Figura 16. Diagrama Pareto

Tehnica Brainstorming. Tehnica Brainstorming (in traducere "cascada ideilor" sau "asaltul creierului") este o tehnica ce isi propune simularea emisiei de idei a unui grup pluridisciplinar pentru rezolvarea unei probleme. Grupul reuneste de la 3 pana la 10 persoane solicitate sa rezolve o problema despre care nu au fost informate in prealabil. Numarul optim este de 5 sau 6 membri. Tehnica se desfasoara sub forma unei sedinte, a carei durata optima este de 30-40 minute.

Principiile metodei sunt:

     Cantitatea poate genera calitate. Dat fiind faptul ca intr-o sedinta sunt emise un numar mare de idei (intre 30 si 200), exista de cele mai multe ori sansa ca ideea care va duce la rezolvare sa fie printre cele emise.

     Critica sau evaluarea nu este admisa in timpul sedintei. Datorita acestui fapt varietatea de idei creste, ca si neconventionalitatea lor.

     In grup se creeaza efectul de "reactie in lant". O idee a unui participant (chiar daca este ridicola, absurda, total nepractica etc.) prin procedeul asocierii (sau prin alt procedeu de creatie) genereaza o alta idee altui participant sau chiar celui ce a emis-o s.a.m.d.

Evaluarea si selectarea ideilor se face ulterior, de un grup restrans de specialisti, retinandu-se solutiile mai valoroase cu un grad mare de aplicabilitate. Statisticile au aratat ca dintre ideile emise prin tehnica Brainstorming, 20% sunt aplicabile iar cca 4% sunt de o certa valoare.

C. Iesiri ale controlului calitatii

Imbunatatirea calitatii. Cresterea calitatii este prezentata in subcapitolul 1.3, punctul B.

Elaborarea deciziilor. Componentele neconforme ale activitatilor sau proceselor, identificate in timpul inspectiilor, pot fi acceptate sau eliminate. Componentele eliminate presupun aplicarea de activitati corective.

Corectii. Corectiile sunt actiuni de eliminare a neconformitatilor. Ele intra in categoria activitatilor neprevazute si reprezinta una dintre cauzele cele mai frecvente de nerespectare a termenilor proiectului. Echipa de proiect trebuie sa depuna eforturi pentru minimizarea acestor tipuri de activitati.

Completarea listelor de control. Listele de control, prezentate in subcapitolul 1.2, punctul C, odata completate, devin baza de inregistrari si de informatii pentru proiect.

Procese de ajustare. Procesele de ajustare presupun actiuni preventive si corective imediate, ca urmare a rezultatelor controlului calitatii. In unele cazuri, aceste procese se desfasoara o data cu procesele de control integrat al proiectului.

Standardele ISO prezinta ca parti distincte ale managementului calitatii proiectelor asigurarea calitatii proiectelor si imbunatatirea calitatii proiectelor. Imbunatatirea calitatii proiectelor este partea managementului calitatii proiectului ce se concentreaza pe cresterea abilitatii proiectului de a indeplini cerinte ale calitatii.

In opinia mea, asigurarea calitatii proiectului, respectiv imbunatatirea calitatii proiectului reprezinta doua secvente interdependente ale conducerii proiectului, ce reflecta satisfacerea cerintelor referitoare la calitate identificate la un moment dat, respectiv trecerea la un nivel nou de performanta pentru o mai buna satisfacere a asteptarilor. Astfel, imbunatatirea calitatii proiectului apare ca finalitate a unui ciclu de actiuni initiate pentru rezolvarea unor probleme de calitate.

Realizarea acestui proces se bazeaza pe folosirea unor instrumente specifice. O importanta deosebita o au planurile de actiune PDCA, cunoscute si sub denumirea de "ciclul Deming" (sau "roata lui Deming"). PDCA (Plan-Do-Check-Act) sugereaza ca pentru a imbunatati calitatea, ciclul Planifica-Executa-Verifica-Actioneaza trebuie reluat mereu.

Roata lui Deming prezinta succesiunea activitatilor pentru imbunatatire evidentiind faptul ca este esential sa se evalueze corect realitatea inainte de a efectua imbunatatiri. In cadrul organizatiilor care si-au creat sisteme de management al calitatii acest mecanism se aplica in toate domeniile de activitate, nu numai in domeniul managementului proiectelor, parcurgandu-se cele patru faze astfel:

     Planificarea actiunilor, stabilirea unor indicatori de control (plan).

     Transformarea planului in actiuni individuale (do).

     Monitorizarea actiunii, colectarea de informatii cu privire la performantele realizate (check).

     Analiza abaterilor, identificarea cauzelor si stabilirea corectiilor (act).

Munca in echipa, metodele de analiza si de creativitate, dar mai ales formarea unei atitudini favorabile imbunatatirii, astfel incat aceasta sa devina o stare de spirit a fiecarui lucrator, sunt elemente specifice managementului calitatii in general, si ale managementului calitatii proiectelor in particular, de care depinde succesul acestor actiuni.

Rezultatele cercetarilor grupului Standish sunt cele mai citate statistici in industria de IT si au avut si efecte, inclusiv schimbari guvernamentale majore. [CHR 04] Cercetarea cumulata prezinta date prelevate, pe perioada unei decade, despre cauzele ce duc la esecul proiectelor: 50.000 de proiecte IT terminate, plus 450 de workshop-uri, focus grupuri si sesiuni de terapie ale grupurilor de proiect pentru a crea contextul calitativ pentru rezultatele studiilor.

Grupul Standish a realizat mai multe studii ce s-au concluzionat prin rapoarte. Dintre acestea cele mai importante sunt:

      "CHAOS" in 1995.

      "CHAOS: A Recipe for Success" in 1999.

      "EXTREME CHAOS" in 2001.

      "2004 THIRD QUARTER RESEARCH REPORT".

Toate rapoartele CHAOS s-au concentrat consecvent pe identificarea:

       Scopului proiectelor software esuate.

       Factorii principali ce au cauzat esuarea proiectelor software.

       Ingredientele cheie ce pot reduce numarul proiectelor esuate.

Rezultatele cercetarilor CHAOS dau o vedere globala asupra statisticilor de proiect, dar au tendinta sa se concentreze mai mult spre Statele Unite si Europa:

      58% dintre respondenti sunt din SUA,

      27% dintre respondenti sunt europeni,

      doar 15% reprezinta restul tarilor lumii.

"In USA se cheltuiesc mai mult de 275 bilioane de dolari in fiecare an pentru dezvoltarea de aplicatii IT prin aproximativ 200.000 de proiecte." [CHR 99] "Costul mediu pentru un proiect de dezvoltare pentru o companie mare este de 2.322.000 , pentru o companie medie este de 1.331.000$, iar pentru o companie mica este de 434.000 . Multe dintre aceste proiecte vor esua. Proiectele de dezvoltare a softurilor sunt in haos." [CHR 95]

Cercetarea grupului Standish arata ca un zguduitor procent de 31,1% din proiecte au fost contramandate inainte de a fi terminante. Alte rezultate indica ca 52,7% din proiecte costa 189% din estimarea lor originala. Costurile oportunitatii pierdute nu sunt masurabile, dar s-ar putea usor estima la tilioane de dolari.

Pe baza acestei cercetari, grupul Standish estimeaza ca in anul 1994 companiile americane si agentiile guvernamentale au cheltuit 81 bilioane de dolari pentru proiectele de software contramandate. Aceleasi organizatii au platit inca 59 de bilioane de dolari pentru proiectele de software ce au fost duse la bun sfarsit, dar depasesc estimarile originale de timp. Factorul de risc intotdeauna va exista in cazul dezvoltarii de noi softuri, dar multe dintre aceste proiecte sunt banale, cum ar fi crearea unei baze de date pentru carnetele de conducere sau un nou pachet de contabilitate.

Media proiectelor software ce sunt terminate la timp si in buget este de 16,2%. In companiile mari, procentul este si mai scazut: doar 9% din proiectele lor sunt terminate in timp si in bugetul planificat. Si chiar si atunci cand aceste proiecte sunt terminate, multe dintre ele nu sunt decat simple umbre ale cerintelor originale specificate. Proiectele terminate de cele mai mari companii americane detin doar aproximativ 42% din caracteristicile si functiile original propuse, in timp ce companiile mai mici o duc mai bine. Un total de 78,4% dintre proiectele de software vor fi derulate cu cel putin 74,2% din caracteristicile si functiile lor originale.

Aceste date sunt descurajatoare, dar de fapt 48% dintre directorii IT executivi, ce au facut parte din esantionul cercetarii, cred ca actual exista mai multe esecuri decat acum 5 ani. Vestea buna este ca peste 50% cred ca in ziua de azi exista mai putine esecuri sau numarul lor este acelasi cu cel inregistrat cu 5, 10 ani in urma.

Studiul facut de grupul Standish a fost cat se poate de minutios. Rezultatele se bazeaza pe ceea ce grupul Standish defineste ca "constatari cheie" ale studiului de cercetare si pe cateva interviuri personale. Respondentii au fost manageri executivi IT. Esantionul a inclus companii mari, medii si mici din principalele segmente industriale: bancare, asigurari, industria manufacturiera, vanzare en-detail si en-gros, sanatate, servicii si organizatii locale, de stat si federale. Dimensiunea esantionului in 1994 a fost de 365 de respondenti, ce reprezentau 8380 de aplicatii. In plus, grupul Standish a condus 4 focus groups si numeroase interviuri personale pentru a crea contextul calitativ pentru rezultatele studiului.

Pentru a atinge scopul studiului, proiectele au fost clasificate in 3 tipuri in functie de gradul de reusita: [CHR 95]

     Tipul 1 sau proiect reusit: Proiectul a fost terminat in timp si in buget, cu toate caracteristicile si functiile specificate initial.

     Tipul 2 sau proiect incercat (provocat): Proiectul a fost terminat si este operational, dar a depasit timpul si bugetul estimat si are mai putine caracteristici si functii decat a fost original specificat.

     Tipul 3 sau proiect contramandat: Proiectul este anulat intr-un anumit moment din derularea sa.

In total, rata de succes (de reusita) a fost doar de 16,2%, in timp ce procentul proiectelor incercate s-a ridicat la 52,7% si cel al proiectelor contramandate la 31,1%.

Grupul Standish a segmentat mai departe aceste rezultate pe companiile mari, medii si mici. O companie mare este orice companie cu cifra de afaceri peste 500 milioane dolari pe an, o companie medie este definita ca avand o cifra de afaceri intre 200 milioane de dolari si 500 milioane dolari pe an, iar o companie mica inregistreaza o cifra de afaceri cuprinsa intre 100 milioane de dolari si 200 milioane de dolari. Astfel:

     45% dintre companii sunt considerate ca fiind de tipul Fortuna 1000 (mari);

     35% dintre companii sunt medii;

     20% dintre companii sunt mici. [CHR 04]

Cercetarea include proiecte de diferite tipuri impartite in categoriile prezentate in tabelul urmator.

Tabelul 15. Repartizarea proiectelor incluse in cercetare pe categorii [CHR 04]

Procentul de esec determinat este in mod egal descurajator atat pentru companiile mari, cat si pentru cele medii si mijlocii (tabelul 16).

Tabelul 16. Ratele de reusita/insucces repartizate in functie de dimensiunea companiilor

Studiul pe o durata de 11 ani a grupului Standish arata o imbunatatire in managementul proiectelor IT (figura 17).

Figura 17. Gradul de reusita al proiectelor (1994-2004) [CHR 04]

Figura 17 arata ca ratele de succes (reusita) sunt in crestere. Acest grafic descrie gradul de reusita a 50.000 de proiecte de aplicatii derulate in companii mari, medii si mici testate de grupul Standish din 1994 pana in prezent.

Reincepute

Una din principalele cauze ale depasirii bugetului si timpului alocat este reinceperea proiectului. Pentru fiecare 100 de proiecte incepute, exista 94 de reinceperi. Aceasta nu inseamna ca 94 din 100 vor avea un nou reinceput, unele proiecte pot avea mai multe.

Depasierea bugetului planificat

In cazul proiectelor de tipul 2 si 3, cumulat in anul 1994 aproape o treime au depasit bugetul cu 150 pana la 200%.

Tabelul 17. Depasirea bugetului planificat

Media depasirii costului a scazut semnificativ de la 189% in anul 1994 (tabelul 17), pana la 45% in anul 2004. Rezultatele studiului CHAOS arata ca aproximativ 71% dintre companii au avut depasiri de buget situate in intervalul 21-100% (tabelul 18).

Tabelul 18. Depasirea costurilor anticipate (planificate)

Depasirea timpului estimat

In cazul proiectelor incercate si a celor contramandate, cumulat in anul 1994 mai mult de o treime au depasit timpul estimat cu 200 pana la 300%.

Tabelul 19. Depasirea timpului estimat

Media depasirii de timp estimat a scazut semnificativ din 1994 pana in anul 2004, de la 222% pana la 63% (tabelul 19). Rezultatele studiului CHAOS arata ca aproximativ 55% dintre companii au avut depasiri de timp situate in intervalul 51-200% (tabelul 20).

Tabelul 20. Depasirea timpului estimat

Deficiente in amploarea (continutul, scopul) proiectului

In cazul proiectelor incercate, in anul 1994 mai mult de un sfert au fost terminate cu doar 25% pana la 49% din caracteristicile si functiile specificate original. In medie, doar 61% dintre caracteristicile si functiile specificate initial au fost disponibile la aceste proiecte.

Tabelul 21. Deficiente in amploarea (continutul, scopul) proiectului

In 1994, 61% dintre caracteristicile si functiile cerute se regaseau in produsul final (tabelul 21), in timp ce, in anul 2004, cercetarile indica un procent de 67%.

Rezultatele studiului CHAOS arata ca aproximativ 61% dintre companii au avut deficiente de continut situate in intervalul 50-99% (tabelul 22).

Tabelul 22. Deficiente in amploarea (continutul,

scopul) proiectului

Conform rezultatelor studiului din 1994, doar 28.000 de proiecte de dezvoltare a aplicatiilor intruneau criteriile de succes - au fost terminate la timp, s-au incadrat in bugetul planificat si detineau toate caracterisiticile si functiile specificate initial. Studiul din 2004 arata ca 78.000 de proiecte au fost reusite.

Tabelul 2 Factorii de succes ai proiectelor

Cel mai important aspect al acestei cercetari este determinarea cauzelor ce duc la esecul proiectelor. Pentru aceasta grupul Standish a chestionat manageri executivi de IT pentru a afla opinia lor cu privire la cauzele care duc la reusita proiectelor. Principalele trei motive ce conduc la succesul unui proiect, in anul 1994, au fost: implicarea utilizatorilor, suportul conducerii executive si declararea clara a cerintelor (tabelul 23). Exista si alte criterii de succes, dar indeplinirea celor trei enumerate mai sus creste semnificativ sansele de succes ale oricarui proiect. Fara ele, sansele de reusita scad dramatic.

Participantii la sondaj au fost deasemenea intrebati despre factorii ce cauzeaza incercarea proiectelor (tabelul 24).

Tabelul 24. Factorii de incercare ai proiectelor

Opiniile despre cauzele ce duc la contramandarea proiectelor au adus pe primele locuri in lista cerintele incomplete si lipsa implicarii utilizatorilor (tabelul 25).

Tabelul 25. Factorii care conduc la contramandarea proiectelor

O alta descoperire a studiului din anul 1994 a fost aceea ca un procent ridicat de manageri executivi credeau ca exista mai multe proiecte esuate decat cu cinci ani in urma, in ciuda faptului ca tehnologia a avut timp sa se maturizeze (tabelul 26).

Tabelul 26. Rezultate comparative

Motivele ce stau la baza cresterii ratei de succes a proiectelor variaza. Pentru inceput, costul mediu al unui proiect a fost redus la mai putin de jumatate. Au fost create metode si tehnici mai bune pentru a monitoriza si controla progresul proiectelor si sunt folosite procese de management mai performante conduse de manageri de proiect cu competente mult mai adecvate. Faptul ca sunt definite ca si procese este un imens pas inainte.

Totusi, s-a inregistrat un numar de 137.000 de proiecte ce depasesc bugetul planificat si timpul estimat, in timp ce alte 65.000 de proiecte au esuat cu desavarsire. Motivul pentru care cele mai multe dintre acestea au esuat nu a fost lipsa banilor sau a tehnologiei, ci lipsa unei conduceri de proiect competente si a suportului conducerii executive.

Lipsa suportului conducerii executive a inlocuit implicarea utilizatorilor ca si prima cauza de esec a proiectelor.

O reteta pentru reusita proiectelor: The CHAOS Ten

Ce face un proiect sa reuseasca? Studiul CHAOS original, desfasurat in 1994, a identificat 10 factori de succes. Acestia au fost actualizati in anul 2000 si sunt prezentati in tabelul 27. Chiar daca nici un proiect nu necesita ca toti cei 10 factori sa fie de succes, cu cat un numar mai mare de factori sunt prezenti in strategia proiectului, cu atat nivelul de incredere este mai ridicat.

1. Suportul conducerii executive: Acesta influenteaza desfasurarea si progresul unui proiect, iar lipsa lui poate reprezenta un dezavantaj sever.

2. Implicarea utilizatorilor: Chiar daca un proiect este predat la timp si in limitele bugetului planificat, el poate esua daca nu intampina asteptarile si nevoile utilizatorilor.

Manageri de proiect cu experienta: 97% dintre proiectele reusite au la carma un manager de proiect cu experienta.

4. Obiective de afaceri clare: Acest factor se afla pe pozitia a patra, nu pentru ca este mai putin important, ci pentru ca statisticile arata ca managerii de proiect cu experienta maresc rata de succes a proiectului.

5. Amploare (scop) minimizata: Timpul este dusmanul tuturor proiectelor. Deoarece amploarea proiectului are un impact asupra termenului final, sau a duratei acestuia, ele sunt interdependente. Prin minimizarea scopului, timpul este redus si de aceea sansele de succes se maresc. Minimizarea scopului inlocuieste punctele de control mai apropiate. Acesti doi factori sunt similari, dar minimizarea scopului conduce la un succes mai mare decat crearea de puncte de control intermediare. Punctele de control intermediare sunt incluse in factorul "amploare minimizata". Concentrarea asupra primilor cinci factori poate aduce pana la 70 de puncte de succes.

6. Infrastructura software standard: Cerintele sunt intr-o continua schimbare, dar infrastructura are nevoie de stabilitate. Prin utilizarea unei infrastructuri standard, echipa de dezvoltare a aplicatiei se poate concentra asupra regulilor de afaceri, mai mult decat pe tehnologie. Multe proiecte de dezvoltare a unor aplicatii esueaza nu in dezvoltarea aplicatiei care functioneaza independent, ci in integrarea aplicatiilor existente. Aici, infrastructura standard poate scurta integrarea aplicatiilor.

7. Cerinte de baza ferme: Cheia intelegerii acestui factor este cuvantul "de baza". Acesta se refera la cerintele nivelului de baza. Prin crearea unui minim de cerinte de baza, ce se poate obtine si apoi dezvoltarea acestor caracteristici, efectul schimbarii va fi diminuat. Livrarea aplicatiei cu un minim de caracteristici permite utilizatorilor si sponsorului proiectului sa vada rapid rezultatele. Un beneficiu in plus este acela ca managerii de proiect sunt mai bine pregatiti sa clarifice nevoile si prioritatile urmatoarei faze a proiectului.

8. Metodologie formalizata: Managementul de proiect formalizat furnizeaza o imagine realista a proiectului si a resurselor angajate in el. Anumiti pasi (proceduri) pot fi reprodusi si reutilizati, si de aceea, efectul de reinventare a rotii este minimizat, iar consecventa proiectului este maximizata. Lectiile invatate pot fi incorporate in proiectele aflate in derulare. Procesul incurajeaza un punct de control pentru a se lua o decizie de genul merge sau nu merge. O echipa de proiect poate merge mai departe cu un nivel de incredere ridicat sau pasii (fazele) pot fi opriti sau schimbati pentru a corespunde cerintelor in schimbare. Aceasta abilitate de a se adapta in timp real sporeste abilitatile proiectului si reduce riscul acestuia. Studiul CHAOS arata ca 46% dintre proiectele reusite au folosit o metodologie formalizata, comparativ cu procentul de 30% rezultat pentru proiectele incercate si contramandate. Astfel, putem concluziona ca acest factor ar trebui sa mareasca sansele de succes cu aproximativ 16%.

9. Estimari de incredere: A fi realist in estimari este necesar. Cum a fost mentionat mai inainte, managerii IT trebuie sa foloseasca cunostintele si experienta lor si ale persoanelor implicate pentru a ajunge la estimari ce reflecta efortul necesar cerut.

10. Alte criterii: Pe ultimul loc se afla o colectie de alti factori. Acesti factori includ: puncte de control apropiate, planificare adecvata, personal competent si dreptul de proprietate. In trecut, fiecare dintre acesti factori reprezenta o categorie independenta.

Folosind acest model grupul Standish evalueaza riscul proiectului. Pentru inceput este stabilit profilul proiectului si apoi sunt puse 100 de intrebari referitoare la profil. Pentru a calcula riscul proiectului, profilul si raspunsurile sunt apoi comparate cu un set de 30.000 de studii de caz.

"Factorii de succes CHAOS Ten continua sa fie o unealta de valoare in estimarea potentialului de succes al proiectului. Chiar daca nu exista o formula magica ce poate garanta succesul proiectului, asigurarea prezentei factorilor CHAOS Ten poate creste sansele in favoarea unora." [CHR 01]

Multe companii incearca sa alinieze mai bine tehnologia cu scopurile firmei. Dar inca multe proiecte nu functioneaza. O parte din problema poate fi discrepanta dintre ideile originale si rezultatele finale. In Analiza Discrepantelor s-a studiat cum companiile gestioneaza procesul de generare a ideilor, crearea si executarea planurilor.

Cine e seful? Intelepciunea conventionala spune ca individul sau grupul care are o idee originala de proiect ar trebui sa o implementeze.

Discrepanta

Acesta poate fi scopul dar nu se intampla mereu asa. Multi directori sau comitete au idei si apoi delega responsabilitatea implementarii lor unor subordonati sau unor consultanti externi fara sa transmita valoarea strategica. Dar si ideile angajatilor pot deveni strategice pentru companie, caz in care un director preia comanda proiectului. Acesta poate fi cel mai practic mod dar de multe ori duce la esec.

Figura 18. Analiza discrepantelor-rezultate [VIO 03]

In studiul Optimize realizat pe 113 profesionisti in afaceri si tehnologie 44% dintre ei au raspuns ca persoana sau echipa ce are o idee de proiect conduce rar sau niciodata implementarea (figura 18). Faptul ca cei care au idei le duc pana la productie este o exceptie. Intrebati cine din companie are idei de proiecte, 63% au raspuns ca: manageri sau directori; 37% vicepresedintii de IT; 35% manageri de departament IT si alti sefi de departamente. Multi manageri chestionati au raspuns ca directorii de la acele nivele executa proiectele, deci este in atributiile lor sa conduca initiativele.

Evident, proiectele sunt conduse diferit in functie de importanta lor pentru companie, dar este normal ca grupul sau individul care are idea sa fie implicat in implementarea proiectului si in mentinerea obiectivelor originale.

Metamorfoza

Daca o idee este destul de buna pentru a genera un proiect de companie, rezultatul final ar trebui sa ramana fidel conceptului original

Discrepanta

Am crede ca asa se intampla. Dar toata lumea cunoaste jocul de copii "telefonul fara fir" in care un copil sopteste ceva altui copil, iar acesta sopteste mai departe. Pana ajunge mesajul la ultimul copil este uneori foarte diferit de mesajul original. Desi ideile intr-o corporatie si planurile de proiecte nu trec prin asa de multe nivele, rezultatul final este foarte diferit de ideea originala, asa cum au spus doua treimi din cei chestionati (figura 19).

Figura 19. Analiza discrepantelor-rezultate [VIO 03]

Conform studiului acest lucru nu este intotdeauna rau. 37% din cei chestionati au spus ca discrepanta dintre idea originala si modul in care este executat rezulta in ceva mai bun datorita procesului de colaborare. Totusi, un sfert din cei chestionati au spus ca rezulta ceva mai rau. Cand ideile bune dau rezultate nesatisfacatoare sau proiectele esueaza din cauza executiei slabe, lipsei de conducere, lipsei de claritate, sau absentei sarguintei, procesul trebuie re-examinat.

Companiile trebuie sa se asigure ca acele concepte inovatoare nu sunt transformate in ceva ce nu aduce rezultate.

Scopuri neclare

Stabilirea scopurilor este usoara; executarea este dificila.

Discrepanta

Cand studiul Optimize a intrebat de ce exista o discrepanta asa de mare intre idea originala si rezultatul final (figura 20) raspunsul a fost lipsa de obiective de proiect clar definite (61% din manageri). Pe lista mai erau si: lipsa investitiei in proiect (41%), utilizatorii nu sunt de acord cu ideea/modificarea idei la testarea pilot (34%), departamentul de marketing a modifiat directia proiectului (30%), management de proiect defectuos (28%).

Figura 20. Analiza discrepantelor-rezultate [VIO 03]

Stabilirea unor obiective clare este un pas important in orice proiect, mai ales daca este strategic pentru companie. Determinarea initiala a ceea ce proiectul trebuie sa faca, a costurilor, a termenului limita pentru finalizare si a modului de evaluare - si comunicarea acestora tuturor celor implicati - mareste sansele de succes.

Management selectiv? Pentru a avea o sansa mai mare de succes proiectele ar trebui sa fie bine documentate, planificate si executate.

Discrepanta

Cam 2/3 din manageri au spus ca proiectele selectate de afaceri si cele tehnologice din compania lor sunt riguros documentate, planificate si executate. Doar 13% au spus ca toate proiectele sunt tratate in acest mod, iar 20% au spus ca majoritatea proiectelor sunt tratate ad hoc fara cercetari, planificari sau executii riguroase (figura 21).

Figura 21. Analiza discrepantelor-rezultate [VIO 03]

In mod sigur nu toate proiectele sunt cantarite in valoare strategica pentru companie. Totusi, o buna analiza, planificare si executie ar trebui sa faca parte din orice proiect. Proiectele de afaceri si IT pot sa esueze din mai multe motive, inclusiv finantare inadecvata, schimbari de personal sau o conducere inadecvata; dar o cercetare si o planificare initiala sunt obligatorii pentru atingerea obiectivelor.

Rasplata meritata

Companiile rasplatesc angajatii care sunt responsabili pentru executarea unor proiecte de succes

Discrepanta

Astazi multi angajati se multumesc doar sa ia un salariu. Chiar si asa, studiul arata ca organizatiile platesc bonusuri celor ce executa cu succes proiecte si ating anumite obiective (figura 22).

Figura 22. Analiza discrepantelor-rezultate [VIO 03]

Mai mult de jumatate din toate companiile studiate rasplatesc manageri de unitati de afaceri si directori (53%), manageri de IT si sefi de departamente (52%). La fel de multi gasesc bani sa plateasca bonusuri directorilor si vice presedintilor de IT (49%) si analistilor de afaceri si liderilor de proiect (44%). Doar cativa platesc bonusuri tuturor celor din comitetele de corporatii sau consultantilor (6%) (figura 22). Desi inovarea poate sa fie inclusa in fisa postului, aceste companii cred ca plata in plus pentru rezultate bune rezulta in castiguri pentru companie, mai ales daca angajatii au facut imposibilul pentru a termina cu bine un proiect.