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