Modelul Procesului TenStep include o serie de remarci elementare.

0.0.6.P1 "Pasii" nu Implica o Ordine Secventiala

Este important de observat ca cei zece pasi ai metodologiei TenStep nu presupun o abordare secventiala. Intr-adevar, trebuie sa definesti si planifici proiectul inainte de trece la managementul executiei sale. Asadar, Pasii 1.0 si 2.0 vor fi parcursi inaintea celorlalti. Cu toate acestea, activitatile din Pasii 3.0 - 10.0 se fac in paralel.

0.0.6.P2 Pasul 3 este Pasul Cheie al Integrarii

Toate procesele de management de proiect sunt integrate in Pasul 3.0 - Managementul Planului -, de indata ce proiectul intra in derulare. Integrarea apare aici datorita filosofiei de delimitare / delimitative a procesului TenStep exprimata prin sintagma: "Se executa doar activitatile programate!" Cu alte cuvinte, tot volumul de munca al proiectului ar trebui sa fie inclus in programul de activitati iar daca o activitate nu este programata, atunci ea nu trebuie executata.

Programul de activitati este punctul central in managementul de proiect iar toate celelalte procese de management de proiect sunt integrate in programul de activitati. Ar trebui sa aloci in program activitati si timp pentru comunicare, managementul continutului, pentru actualizarea programului de activitati si tuturor celorlalte activitati de management de proiect. Integrarea apare in momentul in care procesele de management de proiect se intrepatrund, precum si atunci cand activitatile de management de proiect si cele ale ciclului de viata al proiectului se suprapun. Aveti in vedere urmatoarele exemple:

• O cerere de schimbare majora a sferei de cuprindere a proiectului este aprobata, determinand mai mult efort si costuri mai mari. Acesta este un exemplu tipic de integrare a managementului de proiect si activitatilor ciclului de viata al proiectului. Impactul este reflectat in programul de activitati si bugetul actualizate.
• Identifici riscuri si elaborezi un Plan de Management al Riscurilor pentru a le gestiona. Apoi comunici Planul de Management al Riscurilor rezultat tuturor participantilor interesati, asteptand un feedback. Aceasta este o integrare a managementului riscului si comunicarii. Din moment ce toate aceste activitati cer timp si efort, ele vor fi incluse in programul de activitati iar integrarea apare la acest pas.

Intreg volumul de munca al proiectului trebuie reflectat in programul de activitati si in buget. In consecinta, acest pas apare acolo unde se realizeaza managementul ci controlul proiectului si reprezinta locul in care toate activitatile ciclului de viata si ale managementului de proiect sunt planificate, executate, urmarite si integrate. 

0.0.6.P3 Pasii Superiori Implica un Nivel mai Mare de Complexitate a Managementului de Proiect

Pasii superiori ai procesului TenStep implica un nivel mai avansat de rafinament al managementului de proiect. De exemplu, proiectele de anvergura mai mica nu au neaparata nevoie de managementul riscului (Pasul 7.0) din moment ce in mod tipic acestea nu prezinta multe riscuri. Similar, managementul calitatii (Pasul 9.0) si managementul indicatorilor (Pasul 10.0) pot necesita destul de multa munca, ceea ce inseamna ca aceste procese nu se aplica riguros in cazul proiectelor de mica si medie anvergura.

(insert picture)

 

0.0.6.P4 TenStep Nu Include Ciclul de Viata al Proiectului

Metodologia de management de proiect este ca o umbrela sub care sunt executate restul activitatilor proiectului. Tine minte ca managementul de proiect - si nu proiectul in sine - este cel care faciliteaza succesul proiectului. Activitatile proiectului sunt definite generic "ciclul de viata al proiectului". Indiferent de tipul de activitatilor, ciclul de viata urmeaza in mod tipic un proces ce include fazele de analiza, proiectare, constructie, testare si implementare (sau unul din multe alte cicluri de viata a proiectelelor). Admitand importanta intelegerii procesului necesar pentru producerea livrabilelor proiectului reamintim ca acest subiect nu se afla in sfera de cuprindere a procesului TenStep. (Ciclul de viata al proiectului este explicat in detaliu in produsul LifecycleStep, disponibil la http://www.lifecyclestep.com/.)

0.0.6.P5 TenStep Nu Include Colectarea de Cerinte Detaliate

Unele metodologii includ colectarea cerintelor de business drept o componenta a procesului de management de proiect. TenStep Project Management Process presupune un volum satisfacator de analiza avansata astfel incat sa permita elaborarea Documentului de Definire a Proiectului. In alte cazuri, faza de analiza formalizata / cerintele de business este o componenta a ciclului de viata al proiectului si nu intra in sfera de cuprindere a procesului de management de proiect. (Pentru mai multe detalii privind Faza de Analiza consultati produsul LifecycleStep disponibil la http://www.lifecyclestep.com/.)

Multi manageri de proiect sunt preocupati ca la momentul elaborarii Documentului de Definire a Proiectului si a programului de activitati li se va cere sa prezinte o estimare detaliata a volumului de lucru necesar proiectului. Cu toate acestea, cerintele detaliate ale proiectului inca nu au fost colectate. Atunci cum ar trebui sa estimezi volumul de lucru fara sa incluzi cerintele detaliate? Pare a fi o intrebare valida. Insa, cand vorbim de adunarea cerintelor detaliate, de obicei, ne referim la Faza de Analiza a ciclului de viata al proiectului si nu la activitatile de definire si planificare a proiectului de la inceputul procesului de management de proiect. 

Initial te-ai putea gandi ca poate ar trebui sa dispui de cerintele detaliate inainte de a emite o estimare angajanta privind volumul de lucru. Totusi, este cu adevarat practic sa procedam astfel? Sa presupunem ca te ocupi de un proiect tipic de dezvoltare IT. Proiectul ar putea dura sase luni din care procesul de colectare a cerintelor ar putea dura intre sase si opt (sau mai multe) saptamani. Deci, chiar ar trebui sa amanam pregatirea estimarilor proiectului pana cand cerintele vor fi colectate si aprobate? In acest caz, pana la validarea costurilor totale si a termenului de executie, proiectul ar putea fi finalizat deja in proportie de o treime. Daca vei constata ca proiectul nu este rentabil din perspectiva relatiei cost-beneficiu, deja vei fi cheltuit o suma semnificativa de bani. Este mult prea tarziu insa si acesta este motivul pentru care majoritatea metodologiilor de management de proiect nu includ colectarea de cerinte de business detaliate.

De asemenea, daca folosesti acelasi argument, ai putea spune ca inca nu esti sigur ca ar trebui sa estimezi volumul de munca fara a realiza mai intai proiectarea iar apoi ca ar trebui sa-l estimezi pana la finalizarea activitatilor Fazei de Constructie, etc. Remarcati ca acelasi tip de rationament poate fi dus la extrema.

Urmatoarele trei abordari iti vor permite sa estimezi volumul de lucru inainte de a fi adunat cerintele de business detaliate. (Abordarile pleaca de la prezumtia ca adunarea cerintelor reprezinta primul pas din executia proiectului. Acesta mai este denumit si modelul Waterfall. Daca utilizezi tehnici din categoriile "Agile" sau iterative poti colecta cerintele pas cu pas pe tot parcursul proiectului.)

• Estimeaza volumul de munca cu o marja de 10% cand definesti si planifici proiectul. Aceasta este abordarea traditionala si in multe/majoritatea cazurilor inca este viabila. Se presupune totusi ca managerul de proiect si/sau echipa de proiect au mai executat acest gen de activitati astfel ca pot estima volumul de munca necesar cu o marja de 10% in baza cerintelor cu un grad ridicat de complexitate ce au fost colectate drept o parte componenta a elaborarii Documentului de Definire a Proiectului. Daca dupa colectarea cerintelor descoperi ca ai estimat incorect atunci trebuie sa semnalezi situatia si sa ceri mai multi bani. Bineinteles ca aceeasi verificare trebuie facuta la sfarsitul fiecare faze a proiectului indiferent de tehnicile utilizate.
• Descompune activitatile in componente mai mici. Daca nu te simti confortabil sa furnizezi o estimare totala a proiectului cu o marja de 10% atunci poti descompune proiectul mai mare in mai multe mini-proiecte. Cand utilizezi aceasta tehnica ajungi de obicei sa definesti un proiect special pentru colectarea cerintelor. Ar trebui sa poti estima proiectul de colectare a cerintelor cu o marja de 10%. Dupa incheierea acestui proiect poti folosi informatiile pentru a defini un al doilea proiect pentru a executa activitatile ramase. Cu optimism acum poti estima volumul de munca ramas cu o marja de 10%. Cand termini, livrabilele finale vor fi fost obtinute prin doua proiecte, ambele estimate si conduse intr-o marja de buget si durata de 10%.
• Intai "estimeaza din burta" si dupa ce cerintele sunt colectate, consolideaza durata activitatilor si bugetul. Aceasta este o variatie a primei tehnici descrisa mai sus. In aceasta abordare, managerul de proiect furnizeaza o estimare "burtometrica optima" a volumului de munca concomitent cu elaborarea Documentului de Definire a Proiectului si a programului de activitati. Totusi, in baza regulilor organizationale, managerul de proiect nu va fi responsabil pentru aceasta estimare (spre deosebire de prima optiune de mai sus). Aceasta este doar cea mai buna estimare din burta posibila date fiind informatiile la acel moment. Dupa finalizarea cerintelor, managerul de proiect furnizeaza o estimare mai detaliata a volumului de munca in marja de 10%. Managerul de proiect va fi responsabil pentru aceasta estimare.

Multi manageri de proiect cred ca cea mai buna abordare consta in colectarea repetativa a cerintelor. Totusi, ciclul de viata iterativ nu ofera un raspuns referitor la modalitatea de estimare a proiectului intr-o marja de 10%. De fapt, abordarile iterative ar putea chiar ingreuna estimarea acestui nivel de precizie. Cele trei solutii de mai sus furnizeaza un set de tehnici mai viabile pentru a estima volumul de munca intr-o marja de 10% inainte de a incepe executia proiectului. 

0.0.6.P6 TenStep Nu Considera Achizitiile a Responsabilitate Cheie a Managementului de Proiect

In mod similar, unele metodologii includ activitatile de interactiune cu furnizorii si de contractare drept fiind o componenta esentiala a procesului de management de proiect. TenStep Project Management Process considera ca aprobarile, cautarile si evaluarile contractelor si ale furnizorilor fac parte din activitatile proiectului si nu din managementul proiectului. In multe organizatii aceste activitati sunt executate de un departament distinct, fie el de Achizitii sau Legal. Desi managerul de proiect trebuie sa aiba cunostiinte solide in acest domeniu, in filosofia TenStep acestea nu constituie abilitati esentiale in managementul de proiect. Bineinteles ca furnizorii vor introduce riscuri, probleme, schimbari in sfera de cuprindere a proiectului, preocupari privind calitatea, etc., astfel ca procesul TenStep poate fi totusi folosit pentru a gestiona aceste aspecte ale relatiei vanzatorilor cu proiectul.

0.0.6.P7 Procesul de Finantare a Proiectului Nu este Inclus in Metodologia TenStep

Procesul TenStep porneste de la prezumtia ca finantarea si necesarul de personal ale proiectului au fost aprobate. Fiecare organizatie are cateva procese pe care le utilizeaza pentru a identifica si rafina idei de proiecte, pentru a le prioritiza si pentru a le finanta. Procesul TenStep nu include aceste activitati incipiente ale unui proiect si nu le considera componente ale procesului de management de proiect. (TenStep, Inc. a elaborat o metodologie aparte pentru aceste activitati, respectiv PortfolioStep). Procesul TenStep incepe din momentul in care proiectul este definit in mod formal si i s-a desemnat un manager de proiect. Se presupune ca justificarea de business, finantarea si aprobarea resurselor pentru proiect au fost deja finalizate.

0.0.6.P8 Proiectul Incepe Oficial Cand este Desemnat un Manager de Proiect

In mod tipic prima atributie a managerului de proiect consta in definirea formala a proiectului folosind Documentul de Definire a Proiectului si in  elaborarea planului de proiect. Aceasta definitie a momentului de inceput al proiectului ramane aplicabila chiar daca managerul formal de proiect nu finalizeaza Documentul de Definire a Proiectului si programul de activitati (ele ar putea sa fi fost incheiate chair mai repede). Tine minte ca managementul de proiect este un rol. Oricare ar fi persoana care finalizeaza Documentul de Definire a Proiectului si programul de activitati, ea suplineste rolul managerului de proiect chiar daca o alta persoana este ulterior desemnata sa ocupe formal acest rol.