Technical debt is a metaphor used in software development that refers to the implied cost of additional rework caused by taking shortcuts or using limited solutions rather than better approaches that would take more time. This concept can also apply more broadly to IT assets like applications, technologies, platforms and hardware. Technical debt is incurred from the beginning through quick solutions but also grows over time as requirements and technologies change. Ignoring technical debt can lead to an increasing amount of unplanned work that disrupts planned projects and consumes an IT department's resources. Managing technical debt involves assessing debt levels, choosing a payment strategy like replacing or updating assets, preventing new debt, sticking to plans, and tracking progress.

1. Technical Debt
A Concept for PPM & ITASM
HANS NYGAARD, SOEBORG, 2019.09.06

2. 2
Technical debt concept 2019.09.06

3. Technical Debt
(also known as design debt or code debt)
a metaphor in software development that reflects the implied cost of additional rework
caused by choosing an easy or limited solution now instead of using a better approach that
would take longer
3
Technical debt concept 2019.09.06
The metaphor however, can also be used in the bigger IT perspective, when building or buying and then
implementing an IT asset (applications, technologies, platforms, hardware etc.)
Like a negative compound interest rate on our IT investments

4. Fact: Technical Debt can be incurred from the beginning but will be incurred over time
• IT application example:
− Quick and dirty: An application is prototyped, business loves it and the prototype is put into production as-
is - without refactoring into a mature application. The application will likely be difficult to support, scale
badly, have high security risk etc. It has a high Technical Debt from the very start and you’ll be paying a lot
of interest on this ‘quick loan’ from early on. The compound interest goes up very quickly.
− By the book: An application is bought as best of breed and implemented correctly. It has no Technical Debt
to start with but over time the users requirements will shift while the offered functionality in the
application is static and the technology used in and by the application will become outdated. The
application has a ‘rate of decay’ and unavoidably incurs Technical Debt over time. And the compound
interest accelerates if you don’t pay.
• Debt examples: outdated SW version or patch level, old OS, old firmware, EOL hardware, custom code
changes (Z dev), unmonitored integrations, lack of documentation …
Incurring Technical Debt
4
Technical debt concept 2019.09.06

5. 1. Business IT projects
2. Internal IT projects
3. IT changes
4. Unplanned Work, such as incidents, problems, re-work
• Technical Debt leads to Unplanned Work (or best case to many
urgent changes)
The 4 types of work in IT
5
Technical debt concept 2019.09.06
Planned
work
Unplanned
work

6. • TOYOTA principle #2: The Right Process Will Produce the Right Results - Create a continuous process flow to
bring problems to the surface (kaizen to eliminate muda). Waiting time is waste.
• A project plan is a view of the process of providing a solution to our users, consider the potential waiting time:
• Planned vs. Unplanned Work is like matter and antimatter, unplanned work annihilates any plans
• Technical Debt = Unplanned Work: it directly consumes time from planned work and induces wasteful delays
• If ignored Technical Debt can end up consuming the full capacity of an IT department!
Planned vs. Unplanned work
6
Technical debt concept 2019.09.06
•Plan
•Develop
Project Team
•VM
provisioning
•Assign Services
Azure Team
•Install software
•Configure
Project Team
•Firewall rules
•System users
Network Team
•Testing
•Documentation
Super Users
•Training
•Data migration
•Go-live
Project Team
Busy due to
unplanned work
 Waiting time!

7. • IT exists to service business – within the expected time, quality and cost
• Example: ERP releases
• What Business sees is unpredictable results, not delivered on time - and really expensive!
Cost of Change
7
Technical debt concept 2019.09.06

8. • 5 debt steps to manage Technical Debt :
1) Assess (know) what you owe: for each IT asset monitor SW/HW version release status. Check the
numbers and trends of helpdesk Incidents, Problems tickets or Change Requests. Check the number and
trend of test defects for software releases. Etc…
2) Choose your debt ‘payment’ strategy:
• Debt repayment: replace the IT asset that is considered technical debt
• Debt conversion: replace the current IT asset with a better (but not perfect) alternative. The new solution has a lower interest rate. A
good business case if a perfect solution is exceedingly expensive.
• Keep paying the interest: This might be a good business case if: (a) replacement is much more expensive than keeping the IT asset
alive with continued or even extra support; (b) the IT asset is rarely used or changed; or (c) if the IT asset is near its end-of-life.
• Do nothing is not a strategy!
3) Stop incurring unnecessary new debt: implement technical debt rules and checkpoints for provisioning of
new IT assets. In theory you should never do projects that don't somehow reduce technical debt.
4) Stick with the plan! Working on technical debt never stops
5) Track your progress - back to 1)
What to do? Managing Technical Debt
8
Technical debt concept 2019.09.06

9. Bedtime stories
9
Technical debt concept 2019.09.06