Projekte — Grenzen — Transparenz

Manchmal liegen Themen in der Luft: Ende November 2019 habe ich mich zusammen mit Markus Zimmermann von der M19-Organisationsberatung mit einem Paper für das nächste ISPSO Anual Meeting 2020 in Berlin beworben, jetzt der Aufruf zur Blog-Parade vom projektmagazin.de.

Thematische Nachbarn: Die Beiträge für das ISPSO-Symposium sollen das Verständnis der Mauern in uns als Abwehr gegen Ängste, Innovation und Andersartigkeit fördern. Das Projektmagazin fragt nach Fluch und Segen des Abbaus von Grenzen im Projektumfeld, versteht den Abbau von Grenzen als Vergrößerung der Transparenz und fragt sich, ob die „offene Zusammenarbeit über Abteilungs-, Unternehmens- und Branchengrenzen hinweg von der Ausnahme zum Regelfall“ werden wird.

Mauern wie Grenzen sind nicht per se gut oder schlecht, beide können schützen und für Struktur sorgen, aber auch einengen, begrenzen, behindern und einsperren; es kommt auf den Kontext an.

Erst beim zweiten Lesen des Aufrufs zur Blog-Parade kommt mir die Frage: Ist es wirklich so, das Grenzen und Transparenz¹ für entgegengesetzte Pole auf einer gemeinsamen Skala stehen? Also: bedeuten mehr Grenzen gleichzeitig weniger Transparenz und umgekehrt? Auch wenn sich dieser Schluss durch eine gefühlte Kohärenz aufdrängt und keines weiteren Gedankens wert zu sein erscheint, denke ich: Da spielt uns die Sprache (und unser System 1) einen Streich, es kommt auf die Art der Grenze an.

Fangen wir mit den territorialen Grenzen in Organisationen an, den Grenzen zwischen den Abteilungen eines Unternehmens, mit ihrer jeweils eigenen spezifischen Perspektive, die für die „Bewohner“ dieser „Silos“ oft die einzig richtige ist, sodass sie wenig bis gar kein Verständnis für diejenigen der anderen haben. Eine eigene Sichtweise ist zunächst einmal aus der jeweiligen funktionalen Spezialisierung verständlich und nachvollziehbar. Schließlich ist die Verteilung des Know-hows und der Aufgaben auf Spezialisten mit unterschiedlichem Schwerpunkt heute unabdingbar – und so ist sie eben entstanden, diese Ausdifferenzierung, z.B. der IT-Aktivitäten in Analyse, Design, Entwicklung, Test, Deployment, Betrieb und Administration, Support, etc.

Das erklärt aber noch nicht, warum sich Abteilungen oft so gegeneinander abschotten, dass die Einhaltung von Schnittstellenkontrakten mit der Zeit immer wichtiger wird, der Blick für das große Ganze hingegen nach und nach verloren geht und mühsam immer wieder in den Fokus zurückgeholt werden muss. In sehr differenzierten Unternehmensstrukturen, die eine große Anzahl der auf diese Weise zu Silos regredierten, unterschiedlichen Abteilungen aufweisen, geht die Transparenz und der Überblick verloren. Niemand lässt sich dort mehr gerne in die Karten blicken, was dann durch ein komplexes und ausgeklügeltes Berichtswesen versucht wird, abzumildern.

So weit, so erwartbar.

Prozesse

Es ist eigentlich der Zweck von Organisationen, insbesondere von Unternehmen, dass Menschen innerhalb des Organisationsrahmens möglichst reibungslos² zusammenarbeiten, um etwas zu schaffen oder zu bewältigen, was durch ein Individuum schon gar nicht, aber auch nicht mehr durch ein kleines schlagkräftiges Team zu schaffen ist. Um die dafür notwendige Zusammenarbeit zu unterstützen, werden für wiederkehrende, mehr oder weniger standardisierte Abläufe Prozesse definiert, die abteilungsübergreifend ausgeführt werden. Sie dienen der Re-Integration der vielen spezialisierten Einzelleistungen, sodass im Sinne des Gesamtzieles der Organisation etwas erreicht, prozessiert und geschaffen wird.

Für jeden Schritt eines Prozesses, wird festgelegt, welche Rolle (deren Rollenträger dann natürlich zu irgendeinem Abteilungssilo gehört) in welcher Funktion, mit welcher Kompetenz welche Aktivität auszuführen hat und wieviel Zeit ihr dafür zur Verfügung steht. Auch die Daten, Informationen und sonstige Artefakte, die durch diesen Prozess durchgeschleust werden, sind in Qualität, Quantität und Format definiert. Regeln dienen der Entscheidungsunterstützung oder -automatisierung.

Case Management

Sind Prozesse zu unflexibel, weil die auszuführenden Aktivitäten sich doch je nach „Fall“ unterscheiden oder die Reihenfolge mal so, mal anders sein muss, wird auch auf Case Management ausgewichen, wobei ein Case ein Container ist für alle zum Fall gehörenden Informationen, Daten oder sonstigen Artefakte und auch eine grobe Richtschnur der für einen Fall verpflichtenden und optionalen Aktivitäten enthält; auch Regeln sind einem Case nicht gänzlich fremd.

Projekte

Kann für Prozesse und Case Management zumindest noch die Illusion der Wiederholbarkeit gehegt werden, so werden Projekte immer zum ersten und gleichzeitig letzten Mal, also nur ein einziges Mal, durchgeführt. Und ist bei Prozessen die Regel, dass Ausnahmen (unter allen Umständen) vermieden werden müssen, so wird spätestens bei Projekten die Ausnahme zur Regel.

Ein weiterer Unterschied ist, dass in Prozessen die Träger einer Rolle, also die jeweiligen Menschen, die eine Rolle gerade ausfüllen und ausführen, ausgetauscht werden können – vorausgesetzt, sie sind in ihrer Rolle ausreichend kompetent – weil alle erforderlichen Informationen im Idealfall im Prozess mitgeführt werden. Bei Projekten bemerkt man hingegen sehr deutlich einen Einbruch der Produktivität, wenn jemand im Urlaub oder krank ist oder aus anderen Gründen das Projekt verlassen hat, selbst wenn nominell ein Ersatz oder eine Vertretung verfügbar ist. Das gilt selbst dann, wenn alles im Projekt akribisch dokumentiert wird. Auch dokumentiertes Wissen muss in den Köpfen der Projektbeteiligten erst aktiviert werden, bevor es nutzbar wird: es geschieht immerhin alles zum ersten Mal. Und oft existiert ein großer Teil des für ein Projekt benötigten Wissens sowieso nur in den Köpfen der Projektbeteiligten, weil es viel zu aufwendig wäre, für diese einmalige Durchführung alles in Dokumenten niederzulegen.

Projektprozesse und Prozessprojekte

Ich höre schon Ihren Einwand: Und was ist mit Wasserfallprojekten und z.B. dem V-Modell oder ähnlichen Vorgehens-Modellen? Da geschieht doch genau das: Alles wird akribisch in Spezifikationsdokumenten jeweils unterschiedlicher Granularität und Detailtiefe definiert, um dann nach dem Review an die nächste Stufe übergeben zu werden. – Ja, das ist richtig. Das ist m.E. aber nur der mehr oder weniger taugliche (meinetwegen auch untaugliche) Versuch, das Prozessparadigma – Sie erinnern sich: es setzt Wiederholbarkeit, Regelhaftigkeit und Standardisierung voraus – auf einzigartige und einmalige Vorhaben zu übertragen. Es entsteht ein Hybrid, ein Projektprozess/Prozessprojekt, in dem die eigentlich nur der Steuerung, Informationsspeicherung und -weitergabe dienenden Artefakte im Laufe der Zeit fast schon einen Fetischcharakter bekommen, über den das eigentliche Ziel eines Projektes droht, aus den Augen verloren zu werden:

Output rules. Outcome suffers.

Agilität als Ausweg

In einem Projekt alles zum ersten Mal zu machen, bedeutet auch: es ist anstrengend und das nicht nur, weil sich ein Projektteam erst einmal finden und formieren muss. Ein Grundgedanke des agilen Vorgehens ist aus meiner Sicht, die Rahmenaspekte soweit zu standardisieren und vor allem zu vereinfachen, wie es ohne negativen Einfluss auf das zu erzielende Ergebnis möglich ist. So stehen dann Teamstruktur, Rollen und ihre Verantwortlichkeiten, der zeitliche Rahmen, die Standardereignisse, usw. von vorneherein durch das anzuwendende agile Framework fest. Scrum besteht z.B. im Wesentlichen nur aus 5 Ereignissen, 3 Rollen und 3 Artefakten.

Darüber muss dann jedenfalls nicht immer wieder neu entschieden werden (was eine fortlaufende Verbesserung, z.B. als Ziel von Retrospektiven nicht ausschließt). Dann kann sich das erfahrene Team auf die Inhalte konzentrieren, während der Rahmen vertraut ist und zu etwas Gewohntem wird. Damit die Inhalte auf die einfachen agilen Strukturen passen, werden sie solange in kleinere Teile geschnitten, bis sie überschaubar und gut genug verstanden sind, um in den gesetzten Grenzen (Teamgröße, Kompetenzverteilung im Team, Velocity, Sprintlänge) realisiert zu werden. Das ist das genaue Gegenteil davon, die Komplexität der Projektstrukturen solange aufzublasen, bis sie auf die vermutete Komplexität des zu erzielenden Projektergebnisses passen. Das bedeutet auch eine andere Organisationsstruktur (implizit also auch andere Grenzen): statt auf spezialisierte Abteilungen wird auf cross-funktionale Teams gesetzt.

Obwohl man dieses Vorgehen mit Fug und Recht als Prozess bezeichnen kann, so ist dieser agile „Prozess“ doch in wesentlichen Aspekten anders als die oben beschriebenen Geschäftsprozesse: Zum einen ist nur die Meta-Struktur standardisiert (auch wenn diese in Form der Retrospektiven einer ständiger Verbesserung und damit Veränderung unterworfen ist). Zum anderen ist die Illusion der Wiederholbarkeit nicht mehr aufrechtzuerhalten: Eine im 4. Sprint realisierte User Story wird im Ergebnis anders ausfallen als „dieselbe“ Story im 15. Sprint: Das Team verändert sich, der Zeitpunkt, an dem eine Story aus dem Product Backlog entnommen wird, führt zu einer anderen Bewertung aus geschäftlicher Perspektive („das Geschäft“ hat sich in der Zwischenzeit ja auch geändert), usw.

Ein abteilungsübergreifender Prozess wird daraus nur dann, wenn DevOps ins Spiel kommt, mit den vormals „natürlichen Feinden“ Entwicklung und Betrieb mit ihren unterschiedlichen Perspektiven, begründet und herausgebildet aus der sich im Laufe der Zeit zunehmenden Komplexität der IT-Technologie und der notwendigen Spezialisierung der damit verbundenen Aufgaben. Und auch nur dann, wenn DevOps nicht auch gleich zu einer organisationalen Zusammenlegung von Entwicklung und Betrieb in eine Abteilung genutzt wird.

Womit ich wieder zum Anfang des Beitrags zurückkehre und zu der Ausgangsfrage, ob mehr Grenzen weniger Transparenz bedeuten und umgekehrt oder allgemeiner gesprochen:

Wie ist das Verhältnis zwischen Grenzen und Transparenz eigentlich generell?

BART

Ein einfaches, aber effektives Hilfsmittel, um über Organisationen nachzudenken, ist für psychodynamische Organisationsberater das BART-Modell:

• Boundaries
• Authority
• Role
• Task

mit den drei wichtigsten Arten von Grenzen: Time, Task, Territory; was nicht heißt, dass nicht auch weitere Arten von Grenzen, wie z.B. die von Autorität und Rollen wichtig werden können .

Wenn man sich vor dem Hintergrund dieses Modellrasters die obigen Abschnitte über Prozesse, Case Management, Projekte und agiles Vorgehen noch einmal ansieht, dann stellt man schnell fest: Überall existieren die unterschiedlichsten Arten von Grenzen, die auch alle in ihrem jeweiligen Kontext wichtig sind und beachtet werden müssen. Was aber aus meiner Sicht viel wichtiger ist: Sie stehen der Transparenz nicht entgegen, teilweise ermöglichen sie diese überhaupt erst.

Ein Beispiel aus dem agilen Umfeld:

Gäbe es bei Scrum keine feste Sprint-Länge, die als zeitliche Grenze unverrückbar ist, komme was wolle (ist sie es nicht, so ist es nicht Scrum sondern Scrum-But) und gäbe es keine Definition-of-Done (nur was gemäß der Definition „done“ ist, ist auch fertig) als inhaltliche Grenze, die genauso verbindlich ist, dann gäbe es auch keinen Maßstab, anhand dessen das Team ermitteln könnte, ob es sich in einem Sprint bei der Planung übernommen hat oder nicht. Entweder hat das Team die User Stories im Sprint geschafft oder nicht. Erst diese beiden Grenzen (zeitlich und qualitativ) ermöglichen die für eine kontinuierliche Verbesserung erforderliche Einsicht in die Realität. Diese Grenzen schaffen erst die für das Lernen notwendige Transparenz; die aus der Grenzziehung resultierenden Fakten kann man nicht mehr in Frage stellen.

Outcome vs Output

Haben dann Grenzen überhaupt einen negativen Einfluss auf Transparenz? Ja, doch, sehr wohl, aber wie ich in der Einleitung schon bemerkt habe: die Art der Grenzen ist ausschlaggebend.

Dienen territoriale Grenzen zwischen den Abteilungen weniger der funktionalen Spezialisierung als der Sicherung von Macht und Einfluss, dann stehen sie der Transparenz entgegen.

Dienen die über die Grenzen zwischen den Prozessschritten weitergereichten Artefakte also eher der Abwehr (der „Anderen“) als dem Ziel der Informationsweitergabe, -anreicherung und -vermehrung, dann stehen sie der Transparenz entgegen. Wenn sie einmal Fetischcharakter angenommen haben („solange dieses Excel-Sheet nicht genauso ausgefüllt ist, wie wir es brauchen, können wir nicht mit der Arbeit anfangen“), gerät das eigentliche Ziel aus den Augen.

Die Transparenz (Wie ist der Status in Bezug auf die Zielerreichung?), die auf Outcome fokussiert, wird ersetzt durch eine Art von Pseudotransparenz (Wie ist der Status in Bezug auf das Ausfüllen der Artefakte?), die sich weitgehend nur für den Output interessiert.

Abwehrmittel gegen Silos

Bleibt noch die Frage offen, wie solche starren und undurchlässigen Grenzen zwischen Abteilungen, die der Abschottung dienen und die Integration spezialisierter Arbeit zu einem Gesamtergebnis behindern, entstehen und wie man das verhindern kann?

Pauschal ist das nicht zu beantworten. Für die Betrachtung des Einzelfalls dazu nur ein paar Hinweise auf Tendenzen in Form von Schlüsselfragen:

• Sind die Grenzen überhaupt klar definiert?
• Herrscht bei allen Beteiligten Klarheit und Übereinstimmung über den Verlauf von Grenzen?
• Hat es in der Vergangenheit als gravierend empfundene Grenzverletzungen und -überschreitungen gegeben?
• In welchem Verhältnis stehen die Kommunikationsmedien „Vertrauen“ und „Macht“? Was herrscht vor? – Zwischen Silos meist Letzteres; das schließt persönliche Vertrauensverhältnisse auf Arbeitsebene nicht aus.
• Gibt es Personen, die die (meist informelle) Rolle von „Integratoren“ ausüben? Man erkennt sie meist an erworbenem Respekt und persönlicher Autorität.
• Ist ein Konfliktlösungsverfahren etabliert oder besteht nur die Option einer hierarchischen Eskalation?
• Welcher Modus im Umgang mit Konflikten herrscht vor?
• Wie steht es mit Interesse für einander, Wertschätzung und Respekt in der Organisationskultur?
• Wie und in welchem Ausmaß unterscheidet sich die Kultur in den Silos?

Grenzen sind unvermeidbar

In Projekten und nicht nur dort sind Grenzen unvermeidbar. Das Vorhaben, sie niederreißen zu wollen, ist von vorneherein zum Scheitern verurteilt.

Es kommt vielmehr darauf an, dass und wie Grenzen gestaltet werden.

Soweit für jetzt.

Update (25.02.2020):
Die Nachlese und Zusammenfassung der Beträge zur Blog-Parade ist online³.