Lately, I have been thinking about the importance of questions in integration planning. Every company faces the same core challenges: invoicing, payroll, on-boarding. However, everyone solves them differently, and overlooking it is where the post-acquisition integrations tend to go wrong.
To avoid this, you ask questions. Yet it is the perspectives of those involved in the integration planning that shape the questions being asked. That is what prompted a recent webinar.
The perspective can be shaped in several ways: the type of thinker you are (detailed or strategic), your experiences, and exposure to different bits of information. When it comes to the types of questions you are asking, the perspective shapes the view you are building.
Someone on the executive steering committee will look at the post-acquisition challenges differently than the project management office in charge or the team doing the implementation work. For the executive steering committee, they will be looking at the strategic focus and ensuring they get the appropriate ROI from the acquisition. The project management office will want to ensure the integration work is completed in a timely fashion and within the expected budget. Lastly, the team doing the implementation work will need to know what it is they are doing and where they are going.
This becomes a growing concern during the post-acquisition integration planning, and the impact will increase as the integration work continues through the implementation. The missed questions will usually reveal themselves in the middle of the integration work: the missed dependencies on the acquired company’s infrastructure that you will need to account for, or the missed vendor integration that may result in a substantial part of the acquired company’s business.
For missing dependencies, this will normally be where all work stops until the missed dependency can be addressed. As a result, deadlines will be missed, and resources readjusted.
There are two perspectives that need to be called out that can be dangerous when it comes to the integration planning:
- Viewing IT like any other asset.
- Fitting the acquisition into how your company has always operated.
When you don’t account for these perspectives, and you are new to these types of projects, you won’t know what to ask. As a result, your first instinct will be to google ‘post-acquisition checklist.’ This will give you a list of software and hardware that will need to be migrated, but doesn’t tell you how.
Viewing IT like any other asset
When you look at IT just as any other asset such as a cash register or company car then you will make some assumptions and miss out on a few nuances that will save you considerable time and money when it comes to the actual integration.
When you assume that IT is any other asset, then your first instinct will be to just bring everything over: the desktop and laptop systems everyone uses, the servers, software, etc. The idea is to make as few changes as possible to keep everyone productive, minimize impact, and deal with the merging processes later when there isn’t a time clock to deal with.
This is an approach that I call lift and shift.
The problem with this approach is that it is a lot more complex and expensive than it first appears.
The biggest thing to keep in mind: every company usually ends up running into the same challenges from invoicing customers, buying and selling products, on-boarding and off-boarding employees, etc. The way each company solves these challenges is what becomes their process, and it is the job of IT to codify and streamline these processes.
These processes are codified in software using tools like NetSuite or SAP for ERP, and ADP for payroll, etc.
Just as your company has solved these challenges with software, so did the company you just acquired.
For example: one of the first things you will need to do is merge the financial records together. Taking a “lift and shift” approach, you will have to figure out how to merge the resulting data going forward. This means you must pay for the licenses to their system, the people to maintain it, and now you need to find resources to consolidate the reporting.
What would an alternative look like?
Realizing that you both have similar processes, what if you were to migrate the data over into your system? This would have the up-front cost of the migration (which you will need to pay for anyway if you were to lift and shift things over), but now you don’t need to pay for the support or renew the software license going forward. Plus you already have a team maintaining your current system.
The challenge is that you need to know how to do the migration. For example, if you were migrating a financial system, some of the dependencies in their system and your system will serve different purposes. Some dependencies may need to be migrated over, and others can be safely ignored as no longer needed, or already being done by you.
With this perspective, you are doing more than just inventorying what to bring over, but also mapping out the dependencies and their underlying processes.
Fitting the acquisition into how your company has always operated
This is something I have seen first hand with previous clients. They do have some technical expertise in-house. However, they are also biased based on the groups they represent.
What does this mean?
The approach and types of questions feed into the department or group the questioner knows about. For example, if they represent the company’s cloud team, then the line of questioning will reflect not just the cloud infrastructure, but their cloud infrastructure.
This poses a couple of challenges:
- If either side are heavy users of a specific vendor, then there will be a lack of familiarity with that vendor’s specific offering and being able to identify alternatives.
- The narrow focus will miss the larger picture of identifying hidden dependencies that will impact the integration work.
The first challenge highlights the dangers of being too dependent upon a vendor and their ecosystem. Your technical expert will know their ecosystem incredibly well, and your company will have tools that are deeply dependent upon this vendor. The question becomes whether your technical expert has broad enough experience and exposure to know what to ask to plan out what a transition from the acquired company will look like, or if the underlying components even need to be transitioned.
The second challenge is perhaps more dangerous. This leads to assumptions on how the acquired company has implemented and managed their tech stack. This means the technical expert will assume certain processes and forget to ask certain questions used to determine whether certain components are needed, if they have alternatives, and how they are managed.
More importantly, they will assume certain behaviors and flows based on the lines of business and customers they normally interact with, without understanding how those will change as well.
Lastly, and one of the key takeaways, is that when you assume how the interaction flows into a given system, then you will forget that each company has solved the same problem differently.
When you assume the approach these challenges have been solved is the same, then you will miss the underlying dependencies that drive the systems being migrated and integrated.
How do you change this?
Borrowing from my experience as a sustaining engineer at Sun Microsystems, whenever we looked at any issue, we first established a baseline between the two systems. Next, we looked at where we want to go. Lastly, we would tease out the differences between the systems to align it with that destination.
The webinar touches on this aspect as the final concept. The idea is to look at who the users are for each system being migrated. Next, how they interact with the system to determine the flows and underlying processes. This should be enough to determine what you need to know to have a tighter plan.