Wider den Kompliziertismus!

Die Welt ist ein ungeheuer komplexer Ort.

Alle Dinge interagieren ständig aufgrund physikalischer, chemischer und evolutionärer Gesetze miteinander.
Die Interaktion zwischen Menschen ist mit enormen Komplexitäten behaftet.

Zwischen Menschen aus unterschiedlichen Kulturen, Ländern, Städten, manchmal sogar Stadtteilen und ganz sicher aus unterschiedlichen sozialen Herkünften gibt es enorme Unterschiede.Jeder Mensch ist anders. Jeder Mensch hat zeitabhängige Stimmungen.

Die Systeme, die wir in IT-Projekten bauen, sind manchmal ganz einfach. Als Modelle der physisch-technischen, sozialen oder kulturellen Wirklichkeit aber oft sehr, sehr komplex.

Schon kleinste Abweichungen im Verständnis oder der Definition eines Begriffs können weitreichende Folgen in der Systemmodellierung haben. Beispiel: Die Modellierung der Ehe in einem IT-System: Nur zwischen Mann und Frau? Zwischen gleichgeschlechtlichen Partnern? Jeweils wie vielen Personen welchen Geschlechts? In welchem Mindestalter? Was sind die damit verbundenen Rechtsgüter? Was, wenn die Ehe im Ausland geschlossen wurde, wo andere Regeln gelten? Welchen Einfluss haben gemeinsame voreheliche oder aus früheren Partnerschaften stammende Kinder? Spielt die kirchliche Trauung irgendeine Rolle?

Die Welt ist komplex, keine Frage.

Was ist die angemessene Reaktion darauf?

Einige Menschen blähen ihre Einschätzung jedweder Aufgabe grundsätzlich und systematisch auf. Komplex ist für sie das Gleiche wie kompliziert. Sie vermuten und berücksichtigen vorauseilend schon einmal alle denkbaren (und im Zweifel auch nicht denkbare) technischen, organisatorischen und fachlichen Komplikationen – und schlagen am Ende noch einen Risikoaufschlag drauf.
Wenn ein Satz in einer Anforderung komplizierter oder weniger kompliziert interpretiert werden kann, wählen sie immer die kompliziertere Interpretation. Sie wählen die kompliziertesten Architekturen und Implementierungsmuster, betreiben furchtlos das Aufhäufen technischer Schuld. Aufwands- und Preisabschätzungen treiben sie per Hau-den-Lukas in die Höhe, bis die Glocke klingelt.
Provokant formuliert: Komplexität wird zur Ideologie der Kompliziertheit, zum Kompliziertismus. Alles ist irre kompliziert und kaum beherrschbar, lasst es uns noch komplizierter machen.

Warum macht jemand das? Angst, die Aufgabe zu unterschätzen. Frühere schlechte Erfahrung. Überforderung, durch die ein paar Bäume wie ein großer, dunkler Wald aussehen. Viel Feind, viel Ehr. Geldschinderei gegenüber dem Kunden. Ressourcenschinderei gegenüber dem eigenen Chef. Vorauseilende Begründung für das eigene Versagen (“ich hab ja gleich gesagt, dass das irre komplizert ist”). Aufblähen der eigenen Wichtigkeit und demonstratives Zur-Schau-Stellen kritischen Denkens.

Einfachste oder zumindest in der Regel gut beherrschte Dinge werden so mühelos zu kaum überwindbaren Hürden, zu Sorgen, zu Angstbergen, zu Problemen.

Ich bin sehr erfolgreich mit dem gegenteiligen Ansatz. Ich glaube, dass es die Aufgabe von Projektleitern, Architekten und Beratern ist, die jeweils eleganteste und damit oft einfachste Lösung zu finden.

Ich gehe dabei oft zunächst von der naivstmöglichen Annahme aus. Wie würde die einfachste Lösung aussehen?
Natürlich bleibt die Lösung dann meist nicht so einfach. Ich schaue dann, welche zusätzliche Komplexität ich unbedingt berücksichtigen muss. So wird die Lösung Schritt für Schritt komplexer, aber in einer sehr kontrollierten Weise und nur auf Basis von verifizierten Annahmen.

Jederzeit beachte ich Vereinfachungsmöglichkeiten: Welche Anforderungen sind ähnlich und können generisch behandelt werden? Wo bestehen Anforderungen nur noch aus historischen Gründen, die heute eigentlich keine Bedeutung mehr haben?
Wo kommt die Anforderung überhaupt her? Wenn es niemanden mehr gibt, der weiß, warum es eine Anforderung gibt, ist sie vielleicht obsolet.

Oder als Scum Master/Agile Coach: Muss der Prozess wirklich so aufwändig sein? Muss wirklich eine monatelange Tool-Auswahl gemacht werden oder weiß das Team eh schon, welches der Sieger sein wird? Braucht es eine Earned-Value-Analyse oder reicht ein einfaches Burndown?Braucht es wirklich ein Zehn-Mann-Team oder wird nicht alles viel einfacher, wenn man zwei Fünf-Mann-Teams bildet? Hat das Sprint Commitment für dieses Team wirklich einen Mehrwert oder performt es auch ohne optimal?
Muss wirklich in Story Points geschätzt werden oder reichen Personentage?

Das Ziel: Die ohnehin schon komplexe Welt nicht ohne Not kompliziert machen.

 

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.

Verantwortungsflucht – weitere Strategien

In meinem Posting “Über Verantwortung (Teil 1)” nenne ich eine ganze Reihe von Strategien, wie Menschen in Projekten und anderswo versuchen, sich aus ihrer Verantwortung herauszuwinden.

Seit ich den Beitrag geschrieben habe, sind mir ein paar weitere häufig verwendete Strategien bewusst geworden, Kritik über nicht erfüllte Verantwortung (vermeintlich) zu entgehen.
Die möchte ich Ihnen nicht vorenthalten:

  1. Retourkutsche: Aber Du hast das (oder etwas völlig anderes) doch auch falsch gemacht!
  2. Kindergarten: Kollege X nimmt doch seine Verantwortung auch nicht wahr!
  3. Verstecken in einer diffusen Menge: Niemand hier nimmt seine Verantwortung wahr!
  4. Ebenenwechsel: Mir gefällt Dein Ton nicht! Überhaupt: Du hast mich auf dem Kieker!
  5. Relativierung: Ja klar, das ist ja auch die Katastrophe des Jahrhunderts. Du übertreibst total! Im Verhältnis zum Bruttosozialprodukt von Brasilien sind das doch nur Peanuts.
  6. Plattes Leugnen: Ich hab doch gute Arbeit gemacht!
    Gern hilfsweise ergänzt um:

    1. Du verstehst das nur nicht.
    2. Wir haben viel gelernt.
    3. Wir hatten eine gute Zeit! (Absurd, ich weiß, aber ein reales Beispiel!)

Fallen Ihnen weitere Verantwortungsvermeidungsfluchtstrategien ein? Dann ab in einen Kommentar damit.

Zahlen mit und ohne Sinn

Kaum eine Organisation verzichtet auf das Folterinstrument namens “Reporting”.

Ein Auftraggeber außerhalb der Organisation (“Kunde”) oder innerhalb (“Manager”) verpflichtet den Auftragnehmer/Mitarbeiter dazu, über sein Handeln und den Fortschritt von Projekten regelmäßig Rechenschaft abzulegen: “Was Du nicht misst, kannst Du nicht steuern”.

Meist werden neben ein paar qualitativen Aussagen zum Stand der Dinge Key Performance Indicators (KPIs), Kurven und Statistiken gefordert. Zahlen sollen objektive Transparenz schaffen und so das Steuern erleichtern.

So weit, so gut.

Es gibt allerdings einen nahezu allgegenwärtigen Effekt, der viele Berichtende in den Wahnsinn treibt: Zahlen ohne Sinn.

  1. Es werden sehr häufig Zahlen und Statistiken angefordert, die schwer oder  aufwändig zu ermitteln sind. Entweder, weil es Quantifizierungen qualitativer Effekte sind (“Wie ist die Stimmung im Team?”) oder weil die eingesetzten Systeme die Zahlen nicht von selbst hergeben, sie also manuell gesammelt oder aus dem Vorhandenen zusammeninterpretiert werden müssen.
    Kontraproduktiver Nebeneffekt zum reinen Zeitaufwand: Schnell setzt hier ein solider Schlendrian ein, denn wenn der Berichtende schon riesige Mühe hat, die Zahlen zu besorgen, kann sicher auch niemand nachvollziehen, ob sie wirklich stimmen!
  2. Der Gegenstand des Reportings bildet gar nicht die Realität des Projekts ab.
    Beispiele: Über Epics soll berichtet werden, aber viel von dem, was die Teams tun, gehört zu keinem Epic. Die “Lines of Code per Day” sollen berichtet werden, sie haben nur praktisch keine Aussagekraft. In einem Scrum-Projekt wird die Team-Velocity verlangt, aber das Team jeden Sprint umgebaut, was für die Velocity jedes Mal einen Reset bedeutet und die Werte zwischen Sprints unvergleichbar macht.
  3. Das Management hat fast nie eine klare Idee, was es aus den Zahlen überhaupt für Steuerungsimpulse ableiten soll. Wenn KPI X nach oben oder nach unten geht, was heißt das und was macht man dann? Was sind gefährliche Grenzwerte? Was ist Rauschen, was Signal? Keine Ahnung, aber schön die Zahlen zu haben…
  4. Wenn ein Manager doch eine Idee davon hat, was er tun will, wenn sich die Zahlen in die eine oder andere Richtung bewegen, trifft er Entscheidungen oft allein auf dieser Basis (Am Tag nach dem Release: “Die Zahl der beobachteten Produkte im Shop ist nach Update der Benutzeroberfläche gesunken? Panik! Rückgängig machen!”).
    Dabei können Zahlen nur ein Indikator für Probleme sein, da sie immer eine – zum Teil grobe – Vereinfachung sind und einen qualitativen Kontext brauchen, um korrekt verstanden zu werden: Natürlich geht die Benutzung einer neu gestalteten Funktion immer erstmal zurück, bis sich die Leute daran gewöhnt haben. Die zurückgehende Team-Velocity ist auf Urlaube zurückzuführen. Das Burndown, das Story Points aus abgeschlossenen User Storys darstellt, verlässt kurz nach Beginn des Betrachtungszeitraums seinen Ideal-Korridor – weil das Team richtigerweise mit der größten, risikoreichsten Story beginnt und deshalb die Abtragung erst später, dafür aber größer als bei den anderen Storys erfolgt.

Möglichst wenige, richtig definierte, realitätsnahe, leicht ermittelbare Zahlen können ein sehr hilfreiches Instrument beim Steuern von Projekten sein – wenn klar ist, was sie einem sagen und was daraus folgt.

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