Statements of work are most often associated with requests for proposals (RFPs), which are the formal documents issued by a buying organization inviting potential vendors to bid on a contract. However, organizations need to practice writing SOWs for their internal projects as well. As we shall see, the SOW is a definitive description of the work, and having such a document can only aid the project team to fulfill the desires of the customer, whether internal or external.
There are several reasons a SOW is critical to project success. First, this is the document that completely describes the work to be done. Second, the SOW describes what constitutes acceptance. That is, the SOW should always contain a section that describes what the project team must do to provide an acceptable product or service, and, likewise, how the customer will measure project completion. Unless this completion criteria is explicitly stated in the SOW, the project may never reach a conclusion because the customer can always claim the deliverable did not meet her intended desires or needs. Third, the SOW takes precedence over all other documents. For instance, if a specification attached to the SOW describes the desired functionality of the product differently than the statement of work describes it, the SOW is the document that must be followed. Of course, the discrepancy between the two documents should be pointed out to the customer for clarification and possible amendment. Many providers have assumed that, for instance, the engineering specification describing the product is precisely what has to be delivered. They later found themselves redoing the product, at company expense, because the SOW described something slightly different.
For smaller, less costly projects, the buyer might issue a specification or needs statement. The difference between this statement and the SOW is in the amount of detail included. However, whatever term is used, the goal is the same—to describe the needs of the customer. In this book, we will concentrate on the SOW because that is the most difficult and most detailed of the needs descriptions. But even statements of work can take on a different focus or include a different amount of detail depending on the form they take.
There are three major types of SOWs. They can be based on:
Design or detailed specifications
Level of effort
Although there are other types and variations of each of these SOWs, these generally meet the needs of most IT projects.
Design and detailed specification statements of work tell the provider how to do the work. They may include precise measurements, tolerances, materials, quality control requirements, and any other specific constraints determined to be important to the customer. There are definite advantages and disadvantages to this type of SOW. Some of the advantages are:
The customer is able to describe precisely what she wants and how it is to be built.
There generally is less potential for misinterpreting the customer's requirements.
The provider is relieved of bearing the risk for the project.
Up-front efforts are generally reduced. That is, there generally is less design required or less testing required of various technical solutions.
The disadvantages of this type of SOW are:
The customer must bear the major risk burden in the project because he is dictating the solution and how it is to be provided.
The customer may not get the most cost-effective or most functional product since this approach precludes evaluation of other solutions.
It generally produces poor projects in the IT world because it dampens, or even eliminates, creativity.
This SOW is often used in the manufacturing or construction business, but other work efforts are often described in this format. It can be used to good effect in the IT environment, but should be used with discrimination and only for small, highly defined projects. Otherwise, the very essence of IT, namely creativity, is compromised.
An excellent type of SOW that is used effectively in practically any type of service industry or project is the level-of-effort SOW.
Level-of-effort (LOE) SOWs can be written for almost any type of service unless it is an inherent organizational service. The real deliverable under this type of effort is an hour of work. That is, the customer contracts for time and pays the provider according to the amount of time spent providing the task. Usually, this type of contract has a weekly or monthly cap on the amount of compensated work, which requires the provider to closely control the amount of scheduled work. The provider generally has to produce proof, in the form of certified time sheets, to the customer before payment is made. This type of SOW can also be used within an organization to track how much effort is expended in accomplishing such projects as upgrades to managerial systems control processes.
The most efficient and effective SOW model is, however, the performance-based statement of work.
Performance-based statements of work are always the preferred method for transmitting the customer's needs because they structure all aspects of an acquisition around the purpose of the work and not around how to accomplish the work. This approach has a number of advantages to both the customer and to the provider. The two most important advantages are that the provider or contractor has the freedom to develop and evaluate different solutions to meet the customer's requirements. The customer can concentrate on obtaining the desired provider instead of the provider's processes. This approach usually costs less than the design or detailed specification SOW because the focus is on functionality rather than on meeting precise engineering measurements. That is, it is generally more important that a desired result is obtained from turning a knob than it is that the knob be turned precisely one-quarter turn to obtain the result. The cost of engineering the latter example is significantly higher than designing for functionality.
It is possible that some combination of SOW types may be needed. For example, an IT project that addresses a satellite communication system must of necessity contain specifications describing close engineering tolerances. Likewise, satellite size and weight constraints are described in the SOW and accompanying documents, but many of the other project requirements are described in terms of the functions the system must perform.
Statements of work, being the most essential documents in any solicitation, contract, or important internal project initiative, must be written so that all technical and nontechnical readers can understand them. But writing good SOWs is not easy. It requires close attention to detail and a thorough understanding of the customer's needs.
The investment of time and effort to write a clear and high-quality SOW:
Enables vendors or internal project teams to understand clearly the customer's requirements and needs.
Allows project teams to more accurately schedule and cost the effort and to develop a higher-quality technical solution to meet the requirements.
Minimizes the need for change orders or other project adjustments, which can increase project costs and, usually, schedule durations.
Provides a milieu for establishing performance and completion criteria.
Allows both the customer and the project team a way to assess performance and progress.
Reduces claims and disputes.
There are several SOW format variations that are effective and useful, but generally all SOWs have the same basic sections. A general format is provided in Exhibit 4-2, and the content of each of its sections is described in the next several paragraphs.
Exhibit 4-2: A statement of work format.
Statement of Work
Detailed project requirements
Systems analysis and control
Delivery and installation
Concept of operations
System requirements review
System design review
Program management system
Risk assessment, mitigation, and management program
Life cycle cost (LCC) analysis and control
Program electronic database
Buyer's measure of acceptability
Product demonstration milestones
Provider's responsibility for demonstrating product acceptability
The statement of work can be thought of as the project specification. As such, SOWs typically describe the technical aspects of the project. Other important subjects such as background, applicable documents, and acceptance criteria reporting requirements, or any other pertinent contractual requirements not discussed in the SOW, are addressed in the project plan. Although many SOWs will contain engineering specifications, usually as attachments or appendixes, many will not, nor should they. This is especially true of SOWs that have been prepared as performance-based documents. Yet thinking of the SOW as a specification gives an added emphasis to the importance of the document, if there is still any doubt. This thinking also helps focus the writer's attention on providing clear and concise descriptions of the work, and it helps focus the reader on the salient points of the document. Each of the SOW sections is briefly described below.
Scope. The scope section is really an introduction to the project. In one sense, it is a little misleading because we think of the SOW as providing the project scope. Thus, it is logical to assume that this section would do exactly that. However, this section is simply a high-level statement of what is described in the rest of the SOW and generally what the project is about. An example of the scope section is:
This statement of work defines the effort required for the design, engineering development, software programming, fabrication, and test of a prototype of the (project name) information technology system to determine system feasibility. It includes the associated project management, human engineering, and logistics support planning requirements.
The Exhibit 4-2 statement of work format may be more comprehensive than you need for your project, particularly if the project is relatively small and without the usual complexities of most IT projects. If that is the case, use the applicable sections of the format and skip the others. Likewise, add any sections not in the format that are important to your project's success. Remember that every project is unique, so providing a format that fits every situation is difficult if not impossible.
The focus thus far in this chapter has been primarily from the viewpoint of the customer. Understanding what requirements are, how they are developed by the customer, and how they are transmitted to the provider is essential to understanding the next step—interpreting statements of work and identifying the requirements.