{"id":199,"date":"2015-09-02T08:28:18","date_gmt":"2015-09-02T06:28:18","guid":{"rendered":"https:\/\/hub.hslu.ch\/informatik\/?p=199"},"modified":"2026-02-10T11:23:37","modified_gmt":"2026-02-10T10:23:37","slug":"und-wieder-ein-gescheitertes-it-projekt","status":"publish","type":"post","link":"https:\/\/hub.hslu.ch\/informatik\/und-wieder-ein-gescheitertes-it-projekt\/","title":{"rendered":"Und wieder ein gescheitertes IT-Projekt"},"content":{"rendered":"\n\n\n

Die Berichte \u00fcber gescheiterte IT-Projekte beim Bund h\u00e4ufen sich. Die j\u00fcngsten Beispiele sind Insieme<\/a>, Astra<\/a>  und ASALneu<\/a>. Aber auch in der Wirtschaft gibt es vergleichbare Vorf\u00e4lle, wie zum Beispiel das Erneuerungsprojekt der IT-Plattform der Raiffeisen-Gruppe<\/a>. All diesen Projekten gemeinsam ist ihre Gr\u00f6sse und Komplexit\u00e4t.<\/p>\n\n\n\n

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\u00e4tzt werden. Als Gr\u00fcnde f\u00fcr ein Scheitern gelten verpasste Meilensteine, nicht eingehaltene Spezifikationen oder, wie im Fall des k\u00fcrzlich gescheiterten Astra-Projekts, schlechte Performance. Das sind jedoch nur die Auswirkungen.<\/p>\n\n\n\n

Gr\u00fcnde f\u00fcr gescheiterte IT-Projekte<\/strong><\/p>\n\n\n\n

Die Gr\u00fcnde f\u00fcr gescheiterte IT-Projekte liegen tiefer. Dem verst\u00e4ndlichen Wunsch des Auftraggebers nach Kosten- und Planungssicherheit kommt der Lieferant mit umfassenden Spezifikationen \u00fcber das Gesamtprodukt nach. Diese Spezifikationen sind Papierberge von mehreren hundert Seiten, die \u2013 sind wir ehrlich \u2013 niemand im Detail liest und, sollte sie doch jemand lesen, niemand versteht.  Oft werden diese Dokumente f\u00fcr die eigene Absicherung verfasst. Daneben stehen die W\u00fcnsche des Kunden. Wenn man so viel Geld in die Hand nimmt, soll das Ergebnis auch alle W\u00fcnsche abdecken.<\/p>\n\n\n\n

Oft bestehen bereits Systeme, die abzul\u00f6sen sind. Diese sind \u00fcber Jahre gewachsen und haben sich zu wahren Funktionsmollochen entwickelt. Diese Funktionalit\u00e4ten m\u00f6chte man nicht aufgeben, auch wenn teilweise gar nicht klar ist, ob sie \u00fcberhaupt genutzt werden. So startet man bereits mit einer extrem grossen Komplexit\u00e4t. W\u00e4hrend des Projekts kommen dann noch weitere W\u00fcnsche hinzu, da sich die Welt w\u00e4hrend des Projekts weiter dreht.<\/p>\n\n\n\n

Entscheidend: Der Faktor Mensch<\/strong><\/p>\n\n\n\n

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\u00e4ne 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\u00e4hrige Berufserfahrung haben. Sie sprechen eine andere Sprache, haben andere Wertvorstellungen und andere Arbeitsabl\u00e4ufe.<\/p>\n\n\n\n

Das Schlagwort heisst \u201eInterdisziplinarit\u00e4t\u201c. In vielen dieser Grossprojekte klafft eine un\u00fcberwindbare H\u00fcrde zwischen Auftraggeber und Lieferant. Man redet aneinander vorbei und am Ende reduziert es sich auf den Satz: \u201eDie Anforderungen wurden nicht umgesetzt\u201c oder einfacher ausgedr\u00fcckt: \u201eDas habe ich mir nicht so vorgestellt\u201c. Dabei reicht es nicht, dass eine Handvoll Business Analysten die Dom\u00e4ne verstehen.<\/p>\n\n\n\n

Aufteilen, Einschr\u00e4nken, Iterieren, Kommunizieren<\/strong><\/p>\n\n\n\n