In my time at Microsoft I drove technical due diligence for potential acquisitions many times. This is a solid article but I'd like to add a few points from my experience.
I have to admit that I view my track-record in engaging in M&A activity during my career at Microsoft as almost perfect. Out of the dozen M&As I was involved in only ONE actually closed with an acquisition; the rest Microsoft walked away from. I view this as successful because I was never the biz-dev guy, always the technical guy. I'm quite sure my biz-dev colleagues felt the opposite about our "success rate" because, at large companies biz-dev people involved in "corp dev" or "M&A" activities are typically measured, at least in part, on how many deals they complete a deals a year. When I was doing this I never actually had any written commitments/goals for M&A work. It was just something I got roped into/volunteered to do. And I always took the principled approach.
As a guy driving due diligence I viewed it as my job to find all the skeletons in the closet ahead of time that would make the deal impossible for Microsoft to swallow. I'm not saying that all the deals MS didn't do that I was involved in were due to my work; they weren't. But a few were. I found some serious skeletons.
The skeletons I found had to do with three things, which were also the things I explicitly tried to uncover:
1) Horrific code quality.
2) Weak people.
3) Improperly licensed 3rd party code.
You can imagine how I uncovered details on each of these. In some cases #2 was the hardest to accomplish because interviewing employees of an acquisition target is actually very hard. The target often does not want employees to know it is a target early on in the process. One reason is what would happen if the deal did not go through: The employees would know (and probably leak) that a major Co. had attempted the acquisition and turned away. This could be devastating to the target company. When we did interview target company engineers we often found shockingly bad engineers.
Reviewing the code (and often just as importantly the engineering system) was always the most revealing (and damning). Engineering debt creeps up on a lot of small companies and, in cases where the deal is to "buy code", is a deal breaker.
The thing that we had the biggest allergic reaction, however, was #3 above: Improperly licensed 3rd party code.
Many of the acquisitions I was involved in were associated with Windows in some way. The risk to having Windows being contaminated by either commercial code that was not clearly licensed or by open source code with a license like GPLv2 was huge. And we found it all the time. Initially it was shocking to me how these small companies were so cavalier about plagiarizing code with no thought about the consequences; especially given these companies clearly had long term strategies of being acquired at some point!
So add to this great article the following pieces of advice:
1) Set your hiring bar high and be hard-core about managing poor performers. Remember the maxim that As hire As, Bs hire Cs, and Cs hire Ds.
2) Invest in reducing your engineering debt, particularly in the areas of your code where a potential acquirer is going to find the most value.
3) If you use 3rd party code, or open source, take the time to ensure you are using it in a way that is compatible with potential acquiring companies. DO NOT BE SLOPPY.
Can you give some more detail about what your process was for determining code quality? Just getting people to get a checkout and read through it? Running static analysis tools? Examining commit histories?
Since both sides bear their costs until the final contracts are signed, how do you prevent an insincere large competitor from offering a term sheet, doing due diligence to learn everything they can about the business, and then backing off based on a contrived revelation?
If NDA you mentioned is the only thing preventing them from doing this, it seems a bit iffy.
I'm not an expert, but I believe that the term sheet for M&A normally includes breakage clauses, so that the acquirer has to pay the target a breakage fee if they pull out of the deal without a really good and previously agreed reason.
If you don't have such a document in place, you should probably not agree to a DD. DD happens after everything is negotiated, as a final formality, not as a precursor to getting everything agreed.
Sometimes it can be people from the acquiring company, this can be relatively cheap.
Sometimes it can be a 3rd party brought in, usually I-Bankers. This can be expensive, up to 5% of the purchase price.
Another fee that can be expensive is the break fee. This is a fee paid to the acquired company if the deal falls through. This is supposed to prevent the acquirer from getting a thorough look at their competitors books and then walking away. Typically a break up fee can be 10% of the acquiring price, though in the Google-Motorola acquisition I heard that it's 20% of the purchase price.
Not sure if I understand you correctly, but the article states:
It is generally understood that both parties carry their own costs until the final contracts are signed.
Which is how it's normally done, both sides are interested in a sale/investment/merge so I see no reason why you should expect to get paid for the due diligence process.
The buyer has to analyse all data on which the deal is based, until he is satisfied, which in many cases means hiring experts for that job.
The cost from a buyers perspective of the due-diligence process is not the big issue, the big issue is not doing due-diligence and ending up with a lemon or worse.
So for a buyer due diligence is only a cost if the deal eventually goes through unaltered, if the deal does not go through then it is probably more like an insurance premium, you pay it in the hopes that you are wasting your money but just in case you don't you'll be really happy you paid.
The statistics are (based on my personal observation, not exactly a large enough sample to extrapolate from) that out of every 10 deals there will be one or two with 'surprises' and those make up for all the money spent on the due diligences of the rest with plenty of spare change left over. The large majority of potential deals never reach that stage but are cancelled much earlier in the process for some reason or other, by the time an acquirer is prepared to put the money on the table for a full dd they are very serious about the deal.
As for 'how are you paid', I charge an hourly rate, it's by far the simplest way to make sure that I'm as independent and even keeled as possible.
Flat-fees can cause sloppy work (especially if there is more work than anticipated) or over-charging and a percentage of the possible amount (or even a success fee) would either be a bad match (because under $100K investment due diligence is usually very much abbreviated and on the high end the work is usually not that much more than in the middle).
Especially success fees are bad because this causes the due diligence to shift from being somewhat skeptical about claims to ignoring aspects of the target just to let a deal go through.
I find that regular 'hourly rates' are the best match for this kind of work, it means that if a due diligence unexpectedly costs more time (which you have relatively little control over as the person doing dd, after all the supply of information and transparency are not under your control but have a huge impact on the amount of time required) or if there is a large amount of material to absorb or extra areas of interest as dictated by the acquirer that there is no lack of motivation to do the work.
Of course, there will be plenty of parties that disagree with this, I'm aware of people and companies that do 'fixed fee' (but at a price point significantly higher than what I charge), and also of people operating on a 'success fee' basis but I'm just not comfortable with either of those.
Fee and work done should be in some sort of relationship to each other, 'value created' is hard to establish since that is mostly dependent on the deals that don't go through!
Personally, I'm most happy if I don't create 'value' but if everything the target claimed was found to be the truth and there is little or no friction.
As for the absolute amounts, a full legal, financial and technical due diligence can cost anywhere from 20K 'credits' to several 100K depending on the size of the target and the various requirements as made by the acquirer, especially financial can cost a very large amount of money in the case of a company with a long commercial history.
That's also why 'acquirer pays for dd' is a good principle.
One variation on this that I've seen is that if the deal falls through that the acquirer will pay for dd and if the deal gets executed that the dd costs will be paid from the investment.
I hope that answers your questions in sufficient detail.
I have to admit that I view my track-record in engaging in M&A activity during my career at Microsoft as almost perfect. Out of the dozen M&As I was involved in only ONE actually closed with an acquisition; the rest Microsoft walked away from. I view this as successful because I was never the biz-dev guy, always the technical guy. I'm quite sure my biz-dev colleagues felt the opposite about our "success rate" because, at large companies biz-dev people involved in "corp dev" or "M&A" activities are typically measured, at least in part, on how many deals they complete a deals a year. When I was doing this I never actually had any written commitments/goals for M&A work. It was just something I got roped into/volunteered to do. And I always took the principled approach.
As a guy driving due diligence I viewed it as my job to find all the skeletons in the closet ahead of time that would make the deal impossible for Microsoft to swallow. I'm not saying that all the deals MS didn't do that I was involved in were due to my work; they weren't. But a few were. I found some serious skeletons.
The skeletons I found had to do with three things, which were also the things I explicitly tried to uncover:
1) Horrific code quality.
2) Weak people.
3) Improperly licensed 3rd party code.
You can imagine how I uncovered details on each of these. In some cases #2 was the hardest to accomplish because interviewing employees of an acquisition target is actually very hard. The target often does not want employees to know it is a target early on in the process. One reason is what would happen if the deal did not go through: The employees would know (and probably leak) that a major Co. had attempted the acquisition and turned away. This could be devastating to the target company. When we did interview target company engineers we often found shockingly bad engineers.
Reviewing the code (and often just as importantly the engineering system) was always the most revealing (and damning). Engineering debt creeps up on a lot of small companies and, in cases where the deal is to "buy code", is a deal breaker.
The thing that we had the biggest allergic reaction, however, was #3 above: Improperly licensed 3rd party code.
Many of the acquisitions I was involved in were associated with Windows in some way. The risk to having Windows being contaminated by either commercial code that was not clearly licensed or by open source code with a license like GPLv2 was huge. And we found it all the time. Initially it was shocking to me how these small companies were so cavalier about plagiarizing code with no thought about the consequences; especially given these companies clearly had long term strategies of being acquired at some point!
So add to this great article the following pieces of advice:
1) Set your hiring bar high and be hard-core about managing poor performers. Remember the maxim that As hire As, Bs hire Cs, and Cs hire Ds.
2) Invest in reducing your engineering debt, particularly in the areas of your code where a potential acquirer is going to find the most value.
3) If you use 3rd party code, or open source, take the time to ensure you are using it in a way that is compatible with potential acquiring companies. DO NOT BE SLOPPY.