Projektplan
Inhaltsverzeichnis: Definition – Ergebnis eines Prozesses – agile und klassische Projekte – Hinweise
Wissen kompakt: Ein Projektplan beinhaltet die inhaltliche, strukturelle, zeitliche, personelle und monetäre Planung eines Projekts. Er besteht aus einem oder mehreren konsistenten Dokumenten.
Projektplan – das Fundament für ein Projekt
Wer sich in einem Projekt nach dem Projektplan erkundigt, wird häufig unterschiedliche Antworten erhalten. In machen Organisationen ist der Meilensteinplan mit wichtigen Terminen das zentrale Element zur Planung von Projekten. In anderen ist es ein Projektstrukturplan. Oder ein Ablaufplan, ein Kostenplan, ein Ressourcenplan. Das ist aus zwei Gründen nicht wirklich überraschend:
1. Alle diese Pläne versuchen, wesentliche Aspekte eines Projekts logisch zu strukturieren.
2. Viele diese Pläne werden in der Praxis mit Informationen angereichert, die auch in anderen Plänen enthalten sein könnten. Ein Terminplan verbindet häufig die zu erledigenden Aufgaben mit Ressourcen und Kosten. Der Kostenplan enthält Phasen, die auch in einem Projektstrukturplan benutzt werden.
Und was ist dann also ein Projektplan? Ein Projektplan beinhaltet die logische, sprich inhaltliche, strukturelle, zeitliche, personelle und monetäre Planung eines Projekts. Als „Gesamtheit aller im Projekt vorhandenen Pläne“ – wie es die DIN 69901 formuliert – kann der Projektplan aus einem oder mehreren konsistenten Dokumenten bestehen. Er bildet damit das planerische Fundament für ein Projekt.
Der Projektplan als Ergebnis eines Prozesses
Die Erstellung eines Projektplans – alternativ auch Projektmanagementplan genannt – kann auch als Prozess aufgefasst werden, bei dem eingehende Informationen – auch als Input bezeichnet – inhaltlich, zeitlich und logisch strukturiert und in Einklang gebracht werden, um einen einen Output – den Projektplan – zu erzeugen. Häufig wird empfohlen, den Input schrittweise über qualifizierende W-Fragen zu entwickeln:
- Wie ist die Ausgangslage bzw. Situation? Welche Herausforderungen gilt es zu meistern, welche Informationen liegen bereits vor, welche Aspekte sind bereits klar, welche unklar?
- Warum soll das Projekt durchgeführt werden? Welche Chancen bietet das Projekt, welcher Nutzen soll erzielt werden? Und welche Risiken gibt es?
- Welche Ziele sollen verfolgt werden und welche nicht? Welche Ergebnisse sollen zum Projektende vorliegen?
- Wer sind die Stakeholder, wer wirkt in welchem Umfang und Zeitraum mit?
- Wie wird das Projekt, die Projektarbeit und das Projektteam organisiert? Welche Methoden, Tools und Mindsets werden favorisiert?
- Welche Projektphasen ergeben Sinn, welche Ergebnisse sollen zu welchen Meilensteinen vorliegen, wie lange dauern die Phasen?
- Welchen Aufwand darf das Projekt verursachen, welche Budgets gibt es, welche Mitarbeiter und Ressourcen werden benötigt?
Viele dieser Fragen führen zu neuen Fragen wie bspw. wie erfolgt das Stakeholdermanagement, wie gelingt es eine notwendige Aufmerksamkeit des Managements zu erzeugen, wer definiert wie Anforderungen, was geschieht mit Änderungen, wie wichtig ist das Projekt im Verhältnis zu anderen Projekten etc. Dieses Fragen sind nützlich und wichtig, aber nicht alle lassen sich final vor einem Projekt beantworten und entsprechend in Plänen berücksichtigen. Hier lebt eine Organisation auch von Ihrer Erfahrung. Hinzu kommt, dass sich der Projektplan auch je nach Projektkontext unterscheiden kann. Stichwort: agile und klassische Projekte.
Projektplan in agilen und klassischen Projekten
Immer häufiger wird ein agiles Vorgehen für komplexe und unsichere Projekte empfohlen. Offensichtlich sind Projekte mit unsicheren Rahmenbedingungen und unklaren Lösungswegen schwierig zu planen, so dass häufig in kurzen Zyklen geplant und gemessen wird, und gewonnene Erkenntnisse in die Planung der nächsten Phase einfließen. Nichts desto trotz gibt es auch in agilen Projekten einen Projektplan, alleine deswegen, weil der Kunde in den allermeisten Fällen wissen möchte, wann er etwas geliefert bekommt. Was – also bspw. welchen Funktionsumfang – er geliefert bekommt, steht auf einem anderen Blatt. Ein Projektplan im einem agilen Projekt ist somit häufiger weniger detailliert als ein entsprechender Plan in einem klassischen Projekt.
Natürlich sind auch komplizierte (klassische) Projekte, die eine lange Laufzeit haben, an denen viele Parteien mitwirken, alles andere als einfach zu planen. Die Individual Competence Baseline (ICB) – ein Kompetenzstandard der IPMA – stellt daher auch zu Recht fest:
„Ein Projektplan kann zahlreichen Störungen unterliegen, die Anpassungen notwendig machen. Diese können aus unterschiedlichen Quellen stammen (Änderungen bei den Lieferobjekten, Anforderungen, Ressourcen- oder Geldknappheit oder verspätete oder nicht den Anforderungen entsprechende Lieferungen) und eine Überarbeitung der Planung erforderlich machen. Der Ablauf- und Terminplan sollte in regelmäßigen Abständen mit der Bezugsbasis verglichen und, wenn nötig, angepasst werden.“
In anderen Worten: auch in klassischen Projekten werden Projektpläne angepasst, denn Änderungen sind nichts Ungewöhnliches. Und das bedeutet, dass der Umgang mit Projektplänen in agilen und klassischen Projekten gar nicht so verschieden ist, wie es auf den ersten Blick erscheinen mag. Das Image der beiden ist aber sehr unterschiedlich.
Impuls zum Diskutieren
Alle Pläne und Prinzipien sind erst einmal neutral, es kommt immer darauf an, wie Menschen sie konkret einsetzen.
Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.
Der von den Projektverantwortlichen genehmigte erste Projektplan wird auch Basisplan genannt.
Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt: