It’s the System, Stupid

28.05.2020
Dirk Strubberg

Projekte neu denken: Risiken sichtbar machen und agieren, bevor sie ein Problem werden

Komplexe Digitalisierungs- bzw. Transformations-Projekte sind dafür berüchtigt, ihre Ziele zu verfehlen. Agiles Projektmanagement gilt als Königsweg, doch in der Praxis entstehen dadurch viele neue Herausforderungen. In diesem Beitrag möchte ich einen systemdynamischen Ansatz [i] erläutern, der sich in unseren Projekten bewährt hat und den wir als Mindset und Toolset ständig weiterentwickeln.
Ein systemischer Grundsatz ist es, das Ganze zu optimieren, und nicht die einzelnen Teile. Da ein Transformationsprojekt nicht nur eine IT-Angelegenheit ist, sondern die ganze Organisation oder das Ecosystem betrifft, müssen alle Wechselwirkungen berücksichtigt werden. Unsere Beobachtung: Das Projekt ist meist stark auf die Features, die künftigen technischen Vorteile der Lösung, fokussiert. Die kurzfristigen Nachteile, die das Projekt selbst mit sich bringt, werden nicht adäquat gemanaged, weil sie in anderen Abteilungen zum Tragen kommen.
Aus IT-Sicht mag es naiv sein, aber die meisten „Betroffenen“ wünschen sich, dass das mit der neuen Software so läuft wie mit dem neuen Auto: Man nennt sein Wünsche, dann wird sie irgendwo gebaut, am Tag X in perfektem Zustand ausgeliefert und dann ist alles wie zuvor, nur besser. Der Realitäts-Schock kommt bald, denn zunächst passiert das Gegenteil: Wichtige Experten werden mit Beschlag belegt, es fehlen die Ressourcen fürs eigene Alltagsgeschäft, andere Projekte und Abteilungen werden ausgebremst, und dieser Zustand dauert sehr viel länger als geplant. Manchmal werden auch persönliche Kompetenzen und der eigene Arbeitsplatz in Frage gestellt. Dadurch wird das Projekt für einen Teil des Teams zu einem emotional bedrohlichen Vorgang.
Solche unerwünschten Nebenwirkungen sind eine Quelle von Risiken. Risiken sind Probleme, die noch nicht eingetreten sind. Probleme sind Aufgaben, für die es keinen erprobten Lösungsweg gibt. Der Lösungsweg fehlt, wenn die Komplexität zu hoch ist. Komplexität entsteht durch (ungewollte) Wechselwirkungen. Dieser Teufelskreis muss von Anfang an erkannt und durchbrochen werden.

Bei Risiken und Nebenwirkungen fragen Sie … Ihren Projektleiter?

Ein starkes Medikament hat auch starke Nebenwirkungen. Diese sollten bekannt sein, bevor man die Therapie beginnt. Ganz ähnlich sollte man die unerwünschten Nebenwirkungen, die ein großes IT-Projekt auf die Organisation haben könnte, keinesfalls ignorieren.
In einem typischen Industrieunternehmen, so ist unsere Erfahrung, haben die Kolleg*innen außerhalb der Projektorganisation klare Prioritäten. Für sie zählt, dass ihre Anlagen 24/7 laufen und die Qualität fehlerfrei ist. Alles, was den reibungslosen Produktionsablauf stören könnte, ist für sie ein rotes Tuch. Und ein echtes Damokles-Schwert für die IT: Sollte ein unentdeckter Software-Bug eine Anlage lahmlegen und dies zu einem Produktions-Stillstand von nur wenigen Stunden führen, dann könnten die Fehlerkosten viel höher sein als das ganze Projektbudget. Im agilen Mindset ist das ganz anders: Fehler gehören zum Entwicklungsprozess. Aber machen Sie das mal einem Anlagenführer klar!
Da diese Zielkonflikte nicht innerhalb, sondern außerhalb des eigentlichen Projektrahmens entstehen, haben selbst sehr gute Projektleiter sie oft nicht auf dem Radar. Im schlimmsten Fall geht es ihnen wie dem unglückseligen Kapitän der Titanic, der am 14. April 1912 zwar den Kurs, aber nicht das Tempo ändern wollte: „Die Entscheidung von Kapitän Smith beruhte auf einer groben Fehleinschätzung bezüglich der Sichtbarkeit von Eisbergen unter den Bedingungen in der Unglücksnacht,“ so das Fazit der Untersuchungskommission [ii].

Projekte neu denken heißt für mich daher vor allem: die Sichtbarkeit von Risiken (Eisbergen) erhöhen und agieren, bevor sie zu einem Problem werden.

Dafür sollten Sie:

  1. Systemisch-agile Skills und Denkmodelle lernen und erproben [iii]
  2. typische Problemmuster kennen, die in komplexen Projekten „wie von selbst“ auftreten [iv]
  3. Risiken nicht verdrängen, sondern sie beantworten, solange sie noch entfernt sind [v] [vi]

Erstellt mit Loopy https://ncase.me/loopy/v1.1/


Abb. 1: Projekte systemisch denken und lenken

Das Transformations-Problem: Egal was man tut, es ist immer einer dagegen!

In einer funktionierenden Organisation klappt das Zusammenspiel der Menschen, ihrer Kompetenzen, der Regeln, Prozesse und Anreize doch „irgendwie ganz gut“. Und dieses eingeschwungene System wird nun durch ein Transformationsprojekt aus der Balance gebracht. Wie die Systemwissenschaften zeigen, besitzt jede eingespielte Organisation ein „Immunsystem“, dass auf kritische Eingriffe mit Gegenreaktionen und Verzögerungen reagiert [vii]. „Policy Resistance“, der Widerstand gegen alle von oben implementierten Veränderungsvorhaben, ist keine sture Verweigerungshaltung, sondern die natürliche Reaktion eines sozialen Systems, das um seine Stabilität bemüht ist. Sie lässt sich auch durch eine mitreißende Vision nicht so einfach aushebeln.[viii] Der Veränderungs-Widerstand versteckt sich zunächst gern im Untergrund, manchmal sogar im Unterbewussten. Er kommt selten offen zur Sprache (außer in der Kaffeeküche), äußert sich aber im Verhalten. Besonders heimtückisch ist die schleichende Inflation der Anforderungen, die gegen Projektende meist in eine galoppierende Inflation übergeht.[ix] Sie erkennen dieses Symptom an Sätzen wie: „Wir benötigen unbedingt noch dies und das und jenes, sonst nehmen wir die Version nicht ab“.

Erstellt mit Loopy https://ncase.me/loopy/v1.1/


Abb. 2: Systemisches Muster des Transformations-Problems (limits to success / policy resistance)
Je komplexer das IT-Projekt ist, desto mehr Aktivitäten sind nötig. Wenn dies von Teilen der Organisation als Bedrohung empfunden wird, reagieren diese mit Veränderungs-Widerstand, d.h. die Aktivitäten werden gebremst. Daraufhin verstärkt das Projekt seine Bemühungen. Ein Kreislauf entsteht, in dem die Veränderung ihren eigenen Widerstand erzeugt, der umso größer wird, je mehr man die Veränderung vorantreibt.
 

Das Eskalations-Problem: Alle ziehen an einem Strang, nur in verschiedenen Richtungen!

Zielkonflikte zwischen der Projektorganisation und der Aufbauorganisation führen in aller Regel zum Wettkampf um die Lufthoheit im Projekt. Die IT führt Scrum ein? Die Fachabteilung nimmt nur manchmal teil: „Wir haben echt Wichtigeres zu tun“. Die Key User fordern eine benutzerfreundliche GUI? Die IT steigt gerade auf SAP 6.0 um: „Daran werdet ihr euch schon gewöhnen, da mussten alle anderen auch durch.“ Offiziell ziehen alle an einem Strang, nur leider in verschiedenen Richtungen. Folge: Die Zeitampel springt auf gelb.
Rangeleien um Ressourcen, Budgets, Termine und Inhalte sind bald an der Tagesordnung. Wenn der Konflikt nicht gelöst wird, entsteht das Eskalations-Problem wie von selbst. Beide Parteien wollen zwar das Projekt, aber noch wichtiger ist es, auf keinen Fall das Gesicht verlieren oder für irgendwas als Schuldiger dastehen. Also weichen sie in wichtigen Punkten keinen Millimeter mehr zurück, die Fronten verhärten, der Ton wird rauer, die Stimmung eisig. Jeder weiß, wie schwierig es ist, einen Konflikt zu beenden, wenn der Teufelskreis der Eskalation erst einmal eingesetzt hat. In dieser Situation helfen oft nur noch kooperative Verhandlungsmethoden wie das Harvard-Prinzip[x] eine Mediation oder die Lösung emotionaler Blockaden durch die Gewaltfreie Kommunikation.[xi]

Erstellt mit Loopy https://ncase.me/loopy/v1.1/


Abb. 3: Systemisches Muster des Eskalations-Problems (escalation)
Zwei Abteilungen treten in Konkurrenz um Budget, Befugnisse oder Ressourcen. Jeder Vorteil der Partei A wird von B als Bedrohung erlebt und B versucht, seine Position durch entsprechende Aktionen zu stärken. A fühlt sich ebenfalls bedroht und reagiert genauso. Folge: Wichtige Ressourcen werden durch den Konflikt gebunden und nicht mehr ins gemeinsame Ziel investiert.
 

Das Notlösungs-Problem: Man hat niemals Zeit, es richtig zu machen, aber immer Zeit, es noch einmal zu machen!

Aufgrund der Verzögerungen fordert das Management nun schnellere Fortschritte. Weil aber die beiden Kollegen mit dem größten Erfahrungswissen kürzlich in den Vorruhestand geschickt wurden, fehlen jetzt die internen Ressourcen. Ausnahmsweise wird Budget bewilligt, nun schlägt die Stunde der externen Berater. Nach einiger Zeit erledigen sie den Job professionell. Daher wird ein immer größerer Teil der Projektarbeit an sie ausgelagert. Bald geht es nicht mehr ohne sie, schleichend ist die Organisation in eine teure Abhängigkeit geraten. Die Budgetampel wird rot, aber was soll man machen? Das Notlösungs-Problem entsteht immer, wenn ein Quick-Fix zwar kurzfristig hilft, aber langfristig neue Probleme erzeugt. Oder wenn eine grundlegende Herausforderung wie der Wissenstransfer nicht angegangen wird, und man später gar nicht mehr in der Lage ist, die Aufgabe aus eigener Kraft zu lösen.

Erstellt mit Loopy https://ncase.me/loopy/v1.1/


Abb. 4: Systemisches Muster des Notlösungs-Problems (shifting the burden)
Je akuter das Problem, desto eher greift man zur Notlösung und lindert nur die Symptome. Die schnelle Hilfe wird zur Gewohnheit; die Ursachen des Problems werden ignoriert. Dies hat langfristig schädliche Nebenwirkungen, die die Fähigkeit zu einer adäquaten Lösung vermindern.

Das Qualitäts-Problem: Think different statt try harder!

In einer Krisensitzung findet der Projektleiter einen Ausweg, der das Management überzeugt. Man muss ja nicht alle Features sofort umsetzen, nicht alle Anlagen gleichzeitig umstellen, nicht in allen Werken parallel launchen. Das Senken der Ziele scheint in dieser Situation angebracht. Man gewinnt Zeit für bessere, grundsätzliche Lösungen. Da sind sich endlich mal alle einig. Doch: Was sich einmal bewährt hat, macht man beim nächsten Mal wieder.
Weil es einfacher ist, ein Ziel zu senken als es zu erreichen, wird die Qualitäts-Ampel von Monat zu Monat dunkler. Und weil die Ziele im Konsens gesenkt werden, ist man sich auch in der Farbenlehre einig: das neue gelb ist grün. Das Vertrackte daran: Auch die Notlösung funktioniert irgendwann nicht mehr. Mit „Try harder“ kommt man dann beim besten Willen nicht mehr weiter. „Think different“, die Suche nach neuen Möglichkeiten zur Leistungssteigerung, ist der bessere Lösungsweg.

Erstellt mit Loopy https://ncase.me/loopy/v1.1/


Abb 5: Systemisches Muster des Qualitäts-Problems (drifting goals)
Das Defizit zwischen Soll- und Ist-Leistung kann kurzfristig nicht behoben werden, da eine Leistungssteigerung z.B. Investitionen oder Innovationen erfordern würde. Der schnelle und scheinbar einfache Weg einer Senkung der Ziele wird bevorzugt. So entsteht ein Teufelskreis immer weiter sinkender Ziele und Ansprüche.

Lösung: das Problem bei den systemischen Ursachen packen

Kommen Ihnen diese Stories bekannt vor? Wohl jeder Projektleiter hat sie so oder ähnlich immer wieder erlebt. Denn hier sind systemische Archetypen am Werk: Eigendynamiken, die besonders leicht entstehen und die mit dem gewohnten linear-kausalen Denken und der Suche nach einem „Schuldigen“ kaum in den Griff zu kriegen sind. Diese Muster wurden bereits in den 1990er Jahren vom Systemwissenschaftler Peter M. Senge am MIT identifiziert und für Management-Prozesse adaptiert.[xii] [xiii]
Eine visuelle Darstellung der Zusammenhänge ist dabei bewährt. Nur wenn man ein klares Bild vor Augen hat, kann man sicher sein, im Team über das gleiche zu reden. Der erste Schritt ist, das Problem-Muster im Rahmen eines Workshops auf einem Flipchart zu visualisieren. Die Grundprinzipien sind einfach zu lernen.[xiv] Die gute Nachricht: Mit Grundkenntnissen im systemischem Denken kann man diese Muster relativ schnell erkennen[xv]. Interaktive Online-Kurse gibt es seit kurzem auch in Deutschland [xvi]. Es gibt auch eine intuitiv bedienbare Online-Lösung, mit der diese Grafiken einfach erstellt werden können.[xvii]
Eine Lösung für Profis ist der Einsatz einer systemdynamischen Business Intelligence Lösung wie Qentinel Quality Intelligence. Sie kombiniert die Modellierung von IT-Wertschöpfungsprozessen mit der ständigen Erfassung relevanter Kennzahlen zur Software-Qualität. Dies geht weit über MS Project und agile Scrum-Boards hinaus und erlaubt die vorausblickende Steuerung agiler IT-Prozesse von DevOps bis hin zu komplexen Transformationen anhand von Metriken, die Sinn machen. [xviii]

Abb 6: Qentinel Quality Intelligence Dashboard für DevOps Prozesse
 
[i] Hartmut Bossel: Systeme, Dynamik, Simulation. Norderstedt, 2004
[ii] https://de.wikipedia.org/wiki/RMS_Titanic
[iii] Bernd Oesterreich, Claudia Schröder: Agile Organisationsentwicklung. München, 2020
[iv] Daniel H. Kim und Colleen P. Lannon: Applying Systems Archetypes, Pegasus Communications, 1997, https://thesystemsthinker.com/applying-systems-archetypes/
[v] Tom DeMarco, Timothy Lister: Bärentango. München, 2003
[vi] Atlantic Systems Guild: Riskology. https://systemsguild.eu/riskology
[vii] Donella H. Meadows: Die Grenzen des Denkens. München, 2010.
[viii] John P. Kotter: Leading Change. München, 2011
[ix] Tom DeMarco, Timothy Lister: Bärentango. München, 2003
[x] Roger Fisher, William Ury, Bruce Patton: Das Harvard Konzept, München 2018
[xi] Marshal Rosenberg: Gewaltfreie Kommunikation, Paderborn 2016
[xii] Peter M. Senge: Die fünfte Disziplin. Stuttgart, 1996.
[xiii] Daniel H. Kim: Introduction to Systems Thinking, Pegasus Communications, 1999. https://thesystemsthinker.com/introduction-to-systems-thinking/
[xiv] Colleen P. Lannon: Causal Loop Construction: The Basics, Pegasus Communications, 2012, https://thesystemsthinker.com/causal-loop-construction-the-basics/
[xv] www.systemthinking.de
[xvi] www.stayforward.de (Online-Trainingsprogramm, ab Juni 2020)
[xvii] https://ncase.me/loopy/
[xviii] https://qentinel.com/de/predictive-analytics-for-devops/
 
Der Autor
Dirk Strubberg ist Geschäftsführer der Qentinel GmbH, der deutschen Tochtergesellschaft der Qentinel Gruppe, dem Marktführer für IT-Qualität in Skandinavien. Als Diplom-Kommunikationswirt, SAFe Agilist, systemischer Coach, zertifizierter Trainer für Systemdenken und HR-Consultant (ECA) ist sein Spezialgebiet die systemische Steuerung agiler Transformationsprojekte. Kontakt: dirk.strubberg@qentinel.com
 

0 Kommentare

Einen Kommentar abschicken

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.