Agiles Projektmanagement in der Prozessindustrie
„Nachdem wir das Ziel aus den Augen verloren hatten, verdoppelten wir unsere Anstrengungen“ – Dieses Gefühl kennen wohl fast alle Projektmanager. In Zeiten von veränderlichen Rahmenbedingungen und komplexen Projektumfeldern versuchen sie verzweifelt den Spagat zu schaffen zwischen zu Projektbeginn sinnvoll erscheinenden, mittlerweile aber schon veralteten Rahmenbedingungen hinsichtlich Qualität, Zeit und Kosten auf der einen Seite und einem den aktuellen Anforderungen entsprechenden Projektergebnis auf der anderen Seite.
Seit einiger Zeit gilt agiles Projektmanagement als Antwort auf diese Herausforderung. Das klassische Projektmanagement geht davon aus, zu Projektbeginn ein klares Ziel definieren zu können und dieses dann mittels detaillierter Planung in einem linearen Prozess zu erreichen. Agiles Projektmanagement hingegen sieht Zeit, Kosten UND das Projektergebnis als variable Größen an, die im Laufe des Projekts mit Hilfe eines iterativen Prozesses immer mehr eingegrenzt werden.
Agiles Projektmanagement ist zum Industriestandard in der IT-Branche geworden und auch viele Projekte in der Prozessindustrie können unserer Erfahrung nach von agilem Projektmanagement profitieren. Jedoch ist agiles Projektmanagement nicht der Allheilsbringer, als der es häufig dargestellt wird. Zum einen gibt es durchaus Projektarten, die mit klassischem Projektmanagement hervorragend abgewickelt werden können. In diesen Fällen – als Beispiel sein hier die meisten Bauprojekte genannt – gibt es keinen Grund das Projektmanagement umzustellen: If it ain’t broke, don’t fix it. Zum anderen geht die Tragweite der Einführung von agilem Projektmanagement weit über eine simple Änderung des Projektmanagementwerkzeugs hinaus. Hinter den agilen Prinzipien stehen einige geradezu weltanschauliche Grundannahmen.
Vor einer Implementierung sollten die folgenden Grundannahmen in der Organisation diskutiert und aktiv bejaht werden, damit agiles Projektmanagement sein volles Potenzial entfalten kann:
- Mitarbeiter wollen von sich aus gute Arbeit leisten und sind motiviert, wenn man ihnen Freiheiten lässt, Verantwortung für ihre Arbeit überträgt und sie fordert. Dies findet sich im agilen Projektmanagement in der Arbeit in autonomen, selbstbestimmten Teams wieder, die ihre Arbeit im Laufe eines Sprints eigenständig organisieren, Entscheidungen treffen und Probleme lösen. Neben den Anforderungen an die einzelnen Teammitglieder sind hier auch die Führungskräfte gefordert, dem Team zu vertrauen und ihm Raum zum Arbeiten zu geben. Micro-Management ist mit Agil nicht zu vereinbaren.
- Die primäre Aufgabe des Managements ist es nicht den Mitarbeitern im Detail zu sagen, was sie zu tun haben und dies dann zu kontrollieren, sondern die Bedingungen zu schaffen, damit sie gute Arbeit leisten können. Ein gut funktionierendes agiles Projektteam benötigt das Management vor allem dazu Hindernisse (Impediments) zu beseitigen, die nicht innerhalb des Teams gelöst werden können.
- Es ist normal, dass das gewünschte Ergebnis zu Projektbeginn noch nicht genau definiert werden kann. Änderungen sind daher keinesfalls als Ärgernisse anzusehen, die mit besserer Planung oder durch kompetentere Mitarbeiter hätten verhindert werden können. Im Gegenteil, eine kontinuierliche Aufnahme neuer Anforderungen bzw. die Anpassung bestehender Anforderungen sind im Kern des agilen Vorgehens fest verankert und stellen sicher, dass das Ergebnis maximalen Mehrwert für den Kunden bringt.
- Fehler, Missverständnisse und falsche Entscheidungen passieren. Wichtig ist diese möglichst schnell zu erkennen, zu korrigieren und aus ihnen zu lernen. Das iterative Vorgehen unterstützt dabei, Fehlentwicklungen frühzeitig sichtbar zu machen. Gleichzeitig ist eine Atmosphäre der Offenheit und des Vertrauens essenziell, in der alle Beteiligten auch schwierige Situationen diskutieren können, ohne in die Defensive oder unter Rechtfertigungsdruck zu geraten. Bei der Nutzung von Scrum ist es primäre Aufgabe des Scrum Masters diese Atmosphäre herzustellen. Jedoch wird auch der beste Scrum Master an dieser Aufgabe scheitern, wenn er keine Rückendeckung durch das Management erfährt.
Darüber hinaus ergeben sich einige Herausforderungen beim Transfer von der Softwareentwicklung auf die Prozessindustrie und deren Fragestellungen.
In einem klassischen Großkonzern ist der Clash zwischen einer hierarchischen und arbeitsteiligen Linienorganisation und agilen Projektteams vorprogrammiert.
- Klassische Hierarchien bieten Sicherheit für die Mitarbeiter: Mitarbeiter, die sich wegen dieser Sicherheit bewusst für die Arbeit in einem Konzern entschieden haben oder sich im Laufe der Zeit an diese Sicherheit gewöhnt haben, fühlen sich von der eigenverantwortlichen Arbeit überfordert oder scheuen die Verantwortung.
- Die Anforderungen an das Management / die Hierarchie verändern sich: Genauso wie die Mitarbeiter können auch Manager von den neuen Anforderungen überfordert sein oder ihre neue Rolle als Verlust von Macht und Status wahrnehmen.
- Ein komplett autarkes Projektteam ist schwer zu realisieren, Schnittstellen zu Spezialeinheiten bleiben bestehen (Fachstellen, Bau, Analytik, etc.): Die Zusammenarbeit über diese Schnittstellen hinweg ist eine beständige Herausforderung sowohl für das agile Projektteam als auch für die Spezialeinheiten. Die Steuerung dieser Schnittstellen wird zu einer regelmäßigen Aufgabe für das Management.
- Einen geeigneten Product Owner zu finden ist erfolgskritisch und schwierig: Der Endkunde ist oft sehr weit vom Projektteam weg (arbeitsteilige Organisation, B2B, …). Personen innerhalb der Organisation, die die Anforderungen an den Product Owner erfüllen können, befinden sich in der Hierarchie oft so weit oben, dass es ihnen zeitlich nicht möglich ist die Rolle auszufüllen.
Die entscheidende Herausforderung bei der Implementierung von agilen Ansätzen ist es daher immer die Anschlussfähigkeit des agilen Setups an die Gegebenheiten des Großkonzerns sicherzustellen.
Ein Erfolgsfaktor hierzu liegt darin nicht zu versuchen die perfekte Welt aus der Lehre eines agilen Gurus eins-zu-eins zu übertragen, sondern die agilen Methoden anzupassen – wenn es sein muss auch radikal. Diese Anpassung ist nicht trivial, denn sie muss sich immer an den Bedürfnissen und Herausforderungen des Projekts orientieren, ohne sich den Bequemlichkeiten der bestehenden Organisation und Konzernkultur zu unterwerfen. Diese Anpassungsleistung erfordert einerseits ein gutes Verständnis der Grundidee des agilen Arbeitens, das über die Kenntnis einzelner Werkzeuge hinaus geht und andererseits den Abschied von der Vorstellung, dass das agile Setup jemals „fertig“ ist. Genau wie die Arbeit am Projektziel ist auch das Aufsetzen eines agilen Arbeitsmodus ein iterativer Prozess, der auf Änderungen in den Anforderungen und Rahmenbedingungen konstruktiv reagiert.
Somit ist die Einführung von agilem Projektmanagement ein Change Projekt, das in Aufwand und Komplexität über die Schulung eines neuen Tools hinaus geht.