
The Due Diligence Survival Guide - wspruijt
http://www.jacquesmattheij.com/Due+Diligence+survival+guide
======
cek
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.

~~~
babar
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?

------
ajju
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.

~~~
swombat
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.

------
chopsueyar
What is the cost, from the potential buyer's perspective, of the 'due-
diligence' process?

Also, how are you paid? Is it a flat-fee upfront? A percentage of the possible
'acquisition' amount?

~~~
chollida1
Well it depends on who does the due diligence.

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.

