Subscribe
Typically, it’s businesspeople and lawyers who coordinate due diligence in an M&A transaction. A few might be former developers; often, many have gained some understanding of how software is built through osmosis and have at least an intuitive sense of technical risk. The better that attorneys, corporate development folks, and financial investors are at understanding how software is developed and where it can go off the rails, the better equipped they are to ensure their companies and clients have eyes wide open to software risks. And that allows them to better plan how to manage post close.
Stick to the process
An organization’s software development team and process determines the attributes of its code. A well-designed process will lead to better software. The particulars of the process will drive specific attributes in the output. If developers are well-trained on application security and static application security testing (SAST) tools are routine, it’s likely that more-secure software will result.
A well-designed process is table stakes, but what’s on paper may not be what’s in practice. Only a well-governed and well-disciplined organization can stick to best practices. Too often, business pressures can drive development awry. Of course, a full security code review makes sense, but when the project is behind and the deadline for the release is looming, will the team stick to the plan? Often they don’t, and the shortcuts they take accumulate as “technical debt.”
Evaluate, evaluate
Evaluating an organization and development process is fundamental to post-close planning. This provides a forward look at how productive the development team will be at executing the roadmap. It’s also critical, particularly in acquisitions where much of the value lies in the software, to assess what’s in the code. Defined processes may be newly implemented or not always followed. The code is where you’ll find the technical debt, the pile of security, quality, and licensing issues the team will need to clean up in addition to executing the roadmap. Just as financial debt can get out of control, so can technical debt, and “paying it off” needs to be worked into the business case.
Most acquirers do some level of organization and process due diligence themselves; that makes sense and is important. Thorough due diligence on the code complements the process evaluation to complete the picture and inform the deal and post-close integration planning. If you want to hear it from the horse’s mouth, Declan Burns, who’s seen everything that can go wrong with a software project, explains all this in webinar, “Software Construction and Business Risk: A Crash Course for Investors and Lawyers.” And I elaborate further in a pair of white papers titled “Understanding Software Development, Technical Debt, and Risk” and “Mitigating Risk in Mergers and Acquisitions.” I also recommend our software due diligence checklist; it’s the most comprehensive that we’ve seen.
Continue Reading
