Die Grauzone zwischen klassischem und agilem Projektmanagement

Ist es an der Zeit, das klassische Projektmanagement ad acta zu legen? Nein, sicherlich nicht. Mit klassischem Projektmanagement wurden und werden unzählige große Projekte sicher zum Erfolg geführt. Auch im klassischen Projektmanagement bzw. in der Projektsteuerung gibt es den Plan-Do-Check-Act-Zyklus sowie ein eindeutiges und motivierendes, klares Projektziel. Auch dort gibt es Selbstorganisation. Und verschiedene Terminplanebenen, von grob bis fein.Was aber auch zum klassischen Projektmanagement gehört, ist das teils grenzwertige Anspruchsdenken der Akteure. Manch ein Auftraggeber äußert seinen Unmut in etwa folgendermaßen: „Es ist doch alles ganz genau geplant. Warum gibt es jetzt eine Abweichung vom Plan? Klarer Fall: Da hat jemand versagt. Diese ständigen Terminverschiebungen – das kann doch nicht sein. Dabei wissen wir doch genau, was wir wollen ...“

Klare Projektvoraussetzungen entpuppen sich oft als Illusion

In der Realität wird von manch einem Auftraggeber nicht anerkannt, dass der Scope bei vielen klassisch gemanagten Projekten längst nicht so klar ist wie erhofft bzw. gegenüber den Stakeholdern dargestellt. In so einem Fall bleibt vielfach nichts Anderes übrig, als den Scope über ein iteratives Vorgehen im vollen Galopp zu klären. So eine Situation bringt die Projektleitung schnell in Erklärungsnot. Wie soll man das der Abteilungsleitung erklären und wie soll diese wiederum der Bereichsleitung Rede und Antwort stehen? Schließlich wurde die Budgetplanung für die nächsten drei Jahre vom Ausschuss genehmigt und diese stimmt schon jetzt nicht mehr.Genau darin liegt die Krux: Auf der einen Seite erfordern Entscheidungsprozesse in vielen Unternehmen oder Behörden eine detaillierte Budget- und Mittelabflussplanung für die nächsten Jahre – am besten auf den Cent genau. Auf der anderen Seite wird jedoch nicht anerkannt, dass viele Projektverläufe gar nicht so sicher planbar sind, weil etwa fachliches oder technisches Neuland betreten wird oder eine komplexe oder zumindest komplizierte Herausforderung zu bewältigen ist.

Ein Projektleiter muss immer auch Erwartungsmanager sein

Wenn es der Projektleiter in so einer Situation schafft, allen Beteiligten immer wieder klarzumachen, dass es Änderungen im Projektverlauf gibt und weiterhin geben wird, dass diese normal sowie unvermeidbar sind und damit bewusst umgegangen werden muss, dann kann das klassisch gemanagte Projekt zum Erfolg werden. Dabei stehen dem Projektleiter eine ganze Bandbreite im klassischen Projektmanagement bewährter Techniken zur Verfügung, wie z. B. Zielmanagement, Änderungsmanagement, Erwartungsmanagement, Krisenmanagement oder ein Taskforce-Modus. Oft reichen diese Methoden aber nicht mehr aus – hier kann es sinnvoll sein, auf agile Methoden zurückzugreifen.

Der Wechsel von Klassisch zu Agil

Idealerweise gelingt es einem Projektleiter, der sich im Rahmen einer agilen Transition in der Rolle des ScrumMasters oder Product Owners wiederfindet, eine zeitraubende Methodendiskussion zu umgehen und stattdessen in kleinen Schritten bewährte Elemente aus der agilen Toolbox auf das Projekt zu übertragen. Entscheidend ist, ein agiles Framework nicht blind überzustülpen, sondern sich des „Warums“ bewusst zu sein und mit Augenmaß vorzugehen. Bei Bedarf mag es helfen, Anpassungen am „Standard-Scrum“ vorzunehmen und sinnvolle Abweichungen von der „Standard-Methode“ zuzulassen, wenn sie dem Projekt dienlich sind. Denn Agile heißt noch nicht automatisch besser.So sind beispielsweise das Reflektieren und der Plan-Do-Check-Act-Zyklus auch im klassischen Projektmanagement bestens bekannt, allerdings fehlt häufig eine Kultur der regelmäßigen und systematischen Reflexion, etwa durch Retrospektiven. Im klassischen Projektmanagement finden Reflexionen, z. B. in Form von Lessons Learned, viel zu selten und oft erst nach Projektende statt. Für manch einen erfahrenen Projektleiter mag jedoch das Reflektieren eine Selbstverständlichkeit sein, noch während das Projekt läuft, sodass der Methodenwechsel von Klassisch auf Agil fließend gestaltet werden kann.

Augenmaß hilft bei der Einführung einer neuen Methode wie Scrum

Im Gegensatz zur Einführung agiler Methoden mit Augenmaß machen viele Unternehmen jedoch etwas Anderes: Sie führen Scrum pauschal auf der Teamebene ein. Dadurch kann eine unkoordinierte und erklärungsbedürftige Kluft zwischen der Realität in Projekt und Organisation auf der einen Seite und dem Idealbild von Scrum aus dem Lehrbuch auf der anderen Seite auftreten. Es gibt für die Implementierung agiler Methoden kein einfaches Schwarz-Weiß-Schema.Die Kunst liegt im Herausarbeiten der richtigen Grauschattierung – je nach Projektsituation und momentaner Verfassung der beteiligten Personen. Dazu gehört der Mut der Projektbeteiligten, den Fokus weiterhin auf die Erreichung der Projektziele und das Liefern von Ergebnissen zu richten und sich nicht in einer neuen Methode zu verlieren. Leider stehen in Unternehmen nicht immer erfahrene Projektleiter bereit, die dabei helfen, die Schmerzen der Einführung einer neuen Methode zu mildern.

Müssen Sprints dabei immer kurz sein?

Üblicherweise wird agiles Arbeiten mit kurzen Sprintzyklen verbunden, d. h. innerhalb von ein bis vier Wochen Sprintdauer wird ein Produktinkrement erstellt, anschließend Feedback dazu eingeholt und auf Basis der neuen Informationen entschieden, wie es weitergeht. In großen und z. B. technisch aufwendigen Projekten können vier Wochen bei Weitem nicht ausreichen, um ein testbares Produktinkrement zu liefern. In solchen Projekten kann ein Entwicklungszyklus mehrere Monate dauern. Bedeutet das, dass ein agiles Vorgehen in der Projektbearbeitung für solche großen bzw. aufwendigen Projekte nicht funktioniert? Müssen wir uns nicht auch im Agilen von einer falschen Vorstellung lösen?Agil ist nicht immer nur Scrum. Auch große bzw. technisch anspruchsvolle Projekte können mit agilem Mindset durchgeführt werden. Was spricht denn gegen einen 15-Monats-Sprint? Solange die Beteiligten wissen, dass es ein Sprint ist und nach oder sogar während des Sprints auf das (Zwischen)-Ergebnis und den Prozess geschaut wird und alle Beteiligten bereit sind, den Kurs zu korrigieren, sind die Anforderungen an agiles Vorgehen wunderbar erfüllt. Die Länge eines Sprints ist letztlich Definitionssache und muss zum Projekt bzw. Produkt passen.

Bei der agilen Projektbearbeitung sind Erwartungs- und Zielmanagement inkludiert

Wenn eine agile Vorgehensweise im Projekt vereinbart wird, dann müssen sich die Stakeholder auch darauf einlassen, dass der Scope nicht vollständig klar und im Detail fixiert ist. Es wird anerkannt, dass zu einem fixen Zeitpunkt nicht auch gleichzeitig ein vorher fixiertes Ziel erreicht werden wird. Stattdessen verständigen sich die Stakeholder auf eine Vision als Grundlage der Projektbearbeitung. Entlang dieser Vision wird in Teilschritten vorgegangen, es werden Minimum Viable Products (MVPs) und Zwischenlieferungen vereinbart. Es gibt zwar durchaus eine Planung für den zukünftigen Projektverlauf, jedoch entspricht dieser eher einer Prognose für eines von vielen möglichen Szenarien. Eine Roadmap, gerne auch über mehrere Jahre, hilft in der Kommunikation mit den Stakeholdern. Der Fokus liegt jedoch nicht auf dem Plan für die Zukunft, sondern auf den konkreten Arbeitsergebnissen der nächsten Meilensteine.Beim agilen Arbeiten erfolgt das Zielmanagement durch regelmäßige Kommunikation, z. B. in Form von Feedback. Das heißt, es wird immer wieder über die Ziele verhandelt. Und Verhandlungen können unbequem sein, sie können dauern. Aber sie sind unerlässlich, um am Ende Einigkeit in Bezug auf die Erreichung der Vision und eine klare Richtung für alle Projektbeteiligten zu gewinnen.

Bei langandauernden, bedeutenden Projekten ist häufig ganz automatisch das Top-Management involviert.

Bei großen Projekten kann durch die Management-Attention etwas gelingen, was im Zusammenhang mit weniger bedeutenden Projekten aufgrund fehlender Aufmerksamkeit von „oben“ nicht gelingt: Es entsteht echte Business Agilität, die weit über die Agilität des operativen Projektteams hinausgeht. Die strategische Ebene und die operative Ebene tauschen sich über den weiteren Kurs aus – die Geschäftsleitung bzw. Bereichsleitung geht mit der Programm- bzw. Projektleitung in den Dialog und gemeinsam klären sie die Ziele für den nächsten Quartals- oder Jahres-Sprint.

Business-Agilität braucht Koordination zwischen strategischer und operativer Ebene

In der „neuen“ agilen Welt wird die Verzahnung über alle Unternehmensebenen hinweg dringend benötigt, damit die agilen operativen Teams nicht von der strategischen Ebene abgekoppelt werden. Elemente, die eher dem klassischen Projektmanagement zugeordnet werden, wie Meilensteinplanungen, Budgetplanungen und Projektzielvereinbarungen, sind für die Stakeholder-Kommunikation unabdingbar – nur so werden die Entscheider-Ebene und das Top-Management abgeholt. Es geht um Kommunikation, wobei Projektleitung bzw. Scrum-Team stets vermitteln müssen, dass Planungen als Kommunikationshilfen und Prognosen zu verstehen sind, die Zukunft jedoch selten exakt planbar ist und außerdem von zukünftigen Entscheidungen abhängt.

Die Realität in vielen Unternehmen hat längst gezeigt: Es geht sowieso nur klassisch UND agil.

Lassen Sie sich nicht festlegen, ob ihr Projekt klassisch oder agil geführt wird. Wie oben beschrieben, gibt es nicht das Modell für Agilität, das man 1:1 umsetzen sollte. In der Realität muss man immer auf das Projekt bzw. das Produkt und das Unternehmen schauen und ein Vorgehen wählen und zusammenstellen, das tatsächlich passt. Ziel muss immer sein, eine praxistaugliche individuelle Lösung zu erarbeiten. Hierbei ist die Erfahrung ihrer besten Projektmanager eine äußerst wertvolle Basis, der Blick von außen, etwa durch Consultants, vervollständigt die Perspektive. Wir unterstützen Sie gerne, den richtigen Methodenmix für ihr Projekt, Produkt und Unternehmen zu erarbeiten.