Haben Sie den über das verschwindende Lager gehört? Eines Tages verschwand es – nicht aus physischer Sicht, sondern aus den wachsamen Augen des automatisierten Vertriebssystems eines bekannten Einzelhändlers. Ein Softwarefehler hatte irgendwie die Existenz des Lagers ausgelöscht, so dass Waren, die für das Lager bestimmt waren, an einen anderen Ort umgeleitet wurden, während Waren im Lager schmachteten. Da das Unternehmen in finanziellen Schwierigkeiten war und andere Lagerhäuser geschlossen hatte, um Geld zu sparen, schwiegen die Mitarbeiter des „fehlenden“ Lagers. Drei Jahre lang ist nichts angekommen oder gegangen. Die Mitarbeiter erhielten jedoch immer noch ihre Gehaltsschecks, da ein anderes Computersystem die Gehaltsabrechnung abwickelte. Als die Software-Panne schließlich ans Licht kam, Die Waren im Lager wurden verkauft, und das obere Management sagte den Mitarbeitern, sie sollten nichts über die Episode sagen.

Diese Geschichte bewegt sich seit 20 Jahren in der Informationstechnologiebranche. Es ist wahrscheinlich apokryph, aber für diejenigen von uns in der Branche ist es völlig plausibel. Warum? Weil Episoden wie diese die ganze Zeit passieren. Im vergangenen Oktober musste beispielsweise der britische Lebensmitteleinzelhändler J Sainsbury PLC seine Investition in ein automatisiertes Supply-Chain-Management-System in Höhe von 526 Millionen US-Dollar abschreiben. Es scheint, dass Waren in den Depots und Lagern des Unternehmens stecken blieben und nicht in viele seiner Geschäfte gelangten. Sainsbury war gezwungen, etwa 3000 zusätzliche Angestellte einzustellen, um seine Regale manuell zu lagern .

Dies ist nur eines der neuesten in einer langen, düsteren Geschichte von IT-Projekten, die schief gelaufen sind . Die meisten IT-Experten sind sich einig, dass solche Ausfälle weitaus häufiger auftreten, als sie sollten. Darüber hinaus sind die Misserfolge allgemein unvoreingenommen: Sie passieren in jedem Land; in großen und kleinen Unternehmen; in kommerziellen, gemeinnützigen und staatlichen Organisationen; und ohne Rücksicht auf Status oder Reputation. Die geschäftlichen und gesellschaftlichen Kosten dieser Misserfolge — in Form von verschwendeten Steuerzahler- und Aktionärsdollar sowie Investitionen, die nicht getätigt werden können – gehen jetzt weit in die Milliarden von Dollar pro Jahr.

Das Problem wird nur schlimmer, wenn ES allgegenwärtig wird. In diesem Jahr werden Organisationen und Regierungen weltweit schätzungsweise 1 Billion US-Dollar für IT-Hardware, -Software und -Dienstleistungen ausgeben. Von den initiierten IT-Projekten werden 5 bis 15 Prozent vor oder kurz nach der Auslieferung als hoffnungslos unzureichend aufgegeben. Viele andere werden spät und über dem Budget ankommen oder massive Nacharbeiten erfordern. Mit anderen Worten, nur wenige IT-Projekte sind wirklich erfolgreich.

Die größte Tragödie ist, dass Softwarefehler größtenteils vorhersehbar und vermeidbar sind. Leider sehen die meisten Organisationen die Verhinderung von Fehlern nicht als dringende Angelegenheit an, obwohl diese Ansicht das Risiko birgt, die Organisation zu schädigen und vielleicht sogar zu zerstören. Zu verstehen, warum diese Haltung anhält, ist nicht nur eine akademische Übung; Es hat enorme Auswirkungen auf Wirtschaft und Gesellschaft.

SOFTWARE IST ÜBERALL. Es ist, was uns Bargeld von einem Geldautomaten bekommen lässt, einen Anruf tätigen und unsere Autos fahren. Ein typisches Mobiltelefon enthält jetzt 2 Millionen Zeilen Softwarecode; Bis 2010 wird es wahrscheinlich 10 mal so viele haben. General Motors Corp. schätzungen zufolge werden die Autos bis dahin jeweils 100 Millionen Codezeilen haben.

Das durchschnittliche Unternehmen gibt etwa 4 bis 5 Prozent des Umsatzes für Informationstechnologie aus, wobei diejenigen, die stark von der IT abhängig sind — wie Finanz— und Telekommunikationsunternehmen – mehr als 10 Prozent dafür ausgeben. Mit anderen Worten, es ist jetzt eine der größten Unternehmensausgaben außerhalb der Mitarbeiterkosten. Ein Großteil dieses Geldes fließt in Hardware- und Software-Upgrades, Softwarelizenzgebühren usw., aber ein großer Teil davon fließt in neue Softwareprojekte, die eine bessere Zukunft für das Unternehmen und seine Kunden schaffen sollen.

Auch Regierungen sind große Konsumenten von Software. Im Jahr 2003 hatte das Vereinigte Königreich mehr als 100 große IT-Projekte der Regierung im Gange, die sich auf insgesamt 20,3 Milliarden US-Dollar beliefen. Im Jahr 2004 katalogisierte die US-Regierung 1200 zivile IT-Projekte, die mehr als 60 Milliarden US-Dollar kosteten, plus weitere 16 Milliarden US-Dollar für militärische Software.

Jedes dieser Projekte kann über 1 Milliarde Dollar kosten. Um zwei aktuelle Beispiele zu nennen: Die Computermodernisierungsbemühungen im US-Veteranenministerium werden voraussichtlich 3,5 Milliarden US-Dollar kosten, während die Automatisierung der Gesundheitsakten des britischen National Health Service voraussichtlich mehr als 14,3 Milliarden US-Dollar für die Entwicklung und weitere 50,8 Milliarden US-Dollar für die Bereitstellung kosten wird.

Solche Megasoftware-Projekte, die früher selten waren, sind heute viel häufiger anzutreffen, da kleinere IT-Operationen zu „Systemen von Systemen“ zusammengefasst werden.“ Die Flugsicherung ist ein Paradebeispiel dafür, weil sie auf Verbindungen zwischen Dutzenden von Netzwerken angewiesen ist, die Kommunikations-, Wetter-, Navigations- und andere Daten bereitstellen. Aber der Trick der Integration hat viele IT-Entwickler behindert, bis zu dem Punkt, an dem akademische Forscher zunehmend glauben, dass die Informatik selbst angesichts dieser massiv komplexen Systeme möglicherweise neu überdacht werden muss.

Wenn ein Projekt scheitert, gefährdet es die Aussichten einer Organisation. Wenn der Fehler groß genug ist, kann er die gesamte Zukunft des Unternehmens stehlen. In einer stellaren Kernschmelze führte ein schlecht implementiertes Ressourcenplanungssystem FoxMeyer Drug Co., ein 5-Milliarden-Dollar-Großhandelsunternehmen für Arzneimittel in Carrollton, Texas, das 1996 in Konkurs ging.

IT-Versagen in der Regierung kann die nationale Sicherheit gefährden, wie das Debakel der virtuellen Fallakte des FBI gezeigt hat. Das 170-Millionen-Dollar-VCF-System, eine durchsuchbare Datenbank, die es Agenten ermöglichen soll, „die Punkte zu verbinden“ und unterschiedliche Informationen zu verfolgen, endete stattdessen vor fünf Monaten, ohne dass ein System bereitgestellt wurde .

IT-Ausfälle können auch das Wirtschaftswachstum und die Lebensqualität beeinträchtigen. Bereits 1981 begann die US Federal Aviation Administration mit der Modernisierung ihres veralteten Flugsicherungssystems, aber die Bemühungen, einen Ersatz zu bauen, wurden bald von Problemen durchsetzt . Bis 1994, als die Agentur das Projekt endgültig aufgab, hatten sich die prognostizierten Kosten verdreifacht, mehr als 2,6 Milliarden US-Dollar waren ausgegeben worden und der erwartete Liefertermin war um mehrere Jahre gesunken. Jeder Flugzeugpassagier, der wegen festgefahrener Skyways verspätet ist, spürt dies immer noch.; die kumulierten wirtschaftlichen Auswirkungen all dieser Verspätungen allein auf die US-Fluggesellschaften (ganz zu schweigen von den Passagieren) belaufen sich auf 50 Milliarden US-Dollar.

Weltweit ist es schwer zu sagen, wie viele Softwareprojekte scheitern oder wie viel Geld dadurch verschwendet wird. Wenn Sie Fehler als völlige Aufgabe eines Projekts vor oder kurz nach der Auslieferung definieren und eine konservative Ausfallrate von 5 Prozent akzeptieren, werden jedes Jahr Milliarden von Dollar für schlechte Software verschwendet.

Zum Beispiel im Jahr 2004, die U.S. die Regierung gab 60 Milliarden US-Dollar für Software aus (ohne die eingebettete Software in Waffensystemen); Eine Ausfallrate von 5 Prozent bedeutet, dass wahrscheinlich 3 Milliarden US-Dollar verschwendet wurden. Nach mehreren Jahrzehnten als IT-Berater bin ich jedoch davon überzeugt, dass die Ausfallrate bei Projekten mit einem Budget von 10 Millionen US-Dollar oder mehr bei 15 bis 20 Prozent liegt. Betrachtet man die Gesamtinvestitionen in neue Softwareprojekte — sowohl von Regierungen als auch von Unternehmen — in den letzten fünf Jahren, schätze ich, dass Projektausfälle die US-Wirtschaft wahrscheinlich mindestens 25 Milliarden und vielleicht sogar 75 Milliarden Dollar gekostet haben.

Natürlich spiegeln diese 75 Milliarden US—Dollar keine Projekte wider, die ihr Budget überschreiten – was die meisten Projekte tun. Es spiegelt auch nicht Projekte wider, die verspätet geliefert werden – was die Mehrheit ist. Es berücksichtigt auch nicht die Opportunitätskosten, die anfallen, wenn ein Projekt abgebrochen wird, oder die Kosten für fehlerbehaftete Systeme, die wiederholt überarbeitet werden müssen.

Dann gibt es auch die Kosten für Rechtsstreitigkeiten von wütenden Kunden, die Lieferanten wegen schlecht implementierter Systeme verklagen. Wenn Sie all diese zusätzlichen Kosten addieren, liegt die jährliche Registerkarte für ausgefallene und problematische Software konservativ zwischen 60 und 70 Milliarden US-Dollar allein in den USA. Für dieses Geld könnten Sie das Space Shuttle 100 Mal starten, das gesamte 24-Satelliten—Global-Positioning-System bauen und einsetzen und die Boeing 777 von Grund auf neu entwickeln – und noch ein paar Milliarden übrig haben.

Warum scheitern Projekte so oft?

Zu den häufigsten Faktoren:

• Unrealistische oder unartikulierte Projektziele
• Ungenaue Schätzungen der benötigten Ressourcen
• Schlecht definierte Systemanforderungen
• Schlechte Berichterstattung über den Projektstatus
• Nicht verwaltete Risiken
• Schlechte Kommunikation zwischen Kunden, Entwicklern und Benutzern
• Nutzung unreifer Technologie
• Unfähigkeit, mit der Komplexität des Projekts umzugehen
• Schlampige Entwicklungspraktiken
• Schlechtes Projektmanagement
• Stakeholder-Politik
• Kommerzieller Druck

Natürlich werden IT-Projekte selten scheitern aus nur einem oder zwei Gründen. Das VCF-Projekt des FBI litt unter vielen der oben aufgeführten Probleme. Die meisten Fehler lassen sich auf eine Kombination aus technischen, Projektmanagement- und Geschäftsentscheidungen zurückführen. Jede Dimension interagiert auf komplizierte Weise mit den anderen, was die Projektrisiken und -probleme verschärft und die Ausfallwahrscheinlichkeit erhöht.

Betrachten Sie eine einfache Software-Aufgabe: ein Einkaufssystem, das die Bestellung, Abrechnung und den Versand von Teilen automatisiert, sodass ein Verkäufer die Bestellung eines Kunden eingeben, diese automatisch anhand der Preis- und Vertragsanforderungen überprüfen und die Teile und die Rechnung aus dem Lager an den Kunden senden kann.

Die Anforderungen an das System spezifizieren vier grundlegende Schritte. Erstens gibt es den Verkaufsprozess, der einen Kaufvertrag erstellt. Diese Rechnung wird dann einem rechtlichen Verfahren unterzogen, in dem die Vertragsbedingungen des potenziellen Verkaufs überprüft und genehmigt werden. An dritter Stelle steht der Bereitstellungsprozess, der die vertraglich vereinbarten Teile versendet, gefolgt vom Finanzprozess, der eine Rechnung versendet.

Nehmen wir an, während der erste Prozess für den Verkauf geschrieben wird, behandeln die Programmierer jede Bestellung so, als ob sie am Hauptstandort des Unternehmens platziert würde, obwohl das Unternehmen Niederlassungen in mehreren Bundesstaaten und Ländern hat. Dieser Fehler wirkt sich wiederum darauf aus, wie die Steuer berechnet wird, welche Art von Vertrag ausgestellt wird und so weiter.

Je früher die Auslassung erkannt und korrigiert wird, desto besser. Es ist wie das Stricken eines Pullovers. Wenn Sie direkt nach dem Nähen einen fehlenden Stich entdecken, können Sie einfach ein wenig Garn entwirren und weitermachen. Aber wenn Sie den Fehler nicht bis zum Ende fangen, müssen Sie möglicherweise den ganzen Pullover entwirren, nur um diesen einen Stich zu wiederholen.

Wenn die Software—Programmierer ihre Auslassung nicht bis zum endgültigen Systemtest — oder schlimmer noch, bis nach dem Rollout des Systems – feststellen, sind die Kosten für die Behebung des Fehlers wahrscheinlich um ein Vielfaches höher, als wenn sie den Fehler während der Arbeit am ursprünglichen Verkaufsprozess festgestellt hätten.

Und im Gegensatz zu einem verpassten Stich in einem Pullover ist dieses Problem viel schwieriger zu lokalisieren; Die Programmierer werden nur sehen, dass Fehler auftreten, und diese können mehrere Ursachen haben. Selbst nachdem der ursprüngliche Fehler behoben wurde, müssen sie andere Berechnungen und Dokumentationen ändern und dann jeden Schritt erneut testen.

Tatsächlich haben Studien gezeigt, dass Softwarespezialisten etwa 40 bis 50 Prozent ihrer Zeit für vermeidbare Nacharbeiten aufwenden und nicht für das, was sie Mehrwertarbeit nennen, was im Grunde genommen Arbeit ist, die beim ersten Mal richtig gemacht wird. Sobald eine Software ins Feld kommt, können die Kosten für die Behebung eines Fehlers 100-mal so hoch sein wie in der Entwicklungsphase.

Wenn Fehler im Überfluss vorhanden sind, kann Nacharbeit ein Projekt überschwemmen, wie ein Schlauchboot im Sturm. Schlimmer noch, Versuche, einen Fehler zu beheben, führen häufig zu neuen Fehlern. Es ist, als würden Sie das Schlauchboot retten, aber Sie schaffen auch Lecks. Wenn zu viele Fehler erzeugt werden, werden die Kosten und die Zeit, die benötigt werden, um das System zu vervollständigen, so groß, dass es keinen Sinn macht, weiterzumachen.

Vereinfacht ausgedrückt, scheitert ein IT-Projekt in der Regel, wenn die Nacharbeit die budgetierte wertschöpfende Arbeit übersteigt. Dies geschah mit Sydney Water Corp., dem größten Wasserversorger Australiens, als er 2002 versuchte, ein automatisiertes Kundeninformations- und Abrechnungssystem einzuführen . Laut einer Untersuchung des australischen Auditor General, zu den Faktoren, die das Projekt zum Scheitern verurteilt waren unzureichende Planung und Spezifikationen, was wiederum führte zu zahlreichen Änderungswünschen und erheblichen zusätzlichen Kosten und Verzögerungen. Sydney Water brach das Projekt auf halbem Weg ab, nachdem es AU $ 61 Millionen (US $ 33.2 Millionen) ausgegeben hatte.

All dies führt uns zu der offensichtlichen Frage: Warum treten so viele Fehler auf?

Softwareprojektausfälle haben viel mit Flugzeugabstürzen gemeinsam. So wie Piloten niemals abstürzen wollen, wollen Softwareentwickler nicht scheitern. Wenn ein kommerzielles Flugzeug abstürzt, untersuchen die Ermittler viele Faktoren wie das Wetter, Wartungsaufzeichnungen, die Disposition und Ausbildung des Piloten sowie kulturelle Faktoren innerhalb der Fluggesellschaft. Ebenso müssen wir das Geschäftsumfeld, das technische Management, das Projektmanagement und die Organisationskultur betrachten, um den Ursachen von Softwarefehlern auf den Grund zu gehen.

Die wichtigsten Geschäftsfaktoren sind der Wettbewerb und die Notwendigkeit, Kosten zu senken. Führungskräfte erwarten zunehmend, dass IT-Abteilungen mit weniger mehr und schneller als zuvor erreichen; Sie betrachten Softwareprojekte nicht als Investitionen, sondern als reine Kosten, die kontrolliert werden müssen.

Politische Nöte können auch den Zeitplan, die Kosten und die Qualität eines IT-Projekts beeinträchtigen. Als der Denver International Airport versuchte, sein automatisiertes Gepäckabfertigungssystem einzuführen, hielten staatliche und lokale politische Führer das Projekt an einem unrealistischen Zeitplan nach dem anderen fest. Das Versäumnis, das System rechtzeitig zu liefern, verzögerte die Eröffnung des Flughafens (damals der größte in den Vereinigten Staaten) im Jahr 1995, was die finanziellen Auswirkungen um ein Vielfaches verschärfte.

Selbst nach der Fertigstellung des Systems funktionierte es nie zuverlässig: Es zerkaute Gepäck, und die Wagen, mit denen Gepäck transportiert wurde, entgleisten häufig. Schließlich verklagte United Airlines, der Hauptmieter des Flughafens, den Systemunternehmer, und die Episode wurde zu einem Beweis für die Gefahren politischer Zweckmäßigkeit.

Ein Mangel an Unterstützung des oberen Managements kann auch ein IT-Unternehmen beeinträchtigen. Dies reicht von der nicht ausreichenden Bereitstellung von Geld und Arbeitskräften bis hin zur nicht eindeutigen Festlegung der Beziehung des IT-Projekts zum Geschäft der Organisation. Im Jahr 2000, Einzelhändler Kmart Corp., in Troy, Mich., startete ein $1.4 Milliarden IT-Modernisierungsaufwand zur Verknüpfung der Vertriebs-, Marketing-, Liefer- und Logistiksysteme, um besser mit dem Rivalen Wal-Mart Corp. in Bentonville, Ark, konkurrieren zu können. Wal-Mart erwies sich jedoch als zu beeindruckend, und 18 Monate später reduzierte Kmart die Modernisierung und schrieb die bereits investierten 130 Millionen US-Dollar ab. Vier Monate später meldete es Insolvenz an; Das Unternehmen kämpft bis heute.

Häufig greifen IT-Projektmanager, die eine Finanzierung anstreben, auf eine Form von Lügenpoker zurück und versprechen zu viel, was ihr Projekt bewirken wird, wie viel es kosten wird und wann es abgeschlossen sein wird. Viele, wenn nicht die meisten Softwareprojekte beginnen mit zu kleinen Budgets. In diesem Fall müssen die Entwickler das Defizit irgendwie ausgleichen, indem sie in der Regel versuchen, die Produktivität zu steigern, den Umfang des Aufwands zu reduzieren oder riskante Abkürzungen in den Überprüfungs- und Testphasen zu nehmen. Dies alles erhöht die Fehlerwahrscheinlichkeit und letztendlich das Scheitern.

Ein hochmodernes Reisereservierungssystem, das von einem Konsortium aus Budget Rent-A-Car, Hilton Hotels, Marriott und AMR, der Muttergesellschaft von American Airlines, angeführt wird, ist ein typisches Beispiel. Im Jahr 1992, dreieinhalb Jahre und 165 Millionen US-Dollar in das Projekt investiert, gab die Gruppe es unter Berufung auf zwei Hauptgründe auf: einen zu optimistischen Entwicklungsplan und eine Unterschätzung der damit verbundenen technischen Schwierigkeiten. Dies war dieselbe Gruppe, die zuvor das äußerst erfolgreiche Sabre-Reservierungssystem aufgebaut hatte, was beweist, dass die Leistung in der Vergangenheit keine Garantie für zukünftige Ergebnisse ist.

Nachdem Absturzermittler das Wetter als Faktor bei einem Flugzeugabsturz betrachten, schauen sie sich das Flugzeug selbst an. Gab es etwas im Design des Flugzeugs, das den Absturz verursacht hat? Trug er zu viel Gewicht?

Bei IT-Projektausfällen stellen sich immer wieder ähnliche Fragen zu den technischen Komponenten des Projekts: der Hard- und Software, mit der das System entwickelt wurde, und den Entwicklungspraktiken selbst. Organisationen werden oft vom Sirenengesang des technologischen Imperativs verführt – dem unkontrollierbaren Drang, die neueste Technologie in der Hoffnung auf einen Wettbewerbsvorteil einzusetzen. Da sich die Technologie schnell ändert und fantastische neue Funktionen verspricht, ist es leicht zu erliegen. Die Verwendung von unreifer oder ungetesteter Technologie ist jedoch ein sicherer Weg zum Scheitern.

1997 stellte der Bundesstaat Washington nach Ausgaben von 40 Millionen US-Dollar ein IT-Projekt ein, das Führerscheine und Fahrzeugzulassungen verarbeitet hätte. Kfz-Beamte gaben zu, dass sie sich in der Jagd nach Technologie verfangen hatten, anstatt sich auf die Implementierung eines Systems zu konzentrieren, das ihren Anforderungen entsprach. Das IT-Debakel, das FoxMeyer Drug ein Jahr zuvor zu Fall gebracht hatte, beruhte auch darauf, dass ein hochmodernes Ressourcenplanungssystem eingeführt und dann über das hinausgeschoben wurde, was machbar war.

Die schiere Größe eines Projekts ist eine Quelle des Scheiterns. Studien zeigen, dass Großprojekte drei- bis fünfmal häufiger scheitern als kleine. Je größer das Projekt ist, desto komplexer ist es sowohl in seinen statischen Elementen (den diskreten Teilen von Software, Hardware usw.) als auch in seinen dynamischen Elementen (den Kopplungen und Interaktionen zwischen Hardware, Software und Benutzern; Verbindungen zu anderen Systemen usw.). Eine größere Komplexität erhöht die Fehlerwahrscheinlichkeit, da niemand wirklich alle interagierenden Teile des Ganzen versteht oder in der Lage ist, sie zu testen.

Ernüchternd aber wahr: Es ist unmöglich, ein IT-System jeder realen Größe gründlich zu testen. Peter S. Pressman wies in seinem Buch Software Engineering, einem der klassischen Texte auf diesem Gebiet, darauf hin, dass „erschöpfende Tests bestimmte logistische Probleme mit sich bringen….Selbst ein kleines 100-Zeilen-Programm mit einigen verschachtelten Pfaden und einer einzelnen Schleife, die weniger als zwanzig Mal ausgeführt wird, kann 10 bis 14 mögliche Pfade erfordern.“ Um all diese 100 Billionen Pfade zu testen, bemerkte er, vorausgesetzt, jeder könnte in einer Millisekunde ausgewertet werden, würde 3170 Jahre dauern.

Alle IT-Systeme sind intrinsisch fragil. In einem großen Backsteingebäude müssten Sie Hunderte strategisch platzierter Steine entfernen, um eine Mauer zum Einsturz zu bringen. In einem 100 000-Zeilen-Softwareprogramm sind jedoch nur ein oder zwei fehlerhafte Zeilen erforderlich, um größere Probleme zu verursachen. Im Jahr 1991 ging ein Teil des Telefonnetzes von At & amp; T aus und ließ 12 Millionen Abonnenten ohne Service, alles wegen eines einzigen falsch eingegebenen Zeichens in einer Codezeile.

Schlampige Entwicklungspraktiken sind eine reichhaltige Fehlerquelle und können in jeder Phase eines IT-Projekts zu Fehlern führen. Um Organisationen dabei zu helfen beurteilen Ihre software-Entwicklung Praktiken, USA Das Software Engineering Institute in Pittsburgh hat das Capability Maturity Model (CMM) entwickelt. Es bewertet die Praktiken eines Unternehmens anhand von fünf Stufen zunehmender Reife. Stufe 1 bedeutet, dass die Organisation Ad-hoc- und möglicherweise chaotische Entwicklungspraktiken anwendet. Level 3 bedeutet, dass das Unternehmen seine Praktiken charakterisiert hat und sie jetzt versteht. Stufe 5 bedeutet, dass die Organisation die Variationen in den Prozessen und Praktiken, die sie anwendet, quantitativ versteht.

Bis Januar hatten fast 2000 Regierungs- und Handelsorganisationen freiwillig CMM-Werte gemeldet. Mehr als die Hälfte gab an, entweder auf Stufe 1 oder 2 zu sein, 30 Prozent waren auf Stufe 3 und nur 17 Prozent hatten Stufe 4 oder 5 erreicht. Die Prozentsätze sind noch düsterer, wenn man bedenkt, dass dies eine selbst ausgewählte Gruppe ist; Offensichtlich werden sich Unternehmen mit den schlechtesten IT-Praktiken keiner CMM-Bewertung unterziehen. (Das CMM wird durch die CMM-Integration abgelöst, die auf eine umfassendere Bewertung der Fähigkeit eines Unternehmens abzielt, softwareintensive Systeme zu erstellen.)

Unreife IT-Praktiken in den USA. Internal Revenue Service $ 4 Milliarden Modernisierungsaufwand im Jahr 1997, und sie haben weiterhin die IRS aktuelle $ 8 Milliarden Modernisierung plagen. Es kann nur an sich unmöglich sein, die Abgabenordnung in Software-Code zu übersetzen-Steuerrecht ist komplex und basiert auf oft vage Gesetzgebung, und es ändert sich die ganze Zeit. Aus Sicht eines IT-Entwicklers ist dies ein Albtraum für Anforderungen. Aber der IRS wurde nicht durch offene Feindseligkeit zwischen internen und externen Programmierern, eine lächerliche Unterschätzung der damit verbundenen Arbeit und viele andere schlechte Praktiken geholfen.

DIE HANDLUNGEN DES PILOTEN KURZ VOR einem Flugzeugabsturz sind für die Ermittler immer von großem Interesse. Das liegt daran, dass der Pilot der ultimative Entscheidungsträger ist, der für den sicheren Betrieb des Fahrzeugs verantwortlich ist. In ähnlicher Weise spielen Projektmanager eine entscheidende Rolle in Softwareprojekten und können eine wichtige Fehlerquelle sein, die zum Scheitern führt.

Bereits 1986 beschloss die London Stock Exchange, ihr System zur Abwicklung von Aktientransaktionen zu automatisieren. Sieben Jahre später, nachdem sie 600 Millionen Dollar ausgegeben hatten, verschrottete sie die Entwicklung des Taurus-Systems, nicht nur, weil das Design übermäßig komplex und umständlich war, sondern auch, weil das Management des Projekts, um das Wort eines ihrer eigenen leitenden Angestellten zu verwenden, „wahnhaft“ war.“ Wie Untersuchungen ergaben, schien niemand den wahren Status des Projekts wissen zu wollen, auch wenn immer mehr Probleme auftraten, Fristen versäumt wurden und die Kosten in die Höhe schossen .

Die wichtigste Funktion des IT-Projektmanagers besteht darin, Ressourcen für verschiedene Aktivitäten bereitzustellen. Darüber hinaus ist der Projektleiter verantwortlich für Projektplanung und -schätzung, Steuerung, Organisation, Vertragsmanagement, Qualitätsmanagement, Risikomanagement, Kommunikation und Personalmanagement.

Fehlentscheidungen von Projektmanagern sind heute wahrscheinlich die häufigste Ursache für Softwarefehler. Ein schlechtes technisches Management kann dagegen zu technischen Fehlern führen, die jedoch im Allgemeinen isoliert und behoben werden können. Eine schlechte Projektmanagemententscheidung — wie die Einstellung zu weniger Programmierer oder die Auswahl der falschen Vertragsart — kann jedoch verheerend sein. Zum Beispiel behaupten die Entwickler des zum Scheitern verurteilten Reisereservierungssystems, dass sie teilweise durch die Verwendung eines Festpreisvertrags gehumpelt wurden. Ein solcher Vertrag geht davon aus, dass die Arbeit Routine sein wird, das Reservierungssystem erwies sich als alles andere als.

Projektmanagemententscheidungen sind oft schwierig, gerade weil sie Kompromisse beinhalten, die auf unscharfem oder unvollständigem Wissen beruhen. Abzuschätzen, wie viel ein IT-Projekt kosten wird und wie lange es dauern wird, ist ebenso Kunst wie Wissenschaft. Je größer oder umfangreicher das Projekt, desto ungenauer die Schätzungen. Es ist ein laufender Witz in der Branche, dass IT-Projektschätzungen bestenfalls innerhalb von 25 Prozent ihres wahren Wertes in 75 Prozent der Fälle liegen.

Es gibt andere Möglichkeiten, wie schlechtes Projektmanagement den Untergang eines Softwareprojekts beschleunigen kann. Eine Studie des Project Management Institute in Newton Square, Pa., zeigte, dass Risikomanagement branchenübergreifend die am wenigsten praktizierte aller Projektmanagement-Disziplinen ist und nirgendwo seltener angewendet wird als in der IT-Branche. Ohne effektives Risikomanagement haben Softwareentwickler wenig Einblick in das, was schief gehen kann, warum es schief gehen kann und was getan werden kann, um die Risiken zu beseitigen oder zu mindern. Es gibt auch keine Möglichkeit zu bestimmen, welche Risiken akzeptabel sind, was wiederum Projektentscheidungen in Bezug auf Kompromisse nahezu unmöglich macht.

Schlechtes Projektmanagement nimmt viele andere Formen an, einschließlich schlechter Kommunikation, die eine unwirtliche Atmosphäre schafft, die den Umsatz erhöht; nicht in die Schulung der Mitarbeiter investieren; und den Projektfortschritt nicht in regelmäßigen Abständen überprüfen. All dies kann dazu beitragen, ein Softwareprojekt zu entgleisen.

Der letzte Bereich, den die Ermittler nach einem Flugzeugabsturz untersuchen, ist das organisatorische Umfeld. Hat die Fluggesellschaft eine starke Sicherheitskultur oder legt sie vor allem Wert auf die Einhaltung des Flugplans? In IT-Projekten ist eine Organisation, die Offenheit, Ehrlichkeit, Kommunikation und Zusammenarbeit schätzt, eher geneigt, Fehler früh genug zu finden und zu beheben, damit die Nacharbeit nicht überwältigend wird.

Wenn es ein Thema gibt, das sich durch die gequälte Geschichte schlechter Software zieht, ist es ein Versagen, sich der Realität zu stellen. Bei zahlreichen Gelegenheiten teilten der Generalinspektor des US-Justizministeriums, ein externes Expertengremium und andere dem FBI-Chef mit, dass das VCF-System wie definiert unmöglich sei und das Projekt trotzdem fortgesetzt werde. Die gleichen Einstellungen gab es unter den Verantwortlichen für das Reisereservierungssystem, das Taurus-System der Londoner Börse und das Flugverkehrskontrollprojekt der FAA – alles Anzeichen für Organisationskulturen, die von Angst und Arroganz getrieben werden.

Ein kürzlich veröffentlichter Bericht des National Audit Office im Vereinigten Königreich ergab, dass zahlreiche Fälle von IT-Projekten der Regierung empfohlen wurden, nicht fortzufahren und trotzdem fortzufahren. Das Vereinigte Königreich hat sogar eine Regierungsabteilung, die damit beauftragt ist, IT-Ausfälle zu verhindern, aber wie der Bericht feststellte, ignorieren mehr als die Hälfte der Agenturen, die das Ministerium überwacht, routinemäßig seinen Rat. Ich nenne diese Art von Verhalten irrationale Projekteskalation – die Unfähigkeit, ein Projekt zu stoppen, selbst wenn es offensichtlich ist, dass sich die Erfolgswahrscheinlichkeit schnell Null nähert. Leider ist ein solches Verhalten in keiner Weise einzigartig.

Letztendlich ähneln große Softwarefehler eher dem schlimmsten denkbaren Flugzeugabsturz, bei dem der Pilot unerfahren, aber äußerst voreilig war, in einem ungetesteten Flugzeug in einen Eissturm flog und für eine Fluggesellschaft arbeitete, die Lippenbekenntnisse zur Sicherheit ablegte und gleichzeitig Training und Wartung reduzierte. Wenn Sie den Bericht des Ermittlers danach lesen, würden Sie den Kopf schütteln und fragen: „War ein solcher Absturz nicht unvermeidlich?“

Auch die Gründe für das Scheitern von Softwareprojekten sind bekannt und in unzähligen Artikeln, Berichten und Büchern ausführlich dokumentiert . Und doch plagen uns weiterhin Ausfälle, Beinahe-Ausfälle und einfache alte schlechte Software, während Praktiken, von denen bekannt ist, dass sie Fehler abwenden, gemieden werden. Es scheint, dass es in den meisten Unternehmen keine dringende Priorität ist, qualitativ hochwertige Software pünktlich und innerhalb des Budgets zu erhalten.

Es schien nicht bei Oxford Health Plans Inc zu sein., in Trumbull, Conn., im Jahr 1997. Das automatisierte Abrechnungssystem des Unternehmens war für das Endergebnis von entscheidender Bedeutung, und dennoch waren die dortigen Führungskräfte mehr daran interessiert, das Geschäft von Oxford auszubauen, als sicherzustellen, dass das Abrechnungssystem die aktuellen Anforderungen erfüllen konnte . Selbst als Probleme auftraten, wie Rechnungen, die Monate zu spät verschickt wurden, schenkten die Manager wenig Aufmerksamkeit. Als das Abrechnungssystem effektiv zusammenbrach, verlor das Unternehmen mehrere zehn Millionen Dollar, und seine Aktie fiel an einem Tag von 68 auf 26 Dollar pro Aktie, wodurch der Unternehmenswert von 3,4 Milliarden Dollar ausgelöscht wurde. Aktionäre brachten Klagen ein, und mehrere Regierungsbehörden untersuchten das Unternehmen, das schließlich wegen Verstößen gegen die Vorschriften mit einer Geldstrafe von 3 Millionen US-Dollar belegt wurde.

Selbst Organisationen, die von schlechten Software-Erfahrungen gebrannt werden, scheinen nicht in der Lage oder nicht willens zu sein, aus ihren Fehlern zu lernen. In einem Bericht aus dem Jahr 2000 stellte das US Defense Science Board, ein Beratungsgremium des Verteidigungsministeriums, fest, dass verschiedene vom Verteidigungsministerium in Auftrag gegebene Studien 134 Empfehlungen zur Verbesserung der Softwareentwicklung abgegeben hatten, von denen jedoch nur 21 befolgt worden waren. Die anderen 113 waren immer noch gültig, stellte der Vorstand fest, wurden aber ignoriert, obwohl sich das Verteidigungsministerium über den schlechten Zustand der Entwicklung von Verteidigungssoftware beschwerte!

Einige Organisationen legen Wert auf Softwarequalität, wie die Erfahrung der Softwareentwicklungsfirma Praxis High Integrity Systems in Bath, England, beweist. Praxis verlangt, dass sich seine Kunden nicht nur finanziell, sondern auch als aktive Teilnehmer an der Erstellung des IT-Systems für das Projekt engagieren. Das Unternehmen verbringt auch enorm viel Zeit damit, die Anforderungen des Kunden zu verstehen und zu definieren, und fordert die Kunden auf, zu erklären, was sie wollen und warum. Bevor eine einzige Codezeile geschrieben wird, vereinbaren Kunde und Praxis, was gewünscht, machbar und mit welchen Risiken die verfügbaren Ressourcen verbunden sind.

Danach wendet Praxis einen rigorosen Entwicklungsansatz an, der die Anzahl der Fehler begrenzt. Einer der großen Vorteile dieses Modells besteht darin, dass es die vielen potenziellen Kunden herausfiltert, die nicht bereit sind, die Verantwortung für die Formulierung ihrer IT-Anforderungen zu übernehmen und Zeit und Geld für deren ordnungsgemäße Implementierung aufzuwenden.

Ein gewisses Maß an Softwarefehlern wird immer bei uns sein. In der Tat brauchen wir echte Misserfolge — im Gegensatz zu vermeidbaren Fehlern -, um weiterhin technische und wirtschaftliche Fortschritte zu erzielen. Aber zu viele der Fehler, die heute auftreten, sind vermeidbar. Und da unsere Gesellschaft auf IT-Systeme angewiesen ist, die immer größer, integrierter und teurer werden, können die Kosten des Scheiterns katastrophal hoch werden.

Schon jetzt ist es möglich, darauf zu wetten, wo das nächste große Software-Debakel stattfinden wird. Einer meiner führenden Kandidaten sind die IT-Systeme, die aus der American Health Information Community der US-Regierung hervorgehen werden, einer öffentlich-privaten Zusammenarbeit, die Datenstandards für elektronische Patientenakten definieren soll. Die Idee ist, dass nach der Definition von Standards IT-Systeme aufgebaut werden, mit denen medizinische Fachkräfte im ganzen Land Patientenakten digital eingeben können, um Ärzten, Krankenhäusern, Versicherern und anderen Gesundheitsspezialisten sofortigen Zugriff auf die vollständige Krankengeschichte eines Patienten zu ermöglichen. Gesundheitsexperten glauben, dass ein solches System die Patientenversorgung verbessern, die Kosten um schätzungsweise 78 Milliarden US-Dollar pro Jahr senken und medizinische Fehler reduzieren und Zehntausende von Menschenleben retten wird.

Aber dieser Ansatz ist nur ein Wunschtraum, wenn Software-Praktiken und Ausfallraten so bleiben, wie sie heute sind. Selbst nach den optimistischsten Schätzungen erfordert die Erstellung eines elektronischen Patientenaktensystems 10 Jahre Aufwand, Entwicklungskosten in Höhe von 320 Milliarden US—Dollar und Betriebskosten in Höhe von 20 Milliarden US-Dollar pro Jahr – vorausgesetzt, es gibt keine Ausfälle, Überschreitungen, Terminabsprachen, Sicherheitsprobleme oder minderwertige Software. Dies ist kaum ein realistisches Szenario, zumal die meisten IT-Experten die medizinische Gemeinschaft als die am wenigsten computeraffine aller professionellen Unternehmen betrachten.

Patienten und Steuerzahler werden letztendlich den Preis für die Entwicklung oder das Scheitern solcher Boondoggles zahlen. Angesichts der heutigen IT-Praktiken ist ein Ausfall eine eindeutige Möglichkeit, und es wäre ein Verlust von beispiellosem Ausmaß. Aber dann, Länder auf der ganzen Welt erwägen oder arbeiten bereits an vielen Initiativen ähnlicher Größe und Wirkung — in der Luftfahrt, nationale Sicherheit, und das Militär, unter anderen Bereichen.

Wie Elektrizität, Wasser, Transport und andere kritische Teile unserer Infrastruktur wird es schnell zu einem Bestandteil unserer täglichen Existenz. In wenigen Jahrzehnten wird ein groß angelegter IT-Ausfall mehr als nur eine teure Unannehmlichkeit sein: es wird unsere Lebensweise gefährden. In Ermangelung branchenweiter Änderungen, die Softwarefehler mindern, wie viel von unserer Zukunft sind wir bereit, auf diese enorm kostspieligen und komplexen Systeme zu setzen?

Wir wissen bereits, wie man Software gut macht. Es kann endlich Zeit sein, auf das zu reagieren, was wir wissen.