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.

Software Licensing

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

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

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

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.

Maintainability

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.

Security

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.

Introduction

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.

Technology Ownership

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.

Possible Upside

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.

Open Source

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.

I recently read a great quote from the CIO at Dell: “There is no business without IT right now. We don’t support the business – we are part of the business.” While most due diligence efforts won’t focus on companies the size of Dell, the fact remains that technology now plays a key role in almost all businesses.

If you accept this premise, then you should consider how much attention technology receives when you’re evaluating an investment. If it’s not any less important that customer contracts or financial projections, then don’t treat it as an afterthought.

Too often I’ve seen that technology due diligence consists of a brief period at the end of the overall due diligence process that focuses on things like documenting the existence of IT assets like servers and laptops, and maybe a quick review of the data center.

While acknowledging the need to get a deal done as quickly as possible and to start the process of integration, below are some additional IT due diligence steps that I think should be required in specific IT-related acquisitions.

Source Code Review

If there is proprietary technology involved in the operations or products of the target company, it’s critical to have a source code review performed by an expert in the particular programming language used to develop the target’s technology.

The best IT consultants are truly fluent in only a handful of languages, so it’s worth the added expense to be sure a real expert is reviewing the code, even if that person isn’t involved in the overall IT due diligence process. You want to know that good development practices were used, that the design is scalable and that there are no obvious security concerns.

A source code review can also identify any third party and open source components that are used in the target’s software. It’s very important to ensure that any open source components are used within the terms of their license.

Penetration Testing

If the systems or websites of the target store any sensitive data, it’s worthwhile to have a penetration test performed. This means hiring a resource to evaluate the security of the website and associated network infrastructure. In some cases, the testing firm will attempt to breach the network defenses and to access systems and data. You want to know about any vulnerabilities, and the potential cost to correct them, before you’re the owner. Penetration testing is a highly specialized service not typically part of standard IT due diligence efforts.

Industry-specific Requirements

Industries such as healthcare and finance are subject to various government regulations when it comes to secure storage and transmission of data, retention requirements and encryption. If the target accepts and processes credit cards on their own, a separate set of security requirements must be in place and verified.
Unless your IT due diligence expert is familiar with the relevant requirements, you’ll probably want an additional resource who is a specialist in these industry-specific issues to review them.

Staff Interviews

Having someone meet with the IT staff of the target company who can speak their language can be the most valuable part of an IT due diligence effort. These employees tend to be more open with fellow technicians, and can provide a wealth of information around the target technology’s strengths and weaknesses. In addition, familiarity with key IT staff skills sets can assist in integration planning.

Conclusion

With just a little extra effort, IT due diligence can come closer to reflecting the importance that IT plays in most businesses today. The relatively small incremental cost is well worth the investment.

In recent years, open source software has gone from something used mainly by startups and hobbyists to a resource that at this point is very much mainstream.  This article examines open source software and how it impacts IT due diligence.

What is Open Source?

Generally speaking, “open source software” refers to programs and projects that are developed by a company or an organized group of online programmers, and are made available with source code for free.  The software may be modified or redistributed by those who download it, subject to various open source license terms.

There is nothing inherently wrong with open source or its use in commercial environments.  In fact, many commercial software programs and services include open source components.

Well-known examples or open source software include:

• Apache (web server)
• Linux (Unix-like operating system)
• MySQL (database software)
• PHP (website scripting language)
• WordPress (blogging software)

Today, open source software is used by companies of all sizes.  While it’s often favored by startups due to its low cost, companies like Google and Amazon run significant portions of their operations with open source software.

While open source tools are available at no cost, they are not always “free.”  There are often optional packaging and support costs.  Still, in many cases, very capable and less expensive open source alternatives to popular commercial software tools are available.

Open Source Security

Traditionally, one major concern regarding open source has been security.  There are some valid points on each side of the argument.

Those who believe open source software to be less secure focus on the fact that, since the source code is available for anyone to see, a skilled hacker might be able to identify a vulnerability and exploit it.

Those who feel open source is more secure than commercial products also point to the availability of source code, but their argument is that since many eyes are viewing the code, any security weaknesses introduced should be quickly identified. Large, well organized open source efforts can sometimes issue security updates more quickly than a commercial software company.

Open Source Licensing

Open source software is made available under many standard licenses.   A list of common open source licenses and their terms can be found here:

http://opensource.org/licenses

Some licenses are very liberal, allowing the open source tool to be used in any way desired by an end user, including modification, redistribution and even resale.  At the other end of the spectrum, some licenses require that any redistribution includes the release of any supplemental or modified source code.

Occasionally, a company has acquired another only to later find that certain software assets just purchased were based on open source projects with a very restrictive license.  In that case, the options are to release the source code, redesign it to eliminate the open source component or to pull the product from the market.  Obviously, none of these are good options.

Practical Due Diligence for Open Source

Given the concerns around security and licensing, there are a number of areas to explore during IT due diligence.

First, a list of open source projects utilized by the target company should be requested.  This should include the name and version of the open source project, the license under which the project is distributed and whether the open source component is used for internal or external purposes.

If open source is utilized only for an internal development or administrative utility, there is usually little if any concern, as it’s normally the external distribution of any enhancements that may trigger some of the more restrictive license terms.

The target’s response to this request should be examined to understand the requirements of the relevant licenses in conjunction with a detailed review of how the open source component is used.  This will allow the acquiring company to begin to understand whether there are any concerns.

Due diligence should determine the target’s process for deciding whether to use an open source component.  Is a formal review of the open source license performed before a component is accepted for use?  Who makes the final decision?  Is this a senior staff member, with a thorough understanding of the relevant issues, or can an individual programmer make the decision and potentially put the company at risk?

The security concerns outlined earlier can be mitigated by the size of the open source community for a component and how active it is.  Large open source developer communities ensure that a project continues to be enhanced and supported.

Due diligence should examine, for key open source components used by the target, the process used by that open source project for reporting and responding to bug reports, especially when related to security issues.  Some of the largest open source projects have dedicated security response teams and a specific infrastructure related to security issues, but not all do.

Does the target closely track the updates to any open source components utilized?  Too often, companies bundle an open source component with a proprietary product, but don’t update the open source portion as that component is enhanced.  This can lead to the inclusion of outdated and potentially insecure open source software in the target’s own product.

Audits

The terms and requirements in some restrictive open source licenses cascade to downstream use.  For example, it’s possible that the acquisition target uses a commercial software component in its product or service that in turn utilizes an open source component.  The target may not have any idea that the open source component in indirectly included in its own software.

Audit tools and services exist to identify open source components and their related dependencies in software.  Audit firms track the source code from thousands of projects and versions and can automatically identify this code in the target’s own source code or object code.

Reference

Everything you’d ever want to know about the history of the open source movement, license terms, etc. can be found here:

http://opensource.org/

Conclusion

There is nothing fundamentally wrong with the use of open source software by startups and other commercial enterprises.  However, during IT due diligence it’s important to determine whether the target is using any open source components intelligently and responsibly.