Mastering M&A Integration

This is a conversation with Seema Nimogata, Head of M and A Integration for North America at Woven by Toyota. She started out as a software developer and then transitioned to product management which led her to product and technology integration M and A. In this interview, she shares her experience on how to master M and A integrations. We talked about M and A integration planning, pre loi, setting up an early version of the imo, detailing the M and A integration strategy and aligning deal goals with the integration strategy. This episode is brought to you by Firm Room Searching for a data room that offers simplicity without compromise? Elevate your data room experience with Firm Room, the world's most intuitive virtual data room. Try it free for 14 days, no strings attached. And when you're ready to power up, sign up for unlimited users and 10 gigs of storage at a flat rate of 495 bucks a month. Boost your team with Firm Room, a tool built by dealmakers for dealmakers. Check it out firmroom.com again that's firmroom.com I'm Kisan Patel and you're listening to M and A Science where we talk with deal professionals and learn valuable lessons from their experience. This podcast focuses on stories, strategies and what actually happened during M and A deals. Hello M and A Scientists. Welcome to the M and A Science podcast where you learn from the best in M and A to uncover proven techniques for enterprise value creation. If you're interested in learning more by the products and services we develop to support world class M and A teams or want to get involved with the community of forward thinking M and a practitioners, visit Masscience.com you can get started by subscribing to our free weekly newsletter for the latest insights and events. Again, that's mascience.com I'm your host Kisam Patel, CEO and founder of M and A Science. Joining me today is Seema Nimigata, Head of M and A Integration for North America at Woven by Toyota. Woven by Toyota is the mobility technology subsidiary of Toyota, creating and managing Toyota's software for automated driving and safety. Today we're going to talk about mastering business integrations in M and A. Seema, how are you doing today?

I'm doing great. Really excited to be part of this podcast.

Thanks for taking a break from doing massive integration projects to have a conversation with me. Could we kick things off a little bit about your background?

I started at Woven more than two years back. I had, as you mentioned, the M and A integration for our North America region. Prior to Woven, I worked at KPMG G Digital, Cisco. I've also worked at a few startups. That is where I'm at home at Woven, because essentially we are like a startup acquiring and building business. I started my career as a software developer and then transitioned to product management and services management. So when I started working on M and A integrations, I started with product and technology integration, services integration, and then I had opportunities to lead integrations for some of the business enablement functions or back office functions like HR and legal and finance and it. With my overall experience, I really enjoy leading the IMO here at Hoven.

We love engineers here at M and A Science. It just brings like a different skill set to the industry. I think after doing enough of these interviews. It's this whole problem solving approach that you learn through an engineering background that you don't always get when you come up through finance.

That's true.

Could you tell us a little bit about Woven? A lot of people are familiar with Toyota, but a lot of people aren't familiar with what Toyota is up to with their Woven business unit.

We are a fully owned subsidiary of Toyota. Our focus is to create innovative mobility product technology and services. So one of the focus is of course building the autonomous driving for Toyota. And our presence in North America is solely through acquisitions. So we started with the acquisition of Level 5, which was a division of Lyft and we did few more acquisitions in US and in uk. And the goal is to support Toyota to bring the mobility solutions to the world and to simplify. So the goal is mobility for all and safety for all. So that is the motto that we drive for Toyota.

Not to mention you're building an autonomous city outside of Tokyo.

Yes, Woven City is one of our initiatives where we plan to demonstrate our technologies. That city is built at the base of Fuji, which is like the North Star for all of us.

It's going to be awesome to see that come together. Can you give us an overview of the typical integration process?

So a lot of times you'll hear that integration. Let's think about it. Once we close the deal, it is considered as an afterthought. That is where we see a lot of the deal failures. Because of that approach, I'm a very strong advocate of bringing in integration as early as possible in the deal life cycle. So right when you are structuring the deal, building your deal strategy, that is the right time to bring in integration and start building your integration strategy in parallel. So as you are doing your early or confirmatory due diligence, the integration process should Start, you don't have to pull in the entire integration team, including all work streams or functions at that time. But depending on the type of the deal, you can pull in the key workstream leads into the picture. And as you go through the due diligence process, after you sign the loi, that is the time that you start pre planning for your integration build your integration roadmap. And that's of course very iterative process. But if you get a good head start during that due diligence period, that is what will lead to a successful execution of that integration strategy. Once you close the deal, you can enhance your integration plan that you have put together and then increase the scope, pull in additional resources and additional functions into the mix, and then execute on that integration strategy. The key is to have that integration process aligned with your deal life cycle.

This is the biggest theme that we're seeing in our industry and it's only going to continue through 2024. Is this emphasis on really planning integration well so you can ultimately execute it well. Why is it important to think about integration capabilities even before finalizing a deal?

They say that more than 70% of the deals fail. That high failure rate can be directly attributed to integration that is not planned correctly. It is very important to think about your integration, as I mentioned before, as early as possible during the deal life cycle. But in order to build your integration capabilities ahead of your deal is really critical. You may not have the luxury to have dedicated integration resources at your disposal. You have to leverage the leads from different functions. They will have their day jobs to do, and this is going to be an additional responsibility that they will have to take. If you have the time to do that planning beforehand, try to engage the right leads from each of the functions and prep them for the integration. If you have playbooks that you have built based on your prior experience, you can leverage that so that you can build that muscle in the company and build that culture for M and A in the team so that once you have the deal in front of you, you've done your homework and you're ready to tackle the that specific deal. Because every deal is unique. However you prepare, there are always going to be new situations, new problems that you have to solve. But at least if you have the base aligned, then you can take on those complexities of a specific deal based on your team that is already now familiar with the base integration process and the capabilities that are required to execute that kind of a deal.

I'm under the impression that pre loi, there's really Not a lot you can do with integration planning. I feel like you're just so limited on information and you're ultimately focused on building a business case that's going to get approved to do the deal. What are your thoughts on that? Is it my off? Is there stuff you can actually do? There's certain things that you actually really push for.

I totally agree that pre loi you definitely have a lot of restrictions, but within the constraints you can still bring in the right leads. Make sure you can leverage the NDA so that you can keep the confidentiality and maintain the restrictions that you have. But I think it is really important to pull in the right leads. For example, if you're looking at say an acqui hire, you definitely need to pull in your HR leads up front because then you can plan how you are going to build that strategy to retain that talent. If you are acquiring a new technology, then it is really important to bring in your product and technology leads, bring in your operations leads so that you can integrate and launch that new product as part of the integration. And so, depending on the type of the deal, identify the critical work team leads or critical functional leads that you need. And then once you sign the loi, bring them into the discussions, involve them into the due diligence and make sure you ask the right questions. And it is important to involve the right counterparts from the target too. Again, with NDA you can definitely restrict the audience, but at the same time you can make sure that you have the right people involved so that you can gather the critical information which is going to allow you to build your integration plan and integration strategy. Again, maintaining that tight alignment with the deal strategy that is going to be the key.

Okay, so it's not a whole comprehensive effort. I'm going to bring all the people in from integration pre loi, but identify key value driver. Then I can get a sense of who's going to be critical to delivering on that value driver. And I ideally want to pull them in to start getting some validation or thinking as we put it together in loi.

Absolutely. Yeah.

Okay. Awesome. And then it sounds like the bulk of this stuff happens from LOI to close.

Yes, I think bulk of your planning is going to happen during that phase as you do the diligence. And obviously you'll always have the caveat that you cannot pull in each and every individual into the mix yet because you haven't closed the deal. But to the extent you will have your first world versions of the integration strategy, define integration plan, develop and even you will have your work stream or functional plans. The draft version should be ready by then. You should have at least a good idea about how your target operating model is going to look post close. You will have a good head start on those key deliverables by close and then definitely it will become an iterative process that once you do the detailed discovery after close, you will change certain things, your plans will evolve, and then your focus will change from day one to day 90, day 100, day 300, depending on the type of the deal. Whatever horizon you are looking at for the integration completion, you can continue to enhance and retreat your planning after close.

How do businesses ensure they have the resources and capabilities in place to successfully integrate a company?

A lot of you may or may not have that luxury to have dedicated integration resources or capabilities in place. The best thing to do is when you have a downtime, say right now you don't have any active deals going on or you don't have a very active pipeline. That time should be leveraged to build the capabilities and then identify resources in each of the functions. Your hr, finance, legal, et cetera. And try to do some workshops, train the resources. If you have playbooks that you have built, try to leverage that to bring everyone up to speed. Based on the lessons learned from the past acquisitions, you can identify specific areas that you need to focus. You may have expertise in certain areas already in place, but then I'm just making it up. Your it could be an area where you need to build more capabilities so you can identify those gaps or areas that you need to focus for your organization and then start building that expertise. That is how you can make sure that when the next deal comes through, you have the right resources and you have the right capabilities to tackle that deal.

Kind of have to do one deal to really learn some key lessons the hard way and then you build off of that and start doing your retrospectives and say okay, here's where the gaps, here's things that we can really prep for. Then especially if that downtime, you can utilize that for some proactive preparation for the next deal?

Absolutely.

Is there a way to like not get burnt on the first deal to get us building out an integration program?

It again depends on the maturity level of your organization. For M and A, if you have done deals in some capacity in the previous life, then you are familiar with how the deal lifecycle goes through and the pitfalls of integration and you can plan not to have any burnout but like woven where we didn't have that past expertise in all of our other functional areas. So it was a huge burnout after the integration. Being proactive and then planning ahead would be the key to avoid that burnout. And of course, taking advantage of advisors and resources like M and A Science, I think is a great way to prep for the upcoming transactions to raise that level of maturity for the organization using these resources and tools that we can leverage.

Say it before and I'll say it again, your peer is your most valuable asset. When you get stumped, that's your group that's going to help you out. Let's help out the companies that are going to go through their first deal and try to help them avoid some of the big painful lessons here. Can we break down the major milestones, slash steps in integration, particularly from the LOI to close stage?

We definitely want to bring in the integration as early as possible in the deal life cycle. What I have seen or what my personal preference is, the Integration Management Office I think is really the best to lead the overall due diligence process because end of the day it is running tight governance around the diligence, making sure that the Integration Management Office has the right involvement and the right lead to lead that overall diligence process. After loi, that becomes one of the key steps to make sure that we can have the right integration plan and strategy built. The first milestone would be to set up the first version of your imo as we discussed. You don't have to bring in all the functions, all the work streams into the mix, but depending on the type of the deal, bring in the key leads and start that IMO version before you sign the loi. And then the second milestone would be to come up with your integration strategy which is very tightly aligned with the deal strategy. The next milestone would be to build a high level roadmap or a plan for integration. And again, it's going to be iterative, it's going to be enhanced. But having that starting version is really important. And the most important milestone is to socialize that integration strategy and integration plan with the key stakeholders, including your deal sponsor and all the functional executives and getting their buy in, getting their commitment for the resources that you expect from respective functions. That is a key milestone. These are the things that you should focus from that phase once you sign LOI before you close.

So first step is build out this early version of the imo. Integration Management Office made an interesting point about the integration Management should ideally lead due diligence. I'll come back to that with a question and then from there this is when you're defining the actual strategy of integration and then you'll actually define the plan, slash roadmap. And you're taking this as a pretty iterative effort as you continue to gather information and then you will socialize this with the key stakeholders, which includes the deal sponsor. Is that functional leads from both sides at this stage?

Because this is pre close, you may or may not have that much visibility. But again, two in the box is the right way to go. And so if you can actually get some kind of commitment from the target side, that is awesome. That definitely will first of all make sure that the target feels involved in the overall integration process. And so you are going to get a lot more constructive response or participation from target during the overall integration process. So I definitely would recommend involving stakeholders on the target side as well.

Can you explain briefly what two in a box is? For those that don't know and people like me that don't remember, it's typically.

When you think about building your integration strategy and integration plan, it is the acquiring side which is doing that. But again, if you really want things to work, actually it becomes instrumental to involve the target side. And so two in a box is your IMO has a counterpart from the target side. Your each work stream has a counterpart from the target side. And so you're putting the acquiring company and the target two in a box when you are building or designing your imo.

Thank you. The idea of the IMO leading due diligence. I'm curious your thoughts around structure. Because if you look at traditional structures maybe super early, it's like you have one corp dev team and then integration becomes an afterthought and then it finally becomes a real thought and then all of a sudden it's standing up a separate integration team. Then you end up with this whole knowledge chasm between diligence, integration and then a bunch of other friction and misalignment on strategy and things like that happen. The idea of the IMO leading diligence makes a lot of sense because they'd get all this access to the information they really need to successfully execute integration. But the structure behind that is it's still two teams and you're just enabling the IMO team to run diligence. Or are we thinking of a structure that's more of a combined? Essentially the integration people are within corporate development. How do you think about the structure of that overall?

There are different scenarios that we can talk about at Woven integration is part of the Corp dev team. In my previous life there have been cases where integration is outside of the corp dev team as well. When you look from a deals perspective, it is still one team and in that sense it really becomes very efficient if IMO takes lead into running the diligence process. Because essentially it is program management at that level, just running the governance for the overall diligence process. And even if your IMO sits outside of the corp dev, you work very closely with the corp dev team. With the deal leads who are involved as part of the diligence, IMO can still provide that governing or program management function for the overall due diligence cycle and involve the stakeholders, right? In this case, cogdev is the big stakeholder and then based on the deal you would pull in respective functional leads. Even if your IMO is structured outside of CogDev, I don't see a problem IMO running the overall diligence process. Have you heard about any examples or issues where that has been a problem? When you work with different organizations or with your different clients, have you come across situations where that hasn't worked?

I feel like it's so much around the culture of the company itself because if there is all of a sudden it's like this is mine and it's very like distinct separation. I think that's where a lot of the friction and problems come because you could have it separate and if there's a culture of a real partnership there, then you don't have that point of friction. But then there's a lot of these old school companies that just haven't changed their way in 20 years and you could tell like it is purposeful two weeks before the deal closes. Well, let's give them a heads up. That's a scramble for them to figure out what they're going to do for integration. I think a lot of the company culture itself is actually the biggest influence.

That is true. But for companies like us who are, as I said, we are essentially like a startup, it is a small team, everybody puts multiple hats and I haven't seen any cultural issues with this approach. And actually the deal leads are happy if somebody's taking the overhead of running the overall process for due diligence. They can focus on the actual substance of the process and focus on their areas that they need to go for due diligence. And IMO can take care of the overall program management or the governance aspect of the daily process.

That's the key advantage is having that startup culture where it's very growth oriented. People are very much oriented around change in the company and the ones I just Spoke to a practitioner yesterday that is ready to move on because they're in a role. It's stagnant. The organization refuses to make these changes. They're just frustrated and tired of it when they know the industry itself has moved on in a different direction. I'm wondering if you've ever seen that where the large corporate M and A team that has been around has a very mature function. What does it take for them to actually adopt change?

Yeah, in my previous life where I have worked in big companies, you do see because it's a very well oiled machine and the process is really well set. And so then you happen to stay in your not silo but in your swim lane when it comes to the overall M and A integration process. The problems of that is then you don't have the visibility over the other areas and then you lose out on anticipating some of the problems that you might face because you just didn't have any exposure regarding those areas. One way to overcome is if you have dedicated teams and you can afford or if you have enough resources to run separate parts of the overall integration process. Making sure that you have transparency between all the teams becomes key. The way you manage the information, making sure that your document repository is open to everyone and so people can actually check the required details, go through the diligence findings for other functions. Even though it may or may not directly impact you, that would become the key and that would be a way to overcome having IMO taking over the diligence process management piece. You can still have the respective parts of your deal team in that process, but at the same time opening up the information for everyone and making sure the access is there.

I like your optimism about driving change in these large organizations. I'm going to definitely drop your name when I hear somebody struggling with it. I want to run through those key areas that we talked to and we talked about. The reason for IMO leading diligence makes sense. When you say setting up an early version of the imo, tell me more, what exactly do you mean by that?

In the beginning again, before you have done the due diligence, you don't have your integration strategy in place. You are not sure what is the scope for each and every function or work stream. So setting up the IMO which encompasses the entire integration is going to be difficult. It is important to identify the key work streams or key functions for the deal and then picking up a lead for that and setting up that starting version of IMO becomes key. In the beginning, it could just be the imo, lead with the HR workstream, lead with finance and then depending on the complexity, pull in people from the product and technology, pull in people from your it, sales, gtm, et cetera. And so it's just a mini version or a mini IMO I would call it, based on the deal specifics.

Okay. So we're really identifying people. So if I'm going to buy this company out, it's a competitive product, for example, and a lot of it's around integrating their capabilities into our product. And then there's going to be a lot of lift around migrating customers. And at that point I'm going to start identifying HR because we have a lot of people moving around. I'm going to identify the tech leads because we're going to be integrating technology. And then I'm going to integrate the sales team, we're going to integrate Salesforce. So I'm going to bring my sales lead involved. That's how I start shaping it out. In terms of setting up the early version of the imo.

Exactly.

We start there. Once we have that established, I want those people involved to start defining the integration strategy. Who's involved with that.

So yes, you definitely would take their inputs to build your integration strategy and for their specific functions or specific work streams, you want to build the plan for that and that is where you will start discovering what are the dependencies. For my sales team to build their plan, they need some inputs from the product team and then the product team will say that for this I need some inputs from my infrastructure or IT team, what infrastructure I need to support the capabilities of the combined product. You start building your functional plans along with the overall integration plan with the inputs from these leads and that is how slowly you will expand the scope and bring in other leads into the overall process.

I want to separate like defining the strategy versus defining the actual plan. And what I'm trying to get an understanding is when we define the strategy. If you can help me understand the granularity that we want to get to in detail around defining the strategy. Because I can put it in one sentence and say we are going to integrate this company and put their features in our product. Great. That's our strategy. Give me your take. How much level of granularity in the details do we want to define this strategy?

The level of details that you need to include when you build your integration strategy should be enough for you to actually build or take that next step to build the plan which you can actually execute. Just having one high level sentence is not enough. Again, let's say one of the deal driver is to combine the product from the target and build it as part of your product portfolio and take it to the market. Then your integration strategy is going to be build the combined product, make sure that you are ready to take it to the market, set some timeline. You want to do it in six months, one year, whatever is the timeline. And when you are able to offer that combined product to the market, that means it has to be aligned with your product development process. You have to have the right pricing in place, you have to have the right marketing in place. And so building it to that level of details should be covered as part of your integration strategy. And then you do that. Next double click to build the actual plans for individual functions or work streams in order to achieve that strategy.

Yeah, it's almost like you're getting to a level of detail so that the strategy makes sense to every functional lead.

Exactly. And then that's why it is really important to socialize that strategy and get the buy inside. When you say that oh my strategy is to have that combined product out in the market in six months and you will definitely have some of the functional leads raising their hands. That it is impossible because we don't have this capability or whatever may be the reason that early socialization becomes key. Again, to vet your strategy with the deals and to make sure that it is a strategy that you can actually execute on with the right drivers.

What does it ultimately end up being as a final product? Is it like a PowerPoint slide 5 page document?

That again depends on your company. I don't think format becomes that important. It could be a PowerPoint slide, it could be a document. Format only depends on what your company is used to. But having that clarity where you are able to show based on the strategy, your functional leads are actually able to take and build their own roadmaps and plans. That is what is important. How you want to build it is totally up to you. We are a Google shop and so we use Google Slides for everything. Our strategies are laid out in that format. But again, you could use documents, you could use smartsheets, whatever format that works for the team. Cool.

I like it. Pretty versatile. Depends on the company way of working. No tight definition there. And then the actual planning part, I'm curious because you mentioned the functional leads are there, you have a strategy. It sounds like the different functions start taking off and take their own accountability for what they need to do. How do you do that? How do you allow the team members some autonomy to Help build a plan versus get that cohesion so it all makes sense. Coming together.

When you ask your individual workstream leads or functional leads to start building their plans, one of the important functions of or responsibility of IMO is to make sure that you don't lose the overview. And so you have to bring in all the leads together in a regular manner to go over the plans to talk about the dependencies. Right. To talk about how this plan is going to change based on this specific requirement from the product work stream. That cross communication is extremely important. And again, the IMO lead is the best to bring all the work streams together and to make sure that the plan is built. And the other thing I would say from my past experience is you can actually use your integration plan as a use case for your company to launch a new capability. I'll give an example. This is a deal from few years back. We had acquired a company and the product was a subscription product. And at that time internally we didn't have capabilities to offer subscriptions. Our subscription billing platform was getting built, but it was not ready. And so what I did at that time was use this acquisition as a use case for that subscription billing platform. And the way we put together the integration plan was using some manual workarounds to make sure that the new product is integrated with the existing portfolio and we are able to offer that subscription. But at the same time, I used this use case to provide requirements for the subscription billing platform. Eventually, one of the deal drivers for that transaction was to get the combined product out within I think nine months to a year. And we did that. But that not only helped us to achieve that deal value driver, but it also helped us to build our subscription billing platform. It is really important to leverage your integration challenge or problem that you want to solve as a part of your overall company's development or targets for building new capabilities. It does become a very interesting scenario where you can use your integration as a use case. I definitely enjoyed that process quite a lot.

That's a great example. You got to have a holistic view of your overall company roadmap and what goes beyond just that specific deal you're working on. Yep, the iterative part. How do you sort of maintain that momentum because you're dealing with functional leads? They got a day job, a lot of things going on. Pretty traditional thing is find some template or something and just here's a plan and then you go through as an exercise, you just find a day one to go execute it. Now how do you actually get that momentum for it to be iterative process and collaborative.

Taking the example of Woven, we are a very small team. We don't have the luxury of having dedicated integration resources. And as you said, every functional lead they have their day jobs. I think one of the key part or key feature that IMO provides is that you simplify the overall integration process for all the workstream leads and try to minimize the overhead of integration as much as possible. When it comes to templates, I am a strong advocate of using the tools that the team is already familiar with. You don't want to introduce some new tool and then ask hey for this integration. Now let's all use this new tool and then you have to update it on a whatever daily weekly basis and then do it. You right away will hear that worksim leads raising their hands. It's like we don't have cycles to learn something new and do it. Going with the tools that the team is familiar with works the best. So my product and technology or IT works teams, they love Jira and so they build their integrations plans in jira. But if I ask my HR and finance team, we're not comfortable with jira, so we'll go with maybe Google Sheets or we'll go with smartsheet. Being flexible to whatever tool or whatever format works for the team, that's the key. So you minimize the overhead on all the functional leads and then maintaining a simple cadence for your IMO meetings where you can actually review these plans and do real time changes, that becomes key too because you don't want to wait for a month before realizing that oh, I have this huge dependency and now I have to change my plan. So making sure you have the right collaborative tools in place. We use Slack. So whatever tools again work best for your team, leverage them so that there is an open dialogue and people can continue to iterate their plans in real time and having that transparency. So having shared drives or shared folders where people can see other work streams their plans, that helps a lot too to maintain that iterative nature.

Yeah, I totally agree with you. These are some things you brought up. I learned the hard way. You can't just say hey, learn this new product this and that because I think that's where you end up with the friction and then it becomes more of the singular exercise as opposed to ongoing iterative collaboration. And so removing that by utilizing the tools, allowing those departments to use the tools they're already comfortable with allows them to be able to do that. Can you tell me how much you love managing cross functional dependencies for integration.

That is in nutshell, it's managing cross functional teams and cross functional dependencies. I especially love the challenge. There's hardly anything that you can say that oh, one work stream, go run with it. In integration, everything is cross dependent and everything will have at least two or more functions who need to work together for that. I don't think you can talk about integration without cross functional dependencies.

This is where I draw the line and exit out. This is for the engineering brains, the real type A people out there that can actually do this. Because I see it and I see the different approaches to map these cross functional dependencies and my head starts spinning and then I gotta go and I'm curious going back to here's. You got different functions or using the tools you're most comfortable with. And if you have this, I've seen this a lot in large companies where different functions are using different sets of tool. How do you map out those cross functional dependencies if they're using different tech stacks?

So if your functions are using different tools to map their plans from, IMO having a template where you can report or capture these cross functional dependencies work. So for example, as I said, my engineering or IT work streams use jira, some use Google Plans, Google Sheets for their plans, et cetera. But for my status reporting, I use simple Google Slides. And that is where for every status, cross functional dependency is one of the key sections on that slide where people call out. That way you can make sure it is visible to everyone. But you're right, you do have that additional responsibility to go back to your individual project plans and then add or find a way to track those dependencies and hold each other accountable. So it does become little additional work. But you can use one format to provide visibility to those cross functional dependencies. And then whatever tool you use, you have to make sure that you can track and monitor those dependencies in those specific plans or those specific tools.

I think that's a whole little seminar of its own that you could teach. So we get this plan, it's getting the right direction. People are pretty confident, are there little checkpoints with that plan to kind of know, almost like a validation that the plan is comprehensive enough that we have confidence we're on the right page to go execute it on day one.

Yes. And again, not just day one, but right. Depending on your deal strategy and your integration strategy, it could be day 90, day 100 or day 300, whatever is the timeline you're looking for. And so you build your individual milestones and Obviously you have some kind of cadence for your IMO meetings. Initially it could be weekly, biweekly, and then you can maybe change to monthly depending on where you are on the timeline. But having those checkpoints is really important to make sure if you are on track, if you need to do any adjustments, if you need to check, and a lot of times as you progress, certain work streams will drop off the integration process. They would complete their integration milestones and you could be limited only with the long poles. Typically would be your product and technology, your it, et cetera. Having those regular checkpoints becomes key to first of all, monitor where you are if you're on track, and secondly, what changes you need to do to the upcoming milestones and upcoming plan.

I was curious about your impediments around information gathering. You don't get everything you want for the integration. I'm curious to know what are examples of that. That hey, when you're planning for integration, you'll often run into this roadblock or limit of being able to get this information pre close and how do you manage that?

So in the pre close world you're right. Because of certain restrictions you will not have access to certain information. But then you definitely can set up areas where you can have specific audience with the right clearance, access to that information and setting up those rooms becomes really important. So that way you can manage sensitive information in the right way. Again, depending on the criticality, if that information can be accessed post close, then you can make sure to follow up and then do those double clicks after close as well. But maintaining clean rooms before close and making sure that right people have access to the right information can be definitely the way to approach.

That's a whole nother topic to get into around setting up and operating clean rooms. Otherwise it seems like you're mapping out your gaps, working around there, anticipating the information. I'll throw in Lisa's question here because I think it's pretty relevant. How do you handle managed vendor dependencies and transparency across teams and their work streams?

So vendor management again could be a work stream of its own. Depending on your deal, during your diligence you will come up. Or you can have the initial understanding of what is the scope, what are the vendors used on both the sites, where is the overlap? And you can again have your procurement work stream to take a lead on that initial plan, how you want to do the integration for all the vendors. Again, making sure the target is involved and figuring out what is the scope, where there are overlaps and then coming up with the plan. Which is not going to disrupt your existing contracts which are in place. And so making sure your contract limits and then working with both sides becomes the key to build that procurement plan or vendor management workstation plan.

Just to get clarity on the complexity of the planning part. You have the functions that have their own detailed plan. And then do you have a broader kind of a master high level integration plan that you're hosting to bring everybody in?

Yes, there will be some IMO level milestones that you want to track and there will be a plan around that. And it could be more around your, as you said right before, day one, day 90, day 100, day 300. And so you could have a plan which will cover the IMO specific areas and then you obviously have a separate functional plans for each. So a lot of times since we use Google sheets, typically it will be one sheet with different tabs and IMO would be one tab for the plan where you have high level plans. And so you do want to minimize any duplicate items, then that is again as part of the IMO governance, you want to make sure that you don't have duplicate items in multiple work streams plans. Even if there are cross dependencies, you have to find out one work stream which is going to be accountable for that specific item. Others will be responsible. But then accountability should be with one work stream. And so that is one of the key things that I focus on is to have that right raci identified. You can have multiple functions or work streams responsible, but end of the day it's only one work stream or one function which is accountable. That's the single throat to choke when things go wrong. Making sure that there is no duplication or redundancy across individual plans is definitely key.

You remember the race, the whole acronym was a responsibility.

Yes, responsibility, accountability, consulted and informed. So you'll have people responsible, accountable, consulted and informed.

You don't know Google it. It's a good tool to have in your pocket. From there we're going to socialize this with the key stakeholders to get buy in the fourth pillar that we talked about. You're basically going over this master IMO level plan with everyone. Or do you have people opening up their function executable detail plan.

If you have made sure that you have set up a central document repository which is accessible to everyone, everyone should be able to see every work stream plan, including the IMO plan. And during your IMO checkpoints you definitely go over individual plans. You do run your IMO plan with all the work streams and then focus on individual plans. As and when required, depending on what phase you are at and what are the upcoming milestones. For example, say you have a weekly cadence, you will look into things that are upcoming in next week or two and then you'll pull out respective areas from individual plans that you need to focus and discuss during that checkpoint.

Awesome. There it is. That Siemens framework for integration planning. Set up the early version of the imo. Define the integration strategy, define the integration roadmap plan iteratively and then socialize it with key stakeholders and get your buy in. I gotta ask, what are the potential pitfalls of leading integration as an afterthought?

So one of the things, as I said, your deal success really depends on that. And if you want to really make sure that you realize your deal value drivers, you meet your goals and objectives of the transaction, you definitely need to have the right integration strategy and plan in place. Without it, it's definitely going to be a failure. The other area is your teams are definitely going to burn out because you won't have the right resource planning in place. You will be overwhelmed by the upcoming milestones. And then you have to be answerable to your deal sponsor, to the board, to the steerco. And it is going to put you in a very tough situation if you don't have the right strategy and planning in place. So if you really want to hope for a smooth integration, then making sure you have the right strategy in place and the right plan based on the strategy in place, that's the key.

Can you talk about the relationship between the deal goals and the integration strategy?

So your integration strategy should be built around your deal goals. In order to meet your deal objectives and goals, you have to have your integration strategy which is tightly aligned to that. In nutshell, make sure that your integration strategy follows your deal strategy. Building through in silos definitely will not help.

Yeah, that is a really good point. But when you think about the integration and going through this, eventually it's got to finish. So how do you determine when integration is truly complete?

I have seen a lot of times integration just keep on going forever. People have backlogs years down the line after the acquisition's complete. It is very important to make sure that we identify the integration exit criteria up front. And so I encourage all my work streams right in the beginning when we kickoff integration and think about the charter for each function or work stream. I encourage the leads to think about what is exit criteria for their own function or their own work stream. And again, make sure that you socialize that exit criteria. Get the buy in and approval from the Steerco and from the leadership team. But what it helps is once you have that exit criteria in front for a specific function or work stream, when I can exit integration and transition to business as usual mode, there will be some long pole items that you do want to do it, but you can work on it or execute as part of business as usual, but you can come out of the integration mode and you're ready to continue running the business as usual. So identifying that exit criteria or exit strategy and it will be a different timeline for each work stream and for overall IMO it could be a different timeline as well. But identifying it afraid so that you can release the resources back to the functions or work streams in time becomes easy and it becomes easy to monitor and then track the progress very well as well.

So it's very milestone based. I'm used to private equity firms, it's always the 90 day plan and that's what I feel like. It's just a do whatever you can in 90 days and then it's onto the business. But your definition is very much. It sounds like it's around specific milestones.

Exactly.

All right, let's summarize this. So what are the best practices for businesses to ensure smooth integrations after close?

Just going back to where we started. Bringing integration as early as possible in the mix right from your deal strategy or deal structuring phase. Involve integration in the diligence process after your LOI signed. Start your integration planning in that pre close phase itself. Make it a repetitive process. Make sure you involve the right functional leads or work stream leads to build your integration plan and then continue to refine and execute on that plan post close.

Get an early start. Seema, what's the craziest thing you've seen in M and A?

So we all say that when we are doing integrations we are building the plane as we fly. And for us at Woven that was literally true. As I said, we had absolutely no presence in North America when we did our first acquisitions. So it was really crazy. We had to rely on advisors completely. But not having that maturity for M and A at all, not having any capabilities for M and A at all to building those through the initial deals. I think that was the craziest thing that I've ever seen so far.

What was like the craziest part of that? You got to start somewhere. Sounds like you had a pretty crazy start from that start.

I think the craziest part for that process is to demonstrate the value of integration to our stakeholder in our case, it's Toyota. And to demonstrate the true value of the integration was the craziest part. And especially on the other side. Obviously Toyota does acquisitions, but in the software world, which is a new world for that. So that was one of the craziest part. Very rewarding as well at the end of it. Extremely painful and challenging, but at the same time very rewarding too.

That's awesome. That's a great story. I really appreciate you taking the time. Seema. I learned a lot through this conversation. You've helped me become a better M and A scientist today.

Thank you so much. Thank you for the opportunity to be part of this and really enjoyed this discussion.

Those of you that stuck through, you're the best. Thank you. Until next time, here's to the deal. Thank you for taking the time to explore the world of M and A with our podcast. We love hearing feedback. Tag us on a LinkedIn post, add a review on Apple Podcasts. We'd love to hear from you. If you if you need help standing up an M and A function or optimizing one that you already have, we're here to help. And if we can't help you, we probably know someone that can. You can reach out to me by email Kisan K I S o n a science.com or you can text me directly at 312-857-3711. If you just want to keep learning at your own pace, visit mascience.com for a lot more content and resources. That's where you can also subscribe to our newsletter. Again, that's mascience.com here's to the deal. Views and opinions expressed on M and A Science reflect only those individuals and do not reflect the views of any company or entity mentioned or affiliated with any individual. This podcast is purely educational and is not intended to serve as a basis for any investment or financial decisions.