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 (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.
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
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 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
Incoming Work cannot be Planned, and Priorities Constantly Change
Software Maintenance & Support Teams
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 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.
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
Resources
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?
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?
Conclusion
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.
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.
