We moved

We moved this blog to

http://www.themashazine.com/blog

The new feed will come from:

http://www.themashazine.com/blog/1/feed

Applied collaboration – dont always blame me

Image by Pirkka2 via Flickr

I just came back from vacation and there are not so many but still far too many emails asking for things that should not have waited for me. “Could you fix this, do you know how to do that, what’s the name of the guy who works with…” – I’m not the only person around who knows this, but I’m probably the one whom others suppose to know this. There are a lot of colleagues whom you could ask, and I bet you can find a lot of the requested information in the blogs, wikis and other information sharing services I’m running.
I like the idea of collaborating not only in dedicated collaboration environments, but also – or rather way more – in environments that strongly support networking. Yes, information should be tailored to a certain audience – but everybody should have the possibility to be part of that audience.
Public information provides better accessibility, not only of the information itself, but also of the possibilities and responsibilities: Who did what? Who can fix what? Who knows what? I don’t want to skip hierarchies or substitute managers, I’m mainly thinking about intra-team collaboration: Some colleagues have a sense for what’s going on, others simply don’t. They always need help and guidance, especially if they are supposed to get in touch with people they don’t have to deal with every day.
And that quickly leads to fear, prejudice, stubbornness – which again reduces the quality of information. Actually it even reduces the readiness to look for any information at all.

We know the consequences: Colleagues start to blame each other, questions are understood to be suspicions and wrong information becomes harder and harder to fix – you start to believe in things you know just because you know them, and because it seems to be more comfortable than questioning them.

And maybe the colleagues who asked so many questions during my vacation did not want to blame me… , but they really just needed to know something.

What’s the end of it: Collaboration does also stand for networking and documentation; collaboration tools should also provide information on who did what. Or the other way round: every tool that is of value for the community or is used by a community should provide collaborative features that

• provide public information
• show who did what and who can be addressed for what
• are easily accessible and not just an administrator’s secret.

Then we can clearly say that collaboration adds tremendous value to media.

Related articles by Zemanta

• Twitter Handbook on Education
• What’s driving collaboration?
• Swirrl.com – Online Data Collaboration Made Simple

ROI Dashboard – User Experience Indicator 2

Image by Getty Images via Daylife

We need to measure what we do – that’s what we agreed on in part 1. What do we need to measure? Let’s assume we’re introducing a small state of the art 2.zeroey employee-portal in a not not small company.

The company does already run an intranet, it’s almost ten years old. People are used to it, they always complain but there’s nothing special about it.

What can be improved?

• With the new solution, it’s easier to create content, so editors can work faster.
• They have a better flow in their work, so they make less mistakes.
• The new portal offers a better navigation, so people should find content easier.
• Tags are introduced, so that should also increase findability.
• Search is improved.
• Some basic content features have been introduced, so now it is possible to create slideshows, embed videos, audios and other media – that improves the user experience and saves the editors worktime.
• Basic statistics are part of the tool (tracking the backend and the frontend).
• Wiki functionalities allow fast editing for a bigger and not so skilled audience – that saves training, editor time and user time and reduces errors.
• Blog functionalities introduce new possibilities and enhance communication.
• RSS is used for feeds – in the portal, in blogs, wikis, the other way round; they optimize the use and reuse of content.
• Comments are introduced and are a simple feedback tool for users.
• Tags, clouds, categories in the fronted are just some next generation tools in the frontend, they enhance and train the employee’s media literacy.

These are just words… They have to be transformed into measurable numbers, the numbers have to be interpretable so that they relate to values, and finally the complete package has to be transformed somewhere into money.

The desired improvements have to be transformed into trackable metrics: What are the indicators, can they be found in the cms/portal?

The metrics need to be clustered into rememorable topics, and they need a visualisation: create charts, get sample data, build words and their stories.

Finally, an obvious connection between the indicators, their behaviour and the financial development of the project has to be made visible.

Visualization: Key Values based on easily trackable indicators.

But step by step.

• In the current project, four main values could be identified: Effiency, Satisfaction, Quality, Impact. Each of these values is based on several metrics, these metrics can be combined to several graphs that indicate trends and development.
• This leads to a balanced-scorecard-like environment, where small changes on a basic level are aggregated to effects on a visible level, on a level that can be communicated on a senior management level: You don’t have to say “We are having less usercomments than last month”, but you can say “Our portal is loosing on impact”; you don’t have to talk about painful cms editor-tools, but you can talk about efficience in the work of editors or about increasing or decreasing cost per content or cost per user.
• Changes on the value level finally have to be translated into financial dynamics: where do changes in the techy metrics in the underground make you loose money, where do they make you win some?

Relations and data are quite complex by now, but it is really important to keep the dynamic parts really simple and related to as little data sources as possible – preferrably only one: Everything that comes out of the portal can be measured in the portal; everything else should have to be defined only once.

This is what we will cover in the next part.

Part 1: ROI – social media metrics based on investments in the future

Related articles by Zemanta

• Social Media Basic Literacy Skills In the Nonprofit Workplace
• Wikis Still Slow to Catch on Internally, Externally
• New Project to Help Explain Social Media
• ROI Smoke and Mirrors – social media metrics based on investments in the future
• Exchange4Media and Blogworks.in present “India Social Media Survey, Brands and Corporates” Edition 1, December 2008

Take this sheet of paper away or I’ll quit

This guy is called Wiki Image by Getty Images via Daylife

My boss asked me yesterday to print something I was working on and file it as a hardcopy. “So that we have it for sure.” If she does that ever again, I will have to quit.

The problem was even bigger: She was concerned about archiving, security and revision history of contents on the intranet. “How can we make sure, that we have all changes documented, that we can also add notes on why which changes were made and with whom they were agreed.”

She suggested to print every document that is to be published on the intranet, put handwritten notes on it and file it. There are about 1000 new documents per year and another 1000 updates. That easily adds up to 12000 to 15000 pages per year that would have to be printed, commented and filed. And we are not even talking about retrieving something in there…

I was horrified.

I just managed to remove every piece of paper from my desk (except some post its, but I hardly used them since I use deadlineapp, netvibes or iGoogle).

I had planned to handle all workflow, versioning and archiving issues in a new cms-workflow that was supposed to come along with a generally remodeled intranet. This project was cancelled because of budget reasons.

In my horror, I now suggested to use a wiki instead.

I’m curious how far I can take that. There will be discussions with authors, editors, internal audit, IT security and of course users. There will be heavy rights management work, intense process and permission design and lots of documentation work for users.

But the most important issue to me: what can I do to build trust?

Many users think of Wikis as anything goes, laissez faire, informal stuff that is not suited for real business use.

What can you tell an internal audit colleague questioning you about how reliable the built-in usermanagement really is, and how you can prove, that the permission setting really work?

And how should you behave in a discussion with people telling you that they don’t want to store business critical information in open source software?

However, I started prototyping last night. And I’m more willing to go through these discussion marathons then to play with paper. If this does not work out, I will have to intensely reorganize something. In which direction whatsoever.

Related articles by Zemanta

• AMIA report on Open Source Implementations of Healthcare Software
• Kaizen for Developers: Visualization
• Need Help Marketing Open Source?