Business communications problems I often see that undermine operational excellence initiatives and how I resolve them

This post has already been read 1421 times!
0 Flares Twitter 0 Facebook 0 0 Flares ×

Communication problems exist in all companies, but the effects are worse if the company is failing to meet basic operational targets. Three of the most common causes of these problems are:

  • Lack of clarity.
  • Lack of understanding about the underlying assumptions.
  • Lack of meaningful results.

These problems can lead to conflict between parts of the organization. Conflict creates chaos and leads to team members disengaging, which results in both a reduction of commitment and a decrease in the sense of urgency that comes with OpEx implementations. If an OpEx session fails, the lack of results causes team members to communicate apathy towards the process, which also undermines the initiative.

To mitigate these problems, it’s critical that the OpEx process can communicate the following:

  • The company’s goals?
  • How our OpEx Initiatives move us towards the goal?
  • Where this OpEx session fits into the initiatives?
  • How what we do is connected to the objective?
  • How will we be measured and evaluated?

You will find that team members are looking to connect the logic of what they do with the goal of the company. Will sitting through this session lead to anything worthwhile? Will this OpEx Initiative really make a difference to the company? How will it do that? The assumptions around these basic concepts must be clearly communicated at the beginning of the OpEx process or you run the risk of unwanted results that may be unresolvable. Additionally, we want to avoid having the OpEx process itself create and then reinforce these undesired effects.

In “Addicted to Hopium,” I outline the Dependency Variation Analysis Business Process. The major phases are shown in the chart below. The two highlighted phases are where clarity around early communications play a major role.

Integrating Operational Excellence requires effectively communicating the clarity of leadership’s goal, and the logic of how the initiatives will move the organization towards that goalGoal setting

The most difficult part of the OpEx process can be to get agreement from leadership on the goal of the company. There are often lengthy Mission Statements or vague declarations that are used to define the goal. When I worked at GM, the goal was to “Make great cars and trucks.” Making money, it turns out, is a requirement for both a ‘for profit’ company and a non-profit organization. The non-profit just has to make ‘enough’ money. Whatever the goal, we must be able to tie it into the OpEx Initiative.

Set the objective of the OpEx initiative

Initiatives are the strategies that will be used to move the organization towards its goal. It could be something like improve throughput to meet demand, increase the on-time performance of projects, or optimize inventory levels to prevent stock-outs. They tie into the goal but are not as detailed as the tactics that will be part of the OpEx Session.


Set the objective of the OpEx session

Now the session must tie into the OpEx initiative. If increasing profits is the goal, and increasing throughput to meet demand is the initiative, then the focus of the session may be to improve the performance of a bottleneck. Note the objective is now an actionable tactic.


This is a great point to check clarity. Ask the team members in the session, especially those who appear to be disengaged, to repeat back these elements, in reverse order. What’s the objective of this session? How does it tie into our OpEx initiative? How does that connect to the company’s goal? Challenge the group to find fault with the logic. Once that is clear, ask them why they are in the room, this will challenge them to think about their place in the process. Can they do anything-anything at all – to help with the tactic, even if is nothing more than getting coffee?

A lack of meaningful results

How is what I do connect to the objective?

This is where many OpEx sessions come off the rails, primarily due to poor assumptions.

A lack of meaningful results


The OpEx process may assume that the teams or the team members can operate independently to reach the objective of this session. They look at the teams or team members in this fashion:

The assumption is that if everyone comes up with an idea and puts it on a to-do list, it will get done, and things will improve. All of the ideas have equal weight, and someone will do them at some point. The real question that the group will ask is – is this a meaningful result? Will adding more things to the to-do list really make a difference, or will it actually have a negative impact on the organization? Asking someone to find a problem, develop a solution, and then never actually implementing that solution is disheartening, and when people go through this, they tend to come away with a poor view of their OpEx experience.  Communication of these poor results to others will undermine efforts to improve the organization.

bigger to do list


As it turns out, most of the employees walking into our session already have this paradigm, and we have to overcome this. They have no expectation of meaningful results, and the main reason they are in this session is that they have been told to be there. Our OpEx process must generate meaningful results quickly, and continue to generate them over time. How will that occur?

Answering that question is why I wrote “Addicted to Hopium” and formulated the Dependency Variation Analysis (DVA) Business Process. DVA is a combination of the Theory of Constraints, the design of habits, and methods to create motivation. The DVA process does not look at improving each link in the chain but instead, focuses on improving the weakest link. We can’t keep coming up with long lists of potential solutions that never get done. Instead, we must implement one or two powerful solutions that will improve the output of the entire system, quickly. We must not hope things will get better but logically conclude through analysis that there will be an improvement.

system dependency


How will I be measured and evaluated?

Unfortunately, the people that attend our session fit into an org chart, while at the same time they might be part of a system. Org chart pyramids are how chain-like systems are managed. Communications must go up and down this org chart, which will generate additional barriers between the links of the chain. OpEx measures are usually given to the managers in the org chart. Unfortunately, they may not be in a position to determine how well you did in an OpEx session. In this case, a team member may only be measured by something very simple, like attendance.

Worse, the objectives of the left side of the organization may not be in-line with objectives from the right side of the organization, which causes conflict. The managers on the left may measure attendance, while those on the right are looking at the sum of cost-cutting proposals. Team members from the right will obviously recommend cost reductions that should be done on the left side of the organization. Management from the left will point out to their leadership that all of their people have completed training by the end of the second quarter, far ahead of the team from the right – slackers.

How will I be measured and evaluated


In the DVA OpEx method, team members from different parts of the organization are invited to be part of the session. Their different viewpoints often bring different solutions to the problems being faced in the session. They are told at the beginning of the process that they will be evaluated on their results and then will also be evaluating each other. Helping each other is part of the evaluation criteria.


An example

Original session objective:

Develop a list of problems to solve using the DMAIC process.

We may be able to tie it into the:

OpEx initiative: Become proficient at problem-solving (quickly identifying the root cause).

Company goal: To increase profitability.

The OpEx team may have to read through the logic a few times to tighten it up for the session. This is what I came up with for the new session objective. It’s longer but does a better job of tying everything together.

Modified session objective:

Develop a list of problems that are preventing us from increasing our profitability using the DMAIC process.

Not bad, but if we used the DVA business process, we would focus our resources on the bottleneck to increasing profitability. We would have to take a system approach, find the bottleneck, come up with solutions using DMAIC, and then implement the solution that we believe will generate the most meaningful results. So, our DVA version of the session objective now looks like:

Final session objective: Implement the DMAIC problem solution on the bottleneck that creates the largest increase in jobs per day.


Final session objective


We have used the DVA Process in this example, which usually leads us to the metric. In this case, it’s throughput, which we measure in jobs per day. We would also ask for team evaluations, which can be handled in many ways but are important feedback for team-oriented OpEx Initiatives.

In the end, the success of our OpEx initiatives will have to first rely on the clarity of leadership’s goal, and the logic of how the initiatives will move the organization towards that goal. The communication of the initiatives to team members must clearly demonstrate those links, or conflict will begin to emerge. The OpEx team must uncover faulty paradigms and make sure false assumptions are brought to the surface, challenged, and resolved. Finally, there is no better way to avoid negative communication than to achieve quick, meaningful results. This will create positive communications that will lead to sustainable DVA routines, on-going improvement, and establish a company culture that will always strive for excellence.


Additional Reading

A Key Building Block for Successfully Implementing Lean/World-Class Value Stream Management: Communications 

Implementing Lean World Class Manufacturing Means Major Changes – Recipe for Success (or Failure)

Lean Six Sigma and Supply Chain Management – the Time Has Come to Converge


If you liked this article, we'll be happy to send you one email a month to let you know the newest edition of the MetaOps/MetaExperts MegEzine has been published. Just fill the form below.