Workflow, in the context of a unified content strategy, defines how people and tasks interact to create, update, manage, and deliver content. Workflow moves content from task to task, ensuring that the business rules specific to your organization are followed, for example, that sign-off occurs at the appropriate levels. This chapter describes the concepts of workflow and its benefits, and takes you through the basics of designing workflow to support your unified content life cycle.
Once you’ve determined what your workflow processes should be, you can select tools to support and automate them. Refer to Chapter 17, “Workflow systems,” for information on tools that support workflow.
Workflow, as its name implies, is the way tasks flow through a cycle on their way to getting a job done. Workflow helps organizations perform tasks in an efficient and repeatable manner.
Workflow is a process that may or may not be automated. However, when numerous people and activities are involved in a process, human-controlled workflows can be problematic; steps can be missed, work forgotten or misplaced, and approvals omitted, all delaying the finished product. With automated workflow, organizations can create repeatable and verifiable processes to ensure that all stages of a project are completed in the proper order. But, before automating a workflow, you must first design and test it so that processes are consistent with your unified content life cycle. When designing workflow, you represent it diagrammatically, showing the various tasks involved in a project. Your workflow representation not only illustrates all the tasks and players, it also shows where your processes need to be simplified before they are automated. Just as you are improving the way you create and manage content, you are improving the processes involved through the content life cycle.
The following are the components of workflow:
Roles (players)
The people who do the tasks, identified by their role
Responsibilities (tasks)
The steps to complete a particular piece of work; everything that must get done within a process
Processes
The flow of tasks, as performed by the various players, showing the interactions and interdependencies among players
These components are described in more detail later in this chapter.
Chapter 8, “Information modeling,” compares building information products to building a house. Houses are constructed based on their blueprints, and information products are constructed based on their information models. Once the blueprint is completed and sign-off has taken place, the builders follow processes to make sure all the construction tasks happen in the correct order. Some tasks are dependent on others, some are concurrent, and at some stages, the building inspectors, the architects, and the home owners review the completed work before construction of the next components can proceed. In the construction industry, despite the best blueprints, timing and planning are critical. The blueprint simply lays out the plan; the workflow ensures it gets done properly. Accordingly, workflow is tracked throughout construction to ensure that certain things occur:
Materials are delivered in the order that they are used (for example, concrete before shingles, framing materials before windows).
Other players (subtrades) come in when they’re supposed to (for example, electricians can’t do their part before the frame is up) and concurrent jobs are scheduled appropriately, so that time isn’t wasted.
Approvals are done at the right time (for example, inspection of the electrical work has to be done before the walls are up, obscuring the wiring).
Workflow in a unified content life cycle is similar to the workflow that builders follow. Despite the best information models, creating information products should progress in a logical, well-designed flow to ensure that tasks are completed in the proper order, by the correct people, and that approvals occur when they are supposed to. In the content management world, good workflow design ensures that:
Departments that should be creating content—or that should at least know about it—aren’t left out.
Content and all other supporting elements—such as graphics—are created in the proper order (for example, content is written before graphics are drawn, ensuring the graphics support the content).
Content is reviewed at the right time, by the right people, eliminating reviews and approvals that have to be redone if additional changes are made.
Departments are notified when content is published (for example, customer service staff are notified when a new brochure is out in case they get phone calls about it).
Efforts aren’t duplicated and content is consistent (for example, different departments don’t end up creating different versions of the same content).
Work isn’t held up at any given stage of the workflow.
Content is stored in the right place after it’s written, reviewed, approved, and delivered.
An effective workflow is really just the organized and managed application of common sense, as governed by the business rules of your organization.
Through workflow representation, you can see processes as they exist now, then depict them as you’d like them to be. Simplification should always be one of your goals when depicting your workflow. Otherwise, you may end up including tasks that don’t need to be done in the first place, like sending information to a department as part of the approval or review process, when all they really need is notification that the information has been published. It’s not only critical to depict everything that happens, but also what should happen. This is similar to information modeling, in which you don’t model information products as they are currently structured, but rather, as they should be structured.
To improve or simplify a process, you analyze and change the tasks, then test the process to make sure the work will flow properly. Tasks may be eliminated or combined, the sequence and location where the task is performed may be changed, as can the person who performs the task. Benefits of such change include:
Greater efficiency
With well-designed workflow, the work is easier and can be done more quickly, and the tasks require fewer steps to complete. Tasks are handled concurrently wherever possible and “what ifs” are built into the processes, eliminating delays.
Better quality
Better quality results from focusing tasks more clearly. Tasks become more individualized; they are smaller and less complicated, taking less time to complete. With more focused tasks, authors can visualize the big picture without being pressured by it. Instead, they focus on their particular tasks as those tasks relate to the big picture.
Lower costs
When duplicate efforts are eliminated, costs are lower. When content is consistent, less effort is required to address inconsistencies, either from internal or external users.
A good workflow system must be able to support your workflow design, but for your workflow system to work effectively, you must first design what you want it to do. You need to figure out how—given certain business situations—tasks such as authoring, editing, reviewing, approval, publishing, and distribution should flow throughout your organization and what should happen if, at any given stage, a task cannot be completed as dictated by the workflow.
Because workflow describes the “flow” of tasks, it is usually depicted diagrammatically in either a linear flowchart or a swimlane diagram.
Linear flowcharts depict a process from beginning to end, often using flowcharting symbols to indicate the types of tasks in the process. Flowcharting symbols illustrate such things as which task is a process, which task is a decision, which task is a predefined process, which task is a manual operation, and so on. Although flowcharting symbols can be useful in representing meaning visually, we recommend a simpler approach: boxes with clear task descriptions written in them. Flowcharts should be understandable to most people, with minimal training or effort. They should also be universal. Many people become frustrated trying to interpret what the many different flowcharting symbols mean and their frustration is compounded if there are no clear task descriptions accompanying the symbols.
Swimlane diagrams show processes in “lanes” (like the in which lanes you swim laps) to depict tasks that occur concurrently, illustrating who does what, and when. Swimlane diagrams are known by many other names, among them process maps, business process maps, process responsibility diagrams, and LOV (line of visibility) charts. Like in a pool, where swimmers are expected to stay in their own lanes, players stay in their process lanes. However, with all the lanes shown, players can see how what they do depends on what others do and vice versa. In addition to using arrows to connect tasks linearly, you use arrows to connect the tasks in the various swimlanes. Figure 11.1 uses a swimlane diagram to illustrate the opportunistic reuse process. (Note that players are shown by their roles, followed by the names of their departments in parentheses.)
Figure 11.2 illustrates the systematic reuse process. Note the similarities and the dissimilarities between the systematic reuse process with the opportunistic reuse process.
How should you depict your workflow? It really depends on what you want to depict. We like to use swimlane diagrams because they show the interdependencies of tasks. Linear flowcharts are useful if you want to show all the tasks within a process, with a view to simplifying them. This technique can be effective when you need buy-in from others in your organization. Linear flowcharts that detail every step, including hand-offs and wait-tasks, may end up being many feet long. Their size alone may convince others that the process should be simplified.
To design workflow as it will be supported by a workflow system, you may want to use a swimlane diagram. A swimlane diagram shows all roles and all tasks, as they relate to each other, which is critical in a unified content strategy. Also, people can highlight their particular role on a printout for quick reference. However, with that said, while depicting workflow, simplification should always be one of your goals regardless of what type of diagram you use. While drafting your swimlane diagrams, you may want to use flowcharts to illustrate where you can simplify tasks.
Workflow consists of roles (the people or “players” who participate in the process), responsibilities (the tasks for which the players are responsible), and processes (the workflows that connect all the people and tasks together and define the path that each task must take).
Developing, managing, and delivering content involves many people with different skills, spanning many tasks over an extended period of time. Content comprises many elements: text, images (and potentially video and sound), layout and design, and so on. This multi-faceted nature of content introduces complexity into its development process. Many different departments create content in a number of different formats for a number of different audiences; once content is created and delivered, it must be stored so that it can be accessed later on.
Generally, a player is any person or group that handles the work between the initial event and the achievement of the process’s results. A player can be anyone who fulfills a role within your organization, or a player can be an external customer or supplier. Information systems are also players. The role of a player may be very complex or as simple as being notified that a new product or new information is available. Regardless of the complexity—or simplicity—of each role, the workflow must accommodate all roles. If you leave out roles, you will not have an accurate depiction of all the project phases, which could unnecessarily delay your project.
Some common players are:
Authors
An author is anyone involved with creating content of any type (for example, text or graphics). Authors should have full permission to create, modify, and delete their own content, but not anyone else’s. Authors can be broken down into as many types of authors as your organization has.
Reviewers
Reviewers check content for such things as accuracy, completeness, appropriateness. Reviewers are usually limited to making comments on the content without changing it.
Editors
Editors review and make changes to content; the scope of their changes depends on their role as either substantive or copy editors. Editors can also be reviewers, but unlike reviewers, their permissions allow them to modify the content.
Approvers
Approvers provide the final sign-off for content before it is “posted” or published. Approvers can also be reviewers, and although their permissions are similar to the reviewers’ permissions, approvers have the final authority to determine whether the content is ready to go to the public.
The workflow doesn’t tell the players how to do their part; it tells them that they have a part, what that part is, and when it must be done. The workflow must also allow for alternatives if players are not available when they are required.
In a swimlane diagram, the players are the swimmers actually doing the work (tasks) shown in the swimlanes. Your workflow must depict how all the different swimmers collaborate on the different aspects of your project in a tightly integrated manner, without swimming into other swimmers’ lanes! In a swimlane diagram, each player is shown on the left side of the diagram, beside the lane which they belong in. Players are shown by their roles (for example, Information Architect), not by their individual names, along with the name of the department.
One of the most common questions people ask when charting their workflows is, “What is a task; how do I know what to include?” A task is a particular series of actions that accomplish a particular goal. A good rule of thumb is if it must “get done,” then it’s a task and you need to show it. To determine all the tasks within a workflow, you need to talk to the various players about their responsibilities, keeping the discussion focused on the particular process, not all the activities of the players their department.
You can categorize tasks into three types:
Tasks that add value (work tasks)
When value is added to a task, the work is changed in some way. Content may be written, approved, revised, returned for correction, have metadata added to it, and so on. Work is being performed on a work item, including inspection or validation activities. This is also known as “work time” and it advances the progress of the workflow as a whole.
Tasks that move the work along (transport tasks)
A task that moves the work along does not change a work item (for example, content isn’t written or edited); instead, it moves the work item from task to task in the workflow. People tend to exclude these tasks from their workflow, but transport tasks are critical to include because they illustrate important parts of the process, such as how a work item gets to the next person. Also, a transport task that moves information to a different location may take longer. In a transport task, include information on how the work item is transported. For example, “route first draft by email to supervisor in head office,” or “courier original artwork to ad agency,” or “post to intranet.”
Tasks that introduce a delay (wait tasks)
When a task introduces a delay, the subsequent task cannot proceed until the previous one is finished. A task that introduces a delay may not actually do anything to the work item; instead, it pauses the process temporarily. Most tasks introduce a delay simply by their nature; after all, it takes time for work to get done or transported. Sometimes when a delay is introduced, the next task may still be able to proceed. For example, while waiting for graphics, an author may still be able to complete a draft, then insert the graphics when they arrive. However, a delay-introducing task means that the next task has to wait for the previous one to be finished. An example of this is “wait for content from marketing before completing draft.” While waiting, the author can do other work, but not work that moves this process along. It’s important to include these types of delays because they give you a more accurate depiction of how long a process will take. A process may appear to take only 42 hours, but the delays may extend it up to 80 hours or more.
Regardless of the type of task, we recommend writing tasks consistently in a verb-noun format. Anyone who reads a workflow diagram should be able to understand it, so you should avoid cryptic descriptions such as “Form CP-13.” A task is something that is performed, and accordingly, should be written as an action. Instead of writing “Form CP-13”—which is highly open to interpretation—you would write something like “Submit graphics request on Form CP-13.” Optionally, you can include “how” information in your step, for example, “Sort graphics requests” could become “Sort graphics requests by due date,” providing additional information on how the task should be completed. You can also use qualifiers to modify the noun, for example, “Sort graphics requests from marketing by their due date.” The more descriptive you can make your task, the better. Tasks must never be open to interpretation. Although the task name must convey its result (for example, the result of “sort graphics request by due date” is that graphics requests are sorted by due date), do not write the task by focusing on the result, as in “Graphics requests are sorted.” The task should focus on the verb, the action of performing the task. It is not necessary to include players in the task description because they are indicated in the swimlane diagram and all the tasks belonging to a particular player are put in that player’s lane.
The system can have tasks as well. It can do such things as publish content to PDF, post content to the web site, or notify a reviewer that content is ready to review. These are tasks that are programmed by a system developer or integrator and to be included in workflow, they must available in your system. When you’re setting up your workflow system, be sure that it can perform the tasks you’re asking it to do (refer to Chapter 17).
In a swimlane diagram, tasks are shown in the swimlane of the player who does the task, with descriptive text depicting each task.
A process has a start point and an end point between which various tasks are performed, usually by a number of different people located in different places, who are often using different equipment or systems. A process comprises the tasks and responsibilities, as performed by the various players, and the workflow must illustrate the entire process from beginning to end. So, where to start? First, you need to decide where your process begins, where it ends, then start charting everything that happens in between.
Processes may start outside the system, but automated workflow starts when the system can manage a task. For example, the process to create a web product page may start with a meeting to discuss the requirements for the page. But the meeting may occur long before the system takes the content and routes it. This is not to say that you might not capture the meeting in a set of minutes with action items. In fact, you can store the meeting minutes in the content management system, designating them as “content of record” for access by team members. When you are depicting workflow, you may also include such tasks as “determining project requirements” and “holding meetings.” Even though they are not managed by the workflow system, it’s a good idea to include such tasks; they form part of the entire process and may be overlooked if not described.
However, the automated workflow starts when work begins on the action items, such as when the specification is created or when the marketing writer begins to write. At whichever point the process must be managed automatically, workflow begins. If you include requirements tasks, or tasks that are not managed through the system in your swimlane diagrams, you should indicate where the automated workflow begins; the automated tasks form your requirements for selecting and configuring a workflow system.
It can also be difficult to determine the end of workflow. For example, a web product page is posted to the Web, but it is modified over time to remain current. You could include the updates in the initial creation workflow, but it probably makes sense to end the workflow when the page has been posted. Then you can create an additional workflow that handles the content when it needs to be updated, modified, or corrected.
In a sense, the entire workflow process is like a virtual assembly line on which the various players perform various tasks to support the unified content life cycle. For example, research and development develops a new version of a software package; marketing gets the word out to potential customers; subject matter experts review the existing documentation to determine which elements can be used as is and which should be revised; technical publications makes the necessary changes, and so on. After all the tasks on the assembly line are complete, the last task is to notify the originator, thus ending the process.
Your company may also have specific processes for different types of projects. For example, you may need to develop workflows to support the content life cycle for:
New products or services
Updates to existing products or services
Discontinued products or services
You may also need to develop workflows for special situations, such as emergency notification of changes to your products. Depending on how complex they are, each of your workflows may also be broken down into various supporting workflows, but they must all relate to the common goal. That is, don’t have separate workflows for the various tasks in individual departments. You need to see how departments coordinate their tasks for them to be truly unified. For example, in the construction industry, there are workflows for the framing, the electrical work, and the plumbing, but they all relate to the master plan and depend on each other. Likewise, in a unified content strategy there may be workflows for writing user documentation, for developing collateral and graphics, and for creating training materials. All the processes are part of an overall project and are dependent on each other.
Processes are also usually governed by business requirements, specific to your organization. Business requirements include such things as:
Budgets that dictate how much can be spent on any given task
Hours of work in which tasks can be completed
Union job descriptions (or other associations) that govern who can perform a certain task and under which conditions
Physical location of the company that dictates where a task is performed (physical location can affect such things as handoffs and transport tasks, as well as translation and localization)
Suppliers that your company does business with and their particular constraints
When determining your workflow, you need to consider the business rules specific to your environment.
Processes are shown in swimlane diagrams with specific start and end points, and with all lanes completed with all relevant tasks, including such things as handoffs and delays. Where a task is performed by two players at the same time, you can write the task in each lane, but draw a box around them both to show they are performed together. Use arrows to connect the flow of tasks and to show when they transfer to another role/lane. Figure 11.3 illustrates the parallel tasks of review with all the members of the review team.
Remember that when designing workflow, it’s important that you don’t chart the processes as they currently exist in your organization, but instead, try to improve, or simplify, them. Accordingly, your first draft flowcharts may show processes in their current state, but your unified content life cycle workflows should show your processes as they will support your unified content strategy
The components of an effective workflow are players, their responsibilities (or tasks) and the processes they all follow. Designing an effective workflow involves analysis of players and their tasks, as well as identification of patterns and interactions, then a documenting of detailed tasks, followed by testing.
To design effective workflow, follow these steps, referring to your content life cycle:
Determine a starting point for your workflow. Usually a process starts with an incoming event, such as a new product being made ready for market, or a request to update existing documentation. A starting point can also be a crisis that you need to respond to. If you include tasks that are not part of the automated workflow, indicate where automated workflow begins.
Figure out a logical place for the workflow to end. This is typically when the incoming event that triggered the beginning has been handled satisfactorily. In a unified content life cycle, content must be stored in the repository for the event to be considered complete.
Identify all players from the beginning to the end of the workflow. Identify players by their roles rather than by their names. A task should be associated with a role to accommodate people moving in and out of jobs. If tasks are assigned to roles, regardless of where particular people move in your organization, the task stays with the role. If you assign tasks to people, you have to go into your workflow system and make changes every time the people change jobs.
Sketch the tasks. Start by identifying all the tasks that belong to each player, including when those tasks are waiting for something else to happen, or when they are handing off work to someone else. Remember to write tasks clearly so that everyone who looks at the flow knows exactly what the task is about. (You may omit notification in your first iteration, allowing you to focus more clearly on the tasks themselves. However, notification must be included before your workflow can be considered complete. See step 7.) Look for potential bottlenecks that may slow your workflow down, such as one player having too many tasks at a certain stage, while other players wait for those tasks to be done so they can contribute theirs. Can tasks be delegated to other roles? Can tasks be completed concurrently?
Identify interaction patterns among players and tasks. When are players working alone and when are they working with others? A critical component of workflow is in designing the interactions among players and their tasks. Who relies on whom or on what information? When there are numerous interactions, there may also be bottlenecks; look for potential bottlenecks that may slow your workflow down, such as information not being ready so one player is delayed in performing a task. Can you build in an alternative?
Allocate timeframes for tasks. In addition to selecting a start and end for the entire workflow, you should allocate start and end times for each task. When is each task complete and how much time should you allow from the time a task is assigned until it is completed? How much leeway should you build into the timeframe?
Identify notification patterns. Who needs to know what at any given stage of the workflow?
Identify approval patterns. Who is responsible for reviewing work items throughout the workflow? It’s important to distinguish approval from notification. Sometimes a department only needs to know about what you’re doing, but they don’t necessarily have to approve it. Make sure all your approvals are valid.
Determine all the “what ifs” that may knock your workflow off its path. Try to think of everything that could happen to deter workflow. For example, what happens if an approver is away? Can work be routed to someone else for approval? What happens to other tasks if a deadline is missed? What if a tool breaks or if content is lost somewhere along the way?
After all roles are identified, tasks are sketched, and notification and approval patterns are identified, examine your workflow to see whether it can be simplified.
Repeat these steps for all the workflow processes you need to support your unified content life cycle, for example, workflow for new projects, workflow for different types of new products, or workflow for updates to existing content.
Now that your workflow is documented, you can focus on selecting a workflow system to support your design. It’s important to design your workflow before selecting a workflow system because you need to make sure the system will do what you need it to do. For example, if notification is important to keep your workflow moving, you want to make sure that a workflow system sends notifications automatically. For more information on selecting a workflow system, refer to Chapter 17.
A unified content strategy requires unified processes that are supported by well-designed workflow. A workflow representation shows how tasks are assigned to the appropriate players, how tasks and players interact, and how players interact. It also shows the dependencies within the workflow. A well-designed workflow saves time and reduces duplicate work and potential errors. To design an effective workflow, keep the following points in mind:
Select start and end points.
Determine everything that has to happen in between, assigning tasks to roles. Remember to accommodate business requirements specific to your organization.
Identify all the interactions and dependencies, notifications and approvals.
Figure in the “what ifs.”
Document your workflow in swimlane diagrams, showing players’ roles in the appropriate swimlanes.
Examine your documented workflow to simplify where possible.
After you’ve designed workflows to support your unified content life cycle, you’re ready to find a workflow system to support them.