Change Management in Projekten

2021-03-01

Dieser Beitrag wurde ebenfalls veröffentlicht in Schröder Dörte: Change Management in Projekten: Komplexität gemeinsam bewältigen, in: Andreas Klein (Hrsg.), Projektcontrolling mit agilen Instrumenten, 1. Auflage, Freiburg 2021, S. 205-2018.
Der besseren Lesbarkeit halber wird in diesem Beitrag auf gendergerechte Sprache verzichtet und stets die weibliche Form verwendet. Es sind jedoch selbstverständlich stets alle Geschlechter gemeint.

Veränderungen im Projekt – seien es neue Anforderungen, Umbrüche in der Projektaußenwelt oder Veränderungen im Team selbst – treten gerade bei komplexen Projekten immer wieder auf, und der Umgang damit ist ein wesentliches Erfolgskriterium. Gemeinsame Verantwortung und eine etablierte Lernkultur im Projektteam sowie zielführende Grundannahmen leisten dazu einen wesentlichen Betrag. Und nicht zuletzt helfen Messpunkte, den Fortschritt zu objektivieren.

Wie kommt die Veränderung ins Projekt?

Es ist schon lästig, diese ständige Veränderung. Gerade hat man sich an die neue Software gewöhnt, da gibt es auch schon ein Update und die Oberfläche sieht wieder anders aus. Kürzlich noch war der Besuch großer Konzerte möglich und es ließ sich in die Menge der Fans und in die Musik eintauchen, jetzt gibt es gesundheitliche Regelungen, die das unmöglich scheinen lassen. Und der überaus gut durchdachte Projektplan, der vor wenigen Wochen erstellt wurde, scheint heute schon nicht mehr zu passen, weil der Kunde wieder neue Anforderungen hat.

Veränderung ist ein Zeichen von Leben und insofern uns allen sehr vertraut. Wir verändern uns ständig, und die Welt um uns herum ebenfalls. Dennoch scheinen Veränderungen im Projektmanagement eher schwierig zu sein. Woher kommt das?

Ein Blick in die Systemtheorie und insbesondere das Cynefin-Framework kann helfen. Entwickelt wurde dieses Framework von David Snowden, und es untersucht insbesondere die Art der Ursache-Wirkung-Beziehungen. Grob werden vier Bereiche unterschieden:

offensichtlich: Systeme mit offensichtlicher Ursache-Wirkung-Beziehung sind, wie der Name schon nahelegt, sehr einfach verständlich. Offensichtliche Systeme lassen sich typischerweise über Kategorisierung einordnen, mit anderen Worten: es gibt sowas wie ein Handbuch. Einen Besprechungsraum buchen beispielsweise ist in Unternehmen oft ein offensichtlich lösbares Problem, weil es ein Buchungssystem gibt, in dem sich die Raumverfügbarkeit überprüfen und ein geeigneter Raum buchen lässt. Man muss nicht unnötig lange planen oder analysieren, sondern kann quasi nachschlagen: sense – categorize – respond.
kompliziert: diese Systeme lassen sich komplett analysieren und verstehen, allerdings ist dafür möglicherweise Expertenwissen erforderlich. Ein Uhrmachermeister beispielsweise kann ein mechanisches Uhrwerk analysieren und in der Wirkungsweise vollständig verstehen. Eine Architektin kann die Statik eines Gebäudes komplett berechnen. Und wenn ein kompliziertes System komplett analysieret werden kann, ist es eine gute Idee, das auch zu tun, d.h. das sinnvolle Vorgehen ist sense – analyze – respond.
komplex: diese Systeme haben durchaus Ursache-Wirkungs-Beziehungen, allerdings gibt es so viele Einflussfaktoren, dass es nicht möglich ist, das System komplett zu analysieren und zu verstehen. Das Verhalten in komplexen Systemen versteht man typischerweise rückwärts, also von der Art „weil die das gemacht hat, hat der dann so reagiert und dann ist das passiert, und jetzt haben wir den Salat“. Das Verhalten von Märkten und Menschen ist in der Regel komplex. Da sich komplexe Systeme nicht komplett durchanalysieren lassen, ist ein anderer, flexiblerer Ansatz erforderlich. Man kann nur schrittweise vorgehen, Hypothesen bilden über Wirkzusammenhänge, darauf basierend Erfahrungen sammeln und mit den neu gewonnenen Erkenntnissen den Kurs dann anpassen, d.h. probe – sense – respond.
chaotisch: in diesen Systemen gibt es keine Ursache-Wirkungs-Beziehung, die sich für uns erschließen lässt. Das ist im allgemeinen kein besonders angenehmer Zustand, weil in einem solchen Umfeld keine Voraussagen darüber gemacht werden können, wie die Akteure sich verhalten und wie die Zustände sich entwickeln werden. In chaotischen Systemen können am ehesten innovative Praktiken entstehen; das sinnvolle Vorgehen lässt sich hier mit act – sense – respond beschreiben.

Darstellung Cynefin-Framework — David Snowden (en:User:Snowded: file log), Public domain, via Wikimedia Commons

Besonders relevant ist der Unterschied zwischen komplizierten und komplexen Systemen. Während sich komplizierte Systeme komplett verstehen und durchplanen lassen, kann das für komplexe Systeme per Definition nicht mehr gelingen. Damit ist klar, dass in komplexen Systemen der Projektplan nicht mehr nachhaltig existieren kann. Selbst wenn wir ein komplexes Projekt komplett durchplanen, dann kann das nur eine Momentaufnahme unsere aktuellen Wissensstands und unserer aktuellen Annahmen sein – und das kann sich morgen schon ändern. Wir müssen in einem komplexen System also grundlegend anders vorgehen.

Um als Organisation mit den Anforderungen komplexer Problemstellungen umgehen zu können, haben sich die agilen Arbeitsmethoden wie Scrum oder Kanban herausgebildet. Im Kern geht es dabei immer um eine Reduktion von Komplexität bei gleichzeitig Erhaltung der Flexibilität. In diesem Artikel wollen wir uns jedoch nur auf den Aspekt der Veränderungen und der Entwicklung des Teams fokussieren.

Komplexe Aufgaben brauchen mitverantwortliche Mitarbeiterinnen

Wir haben gesehen: die technische Lösung an sich, die Bewegungen der Mitbewerber und des Markets, die Anforderungen unserer Kunden, die Randbedingungen durch Stakeholder und andere Ereignisse wie Pandemien, all das kann in komplexen Projekten zu Veränderungen führen, mit denen eine Projektleiterin und das Team umgehen muss.

Es hat sich gezeigt, dass komplexe Aufgaben in selbstorganisierten und interdisziplinären Teams am besten erledigt werden können. Mit anderen Worten: wenn unterschiedliche Expertinnen in einem selbstorganisierten Team zusammen arbeiten, dann erreicht man dadurch u.a. eine Komplexitätsreduktion, weil diese Expertinnen viele Abhängigkeiten zwischen Teilaufgaben untereinander ausregeln, ohne dass es dafür eine zentrale Lösungskompetenz (sei es die Projektleiterin oder jemand anderes) braucht. Die notwendige Voraussetzung dafür ist natürlich, dass das Team tatsächlich als Team zusammenarbeitet und sich für das Ergebnis gemeinsam verantwortlich fühlt.

Damit kommen wir zu der wirklich spannenden Frage: wie bringen wir denn nun das Projektteam in diesen Nirwana-artigen Zustand?

Das ist keine einfache Aufgabe, sie ist noch nicht mal „nur“ kompliziert, sondern tatsächlich sehr komplex, mit anderen Worten: den einen richtigen Weg, die eine richtige Antwort gibt es nicht. Aber es gibt gute Zutaten dafür, von denen wir die wichtigsten im folgenden beleuchten wollen.

Zutaten: Verantwortung und Partizipation im klaren Rahmen

Wie beschrieben ist es die grundsätzliche Idee, das Team in die gemeinsame Verantwortung bringen. Dafür ist es zielführend, innerhalb eines klaren Rahmens das Team den größtmöglichen Freiraum zu geben, um den Lösungsweg zu erarbeiten.

Aus Führungssicht (und zwar sowohl einer Führungskraft als auch der Projektleiterin) liegt der erste Schritt darin, sich über die Ziele und Leitplanken klarzuwerden.

Welche Ziele hat das Projekt? Welches Ergebnis möchte das Unternehmen mit diesem Projekt erreichen? Welche Auswirkungen wird es haben, wenn wir das Ziel erreichen oder nicht erreichen? Gibt es Haupt- und Nebenziele, und wenn ja, wie sind diese zu gewichten? Je konkreter und messbarer die Ziele gefasst werden können, desto besser.

Welche Leitplanken sind relevant? Welche Rand- und Rahmenbedingungen gibt es? Welche Grenzen dürfen nicht überschritten werden? Auch hier gilt wieder: je konkreter, desto besser.

Erfahrungsgemäß sind die Ziele und Leitplanken nicht sehr gut beschrieben und/oder werden nicht transparent dargestellt. Das gilt insbesondere für das WOZU des Projekts, also den Sinn und Nutzen, der mit diesem Projekt verfolgt wird. Diese Informationen konkret und transparent zu haben, hilft jedoch allen Beteiligten enorm bei der Einordnung und der Priorisierung.

Ein Wort zur Messbarkeit der Ziele: wichtig ist es, die tatsächlichen Ziele abzubilden und dafür Metriken zu entwickeln. Es hat wenig Sinn (und ist sogar schädlich!), nur diejenigen Ziele transparent zu machen, die sich rein zufällig gut messen lassen.

Ein Beispiel für die Messbarkeit des Sinn und Nutzens eines Projekts: Ein Logistikdienstleister für Spezialtransporte möchte sein Beschwerdemanagement digitalisieren und hat ein entsprechendes Projekt aufgesetzt. Das Projektziel ist es, den bisher teilweise manuellen Prozess weitestgehend digital zu führen. Dafür lassen sich Metriken formulieren, die beispielsweise den Digitalisierungsgrad der verschiedenen Prozessschritte oder Schnittstellen abbilden. Der Sinn und Nutzen des Projekts liegt jedoch nicht einfach in der Existenz dieses digitalen Prozesses, sondern dient (z. B.) dazu, die Kundenzufriedenheit zu erhöhen. Dafür lassen sich durchaus messbare Größen formulieren wie Net Promoter Score oder durchschnittliche Antwortzeiten. Im Verlauf des Projekts kann sich unter Umständen herauskristallisieren, dass das Projektziel nicht im geplanten Umfang den eigentlich gewünschten Nutzen erzielt, z.B. weil die Kundenzufriedenheit auch bei digitalisiertem Prozess nicht steigt. Dann ist es sinnvoll, das Projektziel (und damit das Projekt) anzupassen.

Es könnte an dieser Stelle der Eindruck entstehen, dass dieser erste Schritt alles andere als einfach und möglicherweise echte Arbeit ist. Dieser Eindruck wäre richtig ;-). In der Anwendung führt die geforderte Klarheit manchmal zu schwierigen Diskussionen mit Stakeholdern oder Auftraggebern und wird daher gern vermieden, ist jedoch sehr wichtig.

Es ist durchaus möglich (und in einer komplexen Umgebung sogar wahrscheinlich), dass sich das Ziel des Projekts im Laufe der Zeit verändert. Das können kleinere Anpassungen sein, die sich sehr klassisch über Change Requests verarbeiten lassen, es können sich aber auch signifikante Veränderungen des Projektziels ergeben. Oft entsteht dann „scope creep“, also die schleichende Veränderung bzw. Erweiterung des Leistungsumfangs. Eine Veränderung des Projektziels ist jedoch nicht schlecht per se, im Gegenteil: es gibt ja in der Regel einen guten Grund dafür. Wichtig ist nur, diesen Prozess nicht „creepy“ werden zu lassen. Mit anderen Worten: wenn es signifikante Änderungen des Leistungsumfangs gibt, dann ist es wichtig, das entsprechend zu benennen und zu kommunizieren.

Bei der Kommunikation des WAS und WOZU des Projekts ist unter Umständen durchaus Überzeugungsarbeit nötig, um die Projektmitarbeiterinnen an Bord zu holen. Schwierigkeiten auf diesem Weg sind ein Signal dafür, das nicht ignoriert werden sollte, sondern mit dem die Projektleiterin konstruktiv-offen umgehen sollte.

Im zweiten Schritt geht es darum, die Ziele und Leitplanken (das WAS) den Projektmitarbeiterinnen zu vermitteln, deren Feedback und Zustimmung einzuholen und mit ihnen gemeinsam das WIE zu erarbeiten.
Das ist ein Diskussionsprozess, in dessen Verlauf es durchaus sein kann, dass sich an den Zielen und den zugehörigen Metriken noch Änderungen ergeben. Wenn sich dadurch was ändert, ist das ein gutes Zeichen, weil die Ziele dadurch besser werden (und weil die Mitarbeiterinnen sich engagiert haben).

Grundsätzlich können sich daraus Herausforderungen verschiedener Art ergeben.

Es könnte sein, dass sich das Team nicht einigen kann, weil es zu viele widerstreitende Ideen oder Interessen gibt. Dann ist es wichtig, die entsprechenden Interessenskonflikte anzugehen und aufzulösen. Das mag zwar schwierig und mühsam sein, ist aber dennoch sinnvoll, weil nicht aufgelöste unterschwellige Konflikte für die Zusammenarbeit und damit den Projekterfolg schädlich sind.

Es könnte auch sein, dass das Team sehr passiv reagiert und auf eine Lösung von außen wartet. Dieses Verhalten findet sich sehr oft in Organisationen, die bislang noch wenig Erfahrung mit partizipativen Führungsstrukturen gemacht haben. In diesem Fall ist es wichtig, die Erwartung klarzustellen und den Diskussionsprozess zu unterstützen, ggf. mit einer externen Moderatorin oder Facilitatorin. Auch diese Investition ist sinnvoll, weil mangelndes Verantwortungsgefühl bei den Teammitgliedern für den Projekterfolg schädlich ist.

Oft gibt es auch Einwände – gerade von Führungsebenen -, dass dieses Vorgehen zu lange dauert und dass es doch viel effizienter wäre, das WIE den Projektmitarbeiterinnen einfach vorzuschreiben. Investitionen in die Zusammenarbeit, wie die Auflösung von Interessenskonflikten und Stärkung des Gefühls gemeinsamer Verantwortung, haben jedoch durchgehend eine positive (wenn auch nicht immer direkt messbare) Auswirkung auf den Erfolg des Projekts, und sind auch keine einmaligen Aktivitäten. In welchem Umfang dies sinnvoll und nötig ist, hängt natürlich immer auch vom Kontext ab: wie groß sind die Konflikte, wie viel Vertrauen haben die Projektmitglieder in das Vorgehen, in welchem Umfang ist die intensive Zusammenarbeit überhaupt nötig etc.

Das WIE vom Projektteam erarbeiten zu lassen, ist eine kontinuierliche Aufgabe und auf allen Ebenen des Projekts möglich. Als praktische Anregungen können dienen:

Die Regeln der Zusammenarbeit im Projektteam lassen sich beispielsweise initial sehr gut bei einem Projekt-Kick-Off erarbeiten. Nebenbei dient dies direkt zu Beginn des Projekts als ein deutliches Signal für die Projektmitarbeiterinnen, dass sie für diese Aspekte mitverantwortlich sind.
Inhaltliche Lösungen können von den relevanten Expertinnen und betroffenen Personen gemeinsam erarbeitet werden. Dabei ist es wichtig, tatsächlich alle einzubeziehen, die von dieser Lösung in irgendeiner Form betroffen sind. Beispielsweise sollte die Software-Architektur nicht nur von den entsprechenden Architektinnen und Entwicklerinnen erarbeitet werden, sondern auch die Expertinnen der Bereiche Test / Qualitätssicherung, Betrieb, funktionale Anforderungen etc. mit einbeziehen.
Die Arbeitsorganisation im Team kann vom gesamten Team erarbeitet werden und sollte dann regelmäßig auf Zweckmäßigkeit überprüft werden (siehe Abschnitt „lernende Organisation / Retrospektiven“). Dies betrifft beispielsweise Transparenz zu Inhalten und Status der Arbeitspakete (z.B. Ticket-Systeme oder Boards), Darstellung der Abhängigkeiten, Umgang mit Problemen, Inhalt und Form regelmäßiger Meetings, …

Gerade wenn die Projektmitarbeiterinnen bzw. die gesamte Organisation nicht sehr geübt ist, bietet es sich an, diese Prozesse durch eine neutrale Moderation zu unterstützen. Im Kontext agiler Arbeitsmethoden ist dies eine wesentliche Aufgabe einer Scrum Masterin bzw. Agile Coach, sie kann jedoch auch allgemein durch eine Projekt-Coach oder sogar eine Führungskraft oder die Projektleiterin wahrgenommen werden – vorausgesetzt die Person wird von den Projektmitgliedern als neutral gesehen.

Im Grundsatz kommt also das WAS von der Führungskraft / Projektleiterin, das WIE erarbeiten die Projektteilnehmerinnen dann gemeinsam. Im Idealfall lässt sich der Projektstart und ein gut vorbereitetes Kick-Off nutzen, um Ziel und Leitplanken transparent zu machen, die Unterstützung der Projektmitarbeiterinnen zu gewinnen und erste Ansätze für das Vorgehen zu entwickeln.
Wichtig ist, den Teammitgliedern durchgehend zu vermitteln, dass sie diejenigen sind, die für das WIE, das Vorgehen verantwortlich sind. Um die Teammitglieder in die Verantwortung nehmen zu können, brauchen sie Unterstützung: Freiraum (durch entsprechend verfügbare Zeitkontingente), klare Ziele und Leitplanken, ggf. Moderation.

Und um das klarzustellen: Das alles führt nicht zu einer Veränderung der Mitarbeiterinnen über Nacht, sondern ist ein längerer Prozess. Die Mitarbeiterinnen haben ja oft über Jahre, wenn nicht Jahrzehnte, gelernt, welche Verhaltensmuster erfolgreich sind. Dass jetzt andere Verhaltensmuster erfolgreich sind, ist ebenfalls ein Lernprozess, der schlicht Zeit und Raum zum ausprobieren und Erfahrungen sammeln braucht. (Das gilt übrigens auch für die Führungskräfte und die Projektleiterinnen…)

Zutaten: lernende Organisation / Retrospektiven

Wer sich schon einmal mit Scrum oder einer anderen agilen Arbeitsmethode beschäftigt hat oder sogar schon in einem Scrum-Team mitgearbeitet hat, kennt die konsequenten Feedbackschleifen und insbesondere die Retrospektiven. Nicht umsonst sind Retrospektiven ein Herzstück des agilen Arbeitens, hier kommt das Grundprinzip überprüfen und anpassen (englisch: inspect and adapt) voll zum Tragen. Das Charmante daran: Retrospektiven lassen sich auch unabhängig von Scrum und in praktisch jedem anderen Kontext mit Gewinn anwenden.

In einer Retrospektive begibt sich das Team regelmäßig auf eine Metaebene und betrachtet die Zusammenarbeit, rekapituliert was in der letzten Zeit gut lief, wo es Verbesserungspotenzial gibt und welche Veränderungen sie vornehmen wollen. Damit ist es ein sehr effektives Tool, um die lernende Organisation zu etablieren und um überhaupt in einer Organisation auf allen Ebenen die Veränderungsfähigkeit und Resilienz zu stärken.

Was sind nun wesentliche Faktoren, damit Retrospektiven auch wirklich diesen Effekt haben können? Da gibt es einige Punkte, die zu beachten sind:

Regelmäßigkeit statt Krisenmodus: Retrospektiven sollten regelmäßig stattfinden, bei intensiv zusammenarbeitenden Teams alle 1-4 Wochen. Das stellt sicher, dass sich Probleme nicht zu lange ansammeln und entsprechende Emotionen nicht zu lange aufstauen können. Die Regelmäßigkeit ist außerdem ein sichtbares Zeichen dafür, dass es gerade nicht um Krisenbewältigung geht, sondern dass kontinuierliche Verbesserung das Ziel ist.
Alle Sichtweisen statt Dominanz einzelner: Oft erlebt man in Meetings, dass eine früh und nachdrücklich geäußerte Meinung, vielleicht sogar von einer Führungskraft oder Machtperson, die Richtung des Meetings und damit auch das Ergebnis nachhaltig beeinflusst. In einer Retrospektive ist das explizit nicht gewünscht; hier möchte man die Stimmen aller Beteiligten hören, möglichst ohne dass diese initial von anderen beeinflusst werden. Diversität der Meinungen ist wichtig, um die blinden Flecken zu reduzieren und zu guten Lösungen zu kommen. Daher wird durch die Moderatorin sichergestellt, dass erst alle Sichtweisen gehört und gesehen werden, bevor das Team zu gemeinsamen Entscheidungen zu den nächsten Schritten kommt.
Lösungsorientierung statt Schuldzuweisung: Retrospektiven haben immer einen lösungsorientierten Ansatz und sind keine Instrumente, um nach Schuldigen zu suchen. Je nach kultureller Prägung der Teammitglieder ist von der Moderatorin hier eine gewisse Kompetenz gefragt, um diesen Fokus zu halten. Gern wird in diesem Zusammenhang auf die sog. Prime Directive verwiesen, s.u.
Sollten die Teammitglieder dazu neigen, die Probleme außerhalb ihres Teams zu sehen und dadurch nicht aktiv werden zu wollen, hat es sich bewährt, das Problem schichtweise anzugehen: a) Steht es in der Macht des Teams, an der Situation etwas zu ändern? Wenn ja, lassen sich konkrete Maßnahmen identifizieren, die das Problem lösen. b) Hat das Team die Möglichkeit, die Situation zumindest zu beeinflussen? Typischerweise werden die Möglichkeiten der Einflussnahme unterschätzt, es lohnt sich, hier etwas genauer hinzusehen und nicht in „das haben wir noch nie gemacht“ stehenzubleiben. Wenn ja, lassen sich ebenfalls konkrete Maßnahmen identifizieren, auch wenn nicht garantiert ist, dass diese zum Erfolg führen. c) Wenn das Team keine Chance hat, die Situation auch nur zu beeinflussen, dann ist das wie schlechtes Wetter – nicht schön, aber eben auch nicht zu ändern. In dem Fall geht es darum herauszuarbeiten, wie die vorhandenen Handlungsspielräume am besten genutzt werden können.
Konkrete kleine Schritte statt (zu) große Lösungsideen: Bei jeder Retrospektive werden sehr konkrete Aktivitäten vereinbart, die für das Team einen positiven Effekt haben. Dabei liegt der Fokus vor allem auf der Umsetzbarkeit. Bei jeder Retrospektive nur kleine Schritte vereinbaren und umsetzen ist sehr viel besser als große Lösungen, die dann eventuell nicht umgesetzt werden (können). Die Regelmäßigkeit von Retrospektiven erlaubt auch explizit experimentelle Ansätze: es werden kleine Maßnahmen für wenige Wochen ausprobiert, von denen sich die Teammitglieder Verbesserungen versprechen. Wenn diese den gewünschten Effekt haben, behält das Team sie bei, ansonsten wird etwas anderes probiert. Das nimmt allen Beteiligten auch den Druck, vorab die „richtige“ Lösung finden zu müssen – was in vielen Fällen weder nötig noch hilfreich ist.

Prime Directive
Die sog. Prime Directive geht zurück auf Norman Kerth, der sie als eine Basis für Retrospektiven betrachtet. Sie lautet:
„Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” – bzw. auf deutsch:
„Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jede ihr Bestes in der gegebenen Situation getan hat mit dem verfügbaren Wissen, den Ressourcen und den individuellen Fähigkeiten.“

Retrospektiven sind manchmal emotional oder führen zu besonderen Durchbrüchen, fühlen sich in den meisten Fällen aber eher unspektakulär an – und das ist auch gut so. Schließlich geht es ja darum, die kontinuierliche Verbesserung und Veränderungsfähigkeit zu verankern. Wichtig bei der Durchführung einer Retrospektive ist in jedem Fall eine gute und vor allem unabhängige Moderatorin. Bewährt hat sich für die Moderation das von Esther Derby und Diana Larsen entwickelte 5-Phasen-Modell für Retrospektiven. [Esther Derby, Diana Larsen; Agile Retrospectives: Making Good Teams Great; O’Reilly UK Ltd.(2006)]

Zutaten: Grundannahmen

Grundannahmen bestimmen unser Leben, und zwar oft ohne dass uns das bewusst ist. Grundannahmen sind verinnerlichte Überzeugungen, die wir aus Erfahrung gebildet oder von anderen Menschen übernommen haben. Es sind quasi die Axiome, auf denen unsere Modellierung der Welt beruht. Das ist sowohl praktisch als auch gefährlich, je nachdem, mit welchen Grundannahmen wir unterwegs sind.

Vermutlich kennen wir alle Menschen, die mit einer sehr misstrauischen Haltung unterwegs sind, und die dann auch regelmäßig erleben, dass ihr Misstrauen berechtigt ist. Umgekehrt gilt das auch: wer davon überzeugt ist, dass die Mitmenschen grundsätzlich hilfsbereit und unterstützend sind, wird auch oft diese Unterstützung erfahren. Das liegt daran, dass unser Hirn Kongruenz mit der eigenen Modellierung der Welt herstellen möchte und daher die Wahrnehmungen entsprechend filtert und die Fakten „passend“ interpretiert.

Generell gilt: ob jemand glaubt, dass etwas möglich oder nicht möglich ist, er oder sie wird höchstwahrscheinlich Recht behalten – das Phänomen der self-fulfilling prophecy.

Auch im Projekt- oder Führungsumfeld haben Grundannahmen daher erhebliche Auswirkungen. Zwei zielführende Grundannahmen und deren Auswirkungen sollen hier näher beleuchtet werden.

Jede tut ihr Bestes.

Wenn Führungskräfte mit diesem Satz konfrontiert werden, löst das oft erstmal Widerstände aus. Fast jede hat ein Erlebnis parat, was dieser Aussage zu widersprechen scheint, weil eine Person eben gerade nicht das getan hat, was als „das Beste“ gesehen wird. Wenn beispielsweise eine Projektmitarbeiterin mit der Erledigung eines Arbeitspakets in Verzug gerät, scheint sie zunächst einmal nicht „das Beste“ zu tun. Dennoch eröffnet die Grundannahme „jede tut ihr Bestes“ neue Optionen, die Situation zu verstehen und aufzulösen. Wenn die Projektmitarbeiterin nämlich ihr Bestes getan hat, wenn sie also grundsätzlich eine gute Absicht hatte, dann muss es andere Gründe geben, warum sie in Verzug ist. Vielleicht hat sich das Arbeitspaket als umfangreicher herausgestellt als geplant, vielleicht gab es Störungen von außerhalb des Projekts, vielleicht fehlt ihr die nötige Kompetenz oder Erfahrung, und vielleicht hat sie auch keine persönliche Verbindung zum Projektziel und dem Sinn, so dass sie ihre persönlichen Prioritäten anders gesetzt hat. Der Fokus verlagert sich also von einer Wertung der Person weg und hin zu einer Untersuchung der Rand- und Rahmenbedingungen, und damit auch zu der Fragestellung, was die Projektmitarbeiterin an Unterstützung braucht bzw. welche Rahmenbedingungen geändert werden sollten.

Jede führt sich selbst in voller Verantwortung.

Auch diese Aussage führt oft zu Widerständen, gerade bei Führungskräften, deren Aufgabe es ja gerade ist, andere Menschen zu führen. Wie passt das mit „jede führt sich selbst“ zusammen?

Führung versteht sich als direkte und indirekte Verhaltensbeeinflussung von Menschen, um ein bestimmtes Ziel zu erreichen. Die Art der Beeinflussung ist dabei breit gefächert und reicht von direkter Anordnung bis hin zu indirekten und systemischen Randbedingungen. Selbst eine direkte Anordnung („Herr Müller, bringen Sie mir Akte X!“) lässt der Mitarbeiterin immer noch den Freiraum (und damit auch die Verantwortung für sich selbst), dieser Anordnung Folge zu leisten oder nicht – oder auch, in welcher Form sie die Anordnung befolgt. Je vielfältiger und anspruchsvoller die Tätigkeiten sind, desto größer ist der Freiraum und der Verantwortungsbereich bzw. Einfluss der Mitarbeiterin. Und desto größer sind dementsprechend auch die Auswirkungen von Verhalten wie „Dienst nach Vorschrift“. Um es pointiert zu formulieren: Weisungsbefugnis auszuüben und auf nebenwirkungsfreie Umsetzung zu hoffen, ist oft eher ein Akt der Verzweiflung.

Die Grundannahme „jede führt sich selbst in voller Verantwortung“ gesteht den Mitarbeiterinnen den Freiraum zu, für sich selbst zu entscheiden, wie sie mit der jeweiligen Situation umgehen. Sie werden damit automatisch auch in die Verantwortung für ihr eigenes Verhalten genommen.

Das bedeutet natürlich nicht, dass Anarchie einziehen wird, im Gegenteil. Ein guter Ansatz ist es, wenn Führungskraft und Teammitglieder ein gemeinsames Verständnis entwickeln, welche Themen oder Arbeitsbereiche in welcher Delegationsstufe bearbeitet werden und damit Transparenz und Verantwortung bei allen Beteiligten zu stärken. Für eine konkrete Umsetzung bietet sich das Delegation Board aus dem Ansatz Management 3.0 an.

Menschen haben typischerweise ein sehr gutes Gespür dafür, wie sie von ihrem Gegenüber gesehen werden. Selbst wenn die Führungskraft es nicht formal ausspricht, werden Projektmitarbeiterinnen es spüren, ob sie persönlich bewertet und in ihrem Verantwortung beschnitten werden oder ob ihre Intentionen unabhängig von den Ergebnissen gewürdigt und sie in ihrer Verantwortung wahrgenommen werden.

Grundannahmen sind für Menschen und Organisationen das Phänomen, dass sich am nachhaltigsten (wenn auch nicht am schnellsten) auf Ergebnisse auswirkt.

Wie lassen sich existierende Grundannahmen verändern und neue implementieren? Die Schlüssel sind Reflexion und Bewusstsein. Den eigenen Grundannahmen auf die Schliche zu kommen, ist keine leichte Aufgabe. Einige Fragestellungen:

Was bringt mich zu dieser Überzeugung? Woher weiß ich das?
Welche anderen Grundannahmen könnte es geben?
Was würde sich in dieser Situation verändern, wenn ich die o.g. Grundannahmen „jede tut ihr Bestes“ und „jede führt sich selbst in voller Verantwortung“ wirklich annehmen würde?
Wozu dient mir meine Überzeugung, was ist der Nutzen?
Wer wäre ich ohne die Grundannahme?
Was wäre, wenn genau das Gegenteil wahr wäre?

Messpunkte: wie gut funktioniert der Umgang mit den Veränderungen?

Wer sich mit Projektmanagement beschäftigt, lernt früher oder später (meistens früher) das magische Dreieck kennen: Zeit, Kosten und Leistung (inkl. Qualität).

Selbstverständlich lässt sich entlang dieser Dimensionen messen, inwieweit das Projektziel erreicht wird, also

Zeit: Wie gut liegt das Projekt im Zeitplan? Wird das das Projektziel zum geplanten Endtermin erreicht?
Kosten: Wie sieht es mit den entstandenen Kosten aus? Wird das Projektziel innerhalb des geplanten Budgetrahmens erreicht?
Leistung / Qualität: Wie sieht es mit dem Erledigungsfortschritt aus? Kann in dem Projekt die geplante Leistung in der geplanten Qualität geliefert werden?

Das funktioniert genau dann sehr gut, wenn diese Dimensionen fixiert und stabil sind. Oft ist das aber nicht der Fall, etwa weil es weitere oder andere Anforderungen gibt, oder weil es andere Veränderungen gibt, die sich auf das Projekt auswirken. Und es geht ja auch darum zu messen, wie gut im Projekt mit Veränderungen umgegangen wird.

Es gibt drei grundlegende Ansätze, die es zu verfolgen lohnt. Der erste bezieht sich auf den eigentlichen Sinn und Nutzen des Projekts, das WOZU. Wie praktisch, dass wir uns dazu schon weiter oben Gedanken gemacht haben, was das ist und wie wir das messen können. Diese Messgrößen liefern eine Indikation dazu, ob wir uns in die richtige Richtung bewegen – und damit oft auch Indikationen dazu, ob das Projektziel vielleicht angepasst werden sollten.

Der zweite Ansatz bezieht sich auf die Organisation und den Fluss der zu erledigenden Arbeit. Dazu könnten sich Messgrößen eignen wie etwa Durchlaufzeiten: wenn die Bearbeitung eines Arbeitspakets angefangen wird, wie schnell ist es dann fertig? Ähnlich sieht es aus mit der Umsetzung von Veränderungen: wenn eine Anforderung sich ändert, wie schnell ist diese Änderung dann umgesetzt? Welche Maßnahmen sind möglich, damit das bei der nächsten Änderung schneller geht? Wie viele Arbeitspakete vergleichbarer Größe werden in einer Woche fertig?

Und: ist der Arbeitsprozess überhaupt transparent genug um zu wissen, wo es gerade „hängt“, wo der größte Engpass ist? Falls ja, sind Maßnahmen identifiziert worden, um diesen Engpass aufzulösen?

Explizit warnen möchte ich davor, die Auslastung der Teams als Metrik zu verwenden – jedenfalls mit dem Ziel, diese zu maximieren. Bei maximaler Auslastung haben wir nur maximal beschäftigte Teams, es werden aber kaum noch Arbeitspakete fertig – ein mitunter als widersprüchlich erlebter Zusammenhang, der sich aber mathematisch beweisen lässt. (Siehe Little’s Gesetz; dies führt z.B. zu einer der Grundpraktiken von Kanban: Limitiere die parallele Arbeit im System.)

Der dritte Ansatz bezieht sich auf das Team und die Zusammenarbeit. Die gute Zusammenarbeit im Team dient dazu, komplexe Aufgaben effizient und effektiv zu lösen, daher ist es naheliegend, eben diese die Zusammenarbeit im Blick zu halten und zu verbessern. Da die Qualität der Zusammenarbeit von vielen Faktoren abhängt, können (und müssen) hier unterschiedliche Beobachtungspunkte genutzt werden.

Selbstbewertungen der Teammitglieder: in regelmäßigen Abständen schätzen Teammitglieder ein, wie sie die Zusammenarbeit im Projekt erleben. Bewährt haben sich auch Einschätzungen zu spezifischeren Aspekten wie psychologischer Sicherheit oder Innovationskultur (z.B. „Es fällt mir leicht, im Team um Unterstützung für Probleme zu bitten.“, „Neue Ideen werden wohlwollend geprüft und ggf. weiterentwickelt oder umgesetzt.“).
Beobachtung der Zusammenarbeitskultur, z.B. Verteilung der Redezeit in Meetings, Verhältnis von problemorientierten (was ist schiefgegangen, wer ist schuld?) und lösungsorientierten (welche Optionen haben wir, was sind die nächsten Schritte?) Diskussionen.
Anzahl und Erfolgsquote von bewusst durchgeführten Experimenten, die das Team aufsetzt, beispielsweise als Ergebnis von Retrospektiven. Dabei ist es nicht das Ziel, dass alle Experimente erfolgreich sind – dann sind es ja keine Experimente mehr. Es geht um einen möglichst großen Lerneffekt, daher sollten die Experimente so gestaltet sein, dass sie im Mittel in nicht mehr als 40-60% der Fälle erfolgreich sind.
Und nicht zuletzt lassen sich auch die typischen HR-Parameter nutzen, wie Entwicklung der Krankheitstage, der Abruf der Urlaubstage, die Nutzung von Fortbildungsangeboten etc.

Extrem wichtig ist es, diese Metriken als Informationsquellen zu sehen und zu nutzen, um darauf basierend Verbesserungsideen zu entwickeln, aber nicht als ein System zur Performance-Messung. Die Mitarbeiterinnen (und auch die Führungskräfte) wissen typischerweise sehr gut, wann das passiert, und werden ihr Verhalten entsprechend ändern, so dass die Werte gut aussehen – und damit haben wir nicht nur keine verlässlichen Informationen zum tatsächlichen Zustand mehr, sondern wahrscheinlich sogar dysfunktionales Verhalten hervorgerufen. Diese Metriken sind also nur dann gute Informationsquellen, wenn sie nicht als Performance-Indikatoren genutzt werden.