Technology Blog »

Strategy before tactics: yes, but what is our strategy?

Strategy Before Tactics

If you have no defined strategy then what ever tactics you employ probably won’t meet your goals.

How many of us in the information security business bought a product, tool, policy or process from a company because we needed to meet a legal requirement, a passing interest in a neat new toy, or a recommendation from a group or consultant without really visualizing how it will fit into our strategic and tactical goals for the company?

[via Expert Articles - WebProNews]

This article is about purchasing anti-virus software, and it’s generally sound but there’s one point it misses: when justifying a decision on strategic grounds, be sure that it really is a strategy.

Here’s an example to show you what I mean. A few years ago I was working for a consultancy and we were talking to a large corporation about a problem they had with their website. A form on the site was generating emails rather than saving the data to a database. To get the data into the right application, several unfortunate clerks had to type the details from printouts of the emails into a data entry screen.

Now, this was obviously an unsatisfactory state of affairs. We proposed to install some integration software of our own which would take the data directly from the site, then use terminal emulation software to enter it into the application system. The manager of the department in question was very favourable to this approach.

We started work, struggling at every step to get the information we needed from the different sections of the company involved. This sort of hassle was to be expected in a large organization, and something we were accustomed to. But then the word came down that the project was to be cancelled.

Why? Because it supposedly conflicted with the company’s IT strategy, which decreed that all applications were going to be replaced by, or integrated with, a major suite from one of the big vendors of the IT world. Fair enough, except for the timescales involved. The migration process they were talking about was to take place over several years, whereas our little project would have been ready in a couple of months.

So the result was that the situation continued as it was, with an approximate annual cost to the company of something like £90,000, and no visible end in sight.

The mistake that was made was to identify the strategy with certain decisions that had been made about its implementation, and then harden those decisions so they become inflexible rules. The company’s strategy was to reduce IT costs by integrating its applications. Did our project conflict with that strategy? No, not at all. If we’d been proposing a replacement for the application the data was going into, yes, that would have been unstrategic. But what we were doing was essentially an improvement to the existing process: if we’d found a way to make the clerks type faster that would have been OK, but because we were making the improvement through software it was seen as breaking the rules.

So the moral is: the spirit of your strategy is more important than the letter of it. Unfortunately the middle management of large organisations tends to be risk averse to such an extent that they’d rather do nothing at all than possibly make a mistake they might later be blamed for. (I wish I had some software that’d fix that.)