Hi, herzlich willkommen in dieser Lektion, in der Du von mir etwas über die Motivation zu diesem Kurs erfährst und auch einen kleinen Einblick in den Praxisalltag bekommst.

Nun zum Inhalt dieser Lektion:

Entspricht der Kursinhalt meinen Praxisanforderungen?

Ich habe diese Kursreihe nicht nur deshalb erstellt, weil ich den Schwenk von Präsenztrainings über Remote-Trainings zu wirtschaftlich sinnvolleren Online-Basistrainings vollziehen möchte. Ich habe meine Präsenttrainings und Coachings auch in der Vergangenheit stark auf die praktischen Notwendigkeiten ausgerichtet und orientiere den Inhalt deshalb am Tages- und Projektverlauf.

Teammitglieder machen ihre Trainings aber typischerweise themenspezifisch und müssen die Trainingsinhalte dann mit viel Geschick und Können mit den passenden Situationen verbinden. Mein Ansatz sieht deshalb vor, dass ich den Inhalt vieler verschiedener Trainings in einem Training zusammenfasse und die Abfolge der Lerninhalte am realen Tages- und Projektablauf anpasse. Genau das kannst Du auch in den bereits vorgestellten Kursreiheninhalten nachvollziehen.

Wir Starten bei der Erkennung von Herausforderungen und der Ableitung von Strategie-Anforderungen, gehen dann über das Projekt-Setup, das Herunterbrechen von strategischen Anforderungen, die fachliche Anforderungsermittlung bis zur Realisierung der Lösung. Auch die Anforderungsobjekte und Zeremonien gehen wir in exakt der tatsächlich praktizierten Reihenfolge durch.

Spricht der Kurs Herausforderungen offen an?

Bei mir hat sich dieser Ansatz ganz gut bewährt. Auch beim Inhalt gehe ich über den typischen Rahmen von Trainings für das agile Projekt-Management hinaus. Wenn Du einen Dozenten fragst, was er Dir in kritischen Projektsituationen vorschlägt, dann wird er Dir überwiegend mit einem süffisanten Grinsen viel Kreativität bei der Lösung vorschlagen. Natürlich gibt es in Projekten immer wieder dieselben Herausforderungen. Lösungsansätze greifen jedoch tief in individuelle Strukturen ein. Ich verbrenne mir die Finger gerne, spreche die immer wiederkehrenden Herausforderungen offen an und stelle Dir dazu auch Lösungsansätze zur Verfügung. Denn genau an diesen Herausforderungen scheitern die meisten Projekte. Ich habe gute Lösungen kennengelernt und gebe diese gerne an Dich weiter.

Hält sich der Kursinhalt streng an Theorien von Methoden und Frameworks?

Wenn ich mich heute in Projekten so umschaue, dann finden wir im Bereich von Projektmethoden einen wahren Wettbewerb der Denkschulen, bei dem die jeweiligen Anhänger die Prinzipien ihrer Denkschule verteidigen – ja, regelrecht miteinander streiten und konkurrieren, als gäbe es kein Links und Rechts.

Da hat einmal jemand einen Kurs besucht und ein Zertifikat erhalten, hat jetzt einen schönen Titel und vielleicht sogar ein paar Euro mehr auf dem Gehaltszettel. Alles Erlernte scheint in Stein gemeißelt, das einzig Wahre – nun ja: es ist das Einzige, was jemand ohne umfangreiche Projekterfahrung kennt. Und daran hält er sich fest, weil er darüber hinaus keine Lösungen parat hat. Egal ob die erlernte Lösung für die momentane Herausforderung zielführend ist oder nicht.

Die älteren Mitarbeiter hängen an klassischen Wasserfall-Modellen, jüngere an Kanban- oder Scrum-Arbeitsmodellen. Meist deshalb, weil sie sich nur mit ihren erlernten Arbeitsabläufen auskennen. Und andere arbeiten, wie sie es schon immer getan haben, nämlich unkoordiniert und chaotisch.

Nun ist es so, dass sich die Anforderungen eines Unternehmens selten ideal in einer Projektmethode abbilden lassen und sich zudem leider im Laufe der Zeit verändern. Scrum ist zum Beispiel extrem flexibel und effizient, damit ideal für reine Software-Unternehmen geeignet. Das pure Scrum kommt bei industriellen Fertigungsunternehmen aber schnell an seine Grenze. Kanban ist aus der industriellen Fertigung bei Toyota entstanden und deshalb gut für deren Anforderungen geeignet, aber nicht so flexibel und effizient wie Scrum. Das Wasserfall-Modell ist aus dem Bedarf entstanden, Fehler zu vermeiden, möglichst viel einzuplanen und eine Aussage zu den Realisierungszeitpunkten, den entstehenden Kosten und der Personalplanung im Projekt liefern zu können, dafür aber alles andere als flexibel, schnell und effizient. Und das Arbeitsergebnis bzw. die Einsicht dessen Nichterreichbarkeit ist beim Wasserfall-Modell extrem spät verfügbar – dann, wenn das ganze Budget bereits ausgegeben ist.

Hey, und irgendwie ging es ja schon immer, auch ohne Wasserfall, ohne Kanban und ohne Scrum. Oder?

Wofür gibt es Methoden und Frameworks?

Dafür gab es jedoch auch schon immer Beschwerden über nicht eingehaltene Budgets, Realisierungszeitpunkte, nicht erfüllte Anforderungen oder der ewig lange Realisierungszeitraum von nachgeschobenen Anforderungen bis zur Verfügbarkeit. Nicht zu vergessen die vielen erfolglosen Projekte, welche die Budgets und Ressourcen bis zum bitteren Ende ausgesaugt haben. Bedenke die vielen verspäteten Fertigungsanläufe, die zusätzliche Zeit, Budget, Ressourcen, Überarbeitungen, komplette Neuentwicklungen nötig gemacht haben, dem Wettbewerb einen Vorsprung gegeben haben. Oder prominente Beispiele wie den Airbus A380 mit seiner nicht passenden Verkabelung, den Airbus A400M mit den nicht kompatiblen Systemen, den Hauptstadtflughafen BER mit seinen unkoordinierten Schnittstellen und nicht erfüllten Anforderungen, neue ICE-Modelle, die erst Monate und Jahre später in den Produktivbetrieb gehen konnten. Die Liste lässt sich wohl bis in jedes einzelne Unternehmen herunter verlängern.

Woran scheitern Projekte?

Wer von Euch kennt die Situation nicht? Kaum ist das Projekt gestartet, kommen die ersten Fragen, wie weit man denn sei. Diese Fragen kommen auch nach einem Monat, etwas nachdrücklicher nach 3 Monaten, nach 6 Monaten vielleicht eine kleine Eskalation gefällig? … und wenn die Antwort dann immer noch lautet, dass das Projekt-Setup noch nicht abgeschlossen ist, es noch nicht einmal ein verabschiedetes System-Architektur-Ergebnis gibt und auch die Implementierung noch kein nennenswertes Ergebnis zeigt, dann liegt da was im Argen. Und dann lässt auch die Geduld der Budgetgeber und der mitarbeitenden Fachbereiche nach. Der Druck wächst – und dann beginnt der Murks.

Nun ja, vielleicht sollten wir doch von den Erfahrungen anderer lernen. Denn Projektmethoden beinhalten nichts anderes, als Handlungsvorschläge zur Vermeidung von Problemen, die andere längst hatten und dafür Vermeidungsstrategien entwickelt haben. Wir behandeln in der Folge dieser Lektion eine Mischung aus mehreren Methoden, jede an der geeigneten Stelle und mit der Option, Dir den individuell passendsten Weg auszusuchen. Dabei entscheide ich mich ganz bewusst gegen die Verteidigung von Methoden-Prinzipien, weil ich mich wenig von Theorie, dafür umso mehr von Praxiserfahrungen leiten lasse. Für einen besseren Einblick, warum wir etwas wie machen, betrachte ich nicht nur das Innenleben eines Teams, sondern auch, wie es zu den Anforderungen an ein Projekt kommt und wie diese vorgelagerten Phasen effizient gestaltet werden können.

Nachdem ich Dir mit meinem Vorwort hoffentlich einen kleinen Einblick in den Praxisalltag gegeben habe, gebe ich Dir in der folgenden Lektion einen Überblick darüber, wie ich die Grundlagen für das Agile Projektmanagement vermitteln möchte. Also, bis gleich dann.

Kommentar verfassen