November 25, 2015

1086 Views

IT Disentanglement Program - CIO’s Guide

Mergers and acquisitions (M&A) are increasingly becoming the new way of doing business. The surge of M&A is evident by the steep increase in the deals in recent times. In the first nine month of 2015 total of 1.5 Trillion USD deals were announced, 89% up for the same period in 2014. Interestingly, it is not dominated by a single industry; from Healthcare to telecom to Media giants to technology one can see M&As happening in all industries.

The rise in M&A is predominantly driven by four factors: geographical expansion, aspiration to get the niche advantage, expansion to new areas, and spinning off business that is least critical or troubled unit for enterprises.  In a 2014 survey of CEOs by Gartner, growth clearly dominates key business priorities list. M&A is always the easy choice for growth and often also the cause of worry. As CEOs are constantly worried about their competition having a leg up in identifying acquisition target before them.

In M&A, when the acquirer is a publically traded company there is extreme pressure to deliver on the promises to the street, often in a very tight schedule. This makes the integration of both entities a really challenging job. The complexities raises multi-fold when enterprises acquire spin off entities.

In this blog, I am going to focus M&A more from the perspective of the CIO, particularly focusing on spin off based acquisitions. The acquiring company CIO has a huge undertaking to make all the systems function and work in a pre-defined time period. Unlike the CEO, the CIO organization usually are not trained for managing M&A. There are lots of moving parts - regulations, market, and the senior management looking for results at a faster pace. To top it all, the transition of IT systems are driven by a time-bound transition service agreement (TSA).

The selling entity IT division may not have the same zeal as the executives to drive it to the closer and often they are burdened with two jobs, one for their existing company and another for the divesture exercise.  Often they have least interest for the latter as their compensation is not driven by the outcome of the successful transition of the IT systems.

In my experience in dealing with IT disentanglement programs, I have put together a best practices cheat sheet which I want to share with you.  Hopefully some of you will find it useful and make you aware of the potential pitfalls for your planning and execution.

People First

Whenever an M&A happens there are lot of uncertainties.  Always the good people leave first. As a CIO the first charter is to provide clarity to the extended organization about what the merger means to IT enterprise at large.  Create a handful of change agents in all departments who can communicate with the audience at large. Put together a technology medium, such as a web portal, for communication. One of the best and time tested medium is communication through town halls. Leverage technology to reach out to mass audiences through medium such as podcast. In such situation people have lot of questions and getting them answered by the CIO’s organization or through the identified change agent team put away lot of anxiety, rumors and uncalled resignations.

Business Partners

It is not about knowing the business partners but having a relationship with them. Please remember they have many more complex situations to take care of and IT may be low in their Agenda (except for critical applications such as finance control). Getting in their recall list and most importantly keeping them aware of “What to Expect or What not to expect” removes lot of unwanted calls and expectations mismatch.

Transition Support Agreements

Transition support agreements are usually very costly and often driven by short timelines. When defining the support agreements ensure the following

  • -Define granularly the involvement of existing IT team from the seller’s organization. A RACI (Responsibility, Accountability,  Controlled and Informed) chart helps in defining the responsibility matrix
  • -Be very clear on access to data and application definition
  • -Account for holidays and vacation time of critical players and put a workaround plan, if needed
  • -Sign off on a master plan before signing the TSA and make it part of the TSA. The master plan should have adequate contingency built in. Nothing goes as planned in programs like this
  • -Data segregation should be treated as a separate project
  • -Define the critical roles that you would need access to and have named individuals against it. Have both primary and secondary contacts
  • -Define success criteria with quantifiable goals and have business owners on both side of the house sign it

Success incentive plan

Keep some money aside to incentivize the team on both sides, upon successful execution of the program or milestone. This keeps the team charged up and motivated.

Identifying transition office

Although forming a transition office is not uncommon, what lacks in most of the transition offices are the representation of adequate functions. Following are some of the key functions of a transition office:

  • -Program management office – responsible for the planning, reporting, risk management and timely communications
  • -Transition Lead – there has to be one lead managing the entire program reporting to the CIO
  • -Key functional leads – from both the acquirer and the selling entity
  • -Key technology leads – from both the acquirer and the selling entity
  • -Compliance office – to ensure all regulatory needs are understood and a plan exists to manage it
  • -Change Agents – ambassador who will be responsible to manage change and represent the transition office

Understand the new entity’s IT Portfolio

The first charter during any spin off is ability to understand the acquiring entity IT landscape.  Good news is every organization would have some form of application repositories. However, in most cases it lacks in two front; data accuracies and application dependencies information such as, integrations with other application, databases it uses, the infrastructure it runs on and technology it utilizes. Not having this information handy deeply impacts any IT disentanglement program. Often the CIO is blindsided and depends on whatever information the selling organization provides. There are way too many IT disentanglement programs that goes off track because of lack of information resulting in a costly and painful migration. Not to mention the frustration business goes through in testing and functionality failures.

So how do you solve this problem? The first step is not to create a transition plan depending on IT application information provided as a single source of truth. Put a mini discovery project. There are many enterprise mapping tool like PRIZM (from HCL) available that helps map applications to database to infrastructure. It helps you to get all integration dependencies and the Technology Quotient (TQ) of the environment. With all the dependencies known you will be more confident on the plan you are putting together.

Ranking of application by business criticality and categorizing in Migration Zone

There is always an 80:20 rule in any IT environment; 20% of application matters the most and remaining 80% is ancillary.

As in the previous step, when the IT landscape information is gathered one of the best practices is to revisit metal classification or create one if it is not exiting. Giving a metal classification helps in prioritizing and clubbing them in look-alike zones for easier migration. For example if there is an application which is hardly being touched in the last 6 months (as evident from the data from the IT discovery project) and is not a compliance/finance application, it could be put in a least priority bucket. Similarly, if there are applications which have multiple interfaces and high complexities, it does not qualify to be the first application to migrate.

Data driven ranking and classification helps put a science behind the process and taking away emotional attachment of business, as in most cases it is seen evident.

Target environment identification

Infrastructure planning is a big part of any application movement. Cloud penetration into enterprises has made the job of infrastructure planning even more complex. Some of the best practices to follow are as below:

  • -Classify applications as on premise, software as a service ,platform as a service and  hosted  applications category
  • -For all applications which are not residing in the four walls of the selling organization, in the first phase, try retaining the vendor to minimize change. Once the transition is done, an organization wide rationalization program can be launched to streamline the SaaS and the PaaS providers
  • -For the on premise applications, get a complete list of software, hardware and integration details ( through the enterprise discovery project as explained before)
  • -Also, find out data dependencies – what data does not belong to you vs. data that you need to segregate
  • -For applications running on old H/W and/or S/W, this is not the time to upgrade to latest and greatest – try the cloning approach. Which is  keeping all the H/W and S/W exactly the same in the target environment and moving the application and its instances on to it
  • -Identify if there exists any service bus in the source environment – in such case the integration interface building becomes lot easier as one needs to confirm to service signatures. In case the service bus does not exists, a detail discovery needs to be done on all depending interfaces and a plan for stubbing the interface or redirecting it to correct interfaces
  • -Try using concepts like static IP, same host name for phase I to avoid any lookup related issues
  • -For application with latest H/W and S/W – install approach could be use which involves installing S/W, application and transferring data and booting the application up

Data segregation

One of the most unknown and complex transaction to handle is the data separation exercise. As the systems are getting disentangled one needs to ensure that only relevant data moves along with the application. This usually also has legal binding and often becomes one of the most critical items to plan. Following are some of the best practices for data segregation:

  • -Categorize applications by information criticality. For example, the application that has finance information or legal and compliance binding needs a different lens than a web site content management system. Categorization helps in putting adequate rigor on application that needs highest attention.
  • -Understand the master data model of the core applications. The MDM will provide the data entity relations and will help in executing the right scripts to pull out relevant data
  • -Make sure you have the core application owner from both the organization as part of the core team
  • -Develop a data migration strategy and test strategy
  • -Identify the historical data access strategy for legal and compliance requirements. Most of the time archived data is also required to be migrated.
  • -Involve the compliance team to ensure all data audit measures are well taken care of.
  • -Finally, block testing time of application business owners for testing. Often the data sanctity is verified by the reports the system generate and the business process the system follows through. Testing is critical to ensure process and data accuracy. 

Future Readiness

While cleaning application and doing business enhancement should not be encouraged during a time bound IT disentanglement project however this is also a great time to assess the new environment. By doing this assessment you plan well for application optimization and modernization exercise down the road. Following are some of the things you can plan to do:

  • -Clean up the CMDB and create a good inventory of application – as discussed before tools like HCL’s PRIZM is very useful to generate application inventory
  • -Perform a cloud assessment strategy – while you do not need to move anything to cloud with the word go. It is always helpful to know, if tomorrow you decide to move what are the pitfalls or areas to look out for
  • -Identify applications which are heavily customized. These are the difficult ones to upgrade or modernize. By knowing the granular level of customization you can plan for future modernization exercise well
  • -Create an application decommissioning strategy, either to see how they fit with your existing application or to be retired and modernized

Conclusion

IT disentangled programs are complex transactions. Often you are driven by factors beyond your direct control. The only part that is in your control is the plan that you build for a successful migration. I hope this blog will help you as an IT leader to plan your migration well and execute successfully on many more IT M&A programs to come in the future. Please do leave your comments, suggestions and learnings in the comment section to make this blog more useful for others.

References

http://www.gartner.com/newsroom/id/2707517