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.

Verantwortlichkeitsmatrix - RACI-Matrix

Definieren Sie eindeutige Verantwortlichkeiten im Projekt einprägsam und klar verständlich! Geben Sie allen Stakeholdern einen schnellen Überblick, wer für was zuständig ist!

Zur Methode

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.

Der Mensch im Projekt - Was braucht er zum Wachsen, Entfalten und Schaffen?

E-Book mit 108 Seiten, 3 Methoden und einer Arbeitshilfe

Ist es Zeit für etwas Neues? Dieses Spotlight unterstützt Sie dabei: Sie erfahren, wie Sie zu einer einer ausgewogenen Work-Life-Balance gelangen, mit Gelassenheit dem Stress trotzen, sich Ihr Bauchgefühl zunutze machen oder ...

Zum E-Book

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.

Aufgrund dieser Reibungsverluste brachte das gesamte Entwicklerteam eine deutlich geringere Leistung als es der Summe der Leistungen der einzelnen Entwickler entsprochen hätte. Ein Projekttermin nach dem anderen verstrich ohne das gewünschte Ergebnis, der Projektleiter wurde zeitweise im vierwöchentlichen Rhythmus ausgetauscht, am Ende wurde das Projekt mit großem wirtschaftlichen Schaden abgebrochen.

Beispiel 2: Ein Steuerelemente-Projekt in der Automobil-Branche

Vor einigen Jahren arbeitete ich in einem Projekt zur Entwicklung eines Systems, das Fehler von elektronischen Steuerelementen in Autos analysieren sollte. Das Projektteam bestand aus drei Prozessberatern und sechs Entwicklern. Die Rollen und Zuständigkeiten wurden gemeinsam abgestimmt und aktiv gelebt. Obwohl wir, ähnlich wie in dem vorigen Projektbeispiel, auch hier mit sehr anspruchsvollen Terminvorgaben – bei gleichzeitig unklaren und häufig wechselnden Anforderungen – zu kämpfen hatten, war die Stimmung im Projektteam ausgezeichnet.

Das Team kannte die Projektziele, d.h. die Meilenstein-Termine, hergeleitet von einem allen bekannten Endtermin, die vereinbarten Leistungsumfänge und die vom Kunden geforderte Qualität, und akzeptierte sie. Es organisierte sich und seine Arbeit selbstständig als "verschworene Gemeinschaft" rund um diese Ziele. Jeder dachte für den anderen mit und auch das Erreichen kleinerer Meilensteine wurde gemeinsam gefeiert. Obwohl auch in diesem Team immer wieder projektbedingt einzelne Mitarbeiter neu hinzukamen oder ausschieden, wurde jeder neue Mitarbeiter herzlich aufgenommen und aktiv in das Team integriert. Mitarbeiter, die das Team verlassen mussten, wurden entsprechend überschwänglich verabschiedet.

In diesem Projekt erbrachte das Team gemeinsam eine größere Leistung, als es die Teammitglieder alleine vermocht hätten. Auch heute noch – Jahre nach dem erfolgreichen Abschluss des Projekts – halten die ehemaligen Teammitglieder privaten Kontakt, obwohl sie danach nie wieder gemeinsam in einem Projekt gearbeitet haben und mittlerweile zum Teil bei anderen Arbeitgebern beschäftigt sind.

Beim Internet-Projekt hingegen hatte ich schon kurze Zeit nach meinem Ausscheiden aus dem Projekt nur noch losen Kontakt zu den Mitgliedern meines "Grüppchens".

Acht Kriterien für erfolgreiche Teams

Es ist unschwer zu erkennen, dass das Team des "Steuerelemente"-Projekts effizienter gearbeitet hat als das des "Internet"-Projekts und trotz seiner deutlich höheren Leistung auch noch mehr Spaß an der Arbeit hatte. Ein solch performantes Team wünscht sich nicht nur jeder Projektleiter, auch die Projektmitarbeiter fühlen sich in einem teamorientierten Umfeld wohler als in einer Projektumgebung, in der jeder auf sich alleine gestellt ist und nur für sich "kämpft". Die ungesteuerte und selbstständige Grüppchen-Bildung im Internet-Projekt zeigt deutlich den Wunsch des Einzelnen nach Zugehörigkeit zu einem funktionierenden Team.

Doch was zeichnet erfolgreiche Teams aus? Dazu gibt es zahlreiche Ansätze in der Fachliteratur, die von den Autoren überwiegend auf Basis ihrer Praxiserfahrungen zusammengestellt wurden.

So nennt das Projektmanagement Lexikon (Motzel, 2010) als "Merkmale erfolgreicher Teams (…) ein hohes Maß an (a) Zusammenhalt ('Wir-Gefühl'), (b) Engagement und Motivation sowie (c) Ziel- und Ergebnisorientierung".

Exemplarisch für die vielen Kriterienkataloge zu diesem Thema ist die folgende Auflistung der "Merkmale erfolgreicher Teams" von Gerold Patzak und Günter Rattay (Patzak; Rattay, 2004):

• Auf eine ausgewogene Teamzusammensetzung und -struktur (fachliche und soziale Kompetenz) wird geachtet.
• Das Team genießt Unterstützung und Anerkennung von außen.
• Das Arbeitsziel ist klar definiert und wird von allen Gruppenmitgliedern verstanden und akzeptiert.
• In der Gruppe herrscht eine klare und von jedem akzeptierte Rollen- und Aufgabenverteilung.
• Der Gruppenleiter ist nicht autoritär oder dominant. Er hat eine Vermittlerfunktion; nicht sein Prestige, sondern die Aufgabe steht im Vordergrund.
• Die Atmosphäre ist informell. Jeder Beitrag wird aufgenommen und gewürdigt, alle Ansichten werden diskutiert, keine wird übergangen oder unterdrückt.
• Die Gruppendiskussion ist nicht personen-, sondern sachbezogen.
• Alle Teilnehmer können ihre Meinungen offen äußern.
• Konflikte werden im Team offen angesprochen und geklärt.
• Alle Gruppenmitglieder sind engagiert an Diskussionen beteiligt.
• Ein am Erfolg orientiertes Motivationssystem hat sich ausgebildet.
• Personen mit Entscheidungskompetenz sind eingebunden.

Aufschlussreich ist auch die Gegenüberstellung von Effektivitäts- und Ineffektivitäts-Indikatoren von Harold Kerzner (Tabelle 1).

Tabelle 1: Indikatoren effektiver und ineffektiver Teams (Kerzner, 2009) (Übersetzung des Autors).

Die drei Merkmale des Lexikoneintrags (Zusammenhalt, Engagement und Zielorientierung) lassen sich auch in den umfangreicheren Listen von Patzak, Rattay und Kerzner finden. Diese haben einen auffällig starken Fokus auf den "weichen" Faktoren, welche die Beziehungen der Gruppenmitglieder untereinander beschreiben, wie z.B. "informelle Arbeitsatmosphäre", "Konfliktfähigkeit", "sachbezogene Kommunikation", "Vertrauen" und "Zusammengehörigkeitsgefühl“.

"Härtere" Faktoren, wie Ziele, Rollen, Aufgabenverteilung, ja selbst so etwas wie "effektive Kommunikation" kann der Projektleiter direkt, notfalls durch persönliche Anweisung beeinflussen. Für die offensichtlich so wichtige Beziehungsebene seines Teams muss er förderliche Rahmenbedingungen schaffen.

Eine konsolidierte Liste von acht Kriterien, die die oben zitierten Merkmale und Indikatoren erfolgreicher Teams optimal abbilden, haben Matthias T. Meifert u.a. vorgestellt (Meifert u.a., 2010):

1. ein gemeinsames Ziel
2. gut geplante Arbeitsabläufe und Prozesse
3. zielführende Normen und Verhaltensregeln
4. geeignete Teamstruktur und Teamgröße
5. klare Rollen und komplementäre Fähigkeiten
6. konstruktive Kommunikation und Kooperation
7. starker Teamgeist und Zusammengehörigkeitsgefühl
8. ausgeprägte Leistungsorientierung

Diese acht Kriterien erlauben eine strukturierte und detaillierte Analyse der beiden Projektbeispiele.

Stakeholdermanagement

Berücksichtigen Sie die Ziele und Interessen der Stakeholder und identifizieren Sie mögliche Projektgegner! Definieren Sie gezielte Maßnahmen, um Schaden vom Projekt abzuwenden. Binden Sie Befürworter so ein, dass sie positiv auf den Projektfortschritt einwirken.

Zur Methode

1. Das gemeinsame Ziel

Im Internet-Projekt existierten widersprüchliche Aussagen von den unterschiedlichen "Grüppchen"-Leitern, "die es ja hätten wissen müssen", über das bzw. die eigentlichen Projektziele. Die einzelnen Projektmitarbeiter verfolgten nur das Ziel, das Arbeitspaket, das ihnen jeweils aktuell zugewiesen worden war, so schnell wie möglich abzuarbeiten. In einer solchen Situation braucht sich der Projektleiter nicht wundern, wenn sein Team nicht mitdenkt und ihn bei der notwendigen Feinplanung des Projekts nicht unterstützen kann.

Im Steuerelemente-Projekt hatte der Projektleiter die Projektziele zunächst mit seinem Auftraggeber abgestimmt und priorisiert. Diese Ziele stellte er dann im Rahmen des Kick-off-Workshops seinem Projektteam vor (Tabelle 2).

Tabelle 2: Die priorisierten Projektziele im Steuerelemente-Projekt.

Auch wenn diese Ziele natürlich nicht zur Diskussion standen, trug die gemeinsame Auseinandersetzung damit dazu bei, dass die Teammitglieder ein gemeinsames Verständnis von den Zielen bekamen. Dabei wurden u.a. folgende Fragen diskutiert:

• Was bedeutet es für unsere Arbeit, dass das Terminziel wichtiger ist als der Leistungsumfang?
• Ergibt sich die Kundenzufriedenheit nicht automatisch, wenn wir die anderen Ziele alle erreichen?
• Wie können wir die gewünschte Qualität möglichst schon vor der eigentlichen Testphase sicherstellen?

Aus diesen Diskussionen entwickelte das Team entsprechende Maßnahmen, um die gesteckten Ziele zu erreichen.

2. Gut geplante Arbeitsabläufe und Prozesse

Im Internet-Projekt gab es keine allgemein bekannten und dokumentierten Arbeitsabläufe oder Projektprozesse. Da die Projektleitung es nicht unterstützte, dass sich die Projektmitarbeiter untereinander abstimmten, spulte jeder Entwickler, so gut er konnte, sein eigenes "Standardprogramm" herunter. So überrascht es wenig, dass die Einzelergebnisse eine sehr unterschiedliche Qualität und keine einheitliche Architektur aufwiesen. Außerdem fanden die am Projekt beteiligten Fachbereiche sehr bald heraus, bei welchen Entwicklern sie die größten Chancen hatten, "vergessene" Anforderungen doch noch schnell nachträglich in das Projekt einzusteuern. Dies führte zu nicht geplanten Mehraufwänden und damit zu Terminverzug.

Im Steuerelemente-Projekt dagegen erarbeitete der Projektleiter zusammen mit dem Architekten und dem Senior-Berater einen ersten groben Projektplan, der die vorgegebenen Projektziele bereits berücksichtigte. In einem Teamworkshop wurde diese Planung weiter ausgearbeitet. Jedes Teammitglied erhielt hier die Möglichkeit, durch seine Planungsideen zum Gesamterfolg des Projekts beizutragen. Die ebenfalls in diesem Workshop vereinbarten Arbeitsabläufe, wie z.B. der Change-Prozess oder die projektinterne Abnahme von Arbeitsergebnissen, wurden dokumentiert. Diese Dokumentation diente hauptsächlich der späteren Einarbeitung neuer Projektmitarbeiter, denn die Teilnehmer am Teamworkshop hatten diese Prozesse ja mitgestaltet und dadurch schon verinnerlicht. Die gemeinsame Planung und Erarbeitung der Arbeitsabläufe brachte den erwünschten Nebeneffekt, dass das Projektteam nach außen geschlossen auftrat: Jeder wusste, auf wen er verweisen konnte oder an wen er eskalieren musste, wenn eine notwendige Entscheidung außerhalb seines Kompetenzbereichs lag.

3. Zielführende Normen und Verhaltensregeln

Im Internet-Projekt wurden innerhalb des Projektteams keine gemeinsamen Normen und Verhaltensregeln vereinbart. Jedes neue Teammitglied brachte eigene Wertevorstellungen und Verhaltensregeln in das Projekt mit. Da es kein abgestimmtes Wertesystem in Form von vereinbarten Normen gab, war die Zusammenarbeit der Projektmitglieder von ständigem gegenseitigen Misstrauen und Manipulationsversuchen gekennzeichnet. Beispielsweise hatte bei der Abstimmung von Schnittstellen jeder Sorge, Arbeit vom Schnittstellenpartner delegiert zu bekommen, versuchte aber auch seinerseits, die Verantwortung für eigene Arbeit zu delegieren. Dies diente dazu, sich abzusichern, um im Fehlerfall nicht als der Verursacher beschuldigt werden zu können.

Im Steuerelemente-Projekt wurden im Rahmen des Kick-off-Workshops auch Vereinbarungen zum Umgang miteinander getroffen. So beschloss das Projektteam u.a.,

• einen offenen Umgang miteinander zu pflegen, indem jeder offen seine Meinung vertreten konnte,
• abweichende Meinungen zuzulassen,
• Konflikte anzusprechen und gemeinsam zu lösen und
• alle Leistungen der Teammitglieder unabhängig von ihrem Beitrag für den Gesamterfolg zu wertschätzen.

4. Geeignete Teamstruktur und Teamgröße

Im Internet-Projekt gab es ein einziges, sehr großes Projektteam, das aus ca. 50 Mitarbeitern bestand. Außer dem Projektleiter hatte niemand den Überblick, wer alles für das Projekt tätig war. Eine erkennbare (Unter-) Struktur gab es nicht. Es fanden sich jeweils die Projektmitarbeiter zusammen, die an einem gemeinsamen Modul arbeiteten oder Schnittstellen hatten. Die Grüppchen bildeten sich in den Projektbüros hingegen aufgrund der räumlichen Nähe der Mitarbeiter, teilweise ohne jeden Bezug zur Leistung, die sie erbrachten.

Das Steuerelemente-Projekt war mit ca. zehn Projektmitarbeitern vergleichsweise übersichtlich. Allerdings gab es selbst in diesem Team eine transparente Unterstruktur: So gab es ein Kundenteam, das aus dem Projektleiter, dem Architekten und den Beratern bestand, die gemeinsam mit dem Kunden die Anforderungen und den Projektablauf abstimmten und planten, und ein Entwicklerteam, das überwiegend ohne Kundenkontakt im Projektbüro die eigentliche Produktentwicklung durchführte. Diese Projektstruktur wurde vom Projektleiter in Form eines Organigramms zusammengestellt und dem Projektteam im Rahmen des Kick-off-Workshops vorgestellt (Bild 1).

Bild 1: Organigramm des Steuerelemente-Projekts.

Teammitglieder mit Kundenkontakt sind im Organigramm blau hinterlegt, das Entwickler-Team grün. So wusste jeder Projektmitarbeiter, welche Stellung er innerhalb des Projektteams hat, mit wem er sich abstimmen und an wen er berichten musste. Bei der Zusammenstellung achtete der Projektleiter auch auf die vermuteten informellen Rollen seiner Teammitglieder (siehe Abschnitt "Das Modell der Teamrollen nach Belbin").

5. Klare Rollen und komplementäre Fähigkeiten

Im Internet-Projekt gab es keine dokumentierten Rollenbeschreibungen. Jeder neue Projektmitarbeiter besaß ein eigenes Verständnis von den verschiedenen Rollen. So kam es, dass die Entwickler, die Tester und die Mitarbeiter des Fachbereichs jeweils sehr unterschiedliche Vorstellungen hatten, wer bei der Qualitätssicherung welche Aufgaben zu übernehmen hatte. Einig waren sich Entwickler und Tester darin, dass der Fachbereich dafür verantwortlich war, die Testdaten bereitzustellen – wie sich im Projektverlauf herausstellte, war dies jedoch vertraglich anders geregelt worden!

Rollen-Canvas

Wer macht hier eigentlich was? Mit der Rollen-Canvas visualisieren Sie gemeinsam die Aufgaben, Verantwortungen und Kommunikationswege der Rollen im Projekt klar und für alle verständlich.

Zur Methode

Da die Entwickler aufgrund ihrer Verfügbarkeit nach und nach "zusammengekauft" worden waren, wurde bei der Zusammensetzung des Entwicklerteams ausschließlich darauf geachtet, dass die fachlichen Profile möglichst gut mit den Projektanforderungen übereinstimmten. Die wechselnden Projektleiter hatten vermutlich keinen oder nur sehr wenig Einfluss auf die Auswahl der Teammitglieder. Soziale Kompetenzen spielten hier keine Rolle. Bei der Größe des Projektteams wäre es aber sinnvoll gewesen, dieses bewusst in Teilteams zu untergliedern und diese Teilteams auch in Bezug auf die sozialen Kompetenzen der Projektmitarbeiter gezielt zusammenzustellen.

Im Steuerelemente-Projekt konnte der Projektleiter in gewissem Umfang die Auswahl der Projektmitarbeiter beeinflussen. Zwar gab es nur für einzelne Positionen tatsächlich mehr als einen Kandidaten. Das war aber ausreichend, um die Teamzusammenstellung auch auf Basis sozialer Fähigkeiten und vermuteter informeller Rollen zu optimieren (Mehr zu den informellen Rollen im Abschnitt "Das Modell der Teamrollen nach Belbin").

Danach konkretisierte das Projektteam die einzelnen Rollen im Rahmen des Kick-off-Workshops anhand der Rollenbeschreibungen aus dem vorgegebenen Projekt-Vorgehensmodell. Dadurch wurden zwei Ziele erreicht: Zum einen identifizierte sich jeder Projektmitarbeiter bereits zu Projektbeginn stark mit seiner Rolle, da er diese ja selbst mitgestaltet hatte. Zum anderen wusste er auch, was er von seinen Projektkollegen erwarten konnte.

6. Konstruktive Kommunikation und Kooperation

Im Internet-Projekt wurde auf Kommunikation und Kooperation kein besonders großer Wert gelegt. Die Kommunikation beschränkte sich auf den notwendigen Austausch von Sachinformationen. Kooperation gab es nur da, wo unbedingt zusammengearbeitet werden musste. Dabei versuchte jeder stets, so wenig zusätzliche Arbeit wie möglich zu übernehmen.

Im Steuerelemente-Projekt stimmte das Team bereits im Kick-off-Workshop Kommunikations- und Besprechungsregeln ab. Gemeinsame Teambesprechungen fanden dann nach diesen Regeln regelmäßig wöchentlich statt und sorgten dafür, dass das gesamte Team auf einem Stand war. Aber auch neben dieser formalen Projektkommunikation sprach das Team viel miteinander: Jeder Tag begann mit einem ca. 15-minütigen Stand-up-Meeting, in dem sich die Teammitglieder bei einem Kaffee über ihre aktuellen Tätigkeiten informierten. Häufig traf sich das Team auch abends zu gemeinsamen Aktivitäten. Sowohl die Stand-up-Meetings als auch die regelmäßigen gemeinsamen Aktivitäten etablierten sich mit der Zeit von ganz alleine – ohne dass der Projektleiter sie steuerte oder "anordnete". Da das Team gemeinsame Ziele verfolgte, war es letztlich auch egal, wer welche Arbeit erledigte. Jeder konnte sich darauf verlassen, dass jemand für ihn einspringen würde, wenn er aufgrund von ungeplanter Mehrarbeit einmal sein eigenes Pensum nicht schaffte.

7. Starker Teamgeist und Zusammengehörigkeitsgefühl

Im Internet-Projekt existierten weder Teamgeist noch Zusammengehörigkeitsgefühl außerhalb der informellen "Grüppchen". Es gab ja auch keine Basis, auf der sich dies hätte ausbilden können.

Im Steuerelemente-Projekt begriff sich das Team als "verschworene Gemeinschaft". Dies war das Ergebnis der idealen Zusammensetzung des Projektteams und der optimalen Randbedingungen, wie sie der Projektleiter und sein Team sich geschaffen hatten. Gestärkt wurde dieses Zusammengehörigkeitsgefühl sowohl durch die Atmosphäre des Vertrauens als auch durch die regelmäßigen gemeinsamen positiven Erlebnisse – sowohl in der Projektarbeit als auch im Rahmen der gemeinsamen privaten Aktivitäten.

8. Ausgeprägte Leistungsorientierung

Im Internet-Projekt gab es keine Leistungsorientierung. Jeder war froh, wenn er sein eigenes Pensum geschafft hatte. Niemand wäre auf die Idee gekommen, seine Arbeitspakete vor dem vereinbarten Termin abzuschließen, nur um zusätzliche Arbeit "für andere" zu erledigen.

Natürlich gab es auch im Steuerelemente-Projekt große Unterschiede in der Leistungsfähigkeit der einzelnen Mitarbeiter. Es versuchte jedoch jeder, sein Bestes für den gemeinsamen Projekterfolg zu geben, was vom Team – in Übereinstimmung mit den vereinbarten Verhaltensregeln – anerkannt wurde.

Bedeutung der acht Kriterien in der Teambildung

Die richtige Teamstruktur und die komplementären Fähigkeiten der Mitarbeiter (Kriterium Nr. 4 und 5) spielen bereits bei der Zusammenstellung des Teams eine Rolle. Anhand des Rollenmodells von Belbin wird im Folgenden gezeigt, worauf dabei zu achten ist. Ziele, Prozesse, Verhaltensregeln und gute Kommunikation (Nr. 1 bis 3 und 6) sollten im Rahmen der initialen Teambildung gemeinsam abgestimmt und etabliert werden. Kooperation, Teamgeist und Leistungsorientierung (Nr. 6 bis 8) sind das Ergebnis einer erfolgreichen Teamentwicklung.

Das Modell der Teamrollen von Belbin

Um besser nachvollziehen zu können, wie sich ein optimales Team zusammensetzt, ist es hilfreich zu verstehen, was mit "komplementären Fähigkeiten" und "informellen Teamrollen" in Abgrenzung zu den funktionalen Projektrollen genau gemeint ist.

Nach Belbin gibt es in jedem Team neun informelle Teamrollen, die sich aus den Verhaltensmustern der Teammitglieder ergeben (Belbin, 2010). Die Rollen des "Machers", des "Umsetzers" und des "Perfektionisten" bilden die Gruppe der handlungsorientierten Teamrollen. Der "Vorsitzende", der "Teamarbeiter" und der "Wegbereiter" bilden die Gruppe der kommunikationsorientierten Rollen. Zur Gruppe der wissensorientierten Rollen gehören der "Neuerer", der "Beobachter" und der "Spezialist" (Meifert u.a., 2010). Tabelle 3 gibt einen Überblick über das Profil dieser Rollen.

Tabelle 3: Beitrag, Stärken und Schwächen der Teamrollen nach Belbin.
Tabelle vergrößern

So wie eine funktionale Projektrolle, z.B. Entwickler, Berater oder Teilprojektleiter, kann auch eine informelle Teamrolle von mehreren Teammitgliedern besetzt sein und ein einzelnes Teammitglied kann auch mehrere Rollen übernehmen. Anders als die Besetzung der funktionalen Rollen kann eine informelle Rolle aber nicht einfach (vom Projektleiter) zugewiesen werden, sondern die Teammitglieder müssen diese eigeninitiativ besetzen und im Rahmen eines gruppendynamischen Prozesses im Team ausgestalten.

Diese informellen Teamrollen korrespondieren nicht immer mit den funktionalen oder organisatorischen Rollen der Projektmitglieder: So muss der Projektleiter nicht unbedingt der "Vorsitzende" sein und der Qualitätsbeauftragte nicht notwendigerweise ein "Perfektionist", auch wenn die Eigenschaften dieser Belbin-Rollen die Aufgaben der entsprechenden Projektrollen gut unterstützen.

Es ist nicht schwer, sich auszumalen, wie die Ergebnisse eines Teams aus lauter "Perfektionisten" aussehen würde, oder wie ein Team arbeitet, in dem die Rollen "Umsetzer" und "Macher" unbesetzt sind: Das "Perfektionisten"-Team würde vor lauter Selbstkontrolle, Qualitätssicherung und Optimierung nur einen sehr langsamen Leistungsfortschritt erzielen und möglicherweise sogar an den eigenen und gegenseitigen hohen Erwartungen scheitern. Im zweiten Team würde der "Vorsitzende" Meetings moderieren, bei denen die "Spezialisten" und "Neuerer" großartige innovative Ideen entwickeln, deren Realisierung begonnen, aber von niemandem zu Ende geführt werden würde.

Tatsächlich haben die Untersuchungen Belbins, die mehrere hundert Teams umfassten, die naheliegende Vermutung bestätigt: Teams mit ausgeglichener Rollenverteilung sind leistungsfähiger als weniger ausgewogen besetzte (Belbin, 2010).

Im Idealfall haben Sie als Projektleiter bereits bei der Auswahl der Teammitglieder die Möglichkeit, auf diese optimale Rollenkombination Einfluss zu nehmen, indem Sie möglichst sich ergänzende Charaktere mit komplementären Fähigkeiten auswählen (s. das 5. der acht Kriterien).

Dies setzt natürlich eine gute Kenntnis der Kandidaten voraus. Deshalb empfiehlt es sich, mit potenziellen Projektmitarbeitern, die Sie noch nicht kennen, ein Vorstellungsgespräch zu führen. Ob jemand die erforderlichen fachlichen Kompetenzen mitbringt, lässt sich in der Regel recht leicht aus dem Lebenslauf ablesen, ob sie oder er sich aber als Mitglied für ein bestimmtes Projektteam eignet, lässt sich dagegen nur im persönlichen Gespräch erfahren.

Auch wenn Sie die Teammitglieder "komplementär" ausgewählt haben, müssen sich diese erst in "ihre" informellen Rollen im Team einfinden. Dabei kann und wird es zu Konflikten kommen: Konkurrieren z.B. mehrere Mitglieder um die Rolle des "Vorsitzenden", muss dieser Konflikt gelöst sein, sonst kann sich um jeden "Vorsitzenden" eine Teilgruppe bilden, die gegen die andere Teilgruppe arbeitet (siehe das Internet-Projekt). Wenn möglich sollte der Projektleiter die einzelnen Vorsitzenden auf einzelne Teilteams verteilen oder auf funktionale Rollen mit klar abgegrenzten Zuständigkeiten aufteilen, wie z.B. Testmanager und Entwicklungsleiter.

Drängen sich beispielsweise alle Mitarbeiter in die "Beobachter"-Rolle, besteht die Gefahr, dass sich das Projekt auf sehr niedrigem Produktivitäts-Niveau stabilisiert. Daher muss das Team die Möglichkeit bekommen, diese informellen Rollen möglichst optimal und einvernehmlich zu besetzen. Dies ist in aller Regel auch möglich, denn wenige Menschen sind auf eine einzige informelle Rolle festgelegt: Es ist möglich, in einem Team der "Vorsitzende" oder "Macher" zu sein und in einem anderen Team der "Beobachter" oder "Spezialist".

Überlegen Sie zur Übung doch mal, welche unterschiedlichen informellen Rollen Sie in Ihren Teams im beruflichen oder auch im privaten Umfeld – auch ein Sportverein oder eine Familie ist ein Team – bereits eingenommen haben.

Wenn Sie ein gewisses Gefühl für die Charaktere der einzelnen Rollen gewonnen haben, ordnen sie die Mitarbeiter Ihres aktuellen Projekt- oder Arbeitsteams den entsprechenden Rollen zu. Gibt es Rollen, die doppelt besetzt sind? Sind Rollen unbesetzt?

Manche Doppelbelegungen stören nicht weiter – so verträgt jedes Team mehrere "Beobachter" und "Teamarbeiter". Fehlt aber z.B. ein "Neuerer" und es findet sich auch niemand aus dem Team, der diese Rolle beansprucht, so können Sie als Projektleiter z.B. versuchen, das zu erwartende Kreativitäts- und Innovations-Defizit zu kompensieren, indem Sie Kreativitätstechniken einsetzen.

Das Rollenmodell von Belbin in den Projektbeispielen

Mit der Kenntnis des Rollenmodells von Belbin kehren wir noch einmal zurück zu den beiden Projektbeispielen.

Das Internet-Projekt verfügte aufgrund seiner Größe eigentlich über eine ausreichende Basis an komplementären Fähigkeiten und potenziellen informellen Projektrollen. Leider nutzte der Projektleiter dieses Potenzial nicht: Weder wurde das Projekt mit übersichtlichen Projekt-Unterstrukturen versehen, in die die einzelnen Rollen optimal hätten verteilt werden können, noch wurde den Teammitgliedern jemals die Möglichkeit gegeben, ihre informellen Rollen zu finden und zu besetzen. Das zeigt, dass ein guter Skill- und Persönlichkeits-Mix alleine noch kein gutes Projektteam garantiert. Wer die Normen- und Regelbildung für eine gute Zusammenarbeit dem Zufall überlässt, kann eben auch nur mit einem zufälligen Erfolg rechnen.

Im Steuerelemente-Projekt hatte der Projektleiter die Möglichkeit, Einfluss auf die Zusammenstellung seines Teams zu nehmen. Dies ist der Idealfall und unbedingt zu empfehlen! So hatte er bei der Zusammenstellung des "Entwicklerteams Modul 2" die Auswahl zwischen vier, fast gleichwertigen Entwicklern. Zwei der Entwickler kannte er bereits als "Macher" und "Teamarbeiter" aus früheren Projekten, die anderen beiden lernte er im Vorstellungsgespräch als "Perfektionisten" und "Neuerer" kennen. Da die fachlichen Anforderungen an das Projekt noch sehr unklar waren und mit großen Herausforderungen bei der technischen Umsetzung zu rechnen war, fiel die Wahl auf den "Neuerer", der sich dann auch hervorragend in das Team integrierte und wertvolle Beiträge für die Ausgestaltung der technischen Lösung leistete. Er erwies sich auch als idealer Sparrings-Partner für den Architekten.

Das Beraterteam bestand aus einem "Spezialisten" (dem Senior-Berater), einem "Beobachter" und einem "Teamarbeiter". Dies stellte sich als problematisch heraus, da der "Spezialist" für das Projekt zwar unverzichtbar, aber nicht in der Lage war, sein Beraterteam effizient zu steuern: Zu sehr war er mit der inhaltlichen Ausgestaltung der Konzeption beschäftigt und damit, seine eigenen Ideen möglichst detailliert zu spezifizieren. Damit wäre er eigentlich ein ideales Teammitglied im Beraterteam gewesen, aufgrund seiner Seniorität und der Unerfahrenheit der beiden anderen Berater konnte aber niemand außer ihm diese Führungsposition besetzen – eine andere Besetzung hätte er auch nicht akzeptiert. Er erwartete von seinen Beratern, dass sie sich möglichst selbst organisierten und notwendige Informationen bei Bedarf selbstständig von ihm einforderten: "Ich muss mir das ja auch alles alleine erarbeiten!", war ein häufig von ihm geäußerter Vorwurf.

Die Lösung bestand darin, dass der Architekt – eine gute Mischung aus "Wegbereiter" und "Vorsitzender" – auf Anregung und mit anfänglicher Unterstützung des Projektleiters die informelle Führung des Beraterteams übernahm. Aufgrund seiner Rolle arbeitete er ohnehin sehr eng mit den Beratern zusammen, konnte die notwendigen Abstimmungen herbeiführen und die fehlende fachliche Führung durch den Senior-Berater ausgleichen, indem er intensiv nachfragte und aktiv von den Beratern die explizite Bestätigung der Übernahme von Arbeitsaufträgen einforderte. Stabilisierend wirkten sich dabei natürlich die akzeptierten Normen und Verhaltensregeln sowie das etablierte Projektvorgehen aus.

Fazit

Der Beitrag fokussiert auf Kriterien für gute Teams und die optimale Zusammensetzung von Teams auf Basis informeller Rollen und der damit verbundenen sozialen Kompetenzen.

"Sage mir, wie dein Projekt beginnt und ich sage Dir, wie es endet." (Gero Lomnitz)

Hilfreich für die Bildung erfolgreicher Projektteams ist ein planmäßiges Vorgehen bei der Teambildung von Beginn an. Im Idealfall hat der Projektleiter einen führenden Einfluss bei der Zusammensetzung seines Teams. Dazu ist es nicht notwendig, für jede zu besetzende Projektstelle mehrere Kandidaten zur Auswahl zu haben. Bei guter Menschenkenntnis reichen schon wenige Wahlmöglichkeiten bei der Teambesetzung aus, um die Teamzusammenstellung zu optimieren oder die Rollendefinition vorteilhaft zu beeinflussen.

Harte Fakten und weiche Faktoren

Eine besondere Bedeutung kommt der Projektinitialisierung zu: Die Durchführung eines Kick-off-Workshops ist ein wichtiger Schritt auf dem Weg zum erfolgreichen Projektteam. Im Rahmen dieses Workshops gilt es nicht nur, die Ziele und den Projektplan vorzustellen und die Regeln zur Kontierung der Arbeitszeit zu erklären – zweifellos wichtige und notwendige Informationen.

Die Teammitglieder müssen sich aber auch kennenlernen dürfen und die Möglichkeit bekommen, ihre informellen Rollen zu besetzen und ihre funktionalen Rollen möglichst selbstständig auszuarbeiten.

Die gemeinsame Vereinbarung von Arbeitsabläufen und Prozessen, Normen und Verhaltens-, Kommunikations- und Besprechungsregeln – wenn möglich im Konsens – sind Voraussetzung dafür, dass sich Teamgeist, Zusammengehörigkeitsgefühl und Leistungsorientierung entwickeln können.

Besonderheit virtueller Teams

In der Einleitung hieß es, dass die Mitglieder eines Teams miteinander in persönlichem Kontakt stehen und direkt miteinander kommunizieren. Auch virtuelle Teams können über Telefon oder E-Mail in persönlichen und direkten Kontakt treten – und so auch erfolgreich zusammenarbeiten. Diese Zusammenarbeit hat aber eine andere Qualität als die Arbeit in Präsenzteams. (Zur Arbeit in "virtuellen Teams" siehe auch "Vertrauensbildung in virtuellen Teams", Projekt Magazin 03/2011, "Kommunikation in virtuellen Teams. Teil 1", Projekt Magazin 13/2011, und "Kommunikation in virtuellen Teams. Teil 2", Projekt Magazin 14/2011.)

Im Falle verteilter Teams ist es unbedingt notwendig, ein Präsenz-Kick-off mit allen Teammitgliedern durchzuführen, bei dem sich diese von Angesicht zu Angesicht kennenlernen. Wenn es nicht gelingt, einen gemeinsamen "Team-Spirit" zu erwecken, werden sich die einzelnen Standorte als eigenständige Teilteams ausbilden und sehr bald gegeneinander arbeiten.

Disclaimer

Das genaue Befolgen der Empfehlungen dieses Beitrags garantiert nicht ein funktionierendes Team und selbst ein optimal zusammengestelltes und funktionierendes "High-Performance-Team" garantiert nicht den Projekterfolg. Aber ein funktionierendes, "erfolgreiches" Team schafft den Nährboden für erfolgreiche Projekte, eine bewusste Planung der Teambildung schafft den Nährboden für ein funktionierendes Team.

Literatur

• Belbin, Meredith: Team Roles at Work, Taylor & Francis, 2010; s. auch http://www.belbin.com (Verfügbarkeit zuletzt geprüft am 6.11.2012)
• Kerzner, Harold: Project Management – A Systems Approach to Planning, Scheduling, and Controlling, John Wiley & Sons, Inc., Hoboken, New Jersey 2009
• Meifert, Matthias T. (Hrsg.); Sattler, Johannes; Förster, Lars; Saller, Thomas; Studer, Thomas: Führen: Die erfolgreichsten Instrumente und Techniken, Haufe-Verlag, 2010
• Motzel, Erhard: Projektmanagement Lexikon – Referenzwerk zu den aktuellen nationalen und internationalen PM-Standards, Wiley-VCH Verlag GmbH & Co KGaA, Weinheim 2010
• Patzak, Gerold; Rattay, Günter: Projektmanagement, Linde Verlag, Wien 2004