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

Zwei Arten von Projekt-Management

Die Entwicklungsabteilung eines Herstellerunternehmens soll ein sehr komplexes und umfangreiches Programm zur Fehlersuche in einem großen Softwaresystem entwickeln. Auftraggeber ist ein Großkunde, die Ingenieure erhalten den Auftrag in Form eines Leistungskatalogs, der als Grundlage für die Planung dient. Eine Reihe von Entwicklern soll für einzelne Teilsysteme die voraussichtlich erforderlichen Lines-of-Code angeben. Ausgehend von diesen Schätzwerten, erstellt nun der Projektleiter einen Aufwands- und Zeitplan, wobei er die angesetzten Werte erheblich verringert. "Wenn wir bereits am Anfang gesagt hätten, daß wir 30 Mannjahre brauchen, wäre mit diesem Projekt nie angefangen worden." Der Vertrieb reduziert die Aufwandskalkulation noch einmal, so daß schließlich von den ursprünglich 30 Arbeitsjahren nur 15 verbleiben.

Die Verantwortlichen stellen nach Erteilung des Auftrags den Projektleiter und sechs Software-Entwickler für die Projektarbeit ab. Unterstützt werden sie durch ein externes Softwarehaus, in dem insgesamt 15 Software-Entwickler für das Projekt tätig sind. Die Aufteilung der Arbeiten wie auch der Projektablauf werden detailliert geplant, Meilensteine für die einzelnen Phasen vorgegeben. Diese Projektplanung wird schriftlich fixiert.

Auf der Basis des Leistungskatalogs wird eine Funktionsspezifikation erarbeitet und an den Vertrieb gesandt, der sie wiederum dem Kunden übermittelt. Eine direkte Diskussion zwischen dem Kunden beziehungsweise einzelnen Anwendern und der Entwicklungsabteilung unterbleibt. Das Systemdesign beinhaltet eine sehr elegante Lösung für das Gesamtsystem. Anspruchsvoll ist auch die Planung des Entwicklungsprozesses: Die Arbeit an den einzelnen Teilsystemen erfolgt zeitgleich und inhaltlich eng aufeinander bezogen.

Die Entwicklungsarbeiten beginnen sehr rasch, so daß, als nach einiger Zeit vom Vertrieb ein umfangreicher Änderungskatalog eintrifft, dieser aus Zeit- und softwaretechnischen Gründen kaum mehr berücksichtigt werden kann.

Trotzdem läßt sich der erste Meilenstein nicht erreichen, so daß die Bereichsleitung eine Verlängerung genehmigen muß. Aber auch die geänderten Termine werden überschritten. Es kommt zu einer Serie von Neufestsetzungen. Nachdem das ursprünglich angesetzte Arbeitsvolumen um mehr als das Doppelte überzogen ist, ohne daß eine Fertigstellung der Arbeiten absehbar wäre, ordnet der Vorstand schließlich den Abbruch des Projekts an. Für Projektleiter und Projektteam kommt das völlig überraschend.

In Abstimmung mit dem Kunden nimmt man unmittelbar anschließend ein Folgeprojekt in Angriff, allerdings mit einem erheblich reduzierten Umfang. Es soll eine Laufzeit von einem Jahr haben. Das Team besteht aus dem bisherigen Projektleiter und vier Software-Entwicklern.

Die Leitung des Entwicklungsteams gibt Anforderungskatalog und Fertigstellungstermin vor. Das Team selbst erstellt die Funktionsspezifikation, wobei man sich wesentlich auf Erfahrungen aus dem unternehmensinternen Kundendienst bezieht. Das Vorhaben wird nun im weiteren mit einem Minimum an formalen Projekt-Management durchgeführt, so gibt es weder Phaseneinteilung noch Meilensteine, vor allem fehlt jegliche schriftliche Fixierung des Vorgehens. Projektleiter und die einzelnen Entwickler kooperieren sehr kontinuierlich und eng miteinander. Das Projekt läßt sich termingerecht mit einer Version des Systems, die zumindest formal die Anforderungen weitgehend erfüllt, abschließen.

Für den Abbruch des ersten Projekts läßt sich rückblickend eine Kombination von Ursachen erkennen:

- Das sehr anspruchsvolle Design, die Orientierung an der perfekten Lösung, erfordert eine sehr genaue inhaltliche und zeitliche Koordination. Schwierigkeiten und Verzögerungen bei der Bearbeitung einzelner Teilsysteme schlagen daher unmittelbar auf die Arbeiten an anderen Teilsystemen durch.

Vor allem die Koordination der Arbeiten des internen und externen Entwicklungsteams bereitet Probleme. Die Orientierung der internen Software-Entwickler an einer hocheleganten Lösung überfrachtet die Funktionsspezifikationen und führt im weiteren zu immer neuen Ausdifferenzierungen des Systems.

- Kompliziert wird die Entwicklung des Systems weiterhin durch die nachträglich vom Kunden beziehungsweise dem Vertrieb eingebrachten Änderungswünsche, die zwar nur zum Teil noch berücksichtigt werden, aber doch eine Reihe von Anpassungen und Korrekturen erforderlich machen.

- Das vom hochformalisierten Projekt-Management vorgegebene starre Schema erschwert die Bewältigung der genannten Schwierigkeiten. Hoher Zeitdruck aufgrund unrealistischer Terminansetzungen, dem auch durch Überstunden nicht erfolgreich zu begegnen ist, läßt die ursprünglich sehr hohe Motivation der Entwickler verlorengehen. Zwei der internen Entwickler verlassen das Projekt, ihre Nachfolger müssen sich erst einarbeiten, was wiederum die Abstimmungsschwierigkeiten in den Teams verstärkt.

Das reduzierte Folgeprojekt basiert auf einem diametral entgegengesetzten Ansatz:

- Nicht die möglichst elegante Softwarelösung, sondern Umsetzungsfähigkeit und termingerechte Fertigstellung sind die vorrangigen Ziele. Die Entwickler dimensionieren den Systementwurf so bescheiden wie möglich.

- Die Leitung bemüht sich verstärkt, nur noch realistische Termine anzusetzen.

- Auch Organisation und Management des Projekts reduzieren die formalen Regelungen so weit wie möglich. Es gibt kaum schriftliche Vorgaben, man verläßt sich vorwiegend auf die Kooperation eines kleinen, sehr kompetenten und bereits eingespielten Teams.

Dieser sehr pragmatische Ansatz wird wesentlich durch die Erfahrungen aus dem Vorprojekt bestimmt. Ihre Verarbeitung erfolgt allerdings nur informell und beim Projektteam. Eine offizielle Erörterung vor allem auf den höheren hierarchischen Ebenen findet nicht statt. Es kommt nicht zu einer grundsätzlichen Diskussion des formalen Projekt-Managements.

Die sehr pragmatische Abwicklung des Folgeprojekts verdankt sich einer Nische, die sich unter dem extremen Zeitdruck nach dem Abbruch des ursprünglichen Vorhabens aufgetan hatte. Für das firmenoffizielle Verständnis von Projekt-Management und Projektorganisation bleiben die gesamten Geschehnisse weitgehend folgenlos.