How many organisations do not fully consider software implications when buying or selling a company? Mergers and acquisitions pose a massive challenge for any IT infrastructure, especially where merged organisations are of a similar size. Making IT and software the often overlooked deal breaker.
It is very common that two merged organisations have entirely disparate systems, different processes, protocols, hardware, and websites. In order to gain the expected benefits from a merger, the new organisation has to rationalise its data and technical architecture, whilst standardising systems and application platforms.
A recent survey has shown that 75 per cent of failed mergers and acquisitions were due to a failure to meet requirements of IT and software, for merging business critical supporting systems such as back office systems and billing.
Whilst the due diligence process for merger or acquisition may have been robust in other operational aspects, software is often an area overlooked; evidence suggests that many software focussed business change programmes suffer substantial time and budget overruns, do not deliver the desired outcome and are eventually written off.
Securing information before a purchase or a merger is key, as a minimum, organisations should consider:
What software licenses does the company have and how critical are they to the company’s core business?
What software is critical to the company’s operations, and does the company have appropriate licenses for the IP (both open source or proprietary) of that software and does this cause any exposure?
Does the company’s usage of that software comply with use limitations or other restrictions?
Requesting architectural documentation for the system structure and applications
Identify who wrote the original base software and undertake a full code review/systems audit
In some cases, merged companies’ systems are so incompatible that it may be too costly and doesn’t make sense to consolidate them. In these situations, it’s important to take a longer term view by allowing both companies to continue to function with their existing systems, having temporary tactical integration points, whilst developing a bespoke specification that meets the needs of the new organisation.
Software assets continue to become an increasing part of a company’s valuation, buyers should understand the technical debt embedded in the code they are acquiring. Technical debt, the cost of fixing issues or making necessary upgrades, can increase when left unresolved, along with the likelihood of application crashes, degradation in performance and potential corruption of data.
Prior to acquiring a company insist on conducting a technical debt assessment as part of wider code audit during the due diligence process. When this assessment is complete the buyer should deduct a monetized version of the technical debt assessment from the acquisition price.
Eliminating all technical debt is not possible but in today’s business environment where both speed and quality are critical success factors, analysing and measuring the quality of an organisation’s software applications to ensure that they carry a small but manageable amount of technical debt can mean the difference between a successful purchase and a costly disaster.