While the meat of what I have to say is under #3, I'd like to address all four questions posed:
1. How can this paper target its audience better?
First, one must be clear who the audience is. The fourth paragraph of the paper (post Exec Summary) makes reference to "IT management", so I infer that is the intended audience. I suggest two things: one, clarity of audience would be achieved with a "who should read this paper" statement similar to what The Gartner Group does. Two, the audience should not be IT management, but strategic management and line managers. Addressing IT management presumes the solutions recommended are push solutions out of IT. Addressing strategic and line management presumes a pull construct can be created by showing that audience the possibilities and value of IT supported collaboration tools and techniques.
2. What specific business communities would benefit most from employing Collaboration 2.0 tools?
I will address this question more fully in my answer to your question three by discussing how collaboration tools can benefit managers interested in enterprise social networking, collaborative authoring, collaborative ideation, and collaborative decision-making, among other specific tasks. I am not covering in my essay--but could easily extend my analysis to--virtual meeting management, and virtual project management.
The communities are not bounded by business domain (though different constraints exist depening upon data governance, data stewardship, and data privacy issues). The communities are not bounded by professional domain (though marketing might make very different use of collaboration processes than operations or accounting). The communities are not bounded by business size (though an SMB or not-for-profit might select different collaboration tool suites than a Fortune 500).
The theme--and the white paper I think makes this case--is that collaboration is now mainstream; it is not a niche concept limited to few industries or professional fields any more.
3. How could this whitepaper be improved? What points could be added?
Here are some thoughts.
a. The buzz words enterprise 2.0 and collaboration 2.0 are plays on web 2.0. The latter has, sort of, shared meaning. The two former terms play on that cutely, but do not have crisp definitions useful to a manager trying to make a decision. They are buckets of lots of technologies and business processes, the boundaries of which are very poorly defined. This paper, as written, adds to that quagmire, rather than removing the reader from it.
b. So, I'd like to suggest to you some definitions that might help. First, I encourage you to clearly differentiate communication from collaboration. I define the terms this way:
Communication is the exchange of information. This definition has been with us a long time, is universally understood, and is shared across many academic and practitioner disciplines.
Collaboration is the participatory building of information. This is my definition, so it is new. But it is useful in differentiating communication tools from collaboration tools (and we have to do that if we want to talk about Collaboration 2.0.)
Communication tools, then are tools that support the exchange of information. Email is a communication tool. Email is not a collaboration tool; at least it is not an effective one as the user is trying to collaborate (build information structure) using a communication tool. We have lots of communication tools out there from circuit switched phones to email to IM to SMS to LotusConnect (to bring this back to IBM). All of these tools support information exchange. None of them are designed to support information construction.
We also have lots of collaboration tools. GoogleDocs is a classic tool by which multiple people can collaborate to build a document. A multi-user mind mapping tool is a collaboration tools. A networked based installation of MS Project fits.
Notice, that some "products" do both communication and collaboration. Some vendors have recognized that bundling tool concepts together (Swiss Army Knife-like) makes them more salable products. So the fact that Skype (a package of about four communication tools: VoIP, VTC, IM, and file transfer) also support plugins that enable collaboration simply makes it a workbench that exists in both arenas.
If you accept this diffentiation, and I hope you do, then we might ask: what differentiates Communication 1.0 from Communcation 2.0. And what differentiates Collaboration 1.0 from Collaboration 2.0?
I'd like to suggest (and I am just brainstorming here) that Communication 1.0 (assuming we are talking about IT communication tools, not pencil and paper) were tools that were protocol specific. You could only communicate if someone on the other end had access to the same protocol. Communication 2.0 tools are tools that can interoperate across protocols.
This would suggest that what we call Unified Communication might also be called Communication 2.0.
If that is the case, what is Communication 3.0? Along the same lines of Web 3.0 being the increase in intelligence (KM, agents, etc.) to tools, I suggest Communication 3.0 is the advancement of intelligent message handling. Gmail's new priority mail interface would be an example of this.
Collaboration 1.0 and Collaboration 2.0 do not map the same way. Here is how I suggest we think about it. Collaboration 1.0 (of IT tools) were horseless carriages. They simply automated work processes that existed before IT; they didn't change the way we do interactive work. Collaboration 2.0 moves beyond horseless carriage to imagine new ways of doing interactive work that were never considered before IT. I can describe this with examples from different specific collaboration domains.
Collaborative Ideation: The first generation of online tools for ideation were horseless carriages. They took offline processes (think brainstorming or mindmapping) and leveraged software functionality to those processes them slightly more efficient. Ideation 2.0, then, would break beyond the horseless carriage stage and creating interactive collaborative processes that were not imagined pre computer network to leverage much more effectiveness.
Case in point: Electronic Brainstorming (found in the Group Decision Support Systems literature) improved productivity over traditional (Osborn) brainstorming by maybe 15% or so (Fjermasted's meta-analysis found mixed results over the first 15 years of research) by automating what had previously been done manually. This was Collaboration 1.0. But in the late 1990s those of us working in this area started developing ideation techniques were never considered pre IT. Directed Brainstorming (a set of particular process rules that weren't practical pre networked IT), for example, is almost 200% (three times) more effective than traditional brainstorming! The technology for this is simple; it is the process that the technology allowed us to discover there the real gains lie. This was Collaboration 2.0.
Incidently, a product called GroupSystems for Windows, which no longer ships, well supported Directed Brainstorming. No currently shipping commercial product does, though one can cobble out a rudimentary process with available tools. There is a distinct market opportunity here for someone. IBM had a product in this area called TeamFocus, but I think it has long been decommissioned. Note that you could put TeamFocus in my hands as a meeting leader and I could lead either Collaboration 1.0 or Collaboration 2.0 processes with that product, depending on how I deployed it. Of course, one might update the product to optimize for discovered Collaboration 2.0 processes.
Decision Making: Similar to ideation, many collaborative decision making techniques existed pre IT. Consider multi-person multi-criterion decision modeling where each member of a group grades several alternatives over several criteria. This can be done without IT, but is much more effective using IT to capture and tabulate votes in real time. Further, a collaboration tool that permits group members to discuss each cell of the matrix (think of it as an NxM IM chat tool), and use that discussion data to inform their votes has ramped up possibilities well beyond what was possible pre IT. I'd consider all of this Collaboration 1.0 (and TeamFocus, I believe, supported this or something similar). Again, I note, there are no shipping products at any price point that do this today, though ThinkTank and a few others come close.
We can take this process a step further and ask each group member to explain her vote in text. Then, should we decided to post (probably anonymous) vote results to the group, the tool might permit drill down into each cell allowing all group members to see vote rationale by choice (but not by individual). Further, if the cells indicate variance among the votes--products that have done this use green for low variance and red for high variance--then a meeting leader can focus the group on one cell and talk through differences making use of the text discussion, and vote rationale available. At this point the tool is afforded several process steps absolutely impossible pre IT and this is a Collaboration 2.0 tool (again, no product does all this, but some shipping products do different parts).
Allow me to digress for a moment. If GroupSystems or Facilitate.Com (which currently have products in this space) or IBM or Cisco (which could easily ramp up a product offering if they were interested) built an .exe platform at a price point of say $1000 a seat targeted at large enterprises to do what I've laid out here, that would be an example of an Enterprise 2.0 offering of Collaboration 2.0 product. If any of these firms (or any start up) were to roll this out as a SAAS model at a price point one or two orders of magnitude lower, that would be a Web 2.0 offering of a Collaboration 2.0 product.
Back to my main point.
Collaborative Writing: The collaborative authoring literature discusses three basic techniques: Serial, Parallel, and Reciporcal authoring. MS-Word (and Lotus Symphony, to keep this IBM centric) well support serial authoring where one author drafts and hands the document off to another author who edits or continues drafting. The tool make color code (or otherwise indicate) authorship. Serial authoring
The standard word processing tools (but Word Perfect in particular) also support parallel authoring. This is where separate documents can be created and then merged into a master document. It is only the most recent tools (Google Docs, for example) that well support reciprocal writing. Reciprocal authoring is where sections of a document can be checked out for write access, but the entire live document sits in a single location and all authors have complete read access.
Parallel and Serial authoring took manual processes and automated them. This was Collaboration 1.0. Reciprocal authoring is not practical manually, so these processes may be Collaboration 2.0. But the true 2.0 breakthrough will come when facilitative (role and step-based) writing processes are embedded in these reciprocal tools - no currently shipping product has ever done this to my knowledge.
Enterprise Social Networking: This category suffers from a poor name. For the last 18 months I have been calling this category "Strategic Networking" or "Enterprise Strategic Networking" as it only makes sense for an organization to invest in both the org change and the technologies required (and it does take both) if there is a distinct strategic benefit for doing so. I believe in many (most?) organizations there is. The network must be structured to make available information about participant skills, knowledge, and talents. The organization must tie the role of the individual in the network back to projects, initiatives, and tasks and are directly tied into the strategic goals of the organization. It is possible to do this with some of the walled garden social networks currently shipping (but they may not do so out of the box). All this takes a significant org change effort. And sustained use must be tied to direct or indirect incentives for regular and honest participation (doable, but not an easy task.) There are many significant barriers, among them the security model for the strategic network system (who sees what information and in what context?)
Let's consider Facebook, LinkedIn, and simple Ning networks to be strategic Networking 1.0 and the potential I lay out above (I think Cisco may have something that sort of does this--and it appears to be on the Lotus roadmap) to be Strategic Networking 2.0. Perhaps this is a subset of Collaboration 1.0 and 2.0.
This same sort of analysis is possible with virtual meeting management, virtual project management, workflow, and several other collaboration sub-categories.
The IBM paper gets into none of this. In fact, few commentators out there get into much of this.
My hunch is that Lotus (now IBM) came out with Notes about two decades ago and built their tools suite and consulting model around what they had. So they got into workflow, document management, and messaging. There was a lucrative business for it, so it made sense. But it left them in a conceptual flatland where they weren't (aren't) seeing much more opportunity. LotusConnect is a communication tool.
Microsoft followed. They bought Groove, but had no idea (that I can percieve) what to do with it. They developed SharePoint as a Notes killer (or something like that), and got sucked into the same flatland. LiveMeeting has a nice feature set, but is a communication tool, not a collaboration tools
Cisco has come at the problem by thinking about: How can we sell more bandwidth? So WebEx and Telepresence make sense to them, but this is simply a different communication flatland. They use the term collaboration to mean what I view as unstructured communication.
I too am probably on a flatland that is GDSS centric. The real advances are going to come when people from all of these flatlands get together and view collaboration in three or four dimensional conceptual space.
Hope this #3 discussion has been helpful.
4. Given the recent demise of Google Wave, what lessons can be learned for collaboration software providers?
Several lessons, none of them new.
a. Sometimes the victory goes to the second wave, not the first wave (no pun intended). Google broke some new ground with Wave and what we have seen will not go away. It will be tweaked by Wave open source developers or head on competitors and many of the concepts will return.
b. Great user interface is necessary (and Wave may have suffered a bit on this front), but clarity of purpose is even more important. It was not clear to most early adopters just what problem Wave was supposed to solve for them. I suspect had the full envisioned product ever rolled out; had 3rd party developers ramped up some great collaboration add-ons, then the potential for Wave might have been evident. But too many early adopters looked at the feature (and interface) poor alpha version and asked themselves, "what is this supposed to do for me that I can't already do?"
c. Related to that, Google dug a hole for itself (as best I can determine from press reports) in that they were caught flatfooted by the bandwidth required to provide full multi-cursor text editing to masses of people. Their product just didn't scale; or perhaps they released a bit too soon.
Further, it made no sense from a user perspective that Wave couldn't interoperate with gmail. It looks like Google had some sort of architectural problem that prevented interoperativity. This problem significantly limited the real world usefulness of Wave out of the box.
d. Google didn't seem to fully grasp (even though they did a great job of it with gmail) that collaboration software requires critical mass to be viable. Wave got out there without the critical mass and users simply did not find it viable. If one compares this rollout to gmail, there are several differences to this point. One, gmail was not a conceptual leap for users. They understood Hotmail, and AOL mail, and Yahoo Mail, etc. So it was simply a matter of deciding whether Google's interface was better. Two, gmail interoperated with all these other mail platforms, so there was instantly a critical mass of people to email with; Wave was its own sandbox. And three, they didn't give Wave long enough to naturally develop out to critical mass.
Given the first points raised about architecture, interoperability limits, and confusion of what Wave was, perhaps it made sense to pull the plug rather than give it another 12 to 36 months. But that amount of time would have been required for success. I guess point D lesson is patience.
Been studying group support systems, CSCW, virtual meetings, and strategic networking for about 20 years now. My (and my students') blog is http://www.cdmblogs.net/virtual