Statement of Work (SOW): Was hineingehört (mit Vorlage)

Ein Statement of Work (SOW) ist das Dokument, das aus einer mündlichen Vereinbarung eine bindende Projektverpflichtung macht. Ohne dieses Dokument gehen Kunde und Anbieter mit unterschiedlichen Annahmen darüber in ein Projekt, was geliefert wird, wann und zu welchen Kosten.

Ein von Anfang an korrekt formuliertes SOW erspart später wochenlange Nacharbeit, Streitigkeiten und teure Debatten über den Projektumfang. Dieser Leitfaden behandelt jeden Abschnitt, den ein solides SOW braucht, die drei zur Auswahl stehenden Typen, den Vergleich mit ähnlichen Dokumenten und eine Vorlage, die Sie sofort anpassen können.

Was ist ein Statement of Work (SOW)?

Ein Statement of Work (SOW) ist ein formelles Projektdokument, das den Arbeitsumfang, die Liefergegenstände, den Zeitplan, die Abnahmekriterien und die Bedingungen zwischen einem Kunden und einem Anbieter oder Projektteam festlegt. Es ist das vertragliche Gegenstück zum Projektauftrag: Der Projektauftrag autorisiert das Projekt intern, während das SOW die externe oder funktionsübergreifende Vereinbarung regelt, die die Arbeit ermöglicht.

Das SOW beantwortet fünf Fragen, die vor Arbeitsbeginn geklärt sein müssen:

• Was wird getan? (Umfang und Liefergegenstände)
• Wie wird es getan? (Methodik und Standards)
• Wann wird es getan? (Zeitplan und Meilensteine)
• Wo wird es getan? (Ort und Umgebung)
• Wie viel wird es kosten? (Zahlungsbedingungen und Sätze)

Verträge fügen ein SOW häufig als Anhang bei, wodurch es zu einem rechtlich referenzierten Dokument wird. Deshalb ist Präzision hier weitaus wichtiger als in internen Planungswerkzeugen.

Wichtige Fakten

• Organisationen mit einem formellen SOW-Prozess berichten von einer 28-prozentigen Reduzierung von Scope-Streitigkeiten und Änderungsaufträgen im Vergleich zu Organisationen, die sich ausschließlich auf mündliche Vereinbarungen verlassen (Project Management Institute, 2023).
• 73 % der gescheiterten IT-Projekte nannten unklare Anforderungen und einen unklaren Umfang als Hauptursache (Standish Group CHAOS Report, 2022).
• Ein durchschnittliches SOW umfasst 3 bis 10 Seiten bei Dienstleistungsprojekten; komplexe Bau- oder Regierungsverträge erreichen oft 50 Seiten oder mehr (PMI Practice Standard for Project Estimating, 2021).

Was in ein Statement of Work gehört

Jedes SOW sollte die folgenden Abschnitte abdecken. Manche Branchen ergänzen spezialisierte Klauseln (Sicherheit, Compliance, Versicherung), doch diese zehn bilden die universelle Grundlage.

Die Abschnitte zu Umfang und Liefergegenständen tragen das größte rechtliche Gewicht. Vage Formulierungen sind hier der größte Treiber von Streitigkeiten. „Eine Website bereitstellen" ist kein Liefergegenstand. „Eine responsive, fünfseitige Marketing-Website mit Kontaktformular, CMS-Integration und WCAG-2.1-AA-konformer Barrierefreiheit bis zum 31. Juli liefern" ist einer.

Der Abschnitt zu den Annahmen wird oft ausgelassen, ist aber genauso wichtig. Wenn Ihr SOW voraussetzt, dass der Kunde Markenmaterialien bis Woche zwei bereitstellt, und das nicht geschieht, brauchen Sie einen schriftlichen Nachweis, dass die Verzögerung beim Kunden lag, nicht bei Ihnen.

Arten von Statement of Work

Es gibt drei SOW-Typen, und welcher der richtige ist, hängt davon ab, wie genau sich der Projektumfang im Voraus festlegen lässt.

Ein Design-/Detail-SOW gibt dem Kunden maximale Kontrolle, erfordert aber den größten Aufwand bei der vorherigen Spezifikation. Sind die Anforderungen unvollständig, hält sich der Anbieter exakt an den Wortlaut des Dokuments, und der Kunde ist am Ende mit einem technisch konformen, aber unbefriedigenden Ergebnis unzufrieden.

Ein leistungsbasiertes SOW gibt dem Anbieter Freiraum für Innovation, verlangt aber klare, messbare Ergebnisse. Sind die Abnahmekriterien schwach, kommt es häufig zu Streitigkeiten darüber, ob der Standard erfüllt wurde.

Die meisten SOWs in der Praxis kombinieren mehrere Typen. Ein Softwareprojekt könnte leistungsbasierte Kriterien für die Feature-Abnahme nutzen und gleichzeitig die genaue Teamzusammensetzung (Level of Effort) für die Personalbesetzung festlegen.

SOW vs. Projektauftrag vs. Scope Statement

Diese drei Dokumente sorgen bei Teams häufig für Verwirrung, weil sie sich überschneiden. So unterscheiden Sie sie voneinander:

Ein Projekt kann alle drei Dokumente umfassen. Das SOW mit dem Kunden definiert, was der Anbieter liefern muss. Der Projektauftrag autorisiert intern den PM des Anbieters, Ressourcen zu mobilisieren. Das Scope Statement schlüsselt die Arbeit für die interne Planung des Teams auf.

Das SOW unterscheidet sich zudem von einer Master Service Agreement (MSA). Eine MSA legt die übergeordneten rechtlichen Bedingungen für sämtliche Arbeiten zwischen zwei Parteien fest (Haftung, geistiges Eigentum, Streitbeilegung). SOWs werden dann im Rahmen der MSA für spezifische Projekte ausgestellt. Betrachten Sie die MSA als den Rahmen und jedes SOW als einen darunter liegenden Arbeitsauftrag.

So schreiben Sie ein Statement of Work

Stimmen Sie den Umfang ab, definieren Sie Liefergegenstände und Abnahme, legen Sie Meilensteine und Zahlung fest, und sichern Sie Änderungen anschließend mit Unterschriften ab.

Schritt 1: Umfang abstimmen, bevor Sie zu schreiben beginnen

Sprechen Sie mit jedem Stakeholder, bevor Sie ein Dokument öffnen. Führen Sie einen Scope-Workshop mit dem Kunden, den Verantwortlichen für die Umsetzung, der Rechtsabteilung und dem Finanzteam durch. Nutzen Sie eine Anforderungsverfolgungsmatrix, um Anforderungen zu erfassen und mit Liefergegenständen zu verknüpfen. Das Schreiben fällt leicht, sobald Sie wissen, worauf Sie sich einigen.

Schritt 2: Die Projektübersicht schreiben

Ein Absatz, klare Sprache. Nennen Sie, wer der Kunde ist, wer der Anbieter ist, welches Geschäftsproblem das Projekt löst und welches Geschäftsergebnis erwartet wird. Verzichten Sie auf Marketingsprache. „Die Reaktionszeit des Kunden bei Leads von 48 Stunden auf unter 4 Stunden verkürzen" ist nützlicher als „die Vertriebsabläufe des Kunden transformieren".

Schritt 3: Umfang und Out-of-Scope-Punkte definieren

Listen Sie jede Aufgabe und Leistung auf, die innerhalb des Projekts liegt. Listen Sie dann explizit auf, was außerhalb des Umfangs liegt. Diese zweite Liste ist genauso wichtig. Wenn Sie nicht festhalten, dass etwas außerhalb des Umfangs liegt, gehen manche Stakeholder davon aus, dass es enthalten ist.

Eine Projektstrukturplan (WBS) ist hier ein praktisches Werkzeug. Erstellen Sie zuerst den Projektstrukturplan und nutzen Sie ihn dann, um den Umfangsabschnitt Ihres SOW zu füllen. Der Projektstrukturplan zwingt Sie, die Arbeit bis auf eine Ebene herunterzubrechen, auf der nichts Mehrdeutiges übrig bleibt.

Schritt 4: Liefergegenstände und Abnahmekriterien definieren

Beantworten Sie für jeden Liefergegenstand: Was ist es? Welches Format? Wer prüft es? Welchen Qualitätsstandard muss es erfüllen? Wann ist die Freigabefrist?

Verknüpfen Sie die Abnahmekriterien mit Ihrer Projekt-Baseline, damit Sie über den gesamten Projektverlauf einen Referenzpunkt zur Fortschrittsmessung haben.

Schritt 5: Den Zeitplan erstellen

Ordnen Sie Meilensteine konkreten Kalenderdaten zu. Berücksichtigen Sie kundenseitige Abhängigkeiten (Datenlieferung, Freigaben, Abnahmen) mit ihren jeweiligen Fälligkeitsdaten. Vermerken Sie, welche Meilensteine als Gates fungieren: Die Arbeit an der nächsten Phase kann erst beginnen, wenn der Kunde die vorherige freigegeben hat.

Ein Kommunikationsplan passt gut zu diesem Schritt. Legen Sie fest, wie der Fortschritt berichtet wird, in welcher Häufigkeit und an wen.

Schritt 6: Zahlungsbedingungen vereinbaren

Legen Sie den Gesamtvertragswert, den Zahlungsplan (meilenstein- oder kalenderbasiert), die Rechnungsstellungsanweisungen und die Auslöser für jede Zahlung fest. Berücksichtigen Sie Regelungen für Zahlungsverzug und was mit der Arbeit geschieht, wenn sich die Zahlung verzögert.

Schritt 7: Änderungsmanagement und Unterschriften ergänzen

Definieren Sie den Änderungsantragsprozess: Wer kann eine Änderung einreichen, wer bewertet sie, wie lange dauert die Prüfung, und wie wirken sich Änderungen auf Preis und Zeitplan aus? Beide Parteien unterschreiben. Bewahren Sie unterzeichnete Kopien sowohl für den PM als auch für die Rechtsabteilung zugänglich auf.

Beziehen Sie sich bei der Zuweisung von Freigabebefugnissen im Änderungsprozess auf Ihre RACI-Matrix. Das verhindert Unklarheiten darüber, wer für Entscheidungen verantwortlich ist.

Statement-of-Work-Vorlage

Nachfolgend finden Sie eine minimale SOW-Struktur, die Sie kopieren und anpassen können. Ersetzen Sie die Felder in Klammern durch Ihre tatsächlichen Projektdaten.

---

STATEMENT OF WORK

Projektname: [Projektname] Kunde: [Kundenorganisation] Anbieter/Dienstleister: [Ihre Organisation] Wirksamkeitsdatum: [Datum] Vertragsreferenz: [MSA-Nummer oder Vertrags-ID, falls zutreffend]

---

1. Projektübersicht

[Name des Kunden] beauftragt [Name des Anbieters] mit [Beschreibung dessen, was das Projekt umfasst und welches Geschäftsergebnis es adressiert]. Dieses SOW regelt alle Arbeiten, die zwischen [Startdatum] und [Enddatum] ausgeführt werden.

2. Arbeitsumfang

Im Umfang enthalten:

• [Aufgabe oder Leistung 1]
• [Aufgabe oder Leistung 2]
• [Aufgabe oder Leistung 3]

Nicht im Umfang enthalten:

• [Ausgeschlossener Punkt 1]
• [Ausgeschlossener Punkt 2]

3. Liefergegenstände

4. Zeitplan und Meilensteine

5. Abnahmekriterien

Jeder Liefergegenstand gilt als abgenommen, wenn: [beschreiben Sie den messbaren Standard, z. B. „alle automatisierten Tests bestehen ohne kritische Fehler, das QA-Team des Kunden gibt die Freigabe innerhalb von 5 Werktagen nach Lieferung"].

6. Annahmen und Einschränkungen

• Der Kunde stellt [spezifische Daten oder Zugang] bis [Datum] bereit.
• Die Arbeit wird in [Ort oder Umgebung] durchgeführt.
• Alle Liefergegenstände sind in [Sprache].

7. Zahlungsbedingungen

Gesamtvertragswert: [Betrag] Zahlungsplan: [z. B. 30 % bei Vertragsabschluss, 40 % bei Freigabe von Meilenstein 2, 30 % bei Endabnahme] Rechnungsstellung: [Anweisungen zur Einreichung von Rechnungen]

8. Änderungsmanagement

Änderungen an Umfang, Zeitplan oder Kosten erfordern einen schriftlichen Änderungsantrag, eingereicht bei [Name/Rolle]. Der Anbieter antwortet innerhalb von [X] Werktagen mit einer Auswirkungsbewertung. Keine Änderung tritt ohne schriftliche Zustimmung beider Parteien in Kraft.

9. Autorisierte Unterschriften

---

Häufige Fehler beim Schreiben eines Statement of Work

Vage Liefergegenstände. „Ein Bericht" ist kein Liefergegenstand. „Eine 20-seitige schriftliche Analyse im PDF-Format zu X, Y und Z, geliefert bis [Datum]" ist einer. Jeder Liefergegenstand braucht ein Format, einen Erfolgsstandard und ein Fälligkeitsdatum.

Fehlende Out-of-Scope-Liste. Kunden gehen häufig davon aus, dass verwandte Arbeiten enthalten sind, sofern sie nicht explizit ausgeschlossen wurden. Wenn Sie es nicht schriftlich festhalten, erledigen Sie es am Ende kostenlos.

Unrealistische Zeitpläne ohne kundenseitige Abhängigkeiten. Zeitpläne, die von Kundenaktionen abhängen (Datenlieferung, Freigaben, Zugangsbereitstellung), müssen diese Abhängigkeiten explizit ausweisen. Ist der Kunde zwei Wochen im Verzug mit einem Datenexport, verschiebt sich Ihr Liefertermin. Das SOW sollte das festhalten.

Nicht messbare Abnahmekriterien. „Hohe Qualität" ist kein Abnahmekriterium. „Null SEV-1-Fehler, Ladezeit unter 2 Sekunden bei 4G-Verbindung, WCAG-2.1-AA-Konformität durch automatisierten Scan verifiziert" ist eines.

Unterschrift nur einer Partei. Ein SOW, das nur von einer Partei unterzeichnet wurde, ist keine gegenseitige Vereinbarung. Beide Parteien müssen unterschreiben, bevor die Arbeit beginnt.

Den Änderungsmanagement-Abschnitt ignorieren. Teams, die diesen Abschnitt auslassen, verbringen die zweite Hälfte des Projekts damit, darüber zu streiten, ob sich der Umfang geändert hat und wer dafür aufkommen muss. Schreiben Sie den Prozess, bevor der erste Änderungsantrag eintrifft.

---

Ein gut geschriebenes Statement of Work zahlt sich beim ersten Scope-Streit aus. Mit klaren Liefergegenständen, messbaren Abnahmekriterien und einem expliziten Änderungsprozess verbringen beide Parteien weniger Zeit mit Diskussionen und mehr Zeit mit dem Aufbau. Nutzen Sie die obige Vorlage als Ausgangspunkt, lassen Sie beide Parteien jeden Abschnitt sorgfältig prüfen, und betrachten Sie die Unterschriftszeile als den Moment, in dem das eigentliche Projekt beginnt.