Solving Systems Engineering problems on the Back of a Napkin

Paul Martin's artifact from a Dan Roam seminar,
a napkin depicting the "visual thinking codex"

The other day I was able to go to a lecture by Dan Roam, the author of the wildly popular book, "The Back of the Napkin: Solving Problems and Selling Ideas with Pictures."  His topic was, "What to do when words don't work" and his seemingly outrageous claim the, "You can solve our problem with pictures." What problems? Any problem. And what pictures? Well you need just a few.
Look at my napkin from the seminar and you'll see only six are needed, Portraits, Charts, Maps, Timelines, Flowcharts, and Equations. The impressive part was how effective he was in using these very simplistic graphics of circles, squares, and stick figures. And why was he able to convey concepts so powerfully with these simplistic drawings? Because almost 50% of our brain is dedicated to visual processing. Mr. Roam made another sweeping statement during his lecture . . . "Whoever best describes the problem is the one most likely to solve it." And this is where I believe Systems Engineers live and breathe.  Our main business is using pictures to get across the problems and their solutions. Functional Flow Block Diagrams, System Boundary Diagrams, IDEF0, Use Cases, ConOp diagrams, all the DoDAF diagrams like the OV-1, etc. All of these "pictures" are used to communicate a design of a solution to a problem.  Just look at what the Zachman Framework for enterprise architecture is all about ~~ it's a slice and dice of different views of a system. And think about how the Systems Engineer because a story teller during each design review...

• Here's the problem
• Here's a solution
• Here's the solution within its environment
• Here's the solution in operation
• Here's the solution when it needs to be repaired
• Here's the solution after its all finished and needs to be thrown away.

From the customer need, to the design, to the build, to the operation and maintenance, to disposal -- it's all one story with a beginning, middle and end. And the  Systems Engineer tells that story of a system's life with mostly pictures and diagrams. So don't worry about being able to draw, you're just out of practice. And don't be afraid to embrace your inner artist.