Mit Portfolio- und Projektmanagement verhält es sich in etwa wie mit Effektivität und Effizienz:

Während das Portfoliomanagement dafür sorgt , dass wir die richtigen Dinge tun, also effektiv handeln, wird im Projektmanagement darauf geachtet , dass wir die Dinge richitig, also effizient machen.

Unschwer zu erkennen: Wir brauchen beides – Effizienz und Effektivität!

Kennen Sie das Phänomen, das Grossprojekte sich verselbständigen und ein Eigenleben entwickeln? Sich willkürlich von ihrem Projektauftrag entfernen oder im anderen Fall an ihm Festhalten, obwohl die Voraussetzungen dafür längst nicht mehr gegeben sind?

Während im vorangegangenen Beitrag das Autopoiesis-Konzept genutzt wurde, um aufzuzeigen, wie das Zulassen von Selbstorganisation zum Projekterfolg beitragen kann, erklärt uns die gleiche Theorie hier, wie es zu solchen Auswüchsen kommen kann, wie ein Staat im Staat entsteht.

Was heißt dies wiederum für die Projektarbeit?

Klar brauchen wir Selbstorgansiation, aber wir brauchen auch Grenzen. Sozusagen Selbsthygiene für unser soziales System. Auch wenn wir Freiräume für die Selbstorganistion sicherstellen müssen, müssen wir Auftrag und den Weg zum Ziel regelmäßig hinterfragen und verfolgen. Unsere Projektkultur benötigt nicht nur Selbstorganisation, sondern auch Selbstreinigung.

Abseits der bekannten Definitionen von Projekten (siehe auch Wikipedia), lassen sich Projekte auch als soziale Systeme interpretieren. Projekte können als ein Organisationsform sozialer Systeme für komplexe Aufgabenstellungen verstanden werden.

Einige vorangegangene Beiträge auf schlossbBlog haben sich bereits mit dem Thema Projektplanung und insbesondere den Grenzen der Planung beschäftigt.

Hier wird die Interpretation von Projekten als sozialen Systemen wieder interessant:

In der Theorie sozialer Systeme gibt es das Konzept der Autopoiesis. Autopoiesis (Begriffserklärung in Wikipedia) beschreibt die Selbstorganisation sozialer Systeme. In der täglichen Projektarbeit stellt sich die Frage, wie sich solche Selbstorganisationsmechanismen gezielt nutzen lassen. Die Antwort liegt auf der Hand: in der Schaffung einer entsprechenden Projektkultur, die die erforderlichen Freiräume zur Selbstorganisation sicherstellt. Das heißt z.B. für die Planung eines komplexen Projekts, dass diese nicht auf den Level von mehreren Tausend Tasks oder mehr heruntergebrochen werden muss, sofern die Selbstorganisation auf diesen Ebenen gewährleistet ist. Ein Planungsmonster von tausenden Zeilen ist nicht mehr aktuell pflegbar und ein solches Projekt wahrscheinlich mehr tot als lebendig.

Die Forderung: „Selbstorganisation statt Planung“ ist zugegebenermaßen ketzerisch und so nicht haltbar. Auch kleinere Teileinheiten können und müssen ihre Tasks sehr wohl planen. Dies muss aber nicht unbedingt in einer zentralen Gesamtplanung geschehen. Eine solche Planung muss nicht unbedingt deren formalen Anforderungen genügen, kann mitunter auch kurzfristig erfolgen und ist weitaus flexibler.

In der klassischen Projektplanung werden die Beziehungen zwischen einzelnen Tasks in Form von Abhängigkeiten abgebildet. Für den Projekterfolg entscheidend ist aber weniger deren formale Abbildung als das entsprechende Bewußtsein der Beteiligten und die Berücksichtigung im Handeln. Anderenfalls erklären Abhängigkeiten nur die Gründe für das Scheitern. Ein solches Bewußtsein, das Ansprechen und Aufgreifen der „richtigen Themen“ ist der Schlüssel zum Projekterfolg und führt uns wieder zurück zur Theorie sozialer System, insbesondere zu den Arbeiten von Niklas Luhmann (Wikipedia), der soziale Systeme über die Kommunikation definiert. In diesem Sinne liegt in der Kommunikation der Schlüssel zum Projekterfolg (aber auch der Schlüssel für eine erfolgreiche Planung 🙂 ).

Hier eine Studie zum Scheitern von Großprojekten, zitiert auf heise-online:
http://www.heise.de/newsticker/meldung/101626

Alexander Volland ist mir seinerseits bei Wikipedia über den Weg gelaufen. Gemeinsam haben wir uns um das Wikiprojelkt Projektmanagement gekümmert – und mittlerweile etwas frustriert auch wieder zurückgezogen. Er betreibt eine eigene Projektmanagement-Plattform unter http://www.pmqs.de

. Alexander bastelt auch an einem ehrgeizigen WBT zum Thema Projektmanagement.

Bei weniger technischen Themen, wie z.B. dem Projektmanagement wird die Luft in den Internet-Foren deutlich dünner, als in IT-nahen Themengebieten.

Selbst in Fachpublikationen wie dem Projektmagazin finden sich nur sehr rar Beiträge, auch wenn hier im Laufe der Zeit die Struktur gewachsen ist:

Und selbst bei der GPM wird unter dem Stichwort Diskussionsforum „gemogelt“ oder besser gegoogelt, denn dahinter verbirgt sich kein Forum, sondern eine vorkonfigurierte Google-Suche:

Vielversprechender sind da mitunter die Gruppen der Online-Community/des Abodienstes XING, insbesondere die Gruppe „Projekte oder das Management von Vorhaben“:

Darüber hinaus gibt es aber auch noch eine ganze Reihe von Business-relevanten Gruppen:

Und auch eine eigene GPM-Community findet sich hier:

Nicht Web 2.0, aber besten user generated content liefert nach wie vor das Usenet (mittlerweile über goolge groups erreichbar). Hier finden sich auch zwei für Nutzer von Microsoft Project interessante Gruppen, die weitaus mehr bieten als nur frequently asked questions:
http://groups.google.de/group/microsoft.public.de.project (deutsch)

und

http://groups.google.de/group/microsoft.public.project (englisch)

Zwar können die Foren nicht ganz mit Foren zu anderen Office Produkten mithalten, aber dies sind noch immer die besten Beiträge zu MS Project.

Die morderate Beteiligung könnte als Indiz für die vielfach noch oberflächliche Nutzung von MS Project sein.

Was bitte ist ein Projektmanager? Oder besser: Was ist der Unterschied zwischen einem Projektmanager und einem Projektleiter?

Im Englischen besteht kein Unterschied. Der Project Manager bezeichnet nichts anderes als den Projektleiter.

Im Deutschen ist der Projektmanager hingegen eher als Stabsstelle, die den Projektleiter unterstützt „sein Projekt zu managen“ zu verstehen. Im englischsprachigen Raum würde man eine solche Aufgabe in einem PMO (Project Management Office) angesiedelt sehen. Je nach Ausprägung kann ein PMO aber auch eine reine Sekretariatsfunktion wahrnehmen, während der gute, deutsche Projektmanager als Projektmanagement-Experte zu sehen ist, der den Projektleiter entlastet und ihm Freiräume zur inhaltlichen Mitarbeit im Projekt oder zum „Verkaufen“ des Projekts gegenüber den Stakeholdern verschafft.

Als Schlusspunkt dieser Reihe mit Beiträgen zur Planung noch ein Thesenkatalog über die Grenzen der Planung:

Die Abbildung von Abhängigkeiten in der Projektplanung ist ein zweiseitiges Schwert. Einerseits ist die Kenntnis von Abhängigkeiten erforderlich, um Auswirkungen des Verlaufs von Arbeitspaketen aufeinander abschätzen, sowie Termine und Kosten automatisch bei Planänderungen aktualisieren zu können, auf der anderen Seite sprengt die damit verbundene Komplexität regelmäßig die Projektplanung.
Die Abbildung von generischen Abhängigkeiten – meist auf einem sehr hohen Level – ist zwar noch einfach, ihre Aussagekraft hingegen tendiert gegen Null und grenzt an Trivialität, ja, sie ist mitunter sogar falsch. Einerseits erscheint es logisch, dass die Konzeption abgeschlossen sein muss, bevor eine Realisierung beginnen kann, diese muss wiederum abgeschlossen sein, bevor ein Test erfolgen kann, etc., aber die Wahrheit sieht anders aus, zumindest in einer schnelllebigen Zeit wie der unseren, in der viele Aktivitäten parallelisiert werden. Natürlich muss die Konzeption nicht vollständig abgeschlossen sein, bevor ene Realisierung beginnenen kann. Zunächst sind nur gewisse Eckpunkte erforderlich, die parallel zur Realisierung noch um die fehlenden Details zu ergänzen sind, usw., d.h. aber auch dass eine Pflege von Abhängigkeiten in einer Planung nur dann sinnvoll möglich ist, wenn man die Planung bis auf die kleinste erforderliche Planungeinheit herunterbricht. Dies kann mitunter eine Planung unbeherrschbar machen. Die Planungstiefe und die Detaillierung wird schnell zum Problem.
Für komplexe Planung gab mir einst ein auf MS Project spezialisiertes deutsches Systemhaus mit auf den Weg, dass sie ihren Kunden in komplexen Problemen von der Pflege von Vorgänger-/Nachfolgerbeziehungen (und in solchen werden Abhängigkeiten abgebildet) in den dafür vorgesehenen Feldern abraten würden. Wenn sie diese Beziehungen abbilden, dann würden sie Textfelder hierfür missbrauchen, damit die Plandatei noch pflegbar bleibt.
Natürlich ist es trotzdem sinnvoll, ja auch erforderlich sich mit Abhängigkeiten auseinanderzusetzen. Entscheidend ist, dass in einem Projekt alle voneinander abhängigen Parteien miteinander reden und sich ihrer Abhängigkeiten bewußt sind. Die Abbildung in der Planung ist hingegen eher ein Formalie und darf nur soweit gehen, dass sie den Rahmen der Planung nicht sprengt. Hierfür gibt es aber auch alternative Konzepte, wie z.B. eine DEBI-Matrix, in der je Arbeitspaket definiert wird welche Partei für die Durchführung zuständig ist, wer ein Paket zu verantwortden und darüber zu Entscheiden hat, wer lediglich Beratend mitwirkt und wer Informiert werden sollte.