Wenn weder klassisch noch agil passt Hybrides Projektmanagement in Logistik- und Produktionsplanungsprojekten

Teil 2:
Projektsteuerung
Hybrides Projektmanagement vereint die Vorteile von klassischem und agilem Projektmanagement: Einerseits fixe Termine einzuhalten, andererseits auch bei kurzfristigen Änderungen flexibel zu reagieren. Johannes Schweizer von der BLSG AG und Florian Meindl beschreiben, wie sie Logistikprojekte hybrid betreuen. In Teil 1 haben sie ihr Vorgehen bei der Projektplanung beschrieben, in Teil 2 erklären sie nun, wie sie Teams zusammenstellen und das Projekt steuern.

 

Wenn weder klassisch noch agil passt Hybrides Projektmanagement in Logistik- und Produktionsplanungsprojekten

Teil 2:
Projektsteuerung
Hybrides Projektmanagement vereint die Vorteile von klassischem und agilem Projektmanagement: Einerseits fixe Termine einzuhalten, andererseits auch bei kurzfristigen Änderungen flexibel zu reagieren. Johannes Schweizer von der BLSG AG und Florian Meindl beschreiben, wie sie Logistikprojekte hybrid betreuen. In Teil 1 haben sie ihr Vorgehen bei der Projektplanung beschrieben, in Teil 2 erklären sie nun, wie sie Teams zusammenstellen und das Projekt steuern.

 

In Teil 1 dieses Zweiteilers haben wir unser Vorgehen bei der hybriden Projektplanung erklärt. Wir planen hybrid, indem wir gemeinsam mit unserem Auftraggeber einen "klassischen" Rahmen mit Projektphasen, festgelegten Meilensteinen und einem Projektstrukturplan schaffen, innerhalb der einzelnen Projektphasen und teilweise phasenübergreifend aber agil planen. Dazu erstellen wir einen Product Backlog, der sich aus einem Project Backlog (mit übergeordneten Zielen, Prämissen, Randbedingungen oder Qualitätseigenschaften, die die gesamte Planung und damit alle Phasen betreffen) und Phase Backlogs (bekannten Anforderungen für eine Projektphase, bestehend aus notwendigen Zwischenergebnissen, Meilensteinergebnissen, funktionalen Eigenschaften etc.) zusammensetzt.

Bei der Projektsteuerung dominieren die Herausforderungen Konkurrierende Ziele und starke Abhängigkeiten innerhalb des Projektteams. Dies bedingt die Verankerung eines "Teamgedankens" über eine gemeinsame Zielvorgabe und Ergebnisverantwortung sowie einen klar definierten Modus zur Zusammenarbeit im Projektteam.

Der zweite Teil unseres Beitrags betrachtet daher zunächst die Teamzusammensetzung, anschließend basierend auf der hybriden Projektplanung den Übergang zur Projektsteuerung mit entsprechenden Events/Meetings und Controlling-Instrumenten.

Das Team richtig zusammenstellen

Bei der BLSG AG verstehen wir als Team im Kontext hybriden Projektmanagements ein Scrum-Team. Es setzt sich auch im hybriden Modell zusammen aus einem Product Owner, einem Scrum Master und einem Development Team, das wir als Planungsteam bezeichnen.

Die Besetzung des Scrum Masters und Product Owners erfolgt analog dem klassischen PM-Ansatz in der Projektplanungsphase in Abstimmung mit dem Auftraggeber. Zusammen mit dem Auftraggeber und dem Product Owner legen wir fest, welches Know-how im Planungsteam für das Projekt und welche Kapazität (Grundlast) notwendig ist. Das Planungsteam inkl. der notwendigen Kapazität wird in einem anschließenden Abstimmungstermin mit den jeweiligen Vorgesetzten festgelegt.

Product Owner

Die wichtigste Position ist die des Product Owners. Er verantwortet das Management des Product Backlogs. Indem er Anforderungen ergänzt, priorisiert und streicht, entscheidet er, WAS wann getan wird. Damit er das erfolgreich tun kann, "muss die gesamte Organisation seine Entscheidungen respektieren" (Zitat Scrum Guide). Daraus ergeben sich für uns folgende Anforderungen an die Position des Product Owners.

Der Product Owner sollte:

  • das Vertrauen des Projektauftraggebers/-verantwortlichen genießen
  • idealerweise disziplinarische Weisungsbefugnis über die benötigten Fachbereiche (Planungsabteilungen und Betreiber) besitzen, die Teil des Planungsteams werden – mindestens jedoch im Unternehmen (idealerweise auf allen Ebenen inkl. Shopfloor) vernetzt und respektiert sein, um als Schnittstelle zwischen den Process Ownern (Betreibern der Produktions- und Logistikprozesse) und den Planungsabteilungen fungieren zu können
  • große Fachkenntnis über die Prozesse beim Auftraggeber mitbringen
  • genug Zeit haben, um die Rolle auszufüllen

Der Product Owner kann im Idealfall formulieren, welche Mitglieder das Development Team haben sollte, um die gewünschten Projektergebnisse zu erzeugen. Er muss (u.U. mit Unterstützung des Auftraggebers) mit der Stamm- bzw. Linienorganisation abstimmen, dass die entsprechenden Mitarbeiter Teil des Planungsteams werden.

Unsere Auftraggeber haben meist die Anforderung an uns, zu spezifizieren, welche Know-how-Träger für die Projektabwicklung notwendig sind. Dies bedeutet, dass wir als fachliche Experten der Produktions- und Logistikplanung die notwendigen Disziplinen/Abteilungen für das Team definieren.

Scrum Master

Für den Scrum Master sieht der Scrum Guide folgende Eigenschaften vor: "Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Er tut dies, indem er dafür sorgt, dass das Scrum Team die Theorie, Praktiken und Regeln von Scrum einhält. (…) Der Scrum Master hilft denjenigen, die kein Teil des Scrum Teams sind, zu verstehen, welche ihrer Interaktionen mit dem Team sich hilfreich auswirken und welche nicht." Der Scrum Master beseitigt demnach Hindernisse, die das Planungsteam bremsen und verbessert damit die Leistung des Scrum Teams. Dazu ist regelmäßig auch die Eskalation über den Product Owner und den Auftraggeber notwendig.

Die Aufgaben des Scrum Masters im hybriden Umfeld erfordern:

  • Know-how über agile und klassische Elemente der hybriden Projektvorgehensweise
  • Einfluss auf die Organisation, um Hindernisse wirksam zu beseitigen
  • Akzeptanz im Planungsteam
  • Fähigkeit, einen neutralen Standpunkt einzunehmen, um unvoreingenommen Konflikte zu moderieren

Bei den Anforderungen zeigt sich, warum wir als externe Beratung diese Rolle häufig einnehmen. Alle Anforderungen durch einen internen Mitarbeiter perfekt zu erfüllen, ist schwierig. Allerdings haben wir als externe Unterstützung im Gegensatz zu einem internen Scrum Master i.d.R. eine vertraglich vereinbarte Ergebnisverantwortung, v. a. dann, wenn wir mit eigenen Mitarbeitern Know-how und Kapazität für das Planungsteam liefern. Somit ist es für uns besonders wichtig, den Product Owner intensiv zu begleiten und zu unterstützen. Das Aufgabenspektrum geht also über das eines "klassischen" Scrum Masters hinaus, damit wir unserer Ergebnisverantwortung gerecht werden können.

Klassische vs. agile Rollen im hybriden Projektmanagment

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 1
Kommentare 2

Fortsetzungen des Fachartikels

Teil 1:
Projektplanung
In Logistikprojekten müssen fixe Termine eingehalten und kurzfristige Änderungswünsche zahlreicher Schnittstellen umgesetzt werden können. Weder das klassische noch das agile Projektmanagement wird diesen gegensätzlichen Anforderungen gerecht.

Alle Kommentare (2)

Tassilo
Kubitz

Hallo Herr Meindl, hallo Herr Schweizer, Sie schreiben viel über Verantwortung - auch über die des Teams. In der agilen Welt übernimmt das Team mehr Verantwortung (wie Sie ja auch geschrieben haben). Meine Frage dazu: Wie übernimmt das Team die Verantwortung? Sie zu haben ist das eine, sie zu übernehmen etwas anderes. Könnten Sie von konkrete Ereignissen berichten, wie sie die Konflikte im und mit "dem Team an sich" aufgelöst haben? Zu den klassischen Konfliktfeldern Termin und Kosten haben Sie leider nichts weiter geschrieben. Vielen Dank und herzliche Grüße Tassilo Kubitz

 

Sehr geehrter Herr Kubitz vielen Dank für Ihre Frage! Wir möchte Sie in diesem Zuge auch um Entschuldigung für die späte Antwort bitten! -- Das Team hin zu einer aktiv gelebten Ergebnisverantwortung zu entwickeln ist immer ein Prozess, der zum einen Zeit und zum anderen eine intensive Begleitung im Sinne eines Coachings braucht. Grundlage ist wie im Artikel beschrieben eine strikte Rollen- und Eventdefinition mit klaren Regeln (= agiles Framework) angepasst auf die konkrete Projektorganisation. Alles was hier nicht klar definiert wird, holt einen im späteren Projektverlauf ein. Das agile Framework sollte auch (im Sinne einer permanenten Qualifizierung) stets sichtbar und transparent gehalten werden, z.B. in einer Scrum-Fibel für alle Projektteilnehmer oder auch über „Marketing“-Folien im Scrum Room. Darauf aufbauend ist wie ebenfalls im Artikel beschrieben im Rahmen der Projektsteuerung eine konsequente Einhaltung des agilen Frameworks notwendig, da das der zentrale Enabler für eine Verantwortungsdelegation vom Product Owner an das Planungsteam ist. Das fängt bei kleinen Dingen an wie einer täglichen Teilnahme am Daily Scrum zur Synchronisation des Teams und geht bis zur Aufbereitung klarer Umsetzungsempfehlungen (Verantwortung über das WIE) bzgl. zentraler Projektergebnisse in den drei Dimensionen Ergebnis-Termin-Kosten. Dabei nehmen der PO und der Scrum Master wie beschrieben die Coaching-Rolle ein. Gerade der PO muss als Vorbildfunktion seiner Rolle gerecht werden und die Rolle des Teams einfordern. Über ein Coaching hinaus müssen der PO und der Scrum Master dem Team auch Ängste nehmen (Verantwortungsdelegation ist ein kontinuierlicher Change Prozess!). Hierbei hat die Retrospective mit einer offenen Feedback- und Fehler-Kultur eine entscheidende Bedeutung. Werden Ziele nicht erreicht, darf dies nicht sofort zu einem Ausbrechen aus dem Prozess führen. Gerade vor ein paar Tagen habe ich die Diskussion mit einem PO geführt, um ihn von einem sofortigen Einschreiten abzuhalten. Ein bisschen Zeit und Vertrauen muss man dem Team schon geben. Ein Feedback ist allerdings auch wichtig. -- Anhand folgender Beispiele möchten wir das Coaching durch den Scrum Master konkretisieren. - Im Rahmen eines Fabrikplanungsprojekts haben wir es nach einiger Zeit geschafft, dass das Team nun entscheidungsfreudiger ist. Zu Beginn wurden vor allem Entscheidungsvorlagen gebastelt. Wobei die Fragen, die nur interdisziplinär zu beantworten sind (Schnittstellen der Funktionen im Dev. Team), ausgeklammert bzw. maximal stiefmütterlich behandelt wurden. Ein Fertigungsplaner im Bereich Vorfertigung hat beispielsweise mehrere Optionen zu einer vom Kunden gewünschten Volumensteigerung (wie z.B. zusätzliche Anlage, Erweiterung einer bereits beschafften Anlage, Mitnutzung einer bereits beschafften Anlage eines anderen Projekts) detailliertest ausgeplant, sekundengenaue MTM-Analysen inklusive. Auswirkungen auf den Prozess und somit auf Kosten und Investitionen in anderen Fertigungsbereichen, auf das Layout, auf Logistikprozesse usw. waren somit gar nicht Teil der Entscheidungsvorlage. Das Denken im Gesamtzusammenhang und das Wissen, auf was individuelle Planungsänderungen alles Einfluss haben können fehlte zu Beginn komplett. Wir fordern von den Planungsteammitgliedern ein, dass sie alle Entscheidungsvorlagen als Team soweit aufbereiten (inhaltlich, nicht graphisch), dass sie selbst in der Lage wären, eine Entscheidung zu treffen. Damit einher geht klare, begründete Empfehlung aus dem Team für jede Entscheidung, die sich das Team (noch) nicht selbst zutraut. Während der Präsentation der Entscheidungsvorlage dringen wir darauf, dass die Entscheidung sofort fällt und nicht vertagt wird. Falls dies doch passiert, versuchen wir zu klären, warum die Erkenntnis (dass die Entscheidung nicht getroffen werden kann) erst jetzt fällt (Was hätte man tun müssen/müsste man beim nächsten Mal tun…). Wenn man soweit ist, dass der Entscheidungsträger den Empfehlungen in der Regel folgt, kommt die Einsicht für den letzten Schritt von alleine. „Warum könnt ihr (das Planungsteam) das nicht direkt entscheiden?“. Inzwischen hat sich die „Eskalationsfreude“ deutlich zurückentwickelt. -- Im Rahmen eines hybriden Projekts (Fahrzeugprojekt Zulieferer Automotive) mit einem Scrum Team aus Entwicklung, Konstruktion, Einkauf, Fertigungs-, Logistik- und Qualitätsplanung haben wir mehrfach erlebt, dass das Team dazu neigt, auftretende Schwierigkeiten zu Hindernissen zu erklären (und sie damit aus dem Verantwortungsbereich zu schieben). Ein Beispiel ist die folgende Situation: In der Zusammenarbeit mit einem weiteren Planungsteam auf einem anderen Kontinent kommt es zu Unstimmigkeiten. Die von dort stammende Kritik an bestimmten Dokumenten kann nicht nachvollzogen werden. Anstatt in einem kurzen Telefonat dieses gegenseitige Verständnis zu schaffen, wird es als Hindernis in das Daily Scrum gespielt. Dies ist natürlich eine Einladung zur Intervention durch den Scrum Master. -- Im Rahmen einer Retrospektive wurde erkannt, dass die interkontinentale Kommunikation nicht zufriedenstellend funktioniert, was sich zunehmen zu einem Hindernis für das Planungsteam entwickelte. Um die Zusammenarbeit nachhaltig zu verbessern haben wir daraufhin die agilen Methoden auch im internationalen Partner-Team eingeführt, ergänzt um eine Schnittstelle zwischen den Teams („scaling scrum“). Im Rahmen der dortigen „Anlaufphase“ konnten wir wieder einmal in der vollen Bandbreite erleben, wie schwierig es für ein neues Team zu Beginn ist, die Ergebnisverantwortung anzunehmen. Ein Team, dass gewohnt ist, Aufgabendelegiert zu bekommen und dann einen Status zu reporten, tut sich naturgemäß schwer mit der neuen Rolle. Das gleiche gilt auch für die Product Owner (wir haben in diesem Projekt ein PO-Team). Doch wie äußern sich diese Schwierigkeiten? Die Product Owner tauchen im Daily Scrum auf und reden mit. Das gemeinsame Ziel wird unterschiedlich interpretiert. Die Planungsteammitglieder schicken uninformierte Vertreter. Das Planungsteam „berichtet“ an den Scrum Master, statt gegenseitig an sich selbst. Der Link zwischen Aufgaben und dem Sprint Backlog geht z.T. verloren, weil das Team Aufgaben aus dem Tagesgeschäft mitbringt und zugleich dazu tendiert, interdisziplinäre Aufgaben aus dem Sprint Backlog zu vergessen. Neben der permanenten intensiven Intervention im Rahmen der Events ist hier vor allem die konsequente Sprint Retrospective extrem wichtig, um gemeinsam im Scrum Team am Rollenverständnis, an den Regeln und an der „Definition of Done“ zu arbeiten. Die gemeinsam festgelegten Regeln platzieren wir immer auch sichtbar am Scrum Board. -- Um bei Zielkonflikten Ergebnisse-Termine-Kosten ein entscheidungsfähiges Planungsteam zu haben, sehen wir nur einen vielleicht radikal erscheinenden Ansatz Das Entscheidungsparadigma umzudrehen heißt, dieses vollständig umzudrehen! Also letztlich das komplette magische Dreieck Ergebnisse-Termine-Kosten in die Verantwortung des Teams zu legen. Ansonsten kann ein Team nie vollständig eigenverantwortlich über das WIE entscheiden. Natürlich lässt sich das Ausmaß der Verantwortung (gerade in der Dimension Kosten) wieder durch den Product Owner steuern. Dazu kann zum einen der Project Backlog mit übergeordneten Akzeptanzkriterien (z.B. hinsichtlich Kosten) dienen, zum anderen stellen die genannten Events des agilen Framework starke Quality-Gates dar. Vorausgesetzt wie eingangs beschrieben ist wiederum die strikte Definition und Umsetzung des agilen Frameworks im Projekt. -- Wir hoffen, damit Ihrer Frage einigermaßen gerecht zu werden. Falls weitergehendes Interesse besteht, stehen wir gerne für einen persönlichen Austausch zur Verfügung!