Projekte
Ambitionierte IT-Großprojekte sind vom Start weg fehlerbehaftet. 30 bis 70 Prozent von ihnen gehen schief. Die Branche ist übersät mit schlechten Beispielen (siehe auch die nachfolgende Bilderstrecke). Wie die Standish Group in ihrem letztjährigen CHAOS Report schrieb, wird jedes vierte IT-Projekt gar nicht erst abgeschlossen, weil es nicht mehr zu retten ist – die Kosten gehen in die Milliarden.
- Fehlerhafte Hartz IV Software (2004)
Zum Start der Arbeitsmarktreform Hartz IV streikte die Software, die die das Arbeitslosengeld für Langzeitarbeitslose berechnete. Die von T-Systems entwickelter Anwendung "A2LL" lief nicht stabil und löste Rechnerabstürze aus. <br /><br />Zudem wurden Zuschläge falsch berechnet, Datenfelder fehlten oder waren für die Erfassung gesperrt. Außerdem kam es bei der Berechnung der Krankenversicherungsbeiträge zu Rundungsfehlern. <br /><br />Später wurde bekannt, dass eine nach gelagerte Software kurze Kontennummern falsch auffüllte. Statt Nullen voranzustellen, wurden sie hinten angehängt. Dadurch waren Konten nicht zuzuordnen. <br /><br /><a href="http://www.computerwoche.de/nachrichtenarchiv/549354/" target="_blank">Fehlerhafte Software bedroht Hartz-IV-Start</a> - Hartz-IV-Softwarepanne, die Zweite (2006)
Im Dezember 2006 streikte die Software erneut, eine Bearbeitung von Erst- und Fortzahlungsanträgen für das Arbeitslosengeld 2 (ALG2) war nicht mehr möglich. Die Probleme tauchten auf, nachdem ein Update eingespielt wurde, hieß es zunächst. <br /><br />T-Systems wehrte sich allerdings gegen den Vorwurf, eine fehlerhaft implementierte Dialog-Software sei der Grund für die Pannenserie. Vielmehr sei das Problem durch ein Datenbank-Update hervorgerufen worden, betonte die Telekom-Tochter. <br /><br /><a href="http://www.computerwoche.de/nachrichtenarchiv/585325/" target="_blank">Probleme mit Hartz-IV-Software</a> - EDS und die britische Kindergeld-Behörde (2004)
Der US-amerikanische IT-Dienstleister scheitert 2004 spektakulär in Großbritannien und bescherte dem Steuerzahler einen Verlust von etwa einer Milliarde Pfund. <br /><br />EDS war beauftragt worden, für die britische Behörde Child Support Agency (CSA), die das Kindergeld auszahlt, ein neues IT-System zu entwickeln, dass das Verfahren beschleunigt. <br /><br />Die implementierte Lösung CS2 überwies etwa 1,9 Millionen Berechtigten zuviel Geld, rund 700 000 bekamen allerdings zu wenig. Grund dafür war nicht allein die Software, denn zeitgleich hatte die britische Regierung die CSA reformiert. Update zwang die Software in die Knie. - Die Explosion der Ariane 5 (1996)
Innerhalb von Sekunden zerbarst im 1996 Europas ehrgeizige Ariane-5-Mission. Die unbemannte Rakete explodierte 30 Sekunden nach dem Start vom Weltraumbahnhof Kourou in Französisch-Guayana, nachdem sie zuvor von ihrem Kurs abgekommen war. An Bord waren vier Satelliten im Wert von 500 Millionen Dollar. <br /><br />Später veröffentlichte die New York Times den Grund für die Panne. Die Ariane 5 nutzte die gleiche und bewährte Software wie ihr Vorgängermodell, die Ariane 4. Die neue Trägerrakete war jedoch schneller und konnte eine größere Nutzlast transportieren, dadurch fielen deutlich mehr und höhere Flugdaten an, die verarbeitet werden mussten. <br /><br />Letzten Endes löste die Umwandlung von Gleitkommazahlen in ganzzahlige Werte einen Overflow aus und setzte damit eine Fehlerkette in Gang. Das redundante System der Ariane 5 konnte die Katastrophe nicht verhindern. Es nutzte die gleiche Software. - Panne in der Entwicklung des Airbus A380 (2006)
Die verteilte Fertigung bei Airbus brachte es mit sich, dass in verschiedenen Werken unterschiedliche Software verwendet wurde. Peinlich wurde dies, als die Werke unterschiedliche Versionen der CAD-Software Catia verwendeten. <br /><br />In Hamburg arbeiteten die Ingenieure mit einer älteren Version, im französischen Toulouse kam die aktuellste Ausführung zum Einsatz, die allerdings nicht abwärtskompatibel war. Als die an den jeweiligen Standorten entwickelten und gefertigten Teile zusammengeführt werden sollten, passten die Verkabelungsbäume nicht zueinander. <br /><br />Die Auslieferung des Airbus verzögerte sich um acht Monate. - Das Jahr-2000-Problem (1999/2000)
Für die IT-Industrie wurde der Jahrtausendwechsel zum großen Fest. Sie verdiente prächtig an einem Fehler (beziehungsweise einer Unzulänglichkeit), den sie selbst mitverursacht hatte. <br /><br />Weil in den frühen Jahren der IT Speicherplatz teuer war, wurden Jahreszahlen nur zweistellig dargestellt. Die Zahlenkombination "00" bezeichnete also sowohl das Jahr 1900 als auch das Jahr 2000. Zum Teil wurde auch ungültige Datensätze mit der Doppelnull gefüllt. <br /><br />Viele Anwenderunternehmen fürchteten finanziellen Schaden aufgrund falscher Berechnungen. Zudem drohten Computerabstürze und Sicherheitslecks in Anwendungen von Banken, Industrieanlagen und Kernkraftwerken. - Millionengrab Fiscus (1993 bis 2005)
Zum Fass ohne Boden entwickelte sich das Föderale Integrierte Standardisierte Computer-Unterstützte Steuersystem (Fiscus). Mehr als zwölf Jahre strebten die deutschen Bundesländer an, eine einheitliche Steuersoftware für rund 650 Finanzämter einzuführen. Dafür verbrauchten sie geschätzte 900 Millionen Euro. <br /><br />Ein brauchbares Ergebnis kam nicht dabei heraus. Die Anfänge nahm Fiscus im Jahr 1993. Die Bundesländer wollten die parallele Entwicklung mehrerer Lösungen zentralisieren, um Kosten zu sparen. Zudem sollten die ausufernden Altsysteme durch eine neue, moderne Applikation ersetzt werden. <br /><br />Während der Entwicklungsarbeiten wurden mehrfach die technischen Zielrichtungen verändert (etwa von der strukturierten zur objektorientierten Entwicklung). <br /><br />Schwierigkeiten bereitete zudem das Kompetenzgerangel zwischen den Bundesländern. 2005 wurde die eigens für das Projekt gegründete Fiscus GmbH liquidiert und das neue Projekt "Konsens" gestartet. <br /><br /><a href=" http://www.computerwoche.de/it_strategien/it_management/599350/index2.html" target="_blank"> Von Fiscus zu Konsens: Ein langer Weg geht zu Ende </a> - Hessens Desaster mit der Schulsoftware (2007)
Das Bundesland Hessen erlebte mit der Einführung der neuen Schulverwaltungssoftware LUSD (Lehrer- und Schülerdatenbank) ein Desaster. <br /><br />Ziel der Software war eine zentrale Verwaltung aller Schüler und Lehrerdaten. Mit der Implementierung in den Schulen startete der beauftragte IT-Dienstleister CSC im Oktober 2006. Zur Eskalation kam es im Herbst 2007 als die betroffenen Schulsekretariate sich über anhalten Performance-Probleme beschwerten und sich die Mängel zum Politikum entwickelten. <br /><br />Ursache der Leistungsprobleme war offenbar eine nicht sauber implementierte 3-Tier-Architektur aus Web-Client, Application- und Datenbank-Server. Im Lauf des Entwicklungsprojekts wurde Prozess- beziehungsweise Business-Logik auf dem Datenbank-Server statt auf dem Application-Server abgebildet.
"Schlechtes Projekt-Management ist mit der größte Kostenpunkt in Unternehmen", so Chris Stephenson, Partner beim Beratungsunternehmen Arryve. Warum? Weil sich Projekterfolge und -misserfolge nicht (richtig) messen lassen und das Management nicht mitzieht: "Viel zu oft, werden IT-Projekte produktives Zutun der einzelnen Abteilungen vom Business zu den Entwicklern zu den Testern bis in den Livebetrieb durchgereicht. Niemand, der das spätere Produkt einsetzen soll, wird um Rat gefragt – jeder macht sein eigenes Ding, womit viel Arbeit doppelt und dreifach anfällt und immer auf andere Art und Weise ausgelegt wird", so Stephenson.
Er schätzt, dass die Zeit bis zur Fertigstellung von Projekten, die so und nicht den Regeln nach verschiedene Phasen durchlaufen, doppelt so lang ist wie bei Projekten, in denen von Anfang an alle Beteiligten mit einbezogen werden. Die Kosten seien entsprechend auch doppelt so hoch – außerdem liefen solche Projekte große Gefahr, niemals im Unternehmen angenommen zu werden.
Die Kosten für ein Projekt berechnen sich nicht in erster Linie aus den Ausgaben für die eingesetzte Soft- oder Hardware, sondern aus den Kosten für den Mitarbeiter, der seine Zeit mit einem Projekt verbringt. "Unternehmen müssen herausfinden, welche ihrer laufenden Projekte riskant sind und Gefahr laufen, im Desaster zu enden", rät Curt Finch, CEO des Online-Dienstleisters Journyx, der unter anderem Web-basierende Zeiterfassungssysteme anbietet.
"Am besten geht das, indem geschaut wird, wie viel Zeit die Mitarbeiter in bestimmten Projekten verbringen. Gleichzeitig ist zu prüfen, wie weit diese Projekte vorangeschritten sind. Wenn ein Projekt beispielsweise 1000 Personenstunden vorsieht und davon bereits die Hälfte verbraucht wurde, das Projekt aber nur zu 15 Prozent fertig gestellt ist, haben sie in den meisten Fällen ein Hochrisiko-Projekt vor sich – und damit ein Problem."
Um diese bodenlosen Fässer erst gar nicht ins Haus zu lassen, reicht es oft schon, nur den gesunden Menschenverstand einzuschalten. Finch rät Unternehmen: Beginnen Sie niemals mit Projekten, von denen Sie wissen, dass Sie sie nicht abschließen können (so sehr Sie es auch wollen). Starten Sie auch keine drei Projekte gleichzeitig, wenn Ihre Ressourcen nur für die Bearbeitung eines einzigen reichen.
Prüfen Sie fortlaufend den Projektfortschritt und den eingebrachten Arbeitsaufwand. Projektmitarbeiter sollten zu regelmäßigen Statusupdates angehalten sein, die der Wahrheit entsprechen und Projektrückstände klar benennen dürfen, ohne persönliche Konsequenzen fürchten zu müssen. "Wenn ein Projekt in Schieflage gerät, das Management das Projekt aber für wichtig hält, sollten weitere Ressourcen dafür freigesetzt werden und nicht sofort die Köpfe rollen."
Dieser Artikel stammt von Dan Tynan von unserer US-Schwesterpublikation Infoworld. (cm)