Zum Hauptinhalt springen

Abnahmekriterien im Projekt: Mit Definition of Done und Akzeptanzkriterien zu klarer Projektabnahme und sauberem Projektabschluss

27.08.26Ungefähr 10 minblogProjektmanagement


Du kennst das vielleicht: Ein Projektteam arbeitet wochenlang konzentriert an einer Lösung, die Vorfreude auf das Ergebnis steigt und bei der Abnahme kippt plötzlich die Stimmung. Auf einmal tauchen Erwartungen auf, die nie sauber ausgesprochen wurden. Das Team sagt: „Eigentlich ist doch alles fertig." Der Auftraggeber sagt: „Für mich noch nicht." Und schon steckt ihr in Diskussionen, die niemand gebraucht hätte.

Genau an dieser Stelle werden klar vereinbarte Maßstäbe im Projekt entscheidend. Sie helfen dir nicht nur dabei, Qualität sichtbar zu machen. Sie schaffen vor allem ein gemeinsames Verständnis davon, was „fertig" eigentlich bedeutet. Wenn du dafür zusätzlich mit einer Definition of Done und klaren Akzeptanzkriterien arbeitest, verhinderst du Missverständnisse, Frust und unnötige Schleifen schon viel früher.

Wichtig ist dabei das richtige Framing: Eine gute Definition of Done ist nicht bloß ein Schutzschild für schwierige Gesprächspartner oder ein Vertrag, mit dem sich jemand absichern will. Sie ist viel hilfreicher, wenn du sie als Empathie-Werkzeug verstehst. Sie bringt Entwickler-Team, Projektleitung, Kunde und externe Partner auf Augenhöhe zusammen. Nicht gegeneinander, sondern miteinander.

Das erfährst du in diesem Artikel

  • Was sind Abnahmekriterien im Projekt und wie sichern sie Projektergebnisse für den Auftraggeber?
  • Definition of Done, Akzeptanzkriterien und Abnahmekriterien: Was ist der Unterschied?
  • Warum so viele Projekte bei der Abnahme unnötig Reibung erzeugen
  • Warum eine klare Definition of Done ein Empathie-Werkzeug ist
  • So definieren du und dein Auftraggeber die Definition of Done als verbindliches Abnahme-Dokument
  • So entwickelst du Abnahmekriterien in 5 Schritten - inklusive kostenloser Vorlage
  • Messbare Abnahmekriterien formulieren: Worauf du achten solltest
  • Testfälle, Übergabeprotokoll, Abnahmeprotokoll und Vertragsformulierungen im Projekt sinnvoll verknüpfen
  • Warum Kriterien im Projekt lebende Dokumente bleiben sollten
  • Was passiert, wenn sich Anforderungen im Projekt ändern? Änderungen sauber nachziehen
  • Häufige Fehler bei Abnahmekriterien im Projekt und beim Projektabschluss
  • Q&A. Häufige Fragen zu Abnahmekriterien, Projektabnahme und Akzeptanzkriterien

Was sind Abnahmekriterien im Projekt und wie sichern sie Projektergebnisse für den Auftraggeber?

Abnahmekriterien sind die klaren Bedingungen, die ein Projektergebnis erfüllen muss, damit es offiziell als akzeptiert gilt. Sie legen fest, woran du erkennst, dass ein Arbeitsergebnis den vereinbarten Anforderungen entspricht.

Das klingt zunächst technisch, ist aber in Wahrheit sehr menschlich. Denn ohne klar vereinbarte Prüfmaßstäbe beurteilt jede beteiligte Person das Ergebnis aus ihrer eigenen Perspektive. Der Entwickler schaut vielleicht auf die technisch saubere Umsetzung. Der Auftraggeber achtet auf Nutzbarkeit, Vollständigkeit und Zielerreichung. Die Projektleitung denkt an Termine, Scope und Freigaben. Alle meinen dasselbe Projekt, aber nicht automatisch dasselbe mit „fertig".

Sauber formulierte Kriterien schaffen hier eine gemeinsame Sprache. Laut Atlassian sorgt eine klar definierte Definition of Done dafür, dass Teams ein gemeinsames Qualitätsverständnis entwickeln. Auch Scrum.org beschreibt die Definition of Done als transparenten Maßstab dafür, wann ein Inkrement wirklich abgeschlossen ist.

Abnahmekriterien im Projekt: Team, Projektleitung und Auftraggeber prüfen ein Ergebnis gemeinsam gegen Definition of Done und Akzeptanzkriterien
Von gefühlt fertig zu nachweislich abgenommen: Akzeptanzkriterien, Definition of Done und Abnahmekriterien greifen ineinander.

Definition of Done, Akzeptanzkriterien und Abnahmekriterien: Was ist der Unterschied?

Diese Begriffe werden oft durcheinandergeworfen. Im Alltag ist das verständlich, in Projekten aber riskant. Denn jeder Begriff erfüllt eine etwas andere Funktion.

Abnahmekriterien beschreiben die Bedingungen, unter denen ein Ergebnis vom Auftraggeber akzeptiert wird. Sie helfen dir bei der formalen Beurteilung.

Akzeptanzkriterien beziehen sich meist auf eine konkrete Anforderung, User Story oder Leistung. Sie beschreiben genauer, was dieses eine Ergebnis können oder enthalten muss.

Ein Beispiel: In procoli gibt es das Feature „Gast-Zugang für externe Partner".
Ein mögliches Akzeptanzkriterium wäre: „Der externe Nutzer erhält einen Einladungslink per E-Mail und kann ohne Registrierungszwang direkt auf die zugewiesene Aufgabe oder den relevanten Projektbereich zugreifen."

So wird aus einer allgemeinen Anforderung eine konkrete, prüfbare Erwartung.

Die Definition of Done geht noch einen Schritt weiter. Sie beschreibt den allgemeinen Qualitätsrahmen, der für alle relevanten Arbeitsergebnisse gelten soll. Dazu gehören zum Beispiel Review, Test, Dokumentation, Freigabe oder Nachvollziehbarkeit.

Im selben Beispiel könnte die Definition of Done bedeuten: „Code wurde gepullt und gereviewt, automatische Security-Tests sind grün, die UI ist barrierefrei und die Dokumentation ist aktualisiert."

Abnahmekriterien ziehen dann die formale Linie: Sie machen messbar, wann ein Ergebnis tatsächlich abgenommen werden kann. Für den Gast-Zugang könnte das zum Beispiel heißen: „Der Gast-Login ist nachweisbar DSGVO-konform, externe Mitarbeiter sind im Testlauf innerhalb von 60 Minuten voll arbeitsfähig und das Abnahmeprotokoll wurde beidseitig unterzeichnet."

Kurz gesagt:

  • Akzeptanzkriterien = konkrete Erwartungen an ein einzelnes Arbeitsergebnis
  • Definition of Done = übergreifender Qualitätsrahmen für „fertig"
  • Abnahmekriterien = messbarer Maßstab für die formale Annahme
EbeneBegriffFokusKunden-Perspektive
Mikro (Feature)AkzeptanzkriterienEinzelne Funktion„Tut genau diese eine Story das, was vereinbart war?"
Meso (Standard)Definition of DoneQualität & Prozess„Ist das Ergebnis technisch und organisatorisch sauber verarbeitet?"
Makro (Vertrag)AbnahmekriterienBusiness & Rahmen„Erfüllt das fertige Gesamtprojekt unsere geschäftlichen/formalen Ziele?"

In der Praxis greifen diese drei Ebenen ineinander. Genau deshalb lohnt es sich, sie nicht isoliert zu betrachten, sondern als zusammenhängendes System. Für viele Teams hilft schon eine einfache Merkhilfe: Anforderungen beschreiben das Ziel, diese Maßstäbe machen das Projektergebnis prüfbar.

Warum so viele Projekte bei der Abnahme unnötig Reibung erzeugen

Das Problem entsteht selten erst am Ende. Meistens beginnt es viel früher, nämlich dann, wenn Erwartungen nur grob formuliert oder implizit mitgedacht werden.

Vielleicht steht im Briefing, dass ein Feature „benutzerfreundlich" sein soll. Klingt vernünftig, ist aber nicht prüfbar. Vielleicht wurde besprochen, dass externe Partner eingebunden werden müssen, aber nicht, ob dafür ein Login nötig ist, welche Dateien hochgeladen werden dürfen oder wie Benachrichtigungen laufen sollen. Vielleicht hat das Team intern längst entschieden, was „done" bedeutet, aber der Auftraggeber kennt diese Definition gar nicht.

So wächst ein Projekt mit vielen stillen Annahmen. Und stille Annahmen sind oft die eigentliche Ursache für Konflikte.

Wenn du solche Maßstäbe früh klärst, veränderst du nicht nur den Abnahmeprozess. Du verbesserst die Zusammenarbeit selbst. Teams treffen bessere Entscheidungen, weil sie den Zielzustand klarer sehen. Auftraggeber fühlen sich besser mitgenommen, weil ihre Perspektive konkret abgebildet wird. Und die Projektleitung spart sich spätere Eskalationen, weil das Erwartungsmanagement nicht erst am Ende stattfindet.

Warum eine klare Definition of Done ein Empathie-Werkzeug ist

Viele Teams definieren sauber, wie sie starten, planen, bauen und testen. Aber sie definieren nicht präzise genug, wann ein Ergebnis wirklich als „fertig" gilt – und wie sich das für alle Beteiligten nachvollziehbar belegen lässt.

Genau hier liegt die Stärke einer klaren Definition of Done: Du machst nicht einfach Regeln strenger, sondern nimmst unterschiedliche Perspektiven ernst.

Für das Entwickler-Team schafft eine gute Definition of Done Orientierung. Niemand muss raten, ob etwas schon wirklich abgeschlossen ist oder ob noch Rückfragen, Tests, Freigaben oder Doku fehlen. Das reduziert Frust und verhindert das Gefühl, dass sich das Ziel kurz vor Schluss plötzlich verschiebt.

Für den Auftraggeber schafft eine gute DoD Vertrauen. Er sieht früher, wie Qualität gedacht wird, worauf er sich verlassen kann und an welchen Punkten seine Rückmeldung sinnvoll ist. Das macht die Zusammenarbeit fairer und transparenter.

Genau deshalb ist die DoD kein Misstrauensdokument. Sie ist ein Werkzeug für gegenseitiges Verständnis. Sie sagt nicht: „Damit du dich später nicht beschweren kannst." Sie sagt: „Damit wir beide heute schon dasselbe Bild vom Ergebnis haben."

So definieren du und dein Auftraggeber die Definition of Done als verbindliches Abnahme-Dokument

Viele Teams haben irgendwo eine lose Liste mit Punkten wie „getestet", „reviewed" oder „dokumentiert". Das ist ein Anfang, aber noch kein belastbares Abnahme-Dokument.

Wenn du die Definition of Done verbindlich machen willst, braucht sie mehr Struktur. Sie sollte mindestens diese Elemente enthalten:

  • klare Qualitätsstandards
  • messbare Prüfkriterien
  • zugehörige Testfälle oder Prüfschritte
  • Verantwortlichkeiten für Prüfung und Freigabe
  • Dokumentation der Ergebnisse
  • Bezug zu Scope, Angebot oder Vereinbarung

Wichtig ist dabei: Die DoD darf nicht im luftleeren Raum hängen. Sie muss mit dem Projektkontext verbunden sein. Wenn du zum Beispiel mit einem Kunden, Fachbereich oder externen Partner arbeitest, sollte eindeutig dokumentiert sein, welche Kriterien für welche Deliverables gelten.

Damit entsteht aus einer abstrakten Qualitätsidee ein konkretes Arbeitsinstrument. Gerade zwischen Auftraggeber und Auftragnehmer verhindert das spätere Missverständnisse, weil beide Seiten dieselbe Abnahmevereinbarung vor Augen haben. Im klassischen Projektmanagement wird diese Abstimmung oft mit einem Pflichtenheft oder einer vertraglich festgelegten Leistungsbeschreibung verbunden. Auch in Scrum bleibt die Logik ähnlich: Alle Beteiligten brauchen ein gemeinsames Bild davon, wann Arbeit wirklich abgeschlossen ist.

So entwickelst du Abnahmekriterien in 5 Schritten

Damit Abnahmekriterien im Projekt nicht abstrakt bleiben, hilft dir ein einfacher, klarer Ablauf. Du musst dafür keine perfekte Prozesslandschaft bauen. Entscheidend ist, dass du systematisch vom gewünschten Ergebnis zur prüfbaren Abnahme kommst.

1. Deliverable definieren

Frage: Was genau soll am Ende übergeben oder freigegeben werden?

Was & Warum: Du grenzt das Arbeitsergebnis eindeutig ein, damit alle Beteiligten dasselbe Zielbild vor Augen haben.

Beispiel: Ein neuer Gast-Zugang für externe Partner in der Projektmanagement-App.

2. Anforderungen erfassen

Frage: Welche fachlichen, technischen und organisatorischen Erwartungen gibt es an das Ergebnis?

Was & Warum: Du sammelst die Anforderungen von Auftraggeber, Nutzern und Umsetzungsteam, um den Rahmen sauber abzustecken.

Beispiel: Externe Partner sollen ohne Hürden schnell mitarbeiten können, ohne dass Sicherheit oder Zugriffskontrolle darunter leiden.

3. Akzeptanzkriterien formulieren

Frage: Woran erkennen wir bei diesem spezifischen Feature, dass es passt?

Was & Warum: Du übersetzt vage Erwartungen in konkrete, beobachtbare Bedingungen.

Beispiel: „Ein externer Partner kann über einen E-Mail-Link ohne Registrierung ein Board öffnen, einen Kommentar schreiben und eine Datei hochladen."

4. Definition of Done ergänzen

Frage: Welche übergreifenden Qualitätsstandards müssen generell erfüllt sein?

Was & Warum: Du stellst sicher, dass das Ergebnis nicht nur fachlich passt, sondern auch technisch, rechtlich und organisatorisch sauber verarbeitet ist.

Beispiel: Code-Review erfolgt, Security-Check bestanden, DSGVO-Konformität geprüft und die Dokumentation im Team-Wiki aktualisiert.

5. Abnahme- und Nachweisschritte festlegen

Frage: Wie, durch wen und wo wird die finale Freigabe geprüft und belegt?

Was & Warum: Du legst Verantwortlichkeiten und Prüfpfade fest, damit die Abnahme nicht nach Bauchgefühl erfolgt. Wichtig ist außerdem, dass Rückmeldungen, Freigaben und offene Punkte an einem nachvollziehbaren Ort zusammenlaufen – besonders dann, wenn interne Teams und externe Partner beteiligt sind.

Beispiel: Der Product Owner führt den Testdurchlauf durch, dokumentiert das Ergebnis im Abnahmeprotokoll und der Auftraggeber zeichnet es digital ab. Damit Rückmeldungen nicht in E-Mail-Postfächern untergehen, lohnt sich der Einsatz schlanker Kollaborationstools. Mit Werkzeugen wie procoli Mini können externe Partner Ergebnisse ohne Login-Hürde direkt per Link prüfen, kommentieren und freigeben. Wenn du die Projektabnahme mit externen Partnern endlich an einem Ort bündeln willst, trag dich jetzt auf die procoli Warteliste ein und sichere dir frühen Zugriff.

Wenn du diese fünf Schritte sauber durchgehst, entsteht aus einer vagen Erwartungshaltung ein gemeinsames Verständnis davon, was „fertig" wirklich bedeutet. Genau das reduziert Reibung bei der Projektabnahme und schafft Sicherheit für Team, Auftraggeber und externe Partner.

Kostenlose Vorlage: Definition of Done & Abnahmekriterien

Wenn du diese fünf Schritte nicht jedes Mal neu aufsetzen willst, lohnt sich eine einfache Arbeitsvorlage. Mit unserer Vorlage für Definition of Done & Abnahmekriterien kannst du Deliverables, Anforderungen, Akzeptanzkriterien, Qualitätsstandards, Prüfschritte und Nachweise an einem Ort strukturieren. Das hilft dir besonders dann, wenn mehrere interne Teams und externe Partner an einem Ergebnis beteiligt sind und die spätere Abnahme nachvollziehbar dokumentiert werden soll.

Messbare Abnahmekriterien formulieren: Worauf du achten solltest

Solche Prüfkriterien funktionieren nur dann gut, wenn du sie tatsächlich prüfen kannst. „Schön", „intuitiv", „sauber" oder „vollständig" reichen allein nicht aus. Diese Begriffe sind im Gespräch nützlich, aber für die Abnahme zu schwammig.

Besser ist es, Kriterien so zu formulieren, dass man sie beobachten, testen oder dokumentieren kann. Ein guter Prüfpunkt beschreibt deshalb nicht nur eine Absicht, sondern einen Zustand, den ihr gemeinsam nachvollziehen könnt.

Zum Beispiel:

  • statt „Die Funktion ist benutzerfreundlich"
    besser: „Ein externer Partner kann die Aufgabe über einen Link ohne Registrierung öffnen und kommentieren."
  • statt „Die Übergabe ist vollständig"
    besser: „Alle vereinbarten Dateien sind im finalen Task hinterlegt, versioniert und für die definierten Beteiligten abrufbar."
  • statt „Alle sind informiert"
    besser: „Bei Statusänderungen erhalten die definierten Beteiligten automatisch eine Benachrichtigung per E-Mail oder über den festgelegten Kommunikationskanal."

Du merkst den Unterschied sofort: Das zweite Format schafft Verständlichkeit. Es zeigt dir, was konkret erwartet wird, und es macht Abnahme überhaupt erst nachvollziehbar.

Gerade bei der Zusammenarbeit mit externen Partnern ist das Gold wert. Denn dort entstehen Missverständnisse besonders schnell, nicht weil Menschen unwillig sind, sondern weil sie in unterschiedlichen Systemen, Gewohnheiten und Kommunikationsmustern arbeiten.

Testfälle, Übergabeprotokoll, Abnahmeprotokoll und Vertragsformulierungen im Projekt sinnvoll verknüpfen

Sobald ein Projekt eine gewisse Komplexität erreicht, reichen lose Formulierungen nicht mehr. Dann brauchst du eine Brücke zwischen Erwartung, Prüfung und Nachweis.

Hier greifen Testfälle, Übergabeprotokoll, Abnahmeprotokoll und, je nach Projekt, auch Vertragsformulierungen ineinander.

  • Testfälle übersetzen Kriterien in konkrete Prüfschritte. Sie beantworten die Frage: Wie stellen wir fest, ob der Prüfpunkt erfüllt ist?
  • Abnahmeprotokolle dokumentieren das Ergebnis dieser Prüfung. Sie halten fest, was geprüft wurde, ob der jeweilige Punkt erfüllt ist und welche offenen Punkte eventuell noch bestehen.
  • Vertragsformulierungen sorgen dafür, dass die Erwartungen auch formal sauber verankert sind – gerade bei externen Dienstleistern, Agenturen oder Projektpartnern.

Das Entscheidende: Diese Elemente sollten zusammenpassen. Wenn im Vertrag etwas anderes steht als in der operativen DoD, produzierst du Reibung. Wenn Testfälle fehlen, bleiben Kriterien interpretationsfähig. Wenn das Protokoll nicht zur DoD passt, wird aus einer eigentlich klaren Situation wieder eine Diskussion.

Gerade bei der Projektabnahme lohnt es sich, den Abnahmetermin nicht isoliert zu betrachten. Erst wenn Test, Dokumentation, Übergabe und Freigabe sinnvoll zusammenlaufen, lässt sich sauber beurteilen, ob alle vereinbarten Punkte erfüllt wurden.

Warum Kriterien im Projekt lebende Dokumente bleiben sollten

Viele Teams machen einen Fehler: Sie definieren ihre Kriterien einmal zu Projektbeginn und behandeln sie danach wie eine statische Tafel an der Wand.

In der Realität entwickeln sich Projekte weiter. Neue Abhängigkeiten tauchen auf, Beteiligte lernen dazu, Risiken werden erst im Verlauf sichtbar und manchmal ändern sich auch Anforderungen oder Rahmenbedingungen. Genau deshalb solltest du nicht nur die Definition of Done, sondern das gesamte Kriterien-Setup als lebendes Arbeitsmodell verstehen.

Denn die Dynamik betrifft meist alle drei Ebenen:

  • Akzeptanzkriterien können sich ändern, wenn sich eine konkrete Funktion oder Anforderung weiterentwickelt.
  • Die Definition of Done kann sich verändern, wenn neue Qualitätsstandards, Prüfprozesse oder Dokumentationspflichten dazukommen.
  • Abnahmekriterien müssen angepasst werden, wenn sich Scope, rechtliche Vorgaben oder formale Erwartungen des Auftraggebers verschieben.

Wichtig ist: Diese Änderungen passieren selten isoliert. Wenn sich auf einer Ebene etwas verändert, hat das oft Auswirkungen auf die anderen beiden.

Ein Beispiel:
Wenn für ein Feature plötzlich zusätzliche Sicherheitsanforderungen gelten, betrifft das nicht nur die Akzeptanzkriterien der Funktion. Dann muss oft auch die Definition of Done um neue Prüfungen ergänzt werden – und je nach Projekt sogar die formale Abnahme angepasst werden.

Genau deshalb lohnt es sich, Änderungen transparent nachzuziehen, statt sie stillschweigend einzubauen. Sonst wird aus einem sinnvollen Arbeitsdokument schnell ein bewegliches Ziel, das niemand mehr sauber greifen kann.

Änderungen sauber nachziehen

Aufgepasst bei Scope-Änderungen: Sobald sich Anforderungen mitten im Projekt verändern, greift das Change-Request-Management. Wichtig ist nur: Eine Anpassung auf einer Ebene muss immer sauber auf alle drei Ebenen nachgezogen werden.

Häufige Fehler bei Abnahmekriterien im Projekt und beim Projektabschluss

Einige Muster tauchen in Projekten immer wieder auf:

  • Zu vage Formulierungen
    Wenn Kriterien nicht prüfbar sind, verlagert sich die Diskussion nur ans Projektende.
  • Abnahme nach Bauchgefühl
    Sympathie und Vertrauen sind wichtig, ersetzen aber keine klaren Maßstäbe.
  • Definition of Done und Akzeptanzkriterien werden vermischt
    Dann fehlt entweder der allgemeine Qualitätsrahmen oder die konkrete Prüfbarkeit einzelner Ergebnisse.
  • Externe Partner werden isoliert
    Gerade dort entstehen Medienbrüche, unklare Verantwortlichkeiten und verlorene Informationen.
  • Informelle Scope-Änderungen
    Wenn Anforderungen wachsen, ohne dass Kriterien angepasst werden, ist Streit fast vorprogrammiert.
  • Die DoD als Monolog
    Dann hängt Projektqualität an Erinnerung statt an Transparenz.
  • Ein Mangel wird zu spät dokumentiert
    Wenn Probleme erst kurz vor der Freigabe sichtbar werden, wird aus einer kleinen Korrektur schnell eine große Diskussion.

Q&A. Häufige Fragen zu Abnahmekriterien, Projektabnahme und Akzeptanzkriterien

Wer legt Abnahmekriterien in einem Projekt fest?

Im besten Fall werden diese Kriterien gemeinsam entwickelt. Auftraggeber, Fachbereich, Projektleitung und Umsetzungsteam bringen unterschiedliche Perspektiven ein. Genau das macht die Kriterien belastbar. Wenn nur eine Seite sie definiert, fehlt oft entweder die fachliche Relevanz oder die praktische Umsetzbarkeit.

Ab wann sollte man Abnahmekriterien im Projekt festlegen?

So früh wie möglich. Ein erster Rahmen sollte stehen, bevor die Umsetzung startet. Im Projektverlauf werden die Kriterien oft noch präziser. Entscheidend ist, dass Erwartungen früh sichtbar werden und nicht erst bei der Abnahme auf den Tisch kommen.

Gilt eine Definition of Done nur für agile Projekte?

Nein. Der Begriff stammt zwar aus dem agilen Umfeld, das Prinzip funktioniert aber in fast jedem Projekt. Immer dann, wenn mehrere Beteiligte ein gemeinsames Verständnis von Qualität, Vollständigkeit und Übergabe brauchen, hilft dir eine Definition of Done.

Wie unterscheiden sich Anforderungen und Abnahmekriterien?

Anforderungen beschreiben, was gebraucht wird. Diese Akzeptanzkriterien beschreiben, woran du erkennst, dass dieses Ergebnis passend umgesetzt wurde. Sie machen Erwartungen prüfbar und helfen dir dabei, Diskussionen über „fertig" auf eine klare Grundlage zu stellen.

Warum scheitern Abnahmen besonders oft mit externen Partnern?

Oft nicht wegen der Leistung selbst, sondern wegen unklarer Kommunikation. Informationen verteilen sich über E-Mail, Dateien liegen in verschiedenen Versionen herum und niemand sieht auf einen Blick, was bereits freigegeben wurde. Genau deshalb sind klare Kriterien und eine transparente Zusammenarbeit mit externen Partnern so wichtig.