Three common errors in workflows/threads

Some things seem really simple, until you go to write them down and map them out in full detail.

So, you map out a workflow. How deep do you go?

Is ‘Schedule a review meeting’ one task or three? If you try calling, and they don’t answer, is that a new task? What about when it needs to escalate to the adviser?

Management want to know that the FDS date has been set. Is that a task?

In last week’s blog (So many tasks, so many notifications), we covered a lot about workflow tasks and notifications. This week I want to expand on this concept and three commons mistakes I see in creating a series of tasks to make a workflow.

These are:

These issues are often due to a deviation away from what should be the primary function of any workflow: Efficiency. Why? Because if everything is managed to peak efficiency, it cumulatively and positively contributes to every other aspect of the business. Risk management, client experience, productivity, quality, everything.

When we consider efficiency, especially in a Kaizen or Total Quality Management context, this intrinsically includes reducing risk of error. Managing errors is very inefficient.

Is that a step, or a giant leap?

There are only three good reasons for a new task to be included in a workflow:

When the work changes hands (obvs);
When the completion triggers automation; and
When an action absolutely must be tracked independently.

Tasks for automation

Automation can be an appropriate reason for a new task, so long as it is beneficial enough to offset the annoying need to move steps. Some good examples of simple automation that go beyond just commencing the next step could be:

User attempts to call and schedule a review. They nominate that they’ve completed the task and the client didn’t answer, so an email is automatically sent and a follow-up task set for one week.
User has a task to send a client pre-review email with updated FSG details. On completion the email is sent, and the FSG version/date supplied are updated, all automatically.

Tasks for tracking

Tracking with tasks runs counter to the primary objective of efficiency. Ergo, before creating a new task we should ensure we have exhausted other alternatives first. Some alternatives include:

Leverage the ‘Description’ – If it’s just steps that need to be followed, these should form part of the task description or attached policy/instructions, not separate tasks.
Leverage attachments – If it’s a long list of things that need checking, like an SoA checklist, then perhaps a one-page attachment would be better suited.
Leverage ‘Checklists’ – Some workflow managers have checklist functions, which are perfect when you need a specific acknowledgement from a user that they have done a particular thing. Subtasks can also work in this fashion, if not as cleanly.
Leverage ‘Comments’ – Where checklists aren’t available, you might consider one of the instructions being to confirm they’ve done it in the comments as an option. It’s quicker for the user and cleaner for the process than a separate task.
Leverage ‘Tags’ – For those tools that allow for tags or custom values, you could make them something to be amended before proceeding. QA – Incomplete to QA – Complete for example.

Know when to go deep, and when not to

Some things are linear and uniform, even if they can get complex. Some things are take years of experience to approach properly and each case is different.

Contacting a client for review can lead to many outcomes. They may answer a call and schedule first time, they may need chasing up, it may need escalating, they may not want one. It seems simple, but there are several possible outcomes. That said, the list is still finite, even if it’s not just a 1-2 step process once you drill down into it. Furthermore, this process is uniform. It’s the same decision tree for almost all situations.

Implementing an SoA has millions of possibilities. It may involve any number of strategies and multiple products may be involved, each with their own unique processes. At this point, trying to break apart this process is pointless, it requires human knowledge and understanding. As such, ‘Implement SoA’ is a common single task in the workflows I build.

Again, keeping efficiency paramount, you can go deep where you can add value with automation and detailed instructions. Otherwise, stay out of the users way and keep it high level.

Making it accessible

If a user doesn’t understand a thread, or doesn’t trust the technology, they won’t engage it properly. Every workflow should have clear stages.

Visualise with a process map

Firstly, this should be built with a process map. I recommend Lucidchart for this, but whatever tool floats your boat is fine. Every user should be able to see it and understand what the steps are, and what actions will trigger new actions.

Use numbering to maintain order

Secondly, to track the process, each task should start with a numbering system which provides information on where that task fits in the process.

This may be a simple as Step 1, Step 2, Step 3… however in the real world there are often sub-steps (or even sub-sub-steps (Inception, best movie of the 21st century, BTW.)

When a workflow might skip stages, go back a step, or vary from client to client, the simple 1, 2, 3 doesn’t cut it.

If we use a numbering system that works a little like software version numbers, the users (with a little time) start to get a hang on where anything is up to at a glance. For example: Anything within 3.x will be at SoA production, and anything at 5.x will be in implementation. By having up to three tiers of numbering, you can still keep things orderly even when complex.

I recommend using the below system:

The first number represents a major step in the process.
The second number represents a minor step in the process, which is a subset of the major step.
The third number (where required), represents a very minor step in the process which is a subset of a minor step.
Lettering represents a variation at the same step.

Doing it right takes a lot longer than doing it quickly and typically longer than you would expect. Unfortunately, workflows are often touted as ‘plug and play’ options, which rarely add efficiency to business needs at the coalface. However, the investment is worth it. When done well, the time saved in manual work and reduced risk of error is awesome.

We’d love to hear your thoughts on what makes an effective workflow or thread, or some mistakes you’ve seen that we all can learn from, all in the comments below.

Additional menu