Are you currently using collaborative software, or are you planning to acquire it? Would you like to benchmark your experience against that of others? Are you based in Australia?
We are researching the use of collaboration tools in Australia. “Collaboration” is a buzz term at the moment, and we want to get behind the hype to discover how organisations are selecting and implementing tools and whether they are benefiting from them. If you have experience with selecting, implementing or maintaining a collaboration tool within the last 12 months then we would like you to take part inthis survey. The survey is open from Monday 22 June 2009.
What’s in it for me?
You will receive a free summary overview of the survey results from all participants. You can compare your situation with others and learn from their experiences in:
Identifying the range of tools;
Selecting and implementing them;
Realising benefits;
Using consultants and other service providers.
We will combine these survey results with key vendor interviews, case studies and further research to provide the first authoritative overview report of the Australian Collaboration Technology Landscape. As a participant in the survey, you will be eligible for a copy of this report at a discount.
About the survey
This survey is being conducted by Matthew Moore, Director, Innotecture and Keith De La Rue, Principal Consultant, AcKnowledge Consulting.
All survey data collected will be anonymised before the publication of any reports.
We’re at an interesting stage in our open research project on how expertise is valued and leveraged in organisations. We’ve collected something close to 200 stories (which are still feeding into the project blog) and we’ve conducted four sensemaking workshops so far, three in Australia (thanks to Michelle / KMRt , Anecdote / actKM & Kim / UTS) and one just completed yesterday in Dubai (thanks to Luke Naismith and the Knowledge and Human Development Authority), with more planned for Singapore, USA and maybe Hong Kong.
The workshop outputs are being posted into the project wiki. (If you are interested in hosting a workshop somewhere, let us know… we don’t charge as it’s a community research project, we just need to figure out travel and expenses).
We’ve now got to the point where we’re starting to get some insights that we’d like to check out on a larger scale through a survey. It’s short and snappy, and you’ll get to see the responses so far once you’ve completed (or go back and visit as the survey unfolds). Please do visit and take the survey and pass it on to anyone else you think might be interested.
The Australian Financial Review published an article last month about the negative implications of lay-offs* in which I was quoted. It mentions theUsing Expertise project that Patrick Lambe & I have been working on.
ABC Radio National’s Future Tense programme recently invited Katie Chatfield, Beth Etling & myself as a panel for a show on the Future of Conferences. You can download the mp3 or listen online via the ABC site. Many thanks to Anthony Funnell and Andrew Davies from the ABC for their fine interviewing & editing skills.
Fast Break was at Vibewire and featured 5 of us talking about Creativity, Connection, Collaboration, Commercialisation & (drum roll please) Conversation.
Here are the notes to support the slides (which I didn’t really use):
A key challenge to innovation is noticing. Or the willingness to be surprised.
Conversation plays a key role here – in conversation we can allow ourselves to be surprised.
Lovely quote from Theodore Zeldin’s book Conversation: The kind of conversation I like is one in which you are prepared to emerge a slightly different person.
Finally, 3 suggestions to improve the process:
Find people who are not like you to converse with. The more alien, the better.
This was a presentation that I gave at Wiki Wednesday on 6 May 2009. Here are some notes:
The style of these slides is a blatant steal from Jye Smith’s current presenting style. Jye – sue me.
Slide 2 is a drawing that appeared in an edition of 70s punk fanzine Sniffin’ Glue. The metaphor here is that social software is basically punk rock and that punk emerged in opposition to the world of prog rock. Many Flash-based web sites feel like 10 minute guitar solos – i.e. technical masturbation.
You don’t need to be able to code to create a web site with a wiki. You can just do it.
Slide 4 is a picture of Indian tea cups. Some are made of clay. You drink them and then throw them away. They are designed to be disposable. They have a built-in obsolescence. On the other hand, plastic cups persist in our environment. Many corporate information environments seem to be full of trash that won’t go away.
We need to design our environments with this obsolescence in mind.
Example 1 – built very quickly, iteratively and now no longer used.
Example 2 – built very quickly to prototype an idea.
Example 3 – built very quickly, adapted and still in use.
5 simple conclusions. The last point seemed to excite most interest so the discussion focused on information lifecycle issues rather than the rapid prototyping thing.
This was a short presentation that I gave as part of the NSW KM Forum Future of Conferences event (background & presentations). I was talking about feedback.
The 3 questions that I asked everyone at the start were:
Who here likes getting positive feedback?
Who here likes getting negative feedback?
Who here thinks that feedback is important?
Then I talked a little about the rationale behind the Rate My Speaker experiment. And then I talked a little bit about Twitter, with specific reference to this experiment by Andrew McAfee.
My final three suggestions were:
We have to get better at giving feedback.
We have to get better at receiving it.
Feedback is not an end in itself but a platform for co-creation.
UPDATE: The video is now available courtesy of Oscar Nicholson.
The core of the talk was simple: social software is not complicated technology (although it may be complex), you just have to work out what you’re using it for. As it’s social software, that thinking has to involve a who and a why. You need not be limited by that first thought but you need a somewhere to start. In working out your starting position, it’s also important to think about the whether you’re just broadcasting or whether you’re after a conversation – as Denis B Hancock’s 2×2 sketches out very elegantly* (he’s talking about Twitter but he could be referring to any form of social software).
*Presenting to management consultants, I was contractually obliged to use at least one 2×2.
It deliberately downplays the philosophical for the practical but let me stress that was a tactical decision for the article – I am interested in many facets of this topic. I would like to thank Cory Banks, Alison Bickford, Barbara Clay, Miguel Cornejo Castro, Mark Gould, Patrick Lambe, Neil Lynch, Kate Pugh, Liz Reuben, Greg Timbrell and Peter West for their input (if I’ve forgotten anyone then please let me know).
I’d also like to get your comments – see that comments box just below this post? Go on, I’d love to hear what you think.
As promised, here is the post that support the workshops that I ran today at the E2EF event. Many thanks to Ross Dawson for inviting me and everyone who participated. The topic was policies and guidelines. There are four questions that need to asked here:
Why do we need social software policies in the first place?
How should we develop those policies?
What should be in them?
What next? This question deals with deployment and monitoring.
Why do we need policies?
Things go wrong and people do things they regret. Public mistakes with social software tend to be splashed across the newspapers. Mistakes inside organisations are more easily covered up but they can still result in lasting damage. Things that can go wrong include:
Individuals fighting destructively in public. There should be nothing wrong with constructive debate but arguments and abuse can alienate people and ruin relationships.
Incorrect information being shared and acted upon.
Rarely are these acts carried out maliciously. Mostly it’s due ignorance and thoughtlessness. Policies should remind staff of the behaviour that you expect of them.
Policies also play another role – which is placating managers worried about social software deployments. The things that can go wrong listed above are often voiced as common fears by managers. Enterprise 2.0 is all about changing the balance of control and initiative in an organisation and this can scare people. Good policies reduce that anxiety.
How do we develop these policies?
How you develop your policies is as important as the policies themselves:
Many hands make light work. You have hired smart employees. Enterprise 2.0 is all about collaboration. So why don’t you get your employees to help draft what these policies should be. IBM used a wiki to allow its bloggers to draft their own guidelines (which you can view here). Senior management can reserve the right to make changes of their own – either while everyone else is drafting or at the end. Of course this means that if you’ve involved people up front, you should think twice about throwing out everything they’ve done.
Use what you already have. You should already have policies around internal comms, privacy & confidentiality, IP usage, etc. So use ‘em as the foundation for your social software policies. There should be no inconsistencies between these – otherwise people could get into trouble while trying to do the right thing.
Use the tools. Wikis are very good tools for collaborative policy drafting.
What should be in them?
This may be the easiest bit. There are three areas that you will probably cover:
Be sensible. If the wiki says “work in progress” do not assume that the information in there has been vetted. Use your judgement in what to post about.
Be nice. Don’t abuse people. Use your own identity. Be constructive.
Be legal. Don’t breach copyright. Don’t break confidentiality.
Have a look above at the IBM example or the ones for Intel & Powerhouse Museum. Most examples are about public use of social software but theycan be applied to internal situations. Beth Kanter has some sensible comments as does Joitske.
What next?
You now have your policy. If you have involved your staff earlier then this will make deployment much easier – because they will already be engaged. There are other things you may consider doing:
Use specific examples in explaining the policy to people.We like the concrete above the abstract. “Andy posted dirty jokes in the comments field of Stacy’s blog. They are good friends so Stacy didn’t mind. So why might this have been a bad idea?”
Focus on discussing borderline cases. Employees will generally know that selling confidential information to a competitor is bad but may need some help establishing where the boundaries are.
Include a section on appropriate behaviours as part of any technology roll-out. If there is no formal training to be provided then at least flag the policy when staff first access the tool.
Incorporating a session on the policy in training for new hires.
You’ll need to review your policies over time so build in timeframes for doing this (e.g. after a month, after 3 months, then every year). We give software releases numbers so why not policies?
An important idea that emerged out of today’s discussions was the importance of giving positive examples (& role models) not just negative ones. You don’t want to snuff out the inspiration.
