Critical Mistake Made by Process Creators

When creating a process, it often happens that there is a confusion and mismanagement of operations and end goals. Goals can be lost and the organization might be left with only a mess of processes and procedures. In this post, I will state why this happens and how it can be fixed.

A process itself is not hard to understand. It can be defined simply as a sequence of actions. However, when a process is created, these actions can be mixed up with a lot of words that do not clearly define what needs to be done. We can begin to see why this happens by defining what actions themselves are.

There are two ways to define an action: as an action-state or as an action-operation (or act). In the first case, an action-state is defined as a goal--a desired state in the future which is planned to be achieved by doing something. The focus here is on that desired future state. In the second case, an action-operation is defined as a process to complete an action. It focuses on how to do something.

I’ll try to explain this with a simple example. Imagine an action-state defined as “move one meter ahead.” As we can see, the focus here is on the future state: the expected position of a person will be moved one meter off of his or her current position. The related action-operation may sound something like “step forward.” These two directions look identical to most people. However, the focus in the second case is on the execution of the particular operation--how to move one meter ahead.

In that simple example the difference between the two terms is almost unnoticeable. One step almost always results in moving 1 meter forward. We understand this so well that if we need somebody to move one meter ahead, we almost always tell them: “step forward” instead of “move one meter ahead.” We use the action-operation instead of the action-state. In this and other ways, in our everyday experience we are accustomed to substituting one concept with another--some elementary goal is substituted with an elementary operation that will lead to the goal. We are so used to doing that we often extend that approach to more complex cases. And it is here that we get into trouble. We sometimes mix up processes with their end goals.

Let’s look at another more complex example:

An officer and a soldier are sitting in a trench before a constantly moving enemy. 

  

The officer commands the soldier, “Shoot!”

The soldier asks, “Where should I shoot?”

The officer clarifies, “Shoot ahead!”

Meanwhile the enemy is moving...

Shot - Bang! - missed...

The officer says, “What are you doing? Aim left!”

The enemy keeps moving...

Shot - Bang! - missed...

The officer roars, “#$#$%!! Aim right!”

……...Miss.

The military realized the issue with this example a long time ago. For a while, NATO has had a standard formula to issue commands. It is called “5W,” which stands for “Who,” “What,” “Where,” “When,” and “Why.” Any trained officer in a similar situation to the one above would command a soldier like this: “Private Smith, upon my command hit the moving enemy target ahead 100 meters.” As we can see here, the command is formulated as a goal and not as an operation like the orders in the example above. The execution of such a command will lead to the desired result much faster and more effectively.

Now that we see the problem with using action-operations instead of action-states, let’s go back to processes.

Unfortunately, there are no clear directions on how to define actions in a process. Everyone has the freedom to do it anyway they like. Because of that, many process creators fall into a habit which leads to problems:

1. They make assumptions regarding the initial state of the process (which could be far in the future and not well known)
2. They make assumptions using non-changing goals (but goals sometimes change)
3. They make assumptions that the planned operation (or operations) will produce the expected results and transform the assumed initial state into the desired state.

They say “step forward” when they should really say “move one meter ahead.” Because they assume that everyone is 6 feet tall (an initial state), they think that their goal of moving one meter ahead will be accomplished with a single step (that the operation with the assumed initial state will reach the desired state).

All of that leads to a critical mistake - a substitution of a goal with an operation, a replacement of “what” with “how.”  When this happens, goals (“what”) disappear, and only a meaningless sequence of operations (“how”) remains. That sequence may lead to the desired results, but it does not happen often--and usually only happens with a large amount of luck.

Surely, everyone of us has met such things in our life. There is a lot of meaningless movement and a lot of sweat, time and resources are spent, everything is done by the book, but the results are minimal. This is because the goals have been lost! Workers have been told to “shoot” without being given a clear order or goal/action-state. Of course, process creators see this problem. Some of them even try to address it by creating more processes to anticipate all possible problems and cases, introducing alternative flows, and so on. But is it possible to predict everything that may happen? And is it really necessary? Would it be easier just to say what is required, and then leave how up to a qualified executor, who will assess the situation and apply operations that will lead directly to the desired results?

If a pattern or process exists that works well, then perfect--keep using it! Explicit goals will add more sense to it. But if a process does not exist, or if it’s not optimal, then goals will clearly point the direction to go and will help to define a new and better sequence of actions which are suitable to the current situation.