This Statement of Work example shows how Alex Morgan, PMP, defined the scope, deliverables, and performance requirements for BrightFrame's design engagement in Project Phoenix — a $72,250 website launch managed using the PMBOK Guide 8th Edition. The SOW was the contractual backbone of the vendor relationship: it defined what BrightFrame would deliver, to what standard, by when, and at what price — with enough specificity to prevent disputes and enough flexibility to handle the inevitable iteration that design work requires.

What Is a Statement of Work?

A Statement of Work (SOW) is a formal document that describes the specific scope of work to be performed by a vendor or contractor. It defines the work products to be delivered, the performance standards to be met, the timeline, the location of work, any applicable government regulations or industry standards, and the terms and conditions of the engagement. In PMBOK 8, the SOW is a key input to the procurement process within the Delivery Performance Domain and is incorporated by reference into the final contract. A well-written SOW is the most important document in any vendor relationship: it is what makes the contract enforceable, because it defines what "done" looks like in sufficient detail to be objectively verifiable.

What's Inside This Statement of Work Example

This Statement of Work example for Project Phoenix includes:

• Scope of work: BrightFrame will conduct UX research (competitive review and user persona validation), produce wireframes for all 12 website pages, create visual design mockups in desktop and mobile formats, deliver a Design System (component library in Figma), and provide three rounds of revisions within the SOW price
• Deliverables: five formal deliverables — Design Brief (March 21), Low-Fidelity Wireframes (March 31), High-Fidelity Desktop Mockups (April 7), Mobile Mockups (April 10), Final Design System with annotated Figma handoff (April 14)
• Acceptance criteria: all design deliverables must meet MCG brand guidelines (provided March 14), comply with WCAG 2.1 AA accessibility standards, and receive written approval from Priya Patel (Design Lead) or Alex Morgan (PM)
• Quality requirements: W3C-compliant HTML/CSS structure implied by design; Figma file organized with named layers, reusable components, and developer annotations for spacing, typography, and color values
• Sustainability requirements: designs must be optimized for minimal asset weight (compressed images, SVG icons where possible) to support the PageSpeed ≥90 performance requirement; accessibility-first design approach documented
• Payment terms: 50% ($6,450) at contract signing, 50% ($6,450) upon formal acceptance of the Final Design System; additional revision rounds beyond three are billed at $200/round

How Alex Morgan Used This Statement of Work

The SOW's three-revision-round provision was the most consequential clause during execution. When CR-002 (hero image revision) was raised after the initial mockup used the wrong brand palette, Alex Morgan checked the SOW and confirmed that this was the second revision round — meaning BrightFrame had one more complimentary revision remaining. This prevented any cost discussion with BrightFrame about the revision and kept the relationship professional. The CR-002 change request was raised internally to document the Sponsor-requested change and the associated 1-day schedule impact, but the actual cost to MCG was $0 — because the SOW's revision provisions covered it. This is why SOW specificity matters: a vague SOW would have created a vendor dispute; a specific SOW resolved the question in 5 minutes.

Download and Customize

This Statement of Work example is available as a free download. Use it as a reference to build your own SOW, or start with the blank template and fill it in for your project.

• Download the Statement of Work Template — PMBOK 8 (blank, ready to use)
• Read the article: Statement of Work in PMBOK 8 — Guide and Best Practices

Statement of Work Example: Key Takeaways

The most powerful lesson from this Statement of Work example is that specificity in deliverable descriptions prevents the most common source of vendor conflict: disagreement about what was promised. Alex Morgan invested significant time making the Design System deliverable description precise — naming the exact Figma components, layer organization requirements, and developer annotation standards that would be required for acceptance. When BrightFrame delivered the Design System on April 14, it met every specification on the first submission, with no back-and-forth. That outcome saved at least 2–3 days of revision cycles and kept the Architecture Freeze milestone on schedule. Specific SOWs save time; vague SOWs waste it.

Want to go deeper? The PMBOK Guide 8th Edition is the definitive reference for modern project management. Get your copy and use it alongside these examples to build a solid, practical understanding of every performance domain.