Tabu: Probleme anderer Leute

Ich behaupte, dass es einer der größten Problemauslöser in Projekten und tatsächlich auch im sonstigen Leben ist, anderer Leute Probleme zu lösen.
Glauben Sie nicht? Ein paar Beispiele:

Der Kunde stellt in einem Festpreis-Projekt seine Spezifikation zu spät fertig. Das Team beginnt trotzdem schonmal mit der Implementierung, weil die vom Kunden gewünschte Deadline so eng ist. Effekt: Der Abschluss der Spezifikation verzögert sich, weil der Kunde sieht, dass es ja trotzdem vorangeht. Entwickelt das Team etwas, das er gar nicht haben wollte, kann er immer noch sagen: das war gar nicht so spezifiziert. Vielleicht entwickelt das Team auch eine hypergenerische eierlegende Wollmilchsau, um jeder potentiellen Anforderung des Kunden entsprechen zu können – wenn sie denn irgendwann kommt.

Das Projektteam hat versucht, das Problem des Kunden zu lösen, die Spezifikation nicht vor Projektbeginn fertigzustellen.

Der Freiberufler beginnt mit der Arbeit, obwohl er noch keinen Vertrag hat (“Vertrag ist irgendwo im Einkauf unterwegs. Machen Sie sich keine Sorgen.”). Effekt: Der Vertragsabschluss zieht sich, und die Verhandlungsposition der Freiberuflers über die Bedingungen des Auftrags wird schwächer und schwächer. Im Extremfall heißt es dann am Ende: “Ihre Rechnung zahle ich nicht, wir hatten doch noch gar keinen Vertrag!” Der Freiberufler muss vor Gericht ziehen und wird ggf. nur ein “marktübliches” Honorar aufgrund der offensichtlich erbrachten und vom Auftraggeber nicht gestoppten Leistung nachfordern können, das deutlich unter dem angestrebten liegt.

Der Freiberufler hat das Problem des Auftraggeber zu lösen versucht, die eigenen Prozesse nicht im Griff zu haben oder die Beauftragung nicht rechtzeitig angestoßen zu haben.

Das andere Teilteam sollte eine Schnittstelle zum Import von Daten liefern. Sie wird nicht rechtzeitig fertig. Das konsumierende Teilteam programmiert also erstmal gegen einen Mock. Die Schnittstelle ist immer noch nicht fertig. Das Team programmiert die Schnittstelle heroisch selbst, erreicht dafür aber nicht die eigenen Ziele.

Die gelieferte Datenqualität ist grauenvoll. Weil der Zulieferer der Daten so schwer greifbar ist, entwickelt das Team über Wochen einen Bereinigungsalgorithmus und hochflexible Darstellungsmechanismen.

Ein Team-Mitglied performt einfach nicht, aus welchen Gründen auch immer. Die restlichen Team-Mitglieder wollen keine Kollegenschweine sein, decken den Minderleister und arbeiten selbst eine Stunde mehr am Tag, erst über Tage, dann Wochen, dann Monate.

Die Deadline für das neue Projekt ist viel zu eng gesetzt, das Verkaufsteam sagt dem Auftraggeber trotzdem zu, die Entwickler beginnen einen “Todesmarsch” mit zehn Stunden Arbeit täglich und Wochenendarbeit, oft in dem Wissen, dass die Aufgabe dennoch nicht zu schaffen ist.

Das Management schafft es einfach nicht, auch nur grundlegende Vorgaben zur Arbeitsweise, Qualitätsanforderungen und Zielen der Software-Entwicklung zu machen. Die Teams organisieren selbständig Workshops und Seminare, um das Führungsdefizit auszugleichen. Effekt: Ein Glaubenskrieg zwischen den Teams und am Ende innerhalb der Teams geht los, ob Scrum oder Kanban, Merging oder Baselining, sind Senior-Software-Ingenieure mehr verantwortlich für ein Team-Ergebnis als “normale” Ingenieure, Cloud oder nicht… und viel Zeit und Motivation gehen verloren.

Das Management lässt die Teams in hallende Großraumbüros mit zu wenig Besprechungsräumen ziehen. Niemand kommt mehr in den Flow, die Arbeitsleistung sinkt um 50-75%. Die Entwickler behelfen sich mit Noise-Cancelling-Kopfhörern oder kommen besonders früh oder bleiben besonders spät, weil es da ruhiger ist. In den regulären Arbeitszeiten wird entweder kaum noch miteinander gesprochen, weil es ja alle stört, oder es schert sich niemand mehr um den Krach, denn es erwartet ja eh niemand mehr hohe Leistungen.

Der Abteilungsleiter trifft einfach keine Entscheidungen. Die Mitarbeiter entwickeln telephatische Kräfte um herauszufinden, was der Chef denn wohl wollen können würde und arbeiten unter Annahmen. Der Chef staucht die Mitarbeiter im Problemfall zusammen (“Das habe ich nie so entschieden!”) und streicht im Erfolgsfall die Lorbeeren ein.

Fallen Ihnen mehr Beispiele ein?

Mein Tipp: Lösen Sie nicht anderer Leute Probleme bzw. nehmen sie nicht anderen ihre Verantwortung ab. Weisen Sie den Verantwortlichen auf sein Problem hin und bieten sie die Hilfe an, die Sie im Rahmen Ihrer Fähigkeiten, Möglichkeiten und der eigenen Verantwortung leisten können.

 

Binsenweisheiten und Ewige Wahrheiten (Teil 1)

Zu meinem Posting “Binsenweisheiten – It’s simple, but not easy!” kam mir der Gedanke, dass es interessant wäre, reale oder vermeintliche Binsenweisheiten einmal aufzulisten, weitere von den Lesern dieses Blogs zu sammeln und zu diskutieren, wie “binsig” oder “ewig” sie denn nun wirklich sind.

Hier ist also meine absichtlich provokativ unvollständige Liste. Ich bitte um Ergänzungsvorschläge im Kommentarbereich:

  1. Die Geschwindigkeit eines geeigneten Teamaufbaus hängt mindestens von der Verfügbarkeit von Mitarbeitern der benötigten Qualifikation, der Verfügbarkeit von Arbeitsmitteln und der Parallelisierbarkeit der Aufgaben ab.
  2. Verantwortung ist nicht teilbar – entweder man ist ganz verantwortlich oder nicht verantwortlich (siehe “Über Verantwortung (Teil 1)“).
  3. Die Behebung eines spät gefundenen Software-Bugs kostet exponentiell mehr, als die eines früh gefundenen.
  4. Menschen arbeiten nicht schneller, wenn sie Angst haben.
  5. Änderungen gerade in Entwicklung befindlicher Anforderungen kosten zusätzliches Geld, manchmal viel Geld.
  6. Auch externe Berater sind Menschen mit Menschenwürde, Bedürfnissen, Privatleben, Stärken und Schwächen.
  7. Einem verspäteten Projekt mehr Mitarbeiter hinzuzufügen, macht es noch später.
  8. Nur was Du misst, kannst Du steuern.
  9. Umsatz ist nicht Gewinn.
  10. Wenn die Entwicklung eines Features mehr kostet als es einbringt, sollte man es nicht entwickeln.

Fallen Ihnen weitere ein? Widersprechen Sie einer der obigen vermeintlichen Binsenweisheiten? Was ist Ihre Erfahrung mit dem eigenen Befolgen solcher Grundregeln?

Hinterm Horizont geht’s manchmal nicht weiter

Im Jahr 2010 machte ich mit meiner Familie eine lange Reise nach Vancouver Island vor der Westküste Kanadas. Im fantastischen Strathcona Provincial Park unternahmen wir mit einer befreundeten Familie von einem Campingplatz am Buttle Lake aus eine Wanderung auf dem Flower Ridge Trail, der auf einem schneebedeckten Gipfel mit grandioser Aussicht über die ganze Insel enden sollte.

Stunde um Stunde liefen wir steil bergauf… und immer wieder hatten wir den Eindruck, hinter dem vor uns liegenden Buckel müsse nun endlich der ersehnte Gipfel liegen. Wir motivierten die Kinder (“Kommt, nur noch bis dort hinten!”) und uns selbst, die Gedanken wanderten zu den Vorräten, die dem Gipfelschmaus zum Opfer fallen sollten und wir korrigierten noch einmal den Sitz der Rucksäcke, um voller Elan diese vermeintlich letzte Anhöhe zu erklimmen.

Aber Pustekuchen. Mal um Mal stellte sich heraus, dass dahinter nur einfach der nächste, vielleicht sogar noch steilere Buckel wartete. Nach dem dritten oder vierten Effekt dieser Art, fingen wir an zu lachen und Witze darüber zu machen, während die Kinder langsam nölig wurden. Bei einer Rast an einem kleinen Teich, den nächsten Höhenrücken vor uns, hatte eines der Kinder einen hysterischen Anfall.

Wir überwanden schließlich weitere drei Bergschultern, bis wir aufgrund der fortgeschrittenen Zeit auf einer Art “Untergipfel” beschlossen, den höchsten Punkt unserer Wanderung erreicht zu haben und uns nach ausführlichem Picknick an den Abstieg machten.

Diese Art von Effekt nennt man “Receding Horizon Problem”, das Problem des zurückweichenden Horizonts.

Immer wieder scheint das Ergebnis, das Ziel, in Reichweite zu liegen, aber beim nächsten Überprüfen der eigenen Position stellen wir fest, dass es wieder weiter von uns fortgerückt ist – in wiederum scheinbare Reichweite. Wie Odysseus’ Sirenen lockt uns das wegeilende Ziel weiter, immer weiter. “Nur noch ein kleines Stückchen, noch eine überschaubare Anstrengung, bald sind wir da und dann löst sich alles in Zufriedenheit und Glückseligkeit auf.”

Nur dass es nicht so ist. Wir investieren immer mehr Zeit, Kraft, Geld, Emotionen und sonstige Ressourcen. Und weil die jeweils nächste Investition ja nur so klein zu sein scheint (und wir ja auch schon so viel investiert haben!), machen wir das viel zu oft bis weit hinter den “Point of No Return” hinweg.

Dieser Punkt ist der, ab dem sich eine Investition nicht mehr lohnt und jede weitere Investition den Verlust nur noch vergrößert. Der Sprint gerissen ist. Der Kollege seine abhängige Aufgabe nicht mehr schaffen kann. Das Projekt unwirtschaftlich wird. Man nicht mehr rechtzeitig nach Hause kommt. Eine Beziehung zerstört ist. Man beginnt, die Einstellung des Mitarbeiters zu bereuen. Die anderen Chancen, die man mit der gleichen Investition hätte realisieren können, zunichte sind. Der Aktienkurs endgültig abstürzt. Man pleite ist. Man unaufhaltbare (negative) Konsequenzen verursacht hat.

Aber was, wenn hinter dem nächsten Hügel tatsächlich das Ziel ist?

Sehen Sie? So fängt es an… und so hört es auf.

Besser, Sie kennen den Point of No Return, wissen immer, wo sie in Bezug auf ihn sind, und kehren davor um.

Hört sich leicht an? Nein, das ist nach all den sozialen Aspekten eine der schwierigsten Aufgaben im Management überhaupt.

Haben Sie eigene Beispiele für Receding-Horizon-Situationen? Dann würde ich mich über einen Kommentar zu diesem Eintrag freuen.

Über Verantwortung (Teil 2)

In meinen Postings “Über Verantwortung (Teil 1)” und “Verantwortungsflucht – weitere Strategien“ habe ich über die Natur von Verantwortung und Strategien geschrieben, ihr vermeintlich zu entgehen.

Aber wie stellt man ein Klima, eine “Kultur der Verantwortung” her, wie es immer so schön heißt?

Dafür gibt es aus meiner Sicht drei Bausteine (die teilweise ein bisschen binsig daherkommen, siehe “Binsenweisheiten – It’s simple, but not easy“):

1. Gemeinsames Verständnis über Verantwortung herstellen

Da vielen Menschen die Natur von Verantwortung unklar ist (komischerweise lernt man das weder in der Schule noch auf der Universität), sollte an Mitarbeiter/Team-Mitglieder klar kommuniziert werden, wie in dem Unternehmen oder dem Projekt Verantwortung verstanden wird und warum das so ist.

2. Vorbild sein (aka “Eat your own dogfood”)

Verantwortliches Handeln von den Kollegen zu fordern, es aber selbst nicht zu zeigen, wird zu Recht als Heuchelei wahrgenommen und untergräbt Vertrauen und Motivation. Zudem liefert es eine billige Ausrede im Sinne von “Du machst es ja selber nicht”.

Leben Sie also Verantwortung möglichst konsequent so vor, wie Sie es von Ihren Kollegen, Mitarbeitern und Team-Mitgliedern wünschen:

Übernehmen Sie Verantwortung.

Übernehmen Sie sie nur für Aufgaben, die sie auch tatsächlich erledigen können.

Geben Sie Ihr Bestes, ihr gerecht zu werden.

Wenn etwas schief geht, gehen Sie frühzeitig offen damit um, damit Ihnen geholfen werden, jemand anderes übernehmen oder das Vorhaben abgebrochen werden kann.

Lernen Sie aus Fehlern.

Wenn Sie erfolgreich sind, sprechen sie sachlich darüber und zeigen sie den anderen Beteiligten Wertschätzung für ihren Beitrag.

3. Konsequenzen transparent machen und konsequent ziehen

Sorgen Sie dafür, dass die Übernahme von Verantwortung Konsequenzen hat, sowohl positive als auch negative, je nach dem Grad und der Häufigkeit der Erfüllung. Sorgen Sie dafür, dass diese Konsequenzen vollständig bekannt sind – um Überraschungen bei Betroffenen zu vermeiden und Spekulationen über Konsequenzen (die in der Regel viel beängstigender ausfallen als die von Ihnen tatsächlich beabsichtigten Folgen) zu vermeiden.

Wenden sie die Konsequenzen konsequent, aber mit Augenmaß und Fairness an. Dabei ist es vor allem wichtig, dass die Konsequenzen von dem Betroffenen und seinem Umfeld als fair wahrgenommen werden. Fair kann eine Konsequenz nur sein, wenn sie alle Umstände berücksichtigt. Denn oft genug gibt es tatsächlich Umstände, die weniger beim Einzelnen als in der Organisation liegen – dann kann dem Betroffenen der Misserfolg nur bedingt angelastet werden und die Organisation muss dringend daraus lernen.

Überhaupt: Die wichtigste Konsequenz aus Fehlern ist immer Lernen!

Vor allem dafür ist die Ursachenanalyse wichtig: Gibt es einen abstellbaren Grund für das Nichterreichen des Ziels? Was müssen wir nächstes Mal besser machen?

Das Fairness-Gebot gilt natürlich auch für positive Konsequenzen. Gerade dabei ist die Wahrnehmung des Umfelds besonders wichtig, sonst entstehen Neid und bei Wiederholung der Eindruck von Lieblingswirtschaft (“unverdiente Beförderung”).

Verbieten sollten sich solche Konsequenzen, die als Strafe oder gar Rache gemeint sind (z.B. Mobbing oder öffentliches Zur-Sau-Machen) oder so gedeutet werden – sie führen nicht zu dem gewünschten Lerneffekt, sondern zu Groll beim Betroffenen und Initiative lähmender und Misstrauen schaffender Angst vor ähnlicher Behandlung bei allen anderen.

Viel besser und aus meiner Sicht einzig sinnvoll sind schützende Konsequenzen. Beispiel: Wenn ein Mitarbeiter wiederholt (!) eine übernommene Aufgabe nicht erfüllt, obwohl ihn keine höhere Gewalt daran gehindert hat oder er zur Übernahme der Aufgabe unter schlechten Bedingungen gezwungen wurde, dann ist er vielleicht (noch) nicht qualifiziert genug. Das Unternehmen, das Projekt und nicht zuletzt er selbst müssen davor geschützt werden, nochmal in eine solche Pleite zu laufen. Die sinnvolle Konsequenz wäre, den Mitarbeiter zunächst wieder Aufgaben erledigen zu lassen, die er sicher erfolgreich abschließen kann und ggf. eine Qualifizierung durchzuführen oder ihn schlicht mehr Erfahrung gewinnen zu lassen.

Im Extremfall kann eine schützende Konsequenz natürlich auch sein, sich von einem ständig die Anforderungen nicht erfüllenden Mitarbeiter zu trennen – das ist hart, aber in dem Fall oft für beide Seiten der richtige Schritt zum Schutz der wirtschaftlichen Interessen des Unternehmens, der Harmonie unter den Mitarbeitern sowie der Motivation, Gesundheit und letztlich Karriere des Mitarbeiters (bevor er/sie sich eine immer tiefere Grube gräbt).

In sehr vielen Fällen ist dem Mitarbeiter, der an seiner Verantwortung gescheitert ist, übrigens genug Konsequenz durch das Wahrnehmen des eigenen “Versagens” geschehen. Die meisten Mitarbeiter wollen ihren Job gut machen und leiden genug, wenn das nicht gelingt!
Profis gehen damit offensiv lernend um, manchen muss man in diese Richtung auf die Sprünge helfen, manche versuchen, von ihnen verursachte Probleme vor sich selbst und anderen zu verstecken oder zu leugnen – dann muss man ihnen die Augen öffnen.

 

 

 

Binsenweisheiten – It’s simple, but not easy

Viele der Dinge, die in Management-Beratungsartikeln und bestimmt auch in diesem Blog angeprangert oder empfohlen werden, erscheinen trivial.

“Mein Gott, warum muss man dazu einen Artikel schreiben – das weiß heutzutage doch nun wirklich jedes kleine Handwerkerle!”, denken und kommentieren viele der Leser sinngemäß.

Schaut man dagegen in die Realität, werden selbst die grundlegendsten Binsenweisheiten systematisch ignoriert oder kunstvoll begründet, warum sie nun gerade in diesem Fall nicht gelten sollen. Man könnte meinen, die Welt bestünde vor allem aus Ausnahmen, so häufig passiert das.

Das ist natürlich Quatsch.

Die ewigen Wahrheiten des Managements, insbesondere der Projektsteuerung und -führung gelten, wie der Name schon sagt, praktisch immer. Ignoriert werden sie zum Beispiel aus Betriebsblindheit, Selbstüberschätzung, Überforderung, falsch verstandenem Nonkonformismus, Gier, Realitätsverleugnung, Augen-zu-und-durch-Mentalität, Unwissen, Faulheit, Prokrastination oder vermeintlich nicht änderbaren äußeren Umständen.

Ein sehr sprechendes Beispiel: Ich wurde vor fast 10 Jahren zum Projektleiter eines bereits komplett vorbereiteten Großprojekts berufen, in dem ein offenbar rein rechnerisch ermittelter Teamaufbau von 40 Team-Mitgliedern innerhalb von zwei Wochen geplant war. Als ich darauf hinwies, dass so ein Teamaufbau meines Wissens nach eher unrealistisch sei, wurde das einfach “sportlich” genannt und ansonsten der Einwand ignoriert.

Es kam, wie es kommen musste:

Es gab gar keine 40 verfügbaren Kollegen, und schon gar nicht mit den benötigten Profilen. Erst tröpfelten sie, dann kamen sie in hastig zusammengekratzten Schüben, aber alles gleichzeitig zu langsam (Spezifikateure), zu schnell (Entwickler, Tester) und zu unkoordiniert. Schlüsselpersonen waren noch im Vorprojekt gebunden.

Beim Kunden gab es trotz für rechtzeitig gehaltener Ansage des Bedarfs nicht genug Platz, selbst für die viel langsamer als geplant eintreffende Mannschaft. Zwischenzeitlich musste eine Gruppe hochbezahlter Team-Mitglieder in einem überfüllten Besprechungsraum “arbeiten”.

Die initialen Aufgaben waren gar nicht so weit parallelisierbar, dass sie sinnvoll auf die tatsächlich verfügbaren neuen Team-Mitglieder hätten aufgeteilt werden können. Das halbe Team wartete wochenlang auf ein reifes Fachkonzept (es war noch ein Wasserfall-Projekt), während die Spezifikateure angesichts dieses Drucks brutale Überstunden schoben.

Die in dem Projekt eingesetzten Projektleiter und Teilprojektleiter (inkl. mir zu dem Zeitpunkt!) hatten gar keine Erfahrung mit einem so großem Team und den dafür spezifischen Herausforderungen und benötigten Führungstechniken.

Eskalationen der Probleme wurden von den Vorgesetzten zwar gehört, aber letztlich weitgehend ignoriert, nach Vogel-Strauß-Manier (“Es muss einfach gehen!”).

Dieser Effekt zusammen mit einer verblüffenden Flut weiterer, schon in der Projektvorbereitung angelegter und dann im Projektverlauf nicht mehr wirklich in den Grifff zu bekommender Fehler führte dazu, dass das Festpreis-Projekt mehr als doppelt so lang und teuer wurde wie geplant und mein Arbeitgeber erhebliche Rückstellungen bilden musste, um die Verluste auffangen zu können. Nur gut, dass er finanziell ausreichend potent war, viele andere Consulting-Unternehmen hätte ein solches Projektergebnis zerlegt.

Waren die Vorgesetzten inkompetent, unerfahren, dumm? Natürlich nicht – das waren alles kompetente, erfahrene und grundsätzlich kluge Menschen.

Der initiale Fehler, einen so krassen, nicht mit personellen, räumlichen und planerischen Ressourcen abgesicherten Teamaufbau zur Prämisse des Projekts zu machen, wurde nach meiner Einschätzung primär aus zwei Gründen gemacht:
Aus der Akquisitions-Eigendynamik heraus und aus Gier (sorry für das harte Wort) nach dem zweistelligen Projektbudget und der Beauftragungskontinuität beim Kunden.

Hinzu kam: Gerade aufgrund des Eindrucks, dass die Verantwortlichen kompetent, erfahren und klug sind, wurde die Machbarkeit nie ausreichend von den Ausführenden infrage gestellt (“sie werden schon wissen, was sie tun, und letztlich tragen ja sie die Verantwortung”).

Ähnliche reale Beispiele für das Ignorieren von “Ewigen Wahrheiten”, das zu negativen, manchmal verheerenden Folgen führte, kann ich und können Sie sicher noch Dutzende geben.

Was wäre passiert, wenn die Ewige Wahrheit, die Binsenweisheit über eine realistische Teamaufbaugeschwindigkeit und die notwendige planerische Detaillierung der benötigten Profile und ihrer Einsatzzeitpunkte berücksichtigt worden wäre?

Die Projekt-Akquisiteure (keine geringeren als ein Geschäftsbereichsleiter und ein Vorstand!) hätten innehalten und Zeit für eine haltbare Neuplanung geben müssen, und den Kunden darüber informieren, dass und wie sich das Projekt dadurch verändert.

Hätte das zu einem Verlust des Projekts geführt? Vielleicht. Vielleicht aber auch einfach nur zu einem erfolgreichen, lukrativen Projekt.

Über Verantwortung (Teil 1)

Verantwortung sollte ein lange und gut verstandenes Konzept sein. In der Realität treffe ich dennoch immer wieder auf ein grobes Missverständnis des Wesens von Verantwortung, das manchmal an surreale Diskussionen darüber erinnert, ob die Erde rund oder flach ist.

Dabei ist Unklarheit über die Verantwortlichkeiten – wer welche trägt und was das heißt – eine der größten Bremsen für funktionierende Organisationen!

Im beruflichen Kontext heißt Verantwortung zu haben, dass einem die Folgen des eigenen Tuns zugeschrieben werden und Konsequenzen nach sich ziehen.
Übernimmt man Verantwortung, akzeptiert man sowohl die Zuschreibung als auch die Konsequenzen.

Die positiven Folgen beim Erfüllen der Verantwortung können zum Beispiel sein: Lob, Anerkennung, Bewunderung, Beförderung, Gehaltserhöhung, Macht, Einfluss, Privilegien, interessantere Aufgaben, erweiterte Führungsverantwortung.

Auf der anderen Seite stehen beim Scheitern Kritik, Zurechtweisung, Schuldzuweisungen, Rufverlust, Ausgrenzung, Neid, Überforderung, Konkurrenz, Karriere-Stagnation, Degradierung, Verachtung, Positionsverlust, Abmahnung, Entlassung.

Verantwortung ist keine moralische Kategorie wie Schuld. Schuld setzt vorsätzliches oder grob fahrlässiges Verhalten voraus, Verantwortung lediglich das Annehmen eines Auftrags. Schuld ist grundsätzlich negativ, Verantwortung kann sowohl zu positiven als auch negativen Ergebnissen führen.

Im Folgenden einige Strategien, die gern angewendet werden, um (vermeintlich) Verantwortung zu entgehen.

  1. Ahnungslosigkeit: Ich wusste nicht, dass ich verantwortlich bin!
  2. Gegenseitigkeit: Machst Du mich nicht verantwortlich, mach ich Dich nicht verantwortlich!
  3. Schwarzer Peter: Ich habe die Verantwortung doch delegiert!
  4. Diffusion: Wir sind alle irgendwie verantwortlich – und deshalb ist es irgendwie keiner!
  5. Rückzieher: Ich habe gar nicht gesagt, dass ich das hinbekomme!
  6. Opfer: Die Umstände haben mich gehindert!
  7. Ablenkende Moralisierung: Ich bin gar kein schlechter Mensch! Warum wirfst Du mir das vor?
  8. Mitleid heischen: Ich bin sooooo verantwortlich, ich bin so schlecht, so ein armes Würstchen, ich habe so einen Bockmist gebaut, ich fühle mich so furchtbar wegen meiner Verfehlungen, bitte hab Mitleid mit mir… und (teil-)befreie mich von der Verantwortung.

So als Liste lesen sie sich fast lustig, oder? Schreiben Sie weitere Strategien, denen Sie schon begegnet sind, als Kommentar zu diesem Blog-Beitrag!

Natürlich werden diese Strategien nur angewendet, wenn es darum geht, den Folgen der Verantwortung für ein suboptimales Ergebnis zu entgehen. Lob nimmt jeder strahlend entgegen. Mit Verantwortung ist es ein bisschen wie mit dem Raubtierkapitalismus: Gewinne werden gern privatisiert, Verluste sozialisiert.
Zum Einheimsen von Erfolgen werden übrigens all die oben genannten Strategien umgedreht… Übung: Formulieren Sie die Punkte 1.-8. so, dass sie damit einen Erfolg für sich verbuchen oder verstärken können!

Hier die Grundregeln für Verantwortung, die ich für “ewige Wahrheiten” halte:

  1. Im direkten Verhältnis zwischen Auftraggeber und Auftragnehmer (Vorgesetzen/Mitarbeiter, Projektleiter/Team-Mitglied, PO/Scrum-Team) ist Verantwortung unteilbar. Jeder, der einen Auftrag annimmt, ist voll verantwortlich. Nimmt eine Gruppe (wie z.B. ein Scrum-Team) einen Auftrag an, ist jeder im Team gesamtverantwortlich.
  2. Verantwortung wird man nicht durch Delegation los. Reiche ich die Aufgabe oder einen Teil davon an jemand anderen weiter, bin ich meinem Auftraggeber gegenüber immer noch genauso verantwortlich! Ich habe lediglich ein neues Verantwortungsverhältnis gestartet: Das zwischen dem Delegationsempfänger und mir.
    Selbst, wenn ich keinerlei inhaltliche Arbeit mehr selbst mache (wie die meisten Manager) bin ich immer noch für die Auswahl und Führung der operativ arbeitenden Menschen und letztlich für deren Ergebnis verantwortlich.
  3. Wer einen Auftrag annimmt, darf das nur tun, wenn er ihn erfüllen kann und will. Im Zweifel sollte man vorher seinem Auftraggeber die Risiken mitteilen, die man an dem Auftrag sieht. Mit der Annahme des Auftrags wird man verantwortlich. Deshalb sollte am Beginn jeder Verantwortungsübernahme eine Prüfung stehen, ob die Voraussetzungen stimmen.
    Verantwortung kann man auch übernehmen, wenn man zu einem Auftrag “nein” sagt: Verantwortung für sich selbst!
  4. Wenn sich die Bedingungen nach dem Übernehmen der Verantwortung auf eine Weise ändern, dass der Auftrag nicht mehr innerhalb der vereinbarten Randbedingungen erfüllt werden kann, ist man verpflichtet (und berechtigt!) den Auftraggeber schnellstmöglich darüber zu informieren, ggf. neue Bedingungen für den Auftrag auszuhandeln oder den Auftrag zurückzugeben.

Im Teil 2 zum Thema “Verantwortung” bald in diesem Blog: Eine Kultur der Verantwortlichkeit entwickeln.