In the previous two installments, we examined the Why and the What of Technical Due Diligence (TDD). In this third and final installment, we will briefly examine how a solid and systematic TDD process takes place, and what you can expect. Let me preface this with the statement that TDD is more of an art than a science. Therefore, the process highly depends on the style and experience of the TDD service provider. The following considerations reflect solely my own experience and practice.
 
A solid TDD project starts with a planning step. No matter how much of a system and process the TDD provider has in place, it is crucial to first establish the specific goals of that particular TDD exercise. The key question is: “What business questions do we need to answer through this TDD process?” You must agree upon this list of top-level business questions with the TDD provider up-front, so that expectations are set up right, and also the TDD provider has the right guidance in their work. Mind you, many of these questions are pretty standard (as we discussed in the first article in this series), but there always are nuances that should be worked in.
 
A typical TDD process continues with four more steps: (1) Preliminary research, (2) Site visit, (3) Follow-up research and communications, and (4) Report. Each one of these steps is driven by a plan, and you should expect the TDD provider to already have much of this process and the underlying tools in place. They include checklists, self-assessment instruments, questionnaires, and other optional analytic tools.
 
For brevity, I will focus here on the Site Visit – a key step in the TDD process. The approach will differ from case to case, given the range of sensitivities, types of locations and operations, key personnel availability, etc. Here are just a few of the rules of thumb that have emerged from my experience:
 
•Plan the Site Visit carefully with the target company’s executive team. This experience can be quite disruptive for the team if not planned well. The typical Site Visit is a two-day (rarely over three day) experience, and you want these two or three days to be spent with maximum efficiency.
 
•Ask the CEO to designate a point person who has the authority to arrange for all of the Site Visit components, from group meetings to demos to one-on-ones.
 
•Arrange that the TDD practitioners have access to all levels of the organization, including one-on-one meetings. Speaking with the relevant executives and senior managers is of course necessary, but not sufficient. Many of the true insights into what’s really going on come from front-line workers, from the tech-support trainee to the senior software engineer to the QA technician.
 
•Also arrange that the TDD practitioners gain access to a selection of the company’s customers, and even vendors. You often need to negotiate such access prior to the TDD practitioner’s involvement, as some companies are sensitive about facilitating such access. Typically, the access is gained through conference calls.
 
•Finally, make sure that you make yourself available during the Site Visit, but interfere very lightly, if at all, with the TDD practitioner, so that you ensure their independent position vis-à-vis the company. It is important to try hard not to bias the TDD practitioner in any fashion, so that you get back a report that does not reflect in any fashion your own biases and pre-judgments. You always have the option of challenging the TDD findings later!
 
The quality of the TDD Report depends largely on the sophistication, knowledge, independence, breadth and communication skills of your TDD practitioner. However, your facilitation of the process also contributes to the success of the Technical Due Diligence experience.
 

*  *  *
 
Sergiu S. Simmel (SSS@Clepsydra.net) has been affiliated with The Mercator Group since 2000. He is the Principal of Clepsydra Systems Inc. (www.Cleepsydra.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.