• Link zu Facebook
  • Link zu Xing
  • Link zu LinkedIn
  • Link zu X
  • Link zu Youtube
Projektmanagement im Maschinenbau
  • Leistungen
    • Verbesserung Projektmanagement
    • Interims-Projektleitung
    • Projektmanagement-Seminar
    • Projektmentoring
  • Wissen
    • Grundlagen
      • Projekt
      • Projektmanagement
      • Projektmanager
      • Projektphasen
    • Projektvorbereitungsphase
      • Stakeholder
    • Projektplanungsphase
    • Projektumsetzungsphase
    • Projektabschlussphase
  • Podcast
  • Online-Bibliothek
  • Über mich
  • Click to open the search input field Click to open the search input field Suche
  • Menü Menü

PMMB053: So erstellst Du eine Meilensteintrendanalyse und behältst den Überblick

2 Kommentare/in Podcast, Projektdurchführung/von Jörg Walter

Auch diese Episode dreht sich wieder um den Themenkomplex Projektreporting. Dieses Mal beschäftige ich mich mit der Meilensteintrendanalyse (MTA). Eine Meilensteintrendanalyse zu erstellen ist nicht schwer, wenn man mal verstanden hat, wie sie funktioniert. Und sie liefert einen großen Nutzen, gerade im Projektstatusbericht.

In dieser Episode erfährst Du

  • Was ein Meilenstein ist
  • Was eine Meilensteintrendanalyse ist
  • Welchen Nutzen eine Meilensteintrendanalyse hat
  • Wie Du eine Meilensteintrendanalyse für Dein Projekt erstellen kannst

Beispiel für eine Meilensteintrendanalyse

Im Beispiel gehe ich davon aus, dass wir ein Projekt mit 4 Meilensteinen (M1 bis M4) haben und ein Mal pro Monat berichten.

Erster Berichtszeitpunkt

Wir dürfen am 01.07.2017 zum ersten Mal berichten und ermitteln aus unserem Terminplan die folgenden Meilensteintermine.

M1: 12.10.2017
M2: 13.02.2018
M3: 02.05.2018
M4: 10.06.2018

Damit ergibt sich dann das folgende Diagramm:

Meilensteintrendanalyse - erster Berichtszeitpunkt

Meilensteintrendanalyse | 1. Berichtszeitpunkt

Zweiter Berichtszeitpunkt

Am 01.08.2017 dürfen wir zum zweiten Mal berichten. Im Projekt verläuft alles nach Plan und die Meilensteintermine bleiben bestehen.

M1: 12.10.2017
M2: 13.02.2018
M3: 02.05.2018
M4: 10.06.2018

Damit ergibt sich das folgende Diagramm:

Meilensteintrendanalyse - Zweiter Berichtszeitpunkt

Meilensteintrendanalyse | 2. Berichtszeitpunkt

Dritter Berichtszeitpunkt

Am 01.09.2017 findet der dritte Bericht statt. Leider sind wir nicht wie geplant vorangekommen, so dass sich bei den Meilensteinen die folgende Situation ergibt:

M1: verzögert sich auf den 15.12.2017
M2: verzögert sich auf den 20.03.2018
M3: bleibt am 02.05.2018
M4: kann schon früher erledigt werden, nämlich am 15.05.2018

Damit ergibt sich das folgende Diagramm:

Meilensteintrendanalyse - Dritter Berichtszeitpunkt

Meilensteintrendanalyse | 3. Berichtszeitpunkt

Vierter Berichtszeitpunkt

Am 01.10.2017 dürfen wir erneut berichten und wieder hat es im Projekt Veränderungen gegeben, die wie folgt aussehen:

M1: kann nun doch schon am  20.11.2017 erledigt werden
M2: bleibt am 20.03.2018
M3: verzögert sich auf den 30.05.2018
M4: verzögert sich ebenfalls auf den 10.06.2018

Damit ergibt sich das folgende Diagramm:

Meilensteintrendanalyse - Vierter Berichtszeitpunkt

Meilensteintrendanalyse | 4. Berichtszeitpunkt

So erstellst Du eine Meilensteintrendanalyse und behältst den Überblick

Dieser Beitrag beschäftigt sich noch mal mit dem ganzen Themenkomplex Projektreporting. Beim letzten Mal habe ich dir ja meine Gedanken zum RYG-Status mitgegeben und dieses Mal soll es um etwas gehen, was ganze viele schon kennen oder zumindest einmal gehört haben, aber leider nicht so oft in ihren Projekten verwenden.

Die Meilensteintrendanalyse wird leider nicht sehr oft verwendet

Ich kann, ehrlich gesagt, nur vermuten, warum das so ist, denn eigentlich handelt es sich um ein sehr einfaches Instrument, zumindest dann, wenn man es einmal verstanden hat. Und zum anderen ist es irre nützlich. Es geht um die Meilensteintrendanalyse.

Und du wirst in diesem Beitrag erfahren, noch mal was ein Meilenstein ist und warum wir den brauchen? Was eine Meilensteintrendanalyse denn so genau ist? Welchen Nutzen sie hat? Und wie du für deine Projekte eine Meilensteintrendanalyse aufbauen kannst. Ich werde dir da eine Schritt-für-Schritt-Anleitung an die Hand geben.

Was ist denn ein Meilenstein noch mal

Schauen wir uns doch noch mal an, was ein Meilenstein ist, bevor wir jetzt noch mal einsteigen in die Meilensteintrendanalyse. Ich glaube, es macht Sinn hier noch mal kurz über Meilensteine zu sprechen. Einfach damit auch klar ist, worüber wir überhaupt reden und womit wir es zu tun haben. Den Begriff Meilenstein, den kennst du mit Sicherheit und ich habe ihn auch schön öfter hier im Podcast verwendet.

Deshalb an dieser Stelle noch mal ganz kurz zusammengefasst:

Ein Meilenstein ist ein ganz besonders wichtiger Punkt im Projekt und in der Regel muss zu diesem Punkt ein bestimmtes, hoffentlich messbares, Ergebnis vorliegen.

Und der Meilenstein stellt damit so eine Art großen, wichtigen Checkpunkt im Projekt dar, an dem auch der Projektfortschritt überprüft werden kann und damit wird ein Meilenstein natürlich zu einem Schlüssel, um besser zu verstehen, ob ein Projekt, wie geplant, voranschreitet oder eben nicht.

Wie entstehen Meilensteine im Projekt?

Wie kommst du nun zu den Meilensteinen in deinem Projekt? Zum einen kannst du die Meilensteine direkt aus deinem Entwicklungsprozess oder beziehungsweise auch Produkt-Entstehungsprozess ableiten. Der Entwicklungsprozess beinhaltet ja mehrere Phasen und jede Phase wird durch ein Gate, so nennt man das da, oder eben auch durch einen Meilenstein getrennt. Und hinzu kommen dann manchmal noch weitere Meilensteine, die sich aus dem speziellen Verlauf deines Projektes herausgeben.

Es können dann zum Beispiel bestimmte Liefertermine von Mustern an Kunden sein oder ähnliche Dinge. In der Regel hast du dann irgendetwas zwischen fünf und acht Meilensteine für so ein Projekt. Ich würde vermeiden mehr als zehn Meilensteine für ein Projekt zu haben, weil dann einfach so ein Stück weit die Übersichtlichkeit leidet. Und das ist auch gleich einer der wesentlichen Nutzen der Meilensteine und auch der Meilensteintrendanalyse. Aber dazu vielleicht gleich noch mal ein bisschen mehr.

Was ist eine Meilensteintrendanalyse?

So, da wir jetzt nun besser verstanden haben, was ein Meilenstein ist und wie wir diese Meilensteine für unser Projekt bekommen können, wie wir da herankommen, möchte ich dir jetzt gern erklären, was eine Meilensteintrendanalyse ist. Den Begriff hast du bestimmt auch schon gehört und wahrscheinlich hast du auch schon mal eine gesehen. Also was ist denn nun eine Meilenstein-Trendanalyse oder kurz MTA?

Die MTA ist eine grafische Darstellung deiner Meilensteine im Projekt in einem Diagramm. Und zwar nicht nur deine Meilensteintermine zu einem bestimmten Zeitpunkt, sondern, und das ist das Besondere der Meilenstein-Trendanalyse, du kannst darin sehen, wie sich deine Meilensteintermine im Verlaufe deines Projektes verändern.

Diagramm mit zwei Achsen

Eine Meilensteintrendanalyse, die besteht eben aus einem Diagramm mit zwei Achsen.

Auf der Y-Achse, also der vertikalen, senkrechten Achse werden die Meilenstein-Termine eingetragen. Die Achse geht von unten nach oben. Unten stehen also die frühen Termine, oben die späteren. Das Ganze ist also ein Zeitstrahl von unten nach oben. Man nennt diese Achse übrigens Meilenstein-Termin-Achse.

Und dann gibt es noch die X-Achse, also die waagerechte, horizontale Achse und dort findest du die Berichtszeitpunkte. Auch diese Achse ist ein Zeitstrahl, der geht allerdings von links nach rechts. Links findest du eben die früheren Berichtstermine und weiter rechts die späteren. Und diese Achse nennt man Berichts-Achse.

Meilensteine sind Linien im Diagramm

Jeder Meilenstein ist nun eine Linie in diesem Diagramm. Hast du also zum Beispiel fünf Meilensteine, die dargestellt werden, hast du fünf Linien, fünf Trends in deiner Meilensteintrendanalyse. Ich habe dir in den Shownotes ein Bild und auch ein Beispiel eingefügt, auf dem du eine Meilenstein-Trendanalyse sehen kannst. Da werden dann auch gleich die Meilenstein-Terminachse und die Berichts-Achse klarer für dich. Schau hier einfach einmal hinein. Wie du zu diesen Linien kommst und wie man so einen Kurvenverlauf interpretiert, das erkläre ich dir jetzt gleich.

Also die Meilenstein-Trendanalyse ist also ein Instrument, das sehr gerne dann auch im Projekt-Statusbericht verwendet wird, weil ich damit eben eine gute und auch eine schnelle Aussage zur Terminsituation meiner Projekte bekomme. Jetzt denkst du vielleicht, das ist aber mächtig kompliziert, warum würde ich denn meine Meilensteine so darstellen wollen?

Eine Meilensteintrendanalyse hat einen ganz besonders hohen Nutzen

Es gibt einen ganz einfachen Grund, warum die Meilenstein-Trendanalyse so beliebt ist. Sie hat einen extrem hohen Nutzen. Und, by the way, so kompliziert ist es gar nicht, wie es sich jetzt vielleicht auf den ersten Blick anhört.

Okay, was ist denn nun also dieser Nutzen einer MTA? Ich habe es eben schon erwähnt, die Meilenstein-Trendanalyse ist sehr oft ein Element des Projektstatusberichtes. Sie hat den Vorteil, dass ich, als Betrachter dieses Berichtes, zum einen sofort einen Überblick über alle Meilensteine bekomme. Also welche Meilensteine sind geplant und wie sind die denn aktuell terminiert? Und zum anderen bekomme ich durch den Kurvenverlauf, jeder Meilenstein hat eine Kurve, eine Information, wie sich die Meilenstein-Termine im Laufe des Projektes entwickelt haben. Sind sie nach vorne gerutscht, also früher als ursprünglich geplant? Oder erwarten wir eine Verzögerung? Das heißt, die Meilenstein-Termine sind nach hinten gerutscht.

Sofort sichtbar: wie haben sich die Meilensteintermine entwickelt

Das kann ich dann grafisch aufbereitet in der Meilenstein-Trendanalyse sehen. Und das ist nämlich relativ einfach abzulesen. Das ist ganz einfach:

  • Waagerechte Linien, waagerechte Trends bedeuten, dass der Meilenstein-Termin, wie geplant, eingehalten wird.
  • Fallende Linien bedeuten ein früheres Erreichen des Meilenstein-Termins, also früher als vorher geplant.
  • Steigende Linien bedeuten demnach eben ein verzögertes, geplantes Erreichen des Meilenstein-Termins.

Und dann kommt noch hinzu, dass der Aufwand für einen Projektleiter, aus meiner Sicht, sehr gering ist diese Information auch zur Verfügung zu stellen. Ich erkläre dir gleich noch mal detaillierter in der Schritt-für-Schritt-Anleitung, wie das geht.

Also der Nutzen noch mal zusammengefasst: Ganz einfach, Transparenz und Übersicht. Einfache Analyse des Projektzustandes, was Termine angeht und auch aus meiner Sicht eine einfache Bedienung und Erfassung der Daten.

Wie erstellt man eine Meilensteintrendanalyse

Okay. Wie kannst du nun vorgehen, um eine Meilenstein-Trendanalyse für dein Projekt zu erstellen? Wie schon angekündigt, habe ich dir so eine kleine Schritt-für-Schritt-Anleitung mit fünf Schritten zusammengestellt.

Erstelle das MTA-Diagramm

Der erste Schritt ist, erstelle dir ein Meilensteintrendanalyse-Diagramm. Also du brauchst ein Diagramm, in das du dann in den weiteren Schritten deine Meilenstein-Termine eintragen kannst. Hierzu darfst du dir einfach ein Diagramm aufbauen, wie ich es eben beschrieben habe. Schau einfach auch mal in den Shownotes nach, dann verstehst du schon, wie es gemeint ist. Und du kannst das Diagramm zum einen auf ein Flipchart malen, das ist der einfachste Weg, oder es auch in Excel oder zum Beispiel Power Point aufbauen.

Definiere Deine Meilensteine

Der zweite Schritt ist, definiere deine Meilensteine für dein Projekt. Du brauchst jetzt natürlich Meilenstein, die du im Rahmen der Meilenstein-Trendanalyse zum einen darstellen und zum anderen aber auch verfolgen möchtest. Wie eben schon beschrieben, sind das in der Regel die Gates aus deinem Produktentstehungsprozess oder eben halt die Meilensteine, die diese einzelnen Phasen trennen. Und manchmal kommen noch weitere für dich wichtige, für dein Projekt wichtige, kritische Projekte hinzu.

Noch mal die Empfehlung, bitte versuche weniger als zehn Meilensteine in der Meilenstein-Trendanalyse abzubilden. Es wird sonst tatsächlich so ein bisschen unübersichtlich.

Definiere Deine Berichtszeitpunkte

Der dritte Schritt ist, definiere deine Berichtszeitpunkte. Du darfst nun festlegen, wie oft du berichten möchtest, also in welchen zeitlichen Intervallen du deine Meilensteintermine in der MTA aktualisieren möchtest. Üblicherweise geschieht es immer zum Lenkungskreis eines Projektes, weil da möchte ich ja berichten und da sollten meine Daten natürlich einigermaßen aktuell sein. Meistens findet der eben einmal pro Monat statt und falls nicht, dann hat es sich dennoch bewährt einmal pro Monat die Meilenstein-Termine und damit auch die Meilenstein-Trendanalyse zu aktualisieren. So bekommst du einmal im Monat ein neues Ergebnis.

Meilensteintermine eintragen

Und jetzt kommen wir auch schon zum vierten Schritt. Trage jetzt zu jedem Berichtszeitpunkt, also einmal im Monat, deine Meilenstein-Termine ein. Das geht nun einfach so, dass du beim ersten Berichtszeitpunkt, also in der Regel zum ersten Lenkungskreis, das ist ganz links auf deiner Berichtsachse, die geplanten Termine deiner Meilensteine auf der Meilenstein-Terminachse, das ist die senkrechte Achse, aufträgst. Und da der Zeitstrahl ja von unten nach oben geht, ist der früheste, also der nächste Meilenstein ganz unten, der danach folgende darüber und so weiter und so fort. Und beim ersten Bericht hast du nichts anderes, als ein paar Punkte, die übereinander stehen eben ganz links auf der Achse.

Am nächsten Berichtszeitpunkt, also zum nächsten Lenkungskreis, gehst du eben genauso vor. Du gehst allerdings auf der X-Achse, also auf der Berichtsachse eine Einheit, einen Monat vielleicht nach rechts. Die bereits eingetragenen Termine aus dem letzten Berichtszeitpunkt, die bleiben natürlich bestehen. Die überschreibst du nicht, da radierst du auch nichts aus, die lässt du einfach, wo sie sind. Und jetzt kommen neue Punkte hinzu, die du eben quasi beim Auftragen deiner jetzt geplanten Meilensteintermine bekommst. Und jetzt kannst du die einzelnen, zusammengehörenden Punkte zu einer Linie verbinden, sodass sich ein Graph ergibt.

Und dieses Vorgehen wiederholst du zu jedem Berichtszeitpunkt. Das heißt, jede Linie pro Meilenstein wächst, wenn man so will, von links nach rechts. Und du erinnerst dich, waagerechte Linien bedeuten, dass der Meilenstein-Termin, wie geplant, eingehalten wird, fallende Linien bedeuten ein früheres Erreichen des Meilenstein-Termins und steigende Linien bedeuten demnach eben auch ein verzögertes Erreichen des Meilenstein-Termins.

Maßnahmen überlegen

Und jetzt sind wir schon beim fünften Schritt angekommen. Du musst dir nämlich Maßnahmen überlegen für das Ergebnis. Im letzten Schritt geht es eben darum zu überlegen, wie du mit diesem Verlauf der Kurven umgehen möchtest. Waagerechte Kurven, also gleich bleibende Meilenstein-Termine und fallende Linien, also Termine, die früher als geplant fertig werden, haben natürlich in der Regel keine besonderen Maßnahmen zur Folge. Verschieben sich allerdings Termine nach hinten, so darfst du dir überlegen, welche Maßnahmen du einleiten kannst. Und hier hilft dir natürlich ein Blick in dein Terminplan, denn hier sind ja alle Aktivitäten für dein Projekt dargestellt und abgebildet. Und natürlich auch alle Meilensteine. Und so kannst du nun schnell erkennen, welche Maßnahmen dazu führen können, die Termine wieder nach vorne zu holen.

Diese fünf Schritte versetzen dich ganz einfach in die Lage einen Überblick über deine Meilensteine und deren zeitliche Veränderung im Verlaufe des Projektes zu bekommen. Ich habe dir, um es dir vielleicht leichter zu machen, in der Online-Bibliothek noch eine Excel-Vorlage für eine Meilenstein-Trendanalyse hinterlegt. Also einfach auf bibliothek.projektmanagement-maschinenbau.de gehen, registrieren, falls noch nicht geschehen, einloggen, Vorlage herunter laden und einfach in deinem Projekt verwenden.

So das waren nun also die Schritte, die du gehen kannst, um eine Meilenstein-Trendanalyse für dein Projekt zu bekommen. Und wie gehabt, habe ich auch in dieses Beitrages wieder ein paar Fragen für dich zum Nach- und Weiterdenken:

  • Wie berichtest du denn heute deine Termin-Situation im Projekt?
  • Was funktioniert dabei richtig gut und was funktioniert weniger gut?
  • Welches sind denn für dich die Hauptvorteile der Meilenstein-Trendanalyse?

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-08-15 01:00:352018-02-05 22:37:36PMMB053: So erstellst Du eine Meilensteintrendanalyse und behältst den Überblick

PMMB052: Warum RYG nicht gleich RYG ist

0 Kommentare/in Podcast, Projektdurchführung/von Jörg Walter

PMMB052: Warum RYG nicht gleich RYG ist

Podcast für Projektmanagement im Maschinenbau

Diese Episode anhören

Über diese Episode

Themen dieser Episode

  • Was ist der RYG-Status
  • Welches ist die größte Falle ist, die sich viele Unternehmen damit aufstellen
  • Wie kannst Du damit umgehen

Für wen ist diese Episode?

  • Projektleiter, die in ihren Berichten klar kommunizieren wollen
  • Auftraggeber, die den Stand eines Projekts verstehen wollen
  • Führungskräfte, die gutes Projektmanagement wollen

Diese Episode lieber im Blog lesen

Hier geht es zum Blog-Beitrag:

Was Du zum RYG-Status wissen solltest

Newsletter abonnieren


Podcast abonnieren


Zusammenfassung dieser Episode:

Die meisten Projektstatusberichte verwenden einen RYG-Status. Oft führt dieser Status zu langen Diskussionen um die Bewertung von Projekten.

Grundsätzlich gilt die folgende Zuordnung:

  • R steht für red, rot, gleich roter Projektstatus
  • Y steht für yellow, gelb, also gelber Projektstatus
  • G steht für green, grün, oder, ja, alles in Ordnung, grüner Stand

Grundsätzlich sind jedoch zwei mögliche Sichtweisen mit dem RYG-Status verbunden, die immer wieder zu Unklarheit und Diskussionen führen.

  1. Status ist auf das „heute“ bezogen
  2. Status ist auf das Projektende bezogen

Um den RYG-Status sinnvoll nutzen zu können ist eine Entscheidung zur Sichtweise erforderlich, für ich gerne den folgenden Dinge als wichtig erachte:

  1. Erklären
  2. Klarheit herbeiführen (entscheiden)
  3. Gemeinsames Verständnis schaffen
  4. Lebe mit dem Ergebnis

Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf X
  • Teilen auf LinkedIn
  • Per E-Mail teilen


Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_dummy.jpg 300 300 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-08-10 01:00:052018-03-30 07:43:20PMMB052: Warum RYG nicht gleich RYG ist

PMMB051: Was gehört alles in einen Projektstatusbericht?

0 Kommentare/in Podcast, Projektdurchführung/von Jörg Walter

PMMB051: Was gehört alles in einen Projektstatusbericht?

Podcast für Projektmanagement im Maschinenbau

Diese Episode anhören

Über diese Episode

Themen dieser Episode

  • Was verstehe ich konkret unter einem Projektstatusbericht
  • Welche Elemente kann ein Projektstatusbericht enthalten
  • Wie kannst du das einfach umsetzen

Für wen ist diese Episode?

  • Projektleiter, die gut und vollständig über Ihr Projekt berichten wollen
  • Führungskräfte, die endlich im Lenkungskreis gut informiert werden möchten

Diese Episode lieber im Blog lesen

Hier geht es zum Blog-Beitrag:

Projektstatusbericht: Das gehört alles rein!

Newsletter abonnieren


Podcast abonnieren


Zusammenfassung dieser Episode:

Der Projektstatusbericht ist ein wesentlicher Bestandteil des Projektreportings. Er ermöglicht es, den aktuellen Status eines Projektes und dessen Entwicklung in der Vergangenheit schnell zu erfassen und zu bewerten. Gleichzeitig ist ein Vergleich verschiedener Projekte möglich.

In einem Projektstatusbericht sollte enthalten sein:

  1. Stammdaten mit Projektbeschreibung, Zielsetzung.
  2. Terminen
  3. Projektkosten
  4. Ressourcensituation
  5. letzten Schritte und die nächsten Schritte
  6. Highlights und Lowlights
  7. Risiken
  8. Entscheidungsbedarfe

Ohne Tooling wird es schwierig einen Projektstatusbericht effizient umzusetzen. Meine Empfehlung lautet: Starte zunächst mit einem Projektstatusbericht in Excel, mit dem Du erste Erfahrungen sammelst und den Du immer weitere optimieren kannst. Sobald das erfolgt ist, kannst Du den Projektstatusbericht in eine Projektmanagement-Software übertragen.

Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf X
  • Teilen auf LinkedIn
  • Per E-Mail teilen


Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_dummy.jpg 300 300 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-08-08 01:00:332018-02-13 17:06:34PMMB051: Was gehört alles in einen Projektstatusbericht?

PMMB000: Der "coole" Auftraggeber - Beitrag zur Blogparade von Thomas Reining

0 Kommentare/in Allgemein, Podcast, Projektdurchführung/von Jörg Walter

Thomas Reining hat zur Blogparade aufgerufen und ich mache mit dieser Episode mit. Es geht darum herauszufinden, was machen eine „coole“ Führungskraft aus. Ich habe mich dem Thema aus einem anderen Blickwinkel heraus angenommen und möchte Dir zwei Erlebnisse mit Auftraggebern schildern, die unterschiedlicher nicht sein könnten.

In dieser Episode erzähle ich Dir

  • Was eine Blogparade ist und warum ich daran teilnehme
  • Welche Erlebnisse ich mit dem „coolen“ Auftraggeber verbinde und welche eher nicht
  • Was Du als Auftraggeber aus diesen Erlebnissen mitnehmen kannst

Links zu Thomas Reining:

  • Internetseite von Thomas Reining
  • Aufruf zur Blogparade und Liste der Beiträge
  • Podcast „Gute Führung braucht Gespür“ bei itunes

Der „coole“ Auftraggeber – Beitrag zur Blogparade von Thomas Reining

Die heutige Episode geht mal so ein bisschen außer der Reihe. Und das ist auch der Grund, warum diese Episode keine eigene Nummer besitzt. „Was hat der denn jetzt schon wieder vor“, denkst du jetzt vielleicht gerade. Ich erkläre es dir.

Mit dieser Episode nehme ich an einer Blogparade teil und zwar an der Blogparade von Thomas Reining. Thomas hat vor ein, zwei Wochen aufgerufen zu schreiben, zu sprechen oder zu filmen zum Thema die coole Führungskraft. Und da bin ich natürlich dabei.

Und du wirst in dieser Episode, in diesem Beitrag zur Blockparade erfahren zum einen, was eigentlich was eine Blogparade ist und warum ich da gerne mitmache. Und zum anderen, welches Erlebnis oder besser gesagt, welche Erlebnisse ich sofort im Kopf hatte, als ich gehört habe, das Thema sei die coole Führungskraft. Und ganz zum Schluss vielleicht noch so ein paar Ideen, was ich denke, was Führungskräfte und Auftraggeber aus dieser Geschichte vielleicht lernen können.

Was ist denn eine Blogparade?

Okay. Für alle, fangen wir doch mal an, was denn eigentlich so eine Blogparade ist? Für alle, die den Begriff noch nicht gehört haben, ich versuche es mal so ein bisschen zu erklären.

Also was ein Blog ist, solltest du eigentlich wissen. Ein Blog ist ein Weblog also ein Internetlogbuch, wenn man es so sagen möchte, frei übersetzen möchte und in einem Blog findest du Beiträge, Artikel meistens irgendwie thematisch sortiert. Auf projektmangement-maschinenbau.de findest du auch einen Blog. Bei mir steht da drüber Wissen. Hier schreibe ich Dir immer mal wieder etwas schreibe und darfst auch gerne mal hineinschauen und mal gucken, was ich da so veröffentliche.

Eine Blogparade ist nun also eine Aktion im Internet, die gestartet wird und über einen bestimmten Zeitraum läuft. Das wird eben aufgerufen im eigenen Blog beziehungsweise auf der eigenen Internetseite zu einem bestimmten Thema etwas zu schreiben. Alle Artikel, die nun so entstehen, die werden beim Initiator der Blogparade zusammengefasst, aufgelistet und so entsteht eben dann eine Liste aus Artikeln, Beiträgen, Geschichten und Meinungen zu diesem Thema.

Eine praktische Sache, denn so kann ich mich als Leser mit einem Thema auseinandersetzen, das ich spannend finde und ganz viele verschiedene Sichten von unterschiedlichen Personen, manchmal auch gegensätzlich und widersprüchlich bekommen. Und ich kann mir so ein Thema so ein bisschen von unterschiedlichen Seiten anschauen.

Thomas Reining hat nun zu einer Blogparade mit dem Titel die coole Führungskraft aufgerufen. Thomas ist Trainer und Coach für Führungskräfte und Manager und er betreibt den Podcast Gute Führung braucht Gespür, den ich hin und wieder auch mal höre. Nicht alle Episoden, aber durchaus immer mal wieder. Und ich habe dir seine Seite und auch den Link zu dem Podcast in den Shownotes dieser Episode verlinkt. Kannst du gerne mal hineinschauen.

Mitmachen ist angesagt, weil…

Warum mache ich denn nun bei dieser Blogparade mit, obwohl es vielleicht jetzt auch eher so ein Thema ist, das jetzt nicht so ganz nah ist, also Führung und Führungskräfte, wobei es durchaus auch mal Möglichkeiten bei Blogparaden teilzunehmen, die Themen hatten, die jetzt näher an meiner Passion, dem Projektmanagement, liegen?

Der Grund ist ganz einfach. Als ich den Titel gehört habe und Thomas mich kurz angesprochen hatte, ob ich da nicht mitmachen möchte, da hatte ich sofort ein Erlebnis, besser gesagt zwei Erlebnisse im Kopf, die sehr viel Wirkung bei mir hinterlassen hatten und die ich sofort mit diesem Thema die coole Führungskraft assoziieren konnte. Also habe ich mich entschieden mitzumachen und du wirst gleich erfahren, was diese Erlebnisse waren, worum es da geht.

Wie man als Auftraggeber mit seinem Kunden umgehen kann

Ich hoffe, damit ein wenig beleuchten zu können, wie man als Auftraggeber und Kunde mit einem Projektteam umgehen kann und wie man vielleicht auch nicht damit umgehen kann.

Dann starte ich vielleicht einfach mal mit diesen Erlebnissen, die ich da hatte. Diesem Erlebnis, also genau gesagt, sind es zwei Erlebnisse und beide liegen schon einige Jahre zurück und beide auch ungefähr zehn Jahre auseinander. Und beide Erlebnisse sind aus einer sehr ähnlichen Ausgangslage entstanden und haben aber jeweils ein sehr unterschiedliches Ende genommen, was ich sehr spannend fand.

Mein erstes Projekt

Die erste Begebenheit, das erste Ergebnis liegt schon circa 15 Jahre zurück. Ich habe gerade meinen ersten Job als Projektberater angetreten, war ein bisschen grün hinter den Ohren und das Ganze war mehr oder weniger mein erstes Projekt, in dem ich eingesetzt war. Das Projekt lief bei einem großen, deutschen Automobilzulieferer und die Aufgabe war es, ein System zu entwickeln und dann natürlich auch irgendwann herzustellen, dass in so einem Fahrzeug eingebaut werden sollte.

Ich spreche von einem System, da dort mehrere Komponenten waren, die sollten verbunden werden und zwar über ein neuartiges Bussystem. Die sollten auch miteinander kommunizieren, Daten austauschen und sollten eben in diesem System funktionieren. Und hinzu kam dann noch, dass nicht alle Komponenten von unserem Kunden, also von unserem Projekt entwickelt wurden, sondern da gab es noch weitere Partner. Also alles wurde neu sozusagen auf der grünen Wiese entwickelt.

Alles neu entwickelt

Die Hardware der Komponenten wurde neu entwickelt. Ich spreche jetzt von Elektronik, also da wurden Leiterplatten-Schaltungen entwickelt. Die Software musste komplett neu aufgebaut und entwickelt werden und auch das Bussystem war komplett neu und teilweise noch in der Entwicklung.

Insgesamt waren auf unserer Seite in diesem Projekt, ich würde mal 50, 60, vielleicht auch 70 Entwickler beteiligt und der Kunde für dieses System war ein großer, deutscher Automobilbauer, ein Automobilhersteller und der wollte dieses System in seine neuen Fahrzeuge einbauen und dort natürlich zur Anwendung zu bringen.

Es gab natürlich schon einen SOP. Für alle, die sich im Automobilbau nicht so auskennen, SOP steht für Start of Production, ist also der Termin, an dem alles fix und fertig getestet, serienreif verfügbar sein sollte und quasi in diese Autos eingebaut werden sollte.

Du kannst dir natürlich vorstellen, dass das für mich als Projektmanagement-Neuling ein super spannendes Projekt war. Und unsere Aufgabe: Wir waren ein Team von, ich glaube, drei oder vier externen Beratern, war es die Projektleiter, die es gab, zu unterstützen, für Transparenz zu sorgen, Entscheidungen herbei zu führen und so weiter und so fort.

Insgesamt waren das vier oder fünf Projekte, die wir da zu betreuen hatten, die alle zu diesem Projektprogramm dazu gehörten. Wir haben dann natürlich gemeinsam mit dem Kunden so die üblichen Strukturen aufgestellt. Verschiedene Projektstrukturen für die einzelnen Projekte, die zu diesem Projektprogramm gehören, um die Arbeit sichtbar zu machen, Terminpläne erstellt. Wir hatten regelmäßig interne Projektteamsitzungen, regelmäßige Lenkungskreise mit unserem Kunden, dem Automobilbauer und so weiter und so fort.

Irgendwann gab es technische Probleme

Und so kam es, wie es, wie soll ich sagen, rückblickend fast kommen musste, das Projektteam hat die Aufgabe irgendwann technisch nicht in den Griff bekommen. Wir hatten zu viele technische Probleme, die wir nicht beziehungsweise nicht rechtzeitig lösen konnten. Du kennst das bestimmt auch, wenn du Produktentwicklungsprojekte betreibst. Entwicklung ist nicht immer vorhersehbar und manchmal klappt es und manchmal brauchst du zwei oder drei Rekonstruktionen, um ans Ziel zu kommen.

Wir haben dann Muster ausgeliefert, die teilweise nur die Hälfte der geforderten Funktionen hatten. Es gab immer wieder neue technische Probleme im System, hauptsächlich bei der Kommunikation dieser einzelnen Komponenten untereinander über dieses Bussystem.

Und es war eben abzusehen, dass wir das Projektziel nicht erreichen würden, also dass wir nicht die geforderte Funktionalität dem System zum gewünschten Zeitpunkt verfügbar haben werden. Und natürlich auch noch zu der gewünschten Qualität, das heißt in diesem Fall Stabilität des Systems. Ich glaube, wir haben damals schon ganz ordentlichen Job gemacht, weil wir schon relativ früh gesehen haben und erkannt haben, dass es irgendwie aus dem Ruder läuft. Und wir haben das auch kommuniziert, dass wir das Projektziel wohl nicht erreichen werden.

Wie reagiert der Auftraggeber?

So, und jetzt ist die spannende Frage: Wie hat denn unser Auftraggeber, also der Kunde, der Automobilbauer reagiert?

Was denkst du? Vielleicht hast du ja eine Idee, wenn du dich in der Automobilbranche ein wenig auskennst. Also zunächst einmal hat sich der Kunde zurückgezogen. Seine Position war damals ziemlich klar:

Ihr habt das Projekt angeboten. Wir haben bezahlt, schaut gefälligst, dass ihr die Kuh vom Eis kriegt. Ihr sollt alles ans Laufen bringen. Ist euer Problem.

Also die Probleme dann nicht weniger wurden, sondern eher mehr, eher tiefgreifender, dann hat sich seine Haltung noch mal ein wenig geändert. Jetzt forderte er nämlich regelmäßige Berichte, wöchentliche Statusberichte, er wollte die Risikolisten sehen. Risiken haben ihn im Übrigen vorher nicht die Bohne interessiert. Jetzt waren sie auf einmal wichtig.

Reporting wird auf einmal wichtig

Und er hat begonnen, uns alle zwei Wochen zu besuchen und sich einen Tag lang den gesamten Status auch präsentieren zu lassen. Und da die Manager des Kunden natürlich nicht jedes technische Detail nachvollziehen konnten, mussten wir das im Detail dann auch erklären und beschreiben und quasi dem die Informationen zur Verfügung machen.

Was war das Ergebnis? Unsere Entwickler waren immer irgendwann mehr damit beschäftigt zu erklären und zu rechtfertigen, warum sie bestimmte Dinge gemacht haben und warum die dann manchmal eben auch nicht funktioniert haben. Und die echte Arbeitszeit, die für die Entwicklung noch zur Lösung der technischen Probleme zur Verfügung stand, die wurde irgendwie immer weniger. Und die war vorher schon extrem knapp bemessen.

Alle sind zusätzlich beschäftigt

Und auch wir und die Projektleiter, also wir, die dieses Projekt unterstützt und begleitet haben als Coach und auch die Projektleiter, wir waren immer mehr damit beschäftigt, dem Kunden, die Auftraggeber die Details zu erklären, zu berichten, Listen zu aktualisieren und so weiter und so fort, sodass es immer weniger Zeit gab, Risiken zu identifizieren, Wege zu finden, damit umzugehen Maßnahmen zu erarbeiten, auch wirklich zu erarbeiten, fundiert zu erarbeiten und auch zu verfolgen. Oder es fehlt dir einfach auch schlicht die Zeit zu überlegen, wie wir denn mit dieser Situation umgehen wollen.

Das Projekt gerät in eine Abwärtsspirale

Am Ende war das Projekt dann tatsächlich in so eine Art Abwärtsspirale geraten und wir haben dann irgendwann tatsächlich die Reißleine gezogen und gesagt, dass wir das Projektziel nicht mehr erreichen. Es hat dann, kannst du dir vorstellen, ordentlich Wirbel verursacht, weil dieses neue Fahrzeugmodell ohne das neue, innovative System an den Markt gehen musste. Man hat dann halt einfach den alten Kram eingebaut.

Verstehe mich jetzt bitte nicht falsch. Ich sage hier nicht, dass der Auftraggeber Schuld an diesem Projektabbruch war. Ich glaube, ein Teil der Gründe lag, da gab es noch ganz andere Dinge, die dazu beigetragen haben. Aber das Verhalten unseres Auftraggebers hatte, aus meiner Sicht, einen Einfluss darauf. Es war jedenfalls nicht so, dass es das Projekt unterstützt hat.

Es kann auch anders gehen

Wie es anders gehen kann, möchte ich dir mal in einem zweiten Beispiel verdeutlichen. Dieses Projekt liegt ungefähr fünf Jahre zurück und war eines der ersten, das ich übernommen habe, als ich mich selbstständig gemacht habe.

Der Auftrag war es, ein Antriebssystem für die Öl- und Gasindustrie zu entwickeln. Dieser Antrieb wurde bei der Gasförderung eingesetzt und da die Art des Einsatzes bisschen neu war und auch unbekannt, es war eine echte Innovation, handelt es sich eben auch hier um ein völlig neu entwickeltes System. Der Kunde kam übrigens aus Norwegen.

So ähnlich, wie beim ersten Projekt, musste auch hier Hardware und Software neu entwickelt werden und alle mechanischen Teile sowieso, da es eine kundenspezifische Lösung war. Alles in allem weniger groß, weniger komplex, würde ich sagen, wir reden jetzt insgesamt vielleicht über fünf bis sechs Entwickler und nicht, wie vorher über 50, 60, aber technisch ebenso schwierig, ungewiss und riskant. Würde ich tatsächlich ebenso einschätzen.

Ähnliche Randbedingungen

Und auch hier hatten wir einen fixen Liefertermin, also ein Fertigstellungsdatum, in dem alles fix und fertig verfügbar sein musste. Und im Öl- und Gasgeschäft, da wird, das muss man wissen, richtig, mit richtig viel Geld hantiert. Und du kannst dir vorstellen, wie viel es eine Ölgesellschaft kostet, wenn so eine Ölbohrplattform einen Tag still steht. Das heißt, auf diesem Projekt da war ordentlich Fokus und es war auch mit einer schönen Pönale hinterlegt.

Und hier kam tatsächlich noch dazu, dass wir nur ein ganz bestimmtes Zeitfenster hatten, um fertig zu werden. Für den Fall des Nichttreffens dieses Zeitfensters, war dann eben erst möglich ein Jahr später wieder diese Antriebe zur Anwendung zu bringen. Das lag daran, dass der Einsatzort auf dem Meer war und man da nicht einfach so hinfahren kann, wie wir uns das vorstellen, sondern aufgrund von Wetter und Seebedingungen nur einmal im Jahr eben möglich war solche Arbeiten vorzunehmen.

Ich hatte in diesem Projekt die Rolle des Projektleiters und damit einhergehend natürlich auch die entsprechende Verantwortung. Wie ich vorgegangen bin, kannst du dir denken, wenn du den Podcast hier regelmäßig hörst: Ausgangslage klären, Ziele finden, Projektstruktur erstellen, Terminplan ableiten und so weiter und so fort. Alles für dich keine große Überraschung. Und natürlich haben wir auch die entsprechenden Kommunikationswege aufgebaut, sodass unser Kunde immer im Bild war, wo wir gerade stehen, was wir tun, welche Arbeitspakete sich verzögern, welche schneller werden und so weiter und so fort.

Technische Probleme wo man hinschaut

In diesem Projekt ist dann etwas sehr, sehr ähnliches passiert, wie beim Projekt, dass ich dir eben schon beschrieben habe. Wir haben technische Probleme bekommen und wir haben sie nicht wirklich in den Griff gekriegt. Konkret war es die thermische Situation auf den Platinen, die wir nicht in den Griff bekommen haben und wir haben eben nicht alle Funktionen stabil hinbekommen. Es hat nicht funktioniert.

Und auch in diesem Projekt waren wir dann irgendwann in der Situation, dass wir dem Kunden erklären müssen, dass wir den Liefertermin nicht halten werden. Sprich, wir haben dem Auftraggeber gesagt, dass wir zum gewünschten Termin nicht liefern können werden.

Und wie hat dieser Auftraggeber reagiert?

Wie hat nun dieser Auftraggeber reagiert? Und ich muss gestehen, ich war so ein bisschen gespannt darauf, weil ich natürlich noch die Reaktion der Kunden oder des Auftraggebers aus dem Automobilbereich in Erinnerung hatte. Das Projekt, das ich dir eben schon so ein bisschen erläutert habe. Und die erste Frage, die er uns dann gestellt hat, die gab schon einigen Aufschluss, wie es denn da weitergeht.

Der erste Frage war nämlich, was braucht ihr, um voranzukommen?

Und dann hat er gefragt, und was ist denn genau das Problem?

Und die nächste Frage war noch besser. Wie können wir euch bei der Lösungsfindung unterstützen?

Und dann wollte er natürlich wissen, was könnt ihr denn wann liefern, in welchem Zustand?

Und du erkennst nun schon, das ist ein ganz anderer Ansatz, der da dahinter steckt. Eine ganz andere Haltung, die zu sehen ist. Wenige Tage später hatten wir Experten unseres Auftraggebers bei uns am Tisch im Projekt sitzen, die uns bei der Fehlersuche und Lösungsfindung unterstützt hatten, weil das war nämlich eine Antwort auf die Frage, wie können wir euch bei der Lösungsfindung unterstützen? Wir waren an technische Probleme geraten, wo es manchmal eben keine Lösung direkt aus der Tasche gibt, sondern, wo man nachdenken muss, wo man Experten braucht, die sich zusammensetzen und gemeinsam nachdenken, um an eine Lösung zu kommen.

Und unser Auftraggeber hat uns seine Experten zur Verfügung gestellt. Natürlich haben wir regelmäßig über den Projektfortschritt berichtet. Natürlich waren alle total nervös, weil einige Zeit unklar war, wie es denn überhaupt weitergeht, ob wir überhaupt eine technische Lösung hinbekommen. Und natürlich mussten wir auf Managementebene Statusberichte abgeben. Logisch. Das sind alles Dinge, die völlig legitim sind. Aber dennoch hatte dieser, ich sage mal, coole Auftraggeber ein ganz anderes Verständnis seiner Rolle und er hat sie auch ganz anders wahrgenommen.

Wie ist das Projekt ausgegangen?

Vielleicht zum Abschluss. Wie ist denn das Projekt ausgegangen? Wir haben es tatsächlich geschafft eine Lösung für die aufgetauchten thermischen Probleme zu finden. Der Antrieb war dann mit einigen Monaten Verzögerung, ich glaube, es waren so sechs oder sieben, tatsächlich fertig geworden und konnte auch ausführlich getestet werden. Und, das war jetzt etwas, was sich sehr stark aus dieser engen Zusammenarbeit mit dem Auftraggeber ergeben hat, inzwischen hatten wir eben mit dem Auftraggeber einen Weg gefunden, wie wir einige Tests und Untersuchungen schon vorab durchführen konnten.

Das war nämlich die Antwort auf die Frage, was könnt ihr bis wann liefern, sodass wir zwar Zeit verloren haben, die wir aber an anderer Stelle durch Tests, die wir vorziehen konnten, wieder einsparen konnten. Du siehst, bei der nahezu gleichen Ausgangssituation gab es zwei völlig unterschiedliche Ergebnisse, die herausgekommen sind und die sich, aus meiner Sicht, zu einem großen Maß aus dem Verhalten des Auftraggebers ableiten lassen.

Unterschiedliches Verhalten der Auftraggeber

Ich versuche es noch mal zusammenzufassen und ein wenig zu vergleichen. Da ist auf der einen Seite, das ist das erste Projekt, ein Auftraggeber, der sich nicht wirklich im Boot des Projektes sieht, der etwas beauftragt hat, ein Projekt initiiert hat, dann aber nicht mehr sehr viel mit der Lösungsfindung bei echten auftauchenden Problemen zu tun haben will. Der sich da auch nicht in der Verantwortung sieht, sondern eher die Rolle eines Kontrolleurs und wenn ich böse sein will, sagen wir mal, eines Polizisten oder Richters einnimmt. Und am Ende dann ohne Projektergebnis dasteht. Ein Auftraggeber, der in Kategorien, wie Schuld und Unschuld denkt und handelt. Und damit aber am Ende scheitert.

Und dann gibt es auf der anderen Seite, im zweiten Projekt, einen Auftraggeber, den ich jetzt, und jetzt kommen wir mal ein bisschen zurück zur Blogparade, als cool, als coolen Auftraggeber bezeichnen möchte, der sich selbst sehr stark auch mit in der Verantwortung für das Projekt sieht. Der versteht, dass er, wenn es darauf ankommt, eigene Ideen einbringen darf und soll. Der unterstützend eingreift, wenn es Probleme gibt, die ganz offensichtlich vom Projektteam nicht alleine gelöst werden können zumindest nicht im vorgegebenen Zeitrahmen, und der dann aber am Ende erfolgreich ist, zwar nicht alle Projektziele erreicht, – in diesem Fall haben wir den Liefertermin verpasst – aber dennoch das Beste aus der Situation macht.

Ein Auftraggeber, der in der Lage ist, differenziert zu denken. Der nicht immer unbedingt in Kategorien von richtig und falsch, sondern auch mal im Sinne von besser geeignet und weniger gut geeignet. Und der verstanden hat, dass Druck nicht die Arbeitsergebnisse verbessert. Im Gegenteil sogar oft, manchmal, ich würde fast sagen, meistens, kontraproduktiv ist.

Was kann ein Auftraggeber mitnehmen?

Was können wir nun aus dieser Geschichte oder aus diesen beiden Geschichten mitnehmen? Ich war mal so frei und habe jetzt für die Blogparade von Thomas Reining den Begriff Führungskraft mal ganz lässig durch Auftraggeber ersetzt, weil ich denke, dass der Auftraggeber, gerade im Projekt, auch immer eine Führungsrolle inne hat. Er gibt die Ziele vor, zumindest den Projektauftrag, aus dem wir dann die Ziele für das Projekt ableiten können. Er schaut, dass die Arbeit in die richtige Richtung läuft und versichert sich dessen immer wieder, zum Beispiel in Lenkungskreisen. Und er hat sich überlegt, wie er damit umgehen möchte, wenn etwas schief geht.

Ich durfte in den letzten Jahren schon sehr viele Auftraggeber erleben und ich weiß es immer zu schätzen, wenn ich auf jemanden  treffe, der seine Rolle eher unterstützend versteht und wahrnimmt und nicht so sehr kontrollierend und der mit Ideen unterstützt, die Umsetzung. Also das was und das wie aber auch durchaus dem Projektteam überlässt. Der versteht, wann er gebraucht wird, um  zum Beispiel aufgrund seiner Position oder Rolle bestimmte Entscheidungen zu treffen. Und dann auch handeln immer in Abstimmung mit dem Projektteam, also die anderen auch ins tun kommt. Der dann aber auch versteht, wenn es einfach mal Zeit ist das Team arbeiten zu lassen und auch auf die Umsetzungsfähigkeit, die Schlagkraft und die Kreativität des Teams zu setzen, denn die ist eigentlich immer da. Ich habe noch nie ein Projektteam erlebt, das nicht ganz grundsätzlich in der Lage wäre eine Aufgabenstellung erfolgreich zu bearbeiten. Also und das ist nun mein Appell an alle Auftraggeber.

Bitte überlegt euch doch mal, wie ihr eure Rolle interpretieren wollt, eher unterstützend oder eher kontrollierend, eher wie im Projekt zwei oder eher wie im Projekt eins?

So sind wir nun am Ende dieser Episode meines Beitrages für die Blogparade. Und ich hoffe, dass ich bei der Blogparade von Thomas vielleicht einen etwas anderen Blickwinkel auf die coole Führungskraft einnehmen konnte. Und vielleicht wollt ihr auch noch die anderen Beiträge der Blogparade lesen oder auch hören, ich weiß nicht, was da noch so alles kommt, welche das sind und wie du das findest. Da gehst du einfach auf die Internetseite von Thomas.

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-08-03 01:00:392018-04-25 08:33:47PMMB000: Der "coole" Auftraggeber - Beitrag zur Blogparade von Thomas Reining

PMMB050: Wie geht eigentlich gutes Projektreporting?

0 Kommentare/in Podcast, Projektdurchführung/von Jörg Walter

Shownotes

Wir haben ein Jubiläum! Das ist die 50. Episode des Projektmanagement im Maschinenbau-Podcasts! Vielen Dank, dass Du als treuer Hörer mit dabei bist!

In dieser Episode werden ich mich ein wenig mit etwas auseinander setzen, was uns als Projektmanager manchmal etwas nervt, aus dem wir aber mit ein wenig Nachdenken einen wirklich guten Nutzen ziehen können: Dem Projektrporting!

In dieser Episode erfährst Du

  1. Was Projektreporting ist und warum wir das im Projekt benötigen
  2. Was aus meiner Sicht zu einem guten Projektreporting mit dazu gehört
  3. Wie Du als Projektleiter einen Nutzen daraus ziehen kannst

Episoden und Links, die ich in der Episode erwähne

  • PMMB038: Ich weiß, was Du letzten Sommer gemacht hast – Das Projektlogbuch
  • Projektlogbuch in der Online-Bibliothek
  • PMMB044: Projektmanagement einführen 3b – Rollen beschreiben

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-08-01 01:00:352018-02-05 22:35:07PMMB050: Wie geht eigentlich gutes Projektreporting?

PMMB049: Experteninterview mit Olaf Kapinski - Welche Aufgabe hat eigentlich ein Auftraggeber? Teil 2

0 Kommentare/in Allgemein, Organisation, Podcast/von Jörg Walter

In unseren Projekten haben wir es nicht nur mit unserem Projektteam zu tun, sondern ganz maßgeblich auch mit unserem Auftraggeber. Der Auftraggeber startet das Projekt, wir berichten an ihn und bekommen Unterstützung, wenn es Probleme im Projekt gibt. Wie sieht das nun aus der Sicht eines erfahrenen Auftraggebers aus? Ich habe mit mit Olaf Kapinski zum Interview getroffen. Dies ist der 2. Teil unseres Gespräches.

Im Interview erfährst Du

  1. Welche Erwartungen der Auftraggeber an den Projektleiter und das Projektteam hat
  2. Wie die Rolle eines Auftraggebers aussieht
  3. Welchen Einfluss der Auftraggeber auf den Projekterfolg hat

Hier noch der Link zum ersten Teil des Interviews: PMMB048: Experteninterview mit Olaf Kapinski – Welche Aufgabe hat eigentlich ein Auftraggeber? Teil 1

Informationen zur Episode:

Olaf Kapinski: Website | Podcast bei itunes | Facebook  | Xing

IT-YoungStars: Website

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-07-27 01:00:532018-04-25 08:34:58PMMB049: Experteninterview mit Olaf Kapinski - Welche Aufgabe hat eigentlich ein Auftraggeber? Teil 2

PMMB048: Experteninterview mit Olaf Kapinski: Welche Aufgabe hat eigentlich ein Auftraggeber? - Teil 1

0 Kommentare/in Allgemein, Organisation, Podcast/von Jörg Walter

Shownotes

In unseren Projekten haben wir es nicht nur mit unserem Projektteam zu tun, sondern ganz maßgeblich auch mit unserem Auftraggeber. Der Auftraggeber startet das Projekt, wir berichten an ihn und bekommen Unterstützung, wenn es Probleme im Projekt gibt. Wie sieht das nun aus der Sicht eines erfahrenen Auftraggebers aus? Ich habe mit mit Olaf Kapinski zum Interview getroffen. Dies ist der 1. Teil unseres Gespräches.

Im Interview erfährst Du

  1. Welche Erwartungen der Auftraggeber an den Projektleiter und das Projektteam hat
  2. Wie die Rolle eines Auftraggebers aussieht
  3. Welchen Einfluss der Auftraggeber auf den Projekterfolg hat

Hier noch der Link zum zweiten Teil des Interviews: PMMB049: Experteninterview mit Olaf Kapinski: Welche Aufgabe hat eigentlich ein Auftraggeber? – Teil 2

Informationen zur Episode:

Olaf Kapinski: Website | Podcast bei itunes | Facebook  | Xing

IT-YoungStars: Website

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-07-25 01:00:252018-02-05 22:34:17PMMB048: Experteninterview mit Olaf Kapinski: Welche Aufgabe hat eigentlich ein Auftraggeber? - Teil 1

PMMB047: Projektmanagement einführen Teil 6 - Bitte keine Cargo-Kulte

0 Kommentare/in Allgemein, Organisation, Podcast/von Jörg Walter

Shownotes

In den letzten Episoden habe ich Dir erläutert, wie ich vorgehe, wenn ich Projektmanagement einführe. Leider beobachte ich sehr oft, dass, aus der Ferne gesehen, alles richtig gemacht wird, aber die Umsetzung dann scheitert oder große Schwierigkeiten verursacht. der Grund dafür sind sehr oft Cargo-Kulte.

In dieser Episode erfährst Du

  1. Was ist ein Cargo-Kult
  2. Was hat ein Cargo-Kult mit der Einführung von Projektmanagement zu tun
  3. Was kannst Du tun um Cargo-Kulte zu vermeiden

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-07-20 01:00:262018-02-05 22:33:49PMMB047: Projektmanagement einführen Teil 6 - Bitte keine Cargo-Kulte

PMMB046: Projektmanagement einführen Teil 5 - Umsetzung organisieren

0 Kommentare/in Allgemein, Organisation, Podcast/von Jörg Walter

Shownotes

Projektmanagement im Unternehmen einzuführen dauert mehrere Monate. Wenn der Produktenstehungsprozess entwickelt und das Projektmanagement-Instrumentarium erarbeitet ist, geht es an die Umsetzung. Wie ich hierbei vorgehe erläutere ich Dir in dieser Episode.

In dieser Episode erfährst Du

  1. Welche Voraussetzungen sollten gegeben sein um mit der Umsetzung zu beginnen
  2. Wie ist meine Vorgehensweise
  3. Wie gehe ich Schritt für Schritt vor
  4. Dinge die mir bei der Umsetzung wichtig sind

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-07-18 01:00:202018-02-05 22:33:15PMMB046: Projektmanagement einführen Teil 5 - Umsetzung organisieren

PMMB045: Projektmanagement einführen Teil 4 - Projektmanagement-Instrumentarium entwickeln

0 Kommentare/in Allgemein, Organisation, Podcast/von Jörg Walter

Shownotes

Ein wesentlicher Teil der Einführung von Projektmanagement ist die Ausarbeitung des Projektmanagement-Instrumentariums. Also, die Festlegung welche Instrumente wie zu verwenden sind. Darüber spreche ich in dieser Episode.

In dieser Episode erfährst Du

  1. Wie ich vorgehe die Projektmanagement Instrumente zu erarbeiten und was mit dabei wichtig ist
  2. Welche Instrumente es gibt und welche in Frage kommen
  3. Meine Tipps und Tricks aus der Praxis

Intro- und Outromusik

Die Musik für Intro und Outro wurde freundlicherweise von pinningmerkaba unter dem Titel Urbana-Metronica (wooh-yeah mix) unter einer Creative Common Lizenz (CC-BY 3.0) zur Verfügung gestellt.

https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg 0 0 Jörg Walter https://projektmanagement-maschinenbau.de/wp-content/uploads/2016/01/PMMB_Logo.jpg Jörg Walter2017-07-11 01:00:272018-02-05 22:32:53PMMB045: Projektmanagement einführen Teil 4 - Projektmanagement-Instrumentarium entwickeln
Seite 8 von 13«‹678910›»

Podcast abonnieren

Projektmanagement

Über Jörg Walter

Leistungen

Ressourcen

Podcast

Wissen

Online-Bibliothek

Projektmanagement-Plattform

Kontakt

Dipl.-Ing. Jörg Walter
WALTER | Projekt und Innovation GmbH

Blücherstr. 32
75177 Pforzheim

T: +49 7231 7763897
F: +49 7231 7763898

E: joerg.walter@projekt-und-innovation.de
W: www.projekt-und-innovation.de

© Copyright 2020 - projektmanagement-maschinenbau.de | All rights reserved | Impressum und Datenschutzerklärung
  • Link zu Facebook
  • Link zu Xing
  • Link zu LinkedIn
  • Link zu X
  • Link zu Youtube
Nach oben scrollen Nach oben scrollen Nach oben scrollen

Diese Seite verwendet Cookie. Durch die weitere Nutzung der Seite stimmst Du der Verwendung von Cookies zu.

OKMehr erfahren

Cookie- und Datenschutzeinstellungen



Wie wir Cookies verwenden

Wir können Cookies anfordern, die auf Ihrem Gerät eingestellt werden. Wir verwenden Cookies, um uns mitzuteilen, wenn Sie unsere Websites besuchen, wie Sie mit uns interagieren, Ihre Nutzererfahrung verbessern und Ihre Beziehung zu unserer Website anpassen.

Klicken Sie auf die verschiedenen Kategorienüberschriften, um mehr zu erfahren. Sie können auch einige Ihrer Einstellungen ändern. Beachten Sie, dass das Blockieren einiger Arten von Cookies Auswirkungen auf Ihre Erfahrung auf unseren Websites und auf die Dienste haben kann, die wir anbieten können.

Notwendige Website Cookies

Diese Cookies sind unbedingt erforderlich, um Ihnen die auf unserer Webseite verfügbaren Dienste und Funktionen zur Verfügung zu stellen.

Da diese Cookies für die auf unserer Webseite verfügbaren Dienste und Funktionen unbedingt erforderlich sind, hat die Ablehnung Auswirkungen auf die Funktionsweise unserer Webseite. Sie können Cookies jederzeit blockieren oder löschen, indem Sie Ihre Browsereinstellungen ändern und das Blockieren aller Cookies auf dieser Webseite erzwingen. Sie werden jedoch immer aufgefordert, Cookies zu akzeptieren / abzulehnen, wenn Sie unsere Website erneut besuchen.

Wir respektieren es voll und ganz, wenn Sie Cookies ablehnen möchten. Um zu vermeiden, dass Sie immer wieder nach Cookies gefragt werden, erlauben Sie uns bitte, einen Cookie für Ihre Einstellungen zu speichern. Sie können sich jederzeit abmelden oder andere Cookies zulassen, um unsere Dienste vollumfänglich nutzen zu können. Wenn Sie Cookies ablehnen, werden alle gesetzten Cookies auf unserer Domain entfernt.

Wir stellen Ihnen eine Liste der von Ihrem Computer auf unserer Domain gespeicherten Cookies zur Verfügung. Aus Sicherheitsgründen können wie Ihnen keine Cookies anzeigen, die von anderen Domains gespeichert werden. Diese können Sie in den Sicherheitseinstellungen Ihres Browsers einsehen.

Andere externe Dienste

Wir nutzen auch verschiedene externe Dienste wie Google Webfonts, Google Maps und externe Videoanbieter. Da diese Anbieter möglicherweise personenbezogene Daten von Ihnen speichern, können Sie diese hier deaktivieren. Bitte beachten Sie, dass eine Deaktivierung dieser Cookies die Funktionalität und das Aussehen unserer Webseite erheblich beeinträchtigen kann. Die Änderungen werden nach einem Neuladen der Seite wirksam.

Google Webfont Einstellungen:

Google Maps Einstellungen:

Google reCaptcha Einstellungen:

Vimeo und YouTube Einstellungen:

Datenschutzrichtlinie

Sie können unsere Cookies und Datenschutzeinstellungen im Detail in unseren Datenschutzrichtlinie nachlesen.

Datenschutzerklärung
Einstellungen akzeptierenVerberge nur die Benachrichtigung