December 4, 2020

Technology Contracts Master Services Agreements & Statements of Work

We are an IT company in US and want to help businesses with agile software development and scrum software development. Learn how a Master Services Agreement works.

Executive Summary

Technology contracts can often be difficult to understand and include a lot of specialized technical terms. The intent of this article is to help you understand the common things to look for and avoid when negotiating Professional Services Agreements. There are normally two components when negotiating with a Vendor that involves or includes Professional Services.

  • Master Services Agreement (MSA)
  • Separate Statements of Work (SOWs)

In this blog article we will cover both.

Master Services Agreement

Master Services Agreement (MSA)

The Master Services Agreement (MSA) is the controlling Contract and contains all of the standard Legal Terms & Conditions, which describe the agreed upon business relationship between the parties. It is very important that the MSA include all of the Legal Terms & Conditions (T&C’s), and that any subsequent Statement of Work (SOW) references the MSA. This is important for both Parties, as you don’t want to have to keep renegotiating the T&C’s every single time you want to start a new Project.

MSA Needs to Include

  • Agreement Term
  • Term Length - how long does this Agreement stay in force
  • Renewal of the Term of the Agreement
  • Termination Conditions:
  • Breach Conditions
  • Ability to Cure
  • For Convenience
  • Notification Period
  • Payment for Services
  • Payment Terms - i.e. Net 30, Due upon Receipt, etc.
  • Late Fee Charges for late payments
  • Intellectual Property & Warranty of Work
  • Ownership of Intellectual Property and Resulting Work
  • Granted License for any IP the Vendor Incorporates
  • Warranties
  • Mutual Idemnification
  • General Conditions
  • Non-Solicitation
  • Non-Disclosure of Proprietary Information
  • Assignment Clause
  • Legal Jurisdiction and Dispute Resolution Process
  • Force Majeure Events
  • Process to Modify this Agreement
  • Survivability Clause - what remains in effect, if the Agreement is Terminated for any Reason

Considerations within an MSA

Intellectual Property (IP):
  • Client Perspective
  • To the extent possible, you want to “own” as much of the Solution as Possible. This is known as a “Work Made for Hire.” This allows you to avoid future license fees or complications.
  • If the Vendor includes any 3rd Party Applications or even their own IP (such as previously built Vendor Controls or Code) within the resulting Solution, you want to make sure that you have a World-Wide Perpetual Irrevocable License to this technology. You don’t want to be hit later with a “Surprise” bill or worse a lawsuit.
  • If the Vendor does include their own IP, make sure that you get access to the Source Code, so that you can maintain it in the future, if needed.
  • Vendor Perspective
  • Commercial Software Implementations:
  • If you are selling your Client an actual Product (Software License), this should be covered under a separate Software Licensing Agreement.
  • The MSA, should only focus on the Professional Services involved with the implementation of your (or a 3rd Party) Commercial Software.
  • Example: a Professional Services Vendor implementing PeopleSoft ERP for a Client.
  • Custom Software Development:
  • In most cases this will be done as a “Work Made for Hire,” where you do not own the resulting IP or have any rights to it.
  • However, you may want to try and negotiate the ability to use certain generic UI Components / Controls, Integration Services, etc., which could be applied to other Solutions.
  • By doing this, it builds up your Library of potential reusable Components for Solutions with other Clients in the future.

What the MSA Should NOT Include

  • Resources - Who, How Many, Skill Set, etc.
  • Billing Type & Rates:
  • Time & Material
  • Blended Monthly Rate per Resource
  • Fixed Bid / Fixed Time
  • Billing Schedule
  • Weekly, Monthly, etc.
  • Milestone Based
  • Performance Bonus and Deductions
  • Project Estimated Timeframe or Schedule
  • Total Estimated Costs
  • Key Milestones
  • High Level Requirements
  • Project Assumptions & Known Risks

All of these should be included within the various Statement(s) of Work. The reason for doing this is that every Project is unique and will vary. The MSA should be relatively stable or fixed, while the SOW’s can vary greatly.

Master Services Agreement

Statements of Work (SOWs)

Statements of Work (SOWs) are documents that focus solely on what work is to be performed, by what resources, any project assumptions / requirements, and pricing information. It should not include any contractual T&C’s, like payment terms, etc. The SOW should reference the MSA as the controlling document for all T&C’s, because you do not want to accidentally replace T&C’s previously negotiated within the MSA.

Statements of Work (SOWs) Include

Project Management Methodology & Tools

This is a common area of negotiation for both Parties. Do you want to use the Vendor’s model, or do you want to use yours?  

Common Considerations

  • How advanced is the Software Development Lifecycle of both Parties?
  • How often does the Vendor have Cost Overruns in their Projects?
  • How frequently does the Vendor deliver on Time?
  • And the Client should answer these same questions.
  • What Project Management Tools are in place for both Parties?
  • Bottom Line:  you will want to pick the best approach for the Project.

Traditional Waterfall / Predictive Methodologies

  • Most common PM methodology, as it is easy to understand.
  • Assumes that little or no change will occur during the course of the Project:
  • When Changes do occur there is a very formal Change Order Process
  • And typically additional Fees
  • Requirements must be fully defined, before design can start, design must be complete, before coding starts, etc.
  • This is a “Push” method of manufacturing software.
  • The Variables in the Project are:
  • Time
  • Resources
  • And change in the Scope of the Project will affect these

Agile Methodologies (Scrum, Scrumban, Kanban, SAFe)

Modern Software PM Methodology:

  • Developed in the 1990’s
  • Based on Lean Manufacturing techniques (Toyota, et al.), using a “Pull” model of Software Manufacturing
  • Assumes that Change will occur during the course of the Project.  This is expected, can be planned for, and is perfectly “OK’.
  • Large Projects:
  • Typically broken into separate Phases
  • The First Phase will have the best analysis and estimate
  • Subsequent Phases will be less well defined, as Changes are expected based on the completion of Phase I, etc.
  • What is Fixed:
  • Time Frame - typically this will be broken into 2-week Sprints, with a Phase containing multiple Sprints
  • Resources - during the course of a Sprint, the Resources are Fixed.  They can vary from Sprint to Sprint during the course of a Phase.
  • Very Team Oriented:
  • It is always best if the Client and Vendor have any Resources who are working on the Project work together as one single Team.
  • Alternatively, in very large Projects, you would break the Teams down by function or module that they are working on, regardless of Organization.
  • User Stories:
  • This is a general term which describes a small Requirement in enough detail for the Developer assigned to work on it.
  • Even though the term is “User Stories”, these often include Stories where the User is actually a System.
  • Description:  As a User or System, I need to be able to do this, in order to achieve this business value.

When to use Scrum

When to use SCRUM

  • When you are able to Plan your Work in Advance for a 2-Week Sprint
  • New Software Development
  • Creating a New Module for an Existing Application
  • Refactoring a Component within an Existing Application

When to use Kanban

When to use Kanban

  • Incoming Work cannot be Planned, and Priorities Constantly Change
  • Software Maintenance & Support Teams

When to use SCUMban

When to use SCUMban

  • This combines both SCRUM and Kanban
  • Useful when the Team can operate in 2-Week Sprints, but there are Changes during the course of the Sprint:
  • Client changing their mind on a given Requirement
  • Client replacing one Requirement with a different Requirement
  • Development Team changing a Technical Approach

When to use scalable agile framework

When to use SAFe (Scalable Agile Framework)

  • Once the Project Team Size reaches a certain level, it becomes very difficult to be able to complete any of the Team Meetings within a reasonable period of time.
  • Typically one will start to run into this problem, somewhere between 12 and 20 Team Members.
  • If your 15 Minute Daily Standups start consistently taking 25 or 30 minutes - it’s time to break the Team into 2 (or more).
  • Once you do this, you will also need to create a Scrum-of-Scrums, where the Scrum Master and Business Analyst (a.k.a. Product Owner) of each team have a Daily Standup with the overall Program Manager to solve any issues or problems.

Master Services Agreement
Project Scope & Assumptions

At a minimum the SOW should include the following:

  • Project Scope (High Level)
  • Keep this fairly High Level within the SOW
  • The “Scope” can include a wide variety of Major Items:
  • Requirements Analysis\Solution Design
  • Solution Design
  • Development of Modules
  • Integration Efforts
  • Data Conversion
  • Pilot / Beta Support
  • Go Live Support
  • Etc.
  • Each High Level Scope Item should include a short paragraph to describe what this is.
  • Assumptions / Identified Risks
  • Here you want to identify any key Assumptions that are being made
  • As well as any previously Identified Risks to the Project

This section should at a minimum contain a list of the Number of each type of Resource, the Type of Resource, and Rate Information.

Example Blended Rate Model:

Role  |  Quantity  |  Rate

Scrum Master (PM)  |  1  |  $ ##### per month

Business Analyst (Product Owner)  |  1  |  $ ##### per month

Technical Lead  |  1  |  $ ##### per month

Software Developers  |  3  |  $ ##### per month

QA Engineer  |  1  |  $ ##### per month

Example T&M Model:

Role  |  Quantity  |  Rate

Scrum Master (PM)  |  1  |  $ ### per hour

Business Analyst (Product Owner)  |  1  |  $ ### per hour

Technical Lead  |  1  |  $ ### per hour

Software Developers  |  3  |  $ ### per hour

QA Engineer  |  1  |  $ ### per hour

In addition, one of the items that needs to be identified on the SOW, is the Approval / Removal of Resources from the Project Team. This should cover the following:

  • Does the Client have the right to:
  • Review Resumes
  • Interview Candidates
  • Approve of Assignments to the Team
  • Remove Members from the Team
  • Does the Vendor have full control over their Staff assigned to the Project?

Scrum Master
Billing Information & Invoicing

At a minimum the SOW should include the following information:

  • Bill To Address Information (or A/P eMail Address)
  • Frequency of Invoicing for the Project
  • Time Based:  Weekly, Monthly, etc.
  • Milestone Based:
  • X % billed at Project Start
  • Y % billed once Milestone A is reached
  • Etc.
  • Any Performance Metrics - this is more typical with Government contracts
  • Bonus for Finishing Early
  • Penalty for Project Delays
Change Orders

Change Orders occur in many Software Projects, as it is difficult to accurately predict all of the requirements at the beginning of the project. In addition, assumptions that both Parties make at the beginning, may prove to be inaccurate, sometimes in substantial ways. A Change Order in many ways, simply becomes another SOW attached to the Parent SOW.  Again, all T&C’s should be referenced back to the controlling MSA.

Vendor’s Perspective - using an Agile Methodology:

  • When using an Agile Methodology where you expect change, there are several ways you can handle Changes.
  • Yes, we can Add this X Point User Story (Requirement) to the Project.  And as the Client what X Point User Story do you want to Drop?
  • Define an overall “Buffer”, which you allow Changes up to this amount without charging extra for.  
  • For example, if the Project is estimated to be 400 total Points and you add a 20% buffer, this means Changes up to 80 Points in addition to the 400 Points are expected and included in the Project.  Beyond this amount, you would need to negotiate a Change Order.
  • For very large Changes, you may need to go straight to a Change Order.
Acceptance Criteria

This is critical to define, as both Parties need to know when the Project is DONE.

Items to Include:

  • What is the Definition of the Project being Done?
  • Who from the Client’s side signs off on the Project Completion, thus Accepting the Work?
  • Project Warranty Period:
  • Is there a Project Warranty Period, where some (but not all) of the Team Members are available to handle Defects or Bugs that are found in Production after “Go Live”?
  • What is the length of this Project Warranty Period?
  • Is the Rate Structure different during this period of time?

Software Development Project Warranty Period


Make sure that all of your Legal Terms & Conditions are included in your Master Services Agreement. Never include these within an individual Statement of Work or Change Order, as it will cause problems if there is a dispute. Likewise keep all Project Based Information within the Statement of Work or Change Order. You do not want these to be in the MSA, as they can (and probably will) change frequently.

We hope that you have found this Blog Article helpful and useful.

Thank you, David Annis.

Case Study from Arkusnexus
David Annis
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
RSS feed
Subscribe to our feed
Back to More ContentMore From this Author

3065 Beyer Blvd B-2
San Diego CA 92154 - 349

mind hub tijuana