Jive SBS Design Practices, Part 3

March 10th, 2010 No comments »

The following is a result of Jive Strategic Consulting Practice’s extensive work with many large clients who have deployed Jive Social Business Software. It is Part 3 of a four-part series.

In Part 1, we explained how to use Barry’s Community Flower to determine the top three characteristics of your community.

In Part 2, we discussed the importance of identifying community members’ wants.

Express it!

Now that you have your top three characteristics identified in Part 1, and list of member wants from Part 2, let’s put them together to create your community’s overall expression. Once you do this, you’ll have successfully defined the boundaries of your community design!

Define the following elements:

  • Purpose: “What’s this site all about in two seconds or less? Because that’s how much time you have my attention before I split.”
  • Calls to Action: “OK, I’m here. What do you want me to do? Use clickable verbs to make it obvious.”
  • Motivation:  “What’s in it for me if I answer your calls to action? Is it what I want?”
  • Example: “What behavior do you want me to model? Give me an example.”

This example of expressive elements is based on the top three characteristics of Relationships, Sharing, and Groups. It is for a public community.

How do you design Jive SBS based on all of this?

Finally, we start talking about the technology.

Expression elements can help you decide the following:

Example

Nutshell

Your community’s Top Three Characteristics, member wants, and expressive elements can make it easier to design your site’s overall identity, and keep the design scope from creeping out of control.

If it doesn’t fit with your characteristics, member wants, or expressive elements, it doesn’t belong in your community.

What’s next?

In part 4, we’ll discuss how to map all this design goodness to Jive SBS capabilities.

Jive SBS Design Practices, Part 2

March 9th, 2010 No comments »

The following is a result of Jive Strategic Consulting Practice’s extensive work with many large clients who have deployed Jive Social Business Software. It is Part 2 of a four-part series.

In Part 1, we explained how to use Barry’s Community Flower to determine the top three characteristics of your community. Next, we determine your community members’ wants.

“I want to…”

People often forget to identify the needs/wants/objectives of their community’s members. Not doing so results in yet another cold, lifeless website instead of a potentially thriving community.

For an example of how to avoid this, see this reference to Groundswell’s case study about Proctor & Gamble’s BeingGirl site, in which the authors describe how P&G created a community to enable teenage girls to talk about teenage girl things, rather than tampons and menstrual pads – oh, I’m sorry, um, “feminine hygiene products” – can’t forget to sanitize biology for mass consumption, ha ha! I digress. Where was I?

Right.

To be thorough, you may want to do this next exercise for every persona that will interact in your community, but for simplicity’s sake, let’s just lump them all together for now.

If you’re designing primarily an employee community, think about what your fellow colleagues want to get out of it, keeping the Top Three Characteristics identified in Part 1 in mind. If you’re designing primarily a public community, think about what members – both customers/partners/prospects/developers and employees – want to get out of it.

BIG HINT: “What will members get in my community that they can’t get anywhere else?”

Here are examples for an employee community:

  • Find across all of ACME people who can help me get my work done (Relationships)
  • Tap into ACME’s broad collective experience to help me be more innovative in my work (Groups)
  • Give back – help others I may not know yet get work done (Sharing)

And for a public community:

  • Find education and marketing information that will help me sell more of ACME’s products (Content)
  • Build relationships with other ACME customers (Relationships)
  • Learn from ACME’s customers about what it’s like to be an ACME customer (Conversations)
  • Find what others are doing with ACME solutions and services (Sharing)
  • Tap in to ACME’s expertise (Groups)
But, they can get this somewhere else!

Especially in the case of employee communities, the “I want to…” examples above are seemingly already satisfied by existing collaboration and networking applications. I’m not going to get into the colossal chasm that all too frequently exists between what the business really wants and what IT forces them to use, but I’ll just pull a Dr. Phil here and say, “How’s that workin’ for ya?”

Usability – and all-employee access – matters. But, that’s a whole other blog post.

As for public communities, probably the top reasons potential members will participate – what they can’t get anywhere else – are access to your company’s “official” information and more importantly, your employees. However, if your people are already interacting with your customers/prospects/partners on third-party message boards or in Facebook or LinkedIn groups or Twitter or whatever, you’ll obviously need to entice those employees to stop doing that as much there, and start doing it in your community more (assuming this jibes with one of your top three characteristics).

Then, all those other social media interactions become engagement channels where employees can drive participation to your new community.

Now what?

Stay tuned for Part 3, where we’ll add the top three characteristics to these member wants to figure out how to design your Jive SBS community.

Jive SBS Design Practices, Part 1

March 8th, 2010 9 comments »

The following is a result of Jive Strategic Consulting Practice’s extensive work with many large clients who have deployed Jive Social Business Software. It is Part 1 of a four-part series.

It’s not about you, Corporate MarComm. It’s about we.

It’s not just another website, and yet many approach the design of their community site the same way they approached their intranet or corporate Internet site.

Which are usually all about one-way communication and passive consumption.

To avoid doing this with your community’s design, try using what we here at Jive call, “Barry’s Community Flower” to figure out what your community is all about. This thing actually grew (ha ha!) from Gene Smith’s Social Software Building Blocks (which grew from a few other frameworks), but we like to name our stuff after the peeps who bring it to our frontal lobes.

What do the petals mean?


Can you identify what the main characteristic is?

To spark your thinking, check out these communities, powered by Jive SBS.  See if you can figure out what the main characteristic is.

Identify your community’s top three characteristics

Now, pick the petal that best reflects what it is you’re trying to accomplish with your community, based on:

  1. Corporate objectives“ACME Inc. needs to get abc from the community”; and
  2. Member objectives“I really don’t care what YOU need, ACME Inc., but I want to do xyz here.” (more on this in Part 2)
How to pick your petals
  1. A facilitator draws the flower on a whiteboard/flipchart/napkin/back of her hand.
  2. Everybody gets to pick JUST ONE petal, silently. Shh.
    Note 1:
    It’s not like people are going to do ONLY that one thing, so don’t get your panties in a wad. They’re all relevant, but one has to be primary if you want an elegantly designed site.
    Note 2:
    Don’t think too much about the differences between these characteristics, as they will quickly all seem to mean the same thing, or overlap so much that you cannot make a choice.
  3. The facilitator goes around the room, asking for each person’s vote – she places a mark next to each petal that receives one.
  4. Usually, one petal will emerge as the primary community characteristic, and the next two petals that received the most votes become the two secondary ones.

Voila! You have determined the primary and two secondary characteristics of your community! Yay!

Now what?

First, make sure that your characteristics are in line with the community’s overall objectives. For example, talk/hug it out re: how “Relationships” will help meet the company’s objectives of “Driving Growth” – and make sure somebody is either taking notes or recording your conversation. Gold often emerges here.

If you simply cannot find a connection between the characteristics you’ve chosen and the objectives of your community, stick a tack in that discussion, and stay tuned for Part 2 in this series.

Jamie Pappas from EMC knocks one out of the park!

February 11th, 2010 No comments »

If you didn’t get a chance to attend the 2.0 Adoption Council’s webinar today (like me), I strongly encourage you to check out Jamie Pappasmost excellent presentation that shares valuable lessons learned about Enterprise 2.0 adoption and governance.

Thanks for sharing, Jamie!

Corporations are Really High Schools, Budget-wise

January 30th, 2010 1 comment »

(Disclaimer for the obtuse: This is a tongue-in-cheek post.)

Sales: Football team, the entire Sports program.

Marketing: They support the Sports program. Sometimes they’re the Cheerleaders (plenty of funding), sometimes they’re the Band (but they have to buy their own instruments and sew their own uniforms).

Engineering: Chess, Math, Science clubs (obviously).

Services and IT: A/V club. Mr. Sanders can’t very well fix his own projector, now, can he?

Social Media Strategist/Community Manager: Glee, Theater clubs, the entire Arts program (first one to get cut in a budget crisis).

What am I missing?

Smooshing Enterprise 2.0 and Social Media Together

January 8th, 2010 2 comments »

It’s been almost five months since I first scratched my head over the perception that Enterprise 2.0 and social media practitioners don’t ever mix their chocolate and peanut butter. I wrote that post soon after delivering this presentation.

Since then, I’ve conducted many strategic planning sessions with clients who are implementing online communities as part of their overall social media involvement, and have learned QUITE a bit about what sucks and doesn’t suck about trying to implement a nice, well-rounded social media approach.

Instead of blah blah blah-ing about it, I give you a short, incomplete list that you can challenge me about:

  • Employees throughout your organization should be able to listen to what customers, prospects, and partners are talking about, and DO SOMETHING about it. This isn’t reserved solely for Corporate Marketing or your PR Agency anymore. (Shameless plug: My company, Jive Software, realized this, and bought Filtrbox to help make this happen.)
  • Corporate Marketing can become Corporate Darlings just by including employees in writing social media guidelines and participating in social media activities. We non-Marketing folks are doing it anyway, so why not orchestrate us? (I recommend using my favorite Enterprise 2.0 application, Jive SBS, natch.)
  • Make an online community place just one component of your overall social media plan – drive prospects and customers and partners to a destination place. You Twitter and Facebook and blog about marketing events and promotions and press releases, yet include links to your cold, dead, brochure-like website. Why not link to where your online community is discussing it as well? (Hint: it sure makes it easier to listen and act when the higher-value conversations are all happening in one spot.)

Confession: This blog post included links to mostly cold, dead, brochure-like websites until I wrote that last paragraph.

Busy as a Bee

November 16th, 2009 1 comment »

beeI’ve been busy.

It’s been awhile since my last post due to it being Conference Season (shh! We’re hunting vendor swag!), and to the passing of my father.

Here are a few things I’ve learned in the past few months, in no particular order:

  • My company has honest-to-goodness fans as customers. If you’d like to hear what they presented at JiveWorld ‘09, sign up now. And, they’re doing some wicked cool things with Jive SBS. We recognized a few of them, including UBM, NIKE, CSC, The National Journal Group (for work with the U.S. Congress), Kaiser Permanente, and SwissRe.

  • My daughter’s Disney Wisdom was a surprising comfort to me these past months – “Circle of Life, Mommy.” Thank you, Lion King.

Jive SBS Structure Best Practices, Part 3

September 18th, 2009 4 comments »

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.

—–

Re-cap

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:

R&D_Lobby

Here’s another example:

PS_Lobby

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)

Summary

  • 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 5 comments »

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.

Clearstep_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.

social_media_ninjas_Group

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.

Tags_TagGroups

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 11 comments »

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)

PeopleBrowse

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.

Risks
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.

Risks
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.