What do you define as your integration end
- This topic has 14 replies, 15 voices, and was last updated 8 months, 2 weeks ago by
.
-
Posts
-
All successful projects have a defined end. I am having trouble defining what that is for me. What do you define as your “end” to the integration
For the most part, we define the end of the project to be: completion of a successful integration, resolution of cutover issues (if any), signoff obtained from the business, outstanding items between the Buyer and the Seller wrapped up and our project celebration/appreciation has occurred. However, to your point, it is a moving target and can be different with each acquisition/integration depending on deal type and complexity of the business.
It is important to determine in the beginning what is going to be a project and what is a program that we know will continue on. Integration for us is loosely defined as the projects need to transact business as usual and anything else is outside of the integration and becomes daily work, projects, and programs.
The end of the project should be defined in the project plan, i.e., when all project deliverables are completed, the project is completed. In reality, the end of the PMI and the start of continuous improvement are probably not clear cut. A good way to end the project is to conduct an “after action review” to refine the PMI approach that was applied. The end of the project should be properly announced, also to release the project staff from its project duties.
it is important to understand the requirements of each agreement (TSA, ASA, MSA, etc.) and establish a defined transition process to the business-as-usual model. These item should be transparent and clearly communicated.
We define end of integration as the point we operate as “Business as usual” with regard to that particular acquisition/integration and where the business is set on the right path to deliver the long term acquisition goals and synergies. This can be a bit challenging but found that breaking it down into specific integration workstreams and having each workstream define their BAU requirements and then later sign off that they were delivered or reached appears to be a good approach.
Like many of the other comments here, I would see an integration project as a defined group of steps which are determined before the Acquisition happens. once the different workstreams are completed, the process should be officially done. however, there could be a final workstream to make sure nothing was lost in integration and leaves room for further workstreams
I would say that the three key elements of post-sale plan are (a) commercial, (b) product/services, and (c) people.
Once an organisation has integrated these three, then I think we can say that this integration is ‘complete’, albeit mostly so.
e.g. If an acquired company has completely integrated its Go To Market strategy, sales, customer service, account management and marketing functions, then commercially it is integrated.
If a company no longer has its on product functions or independently operating services / product teams, then we can say that it is integrated.
And if an integrated company has completed the sometimes difficult process to move all of its staff onto the parent company’s contracts, and no longer employed anyone on the former entity, then we can say that the integration is complete.
Outside of these areas, obviously there may still be suppliers, branding, partners or legal issues, that are not yet fully integrated. But this seems to be a good starting point for most mergers to think about an ‘end point’ to the integration process.
As an M&A manager I define the successful end of my participation in integration when our management is put in place at the target and fromally takes responsibility for all further steps for the integration of the acquired asset into our group. This in not the end of the whole integration process, it is just the step where I give this work to the next participant (who is more professional in terms of operations of the target, etc. and will be better informed on what’s going on due to his/her position).
While in absolute term Integration completion will be defined as successful integration of both entities after cutover and make sure that the entities are able to perform seamlessly in performing their day to day function. However effective completion of integration is when you are able to achieve the target synergies and optimize the Capex and Opex cost structures during and post transaction.
I think that the end of the integration can be defined in different ways, so it is normal that you struggle with this. Every project starts with defining goals, timing & responsibles, so I would suggest that the project end is defined at that moment in time as well: WHAT do we need to achieve? WHEN does the roadmap stop? Etc.
This will vary based on the deal, as well as differing integration plans. However, base line “end” should be baked into the initial plan with the understanding that it is an iterative process and may shift and change.
I am in procurement and as such I consider the end of the acquisition to be when all of the liability is off the previous company and fully under the purchasing entity. This usually happens a year or more post legal close.
In my experience, the “end” of an integration isn’t just a date or the completion of a checklist—it’s the point at which the combined business operates as one aligned, value-generating entity, and no longer requires dedicated PMI oversight to function effectively.
Great point! Defining an integration’s ” end ” can be tricky, especially since the lines between ongoing support and project completion can sometimes blur.
For me, the integration “ends” when all the primary objectives outlined in the initial scope have been met, the system is stable and functioning as intended, and the project stakeholders have officially signed off. Sometimes, especially with integrations, there’s a period of monitoring or support after go-live. However, I still mark the official end as the point where the team transitions from active implementation to maintenance or business-as-usual.
- You must be logged in to reply to this topic.