How to Write a Clear and Effective Statement of Work (SOW)
October 10th, 2024
So this post went popular on Reddit and I figured it would make sense to move it to our blog as well...
Every few moons I see a post on "SOW vs SLA", "How to write an MSA", and other Client Facing Document related questions. I wanted to use this post as a springboard on my philosophies on the SOW side and eventually I'll write some more on the other Documents you'd give a client.
Whether you're a one person shop, project manager, or part of a MSP with a consulting arm, getting the SOW right can make or break a project. A clear SOW helps manage expectations, avoid scope creep, and ensures everyone is on the same page from day one. I'm attaching an example completed SOW (and Template) and will dive into the "Why" for each section below.
Example AWS Build SOW Referenced
SOW Template Optimized for TurboDocx
1. Project Overview
Although this is common sense, this section is all about defining what the project is and what the client is asking for. It's essential to set the tone and provide context.
In the example I worked on, the client wanted us to build a web application and deploy it for five franchises. We also outlined that we’d evaluate the potential to expand this rollout to 2,500 franchises in the future.
Key tip: Make sure the overview clearly states what’s included in the current phase and where future possibilities might lead. This helps prevent the annoying "But we thought this was included!" moment and lines you up for future work
2. Scope Definition
Here’s where the magic happens. A good scope definition is clear and concise—it's the cornerstone of your SOW. In my project, we used Scope Tables to outline exactly what was in scope for the deployment, and specified that only the first five franchises were included. I also call out specifics like "3 US Regions" and give brief but concise bullet points on what's included.
But the key takeaway is this: "If it’s not listed, it’s not in scope." Also, you can chop up these Scope Tables into starting points and centralize them for future use. Sometimes, people tie these to SKUs too, however, if you're doing more complicated stuff like Network Appliance Deployments and it's not as cookie-cutter, having a solid starting point that you can maintain is critical.
3. Out of Scope
Again - common sense, but one of the most critical sections of any SOW. It is what you’re not going to do. Seriously, this can save you from so much scope creep.
Here’s a quick look of a few items we marked as out of scope in our SOW:
- Adding any new features to the web app.
- Onboarding more than five franchises.
- Building new AWS infrastructure not mentioned in the Cloud Build Section
- etc..
Pro tip: Be super specific about what’s not included. It helps prevent misunderstandings later and gives you room to negotiate additional services (and budgets!) if needed.
I would argue the next sections are for shops with enterprise styled clients, typically companies with a CIO or a company used to 5 figure+ engagements. I know some of the folks here service large brands and can relate to what I'm saying below..
4. Deliverables
I would argue this is for MS/PS shops that service companies with a traditional CIO and IT Team (similar to what I used to do at Citrix). Clients love to know what they’re getting for their money. In our SOW, we broke down the deliverables by phase, such as:
- Cloud Infrastructure Review Memo – outlines findings and recommended next steps.
- Rollout Strategy Memo - how to go-live smoothly at scale.
- Bug Report Memo – documents issues from the pilot and how to fix them.
Make sure every deliverable is tied directly to the project’s objectives. Vague deliverables like "provide support" won’t cut it.
5. Project Management and Change Control
Projects evolve. That’s why a strong change management process is vital. We used a structured methodology for handling unexpected scope changes. If the client requested changes, we would:
- Confirm the need.
- Outline additional deliverables.
- Estimate the impact on budget and timeline.
This process ensures that both parties agree before moving forward with additional work, avoiding disputes down the line.
Back to regularly scheduled programming applying to everyone:
6. Assumptions
You can't predict everything, but you can prepare. Outline general assumptions that are important for the project to succeed. For example:
- The client will provide all necessary hardware and licenses.
- The client’s team will be available for regular meetings and questions.
- The post-project agreement for ongoing services. In hindsight, I would probably point to the MSA in place.
If any assumptions are not met, this can lead to delays or increased costs. Having these documented gives you leverage if things go off track.
7. Estimated Fees
Don’t forget the financials! We estimated the total consulting fees and laid out clear guidelines for any changes in staffing or scope. Make sure to provide a breakdown of fees based on the project’s phases and possible contingencies.
From /u/SolutionExchange's comment, it's also helpful to point out milestone and T&M billing.
Time and Material:
- Definition: Billing based on actual work performed, tracked through timesheets or ongoing work logs.
- Example: Billing weekly for tasks such as feedback, remediation, or any variable tasks that arise as part of ongoing project support.
- Practical Use: Useful for projects with uncertain scope or evolving requirements, where work effort and time may vary.
Fixed Fee with Milestones:
- Definition: Predetermined fees billed upon the completion of specific project phases or milestones, helping manage cash flow.
Example Structure:
- Phase 1: “Billing $5k upon completion of the ‘Assess Current Infrastructure’ phase."
- Phase 2: “Billing $10k upon completion of the ‘AWS Cloud Build’ phase."
- Final Payment: “Remaining balance billed upon project completion or final milestone.”
Practical Use: Effective for projects with well-defined phases, allowing clients to make payments incrementally as key objectives are met.
Project Closure Clause for Auto-Acceptance:
- Purpose: To prevent project deadlock due to unresponsive clients, enabling project closure and final invoicing.
- Suggested Text: “The project will be considered closed upon the mutual acknowledgment of all deliverables as completed, or, if no response is received, within 4 weeks of work completion. This auto-acceptance clause prevents extended deadlock and allows timely revenue recognition.”
Final Thoughts
A well-structured SOW is more than just a contract—it's a roadmap for success. Always remember to:
- Be explicit in defining both scope and out of scope.
- Include a change management process.
- Set clear expectations around deliverables and assumptions.
I hope this breakdown helps you write better SOWs in your own projects. Curious to other people's thoughts and how they run shop. Excited to see how you can crank these SOWs out in seconds.
Nicolas
TurboDocx
Copyright © 2024 TurboDocx, Inc. The trademarks, logos, and the content appearing herein is exclusively owned by TurboDocx, Inc., and/or its licensors, and are protected. Any unauthorized use or sale or reproduction or distribution, shall attract suitable action under applicable law.