Von Friedrich Weltz und Rolf G. Ortmann*
Software-Entwicklung ist meist kein abgeschlossener Akt, sondern ein fortlaufender Prozeß technischer und sozialer Gestaltung. Das organisatorische Konstrukt "Projekt" erschwert eine fortlaufende Prozeßgestaltung, wird aber wegen seiner Vorteile unter Steuerungs- und Kontrollaspekten beibehalten.
Ein Projekt ist "ein Vorhaben, das im wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, zum Beispiel Zielvorgabe, zeitliche, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation" (DIN 69 901). Es ist diese Einmaligkeit, die dem "Projekt" als Organisationsform seine besondere Wirksamkeit verleiht: die maßgeschneiderte Zuordnung und Organisation verfügbarer Ressourcen auf eine spezifische Aufgabe unter bestimmten Rahmenbedingungen. Diese Einmaligkeit, die eindeutige zeitliche Abgrenzung des Personal- und Mitteleinsatzes, beinhaltet aber zugleich eine Einschränkung in der Wirksamkeit von Projekten.
Dies gilt insbesondere in der Softwareentwicklung. Sie ist eigentlich nie ein einmaliger, abgrenzbarer Akt, der an einem bestimmten Stichtag beendet ist, sondern ein Prozeß, der mit dem Anlauf seiner produktiven Nutzung lediglich in eine neue Phase tritt. In den USA hat Rob Kling schon 1985 programmatisch "Computerization as an ongoing social and political process" bezeichnet. Er leitet den Prozeßcharakter daraus ab, daß nicht ein technisches Produkt erstellt wird, sondern Softwareentwicklung immer Teil eines umfassenden Gestaltungsansatzes ist. Kling spricht von "Computer based packages". (Kling)
Auch in der Auffassung von Softwareentwicklung als Arbeitsstrukturierung, wie wir sie eingangs darlegten, gewinnt der Prozeßcharakter an Gewicht. Softwareentwicklung wird gesehen als Doppelprozeß, in dein technische Entwicklung und Gestaltung der Anwendungen eng miteinander verzahnt sind. Ein solcher Prozeß ist per definitionem auf Dauer angelegt. Schon heute entfallen etwa zwei Drittel aller Softwarekosten auf Nachbesserungen und Änderungen vorhandener Programme (IDC Infonik). Es ist abzusehen, daß dies in Zukunft noch verstärkt gelten wird. Die zunehmende Bedeutung von Standardsoftware, Wiederverwertbarkeit, Einsatz von CASE-Tools und Repositories weisen projektübergreifenden Aspekten immer größeres Gewicht zu - etwa der Einhaltung von Standards, die unternehmensweit eingesetzt werden. Damit werden sich auch die Kriterien ändern, an denen der Erfolg eines Projekts oder genauer eines Entwicklungsansatzes gemessen wird. Neben den projektspezifischen werden projektübergreifende Kriterien an Bedeutung gewinnen.
Am Projektende eine tiefgreifende Zäsur
Auf diesem Hintergrund erscheint das "Projekt" als ein eher künstliches Konstrukt, das mehr oder minder gewaltsam einen Abschnitt aus diesem Prozeß herauslöst und ihn als Ganzes definiert. Dies wurde auch in unserer Untersuchung immer wieder deutlich. Fast alle Projekte hatten zwar formal ein mehr oder weniger klar definiertes Ende, aber zugleich war erkennbar oder abzusehen, daß die Entwicklungsarbeiten mit Projektende nicht aufhören würden. Teilweise zeichneten sich in relativ frühen Projektphasen schon Folgeaktivitäten ab, die über reine Fehlerbeseitigung und Pflegearbeiten hinauswiesen, etwa Aufnahme zusätzlicher Leistungsmerkmale oder Überarbeitung der entwickelten Software. Der Projektabschluß bedeutete also oft nur eine Fortsetzung der Entwicklungsaktivitäten unter veränderten Bedingungen: als Folgeprojekt des gleichen Teams oder als "Maintenance" in einem veränderten institutionellen und personellen Rahmen.
Trotz dieser teilweise recht konkreten, über das Projekt hinausweisenden Perspektiven bedeutete das Projektende durchweg eine tiefgreifende Zäsur. Für Projektleiter und Entwicklerteam beinhaltete es den Übergang in ein anderes Projekt und damit in eine neue Tätigkeit, mit einer neu definierten Aufgabenstellung, meist in veränderter personeller Konstellation; für die Bewertung des Projekts, soweit es eine solche gab, war es der zentrale Zeitpunkt, an dem Termin- und Budgeteinhaltung gemessen und festgestellt wurde, ob das gefertigte Produkt den Vorgaben entsprach. Mit dieser Zäsur war praktisch der Zeittakt der Entwicklung neuer Software vorgegeben. Sie stellte den zentralen Bezugspunkt für subjektive Orientierungen wie für die Abwicklung der Entwicklungsarbeiten dar.
Nur zwei der 46 Projekte, die wir untersuchten, waren "offiziell" auf Kontinuität angelegt. Nun spiegelt diese Verteilung zunächst einmal unseren Untersuchungsansatz wider - dieser war bewußt auf die Analyse von Projekten ausgerichtet, wobei wir von der Vermutung ausgingen, daß in der Regel die "eigentlichen" Entwicklungsaktivitäten in Projektform abgewickelt werden. Diese Annahme wurde durch die Recherchen, die der Auswahl der einzelnen, in die Untersuchung einbezogenen Projekt vorausgingen, bestätigt.
Beide "Dauerprojekte" hatten sich aus einem ursprünglich durchaus begrenzten Entwicklungsauftrag entwickelt. Sehr rasch wurde erkennbar, daß die entwickelte Software einer kontinuierlichen Weiterentwicklung bedurfte. Mit dieser wurde das externe Entwicklerteam beauftragt, wobei das Auftragsvolumen durch jährliche Rahmenvereinbarungen umrissen war, die allerdings nur als Orientierungsgröße dienten, die bei Bedarf mit relativ-geringem formalem Aufwand verändert werden konnten.
Natürlich kam es auch in anderen Entwicklungsvorhaben zu einer Fortführung der Entwicklungsaktivitäten. Diese waren aber institutionell eindeutig ein neuer Abschnitt, sei es, daß sie bei "internen" Projekten von einer anderen Abteilung und damit in neuer personeller Besetzung ausgeführt wurden, sei es, daß sie bei "externen" Auftragsentwicklungen als neues "Projekt" definiert wurden, wiederum mit klar abgegrenztem Auftrag, Volumen und Terminvorgaben.
Dabei war immer wieder zu erkennen, daß eine solche Regelung in mehrfacher Hinsicht unbefriedigend war: Im Projekt akkumuliertes Know-How ging für die weitere Entwicklung verloren, umgekehrt bekamen die "Erstentwickler" kein systematisches Feedback der Erfahrungen, die bei der Nutzung der entwickelten Software gemacht wurden. Die Gestaltung der Software war weniger durch die vorgegebene Entwicklungsaufgabe bestimmt als durch die Projektmodalitäten; inkrementelle Entwicklungsverfahren wurden erschwert.
Bleibt die Frage, warum angesichts dieser Defizite des Konstrukts "Projekt" doch allgemein an diesem festgehalten wurde. Die Antwort brachte einer unserer Gesprächspartner auf die einfache Formel: "Weil wir keine Alternative sehen". Es waren - ähnlich wie beim Phasenschema - die handfesten Vorteile auf der Ebene der organisatorischen Abwicklung, die die Projektkonstruktion nach wie vor attraktiv erscheinen ließen. Es gab eben den Endtermin, auf dessen Einhaltung hin die Arbeiten strukturiert wurden. Gerade angesichts der expansiven Tedenz der Softwareentwicklung erschien dieser - häufig eher willkürlich hergestellte - Termindruck dir einzige Barriere gegen ein Ausufern der Entwicklungsvorhaben.
In diesem Zusammenhang ist die gegenwärtig zu beobachtende Tendenz zu verstehen, für "externe" Auftragsprojekte Festpreise anzusetzen und umfangreiche Vorhaben in Teilprojekte aufzugliedern. Sie ist ein Versuch, zunehmend komplexe Entwicklungsvorhaben berechenbar und steuerbar zu halten, außerdem wohl eine Reaktion auf die bitteren Erfahrungen mit der expansiven Dynamik vieler DV- und Softwareentwicklungsprojekte. Zu beobachten war jedoch auch, wie in vielen Projekten der ursprünglich fixierte Festpreis sehr rasch zu einer eher fiktiven Größe wurde. Änderungen, Erweiterungen des ursprünglich vereinbarten Auftrags - häufig durch ungenaue oder irreführende Unterlagen notwendig geworden wurden zum Anlaß genommen, die Auftragssumme zu korrigieren - wie das in der Hälfte der Festpreisprojekte auch geschah.
Prozeßmanagement, in dem die Softwareentwicklung als kontinuierlicher Prozeß behandelt wird, dessen Ende offen ist, ist demgegenüber wesentlich diffiziler zu steuern und im Griff zu behalten. Ein solches Prozeßmanagement ist letztlich an eine Reihe von Vorbedingungen geknüpft, die in den meisten Unternehmen erst hergestellt werden müssen. Die Definition der Ziele beziehungsweise Vorgaben kann nicht als einmaliger, in sich abgeschlossener Schritt behandelt werden, sondern muß als zeitlich offener Prozeß angelegt sein, in dem Entwicklung des Softwareprodukts kontinuierlich mit einer Neubestimmung der Ziele und Vorgaben verschränkt ist. Damit tritt an Stelle des statischen Abgleichs von Soll und Ist, durch den der jeweilige Projektstand gemessen wird, eine periodische Neubestimmung der einzelnen Arbeitspakete und der gesetzte Termine. Dies macht grundsätzlich neue Verfahren der Legitimation und der Kontrolle notwendig.
Ein solch offenes oder dynamisches Prozeßmanagement hat seinerseits auch Konsequenzen für die Rolle des mittleren und höheren Managements sowohl in den Anwendungs- wie in den Entwicklungsbereichen. Dieses muß nun wesentlich stärker in den Entwicklungsprozeß eingebunden sein, als dies heute in den meisten Softwareprojekten der Fall ist.
Literatur: R. Kling: Cormputerization as an Ongoing Social and Political Process Irvine, 1985.
DIN: DIN 69 901. Projektmanagement, Begriffe. 1980
IDC: Informations Informik 89 - Der deutsche Markt für Software und Sources 1988 - 1994.
Friedrich Weltz und Rolf G. Ortmann