*  Fifty Tips for Your Statement of Work (SOW) -  NCMA Contract Management (CM) Magazine in August 2007 .   Awarded the National Contract Management Association (NCMA) 2007 - 2008  “Delaney Award” for writing the best article in the NCMA “Contract Management Magazine” in 2007 – “Fifty Tips for Your Statement of Work”.  This co-award was presented to me by NCMA in Cincinnati on April 14, 2008

Johnny Miller 
"Con-tracts.com" SM
Here is some information about the … “Statement of Work” … that I have prepared that may potentially be useful as you work with your suppliers and customers. 

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.




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);
(1.2) 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, travel, etc.);
(3.2) Deliverables (work products, acceptance criteria, etc.)
(3.3) Schedule (period of performance, milestones, etc.);
(3.4) Assumptions (SOW based on certain assumptions);
(4) Monitoring Progress/Compliance (reports, meetings, reviews, etc.)

(5) 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). 



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 redundancy.
5.  Is the work set out in logical and chronological order?
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.).
10. Don’t use the words “either”, “any” or “and/or”.
11. Avoid pronouns when the applicable noun can be used.
12. Avoid elegant variations – use the same term for a particular item.
13. Avoid ambiguity.
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.
17. “Engineering and Technical Services” is ambiguous. Be specific.
18. Is there enough – who – does – what - when – where - information?
19. Are there any more objectives that need to be listed?
20. Are there any more references to applicable documents that need to be made?
21. 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?
24. Are the buyer’s duties and obligations clearly stated?
25. Are the deliverables clearly stated and described?
26. Are the acceptance criteria clearly stated?
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?
30. Don’t assume. What is missing?

Generally, there are the following three major types of SOWs: 


(1). design/detailed specification SOW – telling the seller how to do the work;

(2). level of effort SOW – where the real deliverable is a certain number of hours of work; and

(3). performance oriented (based) SOW – where the seller is given the freedom to determine how to meet the buyer’s requirements.




1.  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)? 
4.  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.
6.  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.
8.  Specify “contractor format” when it meets the required need.
9.  Beware of pyramiding of specifications (ever increasing references in one specification to more and more specifications in another specification).
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).
14. Don’t use an agreement-to-agree provision in the SOW.
15. 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.
17. Read the SOW and specifically look for SOW loopholes - then fill them.
18. 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.

20. 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