There Are No Temporary Solutions

In my first series of posts, I'll look at common missteps in the IT world. These are things which I've seen over and over again. For each, I'll give some examples and share some ways to see them coming - oh, and I'll throw out some self-defense techniques for avoiding them, too.

So - the first item on the list of IT Missteps is the temporary solution.

Here's the rule - say it with me: There are no temporary solutions.

What is a temporary solution?

Call it a one-off, a work-around, or a temporary solution - these are the things which were meant to be in place as a stop-gap, but end up becoming calcified into the environment. Sure, sometimes they really are temporary, but you should look at them with skepticism and with an eye towards the long-run.

Did you ever get into a situation like this:

You are trying to get data from one system to another. You've heard that someone is working to build out a new architecture for data transfer but that's just a start-up project. But hey, you need to get this data moving now. So what happens? You end up with some horked up batch file transfer to feed the data across. Later, you find out that the data transfer you need is outside the scope of that architecture project. Welcome to the not-so-temporary Temporary Solution.

Or maybe you run into a bug in some internally-supported software. You can't run the report...but it works fine if you exit and restart the application. So everyone who needs to run the report does just that.

Why does it happen and why is it a problem?

These sorts of solutions are often a matter of risk transfer or effort transfer. It's easier for me to have you do extra work. Other times it's a matter of not having a choice at all - you have to do something now, but in doing that, the future isn't considered.

Temporary solutions become permanent for a few reasons. Sometimes they're just good enough to live with. It's like having a minor chronic injury - you can live with it, you can function - just not as well as you should, and it's hard to know when you should stop living with it and seek treatment. And sometimes there is hand-waving about future fixes, but that cavalry doesn't make it over the hill.

What makes these one-offs a problem? Well, if it really were temporary it wouldn't be so bad. But in the long run, one-off solutions are expensive and difficult to support. There's typically a lack of thought about the workaround since it's only temporary anyway.

These one-offs are like stray animals looking for a (support) home. An ex-boss of mine once put it this way: "shoot it, or adopt it." Okay - maybe that's a harsh way to say it - but the point remains the same - you either need to make it part of your business or you need to end it. The in-between state where you feed the stray and it stays constantly on the edge of starving doesn't help anyone.


What's a good self-defense against the temporary solution?

First, realize that having a workaround shouldn't let anyone off the hook for a root cause. In ITIL, this can be a matter of the graduation from incident management to problem management.

Second, being conscious of when something is about to become the way you do business. Do the processes and support mechanisms exist for it? Do the resources exist? What costs does this impose?

More generally, there needs to be a connection between the temporary solution and the long-term solution. We can set up the batch file method along with adding this to the scope of the architecture project. I'll restart the applications in parallel to you looking for the root cause of the report issue.

This is a problem which demands a holistic approach to get the optimal results. You need to have a good problem management process in place. You need to have an analysis which informs a gating decision to adding workarounds and pieces of solution to your business. And finally, you need the governance to ensure you don't get trapped in the next misstep: this is too important to wait. We'll take a look at that in an upcoming post.