Projekte scheitern nicht am Ende, Projekte scheitern zu Beginn. Der Projektstart erfordert die ganze Führungserfahrung des Projektleiters. Anstatt aber das Projekt mit seinem Umfeld aktiv zu gestalten, anstatt also am System zu arbeiten, wird sofort losgelegt, einfach mal gemacht, also im System gearbeitet. Selbst wenn die Ziele und der Umfang noch gar nicht so genau bekannt sind. Einige wenige Tage Projektinitialisierung bringen erstaunlichen Nutzen: unausgesprochene Annahmen kommen frühzeitig auf den Tisch anstatt sich in der Tiefe des Projekts gärend anzustauen. Die folgenden Vorgehensweise hat sich für mich bewährt.
Am Anfang eines Workshops zur Projektinitialisierung steht die Frage nach dem Nutzen und den Zielen: Warum soll das Projekt gemacht werden? Die Gründe sind vielfältig und reichen von der Erfüllung neuer gesetzlicher Vorgaben über die Ablöse veralteter Technologien bis hin zu einer völlig neuen strategischen Ausrichtung eines Unternehmens. In der Praxis findet sich meist aber eine Mischung aus mehreren Gründen, z.B. wenn eine alte Software auf dem Mainframe nach SAP migriert werden soll und die gesetzlichen Anforderungen eine willkommene Begründung dafür liefern. Eine solche Vermischung von verschiedenen Nutzenaspekten des Projekts führt meist zu Abhängigkeiten und teilweise zu Widersprüchen. Das ist völlig normal und auch beherrschbar, aber nur wenn man diese Abhängigkeiten kennt und in der Planung berücksichtigen kann. Um im Beispiel der SAP-Migration aufgrund gesetzlicher Anforderungen zu bleiben, wäre es vielleicht sinnvoll eine erste Phase so zu planen, dass auf jeden Fall die gesetzlichen Bestimmung erfüllt werden auch wenn andere Funktionen noch fehlen und die Migration noch nicht abgeschlossen ist.
Nach dem Nutzen geht es zu den Projektinteressenten: Wer ist direkt oder indirekt vom Projekt oder den Ergebnissen des Projekts betroffen oder hat Interesse am Projekt? Auch diese Umfeldanalyse ist kein Hexenwerk, birgt aber erhebliche Risiken wenn sie schlampig oder gar nicht durchgeführt wird. Die Alarmglocken schrillen bei mir immer dann, wenn es heißt: „Ist doch eh alles klar!“ Ist es nämlich meist nicht. Oder ist jedenfalls nicht deckungsgleich. Wie beim Nutzen und den Zielen des Projekts liegt der Mehrwert einer sauberen Umfeldanalyse in einen Projektinitialisierungs-Workshop nicht nur im konkreten Ergebnis, also einer Liste von Zielen oder einer Stakeholder-Matrix, sondern hauptsächlich darin, dass explizit darüber diskutiert wird und sich ein gemeinsames Verständnis einstellt.
Während der Diskussion über Nutzen, Ziele und Interessenten werden normalerweise jede Menge Risiken entdeckt, die im dritten Teil des Workshops aufgesammelt und bewertet werden. Für sich genommen auch nicht schwierig, aber leider oft sträflich vernachlässigt: Wer beschäftigt sich zu Beginn voller Tatendrang schon gerne mit dem was schief gehen kann.
Sobald Nutzen und Ziele, das Umfeld und die Risiken ausreichend verstanden sind, kann mit der groben Phasenplanung begonnen werden. Im oben genannten Beispiel der SAP-Migration könnte sich z.B. ein Vorgehen in zwei Phasen ergeben: die erste Phase hätte das Ziel die gesetzlichen Bestimmungen zu erfüllen, während die zweite Phase, vielleicht sogar iterativ in kleinen Sprints, die fehlende Funktionalität liefert. Es geht in diesem Schritt darum das Projekt top-down zu planen und die großen Phasen, ihre Ziele und ihren Umfang grob zu definieren.
Nach einem Tag Workshop ist das Projekt damit grob umrissen und es herrscht ein gemeinsames Verständnis des Projekts. Der Anfang ist damit gemacht. Nun kann die erste Phase genauer geplant werden und ein Projektteam zusammengestellt werden.
Für eine Projektinitialisierung ist es nie zu spät. In abgewandelter Form lohnt sich ein solcher Workshop auch für bereits laufende Projekte zur Justierung oder auch zur Neuausrichtung.
Bildnachweis: Das Artikelbild wurde von Norlando Pobre unter dem Titel „Start your engine“ auf Flickr unter eine Creative Commons Lizenz (CC BY 2.0) veröffentlicht.