RSSManaged and unmanaged social networks in the enterprise
One of the most consistent patterns I have seen with the deployment, and subsequent failure, of social networking tools within the enterprise is that, whether of its own volition or having been hectored into doing so, the IT department puts on a big push to deploy the tools, creates a lot of buzz and fanfare, and then… walks away. The network is left to stand or fall on its own, the problem of adoption and utility left to the users.
Happily, it seems as if enterprise IT departments are starting to understand that deploying a social networking platform inside a business is a different prospect than doing so to the public, and that it’s best if someone is dedicated to shepherding the fledgling community and encouraging and shaping its growth. Business social networks are not, after all, things most users would be drawn to out of self-interest, and even if they were, the proliferation of social networks users are expected to keep up with can quickly become confusing and unmanageable. I’ve discussed some of the problems before. And with 95% of respondents in a recent survey on the subject indicating that community management is “essential” to their Enterprise 2.0 efforts, it looks like the old days may be done with respect to simply throwing tools out toward the users and hoping they latch on.
I’m a fan of community management and believe that it works, and in many cases, is in fact essential to social network-based tool adoption. On the other hand, I also believe that there are still situations in which it’s appropriate to simply throw tools and projects out into the pool and to see what floats. If deployment is sufficiently easy and the tool sufficiently inexpensive, if there isn’t a clear business case and no impetus to build one, why not? The article linked above mentions the prolific failure of Sharepoint deployments in the enterprise as an argument for a managed community approach to deployment, and I have no doubt that adopting that approach improves Sharepoint success rates. Sharepoint, however, is a case in point; many businesses don’t have a compelling business case for it, but many of them have the product already. Deployment is point and click. In that case, why not go ahead and roll it out? Worst case, nothing happens (well, that may not be strictly true; the worst case may be that half the company decides to use it and half go with something else, but that’s another issue); best case, someone finds that it scratches an itch they didn’t know they had and it improves efficiency in the organization.
Enterprise CIOs no doubt feel some sense of revulsion at that idea, but taking two steps back, that is often essentially what happens with many IT-driven projects already; failure to educate or sell the rest of the organization on the tools relegates them to mediocrity or outright abandonment. The difference is, those projects are staffed and budgeted with the assumption, indeed the necessity, of producing a success. If one initiates a project with no expectation of success, and plans and budgets accordingly, little is lost if it tanks and much is gained if it does not. Some people might say that initiating a project in that environment dooms it, but that’s simply not true… users pick up on and champion solutions they find of value to their work. Right now, many of them are going outside the enterprise to look for such solutions. Producing them internally with a similarly entrepreneurial approach to that of external competitors maintains IT department relevance and can produce more efficient internal solutions. And I’m not suggesting that all projects be specced and run as if they are shoestring startups. But there are certainly a large class of them that can be, and should, when full-blown community management isn’t in the cards.
