Im Folgenden möchte ich zwischen Teams (im engeren Sinne), Mannschaften (Crews) und Trupps unterscheiden. Die Begriffe sind nicht zufällig gewählt, sie verkörpern einerseits extreme Beispiele andererseits werden damit gelegentlich verwendete Metaphern aus Sport oder Militär deutlicher. Ich möchte die Unterschiede an der Form der Aufgabenteilung, dem Führungsprinzip sowie der möglichen Aufgabenstellung beleuchten.

Der extreme Fall des Trupps ist z.B. im Militär oder in Organisationen wie Feuerwehr und Katstrophenschutz zu finden. Die Aufgabenteilung ist sehr strikt und wird gezielt eingeübt. Es ist im Einsatzfall bereits vorher entschieden und allen klar, wer welche Aufgabe übernimmt. Die Entscheidung wer die Drehleiter bedient, wer die Schläuche verlegt und wer die Leiter hoch klettert muss (!) im Vorfeld getroffen werden. Im Ernstfall ist es dafür zu spät. Diese Vorab-Entscheidung ist deshalb möglich weil ein Trupp konkrete Handlungsszenarien und definierte Abläufe hat, die eingeübt werden. Der Begriff der “Übung” ist jetzt schon zweimal gefallen. Zu Recht – er ist ein wesentliches Merkmal. Ein Trupp kann und muss üben. Die Übung findet unter Anleitung eines Führers¹ statt. Mit dem explizit benannten Führer gehen auch eine klare, stabile Hierarchie und eine Kommandostruktur einher.

Am anderen Ende der Skala steht ein “echtes Team” wie es z.B. in (agilen) Projekten zum Einsatz kommt. Die Einsatz-Szenarien sind weitgehend unbekannt. Die Aufgabenteilung ergibt sich dynamisch aus den Anforderungen des Projektes. Die innere Hierarchie verändert sich in engem Zusammenspiel mit der konkreten Aufgaben- und Rollenteilung. Eine hierarchische Kommandostruktur und Vorab-Übungen nützen wenig bzw. sind sogar kontraproduktiv.

Die (Fußball) – Mannschaft stellt gewissermaßen die Übergangsform dar. Übungen machen Sinn. Es gibt explizite Hierarchie-Positionen wie z.B. den Trainer oder den Mannschafts-Kapitän² Die Aufgabenteilung ist vorab festgelegt kann aber in gewissem Umfang wechseln – schließlich kann und darf auch ein Verteidiger Tore schießen. In anderen Sportarten wie z.B. dem American Football ist der Abstand zum “Trupp” geringer, hier wechseln je nach Spielsituation sogar die Spieler das Feld.

Aus diesen Merkmalen ergeben sich noch andere Unterschiede. In einem Trupp ist die Spezialisierung viel größer, dies ermöglicht in den eingeübten Situationen eine sehr hohe Effizienz. Anderseits ermöglicht die Flexibilität des “echten Teams” den besseren Umgang mit unbekannten Situationen. Jede dieser Gruppen hat ihre Berechtigung sollte aber auch passend eingesetzt werden. Für die Projektarbeit, die oft eine Aneinanderreihung von unbekannten Situationen ist, würde ich eine Gruppe empfehlen, die so weit wie möglich einem echten Team entspricht.

1. Auch wenn der Begriff eventuelle negative Assoziationen auslösen mag, so trifft er doch den Punkt.
2. Interessanterweise ist der altmodische Begriff für den Kapitän der Spielführer.

1. Erfolgreichere Projekte!
2. Zufriedenere Menschen!

Erfolgreichere Projekte

Der Grad der Selbstorganisation¹ in einem Team lässt sich mit Kontrollfragen² grob ermitteln. Salopp formuliert lässt sich über die Auswertung der Fragen grob differenzieren ob es sich um ein (selbstorganisiertes) Team oder eine ggf. teilweise zerstrittene Arbeitsgruppe handelt.

Für nebenstehende Grafik haben wir erstmals die Untersuchungsergebnisse der letzten 5 Jahre zusammengetragen und für 478 Projekte die Erfolgsquoten der Projekte in Abhängigkeit des Teamzustands ermittelt. Das Ergebnis spricht eine mehr als deutliche Sprache. Von den 478 Projekten hatten 199 gute Teams, von denen wiederum 132 erfolgreich waren. Dies entspricht einer Erfolgsquote von ca. 66%. Bei den Projekten mit schlechten Teams sieht es hingegen düster aus. Nur 6 von 40 Projekten waren erfolgreich (15%).

Anders herum formuliert: Wer sich schlechte Teams leistet überzieht in mindestens 8 von 10 Projekten das Budget und/oder den Termin. Die Alternative ist es sich um die Teams zu kümmern, die Selbstorganisation zuzulassen um dann nur noch jedes dritte Projekt zu überziehen. Jede(r) hat die freie Wahl.

Die zweite Antwort “Zufriedene Menschen” steht hier.

1. Selbstorganisation zielgerichteter Arbeit entsteht als Ergebnis eines gruppendynamischen Prozesses den das Projektteam durchlebt. Hierbei wird eine innere Rollenklärung durchgeführt. Weniger diplomatisch formuliert: Es gibt Machtkämpfe. Am Ende entsteht ein Gerüst aus teilweise unausgesprochenen Normen, Regeln und Verhaltensmustern. Dieses Gerüst stellt die selbst geschaffene Organisation dar.
2. Die erwähnten Kontrollfragen und die Ermittlung des Teamzustandes werden hier am Beispiel einer kleineren Stichprobe beschrieben Weiche Faktoren sind wichtig.

Wie sieht der gemeinsame Kern agiler Vorgehensweisen aus?

• Es wird akzeptiert, dass zu Beginn nur ein Teil der Anforderungen definiert ist.
• Es besteht permanenter und enger Kontakt zu denen,
  die das Arbeitsergebnis geliefert bekommen.
• Es wird in wiederkehrenden Intervallen gearbeitet.
• Am Ende jeden Intervalls wird ein verwendbares Zwischenergebnis fertig gestellt.
• Jedes Arbeitsintervall wird ausgewertet.
  Es werden Konsequenzen für das nächste formuliert und auch gezogen.
• Die produktive Arbeit wird von einem Team geleistet, das selbstorganisiert arbeiten darf.

Aus der Formulierung der Merkmale wird schon deutlich, dass diese Arbeitsweise nicht nur für Software-Entwicklung sondern für viele verschiedene Projektarten möglich sein wird. Wie die Merkmale in der Praxis konkret umgesetzt werden (z.B. mittels Scrum) ist letztendlich egal. Genauer betrachtet lässt sich diese Arbeitsweise auch mit “klassischem Projektmanagement” zuzüglich ordentlichem Changemanagement, kooperativer Führung und transparenter Kommunikation verwirklichen. Agilität ist ohnehin eher als Geisteshaltung denn als Prozessbeschreibung zu verstehen.¹

Nehmen wir an, dass in einem Projekt wie oben beschrieben gearbeitet wird. Das Team arbeitet und liefert nach einer gewissen Zeit ein (hoffentlich) verwertbares Zwischenergebnis ab. Sollte im ersten Intervall nichts Brauchbares fertig werden, muss eben nach den Gründen gesucht werden um dann im zweiten Anlauf erfolgreicher zu sein. Egal ob im ersten oder zweiten Anlauf, das Team hat sehr früh ein Erfolgserlebnis. Konkrete (Erfolgs)-Erlebnisse und Erfahrungen beschleunigen die teaminternen Klärungsprozesse wie Rollenklärung oder die üblichen Machtkämpfe erheblich. Ein simples Beispiel: Ein Kollege bezeichnet sich selbst als Spezialist für ein bestimmtes Thema. Stimmt das? Können sich Team und Projekt wirklich darauf verlassen? Nach der Lieferung des ersten Zwischenergebnisses hat sich das bestätigt (oder eben nicht). Die Bestätigung der Fähigkeiten, der Verlässlichkeit, das Erproben der Zusammenarbeit, das Wachsen des aufkeimenden Vertrauen – all dies erfolgt schneller wenn mit greifbaren Zwischenschritten gearbeitet wird.² Im negativen Fall wird ebenfalls schneller klar, dass der Kollege vielleicht nur eine große Klappe hatte und er mit einer anderen Aufgabenstellung mehr für das Projekt tun kann. Wichtige Grundvoraussetzungen für eine erfolgreiche Teamentwicklung wie die Klärung der Fragen “Wer gehört dazu?” bzw. “Wie sieht die gemeinsame Aufgabe aus?” werden bei einer solchen Vorgehensweise quasi im Vorbeigehen erledigt.

Wer agil arbeitet, stellt gewissermaßen ganz nebenbei gute Rahmenbedingungen für eine konstruktive Teamentwicklung bereit.

Eine konstruktive Teamentwicklung innerhalb des Projektes ist m.E. DER Erfolgsfaktor für Projekte. Scrum stellt hierfür bessere Rahmenbedingungen als das Wasserfallmodell bereit. Dennoch gibt es keinen Königsweg. Auch in Wasserfall-Projekten lässt sich ein Teil des agilen Gedankenguts (siehe obige Merkmale) leben. Ein gutes Team schafft fast alles, eine zerstrittene Projektgruppe kann jedes Projekt scheitern lassen.

1. Insofern kann ich Stimmen, die Scrum als alten Wein in neuen Schläuchen bezeichnen durchaus verstehen.
2. Ein Meilenstein in einem Projektplan ist nicht zwingend ein greifbarer Zwischenschritt. Die Softwareentwicklung hat es hier relativ leicht. Hier entspricht dies einem lauffähigen Release. In anderen Projekten muss die Definition der Meilensteine genau bedacht werden.

1. Im Team waren die gemeinsamen Ziele und Aufgaben bekannt.
2. Die Teammitglieder waren bereit,
   ihre persönlichen Ziele den Zielen des Teams unterzuordnen.
3. Es war klar wer zum Team dazugehört.
4. Die Aufgaben und Rollenverteilung im Team waren klar.
5. Getroffene Entscheidungen wurden vollständig von allen Teammitgliedern umgesetzt.
6. Es war klar, wer welche Entscheidungen trifft.
7. Es gab im Team verbindliche Regeln zur Zusammenarbeit.
8. Es herrschte im Team eine vertrauensvolle Atmosphäre.
9. Kritik wurde im Team offen und konstruktiv geäußert.
10. Probleme wurden offen im Team besprochen und gemeinsam gelöst.
11. Es gab ein “Wir-Gefühl” im Team.
12. Die Arbeit im Team machte Spaß.
13. Projektrelevante Informationen wurden innerhalb des Teams
    bereitwillig ausgetauscht und weitergegeben.
14. Wichtige Entscheidungen im Team wurden transparent für alle Mitglieder kommuniziert.
15. Erfahrungen und Wissen wurden im Team ausgetauscht.
16. Die Teammitglieder haben sich gegenseitig motiviert und unterstützt.
17. Es wurden im Team Witze erzählt, die von Außenstehenden nicht verstanden wurden.

Es liegt auf der Hand, dass einige der Faktoren wie z.B. die Klarheit der Ziele mittelbar von erfolgreichem Methoden- und Werkzeug Einsatz abhängen. Andere wie das “Wir-Gefühl” oder die “vertrauensvolle Atmosphäre” sind als Ergebnis der Gruppendynamik im Team zu sehen. Einen ersten Eindruck, dass diese Faktoren wichtig für den Projekterfolg sind vermittelt nebenstehende Grafik. Es sind 4 mehr oder minder kreisförmige Kurven zu sehen. Die gestrichelten Kurven stellen theoretische Kurven dar. Die Blaue zeigt den Idealzustand (ideales Team) wenn alle der obigen Aussagen mit voller Zustimmung angekreuzt würden. Die Rote zeigt das negative Gegenteil wenn keine der Aussagen auf Zustimmung träfe. Die durchgezogenen Linien zeigen die real ermittelten Werte für “erfolgreiche” und “nicht erfolgreiche” Projekte. In erfolgreichen Projekten ist demnach die Teamqualität höher. Die Frage “Ob die Teamqualität den Erfolg befördert oder sie sich als Nebenprodukt des Erfolgs einstellt” liefert Stoff für eine Henne-Ei-Diskussion, die ich hier schon einmal angerissen hatte.

Interessanter als die Henne-Ei-Diskussion scheint mir ein genauerer Blick auf die Faktoren, bei denen der Unterschied im obigen Diagramm besonders ausgeprägt ist. Darunter sind auch 4 Aussagen, die besonders eng mit dem konstruktiven Verlauf der Gruppendynamik im Projektteam zusammen hängen:

• Es gab verbindliche Regeln der Zusammenarbeit.
• Es existierte eine vertrauensvolle Atmosphäre.
• Es existierte ein Wir-Gefühl.
• Persönliche Ziele wurden Team-Zielen untergeordnet.

Die Zustimmung² zu all diesen Aussagen wird sich nur einstellen wenn das Team die Leistungsphase (performing) erreicht hat. Die verbindlichen Regeln der Zusammenarbeit sind das Ergebnis einer internen Auseinandersetzung (Rollenklärung und Machtkämpfe). Auf dieser geklärten Basis kann das Vertrauen und Wir-Gefühl entstehen. Das positive Erleben des Vertrauens ermöglicht letztendlich dem Einzelnen seine persönlichen Ziele den gemeinsamen Team- bzw. Projektzielen unterzuordnen.³ Ein Blick auf die Erfolgsquoten der Projekte in Abhängigkeit von diesen 4 Faktoren zeigt nebenstehende Grafik. Die Erfolgsquote der Projekte mit weit entwickelten Teams ist mehr als 3-mal so hoch wie jene der Teams, die sich in früheren Teamentwicklungsphasen befinden. Diese Korrelation ist stärker als jede andere bisher gefundene⁴. Weder bei PM Methoden, den Vorgehensmodellen noch beim Werkzeugeinsatz ließen sich vergleichbar große Differenzen feststellen. Ein Team, das die Teamentwicklungsphasen weitgehend durchschritten hat, ist demnach einer der wichtigsten Erfolgsfaktoren in der Projektarbeit.

Die entscheidende Frage ist: “Wie lässt es sich erreichen, dass das Team innerhalb des Projekts möglichst schnell die Findungsphase verlässt, die der Rollen- und Machtkämpfe durchläuft und die produktive Phase erreicht?” Warum agile Methoden hierbei einen gewissen Vorteil haben wird Thema des nächsten Beitrages sein.

1. Die Aussagen konnten wie folgt bewertet werden: trifft überhaupt nicht zu, trifft eher nicht zu, trifft eher zu, trifft voll und ganz zu.
2. Als Zustimmung wurden hier die Antwortoptionen “trifft eher zu” bzw. “trifft voll und ganz zu” gewertet.
3. Eine Beschreibung der Teamphasen und der Zusammenhang mit psychologischen Diagnosefragen zur Ermittlung der Phase ist hier zu finden.
4. Hier ist anzumerken, dass die Erfolgsquote bei den Projekten, die bei diesen vier Teamfaktoren ausschließlich “trifft voll und ganz zu” bewertet hatten, noch höher liegt.

OBJEKTspektrum, Ausgabe 02/2010
Aktuelle Studie: Warum Projektteams erfolgreicher sind als Projektgruppen
Dr. Eberhard Huber, Sven Lindenhahn

Ein Scrum-Master hat einen ähnlichen Job wie ein Handballtrainer. Er oder sie muss den Haufen von Spezialisten dazu bringen als Team zu agieren und durch laufendes Training dafür sorgen, dass die Leistungsfähigkeit erhalten bleibt. Genau! – es geht um Erhaltung und nicht um Steigerung. Die Leistungsfähigkeit jedes Teams wird von alleine schlechter – es ist genauso wie bei einer Handballmannschaft ohne Trainer, die Spielpraxis kann eine gewisse Zeit die sich verschlechternde Kommunikation und das Einschleifen schlechter Gewohnheiten verlangsamen, langfristig geht es aber nicht ohne Training.

Noch ein paar Wort zur Leistungssteigerung oder gar zum Leistungsdruck: Ein echtes Team arbeitet um Größenordnungen effizienter als eine zusammengewürfelte Gruppe oder ein “zerstrittener Haufen”. Wenn die Teamarbeit ins Laufen kommt entsteht das “Wir-Gefühl”, der Teamgeist, der ein Gefühl der Verpflichtung mitbringt. Dieses Gefühl der Verpflichtung lässt den Einzelnen die persönlichen Bedürfnisse hinten an stellen. Mit dem Erfolg kommt als Belohnung das Gefühl der kollektiven Euphorie. Das ist wichtig und manchmal notwendig. Das Wechselspiel aus Verpflichtung und Euphorie darf aber nicht zum Dauermotor der Arbeit werden sonst besteht die Gefahr des Ausbrennens. Hier steht der Scrum-Master in der Pflicht dieses zu verhindern. Diese Aufgabe ist doppelt schwer, weil ein rennendes Team sich gelegentlich selbst überfordert. Auf der anderen Seite wird gelegentlich von Seiten der Organisation Druck aufgebaut um Hochleistungsteams noch weiter zu treiben und auszubeuten. Der Scrum-Master steht dazwischen. Der / die Scrum-Master ist also nicht nur Hebamme der Selbstorganisation sondern manchmal auch großer Bruder oder große Schwester, die das Team beschützen.

Noch einmal zurück zum Handballsport, den ich als ehemaliger Spieler und Trainer immer noch verfolge. Die deutsche Nationalmannschaft hat in den letzten Jahren große Erfolge gefeiert. Erfolge, die teilweise mit ersatzgeschwächten Mannschaftsaufstellungen erzielt wurden. Der Teamgeist hat hier unglaublich viel kompensiert aber irgendwann kollabiert das Verpflichtungs-Euphorie-System. Die Euphorie kann nicht ewig den Verbrauch der Substanz kompensieren – das enttäuschende Abschneiden bei der letzten Europameisterschaft kann man durchaus als Ausbrennen des Teams deuten.

In Kürze noch einmal die wichtigsten Punkte als Zusammenfassung. Diese Punkte gelten nicht nur für Scrum sondern für alle Organisationsformen, die auf selbstorganisierte Teams setzen:

• Selbstorganisation muss erarbeitet, geübt und erhalten werden.
• Selbstorgansierte Teams brauchen Trainer.
• Trainer benötigen eine andere Ausbildung als Teammember

• Es gab ein übergreifendes “Projektziel”, das den Charakter einer Vision hatte.
• Es gab klare und konkrete Ziele, die kompatibel zur Vision waren.
• Die Mitarbeiter im Projekt haben im Dienste der Vision gut zusammengearbeitet.

Das hört sich im ersten Moment plausibel aber auch fast schon trivial an. In jedem dieser Sätze sind jedoch implizit Hindernisse und Abhängigkeiten enthalten. Die Grafik zeigt einen Teil der Zusammenhänge. Der erste Punkt, den es fest zu halten gilt, ist der, dass eine Vision nicht identisch mit den Zielen ist. Aus der Vision können und müssten konkrete Ziele abgeleitet werden. Gut formulierte Ziele verlieren aber ohne Vision an Wert. Die Vision ermöglicht wesentlich die Identifikation der Mitarbeiter mit dem Projekt. In der Literatur findet sich als Merkmal für Hochleistungsteams an erster Stelle die gemeinsame Vision. Ein perfekt formuliertes Lastenheft, das umgesetzt werden soll, reißt – salopp gesprochen – niemanden vom Hocker. Genau das muss die Vision aber leisten. Die Mitarbeiter müssen bildlich gesprochen vom Hocker gerissen werden, für die Dauer des Projektes von den Stühlen des Alltags Abschied nehmen um im Dienste der Vision mit den anderen zusammen zu arbeiten.

Während sich die Urform des Projektmanagements überwiegend um die Klarheit der Ziele (Spezifikation) und die Organisation der zielgerichteten Arbeit (Planung, Steuerung, Controlling) kümmerte, rückte im Lauf der Jahre zunehmend auch die Vision in den Blickpunkt. In den PM-Methodiken äußerte sich dies z.B. im Stakeholder-Management. Auch die Bedeutung der Kommunikation und der Mitarbeiterführung nahm zu und fand Eingang in die PM Methodiken. In der Grafik bezeichne ich diese ausgefeilten Methodiken als “klassisches PM”. Klassisch insofern, dass mit dem agilen Manifest der Aspekt des Teams in den Vordergrund rückte. Vision, Team und die Arbeitsfähigkeit des Teams werden z.B. in Scrum sehr explizit benannt.

Die Debatten “agil” vs. “klassisch” halte ich hierbei für wenig zielführend. Wesentliche Unterschiede sehe ich lediglich in der Vorgehensweise wie die konkreten Ziele, die erreicht werden müssen, ermittelt werden. Vision ist immer nötig, ohne Kommunikation läuft nichts und dasTeam muss immer irgendwie zum Funktionieren und Arbeiten gebracht werden.

Und damit komme ich endlich zur teamorientierten Projektleitung. Das Zusammenwachsen der Mitarbeiter zum Team, die Entstehung einer Kooperation, die mehr als eine Anhäufung von Einzelkompetenzen ist, ist in vielen Projekten von glücklichen Zufällen, den Führungsqualitäten oder dem Charisma des Projektleiters abhängig. Vision, Ziele sind notwendig aber nicht hinreichend um ein gutes Team entstehen zu lassen. Hier setzt teamorientiertes Projektleitung an, die den Teambildungsprozess im Laufe des Projekts fördernd begleitet. Teamorientiertes Projektleitung ist eine (auch ethische) Grundeinstellung. Sie ist ein Leitungsprinzip, das Selbstorganisation zulässt und fördert, und somit ermöglicht, das im Team vorhandene Potential tatsächlich auszuschöpfen. Wie das konkret aussehen kann ist im Beitrag über das Teamuhrwerk nachzulesen.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 1B, siehe Mindmap zu Inhalt und Struktur.

• Angst zu fragen
• Der anonyme Spezialist
• Selbstorganisation und Entscheidungen

Angst zu fragen

Ein Mitarbeiter sitzt an einer Aufgabe, weiß an einer Stelle nicht mehr weiter und traut sich nicht einen Kollegen zu fragen. Das Eingeständnis etwas nicht zu wissen und fragen zu müssen ist nie leicht. Es fällt umso schwerer wenn im Kollegenkreis das gegenseitige Vertrauen fehlt, wenn nicht klar ist was nach der Frage passiert. Kommt ein abschätziger Kommentar oder wird die Wissenslücke gar weiter erzählt. Ich selbst habe einen Fall erlebt, dass ein Entwickler 2 Wochen gewartet hat bis ein Kollege aus dem Urlaub zurück war um eine Frage loszuwerden – er hatte sich nicht getraut den anwesenden Kollegen zu fragen. Zwei Wochen in denen ein Arbeitspaket in Wartestellung blieb – diese zwei Wochen waren doppelt schmerzhaft, da sich das Problem auf das sich die Frage bezog innerhalb von 10 Minuten lösen lies.

Der anonyme Spezialist

Gelegentlich kommt es vor, dass Spezialisten für bestimmte Themen (z.B. Know-How über eine spezielle Datenbank) in ein Team aufgenommen werden. Im Verlaufe des Projektes stellt sich heraus, dass der vermeintliche Datenbank Spezialist auch in anderen für das Projekt relevanten Feldern Qualifikationen besitzt. Möglicherweise bemerkt der Neue einen Fehler an einer anderen Stelle und weist darauf hin. Jetzt kommt es darauf an wie in der Gruppe mit Fehlerhinweisen umgegangen wird. Offen und konstruktiv? Dann ist alles gut. Möglicherweise erhält der Neue aber eine Abfuhr mit den Worten “Kümmere Dich um Dein Thema!” Ob der Neue sich noch einmal mit einem Hinweis unbeliebt machen will ist dann schon fraglich. Es ist unerheblich ob der Neue seinen Hinweis unhöflich, besserwisserisch vorgebracht oder der Alte um seine Stellung fürchtend barsch reagiert hat. Das Ergebnis ist dasselbe. Es entsteht ein anonymer Spezialist der sein Knowhow zurückhält. Dieses Knowhow geht dem Projekt verloren.

Selbstorganisation und Entscheidungen

Egal mit welcher PM-Methode gearbeitet wird, es werden in Projekten Situationen entstehen, die einer Entscheidung bedürfen. Nicht immer wird der notwendige Entscheider zufällig in der Tür stehen oder sofort antworten können. Jetzt kommt es darauf an ob die Gruppe wirklich selbst organisiert ist. Selbstorganisation bedeutet nicht nur, dass die tägliche Arbeit läuft. Selbstorganisation ist vielmehr die Fähigkeit der Gruppe in Entscheidungssituationen eine Entscheidung herbeizuführen und wieder handlungsfähig zu werden. Ob diese Entscheidung die optimale für den Projektverlauf ist muss sich dann erweisen, das gleiche gilt aber auch für die Entscheidung des ausgewiesenen Entscheiders (Projektleiter, Product-Owner, Gremien, …)

Sicherheit zu fragen, frei gegebenes Wissen und die Fähigkeit ohne Führung Entscheidungen zu treffen sind wesentliche Merkmale eines Teams. Mit einer Gruppe von Nebenher-Arbeitern, die auf ihrem Wissen sitzen bleiben und nur auf Kommando arbeiten, wird Projektarbeit sehr schwierig. Der Zustand realer Projektteams liegt oft zwischen diesen Extremen. Teamorientierte Projektleitung versucht die Qualität des Projektteams zu erfassen und im Laufe des Projektes zu verbessern. Um eine Gefühl für den Zustand des Projektteams zu entwickeln kann ein Projektleiter sich die folgenden Aussagen im Sinne eines Fragebogens vergegenwärtigen:

• Probleme werden offen besprochen und gemeinsam gelöst.
• Es wird Hilfe und Unterstützung geleistet.
• Erfahrungen werden bereitwillig ausgetauscht.
• Entscheidungsverantwortungen sind klar.

Wenn diese Aussagen vorbehaltlos mit heftigem Kopfnicken bejaht werden ist das Team auf einem guten Weg. Wenn zweifelnd der Kopf geschüttelt wird ist noch Verbesserungspotential vorhanden.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 3D, siehe Mindmap zu Inhalt und Struktur.

1. Teamphasen, Projektmanagement und Teamuhrwerk