Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Projekt-Management in der Praxis (Teil 17)


11.09.1992 - 

Stille Leistungen: Von großer Bedeutung und schwer meßbar

Neben offiziellen Tätigkeiten erbringen Entwickler vielfach "stille" Leistungen. Sie sind für Projekte und die Qualität der Software von größter Bedeutung, allerdings nur schwer zu fassen und kaum vorzuschreiben.

Welche Leistungen im Rahmen von Software-Entwicklung erbracht werden, scheint durch die einzelnen Arbeitsschritte fest umrissen: Anforderungsspezifikation (Pflichtenheft), Umsetzung in ein Datenmodell, Realisierung in einem lauffähigen Programm, Überprüfung im Test. Zwar besteht inzwischen weitgehend Übereinstimmung, daß die am besten quantifizierbaren Maßstäbe, etwa die Lines of Code, nur unzureichende- Leistungskriterien liefern; schon weil durch sie nur ein-zunehmend kleinerer-Ausschnitt der Entwicklungsarbeiten erfaßt wird. Das Bild vom Arbeitsprozeß "Software-Entwicklung" wird jedoch nach wie vor vorwiegend von jenen Leistungen geprägt, die ausdrücklich ausgewiesen und dokumentiert sind.

Nun waren in den untersuchten Projekten diese offiziellen Leistungen nur ein Teil des Leistungsspektrums, das tatsächlich von den Software-Entwicklern und unter Umständen auch von anderen Beteiligten (Führungskräften, Anwendern) erbracht wurde. Software-Entwicklung beinhaltete in der Regel auch Leistungen, die nicht Teil des offiziellen Arbeitsprogramms waren und entsprechend in diesem weder ausgewiesen noch im Zeit- und Aufwandskalkül berücksichtigt wurden.

Solche "stillen" Leistungen waren etwa:

- Änderung, Korrektur und Ergänzung unsinniger, widersprüchlicher oder unvollständiger Vorgaben - fast in allen Projekten bestand die Notwendigkeit, die Auftraggeber bei der Definition dessen zu unterstützen, was sie benötigten oder haben wollten. Das war oft ein langwieriger und mühsamer Prozeß.

- Ausdrückliche oder implizite (Neu-) Strukturierung der Arbeitsprozesse, auf die sich diese Anforderungen bezogen-häufig genug waren die widersprüchlichen Vorgaben an die Software- Entwicklung letztlich nur Ausdruck einer ungeordneten und widersprüchlichen Arbeitspraxis. Diese mochte sich im normalen betrieblichen Alltag als durchaus funktionsfähig erweisen, der Versuch einer 1:1 Übertragung in ein Softwaresystem war meist jedoch zum Scheitern verurteilt. Ungenaue oder widersprüchliche Regelungen, die bislang in der Praxis informell "verarbeitet" wurden, treten nun stärker in den Vordergrund. "Chaotische Software spiegelt meist das Chaos im Anwenderbereich wider." Dieser Ausspruch muß weniger als Kritik an der chaotischen Arbeitspraxis als an einem Entwicklungsprozeß verstanden werden, bei dem eben jene "stille" Ordnungs- und Umsetzungsleistung fehlte.

- Herstellung eines Konsenses über eine von allen betroffenen Stellen getragene Lösung. Die Entwicklung der Software gestaltete sich in den meisten Projekten kontrovers, nicht nur zwischen Software-Entwicklern, Auftraggebern und Anwendern, sondern auch zwischen einzelnen Anwendergruppen. Hier die notwendige Übereinstimmung herbeizuführen war häufig eine zeitraubende, aufwendige Aufgabe, in die auch Softwareentwickler einbezogen waren.

- Flexibilisierung der Projektabwicklung-starre durch das offizielle Projekt-Management vorgegebene Vorgehensregelungen werden unterlaufen beziehungsweise den Erfordernissen des Entwicklungsprozesses angepaßt.

Viele dieser "stillen" Leistungen erbrachten die Software-Entwickler für den Anwender, entweder stellvertretend für ihn oder in Kooperation mit ihm. Die Entwickler ihrerseits waren ebenfalls auf "stille" Leistungen der Anwender angewiesen, nicht nur bei der Definition der Anforderungen, sondern auch bei der Entwicklung des technischen Konzepts oder bei der Anpassung der Software an die konkreten Einsatz- und Anwendungsbedingungen. Besonders das Prototyping lebt nicht zuletzt von "stillen" Leistungen, die von Anwendern eingebracht werden.

Zwischen der Funktion und der Wirksamkeit der "stillen" Leistungen und jener des kontextuellen Wissens (siehe CW Nr.36 vom 4. September 1992, Teil 16 dieser Serie), besteht Parallelität und auch ein enger Bezug. Der Beitrag "stiller" Leistungen beruht nicht zuletzt darin, daß kontextuelles Wissen verwertet wird; dieses Wissen stellt meist eine wesentliche, Grundlage für solche Leistungen dar. Wie diese "stillen" Leistungen ist kontextuelles Wissen - unsere Beispiele zeigen dies-immer besonders der Gefahr ausgesetzt, nicht berücksichtigt oder verdrängt zu werden und so folgenlos zu bleiben.

"Von Anfang an ein ungutes Gefühl"

Diesen Verdrängungsmechanismus schilderte uns der Leiter eines Projekts, dessen Zeit- und Budgetrahmen beträchtlich überzogen wurde, sehr anschaulich: "Im Grunde hatte ich bei dem Projekt von Anfang an ein ungutes Gefühl. Im Hinterkopf wußte ich eigentlich, daß das nicht gut gehen konnte, daß die Vorgaben, die wir erhielten nicht zu halten war. Aber ich hatte das verdrängt. Die Geschäftsleitung hat gesagt: ,Wir brauchen das unbedingt zu diesem Termin' und ,Sie schaffen das schon', und dann haben wir das eben gemacht. Heute würde ich mich nicht mehr auf so etwas einlassen, da würde ich lieber auf das Projekt verzichten."

Selbstverständlich ist jeder Produktionsprozeß und insbesondere jeder Entwicklungsprozeß auf solche "stillen" Leistungen angewiesen, die in keiner offiziellen Verfahrens- oder Arbeitsplatzbeschreibung, in keinem Ablaufplan ausgewiesen sind. In der Software-Entwicklung dürfte ihnen jedoch eine besonders große Rolle zukommen-für die Qualität des Endprodukts, insbesondere für seine nutzungsgerechte Gestaltung, für die Intensität seiner Nutzung wie unter Umständen für das Zustandekommen einer Lösung überhaupt.

Dies hängt mit dem besonderen Charakter von Software und den besonderen Anforderungen, die sich daraus ergeben, zusammen. Die Abstraktheit des, Gestaltungsgegenstands macht,

wie wir zeigten, Übersetzungsleistungen der Software-Entwickler erforderlich. Der Umstand, daß Software-Entwicklung immer zugleich Arbeitsstrukturierung ist, das heißt in die Arbeit der Anwender unter Umständen sehr radikal eingreift, macht umgekehrt Übersetzungsleistungen der Anwender erforderlich und weist zugleich der Konsensbildung große Bedeutung zu.

Deshalb ergab sich die Notwendigkeit zu "stillen" Leistungen vor allem dort, wo Software-Entwickler wie Anwender bei der Umsetzung der Bedingungen und Anforderungen der Arbeitsprozesse in die Anforderungen und die Logik des Computersystems als Vorlage für die Gestaltung des Softwareprodukts Schwierigkeiten hatten. Beide waren auf "Übersetzungsleistungen" der anderen Seite angewiesen, auf sprachlicher, begrifflicher wie konzeptioneller Ebene.

Die Bewältigung der besonderen technischen und prozessualen Komplexität von Software-Entwicklungsaufgaben ist also nicht zuletzt auf stille" Leistungen angewiesen. Der Bedarf an

diesen Leistungen steigt, je übergreifender, unstrukturierter und je innovativer die Entwicklung aufgebaut sowie die Aufgabenstellung und Abwicklung einer Tätigkeit ist, die durch Software unterstützt werden soll. So war die Entwicklung eines Programms für die Lohnbuchhaltung weniger auf "stille" Leistungen angewiesen als die Integration dieses Teilsystems in ein umfassendes System zur Unterstützung vielfältiger administrativer Arbeitsprozesse. Historisch gesehen heißt dies, daß die Bedeutung "stiller" Leistungen in der Software-Entwicklung in den letzten Jahren, in denen es zunehmend um die Integration von Teilsystemen und die Unterstützung schwachstrukturierter Tätigkeiten ging, sehr gewachsen ist.

Zugleich hat sich auch ihr Schwerpunkt verschoben. Geht es bei der DV-Unterstützung strukturierter Arbeitsaufgaben vor allem darum, bestimmte Bearbeitungsprozeduren nachzuzeichnen und zu ordnen, so ist bei der Entwicklung aufgaben und nutzungsgerechter Software zur Unterstützung von schwachstrukturierten Tätigkeiten das Verständnis und die Berücksichtigung der Rahmenbedingungen und Anforderungen, die diese Tätigkeit bestimmen, in sehr viel stärkerem Maß eine wesentliche Voraussetzung für die Entwicklung. Schließlich kann davon ausgegangen werden, daß "Qualität", vor allem dann, wenn sie nicht nur als reine Fehlerfreiheit, sondern als Aufgaben-und Nutzungsangemessenheit verstanden wird, nicht zuletzt auch Ergebnis "stiller" Leistungen ist.

Dies heißt nun allerdings nicht, daß alle "stillen" Leistungen zu Verbesserungen der Software-Entwicklung beitragen. Wir trafen durchaus auch auf sehr dysfunktionale "stille" Leistungen-wo diese primär daran ausgerichtet waren, bestehende Machtpositionen des DV-Bereichs abzusichern. Auch solche "stille" Leistungen scheinen uns ein spezifisches Problem von Software- Entwicklungsprojekten-wir setzen uns im Zusammenhang mit der Verarbeitung von Konflikten mit ihnen auseinander.

So wichtig nun "stille" Leistungen für den Ablauf` und das Ergebnis von Software-Entwicklungsprojekten waren, so schwer fiel es, diese in den Griff zu bekommen, also planbar und steuerbar zu machen. Mehr als bei anderen Produktionsprozessen werfen in der Software-Entwitklung die "stillen" Leistungen Probleme für die Projektabwicklung auf, etwa für die Projektkalkulation und organisation, für die Arbeitsgestaltung und bei der Qualifizierung der Software-Entwickler.

Der Beitrag "stiller" Leistungen bei der Planung und Durchführung von Software-Entwicklungsprojekten war vielfältig, allerdings schwer nachzuweisen. Schon die Unterscheidung zwischen "stillen" und offiziellen Leistungen ist ein analytisches Konstrukt, das nur gedanklich nachvollzogen werden, kaum aber Gegenstand der Leistungskontierung sein kann.

In dieser Schwierigkeit, "stiller" Leistungen eindeutig zu definieren, liegt bereits ein Teil des Problems: Sie sind schwer faßbar und somit schwer zu organisieren und zu kalkulieren. Sie entziehen sich einer stringenten Vorausplanung ebenso wie einer festen Aufwandsschätzung und passen damit nicht in das Bezugssystem perfekt geplanter Projekte. Wer kann etwa zu Beginn eines Projekts den Zeitaufwand festlegen, der zur Konsensbildung erforderlich sein wird?

Umfang und Bedeutung variieren sehr stark

Entsprechend konnten wir auch in unseren Recherchen den Anteil "stiller" Leistungen an der Gesamtarbeitszeit nicht erfassen oder auch nur schätzen lassen. Schon ihre Eingrenzung erwies sich als schwierig. Am ehesten war dies bei Kosten- und Teminüberschreitungen-wenn auch nur im Rückblick-möglich. So konnten in einigen Projekten der Zeitaufwand beziehungsweise die Verzögerungen, die durch langwierige und aufwendige Konsensherstellung verursacht wurden, geschätzt werden; die Größenordnungen waren beachtlich.

In einem Projekt, dessen Laufzeit ursprünglich auf zwei Jahre angesetzt worden war und das dann nach dreieinhalb Jahren abgeschlossen wurde, gingen diese Verzögerungen vor allem auf das Konto Anforderungsspezifikation. Diese Phase habe allein, statt wie veranschlagt wenige Monate, fast eineinhalb Jahre gedauert. Im weiteren sei man dann im wesentlichen im Zeitplan geblieben.

Solche Überlegungen allerdings wurden nur sehr global und durch unsere Untersuchung veranlaßt und vorgenommen. In keinem Projekt waren sie schon zuvor Gegenstand offizieller Schätzung gewesen. Es gab jedoch eine Reihe von Anhaltspunkten, die darauf hindeuteten, daß der Umfang und die Bedeutung dieser "stillen" Leistungen von Projekt zu Projekt sehr unterschiedlich war.

Das zunächst schwer erklärbare vollständige oder teilweise Scheitern einiger offensichtlich sorgfältig geplanter und organisierter Projekte, die wir untersuchten, dürfte nicht zuletzt darauf zurückzuführen sein, daß gerade die perfekte Organisation des Entwicklungsprozesses wenig Raum für "stille" Leistungen ließ.

Umgekehrt war in erfolgreichen Projekten zu erkennen, daß Spielraum und Kapazität für "stille" Leistungen existierte meist wohl weniger als Ergebnis expliziter Planung als vielmehr wegen günstigen Umständen oder besonderen persönlichen Leistungen.

Schwer nachweisbar waren vor allem Umfang und Auswirkungen "stiller" Leistungen, die sich in qualitativen Verbesserungen des Software-Entwicklungsprozesses und seiner Ergebnisse niederschlagen. Am ehesten schien ihre Bedeutung dort durch, wo sie fehlten: bei Konflikten, die nicht ausgetragen wurden und zu schlechten Kompromißlösungen führten, bei Technik, die nicht genutzt wurde, bei Programmen, die zwar fehlerfrei liefen, aber die erwarteten Leistungen nicht erbrachten, weil sie am Bedarf der Anwender und den Anwendungsbedingungen vorbeientwickelt worden waren.

Der Umstand, daß ihre Bedeutung so schwer positiv nachzuweisen war, dürfte dazu beigetragen haben, daß die "stillen" Leistungen bei der Planung und dem Management von Software-Entwicklungsprojekten häufig vernachlässigt und eigentlich nicht als "Leistung" gehandelt wurden. Auch unter Qualifizierungsaspekten erweist sich dieser Zusammenhang als relevant: "Stille" Leistungen erfordern bestimmte Qualifikationen, deren Vermittlung jedoch im betrieblichen Kontext meist unbeachtet bleibt, eben weil sie sich auf nicht offiziell vorgegebene Aufgabenpakete beziehen.

Fassen wir zusammen: "Stille", nicht offiziell ausgewiesene und an den Ergebnissen einzelner Projektphasen unmittelbar ablesbare Leistungen sind in vielen Projekten eine notwendige Erfolgsvoraussetzung. Wie nutzungsgerecht eine Software ist und wie intensiv sie genutzt wird, hängt vielfach nicht zuletzt von den "stillen" Leistungen ab. Zugleich bestehen besondere Schwierigkeiten, "stille" Leistungen so zu mobilisieren, daß sie zu qualitativen Verbesserungen der Software-Entwicklung führen. "Stille" Leistungen sind nicht nur schwer kalkulierbar, sie sind auch schwer vorzuschreiben. Dies würde eine Redefinition derAufgabenstellung von Software-Entwicklung voraussetzen. Der organisatorische Rahmen vieler Projekte ist für "stille" Leistungen kaum förderlich. Dies führt zu der Frage: Wie können Voraussetzungen geschaffen werden, daß in Software-Entwicklungsprozessen "stille" Leistungen eingebracht und zum Tragen kommen können? Nicht zuletzt geht es dabei darum, "stille" Leistungen "hörbar" zu machen, so daß sie als legitime, notwendige Leistungen ausgewiesen werden können beziehungsweise ihr Fehlen als Defizit erscheint.

Damit wird schon deutlich, daß es sich hier nicht nur um ein Qualifizierungsproblem handelt. Natürlich ist auch hier Qualifizierung erforderlich, um den notwendigen Bewußtseinswandel zu unterstützen. Aber wie so oft: Qualifizierung darf nicht für sich stehen, sondern muß eingebettet sein in andere Maßnahmen.

Produktivität und Intensität als Maßstab

Anzusetzen ist bei der Aufgabendefinition: Nicht allein um die Erstellung eines technischen Systems, sondern um die Realisierung eines Arbeitssystems geht es, in dem die Technik den Menschen bei der Bewältigung einer Aufgabe unterstützt. Anzusetzen ist an den Kriterien, an denen der Erfolg einer Software-Entwicklung gemessen wird: Nicht das fehlerfreie, perfekte System, sondern die Intensität und Produktivität der Nutzung müssen Maßstab sein. (wird fortgesetzt)

Professor Friedrich Weltz ist Geschäftsführer der Sozialwissenschaftlichen Projektgruppe, München, und Honorar-professor an der Universität Göttingen; Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe, München.