A CFO's job is to form a company's investment strategy, and one critical area of investment in any organization is technology. Now, a CFO can rely on its organization's CIO for the understanding of the technical side of their business, but it is also necessary that they have a full understanding of their company's technical debt in order to guide their organization to financial success.
Where can a CFO spot technical debt?
The first and most obvious place where a CFO can find technical debt is in the organization's software development process. This debt is the work needed to be completed before a project can be considered finished. If this debt is not repaid than it will keep building interest and make enacting changes in the future extremely difficult.
A great example of technical debt in the software development process is when a company pushes for a product to get to market as quickly as possible in order to increase market share of stop a competitor's gains on their business. In this scenario it makes sense to release a product that is at minimum viability in order to reach the goals outlined above.
The second most expensive type of technical debt is that which is found in software, hardware, support, and development costs that are used to support systems which are at the end of their lifecycle. These are systems that should have been put out of rotation long ago and written off as sunk costs. As CFO you can spot these systems out by the time spent on keeping high cost projects barely running or by how far behind they are falling behind the projected value they were meant to bring in their business cases. The shortcomings of a project are often due to high cost or long project queues that are needed in order to make the project successful.
Next, as CFO you need to be able to distinguish between good and bad technical debt.
Good technical debt, just like financial debt, is debt that increases net worth, generates value, or helps you manage finances more effectively. So if you are going to market with a minimum viable product in order to gain market share, but you know that your product roadmap will pay off this debt through the product's life cycle while generating revenue, then you are introducing good technical debt. The key to introducing good technical debt is that you have a plan to pay it back and to maintain your financial and technical position (in other words you are releasing a product with debt but it still maintains certain standards in order to not harm your organization).
Bad technical debt is debt that does not present any value, whether it be increased revenue, market share or the ability to get to market faster. Bad technical debt can also manifest itself in a project or system that has extremely high support costs that take over your technology budget and resources.
There is high probability that you have a multi million dollar project in the works right now, where the sole purpose is to move an on premise system that is nearing end-of-life to a currently supported version. Due to high levels of customization and integration that have been used in this system, this will be a multi-year project. Once you complete it, the system you've replaced the old one with will only be one or two years from end-of-life itself. So you will have put all this effort in with no obvious value for your business or customers. This is bad technical debt.
As a CFO understanding technical debt not only will help you to manage budgets, but it will also enable you to work better with your CEO and CIO towards your organization's success.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.