A review of systems that fails to review readiness for the next three to five years of operation isn’t doing you any favors.

By MARK RIFFEY for the Flathead Beacon

In the programming world, there’s a term called “technical debt”. Technical debt is refers to work created by existing systems, processes and methods. You might call it maintenance, upkeep, re-work, refactoring, re-design, etc.

The term “technical debt” is typically used when discussing programming, but as a friend reminded me a week or so ago – programming doesn’t own it. It’s about any process, whether it’s new or has been around a while.

Technical debt appears, like it or not

Think about the handwringing that decision makers face when they find that a road, bridge, or other infrastructure requires substantial maintenance to continue to allow it to remain in public use. This tends to happen years after repeatedly putting off regular maintenance that used to be performed routinely.

Often times this situation is created because the work was set aside because of a shortfall, and sometimes because the funds were re-directed to another project in the same department. When this happens for a decade (or several), the costs of “catching up” are immense. They’re a form of technical debt – a particularly ugly form that can overwhelm an agency budget. The same can happen to a company that fails to maintain and update their processes, systems, and methods.

While it’s easy to say “Don’t create anything you can’t afford to maintain”, you often have no choice in the matter when “the thing” was created several generations ago (such as public infrastructure), or at a time preceding your arrival at the company with looming technical debt.

So what do you do?

“No one likes change, but everyone likes improvement.”Chris Hogan

Deal with “Always done it that way”

Do you still do it “that way” because:

• It’s so much cheaper this way?
• It’s far more efficient?
• You regularly review alternatives and those reviews have (so far) shown that the current process still works best.

As you might expect, the third answer is still a reason why your process hasn’t changed.

Even if your processes are reviewed regularly and are up to par, it’s important that your existing systems, methods are not only solid for existing uses, but ready to meet the challenges of systems and processes now under development – much less those being considered. A review of systems that fails to review readiness for the next three to five years of operation isn’t doing you any favors.

There will be investment to bring existing systems up to the standards needed to work with your next big thing. It’ll be expensive and time-consuming, perhaps seeming insurmountable. That’s no reason to let it sit unaddressed. even more important to minimize creation of new technical debt.

Triage and chip away

People get defensive about technical debt, so you have to be careful how it’s discussed. As with so many things, it isn’t about blame. It’s about improvement. The way it was done “back then” was very likely the best way at the time. Most of us (hopefully almost all of us) are smarter than we were five or ten years ago. When we look back at work we did years ago, does anyone think it’s as good as it should be when viewed through today’s eyes? Rarely. We all make the best decisions we can at that time with the info and resources we have. 20 years later, we may seem much smarter, but we have the benefit of the passage of time.

Prioritize / triage the technical debt in the context of your future. If improved and readied for your projected needs three to five years from now, what existing systems, processes and/or methods will have the greatest impact on the work you’ll do during that period? Chip away at that.

There will be people who need to be convinced. There will be some who see the challenges as insurmountable. There will be some in the middle of the road, waiting to see. Choose a small but important project, involve your influencers, and start getting some small wins. Use them to create momentum. Give your people and the work time to rise to expectations.

Want to learn more about Mark or ask him to write about a strategic, operations or marketing problem? See  Mark’s site , contact him on  LinkedIn  or  Twitter , or email him at  mriffey@flatheadbeacon.com .

*****************

Want to learn more about Mark or ask him to write about a strategic, operations or marketing problem? See  Mark’s site , contact him on  LinkedIn  or  Twitter , or email him at  mriffey@flatheadbeacon.com .