Drop the pilot?

Via Rocket Watch, do you need to pilot the roll-out of enterprise-esque, Web 2.0-ish collaboration tools? Michael Idinopulos of SocialText says no:

But social software is different from traditional IT. Traditional IT enables individuals to carry out well-defined, highly standardized transactions. Users go into the system to process transactions--to transfer funds, purchase supplies, track inventory, etc. The nature of these transactions, and the system's ability to enable them, do not vary much according to the number of people using the system. Whether 100 people are entering orders or 10,000 people are entering orders, the transactions themselves doesn't really change. What that means is that a representative small-scale sample is an accurate predictor of adoption and value at full scale.

Idinopulos starts the post by saying, "Get out your pitchforks, I'm about to commit Enterprise 2.0 heresy." If he detects the smell of torches, or the clatter of pitchforks, it's not because his argument is heretical. (As you might guess, I have a lot of sympathy for heresy.) Instead, his argument overlooks the adoption process for collaboration tools.

Idinopulos' argument breaks down at the following points:

• While "traditional IT" (ERP, etc.) focuses on transactions, social applications focus on interactions. If you have ever had to deal with a rejected expense report, or negotiated a deal with a client, or handled an internal audit, you'll quickly appreciate the lack of clear boundary between "transactions" and "interactions." In reality, work is a combination of well-defined tasks, such as closing the books on the quarterly financial statement, and the large amount of collaboration needed to get those structured activities finished.
• Collaboration is separate from "traditional IT." As the previous bullet implies, there's not a clear boundary between the two. In a business setting, people aren't collaborating for the sake of collaborating. Instead, they're trying to get work done. In a Microsoft shop, a SharePoint or Exchange administrator might not see these other activities, or the applications involved (CRM for sales, document capture for contracts, etc.). However, those files, e-mails, and other unstructured content are part of a larger business process, not the whole business process itself.
• Collaboration has no specific shape or form. "This is the way we communicate new releases to customers in this company" is one of countless examples of how institutional factors constrain activities. So, too, do individuals themselves, who have habits, preferences, past experiences, lessons learned, and a limited amount of time and patience for experimentation.
• Adoption depends on the tool. Idinopulos argues that some social applications, such as Wikis, require more up-front work to make them useful than, say, micro-blogging. However, that's hardly the only variable, and it's not necessarily the most important one. Sure, as a customer service rep, it's easy to post a thought about how to deal with difficult customers via the company's Yammer account. However, you can't put much into that thought, and certainly, for someone looking for advice, it's harder to sort through a bunch of micro-blogging posts than a well-organized Wiki. The business argument for using a collaboration tool, as either a contributor or consumer, is just as important a determinant of adoption as the difficulty of using the tool itself, or the amount of content needed to get it started.
• For a new collaboration technology to be successful, you need to start big. Idinopulos cites Metcalf's Law, which "famously states, the more people there are in that network...the more value that individual derives from participation in that network." And, Idinopulos argues, it's hard to predict from a small pilot how other individuals or groups will use the technology. Unfortunately, people are not Christmas tree lights: you don't just string all the nodes together, stand back, and say, "Ooooh, impressive." Some people may figure out the value of the tool on their own, but for those who don't, a few good business arguments and use cases discovered during the pilot can be very convincing.

The very fact that you can't always predict all the use cases for a collaboration tool is the very reason why, in many cases, you need some use case as an illustration, even if it's not your own. Collaboration tools don't manufacture use cases; they create the means to address these scenarios in new ways. For example, I'd love to stay in touch with everyone that I've ever known. LinkedIn and Facebook just make it way easier to do so.

Social networking, Wikis, blogs, forums, micro-blogging—these are great technologies to address human wants and needs in novel ways. In the workplace, the communications and activities they make possible are connected to business processes.

Of course, IT people can get in the way of projects, deciding on behalf of employees the "proper" use of collaboration tools. Of course, you can smother some projects by making them too small. You can also ensure the failure of the very same projects by making them too big, if you throw new technologies in people's faces and expect them to figure out the use cases, and work out all the kinks of your technology, on their own.

Comments

[blog health style]

was very encouraged to find this site. I wanted to thank you for this special read. I definitely savored every little bit of it and I have you bookmarked to check out new stuff you post.