Wikipedia administrator Sj has posted what appears to be the final word on the debate about deleting the Enterprise 2.0 article:

"I want to highlight a comment by Amcafee which cuts to the heart of the matter, and point out that there is almost no content about the topic at hand, and only discussion of the term — which many (including the coiner) have commented is a) the source of neologism trouble and other confusion, and b) not necessarily the best term for the topic in the long run.

[Amcafee's (in other words, my) comment, in response to Wikipedian Fairsing, was:] Fairsing, thanks for the response. I want to make sure I understand your position, and to do so it’ll be helpful to me if we leave out the term ‘Enterprise 2.0′ altogether. Is it your position that the use-of-brand-new-collaboration-and-communication-technologies-within-organizations development we’re interested in fails to meet one or more criteria for inclusion as a stand-alone entry within WP? If so, what policy or guideline is being violated? Is it verifiability, despite the references listed above? Notability?? Or something else?Amcafee 04:39, 28 August 2006 (UTC)

I hope that we can all get around to writing a great article about this topic and beyond debating over the name. I propose Enterprise social software as a working title for the time being, to be changed over time as necessary. +sj + 23:59, 29 August 2006 (UTC)"

I suggest that we do exactly as Sj suggests, and that to flesh out the article in advance of posting it to Wikipedia we use the enterprise wiki set up in the wake of our Wikimania panel (irony aficionados will be happy to learn that the panel accepted at Wikimania and the article rejected by some Wikipedians were about the same set of topics).  I’ll get to work on this over the weekend.

We now resume our regularly scheduled blogging…

Update 9.1.06:  Turns out that the final result of the ‘Articles for Deletion’ process for ‘Enterprise 2.0‘ was keep.  This means that the article with this title will persist, and that we can modify it over time without having to further justify its existence.  Good news!

Thanks to Ross Mayfield’s excellent work and at least one judicious Wikipedian, the Enterprise 2.0 article has been restored.  It is, however, being considered for deletion.  If you believe that this topic belongs in Wikipedia, please weigh in on its ‘articles for deletion’ entry.

Every vote counts, so please take a minute to chime in (respectfully) on this .  Let’s get ourselves a not-in-danger-of-deletion-anymore entry that we can refine over time, in keeping with Enterprise 2.0 best practices!

Ross Mayfield has done the heavy lifting of reviving the speed-deleted (ow!) Wikipedia entry on ‘Enterprise 2.0.’  This provides us an opportunity to get it right and re-post it, or perhaps ask that it be submitted to a vote.

As we work on this, we’d do well to keep in mind the reasons that it was deleted.  They include the fact that Enterprise 2.0 is a neologism, and Wikipedia’s guidelines say that entries about neologisms must be more than just definitions, and must not consist of original research.  The guidelines are pretty adamant on the latter point; given the volume of print and online material on Enterprise 2.0, we clearly don’t need to do any original research.

The other objection mentioned during the deletion process has to do with the noteworthiness or notability of the term.  I find this confusing, because I’ve never understood Wikipedia to have such a criteria for inclusion.  The closest I can find is this excerpt from the list of what Wikipedia is not, and I think we avoid all of these easily.

So what should an encyclopedia entry on Enterprise 2.0 consist of?  Here’s my proposed outline, which I promise to work on sometime soon.

Definition(s)
List of proposed E2.0 technologies
E2.0 and the concept of emergence
    Claims made for the difference between E2.0 techs and previous techs used for collaboration w/in companies
Evidence of E2.0 in practice
Controversies
    Is E2.0 about architecture (SOA, SaaS, etc.) or communities / users
External references

This is, of course, just a suggestion.  But let’s get this done and accepted by Wikipedia one way or another so that we and others can then use it.

My post last week describing why I’m opposed to using quantitative, ROI-based business cases to justify proposed IT investments generated reactions ranging from support to condemnation to requiems for HBS.

Expressions of support reinforced a couple of the points I was trying to make in the initial post:

• For the majority of technologies, even the most rigorous and objective IT business cases are exercises in speculation and attribution.  They not only anticipate benefits, they also ascribe all these benefits to the technology and none to the individual-, group-, and organizational-level changes that simultaneously occurred.  
• Most IT business cases are something less than rigorous and objective.  Lots of people get paid to generate them, or get paid based on their rosiness.  I have a friend who used to work on ‘pre-sales opportunity assessment’ (or some similar-sounding activity) for a major vendor of supply chain software.  His job was to prepare and present business cases showing the prospective customer how much better off they’d be if they bought the system.  We were out one night and I asked him "how many times did your assessment conclude that the company actually wouldn’t benefit a huge amount from purchasing your software?"  He just smiled and bought me a beer.  I imagine that most of the people whose paychecks and commissions depend on ROI-based business cases want to continue to generate them.
• At their worst, IT business cases are like Soviet five year plans —  devices used by competing groups to come up with bigger numbers than each other in order to secure funding and avoid harsh scrutiny.  

Those who disagreed with the initial post argue that it is in fact possible to accurately describe and ascribe benefits, and that it’s an abandonment of management’s fiduciary duty not to try.  After all, this argument goes, savvy companies don’t start other capital investment projects without first building an extensive, quantitative business case.  

This is true, but these same companies also typically spend money on advertising and/or R&D.  And very few of them say things like "our analysis shows that if we drop our sponsorship of Wimbledon and sign up Scarlett Johansson as a spokesperson we’ll save $3 million and increase sales 4.6% among 18-24 year old males" or "we spent $400 million in our labs last year and introduced 8 new pharmaceuticals into the market.  So if we spend $500 million next year, we’ll get 10 new drugs out."

So it’s just not accurate to say that companies only make large investments once they’ve done an ROI calculation.  In some of the most critical areas of the business, in fact, they do something close to the opposite.  They discuss budgets, goals, and desired outcomes, but not projected ROIs.

 IT looks very much like a standard capital investment —  a company pays cash and acquires an asset, whether that asset is a server and a CD full of software, the right to access a system over a network, etc.  But this money-for-assets exchange is only surface level activity.  The real phenomenon of interest is the attempt to acquire an IT-based capability, just like advertising is an attempt to build a brand and R&D is an attempt to innovate.  Each of these attempts requires sustained management attention, not just a periodic bakeoff among business cases in which the highest ROI figure wins.

SAP’s Thomas Otter, in a comment on my original post, asked an excellent question:

My MBA students who have experience trying to buy or sell corporate IT ask the same question.  They’ve seen that the ROI-based business case is the current tool of choice, and ask me what it can or should be replaced with.  I counsel them to put together a business case that has three main elements:

1. Costs and timelines.  The cost portion of the cost/benefits analysis can and should be calculated with all due precision.  As I wrote before, the cost breakdowns of most types of IT effort are pretty well understood by now, and should be laid out in advance.  So should the best initial guess about how long the whole effort will take, how it will be segmented, and what milestones will be reached along the way.  When doing this, it’s important and smart to acknowledge the great uncertainty inherent in both anticipating costs and timing, especially for large and complex projects.  I’ve been working for some time now with a large utility that’s putting in several new enterprise systems.  The leader of this project is a respected senior non-IT executive.  When he first presented the project to his peers, the CEO, and the board he told them to expect that some of his future reports to them would include notifications of delays and requests for more funds.  Sure enough, they did.  The combination of his reputation, his initial honesty, and the fact that the project was clearly making progress ensured that news of additional costs and delays was taken in stride, rather than providing an occasion for a freakout.  
2. Capabilities anticipated.  I describe enterprise IT’s capabilities as monitoring, standardization, and process design, network IT’s as collaboration, judgment, and emergence, and function IT’s as experimentation and precision (I have an article coming out in the November issue of Harvard Business Review describing these technology families and their capabilities in more detail.).  Capabilities are not as low-level as feature sets, but not as high-level as some of the promised results from IT like ‘organizational transformation’ and ‘customer intimacy.’  They provide a foundation for a concrete discussion of IT outcomes that doesn’t rely on knowledge of any specific vendor’s offerings.
3. Technology footprint.  A technology’s footprint is its geographic, divisional, and/or functional reach.  It’s a description of how much territory a piece of IT is intended to cover.  Network technologies tend to have large footprints (how much territory does email cover?) and ones that are easy to expand.  Function technologies tend to have fairly small ones; a CAD system isn’t that useful outside the engineering department.  Enterprise technologies like ERP and CRM can have small footprints, or very large ones.  Their complexity, and hence cost, goes up geometrically with footprint, so their borders should be set carefully.  

 Cost, capability, and footprint are, in most cases, sufficient information to allow business leaders to make IT decisions.   They also provide a basis for prioritizing IT initiatives, something many companies struggle with.  Is it more important for customer interaction processes to be standardized across all business units, or for vendor interaction processes to be?  Is it more important to change how engineers collaborate, or to give them better tools for experimentation?  These are not easy questions, but they are important and appropriate ones for leadership to discuss.

Walking away from ROI-based business cases does not mean walking away from careful thinking or analytical rigor.  It doesn’t mean spending like a drunken sailor on IT.  And it doesn’t mean abandoning any important management duties.  It instead entails acknowledging that IT is a lot more like R&D than like a new machine tool, and that reliance on big ROI numbers is both a shortcut and a dangerous addiction.

It is, however, a pretty deeply entrenched practice.  If you’d like to move your colleagues and your companies away from it, I’d suggest starting by having people read Kaplan and Norton’s Strategy Maps.  And perhaps a couple blog posts…

Mike Stopforth has done the yeoman’s work of starting a Wikipedia entry on Enterprise 2.0.  Even though I just posted about how the barriers to contribution with wikis are vanishingly low, I still think of this as a milestone.  I hope it survives and grows; Wikipedia’s Web 2.0 entry is an extensive and helpful one, so why shouldn’t the Enterprise 2.0 one be?

I haven’t decided yet if I’m going to contribute to it (that might be too much of a vanity project) but I hope others do, and that it becomes what so many good Wikipedia entries are —  a dynamic source of solid information and a clearinghouse for external references.  Please help it get there!

Our panel yesterday at Wikimania was great fun.  I was amazed at how many people were willing to drag themselves out of bed on Sunday and get to a 9:30 am panel on the use of wikis within organizations, a topic that is not (yet) near to everyone’s heart.

My new HBS colleague Karim Lakhani did an admirable job riding herd on the panelists and encouraging lots of dialogue with the audience.  He and I want to thank our panelists Josh Bancroft , Ned Gulley, Michael Idinopulos, and Ross Mayfield

I’m sure they’ll be blogging about their impressions, and after the current round of conferences I’ll post more here about the common themes I saw.  For now I just want to share a couple quick post-panel impressions and some news.

Perhaps the best part about an event like yesterday’s is when you see something new —  when you have an I-never-thought-of-it-that-way-before moment.  For me, that came when I listened to people talk about the many different ways there are to contribute to an organization’s wiki, from authoring to editing to gardening to correcting spelling mistakes.  The discussion made me realize that for all the emphasis I’d placed on the freeform nature of Enterprise 2.0 technologies, I’d missed one important way in which these tools get out of the way of their users:  they don’t have any notion of what constitutes a good contribution, or a complete one, or an approved one, or a minimum one.

I can see at least two important positive implications of this non-judgmental attitude toward contributions.  First, people with many different talents and proclivities can meaningfully pitch in.  In other words, wikis aren’t just for subject matter experts and those who can write lapidary prose.  They’re also for information architects, fact-finders, nitpickers, linkers, taggers, etc.  Prior to Enterprise 2.0, these folk had virtually no opportunity to influence their companies’ digital platforms unless they worked in the Intranet group.  

Second, people don’t have to dive headlong into making contributions.  They can instead dip a toe in the water by doing something as minor as correcting a spelling or punctuation mistake (of which there are usually no shortage).  Once they see how easy it is to participate they often make deeper contributions.  More than one person yesterday admitted that they purposely misspell words sometimes in order to draw wiki participation.

The problem with accepting all kinds of contributions, of course, is that some of them might not be helpful.  Wikipedians spend a lot of time dealing with vandals, trolls, and people caught up in edit wars.  They also spend a lot of time thinking through guidelines and policies for dealing with them.  So will advocates of organizational wikis have to do the same?

Ross Mayfield said that in four years of building wikis for corporations Socialtext has seen precisely 0 trolls and 0 instances of vandalism.  I was astonished by this and polled the entire room.  No one reported even a single instance of counterproductive behavior on the wiki.  

As I’ve written before, one of the advantages the Intranet has over the Internet is that people within companies share a culture and norms, and are usually quite reluctant to overturn them.  In addition, vandals and trolls can usually be easily identified behind the firewall.  So perhaps I shouldn’t have been so surprised that employees aren’t using corporate wikis to act out.

Ross has generously set up a public wiki to talk about enterprise wikis.  It’s at https://www.socialtext.net/ewikimania  .  What shall we use it for?