Transparent Office

Structure and Corporate Communities

Dawn Foster of Fast Wonder Consulting recently posted a really useful, practical discussion of different types of structures for corporate communities. She puts corporate communities into three categories: emergent, highly structured, and adaptive.

• Emergent Approach: Community has little or no structure at launch, and a structure emerges over time
• Highly Structured Approach: Communities have a detailed, thought-through taxonomy at time of launch
• Adaptive Approach: The community launches with a few very broad categories, from which structure emerges and develops over time

Dawn advocates the Adaptive approach in most cases as being the most flexible and easiest to implement. I wholeheartedly agree, and will chime in with a few supporting observations.

I've seen plenty of examples of communities that launched with a high degree of structure. Many of them worked...after a fashion. But these "communities" usually are really publishing tools where a few people post things and everyone else consumes. (I've seen this a lot in professional services firms, which tend to have large knowledge management or practice staffs whose very job it is to post industry updates, pitch packs, methodologies, etc.) This isn't necessarily a bad use of the tools; many companies are much happier on a collaboration platform than on a larger, more expensive, and less user-friendly Content Management System. But it's not exactly community.

I've also seen examples of successful communities following the emergent approach, but this tends to work best with very small groups (e.g., under 30 or 40 people), and where there's extremely strong momentum going into the project.

With respect to the Adaptive approach, I think it's very important to pick the right types of categories. Because of Wikipedia, many people think "structure" has to be something encyclopedic like industries, geographies, market segments, etc. But what I'm seeing in the field is that a structure is often most effective when it guides a user as to the types of actions or activities the tool supports. In that spirit, here are some structural categories worth considering:

• Instead of email
• Meeting notes
• Feedback
• Big wacky ideas
• Overheard from customers
• Questions and Answers
• Reusable documents
• Company processes

What other categories have you seen work well? I'm curious to hear!

In-the-Flow with Acumen Fund

I blog a lot about the importance of in-the-flow collaboration: the idea that organizations adopt collaborative tools only when those tools are integrated into the flow of daily work. That idea resonates with a lot of readers, but so far I haven't said very much about how to do it.

The other day, I saw a really great example of an in-the-flow collaborative tool at Acumen Fund. When project champions Brian Trelstad and Rob Katz  set out to implement a knowledge management system, they quickly realized that the organization already had all sorts of processes and mechanisms for capturing knowledge and ideas. The question was how to tap into those resources in a way that would create transparency, access, and reuse across the organization's four locations in Hyderabad, Karachi, Nairobi, and New York.

Brian and Rob came up with some really great techniques to redirect Acumen's flow of work through the collaborative workspace:

• "Instead of email": Acumen already had a culture of sending company-wide emails containing interesting articles and thoughts and triggering discussion threads. But those threads were lost in everyone's in-boxes and archives. So Brian and Rob created a button called "Instead of Email" and then approached Acumen's top emailers to use Instead of Email instead of email. Acumen even created a set of email aliases that allow users to send emails to Instead of email. (The language gets a little counter-intuitive...kind of like going to a Start menu to shut down your computer.)
• Meeting notes: Acumen already had a culture of taking detailed meeting notes, especially at company-wide "Monday Morning Meetings." Those notes are now taken online, automatically tagged as meetings, with a standard naming convention including the date and meeting name. Acumen's leadership team reinforces use of the workspace by posting agendas and notes in the workspace rather than email
• Contact details: The company directory, complete with contact information, conference room dial-ins, and other logistical details are all kept in collaborative workspace. It may not be sexy, but it's mission-critical information and it keeps people coming back. And putting it in the wiki makes it easy to keep up to date.
• Office clocks: With offices in four time zones, Acumen's staff is constantly calculating local times for meetings. Rob found a Google widget for international time clocks, and dropped it into the workspace. It was cheap and really really useful.

Finally, there was the way Brian and Rob launched the new workspace. They called an office-wide meeting in New York (Acumen's biggest office), and kicked it off with a scavenger hunt. Participants were given 20 questions to answer from information that was already in the workspace. It was a fun way to launch the effort and, more importantly, it forced everyone to log in and try it out for themselves. The winning team got a pair of Starbuck's cards, which they promptly gave to the runners-up. "We don't like coffee", they announced proudly. "We just wanted to win."

A Funny Thing Happened on the Way to the Intranet

This week a couple of customers I've been working with are unveiling their new corporate intranets...on Socialtext. What's interesting about both customer is that they didn't set out to replace their intranets. Originally, they were looking for knowledge management systems, to replace existing M-drives and document management systems. But as we started working together, both customers had an a-ha moment when they said, "I don't see why we wouldn't use this as our entire intranet."

These customers reflect a fundamental shift in the way companies are thinking about their intranets. Companies don't traditionally think of their intranets as places to collaborate. Since their creation in the 1990s, intranets have been seen as publishing vehicles, places where employees come to consume information published centrally. In the intervening years, intranets have improved on many dimensions. They've become more attractive, more dynamic, more animated, and more personalized. But they haven't really become more collaborative.

As companies have begun to embrace Enterprise 2.0, many began to add collaborative tools like blogs, wikis, social networking, etc. Not surprisingly, collaborative tools first made their appearance as specialized destinations separate from the intranets themselves. Intranets sometimes linked to those tools, and sometimes didn't. But the intranets themselves were almost never collaborative places.

That's beginning to change. As companies digest the implications of broad-based collaboration, they are looking at their intranets as collaboration opportunities. They are using the intranet to distribute publishing of critical information, addressing every intranet's single biggest problem: keeping information up-to-date. They are adding spaces to post ideas and innovations right on the intranet homepage, and weaving social networking into the very fabric of their company's information flows.

Better still, companies are using Enterprise 2.0 tools to reduce the cost and accelerate the launch of their intranets. A traditional intranet launch (or re-launch) project within a mid-size company can easily take a year or more. Debates over design, publishing access, and information architecture consume months, and must be completed before any code can be written. In Enterprise 2.0 model, companies can build intranets much faster and more iteratively, getting a first draft in place within a few weeks and filling in the details over time.

This blurring of publishing and collaboration mirrors the broader trend on the consumer web. In the early days of Web 2.0, collaborative tools like MySpace and Facebook were isolated applications that users navigated to from traditional publishing portals like Yahoo! Increasingly, however, these collaborative spaces are becoming the platform through which users access all kinds of content and applications.

As one pundit put it (can someone help me out with the attribution?), for today's users, MySpace and Facebook are the internet. I predict that in three years' time we'll be saying something similar about intranets.

Predicting Enterprise 2.0 Adoption

The National Computing Centre in the U.K. has posted an interesting article by Martin White on Achieving effective Enterprise 2.0 adoption. The center of the article is a list, developed by INSEAD's Morton Hansen, of 10 statements to diagnose an organization's readiness to adopt Enterprise 2.0. It includes things like:
-Employees feel that they have a duty and a freedom to help others even if there is no immediate benefit, and indeed even a short-term impact on their own work performance.
-Employees willingly work together with colleagues from other units to solve specific problems.
-The organisation has clearly stated principles related to the value of teamwork and cooperation.
-Examples of good practice and success in knowledge exchange are given wide publicity and recognition.

White is right to warn IT managers off the build-it-and-they-will-come approach. And I really like the idea of a simple diagnostic to assess an organization's readiness to embrace Enterprise 2.0, but I think White has the wrong list.

White's list runs together many different types of collaboration: working across organizational silos on specific tasks, working within an organizational silo on specific tasks, codifying personal knowledge for general consumption, picking up the phone to call someone you know, picking up the phone to call someone you don't know, etc. The cultural conditions vary significantly by the type of collaboration, so you can't lump them all together this way.

The common denominator across the list is collaboration. But being "collaborative" is a pretty low bar these days. In most knowledge-intensive organizations, people have to collaborate. The they have to work together on projects, on teams, in meetings, etc. There are very few jobs left where you can be effective working all by yourself.

And people already have a collaboration tool: Email. Even the most "uncollaborative" people send dozens of emails a day.

So the meaningful question here is not "Is your organization collaborative?", but rather "How will your organization collaborate?" Will your employees collaborate through email, or will they use Enterprise 2.0 tools like blogs, wikis, social networking, RSS feeds, etc.?

As I see it, the difference between email and Enterprise 2.0 boils down to a few fundamental contrasts:

• Enterprise 2.0 posits the group as the primary unit of activity; email posits the individual
• Enterprise 2.0 requires high-speed network access; email can accessed offline, via BlackBerry, etc.
• Enterprise 2.0 is the challenger; email is the incumbent

In that spirit, let me offer up a much simpler version of the White/Hansen checklist:

1. Do employees work in groups or teams? (Extra credit if individuals typically work with multiple groups in parallel or group membership changes frequently)
2. Do employees have constant network access, or are they frequently offline due to travel, field visits, etc.?
3. Do employees use multiple online tools to complete their daily work?

If the answer to all 3 questions is yes, you've got a pretty good shot at Enterprise 2.0 adoption.

DMS and Collaboration Suite: Friends not Foes

What's the relationship between a document management system (DMS) and an enterprise collaboration suite like Socialtext?

The other week, I was meeting with a project team at a large retail bank who is bringing Socialtext into their organization. It was a cross-functional team, representing different parts of the IT organization. One of the participants was the manager responsible for the company's document management system. He wanted to know how this project would change his world. Would Socialtext replace the DMS? Would the two work together?

It's a fundamental question. Companies have already made six-, seven-, and even eight-figure investments in their document management systems. Those systems house thousands or even millions of documents. And while many companies are attracted to the ease and flexibility of Enterprise 2.0 collaboration tools, they are understandably jittery about potentially cannibalizing document management systems which have so much investment and content behind them.

The first thing that companies should understand is that document management and collaboration are distinct activities. Document management is all about workflow, control, and risk mitigation. Its objective is summarized perfectly by the two words in its name: "documents" and "management". It got its start in the legal departments of pharmaceutical companies, who were concerned to make sure that their companies were producing documentation in full compliance with regulatory requirements. A DMS thrives where there are a) documents already being created as part of a business process; and b) those documents need to be closely checked in, checked out, supervised, edited, approved, and stored following a consistent and audit-proof process.

Collaboration, by contrast, is all about people working together to share ideas, notes, questions, comments, etc. Collaboration does not typically follow a standard process; it is much more free-form and free-flowing. Documents are not typically the format of choice. Asking a question or creating a meeting agenda or to-do list doesn't require a document; it just requires typing some words and putting them where other people can see and edit them. That's why so many people simply fire off an email when they collaborate; it spares them the unnecessary step of creating a document.

When you look at it this way, document management and collaboration don't have very much to do with each other. So why is there a question about how the two relate?

The two activities get confused because document management, like collaboration, involves creation of content by multiple people. For many companies, the DMS is the first tool they implemented that enabled more than one person to touch a single, centrally stored piece of content. And the document management vendors began to capitalize on the opportunity by introducing document-centric team rooms (like Documentum's eRooms, for example.) As a result, many companies began to use the DMS as a collaboration tool. The DMS wasn't very good at it. It required every piece of collaborative content to be saved as a document. Search was cludgy or non-existent, and everything had to be filed in a nested folder structure. But it was better than nothing, or email.

Last week I saw first-hand a good example of this phenomenon recently at a major executive search firm. They wanted a way to collaboratively publish questions, comments, slides, bios, etc., and engineered an entire intranet around eRooms. It was cludgy, and adopted primarily by power users who took the time to create a Byzantine taxonomy of folders and sub-folders.

All of which brings me back to my meeting with the retail bank. When asked about the relationship between DMS and collaboration tools, what I said was that some of the content in a typical DMS really belongs there. These are the documents associated with highly regulated processes. But most of the content in a typical DMS--to-do lists, meeting notes, press clippings, conversations, working papers, personal observations--doesn't really belong there. It's in the DMS because there was no good place to put it. That's where a collaboration suite can do a much better job. A good collaboration suite can liberate that content from the tyranny of documents and nested folders, and will encourage people to use it for actual working materials.

In many cases, you will want to integrate the two. Law firms, for example, are absolutely dependent on their document management systems to manage their filings and other legal documents. But we're increasingly seeing them set up collaboration suites to capture all the discussion around the documents, how to use them, what they mean, and so on. The two systems are integrated with links from the collaboration suite into the corresponding DMS records.

What I'm saying amounts to this: Use your document management system to manage documents, and use your collaboration suite to collaborate.

Business Week and Professional Immortality

Business Week just published a must-read article called "The Knowledge Handoff: How corporations are scrambling to tap the expertise of baby boomers before they retire." I'm really glad to see this story being picked up. Many of the companies I talk to, from pharmaceuticals to construction, are worried sick over the expertise that is coming up for retirement in the next 10 years. They're desperate to retain it, but don't know how.

Business Week got some important things right here. Most importantly, the stories recognizes that companies won't solve the problem by cramming employees into classrooms and handing aging boomers a piece of chalk. Instead, the article counsels that "companies should encourage soon-to-be retirees to use digital tools like wikis, blogs, and instant messaging." Business Week frames the issue as a generational gap, arguing that boomers need to use high-tech tools to communicate with Gen Y'ers.

Business Week is giving good advice, but for the wrong reasons. It's not that Gen Y'ers can only communicate on wikis and IM. The real insight--the one I wish Business Week had focused on--is that when employees use Enterprise 2.0 tools (like wikis and blogs) to collaborate, they create valuable assets which endure even after their creators have retired. If more boomers did their work in collaborative tools instead of emails and other private forms of correspondence, their colleagues would retain access to their ideas post-retirement. Just think of it as professional immortality.

Professional immortality. If that's not a good reason to use a collaborative tool, I don't know what is.