M&A integration discipline is an operating system

Integration programs stall, and essentially fail, not due to a lack of change or transformation capability. They fail because of a poorly built transformation operating system. For example, consider a recent instance of a bolt-on acquisition in which the acquirer appointed a single business owner of an integration and gave that owner full control over integration decisions. There was no steering committee with only a status report delivered at senior leadership meetings. Given the owner already led the division the acquired business would sit within, the company took the view that ownership was enough governance structure. There were no established cross-functional decision forums, and no agreed authority levels.

The decision that exposed the problem was centred on technology. The decision required was which of the acquired systems were to be retained, and how would they be integrated into the group platform. This decision touched numerous business units, including group technology and data, HR and finance. Given there was no clarity as to how complex decisions would be made, it moved sideways for months and delayed the integration. Nearly everyone involved described the problem as cultural, or as a shortfall in capability.

I believe the root cause was a lack of a well-defined integration operating system.

Organisations that consistently create value from an M&A strategy have not hired more disciplined people, and they have not run better discovery workshops. In my experience, they have installed an operating system that makes discipline the default behaviour. Culture and capability follow the system and are enablers of forward momentum.

That system rests on three connected pillars:

• tracing value from critical path milestones back to the deal thesis;
• monitoring risk through the assumption register and the risk register it feeds (subjects of my previous articles); and
• defining decision rights by level, the triggers that escalate a decision, and a decision log.

“Muddling through” an integration shows a lack of a clearly defined operating system.

The MVP operating system

Many factors drive the complexity of an integration system, such as I’ndustry, regulation, size, geographic footprint, and the state of the target’s technology and data (among others). The core pillars, however, remain smaller than most integration playbooks suggest:

These three pillars constitute the minimum viable Implementation Management Office (IMO) toolset to keep an integration focused on value and risk.

Defining decision rights by level

Value and risk indicate that something has moved. However, movements in either do not determine who acts. That is the role of the third pillar, and organisations commonly default instead to the existing organisation chart and to informal notions of ownership.

Each implementation level requires decision rights that are defined and agreed upfront. Workstreams are the mechanism that decide how the work gets done within their lane. The IMO decides sequencing and the trade-offs that cross workstream and drives implementation velocity; as an earlier article in this series argued, the IMO does not own business risks and makes no business calls. Anything that touches the deal thesis moves to the steering committee, which owns the “what” and the “why”, while the functions own the “how” within agreed guardrails.

Two simple rules do most of the work. Every decision resides in one level and a decision made twice gets treated as a system failure rather than a people failure, which is what the decision log is for.

In the example above, the technology decision had no home level. The owner was accountable on paper, but there was no forum where that accountability could be exercised, so a decision that needed a few weeks of structured work drifted for months. Such delays aggregate and compound across a program.

Escalating on the nature of a decision, not its dollar value

Most organisations run escalation triggers off internal delegation of authority levels. The process is familiar and has withstood scrutiny, so it feels rigorous. Typically, a decision moves up when it crosses a dollar limit. A delegation of authority matrix is a spend control, and organic operations require one, but it measures what a decision costs and says nothing about what that decision affects. The technology decision described above would have sailed under most dollar thresholds as the risk of making the “wrong” decision had many downstream implications.

On the integration programs that run well, escalation triggers are based on the character of the decision. Five triggers move a decision up a level, regardless of dollar size:

The first two triggers anchor to the deal thesis rather than to an approval limit, which is the essential difference. The character test also asks more of the people running the deal. A dollar limit allows a business owner to check a number and kick the decision upstairs. These triggers require that owner, and the IMO around them, to weigh the broader impact of the decision, including the second-order effects that never appear in a cost line. Leaders should set tolerances to suit the deal, for example a week on the critical path or a few points of variance on cost to achieve. The precise levels matter less than the agreement of those levels upfront, which forces a structured discussion of impact. The fifth trigger is the one that matters most on the integration programs that muddle through, because it catches decisions such as the technology systems integration call, which crossed every function and would have sat below most thresholds. It also doubles as the system’s smoke alarm - if it fires often, the problem is the decision rights rather than the decisions themselves.

Where to start

In my experience, integration leaders should install the first three pillars before day one, and within the first month after completion where that is not possible. Three actions matter most:

• keeping the toolset minimal at the outset, and adding only what the deal proves it needs;
• setting out decision rights and the escalation path in writing, with named levels and named triggers; and
• agreeing tolerances before the first hard call arrives, as hard calls arrive earlier than the plan anticipates.

Clarity on decision rights is a key pillar alongside value and risk when designing an integration operating system. Dollar thresholds alone are a spend control, not an escalation discipline, and relying on them is a large part of how integrations “muddle through”.

For more insights subscribe to our Business Advisory updates.