Viele DV-Vorhaben werden ohne offiziellen "Segen" gestartet. Das gilt auch für drei der in dieser Serie behandelten Projekte: Dem formalen Projektauftrag ging damit jeweils eine Phase voraus, in der bereits wesentliche Vorarbeiten geleistet und damit unter der Hand Fakten geschaffen wurden, die den weiteren Ablauf bestimmten.

Besondere Aufmerksamkeit erfordern Entwicklungsvorhaben, die ihre Existenz einem Entstehungsprozeß verdanken, den man in den USA "Bootlegging", in Deutschland "U-Boot-Verfahren" nennt, das heißt subversive Initiativen und Aktivitäten ohne offiziellen Auftrag, teilweise unter Umgehung oder Nichtachtung betrieblicher Vorschriften und Regelungen. Dabei ist, das hat die Untersuchung ergeben, die Abgrenzung zu "autorisierten" Projekten fließend - auch deren Anfänge verweisen fast durchweg auf informelle Initiativen und Aktivitäten.

Der Unterschied liegt darin, daß sie darauf hinzielten, möglichst rasch einen offiziellen Projektauftrag zu erreichen, während es bei subversiver Projekteinleitung das Bestreben war, möglichst lange ohne offiziellen "Segen" auszukommen. Immerhin bei etwa einem Zehntel der von uns untersuchten Projekte war dies ziemlich eindeutig der Fall, bei einem weiteren Fünftel ging dem offiziellen Projektbeginn eine längere Phase informeller Aktivitäten voraus. Deren Dauer und Umfang waren zum Teil beachtlich: von mehreren Monaten bis zu über einem Jahr.

In einigen Projekten stützten sich die subversiven Entwicklungsaktivitäten auf schon bestehende und dann fortgeführte Kontakte mit Anwendern. Häufig allerdings war eine subversive Projekteinleitung durch den Entwicklungsbereich nicht zuletzt durch das Bestreben bestimmt, möglichst ohne als lästig empfundene Abstimmung mit den Anwendern vorgehen zu können.

Subversiven Projektgeschichten begegneten wir typischerweise bei Eigenentwicklungen in Anwenderunternehmen. Bei Projekten für externe Kunden gab es zwar informelle Kontakte und Vorgespräche, sobald aber in stärkerem Maße kostenrelevante Aktivitäten anfielen, wurden diese auch rasch offiziell ausgewiesen und zugeordnet. Nun bezogen sich solche Projekte überwiegend nur auf einen Teil des gesamten Entwicklungsprozesses, die frühen Phasen der Projektentstehung waren typischerweise noch nicht Gegenstand des Auftrags.

Welche Konsequenzen hatte solch subversive Projekteinleitung auf den weiteren Projektverlauf und dessen Ergebnis? Der Soziologe Hoffmann, der "Bootlegging-Innovationen" in Industrieunternehmen untersuchte, vertritt die These, daß diese überdurchschnittlich erfolgreich seien, und führt dies darauf zurück, daß gezwungenermaßen höchst ökonomisch und effizient mit den Ressourcen des Unternehmens umgegangen wird. Er bringt dies auf die Formel "Bootlegging Innovations: Ersparnis von Zeit, Geld und Ärger". Er sieht im Bootlegging den "Ausdruck eines lebendigen Immunsystems gegen bürokratische Verkrustungen, innovationsfeindliche Hierarchien und vergeblich unpolitische Entscheidungsprozesse".

Auch für die Entwicklung von Software scheint dies zu gelten. So waren in den von uns untersuchten Projekten die Entwickler überwiegend der Meinung, daß sich das subversive Vorgehen günstig ausgewirkt habe. Vor allem die Ausschaltung hierarchischer Restriktionen wurde dabei als Vorteil betrachtet. Die Freiräume, die bei solchen Entwicklungstätigkeiten bestanden, wurden als angenehm erfahren. Ohne Beeinträchtigung durch Anforderungen "unkundiger Anwender", ohne Ablenkung durch "störende Abstimmungsgespräche" konnte man sich ganz der "eigentlichen" Entwicklungsaufgabe widmen. Dies trug dazu bei, daß Mehrbelastungen - zumindest in der ersten Entwicklungsphase - in Kauf genommen wurden.

Diese waren allerdings zum. Teil beträchtlich. Die Entwicklungsarbeiten mußten meist neben der offiziell ausgewiesenen Tätigkeit ausgeführt werden. Viele Entwickler klagten über die Doppelbelastung, die die Durchführung der Entwicklungsarbeiten neben dem "Tagesgeschäft" mit sich bringe, beides habe darunter gelitten. Die Entwicklungsarbeiten mußten unter der Hand, neben regulären Tätigkeiten, ausgeführt beziehungsweise auf andere Projekte oder Wartungsarbeiten kontiert werden. Auch konnten die notwendigerweise anfallenden Überstunden nicht verrechnet werden, da die Tätigkeiten ja nicht offiziell ausgewiesen waren.

Nicht nur für die Entwickler, auch für das Projekt konnte ein subversiver Beginn später zur Hypothek werden, die den weiteren Verlauf erschwerte etwa dort, wo er dazu diente, Abstimmungen mit den Anwendern zu umgehen. Diese mußten dann nach dem "Auftauchen" nachgeholt werden, nun allerdings unter Umständen unter eingeschränkten Gestaltungsmöglichkeiten.

Fachbereiche lehnen offizielles Projekt ab

In einem Dienstleistungsunternehmen hatte ein Entwickler in der DV-Abteilung die Idee für ein Entwicklungsprojekt, in dem bestehende Insellösungen

durch ein integriertes System abgelöst werden sollten. Der Gedanke entstand im wesentlichen aus den wachsenden Schwierigkeiten, die bestehenden Systeme zu warten und weiterzuentwickeln. Nachdem im DV-Bereich bereits beträchtliche Vorarbeiten geleistet worden waren, erfolgte der Auftrag der Geschäftsleitung, der prompt den Widerstand betroffener Fachbereiche aktivierte und den weiteren Projektablauf wesentlich belastete.

Nach dem "Auftauchen" des Projektes war Ärger mit übergeordneten Stellen zu gewärtigen, darüber hinaus Schwierigkeiten, den angelaufenen Aufwand nachträglich zu legitimieren, und Widerstände, etwa bei den betroffenen Anwendern. Was also machte "Bootlegging" trotzdem bei Softwareprojekten attraktiv? Warum kam es zu solch subversiven Projektvorphasen, die doch mit einer Reihe von Risiken und Belastungen verbunden waren?

Die Antwort war in den meisten Fällen recht einfach: Der subversive Projektbeginn war der schnellste und bisweilen auch am meisten Erfolg versprechende Weg, das Projekt in Gang zu bringen. Bei offiziellen Projekten, so die Erfahrung der Beteiligten, will jeder Vorgesetzte, auf DV-Seite wie auf Anwenderseite, mitsprechen, auch wenn er keine Ahnung hat, was der Anwender eigentlich will und braucht. Die Ideen und Vorschläge der Anwender kommen so gar nicht zum Tragen.

Dabei wurden die möglichen Risiken subversiver Projekteinleitung vergleichsweise gering eingeschätzt. "Es geht darum, Fakten zu schaffen, um der fehlenden Macht in der Organisation durch die Macht des Faktischen zu begegnen", so oder ähnlich heißt es oftmals. Dies sieht Hoffmann als einen Anreiz für subversives Vorgehen, wobei dann solche Möglichkeiten, vollendete Tatsachen zu schaffen, ihrerseits Macht etablieren.

Dieser Zusammenhang hat schon in der Vergangenheit mit zu der Durchsetzungsfähigkeit und den Freiräumen beigetragen, die sich der DV-Bereich in vielen Unternehmen schaffen konnte. Er wurde gefördert durch die mangelnden DV-Kenntnisse des Top-Managements in Geschäftsleitung und Fachbereichen, durch die Kultivierung der Datenverarbeitung als Geheimwissenschaft der DV-Abteilungen. Er wurde erleichtert durch den raschen technischen Wandel und den damit verbundenen Aufwand, jeweils auf dem laufenden zu sein. All dies dürfte die Möglichkeiten, subversive Aktivitäten im DV-Bereich unter Kontrolle zu halten, in vielen Unternehmen erschwert haben. In keinem der untersuchten Projekte kam es zu Sanktionen; es wurde auch nicht mit solchen gerechnet. Subversive Projekteinleitung war also nicht notwendigerweise ein Zeichen fehlender Macht, sie konnte auch das Vertrauen in die eigene Durchsetzungsfähigkeit spiegeln, zugleich aber auch das Desinteresse an einer frühzeitigen Abstimmung mit den späteren Anwendern.

Ein Softwareprojekt zum Beispiel wurde weitgehend subversiv, das heißt ohne offiziellen Auftrag durch die Geschäftsleitung beziehungsweise durch einen Geschäftsbereich vorangetrieben, die Bestimmung seines Volumens erfolgte erst relativ spät, nachdem wesentliche inhaltliche Weichen de facto bereits gestellt worden waren. Damit schien die terminliche wie inhaltliche Bestimmung des Projekts weitgehend vorgegeben. Die starke Stellung der DV-Abteilung, die ein solches Vorgehen ermöglicht hatte, wurde damit noch untermauert.

Insgesamt stellt sich das, Potential informeller, subversiver Projekteinleitungen widersprüchlich dar: Einerseits können sie ein sehr effektiver Weg zu einem Abgleich der Anwenderwünsche mit den technischen Möglichkeiten sein; andererseits beinhalten sie die Gefahr einer weitgehend unkontrollierten Verselbständigung der technischen Gestaltungsperspektiven. Im einen Fall bedeuten die informellen Aktivitäten im Vorfeld ein von Rechtfertigungszwängen und raschen Festlegungen zunächst entlastetes Herantasten an die gegebene Problemstellung im Vorfeld des eigentlichen Entwicklungsprojektes, im anderen Fall die Abschirmung von möglichen Außeneinflüssen.

Die Lösung dieses Wider Spruchs kann nicht in einer Beschneidung der Freiräume im informellen Vorfeld liegen, etwa - wie in Projektmanagement-Handbüchern zu finden - durch differenzierte Regeln darüber, wie ein Projekt zu initiieren sei. Informelle Aktivitäten können eine notwendige Voraussetzung für einen problemgerechten Einstieg in ein Entwicklungsprojekt sein. Das Ziel muß es sein, den informellen Initiativen und Aktivitäten schrittweise offiziellen Status zu verleihen. Dies ist nicht zuletzt, so wurde immer wieder erkennbar, eine Frage unvermittelter und kontinuierlicher Kontakte zwischen verschiedenen hierarchischen Ebenen, etwa zwischen Anwendern und Entwicklern. Es gilt, die Grundlage für solche Kontakte zu schaffen.

Der DV-Bereich eines untersuchten Dienstleistungs-Unternehmens ist in die Abteilungen DV-Anwendungsentwicklung und Benutzerservice gegliedert. Die Aufgaben des Benutzerservice bestehen darin, die Anwender zu schulen und spezifische Software-Anwendungen für die firmeninterne Anwendungsabteilung zu entwickeln. Drei Mitarbeiter sind für solche Entwicklungsaufgaben und einer für den reinen Benutzerservice zuständig.

Anlaß für das Projekt zur Entwicklung eines Vertriebs-Informationssystems war die Unzufriedenheit des Vertriebs mit der bestehenden DV-Unterstützung. Vom Vertrieb wird dann auch zunächst bei der Abteilung DV-Anwendungsentwicklung ein Fremdprodukt beantragt. Nachdem von dieser Abteilung, die grundsätzlich für Neuentwicklungen und damit auch für die Anschaffung von Fremdprodukten zuständig ist, der Antrag abgelehnt wird, entsteht in Kooperation zwischen Anwendern und den Mitarbeitern des Benutzerservice der Plan einer Eigenentwicklung, der dann von beiden Abteilungsleitern aufgegriffen wird.

Bewertung erst nach längerer Pilotphase

Es wird ein Team aus zwei Mitarbeitern des Benutzerservice und zwei zukünftigen Anwendern gebildet. Dieses erarbeitet zunächst eine relativ grobe Anforderungsdefinition; ein Pflichtenheft mit einer genaueren schriftlichen Fixierung der Anforderungen an das System wird allerdings nicht erstellt. Man beginnt sehr rasch mit der Entwicklung eines installationsfähigen Programms, wobei Mitarbeiter aus dem Benutzerservice und Anwender ans dem Vertrieb sehr eng und kontinuierlich zusammenarbeiten. Schon früh werden einzelne Programm-Module von Anwendern erprobt. Nach Fertigstellung des Gesamtprogramms wird dieses in einem Teilbereich des Vertriebs eingesetzt und nach einer mehrwöchigen Piloterprobung von den Anwendern bewertet.

Erst nach einer positiven Stellungnahme der Pilotanwender wird gegenüber der Geschäftsleitung und der Anwendungsentwicklung das Vorhaben formal definiert. Bis zu diesem Zeitpunkt erfolgen die Entwicklungsarbeiten praktisch im Untergrund. Dem DV-Bereichsleiter ist zwar bekannt, daß vom Benutzerservice an einem neuen System gearbeitet wird, aber den genauen Stand kennt er nicht. Das hat unter anderem zur Folge, daß die Mitarbeiter des Benutzerservice nicht für die Entwicklungsaufgaben freigestellt sind. Diese müssen neben den offiziellen Aufgaben erledigt werden. Die offizielle Absegnung des Projekts durch die Geschäftsleitung und die Leitung des Vertriebs ist dann die Voraussetzung für die Einführung des Systems in weiteren Fachabteilungen, nunmehr mit offiziellem Projektstatus.

Die mehr als einjährige subversive Vorphase, in der die Entwicklungsarbeiten ohne offiziellen Projektstatus neben den sonst routinemäßig anfallenden Arbeiten ausgeführt werden, führt zu zusätzlichen Belastungen und erheblichem Zeitdruck bei den Entwicklern im Benutzerservice. Sie birgt das Risiko, daß die Weiterführung des Vorhabens nach dem Auftauchen von der Geschäftsleitung nicht genehmigt wird.

Daß diese Nachteile in Kauf genommen werden, erklärt sich im Beispielfall unter anderem aus der Konkurrenzsituation zwischen der Anwendungsentwicklung und dem Benutzerservice. Letzterer versucht seit längerem, über die reine Nutzerbetreuung hinaus in die Entwicklung anwendungsorientierter Systeme vorzustoßen, was auf den Widerstand der Entwicklungsabteilung stößt. Durch das subversive Vorgehen unterläuft man diese Eingrenzung, indem man vollendete Tatsachen schafft. Die Koalition mit den Anwendern stärkt dabei die Position des Benutzerservice, erfordert aber auch eine enge Kooperation mit diesen und ein Eingehen auf deren Wünsche.

Die Abgrenzungsschwierigkeiten zwischen der Entwicklungsabteilung und dem Verantwortungsbereich des Benutzerservice scheinen symptomatisch für die gegenwärtige Situation in vielen Unternehmen, in denen zunehmend neben der zentralen Datenverarbeitung auf Mainframes Informationstechnik eingesetzt wird.

Für diese neuen IT-Konzepte erscheint vielen die klassische Vorgehensweise der Anwendungsentwicklung nicht mehr adäquat. (wird fortgesetzt)