Comings and Goings and Solutions

Aug. 15, 2002
Divergent vs. convergent thinking in the world of consulting

How would you define divergent and convergent thinking? As the dictionary defines them, divergence is moving away from, and convergence is moving toward something. The key is remembering what it is you are moving toward

or away from.

This fundamental concept and way of doing things can be of huge benefit to you and/or your business and products--especially now, in these times of trouble, indecision, and product redefinition. Technology isn't changing too fast for you, is it?

The issue here is thinking. Example? A feasibility study is, to my mind, an example of the confusion between divergent and convergent thinking. Normally, the study is conducted to prove the do-ability of some already pre-determined conclusion. There are other reasons, I'm sure, but I've concluded that they all mostly prove or disprove a method, approach, a product, or are simply the affirmation of a different way of doing things.

Divergent thinking is similar to brainstorming, but I think of brainstorming as more of a disorganized blender of ideas that are not necessarily connected in any tidy fashion. Having many issues and ideas that are disconnected might not provide the benefits of divergent thinking.

Diverging from the thinking that created your existing system (whatever that happens to be) starts by identifying what the accomplishment needs to be. Training in divergent thinking can help with the creativity levels required to be successful.

Convergent thinking is the skill (or maybe art, depending on what side of the brain you use) of taking the creative ideas that were unearthed with the divergent thinking process and evaluating the application of these issues to the required pre-defined accomplishments.

I'm involved in one of these feasibility studies for an old company with a new way of thinking. It's a distribution center. They want to change the product flow and conveyance systems to increase productivity, efficiency, and access to operational data. They know how they want to route the product, but they don't know how to get the product there, track the product, and be alerted when something has gone wrong.

The current operation is very open-loop: Do this, then tell me when you're done. There's no tracking or communication to anyone or anything in-between.

So when I was given this project, I had to sit back and really understand what it was that I was being asked to do. Took a few beers and a couple of hours on the deck, but it eventually became clear.

As a consultant, I am supposed to know everything about everything. I will freely admit when I don't know something, but I'll never be afraid to learn and to find out what it's all about.

This is one of those times. My internal audit revealed a treasure chest full of helpful gold nuggets.

The first nugget was recognizing I was dealing with process folks--the people who define the accomplishments needed. The trouble here was they were not very specific in defining their needs. "I want to increase productivity, but sorry, I can't be any more specific than that."

When it became obvious they didn't know what a PLC did or what it could do for them, it was clear I had to present the possible solutions in terms of their knowledge set.

I'm not a management guy, nor do I care to be. I speak Canadian, which takes me off the list faster than most anyway. And my golf swing is marginal. But I realized, like it or not, I had to try to think like a management guy.

I had to learn how. And I'm learning still. Technically, I know what they need to do. But to organize it and present it in a way they would understand was the bigger challenge.

There is also the large issue of explaining why these technical things would have to be done, as well as the methods I used to come to these conclusions.

There was one requirement that I kept missing though, and that came with another nugget. I realized that they were asking me to consider every conceivable option based on varying conveyance locations, and options based on cost, implementation time, and results. But they really didn't come out and say it.

Being more task-oriented than not, it was that one that scared me the most. I'll tell you how I made out in Part 2 of the saga next month.

Jeremy can be contacted through his web site: http://www.tsuonline.com.