Frohe Weihnachten

Das folgende Video passt so wunderbar zur Festzeit:

Projektreviews

Projektreviews sind keine Erfindung agiler Vorgehensmodelle. Es gibt zahlreiche Spielarten von Projektreviews, die sich je nach Zeitpunkt, Teilnehmerkreis und Ziel unterscheiden. Beispiele sind die Projektrevision, das Projektaudit, die Projektrückschau oder das Post-Project Appraisal.

Allerdings wird ihr Einsatz in agile Vorgehensmodellen intensiviert: Agile Modelle schlagen nach jeder Iteration eine Retroperspektive vor. Diese ist zwar nicht so umfangreich, wie ein ausgewachsenes Projektreview, verfolgt aber den gleichen Zweck. Ziel ist immer aus den Erfahrungen der vergangenen Iteration bzw. des vergangenen Projektes zu lernen. Aus diesem Grund können die Techniken zur Durchführung beider Ansätze gut kombiniert werden.

Mögliche Inhalte des Reviews:

• Bewertung der erreichten Projektziele: Zielerreichungsgrad der Leistungsziele wird bewertet.
• Reflektion der Beziehungen zwischen den Projektmitgliedern: Dieser Schritt beinhaltet insbesondere die Bewertung der internen Kommunikation und der Kommunikation mit dem Auftraggeber.
• Sicherung von Schlüsselerfahrungen: Offene Diskussion von Stärken und Schwächen im Projekt: „Was lief gut – Wo haben wir Potenzial?“
• Betrachtung der neuen Werkzeuge und Methoden: Übernahme von Erfahrungen bei der Nutzung vorhandener Werkzeuge und die Diskussion über im Projekt entwickelte Werkzeuge und Methoden.
• Identifikation von Best Practices: Weitergabe von bewährten Vorgehensweisen an neue Projekte.

Einige der Bewertungen, wie der Zielerreichungsgrad der Projektziele, müssen gemeinsam mit dem Auftraggeber vorgenommen werden. Andere Punkte, z.B. die Identifikation von Best Practices, erfolgen intern. Aus diesem Grund empfiehlt es sich zwei Reviewtermine anzusetzen: Einen externen (evtl. unter Einbeziehung des Lenkungsausschusses) und einen internen mit dem Projektteam.

Ein ernsthaftes Review benötigt ausreichend Raum und Zeit. Es sollte nicht als letzter Termin am Freitagabend eingeplant werden. Versuchen Sie für alle Beteiligten eine angenehme Atmosphäre zu schaffen. Sorgen Sie für ein angenehmes Raumklima und ordentliches Catering. Wichtig ist auch, die Spielregeln für das Projektreview im Vorfeld abzustecken. Als Vorlage können z.B. die TZI-Regeln dienen:

• Sprich in der Ich-Form.
• Mach Deine Motivation für die anderen transparent.
• Möglichst nicht interpretieren.
• Keine Verallgemeinerung.
• Störungen haben Vorrang.
• Es redet immer nur einer.

Zur Eröffnung des Reviews sollte vom Moderator kurz beschrieben werden, welcher Zeitraum betrachtet wird und welche Ereignisse in diesen Zeitraum gefallen sind. Der dadurch entstandene Zeitstrahl kann durch das Projektteam vervollständigt werden. Im Folgenden geht es darum, die Potenziale für kommende Phasen bzw. Projekte herauszukitzeln. Fragen Sie nicht nach Fehlern! Besser ist es zu fragen "Welche Klippen haben wir erfolgreich umschifft?" oder "Was würden wir heute anders machen?". Der Zeitstrahl kann dann in die Zukunft weiterentwickelt werden.


Die Ergebnisse des Reviews müssen schriftlich dokumentiert und ausgewertet werden. Je nach Situation erfolgt die Auswertung im Team (Iterationsreview) oder durch den Projektleiter in Zusammenarbeit mit dem QMB (Projektreview). Die Ergebnisse werden zumindest dem Team zur Verfügung gestellt. Lessons Learned und Best Practices sollten der ganzen Organisation zur Verfügung gestellt werden, indem sie veröffentlicht oder in das Vorgehensmodell eingearbeitet werden.

Projektreviews sind sehr wichtig, denn durch sie können Erfahrungen offen ausgetauscht und Fehler in der Zukunft vermieden werden. Sie gehören ebenso zum Projektmanagement, wie auch zum Wissensmanagement und zur Qualitätssicherung. Voraussetzung ist die Schaffung einer offenen Fehlerkultur im Unternehmen.

ERP-Einführung aus AG-Sicht

Lars Nielsen beschreibt in seinem Blog sehr treffend die Herausforderungen bei der ERP-Einführung aus Sicht des Auftraggebers.

Sehr treffend finde ich die möglichen Gründe, warum die Kunden-Erwartungen nicht erfüllt werden - passt natürlich auch wieder herrlich zur Projektmanagement-Schaukel.

Die beschriebenen Gründe bestärken mich darin, wie wichtig die Kommunikation im Projekt ist. Das Vorgehensmodell sollte die geplante Kommunikation unterstützen.

Der Sinn von Vorgehensmodellen

Was hat das Bild hier rechts mit einem Vorgehensmodell zu tun? Aufgenommen habe ich dieses Bild kürzlich, nachdem ich mein Auto auf einem kostenpflichtigen Parkplatz geparkt habe. Es zeigt die Windschutzscheide meines Wagens und das ausgestellte rote Parkticket.

Auf diesem Parkplatz kassieren tatsächlich noch richtige Menschen: Bei der Einfahrt gibt man die voraussichtliche Parkdauer an zahlt je Stunde 70 Cent. Bei der Ausfahrt wird das Ticket geprüft: Hat man die Parkdauer überschritten muss nachgezahlt werden.

Das verwendete System ist denkbar einfach: Bei der Einfahrt wird auf dem Zettel Uhrzeit und Anzahl der bereits bezahlten Stunden notiert. Bei der Ausfahrt wird der Zettel mit der aktuellen Uhrzeit verglichen.

Die Sache wird knifflig, da verschiedene Personen die Autos bei Ein- und Ausfahrt kontrollieren. Die beiden müssen sich also auf ein System für das Festhalten der Informationen auf dem Parkticket geeinigt haben. Wahrscheinlich haben sie bei einer Tasse Kaffe beschlossen, Einfahrzeit und Dauer auf dem Ticket festzuhalten. Würde ein dritter Kollege aus einer anderen Schicht intuitiv auch diese Notation wählen? Was würde passieren, wenn er lediglich die geplante Ausfahrt auf dem Ticket vermerken würde?

Die Abstimmung von drei Kollegen bei einer weiteren Tasse Kaffee ist einfach. Nun soll das Konzept aber auf einen Großparkplatz mit 50 Mitarbeitern ausgerollt werden. Was nun?
Jeder wird bestätigen, dass eine schriftliche Reglung der Arbeitsweise notwendig wird. Auf diese Weise können neue Mitarbeiter schnell eingewiesen werden. Neben dem Ticketinhalt kann hier auch noch der Farbcode für die verschiedenen Tage geregelt werden - und natürlich der Stundensatz, und, und, ...

Ein Vorgehensmodell legt fest Wer, Wann, Was zu erledigen hat und Welches Ergebnis dabei erwartet wird. In diesem Beispiel leuchtet jedem ein, dass bei mehr Mitspielern die Regeln schriftlich festgehalten werden müssen.

Warum ist es dann in IT-Projekten häufig schwer, jeden von der Einhaltung der Spielregeln zu überzeugen?