Ein Team besteht aus mehreren Personen, die aufgabenorientiert zusammenarbeiten und eine gemeinsame Leistung erbringen sollen. Dabei wirken sich die Handlungen eines einzelnen Teammitglieds auf den Erfolg des gesamten Teams aus. Die Teammitglieder stehen in persönlichem Kontakt und kommunizieren direkt miteinander (Patzak; Rattay, 2004).

Projektarbeit ist immer auch Teamarbeit. Gute Teamarbeit wirkt sich positiv auf das Projektergebnis aus. Um ein gutes Projektteam zusammenstellen zu können, muss man zunächst verstehen, was gute Teamarbeit ausmacht. Welche Merkmale kennzeichnen ein gutes Team? Welche Rahmenbedingungen muss ein Projektleiter schaffen, damit die Mitglieder eines Teams erfolgreich zusammenarbeiten können? Was sollte der Projektleiter bei der Teambildung beachten? Auf diese Fragen gibt der vorliegende Beitrag praxiserprobte Antworten.

Nach der Vorstellung von jeweils einem Negativ- wie auch einem Positivbeispiel aus meinem Projektalltag werden anhand dieser beiden Beispiele acht Kriterien vorgestellt, welche gute Teams von schlechten unterscheiden. Dabei wird sich zeigen, dass die innere Teamstruktur sowie sich ergänzende Charakteristiken der Teammitglieder ein zentraler Erfolgsfaktor für gute Teams sind. Dieses Konzept wird anhand des Rollenmodells von Belbin (Belbin, 2010) näher erläutert und auf die beiden Projektbeispiele angewendet.

Beispiel 1: Ein Internet-Projekt in der Medienbranche

Einen meiner ersten Projekteinsätze hatte ich als Software-Entwickler bei der Entwicklung eines Internetauftritts in der Medienbranche. Zu Beginn führte der Projektleiter mit mir ein etwa halbstündiges Einzelgespräch und erklärte mir meine Aufgaben. Danach zeigte er mir ca. fünf Minuten lang das Großraumbüro, in dem die Projektmitarbeiter saßen. Dabei stellte er mir meine wichtigsten Ansprechpartner – den Software-Architekten, den Teilprojektleiter sowie zwei Entwicklerkollegen – kurz vor. Der Rundgang endete an meinem neuen Arbeitsplatz, indem der Projektleiter mich aufforderte, umgehend mit der Entwicklung zu beginnen. So sollte ich meinen Teil dazu beizutragen, den bereits bestehenden Terminverzug des Projekts aufzuholen. Damit der geplante Endtermin eingehalten werden konnte, wurden in den kommenden Wochen sukzessive noch weitere Entwickler eingestellt – zu Spitzenzeiten arbeiteten ca. 50 Entwickler im Projektteam.

Da es nicht einfach war, eine ausreichende Anzahl entsprechend qualifizierter Entwickler zu finden, wurden sie von verschiedenen IT-Dienstleistern "eingekauft". Über einen längeren Zeitraum kamen sie so nach und nach ins Projekt und nahmen unverzüglich ihre Arbeit auf.

Ein gemeinsames Kick-off gab es nicht. Auch verzichtete der Projektleiter auf eine regelmäßige Abstimmung im Team. Es fanden lediglich Ad-hoc-Meetings statt, wenn ein Problem auftrat, das es zu lösen galt. Sowohl der Projektleiter als auch der Kunde vertraten die Auffassung, dass in Meetings nur geredet und dadurch nicht produktiv gearbeitet würde. Wer Informationen für seine Arbeit bräuchte, könne sich diese ja beim zuständigen Ansprechpartner holen. Am besten per E-Mail, denn dann konzentriere man sich "auf die Sache" und die ausgetauschten Informationen seien auch gleich nachvollziehbar dokumentiert.

Der Zusammenhalt im "Team" war sehr schlecht. Außer "dem Termin", d.h. dem geplanten Produktiv-Setzen des Internet-Auftritts, war kein Ziel vorgegeben oder bekannt und auch für dieses oberste Terminziel kursierten unterschiedliche Daten. Aufgrund der resignativen Atmosphäre im Team hatte aber niemand den Willen, diese offensichtlichen Widersprüche zu klären: Jeder versuchte einfach, seine Arbeitspakete so schnell wie möglich abzuarbeiten. Um das anspruchsvolle Arbeitspensum möglichst "effizient" zu erbringen, reduzierten die Teammitglieder den informellen Austausch auf ein Minimum. Entwickler, die ihre Arbeit persönlich abstimmen wollten, wurden von ihren Kollegen als "Störenfriede" angesehen, die den eigenen Arbeitsfortschritt behinderten.

So gab es zahlreiche offene und verdeckte Konflikte im Team, welche die Stimmung zusätzlich beeinträchtigten. Im Falle von auftretenden Problemen oder Fehlern, wie z.B. nicht zusammenpassenden Schnittstellen, orientierte man sich an dem (schlechten) Vorbild des Projektleiters und ermittelte zunächst der Verursacher anstatt sich auf die Lösung des Problems zu konzentrieren. Dieser hatte dann den Fehler zusätzlich zu seinen anderen Aufgaben zu beheben, unabhängig von seiner Qualifizierung für die dazu notwendigen Tätigkeiten.

Die erfahreneren Entwickler konnten ihre Arbeitspakete termingerecht und mit ausreichender Modulqualität abschließen. Allerdings passten die einzelnen Module in den seltensten Fällen zusammen, da sich die Entwickler untereinander nicht ausreichend abgestimmt hatten. Dieser Umstand machte aufwändige Nacharbeiten erforderlich. Unerfahrene Entwickler schafften ihr Arbeitspensum in der Regel nicht und wurden sehr schnell ausgetauscht.

Mit der Zeit bildeten sich einzelne "Grüppchen" innerhalb des Projekts, die sich ihre eigenen Ziele setzten und ihre eigenen Regeln vereinbarten. Die Gruppe, der ich mich anschloss, entwickelte z.B. den Ehrgeiz, für möglichst wenige Nacharbeiten verantwortlich gemacht zu werden – natürlich auf Kosten der anderen Gruppen. So strebte jede Teilgruppe an, das eigene Arbeitsumfeld zu Lasten des Projekts zu optimieren.