There have been a number of interesting posts on workflow recently. Some say that workflow is a feature that is often asked for but seldom used. Others tell you that workflow is the foundation upon which automation is built. Both arguments have their points. For me, workflow is what you make of it. Depending on your requirements, you workflows may be sophisticated or simplistic. It just so happens that most organizations do not really know what do with workflow. Their processes were broken before and, until the processes are improved, workflow will only accelerate the transition from one stagnating work queue to another.
A good way to think about workflow is manufacturing vs. legislation. In a manufacturing model, you have a lot of content to produce and you have specialists who are really good at doing one aspect of the content production process (copy-editing, creating graphics, fact-checking, etc.). These specialists are sitting at their workstations waiting for their next task — that's their job. In this model, a workflow tool is tremendously helpful. It's like the conveyor belt in a factory that moves the units from one station to the next.
Unless your organization is in the content business, the manufacturing metaphor probably doesn't apply to you. You can think of your content producers as craftsmen that make unique items all on their own. When it does it occur, collaboration is typically ad-hoc and informal. Workflow is not going to help them any more than a factory is going to help a sculptor. The one exception there is automation. Even craftsmen like their power tools.
This brings us to the other workflow metaphor: legislation. A legislative process is mainly designed to filter out bad ideas. Legislation is the opposite of manufacturing. Rather than speeding things up, legislation slows things down. People complain about Congress being gridlocked or slow but that's the design. Any wing-nut can draft a bill. We live in a polarized society so we need all the checks and balances we can get. What comes out of Congress is hardly ideal but it could be much worse.
It is doubtful that you work in an organization that has the same diversity of opinion that a country or a state has — at least in matters of your business. So it is unlikely that you need an elaborate system of checks and balances. When companies tend to get hung up is when they envision a manufacturing process as they design a legislative process. In these cases, most of the people involved the workflow are reviewers who are only capable of slowing the content down. The more steps, the slower the workflow. These are the workflows that get whittled down until they are single-approval or, in many cases, direct-publish. If your contributors can create their own content and you trust them to adhere to the voice and standards of the organization, why not?
If you are like me and grew up in the U.S. in the 1970's, you probably remember that School House Rock cartoon about a bill and his journey through Congress to become a law. The bill complains about waiting around and getting sent from one place to another. I embedded the video. Watch it and imagine the bill as your content. Painful, right?
This high failure rate with workflow gives a lot of credibility to people who dismiss workflow as being oversold. The workflows that you see in product demos suggest you can choreograph your ad-hoc processes into an efficient assembly line. It presupposes an opportunity for specialization which requires people to be dedicated to a specific task. That isn't going to fly in most organizations until there is enough demand for content to justify building a factory.
A "Dynamite CMS implementation" is when an I.T. group deploys a CMS and then runs like hell like it's a stick of dynamite. You can't deny that they have moved lots of material, but they have also created a mess that will take years to sort out — and they have conveniently left the scene for the cleanup.
I don't mean to bash I.T. here. If content management was in their queue, along with any number of enterprise technology initiatives, they need to move on to the next project. They don't normally have a choice. This gets back to idea of "Content Management is not a Project."
To get back to the Dynamite metaphor, Content management is not like making a hole in a mountain. It's more like an archeological dig. Like archeological artifacts, content must be preserved, organized, and continually re-assembled to create meaningful and cohesive stories. Archeologists and content managers use specialized tools that balance efficiency and precision. Content management is like archeology in real-time — new content artifacts are being produced every day. Some of what we find fits nicely into the organizational structures we have. Other content challenges our models and tools and forces us to adapt.
Whoever is responsible for a new content management initiative needs to understand that this is a program that cannot be walked (or run) away from when a new tool is deployed.
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.
A few weeks ago I had the pleasure of participating in a J.Boye expert group in New York. I love the open and honest format of the J.Boye events and am looking forward to the J.Boye conference this May (3-5). I am presenting on content management assessment (Grading Your CMS Implentation) in the web content management track. That track will also have a talk on HTML5 and case studies from The Nature Conservancy, The Smithsonian Institution, and University of Houston Libraries.
I think this is going to be a great track for organizations that have laid down the first parts of the foundation and are looking to take their websites to the next level. Hopefully I will see you there.
Context: the purpose and background of the project.
Scope: the scale of the project and other related work that was lumped in.
Execution: how the project was organized and executed.
Results: how the solution has changed the organization.
I plan to present the findings of this survey at my Grading your CMS talk at J.Boye this May and publish the data here. I think this data will be of interest to most people involved with content management. Practitioners, integrators, and vendors all want to know how their experiences compare to that of their peers.
If you are reading this blog, you are probably affiliated with a number of CMS implementations. You probably work for a systems integrator or a software vendor. If that is the case, I could really use your help. If any of your customers has recently gone through a WCMS implementation, please ask them to take the survey. Thanks!
I have been hearing that mobile as a first-class content consumption device is "right around the corner" for around 12 years. At first, I was really excited by the prospect. Then, over time, I started to become skeptical and ignored the prophesies. Part of the problem was that I was always on the laggard end of phone gadgetry. Then a few years ago I got my first iPhone and my attitude started to change. I was actually using the web on my phone! It often sucked but that was OK because I was on the bleeding edge and we bleeding edgers can handle little inconveniences. Now all of the sudden, however, the mobile web is truly ubiquitous. Everyone has a smart phone — even people who "don't do technology."
Some of you reading this are probably wondering why I am writing on such an obvious topic. The analysts have been talking about this trend for years. Well, I am writing this because despite all the prediction this trend is still taking us by surprise in various ways.
A publishing client of mine recently told me that they are getting 20% of their traffic from mobile devices — 20%!. People are still talking about supporting IE 6 and 7. Together, those browsers make up less than half of that. In fact, all of IE makes up just 26% of overall web traffic. My client also shared with me two other interesting facts. First, email subscriptions are bigger than ever for them. Remember when people were predicting the end of email? Those folks were not thinking about mobile. The fact is, email is still mobile's killer app. Every baby boomer with a blackberry gets email to his hip-holster. Email is the primary entry point for my client's mobile traffic.
The second point he made was around advertising. Selling advertising on mobile is a challenge — not because the banner ads are so small (which is what I was thinking) but, because most advertiser websites are not mobile optimized, click-throughs are embarrassing for the advertisers. The customers who are clicking through are not just the tech savvy people who have the skills to accommodate some glitches. These people just see "broken" and move on. This creates an interesting dynamic that is similar to the early days of the web when web publishers needed their advertisers to build nice looking websites to get online advertising revenue.
I think most web teams are like me. We have been hearing about mobile forever. We had plenty of time to prepare but still we are caught off guard. We may have over-invested too early and were hesitant to get burned again. But now companies know they are behind. They are trying to catch up throwing cash into flashy apps. However, maybe money would be better spent on less sexy technologies like email subscriptions and mobile-optimization of their various websites. That would sure go a long way.
This is the third installment of a series of articles on content management assessment. The most recent article ("Have you modeled your content effectively?") introduced warning signs that may indicate that your CMS implementation can be improved by adjusting your content model. In this installment, we will be looking at how you did with workflow.
Workflow has always been a key selling point for content management systems. In sales demonstrations, multi-step workflows give the impression of efficiency and time-savings. Workflow holds the promise of being able to choreograph the presently inconsistent efforts of different stakeholders to achieve high levels of efficiency and consistency. Workflow represents the "Management" in the CMS value proposition. Who doesn't want to transform their chaos of content into a well oiled publishing machine?
In the real world, however, the editorial process is often less repeatable and the manufacturing metaphor doesn't fit so well. It takes time to figure out what aspects of the editorial process are stable enough to encode into a workflow. Maybe the reason people are not doing their content tasks is something other than not knowing about them — like other responsibilities have a higher priority or they procrastinate. Unfortunately, CMS buyers often reach this level of understanding after the budget has run out. The result is a system that is over-engineered to support some idealized representation of the editorial process.
Here are some key questions to determine if your organization has fallen into the workflow trap.
Did the workflow that you wanted to accelerate publishing slow it down?
There are really two purposes for workflow: to speed publishing up or to slow it down. A workflow speeds up publishing when it coordinates a creative process. For example, a graphics person may be responsible for finding and editing images to be used in the content. Workflow can also execute automated steps such as tagging and placing the item in the site hierarchy. You can think of a little content assembly line here where different specialists and robots all have their role in producing the asset.
Workflow slows down publishing when it is used to support a review process. The function of reviewers is to send back content that is inaccurate, inappropriate, or off-message. The reality is that most organizations dream for the assembly line but wind up building review-oriented workflows. Often new review steps are added when a workflow is implemented. It is much easier to find reviewers than it is to find creative specialists that can speed up content production.
Do contributors find themselves clicking through workflow steps without actually doing work?
When collecting requirements and selecting a CMS, it is good to look at your editorial process and a natural outcome of this analysis is a flow chart. Like any diagram or model, when you are making it, you know that you trying to illustrate how the process can or usually works — not how everyone must work all the time. You might have even overstated the complexity just to make sure that you select a product with flexibility just in case you need it in the future. Many CMS products have visual workflow designers that can transform that flowchart into a workflow that drives your editorial process. The next thing you know, boxes that were put in the diagram for talking points (like something that one would do offline) become mandatory steps that people have to click through — formalities that provide no value. Asking this question may also hint at a common syndrome in web content management where all of the editorial process happens before the content is even put into the system. Users often prefer ad-hoc tools and processes to generate and review content and the web content management system is simply used as a publishing tool to get it out to the various digital channels that it serves (web, mobile web, applications, RSS, Twitter, etc.). There is nothing wrong with this unless you pretend that you are doing all this editorial work in the system and you have to unnecessarily click buttons to imitate the work that you already did.
Do contributors find themselves playing multiple roles in a workflow?
During a CMS selection, design, and implementation there is a tendency to be inclusive. You want to engage potential users to design a system that will work for everyone. Everyone is a stakeholder; everyone has a role in managing content. People attend the meetings and play along. It's fun to talk about content and communication .... until actual workflow assignments start to pile up in their queues. Then all of the sudden people get less interested in having their approval be a bottleneck in the editorial flow. People bail out leaving the hardy core content team to play roles that were abandoned.
Are there workflows that are rarely used?
Workflow, like any business process optimization, requires trial and error and continuous improvement. When a workflow doesn't seem to work for an editorial group, content type, or circumstance, there can be an urge to build a new workflow. This is especially the case if workflows are fine-grained and tightly bound to individual people. This often leads to a proliferation of workflows that clutter the interface and confuse users. When you see this happen, it is useful to step back and ask if every nuance of every process needs to be encoded into the software as a formal workflow. Can decision points for special cases happen outside of the workflow? For example, perhaps once a year there is an annual report that needs to be reviewed by the CFO. This is the only piece of content that the CFO needs to review. In this case, it would probably be better to handle that step as part of a more generalized step. Perhaps, during the legal review step the corporate council (who reviews lots of content) knows that he needs CFO approval so he works with the CFO out of the CMS to review the documents (perhaps in email or some collaboration tool).
It is healthy to look at every step of a process and consider its positive or negative impact towards outcomes. This is what Lean Production and value stream mapping is all about. The workflow engine that comes with a CMS can help by forcing conversations about processes and how they can be improved. However, most of the workflows that are implemented to guide these processes wind up wasting time on formality that doesn't apply. Because of this, workflow tends to be the most over-sold and under-used CMS feature. To get the most out of a workflow system, you need to have goals for the process that it supports. Are you primarily focused on time to market? Maybe direct-publish is the way to go. Are there automatable steps like publishing a link to Twitter? Workflow can help by providing an event-based trigger to execute some code. Are you focused on brand consistency or compliance? Start measuring your success against those goals and figure out how to achieve high scores with as little effort as possible. The workflow capabilities of your CMS may assist improvements but they may also get in the way. If you don't use workflow properly, don't blame the CMS.
Nearly all content management systems have flexible repositories that allow you to control how content is structured. This is important because every organization's content is different just like every website is different. But this flexibility can also be a liability because it creates opportunity for bad design as well as good design. Content can be under-structured, over-structured, or wrongly structured. Asking the right questions will help you assess how effective your content was modeled.
Do your contributors spend a lot of time formatting content?
If your content contributors spend a lot of time formatting, it may mean that your content is not structured enough. Look out for "formatting patterns" where a content contributor repeats a format pattern to give the illusion of structure. For example, if the by-line and date-lines of articles are stored in the main body and distinguished by a particular font treatment, those should probably be fielded elements. The risk of letting this go is that it reduces flexibility. The only way to change how a by-line looks is to go into each article and change the formatting.
Do your content contributors feel like data the entry aspect is overshadowing the creative process?
While structure is generally a good thing, too much can be stifling to the overall goal of content: communication. Most content contributors need a blank palette to rearrange and massage information until it tells the right story. Filling out endless form fields breaks that flow and never allows the creative process to take root. A good example is forcing a user to enter the body of a semi-structured content asset into a series of paragraph fields rather than one rich text field. A series of paragraph fields makes it hard for the author to re-arrange content and split and merge paragraphs. A good clue that your content entry interface is overly cumbersome is if content contributors wait until the very end of the editorial process to enter content into the CMS.
Do you frequently find yourself wishing for a global (as in site-wide) search and replace?
On one CMS selection, I received a requirement for a global search and replace. The reason for this requirement was a recent episode where the organization's phone number changed and they needed to update every press release because the contact number was embedded in the body field below the rest of the article. Not everything that a visitor sees on the page has to be entered by a content contributor. Some of the page can be hard-coded into display templates. Other parts of the page can be managed as global content components. In this case, it would have been better to embed the phone number in the press release display template below the body copy. If the phone number was likely to change frequently, a global content component would allow a content contributor to edit this information in one place and without the assistance of a template developer.
Do content contributors find themselves duplicating the same text over and over again?
A content management system is not doing its job if contributors are not effectively reusing content. The classic example is an article list and detail page. If content is structured properly, the article headline exists in only one place: in the article. The list page queries the articles and lists their headlines. If the headline exists in two places, it needs to managed in two places. Now, this is an obvious example and it is shown in nearly every CMS demo that I have seen. A less obvious example is a promotional element — some block of display that promotes some messaging or a product. You want to manage those as components that can be re-used in different places on the site. I call this keeping your content DRY. With better reuse, you can manage less content and still support the same visitor experience. The downside to reuse is that it makes specialization hard, you can't change the wording in one place without it affecting all other occurrences of that content. You need to make decisions about whether specializing a piece of content is worth the additional management overhead.
Do content contributors overload or misuse content attributes?
A hallmark of an un-maintained content management solution is when content contributors start to get creative and misuse content elements to achieve the behavior that they want. Deane Barker has an excellent presentation on this called "Just Put That in the Zip Code Field". This warning sign means that the requirements for the solution have changed but the solution has not adapted. It is a big issue when your content contributors care more about the website more than the support team. On the plus side, this means that you have established ownership over the content. On the negative side, the organization as a whole is either unwilling or incapable of supporting that ownership. If you see these signs, you need to get in gear and honor content contributors' commitment by taking better care of the solution.
The good news is that most content management systems will allow you to correct content modeling inefficiencies — but with certain limitations. First, content management systems tend to have different strategies for managing content: page based or object based and the extent of available data types varies from product to product (again, check out Deane's presentation). Second, going from more structure to less is easier than going from less structure to more. You can automatically concatenate multiple fields into one; it is harder to arbitrarily split large unstructured elements into multiple structured elements. Third, some content management systems have better utilities for doing bulk content transformations than others.
As a quick little exercise, try to prototype and alternative content model and ask your content contributors to give feedback. They may feel like they have a whole new lease on their content.
Most organizations who struggle with content management blame their CMS for their woes. The only hope for relief they see is to replace the platform and start over. But without fully understanding the true nature of the issues, an expensive CMS replacement project is not likely to improve anything; it could even make matters worse. It is highly likely that the CMS doesn't need to replaced and better results can be achieved by reconfiguring the current platform and adjusting roles and processes. As Ian Truscott so eloquently confesses:
Having seen plenty of examples over the years of web content management replacement projects and a common perception that any problem is a tools problem. Also, I confess having been in sales situations as a vendor that have preyed on the fact that an organization perceived that their incumbent product couldn’t do x, y or z when, in truth you can be fairly sure something has gone wrong along the way.
Before you go into CMS selection mode, consider a content management assessment that takes a holistic view of your content management tools and processes. It highly likely that you could be using your current tools more effectively. If that is the case, your organization can solve its content management problems with much less expense and risk. A content management assessment covers a lot of the same ground as a CMS selection but leaves open the possibility that the best platform may be the one that you are already on. If it turns out that you do need to replace your platform you have a head start in a selection because you will already understand your requirements and will some made some operational improvements. Otherwise, you will have a nice list of enhancements that you can use to tune your current tools and processes and achieve better results.
This is the first in a series of articles that explains different aspects of a content management assessment. The following articles will dive into questions one should ask in a content management assessment and how to get to the correct answers. These topics will also help new implementations avoid problems before they occur. Stay tuned!
I recently read Richard Thompson's excellent post "Is content strategy biased towards the written word?" I have to admit that during my read and also during the many moments of reflection that followed, I found myself thinking "but there is a good reason to focus on text as the primary format of content." Other content formats are best used to enhance the written word. Heck, I even wrote a blog post extolling the superiority of the written word over text. All the while, however, I was nagged by the possibility (rather probability) that I was projecting my personal own bias.
As I mentioned in my post, I don't have the patience to wait for information to be spooled out at a pace that I cannot control. I like to scan and search and you can't do that very easily in a video or audio. But, I also agree with Rich's point is that many of the most popular websites are filled with non-text content so I would be foolish to deny the appeal. But then I think that these sites are primarily for entertainment purposes and when I am in leisure mode, I am not so goal oriented. I like experiences like movies where I can sit back and let a story unfold.
As you can see with my flip-flopping, I haven't made up my mind on this issue but, like Rich, I am starting to be more aware of the circumstances when non-textual content would be preferable to text. Ideas that come to mind are:
Any form of entertainment (many people are more likely to watch a movie or listen to an audio book than read the book on which it was based)
Instruction on topics where technique is critical such as hitting a baseball or disarming a nuclear warhead
Things that you need to see to believe like pictures of a flooded town.
Can you think of other times when non-text content can go further than the written word? One thing is for certain; when you decide that you can communicate better with non-text content, you better be sure. Many organizations struggle to maintain their text-based content and non-text content is vastly harder to manage. You need more sophisticated skills and tools to update a video or audio track — even a picture. But maybe that is just my own bias peeking out again.
