Die inhärente Logik der Software-Entwicklungsprozesse legt zunehmend ein inkrementelles Vorgehen nahe. Statische Verfahren des Projekt-Managements geraten in Widerspruch zu den Anforderungen solcher Abläufe. Neue, evolutionäre Konzepte sind gefragt.
Er kenne kein Softwareprojekt, so stellt der IBM-Manager Nocentini in seinem Aufsatz "The Planning Ritual" fest, das erfolgreich zu Ende geführt wurde, indem man den Plänen, die man ursprünglich entworfen habe, gefolgt sei.
Diese Erfahrung wird durch die Befunde unserer Untersuchung weitgehend bestätigt. Auch wir trafen auf diese Diskrepanz zwischen Planung und wirklichem Leben. Dies gilt für die Kalkulation des Projektvolumens wie für die Projektorganisation, für die Qualitätssicherung wie für den Personaleinsatz. Auch wir stellten immer wieder fest, daß Pläne nicht so sehr den Projektverlauf strukturierten als vielmehr an ihn angepaßt wurden. Und auch wir begegneten umgekehrt dem Phänomen, daß die gesetzten Plandaten zum primären Bezugspunkt bei der Projektabwicklung wurden, daß sie ein Eigenleben entwickelten und so das Ergebnis des Projekts gefährdeten.
Die Gefahr, das Kind mit dem Bade auszuschütten
Angesichts dieser Befunde liegt der Schluß nahe, daß detaillierte Planung überflüssig, ja gefährlich sei - ein Schluß, den Nocentini tatsächlich auch zieht. Aber er gerät damit in Gefahr, das Kind mit dem Bad auszuschütten. Ebenso häufig wie auf Fälle verfehlter oder folgenloser Planung stießen wir auf Projekte, die sehr erkennbar unter einem Mangel an ihr litten. Wir scheinen vor dem Paradox zu stehen, daß Planung zwar nicht möglich, aber doch notwendig ist.
Organisation von Software-Entwicklungsprojekten bedeutet nicht zuletzt die Bewältigung von Komplexität. Diese ergibt sich nicht nur aus der beträchtlichen Kompliziertheit der Entwicklungsaufgaben auf technischer Ebene, sondern auch aus den technischen, sozialen und betriebspolitischen Rahmenbedingungen. Zu ihnen gehören etwa bereits im Einsatz befindliche Hard- und Software, Qualifikation der Anwender und betriebliche Kompetenzstrukturierung. Aus der Tatsache, daß Software-Entwicklung nicht nur Technikgestaltung, sondern fast immer auch Arbeitsstrukturierung beinhaltet, ergeben sich besondere Notwendigkeiten. Sie betreffen Konsensbildung, den Ausgleich divergierender Interessen, die mit der Entwicklung und der Anwendung der Software verbunden sind, und auch die notwendigen Lernprozesse bei Entwicklern und Anwendern .
Die sich aus alledem ergebenden Anforderungen in den von uns untersuchten Vorhaben waren sehr unterschiedlich und häufig auch widersprüchlich. Zweifellos machte dies Planung besonders schwierig - zugleich aber auch wichtig. Notwendig war eine Projektsteuerung, die dem Doppelcharakter der Software-Entwicklung entsprach. Eine technikzentrierte, ingenieursmäßige Projektplanung, die feste Vorgaben und Verfahrensweisen fixierte, scheiterte an ihrer Einseitigkeit. Die Bewältigung der komplexen Schwierigkeiten war in vielen Projekten weniger formalen Verfahren des Projekt-Managements als vielmehr informellen Aktivitäten und Initiativen der Mitarbeiter zu verdanken.
Die Komplexität der Aufgaben führte häufig zu einem Spannungsverhältnis zwischen der Notwendigkeit verbindlicher Zielsetzungen und Vorgaben und dem Zwang zu ständigen Korrekturen. Starre Planung gefährdete die erforderliche Offenheit des Entwicklungsprozesses, wie Cleveland schon 1972 anmerkte.
Umgekehrt drohte Software-Entwicklung oft zur unendlichen Geschichte zu geraten, einer sich immer wieder verlängernden Jagd nach der perfekten Lösung. Begrenzung war
ebenso notwendig wie Offenheit. Es galt, feste Bezugsgrößen zu schaffen, an denen sich die Projektabwicklung ausrichten konnte, ohne die Anpassung an die sich mit dem Entwicklungsprozeß verändernden Bedingungen zu behindern und Optionen auszuschließen.
Die Kunst der Planung von Softwareprojekten besteht demnach darin, einen Mittelweg zwischen Verbindlichkeit und Offenheit zu finden. Dabei sind technische, organisatorische, soziale und betriebspolitische Anforderungen gleichermaßen zu berücksichtigen .
In vielen der untersuchten Vorhaben hat man keine solche Kompromißlösung gefunden. Auf der einen Seite begegneten wir Projekten, in denen ein statisches Management den Entwicklungsprozeß eher behinderte. Auf der anderen Seite gab es
Vorhaben, bei denen die Verantwortlichen oft gar nicht erst den Versuch einer Planung gemacht haben und die entsprechend aus den Fugen gerieten. Daß wir so häufig auf diese beiden gleichermaßen unbefriedigenden Alternativen stießen, dürfte nicht zuletzt auf die Konzepte von Planung zurückzuführen sein, an denen man sich orientierte.
Nicht selten allerdings fand man im Verlauf des Projekts dann doch zu einer mehr oder minder tragfähigen Lösung des Planungsdilemmas - sei es, daß die Beteiligten realitätsfremde Vorgaben den sich aufdrängenden Gegebenheiten anpaßten oder durch informelle Regelungen ersetzten, sei es, daß ein bis dahin weitgehend ungesteuerter Projektablauf ein Korsett von Vorgaben erhielt. Es erscheint bezeichnend, daß solche Lösungen durchweg hausgemacht oder genauer projektgemacht waren, das heißt im Rahmen des Projekts Zug um Zug entstanden, in Reaktion auf sich abzeichnende Anforderungen und Restriktionen. Viele Schwierigkeiten ließen sich auf je spezifische Art pragmatisch lösen. Dies erklärt die ungeheuere Vielfalt der Lösungsansätze, auf die wir praktisch in allen Gestaltungsphasen stießen - bei Kalkulation, Organisation und Management ebenso wie bei Qualitätssicherung und Personaleinsatz. Der Beitrag normativer Modellansätze, die zum Projekt-Management kursieren, war dabei äußerst gering. Praxis und Wissenschaft ignorieren einander weitgehend. Dies dürfte nicht zuletzt auf den normativen Ansatz des akademischen Software-Engineering zurückzuführen sein, der die Entwicklung von Modellkonzepten erleichtert, die offensichtlich an den Erfordernissen der Praxis vorbeigehen.
Die gestörte Beziehung zwischen den normativen Ansätzen und der Praxis wurde in den untersuchten Projekten immer wieder durch das Scheitern von internen oder externen Experten demonstriert, die auf Abwege geratene Projekte auf den Pfad der Tugend zurückführen sollten und dies durch schulmäßige Anwendung von Methoden des Software-Managements zu erreichen suchten.
Warum hält man an der statischen Regulierung des Entwicklungsablaufs nach dem Phasenschema fest, obwohl sich deren Unzulänglichkeit erwiesen hat und man sie auch kaum stringent anwendet? Warum stützt sich auch die akademische, normative Informatik vorwiegend noch auf diese Konzepte? Bei der Wissenschaft liegt der Grund dafür vermutlich darin, daß sich die Informatik nach wie vor sehr stark am Ingenieurwesen orientiert. Wenn Softwaresysteme wie Brücken oder Häuser gebaut würden, könnte man dabei auch ingenieursmäßig vorgehen. Das Phasenmodell fungiert hier als Methodologie, um Software-Engineering als Ingenieurswissenschaft zu etablieren.
Für die Praxis dürfte die Erklärung des Festhaltens am Phasenmodell in den Vorteilen zu suchen sein, die es für die Legitimierung von Projekten bietet. Der Vorzug statischer Konzepte des Projekt-Managements liegt nicht zuletzt darin, daß sie einem unmittelbar einsichtigen und scheinbar einfach zu handhabenden Schema folgen: Aus den Zielen, auf die man sich zu Projektbeginn einigt, ergeben sich Vorgaben, an deren Abarbeitung sich dann der weitere Projektverlauf messen läßt. Das Phasenkonzept ermöglicht es nach Saynisch (1984) zu Beginn des Projekts, also zu einem Zeitpunkt, wo Durchsetzungsaspekte besonders wichtig sind, feste Aussagen über Zeiten, Kosten und Abläufe zu treffen. "Der phasenweise Projektablauf trägt wesentlich dazu bei, das anfangs bei allen Projekten vorhandene Risiko der technischen Realisierbarkeit, der Verwertbarkeit sowie der Zeiten und Kosten mit geringem Aufwand rasch abzubauen. Er ist wesentliche
Voraussetzung für die Durchführung von Projekten."
Daß statische Konzeptionen weitgehend auf fiktiven Größen beruhen, fällt trotz vorangegangener leidvoller Erfahrungen in vielen Unternehmen offenbar nicht so sehr ins Gewicht. Der Wunsch nach Berechenbarkeit scheint hier nicht selten die Wahl des Verfahrens zu entscheiden, wobei man billigend in Kauf nimmt, daß die Plandaten voraussichtlich gar nicht einzuhalten sind. Man kann so tun, als gäbe es das Problem des asynchronen Entwicklungsverlaufs überhaupt nicht. Überall dort, wo die Konsensbildung schwierig ist, lassen sich auf diese Weise unangenehme Auseinandersetzungen in der Schwebe halten und auf einen späteren Zeitpunkt vertagen. Das böse Erwachen kommt erst, wenn irreversible Fakten geschaffen sind.
Die Gestaltung inkrementeller Entwicklungsprozesse ist vordergründig wesentlich komplizierter:
Ziele und Vorgaben sind immer wieder neu zu überprüfen. Dies stellt neue Aufgaben an das Projekt-Management und vor allem an die Verfahren der Entscheidungs- und Konsensbildung
Sie erfordern laufende Neubestimmung von Vorgaben und somit die kontinuierliche Abstimmung zwischen Entwicklungs- und Anwendungsbereich. Dies macht sie zugleich aufwendig und verletzlich.
Hieraus wird verständlich warum inkrementelle Verfahren des Projekt-Managements sich nur zögerlich in der Praxis durchsetzen. Bei ihnen lassen sich kaum im voraus genaue Aussagen über den Umfang des Entwicklungsprozesses machen. Die Ungenauigkeiten, die das Phasenmodell mit seiner scheinbaren Planungspräzision verdeckt, liegen hier offen auf dem Tisch, was die Legitimierung des Vorhabens nicht gerade erleichtern dürfte. Gleichwohl ist die inkrementelle Methode letztendlich die genauere, denn im Unterschied zum Phasenkonzept, dessen Planungsansätze sich im Verlauf des Projekts ja immer weiter von der Realität entfernen und damit zu reiner Makulatur werden, liefert das inkrementelle Vorgehen zunehmend präzisere Planungsdaten, so daß am Ende in der Tat eine Punktlandung möglich ist. Die Verbreitung von inkrementellen Entwicklungsmethoden wird deshalb entscheidend davon abhängen, ob realitätsgerechte Planung in den Betrieben auch theoretisch durchsetzbar ist.
Zweifellos ist der Informatik mit den inkrementellen, dynamischen Lösungsansätzen ein Schritt in die richtige Richtung gelungen, der normativ etwas nachvollzog, was in der Praxis de facto schon vielfach üblich ist: die gleitende Anpassung des Entwicklungsprozesses an die sich verändernden Anforderungen.
Schon 1984 forderte Christiane Floyd den Übergang von den klassischen produktorientierten Ansätzen zu einem prozeßorientierten Modell der Systementwicklung, "das sowohl zur Organisation der Projektabwicklung als auch der Einordnung von
Techniken dient und das - als Alternative zum Phasenmodell - auf Benutzerbeteiligung, iterativem Entwurf und Versionsplanung beruht". Wesentlicher Unterschied zu den herkömmlichen Ansätzen der Software-Entwicklung ist die "bewußte Orientierung auf die Evolution von Systemen".
Übergang zum prozeßorientierten Modell
Bislang konzentriert sich die Auseinandersetzung mit diesem prozeßorientierten Modell vorwiegend auf die Entwicklung der Programme. Mit den Konsequenzen für das eigentliche Management hat man sich noch kaum beschäftigt. Auch in der Praxis haben ja prozeßorientierte Ansätze der Software-Entwicklung bislang weitgehend auf der Ebene der informellen Selbststeuerung, kaum aber im offiziellen Projekt-Management Niederschlag gefunden.
Dabei hat sich in den letzten Jahren auf konzeptioneller Ebene ein neues Verständnis von Projekt-Management herausgebildet, das durchaus den dynamischen Konzepten von Software-Entwicklung entspricht. Es kommt unter anderem in den Arbeiten von Saynisch (1979), Balck (1989), Reschke (1983) und von Treeck zum Ausdruck. Entwicklungsprozesse werden dabei begriffen nicht als "kontinuierliches Fortschreiten im Sinne von Abarbeiten, sondern als eine Folge von Selbstreferenzen, Rückkopplungen, Iterationen und echten Rückschritten". Für die Bewältigung dieses Prozesses erscheinen starre Ablaufmodelle ungeeignet, gefordert ist ein offener Umgang mit Störungen und Unterbrechungen aller Art. Projekt-Management regt Wandlungen an, von denen es rückwirkend selbst wieder reguliert wird.
Aus diesen konzeptionellen Ansätzen werden Postulate für das Management von Projekten abgeleitet. An die Stelle der "Planlastigkeit des Handelns" solle ein neues Verhältnis von Plan und Evolution treten. Planerische Vorgaben müssen elastischer werden, und die Trennung von Planen und Ausführen ist zu überwinden. Die konzipierenden Instanzen müssen die Festlegung von Zielen als evolutionären Prozeß begreifen.
Die formulierten Postulate bewegen sich allerdings auf einer sehr allgemeinen Ebene und müssen daher noch operationalisiert und auf die Besonderheiten der Software-Entwicklung bezogen werden. Dem setzt allerdings der evolutionäre Charakter des Ansatzes Grenzen der eine Übertragung in feste Regeln und Leitsätze grundsätzlich erschwert. Hierin dürfte auch eine wesentliche Barriere für die Verbreitung der neuen Denkweise in der Lehre liegen.
Informelle Prozesse der Selbststeuerung
Dabei kann es nicht darum gehen, die informellen Prozesse der Selbststeuerung, durch die, wie wir gezeigt haben, eine situative Anpassung beziehungsweise Wahrnehmung quasi statischer Verfahren des Projekt-Managements wesentlich getragen war, ihrerseits zu formalisieren - wie dies in manchen Modellen der sogenannten Nutzerpartizipation versucht wird - , sondern einen festen, aber möglichst weiten Rahmen zu schaffen, in dem sie sich entwickeln können. Damit allerdings verschärft sich das Spannungsverhältnis von Offenheit und Verbindlichkeit. Die einseitige Ausrichtung der statischen Konzepte des Projekt-Managements kann nicht durch eine einseitige Ausrichtung an Offenheit ersetzt werden, wie auch von Treeck betont: "Erst in einer sinnvollen Kombination von
Selbstorganisation und Organisationsarbeit sowie Evolution und Planmäßigkeit kann das Entwicklungsprojekt zum Erfolg geführt werden."
Für die Entwicklung von Lösungen, die Verbindlichkeit und Offenheit in der jeweils erforderlichen Weise kombinieren, gibt es allerdings keine Patentrezepte, sondern nur Lösungen von Begriff zu Begriff.
Entscheidend ist dazu nicht die Beherrschung einzelner Regeln, sondern vielmehr ein Grundverständnis des Entwicklungsprozesses und seiner Anforderungen an das Projekt-Management, wie Balck 1989 hervorhob. "Gefordert sind ... nicht so sehr neue Instrumente, Techniken etc., sondern im wesentlichen gewandelte Werte und Haltungen." Notwendig ist eine Auffassung der strukturellen Komplexität von Software-Entwicklung, die ihren Doppelcharakter als Technikentwicklung und Arbeitsstrukturierung berücksichtigt. Gerade die Interdependenz zwischen diesen Gestaltungsdimensionen gewinnt bei den dynamischen Modellen der Software-Entwicklung erhöhte Bedeutung. Eine solche Grundauffassung steht in diametralem Widerspruch zu dem Konzept des Software-Engineering als ingenieurmäßigem Prozeß. Ohne eine Überwindung dieses Grundverständnisses wird die Anwendung neuer evolutionärer Ansätze des Projekt- Managements letztlich in der Luft hängen. Vieles spricht dafür, daß entscheidende Impulse
aus der Praxis kommen werden. Die akademische Informatik kann und muß mehr von der
Praxis lernen, als dies in der Vergangenheit der Fall war.
Literatur:
Balck, H.: Neuorientierung im Projekt-Management - Abkehr von mechanistischer Steuerung und Kontrolle. In:
Reschke, H.; Schelle, H; Schnopp, R.
(Hrsg.): Handbuch Projekt-Management.
Köln 1989
Bullinger, H.J.; Wasserlos,G.: Projekt-Management, Steigerung der Effektivität betrieblicher Produktentwicklung. Office Management, Mai 1991
Cleveland, H The Future Executive.
New York 1972
Floyd, C; Keil, R.: Integrative Systementwicklung. Forschungsbericht des BMFT
DV 84-003, 1984
Nocentini, S.: The Planning Ritual. Data-mation. O.J.
Reschke, H.; Swoboda, M.: Projekt-Management - Konzeptionelle Grundlagen. München 1983
Saynisch, M.: Grundlagen des phasenweisen Projektablaufes. In: Saynisch, M.;
Schelle, H.; Schub, A.: Projekt-Management: Konzepte, Verfahren, Anwendungen. München 1979
Saynisch, M.: Konfigurations-Management. Köln 1984
Treeck, W. von: Projekt und Risiko. Unveröffentlichtes Manuskript.
Serie: Das
Softwareprojekt
In dieser Serie wird über eine Untersuchung berichtet, die die Autoren in und an 46 Softwareprojekten durchführten. Sie war soziologischer Teil des interdisziplinären Projekts zur Arbeitssituation in der Softwareentwicklung, das vom Bundesministerium für Forschung und Technologie (BMFT) im Rahmen des Programms "Arbeit und Technik" gefördert wurde. Das Teilprojekt "Informatik" lag in den Händen von Professor Dr. Wolfgang Hesse, ferner von Udo Bittner und Johannes Schnath, Universität Marburg: das Teilprojekt "Arbeitspsychologie" wurde bearbeitet von Professor Dr. Michael Frese sowie Felix C. Brodbeck, Torsten Heinbokkel, Sabine Sonnentag und Wolfgang Stolte, Universität Gießen.
Die Studie ist jetzt in Buchform im Campus Verlag unter dem Titel "Das Softwareprojekt - Projekt-Management in der Praxis" erschienen. Preis: 48 Mark.