Of Monoliths and Minis (Part 4): Control ain’t all it’s cracked up to be

ARRRRRRRRRRGH! okay … got it out of my system … deep, healing breaths …

Here’s a conversation with someone about collaboration and the tools we love (or hate).  The issue at hand for me is that I now have several documents that need to be shared among a group.  It is very likely – nearly going to happen – that folks will want to/need to add, subtract and otherwise edit these documents.  Easy document collaboration – that’s my goal!.


Someone: You need to put those documents on the Sharepoint site.

(I’m clenching my teeth already!)

Me: Oh – I thought I’d just put this up on a wiki or use something like Google Docs or Coventi.

Someone: What are those?

(I took the opportunity to talk about each of these … and even launched a quick screen-sharing session where “Someone” could see it in action.)

Me: I’m leaning more toward a wiki, though, because it really doesn’t have to be in document format. It can just as easily be onscreen. The key is to have folks be able to edit and update quickly and easily.

Someone: That’s what the Sharepoint site is for.

Me: (trying to remain as calm as possible) … Sharepoint is not quick nor easy.


Okay … this doesn’t just have to be about Sharepoint. It can be about anything that is touted as a ‘collaboration platform’ or collaboration tool. 

(something I found: “New Rules” for Collaboration … that addresses a lot of the friction I’m feeling right now … a few points that resonate regarding my hate-affair with huge, mongo, ginormous, so-called collaboration tools:

Users aren’t going to check-in and check-out documents.  I’ve had a lot of discussions with enterprises about collaborative workspaces.  Often their trials or implementations fail because users simply won’t go through the trouble of saving a file, then going into the shared workspace and uploading the file.  Shared workspace vendors ought to provide the capability for end-users to open files directly into their office applications, then save revised copies directly back into the shared workspace without any need for manual check-in / check-out.

Have a mobility strategy.  For many individuals their blackberry is far more important to their productivity than they laptop of PC.  This trend will accelerate as smart-phones get smarter.  Collaboration and communications applications need to support mobile users rather than exclude them.

And I’ll add to this that users – particularly when we are all colleagues working together – should be able to quickly and eaily (there’s those two words again!) change the layout/format/presentation structure of the tool without having to jump through the hoops of finding out who has admin rights and then petitioning her/him to make the changes. 

What may have worked (in terms of presentation format and structure of the web interface) for one project or workgroup does not mean at all! that the same will work for another. 

Sure – use the previous set up as a starting point … a template, if you will.  Then just allow users to make the needed changes when they emerge. …

Who knows? What they come up with might even be good!


About Rory

I make my home in the central part of the Garden State along with my family. When I'm not working as an Instructional Designer (focusing mostly on Web-Based learning ... and other eLearning technologies) or researching something, I'm found at home playing computer or video games. Among other things, I volunteer as a choir member and catechist for 8th graders at my parish.
This entry was posted in collaboration, collaborative writing, project work. Bookmark the permalink.

2 Responses to Of Monoliths and Minis (Part 4): Control ain’t all it’s cracked up to be

  1. nkilkenny says:

    Amen Hallelluhjah! You need to have the ability to be flexible when using any documentation/storage or even living knowledge tool like a wiki. Your structure will change and evolve with your use and according to how your business. But here’s the key, the partners who use the wiki have to be flexible with the rules. Though the larger your collaborative group the less flexible the rules need to be. Too many players means too many variables for change. I once worked with a team of 20 + people who used a Sharepoint folder/server. The file structure was not set in the beginning and the Project Manager kept on changing where things were filed. You could just imagine the texting of expletives ($%@#!!!) Many people got so frustrated we resorted to just e-mailing things back and forth.

  2. Rory says:

    Hi nkilkenny … and thanks for the comment.
    Good point about the larger the group the less flexible the rules to be.

Comments are closed.