Das Thema „Scheitern“ hatten wir schon bei der Diskussion über 10projects, d.h. eigentlich hatten wir dabei die Feststellung, dass Fehler und Scheitern vollständig ausgeblendet werden und dort nur Success-Stories Einzug erhalten, obwohl die Realität ganz anders aussieht. Um so eindrucksvoller ein sehr persönlicher Post von Zamyat M. Klein zum Thema Scheitern:

Die Kunst des Scheiterns- 1- Fehler und Kritik

Die Kunst des Scheiterns- 2: Persönliche Geschichte

Es geht zwar nicht um das Scheitern von Projekten, sondern um den Umgang mit persönlichen Niederlagen. Oder besser: wie man konstruktiv damit umgeht. Lesenswert!

Projektmanagement ist eine Technik und keine Wissenschaft. Das Verhältnis von Wissenschaft und Technik ist wechselseitig befruchtend. Während Wissenschaft vor allem beschreibend und erklärend wirkt, ist Technik (und so auch Projektmanagement) vor allem nutzenstiftend. Böse gesagt könnte man auch formulieren: Projektmanagement ist nie Selbstzweck, Wissenschaft mitunter schon.

Natürlich kann man auch Projekte wissenschaftlich betrachten.

Richard Joerges tut dies in einem Beitrag in dem er versucht von der Chaostheorie Rückschlüsse auf Projekte zu ziehen. Ähnlich könnte man auch versuchen von kybernetischen Modellen oder Organisationstheorien Rückschlüsse auf Projekte zu ziehen. Einen sehr interessanten Ansatz finde ich dabei die Theorie sozialer Systeme nach Luhmann – auch wenn ich noch keine spezielle Ausarbeitung über Projekte finden konnte. Luhmanns zugegebenermaßen abstrakter Ansatz, dass sich soziale Systeme über Kommunikationen konstituieren (und nicht über die teilnehmenden Individuen), rückt das Thema Kommunikation in den Vordergrund und da gehört es auch im Projektmanagement m.E. nach hin! Mit einer solchen Theorie liessen sich Phänomene, wie wir sie aus dem Projektalltag hinreichend kennen, von sich wandelnden Projektaufträgen, politischen Spielchen und Projektdynamiken, erklären, die in den klassischen PM-Methodologien nur ein Schattendasein fristen.

Im Kommentar zum Kommentar zitiert Patrick Fritz seinen Dozenten aus dem Consideo-Workshop mit dem Ergebnis: wir meinen alle das gleiche und haben uns lieb.  😉

Allerdings würde ich einen anderen Passus als Patrick hervorheben:

Der MODELER erhebt aber den Anspruch, dass das, was wir eh sehen und denken, erfasst und aufgezeigt werden kann – erst einmal völlig unabhängig von etwaigen Methoden. Wie gut und aussagekräftig ein Modell ist, hängt einzig davon ab, wie gut oder ausreichend meine Gedanken, meine Wahrnehmungen sind. Den Mehrwert stiftet das Modell dann damit, dass ich mit Blick auf meine Gedanken Ideen für weitere Gedanken habe. Dass ich diese Gedanken nicht nur mir, sondern auch anderen vor Augen führen kann und damit die Kommunikation um ein Vielfaches effizienter gestalten kann – auch in Gruppen! Und schließlich, dass mir aus meinen vielen Einzelannahmen ein Gesamtzusammenhang aufzeigt wird, der häufig fern meiner Bauchintelligenz mir neues Wissen, neue Erkenntnisse ermöglicht, und zwar nicht derart, dass dann schon der Lauf der Welt getroffen wurde, sondern nur die Konsequenzen meiner Annahmen aufgezeigt sind.

Die Schlüsselfrage scheint mir aber darin zuliegen, welchen Ansprüchen und Anforderungen eine solche Modellierung gerecht werden kann. Wo liegen unsere blinden Flecken und wo die blinden Flecken der Methode oder unseres Tools…

Ich habe meine Skepsis bezüglich einer all zu hoch bewerteten quantitativen Modellierung zum Ausdruck gebracht. Aber was bleibt da vielmehr als das reine Malen von Zusammenhängen. Bei Thomas Allweyler bin ich hierzu über einen interessanten Beitrag gestossen: Viele malen nur.

Lean Management war eigentlich ein Schlagwort der 90er.

Nun hat Lean Management die Gemeinde der Agilen Softwarentwicklung erreicht:

MacPM: Projekmanagement – Von Scrum to Scrum-ban
Henrik Knisberg: Kanban vs Scrum

Da trifft die eine Modewelle (Agile SW-Entwicklung) auf eine schon wieder etwas eingestaubte Welle (Lean Management, Kanban & Co).

Dabei sollten wir doch alle besser die Kirche im Dorf lassen: Nicht der Titel, sondern was dahinter steckt, ist interessant – gesunder Menschenverstand!!

Nichts kann „leaner“ sein als nicht-hierarische agile Vorgehensweisen. Und agile Vorgehensweisen sind in hohem Maß geprägt von Selbstorganisation. Selbstorganisation ist für mich das Zauberwort.

Dogmatisch sind nur unsere Ettiketten „Lean Management“, „Agiles Projektmanagement“, etc. …

In dem manchmal etwas schmalbrüstigen pmhut weist Lynda Bourne zurecht darauf hin, dass agiles Vorgehen keine eigene Methodologie darstellt, sondern, selbst Projektmanagement (also Organisation oder auch Selbstorganisation) erfordert. Für mich schließt sich hier der Kreis.

Auch Patrick Fritz von Jahooda berichtet von seinen Erfahrungen mit dem Consideo Modeler. In seiner Bewertung („Ja, aber…“) ist er vor allem was quantitative Modellierungen (und das nicht nur mit dem Consideo Modeler, sondern allgemein) betrifft eher skeptisch und warnt insbesondere vor Scheingenauigkeiten.

Damit spricht er mir aus der Seele: Systemanalyse und Modellierung sind Hilfsmittel und wir müssen uns ihrer Grenzen stets bewusst sein.

Anschaulich belegen lassen sich solche Grenzen z.B. mit dem Fiakso im Risikomanagement der Banken, die zur aktuellen Finanzkrise geführt hat. Hierzu Wolfgang Hartmann, Mitglied des Vorstands und Chief Risk Officer der Commerzbank AG, im Interview mit der Süddeutschen Zeitung:

„In normalen Zeiten haben die Risikomodelle gute Arbeit geleistet. Aber wir müssen noch stärker mit Stressszenarien arbeiten und unsere Schlussfolgerungen daraus ziehen. „

Zwar gesteht Hartmann die Grenzen der Modellierung ein, glaubt diese aber noch mit weiterer Modellierung heilen zu können. (Muss er ja auch: Das ist sein Job.)

An anderer Stelle (RiskNet) wird er noch aus dem Jahr 2005 zitiert, wie er leichtfertig die Tragweite systemischer Risiken herabspielt:

„Nein. Ich halte die Gefahr, die von systemischen Risiken ausgeht, für übertrieben. In der Tat besteht eine theoretische Anfälligkeit, doch hat die Vergangenheit gezeigt, dass auch Risiken von volkswirtschaftlicher Tragweite, die wie beispielsweise in Japan das ganze Banken- und Finanzsystem betroffen haben, nicht alles in den Abgrund reißen.“

Neben den von Patrik Fritz bereits angesprochenen Scheingenauigkeiten, zeigt das Beispiel wie der Glaube an ein Modell in die Bredouille führt, sofern man sich nicht der Prämissen und Grenzen des eigenen Modells im Klaren ist.

In diesem Sinne schließe ich mich ganz dem Kollegen Fritz an: Modellierung – ja, aber…

Die Systemtheorie hat mich wieder: Ich experimentiere zur Zeit mit dem Consideo Modeller und versuche mich an ein paar einfachen Modellierungen. Eine kostenlose Demo-Version gab es bereits in der c’t 17/2008 und einen Artikel mit Beispiel in der c’t 18/2008.

Stephan Hagen hat auf pm-blog.com bereits mehrfach über den Consideo Modeller berichtet:

Komplexe Systeme modellieren und simulieren: CONSIDEO MODELER

Erfahrungsbericht: Consideo Modeler

CONSIDEO Modeler Workshop 

Bei einer systemanalytischen Vorgehensweise und Modellierung geht es darum:

„…die entscheidenden Einflussfaktoren für eine konkrete Problemstellung zu identifizieren und danach Wechselwirkungen zwischen diesen Faktoren qualitativ oder quantitativ zu beschreiben. […] Auf abstrakt mathematischer Ebene liegen immer wieder die gleichen Problemstellungen vor.  Es müssen die wesentlichen Einflussfaktoren und deren Wechselwirkungen im Sinne eines Simulationsmodells erfasst und beschrieben werden. An jedem Faktor kann wirklich intuitiv mathematisch beschrieben werden, wie dieser auf von den anderen im Zeitverlauf abhängt. Aus einfachen Additions- und Multiplikationsformeln beispielsweise erhalten Sie am Ende anspruchsvolle Simulationskurven.
Diese Modelle bilden dann die Grundlagen für „Was-wäre-wenn?“-Szenarien […].“

(Quelle: Consideo Modeller Handbuch)

Bereits vor einer Weile wurde an dieser Stelle über ein neues PM-Portal von Computerwoche und CIO-Magazin hingewiesen: 10projects.

Die Idee, dort Projektsteckbriefe zu hinterlegen, Projekterfolg und Dienstleister standardisiert zu bewerten und fachliche Diskussionsforen zu schaffen, klingt zunächst vielversprechend, aber bereits damals stimmte mich die überschwengliche Bewertung der hinterlegte Projekte eher skeptisch. Hier wird eher der Eitelkeit von Projektleitern gehuldigt als der Objektivität in der Sache.

Aber man soll ja nicht vorschnell urteilen. Also Zeit noch einmal auf 10projects zurückzukehren. Hat sich mittlerweile alles zum Guten gewandelt?

Leider nein. Die Projektsteckbriefe sind noch immer Werbetexte. Die Bewertungen stammen i.d.R. von einem einzigen Projektmitarbeiter und sind bis auf eine einzige Ausnahme, die ich finden konnte, immer weitgehend positiv. In den Diskussionsforen  ist auch nicht gerade die Hölle los. Bei einem schnellen Scan war der jüngste Beitrag, den ich finden konnte von Anfang März, der Rest aus dem letzten Jahr.

Schade, aber 10projects kann man aufgrund mangelnder Akzeptanz wohl abhaken.

Heute erschienen in der neuen Ausgabe des Projektmagazins ist Teil 2 meines Artikels über Testmanagement in IT-Projekten. Während es in Teil 1 noch um die Grundlagen ging, beinhaltet Teil 2 vor allem eine Excel-Vorlage. Kommerzielle Test-Suiten sind als Test-Werkzeug häufig überdimensioniert, da ihr Leistungsumfang die Anforderungen vieler IT-Projekte übersteigt und ihre Nutzung meist nur rudimentär erfolgt. Die vorgestellte einfache Excel-Lösung kann der Anwender leicht an seine spezifischen Fragestellungen anpassen und weiterentwickeln.

Eberhard Huber von projekt(B)LOG hat jüngst einige Checklisten für das Projektmanagement zusammengestellt, die er jetzt noch einmal überlicksmäßig zusammenfasst und deren mögliche Verwendung mittels eines Mindmap visualisiert.

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.