Seven Design Principles for Enterprise Collaboration 2.0

September 16th, 2008 by jeremychone

The two premises of this article are as follows:

  1. Social Networking is the method of connecting and communicating with the purpose of increasing knowledge (of people and of domain).
  2. Collaboration is the method of organizing knowledge and expertise to efficiently accomplish a particular task.

So, Social Networking is about sharing and discovering, and collaboration is about organizing and creating. Although informal, the point of these definitions is to demonstrate the similar but inherently distinctive meanings of collaboration and social networking.

The latest challenge for an enterprise is that social networking has undergone significant innovation cycles, mostly on the consumer side, and collaboration has not kept pace. As a consequence, an enterprise is often tempted to substitute collaboration by social networking, which could lead to an oversized enterprise social network with very little productivity gain, or even a loss, due to the over-communication side effect.

In my opinion, enterprise collaboration is still too unstructured, fragmented, and, I would even say, immature. Most users became accustomed to unnatural and inefficient ways to partner for the most basic task, such as document collaboration. Some collaborative solution providers tend to offers partial results for fear of empowering or promoting their competition. For example, Google has an interest in luring users away from the Microsoft Office application suite, so the company consequently orients its technology and innovation toward this business goal to the detriment of the overall user’s value. Interesting solutions such as SocialText, Confluence, Jive, Yammer, and 37Signals are trying to tackle this opportunity, and while they are indisputably useful and innovative, significant untapped opportunities remain.

The key to designing the next generation of collaboration solutions is to reconsider the ways that software and services can help people who are collaborating from the bottom up. Often times, collaboration software attempts to accomplish too much, and often finds itself obstructing user workflow. I developed the following seven design principles, based on my experience with building collaboration software:

1) With, Not Against, Email.

Although we might first think “email is broken” when we want to build a new collaboration system, this is a bad thought to consider. Instead, remember that email is a popular, easy-to-use type of program. In fact, email is often the first and last application people use every day. In short, do not build a system to bypass email, but rather a system that enhances email.

2) With, Not Against, Office.

officeFor a long time, there has been an emotional (or business) trend among professionals to terminate the office desktop software era. Although some of the rationale behind these wishful thoughts is understandable, the collaborative solution would fare better if it would learn to work seamlessly with desktop office files and software instead of trying to circumvent them.

Users do not want to import or export files, but rather, they want to create, save, share, and comment on documents from any location, such as desktop, Web, or mobile, whether they are on or offline.

In other words, office desktop software, including word-processing, spreadsheet, and presentation programs, are just as pervasive to be considered a part of the operating system, as is the Web browser, but in a much less controversial way.

3) Individual Productivity as the End, Group Collaboration as the Means.

individualUltimately, we live in an individualistic and competitive society, and the best way to build an effective organization is to align individual and organizational interests. To this end, from the beginning of time, organizations have hierarchically organized themselves with clear accountabilities and a clear chain of command.

Thus, organizations require the tools and processes to optimize their entire structures by empowering each element of their organization, from the individual worker up to the top manager. With different roles come different needs, but if the tools exist to make each role more efficient, the entire organization will maximize its execution potential. Maximizing group productivity might be the right path to make a specific role more efficient, but it is just the means and not the end.

4) Extensibility Over Completeness.

extendWhen developing a collaboration system, it is a natural inclination to try to build a full set of shared applications. Some might try to build email, content management, calendar, web conferencing, and instant messaging, while others might focus on a more sophisticated set of applications, such as project management, people-friendly wikis, issue-tracking, and collaborative workspaces.

While some of these modules are necessary, system extensibility is as important, if not more. Effective collaboration systems must be customized and enhanced by the people who are collaborating, and consequently, the applications must be extensible. The trick is to strike the right balance of pre-built application and extensibility capabilities. Because this is where most collaboration systems have failed, it is where the biggest opportunity resides. Hopefully the PaaS movement will result in useful concepts that can be applied to collaboration systems.

5) Software as a Service (Saas) AND Software.

softwareAnother current market tendency is to try to oppose enterprise software (i.e., “on-premise software”) versus SaaS solutions (or “applications in the clouds”). I was recently a Red Herring panelist in San Jose, where some CEOs predicted the slow death of enterprise software and the pending victory of the SaaS way.

While I am big believer in the SaaS business opportunities and the first one to advocate beginning enterprise solutions from a SaaS angle, I believe that a complete collaboration offering ultimately needs to support all the deployment modes possible, including the hybrid ones.

I agree that today’s “enterprise software” is broken and has become increasingly (even ridiculously!) expensive to extend and to maintain. However, the solution is not to remove choice from the users, but rather to fix the problem at its source: the enterprise software architecture. (see good post from Neil Robertson on Why enterprise software is Not dead)

6) Asynchronous Over Real-Time.

asynchSoftware vendors occasionally think that they have an embryo of a collaboration system because they have some real-time technologies (e.g., web push technologies for co-browsing). However, I disagree. Real-time technologies are good tools to build a collaboration system, but they are no more collaborative than any other low-level technology. In fact, Facebook, and before that, email, has shown that most collaboration happens in an asynchronous fashion rather than in real-time. Facebook CEO Mark Zuckerberg articulated this fact in one of his keynote addresses, where he discussed the increasing number of opportunities for two people to communicate if they do not have to be at the same place at the same time. Although obvious, we technologists often get overexcited by our own technology.

7) Social Networking Inside.

socialLast on my list is social networking, because at this time, it is overhyped. It is also last, because a system that follows the first six points would already be relatively unique. Last, because in the end, it will be put first anyway. Nevertheless, a better-connected organization is a more effective one, so social networking practices and technologies are great ways to improve an organization’s internal connectivity.

 

So, here it is, a first take at seven design principles for the next generation of collaboration solution. In collaboration, we have assumed for too long that users will learn new ways of doing things that enable them to accomplish the task at hand more quickly. This, unfortunately, is not true. Rather than assuming that users will adapt to the software, it is the software that should adapt to the users. In short, do not ask a user to spend time in order to save time.

6 Responses to “Seven Design Principles for Enterprise Collaboration 2.0”

  1. Fredericton Designers » Blog Archive » Seven Design Principles for Enterprise Collaboration 2.0 Says:

    [...] Link to the original site [...]

  2. 7 principes de design pour un site de collaboration 2.0 « NSI Solution - Entreprise 2.0 - Amélioration Continue - Génie Industriel Says:

    [...] 7 principes de design pour un site de collaboration 2.0 Voici les 7 principes de design pour un site de collaboration 2.0 (en traduction libre) tel qu’énoncés par Jeremy Chone sur son blogue Bits & Buzz. [...]

  3. Bob Says:

    This is a good list of the mechanics that an enterprise would need to follow to be successful but… even following these they won’t be.

    Enterprises will need to understand the more than this to be successful. How do people self organize? How to nurture these groups?…

    When people self organize they create their own Network that isn’t the same as the classic Org. Chart. The corporation will have to nurture this network as well as the classic org. chart which at time will be in conflict.

  4. Jeremy Chone Says:

    @Bob Agree and this is kind of covered by the Social Networking Aspect (#7). However, I concede that it is different and might need its own design principle.

  5. Medisoft Says:

    In my situation, I have found social networking to be a great source or marketing and enterprise. Interesting article, thanks for the post!

  6. web developer Says:

    I agree, enterprise collaboration is ways down from coming close to the benefits of SaaS. But nonetheless, there are pros and cons for both. Great post, thanks for sharing.