Archive for September, 2009

Jive SBS Structure Best Practices, Part 3

September 18th, 2009

The following is a result of Jive Client Services’ extensive work with many large clients who have deployed Jive SBS for employee engagement purposes. It is Part 3 of a three-part series. Read Part 1 and Part 2 before reading this.



In Part 1, we described the emergent and prescribed approaches to creating an initial Jive SBS structure. A blend of the two is recommended.

In Part 2, we explained what situations were good candidates for Jive SBS Spaces and Groups, accompanied by recommendations about how to design and manage them.

In Part 3, we’ll discuss initial space taxonomies and groups that provide enough comfort for people who need to browse, and that offer enough of a pattern of use to seed proper taxonomy growth.

Taxonomy Patterns

Probably the most important thing to keep in mind when structuring your initial Jive SBS taxonomy is that it’s NOT just about publishing content, and it’s NOT just about broadcasting one-way messages. You probably already have applications for these uses.

Jive SBS is about engaging people about specific topics and content. Of course, many clients find that Jive SBS’s ease of use entices the publishers and broadcasters in their organization, and that’s perfectly fine. Just help them to understand that people will talk about their stuff, and they should respond.

The Lobby Pattern

Note: This pattern was first shared with us by Claire Flanagan. Thanks, Claire!

In the Lobby Pattern, spaces are used as entry points to a particular topic, with relevant sub-communities highlighted on the Overview page. If it makes sense for the topic, this is where the “official” general blog resides, where people can ask general topical questions, and/or where general information about the topic is posted. For more specific focus, people are encouraged to browse any existing sub-communities.

Sub-communities about the topic can exist as Jive SBS Groups and/or sub-spaces. Encourage people to create Groups if membership and self-service group management matters more than the granular permissions, controlled creation, and hierarchical order available with Spaces. Ensure they tag their Groups with the main topic at the very least. For example, groups created about R&D should include “R&D” as a tag. This makes the groups more findable when people who search include “R&D” in their search string. Make this an element of any training materials about Groups.

The lobby space’s manager lists these relevant groups – and in some cases, highlighted sub-spaces – in a Formatted Text widget on a space’s Overview page. As mentioned in Part 1’s discussion about the emergent approach, the goal is to make the groups more findable for participants who choose to browse the space taxonomy. It isn’t necessary to add all groups, because when a participant visits the Overview page for any group, he or she will see related groups in the Similar Groups widget. The space manager should refresh the list of groups periodically by adding new groups and removing those that become inactive.

Here’s an example:


Here’s another example:


A third example uses the Lobby Pattern to educate people how to use the Jive SBS features that sponsors want to promote the most. At the same time, it clearly encourages people to create Groups (and avoid requesting spaces):

  • Help
  • About Groups
  • About Profiles
  • About Blogs
  • Feedback
  • Ask a Question
  • Break Room

In very large organizations, where it is practically hopeless to try to create a space taxonomy that would make sense to all, the Lobby Pattern can provide a browsing experience that helps new participants feel comfortable, without overwhelming them.

The Units Pattern

It is inevitable that someone on the planning team or a sponsor will want to create spaces for any number of “units”. These are usually geographies, departments, divisions, functions, products, services, customer segments, partners, competitive segments, industries… you get the idea.

There’s nothing wrong with creating spaces for these units, as long as someone agrees to take care of each space, as explained in Part 2. Don’t create a bunch of spaces for all the organizational units in your company, and expect them to thrive without owners. Resist the urge to organize everything for everyone in advance. Remember, this isn’t just about making content available – it’s about interactive communities.

You CAN encourage a Units Pattern taxonomy growth over time, however. For example, if you anticipate that functions across the organization will want their own spaces – Marketing, Finance, IT, R&D, Communications, HR – either find people who will serve as community managers, content contributors, and advocates for each and every space, or do so with just one. Create it as a sub-space under a “Lobby” patterned space called “Job Families,” or “Functions,” like this:

  • Job Families
    • R&D

Usually, people will notice that R&D has a space, but HR doesn’t. This will prompt them to ask for their own space, at which time you can educate them about what it means to manage a space. Perhaps you can educate them about the Lobby Pattern as well, so that they realize they don’t have to create and manage a bunch of sub-spaces in addition to their Lobby space.

Again, it’s all about ownership by the people, not the implementation team.

If you’re concerned about upsetting potential key stakeholders by not representing the units they care about in the initial taxonomy, then reach out to them first. Communication about what you’re planning will go a long way to mitigate obstacles to your success.

Initial Taxonomy Example

A combination of the Lobby and Units patterns tends to be a solid way to start for large organizations with somewhat of a traditional culture. If your culture is more collaboratively and Web 2.0 savvy, this might be too much structure to begin with – try it with your initial participants, and adjust as you go.

Here’s an example – the dark items have assigned community managers; the grayed out items represent future growth:

  • Using Brewspace (peer support community)
    • Feedback
    • Success Stories
  • The Fighting Five (key strategic initiatives)
    • Customer Experience (lobby)
    • Globalization (lobby)
    • Becoming One Company (lobby)
    • High-Performance Teams (lobby)
    • Being Green (lobby)
  • Innovating Business Processes (key strategic processes)
    • Idea-to-Market (lobby)
    • Standard Operating Procedures (lobby)
    • Proposal Creation (lobby)
  • Products and Services (lobby)
    • Plastics (product family lobby)
    • Adhesives (product family lobby)
    • etc.
  • Functions
    • R&D
    • Finance
    • HR
    • Marketing
    • etc.
  • Businesses
    • Corporate
    • Americas
    • APAC
    • EMEA
    • Acme Subsidiary
  • Break Room (off-topic discussions)


  • Combine the emergent and prescribed approach to structure, placing emphasis on emergent.
  • Ensure Spaces and Groups have people who will care for them.
  • Create Spaces with the four “keys” in mind.
  • Create a structural pattern that new participants will understand and that will prompt them to create Groups or request valid Spaces.

One last thing: don’t be afraid to change the structure as you go. It’s a living, dynamic thing, just like your company.

Jive SBS Structure Best Practices, Part 2

September 16th, 2009

The following is a result of Jive Client Services’ extensive work with many large clients who have deployed Jive SBS for employee engagement purposes. It is Part 2 of a three-part series. Read Jive SBS Structure Best Practices, Part 1 before reading this.

Special shout-out to my colleague and friend, Kathryn Everest, for writing this entry.


Jive SBS Spaces

Types of Spaces

In a large enterprise, space structures should reflect:

  • key enterprise knowledge domains (e.g., products, customers, industries) where there is significant business value to be gained by improving collaboration at the enterprise level
  • key strategic topics where your organization is trying to stimulate enterprise conversation and collaboration (e.g., Innovation, High-Performance Teams, Growth, Globalization, Customer Focus)
  • key business processes where there is a strong collaborative requirement (e.g., idea-to-market product development methodology)
  • key stakeholder groups or business units (e.g., executive sponsors’ groups)

Spaces are relevant for:

  • different or granular levels of security – spaces can either inherit the permissions of its parent space, or be completely different
  • completely different user communities than what exists.  Subgroups of a user community, however, do not always need a subspace.  Consider using tags and categories (see below) to view content by topic, or use a Jive SBS Group
  • different branding/themes – a space can have a completely different look and feel from other spaces
Space Management

Ensure each space has an owner, and that users understand how the space is managed. If there are no owners or champions of the space, it may surface a larger organizational issue around accountability.

Questions to ask people who request a Jive SBS space:

  1. Is it really a strategic area (see the “keys” above)? If so, there should be accountability somewhere in the organization.  If not, the topic may lend itself better to being deployed as a group, and not as part of the formal space hierarchy.
  2. What will be offered in the space? In addition to displaying information, what collaborative capabilities will be in the space? Communities are NOT just about content – they’re where people collide with content and with one another. To facilitate this collision, a space must have at a minimum one or more of the following elements:
  • Blog
  • Document (e.g., wiki-style pages and files) sharing
  • Discussions
  • Video (if implementing the video module)

It is not mandatory, but recommended that each of the elements are stewarded rather then just enabled.  This means that for each element that is enabled, there is a specific plan in place.  For example, if the blog is implemented, what is the plan for the blog?  Will there be a group of people who will blog regularly?  Will it be open to anyone to blog?  In the Products space for example, perhaps a general product blog can be managed by product marketing, but the space wouldn’t provide a discussion area or document sharing.  Product-related documents and discussions would be available in sub-spaces dedicated to specific products.

If a document or discussion were to be available, how would they be managed?  Would anyone monitor the space to ensure questions are answered within a reasonable time frame?  Would anyone monitor the documents to ensure they are tagged appropriately and stored in the correct space?  If it is difficult to identify what types of content would exist, or who would be interested in helping to ensure it is properly managed, this could be an indication that there isn’t a sufficient need to include the capability.

Space Layout

Develop a guideline for space layout to provide a familiar environment for participants who are members of multiple communities. For example, always place the Actions widget on the right, Categories (“Topics” in the screenshot below) on the left. Ensure that every space initially created has been designed – don’t rely on the default space layout.


Jive SBS Groups

Groups were included in Jive SBS in version 2.5, in direct response to customer requests for a more simplified, self-service approach to forming ad hoc places. They are an essential part of the structure, providing a method for the formation of more organic and/or smaller areas, which lends itself to an emergent approach to structure.

Groups have a strong membership component, unlike spaces – there is a Members tab, in fact. Because of this, groups are a great way to uncover pockets of like-minded people within your organization, and provide an opportunity for them to discover one another.

Types of Groups

Groups are typically used for:

  • Committees and teams
  • Communities of Interest dedicated to sharing best practices around topics such as social media participation, iPhone or BlackBerry devices, Web 2.0, Being Green, etc.
  • Communities of Practice dedicated to sharing best practices and support around a profession or designation, such as .NET, Project Managers, Architects, Sales Engineers, Community Managers, etc.
  • Social groups, such as a cycling club, book club, sports enthusiasts, etc.

Since groups can be public or private, create usage patterns and include them in training materials to demonstrate when to use public versus private groups. This will assist participants in deciding what type of group to create or request.

Group Management

Groups do not include the variety of management options that spaces do. There are no granular permission levels, and group managers do not need access to the space administration console in order to manage their group. Primarily, the person who creates the group is the group administrator – he or she can assign this permission level to any other group members through the end user interface.

Group Layout

As with spaces, design of the group’s Overview page is important. The default layout, however, is typically good enough, and provides uniformity across groups.


Tags and Categories

Tags are keywords that can be added to any type of content by the author. Additionally, participants can tag content created by someone else by using bookmarks. Tags are the “Web 2.0” way of categorizing and making content more findable. A rule of thumb is to tag content with words or phrases you might use to search for it later. Create a tag phrase by using hyphens or underscores between the words, instead of spaces. Initial participants should be well trained in the use of tags.

Space managers create categories in order to collect tags into logical groups. These categories appear as choices in a drop-down selection box within each content type (documents, discussions, blog posts), and as a list of folders within the Tag Group widget on the Overview page for spaces. The tags within a tag group are displayed when the tag group is selected within a content type. Participants can select or manually type multiple tags from one or more categories. When a category is selected within the Categories Widget, all content with tags in that category will be displayed.


Not sure when to create categories? Review the emergent vs. prescribed approaches described in Part 1 for details.


Stay tuned for Part 3 later this week, which will suggest an initial space taxonomy and initial groups that provide enough comfort for people who need to browse, and that offer enough of a pattern of use to seed proper taxonomy growth.

Jive SBS Structure Best Practices, Part 1

September 14th, 2009

The following is a result of Jive Client Services‘ extensive work with many large clients who have deployed Jive SBS for employee engagement purposes. It is Part 1 of a three-part series.


There are generally two approaches to creating an initial Jive SBS structure: emergent, and prescribed. An organization’s culture dictates which approach is predominant.

Since many organizations are in the process of a cultural evolution about how they collaborate and network when they first implement Jive SBS, the best approach to structure involves a combination of emergent and prescribed. Jive SBS can be a useful environment to help participants transition from old, traditional collaboration and networking behaviors (“Enterprise 1.0”) to a newer way of collaborating and networking (“Enterprise 2.0”). To aid in this transition, the structure should be a combination of the old and familiar, and the new and innovative.

Emergent Approach (few Spaces, many Groups)


The emergent approach involves creating very few spaces in which participants interact about a wide range of topics. It also involves allowing participants to create groups for whatever they need. Participants are encouraged to use tags extensively in order to help others find their content more easily.

Over time, the Enterprise Community Manager reviews the content being created, how it is being tagged, and how participants interact with one another about that content. From this, the community manager can usually determine a structure that makes sense to the majority of participants. Implementing more structure based on this analysis can help to better organize participant interaction and content findability. It also enables participants to more finely tune their subscriptions and Your View page to focus on the people, places and content they care about.

Here is an example list of initial spaces designed to let structure emerge over time:

  • Help and Feedback: peer support community about how to use Jive SBS and how to improve it
  • Exploring Ideas: where thoughts are shared and discussed about anything related to the company
  • Questions and Answers: where people can post questions and answers about anything related to the company
  • The Break Room: where people can discuss anything not related to the company
Implementing in Jive SBS

To implement this emergent structure within a space, the community manager can create categories – collections of the tags that participants have been using – and display those categories as a list of folders within the Categories widget on the space’s Overview page. Sub-spaces can also be created to provide better organization. Content from the original space can be moved into these sub-spaces, and spaces can be merged together.

To implement this emergent structure for groups, the community manager reviews the Group directory’s tag cloud, then determines which groups to relate to which spaces. She or he adds a Formatted Text widget to a space’s Overview page, then lists some of the groups related to that space’s topics. The goal is to make these groups more findable for participants who choose to browse the space taxonomy. It isn’t necessary to add all groups, because when a participant visits the Overview page for any group, he or she will see related groups in the Similar Groups widget.

The emergent approach works best if new participants are instructed to use the search function to find people, content, and places.

New participant confusion

The emergent structure approach tends to cause confusion for new participants. This is because they typically expect a browsable taxonomy, similar to their experience with other software applications (e.g., shared file drives, corporate intranet, email folders, desktop file folders). To reduce this risk, repeatedly reinforce the use of search over browsing, and encourage content creators to use tags consistently. Accomplish this through training materials, the telling of success stories, and community email newsletters.

Note: Seasoned participants rarely browse the space taxonomy or the group directory, because they’ve learned how to fine-tune their Your View page and various subscription and notification selections to follow the people, places and content they care most about.

Duplicate groups

Understandably, this approach can lead to the creation of duplicate groups about particular topics. Since groups have a strong membership element, however, many groups about a particular topic can encourage people in different parts of the organization to discover like-minded people that they weren’t aware of before. You must be prepared to tolerate duplicate groups and group proliferation. Some structure can be applied, however, by manually relating groups to a space, as described earlier.

Routine manual “gardening”

While this approach can sometimes feel chaotic and disorganized, and requires routine “gardening” on the community manager’s part, it is extremely effective in generating a structure that makes sense to most participants. This is because an emergent structure tends to reflect how people truly think about and interact about your organization’s people, business processes, functions, business units, competitors, products and services, etc. Such structures can lead to more meaningful and more sustained participation over time.

Prescribed Approach (many Spaces, few Groups)

The prescribed approach is a more traditional approach to structure. It is most commonly used in creating structure for corporate intranets and shared file drives, for example. This involves creating several spaces and sub-spaces based on the implementation team’s perception of what will make sense to most participants. It also involves limiting the creation of groups by implementing a request process.

Here is an example structure of initial spaces designed to prescribe structure from the outset:

  • Help and Support
    • Getting Started
    • Success Stories
    • Feedback
  • Corporate
    • Communications
      • Internal Communications
      • Corporate Communications
    • HR
      • Compliance
      • Benefits
      • Job Postings
    • Finance
    • Legal
      • Regulatory
      • Intellectual Property
    • Manufacturing
    • Marketing
      • Competition
        • Competitor 1
        • Competitor 2
        • Products
          • Brand A
            • Product 1
            • Product 2

            Brand B

            • Product 1
            • Product 2
        • Services
    • IT
    • R&D
  • EMEA
    • Communications
      • Internal Communications
      • Corporate Communications
    • HR
      • Compliance
      • Benefits
      • Job Postings
    • Finance
    • Legal
      • Regulatory
      • Intellectual Property
    • Manufacturing
    • Marketing
      • Competition
      • Products
      • Services
    • IT
    • R&D
  • APAC
  • Americas
  • Etc.
Implementing in Jive SBS

To implement a prescribed structure, the implementation team determines which main spaces and sub-spaces will make the most sense and be the most familiar to a majority of participants. They also determine which categories to create within each space, as necessary.

Participants can request a group through a request process. This process can, for example, require that the requester describe what the group will be used for, whether they’ve already searched for any existing groups or spaces that will meet their needs, and indicate that they are legally responsible for the group’s content and members’ interaction with one another.

Participant confusion

Creating too much structure early on can be confusing, invoking the question ‘where does this go?’ when participants attempt to create content. This can result in early abandonment and slow adoption over time. Less structure and good examples and training materials can reduce confusion.

Collaboration stifling

Requiring participants to request groups through a laborious process can result in the stifling of organic collaboration and business networking. A simple or automated request process, or no process at all can limit the stifling.

Content scattering

Creating too much structure inhibits critical mass in any one area.  The information becomes too scattered to get diverse parts of the organization to interact with one another, and to create opportunities to discover new information. Less structure and education about the use of tags to organize content can encourage a critical mass of interaction and content about particular topics.

Empty spaces

Creating spaces without any content in them, or without identifying people who will manage those spaces leads to a dead, empty environment. In general, only create a space or sub-space if someone or a collection of people are committed to maintaining it.


Stay tuned for Part 2 later this week, which will explain what kinds of spaces and groups to create to blend the emergent and prescribed approaches.

Thrilled to be speaking with my client at Enterprise 2.0 Conference!

September 8th, 2009

Last Friday, Steve Wylie, General Manager of the Enterprise 2.0 Conference, let me know that myself and Miles Appel, Executive Director, Intranet Web Capabilities, ISG, Kaiser Permanente, will be speaking at the conference in San Francisco in November. I’m thrilled to pieces!

Here’s what we’ll be sharing at 4:15pm on Tuesday, November 3:

Making Health Care Providers Social: Kaiser Permanente’s Enterprise 2.0 Adoption
Kaiser Permanente’s success as a premier health care organization depends on connecting approximately 200,000 physicians, nurses, employees, and contractors to promote collaboration, the sharing of best practices, and overall continuous improvement. KP IdeaBook is a socio-collaborative environment that helps make this happen. Learn how we’re rolling out KP IdeaBook in a way that creates excitement and sustained adoption, while balancing the risk of introducing an open environment in a regulated industry and a traditional culture. We will also share how our Enterprise 2.0 vendor is helping us to develop adoption strategies.

Jive Software has been working with Miles and his team since January 2009 to plan a full launch of KP IdeaBook, an implementation of Jive Social Business Software for Kaiser Permanente employees. The organic adoption KP IdeaBook has experienced to-date helped to inform what I can only call the “Go To Market” (GTM) strategies that Kaiser Permanente and Jive have crafted to eventually bring IdeaBook to the approximately 200,000 individuals that provide health care to millions of members.

So, be prepared to learn, because we plan to go deep into the planning required to undertake such an adventure within a regulated industry and a traditional culture. We’ll also give you an idea of what you should expect from your social software vendor beyond technical configurations and customizations, and generic whitepapers about adoption tactics (and yes, I know Jive has those whitepapers, too. Rest assured, we back them up with reality.)

See you in November!