Mergers & Acquisitions

My organization is currently going through a merger, and I've been tasked with building a combined change management process to scope, track, and monitor organizational changes (technology, process, structural...etc) as they move through implementation.

In this role, I'm acting as both Project Manager and the sole Change Manager, and leadership has asked for a practical change intake and tracking system that aligns with change management principles but remains relatively straightforward to implement.

Most merger-related change management resources I've found focus heavily on culture and adoption, which will be addressed separately later in our integration process. My immediate focus is on structuring how changes are identified, scoped, and governed across the organization during implementation.

I'm currently struggling with where to start in designing a clean, structured process that blends project management discipline with change management principles.

For those who have built something similar:

• What intake or change scoping frameworks have worked well for you?

• Are there templates, tools, or governance models you've used to track organizational change during large transitions like mergers?

• How do you keep the process simple enough to be adopted, but structured enough to provide visibility and control?

Any examples, templates, or resources would be greatly appreciated.

Hi Sneha - my suggestion:

1.Define the future integrated operating model (at a high level):Before capturing individual change requests, it helps to define what the combined organisation is aiming to look like. This usually covers areas such as:

• Organisation structure and roles
• Core business processes
• Technology platforms
• Governance and decision rights
• Customer journeys / service model

2.Conduct a current vs future gap assessment
Each business area then performs a light gap analysis comparing the current state of both organisations against the intended future operating model.

Typical questions include:

. Which processes need to be harmonised?
• Which systems will be consolidated or retired?
• Where will roles or structures change?
• What policies or governance models need alignment?

Each gap essentially becomes a candidate change initiative.  

3.Convert gaps into a structured change intake pipeline
Once the gaps are identified, they can be logged into a change register or intake pipeline with basic scoping information:

• Change description
• Business capability / function impacted
• Type of change (process, technology, structural, policy)
• Impact level (low/medium/high)
• Dependency on other initiatives
• Proposed owner

From there you can triage and track them through implementation. Your delivery approach ie traditional/agile/hybrid will determine your project tracking system which will again determine the artefacts for this....Above activities mainly sits with business analysis discipline but if you are doing everything you will need to wear different hats to cover the end-to-end lifecycle of the post acquisition integration effort..

This sounds like a really interesting role to be in, and one advantage is that you have visibility of both delivery and change conversations in one place. In a few merger and integration assignments I've worked on, I've usually adapted and layered change management tools and templates onto the existing PMO framework of the acquiring organization. When one person is covering both project and change responsibilities, getting early agreement on scope, roles and responsibilities, and governance makes a big difference in keeping things organized as the integration progresses.

I agree with Ama's suggestion about starting with a high level view of the future operating model. It does not need to be overly detailed at the beginning, but having clarity around the intended structure, core processes and key technology platforms helps anchor the work. From there, a light current versus future gap assessment with each business area can help surface the main changes that need to happen across process, systems, structure or policy.

Those gaps can then feed into a simple change intake pipeline or register. What has worked well for me is keeping the intake information straightforward so it is easy for business stakeholders to engage with. Typically this includes a short description of the change, the business function or capability impacted, the type of change, the level of impact, any known dependencies and a proposed owner. That register then becomes the central place to scope, prioritize and track changes as they move through implementation.

In practice, the templates that work best tend to be the ones stakeholders already recognize. Reusing existing organizational artefacts, templates and language where possible usually helps adoption and avoids introducing something that feels too new or complex. The approach can also vary depending on the type of merger, particularly whether systems and processes will be fully integrated or whether parts of the organization will continue operating more independently.

One practical approach is to use existing current state processes and workflows and map them to the proposed future state. From there, you can capture people, process and technology impacts across business units or departments. Frameworks such as the APQC Process Classification Framework ( https://www.apqc.org/process-frameworks ) can also be useful as a reference point when structuring process related change artefacts.

I am fairly new to this community myself, so I am not sure if there are shared templates within the forum. There are a number of publicly available examples that can be a good starting point though.  Hope this helps.