Deosebiri dintre planificarea programelor si planificarea proiectelor

Exista cateva diferente clare intre planificarea programelor si planificarea proiectelor.

Planificarea programelor reprezinta planificarea, monitorizarea si controlul unui portofoliu de proiecte.

Planificarea proiectelor reprezinta aceleasi activitati, dar aplicate la un singur proiect.

In continuare, vom discuta cateva diferente dintre aceste doua medii de lucru, din pers­pectiva planificarii.

1. Planificarea proiectelor

Prin traditie se obisnuieste ca planificarea sa fie facuta pe un singur proiect o data. De obicei, proiectul va fi independent de alte proiecte din cadrul companiei, dar dependent de contextul propriu. Proiectele pot fi mult distantate fizic sau geografic de sediul orga­nizatiei. Resursele sunt mai putin importante decat in sfera managementului programelor. Adesea se considera normal sa fie recrutate si angajate resurse pentru durata de viata a unui singur proiect. Nu se preconizeaza ca resursele sa ramana in echipa de proiect dupa terminarea acestuia. In general, proiectele nu vor semana intre ele. Caracterul irepetabil face ca proiectele de acest gen sa difere mult de cele anterioare. Planurile lor pot fi com­plexe. Echipa de planificare s-ar putea sa aplice metoda drumului critic, ca sa stabileasca procesul cel mai eficient pentru realizarea proiectului. Constructorii de poduri si centrale electrice isi dedica mare parte din timp examinarii unor metode alternative de constructie, inainte de a alege o singura solutie. Planificarea are ca obiect atat chestiunea "cand se face", cat si chestiunea "cum se face". Exista un imperativ de a se reduce la minimum cererea de resurse, de a se reduce numarul de oameni si alte resurse angajate pentru proiect si, astfel, de a se reduce la minimum costurile angajate. Exista un inceput si un sfarsit clar definite ale proiectului si, de obicei, exista un singur obiectiv cu care aproape toata lumea se poate identifica.

2. Planificarea programelor

Planificarea programelor presupune existenta mai multor proiecte simultane, care intra in conflict unele cu altele, interactioneaza unele cu altele si depind unele de altele. Planifi­carea tinde sa se concentreze pe resurse, fiindca acestea dau principalul flux de numerar din cadrul companiei. Proiectele vor fi, de obicei, asemanatoare, iar planurile tind sa fie lipsite de complexitate, deci in multe cazuri se vor preta la grafice simple cu bare. Se dedica putin timp evaluarii si alegerii unei metode de executie a fiecarui proiect, deoarece, in mod normal, metodele sunt deja clar instituite. Planificarea are ca obiect principal chestiunea "cand se face". Exista o necesitate de maximizare a utilizarii resurselor, in asa fel incat sa se obtina maximum de efort dintr-o rezerva comuna relativ fixa de resurse. Desi se pot recruta in plus membri ai echipei de proiect, care sa se alature pe termen lung personalului companiei, si este adesea posibil ca o parte din lucrari sa se contracteze cu prestatori din afara, baza fundamentala de resurse este ori fixa, ori greu de schimbat in timp. Nu exista un inceput si un sfarsit clar stabilite pentru program ca intreg. Se adauga permanent proiecte noi in planul de activitate, iar proiectele mai vechi sunt eliminate pe masura ce se finalizeaza. Exista multe obiective diferite intr-un mediu de management al programelor - unii oameni sunt motivati de proiectele proprii, altii sunt motivati sa administreze un departament functional eficient, iar altii cauta sa mentina costurile la un nivel scazut in cadrul intregului portofoliu de proiecte.

3. Un model al procesului de planificare a programelor

Exista multe modele ale procesului de planificare a proiectelor, dar relativ putine pentru procesul de planificare a programelor. Gama diversa a modelelor organizationale si de management al programelor impune existenta unei game de abordari corespunza­toare acestor medii de lucru. Exista cinci etape in planificarea unui portofoliu de proiecte:

Planificarea Fiecare proiect este planificat din punctul de vedere al cerintelor de timp si resurse. Este o etapa similara planificarii unui proiect independent, dat fiind ca fiecare proiect tinde sa fie planificat de o maniera normala, specifica proiectelor execu­tate o singura data. De multe ori, dat fiind ca proiectele tind sa fie asemanatoare sau se bazeaza pe un tipar familiar, planificarea initiala se face prin referire la un plan standard sau chiar pe baza unui standard ori a unui plan anterior.

Transmiterea O data intocmite planurile proiectelor individuale, si pe masura ce se creeaza planuri noi, etapa urmatoare este transmiterea planurilor individuale catre o unitate centrala.

Unificarea Aceasta parte a procesului incepe cu combinarea numeroaselor planuri individuale de proiect sub forma unui singur plan de program. In multe organizatii, aceasta etapa de unificare trebuie derulata frecvent, pe masura ce se adauga planuri de proiecte noi la volumul total de activitate, iar planurile existente sunt aduse la zi.

Rezolvarea O data unificate planurile individuale, poate sa inceapa examinarea conflic­telor dintre proiecte, precum si procesul decizional pentru imbunatatirea planului general. Se poate stabili cererea de resurse aferenta intregului volum de activitate al organizatiei si se pot prevedea situatiile de conflict. Pot fi examinate si evaluate proble­mele legate de interdependenta dintre doua sau mai multe proiecte. O data stabilite si evaluate aceste probleme, echipa de management a programului poate sa ia decizii pentru rezolvarea conflictelor.

Raportarea Deciziile luate de echipa manageriala a programului afecteaza frecvent echipele proiectelor individuale. Exista adesea un mecanism de raportare, astfel incat deciziile sa poata fi comunicate echipelor individuale de proiect. De obicei, deciziile presupun intarzierea unui proiect pentru a imbunatati eficienta pe ansamblu a programului, sau prelungirea duratei unui proiect pentru a reduce cererea de resurse pretioase. Uneori poate insemna anularea unui proiect.

3.1. Modelul autonom

Pentru planificarea propriilor proiecte individuale, planificatorii lucreaza cu propriul exemplar al unui sistem de planificare computerizat, adica un pachet informatic foarte popular pe piata si cu cost scazut. Sistemele de acest gen sunt ieftine si usor de utilizat, si se preteaza perfect la planificarea unui singur proiect. Planurile se transmit periodic (de regula, saptamanal sau o data la doua saptamani) pe discheta sau printr-o retea locala de calculatoare (LAN), catre un birou de proiect sau program, unde sunt unificate in cadrul unui singur plan general, cu ajutorul aceluiasi soft de planificare. Biroul de proiect s-ar putea sa aiba nevoie de experti de specialitate, pentru a putea gestiona complexitatea pachetului de software, precum si de un calculator rapid si puternic, pentru a putea gestiona cantitatile mari de date. Personalul biroului de proiect poate sa verifice histo­gramele si graficele generale de executie, si, mai ales, graficele de executie pentru lucrari similare, cum ar fi toate activitatile de proiectare tehnica. Echipa de planificare a pro­gramului poate sa experimenteze strategii si calendare alternative de executie, in incercarea de a identifica un plan al programului mai eficient.

Aceasta abordare are avantajul ca permite fiecarei echipe de proiect sa-si planifice activitatea proprie, astfel incat sa-si asume "proprietatea" asupra planurilor respective. Biroul de proiect indeplineste un rol de sustinere, consiliind echipa manageriala a pro­gramului in legatura cu conflictele, care tin in general de suprasolicitarea resurselor. Este esential sa existe un grad ridicat de consecventa intre multele planuri de proiect. Daca numerosii planificatori de proiect nu folosesc aceeasi terminologie pentru denumirea resurselor, numerotarea sarcinilor si codificarea conventiilor, procesul de unificare se va solda cu un esec. Echipele de proiect s-ar putea sa se arate reticente sau incapabile sa-si faca planuri suficient de detaliate, si s-ar putea sa nu vada nici un folos din a proceda astfel. Daca echipele de proiect nu sunt incurajate sa-si inainteze in mod periodic planurile, procesul nu se va incheia cu succes.

Deciziile luate din perspectiva mai multor proiecte se comunica prin sedinte, raportari si alte mijloace verbale. Planificatorii individuali trebuie sa-si modifice planurile pentru a le alinia la cerintele programului. Un avantaj al acestei abordari autonome este posi­bilitatea de instalare pas cu pas a sistemului de planificare. Sistemul de unificare poate fi implementat separat, la o data ulterioara.

3.2. Modelul integrat

In acest caz, organizatia cumpara licente de utilizare multi-locatie ale unui sistem de mare capacitate pentru planificarea programelor sau a grupurilor de proiecte. Planificatorii au acces la sistem printr-un terminal local, care poate fi un calculator personal sau un termi­nal dintr-un sistem UNIX ori VMS. Fiecare proiect se planifica la nivel local, iar sistemul este conceput sa execute complet automat transmiterea si unificarea planurilor de proiect. Din nou, o echipa putin numeroasa din cadrul unui birou de proiect examineaza, comparativ cerintele fiecarui proiect si raporteaza problemele existente. Echipa de planificare a programului poate sa experimenteze strategii si calendare alternative de executie, in in­cercarea de a identifica un plan al programului mai eficient.

Aceste sisteme sunt scumpe si cu reguli complexe de utilizare. Fiecare planificator de proiect trebuie sa detina cunostinte experte in domeniu. In general, insa, exista un mic numar de entuziasti care introduc datele atat pentru ei insisi, cat si pentru utilizatorii mai putin experimentati. Din nou, este esentiala consecventa in codificarea conventiilor si actualizarea regulata, daca echipa manageriala a programului doreste sa aiba un model utilizabil al activitatii planificate. Sistemul de mare capacitate poate fi folosit pentru a impune echipelor de planificare normele si regulile de planificare stabilite. Deciziile luate in lumina executarii tuturor proiectelor din program pot fi introduse in sistem la nivelul biroului de proiect, precum si comunicate verbal si pe hartie. Aceasta inseamna ca feed-back-ul privitor la implicatiile situatiilor de conflict poate fi introdus direct sub forma unor planuri modificate.

Sistemele de acest tip presupun o abordare de tip "big bang", iar implementarea lor constituie un demers de mare anvergura. Accesul trebuie controlat in asa fel incat auto­ritatea de a modifica portiuni ale modelului sa apartina numai celor indrituiti. De regula, aceste sisteme se administreaza printr-un birou de proiect cu personal special angajat in acest scop.

3.3. Modelul combinat

Ca sa ia ce e mai bun din ambele metode, unele organizatii isi creeaza un sistem combinat. Fiecare echipa de proiect foloseste un sistem de planificare autonom, instalat pe calcula­toare personale, iar biroul de proiect foloseste un sistem de mai mare capacitate, pentru a integra planurile individuale. Planurile individuale se creeaza si se actualizeaza in sistemul de calculatoare personale pentru proiecte separate, iar fisierele sunt transferate pentru unificare in sistemul de mare capacitate. De regula, organizatia care foloseste modelul combinat va avea o retea de calculatoare locala. Echipa biroului de proiect gestio­neaza datele in cadrul sistemului de mare capacitate si raporteaza situatiile de conflict dintre proiecte. Circulatia datelor are loc de regula intr-un singur sens, deciziile fiind comunicate dinspre echipa de management a programului spre managerii de proiect prin sedinte, telefonic sau verbal. In incercarea de a usura aplicarea acestei abordari, mai nou au inceput sa apara unele instrumente de "unificare". Daca instrumentul de unificare permite acest lucru, echipa de planificare a programului poate sa experimenteze calendare alternative de executie, in incercarea de a identifica un plan al programului mai eficient.

Pentru ca un asemenea sistem sa poata functiona, trebuie mai intai rezolvate anumite probleme de compatibilitate a datelor. Intre planurile proiectelor individuale si instru­mentul multiproiect va exista un transfer periodic de date, deci compatibilizarea fisierelor trebuie sa fie simpla si sigura. Exista si problemele descrise anterior in materie de con­secventa a datelor. Se poate scrie un program de transfer al fisierelor, care sa converteasca si sa valideze datele din fiecare sistem individual. Apare un avantaj de implementare, deoarece organizatia isi poate institui o politica de actiune prin care proiectele sa fie planificate individual cu mult inainte sa se implementeze instrumentul de unificare.

Referat: CALIVITA INTENATIONAL - obiectivele firmei Calivita International Eseu: Functiunile intreprinderii

3.4. Modelul adaptat

Este o abordare similara celei autonome, cu deosebirea ca se creeaza un soft special adaptat pentru gestionarea unificarii. Avantajul specific consta in aceea ca softul respectiv poate fi automatizat, din punctul de vedere al operatiilor de unificare a datelor si de generare a rapoartelor pe baza acelor date. Din nou, se impune un grad inalt de consecventa intre proiecte, privind numerotarea sarcinilor si denumirea resurselor, dar softul special adaptat poate sa verifice consecventa ca operatie din componenta procesului de unificare. Softul special adaptat ar putea fi utilizat pentru raportarea problemelor specifice si ar putea cauta eventualele probleme cu mare probabilitate de aparitie. Dat fiind ca softul special adaptat nu se va ridica, probabil, la capacitatea unui sistem clasic de planificare, este putin probabil ca echipa de planificare a programului sa poata experimenta mai multe variante de plan, in cautarea unor calendare de executie eficiente. Rapoartele de decizie vor fi aproape sigur in forma verbala.

3.5. Instrumente de planificare orientate spre roluri

Sistemele clasice de management al proiectelor pornesc de la premisa ca utilizatorii lor vor fi manageri de proiect, sau, mai precis, planificatori de proiect. Interfata cu utilizatorul si directia de concentrare a softurilor rezulta din originile conceptuale ale acestui tip de sisteme, datand din perioada proiectelor de mare amploare, in cadrul carora planificatorii de proiect erau cei ce intocmeau planurile proiectului individual in cauza. In mediul de management al programelor, noua generatie de planificatori tinde sa utilizeze aproape la fel instrumentele concepute de aceasta maniera. Totusi, acum ar trebui sa fie posibila asigurarea unui instrument care sa aiba o serie de interfete diferite cu utilizatorul, in functie de rolurile manageriale indeplinite. Un astfel de instrument ar fi destinat sa ofere facilitati planificatorilor de proiect, precum si tuturor celor care indeplinesc celelalte roluri identificate in fig. 1. 

Fig. 1. Trei (din patru) roluri de management al programelor

Prin traditie, produsul softurilor de management al proiectelor a fost un model al proiec­tului, asa cum bugetul este un model produs de softurile folosite in departamentul finan­ciar. Planul modeleaza ceea ce incearca sa faca echipa de proiect, iar echipa utilizeaza modelul pentru a-si testa ideile, a-si comunica planurile si a urmari evolutia proiectului. Sa comparam aceasta cu un sistem de gestiune contabila, care modeleaza afacerile financiare ale organizatiei, dar produce direct si ordine de plata, facturi, state de salarii si extrase de cont. In acest caz, sistemul joaca si un rol esential in managementul organizatiei. In exact acelasi mod, softurile specializate pe roluri manageriale pot trece in centrul activitatii de management al programelor, pentru a juca un rol activ, in mai mare masura ca un soft de gestiune contabila. Cu alte cuvinte, softul ar putea furniza fiecarui membru al echipei de management al programelor datele corespunzatoare, si ar putea comunica deciziile luate de indivizi. Un pachet informatic de management al programelor ar putea sa transmita instructiunile referitoare la resurse, sa preia informatiile referitoare la lucrarile executate si sa gestioneze solicitarile din partea managerilor de proiect privind lucrarile ce se cer executate.

Un astfel de sistem ar permite celor ce controleaza organizatia sa incurajeze sau sa impuna aplicarea standardelor organizationale de catre managerii care au in responsabilitate proiecte sau resurse. Metodologia de buna practica va fi astfel consolidata, dat fiind ca sistemul ar putea fi utilizat de organizatie pentru a preveni intreprinderea anumitor actiuni fara obtinerea anumitor aprobari suplimentare. Totodata, organizatia ar putea insista, prin intermediul softului, ca numai anumiti manageri, bine stabiliti, sa aiba autoritate de decizie asupra planului - managerii de proiect ar putea lucra, de exemplu, numai cu sarcinile aflate in sfera proprie de influenta. Managerilor functionali li s-ar putea interzice sa modifice vreo sarcina, dar ar avea autoritate exclusiva asupra alocarii resurselor din cadrul propriului departament.

Tehnologia care face posibile noile solutii este cea a retelelor de calculatoare locale si regionale si arhitectura client/server. Gradul din ce in ce mai mare de conectivitate a sistemelor face ca numeroasele persoane implicate in derularea unui program sa poata avea acces, printr-un simplu calculator personal cu platforma Windows, la un sistem de mare capacitate care joaca un rol central in planificarea si gestionarea fluxului de activitati. Tot gratie tehnologiei se poate evita abordarea de tip "big bang" a sistemelor multi-utilizator, cu riscurile aferente. Avand un sistem in retea LAN, de pilda, ar trebui sa fie posibila testarea softului cu doar cativa utilizatori dintr-un singur departament, permitand apoi raspandirea progresiva a utilizarii softului in restul organizatiei.

Functia de management al programelor foloseste structura organizatorica detaliata pentru a decide caror manageri de proiect sa li se atribuie responsabilitatea pentru fiecare proiect sau pachet de lucrari. In aceasta etapa, fiecare proiect nu poate fi definit decat printr-o singura bara in grafic si o singura suma de bani. Pe masura ce accepta un proiect de la managerul de program, managerul de proiect poate sa detalieze planul proiectului, lucrand cu structura de defalcare a activitatii in portiunile in care aceasta influenteaza proiectul in cauza. Sau intr-o alta varianta, managerul de proiect ar putea folosi un grafic cu bare pentru a elabora planul in gradul adecvat de detaliu. Mana­gerul de proiect ar putea calcula cerintele de personal calificat ale sarcinilor din cadrul proiectului, in necesar zilnic sau orar de programatori ori ingineri. Planul proiectului se alatura multor altor planuri de proiect intr-o baza de date centrala. Aceste sarcini sunt esentialmente solicitari de executare a unor lucrari.

Fiecare manager de resurse nu vizualizeaza, din multele proiecte existente, decat sarcinile care necesita aptitudini profesionale din cadrul departamentului sau. De pilda, toate sarcinile aferente proiectarii tehnice sunt extrase si afisate numai pentru managerul departamentului de proiectare. Acest manager functional sau de resurse aloca resurse reale sarcinilor respective, satisfacand astfel cererea de personal calificat. Managerul de resurse are nevoie doar de vizualizarea alocarii resurselor, plus o vizualizare care sa permita tinerea evidentelor privind membrii echipei si aptitudinile lor profesionale. Infor­matiile de alocare din partea numerosilor manageri functionali sunt din nou stocate la nivel central. Fiecare resursa umana poate asadar sa aiba o vizualizare simpla, indicand ce activitate are de executat in urmatoarele cateva zile sau saptamani. Resursele pot sa inregistreze activitatea efectiv executata si sa depuna ulterior un pontaj cu orele sau zilele efectiv lucrate. Aceste date de pontaj provenite de la numeroasele resurse se reintorc, sub forma de feedback, la sarcinile din numeroasele planuri de proiect si le actualizeaza in consecinta.

Managerii de proiect s-ar putea sa nu dispuna de resurse proprii, dar trebuie sa se ocupe de executarea unor proiecte. Ei vor face acest lucru determinandu-i pe managerii functionali sau departamentali sa le aloce sau sa le imprumute resurse pentru proiectele respective. In toata partea de sus a matricei se afla managerii functionali, iar acestia au echipe de oameni care asigura servicii de specialitate.

Functiunea de management superior se afla deasupra si in jurul ambelor axe ale ma­tricei. Conducerea superioara ii angajeaza, ii dirijeaza si ii concediaza pe managerii functio­nali si pe managerii de proiect. Persoanele din conducerea superioara cunosc prioritatile organizatiei si detin autoritatea asupra managerilor de proiecte si a managerilor functio­nali. Prin urmare, vor actiona in calitate de arbitri, pentru a stabili chestiunile prioritare, atunci cand cerintele din partea a numeroase proiecte vor suprasolicita capacitatea unui departament functional de a furniza resurse pe o anumita perioada de timp.

Resursele sau executantii lucreaza in cadrul unui departament functional si efectueaza activitati de munca in cadrul proiectelor care le trec prin mana. Proiectele inainteaza prin interiorul matricei, petrecand un anumit interval de timp in fiecare departament, pe masura ce se apropie de finalizare. Aceste resurse sunt repartizate sa lucreze la proiecte intr-o mare varietate de modalitati. Uneori, resursele sunt detasate sa lucreze la un proiect in regim de norma intreaga sau partiala, alteori departamentul contracteaza in exterior activitatea aferenta proiectului. Majoritatea organizatiilor preiau volumul de activitate aferent unui proiect in proportie de sub 100 la suta. Orice organizatie de management al programelor este probabil sa deruleze in permanenta un anumit volum de activitati co­nexe, care nu tin direct de nici un proiect. Resursele vor fi implicate in munca la un proiect si intr-o serie intreaga de alte activitati, care nu pot fi cu usurinta defalcate pe proiecte. Activitatile conexe ar putea cuprinde intretinerea dotarilor si echipamentelor, intretinerea relatiei cu beneficiarii unor proiecte anterioare si marketingul activitatilor legate de proiecte noi. Toate presupun un consum de munca si de timp, dar nu sunt legate de activitatea de proiect.

Fig. 2a. Obiectivele si responsabilitatile directorilor de program

Fig. 2b. Obiectivele si responsabilitatilor managerilor de proiect

Fig. 2c. Obiectivele si responsabilitatile managerilor de resurse

Fig. 2d. Obiectivele si responsabilitatile executantilor