Bestandteile eines Projektplans – wirklich nötig?

Stefan Hagen hat in seinem „Projektmanagement Blog“ eine Folie bereitgestellt mit den „Bestandteilen eines Projektplans„. Die Folie enthält unter anderem 18 Teilpläne, einschließlich „Arbeitspaketdefinitionen“ und „Terminplan (GANTT)“.

Aus agiler Sicht erscheint das eher schwergewichtig. Anstatt festzulegen, welche Pläne gebraucht werden, diskutiere ich lieber die Ziele einer Planung:

  • Das Team auf die wichtigen Aufgaben fokussieren
  • Zusammenarbeit koordinieren
  • Vorhersagen über Fertigstellungstermine ermöglichen
  • Transparenz über den Projektstatus schaffen

Im agilen Bereich hat sich das aus der Toyota-Produktion stammende Kanban-Prinzip bewährt: Das Team erstellt gemeinsam mit den Auftraggebern eine priorisierte Liste der zu erstellenden Features und schätzt sie gemeinsam. Schon durch die gemeinsame Erstellung des Plans werden Ziel eins und zwei erreicht.

Die Liste wird prominent aufgehängt, in der Regel in Form von Karteikarten auf einer Pinwand. Sind Entwickler frei, „holen“ sie sich die nächstwichtige Aufgabe von der Wand und hängen sie in die Liste der Aufgaben in Bearbeitung. Sobald das Feature mit allen Tests implementiert ist (das heißt alle neuen automatischen Tests und alle alten Tests laufen auf dem Integrationsserver fehlerfrei duch), hängen sie die Karte auf „fertig“. Diese klare Definition, wann eine Aufgabe fertig ist, trägt erheblich zur Transparenz bei.

Für die Vorhersagen gibt es Schätzverfahren, die anhand der vorigen Iterationen kalibriert und nachkalibriert werden.

Natürlich wird diese Planung für jede Iteration wiederholt. Ich persönlich arbeite dabei oft mit drei Ebenen unterschiedlicher Granularität: Wochenplanung, Monatsplanung und Releaseplanung (siehe auch den Eintrag „Langfristige Produktplanung und Agilität„).

Bei allen Teams, in denen ich diese Verfahren eingeführt habe, war die deutliche Verbesserung von Transparenz und Zusagetreue einer der schnellsten Effekte. Dass das, was man anhand der Transparenz nun sehen konnte, nicht immer erfreut hat, ist ein anderes Thema.

Keines der Teams hat eines der 18 Planungsdokumente erstellt oder gepflegt, alle haben wirtschaftlich erfolgreiche Projekte oder Produkte entwickelt. Ich stimme daher Herrn Hagen zu, dass „eine systematische, pragmatische und dynamische Projektplanung von größter Bedeutung für den späteren Erfolg“ ist, ich bin aber überzeugt, dass der agile Planungsansatz diese Anforderungen weit effizienter erfüllt, als eine Sammlung von 18 Planungsdokumenten – zumal das für deren Pflege notwendige Projektmanagementbüro in der Regel größer ist, als das Entwicklungsteam in agilen Vorhaben.