Das Projektmagazin berichtet, dass die Bundesstelle für Informationstechnik (BIT) den neuen Standard V-Modell XT Bund veröffentlicht hat. Details und Download gibt es bei der BIT.

Craig Brown von Better Projects versucht Projektmanagement (PM) jemanden näher zu bringen, der sich bislang noch nicht mit PM  beschäftigt hat und greift zu einer visuellen „Zwiebel-Darstellung“.

Da sind wir gleich bei den grundlegenden Fragen: Handelt es sich überhaupt um ein Projekt? Hier hilft Stefan Hagen weiter…

Bei der Arbeit mit Listen stellen sich immer wieder die gleichen Grundfragen, deren Beantwortung aber entscheidend dafür ist, ob eine Liste nutzbringend eingesetzt wird oder ob sie in einen Dornröschenschlaf versinkt ohne jemals wieder aufzuwachen oder noch schlimmer: Die Arbeit mit falschen oder veralteten Informationen behindert.

Verantwortlichkeit

Für jeden Punkt einer Liste sollte die Verantwortlichkeit eindeutig definiert sein. Streng nach dem Highlander-Prinzip („Es kann nur einen geben!“) gehört zu jedem Punkt genau ein Name. Das schließt nicht aus, das noch mehr Personen an dem Punkt beteiligt sind (diese können auch z.B. in einem Kommentarfeld dokumentiert werden) , aber dieser eine ist es, der auch für die Einbindung aller weiteren Beteiligten, die Bearbeitung des Punktes und auch die Rückmeldung verantwortlich ist. Geteilte Verantwortung ist keine Verantwortung, dann kann sich jeder fälschlich auf den anderen verlassen.

Verantwortung darf auch nicht falsch verstanden werden indem in der Hierarchie nach oben deligiert wird. Klar ist der Chef oder der Projektleiter irgendwie auch für alles verantwortlich, aber er hat bestimmt nicht jeden Punkt zu jeder Zeit im Blick und ist auch darüber auskunftsfähig.

Wenn Sie ehrliche Rückmeldungen und nicht belogen werden wollen, dann dürfen Sie auch Verantwortung nicht mit Schuld verwechseln. Es geht nicht m Sanktionierung, sondern um Problemlösung und dabei hilft es rechtzeitig über den aktuellen Stand im Bilde zu sein.

Granularität

Die einzelnen Punkte sollten in einer angemessenen Granularität erfasst sein. Angemessen heißt hier häufig relativ fein aufgedröselt. Mehrere kleine Punkte sind häufig besser als ein großer, denn ein kleiner Punkt kann auch schneller wieder abgeschlossen werden, weil er besser abgegrenzt werden kann. Zu weit gefasste Punkte haben ein Beharrungsvermögen, können häufig noch nicht abgeschlossen werden, weil irgendeine Kleinigkeit noch offen ist und tragen so zu einer Unübersichtlichkeit in unserer Liste bei.  Ein Indiz für zu weit gefasste Punkte sind überquellende Kommentarfelder, die den Verlauf dokumentieren sollen. Lieber einen Punkt für jede Aktion und für Folgeaktivitäten neue Punkte (ggf. mit Referenz auf die Vorgänger).

Detailliertheit

Wie detailliert Sie einen Punkt in einer Liste dokumentieren ist Geschmackssache, aber der Informationsgehalt sollte doch soweit vorhanden sein, dass auch ein Dritter diesen Punkt noch nahvollziehen kann.

Verlässlichkeit

Mit der eindeutigen Definiton der Verantwortlichkeit ist ein Schritt getan, aber dafür, dass man sich auf die Inhalte einer Liste verlassen kann, braucht es noch mehr: eine entsprechende Pflegekultur und –disziplin, de dafür sorgt, dass die Liste auch aktuell ist und eine entsprechende Datenqualität aufweist. Praktisch funktioniert dies meist nur mit einem „Kümmerer“, der sich einer Liste annimmt und ggf. Statusaktualisierungen und Feedback „eintreibt“. Aber Achtung es geht hier nicht um ein Strafkommando! Wir unterstellen niemanden, dass er aus Boshaftigkeit unsere Liste torpediert, aber zur „Hygiene“ gehört es auch, dass unsere Liste regelmäßig aufgeräumt und gesäubert wird.

Wenn der von mir sehr geschätzte Eberhard Huber etwas zu sagen hat, dann lohnt sich das zuhören. Aktuell zum Thema Projekterfolg. Seine Aussagen sind empirisch untermauert und sein Fazit, wann ein Projekt als erfolgreich angesehen werden kann, mag überraschen:

„Das hängt von der Zufriedenheit der Stakeholder ab.“

Ich kann diese Aussage nur unterstreichen und meine Weihnachtsanekdote von vergangenem Jahr zur Bestätigung herauskramen…

Wir kennen sie alle: die Offene Punkte Liste (OPL), Liste offener Punkte (LOP), Action Item Liste oder wie auch immer das Kind heißen soll. Egal ob sie an an einem Whiteboard im Teamraum geführt wird, toolgestützt, als Sharepoint-Liste, …

Ihr Einsatzfeld ist weit: Von der reinen Aufgabenüberwachung bis hin zum Protokollersatz.

Wie immer kann man streiten, ob es sinnvoll ist eine solche Liste in Excel zu führen. Excel ist nicht unbedingt ein Collaboration-Tool, aber für den ad hoc-Einsatz durchaus ok. Außerdem kommt es viel mehr auf die Inhalte und deren Pflege an. Das beste Tool mit lausiger Datenqualität ist weniger wert als ein gut gepflegter Schmierzettel.

Für den Hausgebrauch ist so ein kleines Template entstanden. Es verzichtet bewusst auf den Einsatz von Makros (ja, dann könnte man vieles noch bequemer machen, aber die Sicherheitseinstellungen haben bei der Nutzung durch mehrere Nutzer durchaus ihre Tücken). Verschiedene Felder sind mit Gültigkeitsprüfungen hinterlegt, um die Datenqualität zu verbessern. Die entsprechenden Stammdaten finden sich in einem eigenen Reiter. Ein Autofilter, der die erledigten Punkte ausblendet, sorgt ggf. auch schnell wieder für Übersicht – selbst in einer größeren Liste. Natürlich werden Sie nicht alle Spalten brauchen (dann blenden Sie sie doch einfach aus) oder andere (tun Sie sich keinen Zwang an und benennen Sie sie um). Der letzte Änderer und das Änderungsdatum wird nicht automatisch gepflegt (da bräuchten wir wieder Makros), dafür erfolgt die Zeilennummerierung automatisch (was es uns aber wieder verbietet Zeilen zu löschen, weil dann die IDs nicht mehr eindeutig wären – also überflüssige Zeilen deshalb als geschlossen markieren und entsprechend kommentieren). Das Template nutzt das Tabellen-Konzept von Excel 2007. Die runterkonvertierte Version für 2003 funktioniert ebenso. Statt der Tabellen kommen Listen zum Einsatz und die Datei ist nicht ganz so hübsch durchformatiert, aber ebenfalls voll einsatzfähig.

Fehlt nur noch die Link auf die Templates:

• Offene Punkte Liste (Template) für Excel 2007 (falls Ihr Rechner die Datei als Zip-Datei erkennt, einfach die Datei mit der Endung .xlsx speichern. Dies ist eine Tücke des neuen Excel-Formats, das letztlich ein verkapptes Zip-Format ist.)
• Offene Punkte Liste (Template) für Excel 2003

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.

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!

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.