Ü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.

Kosten Projektleiter, Architekten und Tester Geld?

Viele Unternehmen und Organisationen legen einen seltsamen Geiz an den Tag, wenn es um die Besetzung eines Projekt-Teams mit Projektleitern, Architekten oder Testern geht. Der Projektleiter zu teuer, die Architekten bauen doch eh nur Luftschlösser, testen kann doch auch der sowieso zu teure Projektleiter oder na gut, wir geben drei Projekten zusammen einen Tester, der aber nur ein kaltzustellender minderleistender Entwickler ohne “Bock” auf die Aufgabe ist. Ach so – und die Software spezifizieren kann auch ein Fachbereichsmitarbeiter, der so etwas noch nie gemacht hat, ein Junior-Produktmanager, gar eine Sekretärin oder ein Praktikant, die lernen das dann per Trial & Error. Vielleicht. Hoffentlich. Ganz bestimmt. Im Traum.

Ich behaupte, gute Projektleiter/Scrum Master, Architekten, Tester und Spezifikateure kosten überhaupt kein Geld, im Gegenteil.

Nanu? Aber das Unternehmen zahlt ihnen doch jeden Monat Gehalt oder Honorar, im Fall von qualifizierten externen Mitarbeitern sogar stattliche Summen! Das ist doch Geld, oder nicht?

Klar, aber meine Aussage bezieht sich auf das Ergebnis des Projekts und die Gesamtkosten, nicht auf die Einzelvergütung. Ein Projekt ist ja viel mehr wert als sein Budget, sonst würde es sich nicht lohnen. Ein Projekt, für das nicht mindestens ein Effekt in Höhe von Budget plus Projektrisiko plus angestrebte Umsatzrendite erwartet wird, braucht man gar nicht erst zu starten. (Und ja, auch “strategische” Projekte sollten sich mit einer monetär bezifferbaren Wirkungserwartung verknüpfen, Wirtschaftsunternehmen sind kein Ponyhof!)

Nun ist es so, dass Projekte, die mit unerfahrenen oder gar ungeeigneten Projektleitern oder Scrum Mastern, Spezifikateuren und Product Ownern, keinen oder nur Aushilfsarchitekten, keinen oder nur Aushilfstestern ausgestattet werden, ein fantastisch großes Risiko haben, die schillernde Statistik gescheiterter Entwicklungsanstrengungen zu bereichern.

Das Team wird nicht effizient wirksam, weil seine Mitglieder nicht an einem Strang ziehen. Es wird Ungeeignetes entwickelt oder die mangelhafte Benutzerfreundlichkeit macht das Produkt zur Totgeburt. Die fachlichen Klärungen sorgen für jede Menge Aktivität, aber lähmen den eigentlichen Fortschritt. Das Team häuft technische Schulden auf, die zukünftige Projekte zu erdrosseln drohen. Fehler werden spät gefunden und damit viel zu teuer beseitigt, oder sogar erst vom Kunden “entdeckt”, wenn das Produkt schon auf dem Markt ist.

Ergebnis: Budget mehrfach überzogen, riesige Opportunitätskosten angehäuft, Kunden und Mitarbeiter verloren, Projektziele nicht erreicht, Image beschädigt. Ein Desaster! Böses Team… oder?

Nach meiner Erfahrung kosten gescheiterte Projekte oft das Zwei- oder Dreifache des ursprünglichen Kostenansatzes, im Extremfall ein größeres Vielfaches – und damit manchmal das ganze Unternehmen.

Risiko? Da war doch was… Risikomanagement! Ich sehe es so, dass die Ausstattung von Projekten mit qualifiziertem Querschnitts-Personal eine Maßnahme des Risikomanagements ist. Man kann zwei bis fünfzig Entwickler zusammensetzen und hoffen, dass sie in endlicher Zeit das gewünschte Ergebnis produzieren werden. Das Risiko ist nur sehr, sehr groß, dass das nicht passiert und das Projekt entsprechend teuer wird – bei jeder ernstzunehmenden Projektgröße praktisch immer zu teuer.

Um das Risiko und damit die angenommenen Kosten zu senken, werden die Querschnittsfunktionen ins Projektteam aufgenommen.

Gute Projektleiter/Scrum Master sorgen für Disziplin und befördern Teambildung und Kommunikation, schaffen geeignete Rahmenbedingungen und beseitigen Hindernisse. Spezifikationsexperten und erfahrene Product Owner formulieren die Anforderungen an die zu entwickelnde Software so präzise, anschaulich und stabil, dass die Entwickler nur noch wenige Fragen dazu haben. Gute Architekten entwerfen eine Softwarestruktur und Strukturmuster, die dafür sorgen, dass das System redundanz- und fehlerarm, wartbar und leistungsfähig ist, und sie stellen sicher, dass das auch so umgesetzt wird. Tester finden Fehler so früh wie möglich, grenzen die Ursache ein und lassen beim Entwicklerteam nicht locker, bis das Problem beseitigt ist.

All diese Querschnittsaufgaben wirken im Idealfall stark multiplizierend. Ihr Nutzen vervielfacht sich über das ganze Team. Sonst würde man damit ja auch kaum die Kosten eines Projekts senken können, sondern bestenfalls die benötigte Zeit reduzieren!

Wird man sich dieses Zusammenhangs bewusst, wird klar, warum man hier nicht sinnlos sparen sollte: Jedes bisschen positiver Wirkung multipliziert sich positiv!

Es lohnt sich in jeder Hinsicht, Projekte richtig anzugehen, keine halsbrecherischen Abkürzungen zu nehmen und die ewigen Wahrheiten des Projektgeschäfts zu berücksichtigen. Dafür braucht man die richtigen Menschen in geeigneter Anzahl und man muss ihnen für ihre Arbeit Geld geben… das sich aus dem Risikobudget selbst finanziert: Risikosenkungsmaßnahmen, in diesem Fall die Arbeitsplätze und Gehälter oder Honorare der eingesetzten Personen, werden aus dem Wert des Risikos (finanzielle Auswirkung bei Eintritt mal Wahrscheinlichkeit) bezahlt.

Fiktives Beispiel: Angenommen, ohne den Top-Projektleiter besteht ein Risikowert von 250.000€. Den bisherigen Kandidaten durch einen über die Projektlaufzeit 50.000€ teureren zu ersetzen, senkt den Risikowert auf 100.000€. Die Maßnahme hat 100.000€ gespart, obwohl mehr Honorar bezahlt werden muss.

Natürlich gibt es auch hier eine Grenznutzenkurve: Zusätzliche Teammitglieder und zusätzliche Euro Vergütung (als ungefähres Maß für die Qualifikation eines Mitarbeiters) führen nicht unendlich zu linearen Verbesserungen beim Risiko. Der 2.000-Euro-pro-Tag-Berater halbiert nur selten das Projektrisiko gegenüber einem 1.000-Euro-pro-Tag-Berater. Zwanzig Tester finden in einem kleinen Projekt i.d.R. nicht doppelt so viele Fehler wie zehn. Mit hoher Wahrscheinlichkeit wird aber der positive Hebel zwischen einem 1.000-Euro-am-Tag-Berater und einem zu der jeweiligen Rolle verdonnerten Aufgabenneuling beträchtlich sein. Hier gilt es, das richtige Maß zu finden, das aber sehr oft weit unterschritten wird, in der Annahme, dass Querschnittsfunktionen in Projekten Geld kosten.

Meine Empfehlung: Bei PLs, POs, Scrum Mastern und Architekten, von denen es jeweils nur einen oder sehr wenige im Team geben kann, auf Qualifikation achten und dafür im Zweifel etwas tiefer in die Tasche greifen. Bei Testern auf ein ausgeprägtes Tester-Mindset achten und im Zweifel eher einen mehr ins Team stecken.

Warum wird das so oft falsch gemacht? Oft aus mangelndem Bewusstsein für den oben geschilderten Zusammenhang. Ebenso oft aber aus Gier. Aus Gier auf ein vermeintlich billig zu erzielendes Projektergebnis und/oder den damit verbundenen Ruhm werden wider jede Vernunft die Chancen hoch-, die Risiken heruntergespielt und die Kosten großzügig durch “Das wird schon irgendwie gehen”-Teams rechnerisch niedrig gehalten.

Gier vernebelt den Verstand.

Typologie von Software-Entwicklern – Teil 1: Die Diva

Etwas Lustiges zum Einstieg:

Diven sind tödlich für Teams. Und das, obwohl sie meist individuell gut bis sehr gut sind. Manchmal ist diese Güte allerdings auch nur eingebildet. Sie sind sich ihrer tatsächlichen oder nur gefühlten Kompetenz sehr bewusst und sehr sicher. Alle anderen im Team sind tendenziell Idioten, vor allem der Projektleiter/Scrum Master/Product Owner, von dem sich eine Diva kaum etwas sagen lässt, und wenn, dann nur unter augenverdrehendem Protest.

Diese Arroganz versteckt die – übrigens meist männliche – Diva gegenüber den anderen Team-Mitgliedern in der Regel unzureichend, meist gerade so viel, dass man ihr nicht den Vorwurf der direkten Beleidigung machen kann, aber offen genug, um systematisch zersetzend zu wirken.

In Momenten besonderer Entnervtheit zeigt die Diva ungeschminkt ihr wahres Gesicht und zieht gegen das aktuelle Opfer mit voller rhetorischer und manchmal körpersprachlicher Wucht zu Felde. Kritik an ihrem Kommunikationsstil wird bestenfalls beleidigt angehört und grundsätzlich dem Idiotentum des Sprechers zugerechnet, niemals aber eigenen Verfehlungen.

Die Diva nimmt sich in technischen Belangen allen anderen als weit voraus wahr. Das Verwenden gut abgehangener, funktionierender Technologien wird oft abfällig und herablassend kommentiert. Es müssen die allerneuesten, dem Bisherigen theoretisch weit überlegene Technologien und Konzepte sein, unterhalb von “Cutting Edge” macht es die Diva nicht. Die mit diesen Neuerungen verbundenen Kinderkrankheiten, Unvollständigkeiten und sonstigen Schwierigkeiten betrachtet die Diva als Herausforderung und manchmal beherrscht sie sie sogar aufgrund ihrer überlegenen Sachqualifikation sogar – nur leider sonst niemand im Team.

So gut wie immer wirkt sich eine Diva negativ bis sehr negativ auf das Team aus. Zurecht ständig genervte, demotivierte und sich herabgesetzt fühlende andere Team-Mitglieder, zusammenbrechende Team-Kommunikation, ständige zersetzende Negativität gegen über allem, was nicht von der Diva selbst vorgeschlagen wurde, Monopolisierung von Know-how, passiv- oder aktiv-agressives Verhalten und von der Diva durchgesetzte technische Abenteuer sind nur die Spitze des Eisbergs.

Dennoch tun sich Unternehmen sehr schwer damit, Diven aus Teams oder gleich komplett aus der Organisation zu entfernen: Sie sind ja so gut. Man ist so abhängig von ihnen, wegen des Spezialwissens. Selbst wenn die Diva ein ganzes Team mehr oder weniger lahmlegt, erste Teammitglieder um Versetzung bitten oder gar kündigen, wird die Diva kaum jemals als Ursache wahrgenommen.

Ich sage: Diven nach maximal zwei ignorierten Warnschüssen entweder auf nicht unternehmenskritische Einzelaufgaben setzen oder ihnen die Gelegenheit geben, ein anderes Unternehmen zu ruinieren, vorzugsweise einen Konkurrenten.

Nächste Folge: der Ideologe.

Wozu ein Software-Projektführungs-Blog?

Willkommen bei Daniel Tambergs Projektführungs-Blog!

Ab sofort werde ich hier in unregelmäßigen Abständen von ungefähr ein bis zwei Wochen Gedanken zu Themen der Führung von Software-Projekten aufschreiben, die mich gerade beschäftigen.

Neben Gedanken zu abstrakten Aspekten der Projektführung sammle ich hier auch sogenannte “War Stories”, lehrreiche Geschichten aus realen Projekten: meinen eigenen, gern aber auch solche aus Projekten, über die Sie mir als Leser berichten – natürlich anonymisiert, denn es geht nicht darum, hier schmutzige Wäsche zu waschen, sondern darum, aus den Geschichten und ihren Umständen etwas zu lernen.

Ich hoffe, dass sich aus diesem Blog auch ein dritter Inhalt ergibt: Hilfe bei akuten Problemen in laufenden Projekten von Ihnen, meinen Lesern.

Wenn Ihnen also eine aktuelles Problem zum Vorgehen in Ihrem Projekt auf den Nägeln brennt, schreiben Sie mir, worum es geht (ohne Nennung von Unternehmens- und Personennamen, selbst die Branche ist meist unwichtig) und ich werde schauen, ob mir selbst dazu etwas Schlaues einfällt. Wenn ja, veröffentliche ich das hier und stelle es zur Diskussion durch die anderen Leser.

Warum ich?

Ich bin ein sehr erfahrener selbständiger Berater für die Führung von klassischen “Wasserfall”- und agilen Scrum-/Kanban-Projekten. In meinen mehr als 20 Jahren Berufstätigkeit habe ich Dutzende Software-Projekte als Berater, fachlicher und technischer Software-Architekt sowie als Projektleiter, Product Owner und Scrum-Master in vielen Branchen und in der Größenordnung von 2 bis 50 Mitarbeitern betreut.

Ich würde mich freuen, Sie als wiederkehrenden Leser und ggf. Teilnehmer zu gewinnen!