# NUPP

Principiile Cvasi Universale Aplicabile Proiectelor

[image]

Aceasta este o versiune descărcabilă a manualului online (https://omimo.org/ro/modules/nupp/), generată la data 2026‑07‑02. Verificați site‑ul web pentru versiuni mai recente.

NUPP este dezvoltat în cadrul OMIMO (https://omimo.org/ro/), o suită de module deschise,concepute conform unei abordări minimaliste.

Acest manual poate fi utilizat și distribuit liber în baza licenței Creative Commons Attribution 4.0 International.

OMIMO este cofinanțat de Uniunea Europeană. Opiniile și punctele de vedere exprimate aparțin însă exclusiv OMIMO și nu reflectă neapărat poziția Uniunii Europene sau a EPOS VZW. Nici Uniunea Europeană, nici autoritatea finanțatoare nu pot fi considerate responsabile pentru acestea.

Tradus si optimizat de: Raul JURJ, Jan-Florin PANAITE, Daniel ORZATA și Cristina Denissa DUMITRESCU


## introducere

NUPP (Nearly Universal Principles of Projects / Principiile Cvasi Universale Aplicabile Proiectelor) reprezintă o colecție de principii aproape universale aplicabile tuturor proiectelor: sunt acele principii pe care ați face bine să le urmați în toate proiectele, indiferent de metodologiile și abordările pe care le folosiți, pentru a vă maximiza succesul.

Fiecare dintre resursele și metodele disponibile pentru derularea proiectelor se bazează pe unele dintre aceste NUP-uri (Nearly Universal Principles / Principiile Cvasi Universale Aplicabile Proiectelor). Cu toate acestea, următoarele aspecte trebuiesc avute în vedere:

  - De obicei nu sunt aplicate efectiv toate principiile, și tocmai de aceea, ar fi util pentru practicieni să ia în considerare toate NUPP-urile și nu doar o subcategorie aparte.
  - Principiile de bază nu sunt de obicei clarificate suficient în cadrul resurselor și metodelor folosite, iar majoritatea practicienilor sunt atât de implicați pe detaliile practice încât pierd din vedere principiile aplicabile și iau decizii care nu sunt în linie cu acestea.

NUPP este compatibil cu toate metodele, sistemele, resursele și abordările importante aplicabile domeniului de management de proiect, cum ar fi PRINCE2^(®), Ghidul PMBOK^(®), P3.express, PM², DSDM^(®), XP și Scrum. Este posibil să nu fie compatibil cu anumite interpretări ale acestor sisteme și pentru aceste cazuri, NUPP încearcă să încurajeze practicienii să își reconsidere interpretările.

NUPP cuprinde următoarele NUP-uri (Principiile Cvasi Universale Aplicabile Proiectelor):

  - NUP1 — Preferați rezultatele și adevărul în locul afilierilor
  - NUP2 — Conservați-vă și optimizați-vă energia și resursele
  - NUP3 — Fiți întotdeauna un lider cu inițiativă
  - NUP4 — Amintiți-vă că un lanț este la fel de puternic ca și veriga sa cea mai slabă
  - NUP5 — Nu inițiați nici o activitate fără un scop bine definit
  - NUP6 — Folosiți elemente reutilizabile


## NUP1 Preferați rezultatele și adevărul în locul afilierilor

[image]

Cu toții avem o tendință naturală de a face parte din grupuri, tendință care adesea depășește forma sa de bază și conduce la crearea de afilieri puternice care cauzează probleme. Pierdem mult mai mult decât câștigăm din cauza afilierilor. Putem deveni experți mai profesioniști și mai eficienți dacă nu ne limităm identitatea și apartenențele la anumite grupuri.


### Exemplu: Adaptiv (Agile) vs. Predictiv (Waterfall)

Într-o perioadă în care era utilizată cu precădere abordarea predictivă, un grup de oameni foarte entuziaști, care au fost suficient de curajoși să încerce abordări adaptive în domeniul de dezvoltare de software IT, s-au reunit și au numit aceasta nouă abordare ″Agile″. Aceasta a fost o inițiativă excelentă pentru a nu limita alegerile doar la ceea ce părea necesar. Există încă mulți oameni entuziaști și orientați spre rezultate în comunitatea Agile, dar din păcate există și unii oameni în această comunitate care transformă Agile într-un cult și îi consideră pe toți cei din afară, drept dușmani. Acest lucru creează o serie de probleme, precum:

  - Nu permite ca membrii comunității să învețe de la nimeni din afara grupului lor
  - Îi descurajează pe cei din afară să învețe de la ei
  - Face ca apartenența la grup să fie mai importantă decât scopul real, care, la rândul său, îi împiedică pe mulți dintre membrii săi să învețe adevăratul sens al ″Agilității″.

Această problemă poate fi redusă semnificativ, poate chiar eliminată, utilizând ″Agile″ doar ca etichetă, ca referință la o abordare practicată mai degrabă în dezvoltarea IT, decât ca o comunitate de membri; și cooptând oameni care se consideră creatori, capabili de soluționarea problemelor și lideri, care văd conceptul de ″Agile″ nu ca pe o identitate a lor, ci ca fiind unul dintre mulți alți factori care pot contribui în domeniu.

Nu există un război Agile - Waterfall (Adaptiv - Predictiv) pentru profesioniștii adevărați.


### Exemplu: PRINCE2^(®) vs. Ghidul PMBOK^(®)

Există mulți profesioniști în comunitate care se asociază fie cu PRINCE2^(®), fie cu Ghidul PMBOK^(®) (de obicei din cauza locației geografice) și care nu sunt familiarizați cu celălalt concept. Toți putem avea preferințe față de anumite resurse, însă nu ne identificăm cu acestea și este important să ne familiarizăm cu toate celelalte concepte pentru a ne lărgi perspectivele și alegerile.

Adevăratul profesionist este deschis tuturor ideilor, le caută, învață despre ele și le folosește când și cum este necesar, fără a face apel la afiliere.


### Exemplu: Învățare continuă

Afilierile aduc satisfacție persoanei respective datorită sentimentului de apartenență pe care îl generează, dar nu o determină să învețe ba uneori, chiar o descurajează să învețe de teama de a nu o pierde. Când sunteți o persoană liberă, un expert fără afiliere, trebuie să completați golul cunoștințelor cu învățare continuă.

Ceea ce credem astăzi nu este neapărat adevărul. Este doar cea mai bună înțelegere a noastră de până acum, care trebuie îmbunătățită pe măsură ce ne dezvoltăm. Nu este în regulă ca ideile cuiva să fie exact aceleași cu cele de acum câțiva ani. Acesta este și cazul NUPP: dacă revii după câțiva ani și vezi exact același lucru ar trebui să devii suspicios.


### Exemplu: Deschiderea

Când combateți pe cineva, asigurați-vă că vă îndreptați obiecția asupra ideii și nu asupra persoanei. Acest lucru ajută la prevenirea multor tensiuni. Într-un mod similar, atunci când cineva vă combate sau vi se opune, încercați să nu interpretați acest lucru ca pe un război împotriva voastră, ci mai degrabă ca o discuție pe tema ideilor voastre și rămâneți deschis față de acesta. Nu ascultați pentru a răspunde, ascultați pentru a înțelege; și colaborați cu cealaltă persoană pentru a îmbunătăți ideea respectivă.

Unii oameni vă pot viza în mod intenționat pe dvs. în locul ideii discutate, caz în care ar trebui să-i determinați să se concentreze asupra ideii înainte de a continua discuția și să încerce să rămână așa pe tot parcursul conversației.


## NUP2 Conservați-vă și optimizați-vă energia și resursele

[image]

Resursele sunt limitate. Resursele alocate unui proiect sunt limitate, la fel ca și energia mentală pe care o aveți pentru a lua decizii bune. Ar trebui să vă păstrați și să optimizați această resursă în folosul dvs. și al proiectului și să ajutați ceilalți membri ai echipei să facă același lucru.


### Exemplu: Regula 80/20

O mare parte din beneficiile așteptate în managementul proiectului pot fi obținute depunând o cantitate mică de efort. În majoritatea cazurilor, să atingeți 100% din beneficiile așteptate este foarte costisitor și nejustificabil. Trebuie să luați în considerare această regulă în tot ceea ce faceți și să îi încurajați și pe ceilalți să facă la fel.


### Exemplu: Oboseala decizională

Folosim o singură sursă de energie mentală pentru a lua toate tipurile de decizii și de asemenea, pentru a ne exprima hotărârile luate. Dacă folosiți o mare parte din această sursă pentru a lua decizii inutile sau neimportante, veți avea mai puțină energie pentru deciziile importante, ceea ce poate conduce la obținerea unor rezultate slabe. Acesta este unul dintre motivele pentru care ar trebui să evitați micro-managementul (Principiul ″Gestionați prin excepție″ din metodologia PRINCE2^(®)).

Conflictele care țin de idei pot fi de ajutor, dar cele care țin de oameni sunt de obicei dăunătoare proiectului, iar una dintre consecințe este că epuizează energia mentală a membrilor echipei. Dacă observați un astfel de conflict, ar trebui să faceți tot posibilul pentru a găsi cauza care l-a provocat și a o rezolva.


### Exemplu: Ai grijă de tine!

Deciziile pe care le luați și exprimarea acestor hotărâri vă consumă sursa de energia mentală. Pe de altă parte, această sursă se încarcă cu energie atunci când dormiți și mâncați corect. Deci, ar trebui să aveți mare grijă de dvs.; asigurați-vă că aveți suficient somn, odihnă și mâncați corect. Dacă aveți obiceiuri dăunătoare sau probleme cu somnul, nu trebuie să vă descurajați; există mulți specialiști care vă pot ajuta să remediați aceste probleme. Deși studiile nu sunt încă concludente, activitatea fizică vă poate ajuta, de asemenea, în reîncărcarea sursei de energie.

Încercați să încurajați membrii echipei să facă la fel ca dvs. În primul rând, asigurați-vă că lucrează într-un ritm durabil și fără prea multe ore suplimentare. Apoi - dacă aveți posibilitatea - încercați să le puneți la dispoziție mâncare sănătoasă și bogată in proteine, gustări și lichide în timpul orelor de lucru.


### Exemplu: Echilibrul dintre viața profesională și cea privată

Mulți dintre noi adoră ceea ce fac în viața profesională, dar asta nu presupune că locul de muncă reprezintă totul în viață. În același mod în care vă organizați viața profesională, ar trebui să vă planificați și să vă organizați viața dvs. personală, în așa fel încât să vă simțiți împliniți și fericiți. Cu cât sunteți mai fericit, cu atât aveți mai mult succes la locul de muncă. Dacă puteți, încercați să încurajați membrii echipei dvs. să facă același lucru.


### Exemplu: Motivația

Motivația este un concept complex. Există câteva resurse interesante și utile pe această temă, precum și multe altele fără suport științific. Cu toate acestea, ar trebui să descoperiți aceste resurse și să le utilizați continuu, deoarece pot crește energia mentală a echipei și posibilitatea de a obține rezultate mai bune pentru proiect.

Cel mai ușor mod de a motiva oamenii este să le fii recunoscător pentru munca depusă, să zâmbești din inimă sau le spui un simplu ″mulțumesc″. Totuși, aveți grijă, deoarece multe dintre formele comune de motivație, cum ar fi recompensele în bani, pot avea chiar un efect negativ.


### Exemplu: Colaborarea și munca în echipă

Oamenii care lucrează bine împreună au puterea de a obține rezultate mai bune, dar rețineți că cel mai important lucru este că oamenii sunt ființe sociale și se bucură să facă parte dintr-un grup. Dacă puteți elimina aspectele negative ale muncii în echipă și puteți crea un mediu plăcut, membrii de echipă ai proiectului vor fi mai fericiți.

Totuși, cu toții suntem diferiți, iar unii membri ai echipei au nevoie de relaxare, concentrare sau sunt mai solitari decât alții; de obicei este necesar a apela la un act de echilibru.


### Exemplu: Cultura echipei

Există tendința ca diferite părți interesate să creeze sau să ia în considerare părerile unor subgrupuri și să provoace tensiune cu alte grupuri; de exemplu, acei membri care se concentrează pe profitul pe care îl poate genera proiectul vs. echipa care construiește efectiv produsul. Această tensiune consumă multă energie, și este unul dintre motivele pentru care ar trebui să încercăm să construim o cultură de echipă, în care toți membrii lucrează împreună și urmăresc același scop.


### Exemplu: Înțelepciunea mulțimilor

Atunci când un număr mare de oameni diferiți se reunesc și lucrează într-un mediu organizat, există un mare potențial de a obține rezultate, opinii și soluții foarte bune, care ar putea fi chiar mai bune decât cele provenite de la experți unici.

Dacă aveți această opțiune, o puteți folosi periodic pentru a cere membrilor echipei să vă ajute să rezolvați problemele dificile din proiect. Pe lângă posibilitatea de a obține rezultate bune, le permite, de asemenea, membrilor echipei să știe că opiniile lor sunt apreciate și că joacă un rol important în proiect, ceea ce va crește nivelul lor de energie. Activitatea E02 din P3.express este un exemplu de utilizare a înțelepciunii mulțimilor în proiecte.


### Exemplu: Facilitator responsabil de proiect

Dacă sunteți manager de proiect, majoritatea lucrurilor pe care le faceți au o natură de facilitare (sau cel puțin așa ar trebui să aibă). Pe de altă parte, puteți vedea că membrii echipei au avut experiențe diferite cu managerii de proiecte din trecut și că aceste experiențe au impact asupra relației lor cu dvs.: o parte din energia lor este utilizată pentru a vă analiza comportamentul pentru eventuale reacții viitoare în loc să aibă încredere în dvs. În acest caz, vă puteți schimba titlul de manager de proiect în Facilitator responsabil de proiect. La urma urmei, asta faceți cu adevărat în proiect.


## NUP3 Fiți întotdeauna un lider cu inițiativă

[image]

Există o tendință naturală în noi de a fi reactivi. Acest lucru ne ajută cumva să ne păstrăm energia, ocupându-ne de chestiuni fără însemnătate sau ne poate determina să obținem rezultate mai bune atunci când avem de-a face cu lucruri în care suntem complet incompetenți. Aceste situații sunt complet diferite de situațiile existente în proiectele noastre, unde putem obține rezultate mai bune doar fiind proactivi.


### Exemplu: Planificarea

Dacă doriți să conduceți către o locație nouă și sunteți în întârziere, aveți opțiunea să începeți să conduceți imediat pentru a „economisi timp” și veți face față posibilelor probleme atunci când acestea vor apărea. Abordarea proactivă presupune să îți iei puțin timp la început pentru a fixa sistemul de navigație astfel încât să vă ofere cea mai rapidă rută în funcție de trafic și posibilele accidente și blocaje, și apoi începi efectiv să conduci; acest lucru înseamnă să vă alocați timp pentru planificare, înainte de execuția propriu-zisă, pentru a evita problemele ulterioare și, în final, pentru a economisi timp.

Spre deosebire de ceea ce cred unii oameni despre proiectele Agile, planificarea este necesară întotdeauna și trebuie luate în considerare tipul planificării și nivelul de detaliere. Planificarea înainte de execuție este considerată o abordare proactivă.

Amintiți-vă citatul: dați-mi șase ore pentru a tăia un copac și voi petrece primele patru ascuțind toporul.

Dacă vă regăsiți într-un proiect de tip predictiv, puteți petrece patru ore ascuțind toporul, pentru că sunteți sigur că veți tăia copacul. Într-un proiect Agile, nu sunteți sigur dacă veți tăia un copac, dacă veți strânge crengile rupte, dacă veți pune gazon, dacă exploatați cărbune sau faceți altceva. Totuși, trebuie să aveți o pregătire generală pentru toate acestea (să știți unde este cel mai apropiat magazin de unelte, de exemplu) și să aveți o pregătire specifică (ascuțirea toporului) atunci când vă veți concentra pe o anumită soluție; la acest lucru se referă planificarea.


### Exemplu: Planificarea execuției

Planificarea modului în care vom executa proiectul este o abordare proactivă. Această abordare poate fi extinsă chiar și prin planificarea modului în care vom planifica execuția; acesta este conceptul de plan de management descris în ghidul PMBOK^(®), strategiile de management descrise în PRINCE2^(®) și abordările din DSDM^(®).


### Exemplu: Planificare continuă

Realitatea rareori se potrivește cu ceea ce am planificat, și asta este în regulă să fie așa - dar trebuie să ne adaptăm continuu planurile pentru a ne asigura că acestea rămân realiste și practice. Adaptarea planurilor ar trebui să o facem imediat ce este necesară și nu doar atunci când întâmpinăm probleme. Aceasta este o abordare proactivă.


### Exemplu: Gestionarea riscurilor

Întregul concept de gestionare a riscurilor se bazează pe pro-activitate: atunci când ne confruntăm cu evenimente incerte, în loc să așteptăm să vedem ce se întâmplă și apoi să reacționăm la acestea, ne gândim la posibilități și impact, luăm în considerare planuri de răspuns la riscuri și probabilitatea apariției riscurilor, facem ceva înainte ca riscurile să se întâmple.

Rețineți că tot ceea ce facem în cadrul proiectelor este un lucru serios; sunt proiecte în care este pusă la încercare viața oamenilor.


### Exemplu: Definiți roluri și responsabilități

Puteți lăsa membrii echipei de proiect să lucreze fără a le atribui roluri și responsabilități clare dar, mai devreme sau mai târziu, tot se va contura o oarecare formă de roluri și responsabilități; acest mod de a lucra este prea costisitor și la urma urmei, este posibil să nu funcționeze bine. Abordarea proactivă presupune să definești rolurile și responsabilitățile din timp și să le adaptezi după cum este necesar. Acest lucru ușurează munca tuturor iar echipa se poate concentra pe obținerea rezultatelor, în loc să decidă cine ce are de făcut.

Numărul și varietatea rolurilor depind de tipul și dimensiunea proiectului; putem defini rolurile simplu, așa cum sunt prezentate în Scrum, mai detaliat, așa cum sunt prezentate în P3.express sau și mai cuprinzător, așa cum sunt prezentate în DSDM^(®) și PRINCE2^(®). Cu toate acestea, nu uitați că descrierile de roluri din cadrul acestor metode se referă doar la activitățile de management și că trebuie întotdeauna să adăugați descrieri de roluri și pentru aspectele tehnice.


### Exemplu: Opțiuni disponibile

Ar trebui să închideți proiectul mai devreme sau să-l continuați?

Rareori există doar două opțiuni, chiar dacă întrebarea sugerează acest lucru. Trebuie să aveți o abordare proactivă și să luați în considerare toate alegerile înainte de a lua o decizie. Poate puteți redefini scopul proiectul; poate puteți întrerupe activitățile proiectului până când opțiunile devin mai clare; sau poate puteți schimba întreaga abordare a proiectului (de exemplu, să apelați la externalizare) etc.


### Exemplu: Gândirea critică

Cu toții avem multe prejudecăți care, pe de o parte, ne ajută să supraviețuim iar pe de altă parte, ne determină să luăm decizii proaste. Când vine vorba de luarea unor decizii importante cu privire la proiect, cel mai bine este să ne oprim pentru o vreme și să luăm în considerare toate prejudecățile care pot avea impact asupra deciziei noastre, înainte ca acestea să cauzeze probleme.

Ca referință, puteți consulta lista prejudecăților cognitive descrise în Wikipedia.

Există chiar cadre decizionale pe care le puteți utiliza pentru a lua decizii mai bune. La început, poate fi distractiv și chiar enervant să le folosești, dar vă veți obișnuiți cu acestea și veți vedea avantajele fără a conștientiza efortul.


### Exemplu: Transparență

Nu ne place să avem întârzieri în derularea proiectului sau să întâmpinăm orice alte probleme, dar acest lucru nu înseamnă că trebuie să le ascundem. Fiți transparenți și informați-vă partenerii, deoarece unii dintre ei ar putea să vă ajute și, în plus, mai devreme sau mai târziu, vor afla despre aceste probleme și consecințele lor, iar unele probleme ar putea necesita demararea rapidă de acțiuni chiar din partea lor (de exemplu, acceptarea consecințelor negative).


### Exemplu: Comunicați eficient

Pot exista multe cazuri în care trimiteți rapoarte părților interesate și acestea nu vă oferă niciun răspuns. S-ar putea să credeți că totul este în regulă doar pentru că nu există o reacție negativă, dar este foarte posibil să nu fie așa. Trebuie să fiți proactivi și să verificați dacă raportul le-a fost de folos și dacă a servit scopului lor – folosiți-vă de răspunsul lor pentru a vă adapta metoda de comunicare; în caz contrar, această problemă ascunsă poate cauza probleme grave mai târziu, când este prea dificil de remediat.


### Exemplu: Asumați-vă responsabilitatea

Este ușor să dai vina pe alții pentru rezultatele slabe obținute. De exemplu, s-ar putea să doriți ca organizația dvs. să vă ofere autoritate deplină pentru a schimba întru totul proiectul ca sa-l realizați perfect, dar acest lucru nu se întâmplă, și ca urmare, proiectul eșuează. Aceasta nu reprezintă o abordare proactivă.

O abordare proactivă este atunci când vă asumați responsabilitatea și faceți tot ce vă stă în putință pentru succesul proiectului, ținând cont de constrângerile stabilite. Nu vă puteți aștepta ca organizația să aibă încredere deplină în voi și să vă ofere totul în speranța că veți obține rezultate bune, mai ales când au văzut atât de multe proiecte eșuate. Trebuie să faceți astfel încât să aduceți o mică îmbunătățire în cadrul proiectului ținând cont de constrângerilor stabilite, să folosiți acest lucru pentru a câștiga puțină încredere, câteva resurse în plus și puțin mai multă toleranță pentru constrângeri, apoi folosiți toate cele câștigate pentru o aduce o îmbunătățire de substanță și continuați așa până când vă atingeți obiectivul.


## NUP4 Amintiți-vă că un lanț este la fel de puternic ca și veriga sa cea mai slabă

[image]

În cadrul unui proiect există componente diverse și toate au nevoie de atenția noastră; trebuie să avem o perspectivă holistică a proiectului. Nu este suficient să acorzi atenție numai unei componente aparent importante (de exemplu, timpul), deoarece componentele interacționează și funcționează corect doar dacă toate primesc atenția cuvenită.


### Exemplu: Totul este despre termenul limită!

Să presupunem că, ridicați o construcție pentru Jocurile Olimpice. Avem un termen limită clar de finalizare, ceea ce face ca modul de gestionare a timpului în cadrul proiectului să fie extrem de important. Dar este oare corect să acordăm atenție doar timpului? Ce se întâmplă dacă calitatea este atât de scăzută încât necesită refacerea lucrărilor după un timp. Acest lucru ar putea avea un impact asupra timpului, așadar este nevoie și de gestionarea calității. Este posibil să vi se ceară să amenajați o grădină extravagantă în faza inițială a proiectului, dar dvs. știți că dacă nu există suficient timp pentru execuție, puteți să renunțați la idee și doar să acoperiți gradina cu iarbă, dacă ați luat în considerare din timp această posibilitate și v-ați pregătit pentru aceasta alternativă. Așadar, gestionarea scopului proiectului, este de asemenea o componentă importantă. Acum avem scopul, timpul și calitatea în centrul atenției noastre.

Ați auzit de acel exemplu celebru în care președintele Kennedy se întâlnește la NASA cu un paznic și îl întreabă ce face și el răspunde: ″Ajut la trimiterea unui om pe lună″? Ce credeți: să ai astfel de oameni în echipă, ajută la respectarea termenelor limită din proiect?

Pe măsură ce continuați să analizați, observați că fiecare componentă din cadrul proiectului contribuie la o mai bună gestionare a timpului și doar dacă acordați atenție tuturor componentelor puteți respecta cu certitudine termenul limită.


### Exemplu: Culesul cireșelor

Când oamenii se confruntă cu o varietate de metode, se spune că încep să ″culeagă cireșe″ și creează un amestec cu tot ceea ce pare interesant în diferite sisteme. De obicei, acest lucru nu funcționează, deoarece elementele alese nu funcționează izolat și trebuie să fie compatibile între ele. Orice adăugări sau modificări ale unui sistem ar trebui făcute și gândite din punct de vedere holistic.

Acesta este motivul pentru care uneori vedem elemente contradictorii în diferite metode; ceva funcționează bine într-un sistem, iar opusul său funcționează bine într-un alt sistem. Folosit singur, acest element nu poate fi considerat corect sau greșit dacă nu este poziționat într-un context.

Cea mai sigură abordare este să selectezi o metodologie pentru proiect, să o adaptezi și apoi să adăugi treptat elemente noi, luând în considerare contextul întregului sistem.


### Exemplu: Abordarea anti-proces

Unul dintre cele mai bune lucruri pe care le-au făcut metodele agile este să atragă atenția asupra aspectelor umane. Manifestul agile acordă mai multă valoare indivizilor și interacțiunilor în comparație cu procesele și instrumentele, deși este posibil să nu fie o comparație tocmai corectă. Aproape toate metodele spun că aspectele umane sunt importante dar diferența reală pe care o aduce metodele agile este că, acestea integrează aspectele umane în procesele efective și nu o tratează ca o simplă recomandare. . Deci, nu este vorba despre o competiție între aspectele umane și procese, ci mai degrabă despre modul în care aspectele umane sunt integrate în cadrul sistemului.

Nu există nici o îndoială că unii oameni încearcă să înlocuiască aspectele umane cu procese mai sofisticate, dar acest lucru este doar un exemplu de utilizare greșită a acestora. De asemenea există și opusul: oameni care încearcă să înlocuiască procesele cu aspecte umane, lucru care, de asemenea, nu funcționează.


### Exemplu: Acestea sunt toate componentele de care aveți nevoie

Când vă gândiți la componente, ar trebui să aveți grijă să nu treceți cu vederea niciunul dintre ele. Care sunt acestea? Dacă consultați diverse surse de informații, veți primi răspunsuri diferite; și totuși, niciuna dintre ele nu reprezintă întregul adevăr.

Temele la care face referire PRINCE2^(®) sunt considerate componente, dar acestea sunt doar componentele care au un rol cheie în metodologie. Celelalte componente sunt considerate adiacente.

Ghidul PMBOK^(®), deși nu este o metodologie de management de proiect, descrie în detaliu zece domenii de cunoaștere. Acestea domenii de cunoaștere sunt mai degrabă interpretări ale tuturor componentelor proiectului, realizate din perspectiva ghidului PMBOK^(®), și nu sunt descrise dintr-o perspectivă neutră (nu că ar exista neapărat o perspectivă neutră). De exemplu, în Ghidul PMBOK^(®) aspectelor umane nu li se acordă destulă atenție.

O bună sursă de informații despre componentele proiectului este și ICB. Cu toate acestea, ICB nu descrie componentele, ci mai degrabă competențele care sunt necesare în proiect. Nu conține o legătură directă cu componentele proiectului, dar ajută foarte mult la identificarea acestora.

In cadrul NUPP, nu o să avem descrisă o listă de componente, în primul rând pentru că NUPP este considerat mai degrabă un meta-sistem și nu un sistem propriu-zis și, de asemenea, pentru ca clasificarea componentelor depinde de tipul de proiect și de mediul în care se derulează; de exemplu, un proiect derulat in domeniul construcțiilor poate avea nevoie de o perspectivă diferită față de un proiect de cercetare creativă.


## NUP5 Nu inițiați nici o activitate fără un scop bine definit

[image]

Nu ar trebui să faceți nimic decât dacă are stabilit un scop bine definit. Imaginați-vă două lumi paralele în care totul este la fel, cu excepția lucrului pe care vreți să-l faceți: cât de diferite ar fi acele lumi? Merită efortul să faci diferența cu acel lucru?

Dacă nu aveți în vedere un scop clar și faceți ceva doar pentru că toți ceilalți fac, sau toată lumea spune că este important să o faceți, atunci este posibil să nu existe un beneficiu real în cazul dvs. și, prin urmare:

  - este posibil să nu obțineți nimic; sau
  - s-ar putea să existe în continuare beneficii potențiale pentru dvs., dar, pentru că nu aveți în minte scopul, modul dvs. de a face acel lucru nu poate ajuta la atingerea beneficiilor.


### Exemplu: Portofolii și programe

Dacă sunteți implicat în prioritizarea și inițierea proiectelor, ar trebui să vă asigurați că vă concentrați asupra beneficiilor pe care le aduc proiectele și problemelor care pot fi rezolvate, și nu asupra produsului care va realiza efectiv aceste lucruri. Exemplul clasic este cel al producătorului de ascensoare care obișnuia să primească reclamații cu privire la viteza ascensoarelor și, prin urmare, a derulat mai multe proiecte de creștere a vitezei ascensoarelor, fără să aibă succes deplin. A continuat să facă acest lucru până când a decis să se concentreze asupra problemei (plictiseala sau disconfortul oamenilor) în loc să se concentreze pe soluția adecvată (ascensoare mai rapide). Rezultatul a fost că au adăugat oglinzi la ascensoare și au rezolvat astfel problema simplu și ieftin.

Amintiți-vă că managementul de proiect este în principal despre a face lucrurile cum trebuie, în timp ce gestionarea portofoliului de proiecte este despre a face lucrurile care trebuie. Nu contează cât de bine vă implementați proiectele; nu va funcționa bine dacă implementați proiectele greșite. Totul este să aveți un scop.


### Exemplu: Proiectul în ansamblu

Flexibilitatea produsului variază de la proiect la proiect. În unele proiecte de dezvoltare IT, produsul este complet flexibil, iar forma sa finală depinde de feedback-ul primit în timpul proiectului, și care necesită o abordare adaptivă (Agile). Practic, aceasta reprezintă o combinație între portofoliu, program și proiect și necesită acordarea unei atenții maxime obiectivului final. Este o idee bună să documentați scopul proiectului și să îl faceți ușor accesibil; este unul dintre obiectivele ″viziunii produsului″, așa cum este utilizat conceptul în unele proiecte de tip Scrum. În proiectele Agile, se pune accent pe valoarea comercială (de business), tocmai pentru a se asigura alinierea cu scopul proiectului.

În alte tipuri de proiecte, în care produsul este relativ clar definit și există alte mecanisme pentru a se asigura că produsul identificat îndeplinește scopul proiectului, este posibil ca membrii echipei de proiect să își mute atenția de la scopul proiectului la produs (referire la principiul ″Concentrarea pe produse″ din metodologia PRINCE2^(®)), însă este necesară o minimă atenție pentru a se asigura că produsul care se construiește urmărește scopul proiectului, lucru care se poate face prin compararea beneficiilor prognozate cu beneficiile așteptate (de aici și principiul ″Justificarea continuă a afacerii″ și tema ″Cazului de afaceri″ din metodologia PRINCE2^(®)).

Atunci când un proiect este executat pentru un client extern, clientul va avea propriul său scop pentru proiect, iar organizația din care faceți parte va avea și ea un scop diferit. Pentru a asigura succesul proiectului ar trebui să înțelegeți care este scopul fiecărei părți și să tratați laolaltă toate aspectele.


### Exemplu: Monitorizarea proiectului

Concentrarea efortului asupra scopului final este un lucru necesar, dar poate fi considerat prea larg pentru derularea activităților curente din cadrul proiectului. De aceea, în practică, este necesar să se procedeze la o ierarhizare a livrabilelor proiectului. În primul rând, descrieți justificarea și beneficiile proiectului având în minte scopul final și apoi detaliați obiectivele explicite și implicite pentru variabilele proiectului (de exemplu, pe componentele de timp, cost și calitate) urmărind justificarea proiectului, care la rândul său urmărește scopul final al proiectului. Așa arată scopurile la nivel inferior, și ne sunt utile pentru derularea celor mai multe dintre sarcinile noastre zilnice.

Când vorbim de monitorizare, monitorizarea la nivel inferior a proiectului se va face folosind cel mai scăzut nivel al variabilelor, deoarece este posibil ca, la acest nivel, să nu fie posibilă urmărirea scopului final al proiectului. Dar, și în acest caz, ar trebui să aveți în minte scopul proiectului: care este scopul monitorizării?

O întrebare normală și acceptabilă pe care ar trebui să o adresăm este dacă ne aflăm pe drumul cel bun și, dacă nu, să avem o notificare care să ne readucă pe calea corectă sau să ajustăm obiectivele și să vedem dacă putem îndeplini în continuare scopul final. Prin urmare, măsurătorile noastre ar trebui să poată ajuta la îndeplinirea acestui scop de nivel inferior, iar măsurătorile adecvate sunt considerate prognoze pentru variabilele la finalizare; de exemplu: când vom putea finaliza proiectul? De câți bani am avea nevoie pentru a finaliza proiectul?

Toate celelalte măsurători, precum valorile planificate și cele realizate până în prezent, sunt doar valori intermediare de care aveți nevoie pentru a calcula prognozele, nu valorile finale pe care le utilizați în scopuri manageriale.


### Exemplu: Documente

Indiferent de abordarea pe care o folosiți în proiect, planificarea este o etapă necesară întotdeauna. Întrebarea importantă care se pune se referă la nivelul de detaliere al fiecărui tip de plan. Dacă un plan nu este suficient de detaliat atunci acel plan nu va fi eficient, iar executarea proiectului se va baza mai degrabă pe decizii ad-hoc decât pe decizii integrate, holistice. Pe de altă parte, mulți oameni încearcă să fie precauți și să adauge prea multe detalii planului lor, ceea ce va face prea dificilă pregătirea planului și actualizarea sa și prea rigid în fața incertitudinilor proiectului. Drept urmare, planul devine nerealist și inutil.

Cel mai bun mod de a decide cât de detaliat să fie planul este să vă stabiliți câte un scop pentru fiecare element din plan. De exemplu, dacă luați în considerare adăugarea de resurse la plan, ar trebui să vă gândiți la: Cum le veți folosi? Cum vor ajuta proiectul? De cât de mult efort va fi nevoie? Merită?

Uneori va fi necesar să decideți dacă doriți să aveți un anumit element inclus în planurile dvs. sau să decideți asupra modului în care doriți să planificați sau să pregătiți ceva anume. Indiferent dacă este vorba despre un caz de afaceri, despre un proiect sau un raport: ar trebui să vă întrebați tot timpul de ce pregătiți acel document și cum poate acel document să ajute proiectul.

Căutarea unui ″șablon″ reprezintă opusul la a face ceva ce are la bază scopul.


### Exemplu: Raportarea statusului

În multe proiecte, se obișnuiește să se întocmească rapoarte de status lungi. Pe baza acestui NUP, ar trebui să ne întrebăm care este scopul raportului de status și cum poate contribui la atingerea scopului proiectului, indiferent de ceea ce ar face majoritatea oamenilor.

Acest lucru poate conduce, în multe cazuri, la pregătirea unor rapoarte foarte simple de o pagină, pe care părțile interesate chiar le citesc și le înțeleg cu adevărat, în locul acelor rapoarte lungi. Acest lucru presupune să acordăm atenție scopului.

Totuși, dacă pregătiți rapoarte de o singură pagină, este posibil ca unele persoane să fie nemulțumite să creadă că nu aveți un sistem de monitorizare ″adecvat″. În practică, acest lucru vă creează un al doilea scop (pe lângă primul scop, care ajută părțile interesate să înțeleagă stadiul proiectului) și, pentru a satisface acest lucru, puteți crea pur și simplu un al doilea tip de raport care este mai lung. Cu toate acestea, nu veți amesteca acest raport cu primul raport, deoarece cele două rapoarte au scopuri diferite.


### Exemplu: Cazul de business și carta proiectului

Pregătirea documentelor, cum ar fi cazul de business și carta proiectului, este de obicei o activitate necesară, considerată plictisitoare și birocratică, pentru majoritatea oamenilor, în timp ce toate aceste documente au scopuri importante care se aplică în majoritatea proiectelor. Dacă încercați să găsiți un ″șablon″ și să îl completați, efortul dvs. este irosit; mai degrabă vedeți care este scopul real al acestor documente, vedeți dacă și cum pot fi utile în proiectul dvs. și apoi pregătiți documentele în orice mod doriți, ținând cont de aceste aspecte; acestea vor fi cu siguranță documentele cele mai potrivite.

În timp ce vă gândiți la modul în care puteți pregăti documentele pentru a urmări scopurile lor reale, este posibil să pierdeți din vedere unele scenarii. Pentru a evita acest lucru, puteți verifica ce vă sugerează unele resurse, precum PRINCE2^(®), ghidul PMBOK^(®), P3.express și DSDM^(®), iar apoi puteți evalua aceste sugestii în funcție de scopurile avute în vedere.


### Exemplu: Post-proiect

Deși proiectul are un scop specific și îl putem lua în considerare pe tot parcursul proiectului, realizarea scopului este evaluată în principal pe baza previziunilor făcute în timpul proiectului. Cu toate acestea, nu ar trebui să uităm de acest lucru la finalizarea proiectului. Este important să verificați realizarea obiectivelor după finalizarea proiectului, deoarece:

  - putem vedea cum sunt atinse obiectivele finale și putem învăța din acestea pentru proiecte viitoare
  - uneori obiectivele sunt atinse numai atunci când îndeplinim unele sarcini suplimentare după finalizarea proiectului și înțelegem necesitatea acelor sarcini suplimentare care necesită monitorizare.

Monitorizarea post-proiect este un pas necesar pentru urmărirea scopului. Este în principal responsabilitatea sistemelor de gestionare a programelor și a portofoliilor și, deoarece majoritatea companiilor nu au astfel de structuri de management, acest pas este de obicei neglijat. De aceea, metode precum P3.express și DSDM^(®) adaugă acest pas metodologiilor lor de gestionare a proiectelor.


### Exemplu: Simplitatea

Lumea este complexă și haotică, dar modelele noastre sunt aproximări abstracte care reflectă părți ale lumii și, prin urmare, pot fi simplificate. Pe de altă parte, sistemele simple funcționează de obicei mai bine, deoarece ne putem concentra asupra ideii principale.

Mulți dintre noi încercăm să obținem rezultate mai bune adăugând complexitate propriilor noastre sisteme , sperând că acesta se va potrivi cu complexitatea sistemului, chiar dacă în practică această acțiune face ca lucrul cu sistemul să fie mai dificil și de obicei ne împiedică să ne îndeplinim scopul.


### Exemplu: Personalizare

Un software (program PC) pentru redare de muzică are o construcție foarte diferită față de un software utilizat pentru echipamentele dintr-un spital sau pentru un avion în care viața oamenilor poate depinde de aceste programe, sau de un software care va fi utilizat într-un satelit și trebuie să funcționeze mulți ani fără să se prăbușească iar toate aceste programe sunt total diferite de construirea unei case de vacanță , sau a unei stații de stingere a incendiilor sau a unei fabrici de procesare.

Când aveți în minte scopul, înțelegeți mai bine cum să adaptați sistemele și documentele pentru diferite proiecte.


## NUP6 Folosiți elemente reutilizabile

[image]

O abordare ad-hoc a proiectului implică prea multă energie și resurse. De asemenea există întotdeauna riscul să se omită unele dintre elementele absolut necesare. Cel mai bun mod de a simplifica ceea ce trebuie făcut este să folosiți elemente repetabile și de preferință, să le luați în cicluri repetabile.


### Exemplu: Liste de verificare a calității

O listă de verificare este un exemplu simplu de un potențial element repetabil pe care mulți oameni îl folosesc în viața lor personală și profesională. Pentru un livrabil, luați în considerare, de exemplu, următoarele criterii de calitate:

  - În primul rând, puteți crea o listă de verificare a tuturor criteriilor, care reprezintă, în esență , o formă de planificare.
  - Ceea ce recomandă NUP6 este să încercați să faceți o generalizare: există alte rezultate similare în proiect? În acest caz, pregătiți o listă generală de verificare a calității pentru acea categorie de livrabile și utilizați-o pentru toate. Dacă există unele diferențe, păstrați lista generică și adăugați câteva elemente suplimentare pentru livrabilele individuale. Astfel obțineți liste de verificare repetabile.
  - Odată ce ați pregătit listele de verificare generice pentru diferite tipuri de livrabile, puteți identifica în cadrul acestora elementele care se repetă , determinând astfel o categorie de referință. În acest caz, în loc să repetați elementele pentru toate acele liste de verificare generice, le puteți extrage pur și simplu și le puteți așeza într-o listă de control principală. În cele din urmă, veți avea probabil o singură listă de verificare generică pentru întregul proiect. ″Definiția elementului finalizat/definition of done″ din metodologia ″Scrum″ este un exemplu de utilizare a listelor de verificare pentru calitate la nivel de proiect (printre altele). Procedând astfel, fiecare livrabil va aparține unei ierarhii de categorii și ar trebui să îndeplinească elementele care apar în listele de verificare ale tuturor categoriilor din lanțul său.

Procedând astfel, un element din lista de verificare principală va deveni repetabil pentru toate livrabilele de sub el, ceea ce economisește timp și energie în planificare și execuție.

Important este că, odată ce faceți acest lucru pentru un proiect, îl puteți adapta și utiliza pentru toate proiectele similare în viitor, și astfel aveți o formă repetabilă de planificare pentru mai multe proiecte.


### Exemplu: Procese și fluxuri de lucru

Unele rezultate sau obiective legate de acestea necesită parcurgerea unor etape care se pot standardiza și pot deveni elemente repetabile. De exemplu, dacă livrabilele trebuie să fie proiectate individual și aprobate, puteți pregăti un flux de lucru simplu care să conțină toți pașii, persoanele implicate și duratele aproximative evitând astfel multe dificultăți. Totuși, aveți grijă să nu faceți fluxurile de lucru și procesele prea complicate sau să necesite multe documente, deoarece vor avea o consecință negativă. Toți oamenii implicați în proiect ar trebui să vadă fluxurile de lucru și procesele ca pe ceva care le susține și le ușurează munca, și nu ca pe o documentație birocratică care le blochează activitatea.

Proiectele de tip ″Agile″ au elemente repetabile în abordarea lor de dezvoltare iterativă, unde anumite tipuri de activități de dezvoltare sunt repetate pentru fiecare caracteristică; de exemplu: rutina zilnică obișnuită în XP (eXtreme Programming): împerecheați, alegeți un articol, proiectați-l pe o tablă albă, construiți scripturile și codul de testare, integrați codul etc.

Pe lângă fluxurile de lucru repetabile care pot fi utilizate pentru activități tehnice, puteți avea elemente repetabile și pentru activitățile de management al proiectului. Procesele din ghidul PMBOK^(®), PRINCE2^(®) și DSDM^(®), activitățile din P3.express și evenimentele din Scrum sunt exemple ale acestui concept.


### Exemplu: Cicluri

Este util să aveți elemente repetabile pentru gestionarea proiectului. Acest lucru poate fi făcut și mai ușor prin punerea lor în cicluri repetabile. Aceste cicluri simplifică semnificativ activitățile de zi cu zi ale persoanelor implicate în gestionarea și conducerea proiectului. Ciclurile grupurilor de proces din ghidul PMBOK^(®) atunci când sunt utilizate într-un proiect cu mai multe faze, etapele în PRINCE2^(®), cicluri zilnice, săptămânale și lunare în P3.express, iterațiile și intervalele de timp în DSDM^(®) și sprinturile în Scrum sunt toate exemple ale acestui concept.

Ciclurile mai scurte sunt mai ușor de înțeles și de utilizat decât cele mai lungi; de exemplu: sprinturile în Scrum în comparație cu fazele descrise conform ghidului PMBOK^(®). Cu toate acestea, ciclurile care sunt prea scurte s-ar putea să nu fie suficiente pentru a susține anumite tipuri de proiecte, iar soluția poate fi utilizarea mai multor cicluri, cum ar fi utilizarea ciclurilor scurte de timp conform DSDM^(®), împreună cu cicluri de iterație mai lungi sau utilizarea ciclurilor zilnice, săptămânale și lunare din P3.express.


### Exemplu: Metode

Folosirea unei metodologii sau a unui cadru pentru derularea unui proiect reprezintă un alt mod de utilizare a elementelor repetabile. Acesta poate fi un sistem existent, cum ar fi PRINCE2^(®), P3.express, DSDM^(®) sau Scrum sau unul pe care l-ați personalizat sau construit dvs. Cu toate acestea, în mod normal, este o idee mai bună să începeți cu una dintre metodele existente și să o adaptați la nevoile dvs. decât să o construiți de la zero.

Orice element repetabil este abstract și are nevoie de personalizare pentru a-l adapta conform realității. Există totuși un spectru de abstractizare și o nevoie de personalizare: listele de verificare de calitate simple și relativ concrete se află la capătul spectrului cu cea mai mică cantitate de abstractizare și necesitate de adaptare, în timp ce metodologiile se regăsesc în partea cealaltă, la capătul cu cea mai mare nevoie de personalizare. Ar trebui să rețineți că întotdeauna este necesară personalizarea, în caz contrar, elementul repetabil nu va corespunde nevoilor dvs.