Social networking is hot, and it’s smart to think about how your organization might use it to generate benefit equal to the market hype. As you develop your social technology strategy, it’s particularly important to steer clear of a fallacy of thought that often creeps into technology strategies for enterprise communication and collaboration.
Oftentimes, an enterprise social strategy, like enterprise collaboration strategies before them, will have among its goals a phrase suggesting that the technology should “change the way people communicate.” Superficially, this phrase may accurately describe part of the effect, but at a more fundamental level, it violates a very important change management principle. To make my point, I’ll back up and start with a little history.
I used to communicate via paper memos and phone calls, but it was cumbersome and time-consuming. Email has come to replace much of that. So, the “way I communicate” has changed, right? On the face of it, yes, but, looking more closely, not really, at least not at first. Compared to my “before email” days, I still communicate the same types of things with the same kinds of people — only email made these communications easier (for the most part). I started using email because (1) it could improve the existing way I communicated and (2) it fit my work and life context — it was just a new program to use on my handy desktop PC. Once email became part of my context, I realized that I could use it for communications that were too costly before. At this point, it did, to a degree, change the way I communicate.
As I discuss with clients the developing notions of Forrester's Business Capability Architecture (see blog post #1 and blog post #2), I have found it important to distinguish between different levels of scope for technology strategy. The primary distinctions have to do with (a) the degree to which a strategy (and the architecture it promulgates) aims to account for future change and (b) the breadth of business and technology scenarios addressed by the strategy.
Thus, I define a four-part technology strategy taxonomy along a two-dimensional continuum with (a) and (b) as axes (IOW, the four parts are archetypes that will occur in varying degrees of purity), to wit:
Type 1: project strategy for successful solution delivery. With Type 1 strategy, the goal is simply to achieve successful project delivery. It is beyond the strategy’s scope to consider anything not necessary to deliver a solution that operates according to immediate business requirements. Future changes to the business and future changes in technology are not considered by the strategy (unless explicitly documented in the requirements). The classic case for a Type 1 strategy is when an organization definitively knows that the business scenario addressed by the solution is short-lived and will not encounter significant business or technology change during the solution’s lifetime (history argues that this is a risky assumption, yet sometimes it is valid).
In developing a technology strategy for your organization, what will be your basis for deciding which technologies to pursue, when to pursue them, and how to implement them? In other words, what will be the foundation for your technology architecture and strategy? In considering this question, I assume we agree that technology strategy should directly support improvement of business outcomes, both now and over the long haul. To provide for the long haul, your technology architecture and strategy must be crafted to support a continuous stream of business change, both small incremental steps and large radical shifts.
Your strategy could begin with a list of hot technologies — perhaps even ones that business colleagues are clamoring for — but how would you know which of them would lead to the most important improvements in business outcomes? You could begin with your top executives’ current business plans and strategies — which would clearly address today’s priorities for improving outcomes — but over the long haul, business plans change, sometimes dramatically, making them an unstable foundation for technology strategy.
Since the goal of technology strategy is to improve business outcomes, let’s refine the question with that as our focus: What basis for technology architecture and strategy:
(a) Aligns best with the ways that business leaders conceive, plan, execute, and measure improvements to business outcomes,
(b) Provides the best structure for building technology implementations that align with and facilitate the ways that businesses change both now and over the long haul, and
(c) Best guides the prioritization, planning, architecture, design, and usage of technology within business improvement projects?