Building Transformation Capability: Expanding the Role of Project Management

Qui di seguito una rielaborazione del mio intervento al PMI® Global Summit Series (Lisbona - 29 aprile 2026), evento internazionale organizzato dal Project Management Institute (PMI), focalizzato sul project management, sulle nuove metodologie di lavoro e sulle competenze professionali.

Il mio obiettivo è stato quello di rendere i partecipanti in grado di percepire la trasformazione come una capacità organizzativa che va oltre i singoli progetti e programmi e di contestualizzare la gestione dei progetti in un quadro più ampio e interdisciplinare, incentrato sul valore e sui benefici.

Il mio speech, inoltre, ha messo in evidenza la connessione del framework presentato con l’invito del PMI al M.O.R.E.

Manage Perceptions (gestire le percezioni)

Own Success (responsabilità totale)

Relentlessly Reassess (rivalutare costantemente)

Expand Perspective (ampliare la prospettiva)


Business Transformation

Il concetto da cui parto è naturalmente quello di Business Transformation: non esiste una definizione unica e universalmente accettata di Business Transformation ma, nel contesto del mio intervento, la considero pienamente equivalente a quella di trasformazione organizzativa.

Forse una metafora può essere più potente di una definizione puramente teorica. Non a caso descrivo spesso la trasformazione come l’attraversamento di un guado: si lascia una configurazione stabile e familiare, una riva dove ruoli, processi e aspettative sono chiari, e si entra in acque in movimento, dove l’ambiente diventa fluido e meno prevedibile. La riva opposta non può essere progettata del tutto in anticipo: deve essere raggiunta mediante un attraversamento progressivo.

In queste condizioni, la strategia diventa più importante dell’esecuzione lineare. E il vero rischio non è nell’acqua stessa, ma nel presumere che la logica della riva che si è abbandonata sia ancora valida.

Questo potrebbe suonare familiare: molti potrebbero riconoscere elementi del pensiero adattivo o agile, un percorso che si pianifica e si attua per incrementi.

È vero, ma… l’agilità, intesa come approccio al progetto, opera principalmente a livello di esecuzione, mentre la trasformazione richiede qualcosa di più ampio, una coerenza architetturale sull’intero sistema.

La Business Transformation (BT), quindi, è «un processo sistemico di cambiamento organizzativo, che può impattare strutture, processi, strumenti e persone all’interno di un’organizzazione»: questa la definizione preferita.

Il termine Business si riferisce a un’organizzazione, non necessariamente privata o a scopo di lucro in senso più ampio, bensì qualsiasi sistema, comunità, istituzione o entità. Dal nostro punto di vista, quindi, Business Transformation è essenzialmente la metamorfosi di un organismo.

La Business Transformation implica un approccio sistemico e coinvolge sempre almeno alcuni dei seguenti livelli:

• Individuo

• Gruppo

• Organizzazione

• Ecosistema

La Business Transformation può essere:

• Consapevole o inconsapevole

• Intenzionale o imposta

• Radicale o incrementale

• …

Nelle organizzazioni siamo molto bravi a costruire competenze all’interno delle discipline. Project Management, Business Analysis, Change Management: ciascuna approfondisce la propria area tematica. Ma la trasformazione non avviene all’interno di una singola disciplina. Richiede connessione tra funzioni, ruoli e prospettive.

Come ci ricorda il filosofo Edgar Morin, la conoscenza non dovrebbe rimanere separata, va connessa.

Ed è qui che emerge il vero valore, quando prospettive diverse vengono integrate e lavorano insieme.

Quindi, se le discipline da sole non bastano, di cosa abbiamo bisogno? Necessitiamo di struttura, di un modo per integrare diverse capacità in modo coerente, quindi di architettura. L’architettura è ciò che può trasformare la competenza in azione coordinata. Ed è esattamente l’idea alla base del “framework” che condivido.

BTCF®

Per evitare di rimanere sul piano concettuale, abbiamo strutturato questa prospettiva in un framework formale, il Business Transformation Capability Framework, sviluppato attraverso anni di pratica sul campo.

Il suo scopo non è sostituire il project management, ma collocarlo all’interno di una più ampia architettura di capacità di trasformazione. Un’architettura che integra discipline e aree di impatto.

CASE STUDY

Per maggiore chiarezza, introduco brevemente il contesto di un importante case study.

GAB Tamagnini è un’azienda italiana con una lunga tradizione nella tecnologia retail. Progetta ed eroga servizi e soluzioni per la grande distribuzione – tra cui, ad esempio, sistemi di self-checkout.

Insieme, abbiamo stabilito un impegno condiviso per avviare una trasformazione organizzativa strutturata: un patto fra l’azienda che deve attraversare il guado (la Transforming Organization) e l’azienda responsabile di renderla capace di portare a termine questo attraversamento (la Consulting Organization).

Abbiamo identificato quattro Transformation Stream, ognuno definito dal proprio Goal, dai Need e dai Benefit attesi.

Questi stream sono stati poi integrati in un’unica costellazione di trasformazione – la Capability Matrix – che guida la progettazione delle azioni.

Alla fine, la fase ATTEST ha fornito una revisione strutturata del valore generato in ciascuno Stream.

Tale lavoro è stato ulteriormente sviluppato in collaborazione con l’Università di TrentoDipartimento di Ingegneria Industriale, attraverso la tesi sperimentale di Laurea Magistrale in Management and Industrial System Engineering, scritta dalla dott. Federica Baga e dal titolo “Analysis and Application of the Business Transformation Capability Framework: the Gab Tamagnini Case”.

Nel framework, la trasformazione è osservata attraverso cinque aree di impatto, ovvero dimensioni in cui la trasformazione genera impatto:

  1. Strategy

  2. Stakeholder

  3. Delivery

  4. Process

  5. People




E dove c’è impatto, diventa necessario intervenire; ecco perché possono essere definite sia come aree di impatto che come aree di intervento.

Ogni trasformazione tocca più aree, ma non sempre tutte e non con la stessa intensità.

Nella pratica, osserviamo costantemente nove discipline fondamentali interagire in ogni trasformazione significativa. Ciascuna disciplina porta profondità e rigore. E anche metodi, strumenti, spesso determinando un’identità professionale, che rischia però di diventare una gabbia, se la profondità impedisce l’interdisciplinarietà.

La fragilità della trasformazione non emerge dalla mancanza di competenze. Emerge quando la loro interazione rimane implicita.

La sfida non è la competenza. È l’integrazione architetturale.

La capacità di trasformazione emerge dunque dall’intersezione strutturata di due dimensioni: discipline e aree di impatto.

Project Management

Enterprise Management

Agile Mindset

Knowledge Management

Business Analysis

Risk Management

Innovation Management

Change Management

Power Skills

CApability matrix

La Capability Matrix rende esplicita questa struttura: ogni cella rappresenta una possibile area di focalizzazione definita all’intersezione di una specifica disciplina e di una specifica area di impatto.

Queste aree vengono poi selezionate e connesse per formare una costellazione di trasformazione su misura.

E questa personalizzazione è intrinsecamente selettiva: include tutto ciò che è necessario, e solo ciò che è necessario.

Non si tratta di aggiungere di più, ma di essere più precisi.

È qui che la trasformazione diventa operativa. L’architettura sostituisce l’improvvisazione.

il ciclo del valore

Il Value Life Cycle garantisce che la trasformazione rimanga ancorata al valore.

Inizia con un Goal, l’intento qualitativo della trasformazione.

Dal Goal emergono specifici Need, espressi dai diversi Stakeholder.

Questi Need vengono tradotti in Objective, misurabili e temporizzati.

Gli Objective si realizzano attraverso Deliverable. Ma solo quando i Deliverable generano valore reale si parla di Benefit. I Deliverable sono necessari. I Benefit sono decisivi. Molte organizzazioni gestiscono rigorosamente i Deliverable e in modo meno strutturato i Benefit. Ed è qui che la tracciabilità diventa critica, collegando intenzione, esecuzione e valore nel tempo.

I Cinque STEP

1       EXPLORE è il punto di ingresso strategico della trasformazione. È qui che inizia la costruzione di senso.

Adottiamo un approccio complesso, andando oltre una visione puramente meccanicistica dell’organizzazione.

E lavoriamo con una modalità che chiamiamo spiralyzing, ovvero un’esplorazione progressiva che connette prospettive, raffina la comprensione e costruisce significato condiviso.

• Definiamo il Goal della trasformazione: l’orizzonte qualitativo che dà direzione.

• Elicitiamo i Need degli Stakeholder, rendendo esplicite aspettative e tensioni.

• Stabiliamo un linguaggio condiviso per evitare (o almeno ridurre) ambiguità.

E, cosa importante, anticipiamo i Benefit attesi non come un ripensamento, ma come motori della trasformazione.

2       MAP rende esplicita l’architettura.

A partire dal Goal e dai Need identificati, determiniamo quali aree di impatto sono coinvolte.

Selezioniamo quindi le discipline rilevanti – attingendo a un corpus strutturato di conoscenze.

All’intersezione tra discipline e aree di impatto, emergono specifiche aree di focalizzazione.

Questi sono i punti in cui lo sforzo di trasformazione deve concentrarsi.

Insieme, formano la Costellazione.

Non una timeline. Ma una mappa di significato.


3       DESIGN traduce l’architettura in azione.

La Costellazione viene strutturata in azioni coerenti.

Descriviamo i Deliverable – non solo cosa viene prodotto, ma perché è rilevante con una forte attenzione ai criteri di accettazione, distinguendo tra deliverable abilitanti e principali.

Durante questa fase, garantiamo la tracciabilità della trasformazione – collegando Goal, Need, Objective, Deliverable e i Benefit attesi.


4       TRANSFORM è… la vita reale. È l’attraversamento, è il passaggio del guado.

Gli stream si attivano e si sviluppano nell’organizzazione.

Le discipline interagiscono dinamicamente, non più in astratto, ma nella pratica.

L’allineamento tra le aree di impatto viene monitorato continuamente.

L’adattamento è previsto, ma la coerenza sistemica deve essere preservata.

Non si tratta di monitoraggio e controllo: ancora una volta, si tratta di coerenza sistemica.


5       ATTEST è il momento in cui il valore viene confermato.

I Deliverable vengono validati, non solo completati, ma accettati.

E i Benefit vengono presi esplicitamente in carico da Benefit Owner designati.

Si tratta di responsabilità: è adesso che lo sforzo temporaneo diventa capacità duratura. Dove la trasformazione non finisce… ma permane.

 

PMI M.O.R.E.

Ciò che ho presentato al Global Summit Series di Lisbona è stato sviluppato in modo indipendente, eppure confluisce in modo naturale con l’invito del Project Management Institute al M.O.R.E.

Questa convergenza non è casuale, in quanto riflette un’evoluzione più ampia nella nostra professione.

KEYPOiNT

I keypoint con cui chiudo l’intervento sono 4:

• La trasformazione riguarda la riconfigurazione sistemica
• La coerenza si ottiene attraverso l’architettura
• La trasformazione richiede interdisciplinarità e transdisciplinarità
• Il valore deve essere tracciabile dall’intenzione alla capacità duratura

La trasformazione non è qualcosa che consegniamo: è qualcosa che costruiamo – come capacità – all’interno dell’organizzazione.

E forse, è così che il ruolo del project management si espande.

 

Stefano Setti

CEO&Founder di BluPeak Consulting


BLUPEAK - Business is culture