Workflows: To Know Them Is to Love Them

Workflows are crucial to everything we do, but what exactly is a workflow? It’s a process, a set of ordered steps used to complete a task or reach a goal. Brushing your teeth is a workflow, as is driving a car, using a GPS program to navigate that car, cleaning the house or, really, using anything that comes with an instruction manual—even the toaster. We may not think of these things as workflows, but as routines or habits—if we think of them at all. The true test of a good workflow is you don’t even know you’re using it. They’re undetectable.

In the context of daily business life, workflows get things done correctly and as efficiently as possible. They can be very simple, like keeping a calendar, or something more complex involving multiple workflows spanning multiple people or departments, such as production schedules. Automated systems can incorporate thousands—or even tens of thousands—of workflows. 

Jargon alert: When multiple workflows are linked together, they constitute a system or an application. When you hear the terms functionality or process, they reference the workflows incorporated into a system or application.

The larger and more complex a workflow becomes, the harder it will be (and longer it will take) to reach the undetectable stage. Simple workflows like operating a new coffee machine in the office become second nature very quickly; using a financial or title management system will take longer—but it will happen over time.

Similarly, re-engineering workflows or implementing a new system will also take time to incorporate into a daily routine. Habits are hard to change. Muscle memory is strong. Anyone who has ever rented or borrowed a car and spent ten minutes figuring out where the gas cap release, headlights, and air conditioning controls are—and how they work—knows what I’m talking about. Change management, or providing support during this transition, is a key to a successful workflow design. 

The Workflow for Workflows

I’ve been involved with designing, revising, and reengineering workflows throughout my career in publishing. Regardless of size or complexity, I generally follow a standard workflow to create workflows. There are variations, of course, depending on the project and people involved, the tools that are available, and the company culture, but the following approach can be tailored to most any circumstance.

First Steps:

• Identify the task and the expected results: What is it that you are trying to do?
• Define the business justification/benefits, ROI, etc.: Why do you want to do this? More specifically, “Why do we need to spend time, effort, and resources on this?” 
• Assign ownership of the workflow: Who makes final decisions, approves scope changes, resolves disputes between participants, approves resource requests, and has the final sign-off/approval at each step of the process? (This could be one person or an oversight committee.)
• Complete a preliminary estimate of the size of the project: How complicated is the project? How many people need to be involved and for how long? Will this project need only internal staff participation, or will external resources and services be needed, or both? Estimate any budget considerations.
• Identify the participants: Make sure all people, groups, and departments affected by the workflow are represented in the design and implementation stages of the project.

Gathering Requirements:

• If this is a project to replace a current workflow, document the as-is state: How are things done now?
• In all cases, document the desired state. What is the desired solution?
• Review the new workflow with stakeholders until a consensus is reached and all stake holders and owner sign off on the final workflow.

This is an iterative process. I do not recommend walking into the first design meeting, however small, and starting off by asking, “So, what are you looking for here?”

Have something to show, whether it is list of steps or a simple workflow diagram showing the steps and hand offs. Having something for people to react to gets the conversation going faster. Give people something to tear into, a place to start. The as-is illustration really serves this purpose well. And don’t take it personally if the participants start ripping apart your diagram. It is what you want. It means your audience is engaged and thinking. 

When replacing an existing workflow, people may try to copy the old workflow as much as possible. People only know what they know. Some may not be able to see beyond the as-is. For some, the current workflow has become second nature, and they can’t imagine a better and more efficient solution. While keeping some of the as-is may make sense in the new workflow, keep pushing for new ideas. The goal is to come away with an improved, more efficient workflow. At each step of the process ask: How is this done? Why is it done this way? Is there a better way to do this?

Acknowledge right from the start that if the workflow involves several people, especially people from across departments or the larger organization, not everyone is going to love the resulting design, especially if responsibilities are shifting or more individual work is required. Who likes more work? It is important to show the value in the changes. Building consensus is essential. Without it, the folks who are not happy with the result may find workarounds to avoid the new workflow. It happens. I have even seen cases where the workarounds turned out to be more labor intensive than the original workflow, yet the users still preferred them.

If you are leading these requirements sessions, be patient. Let the solution come from the people who will be using the workflow. They’re the real subject matter experts. Remember, in a lengthy and complicated project, business people taking part either volunteered or were assigned to participate. This work may be in addition to their day-to-day responsibilities. Be respectful of their time. Each meeting should have a fixed agenda circulated ahead of time, with meeting notes circulated within a day, detailing any decisions made and any items that need follow up—and who in the team will follow up, and when. Participant availability and attention will be fluid throughout the process depending on the participants workloads and schedules. There will always be moving parts to balance. 

Document, Document, Document

Documentation is key during all steps. Track all steps, changes, progress against the project schedule, and accumulating costs, if applicable. Keep an up-to-date project plan and share it with the team regularly. The project plan can be a spreadsheet or something more intense from a project management tool. Frankly, documenting existing workflows, even before you might be planning to change them, is a great exercise. A good workflow document can make a handy training tool for new employees. It can also give more visibility of the individual’s, department’s, or a company’s responsibilities. Ever hear anyone say, “My bosses don’t understand what I do?” Workflow diagrams are a great way to document responsibilities. 

Get Written Sign Off On the Requirements—and Everything Else

Prior to going live, there should be a formal approval by all parties to mark the end of the requirements/Design phase, and again after development and User Acceptance Testing (UAT). Strict enforcement of the sign-off and design depends on the company and the company culture. In any case, don’t be surprised if the following happens with your project: 

You go through the process; you iterate the design down to the final approval; you go through design and UAT and implement the workflow. After the workflow goes live, you get a pained message from one of the users simply stating, “This isn’t right. It’s not what we needed or thought we were getting.” Do not despair. This happens all the time. Designing something is one thing, using that design in real life is quite another. Workflows will need to be tweaked. In a complicated project, stuff may get overlooked until the project is in use. But doing as much up front as possible—being as detailed as possible in the requirements gathering stage, using workflow diagrams or screen mock-ups, or even prototypes for participants to test out—should limit the amount the final product will need to be tweaked down the road. 

These late discovered changes may also be a boon. My company implemented a title management system and created a workflow for deal memo and contract approval. One of our divisions asked for a custom workflow for their specific products and business models. We built that into the system. Months after that division started using the system, they decided they did not need the custom workflow and preferred the simpler standard workflow. Of course, it was not ideal to have spent time and resources building a custom workflow. But in the end, that division was happier and had a more efficient and less complicated way of doing things using our standard workflow. We counted that as a big win for everyone.

Workflows Are Not Written In Stone

A regular review of workflows is a good idea. Changes to the business, such as growth, new business models and products, acquisitions, automating manual processes, as well as changes in partner and supply chain requirements all require workflow review. It is not unusual that a person starting at a new company, especially in management, will bring workflow processes from their former company with them with the intention of using them—and that may be for the best.

Why Is This Worth the Trouble?

A well thought out and designed workflow can increase efficiency, improve communication, standardize process across departments and divisions, and create transparency over roles and responsibilities. If everyone involved in a task or a group of tasks knows exactly who is responsible for what and when, it’s a win for your business.

Phil Madans
Executive Director, Digital Publishing Technology
Hachette Book Group USA

Technology should empower, not hinder, the publishing process. That has been Phil Madans’s north star since creating HBG’s first intranet over 25 years ago. In his current role as Executive Director of Digital Publishing Technology for the Hachette Book Group, Phil applies his 40-years of publishing experience to evangelize and implement new solutions for content creation, workflow efficiency, metadata optimization, and system data integration. Phil has worked with many industry associations including AAP, W3C, IDPF, GS1, EDItEUR, BIC, and of course, BISG, where he has chaired or been a member of a dozen committees, task forces, and working groups. Today, Phil focuses on the work of the Metadata Committee and oversees HBG’s company membership in BISG.