Das Thema Fehler und Fehlerkultur hat mich jüngst über mehrere Wege eingeholt: Zum Einen bei der Erstellung unseres Qualitätsmanagementtrainings für die LinkedIn Learning Projektmanagement Reihe und zum Anderen über eine Diskussion ausgelöst durch einen Blogpost von Marcus Raitner gefolgt von einigen Repliken, u.a. von Stephan List auf dem Toolblog.

Was mir gar nicht gefällt ist die Verquickung der Begriffe Fehler und Scheitern. Während ein Fehler ganz neutral lediglich ein Ergebnis darstellt, das so weder erwartet noch gewollt war, birgt Scheitern eine stark persönlich wertende Konotation: Eine negative Wertung über die Leistungserbringung und den Leistungserbringer. Insofern würde ich gerne Marcus These („Scheitern erlauben – Fehler abschaffen“) etwas provokant auf den Kopf stellen:

Fehler erlauben – Scheitern abschaffen!

Ganz klar: Es geht nicht um unnötige und fahrlässige Fehler, aber es geht um Fehlerkultur. Es geht um einen konstruktiven Umgang mit Fehlern. Aktuelles Negativbeispiel ist wieder das Dieselgate und der desaströse Umgang damit in Politik und den betroffenen Firmen.

Aber was ist dann eine Fehlerkultur? Was macht eine (positive) Fehlerkultur aus?

(1) Akzeptanz von Fehlern
Fehler passieren. Ob wir wollen oder nicht. Dafür ist unsere Welt viel zu komplex, als dass wir alles kontrollieren könnten. Es ist sinnlos das zu negieren, vielmehr sollten wir den konstruktiven Umgang mit Fehlern suchen.

(2) Keine Schulddebatten
Beim konstruktiven Umgang mit Fehlern geht es nicht um die Schuldfrage, sondern um Lösungen. Es geht nicht um willfährigen, vorauseilenden Gehorsam, der nur auf das achtet, was vermeintlich erwartet wird, sondern um eine ehrliche und sachliche Auseinandersetzung.

(3) Transparenz
Wir brauchen selbstverständlich im Team Transparenz über unsere Fehler und Probleme. Das ist natürlich nur möglich, wenn niemand negative Konsequenzen aus seiner Ehrlichlkeit fürchten muss. Hier schließt sich der Kreis zur Schulddebatte. Es geht eben nicht um Fingerpointing auf Personen, sondern um Sachlichkeit.

(4) Fehlervermeidung kein Selbstzweck
Natürlich wollen wir keine unnötigen Fehler, aber Fehlervermeidung darf auch nicht zur Selbstzensur werden. Wir brauchen Handlungs- und Experimentierfreiräume um Lernen zu können und voran zu kommen. Das Negativbeispiel hier ist der Sprachenschüler, der seinen Mund nicht aufkriegt aus Angst einen Fehler zu machen und damit grandios an seinem Ziel – der Kommunikation – scheitert (upps, jetzt habe ich selbst von Scheitern gesprochen), statt mit Händen und Füßen zu kommunizieren und sein eigentliches Ziel zu erreichen. Die Fehlervermeidung an sich ist nicht das Ziel, sondern (in diesem Fall) die Kommunikation, aber das wird mitunter vergessen.

Wir brauchen also einen entspannteren Umgang mit Fehlern, aber keinen leichtfertigen, einen sachlichen und ganz bewussten.

Und auf die Energieverschwendung für Eitelkeiten und Schulddebatten können wir im Sinne des Teams gerne verzichten.

An dieser Stelle KEINE Leseempfehlung, denn man kann mir Befangenheit unterstellen. Gerade frisch erschienen ist das Buchprojekt „TurnaroundPM“ (Amazon Affiliate Link) von Roger Dannenhauer, Torsten J. Koerting und Michael Merkwitza. Es ist ein ganz besonderes Buch, dass dem VisualPM gefällt, aber sicher nicht jedermanns Geschmack trifft (siehe Thomas Mathoi´s Rezension).

Meine Befangenheit bitte ich zu entschuldigen, aber nachdem mich die drei Autoren zum Kreis ihrer Co-Autoren zählen (ich würde uns aber eher als Impulsgeber und Sparring-Partner bezeichnen), will ich mich in Zurückhaltung üben.

Das Buch ist zweifelsohne ein Hingucker, das inspiriert – auch wenn es beispielsweise Thomas etwas „too much“ ist. Bemerkenswert ist vor allem seine Entstehungsgeschichte, die das Modell des Buchprojekts „Business Modell Generation“ (Amazon Affiliate Link) von Alex Osterwalder auf das Thema Projektmanagement überträgt. Die Autoren haben dabei eigens in einem Internet-Hub und zahlreichen Workshops versucht nicht im eigenen Saft zu schmoren, sondern kolloborative Prozesse zu nutzen, um  zum Ziel zu kommen.  Für jemanden wie mich, der ebenfalls mit kolloborativen Prozessen (z.B. auf openPM experimentiert) und sich mit ähnlichen Inhalten auseinandersetzt (der zentrale Project Square des Turnaround-Hubs entstand parallel zum openPM-Canvas und die beiden Konzepte sind keine Konkurrenten, sondern basieren auf ähnlichen Ideen und wir haben sie gemeinschaftlich diskutiert und unsere Erfahrungen ausgetauscht) ein sehr spannendes Unterfangen.

Zu den Inhalten des TurnaroundPM:

TurnaroundPM beschäftigt sich mit Projekten, die zu Scheitern drohen und versucht aufzuzeigen, wie man (u.a. mit der richtigen Geisteshaltung) sich solchen Projekten nähern kann. Zentrales Werkzeug dafür ist der Project Square – ein PM-Canvas –  die visuelle Reduktion eines Projektes auf seine elementaren Bestandteile.

Der Turnaround-Prozess selbst wird in verschiedene Phasen gegliedert:

1. Erkennen
2. Analyse
3. Stabilisierung
4. Transformation
5. Nachhaltigkeit

Viel mehr sei an dieser Stelle nicht verraten – wie gesagt: ich bin befangen – aber vielleicht konnte ich etwas die Neugier wecken.

Weiterführende Links:

• Der Turnaround-Hub
• Mein Bericht von einem Turnaround-Workshop
• openPM-Canvas und Project Square

Die Betrachtung von Erfolg und Scheitern von Projekten wurde auf dem PM-Camp in Stuttgart auf die Meta-Ebene gehoben (hier in der Session-Doku auf openPM oder hier auf schlossBlog).

Die erste Konsequenz aus dieser Diskussion lautet ganz banal:

Scheitern gehört dazu. Scheitern ist ganz normal, auch wenn uns Gott und die Welt etwas anderes erzählen wollen. Die Studien von Gartner & Co haben es schon immer gesagt, aber wir wollten es einfach nicht wahr haben und haben das Stigma des Scheiterns gepflegt.

Ich würde sogar noch weiter gehen und die folgende These aufstellen:

In Projekten zeigt sich die Fähigkeit einer Organisation zur Veränderung und Selbsterneuerung.

Das Scheitern einzelner Projekte stellt lediglich die Lernkurve in einer solchen organisatorischen Entwicklung dar und ist unumgänglicher Bestandteil.

Kritisch wird es aber, wenn eine Organisation oder Gesellschaft gar nicht mehr in der Lage ist Projekte erfolgreich durchzuführen. Nicht das Scheitern ist zu verurteilen, sondern das Ignorieren des Scheiterns. Nicht das Scheitern des Euro-Hawk-Debakels ist zu verurteilen, sondern dass die Notbremse erst (geschätzt) mehr als ein Jahr nach dem Bekanntwerdens gezogen wird. Natürlich ist der Verlauf von BER desaströs, aber es hat erst den alten Haudegen Mehdorn gebraucht um triviales PM-Turnaround-Management zu starten, Know-How zu sichern, Risiken z.B. durch eine gestaffelte Inbetriebsetzung zu minimieren, fatale Terminaussagen zu kippen und jenseits eines reinen Rechtfertigungsdenkens die Projektarbeit wieder fortzusetzen.

Angesichts des heutigen Umgangs mit Großprojekten stellt sich berechtigt die Frage, wie weit die bundesdeutsche Gesellschaft noch diese Fähigkeit zur Veränderung und Selbsterneuerung besitzt.

Ein weiterer wichtiger Impuls aus dieser Sicht auf das Scheitern von Projekten ergibt sich für die Business Case-Betrachtung: Wie weit macht die heute übliche Praxis Business Cases für Projekte zu berechnen noch Sinn? Wenn wir die hohe Quote des Scheiterns berücksichtigen, ist nahezu jede Business Case-Betrachtung, die wir kennen vollkommen utopisch. Ich habe auch kein Patentrezept hierfür, aber wir brauchen diese Selbsterkenntnis, wenn wir uns mit den entsprechenden Modellrechnungen beschäftigen.

Der im voranstehenden Beitrag zitierte Gunter Dueck beziffert die Erfolgswahrscheinlichkeit von Innovationsprojekten bei 5% und unter optimalen Umständen, wenn entsprechende Investoren mit den erforderlichen Managementfähigkeiten vorhanden sind auf 11%.  Venture Capitalists berücksichtigen solche Zahlen in ihren Kalkulationen, d.h. sie gehen davon aus, dass von 10 Investitionen vielleicht nur eine fliegt, aber diese muss dann auch die Kosten der anderen decken. Übertragen auf das ganz normale Projektmanagement in Organisationen, heißt dass, dass der Business Case sich eben nur über alle Projekte und i.d.R. nicht für ein einzelnes Projekt rechnet, aber wie lösen wir die Wirtschaftlichkeitsbetrachtung vom einzelnen Projekt und heben sie auf die Ebene des Portfolios?

Bleiben wir noch einen Augenblick bei Dueck und dem Thema Management-Fähigkeit: Dueck rechnet gnadenlos mit den Alibi-Management-Funktionen in (zumeist Großunternehmen) ab. Und fordert eine Abkehr von einem solchen Management. Sein Antwort-Ansatz geht Richtung agilem (Projekt-)Management. Diese Sicht teile ich nur mit Einschränkungen. Ich sehe durchaus weiterhin eine Berechtigung von klassischen PM-Ansätzen (neben agilen Methoden), sofern sie sich von den von Dueck zu Recht kritisierten Management-Attitüden verabschieden. Weshalb ich agile Ansätze nicht für die alleinige Lösungsmöglichkeit halte liegt zum Einen daran, dass auch agile Methoden eigene Attitüden mitbringen (können) und zum anderen, dass sich nicht jedes Problem in die im Agilen beschriebenen Scheiben schneiden lässt –  es gibt auch Elefanten, die tot sind, wenn man sie in Scheiben schneidet.

Für den von Dueck kritisierten Management-Begriff sollten wir auch im PM keinen Platz mehr lassen. Die Lösung würde ich aber nicht rein im Agilen suchen, sondern in einem anderen Buch Duecks: Professionelle Intelligenz (Amazon Affiliate Link) könnte der Schlüssel sein. Wir brauchen eine Professionalisierung und gesunden Menschenverstand statt eines Rechtfertigungsmanagements um Veränderungsprozesse zu bewerkstelligen und auch um vielleicht in dem einen oder anderen Projekt mehr erfolgreich zu sein.

Und wieder einmal geht es um Erfolg und Scheitern von Projekten, aber diesmal nicht auf Ebene des einzelnen Projekts, sondern auf der Meta-Ebene.

Den mit Abstand inspirierendsten  Impuls zum Thema habe ich in der aktuellen Session Dokumentation zum PM Camp Stuttgart gefunden: Vermutlich zurückgehend auf Eberhard Huber, wird dort der Projekterfolg nicht aus Sicht des Projekts, sondern in einer Meta-Perspektive diskutiert (Doku auf openPM):

 Viele Projekte sind ggf. nur Teilschritte eines größeren Veränderungsvorgangs (vgl. Portfoliomanagement). Möglicherweise ist in einer Sequenz von Projekten ein scheinbarer Misserfolg nötig, ggf. sind die Misserfolge nur Lernschritte auf einem größeren Weg auf dem das konkrete Projekt nur einen Teilschritt darstellt.

Die Beurteilung des Projekterfolgs erfolgt also nicht mehr auf der Ebene des einzelnen Projekts (Projektauftrag, Stakeholdererwartung, etc.), sondern im Kontext des organisatorischen Anpassungs- und Erneuerungsprozesses.

Das Scheitern vieler Projekte vor dem Hintergrund innovativer Prozesse scheint normal. Scheitern heißt lernen. Interessant scheint die Implikation auf die Business Case Betrachtung. Sind hart gerechnete Business Cases vor dem Hintergrund der hohen Rate gescheiterter Projekte überhaupt sinnvoll?

Aber trotzdem brauchen Organisationen Projekte um ihre Fähigkeit zur Selbsterneuerung und Erhaltung zu beweisen.

Wir stehen erst am Anfang einer spannenden Diskussion!

Nachdem hier schon des öfteren vom Scheitern von Projekten die Rede war, wollen wir uns diesmal positiv der Sache annähern. Den Anfang macht Judith Andresens Präsentation auf Slideshare, die sich zentral mit Projektkultur als Erfolgsfaktor auseinandersetzt. Das erinnert mich an ein lange zurückliegendes Projekt in dem ich eine zentrale Projektdatei mit dem Kennwort „Projektkultur“ geschützt habe – ich war mir sicher, dass niemand im Projekt dieses Passwort knacken würde.

Auch Robert Wiechmann hat eine Präsentation (diesmal von Nick Smith) ausgegraben, die uns sagt, dass Versagen zum Leben dazu gehört.

Dass selbst in der rosaroten agilen Welt nicht alles glänzt, beweisen lahme Scrum Implementierungen.

Aber andersherum ist schnelles Scheitern, die Erfolgsstrategie agiler Methoden, denn es erlaubt schnelles Lernen (Failure: The Road to success).

Craig Brown von Better Projects definiert, was Erfolg ist und setzt sich dabei mit Erwartungen und den gemachten Erfahrungen auseinander.

Last but not least verrät uns Sven Rimbach, wie man ein guter Projektleiter wird, nämlich nicht durch Zertifizierungen, sondern durch machen!

Wenn es um das Scheitern von Projekten geht, wird der CHAOS-Report der Standish-Group gerne zititert. Stefan Hagen fasst nun einen Artikel von Dr. Ingo Zank über den CHAOS-Report und was dahintersteckt zusammen.