Envision – develop and stress-test a technical delivery plan
A good Post-Merger Integration plan is effectively a sales document that will be circulated and assessed by all parties. Therefore, it needs to be convincing, and it needs to work.
Everyone’s eyes will be on the transformation team’s proposed plan, which will assess the feasibility and associated risk.
To move into a pragmatic ‘doing’ phase, you will require buy-in from all parties, therefore the plan is effectively a proposal that needs to demonstrate:
- You understand their business
- Key production services are in-hand
- Data and services will remain intact
- Engineering input has been gathered and included in the plan
- Any R&D activities and potential costs highlighted
During the Envision phase, the technology architects representing different parties will engage with each other to establish if the assumed ‘synergies’ between systems will in fact work, and determine what is needed for them to work together. This will result in a high-level solution and low-level technical design for all major systems.
Solution testing of end user applications will be undertaken, and the phase will complete with detailed dress rehearsal planning to determine how system changes will be made.
The outcomes of the Envision phase are:
- A technical design and approach that fully outlines an effective Day One integration
- A realistic and achievable plan that everyone buys into.
The Post-Merger Integration team need to develop a plan that breaks down the assumptions that have been made regarding the technology platforms and expected technical and financial benefits. Many of these assumptions would already have been challenged during the Engage and Envision phases.
The technology solutions defined in this phase need to be aligned to the business requirements, whilst also ensuring buy-in from key staff in the joint Post-Merger Integration team.
During the Envision phase you need a deeper level of commitment and attention to detail from the team members.
Common Mistakes
1. Approaching post-merger integration as a standard IT project
The post-merger integration project plan has a major long-term impact on the employees and working environment of the merged/divested entity, long after the technology project has completed. Whilst the need to get the plan as accurate as possible is obvious, how the employees are consulted and engaged will impact how the extent to which they will ‘own’ the solution in the long-term. To put it simply, any negative perception of how successful the integration has been will live far longer than the project.
Due to the nature of the project, at which point everything is ‘up in the air’ the number one cardinal sin is a lack of governance being applied to the programme. One problems can arise due to accountability, and who the PMO team represents; unless the team is made up of resources from all parties there may be a bias to their reporting – this is just human nature. But if one, more dominant side is running the project, the other side may become slightly passive. In the situation where one side is passive, the governance will not be effective, as no one is questioning the delivery.
And also note, even with a PMO team in place, this does not mean that governance is being applied effectively, they could simply be taking up more seats in the board room.
If the project team approaches the project without a specific M&A strategy, the team will feel this and will stop responding. After some time, the danger of this situation will become apparent, with either lack of results or many open activities that do not seem to have a valid solution.
This situation will escalate, because once the technology teams start to become dismissive or despondent regarding the project, they will, without a doubt, start telling their colleagues in the wider business. If this is allowed to happen, the impact will far outlast the initial merger activity, as staff will come to consider everything emerging from the technology team in the new world to be sub-standard, and are likely to complain many years after project completes. This may not be a concern for the M&A deal makers, but it creates a challenging working environment, which increases the risk of the best technology employees from both sides leaving the firm. Or, and even worse, they don’t leave the business but complain constantly – becoming “actively disengaged” from the previous integration and everything the technology team delivers in the future.
2. Synergy pressure
The deal pressure of delivering assumed synergies can prevent the overall post-merger integration from completing.
Synergies are amongst the foremost reasons for an M&A deal to take place; however, those synergies that support savings, rather than new revenue, are the most successful. Synergies that assume revenue increases, from bundling or cross-selling into each other’s marketing, can be difficult to realise.
Realising synergies takes up management time. They require numerous outlays (severance packages for fired employees, for instance), and sometimes need further investment, including even further post-merger integration of the IT systems.
3. Technical design
Other than the additional complexity, technical design is one of the few areas where there appears to be no difference between a traditional and an M&A project.
However, you will be working between at least two Architecture teams, who may have competing ideas or different approaches.
Gartner states that enterprise architecture (EA) is:
“… a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalise on relevant business disruptions.”
http://www.gartner.com/it-glossary/enterprise-architecture-ea/
This definition is a little wordy. From a practical post-merger integration delivery perspective, it means that your technology design will produce the ‘sales’ documents to pave the way to agree major change.
If we turn things upside down and treat technology design documents as sales documents not technology documents, then we can approach them in a sales-oriented way. Good sales documents:
- Are engaging
- Use original content, not boiler-plate
- Are concise
- “Sell the ingredients, not the cake” – i.e. they sell the results
- Demonstrate the value of the product
- Start with the end-user journey/experience
- Provide clear guiding principles
- Align well to customers’ needs
- Use case studies as examples
In addition – and this is the theme that runs throughout Gartner’s book – it is essential to brief and engage staff in order to deliver successfully. This becomes very apparent as the teams work together to deliver an agreed technical solution, as without engagement:
- The teams will not work collaboratively
- There is a major risk of not meeting business requirements
- The solution design will be excessively flawed (no design is perfect)
- Downtime is almost certain
- Financial impacts may be seen during the project and post-Day One
Hence, do not deliver a traditional technology design, design one that sells.
4. Transitional Services Agreements (“TSAs”)
This is one for the service management team and legal teams. The TSA is a legal agreement, separate from the M&A purchase agreement, in which the buyer agrees to pay the seller for certain services to support the divested business for a defined period of time.
TSAs are most often used in carve-outs where the buyer lacks the necessary technology capabilities or capacity to support the business on its own.
For instance, many private equity (PE) firms rely on TSAs until they can identify and engage an IT outsourcing vendor. TSAs are also often necessary when the deal closes faster than the buyer’s IT organisation can respond.
Common TSA mistakes are:
- Not taking relationship changes into consideration
- Not putting all requirements and expectations in writing
- ‘Never-ending’ agreements
- Using a TSA to put off the integration strategy
- Poor identification of scope
- Poor costing model
- Setting unrealistic targets
- Assuming it will be easy to extend the TSA
Conclusion
We are constantly reminded that robust technical designs and project plans are essential for smooth transformation project delivery. This is certainly the case here, but the main difference with post-merger integration is that the projects are: (a) not like normal major projects; and, (b) not often alike.
As the programme lead, before you can make an effective plan you need to ensure staff from multiple parties are engaged and on-board with the change, and that your team has taken the time to accurately determine the hardware, software, people, and processes involved before they can create an effective design and plan.
This is one part of a series of five blogs on how to deliver a successful post-merger integration, the other sections can be found here:
5 Post-Merger Integration Challenges: Part One – Employee Engagement
5 Post-Merger Integration Challenges: Part Two – IT Due Diligence
5 Post-Merger Integration Challenges: Part Three – Planning and Design
5 Post-Merger Integration Challenges: Part Four – Day One Cutover
5 Post-Merger Integration Challenges: Part Five – Evolution
{{cta(’23b74a59-42a2-4a7c-8ded-6111a29634b7′)}}
