Statement of Work

How a Statement of Work works in an engagement

A Statement of Work (SOW) gives the parties one engagement-specific reference for the work they plan to undertake. It turns a broad discussion into a record they can use to plan the work, carry it out, and assess the result. Whether the SOW has contractual effect, and how it works with other documents, depends on its wording, the way the parties form or incorporate it, and the applicable law.

When a Statement of Work is useful

An SOW is useful when a client and service provider need a shared description of a defined project or services engagement. By that point, they need to agree on what will be delivered, when the work is expected, and how performance will be assessed. Proposals, meetings, and informal expectations alone may not provide that common record.

An SOW can also support procurement. Under Oregon Department of Transportation guidance for personal-services procurement, consultants use the SOW to develop and price proposals, while the agency uses it to set evaluation factors. After award, the same guidance treats the SOW as a tool for identifying and measuring contractual performance and the parties' rights and obligations. Commercial engagements may follow a different sequence, so check the document's purpose and status in the process at hand.

An SOW may cover a single engagement or one project within a continuing business relationship. For example, some master-service-agreement structures use mutually executed SOWs for projects requested over time. An MSA is not required, and the SOW label does not establish legal effect by itself. The applicable agreement and the SOW's approval or incorporation terms control that question.

What a Statement of Work records

An SOW records more than a project name or a general intention to provide services. It connects the work to the resulting deliverables or service outcomes and the standards used to assess them. A task is an activity carried out to produce an outcome. A deliverable is an end product or service submitted for review or acceptance.

Keeping those concepts separate makes the engagement easier to follow. The work description shows what is expected to happen. The deliverable or service outcome shows what the work is meant to produce, and the stated standard gives the reviewer a way to assess it. Because some tasks do not produce a tangible item, an SOW can describe service outcomes as well as physical deliverables.

The same record can connect the work to project details, timing, responsibilities, price, and acceptance. Some of these terms may sit elsewhere in the contract. Before relying on the document, the parties need to know where each relevant term appears and how the documents work together.

What a Statement of Work should make explicit

The right level of detail depends on the work. Still, the parties need to be able to find and apply the terms that define scope, responsibilities, timing, commercial arrangements, and completion.

Work, outcomes, and boundaries

Start with the project's purpose and objectives, then describe the services within scope. The purpose supplies context. The objectives state the intended result, while the scope identifies the services the provider is expected to perform. These elements give meaning to the more detailed tasks and deliverables that follow.

Break the work into identifiable tasks and connect them to the deliverables or service outcomes they are meant to produce. Where feasible, a tangible and measurable outcome for each task shows whether the work advances the project objective. Work that produces an ongoing service still needs an outcome clear enough to assess against the relevant standard.

The SOW also needs a discernible boundary. A reader should be able to tell which services, tasks, and outcomes are included and whether a new request falls outside them. A list of exclusions can sharpen that boundary, though the document does not need a section titled “Out of scope.” What matters is whether the parties can distinguish agreed work from a new request that may require separate authorization.

Timing, roles, and dependencies

The work needs a workable sequence. For each material task or deliverable, identify the responsible party, the relevant start and finish period or due date, and any relationship to milestones or other work. Make critical milestones visible so each party knows when its contribution must be ready and when to expect the next step.

Responsibilities often extend beyond the provider's tasks. The SOW can allocate who supplies data, access, facilities, equipment, or other resources. It can also name the people responsible for approvals and decisions. This turns necessary inputs into stated commitments instead of leaving them as background assumptions.

Name material dependencies when work relies on an earlier task, another party's contribution, or an external event. A visible sequence makes it easier to see where a delay or missing input could affect the plan. Allocate each dependency where appropriate rather than assuming one party supplies every input or controls every condition.

Price, invoicing, and payment triggers

The applicable documents need to identify the compensation method. An SOW may state a rate, a milestone-based amount, or another method; the surrounding agreement may contain some or all of those commercial terms instead. Either structure can work when the documents make clear which terms govern the engagement.

The payment path needs to connect the work record with the commercial record. Depending on the arrangement, this may include the documentation required for payment, invoice timing, and the relevant deliverable, milestone, or service level. If payment depends on an output or service measure, the triggering event should be identifiable in the applicable documents.

Acceptance is one possible payment trigger, but it is not the trigger in every SOW. Check the agreement for invoice eligibility and timing, along with any terms on expenses, disputes, taxes, or withholding that apply. The price stated for the work is only one part of the payment process.

Acceptance and completion

Acceptance criteria need to show whether a deliverable or service meets the stated requirement. The Oregon DAS SOW writing guide treats objective, testable standards and a defined acceptance process as central to evaluating deliverables. “High quality” alone gives the reviewer no shared measure for deciding whether the requirement has been met.

The SOW should identify both the standard and the review process: who receives the work, which criteria apply, and where approval, acceptance, or rejection occurs. The procedure will vary by engagement, but its decision points need to be clear enough for the parties to use it.

Completion must match the form of the work. A deliverables-based engagement can tie completion to a specified output, due point, and acceptance assessment. Recurring services may instead be measured over a defined period against service levels. ODOT's guidance on SOWs illustrates both approaches. Time spent alone does not establish completion of a deliverables-based outcome, although a level-of-effort arrangement may use hours as its payment basis.

Other engagement-specific terms

Some engagements need terms specific to the setting in which the work will be performed. Depending on the work, these can cover applicable standards, regulations, permits, licenses, certifications, or location. Oregon DAS guidance lists these as matters an SOW may address, not as a universal checklist for every services engagement.

Specialized language needs the same clarity. When a technical term or abbreviation affects the work, a performance measure, or acceptance of a deliverable, the SOW should define it or identify the incorporated document that does. This gives the parties a shared basis for applying the requirement instead of leaving its meaning open to assumption. Oregon DAS guidance lists definitions and acronyms among possible SOW elements in its Oregon state-agency procurement context. It is a useful clarity check, not a requirement for every SOW to contain a glossary.

Operational details can matter just as much. The parties may need to record furnished data, property, facilities, or other resources. Performance reporting, service-level measures, and constraints may also belong in the SOW. If the engagement calls for a response when performance falls short, the relevant process or remedy should be identifiable instead of remaining an unstated expectation.

An SOW can also define how the parties will handle decisions that remain unresolved when work begins. Naming the decision process and the authorized decision-maker gives the engagement a route forward when every outcome cannot be specified in advance. Broader terms covering intellectual property, confidentiality, data security, warranties, indemnity, tax, or liability may appear in a master agreement or elsewhere in the contract. Check the complete document set before assuming that any of them belongs in the SOW.

Common ways to describe the work

An SOW can prescribe the work in detail, define an amount of effort, or focus on required performance and service outcomes. These are ways to organize an engagement, not a universal legal classification. A single SOW can combine them.

Detailed or design-based work

A detailed or design-based approach states the required result and significant aspects of how it must be produced. In Oregon DAS procurement guidance, a design SOW can specify materials, production processes, dimensions, tolerances, quality, inspection, and packaging for a product or service with a detailed design.

This approach gives the provider a defined method or set of specifications to follow alongside the expected outcome. The SOW can then be assessed on two levels: whether it identifies the result and whether it states the required features of the means, materials, or process. That detail makes it possible to compare the stated expectations with the work performed.

“Design SOW” is one procurement convention. The label does not decide who bears performance, cost, schedule, or liability consequences; the actual agreement does. Treat the level of prescription as a description of the work, then review the agreement for the commitments attached to it.

Level-of-effort or time-and-materials work

A level-of-effort SOW can describe broad services through the amount of work to be provided, with an hour of consultant work serving as the deliverable or payment basis. ODOT's SOW guidance uses this approach in its personal-services procurement context. Here, the commitment is framed through effort rather than a defined output.

Time-and-materials is a compensation method, not another name for a level-of-effort SOW. The same ODOT guidance associates labor-hours or time-and-materials compensation with work that cannot be estimated precisely, while “level of effort” describes how the work itself is framed. The concepts may appear together, but they are not interchangeable.

Locate the provisions that state what will be billed and how the amount is calculated. They may specify a billing unit, rate, authorized amount, or other limits, depending on the agreement. Neither “level of effort” nor “time and materials” establishes a universal cap or allocation of cost, schedule, or liability risk.

Performance, deliverables, and service levels

In Oregon DAS procurement guidance, a functional SOW describes the end purpose, expected result, or final objective and focuses mainly on what the requirement must accomplish. It may still specify a product or approach. Oregon distinguishes this from its performance SOW, which adds minimum acceptable standards or ranges without prescribing the process. This is one Oregon state-agency procurement convention, not a standardized or exhaustive taxonomy.

A performance-based description focuses on the required result and a measurable outcome instead of prescribing methods or hours. In U.S. federal procurement, the Federal Acquisition Regulation defines a Performance Work Statement as an SOW for performance-based acquisitions that describes required results in clear, objective terms with measurable outcomes. This federal procurement model does not govern every commercial SOW.

Deliverables-based work and recurring services call for different measures. For a deliverable, the SOW can state the output, its due point, and how acceptability will be determined. For a recurring service, it can state what service must remain available and how the parties will measure whether it is adequate. ODOT's SOW guidance uses measurable, enforceable service levels for recurring services.

The approaches are not exhaustive. An engagement might require a defined output alongside a recurring service level, combining a deliverable acceptance measure with ongoing performance measures. Match the measure to each commitment instead of applying one review method to every kind of work.

The meaning of “hybrid SOW” also depends on the organization using it. Washington DES uses the label for an SOW covering goods and associated services, such as a generator together with operation, maintenance, and repair. That is an organization-specific use, not a standardized category or an automatic label for every SOW that combines approaches. When the term appears, check what the document combines and how each commitment will be assessed.

How a Statement of Work differs from related documents

One engagement may involve a scope, proposal, requirements document, service-level terms, and an SOW. Names and boundaries vary across organizations. Identify what each document does and how the parties use it before drawing conclusions from its title.

Scope of work

“Scope of work” usually refers to the work included in an engagement, but it can be a section of an SOW or a separate document. The terms do not have a universal distinction. A more useful question is whether the document communicates an initial need or invitation to compete, or records the work and obligations agreed for an engagement.

One government-procurement model makes that functional distinction explicit. In Oregon DAS guidance, a scope of work in a solicitation describes the agency's needs and desired outcomes so respondents can decide whether to compete. The contractual SOW describes the agreed work and the parties' roles and responsibilities. This is a practical way to assess the document's function, not a universal naming rule.

The sequence can be less tidy than the labels suggest. ODOT guidance also distinguishes a solicitation's general scope from the contract's more detailed scope, yet it describes consultants using an SOW to develop proposals during procurement. Before treating “scope” and “SOW” as interchangeable or distinct, check the document's role in the solicitation, whether it has been agreed or incorporated, and whether it contains the detail needed to govern performance.

Proposal and request for proposal

In a request-for-proposal process, the RFP invites suppliers to submit offers, and a proposal is a supplier's response. Under U.S. federal procurement terminology, an RFP is a type of solicitation and the offers submitted in response are proposals. These definitions belong to federal procurement, but they also illustrate the different functions of a request and a response.

An SOW describes the work or required results against which a supplier can prepare a response and the parties can structure the resulting engagement. An RFP may attach or include an SOW, so the documents can appear together without doing the same job. The proposal states what the supplier offers in response. The SOW frames the requested work or, once agreed, the engagement itself.

The sequence and terminology vary. A proposal or its work description may change before contract formation, and the parties may later incorporate that description into their agreement. Check which version controls and whether the agreement incorporates it. A proposal or solicitation-stage SOW does not automatically become the agreed SOW.

Requirements specifications and service levels

A technical requirements specification focuses on what a product or system must do. In the NASA Software Engineering Handbook, software technical requirements turn stakeholder expectations into quantitative, measurable requirements used to define a design solution. They are commonly captured in a software requirements specification. An SOW addresses the engagement work and related performance obligations, though it may refer to or include technical specifications.

A service-level agreement or service-level section focuses on responsibilities and the expected performance of an ongoing service. The NIST definition of an SLA covers service details, expected performance such as reliability, quality, or response time, and related reporting and resolution arrangements. A broader SOW can describe the overall engagement while service-level terms state how recurring service performance will be measured.

These documents may be separate, linked, or combined. An SRS is not always separate from an SOW, and an SLA is not universally synonymous with one. The agreement's document structure determines which requirements or service levels are incorporated and which document takes priority when terms overlap.

How a Statement of Work relates to an MSA or other agreement

An SOW may sit alongside other documents that govern the parties' relationship. The document set determines its role: an agreement may use an SOW for a specific engagement, incorporate it into broader terms, or assign it another function.

The relationship framework and the particular engagement

In a common structure, a master services agreement (MSA) sets the general relationship terms and an SOW records the details of a particular project. For example, the Solventum–3M master agreement filed with the SEC uses SOWs for specific projects within its general terms. An SOW does not require an MSA, and MSAs do not all divide terms in the same way.

Under this structure, the SOW may identify the project description, services and deliverables, milestones, pricing, personnel, and term for the individual engagement. The Hyperfine–4Catalyzer agreement is one example: its master contract covers multiple projects, and its SOW form contains those project details. The SOW shows the engagement-specific commitments; the surrounding agreement supplies the framework that applies to them.

The SOW title does not determine whether the document binds the parties. Under the Hyperfine agreement, an SOW does not bind until a purchase order is issued. Under the Access Worldwide–E*TRADE agreement, scopes of work become effective when signed by authorized representatives. These party-specific examples point to the terms that matter in another document set: signature, approval, purchase-order, online-acceptance, and effective-date provisions, together with applicable law.

Incorporation, changes, and conflicting documents

Incorporation language explains how an SOW and the surrounding agreement work together. Identify which documents are incorporated, whether the SOW adds to or changes any master terms, and whether the agreement states an order of precedence. Titles alone do not answer those questions.

Party-specific agreements use different hierarchies. The Solventum–3M agreement generally gives an SOW priority while preserving specified master-agreement articles. The Watsco–FEI agreement generally gives the master agreement or an appendix priority unless the SOW expressly identifies the term it supersedes. These examples show why the actual precedence, exception, and amendment language must be read.

Changes to scope, schedule, price, or other agreed work should follow the mechanism and authorization rules in the applicable agreement. The Solventum–3M agreement, for example, calls for a written change request specifying its type and scope, followed by a written amendment if accepted. ODOT guidance handles additional effort and contingency tasks under its own procurement rules. The required form and approval process vary, so test each new request against the process the parties agreed to use.

What to check before signing or changing a Statement of Work

Reviewing an SOW means testing whether its terms can guide the planning, performance, assessment, and revision of the engagement. The questions below draw on procurement guidance. They are a practical review method rather than a universal test of legal validity or a substitute for reviewing the applicable agreement.

Can each deliverable be verified and accepted?

For each material deliverable or service, trace the commitment through to its assessment. Oregon DAS guidance connects responsibilities, deliverables, schedules, testable performance standards, acceptance, and compensation. ODOT guidance likewise connects outcomes, timing, measurement, acceptance, and payment. Use that chain to ask:

• What output or service is due?
• Who is responsible for providing it?
• When is it due, or over what service period must it be performed?
• Who receives or reviews it?
• Which measurable standard or acceptance criterion applies?
• Who makes the acceptance decision, and at which control point?
• Does an invoice or payment trigger depend on that decision, deliverable, milestone, or service level?

The answers should fit the work. A tangible deliverable may be reviewed at a milestone, while a recurring service may be measured over time against a service level. A time-based engagement may use hours or service periods instead of a physical deliverable. If the document does not identify the relevant commitment, reviewer, measure, and decision point, clarify the acceptance path before relying on it.

Are assumptions, dependencies, and changes workable?

Assumptions and dependencies need to be visible and usable instead of buried in a project plan or left to informal understanding. ODOT guidance recommends listing and validating performance assumptions, allocating relevant responsibilities, and defining a decision process and authorized decision-maker when every outcome cannot be known in advance. Recording an assumption does not resolve its consequences or authorize more time or payment by itself.

For each material input or dependency, ask:

• What client, provider, or third-party input, approval, access, resource, or predecessor work is required?
• Who is responsible for providing it, and when is it needed?
• Which task, deliverable, or milestone depends on it?
• What process applies if the input is late, unavailable, or materially different from the assumption?
• Who has authority to approve a change to the agreed work?

Oregon DAS guidance identifies furnished resources and internal or external dependencies as matters to record. The Solventum–3M agreement illustrates one party-specific cooperation and information obligation. The applicable agreement should provide a route for changing scope, schedule, price, or other commitments. A late or missing input does not automatically create a schedule extension, fee increase, or excuse from performance. The parties need to check the terms and use the agreed authorization process.