INSIGHT 009
Pubblicato il 12 Agosto 2026 da Lorenzo Riccioli
Comprendere i sistemi.
Coordinare il cambiamento.
Completare un progetto non significa aver creato valore
Tempi, budget e deliverable raccontano se abbiamo eseguito il progetto. Gli outcome raccontano se ne è valsa la pena.
Categoria: Insights
Tempo di lettura: 7 minuti
Il progetto è finito. Ma ha funzionato?
La milestone finale è stata raggiunta.
Il deliverable è stato consegnato.
Le attività previste sono state completate.
Il progetto può essere chiuso.
A prima vista sembrerebbe il momento ideale per dichiararne il successo.
Ma manca ancora una domanda.
Che cosa è realmente cambiato grazie a questo progetto?
È una domanda semplice, ma modifica profondamente la prospettiva.
Perché completare un progetto e generare valore non sono necessariamente la stessa cosa.
Possiamo realizzare perfettamente ciò che era stato richiesto e scoprire, qualche mese dopo, che il problema originario è ancora presente.
Possiamo introdurre una nuova tecnologia che nessuno utilizza realmente.
Possiamo ridisegnare un processo che continua a generare le stesse inefficienze.
Possiamo consegnare nei tempi e nel budget e non ottenere il beneficio che aveva giustificato l’investimento.
Il progetto è terminato.
Ma il cambiamento?
Activity, output e outcome raccontano cose diverse
Una distinzione utile consiste nel separare tre livelli.
Activity.
Ciò che facciamo.
Workshop, analisi, configurazioni, incontri, sviluppo, formazione.
Output.
Ciò che produciamo.
Un sistema.
Una procedura.
Un nuovo processo.
Una dashboard.
Un impianto.
Un modello organizzativo.
Outcome.
Ciò che cambia grazie a quello che abbiamo prodotto.
Riduzione dei tempi.
Migliore qualità.
Aumento della produttività.
Maggiore capacità decisionale.
Riduzione del rischio.
Migliore esperienza del cliente.
Incremento della marginalità.
Questi livelli sono collegati.
Ma non sono equivalenti.
Ed è proprio nella distanza tra output e outcome che molti progetti apparentemente riusciti iniziano a mostrare i propri limiti.
È più facile misurare ciò che produciamo
Gli output hanno un grande vantaggio.
Sono visibili.
Possiamo verificare se un software è stato installato.
Possiamo controllare se una procedura è stata pubblicata.
Possiamo contare quante persone hanno partecipato alla formazione.
Possiamo registrare la conclusione di una milestone.
Gli outcome sono più difficili.
Richiedono tempo.
Richiedono dati.
Spesso dipendono anche da fattori che si trovano fuori dal controllo diretto del Project Manager.
Per questo le organizzazioni tendono naturalmente a concentrarsi su ciò che è più semplice misurare.
Ma ciò che è più semplice da misurare non è necessariamente ciò che conta di più.
Un software installato non è ancora trasformazione digitale
Immaginiamo un progetto di digitalizzazione.
Il nuovo sistema viene configurato.
I test vengono completati.
Gli utenti ricevono la formazione.
La piattaforma entra in produzione.
Tecnicamente il progetto potrebbe essere considerato concluso.
Ma cosa succede dopo?
Le persone utilizzano realmente il nuovo sistema?
Oppure continuano a lavorare attraverso file Excel paralleli?
Il processo è diventato più veloce?
Gli errori sono diminuiti?
Le informazioni sono più affidabili?
Le decisioni vengono prese meglio?
Il tempo liberato viene utilizzato per attività a maggior valore?
Queste domande non riguardano più semplicemente il deliverable.
Riguardano il beneficio.
Il rischio di confondere il progetto con il suo scopo
Ogni progetto nasce perché esiste una ragione per cambiare qualcosa.
Aumentare capacità.
Ridurre costi.
Risolvere un problema.
Cogliere un’opportunità.
Ridurre un rischio.
Migliorare l’esperienza di un cliente.
Adeguarsi a una nuova condizione.
Con il passare del tempo, però, può accadere qualcosa di interessante.
L’organizzazione inizia a concentrarsi sul progetto stesso.
Le scadenze.
Le attività.
Le riunioni.
Il budget.
I deliverable.
Progressivamente il mezzo rischia di diventare il fine.
La domanda iniziale — perché stiamo facendo questo progetto? — diventa meno presente.
Eppure dovrebbe essere proprio quella domanda a guidare molte delle decisioni successive.
Un progetto può essere efficiente e non essere efficace
Possiamo fare molto bene qualcosa che non produce abbastanza valore.
È una distinzione importante.
L’efficienza riguarda il modo in cui utilizziamo le risorse.
L’efficacia riguarda la capacità di ottenere il risultato desiderato.
Un progetto può essere gestito in maniera estremamente efficiente e generare un outcome modesto.
Oppure può incontrare difficoltà durante l’esecuzione ma produrre un beneficio organizzativo molto rilevante.
Questo non significa che tempi e costi non siano importanti.
Significa inserirli in una prospettiva più ampia.
La domanda non è soltanto:
“Quanto bene abbiamo eseguito il progetto?”
Ma:
“Quanto valore ha prodotto ciò che abbiamo realizzato?”
Il valore dovrebbe essere discusso prima, non soltanto misurato dopo
Se vogliamo misurare il valore alla fine del progetto, dobbiamo averlo definito prima.
Quale problema stiamo cercando di risolvere?
Quale risultato ci aspettiamo?
Come capiremo se il cambiamento sta funzionando?
Qual è la situazione di partenza?
Quali indicatori possiamo osservare?
Quando sarà realistico misurarli?
Chi sarà responsabile del beneficio dopo la chiusura del progetto?
Sono domande che dovrebbero entrare molto presto nella conversazione.
Perché un beneficio definito genericamente all’inizio sarà estremamente difficile da misurare alla fine.
Non tutto il valore appare immediatamente
Esiste però un’altra complessità.
Gli outcome non rispettano necessariamente la data di chiusura del progetto.
Una soluzione può essere consegnata oggi e produrre benefici nei mesi successivi.
Un nuovo processo può richiedere tempo prima di stabilizzarsi.
Una trasformazione organizzativa può attraversare una fase iniziale di riduzione della produttività prima di generare miglioramenti.
Una formazione può modificare comportamenti progressivamente.
Questo significa che la chiusura amministrativa del progetto e la realizzazione del beneficio possono avvenire in momenti differenti.
Ed è proprio per questo che la responsabilità sul valore non dovrebbe scomparire quando termina il project plan.
Chi possiede il beneficio?
Questa domanda è particolarmente interessante.
Il Project Manager può essere responsabile della realizzazione del progetto.
Ma chi è responsabile dell’outcome?
Lo sponsor?
Il business owner?
Una funzione?
La direzione?
Se nessuno possiede chiaramente il beneficio, può verificarsi una situazione paradossale.
Il progetto viene consegnato.
Il team viene riallocato.
La governance si scioglie.
E nessuno continua realmente a osservare se il risultato atteso si sta concretizzando.
Abbiamo quindi governato attentamente la realizzazione del mezzo e molto meno la realizzazione dello scopo.
Dall’output al value delivery
Questa prospettiva modifica anche il ruolo del Project Management.
Non significa attribuire al Project Manager la responsabilità di ogni risultato futuro dell’organizzazione.
Molti outcome dipendono da fattori esterni al suo controllo.
Significa però mantenere visibile il collegamento tra progetto e valore.
Il Project Manager può aiutare l’organizzazione a chiedersi:
quale beneficio stiamo cercando?
Quali assunzioni stiamo facendo?
Come lo misureremo?
Quali stakeholder devono adottare il cambiamento?
Quali rischi potrebbero impedire la realizzazione del beneficio?
Quale governance continuerà dopo la consegna?
Il progetto diventa così parte di una catena più ampia.
Strategia → investimento → progetto → output → adozione → outcome → valore.
Anche interrompere un progetto può creare valore
Esiste infine una conseguenza meno intuitiva.
Se il valore è il vero punto di riferimento, completare ogni progetto non è necessariamente l’obiettivo.
Il contesto può cambiare.
Un’assunzione può rivelarsi sbagliata.
Una tecnologia può diventare obsoleta.
Il beneficio previsto può ridursi.
Può emergere un’alternativa migliore.
In questi casi continuare semplicemente perché abbiamo già investito tempo e denaro può diventare una decisione molto costosa.
Un’organizzazione orientata al valore dovrebbe essere capace anche di rivalutare.
Ridimensionare.
Reindirizzare.
E, quando necessario, interrompere.
Perché il successo non consiste nel completare qualsiasi progetto iniziato.
Consiste nell’utilizzare risorse limitate per generare il maggior valore possibile.
L’Insight
Un progetto non dovrebbe essere considerato un successo soltanto perché è stato completato.
La consegna rappresenta un passaggio fondamentale.
Ma il motivo per cui l’organizzazione ha investito nel progetto si trova oltre il deliverable.
Si trova nel cambiamento che quel deliverable riesce a generare.
Gli output dimostrano che abbiamo realizzato qualcosa. Gli outcome ci aiutano a capire se quel qualcosa ha prodotto valore.
La maturità del Project Management passa anche da questo cambio di prospettiva:
dal completamento delle attività alla realizzazione dei benefici.
Project Thinking Lens
Domanda
Come capire se un progetto ha realmente avuto successo?
Pattern osservato
Tempi, costi, milestone e deliverable rendono facilmente osservabile la performance di execution, mentre benefici, adozione e outcome possono emergere soltanto dopo la consegna.
Insight
Il successo del progetto e la realizzazione del valore devono essere collegati, ma non confusi.
Un’organizzazione matura non misura soltanto se il progetto è stato completato. Continua a osservare se il cambiamento per cui era stato avviato si è realmente verificato.
Lorenzo Riccioli
Founder — Project Thinking Lab
Comprendere i sistemi. Coordinare il cambiamento.
PTL-I-009
Tag: Benefits Management, Benefits Realization, Change Management, Decision Making, Governance, Maturità Organizzativa, Outcome, outcome e, Output, Project Governance, Project Management, Project Portfolio Management, Project Thinking Lab Breadcrumb: Output, Project Value, Stakeholder Management, Strategia, Value Delivery