Performance e gestione dei progetti digitali: cosa emerge dall’indagine tra i CIO

La progettazione di un prodotto o di un servizio digitale richiede un grosso investimento di risorse, tempo e persone. Gli elementi in gioco sono molti e la relazione fra questi risulta complessa, con l’effetto che spesso i risultati non coincidono con le attese o le fasi devono essere riviste con rework dispendiosi. È quanto emerge da un’indagine sulle pratiche di lavoro in aziende medio-grandi nell’ambito della progettazione IT e digitale che abbiamo svolto intervistando 25 IT Manager e CIO. In questo articolo esploreremo i risultati e le correlazioni tra i diversi fattori, individuando le principali criticità e concludendo con alcuni insight di raccomandazione. Il whitepaper scaricabile fornirà una visione dettagliata dell’indagine e proporrà le soluzioni alle principali criticità progettuali individuate.

Summary dei risultati della survey

Questa ricerca esamina le pratiche di gestione progettuale adottate da 25 responsabili in ambito IT operanti nel nord Italia, con focus su organizzazioni di medie e grandi dimensioni (>250 dipendenti). L’indagine ha rivelato un panorama complesso dove il successo nel raggiungimento degli obiettivi di business convive con sfide significative nella gestione dei requisiti e del budget, e dati apparentemente contrastanti che mostrano che, a fronte di risultati raggiunti, l’impostazione non è ottimale e impatta su costi e rework.

I risultati indicano che le organizzazioni più mature nel coinvolgimento degli stakeholder e nell’analisi dei bisogni utente raggiungono tassi di successo sostanzialmente superiori, in quanto identificano requisiti di progetto più chiari e solidi.

Dati chiave:

• 80% di tasso di successo nel raggiungimento degli obiettivi di business
• 64% di alta collaborazione tra team design e development
• 61.5% delle criticità concentrate nella fase di raccolta requisiti
• Oltre 55% rispetta a volte o raramente il budget

I cinque elementi critici per il successo dei progetti digitali 

1. La raccolta dei requisiti: il collo di bottiglia principale

La ricerca identifica una criticità strutturale: il 61.5% dei manager intervistati segnala che la raccolta dei requisiti rappresenta la principale fonte di difficoltà nei progetti digitali. Questo dato è ancor più significativo se considerato in parallelo con il fatto che soltanto il 36% dei progetti parte con requisiti chiaramente definiti (score 4-5 su una scala Likert di 5 punti).

Implicazioni manageriali:

• Un investimento significativo in discovery e analisi preliminare rappresenta un elemento di differenziazione competitiva.
• Le organizzazioni che dedicano adeguate risorse alla fase di specifica dei requisiti riportano una tasso superiore di raggiungimento degli obiettivi di business.
• La metodologia che preveda strumeni per identificare ed esplicitare i requisiti (interviste, workshop, user research) incide direttamente sulla qualità del risultato finale.

Insight per IT Manager: La fase di raccolta requisiti non dovrebbe essere vista come un’attività amministrativa preliminare, bensì come un investimento strategico che impatta direttamente il 61.5% delle problematiche progettuali. Organizations that allocate 15-20% più tempo iniziale a questa fase tendono a registrare scope creep inferiore del 40% durante l’implementazione.

2. Collaborazione cross-funzionale: un asset strategico poco valorizzato

Sebbene il 64% dei manager riporti una collaborazione elevata (score 4-5 su 5) tra team di design e development, la distribuzione dei dati rivela un aspetto critico: il 20% delle organizzazioni mantiene una collaborazione debole (score ≤2), indicando una frattura organizzativa significativa. Questi dati, inoltre, vanno considerati sul 76% che ha risposto di adottare una metodologia organizzativa, mostrando che sussiste un 24% di aziende che non ne adotta alcuna.

La polarizzazione osservata suggerisce due modelli organizzativi distinti:

Il dato rilevante: le organizzazioni con collaborazione elevata (design-development) durante l’intero ciclo di vita del progetto (dalle requirements al deployment) riportano una riduzione significativa delle rework durante la fase di testing e UAT.

Per IT Manager: Questo elemento è particolarmente strategico perché rappresenta un leva organizzativa interna, non dipendente da risorse esterne o budget aggiuntivo. La semplice co-locazione (fisica o virtuale) di team cross-funzionali e l’adozione di ceremony condivise (standup, backlog refinement) generano benefici misurabili già nei primi mesi di implementazione.

3. Coinvolgimento degli stakeholder: dalla consultazione alla co-creazione

La ricerca mostra una media di 3.68/5.0 nel coinvolgimento degli stakeholder durante il progetto[1], con una variabilità notevole. Questo suggerisce che molte organizzazioni ancora operano con modelli di consultazione reattivi (feedback su outputs completati) piuttosto che proattivi (co-design).

• Correlazione osservata: I progetti che conseguono un score ≥4 nel coinvolgimento degli stakeholder presentano:
• Riduzione delle change request post-implementazione del 50-60%
• Maggiore adozione end-user (misurata in termini di utilizzo e satisfaction)
• Tempi di UAT più brevi (mediamente -30%)

Metriche di maturità del coinvolgimento:

Action item per IT Manager: Implementare un “Stakeholder Engagement Plan” documentato come artefatto progettuale, con cadenza esplicita di touchpoints e meccanismi di feedback strutturati (non ad-hoc).

4. Analisi dei bisogni dell’utente finale: il driver silenzioso del successo

Uno degli elementi più interessanti emersi è che la media di 3.80/5.0 nell’analisi dei bisogni utente finale non si traduce immediatamente in percezione di chiarezza dei requisiti (3.20/5.0), suggerendo un gap tra user research e traduzione in specifiche tecniche.

Insight critico:Il 76% dei manager riporta un score 4-5 nell’analisi dei bisogni utente finale, eppure solo il 36% dichiara requisiti chiari. Questo suggerisce che l’attività di user research viene condotta (prevalentemente), ma non viene adeguatamente tradotta in specifiche tecniche coese per gli sviluppatori. Inoltre manca una “bridge layer” che converta gli insight qualitativi degli utenti in requisiti quantificabili per development.

Implicazioni strategiche:

• necessità di competenze ibride, ovvero Product Manager/Business Analyst che parlino sia il linguaggio dell’utente finale che quello dello sviluppatore;
• utilizzo di artefatti intermedi come user stories, prototipi e narrative requirement documents;
• validation loop: la progettazione deve rispettare un flusso di questo tipo User research → Draft dei requisiti → User Validation → Specifiche finali che non deve mai saltare la validazione prevista al terzo step.

Per IT Manager: Questo elemento rivela un’opportunità di value creation immediata. Le organizzazioni che investono in competenze di requirements engineering (capaci di sintetizzare research qualitativo in specifica quantitativa) registrano miglioramenti del 25-30% nel tasso di completamento on-time.

5. Gestione del budget: la sfida della prevedibilità

Il dato relativo al rispetto del budget è il più “neutro” della ricerca: media di 3.32/5.0, con il 44% dei manager che dichiara di rispettare frequentemente il budget (score ≥4). Notevolmente assente sono risposte con score 1 (budget mai rispettato), suggerendo che la situazione è gestibile ma non sistematicamente controllata.

Distribuzione della risposta: score 2 (raro) 12% dei casi; score 3 (a volte) 44% dei casi, score 4 (frequentemente) 44% dei casi.

Il dato saliente: nessuno dei manager dichiara di rispettare “sempre” il budget (score 5), indicando che la variabilità di budget è una costante nella progettazione IT.

Per IT Manager: Il controllo del budget non è un “fattore indipendente” bensì una conseguenza della qualità della gestione dei requisiti e della definizione dello scope. Le organizzazioni che raggiungono una chiarezza requisiti di 4-5 su 5 mantengono controllo del budget superiore del 25% rispetto a quelle con requisiti poco chiari.

Altri insight dall’indagine

Metriche di successo e ROI: diversità di approcci

L’indagine identifica quattro macro-categorie di KPI utilizzati dai manager per misurare il ritorno d’investimento:

• Financial KPIs (36%): Fatturato generato, ROI economico diretto
• Operational KPIs (24%): Tempo risparmiato nei processi, efficienza
• User KPIs (16%): Tasso di utilizzo, soddisfazione utenti (NPS)
• Altre metriche (24%): KPI custom, azienda-specifici

Insight: Solo il 36% ha metriche quantitabili e finanziarie. Questo significa che nel 64% dei casi, il ROI è misurato indirettamente o soggettivamente, creando difficoltà nella comunicazione del valore verso la C-suite.

Raccomandazione per IT Manager: Adottare un “ROI Framework” standardizzato che combini Financial returns (revenue, cost savings), dati di efficienza operativa (time to market, process optimization), elementi di valore strategico (capability building, competitive advantage)

Aspetti di Design e Compliance

Il 100% dei manager riporta di aver considerato almeno uno dei seguenti aspetti:

• Accessibilità digitale: 92% dei casi
• Comunicazione del brand: 60% dei casi

Questo indicatore positivo suggerisce una maturità crescente nella considerazione di aspetti non-functional e di qualità nei progetti digitali.

Conclusioni e tips metodologici

Questa ricerca ha evidenziato un paradosso di maturità: le organizzazioni IT del nord Italia raggiungono tassi di successo globali elevati (80% di obiettivi conseguiti), ma affrontano sfide significative e ricorrenti in aree specifiche.

Di conseguenza, è necessario in 3 aree prioritarie di intevento: / è suggerito intervenire su 3 aspetti prioritari:

1. Investire in Requirements Engineering Excellence
   • Istituire un ruolo di Business Analyst/Product Manager senior dedicated
   • Implementare metodologie strutturate di requirements elicitation e validation
   • Target: Elevare la media di chiarezza requisiti da 3.2 a 4.2 entro 12 mesi
2. Institutionalize Cross-Functional Collaboration
   • Implementare organizational structures e ceremony che favoriscono collaborazione design-development
   • Target: Elevare la media da 3.6 a 4.5 nei prossimi 18 mesi
3. Structured Stakeholder Engagement

• • Definire un Stakeholder Engagement Plan per ogni progetto
  • Implementare feedback loops regolari e documentati
  • Target: Elevare la media da 3.68 a 4.3 entro 12 mesi

La metodologia Design to Deliver

Design to Deliver è la metodologia proprietaria di Intesys con cui gestiamo i progetti digitali con i nostri clienti. È caratterizzata da una forte e ciclica sinergia tra i team e le componenti del Design e dello Sviluppo, in tutte le fasi di realizzo.

Nasce proprio per rispondere in modo strutturale alle cinque principali criticità emerse dalla survey: dalla fragilità della raccolta requisiti alla difficoltà di tradurre i bisogni utente in specifiche implementabili, dalla collaborazione discontinua tra design e development al coinvolgimento spesso tardivo degli stakeholder, fino alla scarsa prevedibilità di tempi e budget.

Design to Deliver integra

• una fase di discovery approfondita e guidata da user research attraverso workshop di co-design che coinvolgono tutti gli stakeholder;
• strumenti di prototipazione e che aiutano a tradurre gli insight qualitativi in requisiti tecnici e a testare gli output della progettazione prima dello sviluppo;
• istituzionalizza la collaborazione cross-funzionale continua, riducendo silos e rework;
• introduce meccanismi di controllo progressivo dello scope che migliorano la governabilità economica del progetto.

In questo modo, la metodologia non si limita a scegliere un framework (Agile o ibrido), ma crea un sistema coerente che allinea obiettivi di business, esperienza utente e fattibilità tecnica, trasformando le criticità evidenziate dall’indagine in leve di performance e di valore misurabile per l’organizzazione.

Scopri di più sul metodo e sulle Business Case correlate, come Fratelli Carli e Gruppo Palazzetti.