Abordări de management de proiect

Abordările utilizate în managementul proiectului constau în mai multe abordări metodologice care pot fi adoptate pentru gestionarea activităților unui proiect, care includ abordări agile, interactive, incrementale și bazate pe succesiunea fazelor predefinite. Fiecare dintre aceste abordări prezintă avantaje și dezavantaje care pot recomanda adoptarea sa în anumite contexte de proiect, mai degrabă decât să o descurajeze în altele. În proiecte reale nu este neobișnuit să se detecteze adoptarea unor abordări mixte care utilizează părți ale uneia sau alteia în funcție de contextul sau faza proiectului.

Multe dintre ele se referă la PMBOK dezvoltat de Project Management Institute . Printre cele mai importante (vezi de exemplu recenzia lui Max Wideman ) pot fi considerate RUP , PRINCE2 ^[1] , TenStep , SDLC .

Indiferent de abordarea utilizată, trebuie acordată o atenție deosebită definirii clare a obiectivelor / obiectivelor proiectului și a implicațiilor acestora; definirea clară a rolurilor și responsabilităților tuturor actorilor implicați, inclusiv a clienților, are, de asemenea, o importanță decisivă pentru succesul proiectului.

În cazul proiectelor foarte complexe (de exemplu, în cazul unui set de proiecte conexe) și, în orice caz, în cazul impacturilor semnificative ale proiectelor asupra organizațiilor implicate și a proceselor acestora, proiectul trebuie luat în considerare într-un context mai global abordare, acționând în termeni de management al schimbării, care se ocupă în principal de gestionarea impactului uman și organizațional al unei transformări într-un context corporativ și / sau social.

Descriere

Abordare clasică

grupuri de proces ale unui proiect

Abordarea clasică este de fapt reprezentată de ortodoxia PMBOK dezvoltată de Project Management Institute , în cea de-a cincea ediție din care sunt definite 47 de procese , grupate în 5 grupuri de procese și 10 domenii de cunoaștere . Procesele PMBOK, dacă sunt aplicate în mod adecvat proiectelor, vă permit să planificați, să executați și să monitorizați toate aspectele care, direct sau indirect, pot afecta rezultatul proiectului.

Cele 5 grupuri de proces ale unui proiect sunt:

înființarea și pornirea proiectului (grup de procese de pornire);
planificare și proiectare (grup de procese de planificare);
execuție sau producție (grup de procese de execuție);
monitorizare și control ;
finalizarea și diseminarea rezultatelor (grup de procese de închidere).

Această secvență nu trebuie interpretată deterministic: grupurile de proces individuale și procesele individuale sunt adesea repetate înainte de finalizarea proiectului și pot avea interacțiuni în cadrul unui grup de procese și între grupuri de procese. Natura acestor interacțiuni variază de la proiect la proiect și poate fi sau nu realizată într-o anumită ordine.

PMBOK subliniază modul în care grupurile de proces ale unui proiect nu sunt fazele ciclului de viață al proiectului : în cazul în care un proiect este împărțit în mai multe faze, grupurile de proces sunt repetate în mod normal pentru fiecare fază, în plus, în funcție de contextul specific, fazele ciclul de viață al unui proiect poate fi cel mai divers.

De exemplu, în sectorul proiectării civile, proiectele progresează de obicei prin etape precum pre-planificarea, proiectarea conceptuală, proiectarea schematică, dezvoltarea proiectării, proiectarea elementelor de construcție, administrarea proiectelor. În domeniul proiectelor IT, abordarea clasică este adesea cunoscută ca un model de cascadă datorită liniarității cu care succesiunea sarcinilor este explodată în procesul de planificare. Modelul cascadei funcționează cel mai bine pe proiecte compacte și bine definite, în timp ce pe proiecte mai complexe în care există zone mari de scop care nu sunt bine definite sau necunoscute, este mai puțin potrivit. Conul de incertitudine descrie modul în care planificarea efectuată în faza inițială a unui proiect este afectată de un grad ridicat de incertitudine. Acest lucru este valabil mai ales în proiectele software care au ca scop dezvoltarea de noi produse. Modelul cascadei este considerat nesigur în proiectele în care cerințele nu sunt clare și bine definite și în cazurile în care sunt susceptibile la variații semnificative.

În timp ce numele fazelor pot diferi de la un domeniu de aplicare la altul, fazele reale urmează de obicei pașii tipici ai practicii de rezolvare a problemelor (definirea problemei, evaluarea alternativelor și opțiunilor, alegerea căii optime, implementarea și verificarea) .

Abordarea procesului unificat rațional

Rational Unified Process (RUP) este un cadru pentru dezvoltarea iterativă a produselor software create de Rational Software Corporation (o divizie a IBM din 2003). În practicile de dezvoltare software, multe organizații au adaptat RUP prin integrarea acestuia cu abordările de gestionare a proiectelor , deși RUP nu solicită sau recomandă în mod explicit această practică.

În schema RUP, ciclul de viață al unui proces software este împărțit în cicluri de dezvoltare , care sunt la rândul lor împărțite în faze conform următoarei scheme:

faza inițială ( Inception ) - identifică scopul inițial al proiectului, arhitectura probabilă a sistemului și obține mandatul și finanțarea de la client;
Faza de elaborare - proiectează și verifică arhitectura sistemului;
în construcție (Construcție) - produce software-ul cu intervale regulate pe bază incrementală, oferind o prioritate mai mare pentru a elibera cea mai anticipată de clienți;
faza de tranziție ( Tranziție ) - testează și instalează sistemul în mediul de producție.

În RUP fiecare fază are un anumit set de obiective și se termină cu realizarea unui livrabil (produs) de un anumit fel. Fazele sunt împărțite în continuare în iterații , care sunt asociate cu perioade de timp și au termene precise.

Versiunea deschisă a RUP este OpenUP .

Abordareacritică a lanțului

Abordarea lanțului critic dezvoltată de Eliyahu M. Goldratt se concentrează pe disponibilitatea resurselor, precum și pe dependențele logice dintre activitățile proiectului .

Abordarea este derivată din aplicarea teoriei constrângerilor la managementul proiectelor . Scopul este creșterea productivității proiectelor (care poate fi reprezentată ca procentul de activități finalizate cu calitatea necesară în termenele de distribuție stabilite de programul stabilit) în cadrul unei organizații. Prin aplicarea primilor trei pași ai TDV, resursele sunt identificate ca constrângere primară a fiecărui proiect . Pentru a aborda constrângerea, se acordă prioritate tuturor activităților care se află pe calea critică. În special, proiectele sunt planificate și gestionate în așa fel încât să asigure un început prompt, cu resursele total disponibile pentru toate activitățile care se găsesc pe calea critică.

Pentru unele proiecte specifice, planificarea proiectului se poate realiza prin nivelarea adecvată a resurselor alocate activităților; în acest fel, cel mai lung lanț de activități ( sarcină ) este identificat cu calea critică sau lanțul critic (de aici și denumirea abordării).

În mediile cu mai multe proiecte interconectate, nivelarea resurselor ar trebui realizată prin gândirea globală. Cu toate acestea, în multe contexte este ușor să identificați o resursă care acționează ca un wild card pe diferite proiecte, creând riscuri puternice de destabilizare în raport cu disponibilitatea sa.

Abordarea lanțului de evenimente

Metodologia lanțului evenimentelor (ECM sau metodologia lanțului critic) constituie un rafinament suplimentar al metodologiilor de gestionare a proiectelor bazate pe calea critică (CPM sau metodologia căii critice ) și pe lanțul critic .

ECM este o abordare de modelare și analiză a rețelelor de planificare care ia în considerare și gestionează incertitudinea unor lanțuri de evenimente capabile să aibă impact asupra planului de proiect. ECM se bazează pe aceste principii fundamentale:

probabilitate de risc instantaneu: o sarcină în majoritatea proceselor din viața reală nu este un proces continuu și uniform, dar poate fi afectată de evenimente care se pot întâmpla la un moment dat în viața sa;
Lanțuri de evenimente: evenimentele pot provoca alte evenimente, creând lanțuri de evenimente care pot afecta cursul proiectului. Analiza cantitativă este utilizată pentru a determina efectul cumulativ al acestor lanțuri de evenimente în planificarea proiectului;
evenimente critice sau lanțuri de evenimente critice: evenimente unice sau lanțuri unice de evenimente potențial capabile să afecteze proiectul constituie evenimentele critice sau lanțurile evenimentelor critice . Ele pot fi identificate printr-o procedură de analiză;
urmărirea evenimentelor proiectului: dacă un proiect a fost finalizat parțial și sunt disponibile informații cu privire la durata acestuia, costurile sale și evenimentele care au avut loc în desfășurarea acestuia, este posibilă calibrarea previziunilor cu privire la potențiale evenimente viitoare care pot apărea, ajutând astfel la evaluarea performanța viitoare a proiectului;
Vizualizarea lanțului de evenimente: Evenimentele și lanțurile de evenimente pot fi afișate utilizând diagrame de evenimente sau diagrame Gantt .

Abordări de management de proiect bazate pe procese (Agile și XPM)

Managementul proiectului abordări bazate pe procese ( de management bazat pe proces ) sunt derivate dintr - o generalizare a conceptului de control al proiectului.

Aceste abordări, cu o mai mare difuziune în zona IT, au fost induse de utilizarea integrării modelului de maturitate a capacității (CMMI) și a standardului ISO / IEC15504 (SPICE - Software Process Improvement and Capability Determination) care se bucură de o popularitate mai mare.

Una dintre cele mai populare abordări este reprezentată de metodologia agilă , bazată pe principiile managementului interacțiunii umane (managementul interacțiunii umane) care favorizează viziunea proceselor de colaborare umană între actorii implicați în gestionarea proiectului. În abordările de dezvoltare software Agile și de dezvoltare flexibilă a produsului , proiectul este văzut ca o serie de sarcini relativ slabe, proiectate și executate într-un mod puternic orientat spre cerere, conform unei logici adaptive, mai degrabă decât ca rezultat al unui proces complet planificat din inceputul.

Managementul de proiect extrem (denumit și XPM), inspirat și de metodologia agilă comparativ cu managementul de proiect tradițional , se concentrează mai mult pe obiectiv, își reduce domeniul de aplicare la aspectele esențiale și se dovedește a fi deosebit de versatil în fața condițiilor schimbătoare ale contextului în în care se află proiectul.

În unele reinterpretări critice ale managementului de proiect s- a observat că diferitele abordări bazate fundamental pe logica PERT nu sunt potrivite în mod deosebit mediilor multi-proiect ale marilor organizații moderne. Astăzi, multe dintre acestea sunt orientate către proiecte la scară foarte mare, rapide, care nu se repetă și ar trebui, de asemenea, să se considere că multe inițiative manageriale se desfășoară sub formă de proiecte.

XPM susține că, folosind modele prea complexe pentru proiecte (sau chiar sarcini ), mai ales atunci când acestea se întind pe câteva săptămâni, în multe cazuri, sunt generate costuri suplimentare dăunătoare și flexibilitatea și capacitatea de reacție a proiectului sunt reduse. Susținătorii XPM au fost inspirați de abordările ușoare găsite în ingineria software, cum ar fi programarea extremă și tehnicile scrum . Atunci când este utilizat împreună cu modelarea proceselor și principiile de gestionare a interacțiunii umane , XPM poate fi considerat în multe feluri ca generalizarea programării extreme în domeniul managementului de proiect.

Abordări open source și integrate: Praxis

Praxis ^[2] este o abordare gratuită și deschisă de gestionare a proiectelor, care evoluează datorită contribuției comunității managerului de proiect. Praxis Framework ™ ^[3] conține și integrează patru tipuri diferite de ghiduri de bune practici; un corp de cunoștințe, o metodă, recensământul abilităților necesare și un model de capacitate. Este primul cadru care integrează proiecte, programe și portofolii într-un singur ghid.

Praxis Framework este susținut de o comunitate internațională activă care a contribuit cu numeroase resurse, inclusiv un glosar, traduceri, șabloane, studii de caz și un blog.

Puteți utiliza în mod liber Praxis atâta timp cât respectați termenii licenței emise de asociația Creative Commons. De fapt, oricine poate adopta și adapta Praxis la propriile scopuri recunoscând sursa sa; aveți doar obligația de a vă pune la dispoziția altor lucrări fără a percepe drepturi de autor. Contribuțiile fiecăruia dintre noi ar trebui să poată fi încorporate pe acest site web pentru a beneficia și de alții.

Praxis reunește într-un singur cadru integrat, cu o singură structură și terminologie, nu numai un corp de cunoștințe (BoK), ci și un cadru de competențe și un model de maturitate a capacității. Prin urmare, nu mai este nevoie să efectuați o cartografiere și o traducere a diferitelor ghiduri.

Praxis nu este prescriptiv în a dicta modul în care componentele sale trebuie aplicate în gestionarea unui proiect, program sau portofoliu. Cadrul a fost, de fapt, creat pentru a oferi module care pot fi personalizate și asamblate concret pentru a se adapta la diferite contexte.

Notă

^ Ghidul PRINCE2 - de la A la Z, FAQ și peste 1000 de întrebări de examen , la ruleworks.co.uk . Adus la 7 august 2008 (arhivat din original la 27 septembrie 2007) .
^ Praxis Framework; ce este asta? - E-quality Italia , pe Imlearning.it , 3 ianuarie 2018. Adus pe 11 august 2020 .
^ Praxis este un cadru gratuit pentru gestionarea proiectelor, programelor și portofoliilor - Praxis Framework , la www.praxisframework.org . Adus la 11 august 2020 .

Elemente conexe

[1] Ghidul PRINCE2 - de la A la Z, FAQ și peste 1000 de întrebări de examen , la ruleworks.co.uk . Adus la 7 august 2008 (arhivat din original la 27 septembrie 2007) .

[2] Praxis Framework; ce este asta? - E-quality Italia , pe Imlearning.it , 3 ianuarie 2018. Adus pe 11 august 2020 .

[3] Praxis este un cadru gratuit pentru gestionarea proiectelor, programelor și portofoliilor - Praxis Framework , la www.praxisframework.org . Adus la 11 august 2020 .

[1]

[2]

[3]