The digital ecosystems on which higher education institutions depend are ever-expanding and are rivaled only by the healthcare industry in their complexity. Any institution may manage dozens
of enterprise-wide systems, subsystems, and vendors. These systems compose competing technologies, architectures, user experiences, contracts, and financial terms – all of which must be managed. While this critical infrastructure underpins distance learning, enrollment, financial aid, and more, it has created unprecedented technical debt that burdens IT teams and severely limits institutions from making faster, more meaningful progress with their digital investments.
Technical debt is a term used in software development to describe the inevitable debt – money, resources, and time – that organizations incur due to the expedient delivery of services. Because the code base is rushed or customized, these legacy or custom solutions often require significant adjustment, rework, and maintenance. This creates mid- to long-term costs that are rarely considered.
IT managed as a cost center typically adds to technical debt
Most CFOs, CIOs, and senior executives have not strategically evaluated or accounted for technical debt. Although accelerated by the pandemic, these ecosystems are years in the making due to siloed organizations where IT is engaged as a cost or service center instead of as a partner.
IT teams, in turn, do their best to maintain these, often outdated, systems. But working long hours to “keep the lights on” stops them from innovating and improving the value they bring to the students, faculty, and staff.
This siloed, cost-center approach is hard to avoid. Major departments have their own IT and technology budgets and fiercely advocate for their projects to be prioritized and completed. No one is empowered to overrule these budget owners other than the President, Provost, or board. Furthermore, when specifying their IT needs, customer “requirements” typically dictate that software is customized to align with current workflows and operational needs – further burdening IT.
These customizations come to the IT department in small, business-related requests and typically take a developer a few weeks or months to create, test, and deploy. These costs are accounted for in the current fiscal year through budget and IT staff resourcing. However, after that fiscal year, the technical debt these customizations cost is rolled into maintenance and support.
Think of it like compound interest. Unless interest payments are made, the burden of financial debt will grow at an exponential rate. Similarly, with the compounding costs of ineffective maintenance, legacy customizations, outdated software, missed opportunities to roll out new programs, system fragility, and replacement/upgrade costs, the technical debt grows exponentially.
Pet projects and customizations put institutions further in the red
To illustrate this point, here’s an example. Consider the enrollment department with its responsibilities for marketing and recruitment. Because this department “owns” the institution’s revenue stream and has its own technology budget, it can dictate what, where, and how its funds are spent. So, when a mid-level manager requests a customization to the institution’s Salesforce-based recruitment and relationship management system, the IT team jumps into action – even if the pet project brings little benefit to the recruiting process.
It’s determined that the project scope is reasonable and IT commits to a speedy roll-out. Only 100 lines of code must be programmed, equating to $2,500 worth of development time. It sounds easy and cost-effective, right? On the contrary, it’s a short-sighted approach that can catch institutions by surprise in a couple of years when their software solution starts falling behind in new features, etc.
Code customization isn’t a one-and-done task. The custom feature will require ongoing maintenance and support. Plus, each Salesforce upgrade triggers the need for testing, validation, and even code modification. The new code set has now cost the institution the ability to upgrade the system rapidly and uniformly, increasing the liability of its investment in Salesforce.
Over and above the development time, the monthly maintenance cost for this pet project has skyrocketed. Let’s look at the example math:
- $2,500 – Initial cost to build, design, and implement.
- $5,000 x 12 – Monthly testing, maintenance, and updates.
- $20,000 – Lost value from the current Salesforce license (estimated at 20% of license value) due to inability to upgrade to next version
- $5,000 – Cost to build, design and test per 1x integration
- +$200,000/day – Partial or full system downtime caused by customization
- $??? – Opportunity cost of of falling further behind
This is an illustration of typical data that makes up a technical debt formula. There are multiple ways you can calculate technical debt, but as you can see, the true cost of IT customization is significantly higher than the level of effort (time) it takes to build it.
The true cost of technology debt
Software customization has its place when it can close technology gaps and meet strategic-level internal requirements. But institutions must track the mid-to-long term impacts to better estimate the costs of future system replacements, upgrades, etc. However, customizations must be carefully planned, developed, and tracked throughout their lifecycle, because if this piece of software is forgotten, it can be like an iceberg where the real long-term costs are 90% out-of-sight.
I have witnessed many institutions that cannot recover from the untracked and unaccounted liability associated with technical debt. Indeed, it’s a critical KPI – a key indicator of digital health – that has the potential to cost an institution its future, single-handedly.
In today’s COVID and soon, post-COVID world, if institutions are to pay down tech debt, they must take a proactive position and capture, track, and account for it on a balance sheet just like any asset or liability.
I believe that progressively minded CFOs will become champions for more strategic and architecturally sound investments in technology, including reducing technical debt. As a result, higher education institutions will only ensure better, higher-quality digital experiences for their prospects, students, faculty, and staff.
Note: “Technical debt” was first coined by Ward Cunningham, a software developer who is credited with inventing the WiKi and being one of the original authors of the Agile Manifesto. For those in the software profession, Ward is a major influencer and contributor to our modern processes and thinking.
Wayne Bovier is CEO and co-founder of Higher Digital, a leader in digital transformation for higher education. At Higher Digital, he leverages his 20+ years of experience leading global product teams & organizations and his 10+ years in global higher education to help institutional executives (Presidents, Boards, CIO’s, Provosts, and CFO’s) improve IT project success rates
More from UB
