Claus Kolb

IT Projektmanagement


Auf meinem Blog berichte ich regelmäßig von meinen Erfahrungen aus Kundenprojekten. Folgen Sie mir auf Twitter, um über neue Artikel informiert zu werden.

Projektmanagement 2.0 (Teil 2): Vom klassischen zum agilen Projektleiter

Juni 20, 2014Claus Kolb0 Kommentare

Wie im ersten Teil der Blogartikelserie beschrieben, kann die Position des Projektleiters in „klassischen“ Projekten zusätzlich Aufgaben der Rollen Requirements Engineer, Technischer Experte und Softwareentwickler beinhalten. Diese Aufgaben werden in Scrum-Projekten durch die Rollen des Product Owners, des Scrum Masters und des (Development) Teams übernommen. Im letzten Artikel ist allerdings offen geblieben, wie die Projektmanagementaufgaben verteilt werden können, wenn es zusätzlich einen agilen Projektleiter gibt.

Bei den nun folgenden Erläuterungen eines Unternehmens gehe ich davon aus, dass in der Entwicklungsabteilung nach Scrum Software entwickelt wird, das restliche Unternehmen aber „klassisch“ arbeitet. Die Softwareentwicklung erfolgt in stabilen Teams, deren Zusammensetzung über mehrere Projekte hinweg möglichst konstant ist.

Der wesentliche Unterschied zwischen den Scrum-Rollen und der Rolle des agilen Projektleiters liegt in der Perspektive, aus dem ein Projekt betrachtet wird. Die Scrum-Rollen interessieren sich wenig für Projekte. Der Product Owner ist für die Produktvision und dessen kontinuierliche Weiterentwicklung der Software zuständig. Der Scrum Master hat einen Team- und (Scrum-) Prozessfokus. In Unternehmen, die Projekte als ein wesentliches Element des Fortschritts verwenden, fehlt hier jemand, der für das Projekt verantwortlich ist. Diese Lücke schließt der agile Projektleiter. Der Projektleiter stellt den hauptverantwortlichen Ansprechpartner für das Projekt dar (sog. „Single Wringable Neck“).

Im Folgenden beschreibe ich, wie die einzelnen Projektmanagementaufgaben unter den o.g. Annahmen von den Rollen wahrgenommen werden können. Die Beschreibung basiert auf meiner Praxiserfahrung aus Projekten, in denen ich als agiler Projektleiter gearbeitet habe. Die konkrete Arbeitsteilung ist aber von vielen Faktoren abhängig und muss an die individuellen Gegebenheiten angepasst werden.

Koordination agiler und nicht-agiler Organisationseinheiten

In der hier zugrunde gelegten Projektorganisation arbeiten einzelne Bereiche agil und andere nicht. I.d.R. sind die agil arbeitenden technischen Abteilungen in ein traditionell hierarchisch strukturiertes Unternehmen eingebunden, das nicht agil arbeitet. Die Koordination der agilen und nicht-agilen Unternehmensteile sowie die Abstimmung mit externen Partnern sind wesentliche Aufgaben des agilen Projektleiters. In diesem Zusammenhang obliegt ihm ebenfalls die Aufgabe, diese Integration und die Projektvorgehensweise zu gestalten und zu optimieren.

Projektinitiierung

Am Beginn eines Projektes steht die Projektzieldefinition, die am besten in Form eines Projektauftrags festgehalten wird. Der Projektauftrag kann zusätzlich in einer Machbarkeitsstudie verifiziert und mit weiteren (groben) Informationen (Kosten, Dauer, Leistungsumfang) angereichert werden. U. U. sind auf Basis der Machbarkeitsstudie Angebote von externen Dienstleistern einzuholen. Im Rahmen des Portfoliomanagements wird über die Projektdurchführung entschieden. Diese Aufgaben werden vom agilen Projektleiter durchgeführt bzw. koordiniert. Er sorgt dafür, dass aus einer Projektidee ein durchführbares, abgegrenztes Projekt wird. Diese Projektphase muss dabei nicht lang sein[1].

Vorgehensweise und Organisation des Projekts festlegen

Die Scrum-Methode gibt wesentliche Elemente der grundlegenden Vorgehensweise eines Projektes in der Entwicklung bereits vor. Der Sprint legt den Takt fest und die Scrum-Meetings geben der Planung, dem Review der Ergebnisse und der eigenen Projektvorgehensweise ein eigenes Forum. Der Scrum Master ist für die Einhaltung und Optimierung der Scrum-Methode in der Entwicklung verantwortlich. Er stellt einen separaten Methodenwächter dar.

Dem agilen Projektleiter obliegt aber nach wie vor, die Organisation des Projektes zu definieren und zu überwachen (Projektrollen, Organigramm, Meetings…). Die Projektmanagementstandards des Unternehmens sind zu beachten. Der agile Projektleiter verantwortet das Gesamtprojekt.

Planung

Ja, auch im agilen Kontext gibt es Pläne ;-). Eine Planung wird in Scrum-Projekten nach wie vor durchgeführt, aber nicht mehr zentral von einem Projektleiter erstellt und aktualisiert. Des Weiteren wird akzeptiert, dass die Planung gröber wird, je weiter sie in die Zukunft reicht.

Phasen- und Meilensteinplanung

Die Phasenplanung des klassischen Projektmanagements wird zweigeteilt. Der Product Owner ist verantwortlich für die Sprint- und Releaseplanung, die er regelmäßig aktualisiert. Hier fließt ein, welches Epic oder welche User Story in welchem Sprint realisiert werden sollen. Wird nicht nach jedem Sprint ein Release auf das Produktionssystem ausgebracht, bündelt ein Release eine Menge von User Stories, die gemeinsam produktiv genommen werden. Der Sprint- und Releaseplan wird umso grober, je weiter er in die Zukunft reicht.

Der agile Projektleiter definiert auf der Basis des Sprint- und Releaseplans Meilensteine, die für die Kommunikation und Koordination mit dem Gesamtunternehmen wichtig sind. Er aggregiert dafür den Sprint- und Releaseplan.

Als Meilensteine können z.B. das erste Produktionsrelease und weitere nach dem Umfang der bereits realisierten Funktionen definierten Termine festgelegt werden.

Projektplanung

Der Product Owner erstellt und aktualisiert den Sprint- und Releaseplan. Auf dieser Basis und der Velocity des Scrum-Teams kann eine „agile“ Projektplanung erfolgen, die angibt, wie hoch das Gesamtbudget an Story Points ist und wann die einzelnen Epics ungefähr fertiggestellt werden (s. Blogartikel Agiles Projektcontrolling mit Story Points).

Auf Projektstrukturpläne im traditionellen Sinne verzichtet Scrum. Vielmehr definiert der Product Owner fachliche User Stories, die vom Team ggf. in technische Tasks heruntergebrochen werden, und hält sie im Product Backlog fest. Das Development Team unterstützt den Product Owner auch bei der Erstellung der User Stories.

Außerhalb der agilen Bereiche wird im Projekt „klassisch“ gearbeitet, so dass der agile Projektleiter die Arbeitspakete in diesen Bereichen erfasst. Dafür kann ein Projektplan als Gantt-Diagramm sinnvoll sein. In meiner Praxis hat es sich bewährt, die Projektplanung an den Sprinttakt des Scrum-Teams anzugleichen.

Mitarbeitereinsatzplanung

In der hier vorausgesetzten Projektorganisation wird mit festen Teams gearbeitet. Demzufolge ist die Teamkapazität pro Sprint (idealisiert) konstant. Die Einsatzplanung für Mitarbeiter aus nicht-agilen Bereichen ist aber nach wie vor vom agilen Projektleiter durchzuführen.

Zusammenfassung und Ausblick

Im dritten Teil der Blogartikelserie wird es um die verbleibenden Projektmanagementaufgaben Controlling, Kommunikations- und Berichtswesen, Änderungsmanagement, Projektmarketing, Risikomanagement, Mitarbeiterführung und Projektabschluss gehen.

An dieser Stelle möchte ich die bisherigen Betrachtungen bezüglich der Projektmanagementaufgaben noch einmal in einer Tabelle zusammenfassen.

Tabelle 1: Überblick über die Aufgabenverteilung

Tabelle 1: Überblick über die Aufgabenverteilung

Weiterlesen

 


[1] Wie eine „agile Projektinitiierung“ aussehen kann, wird Bestandteil eines anderen Blogartikels sein.


Eine Antwort eingeben