Communication Principles in a Project

The first hours or at least days within a project do shape most of the ongoing communication in a project or program. In other words: if you do not or too late define communication principles in a project you will need to cope with issues in a later stage.

All soft topics like usage of mobile phones or laptops during meetings, respect between each other, listening to colleagues, confirm understanding, participation by all in meetings, avoid mails but call instead, and so on and so forth are topics which are often more easy to follow than the individual behavior in following topics. Therefore guidance should be given.

A set of my standard communication set up in projects from day 1 onwards as an example below.

 

I would like to ask you to follow these communication principles:

To minimize our mail traffic and an easier organization of our mailboxes we should agree on the following rules:

  • Only send mails towards the team members who need the information!
  • Sounds funny, meant is: avoid big distribution list without need! (same with copy!)
  • As long as we are working on drafts or on finalization of templates the drafts are only send around the nominated team
  • Often big copy distribution lists in mails are used for escalation of safety reasons, in case this is needed: Please contact and inform the Program Manager respectively the needed team member before. The Stream Leads are asked to design a workaround for internal escalation handling in their streams.
  • We agree that the work of all of us is very important for this program! For that reason only mails with a critical timeline are marked as urgent.
  • Mails with a critical impact for the program content have to be marked with URG at first.
  • To avoid overload the capacity of our mail server we send links where ever it is possible
  • Last but not least: Don’t bury the needed information’s in mail chains …

 

Mail naming convention

  1. All Mails have to be marked with the kind of information is given with the e-mail
  • INF: Information; an information is given to the addressees, no action required
  • ACT: Date, Action; and action is required by the addressee
  • DEL: Delivery; a required action is delivered
  • URG: urgent information’s start with this prefix
    e. g. URG: DREAM: SP01: … – see also file naming convention
  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

 

Document naming convention

All documents in the program are named as followed:

  1. Date (yyyymmdd)
  2. Project Name (DREAM) and sub project number (e. g. SP01)
  3. Document name
  4. Version (drafts V 0.1 ff; finalized versions V 1.0 ff)

E.g.: 20170220_DREAM_WP01_name convention_V 0-1.doc

The four elements are separated by an underscore.

 

All documents which have been reviewed follow this naming convention:

  1. <Name of Original Document>
  2. Rev<Initials of Reviewer>
  3. Date (yyyymmdd)
  4. g, 20170220_DREAM_WP01_name convention_V 0-1_RevMW_20170307.doc