Gerne wird das Problem mit «Führungsschwäche» im Projekt begründet und dem zu grossen Einfluss externer Berater zugeschrieben. Als ob all diese gescheiterten Projekte keine Projektleitung gehabt hätten.
Anfang Februar hatten wir bei Zeix eine Veranstaltung zum Thema Die Pflichtenheftfalle oder der Weg zur guten Software. Zur Einleitung hatten wir eine kleine Zusammenstellung präsentiert über grosse Softwareprojekte, die an die Wand gefahren wurden. Die zahlreichen Beispiele stammten vornehmlich von der öffentlichen Hand, weil nur diese publik pleite werden. Wir vermuten eine grosse Dunkelziffer im privaten Sektor.
Dramen in der IT
Gestern publizierte die Berner Zeitung die nächste Staffel des Dramas: Mistra ist ein IT-Projekt des Bundesamts für Strassen (Astra), das alle Daten im Zusammenhang mit Strassen in einem einzigen Datenbankverbund integrieren soll. Ursprünglich geplantes Volumen: 45 Millionen, Projektlaunch 2013. Nun ist der Launch verschoben, das Budget war bereits 2011 aufgebraucht und es steht schon fest, dass das Projekt «einige Millionen Franken mehr kosten» werde, so der Astra Sprecher Thomas Rohrbach. Wie so oft bei IT-Projekten seien zusätzliche Bedürfnisse dazu gekommen, die Kosten falsch berechnet und die technologischen Möglichkeiten zu optimistisch eingeschätzt worden. Bei Mistra werden zusätzlich Unregelmässigkeiten bei der Auftragsvergabe angeprangert.
Erst vor wenigen Monaten machte das Projekt der Steuerverwaltung «Insieme» ähnliche Schlagzeilen mit Projektkosten von sogar 150 Millionen. Das Finanzdepartement kam damals zum Schluss: «Da die Kosten massiv überschritten wurden, kann das Informatikprojekt nicht im ursprünglichen Umfang realisiert werden».
Sind also IT-Flops die Schuld der Projektleiter und der Auftragsvergabe-Verfahren?
Zur Ursachenforschung
Gerne wird das Problem mit «Führungsschwäche» im Projekt begründet und dem zu grossen Einfluss externer Berater zugeschrieben. Als ob all diese gescheiterten Projekte keine Projektleitung gehabt hätten. Um im Fall von Insieme bei 150 Millionen Investition und bis zu 220 Personen, die im IT-Projekt beteiligt gewesen sein sollen, zu einem minimalen Output zu kommen (nämlich einfach den Status-Quo auf ein neues System zu portieren), muss noch etwas anderes schief gelaufen sein.
Bei den meisten gescheiterten Projekten liegt die Ursache des Problems in der Vorgehensweise und den Methoden, die in der IT-Branche weit verbreitet sind. Die zu späte Erkennung der Kostenüberschreitungen und allfällige ungeeignete Reaktionen darauf sind nur Folgeerscheinungen.
Wir kennen dieses spezifischen Projekte nicht und wissen auch nicht, wie genau das Vorgehen hier war. Jedoch sehen wir in zahlreichen Projekten immer wieder genau das gleiche Muster:
- In tagelangen «Bedürfnis»-Workshops werden meterdicke prosaische, teilweise unverständliche, sicher aber sehr heterogen interpretierbare Pflichtenhefte erstellt.
- Anschliessend werden Umsetzer gesucht, welche basierend auf den Pflichtenheften Kostenschätzungen für die Umsetzung abgeben (man könnte das auch «Budget-Bingo» nennen). Natürlich legen die Umsetzer den Interpretationsspielraum dabei zu ihren eigenen Gunsten aus.
- Und schliesslich wird dann mit grossem Aufwand das Pflichtenheft in viele Teilprojekte zerstückelt umgesetzt (Stichwort «modular»).
- Schliesslich resultiert eine vollkommen andere Software als irgend ein/e Beteiligte/r der Bedürfnisworkshops sie sich erträumt hat. Zudem passen die einzelnen Teile konzeptionell nicht zusammen. Schon hat man ein «Software-Fiasko», ein «IT-Debakel» und «verschleuderte Millionen» auf den Titelblättern aller Zeitungen.
Agile Concept
Beim Bau eines Hauses spezifiziert man dieses ja auch nicht in Form eines Romans. Es ist uns unverständlich, wie man auf die Idee kommt, dies bei einer Software zu tun.
So kann das nicht weiter gehen. Hier wird der Ruf sämtlicher Dienstleister im IT-Umfeld beschädigt. Es wäre doch so einfach mit agilem User-Centered Design und Prototyping:
- Zuerst verstehen,
- dann denken,
- dann Prototyping und plausibilisieren,
- dann testen und
- dann agile umsetzen.
So findet man eine gemeinsame Sprache zwischen Fachleuten, Anwendern und IT-Leuten und hat schlussendlich eine kohärente, vollständige und benutzerfreundliche Software, die erst noch schlank zu programmieren ist.
Gregor Urech
14.06.2013 - 16:20«Ursachenforschung bei Informatik-Flops» oder «Sind wirklich die armen Projektleiter schuld?»
Matthias Walti
16.07.2012 - 10:06Danke für den aufschlussreichen Beitrag. Um bei der Analogie zum Hausbau zu bleiben: hier gibt es für moderate Budgets Fertighäuser, die man in gewissen Bereichen noch anpassen kann. Sie mögen keine Architekturpreise gewinnen, aber ermöglichen es unkompliziert zu hoher Wohnqualität zu kommen. Es dünkt mich eine speziell schweizerische Eigenheit, auch im letzten Detail das Rad immer neu erfinden zu wollen („Wissen Sie, unsere Firma ist etwas speziell“). Letztmals erlebt bei einer einfachen Extranet-Lösung. Es gab sie pfannenfertig als Drupal-Distribution (in welche viele Monate Entwicklung eingeflossen sind). Klar hätte man die Features etwas der Software anpassen müssen (muss man beim Fertighaus ja auch), aber man baut lieber neu und teuer „from scratch“. Das Problem ist nicht zuletzt auf Interessenkonflikte der Anbieter zurückzuführen, die natürlich auch daran denken müssen, wie sie das Heer ihrer Coder beschäftigen.