PM-Werkzeuge müssen nicht immer IT-gestützt und fancy sein. Allzuleicht lassen wir uns von den Tools ablenken und vergessen die Inhalte. Visualisierungen mitten im Raum regen die Kommunikation an und sorgen u.a. für Transparenz, können aber auch die Kreativität anregen.

In seinem Blog über Software Project Management bekennt Pawel Brodzinski sich leidenschaftlich zum Einsatz von Wihteboards:

if I could name only one tool I’d be left with to manage a project it would be a whiteboard with a set of markers.

Und dass er nicht IT-afin wäre, kann man dem guten Pawel beim besten Willen nicht nachsagen!

Olesya Gileva wendet auf PM Hut konsequent Visualisierungstechniken für Projektmeetings an.

Das CIO-Magazin und natürlich auch schlossBlog berichteten schon im vergangenen Dezember über Peter Hinssen´s Thesen zur IT. Nun berichtet auch die Computerwoche.

Betrachtet man die Entwicklung vieler IT-Abteilungen kann man Peter Hinssen durchaus nachvollziehen, denn die IT(-Abteilungen) managen häufig nur noch sich selbst, die Fachabteilungen und die Dienstleister. Mitunter bilden sich Ketten von Managern an deren einem Ende das operative Business und am anderen Ende operative IT-Dienstleister hängt. Der Wasserkopf hat ein bedenkliches Ausmaß erreicht.

Heise online meldet, dass der IT-Anbieter Bull seine eigenen Arbeitsplätze von Microsoft Office auf das freie OpenOffice umstellt.

Freie Software wie das OpenOffice hat sich in den letzte Jahren gewaltig gemausert. Ohne Frage: dem Normalanwender reicht der Funktionsumfang vollkommen aus. Erst in den Tiefen stösst man gegenüber kommerziellen Konkurrenzprodukten auf Grenzen. Weitere Grenzen tun sich in der Integration weiterer Produkte, wie z.B. Sharepoint oder Project auf – aber wer das nicht braucht… Auch wenn OpenOffice Microsoft Dateiformate verarbeiten kann, ist für mich die Kompatibilität der Dateiformate noch ein Argument für die Konkurrenz aus Redmond. Gerade wer z.B. mit Kunden Dokumente austauschen will, wird hier keine Kompromisse eingehen, sofern andere Standards wie PDF nicht genutzt werden können.

Hinter dem Wechsel von Bull stecken übrigens nicht eine reine Kostenabwägung, sondern zu allererst ein taktisches Kalkül: Man will Kompetenz im OpenSource-Bereich unter Beweis stellen. Doch die Frage aus dem Titel (To buy or not to buy…) ist nicht die richtige Frage. Es geht nicht um kaufen oder nicht kaufen, sondern darum, ob die eigenen Anforderungen von einer Software zu einem angemessenen Preis adäquat erfüllt werden. Und zum Preis gehören nicht nur die reinen Lizenzkosten, sondern auch die Kosten für die Administration und Konfiguration.

Für viele „Normalanwender“ wird die Antwort lauten: naja, für mich tut es OpenOffice allemal, ein paar Poweruser bei Bull oder vielleicht auch Vertriebler, die auf den Austausch mit den Kunden angewiesen sind, werden hingegen mit einem weinenden Auge da stehen.

Und noch einmal Pawel Brodzinski, der sich mit einem Beitrag von Jennifer Bedell auf PMStudent zum Thema Testmanagement auseinander setzt: Testen kann auch ausufern, wenn der Scope des Projekts aus dem Auge verloren wird und weit über die ursprünglichen Projektauftrag hinaus getestet wird. Zurecht weist Pawel darafhin, dass die Erfüllung von Spezifikationen mitunter noch wenig über die tatsächliche Qualität des Ergebnisses aussagt. Auch wenn alle Anforderungen erfüllt sind, kann der Patient bereits tot sein. Der Test der Spec stelllt quasi den minimalen Testumfang dar,  aber um die Qualität sicherzustellen braucht es „mündige Tester“, die auch nach rechts und links schauen, aber mit Augenmaß, um nicht einfach den Projektauftrag beliebig zu erweitern und die Kosten aus dem Ruder laufen zu lassen.

Pawel Brodzinski bringt es auf den Punkt: Bei aller Methoden-Diskussion – letztlich zählt nur das Ergebnis und dessen Qualität, da sollte es keine Rolle spielen ob das mit agilen oder klassischen Methoden erreicht wurde. Auch die beste Methode ist bei fehlendem Qualitätsbewußtsein unzulänglich. Pfusch bleibt Pfusch!

Genau wie Stefan Hagen von PM-Blog (hier sein letzter Beitrag zum Thema Business Mapping), habe ich mich schon wiederholt als Fan von Mindmaps geoutet; sei es beim klassischen Brainstorming,  sei es bei der Ersterstellung eines Projektplans (Ein Mindmap lässt sich leicht auch als Projektstrukturplan interpretieren. Toolgestützt kann man dann den Plan per Drag-and-Drop beliebig in Form bringen.), als Moderations- oder Dokumentationstool, bei der Einarbeitung in neue Themengebiete,…

Auf der Seite Wikimindmap.org kann man nun basierend auf den Beiträgen der Wikipedia automatisch Mindmaps generieren und diese sogar lokal speichern. Allerdings nur im Freemind-Format. Ein Import in Mindmanager oder XMind (den von mir favorisierten Mindmapping-Tools) ist mir leider auf Anhieb nicht gelungen.

Klassenbester unter den mittlerweile zahlreichen Mindmapping-Programmen ist in meinen Augen immer noch der Mindmanager von Mindjet, insbesondere aufgrund seiner Office-Integration, angefangen von Word, Excel bis hin zu MS Project. Aus lizenzrechtlichen Gründen arbeite ich aber sporadisch auch mit der freien Software XMind.

Alle bisherigen Beiträge und Beispiele auf schlossBlog zum Thema Mindmapping finden Sie hier.

Gerne greife ich Peter Addors Kommentar zum vorangegangenen Beitrag auf:

Dass der Projektbegriff bei weitem nicht so eindeutig ist, wie wir es uns vielleicht wünschen würden, darin sind wir uns einig.

Die Begrenztheit der Mittel ist letztlich die Grundfrage jeglichen Wirtschaftens – sprich der Ökonomie. Sie ist nur ein notwendiges aber kein hinreichendes Kriterium für Projekte.

Aber vielleicht müssen wir uns auch dem Komplexitätsbegriff noch einmal nähern: Peter Addors Sichtweise von Komplexität kann ich nachvollziehen, wenn ich eine objektive Sicht auf ein System hätte. Diese Herangehensweise würde einer kybernetischen Tradition entsprechen. Nimmt man aber beispielsweise eine konstruktivistische Betrachtungsweise, sieht das Ganze wieder etwas anders aus. Betrachte ich ein System als meine subjektive Konstruktion eines Realitätsausschnitts, dann kann eine vermeintliche „Komplexitätsreduktion“ für meine persönliche Verhaltensweise durchaus sinnvoll und zielführend sein, denn meine persönlichen (auch geistigen) Ressourcen sind beschränkt (wie sich das anhört!). Die Vereinfachung des Modells verändert aber nicht die Realität, sondern lediglich meine Wahrnehmung. Das kann auch gefährlich sein, ist aber durchaus eine legitime Bewältigungsstrategie zum Umgang mit der Realität – zur Vermeidung von Überforderung.

Peter Addor würde wahrscheinlich argumentieren, dass wenn ich für viele Bäume als Metaebene den Begriff „Wald“ einführe, sich damit die Komplexität des Systems erhöht (es gibt eine zusätzliche Begriffebene). Für mich reduziert sich hingegen zunächst die Komplexität, da ich jetzt von Wald spreche und die einzelnen Bäume möglicherweise gar nicht mehr betrachte. Während er Gefahr läuft den Wald vor lauter Bäumen nicht mehr zu sehen, laufe ich hingegen Gefahr nur mehr von ganzen Wäldern zu schwadronieren, aber den einzelnen Baum nicht mehr zu sehen.

Ein Patentrezept, welche Sichtweise besser ist, gibt es nicht. Fallweise mag die eine oder die andere Vorgehensweise zielführend sein. In Projekten – in denen sich in der Regel der Lösungsweg nicht sofort abzeichnet – fehlt uns die Übersicht, wir sind also erschlagen vor lauter Bäumen. In dieser Situation kann es tendenziell hilfreich sein, die Komplexität zu reduzieren. Sobald wir Land gewonnen haben, können wir dann auch wieder auf die Detailebene der Bäume zurückkehren, denn auch wenn wir Wälder roden wollen, müssen wir einzelne Bäume fällen.

Noch bevor ich einen interessanten Beitrag von Peter Addor zum Thema Komplexität und Projekte hier aufgreifen konnte, hat der Kollege meinen Kommentar aufgegriffen und eine Diskussion beginnt sich zu entwickeln. Gemein ist uns beiden die systemtheoretische Betrachtungsweise mit einem Augenmerk auf Komplexität, aber wahrscheinlich trennt uns noch ein unterschiedlicher Projektbegriff:

(1) Der von Peter Addor verwendete Projektbegriff geht mir eindeutig zu weit, denn Projekte sind nicht nur durch ihre Einmaligkeit gekennzeichnet, sondern auch durch die Komplexität der Aufgabenstellung (upps, hier wird es rekusiv.), Begrenzung der Mittel, etc.. (Der inflationäre Gebrauch des Begriffs „Projekt“ ist wiederum ein anderes Kapitel.)
(2) Komplexität entsteht nicht zwingend aus Projekten, sondern aus Veränderung. Es gibt weit mehr Quellen der Veränderung als Projekte.
(3) Aber auch nicht jede Veränderung führt zwangsläufig zu einer Komplexitätssteigerung, sie kann genauso auch zu einer Systemvereinfachung, also zu einer Komplexitätsminderung führen.
(4) Typisch für Projekte ist der systematische Problemlösungsansatz: Der Mitteleinsatz wird systematisiert um aus 1.000.000 Bausteinen am Schluß 1 fertiges Haus zu erhalten. Ich sehe hier durchaus Möglichkeiten zu einer Komplexitätsreduzierung oder zumindest zu einem bewussten und zielgerichteten Umgang mit Komplexität.
(5) Die Illusion der Planbarkeit ist sicher ein Sündenfall des „ganz klassischen“ Projektmanagement, aber ein solches Planungsparadigma wird heute kaum mehr jemand streng aufrecht erhalten. Wie wir wissen ersetzt die Planung den Zufall durch den Irrtum, aber dennoch ist Planung sinnvoll. Selbst in agilen Ansätzen wie Scrum wird geplant! Dort allerdings nur in kleinen iterativen Schritten. Planung, vorausschauendes Denken gehört zu einer systematischen Problemlösung einfach dazu. Dass wir uns dabei in einem komplexen, dynamischen Umfeld bewegen und dem Rechnung tragen müssen, ist die große Herausforderung an das Projektmanagement.

PM-Definitionen und PJMB berichten über eine mögliche Annäherung von IPMA/GPM und PMI, die möglicherweise zu einer gegenseitigen Anerkennung der unterschiedlichen Zertifierungen führen könnte.