Einladung zum GRATIS-Videokurs für erfolgreiches Projektmanagement

Abonnieren

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

Diese Woche findet mein 3-teiliger GRATIS Videokurs für erfolgreiches Projektmanagement statt.

Ich werde immer wieder gefragt, ob ich nicht mein Wissen aus mehr als 15 Jahre Projektmanagement komprimiert zur Verfügung stellen kann. Ich habe mich entschieden dieses Wissen als 3-teiligen Videokurs aufzubereiten, zu dem ich Dich herzlich einlade!

Du wirst in diesem Videokurs lernen:

  • Warum aus meiner Sicht so viele Projekte scheitern
  • Was Du machen kannst um sofort dein Projektmanagement zu verbessern
  • Was Du tun kannst um ein erfolgreicher Projektleiter zu sein

Melde dich hier zum Videokurs an, damit ich Dich informieren kann, wenn die Videos online sind: www.projektmanagement-maschinenbau.de/videokurs

Ich freue mich sehr, wenn Du dabei bist!

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

PMMB036: Warum Du eine Zielsetzung brauchst und wie das genau geht

Abonnieren

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

Shownotes

Seneca: “Wer den Hafen nicht kennt, in den er segeln will, für den ist jeder Wind der Richtige”

Jedes Projekt braucht zwingend ein Projektziel, woher sollten wir denn sonst wissen, wohin wir segeln wollen? Dabei ist es jedoch sehr oft unklar, was ein Ziel überhaupt ist und wie man eine Zielsetzung formuliert. Dabei ist eine gute Zielformulierung die Grundlage für die Projektarbeit und für gutes Projektmanagement. In dieser Episode geht es darum besser zu verstehen, was eine Zielsetzung ist und wie Du sie am besten erstellst.

In dieser Episode erfährst Du

  1. Was ist ein Ziel und was nicht?
  2. Woran erkennst Du eine gute Zielformulierung
  3. Welche Möglichkeiten gibt es eine Zielformulierung zu erstellen

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

PMMB035: Risikomanagement ist Projektmanagement für Erwachsene

Abonnieren

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

Shownotes

In einem Gespräch mit einem Kollegen fiel neulich der Satz “Risikomanagement ist Projektmanagement für Erwachsene”. Der Satz hat mich eine ganze Weile nicht mehr los gelassen, weil ich glaube, dass da sehr viel Wahrheit drin steckt. Risikomanagement ist eine Haltung, die dazu führen kann, dass Deine Projekte erfolgreicher werden.

In dieser Episode erfährst Du

  1. Warum Risikomanagement Projektmanagement für Erwachsene ist
  2. Was das für Deine Haltung bedeutet
  3. Wie Du das in Deinen Projekten umsetzen kannst

Episoden, die ich erwähne

PMMB004 – Die Sache mit den Risiken

Vorlage zur Risikoanalyse in der Online-Bibliothek (kommt bald)

Buch Bärentango von Tom de Marco (Amazon Affiliate-Link)

 

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

PMMB034: Wie Du eine Vorbereitungsphase hinbekommst ohne aufzufallen

Abonnieren

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

Shownotes

Sehr oft erlebe ich es in meinen Projekten, dass wir als Projektleiter keine ordentlich Projektvorbereitungsphase durchführen “dürfen”. Dennoch halte ich die Projektvorbereitung für einen der wichtigsten Phasen im Projektmanagement. Warum das so ist und was Du tun kannst um diese Schritte nicht wegzulassen zu müssen erkläre ich Dir in dieser Episode.

In dieser Episode erfährst Du

  1. Welche guten Gründe und Argumente es für eine Projektvorbereitungsphase es gibt
  2. Meine Tipps, wie Du eine Projektvorbereitungsphase durchführen kannst ohne eine Projektvorbereitungsphase zu haben
    • Arbeite parallel!
    • Tu es einfach!
    • Nenne es nicht Projektvorbereitung
  3. Welche Schritte Du auf keinen Fall weglassen solltest

Episoden, die ich erwähne

PMMB007 – 5 Dinge auf die Du beim Projektstart achten solltest

PMMB008 – Das Projektumfeld im Griff behalten

PMMB033 – Wie Du die Ausgangslage Deines Projektes analysierst

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

PMMB033: Wie Du die Ausgangslage Deines Projektes analysierst

Abonnieren

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

Shownotes

Gut vorbereitet ist halb gewonnen. Das gilt nicht nur im Sport, sondern auch im Projektmanagement. Aus diesem Grund lege ich besonderen Wert auf die Projektvorbereitungsphase. Hierbei ist mir besonders die Analyse der Ausgangslage wichtig, die ich in der Regel mit einigen Fragen zum Projekt durchführe.

In dieser Episode erfährst Du

  1. Was es mit der Analyse der Ausgangslage auf sich hat und warum sie so wichtig ist
  2. Welche Fragen Du dabei stellen solltest
  3. Wie Du vorgehen kannst um die Ausgangslage zu akzeptieren

Episoden, die ich erwähne

PMMB007 – 5 Dinge auf die Du beim Projektstart achten solltest

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

PMMB016: Stell Dich der Realität!

Abonnieren

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

Shownotes

Ich beobachte es immer wieder in meinen Projekten, dass sich Projektleiter, Projektteams oder Auftraggeber verhalten, als gäbe es bestimmte reale Bedingungen nicht. Da werden Best Case-Planungen erstellt und Entscheidungen getroffen ohne die Konsequenzen zu berücksichtigen. In dieser Episode spreche ich darüber, an welchen Stellen wir dazu neigen uns der Realität zu verweigern und was Du tun kannst um dem zu begegnen.

Hierzu habe ich diese Episode wie folgt strukturiert:

  1. Was meine ich genau mit “Stell Dich der Realität”?
  2. An welchen Stellen solltest Du besonders darauf achten?
  3. Was kannst Du tun, damit sich auch andere der Realität stellen?
  4. 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

PMMB008: Das Projektumfeld im Griff behalten

Abonnieren

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

Projekte werden von Menschen gemacht, beeinflussen Menschen und werden von Menschen beeinflusst. Grund genug, sich als Gedanken zu machen, welche Personen sich in meinem Projektumfeld befinden und wie sie sich zu meinem Projekt positionieren. Stakeholder nennt man diese Personen.

In dieser Episode erfährst Du, wie man die Stakeholder in einem Projekt finden kann und wie man erkennt, wie sie das Projekt beeinflussen können.

In dieser Episode erfährst Du:

  • Was sind Stakeholder und was ist Stakeholdermanagement?
  • Warum ist es so wichtig, sich um Stakeholder zu kümmern?
  • Meine 4 Schritte, mit denen ich meine Stakeholder im Griff behalte
  • Tipps und Tricks beim Umsetzen
  • Meine Fragen an Dich zum Weiterdenken

In der Episode beschreibe ich das Stakeholder-Portfolio. Hier siehst Du, wie solch ein Portfolio aussehen kann.

Beispiel Stakeholder-Portfolio

Beispiel Stakeholder-Portfolio

Das Projektumfeld im Griff behalten

Nachdem wir uns ja in den letzten Podcast-Episoden mit den Phasen im Projektmanagement beschäftigt haben, geht es heute wieder etwas mehr um die Menschen. Projekte leben von Menschen, Projekte werden von Menschen durchgeführt und sie beeinflussen auch Menschen und sie werden auch von Menschen beeinflusst.

Projekte werden von Menschen beeinflusst

Grund genug also, sich hierüber mal ein paar Gedanken zu machen und der Fachbegriff im Projektmanagement dafür, für solche Menschen und für solche Personengruppen, ist Stakeholder. Das hast du vielleicht schon mal gehört. Ich werde da gleich auch noch mal genauer drauf eingehen.

Und so sprechen wir in dieser Episode über Stakeholder-Management.

Wie habe ich die Episode für dich aufgebaut? Wir werden zunächst mal im ersten Schritt uns anschauen, was sind denn eigentlich Stakeholder und was ist Stakeholder-Management? Im zweiten Schritt werden wir uns mal anschauen, warum es denn so wichtig ist, sich um die Stakeholder zu kümmern. Und im Hauptteil geht es dann darum, die vier Schritte mal auseinander zu nehmen, die erforderlich sind, um Stakeholder sozusagen im Griff zu behalten. Dann wird es natürlich wieder Tipps und Tricks von mir geben, die es dir vielleicht etwas leichter machen mit Stakeholdern umzugehen. Und ganz zum Schluss gibt es auch meine Fragen zum Weiterdenken. Das kennst du ja schon.

Was sind eigentlich Stakeholder?

Ja, dann steigen wir doch also mal direkt ein. Was sind denn eigentlich Stakeholder? Und was ist Stakeholder-Management?

Stakeholder zunächst mal vorne weg, ist ein Begriff, der aus dem Englischen kommt und Teilhaber heißt. Es gibt leider kein wirklich schönes deutsches Wort dafür. Wenn du eines hast, lass es mich gerne wissen.

Wikipedia sagt dazu,

als Stakeholder wird eine Person oder eine Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

Gabler Wirtschaftslexikon verwendet einen anderen Begriff. Gabler sagt oder spricht hier im Zusammenhang mit Stakeholdern von Anspruchsgruppen. Ich glaube, beides passt ganz gut. Es geht also um Menschen, die in irgendeiner Form betroffen sind, interessiert am Projekt sind oder tatsächlich sogar am Projekt echt beteiligt sind. Also Menschen, die sich im Umfeld eines Projektes befinden, die Interesse am Ausgang, vielleicht sogar auch am Verlauf eines Projektes haben.

Ob das jetzt nun ein berechtigtes oder ein unberechtigtes Interesse ist, das sei zunächst mal daran hingestellt. Zunächst mal haben sie ein Interesse.

Stakeholder sind nicht Shareholder

Ganz wichtig, einfach um den Begriff auch noch mal abzugrenzen, wir reden hier nicht von Shareholdern. Wir reden von Stakeholdern, nicht von Shareholdern. Shareholder sind nämlich Anteilseigner. Bei Unternehmen sind es zum Beispiel die Inhaber oder eben auch die Aktionäre. Da kommt der Begriff Shareholder her. Also an der Stelle bitte nicht verwechseln.

Was ist Stakeholdermanagement?

Was ist dem entsprechend dann Stakeholder-Management? Für mich zunächst mal ein sehr technisches, vielleicht auch bürokratisches Wortmonster.

Im Prinzip geht es darum, die Menschen, die sich im Projektumfeld befinden, sich mit denen zu beschäftigen, sie nicht außer Acht zu lassen, sie im Blick zu haben und vielleicht eine Vorgehensweise und einen Prozess zu haben, mit denen umzugehen, um auch besser zu verstehen, was die denn eigentlich wollen.

Warum sollten wir uns um Stakeholder kümmern?

Da kommen wir auch schon zum zweiten Punkt, warum es denn so wichtig ist, sich um Stakeholder zu kümmern. Sehr oft ist es doch auch so, dass Personen im Projektumfeld unterschiedliche Interessen und auch Sichtweisen haben. Und diese unterschiedlichen Interessen sollten wir in unseren Projekten kennen und vielleicht auch berücksichtigen.

Und ich glaube, es gibt wirklich ein paar gute Gründe, sich über die Menschen im Projektumfeld Gedanken zu machen.

Zum einen, wenn wir uns vielleicht mal anschauen, was das denn so sein könnte? Zum einen gibt es da vielleicht Gegner, also Menschen, die jetzt nicht gerade dein Projekt unterstützen und dem vielleicht eher so sogar entgegenstehen.

Das sind Risiken, die von diesen Menschen ausgehen können. Ich glaube, es macht Sinn, dass wir diese Risiken kennen und ein Stück weit vielleicht auch damit umgehen können. Und auch Gegner deines Projektes können Projekte tatsächlich behindern bis zum Stopp oder Abbruch.

Dann gibt es auf der anderen Seite auch sowas, wie Befürworter und Unterstützer. Und ich glaube, da gibt es ganz viele Möglichkeiten und Chancen, die in diesen Personen im Umfeld liegen. Die können dein Projekt nämlich beschleunigen, die können es unterstützen, die können Ihnen manchmal den wichtigen Kontakt besorgen und so weiter. Also glaube ich, ganz viele Möglichkeiten, die da eben drin sind.

Kenne die Menschen in Deinem Projektumfeld

Wenn man die Menschen in seinem Projektumfeld gut kennt, hat man eine gute Chance, Marketing für das Projekt zu machen. Und ja, sind wir ehrlich, selbstverständlich hängt der Projekterfolg des Projektes von der Arbeit ab, die das Projektteam gemeinsam macht. Aber eben auch vom Marketing, das um ein Projekt herum gemacht wird.

Und gerade am Anfang des Projektes macht es aus meiner Sicht Sinn, dann wenn du vielleicht an deinen Projektzielen arbeitest, besser zu verstehen, wer denn alles Interesse an deinem Projekt hat und auch deren Sicht auf die Dinge und die Ziele besser zu verstehen, um sie auch vielleicht ja dann im Projekt berücksichtigen und vielleicht sogar einbeziehen zu können.

4 Schritte für gutes Stakeholdermanagement

Wie geht man also vor? Ich habe die Erfahrung gemacht, dass es vier Schritte gibt, die da Sinn machen, um eben Stakeholder oder Menschen im Projektumfeld so ein bisschen einzubeziehen. Wir gehen zunächst mal die vier Schritte durch und ich würde dir dann Schritt für Schritt erklären, was ich damit meine.

Der erste Schritt ist, die Stakeholder zunächst mal zu identifizieren.

Im zweiten Schritt werden wir die Stakeholder dann bewerten und auch so ein Stück weit einordnen.

Wir werden sie im dritten Schritt analysieren und

wir werden im vierten Schritt dann im Prinzip so eine kleine Verfolgung oder Nachverfolgung noch haben.

1. Stakeholder Identifizieren

Beginnen wir mit dem ersten Schritt. Stakeholder identifizieren. Also hier geht es zunächst mal darum, wirklich zu sammeln, wer sind denn eigentlich die Stakeholder in meinem Projekt? Wer sind denn die Personen, die ein Interesse an meinem Projekt haben? Und wenn ich jetzt wieder an Projekte im Maschinenbau denke, dann fallen mir da zumindest mal der Auftraggeber ein, aber auch die Abteilungs- und Teamleiter, die Personen in mein Projekt entsenden.

Selbstverständlich die Geschäftsführung, der Inhaber des Unternehmens, aber auch meine Teammitglieder, die in meinem Team mitarbeiten. Der Kunde ist mit Sicherheit ein Stakeholder, auch wenn es dort verschiedene Personengruppen gibt, die durchaus noch unterschiedliche Interessenslagen haben können. Personen, die unser Produkt, unsere Maschine später bedienen. Also ich würde mal sagen, die Anwender sind Stakeholder mit Sicherheit.

Aber auch unsere Lieferanten und gegebenenfalls deren Lieferanten. Also Sublieferanten sind Personen, die da Interesse haben an unserem Projekt und gegebenenfalls, hängt natürlich wieder vom Projekt ab, sind es vielleicht auch mal Systempartner. Also andere Unternehmen, mit denen wir zusammenarbeiten, gerade auch in unserem Projekt.

Ich sammele also in der Regel einfach auf einem Flipchart oder auf einer Pinnwand und meistens ist das dann bei mir eine Sammlung mit so Moderationskarten und auf jeder Karte steht eben ein Name. Manchmal mache ich das dann aber auch mit einer Mindmap. Wenn ich keine Pinnwand, kein Flipchart, zur Hand habe, geht es auch ganz gut auf einem Schreibtisch oder einem Blatt Papier, hängt einfach auch davon ab, wie viel Personen da dabei sind.

Darauf komme ich aber auch später noch mal darauf zurück. Was mir ganz wichtig ist, bitte ganz konkrete Namen aufschreiben und nicht einfach Rollen. Also auf einer Karte sollte nicht stehen Abteilungsleiter, sondern ganz konkret der Name Müller, Meier, Schulze, weil nämlich verschiedene Personen, die vielleicht die gleiche Rolle, also zum Beispiel Abteilungsleiter haben, durchaus unterschiedliche Interessen und auch Positionierungen zum Projekt haben. Und das macht eben Sinn, das zu unterscheiden.

Fragen, die mir beim Identifizieren und beim Sammeln helfen, sind zum Beispiel, wer ist denn am Ergebnis des Projektes interessiert? Und wer liefert einen ganz konkreten Beitrag zum Projekt? Wer kann den Projektverlauf beeinflussen und wer trifft Entscheidungen für das Projekt? Wer will, dass das Projekt umgesetzt wird und wer will vielleicht nicht, dass das Projekt umgesetzt wird? All das sind Fragen, die ich immer so im Hinterkopf habe beziehungsweise auch meinen Teammitgliedern dann in der Moderation stelle, um so ein bisschen das Hirn anzukurbeln, um da eine wirklich gute Sammlung zusammen zu kriegen.

Als Ergebnis habe ich dann also eine Liste oder eine Mindmap mit Namen, die vor mir liegen. Das sind zunächst mal meine Stakeholder. Und mir ging es dann am Anfang sehr oft da so, dass ich etwas erschlagen war von der Menge. Weil wenn man sich tatsächlich mal Gedanken macht, wer denn da so alles Interesse, berechtigt oder unberechtigt, an meinem Projekt hat, dann kommt man sehr schnell mal auf 30 bis 40 Namen. Und dann kommt natürlich auch gleich die Frage auf, wie sollen wir denn das schaffen? Wie sollen wir denn mit denen allen umgehen?

Für mich sind da zwei Punkte wichtig, zwei Punkte zu sagen. Erstens. Diese Stakeholder existieren egal, ob du sie aufschreibst und damit identifizierst oder nicht. Die haben einen Einfluss auf dein Projekt. Ebenfalls egal, ob du sie aufschreibst oder nicht. Und ich denke, dass es Sinn macht diese Stakeholder zu kennen, denn die Alternative ist doch, den Kopf in den Sand zu stecken, also die Augen zu schließen und dann hätten wir wieder einen Blindflug im Projekt. Und ich glaube, das kann keiner wirklich wollen, der erfolgreiche Projekte umsetzen möchte.

Und der zweite Punkt ist, vielleicht gleich so als Entwarnung vorneweg: Keine Angst, wir müssen uns nicht um alle Stakeholder kümmern, zumindest nicht um alle im gleichen Maße.

2. Stakeholder bewerten und einordnen

Und genau aus diesem Grund gehen wir jetzt nämlich gleich auch weiter zum zweiten Schritt, Stakeholder bewerten und einordnen.

Worum geht es beim Bewerten und Einordnen der Stakeholder? Das Ziel ist zunächst einmal besser zu verstehen, wo denn die einzelnen Stakeholder stehen, wie sie sich zu unserem Projekt positionieren.

Dazu verwende ich normalerweise ein ganz einfaches Instrumentarium, um das besser herausarbeiten und auch visualisieren zu können, es ist sozusagen ein kleines Portfolio.

Stelle dir ein Diagramm vor. Das Diagramm hat zwei Achsen und diese Achsen helfen mir einfach meine Gedanken besser zu sortieren und vielleicht auch eine gezieltere Diskussion zu führen. Es gibt eine horizontale Achse und auf dieser Achse trage ich die Macht beziehungsweise den Einfluss dieser Person ein. Von null bis, sagen wir mal, zehn. Eigentlich braucht man keine Zahl, aber manchmal hilft es so ein bisschen in der Diskussion. Wenn ich keine Zahlen anschreibe, dann ist es eher so eine qualitative Diskussion.

Auf der vertikalen Achse trage ich dagegen die Einstellung der Person gegenüber meinem Projekt auf. Die vertikale Achse ist also die Einflussachse bei null. Nach oben trage ich dann alle ein, die eine positive Einstellung zu meinem Projekt haben und meistens schreibe ich dann an diese Achse ein lächelndes Smiley rein. Und nach unten die Personen, die eine negative Einstellung zu meinem Projekt haben, die das Projekt nicht möchten, die vielleicht auch gute Gründe haben, dass es nicht funktioniert. Da mache ich dann meistens so ein böses Smiley hin.

Falls du es dir jetzt gerade noch nicht vorstellen kannst, kein Problem, schaue einfach oben nach.

Im nächsten Schritt ordne ich jetzt nun jede Person, also jeden Stakeholder, den wir vorher gemeinsam gesammelt haben, in diesem Portfolio ein. Wie viel Einfluss hat er auf das Projekt? Wie viel Macht kann er ausüben, wenn er das denn will? Wie steht er denn zum Projekt? Findet er es gut, unterstützt er das gerne oder ist eher im Lager der Gegner einzusortieren? Oder ist er vielleicht sogar eher neutral? Also es ist ihm mehr oder weniger egal?

Es geht hier weniger um so eine exakte mathematische Bewertung und Positionierung, sondern eher um so eine Relation zueinander und um Ausprägungen, also eher so um Abstände. Wer befindet sich wo? Wer ist am äußersten Ende der Machtskala? Wer steht ganz oben in der Einstellung zu unserem Projekt. Und wer sind so die ganz großen Gegner.

Und so bekomme ich nun ein ganz grafisches, visuelles Bild von der Position meiner Stakeholder. Und ganz am Ende des Schrittes lege ich dann noch Prioritäten fest, weil ich mir ja gesagt habe, ich kann mich nicht um alle Personen kümmern. Das kostet einfach auch zu viel Zeit. Und meistens haben die Personen mit hohem Einfluss und einer sehr negativen Einstellung zum Projekt da eben eine sehr hohe Priorität, weil diejenigen, die sind, die mein Projekt killen können, zum Abbruch bringen können.

Personen mit eher weniger Einfluss haben meistens, wenn ich ehrlich bin, dann eine geringere Priorität. Die beobachte ich eher so ein bisschen. Es sei denn, es gibt da viele Einzelne, die eine sehr negative Einstellung haben, die haben nämlich zusammen dann irgendwann auch wieder einen größeren Einfluss. Am Ende dieses Schrittes, das Bewerten und Einordnen, steht also ein Portfolio, aus dem ich erkennen kann, wie wir die einzelnen Stakeholder bewertet haben, welche Priorität dann später für die Analyse haben.

3. Stakeholder analysieren

Und es ist auch schon der dritte Schritt, die Stakeholder zu analysieren. Bei der Analyse der Stakeholder geht es nun darum, besser zu verstehen, was die eigentlich denn wollen. Was treibt die um? Um dann in einem zweiten, kleinen Schrittchen auch festzulegen, welche Maßnahmen können wir denn einleiten, damit wir hier vielleicht mit dieser eventuellen kritischen Einstellung umgehen können.

Und da arbeite ich mich jetzt einfach wieder meinen Prioritäten entlang. Also die Stakeholder mit der höchsten Priorität bearbeite ich eben als aller erstes, weil ich natürlich auch meine Zeit effizient einsetzen möchte. Stakeholder, die eher auf der Beobachtungsliste stehen, die ich dort draufgesetzt habe, die schaue ich mir in diesem Schritt eher dann nicht mehr an.

Die Analyse mache ich meistens oder anhand so einer kleinen Tabelle. In der ersten Spalte trage ich dann die Stakeholder ein, also die Namen. Meistens auch noch die Rolle dahinter, also z.B. Abteilungsleiter, Auftraggeber, Kunde und so weiter und so fort. Und in der nächsten Spalte überlege ich mir dann, welche Ziele hat denn dieser einzelne Stakeholder. Was möchte der? Was ist ihm wichtig? Und welche Erwartungen hat er denn an das Projekt. Und dann überlege ich mir, also ich als Projektleiter auch gemeinsam mit meinem Team, was hätten wir denn gerne von diesem Stakeholder?

Das könnte zum Beispiel sein, ich hätte gerne Unterstützung. Oder ich hätte gerne schnelle Entscheidungen. Oder ich hätte gerne mehr Personal von ihm. Oder manchmal ist es auch einfach nur die Anwesenheit in bestimmten Situationen, bestimmten Präsentationen. Und das trage ich dann in die nächste Spalte in meiner Tabelle ein. Also was ist meine Erwartung an den Stakeholder?

Und ganz zum Schluss überlege ich mir dann, was könnte denn eine geeignete Maßnahme sein, damit ich diesen Stakeholder in Richtung meiner Erwartung bringe. Und das sind dann meistens Dinge, wie regelmäßige Informationen, zum Beispiel eine Einbindung in den Lenkungskreis, Integration von ganz bestimmten Mitarbeitern, Schlüsselmitarbeitern in meinem Projektteam, Berücksichtigung von bestimmten Dingen, Vorgehensweisen im Projektplan.

Das heißt, ich überlege mir ganz bewusst, was kann ich den tun? Was kann ich aktiv tun, um diesen Stakeholder mit seinen Zielen zu berücksichtigen und ihn so zu behandeln, dass er möglichst dorthin kommt, wo ich ganz gerne, wo ich ihn unterstützend in meinem Projekt wahrnehme?

Und natürlich ordne ich diese Aufgaben, die ich da gefunden habe, wieder einer Person zu, die das zu erledigen hat. Manchmal, sehr oft ist es der Projektleiter, weil das sehr oft Tätigkeiten sind, wo ich sage, da schmieren wir das Getriebe mit ein bisschen Öl. Manchmal ist es aber auch zum Beispiel der Auftraggeber oder einfach ein Teammitglied.

Als Ergebnis habe ich jetzt einfach eine ganz konkrete Liste mit Aufgaben, die abgearbeitet werden können und die mir dann einfach dabei helfen mein Projektumfeld deutlich besser im Griff zu behalten.

Die Betrachtung, die ich eben beschrieben habe, die mache ich nicht nur einmal, sondern ich beginne immer wieder im Projektverlauf meine Stakeholder zu beobachten und das ist auch gleichzeitig jetzt schon der vierte Schritt.

4. Nachverfolgung

Ich hatte ja gesagt, zum Abschluss verfolgen wir die Stakeholder nicht im Sinne eines Stalkings, sondern eher im Sinne eines kontinuierlichen Prozesses. Ich würde es auch Stakeholder-Monitoring nennen.

Das heißt, in regelmäßigen Abständen schaue ich mir mein Portfolio an, das ist diese Sicht der Stakeholder auf mein Projekt und überlege mir, hat sich denn daran etwas verändert und was?

Personen gewinnen im Laufe der Zeit an Einfluss oder sie verlieren und manchmal ändern sie auch ihre Sichtweise auf das Projekt, zum Beispiel weil wir Maßnahmen ergriffen haben.

Aber auch Ziele und Erwartungen an das Projekt verändern sich im Laufe der Zeit. Ich überprüfe also immer mal wieder, hat sich hier etwas verändert und passe dann gegebenenfalls meine Maßnahmen an oder leite auch mal neue ein.

Gelegentlich ist es auch so, dass Stakeholder, die zu Beginn noch auf meiner Beobachtungsliste standen, also keine Maßnahme bekommen haben, mehr und mehr ins Blickfeld kommen, sodass ich mich auch mehr um die kümmern muss. Dann kommen natürlich neue Aufgaben hinzu und andere sind unter Umständen auch nicht mehr erforderlich. Die Verfolgung der Stakeholder gehört für mich zu den ganz normalen Tätigkeiten, die ich dann im Rahmen meines fortlaufenden Projektmanagements erledige, ähnlich wie ich Termine und Kosten verfolge oder wie ich eben auch meine Teamsitzungen mache.

Jetzt hast Du meine vier Schritte kennengelernt, die ich in der Regel so anwende, um mein Projektumfeld im Griff zu behalten und ich hatte dir ja noch so ein paar Tipps und Tricks versprochen, die es vielleicht etwas leichter machen, damit auch umzugehen.

Wie erstellt man eine Stakeholderanalyse?

Beginnen wir mal immer, die erste Frage, die kennst du schon aus den vergangenen Episoden, im Team oder alleine?

Eine Stakeholder-Analyse kann man auch gut alleine machen, zumindest das Sammeln der Stakeholder und auch das Festlegen der Maßnahmen. Beim Bewerten und Einordnen hilft es dann aber ganz oft, verschiedene Blicke auf die Dinge zu haben. Und da macht es natürlich Sinn, das auch im Team zu machen. Grundsätzlich versuche ich die Analyse auch im Team zu machen, weil das mir einfach diese unterschiedlichen Sichtweisen wiederbringt.

Weil Themen hochkommen, an die ich vielleicht zunächst einmal gar nicht dran denke. Und es hilft auch, gerade beim Festlegen der Maßnahmen, der Aufgaben, wenn die Personen, die es später tun sollen, dann auch beim Festlegen dabei sind.

Stakeholder sind Menschen

Ein Punkt ist mir ganz wichtig. Wir reden bei Stakeholdern über Menschen. Und gerade bei der Diskussion, bei der Einordnung im Portfolio reden wir über Einfluss, Macht und Einstellung. Und ich glaube, da ist es ganz wichtig, dass gerade in dieser Diskussion, dass du darauf achtest, dass es hier einen sehr wertschätzenden Umgang miteinander gibt. Ich habe nämlich schon sehr oft erlebt, dass da über einzelne Stakeholder sehr abfällig gesprochen wird und ich glaube, das ist der Sache nicht dienlich. Wir sitzen zusammen und reden über andere Menschen und ihre Sicht auf die Dinge, ihre Sicht auf unser Projekt. Und noch mal, ganz wichtig, achte bitte darauf, dass hier ein wertschätzender Umgang stattfindet.

Auch wichtig: Wenn eine Person eine negative Einstellung, also ein Stakeholder, eine negative Einstellung zu unserem Projekt hat, heißt das nicht, dass er ein schlechter Mensch ist. Er hat lediglich andere Ziele, andere Erwartungen und das ist völlig legitim, dass er die hat. Und es ist unsere Aufgabe, das ein Stück weit zu berücksichtigen und auch damit umzugehen. Und unser Ziel ist ja seine Sicht auf unser Projekt zu verändern und in unserem Sinne zu verbessern.

Meine Erfahrungen für Dich

Es gibt noch so ein paar Erfahrungen, die ich gemacht habe, die ich dir gerne mitgeben möchte. Also das Sammeln der Stakeholder funktioniert, aus meiner Sicht, am besten auf Papier oder mit Moderationskarten. Das ist kreativer, da passiert mehr im Kopf. Das ist aktiver und das ist einfach besser, als wenn zehn Menschen gemeinsam auf eine Leinwand, auf ein Beamerbild starren.

Ich glaube, ich habe es in den vergangenen Episoden schon mehrmals gesagt, ich glaube, es gibt nichts Schlimmeres, als solch eine Situation. Da entsteht nichts Neues. Wenn ich die Namen auf die Karten geschrieben habe, dann fällt es mir auch leichter, gleich die Einordnung zu machen, weil ich die Karten an der Pinnwand so lange verschieben kann, bis sie an der richtigen Stelle sind.

Auch da ist so eine digitale Lösung, meistens nicht richtig gut. Das Sammeln der Erwartungen und der Ziele und auch das Festlegen der Maßnahmen, das hingegen funktioniert dann am besten wieder, wenn ich mit so einer Tabelle zum Beispiel in Excel arbeite und dann übertrage ich den ganzen Kram dann einfach wieder.

Dann arbeite ich dann gerne wieder mit dem Rechner, zumal es auch einfach eine sehr gute Grundlage ist, die Stakeholder dann Schritt für Schritt zu verfolgen.

Und ganz wichtig, so ein letzter Tipp: Versuche es in deinen Ablauf einzuplanen. Ich habe für mich so eine kleine Checkliste, die ich jede Woche, jeden Monat oder auch einmal im Quartal quasi abarbeite. Die mir sicherstellt, dass ich an alle Dinge denke, die ich mir regelmäßig anschauen soll. Und da steht zum Beispiel das Thema Terminplanung drauf. Da steht drauf, dass ich meine Projektkosten regelmäßig aktualisiere und auf dieser Liste steht selbstverständlich auch die Stakeholder-Analyse. Und damit stelle ich sicher, dass ich in meiner regelmäßigen Management-Projekt-Verfolgungsarbeit die Stakeholder nicht vergesse.

Meine Fragen zum Nach- und Weiterdenken

Und jetzt sind wir auch schon bei meinen Fragen an dich zum Weiterdenken. Die Fragen haben ja immer so ein bisschen die Idee, das, was wir heute gemeinsam besprochen haben noch mal ein bisschen in deinem Kopf widerhallen zu lassen. Und die Frage ist für dich:

Wer sind denn in deinem Projekt die wesentlichen Stakeholder und wie stehen die denn zu deinem Projekt und welchen Einfluss haben die?

Was könntest du tun, um diese Einstellung zu deinem Projekt zu verändern?

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

PMMB007: 5 Dinge auf die Du beim Projektstart achten solltest

Abonnieren

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

Ein guter Projektstart sorgt dafür, dass gute Rahmenbedingungen für die Projektplanung und den weiteren Projektverlauf existieren. Leider wird die Projektstartphase sehr oft nicht konsequent durchgeführt, was Projekte dann in Schwierigkeiten bringt.

Ich lege beim Projektstart besonderen Wert auf 5 Dinge, die ich Dir in dieser Episode erkläre:

  • Auftragsklärung
  • Teamzusammensetzung
  • Organisatorisches
  • Ausgangslage
  • Risiken

Ich habe die Episode dafür für Dich folgendermaßen strukturiert:

  1. Was ist eigentlich der Projektstart?
  2. 5 Dinge auf die Du achten solltest
  3. Wie kannst Du den Projektstart organisieren?
  4. Was bedeutet das für Dich?
  5. Meine Fragen an Dich zum Weiterdenken

5 Dinge auf die Du beim Projektstart achten solltest

Im letzten Beitrag ging es ja um die vier Phasen im Projektmanagement. Und heute möchte ich das noch mal etwas vertiefen, und zwar ganz besonders die erste Phase, die Projektstartphase.

Es gibt so eine Beobachtung dass, wir hatten es beim letzten Mal schon drüber, sehr viele Projekte scheitern, beziehungsweise tun sich im weiteren Verlauf schwer. Und ich glaube, dass eine der Ursachen darin liegt, dass die Projekte eben nicht ordentlich gestartet werden. Und das ist, glaube ich, auch gleichzeitig so ein Grund, warum es Sinn macht sich noch mal intensiver mit dem Projektstart, mit der Projektstartphase zu beschäftigen, weil, Projekte ordentlich zu starten, heißt nämlich deren Erfolgschancen zu erhöhen und gute Grundlagen für die Weiterarbeit zu legen.

Es macht Sinn sich mit dem Projektstart zu befassen

Du siehst, es macht also Sinn, sich zu überlegen, was für einen wirklich guten Projektstart erforderlich ist.

Um was geht es also in dieser Episode? Was wirst du erfahren?

Wir werden noch mal einsteigen mit der Frage: Was ist eigentlich dieser Projektstart? Werden dann noch mal ein bisschen tiefer einsteigen und du wirst dann meine fünf Dinge, meine fünf Tipps kennenlernen, fünf Dinge, auf die ich beim Projektstart besonderen Wert lege und auf die du vielleicht auch achten solltest. Wir werden dann noch mal gemeinsam diskutieren, wie man diesen Projektstart gut organisieren kann und noch mal schauen, was das für dich bedeutet. Und wie gehabt, wir schließen auch diesen Beitrag mit meinen Fragen für dich zum Weiterdenken ab.

Was ist der Projektstart

Also Projektstart. Was ist denn das nun? Du erinnerst dich vielleicht aus dem letzten Beitrag, wir haben festgestellt, dass ein Projekt aus mehreren Phasen besteht, das Projektmanagement aus mehreren Phasen besteht.

Es gibt die Projektstartphase, die Projektplanungsphase, dann gibt es eine Phase der Projektdurchführung und ganz zum Schluss eben auch noch den Projektabschluss.

Ganz oft ist es so, dass Projektplanung und Projektdurchführung ineinander rein verschwimmen, ineinander sich rein verschachteln. Das ist immer dann, wenn der Auftraggeber ganz besonders ungeduldig ist und nicht erwarten kann, dass das Projektteam eine Planung vorlegt, sondern gerne hätte, dass da schon gearbeitet wird. Es ist auch oft so, dass wenn Projekte schon laufen, ohne geplant worden zu sein, dann muss man diese Planung nachholen.

Und der normale Fall, das ist auch, glaube ich, aus meiner Sicht, der einzig akzeptable, ist, dass wenn die Planung eben noch nicht vollständig gemacht wurde, weil sie vielleicht auch noch nicht vollständig gemacht werden konnte, weil man zu Beginn des Projektes noch nicht den vollen Umfang des Projektes überschauen konnte. Auch dann wird die Planung so ein Stück weit nachgeholt und Projektplanung und Projektdurchführung verschachteln sich ineinander, verschwimmen ineinander.

Warum wird die Projektstartphase vernachlässigt

Projektstart, die erste Phase, wird leider sehr oft gar nicht durchgeführt. Es hat, glaube ich, mehrere Gründe. Einer davon ist, der Projektstart wird schlicht und ergreifend vergessen. Wir starten direkt mit der Planung.

Ein weiterer ist, dass sich einfach auch nicht die Zeit dafür genommen wird. Schnell, schnell! Es muss losgehen. Wir haben schon die ersten Termine mit dem Kunden. Wir müssen erste Ergebnisse vorlegen. Und weder der Auftraggeber, noch das Projektteam gibt sich eben die Zeit oder nimmt sich die Zeit, um einen ordentlichen Projektstart durchzuführen.

In vielen Fällen ist es auch gar nicht bekannt, dass es diese Phase überhaupt gibt, was unter anderem einer der Gründe ist, warum ich diesen Beitrag mache und den letzten übrigens auch.

Was ist die Projektstartphase

Also was meine ich jetzt noch mal mit Projektstart? Ich meine die Phase, bevor die eigentliche, konkrete Planung begonnen wird.

Und mit Planung meine ich, ich erstelle eine Projektstruktur, leite einen Terminplan ab, ermittle Ressourcen, mache ein Projektbudget, erstelle eine Kommunikationsstruktur, diese Dinge. Und es geht also um die Phase davor. Und da gibt es tatsächlich eine.

Noch mal zur Wiederholung:

Das Ziel dieser Projektstartphase ist für gute Rahmenbedingungen zu sorgen, Arbeitsfähigkeit herzustellen, für Klarheit zu sorgen.

5 Punkte, auf die bei der Projektstartphase zu achten sind

Auch zu Beginn das Team zusammenzustellen und das Team zu formen und wie soll ich sagen, die ersten Wege zu ebnen, damit wir loslaufen können. Und was passiert nun konkret in dieser Phase? Auf welche Dinge solltest du achten, damit du hier möglichst gut arbeiten kannst? Für mich sind es fünf Punkte, auf die ich besonders achte, auf die ich besonderen Wert lege. Gehen wir sie erstmal durch und dann schlage ich vor, dass wir jeden einzelnen Punkt vielleicht noch mal im Detail erläutern.

  1. Was ist der Auftrag? Um was geht es eigentlich?
  2. Wer soll denn das Projekt bearbeiten?
  3. Wie organisieren wir das Team?
  4. Was wissen wir bereits über die Ausgangslage?
  5. Welche Risiken sehen wir?

Was ist der Auftrag?

Steigen wir ein. Punkt eins, was ist der Auftrag? Um was geht es eigentlich? Ganz oft bekommen wir Projekte mit nur einem sehr diffusen Auftrag zugeteilt. Da fallen dann Sätze wie, „kümmern Sie sich mal um das Projekt, dass wir Punkt, Punkt Punkt, gestern mit dem Kunden besprochen haben.“

Oder, „guten Tag, Herr Soundso. Wir suchen einen Projektleiter für dieses und jenes Projekt. Da haben wir doch an Sie gedacht. Legen Sie doch einfach mal los.“

Du merkst, in vielen Fällen nur ein mündlicher Auftrag und wenn überhaupt, dann nur ein Auftrag. Keine konkrete Zielsetzung und da gibt es einen großen Unterschied. Was es im Detail bedeutet, werden wir noch mal in einem späteren Beitrag behandeln.

Aber es gibt einen großen Unterschied zwischen Projektauftrag und Zielsetzung. Und ich glaube, unsere erste Aufgabe hier in der Projektstartphase ist mal diesen Auftrag zu klären. Und zwar in der Regel, ich glaube, das bietet sich an, mit dem Auftraggeber mal zu klären, handelt es sich tatsächlich um ein Projekt oder ist es einfach nur eine Aufgabe, die jetzt komischerweise mit dem Begriff Projekt etikettiert wurde und dass wir diese Aufgabe eigentlich gar nicht in Projektform abarbeiten sollten oder dürfen?

Und die Frage auch zu klären, woher kommt der Auftrag? Wer hat den erfunden? Wo kommt die Idee her? Wer möchte das Projekt eigentlich haben? Was steckt dahinter und wer hat Interesse an dem Projekt und wer auch irgendwie nicht?

Da fällt jetzt natürlich relativ schnell der Begriff Stakeholder-Analyse, also Projekt-Umfeldanalyse. Wie das im Detail geht, auch da gibt es noch mal einen Beitrag dazu. Aber so viel schon mal vorne weg, es macht eben Sinn, dieses Auftragsumfeld mal zu durchleuchten. Und wenn wir die Frage nach dem Auftrag stellen, dann ist natürlich auch die Frage, gibt es denn tatsächlich schon eine Zielsetzung, also etwas mehr, als nur diesen einen Auftrag? Das sind so die Fragestellungen, die sich um den ersten Punkt ranken. Was ist denn eigentlich der Auftrag und um was geht es?

Wer soll das Projekt bearbeiten

Direkt daran schließt sich dann auch die Frage an, wer soll denn das Projekt bearbeiten? Also wer soll Teil des Teams sein? Meistens ergeben sich aus der Aufgabenstellung schon bestimmte natürliche Ansprechpartner.

Also ich brauche jemand aus der Produktionsvorbereitung, aus der Arbeitsvorbereitung. Ich brauche jemanden aus dem Quality-Engineering. Ich brauche einen Software-Entwickler, ich brauche einen Hardware-Entwickler, ich brauche einen Konstrukteur, einen technischen Zeichner und so weiter und so fort. Also kannst du dir vorstellen, das kennst du auch in deinen Projekten, aus der Aufgabenstellung ergibt sich zunächst einmal eher so ein natürliches Team.

Und die Frage, die man klären muss, wer sind denn jetzt die Ansprechpartner und mit wem sollte ich denn auch mal sprechen? Hat denn zum Beispiel dieses Projekt eine Historie und gibt es Wissen oder Personen, die ich da auch einbinden könnte, damit das alles ein bisschen flüssiger läuft. Und wer hat auch Wissen zum Vorhaben? Wer kann uns denn da weiterhelfen?

Natürlich, meistens ändert und erweitert sich das Team in der Planungsphase dann noch mal, wenn die Arbeitspakete konkreter werden und wenn sich zum Beispiel herausstellt, dass wir eine umfangreiche Simulation benötigen, dann kommen natürlich Personen ins Team, die wir in dieser ersten Abschätzung noch nicht so auf dem Schirm hatten. Aber grundsätzlich macht es schon Sinn, sich diese Frage nach dem initialen Team einmal zu stellen.

Ganz wichtig ist mir da an der Stelle auch unterschiedliche Sichtweisen, unterschiedliche Blickwinkel und auch unterschiedliche Wissensstände ins Team hereinzuholen, weil ich die Erfahrung gemacht habe, dass dann einfach das Nachdenken, das gemeinsame Arbeiten in der Gruppe deutlich einfacher und deutlich besser vonstattengeht. Also zweite Frage, wer sollte das Projekt eigentlich bearbeiten.

Wie organisieren wir das Team

Kommen wir zum Punkt drei. Wie organisieren wir das Team? Das ist jetzt eher so ein organisatorisches Thema, also zunächst einmal festzulegen, wann und wo treffen wir uns? Wie soll auch die Planungsphase vonstattengehen? Wo legen wir unsere Dokumente ab? Hat dieses Vorhaben oder dieses Projekt schon eine Nummer? Und welche Rollen gibt es denn eigentlich im Projekt? Wer ist Projektleiter? Welche anderen Rollen gibt es? Gibt es so etwas, wie eine Projektassistenz oder ein Projektbüro, das wir sehr oft mal haben bei größeren Projekten?

Alle diese Rollen sind mal zu klären. Und ich glaube es macht auch Sinn, hier schon die ersten, speziellen Spielregeln im Projekt festzulegen, falls es die denn gibt. Also Punkt drei, Frage nach der Organisation des Teams. An der Stelle einfach mal durchleuchten, welche organisatorischen Themen sind denn für das Projekt relevant?

Wie ist die Ausgangslage

Punkt vier, wie ist die Ausgangslage? Und das ist jetzt, glaube ich, so ein wesentlicher Punkt, der ganz oft in Projekten nicht gemacht wird, nicht sauber gemacht wird und nicht strukturiert gemacht wird und vor allem auch das Ergebnis nicht dokumentiert wird.

Aus meiner Sicht ein Punkt, der extrem stark unterschätzt wird. Nun ist die Frage nach dem, was wir denn heute schon über dieses Projekt wissen, also wie kam es zu diesem Projekt? Gibt es schon Ideen zur Vorgehensweise? Gibt es bestimmte Vorgaben? Also gibt es schon einen Terminrahmen? Gibt es einen Kostenrahmen? Gibt es einen speziellen Rahmen an Personal und Ressourcen, die uns zur Verfügung stehen? Und auch so Dinge, woran müssen wir denn denken? Alles Fragen, die dazu führen, dass wir ein deutlich besseres Wissen über die Ausgangslage haben.

Welche Risiken sehen wir

Kommen wir auch schon zum fünften Punkt. Das ist die Frage nach den Risiken. Welche Risiken sehen wir? Und du merkst, ich bin ein Freund einer ganz frühen Risikoanalyse im Projekt. Das hat mehrere Gründe. Erstens, es bremst am Anfang auch schon einmal ein klein wenig die Euphorie, also die positiven Dinge, den Nutzen, die Chancen, die sehen wir oft von alleine. Da muss uns keiner drauf aufmerksam machen.

Die Dinge, die schiefgehen können, die blenden wir gerade in der frühen Phase sehr oft aus. Wenn ich eine strukturierte Risikoanalyse mache, bekomme ich doch ein sehr gutes Gefühl über die wahre Situation im Projekt und ich kann daraus, aus meiner Sicht, auch ganz gut eine Projektstrategie ableiten. Also wie wollen wir vorgehen? Was sind Schwerpunkte im Projekt? Und ich kann auch davon ausgehend, schon die ersten Arbeitspakete ableiten, die wir dann später natürlich in der Projektstruktur brauchen.

Wichtiger Hinweis: bitte mache die Risikoanalyse im Team.

Ich habe es vorhin schon gesagt, als wir diskutiert haben, wer denn Teil des Projektes sein sollte, unterschiedliche Blickwinkel, unterschiedliches Wissen, unterschiedliche Fachbereiche sind hier extrem bereichernd.

Und schaue, dass du die Risikoanalyse methodisch unterstützt machst. Also nicht nur ein reines Brainstorming, das hinterher eine große Sammlung an möglichen Risiken hinterlässt, weil sehr oft hilft uns das nicht wirklich weiter. Schau, dass du eine ordentliche Bewertung hinbekommst und bitte, bitte, vergiss die Maßnahme nicht. Also entsprechende Risiken oder Risiken mit einer entsprechenden Höhe, sollten immer mit einer Maßnahme belegt sein. Wie du eine einfache Risikoanalyse machen kannst, hast du in einem der letzten Beiträge hier auch schon erfahren. #00:13:17-2#

Das waren sie auch schon, die fünf Punkte.

Wie kannst Du den Projektstart gut organisieren

Ich habe es eingangs gesagt, sehr oft findet leider, leider die Projektstartphase nicht wirklich statt. Und das hat auch damit zu tun, dass es den Teams sehr oft unklar ist, wie man denn so etwas organisiert.

Und da kommen wir auch jetzt schon zum dritten Punkt, wie kann man denn den Projektstart gut organisieren?

Grundsätzlich glaube ich, ist diese Phase, der Projektstart eine Phase, die unterschiedlich lang dauern kann. Viele der eben genannten Punkte kann man, glaube ich, in einem Workshop, und da spreche ich jetzt von einem Workshop von maximal einem Tag, gemeinsam durchsprechen.

Das ist nicht gut geeignet für die Auftragsklärung. Die geschieht oft besser und auch effizienter vorab in Einzelgesprächen mit dem Auftraggeber oder mit den Auftraggebern, mit den einzelnen Fachbereichen.

Aber gerade das Thema Ausgangslage, Risiken, wie organisieren wir uns im Projekt, all das sind Dinge, die du sehr gut in einem Workshop erarbeiten kannst. Deswegen an der Stelle meine Empfehlung, schaue, dass du so eine Art Projektstart-Workshop organisieren kannst.

Fokussiere dich auf die Zielsetzung, die du schon mitbringst, die du mit der Auftragsklärung, die du idealerweise vorab schon geklärt hast mit deinem Auftraggeber, sodass dort möglichst wenig Fragen noch offen sind und fokussiere dich dort im Start-Workshop auf die Ausgangslage, auf die Risiken und auf die Organisation im Team. Und ich glaube, dann sind die wesentlichen Punkte auch schon abgedeckt. Meistens ist es tatsächlich so, dass Startphase dann auch etwas mit der Planungsphase verschwimmt.

Was bedeutet das für Dich

Was bedeutet das jetzt für dich? Fassen wir es noch mal zusammen. Der Projektstart wird viel zu oft vernachlässigt oder gar nicht gemacht, überhaupt nicht berücksichtigt. Damit dein Projekt aber gut in Gang kommt, macht es Sinn, hier einen echten Fokus drauf zu haben, weil der Projektstart die Grundlage für die weitere Planung legt.

Und wenn die Grundlage gut ist, ist auch eine gute Chance, dass deine weitere Planung solide ist. Ein guter Projektstart schafft Klarheit. Und du solltest dir für deine Projekte überlegen, welche Punkte denn für dich wichtig sind. Meine fünf Punkte, meine fünf Dinge, die ich bei jedem Projektstart berücksichtige, habe ich dir ja eben erläutert.

Meine Fragen für Dich zum Nach- und Weiterdenken

Auch in dieser Episode möchte ich mich wieder mit ein paar Fragen für dich zum Weiterdenken von dir verabschieden. Ich hätte ganz gerne, dass du einmal darüber nachdenkst,

  • Wie hast Du denn in der Vergangenheit den Projektstart, die Projektstartphase in deinen Projekten organisiert
  • Was war dir dabei wichtig und was war dir weniger wichtig?
  • Für dein nächstes Projekt, worauf möchtest du denn da gerne achten?

Lass mich gerne wissen, was das Ergebnis deiner Überlegungen ist.

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

PMMB006: Phasen im Projektmanagement

Abonnieren

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

Auch Projektmanagement lässt sich in verschiedene Phasen unterteilen:

  • Projektstartphase
  • Projektplanungsphase
  • Projektumsetzungsphase
  • Projektabschlussphase

Jede dieser Phasen hat ihre speziellen Schwerpunkte und Themen. Und jeder dieser Phasen hat Ihre Berechtigung. In Dieser Episode lernst Du die einzelnen Phasen kennen und erfährst warum es aus meiner Sicht Sinn macht jeder Phase genügen Zeit im Projekt einzuräumen.

Ich habe die Episode dafür für Dich folgendermaßen strukturiert:

  1. Welche Phasen gibt es Denn überhaupt?
  2. Warum solltest Du Dich mit den Phasen im Projektmanagement beschäftigen?
  3. Welche Fragen und Themen sind in den einzelnen Phasen wichtig?
  4. Was bedeutet das für Dich?
  5. Meine Fragen an Dich zum Weiterdenken

Episoden, die in der Episode erwähnt wurden:

Phasen im Projektmanagement

Dieses Mal geht es ums Projektmanagement. Und noch genauer, um die Phasen im Projektmanagement. Vielleicht fragst du dich nun, „Phasen im Projektmanagement? Welche Phasen? Wir machen Projektmanagement und das ist gut.“

Ja, das ist schon richtig, ich glaube es ist aber vielleicht ein wenig zu kurz gesprungen. Projektmanagement lässt sich nämlich in unterschiedliche Phasen aufteilen und jede Phase hat ihren speziellen Schwerpunkt, ihre eigenen Fragestellungen und ihre eigenen Themen, die zu dem Zeitpunkt jeweils wichtig und relevant sind. Also heute geht es um Phasen im Projektmanagement.

  • Was erwartet dich in dieser Episode?
  • Welche Phasen gibt es denn überhaupt?
  • Warum du solltest Du Dich mit den Phasen im Projektmanagement beschäftigen?
  • Welche Fragen, Themen, Schwerpunkte sind denn in den einzelnen Phasen wichtig?
  • Was bedeutet das für Dich?

Die Phasen im Projektmanagement

Also Phasen im Projektmanagement. Welche gibt es denn überhaupt? Ich glaube, Projektmanagement kann man in grundsätzlich vier Phasen unterteilen.

Es gibt eine Projektstartphase, es gibt eine Planungsphase, eine Projektumsetzungsphase und zum Schluss eine Projektabschlussphase. Also zunächst mal nichts wirklich Kompliziertes. Wichtig ist, glaube ich, mit diesen vier Phasen decken wir die komplette Laufzeit eines Projektes ab. Also von der aller ersten Idee, von der aller ersten Übergabe der Idee vom Auftraggeber an den Projektleiter bis zum vollständigen Abschluss des Projektes.

Jede Phase hat Ihre Berechtigung

Ja, du hast ja schon gemerkt, Vollständigkeit im Projekt ist mir sehr wichtig. Aus diesem Grund sind mir auch diese Phasen im Projektmanagement sehr wichtig, weil sie eben alle ihre Berechtigung haben und weil ich glaube, dass etwas fehlt, wenn man die eine oder andere Phase nicht so richtig durchläuft.

Ein Punkt ist mir noch ganz wichtig. Ja, du hast schon gemerkt, die Phasen bauen aufeinander auf. Sie bilden sozusagen eine logische Abfolge. Es macht eben keinen Sinn, zunächst in die Umsetzungsphase zu gehen und dann in die Startphase zu springen.

Alle vier Phasen oder diese vier Phasen bilden sozusagen einen logischen Ablauf, einen logischen Prozess ab, den man auch Schritt für Schritt durchlaufen kann.

Warum solltest Du Doch mit den Phasen beschäftigen?

Warum ist es denn nun so wichtig, sich mit diesen Phasen im Projektmanagement zu beschäftigen und warum solltest du das tun? Da möchte ich so eine kleine Erfahrung mit dir teilen und ich bin sehr gespannt, ob du da ähnliche Beobachtungen, ähnliche Erfahrungen gemacht hast?

Wenn ich in den Projekten, auf die ich so bei meiner Tätigkeit stoße, schaue, dann kann ich die Projektumsetzungsphase selbstverständlich in jedem Projekt beobachten. Das ist logisch. Sonst hätten wir ja kein Projekt. An den Projekten gearbeitet wird immer.

Manchmal ist keine Planungsphase zu erkennen

Wenn ich mir jetzt dann anschaue, wie stark die Projektplanungsphase ausgeprägt ist, wie gut das da gemacht wird und wie intensiv da gearbeitet wird, dann wird es schon schwieriger. In einigen Projekten gibt es nämlich gar keine klare Projektplanungsphase. Da wird nicht geplant, gemeinsam bewertet, durchdacht bis eine Projektplanung entsteht, sondern einfach direkt losgelegt.

Ja. Ja. Sehr oft verschwimmt natürlich die Planungsphase mit der Umsetzungsphase, was total okay ist und in ganz vielen Fällen auch richtig. Aber in vielen Projekten gibt es eben diese klare Planungsphase überhaupt nicht. Da wird einfach direkt losgelegt.

Da wird vielleicht parallel geplant, meistens dann aber auch doch nicht. Wir sind ja auch gerade mit Abarbeiten beschäftigt. So viel Zeit haben wir nun dann doch nicht.

Und die Beobachtung ist, in den meisten solcher Projekte geht dann irgendetwas mächtig schief. Also eine richtig gute Planungsphase zu beobachten, ist echt selten, was ich tatsächlich sehr schade finde.

Die Projektstartphase gibt es noch seltener

Die Startphase findet man noch seltener in den Projekten. Ich komme gleich noch dazu, was da eigentlich gemacht wird, aber so viel schon mal vorne weg, hier wird das Projekt vorbereitet, sozusagen der Grundstein gelegt. Und du kannst dir gut vorstellen, was passiert, wenn in Projekten der Grundstein nicht gelegt wird.

Häuser, wenn ich ein Haus baue ohne Grundstein, Häuser fallen um. Und bei Projekten ist es sehr oft nicht wirklich anders.

Der Projektabschluss kommt häufig zu kurz

Schaue ich mir den Projektabschluss an in den Projekten, auf die ich so stoße, dann findet er sehr oft statt, aber nicht wirklich richtig gut. Leider haben viele Projekte keinen richtigen Projektabschluss, was dazu führt, dass das Projekt nie wirklich endet. Die Teams bleiben weiterhin sozusagen in Amt und Würden, die bleiben Ansprechpartner, auch wenn die Kollegen eigentlich schon wieder in ganz anderen Projekten stecken.

Also kurz gesagt, wenn ich ein Projekt ordentlich starte, dann macht das, glaube ich, auch Sinn es ordentlich zu beenden. Und das mache ich in der Abschlussphase.

Keine Projektphase sollte weggelassen werden

Du merkst, jede dieser Phasen hat ihre Bedeutung und ihre Notwendigkeit. Und ich bin der Meinung, dass keine der Phasen davon wirklich weggelassen werden sollte, weil sonst etwas Wesentliches im Projekt fehlt. Das würde dann einfach zu Risiken und später zu echten Problemen führen. Und ich glaube, das kann keiner von uns wollen.

Also schaue bitte, dass du alle Phasen in deinem Projekt durchläufst, auch wenn es nur ganz kurz ist, denn jede Phase hat ihre Berechtigung.

Jetzt haben wir schon viel über die Phasen gesprochen, aber was ist denn das Ziel der einzelnen Phasen und was sind denn so die Dinge, die da passieren. Gehen wir sie mal von vorne nach hinten durch und starten mit der Projektstartphase.

Ziele der Projektstartphase

Ich glaube, das Ziel, ich habe es eben schon so ein bisschen angerissen, das Ziel der Projektstartphase ist für Klarheit zu sorgen, eine gute Basis zu legen und das Team aufzubauen, das später das Projekt bearbeiten soll.

Kurz gesagt: für Orientierung und Klarheit zu sorgen.

Die Fragen und die Themen, die in der Phase beantwortet werden dürfen, gehen so natürlich in die Richtung der Grundlagen. Also zunächst mal, was ist denn eigentlich die Zielsetzung? Was ist unser Auftrag? Was haben wir bekommen? Was ist das, was wir tun sollen?

Damit verbunden natürlich auch gleich die Frage, welche Priorität hat denn unser Auftrag und in unseren technischen Projekten in der Regel gibt es denn eigentlich schon ein Lastenheft? Und wie vollständig ist denn dieses Lastenheft? Sind denn alle Punkte schon abgedeckt oder ist das im Moment noch so ein halbvollständiger Draft-Entwurf? Im Idealfall habe ich zu diesem Zeitpunkt schon ein freigegebenes Lastenheft. Sehr, sehr oft aber leider nicht. Dennoch sollte das Lastenheft, glaube ich, in dieser Phase schon einen Stand haben, der so vollständig ist, dass wir ein sehr klares Bild über die Aufgabenstellung bekommen.

Ein weiterer Punkt, der so wichtig in der Startphase ist, ist mal zu klären, wer denn im Projekt den eigentlich mitarbeiten sollte. Wer ist Projektleiter? Wer ist denn im Kernteam? Wer sind denn weitere Teammitglieder? Wer sind denn die Personen, die das Ding am Ende wuppen sollen? Und damit verbunden auch gleich wieder die Frage: wer ist denn eigentlich der Auftraggeber? Also wer ist der wirkliche Auftraggeber? Und was ist ihm oder ihr eben besonders wichtig? Was sind ihre Prioritäten und vielleicht auch was ist denn die Motivation, warum machen wir denn dieses Projekt? Was verbirgt sich eigentlich dahinter? Und worauf sollten wir da besonders achten?

Eng verbunden mit dem Auftraggeber ist sehr oft dann auch in dieser Phase schon die Frage nach dem Lenkungskreis. Also quasi so die strukturelle, organisatorische Frage zu stellen, an wen sollen wir denn berichten? Wie soll berichtet werden? In welchen Zyklen? Was sind dort die Erwartungen?

Alles Dinge, die ich in der Projektstartphase schon mal so ein bisschen klären kann.

Und dann versuche ich mir natürlich in dieser Phase auch möglichst viele Informationen zum Projekt selbst zu beschaffen. Also was wissen wir da bereits drüber? Was ist die Historie? Gibt es Vorprojekte? Haben wir Erfahrungen mit dem Kunden? Gibt es irgendwelche Spezialitäten, die ich berücksichtigen muss? Gibt es rechtliche Dinge, die da besonders berücksichtigt werden? Gibt es spezielle technische Anforderungen, die da relevant werden? Wenn ich ein Produkt zum Beispiel in eine spezielle Branche liefern möchte, mal so als Beispiel Medizintechnik oder Automobilindustrie, die da alle spezielle Anforderungen haben.

Da geht es im Prinzip auch sehr stark darum, die Ausgangslage zu klären. Werden wir in Zukunft auch noch mal eine Podcast-Episode dazu machen.

Und last but not least, glaube ich, in der Projektstartphase ist es notwendig, auch so ein paar organisatorische Dinge mal gerade zu ziehen. Also wie wollen wir denn zunächst mal miteinander kommunizieren, so im nächsten Schritt? Wie oft wollen wir uns treffen? Wann soll das sein und wo? Wo legen wir unsere Dokumente ab? Haben wir ein gemeinsames Verzeichnis?

Und dann geht es auch um eher so formale Dinge, wie das Projekt in den verfügbaren und vorhandenen Systemen zu eröffnen, anzulegen. Also im SAP bekannt zu machen zum Beispiel oder in einem anderen ERP-System. Eine Kostenträgernummer zu erstellen. Eine Projektnummer anzulegen. Und so weiter und so fort.

Also du kannst dir vorstellen, eher so diese organisatorischen Dinge. All das sind Fragestellungen, Themen und Punkte, die es eben in dieser Projektstartphase zu klären gilt.

Ziele der Projektplanungsphase

Wenn das erledigt ist, kommen wir in die Projektplanungsphase und das Ziel der Projektplanungsphase ist im Extremfall, ein komplett aufgeplantes Projekt zu haben, an dem wir nun arbeiten können. Ich sage bewusst im Extremfall, es gibt immer wieder Situationen, die sind wahrscheinlich eher die Regel, dass ich eben nicht in der Lage bin das Projekt vollständig aufzuplanen. Aber ich sollte es so weit wie möglich tun. Also alles Wissen, das ich habe, sollte bitte in meiner Planung auch berücksichtigt sein.

Ein weiteres Ziel der Planungsphase ist, dass die Planung freigegeben wurde. Das heißt, vom Auftraggeber auch so akzeptiert wurde, sodass wir eine Planung haben, die wir als Projektteam als Basis für das Losarbeiten verwenden können. Das ist das Ziel.

Fragen und Themen, die in der Phase besonders wichtig sind, eben schon mal angesprochen, die Zielsetzung. Jetzt müssen wir es rund machen. Jetzt müssen wir sie vollständig machen. Jetzt müssen wir sie vor allem auch widerspruchsfrei machen und wir müssen eine Zieldefinition entwickeln, die auch vom Auftraggeber freigegeben wurde. Sonst kann es durchaus sein, dass wir an einem Ziel arbeiten, an einem Auftrag arbeiten, den wir vielleicht nicht vollständig so verstanden haben, wie unser Auftraggeber das im Kopf hatte und wir dann unsere ganze Planung sozusagen für die Tonne erstellen.

Und ich glaube, jetzt ist auch der Zeitpunkt gekommen, wo wir tatsächlich ein fertiges Lastenheft haben sollten. Und in vielen Fällen wird jetzt auch schon das Pflichtenheft erstellt, weil wir das, was wir für die nächsten Schritte benötigen, ganz oft eben aus dem Pflichtenheft ableiten müssen.

In der Planungsphase ist, glaube ich, so einer der ersten Schritte deine Projektstruktur zu erstellen. Darüber habe ich, glaube, hier auch schon in der Episode PMMB001 gesprochen, kannst du gerne mal nachhören. Eine möglichst vollständige Auflistung der Arbeitspakete zu erstellen, sozusagen als Grundlage für alle weiteren Schritte.

Und das Projekt oder die Arbeitspakete auch so weit zu strukturieren, dass sich Teilprojekte, Hauptarbeitspakete ergeben, denen ich nun auch schon Verantwortlichkeiten zuordnen kann.

Und daraus leitet sich dann direkt auch im Prinzip schon das Projektteam ab. Das heißt, ein weiterer Punkt: eine Projektteamliste, eine Projektliste mit Kernthemen, mit erweiterten Projektthemen, einfach um die Frage zu beantworten, wen brauchen wir denn für das Projekt, um das Projekt abzuwickeln?

Daran schließt dann direkt der nächste Schritt an: Eine Terminplanung. Dazu habe ich auch schon im Podcast besprochen in der Episode PMMB002, wie lange brauchen wir denn für die einzelnen Arbeitspakete? Wie hängen die Schritte und die Tätigkeiten zusammen? Um das noch mal zu wiederholen, der Terminplan sollte die Vorgehensweise klar darstellen und eine klare Aussage darüber liefern, wann denn im Verlauf des Projektes was fertig ist.

Nächster Schritt in der Planungsphase ist dann mit Sicherheit eine Ressourcenplanung. Auch wieder abgeleitet aus den Arbeitspaketen, der Terminplanung. Kann man nun ableiten, wie viel Stunden an Kapazität wir denn von einzelnen Personen oder auch Fachbereichen benötigen.

Und ich glaube auch, wenn wirklich gutes Ressourcenmanagement im Unternehmen aus meiner Sicht fast die Königsdisziplin im Projektmanagement ist und in vielen Unternehmen gar nicht beziehungsweise nur ganz rudimentär vorhanden ist, sollten wir trotzdem von unserem Auftraggeber und oder von unserem Lenkungskreis eine möglichst harte Zusage bekommen, dass wir die benötigten Ressourcen, also Personal, Prüfstands-Kapazitäten, Musterbaukapazitäten und so weiter, für unser Projekt auch wirklich, so wie wir es denn vorhaben, zur Verfügung stehen, weil sonst die Planung ganz oft das Papier nicht wert ist, auf dem sie steht.

Habe ich einen Terminplan, habe ich einen Ressourcenplan, kann ich nahezu direkt die Projektkosten und das Projektbudget ableiten. Um die Frage zu beantworten: Was kostet denn das Projekt?

Wann müssen wir denn wie viel ausgeben? In vielen Fällen ist es jetzt auch schon der Zeitpunkt gegeben, eine Vorkalkulation für mein Produkt zu starten, meistens eben noch auf Basis des Pflichtenhefts, so eine allererste Vorkalkulation.

Ich weiß wohl, dass diese Zahlen noch sehr, sehr ungenau sind und sich im Laufe des Projektes mit Sicherheit noch ein paar Mal ändern. Dennoch macht es Sinn, auch schon zu diesem frühen Zeitpunkt mal zu schauen, wie teuer unser Produkt denn wohl werden wird, um hier auch so ein erstes Gefühl zu kriegen.

Spätestens hier in der Planungsphase sollten wir auch mit der Risikoanalyse beginnen. Also ganz bewusst, ganz, ganz früh im Projekt, weil wir zu dem Zeitpunkt noch die Möglichkeit haben, einzugreifen. Darüber habe ich ja auch hier im Podcast schon in der Episode PMMB004 gesprochen. Wenn wir Risiken erst später erkennen, wenn sie uns später erst klarwerden, haben wir sehr oft kaum eine Möglichkeit, gegenzusteuern. Deswegen startet bitte mit der Risikoanalyse schon in der Planungsphase.

Und um das ganze Paket noch so ein Stück weit rund zu machen, glaube ich, macht es Sinn, sich auch noch mal über Projektkommunikation Gedanken zu machen. Und mein Instrument dafür ist eine Kommunikationsstruktur. Auch da wird es noch mal eine Podcast-Episode dazu geben. Also in der Kommunikationsstruktur sollte dargestellt sein und eine klare Absprache getroffen werden, wer, wann, mit wem, wie oft, zu welchem Thema spricht.

Also Festlegung der Regeltermine und der Berichtswege und auch Regeln der Kommunikation. Wie wollen wir zusammenarbeiten? Wie gehen wir damit um, wenn Teile des Teams im Regelmeeting nicht dabei sind.Diese ganzen Dinge eben in einer frühen Phase auch schon festzulegen.

Abschließend darf diese Planung, dieses ganze Planungsbündel aus Arbeitspaketen, Terminen, Ressourcen, Kosten, Risiken, Kommunikation und so weiter, gerne vom Auftraggeber freigegeben werden, bevor es dann tatsächlich in die Umsetzung geht. Und ich gehe so weit, dass ich mir, wenn es denn geht, diese Planung per Unterschrift freigeben lasse.

Das ist aus meiner Sicht sozusagen die höchste Form des Commitments, dass man sich an der Stelle einholen kann. Und es sorgt natürlich auch dafür, dass mein Auftraggeber sich tatsächlich mit dem Projekt auseinandersetzt, weil am Ende setzt er seine Unterschrift darunter.

Ziele der Projektumsetzungsphase

Jetzt haben wir ein freigegebenes Projekt und kommen in die Umsetzungsphase.

Und hier ist das Ziel ganz klar: Das Projekt mit möglichst wenig Abweichung von der Zielsetzung umzusetzen.

Klar ist auch, es wird wohl kaum ein Projekt geben, bei dem es keine Abweichung gibt. Ich kenne zumindest keins. Projekte haben nämlich immer Risiken. Die sind sozusagen eingebaut. Und so sicher wie das Amen in der Kirche eines der Risiken wird mit Sicherheit eintreten.

Also was sind denn nun die Themenschwerpunkte in dieser Phase? Ganz plakativ gesagt, zunächst einmal Projektsteuerung, also Verfolgung von Terminen, Kosten, Aufwänden und Arbeitspaketen, also der inhaltlichen Arbeit und zu gucken, was passiert da und gegebenenfalls Maßnahmen abzuleiten, falls die Dinge eben nicht so funktionieren, nicht so eintreffen, wie wir uns das mal vorgenommen haben.

Und gleich an der Stelle noch mal: Änderung ist der Normalzusand!

Also gehe bitte nicht davon aus, dass deine erste Planung tatsächlich genauso eintreten wird. Wenn das der Fall wäre, würde ich dir raten, Lotto zu spielen, weil diese Chance ist sehr, sehr gering.

Ein weiterer Punkt, der hier deutlich mit dazu gehört, ist die permanente Risikoüberwachung. In der Planungsphase haben wir es schon begonnen, das wird nun fortgesetzt. Risiken werden verfolgt. Wir werden neue Risiken identifizieren. Andere werden sich in Luft auflösen. Und Maßnahmen werden eben eingeleitet.

Das, was wir in der Kommunikationsstruktur festgelegt haben, muss jetzt umgesetzt werden. Das heißt, ein weiteres Thema, ein weiterer Schwerpunkt, in der Phase ist eben, für Projektkommunikation zu sorgen. Also dafür zu sorgen, dass die Regeltermine stattfinden, dass über das Projekt berichtet wird zum Beispiel an den Lenkungskreis oder den Auftraggeber und auch, dass erforderliche Entscheidungen getroffen werden.

In der Projektumsetzungsphase startet zudem auch noch das Änderungsmanagement. Und zwar genau ab dem Moment, ab dem ich ein freigegebenes Projekt habe. Jede Änderung am Auftrag, also technische oder organisatorische oder wirtschaftliche Änderungen haben nämlich meistens, Ausnahmen bestätigen die Regel, eine Rückwirkung auf unser Projekt. Und das darf ganz gerne im Änderungsmanagement berücksichtigt werden. Auch da mache ich mal noch eine Episode zum Änderungsmanagement. Also in der Umsetzungsphase alles Dinge, die du kennst, Themen, die wir ganz klassisch aus dem Projektmanagement zuordnen, die in den aller, aller meisten Projekten tatsächlich auch so gemacht werden.

Ziele der Projektabschlussphase

Wenn ein Projekt zu Ende ist, kommst du in die Projektabschlussphase.

Das Ziel ist hier ganz klar: Das Projekt sauber beenden, vollständig abschließen und auch das Team gut auseinandergehen zu lassen.

Dazu gehören natürlich so ein paar organisatorische Dinge. Also beende die Regeltermine in deinem, meistens Outlook, also in deinem Kalender. Schließe die Projektnummern ab. Sorge dafür, dass keiner mehr auf dein Projekt buchen kann, dass keine Kosten mehr entstehen.

Und aktualisiere deine Planung rückwirkend ein letztes Mal und schließe sie ab. Also speichere ein letztes Mal ab. Ich habe gute Erfahrungen damit gemacht, auch einen Projektabschlussbericht zu erstellen. Also ein letztes Mal über das Projekt zu berichten.

Und da gehört sehr oft dazu auch so eine Art Lessons-Learned-Sicht zu erzeugen. Also was hat gut funktioniert? Was hat nicht so gut funktioniert? Und wie wollen wir im nächsten Projekt damit umgehen? Gehört alles, aus meiner Sicht, noch in den Projektabschlussbericht.

Sorge dafür, dass das Projektteam entlastet wird. Nicht entlassen, entlastet. Und zwar vom Auftraggeber oder vom Lenkungskreis. Ein formaler Abschluss des Projektes von denen, die es auch angestoßen haben. Das sorgt dafür, dass dein Team auch gut auseinandergehen kann.

Und wenn das Projekt beendet ist, darfst du, glaube ich, auch gerne mal mit deinem Projektteam feiern. Ein Glas Sekt oder eine kleine Wurst auf dem Grill sollten eigentlich immer drin sein.

Du siehst, eher formale Punkte, die auch in den meisten Projekten tatsächlich so erledigt werden. Die anderen Punkte, wie zum Beispiel der Projektabschlussbericht oder dafür zu sorgen, dass das Team gut auseinandergehen kann, beobachte ich leider in den Projekten viel zu selten.

Das hängt natürlich auch stark damit zusammen, dass die Unternehmen und die Fachbereiche extrem gestresst sind, die Mitarbeiter meistens schon wieder im nächsten Projekt versunken sind und eben da vermeintlich keine Zeit mehr dafür bleibt.

Was heisst das für Dich?

Okay, was heißt das denn jetzt für dich? Du siehst, es steckt eine Menge Inhalt in den einzelnen Phasen, den es, glaube ich, zu berücksichtigen gibt. Und wenn du nun einzelne Phasen gar nicht oder vielleicht auch nur sehr oberflächlich durchläufst und bearbeitest, wirst du wahrscheinlich eine Rückwirkung und eine Konsequenz auf dein Projekt haben.

Ganz wichtig: Ich sage nicht, du musst alle diese Themen und Punkte in den einzelnen Phasen unbedingt erledigen.

Es ist mir nur wichtig, dass du die Phasen und die Punkte kennst. Und dass du dann ganz bewusst entscheidest, wo du deine Schwerpunkte setzt. Was dir wichtig ist und was du vielleicht eher weglässt. Und ganz wichtig: welche Konsequenzen sich daraus ergeben. Als Projektleiter darfst du gerne deine Projekte aktiv gestalten und da gehört auch dazu, zu wissen, was einem im Projekt wichtig ist und was eher nicht. Also entscheide dich an dieser Stelle ganz bewusst.

Meine Fragen zum Nach- und Weiterdenken

Und um dir da vielleicht ein bisschen weiterzuhelfen, auch dieses Mal meine Fragen an dich zum Weiterdenken, mit denen ich mich für heute verabschieden möchte.

  • Welche der Phasen, die wir heute besprochen haben, hast du denn bisher gekannt und welche waren dir eher nicht so klar?
  • Und welche Schwerpunkte hast du denn in deinen Projekten?
  • Welche Phasen und welche Inhalte darin waren dir denn bisher besonders wichtig?
  • Für dein nächstes Projekt, wirst du die Schwerpunkte verändern?

Ich bin an der Stelle sehr gespannt auf deine Überlegungen.

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