Superare l’inganno delle previsioni perfette: l’arte del budgeting IT nell’era contemporanea

La diffusione delle metodologie agili in contesti di sviluppo software e, più in generale, nella gestione dei progetti IT, ha portato con sé una serie di cambiamenti profondi nei modi di lavorare, di pianificare e di controllare i costi. Uno dei temi più complessi da affrontare per i Manager IT (CIO) e per i Responsabili finanziari (CFO) è come costruire e gestire un budget in un contesto in cui i fornitori esterni – con cui si stipulano contratti e si definiscono deliverable – lavorano con cicli brevi (iteration, sprint o timebox di 2-3 settimane). In questo scenario, tali fornitori offrono visibilità dettagliata e previsioni accurate solo nel breve termine. Quando si tratta invece di orizzonti temporali più lunghi, i fornitori optano per stime costruite con intervalli di confidenza, basate sulle informazioni disponibili al momento. Queste stime, pur costruite al meglio, restano inevitabilmente soltanto indicative, poiché non tutti i dettagli necessari per una previsione più affidabile sono disponibili fin dall’inizio. Molti di questi elementi emergeranno infatti solo nel corso del progetto, grazie ai feedback degli utenti e sulla base delle evoluzioni delle esigenze di business da soddisfare. 

Questo scenario crea inevitabilmente tensione tra l’approccio “classico” al budgeting, tipicamente annuale o multi-annuale, e la natura iterativa e incrementale dell’Agile. 

Con il passare del tempo, tuttavia, sono emerse pratiche, framework e filosofie di gestione che suggeriscono come riconciliare una governance economica coerente con la flessibilità indispensabile per la gestione delle iniziative di trasformazione digitale.

Nelle metodologie di budgeting tradizionali si partiva, in genere, da uno scenario in cui la Direzione IT e la Direzione Finanziaria concordavano all’inizio dell’anno un determinato ammontare di spesa. Questo importo veniva stabilito sulla base di progetti pianificati con mesi, se non anni, di anticipo. Tali progetti, nella loro forma classica, erano gestiti con un approccio a cascata (waterfall), contraddistinto da una sequenza lineare di fasi (analisi, progettazione, sviluppo, test, rilascio) e da deliverable definiti nel dettaglio già all’inizio, quasi come se le esigenze non dovessero mai cambiare. Questo permetteva una relativa stabilità: le attività erano ben delineate, i costi e i tempi per singola fase stimati con una precisione solo apparente, e la Direzione Finanziaria poteva allocare i fondi senza la necessità di continue revisioni. In questo scenario, l’IT era spesso considerato un centro di costo piuttosto che un motore di valore. 

Oggi, l’approccio Agile si fonda su principi decisamente diversi. Essendo la tecnologia e il mercato in costante evoluzione, le specifiche dei progetti non possono assolutamente essere considerate immobili dall’inizio alla fine. Le esigenze dei clienti cambiano, i feedback provenienti dal campo suggeriscono nuovi sviluppi, le priorità del business si modificano in base alle opportunità emergenti, e le nuove tecnologie introdotte sul mercato possono rendere obsolete, in poche settimane, alcune delle soluzioni originariamente pianificate. 

Di fronte a questo scenario, i fornitori – almeno quelli orientati allagenerazione di valoree alla consegna disoftware di qualità– lavorano per incrementi rapidi e iterativi (sprint), generalmente di 2-3 settimane, consegnando in tempi brevi porzioni funzionanti di prodotto. Questo approccio consente di adattare costantemente la rotta in base al feedback appena raccolto, evitando di accumulare ritardi e costi su funzionalità non più essenziali. Tuttavia, proprio questa flessibilità, che rappresenta il cuore dell’agilità, entra in conflitto con la rigidità dei metodi di budgeting tradizionali, generando una serie di problematiche. 

Incertezza sui deliverable futuri  
Poiché l’approccio Agile consente di modificare la roadmap sulla base di feedback e nuove priorità che emergono man mano, diventa complesso definire con precisione, già a inizio anno, quali funzionalità verranno rilasciate tra sei o nove mesi. Dopo un paio di iterazioni (indicativamente 4-6 settimane), le conoscenze acquisite potrebbero suggerire l’eliminazione di alcune attività previste, l’aggiunta di altre funzionalità più utili o un cambiamento radicale delle priorità. Questo rende inevitabilmente molto meno affidabili le previsioni di lungo periodo basate su dettagli statici, poiché la roadmap è un “oggetto vivo” e in costante evoluzione. 

Frequente ridefinizione delle priorità  
Se l’organizzazione vuole davvero raggiungere gli obiettivi di valore di business ipotizzati, e quindi sfruttare i benefici dell’agilità, non si limiterà a piani iniziali fissi, ma rivedrà regolarmente le priorità in funzione dei risultati parziali ottenuti. Ciò potrebbe significare, ad esempio, spostare risorse da un progetto a un altro se si intuisce che il secondo offrirà maggior valore per il business. In un modello tradizionale, questo genere di cambiamenti era difficile da implementare, poiché l’intero piano e il budget erano calibrati su un set di attività predefinite. Con l’agilità, invece, è proprio questa capacità di adattamento costante a fare la differenza. Di conseguenza, il budget non può più essere una “gabbia” rigida, ma deve diventare uno strumento dinamico, che si aggiorna e si riconfigura nel corso dell’anno. Questo comporta la necessità di rivedere i processi di budgeting e di governance, creando meccanismi di allocazione più flessibili, magari con revisioni trimestrali o mensili. 

Necessità di valorizzare il risultato, non lo sforzo  
Nelle logiche tradizionali, era relativamente comune considerare il costo come una funzione dello sforzo (per esempio, del numero di funzionalità consegnate o, peggio ancora, il numero di linee di codice prodotte). Ma nell’universo Agile, la vera domanda non è “Quante funzionalità abbiamo consegnato?” bensì “Qual è il valore di business generato dalle funzionalità consegnate?”. L’obiettivo non è produrre codice in linea con un piano predefinito, ma rilasciare rapidamente funzionalità che migliorino l’esperienza del cliente, aumentino le vendite, riducano i costi operativi o portino altre forme di valore tangibile. Questo cambio di prospettiva rende superflua la pianificazione tradizionale basata su deliverable fissi, perché ciò che conta non è la quantità di lavoro svolto, ma l’entità dell’impatto sul business. I budget pensati per finanziare un determinato “pacchetto di funzionalità” devono dunque essere ripensati per finanziare un continuo flusso di valore, soggetto a cambiamenti di priorità. 

In altre parole, il budgeting tradizionale presuppone un contesto stabile, previsioni affidabili a lungo termine e attività definite fin da subito con chiarezza. L’universo Agile, con la sua natura dinamica, iterativa e centrata sul valore, ribalta queste premesse. Ne deriva che i vecchi modelli di budgeting, così come erano concepiti, non risultano più adeguati. Per i manager, questo richiede un ripensamento dei criteri con cui definire, monitorare e adeguare il budget, accogliendo logiche di flessibilità, revisione continua e attenzione ai risultati, piuttosto che ai deliverable rigidamente prestabiliti.

Budgeting dinamico e ritmi più brevi  
Il superamento della tradizionale logica di pianificazione waterfall consente di andare oltre i limiti di rigidità che la rendono inefficace nei contesti dinamici della trasformazione digitale. Alla base di questo approccio vi è l’idea di abbandonare la staticità del budget annuale, sostituendolo con un processo più flessibile, articolato in intervalli più brevi, come trimestri o persino mesi. Questa frequenza di revisione, coerente con i cicli di sviluppo Agile, non significa rinunciare del tutto alla visione annuale, bensì adattare la ripartizione interna dei fondi secondo i feedback continui provenienti dal campo. L’obiettivo è garantire che le risorse finanziarie siano costantemente allineate alle necessità emergenti, evitando l’immobilismo tipico dei piani a lungo termine, ma rimanendo all’interno di un processo di controllo coerente con i principi contabili e con le regole di governance aziendali. 

Allineamento con le priorità di business  
Il budget IT non va più considerato come una semplice voce di costo, ma come un driver strategico. Le iniziative tecnologiche devono competere per le risorse in base al loro impatto sul business, alla capacità di misurare gli outcome e alla loro strategicità. In questo senso, l’adozione di pratiche di portfolio management agile aiuta a garantire che i fondi siano destinati alle opportunità di maggior valore, valorizzando quegli investimenti che, in ultima analisi, portano risultati tangibili all’organizzazione.

Quando si parla di budgeting agile, un aspetto cruciale è la capacità di ingaggiare e contrattualizzare i fornitori esterni in modo da creare un contesto di flessibilità, trasparenza e adattabilità. Lavorare con partner che operano a cicli iterativi brevi (2-3 iterazioni, equivalenti a rilasci o checkpoint ogni 4-6 settimane) impone di strutturare accordi che permettano di riconfigurare facilmente risorse, scope e priorità, senza perdere di vista il valore generato. In questo scenario, possono essere adottate diverse tecniche. 

Team dedicati con costo definito per un certo intervallo di tempo  
Una pratica diffusa consiste nel definire i costi di team multidisciplinari autonomi con orientamento alla generazione di valore di business. Invece di calcolare il costo per singola funzionalità, il budget copre il mantenimento di questa “capacità produttiva” per un periodo (ad es. un trimestre/semestre/anno). Ogni 2-3 iterazioni si può valutare il valore generato e, se necessario, ridurre o aumentare le risorse oppure riorientarle verso altre iniziative. In questo modo si trasforma il problema della stima in una questione di capacity planning: di quanti team avvalersi e per quanto tempo mantenerli attivi. 

Opzioni di uscita o ridimensionamento periodico  
Per evitare impegni a lungo termine troppo rigidi, è possibile inserire nei contratti con i fornitori agili opzioni di uscita trimestrali/semestrali/annuali, collegate a specifici indicatori. Queste metriche non devono essere limitate ad indicatori operativi (output di attività), bensì essere orientate alla misura dell’outcome di business raggiunto. Agendo in questo modo, i fondi vengono allocati su base temporale ridotta, con la possibilità di ridurre o espandere lo scope a seconda dei risultati di valore ottenuti. 

Adottare una pianificazione finanziaria a scorrimento  
Anziché definire un budget statico a inizio anno, si può optare per un meccanismo previsionale “in movimento” (rolling), rivedendo la previsione di spesa ogni 3 - 6 mesi. Questa revisione periodica (rolling forecast) permette di adattare la disponibilità economica in base a ciò che i fornitori hanno consegnato, alle nuove priorità emerse e alle opportunità scoperte lungo il percorso. In tal modo, il budget diventa un meccanismo flessibile, sempre aggiornato sulle ultime evidenze di valore. 

Allocazione dei fondi in base a linee di prodotto o flusso di valore  
Invece di destinare il budget a singoli progetti con obiettivi rigidi, è possibile concentrarsi su intere aree di prodotto o flussi di valore (value stream) che generano valore continuo per il business. Immaginiamo di stabilire un budget annuale per l’intera piattaforma di Customer Experience (ad esempio, tutti i canali digitali e le funzionalità che migliorano l’esperienza del cliente). In questo modo, non si finanzia un singolo progetto con scopo e fine già definiti, ma si crea un “contenitore” di risorse destinato a sviluppi e miglioramenti successivi nel tempo.  
Grazie a questo approccio, i team interni ed esterni – inclusi i fornitori – possono decidere, iterazione dopo iterazione, quali iniziative avviare per ottenere il massimo impatto in base alle esigenze del momento. Così, l’ingaggio del fornitore non è vincolato ad un elenco statico di funzionalità, ma diventa una modalità con cui costruire una partnership nell’evoluzione continua del prodotto. Il budget supporta quindi la crescita dinamica del valore, anziché la mera conclusione di un singolo progetto. 

Metriche di valore e remunerazione basata sui risultati  
Con questo approccio, parte del compenso del fornitore è collegata alla capacità di raggiungere risultati concreti, misurabili e orientati al business, non solo alla quantità di ore lavorate o alle funzionalità rilasciate. Ciò significa che la retribuzione variabile del partner non si limita all’esecuzione di compiti, ma dipende dall’effettivo miglioramento di determinati parametri che qualificano il valore generato dall’attività di sviluppo software. 

Ad esempio, si possono definire indicatori chiave come la riduzione dei tempi di risposta del sito, la diminuzione dei bug in produzione, la riduzione del codice duplicato, il superamento dei test di sicurezza o la stabilità della piattaforma. Questi indicatori – la cui evoluzione è sotto il diretto controllo del fornitore, in quanto collegati a processi e tecniche di sviluppo e testing – consentono di misurare con maggiore precisione la qualità del lavoro svolto. Se tali parametri mostrano un miglioramento, il fornitore riceve un incentivo extra; in caso contrario, la parte variabile del compenso può essere ridotta. 

Tuttavia, è possibile spingersi oltre, legando il compenso a metriche direttamente correlate al valore di business generato dal software. Ad esempio, si potrebbe considerare l’aumento dei tassi di conversione, la crescita del fatturato online o la riduzione dei costi operativi, a condizione che questi dati siano misurabili e attribuibili alle funzionalità implementate. In questo modello ambizioso, il fornitore assume un ruolo abilitante, contribuendo alla creazione di valore per l’azienda committente attraverso la realizzazione di un prodotto software di alta qualità. Tuttavia, la responsabilità delle scelte strategiche e delle decisioni di business rimane saldamente nelle mani del committente: definire strategie di mercato, selezionare le iniziative da sviluppare o ottimizzare i processi interni sono leve che esulano dal controllo del fornitore. Proprio per questo, un tale approccio richiede una relazione di fiducia e trasparenza ben consolidata, in cui entrambe le parti riconoscano i rispettivi ruoli: il fornitore si concentra sull’eccellenza tecnica del software, mentre il committente mantiene il controllo sulle decisioni chiave che determinano il successo del progetto.

Nel passaggio a un budgeting realmente agile, il Project Management Office (PMO) assume un ruolo cruciale nel garantire continuità di visione, qualità delle informazioni e fiducia degli stakeholder, incluso il top management e gli azionisti. Da semplice struttura focalizzata su Gantt e milestone rigide, il PMO può evolversi in un Lean Portfolio Management Office, divenendo così un vero e proprio nodo di raccordo tra strategia, esecuzione e misurazione del valore. 

In un contesto di budget flessibili, rivisti periodicamente, il PMO coordina i diversi flussi di valore, raccogliendo e integrando dati sulla performance dei team IT e dei fornitori, monitorando gli indicatori chiave e collegandoli agli obiettivi di business. Questo approccio fornisce un quadro chiaro dell’impatto effettivo degli investimenti IT, aggiornato sulla base dei risultati ottenuti e non più vincolato a un piano iniziale immutabile. Così, il PMO diventa un “orchestratore” del portafoglio di iniziative, capace di riallocare fondi e priorità in modo dinamico, in funzione del valore che ciascun progetto produce. 

Grazie a questa prospettiva integrata, il PMO può offrire al vertice aziendale e agli azionisti rassicurazioni più solide rispetto a quelle derivanti da un budget statico, senza dover sostenere l’illusione di una capacità previsionale espressa ad inizio progetto senza avere a disposizione le informazioni necessarie. Al contrario, fornisce un controllo più stretto e frequente, consentendo di reagire ai cambiamenti e di spostare l’attenzione sui progetti più promettenti. La trasparenza dei dati, le revisioni periodiche e la capacità di dimostrare i progressi rispetto agli obiettivi strategici rendono il PMO un interlocutore chiave nella governance del budget, garantendo un approccio dinamico e orientato al valore, anziché basato sull’aderenza a piani rigidi e predefiniti. 

Sarebbeun errore gravissimo, tuttavia, se il PMO si limitasse asvolgere un ruolo di controllo ispettivo, focalizzandosisu metriche di output o di puro processo– come il rispetto di un piano immutabile o la produttività misurata in linee di codice per unità di tempo – ignorando l’importanza di valutaregli outcome reali generati. Ridurre il PMO a unafunzione di policing su indicatori miopi, orientati all’efficienza di breve periodo e non all’efficacia strategica,vanificherebbe lo spirito dell’agilità. Al contrario, il PMO deve concentrarsi sulvalore prodotto, sull’impatto delle iniziative e sull’allineamento con gli obiettivi di lungo termine,favorendo il cambiamento culturale e metodologico necessarioper affrontare con successo le sfide del contesto digitale.

La trasformazione digitale, l’avvento delle metodologie Agile e l’evoluzione dei rapporti con i fornitori IT hanno ridefinito il modo di concepire la pianificazione economica e finanziaria dei progetti informatici. Da un lato, le logiche tradizionali di budgeting, basate su previsioni rigide e lontane nel tempo, si sono dimostrate inadattea contesti caratterizzati da incertezza, mutamenti rapidi e necessità di adattamento continuo. Dall’altro lato, l’approccio Agile, pur aumentando la complessità nella previsione di costi e deliverable a lungo termine, offre l’opportunità di creare sistemi di budgeting dinamici, periodicamente ricalibrati in base al valore generato, all’impatto sull’utente finale e al contributo effettivo alla strategia aziendale. 

Ripensare il budgeting IT in chiave agile significa adottare principi cardine come la flessibilità negli orizzonti temporali, l’allineamento con le priorità di business, la trasparenza nei dati e la misurazione continua del valore. Significa, inoltre, considerare i fornitori non come semplici esecutori di un piano predefinito, ma come partner inseriti in un flusso di valore continuo, governato attraverso modelli contrattuali più evoluti e meccanismi di remunerazione basati sui risultati. In questo processo, funzioni come la Direzione Finanziaria, la Direzione IT, il PMO e le Business Line diventano attori fondamentali per garantire una visione strategica condivisa e una governance efficace dei fondi, assicurando la capacità di reagire prontamente al cambiamento.

·      Bogsnes, B. (2009, 2nd ed. 2016). Implementing Beyond Budgeting: Unlocking the Performance Potential. Wiley. 

·      Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall. 

·      Humble, J., Molesky, J., & O’Reilly, B. (2014). Lean Enterprise: How High Performance Organizations Innovate at Scale. O’Reilly Media. 

·      Kersten, M. (2018). Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press. 

·      Larman, C., & Vodde, B. (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley. 

·      Mainetti, S. (2024). Convertire l’incertezza in valore tangibile, ovvero fare del cambiamento la vera stabilità, disponibile al link https://www.linkedin.com/pulse/convertire-lincertezza-valore-tangibile-ovvero-fare-del-mainetti-ut4bf 

·      Mainetti, S., Marsanasco A., (2024). Costruire valore duraturo: il dialogo tra strategia e operatività, disponibile al link: https://www.linkedin.com/pulse/costruire-valore-duraturo-il-dialogo-tra-strategia-e-stefano-mainetti-x9odf 

·      Mainetti, S. (2024). Verba volant, scripta manent, facta valent, disponibile al link https://www.linkedin.com/pulse/verba-volant-scripta-manent-facta-valent-stefano-mainetti-keyrf/ 

·      Rautiainen, K., Schobl, M., & Kettunen, P. (2019). Agile Contracts—Allocating and Managing Risks in Agile Software Projects. IEEE Software, 36(2), 47–53. 

·      Rigby, D. K., Berez, S., Caimi, G., & Noble, A. (2018). "Agile Teams", Harvard Business Review. 

·      Uludağ, Ö., Harders, L., Reiter, N., & Matthes, F. (2020). Towards Lean Portfolio Management: Aligning Agile Teams with Business Strategies. International Conference on Enterprise, Business-Process and Information Systems Modeling (BPMDS), 61–75. Springer.