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 man ü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. - 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. 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 eines 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 oder Product Owners die Gesamtsicht des Projekts zu steuern. Aus meiner Sicht muss eine Person (Scrum Master, Product Owner oder Projektmanager) 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 erfolgt. Stattdessen übernimmt ein Projektmanager ggf. die Gesamtplanung und überlässt die Feinplanung dem Scrum Team. Bei der Feinplanung kann er das Team beraten.
Hinweis: Die verwendeten Prozessnamen sind meine Übersetzungen da die deutsche Übersetzung des PMBOK® Guide 4th edition noch nicht erschienen ist. 
Dieser Artikel wurde von Andreas Heilwagen am 05.06.2009 um 08:00 gepostet und unter Best-of, Meinung, PMI, Scrum, Standards eingeordnet. Sie können Kommentaren über den RSS 2.0-Feed folgen. Das Posting steht unter der Creative Commons-Lizenz wenn nicht anders vermerkt.
