Wann immer Projekte nicht optimal laufen oder sogar grandios scheitern, schlägt die Stunde der Apologeten des bedingungslosen Glaubens an Best Practice. „Bewährte, optimale bzw. vorbildliche Methoden, Praktiken oder Vorgehensweisen im Unternehmen“ (Definition: Wikipedia) müssen her, um künftiges Ungemach abzuwenden – so die gängige Logik. Nun ist nichts einzuwenden gegen die Anwendung von bewährten Praktiken, nur eben nicht bedingungslos, blind und dogmatisch, sondern situativ, überlegt und angepasst.
Sicherlich lässt sich über den richtigen Gebrauch eines Hammers im Sinne einer Best Practice viel schreiben, aber was nützt das schon, wenn die konkrete Situation die Verwendung von Schrauben und Dübeln erfordert? Es nützt nichts und meistens schadet es sogar, weil das Hinterfragen der Anwendbarkeit der Methode auf das jeweilige Problem ausbleibt.
Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.
Paul Watzlawick
In dem banalen Beispiel ist das Problem der bedingungs- und kontextlosen Empfehlung und folglich unhinterfragten Anwendung von Best Practice sofort jedem ersichtlich. Dennoch passiert genau das in vielen Unternehmen wenn es um die Nutzung von Best Practice im Projektmanagement und konsequent weiter gedacht um die Standardisierung der Durchführung von Projekten geht. Aus der mehrmaligen erfolgreichen Anwendung eines Werkzeugs oder einer Vorgehensweise wird unter Vernachlässigung des spezifischen Kontexts per Ingenieurs-Induktion geschlossen, dass dieses Werkzeug oder diese Vorgehensweise immer nützlich sei.
Eine Meilenstein-Trendanalyse (MTA) beispielsweise ist eine feine Sache. Anstatt immer nur die aktuellen Meilensteintermine zu berichten, zeigt eine MTA Trends in der Entwicklung dieser Meilensteine und lässt so Rückschlüsse auf die Lage des Projekts zu. Dazu müssen die Meilensteintermine aber auch veränderlich sein. Das sind sie aber nicht immer. In vielen Projekten sind die Termine starr vorgegeben, beispielsweise in Form von zwei oder drei festen Releases im Jahr, aber der Umfang dafür flexibel. Natürlich kann man trotzdem eine MTA machen, nur ist diese dann eben völlig sinnfrei.
Einen schönen grafischen Ablaufplan (siehe die ArtikelserieProjektplanung 101), nicht zu kompliziert und groß, mangagementtauglich auf einer Folie darstellbar (die Schriftgröße ist ja zum Glück einstellbar), wird aber doch wohl jedes Projekt brauchen, oder? Wie die MTA kann man einen solchen Plan in jedem Projekt machen, nur variiert eben seine Aussagekraft und sein Nutzen. Besonders in agilen Projekten wird ein solcher Plan schnell zur lästigen Pflichtübung. Die Ablaufplanung in agilen Projekten ist recht trivial: Es folgen Sprint auf Sprint bis zu einem definierten Endtermin. Das spannende ist nur der Umfang der Sprints, der aber prinzipiell erst unmittelbar vor jedem Sprint festgelegt wird.
Das waren nur zwei Beispiele für die Sinnlosigkeit bedingungs- und kontextloser Anwendung von Best Practice. Man mag nun einwenden, das alles sei zwar unschön, aber schaden würde es ja auch nicht, diese Werkzeuge der Standardisierung wegen trotzdem anzuwenden. Solange das bewusst geschieht und dem Projektleiter daneben noch genügend Zeit für diejenige Aufgaben bleibt, die tatsächlich einen Unterschied machen, ist dagegen auch nichts einzuwenden.
Überarbeitete Manager beschäftigen sich mit Dingen, mit denen sie sich nicht beschäftigen sollten.
Tom de Marco
In der Praxis ist mit Best Practice und ihrer Zusammenfassung als Vorgehensmodelle allerdings fast immer ein trügerisches Heilsversprechen verbunden: Erfolgreich wird sein, wer alles nach Vorschrift umsetzt. Die Anwendung der ohne Frage guten Werkzeuge und Methoden geschieht dann meist unreflektiert und ohne den individuellen Kontext des jeweiligen Projekts zu berücksichtigen. Die Verantwortung für die passende Gestaltung des Projekts und seiner Abläufe wird so an das Vorgehensmodell und seine Sammlung an Best Practice delegiert. Es lebe die organisierte Verantwortungslosigkeit: alles ordentlich geregelt und standardisiert und trotzdem gescheitert.
Best Practice entheben den Projektleiter nicht von der Verantwortung das Projekt selbst zu gestalten. Im Gegenteil ist es gerade die kreative Umsetzung und Anpassung von Standards und die passgenaue Nutzung von Best Practice die erfolgreiches Projektmanagement ausmachen. Und manchmal passt auch keines der Werkzeuge und man muss ein neues basteln, das dann vielleicht morgen zur Best Practice erhoben wird. Projekte haben immer etwas Ungewisses und sind daher auch immer Experimente, nicht nur in Bezug auf den Projektgegenstand sondern eben auch in Bezug auf die Vorgehensweise und die eingesetzten Methoden und Werkzeuge.
I’m as proud of what we don’t do as I am of what we do.
Steve Jobs
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
19 Kommentare
Hallo Marcus,
Dein Beitrag spricht mir aus dem Herzen! Schön auf den Punkt gebracht.
Die Best-Practice-Gläubigkeit zieht sich inzwischen durch viele Lebenslagen. In meinem Bereich (IT-Service-Management) ist dies auch besonders ausgeprägt. Wir sprechen da ja von ITIL einführen, was meiner Meinung nach mit Best Practices nicht geht. Ich habe mir dazu vor geraumer meine Gedanken in einem Blogpost aufgeschrieben.
Etwas ähnliches passiert meiner Beobachtung nach mit den „agilen Methoden“. Die scheinen mir momentan der heilige Gral im Projektmanagement zu sein.
Lars Vollmer hat in seinem Buch Wrong Turn dieses und andere Probleme in Bezug auf das gedankenlose Umsetzen von Dingen, die irgendwo mal funktioniert haben, sehr gut beschrieben. Das Lesen lohnt sich.
Mich bewegt die Frage: Warum ist das so? Sind wir Menschen anfällig für einfache Rezepte? Ist es der Gedanke der Absicherung: „Wir haben alles nach Best Practices gemacht und können uns nicht erklären, warum das trotzdem schief gegangen ist“? Oder ist es Faulheit? Zu viel zu tun und wir wählen die Abkürzung? Oder können wir das wichtige nicht vom dringenden unterscheiden?
Ich persönlich tendiere ja vor allem zur Variante 2: Absicherung – was ist Dein Eindruck?
Robert
Hallo Robert, vielen Dank für Deinen Kommentar und Deine Anerkennung! Ich habe das Gefühl, dass die Best-Practice-Gläubigkeit sich direkt proportional zur Komplexität der Herausforderungen verhält. In meiner Wahrnehmung leben wir in turbulenten Zeiten mit sehr komplexen Herausforderungen und Problemstellungen. Der Mensch braucht Muster, Rituale und Patentrezepte damit er nicht über jeden Schritt nachdenken muss und das ist meistens auch gut so. Wenn nun so viel im Wandel ist, dann macht das Angst, weil noch keine adäquaten Verhaltensmuster bekannt sind. In dieser Angst ist man anfälliger für Wunderheiler und Wundermittel.
Letztlich ist der Grund meiner Meinung nach also Verunsicherung und Angst gepaart mit einer gewissen Faulheit des eigenen Denkens sowie einer Unternehmenskultur, die das Experimentieren durch einen nicht konstruktiven Umgang mit Fehlern effektiv verhindert.
Hallo zusammen,
wahrlich wichtige und richtige Gedanken zum Mythos Best Practice.
Für mich persönlich ist Best Practice das Ergebnis verzweifelter Trivialisierung. Die Begründung dazu habe ich vor ein paar Jahren in der Zeitschrift „SEM Radar“ als Artikel verfasst. Der Link zum Artikel ist hier.
http://blog-conny-dethloff.de/wp-content/uploads/2014/02/Best-Practice-ist-das-Ergebnis-verzweifelter-Trivialisierung.pdf
Aber Vorsicht. Er ist ein bisschen länger geworden.
Was man sich zusätzlich immer wieder vor Augen halten sollte, ist, dass Best Practice genau deshalb so heißt, weil Jemand vor mir dies schon einmal erfolgreich eingesetzt hat. Hetze ich dem also hinterher kann ich Denjenigen wohl bestenfalls adaptieren. Aber wo bleibt da die Einzigartigkeit und Identität, die ich mir selber zuschreibe?
Beste Grüße,
Conny
Vielen Dank für Deinen ergänzenden Kommentar und den Hinweis auf Deinen sehr ausführlichen Artikel, Conny! „Verzweifelte Trivialisierung“, das war’s was ich in meiner Antwort an Robert ausdrücken wollte ;-)
Ich habe mal versucht das weiter zu hinterfragen.
Warum glauben wir an Best- Practice – Weil wir uns absichern wollen
Warum wollen wir uns absichern – Weil die übliche Unternehmenskultur das so erwartet
Warum ist die Unternehmenskultur so – Weil wir in zweiwertiger Logik denken
Warum denken wir zweiwertig – Weil die wirkliche Komplexität nicht beherrschbar ist und andernfalls wir dieses auch zugeben müssten.
Warum könne wir es nicht zugeben – Weil das Zugeben einer solchen Unsicherheit wiederum nicht in die übliche Unternehmenskultur passt.
Wenn ich es richtig verstanden habe ist das jetzt ein Zirkelschluss und in einer reinen Hierarchie nicht auflösbar.
Aber wie vermeiden wir jetzt den unreflektierten Einsatz von Best-Practice?
Ich denke, das kann nur in gegenseitigem Vertrauen und bei einem Umgang auf Augenhöhe funktionieren. Einer Vertrauensvollen Umgebung also, die das Zugeben von Unsicherheiten mit besseren Lösungen belohnt und eben nicht bestraft. Was aus meiner Sicht Eigenschaften einer heterarchischen Struktur seine könnten.
Danke für Deine Ausführungen, Peter. Der Schlüssel liegt für mich auch im richtigen Umgang mit Komplexität bzw. eigentlich schon im Eingeständnis, dass unsere Probleme und Projekte komplex sind. Dem entgegen stehen die tradierten Unternehmensstrukturen, die stark auf Planbarkeit basieren. Das passt tatsächlich nicht. Vertrauensvoller Umgang mit Fehlern und das Akzeptieren von Unsicherheit ist daher meiner Meinung nach unerlässlich.
Huh,
der Artikel von Conny ist ein hartes Stück zum Lesen. Lohnt sich aber. Und da „neue Lösungen erdenken weh tut“, gefällt mir besonders der letzte Absatz ;-)
@Peter: Klappen die Schlüsse wirklich so gut? Oder ist das ein einfaches Modell der Realität – oder bin ich nur einfach nur naiv und glaube an das Gute?
Wie kommen wir zu einer vertrauensvollen Umgebung im Unternehmen? Ich meine in einem bestehenden.
Robert
Hallo Robert,
ja, das ist natürlich nur ein einfaches Modell von dem wie es zusammenhängen könnte. Jemand anderes wird auch ganz andere Antworten finden. Wissen kann ich es nicht. In dem Moment wo ich davon ausgehe es zu Wissen, ist es dann nicht so etwas wie wie meine eigene Best- Practice?
Wenn wir möglichst viele verschiedene solche Zusammenhänge (Modelle) nebeneinander legen und darin nach ähnlichen Kontexturen und Zirkelschlüssen suchen, müssten doch Muster erkennbar werden?
Es ist eine Ansatz, den ich für mich aus Connys Beschreibungen abgeleitet habe. Mal sehen wo es hinführt.
Peter
Hallo Peter,
guter Ansatz! Wir sind da zumindest schon weitgehend deckungsgleich!
Robert
Ich habe neulich auf dem Kongress der Best-Practice-User Group (früher PRINCE2-Verein) einen Vortrag über das Spannungsfeld zwischen PRINCE2 und Agilem wie SCRUM gehalten. Von den Leuten da hatten nur wenige Probleme mit einer MTA. Ich glaube keiner.
Wenn man aber eine machen will und die Entscheidung ob ist schon gefallen, dann ist m.E. die Best Practice immer eine gute Hilfestellung, wie man sie macht.
Nennt man das Kind nicht Best Practice sondern Standard, dann werden noch andere Dinge sichtbar. Seit Jahrzehnten höre ich immer wieder, warum man gerade aktuell keinen Standard nutzen könne. Beispiel: bei einer Migration Mainframe zu Client-Server hatten wir uns für Unix-Maschinen geeinigt, X‑Windows zu nehmen. Dann kam Apollo Domain, die hatten eine Taste für neue Fenster. Wollte der Programmierer unbedingt haben. Wir haben uns dann geeinigt, keine Hersteller-Lockins zu verwenden sondern offene Standards. Meine Erfahrung ist, es kostet Kraft, Standards erfolgreich umzusetzen, während dagegen „Es ist alles eitel!“ leichter von den Lippen geht :-)
Bei der MTA ist dann doch die Frage, welche Methode besser ist, Planung von Milestones näher an die Realität zu bringen, wenn man das braucht und zweitens, warum man das braucht, wenn einem Best Practices nicht helfen.
Ich neige dazu, bei Einsatz von bestimmten Methoden mich immer auch an Best Practices zu orientieren statt bei allem das Rad neu zu erfinden.
Aber das ist auch eine kulturelle Frage. Jemand, der alles selbst und neu bei jedem Projekt erfindet, braucht auch keine Reifegradmodelle. Anderen liegt aber manchmal daran, Reife zu erhöhen, wenn Projekte dann doch oft gleichartig verlaufen. Selbst die SCRUM-Leute verfolgen Satndards, Zertifizierungen, Best Practices in ihren Zeremonien :-)
Schwierig wird es auch in Kunden-Lieferanten-Beziehungen, wenn man keine Best-Practices als Baselining setzt und der Lieferant sagt, Ihr Projekt ist so speziell, so komplex: wir erfinden alles neu und greifen nicht auf Bewährtes zurück.
Spannender und realistischer als BP zu bashen fände ich, Standards zu entwickeln, wann denn etwas als „Best“ definiert werden kann, um es nicht als Marketinghülse verkommen zu lassen. Dethloffs Negationen wären mir als Kunde zu teuer.
Danke für Deinen ausführlichen Kommentar, Wolfgang. Ich habe auch gar nichts gegen Best Practice im Sinne eines Werkzeugkastens. Ich sehe einen großen Wert darin, dass die Methoden sauber beschrieben sind und ich das Rad nicht neu erfinden muss. Die Frage, ob ich eine Methode einsetze liegt aber immer noch bei mir als Projektleiter. In dem Moment wo alle Projekte über einen Kamm geschoren werden und Werkzeuge verpflichtend werden wird es gefährlich. Und ja: auch und gerade bei Scrum wird es hier gefährlich. Scrum ist viel mehr als das scheinbar einfach Kochrezept als das es oft dargestellt wird. Ohne die passenden Werte und die passende Kultur geht das grandios schief.
„Ohne die passenden Werte und die passende Kultur geht das grandios schief.“
Ist das nicht generell so?
Auch im klassischen PM (immer noch ein dämlicher Begriff, aber lassen wir das), also im Wesentlichen dem Anlagenbau, habe ich immer wieder festgestellt, daß viel Zeit darauf verschwendet wird, Schuldzuweisungen zu deflektieren und die Kehrseite zur Wand zu bringen.
Das ging so weit, daß ich teilweise 75% des projektinternen Schriftverkehrs direkt in den Ordner „Nicht mein Tisch“ verschoben habe, weil es da um nichts sachdienliches mehr ging, sondern nur noch um teils heftig formulierte Schuldzuweisungen und sinnlose Rechtfertigungen.
Werte im Sinne von gegenseitigem Vertrauen (zumindest ein gewisser Teil davon ist ein Vorschuß und unternehmerisches Risiko) und Kultur im Sinne von offenem Umgang mit Fehlern, Versäumnissen und Risiken sind so oder so essentiell.
Meine persönliche Meinung ist, daß unterm Strich gerade diese Aspekte eine große Rolle bei den prominenten Katastrophenprojekten spielen.
Da hast Du recht, Thilo. Das ist generell so. Wenn es irgendwann im Projekt oder Unternehmen nur noch um Cover-your-ass geht, dann läuft etwas ziemlich schief. Oft ist es aber wirklich so wie Du schreibst. Leider.
Vielen Dank für diesen Beitrag, Marcus!
Für sich genommen ist das Thema „Best Practice“ schon eine Marke für sich. Richtig spannend wird das aber wie immer durch Beispiele.
Einige aus der IT hatten wir schon. Also gehen wir (mal wieder) in den Anlagenbau:
Bei einer mir bekannten Firma wurde vor ein paar Jahren eine Projektleiterzertifizierung eingeführt. Das ist ja an sich nichts Schlechtes, zumal in dieser Firma (anders als in einer anderen) entsprechend aufwändige, dem PMP entlehnte Schulungen und Praxisübungen sowie ein Nachweis über die in den einzelnen Kompetenzfeldern erbrachten Tätigkeiten im Programm enthalten waren.
Nach insgesamt knapp 14 Tagen Präsenzschulung, ein paar Tagen E‑Learning, und noch ein paar Tagen Dokumentation des Lebenslaufes war man dann „Certified Project Manager“.
Bis hierhin alles in Ordnung und sinnvoll.
Mein Problem bei der Geschichte war die Motivation:
Es ging nicht etwa darum, Projektleiter zu schulen, für Risikomanagement zu sensibilisieren, und unterm Strich die Projekte zu verbessern.
Vielmehr ging es um eine Forderung der Kunden: Die hatten nämlich (um ihre Projektabwicklung zu verbessern und weniger Geld und Zeit zu verlieren) in ihre Lastenhefte bzw. Anfragen geschrieben, daß die Projektleiter der Lieferanten ihre Qualifikation im Projektmanagement nachweisen müssen, um die Projekte auch abwickeln zu dürfen.
Kein Nachweis hieß: „Angebot abgelehnt“.
Wie also Peter auch schon schrieb: „Weil wir uns absichern wollen“
Also wir merken uns: Ziel ist in diesem Beispiel die Absicherung gegenüber wem auch immer.
Wie weise ich also Qualifikation nach?
Naja, die „Best Practice“ ist ein Zertifikat. Egal, ob PRINCE2, PMI/PMP oder was auch immer – ein Zertifikat muß her.
Da man ja auch der ISO 9001 verpflichtet ist, und zudem noch vom Vorstand einen auf den Deckel bekommen hatte (siehe oben: Verbesserung der Abwicklungsqualität), wurden also alle PMs durch die Bank verpflichtet, egal ob sie an Projekten, im Systemgeschäft oder ganz wo anders arbeiteten.
Das Ziel, weiter anbieten zu dürfen, hat man tatsächlich erreicht. Den Nebeneffekt der besseren Projektabwicklung leider nicht.
Macht aber nix. War ja nicht die Zielvorgabe.
Ich finde, das ist ein Klassiker in der „Best-Practice-Hörigkeit“, wie man ihn kaum noch toppen kann.
Nebenbei erschlägt das übrigens auch gleich nochmal das Thema „Zieldefinition“:
Hätte man durch alle Ebenen verstanden, warum die ominöse Forderung nach der Qualifikation überhaupt erst aufgekommen ist, hätte man aus dem ganzen Programm einen riesigen Benefit für alle Beteiligten ernten können.
Übrigens war der enthaltene Ansatz zur globalen Vereinheitlichung des Projektmanagement gar nicht mal verkehrt, hätten sich alle dran gehalten.
Dieser Ansatz war gut durchdacht, und enthielt etliches an Werkzeugen, die nach dem Motto „Müßt Ihr nicht, aber wenn, dann so“ bereitgestellt wurden.
Leider wurde das aber nicht ausreichend durch die Zieldefinition gestärkt, so daß die Umsetzung z.B. in Deutschland dort hängen blieb.
Schön (oder schrecklich), dass es auch in anderen Branchen nicht anders geht. Was da an Zeit und Geld versenkt wird, ohne davon durch die Projekte Profit zu machen. Das tut mir immer weh.
Im IT Bereich geschieht da regelmäßig mit der ITIL Foundation Zertifizierung. Eine gesamte IT-Abteilung muss da durch, ob es den AS/400 Admin interessiert oder nicht. An andere Wege wird da gar nicht gedacht.
Danke für dieses Beispiel, Thilo! Aus dem Impuls der Auftraggeber, nämlich der ziemlich naiven Forderung alle müssen zertifiziert sein, hätte man mit der richtigen Motivation tatsächlich viel mehr herausholen können. So war das bestenfalls halbherzig. Das Muster kenne ich aber auch aus der IT …
Ist halt ein Klassiker. Aus einer falschen (oder zumindest ungenau formulierten) Motivation heraus das Richtige anfangen und dann mittendrin abbrechen.
Da steckt übrigens für mich ein Körnchen „Agile“ drin:
Wenn ich mitten im Prozeß feststelle, daß ich trotz der falschen Ursprungsmotivation etwas Gutes erreichen kann – was hindert mich daran, die Zieldefinition und die Regeln zu ändern und auf die richtige Straße abzubiegen?
Selbst im Phase-Gate-Modell habe ich genug Punkte, an denen ich die Ziele hinterfragen und justieren kann.
Letztlich ist das aber immer eine Frage der menschlichen Variablen. Habe ich Vorgesetzte und ein Team, die tatsächlich zusammen an einem gemeinsamen Ziel arbeiten, kommt so eine Verfeinerung bzw. Verbesserung eher vor, als in klassisch hierarchischen Strukturen, wo alle machen, was der Chef sagt (oder zumindest das, was sie davon verstehen) und niemand einen Einspruch wagt.
Und hier noch was für die Freunde von best practices:
Best Practices im agilen Software Testing
„Embracing Disruptive Testing“
http://tyro.com/embracing-disruptive-testing/
„My aversion to the concept of best practice has grown over the years as in reality it fails miserably.“
Der Videoclip plus Folien unten auf der Seite ist auch zu empfehlen:
„Disruptive Testing: The Hunt for Black Swans“
Best Practices für alles was das moderne Herz begehrt, inklusive der Jagd nach den Schwarzen Schwänen :-)
http://www.infoq.com/presentations/embrace-disruption-testing
Wir dürfen gespannt sein, wann es zertifizierte Schulungen für die best practices des disruptive testing gibt. Die modernen buzzwords sind alle da: Komplexität, nicht planen, Autonomy, Collaboration, Continous Self Learning, Empowerment.
:-)
Danke für all die sehr einmütigen Kommentare, die letztlich auf den Punkt gebracht bedeuten: Best Practice entheben den Projektleiter nicht von der Verantwortung das Projekt selbst zu gestalten. Es ist noch kein Projekt erfolgreich geworden, nur weil es mit Best Practices durchgeführt wurde !
Das bedeutet im Umkehrschluss für alle, die (weil nie gelernt) von Best Practices wenig Ahnung haben und die selbstverantwortliche Führung ihrer Projekte scheuen: Lass die Finger vom Projektmanagement und nenne (bzw. verkaufe) Dich bitte auch nicht (als) Projektmanager !