Managementul de proiect: tradițional, iterativ sau hibrid?

Ca majoritatea managerilor de proiect (și a organizațiilor), probabil vă este greu să selectați abordarea optimă de livrare. Majoritatea dintre noi recunoaștem că abordările tradiționale nu garantează livrarea cu succes și căutăm mereu o cale mai bună.

Tehnicile de dezvoltare Agile sau iterative au primit multă publicitate pozitivă în ultimii ani, fiind considerate o îmbunătățire semnificativă, care duce la o livrare cu succes a proiectelor. Prin urmare, ca majoritatea organizațiilor de astăzi, probabil că și organizația dvs. se întreabă unde și cum pot fi utilizate cel mai bine aceste tehnici de dezvoltare Agile sau iterative pentru a îmbunătăți atât promptitudinea, cât și succesul livrării proiectelor.

Pe scurt, tehnicile de dezvoltare iterative planifică, dezvoltă și implementează funcționalitățile proiectului în segmente mici (sau iterații). Cheia succesului livrării iterative constă în faptul că fiecare segment mic funcționează efectiv ca un mini-proiect mai restrâns, în cadrul proiectului general. Ca rezultat, fiecare iterație a mini-proiectului poate planifica mai bine efortul necesar pentru a livra o iterație de două săptămâni, în loc de un plan pe doi ani. De asemenea, pentru că planificăm în intervale de două săptămâni, putem adapta ușor planul pentru următoarele două săptămâni, pentru a include orice schimbări identificate.

Studiu de caz Agile versus tradițional

Vreau să fac o scurtă pauză pentru a descrie o situație non-tehnică, în care s-a obținut mai mult succes utilizând o abordare Agile decât un plan tradițional.

Să utilizăm exemplul planificării activităților pentru o zi întreagă – acesta este proiectul. La fel ca într-un proiect mare, există multă incertitudine și risc: nu știm ce se va întâmpla după prânz și ne-ar putea afecta planul, dar tradiția spune că elaborăm un plan cuprinzător pentru ce vom face în fiecare oră a zilei, de la trezirea la 6:00 până la culcare, la 23:00.

La ora 9:00 suntem în întârziere, pentru că traficul ne-a amânat drumul spre serviciu; la ora 10:00 suntem chemați la o ședință de urgență; iar până la prânz, singura activitate zilnică finalizată a fost ajungerea la birou, și chiar și aceasta a fost cu întârziere.

Acum, să tratăm acest lucru ca pe un proiect Agile, în care planificăm doar următoarea iterație: pregătirea pentru a pleca de acasă (astfel, poveștile sunt: duș, micul dejun și ducerea copiilor la școală). Toate acestea au fost livrate cu succes, la timp și în buget.

Așadar, cu încredere, planificăm următoarea iterație, care înseamnă să ajungem la birou (mers cu mașina la autogară, luarea trenului de navetă până la stație, apoi autobuzul urban până la birou).

Acest lucru nu se desfășoară foarte bine: prima poveste (mers cu mașina la autogară) are probleme din cauza traficului, așa că modificăm povestea utilizatorului în mers cu mașina la birou și suntem de acord că celelalte două povești pot fi eliminate din planul iterației. La sosire, planificăm următoarea iterație. Dar, în mijlocul ciclului de planificare, se adaugă o poveste nouă (ședința de urgență), iar acesta va ocupa întreaga iterație următoare.

În cele din urmă, după prânz, lucrurile se liniștesc și putem să analizăm backlogul și să începem sarcinile cu prioritate maximă; finalizăm cu succes două iterații care tratează elementele cu prioritate maximă în cursul după-amiezii.

Dacă am fi rămas la planul tradițional, nu am fi finalizat niciodată aceste elemente cu prioritate maximă, deoarece au fost replanificate pentru ziua următoare din cauza întârzierii planului cauzate de deplasarea la birou.

Care este cea mai bună abordare – Agile, tradițională sau hibridă?

Această flexibilitate de a se adapta la nevoile de afaceri în schimbare este punctul forte al metodelor Agile sau iterative, și motivul pentru care multe organizații le adoptă. DAR organizația dvs. este cu adevărat pregătită să adopte „pe deplin” Agile? Din experiența mea, există adesea multe obstacole în calea adoptării Agile la scară largă, în special politici organizaționale bine stabilite, care sunt adesea mai puțin decât pe deplin compatibile cu abordările Agile.

Politici precum necesitatea unui buget ferm, a unei declarații privind realizarea beneficiilor și a unei date țintă înainte ca un proiect să poată fi aprobat sunt importante (dar nu prea Agile). În mod similar, politicile organizaționale de implementare care trebuie respectate pentru a se asigura că nu există impact asupra operațiunilor existente sunt critice (dar cu siguranță nu sunt Agile).

Ca urmare, multe organizații se confruntă cu dificultăți în a păstra unele procese „tradiționale” esențiale, adaptându-se în același timp la metodele iterative. Răspunsul este un model de livrare hibrid. Părți ale proiectului pot fi livrate utilizând metode tradiționale de management, iar altele pot fi iterative.

Model de livrare hibrid

Cel mai frecvent model hibrid pe care l-am întâlnit acceptă inițierea și planificarea tradiționale a proiectului, urmate de o serie de iterații, cu pauze pentru activități tradiționale de implementare pentru lansări, apoi de o altă serie de iterații și de implementare tradițională.

În acest model, dezvolt o structură tradițională de defalcare a activității orientată pe livrabile (WBS), care identifică livrabilele esențiale necesare în organizație pentru aprobarea proiectului, cum ar fi Project Charter, Project Management Plan și Project Budget.

Aceste livrabile inițiale pot fi dezvoltate și gestionate utilizând metode tradiționale, pentru a arăta conducerii că acest proiect este potrivit și că este o opțiune bună pentru alocarea resurselor.

După aprobarea proiectului, acesta poate trece apoi la o abordare iterativă, în care se menține un backlog de povești de utilizator, iar poveștile cu cea mai mare prioritate sunt selectate și dezvoltate complet în următoarea iterație. Imaginea proiectului se schimbă de la vizualizarea tradițională de tip diagramă Gantt la un panou de glisare și fixare interactiv, permițând alocarea dinamică a poveștilor la iterații.

În orice moment, deseori zilnic, proprietarul produsului poate să adauge, să șteargă și să modifice poveștile din backlog pentru a reflecta nevoile de afaceri în schimbare.

La finalul fiecărei iterații, facem o pauză și realizăm o evaluare retrospectivă a succeselor și nereușitelor, apoi facem modificările necesare pentru a implementa îmbunătățirile. Apoi, și cel mai important, analizăm backlogul produsului și selectăm cele mai importante povești drept candidate pentru următoarea iterație. Această abordare asigură că proiectul lucrează în permanență la cele mai potrivite activități, cu cea mai mare valoare.

În cadrul fiecărei iterații, echipa poate utiliza principii Agile, cum ar fi întâlnirea zilnică, și poate discuta starea poveștilor planificate pentru iterația curentă. Astfel, echipa are control total asupra activității finalizate într-o iterație, asigurând în același timp că proiectul general rămâne actual și disponibil pentru raportarea la nivel de întreprindere privind capacitatea resurselor și stadiul portofoliului și al programului.

Un element-cheie al principiilor Agile este capacitatea de a implementa soluția finală în versiuni mici. Acest lucru are avantajul că funcționalitatea preliminară poate fi utilizată pentru a obține cât mai repede posibil o parte din beneficiile pentru afaceri estimate.

De asemenea, are avantajul validării timpurii a soluției, astfel încât orice ajustări să poată fi incluse cu ușurință în poveștile rămase în backlogul produsului. Prin urmare, de îndată ce în iterații au fost finalizate suficiente povești cu prioritate ridicată, proiectul revine la un ciclu tradițional și execută activitățile standard de implementare solicitate de organizație.

Încercați Microsoft Project gratuit

Încercați gratuit Microsoft Project timp de o lună

Aflați cum

Aceste activități de lansare și implementare vor fi planificate și controlate utilizând abordări tradiționale și vor asigura respectarea proceselor definite pentru a reduce orice impact asupra operațiunilor existente atunci când sunt implementate proiecte noi.

După finalizarea primei lansări, proiectul revine la abordările Agile și începe să parcurgă o altă secvență de iterații pentru a continua dezvoltarea poveștilor rămase.

Deși această abordare „în etape” de combinare a abordărilor Agile și tradiționale este cea mai comună, puteți combina abordările pentru a susține cerințe specifice de livrare a proiectului. De exemplu, am gestionat un proiect care necesita un nivel extrem de ridicat de conformitate și validare, în timp ce implementam un produs nou într-un sector foarte puternic reglementat. Prin urmare, majoritatea proiectului meu a fost planificată și controlată utilizând metode tradiționale.

Totuși, a existat o componentă de business intelligence a proiectului, în care compania mea analiza volumul mare de date de performanță generate de sistem; această componentă era susținută cel mai bine de o abordare Agile. Pentru componenta BI a proiectului (desfășurată în paralel cu activitatea tradițională), am selecta poveștile cu prioritatea cea mai mare – care puteau fi finalizate într-un sprint de trei săptămâni – și am finaliza o iterație.

Deoarece multe dintre aceste povești aveau un caracter exploratoriu, adesea creăm povești noi, fie pentru explorări suplimentare, fie pentru crearea unor rapoarte de performanță specifice. Acestea erau pur și simplu adăugate la backlog pentru a fi luate în considerare în următorul sprint.

Cu această abordare, am avut un singur program al proiectului care s-a asigurat că am îndeplinit toate etapele de raportare și de conformitate cerute, permițând în același timp o abordare extrem de flexibilă pentru dezvoltarea componentei de raportare de business nereglementată a proiectului.

Faptul că totul era într-un singur program a oferit o perspectivă unică asupra a tot ce se întâmpla în acest proiect:

Informațiile de care aveam nevoie pentru a gestiona alocările de resurse către cele mai potrivite activități (tradiționale sau agile) erau disponibile imediat

Posibilitatea de a crea rapoarte de stare săptămânale și lunare solide era la îndemână

Agile este o abordare extrem de puternică de livrare a proiectelor, care ar trebui să ofere beneficii semnificative kitului de instrumente generale a organizației dvs. pentru livrarea proiectelor. Poate fi utilizată ca soluție autonomă, ca parte a unei abordări de livrare în etape sau integrată într-o structură de livrare hibridă.

Cheia este să adoptați principiile Agile care vă vor ajuta organizația să obțină succesul în livrare, respectând în același timp procesele tradiționale care au ajutat organizația dvs. să aibă succes până acum.

Steve Caseley are peste 35 de ani de experiență în Microsoft Project și a fost un utilizator activ al Microsoft Project de la prima sa versiune. Este editorul mai multor cărți legate de Microsoft Project și de cele mai bune practici în managementul proiectelor. Este consultant principal la Sensei Project Solutions, unde ajută organizațiile mari să atingă excelența în livrarea proiectelor utilizând kitul de instrumente Microsoft Project Portfolio Management (PPM).

PRODUSE CONEXE
Office 365

Introducere în Microsoft 365

Este același Office pe care îl cunoașteți, plus instrumente pentru a vă ajuta să lucrați mai bine împreună, pentru a putea face mai mult, oricând și oriunde.

Cumpărați acum

Conținut asociat

Gestionați-vă afacerea

De ce directorii executivi nu îi suportă pe managerii de proiect?

Citiți mai multe

Detalii și idei pentru afaceri nu oferă recomandări de specialitate în domeniul fiscal sau financiar. Ar trebui să luați legătura cu propriul specialist în domeniul fiscal sau financiar pentru a-i prezenta situația dvs.