Projektmanagement classic – agil oder hybrid?

Zurzeit wird in Organisationen mächtig viel experimentiert mit der Arbeitsform des guten alten Projektmanagements.

Die Methodik des klassischen Projektmanagements, entwickelt für das Managen von Industrieprojekten in den 1980er Jahren, war schon immer etwas mächtig, wenn sie für kleinere, schlanke Projektsituationen eingesetzt werden sollte. Und spätestens bei der Frage, ob MS Project die adäquate Software für die Projektadministration sein könnte, gingen viele unserer Kunden in den Streik und zogen es vor, sich selbst schlanke Excel-Übersichten zu basteln. Unsere Kunden haben selbstbewusst das Kleingedruckte der DIN-Beregelung „Projektmanagement“ überlesen und die Methodik und die vielen Übersichts-Tools für sich passend gemacht.

Allen eingeleuchtet haben hingegen die Grundprinzipien guter Projektarbeit:

• Zuerst Ziele klären, dann loslegen
• Gemeinsam mit Projektteam und Projektleitung sich im Kick off-Workshop einen Überblick über Arbeitspakete und Zeitleisten zu schaffen (deren Gerüst dann auch als Grundlage für eine grobe Budgetkalkulation zu nutzen war)
• Ein regelmäßiges Fortschrittsmonitoring durch einen Vergleich der Soll-Planung mit dem Ist-Zustand und eine Reaktion auf das Gap durch die Projektsteuerung
• Für einige Problemdauerbrenner gab es allerdings keine zufriedenstellenden Lösungen:
  Wie kann für Innovationsprojekte, die Neuland betreten, schon vor dem Start ein smartes Ziel formuliert werden?
• Werden Umweltdynamiken, die die Sinnhaftigkeit der Projekte in Frage stellen, überhaupt wahrgenommen im abarbeitenden Projektteam?
• Warum müssen Teams Aufwand für Detailplanungen betreiben, deren Konkretisierung noch weit in der Zukunft – also in sehr viel späteren Projektphasen – liegen?
• Haben Lenkungsgruppen, die über wichtige Weichenstellungen im Projekt entscheiden, wirklich genug Chance, die Auswirkungstiefe ihrer Fließband-Entscheidungen in Meetingmarathons zu überblicken?

Agiles iteratives Projektmanagement

Inzwischen lassen sich die Organisationen von jungen, alternativen Arbeitsmethoden für die Projektarbeit inspirieren. Das agile Projektmanagement packt die Sache methodisch etwas anders an. Und es ist nur logisch, dass diese agilen Methoden sich aus der Disziplin der Softwareentwicklung entwickelt haben, also die Disziplin, auf die die Wertschöpfung im Zeitalter der Digitalisierung maßgeblich fußt.

Auch hier beobachten wir Geburtswehen bei den Experimenten unserer Kunden, die Methodologie auf ihre Wertschöpfungsprozesse zu adaptieren:

Ist eine orthodoxe SCRUM Methodik (zurzeit die Nummer 1 unter den agilen, iterativen Methoden) wirklich das Richtige für unsere Projektaufgabe?

Oder verirren wir uns in der Anstrengung, uns einzupassen in einer zwar iterative, aber hochstrukturierte Produktionslogik, die erfunden wurde, um technikverliebte Nerds kundenorientierter auszurichten und Programmiersolisten in Teamarbeit zu bringen?

Wir wollen Sie in diesem Newsletter wie immer ermutigen herauszufinden, welche Ansätze des Projektmanagements für Sie die richtigen sind und das Beste aus zwei Welten selbstbewusst zu kombinieren.

Wann nehme ich was?

Hier möchten wir Ihnen eine erste Unterscheidung anbieten, die wir aus dem immer bekannter werdenden Cynefin-Modell entwickelt haben.

In einem eher stabilen und bekannten Projektumfeld funktioniert klassisches Projektmanagement weiterhin sehr gut und sehr effizient. Ihr zu lösendes Problem ist bekannt, die Ziele für das Projekt können SMART formuliert werden, die zum Ziel führenden Aktivitäten können einfach geplant werden und die Ressourcenschätzung fällt leicht, weil sie Vorerfahrungen in der Organisation nutzen können. Dann haben Sie keine Scheu, auf das Bewährte zu vertrauen.

Immer mehr stehen wir aber vor Herausforderungen, wo uns weder das Projektumfeld bekannt ist, noch das zu lösende „Problem“ durchdrungen ist. Und somit ist es schwierig, ein konkretes Ziel für das Projekt zu formulieren. Auch für einzelne Projektphasen lassen sich kaum Ziele benennen.
Das Vorgehen des Projektteams in einem solchen Fall besteht aus iterativen (Lern-)Zyklen: es wird etwas entwickelt, getestet und aus dem Feedback gelernt. Die Erkenntnisse daraus finden dann direkt Berücksichtigung im nächsten Zyklus. Das Team stellt damit sicher, dass es sukzessive und mit einer hohen Geschwindigkeit neue Erkenntnisse gewinnt und Unsicherheiten reduziert, bis smarte Ziele definiert werden können. Wenn also häufige Änderungen zu erwarten sind oder diese sogar fürs Vorgehen wünschenswert sind, überwiegen mit hoher Wahrscheinlichkeit die Vorteile agiler Methoden und Techniken.

Während das traditionelle Projektmanagement also nach dem Motto funktioniert „Den Weg zum gesteckten und bekannten Ziel einschlagen und Kurs halten“, gilt im iterativen Grundverständnis des agilen Projektmanagements „Wege und Idee entstehen beim Gehen“.

Und wie ist das jetzt mit den Zielen und der Planung

Wir werden oft gefragt, ob das agile Projektmanagement tatsächlich ganz auf eine Projektvision / auf eine Zielbeschreibung verzichtet. Das ist natürlich Unsinn – beziehungsweise ein großes Missverständnis.

Menschen, die gemeinsam eine Aufgabe lösen sollen, haben hoffentlich immer das Bedürfnis, ihr Ziel zu kennen. Aber im iterativen Arbeiten darf das ruhig ein erst später zu spezifizierender Zielkorridor sein. Und das Projektziel wird nicht zwischen Auftraggeber und Projektleitung/Team verhandelt, sondern das Projektziel wird gemeinsam mit den NutzerInnen entwickelt. Hier helfen am Anfang die sogenannten Userstories, um zu spezifizieren, was das Projekt leisten soll.

Auf eine (zu frühe) SMART-Übung der Quantifizierung wird in der iterativen Arbeit tatsächlich verzichtet. Stattdessen wird nach dem Skizzieren des Zielkorridors „einfach angefangen“, ohne vorher festzulegen welche Teil-Ergebnisse wann und wie erreicht werden sollen. Für jede Etappe (Iteration genannt) wird aber ein fixer und sehr verbindlicher Ressourcen- und Zeitrahmen definiert.

Aber nur dieser „Sprint“ wird tatsächlich feingeplant und zum Teil täglicher, kurzer Projektabstimmungen (daily standup).

Nach jeder Etappe wird dies erreichte Zwischenergebnis mit den Erwartungen des Kunden oder Nutzers abgeglichen. Änderungen werden direkt in der nächsten Etappe mit aufgenommen. Das Team reagiert auf diese Weise wesentlich flexibler und schneller auf neue, möglicherweise richtungsweisende Erkenntnisse und Anforderungen. Anpassungserfordernisse werden frühzeitig erkannt und Risiken von (zu) späten aufwändigen Änderungen reduziert.

Erfolgsfaktoren agiler Projektarbeit

Hat es Sie neugierig gemacht, ebenfalls mit agilen Ansätzen zu experimentieren?

Innerhalb von Organisationen werden in der Projektarbeit häufig beide Herangehensweisen parallel gelebt. Da wird z.B. für bestimmte Projekttypen (oftmals IT-Projekte) die agile Methodik nach Scrum angewendet, wohingegen in anderen Projekten weiterhin klassisch gearbeitet wird.  Allerdings ist den internen Auftraggebern die grundlegend andersartige Haltung und Arbeitsweise häufig gar nicht bekannt. Insbesondere die andersartigen Rollen mit geteilter Verantwortung in der agilen Arbeitsweise sind noch ungewohnt. Product Owner erleben es zum Beispiel als Spannungsfeld, dass innerhalb des Teams eigenverantwortlich und selbstorganisiert gearbeitet wird, während sie von Auftraggeberseite wie ein klassischer Projektleiter mit Gesamtverantwortung gesehen und eingebunden werden.

Wir empfehlen, im ersten Schritt allen Akteuren in der Projektarbeit die Chance zu geben, diese Unterschiede kennenzulernen. Und wir finden es wichtig, die Beschreibung der Unterschiede nicht ausschließlich auf unterschiedliche Planungsprozesse und -tiefen zu beziehen, sondern auch hier eine eher ganzheitliche Perspektive auf gute Projektarbeit zu werfen.

Wir haben hier eines unserer zentralen Arbeitspapiere zum Projektmanagement überarbeitet, um Ihnen einen Vergleich der Ansätze auf einen Blick zu ermöglichen:

Lassen sich klassische und agile Methoden kombinieren?

Ja, natürlich!

In der nächsten Übersicht haben wir für Sie die wichtigsten klassischen und agilen PM-Techniken anhand eines klassischen Standard-Projektablaufs gegenübergestellt, um aufzuzeigen, welche Prinzipien und Techniken kombiniert werden können.

Projektvorbereitungsphase

Kontext- und Stakeholder-Analyse sind für beide Herangehensweisen gleichermaßen wichtige und hilfreiche Instrumente zur Klärung und Projektvorbereitung. Unabhängig von der PM-Methodik geht es hier darum, die Kräfte, die auf das Projekt wirken, besser zu verstehen und vorhandene sowie fehlende Informationen zu strukturieren. Anhand des Kontext-Modells werden die Voraussetzungen für die Projektarbeit analysiert, um überhaupt festzustellen zu können, welche Methodik (agil/klassisch) geeignet ist.

Im Kontext-Modell fragen wir nach Ziel/Nutzen/Ergebnis, vorhandenen/fehlenden Ressourcen, Grenzen/Restriktionen/Risiken sowie nach den wesentlichen Aktivitäten. Durch diese Klärung wird bereits deutlich, ob es sich eher um ein kompliziertes oder möglicherweise komplexes Projekt handelt. Durch genaue Stakeholder-Betrachtung erhalten wir die Einschätzung, ob und wie stark die beteiligten Anspruchsgruppen in das Projekt einbezogen werden sollten. Hat ein Projekt beispielsweise viele Stakeholder, bei denen sowohl das Interesse als auch der Einfluss auf das Ergebnis hoch sind, kann durch häufigere Feedbackschleifen intensive Einbindung organisiert werden. Und hier kann der direkte Kunden- und Nutzerkontakt, den die agile Arbeitsweise pflegt, gleich eingebunden werden.

Projektarbeit „cross-over“ und „hybrid“. Hier einige Beispiele:

• Die agilen Werte und Prinzipien auch im eher klassischen Projekt hinsichtlich ihrer Anwendbarkeit im eigenen Projektkontext im Team reflektieren
• Im Team bewusst mehr Eigenverantwortung und weniger Delegation leben.
• Ergänzend zum SMART-Ziel kann die Qualität oder Charakteristik des angestrebten Projektergebnisses als Produktvision, z.B. analog Jeffrey Moores Elevator Test, formuliert werden.
• Die Beschreibung der Arbeitspakete nutzerorientiert als User Stories inkl. Definition of Done formulieren.
• Häufiger Meilensteine für Feedback einplanen, bzw. systematisch zeitnahes (Kunden- oder Nutzer-) Feedback während der Erarbeitung des Projektergebnisses einplanen.
• Öfter mal Standup-Meetings abhalten und mit einem Task- bzw. Projekt-Board arbeiten.
• In den Statusmeetings auch hin und wieder Retrospektiven einbauen, um die Team-Zusammenarbeit zu reflektieren und zeitnah an Selbstverbesserung zu arbeiten.

Quellen: Thor Möller, www.pm-experten.de, Oestereich/Weiss: APM – Agiles PM: Erfolgreiches Timeboxing für IT-Projekte, S. Peipe: Crashkurs PM, J. Preußig: Agiles PM, Mayrshofer/Kröger: Prozesskompetenz in der Projektarbeit, www.proagile.de