Things happen in IT projects. At times, some quality elements will be sacrificed in order to offset the vagaries of the project delivery scene. A solution that works of course. But as discussed in a previous article, a working solution brings no comfort regarding its quality, since almost anything can be done in the virtual dimensions of software and computers. And when issues arise to put pressure on IT teams, a suboptimal alternative will be presented as a fix, a patch, a temporary solution, or as the most wickedly named: the tactical solution.
In circles of experienced IT managers and practitioners, the ‘tactical solution’ sits somewhere between fairy tale and sham.
The word suggests to the non-IT stakeholder that the chosen tactic is a step sideways, and that once the applicable steps are taken, the product should attain the desired state, which is often labelled as the strategic or target solution.
Because the tactical solution works (since anything in IT can be made to work), it could be viewed as a small step in the right direction. After this dodged solution is implemented, we simply need to perform a few extra steps to reach the strategic state, right?
Not really.
Tactical Solutions Waste Work
The solution does work, and common wisdom says “If it isn’t broke, don’t fix it”. Besides, how could it be broken if it works? Unfortunately, and I know that I am repeating myself, the fact that it works does not guarantee of anything.
Tactical solutions are never presented to you as a step in the wrong direction or a step back, but most of the time they are, and here’s the logic:
Once a tactical solution is delivered, the next step is not a move forward, but rather a revision of the sub-optimally designed part. The system will often have to be partly dismantled and then rebuilt, throwing away portions of the previous work. That’s not a step in the right direction. That’s not tactical. That’s wasted work.
Assets Built on Hope Aren’t Enough
Not many business people are keen to pay for throwing away something that works, and as such, when money for the next phase becomes available, there is a good chance that the sponsor will want to invest in an effort that brings more business value, rather than redoing what’s already completed. Moreover, in many cases the bewildered customer will need to pay an additional fee for the removal of something that was paid to put in place. That’s a stillborn path to the strategic state.
Hence, to get there, the IT team has to hope for luck, or must fall back on secrecy. Hope to correct the situation in the lucky event that the tactical solution breaks, or count on a forthcoming major project to allow them the opportunity to openly (or discretely) administer the needed rework effort.
Next time you hear a friendly IT person confidently talk about a tactical solution or any of its synonymous labels, don’t jump too fast to the conclusion that it will elegantly be transmuted to a strategically positioned investment based on a greater plan to get there.
Most of the time, a so-called tactical solution is in reality a permanent solution that sacrifices agility and becomes an IT liability¹ for many years to come.
If you know -or vaguely heard of- the technical debt concept and hope that it will prevent sideways steps that keep your IT assets on the sidelines of the strategic investment field, stay tuned for next week’s article. You will realize that processes designed for the continuous development of software sold directly to customers don’t always propitiously apply to the delivery of business solutions in support of what your organization makes a living from.
——————-
[1] 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.