Nicht nur für unsere Freunde vom PMCampHH entstand diese kleine Dokumentationsanleitung für das Wiki von openPM. (Einen Vorläufer in Englisch gab es schon mal für das PMCamp Barcelona.) Jetzt fehlen nur noch mehr Mitstreiter. Egal ob nur ein zusätzlicher Link, eine Grafik oder das Fotoprotokoll eine Barcamp-Session. Jeder geteilte Beitrag ist ein Geschenk für die Community! Also: mitmachen!

Immer wieder gerät man in Projektmanagement-Grundsatzdiskussionen, die letztlich auf grundlegenden Missverständnissen beruhen:

(1) Projektitis – Alles  wird zum Projekt

Natürlich kann man PM-Werkzeuge auch für Nicht-Projektmanagementaufgaben sinnvoll einsetzen, aber bitte mit Sinn und Verstand. Wenn alles – jeder Auftrag, jede Aufgabe – zum Projekt wird und einer vollständigen Projektsystematik unterworfen wird, dann ist der bürokratische Super-Gau vorprogrammiert.

(2) Falsch aufgesetzte Projekte

Wenn ich an einem Projekt beteiligt bin, heißt das noch lange nicht, dass ich für mich dafür ein eigenes Projekt aufsetzen muss. Letztlich gibt es nur ein Projekt und die Projektmananagement-Systematik sollte klar den Verantwortlichkeiten folgen.
Ein konkretes Beispiel: Als Berater in einem IT-Projekt stößt meine eigene Projektplanung an ihre Grenzen, wenn ich die Arbeit von Fachabteilung und IT-Servicemanagement mit plane, obwohl ich die dort anfallenden Aufgaben nicht aussteuern kann, sondern auf den Good-Will der Beteiligten angewiesen bin. Mache ich den Fehler trotzdem Termine für diese Zuarbeiten ohne das Commitment der Beteiligten auszuweisen, werde ich mich für jede Terminänderung in meiner Planung rechtfertigen müssen, ob ich sie zu verantworten habe oder nicht. Und die von mir ausgewiesenen Termine/Planungen könnnen möglicherweise bei anderen Beteiligten wiederum zu Fehlschlüssen führen, wenn sie sich auf diese nicht belastbaren Angaben verlassen. Werde ich möglicherweise von dritter Seite genötigt eine solche Planung auszuweisen (also eine Mischung aus (1) und (2)), dann liefere ich nicht nur inhaltlichen Unsinn, sondern bediene auch noch unnötige und irreführende Formalismen.

(3) Nicht aufgesetzte Projekte

Der dritte Fall sind Projekte, die nicht als solche behandelt werden. Wieder ein Beispiel: Die Entwicklung einer IT-Applikation ohne Projektstrukturen. Ohne definierte Verantwortlichkeiten sind Probleme vorprogrammiert. Auch wenn sich jeder der Beteiligten bemüht: Geteilte Verantwortung ist keine Verantwortung. Wenn jeder unkoordiniert seinen Beitrag leistet, besteht die Gefahr von Stückwerk. Die alte Geschichte von vielen Köchen und dem Brei.
Und bitte diese Forderung nach klaren Strukturen nicht als hierarchisches Modell missverstehen: Klare Verantwortlichkeiten gibt es auch im Agilen und in der Unternehmensdemokratie. Auch hier gibt es klare Rollen und Aufgabenverteilungen. Klare Strukturen statt Beliebigkeit!