7 principles for decentralized publishing

During the first Globally Local open thread of a couple of weeks ago, Chamika asked:

“A topic I’ve been trying to research is how to set up workflow for intranet content using Sharepoint. There are several resources that explain the technical aspects of workflow set up, but rarely have I come across any articles about mapping out workflow from a centralized publishing model to a distributed publishing model. Another way it’s being perceived in my organization is the approvals process for intranet content. Any best practices and lessons learned would be great.”

I have identified (thanks to some challenging work with my clients!) 7 fundamental principles that I feel are very important and that each of my clients has implemented – their own way – in their organizations.

1. Define responsibility for content at the lowest level possible in the organization, but at a level of accountability.

Define the level according to the “natural business role”. Publishing on the intranet must be part of normal business procedures. Whoever is responsible for the accuracy of a specific content should also be responsible for that content on the intranet.

Keep this level as low as possible, but make sure it does not go lower than the business responsibility.

2. Do not mix “content owner” with “content publisher”.

The content publisher may be a person whose responsibility is to use the CMS or publishing tool and put the content online. This is not the same thing as being responsible for the accuracy and up-to-dateness of the content. This is a technical responsibility, which is very important, but different. It requires knowing how to use the publishing tool, and, depending on the sophistication of the tool, making the content easy to read online.

3. Make the name of the “content owner” visible on the content itself.

Ensure that the person with business responsibility for the content is visibly identified on the content itself. Visibility goes a long way towards making people aware of their responsibilities.

4. Have the business units and functions specify their own types of content and levels of approval.

If you are a large, global organization, you will have many different types of content with varying degrees of ownership depending on the source: business unit, country, function, etc. Ask the different business units and functions to define their own guidelines for what type of content require approval by what level or role.

Propose a content-approval grid with (1) the types of content with which you are familiar and (2) the potential levels of approval based on your organizational structure. Ask business and functional managers to indicate what level of approval is required. Push them a bit to ensure they are not placing the approval level too high.

Find examples outside of the intranet to help them analyze the true level of responsibility. For example, if certain people are allowed to communicate externally, they can certainly approve content for internal publication. If a level of management produces internal reports on a topic, they can certainly approve publication for this information on the intranet.

Avoid, as much as possible, elevating the approval level.

5. Avoid complex workflow. In fact, avoid CMS workflow completely!

With a few rare exceptions, assume the person publishing a piece of content is authorized to publish the content. Building workflow steps into a content management system simply adds to everyone’s email overload.

I have rarely seen cases where the actual approval process takes place in the CMS workflow. It always happens either before (preferably) or after the actual publication.

6. Do not let content owners alone decide what end-users should or should not see. Involve user rep’s!

Identify owners for user profiles (or “persona ambassadors”). Make sure that if you have defined profiles such as “marketing managers” or “employees based in France” or “customer service staff for product A” that you have also identified a person who is part of that profile and who can work with you to determine what members of that profile need to see and access to do their jobs. This person becomes the “user rep” for that profile. (“Rep” = representative)

One of the biggest pitfalls of customized intranets/portals is letting the content owners alone decide who should see what. They only have a partial view. The complementary view is from the users: “what do we need to see”, and only a member of that user segment can answer that question.

7. Make sure you have no “black holes”.

This is hard, but if you have top management support you can do it!

If you don’t, you probably can’t.

Require every part of your organization to have an intranet representative, a person who represents what the area publishes on the intranet and what the members of that area needs from the intranet.

If your top senior person makes this a requirement, you can be sure that users will be able to find what they need on the intranet. Otherwise, the intranet may be lop-sided (unbalanced) with some areas heavily present and others absent.