Der Titel dieses Textes soll nicht in die Irre führen: Strukturen sind wichtig. Sie geben Orientierung, schaffen Klarheit und sparen Zeit, weil nicht jedes Detail erst diskutiert werden muss, sondern bestenfalls bereits ein Prozess dafür vorliegt. Ich persönlich schätze Struktur und Ordnung sehr, weshalb mir in meiner beruflichen Laufbahn schon früh das Management diverser Projekte übertragen wurde. Wer schon mal ein Projekt gemanagt hat, weiß jedoch: Strukturen sind nicht alles. Manchmal sind sie sogar ein echtes Problem.
VUCA VUCA HEY HEY
Selbst diejenigen, die unter einem sehr großen Stein mit schlechtem Internet leben, haben mittlerweile schon mal etwas von der VUCA–Welt gehört, in der wir uns befinden. Das Akronym steht für Volatility (Volatilität), Uncertanty (Unsicherheit), Complexity (Komplexität) und Ambiguity (Mehrdeutigkeit) und wird von vielen Führungskräfte-Coaches als Ergebnis der Digitalisierung beschrieben. Jedoch tauchte der Begriff bereits in den 1980ern in Kreisen von US-Wirtschaftswissenschaftler:innen das erste Mal auf und fand nach Zerfall des Ostblocks Eingang in das Vokabular des US Army War Colleges.
VUCA wurde und wird genutzt, um eine neue Weltordnung zu beschreiben, in der sich zurechtgefunden werden muss. Das gilt für Führungsränge im US-Militär genauso wie für die Geschäftsführer:innen von Unternehmen.
Nicht umsonst ist agil das Stichwort der (nicht mehr ganz so neuen) Stunde, wenn es um die Re-Organisation von Teams, Abteilungen oder ganzen Unternehmen geht. Wird unser Umfeld unsicherer, müssen wir flexibler werden, um schneller zu reagieren! Klingt schlüssig, birgt aber Probleme. Arbeiten auf Zuruf birgt Fehlerpotenzial und erhöht den Abstimmungsaufwand. Das ständige Neuordnen von Prioritäten und das fortwährende Anpassen von Prozessen verlangt einen nicht zu unterschätzenden Ressourcenaufwand. Und das geht zulasten des Produktionsoutputs: Wer neuordnet oder den ganzen Tag in Abstimmungs-Meetings sitzt, kann nicht wertschöpfend unterwegs sein.
Das andere Extrem ist jedoch auch problematisch: Das Beharren auf starren Prozessen um jeden Preis kann bedeuten, dass Trends schon kalter Kaffee sind, bevor man sie überhaupt wahrgenommen hat. Und ehe man sich versieht, ist das eigene Geschäftsmodell überholt.
Die Strukturen des Henry F.
Ein gutes Beispiel ist Henry Ford, um den man auch in keinem BWL-Einführungskurs herumkommt. Durch seine bis ins kleinste Detail standardisierten Produktionsprozesse war es ihm möglich, die Kosten für sein Model T derart zu senken, dass er die Konkurrenz bei Weitem unterbot und sich fast jeder amerikanische Haushalt eines seiner Autos leisten konnte. Damit war er 1924 mit Abstand Marktführer. Seine hochgelobten Prozesse bargen aber auch Gefahren. Gut illustriert das sein vielleicht berühmtestes Zitat: “Any customer can have a car painted any color that he wants so long as it is black.” Das war solange toll, bis die Konkurrenten mit neuen, verbesserten und bunteren Modellen in sein Marktsegment eindrangen und Ford locker abhängten – ganz vorne mit dabei General Motors. Drei Jahre später – schon 1927 – wurde die Produktion des legendären Modell T dann auch schon eingestellt.
Mangelnde Innovationsfähigkeit starrer Prozesse ist aber nur ein Problem. Ein weiteres Problem stellen Prozesse dar, wenn sie nur (noch) um ihrer selbst Willen existieren.
Du möchtest als Erste:r erfahren, was die Monsters of Project Management noch so treiben? Kein Problem! Melde Dich einfach zu unserem kostenfreien Newsletter an und alle zwei Wochen flattern die neusten Neuigkeiten aus dem Kibibit-Nest direkt in Dein Mailpostfach.
Schizophren: Das Management der Agilität
Insbesondere in den vergangenen Jahren hat Projektmanagement als Disziplin eine neue Popularität erreicht. Gefühlt muss in einem zunehmend agilen Umfeld alles gemanagt werden. Das mutet insofern schizophren an, als dass Management (zu Deutsch: Verwaltung) doch eigentlich das Gegenteil von Flexibilität sein müsste. Wer würde mit dem Wort verwalten innovatives Arbeiten verbinden? Hier vermischen sich oft die Begriffe Management und Leadership, aber dazu an einer anderen Stelle mehr.
Die Popularität von Projektmanagement kann man auch an der starken Zunahme der Projektmanagement-Tools auf dem Markt ablesen. Vor gefühlt jedem YouTube-Video wird mir aktuell ein anderes Tool angepriesen, welches sich angeblich perfekt an meine Prozesse anpasst und mir dabei hilft, bei allem den Überblick zu behalten. Und genau hier liegt der sprichwörtliche Hase im Pfeffer: Das Tool oder die Methode müssen zum Prozess passen – nicht umgekehrt. Und außerdem: Eine Methode oder ein Tool allein schafft noch keinen Prozess.
Projektmanagement-Tools: Irgendwie, irgendwo, irgendwann
Ich habe in einigen Kundenprojekten schon mitverfolgt, wie auf einmal abteilungsübergreifend das Arbeiten mit einem bestimmten Tool vorgegeben wurde. Zum Beispiel Trello. Es gab Einführungs-Workshops in denen allen Mitarbeitenden erklärt und gezeigt wurde, wie neue Trello-Karten angelegt und in verschiedene Buckets einsortiert werden können, wie man Dateien verlinkt, etc. WARUM das Ganze aber gemacht werden sollte und WAS man damit abbilden möchte, dazu wurden keine Workshops abgehalten. Es wurde kein Regelwerk vorgestellt ab welcher Projektgröße dafür eine eigene Kachel erstellt oder ein neues Board angelegt werden soll, wie Aufgaben über Tags verteilt werden, wie viele Trello-Boards es überhaupt wie geben soll, wann ein Punkt als erledigt gilt, wie sich Trello in die bereits existierenden Arbeitsweisen einfügen soll, etc.
Gut. Nun könnte man ins Feld führen, dass wenn die Führungsetage schon ein Tool von oben vorschreibt, ist es doch nett, wenn jedes Team selbst entscheiden kann, wie es dieses Tool nutzt?
Nein. Ziel der Top-down-Einführung war die Schaffung von Transparenz und Vergleichbarkeit. Die Führungsebene wollte besser im Blick haben, was unter ihr passiert. Dieses Ziel kann aber nicht einfach mit der Einführung irgendeines Toolings erfüllt werden. Es ist die Nutzung des Tools, die Transparenz schafft. Und um eine einwandfreie Nutzung zu gewährleisten, muss man sich ein Regelwerk überlegen und dieses – idealerweise zusammen mit den Zielen – auch an alle Nutzenden kommunizieren.
Und es kam, wie es kommen musste: Jedes Team nutzte das neue Tool irgendwie.
Einige bekamen es sinnvoll in ihre Abläufe integriert, bei den meisten anderen verkam das Pflegen ihres Boards zu einer zusätzlichen Arbeit, deren Sinnhaftigkeit niemand begriff. Entsprechend hoch war auch die Frustration in den Teams, wenn sich die Mitarbeitenden einen Einlauf abholen durften, weil ihre Trello-Karten nicht ajour waren. Dass das Pflegen ihrer Karten aber absolut keine positiven Auswirkungen auf ihre eigentliche Wertschöpfung hatte – im Gegenteil: Es fraß ja sogar Zeit – das spielte keine Rolle.
Die Nutzung von Trello wurde ein zusätzliches Häkchen auf der täglichen To-do-Liste anstelle einer klugen Prozessoptimierung. Schade.
Und Achtung: Negative Erfahrungen wie diese können in Teams, Abteilungen und ganzen Unternehmen dazu führen, dass Neues noch kritischer beäugt wird, als ohnehin schon.
Dieses Beispiel mag für einige nun klingen wie ein Märchen aus der Projektmanagement-Hölle – mir sind derartige Geschichten aber deutlich öfter untergekommen, als ich gerne zugeben möchte. Man sollte bei der rückblickenden Betrachtung solcher Fails jedoch auch nicht der Gefahr des Rückschaufehlers unterlaufen – im Nachhinein sieht nämlich alles oft viel logischer und einfacher aus.
Es lohnt sich vielleicht eher zu fragen, warum so etwas passieren kann. Gibt es einen Zusammenhang zwischen den Trends Agilität und Projektmanagement? Während – ganz vereinfacht gesagt – der eine mehr Flexibilisierung fordert, schafft der andere Strukturen. Starre Hierarchien sollen aufgelöst werden – trotzdem müssen Prozesse existieren, um nicht alles immer wieder aufs Neue zu hinterfragen. Wie eingangs erwähnt, ist beides wichtig – und notwendig.
Hierarchien, Agilität oder beides? Hier weiterlesen.
“Hierarchien gehören abgeschafft!” Diese Forderung ist nicht neu, dafür allgegenwärtiger denn je. Gerade im Angesicht agiler Methoden ploppt die Idee von nahezu hierarchiefreien Organisationen immer wieder reflexartig auf: Wer A(gil) sagt, muss auch “weg von Hierarchien, hin zum Führen auf Augenhöhe und selbstorganisierten Teams” sagen. Aber: Geht das überhaupt? Hier vielleicht eine Antwort finden.
Zwischen Mikro und Management
Das Verlangen nach Struktur und Ordnung ist ein recht menschliches, je nach Charakter stärker oder schwächer ausgeprägt. Strukturen geben uns das Gefühl, dass wir Dinge unter Kontrolle haben. So neigen zum Beispiel Manager:innen dazu, Mitarbeitende, denen sie nicht vertrauen, stärker zu kontrollieren. Das verschlechtert aber in der Regel die Arbeitsmoral der Kontrollierten und steigert selten die Arbeitsleistung.
Ich habe es auch schon oft erlebt, dass Manager:innen sich in Mikromanagement verzetteln, anstatt sich den Aufgaben zu widmen, die sie eigentlich bearbeiten sollten, weil man Kleinigkeiten eben leichter unter Kontrolle hat. Entscheidungsunfreudige Personen versuchen außerdem oft Prozesse zu schaffen, die ihnen unangenehme Tätigkeiten oder eben Entscheidungen abnehmen. Ein Projektleiter hat mal einen derart komplizierten Abstimmungsmarathon durch alle Fachabteilungen ausgerufen, damit er die Verantwortung für eine finale Entscheidung nicht alleine tragen musste. Zu dem Zweck hat er außerdem mehrmals nachträglich Protokolle anpassen lassen. Das kann und darf aber nicht der Zweck von Projektmanagement sein. Das ist eher eine white-collar-Form der Prokrastination. Oder ein falsch verstandenes Anforderungsprofil.
Vor diesem Hintergrund klingt es nur logisch, dass sich Menschen in einem volatilen Umfeld eine Form von Kontrolle wünschen – und sei es eben über den Projektplan. Ich kann es tatsächlich nachvollziehen, dass der Blick auf eine gut gepflegte Projektliste einem ein durchaus beruhigendes Gefühl geben kann: Man sieht, was man geschafft hat und man sieht, was man – vermeintlich – unter Kontrolle hat. Dass man nie alles unter Kontrolle haben kann, nun ja, das sagt einem auch kein Projektmanagement-Tool.
Tja, und nun?
Ich bin ein großer Fan vom Fragenstellen. Daher möchte ich allen Ordnungsfanatiker:innen und Mikromanager:innen ein paar Fragen mitgeben, die vielleicht dabei helfen, unnötige Strukturen und Prozesse zu erkennen oder zu verhindern:
Was ist das Ziel meiner Projektplanung?
(Z.B.: Sollen Kapazitäten geplant oder nur Zuständigkeiten verteilt werden?)
Sind meine Prozesse/Methoden geeignet, dieses Ziel zu erfüllen?
(Z.B.: Sind alle relevanten Personen involviert/haben alle eine aktive Rolle? Kann mein Tool alles darstellen, was ich brauche?)
Brauche ich das wirklich? Wenn ja, wofür?
(…dieses Meeting, dieses Protokoll, dieses Tool, etc. Möchte ich kontrollieren/Entscheidungen delegieren/ein cooles Tool haben oder hat es einen projektbezogenen Zweck?)
Geht es auch einfacher?
(Die in meinen Augen wichtigste Frage. Am besten im Projektteam diskutieren. Darunter z.B. auch: Welchen Detailgrad / wie viele Freigaben / Involvierte brauche ich wirklich?)
Hier auch nochmal zum Download und für die Ab – und Wiedervorlage:
Im Zweifelsfall hilft es immer, sich einen zweiten (oder auch dritten Blick) von unbeteiligten Außenstehenden zu holen. Hat der/die Lebenspartner:in, Nachbar:in oder die zwölfjährige Nichte den Prozess verstanden, kann er schon mal nicht ganz verkehrt sein.
*Titel in loser Anlehnung an das folgende Zitat von Oscar Wilde: “Ambition is the last refuge of the failure.”
Du möchtest als Erste:r erfahren, was die Monsters of Project Management so treiben? Kein Problem! Melde Dich einfach zu unserem kostenfreien Newsletter an und alle zwei Wochen flattern die neusten Neuigkeiten aus dem Kibibit-Nest direkt in Dein Mailpostfach.