Mal wieder ein interessanter PM-Thread auf XING (Abo-Dienst) zum Thema Statusampeln im Projektmanagement. Hier eine Zusammenfassung:

Selbst wenn die Ampelfarben vorweg eindeutig definiert worden sind, haben sie dennoch eine politische Dimension. Farben werden trotz allem unterschiedlich gesehen. Niemand will unangenehm auffallen, es drohen Sanktionen,…

Ehrlichkeit und vernünftige Reporting-Zeiträume wären Voraussetzung für einen sinnvollen Einsatz von Ampeln. Leider ist dies meist nicht so gegeben.

Eindeutige Ampeln sind ein hilfreiches Kommunikationsinstrument, aber inwieweit sie tatsächlich zur Projektsteuerung geeignet sind, ist ein anderes Kapitel.

Im Sinne von KISS (Keep it simple and stupid) sind Ampeln (ähnlich wie Smileys) eine willkommene Vereinfachung. Man spricht hier von Komplexitätsreduktion (das hört sich besser an…). Beides ist ein Reporting mittels Symbolen.

Eine interessante Frage ist auf welcher Ebene Ampeln zum Einsatz kommen:

·         Als Trend für das Gesamtprojekt

·         Auf Meilensteinebene (auch wenn es hier vielleicht bessere Alternativen wie die Meilenstein-Trendanalyse (MTA) gibt.

·         Auf Ebene einzelner Vorgänge

Konkurrierende Ampeln, d.h. den gleichen Sachverhalt  unabhängig voneinander von verschiedenen Beteiligten einschätzen zu lassen, scheint in der Tat niemand einzusetzen.

Eine Kritik an der Ampel ist ihre Beschränkung auf wenige Status (rot/gelb/grün), auch wenn in der Praxis die Kreativität zu Erweiterung unbeschränkt ist (gelbrot/gelbgrün, weiß für noch nicht begonnen, schwarz für abgeschlossen,…).  Alternativ würde sich ein Tacho oder Speedometer anbieten.

Eine berechtigte Kritik geht dahin, was eigentlich festgestellt werden soll: Der Ist-Zustand oder eine Prognose.

Das grundlegende Problem eines Ampelsystems ist aber dass, wir immer nur reagieren anstatt zu agieren, selbst mit einem System welches uns einen Trend aufzeigt.

Ein weiterer Teilnehmer schreibt:

Persönlich glaube ich nicht, dass Ampeln Projekte steuern, aber sie helfen dem Betrachter einfach schneller und rascher die Situation zu erfassen.

Bei kurzen Projektzyklen kann dann auch die Projektretrospektive eine Alternative sein, um den Erkenntniszuwachs sicherzustellen.

Danny Quick hat einen lesenswerten Beitrag des Linux-Magazins ausgegraben, in dem versucht wird Methoden und Vorgehen agiler Softwareentwicklung auf Betriebsthemen zu übertragen. Wie bei allen „agilen“ Themen braucht es dafür gleich einen neuen Namen: Agile Software Administration.

Für ITIL/Governance geprägte Welten mag sich das Gedankentum zunächst anarchistisch/revolutionär anhören, letztlich setzt es aber, wie alle agilen Ansätze, auf einer gestärkten Kommunikation und Eigenverantwortung auf – zwei Dinge, die noch keiner Betriebsorganisation geschadet haben.

Über Business Intelligence wurde an dieser Stelle ja schon mehrfach schwadroniert:

#139 Lieber Excel als BI

#140 Zum Stand von BI-Projekten in Deutschland

In Computerwoche und CIO-Magazin finden sich jetzt wieder weitere Beiträge, die mich in meiner Meinung bestärken:

Unzufriedenheit mit Business Intelligence wächst (CIO)

Erfolg von Business Intelligence schwer messbar (CIO)

Noch große Spielräume für Optimierung: Back-Office-Chaos verhindert BI-Erfolge (Computerwoche)

Die besten BI-Werkzeuge sind nutzlos, wenn man nicht weiß, was man tut!

Eine wesentliche Aufgabe in IT-Projekten ist häufig die Übersetzerrolle zwischen IT und Business. Und selbst innerhalb dieser beiden Welten gibt es weitere Sub-Welten, denn das Top-Management spricht eine andere Sprache als der Abteilungsleiter oder der Anwender und der CIO tickt anders wie ein Application Manager oder ein Programmierer oder ein Hardware-Techie.

In einem Bericht des CIO-Magazins von den Hamburger IT-Strategietagen wird Rainer Janßen (CIO der Münchener Rück) zitiert, der dieses Übersetzungsdilemma aus seiner Warte als IT-Leiter auf den Punkt bringt:

Meine IT versteht mindestens zehn Sprachen, die aus dem Marketing, dem Controlling, dem Vertrieb und und und.

Oft genug werden IT-Strategien kritisiert und gescheiterte IT-Projekte in der Luft zerrissen, aber Janßen dreht den Spieß einfach um:

Statt immer nur auf die IT zu schimpfen, sich in Selbstmitleid kleinzureden und für alle mitdenken zu wollen, liegt die Ursache für viele Fehlentwicklungen im Business. Warum die IT- der Geschäftsstrategie nicht folgen könne? Ganz klar: „Nur ganz wenige Unternehmen haben überhaupt eine Strategie“, behauptet Janßen. Und zwar eine, die diesen Titel verdient und nicht nur aus der Aussage besteht, dass Umsatz und Gewinn steigen sollen.

Natürlich ist es vielleicht ein bisschen zu einfach, den schwarzen Peter an das Business durchzureichen, Eigenverantwortung hat auch die IT, aber es braucht schließlich beide Seiten!

Die Computerwoche zititert eine kritische Studie des Beratungshauses Actinum Consulting zum Stand von BI-Projekten in deutschen Unternehmen und fasst kritisch zusammen:

Offenbar fühlen sich immer mehr deutsche Unternehmen mit ihren BI-Projekten überfordert, nicht zuletzt, weil sie voreilig bunte Tools kaufen.

Auch den Herstellern wird eine Mitschuld gegeben:

Demnach werben die Anbieter mit interessanten Features, schnellen Einführungszyklen oder der guten Integration ihrer Produkte, würden aber auf die tatsächlichen Bedürfnisse der Anwender oft nicht eingehen.

Das CIO-Magazin zititert eine Studie von Wolfgang Martin gemeinsam mit Andreas Seufert vom Institut für Business Intelligence, wonach 8 von 10 Mittelständlern Excel statt Business Intelligence Werkzeugen für Unternehmenssteuerung und Controlling einsetzen.
Ich finde das ehrlich gesagt gar nicht so unsympathisch, vorausgesetzt man weiß was man tut! Moderne BI-Tools und Informationssysteme können zweifelsohne von unschätzbarem Wert sein, aber bei unsachgemäßem Einsatz schütten Sie uns mit unnützen Informationen zu oder werden zu reinen Rechtfertigungsinstrumenten. Manchmal kann weniger Tool-Einsatz mehr sein. Und weiter gilt: A fool with a tool is still a fool.

PM Hut via pjmb:  5 Tipps für den Umgang mit Projektsponsoren.

Die Computerwoche berichtet über einen neuen Vermittler: Etengo.

Dabei handelt es sich um keine Unbekannten, sondern um Abtrünige von Hays.
Auf den ersten Blick und nach Registrierung macht das Angebot eine sehr seriösen Eindruck – vielleicht noch mit ein paar Anlaufschwierigkeiten. Mal schauen, was daraus wird.

Passend hierzu ein weiterer Link zur Computerwoche.

„Beratung“ ist ein vielstrapaziertes Wort.
„Berater“ sind deshalb häufig auch in Verruf gekommen.

Was Projekt- und Prozessberatung tatsächlich leisten kann, damit setzt sich Patrick Fritz in einem lesenswerten Beitrag auf Jahooda auseinander und zeigt fachlichen, methodischen und sozialen Nutzen auf.

Storytelling war mal ein Hype und durchdringt langsam und völlig unspektakulär viele Bereiche, so findet man z.B. auch im Requirments Engineering häufiger an Stelle von Use Cases bereits User Stories, um anwendergerecht die Anwendugsszenarien zu beschreiben. Ganz zu schweigen von Anwendungen in Marketing oder in Lernprozessen.

Eine Einführung in Storytelling in Organisatiosnentwicklung und Changeprozessen geben beispielsweise Frenzel/Müller/Sottong mit „Storytelling. Das Harun-al-Raschid-Prinzip“ (Amazon).

Viele englischsprachige Ressourcen zum Thema Storytelling finden sich bei Tim  Sheppard. Einen deutschsprachigen Blog zum Thema betreibt Sigrid Hauer. Und bei XING, gibt es natürlich auch eine eigene Gruppe.