Nel settembre del 1999 la sonda Mars Climate Orbiter si è schiantata sul pianeta Marte a causa di una mancata conversione di unità di misura tra diverse parti del software che controllava la sua traiettoria.
Le successive indagini rivelarono che sarebbe stato troppo semplicistico attribuire il fallimento della missione solo a questa clamorosa svista. L’errore più grave non fu tanto quello della mancata conversione tra le unità di misura, ma l’incapacità di trovare e correggere questo errore che fu causato da alcune scelte imprudenti nel modo in cui la missione fu gestita.
Dalla storia di questo fallimento potremo ricavare alcune importanti lezioni di project management.
La missione
Il Mars Climate Orbiter fu lanciato l’11 dicembre del 1998 da Cape Canaveral in Florida. Assieme con la missione Mars Polar Lander, la sonda faceva parte di un progetto per lo studio dell’atmosfera e del clima di Marte.
In particolare il Mars Climate Orbiter era stato progettato per monitorare l’evoluzione delle condizioni meteo giornaliere, per studiare la distribuzione dell’acqua sul suolo e nell’atmosfera e per misurare la temperatura dell’atmosfera.
Il 23 settembre del 1999 la sonda iniziò le ultime manovre per entrare in orbita attorno a Marte.
La sonda avrebbe dovuto passare dietro al pianeta per cui si sapeva che ci sarebbe stato una temporanea perdita del contatto radio. Accadde però che il segnale si interruppe con 49 secondi di anticipo rispetto al previsto e non fu mai più ristabilito.
Le cause dell’insuccesso
Le indagini che seguirono chiarirono che la navicella era molto più vicina Marte rispetto alla traiettoria programmata, così vicino da essere distrutto dall’attrito con l’atmosfera marziana.
Perché la sonda era così vicina a Marte?
Una parte del software di controllo della traiettoria era stato sviluppato dalla ditta Lockheed Martin e calcolava un risultato numerico in unità britanniche. Questi valori venivano inviati a un’altra parte del software sviluppata dalla NASA che le interpretava invece come se fossero espresse in unità del sistema internazionale.
Per la precisione il software sviluppato dalla Lockheed Martin passava una impulso misurato in libbre $\times$ secondo al software sviluppato dalla NASA che lo interpretava come se fossero stati newton $\times$ secondo.
Il risultato fu che invece che trovarsi a una distanza di 226 km dal pianeta, la sonda si trovò a soli 57 km.
In aggiunta a questo problema delle unità di misura ci furono molti altri fattori che condussero a questo risultato disastroso.
Solo alcuni mesi prima, in aprile, fu corretto un errore nel programma di gestione della traiettoria. A quel punto c’era la massima urgenza nell’usare questa correzione nella missione. Questo voleva dire che non c’era tempo per svolgere dei test completi sul nuovo codice.
Alcuni membri del gruppo di controllo della traiettoria notarono alcuni segnali che potevano indicare una errata posizione della sonda. Anche se condivisero le loro preoccupazioni in alcune riunioni non segnalarono il fatto seguendo le procedure standard.
Il gruppo di lavoro stava seguendo tre diverse missioni allo stesso tempo e a causa di tagli nel budget non era stato adeguatamente formato.
Dall’altro lato della medaglia i project manager pretendevano di avere una prova certa che ci fosse qualcosa che stava andando storto quando, a causa delle incertezze nella traiettoria, non era nemmeno possibile dimostrare che tutto stesse andando per il verso giusto.
A causa di queste incertezze sulla posizione della sonda il gruppo di lavoro ipotizzò anche la possibilità di una correzione preventiva della traiettoria. Sembra che i project manager decisero di non effettuare la manovra fidandosi delle opinioni più ottimistiche e in ogni caso non era chiaro chi avrebbe dovuto prendere la decisione di effettuare la correzione.
Le 6 lezioni
Questo caso dovrebbe essere studiato dai project manager per capire come le cose possono andare terribilmente male quando si affrontano progetti grandi e ambiziosi.
In particolare, ci sono 6 lezioni importanti:
- I test integrati sono fondamentali. In un progetto dalle grandi dimensioni non è sufficiente testare separatamente le varie componenti di una macchina, di uno strumento o di un software. È cruciale svolgere approfonditi test di come i componenti interagiscono tra loro. Non si può risparmiare sui test, la mancata segnalazione di un problema può compromettere tutto il progetto.
- Più complesso è il progetto, più è necessario curare la comunicazione tra i gruppi di lavoro. Nei grandi progetti è difficile avere una visione globale di quello che sta succedendo. Per evitare inconsistenze è essenziale che le informazioni siano condivise tra tutti i gruppi coinvolti.
- Le opinioni controcorrente devono essere valutate con attenzione. Non è bello sentirsi dire che qualcosa potrebbe andare molto male, ma i project manager dovrebbero avere una preparazione tecnica sufficiente per riconoscere quando il dissenso è solo una questione di pignoleria o quando è supportata da motivazioni razionali.
- Considerare sia i segnali positivi che i segnali negativi con la stessa dose di spirito critico. Bisogna cercare di raccogliere in modo oggettivo più informazioni possibili riguardo ad una questione, indipendentemente dal suo impatto positivo o negativo e pretendere la stessa accuratezza dalle persone che sostengono tesi ottimistiche o pessimistiche.
- In situazioni di incertezza attuare tutte le misure a disposizione per ridurre i rischi. Le incertezze sulla posizione della sonda suggerivano di svolgere per prudenza una ultima correzione della traiettoria. Questa scelta non avrebbe in ogni caso messo in pericolo la missione per cui non c’era motivo per non farla.
- A ogni passo del progetto ci deve essere totale chiarezza sui ruoli decisionali. Il rischio nell’affrontare grandi progetti è che le responsabilità siano in qualche modo distribuite su diversi gruppi e persone per cui tutti pensano che sarà qualcun’altro a prendere una particolare decisione.
Per una analisi ricca di dettagli sull’incidente del Mars Climate Orbiter potete leggere (se masticate un po’ di inglese) questo interessante articolo di James Oberg scritto per la rivista che si occupa di ingegneria Spectrum IEEE.
