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.
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.
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.
Depending on who you talk to, Workflow is a core feature of a Content Management System. Many people looking for a CMS have Workflow in their selection criteria and many products calling themselves a CMS have Workflow on their feature lists. However, after experiencing workflow as a both a requirement and as a solution, I have learned that people's definition varies widely. For some products, having the most basic of approval mechanisms (two states: unpublished and published and a designated group of users that can change that state) is enough to claim workflow. At the other end of the spectrum, other products fully implement workflow standards.
The Workflow Management Coalition (WfMC) publishes a document called their Reference Model that describes workflow as "The computerised facilitation or automation of a business process, in whole or in part." This is pretty general (although I am sure there are some who would say that workflow is just about business processes and not about computers.). Workflow is commonly discussed as a set of states and transitions. A state, or "wait state," is a step in the process that requires action from external actor. A transition is an action that changes from one state to another. A workflow definition, describes a set of states and transitions and their relationships (the transitions are available from each state, the participants can initiate these transitions, and the required conditions for those transitions to happen) and also inputs and data that get captured along the way. A workflow instance is the execution of the process.
In his Server Side article The State of Workflow, Tom Baeyens describes a Workflow Management System as something "that takes as input a formal description of business processes and maintains the state of processes executions, thereby delegating activities amongst people and applications." Many CMS do not fully implement the concept of a workflow definition. What they call workflow is more of a task management system where any user can assign a task to anyone and no formal process is followed. CMS Matrix is somewhat reliable in evaluating this feature.
If you want to learn more about workflow theory, there are some excellent resources available. One of my favorites is Workflow Patterns which describes different patterns in workflow definitions along with very cool Flash movies that illustrate the behavior of the pattern. I think that patterns are useful here because they provide a language of commonly found workflow parts. So when I say something like "Synchronizing Merge", you know exactly what I am talking about. Some people will call this jargon but I think it is a good thing because it gives a shorthand way to express familiar concepts. The Workflow Patterns site also has an excellent reading list
There are many products (Open and Closed Source) which specialize solely in Workflow. These workflow engines integrate with other applications to provide workflow functionality. Most of them have a syntax (usually XML based) for defining workflows and an API that is able to receive events and trigger external processes. If you are looking at implementing a CMS only for the workflow, and your workflow is sufficiently complex and subject to change, you should consider this type of solution. Look here for a list of products. Another useful feature on the Workflow Patterns site is a page that indicates what patterns the major commercial Workflow engines support. When I get around to it, I would love to evaluate some Open Source workflow engines along these lines. Speaking of Open Source Workflow engines, here is a list of engines implemented in Java.
The industry is rich with standards especially in the area of Web Services which has the potential to coordinate workflows across application boundaries. One of the most interesting standards is XPDL which is published by WfMC. This is an XML schema that is used by several workflow engines to define workflows. The presence of a standard here means that you could theoretically port your workflow from one engine to another simply be moving a file. I emphasize theoretically here. Several workflow engines (Open Source and proprietary) use XPDL but, to my knowledge, no CMS does. It may be that XPDL is overkill for your typical CMS workflow definition.
Now that I have gotten you all excited about workflow, I would like to leave you with some very practical and sobering advice: less is more. Usually during the analysis stage of a project, workflows become very complicated. There are many factors that drive complexity: the fear of excluding stakeholders from the project, the fear of losing control, overblown promises when the project is sold, and just simply bad business process. More often then not, after painstakingly implementing complex workflows, I am asked to rip them out in favor of very simple solutions before the system is deployed because it is impossible to get anything published. Think about simplifying/streamlining/optimizing business processes before they are encoded into a workflow definition. Don't design for the most complex, infrequently used cases. Instead suggest managing these exceptional cases off line.