PHP Magazin | Scheiternde Projekte aus dem Disorder holen

Agile Projektmethoden werden als das Heilmittel für scheiternde und ausufernde Projekte angepriesen. Während der Gebrauch der unreflektierten Projektmethode „So wie beim letzten Mal“ mit dem Wasserfall-Verfahren verwechselt wird. Dabei findet oft nicht einmal eine bewusste Auseinandersetzung mit der genutzten Projektmethode und den zugehörigen Methodenbausteinen statt. Die Frage, die wir uns im Projektgeschäft stellen müssen, lautet: „Welcher Prozess passt zu den Anforderungen des Projekts?“ und nicht „Wie bekomme ich dieses Projekt in unseren Prozess?“

Die Antwort auf diese Frage liefert das Cynefin-Framework des Waliser Wissenschaftlers für Wissensmanagement Dave Snowden.

Wenn Projekte scheitern, wird meist die bisher im Unternehmen als Wasserfall-Verfahren bekannte und genutzte Projektmethode in Gänze als gescheitert angesehen.

Agiles Projektmanagement, häufig in Form von SCRUM, soll nun alles besser machen.

Viele verwechseln dabei allerdings im Unternehmen herangereifte und gewachsene genutzte Methode mit dem Wasserfall-Verfahren. 

Kick-Off-Meetings zum Projektstart, in dem alle vermeintlich offenen Fragen geklärt werden, lange Aufgabenlisten und Einigkeit darüber, dass geplante Aufgaben und Aufwände vom Projektmanagement verwaltet und kontrolliert werden. Nach bestem Wissen und Gewissen werden ToDo- und Checklisten erstellt, Tickets in ein Ticketsystem wie z. B. Jira eingearbeitet und möglicherweise sogar ein Meilensteinplan erarbeitet.

Wir kennen diese Methodenbausteine. Sie haben in der Vergangenheit gute Dienste geleistet und mit diesen waren wir in etlichen Projekten erfolgreich. Diese Erfolge nehmen wir zum Anlass die etablierte Projektmethode „So wie beim letzten Mal“ unreflektiert zu kopieren. Es wird keine bewusste Entscheidung getroffen, ob die kopierten Methodenbausteine im aktuellen Projekt ein sinnvolles Hilfsmittel sind. Meist fehlt die Zeit über im Unternehmen gewachsene Methodenbausteine zu reflektieren. Die Projektmethode „So wie beim letzten Mal“ etabliert sich. So unauffällig, wie sich die Projektmethode „SWBLM“ etabliert hat, kopieren sich auch gemachte Fehler unreflektiert von Projekt zu Projekt.

Die bewusste Entscheidung für oder gegen eingesetzte Methodenbausteine kann dabei helfen, fehlerhafte Patterns zu erkennen. Nur so ist es möglich, die gewachsene Projektmethode „SWBLM“ bewusst zu betrachten und in Frage zu stellen. Nur weil die ausführliche Checkliste bei Projekt A ein nützliches Hilfsmittel war, bedeutet dies nicht, dass sie auch bei Projekt B zum Erfolg beiträgt. Erst recht dann nicht, wenn sich die Projekte grundlegend unterscheiden.

Das klassisch bekannte Wasserfall-Verfahren zeichnet sich durch eine bewusste Auseinandersetzungen mit Methodenbausteinen des Projektmanagements aus. Bevor also eine gesamte Projektmethode als gescheitert gebrandmarkt wird, empfiehlt es sich aus unbewussten Entscheidungen bewusste zu machen (Das Erfolgsmodell SWBLM in Projekten).

Hinter der Forderung nach einer agilen Projektmethode kann auch ein anderer Wunsch liegen: Der Wunsch nach einem kooperativen Führungsstil. Manche Mitarbeiterinnen und Mitarbeiter fühlen, durch welche Konstellationen ein Projekt blockiert wird. Sie merken, dass die Aufgabenstellung eines Projekts für eine Person kaum zu überblicken ist und möchten über ihren eigentlichen Aufgabenbereich hinaus mit allen Beteiligten interagieren, um das Projekt anzutreiben. 

Hinter dem laut werdenden Ruf nach agilem Arbeiten kann also auch der Wunsch nach mehr Transparenz, Augenhöhe und einer ausgeprägten Feedbackkultur stehen.

Die Halbwertzeit des Internets ist gering. Projekte, die vor fünf Jahren noch einen Award gewonnen haben, möchte heute kaum noch einer ansehen, geschweige denn benutzen. Die Anforderungen an Projekte werden komplexer. Auf diese wachsenden und sich stets ändernden Anforderungen müssen Unternehmen und Teams reagieren. Agile Methoden können eine Antwort auf unterschiedliche Anforderungen sein – ob es sich dabei aber immer um richtige Antwort handelt, sollte individuell von Projekt zu Projekt entschieden werden.

Der Führungsstil eines Unternehmens darf nicht über die gewählte Projektmethode entscheiden. Er kann aber massiven Einfluss darauf haben. Während die agile Methode auf interdisziplinäre Teams und damit auf das fachliche Wissen eines gesamten Teams setzt, erwartet das klassische Wasserfall-Verfahren diese Exzellenz meist von einer Person.

Die genutzten Projektmethoden und agile Werte können Teil einer Unternehmenskultur sein. Ein Kulturwandel im Unternehmen lässt sich aber nicht allein durch das Ändern einer Projektmethode erreichen. Aus diesem Grund muss die Frage nach der richtigen Projektmethode unabhängig von der Unternehmenskultur betrachtet und Beweggründe stets genau heraus gearbeitet werden.

Für die Diskussion um die Auswahl der richtigen Projektmethode gibt es das Cynefin-Framework. 

Die Anforderungen an das Projekt sind klar. Es gibt nur eine richtige Antwort und Lösung für die geforderte Aufgabenstellung, die Best Practice. Das Gesamtprojekt ist überschaubar und es gelten einfache Ursache-Wirkung-Prinzipien. Die Erfassung und Steuerung der Aufgaben kann von einer Einzelperson übernommen werden. Das stoische Kopieren der Erfolgsmethode ist der richtige Weg.  

Ein Projektleiter oder eine Projektleiterin kann die ToDos in einer geeigneten Form wie zum Beispiel einer einfachen Liste auflisten. Entsprechend der herrschenden Unternehmenskultur werden diese ToDos durch direktive Vorgabe abgearbeitet oder in einem kooperativen Team mit einem Kanban-Board organisiert.

Ein Projekt bewegt sich im komplizierten Habitat, wenn Ursache und Wirkung zeitlich und räumlich voneinander getrennt sind. Es gibt nicht nur eine richtige Antwort für die Aufgabenstellung. Es stehen mehrere mögliche Lösungswege, Good Practices, bereit. Doch die tatsächliche Lösung muss an den individuellen Fall angepasst werden. Die Unterteilung des Projekts in Teilprojekte der einzelnen Disziplinen ist machbar und überschaubar. Die vorhandenen Good Practices machen das Projekt planbar, sodass Checklisten, Meilenstein-Pläne und Statusmeetings sinnvolle Methodenbausteine sein können. Die Aufgaben können in ihrer Reihenfolge abgearbeitet werden.

Das Habitat Complicated unterscheidet sich insofern von dem Habitat Obvious, als das es genauerer Planung und Kontrollpunkte bedarf, um am Ende das Ziel zu erreichen. Das einfache Kopieren einer gelernten Projektmethode wird das Projekt zum Scheitern bringen, wenn die Methodenbausteine nicht auf die gewählte Good Practice angepasst wurden.

„Lessons Learned“ und Statusmeetings helfen dabei das Projekt auf Kurs zu halten und einen Lernprozess über die genutzten Methodenbausteine für zukünftige Projekte anzustoßen. Projekte im Habitat „Complicated“ können über vorgegebene Lasten- und Pflichtenhefte oder in einer kooperativen Form geführt werden.

In einem direktiven Umfeld sollte der Projektleitung ein Tandempartner oder eine Tandempartnerin zur Seite gestellt werden, um den geforderten Überblick auf zwei Köpfe zu verteilen und gleichzeitig auch das Wissen von zwei Menschen nutzen zu können.

Das kooperative Projektteam organisiert alle Aufgaben in einer geeigneten Form, wie zum Beispiel einer Wandzeitung mit Kanban. Durch Daily StandUps schafft das Team Transparenz im Projektstatus und hält den Kurs. Retrospektiven oder Lessons Learned sorgen für zusätzlichen Fokus und den notwendigen Lernprozess für zukünftige Projekte.

Im komplexen Habitat gibt es zahlreiche Unbekannte. Das Projekt ist in den Mustern klar, die Anforderungen können sich aber im Laufe des Projekts verändern. Es gibt keine klaren Ursache-Wirkung-Prinzipien. Das Ziel des Projekts ist zwar SMART formuliert, lässt aber Detailfragen offen. Diese Fragen lassen sich möglicherweise erst im Laufe der Umsetzung beantworten. Auf Grund der vorhandenen Unbekannten ist es nicht möglich bereits im Vorfeld einen genauen Projektplan und ein umfassendes Lasten- oder Pflichtenheft zu erstellen. Grundfunktionen, einzelne Features und Meilensteine können zwar klar formuliert werden. Es ist aber möglich, dass sich diese während der Umsetzung in ihrer Priorität und ihrem Umfang verändern werden.

In einem solchen Umfeld muss eine Projektmethode eingesetzt werden, die das Wissen vieler vereint und dem Projektteam gleichzeitig die Möglichkeit gibt, im Laufe des Projekts zu lernen.

Agile Projektmethoden wie SCRUM oder Kanban sind im komplexen Habitat zu Hause. Sie vereinen das Wissen eines interdisziplinären Teams, um zu einem bestmöglichen Ergebnis zu gelangen. Die sich verändernden Anforderungen können durch inkrementelles Arbeiten wie zum Beispiel die Arbeit in geschlossenen Sprints schnell umgesetzt werden. Gleichzeitig liefert das iterative Vorgehen das perfekte Umfeld, um mit regelmäßigen Retrospektiven den Projektprozess stetig zu verbessern und auf die neuen Anforderungen anzupassen.

Das konsequente Verfolgen eines zu Beginn gemachten Plans kann nicht funktionieren, wenn sich das Ziel des Projekts im Laufe der Umsetzung verschiebt. Nur das regelmäßige Hinterfragen und die Neuausrichtung des Vorgehens bietet die Möglichkeit in einem angemessenen Zeitrahmen auf Änderungen zu reagieren. Das Projekt wächst wie ein Baum: Die Verästelungen sind zu Beginn nicht vorhersehbar und einzelne Äste können ihre Wachstumsrichtung ändern. 

Die Praxiserfahrung zeigt, dass Transparenz und Flexibilität in der Umsetzung nur dann erreicht werden können, wenn das Projektteam regelmäßige Retrospektiven nutzt, um das eigene Vorgehen zu hinterfragen. „Wir arbeiten agil, aber für die Retrospektive haben wir keine Zeit“ ist allzu oft der Grund, warum komplexe Projekt scheitern. Mit dem Verzicht auf Retrospektiven wendet das Team keine „Emergent Practice“ mehr an. Der Lernerfolg bleibt aus.

Eine lernende Projektmethode ist nur dann lernend, wenn es bewusste Rituale gibt, die sie zu einer solchen machen.

Im Habitat „Chaotic“ wird eine neue Aufgabe in einem neuen Umfeld bewältigt. Am Anfang steht eine Idee. Es wird zum Beispiel eine Art Prototyp gebaut. Der Projektverlauf ist geprägt durch zahlreiche Unbekannte, da es außer der ersten Idee noch keine konkreten Zielanforderungen gibt. 

Das Projektteam bewegt sich in einer „Novel Practice“. Hierfür muss das interdisziplinäre Team schrittweise vorgehen, um aus ersten Entwicklungen zu lernen und diese in eine neue Runde mitzunehmen. 

Methodenbausteine wie Retrospektiven und Sprints bieten dem Team die Möglichkeit in kurzen Intervallen zu lernen und kurzfristig auf Gelerntes zu reagieren. Gleichzeitig können Anforderungen, die sich erst während der Umsetzung entwickeln, zeitnah umgesetzt werden. Das Team muss während der Umsetzung herausfinden, welche die richtige Vorgehensweise für die Projektaufgabe ist. Dabei bestimmt es zunächst ein Minimal Viable Product. Risiko- und Nutzenanalysen, ebenso wie Akzeptanztests, wie sie aus der Projektmethode XP bekannt, sind typische Methodenbausteine im chaotischen Habitat, die das definierte Minimal Viable Product schärfen und verändern können.

Ein Projekt landet dann im Habitat Disorder, wenn das Projekt und die gewählte Projektmethode nicht zusammen passen. Das Projekt scheitert. Die Gründe für das Scheitern können unterschiedlich sein: Zu viele sinnfreie Meetings, obwohl eine Aufgabenliste ausgereicht hätte oder eine nicht 100%ig klare Zieldefinition. Entscheidend ist, in welchem Habitat versucht wurde das Projekt umzusetzen und in welchem es seinen eigentlichen Lebensraum hat. .

Immer dann, wenn Meilensteine nicht eingehalten werden können oder sich ein Projekt in der Krise befindet, ist eine ehrliche Reflexion über den aktuellen Status notwendig. Ein Teammeeting mit allen Beteiligten in dem die Gründe für die Krise erörtert werden, bietet die Möglichkeit das Habitat des Projektes zu hinterfragen und so möglicherweise ein endgültiges Scheitern des Projekts noch abzuwenden.

Aber auch dann, wenn sich das Scheitern eines Projekts nicht mehr aufhalten ließ, sollte in einer Retrospektive oder Post-Mortem-Analyse offen über das Habitat gesprochen werden, um für zukünftige Projekte zu lernen.

Die bewusste Auseinandersetzung mit Projektmethoden schafft für Euch Klarheit über sinnvolle und nicht sinnvolle Methodenbausteine. Sie hilft Euch außerdem, das Habitat Disorder schneller zu erkennen und entsprechende Maßnahmen zu vereinbaren.

Um die Einteilung nach Cynefin in Euren Projektalltag zu integrieren, kann Euch folgendes Vorgehen unterstützen:

1. Macht Euch mit Cynefin vertraut
   Organisiert ein Teammeeting, in dem Ihr Euch die unterschiedlichen Lebensräume anschaut und gegenseitig erklärt.
2. Ordnet Projekte ein
   Sucht Euch aktuelle und vergangene Projekte, die Ihr unabhängig voneinander in Cynefin einordnet. Betrachtet an dieser Stelle auch gescheiterte Projekte und versucht herausfinden, in welchem Habitat Ihr Euch bewegt habt und welches das richtige für die Aufgabe gewesen wäre.
3. Diskutiert und verhandelt
   Stellt Euch Eure Ergebnisse begründet vor. Diskutiert, welche Methodenbausteine Euch im Projekt weiter geholfen hätten und welche überflüssig waren. Verhandelt über das richtige Habitat und einigt Euch.
4. Schafft ein Ritual: „Drei Schritte zum richtigen Habitat“
   Entwickelt aus den Ergebnissen der Diskussion ein Cynefin-Ritual. Mit einer festgelegten Vorgehensweise schafft ihr es neue Projekte in den richtigen Lebensraum einzuordnen. Ihr lernt außerdem das Habitat Disorder schnell zu erkennen und bekommt das betroffene Projekt nach festem Muster wieder auf Kurs.

Die Einordnung von Projekten in die verschiedenen Lebensräume kann zu Beginn herausfordernd anmuten. Sicher ist aber: Es lohnt sich. Versprochen.

Der Artikel ist eine Zweitveröffentlichung des gleichnamigen Artikels in der Zeitschrift "PHP Magazin 02.2015" von Julia Schmidt.

• Nächster Artikel: Interview | Change, Sprints & Daily StandUps -- die Welt des agilen Arbeitens
• Vorheriger Artikel: Neues Starterset "Stick-it" von Neuland