Why Closed Doesn't Work for Collaborative Workspaces: Three Reasons Why Openness is Required, Nov 3

(PDF, 9 pages, 148 KB)

Introduction
This report is about why collaborative workspaces haven't been adopted, why email continues to be the default medium for communication / coordination / collaboration, and what we "the industry" need to do about it. At a fundamental level, and looking across the demands put on people today, it argues that today's collaborative workspace offerings make it more difficult for people to communicate in comparison to email. Architectural "closedness" is preventing adoption. This used to be the case with email, but it changed. It used to be the case with instant messaging, but it is changing. It is the case with collaborative workspaces, and change is needed.

Statement of Research Independence
This Strategic Viewpoint report is an independent publication of Shared Spaces. No vendor requested or sponsored this report to be written.

What is a Collaborative Workspace?

A collaborative workspace is a pre-assembled collection of tools specifically designed for sharing information about a project between team members. It is thus conceptually similar to an email client, which is also a collection of tools, such as a calendar, a to-do list, an inbox / outbox / folders, and an address book. The difference from email, however, is that the tools in a collaborative workspace are specifically designed so that the information is directly shareable between a group or team of people, usually via common access to a single place.

Common Shared Tools in a Collaborative Workspace
Common shared tools included in a collaborative workspace are:

• A Shared Tool for Discussing Project Matters. Team members can have written discussions about the project. Instead of sending an email to a distribution list or group, the content is placed into a discussion area. Other team members can read what has been said, and leave comments or responses. This gives a centrally-accessible running account of the discussions and decisions that have taken place during the course of the project.


• A Shared Tool for Scheduling Project Meetings and Events. Real-time interaction enables team members to work through differences, leverage the collective knowledge and wisdom of the team, get feedback on difficult issues, and agree to deadlines. The team might meet face-to-face, or hold a virtual meeting by audio, video and/or Web conferencing. A way of scheduling project meetings is needed, as well as a method for capturing and recording key meeting decisions.


• A Shared Tool for Assigning and Managing Action Points. The work of the team is sometimes moved forward by everyone working together (e.g., during a meeting), but more often by individuals working alone on specific areas of action and outcome. Team members need clarity as to whom is doing what, by when, and with what resources.


• A Shared Tool for Storing Shared Documents. Many team projects result in the output of one or more documents, be that a marketing plan, a product strategy, a board paper, a market growth forecast, an advertisement, or something else. Team members require a place to put these documents while they are being developed, a method of tracking versions, and clear delineation between draft and final editions.


• A Shared Tool for Listing People's Contact Details. Details on how to contact others in the team should be stored in an accessible place. With teams increasingly being composed of people from multiple divisions or departments within an organization, and even with people from multiple organizations, how to reach someone by phone, mobile, fax or email needs to be listed. An area for storing contact details, and perhaps even an individual's photo for those in larger teams, is important.


• A Shared Tool for Recording and Analyzing Structured Information. Some teams need the ability to capture information in a structured way, that is, information that is divided into specific fields and is of a particular type. Survey responses, test-bench results, product sales figures, marketing response rates across initiatives, and risks and issues all fall into this category. A team gets benefit from this information when it is aggregated, can be sliced-and-diced, and is amendable to viewing in different ways.

Collaborative workspaces also need capabilities to regulate access--for specifying who can get to the various shared tools--thereby limiting information disclosure to specified individuals or groups.

Division of Projects into Separate Workspaces
An essential idea is the division of individual projects into separate collaborative workspaces. When each project has its own workspace, team members working within the workspace do not have the distraction of unrelated information cluttering their view. The information in the workspace is solely dedicated to the project at hand, rather than being a collection point for everything related to anything. This enables people to focus and concentrate, which are key drivers for effectiveness and productivity.

Examples of Collaborative Workspace Products Available Today
Tens if not hundreds of collaborative workspace products are available today, including Documentum eRoom, Lotus QuickPlace, Groove Virtual Office, Microsoft Windows SharePoint Services, Verosee for Skype, CentralDesktop, Open Text Touchpoint, IntraLinks deal rooms, and many, many more. This list is not exhaustive or authoritative, and nor does it attempt to be.

Why Closed Doesn't Work for Collaborative Workspaces
This section considers why today's approach to building and using collaborative workspaces is not working.

Putting Jim Under the Spotlight
Jim (let's put a name on our "user") is asked to contribute to a divisional project that is powered by a collaborative workspace. And then he is asked to join another project. And then yet another one, although this time the project leader (Anna) is from an another division in the organization, and so Anna's collaborative workspace product will be used. And then a request is received to contribute to a strategic project that involves multiple collaborating organizations within the industry, with the project being driven by an external organization, and thus supported by the collaborative workspace product that they have embraced (Fred is the project leader). And so it continues, until our Jim is concurrently involved in 6 or 7 projects, all of which are powered by collaborative workspaces, and all of which are different.

What's wrong with what we are asking Jim to do?

Similar Meta Models, Nuanced Implementations
Much of each collaborative workspace uses a conceptually common set of capabilities. Most have a shared tool for project or team discussions (eRoom does, QuickPlace does, Groove does). Most have a shared tool for project or team calendaring (eRoom does, QuickPlace, Groove does). Most have a shared tool for delegating and managing action point assignments. Most have a shared tool for storing and organizing documents. But, there is no interoperability between the different products, because each vendor has created their own product in a vacuum.

The current industry approach to collaborative workspace design and delivery means that Jim is forced to use eRoom for one project, QuickPlace for another, Groove for another, SharePoint for another, Touchpoint for another, and another for another. There is no ability for Jim (or his IT department) to decide that he will always use the eRoom interface, for example, and use that to access every collaborative workspace. And Anna can't decide to always use QuickPlace. And Fred can't decide to always use Groove. Everyone has to learn and use everything, and this is preventing adoption, and driving people back to email.

Key Message: 80% of each product is conceptually the same. But it's treated as different.

Multiple User Interfaces to Learn
Jim has to learn to use, and be comfortable in using, the user interface of multiple collaborative workspace products. There's not just "one way" for him to work, like there is with email. Since each product has its own nuanced implementation, different tools are called different things in each product, the navigation bar looks different, and he has to click on different parts of the screen in each product to accomplish similar tasks.

We are asking too much of Jim. Due to the requirement to learn multiple ways of doing things, it is almost impossible for Jim to get in the state of "flow", whereby he is intently focused on the work at hand and the tools he is using become invisible.

Key Message: It's too hard. Technology invisibility is almost impossible to achieve.

Information Scattered in Collaborative Workspace Silos
The project information that Jim, Anna and Fred work with are scattered across a collection of non-interoperable data silos. There is no ability for Jim, Anna or Fred to see the totality of what they are involved with, whilst at the same time maintaining a strict division between projects. For example:

• Jim can't see all his meetings, from across all of his collaborative workspaces, in a single calendar. By implication, free-and-busy searches no longer work for him.


• Jim can't review and prioritize a unified list of action points. He has to manually reconcile the list, and continually check in multiple places for new things.


• Jim can't synchronize all of the contact address cards with his Pocket PC.

For the IT department, the standalone nature of individual collaborative workspaces means that regulatory compliance is more difficult to achieve. Enforcing Chinese walls between people in different divisions of an integrated financial services company is nearly impossible, particularly if a peer-to-peer collaborative workspace tool is involved. Likewise, ensuring the capture of all business records is nearly impossible, especially when the collaborative workspace product is hosted and maintained by another division, an external organization, or a neutral hosting partner. And things that should work, like free-and-busy search, don't.

Key Message: Collaborative workspace silos make it nearly impossible to get stuff done.

A Proposal for Collaboration within the Collaboration Industry

Vendors of collaborative workspace products need to start collaborating, in an intentional way. They need to put aside their own plans for world domination, which can't happen under the current approach for anyone with the possible exception of Microsoft, and come to agreement on the technology underlying a collaborative workspace. These agreements should span three key areas.

Simplicity is Essential to Mass Market Adoption
Very simple to use and very simple to understand technologies get mass market adoption. From the user's perspective, email is dead simple: to, copy to, subject line, content, send. We need something like this that is an intermediate step beyond email, while at the same time recognizing the validity of structured, formal, and enterprise-class collaborative workspaces for business processes enablement. I see this intermediate offering as suiting the high number of ad-hoc collaborations that people engage in during a business day. Rather than merely turning to email all the time, the Jim's, Anna's, and Fred's of the world should be able to have a collaborative workspace that works for everyone everywhere.

Key Message: A simple intermediate offering is needed, something more than email, but something less than process-centric collaborative workspaces.

Agreement on Five Core Functions
Our simple, intermediate collaborative workspace offering needs to have an agreed set of core and common services. Here's the five core functions that I see: threaded discussion, shared calendar, shared task list, shared documents, and shared contact records. By agreeing to these five core functions, industry players would be able to create a standards-based, interoperable server or service to deliver these capabilities.

Key Message: Agree on five core conceptual functions, and then implement them using standards for interoperability.

Unified Client for the End User
Client-side software, be that rich, thick or thin, can then be developed to interact with the collection of collaborative workspaces that users are involved with. Each client implements a client-side rendition of the five core functions, delivering a screen layout and interface that is consistent for the user, regardless of which server or service a specific collaborative workspace is hosted on. Hence for the user, their user experience is consistent across every collaborative workspace, and therefore what they learn about using the product / service in one collaborative workspace can apply equally across all the others. Hence, the two key ideas are, firstly, each organization can settle on a single consistent user interface for its employees, and secondly, the unified client can interact with multiple back-end collaborative workspace servers or services.

Aside from the ability to interact with a collection of collaborative workspaces, three other client-side capabilities are needed:

• Invitation and Subscription. The ability to invite others to participate in the collaborative workspace, as well as the ability to accept / decline / delegate participation.


• Synchronization, perhaps. Synchronization enables users to retain a copy of the information from a collaborative workspace locally on their computer. Changes made locally are automatically synchronized with the server or service-based editions, and changes made by others are pulled down to the local machine.


• Aggregation or dashboards. It is critical that users be able to see an overall summary of where they are supposed to be (calendared events) and what they are supposed to do (delegated action points) from across all of the collaborative workspaces they are involved with. Some kind of roll-up, aggregation or dashboard capability is needed for this. All calendared events from all collaborative workspaces should display in a single calendar layout, and all tasks from across all collaborative workspaces should show in a single list which is capable of being categorized, prioritized, and synchronized with a mobile or wireless device.

Key Message: A unified client that can talk to a collection of standards-based servers or services is needed.

How Do We Make This Happen?
In summary, collaborative workspaces designed for sharing of information between teams are frequently built, but adoption is lacking. This report argues that a lack of interoperability between the various collaborative workspaces is the key reason for this, and proposes the need for intentional collaboration between industry players to create a standards-based, interoperable platform for "beyond email" collaborations.

If this is a valid idea, how do we move forward? I'd love to hear your thoughts.

Comments

[Bill Wood]

I'd argue for a 6th core function: meetings management - scheduling, adding topics, commenting, outcomes, agendas, and minutes.

[Moritz Schroeder]

First, let me thank you for this great report. I always wanted to write something like it, though I never did and never could have done it in your precise and clean analytical way.

I'd like to add another argument why "closed" doesn't work. Teams are unlikely to exclude people from their group because of lack of a particular technology. So they will automatically use the best tool available to all of them, which nowadays is usually email.

How to move forward? Maybe an example of the decision making and principles for a new system:

I am involved with a non-profit organisation (20,000 members) consisting for historical reasons of two legal entities. The aim was to create a common platform for members and staff of both entities, while preserving independant activities and specificities of each of the entities. The system includes address management, list selections of members, tools to create and manage groups among members, events and so on. We have thoroughly checked software solutions, web services and ASPs. One of the entities has been using an MS Access solution (a dead duck from scratch), the other Lotus Notes (ok, but in the need of a complete overhaul. Otherwise Domino is expensive due to the need of specialists, infrastructure...).

After viewing a good dozen of apps and ready-made solutions, we decided to formulate some principles:

1. Open standards: no technology choices as long as it's open, uses standards and has a sufficiently large supporting community of specialists and users .
2. No lock-ins: switch of suppliers,developers and hosters should be as painless as possible if needed. This is not a one way condition, because if the development contractor wants out but can't because of technical and contractual reasons, it's bad for him and as well as us. Who likes to work with someone who doesn't...
3. Accessibility: web centric design (interface to members) and platform independant interface for member/association management.
4. Layout and backend separation: easy design changes based on CSS
5. Understand us: we did not want supplier orgs substantially larger than us, because we feared they would not understand our "business" and because we wanted to keep the communication processes "short".

Nearly all bidders were pleasantly surprised about our process and principles. (In the end we went for the org which had a great guy and presented a surprising solution: the interface for member management will be using the User Interface Language of Mozilla XUL, thereby giving us a rich interface based on a web-like database app).

I think combining such a list of principles is the first step to move forward and your report implies already a good number of them. Why not create a wiki for that project?

[Andy Swarbrick]

great additions to an important debate.

[Gary Buck]

A very good report - a few things immediately come to mind
1. The problem is bigger than joint collaboration tools - I use some of them but also real business apps like SAP (that have another calendar etc)

2. I hate to say it but you almost are building a round-a-bout case for using Outlook (or email client) more as the entry into things like eRooms. It has an interface that everyone knows, has the calendaring, has the tasks - not good at the other components but I guess that is what Bill G is trying to fix???

GB (not a MS fan at all)