Understanding comes first.

Yes, yes, I know. It sounds like one of the Seven Habits. I’d be happier if it was one of the seven virtues, seven wonders of the world, or even one of the seven dwarves.

It’s okay. Covey’s authorship and my insane jealousy of his success notwithstanding, understanding should come first. So credit where it’s due, and anyway, this is a completely different context. While as a matter of both good manners and wisdom it is a good idea to understand what the other feller is trying to say before you start to pick it apart, it has nothing to do with this week’s subject.

This week we’re talking about documenting stuff, writing about stuff, designing stuff, and stuff like that.

Starting with this admittedly trivial aspect of the subject: If you find yourself using “thing” and “stuff” a lot in your writing (and “You know what I mean” in your speech), there’s a decent chance you haven’t thought your subject through. Thing and stuff are vague generalities whose use should be reserved for the most general cases only. Otherwise you can always find a more precise word or phrase that helps readers home in on what you’re talking about.

But that’s more symptom than anything else. I’m talking about the admirable but ultimately misplaced focus many analysts and designers have to get the documentation right. Not that getting it wrong is better, understand. It’s that …

An illustration: Imagine you’re documenting a business process, as is required for various business certifications that start with “ISO,” as well as being insisted upon by one or two maturity model variants. You get the experts into a room, ask what triggers the process in question, ask “and then what happens?” over and over again, and use the answers to build a comprehensive flow chart comprised of a few hundred boxes connected by appropriate arrows and requires a large-format printer to render.

You’ve accurately documented the process, which is useful. The shortcoming: While you’ve documented the process you don’t understand it.

In part, it’s a forest/trees problem — excessive detail can obscure the essentials. As we’re using process analysis as our exemplar (and I’m constructing a strawman to flail at), imagine that instead of setting a goal of “documenting the process” we made our goal understanding it instead. What would we have done differently?

First, we’d have started by listing the process’s outputs. They’re the essence of what matters. Everything else is just the means to producing them; any other means is equally valid.

Next, the inputs — the raw materials the process transforms into its outputs.

Following that … and this won’t be surprising to regular readers … are the organization’s priorities with respect to process optimization. Organizing a process to (for example) maximize flexibility can lead to a very different design than optimizing for, say, a low defect rate (Chapter 3 of Bare Bones Change Management provides a reasonably complete account of process optimization parameters and their trade-offs).

Now is it time for the flow chart? Sorta. Now is the time for flow charts that follow guidelines along the lines of what the Rational Unified Process advises for developing use cases: If you have more than about seven steps in your process description you need to re-think your process description.

Which is often four steps too many, as a very large number of business processes have only three steps to describe: Collect information -> Update databases -> Create process outputs.

Simplistic? Not really, although it is an awfully simple account. Its value is in encouraging this question: Is there a simpler way to collect all the information and use it to update the database?

Because the next step is to drill down each step into the process flow inside it, also adhering to the seven-or-so step guideline. Three layers is almost always enough detail; I’ve never seen a process that’s needed more than four (I’ll save you the math — that’s enough room to describe 2,401 process steps).

But if you follow these guidelines without making understanding the point, all you’ll have accomplished is to document the process differently. Everything I’ve described here is just a means to that end — a way to facilitate understanding.

Not that understanding, all by itself, will do you much good either. But it’s a prerequisite to what you do need.

No, not love, no matter what Sergeant Pepper’s Lonely Hearts Club Band sings, and no matter how pleasant the experience.

What you need, in the world of business, at least, are insights. You get them by understanding something deeply enough to visualize it.

Which is one reason I wish we could stop calling the stuff “documentation.” It might describe what the stuff is, but it misses what matters … what it’s for.