Introduction

Technology transformation within Merger & Acquisition (“M&A”) scenario is not easy.  It certainly doesn’t help when IT project deadlines are created based on the commercial aspects of the M&A deal – often without consultation with the technical teams.  Teams who are so crucial in the delivery of these projects.

Good M&A IT Programme and Project Management is a given.  Both are essential to integration success.  But often the technology workstream fails or misses deadlines due to these common planning mistakes:

1. Actively-Disengaged Staff

Often we join a project team that has recently been informed about their business being acquired. It is a very sensitive period of time and some basic questions need answering, such as:

• How will this recent announcement impact my job security? 
• Who are these new people coming in to assess our IT systems? 
• What will they think of our current systems and processes?  

But a crucial question, the “what’s in it for me?” is rarely answered.  Whilst the IT staff can see the obvious corporate benefit to the company buying their firm, how does that translate to a benefit to them personally?  Will they be able to continue working in their role?  What can they learn from this experience?  Will it be a good experience?  

If these questions are not raised and answered early in the M&A project it is likely to foster actively-disengaged team members, people who do not buy-in to the proposed changes but do not leave the organisation.  Instead they may block progress and this can lead to highly expensive project delays and replanning, the cause of which are often hidden and therefore untrackable.

Therefore it is critical that IT staff are engaged with the proposed changes – that they understand how the deal both benefits the companies invovled and they can see a personal benefit, no matter how small. 

2. Lack of Inventory / Out of Date Inventory

To plan well, you need to know what you are transforming.  During the early stages of the M&A the requirement to understand the target IT environment is essential. Technology environments have grown organically as companies have grown, the focus is on delivering responsive, resilient services – not documenting them.  So the environment may need assessing and documenting before any changes can be proposed.  In addition the information may be required early during contract negotiation and there may be reluctance to reveal too much information too early.  Yet access to a quality CMDB greatly accelerates the discovery process an discussions and helps all parties understand where they may be synergies be it technical or otherwise. 

• The M&A IT integration team may have to spend unplanned time documenting systems.
• There may be the risk of unplanned expenditure and implementation of asset management tools or developers to collect the information.
• Worse case there may be the need for staff to collect the information manually.

I have never worked anywhere in the past 29 years where the infrastructure is smaller than expected.  So getting a reliable, accurate inventory is an essential step for success.

2. Approaching M&A IT as a “standard” Project Plan

A traditional appraoch to planning a IT project is to build from the ground-up and create workstreams as needed.  But in a M&A IT project you need to convince more than one set of stakeholders to buy-in to you and the plan.  In addition, you need to spend less time on standard commodotised IT services (think e-mail, back-office functions) and more time on the business critical services that are specific to the organisation – as they will probably take longer to transform into the new business and if they are bespoke to the company there may be more challenges remediating it before any planned moves. 

Therefore, the better practice is to be prepared with a set of standard workstreams of commoditised IT that would be common for all or most companies and use this as a baseline and spend more time on the specific services and technology to try and reduce any future curveballs.

For further detail, see this post on how M&A IT projects differ.

3. Too much / little detail in the Project Plan

 Often, due to the sheer size and complexity of the planned change, the resulting project plans can be vast.  Long project plans may appear detailed, and maybe even impressive, it may be lost on the people that matter – the staff who will deliver it.  

Conversely, there have been occasions where project plans are not detailed enough.  In these situations, a high-level plan has been developed with guesstimates across all changes which may be fine for the project board but will demoralise the delivery staff.  This level of planning may have been sufficient during the M&A bid but it is a very risky approach when attempting to actually deliver the project.

4. Unrealistic timelines

A common planning and delivery challenge is that the deadline for the M&A deal has been set prior to a detailed assessment of the target business IT estate.  Consequently the Day One cut-over date may demoralise the IT team as they think the timings are unrealistic and therefore slowly stop to engage with the project.  For other staff they may not query the date but work every hour possible to see the project “over the line” but this leads to unhealthy working practice and in some cases absences and sickness impacting the project at critical points of the project.  A pragmatic and strong programme lead is essential to drive the teams with close attention to detail to ensure deadlines can be met and a consistent message delivered through the project life-cycle. 

5. Time Spent Meeting 

The challenge with M&A projects is the number of technical teams involved, combined with differing appetites for risk.  If their approach changes between them is radically different it can create a significant of proof of concept type work to ensure all sides agree with the approach.  This can sometimes create a cycle of meetings.

During the early stages of the deal and IT due diligence, both teams need to learn to trust each other.  The temptation is to spend the first weeks in meetings discussing all the detail, and then to burden the service SMEs with the need to attend every single meeting where decisions may potentially be made.

Often, the buyer does not have access to the seller’s IT systems, so discovery of information is via meeting with the seller’s SMEs and other members of staff. 

Hence, awareness is required to determine the points when meetings turn into “doing” so that the teams spend time delivering rather than discussing theoretical outcomes.  

6. Day Two Considerations

Throughout the project HR teams will be working hard to ensure the personal needs of employees are met.  But from an IT employee’s perspective many things will change – will they now have to adhere to new corporate standards?  If they are a developer will the new firm have different or even opposing coding and development practices?  Will staff have the same administrative access to IT systems and services that they had prior to the acquisition? 

If access is removed from staff they may not really feel the impact until they move to their new positions – and at this point, when staff from both firms are getting used to working with each other it may become difficult to perform their roles.  Whilst technical designs will always assess the end-user experience for post-merger working conditions the same exercise is needed for IT staff that are moved as part of the deal – if done correctly, you can set expectations and reduce the “noise” post transition.  

Conclusion

The above list is not exhaustive, as that would take an entire book (something I have already drafted).  It would be very interesting to hear your feedback and learn of your experiences in this field.  I am interested in addressing problems in M&A projects, because IT staff are often deeply affected by these major changes which can seriously impact their careers.  So the better prepared and managed, the better potential outcome for all. 

{{cta(’23b74a59-42a2-4a7c-8ded-6111a29634b7′)}}