{"id":2187,"date":"2026-05-19T14:40:56","date_gmt":"2026-05-19T14:40:56","guid":{"rendered":"https:\/\/www.pickplace.de\/?post_type=glossary&#038;p=2187"},"modified":"2026-05-19T14:42:30","modified_gmt":"2026-05-19T14:42:30","slug":"statement-of-work","status":"publish","type":"glossary","link":"https:\/\/www.pickplace.de\/de\/glossar\/statement-of-work\/","title":{"rendered":"Statement of Work"},"content":{"rendered":"<p class=\"wp-block-paragraph\">Ein Statement of Work, abgek&#xFC;rzt SoW, ist eine vertraglich verwendbare Arbeitsbeschreibung, mit der festgelegt wird, welche Arbeiten ein Auftragnehmer ausf&#xFC;hren soll. Im <a href=\"https:\/\/www.pickplace.de\/rustung-und-verteidigung\/\" data-type=\"page\" data-id=\"1041\">milit&#xE4;rischen<\/a> und verteidigungsnahen Beschaffungskontext wird der Begriff besonders durch <a href=\"https:\/\/quicksearch.dla.mil\/qsDocDetails.aspx?ident_number=53962\" target=\"_blank\" rel=\"noopener\">MIL-HDBK-245<\/a> gepr&#xE4;gt. Dieses Handbook tr&#xE4;gt den Titel &#x201E;Preparation of Statement of Work (SOW)&#x201C; und beschreibt, wie ein SOW f&#xFC;r Beschaffungen, Entwicklungsleistungen, Dienstleistungen und technische Programme aufgebaut und formuliert werden soll. Das Dokument ist ausdr&#xFC;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&#xFC;r Auftraggeber und Auftragnehmer.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><h2>Inhalt<\/h2><nav><ul><li class=\"\"><a href=\"#ursprung-und-einordnung-nach-mil-hdbk-245\">Ursprung und Einordnung nach MIL-HDBK-245<\/a><\/li><li class=\"\"><a href=\"#zweck-eines-statement-of-work\">Zweck eines Statement of Work<\/a><\/li><li class=\"\"><a href=\"#sow-als-kurzes-lastenheft-fur-hardware-und-software\">SOW als kurzes Lastenheft f&#xFC;r Hardware und Software<\/a><\/li><li class=\"\"><a href=\"#typischer-aufbau-eines-sow\">Typischer Aufbau eines SOW<\/a><\/li><li class=\"\"><a href=\"#abgrenzung-zu-pws-und-soo\">Abgrenzung zu PWS und SOO<\/a><\/li><li class=\"\"><a href=\"#sprache-und-formulierungsqualitat\">Sprache und Formulierungsqualit&#xE4;t<\/a><\/li><li class=\"\"><a href=\"#bedeutung-fur-militarische-dienstleister\">Bedeutung f&#xFC;r milit&#xE4;rische Dienstleister<\/a><\/li><li class=\"\"><a href=\"#sow-und-work-breakdown-structure\">SOW und Work Breakdown Structure<\/a><\/li><li class=\"\"><a href=\"#praktische-relevanz-fur-hardware-und-softwareprojekte\">Praktische Relevanz f&#xFC;r Hardware- und Softwareprojekte<\/a><\/li><li class=\"\"><a href=\"#typische-fehler-bei-so-ws\">Typische Fehler bei SOWs<\/a><\/li><li class=\"\"><a href=\"#beispielhafte-formulierung-fur-ein-engineering-sow\">Beispielhafte Formulierung f&#xFC;r ein Engineering-SOW<\/a><\/li><li class=\"\"><a href=\"#zusammenfassung\">Zusammenfassung<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xFC;hren soll. Es ist also weniger eine reine Produktbeschreibung und st&#xE4;rker eine Arbeits- und Leistungsbeschreibung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Gerade beim Einsatz von milit&#xE4;rischen Dienstleistern, Systemh&#xE4;usern, Engineering-Dienstleistern oder spezialisierten Entwicklungsunternehmen ist das SOW ein zentrales Dokument. Es definiert, welche technischen, organisatorischen und dokumentarischen Leistungen erwartet werden. Dazu k&#xF6;nnen beispielsweise Systementwicklung, Hardwareentwicklung, Softwareentwicklung, Integration, Test, Konfigurationsmanagement, <a href=\"https:\/\/www.pickplace.de\/obsoleszenzmanagement\/\" data-type=\"page\" data-id=\"1201\">Obsoleszenzmanagement<\/a>, Cyber Security, Safety-Aktivit&#xE4;ten, Reviews, Berichte und technische Daten geh&#xF6;ren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"ursprung-und-einordnung-nach-mil-hdbk-245\">Ursprung und Einordnung nach MIL-HDBK-245<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xFC;r den DoD-Kontext geschrieben, hat aber auch au&#xDF;erhalb der US-Verteidigungsbeschaffung praktische Relevanz, weil es eine sehr klare Methode zur Beschreibung komplexer technischer Leistungen bietet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Leitfaden stellt klar, dass ein SOW die wesentlichen und technischen Anforderungen an Gegenst&#xE4;nde, Materialien oder Dienstleistungen beschreibt, einschlie&#xDF;lich der Standards, mit denen &#xFC;berpr&#xFC;ft werden kann, ob Anforderungen erf&#xFC;llt wurden. Gleichzeitig betont MIL-HDBK-245, dass ein SOW insbesondere dann geeignet ist, wenn Aufgaben klar und eindeutig beschrieben werden k&#xF6;nnen. Wenn dagegen eher Zielzust&#xE4;nde und Ergebnisse im Vordergrund stehen und dem Anbieter mehr Freiheit in der L&#xF6;sungsfindung gegeben werden soll, k&#xF6;nnen andere Dokumenttypen wie ein Statement of Objectives (SOO) oder ein Performance Work Statement (PWS) passender sein.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Im Verteidigungskontext ist das wichtig, weil Beschaffungsvorhaben sehr unterschiedlich sein k&#xF6;nnen. Ein SOW f&#xFC;r die Entwicklung einer milit&#xE4;rischen Elektronikeinheit unterscheidet sich von einem SOW f&#xFC;r reine Wartungsleistungen, Softwarepflege, Prototyping, Serienvorbereitung oder technische Dokumentation. MIL-HDBK-245 gibt deshalb keine starre Vorlage f&#xFC;r jedes Vorhaben vor, sondern beschreibt eine Struktur, die an den jeweiligen Beschaffungspfad, Projektstand und Vertragsgegenstand angepasst werden kann.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zweck-eines-statement-of-work\">Zweck eines Statement of Work<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Der Zweck eines SOW besteht darin, die vom Auftragnehmer auszuf&#xFC;hrenden Arbeiten klar, pr&#xFC;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&#xFC;r Auftraggeber, Auftragnehmer, Einkauf, Programmmanagement, technische Leitung, Qualit&#xE4;tssicherung und Vertragsadministration.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Im Engineering-Kontext dient das SOW als Br&#xFC;cke zwischen Bedarf, technischer Spezifikation, Angebot und Vertrag. Es schafft eine Grundlage daf&#xFC;r, dass Anbieter den Aufwand kalkulieren, Risiken bewerten und passende Ressourcen planen k&#xF6;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&#xDF;stab f&#xFC;r die Bewertung der Auftragnehmerleistung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r Hardware- und Softwareentwicklung ist das besonders relevant. Ein unpr&#xE4;zises SOW f&#xFC;hrt schnell zu Scope Creep, Interpretationskonflikten, Nachforderungen, Mehrkosten, Terminverschiebungen oder technischen L&#xFC;cken. Ein pr&#xE4;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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sow-als-kurzes-lastenheft-fur-hardware-und-software\">SOW als kurzes Lastenheft f&#xFC;r Hardware und Software<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Im deutschsprachigen Engineering-Umfeld kann ein SOW als kurze, vertragsorientierte Beschreibung des Hardware- und Software-Gegenstands verstanden werden. Diese Beschreibung enth&#xE4;lt jedoch nicht nur technische Produktanforderungen, sondern auch die zu erbringenden Arbeiten. Bei einem eingebetteten System k&#xF6;nnte ein SOW beispielsweise festlegen, dass der Auftragnehmer eine bestehende Mikrocontroller-Plattform analysiert, eine neue Hardwarearchitektur ausarbeitet, Schaltpl&#xE4;ne erstellt, ein PCB-Layout entwickelt, Prototypen in Betrieb nimmt, Firmware portiert, Treiber implementiert, Testspezifikationen erstellt und definierte Nachweise liefert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das SOW ersetzt dabei nicht zwingend eine detaillierte System Requirements Specification, eine Software Requirements Specification, eine Hardware-Spezifikation oder eine Pr&#xFC;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&#xF6;rt in das SOW. Anforderungen an Lieferung, Format und Inhalt von Daten werden im DoD-Kontext &#xFC;ber CDRL und DID geregelt. Diese Trennung ist wesentlich, weil Redundanz zwischen Dokumenten zu Konflikten f&#xFC;hren kann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r einen milit&#xE4;rischen Dienstleister bedeutet das: Das SOW sagt, welche Arbeiten auszuf&#xFC;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&#xE4;nden, Datenanforderungen und Abnahmeverfahren.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"typischer-aufbau-eines-sow\">Typischer Aufbau eines SOW<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">MIL-HDBK-245 beschreibt einen Grundaufbau mit vier Hauptteilen: Scope, Applicable Documents, Acronyms and Definitions sowie Requirements. Diese Struktur ist einfach, aber f&#xFC;r komplexe Programme tragf&#xE4;hig.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Abschnitt Scope beschreibt den Umfang und die Grenzen des Vorhabens. Er erkl&#xE4;rt, worum es im Projekt geht, welche Arbeiten grunds&#xE4;tzlich abgedeckt sind und welche Zielrichtung der Auftrag hat. Bei komplexeren Vorhaben k&#xF6;nnen Hintergrund, Annahmen oder programmatische Rahmenbedingungen erg&#xE4;nzt werden. Wichtig ist, dass Hintergrundinformationen nicht mit verbindlichen Anforderungen vermischt werden. Hintergrund dient dem Verst&#xE4;ndnis, nicht der Aufgabensteuerung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Abschnitt Applicable Documents nennt die anwendbaren Dokumente, Standards und Referenzen. Dazu k&#xF6;nnen milit&#xE4;rische Standards, technische Spezifikationen, Schnittstellendokumente, Sicherheitsanforderungen, Pr&#xFC;fvorschriften oder Industriestandards geh&#xF6;ren. MIL-HDBK-245 empfiehlt, nur die tats&#xE4;chlich notwendigen Dokumente aufzunehmen und diese m&#xF6;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&#xFC;r den konkreten Leistungsgegenstand gar nicht notwendig sind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Abschnitt Acronyms and Definitions schafft ein gemeinsames Begriffsverst&#xE4;ndnis. In technischen und milit&#xE4;rischen Programmen ist dieser Teil nicht nebens&#xE4;chlich. Begriffe wie Configuration Item, Baseline, Technical Data Package, Acceptance Test, Cybersecurity, Safety Assessment oder Deliverable k&#xF6;nnen je nach Organisation unterschiedlich verstanden werden. Ein SOW sollte daher zentrale Begriffe definieren, wenn Missverst&#xE4;ndnisse wahrscheinlich sind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Abschnitt Requirements enth&#xE4;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&#xF6;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&#xDF;en.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"abgrenzung-zu-pws-und-soo\">Abgrenzung zu PWS und SOO<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">MIL-HDBK-245 stellt das SOW nicht als einzig m&#xF6;glichen Dokumenttyp dar. Zwei verwandte Begriffe sind das Performance Work Statement und das Statement of Objectives.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Performance Work Statement beschreibt die Arbeit st&#xE4;rker &#xFC;ber erwartete Ergebnisse, messbare Outputs und Performance-Ziele. Es wird h&#xE4;ufig bei leistungsorientierten Service-Beschaffungen verwendet. Der Auftraggeber beschreibt also weniger detailliert, welche Einzelt&#xE4;tigkeiten auszuf&#xFC;hren sind, sondern welche Ergebnisse erreicht werden m&#xFC;ssen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Statement of Objectives ist noch st&#xE4;rker zielorientiert. Es nennt die &#xFC;bergeordneten Beschaffungsziele und gibt Anbietern Raum, eine eigene L&#xF6;sung, ein eigenes SOW und passende Liefergegenst&#xE4;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;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&#xF6;sung f&#xFC;r ein noch offenes F&#xE4;higkeitsproblem entwickeln soll, kann ein SOO geeigneter sein. Wenn eine laufende technische Dienstleistung mit messbaren Ergebnissen beauftragt wird, kann ein PWS sinnvoll sein.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sprache-und-formulierungsqualitat\">Sprache und Formulierungsqualit&#xE4;t<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Schwerpunkt von MIL-HDBK-245 liegt auf der Sprache des SOW. Die Anforderungen sollen klar, eindeutig und f&#xFC;r alle Programmteilnehmer verst&#xE4;ndlich sein. Die wichtigste sprachliche Regel lautet: Das SOW soll beschreiben, was der Auftragnehmer leisten muss, aber nicht unn&#xF6;tig vorschreiben, wie der Auftragnehmer intern arbeiten soll. Das ist besonders bei Entwicklungsdienstleistungen wichtig, weil der Auftragnehmer normalerweise Fachverantwortung f&#xFC;r seine technische Umsetzung tr&#xE4;gt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Verbindliche Anforderungen werden im englischen SOW-Stil typischerweise mit &#x201E;shall&#x201C; oder &#x201E;must&#x201C; formuliert. &#x201E;Will&#x201C; beschreibt dagegen eher eine Absicht oder eine Handlung des Auftraggebers. MIL-HDBK-245 empfiehlt au&#xDF;erdem aktive Formulierungen. Statt &#x201E;A test plan shall be prepared&#x201C; ist &#x201E;The contractor shall prepare a test plan&#x201C; klarer, weil der verpflichtete Akteur eindeutig benannt wird.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Problematisch sind unbestimmte Formulierungen wie &#x201E;as required&#x201C;, &#x201E;as necessary&#x201C;, &#x201E;as applicable&#x201C;, &#x201E;assist&#x201C;, &#x201E;support&#x201C;, &#x201E;including but not limited to&#x201C; oder &#x201E;etc.&#x201C;. Solche W&#xF6;rter schaffen Interpretationsspielr&#xE4;ume. Ein Auftragnehmer kann kaum belastbar kalkulieren, was &#x201E;as required&#x201C; bedeutet, wenn nicht definiert ist, wann etwas erforderlich ist und in welchem Umfang. Ebenso kann &#x201E;assist&#x201C; 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein gutes SOW vermeidet deshalb offene Sammelbegriffe. Statt &#x201E;The contractor shall support testing as required&#x201C; w&#xE4;re eine pr&#xE4;zisere Formulierung: &#x201E;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.&#x201C; Diese Formulierung benennt die Arbeit, das Objekt, das Ergebnis und die Dokumentation.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bedeutung-fur-militarische-dienstleister\">Bedeutung f&#xFC;r milit&#xE4;rische Dienstleister<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;r milit&#xE4;rische Dienstleister ist das SOW ein zentrales Steuerungsdokument. Es legt fest, welche Leistungen im Rahmen eines Vertrags tats&#xE4;chlich geschuldet sind. In Verteidigungsprojekten ist das besonders sensibel, weil technische Anforderungen, Exportkontrolle, Informationsschutz, Cyber Security, Safety, Konfigurationsst&#xE4;nde, Nachweisf&#xFC;hrung und Datenrechte eng miteinander verbunden sind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Dienstleister, der Hardware und Software f&#xFC;r milit&#xE4;rische Anwendungen entwickelt, ben&#xF6;tigt aus dem SOW eine klare Ableitung der eigenen Aufgaben. Dazu geh&#xF6;rt beispielsweise, ob der Auftragnehmer nur ein Konzept erstellt oder auch entwickelt, fertigt, integriert, testet und qualifiziert. Ebenso muss klar sein, ob bestehende Hardware &#xFC;bernommen, analysiert oder redesigned werden soll. Bei Software muss das SOW erkennen lassen, ob eine Portierung, Neuentwicklung, Anpassung, Integration, Codeanalyse oder Verifikation geschuldet ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dar&#xFC;ber hinaus ist f&#xFC;r milit&#xE4;rische Dienstleister entscheidend, welche Nachweise und Dokumente aus den Arbeiten entstehen. Beispiele sind technische Berichte, Testpl&#xE4;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&#xE4;hrend CDRL und DID im DoD-Kontext die formale Datenlieferung steuern.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"sow-und-work-breakdown-structure\">SOW und Work Breakdown Structure<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xF6;nnen. Sie hilft dabei, das SOW vollst&#xE4;ndig und logisch aufzubauen. Im Verteidigungsbereich ist hierf&#xFC;r unter anderem MIL-STD-881 relevant.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&#xFC;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&#xE4;nde und Kostenstruktur besser miteinander abgeglichen werden k&#xF6;nnen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wichtig ist, dass die WBS nicht automatisch zu &#xFC;berm&#xE4;&#xDF;iger Detailtiefe f&#xFC;hrt. Sie soll helfen, den Arbeitsumfang vollst&#xE4;ndig zu erfassen, aber nicht dazu verleiten, jeden internen Arbeitsschritt des Auftragnehmers vorzuschreiben. MIL-HDBK-245 betont grunds&#xE4;tzlich, dass der Auftraggeber Ergebnisse und notwendige Arbeiten beschreiben soll, nicht unn&#xF6;tig interne Vorgehensweisen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"praktische-relevanz-fur-hardware-und-softwareprojekte\">Praktische Relevanz f&#xFC;r Hardware- und Softwareprojekte<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">In der Elektronikentwicklung kann ein SOW den Unterschied zwischen einem kontrollierbaren Entwicklungsauftrag und einem offenen Beratungsmandat ausmachen. Ein SOW f&#xFC;r ein Embedded-System sollte den technischen Gegenstand so beschreiben, dass der Auftragnehmer den Umfang absch&#xE4;tzen kann. Dazu geh&#xF6;ren Schnittstellen, Einsatzumgebung, vorhandene Systemelemente, zu ber&#xFC;cksichtigende Standards, erwartete Entwicklungsst&#xE4;nde, Prototypen, Testumf&#xE4;nge und Dokumentationspflichten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei Hardware kann das SOW Aufgaben wie Analyse bestehender Schaltungen, Architekturdefinition, Bauteilauswahl, Schaltplanerstellung, PCB-Layout, Design Review, Prototypenbegleitung, Inbetriebnahme, EMV-Vorbereitung, Fertigungsdaten und &#xC4;nderungsmanagement enthalten. Bei Software kann es um Requirements-Analyse, Architektur, Treiberentwicklung, Middleware, Applikationssoftware, Bootloader, Updatekonzept, Security-Funktionen, Testautomatisierung, statische Analyse oder Dokumentation gehen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei milit&#xE4;rischen Anwendungen kommen zus&#xE4;tzliche Themen hinzu. Dazu geh&#xF6;ren Informationsschutz, sichere Entwicklungsprozesse, Umgang mit technischen Daten, Konfigurationsmanagement, Nachweisf&#xFC;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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"typische-fehler-bei-so-ws\">Typische Fehler bei SOWs<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein h&#xE4;ufiger Fehler besteht darin, technische Produktspezifikationen, Lieferbedingungen, Bewertungskriterien und Arbeitsanforderungen in einem einzigen Dokument zu vermischen. Dadurch entstehen Widerspr&#xFC;che. MIL-HDBK-245 warnt ausdr&#xFC;cklich vor Redundanz, weil doppelte Regelungen zu Konflikten f&#xFC;hren k&#xF6;nnen. Wenn eine Lieferfrist im Vertragsteil f&#xFC;r Deliveries geregelt ist, sollte sie nicht zus&#xE4;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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein weiterer Fehler ist &#xDC;berbeschreibung. Auftraggeber versuchen manchmal, Risiken durch sehr detaillierte Vorgaben zu reduzieren. Tats&#xE4;chlich kann das Gegenteil eintreten: Der Auftragnehmer verliert Handlungsspielraum, die L&#xF6;sung wird unn&#xF6;tig eingeengt, und jede Abweichung wird zum Vertragsproblem. Ein SOW sollte daher so pr&#xE4;zise wie n&#xF6;tig, aber nicht unn&#xF6;tig kleinteilig sein.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auch unklare Verantwortlichkeiten sind problematisch. Aussagen wie &#x201E;The contractor shall support the Government in system integration&#x201C; sind ohne weitere Pr&#xE4;zisierung schwach. Besser ist eine Formulierung, die festlegt, welche Integrationsaufgaben der Auftragnehmer &#xFC;bernimmt, welche Eingangsdaten oder Beistellungen der Auftraggeber liefert und welches Ergebnis erwartet wird.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"beispielhafte-formulierung-fur-ein-engineering-sow\">Beispielhafte Formulierung f&#xFC;r ein Engineering-SOW<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Eine gute SOW-Formulierung im Bereich Embedded-Hardware k&#xF6;nnte lauten: &#x201E;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.&#x201C;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F&uuml;r Software k&ouml;nnte eine passende Formulierung sein: &bdquo;The contractor shall port the existing firmware to the target <a class=\"glossaryLink\"  href=\"https:\/\/www.pickplace.de\/de\/glossar\/mikrocontroller\/\"  data-gt-translate-attributes='[{\"attribute\":\"data-cmtooltip\", \"format\":\"html\"}]' tabindex='0' role='link'>microcontroller<\/a> platform, adapt hardware abstraction layers, integrate required peripheral drivers, execute integration tests on the prototype hardware, and document deviations from the baseline software configuration.&ldquo;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Formulierungen sind besser als allgemeine Aussagen wie &#x201E;The contractor shall support hardware and software development.&#x201C; Sie definieren konkrete Arbeiten und Ergebnisse, ohne dem Auftragnehmer unn&#xF6;tig vorzuschreiben, wie er seine interne Entwicklungsorganisation aufzubauen hat.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"zusammenfassung\">Zusammenfassung<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Statement of Work ist eine pr&#xE4;zise Arbeitsbeschreibung f&#xFC;r vertraglich beauftragte Leistungen. Nach MIL-HDBK-245 beschreibt es die vom Auftragnehmer auszuf&#xFC;hrenden Aufgaben und bildet nach Vertragsschluss einen Ma&#xDF;stab f&#xFC;r die Bewertung der Auftragnehmerleistung. F&#xFC;r milit&#xE4;rische Dienstleister ist das SOW besonders relevant, weil es Hardware-, Software-, Integrations-, Test-, Dokumentations- und Managementleistungen in einem vertraglichen Rahmen beschreibt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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&#xE4;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&#xE4;nen, CDRLs und DIDs abgegrenzt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">MIL-HDBK-245 liefert daf&#xFC;r eine robuste Methode: Scope definieren, anwendbare Dokumente gezielt referenzieren, Begriffe kl&#xE4;ren, Anforderungen als konkrete Arbeitsanforderungen formulieren und eine WBS als Strukturierungshilfe nutzen. F&#xFC;r technische Entwicklungsprojekte im milit&#xE4;rischen Umfeld ist ein sauber geschriebenes SOW damit eines der wichtigsten Instrumente, um Erwartungen, Verantwortung und Leistungsumfang zwischen Auftraggeber und Auftragnehmer klar festzulegen.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Ein Statement of Work, abgek\u00fcrzt SoW, ist eine vertraglich verwendbare Arbeitsbeschreibung, mit der festgelegt wird, welche Arbeiten ein Auftragnehmer ausf\u00fchren soll. Im milit\u00e4rischen und verteidigungsnahen Beschaffungskontext wird der Begriff besonders durch MIL-HDBK-245 gepr\u00e4gt. Dieses Handbook tr\u00e4gt den Titel \u201ePreparation of Statement of Work (SOW)\u201c und beschreibt, wie ein SOW f\u00fcr Beschaffungen, Entwicklungsleistungen, Dienstleistungen und technische [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"menu_order":0,"template":"","meta":{"footnotes":""},"class_list":["post-2187","glossary","type-glossary","status-publish","hentry"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/glossary\/2187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/glossary"}],"about":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/types\/glossary"}],"author":[{"embeddable":true,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/users\/1"}],"version-history":[{"count":2,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/glossary\/2187\/revisions"}],"predecessor-version":[{"id":2189,"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/glossary\/2187\/revisions\/2189"}],"wp:attachment":[{"href":"https:\/\/www.pickplace.de\/de\/wp-json\/wp\/v2\/media?parent=2187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}