by Sunt mai multe articole pe internet cu motive pentru care proiectele esueaza. Exista diverse topuri si cu diverse procentaje. Evident lucrurile variaza si de la industrie la industrie si depinde de insasi modalitatea de intelegere a verbului “a esua” in cadrul diverselor companii/industrii. Printre motive, de multe ori intalnim: unrealistic timelines, unclear requirements, insufficient resource allocation, insufficient sponsor commitment, bad planning etc. In general cred ca pentru toti PMii, mai ales in industria IT motivele enumerate mai sus si altele asemenea lor sunt extreme de cunoscute.
Nu vreau sa rediscut aici aceste motive sau sa vin cu propuneri de imbunatatire, as vrea insa sa punctez faptul ca toate aceste motive pot fi incadrate sub palaria larga a risk managementului. Pana la urma totul se poate rezuma printr-un motiv acoperitor si anume “bad risk management”.
Daca este sa luam in considerare constrangerile la care un proiect este supus, pornind de la cele 3 clasice Scope, Time, Costs si adaugand si altele mai noi gen Quality, Resources, Customer Satisfaction, Risk etc (exista mai multe variante si clasificari de constrainturi, nu asta este important), riscul este cu adevarat o categorie aparte. Este practic singura constrangere din cele de mai sus care nu poate fi inlaturata sau limitata si am sa explic.
Poti sa stabilesti scopul foarte clar, poti sa pui un timeline fix, sau sa stabilesti o limita de buget. Poti hotari cate resurse implici intr-un proiect sau cat de mult ai de gand sa tii cont de satisfactia finala a clientului in raport cu cerintele specificate in contracte si cat esti de flexibil in aceasta relatie. Evident, si riscurile se pot controla, de aceea vorbim de risk management si acesta e un subiect in continua crestere. Insa atunci cand termenele nu sunt realiste, atunci cand incepi un proiect cu resurse insuficiente sau cerinte neclare, ceea ce faci de fapt este sa constrangi dimensiunile respective (si anume timp, scop, resurse) si sa maresti riscurile. Intotdeauna, incepand un proiect, exista riscul sa nu iasa, exista acest risc general ca scopul pe care ti l-ai propus sa nu il poti atinge in timpul, bugetul si cu resursele date si cu un client multumit etc. Evident intr-un risk register acest risc general este spart in bucati mai mici, mai detaliate si mai usor de controlat. Insa el nu poate fi niciodata inlaturat definitiv si probabilitatea sa de realizare creste sau scade direct proportional cu cat de tare umbli la celelalte constrainturi. In mod normal, intr-un proiect rulat ca la carte, poti sa iti dai seama daca proiectul este “in control” ca sa folosesc o terminologie Prince, uitandu-te in Risk Register. Cu cat mai putine riscuri si cu cat scorul lor este mai mic, cu atat proiectul este mai aproape de succes.
Revenind la motivele de mai sus, cred ca multi am avut si proiecte pe care le-am inceput cu termene sau bugete mai putin realiste. De ce le-am inceput? In principiu, pentru ca asa ne-a cerut compania in care lucram. Unele poate au iesit, altele nu, depinde de la caz la caz. Insa mergand pe politica pe care am vazut-o des intalnita in multe companii, aceea in care upper managementul seteaza de la inceput niste termene, un scop, niste bugete fara vreo analiza in prealabil dupa care cere project managerului sa faca un plan de proiect asa incat toate acestea sa fie respectate nu este altceva decat politica strutului. Se baga capul in nisip si se uita ca oricat de tare ai constrange anumite dimensiuni, nu faci altceva decat sa cresti riscurile. Profitand insa de faptul ca risk management in adevaratul sens al cuvantului se face mai putin, managementul se multumeste sa vada acel plan adus din condei ca sa “iasa bine” si se simte confortabil: “uitati ce frumos este planificat si ce bine va iesi proiectul nostru!”. Statistica insa nu minte, si intr-adevar daca e sa judecam dupa ceea ce se numeste baseline-ul proiectului, parerea mea este ca mai mult din jumatate din proiecte esueaza.
