Sample Statement of Work Outline in Plain English

A Destin property management company paid $45,000 for a "complete network overhaul" from an IT vendor. When the work was done, half the equipment was unused, some problems weren't fixed, and they had no idea what they'd actually paid for.

The vendor pointed to the SOW. The SOW said "network overhaul." It didn't say what that meant.

That's the problem with vague SOWs. They sound comprehensive. They leave room for interpretation. The interpretation always favors the vendor.

What an SOW actually does

A Statement of Work defines what you're buying. It should answer:

• What specifically will be done?
• When will it be done?
• How much will it cost?
• How do you know when it's done?

A good SOW prevents disputes. A bad SOW creates them.

The outline

Here's a complete SOW structure in plain English. Use it as a template.

---

Project Name: [What you're calling this project]

Date: [Today's date]

Parties: [Your company name] and [Vendor name]

Project Overview (1-2 paragraphs)

What is this project? Why are you doing it? What problem does it solve?

Example: "We need to replace our aging server infrastructure because it's causing frequent downtime during business hours. This project will install new servers, migrate existing data, and provide documentation for our team."

---

Scope of Work

List each deliverable separately. Be specific. "Server installation" is not a deliverable. "Install and configure two Dell PowerEdge R750 servers with 128GB RAM, configured in a failover cluster" is a deliverable.

For each deliverable, include:

• What specifically will be done
• Where (which locations, which systems)
• Who is responsible (vendor or client)

Example scope items:

1. Remove existing two servers from the main office server room
2. Install two new Dell PowerEdge R750 servers in main office server room
3. Configure servers in Windows Failover Clustering for high availability
4. Migrate data from existing servers to new servers (approximately 2TB)
5. Configure backup system to new servers with 30-day retention
6. Test all migrated applications and verify functionality
7. Provide written documentation of new configuration

---

Out of Scope

What won't be done. This is as important as what's in scope.

Example:

• User workstation upgrades (separate project)
• Voice/phone system changes
• Vendor relationship changes with [specific software vendor]
• Training (separate engagement)

---

Timeline

When will things happen? Include milestones.

Example:

• Week 1: New equipment delivered, site preparation
• Week 2: Server installation and initial configuration
• Week 3: Data migration
• Week 4: Testing and cutover
• Week 5: Documentation and stabilization

---

Acceptance Criteria

How do you know when the project is done? Define measurable outcomes.

Example:

• Both new servers are operational and accessible from the network
• All existing data is migrated with verified integrity (checksum match)
• Backup system completes successful test restore of at least one file
• All existing applications function on new servers as verified by staff testing
• Documentation is provided in written form within 5 business days of completion

---

Change Control

What happens if you want something different?

Example: "Any changes to scope must be requested in writing and approved by both parties before work begins. Approved changes will be documented and priced as a change order."

---

Pricing and Payment

Be specific. Not "payment terms net 30"—actual amounts and schedules.

Example:

• Total project cost: $28,500
• Payment schedule:
  • 30% deposit upon signing: $8,550
  • 40% upon equipment delivery: $11,400
  • 30% upon final acceptance: $8,550

---

Assumptions

What are you assuming that's not explicitly stated?

Example:

• Client will provide access to existing systems within 2 business days of request
• Client IT staff will be available for testing during week 4
• Work can be performed during business hours (8 AM - 6 PM Monday-Friday)

---

Dependencies

What does the vendor need from you?

Example:

• Current credentials for existing systems (provided by client by Week 1)
• Sign-off on equipment specifications by [date]
• Access to server room during installation

---

Warranty

What happens if something breaks after the project ends?

Example: "Vendor warrants all workmanship for 30 days from final acceptance. During this period, vendor will repair any defects attributable to installation work at no additional cost."

---

Why vague scopes cause problems

Vague language in SOWs benefits vendors, not clients.

"Network upgrade" could mean replacing two switches or completely rebuilding everything.

"Configure security" could mean enabling a firewall or installing a full security operations center.

"Migrate data" could mean copying files or meticulously transferring every database relationship with zero downtime.

When in doubt, make it specific. "Configure firewall with existing rule set" vs. "configure firewall with rules as documented in Appendix A."

Common problems to avoid

No acceptance criteria. If there's no definition of done, the vendor decides when it's done.

No change control. Without this, every conversation about scope becomes a potential surprise bill.

No payment tied to milestones. Paying everything upfront means you have no leverage.

No out-of-scope section. Without this, vendors can claim anything is included.

No warranty. No recourse if something breaks shortly after completion.

What to do with this

If a vendor gives you a vague SOW: Send them this outline. Ask them to fill it in specifically.

If a vendor refuses to be specific: That's a warning sign. A professional vendor can define their work.

If you're writing your own SOW: Use this structure. Fill in every section.

What it costs

A well-written SOW doesn't cost money to create. It costs time—probably 2-4 hours to write one properly.

A poorly written SOW can cost thousands. Disputes, change orders, incomplete work, and frustration are common with vague scopes.

Questions to ask

Before signing an SOW:

• Can you walk me through exactly what "network upgrade" means in this scope?
• How will we know when the project is complete?
• What happens if we want to add something during the project?
• What do you need from us to meet this timeline?
• What could cause delays, and how would we know?

The bottom line

A good SOW protects both parties. It gives the vendor clear scope and the client clear expectations.

If a vendor can't write a clear SOW, that's information about how they'll work with you. Vague SOWs lead to vague execution, disputes, and frustration.

Don't sign until you understand exactly what you're buying. Then get it in writing.