July 23, 2007
A Working Knowledge of Wikipedia
HBS's research newsletter, Working Knowledge, has an article today about my experiences with Wikipedia's Articles for Deletion process around the "Enterprise 2.0" article, and the freely available online HBS case my colleague Karim Lakhani and I wrote about it.
Sean Silverthorne did a great job asking me and Karim the right questions, then making our responses sound coherent. In addition to asking us about the case study, he also questioned us about corporate use of the wiki technology. This discussion comes at the end of the article.
Take a look and tell us what you think. How big a danger, if at all, are adamant deletionists to Wikipedia? And what lessons should companies take away from this lesson, and from Wikipedia more broadly?
By the way, I notice that as of right now (4:05 pm EDT on July 23, 2007) Wikipedia has separate articles on "Enterprise 2.0" and "Enterprise Social Software." The last time I checked, this was not the case -- a search for "Enterprise 2.0" redirected the user to "Enterprise Social Software." I'm happy to see an Enterprise 2.0 article as part of WP. I don't know if the 'right' answer is to merge the two articles or do something else. All I know is, I'm staying out of this one...
July 18, 2007
Cases2.com, the Enterprise 2.0 Repository
I'm excited to announce that cases2.com, the Enterprise 2.0 repository, is now up, running, and open to everyone. Sincere thanks are due to my friends at Socialtext, who grabbed the domain name and volunteered their wiki software (disclosure: Socialtext lets me use their software for free, but I have no financial interest in the company and have done no paid work for it.).
At present cases2.com consists of a case template, five cases, and not much more. So please contribute to it. Socialtext's wiki software supports WYSIWYG editing and is, I'll vouch, very easy to use. You don't need to be any kind of markup language expert to add content, links, images, tags, formatting, etc. You'll need to register before you can start contributing, but registration is painless and immediate.
If you know of an E2.0 case study, please enter any and all details. We don't care if you were directly involved in the project or not, got paid for it or not, etc. We simply ask that you be as honest and forthcoming as possible, cite sources where available, and disclose your relationship(s) to the companies involved.
This last point is critical. It's fine for a vendor or consultant to add information about one of their cases, and it's fine if that information is not verifiable from objective and/or published sources. It's essential, though, that contributors correctly and completely identify themselves and their relationships so that readers have the information necessary to make their own judgments about possible biases.
Beyond this, I really don't have many groundrules in mind as the site launches. I hope that contributors are respectful to each other, and that flame wars and trolls don't appear. And most fundamentally, I hope that lots of people contribute here, and that the case library fills up quickly. So please dive in -- be bold and be active, and let's see what emerges.
July 11, 2007
It's Not Not About the Technology
One of the most common phrases I hear in discussions of
any type of IT initiative, from Enterprise 2.0 to ERP to systems integration, is "It's not about the technology." I've heard this from vendors, consultants, technologists, executives inside and outside the IT function, analysts, pundits, and academics. Searching for the exact phrase yields about
1800 results on Google Blog Search,
17,700 on Google Web Search, and at least
one book title. I'm sure I've said it myself a few times, although I try not to.
People usually mean one of two things when they say INATT; one of them is correct but somewhat uninformative, and the other conveys a lot of information, but is incorrect and even dangerous. The correct-but-bland meaning is "It's not about the technology
alone." In other words, a piece of technology will not spontaneously or independently start delivering value, generating benefits, and doing precisely what its deployers want it to do. Technologies have to be managed in order to do any of these things; they're not
magic bullets or miracle cures.
This version of INATT is clearly accurate, but how often, and to whom, does it need to be said? I very rarely come across anyone these days who thinks that technologies
are magic bullets. All the companies I work with know from ample experience that IT efforts need to be managed. They may not handle their deployments perfectly, but they're well past the stage of setting out a new piece of IT, then sitting back and waiting for the benefits to accrue. This version of INATT might be a useful reminder to managers who are underestimating the amount of change management required to succeed on a given project, but it's not really news to them.
The other meaning behind INATT is "The details of this technology can be ignored for the purposes of this discussion." If true, this is great news for every generalist, because it means that they don't need to take time to familiarize themselves with any aspect of the technology in question. They can just treat it as a black box that will convert specified inputs into specified outputs if installed correctly.
This perspective is dangerous because it essentially denies two important facts: that technologies can differ from each other in salient ways, and that they can change over time. Losing sight of either of these can lead to confusion, or worse. For example, it's well established that IT can help integrate the enterprise, but do they all do so in the same way? INATT, taken to the extreme, would cause a company to treat IM and R/3 the same way (after all, they both integrate the enterprise and enable business processes). A lot of my work, for example
these articles, is an attempt to articulate the managerially relevant differences across technologies. The second version of INATT encourages listeners not to keep such differences in mind, and I think that's the wrong idea.
INATT, version 2, also encourages the view that there's nothing new under the sun -- that one generation of technology aimed at addressing a business problem is the same as all other generations. So (for example) we need to collaborate and share knowledge better, but it's not about the technology. We've been disappointed with our past results in these areas for reasons that have nothing to do with the technologies we were using, and there's nothing about any new technologies that gives us better chances of success now.
This sense of INATT is pessimistic and self-defeating, even if it's not intended to be. It denies that there can be improvements, incremental or radical, in the ability of technologies to accomplish important goals. I disagree categorically with this. A lot of my writing on Enterprise 2.0, in this blog
and elsewhere, has stressed that the IT toolkit available to help with collaboration, innovation, and knowledge sharing has recently become a great deal richer and better. This was also one of the
points I tried to make in my recent
debate with Tom Davenport. INATT works against my goals in this area, and I've started to cringe when I hear it.
Sometimes, at least in part, it
is about the technology.
July 06, 2007
The Enterprise 2.0 Repository
In my morning keynote at the recent Enterprise 2.0 conference I proposed the creation of a repository of enterprise 2.0 case studies that would itself adhere to E2.0 best practices -- it would be freely editable and extensible, and have an emergent rather than an imposed structure. I heard expressions of interest in the idea throughout the rest of the day, and when I sat down to dinner with my friends from the enterprise wiki company Socialtext they volunteered their software and told me they'd already grabbed a great domain name -- cases2.com (disclosure: Socialtext lets me use their software for free, but I have no financial interest in the company and have done no paid work for it.).
So now we need to populate this site with all things enterprise 2.0, and we need some help getting started. Cases2.com will be publicly available soon, but it's not yet. When we open it up, we'd like to have some compelling initial content. We need a first set of case studies that will perform the same functions as the first few dollar bills in a tip jar: encouraging others to contribute, and showing them how.
If you have a good E2.0 case study or two and would like to share your experiences, please email me (using the button at the top of this page) and tell me a bit about it. If it sounds appropriate, I'll send you a username and password for the current private version of the site. Please use the template you'll find there to enter the details of your case study. And if you think the template isn't doing a good job of capturing the important aspects, isn't sufficiently user friendly, or could be improved in any way please use the site to suggest modifications.
Once we get enough cases up, we'll open up the site to the entire Internet and see what happens. My grandiose vision is to have cases2.com become the clearinghouse for information from the front lines on this topic. I'd also consider it a good thing if the site came to contain information on E.20 vendors, consultants, writers and writings, etc., but let's start with case studies. Let us know if you want to share one.
