Fallbeispiel: Doppelexperte

04.09.1992

Das Unternehmen ist ein wissenschaftliches Institut mit etwa 200 Mitarbeitern, das sich durch Projekte, die einzelnen Teileinheiten zugeordnet werden, finanziert. Diese Teileinheiten können ganze Abteilungen sein, häufig sind es aber nur, einzelne Gruppen in den Abteilungen.

Das Institut arbeitet hauptsächlich mit den Methoden der qualitativen Sozialforschung. Der neue Leiter sowie einzelne Abteilungsleiter wollen verstärkt auch quantitative Methoden und Verfahren zum Einsatz kommen lassen. Bislang beschränkt sich der Technikeinsatz im wissenschaftlichen Bereich auf wenige PCs und auf ein nur von Spezialisten genutztes Bibliotheks- und Literatur-Dokumentationssystem. Im Rahmen eines sechsjährigen Großprojekts wird ein Subprojekt definiert: der Aufbau eines Informationssystems.

Da entsprechend qualifiziertes Personal fehlt, erhält ein Wissenschaftler, der als Methodenspezialist an einem Hochschulinstitut arbeitet, das Angebot, bei verbesserten Bezügen ins Institut zu wechseln, in der Hoffnung, daß er ein Konzept für das Informationsverarbeitungs-System entwickeln und in die Praxis umsetzen könne. "Entwerfen Sie für uns ein modernes Informationsverarbeitungs-System und setzen Sie dieses Konzept um." Daraus ist zu schließen, daß es für das einzurichtende Informationssystem im Institut kein Konzept, keine Vorgaben gibt, man vertraut auf das Wissen des eingestellten Projektleiters.

Nach einer kurzen Einarbeitung formuliert der Projektleiter das Ziel des Vorhabens: Das zu entwickelnde Informationssystem soll alle Daten, die für das sechsjährige , "Überprojekt" erhoben werden, beschreiben und ein Schlagwortverzeichnis enthalten; für die anstehenden Fragen kann sich der einzelne Wissenschaftler oder Sachbearbeiter quasi die eigene Datenbank inklusive eines Codebuchs aus den bestehenden Datensätzen erstellen; eine Schnittstelle zu einem Statistikprogramm soll die automatischen Auswertung der Daten ermöglichen. Ein weiteres Systempaket, das die Bibliotheksbestände dokumentiert und verwaltet, ist zu integrieren. Das Konzept ist ganz auf eine eigenständige Nutzung durch die Wissenschaftler angelegt.

Das Projekt wird zwar nicht nach einem Phasenschema geplant, im Projektablauf lassen sich jedoch drei Phasen ausmachen: Konzeptualisierung, Aufbau der Entwicklergruppe und Realisierung. In der Phase eins macht sich der Projektleiter zunächst kundig über den Projektumfang, er definiert die Anforderungen in einem Systemkonzept, beginnend bei Hardware, Software, Logik des Systems bis hin zur Definition, welche Daten einbezogen werden sollen. In etwa einem Jahr erstellt der Projektleiter ein umfassendes Konzept. Dabei unterhält er sich mehrfach mit seinem Abteilungsleiter und einem weiteren Kollegen. Das Konzept entwirft und formuliert er allerdings allein.

Nach der Konzeptualisierung baut der Projektleiter die Entwicklergruppe auf. Er kann einen Mitarbeiter der Abteilung mit beschränkten DV-Erfahrungen gewinnen, daneben werden mit befristeten Kurzverträgen ein Wissenschaftler und eine Studentin eingestellt. Beide haben keine DV-Erfahrungen.

Die drei Novizen erhalten in 14 Tagen von dem Projektleiter eine Einführung in die Software-Entwicklungssprachen der vierten Generation: Zunächst wird das Konzept erklärt, danach die Grundsätze der Programmierung in den Sprachen der vierten Generation dargestellt, anschließend beginnt unter Anleitung die "Entwicklung".

Jede Woche Rückmeldungen an den Projektleiter

Es folgt in Phase drei die Realisierung des Konzepts in einem kleinteiligen Prozeß mit 16 Schritten: Der Projektleiter vergibt Aufgaben an die Teammitglieder für die folgende Woche. Diese haben zunächst zu prüfen, was sie "können", um dann den Projektleiter zu Rate zu ziehen; erst dann beginnt die Ausführung, wobei jeder aufgefordert ist, bei Unklarheiten direkt den Projektleiter zu konsultieren. Dieses Wochenprogramm heißt für den Projektleiter wie für die Teammitglieder, sich neben der Auftragserfüllung quasi als Nebenprodukt über die Leistungsfähigkeit jedes einzeln zu orientieren.

Der Projektleiter erhält jede Woche Rückmeldungen über den Stand der Qualifikation und über den Stand der Realisierung seines Konzepts. Indem er die Einzelprodukte der Teammitglieder austestet, erfährt er, ob die einzelnen Teilschritte anforderungsgerecht und konsistent ausgeführt wurden. Die kurzen Zeitabschnitte lassen eine laufende Prozeßsteuerung zu. Das Produkt erfährt dabei eine schrittweise Weiterentwicklung, die Komplexität des Systems und auch des Prozesses wächst; während die wöchentlichen Arbeitsprodukte zusammengesetzt werden, nimmt das Informationssystem zunehmend Gestalt an.

Keine Sprachen der dritten Generation mehr

In diesem Entwicklungsprozeß sind andere Mitarbeiter den Instituts bewußt ausgeschlossen, den Projektleiter schottet während dieser Zeit ein Teammitglied völlig ab, er ist nicht einmal telephonisch erreichbar. Diese Ausgrenzung führt dazu, daß es während des Entwicklungsprozesses zu keinen Interessenskonflikten mit anderen Stellen und Abteilungen im Institut kommt. Die reinen Programmierarbeiten können in vier Monaten durchgezogen werden.

Voraussetzungen für diese kurze Programmierzeit sind nach Ansicht des Projektleiters:

- das widerspruchsfreie theoretische Design,

- das Entwickeln "auf der grünen Wiese" - es gab vorher keine Datenverarbeitung, also auch keine Restriktionen bei der Wahl der Soft- und Hardware,

- der konsequente Einsatz von hochwertigen Tools.

Nur Oracle-Werkzeuge und das Betriebssystem kommen zu Einsatz, mit Pascal oder Fortran wären mehr als drei bis vier Jahre für die Entwicklung notwendig gewesen. Es wird fast nichts mehr in den Sprachen der dritten Generation programmiert, "Do"-Schleifen gehören der Vergangenheit an. Die Funktionen setzen sich aus vorgefertigen Tools und Instrumenten zusammen. Damit sei man wesentlich schneller und effektiver, die Entwicklungszeiten verkürzten sich. Die verfahren seien allerdings langsamer, was bei der nun verfügbaren Rechnerleistung nicht mehr so sehr ins Gewicht falle.

Vollzogen sich die Konzeption und vor allem die Realisierung Informationssystems sehr zügig, so gestaltet sich dessen, Einführung allerdings eher zögerlich. Ein Jahr nach Inbetriebnahme wird das System nur von wenigen Wissenschaftlern genutzt.

Das Projekt, ist Gekennzeichnet durch die offensichtlich sehr effiziente Projektabwicklung einerseits, andererseits fällt die recht begrenzte Nutzung des Systems durch die Anwender auf. Beides verweist auf die Schlüsselrolle des Projektleiters und die Form, in der er das Projekt gestaltet.

Der Projektleiter nimmt eine doppelte Expertenrolle wahr als Entwickler und Anwender. Weil er auf langjährige Erfahrungen mit Methoden zurückgreifen kann, glaubt er zu wissen, was ein Informationsverarbeitungssystem zu leisten habe und wie es aufgebaut sein müsse. Durch sein Studium der Soziologie meint er abschätzen zu können, was seine Kollegen für ihre Arbeit brauchen.

Fehleinschätzungen der Anwendungsbedingungen

Diese Doppelrolle erleichtert zweifelsohne die Erarbeitung eines geschlossenen Konzepts und dessen rasche Realisierung wie auch die Wahrnehmung der Leitungsfunktion im Projekt. Dadurch gelingt es, das Projektteam trotz geringer beruflicher Vorerfahrungen zugig in die Entwicklungsarbeiten einzubinden. Die Rolle als Leiter wird durch die Bedingungen, unter denen das Projekt Abgewickelt wird, nahegelegt, nämlich durch die mangelnden DV-Erfahrungen der Institutsleitung wie auch der Anwender. Zugleich ist es jedoch gerade diese Ausgangskonstellation, die die Rolle des Doppelexperten gefährlich macht: Sie verführt den Projektleiter zu einer Fehleinschätzung der Anwendungsbedingungen des Systems. Er unterschätzt sowohl die Bedeutung der qualifikatorischen Voraussetzungen wie der bestehenden Arbeitsstrukturen und -verfahren.

Das System ist ausgelegt auf eine eigenständige Nutzung durch die Anwender. Dies erfordert sowohl die vollständige Beherrschung des Leistungsangebots des Systems als auch die Bereitschaft und Fähigkeit, das System zur Bewältigung der gestellten Aufgaben auch einzusetzen. Diese Voraussetzungen sind jedoch nicht erfüllt.

Schulung kontra Defizit nicht ausgleichen

Die Bereitschaft der Anwender, sich auf das System einzulassen, mit dem sie mehr oder minder von einem Tag auf den anderen konfrontiert werden, ist gering. Der Entstehungsprozeß hat die Vorbehalte, die man gegen die Technik hat, bestärkt. Zudem sind teilweise tiefgreifende Umstellungen des bisherigen Arbeitsverhaltens erforderlich.

Die Nutzung des Systems zu Dokumentationszwecken macht nur Sinn, wenn anfallende Daten kontinuierlich und in einer Art eingegeben werden, daß auch Kollegen mit ihnen umgehen können. Abgesehen davon, daß dies neue, ungewohnte Anforderungen stellt, verführt die Konkurrenzsituation am Institut dazu, die Daten so allgemein und unspezifiziert wie möglich zu dokumentieren.

Auch erweist sich das System als zu komplex: Besonders ungeübte oder sporadische Anwender verlieren während der Anwendung den Überblick, kommen nur mit einem kleinen Teil der angebotenen Funktionen zurecht. Deshalb wird die Bedienungsanleitung von 450 auf 50 Seiten reduziert. Die angebotene Schulung vermag dieses Defizit bei den Anwendern nicht auszugleichen, im Gegenteil: Sie verstärkt eher noch das Gefühl der Überforderung der Anwender.

Die zügige Entwicklung sowie die begrenzte Nutzung des Systems stellen sich als durchaus komplementäre Seiten dieser Form der Projektabwicklung dar. Die Stärken des Doppelexperten sind zugleich seine Schwächen.