By Bill Vinck, Excendio Advisors
Background
The Information Technology Ecosystem (ITE) is a complex area that should receive a great deal of very specific attention during M&A due diligence. The ITE is itself a rapidly evolving universe and the due diligence process that reviews it should reflect that complexity. Failures in this area can threaten the M&A investment thesis.
In this article we’ll review the standard checklist approach which is clearly necessary; but we’ll argue that it is dangerously insufficient. We’ll review one area in which the insufficiency is pronounced. In subsequent articles, we’ll review five additional areas.
Check lists? Necessary but are they Sufficient?
Standard Industry check lists on IT due diligence are often helpful and correct. Here’s an abbreviated example:
One should collect the following information:
- Details of any current and planned IT initiatives/key projects.
- Summary of key IT resources (hardware/software/people).
- Policies and practices for the purchase and maintenance of software.
- Summary of all material software utilized by the target firm.
- Policies and practices regarding the purchase and maintenance of IT hardware.
This type of review is important in that, as an acquirer, one is getting a suite of IT related assets and it’s important to know what one has acquired. This is an important administrative step and it’s a necessary step. But as an aggregate of data, how helpful is it?
Our argument is that while necessary, such an approach is insufficient. This insufficiency potentially distorts the value, up or down, of the acquired company as well as the costs and risks of company integration. In turn, this insufficiency obscures a clear understanding of the strategic value of the proposed transaction.
Think of the ITE as analogous to the central nervous system of an organism. The overall health and smooth operation of the CNS is critical to the successful life of that organism; problems there comprise the function and, eventually, the life of the organism.
The standard industry check-list approach, while necessary, can fail to disclose key elements of the ITE. By following such an approach to IT due diligence in an M & A transaction, the buyer may not fully understand the ramifications of their purchase. In what follows we add several major topics to the IT due diligence scope to illustrate the problem. These topics help the acquiring firm move beyond necessity and approach sufficiency. These topics share several characteristics:
- In-depth understanding of them is critical to successful business integration.
- They are critical points of intersection between technology and the operations of the business.
- They require detailed technical, process, and business analysis beyond simple data gathering.
- Findings in these areas can materially alter deal terms and even raise questions of deal desirability.
There are six major topics to be considered. We’ll deal here with the first topic and will discuss the others in subsequent articles. The major topics that address the sufficiency issue are the following:
- Company Technology Culture.
- Supply Chain Relationships.
- Cyber Risk Management.
- Competitive Advantage Readiness.
- AI and IP.
Company Technology Culture
Both parties to an M&A transaction have a company culture and may acknowledge the need to understand those cultures as a preamble to the integration of the firms. Both firms also have an IT culture that must be integrated sooner or later. As there can be major differences between company cultures, that possibility exists as well in the ITE subculture. In many ways, the ITE sub-culture can be either a major enabling institution or a potential obstacle to transaction success. Knowing in advance which it will be is critical.
What is an IT culture?
It is:
A way of thinking about technology
What role does IT play in the firm today? The standard answers, of course, are versions of “IT is critical to our business, etc.” These days who would maintain IT is trivial? But wherein does this criticality lie? The due-diligence analyst must dig for examples as they will demonstrate a key linkage between senior leadership and IT leadership. This linkage reveals the quality and sophistication of the relationship between senior leadership and IT leadership. It is a report card on the success of that relationship.
A fondness for certain vendors and tools
Some IT organizations have adopted tools after exhaustive analysis and a detailed mapping of product capabilities to defined requirements. Others are less formal. The acquiring firm will likely see some difference of opinion in technology selection which must be addressed in the integration plan. Platform and tool integration can be a significant and sometimes hidden area of emotion and expense. A joint target technical architecture is a likely post-acquisition integration project. Vendor and tool “fondness” can easily provide challenges during integration. Such challenges result in increased time expenditures and increased cost both of which hurt the investment thesis.
A suite of relationships with certain vendors and an avoidance of others
Product excellence is only one of several ways vendors have of establishing and sustaining relationships with IT leadership. Understanding how product decisions were made reveals many things not the least of which the quality of IT leadership in the acquired firm. Similar to the above point on “fondness”, this area can reveal insights on the IT leadership team.
A way of making decisions about projects and an approach to project management
IT leadership has heavy doses of project management embedded. Few business functions spend more time managing projects than IT. How is it done? Is there a standard approach used by all project leaders? How is project status communicated to senior leadership? A seemingly straight-forward technical implementation may raise business operational issues. How adept is IT leadership at recognizing and framing these matters for senior attention?
A way of dealing with company management vendors, and customers
Most companies have a technical architecture for communications with outside business partners. What does this architecture do? How is it managed? Can it be seen as robust, i.e. supporting interactions beyond the current demand? Would one describe this architecture as sophisticated or elegant or it something cobbled together reflective of limited budget and unimaginative technical design?
A set of beliefs on what priorities exist
Every leadership team has a conversational grasp of the firm’s business and IT priorities. What are they? What does the description of these priorities say about the intimacy and depth of the communications between business leadership and IT leadership? If this depth could be quantified there would be a direct positive relationship between great depth and IT success.
An approach to finance and financial control
IT leadership spends a lot of money. How do they think about it? How do they justify various expenses? Look at a proposal for a new project and ask “How is this justified?” Is there a compelling depth of analysis that would persuade rational but skeptical leaders? Have the depressingly standard cliches been avoided?
A pace of work energy and a style of leadership
There is an organizational energy in every IT organization. That energy reflects, among other things, the morale of the staff, the quality of the leadership, and the confidence of all that important work is being done. So how can that energy be described? One can watch it daily as the IT staff goes through their day. Project meetings can display energy or its’ lack. Communications, formal or informal, with senior leadership are a leading energy indicator. What is their frequency? Intensity?
Attitudes towards learning
Of course, it’s commonplace to describe the IT universe as constantly changing. How does the target firm approach that fact? How is staff training structured? How are new technologies introduced? Professional development in some organizations is non-existent. In others it’s highly unstructured, i.e. a staff member selects a program and attends…box checked.
Conclusion
IT due diligence checklists can be robust and detailed. Our argument here has been that while necessary, the typical checklist may be insufficient in that it fails to deal adequately with the six topics mentioned above. Dealing with these topics requires judgement, experience, and an ability to observe a broad spectrum of phenomena. The leader responsible for the IT component of due diligence should be armed with the tools, background, experience and management support to conduct the needed analysis. Failing that review jeopardizes the transaction.
As the great philosopher Mick Jagger put it: “ You can’t always get what you want, but if you try sometimes, you might just get what you need.”