Why PMI projects differ from traditional projects

Post-merger integration projects amplify every challenge you usually face during transformation projects.
Hutton Henry

Once a merger has been agreed and integration planning is underway, it’s time to map out your project.


First, every PMI project has its own set of challenges. Second, a PMI project is a very different beast from a traditional IT project. With this in mind, you need to examine the complexities, scope and relationships that are going to come into play during integration.


Why PMI projects differ from traditional projects


Multiple parties are involved

Once a time-frame for integration has been agreed, there will be pressure to get your project team together.

With a traditional IT project, you only need to think about the team doing the delivery and the business unit on the receiving end. With a PMI project, you need to consider two technology teams and multiple business stakeholders.

Each IT team is going to bring their own technology infrastructures, processes and cultures. There will also be different levels of capabilities and varying attitudes towards delivering technology.

All of this needs to be taken into account when pulling together your IT teams.

There is more public awareness

Every aspect of a PMI project can be under scrutiny at every phase, from the joint project board, shareholders to your technology teams and suppliers.

This generates a lot more pressure than the average IT project, especially when deadlines are set and determined by factors beyond the control of your technology teams. Into this pressurised environment is the need to align your PMI project with business and logistical changes that are taking place at the same time including office moves and retraining staff.

Any delays can have a major impact on integration, and your technology teams may buckle under the weight of this burden.

Project slippages are more complicated

Unlike traditional IT projects, the stakes are much higher when it comes to PMI. The IT landscape is more complicated and it’s difficult to commit to a deadline that will suit all parties.

When a Day One date is decided on without consulting IT teams, it can have a negative impact. You may also find that assumptions have been made about technology and transformation timelines during the project planning stage.

In these circumstances, project extensions are inevitable. However, you need to be wary of making your teams feel demoralised and as though they are always failing to deliver on time.

Change control mechanisms are necessary

Change advisory boards (CABS) are a necessity within enterprise technology. Representatives from business and technology teams need to examine change from different perspectives to determine the impact on the business.

In a PMI project, you’re bringing together two or more CABS, each aligned to their company culture. And when there are different ways of operating and varying attitudes to risk, it can take time to deliver change.

CAB processes can clash when parties disagree on modifications and delays arise when a CAB is slow to respond. An early awareness of CAB processes can resolve some of these issues – as well as comprehensive documentation of what systems are used to record and implement change.

In summary, an awareness of how a PMI project is different from a traditional IT project will help you to take the right approach to integration from the start.

Plan for PMI success

If you'd like to know how to prepare your teams and systems for post-merger integration success and gain maximum value from your IT, contact us for a friendly discussion regarding your particular business needs on 0800 622 6719.


New Call-to-action

More Posts

M&A Scorecard