Substrate

Where Knowledge Grows

How to deploy SmartShare

Six thoughts on how you might get the most out of SmartShare in your organization, based on experience from a number of other cases of deploying new media to support collaboration. And, of course, based on the design intentions of SmartShare itself.

1. The vanilla scenario for deploying SmartShare is an organization where people mostly uses email, file servers and perhaps more formalized enterprise collaboration solutions as a way to support working together. Maybe there are smaller task forces creating things jointly, maybe there are needs to coordinate different task forces in the production of something larger.

Either way, people probably find that there are problems with different versions of files and that important coordination efforts sometimes get lost in email inboxes.

SmartShare was designed to be a lightweight, clinical tool for such situations.

2. Start small. The best way to get good collaboration practices going in SmartShare is to start with a group that has cohesion, a reason to work together, and where all members are committed to the group and the quality of its results. This could be a project team, for instance, or perhaps a management group.

What is important is to start with groups that are intrinsically motivated, rather than groups that only exist in the organizational charts but which do not function as groups in practice.

Why is this important? Because SmartShare is the kind of tool that can easily spread organically on the grassroots level in an organization. If there is an early adopter group using SmartShare in a productive way, it is likely that those best practices will be spread to other colleagues — simply because people in organizations these days typically belong to several groups and social structures.

SmartShare is a relatively open collaboration platform. It does not prescribe a workflow and there are some tools that groups of people will invent their own uses for (see below). In a committed group of early adopters, it is likely that clever practices will be developed, and those practices may be useful also to other groups within the organization.

3. Be practical about the bootstrap. Having SmartShare notify you via email is generally a good thing for people who use email as their main stream of work-related events, but it becomes a royal pain when the first large batches of material are shared.

A useful procedure for an early-adopter group might be to have all the users registered, then get together for a session where everybody logs in on their own computers, turns off email notification, share all the files they agree to use a common work objects, then finally turn email notification back on for subsequent distributed work.

This also gives the group members a reason to go through SmartShare together and negotiate what they see, what it means, and how it could be useful to them.

4. Evangelize at the right times. When someone sends you an email attachment, ask them kindly to share it on SmartShare if it is potentially meaningful to more people — which it sometimes is. Also, material in a shared repository has better chances of staying at-hand than material that is buried in mailboxes and local mail folders.

And then of course, there is the whole issue of version consistency which becomes important if the stuff that was sent to you in email was intended to be developed further, possibly by several people.

5. Tag, but in a socially-aware way. Remember that tagging is a collective construction. When you share a new object, start by looking for existing tags that might fit the new object. If you can find any useful tags, you will have connected the new object to the web of information already available in SmartShare — and it will immediately make sense to at least some of your colleagues.

If you can’t find any suitable tags, then by all means add new ones. But before you do, try to identify emerging conventions among existing tags and try to adhere to those conventions when you make up your new tags. This increases the chances that the new object will be meaningful to your colleagues.

For example, you might find that a number of existing objects are tagged with “customer” and “Company X”. The object you just shared pertains to Company Y, another one of your customers. Then it would probably be a good idea to tag the new object with “customer” as well as with “Company Y”.

Tagging is not limited to objects that you have shared, either. If you find an object in SmartShare that you think should have a specific tag in order to be more meaningful and easier to find, then seize that thought and add the tag. It takes you only a few seconds, but the potential value for your team and your colleagues could be significant.

6. Use claiming as a gentle hint. In SmartShare, you can claim an object which means that your picture is shown next to it. That is all it means. The object is not locked, any other user can remove the claim or claim it themselves. It is an open mechanism, waiting to be filled with the meaning that your team chooses to invest in it.

In some teams, the claim might be a way for people to tell their colleagues what they are currently focusing on — like a little status update. In other teams, the claim might mean that someone wishes the others to leave a certain object alone until the claim is removed. Another approach might be to use claims as a way to identify who is responsible for different subtasks. Or perhaps for the person responsible for a certain object to mark it as finished or approved.

The point is that claiming must be negotiated in the team and in the organization. One idea might be to talk about it at the bootstrap session and agree on a scheme for how claiming should be used. What is important then is to be sensitive to how it is in fact used in practice, and to modify the agreed-upon scheme accordingly. Another approach would be to leave it open and wait for a claiming practice to emerge (most likely when the lead users start setting examples for how to claim).

, , , ,


2 Responses for "How to deploy SmartShare"

  1. Richard T April 14th, 2011 at 12:34

    Overall very good points on best practices for any social enterprise collaboration tool and not just SmartShare!

    A few concerns though:

    The “claiming of objects” functionality seems likely to become a major confusion to the users. Intuitively, I would interpret “claim” as “request ownership of an object”, thus being the only user that can modify, share, delete or transfer ownership of that particular object. Will be interesting to see how it will be interpreted by real users though.

    Secondly, what about the need for a community manager, a person dedicated to “supervise” the usage of the actions taken on the platform. This would be a super-user that actually have time set aside for helping other users and being a human FAQ.

  2. Jonas Löwgren April 15th, 2011 at 07:28

    Richard, thanks. Good points.

    Concerning “claim”, I think the potential confusion you point to may be in the name of the function. The function itself is intentionally very open (which is what I find interesting about it). It is likely that the first impression of what claim means will be overcome as the function starts to be used in different ways. Could do with a better name, though, that reflects the open-endedness.

    Community managers are quite likely to emerge in use, but I would hesitate to dictate the need for such a role. Instead, I would envision scenarios like a project manager introducing SmartShare to the project team also doing community manager tasks initially (motivated by the benefit for the project of getting SmartShare into efficient use). If SmartShare then starts to spread into other corners of the organization, then the community manager responsibilities will most likely be an issue for the organization to reconcile with existing IT strategies and policies.


Leave a reply