A Statement of Work (SOW) is a document included with all contracts that details the business terms (price, timing, scope, etc.) of the work to be performed by the supplier or independent contractor. It might also be referred to as a “Scope of Work,” “Proposal,” “Bid,” “Letter of Assignment,” “Engagement Letter,” “MOU,” “Service Description,” or “Requirements” document.
Typically, departments consult directly with the supplier representative or independent contractor regarding development of a specific SOW. The SOW identifies key indicators that help monitor project status and provide early warnings of a project moving off target. The time spent creating and agreeing to the SOW will significantly improve the likelihood of a successful project.
FMS provides an optional Statement of Work (SOW) template that departments and suppliers can use to facilitate the contract process. Otherwise, departments may consult with the section below to validate their SOW has all components needed to facilitate the process.
An SOW, proposal, and/or draft agreement must be attached to the contract request within SmartMart Contracts as well as to the purchase requisition associated with a contract if pricing is fragmented across these multiple documents.
When the contract request is associated with an existing University-Wide Agreement (MSA), the SOW is attached using the Statement of Work contract type within the SmartMart request form. Refer to Topic Overview: Contracts for more information.
The SOW should include a summary of project objectives, phases, and the terms and schedule of deliverables. The table below provides a description of what should be included in a SOW if the optional Statement of Work (SOW) template is not utilized:
| SOW component | Purpose/Description |
|---|---|
Basic elements:
| Identifies the parties included in the work. |
| Location | Describes where the work will be performed (e.g., city, state). |
Timeframe
| Provides the general timeframe covered by the contract. |
| Project requirements | Includes the expectations for stakeholders (both Stanford and the supplier or IC), specific work/activities, general steps and process details that need to be completed during the project, and how they will be performed. |
| Milestones (if applicable) | Such as inspections completed (construction), survey participants’ responses collected, test environment becomes operational, testing completed, and data set completed. If payment is contingent on deliverables, they should be tied to the budget. |
| Tasks (to achieve scope or milestones) | Clearly identify which entity is responsible for which tasks such as meetings the supplier or IC must attend, anything expected of the supplier or IC necessary to complement the deliverable such as QA, testing, post production support and training, which events will be used to measure progress, and what criteria will be used to define completion for each event. |
| Schedule | Includes the project’s timeline including start date, end date, milestone due dates, task due dates, resource procurement dates throughout the project’s life cycle (if applicable), and payment schedule (e.g. per milestone delivery or every 30 days). |
| Budget | The amount you are funding under this agreement with a breakdown and explanation of how the costs will be allocated. |
| Breakdown of costs | Includes the contractor’s hourly rates, the per unit rate for each deliverable, the total price to be paid for the project, when payments will be made, how payments are tied to completion of specific milestones and/or deliverables, and what percentage of payment will be withheld until final project completion. |
| Payment type (can be negotiated) | Would be one of the following:
|
| Scope of Work Performed | List the project requirements, including the expectations for stakeholders (both Stanford and the supplier), specific work/activities, general steps, and process details that need to be completed during the project, and how they will be performed. |
| Expected outcomes/project deliverables | Include a list of the goals around the final deliverables. Quantify the products or services that must be provided upon the completion of the project or during an ongoing engagement, such as testing (equipment customization or installation, software development, or research), reports, or physical deliverables, and define what both parties believe success will look like for the project. Expectations should be detailed and include specific methods or systems that must be utilized (e.g. data must be submitted in Excel, equipment must be shipped, etc.) |
| Special considerations | Conditions and requirements, which can be any other item that does not fit in the above such as additional concerns when working with Stanford, including: licensing, routes for construction vehicles, special considerations to prevent interference of students, alignment with Stanford’s SU-18 Patent and Copyright Agreement, on-campus parking passes, etc. |
| Closure/acceptance | Explains how the deliverables will be accepted, who will review and sign off on the deliverables and determine if the project can be properly closed. |
| Exclusions | Items the supplier will not provide under this agreement, or will only provide for an additional fee or time extension (e.g. travel, in-person meetings, specific hardware, licensing fees for third-party software, Google rankings, search engine optimization, customizations, unforeseen conditions, end-user training, troubleshooting issues caused by client modifications, or integrations with 3rd-party systems). |