Open Source and Contracts: MSA and SOW, Part II

In the previous article I illustrated model situation when using software requires vendor’s services with particular contracts in place and wrote in more details about Master Service Agreement (MSA). Let’s have a closer look at its inherent part, the Statement of Work (SOW) and why it is important for organizations not to underestimate it.

Statement of Work (SOW)

Statement of Work describes all services and deliverables which customer expects to be delivered to them by vendor. It represents a strengthening of customer’s confidence and trust that they will receive exactly the services and deliverables they expect. This contract defines what is (scope of work) and what is not (out of scope) the subject of services. It usually defines a specific level of support (support level), namely L1, L2, L3, L4. By clarifying all these important aspects, SOW significantly reduces possible risks of unfulfilled expectations or misunderstandings. As a rule, every professional IT services contract includes at least one Statement of Work (SOW). But usually there is more than one of them.

In the form of schedule, SOW includes a clear project plan, specific identification of particular tasks and subtasks as well as estimated time and price.. It defines results of delivered services that are supposed to be the deliverables for customer. It also defines effective period, i.e. duration of the contract, optionally renewal clause consisting of parts like initial term, renewal term and renewal window. You can find here an information about where the contract takes place: realization in an on-site or off-site form and possible arrangements of travel expenses. It usually includes a description of acceptance testing process or acceptance protocol itself.

SOW contains price arrangements according to the nature of the project:

A) In case of project which subject (scope) is not fully determined or identifiable, customer pays the price for the time and materials burned. This is a price determined by estimation, known as a Time & Material. In this case, SOW also contains a tariff with an hourly (Hours in USA) or man days (MDs in Europe) rate. Note: 1 MD represents the working time of 1 person corresponding to 1 working day, i.e. typically 8 hours.

B) In case of project which budget, time schedule and deliverables are clearly specified and the subject (scope) of the project is fully
determined or determinable, customer pays a fixed price. In this case, SOW contains the so-called invoicing calendar, which means that smaller financial amounts are paid gradually after reaching individual milestones of the project.

In addition, reaction time, known as a Response time, is also covered in SOW. Its purpose is to ensure the vendor is dealing with reported error or defect. In connection with that, there is usually used term 8x5xNext Business Day which does not mean the time of elimination of the error or defect (known as Repair time) or service emergency time called SLA 24/7.

MSA and SOW are two types of contracts forming one big unit. Their purpose is to define individual legal relationships between vendor and organization requiring expert support services or feature development when using vendor’s open source software. They also help to avoid misunderstandings and state scope of work. As I illustrated in these two articles, the contracts have their significant meaning even in case of open source software. OSS is naturally free of charge, but the effort of experts providing the services has to be evaluated. Only this way open source can stay flexible or secure and survive to be the future of technologies.

 

Resources

Tollen, David W. (2010): The tech contracts handbook: software licenses and technology services agreements for businesspeople and lawyers. ABA Publishing, ISBN: 978-1-60442-982-4.

Overly, Michael R.; Karlyn, Matthew A. (2013): A guide to IT contracting: checklists, tools and techniques. CRC Press, ISBN: 978-1-4398-7657-2.

Lindberg, Van (2008): Intellectual Property and Open Source: A practical guide to protecting code. O’Reilly Media, Inc., ISBN: 978-0-596-51796-0.

Meeker, Heather (2015-2017): Open Source for business: A practical guide to Open Source Software licensing. ISBN: 978-1-54473764-5.

Fogel, Karl (2005-2010): Tvorba Open Source Softwaru: Jak řídit úspěšný projekt svobodného softwaru. Edice CZ.NIC, ISBN: 978-80-904248-5-2.

Leave a Reply

Your email address will not be published.