Certificarea PMP® (Project Management Professional), emisă de PMI (Project Management Institute), este cel mai recunoscut standard global pentru manageri de proiect. Din 2021, examenul nu mai testează doar procesele din PMBOK 6, ci un mix de abordări predictive (~50%) și agile/hibride (~50%), organizat pe trei domenii definite în Examination Content Outline (ECO):

formatul examenului

• 180 de întrebări în 230 de minute, cu două pauze opționale de 10 minute (după întrebarea 60 și 120).
• Tipuri de întrebări: alegere multiplă clasică, răspunsuri multiple (ți se spune câte alegi), potrivire (matching), hotspot (dai click pe zona corectă) și completare de spații.
• 5 întrebări sunt „pretest” — nu se punctează, dar nu știi care sunt.
• Rezultatul e raportat pe niveluri: Above Target / Target / Below Target / Needs Improvement, per domeniu.

eligibilitate & aplicare

• Cu studii superioare (licență): 36 de luni de experiență în conducerea proiectelor + 35 de ore de educație în project management (acest curs acoperă materia; orele formale le obții printr-un curs autorizat sau CAPM).
• Fără licență (liceu/echivalent): 60 de luni de experiență + 35 de ore de educație.
• Aplici pe pmi.org, descrii proiectele, iar o parte din aplicații intră aleatoriu în audit. După aprobare, ai 1 an să susții examenul (max. 3 încercări).

cum folosești acest curs

• Parcurge modulele în ordine — sunt construite progresiv: fundamente → principii → metodologii → cele 3 domenii ECO → formule → simulare.
• La finalul fiecărui modul, fă quizul. Fiecare întrebare are explicație — citește-le și pe cele la care ai răspuns corect.
• Marchează lecțiile ca finalizate ca să-ți vezi progresul. Progresul se păstrează pe durata sesiunii curente în browser.
• Modulul 11 conține toate formulele într-un singur loc și o simulare de examen de 30 de întrebări.

Majoritatea întrebărilor PMP sunt situaționale: un scenariu de 3–6 rânduri, apoi „What should the project manager do next?” sau „What should the PM have done first?”. Rareori ți se cere o definiție seacă.

cum decodezi scenariul

1. Identifică momentul din proiect: ești la inițiere, planificare, execuție, control sau închidere? Sau într-un sprint? Răspunsul corect depinde de context.
2. Identifică problema reală, nu simptomul. „Un membru al echipei întârzie constant livrabilele” — problema poate fi de claritate a cerințelor, de capacitate sau de motivație; PM-ul investighează întâi cauza.
3. Elimină extremele: variantele care spun „escaladează la sponsor”, „concediază”, „ignoră”, „acceptă fără analiză” sunt aproape întotdeauna greșite. PMI vrea acțiune directă, proporțională și bazată pe proces.
4. Caută cuvintele-cheie: NEXT (pasul imediat următor în proces), FIRST (primul pas logic — deseori „analizează/evaluează”), BEST (cea mai completă opțiune), EXCEPT/NOT (atenție la negativ).

reguli de aur care rezolvă 30% din întrebări

• Când apare o schimbare cerută de oricine (chiar de sponsor): întâi evaluezi impactul, apoi urmezi procesul de integrated change control. Niciodată „implementezi direct” și niciodată „refuzi direct”.
• Când apare un conflict sau o problemă cu un om: vorbești direct și privat cu persoana implicată, întâi ca să înțelegi.
• Când apare un risc nou: îl adaugi în risk register și îl analizezi înainte de orice acțiune.
• PM-ul este proactiv: nu așteaptă, nu pasează, nu ascunde informații de stakeholderi.
• În context agil: echipa se auto-organizează; PM-ul/Scrum Masterul înlătură obstacole, nu împarte sarcini.

Un proiect este un efort temporar întreprins pentru a crea un produs, serviciu sau rezultat unic. „Temporar” înseamnă că are un început și un sfârșit definite — nu că e scurt. „Unic” înseamnă că rezultatul diferă de ce s-a mai făcut, chiar dacă procesul e similar.

Proiectele produc schimbare: mută organizația dintr-o stare curentă într-o stare viitoare dorită, și sunt lansate ca răspuns la: cerințe legale sau de reglementare, cereri ale stakeholderilor, schimbări de tehnologie sau piață, ori pentru a crea/repara/îmbunătăți produse și procese.

proiect vs operațiuni

program și portofoliu

• Program = un grup de proiecte (și activități conexe) înrudite, gestionate coordonat pentru a obține beneficii pe care nu le-ai obține gestionându-le separat. Focus: beneficii și dependențe.
• Portofoliu = proiecte, programe și operațiuni grupate pentru a atinge obiective strategice. Componentele NU trebuie să fie înrudite. Focus: alinierea la strategie și prioritizarea investițiilor.
• Ierarhia tipică: strategie → portofoliu → programe → proiecte.

valoarea de business

Orice proiect există ca să livreze valoare — tangibilă (bani, cotă de piață, active) sau intangibilă (brand, reputație, aliniere strategică). Documentele care justifică proiectul:

• Business case: justificarea economică — problema/oportunitatea, analiza opțiunilor, costuri vs beneficii, recomandarea. Răspunde la „merită proiectul?”.
• Benefits management plan: ce beneficii vor fi livrate, când, cum se măsoară și cine e responsabil de realizarea lor (deseori după închiderea proiectului).

Ciclul de viață al proiectului este seria de faze prin care trece proiectul de la start la închidere. O fază e un set logic de activități care se termină cu unul sau mai multe livrabile. Trecerea între faze se face de obicei printr-un phase gate (stage gate / kill point): un punct de decizie în care se evaluează performanța și se decide continuarea, corectarea sau oprirea proiectului.

tipuri de cicluri de viață

procese, date și tailoring

În viziunea clasică (PMBOK 6), munca de management e organizată în 5 grupe de procese: Initiating, Planning, Executing, Monitoring & Controlling, Closing — care NU sunt faze, ci grupări logice ce se pot repeta în fiecare fază. PMBOK 7 mută accentul de la procese la principii și domenii de performanță, dar examenul presupune că le cunoști pe amândouă.

Tailoring = adaptarea deliberată a abordării, proceselor, documentelor și ceremoniilor la contextul specific al proiectului (mărime, criticitate, cultură, echipă). Nu aplici tot PMBOK-ul orbește; alegi ce aduce valoare. La examen, „one size does not fit all” e un principiu explicit.

mediul în care trăiește proiectul

• EEF — Enterprise Environmental Factors: condiții pe care nu le controlezi, dar care influențează proiectul. Interne: cultura organizației, infrastructura, software-ul disponibil, apetitul de risc. Externe: legislație, piață, condiții economice, standarde industriale.
• OPA — Organizational Process Assets: activele proprii organizației, pe care le poți folosi și actualiza: procese și politici interne, template-uri, baze de cunoștințe, lessons learned din proiecte trecute, arhive istorice.

structuri organizaționale

pmo — project management office

• Supportive: rol consultativ — template-uri, training, lessons learned; control redus.
• Controlling: impune conformitate — metodologii, framework-uri, audituri; control moderat.
• Directive: conduce direct proiectele — PM-ii raportează la PMO; control ridicat.

PMO-ul standardizează guvernanța proiectelor și facilitează partajarea resurselor, metodologiilor și instrumentelor între proiecte.

Managerul de proiect este persoana autorizată de organizație să conducă echipa responsabilă de atingerea obiectivelor proiectului. E integrator: leagă strategia de execuție, echipa de stakeholderi, constrângerile între ele.

sfera de influență

• Proiect: conduce echipa, echilibrează constrângerile, comunică — se estimează că ~90% din munca unui PM e comunicare.
• Organizație: colaborează cu alți PM, PMO, manageri funcționali, sponsori; face lobby pentru resurse.
• Industrie & profesie: se ține la curent cu trenduri, contribuie la comunitate, transferă cunoștințe.

pmi talent triangle

• Ways of Working (fost Technical PM): stăpânirea abordărilor — predictiv, agil, hibrid, design thinking — și a instrumentelor lor.
• Power Skills (fost Leadership): leadership colaborativ, comunicare, empatie, rezolvarea conflictelor, influență fără autoritate.
• Business Acumen (fost Strategic & Business Management): înțelegerea business-ului — finanțe, piață, strategie, compliance — ca să iei decizii aliniate la valoare.

constrângerile proiectului

Clasicul „triplu constraint” (scop–timp–cost) e extins la șase constrângeri care se influențează reciproc: scop, timp (schedule), cost, calitate, resurse, risc. Orice schimbare într-una le afectează pe celelalte — de aceea orice cerere de schimbare se evaluează integrat, nu izolat.

PMBOK Guide ediția 7 e construit pe principii — comportamente fundamentale valabile în orice abordare (predictiv sau agil) — nu pe procese prescriptive. La examen apar ca „filtru” pentru răspunsul corect.

Domeniile de performanță sunt grupuri de activități interdependente care, împreună, livrează rezultatele proiectului. Nu sunt secvențiale — rulează simultan pe toată durata proiectului.

sistemul de livrare a valorii

PMBOK 7 vede organizația ca un value delivery system: portofolii → programe → proiecte → produse, toate transformând strategia în valoare. Guvernanța (comitete, phase gates, politici) asigură că sistemul rămâne aliniat. Informația circulă în buclă: strategia coboară spre proiecte, performanța urcă înapoi spre decizie.

modele, metode și artefacte

PMBOK 7 include o bibliotecă de modele (ex: Tuckman, ADKAR, leadership situațional), metode (estimare, EVM, retrospective) și artefacte (charter, registre, backlog-uri, rapoarte). Le vei întâlni pe toate în modulele următoare, în contextul în care se folosesc.

Alegerea abordării de dezvoltare e o decizie de tailoring, luată pe baza produsului, proiectului și organizației. Nicio abordare nu e „mai bună” — e mai potrivită sau nu.

criterii de alegere

hibrid în practică

• Faze diferite, abordări diferite: planificare + arhitectură predictiv, dezvoltare agil, deployment predictiv.
• Componente diferite: hardware-ul predictiv, software-ul agil.
• Agile „în ambalaj predictiv”: milestone-uri și buget fixe la nivel de contract, sprinturi în interior.

vocabular esențial agil

• Timebox: interval de timp fix (sprintul nu se prelungește niciodată).
• MVP (minimum viable product): cea mai mică versiune care livrează valoare și generează învățare.
• Backlog: lista ordonată a tot ce e de făcut, deținută de Product Owner.
• Cadence: ritmul livrării; increment: suma funcționalităților terminate până acum.

Manifestul Agile (2001) este fundația tuturor framework-urilor agile. Formulările din stânga sunt prețuite mai mult decât cele din dreapta — dar cele din dreapta au și ele valoare.

cele 4 valori

1. Indivizi și interacțiuni peste procese și instrumente.
2. Software funcțional (produs care merge) peste documentație exhaustivă.
3. Colaborarea cu clientul peste negocierea contractelor.
4. Răspunsul la schimbare peste urmărirea unui plan.

cele 12 principii — pe scurt

• Satisfacția clientului prin livrare timpurie și continuă de valoare.
• Schimbările sunt binevenite, chiar târziu în dezvoltare — sunt avantaj competitiv.
• Livrează produs funcțional frecvent (săptămâni, nu luni).
• Business-ul și dezvoltatorii lucrează împreună zilnic.
• Construiește proiecte în jurul unor oameni motivați; dă-le mediul și încrederea.
• Conversația față în față e cea mai eficientă formă de comunicare.
• Produsul funcțional e principala măsură a progresului.
• Ritm sustenabil — echipa poate menține viteza pe termen nelimitat (fără burnout).
• Atenția continuă la excelență tehnică și design bun sporește agilitatea.
• Simplitatea — arta de a maximiza munca ne-făcută — e esențială.
• Cele mai bune arhitecturi și cerințe apar din echipe auto-organizate.
• La intervale regulate, echipa reflectează și se ajustează (retrospectiva).

Scrum e cel mai folosit framework agil: echipe mici, sprinturi de 1–4 săptămâni (timebox fix), un increment „Done” la fiecare sprint. Se sprijină pe trei piloni empirici: transparență, inspecție, adaptare.

cele 3 roluri (accountabilities)

cele 5 evenimente

• Sprintul — containerul tuturor celorlalte; lungime fixă; scopul sprintului nu se schimbă în timpul lui.
• Sprint Planning (max ~8h/1 lună): ce livrăm (Sprint Goal + itemi aleși) și cum. Rezultat: Sprint Backlog.
• Daily Scrum (15 min, în fiecare zi, pentru Developers): sincronizare și plan pe 24h — nu raport de status pentru manager.
• Sprint Review (max ~4h): echipa demonstrează incrementul stakeholderilor, colectează feedback, adaptează backlog-ul. Focus: produsul.
• Sprint Retrospective (max ~3h): echipa inspectează procesul și oamenii — ce îmbunătățim sprintul viitor.

cele 3 artefacte + angajamentele lor

• Product Backlog → angajament: Product Goal. Listă ordonată, emergentă, a tot ce ar putea fi construit.
• Sprint Backlog → angajament: Sprint Goal. Itemii selectați + planul echipei pentru sprint.
• Increment → angajament: Definition of Done (criteriile de calitate ca ceva să fie considerat terminat).

user stories & rafinare

• Format tipic: „Ca [rol], vreau [funcționalitate], ca să [beneficiu].” + criterii de acceptare.
• Calitatea unei povești: INVEST — Independent, Negotiable, Valuable, Estimable, Small, Testable.
• Backlog refinement: activitate continuă (~10% din capacitate) de detaliere, estimare și spargere a itemilor din vârful backlog-ului.
• Definition of Ready (opțional): condițiile ca un item să poată intra în sprint.

kanban

Metodă bazată pe flux continuu (fără sprinturi obligatorii), pornind de la procesul existent:

• Vizualizează munca pe un board (To Do → In Progress → Done, adaptat fluxului real).
• Limitează WIP (work in progress): mai puține lucruri simultan → flux mai rapid, mai puțin multitasking.
• Gestionează fluxul măsurând: lead time (de la cerere la livrare), cycle time (de la începerea lucrului la finalizare), throughput (itemi terminați / interval).
• Politici explicite, bucle de feedback, îmbunătățire evolutivă.

Când Kanban în loc de Scrum? Muncă de tip flux/cereri continue (suport, mentenanță, operațiuni) sau echipe care vor să evolueze din procesul curent fără restructurare.

extreme programming (xp)

• Pair programming: doi dezvoltatori la același cod — calitate + transfer de cunoștințe.
• TDD (test-driven development): scrii testul înainte de cod.
• Continuous integration: integrezi și testezi codul frecvent (de mai multe ori pe zi).
• Refactoring, design simplu, collective code ownership, ritm sustenabil.

lean

Origine: Toyota. Principiu central: maximizează valoarea eliminând risipa (waste) — muda: supraproducție, așteptare, transport, supraprocesare, stocuri, mișcări inutile, defecte (+ talent nefolosit). Concepte utile la examen: value stream mapping (harta fluxului de valoare pentru a găsi risipa) și decizia la last responsible moment.

alte elemente care apar la examen

• Servant leadership: liderul servește echipa — înlătură obstacole, asigură resurse, protejează focusul.
• Information radiators: afișaje vizibile (board, burndown, build status) care fac progresul transparent fără să întrebi.
• Colocare vs distribuit: colocarea (osmotic communication) accelerează comunicarea; echipele distribuite compensează prin unelte și norme explicite.
• Spike: un timebox scurt de cercetare/experiment pentru a reduce incertitudinea tehnică înainte de estimare.
• Scaling (doar conceptual): SAFe, LeSS, Scrum of Scrums — coordonarea mai multor echipe agile.

Domeniul People valorează 42% din examen. Tema centrală: PM-ul construiește un mediu în care echipa performează — nu comandă, ci abilitează.

formarea echipei

• Evaluezi competențele necesare vs disponibile → identifici gap-uri → plan de training sau recrutare.
• Team charter: documentul creat împreună cu echipa care stabilește valorile, normele de comunicare, procesul de decizie și de rezolvare a conflictelor, orele comune de lucru. Funcționează pentru că echipa și-l asumă (ownership).
• Ground rules: regulile concrete de comportament (ex: camerele pornite la daily, răspuns pe Slack în 4h). Încălcările se adresează de către echipă, devreme și direct.

etapele tuckman

echipe virtuale

• Beneficii: acces la talente globale, costuri mai mici, flexibilitate. Provocări: fusuri orare, lipsa comunicării nonverbale, izolare, cultură.
• Bune practici: norme de comunicare explicite (team charter), suprapunere de ore comune, video pentru discuții sensibile, documentare asincronă bună, atenție deliberată la incluziune și recunoaștere.

management vs leadership

Managementul direcționează prin poziție: planuri, procese, control. Leadershipul influențează prin relație: viziune, motivație, inspirație. Un PM bun le folosește pe ambele, dozat după situație (leadership situațional: mai directiv cu echipe noi, delegare cu echipe mature).

stiluri de leadership

• Servant leadership (favoritul PMI, mai ales în agil): servești echipa — obstacole, resurse, protecție, dezvoltare.
• Transformațional: inspiri prin viziune, stimulezi inovația. Tranzacțional: recompense pentru obiective atinse.
• Charismatic: energie și entuziasm personal. Laissez-faire: neintervenție (potrivit doar echipelor foarte mature, altfel riscant).
• Autocratic / directiv: decizii unilaterale — justificat doar în crize sau urgențe de siguranță.

puterea pm-ului (forme de influență)

• Legitimă (poziție), reward (recompense), coercitivă/penalty (pedepse — de evitat), expert (competență — se câștigă), referent (respect/relație — cea mai valoroasă alături de expert).

inteligența emoțională (goleman)

• Self-awareness (îți cunoști emoțiile) → self-regulation (le gestionezi) → motivation (drive intern) → empathy (înțelegi emoțiile altora) → social skills (gestionezi relațiile).
• La examen: înainte să reacționezi la un conflict sau feedback dur, PM-ul cu EI își gestionează propria reacție și caută să înțeleagă perspectiva celuilalt.

teorii ale motivației

Conflictul e natural și inevitabil în proiecte — și, gestionat bine, e sănătos: aduce perspective diverse și decizii mai bune. Sursele cele mai frecvente (în ordine): schedule-ul, prioritățile, resursele, apoi opiniile tehnice, procedurile administrative, costurile și abia la final personalitățile.

cele 5 tehnici de rezolvare

procesul corect la examen

1. Adresează conflictul devreme, în privat, direct cu cei implicați.
2. Focus pe probleme și fapte, nu pe persoane și trecut.
3. Lasă întâi părțile implicate să rezolve; PM-ul facilitează dacă nu reușesc; escaladarea e ultima opțiune.
4. În agil: echipa își rezolvă singură conflictele; Scrum Masterul facilitează doar dacă echipa e blocată.

negociere

• Țintește win–win: interese, nu poziții. Pregătește-ți BATNA (cea mai bună alternativă dacă negocierea eșuează).
• PM-ul negociază constant: resurse cu managerii funcționali, priorități cu PO/sponsor, termene cu furnizorii.
• Etapele tipice: pregătire → schimb de informații → tocmeală (bargaining) → închidere → implementarea acordului.

empowerment & delegare

• Dai echipei autoritate de decizie pe măsura competenței: definești rezultatul așteptat și limitele, nu micromanageriezi metoda.
• RACI clarifică rolurile pe livrabile: Responsible (execută), Accountable (răspunde — exact unul singur per livrabil), Consulted (consultat, comunicare bidirecțională), Informed (informat, unidirecțional).
• Semne că delegarea lipsește: PM-ul e blocaj la fiecare decizie, echipa așteaptă aprobare pentru orice.

training, coaching, mentoring

evaluarea și creșterea performanței

• Stabilește KPI de echipă transparente (velocity-ul e al echipei, nu instrument de comparat indivizi!).
• Feedback: frecvent, specific, echilibrat, în privat pentru corecții, public pentru recunoaștere.
• Performanță slabă a unui membru: 1) discuție privată pentru a înțelege cauza → 2) suport/training/claritate → 3) plan de îmbunătățire → 4) abia apoi escaladare la managerul funcțional/HR.
• Recunoaștere și recompense: adaptate persoanei și culturii; recompensează comportamentele dorite (colaborarea), nu eroismele individuale care ascund probleme de proces.

lucrul cu stakeholderii ca „people skill”

Domeniul People include și colaborarea zilnică: aliniezi așteptări, construiești încredere prin transparență, formezi acorduri (negotiate project agreements), sprijini incluziunea perspectivelor diverse. Partea analitică (registre, grile, strategii) o tratăm în modulul 8.

Integrarea e treaba definitorie a PM-ului: unifică toate componentele (scop, timp, cost, risc, oameni) într-un întreg coerent. Nu se deleagă.

înainte de proiect: selecția

Organizația compară inițiative folosind metode de selecție economică — trebuie să le poți interpreta:

project charter

Documentul care autorizează formal proiectul și îi dă PM-ului autoritatea de a folosi resursele organizației. E emis de sponsor (sau inițiator), nu de PM — dar PM-ul poate ajuta la redactare și ar trebui numit cât mai devreme.

• Conține, la nivel înalt: scopul și justificarea, obiective măsurabile și criterii de succes, cerințe și descriere high-level, riscuri majore, sumar de milestone-uri și buget, lista stakeholderilor cheie, criteriile de ieșire/închidere, PM-ul numit și nivelul lui de autoritate, sponsorul.
• Charterul nu se modifică la fiecare schimbare de detaliu — e ancora proiectului. Fără charter, PM-ul nu are autoritate formală.
• Echivalente agile ușoare: project vision statement, lean canvas / project brief.

assumption log & primele artefacte

• Assumption log: ipotezele (ce presupunem adevărat fără dovadă) și constrângerile (limitări impuse) se înregistrează din prima zi și se revalidează periodic — ipotezele false devin riscuri.
• Identificarea inițială a stakeholderilor începe tot acum (înainte de planificarea detaliată).

project management plan

Planul de management al proiectului e documentul-mamă: definește cum va fi executat, monitorizat, controlat și închis proiectul. Se construiește progresiv și, odată aprobat (baseline), se schimbă doar prin change control. Componente:

• Planuri subsidiare: scope, requirements, schedule, cost, quality, resource, communications, risk, procurement, stakeholder engagement management plans.
• Cele 3 baseline-uri: scope baseline (scope statement + WBS + WBS dictionary), schedule baseline, cost baseline. Împreună formează performance measurement baseline — etalonul față de care măsori (inclusiv EVM).
• Componente adiționale: change management plan, configuration management plan, ciclul de viață ales, decizii de tailoring.

Planuri ≠ documente de proiect: registrele (risk register, issue log, stakeholder register), log-urile și estimările sunt documente de lucru care se actualizează liber, fără change control.

direcționarea și gestionarea lucrului

• PM-ul conduce execuția conform planului, produce livrabile și work performance data, implementează schimbările aprobate (acțiuni corective, preventive, defect repair).
• Issue log: problemele apărute (nu riscuri — riscul e viitor și incert, issue-ul e prezent și cert) cu responsabil și termen.

managementul cunoștințelor

• Cunoștințe explicite: codificabile (documente, proceduri) — se gestionează prin biblioteci și registre.
• Cunoștințe tacite: experiență, intuiție, context — se transferă doar prin interacțiune: shadowing, comunități de practică, discuții, retrospective.
• Lessons learned register: se completează pe tot parcursul proiectului (nu doar la final!) și la închidere se arhivează în OPA, disponibil întregii organizații.

monitorizare & control

Continuu pe toată durata: compari performanța reală cu baseline-urile, analizezi variațiile (variance analysis), prognozezi (forecasting), decizi acțiuni. Rezultatul: work performance reports pentru stakeholderi și cereri de schimbare unde e nevoie.

procesul de change control — cel mai testat proces din examen

Orice modificare a unui element aflat sub baseline (scop, schedule, cost, uneori planuri) urmează același drum, indiferent cine o cere:

1. Înregistrezi cererea în change log (orice stakeholder poate cere; cererea e mereu scrisă).
2. Evaluezi impactul integrat — asupra tuturor constrângerilor: scop, timp, cost, calitate, resurse, risc. Acesta e aproape mereu „primul pas” corect la examen.
3. Prezinți opțiuni și recomandări către forul de decizie: CCB (change control board) sau sponsor, conform change management plan. PM-ul aprobă singur doar ce intră în autoritatea lui definită.
4. Decizia: aprobat / respins / amânat — se comunică tuturor stakeholderilor afectați și se înregistrează.
5. Implementezi schimbarea aprobată, actualizezi baseline-urile și planurile, verifici efectul.

În agil, schimbarea e binevenită dar tot disciplinată: intră în product backlog, Product Owner-ul o prioritizează, iar sprintul curent rămâne protejat (scopul sprintului nu se schimbă; în cazuri extreme PO poate anula sprintul).

configuration management

Ține evidența versiunilor livrabilelor și documentelor (ce versiune e cea aprobată, cine a modificat, când). Change control decide dacă se schimbă ceva; configuration management urmărește ce și în ce versiune există.

închiderea proiectului sau fazei

1. Confirmi că toate criteriile de finalizare sunt îndeplinite și livrabilele au fost acceptate formal de client (validate scope precede închiderea).
2. Tranziționezi livrabilul către operațiuni/client (suport, documentație, training).
3. Închizi contractele și achizițiile, plătești facturile finale.
4. Finalizezi raportul final, arhivezi documentele, actualizezi OPA cu lessons learned.
5. Eliberezi resursele și sărbătorești/recunoști echipa — ultimul pas.

Închiderea e obligatorie și când proiectul e anulat (terminated): documentezi stadiul, motivele, lecțiile, arhivezi. Un proiect nu se „abandonează” pur și simplu.

Product scope = caracteristicile produsului. Project scope = munca necesară pentru a livra produsul (include și management, testare etc.).

colectarea cerințelor

• Tehnici: interviuri, focus grupuri, workshopuri facilitate (JAD), brainstorming, chestionare, observare/job shadowing, prototipuri și mockup-uri, benchmarking, analiza documentelor.
• Decizii de grup: unanimitate, majoritate, pluralitate; tehnica Delphi = experți anonimi, în runde, pentru consens fără presiune socială; nominal group = brainstorming + vot de prioritizare.
• Requirements traceability matrix (RTM): leagă fiecare cerință de originea ei și de livrabilul/testul care o satisface — nimic nu se pierde, nimic nu apare „din aer”.

definirea scopului & wbs

• Project scope statement: descrierea scopului, livrabilele majore, criteriile de acceptare și — la fel de important — exclusions (ce NU e în scop).
• WBS (work breakdown structure): descompunerea ierarhică, orientată pe livrabile, a întregii munci. Regula 100%: WBS conține tot scopul, și nimic în plus. Nivelul cel mai de jos = work package (unitate care se poate estima și atribui).
• WBS dictionary: detaliile fiecărui element (descriere, responsabil, criterii de acceptare, cost estimat).
• Scope baseline = scope statement + WBS + WBS dictionary — memorizează compoziția, se cere direct la examen.

validare vs control

• Validate scope: obții acceptarea formală a livrabilelor de la client/sponsor — se face pe livrabile deja verificate intern (după control quality) și periodic, nu doar la final.
• Control scope: monitorizezi scopul și previi scope creep-ul — orice deviere trece prin change control.
• Ordinea la examen: Control Quality (livrabil verificat intern) → Validate Scope (acceptat de client) → livrabil final.

scopul în agil

• Scopul e emergent: viziune stabilă, detalii descoperite iterativ prin product backlog (ordonat de PO, rafinat continuu).
• Ierarhia tipică: epic → feature → user story → task. Criteriile de acceptare per story + Definition of Done global joacă rolul criteriilor de acceptare din predictiv.
• Echivalentul validate scope: Sprint Review — feedback și acceptare incrementală de la stakeholderi.

de la wbs la schedule

Lanțul complet: definești activitățile (spargi work package-urile în acțiuni) → le ordonezi (dependințe) → estimezi duratele → construiești schedule-ul (analiza rețelei, CPM) → îl controlezi.

tipuri de dependințe

• Natura dependinței: mandatory (hard logic — legi ale fizicii/contractuale), discretionary (soft logic — bune practici, se pot relaxa la compresie), external (în afara proiectului — ex: aprobarea unei autorizații), internal.
• Lead = devans (succesorul începe mai devreme; FS cu lead 2 zile → începe cu 2 zile înainte de finalul predecesorului). Lag = așteptare impusă (ex: betonul se usucă 3 zile).

tehnici de estimare a duratelor (și costurilor)

Exemplu: O=4 zile, M=6, P=14 → PERT = (4 + 24 + 14)/6 = 7 zile; σ = (14−4)/6 ≈ 1,67 zile. Intervalul E±1σ acoperă ~68% din cazuri, ±2σ ~95%.

concepte

• Drumul critic = cel mai lung lanț de activități dependente prin rețea → determină durata minimă a proiectului. Activitățile de pe el au float zero: orice întârziere acolo întârzie proiectul.
• Total float (slack) = cât poate întârzia o activitate fără a întârzia proiectul. Free float = cât poate întârzia fără a întârzia succesorul imediat.

exemplu calculat

Activități: A(3z) → B(4z) → D(5z); și A → C(2z) → D. Drumurile: A-B-D = 3+4+5 = 12 zile; A-C-D = 3+2+5 = 10 zile.

• Drumul critic: A-B-D, 12 zile. Float pentru C: 12 − 10 = 2 zile (poate întârzia 2 zile fără impact).
• Dacă C ajunge la 5 zile, A-C-D = 13 > 12 → drumul critic se mută pe A-C-D. Drumul critic se poate schimba pe parcurs; pot exista și mai multe drumuri critice simultan (risc mai mare).

compresia schedule-ului

resurse & alte tehnici

• Resource leveling: rezolvi supra-alocarea ajustând schedule-ul → poate lungi drumul critic (constrângerea primară devine resursa).
• Resource smoothing: nivelezi utilizarea doar în limita float-ului → nu schimbă durata proiectului.
• Critical chain: adaugă buffere (project buffer, feeding buffers) și pornește de la constrângerile de resurse.
• Milestone = eveniment cu durată zero (semnare contract, go-live). Gantt = vizualizarea schedule-ului pe bare; network diagram = logica dependințelor.

estimarea relativă

• Story points: măsoară mărimea relativă (efort + complexitate + incertitudine), nu ore. Scara Fibonacci (1, 2, 3, 5, 8, 13...) pentru că incertitudinea crește cu mărimea.
• Planning poker: fiecare estimează simultan cu cărți → discuți divergențele → consens. Elimină ancorarea.
• T-shirt sizing (S/M/L/XL) pentru estimări brute de epic-uri; affinity estimation pentru volume mari rapid.

velocity & prognoză

• Velocity = story points terminate (Done) per sprint. Se stabilizează după ~3 sprinturi.
• Prognoză: backlog rămas 120 puncte, velocity medie 20 → ~6 sprinturi. Simplu, dar apare des la examen.
• Velocity e a echipei: nu compari echipe între ele și nu o folosești ca țintă de performanță (altfel echipa umflă estimările).

vizualizarea progresului

• Burndown chart: munca rămasă în timp — linia coboară spre zero. Deasupra liniei ideale = în urmă.
• Burnup chart: munca terminată în timp + o linie separată pentru scopul total — arată explicit când scopul crește (avantaj față de burndown).
• Cumulative flow diagram (CFD): benzile stărilor (To Do / In Progress / Done) în timp; o bandă „In Progress” care se îngroașă = blocaj (bottleneck), WIP prea mare.
• Kanban metrics: lead time, cycle time, throughput (definite în modulul 3).

cadențe de planificare agilă

Planificarea agilă e pe „foi de ceapă” (planning onion): viziune de produs → roadmap → release planning → sprint planning → daily. Detaliul crește pe măsură ce te apropii de execuție — exact „elaborarea progresivă” din predictiv, dusă la maximum.

tipuri de costuri & buget

• Direct (salariile echipei, licențe pentru proiect) vs indirect (chirie, overhead). Fix vs variabil.
• Construcția bugetului: estimări pe work packages → + contingency reserve (pentru riscuri identificate, „known unknowns”, în controlul PM-ului) = cost baseline → + management reserve (pentru „unknown unknowns”, controlată de management, în afara baseline-ului) = bugetul total.
• Cost baseline în timp = curba S. Funding limit reconciliation: aliniezi cheltuielile la tranșele de finanțare.

evm — earned value management

EVM integrează scop + timp + cost într-o singură imagine. Cele trei valori de bază:

• PV (planned value): valoarea muncii planificate până azi.
• EV (earned value): valoarea muncii efectiv realizate până azi (procent fizic realizat × buget).
• AC (actual cost): cât ai cheltuit efectiv. BAC (budget at completion): bugetul total.

prognoze (forecasting)

exemplu complet

Proiect: BAC = 100.000 €, la jumătatea perioadei planificate. PV = 50.000, EV = 40.000, AC = 48.000.

• SV = 40k − 50k = −10.000 (în urmă cu programul); SPI = 40/50 = 0,80 → avansezi la 80% din ritmul planificat.
• CV = 40k − 48k = −8.000 (peste buget); CPI = 40/48 ≈ 0,83 → fiecare euro cheltuit produce 0,83 € de valoare.
• EAC = 100k / 0,83 ≈ 120.000 €; VAC = 100k − 120k = −20.000 €; ETC = 120k − 48k = 72.000 €.
• TCPI = (100−40)/(100−48) = 60/52 ≈ 1,15 → ar trebui să devii cu 15% mai eficient decât planul ca să te încadrezi — puțin probabil fără schimbări; PM-ul comunică transparent și propune opțiuni.

Calitate = gradul în care caracteristicile îndeplinesc cerințele. Grade = categoria de funcționalități. Un produs de grade mic dar fără defecte = calitate bună; un produs premium plin de bug-uri = calitate slabă. Filozofia PMI: prevenția bate inspecția — calitatea se planifică și se construiește, nu se „testează la final”. Responsabilitatea calității: a întregii echipe (și a managementului pentru sistem — Deming: majoritatea problemelor de calitate vin din proces, nu din oameni).

cost of quality (coq)

cele 7 instrumente de bază ale calității

• Diagrama cauză–efect (Ishikawa / fishbone): descompui cauzele posibile ale unei probleme pe categorii — pentru root cause analysis (adesea cu „5 Whys”).
• Flowchart: vizualizezi procesul ca să găsești pașii care produc defecte.
• Check sheet: numeri aparițiile defectelor pe categorii (date brute).
• Pareto chart: bar chart ordonat — regula 80/20: ~80% din defecte vin din ~20% din cauze → prioritizezi.
• Histogramă: distribuția unei variabile.
• Control chart: procesul în timp, cu limite de control (de obicei ±3σ). Rule of seven: 7 puncte consecutive de aceeași parte a mediei = proces „out of control” (cauză asignabilă), chiar dacă în limite.
• Scatter diagram: corelația dintre două variabile.

plan → manage → control

• Plan quality: standarde relevante, metrici (defect density, coverage), cum vei verifica.
• Manage quality (asigurare, orientată pe proces): audituri de calitate, îmbunătățirea proceselor, design for X.
• Control quality (orientată pe livrabil): inspecții, testare, măsurători → livrabile verificate, care merg apoi la validate scope.
• Concepte conexe: kaizen (îmbunătățire continuă), Six Sigma, just in time (stocuri minime → forțează calitate), și în agil: Definition of Done, testare automată, CI, pair programming = calitate „built-in”.

planificarea resurselor

• Resource management plan: cum identifici, obții, gestionezi și eliberezi resursele (umane + fizice: echipamente, materiale, infrastructură).
• RBS (resource breakdown structure): ierarhia resurselor pe categorii și tipuri.
• Instrumente de alocare: RACI (modulul 4), organigrame de proiect, resource calendars (când sunt disponibile resursele), resource histograms (încărcarea în timp).

obținerea resurselor

• În organizații matriceale, resursele se negociază cu managerii funcționali — folosește date (schedule, priorități, impact), nu autoritate.
• Pre-assignment: oameni promiși prin charter/contract. Alternativa externă: achiziții (modulul 8).
• Dacă resursa promisă nu mai e disponibilă: evaluezi impactul asupra constrângerilor, cauți alternative (alt om, training, externalizare, re-secvențiere), apoi comunici și, dacă baseline-urile sunt afectate, treci prin change control.

gestionarea resurselor fizice

• Asiguri disponibilitatea la momentul potrivit (nici stocuri excesive, nici lipsuri): logistică, inventar, mentenanța echipamentelor.
• Monitorizezi consumul vs plan; risipa și utilizarea sub-optimă sunt semnale de acțiune corectivă.

~90% din timpul unui PM e comunicare. Majoritatea problemelor de proiect au la bază o comunicare defectuoasă — de aceea domeniul apare transversal în tot examenul.

modelul de comunicare

Emițător (codifică) → mesaj prin mediu (cu zgomot/noise: distanță, jargon, cultură, tehnologie) → receptor (decodifică) → acknowledge (am primit) → feedback/răspuns (am înțeles astfel). Sensul se confirmă prin feedback loop — de aici tehnicile de ascultare activă: parafrazezi, întrebi, confirmi înțelegerea.

numărul canalelor de comunicare

Exemplu: echipă de 5 → 10 canale. Vine PM-ul și 2 stakeholderi noi (n=8) → 28 canale. Întrebarea tipică: „câte canale noi?” → 28 − 10 = 18. Atenție dacă enunțul spune „echipa + tu” — include-te în n.

metode & dimensiuni

• Interactive (întâlniri, apeluri, mesaje în timp real): cea mai eficientă pentru subiecte sensibile sau ambigue.
• Push (email, rapoarte trimise): ajunge la destinatar, dar nu garantează înțelegerea.
• Pull (wiki, dashboard, repository): pentru audiențe mari, informație voluminoasă, la cerere. Information radiators din agil sunt pull.
• Dimensiuni: internă/externă, formală/informală, verticală/orizontală, scrisă/orală. Regulă practică: probleme complexe sau emoționale → interactiv (față în față / video); decizii și acorduri → confirmate în scris.

planul de comunicare & cei 5c

• Communications management plan: cine, ce informație, când, prin ce canal, în ce format, de la cine — construit pe nevoile stakeholderilor (din stakeholder register), nu pe preferințele PM-ului.
• Scriere eficientă — 5C: Correct (corect gramatical), Concise (concis), Clear (clar pentru audiență), Coherent (logic), Controlled (idei bine conduse).
• Monitor communications: verifici dacă informația chiar ajunge și produce efectul dorit — dacă stakeholderii sunt surprinși de status, planul de comunicare a eșuat și îl ajustezi.

Risc = eveniment incert care, dacă apare, are efect asupra obiectivelor — negativ (amenințare) sau pozitiv (oportunitate). Diferă de issue (deja s-a întâmplat). Riscul individual ≠ riscul general al proiectului (incertitudinea totală, relevantă pentru sponsor).

• Apetit de risc: cât risc e dispusă organizația să accepte; toleranță/praguri: limitele măsurabile. Le afli devreme — dictează cât de agresiv planifici răspunsurile.

identificarea riscurilor

• Tehnici: brainstorming cu echipa, checklists și prompt lists (PESTLE, TECOP), interviuri, analiza ipotezelor din assumption log, SWOT, analiza documentelor, Delphi.
• Format recomandat de formulare: „Din cauza [cauză], se poate întâmpla [eveniment incert], ceea ce ar duce la [efect asupra obiectivelor].”
• Totul intră în risk register: descriere, cauze, owner, categorii (RBS de risc), răspunsuri potențiale. Identificarea e iterativă — pe toată durata proiectului (și în fiecare retrospectivă/planning în agil).

analiza calitativă

• Evaluezi fiecare risc pe probabilitate × impact → matricea P–I → prioritizezi (scor mare = atenție imediată). Evaluezi și urgența, detectabilitatea, proximitatea.
• Verifici calitatea datelor despre risc (cât de bine îl înțelegem) și bias-urile evaluatorilor.
• Rezultat: lista scurtă de riscuri prioritare pentru analiză cantitativă și/sau răspunsuri; watch list pentru cele minore (le monitorizezi doar).

analiza cantitativă

• Numerică, făcută de obicei doar pe proiecte mari/critice sau pe riscurile de top: simulare Monte Carlo (distribuții de probabilitate pentru cost/durată totală), sensitivity analysis / diagrama tornado (care variabile mișcă cel mai tare rezultatul), decision tree + EMV.

Exemplu decision tree: Opțiunea A costă 20k și are 30% șansă de penalizare 50k → EMV = −20k + 0,3×(−50k) = −35k. Opțiunea B costă 30k, 5% șansă de penalizare 50k → EMV = −30k − 2,5k = −32,5k → alegi B, deși pare mai scumpă inițial.

strategii de răspuns

• Fiecare răspuns primeşte un risk owner; răspunsurile pot genera riscuri secundare (noi riscuri din răspuns) și rămân riscuri reziduale (ce rămâne după răspuns).
• Contingency plan (plan A dacă riscul se materializează, declanșat de triggers) + fallback plan (dacă nici contingency-ul nu merge).

rezerve & monitorizare

• Contingency reserve: pentru riscuri identificate (known unknowns) — în cost baseline, la dispoziția PM-ului.
• Management reserve: pentru neprevăzute (unknown unknowns) — în afara baseline-ului; accesul cere aprobarea managementului (și de regulă un change request pentru a o muta în baseline).
• Monitor risks: risk reviews periodice, risk audits (eficacitatea procesului de risc), reserve analysis (mai ajung rezervele?), urmărirea triggerelor.

decizia make-or-buy

Compari costul total (nu doar prețul!), capacitatea internă, riscurile, proprietatea intelectuală și viteza. Externalizezi ce nu e competența ta de bază sau ce nu poți livra la timp intern.

tipurile de contract — și cine poartă riscul

documentele de achiziție

• Procurement SOW: descrierea muncii de achiziționat, suficient de detaliată ca ofertanții să poată răspunde.
• RFI (cerere de informații — explorezi piața) → RFQ (cerere de cotație — decizia se ia preponderent pe preț) → RFP (cerere de propunere — soluție + abordare + preț, criterii multiple).
• Source selection criteria publicate din timp; bidder conferences: toți ofertanții primesc aceleași informații, în același timp (corectitudine).
• Independent cost estimate: estimarea proprie ca reper de rezonabilitate a ofertelor.

administrarea și închiderea contractelor

• Contractul e obligatoriu juridic: orice schimbare — doar în scris, prin procesul de contract change control. Comunicarea formală (scrisă) primează în relația cu vânzătorul.
• Monitorizezi performanța vânzătorului (inspecții, audituri, rapoarte, milestone-uri de plată), gestionezi claims (revendicări disputate) — ideal prin negociere; altfel ADR: mediere/arbitraj.
• Închiderea: verifici livrabilele acceptate, plățile finale, arhivezi, lessons learned. Contractele se închid înaintea închiderii proiectului.

Stakeholder = orice persoană, grup sau organizație care afectează sau este afectată de proiect (sau se percepe astfel): sponsor, client, utilizatori, echipă, management funcțional, furnizori, autorități, comunități. Identificarea începe de la charter și continuă permanent — stakeholderii descoperiți târziu sunt sursă clasică de schimbări scumpe.

analiza stakeholderilor

• Stakeholder register: identificare, evaluare (cerințe, așteptări, influență), clasificare.
• Grila putere/interes (power/interest grid):
  • putere mare + interes mare → manage closely (implicare strânsă);
  • putere mare + interes mic → keep satisfied;
  • putere mică + interes mare → keep informed;
  • putere mică + interes mic → monitor.
• Alte modele: power/influence, salience model (putere + legitimitate + urgență), stakeholder cube.

stakeholder engagement assessment matrix

Compari nivelul curent (C) cu cel dorit (D) de implicare pentru fiecare stakeholder:

Unde C ≠ D, planifici acțiuni concrete în stakeholder engagement plan: comunicare țintită, implicare în decizii, adresarea îngrijorărilor, quick wins care demonstrează valoare.

lucrul cu stakeholderii dificili

1. Înțelege întâi: discuție directă, privată — care e îngrijorarea reală? (des: teamă de impact asupra rolului lui).
2. Adresează îngrijorarea în plan (nu o ignora și nu o „vinzi” cu marketing).
3. Implică-l: oamenii sprijină ce au ajutat să construiască.
4. Monitorizează continuu — engagementul se schimbă pe parcurs.

conformitatea proiectului (compliance)

• Identifici de la început cerințele de conformitate: legislație (ex: GDPR, siguranța muncii), reglementări de industrie, standarde (ISO), politici interne, cerințe contractuale, praguri de calitate.
• Le tratezi ca cerințe obligatorii (non-negociabile) în scop și ca surse de risc: clasifici, măsori consecințele neconformității, aloci responsabili, auditezi periodic.
• Când apare o potențială încălcare: oprești/corectezi întâi, comunici transparent conform politicii, escaladezi la nivelul potrivit (legal/compliance). Nu ascunzi, nu amâni.
• Metode de suport: quality audits, checklist-uri de compliance, consultarea experților juridici, includerea cerințelor în DoD (în agil).

livrarea valorii — nu doar a livrabilelor

• Valoarea se definește în business case și benefits management plan și se urmărește pe tot parcursul: proiectul care livrează „on time, on budget” un produs nefolosit e un eșec.
• Evaluezi continuu alinierea: dacă mediul de business s-a schimbat și beneficiile nu mai stau în picioare, PM-ul ridică problema către sponsor — inclusiv recomandarea de a opri proiectul. A opri un proiect care nu mai are sens e un succes de guvernanță, nu o rușine.
• În agil, valoarea se livrează incremental și se măsoară devreme (MVP, feedback, metrici de utilizare) — reprioritizezi backlog-ul pe valoare.
• Beneficiile se realizează adesea după proiect — de aceea benefits plan definește owner-ul beneficiilor și măsurătorile post-livrare.

organizational change management

Proiectul livrează capabilitatea; valoarea apare doar dacă oamenii adoptă schimbarea. Managementul schimbării organizaționale pregătește oamenii afectați — diferit de change control (care gestionează modificările baseline-urilor).

• Modelul ADKAR (per individ): Awareness (de ce e nevoie de schimbare) → Desire (vreau să particip) → Knowledge (știu cum) → Ability (pot efectiv) → Reinforcement (schimbarea se menține).
• Kotter — 8 pași (organizațional): creezi urgență → coaliție de ghidare → viziune și strategie → comunici viziunea → înlături obstacolele (empowerment) → generezi short-term wins → consolidezi și continui → ancorezi în cultură.
• Practic în proiect: comunicare timpurie și onestă cu cei afectați, implicarea lor în design, training, suport post-lansare, campioni ai schimbării, măsurarea adopției.

schimbările din mediul extern

• Scanezi continuu mediul (PESTLE: politic, economic, social, tehnologic, legal, environmental): reglementări noi, mișcări ale competiției, tehnologii, condiții geopolitice și de piață.
• Când mediul se schimbă: evaluezi impactul asupra backlog-ului/scopului, riscurilor și business case-ului → recomanzi ajustări prin canalele de guvernanță.
• Sustenabilitate: impactul social și de mediu al proiectului face parte din responsabilitatea PM-ului (principiul stewardship).

guvernanță organizațională & proiect

• Proiectul funcționează în cadrul de guvernanță: comitete de conducere (steering committee), phase gates, praguri de escaladare, politici de raportare.
• PM-ul cunoaște ce decizii îi aparțin și ce se escaladează — și folosește structura, nu o ocolește.

Codul de Etică și Conduită Profesională PMI se aplică tuturor membrilor și deținătorilor de certificări. Are 4 valori, fiecare cu standarde aspiraționale (spre ce tindem) și obligatorii (ce e cerut, cu consecințe la încălcare).

cele 4 valori

situații clasice de examen

• Mită / „cadouri de facilitare”: refuzi, indiferent de „obiceiul locului”; urmezi legea și politica firmei (legile anti-corupție se aplică transfrontalier).
• Presiune să falsifici statusul: refuzi; propui transparență + plan de acțiune.
• Descoperi că un colaborator încalcă regulile: nu ignori; verifici faptele și raportezi prin canalele corecte.
• Informații confidențiale de la un fost angajator / concurent: nu le folosești.
• Copyright/licențe: nu folosești software sau materiale fără licență „doar ca să terminăm sprintul”.

Sinteza reflexelor care aleg răspunsul corect între două opțiuni plauzibile — recitește pagina asta înainte de examen.

roluri & decizie

• PM-ul e proactiv, direct și transparent: investighează întâi, decide pe date, comunică vestea proastă devreme.
• Escaladarea e ultima opțiune — după ce ai încercat rezolvarea la nivelul tău. Dar ce depășește autoritatea ta (buget suplimentar, priorități între proiecte) se escaladează fără ezitare.
• Echipa estimează și decide „cum”; PM-ul asigură „de ce” și „ce”, înlătură obstacole, protejează focusul.
• Problemele cu oameni: întâi discuție privată, direct cu persoana. HR/managerul funcțional — abia după.

proces

• Schimbare cerută (oricine, oricât de mică) → evaluezi impactul → change control. Nu implementezi, nu refuzi din prima.
• Risc nou → register + analiză. Issue → issue log + owner + acțiune.
• Livrabil terminat → control quality (intern) → validate scope (acceptare client).
• Nimic „din memorie”: planurile, registrele și lessons learned se actualizează mereu la final de acțiune.
• Închiderea se face complet chiar și la anulare: acceptări, arhivare, lecții, eliberarea echipei.

agil

• Backlog-ul îl prioritizează doar Product Owner-ul — pe valoare.
• Sprintul e protejat: cererile noi intră în backlog, nu în sprintul curent.
• Problemele de proces se rezolvă în retrospectivă; produsul se inspectează la review.
• Autoorganizare: nu asigni tu task-uri; facilitezi ca echipa să-și ia singură munca.

eliminarea rapidă a variantelor

• Taie variantele cu: „ignoră”, „așteaptă”, „ascunde”, „fă direct fără analiză”, „concediază”, „escaladează imediat”, „refuză categoric”.
• Preferă variantele cu: „meet with”, „review”, „analyze”, „update the plan/register”, „communicate to affected stakeholders”.
• La „what FIRST” alege pasul de înțelegere/analiză; la „what NEXT” alege pasul următor din proces, nu sări etape.

Toate formulele examenului, într-un singur loc. La centrul de testare primești foaie/whiteboard: în primele minute, scrie-le din memorie (brain dump) și apoi doar aplici.

earned value

Interpretare: variație negativă = rău; index sub 1 = rău. EV e primul în toate.

estimare & schedule

comunicare & risc & selecție

contracte cu incentive (dacă apare calcul)

valori de reținut pe de rost

în ziua examenului

• Ritm: 230 min / 180 întrebări ≈ 76 sec/întrebare. Nu te bloca: marchează („flag”) și mergi mai departe; revii în fereastra secțiunii curente (după pauză nu te mai poți întoarce la secțiunea anterioară).
• Brain dump în primele 2 minute: formulele EVM, PERT, canale, strategiile de risc, tipurile de contract.
• Citește ultima propoziție a întrebării întâi (ce se cere exact), apoi scenariul. Atenție la NOT/EXCEPT/FIRST/NEXT/BEST.
• Elimină 2 variante evident greșite → alegi dintre 2 pe mindset PMI (modulul 10).
• Nu schimba răspunsuri fără motiv concret — prima intuiție educată e de obicei corectă.

planul de pregătire recomandat

1. Termină toate modulele + quizurile acestui curs (țintă: ≥80% la fiecare quiz, din a doua încercare).
2. Fă simularea finală de mai jos fără pauză, cronometrat (~40 min).
3. Aprofundează zonele slabe (revino la modulele respective; refă quizurile).
4. Pentru volum suplimentar de practică: PMI Study Hall (banca oficială de întrebări) și simulatoare full de 180 de întrebări. Țintă înainte de examenul real: 75%+ constant pe simulări complete.
5. Aplică pe pmi.org din timp (aprobarea + programarea durează).

după certificare

PMP se menține cu 60 PDU / 3 ani (professional development units): cursuri, webinarii, voluntariat, practică. Aliniate pe Talent Triangle (minim pe fiecare latură).