7 IT Due Diligence Headaches to Avoid

Introduction

In regards to M&A deals two common observations are made:

• The new company formed (or divested) by the integration project did not reach the intended “deal value”.
• The IT work stream was the most expensive within the integration program and is a major reason why the assumed efficiencies were not met.

Dig deeper, and the one of the major reasons stated for the IT work stream causing extensive costs and delays is a problem with the original IT Due Diligence.

As I’ve stated previously, M&A IT Projects differ from traditional IT transformation and there are so many things to consider if you are responsible for assessing a company as part of a Merger or Divestment. Some of the usual concerns are whether the team will have sufficient access and knowledge to assess the systems in detail, so that you can make sound judgment in regards to moving or transforming them.

You will need to consider the IT processes and change cultures – across not just the acquisition/carve out but also the other involved companies – as this will almost certainly impact how changes are made and the project timeline.

It is common sense, if the IT systems and services are not fully discovered, then the resulting integration project cannot succeed. Why do IT Due Diligence fail within M&A programmes?  What sort of things can IT Due Diligence miss and how does this impact the deal?

1. The environment is bigger and more complex than expected

Assumptions can be made during the deal based on information passed in the initial stages of communication. High-level assessments are made based on spreadsheets of infrastructure, applications and assets.  Based on the rough numbers, an outline plan and skeleton technical architecture can be created to explain how the the transformation can be made, for initial bid and approach conversations. 

But it isn’t until you are on the ground, speaking directly with staff that you start to learn that the environment is bigger than the board expected. Way bigger. The pre-development and testing environments had not been discussed in pre-deal meetings and they turn out to be bigger than expected and the management processes are bespoke “DevOps”-style processes created way before the term was even known.

Instead of working with hundreds of servers, you’ve got thousands. All of which need some form of discovery and management.

But the main concern here is time – the longer your team is onsite, the more you find out. Every technology environment evolves over time so of course it will take a while to get a full picture of it.

2. Legacy Software and Infrastructure Overhead

Now your team is onsite you learn the percentage of legacy apps is higher than anticipated – in one area they even run DOS applications. Your discovery team discover the customer-facing systems are web applications as originally agreed and expected but the back office is a myriad of tools from the 1990s and beyond – all running on legacy hardware that needs replacing. Again, adding to the software and hardward inventory but more importantly widening the number of IT stakeholders to discuss both technology and policies.

3. Security challenges

A survey from West Monroe Partners stated More than a third (40%) of acquirers said they had discovered a cybersecurity problem at an acquisition after a deal went through, indicating that standards for due diligence remain low.

http://www.westmonroepartners.com/Insights/White-Papers/security-survey.

There can be many reasons why security was overlooked:

• The deal pressure, the need to get things done
• Lack of single points of contact / responsibility
• Lack of clear security policies
• The security culture and policies between the companies differ

There may even be moments when the team knows they need to consult with the security team but decide not to intentionally so not to create a delay. But these teams exist for a reason, and time spent here in regards to delay may pay dividends. What if a security hole is created post-integration? What data could be stolen or leaked and what could that do for your company reputation?

4. Hidden Costs

During initial meetings it is worth considering the question “What did it take to get the (target) company to where it is today?”. Computer systems organically grow and with growth additional complexity is built-in. Which is fine until you need to transform or move the systems.

For example: Bespoke script and code that has been keeping the company systems and revenue generating systems going for years a black box system that no one wants to amend for fear of impacting company revenues but you learn it does not comply with your corporate standards. Whatever the technical solution is the time to discuss and agree a way forward will cost your timeline and impact the bottom line. The bottom line – if there is the need to update said system there might be the need to contact the SME who may charge extortionate rates.  At one firm I assessed one of the business systems was written years previously and maintained by a talented individual -so talented he managed to buy a yacht from the fees! 

Some questions that will help this early in the discovery process are:

• Is the IT team smaller than it was previously?
• Were more FTEs and contractors needed previously to build and maintain the systems?
• How is the car park looking? Many vacant spaces?

Even if it does not impact your Day One transformation it is essential communicating any risk of unexpected expenditure for Day Two.

5. Use of Open Source Software

When you team assess the target company’s bespoke software, it transpires Open Source components are being used, which is not a surprise as Forrester Research state 80% of companies appear to be doing so.

As part of the software analysis phase your team will need to examine the components and devise a way to manage the Software Assessment. You’ll need to reach out to vendors Black Duck Software, Flexera Software, Sonatype, Synopsys, Veracode, and WhiteSource Software to work out which works for you.

Once you discover the Open Source components you will need to determine how the team will identify and record if these components are a risk – e.g. from a licensing, support and if the security standpoint.

6. Cross-business Compatibilty

Not only does an entire technology environment need to be assessed for existence, risk and issues.  Your team also needs to consider compatibility – not only from a technology standpoint but also with new corporate standards.  The higher ticket items such as CRM and ERP will always be immediately assessed but there may be differences in technology stacks – virtualization stacks such as VMware to Hyper-V, versions of server software or what versions of database software are allowed in the new organisation.  If there is a compatibility issue at the infrastructure software perspective, how is the application-layer impacted?  

Whilst there may be technical differences, the art is getting the cross-company teams to agree a solution going forwards and this will be affected by the differing IT cultures, policies and appetite for risk. 

Whatever work-arounds or actions are finally agreed, there will be an impact on the overall timelines and budget.

7. Performance

In addition to the services, software and hardware inventory you need to ensure the team collects information on the current performance statistics.  You could assess from the lower levels – networking, storage and processing, the virutalisation levels (assuming most companies are off physical kit where possible).  You need to be aware of current performance bottlenecks, shortages of resources and conversely areas where the technical teams know the performance is good.  This will allow the solutions and technical architects to build-in appropriate capacity in the new world.  

But what may arise is poor performance due to application architecture – something that will not be addressed unless you have time and money on your side.  What tools can your team already use to assess the business application estate perfromance and is the inforamtion up to date? 

Summary

At the heart of an effective discovery are the people and teams. The right environment is needed to provide effective rapport between teams from both/every side early to create a more effective team and overall change process.

As Simon Sinek has clearly shown the world, we must start with why in order to bring people on-board with the M&A IT project. If fully engaged the M&A IT project team will do their very best to discover and record the environment.  

IT Due Diligence for a M&A transformation is a very wide subject – and it’s very complex.  What stories do you have to share?

{{cta(’23b74a59-42a2-4a7c-8ded-6111a29634b7′)}}