PRINCE2

Il PROGETTO

PRINCE: Projects in Controlled Environment

Framework composto da 7 TEMI, 7 PRINCIPI e 7 PROCESSI e dall’integrazione degli stessi nel

contesto di progetto.

Temi: IL COSA
Principi: IL PERCHE’
Processi: IL COME

PRINCE2 chiarisce come integrare processi, temi e principi nell’ambiente e nelle circostanze del
progetto.

Progetto: organizzazione temporanea creata con lo scopo di generare uno o più prodotti in base
ad un business case.

Caratteristiche di un progetto:
Cambiamento: il progetto apporta un cambiamento nell’organizzazione che lo esegue
Temporaneità: Il progetto è temporaneo e ha sempre una data di inizio e di fine.
Unicità: ogni progetto è unico perché deve produrre risultati unici in un tempo determinato.
Trasversalità: Il progetto coinvolge figure con skillset diversi
Incertezza: Il progetto include sempre una dose di rischio e il risultato è sempre incerto.

Il progetto serve a Pianificare, delegare, monitorare, controllare una serie di attività che portano al
risultato atteso.

Gli aspetti principali di un progetto sono:

Costi
Tempi
Qualità
Ambito
Rischi
Benefici Attesi

PRINCIPI:

I principi sono linee guida che definiscono l’approccio del PM verso il progetto e provengono dalle
lesson learned di tutti i progetti eseguiti. Essi servono a mantenere il controllo del progetto e in
caso di crisi per aiutare a risolverla.

I principi sono universali e si applicano a tutti i progetti. Sono auto-validanti perché testati nel corsi
di tanti anni e innumerevoli progetti.

Ogni progetto PRINCE2 deve includere tutti i 7 principi per essere considerato tale.
1. Giustificazione continua del Business Case
Un progetto deve avere una ragione giustificabile per nascere, ovvero deve essere presente
un documento di business Case che descrive perché nasce il progetto e quali benefici attesi
si propone.

Tale giustificazione deve rimanere valida per tutto il progetto, anche se può essere variata
nel corso del tempo (con una ufficiale variazione del documento)

Ad ogni fase del progetto il Business Case va aggiornato e controllato per verificare
l’allineamento del progetto con la sua giustificazione. Se questo allineamento mancasse il
progetto deve terminare.

2. Imparare dall’esperienza

Il team di progetto impara da dati storici, da precedenti progetti della stessa organizzazione
o da altre organizzazioni.

Il processo di apprendimento avviene all’inizio del progetto, al termine di ogni fase e al

termine del progetto.

Tutti sono responsabili per la raccolta di lesson learned.

Ogni progetto deve avere un registro delle lesson learned.

3. Ruoli e responsabilità

Le persone coinvolte nel progetto devono conoscere con esattezza il loro ruolo ed il ruolo
degli altri soggetti convolti.

I ruoli sono strutturati in 4 livelli: Corporate management, Project Board, Project

Management, Team di Progetto. I principali fautori del progetto sono nel Project
Management e nel Team di Progetto.

Gli stakeholders principali del progetto sono: Sponsor, Utenti, Fornitori

Tutti questi ruoli vanno chiaramente definiti in ogni progetto.

4. Gestione per fasi

Sia la gestione che l’esecuzione del progetto devono avvenire per fasi : le fasi di gestione e
le fasi tecniche.

Le fasi si susseguono in maniera logica e al passaggio di fase vanno eseguiti una serie di
aggiornamenti come la revisione del business case, dei rischi e della pianificazione alla luce
delle evidenze emerse nella fase completata.
 Un progetto PRINCE2 deve avere almeno 2 fasi (iniziazione e almeno un’altra fase di
gestione)

Più una fase è breve più è facile controllarla.

5. Gestione per eccezioni

Una volta pianificato un progetto viene eseguito dai delegati, monitorato e controllato e
nel corso del lavoro possono emergere scostamenti dal piano che coinvolgono Tempi,
Costi, Rischi, Ambito, Qualità e Benefici Attesi. Queste eccezioni vengono gestite in base al
ruolo. Come detto in precedenza ci sono il Corporate management, il project board, il
project management e il team di progetto. Ogni ruolo ha una serie di responsabilità e delle
soglie di scostamento per ogni aspetto del progetto che può gestire. Al di fuori di quella
soglia l’eccezione va passata al ruolo superiore attraverso una escalation. Es: Se una attività
programmata si rimanda di un giorno può essere una eccezione gestita dal team di
progetto perché magari la soglia di tolleranza era 3 giorni. Sopra i 3 giorni la decisione
passa al project manager, e così via in base alle varie soglie di tolleranza di ogni ruolo.

6. Focus sul prodotto

Un progetto PRINCE2 è focalizzato sul risultato da raggiungere, più che sul processo. Il
progetto è orientato al prodotto desiderato, quindi prima di iniziare a fare qualsiasi cosa è
necessario definire i requisiti del prodotto che ne determinano poi la qualità.

Ogni prodotto necessita di una descrizione che spieghi : lo scopo del prodotto, la
composizione, la derivazione, il formato, la qualità, i criteri e la metodologia di produzione.
Questa descrizione serve a stimare l’effort necessario per le attività, definire le risorse
richieste, determinare le dipendenze e la schedulazione del lavoro.

7. Adattamento al contesto del progetto

Ogni progetto PRINCE2 è adattato al suo contesto. Questo significa che il metodo adottato
per la sua gestione è basato sulla grandezza, la complessità, l’importanza ed il rischio del
progetto stesso.

Nel documento iniziale di progetto (PID) viene descritto il metodo di gestione e come sia
adatto al contesto.

Non è detto che tutti i processi di PRINCE2 vengano applicati nel progetto o che vengano
applicati alla stessa intensità. Anche questo va previsto nel PID.
Tuttavia tutti i principi vanno applicati. Se alcuni principi vengono completamente omessi
non si parla di un progetto PRINCE2, ma di un PINO (Prince In Name Only).

TEMI

1. Business Case
Lo scopo del tema del Business case è fornire strumenti per poter giudicare che il Business
Case sia desiderabile, realistico, fattibile, e che continui ad esserlo durante tutto il progetto,
giustificando fino alla fine l’investimento per raggiungerlo.

Gli elementi principali del Business Case sono:

Desiderabilità: il risultato del progetto è davvero necessario? Quali sono i benefits, quali i
dis-benefits ? qual è il loro rapporto?
Realisticità: E’ possibile raggiungere il risultato atteso del progetto?
Fattibilità: Abbiamo ciò che serve per ottenere il risultato? Ne siamo capaci?
Giustificazione continua dell’investimento: Il business case continua ad essere
desiderabile, fattibile e realistico in ogni momento del progetto? Se no il progetto va
fermato.

Il Business Case è descritto in un documento chiamato Business Case Document. Questo

documento è la giustificazione per intraprendere il progetto basata sulla stima di costi,
rischi e benefici attesi.

L’Outline del BCD è redatta durante il processo “Starting up a project”, e viene dettagliato
durante il processo “Initiating a project”.
Il BCD è continuamente aggiornato con costi, tempi, rischi e benefici attesi.

Per giudicare la desiderabilità ci sono 4 elementi da valutare:

Output del progetto: il deliverable, il prodotto del progetto (es: un nuovo macchinario)
Outcome del progetto: il cambiamento che il deliverable di progetto apporta
all’organizzazione (es: la produzione è più veloce)
Benefits: sono i fattori misurabili del cambiamento ottenuto grazie al progetto (es:
aumento della produzione del 5% per giorno)
Dis-Benefit: le ricadute negative del progetto (es: riduzione del 30% dello spazio nell’area
di produzione dopo l’istallazione della nuova macchina)

Gli output realizzano dei cambiamenti nell’organizzazione i quali generano degli outcome
desiderati come degli effetti secondari e delle conseguenze attese. Gli outcome desiderati
vengono misurati attraverso i benefit. Anche gli effetti secondari possono portare a dei
benefit misurabili. Tutti i benefit misurabili contribuiscono al raggiungimento degli obiettivi
strategici dell’organizzazione. Le conseguenze e gli effetti secondari possono apportare
anche dei dis-benefit, anche essi misurabili e che contrastano il raggiungimento di obiettivi
strategici.

La gestione di questa interazione ed il controllo sulla sua evoluzione durante il progetto è

chiamato Benefits Management Approach.
Il BMA è un piano che prevede la definizione dei benefici attesi , dei disbenefits, come
misurarli e quando durante il progetto.
Il BMA viene creato nella fase di Project Initiation e riceve l’approvazione del Board.
Ad ogni fase il BMA viene aggiornato.
Il Senior User è responsabile per la definizione e la realizzazione dei benefici del BMA.

Il Business Case Document deve quindi essere: Creato, Approvato, (inizio progetto)
Mantenuto e Confermato (durante tutto il progetto, ad ogni fase).
Il documento è responsabilità del Corporate Management (Executive) che può delegarlo al
PM o ad un Business Analyst.

L’outline del BCD viene creata a partire dalle informazioni sul mandato del progetto prima
dell’inizio del progetto (project start up) e prima della fase di iniziazione. Poi viene
verificato (desiderabilità, fattibilità e realizzabilità) e approvato dal board e a quel punto si
avvia la fase di iniziazione durante la quale viene redatta la versione dettagliata del BCD.
Questa versione viene poi verificata e approvata dal Board alla fine dell’iniziazione e questo
permette l’avvio del progetto. Alla fine di ogni fase, compresa la fase di chiusura, il
documento viene mantenuto (aggiornato con tutti i dati acquisiti e le informazioni ricevute
durante l’esecuzione del progetto, come costi, rischi, tempi) e verificato, ed i benefici attesi
vengono confermati secondo quanto definito dal Benefit Management Approach (alla fine
del progetto, o in alcuni casi anche durante il progetto stesso si producono benefici es:
agile).

Ruoli:
Corporate Management: approva la outline del BC e rivede il BC dettagliato.
Project Board: rivede la outline del BC per decider se far partire il progetto
PM: fa riferimento al Bc quando valuta l’impatto di rischi, issues e changes.

Il Bc è solitamente strutturato con:

Executive summary: riassunto in breve
Reasons: descrizione della situazione attuale che ha generato il mandato di progetto e delle
opportunità o problemi che si affrontano con il progetto.
Business Options: Descrive tutte le possibili soluzioni includendo quelle raccomandate e
quelle da escludere
Benefici Attesi: i benefici realizzati alla fine del progetto
Dis-Benefits attesi: le conseguenze indesiderate del progetto
Tempi: tempi previsti per il progetto e per la realizzazione dei benefits
Costi: I costi previsti per il progetto e come ci si finanzia
Stima dell’investimento: specifica l’investimento necessario per eseguire il progetto
 Rischi principali: elenco dei maggiori rischi previsti per il progetto.

2. Organization

Un tempa fondamentale nella gestione di un progetto PRINCE2 è la definizione

dell’organizzazione. L’organizzazione deve essere definita, scritta, confermata e sottoscritta
da tutti. Ci deve essere chiarezza assoluta sui ruoli e le aspettative per ogni membro del
team di progetto.

Lo scopo di questo tema è definire il CHI. Ovvero quali sono i ruoli nel team di progetto.
Questa definizione è basata sulla dinamica customer / supplier.

Customer: sono quelli che beneficeranno del risultato del progetto e quindi hanno il ruolo
di definire i risultati attesi, in quanto molto probabilmente pagheranno loro per il progetto.
Supplier: Sono quelli che mettono a disposizione le risorse e le competenze necessarie a
produrre il risultato atteso dal progetto.

L’organizzazione può essere basata su PROGRAMMI o singoli PROGETTI;

Se si organizza un progetto singolo, allora il progetto fa parte della COMPANY
ORGANIZATION, altrimenti ci sarà un’organizzazione di programma.

PRINCE2 definisce i ruoli coinvolti nell’organizzazione, non le persone.

Una persona può avere più ruoli.

Uno stakeholder è una persona o un gruppo che viene coinvolto in qualsiasi modo nel
progetto. Ci sono 3 gruppi di stakeholders, in base a 3 principali interessi:
Business: L’executive role nel Board di progetto: è quello che cura l’interesse del business e
si assicura che ci sia un business case e che rimanga sempre valido.
User: sono quelli che beneficeranno del prodotto del progetto. Essi vengono rappresentati
nel board di progetto e sono i fondamentali custodi della qualità del prodotto e del suo
ambito. Il Senior user rappresenta gli interessi degli user nel board. Il senior User specifica i
requisiti degli user che beneficeranno del prodotto del progetto, si assicura che durante il
progetto l’output sia sempre allineato ai requisiti degli user.
Supplier: coloro che mettono a disposizione le risorse e competenze neccessarie per
produrre l’output di progetto. Può essere un interno o estero all’organizzazione. Gli
interessi dei supplier sono salvaguardati nel Board di progetto dal Senior Supplier. In
particolare è responsabile per la qualità del prodotto, per la fornitura delle giuste risorse e
per l’integrità tecnica del progetto.

Ci sono 4 livelli di gestione nella struttura del project management e 3 livelli nel project
management team:
La struttura di project management prevede il management dell’azienda o del programma
e il team di project management.
Il team di project management prevede:
un livello organizzativo: Il Board,
un livello direttivo: Project Manager
ed un livello operativo: Team Manager.

management dell’azienda o del programma: Commissiona il progetto, nomina l’executive

del board e decide come il board lo terrà aggiornato e con quale frequenza durante il
progetto. Decide inoltre i livelli di tolleranza per le escalation dal board di progetto.

Project Board: Dirige il progetto ed è responsabile del suo successo. Approva tutte le
risorse e i piani principali, approva le previsioni delle tolleranze e approva i passaggi di
stage. Si occupa di tenere i contatti con il corporate o program management e gli altri
stakeholders del progetto. Il lavoro del project Board è descritto dal processo “Directing a
Project”

Project Manager: Responsabile per il lavoro quotidiano di progetto. E’ la garanzia che il

progetto produca i giusti output in termini di tempi, costi, qualità, benefits e rischi.

Team Manger: Si occupa di produrre un output o parte di esso che gli è stato affidato nei
tempi, costi e qualità richiesti. Il team manager può formare un team e creare piani. Il
processo “Managing Product Delivery” descrive il lavoro del team manager.

Struttura del Project Management Team: Il board è composto da Executive (una sola
persona – ha l’ultima parola se non c’è accordo), Senior User (una o più persone) e Senior
Supplier (una o più persone).

Se il project board non ha le figure o il tempo per occuparsi della Project Assurance,
possono nominare per questo ruolo un esterno al board, ma non il Project Manager. Il
ruolo di Project Assurance fornisce consigli e guida su problemi durante il progetto. Per le
organizzazioni che ne sono provviste di solito la project Assurance è garantita dal PMO.

Change Authority: Il board deve deliberare qualsiasi cambiamento ai piani concordati

prima che sia reso operativo. Il ruolo di Change Authority può essere dato a persone
esterne al board se ci si aspettano molti chanegs. Diversi tipi di changes possono essere
gestiti in termini di Change Authority da diversi livelli della struttura di management in base
all’impatto del change. Di solito si definiscono livelli tolleranza dei changes e viene definito
quale livello di management e quale Change Authority è necessaria per approvare ogni
livello di change.
Project manager:

Team Manager:

Project Support:

Communicating with the corporate structure: Line managers vs PMO

Communicating with stakeholders:

Stakeholders management process:

Communication management approach: