Avoiding The eRoom Debacle

Actually, this isn't fair to the eRoom product.  There's absolutely nothing wrong with the product. 

The same thing happens with Sharepoint, Notes, etc.

You put a tool in everyone's hands. 

And, because they're human, they end up using it very differently than you intended.

Sometimes this is good, sometimes not-so-good.

A Bit Of Background

When EMC acquired Documentum, we found that they had made an acquisition of their own -- eRoom -- which was a web-based collaboration product.

After Documentum acquired eRoom, they took in a direction of collaborating-around-content, which is inherently cool, at least to me.

When EMC acquired Documentum, all of the sudden it was very Politically Correct to be putting up eRooms everywhere.  If you had a team, or a project, or a function, you needed an eRoom.

Now, at other companies, this could be file shares, or Sharepoint, or Lotus, or whatever.

So, what do you think happened?

At first hundreds, then literally thousands of eRooms sprung up everywhere. 

Each with its own little puddle of content. 

Each with its own membership model -- no peeking in an eRoom where you weren't invited! 

And each configured to spam you ruthlessly every night with the latest Automated eRoom Report about each and every document that was added or modified, or ...

Worse yet, these were just repositories.  Think Web 1.0.  Very rarely, if ever, did a true community spring up.

The IT guys tell me that we now have something like 20TB of eRoom content of questionable value hanging around in our infrastructure.

Now, to make matters worse, I've seen some eRooms that have been built and used by our Documentum brethren.  Some of them are vibrant, participatory and interactive places in their own right.  A few are excellent examples of SM and community principles at work.

But that same tool, in the hands of the rest of EMC, turned into a document dumping ground.

And there's a lesson here to be learned.

So, Here's What We've Learned .. And Are Going To Try And Put Into Practice

1. Users of a tool have to be helped to learn to use the tool in the intended manner. 
    
   Unless we closely work with the first few community builders (and participants) on how to build, use, grow and manage a vibrant community, there's a significant chance that it will all turn to grey goo by itself.
   
   Now, I am optimistic that once we get to a critical mass of proficient community developers, managers and participants, they in turn will provide community support to the new folks.  So we probably will have to do less policing -- er, consulting -- over time.
   
   But we'll still need to keep a vigilant eye on untoward behavior.  In particular, we don't want this to turn into another place to post content at EMC, unless there's a community working with the content and collaborating to make it better.
    
   I don't want another content dumping ground.  We have plenty of those already, thanks.
    
2. No private spaces.
   
   The value of a community is in its openness.  Anyone can look around, join in, participate, etc.
    
   When we did eRoom, we did just the opposite.  We assumed that, even if you were an EMC employee, you had no right whatsoever to know what other people were doing, let along contribute a bit if you felt so.
    
   How counterproductive.
    
   On a similar note, EMC has a fundamental issue with openness, trust and cross-functional collaboration.  We're going to make sure that the community norms foster the behavior we'd like to have, rather than the behavior we used to have.
    
   By extensions, small work-groups of people in the same org don't get semi-private spaces, either.  You're either a community (crossing multiple boundaries) or you're not.
    
3. No avatars or pseudonyms.
    
   Part of openness, trust, transparency, etc. is knowing who you're talking to.  As in using your real name, complete with badge number, email, etc.
    
   I can see all sorts of untoward behavior arising from a decision that it's OK to be anonymous on a corporate platform.  However, if you'd like something cool for your picture, that's OK with me (so far).
    
4. No explicit guidelines regarding conduct.
    
   Lots of concerns about vulgarity, inappropriate conduct, etc. on this platform we're putting up behind the firewall. 
    
   I think we need to trust people to behave as they would in a business setting.  We've figured that out (mostly) for internal business meetings, email, concalls, etc. -- this should not be any different.
   
   Inappropriate behavior is inappropriate behavior, regardless of the medium you are conducting yourself in.  Enough said.
    
5. Some communities are inherently temporary in nature.
   
   One of the problems with eRooms is that they came into being very easily, but never ever went away.  And they'd keep spamming, and spamming, and ...
   
   I think we need to recognize that many communities will be temporal in nature, e.g. here's a big project we're working on, and now it's done and ready for archives.  Or we tried to start a community, and it never got off the ground.
    
   Still part of the community platform space, but clearly marked as "archived" rather than active.
    
6. Not everyone will get to build a community just because they asked to.
   
   We're going to create some guidelines, a lightweight review process, complete with hands-on help as people approach this.
   
   Just saying "my boss said I could do this" won't cut it with me.  I pull enough rank around here to make it stick as well -- at least, most of the time.
    
7. Lurking is free.
   
   We are mindful that the way that people evaluate as to whether they want to join a community is that they lurk (quietly nose around without identifying themselves) first.
    
   We want to acknowledge that.
    
   No need to register if you just want to nose around (albeit you're behind the firewall, and we know who you are).
    
   Of course, if you want to post, contribute, you'll have to tell us a bit about you, but that's a fair trade, isn't it?
    
8. Don't get heavy-handed on taxonomy and classification.
    
   The Clearspace folks are pretty vocal on this, and I'm seeing their point. 
    
   Much effort and anxiety gets put into creating a heirarchical taxonomy up front, e.g. Marketing, HR, etc. that usually reflects the org chart.
    
   We're not going to do that, for several reasons.
    
   First, we think alternate navigation tools (e.g. taxonomy, search) will be better than strict heirarchy.
    
   Second, we're hopeful that there will be a self-emergent structure that we can react to and shape, rather than try to define a-priori.
    
   Third, we're trying to get people to cross functional boundaries.  Setting up an org-chart-style taxomony defeats this purpose.
    
   I am arguing for a VERY lightweight top-level taxonomy as follows:
   
   -- Getting Started
   -- Active Communities
   -- New Communities
   -- Archived Communities
   
   .. and then, beneath that, maybe one more level of taxomony, but that's it!
   
   On a tangential note, I think there might be a need for power users (such as myself) to have a personal space (beyond just a blog) but that's something we can come back to later, can't we?

So, there's probably a few more guiding principles we'll get to. 

But that's enough to chew on for now.

Comments

[Xavier]

Sorry to unearth this post, but I'm thniking about embarking on the same journey as you, and I'm reading the whole stuff, starting at the begining.

I have a question regarding your point on 'no private space'

Do you still think that some 'private spaces' are needed?

Doesn't the C-suite need some place where they can discuss some confidential aspects of the business?

Or would you want to have a private space to discuss some project that would only pollute everybody's dashboard with topics that might not be of interest to them?

...

[Chuck Hollis]

Hi Xavier

We made our decision based on specific context. We already had lots of places at EMC where people could share information privately (e.g. concalls, email, file shares, eRoom, etc.) and we had driven that model about as far as it was going to go.

Our thinking was (1) why attack a problem that we already had solutions for, (2) how do we foster broader collaboration and engagement, rather than make small teams productive, and (3) how do we get our employees "speaking in public" on social media platforms?

For us, it was one of the best decisions we made along the way. Your mileage may vary!

[Xavier]

I see!

Thanks!

[kevin shea]

Chuck

I’ve been involved in the introduction of eRoom in a really big automobile company. The specific area that I was involved with didn’t have the issues that you describe here. However, although the general growth of eRoom in this company advanced pretty virally, much of it ended up with the same issues as you have described.

The reason for the difference was that we introduced eRoom using a “controlled emergence model”, rather than an open emergence model. It went like this.

a. The goal was to improve the work practices of an engineering department and to introduce change and improve processes by introducing collaboration.
b. The idea was to introduce this easy-to-use tool, provide some guidance, make collaboration interesting, and then stand back and help direct.
c. The first step was to work with a small group of end users to define a work space that “mostly” mimicked the process.
i. We modified some areas that we wanted to change and placed some barriers in the way in areas that we wanted to test.
d. Prior to opening to members, we created a framework and structure that provided an environment within which work could be conducted
e. We promoted the idea that by imposing structure, people would be able to innovate.
f. Right from the start, we had a vision of what we wanted to end up with, but we limited eRoom creation in order to control rampant growth.
g. We made it a privilege to be part of the new effort. Engineers sold the benefits to other engineers
h. Throughout it all, we didn’t try to manage the technology, we mostly tried to influence behavior.
i. In the end, eRoom deployment in this department did go viral and met the goals; 250 eRooms, 2500 members, integrated suppliers, integrated project management. They currently “run their business” in eRoom.
j. We did have to make small corrections along the way after we learned from the users how they wanted this thing to work.
k. The other departments are getting better, but still have many of the issues that you note.

What we were really focused on was changing behavior. It was pretty apparent to us that if we went in and let people create eRooms, what would result is a very good picture of how the company really looked at that time… pretty ugly. What we ended up with was a generally consensus of “why don’t we just do that in eRoom?”

In my opinion, there are downsides to an open emergence model within businesses. I believe that social networks within businesses are more constrained by the influence of profit, regulation, quality and other attributes. It is these attributes that must be taken into consideration to define the type of emergence that best serves the people and the business.

From my experience controlled emergence can be an effective way of introducing social applications that can work to support business needs.

[Chuck Hollis]

This is a wonderful chunk of practical knowledge here, Kevin, so thank you very much for sharing.

And eRoom sounds like it's delivering all the benefits you had hoped, which (as an EMC guy) makes me smile a bit ...

Quick question -- would you describe your style of collaboration as "document oriented" or "conversation oriented".

We have both here at EMC. And maybe we should have followed your advice when we rolled out eRoom internally.

Thanks again for sharing!

[kevin shea]

Chuck

I guess it was more a hybrid, following the design philosophy of maximizing integration and the idea of creating a “complete story”

That said, I think the issue is content (document side) and context (possibly your conversational side). eRoom is being used to capture both. All the pertinent discussions, debates, relevant emails, etc are associated with a document, a list, or an image, etc.. Maybe it is better to call these business discussions.

Of course there are other conversations being conducted outside of eRoom in email, person to person, at meetings, or in IM. There is not yet any blogging being done, nor are there separate forums. However, the important elements of these conversations are distilled and then added to the eRoom.

The architectural intent of the design was to keep all related discussion associated with the content. The model was the court room, in which, the evidence is the content (documents) and the conversation is the exchange between the lawyers and witnesses (context). Together they make up the complete story. The idea is not to have the users think of content over there, and context over here.

How it is stored, and making sure that the storage method doesn’t disrupt the story, is a different issue.

Keep at it, eRoom roll-outs can be corrected.

Kevin

[robert]

Just starting to think about using eRoom for a colloboration tool between company engineers and customer engineers - for use during rollout of new products that undergo interop testing. We will need to provide access to various artifacts of the testing effort, as well as opportunities for engineering discussions about issues and resolutions. We are currently utilizing the documentum product in house, so eRoom might make sense for us to implemenmt as a web based collaboration tool. Any advice on where to start is appreciated, These erooms will intiially be temporary in nature - allowing a team of a dozen people to focus on the testing effort for a number of weeks/months, but they could develop into web portals dedicated to specific customers.

Just how difficult is it to implement eRoom - for this type of specific colloboration. Not trying to change the internal company colloboration norms, just want to facilitate a specific set of content, and discussion in a certain area with access by multiple parties.

thx - robert

[Chuck Hollis]

Hi Robert

My impression is that eRoom can pretty much do what you want, and without too much fuss.

Your use case strikes me as something that's primarily document-centric: people looking at documents, and discussing what's in them.

eRoom is good at that.

Deployment models vary, but I frequently see a "self service" approach where someone can request one, and they're off to the races. Of course, you'll have to clean up the aftermath, since no one likes to tidy up after the project is done.

You didn't mention whether you're a Documentum user -- if you are, there's the added benefit that the documents can be managed by Documentum processes and workflows, which is frequently useful.

Let me know if I can do something else to help!

[Rich]

I'd agree and disagree here. I've seen some great uses of eRoom and in other cases, it was just a place to dump files.

eRoom is a business tool like anything else. If you don't use the tool the right way, or educate users on how to use the tool the right way...then you just might make a mess....which sounds like what you did at EMC. Funny how an information management company creates a mess -- like a plumber with leaky pikes at home.

I'd argue the problem was in the way you deployed and managed eRoom. Your IT was not close enough to the business to understand exactly how people were using the tool and educating them on how they should be using the tool.

Migrate to sharepoint or Jive or another tool ...you'll probably get the same result -- I've seen it.

Now I'm not opposed to openness and community. You need that to connect people and share knowledge. However, you also need secure collaboration for projects, client work, product development, mergers & acquistions, etc....

And that's what eRoom is best at -- both inside a company and outside.