Managing the Monster: Taming Technical Debt for a Better Bottom Line
In its most basic form, technical debt is any cost associated with technology that affects profit and loss. This could include the cost of hardware and software upgrades, maintenance and support, and staffing for various technology initiatives. For organizations that rely heavily on technology to drive their business, these costs can quickly add up and impact their bottom line.
However, technical debt can also be associated with a large footprint of best-of-breed applications that require diverse skillsets. This can make it difficult to staff for, as organizations struggle to find and retain talent with the right mix of technical expertise and business acumen. This is particularly true in industries where technology is rapidly changing and evolving, such as the software development and IT industries.
Additionally, outsourcing support to multiple vendors can create situations where organizations are working with partners who have partners, and many "middlemen." This can create a complex and fragmented technology landscape that is difficult to manage and maintain, and can lead to delays, inefficiencies, and additional costs.
Finally, technical debt can also extend to software development, where organizations have multiple tech stacks to support, such as Java, C#, Python, and Angular. This can create collaborative challenges, as teams must work together across different platforms and languages, and can also impact talent retention, as developers may choose to leave an organization if they feel their skills are not being fully utilized or are not in demand.
Technical debt is a complex and multifaceted concept that encompasses many different aspects of technology management and development. Whether it is associated with costs, staffing, outsourcing, or software development, the key to effectively managing technical debt is to understand its causes and to implement strategies that prioritize technical excellence and maintainability while still allowing for short-term gains and flexibility.
Debt Drivers: The Factors Behind the Spiral of Technical Debt
Technical debt can often spiral out of control when organizations are not proactive in managing and mitigating its causes. Some of the most common causes of out-of-control technical debt include:
Influential Board Members
Technical debt can sometimes be driven by board members who are incentivized to use their influence to implement a specific technology or vendor, regardless of the IT staff's area of expertise. This can lead to a situation where the technology is not well understood or supported by the IT team, and results in additional costs and challenges in the long term.
Inexperienced or Incompetent IT Leadership
Technical debt can also be caused by inexperienced or incompetent IT leadership who make decisions on technology without due diligence on what it takes to manage and maintain such technology. This can result in technology that is poorly suited to the organization's needs and leads to inefficiencies and additional costs down the line.
Poor Organizational Structure
Technical debt can also be a result of poor organizational structure, where individual departments are empowered to make their own decisions, regardless of how well they fit into the IT ecosystem. This can lead to a fragmented and disjointed technology landscape that is difficult to manage and maintain and can increase the risk of technical debt.
Lack of Investment in Technology
Technical debt can also be caused by a lack of investment in technology, both in terms of resources and time. When organizations are not proactive in investing in technology upgrades and maintenance, they can fall behind their competitors and struggle to keep pace with changing market demands.
Underestimating the Cost of Technical Debt
Technical debt can also be caused by organizations that underestimate the cost of technical debt. This can result in organizations that prioritize short-term gains over long-term costs and end up paying a heavy price in the form of increased costs and reduced efficiency in the future.
As you can see, managing technical debt is a critical challenge for organizations of all sizes, and requires a proactive approach that prioritizes technical excellence, maintainability, and organizational alignment. By understanding the causes of technical debt and implementing strategies to manage and mitigate its impact, organizations can ensure that they are well-positioned for success in the long term.
The Oracle Outcome: The Costly Consequence of a Board Member's Bias
Charlie Ledbetter was a board member at a large corporation that had been using Microsoft Dynamics as their ERP system for the past 8 years. Despite the years of experience and skillset built up around Dynamics, Charlie had his sights set on a different solution. As a former executive at Oracle, Charlie had a vested interest in pushing the organization to choose the Oracle E-Business Suite as their new ERP system.
Using his position of influence, Charlie convinced the rest of the board that Oracle was the way to go. Despite protests from the IT team, who argued that upgrading to the latest version of Microsoft Dynamics would be much cheaper and more efficient, Charlie was able to use his perceived position of power to sway the decision in favor of Oracle.
The implementation of Oracle E-Business Suite ended up being a total disaster. The cost of implementation was estimated at 50 million, a far cry from the 6 million that would have been required to upgrade Microsoft Dynamics. The IT team struggled to manage the new system, which was completely different from the Dynamics system they were used to. As a result, many key employees left the organization, taking their skills and experience with them.
The organization was left with a costly, inefficient system that was difficult to manage. The loss of intellectual capital was a major blow, and it took the company years to recover from the damage done by Charlie's influence. The decision to implement Oracle was one that the organization would come to regret, as the technical debt caused by the change would haunt them for years to come.
When Inexperience Leads to Technical Debt: Tales of The Incompetent Leader
Kevin Turner was a brown-nosing manager with no previous experience in software development, but for reasons that still remain a mystery he had been gifted with a leadership role. When the organization needed a mobile application for warehouse management, Kevin immediately went for the buy option instead of reviewing any internal options. This was despite the fact that the software development team had just finished developing an in-house field service application that was quickly being labeled as "the best thing that IT has ever done for field personnel".
Kevin chose a small, fly-by-night mobile application framework without any proper review or due diligence. The end result was a far from finished product that required 12 months of professional services to customize the application for the organization. The end product was written in a proprietary scripting language that needed an additional resource to support such, so not much value in terms of overlapping skillsets.
Kevin's actions service as a prime example of how inexperienced and incompetent IT leadership can contribute to an increase in technical debt. Kevin's lack of experience and poor decision making led to a situation where the organization was stuck with a mobile application that was far from finished and required a significant amount of professional services to complete.
The organization was now left with a substantial amount of technical debt, as the mobile application was not only costly to maintain, but also lacked user adoption. Kevin's poor decision making had a ripple effect on the organization, as it impacted the overall performance and ability to innovate. The legacy of Kevin Turner's tenure as an IT leader was one of increased technical debt and decreased organizational success.
The Cost of Convenience: How Outsourcing Leads to Technical Debt
Charlie Ledbetter was at it again. This time, he was pushing for a new CMMS (Computerized Maintenance Management System) application for the organization. The decision was made in a moment of desperation, as the ERP implementation project that Charlie had pushed for was overrun with budget overruns and had resulted in severe customer complaints.
The CMMS application that Charlie was demanding was offline capable, which was a priority for the organization. However, the application was not without its flaws coupled with a development process that was far from smooth. The customization process was slow and difficult, and the application ended up being full of defects. Additionally, the application was so expensive to scale that it ended up costing the organization roughly 1.5 million in implementation costs with annual licensing and maintenance costs at approximately 250,000.
To make matters worse, the source code of the application did not fit into the skill sets of the organization's developers. Any modification that needed to be made had to be submitted to the vendor for approval, effectively stifling the organization's creativity and innovation, as well as essentially providing the vendor with free research and development.
The technical debt caused by the CMMS implementation was substantial. The organization was stuck with an application that was cost prohibitive to scale, lacked user adoption, and was full of defects. The skill mismatch between the application and the organization's developers was a major challenge, and the inability to make modifications without vendor approval only added to the frustration.
The legacy of Charlie Ledbetter lived on, as the organization struggled with the ramifications of his decisions for years to come. The CMMS implementation was a prime example of how a lack of due diligence and poor decision making could lead to technical debt and negatively impact an organization's ability to innovate and succeed, not to mention the exorbitant amount of wasteful spending.
Charlie's actions were a pure example of how having a lack of structured "buy vs. build" processes can lead to costly decisions made by individuals who may not have the technical expertise to make the best choice for the organization. As illustrated in the previous examples, in the case of Charlie Ledbetter, his influence and incentives led to the implementation of a costly and ill-suited Oracle E-Business Suite ERP application instead of simply upgrading the existing Microsoft Dynamics. Similarly, in the case of Kevin Turner, a lack of a buy vs. build process led him to make the decision to purchase a small, fly-by-night mobile application framework, despite the software development team being fresh off of developing a successful in-house field service application.
In both of these instances, the lack of a structured decision-making process allowed individuals without the proper technical expertise to make decisions that resulted in technical debt for the organization. However, it is important to note that implementing such a process alone is not enough. The process must be followed and enforced by the organization, ensuring that all decisions are made in the best interest of the company and its technical infrastructure.
In the case of the CMMS application, the negative consequences of a lack of a buy vs. build process were evident. The application was poorly performing, cost prohibitive to scale, and full of defects. However, the organization was able to course correct by ultimately replacing the application with an in-house built solution that was loved and fully adopted by the user community. This solution was tailored to fit the needs of the organization and was developed using the proper technical expertise, resulting in a positive impact on the organization's technical debt. Furthermore, contrary to popular propaganda, the internally built application reached minimum viable product status in a mere three months, removed the annual $250,000 annual licensing and maintenance fees, while also establishing a firm foundation for continuous improvement in line with changes in the operating environment.
Overall, it is crucial for organizations to establish and enforce a structured buy vs. build decision-making process. Doing so can help prevent costly decisions made by individuals without the proper technical expertise, ultimately leading to a reduction in technical debt and improved technical infrastructure for the organization.
From Costly Decisions to Wise Investments: Conquering Technical Debt
Technical debt is a pervasive issue in the corporate world that can be caused by a variety of factors, including inexperienced or incompetent IT leadership, incentivized board members, and a lack of buy vs. build processes. These issues can lead to costly decisions, wasted resources, and even employee turnover. However, by acknowledging the problem and taking proactive steps to address it, such as investing in employee training and implementing proper decision-making processes, organizations can mitigate technical debt and ultimately improve their bottom line. As the old saying goes, "an ounce of prevention is worth a pound of cure," and this rings especially true when it comes to technical debt.
Comments
Post a Comment