Beiträge

Wie man eine Projektstruktur erstellt – Teil 2

Dieser Artikel ist Teil 5 von 5 der Artikelserie Projektstruktur |

Als Fortsetzung zu meinem ersten Blogbeitrag zum Thema „Wie man eine Projektstruktur erstellt – Teil 1“ will ich heute auf das praktische Erstellen der Projektstruktur kommen: Mit welchen Mitteln oder Hilfsmitteln erarbeitet man sich eine Projektstruktur?

Schritt 1: Visuelles Erarbeiten

Am Anfang einer Projekstruktur arbeite ich meist an Pinnwänden mit Moderationskarten oder an Whiteboards oder Ähnlichem. Denn gerade beim ersten Erstellen einer Projektstruktur gibt es noch ganz viele Änderungen: Da müssen Arbeitspakete umbenannt oder einem anderen Teilprojekt zugeordnet werden usw., da ist man an der Pinnwand flexibler. Außerdem ist eine gemeinsame Arbeit an einer Pinnwand, an einem Whiteboard, viel aktivierender. Es gibt für mich nichts Schlimmeres, als wenn fünf Menschen gemeinsam in einem Raum sitzen und auf eine Leinwand starren, während einer mit einer Maus sich abmüht, ein IT-Tool zu bedienen – da passiert einfach nichts in den Köpfen. Ich bin ein Freund von gemeinsamem Arbeiten an der Pinnwand, weil ich gemerkt habe, dass ich dort viel schneller viel bessere Ergebnisse erziele.

An der Pinnwand entsteht also die erste Projektstruktur im Team, und dann gibt es den Punkt, an dem alle nicken. Dann weißt du, dass du eine relativ vollständige Projektstruktur hast. Vorneweg: Du wirst nie 100 Prozent Vollständigkeit erreichen. Aber 90 oder 95 Prozent sind für den Anfang schon einmal gut.

Schritt 2: Digitales Erfassen

An diesem Punkt beginne ich, alles digital zu erfassen. Dafür gibt es zwei brauchbare Instrumente. Zum einen Powerpoint. Da gibt es eine Organigramm-Funktion, die automatisch eine Baumdarstellung erstellt. Zum anderen kann man auch eine Mindmapping-Software verwenden, z. B. XMind (für Mac), es gibt aber auch andere Mindmapper, Mindmanager-Programme. Alle von ihnen können Baumstrukturen darstellen. Die Vorteile der digitalen Erfassung liegen auf der Hand: Ich kann ein Projektverzeichnis anlegen, ich kann die Projektstruktur verschicken, ich kann schnell Änderungen machen, ich kann es auch versionieren.

Wichtig ist mir dabei: Die Projektstruktur ist ein lebendes Dokument. Man darf keine Scheu haben, die Projektstruktur immer wieder anzupassen. Das Ziel der Projektstruktur ist, immer aktuell den Arbeitsumfang deines Projektes wiederzugeben. Und du kennst das: Projekte verändern sich, Projekte leben, und aus dem Grund wird sich auch die Projektstruktur mit verändern.

Wie man eine Projektstruktur erstellt – Teil 1

Dieser Artikel ist Teil 4 von 5 der Artikelserie Projektstruktur |

Zwar fällt es mit einer Projektstruktur leichter, ein passendes Team zusammenzustellen. Umgekehrt ist es aber auch sinnvoll, eine Projektstruktur mit einem Team zu erstellen, weil viele Köpfe einfach einen besseren Überblick über alle anstehenden Aufgaben entwickeln. In der Regel ist es so, dass du aufgrund der Aufgabenstellung schon relativ klar hast, wer in deinem Team dabei ist – und mit diesen Leuten erstellst du die Projektstruktur.

Projekte in Teilprojekte und Arbeitspakete herunterbrechen

Ich gehe in der Regel dabei folgendermaßen vor: Ich erarbeite zunächst einen Projektstrukturplan, also die Baumdarstellung. Diese ist sehr visuell und bietet eine gute Diskussionsgrundlage. Ich gehe einfach so vor, dass ich zunächst einmal den Namen des Projektes in das erste Kästchen ganz oben – also sozusagen in den Stamm des Baumes – schreibe. Und von hier aus gehe ich weiter. Ich sammle gemeinsam mit meinem Team die Themen, die im Projekt aufkommen werden, die Aufgaben, die wir bearbeiten müssen.

Ein Beispiel: Soll in einem Projekt ein mechatronisches Produkt entwickelt werden, dann habe ich mit Sicherheit ein Thema, das heißt „System“ – ich muss ja mehrere Bereiche zusammenbringen. Dann habe ich ein Thema „Mechanik“. Ich habe ein Thema „Hardware“, also Elektronik. Ich habe einen Themenbereich, der heißt „Software“. Ich habe auch das Thema „Versuch und Qualifikation“, dann auch „Produktion“, denn wir brauchen Produktionsprozesse, Montageprozesse usw. Weitere Themenbereiche sind „Markteinführung“ und auch „Projektmanagement“. Das ist jeweils die erste Ebene in meinem Projekt, und diese Ebene nennen wir Teilprojekt, Teilprojekte. Das heißt, wir haben ein Teilprojekt „System“, wir haben ein Teilprojekt „Mechanik“ usw. Meistens nummeriere ich die Teilprojekte durch. Das heißt „Projektmanagement“ bekommt die Nummer null – damit steht es ganz oben, auch später, wenn ich eine Tabelle erzeuge –,„System“ hat die Nummer eins, „Mechanik“ die Nummer zwei usw.

Wenn diese erste grobe Projektstruktur steht, dann beginne ich gemeinsam mit meinem Team, die einzelnen Teilprojekte weiter herunterzubrechen. Darüber steht immer die Leitfrage: „Was steckt da an Arbeit drin? Aus welchen Arbeitsschritten setzt sich das zusammen?“ Zum Beispiel für unser Teilprojekt Nummer fünf „Versuch und Qualifikation“ heißt das: Es steckt mit Sicherheit ein Prüfplan darin, das heißt, irgendeiner muss genau planen: „Was wollen wir alles prüfen und untersuchen?“ Dann gibt es das Arbeitspaket Prüflinge, jemand muss sich überlegen: „Wie viele brauche ich und wie müssen die zusammengestellt sein?“ Prüfereinrichtungen könnte die Nummer drei sein, wir brauchen eine Planung, auf welchen Prüfständen das gemacht werden muss, Prüfmittel, wir brauchen Messgeräte, Messwellen usw. Da würde ich schon die einzelnen Prüfungen grob auflisten, wir haben mit Sicherheit einen Dauerlauf usw. Diese Ebene – das ist jetzt die Ebene unter „Versuch und Qualifikation“ – unter den Teilprojekten, die nennt man Arbeitspakete. Das sind nun die Dinge, die ich gut einer Person zuordnen kann.

Stell dich der Komplexität

Gerade bei großen Projekten kommt man mit diesen zwei, drei Ebenen – also Projekt, Teilprojekt, Arbeitspaket – nicht aus, da ist mehr Struktur erforderlich, um die Arbeit vollständig und verständlich darzustellen. Ich verwende dann Kunstwörter wie „Hauptarbeitspaket“, „Teilarbeitspaket“, „Unterarbeitspaket“, einfach um jeder Ebene im Projektstrukturplan, jeder Ebene im Baumdiagramm auch einen Namen zu geben. Grundsätzlich gilt – und das ist mir ganz wichtig – komplexe Projekte werden nicht einfacher, wenn du die Augen zumachst, etwas weglässt und sagst: „Darum kümmern wir uns später.“ Jedes Projekt bringt seine Komplexität mit, und es ist deine Aufgabe, dich dieser Komplexität zu stellen.

Wie man die Projektstruktur gemeinsam im Team konkret erstellt, das verrate ich dir in meinem nächsten Blogbeitrag.


Du brauchst Hilfe bei der Erstellung einer Projektstruktur? Dann melde Dich in der Online-Bibliothek zum Projektmanagement im Maschinenbau an und hole Dir dort Vorlagen, Checklisten und Kurzlern-Videos zur Projektstrukturierung.

Online-Bibliothek zum Projektmanagement im Maschinenbau

 

Warum man eine Projektstruktur braucht

Dieser Artikel ist Teil 3 von 5 der Artikelserie Projektstruktur |

Es gibt für mich drei gute Gründe, warum ich in meinen Projekten immer eine Projektstruktur erstelle. Erstens: Vollständigkeit. Wenn ich sicher sein kann, dass ich alle Arbeiten eines Projektes erfasst habe, dann kann ich auch sicher sein, dass ich im Projekt keine oder nur ganz wenige Überraschungen erlebe. Wie oft ist es schon vorgekommen, dass Projekte deutlich länger dauern und teurer werden, als ursprünglich einmal geplant? Das passiert dann, wenn Arbeitspakete schlicht und ergreifend vergessen – oder manchmal auch bewusst ignoriert – werden.

Erst vor Kurzem habe ich ein Projekt in einer kritischen Phase übernommen. Und was habe ich dort festgestellt? In der Planung war die komplette Qualifikation nicht in der Projektstruktur (die gab es zu dem Zeitpunkt noch gar nicht), aber auch nicht im Terminplan berücksichtigt. Dabei ist offensichtlich, dass bei einem neuen Produkt, das in Serie produziert werden soll, eine Qualifikation erforderlich ist. Selbstredend bedeutet das einige Wochen Arbeit, mehrere Mann-Tage und Kosten …

Projektstruktur bedeutet Transparenz und Planung

Zweitens: Transparenz. Wenn ich alle Arbeitspakete definiert habe, dann kann ich mit meinem Team – vor allem auch mit meinem Auftraggeber – viel besser über das Projekt sprechen. Wenn ich alle Arbeitspakete habe, dann habe ich es deutlich leichter, in den Teambesprechungen meinen Fortschritt zu verfolgen. Ich habe dann eine Liste an Themen, die ich regelmäßig ansprechen kann, um sicherzustellen, dass an allem gearbeitet wird und ich regelmäßig eine Rückmeldung bekomme.

Drittens: Planungsgrundlage. Die Projektstruktur ist für mich der Ausgangspunkt für alle weiteren Planungsschritte. Wenn ich Arbeitspakete und Aufgaben habe, kann ich diese terminieren, die Projektkosten und das Projektbudget ableiten und das Team zusammenstellen. Ich habe mir einer Projektstruktur eine deutlich bessere Grundlage, ein Projekt so zu planen, das es stabil und richtig ist, also der Realität entspricht.

In der Praxis unterschätzt

Meiner Erfahrung nach wird in der Praxis zu wenig Zeit in eine gute Projektstruktur investiert. Ganz viele Projekte leben von Monat zu Monat, das ist die Sichtweite, die die meisten Projekte und die meisten Projektteams haben. Wenn ich frage: „Was ist als nächstes zu tun?“, dann bekomme ich meistens die Aufgaben des nächsten Monats aufgelistet – aber darüber hinaus hat keiner einen Überblick. Und diese Teams wundern sich dann, wenn sie Monat für Monat den Fertigstellungstermin verschieben müssen – weil keiner über diese Grenze hinaus geschaut hat, weil keiner den Überblick über alle Arbeitspakete hat und somit auch keine verlässliche Aussage machen kann.


Du brauchst Hilfe bei der Erstellung einer Projektstruktur? Dann melde Dich in der Online-Bibliothek zum Projektmanagement im Maschinenbau an und hole Dir dort Vorlagen, Checklisten und Kurzlern-Videos zur Projektstrukturierung.

Online-Bibliothek zum Projektmanagement im Maschinenbau

 

Der Projektstrukturplan: Übersicht über die Arbeit

Dieser Artikel ist Teil 2 von 5 der Artikelserie Projektstruktur |

Um eine Projektstruktur sinnvoll abzubilden, erstellt man einen Projektstrukturplan. Die Abkürzung dafür ist PSP. Falls dein Unternehmen SAP im Einsatz hat, kennst du das sicher, dann hast du für deine Projekte ein sogenanntes PSP-Element anzulegen. PSP-Element steht dabei für Projektstrukturplan-Element.

Einem Organigramm ähnlich

Von der Art der Darstellung ähnelt der Projektstrukturplan einem Organigramm, beide sehen aus wie ein umgedrehter Baum. Der Stamm ist oben, das ist im Organigramm meistens das Unternehmen, und darunter sind dann die Abteilungen und so weiter abgebildet. Aber Achtung: Das Organigramm stellt dar, wie eine Organisation funktioniert. Also: Wer ist wessen Chef? Welche Abteilungen besitzen wir? Wie ist bei uns die disziplinarische Weisungsbefugnis organisiert? Und in den Kästchen im Organigramm stehen in der Regel Abteilungsbezeichnungen und Personen.

Der wesentliche Unterschied

Im Projektstrukturplan dagegen steht in den Kästchen: Arbeit! Es stehen keine Personen oder Abteilungen drin, sondern: Arbeit! Das ist der wesentliche Unterschied, auch wenn die Darstellungsformen sich ähneln. Später mögen Abteilungen und Personen in der Darstellung hinzukommen, nämlich dann, wenn man die Aufgaben verteilt. Aber wichtig ist, dass zunächst die Arbeit, die Aufgaben möglichst präzise definiert und abgebildet werden.

Neben der Baumdarstellung gibt es noch eine andere Möglichkeit, eine Projektstruktur abzubilden: die strukturierte Tabelle, also eine tabellarische Darstellung. Hier wird der Projektstrukturplan in eine eingerückte, strukturierte Tabellenform gebracht. Diese Darstellungsform bietet sich an, wenn im nächsten Schritt Terminpläne und Kosten abgeleitet werden.

Unabhängig davon, welche Darstellungsweise man wählt: Der Projektstrukturplan erfasst die Arbeit in einem Projekt. Er bildet jede noch so kleine Aufgabe ab und strukturiert damit das gesamte Vorhaben.

Warum du eine Projektstruktur brauchst erfährst Du im nächsten Teil der Serie zur Projektstrukturierung.


Du brauchst Hilfe bei der Erstellung einer Projektstruktur? Dann melde Dich in der Online-Bibliothek zum Projektmanagement im Maschinenbau an und hole Dir dort Vorlagen, Checklisten und Kurzlern-Videos zur Projektstrukturierung.

Online-Bibliothek zum Projektmanagement im Maschinenbau

Projektstruktur: Die Mutter aller Instrumente

Dieser Artikel ist Teil 1 von 5 der Artikelserie Projektstruktur |

Die Projektstruktur ist eines der wichtigsten und wirkungsvollsten Instrumente im Projektmanagement. In meinen Seminaren werde ich immer wieder gefragt: „Was ist denn dein wichtigstes Instrument im Projektmanagement? Wenn du alles andere weglassen müsstest, was würdest du behalten?“ Meine Antwort ist in der Regel: “Die Projektstruktur.” Ich erstelle für jedes Projekt, und sei es noch so klein, eine ordentliche Struktur. Sie ist die erste und wichtigste Planungsgrundlage – die Mutter aller Instrumente.

In der Praxis selten eingesetzt

Ich beobachte oft, dass die Bezeichnung in den Unternehmen sehr willkürlich benutzt wird. Gelegentlich verwendet man den Begriff für die Zusammensetzung des Teams, ähnlich wie bei einem Organigramm. Manchmal wird auch eine Multiprojektliste so genannt, also die Übersicht über die laufenden oder anstehenden Projekte. Ich habe in den vergangenen Jahren einiges dazu gesehen und wirklich das Wenigste davon hat etwas mit der tatsächlichen Struktur eines Projektes zu tun. 

Was eine Projektstruktur wirklich ist

Eine Projektstruktur stellt alle Aufgaben, alle Arbeiten, die in einem Projekt anfallen, vollständig dar. Die Betonung liegt auf vollständig. Sie ist die Grundlage aller folgenden Aufgaben. Was hier nicht abgebildet ist, wird später sehr wahrscheinlich vergessen – wenn der Terminplan erstellt wird, Verantwortliche für Arbeitspakete gesucht und Kosten abgeleitet werden.

Die Projektstruktur ist für mich immer die Ausgangslage, das allererste, was zu tun ist, wenn ich ein Projekt aufplane. Auf dieser Basis und von hier aus folgen die weiteren Schritte. Wenn ich alle Arbeitspakete und Aufgaben vollständig erfasst habe, kann ich beginnen, diese zu terminieren und den Terminplan abzuleiten, dann die Projektkosten und das Projektbudget zu ermitteln. Wenn ich weiß, welche Aufgaben genau anstehen, kann ich passgenau das Projektteam zusammenstellen. Denn dann weiß ich ganz genau, für welche Aufgabe ich jemanden brauche und wie lange und mit welchem Aufwand. Mit einer guten Projektstruktur habe ich eine deutlich bessere Grundlage für eine stabile und realitätsnahe Projektplanung.

Dargestellt wird eine Projektstruktur im sogenannten Projektstrukturplan. Mehr dazu erfährst du in meinem nächsten Blogbeitrag.


Du brauchst Hilfe bei der Erstellung einer Projektstruktur? Dann melde Dich in der Online-Bibliothek zum Projektmanagement im Maschinenbau an und hole Dir dort Vorlagen, Checklisten und Kurzlern-Videos zur Projektstrukturierung.

Online-Bibliothek zum Projektmanagement im Maschinenbau

 

Episoden

PMMB028: Was mache ich als Projektleiter eigentlich die ganze Zeit?

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

Bestimmte Dinge erledigen wir als Projektleiter immer wieder. In dieser Episode erfährst Du, welche Aktivitäten ich täglich, wöchentlich, monatlich und ein Mal pro Quartal erledige.

Dazu habe ich natürlich auch eine Checkliste, die Du Dir in der Online-Binliothek herunterladen kannst: bibliothek.projektmanagement-maschinenbau.de

In dieser Episode lernst Du

  1. Warum ich eine Liste mit regelmäßigen Aktivitäten habe
  2. Was mache ich
    • täglich
    • wöchentlich
    • monatlich
    • pro Quartal

Episode, die ich im Podcast erwähne:

PMMB027: Experteninterview mit Ivan Blatter – So kannst Du Deine Zeit besser organisieren

PMMB002: In 5 Schritten zum Terminplan

PMMB001: Projektstruktur – Die Mutter aller Instrumente

PMB022: Wie ich mit der Musterroadmap meine Entwicklungsschritte plane

PMMB018: So ermittelst Du die Kosten Deines Projektes

PMMB011: Wieviel Aufwand benötigt Dein Projekt? – Ressourcenmanagement im Projekt

PMMB004: Die Sache mit den Risiken

PMMB008: Das Projektumfeld im Griff behalten

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB024: Das Geheimnis der Projektsteuerung – Meine 7 Fragen mit denen ich Projekte steuere

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

Projekte werden nicht nur geplant, sondern auch gesteuert. Projektsteuerung nimmt sogar den größten Teil der Projektlaufzeit ein. Aus diesem Grund ist es sinnvoll sich klar zu machen, was Projektsteuerung eigentlich beutet und wie das geht. In dieser Episode erkläre ich Dir meine 7 Fragen, mit denen ich meine Projekte steuere. Zusätzlich erfährst Du was bei der Steuerung von Projekten noch wichtig ist.

So habe ich die Episode für Dich aufgebaut:

  • Was ist Projektsteuerung?
  • Wie geht Projektsteuerung? Meine 7 Fragen, mit denen ich Projekte steuere?
    1. Wo stehen wir heute?
    2. Wo müssten wir heute stehen?
    3. Was ist die Abweichung
    4. Was bedeutet die Abweichung?
    5. Was tun wir gegen diese Abweichung?
    6. Was bedeutet es, wenn wir das umsetzen?
    7. Setzen wir es um?
    8. Los gehts!
  • Was ist alles von Projektsteuerung betroffen?
  • Worauf Du achten solltest/ Tipps und Tricks
  • Meine Fragen zum Weiterdenken

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB022: Wie ich mit der Musterroadmap meine Entwicklungsschritte plane

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

In Produktentwicklungsprojekten macht es Sinn die Entwicklungsschritte schon während der Planungsphase festzulegen. Hierbei hilft die Musterroadmap die erforderlichen Musterstände, deren Verwendungszweck und Eigenschaften festzulegen. Was Musterstände sind und wie Du sie mit der Musterroadmap festlegen kannst erfährst Du in dieser Episode.

Vorlage Musterroadmap: projektmanagement-maschinenbau.de/musterroadmap

So habe ich die Episode für Dich aufgebaut:

  1. Was ist die Musterroadmap und wann kann ich sie verwenden?
  2. Was sind eigentlich Muster und Musterstände?
  3. Wie kannst du vorgehen um mit der Musterroadmap deine Entwicklungsschritte zu planen
  4. Auf was Du beim Erstellen achten darfst
  5. Meine Fragen zum weiter denken

Beschreibung der Musterstände:

Funktionsmuster (A-Muster)

  • Dienst dem Nachweis der Funktionen (der technischen Lösung) des Produktes oder von Teilen des Produkte
  • Darf in der Werkstatt oder im Musterbau hergestellt werden
  • Kein Anspruch an Dauerhaltbarkeit, Qualität und Herstellverfahren
  • Materialien dürfen abweichen

Prototyp (B-Muster)

  • Dient dem finalen Nachweis aller Funktionen eines Produktes
  • Nachweis der Dauerhaltbarkeit
  • Produkt bildet die finale technische Lösung ab
  • Materialien dürfen ggf. noch abweichen (nur wenn keine Rückwirkung auf den Funktionsnachweis existiert)
  • Einzelteile dürfen noch aus Hilfswerkzeugen/ Prototypenwerkzeugen stammen
  • Einzelne Teile (Lager, Dichtungen, etc.) dürfen ggf. noch abweichen (nur wenn keine Rückwirkung auf den Funktionsnachweis existiert)

Vorserie (C-Muster)

  • Dient der technischen Serienfreigabe (Produkt)
  • Einzelteile kommen aus seriennahen Werkzeugen
  • Materialien dürfen nichtmehr abweichen

Erstmuster (D-Muster)

  • Dient der Serienfreigabe (Produkt und Herstellprozess)
  • Muster sind mit Serienprozessen hergestellt
  • Die Qualität der Herstellprozesse ist nachgewiesen (ggf. statistisch abgesichert)

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB021: 8 Punkte an denen Du eine gute Projektplanung erkennst

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

Eine gute Projektplanung sollte vollständig, durchgängig und schlüssig sein. Wie Du schnell überprüfen kannst, ob eine Projektplanung gut und geeignet ist, erfährst Du in dieser Episode.

So habe ich die Episode für Dich aufgebaut:

  1. Was macht eine gute Projektplanung eigentlich aus?
  2. Meine 8-Punkte-Checkliste mit der ich mir Projektplanungen anschaue
  3. Wie kannst Du mir der Checkliste umgehen?
  4. Meine Fragen an Dich zum Weiterdenken

Links zu Episoden, die sich mit den Themen in der Episode beschäftigen:

Online-Bibliothek zum Projektmanagement im Maschinenbau

PMMB020: Schätzmethoden – So gehst du vor um Termine, Kosten und Ressourcen zu schätzen

PMMB019: Wie plant man eigentlich ein Projekt? Eine Schritt-für-Schritt-Anleitung

PMMB018: So ermittelst Du die Kosten Deines Projektes

PMMB013: Wie sprichst Du eigentlich mit mir? Was Du über Projektkommunikation wissen solltest

PMMB011: Wieviel Aufwand benötigt Dein Projekt? – Ressourcenmanagement im Projekt

PMMB004: Die Sache mit den Risiken

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB019: Wie plant man eigentlich ein Projekt? Eine Schritt-für-Schritt-Anleitung

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

Projektplanung ist ein wesentlicher Bestandteil von Projektmanagement. In dieser Episode erkläre ich Dir was dabei wichtig ist und wie Du Schritt für Schritt vorgehen kannst um eine vollständige und schlüssige Projektplanung zu erstellen, die von Deinem Auftraggeber freigegeben werden kann.

Hierzu habe ich diese Episode wie folgt strukturiert:

  1. Wann findet die Projektplanung statt?
  2. Was gehört alles zur Projektplanung dazu?
  3. Wie kannst Du Schritt für Schritt vorgehen?
    1. Erstelle eine Projektstruktur
    2. Erstelle einen Terminplan
    3. Erstelle eine Ressourcenplanung
    4. Erstelle eine Kostenplanung
    5. Erstelle eine Risikoanalyse
    6. Erstelle eine Kommunikationsstruktur
  4. Meine Tipps und Tricks für Dich!
  5. Meine Fragen an Dich zum Weiterdenken

Weitere Episoden, auf die ich in dieser Episode verweise:

Episode PMMB006: Phasen im Projektmanagement

Episode PMMB001: Die Mutter aller Instrumente – Die Projektstruktur

Episode PMMB002: In 5 Schritte zum Terminplan

Episode PMMB011: Wieviel Aufwand benötigt Dein Projekt? – Ressourcenmanagement im Projekt

Episode PMMB018: So ermittelst Du die Kosten Deines Projektes

Episode PMMB004: Die Sache mit den Risiken

Episode PMMB013: Wie sprichst Du eigentlich mit mir? Was Du über Projektkommunikation wissen solltest

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB018: So ermittelst Du die Kosten Deines Projektes

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

Projektkosten sind sozusagen der Preis eines Projektes. Bevor man ein Projekt startet möchte man natürlich gerne den Preis des Projektes kennen. Wie Du die erwarteten Kosten deines Projektes ermitteln kannst und auf was Du achten solltest, erfährst Du in dieser Episode.

Hierzu habe ich diese Episode wie folgt strukturiert:

  1. Warum brauchen wir eigentlich Projektkosten?
  2. Aus was setzen sich Projektkosten zusammen?
  3. Wie Du die Kosten für Dein Projekt ermitteln kannst (Schritt-für-Schritt-Anleitung)
  4. Tipps und Tricks
  5. Meine Fragen an Dich zum Weiterdenken

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB011: Wieviel Aufwand benötigt Dein Projekt? – Ressourcenmanagement im Projekt

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Shownotes

Projekte werden von Menschen gemacht! Aber wieviele Menschen und wieviel ihrer Arbeitszeit benötigst Du im Projekt? Um diese Frage zu beantworten benötigst Du eine Ressourcenplanung für Dein Projekt. Was es damit auf sich hat und wie Du vorgehen kannst um eine Ressourcenplanung zu erstellen, erfährst Du in dieser Episode.

Hierzu habe ich diese Episode wie folgt strukturiert:

  1. Was sind Ressourcen eigentlich? Und was ist Ressourcenmanagement?
  2. Warum ist es wichtig ein Ressourcenmanagement im Projekt zu haben?
  3. Die 4 Schritte zur Ressourcenplanung
  4. Wie gehen wir mit Änderungen um?
  5. Meine Fragen an Dich zum Weiterdenken

Links aus der Episode:

Online-Bibliothek mit Vorlagen für Projektstruktur und Terminplanung: Online-Bibliothek zum Projektmanagement im Maschinenbau

Episode zur Projektstrukturierung: PMMB001: Projektstruktur – Die Mutter aller Instrumente

Episode zur Terminplanung: PMMB002: in 5 Schritten zum Terminplan

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB004: Die Sache mit den Risiken

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Risikomanagement in Projekten kommt oft zu kurz. Risiken werden in Projekten sehr oft als etwas diffuses, gefährliches wahrgenommen. Dabei sind Risiken eine völlig normale Eigenschaft von Projekten, denen wir uns stellen dürfen. Risikomanagement im Projekt hilft uns, mit den Unwegbarkeiten in technischen Projekten umzugehen und erlaubt uns vorausschauend zu handeln.

In dieser Episode erkläre ich Dir, was Risiken genau sind und wie Du sie im Projekt findest.

Hierzu spreche ich in dieser Episode über die folgenden Themen:

  1. Was ist eigentlich ein Risiko?
  2. Warum dürfen wir uns gerne in Projekten mit Risiken auseinander setzen?
  3. Wie kann ich im Projekt mit Risiken umgehen?
  4. Meine Tipps und Tricks zum Risikomanagement
  5. Meine Fragen an Dich zum Weiterdenken

Die Sache mit den Risiken

In dieser Episode wollen wir uns mit etwas beschäftigen, dass es in jedem Projekt gibt, und das uns meistens mächtig Ärger machen kann: In dieser Episode wird es um Risiken gehen.

Risikomanagement in Projekten kommt leider oft zu kurz. Risiken sind ja etwas Diffuses, etwas, das uns meistens unerwartet von der Seite trifft, das uns unsere Ziele nicht erreichen lässt. Das sind  Dinge, wie wir Risiken wahrnehmen. Und aus diesem Grund macht es glaube ich Sinn, dass wir uns in dieser Episode einmal eingehend mit Risiken beschäftigen. Ich bin nämlich der Meinung, dass man vor Risiken keine wirkliche Angst haben muss, WENN man ordentlich damit umgeht. Und genau darum soll es in der heutigen Episode auch gehen.

Keine Angst vor Risiken

Also, worüber werden wir sprechen? Wir werden einsteigen mit der Frage „Was ist eigentlich ein Risiko?“ Wir werden uns so ein bisschen einer Definition nähern und wir werden in einem zweiten Schritt einmal die Frage beantworten „Warum sollten wir uns denn im Projekt eigentlich mit Risiken auseinandersetzen?“ Wäre doch viel einfacher, wenn wir die links liegen lassen könnten. Ich werde dir dann einen Prozess, einen kleinen Verfahren zeigen, wie du in deinem Projekt effizient mit Risiken umgehen kannst. Und ich werde dir dann noch so ein paar Tipps und Tricks aus meinem Schatzkästchen zeigen. Und zum Abschluss wie gehabt: Meine Fragen für dich zum Weiterdenken.

Was ist eigentlich ein Risiko?

Gut, dann stellen wir uns einmal den Risiken mit der ersten Frage: Was ist denn eigentlich ein Risiko?

Fangen wir einmal an eher mit einer Beschreibung, was denn so ein Risiko ist. Risiko ist ja erst einmal wieder so ein Allerweltsbegriff, den jeder verwendet, aber wenn wir da einmal genau nachfragen, versteht eigentlich jeder etwas anderes darunter. Und ich muss gestehen: Ich habe im Vorfeld beim Recherchieren für diese Episode keine wirklich schöne, griffige Definition gefunden, die ich dir nun vortragen kann und dann ist alles klar. Deswegen glaube ich, macht es Sinn, dass wir uns einmal so ein wenig über eine Beschreibung diesem Risikobegriff nähern.

Ein Risiko ist ein Ereignis

Also: Risiko ist zunächst einmal ein Ereignis. Also nicht Diffuses, sondern ein Risiko ist ein Ereignis, irgendetwas, das passiert, irgendetwas, das stattfindet.

Dieses Ereignis hat eine Wahrscheinlichkeit. Es ist also so, dass nicht sicher ist, dass das eintritt. Es kann also auch ausbleiben. Und manchmal kann man diese Wahrscheinlichkeit ziemlich genau beziffern über eine Statistik und manchmal über andere Messungen. Und manchmal ist das sehr, sehr schwer.

Und dieses Ereignis hat eine Auswirkung, hat eine Folge auf unser Projekt. Das kann eine positive Auswirkung sein, wir sagen dann meistens Chance dazu, das kann aber auch eine negative Auswirkung sein. Und das ist das klassische Verständnis eines Risikos.

Also noch einmal, ganz wichtig: Ein Risiko ist nichts Diffuses, sondern ein Risiko ist ein Ereignis, das mit einer bestimmten Wahrscheinlichkeit eintritt, und das eine Auswirkung – also eine Folge – auf unser Projekt hat.

Warum sollten wir uns mit Risikomanagement in Projekten beschäftigen?

Warum müssen wir uns denn nun mit diesen Risiken beschäftigen? Das riecht doch schon wieder mächtig nach Aufwand. Naja, sammeln wir doch einfach einmal so ein bisschen die Gründe.

Also: Risiken – und ich meine jetzt hier die negativen Folgen – können unseren Projekterfolg gefährden. Und zwar ordentlich. Unsere Projekte werden teurer, unsere Projekte dauern länger, die Maschine, die Komponente, die wir da gerade entwickeln, wird nicht den vollen Funktionsumfang haben, wird nicht die volle Leistungsfähigkeit haben. Also alles Dinge, die wir eigentlich ganz gerne in unserem Projekt vermeiden wollen, oder? Wir möchten also gern vorbereitet sein, wenn diese Risiken eintreten. Wir möchten damit umgehen können. Oder am liebsten würden sie ganz gerne komplett ausschalten können.

Projekte sind grundsätzlich risikobehaftet

Vielleicht noch einmal die Frage: Warum haben wir denn eigentlich Risiken im Projekt und können wir die einmal alle komplett ausschalten? Aus meiner Sicht ist es so, dass Projekte ganz grundsätzlich risikobehaftet sind. Das ist also sozusagen im Erbgut eines Projektes verhaftet. Wir machen ja Projekte, weil wir die damit verbundene Chance ergreifen wollen. Und eine Chance war ja ein positives Risiken, oder?

Und das kennst du auch: Chance verknüpft sich in der Regel auch mit einem Risiko. Also man kriegt keine Rendite, ohne ein bestimmtes Risiko einzugehen. Das heißt also, Projekte sind grundsätzlich – Ausnahmen bestätigen die Regel, aber grundsätzlich – mit Unsicherheiten, mit Risiken behaftet. Wenn nämlich das Ergebnis eines Projektes von Anfang an klar wäre, von Anfang an feststehen würde, dann würden wir in der Regel kein Projekt machen, sondern wir hätten so etwas wie einen Prozess. Meine Definition da dazu kannst du dir noch einmal in der Episode Projekt oder kein Projekt? nachhören.

Das heißt also, dass es eine ureigene Eigenschaft von Projekten ist, dass sie mit Risiko daherkommen. Und denen sollten wir uns aus meiner Sicht frühzeitig widmen, wir sollen ihnen begegnen, damit wir nicht kalt von ihnen erwischt werden.

Wie sieht Risikomanagement im Projekt aus?

Dann kommen wir schon zur nächsten Frage: Wie gehen wir denn mit Risiken in Projekten um? Also, es gibt so eine grundsätzliche Vorbedingung, das ist das erste: Nimm dich den Risiken an. Also akzeptiere, dass es Risiken gibt, und entschließe dich mit deinem Projektteam aktiv, mit ihnen umzugehen, ihnen zu begegnen. Fachjargon würde das wieder heißen:

Betreibe Risikomanagement!

Ja, und wie das geht, stelle ich dir jetzt gleich vor. Ich würde so eine kleine, schlanke, aus meiner Sicht sehr effiziente Vorgehensweise erläutern, die es dir erlaubt, relativ schnell einen Überblick über deine Risiken im Projekt zu bekommen und, die es dir auch ermöglicht, dich ihnen anzunehmen.

Eine einfache Vorgehensweise um Risikomanagement zu betreiben

Aus meiner Sicht ein schlanker Prozess, der mit wenig Aufwand zu bewerkstelligen ist. Es geht dabei eher um eine qualitative Bewertung, das heißt, ja, seien wir einmal ehrlich, am Ende geht es darum, die Risiken mit deinem Bauchgefühl, mit deiner Erfahrung und auch mit gesundem Menschenverstand und Nachdenken zu bewerten. Es gibt natürlich noch andere, wesentlich detailliertere – und damit auch meistens aufwändigere – Verfahren, aber ich glaube, dass wir in unseren Projekten auf schlanke und einfache Möglichkeiten zurückgreifen sollten, um mit Risiken umzugehen.

Das Verfahren, das ich dir vorstellen möchte, hat im Prinzip drei Schritte:

  • Risiken sammeln
  • Risiken bewerten
  • Maßnahmen festlegen

Also nichts Kompliziertes, wahrscheinlich für dich auch nichts wirklich Überraschendes. Gehen wir es aber trotzdem einmal durch.

Risiken sammeln

Der erste Schritt ist: Setz dich mit deinem Team zusammen und überlege: Welche Dinge könnten denn passieren, die in deinem Projekt eine negative Auswirkung haben. Das heißt, der erste Schritt ist tatsächlich, naja, sammeln, Brainstorming machen. Setzt euch zusammen, überlegt gemeinsam, werft in die Runde Dinge, die da passieren können.

Und unterscheidet bitte Ursache und Folge. Und habt bitte ein besonderes Auge auf die Formulierung. Ich mache es noch einmal konkret: Wenn ich mit meinen Teams einen Risiko-Workshop mache und, ja, die Leute, die da teilnehmen, die Workshop-Teilnehmer, die Risiko-Workshop-Teilnehmer sind nicht so erfahren im Risikoformulieren, dann ist in der Regel eines der ersten Risiken, das da genannt wird, KOSTEN. Jetzt habe ich aber vorhin gesagt: Ein Risiko ist ein Ereignis, das eintritt. Jetzt sind Kosten kein Ereignis, das eintritt. Das heißt, du musst drauf achten bei der Formulierung von Risiken, dass du über Ereignisse redest, Dinge, die in deinem Projekt passieren können, die in dem Fall eine negative Auswirkung haben. Das heißt: Versuche, diese Ereignisse in kleinen, ja, Stichworten, noch besser in Halbsätzen, zu formulieren. Das wird die später die Möglichkeit verbessern, die Risiken auch zu bewerten.

Unterscheide Ursache und Wirkung

Wenn ich Risiken sammle, differenziere ich auch sehr oft in Ursache – also „Was passiert da eigentlich? Was ist das, was da eintritt? Was ist dieses Ereignis?“ – und Folge und Auswirkung. Wenn dir jemand nämlich sagt, Kosten seien ein Risiko, dann ist das nämlich eine Auswirkung, eine Folge, die er meint.

Hintergrund könnte sein „Wir haben noch nie mit diesem und jenem Lieferanten zusammengearbeitet. Wir wissen nicht, wie genau seine Vorkalkulationen sind, und wir könnten ein Kostenrisiko haben, wenn nämlich das Ereignis eintritt, dass der Lieferant mit seiner Kalkulation danebenliegt.“ Klamüsern wir das einmal auseinander: Das Risiko ist, dass die Kalkulation des Lieferanten falsch ist und die Folge ist, dass unsere Herstellkosten steigen. Ne? Also wichtig bei der Formulierung: Wirkliche Ereignisse formulieren. Formuliere in kurzen Halbsätzen, um es klarer zu machen. Und trenne zwischen Ursache und Wirkung.

Verschiedene Quelle für Risiken

Um so einen kleinen Überblick zu bekommen, dass du auch nichts vergisst im Projekt, hilft es, so im Kopf zu behalten, dass es verschiedene Risikoquellen gibt, also verschiedene Risikoarten.

  • wirtschaftliche Risiken
  • technische Risiken
  • rechtliche Risiken
  • organisatorische Risiken
  • Risiken, die sich aus der Umwelt ergeben
  • Planungsrisiken
  • vertragliche Risiken
  • etc.

Also, wenn du Risiken mit deinem Team sammelst: Behalte diese Risikoquellen im Hintergrund und stelle einfach sicher, dass ihr im Laufe der Diskussion alle Arten, alle Quellen Stück für Stück abklappert. Die Liste hilft dir einfach, die Gedanken im Team, die Diskussionen im Team zu strukturieren und auch zu steuern. Es gibt Risiken, die sind sozusagen immer da. Meistens – so als Beispiel – personelle Risiken. Dass die Mitarbeiter, die da eingeplant sind, vielleicht krank werden. Das ist so ein grundsätzliches Risiko, das wir in den allerallermeisten Projekten haben. Andere Risiken sind hochgradig projektspezifisch. Und da muss man dann meistens schon einmal ein bisschen nachdenken.

Gut, das war der erste Schritt, Risiken sammeln, und du hast nun eine lange Liste an Ereignissen, die passieren können, die deinem Projekt in irgendeiner Form mit ihrer Folge oder ihrer Auswirkung scheitern können. Da ist nun die Frage: Welches davon sind denn die großen Risiken und welches sind eher so die, ja, die kleinen, zu vernachlässigenden Risiken? Also kommen wir zum Schritt zwei, Risiken bewerten.

Risiken bewerten

Wenn ich dich nun Frage „Naja, welches ist denn das große Risiko? Welches ist eher ein kleines Risiko?“, wird es dir schwer fallen, mir hier aus der Hüfte zu sagen, wie das einzuschätzen ist. Aus diesem Grund hat es sich bewährt, die Bewertung der Risiken in zwei Kategorien zu machen.

Eintrittswahrscheinlichkeit bewerten

Das heißt, wir beginnen nun zuerst, die ganze Liste durchzugehen, und jedes einzelne Risiko, jedes Ereignis mit jeder seiner Folge und jeder seiner Auswirkung zu bewerten hinsichtlich seiner Eintrittswahrscheinlichkeit. Das heißt, wir ordnen jedem Risiko eine Eintrittswahrscheinlichkeit mit einer Skala von eins bis zehn zu.

Zehn würde in dem Fall heißen „mit an Sicherheit grenzender Wahrscheinlichkeit“, also tritt immer ein. Und eins würde heißen „Naja, eigentlich nicht. Da müsste es schon wirklich, wirklich mit dem Teufel zugehen.“ Eins ist die kleinste Eintrittswahrscheinlichkeit, zehn ist die größte.

Achtung, wichtig an dieser Stelle: Wir reden hier nicht von einer prozentualen Eintrittswahrscheinlichkeit. Fünf heißt nicht „In fünf von zehn Fällen.“, sondern fünf ist lediglich eine höhere Eintrittswahrscheinlichkeit als vier und eine geringere als sechs. Also es geht eher um das Verhältnis zueinander.

Auswirkung bewerten

Wenn wir die Risiken hinsichtlich ihrer Eintrittswahrscheinlichkeit bewertet haben, gehen wir die gleichen Risiken im zweiten Schritt noch einmal Stück für Stück durch und bewerten sie hinsichtlich ihrer Auswirkung, hinsichtlich ihrer Bedeutung. Wie schwerwiegend wäre es denn, wenn dieses Ereignis eintritt? Und da hilft es jetzt, dass wir uns beim Sammeln schon einmal über die Folge und die Auswirkung Gedanken gemacht haben. Das heißt auch hier bewerten wir die Risiken wieder auf einer Skala von eins bis zehn.

Eins ist wieder das Geringste, die geringste Auswirkung. Das würde ich eher so beschreiben mit „Naja, wenn es passiert, passiert es halt. Wird uns nicht wirklich aufhalten.“ Eine zehn würde ich einem Risiko zuordnen, das, ja, mein Projekt maßgeblich verändert bis hin zum kompletten Projektstopp. Wir würden dann oftmals so Show-Stopper nennen.

Und ich durchdenke jetzt jedes Risiko hinsichtlich so zwei, drei Faktoren. Also wie groß ist die Bedeutung, wie groß ist die Auswirkung hinsichtlich der Zeit? Hinsichtlich der Kosten? Oder auch hinsichtlich der Funktionalität, die ich da abliefern soll, also hinsichtlich der Projektinhalte? Also, alle Risiken noch einmal durchgehen und hinsichtlich der Bedeutung hier ihre Auswirkung bewerten.

Größe des Risikos finden

Wenn ich das gemacht habe, kannst du dir vorstellen, was jetzt passiert – jetzt multiplizieren wir für jedes Risiko die Zahlen durch. Das heißt, für jedes Risiko nehmen wir die Bewertung der Eintrittswahrscheinlichkeit, multiplizieren sie mit der Bewertung der Bedeutung und bekommen somit eine Risikobewertung raus. Das ist eine Zahl, die wird zwischen eins und 100 liegen. Und du bekommst nun ein relativ gutes Gefühl dafür, was die großen, schwerwiegenden Risiken in deinem Projekt sind – das werden nämlich die mit den großen Zahlen sein – und die eher zu vernachlässigbaren Risiken, die zwar Ereignisse darstellen, die in deinem Projekt passieren können, die aber nicht wirklich wahrscheinlich sind, und wenn sie passieren, naja, uns auch nicht wirklich aus der Bahn werfen werden.

Maßnahmen finden

Der dritte Schritt ist nun, sich Gedanken zu machen „Welche Maßnahmen können wir denn einleiten, um diesen Risiken zu begegnen?“ Wir machen das in der Regel nicht für alle Risiken, sondern ich gehe meistens so vor, dass ich, ja, mich so um zehn, 15, in kleineren Projekten vielleicht auch einmal um 20 Prozent der Risiken kümmere. Das heißt, ich schaue mir an „Wie ist die Risikobewertung?“ und nehme so die Top 10, 15, 20 Prozent von oben nach unten. Das heißt, ich nehme die größte Bewertung, dann die nächstkleinere und so weiter und so fort.

Meistens gehe ich auch noch so vor, dass ich Risiken mit einer Auswirkung von neun oder zehn auch noch mit in den Pool der Risiken rein nehme, für die ich eine Maßnahme festlege – auch, wenn die Eintrittswahrscheinlichkeit sehr gering ist. Der Hintergrund ist eigentlich der, dass ich, ja, sicherstellen möchte, dass ich mein Projekt liefern kann, auch wenn da Risiken drin sind, die sehr wahrscheinlich nicht eintreten, die aber mein Projekt ganz grundsätzlich gefährden können. Dann möchte ich denen eigentlich begegnen.

Eintritt verhindern und Auswirkung verringern

Ja, und ich durchleuchte nun jedes dieser Risiken und überlege mir „Welche Maßnahme kann ich denn einleiten?“ Und da gibt es zwei Leitfragen aus meiner Sicht. Die erste ist „Wie kann ich die Auswirkung reduzieren, wenn das Risiko dennoch eintritt?“ Also das Ereignis tritt ein, die Folge tritt ein – und was kann ich nun tun, damit mich die Folge nicht so doll trifft?

Manchmal lassen sich nämlich das Eintreten von Risiken nicht wirklich verhindern. Ich hatte vorhin vom Wetter gesprochen, das ist zum Beispiel so eines. Den Umbau einer Produktionshalle, der kann maßgeblich beeinträchtigt werden, wenn draußen schlechtes Wetter ist, wenn der Frost länger anhält, wenn Transportwege nicht zur Verfügung stehen. Du wirst das Wetter nicht beeinflussen können. Es wird die Temperatur haben, die es hat. Aber du kannst dir vorher schon etwas überlegen, eine Maßnahme überlegen, wie du damit umgehen möchtest, wenn dieses Risiko eintritt.

Also, die erste Leitfrage ist „Wie kann ich die Auswirkung reduzieren, wenn das Risiko dennoch eintritt?“ und die zweite Leitfrage ist „Naja, was kann ich denn tun, um das Risiko komplett zu verhindern?“ Das heißt, du bekommst nun in deiner Risikoliste für die top zehn, 15, 20 Projekte eine Liste an Maßnahmen, die du einleiten kannst, die du einleiten darfst in deinem Projekt, um die Risiken zu reduzieren.

Aus Maßnahmen werden Arbeitspakete

Und diese Maßnahmen überführe ich in der Regel in die Projektstruktur oder ordne sie bereits bestehenden Arbeitspaketen als Tätigkeit zu, und ich übertrage sie auch im Terminplan. So wird das Ganze rundum durchgängig und jetzt verstehst du vielleicht auch ein bisschen besser, warum ich in den vergangenen Episoden immer betont habe, dass es so wichtig ist, eine Projektstruktur und einen Terminplan zu  haben.

Risiken sammeln und bewerten und Maßnahmen festlegen

Also, wiederholen wir noch einmal die Vorgehensweise. Grundvoraussetzung ist deine Entscheidung, dich den Risiken anzunehmen, dich den Risiken zu stellen. Wenn du das gemacht hast, gehst du vor, dass du die Risiken sammelst. Du bewertest die Risiken hinsichtlich ihrer Eintrittswahrscheinlichkeit und ihrer Auswirkung. Du ermittelst daraus die Risikohöhe und leitest dann für die Top 10, 15, 20 Prozent deiner Risiken Maßnahmen ab und überträgst die dann im letzten Schritt in deine Planungsunterlagen.

Geringer Aufwand bei hohem Nutzen

Aus meiner Sicht ist das eine Vorgehensweise, in der Aufwand und Nutzen in einem extrem guten Verhältnis stehen, weil du nicht nur das Risiko, das Gesamtrisiko in deinem Projekt reduzierst, weil du dich dem annimmst, sondern auch zusätzlich noch ganz, ganz viel über dein Projekt lernen wirst.

Meine Tipps und Tricks

Ja, kommen wir einmal zu meinem Tipps und Tricks, Dinge, die ich immer versuche, zu beachten, wenn ich mich mit Risiken und Risikomanagement beschäftige.

Reihenfolge einhalten

Also erstens, aus meiner Sicht ganz wichtig: Halte die Reihenfolge ein, die wir eben diskutiert haben. Also mach diese drei Schritte tatsächlich nacheinander. Sammle erst, bewerte dann zunächst die Eintrittswahrscheinlichkeit, bewerte dann erst die Auswirkung, und sammle erst ganz zum Schluss Maßnahmen. Und schau, dass du beim Bewerten der Auswirkung zum Beispiel die Eintrittswahrscheinlichkeit – das, was du vorher bewertet hast – unsichtbar machst. Wir fangen nämlich sonst an, uns tatsächlich auszutricksen.

Unterschiedliche Meinungen berücksichtigen

Du wirst immer wieder die Situation haben, dass du bei der Bewertung der Risiken – also Eintrittswahrscheinlichkeit und Auswirkung – unterschiedliche Meinungen im Team hast. Du kommst irgendwann in die Situation und sagst „So, Lieferverzug einer Maschine, die irgendwie Kernbestandteil unserer Anlage ist. Der Lieferant liefert einfach später, als er zugesagt hat.“ Und ein Teilnehmer wird sagen „Eintrittswahrscheinlichkeit drei.“ und der nächste wird sagen „Eintrittswahrscheinlichkeit sieben.“ Wie gehst du damit um?

Also, erste Grundregel: Wir bilden KEINEN Mittelwert. Wir diskutieren das aus. Das heißt, ich frage immer „Was steckt dahinter? Wie kommst du auf eine Eintrittswahrscheinlichkeit von drei? Was ist dein Bild dahinter? Wie kommst du auf eine Eintrittswahrscheinlichkeit von sieben? Wie kommt ihr zu diesen unterschiedlichen Bewertungen?“ Und ich bringe die Workshop-Teilnehmer in diesem Fall dazu, ihre Motive, ihre Gedanken offenzulegen. Und sehr oft ist es so, dass wir dann in die Situation kommen, dass einer von beiden nickt und sagt „Hm, ja, aus diesem Blickwinkel habe ich es noch gar nicht betrachtet.“

Und wir kommen in aller Regel zu einer gemeinsamen Entscheidung, zu einer gemeinsamen Bewertung. Also achte darauf, dass du die Gedanken der Teilnehmer offenlegen lässt, vor allem dann, wenn du zu einer unterschiedlichen Bewertung kommst.

Benutze ein Tool

Mach es effizient und arbeite mit einem Tool, am einfachsten ist hier ein Excel Tool. Das erlaubt gemeinsames Arbeiten, du kannst später filtern, du kannst – wie ich es eben schon beschrieben habe – einzelne Spalten ausblenden, das heißt, du kannst die Folge, die Auswirkung bewerten und kannst die Spalte Eintrittswahrscheinlichkeit ausblenden und so weiter und so fort. Ich bin wirklich kein Freund von Workshops, bei denen alle hinter ihren Tischen sitzen und wie die Guppys auf einen Monitor oder auf eine Projektionsfläche schauen, weil ich glaube, dass es fast nichts gibt, was weniger die Gedanken, weniger die Kreativität anregt, also solche Situationen.

Beim Risikomanagement mache ich in der Regel eine Ausnahme, weil es einfach Sinn macht, die Menge an Risiken hier über ein Excel Tool oder ein Online Tool oder irgendetwas Computergestütztes zu erfassen.

Arbeite im Team

Ich habe es eben schon vorausgesetzt in dem, was ich gesagt habe, aber ich möchte es noch einmal erwähnen, das ist glaube ich ein wichtiger Tipp: Mach die Risikosammlung und die Risikobewertung im Team. Sammle gemeinsam, bewerte gemeinsam, lege gemeinsam Maßnahmen fest. Das steigert das Bewusstsein im Projekt, du wirst merken, dass deine Teammitglieder ganz viel Zusätzliches über das Projekt lernen, das sie immer wieder verwenden können, und die Qualität wird einfach steigen.

Starte so früh wie möglich

Und dann ist noch die Frage nach dem Zeitpunkt. Wann macht man denn so Risikobewertung? Wann nimmt man sich den Risiken an? Und ich versuche, es – wenn es geht – tatsächlich noch VOR dem Projektstart zu machen. Also vor dem Moment, in dem wir loslegen mit arbeiten. Du kommst dann nämlich in die Möglichkeit und in die Situation, dass du deine Vorgehensweise so strukturieren kannst, dass du den Risiken am besten begegnen kannst, dass du am besten mit ihnen umgehen kannst.

Und ja, ich glaube, es macht Sinn, gleich am Anfang des Projektes sich bewusst zu sein, was da schiefgehen kann, bevor man da mit einem Projekt dann drauf stößt. Plan einfach ein, regelmäßig während der Projektlaufzeit die Risiken noch einmal anzuschauen und zu bewerten – denn Risiken verändern sich. Es kommen neue hinzu, es fallen alte weg. Wahrscheinlichkeiten und Auswirkung verändern sich. Also alles völlig normale Dinge. Versuche also regelmäßig, ich nenne es Risiko Reviews einzubauen, lade Leute ein und gehe gemeinsam mit deinem Team einfach deine Risikoliste durch.

Große Projekte haben lange Risikolisten

Ich werde immer wieder gefragt „Jörg, wie viele Punkte stehen denn auf einer Liste? Sind das zehn? Sind das 20?“ Ja, ich habe ganz oft in größeren, komplexeren Projekten durchaus Risikolisten mit mehr als 100 Punkten drauf, also mit mehr als 100 Ereignissen, die passieren können. Und da habe ich dann meistens noch das Gefühl „Oh, wir haben noch nicht alles erwischt.“

Es erscheint jetzt relativ viel, ist aber aus meiner Sicht durch die Bewertung und die damit verbundene Priorisierung gut handlebar. Ja, du musst dich erst einmal dieser Menge stellen, dieser vielen Ereignisse. Sobald du sie aber bewertet hast, wird aus dieser großen Menge eine kleinere Anzahl an Risiken, eine kleinere Anzahl an Maßnahmen, die du dann auch gut handlen kannst. Also habe keine Angst vor langen Listen. Gerade komplexe Projekte haben eben viele Risiken. Und ich bin der Meinung, dass man sich denen auch stellen sollte.

Risikomanagement ersetzt keine FMEA

Vielleicht noch einmal etwas ganz wichtiges zum Abschluss der Tipps und Tricks: Das, was ich eben beschrieben habe – also dieses Risikomanagement im Projekt – ersetzt auf keinen Fall eine Design-FMEA oder eine Prozess-FMEA. Es geht hier natürlich um ganz, ganz andere Risiken. Es geht hier um Risiken, die im Projekt entstehen und die das Projekt aufhalten können. Es geht NICHT um technische, konstruktive, produktionsbedingte Risiken. Also bitte nicht verwechseln. Auf gar keinen Fall!

JA, du hast also nun gehört, warum es aus meiner Sicht Sinn macht, sich über Risiken im Projekt Gedanken zu machen. Und ich glaube, ich habe dir einen relativ effizienten Weg einmal aufgezeigt, wie du einfaches Risikomanagement im Projekt betreiben kannst. Und auch dieses Mal möchte ich mich von dir mit ein paar Fragen zum Weiterdenken verabschieden.

  • Wie gehst DU eigentlich mit Risiken in deinem Projekt um?
  • Und wie hat es in der Vergangenheit geklappt?
  • An welchen Stellen war das gut oder an welchen Stellen denkst du, dass du da noch etwas verbessern und verändern möchtest?

Ich bin sehr gespannt auf deine Überlegungen hierzu.

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB002: In 5 Schritten zum Terminplan

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

In dieser Episode erkläre ich Dir meine 5 Schritte, die ich gehe um einen vollständigen und guten Termin aufzubauen.

Kein Projekt kommt ohne einen Terminplan aus. Dabei sollte ein guter Terminplan die folgende Anforderungen erfüllen:

  • eine Aussage zum Fertigstellungsdatum liefern
  • die Vorgehensweise des Projektteams zur Lösungsfindung abbilden
  • das Projekt steuerbar machen.

Wie Du einen Terminplan aufbaust, erfährst Du in dieser Episode, die ich wie folgt gegliedert habe:

  • Was ist überhaupt ein Terminplan?
  • Warum brauchst Du einen Terminplan?
  • Meine 5 Schritte zum Terminplan
  • Meine Tipps und Tricks beim Erstellen eines Terminplans
  • Meine Fragen an Dich zum Weiterdenken

 Themen, die ich in der Episode erwähne:

Beispiel Gantt-Diagramm/ Terminplan

Beispiel Gantt-Diagramm/ Terminplan (erstellt mit ProjectLibre)

  •  ProjectLibre, die Open Source-Software, die ich gelegentlich verwende, wenn ich ein kostenloses Terminplanungs-Tool benötige, findest du unter projectlibre.de oder projectlibre.org
  • Microsoft Project ist die Profi-Alterantive vom Marktführer, die du auf der Produktseite von Microsoft findest

In 5 Schritten zum Terminplan

Über die Projektstruktur hatten wir ja schon in der letzten Episode gesprochen. Ich hatte gesagt, die Projektstruktur ist etwas, dass ich immer in meinen Projekten habe. Jedem meiner Projekte erstelle ich eine Projektstruktur und mit dem Terminplan ist es eigentlich so ähnlich. Ich habe ihn nicht immer in der gleichen Detaillierung. Ich habe ihn nicht immer in der gleichen Pracht, aber ich denke, dass gerade in technischen Projekten, aus meiner Sicht, kein so ein Projekt abzuwickeln ist, ohne dass wir einen Terminplan vorliegen haben.

Termine sollen eingehalten werden

Wenn ich mit meinen Kunden über Projektmanagement spreche, dann fällt mir immer wieder auf, dass gerade in so technischen Projekten, Termine einzuhalten das A und O ist. Und ich würde fast sogar sagen, dass es wichtiger ist, als den Kostenrahmen einzuhalten. Und gleichzeitig ist dann aber das, was ich, wenn ich mal in die Projekte reinschaue, was mir gezeigt wird, als Terminplan, was ich dort zu sehen bekomme, eigentlich aus meiner Sicht nicht wirklich dazu geeignet, um A das Projekt zu steuern und B eine vernünftige Aussage über den Fertigstellungstermin zu machen. Und gerade das sind die Dinge, die aus meiner Sicht am Wesentlichsten sind für einen Terminplan. Grund genug also, dass wir uns hier im Podcast mal mit dem Thema Terminplan und Terminplanung auseinandersetzen.

In dieser Episode bearbeite ich die folgenden Themen:

  • Was ist überhaupt ein Terminplan?
  • Warum brauchst Du einen Terminplan?
  • Meine 5 Schritte zum Terminplan
  • Meine Tipps und Tricks beim Erstellen eines Terminplans
  • Meine Fragen an Dich zum Weiterdenken

Ich werde also mein kleines Schatzkästchen aufmachen. Dinge, die ich mir immer zu Rate ziehe, wenn ich Terminpläne erstelle.

Was ein Terminplan leisten muss

Was ist nun ein Terminplan? Ich habe leider keine schöne Definition für dich, die ich dir jetzt vorlesen könnte und dann ist für uns alles klar und dann können wir eigentlich hier auch schon aufhören. Aber ich denke, wir fangen mal vielleicht damit an zu diskutieren, was denn so ein Terminplan leisten muss.

  • Er muss aus meiner Sicht darstellen, wie im Projekt vorgegangen werden soll. Also welcher Lösungsweg das Projektteam gewählt hat, um den Projektauftrag zu erfüllen.
  • Er muss eine Aussage darauf geben oder auf die Frage geben, wann denn das Projekt beendet ist und was da abgeliefert wird.
  • Und er muss, glaube ich, eine Aussage leisten, wie lange die einzelnen Schritte dauern.
  • Und vielleicht auch noch, wenn er gut gemacht ist, wer denn die einzelnen Schritte im Projekt jeweils erledigt.
  • Und er muss es mir ermöglichen, als Projektleiter, dass ich in der Lage bin das Projekt zu verfolgen.
    Ich möchte also wissen, wo wir stehen. Ich möchte wissen, ob wir unsere Ziele erreichen und wenn ja, wann? Und ich möchte auch immer sofort sehen, wann wir denn eigentlich fertig sind.

Anforderungen an einen Terminplan

  • Und dafür muss ein Terminplan so ein paar Eigenschaften haben.
  • Er muss, aus meiner Sicht, vollständig sein. Das Thema Vollständigkeit haben wir ja schon mal diskutiert in der letzten Episode, als wir über die Projektstruktur gesprochen haben. Er muss also alles abdecken, was wir im Projekt erledigen wollen.
  • Er muss realistisch sein. Ich glaube, das ist selbstredend.
  • Er muss also Dauern oder eine Projektdauer abbilden, die wirklich zu erreichen ist. In ganz vielen Projekten ist das leider nicht der Fall.
  • Und er muss abgestimmt sein. Das heißt, er muss, aus meiner Sicht, von allen Team-Mitgliedern auch getragen werden.

Also eine Menge Anforderungen an so einen Terminplan.

Gantt-Diagramm oder Balkenplan

Wie sieht denn nun so ein Terminplan aus? Die Form, die du in der Regel kennst und die auch in der Regel da gewählt ist, das ist ein Balken-Diagramm oder ein Gantt-Diagramm. Der Begriff Gantt kommt vom Herrn Gantt, der diese Art der Darstellung so um 1900 irgendwann erfunden beziehungsweise entwickelt hat.

Und in so einem Balkenplan wird eben jeder Vorgang, jede Tätigkeit, die im Projekt zu erledigen ist, mit einem farbigen Balken dargestellt. Das heißt, alles, was zu tun ist, ist ein farbiger Balken, ein Strich, wenn man so will. Die Länge des Balkens gibt dabei die Dauer wieder, also je länger ein Balken ist, desto länger der Vorgang, ist dabei linear. Also ein Tag ist zum Beispiel ein Zentimeter lang. Fünf Tage sind fünf Zentimeter lang.

Diese Balken sind miteinander verknüpft. Das heißt, sie folgen aufeinander, so wie eben bestimmte Tätigkeiten im Projekt aufeinander auch folgen. Also eigentlich ganz einfach, und das Gantt-Diagramm liefert eben eine super visuelle Sicht des Ablaufes des Projektes, und man kann sofort sehen, wie lang bestimmte Dinge dauern, wie sie zusammenhängen und naja, wenn man von ganz links nach ganz rechts geht, dann hat man eben auch die Projektdauer.

Netzplan und Terminplan

Es gibt noch eine zweite Darstellungsform. Den Netzplan. Ist aber, aus meiner Sicht, bei weitem nicht so gut geeignet das Projekt darzustellen. Er ist nicht so visuell und ist auch nicht wirklich dazu geeignet ein Projekt zu verfolgen. Darfst du gerne mal googeln. Ich glaube, du musst dich aber nicht weiter mit einem Netzplan beschäftigen.

Also aus solch einem Plan wird dann ein Terminplan, wenn ich noch ein Datum hinschreibe. Das heißt, ich ordne jetzt jedem Vorgang ein Datum zu, wann denn an diesem Vorgang begonnen wird zu arbeiten. Ich habe vorhin schon gesagt, jeder dieser Balken hat eine Länge, das heißt, der hat auch eine Dauer und damit ergibt sich quasi auch das Datum, wann dieser Vorgang beendet werden soll. Wenn ich das habe, also alle Vorgänge dargestellt mit Balken, ich habe eine Dauer und die sind mit einander verknüpft und ich habe jedem noch ein Datum zugeordnet, dann habe ich einen Terminplan. Ich werde dir ein kleines Bild in den Shownotes verlinken, damit du so einen optischen Eindruck bekommst, wie denn so ein Terminplan ausschaut.

Warum brauchen wir einen Terminplan?

Ja. Warum brauchst du denn nun so einen Terminplan? Warum ist es aus meiner Sicht notwendig, so einen Terminplan zu haben?

Ich habe es in der Einleitung schon ein bisschen angerissen. Aus meiner Sicht gibt es drei gute, drei große Gründe, warum wir in unseren Projekten einen Terminplan haben sollten.

1. Information zur Gesamtdauer und zum Projektende

Für den Auftraggeber ist besonders eine Aussage zum Projektende wichtig. Dein Auftraggeber, dein Kunde, dein Projektteam, wer auch immer, möchte eine Aussage darüber haben, wann sind wir denn fertig. Ohne eine solide Aussage zu machen, wann wir das Ergebnis unseres Projektes, eine Maschine, einen Antrieb, eine Steuerung, eine Software, was auch immer, wirklich liefern wollen, ist heute kein Projekt mehr zu verkaufen, weder nach innen, noch an einen externen Kunden.

2. Steuerung des Projektes

Der Terminplan erlaubt dir dein Projekt zu steuern. Wichtig, und ich glaube, das ist uns allen klar, aber man muss es tatsächlich noch mal sagen, kein Projekt läuft so ab, wie es beim ersten Plan aufgeschrieben wurde. Das ist völliger Humbug zu glauben, wir machen einen Plan und das Projekt wird exakt so ablaufen. Änderung ist der Normalzustand im Projekt. Dinge passieren. Sachen, die man vorgehabt, klappen nicht aufs erste Mal. Entwicklungsergebnisse sind nicht so, wie man das haben möchte. Der Lieferant kommt später als geplant. Das, was geliefert wird, ist nicht in diesem Zustand, wie man das vorgesehen hatte und so weiter und so fort. Ich denke, daraus machen wir mal irgendwann eine extra Episode hier im Podcast.

Aber um mit dieser ständigen Änderung im Projekt umzugehen, um dann Handwerkszeug zu haben, brauche ich als Projektleiter oder als Projektteam, erstmal eine Planung, um zu erkennen, ob das, was da passiert, ob dieses Risiko, das da eingetreten ist, ob das überhaupt ein Problem darstellt und wie groß das Problem ist. Und was ich denn vielleicht als Gegenmaßnahme einleiten kann.

Ohne einen Terminplan vor mir liegen zu haben, ist es, aus meiner Sicht, nahezu unmöglich hier agieren zu können. Ganz verrückt, in den allermeisten Unternehmen habe ich leider keine wirklich guten Terminpläne gefunden, und dennoch wird mit diesen äußeren Umständen, die irgendwie auf das Projekt einwirken, umgegangen. Naja, das Ergebnis: die Qualität des Ergebnisses haben viele von euch wahrscheinlich schon am eigenen Leib erfahren. Also wir brauchen, aus meiner Sicht, ganz zwingend einen Terminplan, um in der Lage zu sein, das Projekt auch wirklich zu steuern.

3. Transparenz für Entscheidungen

Ohne eine Terminplanung ist zum Beispiel nicht wirklich klar, wann ich einen Entwickler, einen Konstrukteur, einen Fertigungsplaner wirklich brauche. Um zu so etwas zu kommen, wie einer Ressourcen-Freigabe, einer Zusage einer Mitarbeit von Mitarbeitern einer anderen Abteilung, brauche ich die Information, naja, wann brauche ich denn den Menschen und für wie lange? Und was soll der in meinem Projekt denn überhaupt tun?

Das sind alles Fragen, auf die mein Terminplan eine Antwort liefern kann. Ohne so eine Planung kann ich keine vernünftige Diskussion führen, und ich bekomme dann auch keine wirklich guten Entscheidungen hinterher. Du siehst also, es gibt wirklich gute Gründe, die dafürsprechen, einen Terminplan in deinem Projekt aufzusetzen, und ja nicht nur das Projekt selbst wird profitieren, sondern auch dein Unternehmen beziehungsweise deine Abteilung, also das um dich herum wird von der Terminplanung, von einer guten Terminplanung profitieren.

5 Schritte zur Erstellung eines Terminplanes

Dann kommen wir doch mal zu meinen fünf Schritten, die ich in der Regel gehe, um zu einem Terminplan zu kommen. Ich werde sie dir zunächst mal alle nennen. Es sind eigentlich sechs. Der letzte ist so ein bisschen angehängt. Dann werden wir, glaube ich, Schritt für Schritt noch mal drauf eingehen. Also meine fünf Schritte sind:

  1. Erstelle dir eine Projektstruktur.
  2. Übertrage diese Projektstruktur von der Baumdarstellung in eine tabellarische Darstellung und verwende dazu ein Terminplanungstool.
  3. Brich die Arbeitspakete, die du hast in Vorgänge, in Tätigkeiten, in Aktivitäten runter.
  4. Bring dann diese Vorgänge in eine logische Beziehung zueinander.
  5. Überlege dir, wie lange dauern die Vorgänge
  6. Setze einen Starttermin

Relativ einfach, wenn ich sie dir so runter erzähle und wenn du so überlegst, naja, der erzählt mir doch etwas, was ich eigentlich schon weiß. Ja. Das mag sein. Ich dekonstruiere da so einen Planungsprozess in seine Einzelteile. Ich glaube, es hilft aber zu verstehen, was wir da eigentlich tun, um hinterher einen besseren Terminplan zu kommen. Okay. Gehen wir es mal durch

1. Erstellen einer Projektstruktur

Wie wir das machen, warum wir das machen, haben wir, glaube ich, in der letzten Episode schon diskutiert. Noch mal, um es vielleicht in Erinnerung zu holen. Die Projektstruktur sollte vollständig sein. Sie sollte alles abbilden, alle Aktivitäten, alle Arbeitspakete abbilden, die wir in einem Projekt zu erledigen haben. Ich glaube, das ist so die Hauptanforderung, die ich in einer Projektstruktur habe. Und ich habe in der letzten Episode schon gesagt, für mich ist die Projektstruktur die Ausgangslage für ganz viele weitere Planungsschritte, eben auch für eine Terminplanung. Mir fällt es extrem schwer eine Terminplanung und einen Terminplan auszuarbeiten, ohne eine Projektstruktur zu haben, die ich dann quasi übernehmen kann.

2. Projektstruktur in tabellarische Darstellung überführen

Warum übertragen wir erstmal die Projektstruktur? Ich möchte sicherstellen, dass alles, was im Projekt getan werden soll, was in der Projektstruktur enthalten ist, auch im Terminplan enthalten ist. Und jetzt hat die Projektstruktur diese Baumdarstellung, die du ja schon kennst, und ein Terminplan, wir haben vorhin das Gantt-Diagramm besprochen, ist eher so eine zeilenorientierte Darstellung. Also jeder Vorgang ist eine Zeile und jeder Zeile ist ein Balken zugeordnet, um noch ein besseres Bild zu gucken, schau bitte einfach in die Shownotes, wirst du das sehen, ich muss also, um Vollständigkeit zu gewährleisten, das Ganze erstmal übertragen.

Also alle Arbeitspakete, alle Teilprojekte in dein Terminplanungs-Tool übertragen. Und ich verwende einfach immer die gleiche Struktur. Dann finde ich mich auch wieder zurecht. Ohne Tool kommst du an dieser Stelle nur sehr, sehr, sehr schwierig weiter. Selbstverständlich ist es möglich, einen Terminplan mit einem Blatt Papier herzustellen. Und sind wir mal ganz ehrlich, die Amerikaner sind auf den Mond geflogen und haben die ganze Planung an großen Magnetwänden, an Magnet-Tafeln gemacht. Das geht natürlich. Ist aber nicht mehr etwas, womit wir heute wirklich arbeiten wollen.

Das heißt, du kommst nicht um ein Terminplanungstool rum. Also das klassische Tool, das klassische Instrument wäre Microsoft Project, vor dem ganz, ganz viele zurückschrecken. Auch etwas, wo ich in Zukunft noch eine Episode machen werde. Microsoft Project kann alles, was du brauchst. Es kann aber noch viel, viel, viel, viel mehr und selbst ich nutze ungefähr nur 20 bis 30 Prozent dessen, was Project kann. Den Rest lasse ich so ein bisschen außen vor.

Es gibt noch freie Software, zum Beispiel Project Libre, die ich dir empfehlen kann. Die ich auch schon bei Kunden verwendet habe. Kann genau das gleiche, wie MS Project, ist ein bisschen leichter zu bedienen. Also ohne Tool kommst du an dieser Stelle nicht weiter. Das heißt, du brauchst Software-Unterstützung. Vor allem später, wenn wir dann das Projekt auch verfolgen wollen. Und der Schritt zwei ist eben die Projektstruktur in dein Terminplanungs-Tool zu übertragen.

3. Arbeitspakete in Vorgänge herunter brechen

Ein Arbeitspaket ist, wenn es in der Regel objektorientiert gestaltet ist, ist nichts, was du tun kannst. Ein Arbeitspaket wäre zum Beispiel eine Leistungsplatine. Der Begriff Leistungslinie wäre ein Arbeitspaket. Oder Fertigungsplanung. Das wäre zum Beispiel ein Arbeitspaket, das man üblicherweise in einer Projektstruktur finden würde. Damit kann ich aber nichts tun. Und in einem Terminplan organisiere ich Tätigkeiten, Aktivitäten.

Also muss ich das Arbeitspaket runterbrechen. Ich muss mir also überlegen, welche Dinge muss ich denn tun, welche Schritte muss ich denn nacheinander abarbeiten, bearbeiten, um dieses Arbeitspaket zu erledigen. Das heißt, ich muss nun Schritt für Schritt durch alle meine Arbeitspakete durchgehen und muss mir überlegen, was sind denn die Aktivitäten, nennt man das, die Vorgänge, so der Begriff kommt aus MS Project, was sind denn diese Dinge, die ich da tun muss, um dieses Arbeitspaket zu erledigen. Und du erkennst immer dann, dass du das gut gemacht hast, wenn du in deinen Aktivitäten ein Verb drin hast. Also Lastenheft prüfen, Fertigungsplanung erstellen. Da hast du ein Verb drin, jetzt bist du auf der Tätigkeitsebene.

4. Vorgänge in logische Beziehungen zueinander bringen

Wir haben zunächst mal identifiziert, was wir denn alles tun wollen. Und jetzt müssen wir uns überlegen, wie hängen die Dinge denn zusammen? Ich kann zum Beispiel kein Material für Prototypen bestellen, wenn ich noch nicht festgelegt habe, aus welchem Material soll der Prototyp sein. Ich kann nicht bei einem Lieferanten ein Spritzguss-Werkzeug in Auftrag geben, wenn ich noch keine Zeichnung habe für das Teil, das dort gegossen werden soll.

Es gibt in unseren Projekten immer logische Beziehungen, logische Verknüpfungen, aus denen sich eben bestimmte Abläufe ergeben. Und du musst nun dein Projekt einmal durchdenken, jedes Arbeitspaket durchdenken und musst dir überlegen, welche logischen Verknüpfungen gibt es da. In welcher Beziehung stehen die denn zueinander.

Und die gibst du nun wieder in dein Terminplanungs-Tool ein. In MS Project gibt es dafür zum Beispiel eine Spalte, in der du eine Zahl eingeben kannst und diese Zahl entspricht der Zeilennummer eines anderen Vorgangs. Diese Spalte ist benannt mit Vorgänge und damit ordnen sich also diese Vorgänge in einer logischen Beziehung zueinander. Wenn du nun das hast, dann hast du so ein Geflecht an Vorgängen, die sich aus den Arbeitspaketen ableiten und du musst dir nun so zum Schluss noch die Frage stellen, naja, wie lange dauert denn das? Wie lange dauert mein Projekt? Und das lässt sich eben ableiten aus der Antwort auf die Frage, wie lange dauert denn jeder einzelne Vorgang?

5. Dauer der Vorgänge festlegen

Das heißt, im letzten Schritt gehst du nun durch dein Projekt durch, schaust dir alle Vorgänge, alle Aktivitäten an und überlegst dir, wie lange denn jeder einzelne dauert. Und so ergibt sich aus den logischen Beziehungen, aus den Dauern, aus den Arbeitspaketen eben Stück für Stück dein Terminplan. Du bist nun in der Lage, genau dies, was wir vorhin so als Anforderungen für einen Terminplan diskutiert haben, nämlich er muss den Lösungsweg darstellen, er muss sagen, wann sind wir denn zu Ende. Das wird dann genau geliefert, wenn du diese Schritte durchgegangen bist.

6. Starttermin festlegen

Und ganz zum Schluss, das ist so das Anhängsel, setzt du noch einen Start-Termin. Also das Ganze beginnt irgendwann. Du wirst beginnen zu arbeiten zu einem speziellen Datum. Das heißt, du musst nun deinem Terminplan noch mitgeben, an diesem, jenem Tag beginnen wir mit der ersten Aktivität und du wirst dann sehen, aufgrund der logischen Verknüpfungen, aufgrund des Start-Termins und aufgrund der Dauern, wird jedem einzelnen Vorgang nun ein Datum zusortiert. Und jetzt kannst du zum Beispiel auch durchs Unternehmen gehen und sagen, ich brauche im Herbst nächsten Jahres brauche ich einen Fertigungsplaner. Ich brauche im April dieses Jahrs einen Konstrukteur und so weiter und so fort. Und du kannst sagen, für welchen Zeitraum du diese oder jene Ressource brauchst.

Also gehen wir die fünf Schritte noch mal durch:

  1. Erstelle eine Projektstruktur. Aus meiner Sicht, ich habe sie die Mutter aller Instrumente genannt und ich glaube, damit wird das schon so ein bisschen klarer, einer der wesentlichen Ausgangspunkte für die nächsten Planungsschritte.
  2. Bring diese Projektstruktur in ein Terminplanungs-Tool. Überführe es von der Baumdarstellung in eine Tabelle.
  3. Komm auf die Vorgangsebene. Das heißt, geh durch deine Arbeitspakete durch und überlege dir, was sind die Vorgänge, die dahinterstecken. Was sind die Aktivitäten, die jeweils dahinterstecken.
  4. Bring die Vorgänge in eine logische Beziehung zueinander. Sorge dafür, dass die Abläufe klar werden
  5. Schau dir dann an, wie lange diese Vorgänge dauern.
  6. Startdatum setzen

Dann hast du, aus meiner Sicht, einen Terminplan, der vollständig ist, der wahrscheinlich sehr realistisch ist und der eben genutzt werden kann, um A das Projekt weiter zu verfolgen und B weitere Dinge im Projektmanagement zu tun.

Tipps und Tricks zum Terminplan erstellen

Viele, viele Fragen kommen in der Regel in diesem Moment auf. Probleme, die sich auf tun beim Erstellen eines Terminplans. Und ich möchte dir so ein bisschen meine Tipps und Tricks an die Hand geben, wie ich denn mit diesen Fragen, mit diesen Problemen normalerweise umgehe.

Wie detailliert sollte ein Terminplan sein?

Die erste Frage ist normalerweise, die Frage nach der Detaillierung. Ich habe ja gesagt, wir wollen die Arbeitspakete runterbrechen in Vorgänge, in Aktivitäten und du kannst dir natürlich vorstellen, das ist ein bisschen Aufwand. Das ist Arbeit. Und ich habe, um dir vielleicht mal so ein Gefühl dafür zu geben, wenn ich ein Projekt vor mir habe, das noch so ein Jahr geht, eineinhalb Jahre geht, dann habe ich in der Regel irgendwas zwischen 300, 400, manchmal auch 500 Vorgänge da drinstehen. So ungefähr die Menge an Vorgängen, die ich in solchen Terminplänen habe. Und das ist schon ein gutes Stück detailliert.

So, wenn ich jetzt mit meinen Projektleitern oder auch mal mit Teilnehmern im Seminar über Detaillierung spreche, dann bekomme ich ganz oft die Antwort, wenn ich sage, „ja, wie detailliert sollen wir das denn nun machen?“, die Antwort, „naja so detailliert, wie nötig und so grob, wie möglich.“ Das ist bestimmt nicht falsch, aber es bringt uns auch nicht weiter.

Deswegen habe ich für mich so ein paar Faustregeln zusammengestellt, die mir auch helfen, da so ein bisschen mir Orientierung zu geben:

In der Zukunft gröber planen

Vorgänge, die eher am Ende des Projektes sind, also von heute aus gesehen in fernerer Zukunft, die plane ich in der Regel gröber. Und Vorgänge, die jetzt direkt anstehen, die die nächsten Monate anstehen, die in der nächsten Projektphase und vielleicht auch noch in der übernächsten Projektphase sind, die plane ich in der Regel etwas detaillierter. Und wenn ich dann voranschreite im Projekt, werde ich Stück für Stück auch detaillierter mit meiner Planung im Terminplan.

Wichtig ist mir, wir haben im Terminplan Vorgänge, nicht Arbeitspakete. Wir planen auf Vorgangsebene. Und das gibt ja schon mal so eine erste Detaillierung vor. Ich glaube nicht, dass Arbeitspakete in einer Terminplanung, als letzte Planungsdetaillierung wirklich ausreichen. Und vielleicht so als Hinweis: Ein Vorgang ist immer dann, glaube ich, ganz gut formuliert, wenn er so ein Ergebnis liefert. Also ein Dokument ist erstellt. Eine Abnahme ist erstellt. Eine Planung ist erstellt. Irgendetwas ist freigegeben. Wir nennen das ergebnisorientierte Planung.

Nicht zu lange Vorgänge planen

Noch ein Tipp an der Stelle.

Meine Vorgänge sind in der Regel nicht länger, als 20 Tage.

Ich bin so ein kleiner Control-Freak, und ich habe meine Projekte ganz gern, man würde sagen, vielleicht eher an der kürzeren Leine, und meine Vorgänge haben meistens, es gibt so ein paar Ausnahmen, die die Regel bestätigen, keine Dauer, die länger als zwanzig Tage ist, weil mir das Risiko, dass in dieser Zeit etwas schiefgeht und ich bekomme es nicht mit, zu groß ist. Grundsätzlich gilt auch, die Detaillierung ist stark abhängig von der Komplexität des Vorhabens auch von der Komplexität der Arbeitspakete. Auch, wie groß du deine Arbeitspakete geschnürt hast, je komplexer ein Arbeitspaket, desto detaillierter ist in der Regel die Planung der Vorgänge und der Aktivitäten darunter.

Unbekannte Arbeitspakete detaillierter planen

Dinge, die mir unbekannt sind, die wir im Projekt-Team noch nie gemacht haben, die plane ich in der Regel detaillierter. Das heißt, wir besprechen das durchaus viel detaillierter durch, wie wir hier vorgehen wollen. Dinge, die wir gut kennen, die wir in jedem Projekt haben, die wir auch gut abschätzen können, die plane ich in der Regel gröber.

Und da schließt sich gleich noch so ein weiterer Tipp an. Das sollte so detailliert sein, dass wir in der Lage sind, Dauern von Vorgängen gut abzuschätzen. Da kommt auch so ein Stück weit meine 20-Tage-Regel her, weil ich festgestellt habe, dass sich der Schätzfehler in großen Vorgängen deutlich größer ist, als wenn wir eben kleinteiliger sind. Und auch ganz ehrlich, es hat auch was mit Vertrauen zu tun. Wenn ich mit Teams zusammenarbeite, mit denen ich in der Vergangenheit gute Erfahrungen gemacht habe, denen ich vertraue, da habe ich in der Regel eine Planung, die nicht so detailliert ist, wie mit Teams, die ich noch nicht kenne.

Planen ist doch zu viel Aufand

Eine weitere Frage, die beim Erstellen von Terminplänen immer hochkommt, ist die Frage nach dem Aufwand. Ganz oft diskutiere ich mit meinen Teilnehmern im Seminar genau diesen Punkt und dann kommt dann die Frage, „Jörg, ist das nicht furchtbar aufwändig, so einen Terminplan zu erstellen. Da fließt doch viel Arbeit rein.“ Ich so, „ja, selbstverständlich.“ Es ist mehr Aufwand einen Terminplan zu erstellen, wie ihn nicht zu erstellen. Ich glaube, das ist offensichtlich.

Wir haben vorhin aber schon diskutiert, welcher Nutzen da dagegen steht, und ich denke, dass es eben Sinn macht darüber nachzudenken, wie man den Aufwand und den Nutzen, der damit einhergeht in ein vernünftiges Verhältnis zu bringen. Und da möchte ich dir so einen kleinen Tipp geben.

In kleinen Prozessketten denken

Ich arbeite, wenn ich einen Terminplan erstelle, immer mit so einer kleinen Methode, um den Aufwand ein bisschen zu reduzieren. Ich schaue mir Arbeitspakete an, die sehr, sehr ähnlich sind und bei denen ähnliche Dinge gemacht werden müssen. Und für diese Arbeitspakete definiere ich mir kleine Prozesse, kleine Prozessabläufe und verwende die sozusagen als Template, als Vorlage in meinem Terminplan und die tauchen dann immer wieder auf. Also zum Beispiel: Stellen wir uns also mal vor, wir müssen für ein Projekt mehrere Maschinen beschaffen, die wir dann in einer Anlage verknüpfen. Und für jedes dieser Maschinen haben wir ein Arbeitspaket, das heißt Lastenheft. Weil selbstverständlich müssen wir ein Lastenheft schreiben, um diese Maschine dann bei einem Zulieferer beschaffen zu können.

Und ich gehe nun her mit meinem Team und diskutiere zunächst mal dieses Template, diesen Mini-Prozess, der vielleicht so aussehen könnte, um mal bei diesem Beispiel Arbeitspaket Lastenheft zu sein, der wäre dann Lastenheft erstellen, Lastenheft prüfen, Lastenheft überarbeiten, Lastenheft freigeben. Das heißt, das Ergebnis dieser vier Schritte ist, ich habe ein freigegebenes Lastenheft. Und wenn ich diesen Mini-Prozess habe, dann kann ich ihn in meinem Terminplan, also diese vier Vorgänge, in meinem Terminplan immer wieder an die entsprechenden Stellen kopieren. Das heißt, jedes Mal, wenn ein Lastenheft zu erstellen ist, kopiere ich einfach diese vier Schritte rein und ich kann sie dann mit meinem Team effizient eben bewerten, wie lange sie dauern.

Das heißt, ich versuche meinen Aufwand zu reduzieren, indem ich mir Templates, kleine Vorlagen schaffe, die ich immer wieder verwende. Das mache ich zum einen jeweils im Projekt, also im gleichen Projekt, aber natürlich auch projektübergreifend. Das heißt, bei mir hat sich natürlich in den vergangenen Jahren so eine kleine Sammlung an Mini-Prozessen, an Templates angesammelt, die ich immer wieder verwende in meinen Terminplänen, um hier mit möglichst geringem Aufwand ein Gefühl für die Terminplanung zu kriegen oder eine Grundlage für die Terminplanung zu überlegen.

Ein anderes Thema, das beim Aufwand immer hochkommt, ist, dass meine Team-Mitglieder so ein bisschen, wie soll ich sagen, den Aufwand scheuen, den Terminplan selbst zu machen. Und da muss ich auch ganz klar sagen, ich sehe es als meine Verantwortung, auch als meine Pflicht als Projektleiter den Terminplan zu führen, und ich tue das auch sozusagen als Dienstleister für mein Projekt-Team, und das reduziert natürlich den Aufwand für mein Team, jetzt die Vorgänge selbst in irgendeinem Terminplanungs-Tool einzutragen.

Ich tue das für die. Warum? A ist es meine Aufgabe. B ich bin viel effizienter darin. Es ist mein tägliches Brot mit einem Tool, wie Microsoft Project zu arbeiten. Ich bin dort einfach viel schneller und deswegen reduzieren wir da einfach auch so ein bisschen den Aufwand fürs Team.

Ohne Tool geht es nicht

Tool ist ein wichtiges Stichwort. Ich habe vorhin gesagt, ohne Tool geht es aus meiner Sicht nicht. Und das ist etwas, an einer Stelle, an der dann viele leider schlucken und sagen, „können wir es denn nicht in Excel zum Beispiel machen?“ Excel hat ja auch Zeilen und da kann man wunderbar Balken machen, indem man eben einzelne Zellen dann farblich markiert und das sieht dann auf den ersten Blick durchaus aus, wie ein Balkenplan. Da gebe ich Recht.

Dennoch, also das jetzt einfach mal so als Aussage:

Microsoft Excel ist kein geeignetes Tool, um einen Terminplan zu erstellen.

Und es ist schon gar nicht geeignet, um später Projekte damit zu verfolgen, weil nämlich Excel ein wesentliches Feature nicht zur Verfügung stellt, dass ein Terminplanungs-Tool zur Verfügung stellt und das ist die automatische Verknüpfung von Vorgängen. Das ist das, was ich vorhin gesagt habe. Das war unser Schritt vier, bring die Vorgänge in eine logische Verknüpfung. Und zwar mache ich das in so einem Tool tatsächlich über eine echte Verknüpfung. Das heißt, da werden Software-intern einzelne Vorgänge miteinander verknüpft und wenn sich der Vorgänger-Vorgang verschiebt, dann verschieben sich die nachfolgenden Vorgänge ebenfalls. Und das kann eben ein Instrument oder ein reines Mal-Tool, wenn ich das Excel dann als Mal-Tool verwende, nicht leisten. Das heißt, ich brauche aus meiner Sicht tatsächlich etwas, dass genau hier an der Stelle unterstützt.

Ein spezielles Tool zur Terminplanung ist wichtig

Der Standard am Markt ist Microsoft Project. Hat aus meiner Sicht extremen Vorteil. Ist eben der Standard. Er kann alles. Microsoft Project kann alles, was du brauchst. Ist aber irre teuer und hat den Nachteil, dass es noch viel mehr kann, als du wirklich brauchst und ist am Anfang, glaube ich, mit den ganzen Funktionen, die den Bediener schlicht weg überfordert.

Es gibt eine kostenlose Open-Source-Alternative, die ich sehr oft empfehle, die ich auch selbst verwende. Das nennt sich Project Libre. Hat aus meiner Sicht den tollen Charme, es kann exakt das, was du brauchst, vor allem, wenn du damit beginnst. Wenn du beginnst dich ernsthaft hinzusetzen und einen guten Terminplan zu machen. Project Libre liefert dir alles, was es können muss. Es ist kostenlos. Es überfährt dich nicht. Es ist an der einen oder anderen Stelle vielleicht nicht ganz so benutzerfreundlich, wie es jetzt dann eine Software von Microsoft wäre, aber es liefert exakt das, was du brauchst.

Es gibt noch weitere Tools selbstverständlich, die ähnliches liefern. Es ist einfach so, dass ich in der Vergangenheit mit Project Libre ziemlich gute Erfahrungen gemacht habe und es an der Stelle, glaube ich, auch empfehlen kann. Ich denke, wir machen vielleicht mal irgendwann eine Episode, wo wir uns um diese ganze Tool-Landschaft kümmern.

Für Akzeptanz der Terminplanung sorgen

Ein weiteres Thema, das man sich anschauen sollte, wenn man Terminpläne macht, ist das Thema der Akzeptanz. Ich habe ganz oft die Situation, dass ein Projektleiter auf mich zukommt und sagt, „also ich habe jetzt hier einen Terminplan gemacht. Da saß ich auch drei Wochen dran. Der ist gut. Der ist detailliert, aber der wird nicht von meinem Team akzeptiert. Meine Team-Mitglieder sagen, „keine Ahnung, was du da gemacht hast, wir arbeiten so, wie wir arbeiten.“ Und das ist ein großes Problem.

Aus meiner Sicht sollte ein Terminplan vom gesamten Team getragen werden, weil er die gemeinsam gewählte Vorgehensweise im Projekt widerspiegelt. Und wenn der Terminplan etwas anderes darstellt, als das, wie das Team arbeitet, wie die Arbeitspakete abgearbeitet werden, dann ist er nicht wirklich wertvoll. Also was kannst du tun, um hier für Akzeptanz zu sorgen?

Erarbeite den Terminplan gemeinsam mit deinem Team. Also setzt euch gemeinsam hin und diskutiert gemeinsam die Arbeitspakete. Das ist der ähnliche Tipp, wie wir ihn schon bei der Projektstruktur hatten, arbeitet hier gemeinsam. Arbeite vor. Das reduziert den Aufwand. Ich habe dir vorhin von Mini-Prozessen und Templates erzählt. Arbeite vor, bereite Dinge vor und modifiziere sie dann nur noch im Team. Auch das ist ein gemeinsames Erarbeiten, reduziert aber den Aufwand. Schätze gemeinsam mit demjenigen, der ein Arbeitspaket oder einen Vorgang später tun muss, auch die Dauer ab. Es ist nicht zielführend, wenn du deine Abschätzung dort reinpackst. Es muss die gemeinsame Abschätzung sein, auch derer, die da später beteiligt sind. Also ganz zusammengefasst: du musst zu einer Situation kommen, in der das Team von unserem Terminplan spricht und nicht von deinem Terminplan. Das ist so ein kleiner Unterschied im Wording, in der Diskussion, anhand derer du erkennen kannst, wie gut du hier an dem ganzen Thema Akzeptanz gearbeitet hast.

Du hast nun gehört, warum ich glaube, dass es notwendig ist einen Terminplan für ein Projekt zu erstellen. Und ich habe dir auch meine fünf, fünfeinhalb Schritte genannt, wie ich dabei vorgehe. Und auch diese Episode möchte ich wieder mit meinen Fragen für dich zum Weiterdenken abschließen.

Meine Fragen zum Nach- und Weiterdenken

  1. Hast du denn für dein Projekt einen Terminplan, der meinen Anforderungen genügen würde?
  2. Und worin siehst du denn den größten Nutzen eines Terminplans, gerade in deinem Projekt?
  3. Wie gehst du denn vor, wenn du einen Terminplan für dein Projekt erstellst und warum machst du das genau so?

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de

PMMB001: Projektstruktur – Die Mutter aller Instrumente

Abonnieren

Du verpasst keine Episode mehr, wenn Du den Podcast abonnierst:

Die erste Episode im Podcast zum Projektmanagement im Maschinenbau beschäftigt sich mit der Projektstruktur bzw. dem Projektstrukturplan, aus meiner Sicht die Basis aller weiteren Schritte im Projekt.

Die Projektstruktur stellt die gesamte Arbeit im Projekt dar und bildet den Ausgang für Terminplanung, Kostenplanung, Kommunikation, etc. Leider verwenden nur die wenigsten Projektleiter eine Projektstruktur, dabei ist sie einer der wesentlichen Erfolgsfaktoren für den Projekterfolg. In dieser Episode erfährst Du alles, was Du über die Projektstruktur zunächst wissen musst.

Die Themen in dieser Episode

  • Was ist eine Projektstruktur?
  • Warum brauchst Du eine Projektstruktur?
  • Wie kommst Du zu einer Projektstruktur?
  • Was bedeutet das für Dich und meine Fragen zum Weiterdenken

Projektstrukturplan – Die Mutter aller Instrumente

In dieser Episode geht es also um die Projektstruktur bzw. um den Projektstrukturplan. Aus meiner Sicht eines der wichtigsten – auch wirkungsvollsten – Instrumente im Projektmanagement. Gleichzeitig aber auch am meisten unterschätzt.

Ich werde in meinen Seminaren immer wieder gefragt, „Jörg, was ist so DEIN wichtigstes Instrument im Projektmanagement? Wenn du alles andere weglassen müsstest – was würdest du behalten?“

Meine Antwort ist in der Regel,

„Die Projektstruktur.“

Ich mache KEINE Projekte, ohne dass ich eine Projektstruktur habe, und seien sie noch so klein. Und ich glaube auch, dass ist genau der Grund, warum ich mich entschieden habe, jetzt hier den „Projektmanagement im Maschinenbau“ Podcast zu beginnen mit dem Thema Projektstruktur.

Was erwartet dich in dieser Episode?

  • Was ist eine Projektstruktur?
  • Warum brauchst Du eine Projektstruktur?
  • Wie kommst Du zu einer Projektstruktur?
  • Was bedeutet das für Dich und meine Fragen zum Weiterdenken

Wir werden dann das Ganze wieder abschließen mit der Frage, was es für dich bedeutet und ich habe auch wieder so ein paar kleine Fragen für dich zum Weiterdenken, zum Weiterarbeiten dabei.

Dann steigen wir doch direkt einmal ein:

Was ist denn eigentlich eine Projektstruktur?

Vielleicht vorneweg einmal so eine kleine Definition:

Eine Projektstruktur ist aus meiner Sicht die vollständige Darstellung aller Aufgaben, aller Arbeiten in einem Projekt.

Du kannst dir denken, was mir bei dem Satz besonders wichtig ist: VOLLSTÄNDIG. Alle Arbeiten, alle Aufgaben im Projekt! Für mich bildet die Projektstruktur die Grundlage der Arbeit.

Deshalb: Alles, was hier nicht steht, was ich hier nicht stehen habe, das vergesse ich sehr wahrscheinlich, wenn ich später einen Terminplan erstelle, wenn ich Verantwortliche für Arbeitspakete suche, wenn ich Kosten ableite. Und aus dem Grund auch der Titel dieser Episode “Die Mutter aller Instrumente”. Für mich ist die Projektstruktur immer die Ausgangslage, das Allererste, was ich normalerweise mache, wenn ich ein Projekt aufplane.

Also, Tipp vorne weg: Auf Vollständigkeit achten.

Vielfache, verwirrende Verwendung des Begriffes

Ich beobachte sehr oft, dass der Begriff Projektstruktur ganz willkürlich in den Projekten oder auch in den Unternehmen verwendet wird. Gelegentlich verwendet man den Begriff für die Teamzusammensetzung, ähnlich wie bei einem Organigramm ist dann die Darstellung. Manchmal wird es auch für so etwas Ähnliches wie eine Multiprojektliste verwendet, also die Struktur unserer Projekte.

Ich habe da in den vergangenen Jahren schon so einiges gesehen und wirklich das wenigste hat etwas damit zu tun mit dem, was ich Projektstruktur nennen möchte.

Meistens wird eine Projektstruktur als sogenannter Projektstrukturplan dargestellt. Ja, die Abkürzung für Projektstrukturplan ist PSP und das kennst du vielleicht wenn ihr SAP bei euch im Unternehmen verwendet, dann hast du nämlich für deine Projekte ein sogenanntes PSP-Element anzulegen, und da kommt das auch her. PSP-Element steht für Projektstrukturplan-Element. Kommen wir auch gleich noch einmal bei der nächsten Frage „Wie kommst du denn zu einer Projektstruktur?“ darauf zurück, was das denn bedeutet.

Darstellungsform der Projektstruktur

Also, der Projektstrukturplan ist eine Darstellung, die du schon kennst, die auch verwendet wird, wenn im Unternehmen Organisation dargestellt wird, nämlich das Organigramm. Also der Projektstrukturplan ist in der Regel dann so eine Baumdarstellung, so ein umgedrehter Baum. Da ist dann der Stamm oben, das ist meistens das Unternehmen im Organigramm, und darunter sind dann die Abteilungen und so weiter.

Großer Unterschied – Achtung, Feuerfalle: Das Organigramm stellt dar, wie eine Organisation funktioniert. Also: Wer ist wessen Chef? Welche Abteilungen besitzen wir? Wie ist bei uns disziplinarische Weisungsbefugnis organisiert? Und in dem Kästchen im Organigramm stehen in der Regel Abteilungsbezeichnungen und Personen.

NICHT so im Projektstrukturplan. Im Projektstrukturplan steht dort Arbeit und nicht im ersten Schritt – später wahrscheinlich schon – aber im ersten Schritt stehen dort keine Personen. Es stehen auch keine Abteilungen, sondern es steht Arbeit darin. Das ist ein großer Unterschied, auch wenn die Darstellungsform die gleiche ist.

Weitere Darstellungsformen der Projektstruktur

Es gibt noch eine weitere Darstellung für die Projektstruktur, und das ist eine strukturierte Tabelle, eine tabellarische Darstellung. Hier wird quasi der Projektstrukturplan in einer eingerückten, strukturierten Tabellenform gebracht und dargestellt. Diese Darstellungsform verwenden wir ganz oft, wenn wir dann im nächsten Schritt einen Terminplan ableiten, Kosten planen wollen und so weiter. Da kommen wir aber später auch noch einmal darauf.

Also: Die Projektstruktur ist also ein Instrument, mit der du die gesamte Arbeit in einem Projekt – das sind dann später die Arbeitspakete – erfassen, darstellen und auch strukturieren kannst.

Eine Projektstruktur stellt also die ARBEIT in deinem Projekt dar.

Nutzen einer Projektstruktur

So, warum brauchst du unbedingt eine Projektstruktur? Für mich gibt es drei Gründe, warum ich in meinen Projekten IMMER eine Projektstruktur habe.

1. Vollständigkeit

Wenn ich sicher sein kann, dass ich alle Arbeiten eines Projektes erfasse habe, dann kann ich auch sicher sein, dass ich im Projekt keine oder zumindest nur ganz, ganz wenige Überraschungen erlebe. Wie oft habe ich es schon erlebt, dass Projekte deutlich länger dauern und teurer werden, als ursprünglich einmal geplant, als ursprünglich einmal vorgesehen, weil einfach Arbeitspakete schlicht und ergreifend vergessen oder naja, manchmal auch bewusst ignoriert wurden.

Erst vor kurzem habe ich wieder ein Projekt übernommen in einer kritischen Phase und wir haben dort festgestellt, dass einfach die komplette Qualifikation nicht in der Projektstruktur – die gab es zu dem Zeitpunkt eh noch nicht – aber auch nicht im Terminplan berücksichtigt war. Und es ist nun natürlich offensichtlich, dass bei einem neuen Produkt, das in Serie produziert werden soll, eine Qualifikation erforderlich ist und gemacht werden muss.

Und jeder, der das schon einmal gemacht hat, der kann sich natürlich vorstellen, dass da einige Wochen Arbeit, mehrere Mann-Tage darin stecken, ganz zu schweigen von den Kosten für Prüflingen und so weiter. Also: Vollständigkeit ist einer der großen Nutzen, nichts zu vergessen im Projekt.

2. Transparenz

Ich habe eine viel besser Transparenz und eine Diskussionsgrundlage. Wenn ich alle Arbeitspakete auf dem Tisch habe sozusagen, dann kann ich mit meinem Team – vor allem auch mit meinem Auftraggeber – viel besser über das Projekt sprechen, viel detaillierter, viel mehr auf den Punkt kommend. Ich kann Inhalte besser abgrenzen und ich kann diskutieren, was noch innerhalb des Projektes liegt und wofür ich dann natürlich auch verantwortlich bin und was nicht.

Wenn ich alle Arbeitspakete habe, dann habe ich es auch deutlich leichter in den Teambesprechungen meinen Fortschritt zu verfolgen. Ich habe dann nämlich sozusagen eine Liste an Themen, die ich regelmäßig ansprechen kann, um sicherzustellen, dass auch an allem gearbeitet wird. Und ich kann auch sicherstellen, dass ich zu all diesen Arbeitspaketen regelmäßig eine Rückmeldung kriege, weil ich einfach danach fragen kann.

3. Planungsgrundlage

Mein dritter Punkt, den habe ich vorhin glaube ich schon so ein bisschen anklingen lassen, ist die Planungsgrundlage. Ich habe gesagt die Projektstruktur ist die Mutter aller Instrumente.

Die Projektstruktur ist der Ausgangspunkt für alle weiteren Planungsschritte

Wenn ich Arbeitspakete und Aufgaben habe, dann kann ich beginnen, die auch zu terminieren und damit einen Terminplan abzuleiten.

Wenn ich Arbeitspakete habe, dann kann ich mir daraus die Projektkosten und irgendwann auch das Projektbudget ableiten.

Wenn ich die Arbeitspakete habe, dann kann ich damit Kollegen suchen, die die erledigen können – und ich kann damit dann mein Projektteam zusammenstellen. Und ganz zu schweigen davon, dass ich viel besser in der Lage bin, mir das Team zu beschaffen, weil ich ganz genau weiß, für welche Aufgabe ich jemanden brauche und wie lange und mit welchem Aufwand.

Also ich habe eine deutlich bessere Grundlage, um eine Projektplanung zu machen, die stabil ist, die RICHTIG ist, die der Realität entspricht und naja, die ich auch nicht ständig ändern muss.

Du siehst also: Eine gute Projektstruktur bildet die Basis für die gesamte weitere Projektarbeit. Und naja, vielleicht höre ich mich an der Stelle etwas fanatisch an, aber das liegt einfach daran, dass ich bei meiner Arbeit immer feststelle, dass KAUM ein Projekt, kaum ein Projektleiter mit einer Projektstruktur arbeitet.

Leider zu wenig bekannt

Die meisten KENNEN das gar nicht, obwohl das eigentlich naja, jeder der sich einmal mit Projektmanagement beschäftigt hat spätestens auf Seite acht im Buch oder naja, in der zweiten Vorlesung an der Uni bei der Vorlesung Projektmanagement thematisiert wird. Und ganz oft höre ich solche Sätze wie: „Naja, wir kennen doch unsere Arbeit, wir wissen doch, was zu tun ist. Jeder muss halt einfach nur machen, was seine Aufgabe ist, und dann kommen wir schon ans Ziel.“ Am Ende bedeutet das aber, dass wir keinen Überblick über unsere Projekte haben.

Ganz viele Projekte leben von Monat zu Monat, das ist ungefähr die Sichtweite, die die meisten Projekte und die meisten Projektteams haben. Wenn ich frage, „Naja, was ist denn so als nächstes zu tun?“ Dann bekomme ich meistens so ganz gut die Aufgaben des nächsten Monats aufgelistet – aber darüber hinaus wird es dann dunkel. Und diese Teams wundern sich dann, wenn sie Monat für Monat auch den Fertigstellungstermin verschieben müssen – weil eben noch keiner über diese Grenze hinaus geschaut hat, weil keiner den Überblick über alle Arbeitspakete hat und somit auch keine verlässliche Aussage machen kann. Und ich glaube, das muss einfach nicht sein, weil es wirklich ein gutes Instrument gibt, um das Problem zu bearbeiten.

Vorgehensweise zum Erstellen einer Projektstruktur

Wie kommst du also nun zu so einer Projektstruktur? Also eines einmal vorne weg: Am Besten erstellst du die Projektstruktur mit deinem Team. Ja, ja, ich weiß, ich habe eben oben gesagt, „Naja, wenn ich eine Projektstruktur habe, fällt es mir leichter, mein Team zusammenzustellen.“, das ist mir schon bewusst. Aber meistens ist es ja schon so, dass du aufgrund der Aufgabenstellung eigentlich schon relativ klar hast, wer denn so grob in deinem Team dabei ist – und mit den Leuten erstellst du die Projektstruktur. Du kannst es auch alleine tun, mache ich gelegentlich auch einmal. Nichtsdestotrotz musst du irgendwann mit dem, was du erarbeitet hast, hinaus gehen und mit deinem Team, mit deinen Teamkollegen das einmal diskutieren, weil gehe einmal davon aus, dass das Ergebnis, das du in der Gruppe erarbeitest, deutlich besser ist als das, was du alleine an deinem Schreibtisch hinkriegst.

Ich gehe in der Regel dabei folgendermaßen vor – es gibt bestimmt noch andere Wege, aber das ist eben der, mit dem ich die besten Erfahrungen gemacht habe. Also: Ich erarbeite grundsätzlich zunächst einmal einen Projektstrukturplan, also die Baumdarstellung, weil sie eben sehr visuell ist und ich damit am besten diskutieren kann; in einer Tabelle verliere ich mich am Anfang sehr oft. Ja, und ich gehe dann einfach so vor, dass ich zunächst einmal den Namen des Projektes in das erste Kästchen ganz oben – also sozusagen in den Stamm des Baumes – schreibe. Und davon gehe ich dann weiter. Und dann sammle ich gemeinsam mit meinem Team die Themen, die im Projekt aufkommen werden, die Themen, die wir bearbeiten müssen.

Sammeln der Themen

Naja, wenn ich einmal etwas herausgreifen müsste, zum Beispiel von einem Projekt, das ein mechatronisches Produkt entwickelt, dann habe ich mit Sicherheit ein Thema das heißt „System“, ich muss ja mehrere Bereiche zusammenbringen. Dann habe ich ein Thema „Mechanik“. Ich habe ein Thema „Hardware“, also Elektronik. Ich habe einen Themenbereich, der heißt „Software“. Ich habe einen Themenbereich, der heißt vielleicht „Versuch und Qualifikation“, hatten wir eben glaube ich schon einmal angesprochen. Dann gibt es einen Themenbereich der heißt „Produktion“, das ganze Ding muss ja irgendwann auch hergestellt werden, wir brauchen Produktionsprozesse, Montageprozesse und so weiter. Und ich habe wahrscheinlich auch noch einen Themenbereich, der heißt „Markteinführung“, weil irgendwie muss das ganze Ding ja auch zu unseren Kunden kommen.

Und ganz zum Schluss – auf keinen Fall vergessen, das stelle ich meistens dann oben an – habe ich noch einen Themenbereich „Projektmanagement“. Weil du erinnerst dich, vorhin bei der Definition habe ich gesagt, „Die Projektstruktur stellt alle Arbeit dar, die im Projekt gemacht werden muss, gemacht werden soll.“, und naja, Projektmanagement ist Teil des Projektes, wird darin gemacht – also brauche ich auch einen Themenbereich.

Teilprojekte und Arbeitspakete

Und das ist sozusagen die erste Ebene in meinem Projekt, und diese Ebene – den Begriff kennst du schon – den nennen wir Teilprojekt, Teilprojekte. Das heißt wir haben ein Teilprojekt „System“, wir haben einen Teilprojekt „Mechanik“, wir haben ein Teilprojekt „Hardware“ und so weiter. Und meistens nummeriere ich die jetzt auch noch durch. Das heißt „Projektmanagement“ bekommt die Nummer null – damit steht es ganz oben, auch später, wenn ich eine Tabelle erzeuge – „System“ hat die Nummer eins, „Mechanik“ die Nummer zwei und so weiter und so fort.

Ja, und wenn ich das habe, wenn ich hier einmal so soweit stabil bin, dann beginne ich gemeinsam mit meinem Team, die einzelnen Themen, also die Teilprojekte, weiter runter zu brechen. Also immer mit der Frage: „Was steckt da darin? Woraus setzt sich das denn zusammen?“ Ja, und wenn wir das noch einmal machen, zum Beispiel für unsere Nummer fünf „Versuch und Qualifikation“, dann steckt da mit Sicherheit ein Prüfplan darin, das heißt irgendeiner muss sich hinsetzen und muss eine Planung machen: „Was wollen wir denn alles prüfen und untersuchen?“ Dann gibt es mit Sicherheit ein Arbeitspaket, das heißt „Prüflinge“, also irgendjemand muss sich überlegen: „Wie viele brauche ich und wie müssen die zusammengestellt sein? Welche Eigenschaften müssen die haben?“ und so weiter. „Prüfereinrichtungen“ ist vielleicht die Nummer drei. Wir brauchen quasi eine Planung, auf welchen Prüfständen das gemacht werden muss, Prüfmittel, wir brauchen natürlich Messgeräte, Messwellen, was weiß ich, hängt jetzt sehr stark von deinem Projekt ab. Und dann beginne ich meistens schon die einzelnen Prüfungen schon einmal grob aufzulisten, wie ich sie kenne. Also wir haben mit Sicherheit einen Dauerlauf und so weiter und so fort. Das wird hier nun alles aufgelistet. Diese Ebene – das ist jetzt die Ebene unter „Versuch und Qualifikation“ – die Ebene unter den Teilprojekten, die nennt man Arbeitspakete. Das sind nun also die Dinge, die ich auch gut einer Person zuordnen kann, und die auch sehr gut jemand anderem dann auch übergeben kann.

Große Projekte haben große Projektstrukturen

Ja, manchmal – vor allem auch bei großen Projekten – kommt man mit diesen zwei, drei Ebenen – also Projekt, Teilprojekt, Arbeitspaket – nicht zur Rande, da ist einfach viel mehr Struktur erforderlich, um die Arbeit vollständig und verständlich darzustellen. Das ist aber gar kein Problem, sondern hilft einfach der Transparenz. Ich behelfe mir dann ganz oft mit solchen Kunstwörtern wie „Hauptarbeitspaket“, „Teilarbeitspaket“, „Unterarbeitspaket“, einfach um quasi jeder Ebene im Projektstrukturplan, jeder Ebene im Baumdiagramm auch einen Namen geben zu können.

Und grundsätzlich gilt – und das ist mir ganz wichtig – komplexe Projekte werden nicht einfacher, wenn du die Augen zu machst, also etwas weg lässt und sagst, „Ja, da kümmern wir uns später darum.“ Es wird nicht weniger komplex. Das Projekt hat die Komplexität und deine Aufgabe ist es, dich dieser Komplexität zu stellen.

Moderationsmaterialien nutzen

Ich arbeite bei der Erstellung einer Projektstruktur am Anfang meist an Pinnwänden und Moderationskarten oder an Whiteboards oder so irgendetwas. Der Grund ist ganz einfach: Gerade beim Erstellen am Anfang, beim Erstellen einer Projektstruktur, gibt es noch ganz, ganz viele Änderungen. Da müssen Arbeitspakete umbenannt werden, die werden dann doch einem anderen Teilprojekt zugeordnet, sind doch nicht Teil des Projektes, müssen also wieder runter genommen werden – und du bist einfach bei der Arbeit an der Pinnwand flexibler. Du kannst mehr hin und her schieben, du kannst auch einmal etwas ausprobieren, du kannst einfach einmal drei Arbeitspakete umhängen und gucken, ob das damit irgendwie sich besser anfühlt, besser aussieht. Es gibt noch einen zweiten Grund: So eine gemeinsame Arbeit an einer Pinnwand, an einem Whiteboard, ist viel aktivierender. Ich glaube es gibt nichts schlimmeres, als wenn fünf Menschen gemeinsam in einem Raum sitzen und auf eine Leinwand starren, während einer mit einer Maus sich abmüht irgend so ein IT-Tool zu bedienen – da passiert einfach nichts in den Köpfen. Und ich bin einfach ein Freund von gemeinsamem Arbeiten an der Pinnwand, weil ich gemerkt habe, dass ich dort viel schneller viel bessere Ergebnisse erziele.

Und wenn ich das Ganze dann einmal stehen habe an der Pinnwand, es gibt dann so einen Moment, den wirst du dann auch feststellen, dann stehst du mit deinem Team vor der erarbeiteten Projektstruktur und alle beginnen so langsam zu nicken. Und jetzt weißt du, „Ja, super, jetzt haben wir eine Projektstruktur, die ist schon einmal RELATIV vollständig.“

Vorneweg:

Du wirst NIE 100 Prozent Vollständigkeit hinbekommen, dir wird immer irgendetwas durch die Lappen gehen.

Aber ich denke einmal so 90, 95 Prozent sind für den Anfang schon einmal ganz gut.

Tools zum digitalen Arbeiten

Und JETZT beginne ich das Ganze in eine Datei zu übertragen, also digital zu erfassen. Ich verwende in der Regel zwei Instrumente. Zum einen Powerpoint, das kennst du, da gibt es so eine Organigramm-Funktion, das dir eben quasi automatisch schon eine Baumdarstellung macht. Oder – was ich fast noch lieber verwende – ist eine Mindmapping-Software. Ich verwende hier auf Mac XMind, gibt aber auch andere Mindmapper, Mindmanager-Programme, die teilweise etwas kosten, die teilweise auch kostenlos sind. Im Wesentlichen aber alle die Funktion haben, dass sie auch solche Baumstrukturen darstellen können. Und das Ganze hat einfach den Vorteil, dass ich das nun digital habe, ich kann es auf meinem Projektverzeichnis anlegen, ich kann es verschicken, ich kann schnell Änderungen machen, ich kann es auch versionieren.

Also:

Ausarbeiten am Anfang am besten an Pinnwand, Moderationskarten, Whiteboard. Und wenn du dann einmal einen guten Stand hast übertrage das Ganze in eine digitale Datei.

Die Projektstruktur lebt

Wichtig ist mir dabei: Die Projektstruktur ist ein lebendes Dokument. AUCH wenn wir am Anfang hoffentlich schon die allermeisten Arbeitspakte aufgelistet haben, kommt in der Regel noch etwas dazu, es entfällt etwas oder es wird etwas umbenannt. Also deshalb keine Scheu, die Projektstruktur immer wieder anzupassen. Das Ziel der Projektstruktur ist, dass sie immer wieder den Arbeitsumfang deines Projektes wiedergibt. Und du kennst das: Projekte verändern sich, Projekte leben, und aus dem Grund wird sich auch die Projektstruktur damit verändern.

So, was bedeutet das nun für dich? Ja, ich bin der Meinung, dass es nahezu unmöglich ist, ein Projekt ohne Projektstruktur zu planen und zu steuern. Ich wüsste jedenfalls nicht, wie das gehen sollte. Gleichzeitig weiß ich aber, dass alle Projektleiter, die für ihre Projekte eine Projektstruktur haben, sich deutlich leichter tun, den Überblick zu bewahren, ihre Projekte zu steuern, zu planen, und am Ende erfolgreich abzuliefern. Und ja, ich beobachte aber auch immer wieder, dass die Projektstruktur in den wenigsten Fällen Anwendung findet.

Fragen zum Nach- und Weiterdenken

Auch dieses Mal möchte ich dir am Ende der Episode wieder ein paar Fragen mitgeben, mit auf den Weg geben, mit dem Ziel, dass du vielleicht ein wenig überprüfst, wie du arbeitest und was du tust und ob du da vielleicht etwas verändern möchtest.

  1. Was hast du denn bisher als Grundlage für deine Projektarbeit verwendet?
  2. Was war deine Mutter aller Instrumente?
  3. Und was hat dabei gut geklappt und was hat weniger gut geklappt?
  4. Worin siehst du den größten Nutzen der Projektstruktur für deine Projektarbeit?
  5. Wie würde denn die Projektstruktur für dein aktuelles Projekt ausschauen?

Dein Feedback

Du hast Fragen, Kommentare oder Anregungen zu dieser Episode oder zum Podcast? Dann schreibe mir einfach eine E-Mail an: joerg.walter@projektmanagement-maschinenbau.de