My perspective on the coding versus modeling balance

Root Cause Analysis stencil uploaded on Graffletopia Stencil

There are few OmniGraffle stencils which I use frequently during my consulting gigs, especially while gathering information for a change initiative, and in presentations also. One of my favorites is the one I just uploaded to Graffletopia for sharing.

Notation info

• Observable Facts are ellipses (or bubbles). 
• When using a tool for drawing like OmniGraffle, I take advantage of colors to display perceived severity. White is neutral, from yellow to red is bad. Black is disaster.
• Border thickness maps to our perception of our ability to affect/change a phenomenon. A fact with no border is under our control, a fact with a thick border is something we cannot influence easily. A company policy which is generating an undesirable effect might be mapped like a constrained fact (but later, you might be in the position to influence it).
• Unknown Areas are represented as clouds. There's something important there which we don't know yet.
• Question marks are part of the stencil as well. I never know everything, but mapping the things that I don't know is often a good idea.
• Since my primary use is to collect information for change at a system level, local solutions are part of the notation also.
• Direct dependencies are represented by arrows. 
• Dotted line arrows represent indirect dependencies. I'm less strict than some other more precise notation, I use the same dotted line for not-so-clearly-related facts and for relationships with delay. It's less precise, but at sketching time I probably don't have enough information to make a clear distinction anyway.

Some guidance

I have to admit I am driven by instinct more than a real formal process. However in drawing the map I have influences from Peter Senge ("The Fifth Discipline"), Craig Larman ("Scaling Lean & Agile Development" and from Eliyahu Goldratt (who described the Reality Tree in "It's not Luck!").

Collecting Data

I start collecting sparse data, from my observation. If I can draw direct links, I add them. If a fact has no clear explanation, I add a cloud or a question mark. Same goes of the causal effect link is no sufficient to imply the consequence. The fact that it's raining doesn't necessarily imply that I'll get wet. But if my car is broken, and I have no umbrella, and I have to go shopping for food, that's another story.

I don't need that much precision on the constraints. I like to capture the mood. If the team says there's nothing that it can be done about a policy, I'll draw it as a constrained fact. But I'll challenge that assumption later when it comes to use the drawing for collaborative problem solving,

Please feel free to share your comments. Hope you'll find it useful!