Projektkommunikationsplan: So erstellen Sie einen (Vorlage + Beispiele)

Ein Kommunikationsplan ist das Dokument, das darüber entscheidet, ob Ihre Projekt-Stakeholder informiert und abgestimmt bleiben oder frustriert und überrascht werden. Ohne einen solchen Plan erreichen die richtigen Informationen selten die richtigen Personen zur richtigen Zeit, und die meisten Projektprobleme lassen sich auf genau diese Lücke zurückführen.

Was ist ein Projektkommunikationsplan?

Ein Projektkommunikationsplan ist ein Dokument, das festlegt, wer welche Informationen benötigt, über welchen Kanal, wie häufig und wer für das Versenden verantwortlich ist. Es handelt sich nicht um einen Besprechungskalender. Es ist eine gezielte Zuordnung jeder Zielgruppe zu jedem Informationsfluss, der sie während des gesamten Projektlebenszyklus handlungsfähig hält.

Betrachten Sie es als die Vereinbarung, die das Projektteam trifft, bevor das erste Statusupdate verschickt wird. Wenn ein Sponsor fragt, warum er bei einer Umfangsänderung nicht einbezogen wurde, oder wenn ein Entwickler sagt, er habe von der neuen Deadline nur durch den Buschfunk erfahren, liegt die Ursache meist in einem fehlenden oder ignorierten Kommunikationsplan.

Der Plan steht neben dem Projektauftrag und dem RAID-Log als grundlegendes Governance-Dokument. Er wird während der Projektinitiierung erstellt und aktualisiert, sobald sich die Zielgruppe, der Lieferkanal oder der Rhythmus wesentlich ändert.

Kennzahlen

• PMIs Pulse of the Profession-Bericht ergab, dass 56 % des gefährdeten Projektbudgets auf schlechte Kommunikation zurückzuführen sind.
• Dieselbe Studie stellte fest, dass Organisationen mit effektiven Kommunikationspraktiken mehr als dreimal so viele Projekte pünktlich und im Budget abschließen wie Organisationen mit schlechten Praktiken.
• PMI berichtet zudem, dass leistungsstarke Organisationen 2,6-mal häufiger formal dokumentierte Kommunikationspläne als Standardpraxis einsetzen.

Die Kernelemente eines Kommunikationsplans

Jeder wirksame Kommunikationsplan deckt dieselben sechs Dimensionen ab, unabhängig von Projektgröße oder Branche. Das Tabellenformat ist am übersichtlichsten, da es alle sechs auf einen Blick zeigt und Lücken offensichtlich macht.

Diese sechs Elemente beantworten gemeinsam jede sinnvolle Frage zu einem Kommunikationsfluss. Fehlt eines davon, hat der Plan eine Lücke.

Starke Pläne enthalten außerdem einen Kommunikations-Eskalationspfad (was passiert, wenn außerhalb des normalen Rhythmus etwas Dringendes auftritt). Für größere Projekte empfiehlt sich ein Feedback-Mechanismus: Wie teilt jede Zielgruppe dem Projektteam mit, wenn die Kommunikation nicht funktioniert?

Beispiel eines Kommunikationsplans

Nachfolgend ein ausgefülltes Beispiel für ein mittelgroßes Software-Einführungsprojekt mit einer bereichsübergreifenden Zielgruppe.

Beachten Sie, dass jede Zeile konkret ist: Der Executive Sponsor erhält eine zweiwöchentliche E-Mail UND ein zehnminütiges mündliches Briefing im Lenkungsausschuss, nicht nur "regelmäßige Updates". Diese Genauigkeit verhindert das Gespräch "Das wusste ich nicht" drei Monate später.

So erstellen Sie einen Kommunikationsplan

Das Erstellen eines Kommunikationsplans dauert bei einem kleinen Projekt einige Stunden und bei einem großen einen vollen Tag. Die folgenden sechs Schritte gelten für beide Fälle.

Schritt 1: Stakeholder identifizieren

Ohne Kenntnis der Zielgruppen lassen sich keine Kommunikationsflüsse definieren. Listen Sie zunächst jede Person, jedes Team oder jede Gruppe mit einem Interesse am Projekt auf. Dies entspricht der Übung einer Stakeholder-Analysematrix; wenn Sie diese bereits durchgeführt haben, nutzen Sie sie als Ausgangspunkt.

Sortieren Sie Stakeholder nach Einflusspotenzial und Interesse. Stakeholder mit hohem Einfluss und hohem Interesse (typischerweise Sponsoren und wichtige Entscheidungsträger) benötigen häufige, detaillierte Kommunikation. Stakeholder mit hohem Einfluss und geringem Interesse (Führungskräfte, die zugestimmt haben, aber nicht operativ involviert sind) benötigen kurze, ausnahmebasierte Updates. Gruppen mit geringem Einfluss und hohem Interesse (von der Änderung betroffene Endnutzer) benötigen regelmäßige, klare Kommunikation darüber, was sie betrifft.

Schritt 2: Festlegen, was jeder Stakeholder wissen muss

Fragen Sie für jeden Stakeholder: Welche Entscheidungen trifft er, und welche Informationen benötigt er dafür? Ein Executive Sponsor muss wissen, ob das Projekt auf Kurs ist und ob Risiken seine Eingriffe erfordern. Ein Entwickler muss wissen, was er in diesem Sprint baut und wann das Spec abgeschlossen ist. Endnutzer müssen wissen, was sich ändert, wann und was sie tun müssen.

Formulieren Sie das in klaren Worten. Vermeiden Sie generische Bezeichnungen wie "Projektupdates", da diese für verschiedene Personen unterschiedliche Bedeutungen haben. Konkret ist immer besser: "Budgetist gegenüber Prognose" statt "finanzielle Informationen".

Schritt 3: Den richtigen Kanal für jeden Fluss wählen

Die Kanalwahl bedeutet, das Medium auf die Botschaft und die Gewohnheiten der Zielgruppe abzustimmen. Der falsche Kanal ist schlechter als gar keine Kommunikation: ein dringendes Risikohinweis, der in einem wöchentlichen E-Mail-Digest vergraben ist, ist praktisch kein Hinweis.

Nutzen Sie diese Grundsätze:

• Zeitkritisch und bedeutsam: Direktnachricht, Anruf oder ein eigens anberaumtes Meeting
• Regelmäßige strukturierte Updates: E-Mail-Bericht oder ein regelmäßiges Meeting
• Referenzinformationen, die Stakeholder bei Bedarf abrufen: Gemeinsames Dokument, Dashboard oder Intranet-Seite
• Teamkoordination: Aufgaben-Updates im Projekttool und ein regelmäßiger Standup

Achten Sie darauf, nicht alles per E-Mail zu versenden. Überfüllte Posteingänge sind Realität. Wenn Stakeholder Ihre E-Mails bereits ignorieren, werden sie auch einen neuen Kommunikationsplan, der per E-Mail kommuniziert wird, ignorieren.

Schritt 4: Den Rhythmus festlegen

Frequenz ist genauso wichtig wie Inhalt. Zu häufig, und Stakeholder beginnen, Ihre Nachrichten herauszufiltern. Zu selten, und sie füllen das Vakuum durch Ad-hoc-Anfragen, die mehr Zeit kosten als ein regelmäßiger Rhythmus.

Passen Sie die Häufigkeit daran an, was sich tatsächlich verändert. Ein Projektstatusbericht an den Sponsor macht in der Ausführungsphase wöchentlich Sinn und in ruhigeren Phasen zweiwöchentlich. Ein Änderungshinweis an Endnutzer passt zu wichtigen Meilensteinen, nicht bei jeder kleinen Aufgabenerledigung.

Richten Sie den Rhythmus an den natürlichen Abläufen Ihres Projekts aus: Sprint-Reviews, Meilensteingates und Projekt-Kickoff-Meetings sind natürliche Kommunikationspunkte, um die Sie aufbauen können.

Schritt 5: Verantwortliche benennen

Jede Kommunikation im Plan braucht einen namentlich genannten Verantwortlichen: die Person, die für die pünktliche Erstellung und Verteilung zuständig ist. Ohne namentlich genannten Verantwortlichen wird aus "jemand schickt es" schnell "niemand hat es geschickt".

Der Projektmanager verantwortet die meiste externe Kommunikation zu Sponsoren und Führungskräften. Der Scrum Master oder Team Lead verantwortet typischerweise die interne Teamkommunikation. Fachexperten oder Abteilungsleiter verantworten technische Kommunikation zu bestimmten Gruppen. Nutzen Sie die RACI-Matrix, wenn die Verantwortung über Kommunikationsarten hinweg komplex genug ist, um eine solche zu rechtfertigen.

Schritt 6: Den Plan überprüfen und pflegen

Ein Kommunikationsplan, der beim Kickoff erstellt und danach nie aktualisiert wird, ist schlechter als kein Plan, weil er falsches Vertrauen erzeugt. Planen Sie eine Überprüfung bei jedem wichtigen Meilenstein oder Phasengate. Fragen Sie:

• Hat sich die Stakeholder-Liste geändert?
• Funktionieren die gewählten Kanäle noch?
• Ist der Rhythmus für den aktuellen Projektstand richtig?
• Lesen Stakeholder das Erhaltene tatsächlich und handeln danach?

Berücksichtigen Sie Feedback aus dem Projekt-Kickoff-Meeting und aus retrospektiven Gesprächen mit wichtigen Stakeholdern. Der Plan ist ein lebendes Dokument, kein Abzuhakender Punkt.

Leitfaden zu Kommunikationskanälen und Rhythmus

Verschiedene Kommunikationsbedürfnisse erfordern unterschiedliche Kanäle und Rhythmen. Hier ist eine Kurzreferenz für die häufigsten Projektkommunikationsarten.

Der richtige Rhythmus für einen bestimmten Kanal hängt vom Projekttempo ab. Ein agiler Sprint-Zyklus erzeugt einen schnelleren internen Rhythmus als eine Waterfall-Phase. Passen Sie Ihren Kommunikationsrhythmus dem Projektrhythmus an, nicht einem beliebigen Kalender.

Best Practices

Schreiben Sie den Plan zu Beginn der Projektinitiierung, nicht danach. Kommunikationsprobleme kumulieren über Zeit. Jede Woche, in der ein Stakeholder ohne klare Informationen bleibt, ist eine Woche aufgebauter Annahmen.

Halten Sie den Plan kurz und übersichtlich. Ein Kommunikationsplan, den niemand liest, ist nutzlos. Verwenden Sie ein Tabellenformat. Vermeiden Sie Fließtextabsätze. Das Sechsspalten-Tabellenformat in diesem Artikel deckt alle notwendigen Elemente ab, ohne zum Handbuch zu werden.

Trennen Sie regelmäßige Kommunikation von ausgelöster Kommunikation. Ihr Plan sollte zwei Abschnitte haben: geplante Kommunikation (Wochenberichte, Standups, Lenkungsausschuss-Meetings) und ausgelöste Kommunikation (Risikoeskalationen, Umfangsänderungen, Go/No-Go-Entscheidungen). Beide brauchen Verantwortliche und Kanäle, teilen aber keinen gemeinsamen Kalender.

Stakeholder-Freigabe beim Kickoff einholen. Gehen Sie den Kommunikationsplan während des Projekt-Kickoff-Meetings durch. Fragen Sie Stakeholder, ob Kanal und Rhythmus für sie funktionieren. Ihr Feedback deckt oft praktische Einschränkungen auf (der CFO nutzt Slack nicht, der technische Leiter bevorzugt Async gegenüber Meetings), die den Plan deutlich besser umsetzbar machen.

Bei Teamwechseln überarbeiten. Wenn ein Stakeholder hinzukommt oder ausscheidet oder ein neues Risiko auftritt, das einen neuen Kommunikationsfluss erfordert, aktualisieren Sie den Plan. Behandeln Sie ihn als lebendes Dokument mit Versionsnummer und Datum der letzten Aktualisierung.

Häufige Fehler

Kommunikationsplan mit Besprechungskalender verwechseln. Ein Plan bildet jeden Informationsfluss ab, nicht nur die Meetings in Ihrem Kalender. Statusberichte, Dashboard-Zugriff, Slack-Kanäle und E-Mail-Ankündigungen sind allesamt Kommunikationsflüsse. Stehen sie nicht im Plan, werden sie inkonsistent stattfinden.

Denselben Kanal für alles verwenden. Wenn man standardmäßig alles per E-Mail kommuniziert, entsteht Posteingangs-Unordnung und Dringlichkeit wird verborgen. Differenzieren Sie Kanäle nach Zweck. Dringende Probleme brauchen schnellere Kanäle. Referenzmaterialien brauchen durchsuchbare, abrufbare Kanäle.

Die Verantwortlichen-Spalte vergessen. Pläne, die auflisten, was kommuniziert wird, aber nicht, wer dafür verantwortlich ist, scheitern fast sofort. Jede Zeile muss eine namentlich genannte Person haben, keine Rolle oder kein Team.

Den Plan als einmaliges Artefakt behandeln. Projekte ändern sich. Stakeholder ändern sich. Kanäle, die in der Planungsphase funktionierten, funktionieren nicht immer in der Umsetzung. Planen Sie eine Überprüfung des Kommunikationsplans bei jedem wichtigen Meilenstein.

Stakeholder mit Informationen überfluten, die sie nicht benötigen. Nicht jeder Stakeholder braucht jedes Update. Zu viele Informationen führen dazu, dass Stakeholder alle Kommunikation herausfiltern, auch die kritische. Segmentieren Sie Ihre Zielgruppe sorgfältig und senden Sie jeder Gruppe nur das, was für sie relevant ist.

Zweiseitige Kommunikation ignorieren. Ein Plan, der nur Informationen hinausschickt, liefert nur die halbe Leistung. Bauen Sie Feedback-Mechanismen ein: eine geplante Retrospektive-Frage, einen festen Tagesordnungspunkt, bei dem Stakeholder Bedenken äußern können, oder einen einfachen "Antworten auf diese E-Mail"-Mechanismus.

Häufig gestellte Fragen

Was sollte ein Kommunikationsplan beinhalten?

Mindestens: eine Liste der Stakeholder, die Informationen, die jeder benötigt, den Kanal zur Übermittlung, die Häufigkeit, den verantwortlichen Eigentümer und das Format. Größere Projekte beinhalten außerdem einen Eskalationspfad für dringende Probleme und einen Feedback-Mechanismus. Das Sechsspalten-Tabellenformat (Zielgruppe, Botschaft, Kanal, Häufigkeit, Verantwortlicher, Format) erfasst all das in einem übersichtlichen Dokument.

Wie unterscheidet sich ein Kommunikationsplan von einem Stakeholder-Management-Plan?

Eine Stakeholder-Analysematrix konzentriert sich darauf, Stakeholder zu identifizieren, zu bewerten und zu planen, wie man sie im gesamten Projekt einbindet. Ein Kommunikationsplan ist enger gefasst: Er legt die tatsächlichen Informationsflüsse zwischen dem Projektteam und den Stakeholdern fest. Beide hängen zusammen. Die Stakeholder-Analyse sagt Ihnen, mit wem Sie es zu tun haben und wie viel Einfluss sie haben; der Kommunikationsplan sagt Ihnen genau, was Sie ihnen schicken, wann und wie. Die meisten Projekte erstellen die Stakeholder-Analyse zuerst und nutzen sie als Input für den Kommunikationsplan.

Wann sollte ein Kommunikationsplan erstellt werden?

Während der Projektinitiierung, zusammen mit dem Projektauftrag und der ersten Risikobewertung. Der Plan sollte vor dem Projekt-Kickoff-Meeting entworfen sein, damit er bei diesem Meeting mit den wichtigsten Stakeholdern überprüft und abgestimmt werden kann. Ihn nach Beginn der Ausführung zu erstellen ist besser als gar nicht, aber Sie werden extra Zeit damit verbringen, Kommunikationsmuster zu entwirren, die sich bereits informell gebildet haben.

Wie lang sollte ein Kommunikationsplan sein?

So lang wie nötig und nicht länger. Ein kleines Projekt mit fünf Stakeholdern passt auf eine einzige Seite. Ein großes Programm mit 30+ Stakeholdern über mehrere Organisationen hinweg benötigt möglicherweise ein mehrseitiges Dokument mit separaten Abschnitten für interne und externe Kommunikation. Die richtige Länge ist das, was alle wesentlichen Kommunikationsflüsse erfasst, ohne Füllmaterial.

Ändern sich Kommunikationspläne während eines Projekts?

Ja, und das sollten sie. Immer wenn sich die Stakeholder-Liste ändert, der Projektumfang sich erheblich verschiebt oder ein Kommunikationskanal aufhört zu funktionieren, sollte der Plan aktualisiert werden. Best Practice ist, den Plan bei jedem wichtigen Meilenstein-Gate zu überprüfen. Verfolgen Sie Änderungen mit einer Versionsnummer und einem Datum der letzten Aktualisierung, damit Stakeholder immer wissen, welche Version aktuell ist.

---

Der Kommunikationsplan steht nicht für sich allein. Er ist das Dokument, das Ihre wöchentlichen Projektstatusberichte antreibt, den Rhythmus Ihrer Stakeholder-Meetings informiert und die Aufzeichnung darüber, was wann kommuniziert wurde, in die Lessons Learned einfließen lässt. Bringen Sie ihn von Anfang an in Ordnung, und die Projektinformationen fließen fast automatisch. Versäumen Sie das, werden Sie den Rest des Projekts damit verbringen, Stakeholder mit Updates zu versorgen, die sie längst hätten haben sollen.