Von Friedrich Weltz und Rolf Ortmann*

Die Möglichkeit, Entwicklungsarbeiten nach außen zu vergeben, eröffnet bei der Abwicklung von Softwareprojekten zusätzliche Gestaltungsmöglichkeiten, aber auch besondere Anforderungen. Die Arbeitsteilung von externen und internen Kräften ist da. mit wesentlicher Aspekt des Projekt-Managements. In der Praxis wird dies allerdings vielfach kaum berücksichtigt.

In der Mehrheit der Projekte begegneten wir einer Kombination aus internen Leistungen, die vom Träger oder vom Auftraggeber der Software-Entwicklungsmaßnahme erbracht wurden, und Fremdleistungen durch Softwarehäuser, Hersteller, Berater etc.

In 57 Prozent der Projekte wurden externe Leistungen in Anspruch genommen. Bei Entwicklungen waren 17 Prozent der restlichen Fälle für einen externen Auftraggeber.

Nur 26 Prozent der Projekte stellten Entwicklungen für Anwendungen im eigenen Unternehmen dar beziehungsweise für Softwareprodukte, die vom eigenen Unternehmen vertrieben wurden, die auch ganz mit eigenen Kräften durchgeführt wurden.

Der Anteil, den die Fremdleistungen an den Gesamtvolumina dieser Projekte ausmachten, variierte von Projekt zu Projekt erheblich, von zwei bis zu 90 Prozent. Der durchschnittliche Anteil belief sich immerhin auf 32 Prozent.

Kein Großprojekt ohne Fremdleistungen

Bei "Eigenentwicklungen" in Anwenderunternehmen wurden Fremdleistungen in zwei Drittel der Projekte in Anspruch genommen. Bei Auftragsentwicklungen war dies immerhin bei etwa 40 Prozent der Fall.

Eine Arbeitsteilung zwischen internen und externen Arbeitskräften kann also als normale Bedingung bei der Durchführung von Software-Entwicklungsvorhaben gesehen werden.

Das heißt allerdings nicht, daß dies immer bereits zu Beginn des Projekts vorgesehen war. In immerhin einem Drittel der Projekte mit Fremdleistungen griff man erst im Projekt. verlauf auf Externe zurück meist als Ausweg bei Schwierigkeiten und Verzögerungen, die sich bei der Projektabwicklung ergaben.

Erwartungsgemäß wurden vor allem in Großprojekten Fremdleistungen in Anspruch genommen. Bemerkenswert erscheint immerhin, daß kein einziges der untersuchten Großprojekte ohne Fremdleistungen auskam - bemerkenswert auch, daß dies nur in gut der Hälfte der Projekte von Anfang an geplant war. In kleineren Projekten griff man nicht nur weniger häufig auf Fremdleistungen zurück, vor allem geschah dies auch nur relativ selten ungeplant.

Teilweise recht komplexe Konstruktionen

Die Fremdleistungen wurden von recht unterschiedlichen

Trägern erbracht:

- Beauftragung eines Softwarehauses mit der Durchführung des Projektes, wobei die internen Leistungen des Auftraggebers sich im wesentlichen auf die Mitarbeit an der Erstellung der Zielvorgaben (Pflichtenheft, Anforderungsspezifikation etc.) beschränken;

- Heranziehung externer Berater für die Durchführung von Ist-Analysen beziehungsweise die Erarbeitung des technischen Konzepts, die weitere Durchführung des Projektes liegt dann in den Händen interner Kräfte; - Beauftragung einzelner externer Kontraktoren, insbesondere mit der Ausführung von Programmierarbeiten;

- Beschäftigung externer Experten (zum Beispiel Mitarbeiter von Softwarehäusern, Beratungsfirmen oder Selbständige) für die Dauer des Projekts oder einzelne Projektphasen als Leiharbeiter (Bodyleasing).

Am häufigsten wurden die Fremdleistungen durch Softwarehäuser erbracht (35 Prozent), weit verbreitet war auch "Bodyleasing", das heißt, Mitarbeiter einer externen Institution wurden meist für einen längeren Zeitraum an das Unternehmen, in dem das Projekt durchgeführt wird, ausgeliehen (30 Prozent), und die Beschäftigung einzelner Kontraktoren (17 Prozent). Seltener war die Inanspruchnahme externer Leistungen von Herstellern (sieben Prozent) und Unternehmensberatern (sieben Prozent).

Teilweise stießen wir auf recht komplexe Konstruktionen:

- Der Auftraggeber, ein großes Industrieunternehmen, beauftragte einen großen Hersteller mit der Durchführung des Entwicklungsprojektes; dieser wiederum vergab die Programmierarbeiten an ein kleines Softwarehaus.

- Das Entwicklungsprojekt wurde in enger Zusammenarbeit zwischen Arbeitsgruppen beim Auftraggeber, einem Hersteller und zwei Softwarehäusern ausgeführt.

- Planung und Leitung eines Projekts bei einem großen öffentlichen Dienstleistungsunternehmen lagen im wesentlichen in den Händen externer Experten, die für die Dauer des Projekts langfristig verpflichtet wurden. Zugleich wurde ein Großteil der Programmierarbeiten nach außen an Kontraktoren vergeben.

Bisweilen hatten sich zwischen den auftraggebenden unternehmen und den Anbietern externer Leistungen recht stabile und dauerhafte Beziehungen entwickelt, die über die Spanne mehrerer Projekte beziehungsweise Projektabschnitte hinweg reichten oder als kontinuierliche Kooperationsbeziehungen definiert waren.

- Eine Arbeitsgruppe in einem großen Softwarehau war über mehrere Jahre kontinuierlich und ausschließlich für eine Großbank mit der Entwicklung und Pflege eines Softwaresystems beschäftigt.

- Ein kleines Software-Institut arbeitete ausschließlich und kontinuierlich für ein großes Versicherungsunternehmen in mehreren Teilprojekten an einer umfassenden Erneuerung der DV-Landschaft,

- In einem sehr umfangreichen Entwicklungsvorhaben eines großen Öffentlichen Auftraggebers wurde zunächst ein Projekt mit zweijähriger Lauf. zeit vergeben, wobei von vornherein eine Fortsetzung anvisiert wurde. Tatsächlich kam es dann zu drei Folgeprojekten, in denen das entwickelte System erweitert und modifiziert wurde.

Für solche langfristigen Entwicklungsvorhaben schlossen die Beteiligten meist Rahmenverträge für ein oder mehrere Jahre ab, innerhalb derer dann einzelne Teilaufträge ohne größere Genehmigungsprozeduren erteilt beziehungsweise Leistungen abgerufen werden konnten. Die Aussicht auf einen solchen Dauerauftrag führte in einigen Fällen erst zur Gründung des Software-Instituts.

So hatte zum Beispiel ein Softwareberater zunächst als

Einzelperson bei der Erarbeitung eines neuen DV-Konzepts in einem Großunternehmen mitgewirkt, später beauftragte ihn die Geschäftsleitung mit der Realisierung eines Teilkomplexes. Um diesen Auftrag entstand ein kleines Software-Institut, das auch andere Projekte ausführte,

Umgekehrt wechselten im Verlauf mehrerer Projekte externe Experten in ein festes Beschäftigungsverhältnis beim Auftraggeber über. Die Gründe für die Vergabe von Entwickungsarbeiten nach außen beziehungsweise die Verpflichtung externer Experten schienen auf den ersten Blick relativ klar konturiert.

Wesentlicher Aspekt war vielfach die Flexibilisierung des Personaleinsatzes. In den verschiedenen Projektphasen wurden ja meist personelle Ressourcen in, sehr unterschiedlichem Umfang benötigte entsprechend schwankte die personelle Besetzung im Projektverlauf beträchtlich.

Mit dem Einsatz externer Entwickler war kurzfristig eine Vergrößerung der verfügbaren personellen Ressourcen möglich, ohne daß sich damit langfristige Verpflichtungen ergaben. So konnte eine dauerhafte Ausweitung des festangestellten Personals vermieden werden, das unter Umständen nach den arbeitsintensiven Projektphasen nicht weiter benötigt wurde. Dies galt etwa für die Vergabe von Programmierarbeiten nach außen, wie sie nicht nur in Anwenderunternehmen, sondern auch in Softwarehäusern praktiziert wurde.

Für öffentliche Verwaltungs- und Dienstleistungsunternehmen, deren Flexibilität beim Personaleinsatz beziehungsweise bei der Rekrutierung qualifizierten Personals durch die geltenden Richtlinien stark eingeschränkt ist, war teilweise die Möglichkeit, externe Dienstleistungen zu nutzen, Oberhaupt erst Voraussetzung dafür, ein Projekt in Angriff zu nehmen.

In einigen Projekten führten offensichtlich fehlende Expertise und Erfahrung zur Inanspruchnahme externen Know-hows. Dies spielte nicht nur in kleineren oder mittelgroßen Unternehmen eine Rolle, sondern durchaus auch in Großunternehmen. Erforderlich machte dies nicht zuletzt der rasche technische Wandel sowohl auf dem Gebiet der Hardware als auch im zunehmenden Maß bei der Software (Sprachen, Tools etc.). Vor allem dort, wo der Übergang zu neuen Systemen oder Verfahren anstand, wurden externe Experten herangezogen. Der Aufbau, ausreichender Kompetenz in neuen Feldern im laufenden Betrieb, der tendenziell auf eine Perfektionierung der bestehenden Verfahren beziehungsweise des mit diesem verbundenen Wissens drängt, war offensichtlich nicht erfolgt.

Hinter diesen manifesten Gründen der Inanspruchnahme externer Leistungen - Ausgleich fehlender personeller Kapazitäten und Expertise - standen häufig unausgesprochene 1 Erwartungen. Auf die Rolle von Beratern als Change Agents wird ja immer wieder hingewiesen.

Softwareprojekte ausgesprochen konfliktträchtig

Im Rahmen der Software-Entwicklungsprojekte ist diese Funktion nicht zuletzt deshalb besonders wichtig, weil sich die Durchsetzung, Gestaltung und Abwicklung von Softwareprojekten in vielen Unternehmen ausgesprochen konfliktträchtig gestaltet. In diesem Feld wider. streitender Interessen erhält die Beauftragung externer Stellen eine eindeutig betriebspolitische Komponente.

Mit der Vergabe von Entwicklungsarbeiten nach außen hofft man, diese aus dem Geflecht der Interessen herauszuhalten. Oder häufiger noch: Betriebliche Akteure zogen externe Expertisen heran, um die eigene Position zu stärken, um mögliche Widerstände zu umgehen oder auszuhebeln.

Eng verknüpft mit der Rolle des Change Agents war auch eine Aufgabe, die man als Blitzableiterfunktion bezeichnen könnte: die Verlagerung der Verantwortung für mögliche Risiken nach außen.

Gerade das hohe Maß an Unsicherheit, mit dem viele Software-Entwicklungsvorhaben belastet sind, legte eine solche Delegation der Verantwortung nach außen nahe. Hat man wirklich auf das richtige Pferd gesetzt, als man sich für Unix entschied, wird sich Oracle als langfristig geeignete Entwicklungsumgebung erweisen etc.?

Die Beantwortung dieser Fragen war für die betrieblichen Akteure nicht nur schwierig, sondern unter Umständen mit einem erheblichen Risiko verbunden. Die Einschaltung eines externen Experten schaffte die Möglichkeit, ein solches Risiko abzuwälzen.

Schließlich spielte auch ein weiterer Aspekt eine Rolle: die Erhöhung der Steuerbarkeit und Berechenbarkeit des Projektablaufs.

Nach außen vergebene Leistungen waren bis zu einem gewissen Grad den internen Auseinandersetzungen entzogen und damit zu berechenbaren Größen geworden. jede Veränderung der Vorgaben erwies sich in der Regel als kostenrelevant, das heißt, machte eine neue Definition des Auftrags notwendig. Allein der Zwang, Arbeitspakete für die Auftragsvergabe verbindlich zu definieren und zu quantifizieren, den zeitlichen Rahmen abzustecken, in dem sie abgearbeitet werden müßten, führte zu einer deutlichen Strukturierung der Projektabwicklung. Dazu kam, daß mit der Vergabe von Aufträgen nach außen nicht nur technisches Know-how eingekauft wurde, sondern auch Erfahrungen und Kompetenz in der Abwicklung von Projekten.

In vielem schien sich also das Projekt-Management durch die Externalisierung von Leistungen zu vereinfachen. Das wurde allerdings teilweise auch mit Nachteilen erkauft: Interne Abstimmungs- und Klärungsprozesse, die die Abwicklung von Projekten belasteten und verzögerten, wurden durch die Vergabe von Entwicklungsarbeiten Abgeschnitten, nachträgliche Änderungen waren schwieriger umsetzbar - mit der Folge, daß unter Umständen Gestaltungsanforderungen, die sich als unsinnig oder unpraktikabel erwiesen, lange Zeit mitgezogen wurden. Die Kette zwischen dem Produzenten von Software und den Anwendern wurde länger, der Kontakt zwischen beiden erschwert. Es ist wohl kein Zufall, daß bei einer Reihe von Projekten die Entwicklungsarbeiten von dem externen Dienstleister zwar scheinbar problemlos und effizient durchgeführt wurden, sich dann aber bei der Implementierung der Software die Schwierigkeiten häuften.

Zwar wurde effektive Anwenderpartizipation durch die Externalisierung von Entwicklungsleistungen nicht durchweg unmöglich gemacht - wir trafen in einigen Projekten auf recht stabile Beziehungen zwischen Anwendern und externen Entwicklern -, zumeist führten jedoch die Bedingungen, unter denen diese stattfand, de facto dazu. Immer wieder war bei unseren Untersuchungen erkennbar, daß die externen Entwickler praktisch keinerlei Kontakt mit den eigentlichen Anwendern gehabt hatten. Dazu trug nicht nur die räumliche Trennung bei. Dort, wo die prozessuale und inhaltliche Planung von Projekten darauf angelegt war, die Vergabe von Leistungen nach außen zu ermöglichen, blieb meist für eine Anwenderbeteiligung wenig Raum. Der Projektablauf war von vornherein so strukturiert, daß sich feste Arbeitspakete nach außen vergeben ließen, um die man sich dann im weiteren möglichst wenig kümmern mußte. Auftraggeber des externen Dienstleisters war in der Regel nicht die Fachabteilung, also der Anwender, sondern die DV-Abteilung, über die dann auch während des Projekts die Kontakte mit diesem liefen.

Die Verlagerung organisatorischer oder betriebspolitischer Probleme nach außen dürfte tendenziell zu eher technikzentrierten Entwicklungsprozessen geführt haben, zu Software, die primär die Ziel- und Qualitätskriterien der Software-Entwickler selbst spiegelte und nicht so sehr jene der Anwender. Die betriebspolitische und die inhaltliche Dimension sind eben meist nicht ohne weiteres zu trennen. Betriebspolitische Auseinandersetzungen haben immer ihre inhaltliche Komponente.

Mit der Vergabe von Entwicklungsaufgaben nach außen, so läßt sich zusammenfassend feststellen, eröffnet sich zusätzlicher Spielraum bei der Abwicklung von Softwareprojekten. Sie kann einen deutlichen Gewinn an Kompetenz und Effizienz beinhalten, sie birgt aber auch die Gefahr eines Regelungsvakuums. Zwar werden die" manifesten, technikbezogenen Leistungen des externen Kontraktors genau definiert. Undefiniert bleiben die unter Umständen ebenso wichtigen nichttechnischen Leistungen oder Funktionen, die vom externen Kontraktor übernommen werden beziehungsweise ihm zuwachsen. Mit der technischen Entwicklung ist meist auch die Lösung betriebspolitischer oder organisatorischer Probleme verknüpft. Wo versucht wird, mit der Vergabe von Entwicklungsarbeiten auch die Lösung dieser Probleme nach außen zu verlagern kann dies leicht zu Lösungen führen, die zwar funktionsfähig sein mögen, bei ihrer Anwendung aber auf Schwierigkeiten stoßen. Die Lösung betrieblicher Probleme kann nicht delegiert werden, der externe Dienstleister kann hier nur unterstützen. (wird fortgesetzt)