Das Lehrprinzip PIPE (Projekt-im-Projekt-Erfahrung) wurde an der Hochschule Konstanz über 7 Jahre hinweg entwickelt und dabei stetig anhand eines Masterkurses in Informatik verfeinert. PIPE setzt einen einen projektartigen Kompetenzerwerb voraus. Dies ist etwa der Fall, wenn die für das jeweilige Lehrgebiet relevanten Kompetenzen in einer projektartigen Form geübt oder trainiert werden können oder wenn die spätere Anwendung erlangter Kompetenzen im Berufsalltag ein projektartiges Tätigkeitsfeld ist. PIPE ist ein Ansatz für agiles Vorgehen, Kommunizieren und Lernen in verteilten Teams und trainiert mit projektbasiertem Arbeiten eine in unserer westlichen Industriewelt immer wichtiger werdende Schlüsselkompetenz. Durch die Fokussierung auf verteilte Teams bedingt ermöglicht PIPE einen graduellen Übergang zwischen reinem Präsenztraining und vollständiger Online-Lehre. In Corona-Zeiten konnte sich dieses Lehrprinzip daher konzeptbedingt ohne weitere Anpassung von einem Tag auf den anderen Tag auf vollständigen Online-Betrieb umstellen lassen.

In diesem Kapitel wird PIPE anhand der Ausgangssituation in der Hochschullehre bei der Projektmanagement-Lehre vorgestellt. Es ergeben sich daraus eine Reihe von Anforderungen für erfolgreich Projektmanagement-Lehre, anhand derer anschließend die Konzeption des Prinzips, also die Struktur, die Rollen, die Feedbacks, die Tools und insbesondere die didaktischen Ziele und angewandten Lernprinzipien beschrieben werden. In einem abschließenden Abschnitt wird der bisherige Erkenntnisgewinn und exemplarisch eine Reihe von Ergebnissen und Interpretationen der bisher durchgeführten internen und externen Evaluationen beschrieben.

3.1 Ausgangssituation

Projekte dominieren den beruflichen Alltag insbesondere in wissensorientierten Domänen. Das Projektgeschäft ist ein stark zunehmender Wirtschaftsfaktor in unserer westlich geprägten Industriewelt, da die Produktionskosten aufgrund vielfältiger Faktoren wie etwa der Lebenshaltungskosten im globalen Kontext immer weniger wettbewerbsfähig sind (Giap et al., 2011; Wald et al., 2015). Das Management von zunehmend komplexeren Projekten im unternehmerischen Umfeld stellt eine Schlüsselqualifikation in einer modernen, vernetzten und verteilten Informationsgesellschaft dar (Hassemer, 2010) (Kawka, 2013). Projektmanagement (oder erfolgreiche Mitarbeit in Projekten) entwickelt sich daher zu einer der wichtigsten Kompetenzen im Arbeitsleben, insbesondere bei akademisch ausgebildeten Personen. Im Projekt „Agiles Projektmanagement“ (AgilePM) des IBH-Lab „Seamless Learning“ wurde untersucht, wie der Kompetenzerwerb von Lernenden im Bereich Projektmanagement (PM) gesteigert werden kann, damit sie den hohen Erwartungen im realen Projektbetrieb des Berufsalltags gerecht werden können.

Im PM sind Sozialkompetenz und Kommunikation – im deutschen Qualifikationsrahmen DQR (Bund-Länder-Koordinierungsstelle, 2020) wird hier zwischen Selbst- und Sozialkompetenz unterschieden – die alles entscheidenden Erfolgsfaktoren (Lechler & Gemünden, 1998), die allein in Theorie oder einer realitätsfernen Ausbildung nicht erlern- bzw. erfahrbar sind (Cetacea Communications, 2013) (Erasmus et al., 2010) (GPM, 2014). Folglich kann in realen Projekten rein theoretisches PM-Wissen ohne in der Praxis erlangte zugehörige Kompetenz nur schwer genutzt werden (Baron, 2016). Die Lücke zwischen der Theorie (in der Ausbildung) und der praktischen Anwendung (im Unternehmen) kann aus diesem Grund in kaum einer anderen Disziplin erfolgskritischer sein, als im PM (PMI, 2013) (GPM, 2014). Die auf den ersten Blick als ein- und dieselbe Lücke zwischen Theorie/Ausbildung und Praxis/Unternehmen erscheinende Diskrepanz erweist sich bei genauerem Hinsehen als zwei verschiedene Brüche (engl. seams, vgl. auch Dilger et al., 2019; Wong, 2015), die auch zweigleisig adressiert werden müssen. Diese Verwechslungsgefahr entsteht durch die häufig und fälschlich synonym verwendeten Begrifflichkeiten „Theorie und Ausbildung“ bzw. „Praxis und Unternehmen/Industrie/Wirtschaft“. Hier lohnt sich eine genauere Betrachtung.

Bei dem Bruch „Theorie vs. Praxis“ dreht es sich um theoretisch angeeignetes PM-Wissen, das jedoch ohne in der Praxis erlangte, zugehörige Kompetenz nicht angewendet werden kann, also nur von sehr eingeschränktem Nutzen ist. Dabei wäre es aber denkbar, dass etwa das theoretische PM-Wissen in einem sehr realistischen Umfeld einer Weiterbildung in einem Unternehmen mit realistischen oder gar realen Beispielen und Bezügen vermittelt wird, aber weiterhin theoretisch ohne erlangte Kompetenz bleibt (vgl. Abb. 3.1 – Lehrszenario 2). Andersherum könnte PM-Kompetenz auch durch Übungen ausschließlich in der Ausbildungsinstitution oder Hochschule trainiert werden, die zwar praktisch, aber nicht realitätsnah sind (vgl. Abb. 3.1 – Lehrszenario 1).

Abb. 3.1
figure 1

Zwei Dimensionen der Wissens-/Kompetenzvermittlung

Full size image

PM-Wissen und PM-Kompetenz könnten also durchaus auch in einem unrealistischen Szenario theoretisch erarbeitet und praktisch trainiert werden. Der oben genannte Bruch „Theorie vs. Praxis“ wäre damit überwunden, die dadurch erlangte PM-Expertise für den Einsatz in der Realität aber immer noch unzureichend. Anders ausgedrückt hätte der/die auf diese Weise frisch ausgebildete Projektmanager/in oder Projektmitarbeiter/in allein durch die Überwindung des Bruchs „Theorie vs. Praxis“ immer noch schlechte Startvoraussetzungen. Aus diesem Grund macht die Betrachtung des zweiten Bruchs „Ausbildungsinstitution vs. Unternehmen“ als zweite Dimension Sinn. Mit der gleichen Argumentation wie beim ersten Bruch ist auch hier eine Überwindung des Bruchs „Ausbildungsinstitution vs. Unternehmen“ in einem rein theoretischen Umfeld, also ohne gleichzeitige Überwindung des Bruchs „Theorie vs. Praxis“ denkbar.

Für die in diesem Abschnitt skizzierte Herausforderung zu den Brüchen in der PM-Ausbildung bietet sich die Formulierung von eher formalen Anforderungen an, die bei der späteren Konzeption einer Lösung für das Verständnis hilfreich sein können. Angesichts der gerade durchgeführten Betrachtung ließen sich also folgende erste Anforderungen formulieren:

  • Anforderung 1: Überwindung des Bruchs „Theorie vs. Praxis“

  • Anforderung 2: Überwindung des Bruchs „Ausbildung vs. Unternehmen“

Die Verzahnung von Theorie und Praxis ist in der Literatur seit vielen Jahren über alle Phasen der Aus- und Weiterbildung ein vitales Thema. So beschreibt etwa (Hedtke, 2000) die Notwendigkeit zum Praxisbezug am Beispiel schulpraktischer Studien. Das Sandwich-Prinzip zwischen Informationsaufnahmephasen und aktiven Verarbeitungsphasen führt (Huber et al., 2005) als Ansatz zur Überwindung der Theorie-Praxis-Kluft in Schule und Erwachsenenbildung an (vgl. auch Wahl, 2001). Eine Verzahnung der Theorie mit der beruflichen Praxis mit entsprechender Reflektion beschreibt (Mörth et al., 2018) als Lösungsansatz. Und (Scheider et al., 2018) schließlich hält auf dem Weg von Theorie zum Handlungswissen die Praxiserfahrung für unerläßlich. Und dies ist nur ein Ausschnitt aus verwandter Literatur.

Da beide Brüche „Theorie vs. Praxis“ und „Ausbildungsinstitution vs. Unternehmen“ im PM wie oben erwähnt von besonders hoher Bedeutung sind, also sehr stark ausgeprägt sind, ist ein möglichst feingranularer (und damit nahtloser) Übergang unerlässlich. Offensichtlich kann bei dieser Ausprägung nur durch ausreichend kleine, für den Lernenden nachvollziehbare Schritte gewährleistet werden, dass der Lernende diesen Übergang in Ausbildung und Training versteht, mitgeht und verinnerlicht.

  • Anforderung 3: Inkrementelle Vorgehensweise zur Bruchüberwindung

Diese Nachvollziehbarkeit im inkrementellen Vorgehen des Übergangs durch den Lernenden erfordert vielfache Rückkopplungen (Feedback) von beiden Seiten (den Lernenden und Lehrenden) in kurzen Zyklen. Abhängig von Inhalt und Ausprägung der Rückkopplungen kann es erforderlich sein, den nächsten Schritt des PM-Trainings entsprechend anzupassen, also beispielsweise gewisse Aspekte des letzten Schritts zu wiederholen, für diesen Schritt geplante Aspekte verstärkt oder ganz andere Aspekte zu trainieren. Die menschliche Komponente in Form von potentiell unkalkulierbaren Schulungsteilnehmern bedingt, dass diese Umplanung pro Schritt eher die Regel als die Ausnahme ist, insofern hohe Flexibilität bei der Festlegung der Schulungsinhalte im nächsten Schritt gefragt ist.

  • Anforderung 4: Hohe Planungsflexibilität aufgrund von engmaschigen Rückkopplungen

Dabei sind die individuellen Eingangsvoraussetzungen (Wissens- und Erfahrungsstände) der Lernenden, deren individuelle Fortschritte und ggf. sogar individuelle Zielsetzungen beim PM-Training zu berücksichtigen. Diese können zu sehr unterschiedlichen Lernpfaden führen, wie in Abb. 3.2 stark vereinfacht visualisiert wird. Die Eckpunkte der Lernpfade in der Abbildung können dabei als die Zeitpunkte zwischen Lernschritten (Inkrementen) angesehen werden, an denen aufgrund von Feedback von jeweiligen Lernenden oder Lehrenden eine Anpassung im individuellen Lernziel und/oder -Szenario vorgenommen, also sinnbildlich eine an das Feedback angepasste neue Richtung eingeschlagen wird.

Abb. 3.2
figure 2

Inkrementelle Vorgehensweise: Individuelle Eingangsvoraussetzungen und Lernpfade

Full size image

  • Anforderung 5: Individualisierung der Schulungsinhalte

Projektarbeit geschieht im Team und erfordert die Interaktion mit den Stakeholdern des Projekts, insbesondere dem Auftraggeber (Product Owner), ggf. auch Kunden. Auch innerhalb des Teams gibt es häufig verschiedene Rollen wie zum Beispiel die des Teamleiters, Controllers, Qualitätsmanagers, Teilprojektleiters. Dies erfordert Teamarbeit und Rollenverständnis sowie Erfahrung im Praktizieren der Rollen.

  • Anforderung 6: Förderung von Rollenverständnis und Rollenspielen

Projektarbeit erfordert viel Verständnis und Erfahrung für Interaktion in Form von Kommunikation, Kooperation und Kollaboration (im Folgenden als „Interaktion“ zusammengefasst) innerhalb des Teams und in Richtung der Stakeholder. Wie bereits eingangs erwähnt, sind Sozial-, Selbstkompetenz und darin insbesondere Kommunikation die alles entscheidenden Erfolgsfaktoren im Projekt (Lechler & Gemünden, 1998). Heutige Projektarbeit funktioniert zunehmend verteilter und online (ohne Kopräsenz, vgl. Hoch & Kozlowski, 2014 und Gilson et al., 2015), was zu einer Herausforderung für jede Form sozialer Interaktion wird (Solomon, 2016). Die Erkenntnisse aus der Corona-Pandemie 2020 für die Arbeitswelt als Worst-Case-Betrachtung haben dabei einen wegweisenden Charakter (Gigerenzer, 2020).

  • Anforderung 7: Förderung von (sozialer) Interaktion

Planungsunsicherheit ist projektinhärent und wächst zusammen mit der Komplexität des Projekts. Auch hier können die Erfahrungen im Umgang mit der Corona-Krise herangezogen werden: Scheinbar unbegrenzte Projektkomplexität ist hier beinahe für jedermann im Alltag erfahrbar. Situationsadäquate kurzfristige und engmaschige Anpassungen im Projektablauf (Scope) sind daher unausweichlich und erfordern eine agile Vorgehensweise in Projekten (Highsmith, 2009).

  • Anforderung 8: Agilität als inhaltlicher Bestandteil der PM-Ausbildung

Die im Folgenden dargestellte Lern- und Trainingsmethode ist ein inzwischen mehrfach von uns praktizierter und immer wieder verfeinerter Ansatz für die Projektmanagement-Ausbildung. Er wurde innerhalb der letzten sieben Jahre im Rahmen eines jährlichen Master-Kurses an der Hochschule erprobt. Der inhaltliche Fokus im Projektmanagement lag dabei durch die fachliche Ausrichtung des Master-Studiengangs bedingt im Bereich der Informatik und dort insbesondere in der Software-Entwicklung. Es ist aber davon auszugehen, dass sich der Ansatz zumindest immer dann problemlos auf andere Domänen übertragen lässt, wenn ein projektbasierter Kompetenzerwerb vorliegt oder umsetzbar ist. Dem Konzept liegt die generelle Zielsetzung zugrunde, PM-Wissen zu vermitteln und gleichzeitig PM-Kompetenzen zu trainieren. Der Schwerpunkt eines Lehrprinzips für Projektmanagement muss daher auf dem Training von Methoden- und Handlungskompetenz in Praxisphasen liegen. Im Hinblick auf die oben genannten Erfolgsfaktoren Sozial- und Kommunikationskompetenz ist das Trainieren von (sozialer) Interaktion, Rollenverständnis und Verantwortlichkeiten ein weiteres fundamentales Ziel. So liegt unter anderem ein zentraler Fokus auf den Sozial- und Selbstkompetenzen in der Ausprägung der Kommunikationsfähigkeit, Kooperations- und Teamfähigkeit, Führungs- und Managementkompetenz, Interdisziplinarität, Selbstreflexion, Konfliktfähigkeit sowie kritischem Hinterfragen.

Es fällt auf, dass viele dieser Kompetenzen nicht nur für PM relevant sind, sondern sich problemlos auf andere Tätigkeitsprofile übertragen lassen. Dies liegt daran, dass viele Tätigkeiten heutzutage zunehmend weniger klar vorhersehbare, bis in das letzte Detail planbare Routinen oder Prozesse sind, sondern stattdessen mehr projektartige Elemente enthalten, die mehr Handlungsfreiheit, aber auch Verantwortung beinhalten (Appelo, 2011; Beck et al., 2001). Dies verdeutlicht erneut die Bedeutung der PM-Kompetenz, die sich zunehmend durch alle Tätigkeitsfelder unserer Gesellschaft zieht.

Basierend auf der in diesem Abschnitt skizzierten Ausgangslage präsentieren wir im folgenden Abschnitt die Konzeption einer Lösung für agiles Lernen, Kommunizieren und Vorgehen des Managements verteilter Projekte, die den oben genannten Anforderungen genügt.

3.2 Konzept

Der im Folgenden dargestellte Ansatz ist eine projektbasierte Methode zum Trainieren von PM in verteilten Projekten. Das Training selbst ist dabei ein Projekt, dessen inhaltliches Ziel für jeden Teilnehmer individuell durch die persönlichen Vorkenntnisse, Erfahrungen und Trainingsambitionen definiert wird. Gleichzeitig verwenden wir in dieser Methode ein weiteres Projekt, in dem die Teilnehmer die erlernten Konzepte des PM am realen Beispiel trainieren. Zum besseren Verständnis bezeichnen wir das erste Projekt als Trainingsprojekt und das Projekt mit dem realen Beispiel als Anwendungsprojekt. Aufgrund dieser dualen Verwendung eines Projekts für Training und Anwendung bezeichnen wir diese Trainingsmethode als „Projekt-im-Projekt-Erfahrung“ (Project in Project Experience, PIPE).

3.2.1 Anwendungsprojekt

Das Anwendungsprojekt wird in mehrere gleich lange Teilphasen, die Iterationen, unterteilt wird (vgl. Abb. 3.3). Dabei werden Prinzipien des agilen Vorgehensmodells Scrum angewandt, in dem diese Iterationen Sprints heissen (Schwaber & Sutherland, 2020). Vor Beginn einer Iteration werden die meisten Trainingsteilnehmer in Teams annähernd gleicher Größe eingeteilt. Die verbleibenden Teilnehmer nehmen eine Sonderrolle ein, die entweder dem Product Owner (Auftraggeber oder Produktmanager) oder dem Scrum Master entspricht. Teilnehmer in diesen Rollen sind keine Teammitglieder. Jeder Product Owner (PO) und jeder Scrum Master (SM) betreut dabei idealerweise ein Team. Je nach Teilnehmerzahl kann es jedoch erforderlich sein, dass ein PO oder SM mehrere Teams betreut.

Abb. 3.3
figure 3

Iterationen im Zeitverlauf des Anwendungsprojekts

Full size image

Die Iterationen selbst sind wie Scrum-Sprints aufgebaut und enthalten daher unter anderem Plannings, Reviews und Retros (Schwaber & Sutherland, 2020). Die Teilnehmer organisieren eigenständig sogenannte Dailys (oder Daily Scrums), also tägliche kurze Treffen, in denen das Notwendigste des Tages besprochen wird. Bei den Dailys sind die POs in der Regel nicht anwesend, die SMs aber schon. An den wöchentlichen Treffen, den Weeklys, zu denen auch die Plannings, Reviews und Retros gehören, nehmen zusätzlich die POs und damit alle Trainingsteilnehmer teil.

Fester Bestandteil des Anwendungsprojekts sind Unternehmenspartner, die in der Regel die Aufgabenstellung, also das fachliche Ziel für das Projekt vorgeben. Dieses Ziel orientiert sich häufig an realen Anforderungen aus den Unternehmen. Die Quelle der Anforderung ist ein unternehmensinterner Auftraggeber oder im besten Fall ein Kunde des Unternehmens selbst. Vertreter der beteiligten Unternehmen fungieren dabei als sogenannte Chief Product Owner (Chief PO), die im Sinne einer übergeordneten Instanz mit den POs der Teams, also Trainingsteilnehmern, interagieren. Dieser Interaktion folgend legen die POs im Planning (in Scrum aus Sprint Planning 1 und Sprint Planning 2 bestehend) mit dem Team den Umfang (Scope) der nächsten Iteration fest.

Die Iterationen werden zunehmend realitätsnäher gestaltet. So werden die Teams bei der Neubildung und Rollenumverteilung vor jeder Iteration stetig größer. Die Chief POs werden mit jeder Iteration präsenter, üben mehr Druck über die POs auf die Teams aus, zeigen nachlassendes Verständnis für POs und Teams, sind ungenauer und wankelmütiger in Ihren Vorgaben, weniger gut erreichbar und verschärfen ihr Kommunikationsverhalten und dessen Inhalte. Der Umfang (scope) der Iterationen wird größer und die Komplexität nimmt zu. Der wachsende Realitätsbezug äussert sich außerdem durch zunehmende Nähe zum Unternehmen und den Auftraggebern hinter den Chief POs. So findet die Projektarbeit mehr und mehr im Unternehmen und nicht mehr in der Ausbildungsinstitution statt.

Abb. 3.4
figure 4

Zeitpunkte und -räume von Veranstaltungs- und Trainingstypen

Full size image

3.2.2 Trainingsprojekt

Das Trainingsprojekt wird durch Präsenzveranstaltungen strukturiert, die im wöchentlichen Rhythmus stattfinden. Die Struktur des Trainingsprojekts folgt dabei in zeitlich synchronisierter Weise dem Anwendungsprojekt. In den Präsenzveranstaltungen finden die oben genannten Weeklys in enger Verzahnung mit Theorie-Sitzungen statt, in denen Erkenntnisse aus den praktischen Phasen mit theoretischer Fundierung aus dem PM belegt und ergänzt werden. In gleicher Weise werden Inhalte aus den Theorie-Sitzungen unmittelbar danach in den praktischen Iterationen erprobt (vgl. Abb. 3.4). Im Corona-Jahr 2020 wurden die Präsenzveranstaltungen mit entsprechender Tool-Unterstützung durch Online-Veranstaltungen virtualisiert, sodass wir im Folgenden anstelle von Präsenz- eher von Live-Veranstaltungen sprechen. Außerhalb dieser zeitlich synchronen Trainingsphasen gibt es die dauerhafte, aber zeitlich asynchrone Trainingsphase, in denen die Teilnehmer geographisch verteilt im Anwendungsprojekt arbeiten und über verschiedene Software-Werkzeuge miteinander kommunizieren und kollaborieren. Wir bezeichnen diese Trainingsvarianten im Folgenden als Live-Training und Offline-Training. (Abb. 3.5)

Wie im Anwendungsprojekt gibt es auch im Trainingsprojekt Rollen. Wir unterscheiden dabei die Dozenten und die Coaches. Die Dozenten – in unserem Hochschulszenario die Professoren, die die Lehrveranstaltung verantworten – führen die Theorie-Sitzungen durch. Sie sind gleichzeitig in der Rolle der Coaches, die die Teilnehmer in den Live- und Offline-Trainings betreuen, beraten und anleiten. Zu den Coaches gehören aber insbesondere auch die Unternehmensvertreter, die im Anwendungsprojekt die Rolle der Chief POs einnehmen (vgl. Abb. 3.6).

Abb. 3.5
figure 5

Feedback im Anwendungs- und Trainingsprojekt

Full size image
Abb. 3.6
figure 6

Rollen und Ziele im Anwendungs- und Trainingsprojekt in Iteration i

Full size image

Die Dozenten geben zu Beginn jeder Iteration die Struktur der Team- und Rolleneinteilung vor. Dazu gehört die Teamgröße und -Anzahl sowie die Anzahl Teams pro PO und SM, die sich in der Regel aus der Teilnehmeranzahl ableiten lässt. Dazu gehört auch die Vorgabe, ob Teams komplett neu eingeteilt werden oder aus vorherigen Teams soweit möglich zusammengesetzt werden, sowie der Wechselzwang für Rollen. Dementsprechend findet ein Team- und Rollenfindungsprozess statt, dessen Ergebnis die Teilnehmer unter Moderation der Dozenten weitgehend allein herbeiführen. Insbesondere zu diesem Zeitpunkt fließen die individuellen Vorkenntnisse und Lernziele oder Interessen, ggf. auch individuellen Fortschritte während der vorherigen Iterationen in die Entscheidung mit ein.

Wesentlich für die Individualisierung ist dabei das kontinuierliche Feedback, dass die Coaches den Teilnehmern während des gesamten Zeitraums geben. Das trifft insbesondere auf die Iterationen, also im Offline- und Live-Training, aber auch auf die damit verzahnten Theorie-Sitzungen zu. Im Offline-Training wird das Feedback in der Regel zeitlich asynchron in textueller Form gegeben. In besonderen Situationen wird hier aber auch ad-hoc ein individuelles Feedback-Gespräch mit einzelnen Vertretern einer Rolle oder Teams initiiert. Einen besonderen Stellenwert nehmen die Live-Trainings am Sprint-Ende mit den Retros (Retrospektiven) ein, die auf Team- und individueller Basis mit jedem Teilnehmer durchgeführt werden. Die Retrospektiven sind dabei zweigeteilt, einmal für das Anwendungsprojekt und einmal für das Trainingsprojekt. Im Anwendungsprojekt trainieren die Teilnehmer die Durchführung einer Retro am realen Beispiel des gerade beendeten Sprints (Schwaber & Sutherland, 2020). Im Trainingsprojekt reflektieren die Teilnehmer mit Unterstützung der Coaches ihre Lernfortschritte und Erfahrungen während des Sprints, ihr Kommunizieren und Agieren in der Rolle aus der Perspektive des lernenden Teams oder Einzelnen. Insbesondere diese Ergebnisse sind häufig entscheidend dafür, welche Lern- oder Kompetenzziele sich die einzelnen Teilnehmer für die nächste Iteration setzen und welche Rolle sie anstreben.

3.2.3 Interaktion und Werkzeuge

Neben der an agile Vorgehensmodelle gekoppelten Strukturierung des gesamten Trainings bei PIPE spielt die Interaktion (Kommunikation, Kooperation und Kollaboration) im Anwendungsprojekt aus genannten Gründen eine zentrale Rolle (s. 3.1). Die Coaches beobachten und bewerten die Interaktion, geben Feedback und beraten in Live- und Offline-Trainings. Dabei schärfen die Coaches die Ausprägung von individuellen und Teamzielen der Teilnehmer im Projektalltag. Diese Ziele werden für das Anwendungsprojekt formuliert (vgl. Abb. 3.6 – Anwendungsziele) und im Trainingsprojekt mit den Teilnehmern reflektiert. Dabei werden verschiedene etablierte Rahmenmodelle aus der Sozialpsychologie zur Optimierung der Teameffektivität kombiniert und angewandt, wie etwa VIST (Valence- Instrumentality-Self Efficacy-Trust) nach (Hertel, 2002) oder das Wechselwirkungsmodell IMOI (Input-Mediator-Output-Input, vgl. Ilgen et al., 2005 und Mathieu et al., 2008).

Der Begriff der Teamkognition nach Cooke and Salas (vgl. etwa Cooke et al., 2004 und Salas et al., 2013), öfter in der Literatur als Erweiterung der Gruppenkognition gesehen, ist dabei ein schwer messbarer Reifegrad eines Teams (Wildman et al., 2014), der deutlich über das reine Teambewusstsein hinausgeht. Bei der Virtualisierung von Teams entlang mindestens einer der Virtualisierungsdimensionen (z. B. Ort, Zeit, Kultur, Sprache) kommt diesem Faktor offensichtlich eine besondere Bedeutung zu. Geographisch verteilte Teams (Virtualisierungsdimension: Ort) haben gemäß der Media Richness Theory nach (Draft & Lengel, 1984, 1986) häufig fehlende Information oder aber Medienkompetenz, welche erwartungsgemäß negativen Einfluß auf die Teamkognition haben. Verstärkte Interdependenz (z. B. in Bezug auf Aufgaben, Ziele, Ergebnisse) im Team kann im kopräsenten Fall die Teamkognition und auch die Instrumentalität des Teams (vgl. VIST-Modell oben) fördern (Hertel et al., 2004).

Wir erproben seit mehreren Jahren die Anwendbarkeit dieser Erkenntnis auf verteilte Teams in agilen Szenarien. Die Teilnehmer trainieren dabei die Gradwanderung zwischen zu hoher Interdependenz im Sinne der Optimierung des kritischen Pfades (CPM, Critical Path Management, vgl. auch Kelley & Walker, 1959 oder San Cristobal, 2013) im Projekt und ausreichender Interdependenz zur Wahrnehmung der Teamkognition und damit der Instrumentalität des Teams. Interaktion ist dabei ein Mediator im Sinne einer Wechselwirkung nach dem IMOI-Modell (Mathieu et al., 2008): Interaktion fördert die Teamkognition und Instrumentalität im Team und diese wiederum die Interaktion. So ist es naheliegend, dass ein Team das eigene Potential und damit die Instrumentalität schlechter einschätzen kann, wenn aufgrund der geographischen Entfernung und damit fehlender Medienkanäle die Information über aktuelle Teamparameter (z. B. Expertise in einem bestimmten Bereich, den aktuellen Fortschritt oder die vorherrschende Stimmung des Teams) verloren geht.

Interaktion lässt sich sehr gut im zeitlichen synchronen Fall, also dem Live-Training, beobachten, beraten und betreuen, wenn es in Präsenz stattfindet. Im Corona-Jahr 2020 war dies aufgrund der geltenden Richtlinien nicht möglich, sodass hier auf geeignete Software-Werkzeuge zurückgegriffen werden musste. Allerdings entspricht dies auch mehr dem eigentlichen Anwendungsszenario der verteilten Teams, welches in PIPE trainiert werden soll. Insofern ist die durch die corona-bedingte Infektionslage hervorgerufene Umstellung auf Online-Training nur folgerichtig und damit eine gute Testumgebung, um den Ernstfall ganz ohne Kopräsenz im Team zu trainieren.

In den Offline-Trainings sind die Coaches ohnehin nicht vor Ort, was eine Beobachtung, Beratung und Betreuung der Interaktion zwischen den Teilnehmern in Präsenz ausschließt. Die Teilnehmer sind daher angehalten, Ihre gesamte Interaktion im Anwendungsprojekt möglichst ausschliesslich über die bereitsgestellten Software-Werkzeuge abzuwickeln. Die Teilnehmer sind darüber informiert, dass ausserhalb der Werkzeuge stattfindende Schattenkommunikation nicht beobachtet werden kann und sie daher weder beraten, noch bewertet werden können. An dieser Stelle sei erwähnt, dass wir im Hochschulkontext eines Kurses im Masterstudium eine Prüfungsleistung abnehmen müssen. Zu diesem Zweck wurde ein detailliertes Bewertungsschema angelegt. Es wurde von Jahr zu Jahr weiterentwickelt und vermittelt den Teilnehmern in sehr transparenter Weise, wo sie wann in welchen Bewertungsparameter bewertet werden und warum die Bewertung so ausgefallen ist. Die Besprechung dieser Bewertung wird ggf. am Ende einer Iteration in individuellen Feedback-Terminen besprochen und daraus neue Trainingsziele abgeleitet. Diese Bewertung ist im Hochschulkontext aus der Sicht der Studierenden Teil der individuellen Zielsetzung im Sinne des von den Coaches gesteuerten Anreizmanagements.

Für zeitlich synchrone und auch asynchrone Kommunikation verwenden wir in PIPE ein kanalbasiertes Kommunikationswerkzeug, wie etwa Slack oder Discord. Auch das System Element (früher Riot.im) beispielsweise fällt in diese Kategorie. Diese Systeme erlauben die Definition beliebiger Text- und/oder Sprachkanäle, denen Nutzer zugeordnete werden können. Teilweise sehr weit ausdifferenzierte Rollen- und Rechtekonzepte erlauben über die Kanäle die Virtualisierung von rollenspezifischen Kommunikationsgruppen, Meeting-Szenarien und sogar Räumen. So könnte es beispielsweise einen Kanal team1-sm geben, in dem alle Teilnehmer von Team 1, der Scrum Master von Team1, aber nicht der Product Owner von Team 1 schreiben und sprechen können. Die Coaches wären in diesem Kanal nur stille Zuhörer, während sie im Kanal team-sm-coaches aktiv teilnehmen und auch von den Teilnehmern angesprochen werden können. Je nach verwendetem Werkzeug können die für einen Kanal zugelassenen Nutzer zu jeder Zeit erkennen, wer sich gerade in diesem Kanal (und damit in dem virtualisierten Raum oder Meeting) befindet und mit dazu kommen. In den Live-Trainings nutzen die Coaches diese Funktionalität, um wie beim Präsenztraining von Seminarraum zu Seminarraum oder innerhalb eines Seminarraums von Gruppe zu Gruppe zu gehen. Auch individuelle Coaching-Sessions können auf diese Weise während Live-Trainings realisiert werden. Während Offline-Trainings können Coaches bei Bedarf als Beobachter zu virtuellen synchronen Meetings hinzustoßen, wenn sie den Meeting-Zeitraum kennen oder das Meeting per Zufall im der Kanalübersicht sehen.

Ein weiteres hilfreiches Werkzeug ist ein Ticketing-System, dass die hierarchische Abbildung von Projektaufgaben und deren Beschreibung in der Iteration des Anwendungsprojekts erlaubt. Hilfreich ist, wenn das System die Aufwandschätzung und die personelle Zuordnung (Assignment) von Aufgaben erlaubt, welches die meisten gängigen Ticketing-Systeme ermöglichen. Dazu gehört in der Regel auch die dialogbasierte Kommentierung der Aufgaben durch die Nutzer. Idealerweise können die Konzepte eines agiles Vorgehensmodells wie Scrum oder Kanban abgebildet werden. Dazu gehören bei Scrum beispielsweise das Product Backlog, Sprint, Sprint Backlog, Priorisierung, User Stories, Story Points und Reporting-Typen (wie etwas das Burndown Chart). Exemplarisch sei hier auf das System Jira verwiesen, welches wir in PIPE bereits mehrfach eingesetzt haben. Aber es gibt auch andere Vertreter dieser Produktkategorie, die diese Voraussetzungen erfüllen. Die Teilnehmer nutzen in Ihrer Rolle als Entwickler, SMs oder POs das System zur Abbildung des fachlichen Ziels (Sprint Backlog, vgl. Abb. 3.6) einer Iteration und kommunizieren kontextgebunden zu den enthaltenen Projektaufgaben (User Stories, Tasks und Sub Tasks). Die Beschreibung der Aufgaben und deren initiale und Restaufwand-Schätzung ist aber eine Form von impliziter Interaktion zwischen den Projektteilnehmern. Sie ist daher wie die eigentliche Interaktion über die Kommentarfunktion von besonderem Interesse für die Coaches.

Es wurden weitere Software-Werkzeuge für die Abbildung der Domäne „Software-Entwicklung“ in den Anwendungsprojekten verwendet, die unseren bereits durchgeführten Trainings in PIPE unterlag. Dazu gehörten Werkzeuge, wie die Entwicklungsumgebung, die Versionsverwaltung oder Tools für kontinuierliche Systemintegration (Continuous Integration). Da die Software-Entwicklung aber nur exemplarisch verwendet wurde, weil es sich um einen Masterkurs in Informatik drehte, wird hier nicht näher darauf eingegangen.

3.2.4 Lernprinzipien, Zielsetzung und erwartete Ergebnisse

Die Zielsetzung von PIPE kann über die in 3.1 beschriebenen Anforderungen definiert werden, die in Tab. 3.1 noch einmal aufgelistet werden.

Tab. 3.1 Anforderungen und deren Erfüllung
Full size table

In Tab. 3.1 werden diejenigen didaktischen Lernprinzipien aufgelistet, die sich speziellen Anforderungen zuordnen lassen, wenn sie offensichtlich in diese Kategorie fallen, wie im einfachsten Fall etwa die „Individualisierung der Schulungsinhalte“ in die Kategorie des individuellen Lernens.

Des Weiteren finden folgende Lernprinzipien unabhängig von konkreten Anforderungen in 3.1 in PIPE Anwendung:

  • Erfahrungsbasiertes Lernen

  • Problembasiertes Lernen

  • Situiertes Lernen durch Einbindung von Kopräsenz und Virtualisierung bzw. Live- und Offline-Training

  • Live Coaching

  • VIST und IMOI als Anwendung auf das Trainingsprojekt

  • Effektivität des Lernens, Motivation und damit Maximierung des Lern-Outcomes

  • Durch Selbstwirksamkeit und Valenz

Die Spalte „PIPE“ in Tab. 3.1 kennzeichnet mit „Ja“ die Anforderungen, die per Definitionem, also bedingt durch die Konzeption der Lösung, erfüllt sind, wie das in diesem Abschnitt beschrieben wurde. Insofern ist davon auszugehen, dass PIPE diesen Anforderungen genügt, was durch die empirischen Ergebnisse im folgenden Kapitel untermauert wird. Das folgende Kapitel klärt auch die Frage, ob Anforderungen 1 und 2, die nicht so offensichtlich durch die Konzeption erfüllt sind, durch PIPE erfüllt werden.

3.3 Erkenntnisse

Die hier vorgestellte PIPE-Methodik wurden in den seit 2014 bis heute insgesamt sieben Mal erprobt und dabei stetig leicht anpasst. Besonders grosse Fortschritte wurden im Zeitraum 03/2018–02/2020 erzielt, in dem PIPE als Entwicklungsprojekt im Rahmen des von der Interreg geförderten IBH-Labs „Seamless Learning“ von Didaktik-Experten begleitet und beraten wurde (Mueller & Schimkat, 2017; Rapp et al., 2017). Grundlage dieser stetigen Anpassungen waren Erkenntnisse aus den vorangegangenen Trainings, die sich aus verschiedenen zum Teil bereits zuvor erwähnten Feedback-Quellen speisen. Dazu gehören das Team-Feedback im Rahmen der Retros der Live-Trainings nach jeder Iteration genauso wie die persönlichen Feedbacks der Teilnehmer im Rahmen der Individual-Coachings nach jeder Iteration.

3.3.1 Ergebnisse aus Pre-/Posttest und TAP

Im Rahmen der begleitenden Evaluationen wurden während der Phase der Projektbegleitung ein Pre-, ein Posttest primär quantitativ, und eine Teaching Analysis Poll (TAP; Gommers et al., 2019) qualitativ durchgeführt. Im Hochschulkontext wird somit ein Vergleich innerhalb der zwei betroffenen Semester „Wintersemester 2018/2019“ (15 Teilnehmer) und „Wintersemester 2019/2020“ (11 Teilnehmer) aber auch im Semestervergleich möglich. Die Teilnehmer beantworteten die Fragen im Pre- und Posttest anonymisiert über eine Umfragenplattform zu Beginn und am Ende des Trainings. Die TAP wurde jeweils durch einen der Didaktik-Experten ohne Anwesenheit der Dozenten bzw. Coaches mit den Teilnehmern durchgeführt. Insofern kann hier von unbeeinflussten, objekten Umfrageergebnissen ausgegangen werden.

Die Ergebnisse aus Pre-/Posttest und TAP lassen sich wie folgt gemäß Tab. 3.2 zusammenfassen: Beide Brüche zwischen Theorie und Praxis und zwischen dem Hochschulkontext und der Industrie werden nach Rückmeldung der Studierenden vollkommen überwunden. Alle Studierenden gaben an, dass die Veranstaltung für den späteren Beruf sehr wichtig ist (100 % der Teilnehmer) und auch eine sehr hohe Praxisrelevanz (100 %) zugeschrieben wird. Gerade für die Überwindung dieser beiden Brüche scheint die hohe Verfügbarkeit der Coaches (Dozenten und Unternehmensvertreter) von enormer Wichtigkeit. Für alle Teilnehmer war vor allem auch ein hoher Einbindungsgrad (45,5 % sehr hoch, 54,5 % hoch) der Unternehmensvertreter entscheidend. Dementsprechend werden die verschiedenen Lernoutcomes bzgl. der unterschiedlichen Lernziele als wichtig, bzw. hoch wahrgenommen. Spezielle Faktoren, die für den Outcome förderlich waren, waren beispielsweise die kurzen Feedbackzyklen zwischen den Coaches und Studierenden. Dem Feedback an sich wurde ein sehr hoher Stellenwert zugesprochen: 81,8 % der Studierenden halten dies für sehr wichtig, 18,2 % für wichtig. Dies kann auch daran liegen, dass 91 % der Teilnehmer den durch die Dozenten vermittelten Inhalt als unterstützend wahrgenommen haben. Durch diese Ergebnisse wird gleichzeitig die Bedeutung der Rolle der Coaches bestätigt.

Tab. 3.2 Zusammenfassung der wichtigsten Ergebnisse aus Pre-/Post-Test und TAP
Full size table

Darüber hinaus fallen ebenfalls der hohe Praxisbezug, sowie der rollenspiel-ähnliche Veranstaltungscharakter, der alle Rollen von Scrum beinhaltet, als wichtige Faktoren auf, die zu einem hohen Lernoutcome führen. Dabei wurde speziell die vorhandene Kundenorientierung der Projekte als besonders positiv hervorgehoben, da das Projekt nicht im geschützten Rahmen der Ausbildungsinstitution, sondern für die freie Wirtschaft entwickelt wurde und für die Studierenden dadurch eine andere Werthaltigkeit entsteht. Gleichzeitig entsteht durch das Vorhandensein eines realen Kunden eine neue Situation für die Teilnehmer, die einen gewissen Druck und ein neues Stresslevel hervorrufen kann. Das Ziel der Teilnehmer beruht nicht mehr ausschließlich darauf, eine gute Note zu bekommen. Sie nehmen zusätzlich die intrinsische Motivation wahr, ein qualitativ hochwertiges Produkt an den Kunden zu liefern. Diese neue Kundenorientierung wird ebenfalls als positiv aufgenommen und hilft dabei die Brüche zu überwinden, der geschützte und gewohnte Rahmen der Hochschule wird verlassen. Für die Teilnehmer werden Brüche auch dadurch überwunden, dass weitere Kompetenzen (unter anderem Methodenkompetenz, Handlungskompetenz, Selbstreflektion durch Feedback, Teamfähigkeit) erworben werden.

Gegenüber den positiven Wahrnehmungen kann kritisch angemerkt werden, dass die Überwindung dieser Brüche für alle Beteiligten einen zusätzlichen Zeitaufwand bedeuten kann. Gerade Studierende empfinden diesen Zeitaufwand als Herausforderung. So wurde von den Teilnehmern angegeben, dass im Laufe der Veranstaltung die größten Herausforderungen vor allem die Balance zwischen dem Studienaufwand und der Freizeit (91 %), sowie das Zeitmanagement (82 %) sind, sich dadurch also ein hoher Zeitaufwand bemerkbar machtFootnote 1. Interessant ist ebenfalls der Vergleich der Wahrnehmung vor und nach der Veranstaltung. Über alles gesehen wurden die bereits bei den Pre-Tests positiv bewerteten Aspekte in den Post-Tests noch positiver bewertet, also durch den Besuch der Veranstaltung positiv verstärkt. Darüber hinaus wird die in der Zielsetzung genannte Individualisierung des Lernens und die damit verbundenen unterschiedlichen Vorkenntnisse durch die Ergebnisse der Studierenden dargelegt. Vor der Veranstaltung ließen sich hinsichtlich verschiedener Parameter unterschiedliche Kenntnisse zwischen den Studierenden feststellen. Nach der Veranstaltung wurden ebenfalls individuelle Lernzuwächse erkenntlich, wobei hinsichtlich verschiedener Thematiken ein mittlerer bis großer Lernoutcome erzielt werden konnte. Die Studierenden konnten unabhängig des eigenen Kenntnisstandes im Rahmen der Veranstaltung unterschiedliche und individuelle Lernzuwächse erzielen.

3.3.2 Ergebnisse aus Individual-Feedbacks

Über die Jahre hinweg wurde eine große Datenmenge aus der Form der individuellen Feedbacks generiert, die sich schwer in akkumulierter Form zusammenfassen läßt. Dies liegt darin begründet, dass sie im Gegensatz zu Pre-/Post-Test und TAP unter sehr unterschiedlichen Rahmenbedingungen und zu unterschiedlichen Zeitpunkten erfasst wurden. Insbesondere letzteres macht die Vergleichbarkeit schwierig, da PIPE über die Jahre hinweg immer wieder auf Basis des Feedbacks angepasst wurde und dadurch die Daten auf einem unterschiedlichen Reifegrad der Veranstaltung erhoben wurden. Exemplarisch haben wir daher im Folgenden zwei spezielle Auszüge aus dieser Feedback-Datenbasis zusammengestellt, die aber aus unserer Sicht durchaus repräsentativen Charakter haben.

Im ersten Auszug wurden einem einzelnen Teilnehmer der Veranstaltung des WS 19/20 dediziert Themen genannt, zu denen er beliebig Stichpunkte äußern konnte, die ihm dazu einfielen. Die Ergebnisse werden in Tab. 3.3 dargestellt.

Tab. 3.3 Zusammenfassung eines Individual-Feedbacks zu dedizierten Themen – Teil 1
Full size table

Im zweiten Auszug wurden die Teilnehmer der Veranstaltung im WS 20/21 individuell nach den wichtigsten positiven und negativen Hinweisen zur Veranstaltung befragt. Die Befragung jedes Teilnehmers wurde nach der ersten Iteration (Sprint) durchgeführt und spätestens nach vier Hinweisen beendet. Es ist daher davon auszugehen, dass jeder Teilnehmer die jeweils persönlich wichtigsten Aspekte zuerst genannt hat und wir daher einen repräsentativen Querschnitt erhalten. Nach der Befragung wurden thematische Cluster aus den Hinweisen gebildet und die entstehenden Kategorien mit einem Titel versehen, der die enthalten Hinweisen bestmöglich repräsentiert. Die Ergebnisse werden in Tab. 3.4 dargestellt.

Tab. 3.4 Zusammenfassung eines Individual-Feedbacks zu dedizierten Themen – Teil 2
Full size table

Dies lässt sich wie folgt interpretieren: N1–4, N6/7 und N9/10 sind Aspekte, die von den Teilnehmern selbst unter dem Aspekt „ins kalte Wasser geworfen“ subsumiert und negativ bewertet wurden. Zum einem gewissen Grad ist das so von den Coaches gewollt, da wir einen höheren Realitätsgrad erreichen wollen und authentischere Reaktionen bei den Teilnehmer zu bestimmten Zeitpunkten erreichen wollen. Die ist bei sehr guter Vorbereitung der Teilnehmer nicht immer gesichert und daher der „Wurf ins kalte Wasser“ zu einem Teil als didaktisches Mittel aufzufassen. Der Aspekt „hoher Aufwand“ (N11/N17) tritt auch hier wieder auf und ist etwas, was bei der Komplexität und Vielfältigkeit dieser Veranstaltung schwer vermeidbar ist. Erst durch diesen zusätzlich investierten Aufwand wird der Mehrwert wahrnehmbar, den die Teilnehmer als positiv bewerten. Alle anderen als „negativ“ bewerteten Aspekte sind organisatorischer oder Corona-bedingter Natur und sicherlich optimierbar.

Die Prozentzahlen können folgendermaßen bewertet werden: Bei der Befragung wurden die Kategorien in keiner Weise vorgegeben und auch keine Beispiele für Kategorien genannt. Die 38,9 % bei „Realitätsnähe“ (P4) beispielsweise bedeuten also nicht, dass 2/5 der Teilnehmer die Realitätsnähe als positiven Aspekt der Veranstaltung betrachten, während die restlichen 3/5 es nicht so sehen. Es bedeutet vielmehr, dass knapp 2/5 der Teilnehmer dies als einen der ersten positiven wie negativen drei/vier Punkte nennen, wenn sie ad-hoc antworten sollen. Insofern sind sicher alle genannten Kategorien in der Rubrik „Positiv“ als wesentliche Faktoren zu interpretieren, die die Teilnehmer an der Veranstaltungsform schätzen. Besonders interessant sind Kategorien, die mehr als 10 % der Teilnehmer unter den wichtigsten 3 bis 4 Aspekten sehen.

Zusammenfassend lässt sich feststellen, dass die Ergebnisse aus Individual-Feedbacks erstaunliche Übereinstimmungen mit den unbeeinflussteren Ergebnissen der anonymisierten Befragung der Pre-/Post-Tests und den TAPs aufweisen. Es ist sehr gut erkennbar, dass die Teilnehmer genau die Aspekte an der Veranstaltungsform schätzen, die wir als Anforderung an die Veranstaltung „PIPE“ in 1.1 definiert haben. Das ist insofern bemerkenswert, als dass wir diese Anforderungen an die Veranstaltung in keiner der Befragungen implizit oder gar explizit genannt haben. Insbesondere die Anforderung 1 Überwindung des Bruchs „Theorie vs. Praxis“ und Anforderung 2 Überwindung des Bruchs „Ausbildung vs. Unternehmen“, die nicht per Definitionem durch die Konzeption von PIPE gegeben sind (s. 1.2.4), können als erfüllt angesehen werden, da sie in allen oben genannten Ergebnissen durch die Teilnehmer als Mehrwert der Veranstaltung wahrgenommen werden.

3.4 Fazit

Die vorgestellte Trainingsmethode für Projektmanagement PIPE ist ein Ansatz für agiles Vorgehen, Kommunizieren und Lernen in verteilten Teams. Projektmanagement ist eine Schlüsselkompetenz und Verteilung in Teams, allgemeiner die Virtualisierung von Teams, ist bereits heute stark verbreitet und wird in Zukunft deutlich zunehmen. Der iterativ-inkrementellen Struktur agiler Vorgehensmodelle folgend werden in PIPE zwei wesentliche Lernkonzepte engmaschig miteinander verwoben. So werden einerseits Theorie- und Praxis-Phasen feingranular unterteilt und gegenseitig aufeinander Bezug nehmend verzahnt. Andererseits wird in zwei zeitlich und inhaltlich synchronisierten Projekten, dem Anwendungs- und dem Trainingsprojekt, von den Teilnehmern Anwendungs- und Lernziele mitdefiniert und umgesetzt. Die Anwendungsziele des Anwendungsprojekts kamen in allen bisherigen Trainings aus der Domäne der Software-Entwicklung und wurden von den Industriepartnern vorgegeben, die wiederum ein integraler Bestandteil von PIPE sind. Während die Anwendungsziele in der Regel für ein gesamtes Team unter den Teilnehmern gelten, sind die Lernziele des Trainingsprojekts häufig für einzelne Teilnehmer individualisiert. Ein differenziertes Rollenkonzept ermöglicht Lernenden bzw. Lehrenden, unterschiedliche Rollen während des mehrwöchigen Trainings zu erproben bzw. einzunehmen. Die Industriepartner nehmen dabei gleichzeitig die Rolle der Coaches und der Auftraggeber (Chief Product Owner) ein. Ein erfolgskritischer Aspekt im Projektmanagement ist die Interaktion (Kommunikation, Kooperation und Kollaboration) insbesondere bei virtualisierten Teams. Mithilfe geeigneter Software-Werkzeuge werden spezifische Interaktionskonzepte und -Szenarien in Teams unter Virtualisierung nachgebildet, von den Coaches beobachtet und trainiert. Engmaschiges wechselseitiges Feedback zwischen Coaches und Teilnehmern ermöglicht direktes Ausprobieren von angepassten individuellen Verhaltensweisen in Bezug auf die Interaktion und das agile Vorgehen im Projekt. Die Übergänge zwischen den Iterationen (Sprint) sind naturgemäß ein Zeitpunkt, an dem aufgrund von team-basiertem und individuellem Feedback die Ziele angepasst werden. Hier wird zudem mehr Realitäts- und Praxisbezug eingeführt und den Teilnehmer schrittweise nahegebracht.

PIPE wurde in den letzten Jahren bereits mehrfach in Form eines Masterkurses im Hochschulkontext erprobt und evaluiert. Es werden eine Vielzahl von didaktischen Lehrkonzepten kombiniert angewandt, darunter vor allem situiertes Lernen, individuelles Lernen, erfahrungs- und problembasiertes Lernen. Auch neuere eher aus der Arbeitspsychologie bekannte Konzepte, wie VIST und IMIO, werden auf diesen agilen, verteilten Projektkontext angewandt. Die umfangreiche Feedback-Datenbasis der Teilnehmer aus den letzten Jahren hat immer wieder zu leichten Optimierungen des PIPE-Konzepts geführt. Es läßt aber vor allem erkennen, dass der bei der Konzeption anvisierte Lern- und Kompetenzgewinn in Bezug auf Praxiserfahrung und Realitätsbezug aus der Teilnehmersicht besser als in jedem anderen ihnen bekannten Lehrkonzept erreicht wird. Die Evaluationsergebnisse (für den späteren Beruf wichtig: 100 % der Teilnehmer; sehr hohe Praxisrelevanz: 100 % der Teilnehmer) lassen den Schluss zu, dass der Bruch „Theorie vs. Praxis“ und der Bruch „Ausbildung vs. Unternehmen“ im Sinne des „Seamless Learning“ in überzeugender Weise adressiert wird. Die Teilnehmer sind sich einig darüber, dass es sich bei diesem Lehrkonzept um eine sehr motivierende und spannende Veranstaltung handelt. Sie bemängeln neben dem eigenen Aufwand im Wesentlichen Dinge, die sich durch kleine organisatorische Korrekturen im Konzept zukünftig verbessern lassen sollten oder schon verbessert wurden.

Bedingt durch den intensiven, individualisierten Trainings- und Beratungsansatz von PIPE mit hoher Feedback-Frequenz ist offensichtlich, dass das Konzept nicht beliebig in der Anzahl der Teilnehmer skaliert. Dafür impliziert es aber im Vergleich zu besser skalierenden Konzepten eine deutliche gesteigerte Nachhaltigkeit im Sinne einer hohen Rate beim Lern- und Kompetenzgewinn der Studierenden. Die Kenntnis, der Umgang und ggf. die Administration von modernen Kommunikationswerkzeugen bei den Lehrenden ist eine Voraussetzung für die Umsetzung von PIPE, wird aber in der heutigen Zeit immer selbstverständlicher.

Bedingt durch die Konzeption ist PIPE nicht auf die Informatik oder gar Software-Entwicklung beschränkt. Es ist davon auszugehen, dass eine Anwendung dieses Ansatzes ausserhalb der Projektmanagement-Ausbildung in anderen Aus- und Weiterbildungbereichen immer dann problemlos möglich ist, wenn die spätere Anwendung der vermittelten Lernthematik einen projektartigen Charakter enthält. Spannend bleibt die Frage, inwieweit eine Anwendung auf die Aus- und Weiterbildungbereiche möglich ist, in denen es nicht explizit um projektbasiertes Arbeiten geht, aber ein projektbasierter Kompetenzerwerb vorliegt oder umsetzbar ist.