PLEDOARIE PENTRU MANAGEMENTUL PROIECTELOR
Data: 1-15 iunie 2006
«Daca este adevarat ca rata schimbarii se va accelera foarte tare (…), atunci trebuie sa ne asteptam la o crestere substantiala a numarului organizatiilor si suborganizatiilor create pentru scopuri temporare. Aceasta trecere de la formele permanente la cele ad-hocratice este, în fond, o adaptare vasta si fundamentala a societatii la imperativele schimbarii sociale de mare rapiditate (…). Principala transformare care se impune poate fi cel mai bine simbolizata de diferenta dintre piramida lui Keops si „mobilele Calder“. Birocratiile industriale clasice sunt piramidale în structura, cu un mic grup de control în vârf si o desfasurare de departamente permanente si functionale dedesubt. Forma superindustriala a corporatiei va fi probabil alcatuita dintr-un cadru subtire si semipermanent, de care sunt suspendate diverse module mici si temporare. Acestea, ca parte a unei constructii calderiene, se misca la adierea schimbarii. Ele pot fi desfiintate sau reorganizate, dupa cum o cer schimbarile din lumea exterioara» [1].
Aplicând proiectarea toffleriana prezentului românesc si în special institutiilor statului, este evident ca structurile actuale, centralizate ale organizatiilor nu reusesc, datorita multitudinii de reglementari birocratice si datorita ierarhiilor rigide, sa îndeplineasca cerintele impuse de o piata dinamica si de efectele economice si sociale ale acesteia. Sunt necesare structuri organizationale flexibile care sa permita reactia rapida la mediu, orientarea spre piata, sa asimileze si sa prelucreze în timp util informatii noi, sa fie inovative si sa gaseasca solutii noi. Trebuie dezvoltate concepte manageriale care sa permita implicarea personala a angajatilor si asumarea raspunderii personale, individuale. În acest scop, managementul proiectelor, ca parte a unui concept modern de management organizational, poate fi un prim pas spre afirmarea angajatilor în spiritul cooperarii si deschiderii spre nou.
ISTORIC
Dupa unele lucrari, managementul de proiect, în formele sale primare, a început sa se manifeste cu mult înainte ca regele Keops sa planuiasca constructia piramidei sale, existând marturii ca «…de-a lungul a mii de ani, când recolta anului nu era gata de cules în luna „potrivita“, evreii îsi resincronizau calendarul (bazat pe fazele lunii) cu anotimpurile anului, adaugând înca o luna, asigurându-se ca populatia începe sa planteze anotimpul urmator la timpul potrivit (începutul proiectului)» [2].
Odata cu începutul secolului al XX-lea, Frederick Taylor (1856-1915), „parintele managementului stiintific“, a initiat studii detaliate asupra muncii, aplicând gândirea stiintifica si aratând ca activitatea productiva poate fi analizata si îmbunatatita prin concentrarea pe partile ei esentiale. Înainte de aceasta, singura cale de îmbunatatire a productivitatii era solicitarea de ore suplimentare si de intensificare a eforturilor muncitorilor.
Asociatul lui Taylor, inginerul Henry L. Gantt (1861-1919) a studiat detaliat ordinea operatiunilor în munca si a creat în jurul anului 1917 diagrama Gantt, instrument foarte important de vizualizare, care subliniaza secventa si durata tuturor sarcinilor într-un proiect si care a dus la o importanta expansiune a stiintei managementului de proiect. Diagrama Gantt s-a dovedit a fi un instrument analitic atât de puternic pentru manageri, încât a ramas neschimbat pe timpul a aproape 100 de ani [3]. Târziu, la începutul anilor ‘90 au fost adaugate linii de legatura la barele de sarcini (task bars), descriind mai precis dependentele dintre acestea. Taylor, Gantt si altii au contribuit la dezvoltarea managementului într-o functie distincta a afacerilor, care necesita studiu si disciplina.
Dupa cel de Al Doilea Razboi Mondial, complexitatile proiectelor si reducerea timpului de furnizare a activitatii productive au dus la aparitia de noi structuri organizationale. Au aparut diagramele de retea complexe numite PERT (Program Evaluation and Review Technique – Tehnica de Evaluare si Revizie a Programului) si CPM (Critical Path Method – Metoda Drumului Critic), care au oferit managerilor un control mai mare asupra proiectelor extrem de complexe. PERT a aparut la sfârsitul anilor 1950, când amiralul Raborn din cadrul fortelor navale ale Statele Unite ale Americii s-a confruntat cu necesitatea ca rachetele din cadrul programului Polaris sa fie gata de lansare într-un timp foarte scurt, datorita unei amenintari iminente existente între Statele Unite ale Americii si Rusia. Managementul de proiect traditional nu a fost suficient pentru a „garanta“ siguranta natiunii si problema a fost rezolvata cu ajutorul acestei tehnici a lui Willard Fazar. De atunci, PERT a devenit o cerinta obligatorie pentru toate proiectele fortelor navale ale Statelor Unite ale Americii. Dupa acest eveniment nu s-a mai întâmplat nimic semnificativ în urmatorii 45 de ani. În scurt timp, aceste tehnici s-au raspândit la toate tipurile de industrii. Tocmai în 1997, dr. Eli Goldratt (celebru datorita cartii sale “The Goal”, un best seller mondial asupra Teoriei Constrângerilor, TOC - Theory of Constraints), a ajutat organizatiile sa-si îmbunatateasca profitabilitatea si productivitatea, scriind o carte despre realizarile sale si despre o noua metoda de a privi managementul de proiect, prin Teoria Constrângerilor: Lantul critic. Cartea sa subliniaza aplicarea acestei teorii la un mediu de management de proiect.
Bineînteles ca managementul de proiect s-a dezvoltat si din punct de vedere al instrumentelor de tip software, primele fiind introduse în anii ‘60. Odata cu aparitia PC-urilor, prelucrarea pe calculator la fiecare loc de munca a devenit nu numai posibila dar si necesara la anumite nivele ierarhice. Astazi conducerea proiectelor nu se mai poate concepe fara ajutorul calculatorului. În primii ani ai deceniului 8 au aparut sute de sisteme pentru conducerea proiectelor, dezvoltându-se o adevarata industrie a sistemelor de management al proiectelor. Aplicatii ca Timeline, Superproject si Microsoft Project s-au bucurat de un deosebit succes. Aceste prime sisteme, usor de folosit, au reprezentat o revolutie în modul de perceptie a managementului proiectelor, în special în Statele Unite ale Americii. Un salt deosebit l-a reprezentat evolutia industriei comunicatiilor. Retelele locale, posibilitatile extinse de interconectivitate, sistemele multi-user si posibilitatea de a conduce simultan mai multe proiecte au reprezentat tot atâtea avantaje folosite în managementul proiectelor.
Evolutia sistemelor de comunicatie face ca membrii echipei de proiect sa-si poata desfasura activitatea independent, la distante geografice mari unii fata de altii. Dar comunicarea în proiect nu se reduce la transmiterea/receptionarea de mesaje. Accesul la resurse, baze de date, aplicatii aflate pe sisteme diferite este si el deja la îndemâna multora. Cu toate acestea, sistemele software ramân doar instrumente auxiliare ce nu pot înlocui activitatea factorului uman. Succesul unui proiect depinde în primul rând de aportul managerului si al echipei de proiect.
DEFINITII ALE PROIECTELOR SI DIFERENTE ÎNTRE MANAGEMENTUL PROIECTELOR SI MANAGEMENTUL OPERATIUNILOR CURENTE ALE UNEI ORGANIZATII
Cuvântul proiect a fost utilizat prima data în jurul secolului al XVI-lea si deriva din latinescul projicere [4] (= a arunca înainte). Radacina latina sugereaza miscarea, o traiectorie, o anume relatie cu spatiul si timpul. Procesul implicat presupune un punct de plecare folosit ca o baza, de unde cineva se arunca înainte, catre un scop. Istoric vorbind, cuvântul si conceptul au fost folosite prima data de arhitecti. În secolul al XV-lea, Filippo Brunelleschi a primit sarcina desavârsirii catedralei din Florenta prin adaugarea unui dom. Înainte sa înceapa, el a elaborat o schita (progetto sau plan) a domului, folosind diverse perspective pentru a oferi o reprezentare geometrica a viitoarei structuri.
În activitatea curenta a organizatiilor au loc activitati si actiuni foarte diverse atât din punct de vedere al complexitatii, cât si din cel al repetabilitatii lor. De exemplu, într-o fabrica de elicoptere, în atelierul de montaj se asambleaza caroserii prin repetarea acelorasi operatiuni la fiecare aparat de zbor nou. Activitatea de asamblare a unei caroserii este una complexa, care se bazeaza pe mai multe operatii: fixarea subansamblelor prin însurubare, nituire, lipire etc. Actiunile de mai sus au un caracter permanent si repetitiv. Situatia este diferita daca se doreste, de exemplu, introducerea unui nou produs sau înlocuirea unor procedee. De exemplu, înlocuirea modelului de elicopter aflat în fabricatie cu altul, mai performant, cere o alta abordare a activitatilor, acestea având un caracter cu totul nou: noul model de elicopter trebuie mai întâi proiectat. Trebuie realizat si testat prototipul, elaborata tehnologia si metodologia de asamblare si reorganizat fluxul tehnologic în sectia de asamblare.
Toate aceste activitati au caracteristici comune care le încadreaza în categoria proiectelor. Munca efectuata în aceste cazuri nu este o munca de rutina. Ea are un caracter de noutate si unicitate. Temele si obiectivele sunt definite de la început. Activitatea trebuie planificata, derulata si controlata. Orizontul de timp pentru realizarea obiectivelor si implementarea rezultatelor este limitat. Începutul si sfârsitul perioadei în care trebuie sa se realizeze activitatile sunt bine precizate. De exemplu, activitatea de proiectare a noului elicopter trebuie sa se încheie la o data bine stabilita pentru a permite derularea altor activitati, cum ar fi realizarea prototipului, testarea lui, elaborarea planului de lansare pe piata etc. Activitatile au un grad mare de diversitate si complexitate. Ele necesita implicarea mai multor specialisti, deci si munca în echipa. Componenta echipei si raspunderile fiecarui membru al echipei trebuie bine definite. Resursele care stau la dispozitia echipei sunt limitate, fiind si ele stabilite înca de la începutul activitatii. Proiectele apar la toate nivelurile de organizare. Ele pot implica o singura persoana sau echipe de persoane.
Proiectele sunt activitati unice, orientate spre obiectiv, cu un grad ridicat de noutate si cu o sarcina de lucru complexa. Ele sunt limitate în timp si din punct de vedere al resurselor materiale si umane, necesitând, de obicei, o colaborare interdisciplinara în cadrul unei structuri organizatorice speciale, precum si metodici speciale implicând riscuri specifice. Obiectivul urmarit îl reprezinta crearea unei valori noi (produs, serviciu, structura etc.); mai pe scurt, proiectul presupune efectuarea unei activitati temporare în scopul crearii unui produs sau serviciu nou. În limbajul comun, practic, termenul de proiect se foloseste pentru pachete de lucru sau activitati interdisciplinare, în care sunt implicate mai multe persoane sau domenii de activitate. Aceasta colaborare inter/supradepartamentala este obisnuita în practica zilnica a organizatiilor. De obicei este vorba de activitati cu caracter de proiect si nu de proiecte în sensul strict al cuvântului. Folosirea termenului de proiect într-un sens prea larg atrage pericolul ca fiecare activitate mai complexa sa fie considerata proiect. Astfel, la nivelul organizatiei se ajunge la o complicare nejustificata, birocratica a relatiilor din interior si la supraîncarcarea activitatii de proiect.
Operatiile sunt activitatile primare, cu caracter de rutina. Ele se regasesc atât în activitatea de proiect cât si în cea functionala, obisnuita într-o întreprindere. Secventa de derulare a operatiilor este însa diferita în cadrul unui proiect fata de activitatea functionala (în linie) obisnuita. Încadrarea corecta a unei sarcini de lucru în categoria de proiect, program sau operatie este importanta din punct de vedere practic pentru ca, în functie de încadrarea sarcinii de lucru, aceasta necesita o anumita organizare structurala, anumite procedee de derulare specifice, tehnici si instrumente de suport, alocari de resurse si produce anumite costuri.
Conform PMI (Project Management Institute – Institutul de Management al Proiectului), un proiect este «un efort temporar, întreprins pentru a crea un serviciu sau un produs unic, prin aplicarea cunostintelor, tehnicilor si relationarilor pentru proiectarea activitatilor, cu scopul de a satisface nevoile actionarilor si de a respecta cerintele de scop, timp, cost si calitate» [5].
Sa încercam sa clarificam ce este si ce nu este un proiect, pornind de la aceasta definitie. În primul rând, un proiect este temporar, aceasta însemnând ca exista o data de încheiere a acestuia. Proiectele sunt diferite de operatiile curente, desi cele doua au foarte multe lucruri în comun. Diferenta dintre managementul proiectelor si managementul operatiunilor curente este data în primul rând de diferenta dintre proiect si operatiune curenta. Aceasta din urma se deruleaza într-un timp nedefinit, nefiind stabilita o data finala de încheiere (de exemplu, activitatile contabile sau cele care apartin departamentelor de resurse umane). Persoanele care deruleaza operatiuni curente ar putea coordona si proiecte; de exemplu, managerul unui departament de resurse umane al unei organizatii mari poate organiza un târg de locuri de munca pentru absolventi de studii superioare. Proiectele se disting de operatiile curente printr-o data de finalizare asteptata, cum ar fi în exemplul de mai sus data la care are loc târgul de locuri de munca. Conform definitiei, un proiect este un efort care este întreprins de o echipa sau de o organizatie, deci proiectele sunt evenimente intentionate, planificate. Proiectele de succes nu se produc spontan, în primul rând are loc o pregatire, o planificare a lor. În final, fiecare proiect creeaza un produs sau un serviciu unic. Acesta este livrabilul proiectului, motivul pentru care proiectul a fost întreprins [6].
Urmatoarele definitii ale proiectului, foarte apropiate ca semantica, au fost întâlnite în literatura de specialitate:
«Un efort temporar desfasurat pentru a crea un serviciu sau un produs unic, temporar însemnând ca proiectul are o data de sfârsit, iar unic, faptul ca rezultatul final al proiectului este diferit de rezultatul altor functii ale organizatiei» [7].
«Un efort planificat, exercitat pentru îndeplinirea unui obiectiv, care are un început si un sfârsit» [8].
«Un efort structurat (adesea presupunând o suma de bani apreciabila, personal si echipament) cu durata limitata, care este dezvoltat prin procese birocratice, analitice si de aprobare, pentru îndeplinirea unui obiect tangibil (de exemplu, proiectul de constructie a unei scoli). Un proiect ar trebui considerat ca una din tipurile de activitati care contribuie la un rezultat dat sau la un set de rezultate» [9].
Dupa Dennis Lock [10], proiectele pot fi clasificate în patru mari categorii: proiecte de constructii, petrochimice, miniere, extractive; proiecte industriale; proiecte de management si proiecte de cercetare.
Dupa alti autori [11], proiectele pot fi clasificate în trei grupuri mari: proiecte de investitii (constructia unei cladiri noi, restaurarea unui monument istoric, retehnologizarea unei banci), proiecte de cercetare si dezvoltare (dezvoltarea unui produs nou, a unei noi tehnologii, elaborarea unui nou software) si proiecte de organizare (introducerea unui nou concept de marketing, introducerea managementului proiectelor ca forma alternativa de conducere, largirea segmentului de piata, outsourcing-ul unei anumite activitati).
CAUZE ALE ESECULUI SI PREMISE PENTRU SUCCESUL PROIECTULUI
În conformitate cu literatura de specialitate în domeniu, cauzele tipice pentru esecul unui proiect ar putea fi urmatoarele [12]: obiectivele companiei/organizatiei nu sunt cunoscute la nivelurile inferioare; planurile îsi propun prea mult în prea putin timp; estimarea financiara nu a fost corespunzatoare; planurile s-au bazat pe date insuficiente, planificarea nu a fost abordata sistematic; nu se cunosc obiectivul final, necesarul de personal, punctele cheie, inclusiv ce si când trebuie raportat; estimarile sunt mai degraba ghicite, nu se bazeaza pe experienta anterioara sau pe standarde; nu a fost alocat suficient timp pentru estimarea corecta; nu s-a verificat daca exista personal disponibil care sa detina competentele si cunostintele dorite; nu toate persoanele lucreaza dupa aceleasi specificatii; exista o fluctuatie prea mare a personalului de proiect; nu exista consecventa în munca, nu se tine seama de termene; managerul de proiect nu a participat activ si efectiv la planificare, la preluarea responsabilitatilor; în anumite cazuri, daca a trecut prea mult timp de la aprobarea proiectului pâna la demararea acestuia, este posibil ca nivelul tehnologic sa nu mai corespunda sau obiectivele si prioritatile de la nivelul organizatiei sa se fi schimbat, sau situatia actuala sa nu mai coincida cu cea considerata punct de plecare în planificarea facuta; anumite detalii au fost uitate (nu au fost înstiintate la timp anumite persoane asupra unor schimbari survenite, anumite materiale nu au ajuns la cine trebuia, anumite persoane nu au fost informate din timp asupra unor discutii/sedinte/actiuni la care ar fi trebuit sa ia parte etc.); managerul de proiect este prea ambitios si impune un ritm prea accelerat pentru întreaga echipa – chiar daca performantele sefului sunt deosebite, daca întreaga echipa nu tine pasul, se ajunge în situatia de „calaret singuratic“, în care comunicarea în cadrul echipei lipseste sau este necorespunzatoare si, în lipsa sefului, totul se naruie sau se opreste.
Field afirma ca «proiectele esueaza atât de des deoarece scopul proiectului nu a fost apreciat în totalitatea sa sau nevoile utilizatorului nu au fost întelese total» [13]. Dupa Leicht, «…asteptarile înalte ale utilizatorilor pot constitui cauza esecului proiectelor» [14]. Hoffman [15], referindu-se la proiectele IT, spune ca acestea esueaza datorita unei slabe rezonante între departamentele IT si utilizatorii aplicatiilor. Într-un alt articol, acelasi autor afirma ca «managerii de proiect actioneaza prea des ca „politisti ai proceselor“ si „arhivatori de rapoarte“ si pierd din vedere ceea ce ar trebui de fapt sa faca – sa se asigure ca proiectele se desfasoara corespunzator» [16]. Dupa Hodgson «…este o parte din viata faptul ca proiectele esueaza; prea multe proiecte esueaza pentru ca proiectul este ca un iceberg – 9/10 din el se ascunde privirii noastre» [17].
Toti acesti autori au dreptate, dar niciunul nu se raporteaza la cercetarea sistematica a mecanismelor care duc la succesul sau esecul proiectelor.
Într-un articol din 2003, Julia King afima: «La companiile care nu sunt în topul primei treimi de utilizatori de tehnologie, 3 din 10 proiecte de IT esueaza în medie» [18]; acest lucru înseamna ca 30% din proiectele acestor companii înregistreaza esec. Acest lucru nu înseamna ca, automat, 70% din celelalte proiecte sunt de succes. Autoarea nu mentioneaza câte din acestea au depasit bugetul sau perioada de timp alocata sau câte au înregistrat diverse neconformitati dupa terminare. Exista mai multe cai de a masura succesul si esecul, dar nu exista o linie stricta de împartire a celor doua. Baker concluzioneaza: «Ca orice lucru, definitia esecului proiectului este în continua schimbare» [19], iar O’Brochta completeaza spunând ca «marea problema a evaluarii succesului proiectului este ca evaluarea nu este precisa si ca aceasta dinamica poate fi calcâiul lui Achile pentru un proiect; fara o întelegere clara a ceea ce constituie un succes, proiectul este plasat în pozitia de a fi judecat pe diferite criterii si va deveni invariabil înca o statistica de esec raportata de firmele de cercetare specializate» [20].
Exista o bogata documentatie referitoare la ratele de esec. Într-un material din 1997, referitor la un seminar pe aceasta tema se afirma ca: «În 1992, Biroul de Contabilitate Generala al Statelor Unite a analizat proiectele referitoare la Sistemele de Management al Informatiilor si a concluzionat: Dezvoltarea si modernizarea sistemelor de informatii guvernamentale reprezinta un proces dificil si complex. De multe ori proiectele au avut probleme serioase în ciuda muncii intense depuse de echipa de proiect. Activitatile nu s-au putut desfasura dupa planificare iar costurile au depasit plafonul asteptat cu milioane si chiar sute de milioane» [21]. Conform aceluiasi articol, Raportul HAOS al companiei de cercetari Standish Group (din Statele Unite ale Americii), publicat în anul 1994, indica faptul ca numai aproximativ 16% din toate proiectele referitoare la sistemele de management al informatiilor sunt încheiate la timp, la calitatea prevazuta initial si cu respectarea bugetelor (proiecte de succes), peste 52% sunt esecuri partiale (proiecte terminate, dar cu depasirea costurilor, timpului alocat si câteodata cu neîndeplinirea functionalitatilor prevazute initial), iar 31% sunt esecuri totale (proiecte abandonate sau anulate la un moment dat). În conformitate cu raportul mentionat, primii 5 factori identificati ca premise ale succesului sunt: implicarea beneficiarului, sprijinul managementului executiv, o declaratie clara a cerintelor, o planificare adecvata, asteptari realiste. Aceste elemente nu pot asigura însa singure obtinerea succesului. Dar daca acestea sunt îndeplinite în bune conditiuni, un proiect, în concordanta cu afirmatiile grupului Standish, va avea o probabilitate mai mare de succes.
Primele 5 cauze care au dus la proiecte încheiate cu depasirea bugetului, timpului alocat si câteodata cu neîndeplinirea functionalitatilor prevazute initial sunt considerate de catre Standish Group urmatoarele: lipsa semnalelor de la beneficiar, liste incomplete de cerinte si specificatii, schimbarea cerintelor si specificatiilor, lipsa sprijinului managementului executiv, incompetenta tehnica. În ceea ce priveste cauzele care conduc la proiecte esuate, Standish Group le mentioneaza în urmatoarea ordine: cerinte incomplete, lipsa implicarii beneficiarilor, lipsa resurselor, asteptari nerealiste, lipsa sprijinului managementului executiv, schimbarea cerintelor si specificatiilor, lipsa planificarii, lipsa abilitatii tehnice.
Rezultatele unui studiu prezentat la simpozionul Institutului de Management de Proiect din anul 1991 arata ca «exista zone care ar trebui accentuate de managerii de proiect care sunt angajati în succesul proiectelor lor» [22]. Cercetatorii au studiat 24 de zone ale managementului de proiect si au descoperit ca 3 dintre acestea, daca sunt realizate corespunzator, conduc în mod clar la aparitia unei probabilitati ridicate de reusita a proiectului. Conform studiului «se poate afirma ca aceste 3 variabile (planificarea corespunzatoare, responsabilizarea clara a membrilor echipei, controlul planificarilor) au cel mai important impact asupra performantei proiectului; datele obtinute sugereaza ca multe alte variabile sunt necesare pentru realizarea unui proiect de succes, dar cele trei anterior mentionate ar fi cele mai importante» [23]. Acelasi document gaseste doua atribute care au aceeasi influenta atât în proiectele de succes cât si în cele care înregistreaza un esec. Acestea sunt: utilizarea consultantilor si personalul bine pregatit. Un numar egal de proiecte de succes si proiecte esec au folosit consultanti si acelasi lucru a fost valabil si pentru personalul bine pregatit. Este dezamagitor ca aceste doua atribute nu au fost caracteristice numai proiectelor de succes. În sfârsit, acelasi studiu prezinta 4 aspecte care pot previziona un proiect esec: lipsa legaturilor de comunicare interna eficienta, lipsa legaturilor de comunicare externa eficienta, lipsa unei decizii responsabile, lipsa unei echipe de proiect eficiente.
Elenbass afirma ca «proiectele se refera la comunicare, comunicare, comunicare» [24]. Lipsa comunicarii este foarte costisitoare pentru o companie. Succesul poate exista, dar fara o buna comunicare interna si externa, costul succesului va fi mai mare decât de obicei; o alta consecinta ar fi ca în lipsa comunicarii, împlinirea succesului poate necesita un timp mult mai lung decât cel necesar, iar câteodata succesul poate sa nici nu apara.
Ce ne rezerva viitorul? În concordanta cu Johnson, rata de succes pentru proiecte a crescut de la Raportul HAOS al grupului Standish. Johnson atribuie aceasta rata de succes crescuta „Retetei pentru succes“ a grupului, care a fost stabilita în anul 1998. Conform autorului mentionat, rata de succes a crescut de la 16% în anul 1994 la 28% în anul 2000. Care ar fi primii 5 factori care au dus la aceasta crestere semnificativa? În concordanta cu raportul lui Johnson, acestia sunt: sprijinul managementului executiv - factorul a carui lipsa constituie pericolul numarul unu în esecul proiectelor în acest moment; implicarea beneficiarului – factor care a fost în mod traditional cauza numarul unu în esecul proiectelor, este acum pe locul doi, având o importanta foarte mare în continuare; un manager de proiect experimentat, Johnson afirmând ca 97% din proiectele de succes sunt conduse de un manager de proiect experimentat; obiective clare; scop minimizat – nu trebuie permisa „cresterea“ scopului, Johnson afirmând ca scopul minimizat a înlocuit reperele (jaloanele) mici.
Concluzia ar fi ca exista multi factori care duc la succes si multi care duc la esec. Jiang a elaborat o lista care contine 13 premise ale succesului si care poate fi utilizata ca punct de început pentru un proiect: scopuri clar definite – incluzând filozofia generala a proiectului sau misiunea generala a acestuia, cât si angajamentul de îndeplinire a acestor scopuri de catre membrii echipei; manager de proiect competent; sprijinul managementului superior; membri competenti ai echipei de proiect; alocarea suficienta a resurselor; canale de comunicare adecvate; mecanisme de control; capacitati de feedback; receptivitatea clientului; consultarea clientului; sarcinile tehnice; acceptanta clientului; identificarea si rezolvarea problemelor. Dar, ca orice lista, nici aceasta nu poate fi completa.
Un bun management de proiect este un proces aflat într-o continua îmbunatatire. Este un proces în care se fac greseli si în care se învata din acestea. Este un proces de studiere si învatare continua. Pentru aceia care nu se pot devota acestui nesfârsit proces, succesele vor fi foarte rare.
BIBLIOGRAFIE
1. Toffler, A., Corporatia adaptabila, Ed. ANTET, Bucuresti, 1999;
2. www.pqa.net/ProdServices/ccpm/
3. Sisk, Toney, www.sims.berkeley.edu/courses/is208/s02/History-of-PM.htm
4. Project Management T-KIT 3, www.training-youth.net/INTEGRATION/TY/Publications/tkits/tkit3/tkit3.pdf
5. Adaptare dupa Ghidul Corpului de Cunostinte al Managementului de Proiect–PMBOK, 1996, Project Management Institute;
6. Adaptare dupa Carl S. Chatfield si Timothy Johnson, Microsoft Office Project 2003 Step by Step, MCP;
7. en.wikipedia.org/wiki/Project
8. www.cbu.edu/~lschmitt/I351/glossary.htm
9. www.usaid.gov/policy/budget/cbj2004/ glossary.html
10. Lock, Dennis, Management de Proiect, Editura Codecs, Bucuresti, 2000;
11. Mocanu, Mariana/Schuster, Carmen, Managementul proiectelor, cale spre cresterea competitivitatii, All Beck, 2001, Bucuresti;
12. Field, Tom, When bad things happen to good projects, CIO Magazine, 15 oct.1997, vol. 11, cap. 2;
13. Leicht, Michael, Managing User Expectations, publicatia electronica a Universitatii Missouri St. Louis, 1999 www.umsl.edu/~suater/analysis/user expectations.html
14. Hoffman, Thomas, Corporate Execs Try New Ways to align IT with Business Unit, publicatia Computerworld, 27oct. 2003;
15. Hoffman, Thomas, Value of Project Management Offices Questioned, publicatia Computerworld, 21 iul. 2003;
16. Hodgson, Ian, Keeping Your Head Above Water, www.conspectus.com/2002/november/article19.asp
17. King, Julia, Survey shows common IT woes, publicatia Computerworld, 23 iun. 2003;
18. Baker, Bud, Great Expectations: Turning failure into Success-and Visa Versa, PM Network, mai, 1997;
19. O’Brochta, Michael, Project Success – What are the Criteria and Whose Opinion Counts?, Lucrarile seminariilor si simpozioanelor anuale ale Institutului de Management al Proiectului, 3-10.oct.2002, San Antonio, Texas;
20. Kirksey, Kirk A., Storm warning: Danger Signs during Software Implementation, Health Management Technology, vol.11, cap. 6;
21. Anil, lyer si Thomasson, David, An Empirical Investigation of the Use of Content Analysis to Define the Variables Most Prevalent in Project Successes and Failures, Lucrarile seminariilor si simpozioanelor anuale ale Institutului de Management al Proiectului, 27 sept-02 oct.1991;
22. Elenbass, B., Staging a Project - Are You Setting Your Project Up for Success?, Lucrarile seminariilor si simpozioanelor anuale ale Institutului de Management al Proiectului, 7-16 sept. 2000, Huston, Texas;
23. Johnson, Jim, Collaborating on Project Success, www.softwaremag.com/L.cfm? Doc=archive/2001feb/CollaborativeMgt.html
24. Jiang, James J. Gary Klein si Joseph Balloun, Ranking of System Implementation Success Factors, Project Management Journal, dec. 1996.