Discovery – The Art of Finding Reliable Data

There are only two kinds of application engineers: those who say
“Data is the problem” and those who say “Data are the problem.”

The infrastructure team was provided systems discovery information from a variety of sources including internal IT, contractors and key IT support vendors. The team was delighted to see “current-state” systems information. However, the team became concerned about the accuracy of the information because key application end client information was missing. The consolidation team decided to perform first hand verification of all “current-state” data. The program manager consulted with the sr management team and hired contract systems engineers with extensive application and desktop experience to review “current-state” discovery information and verify the information. In many cases, the contract network engineer had to reverse engineer networking equipment and actual protocols to obtain an accurate “current state” data. In addition, acquiring company subject matter experts were engaged to verify and document as-built server and storage system documents. For example, reverse engineering revealed the current state network documentation did not reflect actual configurations and existing routes. In another case, another key subject matter expert identified networking equipment was owned and maintained by telecom provider Sprint instead of by the company. Additional verification revealed remote access equipment had been partially configured and was unusable. The original project had been abandoned by the IT staff short of being fully configured for operations. Application verification and reverse engineering identified software code that had been written with network third party vendor addressing and communications hard coded into the software bypassing the data file inter-exchange through the company data interexchange server.

The verified “current state” was significantly different than the “current state ” provided by vendors and staff.

Lesson learned:

There is no hard-and-fast reliable information source. That would be too easy.

IT Contracts – Due Diligence

 

A Slight Misunderstanding

 

In one acquisition, a domestic technology outsourcing company was contracted to provide key IT services through a twelve month transition period.  Upon signature of the acqusition agreement, the integration transition team asked for the IT equipment access credentials.  The outsourced service provider, a well know M&A services leader, refused to provide the credentials.  The problem turned out to be a difference in interpretation of the contract agreements by the IT service provider subcontractors, also well known industry leaders.   The acquired company spent the next four months renegotiating the contract and the subsequent release of equipment access credentials. 

 

A review the transitional services contract revealed vague contract language with no enforceable service level agreements or “exit” clauses.  The acquisition company management team implemented a successful strategy of appointing key staff members to review all service requests and develop direct line relationships with the subcontracting IT service provider to ensure delivery of services.  The acquisition company had several large contracts with the subcontractor and had considerable financial leverage in driving service delivery.

 

Lesson learned:

 

All misunderstandings concerning contract specifications will eventually be resolved.  The best time to do that is before the acquisition agreement is signed. 

 

Tip: Hire dedicated IT contract M&A specialists to review, negotiate and (re) write all IT contracts prior to acquisitions. 

 

https://joetighe.wordpress.com

Application Inventory – Due Diligence

 

Application Inventory Strategy

Acquire business application information during the due diligence phase.  Adopt a strategy that will identify the most critical applications in advance of the acquisition and focus the available task resources on critical business applications first.  Where the target company lacks application information, immediately allocate skilled M&A IT resources to reverse engineer applications.

 

Key business applications are often undocumented or misunderstood by the target company.  

 

A company with mature information technology internal controls will have documented detailed application interface inventories.  Business application stakeholders and lead information technology personnel for each application will be documented.     However, many IT departments do not have mature internal controls and systems documentations, in particular startup companies or smaller enterprise organizations.

 

In most merger and acquisition programs, expect minimal application inventory documentation.  Review the target company business continuity plan first for information.  However, expect outdated and inaccurate application information.  Key applications may missing from the documentation.  Additionally, there is often no technical description of the application interfaces or technology owners.  Business owners are often outdated or inaccurate.  Be prepared to assign experienced M&A system engineers to reverse engineer applications.   In addition, be prepared to assign skilled M&A systems analysts to interview business units to identify ALL key applications and to interview software developers to identify application programming interfaces.  And, expect a low level of cooperation and urgency from the acquired company development team. 

 

Expect significant application data gaps and identify the risks early on, during the due diligence process if possible.  Some development departments operate independently from the operations departments creating additional gaps in integration knowledge.  Allocate sufficient time to perform application programming interface discovery.  External contract engineers can be utilized as needed to reverse engineer applications and provide interface inventories. 

 

Allocate adequate discovery time during due diligence to close the application knowledge gaps.  The following resources should be allocated as part of the overall IT M&A program:

 

·         Allocate 75% of your time to collect application interface data.

·         Fill in the blanks by reverse engineering core applications.

·         Run a trial cutover on low priority servers and desktops to identify gaps.

·         Allocate 25% of your time to resolve application issues during conversion.

  

By following this strategy, you will focus the integration teams on key applications having the greatest impact on the business and you will increase your rate of successful IT M&A program outcomes. 

 

 https://joetighe.wordpress.com

 

Project Management Scaling

 Project Management Scale – Acquisition Integration

 

Be careful how you scale the information technology integration project management effort.  You might get it.

  

IT Infrastructure integration efforts can be brought to a standstill by excessive project management controls.

 

In one mid-size enterprise organization merger, the project management office (PMO) was often a valued change agent in the IT infrastructure conversion project effort.   However, the type of project management controls and processes applied were often over-scaled, overly complicated and more suited for large scale government programs.  If your project management team is oversized, you can expect excessive overhead costs and staff meetings driven by junior staff members adding little value to the process.  A large project management organization may offer an excellent training ground for junior staff and contract consultants however, the resulting output will often be of low quality or unusable.  The overhead administrative costs relative to the size of the acquisition may be unacceptable. 

 

By scaling the project management effort to a mid-sized acquisition, a simplified set of project controls and a smaller project management staff may be sufficient.

  

Project Management Scaling

 

The first rule of organization is to scale to fit the size of the task. 

 

For mid-sized acquisition efforts, consider limiting the project management staff to two or three key members.  Ensure the project management staff reports to the acquiring company’s program management office.  This will serve to appropriately size the integration organization to the task, provide appropriate governance and ensure alignment of the local project management teams with the acquiring company integration objectives.  

 

Trim the fat.

 

https://joetighe.wordpress.com