Konflikte bei der Software-Entwicklung tragen die Betroffenen häufig nicht offen, sondern verdeckt aus. Das kann die Kooperation sehr belasten. Die Verarbeitung von Konfliktstoff ist zur erfolgreichen Projektabwicklung unerläßlich.
Viele Projekte stellten sich uns als ein Kampf aller gegen alle dar: Entwickler gegen Entwickler, Anwender gegen Anwender sowie Anwender kontra Entwickler. Nicht die gemeinsame Entwicklungsaufgabe scheint das Band gewesen zu sein, das die Beteiligten zusammenhielt, sondern das Bestreben, die eigenen Belange möglichst weitgehend durchzusetzen, auch wenn dies zu zeitraubenden Auseinandersetzungen führte und dadurch das ganze Vorhaben verzögerte oder gefährdete. Um so schwerer wog es, daß ein Konflikt- Management zur gezielten Verarbeitung des Dissenspotentials weitgehend fehlte. Dieses Bild mag überzeichnet scheinen, es trifft jedoch die Realität in einer recht beträchtlichen Zahl der Softwareprojekte wie auch in anderen Entwicklungsvorhaben, die wir untersuchten (Lullies).
In 65 Prozent der Projekte kam es zu vielen Konflikten, in
35 Prozent zu wenigen. Diese Spannungen wurden in 39 Prozent der Vorhaben offen, in 41 Prozent verdeckt ausgetragen. 20 Prozent der Projekte erlebten sowohl offene als auch verdeckte Auseinandersetzungen.
Die Herstellung eines Konsenses erwies sich in über der Hälfte der Projekte als sehr zeitaufwendig.
Differenzen traten vor allem im Entwicklungsbereich auf (61 Prozent) sowie zwischen Entwicklern und Auftraggebern (35 Prozent). Etwas seltener gab es Reibungen zwischen internen und externen Stellen (24 Prozent), zwischen Entwicklern und Anwendern (24 Prozent) beziehungsweise verschiedenen Anwenderbereichen (22 Prozent).
Schwierigkeiten zwischen Entwicklern und Anwendern beruhten auf den unterschiedlichen Wünschen, Zielvorstellungen und Erfahrungen, die Software-Entwickler einerseits, Auftraggeber und Nutzer andererseits in den Arbeitsprozeß einbrachten. Software-Entwickler legten tendenziell den größten Wert auf technikimmanente Aspekte, so zum Beispiel geringe Beanspruchung von Speicherkapazität, Kompatibilität sowie professionelle Qualitätskriterien wie die Eleganz der Programme. Den Nutzern dagegen ging es vor allem um aufgaben- und arbeitsbezogene Gesichtspunkte wie Erleichterung bei der Aufgabenerledigung oder Belastungsreduzierung.
Divergenzen zeichneten sich auch zwischen einzelnen Gruppierungen von Nutzern ab. Die meisten Entwicklungsprojekte berührten - zumindest potentiell - bestehende Arbeits- und Einflußstrukturen in den Unternehmen, vor allem dort, wo der Einsatz von Software zu Veränderungen in Aufgabenverteilung und Organisation führte oder führen konnte. Schon die Möglichkeit solcher Verlagerungen verlieh Softwareprodukten eine betriebspolitische Qualität das heißt, sie wurden auf Interessenspositionen bezogen.
Gegensätze waren schließlich innerhalb des Entwicklungsbereichs zu erkennen: etwa zwischen den Inhabern hierarchisch übergeordneter und denen ausführender Positionen oder zwischen den in den einzelnen Phasen des Arbeitsablaufs Beschäftigten und nicht zuletzt zwischen den Vertretern verschiedener Programmiersprachen, Betriebs- und Datenbanksysteme.
In einem Dienstleistungsunternehmen waren im Lauf der Jahre eine Vielzahl von Systemen zur Unterstützung administrativer Aufgaben durch die DV zum Einsatz gekommen. Wartung und Weiterentwicklung gestalteten sich zunehmend aufwendig und schwierig. Die Verantwortlichen faßten deshalb die Entwicklung eines umfassenden Systems ins Auge, das die bestehenden Insellösungen integrieren sowie neue Funktionen ermöglichen sollte. Die Realisierung dieses Ansatzes war innerhalb der beauftragten DV- Abteilung zunächst heftig umstritten. Im weiteren Verlauf kam es dann zunehmend zu Auseinandersetzungen mit den Fachabteilungen. Dies alles führte zu erheblichen Verzögerungen. Nach zweieinhalb Jahren, dem ursprünglich angesetzten Zeitraum für das ganze Vorhaben, waren internen Schätzungen zufolge erst etwa zehn bis 20 Prozent des Projektvolumens abgearbeitet.
Vor- und Nachteile von technischen Neuerungen
Viele technische Neuerungen brachten den von ihnen Betroffenen - in den DV-Abteilungen selbst wie in den Fachbereichen - zumindest potentiell Vorund Nachteile: Karriereaussichten, Qualifikationschancen, Handlungs- und Einflußspielräume veränderten sich. Die Wahl zwischen IBM oder DEC entschied nicht nur zwischen zwei Herstellern beziehungsweise technischen Anlagen, sondern auch über persönliche Zukunftsperspektiven. Ebenso konnte sich jede Programmiersprache auf die Einflußverteilung zwischen DV und Fachbereichen auswirken. Festlegungen hinsichtlich DV- Lösungen betrafen also zweierlei: die technische Lösung und deren nicht technische Konsequenzen. Diese letzteren konnten allerdings viele Betroffene zunächst schwer einschätzen. Nicht selten traten sie erst im Verlauf des Entwicklungsprozesses, im Zuge der zunehmenden Konkretisierung des Softwareprodukts oder bei seinem Einsatz im Normalbetrieb zutage.
Komplexe Projekte schaffen komplexe Probleme
All diese Schwierigkeiten machten sich um so stärker bemerkbar, je ehrgeiziger, das heißt umfassender und integrativer, die Zielsetzung des Vorhabens war. Projekte waren oft beeindruckend komplex: durch ihren Umfang, durch die Zahl der zu berücksichtigenden Variablen, durch die Integration von Teilsystemen, durch die Bedeutung der Kompatibilität mit bereits eingesetzter Hard- und Software und durch die Zahl der involvierten betrieblichen Stellen. In dem Maß, in dem die Verfahren der Computerunterstützung sich als umfassender und flexibler nutzbar herausstellten, gewann die Anwendungssituation an Bedeutung und mußte im Prozeß der Software- Entwicklung mit berücksichtigt werden. Dies bedeutet: Die neue Generation von Softwareprojekten mit weitgespannter, integrativer Zielsetzung ist - zumindest dort, wo sie auf ein betriebliches Anwendungsfeld zielt - im besonderen Maß konfliktträchtig und damit auf die Verarbeitung des Konfliktpotential angewiesen.
Wir stellten eingangs fest, daß Software-Entwicklung sowohl Technikgestaltung als auch Arbeitstrukturierung beinhaltet und das diese doppelte Bindung die Notwendigkeit des Ausgleichs divergierender Interessen bedingt. Dies hat unsere Untersuchung stets aufs neue bestätigt. Viele Projekte mußten einen Doppelprozeß von technischer Problemlösung und Interessen -aushandlung, also "politischer" Verarbeitung, bewältigen. Beide Abläufe waren auf vielfältige und meist schwer durchschaubare Weise miteinander verwoben. Aus der technischen Entwicklung ergaben sich Impulse für die politische Dimension, die ihrerseits immer wieder in jene hineinwirkte Diese Wechselwirkung gewann eine Eigendynamik, die auch den Projektablauf bestimmte.
Mit anderen Worten: Die betriebspolitische Verarbeitung war notwendigerweise Teil des Software- Entwicklungsprozesses insbesondere bei integrativen Projekten.
Die Beherrschbarkeit der software- und ablauftechnischen Komplexität setzte die Kenntnis der politischen Konstellation voraus.
Mit Sicherheit war eine Ausblendung von Konfliktpotential wie in jenem Projekt, in dem die Software- Entwickler einen fertigen Auftrag als Vorgabe erhielten, nicht die Lösung. Das Vorgehen mochte eine raschere Abwicklung der ersten Phasen des Projekts ermöglichen - auf Kosten sowohl der späteren Aufgabenangemessenheit des Softwareprodukts als auch der Akzeptanz bei den Anwendern.
Die betriebspolitische Dimension wirkte sich auch auf das Niveau der neuen Anwendungen aus. Führte die politische Verarbeitung zu einer Verwässerung von konzeptionellen Entwürfen, zu Kompromissen, die schließlich die Qualität des Produkts
beeinträchtigten, oder leistete sie eine Anpassung an die Anforderungen der Einsatzsituation, eine Durchsetzung des Primats des Aufgabenbezugs? Die Alternative ist falsch gestellt - es handelt sich hier nicht um ein Entweder-Oder. Alles spricht dafür, daß die Güteklasse des Softwareprodukts nicht zuletzt auch von der Qualität der betriebspolitischen Verarbeitung abhing.
Konflikte meist in frühen Projektphasen
In einigen Projekten waren Bemühungen zu erkennen, sich den Problemen und Anforderungen des Doppelprozesses von technischer und politischer Entwicklung zu stellen. Insgesamt vermittelten jedoch nur wenige Vorhaben den Eindruck, daß es gelungen ist, die betriebspolitische Eigendynamik wirklich in den Griff zu bekommen. Vor allem erwies sich das hierzu verfügbare methodische Instrumentarium, zum Beispiel CASE, als kaum wirksam im Gegenteil: Eine einseitige Orientierung solcher Tools verstärkte die Gefahr einer untergründigen und damit ungesteuerten Wirksamkeit der politischen Bewegungen.
Als besonders konfliktträchtig erwiesen sich die frühen Projektphasen, in denen es darum ging, sich auf das Spektrum der Anforderungen zu einigen, die die zu entwickelnde Software abdecken sollte. Schon die Eingrenzung fast der Hälfte der Projekte verlief kontrovers. Die Spezifikation der Anforderungen war vielfach ein langwieriger Prozeß, in dem immer wieder Meinungsverschiedenheiten aufbrachen, die sich dann auch im weiteren Verlauf der Projekte bemerkbar machten.
Konflikte blieben aber keinesfalls auf diese frühen Phasen beschränkt auch im späteren Verlauf der Arbeiten kam es ständig - und häufig weitgehend unerwartet - zu Auseinandersetzungen, die den Fortgang verzögerten und belasteten. Dazu trug nicht zuletzt bei, daß ein Konsens, der zwischen den beteiligten Parteien etabliert schien, sich als nicht tragfähig zeigte, sei es, weil er unter falschen Voraussetzungen zustandegekommen war, sei es, weil sich die Rahmenbedingungen verändert hatten.
Ein Softwareprojekt in der Hauptverwaltung eines Großkonzerns wurde durch die Auseinandersetzung zweier Bereichsleiter für eineinhalb Jahre blockiert. Die Einführung des Systems hatte die Verlagerung bestimmter Aufgaben und damit auch von Stellen aus einem Bereich in den anderen erfordert. Der Einspruch des betroffenen Bereichsleiters führte dazu, daß der Investitionsausschuß das bereits geprüfte und genehmigte Projekt einer erneuten Wirtschaftlichkeitsprüfung unterzog. Bis zu deren Abschluß war eine Fortführung der Entwicklungsarbeiten nur in sehr begrenztem Umfang möglich.
Solcher Scheinkonsens, der sich dann später als trügerisch erwies, war nicht zuletzt mitverantwortlich dafür, daß so viele Meinungsverschiedenheiten verdeckt ausgetragen wurden. Bei fast zwei Dritteln der Projekte erfuhren wir von solchen unter der Oberfläche schwelenden Konflikten, deren Bereinigung - so wurde meist deutlich - sich als besonders schwierig und zeitraubend herausstellte. Um einen Begriff aus der Psychologie zu verwenden: Konflikte wurden verdrängt - und führten gerade deshalb ein Eigenleben, das nur schwer zu steuern war. Besonders Großprojekte litten an solchen ungeklärten Differenzen, während es in mittel -großen und kleinen Vorhaben eher zum offenen Ansprechen der Gegensätze kam. Ein Symptom von Verdrängungen, das zugleich die Auseinandersetzungen über die Systemgestaltung erschwerte, war der Umstand, daß häufig auf technischer Ebene argumentiert wurde, selbst da, wo es auch oder primär um politische Aspekte ging. Dadurch kamen letztere nicht ausdrücklich und offen auf den
Tisch. Dabei wäre es wohl falsch, diese Diskussionen um Technik nur als Scheinerörterungen aufzufassen, durch die die letztlich ausschlaggebenden politischen Aspekte verdeckt wurden. Natürlich hatten die technischen Aspekte Gewicht und konnten die Entscheidungen beeinflussen, nur war in den Auseinandersetzungen meist schwer auszumachen und vor allem nicht nachzuweisen, welche Ebene - die technische oder die politische - nun letztlich gerade den Ausschlag gegeben hatte (siehe Kasten auf Seite 64)
Mit dieser Doppelbödigkeit umzugehen, fiel offensichtlich nicht leicht, und ohne Zweifel trug sie zu der beträchtlichen
Emotionalität bei, mit der Auseinandersetzungen häufig ausgetragen wurden. Zwar bezogen sich unsere Gesprächspartner in ihren Berichten über den Projektablauf offen, ausführlich und reflektiert auf die Kontroversen und die betriebspolitischen Interessen, die diese bestimmten. "Das war eben politisch" war in vielen Gesprächen ein häufig wiederkehrendes Leitmotiv. Diese Betrachtungsweisen fanden jedoch kaum einen - für uns erkennbaren - Niederschlag in der Projektpraxis und in den Lehren und Konsequenzen, die man aus den Erfahrungen abgeschlossener Arbeiten zog. Im wesentlichen standen dann doch wieder Fragen nach der software- und ablauftechnischen Komplexität im Vordergrund des Interesses.
Zunächst erschien uns das inkonsequent und eher enttäuschend. Im Kontext der betrieblichen Praxis waren die Reaktionen jedoch verständlich und durchaus realitätsgerecht. Politik begriffen die Beteiligten nicht als eigene Dimension, sondern als integrale Qualität allen Geschehens; ihre Wirksamkeit bezog sie daraus, daß sie nicht offensichtlich war.
Entmythologisierung der Software- Entwicklung
Die Forderung nach der Entwicklung von Instrumenten und Verfahren, die explizit der politischen Verarbeitung von Entwicklungsprozessen gelten, mag dementsprechend naiv scheinen. Trotzdem meinen wir, daß eine ausdrückliche Auseinandersetzung mit der Frage, wie der Eigendynamik des Doppelprozesses bei Software- Entwicklungsprojekten zu begegnen sei, sowohl in der Praxis der Anwenderunternehmen und Software- Institute wie auch in der wissenschaftlichen Diskussion notwendig ist. Hilfreich könnte eine Entmythologisierung der Software-Entwicklung als rein ingenieursmäßiger Vorgang sein, bei der ihr Doppelcharakter als Prozeß technischer Entwicklung sowie politischer Auseinandersetzung zu verdeutlichen wäre. Unbedingt wünschenswert sind schließlich organisatorische Modelle, die eine tragfähige Grundlage für die Verarbeitung von Interessengegensätzen und Konfliktpotential liefern, um die Thematisierung der betriebspolitischen Fragen zu erleichtern.
Dies gilt auch für Ansätze zur Aktivierung der Nutzerpartizipation. Schwierigkeiten bei deren Durchsetzung sind nicht selten auf eine mangelnde Berücksichtigung der politischen Dimension zurückzuführen. Hier Konzepte zu entwickeln, ist eine lohnende Aufgabe, die nicht zuletzt einen Dialog zwischen Informatik, Arbeitswissenschaft Soziologie und der Praxis nahelegt. Wie wichtig eine Verarbeitung von Konfliktpotential für die erfolgreiche Abwicklung von Projekten ist, wird in der nächsten Folge deutlich werden, in der wir uns mit den Ursachen und Auswirkungen von Krisen im Projektablauf auseinandersetzen.