What makes good Technical Due Diligence?
Technical Due Diligence is often high-value, high pressure and short timescale. Under these circumstances, the best way to find out what lurks within the shadows and cobwebs is to go direct to the best sources of information: the stakeholders and the developers.
Simply put, we need to ask the people who work there. Equally important is the strength of the relationship between the two organisations in question after the exercise is over. Worst case scenario is that everything was found to be good about the software, but in doing so the trust relationship is ruined.
A key differentiator of JFDI consultants is that we are nice. Firm where necessary, but always personable, approachable, humble, honest. We take care how we ask questions. We realise when that when scrutinising a company’s products and architectures or wading through reams of code, we’re often treading through people’s life’s work. And we tread carefully.
We are also thorough. We approach each investigation with an open mind. The services or products of the company under investigation are obviously good enough to have caught the attention of the company looking to buy or use them.
A due diligence exercise, in all but the most complex of situations, often runs for a period of one to three weeks. In that time we use a mixture of techniques to understand the products and services under investigation, including key stakeholder interviews, feature walkthroughs, architecture reviews, code reviews, test reviews. Through years of experience we have built a corpus of questions that we filter according to each set of individual circumstances and unique clients. We build on this list with each new investigation. We have the collective experience to deviate from this list when an investigation takes us down an unforeseen path.
The Technical Due Diligence process usually ends with a report, which can be delivered with an accompanying presentation.