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

Projektfrühwarnsystem in 10 Fragen

5 min.

Summary

In Projektportfolio-Umgebungen oder auch für Projektdirektoren selbst, ist es oft nicht einfach, klare Signale aus den Projekten zu erhalten. Dies zur Prüfung, ob diese sich auf dem richtigen Weg befinden. Oft recht umfangreiche und komplexe Projektportfolio-Steuerungssysteme werden eingesetzt um genau dies zu ermitteln. Die Praxis zeigt, dass diese aufgrund der Heterogenität der Projekte (sehr groß vs. sehr klein, in Land X bzw. Land Y, im Geschäftsbereich A oder B) nicht dieselbe Zahl an zuverlässigen Messpunkten zu den verschiedensten Projekten verfügbar sind. Dieser Bericht zeigt, wie Sie auch bei unterschiedlichsten Projektgrößen und -arten durch 10 identische einfache Fragen, zuverlässige Frühwarnungen erhalten.

Warum bedarf es eines einfachen Projekt-Frühwarnsystems?

Eine andere Frühwarnung habe ich bereits hier beschrieben, die ganz andere Messgrößen hat. Je nach Anwendungsfall sollten diese Ansätze Anwendung finden. In einem Unternehmen mit hoch standardisierten Methoden, Prozessen und Tools im Projektmanagement ist der nächste logische Schritt weiter auf dem Weg zu noch mehr Qualität für Projekte die Überprüfung der Compliance dieser Vorgaben. Das Projektmanagementhandbuch beschreibt Prozesse, stellt Vorlagen und Tools zur Verfügung um jegliche Projektarten und Projektgrößen standardisiert abzuwickeln. Selbst die spezifische Anwendung von Standardapplikationen wie z. B. MS Project ist oft im Detail zu beschrieben und vorgegeben. Compliance-Kriterien ergeben sich daher im Bereich Policies, Prozesse, Vorlagen und Werkzeuge.

Weil effiziente und vor allem einheitliche Methoden oft fehlen, welche schnell Kernprobleme von Projekten aufzeigen können (und diese schnell abwenden können), wird das Senior-Management – trotz hoher Standardisierung im Projektmanagement – häufiger überrascht durch Projekte, welche

  • hinter dem Zeitplan liegen,
  • das Budget überschreiten
  • und den vereinbarten Leistungsumfang nicht erreichen

was wiederum zu

  • Unzufriedenheit von Kunden und das
  • Verfehlen von Geschäftszielen

führt.

Ein Frühwarnsystem (FWS) enthält Fragen zum Projektstatus, die in Form eines Fragebogens monatlich durch die Projektleiter zu beantworten sind.

Zielsetzung des Frühwarnsystems

Zielsetzung des Frühwarnsystems ist die Entwicklung und / oder die Integration einer Reihe von Tools und Prozessen, welche schnell potentielle Projekt-Problembereiche feststellen und ein sinnvolles Mittel zur Eskalation und Problembehebung bieten, solange sie noch in einfacher Form vorliegen um Überraschungen zu vermeiden.

Die Detail-Ziele können sein:

  • Einführung eines einfachen, skalierbaren Systems, das einfach zu warten ist durch „state of the art“-Technologie.
  • Einführung eines Systems welches es ermöglicht Probleme in Projekten aufzuzeigen und die Beseitigung dieser in der Angebotsphase, Start Up Phase und Run & Maintain Phase ermöglicht.
  • Einführung von Prozessen und Tools, welche nicht umgangen und ignoriert werden können; um die Compliance zu Prozessen und Tools zu bestätigen.
  • Die FWS-Ergebnisse zu nutzen um bestehende Berichte zu erweitern mit den FWS-Informationen.
  • Sicherstellen eines engen Time-Boxing von der Problemidentifikation bis zur Lösung.
  • Entwicklung eines Management-Kommunikationsplanes um das Senior-Management kontinuierlich zu informieren über die konsistente Implementierung und Durchsetzung der FWS Tools, Prozesse und Reporting im gesamten Unternehmen.

Die Erfolgsfaktoren des Frühwarnsystems

Um ein globales Frühwarnsystem sicherzustellen müssen folgende Erfolgsfaktoren eingehalten werden:

  • Zeitnahe und genaue Bewertung von Programm-/Projektstatus bezogen auf Schlüsselkennzeichen.
  • Das Linienmanagement mit Profit & Loss-Verantwortung für die Programme und Projekte ist verantwortlich auf negative Antworten zu reagieren und Maßnahmen zu verfolgen bis diese abgeschlossen sind.
  • Die Fragen müssen intensiv geprüft werden durch das Senior Management.
  • Die Fragen müssen global in allen eventuell vorhandenen regionalen Systemen unverändert verwendet werden.
  • Programm- und Projektmanager beantworten diese Fragen monatlich für jedes Projekt.
  • Standardreports werden den Programm-/Projekt-Sponsoren zur Verfügung gestellt um Maßnahmenverfolgung zu unterstützen.

Die Frühwarnsystem-Fragen

Folgende Fragen stellen eine Auswahl dar für ein Frühwarnsystem. Bei der Adaption für spezifische Organisationen werden auch die relativen Abweichungen in Form der Zahlenwerte angepasst. Die sogenannte Riskoantwort gibt die Antwortmöglichkeit an, welche zu einer Zwangskommentierung des Eintrages führt und in einer konsolidierten Auswertung als „Alarmsignal“ dient.

Nr.FrageRisikoantwort
1Ist die letzte Kundenumfrage mit mehr als 3,5 Punkten (von 5 Punkten) bewertet worden?
Nein
2 Wird der Projektplan wöchentlich mit geleisteter Arbeit und Restaufwänden aktualisiert und neu berechnet?
Nein
3 Sind alle genehmigten Änderungsanträge im Projektplan abgebildet?
Ja
4Verläuft die Personalbesetzung entsprechend der Planung im Projektplan?Ja
5Ist eine gemeinsame Projekt-Governance verabschiedet worden?Ja
6Wurde ein Lenkungsausschuss in den letzten 30 Tagen abgehalten?
Nein
7 Ist die Planabweichung (Schedule Variance) > 10%?
Ja
8 Ist die Kostenabweichung (Cost Variance) > 10%?
Ja
9Hat das Projekt Arbeit außerhalb des genehmigten Projektdefinitionsumfangs geleistet?Ja
10 Sind alle bisher erbrachten Leistungen abgenommen worden? Nein

In einem Datenbanksystem sind die Fragen im Feld „Antwort“ jeweils mit „Ja/Nein“ zu beantworten.

Ist eine Frage positiv beantwortet dann ist diese Frage abschließend beantwortet, also fertig.

Ist eine Frage negativ beantwortet dann wird von den Projektleitern die Eingabe von Maßnahmen zur Lösung der negativen Situation angefordert.

  • Feld „Maßnahme“: Maßnahme zur Lösung der negativen Situation eintragen
  • Feld „Verantwortlicher“: Den Namen des für die Maßnahme Zuständigen auswählen
  • Feld „Plan-Datum“: Datum angeben, bis zu dem die Maßnahme erledigt sein soll / muss (Plan-Datum)
  • Feld „Status“: Status der Maßnahme auswählen.

Die Ergebnisse werden idealerweise in ein unternehmensweites webbasiertes FWS-Tool dargestellt um zentrale Reports und Auswertungen erstellen zu können.

Das Zusammenspiel mit einem Projektmanagementhandbuch-Fragebogen

Sind (weltweit) einheitliche Richtlinien, Prozesse, Tools und Templates im Projektmanagementbereich verfügbar ist eine Erweiterung des Fragebogens in Betracht zu ziehen.

Eine detaillierte Befragung der Projektmanager sollte initial bei Projektstart und bei wesentlichen Projektänderungen durch einen ausführlichen Self-Assessment-Fragebogen erfolgen, welcher deutlich über folgende mögliche FWS-Ergänzungsfragen hinausgeht.

Nr.FrageRisikoantwort
1Wurde die Projektdefinitions-Vorlage aus dem Projektmanagementhandbuch verwendet?nein
2Wurde das Schätzverfahren und die Schätztemplates verwendet gemäß Projektmanagementhandbuch?nein
3Wird wöchentlich eine Earned Value Berechnung basierend auf dem aktuellen Projektplan durchgeführt?nein
4Werden Probleme, Risiken, Abnahmen, Change Requests kontinuierlich im Template aus dem Projektmanagementhandbuch festgehalten?nein

Persönliche Beobachtungen zum FWS

Folgende Beobachtungen konnte ich bei der Betreuung von Projektmanagern zum Thema FWS und den Auswertungen feststellen:

  • Trotz sehr präziser und eindeutiger Fragen ist häufig eine zusätzliche Erläuterung (idealerweise durch eine Handbuch) gegenüber den Projektmanagern und in anderer Richtung eine Kommentierung spezifischer Sachverhalte durch die Projektmanager erforderlich. Einheitliche Vorgaben durch die von zentraler Stelle für spezifische nicht standardisierte Fälle sind sicherzustellen. Damit kann die Qualität auch für diese Fälle bezüglich der Aussagekraft des Frühwarnsystems sichergestellt werden.
  • Bei den Projektmanagementhandbuch-Ergänzungsfragen hat sich bestätigt, dass nur durch bereits ausgebildete Projekt- und Programmmanager sprechende Antworten gegeben werden konnten. Es ist besser auf eine Muss-Antwort zu verzichten um die Qualität der Aussagen nicht zu verwässern.

Bei der Analyse zur Adaptierung eines vergleichbaren Systems in einer Organisation ergeben sich folgende grundsätzlichen Überlegungen:

  • Die ersten Fragen lassen sich nahezu vollständig auf andere Unternehmen übertragen.
  • Ein derartiges ergänzendes (paralleles) Reporting ist nur durch globale Vorgaben durchzusetzen. Regionale oder gar abteilungsbezogene Initiativen würden zu viel Widerstand erfahren.
  • Eine automatische Benachrichtigung und Erinnerung zur Anlage des FWS-Berichtes ist vorzusehen.
  • Eine monatliche Frequenz kann sich, bei anderen Unternehmen mit durchschnittlich kleineren Projekten, als zu gering erweisen.
  • Eine automatische Analyse der Ergebnisse ist erforderlich unter Berücksichtigung der manuellen Zusatzkommentare. Eine Analyse ohne Berücksichtigung der Zusatzkommentare ergibt ein falsches Bild auf die Gesamtauswertung.
  • Wie bei allen anderen Reporting ist auch hier zu beachten, dass bei besonders vertraulichen Projekten / Kundenumfeldern ein Frühwarnsystem ebenfalls ausgeschlossen sein kann.
  • Die Berichte müssen IT-technisch so abgebildet sein, dass sie (nahezu) nicht umgangen und ignoriert werden können; um die Compliance zu Prozessen und Tools zu bestätigen. Diese sollten z. B. mit der Ablage des offiziellen Statusreports verbunden sein.
  • Die FWS-Ergebnisse sollten in bestehende Reports eingebunden sein um die klassischen Adressaten des Projektstatusberichtes ebenfalls über den Zusatzstatus des Frühwarnsystems zu informieren. Somit ist sichergestellt, dass auch dieser Empfängerkreis eine direkte oder indirekte Qualitätssicherung der Angaben durchführt.
  • Die Ergebnisse des Frühwarnsystems sollten regelmäßig mit vollständigen Projekt- oder Programmaudits verglichen werden um die Aussagekraft zu validieren und kontinuierlich zu verbessern.
  • Das Frühwarnsystem darf in einem Projekt nicht erst durch die erstmalige Ablage eines Projektstatusberichtes, sondern z. B. durch die Anlage von Projektnummern oder Projektcodes initial ausgelöst werden.
  • Das Frühwarnsystem sollte in Stufen eingeführt werden. Zuerst sollten ausschließlich Projekte mit hohem Projektvolumina oder Komplexität in den Umfang eingeschlossen werden (wichtig ist hierbei harte Kriterien anzuwenden). Dies erlaubt auch den Betreuungsaufwand der Projektmanager durch die Analysten besser zu managen.

Übergabe eines Programmes in 6 Phasen

2 min.

Summary

Sobald Sie ein Programm übergeben, sollten Sie einige Dinge bei der Vorbereitung und Übergabe selbst beachten. Hier hat sich für mich ein 6-Phasen-Ansatz bewährt welcher bei mir immer wieder eingesetzt wird.

1. Preparation (so früh wie möglich!)

  • Abstimmung mit den Stakeholdern
  • Überblick über den Wissenstransfer-Plan
  • Budget für Wissenstransferperiode vereinbaren
  • Suche nach einem Nachfolger und Erhalt der Zustimmung zu einer bestimmten Person von Stakeholdern
  • Endgültiges Startdatum des Nachfolgers bestätigen (Zeitleiste des Wissenstransferplans anpassen)

2. On-Boarding (-3 Wochen)

  • Nachfolger startet im Projekt als zusätzliche Ressource
  • Projektvereinbarung definieren
  • Nachfolger in allen regulären Administrationstätigkeiten wie Zugriffsrechte, Kalendereinladungen, Übergabeprozessdokumentation etc. einbinden
  • Nachfolger im Newsletter vorstellen

3. Shadowing (-2 Wochen)

  • Nachfolger war Ihr bisheriger Stellvertreter, wenn möglich.
  • Der Nachfolger nimmt auch in Ihren besuchten Meetings teil.
  • Der Nachfolger beobachtet alle Ihre Kernaktivitäten.
  • Nachfolger aktualisiert und ändert gemeinsamen Plan für den Wissenstransfer und leitet Aktivitäten ein.

4. Re-Shadowing (-1 Woche)

  • Nachfolger übernimmt Verantwortung
  • Räumen Sie Ihren Schreibtisch und übergeben Sie ihn an den Nachfolger
  • Der Nachfolger leitet alle Ihre früheren Meetings
  • Der Nachfolger ist für alle Ihre bisherigen Prozesse verantwortlich
  • Stehen Sie zur Verfügung für alle Fragen Ihres Nachfolgers

5. Backup (beginnt mit dem Tag der Übergabe)

  • Weniger Präsenz zeigen, nur an internen Teambesprechungen teilnehmen, aber keine Kundengespräche
  • Seien Sie für jede Hilfe für Ihren Nachfolger da
  • Bereiten Sie sich darauf vor, einige operative Tätigkeiten zu übernehmen um den Nachfolger bei der Einarbeitung zu entlasten
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger

6. Phase Out (+1 Woche)

  • Erledigen Sie alle Off-Boarding-Aktivitäten selbst
  • Projektvereinbarung auflösen
  • Seien Sie da, um Ihrem Nachfolger zu helfen
  • Nehmen Sie keine Betriebsaufgaben mehr an
  • Geben Sie eine Abschiedsparty und verabschieden Sie sich im Newsletter
  • Senden Sie alle noch eingehenden Anfragen / Fragen an Ihren Nachfolger
  • Gehen Sie! (+2 Wochen)

Erfolgsfaktoren für eine ordnungsgemäße Übergabe

  • Binden Sie Kunden und alle Stakeholder frühzeitig ein.
  • Ordnen Sie Prozesse nicht programm- / personenzentriert an, sondern prozess- / verantwortungsszentriert.
    • Seien Sie nicht selbst Single Point of Contact für mehrere Prozesse,
    • Machen Sie stattdessen jedes Ihrer Teammitglieder von Anfang an für einen oder mehrere Prozesse verantwortlich (Management by Objective).
  • Planen und bereiten Sie Ihre Übergabe als eigenes Projekt vor.
  • Erstellung eines Wissenstransferplans, der von allen Beteiligten abgestimmt werden muss.
    • Aufschlüsselung des Wissenstransfers in granulare Aktivitäten (1-3 Stunden).
    • Bitten Sie Ihren Nachfolger, diesen Plan zu pflegen und jede abgeschlossene Aktivität abzuhaken.
    • Behandeln Sie diesen Plan und aktualisieren Sie ihn wie jeden anderen Projektplan.
  • Kommunizieren Sie Ihren Weggang dem gesamten Team spätestens zu Beginn der Wissenstransferphase.
  • Sehen Sie nach erfolgreichem Wissenstransfer eine Backup-Phase vor von bis zu zwei Wochen.
  • Definieren Sie ein klares Übergabedatum im Wissenstransferplan.

Viel Spaß in Ihrem neuen Projekt / Programm!

Projektplanungssoftware – alles nur Mist?!

1 Minute


Summary

Die Projektplanungs- und Steuerungssoftware nur als visuelle Darstellung des Planungsstandes zu nutzen ist vergeudete Zeit. Einige wenige Tipps sind zu befolgen und MS Project und Co sind auch für die Projektüberwachung und -steuerung sehr sinnvoll einzusetzen.

Ich höre immer wieder von angehenden Projektmanagern, aber auch von erfahrenen Projektmanagern, dass ein Projektsteuerungstool wie z. B. MS Project nicht praktikabel einzusetzen ist. Es sei zu kompliziert und die eigentliche Steuerung sei damit auch nicht wirklich möglich.

Wenn Du folgende Tipps beachtest geht nichts mehr schief

  • Stelle in den Optionen ein, dass MS Project oder das Tool Deiner Wahl die Planung auf „feste Arbeit“ basiert
  • Die Verfügbarkeiten (Stundenkapazität und Urlaube) der Ressourcen/Qualifikationen müssen im Projektkalender eingetragen werden.
  • Kein manuelles Datum (Termin) setzen, außer Projektstart oder Endtermin.
  • Für jeden Vorgang / Arbeitspaket muss ein Vorgänger (zumindest der Projektstartmeilenstein) und Nachfolger (zumindest der Projektendmeilenstein) eingetragen werden.
  • Keine Dauer eingeben, sondern nur Aufwand für den Vorgang / Arbeitspaket.
  • Für jeden Vorgang sollte nur eine Ressource/Qualifikation eingetragen werden.
  • Den kritisch Pfad im Ablauf- und Terminplan (Gantt) immer anzeigen lassen. Dieser muss durchgängig über die gesamte Projektlaufzeit ohne Unterbrechung angezeigt werden. Ansonsten liegt ein Fehler vor, wie z. B. manuelles Datum gesetzt.
  • Plane nur maximal 2-3 Monate rollierend im Detail (Ressourcen und Aufwände) voraus.

Und das letzte Hemmnis ist dann immer wieder, dass Dein Unternehmen keine MS Project Lizenz für Dich investiert. Dann besorge Dir ProjectLibre als Opensource oder eine andere Freeware.

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

Vorsprung durch Frühwarnung im Projekt – Teamstimmung als Indikator

3 min.

– Methodischer Umgang mit Emotionen im Projekt –

Summary

Als Projektportfoliomanager möchten Sie in allen Ihren Projekten vollständige Projektaudits vermeiden, um mögliche Abweichungen zu identifizieren. Sie können eine sehr einfache Umfrage verwenden, um Überraschungen zu vermeiden.

Als Projektdirektor oder Projekt-Portfolio-Manager steht Ihnen zusätzlich ein anderes Frühwarnsystem zur Verfügung.

Als Projekt- oder Programmmanager möchten Sie Ihr aktuelles Vorhaben auf sehr einfache Weise mit früheren Projekten vergleichen.

Es gibt mehrere Möglichkeiten, die Teamstimmung in Projektteams zu festzuhalten. Ich verwende seit einigen Jahren folgenden Ansatz mit zuverlässigen und soliden Ergebnissen.

Dies geschieht systematisch durch das Sammeln von „SmileyPoints“ über ein Online-Befragungstool. Beispiele für kostenlose Tools sind kwiksurveys.com, die kostenlose Version von surveymonkey.com oder Google Forms.

Fragen, die in der Umfrage gesammelt werden sollen

  1. „Wie glücklich bist du über das Programm/Projekt?“ Dann sollte das obige Bild dieser Frage beigefügt werden.
  2. „Was kann Programm-/Projektmanagement zur Verbesserung beitragen?“
  3. „Was kannst du selbst tun, um dich zu verbessern?“
  4. „Rumor Box: Wenn es Gerüchte gibt und du irgendwelche Fragen dazu hast, lass es uns bitte hier wissen, um es zu klären.“

In größeren Programmen können Sie eine Frage hinzufügen, um die Teamzuordnung des Teilnehmers zu identifizieren, um Hinweise auf die Unterschiede zwischen den verschiedenen Teilteams innerhalb des Programms geben zu können.

Die Umfrage sollte jede zweite Woche durchgeführt werden, wenn es sich um längerfristige Projekte oder Programme handelt. Es kann ein guter Trendindikator während des Projektlebenszyklus sein. Die Mindestbeteiligung der Projektmitglieder sollte mindestens 10% aller Projektteammitglieder überschreiten. Weniger wird nicht aussagekräftig. Für kleinere Teams muss eine höhere Mindestteilnehmerzahl erreicht werden.

Ergebnisinterpretationen

Der Durchschnitt (Mittelwert) und die Standardabweichung aller Ergebnisse der Antworten auf Frage Nummer eins gibt Ihnen einen klaren Hinweis auf die Teamstimmung innerhalb des Programmes oder des Projektteams.

Je höher die Standardabweichung aller zu hinterfragenden Werte ist, desto offensichtlicher sind:

  • mangelnde Kommunikation innerhalb des Teams
    (insbesondere von oben nach unten und von unten nach oben)
  • Rollen und Verantwortlichkeiten, die nicht klar definiert oder für das Team nicht transparent sind und
  • der Umfang ist nicht klar definiert oder nicht transparent – zumindest für das erweiterte Team.

Je niedriger der Mittelwert der zu befragenden Ergebnisse ist, desto weniger attraktiv ist das Projekt für die Teammitglieder. Daher ist auch die Begeisterung für das Projekt geringer. In sehr kritischen Projektsituationen (z. B. aufgrund der Arbeitsbelastung nicht erreichbare Work Life Balance) ist der Durchschnitt tendenziell niedrig.

Nun stellt sich die Frage, ob es einen „Korrelation zwischen Standardabweichung und Mittelwert“ gibt? Nicht wirklich in allen Fällen. Die Standardabweichung sollte in einem gut organisierten Programm gering sein. In der gleichen überlasteten Organisation, wenn Dinge wie Strukturen, Rollen und Verantwortlichkeiten, Kommunikationskanäle, Umfang gut definiert und für das Team transparent sind, sollte die Standardabweichung noch gering sein.

Die nächste Frage ist, was ist niedrig und was ist hoch“? Eine gute! Die Erfahrung zeigt, dass Werte zwischen +2 und +4 als Durchschnitt bei gut funktionierenden Projekten sehr häufig sind. Natürlich gibt es die Tendenz, dass neue Teammitglieder in einem Projekt ihr persönliches Glück in Bereichen von +6 bis +10 bewerten. Diese Artefakte benötigen eine kritische Masse an Reaktionen, um sich auszugleichen.

Dies unterstützt nicht die Hypothese, dass ein neues Projekt mit neuem Team automatisch einen guten SmileyPoint Durchschnittswert bedeutet. Das gesamte Team beachtet alle Qualitätskriterien des Teams gut, bevor es seine SmileyPunkte vergibt, und im Durchschnitt wird die Bewertung wieder auf den „realen“ Wert gebracht.

Am anderen Ende der SmileyPoint-Skala zeigen niedrige Durchschnittswerte von -6 bis -2 Projekte an, die sich in einem Turnaround-Modus befinden oder zumindest einen Turnaround benötigen. Es müssen sofortige Maßnahmen ergriffen werden.

Für die Standardabweichung kann folgendes Muster identifiziert werden. Werte von 6 zeigen ein massives Defizit an implementierten Strukturen, fehlende Rollendefinitionen oder zumindest Transparenz darüber. Die Kriterien e) bis i) von unten nach oben beeinflussen die Standardabweichung nach meiner Erfahrung. Programme in gutem Zustand zeigen eine Standardabweichung von weniger als 3.

Natürlich ersetzt eine solche Umfrage keine Einzelgespräche und Interviews, aber sie gibt Ihnen einen sehr präzisen, unterstützenden Beweis für Ihre Ergebnisse im Gespräch oder zumindest ein erstes Gefühl, falls Sie überhaupt keinen Kontakt zum Programm hatten.

In einem anderen Beitrag werde ich ein paar Elemente und Ideen auflisten, was zu implementieren ist, um die SmileyPoints in Ihrem Team zu verbessern.

Ihre Kommentare und Teilnahme zur Verbesserung von SmileyPoints

Wenden Sie SmileyPoints aktiv in Ihren Projekten an!

Ihre Kommentare und aktive Teilnahme sind gewünscht. Beides können Sie in folgender Umfrage hinterlegen und Sie werden auf Wunsch über neue Erkenntnisse informiert.

Diese Werte sollten Sie erfassen:

  • Mittelwert- und
  • Standardabweichungen
  • Anzahl der Teilnehmer von der Gesamtzahl der Teammitglieder

aus einigen Ihrer Projekte und Programme. Besonders hilfreich wäre es, wenn Sie einen Auditor oder Ihr persönliches Rating auf der gleichen Skala von unten zu folgenden Themenclustern hinzufügen könnten:
a. Teamstimmung innerhalb des erweiterten Teams
b. Programmkostensituation in guter Verfassung und transparent für das Projektmanagement.
c. Infrastruktur gut ausgebaut (z. B. Drucker, Büroräume)
d. Richtiges Fähigkeiten/Personal an Bord
e. Architektur und Lösung gut definiert
f. ordnungsgemäß angewandte Methoden
(z. B. Projektplanung, Issue- und Risikomanagement)
g. Rollen und Verantwortlichkeiten und Struktur klar definiert
h. Leistungsumfang und Akzeptanz- und Abschlusskriterien klar definiert und transparent
i. Governance klar definiert und etabliert

Bitte nutzen Sie dieses Formular, um Ihr Feedback zur Verbesserung von SmileyPoints einzureichen.

Hier ein Slide Deck zum Thema.

Dieser Beitrag wurde bereits am 23.07.2011 auf GooglePlus veröffentlicht.