Animiert durch einen Bericht über den Absturz von AA1420 (1999) bei PRO7 frage ich mich, ob es nicht auch in Projekten zur “Get-There-Weakness” kommt. Der Zwang das Ziel erreichen zu wollen.

Im Falle von AA1420 hat eine Schlechtwetterfront die Landung auf dem Flughafen Little Rock nahezu unmöglich gemacht. Die Piloten wurden besonders stark gefordert. Als die Außenbedingungen durch ein Gewitter über dem Flughafen die Grenzwerte nicht nur meßbar sondern auch sichtbar und spürbar überschritten setzten sie trotzdem den Landeanflug fort. Das Ergebnis: 11 Tote. Letztlich unfallentscheidend war, dass die Spoiler (eine Bremseinrichtung) nicht beim Aufsetzen der Maschine gezogen wurden. Dies gehört zu einer Routinetätigkeit.

Aus den Untersuchungen zu diesem Unfall geht man davon aus, dass die Piloten nicht umkehren wollten, sondern das Ziel (=Landung in Little Rock) direkt vor Augen hatten und dieses strikt verfolgten.

Übertragen wir dies einmal in ein Softwareprojekt (=Flug). Das Ziel ist es eine Anwendung mit gesetztem Budget (=Treibstoff) zu einem gesetzem Zeitpunkt(=Landeplatz) fertigzustellen. Im Laufe des Projektes ergeben sich nun Schwierigkeiten, wie eine fehlende technische Infrastruktur (=Sackwinde) oder fehlende organisatorische Veränderungen (=Sturmfront). Diese müssen von der Projektleitung (=Pilot) oder durch einen Change Agenten (=1. Offizier) gemeistert werden. Wie es sich für ein Projektkontrolling gehört wird die volle Aufmerksamkeit (=Gegensteuern) in die Lösung dieser Schwierigkeiten(=Seitenwinde/Kursabweichung) gesteckt.

Auch wenn diese Schwierigkeiten gemeistert werden, scheitert das Projekt dennoch, da eine Kleinigkeit wie zum Beispiel Unit-Tests vergessen wurde. Am Ende zerschellt das Projekt auf Grund fehlerhafter interner Interfaces oder Module, diese hätten mit einem Unit-Test erkannt werden können.

Die Untersuchung von AA1420 nannte die Unfallursache:
Menschliches Versagen auf Grund eines “Get-There-Weakness”.