Di progetti, programmi e catena del valore

POST ORIGINALE DEL 2017 CON AGGIUNTE NEL 2020

- Incertezza = mancanza di prevedibilità sui risultati

- Ambiguità = mancanza di accordo sugli obiettivi

Entrambe influenzano sia i processi decisionali che gli approcci di governo di progetti e programmi.

Chiariamo subito che il Program Management, a differenza del Project Management, mira maggiormente alla gestione degli obiettivi strategici, gestendo attività molteplici e interconnesse, che abbracciano più aree di business, per produrre vantaggi strategici.

E' quindi semplicistico definire un programma come un insieme di progetti.

Nell’ambiente turbolento e frenetico di oggi, un’organizzazione per essere competitiva deve essere orientata al progetto: tale organizzazione utilizzerà programmi per collegare una serie di processi aziendali, creando sinergia tra le sue diverse componenti. Si tratta senza dubbio di un ambiente complesso, con un elevato grado di ambiguità e/o incertezza e richiede che l’organizzazione percepisca il Program Management come un metodo di esecuzione della strategia e come un mezzo per apportare cambiamenti.

In questo modello, il Program Management è al centro del processo di gestione delle decisioni strategiche e viene utilizzato per gestire il cambiamento organizzativo, con l’obiettivo di creare valore nel breve termine per gli sponsor, nel medio termine per i destinatari del cambiamento e nel a lungo termine per l’organizzazione.

Potremmo quindi vedere un programma come una raccolta di azioni di cambiamento raggruppate insieme per realizzare valore. Il raggruppamento deve essere mirato ed è importante identificare tutte le interdipendenze tra le azioni. Per azioni si intendono progetti o attività o operazioni di transizione che, una volta integrati, apportano benefici (ove possibile in modo ritmato) abilitando capacità.

Il disegno che segue

contestualizza il rapporto tra incertezza e ambiguità in relazione ai quattro domini che ne conseguono:

- Bassa incertezza: dominio delle operations

- Alta incertezza: dominio del change management

- Bassa ambiguità: dominio delle esecuzioni

- Alta ambiguità: dominio delle decisioni

In particolare mostra come il Project Management appartiene al dominio dove l’ambiguità è bassa ma l’incertezza è alta: un progetto può quindi essere visto come un processo di cambiamento con un obiettivo chiaro ma la cui esecuzione è incerta.

Il Program Management invece copre un’area decisamente più ampia, entrando sia nel dominio di analisi strategiche ad alta ambiguità sia nel dominio delle acque calme delle operations, durante il quale (dopo che i progetti hanno prodotto risultati) i risultati vengono misurati e si realizzano i benefici.

Notare come all'aumentare di ambiguità e incertezza si passa dal dominio dei progetti (più o meno agili e/o complessi) al dominio dei programmi.

È ovvio che il trasferimento degli strumenti e delle tecniche del Project Management al Program Management non funzionerà: le tecniche di Project Management tradizionali (più basate su un approccio di comando e controllo) non riescono a rispondere alle situazioni emergenti e all’ambiguità, e mancano dell’integrazione tra l’intento strategico e i risultati generati dal Program Management.

Il Program Management si basa sul concetto di un insieme di decisioni integrate e che si rafforzano reciprocamente a formare un insieme coerente volto a creare valore per gli stakeholder, e si inserisce in un ambiente evolutivo e adattivo, in cui i team devono essere visti come un sistema integrato in evoluzione, adottando un approccio basato sulla semplicità per migliorare la risposta al cambiamento.

Al contrario, il Project Management copre un’area che richiede un’elevata prevedibilità ma soprattutto un project manager (contrariamente a un program manager) non è responsabile della fornitura di benefici.

> Un progetto fornisce output: un singolo prodotto o servizio.

> Un programma fornisce risultati: un insieme di capacità che insieme producono benefici che a loro volta porteranno alla realizzazione di valore.

> Il Project Management è basato sulle prestazioni.

> La gestione del programma è basata sull'apprendimento.

> Il Project Manager si limita alla gestione delle attività che si svolgono tra l'inizio e la chiusura.

> Il Program Manager è lo sponsor dei progetti che fanno parte del programma e sovrintende al ruolo dei project manager, avendo autorità su di essi.

Anche programmi e progetti potrebbero essere confrontati e classificati in base a queste due caratteristiche (perdonatemi se mi ripeto nelle definizioni):

- Incertezza: mancanza di informazioni verificabili, da cui deriva la difficoltà nel prevedere un rapporto causa-effetto; ciò significa una mancanza di prevedibilità dei risultati, anche quando gli obiettivi sono chiaramente definiti.

- Ambiguità: mancata convergenza degli obiettivi; ciò deriva da una serie di possibili soluzioni e da stakeholder senza un chiaro accordo sugli obiettivi, che possono cambiare nel tempo.

Sia l’incertezza che l’ambiguità influenzano i metodi di gestione, poiché al giorno d’oggi il contesto delle organizzazioni è sia complesso che turbolento, e

> complessità porta ambiguità

> turbolenza aumenta l’incertezza

L'immagine qui sotto [adattata da: Michel Thiry — “Program Management” (edizione 2015)]

analogamne alla parte alta del disegno precedente, mostra come il Program Management  (ombreggiato in grigio) si colloca principalmente nell'ambito del CHANGE MANAGEMENT (che copre sia le azioni DECISIONALI che quelle ESECUTIVE) e include elementi di operazioni in corso. Ciò è reso evidente dalla CATENA DEL VALORE (in rosso), composta da quattro diverse fasi:

(A) Creazione di Valore: definizione della strategia aziendale (processo decisionale e problem solving)

(B) Scelta tra le azioni proposte

(C) Consegna dei Risultati (output del progetto = prodotti e/o servizi)

(D) Realizzazione del Valore e dei Benefici >> Questa fase è ciò che effettivamente differenzia la maggior parte dei programmi dai progetti.

Per chi preferisce i diagrammi fatti amano e in italiano:

Ripetiamolo quindi: i progetti appartengono all'intersezione tra il dominio dei cambiamenti e quello delle esecuzioni, quando cominciamo ad addentrarci anche in analisi di business (decisioni sui cambiamenti per adottare una strategia aziendale) e nelle operazioni di routine, allora possiamo parlare di programmi.

La catena del valore parte quindi dalla creazione della strategia (A) passando per la scelta dei progetti da attuare per implementare la strategia scelta (B); a questo punto i progetti vengono eseguiti (C) e un output (il deliverable: un prodotto o un servizio) viene consegnato alle operation (D) dove si realizza il valore che l’output del progetto è destinato a dare.

I programmi non possono essere gestiti con un approccio di delivery, simile a quello del project management, ma con un approccio integrato.

La governance del programma è regolata dalle seguenti tre responsabilità:

- mantenere la direzione, grazie ad una visione, missione e strategia chiare

- mettere in atto le strutture necessarie per garantire il successo

- assicurarsi che gli obiettivi e i benefici dichiarati siano raggiunti

Ciò è possibile solo attraverso un processo collaborativo che favorisca un rapporto costruttivo piuttosto che direttivo, da qui la necessità di una forte collaborazione tra il team del programma e l'azienda per fornire capacità operative.

EDIT 2024

Per quanto il concetto di catena del valore secondo me rimane ancora valida, a distanza di anni, grazie alla conoscenza di Adrian Dooley e del framework Praxis, concordo in una distinzione più sfumata tra progetti e programmi, come in figura.