Schlagwort: eskalation

Regeln der Eskalation

2 min.

Summary

Eskalationen sind nichts Schlimmes im Projekt oder Programm. Sie sind das Einfordern der spontan notwendigen oder bisher nicht erfolgten Entscheidungen auf definierte Weise – vorausgesetzt eine geregelte Governance ist etabliert.

Regeln

Der Sachverhalt sollte immer von beiden Parteien (Kunde und Auftragnehmer) gemeinsam beschrieben werden und abgestimmt sein.

Inhalte der Eskalation

  • Genaue Beschreibung des Sachverhalts, so dass er von Dritten direkt verstanden werden kann.
  • In welchem Bereich und zu welchem Zeitpunkt ist der Sachverhalt entstanden?
  • Wer hat den Sachverhalt in welchem Reporting-Medium (z.B. wöchentlicher Statusbericht) auf die Tagesordnung gebracht?
  • Was ist getan worden, um das ursprüngliche Risiko bzw. Problem zu verhindern,  es  bei Auftreten zu lösen bzw. es abzumildern?
  • Wer war an der Lösungssuche beteiligt?
  • Wie zeitkritisch ist der Sachverhalt bzw. bis wann wird eine Lösung benötigt?
  • Benennung des Risikogrades und Bewertung der Auswirkung (Impact).
  • Welche Aktivitäten werden zur Lösung vorgeschlagen?
  • Beschreibung des Lösungsansatzes mit Schätzung der Zeitschiene (Timeline), der Ressourcen und der Benennung des Verantwortlichen für die Lösung.

Kommunikation

  • Eskalation immer über E-Mail.  Mails, die nicht alle obigen Sachverhalte beinhalten, sollten zurückgesendet werden.
  • Deutliche Nennung des Wortes “ESKALATION” in der Betreffzeile wie auch in der Mail selbst.

Nähere Informationen zu den Kommunikationsregeln finden Sie auch hier.

Eskalationsstufen

  • Alle möglichen Maßnahmen sollten ergriffen werden, um einen Eskalationssachverhalt auf der niedrigsten Stufe zu lösen. Vor dem Start eines Eskalationsprozesses sollten die Konsequenzen deutlich artikuliert werden.
  • Auf jeder Stufe sollte zwischen beiden Parteien versucht werden, eine Lösung zu finden. Ist diese nicht möglich, sollte – nach vorheriger Abstimmung und unter Berücksichtigung der Anzahl der Eskalationstage – der Eskalationssachverhalt an die jeweilig nächste Eskalationsstufe weitergegeben werden. (Eskalationstage = Verweildauer in Arbeitstagen auf einer Eskalationsstufe)
  • Der Projektmanager ist für die Problemlösung verantwortlich und bleibt es auch bei jeder Eskalationsstufe.
Eskalationspyramide

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