Death to workflow: long live the checklist!

05 Mar, 2008

Sequential steps thinking leads to systems that are relatively complex, frustrate users and are not robust in face of unforeseen circumstances. Adopt the goal-oriented, unordered checklist style, and save yourself and your users a world of hurt!

What went before…

Last year I found out how someone can get me angry using only Post-Its.

As the company grows in size (from 35 when I joined to close to 100 currently), we could not rely on information to automatically reach everyone through our personal communication with each other. The company had grown larger than our personal communication spans, and we started to see problems in coordination. “Weren’t you supposed to write that letter?”, “But I already…”, well, I guess you can imagine the kind of mix-ups that can occur. Because of this we wanted to “do something about it”. This something ended up as a pair of process consultants. We thought we would need to agree on and write down our processes, and that this would improve things.
“So what do you do first?”
“Well, first a customer requests a service with one of our salespeople”
Take Post-It, scribble, paste on wall.
“Okay, so what’s next?”
“Oh, but this request could come through our consultants as well!”
“Okay…”. New Post-It, scribble, paste on wall.
“Um, then the salesperson goes to… um…”. “Hey, but what about projects?”
And so on, and so forth. Never mind that the guy was a bad moderator, he kept influencing us with his own opinion, but I became seriously angry. We were already halfway along the wall with a bunch of convoluted paths of Post-Its, and the end was nowhere in sight. I asked him: “Where are we heading? Where is this all leading to? What are we trying to achieve? What is our end goal?”. He just didn’t get it, even after some discussion. In the end our management and the process consultants agreed that we were not “a good fit”. Not a good fit? Maybe, but I shudder to think how many companies these consultants by now have saddled with large, unwieldy, ineffective processes.
Rant aside, a number of experiences and ideas have led me to an insight on how to deal with the ways we should put “Process” into the equation when we’re organizing ourselves, and when we’re creating IT systems.

Death to unnecessary sequential ordering

I think that there is problem when working with use cases, workflow and other “first this, then that” tools and techniques, because you pin down all options into a limited path. Lots of software we produce is IMHO too restrictive: thou mayest only perform step 2 after performing step 1, and only after counting to three, no more, no less… With use cases and workflow we’ve become used to writing down human work as a set of sequential steps, and implementing it that way. But work hardly ever follows a precise flow. Many factors influence this: work style, external dependencies, unforeseen circumstances and delays all contribute to sabotage the One True Way.
Our normal response is to help the human worker get through the process as good as possible, but this leads to systems that take a lot of effort to implement, if they succeed at all. There are valid use cases for ordering restrictions, but in many cases it’s much better overall to have the people determine their own paths through the system (or process) and only worry about the main synchronization points. Is the software a tool of the user, or is the user a tool of the software…?
The problem is that the underlying assumption, following steps, is fundamentally flawed. We should use a different approach altogether.

Focus on end results, not the steps

Going back to my story of our internal processes, we used the “start with the end in mind” approach, we first defined our desired outcome and worked backwards from there: what is the direct preceding thing needed to achieve the end result? What is the direct preceding to that? What we ended up with were four steps, and for each step a checklist of exit conditions. This was a huge difference with the 30-steps-and-no-end-in-sight story we had before. (I recently found that I had reinvented Bruce Schneier’s Attack Trees)
At my current project we have a similar situation: the employees of a department needed support for their work, but there were many internal processes to follow. Looking at these processes I saw that they were similar in that they involved two overall steps: first collect all information, permissions and signed documents needed for a go/no-go decision, then make the decision, and on a “go” proceed to effect the necessary changes. I suggested that we change their thirty or so processes into a set of checklists, where the only sequential ordering was that a “decision” checklist was done before an “effect change” checklist. The future users were very enthusiastic: they got a system that supported them without forcing them into an arbitrary ordering of their work. The implementation shows a screen split in the middle, with the “decision” checklist on the left, and the “effect change” list on the right. This gives the users a nice overview of the situation of a single case they’re working on.

Checklist for the checklist style

– Define the end goal as a checklist of exit conditions
Good old requirements management techniques are very useful here to define what you really want to achieve.
– Create a to-do checklist of all actions that are needed as a direct predecessor to the exit conditions.
Avoid sequential dependencies, and even if they are there in reality, don’t design it into the system if it does not lead to problems in the system itself. A checklist of “proceed through door, open door” is sequentially ordered by physical laws: you normally can’t go through a closed door. But forcing an “open door, proceed through door” ordering leaves out the possibility that the door is already opened, and the “impossible” (assumptions…) case where someone actually succeeds in ramming through a closed door…
– For each checklist item, check if there are preconditions to allow that item to be executed.
These preconditions become the exit conditions for a new checklist.
– Avoid ordering the checklists as much as possible, preferably by combining them. Since “completing a checklist” has become the new granularity of a “process step”, the same rules apply as they do for the process steps that were changed into a checklist.


I have found that the goal-oriented, unordered checklist style brings some much needed sanity in the world of workflow, BPM and other process-oriented IT systems. In two cases I avoided having to implement a BPM tool like jBPM, a BPEL engine or a big and heavy one like IBM’s Process Server. If you’ve ever had to implement one of these “solutions” you’ll understand my relief at the hell I had narrowly escaped…
Users – and especially previous victims of automated processes – are invariably very enthusiastic about the checklist style. It allows much more freedom and robustness against unforeseen circumstances while still enforcing a good outcome.


Sequential steps thinking leads to systems that are relatively complex, frustrate users and are not robust in face of unforeseen circumstances. Adopt the goal-oriented, unordered checklist style, and save yourself and your users a world of hurt!

Newest Most Voted
Inline Feedbacks
View all comments
Computer Consulting Kit Blog

Organizing work you do for clients (and work you do as any part of your own business) is necessary in order to provide the best services and practice good time management skills. I work with small business computer consultants, and I know, as in any service-oriented industry especially, time is equal to money. Therefore, if you don’t have proper systems in place to help you manage your time, you’re often out of luck when it comes to seeing a good profit! Checklists are critical to making sure everything is taken care of and running smoothly, and that you are doing consistent work. Thanks for the helpful post!

Lars Vonk
14 years ago

\”If you\’ve ever had to implement one of these \”solutions\” you\’ll understand my relief at the hell I had narrowly escaped…\”
I totally understand you…. I have seen that hell from the inside.
Aside from hell, I really like this post. I am sure this will help me at my future work.

14 years ago

But waaaaait,
What’s workflow?
Your workflow is not my workflow!
Right now, Does there be a true workflow?

Gerard Janssen
Gerard Janssen
14 years ago

Interesting idea indeed. It does right to the world of knowledge workers who are perfectly capable of organizing their own work. I doubt, however whether this will scale to large organizations where employees need to cope with large numbers of cases “without-a-face”, where cases flow from one department to another. It all comes down to oversight, being able to comprehend all the things you are working on simultaneously.
Anyway, I like the concept and I sure applies to a lot of workprocesses I am involved in. Most of which are nog automated, transaction oriented. This sure is very easy to implement, both in organizations as well as in personal habits.

Tom Baeyens
14 years ago

The task list component in jBPM supports the checklist style of working. Even without a connection to a process or process instance. There is no out of the box UI to create and manage these tasks yet. But your post shows that it would be an interesting idea.
In the next version, we’ll be splitting it up into several subprojects so that you can use the task management jar separately. That should enhance the usability of using checklist style tasks not associated to processes significantly.

Explore related posts