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.

06.11.1992 - 

Projekt-Management in der Praxis (Teil 24)

Exaktere Planung des Projekts garantiert noch keinen Erfolg

In den untersuchten Projekten stellt sich die Softwarekrise wesentlich als eine Krise des Projekt-Managements dar, das heißt der zur Planung, Steuerung und Kontrolle der Projektabwicklung verwendeten Konzepte, Verfahren und Instrumente. Sie erweisen sich als weitgehend unzulänglich, die prozessuale wie die strukturelle Komplexität der Entwicklungsprozesse in den Griff zu bekommen.

Die Softwarekrise, seit den 70er Jahren immer wieder diskutiert, ist nach wie vor ein aktuelles Thema. "Dem großen technologischen Fortschritt auf seiten der Hardware steht heute eine Stagnation auf seiten der Software gegenüber", konstatieren Bullinger, Fähnrich und Otterbein in ihrem Artikel "Mit Software-Architekturen aus der Softwarekrise?" Symptome einer solchen Krise waren in den untersuchten Projekten nicht zu übersehen: Termine und Kostenbudgets wurden - vielfach erheblich - überzogen, entwickelte Software erwies sich als nur bedingt tauglich oder kam gar nicht zum Einsatz. Wir trafen aber auch auf effizient abgewickelte Projekte, die durchaus zu verwertbaren Ergebnissen führten.

Wovon hing der Projekterfolg ab? Wie trug das Projekt-Management zu ihm bei? Es scheint zunächst schwierig, einen direkten Bezug von Planung und Erfolg zu erkennen.

Das liegt nicht nur an der Vielfalt der projektspezifischen Lösungen - diese ist ihrerseits ein wichtiger Befund -, sondern auch daran, daß sich die Ergebnisse gegenüber etablierten Interpretationsmustern zu sperren scheinen.

Wir trafen auf Projekte, die trotz fehlender formalisierter Planung zu einem recht erfolgreichen Abschluß kamen; ihnen standen andere gegenüber, die trotz - oder wegen - detaillierter Planung nur zu unbefriedigenden Ergebnissen führten oder gar abgebrochen wurden.

Eher zu belegen war dagegen ein Zusammenhang zwischen Projekterfolg und der Bewältigung von Anpassungserfordernissen, die sich im lauf des Entwicklungsprozesses stellen. Diesen Befund legt sowohl die Analyse der detailliert untersuchten Projekte als auch die umfassende quantitative Auswertung nahe.

Unbefriedigend verliefen vor allem Projekte, in denen es nicht gelang, die ursprünglichen - häufig diffusen oder irrealen - Ziele und Vorgehensweisen an die sich mit der Zeit konkretisierenden Anforderungen an die Gestaltung sowohl des Entwicklungsprodukts wie des Projektablaufs anzupassen. Erfolgreich hingegen waren Vorhaben, in denen der Prozeß der technischen Entwicklung mit denen der Konsensbildung und der Wissensakquisition verzahnt war, so Entwicklungsziele und Projektabwicklung laufend neu bestimmt werden konnten.

Ein großer Teil der Projekte kam dabei mit einem bemerkenswert geringen Einsatz formalisierter Verfahren und Instrumente aus. Dort, wo Ansätze zu einer systematischen Planung, Steuerung und Kontrolle der Projektabwicklung zu erkennen waren, überwog eine eher reaktive Wahrnehmung des Projekt-Managements, das heißt eine situative Handhabung der Methoden und Verfahren. Das offizielle Projekt-Management hinkte vielfach eher hinter der Entwicklung her, als daß es sie bestimmte. Überspitzt formuliert: Viele Projekte waren nicht wegen, sondern trotz der Interventionen des Managements erfolgreich. Auch ein extensiver Einsatz formalisierter Verfahren verhinderte das Scheitern nicht zwingend.

Symptomatisch erscheint hierfür das Schicksal eines Vorhabens, das zweijähriger, Laufzeit und einem erheblichen Entwicklungsaufwand abgebrochen wurde. Dabei waren bei der Planung und Durchführung die ausdifferenzierten und formalisierten Prozeduren, die eben einem solchen Scheitern vorbeugen sollten, strikt befolgt worden. Eine detaillierte, scheinbar fundierte Aufwandsberechnung lag der Konzeption zugrunde, und an den vorgegebenen Meilensteinen war der Stand der Entwicklungsarbeiten systematisch überprüft worden. All dies konnte den Mißerfolg nicht verhindern: Es war nicht gelungen, ein tragfähiges technisches Konzept zu entwickeln. Dies hatte sich zwar schon seit längerem abgezeichnet, war aber gegenüber der Unternehmensleitung verschleiert worden.

Viele Projekte kamen durch informelle Prozesse der Selbststeuerung voran, etwa bei der Einarbeitung in die Aufgabenstellung, bei der Arbeitsteilung in den Teams, bei den Kotakten zum Anwenderbereich und bei der Konsensherstellung. Notwendig dafür waren nicht zuletzt "stille" Leistungen der Entwickler und unter Umständen auch Anwender. Sie wurden neben den "offiziell" vorgegebenen Aufgaben erbracht und meist in den Projektplanung nur unzureichend berücksichtigt.

Starre Regelungen wurden unterlaufen

Der wesentliche Beitrag dieser stillen Leistungen war die Anpassung der rigiden offiziellen Regelungen an die sozialen und betriebspolitischen Anforderung des Entwicklungsprozesses. Starre Regelungen wurden unterlaufen und der Projektablauf dadurch dynamisiert. De facto erfolgte durch diese Selbststeuerungsprozesse eine Annäherung sequentiell angelegter Prozesse an inkrementelle Vorgehensweisen.

In einem Großteil der Vorhaben standen daher offizielle Regelungen nur in einem recht losen Zusammenhang mit dem realen Geschehen. Ablauf taten sich vielfach erhebliche Diskrepanzen auf, ein Phänomen, auf das man in Betrieben auch in anderen Zusammenhang immer wieder stößt, das hier aber besonders ausgeprägt in Erscheinung trat (vgl. Weltz 1991). Dies beeinträchtigte die Steuerbarkeit und Berechenbarkeit der Projektverläufe und trug zu deren Krisenanfälligkeit und mangelnder Transparenz bei.

Hieraus folgten vor allem auch die Schwierigkeiten bei der Synchronisierung des Projektgeschehens, also bei Verzahnung und Abstimmung von Lernprozessen, Konsensbildung, Definition der Vorgaben und Entwicklung. Konflikte wurden vielfach verdeckt ausgetragen und wirkten sich gerade deshalb belastend für den Projektablauf aus.

Erkennbar war auch die begrenzte Reichweite und Tragfähigkeit der informelle Regelungsprozesse. Dies gilt etwa für die Vermittlung von kontextuellem Wissen, das heißt von Erfahrungen und Erkenntnissen, die im Projektverlauf gesammelt wurden und meist in der formalen Dokumentation kaum einen Niederschlag fanden. So stellte häufig der projektübergreifende Wissenstransfer eine ausgesprochene Schwachstelle dar. In fast allen Projekten fehlte eine systematische Nachevaluierung. Vielfach bewerteten die Verantwortlichen nicht einmal die Angemessenheit der entwickelten Software. Daraus ergab sich die ausgeprägte institutionelle Lernschwäche, auf die wir in vielen Unternehmen trafen, das heißt die geringen Fähigkeiten, Erfahrungen die im Verlauf der Projekte gesammelt wurden, systematisch umzusetzen.

Es erscheint symptomatisch, daß sich gerade bei Großprojekten die Abwicklung oft problematisch darstellte. Sie waren überdurchschnittlich häufig durch folgende Charakteristika gekennzeichnet:

- Die Verantwortlichen formulierten den Projektauftrag ohne Einbeziehung der Anwender und veränderten diese diffuse Beschreibung im Projektverlauf nicht.

- Fremdleistungen wurden im Projektverlauf nur reaktiv in Anspruch genommen.

- Die Projektorganisation entstand erst im Projektverlauf und wurde dann ein- oder mehrmals verändert.

- Die Beteiligten schätzten den Projektablauf als anarchisch ein.

- Die Bewilligung des Vorhabens stützte sich auf keine Kalkulation des Projektvolumens, die vielmehr erst sukzessive vorgenommen und dann noch korrigiert und überzogen wurde.

- Der Personaleinsatz war zwar vorausgeplant, geschah dann aber weitgehend situationsbezogen und reaktiv.

- Aufgabenzuteilung und Einweisung in die Projektarbeit erfolgten nach formalisierten Verfahren.

- Das Projekt war durch verdeckte Konflikte bestimmt.

- Die Beteiligten schätzten den Erfolg kontrovers ein.

Einerseits gab es in Großprojekten ausgeprägter als in kleineren Vorhaben Versuche, das Geschehen durch Planung und formalisierte Verfahren zu steuern.

Andererseits waren die Schwierigkeiten, die Komplexität der Arbeitsabläufe in den Griff zu bekommen, unverkennbar. Verkürzt auf eine Formel gebracht: In Großprojekten gab es zwar mehr Planung, diese wurde aber auch weniger eingehalten.

Bezeichnenderweise schätzte man in großen Softwarehäusern, wissenschaftlichen Institutionen und bei Herstellern - also bei Einrichtungen, die sich durch eine ausgeprägte Planungsorientierung auszeichnen - den Erfolg abgeschlossener Arbeiten wesentlich kritischer ein als in Anwenderunternehmen und kleineren Softwarehäusern.

Insgesamt vermittelt der Verlauf der untersuchten Projekte den Eindruck, daß die Schwierigkeiten, mit einem akzeptablen Aufwand zu einem verwertbaren Ergebnis zu kommen, nicht so sehr auf softwaretechnischer Ebene lagen als im Bereich des Managements. Die Aussichten, diese Schwierigkeiten allein durch technikimmanente Ansätze in den Griff zu bekommen, scheinen begrenzt, solange sie nicht begleitet werden durch komplementäre Entwicklungen auf der Ebene des eigentlichen Projekt-Managements.

Die unbefriedigenden Ergebnisse, die der zögerliche Einsatz von CASE bislang gezeitigt hat, sprechen für diese These. Eine Studie von C. Heinrich für die Butler Cox GmbH in München kommt zu dem Schluß, daß sich die Erwartungen der Anwender von CASE überwiegend nicht erfüllt hätten. Die meisten CASE-Investitionen ließen sich keinesfalls rechtfertigen. Etwa 95 Prozent der 75 untersuchten Unternehmen seien nicht in der Lage, das hochkomplexe Potential der CASE-Tools auszunutzen.

Die Softwarekrise ist eine Krise des Projekt-Managements. Notwendig sind Verfahren, die eine Dynamisierung und Synchronisierung von Entwicklungsprozessen und Projektsteuerung leisten. Gefordert ist die Bereitschaft der Führungskräfte in den Entwicklungs- und Anwendungsbereichen, sich in die Prozesse der Entscheidungs- und Konsensbildung stärker zu engagieren.