Weltweit liefern nur 29 Prozent der Entwicklungsprojekte die bestellten Funktionen im vereinbarten Zeit- und Kostenrahmen. 53 Prozent verschlingen mehr Aufwand als geplant, und 18 Prozent scheitern ganz. Dies hat die Standish Group in ihrem jüngsten so genannten Chaos Report herausgefunden, den sie alle zwei Jahre nach der Untersuchung von zuletzt fast 10000 IT-Projekten erstellt.

Gerade bei behördlichen IT-Grossprojekten ist sowohl der finanzielle, als auch der Imageschaden enorm, wenn sie nicht nach Plan verlaufen. Wilhelm Kruth ist Leiter des gemeinsamen Gebietsrechenzentrums, eines Systemhauses des Landes Nordrhein-Westfalen in Köln. Er ist überzeugt: «Versäumnisse bei der Anforderungsdefinition, also in den frühen Phasen von Entwicklungsprojekten, sind die Ursache vieler dieser Probleme.» Schlechte Vorgaben liessen sich während der Programmierung nur noch aufwändig und im Test gar nicht mehr kompensieren. Kruth fordert deshalb eine übergreifende Qualitätssicherung, die schon im Projektvorfeld prüft, ob die Anforderungen der politisch verantwortlichen Auftraggeber eindeutig und systemtechnisch umsetzbar sind.

Die fundamentale Bedeutung des Anforderungsmanagements für die Wirtschaftlichkeit von IT-Projekten ist zwar seit Jahren nichts Neues mehr. Doch immer noch tun sich viele öffentliche Auftraggeber mit Investitionen in diese vorbeugende Qualitätssicherung schwer. Der Grund: Der politische Entscheidungsprozess ist gerade dadurch gekennzeichnet, dass Anforderungen immer wieder auf den Prüfstand kommen und kurzfristig geändert werden. Gesetze und öffentliche Regularien tragen zumeist die Handschrift vieler unterschiedlicher Interessengruppen. Hinzu kommt, dass IT-Expertise noch keinen festen Platz in den politischen Entscheidungsprozessen besitzt. Dies führt zum bekannten Phänomen, dass die politisch Verantwortlichen die Implementierungsdauer ihrer Vorgaben regelmässig unterschätzen.

Aufgrund des zunehmenden Drucks seitens der Öffentlichkeit und angesichts leerer Kassen sehen sich viele Behörden nach geeigneten Gegenmassnahmen um. So hat etwa der Deutsche Städte- und Gemeindebund einen Rahmenvertrag mit SQS Software Quality Systems geschlossen. Das Beratungshaus unterstützt dessen Mitgliedkommunen beim Qualitätsmanagement und stellt Produkte sowie Dienstleistungen rund um das Software-Testen zur Verfügung.

Was bedeutet das für den Projektalltag der Behörden-IT? Welche Stolpersteine und Erfolgsfaktoren müssen die Verantwortlichen kennen? In erster Linie geht es um eine wesentlich stärkere Verzahnung der bisher getrennten Welten Fachabteilung und IT-Organisation. Zum einen muss die IT-Expertise bei der Vertragsgestaltung einen stärkeren Einfluss bekommen. So können Auftraggeber und IT-Lieferanten zum Beispiel vermeiden, dass sie von vornherein unrealistischen Lieferterminen hinterher laufen. Andererseits gilt es, die Fachexperten während der Entwicklung stärker in die Pflicht zu nehmen - sei es bei der Anforderungsdefinition oder der Priorisierung der verschiedenen Funktionen.

Schon kurzfristig an Effizienz gewinnt das Anforderungs- und Testmanagement durch den Einsatz entsprechend spezialisierter Werkzeuge. Hinter den Tools verbirgt sich jedoch auch ein grosser potenzieller Stolperstein. Viele Behörden, die Werkzeuge für das Anforderungs- und Testmanagement bereits eingekauft haben, besitzen nun nur weitere Beispiele von so genannter Schrankware. Das heisst, sie benutzen die Tools entweder gar nicht oder nur in eingeschränktem Mass, bezahlen aber oft beträchtliche Lizenzgebühren. Der Grund: Diese Werkzeuge sind erstens nur zum Teil selbst erklärend und zweitens ersetzen sie keinen Testprozess, sondern unterstützen ihn nur. Dies sollten sie aber bestmöglich tun. Deshalb müssen die Behörden- und IT-Leitungen zunächst dafür sorgen, dass sie zusätzlich die wesentlichen Vorgehensweisen der Entwicklung und des Testens definieren und die Schulung der Toolnutzer daran ausrichten.

Für die Entwicklung steht seit kurzem ein zusätzlicher Posten auf dem Behörden-Einkaufszettel: Analyse-Verfahren und
-Tools, welche die technische Qualität des Software-Codes systematisch und kontinuierlich vermessen. Wie Forrester Research in einer Studie schreibt, ist die dauerhafte Durchleuchtung des Codes während der Entwicklung der wichtigste Einflussfaktor für die späteren Wartungskosten. Sie machen inzwischen rund drei Viertel aller IT-Etats aus. Die Forrester-Analysten gehen davon aus, dass eine Investition in solche Code-Analyse-Werkzeuge dreimal mehr Effizienzsteigerungen in der Wartung erziele als die gleiche Investition in neue und bessere Entwicklungswerkzeuge. Nichtsdestotrotz fliesse der Löwenanteil der Etats weiter in neue Entwicklungstechnologien.

Von grossem Einfluss ist darüber hinaus der Lieferantenmix: Wer übernimmt welche Aufgaben? Das Deutsche Institut für medizinische Dokumentation und Information zum Beispiel hat gute Erfahrungen damit gemacht, Entwicklungsprojekte nicht komplett in die Hände eines einzigen Dienstleisters zu geben. Die dortigen Verantwortlichen haben vielmehr darauf geachtet, Realisierung und Qualitätssicherung getrennt zu beauftragen. Denn nur Testexperten, die nicht Teil der Implementierung sind, können jenen unabhängigen Blick gewährleisten, der für eine verlässliche QS notwendig ist.

All diese Änderungen, vor allem die stärkere Verzahnung der politisch und fachlich Verantwortlichen mit den IT-Experten, erfordern zum Teil erhebliche organisatorische Veränderungen, die mit verschiedenen Störfaktoren einhergehen. So sind die unterschiedlichen Denk- und Vorgehensweisen der behördlichen Fach- und der IT-Experten nicht durch einfache organisatorische Massnahmen überbrückbar. An dieser Stelle sind in der Regel Kommunikationsprofis gefragt, die zwischen den beiden Welten vermitteln.

Hinzu kommt ein externes Risiko, das speziell bei Behörden auftaucht: Sie führen oft eine vorläufige Haushaltsplanung durch. Dies lenkt den Blick auf einen eher kurzfristigen Nutzen, Risiken können auf Folgehaushalte verschoben werden, die oft schon von anderen Führungskräften verantwortet werden.

Auf ihrem Weg, ein IT-Qualitätsmanagement einzuführen, das in einem wirtschaftlichen Kosten-Nutzen-Verhältnis steht, setzen derzeit zahlreiche öffentliche Auftraggeber auf Risikomanagement. Als Teil des Testmanagements nutzen es die Behörden- und Projektleiter, um die Spreu vom Weizen zu trennen: Wo lohnen hohe Testaufwände, wo nicht? Auf diese Weise erhöhen die Projekte nicht nur die Systemqualität gezielter, sondern senken zugleich den Ressourceneinsatz. Der Grund: Risikomanagement reduziert die Anzahl der zu bearbeitenden Testfälle, da es den Blick auf die wichtigsten Fehlerquellen lenkt und viele unkritische Funktionen auch als solche definiert. Es unterscheidet dabei äussere Risiken, die vor allem in die Verantwortung des Auftraggebers fallen, und innere Risiken auf Seiten der IT-Dienstleister.

o Unvollständige/ständig nachgebesserte fachliche Vorgaben

o Unzureichendes/unerfahrenes Entwicklungsteam

o Einführung neuer Technologien ohne ausreichende Erprobung

o Unzulängliches Anforderungsmanagement

o Unzulängliches Fehlermanagement

o Unvollständige/ungenaue Testziele

o Unbekannte/unvollständige Testeingangskriterien

o Unzureichende Qualifikation des Testteams

o Unzureichende Testinfrastruktur

o Unrealistische Zeitvorgaben für einzelne Tests

o Fehlende Abstimmung zwischen Produktentwicklung und Test

o Unzureichende Testfälle

o Unmethodische Testdurchführung

o Undefinierte Testabbruchkriterien

o Unzureichendes Testbudget

o Unzureichende Ergebniskontrollen

o Unvollständige Dokumentation