What is IT Due Diligence?

Tuesday 13th October 2020 Dave Sharp Technology

IT Due Diligence (ITDD)

Investment deals that are subject to a IT due diligence process have a higher chance of success. ITDD creates evidence-based reporting that contributes to making informed decisions by driving the quality of information available to decision makers.

IT due diligence allows the purchaser to feel more assured that their expectations regarding the purchase are valid. In mergers and acquisitions (M&A), purchasing a business without doing ITDD substantially increases the risk to the purchaser.

IT due diligence exists to provide the purchaser with trust. ITDD may also benefit the seller, as going through the rigorous technical examination may show that the fair market value of the seller’s company is more than previously thought. Therefore, it is not uncommon for sellers to prepare due diligence reports themselves prior to potential transactions.

IT due diligence is conducted to:

  • confirm that IT/technical information supplied was accurate, comprehensive and complete;

  • identify potential issues with IT that is poorly built, will not scale, is expensive to maintain, is commercially limiting or is carrying large amounts of technical debt. Technical deficiencies need to be reflected in any deal or investment opportunity to avoid a bad business transaction;

  • obtain technical information that would be useful in valuing the deal, valuable intellectual property, patents etc.;

  • make sure that the deal encompasses all potential IT opportunities (data, analytics etc.) within the deal criteria.

When does IT Due Diligence take place?
Typically, the ITDD process will take place at the same time as other due diligence workflows. There is a requirement to do financial, commercial, and legal due diligence pre deal and the IT due diligence workflow is conducted at the same time.

How long does the ITDD process take?
The time to report on the IT within the company varies dependent on the size of the company, the complexity of the IT, the level of documentation and the level of finance within the deal. Smaller deals could be completed in 5-8 days with large deals reaching 15-18 days.

Who takes part in the due diligence process?
The company CTO and lead developers are required to work with the ITDD team. Others might include the CFO if there are financial elements to consider, the CEO if there are strategy questions and the CIO if the company handles sensitive data.

What activities are conducted as part of the process?
The purpose of the investigation is to document the factual status of the company’s IT assets. This is done via:

  • Documentation is provided by the company into a secure data vault. The ITDD team will review the documentation and create a list of key individuals within the company that they would like to interview;

  • In a pre COVID scenario, there would have been a physical visit to the company’s offices where interviews would be conducted on premises. Post COVID these are now done online.

  • Once the previous steps are completed and all required information has been provided, the analysis of that information is conducted to identify any risks. The risks form the basis of the recommendations made within the report. The recommendations are mitigating actions to address the risks.

Code quality reviews are not usually part of the ITDD process. This is a separate process and can be time consuming and expensive, dependent on the size of the code base. Qualitative based reviews of source code require experienced CTO level reviewers and can require the involvement of development team members who authored the original code.

What is the output of the process?
The ITDD process concludes in a detailed report of the findings of the investigation. This document will state the factual findings of the investigation, with the corresponding explanation of how those facts were collected. The report will then outline risks identified from the review of the company’s technologies and IT operations. The lead investigator will offer an opinion on the findings and then go on to make recommendations on how to deal with the risks, over what time periods and through what mitigating actions. This will be accompanied by approximate costings, which 3rd parties might need to be used and the legacy of the changes.

What are the most common findings?
There are a few issues that are very common within small/medium size technology teams. These include (but not limited to):

  • Poor technology choices. The development team chose the right software languages for the team, not the product;

  • Little or no documentation. The code base has become large and difficult to navigate and the supporting documentation is non-existent;

  • No discernible software roadmap or strategy. The software team is reactionary to the change with the market and not following a defined approach;

  • Technical debt. The team has been asked to create solutions to meet commercial or financial restrictions and the outcome is software that has flawed design patterns;

  • Poor version control. The software team has been allowed to exist on older versions of tools and technologies for comfort. When old software is deprecated or unsupported the entire codebase is at risk;

  • Poor project management processes. Task management is flawed and poorly executed leading to extended development periods and poor product iterations.

What advice would you give to exec management teams facing the ITDD process?
There are common scenarios for the executive team when it comes to the due diligence process. There are competing workstreams, financial due diligence, commercial and legal due diligence and all workstreams are important. My advice to a management team facing this scenario would be:

  • Focus the development team on creating a functional set of documentation for the current IT. Infrastructure diagrams, ERD/Schemas for the database, UML etc. This is the baseline documentation;

  • In-code documentation should be standardised and consistent;

  • The next level documentation should be around “why” not “how”. For the ITDD team the first concern is why the IT is designed the way it is, the second question is how if functions. Answer the “why” question within the documentation and deal with the “how” as part of the interview process;

  • Ask the ITDD team for the document list they are expecting from you early and give the software team a copy for review in advance;

  • Prepare a data room for all your documents to be delivered to securely. The ITDD team will need a repository for your documents, they typically do not want to send/receive them through other methods like email;

  • Set dedicated time aside to both meet the ITDD team and talk through the process. What they are trying to achieve is not a mystery and the approach is not a trade secret.
Next Article

Analysis paralysis (or paralysis by analysis) describes an individual or group process when overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed", meaning that no solution or course of action is decided upon. This short article is about the possible actions to get out of the syndrome.

Previous Article

While the activity of playing video games can be seen as trivial and frivolous, the industry around developing, and publishing video games is now big business. There are 2.7 Billion video game players around the world, one third of the population of the planet, creating global revenues of £160Billion by the end of 2020, and the sector is still growing. A compound annual growth rate of 12% is forecast between 2020 and 2025, is an indication that there is a lot of room for the sector to continue to grow.