Projekte sind mehr denn je durch eine zunehmende Heterogenität gekennzeichnet. Einerseits in Bezug auf die Zusammensetzung des Teams, das fast nie ausschließlich aus Mitarbeitern eines einzigen Unternehmens besteht, sondern immer aus einem Geflecht aus mehreren Dienstleistern und freiberuflichen Mitarbeitern. Andererseits – und teilweise aus dem vorigen resultierend – in Bezug auf die räumliche Verteilung des Teams, das fast nie zusammen in einem einzigen Projektraum sitzt. Vieles, was unter optimalen räumlichen Bedingungen (also alle in einem Raum) nur für lästige, aber vernachlässigbare, Reibungsverluste sorgt, hat bei verteilten Teams das Potential sich zur Katastrophe auszuwachsen. Defizite in der Führung, der Kommunikation und der Interaktion fallen erst viel später auf. So geschehen beispielsweise beim Absturz des Mars Climate Orbiters, bei dessen Konstruktion das Team der NASA mit Einheiten im international gebräuchlichen SI-System rechnete, das Team des Herstellers der Steuerungseinheit aber im imperialen System (vgl. „Verwalten Sie noch oder führen Sie schon?“).
Die Führung von verteilten Teams ist also nicht die Ausnahme, sondern bereits die Regel; jedenfalls faktisch. Eine ganz andere Frage ist allerdings, ob diesem Umstand auch gebührend Rechnung getragen wird oder ob einfach die bewährten Konzepte irgendwie der verteilten Situation übergestülpt werden. Ich denke nicht, dass im verteilten Fall prinzipiell anders geführt werden muss, wohl aber dass Defizite in der Führung stärker auffallen. Auch der Zweck von Kommunikation und Interaktion des Teams ist kein anderer, sondern nur die Mittel zur Zusammenarbeit und Kommunikation. Insofern ist das verteilte Team nur eine Lupe, unter der Ungenauigkeiten in der Führung und Kommunikation vielfach vergrößert zu Tage treten.
Die räumliche Verteilung macht es notwendig sich explizit mit Fragen der Kommunikation und Interaktion auseinanderzusetzen. (Was, nebenbei bemerkt, sich immer lohnt, aber in diesem Fall wirklich essentiell ist.) Während im klassischen Fall, dass alle in einem Projektraum sitzen, sich vieles implizit und nebenbei ergibt, müssen im verteilten Fall explizit geeignete Mechanismen gefunden werden. Als Projektmanager muss man sich also mit Themen auseinandersetzen, die bisher scheinbar selbstverständlich waren, die man bisher immer als gegeben oder jedenfalls als automatische Folge der räumlichen Nähe angenommen hatte. Dass es aber auch im Projektraum schon Defizite in der Kommunikation gab, ist nur nicht so stark aufgefallen und konnte deshalb einigermaßen gefahrlos ignoriert werden.
Statt sich aber mit den Bedürfnissen des Teams und der Stakeholder wirklich auseinanderzusetzen und ausgehend davon entsprechende Werkzeuge und Prozesse aufzusetzen, wird versucht, das verteilte Szenario irgendwie auf das bekannte und scheinbar bewährte Modell Projektraum zurückzuführen. Plötzlich gibt es virtuelle Projekträume oder es werden alle mühsam und wenigstens für eine gewisse Kernzeit an einen einzigem Ort zusammen gebracht. Ich will nicht sagen, dass das alles per se schlechte Ideen wären, aber sie sollten den speziellen Bedürfnissen des verteilten Teams entspringen und nicht dem Bedürfnis des Managements die einzig bekannte und die einzig beherrschbare Lösung darüber zu stülpen.
If you only have a hammer, you tend to see every problem as a nail.
(Abraham Maslow)
Die Technik wäre ja längst vorhanden und erprobt. Die letzten Jahre haben uns gezeigt, was mittels Web 2.0 und Cloud-Computing an verteilter Zusammenarbeit möglich ist. Und trotzdem sehe ich in großen IT-Projekten und IT-Programmen oft nicht mehr als eine lächerlich kleine, erschreckend chaotische und nicht durchsuchbare Dateiablage kombiniert mit E‑Mail (ebenfalls beschränkt in der Größe) und Telefon. (Warum das Fax nicht überlebt hat ist mir in diesem Zusammenhang schleierhaft.)
Dabei gibt es in vielen Unternehmen wenigstens schon Wikis, die man als Projektmanager sicherlich auch einsetzen könnte. Mit ein wenig Überzeugungskraft könnte man sicherlich auch Blogs und Microblogging einführen. Man könnte asynchrone Kommunikationsformen bevorzugen und das Team dahingehend erziehen. Aber das wäre ein Risiko, gerade in großen Unternehmen. Man würde etwas anders machen als bisher. Oft geht es uns daher wie von Karl Valentin treffend beschrieben:
Mögen hätt‘ ich schon wollen, aber dürfen hab ich mich nicht getraut!
Traut euch!
Vorangegangene Teile der Serie Projektcoaching
- Projektcoaching (01): Nutzen erkennen
- Projektcoaching (02): Kommunikation
- Projektcoaching (03): Ziele
- Projektcoaching (04): Rollen
- Projektcoaching (05): Risiken
- Projektcoaching (06): Lieferergebnisse
- Projektcoaching (07): Projektstart
- Projektcoaching (08): Sinn stiften
- Projektcoaching (09): Planung
- Projektcoaching (10): Marketing
- Projektcoaching (11): Änderungsmanagement
- Projektcoaching (12): Besprechungen
- Projektcoaching (13): Berichtswesen
- Projektcoaching (14): Meilensteine
- Projektcoaching (15): Führungsrolle
- Projektcoaching (16): Glaubenssätze
- Projektcoaching (17): Effektivität
- Projektcoaching (18): Flöhe hüten
- Projektcoaching (19): Informationsfluss
- Projektcoaching (20): Legehennen
- Projektcoaching (21): Rollenwechsel
- Projektcoaching (22): „Richtige“ Arbeit
- Projektcoaching (23): Arbeit verteilen
- Projektcoaching (24): Verunsicherung
Bildnachweis
Das Artikelbild wurde von Takashi Hososhima unter dem Titel „My favorite lens“ auf Flickr unter eine Creative Commons Lizenz (CC BY-SA 2.0) veröffentlicht (Bestimmte Rechte vorbehalten).