In last week’s podcast (Podcast and transcription: Shared Understanding with Dialogue Mapping) , I asked KC Burgess Yakemovic of Cognexus Group that question:
Joe: One of the things that challenges me when I’m looking at it is that I’m not sure let’s say how often I would use it or what’s the limitations to Dialogue Mapping. Is it easier to explain when to use it or is it easier to explain when you don’t use it?
KC: You know that’s a good question. There are aspects of Dialogue Mapping and again, this is one of the benefits of having this sort of the step-by-step process to get up to the point of doing Dialogue Mapping. Because formal Dialogue Mapping used in its entirety, the places where the benefits exceed the work, that goes into it, are fairly limited. If you’re a professional facilitator, you may use it a lot more frequently. If you’re working in a business environment, there are aspects of Dialogue Mapping such as the capture of information during a meeting that can be used without being the person doing the facilitation and those skills can be used very, very frequently.
I have some corporate clients who have trained a number of their staff members just to the level of doing the capture and not to actually doing the facilitation piece. They train a limited number of people to do facilitation because they’re not just going to have a large number of meetings where the benefit of the facilitation aspect is sufficient. One of the places that it does come into play very nicely is anytime you’re doing strategic planning, where you have a number of different positions, people have different things they are trying to accomplish and you want to get all of that information out and make sure that the plan that you’re proposing covers as wide a variety of things as possible; complex, complicated things. I’ve used this method in the software design area a lot to deal with problems that keep recurring. You’ll be doing a piece of design, you think you’ve got an answer to how this is going to work, you get out and get started on it and discover, wait that breaks something else over here. And now you go and try to fix that problem and wait now that broke something else.
There was one situation that we actually wrote up in a paper that it turned out there were six interconnected questions that all had to be answered simultaneously to develop a solution that would really work. We would not have noticed this if we had not been capturing our information in an IBIS structure and realized these questions kept not getting — the answers to the questions kept shifting. We took those six questions, put them out in a room at the same time with all of the people involved in the design and when we saw all of these questions together and the answers we proposed, we realized that we didn’t have the right solution, but we were then able to clearly define a solution that solved all six problems simultaneously.
Lean Sales and Marketing: Learn about using CAP-Do
Lean Engagement Team (More Info)