CIO: So, how is the new performance review tool doing?
Director: Works like a clock. It’s been three months since we’ve deployed it and so far so good.
CIO: No issues, then?
Director: Well, there is that thing we’ve been sort of struggling with.
CIO: What is it?
Director: Adoption is kind of low. Honestly, they don’t use it that much.
CIO: Hmm… Nice. So they keep doing it in email?
Director: Yep. Plus some homegrown stuff and an open source thing someone installed under his desk.
CIO: What have you tried?
Director: The usual. You know, email announcements, posters, some training. Signed up a couple of VPs to talk about it at their meetings. Still, the uptake has been minimal. A couple of divisions said they don’t get it; one said they won’t look at it till the next fiscal year.
CIO: Nah, that’s not enough these days. You’ve got to provide incentives. Sponsor a contest or two, have cool prizes for the top reviewers. Do that viral thing. Also, I hear reaching out to the vocal folks helps – make sure you sell it well to them and get them talk about their success stories. Plus, go to that site… what’s its name… slowforward, fastbckwards… something like that… they post good tips. I’ll look it up for you.
Director: Will do. Remember, how simple it was in the old days?
CIO: Sure do. But times have changed. Don’t forget to set up that contest…

Doesn’t make much sense, does it? But try replacing “new performance review tool” with “new wikis” or a social software package of your choice, and all of a sudden the dialog doesn’t seem so absurd anymore.

Adoption: a New Word and a New Concept

For years IT lifecycles have been about planning, deploying and operating. Whether you were rolling out a review tool or a new accounting package, worrying about its adoption was simply not on your to-do list. You plan it well, you deploy – and then you’re in maintenance mode. But when it comes to social business software, deployment is just an initial step on what may become a long and rocky road. And if you’re not thoughtful about walking that road, it may lead to a rather daunting place where beautiful broadly available tools sit for months waiting for a single user to touch them. Having a social tool to solve a real business problem is necessary for long-term success, but in most cases isn’t sufficient. The second ingredient of the e2.0 secret sauce is adoption.

The main premise of social software is that it connects people – better, faster, cheaper. This is where its power comes from. But it is also its Achilles’ heel. The same network effects that make social software so powerful once it’s broadly adopted can make it nearly useless when its user base is too small. How valuable Facebook would be if you were the only one using it – or if it was used only by people with whom you have nothing in common? Today, more than ever, network effects bring a huge advantage when taken into account, and a lead to spectacular failures when ignored.

As usual, in the enterprise context, things are similar, but not quite the same as they are in consumer space. Network effects are obviously not new in the enterprise land – after all when you send email to a colleague you do expect that person to have an email account and to check it often enough. Same goes for actions like sharing a document with someone – your recipient should have software capable of understanding the format you’re using. What’s different about today’s social software is the landscape in which it has to be introduced and operated.
Until now internal adoption of enterprise software followed one of the two simple models:

1. Users have no choice (desktop OS, e-mail, payroll, etc)
2. Users benefit from software regardless of its adoption by others (file sharing, internal portals, etc)

In the first case you get a speedy (though not always cheerful) 100% adoption, in the second case as long as the tool provides value, a simple awareness campaign leads to steady adoption growth. In contrast, adoption of social software happens in a dramatically different environment: typically users do have a choice, and the value they get out of the software depends on how many other people use it. While different social tools require different levels of adoption to become useful (Hutch Carpenter has a great post on this), they all need some critical mass of users – and for some tools that mass is rather significant.

Enterprise social systems are typically complementary in their nature. Rarely – if ever – they are deployed as a direct replacement of an existing LOB application. They aim to improve connections, but truth is that in any functioning organization people already have some existing ways to connect and collaborate. So unless your new tool explicitly replaces an old one, it faces what every new start-up out there has to face: competition. All of a sudden, IT departments and business decision makers have to deal with challenges such as cold start problem and sobering reality check of “build and they will come” approach. They face internal communities happily sharing information on email distribution lists, documents on internal file shares filling the gap a wiki was expected to fill, and surprisingly efficient expertise finding methods that involve asking a know-it-all colleague down the hallway. When it comes to social software, habit may be the biggest obstacle.

Walk the Yellow Brick Road

So what’s the recipe for dealing with these challenges? It’s simple: you acknowledge their existence, and invest efforts into winning your users’ attention. At least, this is a recipe that’s been working pretty well for the team I lead at Microsoft. In particular it has really helped as we’ve been developing and driving adoption of CodeBox – Microsoft’s internal shared source system for collaborative software development (more on it here).

We’ve found that the key is to think like a startup, treating employees like customers and fully realizing that they had been taking care of their business before your solution existed, and will move on if you go bankrupt. While the exact list will vary depending on the system you are trying to get adopted and factors like organizational dynamics, here are some core principles that in my opinion seriously help with adoption of majority of social software.

1. Know who your users are, what they need, and which of their pain points you can address with your solution.
2. Plan and execute on your adoption strategy – broad adoption very rarely happens on its own
3. Run pilots and early adopter programs, targeting people who really care about the problem space. They may be harsh in their criticism, but their feedback is invaluable, and once you get them on board they become your most active promoters.
4. Build and nurture an active community around the system you introduce.
5. Define a clear set of metrics and track them meticulously all the time.
6. Expose your new solution in the contexts where your users currently operate. New shiny destinations can be tempting, but users don’t have time to go too often out of the tools they live in.
7. Identify the most successful customers and give them stage to tell their story to others.
8. Show the way for your users. The benefits of a new system are much better understood when someone articulates them for you.
9. Walk the talk, i.e. use your solution every day to do some (better yet, a lot of) real work – you’d be surprised how much you learn when your own deliverables depend on the system you thought was perfect for others.
10. Be flexible and adjust as you go, based on the trends you observe and user feedback you receive.

Note that this list (an extended version of which can be found here) is about adoption; it does not cover many things you need to take into account to design and build the system.

When it comes to social software, broad adoption is paramount. More critical than features, it can make a clumsy simplistic system more successful than its sleek feature-rich competitor. But getting to that shiny Emerald City requires walking the yellow brick road, since people need a reason and time to change their habits. The most interesting part about that journey is that while your users will undoubtedly learn something along the way, the person who will learn the most is you.

Enterprise 2.0: A Great Concept Often Taken Backwards

Although 2.0 memes are everywhere, hardly any of them have generated as much controversy as Enterprise 2.0 (a.k.a. E2.0). Introduced by Andrew McAfee in 2006 and later expanded by others, the term seemed to be a slam dunk for a while. Forward-looking and fresh, it was (and still is) about application of social software and corresponding approaches in business. However, somewhere along the way something didn’t go quite right. Today, almost three years after the term’s introduction, there is more confusion about it than there was two years ago. Heated terminology discussions keep going on. Key players are on the quest to find and articulate ROI. And most curiously of all, many business decision makers who decide to dive into the E2.0 sea, often come back more confused than they were before taking that dive.

AIIM’s year-old survey, which found that 74% of surveyed organizations had no idea what E2.0 meant or how it could be meaningfully applied, likely would’ve come back with a similar numbers today. This time around, it also would’ve included people who looked at E2.0 tools only to get puzzled. If you work in or sell to enterprise IT you know what I’m talking about. More likely than not, you have your own example of “now what?” story. As in “So we’ve deployed internal blogs and wikis. Now what?” All of a sudden, software that seems to work so well for millions of people on the internet, fails to make any noticeable difference when used internally. All these stories have the same root cause: as of today, E2.0 is still primarily a vendor space, dominated by ISVs selling software to businesses who haven’t really asked for it. It is simply not a demand-driven market. By contrast, just think of CRM or payroll software. You don’t need to convince businesses they need that.

This is why E2.0 ROI discussion keeps going on like a never-ending story. A thirsty person doesn’t care about the ROI of buying a bottle of water – and even paying a premium for it. But try selling to him a cute new gadget – and you better have some very good supporting arguments on why it’s a smart way to invest a single cent. As enterprise customers look for cutting costs and streamlining processes, ISVs along with internal E2.0 champions often offer them what seems to be a miracle pill. It promises to make their workforces way more productive, their executives much more informed, and their customers happier. And, given the loud buzz around social, many companies do give it a try. Some like it. But some end up with a loud huh? Worse, some end up with an outraged response from the people who think it’s a wrong way to spend money (like an Oregon county’s chair who recently posted a 70K per year social media coordinator position). Why? Because, in a Benjamin Button fashion, many customers – often encouraged by enthusiastic sellers – think about E2.0 backwards, starting with tools instead of concentrating on specific business problems.

It Takes More than Social Software to Become an E2.0 Company

No one (okay, almost no one) expects that buying a word processor can turn him into a great writer. Yet somehow it’s almost widely assumed that deploying tools labeled E2.0 would turn an organization into an E2.0 business. Which couldn’t be further from the truth. Despite all the buzz, E2.0 is first of all a set of principles, not software bits. It is more about business practices and human behaviors than about features. Software with strong social computing capabilities makes it much easier to establish and maintain these practices, but it doesn’t create them on its own, nor does it sustain them.

Social technologies have enormous potential, but to make E2.0 more than a hotly debated buzzword, many players in the space have to shift focus from cool capabilities to critical business functions. This applies to how E2.0 software is developed, how it is positioned, and how it is used. Despite catchphrases like “Facebook for the enterprise”, the much discussed consumerization of IT does not mean emulation of consumer experiences within the firewall. It means taking the concepts behind the amazing transformation of consumer space, and leveraging them to address real business needs. All businesses have to deal with things like customer support, supply chain management, R&D and product distribution. Who makes all these things happen? People. Now, what E2.0 is all about? In essence, it’s about people connections, just like any of its 2.0 siblings. And with the right focus, any business function can benefit from better connections.

There are enough success stories to support this claim. Marketing has already added social media to the must-have part of its portfolio. Customer support organizations have been experimenting with social tools – some quite successfully. Many R&D departments have already discovered that capturing knowledge in wikis can be more powerful than using traditional strict-workflow content management systems. Enterprises around the globe have been finding that Facebook-like employee profiles speed up internal communications. But we’ve just scratched the surface. Real gold is not in the technologies of today. It’s not even in applying the best of breed E2.0 tools correctly. It’s in solutions of tomorrow, designed to solve hard business problems through people-connecting technologies.

Now, there’s one little caveat with everything I’ve just described. Implemented right, social business software and practices have a potential to transform many business functions almost beyond recognition. In other words, they can be quite threatening to organizations that are built around existing processes and tools, and are not willing to evolve. But that’s the topic of another post…

Yuri is a new contributor to the FASTforward Blog – more about him here. This is the first post in the “Connected Enterprise” series. Topics to come: adoption, corporate walled gardens, and more.