Die Planung und Gestaltung des Personaleinsatzes ist für den Erfolg von Softwareprojekten von erheblicher Bedeutung, nicht nur unter Kosten und Terminaspekten, auch für deren inhaltliches Ergebnis. Das wurde in unserer Untersuchung immer wieder erkennbar.

Der Personaleinsatz in den meisten untersuchten Projekten zeichnete sich durch beträchtliche Schwankungen im Projektverlauf aus. Je Projekt waren im Durchschnitt insgesamt etwa 16 Entwickler beschäftigt, von denen aber nur fünf Entwickler über die ganze Projektdauer eingesetzt waren. Der Personalstand der Projektteams schwankte zwischen einem durchschnittlichen Minimum von fünf Entwicklern (meist zu Projektbeginn) und einem Maximum von 11 Entwicklern und lag bei Projektende bei knapp sieben Entwicklern.

Diese Zahlen müssen auf dem Hintergrund der Anforderungen gesehen werden, mit denen der Personaleinsatz in den untersuchten Projekten konfrontiert war:

- Steuerung des Personalaufwands: Es galt, den Personalaufwand -und damit die Projektkosten - berechenbar und steuerbar zu halten. Dies wurde erschwert durch die häufigen Neubestimmungen der Entwicklungsaufgabe im Projektablauf, die Konsequenzen für das Arbeitsvolumen hatten, und durch immer wieder auftretende Verzögerungen. Eine verbindliche Vorherbestimmung des Umfangs größerer Arbeitspakete und des erforderlichen Personalbedarfs war so kaum möglich. In den meisten Projekten waren deshalb kontinuierlich Anpassungen notwendig.

- Bereitstellung und Auslastung der Personalressourcen: Einerseits galt es, die für die Durchführung des Projekts notwendigen Personalressourcen bereitzustellen, und andererseits, verfügbares Personal auszulasten. In fast allen Projekten, in Softwarehäusern wie in Anwenderunternehmen, war der Personaleinsatz nicht allein durch die Anforderungen, die sich aus dem jeweiligen Projekt ergaben, bestimmt, sondern auch durch die Verfügbarkeit des vorhandenen Personals. Personaleinsatz ohne Restriktionen, sozusagen auf der grünen Wiese, war nur in Ausnahmefällen möglich. Das galt für die Rekrutierung von außen: Geeignete Anwärter standen häufig nicht zu dem Zeitpunkt zur Verfügung, zu dem sie im Projekt gebraucht wurden. Dies galt insbesondere für die Rekrutierung von Personalressourcen innerhalb des Unternehmens.

Projekte waren fast durchweg eingebunden in ein Umfeld vorangegangener, parallellaufender und nachfolgender Aktivitäten, durch die das in Frage kommende Personal in Anspruch genommen wurde. Personaleinsatzplanung hieß also nicht nur: "Wen brauche ich für welche Aufgaben", sondern auch, "Wer steht wann zur Verfügung". Ökonomische Aspekte legten eine möglichst "dichte" Beschäftigung der Mitarbeiter nahe, also die Vermeidung von Intervallen zwischen einzelnen Aufgaben. Solch ökonomische Planung des Personaleinsatzes wurde allerdings häufig dadurch erschwert, daß Projekte oder andere Aktivitäten nicht termingerecht abgeschlossen wurden, daß sie noch Nachaktivitäten erforderten und damit Personal nicht zum vorgesehenen Zeitpunkt zur Verfügung stand.

- Berücksichtigung der besonderen qualifikatorischen Anforderungen: Wieder bestanden Anforderungen in zweifacher Richtung: Sicherzustellen, daß Qualifikationen dort, wo sie im Projekt gebraucht wurden, auch zur Verfügung standen, und andererseits dafür zu sorgen, daß die Mitarbeiter ihren Qualifikationen gemäß eingesetzt wurden.

Eine spezifische Mischung von Qualifikationen

Jedes Projekt erforderte- eine spezifische Mischung technischer und anwendungsbezogener Kenntnisse, von Fähigkeiten, unstrukturierte Sachverhalte analytisch zu durchdringen und zu ordnen, allgemein logische Strukturen in Programme zu übersetzen und diese zu gestalten, sowie von sozialen Qualifikationen im Umgang mit den Anwendern oder auch innerhalb des Entwicklungsteams.

Nur relativ selten konnte davon ausgegangen werden, alle notwendigen Qualifikationen in einer Person vereint vorzufinden. Es kam also in der Regel darauf an, in den Projektteams Entwickler mit komplementären Stärken zusammenzubringen, so daß diese sich in ihrer Arbeit ergänzten. Dabei ging es nicht allein um die technischen Spezialisierungen, sondern vor allem auch um individuelle Neigungen und Starken. Erschwert wurde eine solche Zusammenstellung der Projektteams durch die Tatsache, daß im Projektablauf sich die jeweils geforderten Qualifikationen verschoben: von der Fähigkeit in der Frühphase der Projekte, umfangreiche, komplexe und unstrukturierte Zusammenhänge zu durchdringen, zu programmtechnischer Ingenuität in der Realisierungsphase.

Erforderlich war also ein projekt- und phasenspezifischer "Qualifikationsfit", das heißt eine Entsprechung der im Projektteam verfügbaren Qualifikationen und der jeweiligen Arbeitsanforderungen. Die quantitative und qualitative Zusammensetzung des Projektteams, die unter Arbeitsaspekten erforderlich beziehungsweise sinnvoll war, konnte so von Projektphase zu Projektphase sehr stark variieren.

Viele Projekte begannen in den frühen Phasen der Analyse und Konzeptualisierung mit einem verhältnismäßig kleinem Team, das dann in den Realisierungsphasen mehr oder minder stark aufgestockt wurde um schließlich in den abschließenden Test- und Umsetzungsphasen wieder reduziert zu werden.

- Sicherstellung, daß Qualifikationen zum Tragen kommen beziehungsweise entfaltet und entwickelt werden: Wie viele Entwickler zum Gelingen eines Projekts beitrugen, hing nicht nur von den Qualifikationen ab, über die sie verfügten, sondern wesentlich auch davon, wie sie diese nutzen und weiterentwickeln konnten. Neben qualifikatorischen und arbeitsorganisatorischen Maßnahmen (Einweisung, Einarbeitung, Arbeitszuteilung und -aufteilung etc.) war hier auch die Gestaltung des Personaleinsatzes im eigentlichen Sinn gefordert. Die Kontinuität beziehungsweise Diskontinuität der personellen Besetzung eines Projekts war offensichtlich ein wesentlicher Erfolgsfaktor.

Jeder Personalwechsel war mit schwer kalkulierbaren, meist hohen Verlusten an Erfahrungen, Hintergrundwissen und Know-how verbunden, das nur schwer vollständig weiterzuvermitteln war, auch nicht durch die gründlichste Dokumentation.

Für die Zusammenarbeit im Team wie die Konsensbildung erwiesen sich stabile Personalstrukturen ebenfalls als förderlich: Man wußte voneinander, was man konnte und nicht konnte, hatte sich auf bestimmte Verfahrensweisen verständigt etc. Umgekehrt trug ein gezielter Wechsel in der Zusammensetzung von Projektteams auch dazu bei, Schwierigkeiten und Blockierungen, die sich im Projektverlauf gezeigt hatten, aufzulösen.

- Damit wuchsen dem Personaleinsatz auch Funktionen im Zusammenhang mit dem Konfliktmanagement bei der Projektabwicklung zu. Spannungen und Konflikte in den Projektteams, vor allem aber auf der Ebene der Führungsfunktion, wurde durch personelle Umsetzungen zu begegnen gesucht.

Der Personaleinsatz hatte sich also mit einer Vielzahl von Anforderungen auseinanderzusetzen, mit teilweise widersprüchlichen Gestaltungskonsequenzen. Wo unter qualifikatorischen Gesichtspunkten Kontinuität wünschenswert erscheinen mochte, führte das Bestreben, verfügbares Personal möglichst ohne Unterbrechungen auszulasten, dazu, daß eingespielte Teams auseinandergerissen und Entwickler mit Aufgaben betraut wurden, für die sie wenig qualifiziert waren.

Qualifikationen sollten auch zum Tragen kommen

In einem großen Teil der Projekte war Personaleinsatz gekennzeichnet durch eine einseitige Ausrichtung an der Auslastung von Personalressourcen und durch eine Vernachlässigung des "Qualifikationsfits" und vor allem der Sicherstellung, daß Qualifikationen auch zum Tragen kommen und weiterentwickelt werden konnten.

Diese Orientierung führte dann letztlich zu einer unökonomischen Nutzung der verfügbaren Personalressourcen - und stellte damit die ihr zugrundeliegenden Ziele selbst in Frage. Die Steuerung des Personaleinsatzes verlangte die ausgewogene Berücksichtigung der unterschiedlichen Anforderungsdimensionen und vor allem ihrer Interdependenz. Ob die rein rechnerische Auslastung von Personalkapazitäten wirtschaftlich wirklich Sinn machte, hing wesentlich davon ab, in wieweit gesichert war, daß die organisatorischen und qualifikatorischen Voraussetzungen auch produktiv zum Tragen kommen konnten.

Eben diese Voraussetzungen waren vielfach nicht gegeben:

- Projekte wurden, mit unerfahrenen, unzureichend qualifizierten Mitarbeitern begonnen ohne daß ausreichende Personalkapazitäten für deren Einarbeitung zur Verfügung standen.

- Projekte wurden zwar mit kompetentem Personal begonnen, wichtige Voraussetzungen, daß dieses auch produktiv tätig sein konnte, fehlten jedoch (etwa verbindliche Konzepte oder Vorgaben).

- Projekte wurden mit Personal begonnen, das gerade zur Verfügung stand, jedoch dann bald wieder zu anderen Aufgaben abgezogen und durch andere Entwickler ersetzt wurde.

- Projektteams wurden während der Laufzeit des Projekts in Reaktion auf aufgetretene Verzögerungen und Ausweitung der Aufgabenstellung stark aufgestockt, ohne daß die Voraussetzungen für einen produktiven Einsatz dieser Entwickler gesichert waren. Der Personalstand mancher Projekte glich einer Fieberkurve, die weniger die tatsächlich sinnvollen Einsatzmöglichkeiten und Personalressourcen widerspiegelte als die sich kumulierenden Versäumnisse und Verzögerungen die Ungeduld der Verantwortlichen und deren Furcht, gesetzte Termine nicht halten zu können.

Dem Personaleinsatz wuchs häufig eine Lückenbüßerfunktion zu: Durch ihn sollten Abweichungen vom geplanten Projektverlauf, Schwierigkeiten und Verzögerungen aufgefangen werden. In mehreren Projekten wurde der Versuch gemacht, durch massiven Einsatz zusätzlichen Personals eine drohende Überziehung von Terminen zu vermeiden. In den meisten Fällen allerdings erwies sich eine solche Anwendung des "Chinesenprinzips", wie einer unserer Gesprächspartner dieses Vorgehen nannte, nur als begrenzt erfolgreich. "Mens and months are not interchangeable, nine women do not bear a child in one month" (Nocentini, S. 126). Diese Erfahrung wurde auch in den von uns untersuchten Projekten immer wieder gemacht. Der zusätzliche Einarbeitungs- und Abstimmungsaufwand, der nicht nur die neuen, sondern auch die "alten" Teammitglieder traf, neutralisierte die rechnerisch gewachsene Personalkapazität.

"So kommt es", stellt Frederick P. Brooks fest, "daß die Zeit, die der einzelne Mitarbeiter durch die Aufgabenteilung eigentlich gewonnen hatte, wieder verlorengeht" Er (F.B. Brooks, S. 17) zieht daraus den Schluß: "Der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten verzögert sie nur noch mehr." (Brooks, S. 22). Allerdings, dieses "Brooksche Gesetz" gilt nicht immer: Wir trafen auf Projekte, in denen es durchaus gelang, durch zusätzliches Personal den Entwicklungsprozeß zu beschleunigen.

In einem Projekt konnte ein festes Kernteam mit unterschiedlichen, sich ergänzenden Qualifikationsschwerpunkten von Projektbeginn über die ganze zweijährige Projektlaufzeit zusammen eingesetzt werden. Die Arbeitsteilung in diesem Team sah so aus, daß einerseits einzelne Entwickler für bestimmte übergreifende Aufgaben zuständig waren (Datenbank, Steuerungssysteme etc.), andererseits jeder der Entwickler für die Bearbeitung bestimmter Subsysteme vom Design bis zur Realisierung und zum Test verantwortlich war.

Kernteam entwickelt tragfähiges Gesamtkonzept

Bei der Bewältigung dieser Aufgaben unterstützte man sich innerhalb des Teams je nach persönlichen Vorlieben und Stärken wechselseitig. Durch die stabile Struktur des Schlüsselteams konnte über grundsätzliche Gestaltungsfragen eine relativ rasche Konsensbildung erreicht werden. Weiterhin "verkraftete" dieses Kernteam eine beträchtliche Zahl von Mitarbeitern, die nur zeitweise im Projekt beschäftigt waren, meist für die Bearbeitung von relativ klar begrenzter Teilaufgaben. Das Projekt lief innerhalb des gesetzten Budget- und Terminrahmens ab.

Voraussetzung dafür war die Existenz eines qualifizierten und eingespielten Kernteams, durch das ein tragfähiges Gesamtkonzept entwickelt und vertreten wurde. So konnten klar strukturierte und abgegrenzte Teilaufgaben den neuen Mitarbeitern zugewiesen und diese bei deren Bearbeitung eingewiesen und kontinuierlich betreut werden.

Solche Konstellationen, wie auch allgemein ein gelungener Personaleinsatz, waren in der Regel allerdings weniger Ergebnis gezielter und bewußt getroffener Maßnahmen als günstiger Umstände. Meist wurde der Personaleinsatz weitgehend reaktiv gehandhabt, ergab sich als Resultat scheinbar vorrangiger Sachzwänge. Eher selten wurde bei fast durchweg im Projektverer gezielt als Gestaltungsmittel des Projektmanagements aktiv genutzt, Ansätze zur gezielten Planung wurden häufig nicht konsequent durchgehalten.

Nur in etwas mehr als der Hälfte der Projekte meinten unsere Gesprächspartner, der Personaleinsatz sei überwiegend geplant und gesteuert erfolgt, wolauf dann situationsbezogene (54 Prozent) oder personalbezogene (24 Prozent) reaktive Anpassungen des Personaleinsatzes erfolgten.

In Softwarehäusern gab es zwar etwas häufiger Ansätze zu einem geplanten und gesteuerten Personaleinsatz. Reaktive situations- oder personalbezogene Anpassungen waren hier aber ebenso häufig zu finden wie in Projekten in Anwenderunternehmen.

In ähnlicher Weise unterschieden sich Großprojekte von kleineren Projekten: Einerseits wurde häufiger der Personaleinsatz vorausgeplant, andererseits waren dann in fast allen Projekten situationsbedingte Korrekturen notwendig. In kleineren und vor allem mittelgroßen Projekten wurde der Personaleinsatz zwar seltener geplant, zugleich waren aber auch erheblich seltener Anpassungen notwendig.

Die Folgen solch reaktiver Gestaltung des Personaleinsatzes schlugen sich im Projektablauf und im Projektergebnis nieder:

- Die Sorge um die Auslastung frühzeitig eingestellter Personalkapazitäten führte dazu, daß rasch mit dem Programmieren von Teilsystemen begonnen wurde, ohne daß die Konzepte und Anforderungen, auf die diese sich zu beziehen hatten, ausreichend geklärt waren. Das hatte entsprechend nachteilige Folgen sowohl für diese Teilsysteme wie für das Gesamtkonzept. Oder die Entwickler wurden mit Aufgaben beschäftigt, etwa Systemanalyse und Systemdesign, die dann durch die weitere Entwicklung weitgehend hinfällig wurden.

- Die starke Diskontinuität in der personellen Besetzung von Projektteams führte nicht nur zu erheblichem Zusatzaufwand, sondern auch zu Brüchen im Entwicklungskonzept.

- Häufiger Wechsel im Entwicklungsteam schwächte den Bezug zum Anwendungsfeld. Etablierte Kontakte mit Anwendern gingen wieder verloren.

Auch für die betroffenen Softwareentwickler hatten diese Formen des Personaleinsatzes vielfach Nachteile, wenn auch vereinzelt Chancen eröffnet wurden. Besonders Berufsanfänger wurden relativ rasch mit anspruchsvollen Aufgaben betraut; dies konnte, sofern sie die Aufgaben bewältigten, einen deutlichen Karriereschub mit sich bringen. In mehreren Projekten begegneten wir Entwicklern; die in kürzester Zeit zu "Experten" avanciert waren, schlicht durch die Tatsache, daß sie sich einige Zeit einer spezifischen Aufgabe gewidmet hatten. Meist aber war ein solch reaktiver Personaleinsatz mit einer Überforderung der Entwickler verbunden. Man wurde ohne adäquate Unterstützung und Vorbereitung mit schwierigen Aufgaben konfrontiert, es fehlte die Zeit und Kontinuität sich in einzelne Aufgabenkomplexe gründlich einzuarbeiten.

Insgesamt demonstrierte der Verlauf der Projekte die Notwendigkeit wie auch die Schwierigkeiten eines gesteuerten Personaleinsatzes, durch den gezielt die Voraussetzungen für den erforderlichen "Qualifikationsfit" geschaffen werden.

*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