In an earlier post in this series, I shared some thoughts from Jeff Gordon, author of the Software Licensing Handbook, about how companies can mitigate risk in their vendor supply base when software providers are acquired. In this post, I'll share some of Jeff's suggestions from the acquirer's perspective when it comes to doing diligence on the health and safety of a vendor's contracting agreements and customer relationships. Take it away, Jeff.
"Jason, here are my thoughts, in no particular order, that I would suggest to software companies in the process of analyzing and doing due diligence on potential acquisitions. Let's begin:
1 - The easiest way to see how a traditional software provider is doing (relationship-management wise) is to check their maintenance roster. See how many customers are on it ... how long they've been on ... and look for recent quantities of drop-offs. In other words, you're looking to see if the rats are leaving the ship before the people. (Looking at maintenance is also a good way to get an idea of what the company's revenue is going to be, but that's outside the scope of what you asked.)
While digging around in maintenance records, I would also be interested to see their bug-tracking database -- again, it's really a relationship management issue to see how they treat their customers who call in and ask for help. If you find that they don't have any great method for tracking issues and problem resolution, then you can bet that you have a group of unhappy customers whose problems are either not getting solved, not getting solved in a timely manner, or aren't being told when they're solved. Regardless, they're not going to be good customers.
2 - Next, I would look to see the status of their contract files. Do they have a way of keeping track of every contract touch-point with each individual customer? Or are all the contracts just tossed in a drawer? The management of the documents hints at customer service, but more accurately, it shows whether there has been any "attitude" issues between sales and customers (i.e., if the sales folks really don't care, they don't follow-up on paperwork -- like turning in contracts, etc). You would also try to match the number of advertised clients to the number of clients evidenced by contract.
3 - Now I would start looking at the terms and conditions -- and this is where traditional M&A work starts (#'s 1 & 2 are rarely done -- which is why many folks are surprised at the state of things when they arrive AFTER the acquisition). You have a few different sections of every contract that you'll want to review to see if there's any extraordinary risk -- or violations of law/regulations.
a. The most important term for M&A work is the Assignment/Transferability clause. You need to see if there's any language in the agreement that prevents the software provider from transferring or assigning the agreement to a "successor in interest" and/or "by operation of law". It's conceivable that a crafty customer would be able to remove the software provider's ability to assign the agreement to a successor -- which means that the provider would be breaching the agreement (depending on the language of the clause) to attempt to perform the transfer. This isn't super common for software licenses, especially perpetual ones ... but for services work, I NEVER want the provider to be able to transfer/assign, as I want who I want to do the work ... not someone else.
b. Then move to payment terms, because this is where the rubber meets the road between the client and the provider. Are they complete terms (amount, duration, remittance timing/address, penalties)? Is there a "template"? Or is everyone's payment language unique/different/special? What about services deals? Do they have clear payment milestones and acceptance terms? This is all evidence of a revenue recognition policy, or lack thereof. And if they do work for the federal or state government, unique terms/price can become problematic if not properly documented.
c. Next, warranty. You're looking to see if 1) there's default/template warranty language; 2) if anyone negotiated something spectacular (getting a 1 year warranty when the usual is 6 months isn't probably too incredible ... but if someone got a "perpetual" warranty by re-writing the maintenance language in a creative way, you'd want to know about it both from a risk perspective and a revenue recognition perspective).
You also want to look for any special warranties themselves. Did someone get the provider to warrant against violations of law? What about Y2K-related (4-digit year) stuff? How about warranties on services? Most stuff is common and innocuous ... but sometimes, there's a real doozie.
d. Now indemnification. Most experienced enterprise buyers know to get IP and General indemnification ... and the good ones will get standard remedies for such things. But you want to see if there is anything over-the-top ... such as situations where a customer gets the provider to indemnify the customer against the customer's negligence (don't laugh, I've actually done it from the customer's side).
e. SLAs. For any software vendor providing maintenance, the issue of Service Level Agreements will come up. Check the SLA percentages (for the promises made from vendor to customer) and the penalty amounts (from vendor to customer) for missed SLAs.
f. Next to last is Term. How long are the various contracts? Perpetual/Annual/SetTerm? Is there a template? What about NDA's? How long is information kept confidential AFTER the agreement is terminated, for example?
g. And last is Governing Law and Jurisdiction/Venue. Not because it's really super important, but you want to see if there are any "bad" state laws governing any of your relationships. These are usually the UCITA states (VA, MD, etc...). But I consider California a "bad" state that I never want to use for the governing law.
The jurisdiction/venue issue is where you can be sued. If you're a NY company buying a CA software provider, it's conceivable that they've not only used CA law to govern every transaction (since they were based in CA), but they've also tried to force jurisdiction and venue into CA. As a NY company, you don't want to have to litigate anything in these contracts in CA if you don't have to. Knowing it up front is helpful.
4 - So, what happens if you find contractual risk? To head these things off at the pass, once discovered, is to simply have the provider send out proposed amendments to those customers with contracts that have been identified as "high risk". The customer might realize the reason for the proposal (even if done with a letter stating that this is simply a "routine" change to make things uniform), but the leverage goes towards the customer once the purchase is announced and the vendor HAS to do something or risk breaching the agreement. Additionally, many vendors plan far enough in advance that they sneak these changes into an upcoming amendment for something else (like the maintenance renewal)."
What can I say other than the fact that Jeff is truly the man when it comes to all sides of software licensing agreements. Great advice from someone who clearly knows his stuff.