Die Bedeutung von Zielen in agilen Projekten

"Grinekatze", sagte Alice, "würdest Du mir bitte sagen, wie ich von hier aus weitergehen soll?"
"Das hängt zum großen Teil davon ab, wohin Du möchtest", sagte die Katze.
"Ach, wohin ist mir eigentlich egal" entgegnete Alice.
"Dann ist es auch egal, wie Du weitergehst", meinte die Katze.
(aus Alice im Wunderland von Lewis Carroll)

Ziele sind für jedes Projekt von großer Bedeutung. Ohne ein Ziel gäbe es kein Projekt (besser: sollte es kein Projekt geben). Sie geben unserer Projektarbeit den Sinn.

Agile Vorgehensmodelle fordern von uns, dass wir uns ständig auf die veränderten Rahmenbedingungen einstellen. Das bedeutet auch während der Projektlaufzeit neue und geänderte Anforderungen offen anzunehmen und ggf. den Kurs im Projekt zu ändern. Das Wissen um die Projektziele ist dabei besonders wichtig. Bei jeder neuen bzw. geänderten Anforderung müssen wir uns die Fragen stellen:

• "Unterstützt diese Anforderung überhaupt noch unser Projektziel?"
• "Sind wir noch auf dem richtigen Kurs?"

Ich fasse die Kernziele gerne in einer Projektvision zusammen. Auch wenn der Begriff Vision sehr weitgreifend ist, bringt er das Ziel zu Projektbeginn auf den Punkt: Zu Beginn gibt es eine vage Vorstellung von dem künftigen System. Diese Vorstellung wird gemeinsam mit den Kernanforderungen im Visionsdokument festgehalten.

Grundsätzlich sollten die Ziele immer S.M.A.R.T formuliert werden:

• Simple bzw. sinnspezifisch
• Messbar
• Aktionsorientiert bzw. attraktiv
• Realistisch
• Terminiert

Die Vision selbst kann davon abweichen, da sie größer ist, als ein einziges Ziel. Sie passt besser in die Kategorie der HUGGs = huge, unbelievable great goals. Ein riesiges (unglaubliches) großartiges Ziel, das wichtiger ist als alle anderen. Die Vision gibt den roten Faden für das Projekt vor.

Jedes Projektmitglied sollte diese Vision kennen und die wesentlichen Ziele in einem Satz formulieren können! Häufige Antwort auf die Frage nach dem Projektziel lautet "wir müssen System XY einführen" oder "wir entwickeln eine neue Software zur Verarbeitung von ZX-Daten". Sind das wirklich die Ziele, die dieses Projekt angestosen haben? Was sind die wahren Ziele z.B. einer ERP-Einführung?

Bleiben wir beim Beispiel ERP-Einführung. Was treibt Unternehmen in dieses Abenteuer? Mögliche Gründe für die Neueinführung oder Ablösung eines System können sein:

• Optimierung der Unternehmesprozesse
• Konsolidierung vorhandener System (leichtere Wartbarkeit, weniger Schnittstellen, etc)
• Einsatz neuer Technologien (elektronischer Datenaustausch)
• Vereinheitlichung der IT-Landschaft

In all diesen Fällen ist die ERP-Einführung selbst nicht das Ziel, sondern lediglich ein Werkzeug.

Kennen Sie die Beweggründe für das Projekt haben Sie mindestens zwei Vorteile:
Entscheidungen im Projekt können mit den Projektzielen abgestimmt werden. Im Zweifelsfall kommt das Team so schneller zu einer Entscheidung.
Anhand der Projektziele kann nach dem Projekt der Erfolgt gemessen werden. Hilfreich ist es hier zur Bewertung der Ziele im Vorfeld bereits Metriken zu definieren.

Halten wir fest:
Eine Projektvision fasst die Beweggründe, Ziele und Kernanforderungen an das gesamte Projekt zusammen. Jedem Projektmitglied sollte diese Vision bekannt sein. Die Erarbeitung kann in einem Visionsworkshop erfolgen.
Die Projektvision ist während der Projektlaufzeit der leuchtende Stern, der uns den Weg weist. Neue Anforderungen sollten diese Vision unterstützen. Sie hilft uns nicht vom weg abzukommen.

Besprechungen - ein leidiges Thema?

Besprechungen verfolgen uns im Projekt und im Arbeitsalltag. Im folgenden Foliensatz werden viele sinnvolle Tips zur Gestaltung von produktiven Besprechungen gegeben!

Stop Meeting Failure, get your productivity back today!

View more presentations from Andreas Heilwagen.

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?