Wie klassisches Projektmanagement und Agilität mit der Unvorhersehbarkeit zukünftiger Umstände umgehen

Als Berater, der methodisch und in seiner Haltung der agilen Hemisphäre zuzuordnen ist, habe ich schon oft die Dichotomie zwischen klassischem Projektmanagement und Agile argumentiert und noch öfter genau dieser zugehört.
Eine oft gehörte Variante bezieht sich auf die Unvorhersehbarkeit zukünftiger Umstände und Entwicklungen. Das zentrale Schaubild ist hier die Stacey-Matrix: Gerne wird in dem Feld zwischen „trivial“ und „chaotisch“ im Bereich des Komplexen die Agilität verortet. Damit wird Agilität sofort zur Antwort auf Komplexität, Unvorhersehbarkeit und Unplanbarkeit gestempelt. Als Gegenbild dient dann meist das klassische Duo aus Wasserfallmethodik und Projektmanagement, das an der Komplexität scheitern muss, weil es auf Planbarkeit setzt.
Beim Lesen des Buchs eines befreundeten Autors und Universitätsprofessors über „Therapeutisches Chaos“ hat mich ein Gedanke besucht: „Auf diese Weise wird der Theorie und Welt des klassischen Projektmanagements unterstellt, sie würde Komplexität und Unplanbarkeit per se weder verstehen noch für die eigene Modellierung zur Kenntnis nehmen oder berücksichtigen.“ Dass es in der Praxis durchaus zu oft so vorkommt, ist damit nicht ausgeschlossen.
An dieser Stelle möchte ich für einen Agilisten allerdings etwas ziemlich Unpopuläres machen: Ich unterstelle bewusst, dass sich klassische Ansätze des Projektmanagements sehr wohl im Kontext von Komplexität bewegen und sich mit Inhalten und Umwelten auseinandersetzen, die man schwer bis gar nicht deterministisch behandeln kann. Sie sind sich dieses Umstandes gewahr und gehen bewusst damit um.

Klassisch vs. agil – der Unterschied im Wie

Der große Unterschied zwischen klassischem Projektmanagement und Agilität liegt im „Wie“, und das ganz deutlich.

Ist also im klassischen Projektmanagement die Abweichung per se eine Krise, wird sie im agilen Kontext per se als Chance behandelt.
Formulieren wir die beiden Begriffe einmal im Sinne ihrer Funktion um, um sie einander gegenüberzustellen:

Warum kann es wichtig sein, den Unterschied zwischen diesen beiden Ansätzen sorgsam zu betrachten?
Zu allererst ist das wichtig, wenn wir uns mit Veränderungen beschäftigen – als Change Manager, Agile Coaches oder Berater, die beim Umbau von Unternehmen mitwirken bzw. diese verantworten. Wir verantworten das Bild der Veränderung „VON – ZU“. Und dabei sind wir gut beraten, bei den richtigen, damit auch relevanten, weil wirksamen Inhalten und Umständen anzusetzen. Einen Schritt weitergedacht, ließe sich also ein Change, noch besser eine Transformation „vom Projektmanagement hin zu Agile“ reframen in „von der korrektiven Organisation hin zur lernenden Organisation“.

Foto: CC0 Creative Commons, pixabay – Septimiu88

Collaboration Hacks for Distributed Teams

Last month I have been invited to join an event for the PMA young crew organization in Austria, an organization that has the aim to foster project management knowledge for young professionals. The organizer asked if I do have experiences with distributed teams and if I can share them with interested young professionals from all over Europe. Therefore, I prepared a workshop to elaborate on success factors for distributed teams, no matter if they are distributed around the world or in the same city sitting in different offices. Although I’m primarily working with agile teams, the experiences shared could be used for any work setting. This is also the reason I named the workshop “Agile flavored Collaboration Hacks for Distributed Teams”.
In my opinion, there are two major categories of enablers for high performing distributed teams:

From my perspective the most important success factor is that the project leader can decide autonomously on how to structure the process of collaborating and which tools are used. If everything is predefined and there is no freedom in adapting to challenges, chances are pretty low that the team will fully unleash its potential. Therefore, be self-confident and define your space of autonomy with your sponsors so that you can decide on important adaptions improving your team performance!
You can find more experiences in my slide deck:
Agile Flavoured Collaboration Hacks for Distributed Teams

Foto: CC0 Creative Commons, pixabay -Free-Photos

Agiles Projektportfoliomanagement

 
Agiles Projektportfoliomanagement ist ein besonderes Thema: Auch wenn es mittlerweile viele Bücher gibt, die dieses Thema betrachten, beschränken sich viele dieser Bücher auf große Frameworks und weniger auf die dahinterliegenden Prinzipien und Werte. Diese Prinzipien liefern vielleicht weniger konkrete Antworten auf die spezielle Herausforderung, die im eigenen Unternehmen anzutreffen ist, jedoch sind sie meines Erachtens notwendig, um den Themenkomplex wirklich zu verstehen.

Doch was versteckt sich hinter diesen Prinzipien?

Ganz viel aus dem Lean Management, vor allem aus den Themenbereichen der Engpasstheorien und Kanban. Im Rahmen der Projektmanagement-Konferenz Happy Projects 2017 in Wien habe ich einen Workshop zum agilen Portfoliomanagement gehalten, der auch aufgezeichnet wurde. Diesen Mitschnitt möchte ich mit euch teilen!
 

 
PS Ein tolles weiterführendes Buch, das ich empfehlen kann, ist “Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects”.

Scrum & Stage-Gate-Prozess kombiniert

 
Im Rahmen einer Veranstaltung der Plattform für Innovationsmanagement Österreich hatte ich die Gelegenheit, vor einer Reihe interessierter Innovationsmanager einen Vortrag zum Thema “Neue Innovationsprozess-Modelle – hat Stagegate ausgedient?” zu geben. Bereits als ich für einen Beitrag angesprochen wurde, hatte ich großes Interesse, das Thema Stage Gate in Bezug zu Scrum aufzuarbeiten.
Ich denke, dass der Stage-Gate-Prozess weiterhin seine Berechtigung hat. Es ist definitiv sinnvoll, sich in kontinuierlichen Abständen bzw. zu bestimmten Zeitpunkten mit der Produktentwicklung auseinanderzusetzen und zu entscheiden, ob ein weiteres Investment sinnvoll ist. Was ich jedoch proklamiere ist, dass diese einzelnen Phasen nicht dem wasserfallartigen Gedanken von Konzept, Design und Umsetzung entsprechen, sondern dass jede einzelne Phase ein Produkt als Ergebnis hat. Während die erste Phase einen Prototyp zum Ergebnis hat, hat eine dritte Phase möglicherweise bereits ein Minimum Product für den Markt im Visier.
 
image_stage-gate-prozess
 
Meine Vision ist, dass sich Unternehmen mehr wie Venture Capitalists verhalten und Innovationsprojekte als Start-ups behandeln. Das bedeutet, dass in diese – je nach Marktreife – schrittweise mehr Kapital investiert wird. Sollte man zur Erkenntnis kommen, dass die Idee nicht profitabel genug sein wird, kann man entweder mit Hilfe des Lean Startup Gedankens das Geschäftsmodell weiterentwickeln bzw. neu ausrichten oder das Experiment beenden.
 
Hier gehts zum ganzen Vortrag zum Thema “Neue Innovationsprozess-Modelle – hat Stagegate ausgedient?”
 

Die 7 Erfolgsfaktoren für Digital Labs

 
Die Digitalisierung hat inzwischen selbst die konservativsten Branchen erfasst. Heute lautet die Frage nicht mehr, ob es Veränderungen geben wird, sondern wie stark diese Veränderungen sein werden. Wer unter den Gewinnern der Digitalisierung sein will, muss handeln – aber wie packt man es am besten an?
 
Ein erfolgreicher Weg ist die Bündelung digitaler Initiativen in eigenen, von der Mutterorganisation weitgehend unabhängigen Einheiten. Ob man sie nun Digital Labs, Digital Hubs oder Digital Campus nennt – sie alle verfolgen dasselbe Ziel: Sie sollen das Unternehmen fit für den digitalen Wandel machen. Doch der Wandel beginnt ganz oben: Topmanagement und Führungskräfte müssen die Mission dieser digitalen Sondierungseinheiten festlegen und dafür sorgen, dass sie erfolgreich sein können. Die größte Gefahr am Beginn solcher Initiativen ist, dass die Motivation nur kurz anhält, wenn sie nicht immer wieder befeuert wird. Zu diesem Feuer gehören eine begeisternde Vision einerseits und die richtigen Rahmenbedingungen andererseits, um den Boden zu bereiten, auf dem erste Erfolge erzielt werden können. Daraus nährt sich in weiterer Folge das Wachstum der Initiative.
 

Wozu überhaupt ein Digital Lab?

Die Verantwortlichen in vielen Unternehmen fragen sich, ob eine eigene Einheit für digitale Initiativen überhaupt nötig ist. Könnten solche Vorhaben nicht auch mit klassischen Matrix-Strukturen abgewickelt werden, also in Programmen und Projekten?
Vor allem in der Arbeit mit großen Unternehmen sehen wir im klassischen Projekt-Setup immer wieder ein Kernproblem:
“Die Time-to-market der Ergebnisse ist schlechtweg zu lange.”
Natürlich gibt es dafür viele Ursachen, doch drei wesentliche begegnen uns besonders oft.Diese drei Ursachen hängen durchaus voneinander ab und erzeugen im Wechselspiel eine Abwärtsspirale, die den Eintritt am Markt immer weiter nach hinten schiebt: fehlender Fokus, fehlende Leidenschaft, aber dafür eine umso striktere Governance.

1. Der Fokus ist nicht stark genug

Eine bekannte Situation: Mitarbeiter werden – basierend auf ihrem Wissen – nicht nur einem, sondern gleich mehreren Projekten zugeteilt. Das Tagesgeschäft soll noch nebenbei erledigt werden. Es ist Taskswitching auf höchster Ebene: Alles wird gemacht, aber nichts mit der vollen Aufmerksamkeit. In dieser Zerrissenheit kommen die einzelnen Projekte zu kurz – oft fehlt die richtige Expertise zur richtigen Zeit. Das Gesamtvorhaben verzögert sich unweigerlich.

2. Die Leidenschaft fehlt

Innovative, moderne Produkte entstehen immer aus einer Leidenschaft. Genau diese Leidenschaft ist in den meisten Unternehmen im Laufe der Jahre verloren gegangen. Nur wenige Mitarbeiter brennen für die Vorhaben, zu denen sie gerade verpflichtet wurden. Es gibt keine überzeugende Vision oder sie verschwindet irgendwann in den Schubladen. Wenn die Begeisterung fehlt, verschwinden auch der Enthusiasmus und die Energie der Mitarbeiter. Sie werden langsamer und damit verzögert sich auch das Projekt.

3. Die Governance ist zu strikt und zu langsam

Umfassende Status-Reportings, unzählige Gremien und viele Eskalationsebenen – das ist die rigide Governance-Realität in vielen Unternehmen, vor allem in Großkonzernen. Wer hier schnelle Entscheidungen erwartet, wartet lange: Entscheidungen tröpfeln nur langsam wieder nach unten. Und wieder dehnt sich die Projektdurchlaufzeit aus.
Weil die alten Strukturen zu behäbig sind, sehen viele Unternehmen in der Gründung eines Digital Labs die Antwort. Die Hoffnungen, die in diese Initiativen gesetzt werden, sind groß, die Erwartungen enorm: “Sobald wir ein Digital Lab haben, werden Innovationen am laufenden Band produziert.” Doch wie stellt das Management sicher, dass diese Unternehmungen tatsächlich erfolgreich werden? Neben allen Chancen birgt das Unterfangen naturgemäß auch Risiken: Teuer produzierte, aber unprofitable Spielereien gehören genauso zu den Fallstricken wie das Entstehen einer kompletten Parallelorganisation, deren Ergebnisse nicht mehr in das Mutterunternehmen integriert werden können.
 
Sollten Sie gerade überlegen, für Ihre Digitalisierungsinitiative ein Digital Lab zu gründen, empfehlen wir Ihnen, sich im Vorfeld Gedanken zu sieben Faktoren zu machen, die für den Erfolg entscheidend sind.
 

Die 7 Erfolgsfaktoren für Digital Labs

Wir unterstützen Unternehmen in diversen Branchen beim Aufbau von Digital Labs. Dabei sehen wir immer wieder, dass es für das Gelingen auf das richtige Zusammenspiel von Struktur, Führung und Skills ankommt. Diese drei Bereiche lassen sich noch genauer in 7 Erfolgsfaktoren unterteilen:

  1. Optimale Rahmenbedingungen
  2. Modernes Führungsverständnis
  3. Geeignete Mitarbeiter
  4. Absolute Kundenzentrierung
  5. Schlanke Governance
  6. Zusammenarbeit mit externen Partnern
  7. Transformation in die Gesamtorganisation

Lesen hier das ganze Whitepaper “Die 7 Erfolgsfaktoren für Digital Labs”.
 

Erfolgreiche agile Projekte jenseits von Anarchie und Kontrollwahn

Am 8. Juni 2016 hatte ich die Gelegenheit, auf dem 7. PM Symposium in Wien einen Vortrag über agile Projekte zu halten. Das Thema der Veranstaltung lautete „Projektcontrolling, Risiko- und Claimmanagement zwischen Anarchie und Kontrollwahn“. Aus meiner Perspektive, der des agilen Projektmanagements, wurde mir schnell klar, dass ich agile Methoden als gute Balance zwischen diesen beiden Extremen vorstellen kann – vorausgesetzt, die Methodik wird diszipliniert eingesetzt.
Warum werden Agilität und Scrum oft mit Chaos oder Anarchie verbunden? Ich denke, es liegt leider tatsächlich an den vielen Organisationen, die agile Methoden eingeführt haben, aber dessen Werte und Prinzipien in der täglichen Arbeit nicht leben und sich mit einer Vielzahl von Kompromissen zufrieden geben. Agile Methoden bieten sehr wohl geeignete Ansätze, um Aufgaben des Controllings und Risikomanagements wahrzunehmen. Beim Claimmanagement drängt sich die Frage auf, ob es in seiner PM-Definition so überhaupt noch Anwendung finden kann. Aber alles der Reihe nach.

Das Projektcontrolling

In agilen Projekten plädiere ich gerne dafür, das magische Projektmanagement-Dreieck auf den Kopf zu stellen. Ausgehend von einem fixen Termin und einem fixen Budget soll mit Hilfe eines variablen Scopes das optimale Ergebnis zu den fixierten Randbedingungen erzielt werden. Mit Hilfe kurzer Iterationen können wir regelmäßig die gelieferten Ergebnisse begutachten und Feedback geben. Das Management kann so als Venture Capitalist agieren und wie in einem Stage-Gate-Prozess schrittweise mehr Geld für die Investition freigeben oder das Vorhaben „killen“. Eigentlich logisch und plausibel. In der freien Marktwirtschaft passiert das genau so!
Wichtig ist auch, das Richtige zu messen, nämlich den Nutzen oder die Zufriedenheit mit dem Ergebnis. Die Standish Group stellt im aktuellen CHAOS Report einmal mehr fest, dass auch die Einhaltung aller Ecken des PM-Dreiecks (Budget, Zeit und Scope) den Kunden nicht automatisch zufrieden stellt. Stattdessen sollten die Features priorisiert nach Kundennutzen oder Business Value kontinuierlich entwickelt werden, bis man nüchtern feststellen kann, dass sich jede weitere Investition nicht mehr lohnen würde, da es sich nur mehr um Add-ons handelt, die selten benötigt werden. Man schließt das Projekt ab und widmet sich dem nächsten Vorhaben.
Der klassische Ansatz der agilen Releaseplanung arbeitet mit Hilfe eines Worst und Best Case Szenarios für die Velocity des oder der Teams. Anhand dieser Szenarien kann der Liefertermin für eine definierte Anzahl an User Story Points prognostiziert werden. Das erlaubt dem Product Owner eine rechtzeitige Einschätzung, ob das gesetzte Ziel erreicht werden kann. Eine weitere Variante der agilen Releaseplanung orientiert sich an der durchschnittlichen Lead Time von User Stories. Der Vorteil dieses Modells ist das Controlling der Durchsätze und der Lieferzeiten, um so dem Kunden genaue Aussagen über den Liefertermin bei Einmeldung der Anforderung zusagen zu können. Wichtigster Bestandteil für diese Steuerung ist die Begrenzung des Product Backlogs auf eine fixe Anzahl an Items (idealerweise <= 50). Anschließend wird für jede Anforderung, sobald sie in diesem sogenannten Committed Backlog landet, mit einem „Entry Date“ versehen. Nach Fertigstellung durch das Team erhält die Anforderung ein „Delivery Date“. Über eine größere Menge an User Stories kann so herausgefunden werden, was die durchschnittliche und die maximale Lead Time des Teams ist. Wird eine neue Anforderung vom Kunden nun aufgenommen, kann mit diesen Werten eine gute Einschätzung gegeben werden.

Das Risikomanagement

Meines Erachtens ist das Risikomanagement dem agilen Prozess inhärent. Durch die regelmäßige Lieferung von Ergebnissen kann ein katastrophales Projektergebnis de facto ausgeschlossen werden, parallel dazu reduziert sich das Risiko, vollkommen an der Zufriedenheit des Kunden vorbei zu arbeiten. Durch eine kleine Timebox wird das Team außerdem zum kreativen Umgang mit Risiken gezwungen, denn es ist nicht möglich, große Konzepte innerhalb von zwei Wochen zu erstellen. Stattdessen geht es darum, schnell Prototypen oder Proof of Concepts zu entwickeln, um zu beweisen, dass das Versprochene tatsächlich möglich ist. Und zu guter Letzt gibt es natürlich den ScrumMaster, eine Rolle in Scrum, die sich gänzlich der Produktivität des Teams verschrieben hat. Eine seiner wesentlichen Aufgaben ist das Führen und Pflegen eines öffentlichen Impediment-Backlogs, das alle Hindernisse des Teams und etwaige Risiken transparent für alle sichtbar darstellt.

Das Claimmangement

Bei Betrachtung des agilen Manifests wird schnell klar: Es geht um eine vertrauensvolle Zusammenarbeit mit dem Kunden und nicht um das Pochen auf Verträge. Im Claimmanagement wird häufig davon gesprochen, vereinbarte Bereitstellungen des Kunden einzufordern. Kurz und knapp könnten wir in agilen Projekten sagen, dass der Haupt-Claim die Mitwirkung des Kunden im Entwicklungsprozess ist. Es geht darum, den Kunden so in den Prozess zu integrieren, dass er kontinuierlich Feedback gibt und Verantwortung bei der Priorisierung der nächsten Anforderungen übernimmt. So entsteht eine neue Dimension der Zusammenarbeit, in der direkt am Kunden entwickelt wird und an deren Ende vielleicht sogar die Abschaffung von Anforderungslisten entsteht.

Meilensteine und Scrum

Um ihren Produktentstehungsprozess planbar zu machen, setzen viele Unternehmen eine Form von Meilensteinplanung ein. Im Detail gibt es hier viele Unterschiede, aber das Prinzip ist immer das gleiche: Die Meilensteine sind Punkte entlang einer zeitlichen Achse, zu denen das Entwicklungsprojekt intern evaluiert wird. Die Zeiträume zwischen den Meilensteinen bilden häufig die Entwicklungsphasen nach dem V-Modell ab. In solchen Fällen folgt auf eine Machbarkeitsstudie die Konzeptionsphase, gefolgt von Design-, Verifikations- und Validationsphasen. Um einen Meilenstein zu “passieren”, wird anhand von festgelegten Dokumenten und Reviews überprüft, ob die vorangehende Phase erfolgreich abgeschlossen wurde.
Zugleich entscheiden sich immer mehr produktentwickelnde Unternehmen (längst nicht mehr nur in der Softwareentwicklung) für den Einsatz agiler Rahmenwerke wie Scrum. Hier kommt dann sehr schnell die Frage auf, ob und wie Scrum mit einer Planung in Meilensteinen “vereinbar” sei oder zumindest “kompatibel” gemacht werden könne. Aus meiner Erfahrung beruht allein schon diese Wortwahl auf der falschen Vorstellung, dass Scrum und Meilensteine zwei Prozessvarianten seien. Wenn das so wäre, müsste man sich für eines von beidem entscheiden – oder eben einen Kompromiss finden, der ein wenig von dem einen und ein wenig von dem anderen realisiert (was auch immer das dann konkret bedeutet).
Scrum ist eine Methode. Scrum sagt, dass Produkte iterativ (in regelmäßig wiederkehrenden Sprints) und inkrementell (Feature für Feature) entwickelt werden, damit die Organisation nicht erst zum Ende des Projektes, sondern kontinuierlich lieferfähig ist. Meilensteinpläne schreiben vor, welche Dokumentation wann im Laufe eines Projektes erzeugt und freigegeben werden muss. Scrum ist darauf ausgerichtet, die Entwicklung am Bedarf des Marktes auszurichten. Meilensteine sind hingegen interne Revisionsmechanismen, um Projekte auf der Spur zu halten.
In meinem aktuellen Projekt sind wir zum Start folgendermaßen vorgegangen:

Zusammenfassend: Es wäre naiv, Meilensteinpläne komplett zu ignorieren. Manche der dort vorgeschriebenen Deliverables sind sehr wohl für eine erfolgreiche Produktlieferung wesentlich. Genauso naiv aber wäre es, die Vorschriften 1:1 umzusetzen, nur weil es der Plan so besagt. Vor allem bietet Scrum die Chance, die starre Abarbeitung von Meilensteinen dadurch überflüssig zu machen, indem die kritischen Projektaspekte schon zu Beginn angegangen werden, so dass der Zweck der Meilensteinplanung – die Projektabsicherung – ohnehin erfüllt wird.