Das Problem ist nicht das Problem!

Einmal war ich bei einer Firma, die ein großes Problem hatte. Die Qualität war schlecht. Diese Firma entwickelt und vertreibt ein Softwareprodukt, und in letzter Zeit stieg die Anzahl der Fehler. Gleichzeitig sank die Kundenzufriedenheit, und es zeichnete sich bereits ab, dass einige Kunden daran dachten, zur Konkurrenz zu wechseln.

Das Problem ist nicht das Problem!

Einmal war ich bei einer Firma, die ein großes Problem hatte. Die Qualität war schlecht. Diese Firma entwickelt und vertreibt ein Softwareprodukt, und in letzter Zeit stieg die Anzahl der Fehler. Gleichzeitig sank die Kundenzufriedenheit, und es zeichnete sich bereits ab, dass einige Kunden daran dachten, zur Konkurrenz zu wechseln.

Also musste schnell gehandelt werden, und es wurde sofort eine Taskforce aus Managern und externen Beratern gebildet, die sich des Themas annahmen. Sie erarbeiteten eine Qualitätsinitiative, deren erster Schritt in der Schulung der Mitarbeiter bestand. Jeder Softwareentwickler und jeder Tester musste an einem speziell entwickelten Training teilnehmen, in dem ihnen erklärt wurde, warum Qualität so wichtig für das Unternehmen ist. Parallel erarbeitete die Marketingabteilung eine interne Kampagne, so dass wenig später in jeder Kaffeeküche und in jedem Meetingraum Poster hingen, auf denen Sprüche wie „Do it right the first time!“ oder „Never compromise quality!“ zu lesen waren.

Die Ergebnisse waren... ernüchternd. Paradoxerweise stieg in der Folge die Anzahl der Fehler, die Beschwerden der Kunden nahmen noch weiter zu, und immer mehr Kunden kündigten ihre Lizenzen. Die Taskforce traf sich zu einer Krisensitzung, um das Schulungsprogramm zu verbessern und auszuweiten. Offensichtlich hatten es die Mitarbeiter noch nicht richtig kapiert...

Verstehen

Diese kleine Geschichte demonstriert eines der größten Probleme, das wir in der Wissensarbeit haben: Ein Mangel an Verstehen! Wenn es darum geht, Probleme zu lösen, gibt es in der Praxis ein fürchterliches Durcheinander aus Symptomen eines Problems, tiefer liegenden Ursachen und möglichen Lösungen.

Trommeln sie einmal ein Team zusammen, um über ein Problem zu sprechen und bitten Sie jedes Teammitglied, einen Zettel zu schreiben zum Thema: „Was genau ist das Problem?“ Sie können sicher sein, dass auf einigen Zetteln „Wir brauchen mehr X“, oder „Wir müssen aufhören mit Y“ steht.

Dies sind mögliche Lösungen – und vielleicht sind sie sogar sinnvoll. Aber im ersten Schritt tun wir gut daran, das eigentliche Problem etwas genauer zu verstehen. Solange wir dies nicht tun, werden wir oft so enden wie die Taskforce in unserem Beispiel: Im Besten Fall bleibt das Problem bestehen, aber oft werden wir das Problem noch verschärfen.

Annahmen überprüfen

Sehen wir uns das Szenario noch einmal etwas genauer an: Ausgangspunkt der ganzen Initiative waren zwei Beobachtungen: 1) Es wurden mehr Fehler gemessen als vorher, und 2) Die Kundenzufriedenheit sank. Was die Taskforce nun getan hat, ist im Englischen unter dem Begriff „Jumping to conclusions“ bekannt. Dies ist vergleichbar mit einer Gruppe von Menschen, die in einem Ruderboot sitzen und merken, dass ihre Füße immer nasser werden. Nun schnappen sie sich Töpfe und Becher und fangen an, das Wasser aus dem Boot zu schöpfen. Das ist vielleicht sinnvoll, wenn Regen der Grund für die nassen Füße ist. Aber was, wenn das Boot ein Leck hat? Wäre es dann nicht besser, erst einmal das Leck zu finden und abzudichten?

Die Maßnahmen der Taskfoce implizieren mehrere Annahmen:

Annahme 1: Die Messungen belegen, dass es tatsächlich mehr Fehler gibt als vorher. Aber es kann ebenso gut sein, dass plötzlich mehr Fehler gemessen werden, weil sich das Messverfahren oder die Defintion von „Fehler“ geändert haben.

Annahme 2: Es gibt einen kausalen Zusammenhang zwischen mehr (gemessenen) Fehlern und sinkender Kundenzufriedenheit. Auch diese Annahme muss keinesfalls stimmen. Es könnte nämlich auch sein, dass die Kunden aus einem ganz anderen Grund unzufrieden sind, etwa weil sich das Interface der Software geändert hat und viele Funktionen jetzt nur noch umständlich zu erreichen sind; oder weil gerade der Kundenservice nach Asien ausgelagert wurde und die Kunden nun sehr lange warten müssen, bis ihre Fragen beantwortet werden.

Annahme 3: Die Entwickler und Tester liefern das Produkt in schlechter Qualität aus, weil ihnen die Qualität nicht wichtig ist bzw. weil sie nicht verstehen, warum die Qualität wichtig für das Unternehmen ist. Auch hier gibt es aber andere Möglichkeiten: Vielleicht gibt es keine gemeinsame Vorstellung, was Qualität in diesem Unternehmen überhaupt bedeutet. Oder vielleicht fehlte schlichtweg die Zeit, um für die nötige Qualität zu sorgen.

Das wirkliche Problem verstehen

Die Maßnahmen, die ergriffen wurden, sind durchaus sinnvoll - wenn alle drei Annahmen (und einige weitere) zutreffen. Wenn man jedoch direkt mit der Umsetzung der Maßnahmen beginnt, ohne vorher die Annahmen zu evaluieren, dann gleicht die Initiative einer Lotterie. Deshalb ist es so wichtig, dass wir uns die nötige Zeit nehmen und mit geeigneten Modellen (z. B. A3 Thinking oder die 5 Phasen einer agilen Retrospektive) arbeiten, um erst einmal zu verstehen, was wirklich das Problem ist. Und meiner Erfahrung nach gilt: Das Problem ist nicht das Problem!

Gemeint ist, dass wir im ersten Moment fast immer etwas für das Problem halten, das sich bei genauerem Hinsehen als zweitrangig entpuppt. Um sich dem wirklichen Problem zu nähern, brauchen wir erst einmal unterschiedliche Hypothesen, was wirklich der Kern des Problems ist, auch wenn sie uns erst mal abwegig erscheinen (denn wir meinen ja schon zu wissen, was das Problem ist). Hierfür finde ich die „Rule of Three“ hilfreich, die von Jerry Weinberg stammt und sinngemäß lautet: „Wenn dir nicht mindestens drei unterschiedliche Gründe für etwas einfallen, dann hast du noch nicht genug nachgedacht.“

Das System verändern

Um die Geschichte vom Anfang zu Ende zu erzählen: Die Unzufriedenheit der Kunden lag tatsächlich in der steigenden Anzahl der Fehler begründet. Annahmen 1) und 2) stimmten also. Aber in ihrer Annahme 3) hatte sich die Taskforce fundamental geirrt! Den Entwicklern und Testern war vollkommen klar, wie wichtig Qualität ist. Ihnen war nicht nur bewusst, dass sie Software auslieferten, die ihren eigenen Qualitätsansprüchen nicht genügte, sondern dies war ihnen auch sichtbar unangenehm.

Warum taten sie es dennoch? Weil sie immer wieder unrealistische Deadlines für die nächsten Releases vorgegeben bekamen und der Scope unter keinen Umständen reduziert werden durfte. Damit die Deadlines auch wirklich gehalten wurden, wurden individuelle Prämien ausgesetzt. Die Entwickler und Tester taten das, was wohl jeder andere auch getan hätte: Sie opferten sehenden Auges die Qualität, um Scope und Deadline halten zu können (und ihre Prämie nicht zu gefährden). Dies war keine böse Absicht, Unwissenheit oder Faulheit, sondern eine systemische Notwendigkeit.

Der eigentliche Kern

Und was änderte sich jetzt mit der Qualitätsinitiative? Nur eine Sache: Die Teams gerieten unter noch mehr Zeitdruck, weil sie kostbare Zeit in (in diesem Fall nutzlosen) Qualitätsschulungen sitzen mussten. Um diese Zeit wieder aufzuholen, blieb ihnen kaum etwas anderes übrig, als die Qualität noch weiter herunterzuschrauben.

Hätte die Taskforce diese Zusammenhänge besser verstanden, dann wäre sie zum eigentlichen Kern des Problems vorgestoßen: Die Art des Projektmanagements und das Bonus-System. Diese zu ändern, ist zweifellos eine große Aufgabe. Aber nur, weil eine sinnvolle Aufgabe uns zu schwierig erscheint, sollten wir uns ja nicht mit einer leichteren, aber sinnlosen Aufgabe abgeben.

Unsere Abos: für jeden Bedarf das passende Abonnement

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (3)

Guest

Yup. Ein Klassiker. Hab gerade einen ähnlichen Fall. Viel Symptombehandlung, aber keine Ursachenbeseitigung. Es werden zahlreiche Verantwortlichkeiten verteilt ohne Aufwände und Kapazitäten (genauer: Throughput) zu schätzen, dann entsprechend zu planen (und die Schätzung/Planung anhand der tatsächlichen Werte laufend zu korrigieren). Zum Erstaunen des Managements kommt trotz Pareto nicht 80% Ergebnis raus, wenn jeder Einzelne jede seiner Verantwortlichkeiten nur zu 20% erfüllen kann.

 

Guest

Die beschriebene Situation kommt mir sehr bekannt vor. Vor allem viele Führungskräfte halten es gar nicht für sinnvoll, sich mit dem Problem zu beschäftigen – sie sind ‚lösungsorientiert’. Außerdem kann man sich im Unternehmen nur mit Lösungen profilieren, nicht mit einer guten Problemanalyse. Ob eine Lösung dann sinnvoll, machbar, erfolgreich ist oder nicht stellt sich immer erst später raus und da guckt dann sowieso keiner mehr hin. Inzwischen ist die Aufmerksamkeit schon längst auf anderen (Problem-) Lösungen nach diesem Muster konzentriert. Das hat etwas mit der Kultur in einem Unternehmen zu tun.

 

Ich kann mich Herrn Lüschow nur anschließen; wie oft höre ich " ... ich will keine Probleme hören, ich will Lösungen! ..." oder auch "... Bei uns gibt es keine Probleme, sondern nur Herausforderungen. ...". Eine Frage der Führungskultur. Übrigens: Im Eingangs geschilderten Beispiele gehören die internen Manager entlassen (oder zumindest der Bonus gestrichen) und von den externen Fachleuten würde ich mein Geld zurückverlangen. ... :)