Subscribe
Engineers tend to see the world in terms of tradeoffs. Certainly, successful product or solution design requires a clear understanding of the problem to be solved and the associated constraints, and then making informed tradeoffs to solve the problem within the constraints. Tradeoff thinking also applies to successful software due diligence.
The purposes of due diligence are to confirm pre-diligence understanding, gather information, and identify any unknown “gotchas” before closing an M&A transaction. All the information-gathering is in support of integration planning and can inform the terms of the deal to minimize risk in the transaction. The main constraints on due diligence are generally time and budget. (If you have an infinite amount of both, you can stop reading.) Another resource to be mindful of is the target’s time and tolerance for this “second job” of responding to myriad due diligence requests. The constraints mean that no due diligence will ever be 100% complete or perfect, but the effort can still be optimized if informed by intelligent tradeoffs.
Prioritization is key
Every acquisition scenario is unique, so while it’s critical to have a due diligence playbook, you need to have the agility to prioritize some areas over others. This should be based on the specifics of the investment scenario and focused on gaining the most important knowledge required within practical constraints. You can make tradeoffs along several dimensions. One is embodied in our software due diligence checklist that should cover all types of evaluation that you might want to perform. The other dimensions are the range of applications in the target’s software suite and the depth of analysis. An apt mental model is a three-dimensional shape that represents the types of evaluation, on which software, and to what depth. The volume represents the amount of effort (a combination of cost and time). You can reduce the volume along any dimension to fit the constraints
Prioritize evaluation efforts
The first consideration might be around the types of evaluation and should be driven by the perceived risk and plans for the acquisition. We think about software risk (and therefore types of evaluation) as residing at two levels: risks in the software development process and organization and—where the rubber meets the road—risks in the code itself. A poor development process will produce various types of technical debt that accumulate in the code. The types of issues in the code include application security, code and architectural quality, and third-party composition. Different types of analysis are focused on each of these areas.
Prioritize what matters most given the investment scenario. If the applications are public-facing, you might be more concerned about security vulnerabilities. If the new feature roadmap is ambitious or the intent is to dramatically scale a SaaS platform, energy should go into ensuring that the architecture will support future plans. If the seller stumbles when you ask about open source in the code, that should be a focus. On the other hand, in areas where the target seems to have its act together, you can take some comfort. Let’s say it seems security savvy as evidenced by a recent, reputable third-party penetration test; you might assume it is up to market snuff in that regard and not put as much energy into evaluating application security.
Additionally, your plans will determine how much you need to dig into the development team’s processes. It’s much more important to scrutinize how a team does what it does, if it will continue operate as-is. On the other hand, if the plan is to integrate the technology and merge into an existing engineer organization, then shortcomings in the current modes of operation matter less. (It’s still important to plan to remediate the issues in the code, but past process ills should be a lesser concern.) The size and maturity of the target can enter into the calculus as well. Early stage investments are bets on future software development more than past, so an emphasis on the organization and processes is appropriate. Smaller investments generally mean smaller due diligence budgets and involve less code, so that works out. On the other hand, a big acquirer needs to be mindful that integrating even a small acquisition may lead to different types of risk exposure.
Prioritize for future plans
Another consideration is the nature of the target company’s application portfolio and the plans going forward. Prioritize future money-makers over waning legacy products that you plan to end-of-life. Worry less about internally used applications than market-facing applications. You can refine this by particular risk areas as well. You might want to ensure a widely used cash cow product is secure, but if the plan is not to add significant functionality, you needn’t dig into the architecture too much. With regard to third-party licenses, recognize that there are a few problematic licenses for a SaaS back-end than for, say, distributed mobile apps.
Consider too, the depth in which you dig into all these areas. It’s not a binary decision, whether to evaluate code quality or development processes. The question is really how deep you go and how much energy goes into it. Just asking a few questions about a particular concern can provide useful information, albeit not to the depth of detailed code analysis. So a good practice is to go broad and shallow initially, ideally before due diligence even commences, and then use those up-front learnings to decide how deep to go, in which areas, and for which code.
Again, in an ideal world, software diligence would deep-dive into all risk areas of every product or software application, but practically, time, budget, and seller’s resources never allow. It’s worth noting too that time constraints can be addressed with money, by applying more internal or third-party resources while still being mindful of overwhelming the target’s capacity. A trusted third party (yes, like Synopsys) is particularly suited to code analysis, as targets are unwilling to share code with a prospective acquirer. And once such a service provider has the code, there is no additional burden on the target.
How Synopsys can help
The Black Duck® audit team advises on hundreds of transactions every year. Many of our clients rely on the insights we provide into software risks, and also on our help to design their software due diligence playbook, and then to take a risk-based approach and apply it optimally to each unique transaction.
Guide
M&A Software Due Diligence Checklist
Continue Reading
Audited vs. automated: What your automated open source tool isn't seeing
The hidden business risks of technical debt in mergers and acquisitions
From diligence to integration: How software audits inform post-close M&A strategies