strategic planning, or not

Few words in the business lexicon are applied more inconsistently than "strategy." This thought comes to mind once again from reading former Symantec CIO Mark Egan's excellent summary of what activities the new CIO should perform in his first 90 days.

In this chapter, Mark assets that in your first ninety days you needed to accomplish some high visibility tactical objectives, get some critical, time-sensitive issues addressed. Makes sense -- I'm being brought in because the organization has some problems, and I'm expected to hit the ground running and fix them, while not getting dragged down to only operating at a tactical level. He then recommends a full organization review, to clarify roles and responsibilities, ensure alignment with business needs, etc. Also, a fantastic idea, and now is the time to do it.

Then Mark argues that the last thing to be accomplished in the first ninety days is a strategic plan. Wow, that got me excited. You're going to get all this AND a strategic plan executed within your first quarter?

The reason for my confusion is a variance in definitions. Wikipedia says that strategic planning consists of the process of developing strategies to reach a defined objective." Mark's focus in his chapter is aligned with this definition. Mark encourages the new CIO to examine the current state, imagine a potential future state, and perform a gap analysis to determine what needs to be done to achieve this future state. As a consultant, I perform these activities regularly, which I have always considered to be "assessment, recommendation and implementation." I should acknowledge that I agree entirely with Mark's assertion that such a gap analysis should be performed as soon as possible, although 90 days is pretty aggressive for a full assessment of the application, organization, network and infrastructure.

However, I don't see these activities as strategy. Let me tell you why.

The classic definition of strategy consists of several factors. I need to establish a competitive position that is different from my rivals, so that I can create and preserve a competitive advantage. Strategy is by definition a differentiator. Method and Apple create a stylish product in a commodity market, which allows them to charge a premium price. Operational efficiency, on the other hand, is doing the same thing your competitors are doing, just doing it better. So productivity, change management, continuous improvement -- all great things, but ultimately they are easily copied by your competitors.

But, you say, what about Wal*Mart or Southwest Airlines? Their strategy is focused on low prices for consumers. So isn't reducing costs a strategy? Only if they are so committed to cost leadership that they're willing to do everything differently. Southwest doesn't go to the airports that anyone else does, refusing to play the hub game that all other airlines play. Strategy implies trade-offs -- determining that you can't be everything to everyone, so you define one segment as your own and run with it. If I want to fly to O'Hare inexpensively, I can't take Southwest, because it doesn't go to O'Hare. But if I am price-conscious enough to play by entirely different rules, Southwest is my airline.

So the definition that Mark Egan uses here doesn't match the classic definition of strategy. This review he recommends is not so deep as to examine, "How can we make operations a competitive advantage?" To be fair, that's a conversation which has only just begun. In an interview recently, Eric Schmidt, CEO of Google, stated:

At Google, operations are not just an afterthought: they are critical to the company's success, and we want to have just as much effort and creativity in this domain as in new product development.

Google has built a distributed parallel computer system, using commodity hardware. When it comes to adding more servers, Google plugs them in. New resources are recognized and used almost without human intervention. Google modified the Linux kernel to make this happen, and the knowledge of what's been modified and why remains proprietary. Is this going to work in the long term? Who knows? Strategy is a hypothesis, a theory, a way of guessing which innovation will allow competitive advantage.

So strategy is beginning to be applied within technology departments. Adoption will be slow, since so much money is committed to "keeping the lights on," which makes the lure of continually refining existing processes very appealing. And how many companies are willing to look at the IT spend, and say, "Huh, this is good, but if we invested a lot more, it's possible we could realize considerable upside."

The most difficult barrier with implementing strategy within a technology department is alignment with overall business strategy. Too many organizations still confuse operational effectiveness with strategy. If a company's defined strategy consists of elements which are not true strategy, how far can the organization move forward? Many corporations go through the exercise of defining a mission, vision and strategy, but at the end of the process, if your strategy is, "Reduce costs, increase conversion to sale, and expand globally," how can a technology organization align with those goals and do anything beyond operational efficiency?

At that point, you're stuck with the dilemma I've heard many times from consultants, "How can I tell the CEO that the strategy she's proudly rolled out isn't really strategy, and isn't going to get us a sustainable competitive advantage?"

Good luck with that.