A CFO's Guide to Technical Debt

by

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.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|