Anatomy of a Turnaround - Part 4: Process

I'm writing these articles to explain the meat-and-potatoes of turning a plant around. Parts 1-3 are not negotiable. There is no other way.

You cannot coerce people into excellence. Great organizations are creative enterprises at every level. That requires you to earn the investment of a lot of people. 

Even if you get people to work with you by keeping them out of the error states and behaving well, you won't survive the complexity of the task without using a well-structured hierarchy. Your subordinate leaders will be critical, you must hold them accountable for leading. And you have to teach them to lead. They already want to lead, they're just waiting on you to structure it. 

Process, Process Adherence, and Maintenance. Parts 5 and 6 will be about process adherence and maintenance. This one is about process.

Process  

Every multiperson process is comprised of three components: tasks, decisions, and communications. Each of which should be detailed in a written chain that explains who does it and to what standard it must be done.

That includes "when" it must be done. Good communications, as part of a process, is defined as people being provided all necessary information before they need it. Only with a well run process will this be achieved.

Single-point lessons that describe how to perform a single task are a part of this, and those are good for outlining complex individual tasks where errors occur, but the single-point-lessons fail to address communication and decision process issues.

Communications and decisions are frequently where issues emerge for two reasons: 1) A lot of organizations treat them like they aren't process. 2) It's human nature to want to make decisions and communicate at the latest possible moment.

This is why process tasks, decisions, and communications must all be "standardized" such that they are completed the same way every time. 

And once standardized, they should be pushed to the lowest tier of the organization where they can be made.

Process Communications:

When you map a process, it's important that you get enough people in the room to actually understand what is being done and its deliverables.

When you evaluate process communications, you need to determine when they need to be completed (such that everyone has the right information before it's needed) as well as how structured it needs to be. 

If you only require single direction communication, a report with the information is fine. However, this doesn't allow for clarification of the task or response of how it turned out.

The ultimate structure of communication is typically to have 2 way communication when a task is initiated, tell them what you want, then they ask questions. Then 2 way communication after the task is completed, they tell you how it went, then you get to ask questions. This isn't required for everything, but this structure prevents inadequate or unclear communication from causing issues.

You get to decide how each communication should be conducted.

Process Decisions:

Process decisions typically drive process communications. This is because the information for making decisions needs to come from somewhere.

Often times, it needs to be communicated. For example, if there is a set of decisions that needs to be made at 7:00 am each day, perhaps you should require the reports with the necessary information to be provided by 6:30 am so that the information is timely and current.

The other important thing that is wrapped into this is that decisions of this nature should be made at the lowest tier of the organization possible. The closer a person is to the work being performed the better/faster the decisions will be made.

Also, the less information that travels through a single member of the team, the more reliably that person will be able to handle repetitive communications and decisions on a daily basis without errors or omissions. Therefore, communications and decisions that can be made in a standardized fashion on the floor, while still needing to be documented, are frequently better made by technical level players.

Process Tasks:

Creating guides on how to execute tasks is what most people immediately envision when we say process. This is part of it, but only part of it.

Example:

Suppose you wanted to evaluate and standardize the process of making a sandwich for a kid.

Here is a simple initial process that perhaps we use:

Kid says he is hungry > Ask the kid what kind of sandwich he wants > Evaluate whether we have the stuff the kid wants > If we do, make sandwich. If we don't, offer options available, then make sandwich > Give kid sandwich > Clean up and put things away

Next, we have to "walk the dog" through this process to identify every task, decision, and communication that is needed. We should also evaluate this task for sustainability and efficient order (redundant work, keeping stock of items needed, etc.).

From a process simplification standpoint, it likely makes sense to rework this process to eliminate the redundant and disappointing step of letting the kid request a sandwich which you may not have stuff to support. Therefore, let's change the process to where we inventory sandwich items before we take the order.

Here is an updated process which may be more efficient and sustainable:

Kid says he is hungry > Check sandwich makings for options > Offer the kid sandwich choices > Accept sandwich order > Make sandwich > Give kid sandwich > Clean up >Add used items to shopping list. 

Now I have eliminated an unnecessary negotiation and added a task to make sure I replenish used materials. 

Next, I want to detail all of the communications and tasks/decisions required and assign them to the appropriate parties. I will number these in the order of execution which is typically the correct prioritization order for owning parties.

Communications: After drawing these out, you will typically see that some of these should be grouped together in different ways: reports, meetings, etc. If you group together the ones that make sense to put together, this will produce a technically correct agenda for a meeting or necessary report components.

2) Kid -Communicate request for sandwich 

6) Kid - Communicate which option he wants for sandwich 

4) Parent - Communication sandwich options to kid

Tasks/Decisions

1) Kid - Get hungry (Evaluation afterwards: Is this the best way to initiate feeding the kid? To what standard?)

5) Kid - Decide what sandwich he wants from options (Evaluation afterwards: Is this the best way to determine which sandwich the kid gets?)

3) Parent - Inventory Sandwich Options (Evaluation afterwards: Is the current stock the right stock? Am I happy with the options the kid has?)

7) Parent - Make sandwich (Evaluation afterwards: What standards matter? What finished product to I want to deliver?)

8) Parent - Deliver Sandwich (Evaluation afterwards: What standards matter? How should it be delivered?)

9) Parent - Clean up work space and put away components (Evaluation afterwards: What standards matter? How should the workspace be cleaned. How should it be left?)

10) Parent - Add items below "min quantity" to shopping list. (Evaluation afterwards: What standards matter? How much is the minimum? How is the list used? How should it be written and where?)

Ok, so after walking the dog on this, any group of people is going to clearly see the holes in this process. Someone in the room will ask who cleans up the kid's eating space. Someone will point out that the parent could take an inventory at the start of the day instead of doing it with each sandwich request, and so forth.

The point is that once you break a task into decisions, communications, and tasks you can start assigning standards to them. 

In this simpler format where you are just evaluating the components you will clearly see the holes in your process.

Perhaps we decide that we want to serve food at a given time instead of waiting for the kid to get hungry. Maybe we decide to reduce waste by serving the same thing all the time. Maybe we decide we want to feed healthy choices and that changes the process.

I typically do this process with the team who owns a process. First, I get them to agree on what the process is in the format of our first process. I write it across the top of the white board. Once we all agree on what should happen (design is aspirational, if we can't agree on what happens we should opt for what we think should happen), we can go forward.

Then, I try to "walk the dog" where I assign every communication to the owning party on one side of a white board and every task/decision to the owning party on the other side.

When we are done, we try to combine communication tasks into meetings/reports/etc and we identify standards for every task/communication/standard.

Which is, effectively, how you develop standard work.

As you approach process evaluations like this, never forget Gall's law. You cannot add 10 steps to a process in one sitting. Don't try.

Gall's Law - A complex system that works evolved from a simple system that works.

You can iterate your process once you get it working, but you have to get it functioning consistently first. Then make one change at a time.