Ein Statement of Work, abgekürzt SoW, ist eine vertraglich verwendbare Arbeitsbeschreibung, mit der festgelegt wird, welche Arbeiten ein Auftragnehmer ausführen soll. Im militärischen und verteidigungsnahen Beschaffungskontext wird der Begriff besonders durch MIL-HDBK-245 geprägt. Dieses Handbook trägt den Titel „Preparation of Statement of Work (SOW)“ und beschreibt, wie ein SOW für Beschaffungen, Entwicklungsleistungen, Dienstleistungen und technische Programme aufgebaut und formuliert werden soll. Das Dokument ist ausdrücklich als Guidance, also als Leitfaden, zu verstehen und darf nach eigener Aussage nicht selbst als vertragliche Anforderung zitiert werden. Es dient damit nicht als Norm, sondern als methodische Hilfe für Auftraggeber und Auftragnehmer.
Inhalt
In der Praxis beschreibt ein SOW den Leistungsgegenstand eines Projekts. Bei Hardware- und Softwareprojekten kann man es vereinfacht als eine kurze, vertraglich orientierte Form eines Lastenhefts verstehen. Der Vergleich mit einem Lastenheft ist jedoch nur teilweise korrekt: Ein Lastenheft beschreibt typischerweise die Anforderungen des Auftraggebers an ein Produkt oder System. Ein SOW beschreibt dagegen vor allem die Arbeiten, Aufgaben und Verantwortlichkeiten, die ein Auftragnehmer im Rahmen eines Vertrags ausführen soll. Es ist also weniger eine reine Produktbeschreibung und stärker eine Arbeits- und Leistungsbeschreibung.
Gerade beim Einsatz von militärischen Dienstleistern, Systemhäusern, Engineering-Dienstleistern oder spezialisierten Entwicklungsunternehmen ist das SOW ein zentrales Dokument. Es definiert, welche technischen, organisatorischen und dokumentarischen Leistungen erwartet werden. Dazu können beispielsweise Systementwicklung, Hardwareentwicklung, Softwareentwicklung, Integration, Test, Konfigurationsmanagement, Obsoleszenzmanagement, Cyber Security, Safety-Aktivitäten, Reviews, Berichte und technische Daten gehören.
Ursprung und Einordnung nach MIL-HDBK-245
MIL-HDBK-245 ist ein Handbook des US Department of Defense zur Erstellung von Statements of Work. Die Ausgabe MIL-HDBK-245E mit Change 2 vom 21. September 2023 beschreibt, wie ein SOW aufgebaut werden kann, welche Inhalte typischerweise enthalten sind und welche sprachlichen Fehler vermieden werden sollten. Das Handbook ist für den DoD-Kontext geschrieben, hat aber auch außerhalb der US-Verteidigungsbeschaffung praktische Relevanz, weil es eine sehr klare Methode zur Beschreibung komplexer technischer Leistungen bietet.
Der Leitfaden stellt klar, dass ein SOW die wesentlichen und technischen Anforderungen an Gegenstände, Materialien oder Dienstleistungen beschreibt, einschließlich der Standards, mit denen überprüft werden kann, ob Anforderungen erfüllt wurden. Gleichzeitig betont MIL-HDBK-245, dass ein SOW insbesondere dann geeignet ist, wenn Aufgaben klar und eindeutig beschrieben werden können. Wenn dagegen eher Zielzustände und Ergebnisse im Vordergrund stehen und dem Anbieter mehr Freiheit in der Lösungsfindung gegeben werden soll, können andere Dokumenttypen wie ein Statement of Objectives (SOO) oder ein Performance Work Statement (PWS) passender sein.
Im Verteidigungskontext ist das wichtig, weil Beschaffungsvorhaben sehr unterschiedlich sein können. Ein SOW für die Entwicklung einer militärischen Elektronikeinheit unterscheidet sich von einem SOW für reine Wartungsleistungen, Softwarepflege, Prototyping, Serienvorbereitung oder technische Dokumentation. MIL-HDBK-245 gibt deshalb keine starre Vorlage für jedes Vorhaben vor, sondern beschreibt eine Struktur, die an den jeweiligen Beschaffungspfad, Projektstand und Vertragsgegenstand angepasst werden kann.
Zweck eines Statement of Work
Der Zweck eines SOW besteht darin, die vom Auftragnehmer auszuführenden Arbeiten klar, prüfbar und vertraglich belastbar zu beschreiben. Ein gutes SOW beantwortet nicht nur die Frage, was beschafft oder entwickelt werden soll, sondern vor allem, welche Arbeitsschritte, Ergebnisse und Verantwortlichkeiten Bestandteil des Vertrags sind. Dadurch wird es zu einer gemeinsamen Referenz für Auftraggeber, Auftragnehmer, Einkauf, Programmmanagement, technische Leitung, Qualitätssicherung und Vertragsadministration.
Im Engineering-Kontext dient das SOW als Brücke zwischen Bedarf, technischer Spezifikation, Angebot und Vertrag. Es schafft eine Grundlage dafür, dass Anbieter den Aufwand kalkulieren, Risiken bewerten und passende Ressourcen planen können. Gleichzeitig hilft es dem Auftraggeber, Angebote vergleichbar zu machen und nach Vertragsschluss die Leistung zu beurteilen. Nach Auftragserteilung wird das SOW zu einem Maßstab für die Bewertung der Auftragnehmerleistung.
Für Hardware- und Softwareentwicklung ist das besonders relevant. Ein unpräzises SOW führt schnell zu Scope Creep, Interpretationskonflikten, Nachforderungen, Mehrkosten, Terminverschiebungen oder technischen Lücken. Ein präzises SOW beschreibt dagegen, welche Entwicklungs-, Integrations-, Test- und Dokumentationsleistungen Teil des Auftrags sind und welche Leistungen gerade nicht enthalten sind. Es ist damit auch ein Instrument zur Abgrenzung des Projektumfangs.
SOW als kurzes Lastenheft für Hardware und Software
Im deutschsprachigen Engineering-Umfeld kann ein SOW als kurze, vertragsorientierte Beschreibung des Hardware- und Software-Gegenstands verstanden werden. Diese Beschreibung enthält jedoch nicht nur technische Produktanforderungen, sondern auch die zu erbringenden Arbeiten. Bei einem eingebetteten System könnte ein SOW beispielsweise festlegen, dass der Auftragnehmer eine bestehende Mikrocontroller-Plattform analysiert, eine neue Hardwarearchitektur ausarbeitet, Schaltpläne erstellt, ein PCB-Layout entwickelt, Prototypen in Betrieb nimmt, Firmware portiert, Treiber implementiert, Testspezifikationen erstellt und definierte Nachweise liefert.
Das SOW ersetzt dabei nicht zwingend eine detaillierte System Requirements Specification, eine Software Requirements Specification, eine Hardware-Spezifikation oder eine Prüfspezifikation. Es verweist vielmehr auf solche Dokumente oder beschreibt, dass sie zu erstellen sind. MIL-HDBK-245 unterscheidet deutlich zwischen Arbeitsanforderungen und Datenanforderungen. Die Arbeit selbst gehört in das SOW. Anforderungen an Lieferung, Format und Inhalt von Daten werden im DoD-Kontext über CDRL und DID geregelt. Diese Trennung ist wesentlich, weil Redundanz zwischen Dokumenten zu Konflikten führen kann.
Für einen militärischen Dienstleister bedeutet das: Das SOW sagt, welche Arbeiten auszuführen sind. Andere Vertragsbestandteile regeln, wann Ergebnisse zu liefern sind, in welchem Format Dokumente abzugeben sind, welche Vertragspositionen gelten, welche Abnahmekriterien greifen und welche Rechte an technischen Daten bestehen. Ein gutes SOW ist daher nie isoliert zu betrachten, sondern steht im Zusammenhang mit Vertrag, Spezifikationen, Liefergegenständen, Datenanforderungen und Abnahmeverfahren.
Typischer Aufbau eines SOW
MIL-HDBK-245 beschreibt einen Grundaufbau mit vier Hauptteilen: Scope, Applicable Documents, Acronyms and Definitions sowie Requirements. Diese Struktur ist einfach, aber für komplexe Programme tragfähig.
Der Abschnitt Scope beschreibt den Umfang und die Grenzen des Vorhabens. Er erklärt, worum es im Projekt geht, welche Arbeiten grundsätzlich abgedeckt sind und welche Zielrichtung der Auftrag hat. Bei komplexeren Vorhaben können Hintergrund, Annahmen oder programmatische Rahmenbedingungen ergänzt werden. Wichtig ist, dass Hintergrundinformationen nicht mit verbindlichen Anforderungen vermischt werden. Hintergrund dient dem Verständnis, nicht der Aufgabensteuerung.
Der Abschnitt Applicable Documents nennt die anwendbaren Dokumente, Standards und Referenzen. Dazu können militärische Standards, technische Spezifikationen, Schnittstellendokumente, Sicherheitsanforderungen, Prüfvorschriften oder Industriestandards gehören. MIL-HDBK-245 empfiehlt, nur die tatsächlich notwendigen Dokumente aufzunehmen und diese möglichst exakt mit Version, Datum oder Revision zu benennen. Eine pauschale Referenzierung ganzer Standards kann problematisch sein, weil dadurch Anforderungen in den Vertrag gelangen, die für den konkreten Leistungsgegenstand gar nicht notwendig sind.
Der Abschnitt Acronyms and Definitions schafft ein gemeinsames Begriffsverständnis. In technischen und militärischen Programmen ist dieser Teil nicht nebensächlich. Begriffe wie Configuration Item, Baseline, Technical Data Package, Acceptance Test, Cybersecurity, Safety Assessment oder Deliverable können je nach Organisation unterschiedlich verstanden werden. Ein SOW sollte daher zentrale Begriffe definieren, wenn Missverständnisse wahrscheinlich sind.
Der Abschnitt Requirements enthält die eigentlichen Arbeitsanforderungen. Hier wird beschrieben, was der Auftragnehmer tun soll. Dieser Abschnitt ist der Kern des SOW. Er kann nach Arbeitspaketen, technischen Disziplinen, Projektphasen, WBS-Elementen oder Ergebnissen gegliedert werden. Bei einem Elektronikentwicklungsprojekt könnten Unterabschnitte etwa Program Management, System Engineering, Hardware Development, Software Development, Configuration Management, Cyber Security, Test and Qualification, Reliability, Obsolescence Management und Technical Reviews heißen.
Abgrenzung zu PWS und SOO
MIL-HDBK-245 stellt das SOW nicht als einzig möglichen Dokumenttyp dar. Zwei verwandte Begriffe sind das Performance Work Statement und das Statement of Objectives.
Ein Performance Work Statement beschreibt die Arbeit stärker über erwartete Ergebnisse, messbare Outputs und Performance-Ziele. Es wird häufig bei leistungsorientierten Service-Beschaffungen verwendet. Der Auftraggeber beschreibt also weniger detailliert, welche Einzeltätigkeiten auszuführen sind, sondern welche Ergebnisse erreicht werden müssen.
Ein Statement of Objectives ist noch stärker zielorientiert. Es nennt die übergeordneten Beschaffungsziele und gibt Anbietern Raum, eine eigene Lösung, ein eigenes SOW und passende Liefergegenstände vorzuschlagen. Dieser Ansatz kann sinnvoll sein, wenn Innovation, Variantenbildung und Anbieter-Know-how bewusst genutzt werden sollen. Im Unterschied dazu ist ein klassisches SOW geeignet, wenn der Auftraggeber die notwendigen Arbeiten bereits relativ klar beschreiben kann.
Für Hardware- und Softwareentwicklung kann die Wahl zwischen SOW, PWS und SOO strategisch relevant sein. Wenn ein Auftraggeber eine sehr konkrete Portierung, Redesign-Aufgabe oder Qualifikationsleistung vergeben will, ist ein SOW oft passend. Wenn ein Anbieter dagegen eine Lösung für ein noch offenes Fähigkeitsproblem entwickeln soll, kann ein SOO geeigneter sein. Wenn eine laufende technische Dienstleistung mit messbaren Ergebnissen beauftragt wird, kann ein PWS sinnvoll sein.
Sprache und Formulierungsqualität
Ein Schwerpunkt von MIL-HDBK-245 liegt auf der Sprache des SOW. Die Anforderungen sollen klar, eindeutig und für alle Programmteilnehmer verständlich sein. Die wichtigste sprachliche Regel lautet: Das SOW soll beschreiben, was der Auftragnehmer leisten muss, aber nicht unnötig vorschreiben, wie der Auftragnehmer intern arbeiten soll. Das ist besonders bei Entwicklungsdienstleistungen wichtig, weil der Auftragnehmer normalerweise Fachverantwortung für seine technische Umsetzung trägt.
Verbindliche Anforderungen werden im englischen SOW-Stil typischerweise mit „shall“ oder „must“ formuliert. „Will“ beschreibt dagegen eher eine Absicht oder eine Handlung des Auftraggebers. MIL-HDBK-245 empfiehlt außerdem aktive Formulierungen. Statt „A test plan shall be prepared“ ist „The contractor shall prepare a test plan“ klarer, weil der verpflichtete Akteur eindeutig benannt wird.
Problematisch sind unbestimmte Formulierungen wie „as required“, „as necessary“, „as applicable“, „assist“, „support“, „including but not limited to“ oder „etc.“. Solche Wörter schaffen Interpretationsspielräume. Ein Auftragnehmer kann kaum belastbar kalkulieren, was „as required“ bedeutet, wenn nicht definiert ist, wann etwas erforderlich ist und in welchem Umfang. Ebenso kann „assist“ den Eindruck erzeugen, dass Auftragnehmerpersonal direkt neben dem Auftraggeber arbeitet und von diesem gesteuert wird. Das kann insbesondere im US-Beschaffungskontext mit der Abgrenzung zwischen personal services und non-personal services kollidieren.
Ein gutes SOW vermeidet deshalb offene Sammelbegriffe. Statt „The contractor shall support testing as required“ wäre eine präzisere Formulierung: „The contractor shall prepare the test procedure, execute the integration test on the prototype hardware, record test results, document deviations, and submit a test report.“ Diese Formulierung benennt die Arbeit, das Objekt, das Ergebnis und die Dokumentation.
Bedeutung für militärische Dienstleister
Für militärische Dienstleister ist das SOW ein zentrales Steuerungsdokument. Es legt fest, welche Leistungen im Rahmen eines Vertrags tatsächlich geschuldet sind. In Verteidigungsprojekten ist das besonders sensibel, weil technische Anforderungen, Exportkontrolle, Informationsschutz, Cyber Security, Safety, Konfigurationsstände, Nachweisführung und Datenrechte eng miteinander verbunden sind.
Ein Dienstleister, der Hardware und Software für militärische Anwendungen entwickelt, benötigt aus dem SOW eine klare Ableitung der eigenen Aufgaben. Dazu gehört beispielsweise, ob der Auftragnehmer nur ein Konzept erstellt oder auch entwickelt, fertigt, integriert, testet und qualifiziert. Ebenso muss klar sein, ob bestehende Hardware übernommen, analysiert oder redesigned werden soll. Bei Software muss das SOW erkennen lassen, ob eine Portierung, Neuentwicklung, Anpassung, Integration, Codeanalyse oder Verifikation geschuldet ist.
Darüber hinaus ist für militärische Dienstleister entscheidend, welche Nachweise und Dokumente aus den Arbeiten entstehen. Beispiele sind technische Berichte, Testpläne, Testberichte, Review-Unterlagen, Konfigurationslisten, Obsoleszenzberichte, Risikoanalysen, Sicherheitsbewertungen oder Produktionsunterlagen. Nach MIL-HDBK-245 sollte das SOW selbst jedoch nicht die komplette Lieferlogik und Formatbeschreibung dieser Dokumente enthalten. Das SOW beschreibt die Arbeit, während CDRL und DID im DoD-Kontext die formale Datenlieferung steuern.
SOW und Work Breakdown Structure
MIL-HDBK-245 empfiehlt, bei der Entwicklung eines SOW eine Work Breakdown Structure zu nutzen. Die WBS dient als strukturierte Zerlegung des Programms oder Produkts in Elemente, die zur Planung, Steuerung und Nachverfolgung genutzt werden können. Sie hilft dabei, das SOW vollständig und logisch aufzubauen. Im Verteidigungsbereich ist hierfür unter anderem MIL-STD-881 relevant.
Für ein Hardware-Software-System kann eine WBS beispielsweise System Engineering, Hardware, Software, Integration, Test, Dokumentation, Projektmanagement und Supportelemente enthalten. Das SOW kann dann entlang dieser Struktur die jeweiligen Arbeitsanforderungen beschreiben. Der Vorteil liegt darin, dass Arbeitspakete, Vertragspositionen, Liefergegenstände und Kostenstruktur besser miteinander abgeglichen werden können.
Wichtig ist, dass die WBS nicht automatisch zu übermäßiger Detailtiefe führt. Sie soll helfen, den Arbeitsumfang vollständig zu erfassen, aber nicht dazu verleiten, jeden internen Arbeitsschritt des Auftragnehmers vorzuschreiben. MIL-HDBK-245 betont grundsätzlich, dass der Auftraggeber Ergebnisse und notwendige Arbeiten beschreiben soll, nicht unnötig interne Vorgehensweisen.
Praktische Relevanz für Hardware- und Softwareprojekte
In der Elektronikentwicklung kann ein SOW den Unterschied zwischen einem kontrollierbaren Entwicklungsauftrag und einem offenen Beratungsmandat ausmachen. Ein SOW für ein Embedded-System sollte den technischen Gegenstand so beschreiben, dass der Auftragnehmer den Umfang abschätzen kann. Dazu gehören Schnittstellen, Einsatzumgebung, vorhandene Systemelemente, zu berücksichtigende Standards, erwartete Entwicklungsstände, Prototypen, Testumfänge und Dokumentationspflichten.
Bei Hardware kann das SOW Aufgaben wie Analyse bestehender Schaltungen, Architekturdefinition, Bauteilauswahl, Schaltplanerstellung, PCB-Layout, Design Review, Prototypenbegleitung, Inbetriebnahme, EMV-Vorbereitung, Fertigungsdaten und Änderungsmanagement enthalten. Bei Software kann es um Requirements-Analyse, Architektur, Treiberentwicklung, Middleware, Applikationssoftware, Bootloader, Updatekonzept, Security-Funktionen, Testautomatisierung, statische Analyse oder Dokumentation gehen.
Bei militärischen Anwendungen kommen zusätzliche Themen hinzu. Dazu gehören Informationsschutz, sichere Entwicklungsprozesse, Umgang mit technischen Daten, Konfigurationsmanagement, Nachweisführung, Obsoleszenzmanagement, Reliability, Maintainability, Safety und Cyber Security. Ein SOW muss diese Themen nicht immer in voller Tiefe beschreiben, sollte aber klar festlegen, welche Arbeiten in diesen Bereichen geschuldet sind.
Typische Fehler bei SOWs
Ein häufiger Fehler besteht darin, technische Produktspezifikationen, Lieferbedingungen, Bewertungskriterien und Arbeitsanforderungen in einem einzigen Dokument zu vermischen. Dadurch entstehen Widersprüche. MIL-HDBK-245 warnt ausdrücklich vor Redundanz, weil doppelte Regelungen zu Konflikten führen können. Wenn eine Lieferfrist im Vertragsteil für Deliveries geregelt ist, sollte sie nicht zusätzlich in abweichender Form im SOW stehen. Wenn das Datenformat in einer CDRL oder DID geregelt ist, sollte das SOW nicht nochmals abweichende Formatvorgaben enthalten.
Ein weiterer Fehler ist Überbeschreibung. Auftraggeber versuchen manchmal, Risiken durch sehr detaillierte Vorgaben zu reduzieren. Tatsächlich kann das Gegenteil eintreten: Der Auftragnehmer verliert Handlungsspielraum, die Lösung wird unnötig eingeengt, und jede Abweichung wird zum Vertragsproblem. Ein SOW sollte daher so präzise wie nötig, aber nicht unnötig kleinteilig sein.
Auch unklare Verantwortlichkeiten sind problematisch. Aussagen wie „The contractor shall support the Government in system integration“ sind ohne weitere Präzisierung schwach. Besser ist eine Formulierung, die festlegt, welche Integrationsaufgaben der Auftragnehmer übernimmt, welche Eingangsdaten oder Beistellungen der Auftraggeber liefert und welches Ergebnis erwartet wird.
Beispielhafte Formulierung für ein Engineering-SOW
Eine gute SOW-Formulierung im Bereich Embedded-Hardware könnte lauten: „The contractor shall develop the schematic design for the controller board based on the system requirements document and the approved hardware architecture. The contractor shall document design assumptions, component selections, interface constraints, and identified technical risks in the hardware design description.“
Für Software könnte eine passende Formulierung sein: „The contractor shall port the existing firmware to the target microcontroller platform, adapt hardware abstraction layers, integrate required peripheral drivers, execute integration tests on the prototype hardware, and document deviations from the baseline software configuration.“
Solche Formulierungen sind besser als allgemeine Aussagen wie „The contractor shall support hardware and software development.“ Sie definieren konkrete Arbeiten und Ergebnisse, ohne dem Auftragnehmer unnötig vorzuschreiben, wie er seine interne Entwicklungsorganisation aufzubauen hat.
Zusammenfassung
Ein Statement of Work ist eine präzise Arbeitsbeschreibung für vertraglich beauftragte Leistungen. Nach MIL-HDBK-245 beschreibt es die vom Auftragnehmer auszuführenden Aufgaben und bildet nach Vertragsschluss einen Maßstab für die Bewertung der Auftragnehmerleistung. Für militärische Dienstleister ist das SOW besonders relevant, weil es Hardware-, Software-, Integrations-, Test-, Dokumentations- und Managementleistungen in einem vertraglichen Rahmen beschreibt.
Im Sinne eines kurzen Lastenhefts kann ein SOW den technischen Gegenstand einer Hardware- oder Softwareentwicklung beschreiben. Sein eigentlicher Schwerpunkt liegt jedoch nicht auf der vollständigen Produktspezifikation, sondern auf der Beschreibung der geschuldeten Arbeiten. Gute SOWs sind eindeutig, aktiv formuliert, frei von vagen Sammelbegriffen und sauber von anderen Vertragsbestandteilen wie Spezifikationen, Lieferplänen, CDRLs und DIDs abgegrenzt.
MIL-HDBK-245 liefert dafür eine robuste Methode: Scope definieren, anwendbare Dokumente gezielt referenzieren, Begriffe klären, Anforderungen als konkrete Arbeitsanforderungen formulieren und eine WBS als Strukturierungshilfe nutzen. Für technische Entwicklungsprojekte im militärischen Umfeld ist ein sauber geschriebenes SOW damit eines der wichtigsten Instrumente, um Erwartungen, Verantwortung und Leistungsumfang zwischen Auftraggeber und Auftragnehmer klar festzulegen.
Zurück zum Glossar