Ein wichtiges Merkmal von agil durchgeführten Projekten ist die iterative Entwicklung. Diese bietet die Möglichkeit, auf Änderungen schnell zu reagieren und notwendige Anpassungen zu einem frühen Zeitpunkt vorzunehmen. So vorteilhaft dieses Vorgehen in dieser Hinsicht ist, so anspruchsvoll macht dies die Planung des Projekts oder der Releases. Da es keinen vorausberechneten Projektplan als Netzdiagramm oder Gantt-Chart gibt, kann auch kein Soll-Ist-Vergleich vorgenommen werden, ob das Projekt im Plan ist. Stattdessen wird der Projektfortschritt aus den erreichten Ergebnissen der abgelaufenen Iterationen abgeleitet.

In Scrum als dem bekanntesten Vertreter von agilem Vorgehen wird für die Planung ein Burn-down-Chart angeboten. In ersten Teil der Artikelserie lernen Sie eine alternative Darstellungsform – den Burn-up-Chart – kennen und in welchem Kontext diese besser geeignet ist als der allgemein gebräuchliche Burn-down-Chart. Im zweiten Teil der Artikelserie erhalten Sie eine Vorlage für einen Burn-up-Chart in Form eines Excel-Spreadsheet. Anhand einer detaillierten Beschreibung und eines konkreten Beispiels erfahren Sie auch, wie Sie diese Vorlage anwenden, um einen Burn-up-Chart zu erstellen, der Ihren Projektanforderungen entspricht.

Traditionelle Projektplanung

Die Planung sog. "traditioneller" Projekte erfolgt häufig nach diesem Muster: Zunächst werden die Projektziele definiert. Dann werden das Projektumfeld und die Stakeholder analysiert. Daran schließt sich eine erste Risikoeinschätzung an und es werden Maßnahmen zur Verringerung der Risiken abgeleitet.

Nachdem eine für das Unternehmen passende Projektorganisation ausgewählt wurde, kommt es nun zur Planung des Projekts (Bild 1), die z.B. folgendermaßen abläuft:

1. Mit der Beschreibung der Projektphasen und Meilensteine erfolgt eine erste Strukturierung des Vorhabens.
2. Daran schließt sich die Erstellung des Projektstrukturplanes (PSP) an, der mit den beinhalteten Arbeitspaketen das zentrale Ordnungs- und Kommunikationselement im Projekt darstellt. In der Arbeitspaketbeschreibung sind wiederum die Aufgaben inklusive der Schätzung, also der Dauer für die einzelnen Aufgaben, enthalten. Die Schätzungen werden dabei häufig als Expertenschätzungen durchgeführt, d.h. wenige erfahrene Entwickler und/oder Architekten schätzen die Dauer der Arbeitspakete.
3. Mit Hilfe der Schätzung können nun die Einsatzmittel inklusive einem Ressourcenabgleich geplant werden. Mit den Einsatzmitteln sind hier u.a. diejenigen Menschen gemeint, die das Projekt tatsächlich durchführen werden.
4. Der nächste Schritt bildet die Erstellung des Kostenplans, mit dem die Gesamtkosten des Projekts, basierend auf den Ergebnissen der vorangegangenen Arbeiten, ermittelt werden.
5. Die genaue zeitliche Darstellung der zu erledigenden Arbeiten und vorhandene Abhängigkeiten fließen dann in einen Netzplan oder vernetzten Balkenplan ein. Erst jetzt bekommt der Projektleiter die genaue Information, wie das Projekt zeitlich gesehen abgewickelt werden kann und ob dies im Einklang mit der groben Strukturierung im Phasen-/Meilensteinplan steht. Auch die Ermittlung des kritischen Pfades und die Pufferzeiten ergeben sich aus der Berechnung des Netzplans.

Bild 1: Traditionelle sequentielle Projektplanung.

Der Vorteil eines derartigen Vorgehens liegt darin, dass es das Projekt stark strukturiert und ungeübte Projektmitarbeiter ziemlich genaue Anweisungen haben, wie sie vorgehen sollten.

Ein Nachteil liegt darin, dass der Auftraggeber bei perfekter Durchführung des Plans genau das bekommen wird, was zu Beginn des Projektes vereinbart wurde, und nicht das, was er mittlerweile tatsächlich benötigt. Mittlerweile deshalb, weil gerade bei langlaufenden Projekten neue Erkenntnisse im Projektverlauf zu neuen Anforderungen führen können. Eine Änderung an Anforderungen kann hier aber nur durch Change Requests dargestellt werden, was zur Folge hat, dass alle damit zusammenhängenden Pläne angepasst werden müssen.

Des Weiteren führen meiner Erfahrung nach häufig nicht diejenigen Mitarbeiter die Planung durch, die später an der Umsetzung beteiligt sind. Die Folge davon kann sein, dass die Festlegungen, die erfahrene Entwickler und/oder Architekten vorgenommen haben, nicht eingehalten werden können, da die Umsetzung durch weniger erfahrene Entwickler erfolgt.

Die Tätigkeiten im Rahmen der Planung verteilen sich auf einen großen Arbeitsaufwand vor bzw. zu Beginn des Projekts. Im laufenden Projekt ist der Projektleiter dann hauptsächlich damit beschäftigt, den Fertigstellungsgrad (Ist-Zustand) abzufragen, mit dem geplanten Fortschritt (Soll-Zustand) zu vergleichen und ggf. Maßnahmen einzuleiten, falls die Budget- und Terminhochrechnungen, z.B. mit Hilfe einer Earned-Value-Analyse, eine Abweichung vom Plan ergeben.

Projektplanung mit einem Burn-down-Chart

Bei Scrum, dem bekanntesten Vertreter agiler Vorgehensweisen, erfolgt kein derartiges "Big Planning Upfront". Auch wenn Scrum dies nicht explizit vorschreibt, sollten natürlich die ersten Schritte einer Projektinitiierung, also die Definition der Projektziele, eine erste Umfeld- und Stakeholder-Analyse sowie eine Risikoeinschätzung inklusive Maßnahmen zur Verringerung der Risiken ebenso vorgenommen werden.