The Agile Executive

Making Agile Work

Posts Tagged ‘M&A

How to Use Technical Debt Data in the M&A Process

leave a comment »

http://www.flickr.com/photos/brajeshwar/266749872/

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.

http://www.flickr.com/photos/tantek/254940135/

____________________________________________________________________________________________________

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.

____________________________________________________________________________________________________

Advertisements

Written by israelgat

October 20, 2010 at 5:37 am

Cutter’s Technical Debt Assessment and Valuation Service

with 3 comments

 

 

Source: Cutter Technical Debt and Valuation Service

The Cutter Consortium has announced the availability of the Technical Debt Assessment and Valuation Service. The service combines static code analytics with dynamic program analytics to give the client “x-rays” of the software being examined at any desired granularity – from the whole project portfolio to a single instruction. It breaks down technical debt into the areas of coverage, complexity, duplication, violations and comments. Clients get an aggregate dollar figure for “paying back” debt that they can then plug into their financial models to objectively analyze their critical software assets. Based on these metrics, they can make the best decisions about their ongoing strategy for the software development effort under scrutiny.

This new service is an important addition to the enlightened software governance framework that Jim Highsmith, Michael Mah and I have been thinking about and contributing to for sometime now (see Beyond Scope, Schedule and Cost: Measuring Agile Performance and Quantifying the Start Afresh Option). The heart of both the technical debt service and the enlightened governance framework is captured by the following words from the press release:

Executives in charge of software governance have long dealt with two kinds of dollar figures: One, the cost of producing and maintaining the software; and two, the value of the software, which is usually expressed in terms of the net present value associated with the expected value stream the product will generate. Now we can deal with technical debt in the same quantitative manner, regardless of the software methods a company uses.

When expressed in terms of dollars, technical debt ties neatly into value vis-à-vis cost considerations. For a “well behaved” software project, three factors — value, cost, and technical debt — have to satisfy the equation Value >> Cost > Technical Debt. Monitoring the balance between value, cost, and technical debt on an ongoing basis is an effective way for organizations to stay on top of their real progress, and for stakeholders and investors to ensure their investment is sound.

By boiling down technical debt to dollars and tying it to cost and value, the service enables a metrics-driven governance framework for the use of five major constituencies, as follows:

Technical debt assessments and valuation can specifically help CIOs ensure alignment of software development with IT Operations; give CTOs early warning signs of impending project trouble; assure those involved in due diligence for M&A activity that the code being acquired will adapt to meet future needs; enables CEOs to effectively govern the software development process; and, it provides critical information as to whether software under consideration constitutes an asset or a liability for venture capitalists who need to make informed investment decisions.

It should finally be pointed out that the technical debt assessment service and the governance framework it enables are applicable to any software method. They can be used to:

  • Govern a heterogeneous environment in which multiple software methods are used
  • Make apples-to-apples comparisons between disparate software projects
  • Assess project performance vis-a-vis industry norms

Forthcoming Cutter Executive Reports, Executive Updates and Email Advisors on the technical debt service are restricted to Cutter clients. As appropriate, I will publish the latest and greatest news on the subject in the Cutter Blog (which is an open forum I highly recommend).

Acknowledgements: I would like to wholeheartedly thank the following colleagues for inspiring, enlightening and supporting me during the preparation of the service:

  • Karen Coburn
  • Jennifer Flaxman
  • Jonathon Golden
  • John Heintz
  • Jim Highsmith
  • Ken Collier
  • Kim Leonard
  • Kara Letourneau
  • Michal Mah
  • Anne Mullaney
  • Chris Sterling
  • Cindy Swain
  • Sarah Wiesbrock

Should You Invest in This Software?!

with 2 comments

Martin Fowler - Technical debt quadrant by Kalle Hoppe.

Source: martinfowler.com/bliki/TechnicalDebtQuadrant.html

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.

Written by israelgat

March 4, 2010 at 5:40 am