The key to a practical, comprehensive, and precise Technical Due Diligence (“TDD”) report is the extent to which it answers the client’s business questions, motivated by the anticipated transaction, be that an investment, a financing, an acquisition or a merger. Experience has suggested that there is always a set of questions that are common to most clients, and should be addressed in a standard manner. Additionally, there is also a set of questions that are peculiar to each situation, mainly driven by the anticipated transaction. The TDD report is complete when it answers both the standard as well as the custom business questions completely and specifically.
Examples of generic questions to be answered by the due diligence are:
- Is the technology implementation sound? Is it maintainable?
- Is the engineering group well managed? How mature is its lifecycle process?
- Is the intellectual property well protected?
As we will discuss in the next part of this series, a technical due diligence project must start with the uncovering and precise formulation of the additional questions that are specific to the situation at hand. Examples include:
- For a financing transaction targeting an ASP company: Is the technology scalable to support the projected customer base growth?
- For an acquisition transaction targeting a software company: How complex would be to integrate the acquired technology and product lines with that of the acquirer?
- For an acquisition transaction: How different or incompatible are the two IT organizations?
A due diligence report should cover both classes of questions in a systematic manner. In addition, the report should apply a set of measures to quantify the findings along a limited number of standard criteria. We have found that 8-12 criteria represent a useful and comprehensive set, and when applied consistently across all evaluation can offer the client a good, yet high-level basis for comparison.
Below, we illustrate the point above with the Table of Contents of a (sanitized) Technical Due Diligence Report (left), and the corresponding summary assessment which we call the “Bill-of-Health” (right). Note that these examples were taken from an average-sized report on a mid-size, mature software company.
In the next and final installment of this three-part series we will examine how a technical due diligence exercise takes place.
Sergiu
S. Simmel has been affiliated with The Mercator Group since 2000. He is the
Principal of Clepsydra Systems (www.clepsydra.net),
and
has successfully combined executive leadership, entrepreneurship,
technology and senior consulting over the course of his 20-year career in the
software product and software-based services industry. He often works with
financial institutions and management consulting groups on technical and
operations due diligence assignments. 
