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.

09.10.1992 - 

Projekt-Management in der Praxis (Teil 20)

In Krisen kommt Klärungs- und Entscheidungsbedarf ans Licht

Krisen gehören ZUM gewöhnlichen Schicksal von Software Projekten. Sie können Projekte gefährden, sie können aber auch Spannungen abbauen oder Fehlentwicklungen korrigieren, die den Ablauf der Entwicklungsarbeiten belastet haben, Daher gilt es, Krisen konstruktiv zu nutzen.

In über der Hälfte der untersuchten Projekte berichteten unsere Gesprächspartner von Krisen, die es gegeben habe. Diese hatten sehr unterschiedliches Gewicht. Sie reichten von einem Durchhänger, also einer Motivationskrise, die nach einigen Tagen überwunden war, bis hin zum Abbruch des Projekts.

So unterschiedlich diese Krisen sich manifestiert haben mochten, wiesen sie doch eine Reihe von Gemeinsamkeiten auf. Durch allmählich sich verstärkende Schwierigkeiten er. schienen das bisherige Vorgehen und der Erfolg das Projekts zunehmend in Frage gestellt, ohne daß die Beteiligten dies als Problem offen und ausdrücklich aufgegriffen und zu einer Lösung geführt hatten. In der Krise kam nun dieser aufgestaute Klärungs- und Entscheidungsbedarf mehr oder weniger gewaltsam nach oben.

In einigen Projekten hatte man eine technische Lösung - Entwicklungssprache, Datenbank etc. - gewählt, die sich dann als nicht tragfähig erwies. Angesichts des bislang investierten Arbeitsaufwands und der Hoffnung, doch noch einen gangbaren Weg zu finden, wurde die grundsätzliche Auseinandersetzung über die Erfolgsaussichten des gewählten Ansatzes immer wieder hinausgezögert. Das Eingeständnis, daß man in einer Sackgasse stecke, und der Entschluß, eine neue technische Lösung zu suchen, gestalteten sich ausgesprochen schwierig.

In einem Projekt hatte man eine neue, vom Anbieter gerade Freigegebene Entwicklungssprache genutzt, die sich aber nach und nach als weitgehend instabil, das heißt, noch mit zahlreichen Fehlern behaftet, erwies. Zwar sagte der Hersteller immer wieder deren Bereinigung zu, konnte dieses Versprechen aber nicht erfüllen. Diese Schwierigkeiten und die damit verbundenen Verzögerungen hielt das Projektteam zunächst verdeckt, da es sich ursprünglich für die gewählte. Entwicklungssprache sehr stark eingesetzt hatte und befürchtete, sich mit der eigenen Fehlentscheidung konfrontiert zu sehen. In einer Sitzung Mit der Geschäftsleitung, bei der die Ursachen der Verzögerungen im Projektablauf diskutiert wurden, mußten dann schließlich die Karten offen auf den Tisch gelegt werden. Daraufhin stoppte die Leitung das Projekt zunächst entschloß sich nach eingehender Überprüfung möglicher technischer Alternativlösungen aber doch zur Fortführung.

In die Krise gerieten Projekte vor allem dann, wenn ein vorgegebener Termin oder Budgetrahmen nicht einzuhalten war. Nachdem sich im Projektverlauf allmählich - und zunächst nicht problematisiert - Abweichungen von dem vorgegebenen Zeit- und Kostenrahmen oder auch nur den eher diffus bestehenden Erwartungen ergeben hatten, kam es schließlich zu einer Auseinandersetzung über diese Verzögerungen und deren Ursachen, die dann meist zu einer Neudefinition der Terminvorgaben, des Projektvolumens oder des Leisungsumfangs führten, in einigen Fällen aber auch zum Abbruch des Vorhabens.

Bei der Entwicklung eines Fehlerdiagnosesystems, das für den Vertrieb eines großen Herstellers erarbeitet wurde, unterliefen immer wieder Abweichungen von der Projektplanung. Diese begründete das Projetteam mit unvorhergese henen technischen Schwierigkeiten, die zu einer mehrmaligen Korrektur des ursprünglich gesetzten Termin- und Budgetrahmens führten. Als nach zwei Jahren eine weitere Verlängerung beantragt wurde, stoppte der zuständige Bereichsleiter das Projekt, weil er keine verbindlichen Aussagen über den noch notwendigen Entwicklungsaufwand erhalten konnte.

Häufigster Auslöser von Krisen waren Schwierigkeiten bei der Konsensfindungs etwa dort, wo es über einen längeren Zeitraurn hinweg nicht gelang, sich über die Gestaltung der zukünftigen Lösung zu einigen. Divergenzen gab es bei der Wahl der Entwicklungssprache oder der Hardware, der Datenbanklösung und vor allem der Formulierung der Anforderungsspezifikation. Die Konfliktfronten verliefen dabei sowohl zwischen Auftraggebern und Entwicklern der Software als auch unter den Anwendern sowie innerhalb des Entwicklungsbereichs.

Woher rührt diese offenkundige Krisenanfälligkeit von Softwareprojekten? Fäst jedes Vorhaben enthielt, so stellten wir fest, Konfliktpotential, weil divergierende Erwartungen mit ihm verbunden wurden. In den frühen Projektphasen karn das nicht zum Tragen, weil die Konturen des neuen Produkts und seiner Auswirkungen noch blaß und undeutliche mögliche Interessengegensätze damit verdeckt blieben. Erschwert wurde die Verarbeitung von Konfliktpotential auch durch die Neigung, Divergenzen, die letztlich betriebspolitischer Natur sind, über technische Argurnentationen auszutragen.

In der Anteilung für Datenverarbeitung eines Dienstleistungsunternehmens rangen Mitarbeiter ein Jahr lang um das richtige Betriebssystern für eine geplante Entwicklung. Obwohl sich die Argumentationen ausschließlich auf die technischen Leistungsmerkrnale der diskutierten Möglichkeiten bezogen, waren es recht handfeste be. triebspolitische Gründe, die die Frontenbildung bestimmten: Die "Traditionalisten", die für die Beibehaltung des bereits im Einsatz befindlichen Betriebssystems plädierten, befürchteten mit dem Übergang auf, ein neues System persönliche Nachteile. Ihre Qualifikationen und darnit auch ihr betrieblicher Status waren wesentlich auf die alte Anlage bezogen. Die "lnnovatoren" versprachen sich von einem Systemwechsel unter anderem auch ein Aufbrechen des bestehenden Statusgefüges in der Datenverarbeitungsabteilung. Sie wandten sich,schließlich - unter Umgehung des Dienstwegs - mit einer Vorlage an den Vorstand. Dies führte zu einem Eklat, durch den sich der Vorstand gezwungen sah, den Streitfall endlich zu entscheiden.

Dabei bestand die Gefahr, sich mit einem Scheinkonsens zu begnügen, das heißt einer Lösung, der die interessierten Parteien nur deshalb zustimmten, weil kontroverse Aspekte ausgeklanimert blieben. Die Bedingungen, die eine kontinuierliche Auseinandersetzung mit der Zielbestimmung wie mit dem Vorgehen besonders wichtig erscheinen ließen, ers chwerten diese zugleich. Sie bewirkten, daß ständige Neubestimmung des Vorgehens und Konsensherstellung in vielen Projekten unterblieb und entsprechend Klärungsbedarf sich aufstaute.

Häufig fehlte zudem - insbesondere bei innovatorischen Aufgabenstellungen - in den Anfangsphasen noch die eindeutige Klarheit über Aufgaben und Methoden. Sie stellte sich vielfach erst im Lauf des Entwicklungsprozesses ein. Viele Softwareprojekte glichen damit einer Reise in unbekanntes Gebiet. Immer wieder war der Weg, unter Umständen sogar das Reiseziel neu zu bestimmen, galt es Einigkeit zwischen den Teilnehmern darüber herbeizuführen, ob das Ziel noch das gleiche war, ja ob es überhaupt erreicht werden konnte. Unterblieb diese kontinuierliche Abstimmung, so konnte man zwar noch eine ganze Weile weitermarschieren, mit jedem weiteren Schritt allerdings wuchs die Gefahr, daß die Weggefährten, recht unterschiedliche Absichten verfolgten.

Eine Reihe von Bedingungen komplizierte jeweils die Klärung. Dazu gehörte die Abstraktheit des Gestaltungsgegenstands, der die Kommunikation zwischen den am Entwicklungsvorhaben Beteiligten wie auch eine eindeutige Bestimmung von Zielvorgaben erschwerte. Die Software-Entwicklung stellt sich dar nicht nur als ein Prozeß zunehmender Verfeinerung der .Zielvorgaben, sondern gleichzeitig auch der Reduzierung ihrer Abstraktheit. Versuche, diese Abstraktheit im Sprung auf zuheben, etwa durch die Diskussion sehr konkreter Einzelanwendungen - zum Beispiel des Aufbaus verschiedener Masken - erhöhten eher das Krisenpotential. Die grundsätzlichen Prämissen und Implikationen des isolierten Gestaltungsproblems blieben meist ausgespart - und damit die notwendige Präzisierung der Zusammenhänge und Voraussetzungen. Unklarheiten, ungelöste Widersprüche wurden so unter Umständen über mehrere Entwicklungsschritte fortgeschleppt, bis sich irgendwann ihre Bereinigung aufdrängte, häufig erst bei der Konfrontation mit dem fertigen Produkt.

In diesem Zusammenhang ist auch ein Phänomen zu sehen, das sich in vielfacher Hinsicht belastend auf die Projektabwicklung auswirkte: die Unterschätzung der Komplexität des Vorhabens, die man erst im Lauf des Entwicklungsprozesses entdeckte.

Entsprechend erfaßte man auch erst Schritt für Schritt ihre Konsequenzen für den notwendigen Arbeitsaufwand und die Einhaltung der gestellten Termine sowie die möglichen Auswirkungen auf Arbeitsverfahren und Zuständigkeiten im Anwendungsbereich. Gerade die nicht technischen Aspekte des Vorhabens erwiesen sich als krisenträchtig.

Man könnte von einer strukturellen Krisenanfälligkeit von Softwareprojekten sprechen. Krisen können gesehen werden als normaler oder sogar notwendiger Teil von Vorhaben, bei denen kein laufender Abgleich der Ziele und Vorgaben mit dem jeweiligen Entwicklungsstand und den sich ergebenden Konsequenzen für die Gestaltung sowohl der Software als auch des weiterer Projektablaufs stattfindet. Erfolgreich gestaltete Krisen holen nach, was vorher versäumt wurde: die Anpassung des Vorgehens an veränderte Bedingungen und die Sicherstellung der Übereinstimmung darüber. Umgekehrt ausgedruckt: Maßstab für den Erfolg einer Krise ist, ob sie zu einem tragfähigen Konsens für das weitere Vorgehen führt oder nicht.

Krisen bedeuten vielfach letztlich eine Konfrontation mit dem Realitätsprinzip; erfolgreich bestandene Krisen bringen eine Anpassung an eine veränderte oder überhaupt erst erkennbar gewordene Sachlage. Dies wird indirekt bestätigt durch Projekte, in denen sich das Fehlen einer solchen Krise zum Nachteil auswirkte.

Unterschiedlich wie die Ursachen und Ausdrucksformen von Krisen waren auch die Formen ihrer Überwindung. In einigen Projekten verständigten sich die beteiligten Stellen durch eine Diskussion, in der sie Ziele und Lösungsansätze, über die man sich bislang nur vage ausgetauscht hatte, explizit behandelten.

In einem Projekt, bei dem man lange Zeit keinen Konsens über eine verbindliche Anforderungsspezifikation gefunden hatte, setzen sich Vertreter aller involvierten Stellen zusammen und erarbeiteten in einem siebentägigen Workshop ein sehr detailliertes Pflichtenheft, das zwar später noch ergänzt und korrigiert wurde, sich aber doch als tragfähige Basis für die weitere Entwicklung erwies, nicht zuletzt, weil die Beteiligten die einzelnen Spezifikationen nicht nur aufgelistet, sondern auch inhaltlich diskutiert hatten.

In anderen Projekten führte die Intervention hierarchisch übergeordneter Stellen die Bewältigung der Krise herbei.

So übernahm in einem Vorhaben, in dem das Entwicklungsteam keine Einigung über eine alternative Technikvariante erzielen konnte, der zuständige Abteilungsleiter die Projektleitung und erzwang einen Konsens.

In all diesen Fällen war die Bewältigung der Krise Ergebnis einer mehr oder weniger spontanen Aktion, ausgelöst in Reaktion auf eine sich dringlich darstellende Problematik, sozusagen aus der Not geboren. Nur in einem Großunternehmen begegneten wir einem Krisen-Management, das ausdrücklich als solches bezeichnet und institutionalisiert war.

Dort bestand die Institution eines Krisen-Managers, der eingeschaltet werden konnte, wenn Entwicklungsprojekte in Schwierigkeiten gerieten. Er verfügte über weitgehende Vollmachten und Ressourcen, durch die Restriktionen, die die Projektabwicklung behinderten zum Beispiel fehlende Personalkapazitäten -, schnell beseitigt werden konnten. In dem von uns untersuchten Vorhaben, in dem es immer wieder zu Kontroversen zwischen Projekt-Management und Projektleitung gekommen war, leitete der Krisen-Manager auf Intervention des Vertriebs beziehungsweise Beschwerden von Kunden, die über Terminverzögerungen klagten, eine Umstrukturierung der Projektorganisation ein.

Auch bei dieser Form des Krisen-Managements handelte es sich letztlich um eine reaktive Rettungsaktion, eine von außen dem Projekt verordnete Hilfe vor dem Scheitern. Wie in anderen Projekten auch, setzte diese Maßnahme erst sehr spät ein. Mit früherem Eingreifen hätten sich erhebliche Verzögerungen vermeiden lassen.

An sich mag es überraschend erscheinen, daß solche Krisen, obwohl sie offensichtlich zum normalen Schicksal von Software-Entwicklungsprojekten gehören, durchweg, für die Beteiligten unerwartet kamen und auch erfahrene Software-Entwickler weitgehend unvorbereitet trafen. Dazu beigetragen hat zweifellos, daß die Schwierigkeiten unmerklich, eher schleichend entstanden, und daß die Ursachen, die zu ihrem Ausbruch führten, zunächst verdeckt waren und nur allmählich verstärkend wirkten. Bezeichnend erscheint dafür, wie die meisten Projekte in die Krise gerieten: über einen langen, für alle Beteiligten quälenden Prozeß, in, dem Spannungen, Widersprüche und Unklarheiten die Arbeit mehr und mehr belasteten, ohne ausgetragen zu werden.

An der Entstehungsgeschichte der Krisen wird erkennbar, daß die an sich naheliegende Forderung nach einem präventiven Krisen-Management, das der Krise zuvorkommen würde, naiv wäre. Ein solches Management setzt Bedingungen voraus, deren Fehlen gerade die Probleme verursacht hat. Krisen zeichnen sich durch ihre unter Umständen gewollte - unauffällige Entstehungsgeschichte aus, durch die die Auslösung vorbeugender Maßnahmen erschwert wird. Nicht präventives Krisen-Management ist die Antwort auf die strukturelle Krisenanfälligkeit von Softwareprojekten, sondern die ausdrückliche Berücksichtigung jener Voraussetzungen in der Projektorganisation und -abwicklung, auf deren Fehlen die Entstehung der Krise zurückzuführen ist. So können etwa der laufende Abgleich der Entwicklungsarbeiten mit den gesetzten Zielen und die kontinuierliche Abstimmung und Konsensherstellung zwischen Entwicklern und Anwendern die Krisenanfälligkeit eines Projekts reduzieren. Mit diesen Anforderungen an die Gestaltung des Prozesses der Software-Entwicklung werden wir uns in der nächsten Folge auseinandersetzen