Auch im Garagengespräch vom 30. Januar 2012 ging es engagiert zur Sache. Hier ist ein Überblick der Themen, die wir im Lauf der eineinhalb Stunden diskutiert haben:

Das Eingangsstatement: Plan und Ziel

Anlässlich der Planungsgespräche, die im Januar in vielen Firmen stattfinden, haben wir das Thema „Plan und Ziel“ eingeplant. Eine alte Projektmanagement-Weisheit lautet „Kein Schlachtplan überlebt den ersten Kontakt mit dem Feind“. Modernes Projektmanagement kennt dazu den Begriff der „Progressiven Elaboration“, der fortlaufenden Weiterentwicklung des Projektplanes während des laufenden Projektes. Das funktioniert hervorragend, solange das Ziel des Projektes von Anfang an klar ist. Der Haken an der Sache ist, dass wir in IT-Projekten oft das Ziel gar nicht wirklich kennen, bis die ersten Prototypen uns ermöglichen, das System und seinen Einfluss in der Praxis zu erleben. Also stellt sich die Frage: Wie viel „Ziel“ braucht der Plan von Anfang an, wie viel Ziel entsteht auf dem Weg?

Highlights der Diskussion

Visionen und Ziele

• Es gibt eine Forderung, dass eine Vision ~30 Jahre umfassen sollte. Ist das heute noch sinnvoll?
• Visionen sind nicht verhandelbar.
• Visionen sind so formuliert, dass sie den Lösungsraum der eigentlichen Aufgabe nicht (oder nur minimal) einschränken
• Um sicherzustellen, dass das Produkt sich noch dem eigentlichen Ziel annähert, ist eine ständige Validierung mit den Kunden erforderlich (siehe unten zu Politik)

Die Dichotomie: Engineering vs. Emotionalisieren

Für mich entstand in der Diskussion eine Unterscheidung zwischen „Engineering“ und „Emotionalisieren“. Vielleicht wäre das ein Thema für ein eigenes Garagengespräch. Engineering war charakterisiert durch Parallelen zum Maschinenbau, basierend auf der Hypothese: Wenn in der IT nur endlich anständiges Software Engineering betrieben würde, wäre auch IT viel besser planbar, und wir bräuchten die aktuelle Diskussion nicht führen, denn „Wasserfall“ wird machbar. Ein wesentliches Element dazu wäre eine saubere Zerlegung sowohl der Anforderungen als auch der Lösung in zueinander passende Einheiten. Dann könnte Innovation von überschaubaren, abgeschlossenen Einheiten stattfinden. Auch im Maschinenbau gab es agil-artige Ansätze („Concurrent Engineering“). Wie weit dieser Vergleich trägt, war umstritten: „Es gibt keine Physik in der IT“ war ein Slogan, Moore’s Law (umgangssprachlich: dass sich die IT-Performance alle 18 Monate verdoppelt) gibt es dafür in den klassischen Ingeneurwissenschaften nicht.

„Emotionalisieren“ deutet auf den intensiven Trend in der Software-Industrie hin, Produkte auch emotional attraktiv zu machen. Da die emotionale Wirkung noch schwerer vorhersehbar ist, passt das – aus meiner Sicht – offensichtlich hervorragend zu agilen Methoden. Henry Ford wurde zitiert: „Wenn ich die Menschen nach ihren Wünschen gefragt hätte, hätten sie geantwortet: schnellere Pferde“. Essentiell ist also, die Nutzer zu beobachten und nicht nur zu fragen, um Konzepte zu validieren. Im Zusammenhang mit Emotionalisierung leben dann Methoden wie Design-Led Innovation auf.

Ein spannender Teil-Aspekt dabei war, dass politische Überlegungen nicht nur auf der Anbieter/Hersteller/Dienstleister-Seite eine Rolle spielen, sondern bei komplexen Produkten auch beim Kunden: Ein Einkäufer will den Preis drücken, ein Vorstand will die Auswertungen, und die Mitarbeiter wollen ein sinnvolles User-Interface für die Datenerfassung. Diese Interessen haben miteinander nichts zu tun.

Notfall-Einsätze („War Rooms“)

Gerade im Kontext von sehr großen Konzernen, auch und gerade mit Wasserfall-Prozessen, wurde der überraschende Effekt berichtet, dass in Notfällen auch ein Großkonzern üblicherweise von einigen wenigen Personen abhängt. Eine gängige Praxis ist wohl, diese Personen dann in ein Notfall-Projekt zusammenzubringen. Diese Notfallprojekte wurden charakterisiert durch:

• Klare Ziele, hohe Autonomie in der Umsetzung („offene“ Pläne)
• Weitgehende Entscheidungsbefugnisse für die Mitarbeiter des Notfall-Projektes
• Hohe Ehrlichkeit (wobei sich in meinem Verständnis „Ehrlichkeit“ qualitativ über „Transparenz“ hinausgeht und umfasst)
• Volle Unterstützung der Unternehmensführung, sowohl moralisch als auch mit Ressourcen.

Und: Normalerweise liefern diese Notfallprojekte zuverlässig ein brauchbares Ergebnis (auch wenn keine belastbaren Daten zum Thema bekannt waren).

Umgekehrt liegt die Vermutung nahe, dass normale Projekte diese Punkte nicht erfüllen, das würde eines oder mehrere der Folgenden bedeuten:

• auch wenn die Ziele nicht klar sind, wird ein – eventuell sogar zertifizierter – Prozess abgearbeitet
• die Entscheidungsbefugnisse sind mehr oder weniger von der Fachkompetenz getrennt,
• Ehrlichkeit und Transparenz haben Verbesserungsbedarf
• Die Unternehmensführung unterstützt die Projekte nicht, Ressourcenknappheit kann von Mitarbeitern auch als Geringschätzung erlebt werden.

Leider wurde die mehrfach gestellte Frage, was wir daraus für Standard-Projekte lernen könnten, in der Runde nicht beantwortet. War Rooms wurden als ultimatives Versagen der Organisation bezeichnet. Meine Interpretation ist: Auch wenn ihr Ursprung im Versagen liegt, sind War Rooms trotzdem ein Prototyp für agile Methoden und Scrum. Allerdings muss der Anspruch an „Sustainable Pace“ noch hinzugefügt werden. Und dann stellt sich noch die Frage, wie diese Punkte in der Praxis realisiert werden können: Ehrlichkeit kann einfach außerhalb einer War-Room-Atmosphäre mit der eigenen Karriere interferieren, und so weiter.

Links

Seite mit Hinweisen zu Bau-/Ingenieurprojekten, die deutlich aus dem Zeitplan und/oder Budget liefen: Wikipedia: Cost Overrun

Dieser Quora-Thread Why are software development task estimations regularly off by a factor of 2-3? enthält viele einschlägig interessante Beiträge.