Structura de decupaj a proiectului (sdp)

STRUCTURA DE DECUPAJ A PROIECTULUI (SDP)

SDP este un instrument obligatoriu in managemntul prin proiecte , permitand o colecta selectiva a datelor, o analiza si interpretare riguroasa a acestora pentru a vedea in ce mod corespund planului strategic al orgnaizatiei. Creare a SDP consista in divizarea muncii in activitati mai mici si asigurarea ca fiecare membru al proiectului intelege natura atributiilor pe care le are in proiect. SDP urmareste stabilirea unui calendar de lucrari si determinare abugetului necesar. Aceste date vor servi ca baza pentru controlul avansarii proiectului.

Crearea SDP se face pe parcursul a cinci etape.

1. Definirea anvergurii proiectului

Definirea continutului proiectului consista in crearea unui plan al proiectului. In mare, este vorba de stabilirea rezultatului final sau de misiunea proiectului - un produs, un serviciu, etc - si de determinare mai clara a livrarilor destinate utilizatorului final, adaptand activitatile in functie de asteptari. In general managerii de organizatii si chiar de proiect neglijeaza acest aspect, fapt ce are consecinte negative asupra intregului proiect.

Cercetatorii au demonstrat ca esecul unui proiect rezulta in principal dintr-o misiune sau dintr-un continut rau definit. In SUA, jumatate din esecurile proiectelor se pot explica porind de la neglijarea definirii ferme a continutului.

Continutul proiectului trebuie definit de asemenea maniera ca el sa satisfaca deopotriva pe manager si pe client. Managerul trebuie sa se asigure ca exista perfecta intelegere cu clientul in atingerea obiectivelor, in livrarile la termen, in exigentele tehnice, etc.

Descrierea continutului proiectului este un document care va fi public si va fi utilizat de catre proprietari si de catre participanti la proiectcu scopul planificarii si evaluarii sanselor de succes ale proiectului. Continutul decsrie ceea ce trebuie oferit clientului cannd proiectul va fi terminat; el defineste tinte precise, tangibile si masurabile.

Continutul proiectului serveste ca liant intre toate elementele planului proiectului. Lista de verificare urmatoare permite asigurarea exhaustivitatii continutului.

A) Obiectivele proiectului sunt stabilite in functie de necesitatile clientului. De exemplu, dupa ce a efectuat un vast studiu de piata, o societate informatica a decis sa dezvolte un program pentru traducere din romana in chineza. Costurile acestui proiect care se deruleaza pe doi ani este de 100.000 Ron. Observam din acest exemplu ca obiectivul proiectului raspunde la trei intrebari care se vor regasi in nevoile clientului: ce, cand si cat ?

B) Rezultatele imediate. Rezultatele concrete, exprimate in indicatori, in produse, servicii cu caracter de prototip, trebuie exprimate in lista de specificatii tehnnice sau in matricea logica. Exemplu redactarea unui manual tehnic poate fi un produs ce va fi livrat beneficiarului.

C) Jaloanele reprezinta momente importante si precise ale unui proiect. Ele servesc in divizarea mai buna a principalelor parti ale muncii. Ele furnizeaza prima estimare grosiera in termeni de timp, costuri si resurse a rezultatului proiectului. Jaloanele reprezinta puncte de control naturale si importante. Patricipnatii la proiect trebuie sa fie toti in masura sa le recunoasca cat mai usor.

D) Exigentele tehnice sunt reclamate de orice produs sau serviciu menit sa satisfaca pretentiile clientilor. Calitatea produselor si serviciilor sunt expresia satisfacerii exigentelor tehnice in fata clientilor.

E) Limitele si excluderile. Limitele de continut trebuie sa fie clar stabilite pentru a se evita deceptia asteptarilor si a indeparta risipirea resurselor si timpului. De exemplu, in cadrul unui proiect de hotel de cinci stele, trebuie definite limitele de confort pentru a se evita deceptia clientilor si a se indeparta perspectiva risipei resurselor si timpului de catre proprietarii hotelului.

Excluderile din continut permit determinarea dezavantajelor limitelor proiectului, pentru ca ele precizeaza tot cea ce nu este inclus. De exemplu, datele sunt colectate de catre client si nu de catre antreprenor; o casa este construita, dar amenajarea peisagistica si dispozitivul de securitate nu sunt incluse in pret.

F) Reviziurea continutului in prezenta clientului corespunde ultimei etape din lista de verificare a continutului unui proiect. Este vorba de asigurarea ca asteptarile sunt intelese si acceptate. Este esentiala comunicarea in toate fazele pentru a se evita orice reclamatie sau neintelegere.

Exercitiul 1. Realizati un chestionar si aplicatilor intr-o organizatie oarecare pentru a vedea urmatoarele calitati sau defecte ale unui proiect:

- clientul obtine ceea ce el astepata de la furnizor?

- descrirea proiectului reflecta fidel principalele realizari si exigente de performanta dorite?

- limitele si excluderile sunt bine intelese de ambele parti?

In concluzie, este esential de stabilit si de intretinut raporturi stranse cu clientii pentru descrierea proiectului pentru a raspunde la toate exigentele. Claritatea continutului va permite cernerea oricarei modificari susceptibile sa survina. O descriere precisa a continutului constituie esenta SDP. Odata completa si succinta, descrierea continutului proiectului va servi la elaborarea planului administrativ si logistica de la care va fi creat planul operational. In cazul proiectelor de mica anvergura, descrierea nu va putea sa fie mai mare de doua pagini.

Lista de verificare prezentata mai sus este una generala. Diferite industrii si organizatii creaza propriile liste si modele pentru a raspunde nevoilor lor si propriilor proiecte. Pentru numeroase intreprinderi de subansamble, enuntul continutului proiectului este in realitate caietul de sarcini. Alte organizatii privilegiaza mandatele de proiecte, care se utilizeaza in mai multe sensuri in managemntul proiectelor.

Cand continutul unui proiect necesita modificari, un proces de control etans se impune. Acest proces permite consemnarea tuturor schimbarilor efectuate. Un raport prezinta starea modificarii, efectele asupra proiectului si responsabilul care a acceptat sau refuzat schimbarea propusa.

2. Stabilirea prioritatilor proiectului

Calitatea si succesul unui proiect depinde de capacitatea de a raspunde asteptarilor clinetului si celei a managerului de proiect in ceea ce priveste costurile (bugetul), timpul si performanta (continutul). Raporturile mutuale intre cele trei criterii variaza de la caz la caz. Este important sa fie propuse compromisuri, fie in privinta performantei continutului proiectului pentru a fi terminat mai repede sau pentru a-i diminua costurile. Cu cat durata unui proiect se prelungeste cu atat costurile sunt mai ridicate. Forta de munca sau echipamentele ieftine pot cateodata sa conduca la anumite reduceri de costuri. De multe ori manageri de proiect sunt obligati sa accelereze sau sa precipite anumite activitati cheie. Pentru aceasta ei fac apel la un numar mai mare de resurse, de unde va rezulta o crestere a costurilor initiale ale proiectului.

Deseori managerul de proiect trebuie sa faca compromisuri in materie de timp, costuri si performanta. Pentru a face aceasta, el va trebui sa determine si sa inteleaga natura prioritatilor proiectului. O discutie dircta si onesta cu clientii si cu conducerea organizatiei ii va permite sa stabileasca importanta relativa a fiecarui criteriu. O matrice de prioritati ale proiectului ii va permite sa determine criteriile supuse acestor constrangeri si cele care vor putea fi optimizate sau acceptate:

A) Constrangerile vor trebui sa fixeze parametrii initiali. Proiectul trebuie sa fie terminat la data prevazuta, sa fie conform cu specificatiile sale si continutul sau si sa respecte bugetul.

B) Ameliorarile vor fi aduse in materie de timp si costuri. Este vorba de studia durata proiectului sau de a reduce cheltuielile. In ceea ce priveste ameliorarea performantelor este vorba de cresterea valorii proiectului.

C) Acceptarea. In ce situatie s-ar putea accepta un criteriu, care nu raspunde continutului initial? Cand un compromis se impune, este de conceput prelungrirea duratei proiectului decat a-i reduce continutul sau performanta? Este de dorit sa fie depasit bugetul initial?

Prioritatile variaza functie de proiect. De exemplu, pentru proiectele informatice moemntul oportun pentru a comercializa un produs nu este esential. Microsoft poate sa reporteze specificatiile initiale de continut in versiuni ulterioare, fara ca sa se tina seama de cine vinde prima data produsul. Din contra, cand este vorba de un proiect de organizare a unui eveniment -conferinta, competitie sportiva - timpul constituie o constrangere esentiala din momentul anuntarii datei de desfasurare. Cand bugetul este foarte strict, gestionarul proiectului trebuie sa faca compromisuri la continutul prioectului pentru a putea respecta calendarul prevazut.

Specialistii in managemntul proiectelor considera ca cele trei criterii sunt fara incetare supuse constrangerilor si ca gestionarii de proiecte trebuie sa gaseasca o maniera eficace de a optimiza actiunea acestor constrangeri. Daca totul se intampla bine, adica nu este nici o problema grava sau vreo limita importanta, managerul de proict trebuie sa fie in masura sa apere punctul sau de vedere. Aceasta situatie, insa este foarte rara, managerul de proiect este chemat adesea sa face alegeri dificile care vor avantaja un criteriu sau altul. Scopul acestui exercitiu consta in determinarea si acceptarea prioritatilor si constrangerilor proiectului inainte de a lua decizii bune atunci cand presiunea creste. Exista tendinta de a utiliza doar doua criterii din trei in luarea deciziei in momentul stabilirii prioritatilor.

Stabilirea unei matricii de prioritati pentru un proiect se dovedeste foarte utila in luarea de decizii. Acest instrument, care poate servi de vector de comunicare, permite stabilirea clara a prioritatilor in acord cu clientii si cu conducerea oragnizatiei, evitandu-se neintelegerile. Informatiile referitoare la prioritati se dovedesc esentiale in procesul de planificare, caci continutul, calendarul si bugetul fac adesea obiectul modificarilor. In fine, matricia este de asemenea foarte utila pentru a rezolva o problema situata la jumatate de drum in cadrul proiectului.

Managerul de proiect trebuie sa stie !

Prioritatile se pot schimba in cursul derularii proiectului. Un client poate adesea pune capat proiectului cu o luna mai devreme decat a fost prevazut sau conducerea organizatiei poate sa dea noi directive cu scopul reducerii costurilor. Este foarte important ca managerul de proiect sa ramana vigilent pentru a prevedea si confirma schimbarile de prioritate si a se adapta la ele.

3.Crearea unei Structuri de Decupaj a Proiectului (SDP)

3.1. Principalele regrupari in structura unui proiect. Din momentul in care continutul si termenele de livrare sau executie sunt determinate, ansamblul proiectului poate sa fie divizat in mod succesiv in activitati din ce in ce mai mici (poarta numele de planuri de munca, planuri operationale sau planuri de activitati -workpackeg-iuri ). Rezultatul acestui proces poarta numele de structura de decupaj a proiectului (SDP) . Este vorba de un plan al proiectului care permite managerului sa se asigure ca toate produsele si toate activitatile sunt bine definite. In plus SDP permite integrarea proiectului in organizatiei si stabilirea unei forme de control. SDP permite aprecirea proiectului la nivel de detaliu.

SDP debuteaza cu produsul final ce trebuie livrat (proiectul constituie produsul final ce trebuie livrat); este urmat de principalele sisteme/livrarile proiectului. Urmeaza apoi livrarile secundare necesare indeplinirii livrarilor de nivel superior. Se repeta procesul pana cand elementele de livrare sunt suficient de mici pentru a putea fi atribuite un singur gestionar. Livrarile secundare sunt divizate in loturi de lucrari sau activitati, care pot fi incredintate la echipe/grupuri de lucru sau activitati (echipa informatica/logistica, echipa de incercare, etc. Aceste regrupari la nivelul livrarilor secundare permit supravegherea avansarii lucrarilor, costurilor si repartitia responsabilitatilor in cadrul proiectului.

3.2. Utilitatea SDP pentru managemntul proiectului. SDP defineste toate elementele proiectului potrivit unei structuri ierarhice si stabileste legaturile cu elementele finale ale proiectului. Este suficient sa ne imaginam proiectul ca un mare pachet de loturi de activitati/lucrari, divizat in loturi mai mici. Aceasta structura ierarhica faciliteaza evaluarea costurilor, atimpului si performantelor tehnice la toate nivele de organizare si pe toata durata proiectului. SDP precizeaza de asemnea tipul de gestiune potrivita fiecarui nivel. De exemplu, conducerea organizatiei este insarcinata in mod esential cu principalele livrari/termene; managerii de prim nivel sunt responsabili cu livrarile/termenele secundare si cu loturile de lucru/activitati.

Pe percursul elaborarii unui SDP, responsabilitatea stabilirii continutului lorurilor de activitati/lucru este atribuita unitatilor organizationale si indivizilor. Aceasta integrare a muncii si organizationala, este in practica desemnata sub numele de structura de repartitie a sarcinilor in organizatie/ organigrama functionala.

SDP ofera de asemenea posibilitatea planificarii, ordonarii si stabilirii bugetelor. Structura sa permite sa se asigure o urmarire acosturilor si un control al performantelor. Ea permite obtinrea unei vederi de ansamblu asupra bugetului total si a costurilor reale a lotului de activitati pana la elementele de lucru de detaliu. Oragnizatia poate masura de asemenea performanta unitatilor organizationale si lucru de indeplinit.

SDP defineste caile de comunicare si de ajutor pentru a intelege si coordona partile proiectului. SDP ilustreaza sarcinile de indeplinit si responsabilitatile unitatilor organizationale. SDP ofera posibilitatea unei comunicari eficiente si o integrare a muncii si responsabilitatilor.

3.3. Elaborarea unui SDP Pentru nivel al SDP trebuie avute in vedere urmatoarele etape:

A) Definirea proiectului/activitati/lucrarii (Ce?)

B) Determinarea timpului necersar pentru indeplinirea proiectului/lotului de activitati (Cand?)

C) Stabilirea unui buget pentru executarea proiectului/activitatilor (Costurile?)

D) Detreminarea resurselor necesare executiei proiectului/activitatilor (Cat?)

E) Desemnarea unui responsabil de proiect/unitate de lucru (Cine?)

F) Stabilirea punctelor de control pentru evaluarea avansului proiectului.

Conceperea unui SDP de la zero este o intreprindere foarte curajoasa. Toti gestionarii de proiect trebuie sa se inspire din exemplele ce provin de la alte proiecte pertinente.

SDP sunt in realitate rezultatele unui efort colectiv. Cand este vorba de un mic proiect, membrii echipei participa toti la diviziunea proiectului in elemente mai mici. In cazul proiectelor mai mari si mai complexe, responsabilii principalelor nivele de executie se intalnesc pentru a determina primle doua nivele de exceutie. Principalii actori, cel mai adesea clientii, sunt consultati pentru a confirma asteptarile si pentru a aduce modificarile in caz de forta majoara.

In general, echipele proiectului care concep primul lor SDP uita ca structura lor trebuie sa conduca la un produs final, gata sa fie livrat clientului. Primele tentative sfarsesc adesea intr-un SDP calculat potrivit organigramei organizationale - conceptie, marketing, productie si finante. Cand SDP tine cont de structura organizatiei, accentul este pus pe functionarea si procesle organizatiei in detrimentul produsului fianl al proiectului. Intre altele, un SDP axat pe proces va deveni un instrument contabil foarte buna care va inregistra costuri de functiune decat un instrument necesar clientului. Este extrem de important sa se elaboreze un SDP axat pe produsul final decat pe indeplinirea unor indicatori. Relatia dintre responsabilitatile unitatilor organizationale si SDP poate sa fie stabilita prin regruparea loturilor de activitati intr-un cont de costuri de ansamblu avand drept tinta atingerea unui produs final acceptat de catre client/organizatie.

4. Integrarea unui SDP in sanul unei organizatii

Unul dintre elementele esentiale ale SDP consista in definirea unitatilor organizationale insarcinate cu executia activitatilor/lucrarilor. In practica, acest proces consista in conceprea unei organigrame functionale (OF). OF permite sa cunoastem maniera in care organizatia a delegat responsabilitatile. Obiectivele unei astfel de organigrame consista in rezumarea sarcinilor unitatilor organizationale intr-un cont colectiv de control al costurilor. Trebuie sa reamintim ca loturile de activitati/lucrari similare sunt regrupate in acelasi cont de costuri. OF defineste nivelele dintr-o organizatie potrivit unui model ierarhic care divizeaza unitatile din ce in ce mai mici. In cea mai mare parte din cazuri, o structura organizationala traditionala este suficienta. Chiar daca proiectul va fi executat de o singura erchipa, este important ca organigrama sa fie divizata in ceea ce priveste responsabilitatile de executie a bugetului si de performanta tehnica.

Intersectarea SDP cu OF furnizeaza ansamblul de loturi de activitati/lucrari necesare realizarii sarcinilor situate imediat la nivelul superior astfel ca o unitate organizationala sa fie responsabila de executia lotului de activitati situate la aceasta intersectie. Interesectia din tre SDP si OF permite evaluarea si controlul periodic al avansarii proiectului. Controlul se efectueaza de doua maniere - in functie de rezultate (axa verticala) sau de responsabilitati (axa orizontala). Pe parcursul proiectului, urmarirea avnsarii proiectului poate sa fie asigurata potrivit axei verticale corespunzatoare intereselor clientului sau potrivit axei orizontale, care corespunde responsabilitatii organizationale, adica intereselor conducerii organizatiei.

Organigrama de procese (OP)

Utilitatea unei structuri rezida in sistemul sau de codaj. Codajul serveste la definirea nivelelor si elementelor SDP, a loturilor de sarcini cat si la datele relative la buget sau la costuri. Intre altele, ele permit consolidarea raporturilor la oricare nivel al structurii. Planul cel mai des utilizat este alinierea numerica.

SDP-ul convine perfect proiectelor de conceptie si de constructie care necesita rezultate concrete, cum ar fi un nou prototip de masina. Proiectul poate fi divizat in livrari principale, livrari secundare, livrari secundare de nivel tot mai mic si in loturi de activitati (workpackeg-iuri. Este dificil de a utiliza un SDP in cazul proiectelor putin mai concrete axate pe proces, unde rezultatul final este produsul in serie. In acest caz, diferentele principale rezida in faptul ca proiectul contine ore supolimentare. Astfel, proiectele IT intra esentialmente in aceasta categorie -crearea unei retele extranet sau a unui sistem intern de baze de date. Proiectele axate pe pe un proces sunt dictate de exigente de performanta si nu de planuri si deviz. Anumiti practicieni aleg sa utilizeze organigrama de proces (OP) in locul traditionalului SDP.

OP se preteaza foarte mult in dezvoltarea sistemelor informatice. Fiecare etapa parcursa este urmata de o etapa de verificare, care contine exigentele principale de la finalul unei etape, care anunta o etapa noua. Listele de verificare relative la calitate permi asigurarea ca livrabilele sunt complete si precise. Toti responsabilii de nivel aproba in scris finalizarea unei etape si trecerea la etapa urmatoare a proiectului.

In masura in care exigentele finale sunt clar stabilite si ca livrabilele din fiecare etapa sunt bine definite, OP constituie o foarte buna solutie de inlocuire a SDP la proiectele care necesita o indeluingata activitate de dezvoltare.

6. Matricea responsabilitatilor

In foarte multe din cazuri continutul proiectului nu justifica elaborarea unui SDP sau unui OF. Matricea responsabilitatilor este foarte pe larg utilizata in gestiunea proiectelor si sefii de echipe specializate sunt afectati micilor proiecte. Aceasta matrice, mai este denumita si diagrama a responsabilitatilor ierarhice, care rezuma sarcinile de indeplinit. Ea indica cine este responsabil de ce activitate din proiect.

Matriciile de responsabilitati simple sunt utilizate in planificarea si atribuirea de responsabilitati reale a micilor proiecte si sub-proiecte ale proiectelor complexe de mare anvergura.

Matricea respnsabilitatilor complexe precizeaza nu numai responsabilitatile fiecaruia, dar ea serveste de asemnea sa clarifice interferentele dintre unitati si angajati, care solicita o anumita coordonare. Matricea responsabilitatilor permite tuturor participantilor la un proiect sa-si faca o idee asupra responsabilitatilor si sa se inteleaga asupra sarcinilor. Privilegiind o matrice a responsabilitatilor si deterinind persoane in pozitie de autoritate, responsabilitatile fiecaruia si canalele de comunicare ale fiecarui grup, relatia dintre unitatile organizationale si continutul muncii in cadrul proiectului este mai clara.

Prima etapa a procesului de planificare si de departe cea mai importanta, consista in definirea proiectului cu claritate si precizie. Absenta unei astfel de planificari constituie principala ratiune a esecului proiectului. Trebuie sa se faca apel la un SDP sau un OF sau la o matrice de responsabilitati? Totul depinde de anvergura proiectului. Oricare ar fi metoda folosita, proiectul trebuie sa fie descris cu suficienta precizie pentru a asigura un anumit control al acestor activitati.