What is Technical Debt and how to avoid and reduce it
In this brief article, I’ll attempt to explain the concept of technical debt, breaking down the term and suggesting ways organisations can avoid it as much as possible. As I’ll explain, some aspect of technical debt is inevitable, but there are things IT leaders in the public sector and beyond can do to minimise it.
What is Technical Debt?
If I were being flippant, I’d say:
Technical Debt is essentially the amount of work required to do something properly
I can almost hear my fellow ICT professionals shouting, “properly is subjective!” and I couldn’t agree more, that’s why Technical Debt needs to be considered at all levels, not just ICT. Put another way, technical debt is the price we often pay when our historical technical investments are no longer fit for purpose or need to evolve to meet new requirements. In many ways, technical debt could be described as the price of IT change. So where does it come from and how can technical leaders in the public sector address or mitigate it?
“We need to capture some data from a group of people” – sound familiar?
The ICT department has been asked to create a way of capturing data from a group of people. The easy answer would be to use something like Microsoft Forms, a fantastic forms package that can have an interactive form prepared and ready to share in minutes. You can send it to a group of people via email, or even use a QR code on a document, the data is collected and stored, ready to be added to an excel spreadsheet – great.
But what if the requirements change?
For these three new requirements, you have technical debt – as the initial solution was fit for purpose based on the requirements at the time but not when new requirements are added. This is a very basic example – imagine the issues that might come about if an Infrastructure was designed for predominantly office workers, then suddenly, they all work from home…
Types of technical debt
I haven’t been able to find these defined anywhere but they are so logical I imagine they have been discussed previously. For me, four types of technical debt need to be considered:
Scope Change technical debt
This is essentially the scenario above. When the given requirements change and the solution that was scoped and put in place becomes unfit for purpose, or at least not the ideal solution. Sometimes this can’t be helped as things do change but it is so important for services to be clear with what they want to achieve, as this will help an ICT team deliver the right solution.
Delivery and Fundamentals Technical Debt
If the request for a service is unrealistic, it can lead to significant technical debt. This would include unrealistic timeframes or expected costs. A lack of input from the right people requesting the service. A lack of understanding about core fundamentals of any technical delivery, such as accessibility, security, and data governance. You could not only build considerable technical debt by not considering these areas, but you could also be non-compliant.
Recommended by LinkedIn
Technology Evolution technical debt
Technology evolves, it gets better and better, it’s important to let ICT departments work to a model of Continuous Service Improvement (CSI) as this will help to keep on top of technical debt. Think of this one as a house of cards – if you’re adding cards on top, but the ones below need replacing as they are no longer fit for purpose, you’re more likely to have problems.
Strategic technical debt
Strategic Technical Debt is in my view the most difficult for large parts of the public sector. Technology moves fast, opportunities come along quickly and keeping the house of cards that is an ICT department in a good shape is difficult. Senior leaders in an organisation need to think big and invest time in understanding what is possible so that your strategy reflects the incredible things that can be achieved with tech. There is a lot of help available to achieve this, from your Client Technology Leads (CTL’s) at Microsoft for example, but it’s important to be aware of the potential for all types of technical debt if it’s not part of your strategic thinking.
So what can you do?
We find ourselves in a world where machine learning and incredible Artificial Intelligence (AI) services can be part of your standard Public Sector toolset (your ICT Service Catalogue). Chatbots could be controlled by those service staff answering questions, automating huge parts of a Public Sectors customer-facing world with a 24/7 service at a reduced cost. Automatic transcripts of meetings, complex business workflows and automation of processes should be the norm – it is a hugely exciting time to embrace the art of the possible.
2. Think iterative
My advice is to think big and invest in a model of digital building blocks, with the flexibility to transform your services regardless of the problems to be solved. We are seeing customers transform archaic Line of Business (LoB) systems using the Microsoft Power Platform or Dynamics, using IoT to trigger workflows in the support of vulnerable people and complex problems.
3. Be informed
Do you and your colleagues understand what’s possible? Are you aiming high enough? Understanding the art of the possible doesn’t necessarily mean you need to undertake hours of research, there are people available to help from us at Microsoft and some of our partners. We see what’s possible every day and can help you with real-world examples.
Final thoughts…
The future many of us talked about for years in the public sector is here – the question is how quickly organisations can move to adopt the tools available, and how much technical debt they can avoid along the way…
One last thing - there’s also a great book that touches on technical debt called the Phoenix Project, which describes itself as “A novel about IT, DevOps and Helping Your Business Win”, written by Gene Kim and Kevin Behr. Well worth a read 😊
About Me
I have an MSc in Managing and Leading IT systems change, specifically studying Leadership, Change Management (most notably Kotter’s model) and a (seemingly) little known area of research called Technology Acceptance (which I’ll write a dedicated post about another time). I’m also an ITIL V3 expert and undertook the ITIL4 transition course (High-Velocity IT – who would have guessed?)
About My Role
I’m a Microsoft Client Technology Lead (CTL), working to help customers understand the range of Microsoft products and how they solve business problems. Essentially, my role aims to support IT departments to ensure they have suitable technology available in their Service Catalogues to solve business problems.
great article Andrew Boxall. project overhangs will never go away, it just needs to be considered, accounted for and approached in the right way especially during project rollouts. True is the same for non-technical change. You'll probably agree it's easier to see some of this from the outside looking in now.
This is a great post - Think big, be iterative and always have CSI in mind.