Das Prinzip Verantwortung

Unter diesem Titel hat der deutsche Philosoph Hans Jonas 1979 sein Hauptwerk veröffentlicht. Es sollte eine Ethik für die technologische Zivilisation sein.

Die Komplexität der Welt nimmt zu, weil immer mehr Systeme miteinander verbunden sind und voneinander abhängen. Ein Fehler in einem System kann einen Schneeball auslösen, wie beispielsweise in Fukushima. Das Unerwartete tritt zwar zunächst in technischen Systemen auf, da diese aber die Gesellschaft bedienen, greift es auch auf soziale Gruppen über.

Ist übermässiges Vertrauen noch zu verantworten?

Ohne auf Jonas‘ Werk einzugehen, möchte ich eine Passage herauspflücken, die mir in unserem Zusammenhang hilfreich erscheint. Jonas sagt, dass man sich im Handeln eher nach dem „worst case“ anstatt nach dem „best case“ richten sollte, um der Versuchung der Abwiegelung zu entgehen.

Leider ist auch nach Tschernobyl, 9/11, Deepwater Horizon und Fukushima die „We can“-Haltung beliebt und verbreitet. Übermässiges Vertrauen zeichnet soweit jede Projektplanung aus. Je komplexer unsere Welt aber ist, desto sensibler reagiert sie auf unsere Unterlassungen und desto mehr Verantwortung muss der Einzelne übernehmen, wie ich das in meinem letzten Blogpost gefordert habe[1]. Ich kann aber meine Veranwtortung nur übernehmen, wenn alle anderen sie auch übernehmen. Geht das Projekt schief, fühle ich mich als Projektmanager nicht in der Verantwortung, wenn die anderen Stakeholders am Projekt ihre Verantwortung nicht wahrgenommen haben.

Ein Beispiel für die Verantwortung, die ich meine, liegt bei Absolventen einer Weiterbildung. Üblicherweise gehen sie zu vorgegebenen Zeiten in ein Schulzimmer und erwarten, dass ihnen dort ein Dozent etwas erklärt. Das schreiben sie dann auf und nehmen sich vor, es vor der Prüfung auswendig zu lernen. Einen Tag nach der Prüfung haben sie das Wissen wieder vergessen. Hauptsache ist jedoch, dass das Diplom bleibt.

In letzter Zeit macht ein Konzept von sich reden, das sich „Inverted Classroom“ nennt. Dabei sollten sich die Studierenden das Wissen selber aneignen. In der Klasse wird es dann nur angewendet, um zu testen, ob es überall verstanden ist. Ich habe einige Versuche unternommen, Inverted Classroom durchzuführen. Die Erfahrung hat gezeigt, dass sich die Studierenden nicht in der Verantwortung sehen, sich den Stoff selbstständig anzueignen. Wozu bezahlen sie denn Schulgeld?

Zur Übernahme der Verantwortung in unserer hochkomplexen Welt gehört für mich auch die Präsenz in den digitalen Medien. Es genügt nicht, sich ab und zu mit einem neuen Berufskollegen oder Kunden in XING zu verlinken, ohne dort auch in Gruppen und Foren aktiv zu sein. Der ständige Dialog mit Personen, die sich ebenfalls in komplexen Situationen befinden, z.B. via Twitter, gehört ebenso zur individuellen Verantwortung.

Die Ursachen des Unerwarteten kann selbstverschuldet sein

In Projekten gibt es neben den üblichen Risiken, die man kennt und sich auf ihr Eintreffen rüstet, das Unvorhersehbare. Es gibt dafür keine Beispiele, denn sobald ich ein Beispiel nenne, ist es nicht mehr unvorhersehbar. Edward Yourdon hat in seinem Buch „Himmelfahrtskommando“[2] versucht, Beispiele von Unvorhergesehenem in Projekten zu geben:

Ihre zwei besten Programmierer sind gerade in Ihr Büro marschiert, um Sie darüber zu informieren, dass sie a) heiraten werden, b) den Zeugen Jehovas beitreten und c) heute ihr letzter Tag in ihrem alten Job ist

Jetzt, wo er das gesagt hat, wäre es für Sie nicht mehr unerwartet, wenn es in Ihrem Projekt tatsächlich eintreffen würde. Sie können sich jetzt Gedanken machen, wie Sie reagieren würden, wenn Ihr Projekt tatsächlich plötzlich Ressourcen abgeben müsste.

In der Tat kann man versuchen, die Ursachen des Unerwarteten zu unterteilen in gänzlich extrinsische (der buchstäbliche „Blitz aus heiterem Himmel“) und teilweise selbstverschuldete. War z.B. Fukushima unerwartet? Das Seebeben und der darauffolgende Tsunami waren in der Tat völlig unvorhergesehen und hatten extrinsische Ursachen. Dass hingegen die Sicherheitssysteme der direkt am Ufer erbauten Atomanlagen dabei in Mitleidenschaft gezogen wurden, war durchaus selbstverschuldet. Die Betreiber machten sich offenbar zu wenig Gedanken, was an diesem Standort alles passieren konnte. Das war unverantwortlich.

Wir entscheiden (in Projekten) meistens aufgrund pragmatischer und kostenspezifischer Leitlinien und ohne weitergehende Folgeabschätzungen. In einem Projekt musste ich für einen Telefonprovider auf ein neues Voice Messaging System migrieren. Das Produkt war eben erst entwickelt worden. Die Entwicklungsabteilung, die sich weit weg vom Kunden im Ausland befand, übernahm die de facto Projektleitung, während ich bloss de jure Projektleiter und kommerzieller Partner des Kunden war. Trotz meines Protestes verkaufte der Accountmanager das System, weil er das Geschäft machen wollte.

Für mehr Handlungsfolgeabschätzungen in Projekten

Es zeigte sich jedoch, dass das System in der speziellen Kundenumgebung nicht funktionierte und der Kunde verlangte Schadenersatz vom Lieferanten, den ich vertrat. Die Entwicklungsabteilung behauptete, dass wir den Kunden nicht im Griff gehabt hätten und weigerte sich, zu zahlen. So kam es zu einem unnötigen Streit, in dessen Verlauf in der lokalen Organisation Köpfe rollten. Der unverantwortliche „We can“-Optimismus wider besseren Wissens, das Aus-dem-Wind-Schlagen jeglicher Warnungen und die Gier nach dem Geschäft haben das Unerwartete verursacht.

Wie kann man aber mittel- und langfristige Konsequenzen von Entscheidungen und Handlungen vorhersagen? Es ist klar, dass es keine Möglichkeit gibt, in die Zukunft zu sehen. Pfadabhängigkeiten engen aber mögliche Entwicklungen schon mal ein, so dass nicht einfach „alles“ passieren kann. Vergleiche mit ähnlich gelagerten Projekten können wertvolle Hinweise geben, auch wenn jedes Projekt einzigartig ist. Im Übrigen gibt es mittlerweile mächtige Entscheidungsunterstützungswerkzeuge, die helfen, mögliche Entwicklungsszenarien aufzuzeigen. Ein Beispiel sind Peter Senges systemische Archetypen. Systemisches Denken ist eine Hauptkompetenz einer verantwortungsvollen Gesellschaft in einer hochkomplexen Welt[3].

Wer nun sagt, dass Unerwartetes nicht simuliert werden könne, hat zwar recht, macht sich aber mitverantwortlich für Katastrophen, die vielleicht durch weitergehende Analysen hätten verhindert werden können.

[1]Addor, P. Muss Führung Überzeugungsarbeit leisten? Dieser Blog, 2014

[2]Yourdon, Edward. Himmelfahrtskommando. Aussichtslose IT-Projekte überleben. Verlag Moderne Industrie. 2004

[3]Senge, Peter. Die fünfte Disziplin. Kunst und Praxis der Lernenden Organisation. Klett-Cotta Verlag. 2008 und
Senge, Peter et al. Das Fieldbook zur Fünften Disziplin. Klett-Cotta Verlag. 2008

Muss Führung Überzeugungsarbeit leisten?

Kürzlich erzählte ich jemandem, dass ich an Veranstaltungen wie Forschungswerkstatt über Projektmanagement oder PMCamp teilgenommen habe. Die Person äusserte Skepsis über „solche Veranstaltungen“. Sie behauptete, es komme nur darauf an, was jemand erreiche, nicht, was jemand denke. An solchen Veranstaltungen würde nur viel Zeit verbraten, um miteinander über realitätsferne Dinge nachzudenken und einander beim Beklagen von Schwierigkeiten zu bestärken.

Der Projektalltag

Ich glaube, ich weiss, was sie meint. Sie ist eine Person, die „toughe Projekte“ in Grossbanken in ganz Europa stemmt. Unter einem „toughen Projekt“ verstehe ich meist Migrationsprojekte, in denen mehrere Subcontractors mitmischen, die alle eine erhoffte Marge verfolgen, während das zu migrierende System für das Kerngeschäft des Auftraggebers überlebensnotwendig ist. Es ist vergleichbar mit einer Herztransplantation, an der verschiedene Lieferanten und Dienstleister verdienen wollen. Jedes Mal, wenn eine Schwierigkeit auftaucht, erhebt sich unter den Parteien eine Diskussion, wie man jetzt wohl am besten vorgehen soll. Jeder versucht durchzusetzen, was ihm am wenigsten an der Marge kratzt.

„Tough“ ist dabei die Tatsache, dass wenn das System zum Stichtag nicht bereit ist oder – noch schlimmer – zwar bereit sei, aber nicht fehlerfrei funktioniert –, dass dann der Auftraggeber grosse Verluste hinnehmen muss.

In solch turbulenten Projekten vergisst man gerne alle noch so hilfreichen Erkenntnisse, die an PM-Veranstaltungen diskutiert und in schönen Bücher über Führung geschrieben wurden. Man versucht, seine Haut zu retten und die „renitenten“ Projektmitarbeiter zur Kooperation zu bewegen. Ob Sie in einer turbulenten Situation einem selbstherrlichen oder eher kooperativen Führungsstil folgen, hängt letztendlich nur von Ihrer Persönlichkeit ab, nicht von guten und interessanten Leitsätzen, die Sie an letzten Veranstaltung gehört haben. Und so könnte man tatsächlich zur Überzeugung gelangen, dass das zählt, was man erreicht und nicht das, was man gelesen oder gedacht hat [1]. Aber diese Meinung ist mir zu macher- und heldenhaft. Und Helden brauchen wir nicht mehr.

Man kann nicht nicht führen

Es geht also um Führung, und es führen nicht nur Projektleiter oder –manager, wenn es diese Rolle denn überhaupt gibt. Jede Person führt, wenn sie versucht, ihre Interessen und ihre Persönlichkeit anzumelden oder gar durchzusetzen. Ich glaube aber, dass man nicht nicht führen kann. Auch graue Mäuse, die die ihr zugedachte Arbeit prompt und fehlerfrei ausführen, sich sonst aber nicht bemerkbar machen, bringen das Projekt vorwärts. Sie bringen es dadurch vorwärts, dass sie die Turbulenzen nicht erhöhen und gute Arbeit abliefern, die möglichst wenig zum Rework Cycle beitragen [2].

Geht es jedoch hart auf hart, müssen sich auch die grauen Mäuse entscheiden, auf welche Seite sie sich schlagen wollen. Wenn z.B. die Policy herausgegeben wird, dass jede Person im Projekt so viele Reports und Formulare ausfüllen muss, dass sie nicht mehr substantiell arbeiten kann, muss sich die graue Maus entscheiden, ob sie das mitmachen oder doch eher die substantielle Projektarbeit leisten will. Letztendlich kann sich niemand aus der Verantwortung stehlen.

Wo liegt denn die Verantwortung?

Das bringt mich zu der Frage, ob das ultimative Sinnkriterium der Führung tatsächlich nur darin besteht, was jemand erreicht. Es ist eben nicht so, dass nur diejenigen Projektmanager erfolgreich sind, die das Projekt termin- und budgetgerecht beendet haben. Das ist ähnlich, wie in politischen Situationen. Überlegen Sie sich einmal, welche Bundeskanzler Deutschlands oder welche amerikanischen Präsidenten „gut“ waren! Selten ist einer direkt für das verantwortlich, was in seiner Amtsperiode passiert. Es war nicht Kohl, der die Wiedervereinigung „gemacht“ hat. Sie hat nur zufällig während seiner Amtszeit stattgefunden. Es ist nicht so, dass die Amerikaner dank Kennedys Motivation als erste den Mond erreicht haben. Vielmehr war seine Vision auch die Vision der meisten Amerikanern und hat sofort Resonanz ausgelöst, so dass sie Kennedys Aufforderung gerne nachgekommen sind.

Jede Führungsintervention ist eine Fluktuation, die das System zunächst einmal zu unterdrücken versucht. Das sind die Widerstände, die uns entgegenschlagen, wenn wir etwas versuchen. Sind die Widerstände eher schwach, die Fluktuation stark genug und gibt es in der Umgebung ähnliche Fluktuationen, dann können sie das System „versklaven“, d.h. zum Kippen bringen. Im Klartext heisst das: wenn eine (Führungs-)Intervention auf fruchtbaren Boden fällt und natürlich dediziert genug vorangetrieben wurde, kann sie Erfolg haben. Damit sie aber Erfolg hat, braucht es ein Publikum, welches die Intervention akzeptiert und unterstützt. Fehlt das Publikum, kann kein Mensch etwas erreichen.

Verantwortung haben in erster Linie die Individuen der Community

Damit möchte ich die Verantwortung auf alle Projektteilnehmer verteilen. Ich fühle mich nie allein verantwortlich, weder für Erfolg noch für Misserfolg. Ich reisse gerne etwas an oder stelle Ideen zur Diskussion. Wenn ich aber zu wenig oder keine Unterstützung habe, sehe ich nicht ein, weshalb ich jemandem etwas aufzwingen sollte. Ich will gar keinen Erfolg haben, wenn er nur dadurch zustande kam, dass ich andere gegen ihre anfängliche Meinung überzeugen musste. Beispielsweise fühle ich mich für eine Terminüberschreitung nicht verantwortlich, wenn ich mir als Projektmanager eines Auftragnehmers Mühe gebe, den Termin zu halten, der Auftraggeber aber verzögert, weil er das Gefühl hat, dass die Qualität nicht stimmt.

Sicher sind einige Leser der Meinung, dass die Fähigkeit, andere zu überzeugen, ein wesentlicher Führungsbestandteil ist. Das gehört aber eher zu der Vorstellung „Hundert Mann und ein Befehl“, also ein Chef, der genau weiss, was er will und 100 Mitarbeiter, die sich vom Chef überzeugen lassen wollen. Das passt aber nicht zu Nils Pflägings dynamikresistenter Organisation, die ich im letzten Blogartikel diskutiert habe. Dort gibt es keine Chefs, die überzeugen müssen. Es gibt nur Teams hochmotivierter Mitarbeiter. Allenfalls gibt es in einem Team informelle Führer, die stets gute Ideen haben und diese manchmal etwas vorwitzig anbieten.

Ich erwarte von meinen Mitmenschen, dass sich selber eine Meinung bilden und nicht warten, bis ein Fürsprecher oder Visionär ihnen sagt, was Sache ist. Ich erwarte auch, dass jemand, der nicht gleich versteht, worum es geht, sich selber schlau macht. Mit den heute verfügbaren Hilfsmitteln im Web gibt es keine Hürden mehr.  Wer seiner Verantwortung bewusst ist, braucht keine externe Überzeugung, sondern kann sich selber eine bilden. Er stellt seine Überzeugung entweder zur Disposition oder im Dienst an der Sache bewusst hinter diejenige eines anderen.

[1] Daher empfehle ich, sich für 10% der Präsenz zurück zu ziehen (ca. einen halben Tag pro Woche) und über die Projektsituation und das, was sie mit einem macht, nachzudenken. Es genügt nicht, wenn man das beim Einschlafen tut, auch wenn man dabei auf mehr als 4 Stunden pro Woche kommt. Man muss sich während der Arbeitszeit, bewusst und intentional ausklinken, mal zusammen mit anderen vom Projekt, mal mit einem Coach, der genügend Abstand zum Projekt hat.

[2] Lancy, Peter. Development Inefficiencies – Managing The “Rework Cycle” in Complex Projects. ACLN 55/1997