Expand search form

Corsi e certificazioni on line

Ottieni le certificazioni più richieste senza spendere una fortuna e da casa tua

PRINCE2®: i principi

Soltanto burocrazia?

Sono migliaia in Italia le persone in possesso di certificazioni di Project Management, ma sono pochissime le aziende italiane che applicano davvero PRINCE2® o altre metodologie di Project Management. La motivazione più comune per questo comportamento apparentemente irrazionale è la mancanza di tempo, o la troppa burocrazia necessaria per seguire le indicazioni della guida.

I principi di PRINCE2® per raggiungere gli obiettivi di progetto
I principi di PRINCE2® per raggiungere gli obiettivi di progetto


Mi sono quindi chiesto più se tutto quello che racconto da anni in aula è utile, o serve soltanto a distribuire in giro dei certificati per partecipare a qualche gara pubblica. Per trovare una risposta ho fatto un esperimento; ho stravolto i sette principi di PRINCE2®, ottenendo così i sette principi per garantire il fallimento di un progetto.

7 principi per far fallire il tuo progetto

  1. Assenza di una vera motivazione aziendale
  2. Omertà nella gestione dei problemi
  3. Ruoli e responsabilità devono essere vaghi
  4. Suddividere il progetto in fasi è pericoloso
  5. È sempre colpa del fornitore
  6. Lavorare è più importante che ottenere un risultato
  7. Il bello delle metodologie è che sono uguali per tutti

1: Assenza di una vera motivazione aziendale

Il Project Manager che voglia garantire l’insuccesso del progetto di cui è responsabile:

  • Si accerterà – prima di avviare un progetto- che non esista alcuna motivazione aziendale valida e riconosciuta da tutti per portarlo a termine.
  • Eliminerà immediatamente eventuali motivi validi che dovessero evidenziarsi.
  • Garantirà che non resti alcuna traccia scritta di eventuali analisi relative a quanto esposto nei punti precedenti.

L’assenza di tracce scritte eviterà che il progetto sia interrotto nel caso cambino le condizioni al contorno. In questo modo anche progetti con benefici scarsi o nulli, o in contrasto con la strategia aziendale, potranno procedere indisturbati fino al completamento.

Inoltre l’assenza di un Business Case formale consentirà la creazione e la gestione di un Project Portfolio in cui possono essere sviluppati con successo progetti con obiettivi contrastanti o duplicati.

L’assenza di un Business Case consentirà inoltre a tutti coloro che hanno degli interessi personali nel progetto di curarli in piena tranquillità.

Purtroppo esistono progetti la cui attivazione è legata al soddisfacimento di requisiti di natura obbligatoria, quali ad esempio l’adozione di nuove leggi o regolamenti.

L’assenza di un Business Case formale ci fornirà dei vantaggi anche in questi casi, dal momento che potremo scegliere un approccio qualsiasi alla realizzazione, senza curarci di costi, benefici e rischi.

Formalizzare il motivo per cui abbiamo iniziato un progetto ci costringerebbe a garantire la compatibilità dello sviluppo con la giustificazione iniziale, con il rischio di interrompere il progetto nel caso tale compatibilità non fosse più possibile.

L’interruzione del progetto avrebbe come conseguenza l’allocazione dei fondi ad altri progetti presunti più interessanti, esito questo che il Project Manager avrà cura di impedire ad ogni costo.

2: Omertà nella gestione dei problemi

I team di progetto che non applicano PRINCE2® hanno cura di ignorare le esperienze precedenti, e non corrono inutili rischi nel documentare lezioni da registrare e in seguito alle quali agire.
I progetti prevedono un’organizzazione provvisoria per un tempo indefinito, al fine di raggiungere uno scopo aziendale altrettanto indefinito. I manager di linea e di unità funzionale cercheranno quindi di mantenere un controllo puntuale sui progetti, dal momento che sanno che il team provvisorio generalmente non ha l’esperienza necessaria a gestire la situazione, e che tale inesperienza in genere conduce al fallimento. Dove non sia possibile mantenere tale controllo è necessario garantire che gli errori che immancabilmente Project Manager e team commetteranno siano accuratamente tenuti nascosti.
Ci sono almeno tre momenti, nel corso del progetto, in cui l’omertà dovrà essere garantita.

  • Al momento dell’avvio di un progetto. In genere è sempre possibile individuare progetti precedenti o simili che sono già falliti; nascondere le tracce di questi progetti è fondamentale, dal momento che la diffusione di queste informazioni potrebbe far cancellare l’iniziativa. Si dovrà porre grande attenzione anche ad evitare la diffusione di informazioni circa eventuali fallimenti di altri. I successi dei progetti precedenti andranno nascosti alla stessa maniera, dal momento che rischiano di porre in cattiva luce il lavoro del progetto in corso.
  • Nel corso del progetto. Il rischio che il progetto evidenzi carenze del team, del management o dell’organizzazione è sempre in agguato. Si eviterà quindi di lasciare qualsiasi traccia di tali informazioni in tutti i rapporti e in tutti i documenti di progetto. Nel caso improbabile in cui il team evidenziasse performance brillanti queste andranno accuratamente tenute nascoste, per evitare che il committente riduca le stime di tempo e di costo del progetto.
  • Alla chiusura del progetto. Come si è visto il fallimento di un progetto potrebbe causare problemi ai progetti successivi. Si avrà quindi cura di evitare di lasciare traccia scritta delle cause di tale fallimento; se questo non fosse possibile si avrà cura di evitare che tali tracce scritte abbiano conseguenze sull’organizzazione. È altresì poco cortese documentare eventuali soluzioni brillanti che il team dovesse per inesperienza avere applicato, per gli effetti negativi che questo potrebbe avere sui progetti successivi.

Qualsiasi membro zelante e inesperto del team (o anche un consulente esterno) potrebbe lasciarsi sfuggire informazioni riguardanti problemi individuati nel progetto o nell’organizzazione; sarà cura del Project Manager creare l’opportuno clima di omertà e sfiducia necessario per evitare che ciò avvenga.

3: Ruoli e responsabilità devono essere vaghi

I team di progetto che non applicano PRINCE2® hanno cura di lasciare alla libera interpretazione dei singoli i ruoli e le responsabilità, in modo che l’azienda, gli utenti e i fornitori possano evitare i propri doveri e far ricadere eventuali colpe sugli altri.
È necessario tener presente che purtroppo i progetti prevedono il coinvolgimento di individui, e anche se abbiamo evitato accuratamente ogni forma di pianificazione e controllo è sempre possibile che qualche soggetto inopportuno voglia sapere cosa ci si attende da lui durante il progetto, o, peggio, abbia delle aspettative nei confronti degli altri.
Generalmente i progetti hanno natura interfunzionale, coinvolgono più di un’organizzazione e impiegano un mix di risorse a tempo pieno e a tempo parziale. Le strutture burocratiche cui le risorse rispondono sono quindi diverse e hanno priorità, obiettivi e interessi diversi da proteggere. Inoltre tali strutture generalmente non hanno nessun desiderio di occuparsi del progetto, dal momento che hanno pagato uno o più fornitori per realizzarlo.
Per evitare la riuscita del progetto è necessario che la struttura organizzativa che lo gestisce non sia definita; si eviterà quindi di fissare e concordare ruoli e responsabilità, in modo da evitare che le parti interessate possano comunicare tra loro e quindi possano capire come stanno realmente le cose.
Per semplicità suddivideremo le parti interessate in tre grandi categorie:

  • Sponsor, ovvero coloro che hanno incautamente assegnato un budget al progetto e ingaggiato un fornitore per realizzarlo. Il principale interesse degli sponsor è dimostrare che non è stato possibile raggiungere l’obiettivo del progetto per colpa del fornitore.
  • Utenti, ovvero coloro che pur non avendo alcuna colpa sono stati coinvolti nel progetto. Il principale interesse degli utenti è evitare il completamento del progetto, che potrebbe avere ripercussioni anche gravi sul loro lavoro futuro.
  • Fornitori, ovvero coloro che hanno incautamente accettato un incarico nella vana speranza di ricavarne un utile. Il principale interesse del fornitore è dimostrare allo sponsor che il prodotto del progetto è perfetto, e che tutti i problemi derivano dagli utenti.

Come si può vedere facilmente gli interessi delle parti divergono in modo inconciliabile, ed è quindi necessario che una delle tre vinca e le altre due soccombano. Occorre evitare che il progetto sia interrotto prima del termine perché i costi superano i benefici, ma occorre evitare anche che si possa dire che il risultato finale del progetto non soddisfa gli utenti o non possa essere materialmente realizzato. Pertanto lo sponsor avrà cura di evitare di dichiarare i benefici attesi (anche perché non ve ne sono), e il fornitore avrà cura di evitare di dire che il progetto non è fattibile (altrimenti non sarà pagato). Gli utenti, dal canto loro, potranno accettare il prodotto del progetto per evitare inutili discussioni, certi che prima o poi tale prodotto sarà accantonato e loro potranno tornare a lavorare come prima.

Quanto detto sopra, pur essendo noto a tutti, non potrà essere dichiarato pubblicamente per ovvi motivi; è quindi necessario evitare a tutti i costi che siano definiti ruoli e responsabilità chiare all’inizio del progetto, onde evitare spiacevoli conseguenze per lo sponsor, per il fornitore e per gli utenti. Si avrà quindi cura di evitare di dichiarare cosa ci si attende da tutti i soggetti coinvolti.

4: Suddividere il progetto in fasi è pericoloso

È necessario evitare che il committente del progetto disponga di punti di controllo pianificati durante il progetto, per evitare che qualcuno valuti lo stato del progetto, si faccia venire dei dubbi sulla sua convenienza, sulla sua fattibilità o sui piani che sono stati predisposti, ed eventualmente decida di cancellarlo.

La suddivisione in fasi consentirebbe infatti alla direzione del committente di esercitare un maggior controllo sul progetto, adeguandolo alle proprie priorità di business, al rischio che intende correre e alla complessità delle attività. Evitate quindi questo rischio impedendo alla direzione del committente di esercitare tale controllo; la pianificazione ideale prevede un’unica fase progettuale.

Per ottenere tale risultato è sufficiente estendere l’orizzonte di pianificazione fino a fine progetto; questo richiederà uno sforzo di creatività al Project Manager, che dovrà realizzare dei piani dettagliati per ciascun membro del team per almeno i prossimi 12 mesi. I piani saranno stampati sotto forma di diagramma di Gantt in formato almeno A3 e presentati al committente il giorno del kick-off di progetto. Non si deve avere timore del fatto che i piani così realizzati saranno obsoleti dopo poche ore; nessuno li consulterà mai più, per paura di essere tacciato di inadempienza.

In sintesi il Project Manager che voglia essere certo di portare a termine il proprio progetto dovrà:

  • organizzare il progetto in modo che il risultato finale sia disponibile al termine di un’unica, lunghissima fase progettuale,
  • creare un Piano di Progetto che descriva dettagliatamente le attività di ciascun team member per ogni giornata del progetto,
  • stampare in formato almeno A3 il diagramma di Gantt risultante ed affiggerlo alle pareti del proprio ufficio,
  • rinfacciare costantemente a tutti (soprattutto al committente) il mancato rispetto delle tempistiche indicate,
  • far fronte giorno per giorno agli eventuali problemi che naturalmente si manifesteranno.

5: È sempre colpa del fornitore

È necessario evitare a ogni costo che le responsabilità del progetto risalgano la catena di comando fino a coinvolgere la direzione del committente o comunque le persone incaricate dal committente della gestione del progetto. Si avrà quindi cura di delegare tutte le responsabilità al fornitore. In particolare ci si focalizzerà sui seguenti aspetti:

  • Tempistica La data di completamento indicata è assolutamente tassativa.
  • Costo Il budget prestabilito è assolutamente tassativo.
  • Qualità Non saranno mai fissati a priori parametri qualitativi, per dare la possibilità al committente di decidere i parametri più adatti al momento della consegna.
  • Ambito L’ambito del progetto non sarà mai fissato a priori, per dare la possibilità al committente di modificarlo quando necessario.
  • Rischi Quali rischi? Il committente ha individuato un fornitore proprio perché si faccia carico dei rischi.
  • Benefici Come si è detto nella prima parte di questo articolo tutte le parti interessate devono accuratamente evitare di individuare i benefici del progetto.

Dovranno essere attuati meccanismi opportuni per evitare che il fornitore porti all’attenzione dei livelli superiori una questione, o per minimizzare l’impatto di tali questioni sul committente. Uno dei meccanismi più efficaci è costituito dalla cosiddetta “garanzia”, che ha il compito di redigere procedure che nessuno legge e che quindi possono essere utilizzate per attribuire le colpe di eventuali problemi alla parte più debole della catena di fornitura.
Attuare i meccanismi sopra descritti consente al committente di disinteressarsi completamente del progetto e dedicarsi ad altro, senza tuttavia privarsi della possibilità di attribuire al fornitore tutte le responsabilità dell’inevitabile fallimento del progetto.

6: Lavorare è più importante che ottenere un risultato

Un progetto di successo è orientato alle attività, e non ai risultati. Un progetto orientato ai risultati obbligherebbe infatti tutte le parti interessate a concordare e definire i prodotti del progetto prima dell’avvio delle attività finalizzate alla loro realizzazione. Questo approccio è estremamente rischioso per il committente, che non sa quello che vuole, e quindi non ha nessuna intenzione di chiarire a priori cosa desidera.
Il committente non ha certamente investito i suoi denari per soddisfare le iniziative delle parti interessate, o in conformità a una presunta inesistente motivazione commerciale, come abbiamo già visto trattando del primo principio. Evitando di stabilire con chiarezza la natura dei prodotti da realizzare e i relativi criteri di approvazione consentiamo al committente di lasciare la finalità del progetto aperta a numerose e diverse interpretazioni.

Eviteremo quindi di descrivere in dettaglio i prodotti da realizzare, in modo che scopo, composizione, derivazione, formato, criteri e procedure relative alla qualità siano flessibili. Le stime di costo per ciascun prodotto saranno imposte dal committente, mentre i requisiti in materia di risorse, le dipendenze tra le attività e i relativi cronogrammi saranno opportunamente delegate al fornitore, che in fondo viene pagato per questo.

Evitando di focalizzarci sui prodotti fin dall’inizio eviteremo inutili discussioni su aspetti fastidiosi quali la pianificazione, le responsabilità, i rapporti di avanzamento lavori, la qualità, il controllo delle modifiche, la gestione dell’ambito e della configurazione.

Evitando di focalizzarci sui prodotti consentiremo inoltre al committente di:

  • rifiutare i prodotti qualora questi risultassero insoddisfacenti
  • introdurre tutte le varianti necessarie
  • evitare ogni inutile burocrazia legata alla gestione delle modifiche
  • sprecare tempo per attività che devono essere svolte dal fornitore

7: Le metodologie sono uguali per tutti

Una volta investito del tempo e del denaro per la formazione in una metodologia di Project Management come PRINCE2® è bene evitare qualsiasi adattamento all’ambiente, all’entità, alla complessità, all’importanza, alla capacità e al rischio relativi al progetto

Il bello delle metodologie come PRINCE2 consiste nella loro universalità di applicazione nella gestione dei progetti, a prescindere dal tipo di progetto, organizzazione, ubicazione geografica o cultura, impedendo così pericolosi adattamenti alle esigenze specifiche dello stesso.

Impedendo ogni adattamento del metodo PRINCE2® evitiamo inutili sforzi per inventare l’applicazione di metodi personalizzati per la gestione del progetto, presunti idonei per le esigenze dello stesso. Consentiamo in questo modo sia una gestione “robotizzata” del progetto (si segue il metodo senza chiedersene in perché), che una gestione “eroica” del progetto (di giorno si realizza quello che vuole il committente e di notte si produce la documentazione).

Evitare l’adattamento consente di:

  • Garantire che il metodo di gestione del progetto sia attinente alle regole aziendali (p. es. allineandolo ai processi aziendali in grado di far funzionare e sostenere il progetto, quali risorse umane, finanze e approvvigionamenti)
  • Garantire che i controlli di progetto si basino sull’entità di quest’ultimo, nonché sulla sua complessità, rilevanza, capacità e rischio (p. es. frequenza e formalità dell’attività di reporting e di verifica).

Evitare l’adattamento rende più efficienti il Project Manager e il Comitato di Progetto, che devono limitarsi ad applicare il metodo per cui sono stati formati. Durante la fase di applicazione di PRINCE2®, è importante ricordare che il metodo richiede informazioni, da riportare necessariamente su documenti approvati dal committente, e decisioni, verbalizzate al termine delle riunioni di avanzamento lavori.

Al fine di assicurare la corretta assimilazione di PRINCE2® da parte dei soggetti coinvolti nel progetto e preposti all’utilizzo del metodo, la Documentazione dell’Inizio del Progetto deve indicare chiaramente l’obbligatorietà di adozione di quanto specificato dalla metodologia.

Certificazioni PRINCE2®

Per PRINCE2 sono disponibili due edizioni (5th e 6th) e due livelli di certificazione; il livello Foundation, che verifica la conoscenza del metodo da parte del candidato, e il livello Practitioner, che ha come obiettivo valutare se il candidato è in grado di applicare il metodo a un caso di studio. Per ulteriori informazioni puoi consultare le pagine dei corsi di preparazione agli esami: