Kommunikationsprinzipien in einem Projekt

2 min.

Summary

Die ersten Stunden oder zumindest Tage innerhalb eines Projekts prägen den Großteil der laufenden Kommunikation in einem Projekt oder Programm. Mit anderen Worten: Wenn Sie in einem Projekt keine oder zu spät Kommunikationsprinzipien definieren, müssen Sie sich später mit Problemen auseinandersetzen: Alle „weichen“ Themen wie die Nutzung von Mobiltelefonen oder Laptops bei Meetings, Respekt untereinander, Zuhören, Verständnis bestätigen, Teilnahme aller an Meetings, statt Mails besser anrufen und so weiter und so fort sind Themen, die oft leichter zu verfolgen sind als das individuelle Verhalten in folgenden Themen. Daher sollte eine Anleitung ausgegeben werden. Ein Beispiel meiner Standardkommunikation, die in Projekten etabliere.

Sinnvolle Kommunikationsprinzipien

Ich möchte Sie bitten, folgende Kommunikationsprinzipien zu befolgen.

Um unseren Mailverkehr zu minimieren und die Organisation unserer Mailboxen zu erleichtern, sollten wir uns auf folgende Regeln einigen:

  • Senden Sie nur Mails an die Teammitglieder, die die Informationen benötigen!
  • Klingt selbstverständlich, aber gemeint ist: Vermeide große Verteiler ohne Grund.
  • Solange wir an Entwürfen oder an der Fertigstellung von Vorlagen arbeiten, werden die Entwürfe nur an das definierte Team verschickt.
  • Häufig werden große Kopienverteiler in Mails zur Eskalation um auf Nummer sicher zu gehen verwendet: Bitte kontaktieren und informieren Sie den Programm-Manager bzw. das gewünschte Teammitglied vorher.
  • Die Stream Leads werden gebeten, einen Workaround für die interne Eskalationsverarbeitung in ihren Streams zu entwerfen, da wir alle der Meinung sind, dass die Arbeit von uns allen sehr wichtig für dieses Programm ist! Aus diesem Grund werden nur Mails mit einer kritischen Zeitachse als dringend markiert.
  • Mails mit einer kritischen Auswirkung auf den Programminhalt müssen im Betreff mit URG markiert werden
  • Um eine Überlastung der Kapazität unseres Mail-Servers zu vermeiden, senden wir Links, wo immer es möglich ist.
  • Last but not least: Vergraben Sie nicht die benötigten Informationen in E-Mail-Ketten….

E-Mail Richtlinie

  1. Alle Mails müssen mit der Art der Informationen gekennzeichnet sein, die in der E-Mail angegeben sind.
  • INF: Information; eine Information wird die Adressaten gegeben, es besteht kein Handlungsbedarf.
  • ACT: Datum, Aufgabe; und die Aufgabe ist vom Empfänger zu erledigen.
  • DEL: Lieferung; eine angeforderte Lieferung erfolgt.
  • URG: Dringende Informationen beginnen mit diesem Präfix.
  • z. B. URG: DREAM: SP01: …. – siehe auch Dateinamenskonvention
  1. Mail subjects needs to include a short and clear description of the content
  2. Addressees on copy have in general no action!
  3. Escalations
    In general the escalations come up as followed:
    1. Team Members to Subproject Managers
    2. Subproject Managers to Project Management
    3. Project Management to Program Sponsor / SteercoE.G.: INF: DREAM: SP01: Mail Convention

Dokumentnamens-Konvention

Alle Dokumente im Programm sind wie folgt benannt:

  1. Datum (yyyymmdd)
  2. Projektname (DREAM) und Unterprojektnummer (z. B. SP01)
  3. Dokumentname
  4. Version (Entwürfe V 0.1 ff; fertige Versionen V 1.0 ff)

Z. B.: 20170220_DREAM_WP01_name convention_V 0-1.doc

Die vier Elemente sind durch einen Unterstrich getrennt.

Alle Dokumente, die reviewed wurden, folgen dieser Namenskonvention:

  1. Name des Originaldokuments
  2. Rev<Initialen des Reviewers>
  3. Reviewdatum (yyyymmdd)

z.B.: 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc

Besprechungsagenda

1 Minute

Summary

Effektive Meetings sind immer eine Herausforderung. Es gibt viele Regeln und Checklisten für Meetings. Aber bis jetzt habe ich noch keine gute Vorlage für eine effektive Meeting-Agenda gefunden.

In meiner täglichen Anwendung habe ich den Bedarf an zwei verschiedenen Agenda-Formaten festgestellt, abhängig von der Dauer der Sitzung oder besser der Anzahl der Agenda-Themen.

Für eine Telefonkonferenz

verwende ich seit Jahren immer das folgende einfache Format (falls nicht viele Themen behandelt werden müssen):

INITIAL SITUATION/AUSGANGSSITUATION
  • Der Projektstatus muss bis Freitag 12:00 Uhr MEZ an Steerco gemeldet werden.
PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)
  • Bitte aktualisieren Sie Ihre Arbeitspakete bis Donnerstag 10:00 Uhr CET Server Link (ALLE).
  • Bitte aktualisieren Sie den Status der Aktionspunkte / Server link (ALLE)
  • Berichtsvorlage aktualisieren (ML)
AGENDA
  • Überprüfung von Schnittstellenproblemen zwischen Arbeitspaketen (MW)
  • Abstimmung von Aktionspunkten über Arbeitspakete hinweg (MW)
  • Abstimmung über Teamdiskussionen auf dem Projektserver (ML)
  • Probleme und Risiken, auf die es abzustimmen gilt (ML)
RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS
  • Abgestimmte Sicht auf Projektstatus
NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING
  • Zu konsolidierender Bericht (ML)
  • Bericht zur Überprüfung und Übermittlung an Steerco (MW)

Für Präsenz-Workshops oder längere Telkos

bevorzuge ich das folgende Format:

Berlin, Hauptstr. 14-16, 1.OG, Raum E1.15a, Montag 05. Feb 2018 – CMO FMO Big Picture
Ziel: Gemeinsames Verständnis von CMO und FMO Big Pictures und damit verbundenen Aktivitäten
Ansatz: Time Boxing
Vorbereitung: Präsentation: Serverlink
Materialien: 2 Beamer, Moderationskoffer
Zeit (CET)ThemaHostInput und Vorbereitung erforderlich / VerantwortlicherErgebnis erwartet / VerantwortlicherTeilnehmer
09:30 – 10:00Einführung und Ziel der BesprechungMW Einführung – keine Vorbereitung erforderlich Alle Alle