Das ideale Projektreview

“Wow, das war mal ein großartiges Projekt! Von Anfang bis zum Ende ein Erfolg!” Oder: “Leider konnten wir unser Projektziel nicht erreichen. Wir hatten keins definiert!” Zwei unterschiedliche Aussagen zum Ende eines Projekts. Zwei Aussagen, die so vielleicht im Zuge eines Projektreviews fallen könnten. Laut Definition ist ein Projektreview eine Nachbetrachtung einer abgeschlossenen Projektphase oder eines abgeschlossenen Projekts. Ziel ist es, aus der Vergangenheit zu lernen, um Projekte zukünftig noch besser zu gestalten. Was lief gut, was hätte besser laufen können und was lässt sich aus den gesammelten Erfahrungen lernen?

Leider klingt ein Projektreview in der Theorie deutlich leichter als es in der Praxis oftmals ist. Leicht wird schmutzige Wäsche gewaschen, Details werden in Diskussionen aufgebläht und der rote Faden und damit das Ziel gerät aus dem Blick. Wie lässt sich dies vermeiden? Wie wichtig sind Moderation, ein abgestimmter Ablauf und der Zeitpunkt für ein erfolgreiches Projektreview. Und wann ist es überhaupt ein erfolgreiches Review?

Der Zweck und Nutzen von Projektreviews

Der primäre Nutzen eines Projektreviews liegt meist in der Steigerung der Effizienz, also in der Frage, wie können wir ein solches oder ähnliche Projekte zukünftig noch schneller, kostengünstiger und/oder mit besseren Ergebnissen realisieren. Wirft man einen Blick hinter diese eher allgemeine Aussage, so lassen sich unterschiedliche Vorteile festhalten:

• Die Steigerung der Effektivität, beginnend bei der Priorisierung und Auswahl von Projekten. Als erstes ist es wichtig, das Richtige zu tun, in der Folge geht es darum, die “Dinge” richtig zu tun.
• Mehr Klarheit über Vorgehensweisen, Organisation, Planung, Aufgaben und Ziele.
• Die Identifikation von methodischen Schwächen wie bspw. bei der Erhebung von Anforderungen, bei der Durchführung von Brainstormings oder beim Umgang mit Impediments.
• Verbesserung der internen Zusammenarbeit, also in und zwischen Teams; dabei auch Verbesserung der Kommunikation, inklusive der Kanäle, der Häufigkeit und der Dauer.
• Optimierung der externen Zusammenarbeit, also mit Auftraggebern, Partnern, Kunden. Oder in anderen Worten: Verbesserung des Stakeholdermanagements.
• Die Ableitung von Best Practices oder idealerweise Good Practices und die Identifikation von Worst Practices.
• Die Ermittlung von definierten Metriken.

Diese Liste lässt sich beliebig fortsetzen. Damit ein Projektreview aber seinen Zweck erfüllt, sollten Organisationen diesen individuell zu Beginn des Austauschs, möglicherweise sogar im Vorfeld thematisieren und vereinbaren. In der Folge könnte sich bspw. die Zusammensetzung der Teilnehmer ändern. Handelt es sich z.B. um ein teaminternes Review, werden keinerlei Mitglieder anderer Teams oder Vertreter der Fachabteilungen eingeladen. Adressiert das Review die gesamte interne Organisation, werden externe Stakeholder nicht am Austausch teilnehmen.

Ein möglicher Ablauf eines Reviews

Natürlich gibt es unterschiedlichste Möglichkeiten Projektreviews durchzuführen. Neben rein organisatorischen Aspekten – wer nimmt daran teil, wann findet es wo statt, wie lange dauert es, wer moderiert es, wer visualisiert und dokumentiert die Erkenntnisse, wie ist der Umgang mit technischen Geräten während des Austauschs etc. – sowie der Bestimmung und Kommunikation des Zwecks bzw. der Ziele, gibt es meistens vier Phasen in einem Projektreview:

• Die Informationssammlung.
  Manchmal findet die Sammlung von Informationen bereits im Vorfeld durch Interviews oder per Fragebogen statt. Dies bietet einerseits den großen Vorteil, dass sich die Befragten nicht durch anwesende Kollegen oder Vorgesetzte beeinträchtigt fühlen – immer vorausgesetzt, dass im Unternehmen überhaupt eine offene und ehrliche Kommunikation erwünscht und auch tatsächlich möglich ist. Insbesondere introvertierte Mitarbeiter erhalten so die Chance, ihre Meinungen kundzutun. Die Durchführung von Interviews und/oder die Gestaltung von Fragebögen sind jedoch sehr aufwändig, zumal die Ergebnisse für den anschließenden Dialog ausgewertet und aufbereitet werden müssen. Dieser relativ große Aufwand führt daher oftmals zu einer Informationssammlung vor Ort, gemeinsam im Team.
  Bei der gemeinsamen Informationssammlung live und in Farbe ist der Moderator gefragt. Er gibt dem Ablauf eine Struktur und erläutert diese den Teilnehmern. Bspw. könnte er sich an Projektphasen wie Vorbereitung, Planung, Durchführung, Projektabschluss, Inbetriebnahme etc. orientieren. Oder er adressiert die jeweiligen Disziplinen wie Anforderungsmanagement, Projektmanagement, Changemanagement, Reporting. Welche Struktur sich am besten eignet, ist vom konkreten Projekt abhängig. Es empfiehlt sich aber, keine “künstliche” Struktur zu schaffen, sondern eine zu nutzen, die auch im Projekt selbst zum Tragen kam. Und natürlich geht es auch nicht um eine Trennung der Erkenntnisse, sondern um eine strukturierte Ermittlung. Daher sollte der Moderator auch auf verbindende Elemente zwischen den strukturgebenden Elementen achten, in dem er bspw. fragt: “Was hat bei der Zusammenarbeit zwischen Projektleiter und dem Vertriebsmitarbeiter als Vertreter des Kunden gut funktioniert, was können wir verbessern?”
• Der gemeinschaftliche Austausch über die gesammelten Informationen.
  Auch hier ist der Moderator wichtig, denn es gilt jeden Teilnehmer einzubinden und zu hören. Idealerweise sollten alle Teilnehmer ähnliche Redeanteile erhalten, Hierarchien im Unternehmen in den Hintergrund treten und das Miteinander bzw. der Austausch und das voneinander Lernen im Fokus stehen. Natürlich müssen auch negative Aspekte thematisiert werden, dies sollte aber wertschätzend und auch auf Augenhöhe geschehen; alles andere wäre nicht nur dem Zweck des Projektreviews sondern möglicherweise auch der zukünftigen Zusammenarbeit abträglich.
• Die Ableitung von Konsequenzen, Maßnahmen oder Verbesserungsvorschlägen.
  Ein offener und ehrlicher Austausch über Stärken und Schwächen der Projektarbeit fühlt sich für viele Teilnehmer oft gut an. Doch damit ist es nicht getan. Was ergibt sich aus den Erkenntnissen? Was sollte beim nächsten Mal ausprobiert, adaptiert oder einfach weggelassen werden? Hier gibt es idealerweise Raum für Gruppenarbeiten und -diskussionen, oder für Visualisierungen wie sie bspw. bei einer Starfish Retrospektive genutzt werden.
• Die Dokumentation und Verwaltung der Erkenntnisse und Maßnahmen.
  Wer einmal ein Projekt wie eine jährlich stattfindende Veranstaltung gemanagt und die Lessons Learned dokumentiert hat, weiß, dass auch das noch nicht alles ist. Wer sorgt dafür, dass im nächsten Jahr, wenn die erneute Planung und Durchführung der Veranstaltung ansteht, die Lessons Learned auch genutzt werden? Die Dokumentation der Erkenntnisse und Maßnahmen ist wichtig, aber ohne eine wie auch immer geartete Erinnerung, ein Vergegenwärtigen der Erfahrungen aus dem Vorjahr, ist sie nutzlos. Alles beginnt von Neuem. Erinnerungen werden genutzt, neue Überlegungen angestellt, aber die konkreten Ideen werden vergessen. Klingt komisch, ist aber sehr viel häufiger der Fall als man glauben würde.

Tatsächlich sollte es sogar noch eine fünfte Phase geben, denn die Frage “Wie geht es jetzt weiter?” bzw. “Was sind die nächsten Schritte, wer ist dafür verantwortlich und wann werden diese einem Review unterzogen?” bleibt häufig unbeantwortet. Es reicht nicht aus, “nur” Ideen zu entwickeln, es gilt diese in die Tat umzusetzen und anschließend zu bewerten: Funktioniert die Maßnahme oder Idee wie gedacht? Was müsste geschehen, damit sie ihre volle Wirkung entfaltet? Etc. Natürlich setzt dies auch voraus, dass es in absehbarer Zeit – im Zuge neuer Projekte – entsprechende Möglichkeiten zur Umsetzung gibt.

Die Beurteilung von Projekten

Es ist gar nicht so leicht, ein Projekt nach seinem Erfolg zu beurteilen. Ist ein Projekt erfolgreich, wenn es in Time and Budget fertig wird, die entwickelte Lösung aber im Markt keinen Anklang findet? Wie wichtig sind Time and Budget, wenn beides nicht eingehalten werden, die Lösung aber ein Verkaufsschlager wird? Im Sinne des Projektreviews können Sie sich dem Thema nähern, in dem Sie zwei wesentliche Fragen beantworten:

1. Würden Sie das Projekt mit Ihrem heutigen Wissen nochmals durchführen?
2. Wenn Sie es nochmals durchführen würden, dann auf dieselbe Art und Weise?

Wenn im Team die ehrliche Ansicht besteht, dass beide Fragen mit “ja” beantwortet werden können, dann haben Sie ein Projekt erfolgreich durchgeführt. Sie haben Ihre Ziele erreicht. Sehr gut. Beantworten Sie die zweite Frage mit

• “ja, aber mit einigen Anpassungen”,
• “ja, aber mit vielen Anpassungen”, oder mit
• “nein”,

dann war Ihr Projekt nur in Teilen ein Erfolg bzw. ein Misserfolg. Nun sollten Sie sich den “ja, aber …” Antworten widmen und die gewünschten Anpassungen in Erfahrung bringen. Sie könnten bspw. fragen,

• wie gut war die Projektorganisation, die Rollen und das Rollenverständnis, wie klar waren die Verantwortlichkeiten und Mitwirkungspflichten? Wurden alle Rollen besetzt, gelebt und akzeptiert?
• welche Konflikte gab es im Projekt, wie funktionierte der Informationsaustausch und wie wurde mit Änderungen und Unklarheiten umgegangen?
• wie waren die Prioritäten und Verfügbarkeiten einzelner Mitarbeiter und/oder Manager, Kunden, Experten?
• wie erfolgte die Projektplanung, wie war die Mitarbeiterauslastung und gab es Raum für Kreativität?
• was lief gut oder was könnte verbessert werden aus Sicht des Projektleiters, des Mitarbeiters, des Auftraggebers, des Product Owners, des Scrum Masters, des Entwicklungsteams …

Auch diese Liste lässt sich leicht erweitern. Im Internet finden Sie zahlreiche Beispiele für mögliche Fragen. Wichtig ist immer die konkrete Kontextbetrachtung; einen Scrum Master können Sie natürlich nur befragen, wenn es in Ihrem Projekt einen gibt.

Der ideale Zeitpunkt für ein Projektreview

Wann ist der ideale Zeitpunkt für ein Projektreview? “Kurze Feedbackschleifen” gelten als ein großer Vorteil agiler Vorgehensweisen in Projekten. Zur Verbesserung der Zusammenarbeit kennt u.a. Scrum das Konzept der Retrospektiven. Nach Ablauf eines Sprints, der zwischen einer und vier Wochen dauert, trifft sich das Entwicklungsteam, zu dem auch der Scrum Master und der Product Owner gehören, und bespricht Erkenntnisse, Learnings, Verbesserungsvorschläge. Diese “kurzen Feedbackschleifen” ermöglichen eine fortlaufende Optimierung der Zusammenarbeit. In vielen klassischen Projekten lässt sich eine solche Frequenz jedoch nicht (oder zumindest nicht so leicht) umsetzen.

Grundsätzlich ist der ideale Zeitpunkt für ein Projektreview abhängig vom konkreten Projekt. Bei einem Projekt mit einer Laufzeit von einer Woche, macht ein formales Review im laufenden Projekt vermutlich wenig Sinn. Natürlich ist dort auch eine Kommunikation im Laufe der Woche zwischen den Teilnehmern essentiell,  ein formales Review wird aber üblicherweise erst nach Projektabschluss durchgeführt. Bei einem Projekt mit einer Laufzeit von zwei Jahren, wäre es vermutlich keine gute Idee, sich erstmals nach dem Ende des Projekts über Lessons Learned auszutauschen.

Auch wenn es keine Faustformel für den richtigen Zeitpunkt von Projektreviews gibt, die Orientierung an den Lessons Learned bzw. dem zeitlichen Fokus hilft bei der Beantwortung der Frage: “Wollen und können Sie im laufenden Projekt bereits von den gesammelten Erfahrungen profitieren?” Falls ja, dann initiieren Sie ein Projektreview lieber heute als morgen. So lässt sich ein Projektreview auch nach jeder Projektphase, also bspw. nach jeder Iteration oder jedem Release durchführen.

Manchmal bietet es sich auch an, bei auftretenden Problemen ein situatives Review anzuberaumen. Dabei geht es aber meist nicht um allgemeine Fragestellungen, sondern um konkrete Herausforderungen, die für die weitere Projektgestaltung wesentlich sind. In einem solchen Fall werden natürlich die vier bzw. fünf Phasen des Projektreviews deutlich schneller durchlaufen.

Fazit

Bleibt noch eine Frage zu beantworten: Wann ist ein Projektreview erfolgreich? Es ist erfolgreich, wenn jeder für sich, das Team und die Organisation etwas aus der Vergangenheit lernt, und sich die Chance bietet, diese Erfahrungen zu nutzen. Das können kleine Dinge sein, die das gegenseitige Verständnis fördern. Es können evolutionäre Aspekte sein, wie die Reduzierung von Meetings. Oder revolutionäre Ideen wie … na, alles kann ich Ihnen ja hier nicht verraten …

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Hier finden Sie eine kostenlose Lessons Learned Vorlage zum Mitnehmen.

Michael Schenkel hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.