Most companies have a fixed human and financial capacity for project work, especially if for internal work. Unless they hold a monopoly in their market, their ability to increase project portfolio funding is constrained by multiple factors including market growth opportunities, price sensitivity but to a great degree by their operating expenses. Assuming a fixed budget, the more the organization spends on keeping the lights running, the less is available to deliver change. While there are multiple causes of high operating expenses relative to one’s competitors or industry benchmarks, one of the most challenging to control is technical debt.
Technical debt is normally defined as the long term costs resulting from short-sighted decision making. While projects are not the only source of technical debt, they can be one of the worst contributors to it.
Finance departments often budget for operational costs or resource utilization using previous results as a baseline – this ignores the puts and gets from those projects which implemented changes over the previous year. When technical debt avoidance and reduction is not an area of focus, each year’s projects will increase the operational burden, further reducing how much change can be implemented. In short, the more we deliver inefficiently, the less we will be able to deliver in the long run.
Two common causes of technical debt are sticking with a given technology beyond the point where the benefits of doing so exceed operational costs and investing insufficient effort in quality practices.
Both of these causes can often be traced to unrealistic deadlines or the obsession with reducing short term costs. The former causes teams to cut corners in quality practices or to avoid innovative solutions in favor of tried, true and inefficient approaches whereas the latter can reduce appetite for investing in learning newer, efficient technologies or automating highly repetitive manual tasks.
One example is the resistance of a project sponsor or funding bodies to incur the costs or schedule impacts of developing automated test suites for an existing application as part of the scope of an upgrade project. While that one time investment might help the ongoing support and evolution of that product by reducing or eliminating manual regression testing, if the project team feels under pressure to hit an aggressive deadline or has tight cost constraints they will continue to perform manual testing and won’t do their part towards paying down technical debt. Even worse is when a new solution gets developed without operational efficiency being a priority – in that case, the level of overall technical debt will just continue to increase.
We need to apply the same foresight to paying down technical debt as etiquette recommends for ball marks on golf greens. Not only should we fix the marks we’ve created, we should also fix one or two others.
Easy in theory, difficult in practice 