I think the scientific community often gets overlooked when we talk about collaboration and software. Granted, they aren't usually early adopters of of things, but I was initially very excited about what something like Google Wave could do for me. Unfortunately I and my collaborators ended up quite disappointed.

I want to try and develop this insight further, but the collaborations in the scientific community range from co-authorship of papers to managing workers and results across time and staff changes and between different laboratories. Information often gets lost or must be redone simply because there isn't a solid central means for people to share digital files.

Robust version tracking and citation ability is a must.

Technical content issues:

The paper kicks off with a large list of capabilities, but it does not directly address how IBM's products meet each of these capabilities.  For instance, "Search", the number one capability, is only mentioned in the list and not in the rest of the white paper.  How can this be considered a valuable technical insight into how IBM's products will help me search if you don't even tell me that they can do that at all?

The paper promotes 3 IBM products, but it doesn't have a subsection for each one.  Instead, it jumps around all over the place trying to discuss seemingly random features.  It looks like someone took the guts of 3 good product summaries and cut, shuffled, and pasted it back together.  I would go ahead and undo that, and put it back as 3 content subsections, one for each product.  I would furthermore list specifically how each product meets some of the listed capabilities mentioned above.

It's a white paper touting a piece of enterprise-level software, but it's a year out of date.  In the high-tech world, this white paper is basically useless now.  I'm sure there is a newer version of this software, or some newer updates at least that would invalidate or alter some claims made here.

No diagrams or working examples of IBM's products delivering what is described.  Prove to me that the files facility "provides a convenient way to share documents".  Without this technical level of detail, this white paper reads like a transcript of a non-technical sales pitch. 

Be very careful specifying availability of software without specifics.  "Available on AIX, Linux, and Microsoft Windows"... but what versions, and with what features?  You can't say that and leave out the details, that's making me have to work to even find out if your product will work for me.  Just tell me so I can tell right away that either yes, I can use this, or no, it will be incompatible with my setup.

I am not sure I would use the "2.0" meme to mean social.  "Web 2.0" refers to social sharing, but "Enterprise 2.0" seems redundant.  Organizations that operate within fiefdoms that have no sharing generally do not get to Enterprise size, so I'd assume that most enterprise-size companies are familiar with the concept that sharing is a good thing.  I think what you might mean instead is "Web 2.0 for enterprise" or something similar.

General/writing issues:

The subtitle is long and confusing.  Consider "The transition from document-centric to people-centric collaboration" or similar.

The footer "Analysis without compromise" has a bullet as if it is part of the paper.  consider tinting the phrase red to match the OVUM logo and/or removing the bullet point and left-side footer slogan  altogether, or put it under the OVUM logo if it is their slogan.

The paper bounces back and forth between different topics with little transitional material.  In one paragraph, it talks about lotus Quickr, in the next, it's Lotus Connectons, in the next, it's talking about a Microsoft product.  (p. 8)

I am still reeling from the comment on in the first line of page 11 of "industry vertical". I think that line needs to be reworked.

However, the paper overall is good, and (as was true when I worked for IBM) shows great care and thoughtfulness.

Some things are overlooked, though the second comment touches on them:

First, accountability. People need to be responsible for their contributions, otherwise they will "munge" the system "just because". I don't see a strong tracking, let alone, citation controls. The system needs to check and recheck on who actually started a thread, otherwise the thread will be appropriated by others.

Next, motivation: the collaboration software assumes everyone will be anxious to contribute meaningfully - in what world? Not this one. One suggestion would be a collaboration overseer (non-threatening) who promptly recognizes contributions (or the reverse) with a sympathetic feedback to the contributor's supervisory structure (WITH THE CONTRIBUTOR'S KNOWLEDGE, and in most cases, consent.

An ideal way (though likely unmanageable) would be in IP. IP as it is often practiced is out of control, and threatens to undermine our economy. Some way of collaborating in swiftly and cleanly targeting these threats would be of great value.

Of course, such a collaboration in IP would mean somehow buying our legislators back from the wealthy corporations that own them, and public financing for our IP system (it is unrealistic to make our system both self-financing and fully dedicated to the public).

Of course, one step at a time. For now, simply forming a collaboration to limit IP abuse would be a very good and much needed thing. How would we finance it? Why not the same way we finance the internet?

The act of any collaboration should begin with a written agreement regarding the I.P. to be created by that collaboration.  Without it, things could get messy especially if the collaboration produces results from which the collaborators want to profit.  In a 7th circuit case back in 2004 involving the comic character Spawn and related characters, the collaborators on those comics didn't start with a written agreement and ended up in messy litigation.  That kind of thing can be solved with a visit to a competent I.P. lawyer.  You can pay the lawyer now or you can pay through the nose to the lawyer later.  Smart people settle things when easiest, at the beginning when things are calm and the act of collaboration lies ahead.

re the IBM blurb....
GO directly to page 7:
  this is what you're selling.     (the social web.)
-----------------------------------------------------------------------

You won't like what I have to say...

I agree that digital collaboration is an important problem to solve. I agree that the solution will be more people-centric and that social sites we see today (Facebook, Twitter, etc) are indicators of the direction that solution will take.

However, this paper tries to brand old concepts (Blogs, Wikis, Bookmarks, Files) as the solution in the future, when they almost certainly won't be. The Lotus and SharePoint suites are antiquated technology just asking to be disrupted. I don't see them taking back the collaborative space.

You can't just point at your suite of technologies and say "this is Enterprise 2.0". You earn that title after the fact.

The problem is that innovation usually doesn't come from the enterprise space. It's too conservative and motivated by money to make innovative leaps.

And though Facebook, Twitter, and Google Docs are on top today, they too will be displaced soon. The thing is, it's not really about the specific brands or applications. It's about the fundamental technical/social insight they exposed. Sooner or later these concepts are absorbed into a new paradigm and the brands are forgotten.

Any programmer could create Twitter in a matter of weeks. Once the idea is out there it becomes trivial to implement. The most difficult thing to achieve is the mindshare and the infrastructure to support the influx of users. That's why cloning doesn't work. There's no reason for users to jump ship from one thing to a clone of that thing unless they're being treated badly by the original site.

I believe the reason e-mail and web sites have lasted so long is that they're open standards that allow cross communication regardless of the brands your organization bought. Enterprise 2.0 won't succeed as a revolution as long as it's built on brands instead of standards.

The collaborative solution that begins the next revolution will be a series of open technologies organized around data distribution & management, identity & authentication, social connections, and be able to support various gui and programming technologies.

If you want a glimpse of the future I would look more to Diaspora than Lotus.

 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.

Reading the IBM white paper, one thing comes out as quite evident: The author has never worked with the tools he talks about. Nor understood the problem they are trying to solve, so he can understand the alternatives.

Electronic collaboration tools have changed little since they were first introduced in the 1980's, still implementing the paper-based routines of the last millenium. While companies are legally forced to do certain things on paper (financial reports, for instance), true collaboration does not mean producing documents. It is telling that software developers do not see any use for these tools, including the Google toolset, to create software. Be it Open Source or otherwise.

The white paper itself is a striking example of corporate fluff which does not help anyone with anything. It does not even market the Lotus tools well.

Regarding the idea itself: It would be great to have this kind of tools. A company can not run on meetings and documents any more. Non-companies, like almost all entrepreneurial projects today, would benefit enormously.

Tools for collaboration today need to go beyond the paradigm of sending paper memos to select groups of people (which is what email is all about). An enterprise needs to move fast, organize ad-hoc groups, and move fast in those groups. Fostering independence of location, but also connecting back into the back-end systems, making flexible resource allocation and budgeting possible, are a must. No systems can manage this today, whether you call them enterprise 2.0 or 3.0. Not even Google Wave did, although it was probably the best effort so far att accomplishing ad-hoc cooperation.

There are constraints, such as being forced by legislation to keep certain documents. It will not be until there is a lawsuit that we can find out if a wave can be a document. But mostly, the constraints are in the minds of people and organizations. No matter how you reorganize, being forced into a straitjacket does not help a company grow, or even use its people more effectively.

Flexwork is another issue. Most people today probably access their email from mobile phones from time to time. Of course it is lousy for viewing large documents. But most of the time the discussion does not take place in, or even around, the documents. Good clients for making it possible for anyone to contribute to a workstream from anywhere at anytime will capture more ideas and make the company more efficient. The problem is probably filtering out input that does not help drive the resolution forward.

Because differently from traditional document-oriented flows, the instant-messaging-inspired flows are open-ended. A document is an endpoint. A discussion does not have one. Yet if your customer has asked for an RFP, then involving them in a wave will not help you get business. It may help afterwards, but the collaboration tools have to cope with this reality. How to build a document using waves and IM is still unexplored, and especially how it could be more effective than doing it the traditional way. Some large-scale experimentation is probably called for, otherwise some Internet entrepreneur will step into the niche.

Then, there are the Facebook-like aspects. How could a company use such a platform to make people work more effectively? If everyone could write status reports about their work, it would save them the tedious writing of monthly reports, for instance. Provided the status reports could be automatically collated. You could even use it to automate time reporting, which would eliminate another tedious task and replace it with one most people are interested in - privately, anwyay.

Security matters, of course. But rather than the old paradigm of keeping information secret until you are ready to share it, the new paradigm is to make everything open until the discussion is finished. How does security systems reflect that?

Not to forget Twitter. An intra-company Twitter would be a great tool for the CEO to spread his message in a big company. But only if he listens to the backtweets. Japanese company Softbank recently wrote a new corporate strategy using internal meetings involving all its 30 000 staff - and Twitter. So it scales. But how do you transplant it to another company? Another country?

There are businesses which work this way, of course. Internet startups today try to do it. If you have grown up on the Internet, even sending emails feels a bit mossy. But in most cases, there are constraints imposed on you by investors and people with "experience". An NGO would be a good place to try, sine they have less formal requirements, and also less mental baggage.

A collaboration software provider today must address these issue. IBM has done more than most - letting people work without email for a year, for instance. What do you learn from that? And how do you build in the required documentation into an ad-hoc process? How do you make the transition from a "document heavy" company to a "communications lite" company? One way would of course be to save everything in a backend server, so that it could be played back. Today it would not be prohibitively expensive.

These are things that the paper should address to be an interesting paper, and not just a bad marketing tool. Hey, why not outsource the writing of the white paper 2.0 to this community?

I have contributed to this (or a similar) insight project before, but since then I have had the opportunity to actually use collaboration software in my business, and it has changed my viewpoint (to more favorable, but with reservations).

First, though, on page 4 it says "leverage the business of value of Enterprise 2.0 ..." - I am assuming it means "leverage the business value(?) ...".

Later on the same page it says "'utility-isation' of core IT services ...". Not at all clear, but I assume it means utilization of Enterprise services.

On page 11 it says "industry vertical". Be nice if that was intelligible, it isn't.

And on page 11, the "mea culpa" is unnecessary. IBM will do great things when the service is fully developed says enough. The way it is written says "don't use this".

Now, overall, Enterprise 2.0 (things like that) are clearly the wave of the future. Everyone else will be using buggy whips in an automobile. However, instead of "in place of" (yes, I know that wasn't said that way) we need to think "with". Email, IM, etc. needs to be integrated into E2.0, not replace by E2.0. Often I want a face-to-face, and I need to know if someone is online, etc. Often I want to leave a post-it for someone I know is in bed/busy/out of town, so I need email, NOT IM or chat.

What I am saying is; NOT off with the old, on with the new, but "we need the old in the framework of the new". We need MORE capability, not just a different capability, and at times paper/email/phone (well, not sure about that)/simple drop off (when you have time) is called for.

To me, if E2.0 REPLACES the antiquated, it is a reduction in capabilty for improvement otherwise.

Yes, I have to have an E2.0 capability - no, I am not ready to abandon everything else! I would rather add on to my house, not tear it down and start over; unless there is no other way to get the capability of E2.0, which, yes, I have to have.

Having read through the whitepaper I came away thinking that a key opportunity has been missed, maybe it's inevitable given the potential target audience so should the audience be changed?

The paper does skip over the way that users have started to adopt social networking and collaboration tools in an attempt to use the void in the corporate world, what it doesn't address is why.

On the face of it the list of tools generally grouped together as Enterprise 2.0 are not new to many, they are just not common inside the Enterprise.

Why do users feel the need to look outside to be able to find collaboration solutions? is it because the IT departments, their policies, standards, and procedures are too rigorous and restrictive?

This, at least to me is the key problem.  As such the question becomes how does selling a toolset to the same department that locks down the current environment address the problem.

I feel that the paper needs to be requirements led in order to convery the benefit that IBM solutions should bring.  It would benefit from some real life examples where necessity has driven innovation with the use of technology.  Examples inlcude the HP Halo video conferencing solution that was created to assist Pixar with near real life video conferencing so that Disney and Pixar could work togther remotely, or the development of the Boeing Dreamliner platform with the key teams barely physically meeting each other.

Stitching in some tangible examples of where technology has been successfully used to solve collaboration gaps would make the tool pitch more compelling.

I would suggest rethinking who the target audience is.  Is it the IT procurement manager or the CIO/CTO.  If so a straight technology sales pitch is OK but simply adding tools in a vacuum will not make users actually use them.  Targeting the paper at a different part of the C-suite to illustrate the problem better and then enabling the IT department to become part of the solution, once it's been identified, acknowledge, and agreed, may actually result in better uptake.  My fear would be that simply aiming at license sales would end up proliferating IT as part of the problem and not the solution.

Given that the aim is to try create an enterprise adoption of a flexible and dynamic platform that allows collaboration surely the power is in generating the need in the user community who are currently doing the run-around the current IT systems?

The other inclusion which I believe would add value is thinking about how Enterprise 2.0 can be used to break down the barriers, if desired, between the organisation and the customer.  The focus seems to be internal collaboration but one of the emerging shifts is the perforated boundary between the client and the employee.  I know that the organisation I work for is increasingly creating hybrid teams of our employees and the client's employees. 

By creating a common environment that allows collaboration between the two components of the team the project is more efficient and more effective.  Extending presence outside the organisation, the examples of consultant on call [online], go along way to strengthening the relationship and extending the servicescape beyond the traditional line of interaction.

As globalisation and localised specialisation continue to create a natural tension in organisations making employees available to each other and to customers across timezones and geographies through effective collaboration would be a real differentiator for companies.

This is another example of articulating the business need to the right audience and then positioning the IBM Lotus suite as a response rather than a solution looking for a problem.

1. How can this whitepaper target its audience better?

I'm not sure who the audience for this paper is. I suppose that I could glean some measure of that from the "Executive Summary", but -- and you're probably not going to like this -- the entire Executive Summary is buzzword-laden fluff. It could be reduced to "Enterprise 2.0 good, Enterprise 1.0 bad", an assertion made without any supporting evidence. So I'm not sure who you think you're speaking to here; ostensibly, perhaps, people at the Cxx level, but I would hope that these people would already be well past this.

2. What specific business communities would benefit most from employing Collaboration 2.0 tools?

Those which are not saddled with stratified organizational structure and/or legacy processes. Frankly, it doesn't matter how well you pitch the general concept or the specific product to the those businesses which fossilized in place circa 1975: they will either (a) never adopt them or (b) will insist on adopting them in a fashion that just about entirely cripples them and renders them irrelevant. Sure, you might make inroads with companies that have been running IBM since forever, especially those with a Lotus presence, but you're not going to have a positive impact anywhere that's still struggling to come to grips with basic principles of networked interaction.

Unfortunately, this presents you with a problem. The folks who were once running 370's are going to be inclined to stick with IBM because they have a certain comfort level and because institutional inertia is a powerful force. But that same inertia and Mon-Fri-9-5-cubicle-closed-source-nothing-but-IBM mentality is going to prevent them for even scratching the surface of what they could do with such tools. So you might make a sale, which is great for the bottom line, but you're not going to get these people to change their attitudes.

3. How could this whitepaper be improved? What points could be added?

A. Excise the buzzwords ruthlessly. Please. I beg you.

B. Make a connection between all the chewy goodness described in the first several pages and the product offerings described at the end. As others have noted, these products are presented in haphazard fashion, sans many relevant details, and at no point is there an exposition on how they constitute a solution set for the requirements outlined earlier.

And explain why the chewy goodness is so. The first part of this paper repeatedly asserts that this is the case, but completely fails to back it up. We're left with "2.0 > 1.0", but that's not much of an argument.

C. You'll need to convince the audience that "buy our products" does not equate to "...and thereby get locked in to our proprietary solution which makes it cost-prohibitive for you to ever change to anything else". Knowing the history of Lotus as well as that of some tortuous migration projects does not instill me with joy. You need to show me that you have enough confidence in your offering that you're just as willing to migrate data out as in -- that you believe it's so good that nobody will ever want to change.

D. Explain how a plethora of tools (e.g., blogs, wikis, etc.) is going to make my/their/our operation work better. Just saying "they're Web 2.0 magic" won't do. I say this because I've already *seen* operations that are using various assortments of these and they're not really doing anything better, different or faster than they were.

4. Given the recent demise of Google Wave, what lessons can be learned for collaboration software providers?

Replacing email is going to be much harder than you think. Merely labeling it as "Enterprise 1.0" and denigrating it as outdated will not suffice.

It's been, and remains, the killer app, because it has a number of highly useful properties: it's push; it's (roughly) serialized; it's ubiquitous, standardized and portable (which means I can collaborate with people who aren't running the same software I am); it can be readily archived and searched *INCLUDING* when I'm offline, it can be forwarded (again: including to people not running the same software as I am), it can be threaded, sorted and bundled, it works reasonably well in the presence of temporary system/network outages (thanks to queueing), it can be gatewayed to other communications forums (e.g. Usenet, web boards), and it has rich filtering/filing capabilities (see RFC 2919 and RFC 2369).

The only mechanism which has come close to replicating this is Usenet, which despite the trendy groupthink which insists on labeling it as "quaint", has persisted for over 30 years and *still* is more useful than any web-based forum.

Theres's a reason -- actually, a number of reasons -- why the most technically capable people on the Internet use mailing lists to communicate and interact. From NANOG to the Linux kernel developers to the Apache project to every just about every open-source project to the IETF to...well, you get the idea. These people are MORE than capable of using anything else, and quite likely far more aware of those alternatives than anyone else.

But they stick with email (and Usenet -- have you looked at the comp.* groups recently?). You need to spend some very serious thinking time working out just why that is, and you can begin by rejecting the quick-but-wrong answer that "it's what they know". These are the people who have invented Web 1.0 and Web 2.0 (as you call them) and are busy inventing Web 3.0. They're not averse to new technology, but they're not going to adopt it just because it's new or because someone tells them it's shiny.

5. Additional comments:

A. This doesn't run on Solaris? Or any flavor of BSD, including MacOS? Please. It's 2010. There's no excuse for software non-portability.

B. It's not open-source? Again: it's 2010. Get with the program, please. If you aren't willing to open your code for peer review, then we must all ask what you're hiding. (And we have to note in passing that just because you haven't published the code doesn't mean that the Bad Guys don't have it. Of course they do. Which means that they're busy looking for ways to exploit it.)

C. I realize that Lotus has brand recognition and that labeling all this as Lotus-something likely pre-opens the door for sales to people already using it. I also realize that you have a massive code base and an army of developers familiar with it.

But you know: there are some seriously good open-source projects out there which have produced mature code that handles many of these functions. They're well-supported, portable, etc., all the good things that we want out of software. So don't be surprised if someone looks at what you're doing, and then figures out that they can replicate it *not* by writing the huge amount of code it will take, but by judiciously combining several existing projects -- and just writing the glue.

Or you could try to do it first.

D. I don't see much in here about revision control, auditing trails, and logging. It's necessary, in some environments, and desirable, in others. We need to know who did what when, we need the ability to undo it, we need the ability to produce "everything that relates to $FOO", and so on.

E. Nor do I see much here about security and privacy. (See next point.) One of the things that's very much on my mind when evaluating any product like this is "what's the attack surface?", accompanied by questions such as "what ports will I need to open?", "how am I going to defend this?" and "how am I going to back it up?" and "how can I defend everything else from this, presuming that one day it's compromised?"

The days are gone when I could just install this in a corner and presume that it will never be a target or a threat. It's one big honking target right out of the gate, and if successfully attacked it would become one heck of a threat.

F. At no point do you address the systemic and chronic issues with external sites like Facebook, LinkedIn, Twitter, etc.: to wit: they've had multiple serious security issues. There are massive ongoing privacy concerns. Some of them are spammers. Some of them are malware conduits. Some of them are quite likely being monitored by government security services. Some of them have stability and scalability issues. Some of them are brokering or leaking data to third parties. And so on.

G. We still have to create, edit and render documents. I see some signs that this system supports that, in particular references to XML (which is good): but are you fully-committed to make this an XML-native system (with the ability to render documents for export in other formats, e.g., PDF)?

H. As a corollary to that, are you committed to making this searchable as XML?

I. There are some comparisions to SharePoint, which it's been my unfortunate fate to occasionally have to deal with. It's junk, it's takes an army of (expensive) people to operate, it's not compatible with anything, it runs on an inferior operating system, and it breaks. A lot. What reason do I have to believe that your product is better? (Let me note that I actually *do* suspect that your product is better, partially because I know your history and partially because you couldn't possibly do worse.)

J. Telling me that this is people-centric rather than document-centric doesn't mean anything. (see page 8)

K. I'd like to see which standards are supported -- in particular, IETF standards, because that gives me some clue how easy or hard it will be to get this to play nicely with others.

M. It's good that you recognize that desktops and laptops aren't the only devices people will use; phones are, as you note, becoming more common end-user devices every day. So are tablets and all kinds of hybrids.

N. You mention integration with Microsoft Office: how about OpenOffice, so that we can deep-six Microsoft? (Let's include Thunderbird, too, because Outlook is hideous.)

O. How are you going to support users who are not always connected? For example: I'm getting on plane in DC and flying to SF. I'd like to get some work done en route, but I'm not going to have connectivity until I get to my hotel. How am I going to be able to use that time? (This goes back to the my earlier comments about email. If I have pulled all of it down, I can be drafting replies and queueing them to send. I can be reading attached documents and editing them. I can be searching the archive of messages on my laptop for the last conversation that was about topic X or Y. How much of this can I do with *your* system, or am I just out of luck?)

Collaboration 2.0 is a fine paper that introduces key concepts and trends in the growing Enterprise collaboration space.   However, I think the focus may be too narrow in terms of predicting the evolution of enterprise collaboration - and the enterprise itself - which in my opinion is most likely to increasingly follow, use, and copy the form and function of current non-enterprise, consumer driven tools like Google search, Google documents, Twitter, Wordpress, and even Facebook.  

There are powerful economic and practical reasons to assume that non-enterprise applications will continue to bleed into the enterprise space.   The paper very correctly notes that the new internet is driven in part by human interaction rather than technology, and also notes:

We have seen that Web 2.0 is about empowering the user, and that unexpected things happen as a result.

Many workers are already familar with Google, Google Documents, Twitter, Wordpress, Blog CMS, and other applications.  We should assume that they may shun applications in favor of those they already know.  More importantly, we should assume that the most powerful path to change is to integrate existing technologies rather than "reinvent the wheel".    

My view is that the enterprise market in general is struggling with the fact that historically it's been most profitable to create complex and very robust systems, sell them at a premium, and encourage regulary upgrades.   This is not necessarily the best path for a business and generally it's "forced" on employees.  As software experience has moved out of the workplace and into the home and phone, employees may be even more reluctant to adopt new technologies, especially if they feel the applications they already know are superior in function.    

Again, the best enterprise model may be one that focuses on integration of existing applications, leveraging user familiarity and contentment in favor of adopting whatever new approaches are required by the company for their own specific needs.  

IT departments too often favor maintaining control of the IT environment over creating a more usable and friendly space for employees.   This trend will soon stop as employees are more fully empowered by commonplace, intuitive technologies. Employees will increasingly demand that the enterprise function as seamlessly as do their home computing applications.

Although by definition we can't predict the unexpected, I think we can assume that the ease of collaboration online will create at least two competing activity tracks for workers - one is the path of greater efficiency noted in the paper where the tools facilitate faster and broader communication channels both in and out of the enterprise.   However I think unaddressed was the fact that collaboration can mean wasted "socializing" time and inefficient use of technologies - a factor that will continue to plague businesses where online activity is regularly required.  

For example as many large scale social media efforts ramp up - such as those at large bank customer service centers -we've seen an almost bizarre tendency for the online teams to respond rapidly to customer complaints, collect information, and then refer the customer to their call center for a resolution.   In these cases the social media element has simply added a step to the resolution process, frustrating the customer and adding extra costs for the business.   Businesses deploying this type of system should generally seek to empower the teams to fully resolve most problems rather than simply be a "sounding board" for the hapless customer.

In summary I think Collaboration 2.0 needs a "second chapter" that reviews trends with non-enterprise collaboration tools such as Google Documents and WordPress, and predicts how these tools will affect enterprise collaboration adoption trends as well as how these tools can be most successfully integrated into the enterprise collaboration environment either as independent applications or as "add ons" that interface with the enterprise tool via the open standard APIs that many of those tools already have to interact with other programs.

From the outset of the whitepaper, I was confused as to the audience of the paper. From the tone, it appeared to be focused more towards the IT than business side. On page four it states “Enterprise 2.0 environment is something that all IT managers should be thinking about.” It is not the IT managers which are going to be primarily concerned about collaboration in teams except for their IT teams. It seems as though the audience should also be directed at business side managers. If this is then the case, the assets of Enterprise 2.0 technology should be given more prominence. Paragraphs 4 and 5 of the executive summary are strong reasons to keep reading the whitepaper, as is the 6th paragraph in “Addressing Today’s Business Issues.”

There should be a separate whitepaper addressing the specific needs of government. Though much of the information will be the same, there are different issues involved in working within government, and a paper titled and focused on government would make it more relevant and attractive to that sector.

The heavy use of Web 2.0, Web 3.0, Enterprise 1.0 and Enterprise 2.0 screamed “buzz word” and distracted me from the meaning. These numbers were used 13 times in the first 5 paragraphs, and 52 times in the first 5 pages.

“Enterprise 2.0 also means ‘open’ standards rather than proprietary or ‘closed’ systems.” (p4.) This doesn’t explain to the reader why open standards are important or how they benefit the business and their users. Mentioning cross compatibility, data portability, accessibility, or other benefits of open standards would lend meaning to the reader, but as it stands, they again scream “buzz.”

On page 6 there are a series of bullets which don’t stand out enough either visually or the language. The blocks of bullets should be indented and the line spacing should be tightened up to separate these out as important items. The language of the bullets should be more active. Rather than introducing the first set of bullets with the “reasons relating to business social networking software,” it should read, the “benefits of business social networking software are:” This takes it from introducing each bullet with “need to improve…” and allows you the ability to be more direct with “improves…” It also will reduce the feeling of redundancy in the bullets, as 5 of the 6 bullets start with “A need to”.

• Improves communication and collaboration in a practical and reliable way across an distributed workforce separated by geography, time zones, and culture.
• Enables colleagues, partners, and stakeholders to find, access, share information, and collaborate in a secure and reliable way.
• Maximises the value of contacts and business relationships by understanding their context, relevance, and appropriateness.
• Improves employee satisfaction and loyalty with a view to retaining the organisation’s most important asset: its people.
• Improves the productivity of information workers given that in excess of 70% of salaries are now allocated to such work.
• Reduces expenses and the cost of doing business. Reducing the ‘sales, general, and administration’ line of the business by working smarter can only improve competitiveness.

Most of the paper has a strong business tone, however starting on page 8, conversational tone phrases start appearing. On page 8, the second paragraph starts with “Like it or not”, which may be true, but is unnecessary and weakens the argument, as does “scores top marks.” It should be more of a statement, saying that “Microsoft technology is the industry standard in enterprise collaboration software, and IBM is fully compatible with Microsoft standards.” Simlarly, on page 10, the 3rd paragraph of the Summary it states: “this product does not present anything that is particularly new, original or novel.” This is an unnecessary phrase which weakens the argument at a critical time in the paper, the summary. It gets worse in the last two paragraphs of the entire white paper. These paragraphs leave the reader thinking about how IBM’s “worker strategy has lacked cohesion and direction in recent years” and how the online services are “not yet fully developed.” The conclusion of the paper should give the reader strong thoughts about Enterprise 2.0 technology and the products discussed. A conversational tone can be used for the paper, which may make it more accessible to a wider audience, however it should not be self deprecating or weaken the arguments being made.

Three things are missing from this paper are data, clear use cases for the technology and guidance how to choose, use and manage social tools. Data to substantiate some of the claims like cost savings would lend visual contrast to the paper and strengthen the argument. Use cases could be separated out within the text in a box, which would provide readers the opportunity to see their work in the technology. It would also provide greater texture to the paper and break up the text. Lastly, it proposes features such as blogs, wikis etc. however, someone who is not an active user of these or has not used them in business would likely struggle with which to implement, pros and cons of each option, maintenance involved. This could itself be a white paper which could easily be crowd sourced similar to that done by Dell on Digital Nomads.

Ultimately, there’s significant amount of great information which can be focused more towards specific audiences. The weaknesses noted here are easily correctable and I’ll be interested to see the final version of the white paper. Thank you for the opportunity to comment on this interesting paper.

I've watched collaboration tools coming into the workplace over the last 12 years, first at a biotechnology company and later at a corporation that provided environmental remediation services. They're not the obvious industries for collaboration tools, but in a way that makes the experience even more relevant. Ultimately it's not about specific business processes, but the way collaboration unlocks the hidden potential in all employees. Collaboration software let us accomplish things we could never have accomplished individually -- and I like to think that that experience was universal.

In fact, there's another way the white paper could make its point: by highlighting the downside of "the e-mail and document-centric world". I remember one of my first jobs out of college, where we were produced an important once-a-year catalog for our new product line. After the documents manager had completed the printing, we discovered we'd overlooked a glaring typographical error in the name of one of the products. The company's owner insisted we destroy the catalogs, and reprint a corrected version - and it cost the company over $10,000.

After that, our documents manager found a great way to collaborate within the company. He'd use in-house tools to share an early draft of next year's sale catalog, and then made it available to every salesman and product manager who had a stake in it. Everyone was excited at getting a "sneak peek," but they were also motivated by a chance to make a difference. He got great feedback on what to include and what to leave out -- including one salesman who spotted some language that could've gotten us in trouble with federal regulators. (One year, there were even $10.00 bonuses offered to anyone who found any overlooked typographical errors!)

There's room for more examples of how collaboration helps the sales force. But it's really helpful in two entirely different areas: external communications, and internal communications. I remember starting a new job in the healthcare industry, and discovering my employer had a library of in-house training videos online. I remember thinking that there could've been a lot of goodwill generated with the general public if some of these videos were approved for sharing with the outside world.

The biggest problem with a document-centric world is that information flows much too slowly. One software development department where I worked had no way to track how employees allocated their time to different projects. This made it difficult to bill their work to the appropriate department, but it also meant the department managers were left in the dark. At the end of the week, we'd enter the hours we worked on individual projects into a spreadsheet, and then administrative assistants would have to collate them together so the managers could get their once-a-week overview!

My girlfriend also worked as a software developer, where she learned a similar lesson about the flow of information. The managers had wanted to motivate the sales people by encouraging them to reach a quota in sales. Unfortunately, there was no way they could track their actual sales, since the processing of their initial orders could drag out until the next pay period. Instead of encouraging them to push towards a goal, this ended up "de-motivating" the salesforce instead.

That's mostly a lesson in the importance of communication -- but I wonder if it's also an opportunity for collaboration. Imagine a sales manager announcing that there's a prize for the first salesman to earn 10 sales before closing time. In the real-world, that's harder to implement, because your salesforce is often mobile. So if you want to have a real-time competition, you'll need to find a way to actually communicate with everybody in real-time, and in a way that can reach  mobile employees.

That points to one of the overlooked benefits of collaboration. Pundits talk about the "wisdom of the crowds" -- how someone will eventually come up with a solution if you get enough minds thinking about the problem. But the overlooked advantage of collaboration is that besides creating a mass of problem-solvers, it also creates a receptive audience for those solutions. With everyone networked together, there's a real pressure to take the issues seriously, and to propose good solutions which will move the group forward.  Collaboration instantly rewards your most productive employees with a burst of positive feedback. Humans are social animals. Give us a crowd, and we'll try to impress them.

I think the White Paper could benefit from a discussion of "Best Practices". This might make it less abstract, and offers a chance to give readers some concrete examples.

There's an old saying about collaboration: the more people who are involved, the more useful it becomes. So obviously, it's also important to have a good training program. It's easy to overlook the potential of collaboration tools if you don't know how to use all their features. But once a user discovers new power, they're more motivated to use them, and can even be an "evangelist" for the software to other workers.

There also needs to be a commitment to actually using the tools. In the middle of a crucial conversation, you don't want to discover that the person with the answer isn't part of your social network. Fortunately, there's a built-in "social pressure" to adopt the tools which your co-workers are using. Once installations reach a critical mass, the tools develop their own momentum.

Managers worry about chaotic collaborations, with everyone speaking out of turn. The biggest problem I've seen in the workplace is the opposite: nobody's speaking up. I remember an in-house trainer who used to call on people at random, just to keep everyone awake. That's probably a great way to start your training: make everyone test out the collaboration features. This also reminds everyone that you're working in a group setting, and makes the participants feel more comfortable.

At first there's an implicit "peer pressure" not to slow things down with questions - so be ready to plow through that. But I've also seen people who feel more comfortable typing in their questions -- sometimes anonymously -- than they do speaking up in a crowd. Be sensitive to the user's experience as you implement your collaboration tools.

But finally, remember to set a good example at the top of the hierarchy.  I remember taking an online programming class from a local college. The professor said he'd actually base part of the grade on the level of online participation. During the first week of class, each student was required to introduce themselves in an online post. But later, when I actually started posting some questions - the professor was never around to answer them!

Collaboration tools can increase your productivity expontentially. But only if other people also show up to collaborate with you!