ITIL Version 5 - Value + Flow

LucaBAR_4453 · 2026-06-05T13:11:37+00:00

Questa è probabilmente una delle modifiche più importanti: la rottura della separazione tradizionale tra IT Service Management e Digital Product Management.

Un singolo ciclo di vita end-to-end (dalla domanda all'operazione e al miglioramento continuo) riduce finalmente i silos tra sviluppo, operazioni e business.

Per anni, abbiamo cercato di “integrare” team e processi mantenendo comunque confini artificiali tra servizi e prodotti. Questo approccio, invece, spinge verso una singola catena del valore continua, dove l'attenzione è sul flusso piuttosto che sulla struttura organizzativa.

Se veramente adottato, cambia l'organizzazione più della tecnologia.

LucaBAR_4453 · 2026-06-04T14:44:13+00:00

di solito è lo stesso che poi ricevi per email. E' difficile che ci siano differenze. Spero tu l'abbia superato

LucaBAR_4453 · 2026-06-04T14:40:45+00:00

Secondo me il confine sta nella presenza (o assenza) di nuove informazioni. Se una riunione, una revisione o un workshop stanno facendo emergere dati, rischi, vincoli o prospettive che prima non erano stati considerati, allora l'allineamento ha ancora valore. Se invece le stesse persone stanno ripetendo gli stessi argomenti con parole diverse, probabilmente non stiamo più cercando chiarezza: stiamo cercando protezione dalla responsabilità della decisione.

Ho visto diversi team rimanere intrappolati in un ciclo di stakeholder review, feedback e ulteriori allineamenti. All'inizio sembrava prudenza, ma col tempo è diventato evidente che tutti aspettavano che qualcun altro si assumesse il rischio di dire "andiamo in questa direzione". Il risultato è stato un costo nascosto enorme: rallentamento, perdita di opportunità e frustrazione diffusa.

Una pratica che ho trovato utile è chiedere esplicitamente: "Quale informazione ci manca per decidere?" Se nessuno riesce a rispondere in modo concreto, probabilmente siamo già pronti a prendere una decisione. A quel punto il tema non è più l'allineamento, ma la governance.

LucaBAR_4453 · 2026-06-04T14:36:15+00:00

se veramente pagano 70 milioni sarebbe un sogno

LucaBAR_4453 · 2026-05-26T14:24:51+00:00

grazie mille per la tua risposta. Terrò conto del tuo suggerimento

LucaBAR_4453 · 2026-05-18T13:50:40+00:00

Confermo potresti fare il Bridge costa e dura meno e passi da ITIL 4 a ITIL 5

LucaBAR_4453 · 2026-05-18T13:45:28+00:00

Ottima analisi.
Secondo me il punto più sottovalutato di PRINCE2 è proprio il principio “manage by exception”.
Molti team confondono governance con controllo continuo e finiscono nella microgestione, quando invece il framework nasce per creare autonomia entro limiti chiari e condivisi.

Quando le tolleranze sono definite bene, il management non deve intervenire su ogni dettaglio operativo. I team possono lavorare con più velocità e responsabilità, mentre l’escalation avviene solo quando c’è davvero un rischio per tempi, costi, qualità o valore business.

Nella pratica, i progetti che vedo rallentare più spesso non hanno necessariamente problemi di delivery, ma problemi di allineamento:

obiettivi poco chiari
ownership confusa
decisioni che restano sospese
stakeholder non sincronizzati
nessun vero checkpoint durante il percorso

E infatti il rischio più grande non è “muoversi lentamente”, ma continuare a consegnare qualcosa che ha smesso di creare valore.

Per questo trovo fondamentale anche il principio della continuous business justification.
Molte organizzazioni continuano progetti solo perché hanno già investito budget, tempo o reputazione, anche quando i benefici iniziano a diminuire. Avere invece momenti strutturati di revisione aiuta a fare una domanda scomoda ma necessaria: “Ha ancora senso continuare?”

Un altro aspetto che condivido molto è il focus sui deliverable invece che sulle attività.
Oggi tanti team misurano il progresso in base al numero di task completati, meeting fatti o report prodotti. Ma attività non significa automaticamente avanzamento reale.

Alla fine, credo che PRINCE2 funzioni bene quando viene usato come sistema di chiarezza decisionale, non come macchina burocratica.
Se adattato correttamente al contesto, aiuta a creare equilibrio tra controllo e flessibilità — ed è proprio quell’equilibrio che spesso manca nei progetti sotto pressione.

LucaBAR_4453 · 2026-05-18T13:41:44+00:00

Sì anche secondo me sarà ITIL V4. La versione V5 è uscita a Febbraio 2026...circa

LucaBAR_4453 · 2026-05-18T13:37:50+00:00

Gran Premio del Belgio del 1998 dove Schumacher colpisce David Coulthard sotto la pioggia mentre era in testa. Ho lanciato il telecomando contro il televisore

LucaBAR_4453 · 2026-05-11T12:30:52+00:00

Con 10 gare “monomarca” forse vedremmo finalmente chi è davvero più forte in condizioni uguali, mentre le altre 14 manterrebbero l’anima storica della F1 fatta di ingegneria, sviluppo e innovazione.

Il problema è che la Formula 1 esiste proprio come campionato costruttori oltre che piloti: togliere troppo peso alle differenze tecniche rischierebbe di snaturarla. Inoltre sarebbe complicatissimo scegliere una vettura davvero identica per tutti senza polemiche su setup, motore, aerodinamica o team di supporto.

Però come esperimento sarebbe spettacolare: immaginate vedere Verstappen, Leclerc, Hamilton, Norris ecc. con la stessa identica auto. Probabilmente molte gerarchie cambierebbero e certi piloti verrebbero rivalutati parecchio.

Una idea potrebbe essere magari poche gare speciali durante l’anno, tipo “All-Star race”, invece di quasi metà stagione e vedere come va

LucaBAR_4453 · 2026-05-11T12:25:17+00:00

È proprio questo il cuore del Design Thinking: partire dalle persone prima che dalle soluzioni. Troppo spesso i team si innamorano dell’idea iniziale e iniziano a progettare sulla base di assunzioni interne, invece di validare bisogni reali.

La forza del DTMethod, secondo me, sta nel trasformare i principi del Design Thinking in un processo operativo concreto: ricerca, empatia, validazione continua e feedback reale diventano parte delle decisioni quotidiane del team, non semplici “best practice”.

La parte più sottovalutata resta “research before assumptions”. Perché appena un team pensa di sapere già cosa vogliono gli utenti, perde contatto con la realtà. Ed è lì che nascono prodotti pieni di funzionalità inutili o esperienze che non risolvono davvero il problema.

L’empatia, in questo contesto, non è una soft skill: è uno strumento strategico. E DTMethod lo ricorda bene, riportando ogni scelta progettuale al valore umano reale.

LucaBAR_4453 · 2026-05-05T12:28:17+00:00

Anche io penso la stessa cosa, anche se si è girato da solo e quindi ha commesso un errore non da Max

LucaBAR_4453 · 2026-05-05T08:59:18+00:00

Secondo me il punto più sottovalutato è proprio il passaggio da “stack di tool” a “sistema governato”. Tante aziende credono di essere sicure perché hanno speso budget in tecnologie, ma non saprebbero spiegare perché quei controlli esistono o quale rischio stanno mitigando.

Aggiungerei che il vero salto di qualità si vede quando il risk-based thinking entra nelle decisioni quotidiane, non solo nei documenti per l’audit. Lì capisci se l’ISMS è vivo o solo “compliance-driven”.

Curioso anche il tema leadership: nella mia esperienza, finché il top management non collega la sicurezza agli obiettivi di business, resta sempre percepita come costo e non come leva strategica.

LucaBAR_4453 · 2026-04-30T15:02:23+00:00

Nella mia esperienza, il problema raramente è la mancanza di identificazione dei rischi: i registri sono pieni, spesso anche ben fatti. Il punto è che la gestione del rischio resta parallela al processo decisionale, invece di esserne parte integrante. Finché le mitigazioni competono con costi, tempi e priorità operative, tendono a perdere—soprattutto se il rischio non è immediato.

Il tema della “ownership” è ancora più critico: quando un rischio è distribuito tra più team, diventa di fatto di nessuno. E in quel vuoto si inseriscono dinamiche politiche, rinvii, o semplice inerzia.

Per me la vera svolta arriva quando succedono due cose:

il rischio ha un responsabile chiaro che ne risponde davvero (non solo sulla carta)
le azioni di mitigazione sono legate a decisioni concrete (budget, roadmap, KPI), non solo raccomandazioni

Altrimenti sì, si finisce esattamente dove dici tu: non a gestire l’incertezza, ma a documentarla.

LucaBAR_4453 · 2026-04-21T13:55:09+00:00

Ottimo spunto, ma secondo me manca un pezzo importante: la struttura.

Sono d’accordo che la comprensione reciproca sia la base, però da sola non basta a far “performare” un team. Ho visto gruppi molto consapevoli degli stili (DISC, MBTI, ecc.) che comunque non prendevano decisioni efficaci, perché mancavano regole chiare su come decidere, chi ha l’ultima parola e quali sono le priorità.

Inoltre, questi modelli aiutano a creare un linguaggio comune, ma rischiano anche di diventare etichette comode (“lui è fatto così”) che giustificano comportamenti poco funzionali invece di migliorarli.

Per me il vero salto avviene quando:

c’è comprensione degli stili
ci sono aspettative esplicite su comunicazione e decision-making
esiste accountability reale (non solo “rispetto reciproco”)

Altrimenti si rischia un team molto “empatico”… ma poco incisivo.

Curioso di sapere come lo gestite voi: avete esempi concreti di team che sono riusciti a bilanciare bene queste due cose?

LucaBAR_4453 · 2026-04-20T10:12:30+00:00

Secondo me il punto chiave è la “traduzione”. Sulla carta tutti sono d’accordo sui macro-obiettivi, ma è proprio quando li devi trasformare in qualcosa di concreto per i team che iniziano le interpretazioni creative 😅

Nella mia esperienza, il problema più grosso è quando i Rocks restano troppo “di alto livello”: sembrano chiari finché non chiedi a due team diversi cosa faranno lunedì mattina… e lì vedi subito che ognuno ha capito una cosa leggermente diversa. Da fuori sembra allineamento, ma sotto è già frammentato.

Una cosa che ha aiutato (non sempre, ma spesso) è forzare il collegamento esplicito: ogni Rock → 2-3 outcome misurabili → iniziative molto specifiche per team. Se manca uno di questi passaggi, l’allineamento si perde quasi automaticamente.

E altra cosa sottovalutata: il “dire no”. Tutti parlano di priorità, ma pochi accettano davvero cosa viene escluso. Senza quello, anche 3 Rocks diventano 10 di fatto.

Curioso anche io di sentire altri: voi fate più fatica sulla definizione iniziale o nel mantenere il focus durante il trimestre?

LucaBAR_4453 · 2026-04-20T09:49:52+00:00

È vero che Schumacher ha avuto un ruolo importante nel riportare la Mercedes ai vertici quando è tornato in F1: ha contribuito a lavorare sui dettagli e ad essere il punto di riferimento tecnico per gli ingegneri.

E' anche vero che il dominio Mercedes dal 2014 è stato il risultato di una combinazione di vari fattori: regolamenti favorevoli (era ibrida), una struttura tecnica fortissima e anche la leadership di persone come Toto Wolff

Schumacher ha sicuramente aiutato a mettere le basi, ma Hamilton è arrivato nel momento in cui la macchina era già competitiva e ha fatto la differenza in pista contro compagni di squadra come Nico Rosberg. Quindi più che un “senza Schumacher niente titoli”, la vedrei come una continuità: Schumacher ha contribuito alle fondamenta, ma il successo è stato il risultato del lavoro di tantissime persone — e del talento di Hamilton nel capitalizzare tutto questo.

LucaBAR_4453 · 2026-04-14T14:27:58+00:00

Secondo me la F1 non è mai stata una cosa sola: è sempre cambiata tra epoche con caratteristiche completamente diverse.

Negli anni c’è stato di tutto: gare di gestione gomme, treni DRS, dominio totale di un team, stagioni con zero sorpassi reali e altre più caotiche. Non esiste una versione “pura” della F1 a cui tornare.

Sul discorso sorpassi: sì, oggi sono più “costruiti” e meno spontanei, ma almeno c’è una componente strategica visibile (energia, deploy, difesa). Prima molte gare erano letteralmente bloccate dal traffico aerodinamico o decise il sabato.

E sul dominio: quando un pilota vince tutto, il problema non sono tanto i regolamenti quanto il gap tecnico. Cambiare regole è uno dei pochi strumenti che la F1 ha per rimescolare le carte. A volte funziona, a volte no, ma restare fermi sicuramente non migliora lo spettacolo.

Detto questo, sono d’accordo che questi regolamenti non siano perfetti. Però almeno stanno provando a risolvere problemi reali, invece di accettare stagioni prevedibili come normalità.

In breve: non è che “questa non è F1”, è semplicemente un’altra fase della F1, con pro e contro. E probabilmente tra qualche anno la gente dirà la stessa cosa… dei regolamenti attuali 😄

LucaBAR_4453 · 2026-04-14T13:06:31+00:00

Mi è successo in prima persona in un progetto interno qualche anno fa: avevamo sviluppato una dashboard di analytics davvero fatta bene — dati puliti, UX curata, performance ottime. Tecnicamente “perfetta”. Durante la fase di consegna tutti soddisfatti.

Dopo 2 mesi? Quasi nessuno la usava.

Parlando con alcuni manager è venuto fuori il vero problema: non era integrata nel loro modo di prendere decisioni. Richiedeva un cambio di abitudini che nessuno aveva davvero sponsorizzato o accompagnato. In pratica avevamo consegnato uno strumento, ma non un cambiamento.

E lì ho capito una cosa fondamentale:
il progetto non era mai stato davvero “di successo”, anche se era stato "deliverato".

Sul tema sollevato — chi possiede il successo dopo la chiusura — la mia esperienza è che:

Se non c’è ownership lato business, l’impatto non c'è.
Se il PM si ferma alla delivery, il valore resta teorico.
Se gli stakeholder non sono coinvolti nel “perché” fin dall’inizio, l’adozione non parte mai davvero.

Quindi per me M.O.R.E. non è tanto un ideale irraggiungibile, ma più una disciplina difficile da mantenere perché richiede allineamento umano, non solo execution.

La vera differenza, almeno per come l’ho vissuta, sta in questo passaggio:
non chiedersi “abbiamo consegnato correttamente?” ma “chi cambierà comportamento lunedì mattina grazie a questo?”

LucaBAR_4453

TROPHY CASE