La fel cum modul de conducere a unui start-up diferă de cel al unei corporații și modul de management al proiectelor de mari dimensiuni, diferă de cel al proiectelor obișnuite, care se derulează în general în companiile IT. Când discutăm despre proiecte din perspectiva dimensiunii lor există cinci elemente care trebuie luate în considerare, pe care le vom analiza pe fiecare în parte în ceea ce urmează.
În general în majoritatea companiilor întâlnim proiecte mici sau medii care se ocupă fie de crearea unor noi aplicații, funcționalități sau upgrade-uri de hardware. Rareori se întâmplă să discutăm despre proiecte extinse ca dimensiune din cauza riscurilor ridicate care vin la pachet. Totuși în momentul în care se dorește schimbarea tehnologiei utilizate la nivel de companie, nu putem decât să vorbim de un proiect de foarte mari dimensiuni, iar particularitățile procesului de management trebuie adaptate unei astfel de inițiative.
Găsirea unui șablon pentru evaluarea dimensiunii proiectului s-a dovedit a fi o sarcină dificilă, deoarece nu există un sistem standard de măsurare. Companiile tind să stabilească dimensiunea proiectelor într-un mod foarte subiectiv. Cu toate acestea, numeroase organizații clasifică dimensiunea unui proiect conform criteriilor de mai jos:
Potrivit statisticilor PMI, 1 din 6 proiecte IT întâmpină o depășire medie a costurilor cu 200% și o depășire a duratei prestabilite cu 70%. Prin urmare, eșecul unui proiect de mari dimensiuni poate pune întreaga organizație în pericol. Este foarte important să fim conștienți încă de la început de aceste criterii și să ne adaptăm stilul de Project Management în consecință.
În următoarele rânduri voi împărtăși provocările pe care le-am întâlnit în timp ce coordonam un proiect mamut pentru prima dată. După gestionarea diverselor proiecte de infrastructură sau livrare de software pentru mai mulți ani, am avut ocazia să conduc un proiect tehnic, strategic al companiei, având ca obiectiv migrarea majorității aplicațiilor de produs pe o nouă platformă. Vorbim de peste 300 de aplicații care necesitau a fi migrate în 16 luni cu implicarea a mai mult de 30 de echipe de development. Estimarea costului total plasează proiectul în grupul celor de mari dimensiuni.
După 10 luni de derulare a proiectului, consider că zonele de mai jos merită subliniate ca fiind esențiale atunci când se începe un astfel de proiect.
În primul rând este foarte important să existe un obiectiv și o descriere clară a cerințelor proiectului pentru a se evita schimbări multiple care în final să ducă la depășirea termenului de livrare. Deși acest lucru este valabil pentru proiecte mici, medii și mari, provocările suplimentare apar ca urmare a numărului mare de cerințe și a multiplelor modalități de interpretare a "Definition of Done-ului" pentru acestea.
Multiplele moduri de interpretare a cerințelor pot fi o provocare destul de mare. Pentru a se ajunge la un numitor comun este necesar un efort susținut, care implică numeroase workshopuri și întâlniri față în față pentru a se valida alinierea tuturor cu privire la ce urmează a fi implementat.
O altă provocare pentru proiectele care se desfășoară pe perioade lungi de timp este înghețarea scopului pe parcursul derulării acestora. Acest lucru este greu de realizat. Până la urmă, luând în considerare evoluția rapidă a domeniului IT, nici nu este de dorit, întrucât ar putea afecta relevanța livrabilului și în același timp businessul general. De exemplu, proiectul pe care îl coordonez a avut ca scop inițial migrarea a 170 de componente. Din cauza cerințelor de business de a crea noi aplicații pentru a sprijini nevoile clienților și a unor decizii arhitecturale, acesta aproape s-a dublat, conducând la prelungirea duratei și a costurilor proiectului. Totuși menținerea planului inițial nu ar fi adus aceleași beneficii. Așadar, ceea ce este cu adevărat important în aceste situații este evaluarea raportului impact/beneficiu a fiecărei modificări și asigurarea că deciziile sunt luate în cunoștință de cauză și într-o manieră consecventă.
Consider că impunerea unei "Definition of Done" stricte sau impunerea unui model strict de derulare a proiectului, ar fi condus la întârzieri în livrarea unor componente, fără a aduce un beneficiu companiei. Prin urmare, consider că pentru un proiect complex, care implică un număr mare de cerințe, trebuie să se acorde un anumit grad de flexibilitate, desigur, printr-un proces clar care să precizeze modul în care pot fi acceptate astfel de deraieri de la regulă. Acest lucru se poate realiza numai printr-o comunicare eficientă și printr-un proces solid de gestionare al schimbărilor.
În principiu, crearea planului de derulare a proiectului nu se face foarte diferit de o activitate similară rezervată oricărui alt proiect. Organizezi o serie de workshopuri, petreci timp cu echipa pentru a te asigura că au fost înțelese cerințele, stabilești câteva referințe și construiești o versiune inițială a planului.
Bineînțeles, pe măsură ce o echipă se apropie de momentul livrării, cerințele specifice și planul sunt rafinate. Este practic imposibil și de fapt inutilă o planificare detaliată de la început.
Dificultățile încep să apară în momentul în care mai multe echipe încep să lucreze concomitent. Atunci când există în jur de 15 echipe care lucrează în paralel cu o estimare medie de 4-5 sprinturi, este foarte probabil să apară derapaje și decalaje între dependențe.
Pentru proiectul în discuție este în general o provocare destul de mare stabilirea RAG statusului. Această realitate își are cauza în natura decuplată/modulară a muncii pentru diferite componente. O testare completă poate fi realizată doar după ce se migrează majoritatea componentelor, crescând riscul de livrare din cauza problemelor ce pot apărea la integrare.
Perioada de integrare a unui proiect complex este importantă și, totodată, dificil de programat din cauza numărului mare de echipe care trebuie să ia parte. Rezervarea timpului pentru echipele care au finalizat lucrul cu câteva luni mai devreme și reintegrarea lor în proiect este dificilă și trebuie planificată cu câteva luni înainte. Redobândirea concentrării devine o provocare care poate fi depășită numai printr-o comunicare intensă.
Într-o companie orientată spre dezvoltarea produselor proprii, unde implementarea se face frecvent cu echipe interne, costul de livrare se calculează drept costul unei echipe de dezvoltare per sprint ori numărul de sprinturi. Prin urmare, costul depinde în mod direct de numărul de echipe și de termenele proiectelor.
Într-un proiect complex acest cost poate varia foarte mult în funcție întârzierile de livrare de la o echipă la alta. În plus, stabilirea unei date fixe de livrare poate determina creșterea variației costurilor deoarece pentru a se livra la timp, se vor aloca resurse suplimentare care să accelereze derularea proiectului. Modificarea proceselor de gestiune și aprobarea schimbării sunt cheia administrării acestor situații. Transparența și buna comunicare vor ajuta la depăṣirea divergențelor apărute.
Un proiect mare înseamnă un număr crescut de cerințe, echipe și dependențe, ceea ce se traduce printr-un număr sporit de riscuri. Prin urmare, prioritizarea riscurilor devine esențială, accentul trebuind să se pună pe riscul potrivit la momentul potrivit.
Totodată există multiple dependențe la care trebuie să ne uităm: de la un setup de hardware nou și probleme specifice de infrastructură, la dependențe inter-aplicații care trebuie tratate și programate din timp pentru a permite stabilirea etapelor de integrare.
O bună prioritizare a riscurilor trebuie dublată printr-o comunicare excelentă cu stakeholderii. Asigurarea transparenței și vizibilității este esențială pentru ca aceștia să înțeleagă în ce măsură riscul pe care l-au ridicat se găsește în lista de priorități și care sunt acțiunile pentru a-l gestiona.
În plus, transparența oferită va ajuta la rezolvarea unor probleme chiar înainte ca acestea să apară. Din cauza specificului proiectului, o problemă cu care o echipă are de-a face în prezent este foarte probabil să apară pe viitor și la o altă echipă. Pentru a înțelege clar impactul unui risc, este importantă înțelegerea posibilelor repercusiuni asupra tuturor ariilor proiectului. Prin urmare, o comunicare eficientă devine cheia succesului.
În general, știm că o comunicare bună cu stakeholderi și înțelegerea nevoilor acestora sunt esențiale pentru încheierea cu succes a oricărui proiect. Atunci când vorbim despre proiecte complexe, probabil aceasta este cea mai mare provocare, din cauza numărului mare de stakeholderi și a canalelor de comunicare.
Identificarea stakeholderilor poate fi dificilă din cauza numărului de zone de business atinse de un astfel de proiect. Cu toate acestea, odată ce ele sunt identificate și clasificate pe baza unei analize, evidențierea persoanelor-cheie asupra cărora va trebui să se îndrepte atenția project managerului va fi mult mai ușoară.
Pentru o mai bună înțelegere a motivului pentru care comunicarea este o provocare, trebuie doar să ne referim la modul în care se determină numărul de canale de comunicare:
Prin urmare, un proiect mic / mediu, în cadrul căruia poate avem în jur de 50 de stakeholderi, are aproximativ 1200 de canale de comunicare, în timp ce pentru un proiect mare, care să spunem că ajunge la 200 de stakeholderi ceea ce înseamnă de 16 ori mai multe canale \~20k.
Cu această creștere exponențială, "zgomotul" din jurul proiectului este foarte mare și este de datoria PM-ului să pună în aplicare un plan de comunicare pentru a-l elimina prin alinierea stakeholderilor (de la echipe de development, la funcțiile de business).
Oferirea transparenței cu privire la progres, riscuri și probleme va contribui la sporirea încrederii părților implicate și la reducerea neînțelegerilor și alarmelor false, precum și la focalizarea pe probleme reale.
Modul de implementare a planului de comunicare ar trebui să rămână la latitudinea project managerului, deoarece acesta are cea mai bună vedere asupra întregului ansamblu. Din ce am observat, chiar dacă poate fi tentant să păstrăm sincronizarea tuturor prin organizarea de sesiuni "cu toată lumea" în care ne așteptăm ca fiecare să își expună informațiile relevante, acesta nu este și cel mai eficient mod și poate duce la crearea de zgomot și pierderea interesului celor implicați.
Prin urmare, cea mai bună abordare empirică este "Divide and Conquer". Gruparea pe zone funcționale va contribui la discuții mai concentrate pe subiectul vizat și, totodată, la asigurarea faptului că mesajele sunt relevante pentru audiență. De asemenea, discuțiile individuale cu actorii principali din proiect vor contribui la asigurarea gestionării nevoilor lor specifice și la menținerea nivelului de interes.
În același timp comunicările, rapoartele trimise către grupuri de stakeholderi sunt utile pentru a oferi o imagine de ansamblu bună a proiectului, dar trebuie să fie foarte specifice și să se concentreze pe "KPI"-uri stabilite împreună cu aceștia.
Se spune că un project manager ar trebui să comunice în jur de 90% din timp. În opinia mea, cu cât este mai mare proiectul, cu atât este mai mare nevoia de comunicare. Toate provocările prezentate mai sus, pot fi soluționate printr-o bună comunicare. Oferiți transparență părților interesate și asigurați-vă că toată lumea este aliniată.
Chat, write, call, shout - Communicate! It's the key!
de Robert Mălai
de Dan Colceriu
