During a live Q&A in September — 7 Tips and Tricks for Successful Technology Due Diligence and Integrations — Mart Lumeste, Co-Founder of Intium Tech covered the challenges and best practices for creating technology integration playbooks, managing technical teams post-acquisition, and integrating technologies post-merger. In this follow-up blog post, we’ll outline key takeaways and provide additional insights from questions cut for time to help you master these critical processes.
I. Key Takeaways:
What is Technology Due Diligence and Why Conduct It?
The market has defined it as “in-depth analysis of the target’s current tech capabilities. However, technology due diligence is more than that. You can think about technology due diligence as consisting of three main parts:
- Understanding the future state that is defined by the investment thesis
- Comparing that to the target’s company’s current capabilities
- Gap analysis between the present and required state
The one thing investors try to avoid is high additional investment to fulfill the business plan. Answering the questions below using tech due diligence helps investors decide whether the investment is reasonable.
- Is the target able to fulfill the investment thesis? Is the target suitable for the investor’s business case?
- How do we make it work?
- What do I need to change or add, and what risks do I need to mitigate to ensure the target can fulfill the thesis?
- How much will it cost in terms of money and time?
It’s Not Just For Large, High-Tech Companies
The process should be mandatory for all investors, especially if technology is the target’s core business. If buying into a client base, you may only care about the data integration piece. If you are looking to fully integrate target to platform, you will strongly benefit from detailed sections of technology due diligence. These will help you to outline Value Creation and PMI activities.
Deal size and industry aside, what matters most is the business plan and investment thesis. If technology plays an important role in the value creation, then tech due diligence should be mandatory.
Technology Due Diligence Should Be Investment-Thesis Driven
The process’s goals are to understand if the target is suitable for an investor’s business case and to get a 360-degree view of the development and operations practices. Next to pure technical suspects like product architecture, a well-executed technology due diligence should include product management, organization and processes as the core areas. Operational debt is as serious as tech debt.
Technology Due Diligence Takes About Three Weeks
From kick-off to report readout, the technology due diligence process usually takes about three weeks. Obviously this depends on the target’s availability, as well as the breadth and depth of the scope. To shrink the time footprint, Mart suggests including technology experts in the discussion to review or define the deal thesis as early as possible.
Technology Due Diligence And Post-Merger Integration are Linked
Well-executed technology due diligence should give investors the outline and high-level plan for running the PMI. This includes the risks one should mitigate, how to technically integrate solutions, and what (if any) services should be retired.
Secondly, a professionally done technology due diligence includes details about the target’s processes, key people in the team, organizational structure and other information crucial to planning PMI activities. It is important to consider the to-be team structure, ways of working, and communication. All this comes together as a significant input into the PMI and/or value creation plan.
How to Keep The Technology Integration Plan On Schedule and On Budget
- Have one person responsible for running the PMI plan.
- Be agile and avoid so-called analysis paralysis. The goal should be to deliver value as soon as possible – incremental changes over big-bang projects.
- Use software tools for program management to reduce overhead — e.g., time spent on reporting — streamline processes, lessen mistakes from manual, error-prone tasks, and facilitate transparency and ease of reporting.
- Ensure an all-encompassing approach with template playbooks.
II. Additional Q&A with Mart Lumeste:
Q: How Do You Uncover and Evaluate the Extent of Technical Debt?
Technical debt is a concept that represents the implied cost of additional work that arises when code or architecture design shortcuts are taken in the short term, leading to potentially more significant and costly issues in the future. Organizations usually incur technical debt when the cost of adding additional features increases (e.g., time and money) and the ability to sustain product quality decreases. To understand the current state of the company’s technical debt, we at Intium usually focus on four main pillars – that will cohesively tell the organization’s tech debt story:
- Product roadmap
- Tech stack
- Architecture design
- Product development operational metrics
Product Roadmap
When reviewing roadmap items, we look at how much time is spent on reducing tech debt and how that correlates to time spent on developing new features. It’s expected that all companies have a certain amount of tech debt. Still, we expect the percentage of work items targeting tech debt to fall within acceptable industry standards. The levels vary depending on the company’s maturity (e.g., startup vs. mature company) and stage (e.g., transforming company vs. a company in maintenance mode). Overall, we expect earlier-stage companies to have a single-digit percentage and mature and transforming companies to have up to 30% of all work items and roadmap initiatives tackling tech debt.
Tech Stack
We also look at the tech stack, as technologies, frameworks and versions of programming languages also indicate entropy in code. Legacy technologies are hard to maintain and evolve, requiring specific knowledge or talent that is hard to find on the market. For example, Delphi or COBOL programming languages indicate a legacy tech stack with dwindling talent pool and limited language support.
Architecture Design
Business use cases evolve and change, and architecture should follow suit. Limited usage of 3rd party libraries and tools and poor overall design due to sparse investment into tech ownership yields a spotty and inconsistent system architecture, resulting in increased costs required to deliver new features and sustain or improve product quality.
Product Development Operational Metrics
Product development metrics will tell how frequently the organization can release value to the market and how that impacts product quality. Increasing delays and delivery estimates in product engineering and quality assurance indicate accumulating tech debt.
To summarize, uncovering and evaluating tech debt requires a coherent review of the company’s tech capabilities, metrics and product roadmap. Reducing the debt requires a plan and management buy-in. Understanding what should be done technically to improve the situation is a must to rebalance the product roadmap to accommodate increased work items targeting tech debt, allowing you to keep tech debt under control to sustain delivery speed and improve quality.
Q: Is There a Ratio or Formula for a High-Level Estimate of IT Applications Required to Run a Business if Poor Information is Provided by a Target?
The number of IT applications a business uses depends on several factors, most prominently:
- Company size
- Industry
- Investment thesis
Company Size
Larger companies with several business units and functional areas need more systems to support their day-to-day activities. This is because IT applications help automate tasks. The systems could include a CRM for sales to capture all client contacts, HRM systems help human resources to manage vacations and salaries, and accounting systems automate bulk of finance-related tasks.
Industry
Different industries have varying technology requirements. For example, a manufacturing company may need just one specialized production and supply chain management application. At the same time, a financial institution may require a number of applications to manage compliance, lending, risks, core banking, payments etc.
Investment Thesis
Further, it’s essential to understand whether or not the company’s core business is technology. Software organizations (e.g., SaaS businesses) require additional customer-facing applications to offer services. Thus, the products’ success is strongly tied to business results. This is why we at Intium have dedicated tech due diligence offerings for both tech and non-tech companies. The latter focus on internal business process automation and integration. The former lean towards end-client offerings, ensuring overall business success.
There is no one-size-fits-all metric or benchmark to evaluate if the company uses sufficient IT applications, as it depends on several factors. Poor information about IT systems usage provided by the target can indicate spotty IT adoption in the company. Of course, this is not expected from a modern business. However, automating internal processes and pivoting business strategy towards being a tech or tech-enabled company can be a low-hanging fruit, yielding improvements in the top and bottom lines.
Conclusion
Technology due diligence and integrations are complex processes that require careful planning and execution. Our Live Q&A with Mart Lumeste last month provided valuable tips and tricks to help you navigate these challenges successfully. By implementing these strategies and continuously learning from your experiences, you’ll be well on your way to mastering technology due diligence and integrations in the ever-evolving world of business technology.
