After several months of effort, I’m happy to report that the 2015 Edition of the IT Due Diligence Guide has been released. There are new chapters, including one focused on cyber security. There is also a new set of data collection spreadsheets to make it easier to gather and organize the information you need from the target company. The IT due diligence report template has been expanded and makes the job of writing the due diligence report even easier than it was before.
Employee issues are the fourth key area of IT due diligence.
You need to determine a number of things based on limited information and time. Who are the key people that you need to maintain after the deal? Are they flight risks? I’ve seen many times that people get nervous when a deal is announced. They assume it means they’ll be losing their job and they start looking for a new one. Or, they feel that their employment environment is going to be changing anyway, so they might as well explore all of their options.
If you’re able to identify key employees at TargetCo, AcquiringCo may want to consider offering employment agreements or retention bonuses to ensure that these individuals are going to stick around at least long enough for AcquiringCo to get its arms around the business.
Especially in technology companies, the staff can be very attached to their way of doing things, so it’s very important to understand a number of cultural issues that impact employees. Otherwise, you may find that you’ve just acquired a company where every key employee will be gone in six months.
Many small companies take on the personalities of their strongest employees. If you’re buying a startup where the mentality is to come up with an idea for a cool new feature, work 24/7 to develop it and then roll it out to see what the customers think, it won’t take too many times for those employees to run into red tape or other roadblocks at AcquiringCo before they figure out that AcquiringCo isn’t for them.
In most startup IT companies, the overriding goal is to get the product to market ASAP. To achieve this goal, things like well-commented code, backups and system documentation can go out the window. Other formalities at AcquiringCo such as product management, system analysts and QA may also come as a shock to TargetCo’s employees. If AcquiringCo is an established organization with strict processes in place for its operations, you can count on employees of TargetCo seeing these as nothing but needless bureaucracy.
Companies can have wildly divergent hiring strategies. Some companies may prefer fewer, expert employees and others hire an army of lower level staff, hoping to find diamonds in the rough. If you’re acquiring a company with the latter mentality, be aware that there can be a lot of turnover on the way to a stable workforce, so HR and recruiting resources need to be considered.
On the other hand, if you are that company with many less-experienced employees and you’re acquiring a company with a handful of industry visionaries, be aware that they may very well be unhappy in an environment where they aren’t challenged and inspired by their peers.
There are many established software development methodologies, and software developers can become quite attached to their chosen method, sometimes almost to the point of evangelism. If this is the case at TargetCo, and AcquiringCo enforces a different approach, this can be a sure path to tension.
Tech employees can be very sensitive to their physical working environment. Their jobs often require a lot of concentration, and certain companies provide individual offices to most or all of their tech staff. If you’re buying such a company and plan to make room for more employees by moving everyone to new office space with cubicles, you need to understand that to some employees that could be as bad as telling them they can expect a 50% reduction in pay.
You need to be sure these issues are mentioned in the due diligence report. In my opinion, the job of the person performing IT due diligence is to identify any issues that can impact the success of the transaction, not simply the quality of the source code and age of the servers. In severe cases, the cultural differences may be significant enough to abandon the deal.
Also, when there are real cultural concerns that may cause you to lose key TargetCo employees after the deal closes, it’s even more advisable to lock up those individuals with employment contracts or other incentives as I mentioned earlier. In addition to keeping the key members of the TargetCo staff around, if they’re happy they can become cheerleaders for AcquiringCo and this can help retain the rest of the staff.
I’ve developed a few strategies for dealing with employee interviews in technology companies. It’s best to ask open ended questions.
Some questions I like to use are:
- Who are the people who are critical to the operation? (ask more than one person)
- Are there any bottlenecks in the code or website?
- What would you change or improve if you could?
- What do you think of the technology used here at TargetCo?
- What would you want to know if you were me?
You might be shocked at what people are willing to tell you.
Also, I like to meet with employees in their office and at their desk, often sitting next to them as they demo products or explain what they do, I find that it’s a much less intimidating environment than sitting across from a conference room table in what probably feels like an interview. The more comfortable they are, the more likely they are to provide useful information.
Any one of the issues identified in this series of articles, if serious enough, can be a reason to walk away from a transaction. In many cases, though, they can be addressed before or after the deal closes. The key is making sure you identify the problems ahead of time so TargetCo pays, one way or another, and not AcquiringCo.
The ownership and quality issues discussed in the previous articles in this series can definitely have a financial impact, but sometimes it’s not easy to quantify. In this installment we’re going to discuss items that can be discovered during IT due diligence that have a very quantifiable related expense.
Probably the most common and potentially most significant is software licensing. For any number of reasons, not all of them intentional, TargetCo may not have properly licensed all of the software it uses. Sometimes it IS done intentionally to avoid the expense, but more often it’s due to a lack of understanding or appreciation for the way software licensing works. Regardless, assuming that the goal is to run AcquiringCo as an honest business, any improperly licensed software needs to be brought into compliance.
Besides being the right thing to do, without proper licensing, AcquiringCo opens itself up to whistle blower lawsuits via software industry organization programs which promote proper software licensing.
A real world example I experienced was a company that, instead of properly licensing a particular software package used by its employees, used a single shared copy through a desktop sharing server. This was identified as an issue during IT due diligence, and the $200,000+ it took to acquire the proper licenses was paid by TargetCo as a condition of the deal closing.
Lack of Maintenance
Another common expense that can be identified in due diligence is lack of maintenance or outdated equipment. You might discover that TargetCo has been more profitable because its web and database servers are old, and that the hardware required to handle the expected increase in traffic after the transaction closes will be a significant go forward expense. Or, all of the TargetCo desktop and laptop computers might be running an outdated version of Windows, and bringing them up to AcquiringCo’s corporate standard would mean a significant outlay. These are typical issues in a family-owned or lifestyle business where keeping expenses low is part of the DNA.
Supplier contracts are something to be carefully considered. You may find that TargetCo is tied into an expensive contract for the next three years, and the financial model of the deal counted on a related expense reduction that isn’t really there. You can’t assume you’ll just terminate an existing contract and move TargetCo under the umbrella of your better contract after the deal closes. Telecom contracts are notorious for this. They often contain provisions that require full payment from the remainder of the contract term if they’re cancelled. It’s important to work closely with the financial and legal due diligence teams on issues around the contracts and assumptions.
Employee salaries at TargetCo also deserve careful review. If TargetCo has kept employee salaries low to enhance profitability, the staff may need to be brought up to industry or AcquiringCo standard levels. Having lower salary levels for the newly acquired TargetCo employees won’t be a viable long term solution – people will always find out one way or another. This expense needs to be taken into account when considering future profitability and the multiples used in the deal valuation.
The last article in this series will focus on employee issues.
I began this series on the key areas of IT due diligence with an article covering technology ownership.
The next important topic to consider is product or service quality. Was what AcquiringCo is buying built the right way?
Scalability of TargetCo’s product is usually one of the most important things to establish during IT due diligence.
Typically, AcquiringCo has plans for TargetCo that assumes some level of growth. Can the TargetCo system support it (if the TargetCo product is software or a website)? If the technology is something that is manufactured, does the manufacturing capacity exist to meet the expected demand? Does the supply chain have the capacity to handle the anticipated sales?
If AcquiringCo expects to increase the number of TargetCo customers tenfold, for example, does that mean the related expenses will stay about the same, double or increase tenfold? The person responsible for IT due diligence has to put a number of pieces of data together to answer this question, including customer volume data, existing hardware capacity, the source code review and simply asking direct questions about scalability.
However it’s accomplished, IT due diligence needs to determine if reality matches up with any volume and expense projections so that any required adjustments to the projections, the deal price and possibly the deal completion can be made.
Another key concern is how maintainable the product or service is. If it’s software, is the person or team that wrote it still there? I once discovered that the main developer of a company’s software was terminally ill and wouldn’t ever return to work, and no one else in the company really understood the software. Something like this is obviously a very unfortunate situation, but it’s important for AcquiringCo to know.
Does the product or service utilize standard technology sets? I experienced a company that had hired two brilliant software developers who created their own programming language to implement one component of TargetCo’s product. The problem is that those were the only two people in the world who understood it!
It’s much more comforting if TargetCo uses industry standard technology. It’s easier to hire people to work on it – most developers don’t want to work on something unique to a relatively unknown company, since it will probably do nothing to further their careers. Standard technology also means that it’s much faster for new staff to come up to speed on the company’s products.
Even if the product has been built with well-known technology, a source code review and other investigation can determine whether proper documentation exists. Although the software language may be standard, the developers at TargetCo, as anywhere, have their own style and standards. If these aren’t documented along with the system functionality, it’s much harder to add someone new to the mix and make them productive.
Another area of focus should be security. Was it considered from the beginning? If not, it’s very hard to bolt it on later. You’ll also need to determine if the developers understand any unique security requirements of TargetCo’s industry.
I’m in the healthcare industry, and there are numerous regulations around data security, encryption and privacy. I’ve spoken with developers at healthcare IT companies that had no grasp of security best practices. They were good at developing software, but it was going to take far too much money to rebuild it to meet the security requirements, and in the end the deal wasn’t pursued.
Backup & Recovery
Finally, the backup & recovery plans can reflect the overall quality of the organization. Does TargetCo even have one? If not, that’s a red flag, and the costs of mitigating the associated risks need to be taken into account. If one exists, is it viable and has it been tested?
Next up in the series – unexpected expenses.
In this series of articles, I’ll be discussing what I consider to be the four most important focus areas in an effective IT due diligence effort.
First, what is due diligence?
I like this simple definition from Wikipedia:
“The process through which a potential acquirer evaluates a target company or its assets for an acquisition.”
Due diligence can also be used for an internal review during a strategic planning or budget process, or before an investment without an acquisition, but most of the time it’s related to an acquisition or merger.
IT due diligence is a specific focus on the IT-related products and resources of an organization.
For an introduction to IT due diligence and an overview of the process, please see the sample content from the IT Due Diligence Guide.
As in the book, I’ll use the convention of referring to the company that is the focus of the IT due diligence effort as TargetCo, and the purchasing or investing company as AcquiringCo.
The first key area in the series is technology ownership. You need to be sure that TargetCo really has what they say they have, and this has a number of aspects.
At the most basic level, does TargetCo’s claimed software, service or product exist? Normally you won’t see a blatant lie in this area, but before IT due diligence was common, there were certainly cases where for whatever reason, no one checked that there was anything more than a PowerPoint behind a product.
More commonly, you’ll encounter claims of product maturity or functionality that aren’t based in reality. This is especially true of startup software companies or websites.
It’s been my experience that you’ll frequently find exaggerated customer counts. I was involved in a situation where TargetCo claimed to have 25 customers for a new product. Once I saw a demo of the product and spoke with the developers, it was obvious that it wasn’t ready for the market, and a review of the customer database showed there were actually only five customers, and only two of those were paying!
It’s important to be sure that TargetCo owns the rights to its product or software. This might seem like it shouldn’t be a major concern, but I’ve seen this crop up many times. What often happens is that TargetCo will hire an outside programmer to work on its product, but doesn’t properly establish the relationship as work for hire. At least in the US, the ownership of the contractor’s work can remain with the contractor unless the agreement is clear about the assignment of rights to the buyer.
The last thing you want to do if you’re the buyer OR the seller is to have to go back to someone and ask them to sign an agreement that gives TargetCo the rights to the work the contractor has already been paid for. I’ve seen deals delayed or cancelled if this can’t be worked out.
Source Code Issues
A surprising number of times, I’ve come across situations where the source code for a company’s product has been lost or corrupted. No one will volunteer this information unless you ask specifically. If you don’t have the source code, changing or updating a product can be extremely difficult if not impossible.
Related to source code, once you reach a comfort level that the product seems to be working as expected, you’ll want to have a source code review performed. This means having someone who’s an expert in the technology or programming language used to create TargetCo’s product review the actual programming instructions that have been used.
Typically this person or team will meet with the TargetCo software developers and receive an overview of how the company’s programs work, what they are meant to do, etc. Then the reviewer is provided access to the source code for the programs as well as any infrastructure that may be required to run the programs.
The source code reviewer will examine the security built into the product, as well as the overall quality and scalability of the product. They will normally also do a test build and deployment of the software to verify that all of the necessary components are present. You’ll usually receive a separate report related to the source code review.
On the positive side, while you’re getting into the details of the products and software, you might find out that TargetCo is working on something new that you weren’t aware of, or you’ll identify some technology that can enhance an existing AcquiringCo product or service.
For example, I once discovered in a due diligence project that TargetCo was working on a new product that had never been mentioned, and it happened to involve functionality for which AcquiringCo was about to pay a vendor a significant amount of money. In this situation, I was able to save AcquiringCo well into the six figures by finding out about the new service based on the interviews conducted onsite.
Another area of concern related to technology ownership is TargetCo’s use of open source products and code. There is no concern around the use of open source per se, but there are security and licensing issues that need to be reviewed during IT due diligence. See this in-depth article on open source for more information.
The next article in this series will focus on product service and quality.