Modul 1

Die Aussage ist richtig. Alle Handlungsabfolgen außerhalb des „Business as usual“

sind Vorhaben. Darunter sind einfache Vorhaben (z.B. Austausch von fünf Funkuhren), Vorhaben, die kontinuierliche Prozesse darstellen (z.B. permanentes Durchlaufen des Kontinuierlichen Verbesserungsprozesses; dieser ist nicht Business as usual, wirkt aber darauf ein, was künftig als Business as usual gelten soll) und Vorhaben, die einmaliger Natur, dabei relativ komplex und nicht innerhalb der normalen Strukturen und Abläufe zu bewerkstelligen sind (Projekte).

Die Aussage ist richtig. Ein Merkmal von Projekten ist ihre Einmaligkeit. Was nur

einmal getan wird, ist zwangsläufig neu, also innovativ.

Die Aussage ist falsch. Ein Pionierprojekt ist sehr wahrscheinlich offen und von

hoher sozialer Komplexität. Das in der Behauptung geschilderte Projekt ist mit größerer Wahrscheinlichkeit ein Standardprojekt.

Die Aussage ist falsch. Zwar gibt DIN 69901 fünf Phasen vor, aber in der Literatur und Praxis finden sich zahlreiche Phasenmodelle. Die bekannten Modelle weisen zwischen drei und sechs Phasen auf.

Stakeholder Eigentümer von Grundstücksflächen, über die die neue Straße teil-

weise verlaufen soll: Will nicht verkaufen – weil die Straße die Grundstücke zerschneidet und deren Nutzen erschwert/verhindert; weil die angebotene Entschädigungszahlung als nicht ausreichend angesehen wird; weil der Eigentümer grundsätzliche Bedenken gegen das Projekt hat und keinesfalls verkaufen will.

Stakeholder Anlieger/Nachbarn der neuen Straße: Wollen die Straße verhindern,

weil sie mehr Verkehr und Lärm bringt.

Stakeholder Mitarbeitende: Wollen nicht umziehen; haben Bedenken bzgl. Daten-

schutz und Datensicherheit.

Stakeholder eigene IT-Mitarbeiter: Sperren sich gegen die von der Geschäftsleitung ausgewählten Softwareprodukte oder gegen die Zusammenarbeit mit dem Projektteam.

Stakeholder Fachabteilungen, die mit der neuen Software arbeiten sollen: Befürchten Mehr- und Doppelarbeit sowie Datenverluste während der Einführungsphase; sehen nicht ein, dass sie den Umgang mit einer neuen Bedienoberfläche lernen sollen.

a) Die Forderung des Geschäftsführers ist so nicht zu erfüllen. Das magische Dreieck

verdeutlicht, dass eine gleichzeitige Optimierung von Zeit, Kosten und Qualität nicht möglich ist: Soll es schnell gehen, wird es nicht gut oder kostet „extra“. Soll es geringste Kosten verursachen, wird sich niemand intensiv kümmern können, weswegen es lange dauert und wahrscheinlich auch nicht gut wird. Soll das Ergebnis bestmöglich ausfallen (also höchsten Qualitätsansprüchen genügen), reichen minimale Zeit und minimale Mittel nicht aus, dieses Ziel zu erreichen.

b) Die Zielformulierung ist nicht SMART, denn

▪ sie ist nicht spezifisch im Sinne von präzise; es ist nicht angegeben, was genau erwartet wird;

▪ sie ist nicht messbar, weil sie keine Kriterien enthält, anhand derer nach Ablieferung der Softwarelösung der Grad der Anforderungserfüllung bestimmt werden könnte;

▪ sie ist nicht realistisch, siehe a), weil sie das Dilemma des magischen Dreiecks nicht auflöst,

▪ sie ist nicht terminiert, weil „in kürzestmöglicher Zeit“ keine Terminvorgabe darstellt.

c) Eine SMARTe Formulierung wäre:

„Erstellen Sie eine Software, die die Vorgaben des Lastenhefts erfüllt. Das Ergebnis soll zum Ende dieses Jahres vorliegen. Das verfügbare Budget beträgt 200.000 €.“

Zum Beispiel:

Das Eye of Competence als zentrales Konzept des IPMA-Standards ICB repräsentiert die klare, kompetente und verantwortungsvolle Sichtweise des Projektmanagers, der eine spezifische Situation zu erfassen und hinsichtlich der geeigneten Aktionen zu beurteilen hat und dabei alle für ein erfolgreiches Projektmanagement erforderlichen Kompetenzen einfließen lässt.

oder:

Das Eye of Competence symbolisiert die für eine klare, kompetente und verantwortungsvolle Einschätzung einer bestimmten Situation notwendige Integration aller Elemente des Projektmanagements, wie sie sich aus dem Blickwinkel des Projektmanagers darstellt.

Es ist möglich, die ganze Organisation oder auch einzelne Projektmanager zertifizieren zu lassen, aber dies – wie überhaupt die Anwendung eines Standards – ist nicht vorgeschrieben. Viele Unternehmen verzichten aus Kostengründen auf eine Organisationszertifizierung, beschäftigen aber zertifizierte Projektmanager. Vor allem kleinere Unternehmen folgen bei der Abwicklung von Projekten ihren eigenen, unternehmensspezifischen Standards, die häufig organisch gewachsen sind.

▪ In Unternehmen mit mehreren oder vielen parallel laufenden Projekten gehen die verschiedenen Betriebsteile und Abteilungen beim Projektmanagement oft uneinheitlich vor und stehen sich damit bei notwendigen Abstimmungen (etwa über den Zugriff auf gemeinsam genutzte Ressourcen) selbst im Weg.

▪ Das Befolgen eines Standards garantiert ein strukturiertes Vorgehen, bei dem (bei korrekter Befolgung) nichts übersehen wird.

▪ Externe Projektpartner, die nach einem bestimmten Standard vorgehen, könnten die einheitliche Anwendung dieses Standards zur Bedingung machen.

▪ Neue Mitarbeitende finden sich leichter zurecht, wenn im Betrieb nach einem Standard gearbeitet wird: Entweder weil sie ihn bereits kennen oder weil die Einarbeitung in gut beschriebene, immer dem gleichen Muster folgende Prozeduren einfacher ist, als ein gewachsenes, möglicherweise schlecht dokumentiertes System zu verstehen.

Projektinitiierung

Dokumentation, Projektdefinition, Projektidee, Zieldefinition, Lastenheft

Projektorganisation und Planung

Projektstrukturplanung, Dokumentation, Terminplanung, Budgetplanung, Netzplan

Projektcontrolling

Projektsteuerung, Dokumentation, Überwachung, Gegensteuern, Fortschrittsbericht

Projektende

Dokumentation, Implementierung, Abnahme, Resümee

In der Matrixorganisation bleibt der einzelne Mitarbeitende dem Linienvorgesetzten unterstellt. Wenn er aber für das Projekt tätig wird, ist er fachlich dem Projektleiter unterstellt – disziplinarischer Vorgesetzter bleibt der Linienvorgesetzte. Hieraus können Differenzen entstehen, vor allem, wenn der Mitarbeitende nur zeitanteilig für das Projekt arbeitet. Entscheidungen und Anweisungen der Leitungsfunktionen können einander widersprechen. Durch Kommunikationsprobleme zwischen Projektleitung und Linienvorgesetztem kann der Mitarbeiter „zwischen die Stühle geraten“; durch Arbeitsaufträge von beiden Seiten überfordert werden.

Der Machtpromotor ist eine von der Unternehmensführung bestimmte

Führungskraft (oft Mitglied der Geschäftsleitung, zumindest des Top Managements), die als Vertreterin des Projektauftraggebers engen Kontakt zum Projekt hält.

Bei größeren Projekten muss sichergestellt sein, dass die Führungsspitze als Projektauftraggeberin „hinter dem Projekt steht“ und den Projektleiter bzw. das Projektteam unterstützt. Dies ist gewährleistet, wenn ein Mitglied der Führungsspitze eng an das Projekt angebunden ist. Es muss und wird nicht ständig im Projektteam mitarbeiten, aber so weit eingebunden sein, um Kraft seiner Autorität eventuelle Schwierigkeiten auszuräumen, für die Bereitstellung von Ressourcen zu sorgen und den Fortgang des Projekts sicherzustellen.

Vorteile der Methode 6-3-5:

▪ Alle Beteiligten werden aktiv beteiligt (bei anderen Methoden ist es eher möglich, dass einzelne Aktive die Wortführerschaft übernehmen).

▪ Die Lösungsvorschläge und ihre Entwicklung über Assoziationen der Beteiligten liegen schriftlich vor und sind auch im Nachhinein nachvollziehbar.

▪ Die Methode ist gut verständlich und ermöglicht ein systematisches Arbeiten.

▪ Störungen durch angezettelte „Zwischendurch-Diskussionen“ entfallen.

▪ Konflikte zwischen Gruppenmitgliedern wirken sich weniger aus als bei rein auf mündlichem Austausch fußenden Methoden (oder auch gar nicht).

▪ Jede Lösungsidee wird aufgegriffen

Nachteile der Methode 6-3-5:

▪ Jede/r Beteiligte arbeitet für sich allein – das kann die Kreativität „ausbremsen“.

▪ Lösungen werden weniger spontan als vielmehr überlegt formuliert – auch dadurch kann die Kreativität gemindert werden.

▪ Das Wissen darum, dass die Vorschläge schriftlich erhalten bleiben und möglicherweise einzelnen Teilnehmenden durch „Abzählen“ oder Erkennen der Handschrift zugeordnet werden können, kann sich hemmend auswirken.

Vorteile der Nutzwertanalyse:

▪ Das Verfahren ist einfach und ohne großen Aufwand durchführbar.

▪ Es ist möglich, unterschiedliche quantitative und qualitative (nicht mit Geld-, Mengen oder sonstigen Größeneinheiten bezifferbare) Merkmale zu berücksichtigen.

Nachteile der Nutzwertanalyse:

▪ Wenn zu viele Kriterien einbezogen und jeweils entsprechend gering gewichtet werden, verliert das Verfahren seine Aussagekraft.

▪ Die Auswahl der Kriterien und deren Bewertung erfolgt subjektiv. Die Durchführung durch eine einzige Person ist daher kritisch. Bei wichtigen Entscheidungen müssen daher mehrere Personen die Bewertung unabhängig voneinander durchführen, um zu einem objektiveren Ergebnis zu gelangen – wirklich objektivierbar ist das Verfahren aber nicht.

Hinweis: In der Praxis werden monetäre Aspekte (wie die Grundstückspreise im Beispiel) nicht in die Nutzwertanalyse einbezogen, sondern mittels anderer Verfahren (z.B. Kostenvergleichsrechnung) verglichen.

Aufgrund der angegebenen Skala zeigt die niedrigste Summe das beste Ergebnis

an. Danach sollte der Standort Gründorf ausgewählt werden.

Das Lastenheft beschreibt gemäß DIN 69901-5 die Anforderungen an die zu ent-

wickelnde Software aus Anwendersicht. Dementsprechend wird es vom Auftraggeber erstellt und dem Auftragnehmer übergeben, der sich daraufhin ein genaues Bild von den Wünschen des Kunden und den Anforderungen an das zu liefernde Produkt – hier: die zu liefernde Software – machen kann.

Inhalte des Lastenhefts sind z.B.

▪ grundsätzliche Aufgaben der zu liefernden Software, etwa:

– Die Software soll für die Kommissionierung von Kundenbestellungen eingesetzt werden,

– die Software soll die bei Exporten erforderlichen Frachtdokumente erstellen.

▪ grundsätzliche technische Anforderungen an die Software, etwa

– Die Software soll im Netzwerk in einer WINDOWS-Umgebung installiert werden.

▪ Anforderungen an die Software-Ergonomie, z.B.

– die Benutzerschnittstelle und alle Meldungen sind in deutscher Sprache vorzusehen.

– alle Dialoge sollen kontextbezogene Hilfen anbieten.

Basisanforderung: Für einen Kugelschreiber ist ein hinreichend elastischer Clip, der das Befestigen des Schreibers an der Brusttasche oder an Schriftstücken ermöglicht, selbstverständlich. Fällt dem Kunden nach dem Kauf im praktischen Gebrauch auf, dass eine solche Befestigung nicht möglich ist, weil der Clip zu starr und zu kurz ist, ist er enttäuscht und unzufrieden.

Leistungsanforderung: Der Kunde erwartet von einem höherpreisigen Kugelschreiber eine besondere Leichtläufigkeit beim Schreiben und eine hohe Ergiebigkeit der Mine. Werden diese Anforderungen im praktischen Gebrauch langfristig erfüllt, ist der Kunde zufrieden.

Begeisterungsanforderung: Der Kunde erwartet bei einem Kugelschreiber wahrscheinlich keine „smarte“ Eigenschaft. Ein Kugelschreiber, der das Geschriebene unabhängig vom beschriebenen Material und der Schreibunterlage speichern und auf andere elekt-ronische Geräte übertragen kann, wäre eine echte Überraschung und könnte bei technisch affinen Kunden große Begeisterung auslösen.

Als Teufelsquadrat kommt jedes Viereck in Betracht, dessen Eckpunkte auf den Diagonalen liegen, die den Lösungsraum aufspannen, und dessen Flächeninhalt dem des ursprünglichen Quadrats entspricht. Eine solche Form ergäbe sich z.B. dann, wenn in dem in Kapitel 2.1.2 gezeigten Beispiel die Anforderung neu definiert würde in: „Projektfertigstellung in der bisher geplanten Zeit ohne Verringerung des Leistungsumfangs, aber mit verringertem Budget“: Dann könnte auf die Rechtsverschiebung der rechten unteren Ecke nur die Qualität reagieren (mit einer entsprechenden Verschiebung ebenfalls nach rechts unten). Die zuvor parallelen Seiten (obere und untere Seite) wären infolgedessen nicht mehr parallel, und es entstünde ein Drachenviereck.

Für größere, komplexe Projekte ist der Netzplan vorzuziehen, weil er übersichtlicher als das Gantt-Diagramm die Abhängigkeiten zwischen Vorgängen darstellt und damit die Ermittlung von frühesten und spätesten Anfangs- und Endterminen wesentlich erleichtert. Puffer sind im Netzplan deutlich besser zu erkennen und erheblich leichter zu berechnen. Allerdings ist die Erstellung eines Netzplans sehr viel aufwendiger als die eines Gantt-Diagramms.

Die im Finanzbudget bereitstehenden Mittel fließen nach außen als Bezahlung für fremdbezogene Leistungen ab, d.h. sie sind zahlungswirksam. Die im Ressourcenbudget bereitstehenden Leistungen betreffen die Nutzung von im Betrieb vorhandenen Kapazitäten (Personal, Maschinen, sonstige Leistungen). Sie verursachen in der Regel keinen zusätzlichen Mittelabfluss; ihre Gegenwerte in Geld müssen aber kostenrechne-risch berücksichtigt werden.

Projektcontroller/in

Zeit, Kosten, Leistung (Qualität)

Meilenstein-Trendanalyse

90-Prozent-Syndrom

Projektstatusbericht / Status Review

Ein Projekt ist zu Ende, wenn

▪ das intendierte Ziel erreicht ist und

▪ der Auftraggeber das Ergebnis abgenommen hat

oder

▪ der gesteckte Zeitrahmen ausgeschöpft ist, ohne dass das gewünschte Ergebnis erzielt wurde, und die Beteiligten beschlossen haben, von einer Verlängerung abzusehen.

Wurde das Projektziel nicht erfüllt, sind die gesammelten Erfahrungen („Lessons Learned“) nicht weniger wertvoll – und vielleicht sogar wertvoller – als bei einem erfolgreich beendeten Projekt. Wenn die aufgetretenen Schwierigkeiten, Hemmnisse und letztlich nicht überwundenen Probleme festgehalten werden, ergeben sich daraus wertvolle Hinweise für spätere Projekte und eventuell auch Anlässe für strukturelle Veränderungen im Betrieb.

▪ Einmaligkeit

▪ zielgerichtet

▪ risikobehaftet

▪ zeitliche Befristung

▪ begrenzte Ressourcen

▪ Komplexität

▪ Interdisziplinarität

▪ Verursachen von Veränderungen

▪ Projektumfang

▪ vorgegebene Zeit

▪ verfügbare Ressourcen

▪ Qualität

▪ Konkurrenz und Wettbewerbssituation

▪ Problem- und Krisensituationen

▪ Risikobegrenzung

▪ Chancennutzung

▪ Zielerreichung

Die Projektmanagementphasen entsprechen den kritischen Durchlaufetappen des Projekts (Initiierung, Planung, Ausführung, Steuerung, Überwachung und Abschluss). Im Unterschied zu den Projektmanagementphasen unterscheiden sich die Projektphasen in Abhängigkeit von der Projektart:

▪ Projektträger (Eigenprojekte, Fremdprojekte)

▪ Ressourcenrahmen (Vollzeitprojekte, Teilzeitprojekte)

▪ Kern (IT-Projekte, Organisationsprojekte, Forschungsprojekte), und

▪ Zweck (Infrastrukturprojekte, Produktprojekte, Innovationsprojekte).

▪ Anforderungsanalyse für Systeme und Software - Kundenanforderungen fließen in eine Produktspezifikation

▪ Grobdesign - Entstehung eines Modells und der Architektur

▪ Feindesign - innere Struktur der Software

▪ Implementierung - Programmierung

▪ Test und Integration - Absicherung lauffähiger Software; bei Abschluss - Erfüllung der Spezifikation

Verifikation

▪ Sicherstellung, dass das Produkt mit den Produkteigenschaften, festgehalten im Pflichtenheft, übereinstimmt

▪ meist ein interner Prozess

Validierung

▪ Auswertung, ob das Produkt den Geschäftsanforderungen, festgehalten im Lastenheft wie auch Leitlinien oder anderen verpflichtenden Bestimmungen genügt

▪ meist auch Prüfung der Akzeptanz oder Eignung des Produkts durch externe Anwender

Verifizierung im V-Modell: Modultest, Integrationstest, Systemtest

Validierung im V-Modell: Akzeptanztest

Prototyping

▪ Prozess des Baus und der Erprobung von Prototypen

▪ schrittweise Annäherung an das Endprodukt

Vorteile

▪ dient der Demonstration der bislang erreichten Funktionsfähigkeit

▪ dank Iteration eine weitere Optimierung des Produkts möglich

▪ frühe Erkennung und Beseitigung von Fehlern und Ausfällen mit relativ geringerem Aufwand

Klassische Projektmanagementmethoden:

▪ standardisierte Vorgehensweisen

▪ plangetrieben und phasenbasiert

▪ möglichst exakte Ausführung des fixierten Planes

▪ Projektergebnis bei Projektende

Agile Projektmanagementmethoden:

▪ dynamische Vorgehensweisen

▪ inkrementelle nicht fixierbare Planung

▪ flexibles Management beruhend auf Selbstorganisation von Teams und Kundenfeedback

▪ iterative Bereitstellung von Projektergebnissen

▪ visionsgetrieben

▪ offene oder nicht eindeutig festgelegte Zielsetzung

▪ inkrementelle (schrittweise) Planung

▪ schlanke Prozesse, iterativ organisiert

▪ flexible und schnell durchführbare Änderungen und Anpassungen der Produktanfor-

derungen

▪ selbstorganisierte und aufwärtsgetriebene Kommunikation

Sprint Planning - Vorbereitung des nächsten Sprints

▪ Anforderungen in Aufgaben mit einem Arbeitsaufwand gewöhnlich nicht länger als einen Tag eingeteilt

▪ Status der Abarbeitung der anstehenden Aufgaben im jeweiligen Sprint wird an der Aufgabentafel transparent veranschaulicht

▪ Team legt fest, wie viele Arbeitspakete in den Sprint einfließen und welche Aufgaben realisiert werden

Daily Scrum - täglicher kurzer zweckdienlicher Meinungsaustausch im Team zwecks Projektkontrolle und Leistungsoptimierung

▪ Ergebnisse des Vortages aus der Sicht des Sprint-Ziels diskutiert

▪ Tagesziele, mögliche Barrieren für das Erreichen des Sprint-Ziels und Gegenmaßnahmen besprochen

Sprint Review - Demonstration des Inkrements aus dem aktuellen Sprint gegenüber Product Owner und Anwendern

▪ Auswertung des Inkrements gegenüber den Zielen aus dem Product Backlog

▪ Abschätzung notwendiger Anpassungen an den Produkteigenschaften

▪ Entscheidung über Abnahme des Inkrements

▪ nicht erfüllte Anforderungen im nachfolgenden Sprint Planning aufgegriffen

Sprint-Retrospektive - Sprint-Nachbereitung

▪ erfolgt zum Abschluss des Sprints

▪ Hindernisse und Beeinträchtigungen beachten

▪ Schlussfolgerungen für das Vorgehen in den nachfolgenden Sprints ziehen

Product Backlog - strukturierte Liste aller festgelegten Anforderungen im Sinne von bindenden Funktionen und Eigenschaften des Produktes sowie der Aufgaben, die bis zum Projektende abgeschlossen werden müssen

▪ Anforderungen vom Team gemeinsam erörtert

▪ Liste stets aktualisiert und vervollständigt

▪ Product Owner pflegt das Product Backlog und bestimmt die Priorisierung der Aufgaben anhand der Anforderungen sowie die Anpassung

Sprint Backlog - Teilbereiche aus dem globalen Product Backlog als Anforderungen für die Bearbeitung während eines Sprints

▪ Entscheidung über einzubeziehende Aufgaben in das Sprint Backlog im Rahmen des Events ‚Sprint Planning‘

▪ Aufgaben werden täglich überarbeitet und aktualisiert

▪ Transparenz über Status der Aufgaben sowie effiziente Dokumentation

▪ Vorlaufzeit (gemessen ab Zeitpunkt der Anforderung einer Aufgabe) und Zykluszeit (gemessen ab Zeitpunkt des tatsächlichen Abarbeitungsbeginns) geben Auskunft darüber, wie lange Aufgaben im Arbeitsfluss bis zur Fertigstellung verbringen

▪ Durchsatz - die Anzahl der abgeschlossenen Aufgaben pro Tag - dient als Teamproduktivitätsmesswert sowie Kennzahl für die Auswirkungen des Arbeitsflusses auf die gesamte Unternehmensleistung

▪ Aufgaben in Ausführung anhand von Informationen wie Beschreibung, Empfänger, Frist

▪ Ausgewählte Projektphasen oder Teilprojekte können individuell in einer sequenziellen (aufeinanderfolgenden) Abfolge mit verschiedenen Projektmanagementmethoden verknüpft werden.

▪ Ausgewählte Projektphasen oder Teilprojekte können parallel mit unterschiedlichen Projektmanagementmethoden bearbeitet werden.

▪ Verschiedene Projektmanagementmethoden können hybridisiert (ineinander eingegliedert) werden.

▪ Verknüpfung des Wasserfall-Vorgehensmodells mit dem Scrum-Vorgehensmodell (klassisch und agil)

▪ zum Beispiel klassisch für das Gesamtprojekt und Implementierungsphase mit Sprints

▪ dadurch Kundenrückkopplung besser in die Projektabwicklung integriert

▪ vereint Stärken klassischer sowie agiler Vorgehensmodelle gleichermaßen

▪ theoretisch unendlich viele Möglichkeiten, beide Ansätze - klassisch und agil - und deren Elemente miteinander zu verknüpfen

▪ hohe Flexibilität und demzufolge branchenunabhängig einsetzbar

▪ Abbildung der faktisch vorherrschenden, hybriden Realität von Projekten

▪ ermöglicht situationsbedingte Projektabwicklung

▪ dadurch zuverlässige Anpassung an individuelle Anforderungen und maßgeschneiderte Lösungen

▪ Klarheit über das anvisierte Produkt

▪ Stabilität der Produktanforderungen und Änderungsanpassungsoptionen

▪ Projektumfang und Teamgröße

▪ regulatorische Vorschriften

▪ Klarheit über externe und interne Schnittstellen

▪ Konformität zu Standards

▪ Anforderungen an Dokumentation und Berichterstattung

Der Wunsch der Teamleitung, diese Phase zu überspringen, ist verständlich, aber unmöglich zu erfüllen: Die Auseinandersetzungsphase ist notwendig für die Entwicklung des Teams, da jetzt die Positionen und Rollen ausgehandelt werden, die für das spätere Funktionieren des Teams in der Performing-Phase unerlässlich sind. Ein Übergehen – etwa indem das Team mit Aufgaben „zugepflastert“ wird in der Hoffnung, dass es sich dann weniger mit sich selbst beschäftigt – wird in aller Regel nicht funktionieren, weil nicht ausgetragene Konflikte – siehe Abschnitt 2.3 – sich immer nach vorn drängen („Störungen haben Vorrang“ – weil sie sich ihn nehmen!).

Kohäsion ist der Gruppenzusammenhalt, der sich im gruppendynamischen Prozess herausbildet. Sie drückt sich in der Identifikation der Gruppenmitglieder mit der Gruppe und dem Herausbilden einer Teamidentität aus.

Möglichkeiten, den Gruppenzusammenhalt nach außen deutlich zu machen, sind gemeinsame dingliche Symbole (z.B. Fanschal, Sweatshirts mit Team-Emblem) oder gemeinsame Rituale (besondere Art, einander zu begrüßen; Gebrauch von Schlüsselworten, deren Bedeutung Außenstehende nicht kennen).

1. Aufbauen von „Feindbeziehungen“ zu anderen Gruppen (die Frühschicht wirft der Nachtschicht vor, „nie“ aufzuräumen; ein Team wirft dem anderen vor, Ressourcen und Informationen zurückzuhalten, tut dies aber vor allem selbst);

2. Groupthink: Einzelne Teammitglieder schließen sich – aus vermeintlicher Solidarität – jeder Mehrheitsmeinung in der Gruppe an, auch wenn sie wissen, dass diese falsch ist.

1. die Teamgröße:

Ideal ist eine Teamstärke von 5, 7 oder 9 Personen. Kleinere

Teams bieten zu wenig Vielfalt, schöpfen die Potenziale der Belegschaft kaum voll aus, und es besteht die Gefahr der Isolation einzelner Mitglieder (2:1 3:1); in größeren Teams sind Kohäsionsbildung und Motivation schwierig. In Teams mit gerader Personenanzahl drohen Pattsituationen in Entscheidungsfällen.

2. die Altersstruktur:

Etwa gleich alte Mitglieder werden zwar wahrscheinlich schnel-

ler zu einem Team zusammenwachsen als gemischt-alte Gruppen, aber es lohnt fast immer, die lebensweltlichen Erfahrungen der verschiedenen Generationen für das Projekt zu nutzen. Die Gewichtung sollte auf die konkrete Aufgabe und die Altersstruktur in der Gesamtbelegschaft abgestimmt sein.

3. Heterogenität bei Geschlecht und Herkunftskultur:

Hier sollte versucht werden, die

Diversität der Gesamtbelegschaft abzubilden: Zum einen, um verschiedene Blickwinkel im Projekt zu berücksichtigen – gerade bei der Entwicklung von Marketingstrategien ist dies ein wichtiger Aspekt – und zum anderen, um in der Belegschaft selbst nicht den Eindruck unterschiedlicher Wertschätzung aufkommen zu lassen. Auch hier ist aber die konkrete Aufgabe zu berücksichtigen.

1. Vorhandensein von fachlicher Kompetenz auf mindestens einem für das Projekt

relevanten Feld.

2. Kommunikationsfähigkeit

3. Verträglichkeit

4. Kooperationsfähigkeit

5. Offenheit für Neues

(Weitere Kompetenzen sind denkbar, etwa Zuverlässigkeit, Lernfähigkeit, Kreativi-

tät, Frustrationstoleranz, Konfliktfähigkeit).

a) Pro-Argumente aus Sicht von Herrn Meier:

1. Bei einem solchen Mannschaftsspiel kommt es darauf an, eine Teamstrategie zu entwickeln (offensives oder defensives Vorgehen? Wie und wann?) und sich gegenseitig den Rücken freizuhalten: Wer gibt wem Deckung? Damit werden Fähigkeiten geübt, die in der späteren Teamzusammenarbeit wertvoll sind.

2. Bei einem solchen Mannschaftsspiel sind Durchsetzungs- und Durchhaltevermögen gefordert – ebenfalls wichtige Fähigkeiten in der künftigen Teamarbeit.

3. Das Event als solches ist außergewöhnlich und kann, wenn man sich darauf einlässt, viel Spaß machen. Es wird sicherlich nachhaltig als Teamerlebnis in Erinnerung bleiben.

b) Contra-Argumente aus Sicht von Frau Schulz:

1. Wenn nicht die Möglichkeit besteht, gegen ein fremdes Team zu kämpfen, muss das eigene Team geteilt werden; man kämpft also gegen Mitglieder des eigenen Teams. Dies kann eher entzweiend als zusammenschweißend wirken oder auch eine unerwünschte Cliquenbildung innerhalb des Teams fördern.

2. Extrem sportliche Aktivitäten, die eine hohe körperliche Beweglichkeit fordern, sind nicht für alle Menschen gleichermaßen geeignet.

3. Paintball wird von vielen Menschen als Kriegssimulation empfunden. Es ist daher mit ethischen Einwänden seitens einzelner Teammitglieder, der Geschäftsleitung oder des Umfelds zu rechnen.

Dass nicht alle Teammitglieder auf gleich hohem Niveau Leistungen erbringen, ist nicht ungewöhnlich: Wenn das Team eine Gesamtleistung erbringt, fällt es (scheinbar oder tatsächlich) nicht auf, wenn einzelne Mitglieder mehr und andere weniger leisten. Dieses Phänomen des Social Loafing (Soziales Faulenzen) wird gern am Beispiel des Tauziehens verdeutlicht: Alle ziehen – einige kräftig, andere tun nur so, als ob.