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.
Effects
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.Summary
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!