Nearly Universal Principles of Projects

Nu faceți nimic fără un scop clar

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

Dacă nu aveți în vedere un scop clar și faceți ceva doar pentru că toți ceilalți o 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:

Exemplu: Portofolii și programe

Dacă sunteți implicat în selectarea și inițierea proiectelor, ar trebui să vă asigurați că mai degrabă vă concentrați asupra beneficiilor și problemelor care trebuie rezolvate, decât asupra produsului care va realiza aceste lucruri. Exemplul clasic este producătorul 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, fără succes complet. Acest lucru a continuat până când au decis să se concentreze asupra problemei (plictiseala sau disconfortul oamenilor) în loc de soluția „naturală” (ascensoare mai rapide). Rezultatul a fost că au adăugat oglinzi la lifturi și au rezolvat problema simplu și ieftin.

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

Exemplu: Proiectul în ansamblu

Flexibilitatea produsului variază între proiecte. În unele proiecte de dezvoltare IT, produsul este complet flexibil, iar forma sa finală depinde de feedback-ul care va fi generat de dezvoltarea produsului în timpul proiectului, care necesită o abordare adaptivă (Agile). Aceasta este, în termeni practici, o combinație a straturilor de portofoliu, program și proiect și are nevoie de o atenție maximă acordată obiectivului final. Este o idee bună să documentați scopul și să îl faceți accesibil; este unul dintre scopurile ″viziunii produsului″, așa cum este utilizat în unele proiecte tip Scrum. Atenția către valoarea comercială în proiectele Agile este modul acestora de a asigura alinierea cu scopul.

În alte tipuri de proiecte, în care produsul este relativ clar definit și există alte mecanisme pentru a se asigura că produsul identificat va îndeplini scopul, este posibil ca membrii echipei de proiect să își schimbe o mare parte din concentrarea lor de la scop la produs (prin urmare, principiul ″Concentrarea pe produse″ din metodologia PRINCE2®), însă cel puțin o atenție minimă este necesară pentru a se asigura că ceea ce se construiește va îndeplini scopul, lucru care se poate face prin compararea beneficiilor prognozate cu beneficiile așteptate ( de aici și principiul ″Justificarea continuă a afacerii″ și tema ″Cazul de business″ din metodologia PRINCE2®).

Atunci când un proiect este executat pentru un client extern, clientul va avea propriul scop pentru proiect, iar organizația din care faceți parte va avea un scop diferit. Pentru a avea succes ar trebui să le înțelegeți și să le utilizați împreuna.

Exemplu: Monitorizarea proiectului

Este necesară concentrarea efortului asupra scopul final, dar poate fi prea abstract pentru multe dintre utilizările zilnice. De aceea, este necesară o ierarhie a livrabilelor pentru a o face mai practică. În primul rând, justificarea și beneficiile proiectului sunt definite pe baza scopului final și apoi veți avea obiective explicite și implicite pentru variabilele proiectului (de exemplu, timp, cost și calitate) pentru a satisface justificarea, care la rândul său va satisface scopul final. Acestea sunt scopuri de nivel inferior, care sunt utile pentru multe dintre sarcinile noastre zilnice.

Când vine vorba de monitorizare, monitorizarea la nivel scăzut a proiectului se va face folosind cel mai scăzut nivel de variabile, deoarece este posibil să nu fie posibilă urmărirea scopului final. În acest caz, ar trebui să aveți în continuare scopurile în vedere: care este scopul monitorizării?

Un răspuns normal și acceptabil este să vedem dacă suntem pe drumul cel bun și - dacă nu - să declanșăm o anumită reacție care să ne readucă pe cale sau să ajustăm țintele și să vedem dacă poate îndeplini în continuare scopul final. Prin urmare, măsurătorile noastre ar trebui să poată ajuta la acest scop de nivel scăzut, iar măsurătorile adecvate sunt prognoze pentru variabilele la finalizare; de exemplu: când vom putea termina proiectul? Câți bani am avea nevoie pentru a termina 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 de dezvoltare pe care o folosiți în proiect, planificarea este întotdeauna necesară. Întrebarea importantă este nivelul de detaliere din fiecare tip de plan. Dacă nu există suficiente detalii în plan, planul 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 face prea dificilă pregătirea și întreținerea și prea rigidă pentru incertitudinile proiectului. Drept urmare, planul devine nerealist și inutil.

Cel mai bun mod de a decide cu privire la nivelul de detaliu este să aveți în vedere un scop pentru fiecare element din plan. De exemplu, dacă luați în considerare adăugarea de resurse la plan, ar trebui să aveți un scop: Cum îl veți folosi? Cum va ajuta proiectul? Cât de mult efort va fi nevoie? Merită?

Uneori este vorba de a decide dacă doriți să aveți un anumit element în planurile dvs. și, uneori, despre modul în care doriți să planificați sau să pregătiți ceva. Indiferent dacă este vorba despre un caz de afaceri, un proiect sau raport: ar trebui să vă întrebați în continuare de ce pregătiți acel document și cum poate ajuta proiectul.

Căutarea unui ″șablon″ este opusul a face ceva bazat pe un scop.

Exemplu: Raportarea statusului

Este obișnuit să aveți rapoarte ale statusului foarte lungi în multe proiecte. Pe baza acestui NUP, ar trebui să ne întrebăm care este scopul raportului și cum putem atinge acest scop, indiferent de ceea ce ar face majoritatea oamenilor.

Acest lucru ne poate conduce, în multe cazuri, la pregătirea unor rapoarte foarte simple pe o pagină pe care părțile interesate le citesc și înțeleg cu adevărat în locul acelor rapoarte lungi. Acest lucru este definit la scop.

Totuși, dacă pregătiți rapoarte de o pagină, este posibil ca unele persoane să obiecteze despre dvs. și 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ă starea proiectului) și, pentru a satisface acest lucru, puteți crea pur și simplu un al doilea tip de raport care este foarte lung. Cu toate acestea, nu veți amesteca acest lucru cu primul raport, deoarece aceste două scopuri nu sunt aceleași.

Exemplu: Cazul de business și carta proiectului

Pregătirea documentelor, cum ar fi un caz de business și o cartă de proiect, este de obicei o necesitate plictisitoare și birocratică pentru majoritatea oamenilor, în timp ce toate aceste documente au scopuri importante care se aplică majorității proiectelor. Dacă încercați să găsiți un ″șablon″ și să îl completați, efortul dvs. este doar irosit; întrucât puteți verifica în schimb scopul real al acestor documente, puteți vedea dacă și cum pot fi utile în proiectul dvs. și apoi pregăti documentul în orice mod doriți, doar pentru a satisface aceste scopuri; acesta va fi documentul potrivit.

În timp ce vă gândiți la modul în care puteți pregăti documentele pentru a le îndeplini scopurile, este posibil să nu vă gândiți la fiecare scenariu și să pierdeți ceva. Pentru a evita acest lucru, puteți verifica pentru a vedea ce resurse, cum ar fi PRINCE2®, ghidul PMBOK®, P3.express și DSDM®, sugerează iar apoi puteți evalua aceste sugestii pe baza scopurilor.

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:

Monitorizarea post-proiect este un pas necesar pentru a fi orientat către scop. Este în principal responsabilitatea sistemelor de gestionare a programelor și a portofoliului ș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 simple. 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 sistemelor noastre, sperând că acesta se va potrivi cu complexitatea sistemului, chiar dacă în practică acest lucru face ca sistemul să fie dificil de lucrat și de obicei ne împiedică să îndeplinim scopul.

Exemplu: Personalizare

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

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

discussion icon NUPP este colaborativ, gratuit și publicat sub o licență Creative Commons.

discussion icon Împărtășește-ți opinia sau puneți întrebări pe această pagină LinkedIn.

discussion icon Scris de: Nader K. Rad

discussion icon Tradus de Raul JURJ, Jan-Florin PANAITE si Daniel ORZATA.

discussion icon Contribuții la această translation:

discussion icon Versiunea de o pagină a NUPP, potrivită pentru imprimare sau pentru realizarea fișierelor PDF.