For knowledge workers, automating the business process so that the system can “tell them what to do” is the entirely wrong focus for IT system support. The focus of the system should instead be on presenting to knowledge workers the current status of the project, measured a couple of different ways. The distinction is subtle, but important.
“We need guidelines, not guardrails”
To be perfectly clear: this article is about knowledge workers. These are people who figure out what they have to do, and there are often very creative differences between how each case is handled. How can we design IT support that supports their work, and yet still leaves them free to be creative and innovative.
The answer lies in what all seasoned managers know: you give your best employees useful feedback on how well they are doing, but you don’t tell them what to do. One of the most famous management guide books, “The One minute Manager“, makes it clear that in order to engage and motivate your best talent, a good manager will give short, clear written statements about what results expected, and not a detailed itinerary of all the steps and how exactly to perform each step. Working out the details is part of the job of the knowledge worker.
You may find it odd that I am comparing an IT system to a manager. The IT system does not replace management in any sense. A good manager provides the right extra ingredients to make a knowledge worker successful, and there is every reason to believe that the IT system to support knowledge workers should be based on the same principles.
Does a knowledge worker need a detailed description of exactly what is to be done? Management wisdom clearly indicates that they do not. In fact, when a detailed list of the steps to be taken are provided to the work, we call this “micro-management” and it is universally considered a bad thing. A detailed process diagram showing exactly what needs to be done, is exactly the same thing as micro-managing. This sort of detail might be the right thing for assembly line workers, because the routine, repeatable aspect of that work makes it appropriate, but for creative, innovative knowledge workers is it not. Remember, it is that creativity and ability to handle unexpected situations that you pay the large salary for. You don’t want to defeat that by micro-managing them.
Instead of focusing on the finding, documenting, and presenting the steps to be performed, we would better spend our time on tracking meaningful status. Here are a few examples:
- Every year my companies goes through an employee review process, and each manager has a lot of things to do. Instead of indicating a process of precisely how to accomplish this, it is better to make a display that shows what has not been accomplished yet. I have a number of people who report to me, and I have done this for a number of years, what I need is a list of the people who I have NOT complete the write up on, or the list of people who have NOT had their assessment reviewed and approved.
- Similarly, we have an in-house training program and there are several courses a year. From the title, I can not always know if that is the course I already took or not. A display showing all the courses I have completed, along with all the courses I have not yet started, would be the right thing to allow me to coordinate my activities.
- A sales person does not need a fixed process saying “today you need to do Y for prospect X”. Instead, a display showing their total activity this quarter, their expected activity (quota), and the list of prospects and their latest status. This kind of dashboard allows a creative salesman to find the right next thing to do based on a lot of internal expertise that can not be coded into a process diagram.
- It is a well known practice in software development Agile method that you make a big status display board that shows the current work packets (cases) and what their status is. It does not tell the workers directly what exactly must be done. In fact, these details will be different for each work packet. Yet we can all agree that we want to get the work to the “done” status, and to do whatever it takes to get that done.
Maybe I am splitting hairs here: what is the difference between telling the status of a work instance, and telling what has to be done next? It is the difference between goal oriented, and task oriented. Goals imply tasks, and tasks imply goals.
The point I am trying to make is this: the person who creates a process map will determine an ordering for tasks to be done. That ordering is unnecessary for the knowledge worker, and can in some cases actually get in the way. Forget about the ordering of the tasks. Instead, focus on providing good status what what has and has not been done.
This is not that surprising. Many good systems are designed today along these lines. Consider a customer relationship management system (e.g. Salesforce). The focus is on providing a dashboard with all the customers/prospects and the status. Consider a typical management project review meeting: a list of what has and has not been accomplished. Consider a doctor’s patient status chart showing vital signs and recent treatments. Financial managers focus on financial market status indicators, and account status indicators.
I have experienced systems that violate this principle, and they simply tell you what you have to do next, without any context around it, and without any status of other things. These systems are frustrating and unhelpful. If you want the best from your knowledge workers, you will learn from management wisdom, and provide a status overview that the knowledge worker can use effectively to determine for this case what needs to be done. It is not only more motivating, it also supports creativity and innovation.
I am not trying to say that all concept of a process should be eliminated. Clearly we have an understanding that a sales prospect will be vetted at a basic level long before the deal is signed. I am simply saying that the focus should not be on specifying the exact process, because knowledge workers are by their nature already knowledgeable about this. Instead, the focus should be screens and displays that gather status information. Knowledge workers need to be informed about the status of things … often things outside their direct control. This is an area of great need, and an area that will yield results.
If you are starting by mapping out the process that a knowledge worker will perform, then you might be focusing on the wrong thing. Instead, start by finding what sources of information and status can be collected and presented in a dashboard. Leave the knowledge worker free to decide what the right thing to do it. That feedback information is the right thing to support, motivate, and get the best from knowledge workers.
Thinking Matters 
Is not defining the task/goal the same as saying what to do? Not how to do, for sure. But the task/goal is what the knowledge worker has to deliver, nothing else. It is what to do to me. Another matter that the knowledge worker should not be told what to use to reach the goal, what steps to go through (beside compliance) .
The monitor example is very appealing 🙂 – it was my personal experience – automated diagnosis of the ECG; many, many years ago.
There is a fine distinction between saying what you want to be done, and saying exactly how to do it. To specify exactly what you want in a coffee, you might find it easiest to explain precisely how to prepare it. These are deeply intertwined. Still, if you sit down to dinner at the restaurant of a famous chef, you wouldn’t dare detail how you want something prepared. It is a matter of respect, it is also a matter of wanting the best they can do. If you can say “just do the right thing” then you are more likely to get a satisfying result from an expert.
Hi Keith, great post.
We have proposed and delivered state/event driven processes since 2001 but only when we added BPMN (albeit in a case management context) in 2009 what we do was considered a process management functionality.
http://isismjpucher.wordpress.com/2009/03/21/stateevent-dynamics-of-facebook-and-twitter/
And yes, as I have said: ACM is not really about unstructured lists of tasks, but about defining goals and letting experts execute towards those as they see fit. I am not too happy with ‘tasks implying goals’, because goals need to be well-defined rules and not implicit.
http://isismjpucher.wordpress.com/2011/10/17/goal-orientation-in-process-management/
Thanks, Max
This is a great article about how process maps can be used to micromanage. However, I’d like to point out that process maps can aid knowledge workers in a way that doesn’t lead to micromanagement. In fact, let’s use the Claims Processing business process for a claims processor as an example.
For many Health Plan organizations, the Claims processing business process should be a relatively simple process. However, organizations tend to overcomplicate the process with unnecessary steps and an unreasonable number of sign-offs and approvals, thereby leading to micromanagement. As you mentioned, a detailed process map which includes every step can be seen as a micromanagement tool. Instead, if an organization were to use a template of the claims business process flow, it would lead to a process which encourages collaboration and allows employees to discover best practices unique to their organization.
Improved Claims processing can help to reduce the amount of low-value work done and lead to higher customer satisfaction. Modest initiatives, however, can still encounter stumbling blocks and almost no one provides effective resources for business process improvement for free. These resources can include end-to-end business value stream map templates, KPIs, best practices and other improvement opportunities.
Most health plan employees who want end-to-end business process flows will have to convince a C-level executive to hire an expensive consulting firm to come in and make business process maps of their processes, with no guarantee that any real improvements will be made. Since the data contained in the maps is so valuable, no consulting firm will make that data available for even the client to use if they tried to replicate the work themselves. However, for employees who can’t make executive level decisions, there are some resources available. This free online source provides health plan business process flow map templates, KPIs, best practices and other improvement opportunities: http://opsdog.com/improvement/health-plans/processmaps
Pingback: Adaptability as a Competitive Advantage | Collaborative Planning & Social Business
Hi Keith,
Undoubtedly there are cases where this is true however I have never really understood the contempt with which many thinkers in this space have for process maps. After many years of working in process led programs I have only once seen an attempt to ‘micromanage’ a business area using process. In this case the manager was replaced as it quickly became apparent this person was responsible for demotivating the knowledge workers not process maps as such. The exercise to map the process made this painfully clear.
Your opening assumption “For knowledge workers, automating the business process so that the system can “tell them what to do” is the entirely wrong focus for IT system support.” is part of the problem. In a majority of projects I have worked on automating the process was NOT the goal, although parts of the process may have ended up being automated down the line. No, the goal, in most cases was to understand an area of work that had become a black box to management. Stuff went in, things happened and stuff came out. When things went wrong it was hard to identify exactly what and why.
The process led analysis, that I’ve been involved in, was not designed to create a prescriptive set of low level sequential steps for workers to follow. It was actually designed to help workers understand how each other worked so that every individual could understand the context in which they worked. It facilitated collaboration between workers that had sat next to each other for years but never really understood what each other did. I certainly have never advocated capturing every task level detail. In my view this is an impossible task as knowledge works will do things differently depending on which approach works best for them.
We would, however, highlight things that Must be done, business control points for example. And we would make a point to capture goals constantly making the point that the goal was the most important item we captured and everything else was a guideline. When we did automate something it was only when the knowledge workers themselves agreed that it made sense to do so.
At this point my opinion about what happened to the process map differed to that of my employer and we have since parted ways. I now focus on the agile development process which exhibits many of the working practices described in these articles on ACM. Even here collaboration is facilitated by visualizing the work that needs to be done. Fortunately it’s purpose is recognized as a “promise of a conversation”, once that conversation has taken place workers are free to complete the work as they see fit. Artifacts such as process maps are consigned to the electronic filing cabinet only to be referenced when someone needs some additional context.