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

Something new…

I just wanted to write a post about the three hours it took me to teach a colleague how to publish videos on the intranet (and that only covers half of the work), and about that I’m looking forward to calculating a business case for the new solution we’ve been discussing for more then a year.

This morning, I got the amazing news: My project has been approved by the management board. We will build a new intranet. I started to work on the first proposals in November 2007  – so that were really really long discussions.

Now it’s signed; the main requirements we want to meet are:

• build a portal that’s accessible for everybody from every country we’re operating in
• introduce publication processes that talk with one voice to everybody (same content, same time, all audiences)
• introduce permission management and closed usergroups where necessary
• introduce group-personalisation to create different views on the content for different audiences
• enhance the corporate directory towards an enterprise network
• carefully introduce well planned blogs and microblogs with attractive authors
• provide wikis as collaboration-, documentation and knowledgemanagement tools (knowledgemanagement projects are running in parallel)
• use tags as additional navigation- and categorisation tools, introduce rss for easier and for flexible customization
• support and train employees especially with increasing their media literacy

Detailed planning will continue now, I will keep posting and I’m looking forward to comments and discussions.

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

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?