Should you do only things that are “strategic”?

I've had a couple of emails from readers in the last week complaining that an initiative they are passionate about was either slowed down, or cancelled altogether because it was deemed "not strategic".

In one case, it was an architecture function that said this when the project wanted to implement something not in the standards. And in the other, it was a new business initiative stopped because the opportunity wasn't aligned to existing revenues and failed to meet the "adjacency" test for new markets.

As a general rule, my own thinking is that lots of little initiatives that aren't part of the strategy can get distracting. Usually, the benefits associated with such non-strategic initiatives are microscopic compared to the amount of bandwidth they take up to generate those benefits. And the strategic projects, big as they usually are, tend to have equally large benefits associated with them.

But does that mean that non-strategic projects don't have any value at all? By no means.

Whilst it is true enough that when you factor in all the long-term costs (i.e, the operating costs of non-standard, the dis-synergies you get from complexity, and the increase in potential legacy, for example) of these non-strategic things, the business case usually collapses, those few times when it doesn't are highly illustrative.

Such cases tend to tell you that the strategy, not the project, is wrong.

People always tend to think that that strategy, once defined, is inviolate. That it should be fixed over some long term planning period, and must be adhered to rigorously.

I, on the other hand, prefer strategy to be flexible. The overall objective can't change every few seconds, of course, but the way those objective ought be achieved should have a degree of flexibility, a flexibility that increases the less course-grained the decision level is.

So, for example, I wouldn't like to see a new platform introduced to a technology estate just because a single project wanted to do so. On the other hand, if the benefits outweighed all the long term costs, I can't see any rational reason to prevent it. Even if it meant a new standard had to be created.

The fact is, if the new platform can stand alone and pay for itself, it actually represents a new capability that can reasonably be added to strategy.

Here is the fundamental failure I see so often with strategy, and strategy-related functions like architecture: as custodians of the one-true-vision, it is often the case that such teams fail to consider the inputs from teams they feel have no stake in the "big-picture". Small business lines, and smaller projects fall into this camp. Because their overall contribution is demonstrably less impactful to the whole how could they possibly have any idea of what the overall picture should look like?

The thing is, those small projects and business lines, when added together, are often much bigger than even the biggest of the big-ticket items in any organisation. How, then, is it reasonable to fail to consider their views in the overall scheme of things?

What I am really describing here, of course, is ivory-tower-ism. That's what you get when groups are entrusted to keep the "one-true-vision" and aren't forced to justify their decisions to those who are entrusted with implementing them. They go ahead and publish their positions to the organisation, without very much acceptance of the do-ability of those positions.

All this leads me to a diagnostic question: when were the architects, or the strategic folk, or the business development people in your organisation last asked to prove their statements were valuable? If the answer is never, I bet you have lots of documents, but not much coherence to them. I bet your organisation spends a whole lot of time getting around all these people rather than working with them. I bet, in fact, that they represent a consistent drain on progress, a brake to any move forward that anyone ever proposes.

On the other hand, I've seen working strategy functions. Even working architecture functions! They all have one thing in common: they have to prove that what they're saying is worthwhile doing. And they have to prove it to everyone, not just management.

What kind of organisation is yours? Strategy as hand-break, or strategy as accelerator?

Update: Peter Evans-Greenwood adds some interesting points in this comment. Refer to his blog posts on the value of strategy and enterprise architecture and how the new name of the game is moving from velocity to acceleration.

Comments

[Peter Evans-Greenwood]

Strategy methodologies, and IT strategy methods in particular, are largely irrelevant in their current forms. What sense does a five year plan make in a world which changes radically in two years, or less? I know some CIOs--some particularly innovative and effective CIOs--who have abandoned three or five year plans to focus on organizational agility and effectiveness.

Too much IT strategy is premised on large, multi-year transformation programs. It's application strategy, rather than IT strategy. These programs never seem to deliver their promised benefits. This approach made sense a decade or more ago, where IT was focused on delivering the next big IT asset into the enterprise. The pace of business has accelerated so much in recent years that the multiyear engagement model this implies is not longer appropriate.

The IT departments we've created as applications factories have become an albatross too the business; making us incapable of engaging anything but a multiyear project worth tens of millions of dollars. They actively prevent the business from engaging in innovative solutions or business opportunities. Even, as you point out, when there is a compelling reason to do so.

Simply put, the value created by enterprise architecture has moved, and the practice hasn't kept up. http://peter.evans-greenwood.com/2009/05/07/the-value-of-enterprise-architecture/

In the same way, the last decade's focus on process has driven significant cost out of the business, but at the expense of removing variation. Now that we're all good at process, it is these variations which create differentiation. The battle front has move from optimizing velocity--how efficient we are at delivering a product or service--to improving acceleration--how good we are at rapidly reconfiguring a product or service. http://peter.evans-greenwood.com/2009/07/21/accelerate-along-the-road-to-happiness/

In both cases, the methods and practices that have brought us to the current level of performance, are also one of the larger impediments to achieving the next level.

r.

PEG