In vielen Unternehmen hören wir den Ruf nach Best Practices.

• Wie werden wir besser? Dafür gibt es doch bestimmt eine Best Practice.
• Wie werden wir schneller und effizienter? Dafür gibt es doch bestimmt eine Best Practice.
• Wie sparen wir Kosten? Dafür gibt es doch bestimmt eine Best Practice.
• Wie entwickeln wir bessere Produkte? Dafür gibt es doch bestimmt eine Best Practice.

Berater servieren uns diesen Begriff gerne auf dem Silbertablett. Sie suggerieren uns damit, dass sie einen erprobten Weg kennen, der auch uns weiterhelfen wird.

Der Wunsch nach Best Practices ist verständlich

Geschäftsmodelle sind heute komplexer als früher. Dazu tragen die gestiegenen Ansprüche der Kunden und die Megatrends Globalisierung und Digitalisierung bei. Entsprechend sind unsere Aufgabenstellungen komplex.

Das bedeutet: Es gibt keine klare, definierte Beziehung zwischen Ursache und Wirkung. Wir können nicht vorhersagen, ob eine bestimmte Strategie erfolgreich sein wird.

Gleichzeitig stehen wir im Unternehmen unter wirtschaftlichem Druck.

Also blicken wir auf andere erfolgreiche Unternehmen. Welche Produkte bieten sie an? Auf welchen Märkten sind sie aktiv? Wie arbeiten sie intern? Welche Methoden setzen sie ein? Und wir vermuten: Wenn wir es genauso machen, werden wir Erfolg haben.

• Wir orientieren uns an anderen und versprechen uns davon, dass es bei uns auch funktioniert.
• Wir hoffen, dass wir eine komplexe Aufgabe mit erprobten Mitteln meistern werden.
• Wir hoffen auf Musterbeispiele, auf ein Erfolgsrezept, auf einen Weg, der funktioniert.

Das ist verständlich. Es entspringt dem Wunsch des menschlichen Gehirns, Dinge zu vereinfachen und in einer schwierigen Umgebung einen klaren Weg zu finden. Wir glauben, dass bewährtes Vorgehen, Fallbeispiele oder vermeintlich “optimale” Methoden uns helfen.

Funktionieren Best Practices?

In definierten, gleichartigen Umgebungen und Situationen funktionieren Best Practices möglicherweise. In stabilen Produktionsumgebungen existieren bekannte Methoden und Regelwerke oder Normen, die uns helfen, effizienter zu werden.

In komplexen Umgebungen – und Wissensarbeit ist immer komplex – funktionieren Best Practices in der Regel nicht. Organisationen sind komplexe Systeme aus Interaktionen zwischen Menschen. Best Practices können dort nicht als Blaupause dienen:

• Es funktioniert nicht, wenn wir einen Lösungsweg unverändert auf andere Bedingungen übertragen.
• Es funktioniert nicht, wenn wir einen Lösungsweg unverändert auf andere Zielgruppen übertragen.
• Es funktioniert nicht, wenn wir einen Lösungsweg unverändert auf andere Aufgaben und Situationen übertragen.
• Es funktioniert nicht, wenn wir einen Lösungsweg unverändert auf eine andere Firmenkultur übertragen.

Mal abgesehen von einer einfachen Erkenntnis: Wenn wir alle das gleiche machen, stechen wir nicht mehr aus der Masse heraus.

Wir machen uns zu einer Kopie.

Kommt drauf an. Nächste Frage, bitte.

So einfach ist es natürlich nicht. Lassen Sie uns die Frage konkretisieren:

Führt es zum Ziel, lediglich agile Methoden einzuführen? So wie statt eines Hammers eine Zange aus dem Werkzeugkoffer zu nehmen?

Und – wie ist das Ziel definiert? Schneller und kostengünstiger zu werden? Bessere Produkte zu entwickeln? Die Kunden zufriedener zu machen?

Ist agiles Vorgehen schneller als klassisches?

Ein verbreitetes Missverständnis lautet, dass es mit agilen Methoden schneller geht.

(Aus dieser Annahme folgt eine weitere Annahme: Es wird kostengünstiger.)

Wir stellen uns vor, dass wir eine neue Methode aus dem Koffer holen und die Projekte und Produkte künftig früher fertig werden.

Das Problem an dieser Sichtweise ist, dass die Methoden nur die Spitze des Eisbergs darstellen. Wenn der Bereich unter der Wasserlinie unverändert un-agil bleibt, werden neue Methoden nicht viel ändern:

Das wird an einem Beispiel anschaulicher.

Wie die XY GmbH versucht, agiles Arbeiten einzuführen

Die fiktive XY GmbH entwickelt Software. Sie steht als Beispiel für eine Vielzahl von Unternehmen, die agiler werden wollen.

Das Management der XY steht vor den üblichen Problemen. Die interne Zusammenarbeit ist nicht gut, die Projekte dauern zu lange, und die Kunden werden unzufriedener.

Also beschließt der Geschäftsführer, dass ein Projekt als “Versuchsballon” agil durchgeführt werden soll. 

Das Team bekommt eine Scrum-Schulung, eine Person übernimmt die Rolle des Scrum Masters, und eine andere die des Product Owners. Außerdem beruft die Firma eine Projektleiterin. Der Geschäftsführer möchte eine feste Ansprechpartnerin für das Projekt haben.

Damit sind die Vorbereitungen abgeschlossen, der Scope des Projekts wird fixiert, und die Arbeit beginnt.

Bestandsaufnahme

Nach einiger Zeit stellt der Geschäftsführer fest, dass die Verbesserung, die er sich von agilem Vorgehen erhofft hatte, nicht eingetreten ist. Das Projekt ist weit davon entfernt, Ergebnisse an die Kunden auszuliefern. Obwohl die Projektleiterin den Auftrag hatte, sich besonders darum zu kümmern.

Die Projektleiterin wiederum ist der Meinung, dass sie ihren Job nicht richtig machen konnte. Sie war es früher gewohnt, ihr Team zu steuern, und muss sich jetzt mit einem Scrum Master auseinandersetzen. Sie war es gewohnt, für die Inhalte verantwortlich zu sein, aber da gibt es einen Product Owner, der das gleiche Verständnis hat. Sie hat das Gefühl, dass ihre Aufgabe überwiegend darin besteht, im Lenkungsgremium den Druck abzubekommen und für das Reporting zuständig zu sein.

Das Team meint,

Das kommt darauf an, wen wir fragen.

Klassisch ausgebildete Projektleiter ziehen auf diese Frage ihre bewährten Methoden mit Phasenmodell, Projektplan, Meilensteinen usw. aus der Schublade.

Verfechter agiler Vorgehensweisen sehen das anders. Sie schlagen zunächst einen Design Sprint oder eine Design-Thinking-Phase vor. Anschließend bildet sich ein Scrum-Team, das in seinen Sprints ein Minimum Viable Product erstellt. Danach sieht man weiter.

An dieser Stelle ziehen wir zwei Schlüsse.

1. Wir neigen dazu, das Hilfsmittel zu nutzen, das wir gut beherrschen. Wir favorisieren eine Vorgehensweise, mit der wir gute Erfahrungen haben. Oder die tief in der Arbeitsweise und der Kultur des Unternehmens verankert ist. Das ist eine natürliche Reaktion. Deswegen antwortet jede befragte Person anders.
2. Die Frage ist zu oberflächlich gestellt, ähnlich der Frage: “Was kostet ein Auto?”

Aber ist diese Frage überhaupt wichtig?

Ja. Denn eine ungeeignete Vorgehensweise zu wählen, kann Projekte deutlich verzögern, schlechte Ergebnisse produzieren, oder scheitern lassen.

Kompliziert vs. komplex

Wir betrachten als erstes: Handelt es sich um eine komplizierte oder eine komplexe Problemstellung?

Um diesen Unterschied besser zu verstehen, nehmen wir das Beispiel einer mechanischen Armbanduhr. Sie ist zweifellos ein technisches Meisterstück, bei dem viele Bauteile geschmeidig ineinandergreifen.

Aber Zusammenhänge der Bauteile sind definiert. Die Ursachen und Wirkungen lassen sich genau beschreiben.

Nicht jede/r ist in der Lage, solch eine Uhr zusammenzubauen oder zu reparieren. Das erfordert Wissen und Können. Aber jemand mit der entsprechenden Ausbildung und Erfahrung wird diese Aufgabe meistern. Das ist vorhersagbar. Die Armbanduhr ist kompliziert.

Komplizierte Aufgaben meistern wir mit den folgenden Strategien gut:

• Lernen, wie etwas funktioniert,
• Analysieren,
• Erfahrungen und Daten aus der Vergangenheit benutzen, um daraus Entscheidungen abzuleiten.

Diese Frage hilft uns: Kann jemand dafür ein Handbuch schreiben oder einen verlässlichen Plan entwickeln? Falls ja, ist der Sachverhalt wahrscheinlich kompliziert.

Komplexe Probleme meistern wir am besten mit anderen Strategien:

• Erkunden und einen “Probeschritt” machen
• Erkennen, wie das System reagiert
• und mit dieser Erkenntnis die nächsten Schritte machen.

Die Auswirkung von Komplexität auf die geeignete Projektvorgehensweise

Für das Projektmanagement