M&A, Business Models and Ecosystems in the Software Industry

Karl´s blog

Posts tagged PMI
M&A digitization:Leveraging the domain model to map M&A data rooms, process tools easily

The domain model will consist at least of the following parts:

  • A data model that shows the data objects that are involved in M&A transactions and processes.

  • A Hierarchy of tasks in different phases of M&A Processes.

  • APIs for data objects and tasks.

The domain model is a programmable model. This means it is available electronically and can be navigated and displayed as you wish. It is implemented in a set of Prolog facts and rules.

Here is a first view at the phase Due Diligence. It consists of the tasks Target Due Diligence, Integration Approach Blueprint, Merger Integration Due Diligence, Deal Making and Finalize and Approve Due Diligence Business Case. Each tasks will be documented by its goals, the data objects used and a task description.Each of the data objects will be also represented in JSON notation as well as an API documentation.

duediligence.PNG

Here is an example of the documentation of each task. The task Review Merger Integration Project works on concepts

 Integration Project Plan, Integration Budget, Stakeholder, Integration Success, Integration Project, Integration Project Resources.

It has the goal (that describes the result):

Integration project: tested and verified

and the objectives, which describe the qualities of the result:

 Integration success: maximized
 Quality: maximized

It has the following task description:

We review the structure and behaviour of the merger project. It is important to remember that the word "project" means that we have a professional management of integration by professional project managers who are experienced with complex projects and equipped with the skills of a certified project manager. We should also set up a project steering committee that has comprehensive competencies and can make decisions quickly.
The word "project" means that we have a project structure plan with tasks to be performed in the project. Buying companies that make frequent acquisitions have a project structure plan template that they adapt to each of the new merger integration projects. This ensures completeness and also allows a correct assessment of whether we have sufficient resources and whether the resources know what to do in the merger.
But we also focus on providing answers to questions like: Do we have the right resources for the integration tasks in mergers? Are the resources able to perform the tasks assigned to them? Do the resources have adequate social skills to guide people and convince them to integrate?

So stay tuned for more information. One of the next blogs will talk about programming on top of the domain model.

M&A digitization: A first glimpse of the domain model

The domain model will consist at least of the following parts:

  • A data model that shows the data objects that are involved in M&A transactions and processes.

  • A Hierarchy of tasks in different phases of M&A Processes.

  • APIs for data objects and tasks.

The domain model is a programmable model. This means it is available electronically and can be navigated and displayed as you wish. It is implemented in a set of Prolog facts and rules.

Here is a first view at the phase Due Diligence. It consists of the tasks Target Due Diligence, Integration Approach Blueprint, Merger Integration Due Diligence, Deal Making and Finalize and Approve Due Diligence Business Case. Each tasks will be documented by its goals, the data objects used and a task description.Each of the data objects will be also represented in JSON notation as well as an API documentation.

duediligence.PNG

Here is an example of the documentation of each task. The task Review Merger Integration Project works on concepts

 Integration Project Plan, Integration Budget, Stakeholder, Integration Success, Integration Project, Integration Project Resources.

It has the goal (that describes the result):

Integration project: tested and verified

and the objectives, which describe the qualities of the result:

 Integration success: maximized
 Quality: maximized

It has the following task description:

We review the structure and behaviour of the merger project. It is important to remember that the word "project" means that we have a professional management of integration by professional project managers who are experienced with complex projects and equipped with the skills of a certified project manager. We should also set up a project steering committee that has comprehensive competencies and can make decisions quickly.
The word "project" means that we have a project structure plan with tasks to be performed in the project. Buying companies that make frequent acquisitions have a project structure plan template that they adapt to each of the new merger integration projects. This ensures completeness and also allows a correct assessment of whether we have sufficient resources and whether the resources know what to do in the merger.
But we also focus on providing answers to questions like: Do we have the right resources for the integration tasks in mergers? Are the resources able to perform the tasks assigned to them? Do the resources have adequate social skills to guide people and convince them to integrate?

So stay tuned for more information. One of the next blogs will talk about programming on top of the domain model.

Two best practices for managing the integration project

Best practices in merger integration have to include many aspects like timing, project management, handling exceptional situations and decisions and when to end the integration project.

In merger integration activities timing is essential. So when is the right point in time e.g. to merge teams of acquirer and target that do similar things? When is the knowledge of the acquirer complete to integrate HR functions of the acquired company? When is the right time to end the integration project?

Merger integrations are also high-risk, high effort topics that have to manage numerous exceptional situations. Project management practices are made for such projects. But there is the risk of keeping project members hostage in reporting activities instead of focusing on resolving issues and completing tasks. So a key aspect is to find the right dose of project management for keeping project control by providing appropriate follow-up and execution of critical tasks and minimizing the project management workload on project members.

Let us quickly look at the topics:  “When to mix up teams working on the same topics?” and “When to declare the end of the integration project?”

When to mix up teams working on the same topics?

So when is the right point in time e.g. to merge teams that are working on the same tasks, selling to the same customers, producing similar work results? We discussed different aspects.

The first one is that the acquirer has to have sufficient knowledge about all departments or teams that have to be integrated. Without that knowledge it is impossible to plan and execute change management needed for the transition into a merged team.

The second aspect is if the time is right to integrate if the immediate value of integration is maximized or the confusion and trouble is minimized. One example is the immediate integration of finance activities for maximizing the value for the acquirer to be in control of finance. Another one is integration of sales teams to avoid having two different, competing sales teams as “one” face to the customer.

When to declare the end of the integration project?

Ending the integration project makes sense when at least one or more of the following goals have been reached:

·         integration plan has been fully executed,

·         benefits of the acquisition have been reached or

·         organizational performance (fully functioning and stable merged organization) is ensured.

The selection of one or more of these goals depends very much on attributes of the merger, specifically on the department (or corporate function) to be integrated, on the culture of the target and the acquirer and on the integration strategy, like e.g. if the target should stay separate or should be fully integrated into the acquirer. Depending on the size of the M&A and merger integration team, the support of these teams might end earlier due to high workload or focus on new, different M&A and integration projects.

Find more information in the book “Mergers and acquisitions in the software industry” (click here for German version) and at the German Event Denkfabrik 2019

Systematic identification of PMI risks in the due diligence process

[this blog is an excerpt from an interview with me]

 "My experience has shown that there are certain risks that can always be observed in any acquisition."

According to your experience, what merger integration risks are there?

Every takeover of a company    is associated with numerous risks. On the one hand, there may be unpleasant surprises lurking in the target company, but on the other hand, integration itself also holds many dangers. Finally, risks may also be present in the organization and strategy of the acquiring company.

There are many examples of what can happen in a merger. Particularly in the software industry, it is not uncommon for employees to leave the target. The following points are therefore crucial for the success of an integration process:

  • How can I motivate relevant employees to stay?

  • Are there opportunities to document their know-how and make it available to the company in a sustainable manner?

  • Is the target company really in possession of all intellectual property rights?

Project risks in the context of a merger and the resulting integration already arise during the definition of the project scope, the assessment of the necessary resource expenditure as well as during the coordination of its implementation.

How can the risks of merger integration be classified?

The most comprehensive classification is based on the findings of the merger integration expert Dr. Johannes Gerds. My recommendation is that every company should use this as a basis for identifying risks and identify the problems specific to the company. These can be summarized in a risk catalogue and subsequently supplemented by further project-specific risks during the concrete due diligence. This provides an extremely solid basis for the entire risk management process.

What is the best way to identify risks?

In any case, a structured approach is advisable. As a rule, this is based on a company-specific risk catalogue, which is used in every due diligence. But first and foremost, the project and its integration should be examined from a neutral perspective. In the course of a risk workshop, the entire project-specific risks can then be identified and assessed together with all experts and managers involved.

It is always important to adopt and maintain a neutral position. This not only serves the critical questioning of hypotheses regarding adoption and integration, but also a concretization of the entire planning to be carried out. As a rule, this can be done by the finance department and the central units of the organization that are assigned to support acquisitions.

What are the most common risks?

My experience has shown that there are certain risks that can be observed again and again in an acquisition. These are primarily personnel attrition, serious differences in the corporate culture as well as an underestimation of the actual integration effort and the project management requirements in the case of more complex integrations.

Which risks can have the most adverse effects?

This question must always be considered in connection with the size of the buying company and the company to be bought. In the case of smaller acquired companies, the departure of a few key employees can have a major impact on the success of a merger. However, integration often suffers from a lack of experience on the part of the project members involved as well as insufficient resources on the part of the acquired company.

Large companies, on the other hand, often underestimate the complexity and effort required for integration. In addition, the cultural differences between the company buying and the company to be bought also involve a recurring risk potential.

Medium-sized companies tend to show mixed forms of problems with mergers, such as those found in small or large companies. Although the resources are often better and often more experience is available than for smaller companies, there are the risks known from them. But even the acquiring company can create considerable distortions through wrong decisions and negatively influence the success of an integration. Examples of this can be found in surprising strategy changes or sudden changes in the receiving organization in the middle of the integration process.

Once risks have been identified, how should they be dealt with afterwards?

In my view, there are four very typical approaches to dealing with risks: Ignoring and observing or actively initiating countermeasures and sales. Of course, the first approach is the easiest, but also the most dangerous way. Therefore, it is not really recommended, even if the probability of these risks is minimal. Perhaps I should note at this point that we are not talking about probabilities in the statistical sense, but rather about assumptions, i.e. assumptions about the probabilities of occurrence. According to this, even a risk with a low probability of occurrence can occur at any time, precisely because one does not know its probability.

Observation appears to be the most sensible step for risks that are unlikely or can hardly have any consequences for the success of the project. They are identified and regularly checked to see whether their probability of occurrence and thus their influence on the success of the project have changed. Accordingly, active countermeasures can be taken in good time in the event of an expected hazard potential.

But one can already act in advance and take countermeasures if the occurrence of risks is to be avoided for very pragmatic or political reasons. An example of this is the impending departure of relevant employees, which can be prevented at least temporarily by contractual regulations. In this way, time can be gained which is actively used to transfer their relevant knowledge about products or workflows in the company to be purchased to other persons or to document them if necessary.y

 

M&A Digitalization: where should data reside?

In past years, there always was a dichotomy: either companies were only on premise, storing their crown jewel data on site, or companies ran certain applications in the cloud. Now, hybrid clouds are on the rise.  This means there are three options now.  

In M&A, data rooms are typically private cloud based storage of highly confidential data during due diligence. Data from other phases are usually stored on site. With all these changes happening and the clear need to manage M&A processes,  where should company store their data about  all phases of the M&A process ?

On premise?

The safest way to store mission critical data is to store them on premise.  locked up.  This is perfect for a the early phases. As soon as more people get involved from inside and outside the company, during due diligence and post merger integration, this approach is not perfect. 

in the cloud? 

Cloud storage makes perfect sense for trustfully giving restricted access to people from different companies. For most companies, this is needed during due diligence and following phases. But many companies also interact with third party companies even before due diligence. 

Requirements for M&A process tools

Customers rule. An end-to-end process tool must respect that. No matter if  customers choose on site, private cloud or public cloud, vendors of end-to-end process tools should give customers a choice. The customer should decide where to store data.