Home Computer Science
Scope of Work and Business Requirements
This is the portion of the SOW that describes the scope of the services to be provided and details the customer’s business requirements.
■ Include an overview section at the beginning of each SOW providing a brief, plain-English explanation of what the contractor is expected to do or deliver. This explanation should be written so that someone unrelated to the project who is generally familiar with technology could understand the services and deliverables to be provided by the contractor. Avoid excess use of jargon and acronyms and capitalized terms, unless such terms are clearly defined in the SOW or the agreement.
■ Include a project plan with a clear project schedule. All dates must be readily calculable. Avoid referring to dates as “estimates.” Avoid calculation of all dates from the “beginning of the project” without clearly defining the date of that beginning. Where appropriate, include credits for failure to adhere to the project schedule (e.g., credits to be issued for each day/week a deliverable is delayed). Credits should scale according to the length of the delay. Consider “earn-back” language to permit the contractor to earn back the credits if it promptly returns to the required schedule.
■ Functional and technical specifications are essential. Avoid deferring the specifications to a later date. If part of the project includes the development of detailed technical specifications later in the project process, include a description of the requirements for the development of specifications.
■ Avoid using unmodified contractor form implementation plans. Each implementation effort is unique to the customer and should be modified to reflect the specifics of the engagement.
■ Remove or limit extensive lists of contingencies on the contractor’s performance. Carefully review and limit any contractor “assumptions” in the SOW. Tire vast majority of those contingencies are very general in nature and would create a substantial “out” for the contractor and provide the means for the contractor to charge additional fees. Often, the assumptions should be reevaluated as requirements. For example, if the contractor assumes that the customer will provide all workstations and development software, this statement should be recast as a requirement for the project and include detailed descriptions of exactly what software or hardware is required and when it is required.
■ Avoid references to an associated proposal, request for proposal (“RFP”), or other sales-related documentation. These documents may contain legal terms that could conflict with the agreement. When specific content in these documents is relevant to a particular project, it should be revised accordingly and then directly incorporated into the SOW.
■ Remove language that would allow the SOW to override the agreement, especially when there are conflicting terms. Unless specifically approved by the customer’s contract management and legal department, there should be no legal terms in the SOW. In particular, language relating to ownership of intellectual property, warranties, indemnities, and limitations on each party’s liability should not be included in the SOW. This language should be fully addressed in the agreement.
■ Ensure the language in the SOW conforms to the agreement. This means making sure defined terms used in the agreement are also used in the SOW. Examples of potential problems include the following: referring to the contractor by a name that conflicts with the defined name in the agreement and failure to use defined terms like “Deliverables” and “Services” (most SOWs refer to the “work” to be performed, but the agreement likely focuses entirely on the “Services,” a defined term, to be performed).
■ Avoid passive voice. Never have statements like the following: “the router will be configured” or “the functionality will be tested.” Passive voice means the party doing the acting is not expressed. That is exactly the kind of language no SOW should contain. SOWs should be comprised of clear, affirmative, active voice: “the Vendor will configure the router” and “Vendor will complete the functionality and Customer will test the functionality.” More than one dispute has arisen from the use of passive voice. Avoid it.
■ Delete all language that would result in deliverables or services being “deemed accepted” simply because of the passage of time. Tire express procedure and criteria for acceptance should be set forth in the agreement and should not be overridden in the SOW.
■ If capitalized terms and/or acronyms are used, they must be clearly defined. If highly technical terms are used, consider including a brief definition.
■ Consider breaking complex SOWs into smaller, more discrete SOWs. When necessary, an initial, limited “scoping” SOW may be used to better define the requirements for a later SOW (e.g., it may be necessary for the contractor to perform certain initial assessment services to better understand the customer’s systems before it can commit to a SOW for a software implementation). Scoping SOWs may also be useful in changing a time and materials assignment into a fixed-fee engagement. For example, if the contractor has insufficient information about an engagement, it may be reticent to provide services on a fixed-fee basis. However, if the contractor is afforded the opportunity to conduct an assessment of the customer’s environment during a brief scoping SOW, it may be more inclined to commit to a fixed-fee engagement.