Escalation Rules

2 min.

Summary

Escalations are nothing bad in the project or program. They are the demand for spontaneously necessary or not yet taken decisions in a defined way – provided that a regulated governance is established.

Rules

The facts of the case should always be described and agreed upon by both parties (customer and contractor).

Contents of the escalation

  • Precise description of the facts so that they can be understood directly by third parties.
  • In what area and at what time did the facts arise?
  • Who put the facts on the agenda in which reporting medium (e.g. weekly status report)?
  • What has been done to avoid the original risk or problem, to solve it when it occurs or to mitigate it?
  • Who was involved in the solution search?
  • How time-critical is the situation or by when is a solution needed?
  • Identification of the degree of risk and evaluation of the impact.
  • Which activities are proposed for the solution?
  • Description of the solution approach with estimation of the timeline, the resources and the name of the person responsible for the solution.

Communication

  • Escalation always via e-mail. Mails that do not contain all of the above should be returned.
  • Clear mention of the word “ESCALATION” in the subject line as well as in the mail itself.

Further information on the communication rules can also be found here.

Escalation steps

  • All possible measures should be taken to resolve an escalation issue at the lowest level. Before starting an escalation process, the consequences should be clearly articulated.
  • At each stage, an attempt should be made between both parties to find a solution. If this is not possible, the escalation issue should be passed on to the next escalation stage after prior agreement and taking into account the number of escalation days. (Escalation days = length of stay in working days at an escalation level)
  • The project manager is responsible for solving the problem and remains so at every escalation stage.
Escalation Pyramid

Communication Principles in a Project

3 min.

Summary

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.

Useful communication principles

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 just to be sure in case this could be 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 the beginning of the subject.
  • 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)

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