Hai sentito quello sul magazzino che scompare? Un giorno, è scomparso-non dalla vista fisica, ma dagli occhi vigili del sistema di distribuzione automatizzato di un noto rivenditore. Un problema tecnico del software aveva in qualche modo cancellato l’esistenza del magazzino, così che le merci destinate al magazzino venivano dirottate altrove, mentre le merci al magazzino languivano. Poiché la società era in difficoltà finanziarie ed era stato casseforme altri magazzini per risparmiare denaro, i dipendenti presso il magazzino “mancante” taciuto. Per tre anni, nulla è arrivato o lasciato. I dipendenti stavano ancora ricevendo i loro stipendi, tuttavia, perché un sistema informatico diverso gestiva il libro paga. Quando il problema tecnico del software è finalmente venuto alla luce, la merce nel magazzino è stata venduta e la direzione superiore ha detto ai dipendenti di non dire nulla sull’episodio.

Questa storia è stata galleggiante intorno al settore della tecnologia dell’informazione per 20-alcuni anni. Probabilmente è apocrifo, ma per quelli di noi nel business, è del tutto plausibile. Perché? Perché episodi come questo accadono tutto il tempo. Lo scorso ottobre, ad esempio, il gigante rivenditore di alimenti britannico J Sainsbury PLC ha dovuto cancellare il suo investimento di 526 milioni di dollari in un sistema di gestione automatizzata della supply chain. Sembra che la merce fosse bloccata nei depositi e nei magazzini dell’azienda e non arrivasse a molti dei suoi negozi. Sainsbury fu costretto ad assumere circa 3000 impiegati aggiuntivi per rifornire manualmente i suoi scaffali .

Questo è solo uno degli ultimi in una lunga, triste storia di progetti IT andato storto . La maggior parte degli esperti IT concorda sul fatto che tali fallimenti si verificano molto più spesso di quanto dovrebbero. Cosa c’è di più, i fallimenti sono universalmente senza pregiudizi: accadono in ogni paese; alle grandi aziende e piccole; in commerciale, senza scopo di lucro, e le organizzazioni governative; e senza riguardo per lo status o la reputazione. I costi aziendali e sociali di questi fallimenti – in termini di dollari sprecati di contribuenti e azionisti e investimenti che non possono essere fatti—sono ora ben nei miliardi di dollari all’anno.

Il problema peggiora solo man mano che diventa onnipresente. Quest’anno, organizzazioni e governi spenderanno circa 1 trilione di dollari su hardware, software e servizi IT in tutto il mondo. Dei progetti IT che vengono avviati, dal 5 al 15 per cento sarà abbandonato prima o poco dopo la consegna come irrimediabilmente inadeguata. Molti altri arriveranno in ritardo e oltre il budget o richiedono una rielaborazione massiccia. Pochi progetti IT, in altre parole, hanno davvero successo.

La più grande tragedia è che il fallimento del software è per la maggior parte prevedibile ed evitabile. Sfortunatamente, la maggior parte delle organizzazioni non vede prevenire il fallimento come una questione urgente, anche se questa visione rischia di danneggiare l’organizzazione e forse anche distruggerla. Capire perché questo atteggiamento persiste non è solo un esercizio accademico; ha enormi implicazioni per le imprese e la società.

IL SOFTWARE È OVUNQUE. E ‘ quello che ci permette di ottenere denaro da un bancomat, fare una telefonata, e guidare le nostre auto. Un tipico cellulare ora contiene 2 milioni di righe di codice software; entro il 2010 probabilmente avrà 10 volte di più. General Motors Corp. stima che a quel punto le sue auto avranno ciascuna 100 milioni di righe di codice.

L’azienda media spende circa 4-5 per cento delle entrate sulla tecnologia dell’informazione, con quelli che sono altamente IT dipendente—come le società finanziarie e di telecomunicazioni—spendendo più del 10 per cento su di esso. In altre parole, è ora una delle più grandi spese aziendali al di fuori dei costi dei dipendenti. Gran parte di quel denaro va in aggiornamenti hardware e software, costi di licenza del software, e così via, ma una grossa fetta è per i nuovi progetti software destinati a creare un futuro migliore per l’organizzazione ei suoi clienti.

Anche i governi sono grandi consumatori di software. Nel 2003, il Regno Unito aveva più di 100 importanti progetti IT governativi in corso che ammontavano a $20,3 miliardi. Nel 2004, il governo degli Stati Uniti ha catalogato 1200 progetti IT civili che costano più di billion 60 miliardi, più altri billion 16 miliardi per il software militare.

Uno qualsiasi di questi progetti può costare oltre $1 miliardo. Per prendere due esempi attuali, lo sforzo di modernizzazione del computer presso il Dipartimento degli Affari dei Veterani degli Stati Uniti dovrebbe correre billion 3.5 miliardi, mentre l’automazione delle cartelle cliniche del Servizio sanitario nazionale del Regno Unito rischia di costare più di billion 14.3 miliardi per lo sviluppo e un altro billion 50.8 miliardi per la distribuzione.

Tali progetti megasoftware, una volta rari, sono ora molto più comuni, poiché le operazioni IT più piccole sono unite in “sistemi di sistemi.”Il controllo del traffico aereo è un ottimo esempio, perché si basa su connessioni tra decine di reti che forniscono comunicazioni, meteo, navigazione e altri dati. Ma il trucco dell’integrazione ha ostacolato molti sviluppatori IT, al punto in cui i ricercatori accademici credono sempre più che l’informatica stessa possa aver bisogno di essere ripensata alla luce di questi sistemi massicciamente complessi.

Quando un progetto fallisce , mette a repentaglio le prospettive di un’organizzazione. Se il fallimento è abbastanza grande, può rubare l’intero futuro dell’azienda. In una fusione stellare, un sistema di pianificazione delle risorse mal implementato ha portato FoxMeyer Drug Co., una società di distribuzione di droga all’ingrosso billion 5 miliardi a Carrollton, Texas, a precipitare in bancarotta nel 1996.

Il fallimento IT nel governo può mettere in pericolo la sicurezza nazionale, come ha dimostrato la debacle del caso virtuale dell’FBI. Il sistema VCF da 170 milioni di dollari, un database ricercabile destinato a consentire agli agenti di “collegare i puntini” e seguire le informazioni disparate, si è invece concluso cinque mesi fa senza che alcun sistema venga distribuito .

I fallimenti IT possono anche frenare la crescita economica e la qualità della vita. Nel 1981, la Federal Aviation Administration degli Stati Uniti ha iniziato a esaminare l’aggiornamento del suo antiquato sistema di controllo del traffico aereo, ma lo sforzo di costruire una sostituzione divenne presto pieno di problemi . Nel 1994, quando l’agenzia ha finalmente rinunciato al progetto, il costo previsto era triplicato, erano stati spesi più di $2,6 miliardi e la data di consegna prevista era scivolata di diversi anni. Ogni passeggero aereo che è in ritardo a causa di skyways gridlocked sente ancora questa cancellazione; l’impatto economico cumulativo di tutti quei ritardi sulle sole compagnie aeree statunitensi (non importa i passeggeri) si avvicina a billion 50 miliardi.

In tutto il mondo, è difficile dire quanti progetti software falliscono o quanti soldi vengono sprecati come risultato. Se si definisce fallimento come l’abbandono totale di un progetto prima o poco dopo che viene consegnato, e se si accetta un tasso di fallimento conservativo del 5 per cento, poi miliardi di dollari vengono sprecati ogni anno su software difettoso.

Ad esempio, nel 2004, gli Stati Uniti. il governo ha speso billion 60 miliardi sul software (senza contare il software incorporato nei sistemi d’arma); un tasso di fallimento del 5 per cento significa probably 3 miliardi è stato probabilmente sprecato. Tuttavia, dopo diversi decenni come consulente IT, sono convinto che il tasso di fallimento è dal 15 al 20 per cento per i progetti che hanno budget di $10 milioni o più. Guardando l’investimento totale in nuovi progetti software-sia governativi che aziendali-negli ultimi cinque anni, stimo che i fallimenti dei progetti siano probabilmente costati all’economia statunitense almeno billion 25 miliardi e forse fino a billion 75 miliardi.

Naturalmente, quei billion 75 miliardi non riflettono i progetti che superano i loro budget, cosa che la maggior parte dei progetti fa. Né riflette i progetti consegnati in ritardo-che la maggior parte sono. Inoltre, non tiene conto dei costi opportunità di dover ricominciare una volta che un progetto viene abbandonato o dei costi dei sistemi bug-ridenominati che devono essere ripetutamente rielaborati.

Poi, c’è anche il costo del contenzioso da parte di clienti irati che fanno causa ai fornitori per sistemi mal implementati. Quando si sommano tutti questi costi aggiuntivi, la scheda annuale per il software fallito e problematico viene eseguita in modo conservativo da somewhere 60 miliardi a billion 70 miliardi nei soli Stati Uniti. Per quei soldi, si potrebbe lanciare lo space shuttle 100 volte, costruire e distribuire l’intero 24-satellite Global Positioning System, e sviluppare il Boeing 777 da zero—e hanno ancora qualche miliardo di sinistra sopra.

Perché i progetti falliscono così spesso?

Tra i fattori più comuni:

• Irrealistiche o inarticolata obiettivi del progetto
• stime Imprecise delle risorse necessarie
• Mal definiti requisiti di sistema
• Poveri di rendicontazione del progetto di stato
• non gestito rischi
• la Scarsa comunicazione tra i clienti, sviluppatori, e gli utenti
• Uso della tecnologia immatura
• Incapacità di gestire la complessità di un progetto
• Sciatta pratiche di sviluppo
• cattiva gestione del progetto
• Stakeholder politica
• pressioni Commerciali

naturalmente, progetti raramente fallire solo per uno o due motivi. Il progetto VCF dell’FBI ha sofferto di molti dei problemi sopra elencati. La maggior parte dei fallimenti, infatti, può essere ricondotta a una combinazione di decisioni tecniche, di gestione del progetto e di business. Ogni dimensione interagisce con le altre in modi complicati che aggravano i rischi e i problemi del progetto e aumentano la probabilità di fallimento.

Considera un semplice lavoro di routine software: un sistema di acquisto che automatizza l’ordine, la fatturazione e la spedizione delle parti, in modo che un venditore possa inserire l’ordine di un cliente, verificarlo automaticamente in base ai prezzi e ai requisiti contrattuali e organizzare l’invio delle parti e della fattura al cliente dal magazzino.

I requisiti per il sistema specificano quattro passaggi fondamentali. In primo luogo, c’è il processo di vendita, che crea una fattura di vendita. Tale fattura viene quindi inviata attraverso un processo legale, che rivede i termini e le condizioni contrattuali della potenziale vendita e li approva. Terzo in linea è il processo di fornitura, che invia le parti contratte per, seguito dal processo di finanza, che invia una fattura.

Diciamo che mentre viene scritto il primo processo, per le vendite, i programmatori trattano ogni ordine come se fosse collocato nella sede principale dell’azienda, anche se l’azienda ha filiali in diversi stati e paesi. Questo errore, a sua volta, influisce sul modo in cui viene calcolata l’imposta, sul tipo di contratto emesso e così via.

Prima viene rilevata e corretta l’omissione, meglio è. E ‘un po’ come lavorare a maglia un maglione. Se si individua un punto mancato subito dopo averlo fatto, si può semplicemente svelare un po ‘ di filato e andare avanti. Ma se non si cattura l’errore fino alla fine, potrebbe essere necessario svelare l’intero maglione solo per rifare quel punto.

Se i programmatori software non rilevano la loro omissione fino al test finale del sistema—o peggio, fino a dopo che il sistema è stato implementato—i costi sostenuti per correggere l’errore saranno probabilmente molte volte maggiori rispetto a se avessero colto l’errore mentre stavano ancora lavorando al processo di vendita iniziale.

E a differenza di un punto mancato in un maglione, questo problema è molto più difficile da individuare; i programmatori vedranno solo che compaiono errori e questi potrebbero avere diverse cause. Anche dopo che l’errore originale è stato corretto, dovranno modificare altri calcoli e documentazione e quindi riprovare ogni passaggio.

In effetti, gli studi hanno dimostrato che gli specialisti del software spendono circa il 40-50% del loro tempo su rielaborazioni evitabili piuttosto che su quello che chiamano lavoro a valore aggiunto, che è fondamentalmente un lavoro fatto bene la prima volta. Una volta che un pezzo di software entra in campo, il costo di correggere un errore può essere 100 volte più alto di quanto sarebbe stato durante la fase di sviluppo.

Se gli errori abbondano, la rilavorazione può iniziare a inondare un progetto, come un gommone in una tempesta. Quel che è peggio, i tentativi di correggere un errore spesso ne introducono di nuovi. E ‘ come se stessi salvando quel gommone, ma stai anche creando perdite. Se vengono prodotti troppi errori, il costo e il tempo necessari per completare il sistema diventano così grandi che andare avanti non ha senso.

Nei termini più semplici, un progetto IT di solito fallisce quando la rielaborazione supera il lavoro a valore aggiunto per cui è stato preventivato. Questo è quello che è successo a Sydney Water Corp., il più grande fornitore di acqua in Australia, quando ha tentato di introdurre un sistema automatizzato di informazioni sui clienti e fatturazione nel 2002 . Secondo un’indagine del Revisore generale australiano, tra i fattori che hanno condannato il progetto c’erano una pianificazione e specifiche inadeguate, che a loro volta hanno portato a numerose richieste di modifica e significativi costi e ritardi aggiuntivi. Sydney Acqua interrotto il progetto midway, dopo aver speso AU million 61 milioni (US million 33,2 milioni).

Tutto ciò ci porta alla domanda ovvia: perché si verificano così tanti errori?

I fallimenti del progetto software hanno molto in comune con gli incidenti aerei. Proprio come i piloti non intendono mai andare in crash, gli sviluppatori di software non mirano a fallire. Quando un aereo commerciale si schianta, gli investigatori esaminano molti fattori, come il tempo, i registri di manutenzione, la disposizione e l’addestramento del pilota e fattori culturali all’interno della compagnia aerea. Allo stesso modo, dobbiamo guardare l’ambiente aziendale, la gestione tecnica, la gestione dei progetti e la cultura organizzativa per arrivare alle radici dei guasti del software.

In primo luogo tra i fattori di business sono la concorrenza e la necessità di tagliare i costi. Sempre più spesso, i senior manager si aspettano che i reparti IT facciano di più con meno e lo facciano più velocemente di prima; vedono i progetti software non come investimenti ma come costi puri che devono essere controllati.

Le esigenze politiche possono anche devastare il programma, i costi e la qualità di un progetto IT. Quando l’aeroporto internazionale di Denver ha tentato di stendere il suo sistema automatizzato di bagaglio-trattamento, lo stato ed i capi politici locali hanno tenuto il progetto ad un programma irrealistico dopo un altro. La mancata consegna del sistema in tempo ritardato l’apertura 1995 dell’aeroporto (allora il più grande negli Stati Uniti), che ha aggravato l’impatto finanziario molte volte.

Anche dopo che il sistema è stato completato, non ha mai funzionato in modo affidabile: ha masticato i bagagli e i carrelli utilizzati per trasportare i bagagli sono spesso deragliati. Alla fine, United Airlines, l’inquilino principale dell’aeroporto, ha citato in giudizio l’appaltatore del sistema e l’episodio è diventato una testimonianza dei pericoli dell’opportunità politica.

Una mancanza di supporto di gestione superiore può anche dannare un’impresa IT. Questo va dal non riuscire a destinare abbastanza denaro e manodopera a non stabilire chiaramente il rapporto del progetto IT con il business dell’organizzazione. Nel 2000, rivenditore Kmart Corp., a Troy, Mich., ha lanciato un $1.4 miliardi di IT sforzo di modernizzazione volto a collegare le sue vendite, marketing, fornitura, e sistemi logistici, per meglio competere con la rivale Wal-Mart Corp., a Bentonville, Ark. Wal-Mart si è rivelato troppo formidabile, però, e 18 mesi dopo, Kmart a corto di contanti ha tagliato la modernizzazione, cancellando i million 130 milioni che aveva già investito in ESSO. Quattro mesi dopo, ha dichiarato bancarotta; l’azienda continua a lottare oggi.

Spesso, i project manager IT desiderosi di essere finanziati ricorrono a una forma di liar’s poker, esagerando su cosa farà il loro progetto, quanto costerà e quando sarà completato. Molti, se non la maggior parte, progetti software iniziano con budget troppo piccoli. Quando ciò accade, gli sviluppatori devono compensare in qualche modo il deficit, in genere cercando di aumentare la produttività, riducendo la portata dello sforzo o prendendo scorciatoie rischiose nelle fasi di revisione e test. Tutti questi aumentano la probabilità di errore e, in definitiva, il fallimento.

Un sistema di prenotazione di viaggi all’avanguardia guidato da un consorzio di Budget Rent-A-Car, Hilton Hotels, Marriott e AMR, la controllante di American Airlines, è un esempio calzante. Nel 1992, tre anni e mezzo e 165 milioni di dollari nel progetto, il gruppo lo abbandonò, citando due ragioni principali: un programma di sviluppo eccessivamente ottimistico e una sottovalutazione delle difficoltà tecniche coinvolte. Questo era lo stesso gruppo che in precedenza aveva costruito il sistema di prenotazione Sabre di grande successo, dimostrando che le prestazioni passate non sono garanzia di risultati futuri.

Dopo che gli investigatori di crash considerano il tempo come un fattore in un incidente aereo, guardano l’aereo stesso. C’era qualcosa nel progetto dell’aereo che ha causato l’incidente? Stava portando troppo peso?

Nei fallimenti del progetto IT, domande simili invariabilmente sorgono per quanto riguarda i componenti tecnici del progetto: l’hardware e il software utilizzati per sviluppare il sistema e le pratiche di sviluppo stesse. Le organizzazioni sono spesso sedotte dal canto delle sirene dell’imperativo tecnologico—l’impulso incontrollabile di utilizzare le ultime tecnologie nella speranza di ottenere un vantaggio competitivo. Con la tecnologia che cambia veloce e promettente fantastiche nuove funzionalità, è facile soccombere. Ma l’utilizzo di tecnologie immature o non testate è una strada sicura verso il fallimento.

Nel 1997, dopo aver speso million 40 milioni, lo stato di Washington ha chiuso un progetto IT che avrebbe elaborato le patenti di guida e le immatricolazioni dei veicoli. I funzionari dei veicoli a motore hanno ammesso di essere stati coinvolti nell’inseguire la tecnologia invece di concentrarsi sull’implementazione di un sistema che soddisfacesse le loro esigenze. La debacle IT che ha portato giù il farmaco FoxMeyer un anno prima derivava anche dall’adozione di un sistema di pianificazione delle risorse all’avanguardia e quindi spingendolo oltre ciò che potrebbe fare in modo fattibile.

Le dimensioni di un progetto sono una fonte di fallimento. Gli studi indicano che i progetti su larga scala falliscono da tre a cinque volte più spesso di quelli di piccole dimensioni. Più grande è il progetto, maggiore è la complessità sia nei suoi elementi statici (i pezzi discreti di software, hardware e così via) che nei suoi elementi dinamici (gli accoppiamenti e le interazioni tra hardware, software e utenti; connessioni ad altri sistemi; e così via). Una maggiore complessità aumenta la possibilità di errori, perché nessuno capisce davvero tutte le parti interagenti del tutto o ha la capacità di testarle.

Che fa riflettere ma è vero: è impossibile testare a fondo un sistema IT di qualsiasi dimensione reale. Roger S. Pressman ha sottolineato nel suo libro Software Engineering, uno dei testi classici del settore, che ” test esaustivi presentano alcuni problemi logistici….Anche un piccolo programma di 100 righe con alcuni percorsi nidificati e un singolo ciclo che esegue meno di venti volte può richiedere da 10 alla potenza di 14 possibili percorsi da eseguire.”Per testare tutti quei 100 trilioni di percorsi, ha osservato, supponendo che ciascuno possa essere valutato in un millisecondo, ci vorranno 3170 anni.

Tutti i sistemi IT sono intrinsecamente fragili. In un grande edificio in mattoni, dovresti rimuovere centinaia di mattoni posizionati strategicamente per far crollare un muro. Ma in un programma software di 100 000 linee, ci vogliono solo una o due linee sbagliate per produrre problemi importanti. Nel 1991, una parte della rete telefonica di ATandamp;T è andato fuori, lasciando 12 milioni di abbonati senza servizio, tutto a causa di un singolo carattere digitato male in una riga di codice.

Le pratiche di sviluppo Sloppy sono una ricca fonte di errori e possono causare errori in qualsiasi fase di un progetto IT. Per aiutare le organizzazioni a valutare le loro pratiche di sviluppo software, gli Stati Uniti Software Engineering Institute, a Pittsburgh, ha creato il Capability Maturity Model, o CMM. Valuta le pratiche di un’azienda rispetto a cinque livelli di crescente maturità. Livello 1 significa che l’organizzazione utilizza pratiche di sviluppo ad hoc e possibilmente caotiche. Livello 3 significa che l’azienda ha caratterizzato le sue pratiche e ora le comprende. Livello 5 significa che l’organizzazione comprende quantitativamente le variazioni nei processi e nelle pratiche che applica.

A partire da gennaio, quasi 2000 organizzazioni governative e commerciali avevano segnalato volontariamente livelli di CMM. Oltre la metà ha riconosciuto di essere a livello 1 o 2, 30 per cento erano a livello 3, e solo 17 per cento aveva raggiunto il livello 4 o 5. Le percentuali sono ancora più tristi quando ti rendi conto che questo è un gruppo auto-selezionato; ovviamente, le aziende con le peggiori pratiche IT non si sottoporranno a una valutazione CMM. (La CMM viene sostituita dalla CMM-Integration, che mira a una valutazione più ampia della capacità di un’organizzazione di creare sistemi ad alta intensità di software.)

Le pratiche IT immature hanno condannato gli Stati Uniti. Internal Revenue Service effort 4 miliardi di sforzo di modernizzazione nel 1997, e hanno continuato ad affliggere l’attuale modernization 8 miliardi di modernizzazione dell’IRS. Potrebbe essere intrinsecamente impossibile tradurre il codice fiscale in codice software: la legge fiscale è complessa e si basa su una legislazione spesso vaga e cambia continuamente. Dal punto di vista di uno sviluppatore IT, è un incubo requisiti. Ma l’IRS non è stato aiutato da aperta ostilità tra programmatori interni ed esterni, una ridicola sottovalutazione del lavoro coinvolto e molte altre cattive pratiche.

LE AZIONI DEL PILOTA POCO PRIMA che un aereo si schianti sono sempre di grande interesse per gli investigatori. Questo perché il pilota è l’ultimo decisore, responsabile del funzionamento sicuro dell’imbarcazione. Allo stesso modo, i project manager svolgono un ruolo cruciale nei progetti software e possono essere una delle principali fonti di errori che portano al fallimento.

Nel 1986, la Borsa di Londra decise di automatizzare il suo sistema di regolamento delle transazioni azionarie. Sette anni dopo, dopo aver speso 600 milioni di dollari, ha demolito lo sviluppo del sistema Taurus, non solo perché il design era eccessivamente complesso e ingombrante, ma anche perché la gestione del progetto era, per usare la parola di uno dei suoi dirigenti, “delirante.”Come le indagini hanno rivelato, nessuno sembrava voler conoscere il vero stato del progetto, anche se sono comparsi sempre più problemi, le scadenze sono mancate e i costi sono aumentati .

La funzione più importante del project manager IT è quella di allocare risorse a varie attività. Oltre a ciò, il project manager è responsabile della pianificazione e stima del progetto, del controllo, dell’organizzazione, della gestione dei contratti, della gestione della qualità, della gestione dei rischi, delle comunicazioni e della gestione delle risorse umane.

Le decisioni sbagliate dei project manager sono probabilmente la principale causa di errori software oggi. Una cattiva gestione tecnica, al contrario, può portare a errori tecnici, ma questi possono generalmente essere isolati e corretti. Tuttavia, una cattiva decisione di gestione del progetto—come assumere troppo pochi programmatori o scegliere il tipo sbagliato di contratto-può devastare. Ad esempio, gli sviluppatori del sistema di prenotazione del viaggio condannato affermano di essere stati zoppicati in parte dall’uso di un contratto a prezzo fisso. Tale contratto presuppone che il lavoro sarà di routine; il sistema di prenotazione si è rivelato tutt’altro.

Le decisioni di gestione dei progetti sono spesso complicate proprio perché implicano compromessi basati su conoscenze sfocate o incomplete. Stimare quanto costerà un progetto IT e quanto tempo ci vorrà è tanto arte quanto scienza. Più grande o più nuovo è il progetto, meno accurate sono le stime. È uno scherzo in esecuzione nel settore che le stime del progetto IT sono al meglio entro il 25 percento del loro vero valore il 75 percento delle volte.

Ci sono altri modi in cui una cattiva gestione del progetto può accelerare la scomparsa di un progetto software. Uno studio del Project Management Institute, in Newton Square, Pa., ha mostrato che la gestione del rischio è la meno praticata di tutte le discipline di gestione del progetto in tutti i settori industriali, e da nessuna parte è più raramente applicata che nel settore IT. Senza un’efficace gestione del rischio, gli sviluppatori di software hanno poche informazioni su cosa potrebbe andare storto, perché potrebbe andare storto e cosa si può fare per eliminare o mitigare i rischi. Né c’è un modo per determinare quali rischi sono accettabili, a sua volta rendendo le decisioni di progetto per quanto riguarda i compromessi quasi impossibili.

La cattiva gestione del progetto assume molte altre forme, tra cui una cattiva comunicazione, che crea un’atmosfera inospitale che aumenta il fatturato; non investe nella formazione del personale; e non rivede i progressi del progetto a intervalli regolari. Ognuno di questi può aiutare a far deragliare un progetto software.

L’ultima area che gli investigatori esaminano dopo un incidente aereo è l’ambiente organizzativo. La compagnia aerea ha una forte cultura della sicurezza, o enfatizza soprattutto il rispetto dell’orario di volo? Nei progetti IT, un’organizzazione che valorizza l’apertura, l’onestà, la comunicazione e la collaborazione è più adatta a trovare e risolvere gli errori abbastanza presto che la rielaborazione non diventi travolgente.

Se c’è un tema che attraversa la storia torturata del cattivo software, è un fallimento per affrontare la realtà. In numerose occasioni, l’ispettore generale del Dipartimento di Giustizia degli Stati Uniti, un gruppo di esperti esterni e altri dissero al capo dell’FBI che il sistema VCF era impossibile come definito, eppure il progetto continuò comunque. Gli stessi atteggiamenti esistevano tra i responsabili del sistema di prenotazione dei viaggi, del sistema Taurus della Borsa di Londra e del progetto di controllo del traffico aereo della FAA, tutti indicativi di culture organizzative guidate dalla paura e dall’arroganza.

Un recente rapporto del National Audit Office nel Regno Unito ha rilevato che numerosi casi di progetti informatici governativi sono stati raccomandati di non andare avanti ancora continuando comunque. Il Regno Unito ha anche un dipartimento governativo incaricato di prevenire i fallimenti IT, ma come ha osservato il rapporto, più della metà delle agenzie che il dipartimento supervisiona abitualmente ignorano i suoi consigli. Chiamo questo tipo di comportamento escalation del progetto irrazionale—l’incapacità di fermare un progetto anche dopo che è ovvio che la probabilità di successo si sta rapidamente avvicinando a zero. Purtroppo, tale comportamento non è in alcun modo unico.

In ultima analisi , i grandi guasti del software tendono ad assomigliare al peggiore incidente aereo immaginabile, in cui il pilota era inesperto ma estremamente avventato, volava in una tempesta di ghiaccio in un aereo non testato e lavorava per una compagnia aerea che ha dato un servizio a parole alla sicurezza riducendo l’addestramento e la manutenzione. Se leggi il rapporto dell’investigatore dopo, scuoteresti la testa e chiederesti:”Non era inevitabile un simile incidente?”

Così, anche, i motivi che i progetti software falliscono sono ben noti e sono stati ampiamente documentati in innumerevoli articoli, rapporti e libri . Eppure, fallimenti, quasi-fallimenti, e pianura vecchio cattivo software continuano ad affliggerci, mentre le pratiche noti per evitare gli errori sono evitati. Sembrerebbe che ottenere software di qualità in tempo e all’interno del budget non sia una priorità urgente nella maggior parte delle organizzazioni.

Non sembrava essere a Oxford Health Plans Inc., a Trumbull, Conn., nel 1997. Il sistema di fatturazione automatizzato della società era vitale per la sua linea di fondo, eppure i senior manager erano più interessati ad espandere l’attività di Oxford che a garantire che il suo sistema di fatturazione potesse soddisfare le sue attuali esigenze . Anche se sono sorti problemi, come l’invio delle fatture con mesi di ritardo, i gestori hanno prestato poca attenzione. Quando il sistema di fatturazione è effettivamente crollato, la società ha perso decine di milioni di dollari e le sue azioni sono scese da $68 a $26 per azione in un giorno, cancellando out 3,4 miliardi di valore aziendale. Gli azionisti hanno intentato cause legali e diverse agenzie governative hanno indagato sulla società, che alla fine è stata multata di million 3 milioni per violazioni normative.

Anche le organizzazioni che vengono bruciate da cattive esperienze software sembrano incapaci o non vogliono imparare dai loro errori. In un rapporto del 2000, il Defense Science Board degli Stati Uniti, un organo consultivo del Dipartimento della Difesa, ha osservato che vari studi commissionati dal DOD avevano formulato 134 raccomandazioni per migliorare il suo sviluppo software, ma solo 21 di queste raccomandazioni erano state applicate. Gli altri 113 erano ancora validi, ha osservato il consiglio, ma venivano ignorati, anche se il DOD si lamentava del cattivo stato di sviluppo del software di difesa!

Alcune organizzazioni si preoccupano della qualità del software, come dimostra l’esperienza della società di sviluppo software Praxis High Integrity Systems, a Bath, in Inghilterra. Praxis richiede che i suoi clienti siano impegnati nel progetto, non solo finanziariamente, ma come partecipanti attivi nella creazione del sistema IT. L’azienda dedica inoltre una quantità enorme di tempo a comprendere e definire le esigenze del cliente e sfida i clienti a spiegare cosa vogliono e perché. Prima di scrivere una singola riga di codice, sia il cliente che la prassi concordano su ciò che è desiderato, ciò che è fattibile e quali rischi sono coinvolti, date le risorse disponibili.

Successivamente, Praxis applica un approccio di sviluppo rigoroso che limita il numero di errori. Uno dei grandi vantaggi di questo modello è che filtra i molti aspiranti clienti non disposti ad accettare la responsabilità di articolare i loro requisiti IT e spendere tempo e denaro per implementarli correttamente.

Un certo livello di guasto del software sarà sempre con noi. Infatti, abbiamo bisogno di veri fallimenti-al contrario di errori evitabili-per continuare a fare progressi tecnici ed economici. Ma troppi dei fallimenti che si verificano oggi sono evitabili. E mentre la nostra società si affida a sistemi IT sempre più grandi, più integrati e più costosi, il costo del fallimento potrebbe diventare disastrosamente alto.

Anche ora, è possibile scommettere su dove si verificherà la prossima grande debacle del software. Uno dei miei candidati principali è i sistemi IT che deriveranno dalla comunità di informazioni sanitarie americane del governo degli Stati Uniti, una collaborazione pubblico-privata che cerca di definire gli standard di dati per le cartelle cliniche elettroniche. L’idea è che una volta definiti gli standard, i sistemi IT saranno costruiti per consentire ai professionisti medici di tutto il paese di accedere digitalmente alle cartelle cliniche dei pazienti, offrendo a medici, ospedali, assicuratori e altri specialisti sanitari l’accesso immediato alla storia medica completa di un paziente. Gli esperti sanitari ritengono che un tale sistema di sistemi migliorerà la cura del paziente, tagli i costi di circa 78 miliardi di dollari all’anno e ridurrà gli errori medici, salvando decine di migliaia di vite.

Ma questo approccio è un semplice sogno irrealizzabile se le pratiche software e i tassi di fallimento rimangono come sono oggi. Anche secondo le stime più ottimistiche, per creare un sistema di cartelle cliniche elettroniche saranno necessari 10 anni di sforzi, costs 320 miliardi di costi di sviluppo e billion 20 miliardi all’anno di spese operative—supponendo che non ci siano guasti, sforamenti, slittamenti di programma, problemi di sicurezza o software scadente. Questo non è certo uno scenario realistico, soprattutto perché la maggior parte degli esperti IT considerano la comunità medica di essere il meno esperto di computer di tutte le imprese professionali.

Pazienti e contribuenti alla fine pagheranno il prezzo per lo sviluppo, o il fallimento, di boondoggles come questo. Date le pratiche IT di oggi, il fallimento è una possibilità distinta, e sarebbe una perdita di portata senza precedenti. Ma poi, i paesi di tutto il mondo stanno contemplando o già al lavoro su molte iniziative di dimensioni e impatto simili—nell’aviazione, nella sicurezza nazionale e nell’esercito, tra le altre arene.

Come l’elettricità, l’acqua, i trasporti e altre parti critiche della nostra infrastruttura, sta rapidamente diventando intrinseca alla nostra esistenza quotidiana. In pochi decenni, un fallimento IT su larga scala diventerà più di un semplice inconveniente costoso: mettera ‘ a rischio il nostro modo di vivere. In assenza del tipo di cambiamenti a livello industriale che attenueranno i guasti del software, quanto del nostro futuro siamo disposti a scommettere su questi sistemi enormemente costosi e complessi?

Sappiamo già come fare bene il software. Potrebbe finalmente essere il momento di agire su ciò che sappiamo.