Heiteres Zahlenraten zum Jahresende

Die termin- und kostengerechte Realisierung von Informatiklösungen ist scheinbar nach wie vor die Ausnahme von der Regel. Besonders das Jahr XXXX war gekennzeichnet von mehreren allzu prominenten Beispielen...»
Was denken Sie habe ich da wieder gegoogelt? Handelt es sich um das Jahr 2012, in dem das Informatikprojekt Insieme der Schweizer Bundesverwaltung scheiterte und 100 Millionen Franken den Bach runtergingen? Oder reden wir von der 2005 gestellten Klage über 5,1 Milliarden Euro gegen das Maut-Konsortium, welches in Deutschland Toll-Collect zu spät und in technisch reduzierter Form online brachte? Wir könnten aber auch über Adonis, ein gescheitertes Informatikprojekt aus Österreich mit einem Auftragsvolumen von 310 Millionen Euro aus dem Jahr 2002, oder das DIA-Gepäcksystem aus dem Jahr 1993 reden. Wegen der Verzögerung beim DIA-Gepäcksystem wurde der Flughafen in Denver mehr als ein Jahr später eröffnet. Vielleicht denken Sie aber auch schlicht «Was redet der von Multimillionen-Projekten, das ist bei uns in der Firma seit 20 Jahren bei jedem IT-Projekt so.»

Wie wir es drehen und wenden, IT-Projekte scheitern. Regelmässig. Sie werden zu spät geliefert oder leisten nicht, was sich die einzelnen Teilnehmer anfangs selbst versprochen haben. Das Anforderungs-Management, das ganz am Anfang eines jeden Software- und Applikationsmanagements steht, scheint wieder einmal versagt zu haben. Aber ist das so schlimm? Offensichtlich ist ein gescheitertes IT-Projekt immer noch besser als kein IT-Projekt. Trotz Trümmern, Enttäuschungen und frustrierten Projektteilnehmern startet schon kurz nach dem letzten Projekt das nächste. Und oft bringt eine zu spät gelieferte Software mit weniger Umfang immer noch einen Mehrwert.
Was lernen wir daraus? Offen gestanden, sehe ich wenig Lernfortschritte bei den Auftraggebern, den Projektteilnehmern und den Entwicklern. Es kommen zwar immer mal wieder neue Projekt-Management-Methoden auf den Markt und werden heiss besprochen. Bei den Anwendern sorgen die meisten Methoden unter dem Strich aber für denselben Frust. Selbst die hochgelobte agile Entwicklung wird im Nachhinein vielfach enttäuscht angeschaut, weil die Software-Entwicklung immer noch lange dauert, die Software am Schluss weniger Funktionen hat und mehr kostet, als man sich anfangs vorstellte.

Ratgeber, Leitsätze, Fachartikel, Blogs und Konferenzen gibt es genug zum Thema, und im Grundsatz werden immer die selben Punkte durchgekaut: Besser beschreiben, besser dokumentieren, besser kontrollieren, besser planen – und dies seit 30 Jahren.
Da Sie diese Kolumne lesen, erwarten Sie von mir bestimmt einen neuen Ansatz, eine Idee, wie Sie in Zukunft das Applikations-Management verbessern und den womöglich existierenden Graben zwischen der Entwicklung und der Verkaufs-Projektleitung aus der Welt schaffen können. Mein Vorschlag: Spielen Sie das Bierspiel. Rufen Sie Ihr Team zusammen – inklusive den Kunden – und legen Sie los. Aber Achtung: Mit dem Bierspiel meine ich kein gemeinsames Besäufniss, um sich die Projektresultate schönzutrinken, sondern ein ernsthaftes Spiel (mehr dazu unter www.beergame.lim.ethz.ch). Dabei schlüpfen die einzelnen Teilnehmer in Teams in die Rolle einer Bar, eines Grosshändlers, eines Vertriebszentrums und eines Produzenten. Gemeinsam versuchen sie dann eine Balance zwischen Produktion, Verkauf und Absatz zu schaffen. Es ist ein sicherer Rahmen, indem Sie aufregende Parallelen zur Software-Entwicklung entdecken werden und plötzlich ganz andere Gespräche mit neuen Analogien führen. Es sensibilisiert die Kunden, den Verkauf, die Projektleiter und die Entwickler über Formulare, Anforderungsprofilen und die üblichen Probleme hinauszudenken.