Pling! Rückblende in das Jahr 2013: Immer mehr agile Projektansätze tauchen auf. Scrum ist zwar etabliert, aber noch längst kein Standard. In vielen Projekten ist man stattdessen noch „klassisch“ nach Wasserfall unterwegs – genauso wie in meinem damaligen. Ich sitze also seit zwei Monaten am Pflichtenheft für das neue Release eines IT-Systems und werde für die geschätzten 80-100 Seiten wohl auch noch einige Zeit sitzen. Jeder Use Case, jede Maske, jeder Button, jeder Edge-Case wird detailliert beschrieben. Ohne eine einzige Zeile Code zu schreiben. In solchen klassischen Softwareprojekten war die Aufgabenverteilung zwischen Kunde und Dienstleister meist recht eindeutig geklärt: Der Dienstleister schreibt das Pflichtenheft, der Kunde nimmt es ab. Der Dienstleister entwickelt daraufhin die Software, der Kunde nimmt sie ab. Das war wenig flexibel, denn nur im Pflichtenheft detailliert niedergeschriebene Aspekte konnten auch in der späteren Software umgesetzt werden. Dafür gab es mit den Abnahmen jedoch sehr eindeutige Checkpoints: Der Kunde musste sich die Zeit für die Abnahme des Pflichtenheftes nehmen, da man sonst mit der Entwicklung der Software nicht beginnen konnte.

Heutzutage sind Wasserfallprojekte im IT-Bereich nur noch vereinzelt zu finden, stattdessen setzen viele Vorhaben auf agile Frameworks wie zum Beispiel Scrum. Das macht den Ablauf deutlich flexibler, da man Vereinbarungen und passende Realisierung in deutlich kleineren Zyklen umsetzen kann. Das führt nicht zwingend zu kürzeren Projektlaufzeiten, aber zu kürzeren Feedbackschleifen und damit zu einem Projektergebnis, das oft näher am Kundenwunsch liegt. Das flexiblere Vorgehen bringt allerdings auch Herausforderungen mit sich – und zwar nicht nur inhaltlich und zeitlich, sondern auch in Bezug auf die Teamaufstellung zwischen Kunde und Dienstleister. Während früher die Teams meist komplett getrennt waren, gibt es in heutigen agilen Projekten verschiedene Möglichkeiten für die Teamzusammensetzung. Diese oft enge Verzahnung von Teams über Unternehmensgrenzen hinweg beleuchtet auch die Studie „Digitalisierung und Softwareinvestition“ [1]. In der Auswahl von externen IT-Dienstleistern ist demzufolge den beauftragenden Unternehmen die „kollegiale Zusammenarbeit ohne große hierarchische Grenzen“ und „gemeinsames Arbeiten“ besonders wichtig (Abb. 1).

Abb. 1: Kommunikation und Zuverlässigkeit sind zentrale Erwartungen in der Zusammenarbeit mit externen IT-Dienstleistern [1]

Diese enge Zusammenarbeit zwischen Kunde und Dienstleister bietet sowohl Vorteile als auch Herausforderungen, auf die im weiteren Verlauf des Artikels näher eingegangen wird. Für Projektleiter:innen ist vor allem die Frage relevant, wie Verantwortung und Steuerung im Mixed Team sinnvoll verteilt werden können, sodass alle Teammitglieder konsequent auf das gleiche Projektziel hinarbeiten. Als Mixed Teams sind hier Projektteams zu verstehen, in denen Mitarbeitende von Kunden- und Dienstleisterseite gemeinsam, interdisziplinär und möglichst ohne künstliche Trennung auf ein Ziel hinarbeiten.

Zwei Welten, ein Ziel: wenn Business und IT aufeinandertreffen

Die Mitarbeitenden beider Parteien haben unterschiedliche Backgrounds, Ausbildungen und Erfahrungen. Das führt dazu, dass im gemeinsamen Projekt ggf. deutlich verschiedene Wissensgebiete aufeinandertreffen. Der Dienstleister beispielsweise hat oft Expertenwissen zu Technologien wie etwa KI, Cloud, bestimmten IT-Produkten usw. Der Kunde hingegen hat ausgiebiges Wissen in seiner Fachdomäne, also etwa Automotive, Telekommunikation, Bankenwesen usw. Für ein erfolgreiches Projekt braucht es beides: Fach- und IT-Know-how. Gerade diese Kombination führt zu besonders innovativen Lösungen [2], weil sich fachliches und technisches Know-how sinnvoll ergänzen. Je weniger „weiße Flecken“ es dabei gibt, desto wahrscheinlicher ist ein Projektabschluss im Rahmen des magischen Dreiecks (Time, Budget, Scope) oder Fünfecks (zzgl. Qualität und Team, Abb. 2). Zusätzlich führt Austausch und gegenseitiges Lernen über die Unternehmensgrenzen hinweg zu einem erweiterten Horizont. Außerdem steigert die hierdurch erlangte thematische Abwechslung die Motivation der Teammitglieder auf beiden Seiten.

Abb. 2: Das magische Fünfeck definiert fünf Zieldimensionen für ein Projekt: Team, Leistung, Qualität, Termin und Budget

Kurze Wege, bessere Ergebnisse: Der Draht zum Anwender zählt

In klassischen Softwareprojekten, bei denen die Umsetzung vollständig durch einen externen IT-Dienstleister erfolgt, gestaltet sich der direkte Austausch mit zentralen Stakeholdern, insbesondere mit den späteren Anwendern, oft schwierig. Oft kommuniziert der Projektleiter des Dienstleisters mit dem Projektleiter auf Kundenseite, der wiederum als Mittelsmann zwischen Dienstleister und Nutzer fungiert. Diese mehrstufige Kommunikationskette erschwert nicht nur die Verständigung, sondern verlangsamt auch die Feedback-Zyklen erheblich. Schnelles, iteratives Arbeiten wird dadurch zur Herausforderung.

Ganz anders sieht es in Mixed Teams aus, in denen Mitarbeitende des Dienstleisters und des Kunden gemeinsam an der Umsetzung arbeiten. Hier lassen sich wesentlich direktere und belastbarere Kommunikationswege etablieren – nicht nur auf Managementebene, sondern auch zwischen Fachexperten. So können beispielsweise Software-Engineers direkt mit Anwendern und Anwenderinnen in den Dialog treten, um Anforderungen besser zu verstehen, Nutzungskontexte nachvollziehbar zu machen und frühzeitig Rückmeldung zu erhalten. Dieser unmittelbare Austausch fördert nicht nur die Qualität des Endprodukts, sondern erhöht auch das gegenseitige Verständnis und die Identifikation mit dem gemeinsamen Projektziel. Der direkte Kontakt zum Nutzer sorgt dafür, dass Teammitglieder die Auswirkungen ihrer Arbeit unmittelbar erleben. Das erhöht die intrinsische Motivation durch das Erleben von Wirksamkeit [3].

Gemeinsam starten: damit keiner später mit dem Finger zeigt

In einer idealen Welt verlaufen Projekte problemlos und im Rahmen des Drei- bzw. Fünfecks. Es gibt keine neuen Anforderungen, keine Notwendigkeit zu priorisieren und keine technischen Probleme. Wenn es aber, wie in den meisten größeren Projekten, zu Änderungen und Verschiebungen während der Laufzeit kommt, kann eine trennscharfe Front zwischen Kunde und IT-Dienstleister Schuldzuweisungen begünstigen: „WIR wären ja fertig geworden, wenn DIE denn alles fristgerecht geliefert hätten“. In gemischten Teams hingegen sitzen alle Projektmitglieder sprichwörtlich im gleichen Boot. Das gilt umso mehr, je stärker die Teams gemischt sind. Ein Beispiel für eine starke Mischung ist, wenn Software-Engineers sowohl vom Kunden als auch vom Dienstleister im gleichen Team agieren. In solchen Konstellationen haben beide Parteien die Möglichkeit, gestalterisch in den Projektverlauf einzugreifen. Abgesehen von diesem planerischen Aspekt entsteht auf der menschlichen Ebene ein stärkeres Wirgefühl, je verzahnter und gemischter das Team zusammengesetzt ist. Für die transparente Darstellung von Verantwortung dient die RACI-Matrix (Abb. 3). RACI steht hierbei für die Anfangsbuchstaben von Responsible (verantwortlich), Accountable (verantwortlich für das Ergebnis), Consulted (konsultiert) und Informed (informiert) [4].

Abb. 3: Die RACI-Matrix zeigt übersichtlich, wer für welche Themen verantwortlich ist und wo es Lücken gibt

Entscheiden statt eskalieren: warum gute Teams nicht immer fragen müssen

In klassischen Projekten zwischen Kunde und Dienstleister verläuft vieles sequenziell. Anforderungen werden gesammelt, weitergereicht, umgesetzt – oft mit erheblicher Verzögerung zwischen Bedarf und Reaktion. Doch gerade in dynamischen IT-Projekten funktioniert dieses Modell nicht mehr. Anforderungen ändern sich – und das oft kurzfristig. Rahmenbedingungen verschieben sich. Neue Erkenntnisse tauchen auf, sobald man beginnt, das erste Feature zu implementieren. Gemeinsame Teams schaffen hier echte Flexibilität, da das gemeinsame Arbeiten auf Augenhöhe spontane Entscheidungen erlaubt. Nicht jede Frage braucht ein neues Ticket oder eine Rücksprache auf Managementebene. Oft reicht ein kurzes Gespräch im Daily, ein schneller Slack-Call oder ein gemeinsames Whiteboard. Wenn beide Seiten im Projekt tatsächlich Verantwortung übernehmen, trifft das Team Entscheidungen direkt vor Ort – schnell und fundiert. Was gestern noch Prio 1 war, kann heute bewusst zurückgestellt werden, weil etwas anderes dringender ist. Statt Blockaden entstehen damit Beweglichkeit und ein echtes Reaktionsvermögen auf neue Herausforderungen – fachlich, technisch und organisatorisch. Wichtig ist dabei: Mit „Flexibilität“ ist hier nicht „Chaos“ gemeint, sondern moderierte Beweglichkeit. Ein Mixed Team kann schneller navigieren, weil es sich nicht ständig gegenseitig erklären muss, was warum wie entschieden werden soll.

Blinder Fleck ade: Mixed Teams sehen mehr Risiken

Das Risikomanagement kann nach PM3 [5] in IT-Projekten nach folgendem Ablauf erfolgen:

1. Projekt-/Risikostrategie

2. Identifikation

3. Analyse und Bewertung

4. Steuerung

5. Controlling

Vor allem in den Punkten 2-4 ist es von Vorteil, Aspekte aus zwei verschiedenen Perspektiven zu betrachten. Das führt einerseits dazu, dass in der Identifikation, z. B. durch Methoden wie Mind Mapping oder Brainstorming, deutlich mehr Risiken aufgedeckt werden. Während der Kunde oft fachliche Risiken aufdeckt („Use Case X mit Eingangsdaten Y nicht ausführbar“), findet der IT-Dienstleister vermehrt die technischen und architektonischen Risiken eines IT-Systems (Performance, Skalierbarkeit, Stabilität, Ausfallsicherheit). Bei der darauffolgenden Bewertung von insbesondere technischen Risiken kann der IT-Dienstleister dann hilfreiche Hintergründe liefern, warum etwa der Aufbau von technischen Schulden später Probleme bereiten kann und somit mehr ist als nur ein Schönheitsfehler. Auch bei der Steuerung der Risiken bringt der IT-Dienstleister seine Erfahrungen aus anderen Projekten ein und trägt damit zu passgenauen Maßnahmen bei.

Die Medaille der gemischten Teams hat jedoch zwei Seiten, denn den genannten Vorteilen stehen durchaus einige Herausforderungen gegenüber. Die Kunst des richtigen Teamaufbaus besteht darin, diese gut gegeneinander abzuwägen. Idealerweise kann man dabei die Vorteile ausbauen und stärken und die Herausforderungen minimieren.

Kommunikation ohne Chaos: Wenn alle reden, aber keiner weiß mit wem

Besteht ein Team lediglich auf einer der beiden Seiten, sind die Kommunikationsstrukturen meist sehr klar und für alle Beteiligten transparent. Die Best Practices für die Aufbauorganisation von Projekten (Projektleiter, Architektin, Software-Engineers, Scrum Master, Product Owner, …) sind bekannt und es gibt gewisse Regeln und Gepflogenheiten, an die sich alle halten. Jedes Teammitglied weiß, zu welcher Frage wer im Team angesprochen werden kann und Änderungen an der Teamstruktur sind für alle Teammitglieder gut und schnell nachvollziehbar. In gemischten Teams ist es deutlich anspruchsvoller, eine einheitliche Kommunikationsstruktur zu etablieren. Einige Beispiele dafür sind:

• Kann etwa jeder Software-Engineer direkt mit dem Product Owner auf Kundenseite sprechen oder gibt es dafür passende Meetings?

• Wie gelangen Anforderungen an die Software-Engineers? Ist der Product Owner SPOC (Single Point of Contact) oder sprechen Stakeholder direkt mit Software-Engineers?

• In welchem Kreis erfolgen Sprint Planning und Sprint Reviews? Sind alle relevanten Teilnehmer eingebunden – aber auch nicht mehr?

Die Frage, wer wann mit wem redet, ist von zentraler Bedeutung. Ein Kommunikationsplan schafft hier Klarheit. Dieser sollte direkt in der Projektinitialisierung aufgesetzt werden. Darin ist abzulesen, welche Meetings existieren, welche Ziele diese haben und wer daran teilnehmen sollte. Auch regelmäßige Reports (die monatliche Auswertung der umgesetzten Story Points an den Product Owner oder ähnliches) zählen dazu. Das Team trägt alle Informationen dort ein und sorgt damit für maximale Transparenz. Die Darstellung kann sowohl tabellarisch als auch grafisch erfolgen, in Abhängigkeit der Teamgröße und -strukturen. Bei einer grafischen Darstellung (Abb. 4) kann die Dicke der Linien die Häufigkeit, die Farbe die Art der Kommunikation und die Hintergrundfarbe die Unternehmenszugehörigkeit abbilden. Ohne solche abgestimmte Kommunikationsregeln sind Mixed Teams ineffizienter als klassische Vorgehensmodelle.

Abb. 4: Ein grafischer Kommunikationsplan zeigt durch Verbindungslinien regelmäßige Kommunikation im Team auf

Wenn „Sie“ auf Slack trifft: Kulturkonflikte im Projektalltag

Firmenkulturen können viele Facetten haben: Vom klassischen „Du oder Sie?“ über den üblichen Kleidungsstil im Büro bis hin zum Umgangston. Auch in den internen Kommunikationswegen, der Art der möglichen Mitwirkung im Unternehmen, dem gegenseitigen Vertrauen und der Gehaltstransparenz kann es deutliche Unterschiede geben. Jedes Unternehmen hat seine eigene Kultur, seinen eigenen „Style“ – und das ist auch gut so. Das gleiche gilt für die Arbeitsmethoden: Was sind die im Alltag genutzten Tools? Was sind übliche Meetingabläufe von z. B. einem Scrum Daily? Was sind die Aufgaben des Scrum Masters oder Product Owners in einem agilen Team? Wie flexibel sind die Arbeitszeiten? Wie läuft die Zusammenarbeit im Team? Vielen Unternehmen ist nicht bewusst, wie breit das Spektrum an dieser Stelle ist. Oft wird angenommen, dass die eigene Unternehmenskultur der Normalfall ist. Oft ignorieren Teams unbedacht mögliche Alternativen. Wichtig wird dieses Bewusstsein allerdings, wenn man in einem gemischten Team zusammenarbeitet. Dabei geht es im ersten Schritt darum, die Bedürfnisse der Teammitglieder zu sehen und dafür Verständnis aufzubringen. Im Umkehrschluss ist es wichtig, die eigenen Bedürfnisse möglichst deutlich und präzise mitzuteilen, um Missverständnisse und falsche Annahmen zu vermeiden. Das Verständnis auf der einen und die Offenheit auf der anderen Seite ermöglichen dann idealerweise für alle Kategorien von möglichen Unterschieden Mittelwege, die von allen Beteiligten akzeptiert werden können.

Prioritäten setzen: Aber bitte nicht aus dem Bauch heraus

Vor allem in agilen Projekten steht die Priorisierung von Anforderungen weit oben auf der Tagesordnung. Und: In den meisten Fällen gibt es deutlich mehr User Stories im Backlog als Platz in den nächsten Sprints. Es führt somit kein Weg daran vorbei, sich immer wieder für die einen und gegen die anderen Themen zu entscheiden. Das Team sollte diese Entscheidungen aktiv und begründet treffen, da nur so das Projekt sinnvoll gesteuert werden kann. Bleiben die bewussten Entscheidungen aus, arbeitet das Team vielleicht trotzdem weiter und setzt User Stories um – der daraus generierte Mehrwert für die Stakeholder bleibt aber durch fehlende Fokussierung auf der Strecke. Auf den ersten Blick scheint Thema A klar wichtiger als Thema B. Verschiedene Erfahrungen und Hintergrundwissen in einem gemischten Team führen jedoch zu deutlich unterschiedlichen Priorisierungen. Während der IT-Dienstleister technische Details oft fundierter beurteilen kann, obliegt das dem Kunden für die Aspekte seiner Businesslogik. Bei vielen Priorisierungsentscheidungen haben beide Aspekte einen wichtigen Anteil. Für den Kunden kann es deshalb herausfordernd sein, eine ganzheitliche Entscheidung zu treffen, in der alle Perspektiven berücksichtigt werden. Aus Sicht der Projektverantwortlichen ist es deshalb besonders wichtig, die verschiedenen Perspektiven als Mehrwert und nicht als Widerspruch zu betrachten, durch die die Priorisierung ganzheitlicher und damit idealerweise besser wird.

Erreichbarkeit ist kein Zufall: wie Teams Planbarkeit schaffen

Flexibilität, Work-Life-Balance, Parallelprojekte – die Notwendigkeit von Koordination zwischen den Projektmitgliedern ist im Alltag ständig präsent. Insbesondere in Zeiten von Teilzeit und Remote Work ist es nicht selbstverständlich, dass Teammitglieder zwischen 9 und 17 Uhr tatsächlich zuverlässig erreichbar sind. Mittwochs eine längere Mittagspause? Donnerstags den Knirps zum Kindergarten bringen? Oder einfach aufgrund von 80 Prozent Arbeitszeit montags frei? Die transparente Pflege von Verfügbarkeiten über Firmengrenzen hinweg ist allerdings oft schwierig, da nur in seltenen Fällen beide Seiten Zugriffe auf die Kalender der jeweils anderen Seite haben. Wenn also der Scrum Master Urlaub in seinen Kalender eingetragen hat, sehen das meist nur die Teammitglieder aus dem eigenen Unternehmen.

• Wie kann ein gemeinsamer Urlaubs- und Terminkalender gepflegt werden?

• Wie werden reduzierte Verfügbarkeiten wie Teilzeitarbeit, parallellaufende Projekte oder Linientätigkeiten transparent gemacht?

• Wie können spontane Abwesenheiten wie Arztbesuche, Notbetreuung im Kindergarten oder Handwerker im Haus zuverlässig im Team geteilt werden?

Als hilfreich erwiesen hat sich die gemeinsame Nutzung des gleichen Messengers für alle Teammitglieder (MS Teams, Slack, …) und die dortige Pflege von Abwesenheiten, beispielsweise über den Status. Das kann eine doppelte Datenpflege sein (Kalendereintrag und Teams-Status), der Mehrwert allerdings ist deutlich spürbar und reduziert merklich das Risiko von Missverständnissen.

Damit es wieder „mein Projekt“ wird: warum Identifikation kein Zufall ist

Manche IT-Dienstleister arbeiten aufgrund vieler paralleler Projekt diese oft nur noch nach Schema F ab. Sie erscheinen zunehmend namenlos und austauschbar. Sie vermeiden Ownership zum Beispiel aus Selbstschutz. Fehlende Identifikation mit dem Projekt kann auch auf Kundenseite passieren, wenn etwa ein Product Owner für mehrere Projekte parallel zuständig ist. Die Identifikation mit dem Projekt schwindet, und damit auch die intrinsische Motivation, etwas besonders gut umzusetzen oder auch mal über den Tellerrand hinauszuschauen. Die Beteiligten verlieren den Bezug zu ihrem Projekt. Es ist nicht mehr „mein Projekt“, sondern nur noch eines von vielen. Zusammen mit anderen Teammitgliedern entsteht durch gemeinsame Ownership ein Gemeinschaftsgeist, bei dem man auch mal für andere mitdenkt und sich engagiert. Um die Identifikation mit dem Projekt zu fördern, können beispielsweise Teamrituale eingeführt werden, ein gemeinsames Projektlogo entworfen und im Allgemeinen eine Teamkultur gepflegt werden.

Agil, aber legal: wie Mixed Teams rechtssicher funktionieren

Die rechtlichen Rahmenbedingungen für den Einsatz von IT-Dienstleistern in agilen Teams sind vielfältig und kompliziert. Die Risiken sind vor allem: Illegale Arbeitnehmerüberlassung und Scheinselbstständigkeit von Freelancern. Der Kunde muss strenge Regeln definieren und konsequent umsetzen, um das Eintreten dieser Risiken zu verhindern. Das beginnt bei Rollenbeschreibungen im Vertrag und endet bei klarer Trennung von Steuerungsverantwortung und operativer Zuweisung im Teamalltag.

Vergleichsweise einfach und unverfänglich ist es, Leiharbeiter in gemischten Teams einzusetzen. Sie unterliegen dem Weisungsrecht des Kunden und können damit nahtlos in eine Projektstruktur integriert werden. Problematisch könnte hier die maximale Überlassungsdauer von 18 Monaten (AÜG) sein, die für viele Projekte nicht ausreichend ist. Der Einsatz von Mitarbeitenden von IT-Dienstleistern und Freelancern hingegen birgt die Gefahr, dass abhängige Beschäftigungsverhältnisse entstehen. Um das zu vermeiden, sind explizite Weisungen an das externe Personal sowie dessen unmittelbare Einbindung in die Organisationsstruktur des Kunden zu unterlassen. Diese Einschränkung stellt die Zusammenarbeit vor spürbare Herausforderungen, da insbesondere die enge Interaktion im Team ein Erfolgsfaktor von agilen Projekten ist [6].

Die nachfolgend beschriebenen Ansätze zur Bewältigung dieser Einschränkungen sind von der jeweiligen rechtlichen Detailsituation abhängig. Sie stellen ggf. nur eine Auswahl der notwendigen Maßnahmen dar und sollten deshalb vor dem Einsatz spezifisch für das betreffende Projekt rechtlich bewertet werden:

• Explizite Benennung als „externe Unterstützung“, zum Beispiel durch den Zusatz „Extern“ in der E-Mail-Adresse oder im Benutzernamen im Messenger.

• Pflege der extern umzusetzenden Arbeiten in einer separaten Liste, zum Beispiel in einem eigenen Jira-Projekt/-Board

• Idealerweise werden nicht einzelne User Stories, sondern ganze Epics an den IT-Dienstleister zur Umsetzung übergeben. Das ermöglicht das selbstständige Arbeiten ohne viele einzelne Anweisungen.

Fazit

Was ist also die bessere Wahl für ein IT-Projekt: ein klassisches Projekt-Set-up oder ein gemischtes Team? Wie zuvor dargestellt, birgt ein „Mixed Team“ durchaus Herausforderungen, die ein Projekt ins Wanken bringen können, wenn sie nicht aktiv adressiert werden. Demgegenüber stehen jedoch klare Vorteile: Direktere Kommunikation, kürzere Feedbackzyklen und eine höhere Identifikation aller Beteiligten mit dem Projektziel. Diese Effekte lassen sich in rein klassischen Set-ups oft nur schwer erzielen. Vorausgesetzt, das Projekt eignet sich grundsätzlich für ein gemischtes Team – etwa, weil keine strengen Vorgaben zur Geheimhaltung oder Compliance entgegenstehen – und das Management ist bereit, sich den damit verbundenen Herausforderungen konstruktiv zu stellen, kann das „Mixed“-Modell einen erheblichen Mehrwert für alle Beteiligten bieten.

Mixed Teams sind wahrlich keine Selbstläufer. Wer sie aber bewusst gestaltet, kann damit nicht nur Projekte erfolgreicher machen, sondern auch die Zusammenarbeit auf ein neues Level heben. Wer Mixed Teams einsetzen will, sollte frühzeitig klären: Wie kommunizieren wir? Wer priorisiert? Wer gibt Orientierung im Alltag?

Links & Literatur

[1] techconsult GmbH: „Digitalisierung und Softwareinvestition: Worauf es ab 2025 für DACH-Unternehmen ankommt“

[2] Van Knippenberg, D.; De Dreu, C. K. W.; Homan, A. C. : „Work group diversity and group performance: An integrative model and research agenda“; in: Journal of Applied Psychology 89(6), 2004

[3] Ryan, R. M.; Deci, E. L.: „Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being“; in: American Psychologist 55(1), 2000

[4] Project Management Institute (PMI): „A Guide to the Project Management Body of Knowledge“; 2021

[5] GPM Deutsche Gesellschaft für Projektmanagement: „Kompetenzbasiertes Projektmanagement (PM3): Handbuch für die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline Version 3.0“; 2014

[6] Haufe Online Redaktion. (o. D.). Einsatz von Fremdpersonal im Rahmen der agilen Zusammenarbeit. Abgerufen am 10. Juni 2025, von https://www.haufe.de/id/beitrag/einsatz-von-fremdpersonal-im-rahmen-der-agilen-zusammenarbeit-HI13675551.html