Und wieder ein gescheitertes IT-Projekt

Die Berichte über gescheiterte IT-Projekte beim Bund häufen sich. Die jüngsten Beispiele sind Insieme, Astra  und ASALneu. Aber auch in der Wirtschaft gibt es vergleichbare Vorfälle, wie zum Beispiel das Erneuerungsprojekt der IT-Plattform der Raiffeisen-Gruppe. All diesen Projekten gemeinsam ist ihre Grösse und Komplexität.

IT-Projekte mit einem Budget von zig Millionen Franken und deutlich mehr als 30 Personenjahren Aufwand beherbergen enorme Risiken, die von den Auftraggebern oft unterschätzt werden. Als Gründe für ein Scheitern gelten verpasste Meilensteine, nicht eingehaltene Spezifikationen oder, wie im Fall des kürzlich gescheiterten Astra-Projekts, schlechte Performance. Das sind jedoch nur die Auswirkungen.

Gründe für gescheiterte IT-Projekte

Die Gründe für gescheiterte IT-Projekte liegen tiefer. Dem verständlichen Wunsch des Auftraggebers nach Kosten- und Planungssicherheit kommt der Lieferant mit umfassenden Spezifikationen über das Gesamtprodukt nach. Diese Spezifikationen sind Papierberge von mehreren hundert Seiten, die – sind wir ehrlich – niemand im Detail liest und, sollte sie doch jemand lesen, niemand versteht.  Oft werden diese Dokumente für die eigene Absicherung verfasst. Daneben stehen die Wünsche des Kunden. Wenn man so viel Geld in die Hand nimmt, soll das Ergebnis auch alle Wünsche abdecken.

Oft bestehen bereits Systeme, die abzulösen sind. Diese sind über Jahre gewachsen und haben sich zu wahren Funktionsmollochen entwickelt. Diese Funktionalitäten möchte man nicht aufgeben, auch wenn teilweise gar nicht klar ist, ob sie überhaupt genutzt werden. So startet man bereits mit einer extrem grossen Komplexität. Während des Projekts kommen dann noch weitere Wünsche hinzu, da sich die Welt während des Projekts weiter dreht.

Entscheidend: Der Faktor Mensch

Schlussendlich ist da noch der Faktor Mensch. Auch wenn Informatik immer den Touch des Analytischen und Technischen hat, IT-Projekte sind vor allem People Business. IT ist nicht Selbstzweck und die Software wird in einer Fachdomäne genutzt, die oft sehr weit von der Informatik entfernt ist. Im Banking, Bauwesen, Verkehrswesen, etc. arbeiten Leute, die in diesen Gebieten ausgebildet wurden und mehrjährige Berufserfahrung haben. Sie sprechen eine andere Sprache, haben andere Wertvorstellungen und andere Arbeitsabläufe.

Das Schlagwort heisst „Interdisziplinarität“. In vielen dieser Grossprojekte klafft eine unüberwindbare Hürde zwischen Auftraggeber und Lieferant. Man redet aneinander vorbei und am Ende reduziert es sich auf den Satz: „Die Anforderungen wurden nicht umgesetzt“ oder einfacher ausgedrückt: „Das habe ich mir nicht so vorgestellt“. Dabei reicht es nicht, dass eine Handvoll Business Analysten die Domäne verstehen.

Aufteilen, Einschränken, Iterieren, Kommunizieren

• Grossprojekte sollten möglichst in Teilprojekte zerlegt werden, die für sich testfähig und eventuell sogar einsatzfähig sind. Hier bieten sich agile Entwicklungsmethoden an. Dabei sollte man sich konsequent auf das benötigte Minimum beschränken. Hierzu liefern die Erfahrungen aus dem Lean-Startup-Bereich viele Denkanstösse.
• Mit den gleichen Ansätzen kann auch das zweite Problemfeld, die Behebung technologischer Schulden aus der Vergangenheit, angegangen werden. Schrittweise Ablösung mit einer klaren Vision über die Zielarchitektur erlaubt das Risiko einer Big-Bang-Einführung zu reduzieren. Die technischen Voraussetzungen sind mit serviceorientierten Architekturen (SOA) und Cloud-Lösungen längstens gegeben. Zentraler Aspekt hierbei ist das Thema Schnittstellen, das nicht vernachlässigt werden darf.
• Kosten- und Planungssicherheit ist Vertrauenssache. Die Erfahrung hat gezeigt, dass auch mit umfangreichen Spezifikationen und Fixpreisverträgen kein Erfolg garantiert werden kann. Vertrauen kann nur über die Zeit aufgebaut werden. Auch hier hilft ein iteratives Vorgehen. Kann dem Kunden in kurzen Zyklen funktionierende Software vorgestellt werden, gewinnt er Vertrauen zum System und zum Lieferanten. Dabei müssen sich beiden Parteien über das Ziel im Klaren sein und es muss eine Kultur aufgebaut werden, die auch Fehler und Rückschläge erlaubt.
• Wobei wir beim Faktor Mensch wären. IT-Projekte sind Gemeinschaftswerke, bei denen jeder Partner sein Know-how einbringt: Der Kunde das Domänenwissen und der IT Provider sein technisches Wissen. Für diese Zusammenarbeit ist gegenseitiges Verständnis unverzichtbar. Interdisziplinarität ist ein Key Asset auf dem heutigen Arbeitsmarkt.

Interdisziplinäre Ausbildung macht den Unterschied

Damit ist die Schulung der interdisziplinären Arbeitsweise eine Verpflichtung für die Ausbildung. Die Hochschule Luzern hat dieses Thema deshalb zu einem ihrer Schwerpunkte gewählt. Neben der interdisziplinären Arbeit unter den Departementen und den interdisziplinären Schwerpunkten geht die Zentralschweizer Bildungsinstitution noch einen Schritt weiter. Sie vereint technische Informatik und Wirtschaftsinformatik ab Sommer 2016 am neuen Campus Rotkreuz. Durch die enge Zusammenarbeit von „Blue Collar“ und „White Collar“, die gemeinsame Ausbildung und gemeinsame Forschung wird das gegenseitige Verständnis gefördert.

Ziel ist es, dass Studierenden als interdisziplinär denkende Profis ins Berufsleben einsteigen und ein Stück dazu beitragen, dass Hiobsbotschaften über gescheiterte IT-Projekte der Vergangenheit angehören.