A Busy PM’s Guide to Workflow Management Systems
So…
Why yet another workflow management guide?
Every now and then I hear from fellow PMs, department managers, and other IT people something like:
This post explains why traditional project management tools we all know and like — Asana, Wrike, JIRA, Trello… Monday… May not be the best option when you need to manage tasks related to repeatable processes in your department. Things like “starting and setting up a new project”, “requesting a vacation”, “onboarding new partner”.
And especially all these custom core processes you may have in your team or a company: “processing loan application”, “reviewing partner’s submission of a plugin”, “preparing a new online course”.
In general, all these things where you want your team to follow a predefined list of steps every time you execute a new process.
You may think that in a tool like Asana you can easily create a template of a project, put in all tasks that need to be done for, e.g. onboarding a new employee, and use it every time.
Unfortunately, this doesn’t work well even for trivial workflows.
Some features essential to Workflow Management apps are just missing in most Project Management apps. I will talk about this a bit later, but before that, you need to understand important difference between state machines and flowchart diagrams.
State Machines VS Flowchart Diagrams
Both the flowchart diagram and a state machine diagram can be used to describe workflows.
Many people with extensive experience in project management are familiar with a state machine approach.
Apps like JIRA, Asana, or Wrike usually support a notion of “state” for individual work items — bugs, stories, or tasks.
For example in JIRA you may have following states for any issue:
- Open
- In Progress
- Resolved
- Closed
- Reopened
In addition to states, you can define transitions — how these states are allowed to be changed. For example, if the issue is “Closed” it can be transitioned to “Reopened” but not to “In Progress”.
These states along with transitions are commonly referred to as a “workflow”. Workflow defined with a set of states can be shown as a Kanban board. Every column on board usually represents a single state or multiple states.
A diagram shown above can be shown as a Kanban board with three columns:
- Open (Open)
- In Progress (In Progress, Reopened)
- Done (Resolved, Closed)
But just having a board is not enough, as you see we also need to somehow define rules on how cards are allowed to be moved between columns.
This types of workflows are really good to describe continuous processes where a state of every work item is more important than exact steps process participants must take to take work item from state A to state B.
For example, in software engineering, every issue is unique and it's just not possible to know exact steps to follow as a part of a workflow. Moreover, any given issue may move between states many times — for example, a completed issue may be reopened and put back to work.
On the contrary, the very idea of business process management is to make common processes more predictable by reusing the same steps over and over.
For example, an Onboarding Process for new employees will always include steps to introduce a new person to a team, create new company accounts, set up a laptop, etc.
By using the same steps every time when we need to hire a new employee, we making onboarding experience smooth, enjoyable and predictable for both employer and a new employee.
Focus on repeating the same steps and following the same rules is why state charts are not commonly used for business processes. Even an industry-standard BPMN notation for describing business processes is basically a flowchart diagram.
You can express some common workflow patterns on a flowchart, you cannot describe with a statechart. On the example below a flowchart diagram shows a set of activities which performed in parallel, at the same time.
In project management tools card represents the whole process, e.g. if it's a Customers Onboarding board — each card represents a Customer.
Since you cannot have the same card in multiple columns — it is very hard to support even trivial workflow patterns on the Kanban board.
The problem with accountability
In most business processes it is natural that different steps of a workflow are assigned to different departments.
The problem is that it is hard to tell who exactly will work on a task in advance. You may have 10 people in HR and 5 people in IT teams and you will end up with manually assigning tasks to people every time you start a new process.
While this may actually work out for a very small team, where every person is a department, it will not work for bigger teams where more than one person can work on tasks of the same kind. For example, “Create a new email account” task could be done by any available member of the “IT Support” team.
The problem with due dates
As you would imagine, setting due dates in advance is also tricky. This is why in project management you probably used to get away without having a due date set for every task. In Projects management, we used to work with estimates. This makes sense when all tasks are unique for every new project.
In operations, however, you will work with repeating processes with exactly the same tasks performed every time. This is why you will want to set SLAs for all steps of a process. Especially for customer-facing processes, like an order processing.
Now, even if you put due dates in a project template — all dates will change next time you need to create a new project. The only option is manually set all due dates every time.
The problem with data
If you have two cards for two customers going through the onboarding process — what makes these cards different? It’s the data associated with each card:
- Customer’s company name
- Contacts
- Address
- Phone number
- Requested services
- Assigned account manager
There could be a lot of data inside every running process. As a part of working on a process, employees will be providing some information and expect some information to be provided to them.
This is called a “value chain”:
It gets even more complicated when the process is going through multiple departments, e.g. from “HR” to “Accounting” and then to “IT”. And some information is sensitive and you do not want to share it with all participants — like “Contract amount” or “Salary”.
These problems are not solvable in existing Project management tools.
Meet workflow management apps
Unlike project management tools, workflow management tools are built almost exclusively with flowchart approach (sometimes it is internal and you can’t see it on the user interface).
This makes it easy to describe common workflows with requests and approvals, reviews, parallel branches, optional steps, etc.
Workflow apps support assigning tasks to a group, using work queues, dynamic assignments and more.
In most Workflow apps you can set due dates as relative dates, solving the issue described above.
Workflow apps are great at working with processes related data, you can create complex forms with a rich set of field types to capture any information. You can also add tables to create forms like “Invoice items”.
Check out my other post to learn about all the features provided by workflow management apps:
If you would like to learn about some workflow apps in much more details, check out these very in-depth reviews:
