Technical Due Diligence – What’s it all about, anyway?

Over the years, I’ve been involved in a number of technical due diligence exercises.  They’ve ranged from assessing an organisation’s information technology where the primary product or service was not technology related, all the way to examining companies where the main product or service was fundamentally a technology offering.  Sometimes the transaction in question was the purchase of technology or services from what would become a strategic vendor, and other times it was the outright purchase of or investment in another company.  In this post, I’m going to cover the M&A and investment-related approach, as in many ways it’s a super-set of the other cases, with some of its own considerations.

When looking at a company as a potential acquisition or investment target, there are really just a few fundamental questions to which I’m trying to ascertain the answers.  They are as follows:

  1. In the case where a technology product of service is the focus, do the technology and the rest of the offering actually exist?  That may seem like a bit of a strange question, but actually ensuring that the glossy marketing brochures, the demos, and tantalising claims of the company in question are more than just vapourware is important.  Anybody remember Ovation?  For a good list of example vapourware technologies, see PCWorld’s 2008 article, “The Top 15 Vapourware Products of All Time” at http://www.pcworld.com/article/145351/article.html. While the article is a bit dated, you’ll get the idea.
  2. Does the company actually own or have the legal right to use all the technology it is selling and using in its business in the way it is selling and using it?  That applies to open source as well as commercial technology.  Most open source software, for example, nonetheless has a license that accompanies it, with specific provisions on how that software can and cannot be used, what accreditation must be given the copyright holder, and other possible provisions, open source notwithstanding.  VMWare is in hot water for its alleged improper use of Linux under the Gnu General Public License version 2 (GPLv2) (see http://www.zdnet.com/article/vmware-sued-for-failure-to-comply-with-linuxs-license/).
  3. Are there risks to the ongoing health of the company, or to it achieving the business goals?  This is often by far the largest focus, covering a broad range of factors.  Here I examine the health, robustness, and resilience of product and technology, people, processes, information security, business continuity, and legal agreements impacting technology and service delivery.  For example:
    1. Product and Technology: A monolithic application architecture tends to make the process of software enhancement slow, and prone to errors.  It also may make it extremely difficult to scale the business.  Use of substandard technology tools can hinder more than help the company move its offerings forward, such as outdated integrated development environments (IDEs), cumbersome source code control systems, or awkward testing tools.  Poor-quality end-user documentation can cause support costs to escalate.  Out-of-date technology makes hiring and retention a challenge (think CoBOL).  I once did a due diligence for a company where a critical underlying technology was at risk of being sunset by that technology’s vendor, with no real plan in place by the acquisition target to replace that technology – talk about risk!
    2. People: Is the compensation of technology staff appropriate for the labour market conditions at hand?  Is there a potential flight risk based on inadequate remuneration?  A large-scale exodus of disgruntled staff – or even one key position – can have deleterious effects on the company’s business plan.  What is the capability of staff, and in particular in relation to the company’s business goals and what that staff will need to do to support those goals?  Will the people be able to do the work?  If not currently, what are the plans to close the gap?
    3. Process:  Poor processes, lack of adequate quality assurance, and failure to identify systemic process issues can easily lead to skyrocketing costs when a company tries to grow.  Failure to have an appropriate product development / road-mapping process can result in quickly getting out-of-step with your customer’s needs, and missing emerging market opportunities, reducing revenue and possibly losing business, not growing it.  Lack of appropriate design, development, and other standards can result in disjointed products, inconsistent user interfaces, quality issues, increased employee on-boarding costs, increased development costs, and deteriorated reputation based on customer experience, which will likely impact future sales and if bad enough, existing customer renewals and follow-on business.
    4. Information Security:  Without appropriate controls on the company’s information, intellectual property, and confidential customer information, should anything go sideways, legal ramifications can be disastrous.  Are there appropriate policies and procedures in place within the company to adequately ensure information is safe and secure, and that employees will not inappropriately use any information, either while they’re employed, or after they have left the organisation?  What provisions are there governing vendors and contractors?  What about obligations of customers?
    5. Business Continuity:  At some point, somewhere, something is going to go wrong.  Be it a massive power outage (2003 northeast North America power outage), pandemic (SARS), fire in the building, or somebody took a coffee into the server room when they shouldn’t have, something will go wrong.  Does the company have adequate plans in place to deal with those situations, and have they practised them so they know they actually will work?  What are the expectations of their customers in such a situation, if, for example, the company is a service provider?
    6. Legal Agreements:  This covers everything from what rights and responsibilities the company’s customers have under license agreements to the SLAs the company’s vendors are to provide.  Are there any provisions anywhere that will hamper the company’s ability to meet its business objectives?  Are there any potentially unreasonable covenants in any special agreements with select customers that while they may have been necessary at the time to secure that business, may now create a significant potential liability?  What recourse does the company have if one of its key vendors massively fails to deliver, materially impacting the company’s ability to service its customers?

Performing a technical due diligence is a bit like combining a detective with an auditor.  The detective seeks to get at the underlying story, digs into the important details to uncover evidence of the health, robustness, and resilience of the company, and never makes any assumptions about the information, but works with the facts / evidence.  The auditor wants to make sure that what’s represented can be substantiated through third-party corroboration, direct observation, and sampling and testing.  Once all this is complete, an opinion can be given as to whether or not there are material risks to the company achieving its objectives, and thus to the investment in the company.