socs – Service Oriented Content Sourcing

Image by Getty Images via Daylife

I just spent six hours in a meeting with internal communication managers trying to find a define content for their internal media.

They switched from general rules to detailed content and back, reinvented everything, broke every agreement they achieved in the meeting and then agreed on it again – so it was quite an ordinary meeting.

But I had a few ideas on what are basic guidelines for content sourcing and defining contentguidelines, be it for print, online or audiovidual media.

Guideline #1: It does not really matter what you do. You will never come to an end if you try to define topics, typical stories, and content areas. It’s more a matter of how you do it: You can put everything in your media, as long as you do it in a way that attracts your audience and suits your company.

Guideline #2: It’s people who sell. You need faces, lives, quotes, emotions, personal experience, personal power. Build your content around people, use people as the main ingredient. Don’t say anything, let people say everything.

Guideline #3: Do tell stories. That corresponds directly to #2. Facts are ok, but only if they can be told, if the narrative dimension is ok too. And a narration is only worth reading,if it’s about people.

 

Guideline #4: Don’t worry too much about what you what to tell. Nobody cares about that. Do worry more about what your audience wants to read, and, foremost, why they should read your stuff at all. That depends on your audience and on the type of media.

 

Today’s discussion was about employee magazines. Employees expect benefit from their employers; they work for money, so they want get something out if they out something in. You can write about whatever you want; as long as people understand it as something they can do too, something they should not do, an offer or a rule, something that can push their career or facilitate their lives, they will read it.

It helps, if you think about content examples, but you will never have a complete listing, probably not even an inspiring one. Actually, the more precision you try to bring into these lists, the more boring they get.

If you focus on the kind of service you want to deliver, you can probably describe it in three lines. It will help you find new contents, it will help your audience understand your media, and it will create additional value that is obvious and understandable for everybody.

That’s why I call it SOCS – the Service Oriented Content Sourcing approach. No matter what you what to publish – focus on how you want to publish it, how you want to tell it and want service you want to deliver to your users.

That also reveals the sad side of it: You have to know your business. You can talk, negotiate, define for ages – if you don’t have the experience and the feeling for what makes a great story, then you need professional help.

You can learn to write, you can learn to take pictures and you can also learn how to find, invent, describe or tell great stories – but you need to be aware that this is a discipline on it’s own.

Every successfull media have their guidelines, sometimes they are explicitly written, sometimes they are part of general guidelines, sometimes they are just there.

Some samples for SOCS-Guidelines:

Every story in xxxxx Magazine is there to activate our employees. Its tells them what they can do and how they can start it.

We always present the full view. Our readers are able to participate in any discussion with colleagues or customers, and they will always be well informed, they will not be surprised by anything.

We don’t have managers talking. It’s always employees who tell the story.

And, as an example from a more general perpective:

We tell dramatic stories from all over the world – but we always look for a connection to our country.

Related articles by Zemanta

• Companies, Employees, and Social Media requires Trust
• How People React to Crazy Ideas
• Benefits From Blogging

ECM Summit Day 2: Communication Controlling and Knowledge Management

Today I could listen to another four presentations.

In the morning, the topic was communication controlling: How do you know that your communication activities really achieve their goals, that you reach your audience – and how can you transform that into ideas for and ROI argumentation?

First speaker was Mark-Steffen Buchel from aexea who introduced a case study from Vattenfall. They built a balanced scorecard-like kpi-measuring tool, that showed interdependencies between different criteria and their influence on some main criteria. Eg. download speed of the websites is split into real download time, error rates, download time perception (by users), explicit user satisfaction and some more criteria.

In order to keep the data current, Vattenfall does quarterly user surveys.

Quite a lot of work, but it seems to be promising – if you are asking the big questions, then you have to invest some work to get the answers.

Rolf Schulte Strathaus from eparo held the second presentation. He spoke about a portal relaunch project where they made heavy use of wireframes, wireframe clickdummies and wireframe mockups.

I did not quite get the point why this was supposed to cover communication controlling, but I’m a huge fan of wireframes anyway.

In the afternoon, I attended a panel on knowledge management. Erik Schulz from FH Berlin showed a casestudy from Berliner Gaswerke, where they focused on networks only – and not on technical topics. A lot of places where created where people can talk and interact (while having coffee or eating apples), a culture of sharing was set up in order to make people feel more comfortable, and some tools for storing knowledge where created.

I guess it works great as long as everybody is in the same building; might be difficult with bigger companies.

The second speech was held by Joachim Lindner from ABB. He introduced an international wiki in his company. Standard solution, but a cool approach: To get attention, he invited all 120.000 worldwide ABB-employees to a Web2.0-kick off-conference. 120 came and built the foundation for the first company wiki.

ABB invested three months of work in building the structure (sometimes for three and more levels of pages) and some initial content, another month in a wiki roadshow and now one day per week in monitoring and cleaning the wiki. It’s only a few months old, but it seems to start growing (also through the help of so called wiki-wichtel, who are reponsible persons in the business departments) and might be a very good example for real basic setup projects.

Multilingual Sites – the untranslatable

There are several reasons why some contents can not be translated:

• specific terms
• specific languages (english, russian, latin)
• multimedia – pictures, video, audio
• you would not understand it anyway: “is your birthday calendar really the high priority content for the intranet-homepage?”

Hierarchical terms that denominate positions that do not exist in other countries, popular terms that are hard to understand for non native speakers and even harder to translate – both are great in creating identity, they are entertaining and they are good means of communication.
But they are also tools to exclude others: That’s our thing, we say that, you don’t have to bother. You can no and should not get rid of this on a local level, but you can not use it if acting internationally; you have to neutralize yourself (one common way: just talk broken english – as I am doing it here – nothing will be perfect;; everybody will understand… )

Sometimes, it’s not the language, but the attitude that can’t be translated.
The further east I go the more I am impressed by how important birthdays and namedays are in many cee-cultures. – That must be highly fertile area for any social media services, but it’s very hard to integrate warmest wishes into business-style intranets as we know them. As prime content on the portal homepage, notabene.

A third quite special case are pictures, video- and audiofiles. Metadata can either be translated or use common language so that it’s easier to argue about, captions and other supporting texts are also easy to translate.
Pictures should be general, but actually they are not. Pictures tell a lot about tradition, power and personal views, and that is closely related to local views and traditions. A western CEO may want to visualize cooperation, openness and friendliness, an  eastern CEO may rather want to represent strength, wealth and power. Western users will understand the strength-image as something oldfashioned, maybe even threatening. Eastern users may interpret open friendliness as weakness.
A universal picture language will end up being just boring. So this has to be handled somewhere else, it’s a mainly cultural and political matter where official media can only support.

Videos strongly transport values and identity. Use them only, if your plan is really clear – or if your actors are great. Information-driven videos that contain a lot of explanations can synchronised; vox pops or interviews should never be completely synchronised. That will just destroy their actual value. 
To summarize: I feel more and more that multilingual sites are not a matter of translation, workflows, contentmanagement or menus, but they interfere a lot with cultural and political values in the enterprise, they have a high impact on information architecture – and they are one of the big cost drivers for portals.

Shaping a poor man’s portal

Developing internal media for the banking industry is no fun at the moment, not at all. Medium term investements, even if their benefits are obvious, are cancelled if there is no plainly positive business case for the first year.

That’s a common problem for now; so should we get used to it or should we try to wait for better times? One big problem, I guess, is that most of us did probably already wait for a few months or even a year: things have been slowing down before, thorough planning and 100% budget compliant planning were some of the biggest slowdown factors up to now.

So now I’m about to plan a redesign of a ten year old intranet that should not produce any costs, should not require too many emergency workarounds, should be manageable for average-skilled editors and should attempt to satisfy those need, that we identified as the drivers for a 1 Mio € project.

Sounded disgusting in the beginning. Now I think it sounds interesting. There is no other choice anyway.

How to evaluate content managementsystems for the intranet

What are the most important topics in an intranet architecture, what are the most important features for Content Managementsystems to be used in an Intranet?

I just sent out a Request for Proposal to a longlist of vendors and I am now about to prioritize all the defined requirements. What I came up with as a proposal for further discussion is

• basic technology first (if its supposed to be java it shouldnt be .net)
• compatibility, scalability, integration features (content, applications and users as well as import and export)
• support (slas, guarantees, personal skills and qualities, regional distance/availability)
• basic business requirements (multitenant, multilingual, if required)
• workflows, roles and permissions
• roadmap, strategy, partnering models with vendors
• licensing models, licensing costs
• other commercial issues
• additional business requirements

It may be a little strange that the commercial criteria are so low in the ranking. In my opinion, the licensing costs really hardly matter. Vendors will offer you discounts that they almost pay you for buying their system, they will always be cheaper than their competitor. Id they are not and there is really a difference – then you should be alarmed.
The real costs will come up with additional tools and integration efforts – thats why integration features are my number 2, and support is # 3. Support and the personal relationship determin, how fast your developers will work – this will depend on how good documentation and support are, but also on how much they like the system and its consultants.
Business requirements and workflows are # 4 and 5 because they are important, but you can still fix things that are not ok – as long as # 2 and 3 are granted.
The roadmap is nice to know – you should make sure that you and your partner are going in the same direction.
You will have to pay for it, yes. But once youve paid, its over. Thats whz licensing costs are only # 6. And if # 3, 4, 5 and 6 are ok, you will be happy to pay.

So dont worry too much about prices, dont look at the big players only, listen to your developers and do care about personal relationships on all levels. If you get along with developers, project managers and CEOs, the project will be smooth and great.