In the following second part of the blog series, we are going to discuss the fields of investigation of a software due diligence.
This blog series also appeared as an article in the 11/2020 issue of the German M&A Review magazine. The specific issue of M&A Review can be found here.
In Part 1 we talk about the reasons why software assets present particular valuation risks. The last, third part, deals with the process of a software due diligence and its deliverables.
The unique characteristic of software as an asset is that the relevant features of the application must be renewed and extended very regularly in order to be able to adapt timely to the further development of users or customers. The software provider has an additional responsibility for its customers as the software fulfills a function that cannot simply be replaced by another software product. The customer base trusts that the software will be developed and updated for a long time to come. A software must therefore be designed so open and flexible, that it is capable of delivering answers tomorrow to questions that have not yet been asked today.
The main goal of a software due diligence is therefore to correlate the potential of the software as stated by the seller with the technical reality of the code architecture and especially the quality of the development process. The technological basis of the software – as well as the necessary development, quality assurance and acceptance processes – should be able to follow the dynamics of changes in requirements. This is required to provide the necessary updates, upgrades and new functionalities in a market-oriented time-to-market. In contrast to other due diligence processes, software due diligence is highly automated. Otherwise, hundreds of thousands or even millions of lines of code cannot be analyzed. Fig. 1 shows how the tasks of the consultants and the analysis tools used in the individual fields of investigation complement each other.
Fig. 1: Focus areas of the tools and consultants in a software due diligence
For example, the relevant developers of a software functionality are identified directly in the code. However, the relevance of this code section and thus of the responsible developer is only ascertained by the consultant with the help of further analysis results and interviews. This ensures that the identification of the key developers is anonymized and thus GDPR-compliant (e.g. developer 1). Technical debt, incomplete documentation or the distribution of knowledge within the development team are also identified directly in the code by the analysis software. The error intensity of individual functionalities is read from a bug tracker and linked to critical code points. The quality and development processes have an initial input from the software analysis, but must be supplemented by interviews and experiences of the consultants. To assess the quality of the code architecture is a task for the consultants. However, the assessment is not only based on personal expertise, but also takes into consideration the data from the analysis.
Fig. 2 lists generically the possible fields of investigation of a Software Due Diligence. In practice, due to time and budget constraints, one is limited to the code (1), key personnel (2) and the development process (3). These three sets of issues essentially determine whether the company can develop successfully in terms of technology and are correspondingly subject to risk. With respect to the topics (4) tools and (5) application the risks are rather low from a technological point of view and a very brief consideration may be sufficient or they are the subject of other due diligence work streams. The assessment of the functional characteristics of the software in comparison to the market and competition are not subject of a Software Due Diligence as well and should be considered as part of a Commercial Due Diligence.
| Field of investigation |
Risk Potential |
Criteria | Risk to the Investor |
|
|---|---|---|---|---|
| 1 | Code | very high | Defects, Language, Documentation, Technical Debt |
No basis for further development |
| 2 | Personnel | very high | Affiliation, Turnover, Knowledge Distribution |
Know-how gaps, Knowledge islands, Turnover of staff |
| 3 | Processes | high | Time-to-market, Quality, Documentation, Acceptance |
Lacking innovations, quality, time-to-market |
| 4 | Tools | low | Up-to-dateness, Culture, Spread of usage |
Productivity and Quality |
| 5 | Application | low (reflected in KPIs) |
Financial turnover, Financial result, Customer Feedback, Reviews |
Competitiveness |
| 6 | Valuation of the software |
low | Production costs | Valuation value dependent on selected parameters |
Fig. 2: Fields of investigation of a Software Due Diligence
The question often asked by industrial investors “what does it cost if we develop this ourselves” leads to the question of the value of the software (6). A valuation of software is complex and the different methods are not without their challenges. The Function Point Analysis (FPA) and the Cocomo II method are two calculation approaches that have gained a certain amount of popularity. /1,2/ Both use complex algorithms to determine the production costs and project duration of the software under investigation. The result can be significantly influenced by the choice of the parameters and thus can only be used to a limited degree to serve as a basis for comparison in an M&A transaction for the investor.
Note for sellers: The use of these methods makes sense in a vendor due diligence, in order to proactively answer the question of whether a self-development is not cheaper with a cost and effort estimation and to substantiate the asking price.
For a holistic analysis it must be taken into account that software is a “fluid” product that needs to be adapted constantly and often in short cycles to cope successfully with its innovative and highly competitive market environment. Since a software version is in principle always more or less progressed in its life cycle at the time of the analysis, ongoing projects for updates and new functionalities should also be disclosed by the seller.
It is important to ensure that the work is on schedule and within budget and to check when the launch is scheduled for. Together with the delta analysis (as proposed in the first blog) of the software version examined in the due diligence process with the version at hand at closing, it can be determined how well the software engineering processes really work.
Questions should also be asked about the current bugs as well as the measures and processes taken to correct them. If too many serious doubts arise at this topic, the whole transaction is at risk. Below are listed some of the questions that should be answered positively through analysis and interviews:
Have you ever dealt with software assets in an M&A transaction? What were the fields of your investigation? Were there additional ones?