5

The SOW Format

It is important to organize the presentation of information in your SOW effectively. One of the common problems with SOWs occurs when different categories of information are mixed, making it difficult to identify the requirements and their relationships.

View the SOW as a large box divided into separate compartments of information pertinent to the description of your requirement. Your job is to sort the information into appropriate compartments, with each compartment containing just one type of information. Organizing the format of your SOW around the types of information to be presented helps ensure that all related information is presented in one place in the SOW.

A sample SOW format is shown in Figure 5-1. It should be noted that this is simply a sample and is not intended to be taken as a standard. The format you use should be customized to best fit the needs and requirements of your project and organization.

The items listed in Figure 5-1, which represent the ten types of information common to most SOWs, fall into three major categories. First is the general information necessary to introduce the requirement to the contractor. Next are the work requirements, which are the most important part of the SOW. Third is the supporting information necessary to complete the description of your requirement.

These categories can be used as your SOW format; they are general enough to fit most requirements. While you must tailor each SOW to its own requirements, your first step should be to separate the information into the appropriate SOW sections. A particular SOW may not require each of these information types, but you should consider each initially to determine if it is applicable.

FIGURE 5-1:
Sample Sow Format

As noted, the format in Figure 5-1 is just one of many ways to organize your SOW. Any sensible format is acceptable. The specific format used is not as important as ensuring that the SOW information is separated according to the categories of information and presented in a coherent fashion.

Organizing your SOW well makes it easier for the author to write and for everyone else to read. It is easier to write because the basic outline is established—all you have to do is fill in the details. It is easier to read because the information is presented in a coherent fashion. The grouping of similar information into a single section helps avoid confusion and redundancy (although some redundancy may be required) and presents a clear picture of your requirement. This not only enhances the contractor’s ability to read and understand the SOW, but also simplifies its review by contracting and higher management personnel.

This chapter describes the SOW contents using the format presented in Figure 5-1. The purpose of each SOW section is described, and comments are provided about what information should be placed in the section. When appropriate, the relationship of the SOW information to the proposal preparation instructions is also addressed.

SOW PART I: GENERAL INFORMATION

The information presented in Part I of the SOW provides a general introduction to the work requirements described in Part II. Part I is introductory in nature, so keep it short and to the point.

The introduction, background, and scope sections may be written as individual sections or combined. The purpose of these sections is to ensure that the contractor understands the purpose and extent of the requirement, and how it relates to the overall program. Do not include specific work-related information in these sections; that information goes in Part II: Work Requirements.

Section A: Introduction

The purpose of the introduction is simply to “title” the SOW. It provides a general description of the requirement, with only enough detail for a contractor to recognize generally what the procurement is about.

The most common problem in writing an introduction is length. Normally no more than two or three sentences are needed. Specific details are not required; they are provided in the technical requirements section. The introduction below is an example of an overly long introduction:

The purpose of the first two sentences in the last paragraph of this introduction is not clear. There was no other reference to a task WBS in the solicitation. In any event, this is either a work requirement or a solicitation requirement, and it therefore should not be in the introduction. If it is a contractual requirement (something that is developed after contract award), it should be described as such in Part II, in the technical requirements section of the SOW. If it is a solicitation requirement (required for purposes of evaluation), it should be included in the proposal preparation instructions.

The first paragraph of the example is fine if it is intended to combine the introduction and background sections, but if there is to be both an introduction and a background section in this SOW, there are several better alternatives.

Alternative 1 simplifies the introduction by using only the third sentence of the first paragraph and the third sentence of the second paragraph as introductory information. The other information in the first paragraph is background information, and the other information in the second paragraph should be in the proposal preparation instructions.

In addition to the changes made by Alternative 1, Alternative 2 moves the listing of the functional areas to an introductory paragraph in Part II: Work Requirements. When the work requirements consist of multiple tasks, it is a good idea to use an introductory paragraph in Part II to summarize the tasks to be addressed rather than to place this information in the Part I introduction. Otherwise, when the SOW is printed there will be too much physical separation between the summary information and the details of the work requirement.

In addition to the changes made by Alternatives 1 and 2, Alternative 3 reduces the introduction to its absolute minimum by omitting the information on the definition of particular missions and future assignments. Instead, that information is placed in the introductory paragraph in Part II: Work Requirements.

Clearly, there are a number of ways to present the introduction. The key is that the introduction should not contain information relating to specific requirements or information better placed elsewhere in the SOW.

Section B: Background

The purpose of the background section is to describe how the requirement evolved and its relationship to the project it supports. This information helps the contractor understand the overall project environment and how the proposed work relates to it.

For example, if the requirement is for an IT system or software, the problems with the existing system or software that the new requirement is to correct should be identified. If the contractor understands where the current requirement comes from and where the project is headed, it is in a better position to offer ideas that will help attain these goals. The background is particularly important when you are seeking innovations and state-of-the-art effort.

The background is usually described in two or three paragraphs; however, there are exceptions. For example, the SOW for the management of a breeding and experimental facility for woodchucks (for research purposes) contained a four-page background section. It outlined the history and results of studies of progressive hepatic diseases and their relationship to the woodchuck facility where such studies are conducted. This background information, although long, provided significant information related to the purpose of the facility and the associated research.

The background section provides the historical information the contractor needs to understand the current requirement. Generally, this section is short and concise, but its purpose is to provide necessary information, not to save paper. The problem with long background sections is that current requirement may be addressed in this section, rather than in the work requirements section where it belongs. This misplaced requirement can cause confusion and adversely affect your project. (In the woodchuck facility example, there was no reference at all to the current requirement.)

When writing your background section, identify related research, studies, or other efforts that contribute to the contractor’s understanding of the requirement. Reference these as background information, but explain the specific relationships as part of the appropriate task descriptions in the technical requirements section in Part II. For example, if a series of studies led to the current requirement, describe the studies (briefly) in the background section. Then include the details of how the studies support the current requirement in the appropriate task descriptions in the technical requirements section.

Technical problems that have occurred in past contracts for the same or similar effort should be identified to help avoid the same problems in the current contract. Mention the problems as part of the background, but reserve their specific description for the appropriate task description in the technical requirements section of Part II. This keeps the problems in context with the work requirement.

A common writing problem occurs when details of a work requirement are mentioned in the background section and then later in the technical requirements section, but with different wording, so that there appears to be two different work requirements. Avoid this problem by paying careful attention to the purpose of each section and limiting each SOW section to a specific kind of information.

Section C: Scope

The purpose of the scope section is to describe the overall project purpose and specific objectives of the requirement to help the contractor understand the size or magnitude of the anticipated effort. You do not want the contractor to propose a major R&D effort, for example, when all you are seeking is a simple study or analytic effort.

State the project purpose and specific objectives of the requirement in terms that indicate the relative size or magnitude of the effort. For example:

In labor-intensive requirements, you may also express the scope in terms of the estimated number of work hours, work days, or work months required for contract performance. This may be done by task, as an overall figure, or broken down by labor category, as long as it contributes to contractor understanding of the scope of the effort. For example:

The estimated level of effort is as follows:

Labor category	Hours
Principal investigator	1,872
Co-investigators	2,309
Research support	16,224
Animal technicians	6,552
Clerical/administrative support	4,992

Some agencies, when contracting for services, use locally developed level-of-effort clauses to express the estimated level of effort required by each labor category. In such instances, draw the contractor’s attention to the clause by referencing it in the scope section. For example:

As noted earlier, specific resource requirements are not necessarily appropriate for a PWS used in performance-based contracting (see Chapter 3) or in a statement of objectives (SOO) (see Chapter 4).

Generally, you should not indicate the scope in terms of the amount of funds available. Contractors accept a work-hour estimate as an indicator of the magnitude of the effort, but a dollar amount tends to be viewed as a goal. When dollar amounts are used, contractors may structure their proposals around the dollars available rather than the actual requirements, particularly if the procurement is sole source.

In some industries, however, such as construction and advertising, dollar figures are commonly used to indicate project scope. In such instances, indicate the scope by dollar ranges or not-to-exceed figures, but do not reveal the government’s estimate or level of funding. When using an SOO, however, it may be appropriate to indicate the level of funding (see Chapter 4) because the contractor will be proposing the complete SOW and must show that the requirement will be met in an efficient and effective manner.

Section D: Applicable Documents

The purpose of this section is to provide the contractor a consolidated listing of all documents cited in the SOW as part of the work requirement. The listing helps ensure that the contractor does not overlook a pertinent document that might affect how the contractor develops its proposal or performs the work. These documents include government directives, formal government or commercial specifications and standards, and other documents specifically cited in the SOW as applicable to the work effort. Documents that are mentioned in the SOW but not cited as part of the work requirement, such as illustrations or examples, should not be included.

The listing of applicable documents is placed early in the SOW to ensure that the contractor reads it. If you place it at the end of the SOW, or include it as an attachment, it is more likely to be overlooked. This information is important and needs to be prominently displayed. If the contractor fails to include the requirements of a cited document in the end product, it may adversely affect contract performance.

When writing this section, be sure to identify each document by title, number (if applicable), and date of the pertinent edition or revision. For example, if the SOW required the contractor to prepare a report using Microsoft Word, the citation in the Applicable Documents section might read:

Microsoft Word Users Guide, Version ____, Dated ____

A complete reference for each document, particularly the edition or date, is important. It establishes the legal relationship of the cited document to the work requirement. If a cited document is revised after contract award, the revision does not apply to the contract unless the contract is modified accordingly.

Do not use language that attempts to hold the contractor responsible for keeping up with changes to cited documents. This is generally unenforceable because the government is responsible for defining its requirements and updating them as necessary.

Review each document carefully to ensure that only the pertinent portions are referenced. If a document is referenced only by its title, the entire document becomes part of your SOW. This may create a problem if the referenced document contains requirements that conflict with other SOW or contract requirements. If only part of a document applies, reference only the applicable portions, down to the paragraph or sentence level if necessary. In addition, any allowable deviations should be identified either by direct citation or by reference to the appropriate SOW paragraph. For example:

As part of the citation for each document, it is important to indicate if the document is attached to the SOW by using the phrase “see attachment __.” If the cited document is not provided with the SOW, provide the name and address of the entity or the web address/URL where the document can be obtained. If the document is not available to the contractor because it is classified or otherwise restricted, inform the contractor where the document may be viewed and how to obtain any necessary permission.

Ask the contracting officer if a contract clause will be used to provide the required direction with respect to referenced documents. If a clause will be used, you need only indicate that the clause provides the required direction. For example, four standard FAR clauses are available for use when federal or military specifications are involved:

• 52.211-1, Availability of Specifications Listed in the GSA Index of Federal Specifications, Standards and Commercial Item Descriptions, FPMR Part 101-29, which describes how to obtain federal specifications, standards, and commercial item descriptions

• 52.211-2, Availability of Specifications, Standards, and Data Item Descriptions Listed in the Acquisition Streamlining and Standardization Information System (ASSIST), which describes how to obtain military specifications and standards

• 52.211-3, Availability of Specifications Not Listed in the GSA Index of Federal Specifications, Standards and Commercial Item Descriptions, which describes how to obtain specifications, standards, and commercial item descriptions that are not available through GSA

• 52.211-4, Availability for Examination of Specifications Not Listed in the GSA Index of Federal Specifications, Standards and Commercial Item Descriptions, which describes how to go about examining specifications, standards, and commercial item descriptions that are not available for distribution.

The FAR clauses may be used as examples for the development of local clauses when the cited documents are not federal or military specifications, standards, or commercial item descriptions.

The related SOW paragraph should be referenced for each entry, unless doing so would be unnecessarily confusing, such as when each entry requires multiple references. This might happen, for example, when a cited document applies to a number of different tasks. In such instances it is better not to include any references, as a long list of referenced SOW paragraphs makes for difficult reading.

If the SOW does not reference other documents as part of the requirement, this section is not needed.

SOW PART II: WORK REQUIREMENTS

Section A of the work requirements addresses technical requirements and Section B addresses deliverables.

Section A: Technical Requirements

The purpose of Part II, Section A, is to describe the contractual work requirements. This is the most important part of the SOW. This section contains all of the technical details related to the work requirement. You must describe the work requirements, the required end products, and any special considerations or restraints that apply. In addition, you must provide the criteria that will be used in determining whether the requirements are met.

It is important to note that the SOW applies only to actions taken after contract award. Do not include any material related to the contractor’s proposal or other matters pertaining to the solicitation or source selection process.

Describe the Work Requirements

Your description of the work requirement must be definitive enough to serve as the basis for the contractor’s technical, management, and pricing proposals. If the contractor responds to your solicitation with questions seeking to clarify your requirement, you have failed to express that requirement adequately.

Your description of the work requirement should reflect the results of the market research conducted to determine what the commercial marketplace has to offer, its capabilities and practices, how it describes its work outputs or products (such as performance indicators, performance standards, and acceptable quality levels), and if there have been technological or other changes in the products or services required that would affect how the requirement is described.

You should carefully consider the ramifications of your description. For example, your requirement is for a contractor to run a soil testing program, and you describe the requirement by saying, “the contractor shall test all soil samples.” What are you testing for, and why? What kinds of tests must the contractor conduct? How many tests are required? When and where shall the contractor conduct these tests? These are just a few of the questions that will go unanswered if you oversimplify or generalize the description of your work requirement.

You must explicitly state your requirements in the initial SOW or require the contractor to provide the necessary detail in its proposal for incorporation in the final SOW (except when using an SOO). If you do not, you may get exactly what you asked for rather than the required end product. The following steps can help guide you in describing your work requirements.

1. Divide the Work into Tasks

Divide the work into separate tasks and related subtasks, if possible, and describe each one separately. Make each task description stand alone. Describe the work related to each task, including the criteria for determining whether the requirements are met. When writing a PWS, the criteria for determining whether the requirements are met would be expressed as performance indicators, performance standards, and the AQL, and placed at the end of the applicable task or subtask description.

Reference other tasks as necessary to establish relationships and avoid redundancies. For example, if part of the requirement of a particular task is to be performed in the same manner as in an earlier task, simply indicate that the work is to be performed as in the earlier task rather than repeating the requirement:

Be careful, however, about how you use references. Do not reference references. If you have three tasks and each task requires the use of the same statistical sampling methodology, reference the sampling requirements of the first task in each of the following tasks. If Task 2 simply references Task 1, do not reference the sampling requirements of Task 2 when describing Task 3. For example, if Task 1 establishes a requirement for the use of a specific statistical sampling methodology, the same requirement in Task 2 would be expressed by referencing the requirement in Task 1. The same requirement in Task 3 would also be expressed by referencing the requirement in Task 1.

Multiple references make a task description difficult to read and can cause misunderstandings. For example:

If you used references in each of the cases in this example, the contractor would have to be searching back and forth continually to figure out what is to be done. It is better in such instances simply to repeat the requirements in full. The SOW must effectively communicate your requirements; clarity is more important than saving paper.

2. Use Functional Descriptions or Performance-Based Descriptions

Describe each task and subtask as a functional or performance-based requirement. Use design parameters only as necessary to ensure that the end product will meet your requirements. Describe the key technical requirements that must be accomplished to produce the desired results. Identify what needs to be done, who will do it, and when. Describe each task completely. Describe what each product is expected to do or accomplish in terms that establish performance objectives and set design parameters for that product.

As appropriate, relate the product’s major critical characteristics to categories, such as performance, operational suitability, standardization, and interfaces. Require the submission of drafts when the interim or end product is a report. Indicate the required time frames for review, approval, and revisions of the drafts.

3. Define Requirements

Define the project requirements as precisely as possible within the context of a functional or performance-based description. Keep in mind that the description must focus on what is to be accomplished, not provide the details of how to do the work.

In an R&D effort, for example, describe any major scientific or technical breakthroughs required. If you require the solution of a specific research problem, define the problem so that it stands out from any collateral or peripheral research requirements. In effect, make sure that your SOW aims the contractor in the direction you intend. Regardless of the nature of your requirement, when there is associated effort to be performed, make sure that your SOW describes the relative importance of each part of your requirement.

To the extent possible, describe the relationships among requirements, systems, and subsystems, as well as with other projects. For example, if the requirement involves the development of computer software, describe its operating environment (i.e., the hardware and software, such as operating systems, database management systems, and utility software) to the extent possible. This description will help ensure that the contractor will provide software compatible with the environment in which it must operate.

Do not assume that the contractor will intuitively understand the performance requirements. This is particularly important when developing an SOW for a sole-source procurement. As noted earlier, there is a tendency in sole-source procurements to write SOWs based on discussions with the contractor rather than the actual government requirement. This can result in unwritten requirements that you and the contractor have already discussed and agreed to. Be careful that you do not overlook such requirements; they must be described in the SOW.

4. Describe All Work Elements

Describe all specific work elements, including documentation and data requirements; phasing requirements; quality, reliability, and maintainability requirements; fabrication requirements; testing requirements; and installation requirements. Do not overlook work elements that occur at the end of the contract, such as training and maintenance. If you are uncertain about some work elements, use the proposal preparation instructions to require the contractor to discuss the specific work elements and then incorporate any added information into the final SOW.

The following excerpt from an SOW for the presentation of training courses illustrates the need to define all work elements fully:

The problem is not what is stated in this example but what is not stated. Testing requirements are not mentioned anywhere else in the SOW, not even in the descriptions of the courses to be presented. This leaves the question of testing up to the contractor. The development and maintenance of tests is a time-consuming and expensive task, if done properly. In this instance, the contractor could decide not to use any testing at all (to lower contract costs) and still fully meet the stated contract requirements. If testing is part of the requirement, it must be explicitly described as such.

In another instance, an RFP for a specific training course failed to say anything about textbooks. The contractor proposed to teach from the applicable Navy directives (not creating a textbook lowered the contract price significantly) and was awarded the contract. Later, the COTR complained about the lack of textbooks. The contractor pointed to the RFP and contract, saying there was no such requirement. End of story.

Do not generalize the work elements with statements such as, “the contractor shall provide all necessary supporting documentation.” This permits the contractor to decide what supporting documentation is necessary, and you may not be happy with the results. For example:

• Manufactured items. When procuring a manufactured item (such as a drill press), items of supporting documentation (such as operating and maintenance manuals and spare parts listings) are usually required. These items should be identified as part of your work requirement, both in this section and in the deliverables section.

• Training. Training courses should be documented by training plans, training outlines, handouts, and manuals. If you do not state a requirement for supporting documentation, the contractor is not required to provide it.

• Computer software. A requirement for the development of computer software should specifically identify the supporting documentation required. This includes such items as user’s manuals, programmer’s guide for code, diagnostic and error documentation, and applicable test plans. If these items cannot be specifically identified initially, the specific types of documentation that will be required should be identified, and the SOW should specify a point in time when such decisions will be made.

5. Describe Pertinent Previous Efforts

Reference any previous effort that might be helpful in meeting the current requirement. This includes efforts with negative results that established that a particular solution or course of action will not work as well as efforts with positive results. This information is similar to, but not the same as, the information provided in the background section of the SOW. The information in the background section refers to the project as a whole. The information here refers to the particular task.

Identify the results of related research, studies, or other efforts that will contribute to the contractor’s understanding of the task requirement. The contractor must understand the project relationships and related research to plan and perform the task requirements properly. For example, previous effort would be pertinent if the task is a continuation of previous effort or is based on previous studies or similar effort.

6. Describe Known Risks

Describe the uncertainties related to contract performance when the effort goes beyond the state-of-the-art, requires use of new or untried techniques, or successful performance otherwise bears a significant risk. Ensure that task descriptions clearly identify technical, design, or other problems anticipated during contract performance. For example, in a requirement for the development of ink used in printing currency, the known problems related to such development (such as the chemical composition and hazardous materials) were identified to ensure that prospective contractors understood the risks involved. Identify the risks involved and use the proposal preparation instructions to require contractors to discuss how they would resolve such problems.

In particular, describe problems that were not resolved in previous contracts of a similar nature. Do not conceal knowledge of previous problems; to do so is to invite a repetition of such problems.

7. Ensure That Descriptions Are Consistent

Ensure that the descriptions are consistent and use the same terminology throughout. Calling a requirement a report in one task and later referring to it as a study can cause confusion and lead the contractor to believe that these are different requirements. Do not make up your own terminology; this will confuse the contractors and those who review your work. Use commonly understood terms, events, and documents. If it is necessary to use a number of project management terms and government acronyms, consider producing a tailored glossary to be attached to your SOW.

8. Use the Proposal Preparation Instructions

In some instances, the requirement itself is so complex or innovative that you cannot define it fully. If this is the case, describe the requirement as clearly as possible in the initial SOW and use the proposal preparation instructions to require the contractor to provide the performance details. The details in the successful proposal can then, if appropriate, be incorporated into the SOW prior to award.

Even if the requirement cannot be fully described, do not leave the contractor free to pursue its own approach unchecked. Require the use of control processes, such as design or milestone reviews, to oversee the contractor’s actions whenever a choice or decision must be left to the contractor’s discretion.

9. Describe the Tasks in Sequence

Whenever possible, describe the tasks in the sequence in which they occur. Ensure that the descriptions flow in an orderly manner, both within the task and from one task to another. This makes it easier for both the contractor and the government to understand and monitor the flow of work.

Be careful about the use of a concurrent effort that requires the contractor to perform multiple tasks at the same time. Concurrent effort is difficult to manage effectively and leads to inter-dependency, in which a technical problem in one effort adversely affects the other effort.

For example, as part of your requirement, the contractor must develop and build two instruments. These instruments have different functions but must be compatible. You can direct the contractor to develop and test one of the instruments and then the other, using the specifications of the first instrument to ensure the compatibility of the second. This is a safe approach, but it takes time. Your other choice is to direct the contractor to develop and build the instruments concurrently. This approach is faster, but there is a risk that once built, the instruments will not be compatible because of unanticipated technical problems. Lack of compatibility often cannot be detected until the instruments are tested together.

When project needs dictate the use of concurrent effort, ensure that each task references the other effort and, as appropriate, explains the interrelationships. Consider using planning software to help develop the task assignments and monitor concurrent effort during contract performance.

10. Describe Project Phasing

Complex projects are often divided into phases, such as a study phase, design phase, prototype phase, etc., so that the overall project can be managed more effectively. Government approval is usually required to move from one phase to the next. This government oversight provides greater control over the progress of the project than would otherwise be the case. The price you pay for the greater control is the added time for the government review and approval process.

If the requirement is divided into phases, describe the required phasing of the effort so that the interrelationship of the phases is clearly defined (that is, so that each phase clarifies and defines the remaining phases). Each phase may contain a single task or multiple tasks. Describe the tasks and the phases in the sequence in which they occur. Identify the specific requirements of each phase. Describe how the contractor obtains approval to continue from one phase to another. For example, a phase may end with a specific milestone or a specific event such as a design review; government approval of the completion of the phase signals the start of the next phase. When government approval is required, describe the review and approval process and the time allotted for the review and the resulting revision process.

Describe the Contract Management Requirements

In addition to describing your technical requirements, the SOW must describe the contract management requirements, such as reports and other management control systems that you require the contractor to maintain. Management reports (e.g., progress reports) provide information necessary for you to manage and monitor contract performance. Management control systems, such as a computer-based schedule planner and manager or a quality assurance program, are systems run by the contractor. These systems provide project visibility and help ensure conformance to contract requirements.

When describing management reporting requirements, it is important to describe the purpose of the report required, the specific areas to be addressed, and the frequency of submission. Do not over specify your requirements; permit the contractors to use their own existing reporting systems as long as they will yield the required information. Describe what the reports are to accomplish in the initial SOW and use the proposal preparation instructions to require each contractor to fill in the details. Negotiate the details and incorporate the contractor’s proposed reporting system into the final SOW before award.

Minimize your information requirements. Do not require any information that you are not going to read and act upon when it is received. Report preparation is expensive and time-consuming. Asking for information that is “nice to have” clutters up the reports and adds unnecessary costs.

Specify reporting formats in the initial SOW only when a particular format is necessary for project purposes. For example, if you manage the project using a particular computer-based schedule planner and manager, you will need a report from the contractor in a format that facilitates the input of the data to your system. As an alternative, you may want to require the contractor to manage its work using the same software. In most instances, however, it is best simply to identify your information requirements and let the contractor use its own format.

Do not require the submission of frequent written reports. Assess the frequency of reporting on the basis of the complexity of the work and how you plan to manage the contract. Normally, reports submitted more frequently than monthly are a waste of time and money because they cannot be read and acted upon effectively. In addition, frequent reporting diverts the contractor’s time and energy from productive effort. If you must monitor contract performance closely, use telephone calls, impromptu meetings, and site visits instead of frequent written reports.

To ensure the timeliness of the information reported, establish reporting periods that are realistic. Use the proposal preparation instructions to require the contractor to indicate how it prepares its reports and how long it takes. Contractors, like the government, have their own bureaucracy, and written reports are not generated overnight. For example, a contractor’s accounting system may produce its reports on the tenth of each month, with data effective as of the first of the month, and it takes four days to develop and submit its report to the government. If you require your report on the first of each month, the most current financial data will not be available.

Take the time to find out how the contractor generates its reports and adjust the reporting periods in the final SOW accordingly. There will always be a lag in the timeliness of the information provided, but if you know what the time lag is, you can minimize its impact.

At a minimum, require the contractor to report on the progress of the contract. Progress reports are used to monitor the contractor’s technical progress toward completion of the contract. Require the contractor to address the status of the work (usually in terms of milestones, percentage of completion, or some other measure that is mutually understood), problems encountered and their solutions, progress predictions (including potential problems and possible solutions), and the contractor’s plans for the next reporting period. Progress reports are generally submitted in letter form.

Progress reports may also be used to monitor the status of contractual expenditures (i.e., financial progress), but only in cost-reimbursement, time-and-materials, and labor-hour contracts. Financial progress reports usually include the costs incurred during the reporting period by cost element or labor category, the cumulative costs incurred for the contract to date, and the funds remaining on the contract. When financial progress reports are required, they are usually made a part of the technical progress report.

Avoid asking the contractor to report anticipatory costs—costs expected to be incurred during the next reporting period. The use of anticipatory costs can cause problems when actual costs vary from the estimated costs. Concern about the difference between actual and estimated costs diverts attention from the technical problem causing the cost variance. In most instances, resolving the technical problem is much more important than worrying about the contractor’s estimating ability. If it is necessary to track anticipatory costs, require the contractor to report any significant expenditures anticipated rather than the total anticipated costs.

Require the use of specific management control systems, such as cost/schedule control system criteria (C/SCSC), as used by DoD, or a computer-based schedule planner and manager, but only when necessary for project purposes. If you require the use of a specific system and the contractor does not already use that system, you will incur added costs—the contractor’s costs for training and maintenance of a new system as well as the costs and problems associated with integrating a new system into its existing management system. Balance the value of the use of the specified system against the added costs.

Balancing the value is particularly important with respect to progress and financial information because you will require the contractor to manage and maintain two sets of books—one set in the format of the contractor’s existing management system, and the other using the same information but in your specified format. Such duplication can create problems during contract performance.

Use the proposal preparation instructions to find out how the contractor proposes to manage the contract. To the extent possible, use the contractor’s existing management systems as long as they will yield the required information and provide the required level of management control.

Identify Government Responsibilities and Interfaces with Third Parties

The primary purpose of the SOW is to describe your requirements clearly and establish the contractor’s responsibilities in contract performance. However, the government’s responsibilities must also be described, including responsibility for such activities as government reviews and approvals, government-conducted testing, and any other actions taken by government personnel that are directly related to the contractor’s performance. Address these responsibilities as part of the related task description rather than as a separate subject in another part of the SOW.

There are other government responsibilities that are not directly related to the contractor’s performance, such as government-furnished property and key personnel requirements. These are addressed in the “other considerations” section of the SOW.

When describing government responsibilities that affect contract performance, it is important to indicate their impact on the schedule. For example, when reviews and approvals are required, indicate how long it will take to conduct the review and provide the approvals or comments. Also describe the contractor’s actions upon completion of the review and approval process, such as correction and re-submittal. Be sure to allow sufficient time for both government and contractor actions.

Describe any known interfaces among the government, the contractor, and third parties. Interfaces are instances when third-party actions will affect contract performance, such as when a third party will develop hardware, software, or information needed by the contractor to continue performance. If the third-party action is not completed on time, the contractor’s performance will be adversely affected.

Identify the respective interface responsibilities and, if known, the timing involved. If you know that an interface will occur but you cannot describe the details, provide as much information as possible, even if it is only the fact that there will be an interface. Indicate, if possible, how and when the interface will be fully defined. Interface actions require planning and coordination; putting even minimal interface information in the SOW helps focus both contractor and government management attention on this requirement.

Provide for Performance Schedules

Avoid establishing fixed performance schedules or milestones in the initial SOW, except when project needs dictate performance by specified dates. A fixed schedule in the initial SOW inhibits the contractor’s ability to plan its proposed effort. Establish only an overall schedule. Use the proposal preparation instructions to require the contractor to define the milestones or specific work schedule (i.e., a critical path schedule) in its proposal. Negotiating the schedule and milestone details generally results in a more workable plan. Once agreement is reached, incorporate the plan in the SOW.

If for some reason it is not feasible to finalize performance schedules or milestones before award, require the delivery of such a schedule shortly after award. This could happen, for example, when a study or an analytic effort is required before the remaining effort can be defined sufficiently to establish a schedule. At a minimum, the schedule should identify the contractor’s key activities or milestones and provide a time frame (schedule) for attainment. Provide time for the review and approval of the schedule and for its periodic review and update.

The final SOW may contain two schedules: a performance schedule (related to the performance progress) in the technical requirements section and a delivery schedule (related to the delivery of specified products) in the deliverables section. A performance schedule is not always necessary; a delivery schedule is always required.

Consider Using Work Plans
Consider putting a work plan in your final SOW, but not in the initial SOW. A work plan identifies the key work elements and provides a schedule that demonstrates how the work will be accomplished within the project time frame. The work plan may also address the methodology to be used and how known problems will be resolved. Work plans are most appropriate for studies, analytic efforts, and R&D but can be used effectively in other efforts as well.

In many instances, as part of your procurement planning, you will have developed a work plan to demonstrate to your management that the project is feasible. This is your concept of how the work should be done. It is the contractor, however, who must perform the work, and the contractor’s concept may differ from yours.

The most effective work plans usually result from negotiations. Directing the use of a particular work plan in the initial SOW inhibits the contractor’s flexibility and use of innovative techniques. Generally, the initial SOW is silent on the subject of work plans. You may use a task description to identify specific analytic techniques or methodologies that you do (or do not) want used. However, do this only when the use or non-use of a specific analytic technique or methodology is necessary to achieve desired results.

Use the proposal preparation instructions to require the contractor to propose a work plan. This gets the contractor involved and generally leads to a more workable plan. Negotiate the details and incorporate that part of the contractor’s proposal in the final SOW before award.

If at all possible, do not make the development of a work plan and methodology the first task in the SOW. It is important to ensure agreement on the work plan, schedule, and methodology before contract award. Otherwise you will have to resolve any disagreements on government time and at government expense. Do not pay for something under the contract that can be obtained for less cost during the solicitation process.

In some circumstances, the work plan, schedule, and methodology must be developed during contract performance (as in a complicated R&D project), but this is the exception rather than the rule. In such instances, the development of the work plan is usually set forth as a separate task in the SOW, with the work plan as the deliverable item.

Provide for a Final Report

Many contracts require the submission of a final report. Describe the subjects to be addressed in the final report. Make the description specific enough to ensure that all the topics of interest are addressed, but leave room for creativity on the part of the contractor. Use a general description rather than a detailed description. Formats for final reports vary, but the following subjects are usually addressed:

• Executive Summary. An executive summary highlights the salient features of the final report. Use an executive summary only when it adds value to the report, such as facilitating upper management review. An executive summary is usually used for long, complex reports. If the report is short and simple, require an introduction instead. Consider limiting the executive summary to relatively few pages.

• Background. The background relates the history of the contract performance, including any modifications. When appropriate, as in R&D, it also traces the progress of the research that led to successful contract completion, summarizing the work performed, problems encountered, and solutions developed.

• Scope. The scope describes the extent of the effort expended. Require a scope paragraph that cites the size or extent of the technical effort in terms of the technical effort covered, not the work effort expended (i.e., what was accomplished, not how many hours it took to do the work).

• Work Performed and Results. Require a detailed description of the work performed, including both the positive and negative results of the work.

• Problems Encountered and Resolutions. Require a discussion of the technical problems encountered during contract performance and how they were resolved. If the problems were not resolved, require an explanation and a discussion of the impact of the unresolved problem on the project.

• Future Direction. When appropriate, require recommendations regarding follow-on effort or the direction of future research. This is usually used only when the contractor will clearly be in a sole-source position for any future effort resulting from the contract.

You do not want to be surprised by the structure and content of the final report. Require the submission of a draft final report for your review and approval. This helps ensure that the final report will contain the information required. Allow sufficient time for review and approval of the draft as well as its final correction and revision before the required delivery date of the final report.

Assess the review requirement objectively. Consider how many people will be involved in the review and how much time will be required to get responses from all the reviewers. Consider the nature of the report (complexity, length, etc.) and the nature of the comments likely to be received from the reviewers. Consider whether a review of the revised report will be required (e.g., if numerous reviewer comments are anticipated). Be realistic in your assessment and adjust the overall project schedule accordingly.

These guidelines also apply to interim deliverables. Any document submitted by the contractor should first be submitted and reviewed in draft form.

Describe the Contract Work Products

Describe all work products, including those produced during contract performance rather than at the end of it. Work products are deliverable evidence of compliance with SOW requirements. The contractor is required to deliver only those work products explicitly described as such in the SOW.

All interim and end products for each task should be identified as part of the task description. An interim product is anything, other than the end product, that is physically delivered during contract performance, such as draft documents, interim reports, designs, and test results. A deliverable that signals the completion of a task or milestone event is usually an interim product. An end product is the deliverable that signifies contract completion.

For R&D efforts, interim products include such things as designs, reports, or breadboard models, usually delivered in conjunction with the attainment of a contract milestone. The end product is a final report, a prototype, or an operating item, depending on the purpose of the contract.

For studies and analytic efforts, interim products are usually draft copies of the final report but may also be separate reports that demonstrate progress or completion of a part of the overall project. The end product is normally a final report.

For IT software efforts, interim products range from interim documentation to software packages that demonstrate only a part of the overall system. The end products are the operating software and the supporting documentation.

For general services efforts, such as janitorial services or transportation services, the services are provided on a daily basis. It is usually not possible to define a specific deliverable in such instances.

For technical support services, which are usually ordered on a work order or task order basis, the deliverables are defined in each order rather than in the basic contract.

The purpose of describing the contract work products is to relate the technical effort to the desired results. The physical characteristics of the interim and end products are described in the deliverables section of the SOW.

Describe Any Special Considerations That Apply

Special considerations, in this context, are those details that uniquely characterize your requirement and can make the difference between a successful and an unsuccessful contract. The following discusses how special considerations might be addressed in different kinds of acquisitions.

Studies and Research Efforts—Consider stating study or research requirements as a series of questions to be answered or areas of interest to be addressed. In most cases the purpose of the study or research effort is to answer questions or develop information about specific areas of interest. If your SOW is generalized or otherwise incomplete in this respect, the contractor must use its own discretion in setting the direction of the work. If the contractor does not view the requirement as you do and goes off on a tangent, you may not achieve your contract goal.

Establishing the questions or areas of interest in the SOW sets the direction of the work effort and helps keep the contractor within the boundaries of the requirement. It also establishes a quality standard for your use in assessing the contractor’s compliance with the SOW requirements.

For example, if your requirement is to conduct a study to determine the feasibility of relocating certain field offices to another location for purposes of consolidation, what questions must be answered? The following are just a few of the possible questions:

• Are adequate facilities available at the new location?

• How much will the move cost?

• How much will the move save, both in dollars and efficiency?

• What are the economic implications of the move for both the areas where the offices were and the area of relocation?

• How many employees will be affected by the move?

• How will the move affect current employees?

• How many employees are likely to move to the new location?

• Can the employees who do not move be placed elsewhere in the federal government?

• What programs can be established to obtain employment retraining for those employees who do not move?

• Are qualified personnel available at the new location to replace those who do not move?

• What is the cost of living at the new location? Is this likely to affect how many employees will move?

• Is housing available at the new location? What are the housing costs? Will this affect the number of employees who will move?

These are only some of the questions that must be answered to determine if a move is feasible. If these and other questions are not stated in the SOW, the contractor may consider other questions more important and not provide the results you anticipate.

If you cannot identify the questions or areas in the initial SOW, you can use the proposal preparation instructions to require the contractor to propose them. You should negotiate the details, making sure that you and the contractor understand the direction and emphasis of the contractual effort, and incorporate the questions or areas of interest into the SOW before award. Ensure that the final SOW clearly establishes the direction of the contractual effort.

Data Collection—Collecting data is often the first step in a study, analytic, or R&D effort. It is important to address data collection in the SOW because, unless you clearly define this step, it can go on forever.

You should first identify the kinds of data to be collected, such as technical or scientific data about a specific subject, or economic data about a specific product, industry, or country. Then identify the data sources, such as technical and scientific journals, trade publications, newspapers, periodicals, or interviews with certain people or types of people. You will also need to indicate who will provide or obtain the data (government, contractor, or both).

If the government will provide all or part of the data, the SOW must describe when the data will be provided and its form. Be definitive; it is not appropriate simply to indicate that “pertinent data” will be provided or that the data will be provided “as necessary.” Specific identification of each data item is not necessary, but you must describe the types or categories of data to be provided and when.

The form of the data is also important (e.g., hardcopy, digital media) because the data may have to be manipulated before it is usable. For example, if your data is in hardcopy, some printed and some handwritten, the contractor may have to convert the data to digital media to make it usable.

If the contractor will be responsible for data collection, the SOW must provide some means to control the extent of the data collection effort. Data collection is a time-consuming and expensive task if not controlled properly because it is often difficult to determine when enough data has been collected. You can control this effort somewhat by specifying the kinds of data to be collected and restricting the sources to be used, but doing so inhibits the contractor’s use of innovative approaches. You can also restrict the amount of time allotted for data collection, but this not only inhibits the contractor’s approach but also presupposes that you know the optimum amount of time required for this effort.

The contractor exercises primary control over the amount of time spent for data collection. Accordingly, the contractor should be involved in this determination. Use the proposal preparation instructions to require the contractor to provide details of its proposed data collection effort. At a minimum, require the contractor to describe how the data will be collected, the sources to be used, and the schedule of the data collection effort.

The data collection details should be negotiated and that part of the contractor’s proposal should be incorporated into the final SOW. This makes the details of the data collection effort a part of the contractual requirement. The contractor is more likely to comply with a plan it developed than one arbitrarily mandated by the government.

If data collection is the initial step in the work requirement, it must be defined in the SOW before contract award. When the government provides the data, the data collection requirement is usually defined in the initial SOW. When the contractor is responsible for data collection, the effort is usually defined in the final SOW by incorporating the contractor’s proposed data collection process. In some instances the data collection effort cannot be defined at all, because it will occur later in contract performance and is dependent on the results of the initial work efforts. If so, the SOW should provide a requirement for the definition of the data collection effort before it starts.

IT Systems and Software—Many projects involve developing IT systems or software. Before initiating a contract for developing a new IT system or new software, consider what other options are available. These include incrementally improving all or part of the existing system or software or purchasing commercial off-the-shelf systems or software. Making incremental improvements takes longer but reduces risks. Using commercially available systems or software also reduces risks but may generate integration problems when used with existing systems.

Engineering a completely new product should be a last resort. If a new product is the only way to meet your requirement, initiate your planning well in advance of your need for the product. In addition to the usual planning and procurement lead time, be sure to allow sufficient time for acceptance testing, training, and debugging or fine-tuning the end product.

When developing an SOW, particularly for IT systems or software, you are not expected to do everything yourself. Ensure that you have sufficient resources available to define the procurement objective and technical specifications. Sufficient resources and facilities should also be available to manage and support the contractor’s activities and to review and critique the contractor’s interim and end products.

It is often helpful to check with others who have had the same or similar problems. Find out what they have done and request assistance from those who have appropriate expertise. As a last resort, hire a contractor to assist in the planning and SOW development. Be careful, however, when using contractor assistance: a contractor who helps develop the SOW must be precluded from competing for the actual requirement.

Both management and users should be involved in acquisition planning, SOW development, evaluation of technical proposals, and monitoring and review of contractor efforts. User involvement is particularly important. Ensure that the user understands and concurs with the requirements of the SOW and participates in proposal evaluation and the testing and acceptance of the end product. The user is your customer; if the end product does not meet the user’s requirements, your project will not meet its goals.

Describe IT system or software requirements clearly and in detail, including the applications area and the specific need and function the system or the software is to satisfy. You should focus on your objectives and the end product, using functional terms when possible. Define the standards to be used, and cite the applicable federal standards (unless they are clearly not applicable).

When the requirement involves the development of software, describe the operating environment (i.e., the hardware and software, such as operating systems, database management systems, and utility software) to the extent possible. Describe how files are to be prepared, including sufficient detail to preclude delivery of files that cannot be used. The level of the operating system, the release level of commercial software for data files, the target machine, and other equipment on which the software is to work or be compatible with should also be described. Specifically identify the supporting deliverables associated with the software deliverable, such as user documentation, programmer’s guide for code, appropriate diagnostic and error documentation, and applicable test plans and criteria.

If your project is not structured as a formal project with the checks and balances of formal systems acquisition, you must provide for ongoing review of the technical effort. Describe the review requirements as part of the appropriate task effort. Review requirements include providing for periodic reviews of the estimates for hardware capacity and reviewing the planned use of software development tools, database management systems, and other technical resources. System conformance to security, privacy, and internal controls should be assessed periodically, and end products should be reviewed for appropriateness, technical integrity, and conformance standards.

Quality control at the point of acceptance is the key to ensuring product conformance. Ensure that the delivered product does not contain hidden additional costs in the form of high maintenance costs caused by errors in logic or deviations from standards. To ensure quality, you must provide a clear definition of the expected quality, usually in terms of what the system or software is to do or accomplish in the operating environment.

Define the methodology (acceptance criteria) for measuring compliance for both interim and end products. If the effort is divided into phases, define the acceptance criteria for each phase. Conduct comprehensive testing of interim and end products, preferably by the actual users. Use testing procedures that clearly demonstrate that the products produce exactly the required results in a real-world operating environment. Ensure that interim and end products are prepared according to the required standards (to ensure maintainability) and that the effort is fully documented. Establish a period of time during which the contractor is required to maintain the system or software and correct any latent defects.

Commercial Items—The FAR¹ states that, to the maximum extent practicable, SOWs should be written in terms that enable contractors to supply commercial items or nondevelopmental items in response to agency solicitations. The FAR goes on to say that prime contractors and subcontractors at all tiers should be required to incorporate commercial or nondevelopmental items as components of items to be supplied to the agency. The FAR² indicates that this policy includes, as appropriate, the modification of current requirements to ensure that the requirements can be met by commercial or nondevelopmental items.

A commercial item is a product or service customarily sold in the commercial marketplace but that can be used for government purposes as is or with minor modifications. This includes items under development that are not currently available in the commercial marketplace but will be available in time to satisfy current delivery requirements.

A nondevelopmental item is a previously developed item of supply used exclusively for government purposes by federal, state, or local governments that can be used as is or with minor modifications. This includes items being produced that are not yet in use.

When acquiring commercial items or services or nondevelopmental items, the SOW description of the requirement must contain sufficient detail for potential contractors to know which commercial items or services may be suitable. The SOW should describe the type of product or services required and explain their intended use in terms of the functions to be performed, the performance requirements, or the physical characteristics.

When acquiring commercial services, it is important to focus on the specific services the contractor is expected to perform. Provide sufficient detail to ensure that the contractor will understand and be able to price the extent of the services required. If you are not sure how to describe a commercial-type service, check to see how the same or similar services were described in past contracts. Be careful, however, never to use the language of a previous SOW without first finding out how well it worked in practice. You do not want to repeat someone else’s mistakes.

You should also conduct market research on commercial services to determine whether there are published industry procedures or standards that establish how the services are performed in the commercial marketplace. For example, for grounds keeping services, there are established standards as to how grass is to be cut and sidewalks edged; for janitorial services, there are established standards for how rooms are to be cleaned. Referencing such procedures or standards in the SOW will help minimize the length of the SOW and avoid the problem of having your requirements at variance with how such work is normally performed. Keep in mind that the people actually doing the work will not have seen the SOW and generally will perform your work in the same way that they perform the same work for other customers.

Commercial products are generally described in terms of the salient physical or performance characteristics of the product required. The primary source of such information is brochures or other descriptive literature published by manufacturers or dealers, which can be obtained during market research.

The characteristics of commercial products are often described in a manner that only the manufacturer can meet. Be careful that you do not inadvertently create a restrictive requirement by copying directly from commercial literature. Examine commercial literature objectively and select only those characteristics that are necessary to ensure that the product will meet your needs and that can be met by more than one manufacturer.

Manufactured Products—A functional description of a requirement for a manufactured product must concentrate on the physical characteristics and functions that describe what the end product will do or how it will operate. When describing numerical requirements (e.g., height, weight, dimensions), use ranges or minimums and maximums rather than specific numbers (except as necessary to meet project requirements) to avoid creating a restrictive description. Using restrictive descriptions and excess requirements may lead to protests from unsuccessful contractors. Only your minimum requirements should be described; do not ask for anything that cannot be justified as an actual requirement. When describing a requirement for manufactured items, you should consider the following:

• Power. What are the power requirements? This includes such things as input power to run the equipment and output power in terms of production.

• Capacity. What kind of load must the equipment handle? This could range from production capacity (as in IT equipment) to lifting capacity (as in a forklift).

• Accuracy. What accuracy level is required? This could range from error rates to the accuracy of measurements.

• Reliability. What reliability level is required? This includes mean-time-between-failures, failure rates, and repair rates.

• Physical Restrictions. What restrictions or physical characteristics apply? This includes an item’s size, dimensions, weight, and configuration.

• Ruggedness. What operational environment considerations apply? This could range from an item’s ruggedness (ability to withstand vibration or shock) to its ability to operate under extreme conditions (heat, cold, moist, dry, or saltwater).

• Environment. Must the equipment meet, or be protected from, environmental or health and safety constraints? These include devices to protect operators and the public from hazards produced by or used with the item, such as hazardous materials, electromagnetic radiation, toxic products, and other pollutants. They also include requirements to protect the item from damage from such hazards.

• Materials. Are special materials required? This usually applies only when project needs dictate the use of special materials, such as particular chemicals or a special grade of steel or other construction materials.

• Interchangeability. Are there interchangeability requirements? These address the ability to interchange parts or components within the item or between the item and other specified items.

• Compatibility. Are there compatibility requirements? These address the need for the item to operate in conjunction with other items; for example, pieces of equipment operating in tandem must be able to plug into each other. Compatibility also addresses the ability of the item to fit in with other items, such as a requirement that a replacement laboratory table be the same height as the adjoining table.

• Transportation and Storage. Are there special requirements related to transportation and storage? These include any special characteristics that must be built into the item, such as hooks and handles, and requirements for skids or pallets.

• Installation. Are there special installation requirements? These could range from a need for a crane to lift an item to the third floor of a building, to a need to construct special foundations for the item where it is to be placed.

Some of these items are performance (functional) requirements and some are design requirements. Most product descriptions are a combination of functional and design requirements. In addition, many agencies have directives that place specific requirements on the procurement of manufactured products. These must also be considered when describing your work requirement.

Formal Technical Meetings—Include any requirements for formal technical meetings to be held after contract award as part of the applicable task description. These are meetings at which technical progress and technical problems, rather than administrative matters, will be discussed. Such meetings are usually conducted in conjunction with a specific task or milestone set forth in the SOW, such as preliminary design reviews and critical design reviews. The contractor needs information about such meetings to plan and price its proposal; both parties need the information to manage and monitor contract performance.

If the meeting is to be conducted at a government facility, the SOW must describe the purpose of the meeting, when and where it will be held, who will conduct the meeting, and the anticipated duration. Indicate the number of participants and, when appropriate, the classification level and access procedures. If the contractor will make a presentation, the SOW must describe any documentation requirements, such as handouts or briefing papers. It should also indicate what equipment, such as audiovisual equipment, whiteboards, and overhead projectors, will be available for the contractor’s use.

If the meeting or briefing is to be held at the contractor’s facility, describe its purpose, when it will be held, the number of government participants, any documentation requirements, and, as appropriate, the classification level. Use the proposal preparation instructions to require the contractor to discuss any other details deemed necessary.

If you feel that formal technical meetings are necessary but do not want to dictate the details, you can also use the proposal preparation instructions to require the contractor to propose the details. Indicate the requirement for the meeting and its purpose in the initial SOW. Negotiate the details proposed by the contractor in its proposal and incorporate the results in the final SOW.

Incorporation of Other Documents—You may incorporate the requirements of other documents into the SOW when necessary to describe the work requirements completely. Documents that may be incorporated include government documents or publications; federal, military, or commercial specifications or standards; and documents published by other agencies or commercial concerns.

For example, an SOW required compliance with the National Electric Code (NEC) in a construction contract, stating that junction boxes shall be provided as indicated on the drawings and where required by the NEC. The contractor submitted a claim for additional work for the installation of a particular junction box, claiming that the drawings did not indicate a junction box at that location. The contractor lost because, based on how the contractor performed the work, the NEC required installation of the junction box.

In this instance the drawings did not show the junction box requirement, but the contractor was required to perform as specified by both the drawings and the NEC. If the SOW had not made reference to the NEC, the government might have had to bear the extra cost.

You must exercise care when incorporating the requirements of other documents in your SOW. If you simply cite the title of the document, you are making the entire document a part of your work requirement. Other documents, such as formal specifications and standards, often include coverage that may not be applicable to your requirement or may even be contrary to what you want, particularly if the document has not been revised in some time. Revisions to published documents rarely keep up with technological changes.

Each document should be reviewed carefully and tailored to your requirement, incorporating only those parts pertinent to your requirement in the SOW. For example, if you want the work performed in accordance with Chapter 4 of XYZ standard, but the rest of the standard does not apply, you should state in the SOW that the work is to be performed in accordance with Chapter 4 of the XYZ standard; do not cite the entire standard. Tailoring must be specific, down to the sentence level, if necessary. Ensure that all documents incorporated as part of the work requirements are also listed in the applicable documents section of the SOW and that the listing reflects the tailoring of the documents.

Technical Data Requirements—Technical data is recorded information of a scientific or technical nature other than computer software and administrative data, such as financial and management reports. Technical data requirements, such as reports, usually result from the completion of a task or attainment of a milestone and should be described as such.

Describe the format and content of the technical data requirements for each task as part of the task description. The physical characteristics of the technical data, such as the number of copies and the media, however, should be described in the deliverables section of the SOW.

Require delivery only of technical data that you intend to use. The preparation of technical data for delivery is expensive and time-consuming. Excessive data requirements (including nice-to-have rather than need-to-have data requirements) increase contract costs without adding significant value to the results.

One way to avoid over-specification is to describe in the SOW what technical data is required and why, and then in the proposal preparation instructions require the contractor to propose the specific data to be provided and its format. Negotiate the details and incorporate the results into the SOW before award.

Some agencies use the Contract Data Requirements List (CDRL), DD Form 1423, to order data and prepare the Data Item Description (DID), in plain paper format, as shown in MIL-STD-963B, to describe data. If your agency uses these forms, you should not describe the data and data delivery requirements in the text of the SOW. Instead, make reference to the forms in the SOW and use the forms to describe the details. When using these forms, make sure that you double-check the details on the forms with the text of the final SOW and any related documents, particularly with respect to delivery times.

Describe the Criteria for Determining Whether Requirements Are Met

Each task, as well as the contract as a whole, must have a product or an event that demonstrates successful completion. You must, therefore, develop a way to measure contractor achievement and determine if the contractor’s performance is successful, at both the task and contract level. This is done by establishing quality requirements in the SOW and, when appropriate, testing to ensure that the requirements are met.

Quality Requirements in Functional SOWs—To describe quality requirements in a functional SOW, you must determine the attributes of contract performance and how these attributes can be measured. Quality attributes are the characteristics or features of contract performance that signify successful performance.

Indicate how the attributes are to be measured by describing how satisfactory quality will be determined. Describing quality requirements helps ensure that the end product is usable and establishes a standard for measurement of the contractor’s performance. When appropriate, you should describe how products will be tested or demonstrated to verify compliance with technical requirements.

When buying standard commercial items, describe quality attributes in terms of the essential physical and functional characteristics of the required items. Use criteria such as the kinds of material, dimensions, size, capacity, principle of operation, restrictive environmental conditions, essential operating conditions, and other pertinent information that further describes the item required. Use attributes that can be measured through inspection or testing of the end product.

When buying technical hardware such as electronic or scientific equipment, describe quality attributes in terms of the performance or configuration of the end product. Use criteria such as weight, dimensions, power, speed, accuracy, processing rate, error rate, ease of operation, or other measurements that indicate the contractor’s degree of success. Use attributes that can be measured through inspection or testing of the end product.

When buying studies or analytic efforts, describe quality attributes that indicate the contractor has successfully met the goals of the contract. Use attributes such as how well specified questions or areas of interest are addressed, how well results are documented or otherwise substantiated, and whether appropriate emphasis is provided. Describe these attributes as part of task performance; this helps relate the quality requirements to the performance requirements. These attributes can be measured by inspecting the end product.

When buying support services (these can range from janitorial services to technical support services), describe quality attributes in terms of the adequacy of the services provided. Use attributes such as responsiveness, on-time performance, the amount of service provided, the rate of rework required, or some other term related to the quality of the services performed.

You need to be careful not to overspecify quality attributes—doing so may interfere with contract performance by setting unrealistic goals that inhibit the contractor’s flexibility in managing its own effort. A common example is when the SOW requires unrealistic response times, such as “the contractor must provide the technical support within thirty minutes of notification….” This response time might be appropriate for emergency services, but not for normal technical support. Ask yourself how long it would take the government to respond in a similar situation. Keep in mind that you will have to pay for any unusual requirements; be sure that they will be worth the extra cost.

Determining quality attributes for technical support services is particularly difficult because it is often hard to pinpoint a particular feature of contract performance that signals successful performance. In many instances performance of the work is the only deliverable, and it is provided on a daily basis. It may be better to generalize the quality attributes in the SOW and to rely on the monitoring of contract performance to control performance quality. This decision must be made on a case-by-case basis.

Establishing quality attributes is also difficult when buying R&D efforts because it is often not possible to specify the end product. It is hard to establish a quality level for a product you are not sure can even be made. R&D encompasses a wide range of efforts, including elements of any of the situations described above. Quality requirements are often established as the project progresses through the R&D process, using project management techniques such as design and milestone reviews. If your contract is for an R&D project, use the project management approach to control your quality requirements. If your contract is in support of a project, use the techniques discussed.

The quality attributes discussed relate to the condition of the end product and should not be confused with quality assurance (QA) programs such as ISO 9000, 9002, or 9003 or a contractor’s internally developed QA program. Contractor QA programs are concerned with developing or maintaining quality work during contract performance and are designed to ensure that required quality attributes are met. Generally, the government relies on the contractor’s QA program, but you may direct the use of a particular QA program in your SOW when necessary.

Quality Requirements in Performance-Based Service Contracting SOWs—The process of developing quality requirements for the performance work statement (PWS) used in performance-based service contracting (PBSC) is more exacting than that needed for the development of quality requirements for a functional SOW. A functional SOW for services usually describes the quality requirements in general terms and does not establish specific measurable performance standards. As noted in Chapter 3, however, the description of the quality requirements in a PWS requires that the expected work outputs be expressed in terms of objective, measurable performance standards. This requires a job analysis of each task and significant subtask to define the services in terms of the expected results, the development of performance indicators, performance standards, acceptable quality levels, and a quality assurance plan. This is significantly greater detail than that required for a functional SOW.

Testing Requirements—Testing must be addressed in the SOW if interim or end products will be tested to determine the contractor’s compliance with SOW requirements. How test requirements are described depends on the circumstances of your project. For example, in many R&D projects testing requirements cannot be established initially because the end product cannot be fully defined. In such instances, testing can only be described as a requirement to be defined during contract performance through the submission of a test plan by the contractor. However, there are instances in which you know what the end product should be able to do, such as in the development of software to perform a particular function. When this is the case, the final SOW must be more specific about the testing requirements.

When you can determine the testing requirements in advance, you should develop an objective method of verifying compliance with the SOW requirements. The contractor cannot be held to the SOW requirements if there is no method to verify compliance. If there are varying methods and you do not specify one, the contractor may make the selection. This is not always desirable. The most common methods of verification are modeling, technical analysis, demonstrations, and testing. When describing testing requirements, address the following (these also apply to the other methods of verification):

• Indicate who is to conduct the testing. Testing may be conducted by the government, the contractor, or a third party.

• State when the tests will be conducted. The timing of tests is usually described in terms of a milestone or other attainment within the task. Do not use calendar dates. Ensure that sufficient time is allowed. Include time for installation and setup, conducting the test, documenting and analyzing the test results, government review and approval, and any resulting contractor actions.

• Describe the test. At a minimum, indicate what the test is, how it is to be conducted, what the test is to accomplish (what you are testing for), and how the results are to be documented.

• Describe the form and condition necessary to make the test item ready for testing to ensure that the contractor’s item is delivered in a test-ready condition.

• Describe how the test results are to be documented and analyzed and describe the contractor’s action when the government review and approval process is completed, such as correction, revision, or replacement. Indicate the time frames for this process.

When the contractor will conduct the testing, it is usually a good idea to get contractor input before completing your testing approach. In the initial SOW, indicate that there is a test requirement, describe what the test is to accomplish, and specify how it is to be documented. Use the proposal preparation instructions to require the contractor to propose a test plan. Negotiate the details and incorporate that part of the contractor’s proposal in the final SOW before award.

Section B: Deliverables

The purpose of this section is to separate the description of the physical characteristics and the delivery schedule for interim and end products from the description of the technical requirements. This separation is necessary to avoid confusing work requirements with delivery requirements. The work requirements are described in the technical requirements section; the products of the work requirements and scheduled delivery are described in the deliverables section.

What Is a Deliverable?

A deliverable can be a prototype or other manufactured product, a design, a report, computer software, or anything else that can be physically delivered. This definition includes interim deliverables, such as reports, draft documents, interim findings, and test results and analyses, as well as end products. A deliverable usually signals the end of a task or the accomplishment of a milestone and is used to measure successful performance.

There are exceptions to the requirement that a deliverable be a physical item. The presentation of a formal training session, for example, is usually treated as a deliverable. Meetings, however, are not usually considered deliverables. Meetings can be described as deliverables when they signal completion of a task or the meeting of a milestone, but this is the exception rather than the rule. Most meetings are held in connection with a specific task and are described as part of the task rather than as a product of the task. A report that summarizes the results of the meeting is a deliverable item, but the meeting itself is not.

Describing Deliverables

Describe all deliverable items, the quantity (or number of copies), and the delivery time. Avoid using specific calendar dates, if possible. Express the delivery time in terms of a period of time after contract award or after a specific event, such as the completion of a task or attainment of a significant milestone. Ensure that each deliverable is identified with the associated task by specific cross-reference or by narrative discussion. Deliverables may include:

Manufactured Products—If the deliverable is a manufactured product, identify the item, the deliverable quantity, and when delivery is due. If testing is to be conducted upon delivery, reference the testing requirement and indicate that the item must be delivered in a test-ready condition.

Written Material—If the deliverable is written material, such as a report or a design, identify the item, the number of copies required, and when delivery is due. If your intention is to duplicate and further distribute the deliverable, indicate that a reproducible copy is required.

Digital Media—If the deliverable is on digital media (i.e., a compact disc, USB flash drive, or removal storage device that digital data can be stored on, hereafter referred to as a “disc”) containing a computer program or data (such as a report), you should pay particular attention to the description of the disc. The description must be sufficient to ensure that the information is usable upon receipt. For example, indicate the size and format of the disc and describe how the files are to be prepared and named. Describe the files in sufficient detail to preclude delivery of files that cannot be used. As appropriate, describe the version of the operating system, the release version of commercial software for data files, the type and model of machine, and other equipment with which the software is to be compatible.

If the deliverable is a disc that contains a software program rather than data (e.g., a report), consider requiring several copies of the disc. At least two working copies of each disc, plus an archive copy, should be delivered to ensure there is a usable backup if there are problems with one of the discs.

If the primary deliverable is a disc, indicate if a hardcopy is required and, if so, how many copies. At least one hardcopy is usually required when the disc contains information, such as a report. Hardcopies are not usually required when the disc contains a program.

Identify supporting deliverables separately. These include user documentation, programmer’s guide for code, appropriate diagnostic and error documentation, and applicable test plans and criteria associated with the software deliverable. Supporting deliverables may be delivered on disc(s), in hardcopy, or both, depending on what they contain and how they will be used.

Review your description of the IT operating environment in the technical requirements section of the SOW. That description should be repeated in this section, if necessary, to ensure the contractor understands what is required. In this instance, redundancy is a good thing and can help avoid future problems.

Packing, Packaging, and Marking Requirements

Do not overlook the packing, packaging, and marking requirements necessary to prevent deterioration and damage during shipping, handling, and storage. Items such as electronic equipment, IT equipment, and hazardous materials require special attention. Marking requirements are particularly important with respect to hazardous materials. Check for environmental constraints, such as sensitivity to heat, cold, or humidity, that will affect how the item is packed and shipped. If the item is going into storage after delivery, check to see if any special packing, packaging, or preservation requirements apply.

Most agencies have locally produced contract clauses to cover the typical packing, packaging, and marking requirements. The FAR does not address these issues to any great extent. Put your requirements in the initial SOW, and then consult with your contracting officer to determine if some of these issues are covered by local or FAR clauses. It will be easier for the contracting officer to provide the appropriate advice if your requirements are in writing.

SOW PART III: SUPPORTING INFORMATION

Part III of the SOW sets forth supporting information that applies to contract performance but does not fit anywhere else in the SOW format. Typically, these considerations are in support of, rather than part of, the work requirement. They include information related to security issues, the place and period of performance, government-furnished property or information, key personnel considerations, rights in technical data or computer software, or other contractual requirements unique to the specific procurement.

Section A: Security

Security issues must be considered in all contracts, even those that are unclassified, and early consideration of these issues is critical. Security issues can affect the timing of the procurement, particularly with respect to obtaining personnel and facilities clearances. Consider the time required to obtain personnel and facilities clearances in terms of the release of your SOW and timing of the initial contractual effort.

Security issues also affect the place of performance if classified work is required and the potential contractors do not have the appropriate clearances to perform classified work at their own facilities. If a number of the potential contractors do not have the appropriate facilities clearances and timeframes are short, you may have to consider having the classified work performed at a government facility.

If the contractor will use its own computers for classified work, you must determine the appropriate sanitization requirements for the contractor’s IT and word processing equipment. If contractor personnel will be using government computers, you must ensure that they have the necessary clearances to view any other information that might be on the computers they will be using. These requirements must be set forth in the SOW.

You will need to check with your security officer to determine if your requirement involves any security issues. You may have to explain the clearance processes in the SOW to ensure that the potential contractors understand these requirements.

Section B: Place of Performance

Contract performance may take place at the contractor’s facility, a government facility, a third party facility, or any combination thereof. While there are solicitation provisions that require the contractor to identify its specific place of performance, identifying the place of performance in the SOW helps make the SOW a complete document and also indicates the government’s preference in this matter.

Section C: Period of Performance

The period of performance is the term of the contract, i.e., how long the contract will be in effect, and not the length or scope of the work effort. Express the period of performance as a time period after award rather than a specific date. Use specific dates only if the dates are critical, such as when the contract is to expire at the end of a fiscal year.

The performance period is usually longer than the estimated scope of the effort. For example, a performance period of four to five months should be used when the scope of effort is estimated to be three work months. This is necessary to give the contractor some flexibility. It is not realistic to expect contractor personnel to devote 100 percent of their time to a single contract, particularly if the contractor is small. In addition, contractor personnel, like government personnel, have other demands on their time, such as corporate meetings, emergencies, training, and administrative responsibilities.

The term of performance must be compatible with the other time periods in the SOW. Check the contract term against the delivery times in the deliverables section, the estimated scope of effort in the scope section, and, when incorporated in the SOW, the contractor’s work plan. In addition, check to ensure that the period of performance is compatible with any contract clauses used in other parts of the contract.

Do not put the contractor’s back to the wall with contractual timing unless the timing is critical to project success. The typical result of tight schedules is lower quality because contractors cut corners to meet the schedule, or they deliver late. If the schedule is too tight, the contractor may do both. Contractors are well aware that the government rarely defaults a contract on the basis of late delivery. The period of performance must be realistic.

Section D: Government-Furnished Property

The identification of government-furnished property and when it will be furnished is usually addressed as supporting information. Government property clauses in the FAR describe the rights and obligations of the parties with respect to government-furnished property. The applicable clause depends on the type of contract used and is selected by the contracting officer for placement in Section I of the contract.

Government property clauses require that specific identification of the property and when it will be provided be set forth in the contract schedule or specifications. Government-furnished property is addressed in three places in the contract: (1) the fact that the government will furnish government property or data is part of the work requirement addressed in the technical requirements section of the SOW; (2) the supporting information (identification and delivery) is set forth in the supporting information section of the SOW; and (3) the related clauses are set forth in either Section F or Section I of the contract. If a significant amount of property is involved, the property should be listed in an attachment and a reference made to it in this section.

Section E: Qualifications of Key Personnel

Many contracts, particularly those for technical support services, use locally developed key personnel clauses³ to identify and control the use of the contractor’s key personnel (such requirements are usually not appropriate for use in a PWS or SOO). A key personnel clause requires that the contractor propose its key personnel by name. After award, the clause requires that substitutions of key personnel be made only after (1) advance notification to the contracting officer, and (2) a determination by the contracting officer that the substitute meets the requisite qualifications for that position. It is necessary, therefore, to describe the requisite qualifications and reference the clause in the SOW.

Use key personnel requirements sparingly. Each position identified as a key personnel position carries with it the administrative burden of reviewing each personnel change in that position for the life of the contract. If it is necessary to use a key personnel clause, only the top managerial and technical positions should be named as key personnel positions. Designate lower-level positions as key positions only when specific levels of expertise are required.

Describe the qualifications required for each key position. Specify the level of expertise and the educational or experience background required. Use the proposal preparation instructions to require the contractor to identify its key personnel and demonstrate how they meet the requisite qualifications. Permit the contractor to provide and explain equivalent education or experience levels as a substitute for those specified. You are not required to accept the contractor’s equivalency contentions, but doing so helps avoid problems when there are equivalent educational or experience levels of which you were not aware. If exceptions are made, the SOW should be modified accordingly before award.

If appropriate, indicate the percentage of time the key personnel are expected to devote to the contract. If you do not want to dictate the degree of participation, you can use the proposal preparation instructions to require the contractor to provide this information and incorporate the information into the SOW. This might be appropriate, for example, in an R&D contract with a university when you want to ensure significant participation by the specified key person rather than his or her assistants.

Give some thought, however, to the effect that a specific description of the qualifications of key personnel might have on an offeror’s response. Describing specific qualifications may inhibit the offeror’s ability to provide an innovative solution that uses personnel with different qualifications. For example, the FAR⁴ states that when acquiring information technology services, the solicitation must not describe any minimum experience or educational requirement for proposed contractor personnel unless the contracting officer determines that: (1) the needs of the agency cannot be met without that requirement, or (2) the use of other than a performance-based contract is required.

You do not necessarily need to use a key personnel clause. Use the proposal preparation instructions to require potential contractors to identify those persons they consider key personnel and describe their qualifications. Even though you have not mandated certain personnel qualifications, you may evaluate the cited qualifications as a function of how well the offeror understands the requirement. You may also consider the cited qualifications in a comparative assessment of offerors’ key personnel when determining the most highly rated proposals. This technique does have an elevated risk of protest; however, if you document a rational justification for your evaluation and can show this in your debriefing of the unsuccessful offerors, you should be able to avoid a protest.

SOWS FOR SEALED BIDDING

The nature of sealed bidding requires particular attention to how the requirement is described. The FAR⁵ states that sealed bidding may be used only if:

• Time permits the solicitation, submission, and evaluation of sealed bids.

• The award will be made on the basis of price and other price-related factors.

• It is not necessary to conduct discussions with the responding offerors about their bids.

• There is a reasonable expectation of receiving more than one sealed bid.

The use of sealed bidding is appropriate only if all of these conditions are met. Otherwise the use of competitive proposals (negotiation) is required.

How the Differences between Sealed Bidding and Negotiation Affect the SOW

In sealed bidding, award must be made on the basis of price (i.e., a fixed-price contract), no discussions may be held, and the bids may not be changed after bid opening. In negotiation, any appropriate pricing arrangement may be used, discussions may be held with offerors after the receipt of proposals, and the proposals may be changed to reflect these discussions. These differences affect SOW preparation for sealed bidding in two ways:

• The SOW must be particularly definitive. If a contractor must offer a fixed price, the SOW must be so definitive that the contractor can price the effort accurately based solely on the SOW presented in the solicitation. Under a fixed-price contract, the contractor guarantees performance, even if it is at the contractor’s own expense. This makes the accuracy of the contractor’s pricing an important factor both in the contractor’s willingness to compete and later in the contractor’s performance. A contractor working at a loss is going to be more interested in minimizing the loss than in maximizing the quality of the contract product.

• The SOW must stand on its own. In the sealed bidding process, the bidder submits its bid price, the bid price and any designated price-related factors are evaluated, and award is made to the lowest bidder. There is no opportunity to discuss the technical aspects of the bid with the bidder and no opportunity to use the proposal preparation instructions to obtain additional information to refine or clarify your SOW. The SOW must completely describe the requirement the first time. Your SOW must be good enough that you are willing to take the contractor’s word that it can perform the work successfully without any discussions or supporting information at all.

Under these circumstances, sealed bidding should be used only when the requirement can be described so clearly that a contractor proposal is not required to determine if the contractor can do the work. This is why the use of sealed bidding is usually restricted to requirements for commercial or commercial-type supplies and services.

Techniques to Support the SOW

Several techniques are available to support your SOW when sealed bidding is appropriate but a fully definitive SOW is not possible due to the nature of the product being procured.

Bid Samples

The FAR⁶ permits the use of a bid sample requirement only when characteristics of the product cannot be described adequately in the specification or purchase description but are important to the acceptability of the bid. A bid sample is a sample of the actual product to be furnished by the bidder to demonstrate the characteristics of the product offered. These characteristics include balance, facility of use, feel, color, pattern, or other characteristics that cannot otherwise be described in writing. If you have to see, feel, touch, or test an item to determine if it will meet your requirement, you should obtain a bid sample.

The SOW must indicate the number and size of the samples and otherwise fully describe the samples required. All characteristics for which the samples will be examined must be identified. If the bid sample is to be tested, describe what tests will be used and ensure that the description of the samples is such that the items will be delivered in a test-ready condition.

Note, however, that the FAR⁷ states that when more than a minor portion of the characteristics of the product cannot be adequately described in the specification, products should be procured by two-step sealed bidding or negotiation, as appropriate. Two-step sealed bidding or negotiation offers the contractor more flexibility in the submission and testing of samples.

Descriptive Literature

The FAR⁸ permits a requirement for descriptive literature only when it is necessary to determine, before award, that the products offered meet the specifications and to establish exactly what the bidder proposes to furnish. Descriptive literature is information such as cuts, illustrations, drawings, and brochures that show the characteristics or construction of a product or explain its operation.

The SOW must describe what descriptive literature is to be furnished and the purpose for which it is required. This is usually accomplished by describing the salient characteristics of the product that the literature must demonstrate. Salient characteristics may include design, materials, components, performance characteristics, and methods of manufacture, assembly, construction, or operation.

When using a descriptive literature requirement, ensure that the listed salient characteristics are limited to those characteristics that are necessary to determine the acceptability of the product. Do not include information related to the qualifications of the bidder or for use in operating or maintaining equipment.

Brand Name or Equal

The FAR⁹ permits the use of brand name or equal purchase descriptions for products readily available in the commercial marketplace when an adequate specification or more detailed purchase description cannot feasibly be made available in time for the acquisition. A brand name or equal description identifies the required item by brand name and model number or other description that serves to specifically identify the required item. The description must clearly state that either the brand name product or an equal product shall be provided.

To support the submission of an “or equal” product, the description must also identify the salient characteristics of the brand name product that the “or equal” product must meet. Contractors submitting an “or equal” product must submit descriptive literature demonstrating that their product meets all the salient characteristics listed.

Two-Step Sealed Bidding

Two-step sealed bidding is a combination of negotiation and sealed bidding used to obtain the benefits of sealed bidding when a description of the requirement suitable for sealed bidding is not available but all other conditions for sealed bidding apply.

Step 1 is a negotiated process in which technical proposals are submitted and evaluated, and, when necessary, discussions are conducted to clarify questions relating to the technical proposals. No pricing information is provided in this step. Step 1 is completed when all proposals have been evaluated and found to be either technically acceptable or technically unacceptable. The technically unacceptable proposals are rejected.

Step 2 is sealed bidding. The offerors who submitted technically acceptable proposals in Step 1 are invited to submit priced bids for their own technical proposals in Step 2. All the rules for sealed bidding apply. Award is made to the lowest evaluated price.

Even though discussions are permitted in Step 1 of the two-step process, the SOW still must be as definitive and stand-alone as possible. The SOW must set forth the technical requirements definitively; the discussions in Step 1 are only to determine the proposal’s conformity with the technical requirements in the SOW. The SOW will not be revised as a result of the information provided in the proposals and nothing will be incorporated by reference.

The two-step process is most appropriately used when there is a definitive requirement but the requirement could be performed in a number of ways and the government does not want to restrict competition by dictating the manner of performance.

SUMMARY

A well-written SOW answers the “what, why, where, when, and how” questions. What you want to buy is addressed in the introduction and scope sections. Why you want it is explained in the background section. Where the work is to be done is covered in the place of performance section. When the work is to be done is covered in the period of performance section. How the work is to be done is set forth in the technical requirements and delivery sections, supported by the applicable documents and supporting information sections.

The purpose of the SOW format is to compartmentalize the information about your requirement so that the SOW communicates your requirement effectively and facilitates your management of the contract. Conduct market research to determine what the marketplace has to offer and incorporate this information into the description of your requirement. Market research notwithstanding, it may be necessary to obtain specific contractor input before issuing your final SOW. This is done by issuing an initial SOW supplemented by proposal preparation instructions that require the contractor to provide specific kinds of information. This information is made part of the final SOW by incorporating all or part of the contractor’s proposal by reference. The final SOW becomes the contractual requirement at the time of contract award.

Chapter 6 addresses common problems in writing SOWs. This information is designed to help you avoid problems when writing an SOW and to help you ensure that any contractor-provided information that is to be incorporated by reference does not contain loopholes or ambiguities that will make contract administration difficult.