Tag Archives: M&A

My grandmother hooked me on puzzles during my childhood with crossword and word search games. We bought the word game booklets for the car ride to vacations in St. Petersburg Florida. We also worked on them after school when I spent time at her house waiting for my mom to pick me up after work. Those were some good times.

Now, some forty years later, I still love to solve puzzles. Finding or building solutions is what energizes me at work and it is one of the reasons why I chose Information Technology as a professional career. Every week is a new adventure. Systems and hardware will fail. There are business workflows to automate. There are new solutions sold in the marketplace. For me, it’s like that word search game just became tougher to solve!

Perhaps the ultimate IT puzzle is to retire and consolidate aged applications in the enterprise portfolio. Productions applications have roots that run deep into the organizational framework. Applications have embedded logic for business rules, process flows, and client customizations. But over time, applications become outdated based on the underlying support platform, the user-interface, or the knowledge of the technology staff. Additionally applications become repetitive as organizations grow through mergers and acquisitions. Seemingly overnight, the business is faced with decisions about how to best retire and consolidate applications to keep costs in check and systems reliable. This is the puzzle that finds us at some point. All of us.

Keep the car moving!

Shutting down a production application is tough stuff. It can be disruptive to the departments that rely on the workflow. It can also be disruptive to the clients that rely on the application. My experience is that businesses don’t look to simplify or improve the workflow during an application change, but instead they place requirements that the new application should do everything the older application did. This equates to more complexity. Clients that have large number of customizations on the systems are deeply rooted as well. Business owners usually doesn’t want to inconvenience a client with an application change because there is often no value-add for the client. It’s a risky endeavour! To retire the application is analogous to changing tires (applications) on a car (business) still running.

My general approach to application retirement.

There is no single answer on how to retire and consolidate applications in the enterprise. Factors could include a wide range of criteria including integrations with an ERP, compliance, the knowledge of support staff, licensing fees, client usage, and order volume.

The high level approach that project teams I have been on have used are:

Pick the surviving application based on the criteria most important to the business.

Bring the surviving application online in parallel with the system(s) it is replacing. In the case of an acquisition, it may already be online.

All new clients to the business are added on the surviving application.

Migrate existing clients or business processes to the surviving application.

The most difficult step is usually the last one. This is the part of the puzzle that requires creativity, patience, and gamesmanship.

If you’ve ever been employed by an organization that has either bought another company or has been bought, then there’s a good chance you have witnessed organizational culture meshing. I think of it as the company culture melting pot. In some cases a purchased company is left alone as an independent business unit and may function outside the boundaries of most of its owning parent. However, there could still be culture shifts in either company related to best practices and cultural norms of the other.

I’ve worked in organizations that have acquired other companies and I’ve worked in an organization that was acquired by another company. I’ve witnessed and lived all types of cultural shifts as a result and I thought I’d share a few of my observations.

“Legacy” is redundant

The term “Legacy xxxxxx” is often used to designate a previous brand or company name. Sometimes we use it in systems speak to designate a system that pre-dates the current system. As I think about it though, it’s really not needed as a prefix because in the context of conversation or written document the name/brand of the element it modifies is unique. I won’t go so far as to say that legacy implies a fully negative feeling of the name/brand it precedes. But it’s often used in context to mean:

* That was then and it’s out dated

* We have to live with it

* That was the archaic way. Someday we’ll turn it off

Here’s the deal though. The historical elements in your organization whether company, process, or program are all now part of the existing portfolio of what makes your company unique. Sure the purchased company may not exist any longer, but you don’t need to say Legacy CompanyABC. CompanyABC itself will suffice and gives due respect to that name/brand for the value it holds in its historical context.

Bust silos with assignments that cover the entire portfolio

Nothing creates silos of thought and turf wars faster than keeping people assigned to specific programs and processes within previous companies. So if Joe worked on Program A at Company A and Bob worked on Program B at Company B then they’ll see each other somewhat as competitors in discussions about their respective programs. The way to relieve this organizational strain is to give them both responsibility over programs A and B. In this way, they will create work that is for the betterment of the organization and not their respective silo. Often times programs A and B will be redundant. The way to remove the protectionist feelings is to get the entire team involved in the entire portfolio. It’s good for career growth as employees are allowed to learn new areas and given increased responsibility.

Promote unique functions where they exist

Sometimes as organizations merge together there is a functional area in one company that didn’t exist or was outsourced in the other company. If the company leaders decide to keep that functional area in-house then promote that to the broader organization as one of the advantages of the newly combined company. So often employee morale is hit because redundant areas typically mean job losses as the new company looks for economies of scale. So where there is no redundancy, promote it and the benefits that group brings.