Projekt-Newsletter: Ein wirksames Kommunikationswerkzeug

Für ein erfolgreiches Stakeholdermanagement in agilen Projekten

Der Erfolg eines Projekts hängt von gelungener Kommunikation mit den verschiedensten Menschen ab – innerhalb und außerhalb des Projektteams. Diese Personen werden unter dem Begriff „Stakeholder“ zusammengefasst. Zu Beginn des Projektes ist es sinnvoll, die Stakeholder zu analysieren und anhand der Stakeholder-Matrix zu klassifizieren – um dann im Laufe des Projektes entsprechend ihre Bedürfnisse zu erfüllen. Viele dieser Bedarfe können mit regelmäßiger Kommunikation befriedigt werden. Eines der einfachsten Mittel dafür ist ein Projekt-Newsletter.

Stakeholder-Matrix

Die Stakeholder-Matrix wurde 1991 von Aubrey Mendelow erfunden. Wenn man alle Stakeholder nach ihrem Einfluss und ihrem Interesse an Projekt ordnet, bekommt man einen einfachen Leitfaden, wie man mit ihnen vorgehen muss. Dabei sind die zwei Gruppen ziemlich einfach: Die Gruppe mit dem niedrigen Interesse und niedrigen Einfluss kann ignoriert werden.

Das gleiche gilt weitestgehend auch für die Gruppe mit dem hohen Interesse und hohem Einfluss – das ist die Gruppe, die zu den Lenkungsausschüssen eingeladen wird oder in regelmäßigen Abstimmungen über das Projektgeschehen informiert wird (auch wenn normalerweise die Mitglieder dieser Gruppe eher wenig Zeit für solche Abstimmungen haben). Was aber tun mit der Gruppe hohes Interesse und geringer Einfluss (hier lautet die Empfehlung: „Informiert halten“) oder umgekehrt mit geringem Interesse und hohem Einfluss („Zufrieden halten“)? Der Projekt-Newsletter adressiert die Bedürfnisse dieser zwei Gruppen – und trägt auch dazu bei, dass die Anzahl der Meetings mit den wichtigen (hoher Einfluss, hohes Interesse) auf das nötige reduziert werden kann.

Stakeholder-Bedürfnisse

Betrachten wir ein agiles Projekt mit mehreren beteiligten Organisationen, wie etwa verschiedenen Abteilungen eines Unternehmens oder verschiedenen Firmen. Agil ist hier wichtig insofern, weil Transparenz eine der wichtigsten Säulen der Agilität ist. Wenn keine Transparenz über Projektgeschehen gewünscht ist, dann kann der Projekt-Newsletter nicht benutzt werden. Wir gehen also von einem Projekt mit mehreren beteiligten Organisationen, die Wert auf Transparenz legen, aus.

Ein paar Situationen aus dem echten Leben:

• Der Abteilungsleiter überfliegt den Newsletter alle zwei Wochen, freut sich über den sichtbaren Fortschritt und, solange keine wichtige Themen im Bereich „Offene Punkte und Risiken“ stehen, ist für ihn das Projekt im grünen Bereich.
• Die Teamleitung kommt aus dem Urlaub und hat dank des Newsletters Infos über das Projektgeschehen während seiner Abwesenheit.
• Die Bereichsleiterin fragt den Abteilungsleiter nach dem Projektstatus, woraufhin er den letzten Newsletter direkt weiterleiten kann.
• Der Frontend-Entwickler wartet auf die Backend-Schnittstelle und liest im Newsletter, welche Fortschritte gemacht wurden.
• Die Testverantwortlichen bekommen Links auf die Konzepte und schauen sich diese direkt durch.
• Der Backend-Entwickler liest eine stolze Meldung über eine wichtige Funktion, die er bereitgestellt hat.
• Bei der Vorbereitung des Newsletters entdeckt der Product Owner eine wichtige offene Frage, die noch nicht adressiert wurde.
• Eine neue Mitarbeiterin fängt an und kennt dank des Newsletters die Projektgeschichte.
• Bei der Vorbereitung vom Projektabschlussevent und der großen Retrospektive werden die Newsletter nochmal ausgedruckt und im Raum für die Retrospektive aufgehängt.

How-To Projekt-Newsletter

So kommt man zum Newsletter

1.  Ist der Newsletter überhaupt gewünscht? Dies muss mit den Verantwortlichen geklärt werden, also meist mit dem Projektauftraggeber / Projektsponsor. Es kann hilfreich sein, zunächst eine oder zwei Ausgaben nur an diese Person zu senden, damit sie die Vorteile des Newsletters erkennt. Solange dies geklärt wird, kann bereits ein Projekttagebuch in einer gemeinsamen Ablage (z. B. Atlassian Confluence) geführt werden, das dieselben Informationen wie der versendete Newsletter enthält.
2. Verteiler definieren und mit den Verantwortlichen klären: Zum Beispiel Kernteam als Empfänger, sonstige Stakeholder auf CC. Zur Not mit einem kleineren Verteiler anfangen und dann erweitern.
3. Turnus definieren – etwa 2 bis 4 Wochen.
4. Den Erstellprozess definieren, z.B. wird der Inhalt in Einzelgesprächen oder in einem gemeinsamen Meeting besprochen, gibt es ein Review mit dem Auftraggeber.
5. Die erste Ausgabe schicken. Die Ausgabe auch in einer gemeinsamen Ablage (z.B. Confluence ablegen).
6. Bis zum Projektende weitere Ausgaben regelmäßig verschicken.

Newsletter-Struktur

Folgende Newsletter-Struktur hat sich als hilfreich erwiesen:

• Fortschritt (seit dem letzten Newsletter)

Kurze, stichpunktartige und für alle verständlichen Beschreibungen von den letzten Erfolgen und abgeschlossenen Arbeitspaketen mit Links auf die weiterführenden Informationen.

• Risiken und offene Punkte (Optional)
  Kurze, stichpunktartige und für alle verständlichen Beschreibungen von offenen Fragen, wenn möglich, mit der Angabe von Verantwortlichen und weiterem Vorgehen.
• Entscheidungen und Festlegungen (Optional)
  Seit dem letzten Newsletter getroffene Entscheidungen
• Aktueller Entwicklungsstand (Optional)
  Screenshots oder Links auf Videos mit der Zusammenfassung des aktuellen Entwicklungsstandes.
• Dashboards / Statistiken (Optional)
  Grafische Darstellung des Entwicklungsstatus (wie viele User Stories wurden bereits umgesetzt), z.B. als Kuchen-Diagramm oder Tabelle.
  Nutzungsstatistiken oder ähnliches
• Nächste Termine (Optional)
  Nur die allerwichtigsten, nach außen kommunizierten Termine

Best Practices

Damit die oben beschriebene Wirkung erzielt werden kann, gibt es ein paar einfache Praxistipps:

1. Verteiler:
   Lieber klein anfangen und Verteiler offenhalten, d.h. bei Interesse weitere Kollegen auf CC aufnehmen.
2. Inhalt:
   a. Auf Verständlichkeit achten. Sätze sehr kurz formulieren. Wichtige Messages fett hervorheben. Auflistungen verwenden.
   b. Beim Fortschritt keine Namen nennen, um den Teamgedanken zu stärken. (Funktion X implementiert. Konzept für Y erstellt.).
   c. Wenn wegen z.B. Urlaubszeit es nur wenig Fortschritt gibt, lieber trotzdem den Newsletter verschicken. Alternativ früh den Termin der nächsten Ausgabe ankündigen.
   d. Screenshots oder Links zu den Videos von der funktionierenden Anwendung hinzufügen, sie sagen mehr als 1.000 Wörter.
   e. Betreffzeile gleich halten, um später die Suche zu erleichtern.
   f. Die Newsletter-Ausgabe oder das Datum hinzufügen.
   g. Achten, dass der Newsletter nicht zu lang wird, damit er noch gelesen wird.
   h. Im Bereich „Nächste Termine“ nur die allerwichtigsten, bereits nach außen kommunizierten Termine erwähnen. Sonst kann der Erklärungsaufwand bei Terminverschiebungen zu groß werden und auch kann es zum unnötigen Druck auf das Team führen.
   i. Überblick über Fortschritt aus den im Projekt benutzten Werkzeugen (z.B. Jira) generieren.
3. Prozess:
   a. Wenn Review mit den Projektverantwortlichen gewünscht ist, einen regelmäßigen Termin einstellen und Projektstatus anhand des Newsletters besprechen
   b. Wenn ein wichtiger offener Punkt oder Risiko dazu kommt, den an die wichtigen Stakeholder direkt kommunizieren!
4. Zugriff:
   Die Newsletter auch in einem für Projektmitglieder verfügbaren Bereich ablegen, damit alle (insbesondere auch die neuen Projektmitglieder) die Projektgeschichte nachlesen können.

Wann sollte der Projekt-Newsletter nicht eingesetzt werden

Es gibt einige Situationen, in denen ein Newsletter nicht sinnvoll ist:

• Transparenz im Projekt ist nicht gewünscht
• Projekt ist ein Teil eines größeres Vorhabens, das bereits eigene Kommunikationswerkzeuge nutzt
• Es kann nicht sichergestellt werden, dass der Newsletter über Projektzeitraum bereitgestellt werden kann.

Zusammenfassung

In einem Flugzeug bekommt man regelmäßig die Information, wo wir uns auf der Strecke befinden, wie lange wir schon geflogen sind und wie lange der Flug noch dauert. Auch wenn wir keinen Einfluss darauf haben, gibt es ein positives Gefühl – genauso wie regelmäßige Information über Projektfortschritte im Newsletter.

Auch im Kreißsaal erhält die Hebamme regelmäßig Informationen über den Herzschlag von Mutter und Kind während der Geburt, um bei Bedarf den Arzt hinzuzuziehen. Mit dem Newsletter sehen die Stakeholder den Herzschlag unserer Projekte und können uns bei Bedarf schnell helfen.

Letztlich ermöglicht der Projekt-Newsletter den Stakeholdern das Gefühl, in den Prozess integriert zu sein, was die Unterstützung und das Vertrauen in das jeweilige Projekt stärkt. Des Weiteren können Missverständnisse und Unsicherheiten frühzeitig vermieden werden, da alle Beteiligten die gleiche Informationsbasis haben.

Über Irina Dobrikova:

Irina Dobrikova, selbstständige IT-Projektleiterin, Beraterin und Trainerin. Ihren ersten Projekt-Newsletter schrieb sie vor neun Jahren und hat seitdem so viel positives Feedback zu diesem Vorgehen erhalten, dass sie ihre Erfahrungen gerne in diesem Artikel teilt.