In last week’s article we saw that you should be very prudent concerning IT Tactical Solutions. They are often presented by your IT teams as temporary situations; sidesteps that must be taken before the envisioned strategic situation can be reached. But more often than not, these patches are permanent. Since these dodged solutions work, most business people aren’t keen to invest in further revisions to develop an optimal design. Hence, these enduring fixes lower the quality of your digital platforms and compromise the agility and speed in future business projects.
The effect of the repeated production of sub-par assets – regardless of the name they’re given – is nothing less damaging than the continuous creation of unnecessary complexity, leading to the progressive decline of your IT platforms.
Let’s Get Financially Disciplined
The cumulative detriment to IT assets has recently inspired some smart IT people to come up with a new idiom: Technical Debt. If an IT colleague has ever uttered a sentence to you including that pair of words, you should read the following.
The Technical Debt idea entails that an IT person will document cases of sub-optimally built solutions into some sort of a ledger. Each individual occurrence, as well as the sum of everything in the register, is referred to as a technical debt. With each new IT hiccup added to the books, an official process makes the paying business sponsor officially aware of the added technical debt. The message from IT sent to the client in such situations means something like this:
- “For technical reasons, the project cannot be delivered according to the original blueprint and/or customary good practices within the allotted time and budget.
- This may impede the agility of the platform, or create additional costs in future projects. Hence there is a technical debt recognized.
- We all acknowledge that this debt should be corrected.”
Technical Debts are Fine for Communicating
This is great from a communications point of view. There are, however, caveats regarding such a well-intended message:
- The project will deliver something anyway, and it will work[1].
- But you won’t have a clue about the problematic “technical reasons” used to justify inferior quality; you’re held hostage by a single IT desk, holder of all technical knowledge.
- The debt is declared, but the impact is not evaluated. There is no reliable forecast suggesting the amount of the added deficit to write off.
- There is probably no transparent process in place to check the ledger at the end of a project in order to track and contain the global deficit.
Loans 2.0
This whole concept of indebtedness in IT doesn’t make sense from the start. It leads any business people to falsely believe that the deficit is managed. So you have a debt? As a businessperson, the following questions probably come to mind:
- Who is the lender?
- Who is the debtor?
- What are the interests made of?
- What is the interest rate?
- How and when is the principal being reimbursed?
The answers are brutal:
- You.
- You.
- Budgetary increases or lost speed pertaining to future business projects.
- Nobody knows.
- At an undefined date, when you ditch your platform and pay for another one.
Call ‘em Whatever You Want – You Pay for Everything
Short term management, conflicting accountabilities, or any other good or bad reasons to cut corners will foster the creation of lower quality assets by your IT team.
Your IT staff can call these situations fixes, patches, tactical solutions, or technical debts, but the result is always the same: the customer pays for everything, now or in the future, in hard cash or in reduced business agility.
As for the assets in question, you will always keep them for a longer time than you’d want to, whether they are true assets or debt-ridden liabilities[2].
Measuring Quality
The gloomy outcome I’ve been describing is not inevitable – there is hope. But only if you work to change how accountabilities are distributed. In my first book Understanding the Game you will have the opportunity to look more closely at the reasons why accountability on IT asset quality is missing and afflictive.
—————-
[1] For more details on why it will always work, refer to this other article.
[2] The IT Liability idiom is borrowed from the work of Peter Weill & Jeanne Ross from MIT Sloan’s Center for Information Systems Research, and refers to the fact that IT investments may create liabilities rather than assets if these so-called assets become a burden under changing business conditions.