Integration Management Framework
Success of a merger largely depends on how well the two entities are integrated together. This post will show you how we have approached integrations in the past and what tools and processes we had implemented to ensure desired results.
Just like with any other project, the first question to answer is – why are we merging? Is the goal to achieve efficiencies of scale? Is it to gain access to a new market? Are we looking to embark upon rapid growth right after the merger or do we want to focus on optimizing our costs and processes? This is a strategic decision made by senior management and it needs to be clear to the organization. It also needs to be remembered after the integration is complete! I have seen where companies merged to cut costs, but immediately after the merger wanted to grow only to find that they had no capacity for that. I have also seen companies acquiring assets for growth, but had too heavy of a cost burden, limiting any meaningful growth investments post-acquisition. So, a decision around “why merge” is critical and has long lasting impact.
The next big question is – how will the NewCo look? What will be the new organizational structure, what tools will we use and what processes are we going to follow? Again, this question can only be answered when we understand the long-term purpose of the merger. If we are trying to cut costs, we will likely try to leave just enough people to run operations in the new organization. Our tool selection will be impacted by contract negotiations and where we can get most favorable usage rates. On the other hand, if we are trying to grow, we may intentionally retain extra capacity where some people from the two entities focus on operations, while others focus on projects that get us the desired growth. This means a completely different approach to selecting and retaining employees and contractors during the merger. The systems that we choose to keep may be very different as well. When the goal is to grow, it will most likely have implications on our Customer Experience, which in turn, leads us to those tools that best support it. Consider this example – one company has an old ERP system that people wanted to replace for a long time and the second company has a newer one that would address most of the known shortcomings. A logical first thought is to go with a newer system as it appears to address current needs. However, if the goal is to rapidly grow post-merger, then most likely the business will have to truly transform client experience. Why? Because most often a greater than normal growth either requires changing major components of the client experience or it will cause it – simply because the size of the organization increases, which inevitably impacts quality of products and services. Any time a company wants to grow faster than usual – I ask “what are you doing that you have not done before”? So, if the goal is to rapidly grow post-merger, the newer ERP system may not necessarily be the best choice. First, we need to design the new experience and work backwards to determine what back-end system is best suited for that purpose. It very well could be that a completely different tool will be required, in which case it may make sense to stay on the older system or even on two systems temporarily through the merger and then immediately work to bring in the new ERP. Mergers must be planned with post-integration projects in mind! This will help you plan your resources much more effectively.
Once these fundamental questions are answered and key decisions are made, the rest of the integration can be planned. We are now able to define scope and “definitions of done” at a more detailed level. The first building block of the Integration Management Framework is the Work Breakdown Structure (WBS) which helps answer – what are we merging? The standard top-level of the WBS has seven categories:
- People
- Processes
- Tools
- Products*
- Facilities
- Customers
- Suppliers
It is important to note that Products don’t just include those items that our clients buy – they also include internal team outputs. For example, one of the products of the Accounting team is a General Ledger.
When we merge, we need to build a plan for each team that answers how we integrate each one of these seven categories. A team should start with a goal – what do they want to achieve as part of the merger for themselves? This goal needs to connect to the overall enterprise goal discussed earlier. Once the team aligns on the goal, it can plan work within each of the seven categories. The activities within each category can be listed as “work buckets” which later on will be connected and prioritized across the entire integration. One important note to make – work buckets must have verbs. Verbs mean actions and actions mean ownership, duration, etc. For example, if a work bucket under the People category says “training” we don’t know if training needs to be designed, developed, executed, or all of the above. Actions eliminate confusion and help identify any gaps in the plan. Another important consideration when determining work buckets is their size. My standard rule is that a work bucket does not exceed one sprint. While exceptions are possible, generally we want to break our work down into activities that are no more than about two weeks long. On the other hand, another rule for a work bucket is that it has at least two tasks. This WBS is similar to an Agile structure with Epics, Features and Stories. Those are fine to use as long as the recommendations above are followed, otherwise the team may experience various challenges, including confusion, delivery delays, lack of prioritization clarity, etc.
Once the work buckets are defined, we can build a Roadmap that connects all of these buckets together. A Roadmap is a visual representation of the sequence of work. It also identifies relative work sizing, ownership and helps determine the Critical Chain. The Work Bucket Roadmap provides an optimal level of detail – it allows us to see what is happening in each sprint, how it impacts other teams and work buckets, how a delay in a work bucket completion impacts the overall schedule and, lastly, it does not require us to get to the task level, avoiding micromanagement and giving teams necessary level of autonomy to do that work, which is required to achieve a particular objective.
Since merger integrations involve a very large number of people across at least two enterprises, the Integration Roadmap creates a single view of the project. This allows each team to manage their tasks in a way that is more convenient for them. Some may have task management tools available, others may rely on Excel. In the end, it is not critical to have everyone manage tasks in the same system as long as it all rolls up to a single Roadmap that connects all work at the bucket level. This is usually a welcome news by the teams as the requirement to have a single task-level management system adds cost and creates various pain points across teams. With that said, there are online tools that are lightweight and convenient for task management, if teams want to use a single platform. I have effectively used MS Planner and MS Teams for tasks and collaboration. These tools allowed us to have an ‘independent’ integration system and, when connected with the Roadmap, gave teams and executive management all the visibility and control needed to manage the merger.
Once you have the goals, the work buckets, the Roadmap, the task management and collaboration tools in place, the last piece is Execution Rhythm. This is where Agile framework comes in best. It’s simple, light weight and creates a routine that people either already know or can quickly adapt to. Sprint Planning and Sprint Review meetings where you can review the Roadmap, combined with Daily Standups, where teams discuss tasks, provide a great framework for regular team collaboration and communication.
At the end I will just add that if you put such a management framework in place, you will save a lot of time and money during the execution and reduce risk significantly as well. This framework has been proven in the most complex mergers where success was the only option.