
Es gibt ja den Grundsatz, dass der Titel eines Textes keine negative Konnotation haben soll. Entweder positiv, konstruktiv oder motivierend. Ich muss gestehen, mir ist nichts Besseres eingefallen als der Gegensatz.
Ich hatte schon einmal dargelegt, warum Veränderungen scheitern (können). Da hatte ich ein entsprechendes Feedback zu dem gewählten Titel erhalten. Hier ist übrigens der Beitrag, den ich meine:
Warum scheitern Veränderungen?
Vermutlich wird jeder, wenn nicht aus eigener Erfahrung, so jedoch über Berichte aus dem Bekanntenkreis, von großen und aufwendigen Projekten gehört haben, die gescheitert sind. Nun ist „Scheitern“ per se zwar negativ belegt, aber im Kern nichts Negatives. Schließlich lässt sich aus einem Scheitern auch vieles lernen, wenn man die richtigen Schlüsse zieht.
Ganz oft sind ganz schnell Überschriften für die Gründe gefunden:
- das Projektziel war von vornherein unrealistisch!
- das Budget wurde nachträglich zusammengestrichen
- die zugesagten Ressourcen waren nicht verfügbar
- der Projektausschuss trifft keine Entscheidungen
- es sind zu viele Themen nachträglich in das Projekt „gekippt“ worden
- …
Die Liste dieser Gründe lässt sich sicherlich beliebig fortsetzen. Davon ab, ob es im Einzelfall auch jeweils die tatsächlichen Gründe sind, oder ob es auch nur „politisch“ akzeptierte Gründe sein mögen, die Ursachen lassen sich vergleichsweise einfach in einer der folgenden Gruppen einordnen:
- Das Zielbild des Projektes wird nicht von allen Beteiligten in gleichem Maße geteilt
- Mitarbeiter bzw. Teilnehmer des Projektes arbeiten nicht (in ausreichender Qualität) oder nicht rollengerecht
- Die Linienhierarchie überstrahlt die Projektstruktur
- fehlende Transparenz der Projektteilnehmer und ihrer Arbeitspakete/Fortschritte zueinander
- fehlende Klarheit in Teilaufträgen, Ergebnisobjekten, Abhängigkeiten und Priorisierung
Auch hier will ich nicht behaupten, dass diese fünf Gruppen zwingend vollständig sind, sondern lediglich veranschaulichen, dass die meisten (potentiellen) Probleme eines Projektes mit Führung und Steuerung zusammenhängen.
Es hat sich in den letzten Jahren die Unart entwickelt, dass häufig Ampeln (bzw. die Farben grün, gelb, rot) benutzt werden, um Statusberichte zu ersetzen oder mindestens jedoch sie zusammenzufassen. Natürlich ist es so, dass mit zunehmender Größe eines Projektes die Informationsflut und die Komplexität zunimmt, zumeist sogar überproportional. Allerdings steigt mit zunehmender Projektgröße auch die Kritikalität des Projektes für das Unternehmen. Aus dieser Sicht ist es gar nicht gerechtfertigt Informationen, wenngleich aus einem Servicegedanken heraus, zu sehr zu vereinfachen oder vorzuverdauen. Es gibt in jedem Projekt Rollen, die ihr Gehalt (auch) dafür bekommen, dass sie die Projektarbeit überwachen, kontrollieren und Entscheidungen treffen.
Wann darf man Ampeln verwenden?
Die Verwendung von Ampelfarben hilft dabei verschiedenartige weiche Faktoren in Gruppen zu bündeln oder mit einer beruhigenden bzw. alarmierenden Wahrnehmung zu versehen. Ebenfalls wiederkehrende (qualitative) Beobachtungen lassen sich gut über Farben darstellen, wenn es nur um Richtungsveränderungen im Sinne von Verbesserung oder Verschlechterung geht.
Es geht also immer primär um die (verantwortungsvolle) Reduktion von Komplexität, aber nur im Kontext von Faktoren mit geringer Kritikalität und/oder geringer Dringlichkeit. Im weiteren Sinne ist es ein Themenspeicher und eine wie auch immer geartete Ampelfarbe führt lediglich dazu, dass ein Thema aus diesem Themenspeicher herausgenommen und neu priorisiert wird.
Wann sind Ampeln tunlichst zu vermeiden?
Harte Projektergebnisse, wie zum Beispiel Meilensteine des Projektes, sind nicht geeignet um lediglich durch einen dreifarbigen Code bewertet zu werden. Auch quantitative Zielgrößen sind nicht durch eine Dreistufigkeit adäquat abzubilden. (Es spricht natürlich nichts dagegen, die Werte durch eine unterschiedliche Farbigkeit zu betonen, aber es geht eben primär um die Werte und nicht um die Farben.)
Was ist das Problem?
Die Arbeit mit der Ampelfarbe bringt mehrere (psychologische) Probleme mit sich:
- die Farbgebung ist zumindest in Teilen willkürlich; anstelle über einen Befund zu sprechen wird, quasi als Übersprungshandlung, über die richtige Farbgebung diskutiert
- niemand meldet gern, dass er es nicht geschafft hat seine Aufgabe zu bewältigen oder seine Probleme zu lösen. Es besteht somit ein erheblicher Anreiz kritische Farben („rot“) erst viel zu spät zu melden, sodass keine ausreichende Zeit für eine vernünftige Gegenreaktion mehr bleibt
- über die Ampelfarben wird die Aufmerksamkeit des Auftraggebers und/oder des Lenkungsausschusses bewusst oder unbewusst gesteuert. Hierdurch erfolgt eine Ablenkung oder gar eine Täuschung
Ampelfarben führen also nicht dazu das Reporting oder einen Statusbericht zu vereinfachen, sondern sie verschleiern ggfs. wichtige Informationen und führen Entscheidungsträger in die Irre. Die Steuerungsfunktion wird somit nicht entlastet, sondern behindert – letztlich weil Transparenz fehlt bzw. erst viel zu spät entsteht.
Es spricht nichts dagegen besondere Themen oder Ereignisse in den Berichten zu betonen, weil das Projekt sie für wichtig hält. Auch grafische Kurven und wertabhängig gefärbte Zahlen können ihren Nutzen entfalten, denn sie betonen Informationen und ersetzen sie nicht.
Wie geht es denn dann?
Zuallererst: klare Spielregeln vereinbaren und vor allem auch dokumentieren!
- Was ist die Aufgabe?
- Welche Ressourcen werden benötigt und zur Verfügung gestellt?
- Wie sieht der Zeitplan aus, welche Meilensteine sind einzuhalten?
- Welche Ergebnisobjekte müssen jeweils vorliegen?
Und hierauf (nur hierauf) ist ein Controlling aufzusetzen.
Wichtig ist zudem, dass das Controlling rollengerecht durchgeführt wird.
Warum ist das so?
Oftmals entsteht das Problem, dass irgendwo unterwegs und im Vorbeigehen die Spielregeln verändert werden. Wenn jemand fragt oder versucht sich dagegen zu wehren, dann wird gern mit Agilität gekontert.
Weniger Ressourcen oder weniger Zeit durch den Auftraggeber und schon sind wir ganz schnell wieder bei den Ampeln. Lieber gelb als rot, denn niemand mag von Anfang an zu geben, dass das Projekt durch die letzte kleine Entscheidung unrealistisch geworden ist. Das Schöne ist doch, dass eine gelbe Ampelfarbe, die erst mit Überschreiten der Ziellinie rot wird, weniger nervös macht, als eine Konstante zeitanteilige Zielerreichung von 70 % auf dem Projekt. Kreativ wird das Reporting erweitert um Teilfelder, in die das Projekt überdurchschnittlich gut gelaufen ist, um auch ein bisschen Grün in die Farbpalette hinein zu bekommen.
Ich weiß es nicht wirklich, aber ich glaube, der Berliner Flughafen hatte ganz viel mit grünen Ampeln zu tun. Das Ergebnis ist mittelmäßig, keiner ist so recht gewesen, aber die Ampeln waren schön grün.
Stattdessen muss jede Abweichung von dem ursprünglichen Projektauftrag (oben so salopp als Spielregeln bezeichnet) sauber über einen Change-Request dokumentiert und den entsprechenden Vertretern des Projektes rollengerecht verhandelt werden. Ich betone hier das Rollengerechte sehr gern, weil es für Führungskräfte der Linienorganisation oftmals einfacher und verlockend ist, die Veränderung über die Schulterklappe von der Seite in das Projekt zu geben.
Natürlich gibt es auch ein Leben nach dem Projekt, die Mitarbeiter kommen zurück in ihre Linientätigkeit und damit auch zurück zu ihrer alten Führungskraft. Aber es ist eben auch die Verantwortung dieser alten und neuen Führungskraft, die Integrität eines Projektes nicht zu beschädigen in dem Trampelpfade in den Rasen getreten werden. Und natürlich ist es die Aufgabe des Projektauftraggebers ein Projekt vor derlei Einmischung zu beschützen.
Für Einmischungsversuche wäre in der Tat eine rote Ampelfarbe angemessen.
Zur weiteren Lektüre empfehle ich:
Warum auch die Auswahl von Führungskräften ein Teil des Change Managements ist
Veränderungen sind nicht homöopathisch = weniger ist nicht mehr