A Statement of Work (SOW) specifies in clear, understandable terms the work to be done in developing or producing
the goods or services to be delivered or performed by a contractor. A SOW needs to be written containing "what is to
be done" in definitive and precise language and terminology. The purpose of a SOW is to detail the work requirements
for projects and programs that have products, deliverables and/or services performed.
I have gradually developed (over the years) both a potential SOW format sample
and a SOW checklist of 50 practical tips that I routinely refer to before I either review or draft a SOW. Such a format
sample and checklist aid in not overlooking important issues. This is a practical format sample and checklist and it is not
intended to address all possible SOW issues. Of course, the contractual position that one takes on SOW issues often depends
whether one is the buyer or seller. There are many aspects to consider – the most helpful of which (in my humble
opinion) are listed below.
SOW FORMAT SAMPLE:
A practical standard SOW format layout
could be as follows:
(1) Introduction/Overview (the project is briefly described);
(1.1) Background (how the project came to be);
Scope (describe the scope of work of the SOW and, if applicable, use a work breakdown structure (WBS);
(1.3) Objectives (specific objectives that the SOW will achieve consistent with scope);
(2) References (a list of all documents or portions of documents referenced in the SOW);
(3) Requirements (the “heart” of the SOW - Tasks, Deliverables, and Schedule);
(3.1) Tasks (sequential order, methodology, specifications/performance requirements, standards, place,
(3.2) Deliverables (work products, acceptance criteria,
(3.3) Schedule (period of performance, milestones, etc.);
(3.4) Assumptions (SOW based on certain assumptions);
(4) Monitoring Progress/Compliance (reports, meetings, reviews, etc.)
Notes (areas of clarification, amplification, other information, etc.)
Of course, a Service Level Agreement can be added to the SOW or be added elsewhere
in the applicable Agreement.
Compensation typically is addressed in a separate contract exhibit, however, it could be added to the SOW
(in the alternative).
GENERAL SOW TIPS:
1. Is the SOW appropriate for the contract type? (For example, fixed price contracts require a tight
SOW while time & materials and cost reimbursement contracts require a looser SOW).
2. Does the SOW describe the requested goods and services in clear and understandable terms?
3. Think of a SOW as defining - what is to be done.
4. Is the work stated explicitly? Be definitive and precise. Don’t use unnecessary narrative. Avoid
5. Is the work set out in logical and chronological
6. Don’t use words with multiple interpretations.
7. Use “shall” when it is mandatory (seller shall drill – not – seller
may drill or seller should drill).
8. Use active voice
(seller shall deliver software – not – software shall be delivered by seller)
9. Use verbs that correctly describe the work requirements (track, document, refine, create, coordinate,
install, verify, define, develop, perform, integrate, conduct, assist, provide, resolve, monitor, acquire, test, revise, record,
conduct, maintain, inform, identify, use, install, implement, etc.).
Don’t use the words “either”, “any” or “and/or”.
11. Avoid pronouns when the applicable noun can be used.
Avoid elegant variations – use the same term for a particular item.
14. Define terms that need to be defined.
15. Define acronyms the first time they are used in the SOW.
16. “Support” is ambiguous. Be specific.
“Engineering and Technical Services” is ambiguous. Be specific.
Is there enough – who – does – what - when – where - information?
19. Are there any more objectives that need to be listed?
Are there any more references to applicable documents that need to be made?
Are there any more specifications, standards, performance requirements, accuracy requirements, and quality requirements that
need to be made?
22. Do any more methodologies need to be stated?
23. Is there anything that is fuzzy?
Are the buyer’s duties and obligations clearly stated?
Are the deliverables clearly stated and described?
26. Are the acceptance criteria
27. Avoid words like ensure, assure, best, all, every,
detailed, certify, as-required, average, adequate, equal, to the extent necessary, any, properly assembled, as directed, and
subject to approval.
28. Use simple sentence structure.
29. Does a level-of-effort need to be stated?
Don’t assume. What is missing?
THREE MAJOR TYPES OF SOWS:
there are the following three major types of SOWs:
design/detailed specification SOW – telling the seller how to do the work;
of effort SOW – where the real deliverable is a certain number of hours of work; and
performance oriented (based) SOW – where the seller is given the freedom to determine how to meet the buyer’s
20 SPECIFIC SOW TIPS:
Do you only need a statement of objectives (SOO) document stating basic top level objectives instead of a SOW so that the
seller can develop a cost-effective innovative solution (later converted to a SOW) meeting the SOO?
2. Should this be a level-of-effort or completion type SOW?
3. Do you need a performance based SOW (performance requirements that define work in measurable terms,
performance standards such as quality and timeliness tied to performance requirements, quality assurance plan describing how
performance is measured against standards, and positive and negative incentives tied to quality assurance plan measurements)?
Remember that the SOW is a part of the legal contract.
5. A well written SOW
allows more opportunities for more potential sellers to compete.
Improper document referencing is a major factor in pricing since total document compliance is implied unless stated
otherwise. Reference only the minimal specifications and standards by tailoring what is really needed.
7. Identify data items required.
Specify “contractor format” when it meets the required need.
Beware of pyramiding of specifications (ever increasing references in one specification to more and more specifications in
10. Use commercial items and practices
if it meets the required need.
11. Should a list of additional services/products
with applicable pricing (options) be provided that are not covered by the current price?
12. Don’t state a requirement as a part of or subset of another requirement since this secondary requirement
may be overlooked by the seller?
13. Don’t tell the seller how
to do the work (unless you are using a design specification).
Don’t use an agreement-to-agree provision in the SOW.
Use drawings, illustrations, diagrams, charts, pictures, tables, graphs, etc. if they clearly improve the communication in
describing the requirements.
16. Have your SOW reviewed by other
knowledgeable people and honestly analyze their comments.
Read the SOW and specifically look for SOW loopholes - then fill them.
Does negative scope need to be added specifically stating work that will not be done under the SOW?
19. Check the SOW for ITARS and EAR export compliance issues.
Are there any conflicts/inconsistencies between the SOW and the contractual terms and conditions?
Many resources are necessary in creating, drafting, and
reviewing a SOW. You could use this sample format and checklist as one of your practical SOW resource tools. You will
probably find that it will cause many SOW-related issues to be surfaced and identified for your consideration. Only by systematically
identifying such SOW issues upfront can they be appropriately resolved in a professional and timely manner.
Your use of this sample format and checklist might prevent
folks from saying the following about the SOWs that you prepare: “Construing such conglomerate provisions
requires a skill not unlike that called for in the decipherment of obscure palimpsest texts.”
"Con-tracts.com" SM is a domain name
and service mark of John ("Johnny") E. Miller