Sinnlose Meetings müssen nicht sein. Einige Tipps für frustfreie Meetings.

Meetings müssen nicht ärgerlich, langweilig und frustrierend sein. Dass die meisten sinnlos sind, sollte nicht von der Erkenntnis ablenken, dass Meetings – wenn sie richtig gestaltet werden – eine lebenswichtige Kommunikationsebene in einem Unternehmen darstellen. In einem Meeting werden sehr viele Informationen ausgetauscht: fachliche Fakten, organisatorische Vorgaben, teamdynamische Aspekte wie Führungsanspruch und Zusammengehörigkeit. Meetings sind wichtige soziale Ereignisse in der Gruppe, in denen die so oft beschworene Unternehmenskultur sichtbar gelebt wird. Gerade in ausgeprägten Projektorganisationen, die üblicherweise schnelllebiger sind als auf Linienmanagement basierende Organisationen, stellen Meetings eine Chance dar, unkompliziert und effizient mit dem Projektteam zu kommunizieren.

Damit ein Meeting klappt, müssen allerdings einige allgemeine Regeln etabliert werden.  Diese lassen sich in zwei Arten unterscheiden: allgemeine Rahmenbedingungen und Regeln, die sich auf konkrete Meetings beziehen.

Grundsätzliche Regeln:

1. Ressourcenschonung: Meetings dürfen nur stattfinden, wenn andere, effizientere Maßnahmen nicht zielführend erscheinen.
2. Erwartungshaltung: Meetings sind keine Workshops:
   - Workshops sind als moderierte Diskussionen zu verstehen.
   - Meetings dienen dem Informationsabgleich und der Entscheidungsfindung.
3. Entscheidungsfindung: Ergebnis eines Meetings ist eine Liste von Entscheidungen.
4. Entscheidungsinhalt: Entscheidungen enthalten immer drei Aussagen: wer was bis wann liefern wird (im Unterschied zu Beschlüssen, mit denen nur das „Was“ festgehalten wird).
5. Umsetzung: Entscheidungen werden umgesetzt und ihre Umsetzung geprüft.
6. Verbindlichkeit: Alle Meetingregeln gelten für alle (interne und externe Teilnehmer, Chef eingeschlossen).

Auf Workshops wird im Folgenden nicht weiter eingegangen.

Bei der Durchführung eines Meetings haben sich folgende Regeln als hilfreich erwiesen:

1. Vorbereitung: Meetings werden rechtzeitig im Voraus an alle Teilnehmer kommuniziert: die Uhrzeit, der Ort, die Agenda und die Liste aller eingeladenen Personen.
2. Teilnehmerkreis:  Relevante Entscheider und Meinungsmacher werden eingeladen.
3. Timing: Meetings beginnen und enden pünktlich.
4. Redestil: Jeder fasst sich möglichst kurz und überlässt schleunigst anderen das Wort.
5. Verbindliche Agenda: Sprecher bleiben beim Thema und eröffnen keine Nebenkriegsschauplätze. Komplexe Themen werden im Nachgang geklärt.
6. Ad rem: Persönliche Angriffe sind tabu.
7. Keine Hexenjagd: Schuldzuweisungen („Man hätte … sollen“) sind tabu.
8. Diversität: Abweichende Meinungen und Ideen sind willkommen.
9. Lösungsorientierung: Zu Problemen werden konkrete Lösungsvorschläge „mitgebracht“.
10. Diskretion: Interne Themen werden in Anwesenheit externer Gäste (etwa Lieferanten, Kunden) nicht besprochen.
11. Beschlussfähigkeit: Schweigen bedeutet Zustimmung.
12. Nachbereitung: Es gibt exakt zwei Meetingergebnisse: Informationen und Entscheidungen (s. Grundsätzliche Regel 3). Sie werden im Anschluss an alle Teilnehmer verteilt.

Es hat sich vielerorts bewährt, diese Liste (auch als „Meeting Ground Rules“ bekannt) im Meetingraum auszuhängen, sodass man sich im Zweifel immer auf verbindliche Rahmenbedingungen berufen kann.

Natürlich genügt es nicht, gerahmte Meeting Ground Rules auszuhängen – sie müssen auch gelebt werden. Die Regeln müssen aktiv kommuniziert und im verbindlichen Managementhandbuch formell veröffentlicht werden. Auch ist zu beachten, dass für jedes Meeting der Organisator bekannt sein sollte, damit Fragen im Vorfeld geklärt werden können.

Derartig stringente Meetingregeln mögen den Eindruck evozieren, dass Meetings nur gelingen könnten, wenn sie mit militärischer Disziplin durchgepeitscht werden. Die Praxis zeigt jedoch genau das Gegenteil: So organisierte Meetings sparen eine Menge Geld und Frust für alle Beteiligten. Schließlich arbeiten die meisten von uns am liebsten in einem professionellen Umfeld, in dem unsere stets knappe Zeit nicht sinnlos verschwendet wird. Die vielerorts grassierende Meetingitis kann so durch Meetings mit Hand und Fuß ersetzt werden, und die Meetings machen wieder Spaß – versprochen!

• Was sind die Herausforderungen der allgegenwärtigen Software, ja, man kann sagen: der „Software-Gesellschaft“?
• Welche Kompetenzen werden notwendig sein, um diese Herausforderungen in wirtschaftliche Potenziale zu verwandeln?
• Wie kann ich meine jetzigen Anstrengungen im Bereich Kompetenzausbau so ausrichten, dass diese Kompetenz auch für die Zukunft ein Erfolgsfaktor ist?

Die Keynotes lauten:

• „Vernetztes Fahrzeug – wie bleibt dieses sicher, beherrschbar und benutzerfreundlich?“, Hans-Georg Frischkorn, Executive Vice President Division Automotive bei der ESG
• „Das Fahrzeug als mobile Internetplatform – Mobilität durch intelligente Vernetzung“, Giuseppe Mascolino, Leiter Software Architektur und Prozesse bei BMW
• „Intuition und Meditation als Schlüsselkompetenzen für das Management der Zukunft“, Gerhard Conzelmann, Vorsitzender des Internationalen Shaolin Instituts
• „Open Minds Economy – die Community-basierte Gestaltung unserer Zukunft“, Dr. Karl-Heinz Strassemeyer, Ehrenvorsitzender der OSB Alliance

Neu sind in diesem Jahr die Praxisforen, bei denen zu jeweils einem Thema drei bis vier Leute vom Fach ihre Erfahrungen darstellen und dann in einer Podiumsdiskussion in einen Dialog mit den Konferenzbesuchern treten.

Man nennt sie internationale oder globale Projekte. Sie tauchen heutzutage in den meisten Unternehmen auf und bereiten den Projektmanagern Kopfzerbrechen. Die Rede ist von Projekten, die nicht nur standort-, sondern auch länderübergreifend durchgeführt werden und in einer multilingualen Umgebung stattfinden.

Wegzudenken sind solche Projekte für Unternehmen natürlich nicht, um wettbewerbsfähig zu bleiben. Ganz klar. Wie aber internationale Projekte durchführen, wenn in Projekten hierzulande bereits Chaos herrscht?

Nun, man muss das Projekt mal Projekt sein lassen, denn wenn man ein paar allgemeine Regeln beachtet, gestalten sich internationale Projekte im Grunde genommen auch nicht komplizierter als x-beliebige. Wie auch in nationalen Projekten gilt hier: Planung und Organisation sind alles.

Babylonisches Sprachgewirr

Die größte Herausforderung bei internationalen Projekten ist wahrscheinlich die Kommunikation untereinander. Nun wäre es natürlich am einfachsten, sich mit seinen Teamkollegen direkt auszutauschen. Diesen Luxus gibt es in internationalen Projekten jedoch logischerweise nur ganz selten. Daher sollte man zunächst eine Kommunikationsstrategie ausarbeiten, in die alle Projektteams einbezogen und wofür die nötigen Werkzeuge bereitgestellt werden.

Schlechte Kommunikation führt nicht nur zu Fehl- oder verspäteten Informationen, wesentliches Wissen kann auch ganz verloren gehen. Dies wäre für ein Projekt fatal, da hierdurch Zeitvorgaben und Ergebnisse negativ beeinflusst werden.

Zum Teil kann man die Schuld an fehlerhafter Kommunikation auch Kommunikations- und Dokumentationswerkzeugen zuschreiben, die nicht gerade einfach in der Handhabung und für verteilte Teams nicht unbedingt geeignet sind. Der unstrukturierte Austausch von Projektinformationen, wie er über E-Mails und Dokumente vorgenommen wird, erschwert die effektive Zusammenarbeit zwischen allen Projekt-Stakeholdern zusätzlich und macht es ihnen nahezu unmöglich, Fortschritt, Ereignisse und Prozesse lückenlos zu verfolgen. Tatsächlich benötigen globale Projektteams eine Kommunikations- und Projektmanagement-Plattform, die Informationen bündelt und zumindest die Vorteile aufweist, die man sonst nur von einer Zusammenarbeit mit lokalen Projektteams kennt.

Bei der Erstellung einer Kommunikationsstrategie muss Folgendes bedacht werden:

• Entfernung – Globale Projekte bedeuten immer verteilte Teams und Stakeholder. Diesbezüglich bleibt der persönliche Umgang mit Teammitgliedern auf der Strecke. Die Entwicklung einer Strategie, die gemeinsame Meetings in regelmäßigen Abständen vorsieht, führt zu einem besseren Zusammenhalt des Teams und dazu, dass auf Engpässe und andere Ereignisse schneller reagiert werden kann. Nichts ist für Manager, Stakeholder und Teammitglieder so realitätsnah wie der persönliche Umgang miteinander, daher ist es wichtig, die Zeit für persönliche Meetings in der Strategie zu berücksichtigen.

• Sprache – Normalerweise arbeiten globale Teams in einer multilingualen Umgebung. Die sprachlichen Hürden führen häufig zu Verzögerungen und fehlerhafter oder inakkurater Informationsübertragung. Das Festlegen einer Standardsprache, in der die Kommunikation stattfinden soll, ist unerlässlich.

• Unternehmenskultur – Besonders bei globalen Teams unterscheiden sich Führungsstile und Arbeitsweisen. Die unterschiedlichen Kulturen müssen im Team bekannt sein. Nur so kann das gesamte Team seine Produktivität steigern, und nur so sind Manager und Stakeholder in der Lage, eine ähnliche Erwartungshaltung beim Auftreten von Problemen einzunehmen.

• Zeitzonen – Die Arbeit mit internationalen Teams führt dazu, dass rund um die Uhr Aktivitäten und Ereignisse stattfinden. Projektleiter müssen deshalb eine Strategie entwickeln, die regelmäßige strategische Meetings mit wenigen ausgewählten Mitgliedern des Teams vorsieht. Nur so wird sichergestellt, dass das Gesamtziel in den entsprechenden Regionen verfolgt wird. Hinzu kommt, dass die regionalen Stellvertreter hierbei auch als Informanten der jeweiligen Region fungieren und Informationen direkt an das globale Management weitergeben können.

• Zugriff auf Informationen – Die Herausforderung, dass ein globales Team auf alle relevanten Informationen zugreifen kann, ist in dieser Form der Projektumgebung größer als in jeder anderen. Selten haben globale Projektteammitglieder die Möglichkeit, einfach mal eben zum Schreibtisch eines Kollegen herüberzugehen und diesem eine Frage zu stellen. Folglich ist eine formelle Strategie, die Projektdetails dokumentiert und die nötigen Mittel dazu liefert, damit sofort auf wichtige Informationen zugegriffen werden kann, enorm wichtig, um ein Projekt effektiv auf eine erfolgreiche Fährte zu führen.

Auch wenn globale Projekte einzigartigen Herausforderungen bezüglich Kommunikation und Entscheidungsfindung unterliegen, stellt der Einsatz globaler Talente für Unternehmen häufig einen Mehrwert für das Portfolio ihrer Projekte dar. Da wichtige Informationen heutzutage über das Web zugänglich sind, hierfür keine horrenden Kosten entstehen und die Welt über eine unbegrenzte Fülle von Talenten verfügt, nutzen Unternehmen ihre Größenvorteile für sich und können ihren Kunden dadurch bessere Ergebnisse liefern.

Der hiesigen Wirtschaft geht es derzeit verblüffend gut. Dafür gibt es sicherlich eine Reihe volkswirtschaftlicher Gründe. Der wichtigste aber ist die Ausrichtung der Exportindustrie auf den Systembau.

Es ist schon erstaunlich, wie schön der Exportmotor hierzulande brummt. Schuldenkrise hin oder her – deutsche Produkte scheinen im Ausland extrem begehrt zu sein. Die Exportquote (Anteil der Ausfuhren am Bruttoinlandsprodukt) beträgt inzwischen satte 40 %, Tendenz steigend. Von solchen Zahlen können die meisten Länder nur träumen.

Die Automobilindustrie ist dabei ein Paradebeispiel. VW, Daimler und BMW zahlen ihren Mitarbeitern nie dagewesene Prämien. Auf den Audi Q5 muss man mindestens zwölf Monate lang warten. Und es werden verzweifelt qualifizierte Mitarbeiter für den Automobilbau gesucht.

Neben den volkswirtschaftlichen Faktoren, unter denen insbesondere die Rolle der gemeinsamen EU-Währung von großer Bedeutung ist, fällt ein Umstand besonders ins Gewicht: In Deutschland werden offensichtlich attraktive Produkte hergestellt. Dabei handelt es sich nicht um Rohstoffe, rein mechanische Produkte oder reine Software – es geht um komplexe Systeme mit Hardware- und Softwareanteilen.

Die Verbindung von Hard- und Software spielt eine immer wichtigere Rolle. Ein modernes Fahrzeug enthält Dutzende von Prozessoren, die alle softwaretechnisch umfangreich ausgestattet sind. Diese Hardware wird mit ausgeklügelter Software erst richtig wertvoll gemacht. Ob es sich um ABS-Systeme, Aktivlenkung oder das Unterhaltungssystem handelt – Hard- und Software gehen da stets Hand in Hand. Wenn zudem das Design noch stimmt – und das scheint bei hiesigen Autoherstellern häufiger als anderswo zu gelingen –, dann ist ein Fahrzeug ein Produkt, dass seine Marktpotenziale lange ausspielen kann.

Diese Stärke ist kein Zufall, sondern logische Folge der konsequenten Systemdenke, die Hard- und Software systematisch vereint.

Reine Hardware im weitesten Sinne, zum Beispiel RAM-Bausteine im Computerbau oder mechanische Bauelemente, sind leicht zu kopieren, in Fernost billiger herstellbar, oder beides. Derartige Produkte (bestes Beispiel: Unterhaltungselektronik) haben an teuren Standorten wie hierzulande keine Zukunft.

Reine Softwareerzeugnisse sind zwar sehr flexibel, jedoch intrinsisch leicht zu kopieren, patenttechnisch (zumindest hierzulande) schwer zu schützen, relativ leicht und (je nach Standort) günstig herzustellen und daher flüchtig wie Äther. Abgesehen von wenigen Schwergewichten wie Microsoft, Oracle oder SAP ist reine Software strategisch gesehen traditionell eine riskante Wette.

Eine Kombination aus Hard- und Software dagegen vereint die Stärken beider Komponenten. Sie ist schwer zu kopieren, relativ leicht zu entwickeln, flexibel und lässt sich patentrechtlich schützen.

Darüber hinaus sind psychologische Aspekte der Produktgestaltung nicht zu vernachlässigen. Menschen kaufen gern etwas, das sie in die Hand nehmen können. Der Wert – und damit der Preis – von „Produkten zum Anfassen“ wird unbewusst höher eingeschätzt, als dies bei reinen Softwareprodukten der Fall ist („die Software muss frei sein“, sagt man gern – heißt übersetzt: Wir wollen für Software nicht zahlen).

Natürlich werden nicht nur in Deutschland attraktive Systeme hergestellt. Ein Paradebeispiel stellt das iPhone dar. Es ist so begehrt, dass Menschen im Extremfall bereit sind, ihre Körperteile zu verkaufen, um sich ein solches Smartphone leisten zu können. Apples Produkte zeichnen sich dadurch aus, dass sie keine reine Soft- oder Hardware, sondern untrennbar miteinander verwobene, wohldurchdachte Systeme darstellen. Weder Soft- noch Hardware ist da allein von herausragender Bedeutung; doch ihr geschicktes Zusammenspiel erscheint der wachsenden Kundenschar unwiderstehlich.

Doch im Unterschied zu den USA, die neben einigen herausragenden IT-Produkten immer weniger im Bereich des Systembaus anbieten können, haben deutsche Hersteller nicht versucht, Entwicklungs- und Produktionsprozesse auf Biegen und Brechen nach Asien zu verlagern. Die berühmte deutsche Ingenieurskunst wurde nicht in dem Maße dem billigen Massending geopfert, wie es woanders der Fall war. Ausgiebig könnte man darüber philosophieren, warum es so gekommen ist. Vielleicht ist die oftmals unterstellte Unfähigkeit deutscher Hersteller, die höherwertigen Schritte der Wertschöpfungskette nach China zu verlängern, im Endeffekt für das ganze Land ein Glücksfall. Dank dieses Umstands werden hier immer noch Güter „zum Anfassen“ gebaut.

Natürlich sind kurzfristige Erfolge auch mit Softwareprodukten und damit verbundenen Dienstleistungen möglich. Der neuerliche Kauf der 13-Mann-Bude Instagram nach knapp zweijährigem Bestehen durch Facebook für sage und schreibe eine Milliarde Dollar ist eine seltene Ausnahme.

Bei rein mechanischen Produkten stellt sich die Frage nach ihrer strategischen Bedeutung im volkswirtschaftlichen Sinne erst gar nicht.

Das volkswirtschaftliche, strategische Potenzial steckt in einer cleveren Kombination aus beiden Komponenten: Hardware und Software.

Strategisches Potenzial von Hardware-Software-Systemen

Dem Systembau gehört die Zukunft. Solange wir schöne Dinge „zum Anfassen“ (oder zum Fahren, zum Fliegen …) bauen und dieses Know-how nicht fahrlässig aus der Hand geben, werden wir voraussichtlich weiterhin vorne mitspielen dürfen. Länder wie Deutschland oder Japan, die konsequent auf den Systembau setzen, konnten bisher den meisten Attacken der Billigheimer widerstehen.

Man bedenke, dass britische Produkte im 19. Jahrhundert für ihre Qualität weltberühmt waren. Was heute „Made in Germany“ ist, war damals „Made in England“. Schlimmer noch: Deutsche Erzeugnisse galten als wenig zuverlässig, schlecht verarbeitet und generell minderwertig. Dass es heute teils umgekehrt ist, liegt auch – oder vielleicht sogar vor allem – daran, dass der Systembau in Deutschland weiterhin beheimatet blieb, während andere Länder sich mit Finanzdienstleistungen & Co. zufrieden gaben und ihre Systembauindustrie verdorren ließen.

Dank seiner Ausrichtung auf hochwertige Systemherstellung sehe ich gute Chancen, dass Deutschland schlimme Finanzkrisen und Mega-Trends wie die demografischen Herausforderungen oder extreme Klimaveränderungen  gut meistert – solange wir weiter Dinge „zum Anfassen“ bauen.

Ein Ruck muss durch die Unternehmen gehen. Wir ersaufen in Meetings. Wir verbringen unendlich viel Zeit in Meetings. Das hört sich nach Arbeit an – und Meetings sind Arbeit.

Doch die meisten Meetings sind Zeitverschwendung und kosten dazu noch richtig Geld, denn sie werden schlecht vorbereitet und oft als Workshops zur Lösungsfindung missbraucht. Doch typische Meetings sind nicht als Workshops gemeint – Lösungen für komplexe Probleme lassen sich kaum in einem 60-Minuten-Zeitfenster erarbeiten.

Andere Meetings werden als Machtinstrument missbraucht.  In solchen Sitzungen werden Überraschungsangriffe gestartet, rhetorische Gefechte bestritten, persönliche Machtkämpfe ausgetragen. So etwas ist für alle Beteiligten eine furchtbare Energiesenke. Es passiert aber auch mal das Gegenteil, Langeweile macht sich breit und nichts wird entschieden. „Gut, dass wir darüber geredet haben“ lautet das Motto.

Es lässt sich dagegen etwas tun. Sinnlose Meetings müssen nämlich nicht sein. Die Lösung in Stichworten:

1. Typ der Veranstaltung klarstellen:
   a) Workshops haben das Ziel, Lösungen zu erarbeiten oder Know-how aufzubauen.
   b) Brainstorming-Sessions dienen zur Ideenfindung.
   c) Schulungen (Trainings) sind reine Lernveranstaltungen.
   d) Meetings dienen zur Entscheidungsfindung. Um diese Form dreht sich dieser Beitrag. Dabei ist es wichtig, Entscheidungen von Beschlüssen zu unterscheiden: Beschlüsse sind Willenserklärungen, Entscheidungen sind komplette Ziel- und Zeitvorgaben mit Benennung von Verantwortlichen für ihre Umsetzung.
2. Meetings vorbereiten. Neben den üblichen Regeln wie Agenda und Einhaltung der Zeitvorgaben ist die Vorentscheidungsphase besonders wichtig. Nichts wird im Meeting entschieden, wenn der Organisator des Meetings nicht vorher klärt, welche Entscheidung es sein wird.
3. Meeting-Kodex aufstellen. Speziell bei wiederkehrenden Meetings sollte klar sein, dass dialektische Kunstgriffe unerwünscht sind und als solche sofort transparent gemacht werden. Damit Meetings in einer sachlichen Atmosphäre verlaufen, müssen althergebrachte Tricks wie das Laut-und-viel-Reden und Ins-Wort-Fallen untersagt werden. Auch Überraschungsangriffe – etwa Unterlagen, die den Beteiligten nicht vorher bekannt waren – sollten einfach aus dem Meeting ausgeschlossen werden. Manchmal ist es hilfreich, solche Regeln im Meetingraum für alle sichtbar an die Wand zu pinnen.
4. Meetings kurz halten. Die berüchtigten stand-up meetings (Scrum-Methodik) sind deshalb so beliebt, weil dieser simple Trick Meetings einen engen zeitlichen Rahmen aufzwingt.
5. Meetings nicht als Litfaßsäule missbrauchen. Gute und knapp formulierte Berichte genügen in der Regel, und wenn sie im Vorfeld abgestimmt und verschickt werden,  dann kann man sich im Meeting auf Wesentliches beschränken.

Übrigens, es ist vollkommen in Ordnung, wenn Meetings früher enden als geplant. Es ist ebenso okay, Meetings zu beenden, wenn die Zeit abgelaufen ist; in der Regel bringen Verlängerungen nur Terminkonflikte und führen selten zu brauchbaren Ergebnissen (also Entscheidungen).

Nicht jedem wird eine solche Meeting-Strategie gefallen. Vor allem diejenigen, die es gewohnt sind, Meetings als Bühne für dialektische Spielchen oder als zusätzliche Arbeitspausen zum Tagträumen zu missbrauchen, werden sich unwohl fühlen.

Ein Ruck muss durch die Unternehmen gehen. Ein Ruck muss vor allem durch Meetingräume gehen. Dann können alle ihre kostbare Zeit für Wichtigeres verwenden: die eigentliche Arbeit.

li

Matrixorganisationen sind „State of the Art“. Sie liefern bei Restrukturierungen einen weitverbreiteten Ansatz und lassen sich aus der Unternehmenswelt kaum mehr wegdenken. Und sie bringen Ihre Firma um.

Was ist eine Matrixorganisation? Eine Matrixorganisation – kurz „Matrix“ – ist ein Organisationskonzept, bei dem sich verschiedene fachliche Bereiche systematisch die gleichen Ressourcen und Zuständigkeiten teilen.

Man könnte sich beispielsweise vorstellen, dass Produkt-, Technologie- und Managementbereiche eine multidimensionale Matrix bilden.

Das Konzept erscheint sinnvoll und vernünftig, und es bedient sich in seiner ursprünglichen Version einer zweidimensionalen Matrix, die bösen Gerüchten zufolge die maximal akzeptable Management-Abstraktion darstellt. Da jedoch die Komplexität der modernen Geschäftswelt immer weiter voranschreitet, genügen zwei Dimensionen nicht mehr, und der Trend geht zu multidimensionalen Matrixorganisationen.

Abbildung 1 Eine multidimensionale Matrixorganisation

Die Vorteile der Matrix scheinen auf der Hand zu liegen: gemeinsame Nutzung von Ressourcen und bessere Verteilung des Wissens in der Organisation. Doch die scheinbare Einfachheit der Lösung trügt. In den kleinen Matrix-Kästchen befinden sich nämlich keine abstrakten Kreuzchen, sondern Personen aus Fleisch und Blut, die in einem solchen Gebilde zwangsläufig an mehrere Chefs gleichzeitig berichten müssen. Daraus ergibt sich eine Vielzahl von Risiken und Nebenwirkungen. Zwei davon sind als besonders verhängnisvoll einzustufen: unscharfe Zuständigkeiten und Veränderungsresistenz.

1. Unscharfe Zuständigkeiten

Kann man zwei Göttern dienen? Organisatorischer Polytheismus funktioniert nicht. Betroffene Mitarbeiter werden sich immer nach dem Stärkeren richten, denn das ist für ihr berufliches Fortkommen stets die richtige Entscheidung. Die „stärkeren“ Matrix-Herrscher schreiben Jahresziele und Abteilungsregeln vor, die in den gemeinsamen Matrixzellen den „schwächeren“ Mitspielern das Wasser abgraben. Diese organisatorische Achillesferse ist weder theoretisch noch praktisch behebbar, denn es geht um persönliche Vorteile von Funktionsträgern, und diese sind psychologisch den – aus Not in Matrixorganisationen entstandenen – Appellen an das kollektive Bewusstsein am Ende immer überlegen. Sämtliche „Policies“, „Grundwerte“, „Strategien“, „Claims“ etc. kosten dabei nichts als Geld und bringen wenig Besserung. Auch die berüchtigten Tschaka-Tschaka-Reden und motivierende Teambildungsmaßnahmen helfen – wenn überhaupt – nur vorübergehend. Effektive Führung in einer Matrix gestaltet sich sehr schwierig, denn Führung (= Veränderung) und Matrix (= Veränderungsresistenz) verhalten sich zueinander wie natürliche Feinde.

2. Veränderungsresistenz

Matrixorganisationen sind ein Kind der 60er- und 70er-Jahre, als Mitarbeiter noch oft ihr ganzes Leben in derselben Firma arbeiteten und nach der Dauer ihrer Betriebszugehörigkeit befördert wurden. Das typische Unternehmen war eine ineffiziente Bürokratie, in der es vorrangig darum ging, den Status quo zu erhalten und ehrgeizige Einzelgänger im Zweifel in die Schranken zu weisen. In einer Matrixorganisation wird jeder von mindestens vier Augen kontrolliert – und bei Bedarf umgehend ausgebremst. Daher sind Matrixorganisationen sehr gut darin, repetitive Vorgänge risikoarm und langfristig nach dem gleichen Muster zu gestalten.

Matrixorganisationen sind moderne, Technologie-affine Projekte wesensfremd. Jedes Projekt mit dem Ziel, ein neues Produkt zu erstellen, bedeutet nämlich unweigerlich eine risikobehaftete Veränderung. Eine typische, risikoscheue, auf Beständigkeit ausgerichtete Matrixorganisation tut sich mit Projekten daher sehr schwer. SEHR schwer. SEHR, SEHR, SEHR schwer. Sie können es einfach nicht, basta. Warum? Weil sie es eben nicht WOLLEN.

Im Würgegriff der Matrix

Unklare Zuständigkeiten und Veränderungsresistenz korrelieren und verstärken sich mit der Zeit gegenseitig. Während eine Verwaltungsbürokratie diesen Zustand lange unbemerkt durchhalten kann, leidet eine Produktentwicklungsorganisation rasch unter der intrinsischen Unbeweglichkeit der Matrix-Struktur. Von der Chefetage aus gesehen ist die Welt scheinbar in Ordnung, doch in den einzelnen Projekten wächst die Verzweiflung, denn da geschieht Folgendes:

• Das Interesse der Projektmitarbeiter am Projekterfolg erreicht seinen Höhepunkt am Tag des Kick-offs. Tendenz danach: fallend.
• Wichtige (obwohl häufig ungeliebte) Projektaufgaben bleiben unerledigt und niemand kümmert sich darum. Folge: Das Projekt versinkt im Chaos.
• Für die Erreichung der Projektziele ist immer jemand anderes zuständig (je nachdem, wen man fragt). Folge: Es platzt ein Termin nach dem anderen, inklusive Kunden- und Zulieferer-Deadlines.
• Für die geplatzten Termine ist niemand verantwortlich. Niemand hat Schuld, wenn die Produktqualität nicht stimmt. Folge: Aus gerissenen Terminen und teils peinlichen Pannen wird nicht gelernt.
• Projektleiter, die für das Projektergebnis alle Verantwortung, aber über ihre Ressourcen keine Befugnis haben, suchen auf „kurzen Dienstwegen“ quer durch die ganze Organisation fieberhaft nach Verbündeten, die ihnen bei der Ressourcenbeschaffung helfen können. Es werden immer mehr Mitarbeiter ins Projekt gebracht. Diejenigen, die ihrer Aufgabe nicht gewachsen sind, können aber nicht aus dem Projekt entfernt werden und bleiben im Projektbudget. Folge: anhaltende Kostenexplosion.
• Wegen der Trägheit und des Zuständigkeitsvakuums werden „Task Forces“ gebildet, die in Nacht-und-Nebel-Aktionen lange liegen gebliebene Aufgaben nach dem Muster „quick and dirty“ erledigen. Folge: kurzfristige Lösungen, langfristige Probleme.

Pervers erscheint dabei die Erkenntnis, dass es auch mal gut gehen kann. Wenn mit Verspätung und Ach und Krach geliefert wird, ist die Erleichterung groß, und für einige wenige Projektmitarbeiter bringen Chaos-Projekte persönliche Vorteile. Am Ende werden nämlich die größten Helden der turbulentesten Task Forces in die Linie befördert, denn der „volle Einsatz“ muss ja belohnt werden. Die Folge davon ist natürlich, dass der dramatische Einzelfall dadurch zum Standardvorgehen in der Organisation gekürt und so auf Dauer zementiert wird.

Bei einem Nicht-so-happy-End dagegen wird der völlig ausgebrannte Projektleiter einfach für unfähig erklärt und gefeuert. Nun kann das Ganze beim nächsten Mal nach dem gleichen Muster von vorn losgehen.

Matrix muss nicht sein

Das war natürlich alles nie so gewollt. Kein Unternehmenslenker macht so etwas mit Absicht. Oftmals liegt es an seinem Umfeld: Mitarbeiter, die nichts anderes kennen, Berater, die einfach nach Machtverhältnissen beraten, Unkenntnis der Kehrseite einer Matrixorganisation.

Doch es geht auch anders – Matrix muss wirklich, WIRKLICH, nicht immer die beste Lösung sein. Es gibt tatsächlich Organisationen, die aus ihrer leidigen Vergangenheit gelernt haben und ihre gesamte Struktur um Projekte herum aufbauen. Die tragenden Rollen dieses Modells stellen Produkt- und Projektmanager dar.

Die Rolle eines Projektmanagers zeichnet sich dadurch aus, dass sie innerhalb des Projekts die absolute Macht besitzt. Ein Projektmanager trägt die volle (persönliche) Verantwortung für das Projektergebnis, er verfügt aber auch vollständig über seine Ressourcen. Projektmitarbeiter werden dem Projektmanager vollständig unterstellt. So kann er selbst entscheiden, wer die nötige Qualifikation benötigt, um bestimmte Projektaufgaben mit möglichst wenig Personal (also effizient) möglichst zielgerichtet (also effektiv) umzusetzen. Es gibt keine unklaren Verantwortlichkeiten mehr, kein Zögern, kein fahrlässiges Liegenlassen wichtiger Projektaufgaben und – hoffentlich – auch keine Task Force im späteren Projektverlauf.

Natürlich stellt eine vollständig Matrix-freie Projektorganisation eine unrealistische Wunschvorstellung dar. Denn schließlich wird es weiterhin Competence Center, HR-Abteilungen, Einkauf etc. geben, die allen Bereichen zur Verfügung stehen. Eine gute Lösung ist es hierbei, die Organisation nicht als Matrix zu begreifen, sondern als einen Graphen. Die Beziehung von Mitarbeiter zum Einkauf zum Beispiel muss nicht über Matrix-Kanten gehen, sie kann direkt erfolgen.

So könnten die Knoten dieses Graphen aussehen:

• Projektmanagement
• Produktmanagement
• Einkauf
• Personal
• Fachliche Expertenpools (bitte nicht etwa „Humanressourcen-Pools“ – das hört sich entwürdigend an)

Klare Zuständigkeiten, sauber definierte Rollen, unverfälschte Zielsetzungen prägen eine solche Organisation. Da macht es Spaß, etwas zu bewegen, denn es LÄSST sich dann viel bewegen. Projekte können auf Expertenpools zurückgreifen, wenn sie Unterstützung benötigen, und können überflüssig gewordene Experten wieder in entsprechende Expertenpools zurückgeben. Die gefürchtete „Linie“ hat im Projekt wenig zu suchen. Es handelt sich um eine schlagkräftige Projektorganisation, in der Zuständigkeiten eindeutig geklärt sind und die Projektmanager volle Verantwortung für den Projekterfolg tragen, zugleich aber auch die uneingeschränkte Weisungsbefugnis über ihre Projektteams erhalten.

Regelbasierte Unternehmensorganisation

Eine so stark auf Projekte ausgerichtete Organisation mag ängstigen. Was machen die Mitarbeiter, die gerade in keinem Projekt sind? Haben die Projektmanager nicht zu viel Macht? Wie kann eine solche Organisation eine konsistente Strategie umsetzen?

Ich behaupte, ohne es aus Gründen der Platzknappheit weiter zu vertiefen, dass dies besser funktioniert als in einer starken Matrixorganisation. Denn die so oft beschworene „Agilität“ kann am besten in einem Graphen und am schlechtesten in einer Matrix abgebildet werden. Da jedoch eine Graphen-Organisation offenbar sehr viele Freiheitsgrade aufweist, muss es eindeutige Handlungsvorgaben geben, die in jedem Kontext befolgt werden können und müssen.

Es sollte ein Regelsatz erarbeitet werden, der dazu genutzt wird, die Verantwortung von der Unternehmensspitze bis ins kleine Teilprojekt erfolgreich und ohne Mikromanagement sehr effektiv zu delegieren. Ich schrecke vor dem Wort „Prozess“ inzwischen zurück, da es den falschen Eindruck erweckt, es handele sich um einen bürokratischen Ansatz. Der Begriff „Prozess“ erinnert außerdem an traditionelle Fließband-Betriebe, die traditionell starre Matrixorganisationen sein müssen. Eine deutlich bessere Überschrift wäre „Managementsystem“. Dieses Managementsystem muss ergebnisorientierte Handlungsvorschriften und Qualitätssicherungsmaßnahmen definieren, die jeder im Unternehmen (und speziell im Projekt) befolgt. Es ist ein Regelwerk, das keine Matrix benötigt oder bedingt (ihr aber nicht unbedingt widerspricht).

Solch ein regelbasiertes Unternehmen kann sich flexibel und schnell auf neue Projekte konzentrieren. Auch wenn in einer regelbasierten Organisation Projekte naturgemäß scheitern können, so sind sie wenigstens nicht von vornherein dazu verdammt, zu einer Task Force zu degenerieren.

Softwareprojekte auf Festpreisbasis misslingen nicht wegen der Technik, sondern wegen der Projektorganisation. Sie können nichts dafür. Sie scheitern an ihrem eigenen Wesen.

Gerne wird argumentiert, dass misslungene Projekte nicht scheitern, wenn alle Beteiligten einen Standard XYZ beachten oder ein ordentliches Projektmanagement-Tooling konsequent einsetzen.

Doch das ist größtenteils Quatsch.

Natürlich sind richtige Tools im Projekt enorm hilfreich. Standards erweisen sich als sinnvoll. Alles zusammen ist schön und gut, und es hilft auch – vorausgesetzt, das Projekt hat die richtige DNA. Doch das ist bei Festpreisprojekten selten der Fall. Der typische Ansatz ist nämlich der folgende:

1. Der Kunde stellt fest, dass er neue Software braucht, die er auf dem Markt nicht bekommt und somit entwickeln lassen muss.
2. Da im eigenen Hause die notwendige IT-Kompetenz fehlt, wird ein externer Lieferant gefunden.
3. Es wird mit dem Lieferanten ein Festpreis ausgemacht.
4. Das Projekt läuft gut an.
5. Das Projekt scheitert vollends in einer späteren Phase.

Woran liegt das? Die Projektveranlagung besteht aus widersprüchlichen Genen. Etwas überspitzt formuliert gestaltet sich das so:

• Der Kunde denkt, dass er einen Dummen gefunden habe, der billiger als andere das Richtige liefert.
• Der Lieferant denkt, dass er eine ahnungslose Melkkuh gefunden habe.

Natürlich predigen alle Fairness und Zufriedenheit unter den Beteiligten, aber das ist oft lediglich Teil des üblichen Projektrituals. Projekt-Outsourcing (noch schöner: -Offshoring) ist nämlich theoretisch eine tolle Sache, doch bei Großprojekten ist Ehrlichkeit Mangelware, und somit entfällt die elementare Grundlage für ein erfolgreich extern umgesetztes Festpreisprojekt.

Es geht schief, was schiefgehen muss

Die erste Projektphase gestaltet sich ja noch optimal, der Lieferant tut praktisch alles, worum er gebeten wird. Man will ja die Abhängigkeit weitgehend festigen, und der Kunde ist oft naiv genug zu glauben, dass das so weitergehen werde.

Doch später gewöhnt sich der Lieferant an seine fette Wurst und beginnt, sein Verhalten zu verändern. Auch der Kunde merkt allmählich, was er WIRKLICH braucht, und stellt weitere Forderungen. Gespräche laufen dann nach dem folgenden Prinzip:

• Kunde: „Wir brauchen Feature XYZ.“ (Übersetzung: „Warum hat der Lieferant das nicht selbst gesehen?“)
• Lieferant: „Das ist ein sinnloses Feature.“ (Übersetzung: „Das steht nicht im Lastenheft.“)
• Kunde: „Wir benötigen das aber.“ (Übersetzung: „Das ist doch offensichtlich!“)
• Lieferant: „Das ist technisch nicht machbar.“ (Übersetzung: „Das wollen wir nicht machen, es sei denn, es wird uns dafür ein Vermögen gezahlt.“)

Festpreisprojekte haben dieses Problem ab einer gewissen Größe, und es gibt wenig Hoffnung, dass sich das ändert. Weder agile Ansätze (die der Festpreisnatur eines Projekts widersprechen) noch strenge Standards (die die Kosten in die Höhe treiben) konnten bisher entschieden helfen.

Kunden folgen bei Festpreisprojekten der folgenden Argumentation:

„Wir liefern doch auch Produkte XYZ (Betondecken, Einbauküchen, Fenster etc.) nach Leistungsbeschreibung X, und es klappt ja hervorragend. Bei Software muss es auch so gehen. Das kann doch nicht soooo schwer sein!“

Es ist aber so schwer. Software ist vielleicht das komplizierteste, unüberschaubarste, schwierigste Produkt, das man auf Bestellung kaufen kann. Software ist dermaßen absurd komplex, dass dies einem Außenstehenden nicht näherzubringen ist.

Festpreisprojekte können funktionieren (ernsthaft)

Es geht auch anders. Dabei meine ich nicht den „agilen Festpreis“ oder ähnliche Versuche, die Natur auszutricksen. Wichtig ist nicht die Welche-auch-immer-Methodik, sondern die Qualität der Lieferanten-Kunden-Beziehung. Speziell in der Automobilindustrie funktionieren Festpreisprojekte nach einem bestimmten Muster. Da werden Zulieferer, die nicht selten extrem komplexe Systeme mit Software, Elektronik und Mechanik entwickeln, an die sehr kurze Leine genommen. Für die Laufzeit ihres Projektes werden die beteiligten Lieferantenmitarbeiter praktisch zur internen Abteilung des Automobilherstellers. Nichts passiert ohne Kundenzustimmung, weder Designanpassungen noch Änderungen im Team, und schon gar nicht Anpassungen am Projekt-Scope. Zugleich werden Zulieferer mit einer irrsinnigen Menge an Anforderungen konfrontiert, denn neben dem Lastenheft müssen sie abertausende Seiten Konzern- und Industriestandards befolgen.

Unter solchen Umständen geht es oft gut mit dem Festpreis-Entwicklungsprojekt. Es ist natürlich zu beachten, dass der Zulieferer nur teilweise seine Entwicklungskosten direkt erstattet bekommt. Er wird nämlich am Umsatz beteiligt (seine Teile werden in Fahrzeugen explizit mitverkauft), es besteht also ein Eigeninteresse an der Qualität der zu liefernden Komponenten.

Was aber tun, wenn man seine Lieferanten nicht in der Tasche hat?

Was sich große Automobilhersteller leisten können, das geht bei vielen anderen nicht. Erstens fehlt da die Eigenkompetenz im Softwarebau, und zweitens sind insbesondere im Mittelstand die Lieferanten schnell größer als ihre Kunden, oder zumindest können sie die für Festpreisprojekte charakteristische Abhängigkeit in (Nach-)Verhandlungen zu ihren Gunsten besser nutzen.

Wie beim Hausbau heißt es: Wenn man von der Materie keine Ahnung hat, dann sollte man jemanden anheuern, der das kann, und das Projekt NICHT per Festpreis, sondern nach Aufwand durchführen. Das ist speziell bei unternehmenskritischen Kernanwendungen sinnvoll. Dabei darf es sich bei dem Experten nicht um eine einzelne externe Organisation handeln, die alle erforderlichen Projektmanager, Entwickler, Tester etc. zur Verfügung stellt. Damit würde sich der Kunde in eine folgenschwere Abhängigkeit begeben. Es muss stattdessen eine unabhängige Person sein, die noch am besten am Projekterfolg direkt oder indirekt beteiligt ist. Dann gilt es, weitere Experten einzeln „nach dem Nasenprinzip“ einzukaufen, ins Team zu integrieren und das Projekt nach allen Regeln der Kunst durchzumanagen.

Oft schrecken Kunden vor diesem Ansatz zurück, denn er bedeutet, dass man einer Einzelperson vertrauen muss, und außerdem fürchten sie, dass das Projekt „ein Fass ohne Boden“ werden könnte. Doch die Praxis zeigt, dass man sich in die Tasche lügt, wenn man bei einem externen Dienstleister eine andere Erwartungshaltung entwickelt.

Illusionen darf man sich keine machen: Ein Softwareprojekt stellt immer eine enorme Anstrengung dar. Wer frei nach dem Spruch „Das kann doch nicht so schwer sein“ handelt, der lebt auf einem fernen Planeten. Entwicklungsprojekte sind immer mit einem hohen Risiko behaftet – auch deshalb machen sie ja so viel Spaß! Vorausgesetzt, am Ende wird das Projekt von Erfolg gekrönt. Und es wird erfolgreich, wenn es dazu von Geburt an richtig veranlagt ist.

Da im eigenen Hause die notwendige IT-Kompetenz fehlt, wird ein externer Lieferant gefunden.

Suchen Sie eine hundertprozentige Lösung? Dann wird der Weg Ihr Ziel bleiben.

Wann lernen wir endlich, dass Hundertprozent-Lösungen reine Zeitverschwendung sind? Zumindest in aller Regel.

Die Erwartungshaltung sollte sich an der Realität und nicht am theoretisch Möglichen ausrichten. Wir wissen doch alle, dass es Probleme gibt, die sich theoretisch lächerlich einfach darstellen, praktisch aber nicht lösbar sind, wenn man verhältnismäßige Kosten und/oder verfügbare Zeit nicht aus der Gleichung weglässt.

Da gibt es ein paar schöne Beispiele:

• Schach. Theoretisch kann ein Computer durch schlichtes Durchprobieren aller Varianten (des kompletten Spielbaumes) immer gewinnen, zwei Computer werden immer unentschieden spielen. In der Praxis würde der schnellste Computer der Welt nie alle Varianten durchrechnen können.
• Korrektheit einer Software. Theoretisch testet man einfach alle Systemzustände, Eingabe/Ausgabe-Kombinationen und Variablenwerte durch. Dann hat man die Sicherheit, dass die Software den Anforderungen entspricht. In der Praxis würde ein kompletter Test mittelgroßer Software Jahre dauern.
• Das Wasserfallmodell in der Softwareentwicklung. Theoretisch ist nichts schöner als das Extrem-Wasserfallmodell. Zuerst hat man alle Anforderungen vollständig aufgeschrieben. Dann hat man auf dieser hundertprozentig korrekten Grundlage ein vollständiges Design entworfen. Dann hat man alles getestet. Dann ausgeliefert. Perfekt! In der Praxis ist das Extrem-Wasserfallmodell ein sicheres Rezept für ein gescheitertes Softwareprojekt.

Sogar bei scheinbar trivialen Aktivitäten ist eine hundertprozentige Korrektheit wenig Erfolg versprechend. Nehmen wir zum Beispiel die E-Mail-Flut. Ein Versuch, eingehende E-Mails zu klassifizieren und in speziell dafür vorgesehene, sinnvolle Ordner zu verschieben, ist theoretisch eine tolle Idee. Man weiß immer, wo man etwas suchen soll: Man öffnet einfach den Ordner „Anforderungen für Projekt X“ und hat alle betreffenden E-Mails parat. Toll! Und sinnlos. Weder manuelles Verschieben noch geschickt angelegte Regeln werden garantieren, dass alle E-Mails in die richtigen Ordner einsortiert werden. Schlimmer noch: Wenn eine E-Mail zwei Themen betrifft, was dann?

Nein, die realistische (und vermutlich beste) Lösung ist eine mächtige Suchfunktion für die Mailbox, die ähnlich wie Google Mail sämtliche E-Mails nach den entsprechenden Begriffen absucht und das Ergebnis in Sekundenbruchteilen liefert.

„The perfect is the enemy of the good“, so ein englisches Sprichwort. Da ist wirklich was dran.

Der Nachteil dieses Ansatzes liegt auf der Hand. In einer Achtzigprozent-Lösung findet sich immer ein Fehler.  In einem Umfeld, in dem man sich gegenseitig zu beweisen versucht, dass der Andere Unrecht hat, sind Hundertprozent-Lösungen angesagt. Wer es toll findet, dass der Weg das Ziel sein soll, der wird sich hier heimisch fühlen. In einem solchen Umfeld wird der Weg nämlich immer das Ziel bleiben, im denkbar schlimmsten Sinne dieses beliebten Spruchs.

Dass sich das auf kurz oder lang katastrophal auswirkt, dürfte nun klar sein. Hundertprozent-Lösungen sind eine schlimme Plage, die gründlich ausgerottet gehört. Es sei denn, Geld und Zeit spielen keine Rolle. Wer solche Projekte kennt, der soll mir bitte verraten, wo man sie findet. Dort werde ich auch sehr gern Hundertprozent-Lösungen predigen.

Unterrichtseinheiten:

• Class 01 Modeling Behavior with UML: Interactions and Statecharts
• Class 02 Agile Systems Engineering
• Class 03 Introduction to Real-Time Operating Systems
• Class 04 Hands-on-Workshop Safety Critical Linux
• Class 05 Cryptography and embedded Security – The Workshop
• Class 06 Embedded Software Development on Virtual Platforms
• Class 07 ARM Cortex-A for industrial real time communication
• Class 08 Software Design for Multicore Systems – 2012 Edition2
• Class 09 Hands-on-Introduction to RT-Linux
• Class 10 Application programming with the new Cortex-M4
• Class 11 Fault Tolerant Design of Embedded Systems
• Class 12 How to use the iPad as an embedded interface
• Class 13 MCU System Design with RTOS and Middleware Components

Vortragsbereiche:

• Session 01 Smart Grid / Smart Metering
• Session 02 Managing Embedded System Development and Life Cycle
• Session 03 Achieve High Embedded Software Quality
• Session 04 ARTEMIS – Visions, Projects and Results I/II
• Session 05 Cryptography and embedded Security – The Session I/II
• Session 06 The Multicore Session I/II
• Session 07 Model Based Development of Embedded Systems I/II
• Session 08 Functional Safety of Embedded Systems I/II
• Session 09 Software Development in High Level Languages I/II
• Session 10 Software Development and Debug Methods I/II
• Session 11 RTOS I/II
• Session 12 Communication I/II
• Session 13 Open Source Projects
• Session 14 Embedded Linux and Android – Development & Trends I/II
• Session 15 Embedded System Architectures and SoC I/II
• Session 16 Internet Technology and M2M I/II
• Session 17 Wired and Wireless Network Technologies I/II
• Session 18 Development tools
• Session 19 Test and Verification
• Session 20 Embedded System Applications I/II
• Session 21 Low Energy Embedded Systems I/II
• Session 22 OSADL – FLOSS Safety I/II

Die Konferenzkeynote “Low power Embedded Design – What Next?” wird von Mike Muller (CTO, ARM) gehalten.

Standards können in der Softwareentwicklung nützlich sein. Eine „sauber durchdefinierte“ Ansammlung von Best Practices (neuerdings auch als „Good Practices“ bekannt) ist im Grunde eine feine Sache. Solche Standards bilden aber auch ein mächtiges Werkzeug, das in den Händen eines Unerfahrenen katastrophale Wirkung entfalten kann. Wenn solche Leute Hand anlegen, dann platzt den Entwicklern schnell der Kragen! Dann wird ab sofort alles agil. Oder nicht?

Wo immer man hinschaut, Automotive SPICE, CMMI und Co. scheinen fast einhellig gehasst zu werden. Experten hingegen, die mit diesen Standards Geld verdienen, pflegen diesen Umstand als bloße Widerspenstigkeit oder Mangel an Erfahrung abzutun.

Was ist nun das Problem? Ich wiederhole mich, aber es muss sein: Wir Berater sind SELBST SCHULD. Denn viele von uns haben zu lange die Realität der Standardeinführung in den unendlichen Weiten der Software-Welt ignoriert.

So in etwa sieht der hypothetische Ablauf einer Prozessverbesserung aus:

1. Ein Verbesserungsbedarf wird festgestellt, z. B. möchte das Team professioneller werden, um seine Marktposition auszubauen.
2. Ein renommierter Prozessberater, als Experte z. B. auf dem Gebiet Automotive SPICE verdientermaßen bekannt, wird angeheuert, um dem Team zu helfen.
3. Es wird gemeinsam eine neue, standardkonforme Prozesslandschaft entwickelt, in der sich jeder in einer sinnvollen Rolle wiederfindet und wohldefinierte Qualitätsziele effizient erreicht werden können.
4. Der Berater beendet seinen Einsatz und hinterlässt einen zufriedenen Kunden.
5. Weiter siehe Schritt 1.

Die praktische Erfahrung mit Prozessverbesserungen erwies sich oft genug als eine andere. So der häufige Ablauf:

1. Die Endkunden (z. B. Automobilhersteller) einigen sich auf einen neuen Satz von Regeln („Standards“) und zwingen diesen ihren Zulieferern auf.
2. Verzweifelte Projektorganisationen heuern einen Berater an.
3. Der Berater verkauft dem Kunden ein Beratungsprojekt und schickt, statt selbst hinzugehen, junge „High Potentials“ ins Projekt. Dem Kunden versichert er, dass er die Arbeit seiner unerfahrenen Jünglinge selbstverständlich überwache, damit alles so gut werde, „als hätte er das selbst gemacht“.
4. Die für das Projekt abgestellten Berater haben den neuen Standard auswendig gelernt und legen ihn buchstabengetreu aus.
5. Weitere Akteure, z. B. QA-Mitarbeiter, andere externe Mitarbeiter oder sonstige Profilierungswillige, lernen den Standard auch auswendig und legen ihn ebenfalls orthodox aus.
6. Da Standards meist analytisch (und nicht systemisch) aufgebaut sind, führt das so geführte Prozessverbesserungsprojekt im gesamten Entwicklungsbereich zu einem exponentiellen Kostenanstieg, während das Team, statt sich um die Bedürfnisse des Kunden zu kümmern, erbitterte Grundsatzdiskussionen über eine „Practice XY.47.11“ führt.
7. Das wird dem Sponsor des Prozessverbesserungsprojekts zu viel. Die Junior-Berater werden heimgeschickt.
8. Nun werden entweder (a) alle oder zumindest viele der vorgenommenen Anpassungen rückgängig gemacht und die Organisation „hyperagil“; oder (b) Möchtegern-Experten übernehmen die Führung und lähmen die gesamte Organisation, indem sie den Standard als Totschlagargument im Kampf der Egos missbrauchen.

Das STINKT!!! Verwundert es vor diesem Hintergrund, dass „alle“ heutzutage „agil“ sein wollen?

Wie konnte es dazu kommen?

Dafür gibt es Gründe. Keine guten Gründe, davon aber recht viele.

Zum Beispiel:

Das Geschäftsmodell der Beratungshäuser. Wie (hoffentlich) jeder weiß, ist die auf Neudeutsch gern als „Leverage“ bezeichnete Hebelwirkung das A und O eines jeden Geschäftsmanns. Chefs von Beratungsunternehmen sind Geschäftsleute, und Leverage bildet ihre Existenzberechtigung. Diese Hebelwirkung entfaltet sich im Beratungsgeschäft über die Anzahl der eingesetzten, festangestellten Berater. Da diese zwecks Maximierung der Gewinnspanne günstig sein müssen, sind sie oftmals nicht so hoch qualifiziert, wie ihre Chefs dies vorgeben. Sie sind vielleicht erfahren im Consulting-Business, aber oft weniger erfahren in der Materie, in der sie beraten. Fachliche Erfahrung ist Mangelware.

Nochmals und immer wieder:  Mangel an erfahrenen Beratern. Es ist ein extrem gefährlicher Irrglaube eines Anfängers, dass das Auswendiglernen aller Details eines Standards genügen würde, um wirksam beraten zu können. Das reicht eben vorn und hinten nicht aus. Standards sind toll, wenn sie ein Experte als Checkliste nutzt, aber sie ersetzen die eigene Erfahrung in keiner Weise. Wenn man nicht jahrelang (noch besser: jahrzehntelang) selbst marktfähige Systeme entwickelt hat, wie soll man dann wirklich in der Lage sein, als Berater Wichtiges von Unwichtigem zu trennen? Es mag sehr seltene Talente geben, die dies von Natur aus vermögen, aber diese Sonderfälle können wir in unserer Betrachtung als statistisch irrelevant vernachlässigen. Und so – anstatt eigene Erfahrungen, gestützt durch Standards als Spickzettel, praxisgerecht umzusetzen – wird vielmehr das auswendig Gelernte wörtlich postuliert und dogmatisch umgesetzt. „Der Standard sieht das so vor.“ Wenn dieses Killerargument häufig ins Spiel kommt, sollte jeder Kunde hellhörig werden, denn es gibt in diesem Fall Grund zur Annahme, dass das Ergebnis der Beratung der betrieblichen Realität nicht gerecht wird.

Anfälligkeit für Modebegriffe. Was verkauft ein Berater? Sinnige, aber schwer greifbare Eigenschaften wie „Erfahrung“, „Expertise“ und „Know-how“ vermarkten sich schlecht. Es muss schon ein magischer Begriff herhalten, wie „CMMI“, „Scrum“ oder „Reengineering“. Die PR-Industrie dient jedem Teufel, so auch diesem. Wer nun kritiklos auf Modebegriffe à la „Wasserfall“, „V-Model“, „Design Thinking“, „Agility“, „ITIL“, „Cloud Computing“ etc. hereinfällt, der hat sein Scheitern verdient. Diese Begriffe sind teils hohl, teils stehen sie für einen überaus komplexen Sachverhalt, und wenn sie im Gespräch genutzt werden, dann denkt sich oft jeder etwas Anderes dabei. Das kann nur zu desaströsen Missverständnissen führen.

Unerfahrenheit der Kunden in der Beraterauswahl. Den richtigen Berater muss man finden können. „Richtig“ meint eine passende Mischung aus Erfahrung und persönlicher „Chemie“, die einfach stimmen muss. Wer sich von coolen Logos, glänzenden Visitenkarten und Marken blenden lässt, der ist wahrscheinlich schnell geneigt, ein mäßiges Preis-Leistungs-Verhältnis zu akzeptieren. Wenn man selbst nicht über jahrelange Projekterfahrung in seinem Fach verfügt, dann sollte man vielleicht erst einmal einen Berater für die Beratersuche anheuern. Vielleicht wird das im Endeffekt der wichtigste Berater im Projekt gewesen sein. Wem diese „Meta-Beratung“ zu extrem erscheint, dem helfen vielleicht eigene, erfahrene Mitarbeiter bei der Suche nach der richtigen Expertise.

Angst vor der Abhängigkeit von Lieferanten. Ein Großkunde, zum Beispiel ein Automobilhersteller, hat notorisch Angst, von seinen Lieferanten abhängig zu werden. Diese Sorge ist historisch gesehen nicht unbegründet. Bevor der umstrittene VW-Manager Ignazio Lopez die Zuliefererlandschaft umpflügte, litt die europäische Automobilindustrie unter explodierenden Kosten und massiven Qualitätsproblemen. Doch das Gegenteil ist auch nicht unbedingt vorteilhaft: Zulieferer mit Hunderten von Standards zu knechten, bis sie kaum atmen können, zerstört das Vertrauen und öffnet die Hintertür für die unerwünschte Beraterinvasion, die zwangsläufig die aus dem Berater-Geschäftsmodell resultierenden Probleme akut werden lässt.

Die Folgen dieser Umstände sind so dramatisch, dass wir wirklich darüber nachdenken sollten, ob wir mit den Standards richtig umgehen. Standards infrage zu stellen darf kein Tabu mehr sein. Standards können Projekte umbringen. Die Mehrkosten einer Standardeinführung (und nachfolgender Pflege) werden von Endkunden nicht übernommen. Diese leisten sich eine völlige Ignoranz der Tatsache, dass immer mehr Standards immer mehr Kosten verursachen. Zugleich wird gemunkelt, dass Endkunden selbst den Anforderungen ihrer eigenen Standards nicht genügen. Da könnte was dran sein.

Alles Quatsch?

Die Standards selbst seien gut, nur würden sie häufig falsch verstanden und umgesetzt, lautet der typische Einwand des prozesstreuen Beraterlagers.

Es ist schier überwältigend, wie viel Schindluder mit einer Rückübertragung eines analytischen Prozessmodells in die Synthese einer Prozessdefinition getrieben werden kann. Da werden beispielsweise Referenzprozessmodelle wie Automotive SPICE komplett eins zu eins in der Praxis umgesetzt. Dabei werden alle ENG-Prozesse (zehn Stück) zuzüglich der SUP- und sonstiger MAN-etc.-Prozesse als separate Entitäten ins Leben gerufen. So erhält die betroffene Organisation auf einmal eine hohe, zweistellige Zahl von Prozessen und Prozessverantwortlichen, die sich mit größtenteils redundanten Themen beschäftigen und so zu Reibungen und Ineffizienzen beitragen. Alles unheimlich standardkonform – und kaum zielführend.

Analytische Prozessmodelle sind von Natur aus redundant, und die Erfahrung über die einzelnen Prozessbereiche hinweg muss in hohem Maße gegeben sein. Nur so kann ein Berater helfen, diese Redundanz in den Griff zu bekommen und konsistente, redundanzfreie Projektmanagementsysteme aufzubauen.

Nicht nur Automotive SPICE, sondern auch ITIL, CMMI, ISO 9001, Functional Safety 26262 etc. sind in ähnlicher Weise problematisch.

Liebe Freunde: Standards können Eure Organisation UMBRINGEN.

Wir sind nun agil, alles wird gut.

Was nun? Alle Prozesse sind schlecht? Nichts wie weg damit?

Vorsicht, Falle! Die Unzufriedenheit mit Prozessstandards weckte bereits unverhoffte Begehrlichkeiten. Bereits vor über zehn Jahren haben clevere amerikanische Berater den Braten gerochen und eine Abwendung von den „bürokratischen Prozessen“ proklamiert. Da half es nicht zu betonen, dass Standards gut seien und lediglich falsch umgesetzt würden. Die Glaubwürdigkeit der traditionellen Prozessberater war leider bereits selbstverschuldet ruiniert. Auf einmal mussten daher alle „agil“ werden.

Doch was bedeutet „agil“? Das Gegenteil des englischen Begriffs „agile“ ist „clumsy“ (dt. „plump“) oder „awkward“ (dt. „scheußlich“). Dies hört sich eher nach dem Versuch, abweichende Ideen abzuwerten, als nach einem konstruktiven Lösungsvorschlag an. Populäre Agilitätsansätze bestärken diesen Eindruck. Nehmen wir z. B. Scrum. Für viele heißt „agil“ heute Scrum. „Scrum“ bedeutet zu Deutsch „Gedränge“. Ich kann mir nicht vorstellen, dass dies eine sinnvolle Zielvorstellung für einen erfolgreichen Manager verkörpern kann.

Die Scrum-Kritik lässt sich leicht weiter vertiefen. Im Scrum wurde nämlich die Rolle des Projektmanagers abgeschafft. Doch gerade diese Funktion war schon immer für erfolgreiche Projektarbeit wichtig. Sie gerät allerdings in Matrixorganisationen unglücklicherweise oft unter die Räder, weil sie nun einmal produktorientiert und nicht linientreu ist. Diese unselige Tendenz darf sich keinesfalls fortsetzen. Aus meiner Sicht muss die Rolle des Projektmanagers unbedingt gekräftigt werden. Dafür gibt es zu viele gute Gründe, um sie hier alle aufzulisten. Nun ist also in Scrum der Projektmanager weg; und was machen unsere agilen Freunde? Sie führen die Rolle des „Scrum Masters“ ein, eine typische Beraterrolle, die kaum intern besetzt werden kann. Scrum wurde offensichtlich zu dem Zweck entwickelt, als gut geölte Vertriebsmaschine für die Beschaffung von Berateraufträgen zu fungieren. Toll!

Die praktische Umsetzung der Agilität ist daher häufig selbst „clumsy“ und „awkward“. Denn auch im agilen Projekt muss ein Berater mindestens genauso viel fachliche Erfahrung mitbringen wie in einem sinnvollen Prozessverbesserungsprojekt. Ist das nicht der Fall, dann werden unter dem Vorwand der „Agilität“ Chaos, Aktionismus, schlechte Organisation und willkürlich bewegliche Ziele verkauft.

Das geht so nicht, meine Lieben.

Extreme Ansichten können erfrischend wirken, auf Dauer lenken sie nur vom Ziel ab.

Das können wir – die Softwareexperten – mit Sicherheit besser.

Erstens brauchen wir „schlanke“ Projektorganisationen und nicht bloße „Prozesskonformität“ oder willkürlich simplifizierte „Agilität“.

Zweitens geht es darum, als Projektmanager seine Erfahrung weiterzugeben. Es lässt sich nicht überzeugend leugnen, dass eigene Projekterfahrung nicht durch Lernfleiß zu ersetzen ist.

Drittens, ob man nun unter der agilen oder sonstiger Überschrift arbeitet, ändert nichts an der eigentlichen Aufgabe, ein ordentliches Projektmanagementsystem aufzusetzen.

Viertens sind die Entwicklungsabläufe mundgerecht zu gestalten, und das ist nur möglich, wenn man realistisch berät und die Projektorganisation fallspezifisch aufbaut. Projektmanagementsysteme von der Stange sind nämlich ähnlich unsinnig wie eine Zahnfüllung aus dem Versandkatalog.

Fünftens: Nein, Prozesse stinken nicht. Agilität stinkt auch nicht. Realitätsfremde Umsetzung, Mangel an Offenheit und blinde Trendgläubigkeit dagegen schon.

Und nu?

Alles Unsinn? Nein, aber einfach auf Teufel komm raus „agil“ zu sein stellt auch keine Lösung dar. Denkverbote in irgendeiner Art (Aufteilung in „gute“ und „böse“ Ideen) ebenso wenig. Eine sklavische, buchstabengetreue Umsetzung von Buch X oder Standard Y ist keine Lösung. Nichts zu tun aber auch nicht.

Und worin liegt denn nun die Lösung? Die Lösungsfindung beginnt bei der Erkenntnis, dass ein Entwicklungsprozess seinem Umfeld gerecht werden muss. Dieses Projektumfeld wird bestimmt von Schlüsselfaktoren wie verfügbaren Ressourcen, der Phase im Produkt-Lebenszyklus und damit verbundenen Marktanforderungen. Auf der anderen Seite ist es wichtig, den Prozess möglichst schlank zu halten, damit er nicht zu viel „Fett“ ansetzt. Ein guter Entwicklungsprozess muss gewissermaßen die richtige „DNA“ aufweisen, damit die daraus resultierende Kreatur – also das Projekt – überlebensfähig ist.

Weitere Details folgen demnächst auf diesen Seiten.