Increasing the Speed of M&A Integration

In over a decade of delivering successful M&A Integration services, we’ve worked aggressively to speed up the integration or transition process after a deal closes. Often, this involves taking appropriate shortcuts with traditional project management, requirements gathering and implementation methodologies.

What shortcuts from your personal M&A history have been most helpful?

A few, off the top of my head, for starters:

  • Limiting the requirements gathering scope to high risk processes
  • Flattening the project team structure to smaller, more highly and broadly skilled teams
  • Making the project plan the driving tool for regular status meetings, without supporting word meeting notes

4 thoughts on “Increasing the Speed of M&A Integration

  1. I’d go a different route – I think that once an integration is underway, the suggestions provided make sense, but may not make a substantive difference in overall timeline.

    In working with several M&A integrations in the past years, I am not aware of any of our M&A clients who did only one acquisition – they tend to be on an acquistion path and perform at least several of them. At the extreme, a company decides strategically to become “acquisition ready.” What about helping such a “serial acquirer” really getting ready for the next one in advance.

    I believe that the greatest inefficiencies are usually in two areas:
    * Clearly understanding and resolving data requirements/impacts
    * Identifying and then categorizing gaps between business processes (such as they are supported by technology, anyway) – this is, after all, the entry point to system mods, new reports, and other artifacts that can rise up and bite an implementation team, as well as drive the overall timeline and cost up

    The first one is tricky and I don’t really have a good suggestion for improving speed there (other than going into it with your eyes open, with experienced resources immediately available, and with clear business ownership of the master and transactional data).

    However, in the second case, I think that you could conceivably reduce the overall implementation timeline (if not effort) by 20-40% (depending upon size and complexity) if you build an appropriate acquisition toolkit before the next acquisition.

    * Every key business process has supporting (and current) BPDs and workflow diagrams (both process deployment and technology deployment diagrams).

    * A framework – supported by tools and experienced resources – exists for rapidly drilling into the details in understanding differences between the two companies

    * There are current org charts and job descriptions for every key role; furthermore, default change management methods, tools, and messages are archived and ready for re-use

    * The technology environment is accurately reflected in up-to-date system integration and data flow diagrams
    * Key performance measures have been generalized from previous acquisitions and are ready for the next one

    * An inventory of key differentiators (as in marketing differentiators), cross referenced to the business processes, exists and accurately reflects executive-level vision for the company

    * Key project management deliverables (default team plans, status meeting templates, status report templates, default team structures (by role), etc.) have been generalized and reflect lessons learned

    * Other deliverables (e.g., training materials) are current and accurately reflect the current baseline processes – as well as many other deliverables that involve business processes or technology

    * Lessons learned are actively and non-judgementally collected and incorporated back into the toolkit – a great way to get faster is to get better

    The goal is not just to support more rapid decision making, but to speed up determining where key decisions must be made (e.g., gaps between the acquired company’s processes and the master processes at the acquirer).

    Basically, the better the baseline data, the more valuable and rapid any comparison between competing business models becomes.

  2. I would amplify one of your points as well as add some of my own.
    * Use a milestone or summary plan to drive the meetings. The detailed plan allows too many tangential trips down minutae lane.
    * Investigate legacy documentation artifacts. These may provide enough baseline material to streamline the requirements gathering process.
    * Leverage the processes of your vendors (and vice versa). If they require detailed process flows, either use theirs or sell them on using yours. Try to avoid duplicating efforts.
    * Understand who will be making the decisions for the to-be organization. The person that owns a given process may not own it in the new world. If that is the case, there is a good chance that the new process will look different, if only to allow the new owner to place a stamp on it.

  3. I think we need to focus separate the speed up activities between the infrequent activities that have a large impact on the schedule – typically by eliminating rework or decision delays – and the frequent ones that have a small impacts that add up to a large effect.

    The first two bullets fall into the first category. A broader version of the third bullet which I will call “Effective use of project management tools” falls into the second category.

    In the first category, I would add:

    * Divide the integration effort into repeatable pieces to mitigate the risk and to provide learning opportunities in the early stages that can be leveraged in the later stages.
    * Spend the time to design integration procedures for which many (ideally, all) steps can be executed by people who do not have intimate knowledge of the business at hand. (All my integration “war rooms” have been staffed by temporary staff to a large degree)
    * Take time to understand the “points of no return” on projects and make sure no one walks off the cliff unnecessarily in their eagerness to make progress.
    * Understand any strategic constraints and desires the new owners may have. For example, do they want a speedy “pick one platform as the standard and push every unit onto it” approach or a slower but potentially more profitable “select the best practice as the platform whether or not we are using it now”.

    In the second category (frequent small gains):

    * Set up an environment to foster rapid decision making. This includes having a business case and strategic priorities identified before the merger close that can be used by the project team. Don’t beat people up over one bad decision – (a “one strike and you are out” culture slows down all decisions because the cost of not making a decision is less than the cost of making a bad one.)
    * Use a limited standard set of simple, easy-to-use collaboration tools (such as phone and Web conferencing) give numerous small efficiency gains that add up over the length of the project.

  4. Pingback: M&A Data Integration Readiness « Edgewater Technology Weblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s