Die Organisation des Projektablaufs orientiert sich überwiegend am Phasenschema, das dann allerdings in der Praxis häufig situativ an die jeweiligen Bedingungen angepaßt wird. Dabei spielen Prozesse der Selbststeuerung durch die Entwicklerteams eine große Rolle.
Projektmanagement ist nach deutscher Industrienorm "die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes" (DIN 69901). Unter Projektmanagement wird also die Steuerung und Kontrolle der Projektaktivitäten verstanden, durch die sichergestellt werden soll, daß Ziele, Termine und Aufwand des Projekts festgelegt und eingehalten werden. Spezifische Anforderungen erwachsen dem Projektmanagement aus den Besonderheiten der Softwareentwicklung, wie wir sie in Folge 1 skizziert haben, der Abstraktheit und Komplexität des Entwicklungsgegenstands und den daraus resultierenden Schwierigkeiten, zu Beginn des Projekts verbindliche Ziel- und Zeitvorgaben zu formulieren. Klassischer Ansatzpunkt des Projektmanagements in der Softwareentwicklung ist das Phasenschema. Der Entwicklungsprozeß wird in eine Reihe von Abschnitten aufgeteilt, die jeweils mit einem klar definierten Ergebnis enden (zum Beispiel Analyse, Definition, Entwurf, Programmierung, Test, Integration). Durch diese Gliederung soll der inhaltliche und zeitliche Ablauf der Entwicklung plan- und steuerbar gemacht werden. Für jeden Arbeitsschritt ist ein definiertes Ergebnis vorgegeben, auf dem dann der nächste Arbeitsschritt aufbauen kann.
Dieses Phasenschema wurde in den letzten Jahren zunehmend kritisch beurteilt (vgl. Hesse). So überzeugend diese Argumentationen aus der Perspektive der immanenten Anforderung des Entwicklungprozesses sein mögen, sie lassen vielfach die Aspekte der Steuerung und Kontrolle von Projekten unberücksichtigt, unter denen dem Phasenschema nach wie vor Vorteile zugeschrieben werden:
Es können Zwischenergebnisse definiert werden, an denen die Termin- und Ablaufplanung ausgerichtet werden kann und die die Kontrolle des Projektfortschritts erleichtern. "Gegen die altmodischen Phasenmodelle läßt sich viel sagen, sie haben aber den Vorteil, daß man weiß, wo man steht. Für die Projektverfolgung ist das eben ideal."
Entsprechende Begründungen finden sich in den Handbüchern zum Projektmanagement: "Der phasenweise Projektablauf trägt wesentlich dazu bei, das anfangs bei allen Projekten vorhandene Risiko der technischen Realisierbarkeit, der Verwertbarkeit sowie der Zeiten und der Kosten mit geringem Aufwand rasch abzubauen.
Er ist eine wesentliche Voraussetzung zur wirtschaftlichen Durchführung von Projekten." (Saynisch)
Trotz aller Zweifel an der Angemessenheit des Phasenschemas verzichtet man deshalb nicht auf seine Anwendung.
Nach wie vor ist die formalisierte Gliederung in feste Abschnitte die vorherrschende Form der Strukturierung des Entwicklungsprozesses (61 Prozent der Projekte).
Andere Formen wie die sukzessive Bearbeitung von Subsystemen (30 Prozent) oder inkrementelle Entwicklung (15 Prozent) finden sich allerdings schon in einer beträchtlichen Zahl der Projekte, wobei diese ihrerseits häufig nach Phasen strukturiert sind. In einem Drittel der Projekte wird Prototyping in der einen oder anderen Form verwandt, wobei hier jedoch eine genaue Angabe durch das recht unterschiedliche Verständnis, was unter diesem Begriff zu verstehen sei, erschwert wird.
Allerdings dominierte ein durchaus analog zur Gestaltung der Projektorganisation primär situativer - Umgang mit der Strukturierung des Entwicklungsablaufs, das heißt, das Vorgehen war stark durch die jeweils vorgegebenen Rahmenbedingungen bestimmt. Nur bei wenigen Projekten war der konsequente Versuch zu erkennen, diese "nach Plan" abzuwickeln. Selbst dort, wo langfristige Planungen bestanden, wichen geplanter und tatsächlicher Projektablauf nicht selten erheblich voneinander ab.
Nur in einem Viertel der Projekte wurde das Phasenschema, nach dem man vorging, auch eingehalten, häufiger (41 Prozent der Projekte) kam es zu Überlappungen der Phasen: Arbeiten der nachfolgenden Phasen wurden begonnen, obwohl die vorangegangene Phase formal noch nicht abgeschlossen war. Auch nach Abschluß einer Phase wurden deren Ergebnisse nochmal einer Überarbeitung unterzogen.
Der Ablauf von 13 Prozent der Projekte wurde als Echternacher Springprozession charakterisiert, das heißt jeweils zwei Schritte vorwärts, einen zurück. Der Projektverlauf war nicht eine stetige Fortentwicklung, in der ein einmal erreichter Entwicklungsstand als feste und verbindliche Basis für den nächsten Schritt diente, vielmehr wurde dieser immer wieder in Frage gestellt. Dies galt nicht allein für technische Entwicklungen, sondern vor allem auch für Beschlüsse und Vorgaben, auf die man sich geeinigt zu haben schien. In weiteren 13 Prozent wurde der Projektablauf als schlicht anarchisch bezeichnet, das heißt ohne erkennbare Systematik, weitgehend von den jeweiligen aktuellen Bedingungen und Zufälligkeiten bestimmt.
In den meisten Projekten kam man mit einem recht begrenzten Instrumentarium formalisierter Verfahren aus. Das gilt für die Qualitätssicherung, für die Kontrolle der Einhaltung von Terminen und Budgets, und das gilt auch für die Steuerung und Kontrolle der Entwicklungsarbeiten.
Hierzu gehört die Erfassung des Zeitaufwands der Entwickler. Immerhin in vier Fünftel der Projekte wurde eine solche Erfassung durchgeführt, allerdings doch recht häufig summarisch, ohne eine Differenzierung nach verschiedenen Tätigkeitsarten etc. Nur in relativ wenigen Projekten wurden die anfallenden Daten kontinuierlich ausgewertet und für die Projektsteuerung verwertet.
In nur wenigen Projekten trafen wir auf den Einsatz computergestützter Instrumente zur Unterstützung des Projektmanagements. In mehreren Projekten hatte man mit solchen Instrumenten experimentiert, dann aber auf ihren Einsatz wieder verzichtet. Ganz überwiegend wurden die Erfahrungen, die man mit solchen Projektmanagement-Tools gemacht hatte, sehr kritisch bewertet. Wichtigste Kritikpunkte waren: Die Verfahren sind zu schwerfällig und aufwendig, sie können ein Projektmanagement durch die Projektleitung, die sich auf persönliche Kontakte, Erfahrungen und Interventionen stützt, kaum entlasten, keinesfalls ersetzen.
"Das hat nur bei ganz großen Vorhaben einen Sinn. Sinn eines Projektmanagement-Tools ist doch, daß es als Frühwarnsystem wirkt, daß da frühzeitig die Alarmglocken läuten, wenn etwas schiefläuft. Wir bekommen aber die Daten, zum Beispiel den Soll/Ist-Abgleich erst am Ende des Monats, da kann es unter Umständen schon zu spät sein. Durch den täglichen Kontakt mit seinen Mitarbeitern ist der Projektleiter viel früher informiert."
Offensichtlich machte es Schwierigkeiten, solche in ihrer Anwendung relativ starren Instrumente einem "situativ" ausgerichteten Projektmanagement anzupassen - oder umgekehrt: Der Beitrag solcher Instrumente zu einer gesteuerten und kontrollierten Projektabwicklung war an Voraussetzungen gebunden, die in den meisten Projekten nicht gegeben waren.
Dynamisierung des Phasenschemas erreicht
Diese Anpassung wurde vielmehr primär getragen von weitgehend informellen Initiativen und Aktivitäten der Projektleiter, Entwickler und vielfach auch der Anwender. Durch diese Prozesse informeller Selbststeuerung wurde de facto eine Dynamisierung des eher "statischen" Phasenschemas erreicht, eine Annäherung an inkrementelle Vorgehensweisen. Erschwert wurde diese situative Anpassung der formal definierten Vorgaben nicht zuletzt durch bestehende Interessenskonflikte und Schwierigkeiten bei der Konsensbildung. In einer der nächsten Folgen werden wir uns damit auseinandersetzen.
Neben diesen Unterschieden in der Gestaltung des Ablaufs des Entwicklungsprozesses waren in den Projekten auch verschiedene Ansätze in der Verankerung des Projektmanagements zu erkennen. Idealtypisch ließen sich hier vier Ansätze unterscheiden:
- prozedurgestütztes Projektmanagement, das stark an festen, mehr oder minder verbindlich vorgegebenen Prozeduren ausgerichtet ist (zum Beispiel Durchführung von Reviews, Überprüfung von Vorgehen für die Erfüllung von Meilensteinen). Projektmanagement heißt vor allem, auf Einhaltung dieser Prozeduren hinzuwirken.
- positionsbezogenes Projektmanagement, das vor allem auf der Interaktion eines - häufig recht komplexen - Netzes von Inhabern bestimmter Positionen beruht, denen spezifische Funktionen zugeordnet sind (Projektleiter, Projektmanager, Vertreter der Fachbereiche, Anwendervertreter, Qualitätsbeauftragte etc.). Die Zuständigkeiten und Verantwortlichkeiten dieser Positionsinhaber sind meist relativ genau fixiert. Dagegen kommt man mit einem Minimum an vorgezeichneten Prozeduren und auf Dauer installierten Gremien aus. Fallen Abstimmungen an, die nicht bilateral zwischen zwei Positionsinhabern geklärt werden können - etwa zwischen Projektmanager und dem Vertreter eines Fachbereiches -, werden ad hoc Ausschüsse gebildet.
- gremiengestütztes Projektmanagement, in dem in einer Reihe von Gremien (Projektgruppe, Arbeitsgruppen, Entscheidungsausschuß) nicht nur die Abstimmung zwischen den verschiedenen Bereichen und Teilprojekten stattfindet, sondern auch "produktive" Arbeit geleistet wird, etwa die Erstellung der Anforderungsspezifikation, oder des Pflichtenhefts.
- personenbezogenes Projektmanagement, das im wesentlichen von einzelnen Personen meist, aber nicht immer der Projektleiter - getragen und bestimmt wird. Diese Zentralfiguren sind sozusagen das Projektmanagement.
Diese Typologie ist natürlich ein analytisches Konstrukt. In der Praxis stießen wir häufig auf Mischtypen, etwa dort, wo die Tätigkeit eines Projektmanagers in starkem Maße durch vorgegebene Prozeduren bestimmt wurde. Insofern ist auch eine eindeutige quantitative Eingrenzung der Verteilung dieser Typen nur bedingt möglich.
Jedes dieser Modelle wies spezifische Stärken, aber auch Schwächen auf. So erleichterte das prozedurbezogene Modell die Steuerung und Kontrolle auch vielschichtiger und komplexer Entwicklungsprozesse. Zugleich war aber immer wieder die Gefahr zu erkennen, daß sich die Prozeduren quasi verselbständigen, das heißt, daß die Einhaltung der Prozeduren und nicht so sehr die sachlichen Anforderungen des jeweiligen Entwicklungsstands die Projektabwicklung bestimmten.
Die Funktionsfähigkeit des positionsbezogenen Modells hing sehr stark nicht nur davon ab, wie kompetent die einzelnen Positionsinhaber waren, sondern auch, wie gut sie miteinander auskamen. Hier lag zugleich die Stärke wie die Schwäche des Modells: Bei guter Kooperation wies es eine beträchtliche Flexibilität und Produktivität auf: fehlte diese, kam es zu Blockierungen, die nur schwer aufzubrechen waren.
Eben dieser Personenabhängigkeit sollte durch das gremienbezogene Modell begegnet werden. Stärke dieses Modells war, daß dort, wo die Gremienarbeit "funktionierte", sie sich als wirksames Instrument der Abstimmung und Konfliktbereinigung zwischen den involvierten Stellen erwies. Andererseits war häufig eine gewisse Schwerfälligkeit in der Projektabwicklung nicht zu verkennen, wie auch die Gefahr verwässerter Gestaltungskonzepte.
Die Stärke des personenbezogenen Modells lag in der maximalen Nutzung der personellen Ressourcen, auf die es zugeschnitten ist. Seine Schwäche und besondere Verletzlichkeit liegt in eben dieser extremen Personenbezogenheit. Das Projekt stand und fiel mit der Leistung dieser Personen.
Stärken und Schwächen der verschiedenen Ansätze waren also an Voraussetzungen gebunden: Das prozedurbezogene Modell etwa an das Greifen der Prozeduren, auf die es sich stützte, das personenbezogene Modell an die Qualitäten einer oder mehrerer Schlüsselfiguren. Dies bedeutet zugleich, daß diese vier Typen nicht als historische Reihenfolge begriffen werden dürfen, als aufeinanderfolgende Stadien einer Entwicklung, die von dem informellen über das situative Projektmanagement hin zum positionsgestützten und schließlich zum prozedurgestützten Management verläuft. Sie sind eher zu verstehen als Lösungsansätze, die sich bei jeweils unterschiedlichen Entwicklungsaufgaben und Rahmenbedingungen anbieten.
In der Praxis war allerdings eine eindeutige Zuordnung der einzelnen Lösungsansätze zu Projekten mit bestimmten Entwicklungsaufgaben kaum möglich. Sehr gut herstellbar war dagegen ein Bezug zum "Stil" des jeweiligen Unternehmens. So entsprach die prozedurbezogene Projektorganisation, der wir bei einem großen Hersteller in mehreren Projekten begegneten, dem allgemeinen, stark formalisierten Verfahrensstil in diesem Unternehmen. Und ähnlich stand die positionsbezogene Organisation eines Projekts bei einem anderen Hersteller im Einklang mit der wesentlich informelleren, stark auf individuellen Initiativen ausgerichteten "Philosophie" dieses Unternehmens. Diese unternehmensspezifische Prägung des Projektmanagements scheint uns Ausdruck dafür, daß es kaum einen als verbindlich akzeptierten "State of the art" auf diesem Gebiet gibt, an dem man sich bei der Projektabwicklung orientierte.
Bezeichnend für diese Unsicherheit waren die Versuche, das Management eines Großprojektes in einer wissenschaftlichen Einrichtung in den Griff zu bekommen. Zunächst wurde "Projektmanagement" vom Projektleiter und seinem Stellvertreter wahrgenommen, das heißt sie wiesen den Teammitgliedern Arbeitspakete zu, ohne oder mit sehr lockeren Zeitvorgaben. Für den zeitlichen Ablauf des Projekts wurden grobe Schätzungen angestellt, die jedoch ohne Bezug zur Planung der laufenden Arbeit blieben. Nachdem das Projekt erkennbar in Verzug geraten war, wurde von der Geschäftsleitung ein Angehöriger der Organisationsabteilung mit dem Projektmanagement beauftragt. Dieser versuchte eine systematische Bestimmung des Volumens einzelner Arbeitspakete, um daraus ein Raster von Zeitvorgaben abzuleiten. Dieser Versuch einer Außensteuerung des Projektmanagements schlug fehl. Er führte zu Konflikten mit der Projektleitung und wurde nicht konsequent in die Projektpraxis umgesetzt. Als Konsequenz wurde nun ein Mitarbeiter des Projektteams mit dem Projektmanagement betraut. Dies führte zwar zu einer Reduzierung der Konflikte, nicht jedoch zu einer systematischen Projektsteuerung und -kontrolle.
Feste und verbindliche Muster fehlten weitgehend
Insgesamt vermittelte das Management in vielen Projekten den Eindruck, daß feste, verbindliche Muster für das Vorgehen noch weitgehend fehlten und daß man sich in einem eher experimentellen Zustand befand. Ohne klares Konzept bewegte man sich zwischen den sich widersprechenden Anforderungen einer flexiblen, an den jeweiligen Gegebenheiten ausgerichteten Projektabwicklung und dem Versuch, das Projekt berechenbar zu halten.
Literatur:
DIN: DIN 69 901 Projektmanagement, Begriffe, 1980.
W. Hesse: Neues Denken in der Softwareentwicklung. Manuskript, Veröffentlichung in Vorbereitung, Marburg 1992.
M. Saynisch: Grundlagen des Phasenweisen Projektablaufes. In M. Saynisch, H. Schelle, A. Schub: Projektmanagement: Konzepte Verfahren, Anwendungen. München 1979.