SOW VS. MSA
What issues are generally addressed in the Master Services Agreement (“MSA“) and what issues are addressed in the (“SOW“). There is no hard and fast rule here, but remember the MSA is a broadly focused corporate position addressing how they generally expect to contract for Services. The SOW is the exact opposite, it is a custom developed description of how a specific Project will be delivered, and as such it includes a great deal of detail about the specific Customer’s facility, departments and the people that are specific to the Project. So where the MSA might call for periodic status reports the SOW might designate the Project Manager for both parties and designate who is responsible for producing the Status Reports, perhaps a day of the week they will be held, a specific time for the Project Status calls, the requirement for a formal follow up Project Status Report (to reflect the minutes of the meeting) and a time in which both parties must review and respond to the draft minutes that are circulated for comment. Again there are no hard and fast rules so if some of that process is a Customer or Consultant standard i.e. Weekly Status Reports, with 3 days to review and approve the minutes, that could be covered in the MSA; whereas other Customers might be scant on that in the acceptance process detail in the MSA and rely upon the project terms in the SOW to define all of those Project Status reporting process details.
Depending upon the circumstances, and the importance of the installation to the Customer’s operations you may agree to expedited escalation measures that you would not ordinarily agree with; i.e. if the Project was to remediate a compliance issue shorter cure periods might be appropriate. In the same way, your acceptance process might be non-standard. The purpose of the SOW is to help fill in all of the detailed specific facts pertaining to your project assign specific people to specific roles define variables like the Customer’s Executive sponsor assigned to the Project.
In most Consulting Ser v ice Projects the Consultant has access to the Customers Data, that data will likely include Personal Identifiable Information (PI) of employees and vendors, perhaps Personal Credit Information (PCI) or perhaps Personal Health Information (PHI). The Customer is obligated to ensure that from a com p l i a n ce p er s p ecti v e to en s u r e th a t information is adequately protected as required by regulation. In addition, if the Consultant has access to the Customer’s network they are also required abide by the Customer’s network security policies. It is essential that the Customer’s flow through these obligations to the Consultant. Conversely, the Consultant has certain duties with regard to their suppliers, some license carry specific obligations that they need to ensure the Customer will abide by. Constructing appropriate SOW flow–through obligations represents a very important part of most Consulting Service Projects and typically those details cannot be adequately defined at a corporate level, they are more facility and project specific.
The SOW uses the MSA as a backdrop and then builds upon that to bring your project delivery plan to life. The SOW adapts the general consulting services terms to the specific circumstance of the Project, as a result the issues you tend to deal with in a SOW are focused on the Project specific level of detail, rather than trying to alter the general terms on the MSA at the transactional level. SOW terms generally should “supplement” rather than amend the MSA terms, often the MSA stipulates that in order to override the MSA terms it must be specifically called out (and amended by section/issue first acknowledging it is an exception to the MSA) in the SOW otherwise the MSA prevails in the order of precedence. As a result, assumptions that are specific to a particular project would be defined in the SOW; therefore general expense guidelines might be stated in the MSA, but when you plan the project details project specific variances might be added within the SOW like approval for a specific short term residence facility. When a contract proactively defines the project environment, the parties expectations, project assumption, the project acceptance test, it reflects a thorough understanding of the Project requirements. That preparation sends a positive message about the skills and professionalism of the Consultant, or if you are the Customer, it demonstrates a detailed understanding of the task at hand. The process instills a level of confidence for both parties, which helps establish loyal business relationships; i.e. you are prepared to execute on the project delivery.
We represent buyers and sellers of IT products and services, Cloud based SaaS offerings and software licensing matters. If you or the organization you work for is tired of trying to develop, negotiate and/or modify consulting contracts, licenses, SOWs, HR Agreements, and other business related financial transactions, please contact me for a free consultation.
Take advantage of a 30-minute free consultation to review a SaaS agreement, highlight anything important and/or provide the extra assurance of adequate protection. Users may be surprised at the errors and/or omissions that occur within most standard SaaS license agreements.