Gibt es tatsächlich jemanden auf diesem Planeten, der Managementmethoden ganz banal Wort für Wort und ohne Nachdenken anwendet? Ich finde im Netz sehr selten eine Diskussion, die zwei Methoden vergleicht und ein gerüttelt Maß an Erkenntnisgewinn hervorbringt. Zumeist ist es verplemperte Lesezeit und das Dargebotene eine Debatte, die in Kardinalfällen eine sehr geringe Streitkultur aufweist.
Der Methodenkoffer von Projekt Management, Service Management, Qualitäts-Management, Governance und ähnlichen Vorgehensweisen ist am Ende des Tages recht übersichtlich. Je komplexer die Zusammenstellung dieser Methoden ist, desto eher muss bei der Umsetzung das Gehirn eingeschaltet werden und eine Systematik gefunden werden, die erstens passt und zweitens die Grundidee aus der Managementmethode sinnvoll transportiert.
In solchen Debatten wird jedoch von den Protagonisten ernsthaft behauptet die neue Version der Methodik sei unter Anderem deshalb unbedingt zu bevorzugen, weil ein zwei Prozessschritte eingefügt wurden.
Ich meine, was soll das? Die neuen Prozessschritte sind ja als Anregung ganz schön, jedoch werde ich einen Prozessschritt immer dann einfügen wenn ich ihn benötige und alle unnötigen Prozessschritte weglassen – eliminating waste wie es so schön bei Lean heißt.
Als Illustration des Obigen: In ITIL® v3 und 2011findet sich ein Major Problem Prozessschritt. Eine Major Incident Procedure benötigt fast jeder Kunde, Major Problem habe ich noch nie in freier Wildbahn gesehen. Deshalb kurz ansprechen und prüfen ob der Kunde das benötigt und im Zweifelsfall weglassen (Sonderfall: Falls die ITSM Software dies vorsieht, muss diese Funktion nicht ohne Not ausgebaut werden, kostet nur Geld und ignorieren einer Schaltfläche bedeutet keinen Zeitverlust für die Mitarbeiter).
Ein Problem Management Prozess ohne Major Problem ist im Ergebnis immer noch ITIL. Beim Weglassen ist wichtig Nachzudenken und die Gründe der Entscheidung zu dokumentieren. Auch ist Weglassen kein Freibrief verlangte Standards wegzulassen „eliminating waste“ und nicht „ignore to do things right“.
Eine weitere Spielart weltfremder Argumentation meint sequentielle Abläufe oder ähnlich einfache Strukturen würden zum Scheitern von Projekten, Verfahren, etc. führen. Jeder Informatikerin und jeder Informatiker lernt im Studium wie Abläufe parallelisiert oder iterativ abgearbeitet werden. Übrigens sowohl strukturell im Sinne von Algorithmen, als auch sozial bei den Methoden der Softwareentwicklung.
Aber bei Managementmethoden schauen wir alle ins Buch, sehen eine einfache Sequenz, kratzen uns am Kopf und gehen zur nächsten Methodik über? In der Schule wird auf Transfer des Wissens Wert gelegt und bei simplen Vorgehensweisen soll das nicht möglich sein?
Zugegeben ich hatte einen Fall, in dem ein Projektmanager zu mir gesagt hat, dass eine Erweiterung der Methode obwohl unstrittig sinnvoll nicht zulässig sei. Daraufhin fragte ich, warum dies nicht möglich ist:
„Das steht so nicht in unserem Methodenhandbuch!“
„Wer hat das geschrieben?“
„Wir“
„Warum können wir dann keine Sonderregelung beschließen?“
„Weil das so nicht vorgesehen ist!“
Die Erlangung der „Sondergenehmigung“ war einer kürzesten Entscheidungspunkte im nächsten Lenkungsausschuss.
Ich kann übrigens auch wirklich gut verstehen, warum Menschen mit viel Herzblut ihre Methodik vertreten. Diese wurde mit viel Schweiß erlernt und so oft angewandt bis sie sich tief ins Kleinhirn eingegraben hat. Kein Wunder das bei Kritik oder Verteidigung die Emotionen hochschießen.
Ich rate zu Ruhe und Einsatz des präfrontalen Kortex. Anderen Methoden haben auch schöne Ansätze in ihrem Portfolio. Es lohnt sich da mal rein zuschauen, auch wenn man bei seinem Werkzeugkasten bleibt. Falls man gezwungen wird eine andere Methodik anzuwenden, so fühlt man sich zugegebenermaßen unsicherer. Mit einem Buch bewaffnet ist das lösbar, die andere Methode kocht auch nur mit Wasser und so viel Umstellung meist auch nicht.