Secondo statistiche del 2001 indicate dal Gartner Group il 30% dei progetti di IT (uno ogni 3!!!) non giungono ad una conclusione positiva ossia vengono abortiti oppure producono un software che non soddisfa i bisogni per cui è stato commissionato. Mentre il 51% supera il budget in media del 189% relizzando solamente il 74% delle funzionalità previste.
Lo scorso anno mi è capitato di vivere l'esperienza di un progetto che è stato abortito, abbastanza presto da ridurre al minimo i danni, abbastanza tardi per poter salvare tutte le teste in un periodo di recessione.
L'aspetto positivo è quanto ho potuto imparare da questa situazione nel adoperarmi per evitare che un progetto fallisca o nel tenermi alla larga da progetti condannati al fallimento.
Che imparare dagli errori (che si vivono, si commettono o che si osservano) è importante specialmente nel IT, lo sento da diverse fonti. Ad esempio i sistemi di qualità e le tecniche di Process Improvements hanno lo scopo di capitalizzare l'esperienza di una organizzazione e metterla in pratica in modo ripetibile; nella Human Computer Interaction quando parla del ciclo di esecuzione e valutazione (dell'errore) di D.A. Norman e anche in XP dove il feedback serve per correggere la rotta e adattarsi ai cambiamenti in una successione convergente di passi.
E infatti proprio in questi giorni ho tratto beneficio da quanto imparato in quel progetto andato a cattivo fine che perciò non è stato inutile.
A questo proposito mi viene in mente un serioso articolo sul tema The top 10 reasons why projects fail e un simpatico proverbio giapponese (?) rubato da Ghost in the Shell 2, Innocence: <<Cosi come si ha fortuna 3 volte, anche la sfortuna da 3 segnali. Non vedi perché non vuoi vedere. Anche se te ne accorgi non lo ammetti. Se qualcuno te lo dice non ascolti. E finisci in una catastrofe.>> ;-)
Tags :
Team Work |
Agile |