Der komplette Projektmanager. Roel Wessels
1.7 Zusammenfassung Deliverables des Projektmodells
Abschließend gibt Abbildung 1.7 eine Zusammenfassung aller Deliverables aus dem Projektmodell, wobei angegeben ist, ob das Eigentum, also die Verantwortung, primär beim Projektmanager oder Auftraggeber liegt. Damit will übrigens nicht gesagt sein, dass der Eigentümer auch der Ausführende sein muss. Als Projektmanager können Sie sich beispielsweise dafür entscheiden, den Business Case für den Auftraggeber auszuarbeiten. Dies bietet oft die Gelegenheit, selbst den Projektumfang zu beeinflussen. Aber, es ist wichtig, dass sich der Auftraggeber letzendlich als Eigentümer des endgültigen Business Cases fühlt, denn ansonsten begeben Sie sich als Projektmanager schnell auf Glatteis.
1.5 Agil denken und arbeiten
Funktioniert das Projektmodell auch in Situationen mit vielen Unsicherheiten (Cynefin komplex)? Die Anwort ist jein. Ja, weil auf der Ebene des Auftraggebers oftmals in der Struktur des Projektmodells gedacht und gehandelt wird:
Frage
Ihnen bleibt demnach gar nichts anderes übrig, als auf dieselbe Weise zu denken und zu kommunizieren.
Nein, weil das Projektmodell im Prinzip auf dem Wasserfallmodell basiert. Dies bedeutet, dass die Phasen nacheinander durchlaufen werden müssen und Sie demnach erst dann mit einer neuen Phase beginnen können, wenn die vorherige zu 100% abgeschlossen ist. Und es empfiehlt sich nicht, später zurück in eine vorherige Phase zu springen. Darum werden wir das Projektmodell in diesem Abschnitt mit agilen Elementen erweitern. Wir gehen dabei weder von Wasserfall oder reinem Agile aus, sondern wir nutzen die Kombination (der eine Teil des Projekts als Agile, der andere Teil als Wasserfall), denn dies ist auch, was Ihnen häufig im wirklichen Projektleben begegnet.
Das Wasserfallmodell
Im Wasserfallmodell beginnen Sie erst dann mit dem Entwurf, wenn alle Forderungen bekannt sind. Und die Testphase wird erst dann durchlaufen, wenn der vollständige Entwurf realisiert wurde. Wird ein Fehler aufgedeckt oder muss etwas verändert werden, so begeben Sie sich zurück in die diesbezügliche Phase und der Projektpfad wird ab diesem Punkt erneut durchlaufen. Eine lästige Gegebenheit bei Situationen mit vielen Unsicherheiten. Diese bieten nämlich niemals eine 100%ige Vollständigkeit. Außerdem ist die Gefahr hoch, dass es doch noch zu Änderungen an den Spezifikationen kommt, während Sie bereits entwerfen. Wasserfall in Cynefin komplexen Projekten bedeutet also das Warten auf Deutlichkeit, während Sie wissen, dass weitere Korrekturen anstehen werden…?
Concurrent Engineering
Um die Schmerzen zu lindern, kann Concurrent Engineering, bzw. paralleles Entwickeln angewendet werden. Beim Concurrent Engineering dürfen Projektphasen nämlich parallel ausgeführt werden. Es wird dann bereits am Entwurf gearbeitet, während die Spezifikationen noch nicht ganz klar oder vollständig sind. Dies bietet die Gelegenheit, auch bei Unsicherheiten dennoch einen Fortschritt verbuchen zu können.
In aller Fairness muss gesagt werden, dass der wahre Grund für Concurrent Engineering oftmals ein Kürzen der Projektdauer ist. Indem die Beteiligten nicht nacheinander an Ihren Themen arbeiten, sondern gleichzeitig, wird das Projekt sozusagen zusammengepresst. Das ist keineswegs verkehrt, macht die Projektausführung aber komplexer. Denn das simultane Arbeiten an Aktivitäten, die eigentlich nacheinander geschehen sollten, verlangt viel Geschick der Mitglieder des Teams, sehr gute Einsicht in die Arbeiten des Anderen und ein hohes Maß an Kommunikationsfähigkeit von allen.
Abbildung 1.8 Das Wasserfallmodell
Abbildung 1.9 Concurrent Engineering
Agile: Unsicherheiten sind Tatsachen
Obwohl Concurrent Engineering also einen Schritt in Richtung Flexibilisierung bedeutet, wird dies durch eine höhere Ausführungskomplexität erkauft. Außerdem geht die Methode, genau wie das Wasserfallmodell, davon aus, dass jede Phase vollständig abgeschlossen sein und Unsicherheit zunächst aus dem Weg geräumt werden muss. Aber was ist, wenn dies nicht gelingt?
Die Agile Methodik (der italienische Musikbegriff “agile” bedeutet schnell bzw. beweglich) dreht dies ins genaue Gegenteil. Agile sieht Unsicherheiten als gegebene Tatsachen an und nicht als etwas Unerwünschtes. Es geht davon aus, die Welt könne eben nicht geformt werden und Projekte in einem unsicheren, dynamischen Umfeld sind demnach nicht vorhersehbar. Zusätzlich schafft agiles Arbeiten ein Umfeld, in dem das Tragen von Verantwortung durch die Mitglieder des Teams explizit stimuliert und ermöglicht wird. Hierdurch kann der Projektmanager eine eher coachende und fördernde Haltung annehmen und muss nicht mehr leitend oder direktiv sein. Agiles Arbeiten ist für die Softwareentwicklung entworfen worden, aber kann mit etwas Geschicklichkeit auch in anderen Umfeldern eingesetzt werden. Beispielsweise in der Mechatronik, im Bau- und öffentlichen Sektor, etc.
Obwohl PRINCE2 und andere Methoden den agilen Ansatz inzwischen integriert haben, werden das Wasserfall- und das Agile-Modell oftmals als Gegensatz wahrgenommen. Das ist schade, denn das hebt künstlich die Unterschiede hervor, während es doch in der Realität gar nicht praktikabel ist, entweder rein Agile oder nur nach dem Wasserfallmodell zu arbeiten. Die Modelle bestehen nebeneinander und das sollte die Projektausführung auch nicht erschweren. Dennoch tun sich viele Organisationen mit der Kombination von mechanischer Produktentwicklung (Wasserfall) und Softwareentwicklung (Agile) schwer. Die Teams sprechen nicht dieselbe Sprache und sehen den Prozess des jeweils anderen Teams als eine unbegreifliche Blackbox an. Hierdurch können selbst innerhalb einer Organisation verschiedene Welten entstehen, die einander unzureichend verstehen und nebeneinander her anstatt zusammen arbeiten.
Schwarz-Weiß-Denken in Agile versus Wasserfall wird sich also kontraproduktiv auswirken. In diesem Buch möchte ich betonen, wie Sie beide Methoden miteinander kombinieren können. Dazu werde ich Agile nicht nur als Methode, sondern auch als Verhalten besprechen. Agiles Verhalten bietet nämlich auch innerhalb von traditionell organisierten (Wasserfall-)Projekten Möglichkeiten, um die Wendigkeit, den Fokus auf Produktinkremente und die Autonomie der Teammitglieder zu erhöhen.
Kurze Iterationen
Ein wichtiger Unterschied von Agile im Gegensatz zum traditionellen Projektansatz ist die Methode der Projektkontrolle. In einem traditionellen Projekt wird der Projektumfang meist als fix und unveränderlich angesehen. Bei Rückschlägen oder Änderungen bedeutet dies automatisch, dass das Projekt länger dauert und mehr Kosten entstehen. Dieser Druck hinsichtlich Zeit und Budget bewirkt anschließend die Reaktion, während der des Projekts den Plan zu korrigieren, wobei es nicht ungewöhnlich ist, dass Qualität eingebüßt wird: Zum Beispiel wird weniger Zeit für die Ausführung der Aufgaben veranschlagt, Reviews werden gekürzt, der Fokus liegt weniger auf dem Risikomanagement, das Testprogramm wird gekürzt, etc.. Der Druck entsteht dabei in der Regel besonders in der letzten Phase des Projekts.
In agilen Projekten werden Zeit, Geld