Die Kunst des Projektmanagements besteht zu einem maßgeblichen Teil darin, Vorgehensweise, Methoden und Werkzeuge auf die jeweilige Projektsituation zuzuschneiden und kontinuierlich zu optimieren. Die Frage wie agil es sein darf und sein muss ist dabei eine ganz zentrale und hängt nicht zuletzt von der erwarteten Stabilität der Anforderungen ab. Meist darf es aber dann doch nicht so agil sein, wie es bei ehrlicher Betrachtung dieser erwarteten Stabilität sein müsste.
Projekt ist nicht gleich Projekt. Jedes Projekt ist per Definition der DIN ein Vorhaben, »das im wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist.« Folglich kann es das Projektmanagement im Sinne eines Kochrezeptes nicht geben und eine Standardisierung des Projektmanagements ist somit ein Widerspruch in sich und bleibt ein leeres Heilsversprechen.
Projektmanagement ist letztlich eine Sammlung von hochgradig abhängigen Aktionsfeldern mit jeweils mehr oder weniger gut erprobten Methoden, Techniken und Werkzeugen. Weder diese Aktionsfelder noch ihre jeweiligen Methoden sind einzeln betrachtet besonders kompliziert, vieles sogar einfach gesunder Menschenverstand. Vielmehr liegt die Schwierigkeit im Überblick und dem Sinn für die Zusammenhänge und Abhängigkeiten einerseits und in der Auswahl und im Setzen von zum Projekt und Umfeld passenden Schwerpunkten andererseits. Ein guter Projektmanager braucht also beides: den Überblick über alle Aktionsfelder und deren Methoden, also über das, was theoretisch getan werden könnte, und er braucht ein Gespür für das in der jeweiligen Situation Wesentliche und Notwendige, also das, was praktisch hier und jetzt getan werden sollte. Umfassendes Wissen und Neugier auch auf noch nicht so Erprobtes also gepaart mit praktischer Erfahrung und dem Mut zur klugen Wahl.
Die Crux des Projektmanagements liegt also darin, die Vorgehensweise und Methoden auf das Vorhaben und das Umfeld passgenau zuzuschneiden und kontinuierlich während der Laufzeit zu hinterfragen und anzupassen. Viele Merkmale eines Vorhabens müssen dabei beachtet werden, ein ganz wesentliches aber ist die zu erwartende Stabilität des Projektumfangs. Die Kernfrage ist: Wie realistisch kann zu Projektbeginn Ergebnis und Umfang des Projekts definiert werden?
Der Bau eines Einfamilienhauses nach bewährtem Plan an einem neuen Ort für einen neuen Kunden ist damit sicherlich besser definierbar als der Bau eines Dienstes wie Facebook oder Twitter für einen Markt, den es noch gar nicht gibt. Man kann beide Vorhaben mit der klassischen Vorgehensweise angehen: Umfang definieren, Projektstrukturplan und Arbeitspakete definieren, Ablaufplan erstellen, usw. In der Durchführung wird man dann aber feststellen, dass die Veränderung des Umfangs beim Bau des Einfamilienhauses die Ausnahme, beim Bau von neuen Diensten wie Facebook oder Twitter aber die Regel ist. Entsprechend leicht oder schwer fällt die Durchführung des Projekts nach dieser Methode, was nicht an der Methode oder ihrer kunstfertigen Anwendung per se liegt sondern allein an der jeweiligen Situation. Wie wenn man einen Schlitzschraubendreher für Schrauben mit Kreuzschlitz oder Torx verwendet: »Das kannste schon so machen, aber dann ist es halt Kacke.« (Neulich gesehen auf einem T‑Shirt.)
In diesen Zeiten großer Veränderungen gibt es immer mehr und immer größere Projekte und gleichzeitig wird es immer schwerer, zu spezifizieren wie das Ergebnis eines Projekts in drei Jahren aussehen soll. Trotzdem wird genau das oft genug verlangt und versucht. Diese Ungewissheit führt dann zu Instabilität der Anforderungen, die wiederum zu vielen mühsamen Anforderungsänderungen führt und am Ende zu Projekte die Zeit und Budget massiv sprengen (vergleiche die Studie von McKinsey und der Universität Oxford) und dennoch selten ein zufrieden stellendes Ergebnis liefern. Leider fehlen in großen Konzernen entweder die Erfahrung oder der Mut, solche Projekte von Anfang so agil aufzusetzen wie es der Ungewissheit der Anforderungen entspräche. Im Prinzip hat man die Wahl zwischen festem Zeitplan bzw. Budget einerseits und festem Umfang andererseits. Zeit, Budget und Umfang zu fixieren wird nur in Ausnahmefällen möglich sein und gut gehen. Der Umgang mit unscharfen Projektumfang scheint in vielen Unternehmen aber so verpönt, dass man eine Scheinwelt der Spezifikationen errichtet und lieber Zeit und Budget opfert als der Ungewissheit von Anfang an Rechnung zu tragen.
(Bildnachweis: Das Artikelbild wurde von Toshihiro Oimatsu unter dem Titel „Stones“ auf Flickr unter einer Creative Commons Lizenz (CC BY 2.0) veröffentlicht.)
3 Kommentare
Der Satz ist zum Einrahmen:
Der Umgang mit unscharfen Projektumfang scheint in vielen Unternehmen aber so verpönt, dass man eine Scheinwelt der Spezifikationen errichtet und lieber Zeit und Budget opfert als der Ungewissheit von Anfang an Rechnung zu tragen.
Schön, oder besser gesagt: schrecklich, dass ich scheinbar nicht der einzige bin, der das so empfindet …
„Die Kernfrage ist: Wie realistisch kann zu Projektbeginn Ergebnis und Umfang des Projekts definiert werden?“ – Ergänzend:
„wie kann die Komplexitätsschätzung statt Aufwandsschätzung eingeführt werden?“
„wie kann der Auftraggeber überzeugt werden, dass die Kosten- und Zeitschätzung nichts anderes als „Hausnummern“ sind?“
openPM könnte diese und ähnliche Fragen auf die Fahne schreiben. In Betrieben suchen die Leut´ bereits nach Antworten. (Die Methodensklaven haben aber keine Antworten.)