PMMB067: Ankündigung – Die Projektsprechstunde

Abonnieren

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

Der Podcast soll sich ja mit Projektmanagement im Maschinenbau beschäftigen. Dabei zum einen mit den Grundlagen: Wie macht man gutes Projektmanagement? Wie bekommt man erfolgreiche Projekte? Zum Anderen aber auch mit Deinen, ganz konkreten Fragen.

Aus diesem Grund wird es ab 2018 ein neues Format hier im Podcast geben: Die Projektsprechstunde!

In der Projektsprechstunde werde ich Deine Fragen beantworten. Wenn Du möchtest, wird das natürlich auch anonymisiert und verfremdet.

Du darfst mir Deine Fragen an sprechstunde@projektmanagement-maschinenbau.de schicken. Ich bin schon sehr gespannt darauf.

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

Der Projektstrukturplan: Den Überblick im Projekt behalten

Der Projektstrukturplan ist eines der wichtigsten und wirkungsvollsten Instrumente im Projektmanagement.

In meinen Seminaren werde ich immer wieder gefragt: „Was ist denn dein wichtigstes Instrument im Projektmanagement? Wenn du alles andere weglassen müsstest, was würdest du behalten?“ Meine Antwort ist in der Regel: Der Projektstrukturplan!

Ich erstelle für jedes Projekt, und sei es noch so klein, eine ordentliche Struktur. Sie ist die erste und wichtigste Planungsgrundlage, sozusagen die Mutter aller Instrumente.

In der Praxis leider selten eingesetzt

Ich beobachte oft, dass die Bezeichnung Projektstrukturplan oder auch Projektstruktur in den Unternehmen sehr willkürlich benutzt wird.

Gelegentlich verwendet man den Begriff für die Zusammensetzung des Teams, ähnlich wie bei einem Organigramm. Manchmal wird auch eine Multiprojektliste so genannt, also die Übersicht über die laufenden oder anstehenden Projekte.

Ich habe in den vergangenen Jahren einiges dazu gesehen und wirklich das Wenigste davon hat etwas mit der tatsächlichen Struktur eines Projektes zu tun. 

Was ist nun ein Projektstrukturplan

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

Die Projektstruktur ist für mich immer die Ausgangslage der weiteren Planungsarbeit, das allererste, was zu tun ist, wenn ich ein Projekt aufplane. Ausgehend von dieser Basis folgen dann die weiteren Schritte.

Wenn ich alle Arbeitspakete und Aufgaben vollständig erfasst habe, kann ich beginnen, diese zu terminieren und den Terminplan abzuleiten, dann die Projektkosten und das Projektbudget zu ermitteln. Wenn ich weiß, welche Aufgaben genau anstehen, kann ich passgenau das Projektteam zusammenstellen. Denn dann weiß ich ganz genau, für welche Aufgabe ich jemanden brauche und wie lange und mit welchem Aufwand.

Mit einer guten Projektstruktur habe ich eine deutlich bessere Grundlage für eine stabile und realitätsnahe Projektplanung.

Der Projektstrukturplan ähnelt sehr einem Organigramm

Von der Art der Darstellung ähnelt der Projektstrukturplan einem Organigramm, beide sehen aus wie ein umgedrehter Baum. Der Stamm ist oben, das ist im Organigramm meistens das Unternehmen, und darunter sind dann die Abteilungen und so weiter abgebildet.

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

Im Projektstrukturplan steht Arbeit

Im Projektstrukturplan dagegen steht etwas anderes in den Kästchen: Arbeit! Es stehen keine Personen oder Abteilungen drin, sondern eben Arbeit!

Das ist der wesentliche Unterschied, auch wenn die Darstellungsformen sich ähneln. Später mögen Abteilungen und Personen in der Darstellung hinzukommen, nämlich dann, wenn man die Aufgaben verteilt. Aber wichtig ist, dass zunächst die Arbeit, die Aufgaben möglichst präzise definiert und abgebildet werden.

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

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

Teilprojekte und Arbeitspakete

Die erste Ebene eines Projektstrukturplanes sind dann die sogenannten Teilprojekte. Unterhalb der Teilprojekte finden sich die Arbeitspakete wieder.

In manchen Projekten reichen diese zwei Ebenen nicht aus, da das Projekt größer und komplizierter ist. Man kann dann weitere Ebenen der Strukturierung einführen (z.B. Haupt-Arbeitspakete, Unterarbeitespakete, etc.). Ziel ist es dabei immer eine möglichst gute Struktur für das Projekt zu finden.

Es gibt vier Strukturierungs-Möglichkeiten

Es gibt grundsätzlich 4 grundsätzliche Möglichkeiten bzw. Arten einen Projektstrukturplan zu strukturieren:

  • Phasen-/ ablauforientiert:
    Die Teilprojekte ergeben sich aus den Phasen des Projektes. Darunter sind dann jeweils die Arbeitspakete der jeweiligen Projektphase einsortiert. Diese Strukturierungsart wird oft verwendet, wenn das Projekt noch nicht so gut überblickt wird.
  • Objektorientiert:
    Die Teilprojekte sind dabei physische Objekte  (z.B. bei einem Fahrzeugzeugprojekt: Fahrwerk, Antrieb, Interieur, Sicherheitssysteme, etc.). Diese Strukturierungs-Art wird sehr oft in Bauprojekten verwendet (da sind die Objekte dann die Gewerke)
  • Funktionsorientiert:
    Die Teilprojekte ergeben sich aus den am Projekt beteiligten Funktionsbereichen (z.B. Entwicklung, Produktion, Marketing, Vertrieb, etc.). Diese Art der Strukturierung verwende ich oft in  Produktentwicklungsprojekten.
  • Gemischtorientiert:
    Die gemischtorientierte Form der Projektstrukturierung kombiniert die oben genannten Strukturierungsformen miteinander.

3 gute Gründe für einen Projektstrukturplan

Es gibt für mich drei gute Gründe, warum ich in meinen Projekten immer eine Projektstruktur erstelle.

Vollständigkeit

Wenn ich sicher sein kann, dass ich alle Arbeiten eines Projektes erfasst habe, dann kann ich auch sicher sein, dass ich im Projekt keine oder nur ganz wenige Überraschungen erlebe. Wie oft ist es schon vorgekommen, dass Projekte deutlich länger dauern und teurer werden, als ursprünglich einmal geplant? Das passiert dann, wenn Arbeitspakete schlicht und ergreifend vergessen – oder manchmal auch bewusst ignoriert – werden.

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

Transparenz

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

Planungsgrundlage

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

Der Nutzen wird in der Praxis oft unterschätzt

Meiner Erfahrung nach wird in der Praxis zu wenig Zeit in eine gute Projektstruktur investiert. Viele Projekte leben von Monat zu Monat, das ist die Sichtweite, die die meisten Projekte und die meisten Projektteams haben.

Wenn ich frage: „Was ist als nächstes zu tun?“, dann bekomme ich meistens die Aufgaben des nächsten Monats aufgelistet – aber darüber hinaus hat keiner einen Überblick. Und diese Teams wundern sich dann, wenn sie Monat für Monat den Fertigstellungstermin verschieben müssen – weil keiner über diese Grenze hinaus geschaut hat, weil keiner den Überblick über alle Arbeitspakete hat und somit auch keine verlässliche Aussage machen kann.

Mit einem Projektstrukturplan als Planungsgrundlage würde das nicht passieren

PMMB062: Kleine Projekte managen – Wie geht das?

Abonnieren

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

Auch kleine Projekte haben eine Menge Besonderheiten und viele Unternehmen denken, dass sich der Aufwand für Projektmanagement für kleine Projekte nicht lohnt. Und tatsächlich sollte das Projektmanagement auf die Größe eines Projekt angepasst sein. Wie sieht also gutes Projektmanagement für kleine Projekte aus? Damit beschäftige ich mich in dieser Episode.

In dieser Episode erfährst Du:

  • Was verstehe ich unter kleinen Projekten
  • Was macht kleine Projekte aus Projektmanagementsicht so besonders
  • Was ist ein geeignetes Projektmanagement-Setup für kleine Projekte
  • Worauf bei kleinen Projekten zu achten ist

Themen, die ich in dieser Episode erwähne:

PMP002: Projekt oder kein Projekt?

PMMB001: Projektstruktur – Die Mutter aller Instrumente

PMMB002: In 5 Schritten zum Terminplan

PMMB036: Warum Du eine Zielsetzung brauchst und das genau geht

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

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

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

Abonnieren

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

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:

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.

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

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

Abonnieren

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

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

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

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

Abonnieren

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

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

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

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

Abonnieren

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

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

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