A Statement of Work (SOW) is sometimes confused with a Master Services Contract (MSA), and indeed some use the terms interchangeably.
On the other hand, an SOW is an ideal way to scope out a project, especially a complex project, as opposed to an MSA, that details a long-standing services arrangement. (You can read a recent blog of mine on how to craft contracts, SLAs and MSAs.)
Many times a client will specifically require an SOW, so you should be prepared to craft one that suits both parties.
If you already have a contract or MSA with a client, your SOW can encompass some of the same issues and reinforce those bonds.
SOW General Overview
An SOW, being most often project-based, focuses on defining what the deliverables are and when they should arrive.
Just as important, the SOW defines all the milestones that are behind the deliverables and who does what. This requires timetables, a way to review progress, and a means of tying payment to project progress. In addition, all resources critical to the project are defined in the SOW, as well as which parties bear which costs.
There also needs to be agreement on how the project is managed and governed, by what methods, and what defines success or failure. Sometimes these measurements will include KPIs; other times there are other ways to define whether the project is progressing properly and these measurements depend on the scope or style of the project. Some, for instance, may be more infrastructure or network related, while others deal entirely with new services. Obviously these would be measured very differently. For instance, measuring an infrastructure project may require making sure the hardware is installed, configured, has good network performance and security. A service would be judged on whether is properly customized for the client, that end users can exploit the service such as with cloud backup, and that there is confidence the service can meet SLAs.
It may be a good idea to establish a change management procedure to deal with changes in the scope of the project, unforeseen difficulties out of either party’s control, or other circumstances. This way, you have a mechanism to deal with requested changes accommodating both parties.
However, an SOW can’t always cover every aspect of the project. For complex endeavors, there may be a number of related documents and addendum’s to handle details, such as specifications in the case of a software project or contract addendum’s related to service guarantees.
How an SOW Leads to Other Work
Just like a simple contract, MSA or SLA, a SOW is used to measure a service provider’s performance. If you perform well, that SOW is a key sales tool to acquire new business. Not only have you proven you can do the project, you also understand the client and are fully prepared to do more. And you can demonstrate this in a detailed manner by showing how you handled all aspects of the project and prove your top-notch performance.
Legal Aspects
As with a contract or MSA, any SOW should be carefully reviewed by legal counsel. At the same time, the language includes both technical and legal aspects. Since the SOW is a document used by many folks, including managers and other business pros, it should be written using clear, non-jargon language as much as possible. It’s important that the document be comprehensible to all readers, not just lawyers and technical experts. To achieve this, have a literate member of your team or a third party read it for clarity and make the appropriate edits.
Here are some of the legal aspects the SOW should cover.
Intellectual Property
In many cases an MSP will create unique intellectual property for clients, inventions that have market value. This could include techniques, scripts, code and complete software tools. In the section, the client should agree that even though there are rights to usage, you as the creator own these inventions.
Confidential Information
Your business practices, prices and discounts can be just as valuable as your intellectual property.
Your clients should not share this information with your potential customers and especially competitors.
The same is true for the MSP. As a trusted service provider, you are privy to confidential client data and strategies. It is not just in your professional interest, but legal interest as well, to protect this knowledge.
Contract Termination
Termination can harm either side. If you terminate, the client doesn’t get the project or service they may desperately need. For you, you may not get the revenue you counted on and may have trouble recovering sunk costs.
The SOW should determine, for both sides, what is just cause for termination and whether and how either party may be compensated for work promised or delivered at the time of termination. It should establish who owns what property, such as physical hardware, and whether (and by when) this needs to be returned to the true owner.
Some MSP Specifics
The government of the State of Texas works with Managed Service Providers and Cloud Services Providers who help with applications and IT operations. Under a document “How to Write an Effective Statement of Work.” the government offers MSPs advice. One example is particularly germane as it talks about an SOW contract pertaining to core MSP functions.
Here is that example: “Customer desires and vendor provides site monitoring and maintenance that include remote network equipment monitoring and alerting, remote and on-site repair and maintenance, and on-site outage response services in Houston, Dallas and El Paso,” the document reads.
Here is how the responsibilities divide.
- “Customer Roles and Responsibilities
- Site access at all three locations
- Purchase and delivery of network equipment
- Configuration design for all network equipment
- Vendor Roles and Responsibilities
- Respond to network outages in accordance with SLA’s
- Respond to customer requests in accordance with SLA’s
- Provide any network drawing updates as changes occur”
The vendor, or MSP, must:
- “Conduct site inventory and provide updated inventory list and schematics.
- Weekly status reports.”
Texas also requires SLAs as part of the SOW. “Service Levels enable the customer to specify service level expectations for the services being performed. Service Levels may be tied to response times for service, uptime of a network, mean time to repair (MTTR), or similar measures.
- Vendor will respond to outages within two hours of notification.
- Vendor will provide a status within 4 hours of outage notification.”
Texas also has specifics and what is required for it to accept the work and, if these are not met, the state will withhold payment.
- “Conduct site inventory and provide updated inventory list and schematics.
- Weekly status reports.”
Tying payment to work performed is also critical to Texas, and their document details: “Pricing and Payment Schedules/Milestones may be tied to Deliverables as noted above, but may also be tied to completion of phases of a project as long as vendor demonstrates task completion and tracking toward project goal.
Example: Project phases that may generate payments:
- Report of current business practices
- May include personnel interviews, write ups, review of IT platforms, etc.
- Gap analysis report
- This would include the vendor tasks of identifying the end goal of the customer, analyzing current systems and processes, and drafting the gap report.
- Final assessment report”
CompTIA to the Rescue
For many MSP issues, CompTIA is chockfull of resources. In the guide Incorporating a Statement of Work, the organization offers guidance on the fundamentals of crafting an SOW and why you may need one.
Solving Disputes
Like with any contract, a SOW helps protect both parties in the event of a dispute, especially one that seems to be moving toward the courtroom.
“If there is a dispute about a contract, one of the first things a court does is try to understand what the parties intended. The Statement of Work is the place to tell them. Every agreement should have some kind of description of what is being sold, what kind of work will be done, or objectives to accomplish; it doesn’t have to be any more elaborate than the circumstances warrant,” CompTIA argues.
Core Assumptions
CompTIA believes much of the SOW can be based on the information in your original quote, but then you add details about how contingencies are dealt with. “You, no doubt, quoted your price based on what you would do for the customer, what the customer or a third party might do and when or how often. Often these assumptions are based on what you have control over and what you do not,” CompTIA explained.
The group cites the example of onsite repair that should take one day. However, that schedule assumes that you recommended the client keep replacement parts in inventory. If that doesn’t happen that one-day repair can turn into many.
The Larger the Scope, the More Plentiful the Issues
For smaller projects or tasks, a simple contract may suffice. But broader, more complex projects introduce more variables. “Installation raises a number of issues when added to the contract. Turnkey? Time and Materials? Milestone payments? Coordinating contractors? Performing help desk functions injects a separate set of problems,” are some of the issues CompTIA raised. “What packages will you have to support? How much training do their users have? How old is their system? The nature of the customer’s business, and the laws that regulate it, also complicate the equation. Health care and financial business often have significant amounts of customer information that is highly sensitive and potentially damaging if compromised.”
Conclusion
MSPs pour their hearts into the services they provide. At the same time, customers are not always perfect. They can be difficult to deal with, and miscommunication can arise because they don’t understand technology as well as you do.
That’s why contracts such as SOWs and MSAs are so import. These offer legal protection for you in the case of a misunderstanding, and give the client a roadmap to what you provide. They can also be living document which change as you add new or higher level services.
