Exactly one year ago, Fred Cummins published a blog post called “A Knowledge Worker Cockpit” which remains today one of the best descriptions of the kind of information system that an active knowledge worker needs to keep on top of unpredictable processes. Over the year I have started a couple of time to critique the article, and finally here it is. There is a lot to agree with, but a few things I would suggest differently.
Overall it is an excellent vision of what a knowledge worker needs and might use. If you haven’t already, link over there and read it now. It is not (in my admittedly opinionated eyes) completely perfect, and I will spend the bulk of this post criticizing some niggling aspects in detail. You should not, however, conclude that his original proposal is riddled with problems.
After defining terms, there is a description of a case folder and the kinds of things you would find there. Earlier posts had focused on modeling, which might be appropriate for Production Case Management (PCM) but not for Adaptive Case Management (ACM). This post is on planning while you work, something that knowledge workers are forced to do because the process can not be precisely predicted ahead of time — something he calls “Interactive Case Management“. He makes it clear that this is broader in scope than the OMG’s Case Management Modeling Notation (CMMN).
He lists capabilities needed:
- Planning and Decision Making Support
- Support of Collaboration with Others
- Management of Participation
- Participant Personal Support
- Information Access
I like the specific mention of “planning” as a primary activity of the knowledge worker. It is not called “modeling” as so often BPM discussion do, and for a good reason: the knowledge workers do not see themselves as modeling their work, but rather they are doing their work which happens to be planning. That is an important point of view.
I like the depiction as a “cockpit” which symbolizes a central place where all the control are available, and does not symbolize the automation. The pilot is still the pilot and makes the decisions and in this way you leverage the knowledge and expertise of the knowledge worker.
I like the focus on the how the case manager sees it, and not on how the developer sees it. Instead of being described as a “system” which supports many case managers, it is a cockpit for an individual case. This viewpoint is important, because different case managers are going to using different systems for different kinds of work, and thinking that an organization will get a single “system” for all the knowledge workers will end up frustrating many workers. The cockpit is an individual space tuned to a particular kind of work.
While you read about the cockpit, there is one thing you need to keep in mind: knowledge workers (case managers) are in a hurry. They are busy. They just want to get the job done as quickly and effectively as possible. They often already work long hours. When they are in the middle of an important case, they are not thinking about other cases that might benefit by a change in plan. If they see the need to get something done, even something they have never done before, they want primarily to get that done.
A doctor designing a treatment plan for a patient does not want to address the added complication of how future patients might use a variant of this plan. They don’t have to time to sit and write a conditional expression that determines whether this activity is needed or not in future cases. Any time they spend worrying about future cases is taking time away from their current, urgent case. If adding an activity to a case plan takes more trouble than a phone call (& follow-up) to ask someone to get something done, then the case manager will opt for the phone call instead.
This single design consideration is probably the most important factor in determining what a knowledge worker cockpit needs to do. It puts an extreme limit on how much trouble you can expect a case manager to take.
Some of these are quite subtle, but I will start with the more obvious.
Support for Innovation
It seem that the knowledge worker is still a second rate citizen when it comes to planning. The descriptions are that there are “palettes” of types of activities available, and the presumption is that there will be so many that they will need filtering. I don’t see a mention of making a task from scratch.
For example, Jeanette, who is responsible the launch of a large budget movie, hears that Apple has announced the new “iShades” which are wearable iOS devices, and determines that new version of the promotional game will need to be created to fit this new format. The case manager want to create a task and assign it to someone. There won’t be a “Create iShades App” task in the palette. How does one get one? Does Jeanette have to call in a programmer? Let’s assume that the cockpit has a way to create a new type of activity at any time.
Validation of Task Placement
This is further supported by the idea that the system will validate whether the activity is appropriate or not for the context. Great idea, but consider the implications. There must be a large set of rules that can tell when an activity is valid. Who enters these rules? Who tests them? Consider again the above example, when a knowledge worker constructs the “Create iShades App” activity, how does the knowledge worker specify the contexts for which this activity is valid? More important, why would a knowledge worker bother? The knowledge worker knows that it is valid for this particular case — based on their expertise and knowledge of the world. It would be a much greater amount of work to determine all the possible situations that you might need the task. We are seeing an attempt to automate the judgement of what activity to do — but that is the job of the knowledge worker. Presuming to know precisely what situations you are going to need this activity, means that you are not really addressing unpredictable processes in the first place.
Validation of activities is a kind of Holy Grail: conceptually it would be a great way to make life easier for the case manager. We can think of a few trivial cases that work well: wouldn’t it be great if the system could tell the doctor when he was prescribing too much medication. But knowledge workers, by their very nature, are not doing trivial, predictable tasks! It would be impossible to make such a rule base for unpredictable tasks, and in any case it is a lot of effort with very little value. It is simpler, and much more cost effective, to simply let the knowledge workers decide what they want to do when.
This does not mean that the case manager is completely without guidance. Fred also mentions the idea of mining the history to find out the sort of activities that are typical according to what has gone before. These are suggestions, and not validations.
Role of the Case Manager
My final criticism is much harder to pin down, so please bear with me. The tone of the entire piece is one that the knowledge worker is a user, and there are designers elsewhere who “set up” the system. You see this in the knowledge worker “picking” the activity from a list, but no mention of creating from scratch. You see this in the description of things that are going to be done “automatically” for the konwledge worker, but no description of how the knowledge worker sets up this automation. The knowledge worker will need to contact the IT department in order to get any change to the system. The article does not say this exactly, but it is strongly implied in many places.
Perhaps this is just an oversight that was accidentally left out of the article, but you will notice a tendency to see the knowledge worker not as an innovator of tasks, but instead as an operator who plugs things together that were provided by someone else. Who is that someone else? In an adaptive system, there should be no distinction between design time and run time: all options should be available all the time.
Notice that it describes a separate facility to create plans. I have found that even just making someone go into a separate mode from working, is enough to prevent use. Remember what I said above about knowledge workers being in a hurry and just wanting to get the current job done. Going to a separate mode to make a plan when all you really want to do is ask “Joe to do X”, is a barrier.
The knowledge worker needs an integrated cockpit where planning is not separate from working, where planning is an integral part of completing daily work, not a separate mode.
Essentially it is the right idea, but it needs to emphasize the knowledge worker as the primary innovator with ability to most things without any IT support, and to de-emphasize the role of “automated” tasks and “validation” which take coding that the knowledge worker is not likely to do.