September 27, 2011 2 Comments
This morning I started reading “Turning numbers into Knowledge” by Koomey; an interesting book gear more towards academics and researchers than typical knowledge workers. When I say geared, it’s the style and tone of writing more so than the information contained within. The book presents a how-to organize your problem solving. The small amount I’ve read so far had me thinking about the problem of problem solving and if in the scheme of issues it ranked high on an organization’s the Pareto List of critical items to address. Combing through my various graphical notes
–I typically create diagrams and sketches for notes rather than text; I had found visual note taking and thinking to be more information intensive than typical text when I was studying architecture. This was later reinforced by a business associate, Eileen Clegg; I met at the Congress on the Future of Engineering Software (COFES) several years ago. Her company Visual Insights http://www.visualinsight.net/ is a welcomed regular fixture at this annual event. I think the one year she missed attendance there were several people, myself included, asking why. Many of the Engineering and Engineering Software community’s best; the most creative, innovative and productive are visual thinkers. I can’t recall a single member of this esteemed group that didn’t have to have a whiteboard or some graphical tool suite in order to think or relate information during our conversations.
At first I thought it was because these were complex topics with lots of detail, which each could be. The diagrams and pictures though were for the most part very simple, no more than a few simple lines, circles and arcs, etc. However, like the Chinese saying “One picture is worth a thousand words” these minimalist sketches were very dense in the information they chaptered and represented.–
I bring up graphical notes as to indicate that during my career, as I’ve taken notes, I have captured in my graphical journaling much more details than just the issue that was to be address at the time. Many times I would capture the process of how the group solved the problem or made the decision. The various projects I’ve been involved with regarding reengineering processes for Rockwell, Boeing, Microsoft, IBM, Samsung and a host of small companies has introduced me to multiple graphical techniques. Even as I write this post this morning I find myself drawn to mindmap my thoughts as opposed to writing out these ideas. Writing –as skill I’m trying to improve upon these past few years—is basically one dimensional while my thinking in multidimensional so relationships between concepts are lost in translation as I peck out the words. Thankfully Hypertext had been created, so I can come back at a later date and establish those relationships. This has become a long way around and may still have some missing links between my initial thoughts and the insight below, but I’ll come back at a later time and address that bridging issue.
What I discover –again, which was the rationale for creating Intellectual Arbitrage Group—was that most problems companies are addressing are the same. What makes them appear different is the context in which they live. The majority of the activity people in organizations perform is not really deep problem solving but daily searching and translation to the context they’re working in. Some of the interesting issues around that is identifying the core solution set. Often because problem/solution pairs are not well documented, people will take the closest solution metaphor at hand to use. This from my findings is one of the root causes of project failure as opposed to technical failure. So the end results of many projects are technical success but not achievement of business objectives.
The cause of this misalignment and how to avoid such will be the topic of future post as I continue to diagram out a working Information Management Methodology.