Is distributed content management working for you?
This is the fourth installment of a series of articles on content management assessment. The most recent article ("Is your workflow working for you?") showed how to assess the effectiveness of the workflow that you configured in your CMS. In this installment, we will discuss how realistic your expectations for distributed content contribution are.
A common justification for a new CMS is to "remove the webmaster bottleneck" by enabling content contribution from across the organization. Baked into this reasoning is the assumption is that the organization is filled with stifled contributors who are banging on the door with content to publish. But that isn't always the case; in fact, it often isn't. More common is a situation where the webmaster needs to drag content out of departments who are prioritizing other work higher than contributing to the website. It is only after the CMS is deployed that the organization realizes that the webmaster's key value wasn't just coding HTML but was writing content based on whatever raw information he was able to drag out of the business units. I have written about this phenomenon a few times before in "The Myth of the Occasional User" and "Ways to Fail."
If you are still building your business case around the "webmaster bottleneck" issue, be sure that you have not confused a bottleneck with an empty bottle.
-
Talk to your webmaster (or web coordinator) to understand how he spends his time. Is it requesting content or is he working down a queue of content requests.
-
See if there is a backlog of finished content that is waiting for publication.
-
Look at the quality of content submitted for publication. Is it just very rough snippets of text or is it nearly identical to the final published content?
-
Determine whether the content contributors have the skills and tools necessary to produce the content. Can they create the images and multimedia that appear on the website themselves? Or is that work done by the webmaster?
-
Ask how involved the business units are with reviewing and finalizing the content.
-
Try putting up a wiki or blog to see how contributors respond to frictionless publishing. Remember to keep the experiment going past the time that the novelty wears off.
If it looks like the content originators in your organization need a lot of help developing content, distributed authoring will probably not work for you and you should probably take that out of your business case. That doesn't mean you don't need a CMS, better tools will make your webmaster/web coordinator more effective. Beyond the business case, knowing your organization's aptitude for distributed contribution will help with your technology selection. If the CMS will only be used by a dedicated web team, you may want to value power and flexibility over simplicity and intuitiveness; power users will have a greater propensity and desire to learn the platform and stretch its capabilities than the occasional user.
If you went ahead and deployed a CMS with a business case that relied on solving the webmaster bottleneck, it is probably a good idea to test that assumption before you think about enhancing your solution. Some good questions to ask are:
-
Do content contributors feel empowered or burdened? Talk to your distributed content contributors and see how they feel about this added power and responsibility. Do they feel like content is an unfunded mandate? Be careful to listen critically. A content contributor may blame usability when the real issue is the difficulty of producing good content.
-
Does the site owner/coordinator feel like he is steering or pushing the content bus? Talk to the web coordinator about the timeliness, quality, and quantity of content coming from the business units.
-
Has the publishing volume increased since the introduction of the new system? Hopefully, you have gathered some metrics about your content publishing volumes before deploying the new system. Measure the delta. If your goal was to grease the skids of your content publishing process, you want to see a positive change.
-
Has the quality and timeliness of the content increased or decreased with the new system? With content, more is not always better. Just as important as the volume is the ability to be responsive to specific content needs. You want to see reduced lead-times from content-event to publication. For example, lets say there is some company news such as a new acquisition. How long did it take to respond to that news with content (press release, feature on home page, change in leadership)? This is a measurement of your whole content management process, not just the technology platform.
I would say that unrealistic "webmaster bottleneck elimination" goals are the leading cause of perceived failure in content management initiatives. Be careful before you promise this benefit. If you already made this mistake, don't jump to blame platform usability and focus all your remediation efforts on user interface work. Instead, invest in the people and processes to create good content. Shape the tools to serve the people in your organization who are willing and able to shoulder the responsibility of content publishing.