Tactics Vs Strategy in Business Processes

I find it almost amusing that many business leaders struggle to understand the difference between strategy and tactics. One situation that illustrates this that you have likely experienced follows.

I once attended a two day conference for a division of my company that was called a “strategic summit.” On the first day we reviewed what our organization had accomplished (in some cases taking credit for success where credit was not necessarily due) and reviewed some of the new technologies we had implemented in order to improve our ability to measure our success. The second day consisted of a few additional such presentations and then we all attended the plenary session which was hosted by the director of the organization.

The director took the podium and presented the metric targets that our organization would be responsible to meet the following year. He then stepped down from the podium, asked that one of the attendees close the door to the conference room, and said, “None of us are leaving here today until we decide how we’re going to achieve these targets…” I almost laughed aloud.

The (rather weak and half hearted) discussion that followed started with very narrow suggestions on how we should change some of our processes. Then the “discussion” degraded into a debate as to which changes would be most likely to ensure we would meet our targets. Since I was feeling particularly punchy this day, I asked the director whether we intended to conduct any sort of analysis to determine whether the changes we implemented were actually responsible for the increases or decreases in the key metrics. He responded that we would not. No analysis. No data. Almost no logic. Today or in the future.

Wow.

Fortunately, in light of the necessity to maintain professional propriety, I laughed in my head and then started to wonder about the technical definition of “strategy.” I wondered because what we were doing did not seem particularly strategic. Lame management style aside, this conversation did not seem productive and may have even served to create more chaos.

While wondering, the following came to mind: I considered a chess game. When a decent chess player plays a game, they will typically use a strategy which includes an overall goal and a set of principles for reaching those goals. The principles, however, are not cookbook types of moves. They are principles–higher order rules for how to outwit the opponent.

The player then translates those principles into actual moves on the gameboard–these are tactics. Tactics are meant to accomplish a near-term aim. Tactics are specific in nature (e.g., move the knight from A3 to C4). Several different tactical moves may stem from a single strategic principle.

Thus, the plenary session was not really a strategic planning session at all. The strategy had already been set–fortunately, given the incompetence of this particular leader, the strategy had already been set by higher level leaders. What we were really enduring was a tactical planning session. A poorly managed one, but a tactical planning session nonetheless.

Why is it important to make the distinction between strategy and tactics? One of the main reasons is that overall business management is far more likely to succeed when a leader first sets a strategy and then develops or refines their tactics to implement that strategy.

Keep the two clear in your mind so that you do not make a fool of yourself as did this organization leader.

The Power of Process Mapping

One of the challenges I often face is that of explaining the current state of our processes to leaders at my company. Sometimes my goal is to convince them that the current process is “in statistical control” and the seeming irregularities they saw last week were not anything that they need to worry about. Other times, they do not seem to think that some processes are problematic and my goal is to convince them that the same processes are out of control, or trending in the wrong direction.

The causes of these issues usually occur in sub-processes that the leaders do not regularly monitor. Who can blame them? They have far too many metrics to watch as it is. In truth, many of these processes go unmonitored or are completely misunderstood by most employees.

For example, our technical support group uses a knowledge management tool to help them track and resolve customers’ technical issues. The business has spent tremendous effort attempting to prove that this tool either helps or hurts the satisfaction of our customers. The test is usually constructed as follows:

- Collect data on the extent to which each representative uses the knowledge management tool
- Collect data on the extent to which customers handled by each representative are satisfied
- Run a regression analysis using knowledge management tool usage as a predictor of customer satisfaction

Obviously, there are a number of issues with this simplistic analysis. After watching the business run through several iterations of analyses similar to this, it occurred to me that one of the factors ignored, among many others, was the diagnostic questions that the agents used to decide which search terms to put into the knowledge management tool to find the appropriate content.

The focus of the operations group (who do not particularly like the tool) has generally been on the quality of the content. They essentially point their fingers at the content management group and blame them for the poor performance of the tool. On the other hand, the content management group point thier fingers at the operations group as the problem, noting that because the agents do not provide feedback on content that needs improvement, the content does not improve.

When my teammates and I mapped out the technical support process at a high level, it quickly became evident that a major part of the process has been ignored. It occurred to us that the company does not have any measurement systems that assess the quality of the diagnosis performed by the agents. So now we have ourselves a little project to conduct. This may not necessarily be a full fledged Six Sigma project. At the very least, we have an assignment to create a new measurement system that assesses the quality of diagnosis performed by agents. Interestingly, this may require a new knowledge management tool. It is a daunting task but if we are to make progress, we must assess where we stand.

The bottom line: Process mapping will often quickly help you identify areas where your business does not have information that tells them which parts of a process to improve. Once you have this information, it is often clear where you need to develop or refine measurement systems so that you can improve process outputs.