projekt MA N A G E M E N T aktuell 1/ 2014 l 43 Der Interventionszyklus Situationen wie die in Teil 1 geschilderte machen eine oder mehrere Interventionen notwendig, um die Störungen und Probleme zu beseitigen. Aufgrund der Gefahr misslingender Interventionen ist allerdings eine genügende Vorbereitung und Planung notwendig. Dies soll durch den im Folgenden näher beschriebenen Interventionszyklus (Abb. 1) sichergestellt werden. Jede Intervention basiert auf einer möglichst genauen Beobachtung des zu intervenierenden Systems. Wie wir bereits mehrfach dargestellt haben, heißt Beobachten immer, mit eigenen Augen sehen und mit den eigenen Ohren hören. Das Resultat einer Beobachtung ist also nicht „die Wahrheit“, sondern die gedankliche Konstruktion des beobachtenden Subjekts über das beobachtete Objekt. Gerade weil Beobachtungen subjektiv sind, braucht es eine vertiefte Reflexion der dabei gewonnenen Resultate. Der Beobachter tritt dabei bis zu einem gewissen Grade neben sich selbst und versucht sich in die Situation und Lage des beobachteten Systems hineinzuversetzen, um zu erkennen, was in diesem System vorgehen könnte. Er bildet sich also eine Hypothese über Gründe und Ursachen für das beobachtete Verhalten. Auch solche Hypothesen können für sich keine Wahrheit beanspruchen. Je besser die auf einer reflektierten Hypothese aufbauende Intervention im Sinne des Beobachters wirkt, desto brauchbarer ist die Wirklichkeitskonstruktion. Dies hat also weniger mit Wahrheit als mit Wirksamkeit zu tun. In unserem Rigi-Beispiel wurden die Beobachtungsresultate in Zug und Luzern zunächst sehr unterschiedlich reflektiert. Aus einer systemischen Sicht war es jedoch Fallstudie Interventionen als Praktik der sozialen Führung von Projekten, Teil 2 Wie können Beeinträchtigungen in der Zusammenarbeit im Projekt erkannt und wirkungsvoll beseitigt werden? Sobald mehrere Personen in Projekten involviert sind oder von diesen in ihren grundlegenden Interessen tangiert werden, wird die Zusammenarbeit zwischen den beteiligten Personen und den involvierten Gruppen zum zentralen Erfolgskriterium. Die Etablierung und die Aufrechterhaltung einer gut funktionierenden Zusammenarbeit zwischen diesen Rollen ist eine zentrale Aufgabe in Projekten. Ein am Institut für Informatik der Universität Zürich entwickelter Ansatz stellt die Führung der sozialen Prozesse als entscheidenden Faktor für erfolgreiche Projekte in den Mittelpunkt [2]. Die soziale Projektführung soll die beteiligten Teams und die betroffenen Anspruchsgruppen durch die Klippen und Fallstricke der Projektarbeit leiten. Die Redaktion dankt dem vdf Hochschulverlag für die Abdruckerlaubnis. Eine ausführliche Beschreibung der Steuerung der sozialen Prozesse im Projekt und insbesondere die verwendeten Konzepte und Praktiken finden sich im 5. Kapitel des Buches von Huber, A./ Kuhnt, B./ Diener, M.: Projektmanagement. Erfolgreicher Umgang mit Soft Factors. vdf Hochschulverlag AG an der ETH Zürich, Zürich 2011. (Vergleiche auch die Besprechung dieses Buches in projektMANAGEMENT aktuell 2/ 2012.) Teil 1 dieses Artikels ist im letzten Heft erschienen. Andreas Huber, Markus Diener Die Fallstudie von Huber und Diener demonstriert an einem Beispiel aus dem IT-Bereich einen am Institut für Informatik der Universität Zürich entwickelten Ansatz zur Führung von sozialen Prozessen. Das Konzept zeigt die soziale Führung als entscheidenden Erfolgsfaktor in Projekten. +++ Für eilige Leser +++ Für eilige Leser +++ Für eilige Leser +++ Abb. 1: Interventionszyklus PM_1-2014_1-72: Inhalt 30.01.2014 13: 21 Uhr Seite 43 nachvollziehbar, dass sich durch die lange Trennung der beiden Projektteams zwei soziale Systeme gebildet hatten, die sich zunehmend operativ schlossen. Die Kommunikation kam immer mehr zum Erliegen, was zu einem Verlust an Koordiniertheit führte. In beiden Teams wurden die Projektwerte der jeweiligen Organisation weitergepflegt, und es wurde nichts unternommen, um eine gemeinsame, organisationsübergreifende Projektidentität und -kultur zu entwickeln. Was in früheren Phasen in Ansätzen an Gemeinsamkeit erarbeitet wurde, zerfiel dementsprechend langsam, aber sicher. Diese Überlegungen gipfelten in der Hypothese, dass die Zusammenarbeit zwischen den Entwicklern in Zug und den Testern in Luzern nicht eng genug war. Weiter betrachtete Zug das Testvorgehen in Luzern als nicht angemessen. Aufgrund der Hypothese wird nun entschieden, ob und wie interveniert werden soll. Meistens gibt es verschiedene Interventionsmöglichkeiten. Es ist zu klären, welche Interventionsvariante die gewünschte Veränderung am ehesten bewirken könnte. Auch hier geht es also ausschließlich um die Wirksamkeit eines bestimmten Vorgehens. Die Intervention selbst wird geplant und in einem möglichst geeigneten kommunikativen Raum durchgeführt. Das System reagiert auf die Intervention - oder auch nicht, was auch als Reaktion betrachtet werden kann. Die Veränderung oder Nichtveränderung kann nun wieder beobachtet werden, und der Interventionszyklus beginnt von Neuem, bis sich das gewünschte Resultat einstellt oder nur noch die Erkenntnis bleibt, dass in einem bestimmten Kontext eine Steuerung durch Interventionen nicht möglich ist. Das mehrmalige Durchlaufen des Zyklus erhöht aber die Chance, dass die in der Reflexionsphase getroffenen Hypothesen immer präziser und die durchgeführten Interventionen wirksamer werden. Ziel einer Intervention ist es, die Selbststeuerungsmechanismen in einem Projekt zu stärken und damit weitere Interventionen zu minimieren, denn damit sinkt auch das Risiko eines Misslingens. Fallstudie II: Sunrise at Rigi Eskalation als erster Schritt: Die Frage im Rigi-Projekt lautete also: Wie weiter? Die erste Initiative ging von Zug aus. Es gab eine massive Eskalation auf Geschäftsleitungsebene, dass die Situation grundsätzlich zu ändern sei. Dabei kam eine Einigung zustande, dass in Luzern ein von beiden Seiten akzeptierter Testkoordinator eingesetzt werden sollte, welcher die verfahrene Testsituation zu lösen hatte und dabei teilweise vor Ort vom Zuger Entwicklungsleiter unterstützt wurde. Diese Eskalation auf Stufe der Geschäftsleitung war nicht ganz ohne Risiko. Hätte Luzern den Vorstoß abgewiesen, wäre das Projekt akut gefährdet gewesen. Das Ergebnis der Eskalation war eine Veränderung auf der Strukturebene. Es wurde eine neue zentrale Stelle geschaffen. Damit war das Zusammenarbeitsproblem aber noch lange nicht aus dem Weg geräumt. Der Luzerner Testkoordinator stand nun vor der Frage, was konkret geändert werden müsste resp. welche Intervention angesichts der aktuellen Lage die besten Erfolgschancen versprach. Reflexion, Hypothese und Entscheid: Aufgrund ihrer Beobachtungen bildeten der Testkoordinator und der Zuger Entwicklungsleiter die Hypothese, dass der Testprozess radikal zu entschleunigen sei. Es galt, zwischen zwei Interventionsvarianten zu entscheiden. Eine Möglichkeit war die Etablierung eines „Vorbild-Teams“, zusammengesetzt aus dem Testkoordinator, einem Businessanalysten aus Luzern und einem Entwickler aus Zug. Dieses Team hätte vorgezeigt, wie in enger Kooperation vor Ort Schritt für Schritt markante Fortschritte erzielt werden können und wie in der aktuellen Phase konkret vorzugehen wäre. Die zweite Variante sah eine sehr viel direktere und härtere Intervention vor: Alle Tester in Luzern müssen 10 bis 15 Testfälle bestimmen, welche die Hauptprozesse abdecken. Innerhalb von zwei Wochen dürfen nur diese Testfälle bearbeitet werden, damit die volle Durchgängigkeit erreicht werden kann, ohne dass dabei die Zahl der Einträge im Issue-Tool unnötig explodiert. Dazu musste jeder Tester mit seinem Entwicklungspartner in Zug die auftauchenden Probleme in direkter Kommunikation und, wenn immer möglich, vor Ort in Luzern lösen. Alle bisher erfassten Issues waren zudem radikal neu zu priorisieren und es hatte ein tägliches Testkoordinationsmeeting in Luzern stattzufinden. Der Testkoordinator entschied sich schlussendlich für die zweite und härtere Variante. Das höhere Risiko wurde im Hinblick auf den immer größer werdenden Zeitdruck in Kauf genommen. Interventionsablauf: Die Intervention wurde an einem Meeting mit allen Businessanalysten durchgeführt und stieß zuerst auf erhebliches Unbehagen. Es brauchte zwei Zusatzrunden, bis die verlangten Haupttestfälle standen, und auch die Neupriorisierung der Fehler erwies sich als ein zähes Ringen. Als ein Misserfolg stellte sich bald das tägliche Testmeeting heraus. Es dauerte zu lange, und da die gegenseitigen Abhängigkeiten zwischen den einzelnen Testern gering waren, sank das Interesse der Teilnehmer am Austausch. Auf der Basis dieser Beobachtung fasste der Testkoordinator den Entschluss, jeden Morgen jeden Tester zwischen 8 und 10 Uhr zusammen mit dem Zuger Entwicklungsleiter persönlich zu besuchen. An diesen Rundgängen nahm auch der Luzerner Teilprojektleiter, der für die fachliche Umsetzung verantwortlich war, wenn immer möglich teil. An den kurzen Stehmeetings während des Rundgangs wurden die am Vortag neu gefundenen Fehler inhaltlich beurteilt und priorisiert, die notwendigen Maßnahmen besprochen und der Testfokus für den aktuellen Tag festgelegt. Auch wurde sofort ersichtlich, wenn die Tests aus technischen oder applikatorischen Gründen nicht vorankamen. Die neuen Fehler, welche Zug betrafen, waren dem Entwicklungsleiter bekannt. Er konnte diese am Nachmittag in Zug vor Ort mit seinen Mitarbeitern besprechen und deren Feedback am nächsten Tag in Luzern wieder einspeisen. Bei komplexeren Problemen wurde jeweils sichergestellt, dass der betroffene Entwickler die Probleme direkt vor Ort in Luzern besprach und wenn möglich löste. Damit kam langsam wieder eine intensivere Kommunikation in Gang. Der Rundgang kann als kommunikativer Raum betrachtet werden. Die Interventionen des Testkoordinators und des Zuger Entwicklungsleiters erfolgten nun 22 l projekt MA N A G E M E N T aktuell 1/ 2014 44 WISSEN PM_1-2014_1-72: Inhalt 30.01.2014 13: 22 Uhr Seite 44 zeitnah und hatten nicht mehr die Heftigkeit der ersten Interventionen. Langsam kehrte Ruhe ein und das Projekt fasste wieder Tritt. Es wurde termingerecht und ohne später auftretende Komplikationen eingeführt. Neben den geschilderten Interventionen wurde parallel das Test-Reporting verbessert, um auf täglicher und wöchentlicher Basis eine optimale Transparenz herzustellen. Ein wöchentliches Issue-Meeting auf der Ebene des Projektmanagements zwischen Zug und Luzern trug als weiterer kommunikativer Raum ebenfalls zur Deeskalation bei. Fazit Zusammenarbeit, so sollte deutlich geworden sein, bringt auch Konflikte hervor. Entweder prallen unterschiedliche Interessen aufeinander oder unterschiedliches Wissen, unterschiedliche Theorien und Erfahrungen. In den strukturellen Grundlagen, welche die initiale Koordiniertheit prägen, begegnen uns Konflikte zunächst als Konfliktpotenziale. Man kann immer davon ausgehen, dass verschiedene Kooperationspartner unterschiedliche Ansichten über die Ziele, die Wege der Zielerreichung, die Verteilung der Ressourcen oder die Beziehungen selbst haben. Erfahrungen zeigen, dass diese Konfliktpotenziale erst im Laufe der konkreten Zusammenarbeit aufscheinen und zu Störungen oder Krisen führen können. Sie können die Zusammenarbeit einerseits ernsthaft gefährden. Sie können andererseits aber auch anzeigen, dass in Entscheidungsprozessen bei komplexen Problemen gerade im unterschiedlichen Wissen sowie aufgrund verschiedener Theorien oder Erfahrungen der Schlüssel zur besseren Problemlösung oder Entscheidung liegt. Kooperatives Handeln zeigt sich somit zum einen in der Antizipation von Konflikten und deren frühzeitigen Thematisierung. Zum anderen zeigt es sich in der Bearbeitung manifester Konflikte. Interessenkonflikte erfordern eher die Aushandlung unter den beteiligten Akteuren. Konzeptionelle Konflikte benötigen Methoden der Integration unterschiedlicher Standpunkte hinsichtlich Wissen, Theorien und Erfahrungen. Hierfür sind Methoden vorhanden, die theoretisch fundiert, empirisch geprüft und praktisch anwendbar sind. Oftmals haben sie den Weg in die Organisationen noch nicht gefunden [3, 4]. In der täglichen Projektarbeit stellt deshalb das frühzeitige Erkennen von potenziellen Konflikten und Problemen in der Zusammenarbeit eine wichtige Führungsaufgabe dar. Dabei stehen ein hoher Grad von Selbstführung, die kontinuierliche Verbesserung von störungsanfälligen Prozessen und die sofortige Behebung sich abzeichnender Konflikte im Vordergrund. ■ Literatur [1] Baumgartner, A./ Korff, W.: Wandlungen in der Begründung und Bewertung von Arbeit. In: Handbuch der Wirtschaftsethik. Bd. I, Gütersloh 1999, S. 88-99 [2] Huber, A./ Kuhnt, B./ Diener, M.: Projektmanagement: erfolgreicher Umgang mit Soft Factors. Zürich 2011 [3] Vollmer, A./ Manser, T./ Wehner, Th.: Prozessorientierte Kooperationsforschung: zum aktuellen Stand eines arbeitspsychologischen Kooperationsmodells. In: Vollmer, A. (Hrsg.): Kooperatives Handeln zwischen Kontinuität und Brüchen in neuen Tätigkeitssystemen. Theoretisch-konzeptionelle Zugänge und empirische Ergebnisse aus der Arbeits- und Organisationspsychologie und angrenzenden Disziplinen. Lengerich 2006, S. 18-45 [ 4] Vollmer, A./ Wehner, Th.: Konfliktbearbeitung in Innovationsprozessen: Bestehende Konzepte und Empfehlungen zu deren Erweiterung. In: Führung + Organisation, 1/ 10, S. 13-17 [5] Willke, H.: Systemtheorie II: Interventionstheorie. Stuttgart 2005 Schlagwörter Kommunikation, Projektteams, Soft Skills, soziale Projektführung, Zusammenarbeit im Projekt Kompetenzelemente der NCB 3.0 4.1.7 Teamarbeit, 4.1.18 Kommunikation, 4.2.1 Führung, 4.2.12 Konflikte und Krisen Autor Andreas Huber, Studium der Volkswirtschaft, 1992 Dissertation in Wirtschaftsinformatik an der Universität Zürich über Wissensmanagement, Weiterbildungen in systemischer Organisationsberatung, personenzentrierter Beratung und Coaching; Oberassistent bei Prof. Helmut Schauer und Leiter des Schwerpunkts Mensch - Informatik - Organisation an der Universität Zürich 1994 bis 2006, seit 1996 Inhaber der Firma Huber Consulting, Beratungsmandate in diversen öffentlichen und privaten Unternehmen zum Aufbau von Projektmanagementsystemen, zur Begleitung von Businessprojekten und zur Strategieentwicklung; seit 2009 Professor für Projektmanagement an der Berner Fachhochschule Anschrift Berner Fachhochschule Fachbereich Wirtschaft Morgartenstrasse 2 a CH-3000 Bern 22 E-Mail: Andreas.Huber@bfh.ch Autor Markus Diener, kaufmännische Ausbildung mit diversen Weiterbildungen in Informatik, Projektmanagement und Banking, Nachdiplom-Studium Mensch - Informatik - Organisation an der Universität Zürich 2006; nach einigen Jahren Berufserfahrung im Banking und in der Leitung des Wertschriften-Back-Office einer Privatbank Wechsel in die Informatik einer großen Retailbank, diverse Projekte im Host-Umfeld, später Leitung einer dezentralen Software- Entwicklungsabteilung, 1999 Gründungsmitglied und Managing-Partner der Informatikfirma Infometis AG, seit 2009 bei der Bank Vontobel für die Entwicklung und den Betrieb der Trading-, Asset-Management- und Web-Applikationen verantwortlich Anschrift Bank Vontobel AG Head of Front-Applications Dreikönigstrasse 37 CH-8002 Zürich projekt MA N A G E M E N T aktuell 1/ 2014 l 45 PM_1-2014_1-72: Inhalt 30.01.2014 13: 22 Uhr Seite 45