Concetti fondamentali
PRINCE2
Sette principi, sette pratiche, sette processi.
PRINCE2
PRINCE2 (PRojects IN Controlled Environments, versione 2) è uno standard metodologico strutturato di project management, sviluppato dal governo britannico negli anni '80 (originariamente PROMPT II → PRINCE → PRINCE2 nel 1996).
È molto diffuso in UK, Europa, Australia, settore pubblico e grandi aziende. Mantenuto oggi da AXELOS/PeopleCert, con certificazioni Foundation e Practitioner.
A differenza di Scrum (framework leggero) e PMBOK (knowledge base), PRINCE2 è una metodologia prescrittiva: dice esattamente cosa fare, quando e con quali documenti.
Le 4 componenti integrate
PRINCE2 è organizzato in:
- 7 Principi — what (i pilastri filosofici, non negoziabili)
- 7 Pratiche (ex "Temi") — how (le aree da gestire continuamente)
- 7 Processi — when (le fasi sequenziali)
- Adattamento al contesto — tailoring (non si applica meccanicamente)
I 7 Principi
Un progetto è "PRINCE2" se rispetta tutti e 7 questi principi:
- Continued Business Justification — il business case è valido all'inizio, durante e alla fine. Se non lo è più, si chiude il progetto.
- Learn from Experience — si capitalizzano lezioni dai progetti precedenti (e durante questo).
- Defined Roles and Responsibilities — chi fa cosa è chiaro a tutti.
- Manage by Stages — il progetto è diviso in stage gestibili, con decisioni di go/no-go ad ogni stage gate.
- Manage by Exception — il management interviene solo se si esce dalle tolleranze definite (su tempi, costi, scope, qualità, rischio, benefici).
- Focus on Products — si gestisce per prodotti/deliverable, non per attività.
- Tailor to Suit the Project Environment — la metodologia si adatta a dimensione, rischio, complessità.
Le 7 Pratiche (Themes)
Aree che devono essere gestite continuamente per tutto il progetto:
| # | Pratica | Cosa indirizza |
|---|---|---|
| 1 | Business Case | Il "perché" — giustificazione e benefici |
| 2 | Organization | Ruoli, responsabilità, struttura del team |
| 3 | Quality | Cosa qualifica il prodotto come accettabile |
| 4 | Plans | Come, da chi, quando, a quanto |
| 5 | Risk | Identificazione, valutazione, risposte |
| 6 | Issues (Change) | Gestione di problemi, change request, eccezioni |
| 7 | Progress | Monitoraggio, baseline, tolleranze |
Nel passaggio a PRINCE2 7 (2023), i Themes sono stati rinominati Practices con focus su sostenibilità e digitale.
I 7 Processi
Le fasi della metodologia (in ordine):
| # | Processo | Owner | Output chiave |
|---|---|---|---|
| 1 | Starting Up a Project | Executive | Project Brief, Project Approach |
| 2 | Directing a Project | Project Board | Decisioni di go/no-go |
| 3 | Initiating a Project | Project Manager | PID (Project Initiation Documentation) |
| 4 | Controlling a Stage | Project Manager | Work Packages, report stato |
| 5 | Managing Product Delivery | Team Manager | Deliverable consegnati |
| 6 | Managing a Stage Boundary | Project Manager | End Stage Report, piano stage successivo |
| 7 | Closing a Project | Project Manager | End Project Report, Lessons Learned |
La struttura del team PRINCE2
Ruoli di supporto (trasversali alla gerarchia):
- Project Assurance — controllo qualità ed esecuzione, indipendente dal PM
- Change Authority — decisioni su change request entro tolleranze delegate
- Project Support — PMO, amministrazione, configuration management
Documenti chiave (Management Products)
PRINCE2 prevede ~26 documenti formali. I principali:
Baseline (set una volta, gestiti via change)
- PID (Project Initiation Documentation) — il "Project Charter" PRINCE2, molto più esteso
- Business Case
- Project Plan
- Risk Management Approach, Quality Management Approach, ecc.
Records (registri continui)
- Risk Register
- Issue Register
- Quality Register
- Lessons Log → diventa Lessons Report a fine progetto
- Daily Log
Reports (a momenti specifici)
- Highlight Report (al Board, regolarmente)
- End Stage Report (a fine stage)
- Exception Report (quando si superano le tolleranze)
- End Project Report
Tolleranze e Management by Exception
Per ogni stage, il Project Board fissa tolleranze su 6 dimensioni:
| Dimensione | Esempio di tolleranza |
|---|---|
| Tempo | +/- 2 settimane |
| Costo | +/- 5% |
| Qualità | Difetti < 3% |
| Scope | Non più del 10% di scope opzionale rimosso |
| Rischio | Esposizione max € 100k |
| Benefici | Min 80% dei benefici attesi |
- Se il PM lavora dentro le tolleranze → procede senza disturbare il Board
- Se prevede di uscire dalle tolleranze → emette un Exception Report, il Board decide
- Risultato: il management interviene solo quando serve
PRINCE2 vs PMBOK vs Scrum
| Dimensione | PRINCE2 | PMBOK (PMI) | Scrum |
|---|---|---|---|
| Tipo | Metodologia prescrittiva | Knowledge base / standard | Framework |
| Origine | UK (anni '80) | USA (anni '80) | USA (anni '90) |
| Approccio | Process-driven, document-heavy | Knowledge-driven, flessibile | Empirico, leggero |
| Adatto a | Settore pubblico, grandi progetti regulated | Universale, certificazione PMP | Sviluppo prodotto iterativo |
| Certificazione | Foundation, Practitioner | CAPM, PMP | PSM, CSM, PSPO |
| Documentazione | Molto strutturata (26+ documenti) | Suggerita, flessibile | Minimale |
| Compatibile con Agile? | Sì (PRINCE2 Agile) | Sì (PMBOK 7 è agile-friendly) | È agile per definizione |
PRINCE2 Agile
Estensione ufficiale (2015) che combina PRINCE2 con framework agile (Scrum, Kanban). Idea: usare PRINCE2 per la governance (board, business case, stage) e Agile per la delivery (sprint, backlog).
Tipica configurazione hybrid: PRINCE2 a livello programma, Scrum/Kanban a livello team.
Punti di forza
- Governance forte — chiaro chi decide cosa
- Adatto a stakeholder multipli e regulated
- Manage by Exception evita micromanagement
- Focus sul Business Case continuo — non si fa il progetto "perché lo si è iniziato"
- Lessons learned strutturate
Punti di debolezza
- Burocrazia percepita: 26 documenti spaventano team piccoli
- Pesante per progetti agili: senza tailoring serio diventa frizione
- Curva di apprendimento: terminologia specifica (PID, SRO, Highlight Report...)
- Rischio formalismo: scrivere il documento ≠ gestire bene il progetto
Quando scegliere PRINCE2
✓ Sì se:
- Progetto grande, lungo, multi-stakeholder
- Settore pubblico / regolato (sanità, finanza, difesa)
- Più fornitori coinvolti
- Audit richiesto
- Cultura organizzativa già PRINCE2
✕ No se:
- Startup, prodotto digitale in early stage
- Team piccolo (< 10 persone), progetto breve
- Requisiti molto incerti → Agile puro è più adatto
- Cultura allergica alla documentazione strutturata
Anti-pattern
- ✕ Implementare PRINCE2 alla lettera senza tailoring → si soffoca il progetto
- ✕ Compilare i documenti per "compliance" senza usarli → spreco puro
- ✕ PID di 80 pagine → nessuno lo legge, perde efficacia
- ✕ Project Board che non decide → l'intero modello si rompe
- ✕ Confondere PRINCE2 con il Waterfall — è ortogonale e compatibile con Agile
Collegamenti
- Metodologie — confronto generale
- Scrum — framework Agile spesso usato in Hybrid con PRINCE2
- Project Charter — analogo (semplificato) del PID
- Risk Register — analogo al Risk Register di PRINCE2
- Lessons Learned — analogo al Lessons Log/Report
- Stakeholder — il Project Board è la massima espressione di stakeholder governance