dot.kunden - Der Weg zu einfacheren Projekten mit weniger Komplexität

David Berger
26. August 2020

Du verantwortest ein umfangreiches Projektprogramm? Mehr als hundert Mitarbeitende? Zahlreiche Ziele? Viele Lieferanten? Ein quasi unendlicher Backlog? Aber du spürst, dass du den Überblick verlierst? Mit diesem 5-Schritte-Plan reduzierst du nachhaltig Komplexität in deinem Vorhaben.

Dein Projekt ist zu gross?

Vermutlich ist es eine männliche Eigenschaft, Vorhaben möglichst gross und breit zu schneiden, getreu dem Motto: Je grösser, desto besser? Und so kommt es, dass plötzlich auch periphere Vorhaben ins grosse Programm integriert werden müssen, um vermeintliche Abhängigkeiten zu reduzieren. Der Scope des Vorhabens wird kontinuierlich grösser und dadurch immer undurchsichtiger.

Um mit dieser wachsenden Komplexität umzugehen, folgt meist die Projektorganisation dementsprechend: Teilprojektleiter und Querschnittsthemenverantwortliche werden ernannt, fachliche wie technische Entscheidungsgremien und Unterlenkungsauschüsse ins Leben gerufen und PMO-Stellen geschaffen und besetzt. Das klassische Phasenmodell im Projektmanagement ist fachlich zerstückelt. Letztlich sieht jedes grössere Projektprogramm irgendwann so aus:

dot.blog-Komplexe Vorhaben

Jedes Thema ist ein eigenes Projekt. Und jede Phase in einem Thema ein eigenes Teilprojekt. Manche Themen sind naturgemäss in mehreren Phasen gleichzeitig. Erkennst du dein Projekt wieder? Dann bitte weiterlesen.

1) Geht immer: Budget, Umfang und Mitarbeitende reduzieren

Das einfachste Mittel, ein bereits abwegiges Projekt zu retten, ist es, das Budget (stark) zu reduzieren. Das soll nicht bezwecken, dass wir unsere Qualitätsansprüche (weiter) senken, sondern dass wir die künstlich erzeugte Komplexität radikal reduzieren, indem wir den Umfang entschlacken und die Anzahl der am Projekt beteiligten Personen drastisch reduzieren.

Typischerweise greifen Unternehmen bei Grossvorhaben gerne auf die Dienste von externen Beratern zurück, vor allem in Unterstützungsfunktionen. Dies ist grundsätzlich kein Problem, jedoch besteht ein inhärenter Interessenkonflikt. Das klassische Problem der Principal-Agent-Theorie. Während der Auftraggeber ein schlankes und effizientes Projekt haben möchte, um möglichst schnell zum Ziel zu kommen, muss das nicht zwingend den Zielinteressen der externen Berater entsprechen, denn: Ein undurchschaubares Projekt ist eine Gelddruckmaschine für alle Berater und Experten dieser Welt. Weil Komplexität Effektivität versteckt und dadurch Effizienz verunmöglicht. Scheinprobleme werden geschaffen und aufwendig diskutiert, in PowerPoints analysiert und in Besprechungen sind alle paralysiert.

Ich stelle jetzt mal die gewagte These auf, dass man es vielerorts nicht immer bemerken würde, wenn Berater plötzlich nicht mehr vor Ort wären. Erfahrungsgemäss verursachen externe Berater leider zu oft Komplexität, indem sie beispielsweise Zusammenarbeitsmodelle konstruieren, welche bloss sie selbst noch verstehen und erklären können - eine Art Unendlichkeitsmaschine für Berater. In der Principal-Agent Theorie spricht man hier von Informationsasymmetrie.

Wir sind überzeugt, dass grösser nicht immer besser ist. Wir glauben an erfolgreiche Teams und erfolgreiche Projekte, die von allen verstanden und getragen werden können. 

2) Notwendig: Illusion der Parallelisierung vergessen

Parallelisierung lockt und verführt einen stets. Parallel mehr liefern, möglichst effizient Ressourcen auslasten - so die Maxime. Das ist und bleibt eine Illusion. Umso grösser das Projekt, desto weniger kann parallelisiert werden. Ob thematisch oder in Projektphasen. Alles andere ist grob fahrlässig und verantwortungslos. 

Ein Thema gemeinsam beginnen und gemeinsam beenden. Ein Thema analysieren, konzipieren, implementieren, testen und einführen. Und zwar möglichst "kleine" Themen. Idealerweise natürlich in einem 2-Wochen-Sprint. Falls das nicht möglich ist, maximal in einer Quartalsiteration. Projekte sind ohnehin privilegiert, weil sie keinen Betrieb sicherstellen müssen. Diese Chance muss man mit der kompromisslosen Fokussierung und einer Ein-Thema-Strategie nutzen.

3) Daraufhin: Priorisieren und priorisieren

Die Ein-Thema-Strategie bedingt eine ebenso konsequente Priorisierung. Womit beginnen? Was ist das erste Thema? Priorisieren kann entweder eine einzige Person oder eine Art Expertenregierung. So oder so dürfen die Prioritäten sich dauernd ändern. Ein Mehrjahresplan ist weder üblich noch hilfreich. Priorisieren und dadurch Planen ist vielmehr eine gemeinsame Lernreise - und die Wahrheit ist stets die Lieferfähigkeit des Teams. 

4) Im Kern: Ein simplifiziertes Zusammenarbeitsmodell

Grosse Projekte und viele Berater mögen ein "angemessenes" Zusammenarbeitsmodell. Etliche Rollen, meist dreifach besetzt, zieren die Programmorganisation. Diese Rollen müssen naturgemäss abgegrenzt werden; komplexe AKV-Tabellen und RACI-Matrizen schmücken die Projektablage.

Die Durchlaufzeit sowie beteiligte Rollen für ein Thema sind immens. Machen wir dafür ein einfaches Beispiel, welches so vermutlich mehrmals täglich in Schweizer Unternehmen passiert: Für ein IT-Anforderung muss beispielsweise ein Business Engineer ein Grundlagenkonzept erstellen, welches zunächst von einer Facharchitektur-Stelle gereviewt wird. Daraufhin erstellt eine Person dieser Facharchitektur-Stelle ein übergreifendes Lösungskonzept. Dieses greift ein Business Analyst auf und verfeinert die IT-Anforderungen zur nächsten Detaillierungsstufe. Eine der Lösung wesentlich vertrautere Person aus der Facharchitektur muss dies wiederum prüfen. Zudem kommen spätestens zu diesem Zeitpunkt das Testing sowie eine zentralisierte Architektur-Rolle ins Spiel, welche nicht-funktionale Aspekte wie Sicherheit, Wartbarkeit etc. für die Organisation sicherstellen sollen. Schliesslich muss die Software-Entwicklung die Anforderung weiter spezifizieren, bevor die Entwicklung - im Idealfall in Schaffhausen oder in Biel, im Nicht-so-Idealfall in Bratislava oder im Gar-Nicht-So-Idealfall in Indien - etwas aufgrund etlicher Dokumente, welche aber aufgrund von einem enormen Kostendruck kaum studiert werden, entwickelt und ausliefert. Das Ganze möchte dann eine Fachvertretung abnehmen. Dieser hochkomplexe Prozess produziert automatisch Verschwendung, Papier und verlängert die Durchlaufzeit. Ach ja, getestet, installiert und unterschrieben muss das alles auch irgendwann und irgendwie werden. 

Ein solches Zusammenarbeitsmodell scheitert in vielen Fällen. Die Frage ist bloss, wann die Organisation das Scheitern akzeptiert. Typischerweise berichtet man nach oben (aussen) grün, obwohl (innen) bereits alles rot ist - Wassermelonen-Projekte halt.

Das vereinfachte Zusammenarbeitsmodell basiert auf maximal drei PowerPoint Folien. Wir haben für grosse Transformationen auch schon ein Zusammenarbeitsmodell auf einer Folie definiert - Es ist möglich. Es ist maximal vereinfacht und verständlich. Wir vereinfachen. Das muss auch die Prämisse eines Zusammenarbeitsmodells sein: Einfach, klar und verständlich. Alles andere ist kein Zusammenarbeitsmodell mehr, sondern eine marktfremde und kapitalvernichtende Selbstbeschäftigung.

Ein Zusammenarbeitsmodell basiert auf maximal fünf Rollen - mehr sind auch nicht notwendig, sondern blosse Verschwendung. 

5) Es einfach und gemeinsam machen

Grosse Vorhaben haben bekanntlich viele Rollen, viele Teams, viele Mitarbeitende. Man arbeitet schon irgendwie zusammen - das Zusammenarbeitsmodell erklärt dabei entweder eine dreitägige Schulung oder achtzig PowerPoint-Folien im Winkelried-Selbststudium. Keine gemeinsame Vision ist bemerkbar oder begründet und beseelt die Arbeit aller Mitarbeitenden. Das wäre noch verkraftbar. 

Wesentlich kritischer ist jedoch die psychische und physische Abgrenzung der Mitarbeitenden. Teams, Rollen und Menschen bekämpfen sich mancherorts letztlich gegenseitig. Es ist kein Miteinander. Der Fachbereich sitzt im Bau A, der Lieferant ist ohnehin daheim, die Berater pendeln hin und her, die Entscheider verstecken sich im Bau B, die Gremien tagen stets im VR-Saal vom Bau C, weil man sich endlich wichtig fühlen darf. 

Die ultimative Massnahme ist, alle Projektmitarbeitende per sofort zu zentralisieren. Auch trotz Corona  dürfen Menschen (unter den notwendigen Bedingungen und Sicherheitsvorkehrungen) zusammenarbeiten. Das heisst, sie dürfen gerne Abstand wahren. Notfalls dürfen sie auch Masken tragen. Das Projekt tagt fortan bloss noch im Bau A, besetzt dort so viele Stockwerke wie notwendig. Die Teams sind per sofort interdisziplinär und nicht politisch geschnitten. Es möglichst einfach und vor allem gemeinsam tun. 

Und dein Projekt?

Ist dein Projekt auch zu gross? Brauchst du eine Art Assessment? Brauchst du einen Befreiungsschlag? Brauchst du Unterstützung? Wir sind unbefangen, aber erfahren, und helfen dir mit Agile Coaching - damit deine Projekte wieder einfacher, verständlicher und klarer werden.

Meeting mit David

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst.

Newsletter Anmeldung