The IT side of M&A integration involves much more than an integration of IT systems; due to the business risk involved, and in the effort to create value from the M&A, it will demand complete, accurate, consumable software requirements.
Done properly, it should really start with a negotiation of business needs, with the system integration following. Chances are good that the acquired organization does things differently than the acquiring organization, and IT product managers need to understand the business rationale behind the acquired company’s methods before embarking on an IT integration project. Visual software requirements models are an indispensable tool for any product manager or business analyst taking on an M&A integration, for a few reasons.
First, understanding the acquired company’s business needs can help to prioritize requirements and establish the scope of the project. Not everyone can get everything they want, and establishing the high-level business objectives of the integration project at the beginning will help immensely when hard decisions need to be made later.
Product managers should use business models like the Business Objective Model and Objective Chains to outline the goals of the project so that business analysts have a framework to guide them when deciding which features of the acquired company’s systems are necessary to keep which ones are not. This allows business stakeholders to have an important high-level discussion about how they want to reconcile those differences before unleashing their product managers and business analysts on requirements gathering.
Second, software requirements using visual models can help to highlight differences between the two companies’ processes in a way that other requirements documentation simply cannot. Process flows, for example, can be a business analyst’s best friend. On a recent project I worked on, we first documented the existing functionality of a certain feature. Then, based on the high-priority business needs of the acquired company—which were previously discussed by the business and communicated to us, of course—we created future-state process flows, highlighting in yellow the additional steps that needed to be added to accommodate that business need.
During requirements gathering and implementation discussions, this technique allowed us to do two things. First, during elicitation sessions, it allowed us to focus the discussion on the areas where the changes would occur. Having a visual model that clearly called out the changes that needed to be made helped to spark a useful debate about the benefits and drawbacks of addressing the business needs in the way we were proposing and led to refinements that benefited everyone. Second, when it came to write requirements around the changes that were needed, being able to reference specific process flow steps helped to organize the requirements in a consumable fashion and ensure that we didn’t miss chunks of requirements.
IT integration projects between two companies can often be risky and complicated. At stake are hundreds, thousands, or even millions of customers who are familiar with the acquired organization’s processes and are used to doing things a certain way. Further, the risk to a company’s valuation (and the opportunity to realize all the business value expected) is significant. But these projects also represent a huge opportunity. Done correctly, both firms can take advantage of the other’s best practices and create solutions that combine the best of both. Business analysts and product managers have a huge role to play in these types of projects. With the right attitude, the right (visual) models, and good requirements, IT product managers and business analysts can help ensure that these types of projects end up a success!
