A successful PMI project will unlock the benefits of an acquisition

April 27 2021

So running a post-merger integration (PMI) project is the same as any other type of project, yes? Err, no.

Of course, there are similarities at the broadest level, and with the project management tools such as governance, plans, RAID logs and more, but the nature of what needs to be achieved is very different – and can even vary widely for different types of acquisition.

The PMI activity is of course only a subset of the whole Mergers & Acquisitions process, and – as is ever the case – the successful execution of a PMI project is fundamentally based on the quality of the work that has gone before. There are a number of well-defined stages in M&A, and if the early (pre-deal) activity is not effectively completed, the PMI aspect of the acquisition is likely to fail.

This could be for many reasons, including :

  • The rationale for the acquisition is not clearly articulated and understood, which results in no clear vision that all stakeholders can work towards
  • The due diligence was ineffective and crucial information was missed, which could result in additional costs being discovered, undermining the entire purpose of the acquisition
  • There was inadequate thought given to the post-merger operating model – for the combined businesses and the supporting IT landscape

If all the above traps (and others) are avoided, it should be possible to plan and execute a PMI project that will secure the benefits that were originally identified; and the trick is to secure them as quickly and efficiently as possible.

The primary goals of the PMI project must be to realise the benefits that were called out in the business case for the acquisition, and to enable ‘business as usual’ to be resumed quickly. The benefits will often be related to economies of scale – where the cost of operating a single larger organisation is less than operating two separate ones – or from leveraging the assets and capability of the acquired organisation within the core (acquiring) business.

In both cases, with two previously independent organisations, there will have been some sort of operating model in place in each organisation – however richly defined or otherwise, and however well or efficiently it will have been operating.

Ideally, the Target (i.e. combined) Operating Model will have been determined, at least in principle, prior to signature since it is too late to start protracted discussions on this topic only after the deal is done. It is therefore essential that the (pre-deal) due diligence activity uncovers as much information as possible concerning the technology landscape of the target in order that any issues that this intelligence brings forward can be factored into the integration plans and business case. Few people would purchase a house before getting a full survey done, and the same applies here.

Deploying the Target Operating Model may not (in fact likely will not) be a trivial exercise, but if the target is clearly defined and accepted, then through a carefully planned and executed programme of change, it should be achievable.

The diagram on the right illustrates the process by which the technology and IT landscape of the acquired organisation (on the left) is either replaced by, or is absorbed into, that of the acquiring organisation (on the right). At a very generalised level, the landscape is likely to consist of broadly similar components: networks / telephony, core infrastructure, applications and ‘service management’ activities.  For each of those elements, there are essentially two options:

  1. The element of the acquired organisation will either be replaced by the corresponding element of the acquiring (keeping the landscape as simple as possible)
  2. The ownership and responsibility of the particular component from the acquired organisation is absorbed into the general responsibility of the acquiring organisation.

This latter approach will extend and complicate the overall landscape, and indeed increase the workload of the IT teams, but there may be reasons why this is the right choice. It does, however, mean that any compliance issues related to the retained elements of the acquired organisations IT landscape must be promptly addressed.

Despite the new TOM being an achievable target, it will almost certainly be necessary to put in place some interim arrangements whilst the new TOM is introduced. Ultimately, the acquiring organisation has become responsible for the acquired, so at the very least effective oversight needs to be put in place from day 1. This starts from the top, where the IT leadership of the acquiring organisation must take ownership and control of the IT landscape of the acquisition. This may be as simple as a change to the reporting line of the IT Director / Manager of the acquired organisation, but steps should be taken quickly to ensure the required controls are put in place.

The new owner will be held responsible for any compliance breaches (GDPR etc.), and whilst allowance would be made for inherited systemic weaknesses, that ‘excuse’ would diminish over time, and indeed would only apply at all if it could be demonstrated that active steps were being taken to identify and address any issues that may have existed pre-acquisition.

As such, the high-level delivery plan for the IT function will likely follow the broad outline indicated below, with line 1 representing the rapid development and implementation of the Interim IT operating model, which will secure and control the landscape whilst the main full integration (represented by line 2) is planned and undertaken. Of course, the (IT related) benefits of the acquisition can only be fully achieved when the integration project is complete, and ‘business as usual’ has resumed, so the sooner point 3 is reached, the better.

Finally, it is worth noting that change is inevitable, and the end of the integration project is not the end of the road. The business will always evolve, and new requirements will emerge. New requirements will, however, be much easier to deal with after an integration project is complete, and the full landscape is under control. As such, time is of the essence, and integration must be completed as quickly as practically possible.  Knowing that it is not the end state, merely a step towards simplification, it is reasonable to expect that compromises will have to be made. The prize and the benefits of quick completion of integration projects are such that this compromise is worthwhile, and those involved in planning and executing PMI projects must never let the perfect get in the way of the good enough.

The Author

Andy Hill