Posts Tagged ‘M&A’
As a starting point, please read Implication of Technical Debt Uncertainty for Software Licensing Negotiations. Everything stated there holds for negotiating M&A deals. In particular:
- You (as the buyer) should insist on conducting a Technical Debt Assessment as part of the due diligence process.
- You should be able to deduct the monetized technical debt figure from the price of the acquisition.
- You should be able to quantify the execution risk (as far as software quality is concerned).
An important corollary holds with respect to acquiring a company who is in the business of doing maintenance on an open source project, helping customers deploy it and training them in its use. You can totally eliminate uncertainty about the quality of the open source project without needing to negotiate permission to conduct technical debt assessment. Actually, you will be advised to conduct the assessment of the software prior to approaching the target company. By so doing, you start negotiations from a position of strength, quite possibly having at your disposal (technical debt) data that the company you consider acquiring does not possess.
Action item: Supplement the traditional due diligence process with a technical debt assessment. Use the monetized technical debt figure to assess execution risk and drive the acquisition price down.
Negotiating a major M&A deal? Let me know if you would like assistance in conducting a technical debt assessment and bringing up technical debt issues with the target company. I will help you with negotiating the acquisition price down. Click Services for details and contact information.
Consider the following scenario: You are a venture capitalist. One of your portfolio companies has been working for a few years on a promising software application. Various surprises with respect to schedule and functionality have been sprung on you along the way. The company now asks for one last shot-in-the-arm in order to get the product out the door, market and sell it. Should you open your wallet one more time to fund this alleged last push?
It is a familiar scenario not only for venture capitalists, but for CEOs, CFOs, general managers and M&A executives. A renowned CEO once told me the following when I pushed my luck with respect to project funding:
Israel, I have a warehouse of software products that never generated a dime for me.
Believe me, this CEO was neither amused nor philosophical…
Code analysis techniques have progressed to the point that the answer to the software investment question for object-oriented code can to a certain extent be determined through quantifying technical debt. For example, assume the following circumstances:
- A company expects to ship 500K lines of code in 6 months.
- The company asks for additional $2M to complete development and make a significant resound in the market.
To assess the investment decision, apply the code analysis techniques described in Using Credit Limits to Constrain Development on Margin to quantify the technical debt. Assuming a debt of $2 per line of code has been identified, the overall technical debt amounts to $1M (2X500K).
The investment decision then is not an incremental $2M decision. It is actually a $3M ($2M+1M) investment decision when the technical debt is taken into account. The technical debt might not need to be paid overnight, but it will have to be paid back over a period of time. The team might not hire additional resources to reduce/eliminate the technical debt, but the team resources dedicated to reducing technical debt will not be available to carry out other assignments. Hence, the opportunity cost ($1M) is real, relevant and should be taken into account.
If you are hesitant to continue investing in this software/team, you stare at a tricky question:
- What will it take to start afresh?
If you decide to make the $3M investment, two operational questions pose themselves:
- How should work on reducing/eliminating technical debt be interleaved with other pressing work such as new functions and features?
- Given a $1M debt on 500K lines of code, can the company indeed ship as expected in 6 months?
We will address these three questions in forthcoming posts in The Agile Executive.