Projektstrukturplan (PSP) – Alle wichtigen Fragen beantwortet

Projekte jeder Größe müssen auf verschiedensten Ebenen organisiert werden. Zwischen den unterschiedlichen Deadlines, Aufgaben und Verantwortlichkeiten eines jeden Teammitglieds kann man dabei schnell den Überblick verlieren. Nicht selten passiert es, dass erst auf der Zielgraden fehlende Elemente bemerkt werden. Nach zum Teil monatelanger Investition von Zeit, Geld und Arbeitskraft wird dann auf den letzten Metern an Notlösungen gefeilt, denen man den Aufdruck „Lückenbüßer“ förmlich ansehen kann.

Haben auch Sie es satt unter Hochdruck bis Anschlag an Projekten zu arbeiten, deren Qualität ultimativ immer an unzureichender Planung leidet? Ein Projektstrukturplan hilft sowohl Projektleitern als auch Projektmitgliedern Erfahrungen zu koordinieren und Bemühungen zu bündeln.

Im Folgenden haben wir an Hand zahlreicher Beispiele noch einmal alle wichtigen Fragen zum Projektstrukturplan für Sie beantwortet. Viel Erfolg auf dem Weg zu Ihrem individuellen Projektbegleiter!

• Statischer Projektstrukturplan in einer agilen Welt
• Warum erstellen wir einen Projektstrukturplan?
• Wann wird der Projektstrukturplan erstellt?
• Wer erstellt den Projektstrukturplan?
• Wie erstelle ich einen Projektstrukturplan?
• Die Erstellung eines Projektstrukturplans mit Power Point
• Wie erstelle ich einen Projektstrukturplan in Word?
• Wie ist der Projektstrukturplan aufgebaut?
• Warum ein phasenorientierter Projektstrukturplan?
• Wie detailliert sollte der Projektstrukturplan sein?
• Was sind Arbeitspakete innerhalb eines Projektstrukturplans?
• Woher weiß ich, ob ich alle Arbeitspakete erwischt habe?
• Wie verwende ich Kennzahlen in einem Projektstrukturplan?
• Warum sollte ich Krisen in den Projektstrukturplan mit einplanen?
• Überwachung und Anpassung des Projektstrukturplans
• Vom Projektstrukturplan zum Ablaufplan (Gantt-Diagramm)

Statischer Projektstrukturplan in einer agilen Welt

Agiles Projektmanagement muss sich oft den Vorwurf gefallen lassen, dass es ergebnisoffen ist. Das bedeutet, dass einfach „nur“ geschaut wird, dass man mit den bestehenden Ressourcen so weit kommt wie möglich, aber kein konkretes Ziel verfolgt wird. Das lässt sich mit einem Projektstrukturplan in einer agilen Umgebung durchaus umgehen. Denn wenn wir weiterhin zielorientiert denken, bedeutet es, wir wollen etwas erreichen, nach unserer Arbeit und unserem Projekt soll etwas anders ein. Wie der Weg dorthin aussieht, legen wir statisch fest, das heißt, dass wir zwar die Ressourcen agil verwalten, indem z. B. das zuständige Team in Sprints eingeteilt ist, also in kurze Zeitperioden, in denen es arbeitet, dass aber das Ergebnis, das erreicht werden soll, auf eine bestimmte Art und Weise erreicht wird. Diese Art und Weise geben wir wieder über den Projektstrukturplan vor. Wir können also demnach unterscheiden, ob das Team agil arbeiten soll oder ob der Weg zum Projektziel agil sein soll.

Nehmen wir an, ich arbeite in einer Umgebung, in der kurzfristig immer wieder neue Projekte hinzukommen und sich die Prioritäten verschieben. Eine wirklich langfristige Planung ist somit nicht möglich, aber gleichzeitig brauchen die Teammitarbeiter eine Umgebung, in der sie trotzdem so viel Sicherheit haben, dass sie wissen, dass sich nicht jeden Tag die Prioritäten verändern, sondern möglichst nur einmal im Monat, alle zwei oder drei Monate – wann auch immer das in Ihrer Organisation angemessen ist. Ich muss also ein Zeitintervall schaffen, in dem die Prioritäten gleichgelagert bleiben. Ich nenne diese Zeitintervalle beispielsweise Sprint und sage er dauert 3 Wochen. Ich lege am Anfang eines Sprints somit Ziele oder Prioritäten fest. Prioritäten könnten beispielsweise sein: Projekt A ist das wichtigste, dann kommen Projekt B und C und am unwichtigsten ist Projekt D. Wenn wir können, nehmen wir dieses noch mit, müssen wir aber nicht. In diesem Fall, mache ich mein Projektteam ziemlich agil, weil ich zulasse, dass sich die Prioritäten verändern können. Ich gebe eine gewisse Statik mit, nämlich diesen 3-Wochen-Sprint, in der sich mein Projektteam darauf verlassen kann, dass sich nicht die ganzen Prioritäten wieder ändern. Andererseits bin ich aber so agil, dass ich innerhalb kürzester Zeit (3 Wochen) auf Veränderungen reagieren kann.

Jetzt ist die Frage: Ist die Arbeit, die innerhalb dieses Sprints stattfindet, auch agil oder ist die eher statisch? Agil würde bedeuten, dass es eine Art User Story gibt, die erfüllt werden soll. Eine User Story könnte sein, wenn ich eine Bestellung ausdrucke, soll auch noch der Lieferschein ausgedruckt werden. In diesem Fall, sage ich, was passieren soll, aber ich gebe nicht vor, wie der Weg dahin ist. Ich arbeite also ohne Projektstrukturplan. Vielleicht überlege ich mir diesen dann, wenn es soweit ist. Es kann aber auch genauso gut sein, und deswegen kommen wir eigentlich aus der Programmierwelt, dass der Programmierer selbst entscheidet, wie er das dann in dem Fall umsetzt. Und dass er während der Programmierung auf Hürden stößt, die ihn einen anderen Weg gehen lassen. Er ist in der Wahl des Weges damit vollkommen frei. Am besten kann man das mit einer Reise von einer Stadt in eine andere vergleichen. Starte ich in Berlin und möchte nach Hamburg, habe ich die Möglichkeit die A24 zu nehmen.

Mit einem Projektstrukturplan lege ich fest, dass ich erst bei dem einen Rasthof, dann beim nächsten und dann bei einem dritten Rasthof tanke, bevor ich dann in Hamburg ankomme. Wenn ich das ganze agil gestalte, sage ich nur, ich möchte in diesem Zeitintervall (3 Wochen) von Berlin nach Hamburg.Wo ich dann zum Tanken anhalte, ergibt sich aus der Situation selbst, d. h. ich stelle fest, dass ich schneller gefahren bin, mein Tank also nicht mehr so lange hält und ich deswegen hier schon tanke, statt wie im Projektstrukturplan vorgesehen erst in 80 km. Das hätte in diesem Fall gar nicht geklappt, weil mein Tank ja bereits vorher leer gewesen wäre und ich keinen Ersatzkanister habe.

Ein Projektstrukturplan in einer agilen Welt hingegen bedeutet, dass wir uns in dieser agilen Sprintdynamik befinden. Im großen Projektportfolio können wir also kurzfristig auf Veränderungen reagieren, sodass also einzelne Projekte relevanter werden. Im Projekt selber aber arbeiten wir relativ statisch. Es wurde vorher schon ein Projektstrukturplan mit der optimalen Abfolge, also nach Möglichkeit auch ein Ablaufplan, festgelegt. Und wir arbeiten jetzt genau mit diesem Projektstrukturplan und Ablaufplan. Unser Weg ist somit statisch festgelegt, aber wir arbeiten trotzdem agil. Die Erkenntnis, die sich daraus ergibt ist, dass wir zwei Arten von Agilität haben können. Zum einen die Agilität unserer Arbeitsorganisation, also wie unser Projektteam organisiert ist, zum anderen aber auch die Agilität im Weg zur Zielerreichung.

Dies ist eine Sichtweise, die in Deutschland definitiv noch nicht eindeutig verbreitet ist. Wenn Sie sich also mit anderen Menschen über Agilität unterhalten werden, werden Sie vollkommen unterschiedliche Ansätze bekommen. Das ist ein Ansatz, der sich aus meiner Projekterfahrung sehr gut sehen lässt, denn Projekte die nicht nur in Programmierung verortet sind, lassen sich doch relativ gut vorausplanen. Hier kann es dann Sinn machen, diese statisch vorzuplanen, selbst wenn sie in einer sprintorientierten Welt sind. Reine agile Wegfindung macht dann besonders Sinn, wenn zum Beispiel wie in der IT unklar ist, wie der Weg dorthin gegangen werden kann und die Kosten um das zu evaluieren deutlich größer wären, als wenn der Weg einfach versucht wird. Denn das ist etwas, was wir mit Projektmanagement ja gerade vermeiden wollen: Try and Error. Wir wollen vermeiden, dass einfach nur versucht wird und es dann einen Schritt vor und zwei zurückgeht. Wir wollen, dass wir den Weg vorher evaluieren, um ihn dann Schritt für Schritt umzusetzen. Ist das aber technisch nicht möglich, wie in bestimmten Programmierprojekten, dann müssen wir diesen agilen Weg gehen. Was für Sie im Einzelfall besser ist, muss man sich dann detailliert anschauen. Das lässt sich wenig pauschalisieren, da wirklich detaillierte und situationsbezogene Entscheidungen getroffen werden müssen.

Als Unterscheidungskriterium ist es für Sie wichtig, ob Sie in Ihrer Projektwelt agil sind, also ob sich Prioritäten und Ziele zwischen Projekten schnell verändern können oder ob Sie im Einzelprojekt agil sind. Im letzteren Fall, arbeiten Sie nicht mit einem Projektstrukturplan, sondern erarbeiten sich während des Projektes den Weg zum Ziel.

Welchen Weg davon Sie gehen, bleibt Ihnen überlassen. Wichtig ist, dass Sie sich damit auseinandersetzen, was für eine Art von Agilität Sie in Ihren Projekten haben.

Warum erstellen wir einen Projektstrukturplan?

Einer der großen Scheitergründe für Projekte ist unzureichende Planung. Unzureichende Planung bedeutet, dass ich keinen Überblick über das Projekt habe. Ich habe mir vorher keine Gedanken gemacht, welche Schritte alle notwendig sind und wie diese aufeinander ausbauen.

Meine Erfahrungen in der Praxis zeigen, dass Probleme vor allem dann entstehen, wenn ich genau diese Planung unterlasse, wenn ich mich also nicht damit beschäftige, was ich alles zu tun habe. Dann wird es nämlich schnell ein Arbeiten auf Zuruf, dann kommt hier noch etwas dazu und da noch etwas und dort, und plötzlich ist das ganze Projekt viel komplexer als eigentlich gedacht. Und warum? Weil ich mich anfangs nicht hingesetzt habe um es detailliert zu planen.

Und darin liegt die Begründung für den Projektstrukturplan. Wir brauchen ihn um für uns selbst eine Übersicht zu erzeugen, was alles im Projekt zu tun ist. Hierbei können wir davon ausgehen, dass das Kosten-Nutzen-Verhältnis in der Regel gegeben ist. Denn mit etwas Erfahrung brauchen Sie für die Grunddarstellung eines Projektstrukturplans mit 30 bis 50 Arbeitspaketen ungefähr ein bis zwei Stunden. Dazu kommt dann noch Feedback und mehrfaches Überarbeiten, sodass wir vielleicht bei drei bis fünf Stunden für einen Projektstrukturplan sind.

Dafür können Sie sich aber sicher sein, dass Sie einen Großteil der relevanten Projektpunkte erfasst haben. Sie konnten einen großen Anteil der relevanten Arbeitspakete aufschreiben und wissen, was im Projekt zu tun ist. Das stellt am Ende dann auch die Information für den Projektstrukturplan dar.

Von einem intuitiven Handeln („Jetzt müssen wir das tun, jetzt das. Ach ja, wir haben das noch vergessen“) kommen Sie auf eine strukturierte Steuerung von Projekten, indem Sie sich vorher überlegen, welche Arbeitspakte es gibt und wie diese im Zusammenhang miteinander stehen.

Wann wird der Projektstrukturplan erstellt?

Projekte können unterschiedlich aufgebaut sein, genauso können auch Projektphasen unterschiedlich aufgebaut sein. Bei manchen steht so die Projektplanung relativ am Anfang, bei anderen hingegen kommt es erst zu einer Art Evaluation, einer Machbarkeitsüberprüfung bzw. -studie, und dann geht es erst in die detaillierte Projektplanung. Das ist dann aber auch der Moment, an dem der Projektstrukturplan erstellt werden soll. Wir können davon ausgehen, dass dies relativ früh im Projekt ist, sollte aber meiner Meinung nach spätestens mit der Vorplanung abgeschlossen sein.

Einen Projektstrukturplan zu erstellen, bietet sich im Grunde immer dann an, wenn wir die Übersicht über das Projekt haben wollen. Wenn wir erstmal schauen wollen, ob das Projekt überhaupt machbar ist, eine sog. Machbarkeitsstudie durchführen, dann ist ein guter Moment gekommen, einen Projektstrukturplan zu erstellen. Dann können wir uns nämlich darüber Gedanken machen, wieviel Umfang, Aufwand und Kosten ein Projekt hat, denn dann brauchen wir die ersten Kennzahlen. Es ist viel einfacher, diese Kennzahlen anhand eines Projektstrukturplans zu bestimmen, so zum Beispiel die Kosten.

Wenn ich beispielsweise eine große Schusterei habe, und gerade überlege eine neue Maschine anzuschaffen, würde ich im ersten Schritt vielleicht dazu neigen, nur die Kosten für die Maschine zu erfassen, also 30.000 €. Dann frage ich mich, lohnt sich das oder lohnt sich das nicht? Damit vergesse ich aber relevante Kosten, denn es gehören noch die vorhergehende Recherche, die Aufstellung, Anschlüsse, Wartung und einiges mehr dazu. Also alles an Aufwand und Mehrkosten. Wenn ich nun aber den Projektstrukturplan schon erstellt habe, kann ich anhand dessen rangehen und meine Kennzahlen ansetzen. Ich kann überlegen, wie viel Aufwand das einzelne Arbeitspaket macht und wie viel Kosten es verursacht. Ich habe quasi in dieser Anfangsphase, in der ich das Projekt evaluiere einen viel höheren Detailgrad in der Planung und ein viel geringeres Risiko etwas zu vergessen, wenn ich hier bereits mit einem Projektstrukturplan arbeite.

Der späteste Moment, in dem es einen Projektstrukturplan geben sollte, ist wenn das Projekt beginnt. Also wenn der offizielle Startschuss fällt und wir beginnen, konkrete Arbeiten für das Projekt zu machen, ab diesem Moment dürfen wir nicht mehr intuitiv handeln. Wir sind allein schon in unserer Verantwortung als Projektmanager dazu gezwungen, einen Projektstrukturplan zu machen. Nur dann können wir auch uns selbst gegenüber sicher sein, dass wir den Großteil aller Arbeitspakete wirklich erfasst haben und nach Möglichkeit nichts hinten runterfällt. Ansonsten könnten wir davon ausgehen, dass das Projekt ziemlich chaotisch laufen würde, weil wir vielleicht zu spät dran sind und eben nicht alles eingeplant haben, sondern dann wieder auf Zuruf arbeiten. Das wollen wir mit einem Projektstrukturplan vermeiden. Wir wollen frühzeitig eine klare Übersicht darüber, was ist alles im Projekt zu tun. Dementsprechend müssen wir den Projektstrukturplan eben auch frühzeitig genug erstellen.

Wenn wir uns die reinen Methoden angucken, stellt sich natürlich die Frage, welche Methode mache ich nach welcher. Meiner Meinung nach, bietet es sich an, erst die Ziele zu definieren, sich die Stakeholder und die Risiken anzusehen und dann in die Erstellung des Projektstrukturplans zu gehen. Denn Ziele, wie auch Risiken und Stakeholder beeinflussen den Projektstrukturplan maßgeblich. Mit meinen Zielen lege ich fest, was ich erreichen will, daraus ergibt sich ja schon automatisch was ich tun muss um es zu erreichen. Was ich tun muss, ist ja das was ich im Projektstrukturplan erfasse.

In der Betrachtung der Risiken fallen mir vielleicht schon die ersten Risikomaßnahmen auf, die ich treffen muss, um die Eintrittswahrscheinlichkeit und das Schadensausmaß der einzelnen Risiken zu senken. Und auch das erfasse ich natürlich im Projektstrukturplan, denn auch das sind wieder Arbeitspakete.

Auf die Stakeholder, die Anspruchsgruppen, bezogen, leite ich auch Aufgaben ab, die ich zu tun habe. Vielleicht muss ich Informationsveranstaltungen geben oder mich mit einzelnen Stakeholder treffen um das Projekt zu besprechen. Auch das sind Arbeitspakete, die innerhalb eines Projektstrukturplans erfasst werden sollten.

Wir können also dementsprechend davon ausgehen, dass sich Projektstrukturplan und ein Großteil der anderen Methoden, die ich anwende, gegenseitig beeinflussen. Der Projektstrukturplan wird vielleicht am Anfang erstellt, aber er wird im Laufe des gesamten Projektes überwacht und angepasst, wir müssen also von einer ständigen Modifizierung ausgehen.

Wer erstellt den Projektstrukturplan?

Eine häufige Frage ist, wer die Verantwortung dafür trägt, den Projektstrukturplan zu erstellen. Hierfür gibt es keine eindeutige Regelung, das heißt, es ist vollkommen frei. Logisch ist natürlich, dass die Person, die in die Erstellung des Projektstrukturplans involviert ist, am Ende auch für dessen Umsetzung verantwortlich ist. Aber je nach Projekt, muss das nicht immer die gleiche Person sein. Manchmal kann es auch eine Person sein, die für die Planung des Projektes verantwortlich ist, während eine andere Person für die Umsetzung verantwortlich ist. Wenn es jedoch möglich ist, sollte die Person, die für die Umsetzung verantwortlich ist, auf jeden Fall in die Planung involviert werden. Die umsetzende Person legt ja maßgeblich fest, wie sie das Projekt umsetzen möchten. Es führen gewöhnlich mehrere Wege zum Projekterfolg, aber nicht jeder Weg fühlt sich für jeden gleich gut an. Das hat mit persönlichen Präferenzen zu tun. Da Projektmanagement im Wording auch nicht immer eindeutig ist, z. B. in der Abgrenzung von Projektmanager zu Projektleiter, lässt es sich auch hier nicht eindeutig bestimmen.

Es kann also durchaus sein, dass der einzelne Projektmanager, aber auch der Projektleiter für die Erstellung des Projektstrukturplans verantwortlich ist. Was sich auf jeden Fall sagen lässt ist, dass die Person, die den Projektstrukturplan erstellt, über Verantwortungs- und Entscheidungsgewalt verfügen sollte. Manchmal wird diese Aufgabe auch an Zuarbeiter ausgelagert, also an Menschen, die in der Projektvorbereitung helfen und den Auftrag erhalten einen Projektstrukturplan zu erstellen. Dieser kann dann anschließend vom Entscheider oder der Entscheiderin begutachtet und diskutiert werden. Ebenso sinnvoll kann es sein, eine ganze Projektgruppe mit der Erstellung des Projektstrukturplans zu beauftragen. Somit sitzt nicht ein einzelner Mensch in einer dunklen Kammer und erstellt den Projektstrukturplan, sondern es gibt eine Gruppe, die sich aktiv damit auseinandersetzt. Dies kann beispielsweise in Form eines Brainstormings ablaufen, infolgedessen dann eine Strukturierung stattfindet. In diesem Fall wäre das z. B. sehr gut in der Bottom-up-Methode möglich. Es werden also erstmal alle möglichen Arbeitspakete gesammelt und diese dann strukturiert in Teilprojekte gepackt. Es geht aber auch in der Top-Down-Variante, bei der im Brainstorming erst einmal alle Teilprojekte gesammelt werden und dann im zweiten Brainstorming-Schritt die einzelnen Arbeitspakete pro Teilprojekt gefunden werden.

Nicht zu empfehlen ist, dass unterschiedliche Leute die Verantwortung für die Erstellung des Projektstrukturplans haben. Damit ist gemeint, dass während der Erstellung, die Verantwortlichkeiten wechseln. Zuerst arbeitet beispielsweise Herr Müller ihn aus, dann hat Herr Maier die Verantwortung ihn weiter zu bearbeiten, bevor Herr Schmidt die Verantwortung erhält ihn abzuschließen. Das ist nicht ratsam. Während des kompletten Planungsprozesses, sollte eine Person die Verantwortung für die Erstellung des Projektstrukturplans konstant innehaben.

Wie erstelle ich einen Projektstrukturplan?

Die Erstellung eines Projektstrukturplans ist wenig komplex. Das ist der Grund weshalb sich der Projektstrukturplan als Planungsmethode soweit durchgesetzt hat. Im Grunde genommen ist es recht einfach.

Es gibt drei unterschiedliche Verfahren:

• Top-Down
• Bottom-Up
• und das sog. Yo-Yo-Verfahren

Alle drei sagen einfach nur etwas über die Richtung aus.

Beim Top-Down-Verfahren arbeite ich mich von oben nach unten vor . Ich beginne also oben die Teilprojekte zu bilden und gehe dann runter in jedes Teilprojekt und in die einzelnen Arbeitspakete.

 

Bei der Bottom-Up-Variante versuche ich einfach alle Aufgaben, alle Arbeitspakete, alles was mir einfällt, erstmal zu sammeln. Wenn ich das habe, bringe ich es in eine Struktur, d. h. ich teile es im zweiten Schritt erst in die Teilprojekte ein.

Beim Yo-Yo-Verfahren gehe ich im Grunde genommen hin und her. Ich fange vielleicht unten erstmal mit sammeln an, dann mache ich ein paar Teilprojekte, sortiere diese schon mal, dann sammle ich weitere Arbeitsprojekte und mache wieder Teilprojekte.

Welches Verfahren besser ist, muss natürlich am Ende jeder für sich selbst entscheiden.

Meine Empfehlung geht eindeutig zum Top-Down-Verfahren. Ich finde es deutlich weniger chaotisch, viel strukturierter und damit für den Anfang auch einfacher durchzuführen.

Hierbei empfehle ich eine Reihenfolge von sechs Schritten :

1. Schritt: Sie fangen an die Teilprojekte zu identifizieren, d.h. Sie überlegen sich, aus welchen großen Bereichen besteht mein Projektstrukturplan. Das kann dann nach Phasen eingeteilt sein, nach Objekten oder nach Funktionen, das entscheiden Sie natürlich selbst. Wobei auch hier die Vorgehensweise nach Phasen oft ganz gut funktioniert.

2. Schritt: Sie legen als nächstes die Arbeitspakete fest, d.h. Sie gucken in jedes Teilprojekt und überlegen sich welche Arbeitspakete gehören dort rein. Was sind die großen Arbeitsschritte, die zu tun sind?

3. Schritt: Sie gehen über den nun entstandenen Plan und überlegen sich: Kann man Arbeitspakete in Teilbereiche zusammenfassen? Oder ist es notwendig für einzelne Arbeitspakete nochmal darunterliegend weitere Teilaufgaben zu erfassen?
Wenn Sie das gemacht haben, haben Sie inhaltlich erstmal alles erfasst.

4. Schritt: Legen Sie den Projektstrukturplan für 1-2 Tage weg. Denn Zeit ist wichtig, damit Sie darüber nachdenken können. Auch wenn Sie das vielleicht nicht aktiv tun, in ihrem Hinterkopf arbeitet es trotzdem und Sie werden merken, dass sich dieser Projektstrukturplan weiterentwickelt. Ihnen fallen immer noch weitere Arbeitspakete oder Teilprojekte ein, das heißt, Sie können ihn immer noch weiter ergänzen, das machen Sie dann im nächsten Schritt.

5. Schritt: Nun kommt die Überarbeitung. Sie nehmen sich den Projektstrukturplan zur Hand und überlegen sich wirklich konkret: Wo fehlen ihnen noch Arbeitspakete? Wo fehlen Ihnen noch Teilprojekte? Hierbei können Sie sich natürlich an vergangen Projekten orientieren. Schauen Sie, ob es schon mal Projekte in der Richtung gegeben hat und was in diesen Projekten gemacht wurde. Vielleicht finden Sie auch noch alte Projektstrukturpläne, in denen sie nachschauen können. Was oft vergessen wird, sind Maßnahmen des Projektmanagements, wie Steuerung und Controlling, Dokumentation oder Lessons Learned am Ende des Projekts.

6. Schritt: Mit anderen Leuten reden! Sie müssen unbedingt bezüglich des Projektstrukturplans mit anderen reden um sich aktiv Feedback einzuholen. In der Regel ist die Gedankenwelt von einer Person zu begrenzt um wirklich alles zu erfassen. Wenn Sie sicher gehen wollen, dass Sie alles haben, dann empfiehlt es ich auch andere zu involvieren, das heißt darüber gucken zu lassen, es einmal vorzustellen und zu fragen: Was fällt euch noch ein? Fehlen noch Teilprojekte? Fehlen noch Arbeitsprojekte?
Seien Sie nicht verwundert, wenn die anderen nicht sofort mit Ideen kommen. Manchmal muss das ein bisschen reifen. Wobei so ein Projektstrukturplan natürlich auch sehr erschlagend sein kann. Geben Sie den anderen noch 1-2 Tage Zeit und sammeln Sie dann noch einmal aktiv Feedback ein, ob noch jemanden was eingefallen ist. In der Regel werden Sie so immer nochmal drei, vier oder vielleicht auch mehr Arbeitspakete dazubekommen, die Sie vielleicht vorher vergessen haben. Vielleicht werden Sie auch nochmal kritisches Feedback kriegen, dass Sie ein Arbeitspaket in mehrere kleine Arbeitspakete einteilen sollen.

Die Erstellung eines Projektstrukturplans mit Power Point

Die Erstellung von Projektstrukturplänen in Power Point ist etwas, was ich nicht empfehlen kann. Trotzdem für all jene, die gerne Power Point nutzen möchten, erkläre ich folgend, wie man das am besten machen kann.

Der Grund dafür, warum ich dagegen bin, Power Point für Projektstrukturpläne zu nutzen, ist, dass es ein relativ ungünstiges Tool ist. Power Point ist zwar gut um visuelle Zusammenhänge darzustellen, wenn man kein hochwertigeres Grafiktool zur Hand hat oder dieses nicht bedienen kann, aber Projektstrukturpläne sind darin einfach durch die Variabilität nicht sinnvoll dazustellen. Denn jedes Arbeitspaket oder Teilprojekt mehr, zwingen einem auf dem Folienformat des Power Point immer kleiner zu werden. Die Kästchen, die für die Arbeitspakete oder Teilprojekte genutzt werden, verändern ein wenig ihr Format und das Zusammenspiel, wenn man sie nachträglich verkleinert. Verkleinern muss man sie aber, damit man genug auf die jeweilige Folie bekommt. Natürlich kann man alternativ mit einem vorgefertigtem Power Point-Projektstrukturplan arbeiten, in den man nur noch einträgt und aus dem man dann rauslöscht. Das ist eine Option, die durchaus denkbar ist, aber in der praktischen Erarbeitung ist es nicht sinnvoll, Power Point dafür zu nutzen. Falls Sie es trotzdem gerne nutzen möchten, finden Sie eine Vorlage mit leeren Kästchen anbei. Diese gibt es in unterschiedlichen Versionen, das heißt mit Arbeitspaketen, Teilbereichen, sowie Teilaufgaben und Sie können sie nutzen, um sie mit Ihrem Inhalt zu füllen.

Im Grunde ist es recht einfach. Sie fangen erstmal an, sich einen Zettel und Stift zu nehmen und sammeln die einzelnen Arbeitspakete und Teilprojekte. Wenn Sie das alles haben, beginnen Sie einfach nur noch in Power Point Kästchen aufzuziehen und ordnen diese passend zueinander an. Beispielsweise können Sie für die Teilprojekte, die oben stehen ein leicht anderes Format nutzen, z. B einen dickeren Rahmen oder eine andere Farbe, als bei den Arbeitspaketen. Wenn Sie das dann haben, sind Sie eigentlich auch schon fertig. Man hat hier durchaus den Vorteil, dass es sehr einfach ist. Sie können auch Kästchen bzw. deren Inhalt einfach austauschen oder hin und her schieben. Nur dann, wenn Ihr Projektstrukturplan wächst, also mehr Arbeitspakete oder Teilprojekte dazukommen, ist Power Point nicht geeignet. Sie sind in diesem Folienformat, was bedeutet, dass Sie auch nicht über dieses Folienformat hinausgehen können, sondern dann nachträglich alle Kästchen kleiner machen und neu zueinander ausrichten müssen. Also haben Sie relativ viel Formatierungsaufwand, wenn Ihr Projektstrukturplan größer wird, als das was grundsätzlich innerhalb von Power Point als Vorlage angelegt wurde.

Wenn Sie kein spezielles Programm für den Projektstrukturplan nutzen, geht meine Empfehlung eindeutig zu Excel. Mit Excel können Sie nämlich schneller und besser Projektstrukturpläne erstellen.

Wie erstelle ich einen Projektstrukturplan in Word?

Es gibt ein Programm, welches ich noch weniger für die Erstellung eines Projektstrukturplans empfehlen kann als Power Point, und das ist Word.

Word eignet sich in keiner Weise dazu, einen Projektstrukturplan zu erstellen. Natürlich hat es die mit inbegriffene Funktion visuelle Kästchen darzustellen und diese ähnlich wie in Power Point miteinander zu verbinden, aber es geht deutlich schlechter als beispielsweise innerhalb von Power Point. Deswegen macht es Sinn, wenn Sie diese Darstellungsform nehmen wollen, es doch lieber in Power Point oder Excel zu machen, wobei ich Excel auf jeden Fall empfehle.

Die andere Alternative ist, Sie wollen das Ganze nicht als Baumstruktur darstellen, sondern in tabellarischer Form. Auch dann empfiehlt sich jedoch Excel viel mehr als Word, weil Word ein reines Textverarbeitungsprogramm ist. Natürlich habe ich viele Formatierungsmöglichkeiten, wenn ich es aber tabellarisch darstelle, ist nun mal Excel die bessere Variante.

Also Word eignet sich auf gar keinen Fall zur Darstellung oder Entwicklung von Projektstrukturplänen. Lassen Sie deshalb lieber die Finger davon und nehmen andere Programme. Deshalb gibt es hier nun auch keine Vorlage, wie Sie in Word einen Projektstrukturplan erstellen können.

[thrive_leads id=’29658′]

Wie ist der Projektstrukturplan aufgebaut?

Der Projektstrukturplan besteht insgesamt aus drei Ebenen, wobei nicht immer alle drei Ebenen zum Einsatz kommen müssen.

Wir fangen ganz oben an mit der Ebene der Teilprojekte, darunter befindet sich die Ebene der Arbeitspakete und darunter wiederum kann eine Ebene von Teilaufgaben innerhalb von Arbeitspaketen sein. Es kann aber auch leicht anders strukturiert sein, sodass wir oben die Ebene der Teilprojekte haben, darunter gebündelte Arbeitspakete, also Teilbereiche innerhalb eines Teilprojektes und darunter dann die Arbeitspakete.

Bei einem sehr komplexen Projektstrukturplan ist es denkbar, dass es dann auch noch eine Ebene 4 gibt. Dies ist zwar eher unüblich, aber trotzdem denkbar. Stellen wir uns zum Beispiel vor, es gibt oben die Ebene der Teilprojekte, darunter gibt es die Teilbereiche, in den Teilbereichen gibt es Arbeitspakete, und in den Arbeitspaketen gibt es wiederum Teilaufgaben. Das ist natürlich ein sehr detaillierter Projektstrukturplan, was dann auch entsprechend viel Aufwand bringt ihn zu konzipieren. Grundsätzlich sei aber gesagt, das Standardformat, welches sehr oft benutzt wird, ist die Ebene der Teilprojekte und direkt darunter die Ebene der Arbeitspakete.

Für ein Teilprojekt können wir uns vorstellen, dass dies generell das große Projekt in einzelne Bereiche einteilt. Ein Beispiel:

 

Wir bauen ein Carport und denken in diesem Fall phasenorientiert. Erstmal muss also die ganze Planung gemacht werden, dann muss die Baufläche vorbereitet werden, dann muss er gebaut werden, dann wird er abgenommen. Damit habe ich dann schon meine vier Teilbereiche: Planung Vorbereitung, Bau und Abnahme. In jedem dieser Teilprojekte erarbeite ich dann meine Arbeitspakete, z. B. in der Vorplanung werde ich einen Kostenplan, Bauplan und einen Zeitplan erstellen. In der Vorbereitung werde ich das Material kaufen, die Fläche, auf die er gebaut wird, vorbereiten und die Maschinen ausleihen. Im Bau werde ich das Fundament gießen, das Holz stellen und das Dach bauen. In der Abnahme lasse ich dann eine Prüfung machen, vielleicht vom Bauamt, um es dann wirklich auch final abzunehmen. Damit habe ich dann letztendlich einen großen Meilenstein erreicht bzw. je nachdem, ob noch was folgt, das Projekt abgeschlossen .

Auch hier gilt im Grunde wie in allen Bereichen, dass diese Methode einen Mehrwert bringen muss. Sie müssen sich also nicht akribisch dranhalten, wie Sie diesen strukturieren. Sie müssen nicht zwangsläufig sagen, dass Sie Teilprojekte haben, darunter Teilbereiche, dann Arbeitspakete und darin Teilaufgaben. Sie können das beliebig variieren. In einem Projekt sagen Sie vielleicht, Sie haben fünf Teilprojekte und in jedem sind zehn Arbeitspakete. Dann macht eine feinere Gliederung wohl keinen Sinn. Manchmal sind Projekte aber auch so komplex und viel zu erfassen mit vielen Arbeitspaketen, dass eine feinere Untergliederung sehr wichtig ist. Nehmen wir z. B. an, Sie haben ein Projekt mit über 500 Arbeitspaketen in zehn Teilprojekten, das wären 50 Arbeitspakete pro Teilprojekte. Dies wird natürlich schnell unübersichtlich und es kann hier sinnvoll sein, eine weitere Ebene einzuführen, nämlich die Ebene der Teilbereiche. In der können Sie dann die einzelnen Arbeitspakete gruppieren.

Wie kann ein Projektstrukturplan orientiert sein?

Innerhalb des Projektstrukturplans haben wir von oben nach unten gelesen also die Teilprojekte und ihre jeweiligen Arbeitspakete. Jetzt gibt es natürlich noch die Möglichkeit, den Projektstrukturplan horizontal zu lesen, also beispielsweise von links nach rechts. Das ist abhängig davon, welche Orientierung dieser Projektstrukturplan hat.

Ein Format, was denkbar wäre, ist die sog. Objektorientierung. Nehmen wir an, wir haben ein Projekt, das sich in unterschiedliche Teilprojekte einteilen lässt, wie zum Beispiel bei einem Haus. Wenn wir ein Haus bauen, dann muss es ein Fundament geben, es müssen Wände gestellt, Fenster eingebaut und ein Dach aufgesetzt werden.

Bei der Objektorientierung lassen sich also genau diese Bereiche in Teilprojekte umsetzen. Es gibt das Teilprojekt Keller, das Teilprojekt Bodenplatte, das Teilprojekt Wände, das Teilprojekt Fenster und das Teilprojekt Dach. Und in jedem dieser Teilprojekte befinden sich dann die einzelnen Arbeitspakete.

Eine andere Alternative ist es, den Projektstrukturplan funktionsorientiert zu gestalten. Hier sehen wir uns die Organisationseinheit an, die vom Projekt betroffen ist oder dieses managt und überlegen, wie wir den Funktionsaufbau nutzen. Also z. B. haben wir ein Vertriebsprojekt, das durch mehrere Abteilungen geht, wie die Buchhaltung, den Vertrieb und die Geschäftsführung. Wir erfassen die einzelnen Arbeitspakete pro Funktionseinheit. Unser Teilprojekt ist in diesem Fall die Funktionseinheit. Das ist dann der funktionsorientierte Projektstrukturplan:

Das was für die meisten Menschen am organischsten, also am natürlichsten ist, ist der phasenorientierte Projektstrukturplan. Diesen können wir komplett von links nach rechts lesen. Das hatten wir eben beim Beispiel mit dem Bau des Carports: Erst die Planung, dann die Vorbereitung, dann der Bau und dann die Abnahme. Der Vorteil am phasenorientierten Projektstrukturplan ist natürlich, dass er unserer normalen Leserichtung entspricht, d. h. von links nach rechts und von oben nach unten. Innerhalb des einzelnen Teilprojekts von oben nach unten, über die Teilprojekte von links nach rechts. Jetzt ist aber das Problem, dass wir nicht immer phasenorientiert sein können oder zumindest nicht komplett. Vielleicht haben wir ein Teilprojekt, was sich auf einen bestimmten Funktionsbereich oder Objektbereich bezieht. Vielleicht müssen wir die Buchhaltung mitreinnehmen, aber damit es übersichtlicher ist, was die Buchhaltung machen muss, bekommt die ein eigenes Teilprojekt. Denn wenn wir der Buchhaltung dieses Projekt zeigen, möchten wir, dass sie sofort auf einen Blick erkennen, was sie zu tun haben. Natürlich könnten wir innerhalb des Projektstrukturplans ihre einzelnen Arbeitspakete hervorheben. Vielleicht ist es aber für uns insgesamt besser, wenn wir einfach rangehen können, den Projektstrukturplans vorzeigen und sie sehen das Teilprojekt Buchhaltung. Ansonsten gestalten wir den Projektstrukturplan phasenorientiert.

Oder es kann auch sein, dass eine Objektorientierung mit in die Phasenorientierung reinspielt. Wir haben beispielsweise nochmal einen einzelnen Bereich für die Bodenplatte, weil diese beim Carport so komplex ist, dass wir sie rausgelöst haben.

Dann ist hier Objekt- und Phasenorientierung gemischt. Deswegen ist die am häufigste verwendete Form eben auch der Mischplan. Dies ergibt sich z. B. auch, wenn wir zwar unsere Phasenorientierung haben, aber trotzdem das Projektmanagement nebenher läuft. Es passt dann eben nicht, das Controlling oder die Steuerung, welche wir als Arbeitspaket erfassen, ins jede einzelne Teilprojekt mit rein zu packen. Deswegen machen wir ein Teilprojekt -Strang, der sich Projektmanagement nennt. Hier kalkulieren wir z. B. 20 Std. für das Controlling, 100 Std. für die Projektsteuerung.

Denn das ist etwas, was wir auf jeden Fall innerhalb eines Projektstrukturplans erfassen sollten. Schließlich wollen wir ja am Ende unsere Leistung im Projektmanagement auch legitimieren. Dann ist der Projektstrukturplan natürlich nicht mehr phasenorientiert.

Es geht aber durchaus so, wie schon mehrfach erwähnt. Machen Sie das, was Ihnen einen Mehrwert bringt. In der praktischen Anwendung, kann Ihnen relativ egal sein, ob das Projekt nun objekt-, funktions- oder phasenorientiert ist. Wichtig ist, dass Sie verstanden haben, wie man einen Projektstrukturplan baut. Hier ist in der Regel die einfachste Variante, diesen von links nach rechts und von oben nach unten zu planen. Wenn Sie das machen, haben Sie eine Variante, die für andere leicht lesbar ist. Und darin liegt ja gerade der Vorteil eines Projektstrukturplans, dass Sie anderen zeigen können, wie ihr Projekt funktioniert und dann dementsprechend auch leichter Verständnis für Ihr Projekt erzeugen. Das gelingt Ihnen, indem Sie Ihren Projektstrukturplan so aufbauen, dass er für andere leicht lesbar ist.

Welche Formen des Projektstrukturplans gibt es?

Ein weiterer wichtiger Punkt im Aufbau des Projektstrukturplans ist die Frage, ob er als Baumstruktur oder tabellarisch dargestellt wird. Strukturell macht das für den Projektstrukturplan keinen Unterschied, weil wir trotzdem in der Logik von Teilprojekten und Arbeitspaketen bleiben. Es macht aber einen Unterschied in der weiteren Verwendung und in der Darstellung. d. h. je nach Programm muss ich mir die Frage schon im Vorfeld stellen. In Excel ist die Vorgehensweise maßgeblich unterschiedlich, während ich in anderen Projektmanagementsoftwares die Möglichkeit habe, es mir in beiden Formen gleichzeitig darstellen zu lassen. In der Baumstruktur haben wir das, was hier abgebildet ist.

Wir sehen oben den Titel des Projektes, darunter stehen dann die einzelnen Teilprojekte alle nebeneinander orientiert und darunter sehen wir wiederum die einzelnen Arbeitspakete, die sich ja auch nochmal in ihren Teilaufgaben aufsplitten können. Wenn wir das umdrehen würden, haben wir quasi eine Baumkrone mit den einzelnen Ästen als Verzweigung. Deswegen wird dies als Projektstrukturplan in einer Baumdarstellung bezeichnet.

Dem gegenüber steht der Projektstrukturplan in tabellarischer Darstellung. Dabei gehen wir so vor, dass wir eine Tabelle von oben nach unten gelesen haben. Im Grunde genommen ein- oder zwei-, maximal dreispaltig. Wir haben also obenstehend den Titel des Projektes, darunter den Titel des ersten Teilprojekts, dann kommen darunter alle Arbeitspakete dieses Teilprojekts, darunter dann das nächste Teilprojekt und wiederum alle Arbeitspakete dieses Teilprojekts, dann das nächste Teilprojekt mit seinen Arbeitspaketen usw. Das ist die übliche Vorgehensweise, wenn wir einen tabellarischen Projektstrukturplan erstellen. Wir könnten das natürlich auch aufspalten und leicht versetzter darstellen, so wie Sie es auch in der Übersicht sehen (nachfolgendes Bild).

Es gibt eine Spalte für Teilprojekte, eine Spalte für Teilbereiche, eine Spalte für Arbeitspakete, eine Spalte für Teilaufgaben. Je nachdem, wie Sie es machen wollen. In der einfachsten Variante gibt es einfach nur zwei Spalten, also die Teilprojekte und Arbeitspakete, aber es bleibt dabei, dass es untereinander geschrieben wird.

Warum gibt es nun diese zwei Formen?

Die tabellarische Form ist in sich wenig übersichtlich, wodurch sie eindeutige Darstellungsnachteile gegenüber der Baumstruktur hat. Die Baumstruktur ist dann besonders vorteilhaft, wenn ich sie anderen zeigen möchte. Also wenn ich von anderen möchte, dass sie die Struktur meines Projektes verstehen. Das mag im ersten Augenblick ein wenig komisch klingen, aber die Struktur eines Projektes ist wirklich etwas, was man verstehen kann, also wie das Projekt in sich aufgebaut ist. Ich kann in dieser Baumdarstellung hervorheben, was beispielsweise die risikobehaftesten Arbeitspakete sind. Ich kann aber auch darstellen, welche die relevantesten, komplexesten oder die mit dem meisten Aufwand sind. Dies ist natürlich auch in der tabellarischen Variante möglich, aber i. d. R. kann es von einer dritten Person in der Baumstruktur leichter gelesen und erfasst werden.

Die tabellarische Struktur hat aber einen ganz essentiellen Vorteil. Denn sie ist der Vorschritt des Gantt-Diagramm, dem Ablaufplan. Wenn ich also zu diesem Ablaufplan übergehen möchte, brauche ich auf jeden Fall eine tabellarische Darstellung und deswegen gibt es Projektmanagementsoftware, die genau das kann. Sie kann einmal die Baumstruktur darstellen, aber auch die tabellarische Form. In Online-Software finde ich das aktuell leider noch nicht. I d. R. sind das dann Programme wie MS Project oder ähnlich spezifische, die in ihrer Grundfunktion rechnerbasiert sind und über einen Server zugreifbar gemacht werden können. Die einfachen Cloud-Lösungen, wie Trello oder Kanban Flow, können das noch nicht. Mir kann also bewusst sein, dass die tabellarische Form jedem Gantt-Ablaufplan zugrunde liegt, da ich hier die einzelnen Arbeitspakete in ihren Teilprojekten gegliedert untereinander stehen habe. Das ist die Grundlage für die Gestaltung eines Ablaufplans.

Warum ein phasenorientierter Projektstrukturplan?

Ich höre häufig die Frage, warum genau der phasenorientierte Projektstrukturplan an vielen Stellen bevorzugt wird. Ich glaube, das hat genau genommen mit zwei Dingen zu tun.

Zum einen ist der Mensch an sich sehr zeitlich orientiert. Wir überlegen, was wir nacheinander tun können: Heute morgen werde ich erst aufstehen, dann werde ich meine Zähne putzen, dann gehe ich duschen, dann ziehe ich mich an, dann frühstücke ich und dann verlasse ich das Haus. Zur gedanklichen Strukturierung gehört es, ungeordnete Abläufe in eine geordnete Abfolge zu bringen. Das ist ja auch das, worauf ein Ablaufplan hinausläuft, nämlich Arbeitspakete in die richtige Reihenfolge zu bringen. Deswegen bietet es sich an, dies schon bei der Erstellung des Projektstrukturplans zu beachten. Die richtige Abfolge also zu berücksichtigen, die Teilprojekte somit in die richtige Reihenfolge zu bringen und dementsprechend auch die Arbeitspakete zu sortieren. Das geht nicht immer, weil noch eine gewisse Objekt- oder Funktionsorientierung mit enthalten ist und es wird deshalb dann meistens eine Mischform als Projektstrukturplan. Häufig ist der klar zu erkennende Anteil jedoch gerade diese Phasenorientierung.

Der zweite Grund, erscheint mir, liegt vor allem in unserer Leserichtung. Wir sind es in unseren Kulturkreisen gewohnt, von links nach rechts zu lesen. Infolgedessen bauen wir auch die Phasen von links nach rechts auf, weil wir wollen, dass der Projektstrukturplan in sich lesbar bleibt. Das ist nichts was wir aktiv steuern, sondern eher etwas was unbewusst passiert. Wir bauen den Projektstrukturplan also so auf, dass wir ihn gut von links nach rechts, also die Abfolge der Teilprojekte in Phasen, und von oben nach unten, die Arbeitspakete in Reihenfolge nacheinander, lesen können . So ergibt sich dann ein Projektstrukturplan, welcher genauso komplett lesbar ist, wie jedes andere Blatt Papier, von links nach rechts und von oben nach unten.

Gleichzeitig erleichtert uns, diese Art den Projektstrukturplan zu erstellen, auch wiederum die Erstellung von Projektphasen. Denn Phasen können über unterschiedliche Projekte hinweg ähnlich sein, müssen es aber nicht. Ein Projekt kann nämlich durchaus auch in andere Phasen unterteilt sein als beispielsweise ein ähnliches anderes Projekt. Hierbei können die Phasen 1:1 wie die Teilprojekte gewählt sein: Vorrecherche, Planung, Vorarbeit, Umsetzung, Kontrolle und Nacharbeit. Das könnten unsere Teilprojekte sein, die gleichzeitig unsere Projektphasen darstellen und mit Meilensteinen, also besonderen Ereignissen, voneinander getrennt sind.

Wie detailliert sollte der Projektstrukturplan sein?

Ein Projektstrukturplan kann von vollkommen grob bis extrem detailliert reichen. Dabei ist es schwer eine pauschale Aussage zu treffen, was gut ist. So kann es in einem Projekt besonders gut sein, sehr detailliert zu arbeiten, während es in einem anderen Projekt besonders gut sein kann, sehr grob zu arbeiten. Die Entscheidung darüber steht in engem Zusammenhang mit der Komplexität des Projektes und der Erfahrung der Projektleitung. Wenn Sie eine/n sehr erfahrene/n Projektleiter/in mit einem Projekt beauftragen, das nur wenig komplex ist, kann es sich anbieten, einen sehr groben Projektstrukturplan zu entwerfen. Wenn Sie allerdings in der Projektleitung wenig Erfahrung haben, v. a. mit dieser Art von Projekt, aber das Projekt gleichzeitig sehr komplex ist, kann es Sinn machen, den Projektstrukturplan extrem detailliert zu halten. In der Regel werden Projektstrukturpläne, die detailliert sind, auch mehr Ebenen ausweisen. Es wird also vielleicht noch eine Ebene der Teilbereiche und eine Ebene der Teilaufgaben eingeführt, was Sie in Ihrem standardmäßigen Projektstrukturplan vielleicht nicht haben. Dieser besteht vielleicht nur aus Teilprojekt und Arbeitspaket.

Bedenken Sie aber immer, dass die Lesbarkeit im Vordergrund stehen sollte. Ein Projektstrukturplan, der unheimlich detailliert ist und jede kleine Möglichkeit erfasst hat, ist ein schöner Gedanke. Wenn er aber so komplex wird, dass keiner ihn mehr liest, dann bringt er keinen Mehrwert mehr. Den Mehrwert eines Projektstrukturplan haben wir nur, wenn er es schafft, uns die Struktur des Projektes zu vermitteln, wenn er uns also hilft den Überblick zu behalten und das Projekt stückweise abzuarbeiten. Sobald er diese Funktion nicht mehr erfüllen kann, beispielsweise aufgrund zu hoher Detaildichte oder auch dadurch, dass er zu grob gehalten ist, muss nachgearbeitet werden. Dies kann entweder dadurch passieren, dass Inhalte rausgenommen werden oder er entsprechend detaillierter gestaltet wird. Hier macht es Sinn, das Projektteam zu involvieren und kritisch zu schauen, ob wirklich alles oder vielleicht auch zu viel erfasst wurde.

Meine Erfahrung der letzten Jahre zeigt, dass es da sehr deutliche Tendenzen gibt. Entweder Sie entwerfen einen Plan der gut passt oder es ist wirklich ein Plan, der viel zu wenig enthält, der so grob ist, dass er kaum noch Mehrwert bietet. Dies ist auch der Fall, wenn der Projektstrukturplan so komplex ist, weil Sie so viele Details erfasst haben, dass man ihn gar nicht mehr auf einen Blick greifen kann, dass er eben derart schwer zu erfassen geworden ist. Das braucht am Anfang ein wenig Übung und deswegen ist es wichtig, dass Sie andere Menschen involvieren. Holen Sie sich aktiv das Feedback ein, ob der Projektstrukturplan gut zu lesen ist, ob Inhalte fehlen oder zu viele unnötige Inhalte erfasst wurden.

Ob Sie den Projektstrukturplan zu grob, genau richtig oder zu detailliert halten, wird auch mit Ihrer Erfahrung im Zusammenhang stehen. Haben Sie also noch wenig Erfahrung in einem Bereich, kann es sein, dass Ihnen einfach ganz viele wichtige Dinge entgehen oder Sie gar nicht genug Wissen haben um den Projektstrukturplan überhaupt genug zu füllen. Wenn Sie hingegen über sehr viel Fachwissen zu dem Thema verfügen, aber bisher wenig Projekte geleitet haben, dann besteht eine gewisse Wahrscheinlichkeit, dass Sie den Plan zu detailliert erstellen werden. Sie wissen nämlich genau, welche Schritte alle notwendig sind und aus der Sorge, relevante Schritte zu vergessen, gehen Sie dann so vor, dass Sie jedes kleine Detail erfassen. Auch hier hilft es, externes Feedback einzuholen, sobald Sie den Plan erstellt haben.

[thrive_leads id=’29658′]

Was sind Arbeitspakete innerhalb eines Projektstrukturplans?

Man könnte sagen, Arbeitspakete sind am Ende das, was zu tun ist, also der Inhalt dessen, was wir da eigentlich machen wollen. Im Rahmen eines Arbeitspakets kann man relativ viel erfassen:

• was zu tun ist
• wie lange es von Anfang bis Ende dauert, also wie viel Zeit in Stunden
• wie viel Geld investiert werden muss
• wer dafür verantwortlich ist
• wer es ausführt
• welche Ressourcen benötigt werden

und noch viele weitere Kennzahlen.

Das betrachten wir aber näher, wenn wir wirklich die einzelnen Arbeitspakete angucken. Innerhalb eines Projektstrukturplans sind Arbeitspakete relativ einfach, denn hier findet man im Grunde genommen nur die Titel der Arbeitspakete. Wenn es beispielsweise darum geht, ein Büro umzuziehen, kann ein Arbeitspaket „Kartons packen“ sein. Unter diesem Titel kann sich natürlich alles verstecken. Trotzdem bleibt es im Projektstrukturplan erst einmal so, dass wir dort nur Kartons packen reinschreiben. In einer detaillierten Beschreibung vom Arbeitspaket erfassen wir natürlich noch viel mehr. Ob wir diese detaillierte Beschreibung überhaupt machen, hängt aber von unserem Projekt und der Notwendigkeit ab. Gerade bei so einem praktischen Projekt, wie einem Umzug ist es unwahrscheinlich, dass wir diese Arbeitspakete so stark ausformulieren. Aber wichtig ist, innerhalb eines Projektstrukturplans gibt es nur den Titel und unter Umständen Kennzahlen, das können Sie aber nochmal unter Kennzahlen nachlesen.

Das heißt, große Aufgaben, die zusammengehören, stellen ihre Arbeitspakete dar. Sie überlegen sich also, welche großen Aufgaben es innerhalb eines Teilprojektes gibt. Dabei ist die Abgrenzung zu Teilaufgaben natürlich schwierig. Ein einzelnes Arbeitspaket kann nämlich aus unterschiedlichen Teilaufgaben bestehen und die Abgrenzung kann einem durchaus schwerfallen. Wir gehen aber davon aus, dass ein Arbeitspaket eine Zusammenstellung unterschiedlicher Teilaufgaben ist, also mehr als einen einzelnen Schritt erfordert und auch in sich nochmal eine gewisse Komplexität aufweist. Nehmen wir an, wir suchen ein neues Mietobjekt, dann wäre die Recherche ein Arbeitspaket. Innerhalb der Recherche können wir davon ausgehen, dass es mehrere Teilaufgaben gibt: Ich muss erstmal die Anforderungen klären, die es an das Mietobjekt gibt, ich muss einen ersten Recherchevorgang machen, ich werte diesen aus, zeige und bespreche es mit jemanden, dann mach ich den zweiten Recherchevorgang, zeige und bespreche es mit jemanden. Am Ende habe ich vielleichtnach drei oder vier dieser Durchgänge zehn Mietobjekte zusammen, die ich mir dann im weiteren Arbeitspaket angucken könnte. Daran sieht man schon, dass einzelne Arbeitspaket ist etwas komplexer.

Natürlich können wir auch hier entscheiden, dass wir z. B. die Anforderungen an das Mietobjekt wieder in ein davorliegendes Arbeitspaket ausgliedern. Ein Arbeitspaket ist dann „Anforderungen an Mietobjekt definieren“, das zweite Arbeitspaket ist „nur noch“ die Recherche.

Daran merken Sie schon, es liegt in Ihrer Hand, wie fein oder grob Sie das machen. Ich empfehle Ihnen, erstmal relativ grob anzufangen, wenn Sie noch keinen Projektstrukturplans angelegt haben. Wenn Sie merken, dass es zu grob ist und Sie nicht wissen was Sie machen müssen, dann teilen Sie es auf. Erfassen Sie einfach innerhalb des Arbeitspakets noch Teilaufgaben oder stricken Sie die Arbeitspakete insgesamt kleiner.

Woher weiß ich, ob ich alle Arbeitspakete erwischt habe?

Sie können nicht wissen, ob Sie alle Arbeitspakete erwischt haben. Das ist etwas, mit dem Sie lernen müssen umzugehen. Es bleibt immer eine gewisse Restungewissheit, ein Restrisiko.

Sie können also nicht wirklich sagen, ob Sie alle Arbeitspakete bedacht haben, aber Sie können durchaus Maßnahmen treffen, um dieses Risiko zu minimieren. Hierzu zählt vor allem, mit anderen Menschen darüber zu reden, ihnen Ihren Projektstrukturplan zu zeigen und Ideen einzuholen. Das können fachspezifische Menschen sein, die vielleicht schon mal so ein ähnliches Projekt durchgeführt haben. Das können aber auch Fachfremde sein, die natürlich mit einem ganz anderen Blickwinkel auf so ein Projekt gucken und ganz interessante Ideen beisteuern können. Diese können Ihnen somit nochmal neue Perspektiven geben, an die Sie vielleicht vorher nicht gedacht haben.

Hierbei gilt die Grundregel: Je mehr, desto besser. Natürlich müssen Sie irgendwann eine Grenze ziehen, aber Sie können einen Projektstrukturplan je nach Größe schon mit fünf bis zehn Personen besprechen. Sie können ihn auch in der Gruppe vorstellen und sich ein Gruppenfeedback einholen. Dabei macht es natürlich auch Sinn, dass nicht nur geguckt wird, fehlen Arbeitspakete, sondern sind manche Arbeitspakete vielleicht zu groß oder zu klein gehalten. Wobei zu klein eher seltener der Fall ist, aber zu groß kommt durchaus vor. Macht es also an der ein oder anderen Stelle Sinn ein Arbeitspaket in mehrere Arbeitspakete aufzuteilen.

Was Sie Alternativ machen können: Wenn Sie zwar Feedback von anderen haben wollen, aber das Gefühl haben, wenn Sie denen einen Projektstrukturplan vorlegen, diese dann so gehemmt sind, dass sie auf gar keine Ideen kommen, dann lassen Sie doch die Anderen einen Projektstrukturplan erarbeiten. Wenn das nicht mit viel Sorgfalt passieren muss, ist das keine aufwendige Sache. Das kann man in einer halben bis zu einer Stunde schaffen – je nach Projektgröße. Dementsprechend könnten Sie den Projektstrukturplan erstellen lassen und bekommen damit strukturell auch nochmal neue Ideen, da jemand anderes vielleicht ganz anders rangeht als Sie. Vielleicht haben Sie einen phasenorientierten Plan gemacht, jemand anderes macht einen funktionsorientierten Plan. Dieser scheint ja vielleicht viel mehr Sinn zu ergeben, als ihr phasenorientierter. In diesem Fall bietet es sich also wirklich an, andere zu involvieren und diese parallel nochmal den gleichen Plan erstellen zu lassen. Wenn Sie 80% Deckungsgleichheit zu drei anderen haben, dann wissen Sie, dass sie wahrscheinlich schon mal in die richtige Richtung gedacht haben. An den restlichen 20% sehen Sie, was Sie vielleicht noch vergessen haben.

Wie verwende ich Kennzahlen in einem Projektstrukturplan?

Kennzahlen sind etwas Wunderbares. Sie geben uns mit ganz wenigen Zeichen oder Zahlen eine Auskunft darüber, wie der Stand in einem Projekt ist oder wie er sein soll, denn gewöhnlich haben wir einen Soll-Ist-Vergleich, insofern das Projekt läuft. Am Anfang, also in der Projektplanung, gibt es natürlich erstmal nur das Soll, aber später ergibt sich dann auch das Ist. Als Beispiel: Wir planen ein, dass im Rahmen unseres Projektes zur Autobahnüberwachung 100.000 km gefahren werden sollen. Es läuft über 10 Monate, es sollen also monatlich 10.000 km gefahren werden. Wir sehen nach drei Monaten in den Projektstrukturplan und erkennen, dass insgesamt schon 50.000 km gefahren worden sind. Wir können daraus den Rückschluss ziehen, dass wir entweder schneller als gedacht sind, weil wir mehr schaffen oder dass wir mehr Kilometer brauchen als eigentlich geplant. Beides sind unter Umständen Punkte, bei denen wir steuernd eingreifen müssen, abhängig vom jeweiligen Projekt natürlich.

Aber die Kennzahl ermöglicht es uns, diesen Projektstrukturplan mit Leben zu füllen und gibt uns sehr viele Auskünfte über das Projekt. Jetzt stellt sich natürlich die Frage: Was für Kennzahlen kann ich erfassen? Wie kann ich diese erfassen? Mache ich das mit einem Projektstrukturplan in der Baumform oder im tabellarischen Format?

Was für eine Form des Projektstrukturplans ist besser?

In der Baumdarstellung habe ich den Vorteil, dass es übersichtlicher bleibt. Ich sehe die einzelnen Teilprojekte besser, ich sehe die Arbeitspakete in der Regel besser und kann die einzelnen Kennzahlen daran erfassen. Hier komme ich aber zu einem praktischen Problem: Wie mache ich das? Nehmen wir an, Sie nutzen eine reine Papiervariante, wie Karteikarten an einer Wand klebend. Dann müssen Sie jedes Mal, wenn sich eine Kennzahl ändert, wie z. B. die investierte Zeit, einen neuen Post-it darüber kleben. Das verschwendet einerseits natürlich viel Papier, kann aber in einem Projektteam, das real zusammensitzt, total praktisch sein, weil jeder mitbekommt wenn sich Sachen im Projektstrukturplan ändern. Schon alleine dadurch, dass jemand aufsteht zur Wand hinläuft und etwas anklebt.

Die zweite Möglichkeit ist, dass Sie es in Excel machen. Hier ist es jedoch in der Baumstruktur relativ aufwendig den erstmaligen Projektstrukturplan auch wirklich zu bauen, was aber nicht dagegen spricht es zu machen. Sie müssen nur vorher beachten, was Sie alles für Kennzahlen mit reinnehmen. Sie können Ihren Projektstrukturplan dann einmalig als Vorlage erstellen und diesen dann pro Projekt „nur noch“ ausfüllen und Ihre Kennzahlen eintragen. Der Vorteil ist, dass Sie mit den Kennzahlen rechnerisch und kalkulatorisch weiterarbeiten können, wie beispielsweise gebrauchte Stunden, Kosten oder Kilometer summieren.

Die dritte Variante ist, Sie verwenden ein Programm, das Ihnen das direkt mit anbietet. Sie können die Daten also direkt in der Baumstruktur erfassen. Dies hängt aber natürlich vom benutzten Programm ab. Meiner Erfahrung nach, teilt sich die Welt hierbei in zwei, drei Lager:

• Freunde der Onlinenutzung, also Systeme wie Kanban Flow, Trello oder ähnliche: Diese haben in der Baumansicht in der Regel nur einen begrenzten Nutzen von Kennzahlen inkludiert, also z. B. Zeitangaben. Diese können aber oft auch nicht summiert werden, sondern nur pro Arbeitspaket gesehen werden.
• MS Project Fans: Diese arbeiten gewöhnlich in lokalen Teams oder nutzen es über einen Exchange-Server
• Leute, die noch kein System haben oder aber ein kostenfreies verwenden, wie z. B. Gantt-Project oder Excel

Die andere Variante neben der Baumdarstellung ist die Nutzung der Kennzahlen im tabellarischen Format. Hier haben wir einen immensen Vorteil. Wir wissen ja schon, dass wir die tabellarische Darstellung in den Gantt-Plan übernehmen können, also dadurch die gleiche Struktur nutzen. Jetzt können wir in der tabellarischen Darstellung einfach Spalten ergänzen. Es gibt eine Spalte für Anfang, eine Spalte für Ende, es gibt eine Spalte für investierte Zeit Soll und investierte Zeit Ist, eine Spalte für Kosten Soll und Kosten Ist, usw.! Man kann in der tabellarischen Darstellung immer weitere Spalten einfügen, insofern man hierfür Excel nutzt. Falls man es in einem Projektmanagementtool macht, muss man gucken, ob es diese Möglichkeit gibt.

Was für Kennzahlen erfasse ich?

Wie Sie wahrscheinlich schon rausgelesen haben, ist es immer sinnvoll die Zeit zu erfassen, also wann fängt ein Arbeitspaket an, wann hört es auf. Diesbezüglich sollte man auch die benötigte Kapazität eintragen, wie viele Stunden sind geplant, wie viele Stunden brauche ich wirklich? Das macht man im Grunde genommen mit jeder Ressource, die für ein Arbeitspaket benötigt wird. Wenn Sie Laptops brauchen, dann macht es somit vielleicht Sinn reinzuschreiben, dass drei Laptops benötigt werden (Laptops: 3). Vielleicht brauchen Sie aber auch Lizenzen, weil das Projekt daraus besteht, eine neue Modelinie zu erstellen. Sie haben im Unternehmen nur drei verfügbare Lizenzen und müssen deswegen im einzelnen Arbeitspaket des Projekts darstellen, wann die Lizenzen gebraucht werden. Werden in diesem jeweiligen Arbeitspaket zum Beispiel zwei Lizenzen benötigt, müssen Sie das bezogen auf die Ressourcen auch einplanen. Das ist zwar nicht wirklich eine Kennzahl, aber es ist trotzdem von der Ressourcenverknüpfung her höchst sinnvoll. Es kann auch sein, dass Sie die Kosten erfassen, wie hoch die Kosten also geplant waren und wie viel letztendlich angefallen sind. Ein anderes Beispiel ist, dass Sie Benzin einplanen müssen, wenn in Ihrem Projekt viel gefahren wird. Also wie viel Benzin zu diesem Zeitpunkt verbraucht sein soll, wobei Sie auch das wiederum natürlich in Kosten erfassen können. Sie können im Grunde jede Kennzahl nehmen, die Ihnen in den Sinn kommt.

Wie können Sie diese Kennzahlen erfassen?

Am meisten macht es wirklich Sinn, sie in Form von Zahlen zu erfassen. Mit Zahlen können Sie durch Rechenoperatoren nämlich sinnvoll weiterarbeiten. Sie können addieren, subtrahieren und somit auch den Projektfortschritt erfassen. Sie können also sagen, wie viel Anteil ein einzelnes Paket am Projektfortschritt hat. Denn das muss nicht zwangsweise 1:1 mit der investierten Zeit übereinstimmen. Ein einzelnes Arbeitspaket kann sehr viel Zeit kosten, kann aber das Projekt wenig voranbringen. Das ist ein wenig schwer vorzustellen, aber hierzu ein Beispiel. Unser Projekt ist es eine große Messe zu veranstalten, während dieser Messe machen wir dann eine Schaumparty. Die Reinigung dieser Schaumparty ist so ziemlich das aufwendigste, was wir zu tun haben, also das Arbeitspaket mit dem meisten Zeitaufwand. Trotzdem ist es ja nur die Nacharbeit, das Projekt ist zu 95% geschafft, wenn die Messe abgeschlossen ist. Aber auch wenn das Reinigen am Ende die meiste Zeit ausmacht, liegt der Hauptschwerpunkt des Projektes nicht auf der Reinigung. Dies können wir an der Verknüpfung zu den Zielen sehen. Ziel dieses Projektes wäre es ja nicht, eine besonders saubere Messehalle zu übergeben, sondern die Gewinnung der Kunden, die Zufriedenheit unter den Messebesuchern und weiteres. Unter diesem Gesichtspunkt sehen wir natürlich den Projektfortschritt auf das Ziel bezogen.

Deswegen ist der Projektfortschritt nicht immer synchron mit investierter Zeit, weshalb es Sinn machen kann, den Projektfortschritt prozentual einzeln zu erfassen. Hier habe ich natürlich die Möglichkeit zu sagen, ich habe fünf Teilprojekte. Das erste Teilprojekt nimmt fünf Prozent vom Fortschritt ein, das zweite sind dann 15 Prozent, das dritte nochmal 30% und die letzten beiden Teilprojekte sind jeweils 25% des Projektfortschritts. Dann kann ich nochmal in die einzelnen Arbeitspakete reingehen und zu jedem Arbeitspaket auch nochmal einen prozentualen Anteil vergeben.

Wenn ich dann alle diese Kennzahlen drinstehen habe, kann ich anschließend daraus einen Bericht extrahieren. Je nach Projektmanagementsoftware passiert dies halbwegs automatisch. In Excel muss man sich diesen einmal manuell anlegen. Dann habe ich einen aktuellen Bericht, anhand dem ich erkennen kann, dass unser Projekt beispielsweise zu 20% fortgeschritten ist. Wir wollten bis hierhin 5.000 € investiert haben, mussten aber bisher 15.000 € investieren und es ist schon 30% mehr Arbeitszeit angefallen als eigentlich geplant. Das hilft mir, mein Projekt in sich in Relation zu setzen. Ich kann also für mich sehen, wie viel Aufwand entstanden ist, bei wie viel Nutzen. Ist das Projekt in der Waage, sind Fortschritt und Investition gleich miteinander auf oder ist eines weiter vorangeschritten. Habe ich z. B. schon viel mehr investiert, bin aber nicht so weit vorangeschritten oder bin ich mit dem was ich an Ressource und Geld eingeplant habe, schon viel weiter als ich eigentlich gedacht habe.

Kennzahlen sind unerlässlich, wenn Sie den Projektstatus im Überblick haben wollen oder diesen für andere Leute darstellen möchten. Es empfiehlt sich auf jeden Fall, hier strukturell initial Zeit zu investieren und wenn es möglich ist, auch Geld um es visuell aufzuarbeiten. Das dient dazu, dass Sie einen Projektreport, einen Projektbericht, erstellen können, der gut aussieht. Denn am Ende sind für den Entscheider, dem Sie das präsentieren, nicht nur die Zahlen relevant, sondern es ist auch relevant wie es dargestellt wird. Das wird der einzelne vielleicht gar nicht mal bestätigen, und eher sagen, dass Sie hier nicht so viel Zeit reinstecken müssen, aber am Ende – und das unterschreibe ich Ihnen – wird es einen Einfluss haben. Dieser zeigt sich vielleicht unbewusst, aber wenn Ihr Projektreport gut aussieht, Sie so gut geplant haben, dass Sie Krisen berücksichtigt haben und diese auch zeitlich ausgleichen können, und Sie es schaffen innerhalb des Budgets pünktlich abzuschließen, dann wird das Gesamtbild abgerundet. Damit wird auch die Bewertung Ihrer Leistung runder. Das können Sie alles durch Kennzahlen erreichen.

Warum sollte ich Krisen in den Projektstrukturplan mit einplanen?

Das Einplanen von Krisen oder kleineren Katastrophen innerhalb eines Projektstrukturplans kann sehr vorteilhaft sein, weil es dafür sorgt, dass ich Puffer habe. Allerdings stellt es sich im Projektstrukturplan deutlich schwieriger dar, als zum Beispiel in einem Ablaufplan. In einem Ablaufplan kann ich Puffer mit einplanen, denn ich betrachte ja die Zeitachse. Diese Zeitachse betrachte ich im Projektstrukturplans nicht. Im Projektstrukturplans sehe ich nur das strukturelle Verhältnis von Arbeitspakten und Teilprojekten zueinander. Beim Ablaufplan habe ich die Zeitachse, das heißt von wann bis wann das einzelne Arbeitspaket oder Teilprojekt andauert. Hier kann ich natürlich Puffer einkalkulieren und sagen, dass ich für dieses jeweilige Arbeitspaket beispielsweise fünf Tage einkalkuliert habe, aber falls etwas schiefgeht, wir in Revision gehen oder das nochmal wiederholen müssen, nehme ich nochmal eine Woche extra rein. Aus fünf Tagen werden dann zwölf Tage oder vierzehn, falls ich das Wochenende auch berücksichtigen möchte.

Im Projektstrukturplan ist das Einkalkulieren von Zeitpuffern nicht wirklich möglich, sondern hier muss ich es als Arbeitspaket formulieren. Wenn ich also davon ausgehe, wir haben beispielsweise einen Werbebanner, der im Rahmen des Projektes erstellt werden soll, dann kann ich sagen, dass ich den Werbebanner als ein Arbeitspaket einplane. Ein zweites Arbeitspaket wird dann an die Revision, also an die Überprüfung des Werbebanners, vergeben. Das dritte Arbeitspaket ist wiederum das erneute anpassen, das vierte Arbeitspaket dann folgend die zweite Revision, das fünfte Arbeitspaket das zweite Anpassen und das sechste dann folglich die dritte Revision. Ich gehe davon aus, dass nach der dritten Revision, keine weiteren Anpassungen mehr notwendig sind, der Werbebanner also mit zwei Feedbackzyklen erstellt wird. Nach meinem zweiten Feedback muss ich ihn also nur noch einmal prüfen, wobei sich herausstellt, dass er so in Ordnung ist. Das muss natürlich auch zeitlich einkalkuliert werden, weil ich nun statt einem Arbeitspaket sechs Arbeitspakete habe. Ich könnte aber ebenso sagen, dass sich dieses Arbeitspaket Werbebanner in sechs Teilaufgaben gliedert: Erstellung, Revision, Anpassung, Revision, Anpassung, Revision.

Ich habe also unterschiedliche Entscheidungsmöglichkeiten. Ich kann dieses Arbeitspaket in mehrere Teilaufgaben teilen, aber es kann auch einfach mehrere Arbeitspakete geben. Wann ich welche Entscheidung treffe, hängt davon ab, wie viele Arbeitspakete drinstehen. Wenn Sie also im Teilprojekt drei, vier Arbeitspakete haben, können Sie diese auch entsprechend erweitern, dass es dann neun oder zehn werden. Haben Sie allerdings bereits 20 oder 30 Arbeitspakete im Teilprojekt stehen, macht es vielleicht mehr Sinn, wenn Sie eine Untergliederung in Teilaufgaben innerhalb eines Arbeitspaketes zu erstellen. Sie planen aber im Endeffekt schon ein, dass es gerade nicht beim ersten Mal schon perfekt sein wird. Das erstellte Banner hat also nicht gleich zu Beginn den optimalen Zustand, sondern Sie planen aktiv damit, dass Anpassungen notwendig sind. Das machen Sie nicht einfach, indem Sie im Ablaufplan pauschal einen Puffer von fünf Tagen einplanen, denn Zeitpuffer im Zeitablauf heißt ja nicht, Zeitpuffer im Sinne von Kapazität. Sie planen vielleicht ein, dass es fünf Tage länger dauert im Ablauf, aber Sie planen deswegen nicht automatisch mehr Kapazität ein. Da liegt eben auch der Teufel im Detail, denn wenn mehr Kapazität notwendig ist an Zeit, etwa aufgrund erneuter Revision oder Anpassungen, dann haben Sie natürlich auch eine Zeitnotwendigkeit. Diese ist aber nur im Ablaufplan mit drin, wenn Sie das auch in Arbeitspaketen erfassen, ansonsten übergeben Sie ja das Arbeitspaket Banner, haben aber gar nicht an die Möglichkeit einer Revision, und wie oft und wie viel da noch etwas getan werden muss gedacht, sondern sagen einfach nur, es könnte ja auch fünf Tage länger dauern. Da bringt es Ihnen aber am Ende nichts, dass Sie für den Gesamtablauf fünf Tage Puffer einkalkuliert haben, wenn Sie 20%, 30% oder sogar 50% mehr Zeitressource, der bearbeitenden Person benötigen. Natürlich kann man jetzt sagen: „Wir haben jetzt mit 50 Stunden kalkuliert, haben aber nur 30 gebraucht, das heißt, mein Mitarbeiter sitzt 20 Stunden rum“. Dies ist aber höchst unwahrscheinlich, da viele Mitarbeiter entweder noch in der Organisation oder anderen Projekten involviert sind. Im Regelfall sitzen diese also nicht den ganzen Tag rum und warten darauf, dass für das eine Projekt das eine Arbeitspaket gemacht werden kann. Diese Puffer können also letztendlich auch sinnvoll genutzt werden. Sie dienen sogar dazu, die gesamte Projektkultur ein wenig zu entspannen, weil nicht alles im Projekt komplett auf Anschlag geplant wird. Es empfiehlt sich somit, diese Krisen oder Probleme mit einzuplanen.

Das kann ich natürlich auch in anderen Schritten machen. Wenn ich beispielsweise ein Catering beauftragt habe und durch meine Risikoanalyse eine sehr große Wahrscheinlichkeit von rund 50 oder sogar 70% sehe, dass der Caterer absagt, plane ich das womöglich schon in meinem Projektstrukturplan mit ein. Diese Wahrscheinlichkeit kann ich auch anhand eines Ampelsystems darstellen, in diesem Fall wäre es quasi eine rote Eintrittswahrscheinlichkeit. Innerhalb des Projektstrukturplans gibt es dann vielleicht ein Arbeitspaket namens „Neuen Caterer suchen“, welches zur Not eben wegfällt.

Es ist in der praktischen Projektwelt nämlich immer leichter, Sachen wegfallen zu lassen, als diese dazu zu nehmen, denn Projektteams sind gewöhnlich durchaus am Limit geplant und sitzen nicht rum ohne was zu tun zu haben. Damit führt die spätere Einplanung weiteren Arbeitspaketen möglicherweise zu Verzögerungen innerhalb des Projektes. Ein Projekt hingegen mit realistischen Puffern zu kalkulieren, führt am Ende dazu, dass Sie auch in kritischen Situationen, trotzdem rechtzeitig fertig werden. Genau deshalb machen wir ja die Projektplanung, damit wir adäquat geplant und bestimmte Puffer im Vorfeld einkalkuliert haben und unseren Termin halten können.

Die wenigsten Projektauftraggeber sind verärgert, wenn Projekte vorher fertig werden. Sind wir zum Beispiel ein Produktionsunternehmen und haben ein Projekt, bei dem wir Waren liefern, dann haben wir diese Waren vielleicht rumstehen. Hier muss ich dann bei der Ressourcenplanung einkalkulieren, dass ich Lagerfläche brauche, falls wir zwei Wochen vor dem Termin fertig sind. Dies kann ich aber in der Regel leichter einkalkulieren als nachträgliche Zeit. Natürlich stellt es auch ein Problem gegenüber meinem Auftraggeber dar, denn ich muss ja nachverhandeln. Wenn ich mehr Ressource brauche, dann muss ich entweder diese nachverhandeln oder die Projektkosten erhöhen sich intern und ich erziele weniger Deckungsbeitrag bzw. letztendlich Gewinn mit dem Projekt. Egal, ob mein Auftraggeber intern oder extern ist, für meine eigene Erfolgsdarstellung als Projektmanager oder Projektleiter ist es natürlich höchstrelevant, Projekte zeitlich und finanziell so abzuschließen, wie sie auch kalkuliert sind. Wenn ich mit jedem Projekt reingehen kann und am Ende zu meinem Chef oder externen Auftraggeber sagen kann, dass wir schneller und günstiger fertig sind als kalkuliert, kann ich natürlich punkten. Gleichzeitig habe ich auf der Risikoseite diese Puffer drin, dass wir es selbst, wenn wir nicht schneller oder günstiger sind, durch solche Risikomaßnahmen schaffen, Krisen und Problemsituationen vorher mit einzukalkulieren, sodass wir trotzdem am Ende voll in unserem Projektrahmen sind.

Deswegen ist das Einkalkulieren von Krisen und kritischen Situationen innerhalb eines Projektstrukturplans eine Risikomaßnahme, die ich unbedingt empfehle.

Überwachung und Anpassung des Projektstrukturplans

Selten stimmt unsere Planung 1:1 mit der Realität überein. In der Regel haben wir eine Diskrepanz, das Projekt entwickelt sich also anders als wir eigentlich gedacht haben. Es kann sein, dass Arbeitspakete dazukommen, Dinge länger dauern, umfangreicher oder teurer sind als ursprünglich geplant. Das kann zwar begrenzt vorher mit einkalkuliert werden, aber halt nur begrenzt. Wir müssen davon ausgehen, dass während des Projektes Anpassungen im Projektstrukturplan notwendig sind. Das gleiche gilt natürlich auch für ein Gantt-Diagramm, denn hier müssen wir auch davon ausgehen, dass während des Projektes Anpassungen notwendig sind. Bei der Erstellung des Projektstrukturplans sollten wir also darauf achten, dass wir ein Format wählen, das sich gut anpassen lässt. Hier kommt Power Point beispielsweise schnell an seine Grenzen, weshalb ich dieses Programm nicht zur Erstellung des Projektstrukturplans empfehlen kann. Excel macht in diesem Fall noch relativ viel mit, und gewöhnlich können wir hier den Projektstrukturplan im Rahmen eines Projektes schnell und leicht anpassen. Je nach projektmanagementspezifischer Software, welche Sie nutzen, kann diese Umstellung auch leichter oder schwieriger sein.

Das Wichtige ist, dass Sie mit dem Projektstrukturplan ein Instrument haben, mit dem Sie Projektmanagement leben. Es geht nicht darum, einen Plan zu erstellen, den Sie dann in eine Schublade legen, sondern vielmehr darum diesen auszudrucken

und über den Monitor zu hängen. Das ist nämlich Ihr Projekt, vielleicht haben Sie auch mehrere Projekte gleichzeitig, dann hängen da auch mehrere Projektstrukturpläne. Es geht eben genau darum, den Plan nicht auf irgendeinen Server verschwinden zu lassen, sondern diese Art der Methode zu leben. Das bedeutet, sich den Projektstrukturplan stets vor Augen zu führen, ihn als Controllinginstrument zu nutzen, also ihn aktiv zu überwachen. Hier können Sie beispielsweise auch Arbeitspakete, die bald anstehen, orange markieren und solche, die überfällig sind, rot markieren, aber dann eben auch vollendete Arbeitspakte, grün markieren.

So wird sich ihr Projektstrukturplan über den Verlauf des Projektes verändern und immer einen klaren Status Ihres Projektes wiedergeben. Sie können also daran sehr gut überwachen, wie Ihr Projekt läuft. Dazu gehört aber auch die Notwendigkeit, diese Daten zu pflegen. Das ist ein Problem, das Sie generell im Projektmanagement haben. Wenn Sie aktuelle Daten haben und Projekte aktuell überwachen wollen, dann müssen Sie auch immer dafür sorgen, dass Sie diese Daten geliefert kriegen. Dann muss Ihnen jeder Projektmitarbeiter die Kosten und Zeiten übermitteln, sodass Sie stets einen aktuellen Status haben. Entweder die Mitarbeiter machen das tageweise selbst und die Daten werden automatisch übernommen oder die Daten werden Ihnen in einem Einheitsformat in einer Datei übermittelt, z. B. wöchentlich und Sie tragen diese dann wöchentlich in Ihren Projektstrukturplan ein. So können Sie einen Überblick über das Projekt halten und so kann auch der Projektstrukturplan dazu dienen, dass Sie das Projekt überwachen und im Gegenzug dann auch anpassen können.

Es gilt hier der Projektmanagementregelkreis: Planung – Kontrolle – Steuerung.

Sie legen also erstmal mit dem Projektstrukturplan Ihren Plan fest, Sie kontrollieren diesen darauf, ob er in der Realität auch wirklich funktioniert, und dann müssen Sie notfalls korrigierend eingreifen, das heißt Ihre Planung wieder anpassen. Wenn Sie also solch einen Plan ausgedruckt vor Ihnen hängen haben, werden Sie diesen wohl regelmäßig neu ausdrucken. Dies Plan also schön im Copy Shop auf DIN A0 ausdrucken zu lassen um ihn für das ganze Projekt dort hängen zu lassen, funktioniert nicht. Ihn regelmäßig wieder neu auszudrucken und hinzuhängen, ist etwas was wohl in der Realität wahrscheinlich stattfinden wird. Wenn Sie damit gut klarkommen, können Sie den Projektstrukturplan natürlich auch ausschließlich in einer Datei haben. Das müssen Sie sich überlegen, wobei die Erfahrung zeigt, dass vor allem bei so besonderen Dokumenten, diese Visualisierung in die Realität das Erfassen des Projektes deutlich einfacher macht.

Vom Projektstrukturplan zum Ablaufplan (Gantt-Diagramm)

Der Übergang von einem Projektstrukturplan in ein Gantt-Diagramm, auch bekannt als Ablaufplan, ist denkbar einfach. Die erste Frage, die Sie sich stellen müssen ist, ob Sie einen Projektstrukturplan im Baumformat oder in Tabellenform vorliegen haben. Beim Tabellenformat haben Sie natürlich ein einfaches Spiel, beim Baumdiagramm müssen Sie den Projektstrukturplan erstmal in ein Tabellenformat übertragen. Sobald Sie das gemacht und ein Tabellenformat haben, also alle Arbeitspakete untereinandergeschrieben, brauchen Sie nur noch zwei Spalten zu ergänzen. Das ist zum einen, wann das Arbeitspaket anfängt und zum anderen, wann das Arbeitspaket aufhört. Hier arbeiten wir in der Regel mit Tagen, also einem spezifischen Datum. Sollten Sie ein Projekt haben, bei dem es auf Stunden ankommt (z. B. 9 Uhr), sollten Sie das natürlich miterfassen. Generell rechnen wir aber wirklich nur mit spezifischen Tagen, beispielsweise 01.01., 02.01., 03.01.

Sobald Sie also den Anfangs- und Endzeitpunkt für ein Arbeitspaket erfasst haben, kann daraus die visuelle Achse des Ablaufplans generiert werden, also das Balkendiagramm. Damit haben Sie schon das Gantt-Diagramm in seiner einfachsten Form erstellt: Arbeitspaket, Anfangszeitpunkt, Endzeitpunkt. Natürlich bietet es sich an, hier dann noch Pufferzeiten zu ergänzen. Pufferzeiten sind überall dort angebracht, wo Sie denken, dort könnte es länger dauern als bereits geplant. Nur weil Sie sagen, ein Arbeitspaket findet zwischen Montag und Freitag statt, heißt es nämlich nicht, dass es dann auch wirklich schon abgeschlossen ist. Vielleicht sagen Sie, es könnte auch sein, dass es nicht schon am Freitag geschafft wird, sondern doch erst am Dienstag, deswegen kalkulieren Sie noch vier Tage Pufferzeit mit ein. Sie verschieben also das Ende des Arbeitspakets um vier Tage nach hinten. Eine andere Alternative ist, dass Sie zum nächsten Arbeitspaket, das auf dieses folgt, ein Leerraum von vier Tagen einplanen. Das erste Arbeitspaket soll zwar am Freitag abgeschlossen sein, aber das nächste Arbeitspaket, das darauf aufbaut, wird erst am Mittwoch begonnen. Der Nachteil daran ist natürlich, dass dann auch die Ressource für das zweite Arbeitspaket erst am Mittwoch zur Verfügung steht. Der Vorteil ist aber, dass das erste Arbeitspaket bestenfalls schon am Freitag abgeschlossen wird und nicht erst am Dienstag, weil im Plan steht, es muss erst Dienstag fertig sein.

An diesem Beispiel, sehen Sie aber, dass es relativ einfach ist, aus einem Tabellen Projektstrukturplan ein Gantt-Diagramm zu extrahieren. Sie müssen wirklich nur um zwei Spalten ergänzen, nämlich den Start- und Endpunkt für jedes Arbeitspaket. Wenn man dies zum Beispiel in Excel macht, lässt sich daraus relativ automatisch das Balkendiagramm erstellen. Dies geht natürlich auch mit kostenlosen Programmen wie Gantt-Project, sowie mit kostenpflichtigen Programmen.

[thrive_leads id=’29658′]