In previous blogs, I have discussed due diligence questions for non-technical people and and why storytelling is essential in due diligence I then realised I hadn’t covered the basics – what are the common mistakes? And how do you address them?
1. No formal IT Due Diligence
It is now well known, that “Every business is a technology business” but often companies do not invest in a formal tech DD process. I understand some of the common reasons why formal DD is not engaged:
- The technology isn’t deemed to be important in the deal. Let’s use an example of a tiny deal, and the services business only uses basic back-office software. In this example, it would seem a waste of money to ask someone to assess the technology. But then we dig deeper and realise that the <50 employee business is serving corporate clients in the Financial Services sector. Then, we uncover the team are copying data to their home computers to make it easier to manipulate documents. The technology platform isn’t the issue here – cyber-security is an issue.
- It’s obvious from the P&L that the technology is “sound”. I feel that the investor/buyer is already heavily emotionally bought-In to the deal when they say something like this. And yes, that does make sense from a high-level but what has the business (unintentionally) been hiding? One example was a SAAS business that looks fabulous from the web-page and product perspective, but the on-boarding was manual and the business needed to hire temps in peak periods, plus their accounting systems was fraught with issues and reconciliation took weeks (and a dedicated team). Yes, the SAAS product was sound, but from a People-Process-Technology perspective, there was good opportunity to mature and scale the business.
- “We will do an internal Tech DD”. Yes, and I would do the same if I had the resource available. But two issues – will a team fully disclose to a buy-side technology leader and is their internal agenda the same as the business growth agenda? One example is of a 200 employee acquisition – the DD had been performed internally, from the data room. We were onsite post-deal to help with the integration. An assumption was made regarding the number of computers in the deal, e.g. approx. 50 servers and 200 PCs/Macs. There were over 3,000 servers and 400 personal computers and a lot more complex than anticipated. Expanding a 3-month integration project to 9 months.
How do we fix this, so that people are more willing to undertake more formal DD exercises? Make IT Due Diligence affordable and present a good narrative that’s easy to understand but non-technical people. Or maybe there are other “pain points” about IT DD that prevent you from utilising a 3rd party? I’d love to know.
2. Not Talking to The Business
During an assessment, it is easy to be absorbed by the tech team alone. We have a very short amount of time and access to try and understand something that has taken years to build. Plus, it’s a given that the technology team and the solutions they build and maintain does not operate in isolation. But how many DD reports provide input from the business users and key departments such as sales and marketing? The DD practitioner needs to be able to step out of their comfort areas of discussion and interview the business users.
- A common observation is that SAAS platforms are beautifully built and well-resourced but often at the cost of the corporate IT estate. I agree that it’s important to invest in the revenue-generating areas of the business, and understand that resources are limited. But when technology staff have given up on their computer equipment and have reverted to pen and paper, something is seriously wrong.
- Another scenario is at a top-tier University we worked at, where the student technology facilities were top-grade, but the professor’s kit and network were ancient.
- Or a business where the tech team has updated the internal software products, but the business users felt it would impact their welfare and income.
How do we address this? Consider a “business first” approach in the DD interviews. And look for links between the tech team and Sales and Marketing.
3. Treating IT DD as an Audit
I groan when a tech team say or act as if “the auditors have arrived”. Often the assessment is the first one they’ve experienced. We are trying to do so much more, to learn their “story” and what they want to achieve.
Yes, it’s important to understand the history and current state of play from a technology team. Of course, the DD practitioner will assess the technology stack and compare it against the business plan – to ensure the technology is fit for purpose. IT DD has to be more than a box-ticking exercise; otherwise it’s a waste of everyone’s time.
No specific experiences here personally, but I have spoken to customers who have had this issue in the past. This PDF on customer pain says it all.
{{cta(‘4d597540-1034-425b-9dfa-3df2d58038c0′,’justifycenter’)}}
The easiest way to fix this? The DD practitioner needs to treat the environment as if it was their own to transform. But they must also involve others to eradicate pure personal opinion. The report must present the business plan, the next 100+ days and look to turn perceived “faults” into opportunities.
4. Lack of Diversity (of Thought)
Businesses are becoming more diverse culturally. In turn, technology teams are also becoming more diverse.
For example, in the Fintech industry is the additional focus on the people who build the technology itself. The leading Fintech businesses are looking for product innovation through the diversity of people and in particular, diversity of thought.
While industry as a whole is discussing diversity in technology as a broad subject, Fintech is actively working on this challenge by raising the subject, setting up new dedicated communities and meet-ups such as https://www.diversitech-hub.com/ for technology leaders to openly discuss how to challenge their unconscious bias and change hiring processes.
These new communities are having an impact, and attracting companies like Monzo and Starling Bank to share how they are benefitting from a diverse Fintech technology team. The result is better customer experience and service and better products, as firms benefit from “creative conflict” when the mixture of minds and approaches are bought together.
How do you address this? You need a diverse team when assessing DD. No longer can you rely on a middle-aged IT man in a suit to assess the complexity of tech. You need to have people who think differently and have different roles to see the impact of technology from different perspectives. When we are asked about our USPs in the IT DD market, one of the things I do is refer to this slide in our pitch deck:
Having spoken to many investors/investment directors, their main pain point with IT Due Diligence is the cost of getting it wrong. Spend more time assessing the complexity of the finances.
More information on what IT Budget information needs to be submitted can be found in this article, What goes in an IT budget for Tech DD?
{{cta(’23b74a59-42a2-4a7c-8ded-6111a29634b7′)}}
