Projekt-Management in der Praxis (Teil 9)

Schlüsselpositionen sind ein entscheidender Leistungsfaktor

29.05.1992

In den meisten Softwareprojekten, deren Ablauf wir untersuchten, waren Positionen zu erkennen, denen ganz offensichtlich eine Schlüsselfunktion zukam bei der Übermittlung von Informationen und der Koordination von Tätigkeiten, bei der Abstimmung der Belange verschiedener Bereiche oder bei der Vorbereitung von Entscheidungen. Diese Positionen waren fast durchweg überfrachtet.

Inhaber solcher Schlüsselpositionen waren meist, wenn auch nicht immer, der Projektleiter, sein Stellvertreter und häufig auch andere Mitglieder eines Kernteams von erfahrenen Softwareentwicklern. Vor allem in den größeren Projekten war das Leistungspotential der Schlüsselpositionen der eigentlich limitierende Faktor für die Leistungsfähigkeit des Gesamtteams, also die entscheidende Engstelle. Wie weit und, wie rasch es gelang, für komplexe Entwicklungsaufgaben eine Lösung zu finden, wie weit zusätzliche, unter Umständen noch unerfahrene Teammitglieder in den Entwicklungsprozeß integriert und produktiv werden konnten, hing letztlich von der Leistungskapazität dieses Kernteams ab.

Besprechungen fordern ein Drittel der Arbeitszeit

Dies war abzulesen an den subjektiven Selbst- oder Fremdeinschätzungen, an der längeren Arbeitszeit der Inhaber dieser Positionen, an ihren Schwierigkeiten, über diese zu disponieren, an den vielen Sitzungen und Besprechungen.

Projektleiter machen, so ergab die Erhebung des arbeitspsychologischen Teilprojekts, im Durchschnitt 6,3 Überstunden pro Woche (Entwickler 2,9), sie verbringen ein Drittel der Arbeitszeit in Sitzungen und Besprechungen, überwiegend mit Mitgliedern des Projektteams (Entwickler 16 Prozent), und 28 Prozent ihrer Zeit mit organisatorischen und administrativen Tätigkeiten (Entwickler 4 Prozent).

Die Überfrachtung konnte auch abgeleitet werden aus den Klagen im Umfeld dieser Positionen, die auf eine unzureichende Wahrnehmung einzelner Funktionen schließen ließen. So wurde nicht selten von unterstellten Mitarbeitern über das Fehlen von Informationen oder Anleitung, den Mangel an Koordination der Tätigkeiten im Team, die Verzögerung fälliger Entscheidungen und insgesamt über den Mangel an zeitlicher Verfügbarkeit ihres Chefs geklagt. Als Folgen dieser Defizite wurden Schwächen in der konzeptionellen Gestaltung des Entwicklungsvorhabens ausgemacht, Mangel an Koordination der Tätigkeiten der am Vorhaben Beteiligten oder Mangel an Abstimmung mit den Forderungen der Anwender.

Diese Defizite waren zumeist nicht so sehr oder nicht allein auf persönliche Schwächen, sondern eher auf eine strukturelle Überfrachtung dieser Positionen zurückzuführen. Die Gefahr solcher Überfrachtung ergab sich zunächst einmal schon aus der Notwendigkeit der Integration arbeitsteiliger Gestaltungsprozesse. Wir haben in der ersten Folge auf die Komplexität als Problem der Softwareentwicklung hingewiesen, aus ihr resultiert ein Spannungsverhältnis zwischen der Notwendigkeit zu arbeitsteiliger Organisation der Entwicklung einerseits und der Notwendigkeit zur Integration andererseits. Aus diesem Spannungsverhältnis ergibt sich zugleich eine quasi naturwüchsige Tendenz zur Konzentration bestimmter Funktionen auf eine oder eine kleine Zahl von Mitgliedern des Entwicklungsteams - und eben auch zu deren Überlastung. Dies gilt um so mehr, je größer das Projekt, je komplexen die Entwicklungsaufgabe und je arbeitsteiliger deren Bearbeitung organisiert ist. Jede Arbeitsteilung, jedes Delegieren von Teilaufgaben erzeugt zugleich einen Bedarf an Koordination und Integration. Es vergrößert damit die Bedeutung der Schlüsselposition. "Jemand muß das Ganze ja im Kopf haben."

Mit dieser inhaltlichen Gestaltungsfunktion war aber nur ein Teil der integrativen Aufgaben umrissen. Daneben erforderte vieles andere in großen, arbeitsteiligen Projekten ein zentrales Projektmanagement im Sinne einer koordinierenden Steuerung und Kontrolle der Aktivitäten der Beteiligten.

Schließlich gab es noch einen dritten Aufgabenkomplex, der in solchen Schlüsselpositionen wahrgenommen werden mußte. Man könnte ihn als politische Funktion bezeichnen: die Vertretung des Projekts im Unternehmen oder gegenüber dem Auftraggeber, die Durchsetzung von Gestaltungvorschlägen, die Sicherstellung des Konsenses und des Informationstransfers zwischen dem Entwicklungsbereich und den Auftraggeber- beziehungsweise Anwenderbereichen.

Breites Spektrum von Anforderungen

Das Ausüben dieser Funktionen war in der Regel sehr zeitaufwendig. So erforderte die inhaltliche Koordination die aktuellen Kenntnisse über den jeweiligen Entwicklungsstand und die Ausführung in den einzelnen Teilkomplexen. Die Wahrnehmung der ablaufbezogenen Steuerungsfunktion wie der politischen Funktion erwies sich als außerordentlich besprechungs- und sitzungsintensiv.

Jede dieser Funktionen für sich, insbesondere aber ihre Kombination, erforderte also erheblichen Zeitaufwand. Meist ergab sich auch ein recht breites, nicht selten in sich widersprüchliches Spektrum von Anforderungen.

So können bei der inhaltlichen Gestaltungsaufgabe technik-immanente Anforderungen im Vordergrund stehen, bei der politischen Funktion dagegen Fragen der Durchsetzbarkeit oder der "Akzeptanz". Solche Widersprüche machten sich vor allem in jenen Positionen bemerkbar, die eine Scharnierfunktion zu erfüllen hatten, etwa die Abstimmung zwischen Entwicklungs- und Auftraggeberbereich.

Entsprechend breit war auch das Spektrum der Qualifikationen, das in solchen Positionen gefordert wurde: Neben technikbezogenem Fachwissen auch Kenntnisse über den jeweiligen Einsatzbereich der zu entwickelnden Software, außerdem soziale Qualifikationen, Kreativität und analytische Fähigkeiten. Zu der zeitlichen trat damit auch häufig eine qualifikatorische Überforderung. So scheint viel dafür zu sprechen, diese einzelnen Funktionen verschiedenen Positionsinhabern zuzuordnen und auch Scharnierfunktionen aufzuteilen. Dies sollte so ließ sich erwarten, die zeitliche Beanspruchung reduzieren, vor allem aber Widersprüche in den Anforderungen vermeiden helfen.

Mit unterschiedlichen Lösungsansätzen wurde in den von uns untersuchten Projekten versucht, das Problem der Schlüsselpositionen in den Griff zu bekommen:

- Verteilen der Projektleitung auf zwei Projektmanager. Der eine nimmt vorwiegend die "politische" Funktion der Vertretung des Projekts nach außen und dessen administrative Abwicklung wahr. Dem anderen obliegt vorwiegend die Anleitung und Koordination der Arbeit der Entwickler.

- Weitgehend informelle Aufgabenteilung zwischen dem Projektleiter, der sich vor allem der "politischen" Durchsetzung des Projekts widmet, und seinem Stellvertreter, der sich auf die, konzeptionelle Gestaltung und die Koordination der Entwicklungsarbeiten konzentriert.

- Der Projektleiter agiert in einem kleinen Kernteam von drei oder vier sehr qualifizierten und eingearbeiteten Entwicklern als Primus inter pares. Formal liegt zwar die Funktion der Projektleitung bei ihm, de facto sind deren Einzelfunktionen jedoch im Kernteam aufgeteilt. Einzelne Mitglieder des Kernteams betreuen weniger qualifizierte Entwickler bei ihrer Arbeit.

- Neben dem offiziellen Projektleiter fungiert ein hochqualifizierter Entwickler faktisch, wenn auch weitgehend informell, als Chefprogrammierer. In seinen Händen liegen die Konzipierung des Gesamtentwurfs sowie die Ausführung der schwierigeren Entwicklungsarbeiten. Er weist den anderen Mitgliedern des Entwicklungsteams ihre Aufgaben zu und leitet sie an.

- Der Projektleiter wird bei seiner Tätigkeit durch einen Angehörigen einer externen Abteilung (Organisation, Controlling) unterstützt. Die Funktion des Projektmanagements wird also externalisiert.

Jede dieser Formen organisatorischer Aufgliederung der Schlüsselfunktionen hat spezifische Vor- und Nachteile beziehungsweise Gefahren. Grundsätzlich zeigte sich, daß einer Aufteilung der Schlüsselfunktionen doch relativ enge Grenzen gesetzt sind; denn jede Funktionsteilung erzeugt ihrerseits wieder zusätzlichen Bedarf an Information, Kooperation und Abstimmung. Ein Beispiel: Die Wahrnehmung der Gestaltungsintegration und der politischen Vertretung eines Projekts werden auf verschiedene Personen verteilt. Die Gestaltungsfunktionen können nur mit genauer, aktueller Kenntnis des jeweiligen "politischen" Stands eines Projekts wahrgenommen werden. Umgekehrt erfordert etwa die Vertretung nach "außen" eine sehr präzise Vertrautheit mit den Gestaltungsfragen. Zu starkes Aufsplittern der zentralen Funktionen eines Entwicklungsprojekts zieht also neue Koordinations- und Abstimmungsprobleme nach sich. Unter Umständen wiegen sie die Entlastung auf.

Es gilt also - insbesondere bei umfangreicheren Projekten - ein Optimum zwischen Aufsplitterung und Zentralisierung der Schlüsselfunktionen zu finden. Hierfür gibt es kein Patentrezept, die Lösung wird je nach den personellen Gegebenheiten, der Gestaltungsaufgabe, dem Umfang wie auch dem "politischen" Umfeld anders aussehen müssen.

Das Beispiel eines erfolgreichen Projekts

Das untersuchte Projekt wird in einem Softwarehaus mit etwa 500 Beschäftigten durchgeführt. Dieses Haus arbeitet für externe Auftraggeber, entwickelt aber auch eigene Softwareprodukte und vertreibt sie auf dem Markt. Auftraggeber ist ein großes öffentliches Unternehmen, für das das Softwarehaus schon mehrmals tätig war. Das Projekt schließt zeitlich an ein anderes für denselben Auftraggeber an, so daß das Projektteam geschlossen übernommen werden kann.

Grundlage für die Entwicklungsarbeiten ist zunächst ein Fachkonzept, das vom Auftraggeber vorgegeben wird, ein Konvolut von zehn Aktenordnern. Dieses ist in einem viereinhalbjährigen Prozeß der Auseinandersetzung beim Auftraggeber entstanden. Aus der Sicht des Entwicklungsteams weist, dieses Fachkonzept erhebliche Mängel auf, die Nachbesserungen erforderlich machen. Diese "Ergänzungen" werden in einer Arbeitsgruppe erarbeitet, die zu diesem Zweck gebildet wird. In ihr sind einerseits der Auftraggeber durch Angehörige seiner Organisationsabteilung, andererseits Mitglieder des Entwicklungsteams vertreten. In mehreren Sitzungen in 14-tägigem Turnus werden nacheinander die einzelnen Themenbereiche bearbeitet und verabschiedet. So entsteht im Lauf eines halben Jahres ein von beiden Seiten als tragfähig anerkanntes Fachkonzept.

Anschließend wird ein - DV-technisches Konzept ausgearbeitet, in dem das Fachkonzept in technische Vorgaben für die Systementwicklung übersetzt wird (Systemstruktur, Datenbankentwurf etc.). Auf die ausführliche und sorgfältige Ausarbeitung dieses DV-technischen Konzepts wird großes Gewicht gelegt. Es werden sehr genaue, detaillierte Konsistenzprüfungen durchgeführt. Man nimmt sich für diese Arbeiten sehr viel Zeit, die Systemkonzeption wurde im Team ausdiskutiert, bis Konsens hergestellt ist. Dies ist angesichts des verzögerten Beginns der Entwicklungsarbeiten psychologisch nicht einfach, erweist sich jedoch im weiteren als äußerst wichtig für die erfolgreiche Durchführung des Projekts.

Solche Konsistenzprüfungen beziehungsweise Diskussionen im Team werden dann in einer Serie von Reviews über den gesamten Projektverlauf sehr konsequent fortgesetzt. Diese dienen nicht nur der Qualitätssicherung, sondern trägen auch zur laufenden Konsensbildung im Entwicklungsteam bei. An den Reviers nehmen jeweils der "Autor" der Software, der Projektleiter, ein weiterer Entwickler aus dem Team, fallweise auch ein Experte, der nicht dem Team angehört, und der Projektmanager teil.

Insgesamt werden während der dreijährigen Projektlaufzeit 60 solcher Reviews durchgeführt. Sie beanspruchen etwa zehn Prozent des Arbeitsvolumens. Diese Zeit ist in der Projektkalkulation bereits veranschlagt worden.

Es wird großer Wert darauf gelegt, dem Kunden möglichst bald Subsysteme, die praktisch angewandt werden können, zur Verfügung zu stellen. Dieses Verfahren zeitversetzter Ausarbeitung von Subsystemen unterscheidet sich vom orthodoxen Prototyping dadurch, daß die erarbeiteten Lösungen keine "Wegwerfprodukte" sind, sondern durchaus der weiteren produktiven Nutzung dienen.

Voraussetzung für diese Aufteilung in Subsysteme ist sorgfältiges Erarbeiten des technischen Grobkonzepts, so daß auf dieser Ebene im weiteren Projektverlauf kaum noch Änderungen notwendig werden. Zwar ergeben sich bei der Programmierung einzelner Subsysteme gelegentlich Rückwirkungen auf das Gesamtkonzept; sie stellen dessen Grundcharakter aber nicht in Frage.

Relativ hohe Fluktuation

Der Personaleinsatz im Projekt ist durch starke Schwankungen und relativ hohe Fluktuation gekennzeichnet. Insgesamt sind 20 Mitarbeiter eingesetzt. Die Projektleitung wechselt dreimal.

In der ersten Phase steigt der Personalstand von anfänglich zwei auf schließlich 13 Mitarbeiter, die gleichzeitig am Projekt tätig sind. Allerdings ist über die gesamte Laufzeit ein Kernteam von fünf Mitarbeitern im Projekt tätig. Angehörige dieses Kernteams sind für bestimmte Querschnittsaufgaben (Steuerungssystem, Datenbank etc.) und einzelne Subsysteme zuständig. Die anderen Mitarbeiter sind überwiegend mit begrenzteren Teilaufgaben betraut; sie werden von Angehörigen des Kernteams eingewiesen und betreut.

Die starken Schwankungen in der Personalstärke und Zusammensetzung des Projektteams sind unter anderem Folge des modularen Aufbaus der Systementwicklung. Bei den einzelnen Subsystemen läßt sich relativ gut zusätzliches Personal einsetzen, um die Bearbeitung zu beschleunigen.

Abwicklung und Ergebnis des Projekts werden im Unternehmen positiv bewertet. Erfolgskriterien sind die Einhaltung des vorgegebenen Termin- und Budgetrahmens, der reibungslose Anlauf des Systems beim Auftraggeber und die geringe Zahl von Korrekturanforderungen. Diskussion. Wesentliche Voraussetzungen für den Erfolg des Projekts sind:

- Durch das konsequente Aufteilen der Entwicklungsarbeiten in Subsystemen ist es möglich, sehr rasch an einzelnen Anwendungen anschaulich die Funktionsweise des Systems zu demonstrieren. Dabei kann man mit dem Auftraggeber grundsätzliche Fragen (etwa zum Maskenaufbau, Felderaufteilung etc.) diskutieren. Dies führt sehr frühzeitig zu einem stabilen Einverständnis mit dem Auftraggeber, das sich dann für das weitere Vorgehen als sehr wichtig erweist.

- Diese modulare Vorgehensweise wird erleichtert durch die Existenz eines stabilen Kernteams, das sich vorn Vorprojekt her bereits kennt, aufeinander eingespielt ist und während der ganzen Laufzeit des Projekts zusammenbleibt. In der vorangegangenen Zusammenarbeit haben sich fachliche Schwerpunkte herausgebildet (zum Beispiel Steuerungskonzept, Datenbank), die nun in dem neuen Projekt beibehalten werden können, Besonders für die rasche Konsensbildung über das technische Grundkonzept zu Beginn des Projekts erweist sich dies als wichtig. Es gelingt sehr rasch, sich im Projektteam auf eine tragfähige Systemstruktur zu einigen und auch den Auftraggeber von dieser zu überzeugen. Dabei hilft es natürlich, daß man im starken Maß auf Erfahrungen und Vorarbeiten im Vorprojekt zurückgreifen kann.

Grundstruktur muß ausführlich diskutiert werden

Als sehr wichtig wird angesehen, daß man sich am Anfang die Zeit nimmt, diese Grund. Struktur ausführlich im Team zu diskutieren.

- Dieser Konsens im Kernteam kann bis zum Projektende erhalten bleiben. Dazu tragen wesentlich die zahlreichen Reviews bei, die sehr konsequent und kontinuierlich durchgeführt werden.

- Dieses Kernteam "verkraftet" auch die beträchtliche Fluktuation der sonst im Projekt beschäftigten Mitarbeiter. Es gelingt, die neuen Mitarbeiter relativ rasch produktiv in die Entwicklungsarbeit einzubeziehen und auch bei Personalwechsel eine gewisse konzeptionelle und inhaltliche Kontinuität zu wahren, selbst dort, wo diese nur wenige Monate im Projekt tätig sind.

Daß dieser Projekttyp unter den untersuchten Projekten kaum vertreten war, hing mit den Auswahlkriterien unserer Untersuchung zusammen: Es wurden überwiegend Entwicklungsvorhaben einbezogen, denen im Unternehmen ein gewisser Stellenwert zugewiesen wurde. Natürlich gab es in diesen Unternehmen meist auch solche kleineren Projekte, vor allem im Bereich der laufenden Weiterentwicklung und Pflege bereits eingesetzter Systeme.

(wird fortgesetzt)

*Professor Friedrich Weltz ist Geschäftsführer der Sozialwissenschaftlichen Projektgruppe, München, und Honorarprofessor an der Universität Göttingen; Rolf Ortmann ist Mitarbeiter der Sozialwissenschaftlichen Projektgruppe, München