Vor kurzem haben wir in unserem Webinar "Die 7 Todsünden des Projektmanagements" von Justin Rowe, Practice Director bei unserem Beratungspartner Lewis Fowler, erfahren. In seiner Präsentation sprach Justin über die Sünden des Projektmanagements und darüber, wie man sie erkennt und korrigiert. Dies führte dazu, dass sich die Teilnehmer rege an den Fragen beteiligten, von denen viele sehr informativ und relevant waren. Hier sind die Antworten auf die wichtigsten Fragen, die eingegangen sind.
- Sehen Sie, dass PPM-Gruppen die Bedeutung der Nutzung bestehender Domänenmuster und -strukturen für die Verwendung und Wiederverwendung im Unternehmen betonen?
[Ich bin der Meinung, dass dies sowohl aus der Perspektive des Projekt- als auch des Portfoliomanagements immer gefördert werden sollte. Während des gesamten Projektlebenszyklus muss eine Kultur des kontinuierlichen Lernens und Entdeckens betont werden, da Teammitglieder mit unterschiedlich langer Betriebszugehörigkeit ihr Fachwissen in die Projekte einbringen können, während diese durchgeführt werden. Auch in dieser Situation ist die Anwendung von Lessons Learned entscheidend, um Veränderungen und Schwankungen im Geschäft zu erfassen, insbesondere auf der Ebene der Geschäftseinheiten. Da die Projektanforderungen laufend erfasst und priorisiert werden, ist die Einbettung von Fachwissen und die Struktur dessen, was das Endprodukt oder die Lösung des Projekts sein soll, eine wertvolle Information, die in den Projektentscheidungsprozess einbezogen werden sollte.
Aus der Perspektive der Verwaltung des Projektportfolios hängt dies auch davon ab, in welche Richtung sich das Portfolio im Hinblick auf die Strategie des Unternehmens und die Stakeholder, denen die Projekte dienen, entwickelt. Fachwissen muss auf der strategischen Ebene des Unternehmens gesammelt, kommuniziert und genutzt werden. Dabei wird ein ausgewogener Ansatz der Portfolio-Governance angewandt, während das Projekt- und Portfoliosteam in die Lage versetzt wird, äußerst effektiv und effizient zu arbeiten. Wie ich bereits während des Webinars erwähnt habe, kann die Einbindung des PPM-Teams in den Kundenstamm sowie in die Bereiche der Stakeholder die Fachkompetenz erhöhen, um sicherzustellen, dass sie sich auf die erwarteten Projektergebnisse konzentrieren und gleichzeitig alle Bereiche des Projekts (Umfang, Zeitplan, Budget, Risiko usw.) verwalten. Auf diese Weise erhält das PPM-Team einen zusätzlichen Einblick in den Status seines Projekts und kann gleichzeitig mehr Daten quantitativ in seinem PPM-Tool erfassen.
- Wo ordnet sich ein Programmmanagementbüro in die Hierarchie des Portfolio-/Projektmanagementbüros ein? Mein Unternehmen möchte die PMOs der einzelnen Abteilungen vereinheitlichen, Richtlinien und Governance festlegen usw.
Meiner Erfahrung nach hängt die Einrichtung eines Programmverwaltungsbüros von einigen Umständen ab, aber immer von der/den Situation(en) selbst. Zunächst einmal hat die Entscheidung, ein formelles Program Management Office einzurichten, mit mehreren, eher strategischen Faktoren zu tun. Dazu gehören die Größe und Komplexität der Projekte im Portfolio, die dafür erforderliche Governance-Struktur und die finanzielle Einbindung in die Organisation. Die zunehmende Komplexität der Anzahl der Projekte und deren Auswirkungen auf die Finanzplanung und -ausführung des Unternehmens können als Grundlage für die Entscheidung dienen, ob ein Programm mit einem Program Management Office eingerichtet werden sollte. Bei der Durchführung von Projekten werden die einzelnen Budgets innerhalb jedes Projekts verwaltet, wobei der Gesamtdollarbetrag beispielsweise im Bereich von Hunderttausenden liegen kann. Bei einem Programm mit mehreren Projekten, die strategisch miteinander verbunden und auf die Entwicklung eines größeren Produkts ausgerichtet sind, kann der Betrag in die Hunderte von Millionen gehen. Wenn es einen erhöhten Bedarf an Struktur und Governance innerhalb des Projektportfolios gibt, könnte dies auch als Input für das Potenzial eines Program Management Office genutzt werden. Es gibt noch viele andere Ereignisse, die stattfinden müssten, um den wahren Bedarf an einem Program Management Office zu ermitteln. Aber hier sind ein paar Fragen, über die Sie nachdenken sollten...
- Gibt es mehrere Projekte, die nicht unbedingt einen ähnlichen Umfang haben, aber die Entwicklung eines Gesamtprodukts oder einer Lösung unterstützen?
- Gibt es mehrere Projekte mit Budgets, die steuerlich miteinander verbunden sind und zur Entwicklung desselben Produkts oder derselben Lösung führen?
- Müssen mehrere Projekte verwaltet werden, die eng miteinander verknüpft sind und einen ähnlichen Nutzen haben, der auf ein strategisches Ziel und/oder eine strategische Zielsetzung ausgerichtet ist?
- Besteht die Notwendigkeit, mehrere Projekte auf strategischer Ebene zu steuern, bei denen Ressourcen, Abhängigkeiten und andere projektbezogene Variablen eng aufeinander abgestimmt sind?
Die Beantwortung einiger dieser Fragen könnte einen ersten Hinweis auf die mögliche Notwendigkeit der Einrichtung von Programmen und eines Program Management Office geben. Auch der Standard For Program Management, Third Edition von PMI ist ein guter Referenzpunkt, der Ihnen einen Einblick in Ihre Frage geben kann.
- Gibt es PMOs, die Kanban-Tools zur Planung der Entwicklungsarbeit einsetzen (z. B. Iterationen und Scrums)?
Bei der Durchführung von Entwicklungsprojekten - vorausgesetzt, diese Frage zielt auf die Softwareentwicklung ab - eignet sich der Einsatz von Kanban hervorragend, um den Fortschritt zu visualisieren und zu erkennen, wo Probleme auftreten könnten. Durch die kontinuierliche Agilität, die dieser Methode innewohnt, kann Kanban auch auf PMOs angewendet werden, unabhängig davon, ob sie eine IT-Funktion unterstützen oder gar nichts mit der IT zu tun haben. Bei Kanban liegt der Schwerpunkt auf dem Verständnis und der Visualisierung von Arbeitsabläufen, der Geschwindigkeit, mit der Aufgaben ausgeführt werden, und der Fähigkeit, Probleme zu erkennen, für die sofort Lösungen gefunden werden, um kontinuierliches Lernen zu unterstützen. Darüber hinaus kann das Team Work-In-Progress-Limits anwenden, bei denen die Kapazität der Aufgaben, die eine Person ausführen kann, begrenzt wird, um die kontinuierliche Bereitstellung von Software zu ermöglichen.
Im Hinblick auf die Planung wird die Anwendung von Erkenntnissen aus Kapazitätsbeschränkungen früherer Projekte oder Iterationen innerhalb des aktuellen Projekts die Fähigkeit der Planung unterstützen, agil zu bleiben, ohne den Projektfortschritt zu behindern. Die Anwendung von Scrum-Methoden wie z.B. Sprints (feste Zeiträume, z.B. 2 Wochen) mit Kanban kann auch genutzt werden, um Metriken zu Leistung und Geschwindigkeit zu definieren, aber Zykluszeiten innerhalb bestimmter Aufgaben, die definierte Inputs zu Outputs haben. Die Flexibilität und der Einsatz beider Methoden sollte in Abhängigkeit von der Entwicklungsumgebung und der Situation, in der das Entwicklungsteam am besten arbeiten kann, festgelegt werden.
