Search this blog

januari 29, 2014

Super collaboration, super value!

With the current available tools in IBM Connections and some add-ons like Connections Content Manager (CCM) and IBM Docs, collaboration can really take a productivity flight!

Often clients wonder what tools they should be getting. When do we use Files, or should we use the CCM Libraries? What can we do with a Wiki? When is IBM Docs interesting? I tell them, it all depends on the business goals the organization has, or what collaboration needs their employees have to get their work done faster, more efficient and more efficient.

Talking about productivity… what are the productivity gains of new ways of collaborating with IBM Connections Files, Wikis, or IBM Docs versus old ways (file hares and email attachments)?

Comparing collaboration methods efficiency

Imagine you are collaborating on a piece of information with 3 others and you need to review each other’s work before you can finalize it.
What are the differences in using the different tools from a productivity perspective?

Collaborating on a file sent as email attachment

Let’s do a quick test:
How many files (copies) will you get when collaborating through e-mail with 3 others and 2 revision rounds?
a. 4
b. 10
c. 12
d. 52 
Tip: remember you need to save, send and receive copies every time a review is done.

Before you take a peek at the correct answer below, let me elaborate:
Collaborating on a file requires creating it, saving it to a folder, and sending it as an attachment in an email. Then the receivers get an email with the attachment, which they save in a folder, then start editing the file, and save it again (either as a new version copy, or overwrite the old one), then send it back through their email. The original creator gets 3 emails with attachments, and saves these to a folder, then needs to merge them into one new copy manually skipping through the contents. And for the second review round we repeat the whole process again!

Now for the answer: it’s 52 !
And this is why:

I could also work it out like this, try it for yourself by writing down each and every step. Count all the copies for all the steps in the process of working on a file and sending it through email: remember there is a file saved in a folder, a file send in an email, a file received in an email in every step by every person!

It becomes apparent that collaborating together on information through email attachments is not very efficient. In fact you could say the tipping point for effective email collaboration is with 2 people and only one revision round:

How can collaboration using Files, Wikis or IBM Docs improve efficiency so that employees can be more productive?

You could look at efficiency in the collaboration process: the total time spent: how much effort and time does it take to work together, and what is the turnaround (the time spent for a whole process of collaboration).

Collaborating using IBM Connections Files

With Files there are the following productivity gains:
  • Collaborating in one central place, with only one version and everyone can work with the latest version.
  • To prevent making changes at the same time people can lock the file before they edit it, and then unlock it for the next person to start their editing.
  • Every reviewer can see the work done by the previous one, so there are no duplicate efforts, and no merging is necessary
  • Apart from collaboration in the file (edit it), people can also use comments. Comments can be questions, tips or remarks about the content, instead of changing the content. Sometimes you want to give advice but not change the file itself.
  • Every reviewer can see the comments made by others so there are no duplicate efforts.
  • The owner of the file can easily take the comments and make changes to the file accordingly, without having to undo changes in the file, or remove the MS Word style comments.
  • Comments in Files remain, unlike comments in a Word file, after the file is finalized.
  • It’s easy to see all the different versions, and the owner can revert to an older version or even restore it.
All this together makes the total time spent on the file by the 4 people a lot less, and because there is no need to await emails with the changes the turnover is also much less.

Collaborating using an IBM Connections Wiki

If we would use a Wiki to do the same collaboration, there would even be more productivity gain, especially in turnover time.
Next to the automatic versioning, and comments Wikis allow people to work on their own peace of the puzzle, simultaneously, because each can work on their own pages, and afterwards a structure for the whole can be formed through wiki links and peer and child pages movement.
Another great thing about using a Wiki for documentation that is continuously updated, is that in order to change parts of the information only that particular page needs to be updates, and not the whole document as with a file). And it is immediately clear to readers which page was updated.

Collaborating using IBM Docs

Using IBM Docs for true co-creation of a file will result in the following productivity gains, on top of those with using IBM Connections Files: almost no turnover time.
True co-creation can occur, because all reviewers can work in the same file at the same time, resulting in almost no turnover time. It’s like sitting in the same room all writing on the whiteboard at the same time. There is no waiting on each other’s work, and on top of that the reviewers can communicate about their work using chat.

Fantastic collaboration analogy
Compare collaborating on a file in a sequential way - as with Email attachments – with collaborating on a file simultaneously – as with IBM Docs - with this analogy.

Musicians that each play an instrument in a song each record their part separately and sequential in a studio and finally it is all merged into a song. But suppose they would all play their instrument together. I mean, not as a band live show, but REALLY together:

Watch this: Walk of the Earth playing Gotye ‘s Somebody that I used to know.