Kommunikationsprinzipien in einem Projekt

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.

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