The statement of work (SOW) is a narrative description of the work required for the project. The complexity of the SOW is determined by the desires of top management, the customer, and/or the user groups. For projects internal to the company, the SOW is prepared by the project office with input from the user groups. The reason for this is that user groups tend to write in such scientific terms that only the user groups understand their meaning. Since the project office is usually composed of personnel with writing skills, it is only fitting that the project office prepare the SOW and submit it to the user groups for verification and approval.
For projects external to the organization, as in competitive bidding, the contractor may have to prepare the SOW for the customer because the customer may not have a team of people trained in SOW preparation. In this case, as before, the contractor would submit the SOW to the customer for approval. It is also quite common for the project manager to rewrite a customer's SOW so that the contractor's line managers can price out the effort.
In a competitive bidding environment, the reader should be aware of the fact that there are two SOWs—the SOW used in the proposal and a contract statement of work (CSOW). There might also be a proposal WBS and a contract work breakdown structure (CWBS). Special care must be taken by contract and negotiation teams that all discrepancies between the SOW/WBS and CSOW/CWBS are discovered, or additional costs may be incurred. A good (or winning) proposal is no guarantee that the customer or contractor understands the SOW. For large projects, fact-finding is usually required before final negotiations because it is essential that both the customer and the contractor understand and agree on the SOW, what work is required, what work is proposed, the factual basis for the costs, and other related elements. In addition, it is imperative that there be agreement between the final CSOW and CWBS.
SOW preparation is not as easy as it sounds. Consider the following:
• The SOW says that you are to conduct a minimum of fifteen tests to determine the material properties of a new substance. You price out twenty tests just to "play it safe." At the end of the fifteenth test, the customer says that the results are inconclusive and that you must run another fifteen tests. The cost overrun is $40,000.
• The Navy gives you a contract in which the SOW states that the prototype must be tested in "water." You drop the prototype into a swimming pool to test it. Unfortunately, the Navy's definition of "water" is the Atlantic Ocean, and it costs you $1 million to transport all of your test engineers and test equipment to the Atlantic Ocean.
• You receive a contract in which the SOW says that you must transport goods across the country using "aerated" boxcars. You select boxcars that have open tops so that air can flow in. During the trip, the train goes through an area of torrential rains, and the goods are ruined. The customer wanted boxcars that were aerated from below. The court is currently deciding who should be blamed for misinterpretation of the word "aerated."
The above three examples show that misinterpretations of the SOW can result in losses of hundreds of millions of dollars a year. Common causes of misinterpretation are:
• Mixing tasks, specifications, approvals, and special instructions
• Using imprecise language ("nearly," "optimum," "approximately," etc.)
• No pattern, structure, or chronological order
• Wide variation in size of tasks
• Wide variation in how to describe details of the work
• Failing to get third-party review
Misinterpretations of the statement of work can and will occur no matter how hard the quest for perfection during the definition phase. The result is creeping scope, or, as one telecommunications company calls it, "creeping elegance." The best way to control creeping scope is with a good definition of the requirements up front. Unfortunately, this is not always possible.
In some industries, such as aerospace, defense, and MIS, creeping scope had become a way of life until recently. In the Information Technology Group of a major appliance manufacturer, the project manager made it clear that she would not accept any scope changes once the definition of the requirement (prepared by the user group) was completed. Midway through the project, the user group tried to change the requirements. The project manager refused to accept the changes and, against the wishes of the user group, put all requests for changes into a follow-on enhancement project that would be budgeted for and scheduled after the initial project was completed. When the initial project was completed and in stalled at the user's location, the users stated that they could live with the original package, and the enhancement project was neither funded nor approved.
Today, both private industry and government agencies are developing manuals on SOW preparation. The following is adapted from a NASA publication on SOW preparation:3
• The project manager or his designees should review the documents that authorize the project and define its objectives, and also review contracts and studies leading to the present level of development. As a convenience, a bibliography of related studies should be prepared together with samples of any similar SOWs, and compliance specifications.
• A copy of the WBS should be obtained. At this point coordination between the CWBS elements and the SOW should commence. Each task element of the preliminary CWBS should be explained in the SOW, and related coding should be used.
• The project manager should establish a SOW preparation team consisting of personnel he deems appropriate from the program or project office who are experts in the technical areas involved, and representatives from procurement, financial management, fabrication, test, logistics, configuration management, operations, safety, reliability, and quality assurance, plus any other area that may be involved in the contemplated procurement.
• Before the team actually starts preparation of the SOW, the project manager should brief program management as to the structure of the preliminary CWBS and the nature of the contemplated SOW. This briefing is used as a baseline from which to proceed further.
• The project manager may assign identified tasks to team members and identify compliance specifications, design criteria, and other requirements documentation that must be included in the SOW and assign them to responsible personnel for preparation. Assigned team members will identify and obtain copies of specifications and technical requirements documents, engineering drawings, and results of preliminary and/or related studies that may apply to various elements of the proposed procurement.
• The project manager should prepare a detailed checklist showing the mandatory items and the selected optional items as they apply to the main body or the appendixes of the SOW.
• The project manager should emphasize the use of preferred parts lists; standard subsystem designs, both existing and under development; available hardware in inventory; off-the-shelf equipment; component qualification data; design criteria handbooks; and other technical information available to design engineers to prevent deviations from the best design practices.
• Cost estimates (manning requirements, material costs, software requirements, etc.) developed by the cost-estimating specialists should be reviewed by SOW contributors. Such reviews will permit early trade-off consideration on the desirability of requirements that are not directly related to essential technical objectives.
3 Adapted from Statement of Work Handbook NHB5600.2, National Aeronautics and Space Administration, February 1975.
• The project manager should establish schedules for submission of coordinated SOW fragments from each task team member. He must assure that these schedules are compatible with the schedule for the RFP issuance. The statement of work should be prepared sufficiently early to permit full project coordination and to ensure that all project requirements are included. It should be completed in advance of RFP preparation.
SOW preparation manuals also contain guides for editors and writers:4
• Every SOW that exceeds two pages in length should have a table of contents conforming to the CWBS coding structure. There should rarely be items in the SOW that are not shown on the CWBS; however, it is not absolutely necessary to restrict items to those cited in the CWBS.
• Clear and precise task descriptions are essential. The SOW writer should realize that his or her efforts will have to be read and interpreted by persons of varied background (such as lawyers, buyers, engineers, cost estimators, accountants, and specialists in production, transportation, security, audit, quality, finance, and contract management). A good SOW states precisely the product or service desired. The clarity of the SOW will affect administration of the contract, since it defines the scope of work to be performed. Any work that falls outside that scope will involve new procurement with probable increased costs.
• The most important thing to keep in mind when writing a SOW is the most likely effect the written work will have upon the reader. Therefore, every effort must be made to avoid ambiguity. All obligations of the government should be carefully spelled out. If approval actions are to be provided by the government, set a time limit. If government-furnished equipment (GFE) and/or services, etc., are to be provided, state the nature, condition, and time of delivery, if feasible.
• Remember that any provision that takes control of the work away from the contractor, even temporarily, may result in relieving the contractor of responsibility.
• In specifying requirements, use active rather than passive terminology. Say that the contractor shall conduct a test rather than that a test should be conducted. In other words, when a firm requirement is intended, use the mandatory term "shall" rather than the permissive term "should."
• Limit abbreviations to those in common usage. Provide a list of all pertinent abbreviations and acronyms at the beginning of the SOW. When using a term for the first time, spell it out and show the abbreviation or acronym in parentheses following the word or words.
• When it is important to define a division of responsibilities between the contractor, other agencies, etc., a separate section of the SOW (in an appropriate location) should be included and delineate such responsibilities.
• Include procedures. When immediate decisions cannot be made, it may be possible to include a procedure for making them (e.g., "as approved by the contracting officer," or "the contractor shall submit a report each time a failure occurs").
• Do not overspecify. Depending upon the nature of the work and the type of contract, the ideal situation may be to specify results required or end-items to be delivered and let the contractor propose his best method.
• Describe requirements in sufficient detail to assure clarity, not only for legal reasons, but for practical application. It is easy to overlook many details. It is equally easy to be repetitious. Beware of doing either. For every piece of deliverable hardware, for every report, for every immediate action, do not specify that something be done "as necessary." Rather, specify whether the judgment is to be made by the contractor or by the government. Be aware that these types of contingent actions may have an impact on price as well as schedule. Where expensive services, such as technical liaison, are to be furnished, do not say "as required." Provide a ceiling on the extent of such services, or work out a procedure (e.g., a level of effort, pool of man-hours) that will ensure adequate control.
• Avoid incorporating extraneous material and requirements. They may add unnecessary cost. Data requirements are common examples of problems in this area. Screen out unnecessary data requirements, and specify only what is essential and when. It is recommended that data requirements be specified separately in a data requirements appendix or equivalent.
• Do not repeat detailed requirements or specifications that are already spelled out in applicable documents. Instead, incorporate them by reference. If amplification, modification, or exceptions are required, make specific reference to the applicable portions and describe the change.
Some preparation documents also contain checklists for SOW preparation.5 A checklist is furnished below to provide considerations that SOW writers should keep in mind in preparing statements of work:
• Is the SOW (when used in conjunction with the preliminary CWBS) specific enough to permit a contractor to make a tabulation and summary of manpower and resources needed to accomplish each SOW task element?
• Are specific duties of the contractor stated so he will know what is required, and can the contracting officer's representative, who signs the acceptance report, tell whether the contractor has complied?
• Are all parts of the SOW so written that there is no question as to what the contractor is obligated to do, and when?
• When it is necessary to reference other documents, is the proper reference document described? Is it properly cited? Is all of it really pertinent to the task, or should only portions be referenced? Is it cross-referenced to the applicable SOW task element?
• Are any specifications or exhibits applicable in whole or in part? If so, are they properly cited and referenced to the appropriate SOW element?
• Are directions clearly distinguishable from general information?
• Is there a time-phased data requirement for each deliverable item? If elapsed time is used, does it specify calendar or work days?
• Are proper quantities shown?
• Have headings been checked for format and grammar? Are subheadings comparable? Is the text compatible with the title? Is a multidecimal or alphanumeric numbering system used in the SOW? Can it be cross-referenced with the CWBS?
• Have appropriate portions of procurement regulations been followed?
• Has extraneous material been eliminated?
• Can SOW task/contract line items and configuration item breakouts at lower levels be identified and defined in sufficient detail so they can be summarized to discrete third-level CWBS elements?
• Have all requirements for data been specified separately in a data requirements appendix or its equivalent? Have all extraneous data requirements been eliminated?
• Are security requirements adequately covered if required?
• Has its availability to contractors been specified?
Finally, there should be a management review of the SOW preparation interpretation:6
During development of the Statement of Work, the project manager should ensure adequacy of content by holding frequent reviews with project and functional specialists to determine that technical and data requirements specified do conform to the guidelines herein and adequately support the common system objective. The CWBS/SOW matrix should be used to analyze the SOW for completeness. After all comments and inputs have been incorporated, a final team review should be held to produce a draft SOW for review by functional and project managers. Specific problems should be resolved and changes made as appropriate. A final draft should then be prepared and reviewed with the program manager, contracting officer, or with higher management if the procurement is a major acquisition. The final review should include a briefing on the total RFP package. If other program offices or other Government agencies will be involved in the procurement, obtain their concurrence also.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.