Jacob Ukelson bring up some really interesting points in his new post on “Guidelines, Best Practices and Checklists – the Process Model for Unstructured Processes?“. He starts by referencing an old article in The New Yorker by Atul Gawande on some research he did on checklists, and is apparently in a new book “The checklist manifesto : how to get things right“.
Atul Gawande expounds the virtues of the lowly checklist, using examples of knowledge work, such as an intensive care unit where he says you “have to make sure that a hundred and seventy-eight daily tasks are done right”. What is the solution? The lowly checklist. He says “it’s far from obvious that something as simple as a checklist could be of much help in medical care”. Indeed, most eschew checklists precisely because they seem so low-tech. You have doctors, surgeons, and specialists who have received years, if not decades, of training on extremely sophisticated techniques. “Some physicians were offended by the suggestion that they needed checklists.”
In relation to process in general, Jacob suggests that a checklist might be the best way to model “complex, unstructured ad-hoc processes”. He has a good point. When a process is not predictable, as is the case with knowledge work in general, then putting a lot of work into an elaborate diagram is not worth while. Because the process is emergent, you have to model the process using something that people can read, add to, and manipulate readily while they are doing other things. With knowledge work, it is not the case that you have a dedicated business analyst to work and get the process model just right; instead the actual case worker needs to do it on the fly.
I have been researching a new book on Adaptive Case Management (a collaboration that includes Jacob by the way) and I am finding that many such case management products are favoring an approach that makes a process look a lot like a simple check list.
In 2001 I wrote an article for the workflow handbook titled “Workflow for the Information Worker” where I talk about the unique requirements that exist ona process that is not predictable in advance. In there was a proposal that processes are modeled to look like this:
The above process is manipulated directly: Clicking on the button next to an un-started activity starts it, clicking on one that is started completes it. The case owner can easily start multiple activities simultaneously if desired, or can mark steps as skipped.
The response from the process modeling community was similar to that of the surgeons above: “That is not a real process model. What if I want to ….” Those sentences were always completed with hypothetical situations that tended to ignore any consideration of cost/benefit trade-off of drawing the process. Sure, IF you want to ensure that three particular steps above are always executed in parallel, then this paradigm is not sufficient.
Remember that the point of BPM Solution Development is about finding the right process, and then creating a complete model that runs precisely the same way every time. But this only applies when the process is predictable in the first place. The extra effort to design the model with AND-gateways, and branch conditions, is paid back because the model will be executed many times, and this extra effort will be paid back.
But, with case management, where a process is modified and adapted to each individual situation, this extra effort is not justified. The people modifying this process are not trained experts in process, but instead are more worried about their job done. The case owner is responsible for process, and need the freedom to customize the process for the specific case. The fact is that for a one-off process, it is far easier to click next to each of three activities (starting them in parallel) than it is to draw an AND-split, arrows, and an AND join, and then execute that. This should not be surprising: there are many situations where if something needs to be done only once, it is easier to do it, than to write a program to do it.
As Jacob points out, the lowly checklist becomes a great way to communicate what needs to be done, what has been done, and keeps the model simple enough that people can add and remove activities easily without learning the details of BPMN. It smacks of “appropriate technology”, and I am really glad to learn of Atul Gawande’s exploration of this.
I’ve been a fan of checklists for many years.
You can even take a step beyond your model by including links on them that share where to find any detailed instructions, manuals, templates or boilerplate documents relevant to completing that action.
Similar links can also be added to capture copies of any natural outputs (eg reports, quotes, letters, test results, etc) from the action.
If you’re diligent about creating these links, the checklist becomes an excellent repository and tracking tool for what actually happened during each case without requiring any other redundant tracking notations.
Completely agree. Thanks.
Sorry, I have to disagree with you that “the point of BPM Solution Development is about finding the right process, and then creating a complete model that runs precisely the same way every time”.
I believe BPM Solution Development is about developing solutions for business processes, predictable or not predictable, dynamic or static.
The emphasis on “solution”, not on “process”.
I’ve just finished implementing a case management solution using a workflow that embeds a checklist.
A lovely simple workflow with three steps. The first step is a form with a checklist on it. The workflow loops back to the form with the checklist until all tasks are completed.
From the user’s perspective – all they see is a checklist.
From the company’s perspective – it’s a process with SLA checks, reminders and escalations.
Checklist, Tasklist, Grid – these are all GUI elements, not process elements.
Good points. Seems that you have used a checklist to create a ad-hoc process — that is, a set of three tasks which can be completed in any order. The ad-hoc pattern is a valid BPM pattern, and it was a mistake to say that the the activities had to be in a fixed order. What I really meant to say was that the process is defined completely in the sense that end users can not add new tasks, or remove tasks from the process as part of running the process. BPM usually allows very powerful ways to constrain the ordering of task, even having them in ad-hoc (unspecified) order.
It is interesting to know that you have found check-list to work well, even in a BPM case, and I agree that the checklist is a display option for a process, not a structural difference.
Thanks for the response Keith
I agree with the value of checklists, but see them most commonly required at a specific task in a structured process: there’s some structured process that looks like the usual process map, then at some of human-facing steps in the process, there’s a checklist. A situation where the process consists only of a single case management step would rarely be seen in my work, but rather processes that include both automation/integration steps, straight-through human-centric steps, and case management-style human-centric steps.
Agreed, you could implement that as a looping process as Adam suggests, although within an already-complex process map (something more complex than 3 steps is typical for my clients), the extra loops tend to be visually confusing if drawn explicitly.
The Model might be mightier than the Checklist, but a Checklist sure is better than nothing.
I think the “point” is that processes, whether highly structured or not, really need to be managed. We desperately need those “Auto-Managers” that keep track of what’s been done and what’s left to be done to become pervasive.
Without good management, things fall into cracks… Checklists may be “just enough” to keep that from happening.
Pingback: Column 2 : links for 2010-03-12
Great to see that these simple ideas are surfacing again, even in BPM. A great research paper called “Sharing to-do lists with a distributed task manager”, explored these concepts nearly 20 years ago.
Lists should not be limited to “checklists”. There are “action lists” from meetings, while “issue lists” and “bug lists” refer to tasks that need to be handled, without describing, or perhaps even knowing, how.
We should also keep in mind the semi-structured form that lies between the list and the graph/process, the hierarchy, e.g. work breakdown structures.
Once again, you inspired me Keith:
I found a copy of the research paper mentioned by Håvard Jørgensen called “Sharing to-do lists with a distributed task manager”, written by Thomas Kreifelts, Elke Hinrichs, Gerd Woetzel for the ECSCW ’93:
Click to access 03.pdf
I love these guys: “By putting the prototype to actual use we will further evaluate the tool and try to gradually add features that improve its usefulness as a coordination instrument.”
It was around that time I had a paper accepted on visualizing patterns of office work, and an aspect of that struck me as rather funny. So for my presentation I opened with: “In my research team we study ‘work’. And when we figure out what that is, we are going to do some of it!”
Pingback: Library clips :: Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management :: July :: 2010
Pingback: BPMN 2.0: no longer for Business Professionals | On Collaborative Planning
Pingback: BPMN vs. professionals, 2.0 | On Collaborative Planning
Pingback: The Checklist Manefesto | On Collaborative Planning
Pingback: Реализация бизнес-процессов при помощи чек-листов « Архитектура информационных систем
Pingback: Реализация бизнес-процессов при помощи чек-листов « Сетевые записки
Pingback: Social BPM and HIMS and Routine Clerical Work » Process for the Enterprise
Pingback: Реализация бизнес-процессов при помощи чек-листов « J3qx
Pingback: ИТАУ ... в поисках эффективности ... | Blog | Реализация бизнес-процессов при помощи чек-листов