Perché falliscono i progetti IT, e come evitarlo

Raramente è un problema di tecnologia

Quando un progetto IT va male, la prima spiegazione che si sente è quasi sempre tecnica: il software non era adatto, il fornitore non era all'altezza, l'infrastruttura non reggeva. È una spiegazione comoda, perché sposta la causa fuori dall'azienda. Nella pratica, i progetti che si vedono naufragare hanno quasi sempre un problema a monte della tecnologia: nessuno con il potere di decidere, uno scope che cresce senza controllo, un'adozione mai davvero curata dopo il rilascio.

Il primo problema: uno scope che cresce da solo

Un progetto parte con un perimetro definito. Poi, riunione dopo riunione, qualcuno chiede di aggiungere "giusto un'altra cosa, già che ci siamo". Ogni singola aggiunta sembra piccola e ragionevole. La somma, dopo qualche mese, è un progetto diverso da quello approvato, con budget e tempi rimasti quelli originali.

Questo fenomeno ha un nome, scope creep, e non si risolve dicendo sempre no: si risolve avendo un processo per valutare ogni richiesta di cambiamento, con l'impatto su tempi e costi reso esplicito prima di accettarla, e con qualcuno che ha davvero l'autorità di dire "questo lo facciamo nella fase due".

Il secondo: nessuno con il potere di decidere

Molti progetti coinvolgono più reparti, ognuno con la propria opinione, e nessuno con l'autorità di chiudere una discussione. Il risultato sono decisioni prese per stanchezza, rimandate, o prese due volte in modo diverso da persone diverse.

Serve un project owner reale, non solo sulla carta: qualcuno che ha il mandato di decidere, che risponde del risultato, e a cui le altre persone coinvolte riconoscono davvero quel ruolo. Senza questa figura, anche il miglior metodo di gestione progetti si riduce a un calendario di riunioni.

Il terzo: l'adozione trascurata dopo il rilascio

Un progetto spesso viene considerato finito al momento del rilascio tecnico: il sistema è acceso, la fattura è emessa. Ma un sistema che le persone non usano, o usano male perché nessuno le ha formate con cura, non ha prodotto il valore per cui è stato commissionato.

L'adozione va progettata quanto il sistema stesso: formazione mirata ai compiti reali delle persone, referenti interni a cui rivolgersi nelle prime settimane, un periodo di affiancamento prima di considerare il progetto davvero concluso.

Il quarto: fornitori scelti sul prezzo, non sul metodo

Il preventivo più basso non è per forza il progetto più economico: lo è solo se il fornitore consegna quello che ha promesso, nei tempi promessi. Un metodo di lavoro assente, nessun registro dei rischi, nessuna gestione formale delle richieste di cambiamento, comunicazione solo quando qualcosa va storto, costa quasi sempre più caro di una tariffa oraria più alta ma con un processo solido dietro.

Cosa fare diversamente

1. Scegli il metodo in base al contesto: predittivo, a cascata, quando i requisiti sono stabili e noti fin dall'inizio, agile quando il prodotto si scopre lavorando, ibrido quando serve un po' di entrambi. Non è una scelta ideologica, ma pratica.
2. Nomina un project owner con autorità reale, non solo un nome su un documento.
3. Tieni un registro di rischi e decisioni, aggiornato, non scritto una volta e dimenticato.
4. Gestisci formalmente ogni richiesta di cambiamento, con l'impatto su tempi e costi reso esplicito prima di accettarla.
5. Progetta l'adozione come parte del progetto, non come un'attività a parte dopo il rilascio.

Checklist prima di partire

• esiste un project owner con l'autorità reale di decidere, non solo sulla carta;
• lo scope del progetto è scritto, condiviso, e c'è un processo per valutare le modifiche;
• esiste un registro di rischi e decisioni, aggiornato durante il progetto;
• il fornitore ha un metodo di lavoro verificabile, non solo un prezzo competitivo;
• è previsto un budget di tempo per la formazione e l'adozione, non solo per lo sviluppo;
• il successo del progetto è definito con criteri misurabili, decisi prima di iniziare.

In sintesi