When working with a Client or Vendor, you’ll usually find 4 types of contracts:
Non-Disclosure Agreements (NDA)
Master Services Agreements (MSA)
Statements of Work (SOW)
Change Orders (CO)
You might encounter these as multiple documents or they might be consolidated into a single one. The image at left summarizes how contracts flow. It all starts with an NDA and then an MSA. MSAs can have multiple SOWs, and each SOW can have multiple Change Orders.
As a software manager, I strongly recommend becoming familiar with contract language and staying involved throughout the contract negotiation. Many red-lined versions will go back and forth between your two companies. It’s in your best interest to understand what these contracts are about and what you are signing up for, whether you are on the Client or the Vendor side.
/ / Key Watchouts
1. Stay involved: DON’T leave contract negotiations exclusively to Legal or (worse) to Sales. They have different incentives than you do. And at the end of the day, you’re the one on the hook to deliver or receive what was agreed upon.
2. Are you authorized to sign? Keep in mind that contracts are legally binding documents between two companies. Often, only a few people within an organization are legally authorized to sign contracts. So unless you have signature power within your organization, you should never sign a contract or any legally binding document. You could get yourself or your company in trouble.
Contract negotiations are usually tough, take a long time and they can make or break a project. In general, everything in life is negotiable, but the bigger company usually has the upper hand. If you are the Client and work at the bigger company, chances are you’ll be able to get away with a lot. Vendors will bend over backward to accommodate your needs and get your business. On the other hand, if you are a startup or smaller company and would like to work with a big established Vendor, then chances are, you won’t have a lot of leverage. Regardless of the situation, negotiation is key.
In a nutshell, here is what each contract covers, and key watch outs for each:
Non-Disclosure Agreement (NDA)
An NDA is an agreement between a Client and Vendor to not disclose proprietary information with anybody outside the company. As a Client, you’ll probably want to sign an NDA before you start sharing too much information about your product/project with a Vendor, and it’s common to sign NDAs with multiple Vendors before making a final selection. That way you’ll be able to share more information and get more realistic bids.
// Key Watchouts
1. Unilateral or mutual? NDAs can be mutually or unilaterally binding, meaning either one or both companies is prohibited from sharing the other’s info. No matter which way you go, the important part is to make sure you and your company are on the protected side.
2. Company or individual? Make sure that the NDA binds the company and not the individual employee. If you are the Client, you need the certainty that nobody on the Vendor side will divulge your trade secrets. If you are on the Vendor side, it’s a good idea to make sure nobody on the Client side can talk about your procedures and your “secret sauce”.
Master Services Agreement (MSA)
An MSA (a.k.a. Master Contract) defines how two companies will do business together. It is an umbrella contract that governs every SOW you undertake together. The MSA includes very important things like: payment terms, who owns the intellectual property (IP), marketing rights, limitations on liability, how to solve disputes, no solicitation of employees, warranties and so on. Very involved legal stuff. And chances are, both Client and Vendor side will have an MSA template they’d like to use. Which template to use is just the beginning of the negotiations. MSA negotiations can take weeks if not months. Make sure you account for this delay in your project roadmap or schedule.
// Key Watchouts
1. Ownership of IP: A key negotiation point is who owns the intellectual property created during the engagement. Some Vendors release all IP to the Client, while others just give a “perpetual license” but keep the rights. This allows the Vendor to take whatever they built for you and resell or reuse with other Clients. Make sure you understand your company policies and decide whether this clause is a deal-breaker.
2. Payment terms: Cash flow is important. As a Client, you’d like to pay as late as possible, but as a Vendor, you’d like to get paid as soon as possible. The standard terms I’ve seen are “net 30”. If you are on the Vendor side, keep in mind that the term starts counting from when the Client receives the invoice, not from when you sent it out. So “net 30” is really more like “net 35”, and that’s if they pay on time. Make sure your cash flow can take those hits. On the other hand, you can negotiate for shorter payment terms, for example “net 10” or “due on receipt” in exchange for a discount or other concessions. Everything is negotiable.
3. Marketing rights: For many Vendors, the ability to add a big name to their portfolio is invaluable. Many Vendor MSAs include a clause stating they can use the Client logo or advertise that they worked on a specific Client project. However, many Clients consider their chosen Vendors to be a strategic advantage, so they want to keep them secret and don’t allow for this clause. A common negotiation is to agree to a joint press release in exchange for a discount or better payment terms.
4. Non-Solicitation: MSAs usually include a clause to prevent Clients from hiring the Vendor employees. This is a way for the Vendor to protect themselves and keep the Client coming back for more. As a Client, if you really want to hire a person (and they want to come work for you), then you need to openly negotiate it with the Vendor. If you proceed without written permission from the Vendor, you might have a lawsuit coming your way for breach of contract.
5. Limitation of Liability: Usually, this clause states which side is responsible if the Client gets sued for work done by the Vendor. Some big companies have brutal liability clauses. For example, they might claim that the Vendor is liable in case the Client is sued by another company for patent infringement even if the Vendor had no idea about those patents. Basically it’s just a way for the Client to deflect all blame and use the Vendor as a scapegoat. This type of clause can bankrupt a company, so make sure you understand all the risks before signing. Possible solutions include modifying the language to add more protection for the Vendor and/or buying liability insurance that will be valid a certain number of years after the engagement is over. If buying insurance is the agreement, then it must be specified in writing in the SOW and the Vendor must show proof that they, in fact, bought that insurance.
Statement of Work (SOW)
Once the companies have agreed on an MSA (a.k.a. they agree how to work together), now it’s time to negotiate the specifics of the actual project. Each project will have its own SOW, but they all fall under the same MSA. Basically, the MSA defines the “how” and the SOW defines the “what” of the work.
The SOW defines, in detail: the deliverables, timelines, price, invoicing schedule, conditions and assumptions for any particular project. If you are on the Client side, this is what the other company is legally agreeing to deliver to you. If you are the Vendor, the SOW is what you are committing to deliver. Depending on your type of engagement, the SOW type may vary. The most common variations are:
Time & Materials: Client pays Vendor for a certain number of hours of work. Client has to cover any overage incurred to complete the desired deliverables. (see part 2 of this series)
Fixed Price: Client pays Vendor for specific deliverables. Vendor has to cover any overage incurred to complete the deliverables. (see part 3 of this series)
Retainer: Client pays a monthly fee in exchange for unlimited (or loosely limited) services. (see part 4 of this series)
Staff Augmentation: Client temporarily adopts a Vendor employee into their team. (see part 4 of this series)
Recommended post: Internet of Things: A Primer for Product Managers.
Change Order (CO)
As part of the MSA, companies often agree to a change management process, which includes Change Orders (a.k.a. Change Request Order). Change Orders document any changes in scope, budget, timeline, assumptions or any other deviation from the current SOW. A particular SOW can have many change orders. Once a CO is signed, the corresponding language in the SOW is no longer valid, and the CO becomes the new legally binding agreement for that part of the contract.
In general, change management is difficult to track. Often companies refrain from doing Change Orders because they fear the project will slow down until the companies finish negotiations. Don’t be discouraged by this. It is very important to document every change and have the matching contracts to back you up.
//Key Watchouts
1. Keep it in writing: Handshake agreements are often a recipe for disaster. Doesn’t matter how big or small of a change, I strongly recommend creating a Change Order to document the new agreement. As a Vendor, I’ve been burned a few times by having handshake agreements and then having the Client side stakeholders change. Yikes! The new stakeholders didn’t recognize our agreements and wanted (rightfully so) to go strictly by what was in the contract. Can’t tell you how much trouble that was…
2. Be clear and explicit: COs (and any contract) should have little room for interpretation. Make sure the changes are quantifiable and deliverables are clear.
3. Zero-dollar CO: Not all COs have to involve money. It’s common to do “zero-dollar change orders” meaning that the change is in schedule, assumptions or content of the deliverables.
4. Bundle changes: If your company is too slow to sign contracts, you might save time by bundling many changes in a single Change Order.
Recommended post: A Product Management Framework for the Internet of Things.
The Bottom Line
Contracts are a complicated part of software management, so it’s important to get a basic grasp on them. The most important piece of advice is to make sure that all assumptions, deliverables, timelines etc are clearly stated in your contracts.
Avoid handshake agreements or additional comments in emails or other documents. Contracts are legally binding documents, and you want to make sure everything is in writing while the relationship with the Client/Vendor is still in good standing. If a problem arises, companies go with what’s on the contract. If it’s not there, you have no leverage at all.
So where do you go from here?
Now that you know the basics, it’s time to dig deeper into each type of contract:
Part 2: How to Negotiate Time & Materials Contracts
Part 3: How to Negotiate Fixed Price Contracts
Part 4: How to Negotiate Retainer & Staffing Contracts
30 Comments
-
Hi Daniel,
Excellent, concise article! I understand these are, legally, the 4 different types of “contract” but, sometimes, I see “contract” used in contrast with an “MSA.” Is MSA a type of contract or can you have one but not the other? Is it possible to not have an MSA but have a contract that includes an SOW and that becomes the binding agreement between client and vendor? Or is it the same thing called differently?
I hope this makes sense! I’ll definitely be browsing the rest of your site later to gain a better understanding. Thank again.
-
Hi, is there a difference bw a contract worth authorization vs. a master services agreement? ISnt it basically the same thing?
-
Thank you! Nice Article. can you please explain where purchase order(PO) fits in this diagram.
-
Hi Siva,
POs usually come after the SOW is signed. Each company is different. Some companies will issue a PO for the amount of the SOW and they’ll ask you to refer to the PO number when you submit an invoice. Other companies won’t issue a PO and you can simply refer to the SOW or even the Change Order number when invoicing.Hope this helps,
Daniel
-
-
Hi Daniel – Nice article. Some of the comments lead me to believe you may have made this more complicated than necessary though by referring to the Contract (aka Master Agreement) as an MSA. Personally, I leave the term MSA to guide services contracts, which may be for a variety of implementation and consulting work on-site/remote. In this day and age, the MSA may also apply generally to a SaaS offering – since that really is just another type of ‘service’.
For licensed software (perpetual or term), the Master Agreement is term I am more familiar with but I have heard plenty of people use MSA interchangeably with this term despite the “Services” piece not being part of its content. A separate services agreement, which can be an MSA, should be written. License and Services should be kept separate as a best practice.
For software companies trying to save cost and time, I strongly advise that all business terms are negotiated before getting a contract started. This is effectively what an LOI is, but often, firms expect these to go through legal review too. So instead, sales exec and customer sponsor should simply exchange verbal and then written non-binding agreed business terms for the agreement. If these aren’t settled before getting expensive lawyers involved (especially for small firms paying outside lawyers by the hour) you will find yourself wasting a lot of time and money.
-
Hi,
Thanks for the really useful article. We’re a small tech co with a SaaS product but our potential client is trying to get us to sign an MSA which assigns all IP writes to them. I don’t think they understand that we’re not creating anything for them.
I sense an expense legal bill…
-
Sometimes, customers will say that since they are giving you the configuration instructions, that is their IP. To some degree it makes sense and they don’t want you sharing any proprietary info or profitting from their configurations if you reuse what you learn from them.
The argument back is two-fold:
1) If the configurations you implement cannot exist without your underlying SaaS offering as a platform there is no value to their “IP” argument. They cannot take this configuration and make use of it anywhere else but on your platform, making it have no value.2) The data, should be considered theirs. No question. However, configurations that may have industry value should be shared. You need to demonstrate to the prospect that they benefit from best practices and product enhancements built-in to the product at the request of other customers too. If they do not want these benefits than they should build a proprietary product or pay someone to do that — missing out on all the benefits that a standardized vendor offering provides.
-
-
If you have a standard MSA template, how long does it usually take to negotiate and execute from start to finish? I want to know how much billable time I should expect someone to charge toward this.
Thanks!
-
Thanks for your comment Jay. There’s really no standard time for contract negotiation. The same MSA template might take one day with one client and 2 months with another. It really depends on what the other company deems important to correct and negotiate. Usually, the time companies put towards getting an MSA signed is considered part of Sales or Business Development. Clients don’t expect to be charged billable time for this since they are not getting the value yet.
-
-
Good info. Lucky me I recently found your blog by chance (stumbleupon).
I’ve saved it for later! -
Hi Daniel,
What is a 0$ SOW? And when is that used? I was readying your explanation for LOI. Is LOI similar to 0$ SOW?Also what kind of SOW do I submit as a vendor in case of a pilot project? and how do I handle changes in SOW due to delay in project for dependencies on client? and delays from the vendor side?
Can you please help explain these.
Regards,
Sharma-
Hi Sharma,
An LOI can come even before an MSA/SOW to let the vendor know that the company is serious about doing business but they are slow at getting the contracts signed. A $0 SOW implies there is an MSA in place and its purpose is to document work your company agrees to do at no charge, but you still want to keep legal record that it happened. $0 SOWs can be used for new projects, but if you want to make a concession on an existing project (one that has an existing SOW) it is more common to do a $0 change order.Changes due to delays (or other things), need to be handled based on the initial agreements included in the MSA. You don’t want to be negotiating what to do with delays once you are already in one. You need to agree that upfront in the MSA. The usual way to handle it is by having clear language stating what happens in each scenario, for example, any delay of X days from the customer, will result in delays on your end of Y days, or will result in penalties of X% of the SOW value, or will result in a change order, etc.
Hope this helps,
Daniel
-
-
Hi Daniel,
This really helped.Can you please explain about the whats whys and whens of a RFPs ( request for proposal)?
Thank you very much
-
Hi Sharma,
I’m glad my article helped you. RFPs are used when bidding for a big project. Big companies or government entities usually can’t select a vendor at will. Their processes require them to launch a “competition” where they evaluate multiple vendors. As part of this competition, they issue an RFP so whoever wants to bid can provide the necessary information to be invited to the negotiation table.-
Hi Daniel,
Thank you for the explanation. That helps.
So does the RFP involve the SOW or is it vice-versa? Or are they both independent? and is there any order in which they are executed?Regards,
Sharma-
The RFP comes first since companies are evaluating potential vendors. Once the vendor is selected, then you go into contract negotiations starting with an MSA and then an SOW.
Best,
Daniel
-
-
-
-
Hi Daniel,
Thanks for this article, it has given me a lot of confidence in dealing with MSAs. I’ve recently started up my own LPO and thanks to you for your guidance, indeed the article is very helpful.
God bless you
-
Excellent Article! I am a fresher in an Organisation, and I was able to interpret this easily. Thank You very much..!
-
Thank you. I’m glad you found it useful.
-Daniel
-
-
I am an architect accustomed to very different contract terminology than that of the tech world. This is an excellent explanation – one of the very best I have read about any of the many types of contracts I have encountered in my 40 years of practice. Thank you Daniel for sharing it. Clear, Crisp, and Concise. Great Job!
-
Hi Peter,
Thank you for your kind words! I’m really glad the article was useful.-Daniel
-
-
very nice write up.. thanks daniel
-
Glad you liked it. Thanks for reading!
-Daniel
-
-
good one
-
Fantastic article. It’s informative, concise, and well-written. You have no idea how long it took me to find a simple and one-stop article to explain these component parts. Thank you!
-
Thank you Evan! I’m glad you found it useful.
-Daniel
-
Are you there? I have a quick question re MSA vs. SOWs. If there’s a conflict in terms, shouldn’t the SOW generally control?
-
Hi Aaron,
In my experience, the MSA is the one that prevails. Once the MSA is signed, then you can have multiple SOWs under that same MSA. All the SOWs are governed by the MSA. In situations where there are conflicts, I’ve seen both parties go back to the MSA and update that. The modification now applies to all SOWs, not just the last one.Ultimately, I recommend you get your legal team involved to avoid any issues. Our responsibilities as Product Managers is to raise these issues, but it’s important to get proper counsel if we find discrepancies.
What has been your experience?
-Daniel
-
Hello Daniel
I did not know so much about contracts but after reading your post I can proudly go back to my manager and say that I understand all the these terms.
Can also explain LOI and where will you put this in order.
-
Hi Mohit,
Thanks for your comment. I’m really glad you found the article useful.Good question about LOIs! A Letter of Intent (LOI) is a document that formalizes a “hand shake” agreement between two companies. It doesn’t have the legal weight as other contracts. As the name implies, it just shows “intent” of two companies to do business.
A common use of LOIs is to accelerate the start of a project. Usually, the person contracting the service (i.e. a Product Manager) has a tight deadline and she can’t wait for her legal or procurement department to turn around the final contracts. In that case, she might ask the vendor to start the project “at risk”, meaning without a signed contract with the promise that “the contracts will be done soon”.
Understandably, the vendor will be hesitant to start the project without a signed contract, so they ask for an LOI to at least know that the company is serious about contracting with them. When vendors accept an LOI, they are baring all the risk because they’ll be putting resources into a project before closing the deal.
If you are a buyer, you can use LOIs to your advantage to accelerate the start of your projects. Just make sure your company is really planning to go through with the contracts. Otherwise, it’s better to wait for the full contracts to be signed. If you are a vendor, you can use this tool to secure a client and meet your revenue goals. Just understand that the customer might back out of the deal or they might come back with terms that you don’t agree to.
Since and LOI can signal the start of a project, it usually comes after an NDA.
Let me know if this helps,
Daniel
-
-
-
-