IT Due Diligence – is a strategy assessment, not an audit.
As more companies depend on technology, IT due diligence is an essential exercise prior to an acquistion or investment.
Meaning there is greater demand for clear and concise IT Due DIligence and reportting from M&A market. The impact of due dilignce is significant – as it obviously impacts the investors and their decision-making process, but it also impacts the workforce at the target business.
So an assessment cannot be taken lightly and needs to consider the wider strategy, not just where we are today.
Having spoken to and worked with many investment professionals it became clear that they have had experiences where the future technology costs were not fully assessed, this is becuase an assessment of the technology roadmap has not been made, nor a vald costing of the proposed strategy.
What is IT due diligence?
In the context of post-merger integration, IT due diligence is the need to locate and understand the technology estate, including key intellectual property. Easier said than done! Corporate technology estates evolve over decades, and you are expected to inspect and bring everything to the surface within months. Read that again – entire corporate estates that took years to build, to be fully assessed within months.
Imagine buying a house or car and before being able to use it having take it apart, find all the associated components and how they connect, and then produce a meaningful and comprehensive report within a short period of time. Also with the added pressure of knowing that if your report is incorrect, the car might break down, or the house collapse. Okay, that’s a little dramatic, but you get the point.
Technology due diligence as part of an M&A deal can be make or break. If the team misses even 5% of the information, the entire project approach, associated resources and budget may have to be reassessed. You can imagine how going cap-in-hand to the board will go down with the C-suite and your own team.
Some of the key questions are outlined in this article, Critical Questions to Ask during Private Equity Technology Due Diligence.
What should you be looking for from a due diligence exercise?
Given enough time and experienced talent, every post-merger integration team should be able to find services, applications, hardware etc. That’s a given. Therefore, I think the main deliverable from this phase of M&A transformation is credibility:
- You need access to systems and sensitive information
- You need to consider how what the team finds will impact the plan
- You need to persuade the project board that you have a complete Service Catalogue
- You need to demonstrate to two or more technical teams that you know what you are doing
All of this takes enterprise experience, customer-facing consulting skills, and the ability to sense when things don’t sound right. If you get through the due dil exercise you’ll have certainly built rapport and credibility across the teams and across many businesses, and probably in many cultures and countries.
How does IT due diligence differ for post-merger integration?
On the surface, it may seem like the due diligence effort is not much different to a ‘normal’ enterprise transformation programme, such as an enterprise application consolidation, or enterprise desktop refresh, but the following factors amplify the risks:
- Multi-party/multi-company technology teams
- Differing cultures and technology policies
- The impact of different policies and how technology is implemented at either firm
- The ‘entry requirements’ across firms – what is acceptable at one may not be at another
- Software is potentially being moved to another company
- The financial impact of transferring or novating software licensing
- Delays caused by technical unknowns or vendor support and flexibility
In addition, it is critical to understand the systems and whether these are ‘acceptable’ in the new world IT environment; for example, the acquisition may be running a critical application on what is deemed an unacceptable configuration or platform in the new firm.
Where do you start?
It is almost certain that a high-level view of systems will already be understood, as this would form part of the M&A deal, but this may only cover a percentage of the application estate. Whilst a company may have a small number of these ‘above the line’ systems, they are likely to be running hundreds or even thousands of applications. These need to be assessed and put into the plan.
During the ‘Examine’ phase of the managed M&A you will need to:
- Interview IT stakeholders to gather key information
- Develop a detailed CMDB of assets
- Develop a project-specific catalogue of services that can be used to plan and manage the transition
- Create and manage the list of support contracts
- Create a company-wide software inventory and ensure the licensing implications are understood
- Record IT finances and contracts
Regardless of effort there will be some surprises on the way, but it is imperative to carry out a quality assessment, given limited time and resources.
As stated previously, in the early stages most people across more than one company will be sizing-up whether you’ve delivered Post-Merger Integration of this scale before. Unlike a standard technology projects, you potentially have their systems and careers in your hands.
You need to nip this in the bud so that the team will focus on the project, not your capability.
In some cases, I have been blatantly asked (in an aggressive tone) “Have you done this before?”
If you have previous Post-Merger Integration experience, share it. But only if it feels appropriate and you have permission to share that information. You need to do this sensitively, outlining the usual shape of a Post-Merger Integration project and some of the things to consider and look-out for.
Consider documenting a one or two-page outline that can help address this problem and use some of the lessons learnt from previous projects in your information pack.
Stakeholder challenges
Using the information, you have gathered so far, you should be able to create a stakeholder map of the people, their relationships and how they will help the Post-Merger Integration project.
A stakeholder map differs from an organisation hierarchy as it’s a pragmatic view of people who will be useful an against each stakeholder you need to establish:
- Key players
- Their influence
- What’s in it for them?
- How they can help advance the project?
- Their key interest and motivations?
- Their fears?
The map can be useful see things clearly when problems occur, especially for complex multi-party programmes.
For a template, see: https://www.stakeholdermap.com/
Workshops
It is tempting to run team-wide workshops will commence but they can be a waste of time.
One benefit of group-wide workshops is to determine who will collaborate and help versus who will become an obstacle. So it’s worth having a workshop or two but resist the temptation to have too many.
Often, the feeling that the entire environment is so complex that it necessitates an inordinate number of workshops and the need to invite all the key people from both teams – imagine the waste.
In these meetings many people won’t participate and there’s no major benefit of all of the staff being aware of all the historical decisions made along the way.
Higher-skilled technical people often miss meetings rendering the workshops ineffective.
Benchmarking challenges
As part of the technology team from the buy-side it is likely you are one of the first people the technology target team after they hear the news of about the acquisition.
You may immediately face a challenge as you need to obtain confidential information about their business, but you have not gained trust from the key stakeholders. They will be sizing you up whilst you are trying to gain their trust and information.
Firstly, you need to determine quickly who they key stakeholders are (easier said than done in a large business) and secondly, you will need to demonstrate some credibility that you have done this before in order to gain their respect.
CMDB challenges
In order to deliver a successful project, you need an accurate inventory.
It is common for broad-brush estimations and assumptions to be made about an IT environment due to the size of the target firm, but beware. You may find the technology estate is much bigger or smaller than anticipated.
Without an accurate inventory it is impossible to plan accurately. Without truly knowing what’s there you cannot establish what to do with the systems and more importantly who you need to work with to ensure they are transferred correctly into the new environment. This is the same for all IT projects, but the difference with an Post-Merger Integration is that it is a company-wide concern.
Worse still, if you cannot determine what’s there you are unaware of your risks – for instance will the systems from the target firm meet your company security requirements? Is some remediation work required? Are there legacy systems that are on their last legs? It is very common for projects to be stopped mid-flight, to a complete standstill, due to some disagreement that occurred due to an inaccurate CMDB.
Service Catalogue due diligence challenges
An up-to-date Service Catalogue allows the Post-Merger Integration team to build a clear picture of the services to be transferred, and organise the delivery of these services into the new world.
You need to know what the services are to understand how they will be transformed (migrated, upgraded, or decommissioned), how they will work in the new world, and to be able to hand them over to Service Management to be managed post-Day One.
It is likely that some of the software within the catalogue is key IP that was part of the reason the buy-side wanted to buy the acquired business.
The main challenge is creating a clearly defined list that all parties agree to. In addition, the Service Catalogue has contractual ramifications, both early in the agreement and post-implementation, so its accuracy is key. The catalogue can be expensive to produce as it requires expensive talented resource and they need time to produce.
Support contract due diligence challenges
The Post-Merger Integration team needs to fully understand the financial burden of the technology service and a major cost component is the ongoing vendor contracts
The Post-Merger Integration Team will need to uncover and document the current support contracts that are in place for facilities, utilities, hardware, software and managed support to get a clear picture of the current agreements in place.
Your team needs to establish which support contracts can be moved over or novated across to the buy-side firm and by doing so you are effectively “lifting up the carpet” on the financial agreements between the target company and suppliers. By doing so you may awaken a dormant account to a salesperson at a supplier – who may see the transition as an opportunity to mandate an expensive upgrade or transfer fee.
You will also need to identify which support contracts will take time to remediate. For well-known major vendors they will already have written policies available online and partners who can ease the process. But for specialist software written by small software development firms you may need to go into negotiations will may take time.
In addition to the time this will take you really need to de-risk this process by establishing as much information as you can as quickly as possible so you can benchmark the current position and establish the work involved.
Financial due diligence challenges
It is essential to understand the running costs in more detail than was established during the M&A deal Due Diligence phase.
In addition to the usual facilities/hardware/software costs it is critical to unearth hidden costs and temporary costs – especially if the target business develops software.
But your team also need technology experience so that they can correlate behaviour with cost.
For example, if there was a major release in the past 12 months is there evidence of additional (and expensive) software developers on the team. The target technology team may be running quite lean today but it may take a lot more cash and resources if major updates are planned in the coming year.
Software challenges
Even in a small acquisition, the software estate will be complex. From a high-level perspective you will need an inventory of the software used across services, servers, desktops, laptops, and mobile devices. Then, once you have a comprehensive overview, you will need to whittle it down into a workable list. Following that, you will need to establish the interfaces between software (both internally within the company and with partner companies) and then start to examine the licensing overhead.
If the target company also develops software in-house that is consumed by customers you will have a bigger task on your hands, as you will need to assess the licensing of the components they utilise to build their software, considering the licensing allowances that vendors give developers (in layman terms, ensuring that the developer licensing is not being utilised in production!), and lastly, their use of open source software and any risk that this may present to your company. It is estimated 80% of developers use open source, so it will likely be lurking around somewhere.
Summary
This is not an exhaustive list, but it provides a flavour of the auditing task ahead and the associated complexity.
It will help if your team can be both impartial and practical – i.e. don’t judge how software was implemented previously, and be very understanding of why the target software estate got to where it is today.
If you can manage to approach it sensitively, the project will be easier, as it is likely they will gain the trust of the target business and thus have access to the necessary and correct information.
This is one part of a series of five blogs on how to deliver a successful post-merger integration, the other sections can be found here:
5 Post-Merger Integration Challenges: Part One – Employee Engagement
5 Post-Merger Integration Challenges: Part Two – IT Due Diligence
5 Post-Merger Integration Challenges: Part Three – Planning and Design
5 Post-Merger Integration Challenges: Part Four – Day One Cutover
5 Post-Merger Integration Challenges: Part Five – Evolution
{{cta(’23b74a59-42a2-4a7c-8ded-6111a29634b7′)}}
