Mergers and acquisitions can always result in some sort of unplanned issue emerging – whether it be about competition or integrating two disparate IT or HR systems. For this reason, the SEC has strict rules on the information that the acquiring and target company must provide to stockholders of public companies. This is done so that they can be fully informed on whether to vote for or against a potential acquisition. This information is usually centered on financial, operational, and competitive disclosure – but considering what we know about technical debt, shouldn’t it also be part of the dissemination of information before a potential merger and acquisition?
In a great post from CAST’s On Quality blog this question is answered in detail.
Software assets are continually becoming part of the valuation of company, and because of this any buyer should insist on technical debt being part of the assessment process. After the completion of the assessment, the monetized measure of technical debt (which can be done through the CAST Application Intelligence Platform) should be deducted from the acquisition price or be managed to the buyer’s standard of satisfaction. It should also be noted that if we are placing importance on technical debt in code during the process of the acquiring an organization, then the buyer should understand the implications of technical debt. This debt can result in some serious issues like application crashes, degradation of hardware and software performance, and an increase in software risk through the potential corruption of critical data.
Improving and measuring software quality can be an extremely complex process (especially in multi platform, language, and sourced applications) but is directly tied to the identification and quantification of technical debt. It’s always been a bit of a problem that investing in ways to improve software quality does not have seemingly have instant ROI – but it is important to understand that investing in quality pays for itself many times over. If you’re working on high quality software, it makes it easier for developers to modify code to meet pressing needs more quickly than if they were working on code riddled with bugs.
While it is the case that the less technical debt you have the better your code quality will be, it is not feasible to entirely eliminate it. When both speed and quality are critical factors to the success of any organization, being able to measure the structural quality of applications and to make sure that technical debt is at manageable levels could mean the difference between a smooth merger and one marred with complications.
Technical debt is a significant component in the day to day operations of any organization IT department (and to the organization as a whole) – because if it is left unmanaged it can be extremely harmful to the productivity and success of your applications. But it carries particular significance in relation to mergers and acquisitions. With technology becoming a more significant value driver during the merger and acquisition process, it is logical to assume that we should also start to assess technical debt with more scrutiny.
In a recent webinar from CAST in partnership with the Boston Consulting Group it was pointed out that 2015 was a landmark year for the number of mergers and acquisitions. This increased number of M&As signifies the need to more openly discuss the complexities of technology integration during the M&A process. The early identification of software risk in these scenarios helps manage and increase the probability of M&A success.
This means undergoing high level analysis of relevant application portfolios – adequately measuring application portfolios that will be most impacted by M&A activity – will help to enable communication between technology and business stakeholders to find synergies between the portfolios. The availability of objective measures during the M&A process will ultimately enable stakeholders to drive the value up – and that is an highly important goal to achieve.