- The No Goal Error. Not having a purpose or objective behind what you are doing. What will people be using this for? Does what you are asking them to do matter to them? (N.B. "collaboration" is not a goal in itself). Warning Sign: "We put in a x because we thought it would be, y'know cool". Nothing Wrong With: There is no upside to this one.
- The Magic Bullet Error. Thinking that one tool will do everything for you. There are a range of tools out there and no one application (or platform) does everything equally well. Warning Sign: "We plan to do everything in x, the sales guy/evangelist for x said it will do everything we need". Nothing Wrong With: If something works well in more than one situation then by all means use it.
- The New New Thing Error. Deciding to deploy something because it is new rather than based on its merits to meet your purpose (N.B. You do have a purpose don't you?) Warning Sign:"One of our directors read about x in an in-flight magazine, we have to implement x tomorrow". Nothing Wrong With: Experimenting with new tools (with all that the word "experimenting" implies).
- The If I Wear Brad Pitt's Suit, I'll Look As Hot As Brad Pitt Error. Just because another organisation gets good results with a certain tool and set up, it does not mean that you will also. My body is not the same shape as Brad Pitt's nor is my face as pleasantly arranged, hence his suit will probably not have the desired effect. Your organisation and your culture are not the same as somewhere else and context is important. Warning Sign: "Organisation Y (in the building next door but a completely different industry) just implemented x and it went great for them, why don't we do it?" Nothing Wrong With: Learning from the experiences of others and listening to intelligent case studies.
- The Titanic Error. It's not the parts of the iceberg that you can see that you should be worried about. Successful collaboration is about many intangible things (leadership, trust) and yet people focus on what they can see - i.e. the tool. Warning Sign: "I want an online community, show me how to customise the skin on Ning". Nothing Wrong With: Paying attention to design and usability and making it all look good.
Sunday, December 21, 2008
five common collaboration tool errors
I was presenting on collaboration tools last week and I was reflecting on five common mistakes made in the selection or implementation of these tools that I have seen (or even participated in at one time or another) before launching into descriptions of the tools themselves and some case studies. Here are the five members of the hall of shame:
Subscribe to:
Post Comments (Atom)
Posts
5 comments:
The 'No Goal Error' can be seen as a positive if you re-cast it culturally as meaning that the aim is to let users decide what the goal of the tool is, not the organisation!
Stuart - Thanks for commenting. In principle I agree with you - but what you are describing are the tool advocates/implementers working with users (or potential users) on what those goals might be - which is a little different to "no goals".
But that reminds me of another common error - the would-be implementers not talking to who may use the tool.
Good work Matt. I'm coming to Oz in March 2009 and am looking forward to catching up with you. In the meantime, yes, yes, yes.
Also included and an as-yet un-followed-up issue is 'language'. We're going to see a fair bit on this in 2009.
The language and processes we use to discuss, define and deliver 'tools' is highly problematic.
Clients don't know how to talk about what they want/need, aren't used to discussing it together with shared language and common mental models, and providers are gadget-delivery-focused for obvious reasons.
Thus the language used to get this done is tool based, which makes for a whopping barrier to getting any 'platform' done.
When did you last hear someone say 'shall we use a hammer or a screwdriver?' before discussing what it was they were building? (hint: almost every time you hear a web-platform-build conversation).
PURPOSE!
(a mantra that can see the consultant being shown the client's door, weirdly... perhaps it's too hard a question?)
Wayback when in the 70s, an architect called Christopher Alexander produced something called pattern languages. They helped architects and clients talk about stuff in a human way at the design layer.
There's lots of pattern talk around usability, and Clay Shirky has been banging on about them for some time now, but they are a wonderful strategic way to bridge the gaps that lead to some of these errors...
Here are some 'golden rules' (for building a multi-platform project) from a recent Bristol event:
http://tinyurl.com/5cd8l4
Great article. On Stuart's point, wouldn't letting the users decide would be a goal in itself?
Great post. I agree with this, but while reading, it occurred to me that these errors are common in the planning / deployment / use of non-collaboration tools, as well. Probably just about any technology-based tool. This deserves a fresh read before starting any sort of tech project.
Post a Comment