“Hidden” IT risks for acquirers

Sometimes you need to study history—or even forensics—to understand that company you’re eyeing

If your company is interested in acquiring another company (or already in the process of integrating it), pay attention: What you see, on the IT side, may not be representative of the actual situation—or cost.

What may appear stable may be anything but. What seems to be under control might actually be a runaway train. What seems secure may not be.

The answers are rarely on the surface. You need to dig, and know where to look, to find them.

In this article, we’re going to review a few of the “hidden pitfalls” that acquirers face, from an IT perspective, when they’re considering other companies to buy. All of the stories in this article are true, but we’ve been careful to anonymize them; consider it a “highlight reel” of many of our engagements, in which we’ve helped acquirers, and their due-diligence (or post-merger integration) teams, to avoid problems (best-case scenario) or discover and remediate issues (not exactly the best case).

What are the “in-flight programs”?

This is the key question to ask if you’re eyeing an acquisition target. You want to establish a financial baseline for in-flight IT programs—and then see if there are any issues that might deviate from that baseline, and thus cause problems for your due-diligence team.

We’ve seen acquired companies, for example, that have in-flight programs to install a new software platform company-wide. If you see something like that, start asking tough questions, and don’t stop until you get answers:

• What’s the history of this project?
• What was its original projected cost?
• How much has been spent on it so far?
• How far along, percentage-wise, is it?
• How much more must be spent?
• What is the defined future state? Has that remained stable during the project, or has it changed? And if so, how?
• Who is involved? Who’s in charge? How long have they had that responsibility? (And what, perhaps, ever happened to the person who held that role before them?)
• Is there accountability around this project? How is that scoped and charted?

All of the info you get, from the above queries, should go straight back to your mergers-and-acquisitions (M&A) team.

Sometimes the answers you get (only after really prodding) can be eye-opening—and painful:

• We’ve seen systems scoped for around $5 million that had bloated to more than $45 million—when they were barely more than halfway complete
• We’ve seen delays on the order of years.
• We’ve seen change-orders that have gone un-documented, adding to the complexity

A cultural issue

Don’t assume that the sponsor within the to-be-acquired company is your best source of information. Sometimes they’ll get in over their heads. We’ve seen companies that suffer from a well-intentioned “culture of forgiveness,” which translates to “try it now, try and fix it later.”

Example: What is the intended scope of that software implementation? If it’s, say, an ERP system, does the project sponsor fully understand every single business process it must support? A single lapse right there can grow into an un-containable problem.

Similarly, opportunistic vendors can exacerbate issues like these. They may seem very accommodating (“Sure, we’ll customize that process specifically for Mary!”), but that just amounts to higher costs. We’ve seen companies that have approved apparently-small change orders—but they keep rolling in, with no end in sight. That’s a sign of a vendor who’s looking out for their own interests more than their client’s.

Proven practice, potential pitfalls

There’s a reason that commercial-off-the-shelf or COTS software is generally stable and reliable: It’s been tested and debugged across countless clients and installations. It can thus be a safe way to proceed.

Contrast that to the “let’s customize everything” route. It’s not only more expensive; it’s more risky. It lacks the quality-assurance and testing that comes with COTS.

Of course, we’ve seen this, too many times to count. Worse, we’ve seen instances in which companies have customized their software packages—and yet failed to document what they do. So when “Mary” leaves the company, there’s no way of knowing how she worked. And the person who joins after “Mary” will need to have his or her software effectively re-baselined just so they can go to work.

There’s a reason that best practices exist. You don’t want to invest heavily in a software package that’s approaching the end of its support life: that can have serious security implications. Similarly, you don’t want to run such a compromised system on the same network with other mission-critical systems or databases—yet, unfortunately, we’ve seen this happen, too.

Forensics for fixing

When we help an acquirer—either before or after the purchase—to clean up the situation at an acquired company, the work can be daunting. To stop the bleeding, we’ll often “draw a line in the sand” for software vendors: “As of today, no invoices for changes that haven’t gone through proper change-control channels will be paid.” That gets their attention quickly.

Similarly, we’ll often bring in a strong program manager with business-analysis and SDLC (software development lifecycle) skills to “pick apart” a messy “Franken-app,” tracing down the exact people and processes involved, module-by-module (and if necessary, line-by-line of code) in order to find, and fix, the problems. As you can guess, this kind of work is expensive.

That’s why it’s best to avoid it in the first place. If you’re looking at a ripe acquisition target, you need the right people to scope the business, its IT needs, and, vitally, its in-flight projects.

Fortunately, at Ensunet, we do this kind of work all the time, having supported billions in acquisition activity and post-merger integration. Let us help you with that pending challenge: Contact us to learn more today.