Was macht ein gutes Projektteam aus?

Damit ein Projekt erfolgreich ist, müssen die Projektmitarbeiter gut zusammenarbeiten. Doch welche Voraussetzungen müssen gegeben sein, damit die Zusammenarbeit im Team gelingt? Und wie muss sich ein solches Team zusammensetzen? Dr. Matthias Eberspächer stellt anhand von zwei Beispielen aus seinem Projektalltag acht Kriterien vor, welche gute Teams von schlechten unterscheiden. Ergänzend dazu zeigt er mit Hilfe der komplementären informellen Teamrollen von Belbin, warum das eine Projekt scheiterte und das andere zu einem guten Abschluss gebracht werden konnte.

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

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 14 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link