Mergers & Acquisitions: Software Integration Planning

 

 

 

"My company is acquiring another company, how should I plan to integrate their software with ours?"

Scope of Report:

Many venture capitalists, investors, and managers have experienced unforeseen and unnecessary losses due to hidden challenges in a target company’s software. Excessive enhancement requirements stemming from the size and/or complexity of a software asset can lead to significant upgrades and maintenance costs or worse non-performing functionality. These, sometimes large, issues can remain unidentified until very late in the development lifecycle.

Those who have unexpectedly dealt with these problems often face a loss of clients as they struggle to adapt to the new demands placed on their IT departments. Pressured to meet sometimes unrealistic budgetary and release constraints, perhaps due to excessive transaction savings expectations, they find themselves understaffed and incapable of getting their IT back under control.

Generally, there can be four distinct tasks in the acquisition process as it relates to the target company’s software:

- Software Asset Due Diligence (ADD): A profile of how the target organization relies on its technology.

- Software Asset Risk Management (ARM): An assessment of the risk involved in transitioning the target organization’s software.

- Software Asset Maturity Analysis (AMA): A profile of the return-on-investment for the acquired software, with an eye on the future.

- Software Asset Integration Management (AIM): An analysis of how to integrate the acquired software into the current environment.

Challenges occur for the surviving IT department if not all of these tasks are done or if they are not done by software experts. This report focuses on the last task, software asset integration management but reviews the other three tasks to identify the components they need to deliver for successful software asset integration. If these components are not available they need to be done retrospectively as part of software asset integration which can be difficult to impossible.

Software Asset Due Diligence (ADD):

The prospect of capital losses or unplanned expenditures in a targeted company, due to their software, rarely generates as much concern in the M&A team. It rarely affects deal pricing and structure as much as it should. However, anyone who has experienced the challenges of unexpected software project costs, schedule overruns, integration management problems or source code failure can imagine the potential for unforeseen damage to the value of an asset.

Both the balance sheet and the P&L statements are affected by a target company’s dependence on its software. In particular, if custom software is the embodiment of the target company’s unique business model and value, then there is a real risk if the software is unduly expensive to maintain or extend.

Acquirers should be informed about the potential pitfalls or the hidden asset value in any target company that depends on software. Investors will appreciate the thorough nature of the software due diligence and the enhanced quality of performance for the ongoing management teams.

The initial due diligence examination of a targeted asset’s software provides the M&A team with an evaluation of the current state of the targeted assets software and internal operating structure. This information can produce substantial gains for the M&A team, either via negotiation for a more advantageous position in the targeted asset or via a much more thorough understanding of financial statement impact. In some cases, we have identified hidden asset value for our clientele, thereby substantially enhancing returns for investors. In all cases, the benefit has far outweighed the cost of the initial software due diligence.

This information can produce substantial gains, either via negotiation for a more advantageous position in the targeted asset or via a much more thorough understanding of the impact on financial statements.

In many cases, we identify hidden asset value, thereby substantially enhancing profitability for investors. The return-on-investment is the confidence you receive in moving forward with a comprehensive understanding of the impact of the software involved.

Software ADD is designed to shed light on the impact IT can have on a merger or acquisition. Other benefits include:

  • Improved confidence in the profitability associated with a merger or acquisition

  • Identification of hidden asset value

  • Early recognition of post-acquisition risks, including software maintenance and upgrade

    fees

  • Identification of undue dependency on selected individuals in the development team

Software ADD should provide recommendations on how to move forward with the technological piece of the merger or acquisition – or not!

Software Asset Risk Management (ARM):

Software ARM should identify post-acquisition risks. One of the more intangible risks is often the quality of the source code in any custom applications. Venture capitalists, investors, and managers have been subject to unforeseen and unnecessary losses too often due to hidden challenges in the target company’s software. These, sometimes large, capital exposures can remain unidentified until very late in the investment life cycle. Excessive operating expense due to the size and/or complexity of software applications leads to large enhancement requirements and maintenance costs, or worse, non-performing functionality. Some who have experienced these problems have endured losses of credibility and market share.

One way to manage risk in the target’s custom software is to identify the code that presents the biggest risks and then use source code analysis tools to build up a picture of each custom applications strengths and weaknesses. The source code analysis can then inform the investment decision at hand to evaluate the potential financial impact. Source code analysis can provide an appraisal of the source code’s maintainability, ability to support growth and a risk profile defining issues embedded within the custom software, actionable for mitigation. Of course, the acquirer will require access to the source code for this service. This may be difficult to arrange during due diligence and may need to be deferred to the post-acquisition implementation phase. Software ARM outlines the risks involved in transitioning a target company’s software into your portfolio. Other benefits include:

  • The ability to avoid unnecessary losses due to hidden issues in the target’s custom software
  • Identification of potential IT team constraints – and enough time to mitigate them
  • An improved transition timeline based on a comprehensive understanding of the software related issues involved

Software Asset Maturity Analysis (AMA):

The software comes with its own unique growth cycle. Unfortunately for most M&A teams, it can be difficult for an outsider to spot the signs that a particular custom software application is reaching the point where its maturity is becoming a liability rather than an asset. Typically, new software platforms and applications evolve through several stages of maturity, each with its own set of capital, personnel, strategy and support requirements. Dependent upon the nature and size of software functionality, most growth entities will see a consistent pattern of increased resource requirement through the first stages of the maturity curve. If business growth continues, there will come a point where a large influx of resources will be a necessity to allow the software asset to perform to match the business growth and maximize opportunity profit. Put more simply, the more complex an application becomes, the harder it is to make even small changes. We have illustrated this point in the chart below

The difficulty comes in defining where you are on the curve and, hence, the degree of resource requirement necessary to maintain consistency in performance going forward. Should management not be aware of, or be misinformed as to these metrics, implosion may be on the horizon. Many target assets have appeared to be wonderfully performing with respect to market penetration, quality of provision and profitability until the bubble bursts. These entities entered a period of stagnation due to their inability to be responsive to market demands, and in doing so severely damaged their brand.

The key to success is understanding whether the custom software behind the business processes is up to the task of supporting the business model in the future and what future investments might be required. Undetected and unplanned for substantial development or maintenance expenditures can be devastating. Management may be forced into unplanned software asset acquisitions in order to meet future needs.

As more and more seemingly successful organizations fall victim to the expansion “bubble”, it has come to our attention that many investment management entities now want to identify and avoid software asset related capital losses and unplanned expenditures. To that end, software asset maturity analysis “AMA” provides a clear understanding of exactly where your custom software asset sits on the maturity curve.

Software Asset Integration Management (AIM):

Venture Capitalists, M&A firms, and private equity investors all have target ROI, ROE, and EV metrics. Substantial amounts of money and time are invested in potential targets to determine whether these metrics meet or exceed prescribed limits, both now and during the tenure of the investment. When the stars align, the completed transaction becomes another asset in inventory requiring ongoing financial reporting, planning, and management. Should management meet or exceed “pro forma” (essentially a financial plan for the joint entity) in the ensuing years, balance sheets can balloon from the increase in retained earnings. That being said, an inadequate software asset integration plan or an adequate plan based on insufficient information about the custom software will cause unexpected roadblocks on the path to value creation. Existing customers may risk the loss of functionality or may simply choose other alternatives if the integration plan is not clear. Clearly, this could impact ongoing revenue.

Most M&A experts understand capital, marketing, sales and human resource requirements as defined in painstakingly generated pro forma. Unfortunately, most do not consider the impact of weakness in operational systems and/or individual custom software applications. Even fewer plan for these requirements, producing too many examples of non-performing assets with pro forma of great promise. Understanding if, and how, the custom software should be integrated into a new parent company’s software asset portfolio can be the difference between substantial capital losses and financial health.

For a successful merger, it is necessary to document a clear understanding, via analysis and in the form of a plan, of how each target software asset should be integrated (or not) with the parent’s software asset portfolio to achieve the pro forma savings targets. This provides operating a management efficiencies and early identification and management of software integration and scaling problems.

The first step in the integration plan is to decide which applications duplicate the same functionality (e.g. HR software) and which provide unique value to the acquiring or target companies. Generally, the decisions over duplicated functionality applications will generally be decided in favor of the acquiring company who will want to retain their existing HR, finance, etc. software unless there is a compelling reason not to do so (e.g. cost). For these applications, the integration is an operational, people problem. For the targets custom applications with business value to add to the combined entity, the integration plan should cover the following information for all affected applications:

  • Development and testing e.g. Description of methodologies and techniques used for software development and testing
  • Maintenance e.g. Current Defect Backlog by Severity and Age and staff assigned to maintenance
  • Software e.g. List of purchased and developed software and their authors and other creators including information whether the author/creator made their contribution as a company employee under their employment contract, outside their employment, as a consultant or as an independent contractor.
  • Application(s) e.g. Components within application including third party software embedded (especially open source) and the schedule of all ongoing or planned software, databases and related systems development projects that affect the application or its environment.
  • Partners e.g. List of other companies, partnerships, individuals or other entities who are stakeholders in the application.
  • Customers and users e.g. List of the application’s largest customers or users in terms of sales or activity.
  • Employees, other staff and sub-contractors e.g. List of key employees or contractors who work on the application for development, testing, operation or security and an organization chart showing line management and functional relationships
  • The legislation, codes of practice and standards e.g. List any mandatory compliance requirements the application needs to comply with and evidence of most recent compliance audit.
  • Risk mitigation e.g. Copy of the business continuity plan and data backup and verification policies and procedures with a schedule of tests undertaken.

Conclusion:

If your company is acquiring another company, you can plan to integrate their software with yours by working with the M&A team as early as possible to gather information about the risks and challenges that you are likely to face during the due diligence process.

It is sensible to focus on the target’s custom software that is part of their unique business proposition because your existing software will probably replace any software they have that duplicates functionality you already have and custom software is more likely to be risky and difficult to integrate than any commercial off-the-shelf (COTS) software they have. 

Having identified the riskiest, most difficult applications to integrate, gather as much information about them as you can and plan accordingly. Measure twice and cut once!

Written by Default at 05:00

0 Comments :

Comment

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG President

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!