“… spruzzando energia nel vortice del fallimento!”
Rovistando fra i “vecchi bauli” di rete, mi è saltato agli occhi un documento del OECD (Organisation for Economic Co-operation and Development) dal titolo The Hidden Threat to E-Government – Avoiding large government IT failures, che nell’ormai lontano 2001 evidenziava come la maggior parte dei governi spesso incorresse in problemi al momento dell’attuazione dei grandi progetti IT dedicati al e-Governement. Preventivi di spesa che venivano superati, scadenze che venivano mancate, e qualità dei nuovi sistemi molto al di sotto degli standard concordati al momento di intraprendere il progetto, erano, e ahimè sono, ancora oggi, le evidenze più eclatanti dei fallimenti dei progetti di e-Gov. Andando ad allargare l’ambito di verifica dei grandi progetti IT al settore privato, i fallimenti non risultavano più prerogativa esclusiva della PA; le analisi fatte a partire dagli anni 90 dal Standish Group, indicano che, attualizzando i dati ai giorni nostri, le percentuali di successo, misurato da parametri quali il rispetto dei limiti di budget di spesa prestabiliti, le funzionalità realmente sviluppate e il rispetto delle scadenze, oscillano, anno più anno meno, intorno al 30% del totale; per il restante 70%, una parte pari al 20/25%, sono stati cancellati/annullati definitivamente (falliti miseramente!) e per il rimanente 45/50% l’obiettivo è stato mancato in almeno uno dei succitati tre parametri (budget-scadenze-funzionalità).
Abbiamo fatto tesoro dei fallimenti?
La storia, rimarcata dalla relazione svedese sui requisiti per una gestione di successo dei grandi progetti IT di e-Government, ci racconta che si fanno sempre gli stessi errori, più e più volte.
I risultati dell’epoca, ma sempre validi, pubblicati dal National Audit Office e l’Agency for Public Management svedesi, evidenziano come i rischi sarebbero notevolmente ridotti in caso di:
- progetti più piccoli gestibili;
- risultati step by step;
- sviluppo basato su una solida visione, non sul bug fixing;
- evitando risposte/reazioni affrettate ed istintive;
- acquisto/utilizzo di sistemi chiavi in mano;
- rinuncia a personalizzazioni spinte di sistemi acquisiti;
- approccio “slow trigger, fast bullet”;
- rinuncia a compromessi sulle garanzie di qualità.
Il successo “sembra” essere figlio di una serie di fattori critici di successo, elaborati dal già citato Standish Group, sulla base dei commenti dei project manager IT statunitensi. La tabella qui di seguito elenca i criteri in ordine di importanza, indicandone il relativo peso.
Anche qui la storia ci torna a raccontare che la definizione e progettazione di una user experience di successo, “don’t make me think!”, non può e non deve prescindere da un “pesante” coinvolgimento dell’utente. La tecnologia è slave non master, deve quindi continuare ad essere “umile servitore” al cospetto del suo padrone: l’utente!
Pillole di saggezza da Dilbert
… e massime da ricavare
Progetti e tecnologie complicate non funzionano! Se uno schema progettuale è troppo complesso e complicato da capire è quasi certo che quel progetto fallirà. Meglio, molto meglio, suddividere in sottoinsiemi più piccoli e più facili da capire.
“Spruzzare energia nel vortice del fallimento” non funziona. La complessità non si risolve con un pio desiderio, o con le vane fantasie di un gruppo di entusiasti consulenti … altrimenti questo nostro mondo sarebbe un posto migliore.
Al tuo capo davvero non importa. La miopia di gestione di un management disconnesso/dissociato può essere devastante: “il loro” progetto diventa “il tuo” problema!
Commenti recenti