Der agile PMBOK® Guide 4th edition – Zeitmanagement

Standardisierung (Icon)Heute dreht sich in der Serie zum agilen PMBOK® Guide alles um Zeit. Neben dem Scopemanagement ist die Zeitplanung in agilen Projekten ebenfalls deutlich unterschiedlich zu klassischen Vorgehensweisen, wie bereits im Posting zu agilen Projektrandbedingungen erläutert. Der Faktor Zeit ist in agilen Projekten nicht notwendigerweise als Randbedingungen komplett festgelegt, aber werfen wir einen Blick auf die einzelnen Prozesse des PMBOK® Guide 4th edition:

  • Vorgänge festlegen
    Diese Aufgabe gibt es auch in agilen Projekten. Bei SCRUM werden die Aktivitäten allerdings vom Projektteam im Rahmen der Sprintplanung aus den User Stories erstellt, nicht durch den Projektleiter im Vorfeld. Bei anderen agilen Vorgehensweisen ist dies ähnlich. Den Prozess an sich kann man natürlich bestehen lassen, allerdings empfiehlt sich neben einer Umbenennung eine inhaltliche Ausgestaltung entsprechend der Vorgehensweise unter Berücksichtigung der Rollen in agilen Projekten (vgl. Postings dazu: Teil 1 und Teil 2).

  • Vorgangsfolge festlegen
    Hier gilt Gleiches wie für den vorangegangenen Prozess. Im Rahmen von Sprints bei SCRUM kann aus meiner Sicht ein Netzplan meist entfallen. Aus Gesamtprojektsicht sollte der Projektmanager über einen Netzplan verfügen in dem die wichtigen Meilensteine, Schnittstellenaktivitäten und Sprints erkennbar sind. Die Planung eines Sprints durch das Team sollte ggf. in einem anderen Dokument erfolgen.

  • Ressourcen für Vorgänge schätzen
    Dieser Prozess wird in den meisten agilen Projekten Probleme verursachen, da weder Scope noch Zeit notwendigerweise komplett festgelegt sind. Häufig definiert man, wieviel Ressourcen eingesetzt werden dürfen aufgrund einer initialen Grobschätzung der Aufwände oder einer Budgetgrenze für den Personaleinsatz. Aus diesem Grund würde ich den Prozess in agilen Projekten auf die Liste der Streichkandidaten setzen. Stattdessen sollte bei der Planung einzelner Sprints auch die Ressourcenplanung durch das Team durchgeführt werden. Auch hier kann der Projektmanager wieder eine Gesamtsicht für das Projekt pflegen, allerdings rechtfertigt dies möglicherweise keinen dedizierten Prozess mehr.

  • Vorgangsdauer schätzen
    Die Dauer der Vorgänge wird bei SCRUM durch das Team im Rahmen der Sprintplanung geschätzt, eine grobe Vorabplanung findet ggf. durch den Projektmanager statt um den Gesamtaufwand des Projektes einschätzen zu können. Dieser Prozess gehört auch auf die Streichliste wenn die Schätzungen hauptsächlich durch das Team in der Feinplanung durchgeführt werden. Auf der anderen Seite sollte die Erfahrung und Kompetenz eines Projektmanagers für die Schätzung genutzt werden, da dieses Know-How häufig erfolgskritisch für die Planung ist. Gleiches gilt auch für die anderen Prozesse, die in agilen Projekten häufig durch das Team und nicht mehr hauptsächlich durch den Projektmanager durchgeführt werden.

  • Terminplan entwickeln
    Für die Überblicksplanung sollte dieser Prozess beibehalten werden, auch wenn die vorangehenden Prozesse des Zeitmanagements teilweise gestrichen werden. Verbleibende Aktivitäten gestrichener Prozessen würde ich diesem Prozess zuschlagen um die Prozessanzahl zu verringern und Prozesse nicht zu Aktivitäten verkommen zu lassen. Hier werden auch die Gefahren einiger agiler Ansätze offensichtlich. Durch geringere Nutzung der Fähigkeiten des Projektmanagers und weniger intensive Planung, kann der Erfolg von Projekten auch gefährdet werden. Hier ist ein gesunder Kompromiss zwischen Agilität und Erfahrungswerten erforderlich.

  • Terminplan steuern
    Die meisten Aspekte dieses Prozesses entfallen in SCRUM, es verbleibt die Aufgabe des Projektmanagers die Gesamtsicht des Projekts zu steuern. Aus meiner Sicht muss er innerhalb der Sprints dem Team als Coach zur Seite stehen hinsichtlich der Steuerung der Sprintplanung. Ggf. macht es Sinn diesen Prozess durch einen Prozess Sprint steuern zu ersetzen.

In diesem Wissensgebiet können diverse Prozesse entfallen oder zusammengefasst werden, da die Planung nicht mehr durchgehend vom Groben ins Feine, gesteuert durch den Projektmanager, erfolgt. Stattdessen übernimmt der Projektmanager sinnvollerweise die Gesamtplanung und überlässt die Feinplanung dem Team. Bei der Feinplanung berät er das Team, da das Team in Summe meist nicht die Skills des Projektmanagers mitbringt.

Hinweis: Die verwendeten Prozessnamen sind meine Übersetzungen da die deutsche Übersetzung des PMBOK® Guide 4th edition noch nicht erschienen ist.

Kommentare sind geschlossen.

%d Bloggern gefällt das: