Is the Checklist mightier than the Model?

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.