AllgemeinProjektmanagement

Integriertes Projektmanagement – agiles und klassisches Projektmanagement sinnvoll kombinieren

Bereits seit einiger Zeit beschäftigt mich die Frage, was soll soviel besser sein am „Agile Projektmanagement“?  Auslöser für diesen Blog war ein gewisses Erstaunen, wie vermeintliche „Experten“ mit Konzepten und Begriffen um sich werfen, ohne ausreichend zu hinterfragen, was HINTER den ganzen Begriffen steht? Oder betreiben wir nur „Bullshit Bingo“ und Berater-Bla-Bla, was uns inhaltlich keinen Millimeter weiter bringt? Ich befürchte, dass letzteres häufig der Fall ist.

Hat das klassische Projektmanagement ausgedient? Wird sich agiles Projektmanagement durchsetzen? Wir gehen von einer Kombination beider Ansätze aus. Bei gewissen Projektarten werden klassische Projektmanagement-Ansätze weiterhin dominierend sein – z.B. in bei Immobilien-Projekten, Bauindustrie. Andererseit werden bei IT-Projekten mit einem hohen Komplexitäts- und Innovationsanteil die agilen Projektmanagement-Ansätze überwiegen. Wir sollten versuchen, klassische und agile Vorgehensweisen und Methoden sinnvoll miteinander zu kombinieren. Wir brauchen ein integriertes Verständnis im Management – auch im Projektmanagement.

.

Erfolgs- und Leistungsbeurteilung von klassischen Projektmanagement

Agiles Projektmanagement verfolgt das Ziel die Agilität (flink; beweglich) im Projektmanagement zu erhöhen. Es gilt das „klassische“ Projektmanagement flexibler und schlanker zu machen. Das agile Projektmanagement entstand als Gegenbewegung zu den klassischen methoden- und prozessorientierten Projektmanagementansätzen, die in der Praxis, trotz hohen Aufwandes, nur ungenügende Resultate erziehlen konnten. Für Rückschlüsse über die Leistungsfähigkeit von IT-Projektmanagement wird häufig die Langzeitstudie über den Erfolg- und Misserfolg in IT-Projekten der Chaos Report der Standisch Group zitiert.

Die untersuchten Projekte werden bei dieser Untersuchung in drei Gruppen aufgeteilt:

  1. Typ – Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen.
  2. Typ – Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht.
  3. Typ – Projekt nicht erfolgreich: Das Projekt wurde abgebrochen.

Für diese drei Typen ergab sich im Jahr 2015 eine Verteilung von

  • Typ 1: 29 %
  • Typ 2: 52 %
  • Typ 3: 19 %

Seit dem Start der Untersuchungen im Jahre 1994 sind sicher Verbesserungen erkennbar. Durchbrüche blieben, trotz Schulungen und Optimierung der Projektprozesse und der Werkzeuge aber aus.
Die festgestellten Haupterfolgsfaktoren für Projektmanagement sind:

  1. Aktive Einbindung der Endbenutzer
  2. Unterstützung durch das obere Management
  3. Klare Anforderungen

Die Hauptpunkte, die zum Scheitern der Projekte führen sind:

  1. Fehlende Zuarbeit durch Benutzer
  2. Unvollständige/unklare Anforderungen
  3. Häufige Anforderungsänderungen

 

Die verkürzte These beim Agilen Projektmanagement (APM) lautet: Das klassiche Projektmanagement hat versagt. Seit Jahren gibt es nur geringfügige Verbesserung im Durchsatz und Verkürzung der Durchlaufzeit. Agile Ansätze im Projektmanasgement sollen zur Verbesserung beitragen. Zum Teil stimmt das auch, daher ist der personen- und kommunikationszentrierte Ansatz im den Agilen Methoden durchaus zu begrüßen.

Mit der Änderung des PM-Ansatzes alleine ist es aber aus unserer Erfahrung nicht getan. In Unternehmen führen zu viele Ideen zu einer Vielzahl an Vorhaben bei zu wenigen Ressourcen = zu viel Work-In-Progress. Dazu kommt häufig eine fehlende oder ineffektive Projektbeurteilung, -auswahl und -steuerung, keine Konzentration aufs Wesentliche, Verschwendung von Managementaufmerksamkeit, keine oder zu wenig Selbststeuerung. Die Folgen sind häufiges Zuweisen von Schlüsselressourcen zu mehreren, parallel geführten Projekten und die damit verbundenen „Switching“-Verluste. Das Ergebnis: Engpässe bei Projekten, Verzögerungen, erhöhte Stillstandszeiten und schleppendes Vorankommen bei den Lieferergebnissen – also vorprogrammierte Unzufriedenheit. Agiles Projektmanagement soll’s richten!

.

Was heißt „agil“ im Kontext von Projekten?

Agiles Projektmanagement als Begriff entstand in Anlehnung an eine Bewegung zur agilen Software-Entwicklung mit dem Ziel, sich mehr auf die zu erreichenden Ergebnisse zu fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung einzugehen. Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen. Diese Kritik lässt sich gleichermaßen auch allgemein auf Projekte/Projektmanagement übertragen.

Agile Projektarbeit ist gekennzeichnet von iterativem Vorgehen und Orientierung an agilen Werten, wie sie z.B. im Agilen Manifest beschrieben sind. Hierbei werden häufig Ideen z.B. aus dem Lean Management oder Kanban aufgegriffen.

„Agile is a collective term used to refer to project methods, in which requirements and solutions evolve through collaboration between self-organising, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.“

 

„Traditionelles oder klassisches Projektmanagement“ bezeichnet Projektmanagementsysteme, bei denen der Projektablauf so gesteuert wird, dass die Abweichungen hinsichtlich Kosten, Zeit und Umfang vom anfänglich erstellten Plan minimal sind. Charakteristisch für klassisches Projektmanagement ist die durch Meilensteine / Gates getrennte Abfolge der Projektphasen Initiierung, Planung, Überwachung und Steuerung sowie Abschluss.

„Agiles Projektmanagement“ bezeichnet Vorgehensweisen, bei denen das Projektteam über hohe Toleranzen bezüglich Qualität, Umfang, Zeit und Kosten verfügt und eine sehr hohe Mitwirkung des Auftraggebers bei der Erstellung des Werks erforderlich ist. Charakteristisch für Agiles Projektmanagement ist die Fokussierung auf das zu liefernde Werk und die Akzeptanz durch die Anwender. Hingegen werden geschäftliche Anforderungen, wie z.B. die Termintreue, Kostentreue oder Erfüllung eines spezifizierten Leistungsumfangs weniger oder nicht berücksichtigt.

Aus unserer Sicht können die „Value Statememts des APM“ für das klassische PM ebenfalls übernommen und angewendet werden:

  1. Individuals and interactions over processes and tools. –> Mehr gemeinsame Zeit für Kommunikation und Interaktion einplanen.
  2. Working solutions over comprehensive documentation. –> Soviel Dokumentation wie notwendig und nicht so viel wie möglich.
  3. Stakeholder collaboration over contract negotiation. –> Teams, Leistungsträgerentwicklung, gemeinsame Projekträume, Vertrauen.
  4. Responding to change over following a plan. –> Aus neuen Erkenntnissen lernen und zeitnahe Erfolgs-Anpassungen.

Im Zentrum agiler PM Ansätze steht die Annahme, dass komplexe Projekte nicht vollständig geplant werden können. Vielmehr entstehen während eines gesamten Projekts neue Erkenntnisse, die in das Management und die Abwicklung einfließen sollten. Die anfangs große „Wolke“, was das Ziel des Projekts sein soll, wird immer kleiner – der Nebel verzieht sich. Eine einfache Darstellungen, warum agile Vorgehensweisen in Projekten zweckmässig sind, stammt aus dem Buch „APM – Agiles Projektmanagement“ von Bernd Oestereich und Christian Weiss:

Schrittweise Zielklärung mit der Wolken-Metapher- Quelle = Oesterreich/Weiss

.

Dies heißt aber keineswegs, dass in agilen Projekten nicht geplant wird. Auch im APM wird versucht, von Beginn an möglichst klare Ziele, Rahmenbedingungen und Liefergegenstände zu definieren. Allerdings soll bürokratische, starre und unrealistische Planung so weit wie möglich vermieden werden. An ihre Stelle treten intensive, kontinuierliche Kommunikation zwischen ALLEN Beteiligten und das Prinzip, das „große“ Projektergebnis in einzelne, funktionsfähige Zwischenergebnisse zu unterteilen.

Im PM2 Project Managemenat Ansatz sind 12 Agile Principlen formuliert – diese lassen sich aus unserer Sicht auch für das klassische PM anwenden:

  1. Create teams with motivated individuals. Give them the environment and support they need to self-organise, and trust them to get the job done.
  2. Business people and project team must work together throughout the project
  3. The most efficient and effective method of communication is face-to-face conversation.
  4. Deliver value frequently through working solutions.
  5. The highest priority is to satisfy the client through early and continuous delivery of valuable solutions.
  6. Requirement changes are welcome, even late in the solution delivery life cycle.
  7. The primary measure of progress is the usefulness of what has been delivered.
  8. Continuous attention on quality.
  9. Simplicity – the art of maximising the amount of work not done — is essential.
  10. At regular intervals, the team reflects on how to improve, then tunes and adjusts its behaviour accordingly.
  11. Agile processes promote sustainable development. Project stakeholders should be able to maintain a constant working pace indefinitely.
  12. Agile practices should be enterprise-aware, taking into consideration organisational governance requirements, enterprise architecture, and interoperability. Agile teams should be able to collaborate effectively with teams and stakeholders following alternative approaches.

.

Erweiterung der klassischen Projektmanagement-Ansätze mit agilen Elementen

Bei Anwendung von agilen Ansätzen sollten auf jeden Fall eine Klärung und Erweiterung bei:

  1. den agilen Rollen,
  2. den agilen Liefergegenständen,
  3. der Integration in den Projektlebenszyklus

durchgeführt werden.

Agile-PM Erweiterungen zu den klassische Projektmanagement-Methoden. Anlehnung: PM2v2017

 

Anpassung der Projektorganisation und der Rollen im Kontext von agilen Projekt-Ansätzen

Die klassischen Projektmanagement-Ansätze bieten bereits ein gutes Gerüst für die „Project Governance„. Eine Erweiterung der wesentlichen Rollen im Projektkernteam  – wie sie etwa vom  Scrum-Framework vorgeschlagen werden (Product Owner, Scrum Master, Scrum Team) – sind einfach und flexibel möglich.

 

Agile Teams im Kontext mit der klassischen Projektorganisation

 

Hauptrollen im Agilen Projektkernteam

 

Product Owner

Product Owner sind die Verfechter ihres Produkts. Ein Product Owner ist jedoch kein Projektmanager! Sie konzentrieren sich darauf, Unternehmens- und Marktanforderungen zu verstehen und dann die für das Entwicklungsteam anstehenden Arbeiten entsprechend zu priorisieren. Effektive Product Owner haben die folgenden Aufgaben:

  • Spezifikation, Abstimmung und Verwaltung der Anforderungen
  • Entwickeln und Verwalten des Produkt-Backlogs
  • Enge Zusammenarbeit mit dem Unternehmen und dem Team, um sicherzustellen, dass alle die Aufgabenelemente im Produkt-Backlog verstehen (User Stories)
  • Klare Anweisungen an das Team, welche Features als Nächstes ausgeliefert werden sollen
  • Entscheidung, wann das Produkt ausgeliefert wird, wobei die Tendenz zu einer häufigeren Auslieferung gehen sollte.

Team Coordinator

Der Team Coordinator übernimmt die Rolle eines Scrum Masters. Sie sind die Verfechter von Scrum in ihrem Team. Sie coachen das Team, den Product Owner und das Unternehmen in Bezug auf den Scrum-Prozess und suchen nach Wegen, dessen Umsetzung abzustimmen. Ein effektiver Scrum Master hat ein tiefgehendes Verständnis für die vom Team ausgeführten Aufgaben und kann dem Team helfen, den Auslieferungsfluss zu optimieren.

Agiles Team-Mitglied

Scrum-Teams sind die Verfechter nachhaltiger Entwicklungsverfahren. Die effektivsten Scrum-Teams sind eng verknüpft, arbeiten an einem gemeinsamen Standort und haben für gewöhnlich 5 bis 7 Mitglieder. Teammitglieder verfügen über unterschiedliche Kompetenzen und schulen einander übergreifend, sodass niemand zu einem Engpass bei der Auslieferung der Arbeit werden kann. Erfolgreiche Scrum-Teams gehen ihr Projekt mit einer klaren „Wir“-Haltung an. Alle Mitglieder des Teams unterstützen sich gegenseitig, um einen erfolgreichen Scrum-Abschluss sicherzustellen.

.

Anpassung der Liefergegenstände und Artefakte im Kontext von agilen Projekt-Ansätzen

Die Liefergegenstände in Projekten werden nach der Best Practice Methode prince2 grundsätzlich in folgende Kategorien unterteilt:

  • Managementprodukte (MPM): Das sind Liefergegenstände, die für Management- oder Qualitätsprozesse eines Projekts erforderlich sind und
  • Spezialistenprodukte (SPM): Ein Produkt, dessen Herstellung Gegenstand des Planes ist. Spezialistenprodukte gehören konkret zu einem bestimmten Projekt.

Managementprodukte lassen sich weiter unterteilen:

  1. Project Governance Artefacts: Diese Kategorie umfasst alle MPM-Liefergegenstände die für die Organisation und Führung des Projektes relevant sind. Das sind. u.a. der Business Case, der Projektauftrag (Project Charter), das Projekthandbuch.
  2. Project Coordination & Reportig Artefacts: Diese Kategorie umfasst alle MPM-Liefergegenstände die für die Koordination des Projekts relevant sind. Das sind diverse Logs (Projektinformationen), Projektstatusbericht, Fortschrittsberichte, Projektabschlussreport, Decision Logs, Change Logs, Issue Logs, Risk-Logs.
  3. (Agile) PM Specific Artefacts: Diese Kategorie umfasst alle MPM-Liefergegenstände die für die gewählte PM-Methodik spezifisch snd. Für das Agile PM wäre das u.a. Product-Backlog, Retrospetive Logs, Testing Logs, Agile Logs,

 

PM-WKD mit Aktivitäten und Liefergegenständen

.

Wir sollten also versuchen, anstatt schwammige Abgrenzungen zwischen klassischen und agilen Projektmaanagement-Vorgehensweisen und Methoden zu definieren, das passende aus beiden Welten so zu kombinieren und zu integrieren, daß der Projekterfolg noch besser sichergestellt werden kann. Wir brauchen ein integriertes Projektmanagement das sowohl „altbewährtes, klassisches“ als auch den Unternehmenskulturen angepasstes „neues, agiles“ beinhaltet.

Für Fragen und Anregungen stehen wir gerne zur Verfügung.

.

Weiterführende Begriffe und Links:

 

Kommentar verfassen