The two-day Statement of Work (SOW) course provides detailed instructions on the conversion of work or service requirements into highly effective SOWs. Issues of structure (organization of information) and the use of (English) language throughout a SOW are examined in considerable detail. A high quality template/guide is provided for the specification of work or services, with examples. The training is strongly workshop oriented throughout. The techniques of SOW writing which are taught have been used to great effect in scenarios which include acquisition, supply, product definition (both hardware and software including the provisioning of services), enterprise internal projects, business analysis and engineering projects of diverse types, large and small.
Key Learning Objectives
At the conclusion of the course, delegates are expected to:
- understand the concept and fundamentals of a Statement of Work;
- understand the context of a SOW with reference to other contractual and technical documents;
- identify the desired characteristics for a Statement of Work;
- know the differences between the different types of SOW;
- define properly worded requirements for a SOW;
- structure a SOW for a specific use; and
- use an appropriate language style for a SOW.
Training Method and Materials
The course is delivered through a mixture of presentation and practical exercises, discussion and group work sessions.
Delegates will be provided with:
- comprehensive course notes;
- workshop model solutions;
- a library in soft copy form of high quality data item descriptions for key requirements-related documents (or their screen equivalents):
- Operational Concept Description
- Capability System Requirements Specification
- System Requirements Specification
- Software Requirements Specification
- Interface Requirements Specification
- Statement of Work
- Verification Requirements Specification
- a library in soft copy form of high quality examples of key requirements-related documents (or their screen equivalents), as a coordinated set:
- Operational Concept Description– for an element of solution to the capability system
- Capability System Requirements Specification – for an example capability system
- System Requirements Specification – for an element of solution to the capability system
- Statement of Work – for user training for an element of solution to the capability system
- Verification Requirements Specification– for an element of solution to the capability system
- checklists, forms and charts which you can use immediately in your projects; and
- complimentary access to PPI’s evolving Systems Engineering Goldmine.
Who Should Attend this Course?
Specification Writing is designed for acquirer, supplier and developer personnel who, in any capacity, deal with requirements.
1. Transforming Work Requirements into Statements of Work
- contexts within which sow writing is done
- the SOW as a contractual driver
- definition of a requirement
- what is a statement of work?
- how statements of work relate to work requirements
- statement of work purposes
- fundamental statement of work criteria
- organizing requirements for the statement of work
- types of requirements
This short introduction makes the distinction between work requirements and statements of work, and provides guidance on preparing, within requirements analysis, for the transition of requirements in a database form to requirements in a document-based statement of work form.
2. Context of a SOW
- relationship between the SOW and requirements specifications
- relationship between the SOW and the supplier performance
- relationship between the SOW and the RFP/Contract
- what to put in your system requirements specification, the statement of work (or equivalent) and the conditions of contract
- workshop 1 – allocating requirements to solicitation documents
This short module examines the relationships between the SOW, requirements specifications, supplier performance and the RFP/contract.
High quality templates in the form of Data Item Descriptions (DID’s) are distributed for system requirements specifications, software requirements specifications, interface requirements specifications, interface design descriptions, statements of work/task descriptions, and verification requirements specifications.
For groups for which structuring solicitation packages (requests for proposal, requests for tender, etc.) is relevant, the module considers this subject, supported by a workshop activity.
3. Statement of Work Primary Orientations and Requirements
- Functionally oriented SOW
- Process (Design) oriented SOW
- MIL-HDBK-245D guidance
Two orientations of statements of work are described in this module. MIL-HDBK-245D is summarized, including major pitfalls, and advice is provided on its use.
4. Structuring your SOW
This module provides, through discussion, explanation and considerable workshop activity, the principles and methods for structuring a statement of work to be effective.
A statement of work is then structured from start to finish. This session deals comprehensively with one of the three determinants of the effectiveness of a statement of work: information content, organization of the information, and writing of individual requirements.
A detailed description of the coverage of the course in this area follows.
- development approach
- structuring the work – The WBS
- SOW general guidance
- life cycle Considerations
- structuring natural language statements of work
- workshop 2 – writing a scope section
- applicable document
- definitions, acronyms and abbreviations
- identification of sources/destination of inputs/outputs
- identification of required states and modes
- relationships between required states and modes
- task functional and performance requirememts
- workshop 3 – structuring a SOW to deal with states, modes and functions
- functionally oriented versus design oriented SOW requirements
- workshop 4 – classifying specified requirements as functional or design
- workshop 5 – writing a functionally oriented SOW requirements section
- workshop 6 – writing a design oriented SOW requirements section
- specification of required input and outputs
- environmental requirements
- resource requirements
- other qualities of the work task
- process direction
- assurance requirements
- notes and annexes
5. Requirements Specification Writing
This module provides, through discussion, explanation and substantial workshop activity, extensive guidance on writing both non-requirements sections of a SOW, and on writing individual requirements. In the latter respect, many pitfalls, pointers and work-arounds are addressed, to increase requirements writing skills in English.
This session deals comprehensively with one of the three determinants of the effectiveness of a requirements specification: information content, organization of the information, and writing of individual requirements.
A detailed description of the coverage of the course in this area follows.
- applicable documents and precedence
- workshop 7 – using precedence
- definition of terms
- workshop 8 – defining of terms
- review of requirements quality
- requirement structural template
- workshop 9 – writing requirements using the parsing template
- requirements constructs
- shall, should, will, and may
- workshop 10 – linking and cross-referencing
- using success criteria to express otherwise vague requirements
- workshop 11 – using success criteria
- workshop 12 – key specification for a service
- work boundary
- requirements incorporating approval
- expressing exceptions and alternatives
- specifying other qualities
- use of supporting data
- mission profiles/use cases
- baseline designs
- verification specifications
- common pitfalls, do’s and don’ts
- optional workshop – evaluation of example SOWs
- additional reference material
Some Key Questions
- Why do requirements errors cost more to correct than any other class of error?
- Do “requirements” that are not “in the contract” have any effect in a contractual scenario?
- What are the differences between functionally oriented (what and how well) and design (how) statements of work, and when should each be used?
- Why is the use of a requirements structural model the sure-fire path to producing strong statements of work?
- How can I best structure my statement of work?
- What requirements syntax produces the best statements of work?