.jpg)
"The IMO is a shepherd of the process to ensure an intersection between the strategy, project management, and the people in it." - Ian Burk
In this episode, Ian Burk, EVP of integration at Upland Software, talks about how to stand up an IMO. Ian discusses the importance of an IMO, when a company should consider standing up one, and the actual steps to building an IMO.
The boring answer is governance, but day-to-day management of really important topics. The IMO is a shepherd of your process and ensures an intersection between the strategy, project management, and the people in it.
The best IMO practitioners can hover up and down and tie everything they're doing to the strategy, even if it seems really granular.
The idea is a program office that's nimble enough and connected enough to the firm's strategy, understands exactly what you're trying to accomplish, and keeps you on track.
It's exception management. They will handle small decisions that can impact value drivers. Integration management is about collectively staring at your problems and figuring out a path forward. If you got a nice central group that can do that and create trust, that would be your secret sauce
There are probably a hundred opinions on this. Upland had done several deals before I even showed up. So they were pretty good at it before me. There was no IMO before, but there was an integration function, and it just happened to be scattered and maybe not so well thought out.
There was not an IMO in the early days of Dell, and we were a huge company. But I think it depends on the sort of deals you're going to do and how often you will do them.
It's a lot of work to stand up an IMO, and it's even more work to stand one up and then when it down and then stand back up and keep repeating that. So I think if M&A is a core part of the strategy, you should have at least a small core team that's evergreen.
And then you should be thinking about how you can flex up as the deal activity picks up, and one way or another, you want to lean on that next level of folks that are distributed through the company.
And then, who are the third-party partners you can lean on to bring more expertise. I've just worked with so many great consultants and advisors, and having a deep bench of those partners also helps you not have to have a sort of IMO on the shelf all the time because that's much overhead if you're not active.
They can be as long as you're disciplined about going after the best practices. The differentiator is the experience and pattern recognition in doing M&A deals to see the gotchas before they come.
If you're going to be active enough, it doesn't even have to be large. Maybe you can dedicate one small part of the PMO to integration, and that could create a lot of value. Then you can borrow the overall structure.
I've seen several people coming from traditional PMO backgrounds, and they are so interested in driving processes that they become very disciplined IMO person. So I think it could be an evolution there.
It all just depends on how active you're going to be. And the more parallel processes you have, the more that's at stake, and I think that dedicated function is really helpful.
The first is to listen. Don't ask, "how do you all think we should do integrations?" Nobody has an answer for that. Talk about some of the deals that happened and what the results were.
You essentially want to encapsulate lessons learned and outcomes and then try to reverse engineer why that outcome happened.
Just do a little survey and act as a consultant the best you can because templates won't work. The key to finding what works in your firm comes from many conversations.
The second thing is to think about who the core team is. And so my preference is to have a very small sort of core IMO team and then think about the project office itself as a pretty distributed function.
Find people who have a project management bent and are excited about the details and extremely tenacious, and want to be part of something truly transformative. Make sure they also have the right sponsorship at the senior level to establish a certain level of trust.
So you want a mix of new talent and people with institutional knowledge and form a core team that will drive the IMO.
Once I have my core team, how do they interface with the deal sponsor, and how do you make sure that relationship is really interesting.
The third thing is to start thinking about that extended team. Align people by department:
And what I often find is the lead for each one of those departments has a day job, but they understand what it's like to drive an outcome. They're going to co-drive the IMO with you.
So with their help, you start building out a candidate list and you draft them in depending on the deal and where it sits in geography and timing.
From there, you have to start thinking about your operating model:
So I'm talking about the IMO standing up a large meeting with all the stakeholders. You're not going to do that every week with the senior leadership team. So often, that's a monthly review exception management.
After you've gone through a few of these deals and you've got an outline, you've got the structure of the IMO, and you've got the cadence and the meeting rhythm, you're going to be driving through your project plan.
And so project plan starts out as an outline, but you're going to be constantly feeding back into it. So we're version four of our playbook. And the project plan is a thousand items deep. And that just comes through time.
So after a while, you can onboard new team members a lot more easily. So you're thinking about this as a development opportunity for people.
The playbook process will drive a little more discipline in the exception management, and the tool starts to drive some of that for you.
And you've got to make sure that you've got the right sponsorship, not just at the most senior level of the firm, but also the subject matter experts that are in the business unit that you're working with.
You don't want integration happening to someone; you want integration happening with someone. So I've always found it really important to pair up the acquired team and lead an expert with their new sponsor, but sometimes that's their manager, sometimes a coach, and sometimes a partner.
It's like a buddy system that gives the acquired employee the person to call anytime he has a problem or a question on how to navigate things in his new environment.
And then, you could also set up an informal listening post, where folks can get lessons learned. I could also do newsletters. If M&A is a core part of your strategy, then communication is important. You can also push out integration digest or blogpost on an intranet.
It's almost like good news is fine and bad news is fine, but not being sure if something is like a killer. And people don't like the silence.
Another thing to be thought about is the overlap in your deals. You have to learn how to manage multiple parallel deals happening at the same time. Deal cycles are so unpredictable, and sometimes you'll end up with two deals on top of each other or a wide gap in between.
One thing we've arrived at is called the integration commandments. These are the things that you always do and that we never do. They tend to be pretty firm-specific, but they're the things that matter most. So we asked each of the chapter owners and each of the department leads to author their own commandments. Think of them as guardrails to your deals.
Often they're our connection to the financial outcome or their connection to key talent. So you think about:
The IMO is just a giant alignment machine. And so to the extent, you can get everyone in the company to write down exactly what good looks like in your department. You don't need one, but extracting that and pulling it out is tough. And we have a few departments talking about answering the bell; they did an outstanding job.
We said let's line out the do's and don'ts and things that matter to you most. And they went all the way down to what's called desk procedures. If you're brand new, you just started, and these are all the things that you do in your job. It's incredible. Those ended up being amendments to the playbook chapter, but that's really extra credit. That's not for everybody.
It does; it's been helpful for us. A very common track here is that you'll be acquired, and then you'll be the acquirer later. And so, if your experience was only what happened when you came on and who knows when that happened, the task list is really helpful.
That's a really exciting thing and a cool evolution for people. We just hired new team members in communications, and they immediately got to look through the comms playbook. And right off the bat, like a couple of weeks later, she was on a deal and she did a great job.
The nitty-gritty is just honed over time. And the thousand things that I mention will be handled by a great project manager. If your playbook is just a task list, you're doing it wrong. But you have to have a task list to support the things that create a lot of value.
The workstreams and the departments with the most success put somebody on that as a day job, and their entire job is just to think about that to-do list.
A few months. It doesn't need to be a super protracted amount, and if you wait for it to be perfection, you'll never quite get it. So you just need the outline, and you have to get it running.
But I think a few months, if you've got somebody that's done it before, if you're dealing with a project management office, maybe a little bit longer.
It's real pressure. As we think about some deals, they drag on a little bit, so we're constantly trying to orchestrate. But oftentimes, we'll think about one of our large milestones is when key systems cut-over. So good examples. We run one instance of Salesforce for the entire company. It's an important way to ensure that all of our client accounts are aligned. And also every sales team can see all the history, all the notes and whatever.
So the customer has already tried at least one of our products, and they're familiar; it's happy hunting. So there's a single instance, but that's a big deal to move the CRM instance into our, so we rally a bunch of activities right around that particular milestone. And we did the same thing for NetSuite and the same thing for our JIRA stack. And there are a lot of key tools.
And so the question, would it be okay if we had to do them at roughly the same time or within a month of each other, would you change it? Would you do anything differently?
And oftentimes, we'll pull one milestone up and push another back because it's the same core team executing that. But you have to have the playbook, and you have to have the calendar thinking about those dates.
And so, for us, I know that Salesforce is typically cut over in month four. And then, I think about my deal cycle and try to get 80 to 90% of the work done in the first 90 days. I know when that cut-over is going to happen, you can lay those calendars on top of each other and start looking for the problem spots.
It's an executive leadership team. So it's making sure that the top management team, not just as behind the investment that you're going to make in the time you're going to take, but they're going to put all of their support behind making sure that team is successful.
When M&A becomes a cornerstone strategy, they start thinking about the appropriate investment to make.
The art of that for us is making sure that there's a cycle. And so there are a few different informal processes like listening posts, but in each department, we do a sort of end of integration review. We'd go back to that same team, ask what went best, what didn't go well, and ask the acquired leader in that particular department.
So a giant source for us of lessons learned, which all get folded back into the playbook, is these debriefs. And they're done in various small forums. A great example would be the integration lead for product management and the product management director or VP at the acquired company, plus the IMO listening.
What went well, what didn't, what would you do differently? We do that across all of the workstreams. That's often we find where there's gold that we missed. So that closed loop is one of the reasons why the task list has gotten so long because there are a ton of those lessons learned. We take those that are really meaningful or impactful. And we also explain the playbook. I think a big part of continuous improvement is signaling really strongly that you want to learn, and then you're open to it, so we describe it. Typically on the second day, sometimes the fourth day after our company is acquired, we hold a session with them, and we say, what do we mean by integration?And we actually describe some of what we've just done.
The macro lessons learned - there's much value in telling people what you're going to do. Describe your process so that there's something to fill the void.
And I just encourage everybody to put themselves in the shoes of an acquired company employee. Their whole perspective just changed, and maybe they just found out about it that morning.
So assume that you're going to get it wrong and over-communicate. Tell people what to expect and make sure you follow through, which feels not like integration best practices, but more just some good advice, but many lessons learned come out of not doing that.
