IT due diligence will never be the most exciting of terms. However if you’ve worked in enterprise IT for a while, it offers you the opportunity to directly impact the beginnings of a successful M&A transformation and help deliver return on investment for the deal. That’s far more rewarding than systems implementation.

What is IT Due Diligence?

IT due diligence is the need to locate and understand the technology estate, including key intellectual property.

This is often easier said than done because corporate estates can substantially evolve over years or even decades and in the context of post-merger integration, this will need to be fully assessed within months. ‍

Why should you do IT due diligence?

Some of the benefits of IT due diligence include:

• Security - you will need to access sensitive data and need to ensure the new firm’s existing systems are compatible with your own security measures.
• Risk management – identify potential deal breakers early in the process.
• Cost – IT costs can be substantial and it’s important to evaluate the new firm’s IT overheads before committing to a buying decision.
• Project success - IT due diligence can make or break an M&A deal; if even 5% of the information is missed, the entire project may have to be reassessed. ‍

What should you be looking from an IT due diligence exercise?

Post Merger integration teams should be able to find services, applications, and hardware as standard. Therefore, the main requirements from the PMI team at the IT due diligence stage are credibility and trustworthiness, for several reasons:

• You need access to systems and sensitive information.
• You need to start shaping how this information will construct the transformation.
• You need to convince the project board that you have a complete Service Catalogue.
• You need to demonstrate your knowledge and expertise to several technical teams.

These require enterprise experience, customer-facing consulting skills, and the ability to articulate technical jargon effectively and convincingly.

How does IT due diligence differ for post-merger integration?

On the surface, it appears that due diligence for a post-merger integration is similar to that of a standard enterprise transformation programme.  

However, there are several factors that increase the risks:

• Multi-party or multi-company technology teams.
• Differing cultures and technology policies.
• The impact of different implementation policies.
• Differing ‘entry requirements’.
• The movement of software between companies.
• The financial impact of transferring or novating software licensing.
• Delays caused by technical unknowns.

It’s also important to understand whether existing systems will be acceptable in the new world IT environment. For example, the acquisition firm may be running a critical application on a configuration or platform that is incompatible with the firm being acquired.

What other information is needed during IT due diligence?

The acquisition firm should already have a high-level understanding of the systems used as part of the M&A deal. However, this may only cover a percentage of the application estate.

A company may use a small number of these ‘above the line’ systems, but they are also likely to be running hundreds or even thousands of applications. These additional applications need to be assessed.  

During the ‘Examine’ phase of a managed M&A, the merging team should:

• Interview key IT stakeholders to gather information.

• Develop a detailed Configuration Management Database (CMBD) of assets.
• Develop a project-specific catalogue of services to plan and manage the transition.
• Create and manage a list of support contracts.
• Create a company-wide software inventory and ensure the licencing implications are understood.
• Create a record of IT finances and contracts.
• Understand and discover critical cloud services and development platforms.

There will likely be some unexpected surprises during the integration, but it is imperative to carry out a quality assessment to ensure these bumps in the road are minor.

Prepare for access and credibility challenges from stakeholders

At the early stages of an M&A deal, key stakeholders are likely to have understandable concerns. ‘Have you done this before?’ is a very common question.

As part of the IT team from the buy-side firm, you will be among the first people that stakeholders from the firm being acquired will speak with.

You need to demonstrate credibility to obtain confidential information about their business. That’s why it’s important to document all previous projects, with the challenges faced and lessons learned outlined in a simple, easy-to-read table. This can be used as a reference card for your new customers.

Why do I need to create a stakeholder map?

At this stage of the process, you should be able to create a stakeholder map of all the relevant people and how they will help the project. This is not the same as an organisational hierarchy, but a pragmatic overview of the people who will be useful during the process.

The following points should be established for each stakeholder:

• How they can help
• Their key interests
• Their fears and concerns
• What’s in it for them.

The stakeholder map can be used to show build credibility with the client and as a reference point if any blockers arise.

Ensure meetings and workshops are efficient

Large team meetings can be beneficial for global teams, but smaller meetings and mini task forces are likely to be more efficient.

A common mistake is the idea that the project is so complex that several large workshops are necessary. Generally, many people won’t participate and often the skilled technical people won’t attend.

Instead, having smaller meetings between key people at different stages is likely to be much more effective and time efficient.

A Configuration Management Database is key

As outlined above, you need an accurate inventory to deliver a successful project. That’s why you need a Configuration Management Database (CMBD).

Without a CMBD, it’s impossible to plan accurately. You can’t establish how to integrate the systems or who you need to work with to transfer them to the new environment. You will also be unaware of the risks you will be exposed to.  

For example, will the target firm’s systems meet your company’s security requirements? Is some remediation work required? Are there legacy systems in place? These key points need to be answered.

This is the same for all IT projects, but the difference with an M&A is that it is a company-wide concern.  

It is very common for projects to be stopped mid-flight, and come to a complete standstill, due to some disagreement that has occurred due to an inaccurate CMDB.

Would you like to find out more?

If you would like to know more about M&A challenges, the Beyond Migration team would be happy to help. You can contact us at info@beyondmigration.com.