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.	Frage	Risikoantwort
1	Ist 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
4	Verläuft die Personalbesetzung entsprechend der Planung im Projektplan?	Ja
5	Ist eine gemeinsame Projekt-Governance verabschiedet worden?	Ja
6	Wurde 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
9	Hat 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.	Frage	Risikoantwort
1	Wurde die Projektdefinitions-Vorlage aus dem Projektmanagementhandbuch verwendet?	nein
2	Wurde das Schätzverfahren und die Schätztemplates verwendet gemäß Projektmanagementhandbuch?	nein
3	Wird wöchentlich eine Earned Value Berechnung basierend auf dem aktuellen Projektplan durchgeführt?	nein
4	Werden 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.