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.

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.

Das CIO-Magazin berichtet über die überarbeitete DIN-Norm zum Projektmanagement.

Andreas Heilwagen hat dankenswerterweise auf seinem Blog die Inhalte der überarbeiteten Norm zusammengefasst:

Ein Leser-Feedback bestätigt mich in meiner Einschätzung:

Wir setzen seit einiger Zeit zur Verbesserung der Klarheit und Entwicklung der Fachanforderungen ein Tool ein, das sich sehr bewährt. Das ist m.E.

erheblich wichtiger, als ein Testtool, von dem ich – auch nach langen Jahren – je nach SW (die ja heute hochgradig konfigurierbar ist und de facto strukturbildende Wirkungen für Unternehmen und alle damit verbundenen Org-Einheiten hat) nur wenig halte. Es ist nichts schlimmer, als wenn die Fachbereiche nach langwierigen Prozessen der Definition der Fachanforderungen irgendwann selbst nicht mehr wissen, wer was wann und warum angefordert hat und ob und wie diese Anforderung von wem in Absprache mit wem wann geändert worden ist – was ist dann getestet worden – und wie bekomme ich meine Migrationsaufträge? Dann kann ich mir das Testen im Grunde komplett sparen.

In der aktuellen Ausgabe des Projektmagazins (Abodienst) findet sich ein Beitrag zum Thema Testmanagement in IT-Projekten. Als Autor des Artikels kann ich die Lektüre natürlich nur empfehlen…

Im ersten Teil  des Beitrags werden die Grundzüge des Testmanagements und der Testorganisation anhand der immer wiederkehrenden gemeinsamen Fragen skizziert, die vor der Durchführung eines Tests zu beantworten sind:

1. Wann wird getestet?
2. Was wird getestet?
3. Wie wird getestet?
4. Wer testet?
5. Womit und wo wird getestet? 

Teil 2 des Beitrags mit einem ausführlichen Excel-Template ist derzeit in der Schlußredaktion.

Travis Anderson hat einen lesenswerten Beitrag über den Einsatz von Activity Based Costing im Projektmanagement (Englisch) verfasst. Die Kostenzuordnung auf Aktivitäten orientiert sich dabei an der Work Breakdown Structure (WBS).

So wohl überlegt die Ausführungen sein mögen, habe ich dennoch meine Bauchschmerzen mit dem Einsatz solcher high sophisticated Methoden im Projektmanagement: Natürlich braucht PM Kostenüberwachung und Kostenschätzungen, je deaillierter die Modelle hierfür sind, desto größer wird allerdings auch der bürokratisch/administrative Aufwand. Je größer dieser Aufwand, umso mehr entfernt sich die Sicht von der Projektrealität. Die Administration will mit Zahlen gefüttert werden, also bekommt sie Zahlen. Nach meiner persönlichen Erfahrung finden sich die vermeintlich ausgefeiltesten PM-Methoden meist dort im Einsatz, wo von Projekten im engeren Sinn gar nicht mehr gesprochen werden kann, wo es eher um regelmäßige Tasks oder Aufgaben geht. Ein dynamisches Projektumfeld braucht hingegen eine gewisse „Hemdsärmligkeit“.

Stefan Hagen kann es nicht lassen und setzt mal wieder Malik in Bezug zu Projektmanagement.

Bin da ganz auf seiner Seite, wie diverse Beiträge auf schlossBlog zeigen:
#99 Malik
#10 Noch einmal zurück zu Malik
#04 Management-Werkzeuge
#03 Was heißt schon Management?