Building Workflows that Work

Implementing good workflows involves both art and science. If people were 100% consistent and predictable then maybe science would be enough. Someday soon AI may generate perfect automated workflows, sans humans, and we’ll just collect our basic income and write poetry. Until that day, we’ll need to intelligently leverage workflows to corral our messy selves.

I’m a believer in good workflows and I take pleasure in seeing loads of work getting done in a well-designed system. I’ve studied BPM and business analysis and I’ve been in the trenches, deploying tools and processes for lots of users. More importantly, I’ve gotten lots of user feedback about what works and what doesn’t.

In the fashion of modern blogging, I’ve distilled my years of struggles and “Aha!” moments into a discrete set of points that you can implement today and skip all the blood, sweat and tears. OK, I’m being facetious, but the discerning reader should know that this stuff isn’t easy.

First, and maybe obviously, you need software. There’s a broad range of software that is capable of some semblance of workflow. Such as simply using a dropdown to indicate the current step, Kanban boards, or full-blown BPM engine. Your workflow design will be limited by the capabilities of your software, or the extent of your development resources.

Here are some things to think about.

Identify the Trigger

There’s always an event that starts a workflow. It is not a step in the workflow. For example, “a user submits a new helpdesk request” is a trigger. In BPMN notation, this is depicted as a circle, differentiating it from other human or software tasks. The completion of another workflow may also be the trigger for a workflow you’re designing.

The Handoffs

Consecutive workflow steps assigned to the same person are just annoying. Don’t do this. Most workflow steps follow this pattern:

  1. Get notified that you’re supposed to do something.
  2. Do what you’re supposed to do and click a button to say you’re done.
  3. The software notifies someone else and tells them to do the next thing.

Between your task and the next task is something called a transition (or edge in graph theory). The transition is important because it marks task boundaries, a reassignment of ownership and often triggers a message to the new assignee.

If you understand the hand-offs, then you’ll understand who the participants in the workflow are.

Tasks in Black Boxes

A workflow step can have many tasks. That little rectangle on your swim lane diagram can have a lot of stuff going on. You don’t have to decompose the steps at an atomic level. When there’s a transition, i.e. a change in assignment, then add a new black box.

Workflow steps provide a level of abstraction that helps avoid getting lost in the weeds. Focus on the step’s definition of done and what is required to transition the workflow to the next step. This might be a state change (e.g. ‘Completed’), a deliverable or even completion of a workflow in another organization or tool.

Workflows are Guides not Guardrails

The humans know how to do stuff and can generally adapt better than workflows. Workflows can never represent all outcomes. Build flexibility into workflows so that users can adjust when the unexpected happens. Empowering users is better than heavily constraining them to prevent errors.

Good Workflows Get out of the Way

A well-designed workflow in well-designed software helps users get work done and does not create unnecessary overhead. Clicks should add value, not pain.

There are Happy and Not-so-happy Paths

We have an idealized view of how work gets done. This is called the happy path. As Mike Tyson said, “Everyone has a plan until they get punched in the mouth.” That encapsulates the not-so-happy path. What could possibly go wrong? A good workflow design will cover the happy path as well as exceptions. Or, at least provide the flexibility to adapt.

Optimizing your Workflows

  • Does every step add value? Can it be merged with another? More steps don’t mean more control.
  • Can handoffs be reduced? This will reduce notifications, missed emails and time lost during task transitions.
  • Do users frequently copy and paste between apps? Integrate the apps.
  • Do users constantly switch back and forth between apps? Integrate the apps. Reduce context switching.
  • Can manual workflow steps be automated? Build once. Execute endlessly.
  • Is all required information really used? Ruthlessly eliminate unused, unnecessary fields. Database logs can provide clues.
  • Enable macro-management (not micro), reduce cognitive overload and abstract away complexity.
  • Managing too many little workflow steps? Put them in a project and roll up status to that level. Provide functions that manage across multiple tasks and workflows.
  • Empower the humans to manage by exception. Automate the rest. Surface bad events.
  • Is the scope of your analysis broad enough? Unexplored processes may be huge time sinks. Root them out.
  • Are people using Excel to manage work? Excel is symptomatic of people improvising because systems are inadequate. Build workflows and tools to bridge this gap.

That’s an oversimplification but I’m confident you can get a lot of mileage out of these points. Reengineering business processes, and leveraging technology to do so, is a struggle that involves careful analysis, design, development and change management. Users adapt to good and bad processes alike, sometimes becoming attached to either one. The greatest determinants for building workflows that work are empathy, a willingness to listen and a commitment to change.

Our team has years of experience in building translation workflows.   Message me (trent@spartansoftwareinc.com) if you want to see how we can help improving your translation workflow.