Technical debt has been around for a while. It’s not new. You may have come across it without knowing it. It is the theory that in software development it is the implied cost of additional rework caused by choosing an easy/quick solution now, instead of using a better approach that would take longer and may produce a better, more robust result. 

Let’s imagine that if technical debt is not repaid, it can start to accumulate 'interest'. The interest could be stored up to make it harder to make changes later. Of course, I can hear your say: “if we do a ‘proof of concept’ – it is a draft, a tester, to see if the client likes the general direction. It was never supposed to be the end product.” I understand, I’ve done it myself.

Other consequences of technical debt could be: underperformance of the end product, frustration, rework, many defects, increasing the time to delivery, rising costs for support and fixes, and worst of all; decreased customer satisfaction.

If we step away from the software development example, does technical debt exist in other areas of your work?

What if you are creating a report or doing some analysis ... are there things that you can’t answer or write about now? Do you plan on getting back to them later? What if you work out a rough figure on something and expect to get that checked or finalise the numbers later on?  (But, may not get back to.) Could that be classed as technical debt?

For projects, this is where your quality standards and “what does done look like” conversations come into play. At the beginning of the project it is hard to work out what quality standards you may need, and what ‘done’ is. Generally, as the project progresses you will know what poor quality looks like and be very aware of what is not good or acceptable. It is worthwhile during project planning phases to spend time asking these questions: 

• What will satisfy the customer requirements?
• Who is ultimately responsible for the quality sign off of the deliverables?
• Specifically, what characteristics will make the deliverable fit for purpose?
• How often will you check that quality standards are being adhered to?
• What actions will you take to ensure that quality standards remain on track during the project?

I’m sure there are more questions to be asked. The idea is to plan ahead, work the plan and make adjustments as needed.  Take an agile approach to quality, be open to new ideas late in development.

So, yes technical debt can occur in projects and work other than IT software development.

What's your thoughts?

Carol

carol@onedaytraining.co.nz